Log In Sign Up

BEAT: Blockchain-Enabled Accountable and Transparent Network Sharing in 6G

by   Tooba Faisal, et al.

Infrastructure sharing is a widely discussed and implemented approach and is successfully adopted in telecommunications networks today. In practice, it is implemented through prior negotiated Service Level Agreements (SLAs) between the parties involved. However, it is recognised that these agreements are difficult to negotiate, monitor and enforce. For future 6G networks, resource and infrastructure sharing is expected to play an even greater role. It will be a crucial technique for reducing overall infrastructure costs and increasing operational efficiencies for operators. More efficient SLA mechanisms are thus crucial to the success of future networks. In this work, we present "BEAT", an automated, transparent and accountable end-to-end architecture for network sharing based on blockchain and smart contracts. This work focuses on a particular type of blockchain, Permissioned Distributed Ledger (PDL), due to its permissioned nature allowing for industry-compliant SLAs with stringent governance. Our architecture can be implemented with minimal hardware changes and with minimal overheads.


BEAT: Blockchain-Enabled Accountable Infrastructure Sharing in 6G and Beyond

It is widely expected that future networks of 6G and beyond will deliver...

On the Performance of Blockchain-enabled RAN-as-a-service in Beyond 5G Networks

Blockchain (BC) technology can revolutionize the future of communication...

Blockchain-enabled Network Sharing for O-RAN

The innovation provided by network virtualization in 5G, together with s...

BlockPKI: An Automated, Resilient, and Transparent Public-Key Infrastructure

This paper describes BlockPKI, a blockchain-based public-key infrastruct...

Fair and Transparent Blockchain based Tendering Framework - A Step Towards Open Governance

Society is in constant transition to keep up with technological advancem...

Blockchain-based Covid Vaccination Registration and Monitoring

Covid-19 (SARS-CoV-2) has changed almost all the aspects of our living. ...

I Introduction

The deployment of 5G is well under way, but it is proving to be fairly challenging [7]. Notably, with the yearly costs for 5G on operators expected to reach $87.9 billion by 2023 [8], challenges regarding site availability, acquisition and installation of the state-of-the-art equipment are proving to be a hindrance in the wide adoption of 5G services. This calls for radical changes in the way that current network infrastructure is managed from a deployment and operational point of view. With the main 3GPP 5G standard frozen with Release 16, there are opportunities to shape R17, R18 and subsequent 6G standards.

Any realistic review of infrastructure management that can handle 6G and beyond technologies needs to be comprehensive in scope and strike a balance between the often competing variables of greater network capacity, lower operating costs and innovative business models for revenue generation. The experience of the 5G infrastructure rollout by the Mobile Service Providers (MSPs) provides a valuable base from which to start. Firstly, we note that 5G operates at very high-frequency bands (i.e., 24 - 100 GHz), which allows operators to offer low latency services. The downside is that more cells are needed in order to continue to provide the same areal coverage as LTE. This translates into additional costs for the deployment of new cells, site acquisition and related infrastructure such as transmission lines. Given this context, the pooling of resources and network sharing between MSPs is an obvious way to reduce both CAPEX and OPEX.

Indeed, we have already witnessed, for instance, the recent merger between Virgin Media and O2 [3], which will make Virgin Media one of the biggest provider and the planned masts’ sharing between O2, Three and Vodafone to boost the rural coverage [15]. Clearly, such resource sharing agreements are already part of MSPs’ operating practices; however, we note that typically such arrangements involve only a limited number of infrastructure providers bound by a long-term contract model. As 5G transitions inevitably towards 6G, similar agreements are likely to become both more compelling and common.

Indeed, and secondly, 5G inherently enables a multi-vendor environment such as OpenRAN, in which several vendors provide equipment for a single infrastructure. This is quite useful for several reasons, and particularly so with regards to infrastructure scaling without reliance on a single vendor. However, a multi-vendor environment imposes accountability and transparency requirements on equipment usage. From an accountability point of view, if a device malfunctions, network operators should be able to identify precisely the device which failed to meet its quality standards. Transparency, on the other hand, is essential because some dishonest vendors may try to hide their errors and blame others, to save themselves from having to pay a penalty [14].

Network sharing mechanisms proposed by the research community tend to majorly focus on the efficiency of resource sharing issues, either introducing another centralised entity or by the way of other network management techniques [4, 12]. They generally lack the ability to provide transparency and accountability, which we believe to be a significant oversight. A natively transparent, monitorable and accountable resource and infrastructure sharing architecture is essential for next generation systems.

