Part 1 of this series gave you an overview of some of the challenges facing telecommunications and media companies, and we presented high-level use cases of solutions built on blockchain that can be created to solve these challenges. Here in Part 2, we provide an overview of a blockchain platform architecture that’s relevant to a communications service provider (CSP) environment, take a deeper dive into some of the earlier use cases, and examine a specific solution that can help you understand how all of the key components come together to provide tangible benefits to the CSP.

Architecture overview

This section provides a high-level overview of the blockchain reference architecture, as well as a sample implementation of the architecture for specific use cases.

Figure 1. Overview of the blockchain platform architecture

Figure 1. Overview of the blockchain platform architecture

The key elements of the platform:

  • Infrastructure layer — Provides the underlying infrastructure for the platform
  • Data layer — Storage for the associated data
  • Middleware layer — The middleware required to execute required business processes within the enterprise or across participants
  • Application layer — The applications needed for the different business processes; blockchain runs in this layer
  • Interaction layer — User interactions that execute the required business processes using the layers listed above
  • Integration layer — Integrates core systems with enterprise and third-party systems
  • Enterprise and third-party systems — External systems that interact with core systems, including blockchain
  • Security and governance layer — Provides core governance, security, and other services to ensure that all systems within the platform are functioning correctly

Figure 2 provides additional technical details on the architecture for each of these layers.

Figure 2. Architecture details

Figure 2. Architecture details

Here are some key points to consider when defining the blockchain architecture specifically for CSPs:

  • Determine the nature of the participation — Will the member participate directly in the network or indirectly through the reuse of peers and certificate authorities hosted by the master organization? The relationship among members, costs, and involvement desired by members are key factors in determining the level of participation.
  • Determine the tooling needed to develop blockchain solutions — Should you use SDK or other options? Carefully determine the tooling you will use as this could have a big impact on development.
  • Enterprise application integration — One option is to develop integration using the Hyperledger Fabric APIs. Client applications invoke blockchain transactions by invoking the REST APIs running in Node.js or Java™ application servers. Another option is to provide support for multiple integration patterns where processing logic is needed; in this case, an integration hub such as IBM Integration Bus can be used. The first option limits integration but the second option can become quite complex.
  • Design smart contracts for flexibility, evolution, and governance — You can encapsulate decision logic in smart contract code, or smart contracts can externalize decision logic to an external rules engine such as IBM Operational Decision Manager.
  • On-chain vs. off-chain data — With the on-chain approach, the data is stored directly on the ledger; the member organization is a direct participant in the network. With the off-chain approach, the data is stored off chain in a shared store such as an object store.

Figure 3. Reference architecture – simple implementation

Figure 3. Reference architecture – simple implementation

The key components of a simple blockchain implementation:

  • Public network — The external entities that interact with the blockchain network
  • Cloud network — The cloud infrastructure that hosts typical services required for any application including security, portals to applications, and governance; the key component is the blockchain service, which consists of the following:
    • Blockchain admin and ops services — Provide the ability to create, chain, and monitor blockchain components
    • Membership — Manages identity and transaction certificates, and aspects of permissioned access
    • Consensus — Manages identity and transaction certificates, and aspects of permissioned access
    • Ledger — Manages identity and transaction certificates, and aspects of permissioned access
    • Events — Creates notification of significant operations on the blockchain — for example, a new block or notifications related to smart contracts; this does not include event distribution
    • Smart contracts — Executes agreed-to contracts between the different parties
  • Enterprise network — Entities from the enterprise that interact with the blockchain network

Use case 1: Roaming fraud and overage management

Two common problems with CSPs are fulfilling roaming contracts among CSPs and identifying fraud with subscriber authentication across roaming networks. CSPs can use blockchain to address these problems.

Solution overview

