This month’s LTT by Lionel Griache was meant to illustrate the many challenges of reconciling Data-Traffic, in particular in the context of Roaming.
Most platforms create intermediate CDRs for long data sessions. As a result, it can be a little tricky to perform 1-to-1 reconciliations. Some of the challenges for these data-reconciliations are:
- The number of intermediate-CDRs produced per session depends on the configuration of the platform, so for 1 session you might have 10 recorded CDRs in your local data-switch, 8 CDRs in your TAP files and 1 in your prepaid platform. Reconciliation on CDR-Count is therefore not relevant. You might have access to a “session identifier” in your CDRs. If that is the case, reconciling on the number of session-id (or charging-id) might be a relevant control.
- The total data-volume recorded will also differ slightly between platforms. Connection-attempts and protocol-handshakes are not seen the same way by all platforms and could result in a small percentage of variation in the total data-volume recorded. This variation should always be within an acceptable margin.
- Though not illustrated in this LTT, in the context of roaming you also need to account for the timezone differences in the timestamps received
With this in mind, to solve this challenge, you had to add the total data-volume per subscriber recorded on each platform. You’d then see immediately that 3 subscribers stood-out: +33xxxx114, +33xxxx596 and +33xxxx781. These 3 subscribers show much lower total data-volumes on the prepaid platform than on the TAP files and on the local data-switch. This is a first alert that a leak might be taking place. The balance information was an additional clue to understand the root cause of the problem: if you add the retail-value of the CDRs charged on the Prepaid platform for these 3 subscribers, you see that they add-up pretty much to match their open-balance at the start of the day. In other words, these subscribers were charged for their data-usage fully… until all their available balance had been used. Once their credit expired, you’d expect the data-usage to stop. In this LTT example, the data-usage continued for these subscribers, generating direct revenue-loss.
This kind of problem can take place if you have a weak interface between the Prepaid platform (responsible for the charging of the data-session) and your local Data-switch (responsible for allowing/denying/interrupting the data-sessions). In this example, it looks like roaming data-session are not interrupted nor denied for subscribers with no available credit.
The answer to this LTT is therefore: Yes, you should alert the CFO about the suspicion that prepaid roaming subscribers can enjoy data-traffic beyond what their available credit should normally allow them to. The 3 subscribers visibly demonstrating the problem are: +33xxxx114, +33xxxx596 and +33xxxx781
Congrats to Sriram Dharmarajan for providing a valid answer.