Carrier Inter-connect use case
Telecom network operators worldwide open their networks to each other to enable their mutual customers to communicate across network boundaries. This practice, known as “Interconnect,” is being used among national and international operators for fixed, mobile, and Internet services. Network operators cross-charge each other for the interconnect services they offer each other’s customers. It is done through invoicing/billing and settlements.
Network operators collect and store detailed information in a record known as Call Detail Record (CDR) about every call ever attempted, whether completed or not. A typical CDR captures data such as calling and called party phone numbers, duration of the call, CDR unique ID, a timestamp for each activity, the ID of the equipment that handled the call, the result of the call, and so on. Interconnect partners share CDRs for the purpose of “verifying” cross charges and settling balances. This verification process is cumbersome, inefficient, lengthy, costly, and error-prone. Missing CDRs and discrepancies in CDRs are very common problems.
Due to the large number of network operators globally and the many-to-many relationships amongst them, the complexity and amount of cross charging and settlements data is exponential and very error-prone, causing Interconnect to be very expensive. Interconnect is considered one of the largest operating costs and ranges from 30% to 50%, according to some estimates. For example, to settle roaming charges, mobile operators check the International Data Clearing Houses (DCH) to validate roaming charges and then cross-reference the data against charges information provided by Financial Clearing Houses (FCH). FCH are used for debt collection rates and clearing accuracy. Access to DCH and FCH data is slow and the data itself is error prone. Network operators spend substantial amounts of time and money to fix data errors and to reconcile their records and books.
A Blockchain based solution could be used to simplify and expedite the Interconnect’s cross-charging and billing data-verification process. Network operators would store CDR data related to the Interconnect cross-charging and billing into the Blockchain in real time. All operators will have instantaneous access to the data without being able to modify it. The Blockchain ledger becomes the single source of truth, which allows network operators to access and verify billing and cross-charging data in real-time. It eliminates the need for data clearing houses and makes the reconciliation and settlement process simple and error-free. It also helps fighting and preventing fraud.
Network operators dedicate resources just to negotiate Interonnect charges and clearing agreements with other network operators. Once reached, agreements are scripted and governed by international regulations. A Blockchain smart contract can be used to execute these agreements. Certified charging data can also be stored on the Blockchain, which would eliminate the need for financial clearing houses.
The direct beneficiary of the Blockchain-based solution are network operators that collectively constitute a business network or a closed ecosystem whose members have formal legal relationships and share a certain level, but not absolute, trust. This makes a permissioned DLT, such as the Hyperledger, more suitable than a permission-less public Blockchain. This is due to the nature of the relationships amongst network operators. For example, not all network operators need, or should have, access to all CDR data on the ledger; only those who have Interonnect agreements should have access to their mutual data. Also, CDR data contains confidential customer information and should not be open to the public. A permissioned DLT allows for controlled access to information on the ledger.
From the network operators’ perspective, the proposed Blockchain solution is efficiency enhancing, i.e., intensive margin, whereas, from the data and financial and clearing-houses perspective, it is a substitute threat.
With the exception to the human interaction aspect related to negotiations and dispute resolution, Interconnect falls in the digital space. This makes the last mile problem minimum and manageable. Basically, once Interconnect charges and billing terms and conditions are reached, all data generation, storage on the Blockchain, and verification is done automatically by the network. The last mile problem arises in situations when CDR data is in doubt. In general, telecom network equipment manufacturers certify CDR data. However, there is no guarantee that some network operators may manipulate the data to their advantage before writing it on the Blockchain. The solution is to establish some sort of governance and third-party auditors to ensure data providence and veracity. Data and financials clearing houses can be used to perform CDR data audits.
The above solution is simplistic and intentionally did not address key details related to Interconnect regulatory aspects, types of agreements, call scenarios, invoicing, settlement, and netting, and reconciliation processes. These details have a great deal of impact on the how the smart contracts are structured, executed, and disputed in case of disagreements.
Proposal:
Develop a PoC to demonstrate a simple use case that involves a minimum of two carriers to post/update a minimum set of call related data on a DLT for the sake of settling cross-charges in realtime. The scope, details, call flows, and development roadmap are subject to discussion and consensus within the group.
Beautiful writeup!
A couple of points
Using any ledger shared by the participants for private data has some challenging properties
"only those who have Interconnect agreements should have access to their mutual data" could imply (in the HL Fabric context)
a. bilateral channels or private data collections- bilateral channels could imply explosion of channels (maybe in the context of Telecoms it is not very crucial) but it is n**2 for n participants. What is the rough measure of n for telecoms?
b. netting across channels for bilateral will mean some kind of interoperability
c. real-time settling could be another challenge as this might not take full advantage of netting; a solution could be to use an IOU token or a digital coin, and periodically settle them outside the system after netting. Is a link to the FabToken proposal.
d. I would opt for a PoC where you need at least three carriers to explore privacy and netting challenges noted above.
e. Pruning of spent(settled and aged out) on-chain data will need some kind of governance, since if allowed to grow monotonically will have consequences.
f. Maybe a totally different approach in the form of L2 protocols to preserve privacy and speed and data obsolescence could be the answer, with the ledger providing the anchor.