This solution includes smart contracts that govern the transactions between the CSP acting as home operator and roaming partners to track the activities of mobile users on the network:

  • Identity — The subscriber gets on the roaming partner’s network. The roaming partner determines that this is a visitor from the home operator. Authentication and registration decisions are then made based on the smart contract.
  • Billing — A call is initialized and recorded on the blockchain. The call ends, and the call duration is recorded on the blockchain. Based on the smart contract, the charges are set and payment is recorded from the home office to the roaming partner.
  • Fraud — A mobile user with duplicate Mobile Station International Subscriber Directory Number (MSISDN) to an existing registered one attempts to connect. Authentication fails and it is flagged for fraud.
  • Overage — Customer calls as the customer has not exceeded the plan quota. The customer is notified of exceeding or potentially exceeding the quota.

Business value

Some key business values of this solution include:

  • Automatically triggers and enforces a contract between the home operator and roaming partners
  • Enables near-instantaneous resolution of charges, eliminating costly third-party processes like clearinghouses
  • Equips a repository of verifiable transactions between operators to resolve disputes
  • Uses effective identity management across CSPs to mitigate roaming and subscription fraud
  • Uses real-time alerting of overage issues of data/calls between parties, resulting in increased customer satisfaction

Figure 4 illustrates the high-level architecture for this solution.

Figure 4. Solution architecture

Figure 4. Roaming fraud and overage management solution architecture

The following is a high-level overview of how the key players interact with each other using blockchain:

  • When a subscriber arrives in Spain from the Unites States, she connects to a local operator (roaming partner).
  • The roaming partner discovers the subscribers and creates the following blocks:
    • Discovery
    • Authentication
    • Registration
    • Rate type
  • The blocks are created according to the shared business rules, and the home operator has access to them.
  • The subscriber is now a roaming subscriber.
  • In this capacity, she can make the call.
  • The roaming partner records the call duration and charges the home operator accordingly.
  • The home operator charges the roaming subscribers.
  • By using the same data and business rules, they leave no opportunity for disputes.

Use case 2: Mobile number portability

Two other common challenges for CSPs are seamlessly porting numbers across multiple carriers and conforming to regulatory requirements. And again, blockchain can be used by CSPs to address these problems.

Solution overview

This solution includes smart contracts that govern the transactions among users, the donor CSP, and the recipient CSP in the mobile number portability scenario. The solution gives the regulator visibility into the process. The smart contract applies the rules and parameters set in each market by the regulator:

  • Porting request — The user is able to place the request online.
  • Eligibility — Portability eligibility is evaluated in the blockchain by the smart contract following the regulator’s parameters.
  • Approval — Before the portability process is completed, the donor CSP and the recipient CSP need to approve the transaction and the user needs to confirm the new plan.
  • Regulator view — The solution provides the regulator with a complete view of the status of the portability process.
  • Dashboard — The CSPs and the regulator have access to a customized analytics dashboard that summarizes the portability trends and root causes of portability.

Business value

This solution provides key business values to the various players, including:

  • Regulator:

    • Faster end-to-end process cycle
    • Increased customer satisfaction thanks to higher transparency
    • Improved transparency among players enables the regulator to easily validate that the porting request was a valid request
  • CSP:

    • Reduces process times with access to accurate information
    • Reduces costs by minimizing information handoffs
    • Reduces risk by streamlining error-prone steps
  • Customer:

    • Increased efficiency and transparency
    • Faster migration

Figure 5 is a high-level architecture of the solution.

Figure 5. Mobile number portability solution architecture

Figure 5. Solution architecture

The following is a high-level overview of how the key players interact with each other using blockchain:

  • The subscriber who wants to port the number accesses the customer portal and verifies eligibility to the port number.
  • If eligible, the subscriber submits a request to a recipient operator.
  • The donor CSP sees the portability request on its system that feeds into the blockchain and approves it according to the smart contract.
  • The recipient CSP receives a request that is:
    1. eligible
    2. approved by the donor
  • The recipient CSP can now accept the mobile number portability request and also upsell a different plan.
  • The user can accept the new plan.
  • The regulator has full visibility into the process from end to end.

Use case 3: A deeper dive into blockchain for ad sales

Solution overview

