Distributed Ledger Technologies For Network Slicing: A Survey

Network slicing is one of the fundamental tenets of Fifth Generation (5G)/Sixth Generation (6G) networks. Deploying slices requires end-to-end (E2E) control of services and the underlying resources in a network substrate featuring an increasing number of stakeholders. Beyond the technical difficulties this entails, there is a long list of administrative negotiations among parties that do not necessarily trust each other, which often requires costly manual processes, including the legal construction of neutral entities. In this context, Blockchain comes to the rescue by bringing its decentralized yet immutable and auditable lemdger, which has a high potential in the telco arena. In this sense, it may help to automate some of the above costly processes. There have been some proposals in this direction that are applied to various problems among different stakeholders. This paper aims at structuring this field of knowledge by, first, providing introductions to network slicing and blockchain technologies. Then, state-of-the-art is presented through a global architecture that aggregates the various proposals into a coherent whole while showing the motivation behind applying Blockchain and smart contracts to network slicing. And finally, some limitations of current work, future challenges and research directions are also presented.


I. INTRODUCTION
F IFTH Generation (5G) is currently being rolled out globally. As it continues to take shape, network slicing has become one of the fundamental technologies to enable a wide range of use cases of 5G. The introduction of network slicing in networks has motivated their transformation based on software solutions, such as software-defined networking (SDN) and network function virtualization (NFV) [1]. In particular, network slicing helps achieve flexibility and modularity to create multiple virtual networks, each specified for a use-case, on top of a shared network to support various applications belonging to diverse verticals. An inherent characteristic to network slices is their End-to-End (E2E) nature, including both the E2E services and the E2E resources associated with this service. In a general case, this will involve multiple parties, each providing a chunk of the E2E service/resources.
(QoS) for consumers and cost-effective solutions for network operators supporting the transformation that the 5G network brings, along with many advancements that are yet to come in future networks [4]. This is a fundamental characteristic that makes Blockchain appear on scene in this context, as further developed next.
Vertical industries span many different domains with highly diverse requirements. They include autonomous driving and vehicle-to-everything (V2X) applications [5], Industry 4.0 [6], online health monitoring, remote diagnosis, remote robotic surgery and drug delivery [7], 4K and 8K content over the virtualized content delivery network (vCDN) [8], smart cities [9], mobile Augmented Reality (AR)/ Virtual Reality (VR) applications [10], and many more. However, vertical industries are rather broad, and the service characteristics of the corresponding vertical segment determines their requirements. The above approach is often referred to as "network as a service" [11] (or network slice as a service for our purposes) and it is seen as the tool for implementing dedicated and customized virtual E2E networks, enabling vertical industries to deploy their services efficiently.
In a separate thread, some work appeared in [12] and [13] that advocate for Distributed Ledger Technologies (DLT) or Blockchain as a solution for the existing challenges to meet the complex requirements of network slicing for vertical applications. In this sense, DLT may become the basis of a decentralized and transparent platform for multi-party negotiation between stakeholders of the next generation network ecosystem. Also, DLT may provide a solution to ensure the main security principles, including confidentiality, authentication, authorization, availability, and integrity. Moreover, DLT-based new business models for network slicing services can improve profit for providers and better experience and cost-effective solutions for the consumers.
Blockchain is fundamentally an immutable, transparent and decentralized ledger. The concept relies on the architecture of Peer-to-Peer (P2P) networks [14] that efficiently manages all network members and does not need to be controlled by any single centralized authority for transaction information. In particular, Blockchain has many favourable traits, namely decentralization, immutability, transparency and sustainable storage of databases. Due to these properties, Blockchain has the potential to be integrated with network slicing. It is predicted that Blockchain will be a crucial technology for novel applications from resource sharing, ubiquitous computing, and reliable content-based storage [15]. This is even more important in a next generation network context, where the number of stakeholders involved to offer an E2E network slice is expected to grow. It includes Virtual Network Function (VNF) providers, multiple administrative domains under the control of different operators and resource providers as they do not have essential trust established.This lack of trust has traditionally been solved through offline processes for contract negotiations or even through the creation of neutral, yet centralized, trusted entities. However, Blockchain may bring the advertisement of services and automation of administrative negotiations in the form of an open marketplace. It offers the technical substrate to automate all the varied administrative interactions among such diverse stakeholders in a decentralized way and through records that are immutable and auditable. If we add to this the capability of dynamically monitoring such administrative processes through smart contracts, it is expected that all this potential is somehow realized in the short-term. In this sense, it may eventually become a fundamental piece of the telco ecosystem.
Research works on the application of Blockchain as a DLT to Beyond 5G (B5G) or Sixth-Generation (6G) networks are also available [24]- [26].
The preexisting surveys explored various aspects of Blockchain with 5G. Some of these are discussed as follows: In [25] authors discuss the Blockchain for 5G and beyond networks where they aim to provide a study on the integration of Blockchain and 5G technologies for delivering services. The authors discuss opportunities that Blockchain brings to 5G services. Similarly, the authors in [27] take a look at decentralizing applications with Blockchain and examine the state-of-art 5G and beyond DApps. This study also looks at other aspects, such as security, privacy and tokenization. Also, the study presented in [28] gives an overview of the integration of Blockchain with 5G-enabled IoT focused on industrial automation. The authors discuss various applications for integrating Blockchain with 5G-enabled IoT. This study also illustrates open issues and challenges for Blockchain and industrial automation integration. Finally, the authors in [29] present a review on the application of Blockchain in 5G and beyond networks. This paper discusses the benefits of applying Blockchain into the 5G ecosystem using the E2E approach to enable service delivery models.
The discussion above demonstrates that the recent research has provided a perspective on integrating Blockchain with 5G and beyond networks. However, the existing literature has limitations. Although they present the review on Blockchain for 5G and beyond 5G networks, the in-depth and thorough discussion on network slicing is missing from the literature. In addition, the focus of these current surveys lacks an extensive discussion on the motivation, state-of-the-art and frameworks of Blockchain-based network slicing in the existing literature. Furthermore, network slicing focused future research directions are not discussed in-depth in the current literature. Therefore, based on the observation, we can conclude that this article can fill the gap and provide a review on DLT and Blockchain for network slicing dedicating on current efforts, limitations and future research direction which can add value in the academia. Also, we believe that this article can be an excellent opportunity to further increase reader's knowledge and take a closer look at the integration of DLT with network slicing by reviewing current efforts, limitations, and further research directions. Motivated by the limitations discussed above, the aim of this paper is to narrow down the discussion to the area of network slicing and to present a review of the integration of Blockchain as a DLT technology with it.
In summary, the main contributions of this review article follow: • To provide an overview of network slicing, concepts and current challenges; • To overview enabling technologies of DLT (i.e. smart contracts, platforms and its consensus algorithm) and their characteristics; • To discuss and structure the state-of-art on the integration of DLT with network slicing; • To provide an in-depth discussion on application of DLT to verticals served by network slicing; • To highlight the remaining challenges and future directions.
The structure of this review is shown in Fig 1, which also highlights the major contribution of this work. This paper is organized as follow: Section II presents an overview of network slicing. We discuss the basic terminologies, key enabling technologies, principles and global efforts towards its realization, hence providing an overview of the network slicing basics. In Section III, we present a detailed overview of Blockchain as a DLT technology, its basic concepts, how it works, consensus algorithms and the key features such as smart contracts enabled on different platforms. In Section IV we illustrate and analyze the the meaningful works we found in the literature, their aim and functionalities as they integrate DLT features in their network slicing frameworks. The application of DLT for various important verticals industries is presented in Section V. Finally, we summarize the limitations, challenges and future directions in Section VI. Moreover, the list of acronyms used in this review are presented in Table 1.

II. NETWORK SLICING
This section gives a brief overview of the main concepts underlying network slicing as well as those characteristics that make Blockchain fit in this context.

A. CONCEPT
There are various organizations working on (hence defining and refining) the term network slice (e.g., Next Generation Mobile Networks (NGMN), Third-Generation Partnership Project (3GPP) , Internet Engineering Task Force (IETF)). In brief, it could be defined as follows [30]: "A network slice is a complete logical network with specific services offered to customers over a shared compute, storage and network infrastructure, e.g. a network operator can build a network slice including an Access Network (AN) and a Core Network (CN) to enable communication services." VOLUME 4, 2016  There are two implicit characteristics in this definition that are fundamental in network slicing that should be made explicit: • End-to-End: Network slices offer E2E performance guarantees, which implies that if the provider to which the network slice is requested does not have full control of the whole E2E slice and associated resources, it has to reach agreements with other providers and then stitch all the segments into a single E2E network slice. Therefore, there must be mechanisms in place to settle these agreements at the technical and at the administrative levels. While focusing on the 5G networks architectures, an E2E network slice is considered a composition of virtual functions. These virtual functions comprise the access and core networks, which enable mobile connectivity, with added virtual applications instantiated at the cloud domains or edge, while interconnection is provided at the transport level. • Network slice resources: The network slice is a com-plete (logical) network consisting of underlying resources over which the slice is deployed. Therefore, any slicing framework must embed schemes to isolate them from those of other slices. As mentioned above, managing the virtualized networking elements related to access, core and transport domains must be driven and complemented by the orchestration of the virtual application functions. Also, QoS requirements, security, dynamicity, resource consumption and isolation should be considered.
Other related characteristics to the above ones that are associated with network slicing are [1], [2]: • E2E programmability: Softwarization brings programmability, which simplifies the management of services and networks, as well as their integration and operational challenges -especially for supporting communication services. Furthermore, it permits third parties to have control over the allocated slice resources, via open Application Programming Interfaces (APIs) that present network capabilities facilitating on-demand service-oriented customization [3]. • E2E automated network operation: It is a need to enable an on-demand and dynamic configuration of network slices (e.g., creation, removal and deployment) without the need for fixed contractual agreements and manual intervention to handle Service Level Agreements (SLAs) [2]. • Resource isolation: It is crucial for network slicing that it assures performance guarantees even when other slices compete from the resources of the same shared network [31]. • Resource slice customization: Resources must be adapted to the needs of a variety of services with diverse requirements [32]. • Network resources elasticity: Resources consumed by a slice must dynamically adapt to varying network conditions and service needs. For instance, slice elasticity can be offered by scaling up/down/in/out the allocated resources, or by relocating VNFs, or by adjusting the applied policy and re-programming the functionality of specific data and control plane elements [33]. Therefore, flexibility ensures that the requested SLA.

B. CONTEXT
It has been widely discussed that 5G will support a variety of services from a plethora of vertical industries over the same shared infrastructure. At a more technical level, this will translate into the deployment of three types of logical networks (or slices) to serve their needs, namely massive Machine Type Communications (mMTC), enhanced Mobile Broadband (eMBB), and Ultra Reliable Low Latency Communications (URLLC). According to [34] in a 5G network, the network operators have several motivations to introduce E2E network slicing. These motivations include customized network services to satisfy each consumer's SLA, flexibility, and cost-efficiency. And this same trend is only expected to increase in 6G networks. These services are supported with the help of "network slicing" and the capabilities offered by the underlying shared infrastructure. For instance, network slicing can be an answer for telecom operator's on how to construct and manage a targeted network that can meet the emerging necessities of a wide range of enterprises [35]. Moreover, for vertical industries, network slicing is a powerful enabler for telecom operators to expand their service offerings towards industry consumers, produce new services, and enhance network value. To achieve a sliced network, it is remodeled into a set of logical networks on top of a shared infrastructure. Moreover, each logical network is designed to serve a defined business purpose and comprises all the necessary network resources, configured, and combined E2E [2].
In this section, we will discuss the basic concepts including architecture, NFV, orchestration and management in network slicing, and future trends and present limitations. But before that, let us set the context by introducing the stakeholders involved in network slice deployment.

