Content uploaded by Nima Afraz
Author content
All content in this area was uploaded by Nima Afraz on Apr 20, 2020
Content may be subject to copyright.
5G Network Slice Brokering: A Distributed
Blockchain-based Market
Nima Afraz and Marco Ruffini
CONNECT CENTRE
The University of Dublin, Trinity College, Ireland
{naf raz, marco.ruf f ini}@tcd.ie
Abstract—In this paper, we study the business ecosystem
around 5G network slice brokering, where a dynamic mechanism
conducts multiple trades among resource providers and the
network operators, to dynamically provision slices (e.g., in the
order of minutes). Then we address a significant and realistic
scenario, where there is a lack of trust between market players.
This typically occurs when the central slice broker has conflicting
interests (e.g., being simultaneously infrastructure provider and
virtual operator). We propose a distributed market design, lever-
aging smart contracts technology, where the brokering mecha-
nism is operated and validated by all of the parties involved. In
addition, we use blockchain technology to enable a manipulation-
proof record-keeping system, where a record is accepted into the
ledger only when all the parties have reached a consensus to do
so. We deploy a realistic blockchain application/network hosted
on the cloud-based Hyperledger Fabric framework. Finally,
we investigate the performance of the blockchain-based slice
brokering market in terms of transaction latency, throughput
and computing intensity. Our results show that the proposed
market could support 100 auction transactions per second with
a latency below one second, which would add no considerable
delay even to a highly dynamic slicing market mechanism.
Index Terms—Blockchain, Slice Brokering, Network Slicing,
Smart Contract, Telecommunications Operators, Virtual Net-
work Operators.
I. INTRODUCTION
What differentiates 5G from its predecessor generations
of wireless communication is that it goes beyond merely
multiplying the network capacity and speed and promises an
ambitious vision where various services with vastly different
functional requirements are seamlessly hosted over the same
physical infrastructure without affecting each others’ perfor-
mance [1]. This vision, in addition to the many technical
and standardization challenges that need to be addressed,
demands a new approach to business and ownership models
of network infrastructure [2], where automated resource or-
chestration and provisioning mechanisms handle on-demand
resource needs of the operators. The most prominent model
of resource allocation for 5G networks is slicing, which allows
building customizable logical networks on top of a shared
infrastructure [3]. Thanks to the virtualization technologies,
it is now possible to allocate virtual instances of the physi-
cal infrastructure while assuring seamless functionality using
slice isolation techniques. As envisioned by 3rd Generation
Partnership Project (3GPP) [4] in a highly heterogeneous
network sharing ecosystem, network slices could be created
to accommodate different functional and performance require-
ments of the network operators. This vision could see the
emergence of a new market where a wide range of network
operators, infrastructure providers or public authorities carry
out highly frequent transactions involving the exchange of
resources, financial commitments and post-deal operations.
In other words, the conventional manual processing of these
transactions is not feasible; therefore, novel automated pro-
cess management methods have to replace them. The new
automated process management has to enable flexible resource
provisioning for key players of this market and accommodate
their quantitative and qualitative expectations from the network
resources dedicated to them.
Typical business processes in the communications industry
include economic models (e.g., auctions) that aim to solve
resource management problems using pricing and allocation
mechanisms [5]. The main objective of these mechanisms,
including the slice brokering [6] is to efficiently allocate the
available resources to the parties with the most critical demand
while assuring the manipulation-proofness of the scheme.
Nonetheless, the common assumption in these studies is the
existence of an impartial central authority who could be trusted
to conduct the market operations and execute the business
processes without manipulating the outcome to its or another
party’s benefit. We will challenge this assumption throughout
this paper and will illustrate how blockchain technology, along
with smart contracts, could provide a distributed alternative
to the conventional centralized approach to slice brokering.
Blockchain technology has already proven to provide solutions
for similar problems in various trust-less industrial ecosystems
such as healthcare [7], manufacturing [8], banking [9], etc.
To the best of our knowledge, this paper presents the
first pragmatic implementation of a blockchain application for
network slice brokering where the blockchain network is dis-
tributed on a commercial cloud environment and depicts real-
istic network/system-level Key performance indicators (KPIs)
such as latency, throughput and computing resources. These
realistic performance indicators are critical for providing a
practical feasibility analysis of the proposed distributed slice
brokering market.
II. 5G SLI CE BRO KE RI NG
Network slicing provides a solution to the diverse infras-
tructure/resource requirements of modern telecommunication
MVNO1
OTT1
InP1
MVNOs OTTs InPs Slice
Broker
RAN
Virtualized Resource/Infrastructure
Computing
Storage
Auction
Mechanism
Slice1
Slice2
Slice3
Orchestrator
Peer.VNO1
Peer.VNO2
Peer.VNO3
Peer.VNO4
Peer.VNO5
Ordering
Service
Client
Transaction
Proposals
Endorsement
(Auction Smart Contract)
Submitting
Transactions
Raft Consensus Protocol and Block Creation
Block
Verification-Commit
Block
#1
Block
#2
Block
#n
Block
#3
Endorsement
Response
Fig. 1: The Distributed Slice Broker Model
networks. This is done through generating on-demand virtual
instances of an end-to-end network on a physical infrastructure
[10]. This enables service providers to serve their end-users
with utmost flexibility.
In [11], the authors have reviewed the business requirements
and standards in the context of multi-tenant mobile networks.
They have introduced in detail the architecture of the 5G
network slice broker. The idea of the on-demand capacity
broker is to enable the sharing of a portion of network capacity
for a specific time slot to a secondary resource user (Mobile
Virtual Network Operator (MVNO) or Over-the-Top (OTT)
provider).
For the purpose of this paper, a network slice is considered a
complex commodity comprised of various resources required
for providing services over a network. This commodity (net-
work slice) is traded in a market in the form of leasing
(temporary ownership) for a particular time-slot with pre-
negotiated quantitative measures. The key factors in defining
a network slice are:
•The composition of the slice (quantitative description of
the slice components, e.g., Radio Access Network (RAN),
computing, and storage)
•The time duration of the leasing.
•The metrics that determine the expected performance
of the slice (e.g., availability, Quality of Service (QoS)
usually in the form of a Service Level Agreement (SLA)).
Considering the above definition, a network slice can be
treated as a commodity with a typical supply-chain which
has to be sourced from multiple suppliers (the infrastructure
providerss (InPs) or other MVNOs who are willing to share
parts of their idle resources) and be delivered to an interme-
diary business customer who then would serve its end-users
using this network slice. Therefore the first function of the
network slicing supply chain is the sourcing of the slice, i.e.,
acquiring the required resources for creating a slice with a
particular configuration. From the slice requester’s perspective,
the aim is to acquire the slice with the necessary configuration
for the lowest price from the market. On the other hand, from
the suppliers’ (the InP or MVNOs with excess resources) point
of view, the optimal outcome is for the slice to be sold for the
highest possible price. Game theory has been widely used for
similar markets in communications research where multiple
players are involved on both sides of the market [12]. Among
the game theory based solutions, auctions, in particular, are
very popular as market resolution tools [5]. The resources that
are traded in these resource markets range from spatial streams
[13] to spectrum/antennas [14], and resource blocks [15]. More
specifically, we are interested in auction mechanisms that are
capable of handling multiple traders in both the selling and
buying sides of the market (depicted in Fig. 1).
In [16] the authors have proposed a flow-level slice bro-
kering using an iterative double auction with a transaction
cost. In their software defined networking (SDN)-based ar-
chitecture, the SDN controller acts as a broker and arranges
the double-sided auction. Using simulations, they demonstrate
the effectiveness and eventual convergence of their proposed
iterative auction algorithm. In [6], a double auction algorithm
is proposed to address the problems of service function chain
routing and Network Function Virtualization (NFV) price
adjustment. The NFV broker acts as the central auctioneer who
received the bids and ask prices from the customers/suppliers
and decides on the allocation and pricing of the resources.
A. Quality Assurance and Enforcement
A slice of the network comes with certain qualitative
guarantees, often in the form of a pre-negotiated SLA. The
SLA has to provide a detailed description of the expected
reliability, availability and other performance indicators of the
service and the actions to be taken in case of a party breaching
the agreement. The authors in [17] have introduced several
metrics regarding the slice-based network SLAs including
throughput, penalty, cost, revenue, profit, and QoS related
metrics. However, the enforcement of these SLAs remains
an open issue as no automated process has been proposed
to address the problem.
III. DISTRIBUTED 5G SLICE BRO KE RI NG
The slice brokering mechanisms have multiple placement
options (e.g., in the SDN controller [16] or the orchestrator
[11]). However, what is common with most of these proposals
is that the brokering mechanism is hosted by a single entity
who is not necessarily impartial and might have incentives to
manipulate the outcomes of the mechanism.
The authors in [18] have proposed a Blockchain-based
network slice broker for 5G services to secure and ensure
Swarm Manager Node
Docker
Engine
Benchmark
Engine
Resource
Monitoring
Swarm
Worker
Node1
CA1
Peer 1
Orderer 0
Cloud-Based
Linux Host
ORG 1
CA4
Peer 4
Orderer 3
ORG 4
CA2
Peer 2
Orderer 1
ORG 2
CA5
Peer 5
Orderer 4
ORG 5
Swarm
Worker
Node2
Swarm
Worker
Node4
Swarm
Worker
Node5
CA3
Peer 3
Orderer 2
ORG 3
Swarm Worker Node3
Swarm Manager Node VM1
Docker
Engine
Benchmark
Engine
Resource
Monitoring
Cloud-Based
Linux Host
Swarm
Worker
VM2
CA1
Peer 1
Orderer 0
ORG 1
CA2
Peer 2
Orderer 1
ORG 2
Swarm
Worker
VM3
CA4
Peer 4
Orderer 3
ORG 4
Swarm
Worker
VM5
CA5
Peer 5
Orderer 4
ORG 5
Swarm
Worker
VM6
CA3
Peer 3
Orderer 2
ORG 3
Swarm Worker VM4
Swarm Manager Node
Docker
Engine
Benchmark
Engine
Resource
Monitoring
Swarm
Worker
Node1
CA1
Peer 1
Orderer 0
Cloud-Based
Linux Host
ORG 1
CA4
Peer 4
Orderer 3
ORG 4
CA2
Peer 2
Orderer 1
ORG 2
CA5
Peer 5
Orderer 4
ORG 5
Swarm
Worker
Node2
Swarm
Worker
Node4
Swarm
Worker
Node5
CA3
Peer 3
Orderer 2
ORG 3
Swarm Worker Node3
Swarm Manager Node VM1
Docker
Engine
Benchmark
Engine
Resource
Monitoring
Cloud-Based
Linux Host
Swarm
Worker
VM2
CA1
Peer 1
Orderer 0
ORG 1
CA2
Peer 2
Orderer 1
ORG 2
Swarm
Worker
VM3
CA4
Peer 4
Orderer 3
ORG 4
Swarm
Worker
VM5
CA5
Peer 5
Orderer 4
ORG 5
Swarm
Worker
VM6
CA3
Peer 3
Orderer 2
ORG 3
Swarm Worker VM4
Fig. 2: The Experimental Setup: Blockchain Network Architecture
anonymous transactions using Blockchain. They have devel-
oped a proof of concept to evaluate the performance of their
proposed slice broker. Their proposed blockchain platform
is based on a consensus mechanism called Hashcash [19].
Their performance evaluation is, however, only limited to
comparing the average time of sub-slice contract creation and
slice deployment. They conclude that the additional security
and privacy provided by Blockchain does not have a significant
impact on the performance of the slice broker. Hashcash is a
public blockchain that uses a Proof of Work (PoW) based
consensus protocol which relies on the network nodes solving
computationally complex problems to reach consensus [20].
Although PoW consensus due to its pseudo-anonymous nature
could be the most robust and secure option for particular
applications (e.g., crypto-currencies), in enterprise ecosystems
such as telecoms, they appear to be redundant as the parties
involved in the Blockchain are already known to each other.
Therefore, permissioned blockchains that are designed for
enterprise ecosystems and use more straightforward and less
resource consuming consensus protocols such as Raft [21] are
considered a better fit. To address this, we propose a distributed
slice brokering model which allows two-sided trade of the
resources required to create a slice of the network. The traded
commodity in this market is either a unit-bundle of different
resource types (RAN, computing or storage) or a single type
multiple-unit of each resource type. In this paper, we imple-
ment a distributed smart contract which operates a sealed-
bid double auction mechanism (introduced in [22]) enabling
multiple traders in both sides (seller/buyer) of the market
to trade their resources (multiple items simultaneously). The
double auction smart contract assures manipulation-proofness
of the market by decoupling the ask/bid value proposed by the
traders from the final price paid; therefore, the traders cannot
manipulate the market by strategizing over their proposed
ask/bid value.
The transaction flow in our proposed distributed slice bro-
kering is depicted in Fig. 1. First, the transaction proposals
are sent to the blockchain peers. A transaction proposal
consists of a table of ask/bid values, and the quantity of avail-
able/demanded resources proposed by each Virtual Network
Operator (VNO) along with the proposed (unverified) outcome
of the double auction which determines the identity of the
winning traders and the quantity of trades. This process is
initiated inside the client application and then broadcast to
the peers of each blockchain member VNO. Once the peers
receive the transactions, they begin the endorsement process
by executing the chaincode, which contains an implementation
of the brokering auction mechanism. If the resource allocation
outcome resulting from the peer-run auction matches the
proposed outcome, they endorse the transaction by returning a
signed transaction. When enough number of endorsements is
reached (this number depends on the endorsement policy that
in our case is N-out-of-N, i.e., all the peers have to endorse),
the transactions are sent to the ordering Service, where the
consensus is reached (i.e., Raft in our case). The final block
is then created and committed to the ledger. Therefore, this
distributed process replaces the conventional centralized ap-
proach to slice brokering, where a single authority does not
control the entire conduct of the market.
IV. BLOCKCHAIN PERFORMANCE EVALUATION
The main objective of a blockchain application is to handle
a number of transactions that are submitted by the participants
and proceed to the verification and ordering process, leading
to the generation of a block and the transaction outcome
being written on the ledger. Therefore, the performance of a
blockchain application is measured by the following metrics:
•Transaction Throughput: The number of transactions that
the blockchain can process and write its outcome on the
distributed ledger in a given second.
•Transaction Latency: The amount of time that it takes for
a transaction from when it is invoked by the client until
it is written on the ledger.
•Computing Resources: The hardware and network infras-
tructure cost required for the operation of the blockchain.
A more in-depth study of the performance metrics and eval-
uation methods is presented by the Hyperledger Performance
and Scale Working Group [23], [24].
V. SY ST EM IMPLEMENTATION AND RES ULTS
We use the Hyperledger Fabric (version 1.4.1) framework
to implement our blockchain application which is a permis-
sioned open-source blockchain platform designed for enter-
prise ecosystems. To achieve realistic results, we deploy an
under-laying network of nodes hosted on a commercial cloud
provider’s infrastructure, similar to a real-world production
environment. The System Under Test (SUT) shown in Fig.
(a) Send Rate V. Latency (b) Send Rate V. Transaction Throughput
Fig. 3: Benchmark Results: Send Rate V. Latency and Transaction Throughput
2 consists of 6 Virtual Machine (VM) instances spread over
the cloud. VM1 (8 Virtual Central Processing Units (vCPUs)
Intel(R) Xeon(R) @ 2.30GHz and 32 GB memory) hosts
Hyperledger Caliper [25] which is a benchmark tool designed
to measure the performance of multiple blockchain solutions.
The blockchain network consists of 5 organizations, each host-
ing one instance of a peer, orderer, chaincode and certificate
authority. These blockchain components are each deployed as
a Docker container, and Docker Swarm is used to orchestrating
the containers that are distributed across the network of VMs.
VM1 is the Docker Swarm manager and is in charge of
composing and deploying the containers at the beginning of
the benchmark. VM2 - VM6 (4 vCPUs and 15 GB memory)
each host an organization and their containers. This provides
a realistic implementation, where different organizations run
their processing in different and independent virtual machines.
A. Experimental Results
The experiment consists of multiple rounds of benchmarks
with varying transaction send rates (from 20 to 110 trans-
actions per second (TPS)). For each benchmark, we gener-
ate 10,000 transactions (i.e., each transaction is one round
of double auction) and submit them to the blockchain to
measure the minimum, average and maximum transaction
latency and transaction throughput. In addition, to evaluate the
container-level computing and network resource utilization of
the blockchain application we use Prometheus [26], an open-
source monitoring system to record real-time metrics in a time-
series database and then visualize these metrics using Grafana
[27] visualization suite.
The minimum, average and maximum transaction latency
for each experiment is shown in Fig. 3a. The minimum and
average latency follow a semi-linear growth (with a different
slope) as the send rate increases. The average latency remains
below 1 second throughout the experiments. The maximum
latency, on the other hand, grows more rapidly compared to
the minimum and average latency and goes beyond 1 second
as the send rate reaches 50 TPS. In real-time applications,
the maximum latency is the bounding metric as it deter-
mines the feasibility of the application. The maximum latency,
however, can be controlled using transaction processing time-
outs, where necessary, and a default output for the transaction
is defined. Fig. 3b illustrates the transaction throughput of
the blockchain application based on varying send rate. The
throughput remains above 99.5% while the send rate is up to
100 TPS. However, a significant drop (down to 98.4%) in the
throughput is experienced as the send rate is raised to 110
TPS, showing we have reached the highest usable rate.
Throughout each experiment, 20 docker containers are cre-
ated and deployed on top of an overlay network to which all
the VMs are connected. To get a better insight into the resource
consumption of the slice brokering blockchain application, we
have produced Fig. 4, which depicts the container-specific
CPU, memory and network utilization throughout one instance
of the experiment. As previously mentioned, each component
of the blockchain is implemented as a Docker container. For
the purpose of clarity, Certificate Authority (CA) Containers
are intentionally omitted from the visualization as their re-
source consumption is negligible. Fig. 4a depicts the CPU
utilization of the containers. The Peer nodes (tasked with
the endorsement of the transactions) are using most CPU
resources. This is due to the fact that the verification of the
slice brokering smart contracts (auction) outcome is done by
the peers; hence, the high CPU usage.
The memory consumption is illustrated in Fig. 4b, where
the peer nodes are consuming the most memory, followed by
the orderers that also consume a considerable amount. Fig.
4c shows the sum of incoming and outgoing network traffic
to/from each container. As expected, the orderers occupy the
most significant part of the network due to the highly-frequent
signalling among the orderers to reach consensus.
VI. CONCLUSIONS
In this paper, we proposed a distributed market design for
5G network slice brokering based on blockchain technology.
We implemented a variant of the double auction mechanism
as a smart contract to assure trust in a telecoms business
ecosystem, where no trusted authority is available to control
the slice brokering market mechanism. We have deployed
a pragmatic network of blockchain nodes over six cloud-
700%
600%
500%
400%
300%
200%
100%
0%
Container Group All Interval a Node Ne
CPU Usage per Container
10:57:00 10:57:10 10:57:20 10:57:30 10:57:40 10:57:50 10:58:00 10:58:10 10:58:20 10:58:30 10:58:40 10:58:50 10:59:00 10:59:10 10:59:20 10:59:30 10:59:40 10:59:50 11:00:00 11:00:10 11:00:20 11:00:30 11:00:40 11:00:50 11:01:00
0%
100%
200%
300%
400%
500%
600%
700%
de-calie-ela-5g_ca_g1_eale_c.1.ek0e1ck447fkl7k
de-calie-ela-5g_ca_g2_eale_c.1.cdl2c7cble578383i
de-calie-ela-5g_ca_g3_eale_c.1.h8j1c7j6k1ed432ad
de-calie-ela-5g_ca_g4_eale_c.1.dekifkfk2ajbg12a6
de-calie-ela-5g_ca_g5_eale_c.1.dff375h884c878
de-calie-ela-5g_dee0_eale_c.1.826e5cab0e1kadd9c
de-calie-ela-5g_dee1_eale_c.1.h10bg0j31kli5
de-calie-ela-5g_dee2_ale_c.1.a2i3b9480hlc
de-calie-ela-5g_dee3_ale_c.1.5k6daij85jf9i5
de-calie-ela-5g_dee4_ale_c.1.5gk8c6h3kcfb474hbah
de-calie-ela-5g_ee0_g1_eale_c.1.e63fdhdjkaj72i185
de-calie-ela-5g_ee0_g2_eale_c.1.a0b568751c91ca1
de-calie-ela-5g_ee0_g3_eale_c.1.97c7j8if0iagc5jfb
de-calie-ela-5g_ee0_g4_eale_c.1.lf41h1f8c5eja
de-calie-ela-5g_ee0_g5_eale_c.1.0j07kfc109bdjf
de-ee0.g1.eale.c-ile-0
de-ee0.g2.eale.c-ile-0
de-ee0.g3.eale.c-ile-0
de-ee0.g4.eale.c-ile-0
de-ee0.g5.eale.c-ile-0
Nia' Dcke ad e iig 3
2019-10-23 10:56:58 to 2019-10-23 11:01:04
2019-10-23 10:56:58 to 2019-10-23 11:01:04
0 10 20 30 40 50 60 70 80 90
Time (s)
100 110 120 130 140 150 160 170 180 190 200 210 220 230 240
CPU Usage per Container (%)
Orderer0
Orderer1
Orderer2
Orderer3
Orderer4
ChainCode.Org1
ChainCode.Org2
ChainCode.Org3
ChainCode.Org4
ChainCode.Org5
Peer0.Org1
Peer0.Org2
Peer0.Org3
Peer0.Org4
Peer0.Org5
(a) Central Processing Unit (CPU) Utilization
Container Group A Interal a Node Ne
Memor Usage per Container
10:57:00 10:57:10 10:57:20 10:57:30 10:57:40 10:57:50 10:58:00 10:58:10 10:58:20 10:58:30 10:58:40 10:58:50 10:59:00 10:59:10 10:59:20 10:59:30 10:59:40 10:59:50 11:00:00 11:00:10 11:00:20 11:00:30 11:00:40 11:00:50 11:01:00
0 B
238.4186 MiB
476.8372 MiB
715.2557 MiB
953.6743 MiB
1.1641532 GiB
1.3969839 GiB
1.6298145 GiB
1.8626451 GiB
2.0954758 GiB
de-caie-ea-5g_ca_g1_eae_c.1.e0e1c447f7
de-caie-ea-5g_ca_g2_eae_c.1.cd2c7cbe578383i
de-caie-ea-5g_ca_g3_eae_c.1.h8j1c7j61ed432ad
de-caie-ea-5g_ca_g4_eae_c.1.deiff2ajbg12a6
de-caie-ea-5g_ca_g5_eae_c.1.dff375h884c878
de-caie-ea-5g_dee0_eae_c.1.826e5cab0e1add9c
de-caie-ea-5g_dee1_eae_c.1.h10bg0j31i5
de-caie-ea-5g_dee2_ae_c.1.a2i3b9480hc
de-caie-ea-5g_dee3_ae_c.1.56daij85jf9i5
de-caie-ea-5g_dee4_ae_c.1.5g8c6h3cfb474hbah
de-caie-ea-5g_ee0_g1_eae_c.1.e63fdhdjaj72i185
de-caie-ea-5g_ee0_g2_eae_c.1.a0b568751c91ca1
de-caie-ea-5g_ee0_g3_eae_c.1.97c7j8if0iagc5jfb
de-caie-ea-5g_ee0_g4_eae_c.1.f41h1f8c5eja
de-caie-ea-5g_ee0_g5_eae_c.1.0j07fc109bdjf
de-ee0.g1.eae.c-ie-0
de-ee0.g2.eae.c-ie-0
de-ee0.g3.eae.c-ie-0
de-ee0.g4.eae.c-ie-0
de-ee0.g5.eae.c-ie-0
Nia' Dce ad e iig 3
2019-10-23 10:56:58 to 2019-10-23 11:01:04
2019-10-23 10:56:58 to 2019-10-23 11:01:04
0 10 20 30 40 50 60 70 80 90
Time (s)
100 110 120 130 140 150 160 170 180 190 200 210 220 230 240
Memory Usage per Container (GiB)
2
1.8
1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
0
Orderer0
Orderer1
Orderer2
Orderer3
Orderer4
ChainCode.Org1
ChainCode.Org2
ChainCode.Org3
ChainCode.Org4
ChainCode.Org5
Peer0.Org1
Peer0.Org2
Peer0.Org3
Peer0.Org4
Peer0.Org5
(b) Memory Utilization
Container Group A Interval a Node Ne
Received Netork Trac per Container
10:57:00 10:57:10 10:57:20 10:57:30 10:57:40 10:57:50 10:58:00 10:58:10 10:58:20 10:58:30 10:58:40 10:58:50 10:59:00 10:59:10 10:59:20 10:59:30 10:59:40 10:59:50 11:00:00 11:00:10 11:00:20 11:00:30 11:00:40 11:00:50 11:01:00
0 B
2.5000 MB
5.0000 MB
7.5000 MB
10.0000 MB
12.5000 MB
15.0000 MB
17.5000 MB
20.0000 MB
22.5000 MB
de-caie-ea-5g_ca_g1_eae_c.1.ek0e1ck447fk7k
de-caie-ea-5g_ca_g2_eae_c.1.cd2c7cbe578383i
de-caie-ea-5g_ca_g3_eae_c.1.h8j1c7j6k1ed432ad
de-caie-ea-5g_ca_g4_eae_c.1.dekifkfk2ajbg12a6
de-caie-ea-5g_ca_g5_eae_c.1.dff375h884c878
de-caie-ea-5g_dee0_eae_c.1.826e5cab0e1kadd9c
de-caie-ea-5g_dee1_eae_c.1.h10bg0j31ki5
de-caie-ea-5g_dee2_ae_c.1.a2i3b9480hc
de-caie-ea-5g_dee3_ae_c.1.5k6daij85jf9i5
de-caie-ea-5g_dee4_ae_c.1.5gk8c6h3kcfb474hbah
de-caie-ea-5g_ee0_g1_eae_c.1.e63fdhdjkaj72i185
de-caie-ea-5g_ee0_g2_eae_c.1.a0b568751c91ca1
de-caie-ea-5g_ee0_g3_eae_c.1.97c7j8if0iagc5jfb
de-caie-ea-5g_ee0_g4_eae_c.1.f41h1f8c5eja
de-caie-ea-5g_ee0_g5_eae_c.1.0j07kfc109bdjf
de-ee0.g1.eae.c-ie-0
de-ee0.g2.eae.c-ie-0
de-ee0.g3.eae.c-ie-0
de-ee0.g4.eae.c-ie-0
de-ee0.g5.eae.c-ie-0
Nia' Dcke ad e iig 3
2019-10-23 10:56:58 to 2019-10-23 11:01:04
2019-10-23 10:56:58 to 2019-10-23 11:01:04
0 10 20 30 40 50 60 70 80 90
Time (s)
100 110 120 130 140 150 160 170 180 190 200 210 220 230 240
Network Trafic per Container(MBs)
22.5
20
17.5
15
12.5
10
7.5
5
2.5
0
Orderer0
Orderer1
Orderer2
Orderer3
Orderer4
ChainCode.Org1
ChainCode.Org2
ChainCode.Org3
ChainCode.Org4
ChainCode.Org5
Peer0.Org1
Peer0.Org2
Peer0.Org3
Peer0.Org4
Peer0.Org5
(c) Network Utilization
Fig. 4: Container-Level Computing Intensity
hosted VMs to achieve realistic performance measurements.
Using the deployed blockchain application, which is pow-
ered by the Hyperledger Fabric framework, we analyzed the
blockchain network performance in terms of latency and trans-
action throughput. These metrics are essential in designing
blockchain-based markets as they determine the feasibility
and frequency of resource trades over the blockchain. Our
experiments showed that our blockchain-based slice brokering
application could process up to 40 auction transactions per
second while maintaining a 100% transaction throughput and
an average latency of 500 milliseconds, with a maximum of
100 TPS, with throughout very close to 100 %. Meanwhile,
as mentioned in [28], the time-scale envisioned for a 5G
network slice provisioning and deployment is in the order of
minutes. Therefore, our proposed market could support real-
time provisioning of multiple 5G slices without imposing any
considerable latency to the process. However, the performance
of a blockchain system highly relies on the SUT and other
properties of the blockchain such as block size, authorization
methods and consensus protocol. Therefore, further research
is needed to asses the impact of these design choices on the
5G slicing market performance.
ACKNOWLEDGMENT
Financial support from Science Foundation Ireland grants
14/IA/252 (O’SHARE) and 13/RC/2077 is gratefully acknowl-
edged. This material is based upon work supported by Google
Cloud.
REFERENCES
[1] A. Sgambelluri et al., “Orchestration of Network Services across Mul-
tiple Operators: The 5G Exchange Prototype,” in EUCNC, Jun. 2017.
[2] N. Afraz et al., “Evolution of Access Network Sharing and Its Role in
5G Networks,” Applied Sciences, vol. 9, no. 21, Oct. 2019.
[3] “5G Network Slicing,” FCC Technological Advisory Council (TAC),
Whitepaper, 2018. [Online]. Available: https://www.fcc.gov/general/tac-
reports-and-papers
[4] 3GPP, “TR 28.801 Study on management and orchestration of network
slicing for next generation network,” Technical report 28.801, 2018.
[Online]. Available: https://portal.3gpp.org
[5] N. C. Luong et al., “Applications of Economic and Pricing Models
for Resource Management in 5G Wireless Networks: A Survey,” IEEE
Communications Surveys Tutorials, 2018.
[6] W. Borjigin et al., “In Broker We Trust: A Double-auction Approach for
Resource Allocation in NFV Markets,” IEEE Transactions on Network
and Service Management, vol. 15, no. 4, Dec. 2018.
[7] Mettler, Matthias, “Blockchain Technology in Healthcare: The Revolu-
tion Starts Here,” in Healthcom. IEEE, 2016.
[8] Abeyratne, Saveen A and Monfared, Radmehr P, “Blockchain Ready
Manufacturing Supply Chain Using Distributed Ledger,” 2016.
[9] Guo, Ye and Liang, Chen, “Blockchain Application and Outlook in the
Banking Industry,” Financial Innovation, vol. 2, no. 1, 2016.
[10] J. F. Santos et al., “Orchestration next-generation services through end-
to-end networks slicing,” 2018.
[11] K. Samdanis et al., “From Network Sharing to Multi-tenancy: The 5G
Network Slice Broker,” IEEE Communications Magazine, vol. 54, no. 7,
Jul. 2016.
[12] D. E. Charilas and A. D. Panagopoulos, “A Survey on Game Theory
Applications in Wireless Networks,” Computer Networks, vol. 54, 2010.
[13] H. Ahmadi et al., “Virtualization of Spatial Streams for Enhanced
Spectrum Sharing,” in GLOBECOM, Dec. 2016.
[14] J. McMenamy, A. Farhang, N. Marchetti, and I. Macaluso, “Enhanced
Auction-assisted Lsa,” in ISWCS Conference, Sep. 2016.
[15] X. Chen et al., “An Auction-based Spectrum Leasing Mechanism for
Mobile Macro-femtocell Networks of Iot,” Sensors, vol. 17, Feb. 2017.
[16] D. Zhang et al., “A Double Auction Mechanism for Virtual Resource
Allocation in SDN-based Cellular Network,” in 2016 PIMRC, Sep. 2016.
[17] M. A. Habibi et al., “The Structure of Service Level Agreement of
Slice-based 5G Network,” CoRR, vol. abs/1806.10426, 2018.
[18] B. Nour et al., “A Blockchain-based Network Slice Broker for 5G
Services,” IEEE Networking Letters, vol. 1, no. 3, Sep. 2019.
[19] Adam Back, “Hashcash a Denial of Service Counter-measure,” 2002.
[20] S. J. Alsunaidi and F. A. Alhaidari, “A Survey of Consensus Algorithms
for Blockchain Technology,” in ICCIS, Apr. 2019.
[21] Ongaro, Diego and Ousterhout, John, “In Search of an Understandable
Consensus Algorithm,” in USENIX Conference, 2014.
[22] N. Afraz and M. Ruffini, “A Sharing Platform for Multi-tenant Pons,”
Journal of Lightwave Technology, vol. 36, no. 23, Dec. 2018.
[23] Linux Foundation, “Hyperledger Blockchain Performance Metrics,”
Whitepaper, 2018.
[24] “Performance and Scale Working Group - Performance and Scale Work-
ing Group.” [Online]. Available: https://wiki.hyperledger.org/x/ToIk
[25] Charles, P.W.D., “A Blockchain Benchmark Framework,”
https://github.com/hyperledger/caliper, 2019.
[26] “Prometheus - Monitoring System & Time Series Database.” [Online].
Available: https://prometheus.io/
[27] “Grafana: The Open Observability Platform.” [Online]. Available:
https://grafana.com/
[28] L. Valcarenghi et al., “Reliable Slicing in 5G Networks,” 2019.