To this end, this paper introduces our proposed solution to aforementioned problems and outlines a viable way forward for the industry. We introduce a blockchain-based end-to-end architecture for accountable and transparent (BEAT) sharing of network resources through smart contracts residing on Permissioned Distributed Ledgers (PDLs). PDLs are a particular type of distributed ledger that work between a closed group of mutually non-trusted parties. Access is managed via stringent access control mechanisms; i.e. only authorised members can access a PDL, making them ideal for business-like applications. Furthermore, PDLs are immutable and contain executable smart contract code which gets deployed and executed on the ledger.

The required SLAs are installed as smart contracts on a PDL whilst the PDL nodes themselves are installed on the network devices, either baremetal or in a virtualized environment. They record the infrastructure usage by monitoring APIs, packet flows, etc; and by recording the relevant data to the PDL. The high degree of automation in this design can cope with surges in demands for network services and makes the infrastructure sharing plug-and-play without a long contractual process.

The rest of the paper is organized as follows. A review of existing and related work is conducted in Section II. In Section III, we present ”BEAT”, our blockchain-based end-to-end architecture. We then evaluate our work in Section IV by addressing the questions of the resource and performance overhead of PDLs. The paper ends with the concluding remarks of Section VI.

Ii Related Work

The use of blockchain-based distributed ledger technologies for network resource sharing is an emerging area of research that has been considered by several works recently. We restrict our discussion here to those results that are most closely related to our own efforts, and in particular, focus on resource sharing with distributed ledger and smart contract technologies.

A transparent on-the-fly Software Defined Network (SDN) based technique for radio resource sharing architecture is proposed by [9]. In this work, a customer can connect to any available operator where the resources are available and is dependent on a third-party entity (essentially an SDN-Server) — which keeps track of available resources throughout the participating service providers. However, this work is limited to resource provisioning and neither discuss the prospects of low-level (i.e., switch level) sharing nor accountability due to SLA violation.

Another Distributed Ledger Technology (DLT)-focused resource reservation work is Blockchain Network Slice Broker [2] and based on [12]. In that work, tenants (such as Over-the-Top providers) can request network services from the Mobile Network Operators (MNOs) on-the-fly. The SLAs for the allocation is recorded to a distributed ledger through smart contracts. However, the actual resource usage at a device is not recorded, and the problem of accountability in network sharing is not addressed.

Another inter-operator network sharing architecture, specifically for smaller/denser cells, is proposed in [10]. The network sharing SLAs between MNOs are stored as smart contracts on a distributed ledger and executed with service requests through an SDN layer. This work focuses on recording and executing network sharing contracts only and ignores accountability at the device level.

A more ambitious approach, involving the prospect of Distributed Applications (DApps) and smart contracts, particularly in the context of Multi-domain Orchestration operations such as asset sharing and monitoring, is discussed in [11]. Whilst this work does consider the possible applications of DApps in standardized architectures, it neither addresses accountability nor evaluates the overheads introduced by way of the smart contracts and DApps.

Iii Proposed System Architecture

Fig. 1: Network resource sharing architecture

BEAT is an automated architectural solution with three key elements: (1) Resource sharing with (2) Distributed Ledgers and Smart contracts that enable (3) Accountability and Transparency. These objectives are achieved through PDLs and smart contracts. In this section, we explain the BEAT architecture in detail.

Iii-a BEAT’s Architecture

The architecture is underpinned by the following actors:

Network Users: They can be 1) Network Owners – the party who own the infrastructure, or 2) Network Tenants – the party who lease the infrastructure from network owners, or 3) both – own some of the network infrastructure, which other tenants can lease. Moreover, they also lease/rent some network infrastructure from the owners to serve their customers.

Governance: The network governance is the consortium of the network owners and include representatives of the operators. It is up to the network owners to decide the strategy (e.g., through voting) by which governance representatives are chosen.

Illustrated in Figure 1, BEAT’s architecture has three main operational layers: 1) an Orchestration Layer, 2) Network Layer, and 3) a PDL Layer. These are now discussed in subsequent sections.

Iii-B Orchestration Layer

The Orchestration Layer is the top layer and handles the network resource requests from the tenants. Its operations are similar to ETSI’s Management And Orchestration Layer (MANO). This layer is maintained and managed by the governance of the PDL. It oversees the network operations and allocation decisions such as setting up network access, lease duration, price and privileges. Shown in Figure 2, the Orchestration Layer has three main components:

Fig. 2: BEAT Orchestration Process

