Billing of roaming and the future of TAP

When two companies do business, there is generally a monthly invoice and a specification of the goods sold. Roaming has always been different – we have had Transfer Accounting Protocol (“TAP”). For those of you who don’t know, TAP is a container format for the of Call Detail Records (CDRs) for the Home Network’s (HPMN) customers use of the Visited Network (VPMN). These CDRs were originally used for the retail rating of the roamers. Originally, HPMN only applied a mark-up of the wholesale price in the CDRs to derive to the retail rate. After the introduction of rerating, the rate in the TAP CDRs was only used for wholesale reconciliation.

So that was how it started – that was when I worked for an operator who bought the Roameo service from DanNet, where the market alternative was MACH in Luxembourg. An ancient history, old enough to not even be known by most industry people today.

How is it today? Well very different. The HMPN can generate CDRs for almost all the relevant cases, without relying on TAP.

Data: Home Routing has been the norm from day 1. As a side note, I have had long discussions with engineers from the internet business who blame this home routing is the reason why roaming data was expensive, not really understanding any other concept that a sales price that is cost + margin. Let’s leave that topic for another time, but home routing makes it possible to use the GGSN/PGW for rating purposes. All the customer’s data usage goes via it, and it’s hence a point of full control of the rating. Inside the EU you are even obliged to control data usage; a warning SMS must be sent at €40 and the consumption blocked at €50 unless the subscriber accepts additional charges. So this exists and works well.

SMS MO: By design, SMS MO is “home routed”. The phone communicates with the home SMSC and then the Home SMSC sends the message to the recipient. So by design, all messages can be accounted in real time for in the home SMSC.

SMS MT: Normally this is not a case the VPMN charges for (except in a handful of countries), and there is hence normally no need to do any retail rating in the first place. However, in addition since the introduction of “Home Routing for SMS” (which operators really should have for many reasons) the messages, also for the MT case, then passes a node in the home network. Thereby, the HPMN has full control of the message and could charge for it in real time if it wants.

Voice MT: All calls address the subscriber using the phone number (MSISDN). So when roaming, the call reaches the HPMN and then the call is forwarded (RFL = Roaming Forwarding Leg) to the VPMN using a temporary phone number (MSRN = Mobile Subscriber Roaming Number) that is used only for this kind of forwarding. Communication goes via HPMN, who then has full control and can do real time rating.

Voice MO: Outgoing calls are typically routed by the VPMN to the end destination, without passing the HPMN. But this is not the full picture, and you must break this scenario down.

= VoLTE – In VoLTE you can use S8HR. That means home routing also of the voice calls, and this goes on top of the general data pipe, normally using a GRX/IPX service. So MO VoLTE is also possible to fully rate in real time by the HPMN.

In all the cases so far, the communication goes via the HPMN and it can hence be rated in real time. TAP gives the details for validating the wholesale invoice you get, and you can cross reference the details with your own details but it shouldn’t be used for retail rating.

= CAMEL – If the roaming relation supports CAMEL, then CAMEL provides real time control so that the HPMN can do real time rating. So, also MO Voice under CAMEL is also fully possible to real time rate by the HPMN even if the payload is not home routed.

However there is a last case;

= Voice MO, Non-VoLTE and for non-camel relations. Here you DO need the TAP CDRs for retail rating.

As a conclusion, we do have ONE scenario where we still need TAP for it’s original purpose. I could easily see a scenario where operators having CAMEL in place, agrees to scrap TAP from the relation and only exchange an aggregated report. It makes sense to have the TAP relation open for the TD (Test Data) so that you can perform the TADIG test, but as soon as you go into CD (Commercial Data) then it’s no longer needed.