Content uploaded by Hitesh Tewari
Author content
All content in this area was uploaded by Hitesh Tewari on Nov 29, 2020
Content may be subject to copyright.
IEEE Communications Magazine • November 2020
20163-6804/20/$25.00 © 2020 IEEE
AbstrAct
5G technology is expected to enable many
innovative applications in different verticals. These
applications have heterogeneous performance
requirements (e.g., high data rate, low latency,
high reliability, and high availability). In order to
meet these requirements, 5G networks endorse
network flexibility through the deployment of new
emerging technologies, mainly network slicing
and mobile edge computing. This article introduc-
es a distributed blockchain-enabled network slic-
ing (DBNS) framework that enables service and
resource providers to dynamically lease resources
to ensure high performance for their end-to-end
services. The key component of our framework is
global service provisioning, which provides admis-
sion control for incoming service requests along
with dynamic resource assignment by means of
a blockchain-based bidding system. The goal is to
improve users’ experience with diverse services
and reduce providers’ capital and operational
expenditure.
IntroductIon
5G technology is expected to promote many new
applications in different vertical industries such
as manufacturing, automotive, healthcare, ener-
gy, and mobile broadband. Such applications will
encompass a variety of use cases, each having dis-
tinct sets of requirements (e.g., bandwidth, laten-
cy, scalability, and availability). A real-life scenario
depicting some of these use cases is illustrated in
Fig. 1. It consists of sharing high-resolution video
feeds along with braking data among vehicles to
enable motorists to adjust their driving to traffic
conditions and to anticipate sudden stops, and
streaming high-definition multimedia content for
passengers.
Provisioning resources to fulfill the variety of
requirements of these applications is an ardu-
ous task given today’s one-size-fits-all networks.
Indeed, accommodating these applications while
supporting existing services requires a program-
mable and flexible network infrastructure that can
be tailored to the specific needs of each appli-
cation. Besides, guaranteeing service continuity
between realms belonging to different network
providers is still a challenge. For instance, SP1 in
Fig. 1 cannot fulfill the blue car’s service requests
throughout its journey (i.e., from home to office
passing by the school) as it lacks coverage and
computational capabilities. A possible way to alle-
viate this problem is network sharing. It enables
network operators to share their infrastructure to
reduce capital/operating expenditures (CAPEX/
OPEX) and to offer lower-priced services to cus-
tomers. However, the way mobile networks are
built and operated limits the network operators’
ability to create novel services that can support
the diverse requirements of emerging 5G use
cases [1].
5G achieves such a design by integrating two
key technologies: network slicing and mobile
edge computing (MEC). The former splits the
physical network infrastructure into multiple log-
ical networks, called slices, which are controlled
and managed independently by slice owners.
The latter deploys computing resources near end
users to enable low-latency and high-bandwidth
network access. While flexibility is emphasized
through the network slicing dynamics, providing
real-time end-to-end services that can involve dif-
ferent operators is still a challenge. Indeed, there
is a clear urgency to design innovative techniques
to enable network slicing interoperations that
can span over multiple administrative domains.
In this regard, a centralized capacity broker was
proposed in [2], which is built on top of the Third
Generation Partnership Project (3GPP) network
sharing management architecture to enable net-
work operators to lease resources on the fly for
a particular time period. This scheme was large-
ly improved in [3] to optimize the on-demand
allocation of resources based on mobile traffic
forecast. An Internet of Things (IoT) broker was
proposed in [4] to enable operators to offer net-
work slices as a service in order to optimize slice
resource orchestration. In [5], a management and
orchestration architecture that deploys a broker-
ing layer based on software defined networking
was proposed to create end-to-end slices and allo-
cate computing and storage capacities at three
levels: sub-domain, domain, and multi-domain.
Finally, a brokering system that uses a reinforce-
ment learning algorithm was introduced in [6] to
dispatch resource requests to different network
operators considering constraints such as delay
and geographical location.
Despite their ingenuity, these approaches
along with other existing ones face two main
challenges: scalability: as the number of operators
(and therefore the number of slices) increases,
the broker may be overwhelmed, impacting the
Mohammed Amine Togou, Ting Bi, Kapal Dev, Kevin McDonnell, Aleksandar Milenovic, Hitesh Tewari, and Gabriel-Miro Muntean
ACCEPTED FROM OPEN CALL
This article introduces
a distributed block-
chain-enabled network
slicing (DBNS) framework
that enables service
and resource providers
to dynamically lease
resources to ensure high
performance for their
end-to-end services.
Mohammed Amine, Ting Bi, and Gabriel-Miro Muntean (corresponding author) are with Dublin City University; Kapal Dev and Hitesh Tewari
(corresponding author) are with Trinity College Dublin; Kevin McDonnell and Aleksandar Milenovic (corresponding author) are with Huawei Technologies Co.
Digital Object Identifier:
10.1109/MCOM.001.2000112
DBNS: A Distributed Blockchain-Enabled
Network Slicing Framework for 5G Networks
IEEE Communications Magazine • November 2020 3
performance of the whole ecosystem; and com-
plexity: to use network slices of other operators,
memoranda of understanding (MoUs) need to
be established based on pre-defined service level
agreement (SLA) requirements. This is a lengthy
process.
The main contribution of this article is the
design of a signaling-based distributed on-demand
framework, called distributed blockchain-enabled
network slicing (DBNS), to enable end-to-end and
on-the-fly leasing of resources to support service
continuity while meeting quality of service (QoS)
requirements. The key enabler of our distributed
on-demand architecture is global service provi-
sioning (GSP), a control and monitoring compo-
nent that provides admission control for incoming
requests along with resource assignment by
means of a blockchain-based bidding system.
The rest of this article is organized as fol-
lows. First, we describe the technology enablers
of DBNS. Then we present the fundamentals of
network slicing orchestration and its business
requirements. Next, we introduce the DBNS
architecture and describe how it can be deployed
and used. Afterward, we analyze DBNS perfor-
mance through a case study that focuses on video
streaming applications. Finally, we present our
conclusions along with future research directions.
dbns technology enAblers
After the early deployments of 3G networks,
network sharing was introduced to help mobile
operators accelerate their network rollouts as
well as offer various services to their customers
with reduced costs. Passive sharing and network
roaming were the initial network sharing solutions.
The former designates the sharing of site locations
or physically supporting infrastructure of radio
equipment (i.e., mast), while the latter denotes
the ability of subscribers to use networks of other
operators based on contractual agreements [2].
Then active radio access network (RAN) sharing
followed. It consists of sharing active network
equipment including base stations, antennas, and
mobile backhaul equipment [7]. This allowed
mobile operators to merge spectrum resources
on the basis of contractual agreements. However,
with the continuous growth of data traffic gen-
erated by a plethora of emerging applications,
new challenges that go beyond the original RAN
sharing concept have been introduced. As a
result, mobile operators had to think of new ways
to redesign their networks to address these con-
cerns.
Network slicing is a concept that has been
proposed to cope with the surge in mobile data
traffic. It is based on two technologies: Soft-
ware-Defined Networking [8] and Network Func-
tion Virtualization to allow for efficient network
management while enabling flexible network cus-
tomization to meet traffic requirements. Using
network slicing, operators can build multiple iso-
lated virtual networks on a shared physical infra-
structure. These logical networks, called slices,
are self-contained and orchestrated in different
ways depending on their service requirements
and can be owned by one or multiple tenants.
This provides new revenue opportunities for
mobile operators as slices can be used by other
operators, offering efficient utilization of the infra-
structure. Still, innovative approaches for efficient
and secure end-to-end network slicing admission
control that can span over multiple administrative
domains need to be investigated.
Lately, blockchain (BC) has been integrated in
5G networks to mitigate various security concerns
as it offers immutability, transparency, decentral-
ization, and privacy. Its applications in 5G can
be classified into three categories: supporting 5G
technology enablers such as MEC [9]; providing
efficient 5G services like network management
and virtualization [5]; and endorsing 5G IoT appli-
cations [10].BC is a peer-to-peer decentralized
distributed ledger that permanently and chrono-
logically records and ensures immutable and
unchangeable truthful transactions in untrusted or
partially trusted networks via cryptography-based
consensus mechanisms [11]. A simple BC oper-
ation goes through the steps illustrated in Fig. 2.
First, an entity (e.g., computer) requests a trans-
action that is broadcast to all nodes in the peer-
to-peer (P2P) network. All nodes in the network
validate the transaction using the requested enti-
ty’s public key. Once verified, the transaction is
linked to other transactions to create a new data
block, which is appended to the existing block-
chain, indicating the completion of the transac-
tion. Once the transaction has been locked into
a block, the other participants in the P2P network
can create their own transactions and broadcast
them over the BC P2P network to be included in
the next block on the ledger.
There are two types of BC: public and private.
Our focus in this article is on private BC as we
aim to design a network where only a finite num-
ber of entities can access it [12]. There are mul-
tiple platforms that enable the creation of such
networks. For instance, Multichain is a permis-
sioned blockchain that allows multiple networks
to simultaneously be on a single server and has
compatibility with the bitcoin network, including
transaction/block formats, P2P protocols, digital
signature schemes, and application programming
interfaces (APIs). But the main problem with Mul-
tichain is the lack of support for smart contracts.
Unlike Multichain, Ethereum supports smart con-
tracts; however, it suffers two major problems:
Figure 1. Sample of real-life use cases for the automotive vertical. The blue car
is an autonomous vehicle that requires surrounding cars to share two ele-
ments: high-resolution real-time video feeds to adjust the driving to traffic
conditions (see-through), and braking data to anticipate sudden stops. Fur-
thermore, high-quality entertainment services (e.g., games and movies) are
streamed via its built-in entertainment system to its passengers.
IEEE Communications Magazine • November 2020
4
anyone can connect to the network, and all data
inside smart contracts is visible to all nodes. To
mitigate these issues, Quorum was proposed. It
is an Ethereum-based digital ledger technology
(DLT) that provides a layer on top of Ethereum to
enable the implementation of private transactions
and to enhance the BC network robustness via
the deployment of different consensus algorithms.
Some of Quorum’s most promising features, with
respect to our approach, are summarized below:
• Privacy: It supports private transactions and
private contracts through public/private
state separation and uses constellation, a
P2P encrypted message exchange, for the
transfer of private data among network par-
ticipants.
• Peer Permissioning: It allows node/peer per-
missioning using smart contracts, ensuring
that only known parties can join the net-
work.
• Higher Performance: It offers significantly
higher performance (100 transactions/s)
compared to Ethereum.
• Alternative Consensus Mechanisms: It offers
multiple consensus mechanisms that are
more appropriate for consortium chains.
network slIcIng PlAyers And
busIness requIrements
From the technical point of view, a network slice
is an independent logical network that runs on a
shared physical infrastructure capable of provid-
ing an agreed service quality. From the business
perspective, deploying network slicing will enable
different players to achieve strategic commer-
cial goals such as increasing return on investmet
(RoI), enhancing network capacity, and expand-
ing network coverage. We identify four players,
described as follows:
• Mobile Network Operator (MNO): in charge
of deploying and maintaining the physical
network.
• Mobile Virtual Network Operator (MVNO):
lacks network infrastructure and leases
resources from an MNO.
• Over-The-Top Service Provider (OTT): oper-
ates on top of a network infrastructure
according to a pre-defined set of require-
ments that are specified in SLAs signed with
MNOs/MVNOs.
• Vertical Industry (VI): a set of applications
that are specific to an industrial sector (e.g.,
automotive, fabrication, entertainment). They
use the network infrastructure to provide ser-
vices to end users.
Given that the network infrastructure may belong
to either MNOs or MVNOs, addressing the fol-
lowing questions is of paramount importance for
these two players to decide whether or not to
invest in network slicing: Is it beneficial to their
businesses? Can they remain competitive? To this
end, the GSMA Network Slicing Taskforce (NEST)
specified in [13] three considerations when invest-
ing in network slicing. They are summarized here:
• Complexity: MNOs/MVNOs need to engage
in standardization activities in order to min-
imize the technical solutions’ complexity so
that adoption can be made relatively easy.
• Deployment Scenarios: All players should
agree on the commercial deployment sce-
narios for network slicing to drive economies
Figure 2. Distributed blockchain network slicing (DBNS) architecture.
Given that the network
infrastructure may
belong to either MNOs
or MVNOs, addressing
the following ques-
tions is of paramount
importance for these
two players to decide
whether or not to invest
in network slicing:
Is it beneficial to their
businesses?
IEEE Communications Magazine • November 2020 5
of scale.
• Deployment Cost: MNOs/MVNOs need to
work together to make the cost of deploying
network slicing marginal to the broader 5G
investment.
While the 3GPP Service Working Group SA1
described in [14] the requirements for various
use cases that are related to network slice deploy-
ment (e.g., end-to-end asset tracking and wind
farm communication networks), the 3GPP Service
Working Group SA5 presented in [15] use cases
and requirements for management and orchestra-
tion of network slicing, including multiple-operator
coordination management. Assume that operator
A wants to create an end-to-end network slice to
support a service across multiple operators (i.e.,
operators B and C). SA5 enumerates the steps to
accomplish this task, summarized as follows:
• Operator A makes the service request to
operators B and C asking them to allocate
resources (i.e., slices) for the service.
• Operators B and C can either create new
slices or use existing ones.
• Operators B and C should provide manage-
ment data (e.g., performance data) when
requested by operator A.
• Operator A is responsible for the manage-
ment of the end-to-end network slice.
The degree of trust between the different play-
ers can have an impact on the entire ecosystem.
Indeed, VIs and OTTs must trust MNOs/MVNOs
to provide the necessary resources. In addition,
MNOs/MVNOs must ensure that the control
provided to VIs and OTTs does not allow them
to negatively impact their network infrastructure.
Finally, MNOs/MVNOs must trust one another to
provide the required resources for services span-
ning multiple administrative domains. For this to
happen, additional considerations are needed to
provide an appropriate level of control and mon-
itoring.
dIstrIbuted blockchAIn-bAsed
network slIcIng FrAmework
DBNS is a distributed solution that enables net-
work operators to request resource provisioning
from other operators in case they cannot fulfill
the requested services. Figure 2 depicts its block
architecture. It has three components: GSP, slice
orchestrator (SO), and infrastructure manager
(IM). GSP is in charge of mapping resource pro-
visioning requests to appropriate network slices.
This is done through a blockchain-based bidding
system that enables all operators having a GSP
to participate in the bidding process. It has two
modules.
Request-Resource Matcher (RRM): responsi-
ble for handling customer requests and mapping
them to the suitable network slices. When receiv-
ing a customer service request, it first verifies
whether the current provider can fulfill the service
by probing the SO. If not, the RRM plays the role
of a broker by broadcasting the service provision-
ing request over the blockchain and selecting the
best bid among the ones received from the other
operators.
Blockchain Unit (BU): responsible for writ-
ing resource provisioning requests to the block-
chain and fetching their corresponding bids.
The resource provisioning requests, called bid
requests, are advertised in plain text, while the
matching bids, called bid replies, are encrypted
using the public key of the requesting operator.
The SO provides end-to-end network slice
orchestration either locally or across multiple
administrative domains. It has two modules.
Local Resource Orchestrator (LRO): provides
an abstract view of the underneath infrastructure
to GSP with the help of IM. It makes decisions
about creating new slices and updating existing
ones to include virtual/physical network func-
tions. It also keeps track of utilization status of the
various slices and monitors the QoS metrics to
comply with SLA requirements.
Multi-GSP Resource Orchestrator (MGRO):
allocates the appropriate resources (i.e., by cre-
ating new slicing or upgrading existing ones) for
the requested service if the bid reply is selected
and monitors the QoS metrics to ensure that SLA
requirements are properly met. It also enables
seamless service transition from one operator to
another and provides usage reports to be used for
billing purposes.
Finally, IM manages the underlying physical/
virtual infrastructure. It provides support for slic-
ing, enforces slice requirements from the SO, and
provides infrastructure monitoring and analysis
services.
To allow for a secure and efficient service pro-
visioning, DBNS has five phases.
Phase 0 — Setup: An operator willing to join
the DBNS framework is required to obtain a
public key certificate from a trusted third party
(TTP) such as a commercial certification authority
(CA). This certificate is then shared with existing
partners (i.e., operators that are already mem-
bers of the DBNS framework) to ask to join the
framework. Upon agreement, partners virtually
approve the operator’s request. This latter then
signs the GSP-based onboarding digital contract,
which specifies the activities that can be per-
formed and the rules to abide by. This includes
requesting resource provisioning from other part-
ners by broadcasting bid requests and sending bid
replies. If the placed bid is selected, partners have
the obligation of fulfilling the requested service
according to the agreed SLA requirements.
Phase 1 — Consumer Request: To avail of the
various services, consumers send service requests
(SREQs) to their network operators. Each SREQ
contains the consumer ID, the service require-
ments (e.g., bit rate, loss range, latency), a time
period during which the service is needed, and
the location where the service is to be provided.
When received, the RRM forwards the service
requirements to the SO. This latter probes the
LRO to verify whether the service can be fulfilled
locally. With the help of IM, the LRO sends a sta-
tus message to the RRM. If the service can be
supported, Phase 3 is executed. Otherwise, Phase
2 is carried out.
Phase 2 — BC-Based Bidding: If the service
cannot be fulfilled locally, the RRM encapsulates
an SREQ into a bid request (BREQ) containing
the request ID along with the ID of the request-
ing operator and forwards it to the BU. This latter
writes BREQ into the blockchain. DBNS makes
use of a permissioned blockchain to solicit bids
from different partners in the ecosystem.
The degree of trust
between the different
players can have an
impact on the entire
ecosystem. Indeed,
VIs and OTTs must
trust MNOs/MVNOs to
provide the necessary
resources. In addition,
MNOs/MVNOs must
ensure that the control
provided to VI and OTTs
does not allow them to
negatively impact their
network infrastructure.
IEEE Communications Magazine • November 2020
6
Each partner’s BU fetches the BREQ from the
blockchain and hands it to the RRM, which gets
the encapsulated SREQ. The RRM then sends
the service requirements to the MGRO to verify
whether the service can be supported. If yes, the
RRM makes an offer (i.e., includes the minimum
and maximum supported service requirements
along with the price), encapsulates it into a bid
reply (BREP), signs it with the public key of the
requesting operator, and forwards it to the BU.
The signature is used to prevent other providers
from obtaining any details about the bid, ensuring
a fair and transparent competition. The BU adds
the BREP transaction to the blockchain. The BU
of the requesting operator fetches all BREQs and
forwards them to the RRM. This latter decrypts
them using its private key, gets the different offers,
and chooses the one that perfectly suits the needs
of its customer. At this stage, the requesting oper-
ator executes a “smart contract” on the BC, which
locks in the customer and the operator providing
the service (i.e., the bid winner). The smart con-
tract is used to hold both parties accountable in
terms of their respective obligations.
Phase 3 — Service Provisioning: In the case
of local service provisioning (Phase 3a in Fig. 3),
the RRM asks the LRO to allocate the necessary
resources to meet the service requirements and
to start the service. Once the service is complet-
ed, the RRM generates the usage report along
with the bill and sends it to the customer. If the
service is to be provided by another partner, the
corresponding RRM asks the MGRO to allocate
the necessary resources and to start the service.
Once the service is completed, the RRM gen-
erates the usage report along with the bill and
adds them to the blockchain (i.e., encrypted with
the public key of the requesting operator). The
BU of the requesting provider fetches the report
along with the bill and forwards them to the RRM,
which transmits them to the consumer (Phase 3b
in Fig. 3).
Phase 4 — Termination: An operator can leave
the DBNS framework voluntarily by broadcasting
a terminate message via the blockchain. Before
departing, the operator should make sure that
no new service provisioning requests are accept-
ed and that all ongoing services are complet-
ed. Upon approval, partners then terminate the
operator’s GSP-onboarding contract and write
the transaction on the blockchain (Phase 4 in
Fig. 3). Partners can also impose sanctions on an
operator in the case of recurrent noncompliance
with SLA requirements. In this regard, bid request
requirements are compared against usage sum-
mary reports, and penalties (e.g., boycotting the
bid replies of the inspected operator for a period
of time) may apply for reported transgressions.
cAse study: entertAInment servIces
This section presents a simulation-based per-
formance evaluation of DBNS. The case study
considered replicates a real-life situation where a
customer UA of a network operator SPA streams
Youtube videos with resolutions 720p and 1080p,
Figure 3. DBNS sequence diagram illustrating the various phases.
Table 1. Simulation setup parameters.
IEEE Communications Magazine • November 2020 7
plays high resolution 3D games (i.e., with a 2K
video component), and watches 4K Netflix mov-
ies. These entertainment services have high bit
rate requirements of 2 Mb/s, 4 Mb/s, 15 Mb/s,
and 25 Mb/s. UA is connected via base station
BSA.
We assume that BSA has a dedicated network
slice for entertainment services that is already
overloaded as it is serving multiple concurrent
users. In the same area, operators SPB and SPC
offer services via base station BSB and access
point APC, respectively. Two scenarios are con-
sidered:
• SPA only uses its encumbered network slice
(between BSA and UA) to fulfill UA’s service
requests. This scenario is labeled Without
DBNS. Given that existing designs either
have no performance evaluation or are not
suitable for comparison with our proposed
architecture due to the use of auxiliary tech-
nologies, the Without DBNS approach is
chosen as a benchmark.
• SPA employs the proposed DBNS approach
to request service provisioning from SPB and
SPC. This scenario is labeled With DBNS. SPA
selects SPC’s bid as it has enough network
resources to be allocated to UA. The service
is fulfilled via the link between APC and UA.
Other simulation parameters are summarized in
Table 1.
Figure 4 shows how, by employing the pro-
posed DBNS, the supported throughput is equiva-
lent to the bit rate required by the various services
(i.e., 2 Mb/s for 720p, 4 Mb/s for 1080p, 15
Mb/s for 2K, and 25 Mb/s for 4K). Figure 4a also
shows that without deploying DBNS, only the bit
rates of 720p and 1080p services can be sup-
ported due to the lack of sufficient resources at
BSA. Figure 4b depicts the average delay and loss
rate when using both approaches. Using DBNS,
the loss rate is almost 0, while the average delay
ranges between 20 and 25 ms for the different
services. Without DBNS, the average delay is
between 19 and 22 ms, which matches the one
incurred by DBNS, particularly for 2K and 4K ser-
vices. This is because the average delay in this
case only considers the supported throughput
for both services (i.e., 8 Mb/s each) and not the
required one. Furthermore, the loss rate is exorbi-
tant for 2K (i.e., 50 percent) and 4K (i.e., 70 per-
cent) services, which significantly affects the users’
quality of experience.
conclusIons
This article discusses network slicing technology,
describing its major players and business require-
ments in the context of the 5G technology. It
then introduces the DBNS framework, which pro-
motes dynamic resource leasing between differ-
ent providers to support high performance for
end-to-end services. It has two key components
and their associated mechanisms: GSP, which
provides admission control for incoming requests
by means of a blockchain-based bidding system,
circumventing the lengthy process of setting up
MoUs; and the MGRO, which supports seamless
service transition from one entity to another along
with monitoring QoS metrics to ensure that SLA
requirements are met.
We believe that DBNS is a fundamental leap
forward as it enables network operators to move
toward a more flexible and on-demand way of
leasing and procuring network infrastructure and
assets to fulfill services in situations where infra-
structure cannot meet demand, and to provide
more dynamic capacity when demand spikes are
experienced (i.e., “pop-up” networks for large
sporting events). This can help network operators
decrease both their CAPEX and OPEX costs and
increase their revenues.
Future research directions could consider the
analysis of other context-aware, multi-tenant uses
cases and design of innovative resource alloca-
tion techniques considering the isolation require-
ment. In addition, the evaluation of DBNS from
business, policy, and legal perspectives could be
realized. Finally, blockchain performance optimi-
zation in terms of transaction rate and scalabili-
ty can be evaluated through the use of different
data structures as well as deployment of multiple
chains or channels.
Acknowledgment
The Science Foundation Ireland (SFI) support,
co-funded by the European Regional Devel-
opment Fund, via research grants 16/SP/3804
Figure 4. Simulation results of the various requested services with and without use of DBNS: a) average throughput; b) average delay
and average loss rate.
(a) (b)
IEEE Communications Magazine • November 2020
8
(Enable) and 12/RC/2289_P2 (Insight) is grateful-
ly acknowledged.
reFerences
[1] 3GPP, “Feasibility Study on New Services and Markets Tech-
nology Enablers for Critical Communications,” Tech. Rep.
22.862, R. 14, 2016.
[2] K. Samdanis, X. Costa-Perez, and V. Sciancalepore, “From
Network Sharing to Multi-Tenancy: The 5G Network Slice
Broker,” IEEE Commun. Mag., vol. 54, no. 7, July 2016, pp.
32–39.
[3] V. Sciancalepore et al., “Mobile Traffic Forecasting for Maxi-
mizing 5G Network Slicing Resource Utilization,” IEEE INFO-
COM, May 2017, pp. 1–9.
[4] V. Sciancalepore, F. Cirillo, and X. Costa-Perez, “Slice as a
Service (SlaaS) Optimal IoT Slice Resources Orchestration,”
IEEE GLOBECOM, Dec 2017, pp. 1–7.
[5] T. Taleb et al., “On Multi-Domain Network Slicing Orches-
tration Architecture and Federated Resource Control,” IEEE
Network, vol. 33, no. 5, Sept./Oct. 2019, pp. 242–52.
[6] G. Kibalya et al., “A Reinforcement Learning Based Approach
for 5G Network Slicing Across Multiple Domains,” Proc.
15th Int’l. Conf. Network and Service Management, Oct.
2019, pp. 1–5.
[7] A. Devlic et al., “NESMO: Network Slicing Management and
Orchestration Framework,” Proc. IEEE ICC Wksps.), May
2017, pp. 1202–08.
[8] M. A. Togou et al., “A Hierarchical Distributed Control Plane
for Path Computation Scalability in Large Scale Software-De-
fined Networks,” IEEE Trans. Network and Service Manage-
ment, vol. 16, no. 3, Sept. 2019, pp. 1019–31.
[9] H. Yang et al., “Blockchain-Based Hierarchical Trust Net-
working for Jointcloud,” IEEE Internet of Things J., vol. 7, no.
3, 2020, pp. 1667–77.
[10] H. Yang et al., “Distributed Blockchain-Based Trusted
Multi-Domain Collaboration for Mobile Edge Computing
in 5g and Beyond,” IEEE Trans. Industrial Informatics, 2020,
pp. 1–1.
[11] H. Tewari, “Blockchain Research Beyond Cryptocurren-
cies,” IEEE Commun. Standards Mag., vol. 3, no. 4, Dec.
2019.
[12] M. Belotti et al., “A Vademecum on Blockchain Technol-
ogies: When, Which, and How,” IEEE Commun. Surveys &
Tutorials, vol. 21, no. 4, 2019, pp. 3796–3838.
[13] GSMA. “Network Slicing Use Case Requirements,” Apr.
2018; https://www.gsma.com/futurenetworks/wp-content/
uploads/2018/07/Network-Slicing-Use-Case-Requirements-
fixed.pdf.
[14] 3GPP, “Feasibility Study on Business Role Models for Net-
work Slicing,” Tech. Rep. 22.830, Rel. 16, Dec. 2018.
[15] 3GPP, “Study on Management and Orchestration of Net-
work Slicing for Next Generation Network,” Tech. Rep.
28.801, Rel. 16, Jan. 2018.
bIogrAPhIes
MohaMMed aMine Tog ou is a postdoctoral researcher with the
Performance Engineering Laboratory at Dublin City University
(DCU), Ireland. He received B.S. and M.S. degrees in computer
science and computer networks from Al Akhawayn University,
Ifrane, Morocco, and a Ph.D. degree in computer science from
the University of Montreal, Canada. His current research inter-
ests include 5G networks, SDN-NFV, network slicing, and IoT.
Ting Bi is a postdoctoral researcher with the Performance Engi-
neering Laboratory at DCU. He received a B.Eng. in software
engineering from Wuhan University, China, in 2010, and M.Eng.
and Ph.D degrees in telecommunications from DCU in 2011
and 2017, respectively. His research interests include mobile
and wireless communications, multimedia, and multi-sensory
media streaming.
Kapa l d ev is a research fellow with the CONNECT Centre,
School of Computer Science and Statistics, Trinity College Dub-
lin. He was awarded a Ph.D. degree by Politecnico di Milano,
Italy, in July 2019. His research interests include blockchain,
5G beyond networks, and artificial intelligence. Previously, he
worked as a 5G junior consultant and engineer at Altran Italia
S.p.A, Milan. He is coordinating two Erasmus+ International
Mobility projects.
Kevi n Mcdo nnell is an architect at the Huawei Ireland
Research Centre. His recent work focuses on autonomous net-
work operations using knowledge management, intent, and
machine learning. He serves as workstream leader for Autono-
mous Networks in the TM Forum, and participates in standard-
ization activities in 3GPP and GSMA. He is an active contributor
to the ONAP project and is company leader for EU Horizon
2020 Project 5GTANGO.
aleKsandar Milenovic is a Huawei chief architect for Autono-
mous Network Operations and director of the Communications
Technology Lab in the Huawei Ireland Research Center. He
has nearly 20 years of experience in developing products in the
area of telco operations and maintenance (O&M). He is leading
research in intelligent qutomation of telco operations.
hiTesh Tewari is an assistant professor in the School of Comput-
er Science and Statistics at Trinity College Dublin. His research
interests lie in the areas of network security and applied cryptog-
raphy. In recent years he has been actively working in the area
of distributed ledger technologies.
gaBriel-M iro Mun Tean (gabriel.muntean@dcu.ie) is an associ-
ate professor with the School of Electronic Engineering, DCU,
and co-director of the DCU Performance Engineering Labo-
ratory. He was awarded a Ph.D. degree by DCU in 2004. His
research interests include quality-, energy-, and performance-re-
lated issues of rich media content delivery. He is an Associ-
ate Editor of IEEE Transactions on Broadcasting and Multimedia
Communications Area Editor of IEEE Communication Surveys &
Tutorials. He coordinated the EU Horizon 2020 project NEW-
TON.