1) Orchestration Manager: It serves the incoming requests and has features such as Universal View similar to the Software-Defined Mobile Network Orchestrator (SDM-O) discussed in [4] and the SDN-Server of [9]. When a network participant joins the network, the Orchestration Manager assigns the credentials and keeps the record. The Orchestration Manager also allocates a node PDL-ID to a device. This PDL-ID is different from the Layer 2/3 addresses because the devices may change their IP addresses anytime and the PDL-ID must remain same.

2) Access Control: An access control verification entity which maintains a database to keep the record of credentials and replies to access control confirmation queries from the Orchestration Manager.

3) Network Log: A database to maintain network resource logs.

Iii-C Network and PDL Layers

Infrastructure and network resources, such as switches and routers, form the Network Layer of BEAT; it is managed and maintained by its Orchestration Layer. Network devices have a maximum threshold capacity to forward network traffic while maintaining agreed service levels. Beyond these limits, service quality gets affected. Therefore, network access must be monitored and controlled.

When the tenants request network resources, the Orchestration Manager will verify from the access control entity if the tenant has an agreement already. If the agreement is present, the Orchestration Manager will then check from the Network Log the status of the network, that is, the current load on each path of the network and on each device. If the network has resources available, the Orchestration Manager will send a confirmation message to the tenant. Next, a smart contract will be executed to initialize the SLA and then orchestrate the network resource for the tenant.

If the capacity is not available, the tenant can wait for the resources to become available.

BEAT advocates a multi-operator and multi-vendor environment. Therefore, stakeholders must know the performance and usage of the network components at a very fine-grained level. Such performance metrics are required for future SLA compliance and accountability of the sharing agreement.

The infrastructure usage in BEAT is recorded at device level and transparently shared with smart contracts at the PDL Layer. Every device in BEAT is equipped with a PDL node and can execute smart contracts to record relevant data to the PDL. At macro-level, all the devices together form a PDL within the network infrastructure.

Iii-D Automated Recording with Smart Contracts

A tenant’s main objective is to get agreed on service levels to serve its customers’ demands. Service quality can get affected for several reasons, such as a slower path or network device malfunctioning. In the situations of degraded service, the tenant should get compensation if applicable and without any hassle. In such cases, all the stakeholders (i.e., network operators and vendors) would blame each other to avoid paying the penalty. Therefore, there should be a mechanism to record the service data, which no party can deny.

In BEAT, the flows’ data is recorded to the PDL through smart contracts. For each flow, the source and the destination both records the relevant data to the PDL. PDLs are immutable, which means data recorded to them cannot be deleted. Moreover, PDLs are transparent, and all the participants for the consortium can see the flow source and destination information in the PDL. To resolve these two problems of scalability and privacy, we install minimum hashed data per flow to the PDL; specifically, node ID, source IP address, destination IP address and timestamp (i.e., ).

Fig. 3: The Packet Processor – records the packet data (i.e., node_ID, src_IP, dst_IP, timestamp) to the PDL node

Iii-E Trusted Execution Environments for Flow Monitoring

The data is recorded to the PDL by means of a smart contract that is executed by the Packet Processor – which is a software script that runs on a virtual machine within the PDL node adjacent to the device; see Figure 3. The packet processor extracts the data from the flow, hashes it and executes a smart contract to record the data to the PDL node. In BEAT, the owner has no control over this virtual machine – enabling secured and trustworthy data recording.

However, both the Packet Processor and the PDL node are installed on operator/vendor controlled devices, and the tenants may not trust them as owners could tamper with data. Some device owners may behave maliciously; for example, they may intentionally drop a packet and claim that the packet was sent from the source and was dropped in the network – it is difficult to dispute such claims due to the best-effort nature of today’s internet.

Therefore, BEAT adds another layer of security and wraps the Packet Processor and the PDL node inside a Trusted Execution Environment (TEE). It is to be noted here that TEE is a separate secure processing system that solves this trust issue. The governance can give the tenants controlled access to the virtual machine – this access is decided by the PDL voting mechanisms and will rotate among the tenants to enable trustworthy record keeping.

Iv Evaluating BEAT

(a) Hash time
(b) Packet Capture Time
(c) Contract Execution
Fig. 4: Evaluation results – Our results show that BEAT adds a negligible (less than 4 seconds) overhead altogether to data recording

The aim of our evaluation is to establish the overheads introduced by BEAT. To this end, we installed PDL nodes on every network device within the GNS3 simulated network infrastructure that formed an end-to-end PDL system.

