Hyperledger-based Solution for Reducing the Cost of Settling Inter-carrier Charges

Index
Purpose of This Paper
Intended Audience
1 Introduction
1.1 The Problem
1.2 Solution Highlights
2 Why Hyperledger
3 Business Architecture
4 Module Description
4.1 Partner Portal
4.2 ETL Module (Extract Transform Load)
4.3 Open APIs and Collection Services 10
4.4 Alarms and Alerts
4.5 Payments & Collections
4.6 Rate management
4.7 Deal Management
4.8 Rating
4.9 Aggregation
4.10 Disputes
4.11 On boarding/Identity Services
4.12 Smart Contract Manager (Audits)
5 Technical Architecture
5.1 Middle Layer
5.2 Blockchain Network
5.3 Entities in the Blockchain Network
5.4 Flow of transactions
6 Hardware Sizing
7 Blockchain Challenges
8 Next Steps (Proposal)
9 Conclusions
10 Annex A – Hyperledger Frameworks
Table 1: Summary of Hyperledger Frameworks
1.0 TCSIG published in June 2019.
This work is licensed under a Creative Commons Attribution 4.0 International License
creativecommons.org/licenses/by/4.0

Purpose of This Paper

The purpose of this white paper is to define how a blockchain-based solution can help telecommunication service providers settle cross-charging payments efficiently and quickly by reducing friction and removing intermediaries. The objectives of this white paper are to define a Minimum Viable Product (MVP) for a solution and propose a consortium of wholesale operators which would use the solution to address the settlements problem.

Intended Audience

The primary audience of this white paper is network operators who are interested in reducing the cost of cross-charging settlements, as well as technical people who are interested in exploring the technology by implementing a real use case.

1 Introduction

This white paper will describe the inefficiencies and problems of the current solutions telecommunication network operators use to settle charges amongst themselves. The paper will also propose a new approach based on Hyperledger technology to make the process more efficient and cost effective.

1.1 The Problem

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 a 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% of the overall operator’s business, according to some estimates. In many cases, Interconnect is the only primary business of a telecom operator that deals in wholesale business. For example, to settle roaming charges, mobile operators check International Data Clearing Houses (DCH) to validate roaming fees and then cross-reference the data against the 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 money to avail the settlement services from the clearinghouses and also fixing data errors to reconcile their records and books.
Traditional partners are the interconnect entities who form the wholesale business. The fundamental problems emerging from general partnerships are about long contract timelines, disputes due to data mismatches, and long settlement processes that block the disputed revenue for both parties. In most cases, billing discrepancies are honest mistakes, but in some instances, it can be malicious as well where the intention is to block payments or renegotiate on the payables. Some of the most common disputes can take several months to get resolved; in some cases, the operator must compromise and write-off the amount to close the dispute as well. The root of the problem lies in the way transactions are controlled between partners. Since both the parties have a centralized siloed approach of maintaining records, there is a lack of transparency leading to lack of trust. Traditional databases generally are not encrypted by default and are managed centrally; hence there is always a threat of sensitive data getting lost or manipulated if the access of authority gets compromised.

Let us take a simple example:
● Billing Cycle – Monthly
● Billing Generation & Distribution – 5th of every month
● Bill Reconciliation – 2-3 days
● Dispute Identification & Confirmation – 15-45 Days
● Dispute claim form that contains the disputed destinations, volumes and rates along with Police report for fraudulent transactions is shared for the partner to start dispute investigation
● CDR reconciliation process – 90 – 180 Days
● Dispute Analysis and resolution by Partner – Months to Years
● Result – Blocked receivables and Write-offs in some cases
● Additional Overhead – Police report is mandatory in some countries to raise dispute due to fraud. Which is not always accepted due to limited information, unreliable format etc.
● Fraud Disputes – Wholesale business get to know about Fraudulent transactions only after the reconciliation process is initiated.
Note: Above mentioned numbers are based on Operator interviews and generic wholesale practices of settlement.
This shows that traditional ways of settlements are not just time consuming, it also results in multiple overhead issues, exposure to fraud and blockage or loss of revenue because of unpaid bills. To counter this critical problem which is now one of the most vocal concerns of Wholesale operators it has to be addressed by Technology, Process and People.