C. STAKEHOLDERS
In addition to the diversity of technologies and use cases to be served on top of a shared infrastructure, 5G and B5G networks are also complex because of the variety of stakeholders. In fact, softwarization and programmability bring open architectures with clearly defined interfaces. In turn, open interfaces define the borders among potentially different stakeholders, hence defining new business relationships.
The 3GPP defined some of the business roles required when dealing with network slices [36], including communication service customer, communications service provider, network operator, network equipment vendor (incl. virtual network function provider), virtualization infrastructure service provider, network function virtualization infrastructure supplier, data center service provider, and hardware provider. These basic roles have been further elaborated and an operational architecture has been designed, implemented, deployed, and evaluated in the project 5G-Transformer [37], [30]) and its follow-up 5Growth [38]. The various service offerings by each stakeholder have been defined as well.
At a high level, and according to the NGMN description of the slicing concept [39], the stakeholders were distributed in three layers. First, the service instance layer consumes the services offered by the underlying providers, which exposes a vertical-oriented API so that the customer can focus on its business logic and request the required services by using parameters understandable by the vertical. Second, the network slice instance layer is in charge of providing the requested E2E services to the vertical. This entails the translation from vertical-oriented service descriptions to network slices, which are eventually instantiated in the network in the form of NFV network services. Finally, at the resource layer, we find all those providers whose service offerings are related with resource provisioning in its various flavors (e.g., cloud computing, edge computing, transport, resource aggregators).
Though the ecosystem is continuously evolving, in general, it has been the norm that the various roles inside each of the layers have been played by the same organization, hence not introducing administrative boundaries between the entities playing each of the roles. It is also common that the network slice instance layer and the resource layers are under the same administrative domain.

D. THE ETSI ARCHITECTURAL FRAMEWORK AND ITS MAJOR COMPONENTS: AN OVERVIEW
The technical framework enabling network slice offerings is that of European Telecommunications Standards Institute (ETSI)-NFV [40] and associated technologies (e.g., SDN). Figure 2 illustrates the ETSI NFV architectural framework.
NFV allows virtualizing network nodes and services (e.g., routers, firewalls, and load balancers) that have traditionally been run on proprietary hardware. Thus, the software and hardware, which have traditionally been tightly integrated VOLUME 4, 2016 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.  in telecom scenarios, are now split [41]. These services are implemented with the help of virtual machines (VMs) or containers on commodity hardware, which permits service providers to run their network on conventional servers rather than proprietary ones, hence bringing to the telecom's world the economies of scale of cloud computing. This is even more important in a context with increasingly demanding and diverse services.
The ETSI NFV specifications define an operational framework for orchestrating and automating [42] VNF software appliances on virtualized infrastructure on commercial offthe-shelf (COTS) hardware and managing them through their life-cycle [43].
The functional blocks defined in the NFV architectural framework are: These major functional blocks of the framework are illustrated and explained in detail in the ETSI framework [44]. Thus, the NFV architectural framework specifies the interaction across different functional blocks by a set of welldefined reference points. The major components of an NFV architecture, i.e., the functional blocks, are discussed below. We start by explaining VNFs and EM. Then, we explain the role of NFVI and NFV MANO. And, lastly, we discuss OSS/BSS. We also illustrate these functional blocks in Figure  2.

1) Virtualized Network Function (VNF) and Element Management System (EMS)
The functionality assigned to a given VNF can be deployed in one or more VMs (or containers) on top of general purpose hardware infrastructure. VNFs can embed routers, switches, firewalls, or a number of other network services available from various vendors that are run as software processes.
Therefore, VNFs replace dedicated hardware devices by virtualizing essential network functions previously in the domain of dedicated hardware appliances. As a result, operators can deploy novel services, improve security and tailor network performance at scale. Moreover, [44] provides several use-cases of targeted network functions (NFs) for virtualization.
The EMS, in the NFV context, is responsible for the functional management of the VNF, i.e., Fault, Configuration, Accounting, Performance and Security Management (FCAPS). An EMS may manage the VNFs through proprietary interfaces. Also, there may be one EMS per VNF, or an EMS can manage multiple VNFs [45].

2) NFV Infrastructure (NFVI)
The NVFI is built on general purpose networking, computing, and storage hardware. The NFVI also includes the "virtualization layer", which sits on top of the hardware and abstracts hardware resources to expose them as virtual resources and to allow them to be logically partitioned and provisioned to serve VNFs. In other words, the NFVI combines the necessary software and hardware components to supply the computation, storage, network, and software resources on which VNFs are deployed and managed.

3) NFV-MANO Functional Blocks
The NFV management and network orchestration (NFV-MANO) [42], [46] enables the coordinated management and orchestration of services and resources over a virtualized shared infrastructure, including computation, networking, storage, transport network, and Radio Access Network (RAN). The NFV-MANO defined by ETSI, envisions direct mapping of network slices to NFV network services. According to [47], the NFV network service is a resource-centric view of a network slice.
The NFV MANO framework traditionally features three functional blocks: the Virtualized Infrastructure Manager (VIM), Virtualized Network Function Manager (VNFM), and NFV Orchestrator (NFVO). Below we summarize their scope: • NFV Orchestrator: It offers two main functionalities: network service orchestration and resource orchestration. As for the former, it is in charge of the lifecycle management of the deployed services. For instance, this includes making the services available to customers, managing their instantiation/deployment, automatically reacting to service-related events (e.g., scaling if more resources are needed), or network service termination.
Resource orchestration is in charge of the interaction with the underlying infrastructure (e.g., through its VIM. This includes the reservation/allocation of resources according to the service needs, the monitoring of their operation and the placement of VNFs in the right resources to fulfill service requirements. • VNF manager (VNFM): It is in charge of individual VNF lifecycle management. For this purpose, each VNF is associated with its VNFM. This includes instantiation (including not just deployment but configuration of the VNF itself), VNF instance software upgrade, VNF instance scale in/out/up/down, VNF instance termination. • Virtualized infrastructure manager (VIM) and WAN Infrastructure Manager (WIM): The VIM and the WIM control and manage NFV Infrastructure (NFVI) physical and virtual resources in a single domain. These are the building blocks that interacts with the actual infrastructure for deploying the virtual machines or containers (VIM) and for setting up the paths in the transport network (WIM). Therefore, they interface with a variety of hypervisors and network controllers. In an NFV architecture, there may be more than one VIM/WIM, with each of them managing or controlling NFVI resources from a given infrastructure provider. Generally, a VIM/WIM may be concentrated in supervising a particular type of NFVI resource (e.g., computer-only or storage-only) or could operate various kinds of NFVI resources.
To these building blocks, a network slice manager is often added on top to manage network slices that are requested in the form of NFV network services to the NFVO, as for instance in [38]. This building block is in charge of the lifecycle management of the slices. In this sense, they are closer to the service actually requested by the vertical, and so, of its business priorities. This may include slice instantiation according to the types defined by the 3GPP, translation of vertical service requests into slice requests, and finally, into NFV network service requests sent to the NFVO, or arbitration among slices according to priorities.

4) Operation Support System/Business Support System (OSS/BSS))
The OSS of an operator tackles network management, as well as fault, service and configuration management. In contrast, BSS is in charge of customer, product and order management. In other words, in the ETSI NFV architectural framework, the OSS supports network operations and services while the BSS supports business operations. In the NFV architecture, an operator's current OSS/BSS can be connected with the NFV MANO to perform various actions, such as requesting network or VNF lifecycle management or forwarding NFV related information. Further, [40] describes how this reference point can be used.

E. RELATED EFFORTS
Several initiatives from industry and academia have been defining network architectures that feature network slicing. Below we highlight some of these efforts;

1) Standardization and industry groups
Multiple organizations have adopted the network slicing concept and defined the architectures and frameworks to realize it.
• The NGMN Alliance elaborated some high level documents describing the network slicing concept and its potential for mobile network operators [39]. • The 3GPP is the one the significant standards organization involved in architecture definition for 5G. Numerous iterations of standards releases have placed a foundation for the current phase of slice-specific activity. The pathway to network slicing functionality has been paved by DÉCOR (eDÉCOR) in Release 14 standards and fully accomplished with the work on network slicing within the Release 15 system architecture for the 5G System (3GPP TS 23.501) [48]. In this architecture, various types of slices to serve widely different traffic types have been specified (mMTC, URLLC, and eMBB). • The ETSI NFV [41] industry specification group is defining an open architecture that serves as framework for dealing with virtual networks in general, and so, network slices. This architecture separates the software from the hardware functionality and defines the building blocks to enable flexible deployment and management of virtual functions and virtual links over heterogeneous infrastructures. In this way, the flexibility required by operators to adapt to increasing and changing demands can be offered.

2) Research projects
There are multiple projects dealing with the concept of network slicing in general and also focusing on specific aspects in each of them. For instance, most projects in the Horizon 2020, the 5G Infrastructure Public Private Partnership (5GPPP) program deal in one way or another with network slicing [49]. In the following we focus on those that explore some of the concepts that set the framework for what is discussed in this survey paper: • The 5G Novel Radio Multiservice Adaptive Network Architecture (5GNorma) project [50] defines a new programmable and flexible mobile architecture. The intention is to enable multi-tenancy over a shared physical infrastructure. To this end, 5GNorma includes three enabling operational blocks, namely Software Defined for Mobile networks (SDM)-Orchestrator(O), SDM-Control(C), and SDM-X (Coordinator). • The 5G Exchange (5GEx) [51] has introduced an architecture further extending the concept of ETSI NFV architecture for multiple domains. The proposed architecture is composed of three layers: resource domain, VOLUME 4, 2016 single domain resource, and multi-domain resources. The resource domain illustrates the lower layer of the architecture. It presents domain resources to the single domain orchestration layer via specific interfaces. According to 5GEx, a domain may lead to a technological domain or operator domain. The middle layer, the single-domain orchestration layer, constitutes the domain-specific orchestrator, which performs resource and service orchestration of a specific domain managing the interfaces exposed by the domain resource layer. The domain-specific orchestrator is utilizing interfaces for communication and coordination. Additionally, the top layer of the architecture is the multi-domain orchestration, which involves the multi-domain orchestrator. Each multi-domain orchestrator is connected with one or multiple single-domain orchestrators, and managed by the orchestrator administrative domain via businessto-business (B2B) interface. • 5G Transformer (5GT) [37] aims to integrate network slicing concept into mobile transport networks by managing slices tailored to the needs of different vertical industries. The presented technical approach is: (i) enabling vertical industries to reach their service requirements within customized slices and (ii) federating transport networking from the edge up to the core, and cloud, specifically to create and manage slices throughout a federated virtualized infrastructure. It has been built on three main modules, namely; vertical slicer (VS), service orchestrator (SO), and mobile transport platform (MTP). The VS is a logical entry point for verticals to support easy creation and management of the slices. The SO deals with end-to-end service orchestration, the federation of transport networking and computing resources from multiple domains, and their allocation to slices [52]. Furthermore, the MTP is the underlying unified transport layer for integrated front-haul and backhaul networks [53]. • The 5Growth [38], [54] architecture is an evolution of the 5GT architecture. The purpose is to enhance performance, adaptability, automation, and security. It facilitates automated deployment and uniform operation of slices, customized to support the requirements of the various vertical industries, spanning from Industry 4.0 to the transportation industry and energy sectors, to name a few. In this direction, the basic core building blocks are those of 5GT, though they are extended to enable additional functionality. For instance, multiple options for multi-administrative domain interactions are possible, including the request of segment of vertical services, of subslices, of segments of NFV network services, or of resources. The monitoring platform is improved to be able to better monitor those metrics that are needed to better deal with the adaptability requirements of slices and services. And talking about adaptability, an Artificial Intelligence/Machine Learning Platform (AIMLP) is integrated in the framework allowing to dynamically load models that automate management decisions to trigger some of the lifecycle management operations when the service/slice requires it. This section has mostly described the technical characteristics and mechanisms for offering network slices. However, when discussing the inter-stakeholder interactions it was also clear that to realize the E2E network slicing concept to its full extent there are administrative aspects that must be integrated in such technical framework, and this is where Blockchain or Blockchain as a DLT comes into play.
There are two kinds of interactions in a network slicing context that are already assumed to negotiate administrative constraints. First, in addition to their variety, vertical industries are, in general, organizations with very different scopes from those of communication service providers. Therefore, different organization will have to negotiate the vertical service business conditions. And second, the E2E nature of slices in a general case will require the interaction between different communication service providers (sometimes referred to as service/resource federation [52]) in order to deploy the slice in all spots where a given vertical industry wants to deploy its service. For instance, service provider A, with service offering restricted to a given geographic region, may have to interact with service provider B to deploy a segment of the E2E slice that the vertical requested to be deployed in another region. Therefore, an administrative/business relationship must be negotiated.
The dynamicity brought by NFV provides the basic building blocks to adapt to demands and to locate slice resources in the appropriate network spots to fulfill slice requirements. However, this framework must be augmented with components that allow automating the above administrative relationships in the same way technical relationships between different architectural entities are. It is only in this way that generic E2E slices can be offered. It is precisely in this context that Blockchain is expected to play a key role.