We studied the compatibility between two independent systems, that is, the PDLs and the network infrastructure. We evaluated the viability of our proposal with a simple but similar real-world network topology [5] with two ISPs and an Edge Router connecting these two ISPs.

The idea of this study was to enable accountability with PDLs at the network layer - therefore, we installed one Ethereum node on each of the three edge routers. We advocated the use of Permissioned Ledger – hence we adopted Ethereum’s permissioned version with Proof-of-Authority (PoA) consensus protocol; more specifically, the “Clinque” implementation of PoA which has higher throughput and lower latency than traditional Proof-of-Work protocol [13] and blocks can be generated at a user-defined time interval. Clinque also outperforms its other PoA counterparts and requires less message exchanges and hence delivers high throughput as compared to other permissioned flavours of Ethereum such as Aura [1].

We set up our simulations on an Intel Core i7 CPU 2.70 GHz with 16 GB RAM; with GNS3 network simulator. The packet processor shown in Figure 3 is coded with Python 3 and installed on a virtual machine with the PDL node. The blocks for the PDL are generated at 15 seconds intervals. The smart contract to record the usage is coded in Solidity and installed on the ledger.

The Packet Processor processes the flow data, that is, node ID, source IP address, destination IP address and timestamp. to In our simulations, it took mean 5.58 ms (Figure 4(b)). The Packet Processor then, hashes this data and records it to the PDL through smart contract execution. We advocate the use of plug-able hashing algorithm – that is, the governance of the PDL has the liberty to choose their preferred algorithm based on their priorities, such as the availability of computational power.

In this work, however, we chose the 32-byte version of SHA3, that is, SHA3-256. In our experiments, it took 0.05 ms to hash the 54 to 71 bytes processed data; (see Figure 4(a)). The next step was to install this hashed data to the PDL; this was done through a pre-installed smart contract execution and took an average of approximately 1 second; see Figure 4(c).

With these experiments, we observe that BEAT’s additional overhead is less than 4 seconds. This means that our automated, transparent and accountable sharing mechanism results in negligibly small additional processing times for the stakeholders and, most importantly, with minimal hardware changes.

V Considerations

Designing a system with PDLs is not trivial. They have several considerations, such as transaction throughput and scalability.  In this section, we discuss the considerations related to the BEAT.

Integrity of Data

Smart contracts do not have any built-in means to verify the integrity of the data. Hence, it is vital to ensure that the data recorded by network devices is valid. In BEAT, the integrity of data is ensured with TEE (Section III-E). However, if a network device is malicious and somehow tamper the data before the packet processor (Figure 3) captures it, it can be a problem. This is one of the reasons we advocated the use of governance-controlled Permissioned Distributed Ledgers. Other stakeholders or affected parties can report such misbehaviour to the governance, which can take subsequently disciplinary actions and blacklist the node and may impose penalties.

Colluding MSPs

In a Blockchain-enabled architecture like BEAT, the MSPs can collude with each other. In such a case, dominant MSPs can behave maliciously towards other tenants such as reject their transactions. To solve such problems, regulatory authority (e.g. Ofcom in the UK and Federal Communications Commission (FCC) in the US) can also be the part of the PDL network governance. However, the role for the regulatory authority should be limited to “monitoring” only and they don’t control any switch or routers.

Denial-Of-Service (DoS)

Every PDL allows a particular number of Transactions Per Second (TPS), which are generally higher in PDLs (e.g., 20,000 TPS [6]) than permissionless ledgers (e.g., Bitcoin 5 TPS and Ethereum 10 TPS). This means that if many devices send data simultaneously, it can cause congestion at the ledger or DoS for incoming transactions. Therefore, whilst designing a PDL network, it is important to adopt a PDL-type (e.g., Hyperledger Fabric), which can cope with the network’s requirement.

Routers’ Fraud

Routers are vendor or operator-controlled devices, and may send the users’ data to a slower and cheaper path rather than a faster and agreed path. In BEAT, we proposed to record the data on the source and the destination device only to solve the scalability and congestion problems. Note that BEAT records the timestamp

for each flow, both at the source and the destination. This means, the latency-focused SLA can be estimated with this information (e.g.

- ).

However, it is also possible to record the complete path of the packet with BEAT and record the data on every device if scalability and congestion of the PDL is not a concern.

Vi Conclusion and Future Work