1.2 Solution Highlights

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 with fighting and preventing fraud. Many operators and companies are trying Blockchain solution for speedy settlements.
Network operators dedicate resources just to negotiate Interconnect charges and clearing agreements with other network operators. Once reached, agreements are scripted and governed by regulations. A Blockchain smart contract can be used to execute these agreements. Certified charging data can be stored on the Blockchain, which would eliminate the need for third parties and the tedious process of settlement.
The direct beneficiaries of the Blockchain-based solution are network operators that collectively constitute a business network (a consortium) or a closed ecosystem whose members have formal legal relationships and share a certain level of, but not absolute, trust. This makes a permissioned Distributed Ledger Technology (DLT), such as one of the Hyperledger frameworks, more suitable than a permission-less public Blockchain. This is due to the nature of the relationships among network operators. For example, not all network operators need, or should have, access to all CDR data on the ledger; only those who have interconnection or roaming 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.
With the exception to the human interaction aspect related to negotiations and dispute resolution, Interconnect falls in the digital space. Basically, once Interconnect charges and billing terms and conditions are reached, all data generation, storage on the Blockchain, and verification are done automatically by the Hyperledger consortium. In general, telecom network equipment manufacturers certify CDR data, however, there is no guarantee that some network operators don’t manipulate the data to their advantage before writing it on the Blockchain. The solution is to establish a blockchain governance process to ensure data providence and veracity.
Solution Essentials
● Gain better visibility between partners belonging to the same channel
● Build transparency and trust across deals and financial transactions
● Ensure financial and legal compliance in transactions
● Increased direct control by reducing intermediary dependency
● Eliminate insecurity in transaction manipulation

2 Why Hyperledger

When it comes to Wholesale settlements, the operators that partner with each other based on agreed rates either though rate card exchange or bulk deal contracts are known entities. The problem faced by wholesale operators is not about trust as they have granted permission to do business with each other, but it is about the fragmented processes that delay the overall settlement processes and hence block the receivables. Hence, for such a setup, where trusted entities will interact, an enterprise grade Blockchain is the best fit and it is crucial to evaluate a right platform that can integrate with existing billing solutions to bring in the capabilities of Blockchain to make the overall processes seamless and transparent to the parties interacting with each other. Sensitivity of data, throughput and capability to handle huge volumes that are very common in the wholesale interconnect business are mandatory requirements for the platform selection. Another key factor to use when deciding the choice of platform is to use open source technologies, of late telecom operators are opting for technology platforms that do not add to the TCO (Total Cost of Ownership).
Considering these requirements, Linux Foundation governed Hyperledger Fabric seems to be the best fit due to the following capabilities:

● An open source platform governed by the Linux Foundation with the objective to redefine the nature of trust on the Internet. It is a collaboration between over 250 members from various domains and 21 Hyperledger governing members1.
● Well defined Roadmap and dedicated community for long term project support which ensures the addition of new capabilities and for timely closure of the issues.
● Proven track record of successful PoCs and popularity with the enterprises that want to build permissioned blockchain solutions, where only the allowed entities can exist.
● Platform capable of hosting multiple interconnect partners as part of the consortium by creating partitioned channels to enable coexistence but at the same time maintain privacy of the data.
● Hyperledger does not require public miners because of the inbuilt Orderer that handles the consensus, hence there is no concept of cryptocurrency in the permissioned blockchain making it suitable to comply with regulatory bodies across geographies.
● Based on some of the performance experiments, Hyperledger has shown good numbers in terms of the transactions per second. Based on the Cornell University publication, FastFabric 2research paper, the throughput of 20,000 Transaction were achieved per second. Another research by IBM 3has shown throughput of 13,000 Transactions per second. These numbers look promising and make Hyperledger suitable for the wholesale use cases.

1 https://www.linuxfoundation.org/
2 https://arxiv.org/abs/1901.00910
3 https://www.ibm.com/blogs/blockchain/2019/04/does-hyperledger-fabric-perform-at-scale/

3 Business Architecture

The proposed solution will complement existing legacy BSS/OSS systems deployed by CSPs by enabling blockchain based settlement capabilities to drastically reduce complexities of dispute management and settlement processes. The proposed architecture comprises key modules and functionalities that form the basis of a blockchain based settlement solution. The proposed is an event agnostic platform that can manage Voice, SMS, Roaming, IoT, Content or any other event settlement scenarios making it a true convergent approach.
This solution will focus on the support of multi DLT technologies, considering that all operators may not form a single consortium and hence there will be multiple technologies that will be used. Hyperledger is, nonetheless, the primary platform of the proposed solution due to its enterprise grade DLT acceptance and being an open source platform backed by Linux Foundation.
As part of the preferred reconciliation approach, CDRs are to be aggregated based on an acceptable interval for the reconciliation. This will drastically reduce the performance related bottlenecks that are currently a known challenge with DLTs. The Hyperledger Telecom Special Interest Group (SIG) community is actively researching the available techniques by which better throughput can be obtained and is committed to build a solution along with Operators which can reconcile at CDR level for the billions of wholesale records generated across multiple streams including Voice, Roaming, Content, IoT/M2M, MEC and Broadband traffic.