III. BLOCKCHAIN AND DISTRIBUTED LEDGER TECHNOLOGIES
This section provides a background on the DLT and Blockchain. This will allow better understanding in the following sections how these technologies are able to extend the support and the facilitation of B5G networks and services. Moreover, we also provide a summarized conclusion of all the key aspects which we will be discussed in this section.

a: What is a DLT?
A distributed ledger is a type of distributed database that by default assumes presence of malicious nodes. The DLT enables the realization of distributed ledgers through a shared consensus mechanism to establish immutable records of transactions despite failures [55].

b: What is Blockchain?
Blockchain is a DLT realization that enables creation of cryptographically linked and chronologically ordered blocks, containing a certain number of transactions. Bitcoin is the first Blockchain, designed as a public, immutable, appendonly, distributed ledger.
Blockchain is regarded as a disruptive powerful technology that has potential to radically reshape the society and the world economy through decentralized governing structures [56], [57]. The Blockchain idea is captivating because for the first time in human history people from distant locations can securely transact within a massive peer-to-peer network with decentralized/distributed management (i.e., no central authority).
According to [58]- [60], Blockchain is going to be the driving force for the next generation of Internet (i.e. 5G and 6G) and network slicing is fundamental part of it. To fully elaborate the Blockchain as a DLT integration with network slicing in later sections, this section first presents the Blockchain's history, fundamentals, taxonomy, consensus mechanisms. Later, we unfold the application smart contracts and the Distributed Applications (DApp) paradigm. Finally, we go through the leading openly available platforms.

A. HISTORY OF BLOCKCHAIN: AN OVERVIEW
In 2009, after the Financial Crisis of 2008 [61], Satoshi Nakamoto published the Bitcoin paper [62]. Despite the initial idea of creating an open source peer-to-peer electronic cash system that would avoid double-spending attacks, the outcome produced a disruptive technology [63]. Satoshi Nakamoto combined encryption and distributed computing in a unique way to assist a network of computers in collaborating towards maintaining a shared and secured database. Nakamoto generated the genesis block and mined the initial bitcoins, giving birth to the cryptocurrency era. Satoshi Nakamoto is a pseudonym for the person or group of people that design and built the Bitcoin. The identity of Satoshi is a mystery to date [64]- [66].
Bitcoin's popularity began to increase in 2011. Soon, technologists realized that Blockchains could be used to track other things besides money. In 2013, 19-year-old Vitalik Buterin proposed Ethereum. The idea of smart contracts was initially introduced by Nick Szabo [67]. This marks a new milestone in the evolution of Blockchain technology, often referred to as Blockchain 2.0 [68].

B. FUNDAMENTALS OF BLOCKCHAIN AND ITS WORKING PRINCIPLE
The key strengths of Blockchain are founded on its verifiability and tamper-proofness. To understand how Blockchain achieves its key characteristics, in this section we describe its building blocks and how the Blockchain works.

1) Blockchain building blocks
The main components to implement a Blockchain are: • Peer-to-peer network: A Blockchain is constituted by Blockchain nodes that are inter-connected in a peer-topeer network. When a new Blockchain node is setup and initiated, first connects to the peer-to-peer network, and once it has established a connection to at least one node, it starts the syncing process. This consists of downloading all the blocks of the Blockchain, till the latest block. Once a node is in full-sync, it can actively participate in the Blockchain. The Peer-to-Peer network is critical for Blockchain technology, as a base layer (similar to IP layer for Internet). In a centralized system, there is a high risk of single-point failures (SPOF) or denial of service cyberattacks [69]. In a Blockchain instead there is no central authority to set the rules making it a decentralized network. Information is continuously recorded in appendonly fashion, and an identical copy is transferred and stored between the nodes. • Blockchain address: Each user of the Blockchain needs a unique Blockchain address. A Blockchain address is a password protected and has asymmetric keys (private and public key-pair). Users issue and authorize transactions by signing them with the private key. The public key is used for receiving transactions. More precisely, the Blockchain address represents a hash (SHA-256) of the public key. In Bitcoin, a pay-to-public-key-hash (P2PKH) script is used, where the Bitcoin address is a unique 27-34 alphanumeric characters long hash identifier [70]. • Transaction: Every transaction is a new and unique record exchanging value or data between two Blockchain addresses or entities. It has an origin and recipient Blockchain address. The issued transaction is added to a pool of unconfirmed transactions -a collection of signed transactions ready to be added in a block [71]. • Block: A block is a structured collection of multiple transactions. Each block contains a block header and a list of transactions. The block header contains: (i) a hash of the previous block, (ii) a hash of all listed transactions in the block, (iii) a nonce, (iv) a timestamp, (v) the difficulty, as explained in detail below. The list of transactions in a new block is populated from the pool of unconfirmed transactions. The miner is in charge of the process of block creation, and blocks are appended to the Blockchain after consensus is achieved, as it will be better described later. It is important to note that participants can explore the Blockchain data/transactions back in time to the genesis block (Block 0) thanks to the hash of the previous block. In this way each block points back to the preceding block creating a chain of blocks. • Consensus mechanism: To append a new generated block to a Blockchain a miner needs to follow a consensus mechanism. This is a key procedure that enables immutability, security, and integrity to a Blockchain. A consensus mechanism includes a diversity of advanced cryptographic techniques and mathematical models that define a strict procedure for (i) generating the necessary block headers, and (ii) validating the new block. The VOLUME 4, 2016 consensus mechanism is run by all (peer-to-peer) nodes participating in a Blockchain network [72]. Satoshi Nakamoto proposed a Proof-of-Work (PoW) consensus mechanism to regulate nodes/participants in Bitcoin [62]. The consensus algorithms dictate the overall performance of a Blockchain (We discuss them in more details in Section III-D1.). • Hashing and hash functions: A hash function takes any (data) input and produces a finite output of a specific size. The process of applying a hash function to data is called hashing, and the output of a hash function is called a hash. The essential feature of a particular hash function is the size of the output it produces. Essential for preserving structured, manageable and secure Blockchain data is through a hash algorithm with a data structure known as a Merkle Tree. This is a method to structure data that enables a large body of information to be verified accurately and efficiently [73]. • Timestamp: Each block in Blockchain is timestamped.
Timestamps prove chronological order of blocks and transactions, representing the time of each recorded transaction. These tamper-proof timestamps serve as a notary service that prevent occurrence of doublespending transactions [74]. • Nonce: It is the number that a miner node has to guess in order to successfully mine a block. It is mainly used in a PoW-based Blockchains, such as Bitcoin. A nonce is an arbitrary whole number, which is 4 bytes field. The combined hash of the desired Nonce and the block header of a new block should produce a result with leading "zeros", depending on the difficulty. For example, if the difficulty is 1, the combined hash (block header + nonce) should produce a result of single zero leading hash (0x0...). In case that the difficulty was 2, the combined hash should be double zero leading hash (0x00...), and so on. Thus this result is easy verifiable by the rest of miners, running the consensus algorithm. The found hash is added to the hashed block [74]. • Smart contracts: At the most basic level, smart contracts are programs that run independently on top of a Blockchain. They have been introduced by Nick Szabo [67] and contain immutable deterministic code, the creator's Blockchain address and cannot be modified by anybody, not even by their creator. The benefits of smart contracts are most apparent in business collaborations, in which they are typically used to enforce some agreement so that all participants can be sure of the outcome without any intermediary's involvement [75]. This concept is essential for designing frameworks or distributed applications, thus we discuss it in detail in Section III-D2.

2) How Blockchain works
Since we introduced the basic building blocks, in the rest of the section we focus on how a Blockchain generates a new  Figure 3 shows how Blocks are chained together and the information they contain. The figure represents a chain of three blocks.The first block is different as it can not contain the previous block's hash, and is called the Genesis block. Every Blockchain is instantiated or starts with a genesis block. A genesis block is created or mined by a single node, usually the node of the Blockchain's creator. Once a genesis block is created, all nodes of the Blockchain start to compete for a block creation. The rules of the competition are defined by the consensus mechanism. A Bitcoin block creation, can be summarized as follows: • A node collects limited number of transactions from the pool of (pending) transactions • A node populates all the necessary block headers, especially the hash pointer to a previous block and the hash of all included transactions (or the Merkle root). • A node competes to win the consensus. If it wins, the generated block is appended to the Blockchain. In case it does not win the consensus, the transactions are released (or unlocked) back into the pending transactions pool. Tampering the information in the second or any of the following blocks (in Figure 3), modifies the resulting hash. As a consequence, there would be no match in the following blocks, making all the subsequent blocks invalid. As a result, all nodes in the Blockchain can not validate the modified block and discard it. An attacker can only succeed if it controls at least 51% of nodes in the Blockchain network.
The data that is stored inside a block depends on the type of Blockchain. For instance, in Bitcoin, a transaction contains: Sender A sends bitcoins to Receiver B. Hence the transaction data consists of information regarding the sender, the receiver, and the amount of transferred bitcoins (tokens). Note that Bitcoin-capitalized refers to the first Blockchain technology created by Satoshi Nakamoto [62]. While bitcoinlowercase refers to the token or (cryptocurrency) used to transfer different amounts between users.
The continuous creation of new blocks in Bitcoin using the PoW consensus mechanism is called mining.

b: How mining works
The active nodes in a Blockchain such as Bitcoin are referred as miners. They are accountants which record every transaction to the Blockchain. Mining involves creating a hash of a block of transactions that can not be easily forged, protecting the entire Blockchain's integrity without the need for a central system [76]. From a high-level (user) perspective, the concept is simple; a proof of payment is essential if a person wants the payment to be valid. The miners are the ones who keep the record of all the payments. Mining is typically done on a dedicated computer [77], as it requires a fast CPU and higher electricity usage, and more heat generated than typical computer operations [76].
To mine a block, the miner collects a batch of transactions, creates a block and generates all block headers, as mentioned previously. The last step for the miner is to guess or find the proper nonce. The mining process is a simple brute-force generation of random nonce. The right nonce hashed with the block header hash should produce a result with a specific number of leading zeros. The mining difficulty or the number of expected leading zeros is modified by the consensus algorithm. In this way the consensus algorithm can control the block creation time when new powerful computing devices are joining the Blockchain network as miners. For example, in Bitcoin the block creation time is around 10 minutes, and in Ethereum is around 13 seconds [78].
Once the miner brute-forced a proper nonce, records it in the block header and broadcasts the block on the Blockchain network. Note that multiple miners may generate a block at the same time, but only a single block is elected as the winning block that is appended to the Blockchain. The winning block is the block that is first validated by at least 51% of the miners/nodes in the Blockchain network [62].
The miner that mined the winning block is awarded with bitcoins to the miner's coinbase address. The amount of bitcoins or the mining reward depends on the block height. The mining reward is reduced by half every 210 000 blocks. For example, on 11 th of May 2020 for the 629 999 block, the miner received 12.5 bitcoins, whereas for the next block (630 000), the miner received 6.25 bitcoins. The reduction of mining reward for Bitcoin is known as bitcoin halving [79]. According to calculations, it is expected miners to receive rewards up until year 2140 [79].