In this work, we presented “BEAT”, a PDL focused automated, transparent, accountable network sharing architecture operating at the network layer. In future generation networks, operators need to work collaboratively to broaden their coverage area and cope with the ever-increasing demands for network services. A key enabler for viable network sharing is accountability and transparency at every layer of the network sharing architecture – in this work, we focused on the network layer.

In BEAT, the SLAs between the stakeholders (e.g. vendors and network operators) are recorded as smart contracts in a PDL. We introduced a layered architecture in which governance of the PDL manages and maintains the network resources with stringent access control and network management strategies.

BEAT adds a negligible overhead to the system. When considering the time and cost required for the negotiation of SLAs for infrastructure sharing. We believe our system provides a faster and more-seamlessly automated solution.

For now, the smart contracts are pre-defined; in our future work, we intend to explore the possibility of Intelligent Smart Contracts, which can adapt and change the parameters in line with changing traffic conditions. Also, in this work, we proposed BEAT functionality on a VM. However, in future, we envision network devices with built-in BEAT functions.

In conclusion, it is our hope that this work marks the inception of a new era of network sharing in which competing stakeholders can work efficiently and transparently.


  • [1] S. D. Angelis, L. Aniello, R. Baldoni, F. Lombardi, A. Margheri, and V. Sassone (2018) PBFT vs Proof-of-Authority: Applying the CAP Theorem to Permissioned Blockchain. In ITASEC, Cited by: §IV.
  • [2] J. Backman, S. Yrjölä, K. Valtanen, and O. Mämmelä (2017) Blockchain Network Slice Broker in 5G: Slice Leasing in Factory of the Future Use Case. pp. 1–8. Cited by: §II.
  • [3] BBC Virgin Media and O2 Blockbuster Merger Provisionally Approved. Note: on: 14 May 2021 Cited by: §I.
  • [4] M. R. Crippa, P. Arnold, V. Friderikos, B. Gajic, C. Guerrero, O. Holland, I. L. Pavon, V. Sciancalepore, D. von Hugo, S. Wong, et al. (2017) Resource Sharing for a 5G Multi-tenant and Multi-service Architecture. pp. 1–6. Cited by: §I, §III-B.
  • [5] GNS3 BGP Implementation. Note: on: 27 March 2021 Cited by: §IV.
  • [6] C. Gorenflo, S. Lee, L. Golab, and S. Keshav (2020) FastFabric: Scaling hyperledger fabric to 20,000 transactions per second. Int. J. Netw. Manag. 30 (5), pp. e2099. Cited by: §V.
  • [7] GSMA Infrastructure Sharing: An Overview. Note: on: 27 March 2021 Cited by: §I.
  • [8] Heavy Reading Mobile Operator 5G Capex Forecasts: 2018 - 2023. Note: on: 27 March 2021 Cited by: §I.
  • [9] M. Jiang, D. Xenakis, S. Costanzo, N. Passas, and T. Mahmoodi (2017) Radio Resource Sharing as a Service in 5G: A Software-Defined Networking Approach. Computer Communications 107, pp. 13–29. Cited by: §II, §III-B.
  • [10] A. Okon, N. Jagannath, I. Elgendi, J. M. Elmirghani, A. Jamalipour, and K. Munasinghe (2020) Blockchain-Enabled Multi-Operator Small Cell Network for Beyond 5G Systems. IEEE Network 34 (5), pp. 171–177. Cited by: §II.
  • [11] R. V. Rosa and C. E. Rothenberg (2018) Blockchain-Based Decentralized Applications for Multiple Administrative Domain Networking. IEEE Comms. St. Mag. 2 (3), pp. 29–37. Cited by: §II.
  • [12] K. Samdanis, X. Costa-Perez, and V. Sciancalepore (2016) From Network Sharing to Multi-Tenancy: The 5G Network Slice Broker. IEEE Comm. Mag. 54 (7), pp. 32–39. Cited by: §I, §II.
  • [13] P. K. Singh, R. Singh, S. K. Nandi, and S. Nandi (2019) Managing smart home appliances with proof of authority and blockchain. In I4CS, pp. 221–232. Cited by: §IV.
  • [14] P. K. Vairam, G. Mitra, V. Manoharan, C. Rebeiro, B. Ramamurthy, et al. (2019) Towards Measuring Quality of Service in Untrusted Multi-Vendor Service Function Chains: Balancing Security and Resource consumption. In IEEE INFOCOM, pp. 163–171. Cited by: §I.
  • [15] Vodafone UK News Centre O2, Three and Vodafone Agree New Deal to Enhance Rural Coverage. Note: on: 14 May 2021 Cited by: §I.