4 Module Description

4.1 Partner Portal

Partner Portal is the key interface for all the participants of the CSP Hyperledger consortium. This brings self-service capabilities as a part of the solution. Several key features that shall be enabled as part of Partner Portal are:
● Self-Onboarding of new partners
● Upload of rate sheets for the solution to log it in blockchain
● Payment & collections
● Bilateral deal Smart Contract creation interface
● Publish reports and dashboards of reconciliation including discrepancies
● Disputes management

4.2 ETL Module (Extract Transform Load)

ETL layer provides a mechanism for CDR data mapping and translating it into an output format appropriate for processing in the Billing and Settlement process.
The ETL consists of three main capabilities
● Decoding: Parse incoming data format, and create output data formats
● Mapping: The process of translating the decoded input data into one or more output data types, including filtering and enrichment of the data
● Operational Control: The process of configuring data sources, collection schedules and managing the run-time environment

4.3 Open APIs and Collection Services

The proposed solution will come with a library of REST APIs that will act as a middle layer and shall enable the integration of existing CSP legacy systems with the new Blockchain based settlement system. Below are some of the key APIs:
● Create Account
● Create Account Profile
● Payment
● Collections
● Deal Creation
● Dispute Creation
Collection services comprise of CDR and rate sheets file collection from respective CSPs. The rate sheets file will be stored as a hash value where it can be produced in case of rate disputes.
CDR collection service will supply CDRs to the ETL layer for aggregation and normalization processes.

4.4 Alarms and Alerts

The solution will come with a range of off-the-peg alerts, where the partners will be advised on the reconciliations and discrepancies so that relevant actions can be taken on priority.

4.5 Payments & Collections

Payments and collection management module will support the incoming and outgoing transactions logged against the invoices. This module is to facilitate the payment and collection capturing by integrating over APIs or can be logged using the screen options.

4.6 Rate management

Once the rates are uploaded and the other party authorizes the rates, a consensus is established, and the rate entries will be created in the ledger. Rate sheet file can also be maintained with hash value for future reference in case of rate discrepancies.

4.7 Deal Management

The solution will support a multitude of agreement models that can be configured using a user-friendly graphical interface. Different types of agreements such as committed, tiered, back to first minute, balanced deals and others.
A deal can be configured using multiple ways, user can configure the deal smart contract template available via Partner Portal or deal information can be shared over an API. Deal data will be written in the ledger once there is a consensus met between the partners once the deal is accepted. Deal document hash can also be maintained in the ledger for future reference to resolve rate and volume discrepancies.

4.8 Rating

Here the input CDRs are matched against partner reference configurations setup in the system and rated based on the price setup against corresponding services.
This process can be optional in case of existing billing solutions, the recommended approach in case of legacy solutions is to have rated records from the CSPs participating in the consortium for the reconciliation process. For rating, smart contracts will be created that can pick the agreed rates from rate sheets and deals to rate the CDRs based on rates logged in the ledger after meeting the partner consensus, so that the rate disputes can be entirely avoided.

4.9 Aggregation

The rated records undergo an aggregation process which summarizes the CDRs on a configurable aggregation level (hourly, daily, or based on other business decisions.). A configurable aggregation is required for a channel, there can be a different aggregation model agreed across multiple channels, but for partners belonging to the same channel should maintain the same aggregation for a faster reconciliation process.

4.10 Disputes

Dispute management can be achieved directly from Partner Portal or by exposing the key APIs to create and manage dispute in legacy solutions. The objective of a Wholesale Blockchain solution is to have minimum disputes, but in the case of discrepancies which could be due to volume, rate or fraudulent transaction should be handled with a structured dispute management process.

4.11 Onboarding/Identity Services

Onboarding service is a workflow-based module used for adding new organizations in the blockchain and to create different channels enabling the settlement services.
An administrator can put a request and the system will create a workflow to approve the channel and peer creation.
Based on the selected partnerships from the consortium list, the system shall enable auto channel creation between the parties that are involved in the settlement process.
A partner portal user can be created and enabled using the Onboarding service feature.
Key account management activities like enabling, disabling organizations and channels will be taken care from this module.

4.12 Smart Contract Manager (Audits)