C. TAXONOMY OF BLOCKCHAIN
Different types of Blockchain are available. We focus on the three major types: (i) public, (ii) private, and (iii) consortium. We take a closer look at each of them, discussing their features and mapping them on Table 2.

1) Public/Permissionless Blockchain
Public Blockchains are highly decentralized, are accessible to everyone and rely on active network nodes. The first Blockchain in the form of Bitcoin, created in 2009 by Satoshi Nakamoto [62], it is a public Permissionless Blockchain. Facilitating auditability is one of the benefits of using Blockchain technology and permissionless Blockchain allows public auditability. Nowadays, most public Blockchains run PoW consensus mechanism to maintain trust, immutability and security. We discuss consensus mechanisms in-depth in Section III-D. To encourage users in participating as active nodes (e.g., miners in Bitcoin or Ethereum), the network rewards block creators with a finite amount of tokens (e.g., bitcoins, ethers) for each block created.
An utterly public Blockchain with open-source community models is designed to leverage expertise from many diverse people worldwide and use a broad-ranging user base to have supreme decentralization. Public Blockchains are criticized for the vast amount of computational power required to support a distributed ledger at a massive scale. Other concerns are associated to the transaction approval frequency and to the confirmation delay [80]. The performance of other consensus than PoW, like Delegated Proof-of-Stake (DPoS) or Proof-of-Staked Authority (PoSA), running on public Blockchains is significantly higher. For example, they produce 1 block every second, compared to 1 block every 10 minutes [24] provided by PoW.

2) Private/Permissioned Blockchain
Private Blockchain or permissioned Blockchains are only accessible by a limited number of admitted participants as it follows a partial decentralization technique. A private Blockchain has a organization entity (e.g., the Blockchain creator or several members) which manages the Blockchain. Every new user requires an access invitation issued by the governmental entity. Frequently, enterprises or companies deploy private permissioned Blockchains. In this way they are able to define specific access and operating constraints to the user, making the auditability restricted. Enterprises or companies using private Blockchain can keep the autonomy limited. Additionally, the private Blockchains come with the possibility of immutability. Implicitly, these systems are not highly centralized, and often employ less computational demanding consensus mechanism (e.g., Proof-of-Stake), allowing for higher transaction throughput or more frequent block creation [81], [82], which leads to better performance compared to public Blockchain. [82].

3) Federated/Consortium
A federated or consortium Blockchain is a permissioned and group-owned system where individual autonomy is removed, and instead, permissions are vested in a group of companies or individuals. In other words, the consortium Blockchain is a system that is "semi-private" and has a controlled user group (as in a company); however, it works beyond various organizations. Moreover, consortium Blockchain vs. private Blockchain is a sweet-spot between fully open, decentralized and fully centrally-controlled systems. There is more likely to be a trusted consensus, as multiple organizations have a stake in the outcome [83]. Consortium Blockchains have restricted audibility and only selected nodes have autonomy to validate new blocks, which makes them not completely immutable. Moreover, the transaction approval frequency is shorter than that of public Blockchain and offers a higher performance level [84]. VOLUME 4, 2016  In conclusion, federated/consortium Blockchain offers the same benefits provided by private Blockchain: productivity and privacy of transactions. However, it gives the combined advantage of separating the consolidation of power only to a single company. This realization of a Blockchain network is ideal for an organizational collaboration. Table 2 summarizes the type of decentralization, suitability, autonomy, immutability, transaction approval frequency, and overall performance.

D. EXISTING TECHNOLOGIES TO ENABLE BLOCKCHAIN-BASED INTEGRATION
In this part of the section, we highlight the existing Blockchain-based solutions for integration, including supporting platforms, consensus algorithms, smart contracts, and other solutions currently available.

1) Consensus Mechanisms
We have established that a Blockchain is a decentralized peer-to-peer system of nodes with no central authority figure.
The decision about what node to add next is achieved by reaching a consensus among all Blockchain nodes for the next block to be added. The procedure of reaching a consensus is referred to as "consensus mechanisms". It is a key element that provides immutability, trust, transparency and security of a Blockchain. We already discussed how consensus is reached through mining in Bitcoin (Section III-B2b).
A consensus is a compelling way of getting an agreement in a group. Here, we strive to highlight some of the consensus mechanisms including which are being used by some of the frameworks including PoW, Practical Byzantine Fault Tolerance (PBFT) and RAFT. We also discuss other popular consensus mechanisms i.e., Proof-of-Stake (PoS) and Delegated Proof-of-Stake (DPoS) as well. In the following, we discuss their potential and their drawbacks. Moreover, we draw a conclusion based on the power they consume, their fault tolerance, scalability, transmission rate, node management, transaction finality, and throughput.
In Table 3, we compare these algorithms based on node management (i.e. the need to know each node/miner in the network), transmission rate, energy consumption, scalability, transaction finality (i.e., a guarantee that past transactions can never change) and fault tolerance.
A PoW is a consensus algorithm in which it is costly and time-consuming to produce a piece of data. The most famous cryptocurrency, Bitcoin is using the Hashcash proof of work system.
Although the original Hashcash idea was to battle against email spammers, Satoshi applied this idea to bitcoin transactions. To add a new block into the chain, miners have to complete a PoW to verify all the block transactions, as already described in Section III-B2b.
A miner has to finish around 10 21 computations to find the correct number, and it takes approximately 10 minutes to find the valid number. For a hash function, Bitcoin is using the SHA-256 hash algorithm [90]. The SHA-256 gives a distinctive result if anything changes in a block of text validated. If any transaction is modified, the result will not be the same, and everyone will be aware that the modified transaction is not valid.
However, PoW has its limitations. It has low transaction rate and (currently) consumes tremendous amounts of electricity and computer power. PoW is stated to have 50% fault tolerance with 100 transaction per second. Furthermore, now, roughly 50% of Bitcoin hash power is originating from a few mining pools. This means that only a few people have to meet at the same desk to agree on the 51% attack [85]. BFT is the property of a system that can resist the failures derived from the Byzantine Generals' Problem [95]. This means that a BFT system can continue operating nominal even if some of the participating nodes fail or act maliciously. Applied to Blockchain, this approach rules out validations from malicious nodes in the Blockchain network [16].
PBFT aims for high performance (e.g., high transactional throughput, low latency, etc.), and high execution time. The nodes in a PBFT permitted distributed system are sequentially ordered, with one node being the primary/leader, and others the secondary or the backup nodes. The purpose behind PBFT's technique is that all legitimate nodes assist in attaining a consensus concerning the nature of the system employing the majority rule. The rational of the operation is that the maximum number of malicious nodes must not be more than or equivalent to one-third of all the nodes in the system.
As the amount of nodes increases, the course shifts to a more secure state. For this, there are four phases; sending a request, broadcasting, performing the request, and finally, the request is sub-served successfully when the client receives  [88]. Table 3 shows that PBFT has private node management and has a high transmission rate with approximately <2000 transaction/sec. PBFT also consumes lower energy. However, its scalability is weaker. It suffers from <33% voting power attack, follows absolute finality and faults tolerance rate of 33%.
c: RAFT [89] Raft aims to make a model that is easier to understand. In Raft's states model, each node can stay in any of the three states: leader, candidate, or follower. The distributed system will remain operational, even if one of the servers fails. The employed leader-election mechanism is the remote procedure calls (RPC) to request votes and sync-up the cluster (using Append Entries). Consequently, the load of the calls does not fall upon the leader node in the cluster. It has a certain degree of fairness i.e, any node can be a leader. However, there is a high possibility that Raft is strictly a single Leader protocol, and in case of extreme traffic, the system can become overwhelmed. RAFT has private node management and has overall a medium transmission rate and energy consumption. However, it has weak scalability and fault tolerance of 50% with the throughput of <10k transactions/sec. A PoS validator can generate (mint) or validate a new block with a probability equal to the Blockchain tokens/coins it holds. PoS minimizes PoW's rivalry by granting authority to upgrade the Blockchain to a randomly chosen stakeholder. PoS, like PoW, pays validators a clear monetary incentive, known as a block reward, for updating the Blockchain. However, unlike PoW, PoS does not require validators to pay a direct monetary cost (such as the one incurred by solving PoW's puzzle) to obtain the authority to update the Blockchain. In particular, PoS algorithm makes a pseudorandom-selection process to pick a node to be the validator of the subsequent block, based on a combination of various Blockchain specific variables or processes (e.g., token stak-ing) [96].
Blockchain peers who desire to compete in the forging process are expected to secure a certain number of coins into the network as their stake. The size of the stake defines the possibilities for a node to be elected as the next validator to produce the next block -the more significant the stake, the higher the chances [86].
However, to prevent favoring the wealthiest nodes, multiple strategies are available, among them two most commonly used methods are "Randomized Block Selection", and "Coin Age Selection". In the Randomized Block Selection scheme, the validators are chosen by studying for nodes combined with the most profound hash-value and the most eminent stake. The Coin Age Selection method determines nodes based on how long their tokens have been staked [72]. Many people, however, are suspicious of PoS's longterm sustainability because they believe it would struggle to achieve consensus.
PoS has partial node management. However, it has a medium transmission rate. Table 3 compares PoS with PoW and other consensus algorithms and shows that PoS has lower energy consumption. Also, it offers strong scalability. However, it comes with <51% stake tolerated power. PoS follows probabilistic-finality, 50% fault tolerance and performs <1000 transaction/sec. DPoS) is a consensus algorithm developed in 2014. In DPoS, the consensus is achieved through an electoral process. In this process coin holders choose their delegates by votes, and these delegates are responsible for validating new blocks. Additionally, these delegates are also called witnesses. The witnesses or delegates are rewarded for adding blocks to the Blockchain. In DPoS, each participant has several votes depending on the number of parts it has. Or they can choose to delegate the value of their stake in favor of another participant in the network. Moreover, under reasonable conditions and depending on the implementation, delegates usually take a turn in block production every few seconds [72].
In comparison to PoW, DPoS offers better performance. As 3 illustrates that DPoS follows partial node management and has higher transmission rate. Moreover, by eliminating intense competition between miners, DPoS is energy efficient. This solution also promotes decentralization; however, the higher the delegated, the lower the network speed [87]. It also depicts strong stability features, although it comes with the possibility of <51% validator attack. DPoS follows Probabilistic-finality and fault tolerance of 50% and can perform <1000 transactions/sec. The idea of Proof of Activity (PoA) stems from the combination of PoW and PoS. PoA aims to use this hybrid approach to generate new blocks to take advantage of PoS and PoW and tries to provide a more efficient algorithm [97]. The mechanism of PoA goes through two phases before a completely new block is added to the Blockchain. The first phase uses the practice already known from PoW in which miners compete against each other to solve a complex task to generate a new block for the Blockchain. Once that block is generated, the system moves to the second phase, i.e., PoS., where participants are randomly selected from the network. Once all the selected validators sign or confirm the block, the process will complete, and a new block is added to the Blockchain [98].
PoA can offer a good security level and low overhead. It does not require much storage space, either. However, it suffers from a computationally-intensive process. Also, PoA based networks may lack decentralization. A PoA-based Blockchain can have only a limited number of validators, which may not be democratically selected [99]. Table 3 provides a comparison of PoA with others. PoA has private node management with a medium transmission rate. However, it suffers from high energy consumption but it has strong scalability. Also, PoA has immediate transaction finality with 51% fault tolerance. Participants burn their currencies to generate new blocks in the Proof of Burn (PoB) consensus technique. PoB validators burn coins by sending them to an irretrievable address [91]. Miners may burn the native currency or Bitcoin, depending on how the PoB is implemented. The more coin a validator burns, the more chances it will be selected.
PoB is an alternative consensus algorithm that attempts to address the high energy consumption issue of a PoW system. PoB is often called a PoW system without energy waste. While PoB is an alternative to PoW, the protocol still wastes resources. Also, it is questionable that mining power goes to those who are willing to burn more coins [100]. Table 3 illustrates a comparison of PoB. The node management of PoB is public. The transaction rate is high, but PoB does have high energy consumption. The scalability is medium and has a fault tolerance of 51%. PoET uses a lottery method that distributes winning possibilities evenly among network participants, ensuring that every node has an equal chance of winning [101]. The PoET algorithm assigns each node in the Blockchain network a random wait time, and each node must sleep for that duration. The first node to wake up will add a new block to the Blockchain.
The PoET workflow is similar to Bitcoin's PoW. However, it consumes less power. Nevertheless, PoET is highly dependent on Intel technology and suffers from interoperability issues [102]. Table 3 shows a comparison of PoET with other consensus algorithms. The node management of PoET is permissioned. The transaction rate is medium for PoET and also consumes less energy. Lastly, as it follows the PoW, the scalability is strong. The PoA is scalable, as it relies on a limited number of block validators. Further, blocks and transactions are verified by moderators, pre-approved network participants. Therefore, PoA can be a solution for corporations as it can support private Blockchain applications with higher throughput [93]. Table 3 shows the comparison of PoA with the rest of the consensus algorithms. PoA can be private, with high transmission rate and throughput. PoA is also has good scalability and less power intensive.