This solution uses IBM Blockchain to enhance and streamline the business process of advertising sales for linear TV broadcasting. It demonstrates how blockchain can promote trust and remove friction throughout the supply chain. The demo focuses on the following scenario:

  • The broadcaster releases an inventory of ad spots for purchase (also known as “up fronts” or “bulk releases”).
  • Ad agencies buy and manage ad spots on behalf of advertisers.
  • Campaigns are assigned to specific ad spots.
  • The broadcaster reports which advertisements aired successfully and determines whether contract terms and conditions (such as target demographics) have been met.
  • All parties can trace the transaction history regarding ad spots.

The traditional ad sales process shown in Figure 6 is complex and involves multiple players who have their own systems of record.

Figure 6. Traditional ad sales process

Figure 6. Traditional ad sales process

With blockchain, the new process looks like Figure 7.

Figure 7. Blockchain-based ad sales process

Figure 7. Blockchain-based ad sales process

  • Each player owns a copy of the shared ledger and has a customized filter of the data available for visualization.
  • Data is consistent across the network and is based on shared and approved business rules included in the smart contract.
  • When change happens during the process, a new block is created to record the change and reflect it in the dependent steps of the process, eliminating the need for reconciliation later on.
  • The solution covers an ecosystem of 3 players — advertiser, ad agency, and broadcaster.

The scenario shown in Figure 8 illustrates how the process flows between different participants that are managed through a blockchain smart contract.

Figure 8. Blockchain smart contract process flow

Figure 8. Blockchain smart contract process flow

  • Emily from the broadcaster shares an unforeseen change with all the relevant players in real time.
  • Josh from the ad agency approves the change.
  • The shared ledger is updated only after Josh’s consensus is confirmed.
  • Any dependent information (such as billing reports) is updated according to the validated change and the smart contract.
  • Emily does not need to explain the change as it is stored in the blockchain.
  • When Josh receives the invoice, he is already aware of the changes and does not need to start a claim process.

Developing this solution requires several components, including blockchain, a UI, and integration with various back-end systems. What follows is a brief overview of the UI and blockchain components.

Figure 9 is the view of the UI for this blockchain solution.

Figure 9. Blockchain solution user interface

Figure 9. Blockchain solution user interface

It shows different views for the various participants: The advertisers are Big Blue Television (broadcaster), GSC Advertising Co. (ad agency), AMS Motor Co., and Netherlands Brewing Co.

The block diagram shows the simulation of information flow and consensus between the participants and the shared ledger when any transaction is triggered.

In Figure 9, the broadcaster Big Blue Television has released an inventory for TV ad spots available for advertising agencies to buy. You can see a list of programs whose ads may be sold. The UI uses REST APIs from Hyperledger’s REST server to get data and trigger transactions to the blockchain chaincode. All the transactions are governed by the rules in the blockchain smart contract and are immutable once they are finalized after consensus from all participants.

The underlying blockchain model is used with the following asset, participants, and transactions:

  • Asset:
    • AdSpot — Object for the advertisement spot made available by the broadcaster
  • Participants:
    • Broadcaster
    • AdAgency
    • Advertiser
  • Transactions:
    • ReleaseInventory — Broadcaster releases the inventory of ad spots
    • PlaceOrders — Advertising agency places an order for the ad spots on behalf of advertisers assigning adspotID, orderNumber, advertiserID, adContractID, and numberofSpots
    • MapAdspots — Advertising agency assigns campaign names for ad spots purchased by advertisers
    • ReportAsRun — Broadcaster reports true-ups, what actually aired or not, makeups included

As an example of a transaction trigger and flow, here’s what happens after the broadcaster releases its ad inventory:

  1. The ad agency places an order to buy ad spots and the UI uses the REST API to trigger the transaction on the blockchain.
  2. The API invokes the corresponding function in the smart contract script.
  3. The response is sent and the new data is made available on the UI via the REST API.

Conclusion

We have provided a high-level blockchain platform architecture, expanded on a few use cases from Part 1, and taken a deeper dive into a specific solution to give you a better understanding of how TME solutions can be built on blockchain. In our next article, we will build on this work to show how different external components can be integrated into the platform architecture so that an end-to-end solution can be built using blockchain.