Smart Contract Manager feature enables the customer to track existing contracts that are live and new contracts that are either in draft or testing stage. Through Smart Contract Manager a user can see the history of contract execution, the status of execution and various organization and peers for which the contract was run.
The administrator view of Smart Contract Manager can also provide information on various APIs that were triggered by the Smart Contract to perform business tasks.

5 Technical Architecture

5.1 Middle Layer

The wholesale solution involves the middle layer stack to interface with the legacy OSS/BSS systems to receive the input data using APIs for various purposes. The normalization of data and the pre-processing is done in this middle layer which is then passed down to the Hyperledger Fabric blockchain network. Multi-DLT scenario could be handled using available plugins to facilitate the communication between the middle layer to the blockchain network.

5.2 Blockchain Network

Administration of the Hyperledger Fabric network will be able to define the network, add/remove participants, provide roles and privileges, create/modify/delete channels, etc. The Hyperledger fabric network comprises the multiple organizations each representing a collaborating operator (CSP). The operators who are involved in the wholesale settlement process will be added to the fabric network and will communicate with each other via a separate channel. This ensures that the data is available only to the participating operators and not any other operator. In the illustration diagram, CSP1 and CSP2 communicate with each other via channel1 and CSP3 and CSP4 communicate with each other via channel2. In this case, neither CSP1 nor CSP2 will be able to retrieve or tamper the data pertaining to CSP3 or CSP4, and vice versa. This ensures a secure channel of communication.

5.3 Entities in the Blockchain Network

The Hyperledger Fabric network will have different entities where each of them has a distinct role to perform.
● There must be at least one ledger per channel to record each transaction. They would be in sync across all the general peers of all the participating organizations on a single channel. This ensures that the data is distributed across multiple ledgers to maintain integrity.
● There will be at least one smart contract per channel which will write to the corresponding ledger. The smart contract, otherwise referred to as Chaincode in Hyperledger Fabric, will have the custom logic built by Subex to perform the required operations involving wholesale settlement. The aggregated CDR entries would be reconciled, and the required output will be written to the ledger thus recording a transaction.
● The peer node which will run a smart contract will be the endorsing peer.
● The Anchor peer will be responsible for the communication between different organizations via a channel.
● The Orderer peer will be responsible for ordering the transactions before they are validated and committed to the ledger by the committing peer.
Note: The peers can either be located within the operators’ premises or can be provisioned on the cloud to minimize the complexity.

5.4 Flow of transactions

The CDR of the participating operators will be picked by the middle layer then normalized and aggregated. They will then be fed to the Hyperledger Fabric network. The fabric will be designed in such a way that the participating organizations will be connected to each other via a dedicated channel provided they are the source/destination of the corresponding CDR’s. So, the other unintended participants in the fabric network will not be able to communicate with those who are part of another channel.
Only the involved organizations are configured to be part of a particular channel. The consensus involved in making a transaction successful includes the endorsement from the organizations (performed by endorsing peer), ordering the transactions (performed by the Orderer node) and finally validating and then committing the valid transactions to the ledger (performed by the committing/general peer).

6 Hardware Sizing

The minimum recommendation of hardware sizing for PoC:
EEndorsing peer node
1 per Chaincode per organization
AAnchor peer node
1 per organization
OOrderer node
1 per channel
CCommitting peer node
2 per organization
The hardware sizing provided would be required for the wholesale settlement MVP, though the number of the peer nodes can differ based on the actual load and transaction rate.
The considerations made for the above-mentioned sizing are:

● One endorsing peer node per Chaincode will enable higher performance if multiple smart contracts are to be run in parallel without adversely affecting the endorsement process.
● Two committing peers per organization would facilitate distributed availability of the ledger.
● One anchor peer per organization would facilitate the connection between the organizations in the channel.
● One Orderer per channel would help in ordering the messages so that they are sent to the connected peers in the same order.

7. Blockchain Challenges