j: Proof of Capacity
Proof of capacity (PoC) allows mining devices in the network to use their available hard-drive space to validate transactions. This is different from using the mining device's computational power (as in the PoW) or the miner's stake (as in the PoS). Instead, PoC authentication systems use leftover space on a device's hard-drive to keep solutions to a cryptocurrency hashing problem [94].
In PoC, a larger hard-drive equals more possible solution values to be stored. In simple words, it will result in a higher chance that a miner has to match the required hash value from its list, consequently in more chances of winning the mining reward. However, PoC has adaptability issues, and it is vulnerable to malware attacks [103]. Table 3 illustrates the comparison of PoC where it shows that it is public and decentralized. Also, the transmission rate is lower, although it has strong scalability.

2) Decentralized Applications (DApps) and Smart Contracts
Besides the tools used in Bitcoin, a Blockchain can also use other tools, such as smart contracts and DApps. a: What is a Smart Contract Smart contracts are self-executing, deterministic and Turingcomplete code that runs on top of a Blockchain. The smart contracts self-execute predefined and deterministic actions when specific conditions correlated with negotiated transactions are met [104]. The smart contract idea was introduced by Nick Sazbo in 1994 [67].
The input parameters and the execution of a smart contract is precise and objective. In other words, if "x" happens, then execute "z". Smart contracts are stored on the Blockchain with an assigned Blockchain address. A smart contract execution is automatically triggered whenever a transaction is sent to a smart contract's Blockchain address. The called function is executed on every node of the Blockchain. The output is recorded as a state-transition (e.g., new value assignment to a smart contract variable). Additionally smartcontracts can issue transactions towards users' Blockchain addresses or other smart contracts. Note that the smart contract function execution is atomic, which means it is either executed fully or not executed at all. The most emblematic Blockchain supporting smart contracts is Ethereum. In the context of Ethereum, smart contracts run on top of the Ethereum Virtual Machine (EVM) as part of the Ethereum network protocol (i.e., on the decentralized Ethereum world computer). In Ethereum, Solidity is a JavaScript-like language developed for writing Ethereum smart contracts. Solidity compiles this code into bytecode, which is deployed on the Ethereum Blockchain as a special contract creation transaction. A successfully deployed smart contract is assigned with a unique Ethereum address.
To prevent mis-usage (e.g., spamming, infinite loops, etc.), for every function executed, a finite amount of gas is spent. In Ethereum, a gas is calculated as the product of gas usage and gas price. The gas price follows free-market policy based on the network activity (e.g., busy network, higher gas prices), expressed as a small fraction of the main token -ether. Gas usage is unknown prior to execution [105]. A user must specify the maximum amount of gas, it is willing to pay for a full-execution of a smart contract function. The more complex the smart contract, the more gas is used to execute it. If during execution the maximum amount of gas is exceeded, the execution is reverted, without affecting the state of the smart contract. As a result, gas currently acts as an essential gate to prevent overly complicated or numerous smart contracts from overwhelming the EVM [106]. Smart contracts allow for various agreements' terms and conditions to be fully accessible and visible to all the relevant parties. Once a deal is established, there is no way to dispute it. Additionally, automated contracts attempt to sidestep the pitfalls associated with manually filling out heaps of forms, and the speed can save countless working hours compared to traditional business methods [104].

b: What are DApps
DApps are applications that can be mostly or entirely decentralized. There are various advantages of DApps over a centralized architecture. Centralized applications operate on a central server, which implies a single point of failure and a single government & management entity. On the other hand, the decentralized applications distribute the risk to different entities, which favours resiliency, transparency, and censorship resistance. A DApp is usually a web application using an open-source software platform, which interacts with a smart contract on a decentralized Blockchain. A fully decentralized DApp is structured similarly to a common web application, based on front-end and backend code. The main difference is that the backend is minimal, containing an application API. Smart contracts are used to store the business logic and the application state. The design of DApps aims to lower the smart contract execution or the application state transitions, manly due to the fact that the computation executed in a smart contract is expensive [107]. Previously, DApps were referred to as applications used as media sharing protocols like BitTorrent. Later new DApps have been built on top of BitTorrent. Ethereum, as the first Blockchain offering smart contracts, allowed the emergence of the first DApps interacting with EVM. Another example is EOS.
• Ethereum for DApps: The Ethereum platform along with the Web3 Javascript API libraries 1 , allows for simple development of DApps and integration within most of the open source web platforms. The first step in creating a DApp is to develop a smart contract using the Solidity language 2 . The smart contract is uploaded on the EVM, and later executed by the decentralized Ethereum network. Finally a front-end web application is enabled to interact with the uploaded smart contract through the web3.js library. Numerous DApps have been created using Ethereum, including games, gambling apps, exchanges, marketplaces, and many more [108]. • EOS for DApps: The other platform which is competing with Ethereum is EOS. EOS offers a virtual machine and authorizes the execution of any deterministic language inside the VM sandbox. EOS gives the DApps developers the freedom to use the preferred development stack inside the VM and ensures the network's flexibility. Moreover, the EOS platform aims to address the scalability and flexibility concerns faced on Ethereum. EOS's capability to freeze and rollback transactions have decreased the community's confidence lately and gained high criticism [109].

3) Platforms
The demand for Blockchain development platforms increases, as different sectors are exploring numerous applications based on Blockchain. Some of the widely used Blockchain platforms are further discussed. We also discuss new Blockchain platforms as well.  [108]. Ethereum allows the code to be written to control the transmission of numeric values based on programmable conditions. Ethereum was conceptualized through a white paper published in November 2013 by Vitalik Buterin, and with additional contributions from his seven co-founders and other developers. The network was launched in June 2015 to extend the use-cases supported by Bitcoin [110].

b: Hyperledger Fabric
Hyperledger is an open-source collaborative effort designed to advance cross-industry Blockchain technologies, and it is a permissioned Blockchain. The architecture of Hyperledger is modular and it enables components, i.e., ledger, consensus mechanism, and membership services, to be plug-and-play. [111], [112]. The permissioned nature of Hyperledger allows organizations to define specific peer isolation through the use of channels. The smart contracts referred as chaincode run in a separate container at a specific channel. The workflow is not common as in Ethereum. Unlike Ethereum, the nature of Hyperledger opens a risk for execution of a non-deterministic chaincode [113].

c: Corda
Corda is a, open-source, permissioned and private enterprise Blockchain. It has been supported by important companies like Amazon, Intel and Microsoft. Lately, it has opened its gate to nearly every industry by providing a private network for enterprises as well [114]. Corda does not allow peers to share information like Ethereum. Corda introduces legal footing and assured identity feature as well. Moreover, this is a massive performance boost, as linear horizontal scalability can be achieved due to not having all data shared with all network members.

d: Quorum
Quorum is a private/permissioned, Blockchain-based implementation of the Ethereum protocol. It uses a votingbased consensus algorithm and obtains data privacy by introducing a new "private" transaction identifier. Compared to Ethereum, it adds improved permission management and better privacy. One of the most significant benefits of using Quorum is its high performance. Quorum can carry out more than 100 transactions per second, which outperform both Bitcoin and Ethereum [115].

e: MultiChain
MultiChain is an open-source platform for private Blockchain, based on Bitcoin [116]. MultiChain allows users to customize many parameters, including chain anonymity, maximum block size, and mining incentive. A group of identified block validators performs the mining. Each block has only one validator, scheduled in a round-robin fashion. The latest MultiChain 2.0, introduces Smart Filters, a feature that allows custom rule coding for transaction validation [117].

f: EOS.IO
EOS is a BFT and DPoS consensus based Blockchain which offers smart contracts implementation. In comparison to Ethereum, EOS performs higher transaction rate [118], producing a block every 05 sec. The DPoS is based on 21 unique block producers that agree on strict block order creation [119], the producers are voted by token holders. The chosen 21 block producers remain for at least 126 rounds or blocks, where each elected producer generates at least 6 blocks for the elected period. The collaborative nature of the block producers is positive for avoiding potential forks, but it reduces the decentralization of the Blockchain.

g: Tendermint
Tendermint is an application-based Blockchain with a default BFT consensus [120], [121], which enables users to turn any deterministic application into a Blockchain application through the use of the Tendermint BFT state-machine replication. In particular, an application is adapted to use an Application BlockChain Interface (ABCI) in order to communicate any state-transition in the form of transactions to the Tendermint Blockchain.Unlike Bitcoin, Tendermint adds blocks through voting of validator nodes.

h: Cosmos
Cosmos is a network of many Tendermint Blockchains joined in a single Blockchain with a global transaction ordering [122]. It is an upgrade of Tendermint with the goal of enabling inter-operability between different applications realized as Tenderemint Blockchains [123]. It is useful for specific use-cases such as Decentralized Exchange (DEX) [124]. The mechanism for enabling the inter-communication is referred as Inter-Blockchain Communication (IBC).

i: Polkadot
Polkadot is a Blockchain framework created by one of the Ethereum co-founders -Gavin Wood [125], which aims to tackle the scalability issues of common Blockchains (e.g., Bitcoin, Ethereum) [126]. Its framework is organized into a scalable multichain. The organization of nodes is hierarchical and is based on (i) a single relay-chain, and (ii) a large number of parallelised sidechains -parachains -able to communicate among themselves through the relay chain. Polkadot uses Nominated Proof-of-Stake (NPoS) consensus mechanism [127]. At the time of writing, Polkadot has not been fully rolled out for performance evaluation.
To conclude this section, Table 4 summarizes all the key aspects we have discussed so far for the different presented platforms.

IV. INTEGRATION OF DLT/BLOCKCHAIN WITH NETWORK SLICING: MOTIVATION AND PROPOSED ARCHITECTURES
B5G and future 6G networks are expected to be increasingly complex and will need an adaptive and intelligent architecture based on improved SDN, NFV and network slicing concepts in order to facilitate the network management operations [128]. On the other hand, a recent report discussing 6G vision and requirements [129] includes Blockchain as a DLT as one of the key technology to facilitate automation and management in future networks. Specifically, recent studies have proposed to merge the network slicing and Blockchain concepts for multiple purposes, since the Blockchain offers the opportunity to create an automated marketplace, where the network slices and their services can be negotiated. Additionally, Blockchain also offers E2E performance auditing opportunities among all involved actors in various complex scenarios, e.g., multi-tenancy or multiadministrative domain. In this section, we summarize the motivation behind the current research to use Blockchain platforms to handle the management of network slicing, in order to foster automation, organize/configure networking or VOLUME 4, 2016 computational resources, while delivering trust, privacy, and transparency.

A. MOTIVATION: THE ROLE OF BLOCKCHAIN/DLT AND SMART CONTRACT IN THE MANAGEMENT OF NETWORK SLICING
Network slicing success strongly depends on the involved provider's capability to offer an adequate set of solutions tailored to specific needs/requests of various sectors, including but not limited to verticals end-user, tenants and other MNOs. The different industrial verticals are characterized by specific challenges, which the provider needs to fulfill in order to support their clients. In this subsection we go through the different motivations that generate new opportunities for the merge of network slicing and Blockchain concepts.

1) Open marketplace
With the introduction of virtualization technologies, NFV has generated a new market focused on the offer and distribution of VNFs. The notion of an open and decentralized marketplace where to store, advertise, purchase and compare services or resource offers is absent in the 5G concept, but has appeared in many new NFV related contributions. An open marketplace is a significant component of the advertisement and publication of the developed services from different service providers, adding diversity in network services and virtualization. Service and infrastructure providers can benefit from this open market by having real-time assets offers, requests and automated payment settlements [130]. Service and infrastructure providers can also take advantage of the open market by providing their infrastructure, resources, VNFs, to fulfil end user's demands. The demand for the marketplace to be more flexible is increasing, and it is expected to be able to support on-demand agile businesses [131].
Similarly, in network slicing, any network request can be served by combining available VNFs as network slices. A marketplace for network slicing enables end-users like Mobile virtual network operator (MVNOs), Over the Top Provider (OTTP), industrial vertical players to request and lease resources from infrastructure providers that create predefined, differing levels of services for different clients by customizing their requirements. Solutions that promote the competition between providers can reduce prices while increasing network performance to accommodate specific user's demands.
In this context, the need for trust/security between buyer and providers drives the need to integrate DLT because it can redefine the interaction and provide a safe environment for negotiation of resources with its features like consensus and immutability [132]. Ultimately, a decentralized marketplace's role is to introduce an economic plane for exchange of services, VNFs, or resources among service providers by promoting trust and transparency. Therefore, to create telecom infrastructure marketplaces, efforts towards Blockchain-based marketplace are on the rise [133]. For example, IOTA 3 is one of the participant working on "Blockchain-based Telecom Infrastructure Marketplace" catalyst project with TM Forum 4 .

2) Discovery and selection for offered services
An NFV market, which includes the offering, distribution, and execution of VNFs, opens up opportunities for service providers to offer VNF. However, the research on models to efficiently host, audit and improve revenue by introducing market competition can be improved. An auction mechanism can help choose the right infrastructure candidate to host a requested service. Auction mechanisms from economics are transferred and applied in network slicing, and resource allocation [134]. In this direction, a Blockchain-enabled system based on smart contracts helps address the challenge of discovering and selecting offered VNFs and services. As it can be employed to provide immutable and permanent records that allow interested parties to audit and trust in the data ,this has motivated some of the proposed studies, which will be discussed later.

3) Security
We have already discussed how 5G (through network slicing) supports a wide range of new network services from heterogeneous VNFs. In NFV, security weaknesses have been identified in the integrity of VNFs and network services; new challenges have been identified about incorporating trust among end-users. Similarly, network slicing solutions must ensure the main security principles, traditionally categorized into confidentiality, authentication, authorization, availability, and integrity [135]. Ensuring isolation between network slices is essential to avoid common attacks in shared infrastructures. The multi-tenant and multi-domain environment increases the possibility of attacks inside the cloud. The use of Blockchain as a DLT can implement security for building a trust mechanism between different infrastructure providers. DLT can be a reasonable solution to establish an authentication layer for the multi-administrative domain to satisfy the security principles [21]. For instance, DApps for multi-administrative domains enables transparency on identity and permission management for NFVIaaS providers and consumers [12]. Furthermore, Smart Contracts may be used as a mechanism for access control when they execute all the access information (e.g. user credentials) and record it in a distributed ledger. This is elaborated in the latest publication by ETSI PDL [136], which may serve as a guide to prevent future disputes.

4) Smart resource management
The complexity of network management with an increase in users and the lack of spectrum in 5G/6G networks requires capabilities to automate the critical processes involved in network operation. Hewa et al. mentioned that the resource management operations require to be compatible with the large infrastructures [58]. Blockchain technology aims to offer advantages to enable decentralized solutions that ensure the integrity and immutability of the information stored and traded. For instance, [137] presented a Blockchain-based solution that allows providers to trade their processing and networking resources. Also, [138] depicts a smart resource management where a Smart Contract is triggered whenever there is a request for resource allocation.

5) QoS monitoring
Smart Contracts can provide mechanisms for network service provisioning or service allocation, including accountability. The service contracts and their SLAs and QoS can be deployed in the Blockchain through Smart Contracts. This can prevent future disputes and provides audibility. For instance, [139] present a distributed SLA management with Smart Contracts and Blockchain creating distributed cloud offering dynamic services and promoting reduced costs for cloud consumers. Additionally, the service contracts from all operators can be advertised on DApps backed by Smart Contracts and stored in a distributed ledger. The publication on Permissioned Distributed Ledgers (PDL) Smart Contracts System Architecture and Functional Specification by ETSI [136] discusses the complete possible scenario in detail.

6) Automation of operational savings
Another advantage of applying a Blockchain to network slicing is the savings in coordination among consumers and providers for transaction costs. Since a Blockchain provides a platform for negotiations that is trustworthy, it enables automatic agreements so that the slice negotiation process is accelerated, and consequently, the cost of the individual network slicing agreement is reduced [59].

7) New business-model-driven network services
Network slicing naturally involves interactions among stakeholders. As a result, it is essential to create network services able to co-exist with the new business models to improve profit for providers and better experience and cost-effective solutions for the consumers. SLAs between users and network slice providers are required for these business-modeldriven network services. For this purpose, record-keeping Blockchain is used as an authoritative log mechanism for recording and keeping track of final transactions. This allows reduction of conflicts among involved parties [56].

B. REVIEW OF PROPOSED ARCHITECTURES
In the literature, the integration of Blockchain and network slicing concepts has already been explored in different contributions [140]- [150]. In this section we analyze the literature. We aim to spotlight the main features that enable and enhance the integration of Blockchain with network slicing.
We divide the proposed works that interact with network slice stakeholders (as consumers or providers) via NFV MANO frameworks or a Blockchain. These frameworks, can be divided into two main groups as follow: • Blockchain and smart contract-based network slice broker, where we discuss the frameworks integrating Blockchain using network slice broker. A network slice broker act as an enabler for MVNOs, OTTPs or vertical market players to request and lease resources from service providers. We further discussed with details about its components in IV-B2 • Blockchain and smart contract based, where the proposed works introduce Blockchain-based components in their frameworks which are further discussed in IV-B3. Additionally, for clarity the different types of interactions that can happen between stakeholders can be further categorized. The interactions are grouped in: • Vertical-to-provider • Provider-to-provider We start by introducing the network slice stakeholders, i.e., providers or consumers. Then, we go through the architecture summarizing the different contributions in literature, and finally, we elaborate on the different interactions.

1) Stakeholders
We have introduced in Section II-C different stakeholders that interact, negotiate or exchange information in order to deploy E2E network slices. They can be divided into two roles: • Providers • Consumers A single stakeholder may have both roles.

a: Providers
According to 3GPP [151] the Communication Service Provider (CSP) is an entity that provides communication services, and the CSP consumes Network Slice Provider (NSP) services. In the same manner, a provider refers to any entity that provides a service to another entity in terms of infrastructure (e.g., network resources) or Network-as-a-Service (NaaS). According to [152] Infrastructure providers (InP) are able to provide computational and network resources to external entities (or consumers) in order to be used by different network slices. In [145], [147], [149], the term InP is used in similar manner, while Nour et al., in [148] use the term "resource provider". MNOs can take both the InP and NaaS providers roles for example in [146]. Furthermore, the works in [143] and [141] describe interactions between different service providers (e.g., MNOs) to exchange services where they can have both roles, consumer and provider roles.

b: Consumers
The term consumers refers to several entities that consume network slices, or VNFs, for example in terms of a marketplace for VNFs. In [153] the Communication Service Customers is defined as a consumer of services offered by VOLUME 4, 2016 a service provider. Keller defines in [140] the consumer as a customer which acquires VNFs via a web application portal (the front-end), to a Blockchain-based Trusted VNF Package Repository. The authors in [145] also use the concept of generic marketplace where a provider can list their services and the consumer can access this marketplace via the userinterface. Authors in [147] use the term tenants for the consumers of network slices [154]. The concept of a tenant is defined by [152] as that of "consumers acquiring a slice to orchestrate and run network functions within it to provide a certain service to their customers". To accommodate the needs of growing industrial vertical tenants, the authors introduce a Blockchain-based Intermediate Broker (IB), enabling InPs to allocate network resources among tenants.
The ETSI Permissioned Distributed Ledger Industry Specification Group (PDL ISG) has recently released several reports [136], [155], [156] specifying different applications of permissioned DLT to networking. The group categorizes different stakeholders (e.g., end-users, platform operators, infrastructure vendors, regulatory and governance authorities)in [155]. Additionally, it defines three different ICT vertical families: 1) compute vertical, 2) connectivity vertical and 3) storage vertical. Each vertical family leverages on Permissioned Distributed ledger -PDL or permissioned Blockchain to consume or provide different network services or slices.

2) Blockchain and smart contract-based network slice broker
According to [157] the business interactions among stakeholders are mainly focused on (i) support of business-tocustomer (B2C) model, where the consumer acquires customized network resources based on its requirements without considering which provider provides the requested resources, (ii) support of business-to-business (B2B) model, where the provider sells customized network resources to enterprises which control their resources and (iii) support of Businessto-Business-to-Customer (B2B2C) model, where a network slice broker plays an intermediate role and engages with the consumer. In this manner the broker gets more control of the network.
Currently, in the literature the works in [145]- [150] introduce the idea of a Blockchain-based broker, which facilitates the trading of network slices, by benefiting from the introduction of Blockchain. Among the possible tasks of the network slice broker there is to create a generic marketplace to trade VNFs, to lease network slices, the billing management, or the management of auctions to choose the appropriate service providers. This brokering layer is referred to intermediate broker and distributed blockchain-based broker in [147] and [150], respectively.
In this direction authors in [145], implement a generic marketplace for VNFs trading between consumer and InPs. The generic marketplace is linked to a smart contract creator and Blockchain Adapter by means of a broker, so that the proposed solution can be used to supply a large variety of services based on VNFaaS. This approach presents a transparent solution via Blockchain in which InPs can compete to host VNFs for each consumer. Hence, it brings fairness and trust to some degree where an auditable auction is performed as there are transparent records about each interaction between provider marketplace and consumer.
The Slice Leasing Ledger, is another concept based on Blockchain is introduced by [146]. In the proposed system, every involved stakeholder (consumer or provider) has its own unique digital keys which can be used to sign and verify transactions. These keys are tightly interconnected to each stakeholder's identity. The aim behind introducing Slice Leasing Ledger is to create the possibility for verifiable transactions which can be used for charging, billing and SLA agreements between consumer and provider. Moreover, with the help of Blockchain, the time decreases during service creation, and it facilitates to perform operations dynamically. Also, the concept for Monitoring and Billing Management is introduced in [147] to handle the QoS monitoring and billing of services. Together with Blockchain technology, the proposed solution can record the various exchanges of resources.
Similarly, the concept of Sub-Slice Brokering is introduced in [148] to manage all the information related to the subslice deployment brokering mechanism in a permissioned Blockchain. The authors introduce a new business entity called "Slice Provider", which aims to select the resources from different resource providers to create E2E slices. The proposed framework integrates smart contracts to deploy the sub-slices. The process starts when the consumer requests to create a network slice using a template or a blueprint. The Slice Provider translates the template to specific slice resource requirements (VNFs, storage, or memory) and generates a contract. Consequently, the integration of Blockchain allows leasing resources from various providers in a secure manner.
Moreover, the determination of the trading price of resources or services is one of the crucial challenges when it comes to network resource leasing [158]. Also, it is not fair to the consumer if the price is solely determined by the service providers, as consumers need a fair and transparent algorithm for pricing in transactions of services. Auction mechanisms traditionally studied in economics, have been proposed for network resource allocation as one potential solution to the pricing selection problem [159]. The auction helps the consumers choose the best provider according to its own utility, while facilitating that service providers increase their efficiency. In this regard, [145], [147], [149] and [150] use smart contracts-based to perform auction mechanisms.The objective of these approaches is to motivate the providers to bid honestly, which helps the consumers understand the information provided on services and prices to achieve more desirable results. Hence, Blockchain can guarantee reliable auditing and enforces policies through smart contracts in a secure and automated manner.
Also, authors in [150] introduce Service Management and Blockchain Entity. The authors propose a bidding scheme through a Distributed Blockchain-based Broker (DBB) to help operators place their bids for resource provisioning to offer the requested service. The above mentioned components (Service Management and Blockchain Entity) are added inside the broker to perform the process of bidding and resource provisioning. The DBB relies on a Blockchainbased system to request resources, evaluate resource provisioning offers, and propose a service management entity. The proposed system, via a Blockchain-based bidding system, aims to provide admission control for incoming requests and minimize the tedious process of setting up a memorandum of understanding.