Inter-Carrier Settlements, when combined with blockchain, which brings in the philosophy of consensus, security, privacy, and trust, can address some of the key challenges of partnerships. Telecommunication companies can leverage this emerging technology to create a difference in today’s dynamic business landscape with existing and emerging partners. As the technology is in its initial stages, along with the promising capabilities, there are its own set of challenges. Hyperledger Telecom Special Interest Group (SIG) is actively collaborating with Operators, Vendors, and Researchers to solve the below challenges:
1. Business Challenges - Define use cases and integrate these with multi DLT technology to provide better results. Some of the identified use cases are around wholesale Disputes and Invoice reconciliation.
2. Performance Challenges – This is one of the biggest challenges, the current wholesale partnerships between two operators amount to millions of transactions per day. This value will only rise when we talk about the IoT and M2M scenarios with 5G becoming mainstream. Hyperledger Telecom SIG is committed to collaborating with the technical community to build a blockchain based solution that does not just bring expected performance, but also optimizes the resources to have cost-effective solutions.
3. Interoperability challenges – Another challenge of blockchain is interoperability between multi DLT platforms. Blockchain can only be effective if used by a consortium, but it does not make sense to limit each party to a common DLT platform. Hence another key aspect where Hyperledger Telecom SIG wants to collaborate is to solve interoperability challenges. There are multiple projects like Hyperledger Quilt, Polkadot, Ark Smartbridge that are working to solve this problem. We believe that the right solution combined with optimization shall solve this challenge for the parties that which to partner on different DLT platforms.

8. Next Steps (Proposal)

The next step will be to develop a PoC demonstrating Inter-Carrier Settlement use case and form an operator consortium. This whitepaper is a step forward to showcase the intention of Hyperledger Telecom SIG in solving traditional reconciliation processes, bringing automation and simplification of exchanges. The scope, details, call flows, and development roadmap are subject to discussion and consensus within the group.

9. Conclusions

Decentralization is at the heart of Blockchain and the distributed ledger technologies (DLT) and is the underpinning enabler of disintermediation. At its core, disintermediation is the economical driver fueling the adoption of DLT across many industries, including telecommunications.
Inefficiencies of the intercarrier settlement process within the telecommunications industry are well documented and understood by practitioners. Over the years, network operators have lost billions of dollars due to disputes over billing data discrepancies and mismatches and also due to delayed revenue recognition.
In this paper, we explained the inter-carrier settlement problem in detail and proposed a solution based on the open source Hyperledger DLT. The solution simplifies the settlement process by creating a trusted, single source of truth for the call detail records generated by the participating carriers, which eliminates the root cause of data mismatches and discrepancies.
The proposed solution focused on a set of core functionality that allows carriers to reduce friction, time, and costs while maintaining autonomy, integrity, privacy, and control over their own data. The level of details discussed in the paper is sufficient for implementing a Minimum Viable Product (MVP) to demonstrate the core promises of the solution— simplifying and expediting the cross-charging and billing data-verification process across multiple carriers.
Our objective is to form a global consortium representing network operators, billing and settlement vendors, technologists, and industry forum to realize the proposed solution. We would like to showcase the solution at the global stage for the sake of improving and maturing it to a commercial-grade level ready for adoption by carriers worldwide.

Acknowledgements

Last Name	First Name	Company	Company URL	Contact Email
Gunasekaran	Shyam Prabhu	Subex Ltd.	www.subex.com	shyam.prabhu@subex.com
Muscara	Barbara	Ledger Academy	www.ledgeracademy.com	Bobbi@LedgerAcademy.com
Rathi	Vipin	DU		vipin68_scs@jnu.ac.in
Saleh	Bilal	Pacioli Consulting	https://pacioli.us	bilal@pacioli.us
Singh	Amandeep	IBM	www.ibm.com	singham@us.ibm.com
Thomas	Mathews	IBM	www.ibm.com	matthom@us.ibm.com
Zanotto	Paulo	Subex Ltd.	www.subex.com	paulo.zanotto@subex.com
Zelawat	Sunay	Subex Ltd.	www.subex.com	sunay.zelawat@subex.com
Nima	Afraz	CONNECT Centre	https://connectcentre.ie/	nafraz@tcd.ie
Chaudhary	Vinay	NIC		vcteotia@gmail.com

10. Annex A – Hyperledger Frameworks

As shown in Table 1, different Hyperledger frameworks have different purposes. You can see more about each relevant framework in the section below.
FRAMEWORK
BRIEF DESCRIPTION
SEE ALSO
HHYPERLEDGER FABRIC
Hyperledger Fabric is a blockchain framework implementation and one of the Hyperledger projects hosted by The Linux Foundation. Intended as a foundation for developing applications or solutions with a modular architecture, Hyperledger Fabric allows components, such as consensus and membership services, to be plug-and-play.
Hyperledger Fabric leverages container technology to host smart contracts called “chaincode” that comprise the application logic of the system.
Hyperledger Fabric was initially contributed by Digital Asset and IBM, as a result of the first hackathon.

6.2
Table 1: Summary of Hyperledger Frameworks

Browser not supported