3) Blockchain and smart contract-based
The works presented in [140]- [144] propose Blockchainbased solutions to achieve different purposes, like the incorporation of trust, the automation of SLA definition and management, or security provisioning to the network slicing management.
The authors in [140] propose a Blockchain-based trusted VNF repository, which uses smart contracts to incorporate trust. This Blockchain-based solution aim to tackle the challenge of VNF integrity verification by leveraging smart contracts properties of immutability and accessibility, where it is possible for a consumer to verify the integrity of VNF packages running on a local virtualization platform and allowing the the provider to automatically receive any payments once a VNF is acquired.
In [141] the authors talk about the concept of Network Slice Manager referred as Slicer. This work presents a multidomain NFV/SDN network, in which each domain has its own NFV/SDN architecture managed with the support of a Slicer on top. In such a scenario when a vertical in a domain needs a service controlled by a different domain Slicer, it can request an E2E slice to its own domain Slicer, and it takes care of the whole slice deployment with the collaboration of other Slicers in different domains through the support of the Blockchain. The authors aim to minimize the deployment time of the E2E network slice, and hence they illustrate through results that the Blockchain can be a solution. Also, authors state that the Blockchain can bring a fair collaboration among various domain owners to deploy different services.
In [142], the idea of allocation of network resources through an Accountable Just-in-Time to support QoS levels is proposed. This module is specifically designed to handle services that can dynamically change, in both time and location. The proposed architecture achieves billing and accountability through smart contracts solution based on SLA with the aim to provide transparency, immutability and automation. The study also suggests that failure to maintain the SLA may result in penalties that can be automatically imposed through the smart contracts.
Furthermore, to enable service federation for service providers to provide network services across multiple domains, in [143], authors encourage the integration of i.e., Blockchain and smart contracts. The idea is proposed to use Blockchain as an opportunity for secure, distributed and scalable federation solution. This solution also involves a singleblinded reverse auction mechanism to help the consumer domain select a provider administrative domain.
Lastly, the work in [144] proposes the Blockchain technology to register all commands that create, modify, configure, and destroy the network functions of each network slice in the form of signed transactions. The authors propose a Blockchain architecture for creating secure network slices tailored for various E2E use case (i.e., eMBB, mMTC, or Industry 4.0). The consumer interacts with the system to acquire a slice and defines the requested slice features, including desired VNFs and the corresponding Blockchain category for desired use-case to address different slice requirements through different categories of Blockchains. The consumer accesses to the system with a user-interface and interacts with the Management Blockchain Server and a Blockchain Creation Server to create secure network slices for various E2E use cases.
We conclude and summarize the above mentioned discussion with the help of Table 5, where we discuss each framework and its details including stakeholders involved, components, mechanisms, Blockchain platform used, smart contract implemented or not, consensus mechanism used.

4) Interactions among stakeholders
As mentioned, the stakeholders can have different interactions among themselves mainly grouped as: (i) verticalto-provider and (ii) provider-to-provider. Specifically, the vertical-to-provider interactions that are using Blockchain can be further grouped into: • OSS/BSS interactions -in this group, the vertical customers are using Blockchain to communicate and exchange information with the OSS/BSS of the service providers. In the evaluated literature, the authors are using OSS/BSS endpoint (e.g., web portal) to request networking services through auction and bidding process [145], [147], [149], [150]. Although some of the works [143], [148] does not directly use the auction and bidding to interact with customers, they do implement the negotiation process. On top of that, in [140], [142] the authors envision the use of Blockchain in order to perform billing and accountability operations between vertical customers and service providers. In short, it means that customers are charged for all the networking services through the Blockchain, enabling the customers for more transparent and extended choice of providers. • Slice-related interactions -verticals use Blockchain or DApps to request to perform slice creation and leasing.
In the works [144], [146], [148], [149] the authors elaborate the process where the verticals are envisioned to request end-to-end slices directly through DApps, specifying the slice requirements. Although they focus on conceptual realization [146], others evaluate the so-VOLUME 4, 2016 lution through Hyperledger [144], [149], and a custom PoW based prototype [148]. On the other hand, the provider-to-provider interactions involve interactions among provider domains via Blockchain, with a common goal to establish end-to-end network slices across multiple domains. These interactions can be grouped into: • Service related interactions -The work in [143] elaborates how NFV MANO administrative domains negotiate and perform federation of network services using Ethereum Blockchain. In [145], the authors discuss how VNFaaS can be achieved with the support of the Blockchain technology. • Resource-related interactions -Besides network services, providers may exchange network resources.
In [141] the authors elaborate how different providers may exchange NFVI resources in order to achieve endto-end network slices.

V. APPLICATION OF DLT/BLOCKCHAIN IN VERTICALS
In the previous sections, we have analyzed how Blockchain can be integrated in the network slicing provisioning process, either between verticals and providers or between two providers exchanging services/resources in peering relationships.
In this section, we analyze a number of vertical industries by focusing on how the Blockchain as a technology is currently used to improve their business logic. At the end of the section we explore how some works have already integrated a Blockchain solution into a network slice. In our view, the application of network slicing with Blockchain will improve current solutions. The goal is for the reader to understand how specific vertical-related problems can be solved through Blockchain technology, which in most cases is deployed within a vertical network slice.

a: Media and Entertainment
The emergence of the Blockchain technology is significantly affecting media and entertainment. As mentioned in Section III, Blockchain brings novelty in the media and entertainment ecosystem. It provides added value to media publishers and content creators, thus shifting the economical benefits more towards the copyright-owners (e.g., the creator can be the copyright-owner of the content, or the publisher has the full ownership) [160]. The impact is measured as disruptive and sustainable [161].
The micropayment channels [162] disrupt the configuration of the ecosystem by allowing content providers and aggregators to be bypassed and shift the power to content creators. Each art piece, song or movie is published on Blockchain-based platforms by the creators/owners and directly sold to the consumers. This disruptive concept referred to as "one-stop shop" model enhances the relationships between the content creators and the consumers. Through the application of Smart Contracts, each created content can be tokenized and its ownership fairly distributed [163]. The distribution of royalty payments is automatized and fairly distributed to each musician.
Also, in the gaming industry, the in-game assets are registered on public Blockchain (e.g., Bitcoin, BitCrystals [164]). Users can trade or exchange in-game assets outside the game. b: AR/VR Vibehub [165] is a combination of a VR and Blockchain platform for creating virtual spaces where a variety of activities can be conducted, from marketplaces to virtual business meetings. Vibehub has 3D photo-realistic in-house holograms (Holoportation) technology that is used for body scanning of musicians and educators. These holograms can be placed in a custom VR or AR environments where users can take part of the experience.
Decentraland [166] is an open-source and a communitydriven platform that simulates a virtual world where users can access with VR devices through a web browser. Decentraland uses a distributed storage paired with Blockchain that holds all the information to recreate the virtual space in the users' devices. Decentraland users can explore the world, consume user-generated content or create their own experiences and offer it to peering users on the platform.

c: Drones
In the Unmanned Aerial Vehicles (UAVs) industry, Blockchain solves issues and challenges related to cybersecurity, air-traffic control and insurance. With drone technology advancements, the information gathered by dronecontrol systems and the drones becomes an attractive target for cyber-attacks. Blockchain can then be used as a defense against the growing threat of cyber-attacks. In [167], the authors focus on the application of Hyperledger fabric to increase the security of networked swarms of UAVs. More specifically, the authors in [168] analyze the current 5G network security solutions and open issues, and propose an application of Blockchain to solve most security challenges. Air traffic control is essential to prevent drones colliding with an aircraft and/or other drones. The increasing number of active drones may lead to potential mid-air collisions. In this context, Blockchain has been proposed to resolve the issue through an air traffic management system based on Blockchain [169].

d: Aviation
Currently, the radar-based air traffic service providers can preserve the privacy of flight plans and position of airplanes, mainly for military and corporate operations. In the US, the Federal Aviation Administration (FAA) adopted in 2020 the Automatic Dependent Surveillance Broadcast (ADS-B), which does not include privacy features, with corresponding implications in terms of potential security issues (e.g., spoofing, denial of service, etc.). In [169], the National Aeronautics and Space Administration (NASA) proposes a Blockchain-based prototype for air traffic management with the goal to mitigate the ADS-B security issues. The framework envisions the use of Hyperledger fabric, as permissioned Blockchain, which would provide a framework that includes certificate authority, use of smart contracts and high bandwidth communication channels for secure communication channels between entities (e.g., aircraft, authorized members).
In [170], the authors propose to replace paper records through the use of Blockchain-based distributed ledgers. The work provides ideas for improving the aviation record management systems through the example of a record flow using a paper record and the advantage of the use of the Blockchain technology. These records present all the logs that are kept regarding flights (e.g., crewmembers records, airplane maintenance records).

e: eHealth
The application of Blockchain technology to the healthcare industry has been subject of numerous reviews in the last years [171]- [175]. The maintenance of medical records using Blockchain is the most anticipated use-case [176]- [179]. The MedRec [180] is one of the early proof-of-concepts that demonstrate the usability of the Ethereum smart contracts to maintain the patients' records over the years or even for future generations. The feasibility study in [181] confirms that permissioned Blockchain can be successfully used for exchange of personal health records. However, its generalized practical use requires numerous modifications (e.g., reduction in records data size) and reduced operational cost.
The work in [182] proposes a light-weight Blockchain implementation for healthcare data management. The work uses customized Blockchain implementation where the adopted consensus approach is PBFT and the main network regulator is the Head Blockchain Manager (HBCM), which acts as a Certificate Authority (CA). The concept relies on the usage of channels, referred to as canal(s), similar to the Hyperledger network. The results show at least 67% increased efficiency or speed in ledger updates.
The healthcare industry is looking forward to the application of Blockchain to battle drug counterfeit. Numerous studies evaluate the Blockchain benefit for tackling drug counterfeit [183]- [186]. VOLUME 4, 2016 f: Automotive The automotive industry is going to be revolutionized by the next generation of communication technologies [187]. The introduction of vehicular-to-vehicular communications introduces a number of security and privacy issues [188]. The application of Blockchain has been proposed as a solution to the security and privacy issues [189]- [191], as well as a solution for trustful collection of vehicle's data [192]. Specifically, to protect trust among all involved parties, Blockchain technology can be applied to counter fraud. Companies, like Bosch, have committed to build a framework to counter fraudulent actors targeting the manipulation of car odometers [193], [194].
The work in [195] explores the application of Hyperledger fabric as a proof of concept to verify and record reports for vehicle-to-vehicle (V2V) messages exchanged in multiple areas. Thanks to the implementation of the Hyperledger solution, the proposed system manages to collect individual reports of received messages from each vehicle in a certain area and to join them in a single distributed ledger for all areas. To improve the authentication, trust and validation in the vehicle-to-infrastructure (V2I) or V2V communication, the work in [196] proposes a new Blockchain algorithm that uses local dynamic Blockchain for keeping local information of the events that are happening in a given region, and a main Blockchain that keeps track of the global events. Each vehicle in a certain region is authenticated through a unique ID. If an unusual event occurs with a vehicle, the event is directly reported to the main Blockchain.

g: Logistics & Supply chain
From the logistics and supply chain perspective, the Blockchain technology is seen as a disruptive technology that will change the way industry operates. Stakeholders in the supply chain eco-system expect a major impact in increased efficiency, transparency and reliability. The authors of the work in [197] conducted a survey on social media to measure the acceptance of the Blockchain technology applied to the logistics and supply chain industry. The findings reveal that most of the companies understand the positive impact of Blockchain over the logistics industry. However, companies are more hesitant to devote significant resources in developing Blockchain applications.
The work in [198] aims to overcome the adoption fear and to design a strategy to design, develop, validate and integrate a Blockchain solution in a logistic and supply chain business strategy. The authors present a case study of fresh food supply chain deployed with Hyperledger Fabric. The results show that the implementation of Blockchain solutions is highly sustainable and is completely covered by the savings. The most critical issue is that the Blockchain should be adopted by all involved actors. The work in [199] proposes a decision framework for the logistics industry based on using a quantitative approach. The framework is applied on a large-scale logistics company where the findings suggest a range of important criteria for Blockchain applications (e.g., security, visibility and audit) and a range of feasible logistics operations where the Blockchain can be applied (e.g., transportation, materials handling, warehousing, order processing).

A. LIMITATIONS OF CURRENT WORK a: Applicability
Blockchain is a technology which offers many opportunities, but also at a high implementation cost. As a result of that, it is important to identify the areas of applicability which obtain the highest benefits for the costs that are to be paid. Not to pay attention to this initial design phase may make Blockchain more a source of problems rather than a solution. The authors of [200] provide a step-by-step chart of how one should evaluate if a Blockchain would be an appropriate solution to a given problem or use-case. Consequently, while implementing Blockchain applications, the decisions need to be well planned, and Blockchain applications must keep in mind the network effects it will have while delivering value to consumers. Furthermore, identifying the business case and primary drivers cost of implementation are some of the issues that need to be considered beforehand [201].

b: Adoption and complexity
According to [202], there are three categories of factors that abate the adoption of the Blockchain technology: (i) technological factors; (ii) organizational factors; and (iii) environmental factors. The study conducted in [202] focuses on the organizational factors and argues that the biggest adoption factors for a company are the top management, the organizational readiness and the size of the company. Other studies suggest that the Blockchain makes positive adoption steps in the business and industry sector. According to Deloitte´s annual report on Blockchain [203] around 55% of the companies included in the survey study confirm that Blockchain technology is in their top-five strategic priorities. Around 80% of the respondents believe that the Blockchain technology will be widely used in the future.

c: Blockchain Scalability
The Blockchain scalability is a known problem [204]. With increasing number of users or full-nodes in the Blockchain network, the activity and transactions grow drastically. Each new added node, needs to synchronize the Blockchain (e.g., download all the transaction history -more than 1 terabyte (TB) in the Ethereum Blockchain) and start actively participating in the Blockchain network. When a Blockchain grows significantly, the synchronization process is slow and newly joined nodes take time to start actively participating in the network, which results in poor scalability performance. In [126], the authors evaluate these limitations and explore the current solutions to solve the scalability problem in the most widely adopted Blockchains, as Bitcoin and Ethereum.
For the network slicing application, the scalability issue should not be a problem. With the assumption that the number of operators is not more than few thousands (e.g. 3 to 5 operators per country) [205], any Blockchain network (permissioned or permissionless) is not expected to expand as much as the Bitcoin or the Ethereum network. However, if many new stakeholders emerge in the eco-system, beside the mobile operators, the use of a public or a widely adopted permissioned Blockchain may be at risk run into the well known scalability issues, which then need to be taken into account in the design of the network.

d: Energy efficiency
The mainstream view is that Blockchain is one of the major existing energy consuming technology [206], and the numbers are still growing [207]. The analysis in [208] suggest that even maintaining a private or permissioned enterprise Blockchain is significantly more energy inefficient than a non-Blockchain (e.g. centralized) solution for enterprise. The same study suggests that the sustainability of the Blockchain application mainly depends of the design solution. For example, minimizing the on-chain activity can significantly increase the energy efficiency of the Blockchain application. From a networking operator or service provider perspective, depending on the number of nodes running over the local infrastructure, the application of Blockchain technology for network slicing might increase the impact on the operational expenditures (OPEX). At the same time, the automation introduced by the Blockchain can reduce the OPEX on other aspects.

e: Storage
Once a Blockchain is set up and running, the ledger begins to grow recording all the transactions and verified blocks. The storage of a Blockchain can significantly increase if the Blockchain itself allows for big files to be stored on-chain. The overall recommendation is not to store any data onchain (e.g., size in the order of megabytes) [209]. For this reason, significant effort has been recently put to provide distributed off-chain solutions in projects such as Storj [210] and Sia [211]. Recently, with the emergence of the Interplanetary File System (IPFS) [212] in combination with the Blockchain technology promising solutions have been proposed in the area of P2P sharing systems for storing off-chain data [92], [213]- [216]. In network slicing applications, the storage issue mainly depends on the design solution. Specifically, it is important to keep low the on-chain data shared among all participants in the Blockchain network.

B. FUTURE RESEARCH DIRECTIONS a: Global service footprint
The implementation of the Service federation and resource sharing (described in Sec. IV-B) opens a range of opportunities for global collaborations between different service providers and/or stakeholders. Potentially, all operators and service providers can be interconnected in a single permissioned Blockchain. Through the use of service federation feature, the operators and service providers can offer a new range of on-demand services to vertical industries on global scale. With the use of Blockchain technology, the full potential of the network slicing may be extended from a single domain to a global scale, in an automatic and agile manner. By enforcing the SLAs through smart contracts, the reliability of the offered global services can be significantly increased, as well as Blockchain-powered integrated payas-you go charging. Research on how to automate these federated scenarios through the use of Blockchain and the combination with Artificial Intelligent is overall and exciting new area of research. Projects such as 5G-Transformer [37] and 5Growth [54] have studied the possibility to provide mobile network operators the capability to offer Network Slice as a Service (NSaaS). The work in [217] breaks down the NSaaS business model, orchestration and management. From a customer point of view, the NSaaS feature allows the customer to request an on-demand network slice to satisfy the network requirements to monitor an agricultural area [218], or to provide connectivity for a big sporting event [219]. Usually, the customer chooses a template from a catalog of offered slices, that are adjusted according to the needs of the customer. Each mobile network operator has its own catalog of slices that is offered to customers. Joining the catalogs of all mobile operators would create a single-point of access or a marketplace for NSaaS [220]- [222]. By deploying the marketplace on a Blockchain [223] (e.g., as a DApp), the marketplace can have a distributed nature that can potentially overcome all the challenges mentioned in [221]. Research in this area is still widely open and require significant efforts also at implementation levels.

c: DApps widespread
According to [224] there are around 3750 deployed DApps on all the platforms (e.g., Etheruem, Tron, EOS, etc.) with around 200 000 users per month. By mid-2020 [225], the major increase of Decentralized Finance (DeFi) projects emerge along with a new smart contract token standards (e.g. ERC 1155), and these standards help ensure that the smart contract achieves composability. For instance, newly issued token remains compatible with decentralized exchanges already existing. This indicates that the DApps usability and user adoption is slowly increasing. With the introduction of Digital Asset Modeling Language (DAML) [226], [227], a user-friendly programming language for creation of DApps and DLT solutions that is enabling simple set-up of a private Blockchain network without entailing all the setup complexity over certain infrastructure. In our view, the combination of DAML and network slicing (platforms) may open a range of opportunities for research and application of DApps as part of network services or increase the general public usage of DApps. VOLUME 4, 2016 d: Blockchain and AI The Blockchain technology can enhance the AI or viceversa, the AI can enhance the Blockchain applications [16], [17]. From a network slicing perspective, the deployment of distributed AI applications is beneficial for life-cycle management of deployed network slices. Combined with monitoring information, the distributed AI applications can decide per slice different strategies to maintain the SLAs and employ different strategies [228]. e: Theoretical characterization of the Blockchain in network slicing scenarios Blockchain operation has been modeled in the literature in multiple ways at analytical level. In this area, tools that are gaining importance are the batch service queuing and the Markov processes [229] [230]. It is important to study the scenario and application of interest also at theoretical level (in our case, the network slicing one) in order to properly design the Blockchain network so that all the limitations previously discussed can be successfully handled. Aspects which can be theoretically evaluated are the design of the Blockchain in terms of optimal block size, optimal dimension, optimal distribution of information to reduce fork events, etc. An example of this kind of studies, to analyze the stability of the Blockchain and the delays introduced in the provision of service in telecom scenario is the work presented in [231], where a batch queue model allows the analysis of the delay introduced by the Blockchain as a function of the block size, the forks and the timeouts. More work in this area to further understand the theoretical models of the Blockchain in network slicing scenario are of great interest.

f: Introduction of Blockchain in Next Generation Architecture
With the purpose to pursue openness and automation in mobile networks, novel architectures for the RAN, based on NFV capabilities are being standardized and require further enhancements in the area of Blockchain to promote its inclusion for automation of procedures like RAN sharing and security purposes. Some preliminary works in this area can be found in [232] [233].

C. LESSONS LEARNED
The above discussion lists the current literature, including applicability issues lack of adaption factors including technological, organizational, and environmental. We also discuss the scalability challenges of Blockchain and high energy consumption and storage limitations.
Lastly, many potential research directions were then identified, including global on-demand service offers and novel business models such as NSaaS. We also highlight that DAML integration with a network slicing platform can open various opportunities for research and applications of DLT-based applications. In addition, we have mentioned that Blockchain and other domains such as AI can benefit from each other specifically for the life-cycle management of deployed network slices. We also discuss the theoretical models of the Blockchain in network slicing scenario, and Blockchain introduction in next-generation architecture (novel architecture for RAN based on NFV capabilities) are potential research directions.
Finally, realizing the potential of Blockchain technology, specifically in network slicing or generally in future networks, requires a framework for design and implementation that begins by thinking first about areas where there is a need to improve security, transparency, or trust among the stakeholders-then followed by consideration of the Blockchain architectures, protocols and other technical considerations to deliver the necessary capabilities.

VII. CONCLUSION
In this paper, we have reviewed the current state-of-the-art related to the use and applicability of Blockchain features for network slicing. In particular, we have started by introducing the network slicing concept and important related literature, and then we have introduced the main concepts in a tutorial fashion in the areas of Blockchain, DLT and smart contracts. We have discussed how we believe that Blockchain technology can enhance and solve key issues related to network slicing. In this context, we have surveyed the available literature in the area of Blockchain integration with network slicing and also how vertical industries are using it on top of the deployed slices.
Our literature review shows that adopting DLT for network slicing is still in its infancy.
Overall, this analysis has shown that Blockchain holds a lot of promise in contexts where multiple stakeholders (or administrative domains) are involved, such as when deploying an End-to-End (E2E) network slice. And this is increasingly relevant in 6G networks, given their increasing complexity.