End-to-end network slice architecture and distribution across 5G micro-operator leveraging multi-domain and multi-tenancy

Abstract

Local 5G networks are emerging as a new form for 5G deployment, targeting service delivery for vertical-specific purposes and other local users. These networks are also known as micro-operator networks for which prior work has established different deployment scenarios, namely Closed, Open and Mixed Networks. To achieve network flexibility, customization and privacy required by various vertical sectors, such as industry, health and energy, it is essential to have a well-defined network slicing architecture and adequate implementation procedure. In this paper, a sophisticated end-to-end network slicing architecture is proposed for different deployment scenarios of the local 5G micro-operator concept. The proposed architecture incorporates a broad four-layer concept, leveraging a multi-tenancy layer for different tenants and their end users, a descriptive service layer, a multi-domain slicing management and orchestration layer, and a resource layer. We further propose a network slice instance (NSI) communication service distribution technique for local 5G micro-operators. This is achieved by expanding/leveraging the communication service management function in the multi-tenant layer into a multi-tenant manager and an orchestrator of communication services. In addition, we describe how the communication service orchestrator will address all the possible multitenant-slice situations during the distribution of a network slice instance to multiple tenants. The novel methods described in the paper present a solution for not only network slice communication service distribution across different micro-operator’s tenants but also for future use cases, especially, when the allocated slice is responsible for multiple tenants or when a tenant requests multiple NSIs.

1 Introduction

The concept of local 5G network deployments, also known as 5G micro-operators, has emerged to allow different stakeholders to deploy their own networks apart from the existing Mobile Network Operator (MNO) networks [1, 2]. The operations of the local 5G micro-operator network are targeted at vertical specific services [3], thus, providing network customization, flexibility, and isolation as requested by the use. In order to efficiently describe the new micro-operator network deployment model, authors in [4,5,6] have proposed different scenarios including Closed, Open and Mixed networks. The Closed micro-operator network, also described as a vertical specific network provider [7] or a private network, is targeted at the humans/machines present within a closed user group. The Open micro-operator network on the other hand is targeted at serving subscribers from one or more MNOs within a locality. The mixed network combines both the capabilities of the open and closed micro-operator networks. Different micro-operator deployment scenarios are presented in [4,5,6] to cover a variety of use cases that can be deployed by different stakeholders, such as facility owners and network infrastructure vendors. These use cases present new business opportunities allowing the local player control the whole connectivity solution and all data within the premises, opening the market for new business models. For example, the closed micro-operator network is targeted at verticals with specific tailored services and network requirements which can require specialized expertise outside of the MNO experience, hence benefiting from the new local 5G micro-operator network deployment model.

Generally, 5G micro-operator networks are expected to be deployed with network slicing. Network slicing defines the means of logically and carefully isolating network capabilities from a “one size fits all” to a set of different network slices where each slice is responsible for responding to specific network requirements (i.e., eMBB, uRLLC and mMTC slices) [8, 9]. A study carried out in [9, 10], shows that while network slicing is available to increase network customization and provide tailored network services for various end users, it also presents a new form of revenue generation for operators, lowering Operational Expenses (OpEx) and efficiently managing the Capital Expenditures (CapEx), based on the number of slices that can be created. To ensure better network delivery for vertical specific services considering deployment costs, it is not economically feasible for stakeholders to deploy a separate end-to-end network for different verticals. Hence, having a local micro-operator network the services of which are sliced over different tenants can become a promising deployment model and provide tailored network services for the verticals.

For realizing a complete end-to-end network slicing across a micro-operator network from the moment when a slice is requested to the moment when the slice is allocated, we need to understand not only how the network slice instance (NSI) is created across the access and core networks, but also how the created NSIs will be distributed across different tenants based on their deployment scenarios or use cases [11]. Basically, to activate a network slice across a tenant’s end-users, 3GPP [8] introduced the CSMF as part of the management functionalities required for network slicing after the network slice management function (NSMF) and the network slice subnet management function (NSSMF). The NSSMF is responsible for managing and orchestrating different network functions (NFs) to make up the network slice subnet instance (NSSI) or the network service (NS), and the NSMF is responsible for managing and orchestrating different NSSIs to form the NSI (i.e., eMBB, uRLLC or mMTC slice instance for differentiated services). The CSMF on the other hand is responsible for aggregating and translating different slice requests and distributing the created NSIs to the required tenant’s end users as a network slice communication service.

However, even though the implementation of the NSSMF and the NSMF have been achieved to some extent by specific open source bodies such as Open Source MANO (OSM) [12], the implementation of the CSMF for the distribution of created NSIs to a tenant’s end-users is still yet to be solved. This is an extensive research area especially in use cases where the NSI is responsible for multiple tenants or when a single tenant is requesting multiple NSIs.

2 Method/experiment

In this paper, we propose a novel technique by which the network slice communication service will be transmitted and distributed across multi-tenants, considering different micro-operator deployment scenarios. To achieve this, we present a novel 5G network slicing architecture targeted at different deployment scenarios of a 5G micro-operator leveraging the concept of multi-domain and multi-tenancy. The slicing architecture is broadly divided into four layers to enable proper management and orchestration of each layer. These layers include the Service layer (for operation and business support (OSS/BSS) and policy control), the Slicing MANO layer (to cover NSMF and NSSMF implementations using OSM), the Resource layer (for virtual resource allocation, management and orchestration using ETSI NFV), and the Multi-tenant layer (for implementing CSMF slice request aggregation and slice instance distribution).

The proposed architecture will enable us to leverage the CSMF capability in the multi-tenant layer by introducing a multi-tenant manager and a communication service orchestrator of the slicing architecture to cover all possible multitenant-slice situation types that can exist. The multi-tenant manager handles the CSMF responsibility of aggregating and translating network slice requests from different tenants, the communication service orchestration is responsible for the distribution of the created slice request to different tenants based on the distribution of slices over different tenants. These include Situation 1 where one NSI distributed to one tenant; Situation 2 where one NSI is distributed across multiple tenants; Situation 3 where Multiple slice instances are to be distributed to a single tenant; Situation 4 where Multiple slice instances are to be distributed to multiple tenants.

The remaining part of this paper is arranged as follows. Section 3 presents a comprehensive study on the existing work related to local 5G micro-operators and their deployment scenarios, different network slicing architectures, and slice instance distribution. The proposed end-to-end network slicing architecture for a micro-operator network covering all the deployment scenarios and leveraging multi-domain and multi-tenancy is presented in Sect. 4. In addition to the network slicing architecture, the generic technique for network slice communication service distribution across different multitenant-slice situations is presented in Sect. 5. The concluding section contains a general summary of the work ironed so far and the possible future directions.

3 Existing work and literature review

The literature review is divided into four parts. These include the existing work on micro-operators and their deployment scenarios, previously proposed 5G network slicing architectures, existing work on network slicing with relation to a micro-operator network, and finally the work carried out on network slice instance distribution.

3.1 Local 5G micro-operators and their deployment scenarios

The idea of locally deployed 5G networks is to complement traditional MNOs’ networks [3]. The local 5G micro-operator network model, depicted in Fig. 1, has been proposed [2, 13] in order to serve the location-specific needs of various verticals and their tenants. In that case, each vertical is made of different tenants that will be allocated a network slice based on the service requirements of the tenants’ end users.

Fig. 1

General micro-operator model [11]. This figure describes the overall model for a 5G micro-operator network considering all key elements such as the end users, tenants, verticals, and the micro operator network operator

In general, a micro-operator network can be deployed as a Closed, Open or a Mixed network [1, 4, 5]. The closed micro-operator network [4, 5] aims to provide communication services to tenants whose users present a closed user group that corresponds to a private network. The authors in [4, 5] have defined closed micro-operator network to be deployed in two scenarios, depending on the location of the tenants and the network. These include, closed Deployment A and Deployment B [4]. Closed Deployment A represents a micro-operator network whose tenants are at a single location while Closed Deployment B represents a micro-operator whose tenant are at different locations and their connectivity can be established via an external communication network.

An open micro-operator network [4, 6] on the other hand can be deployed as an MNO open or Public Open network. While the Public Open network is targeted at offering network services to unregistered public subscribers just like a public Wi-Fi, the MNO open is targeted specifically for MNO subscribers within a locality. The MNO open micro-operator is responsible for serving MNO subscribers within a micro-operator network in localities where the MNOs aren’t willing to deploy efficient network services. Financial analysis according to authors in [14], shows that MNOs are reluctant to deploy their networks over areas with few customers; hence a micro-operator network can be responsible for subscribers of different MNOs by allocating a separate slice for a set of subscribers from each MNOs. This will be beneficial for both MNOs and micro-operators. The number of MNO subscribers that will be covered under one slice of a micro-operator network will be determined by the service level agreement (SLA) between the micro-operator and the MNO.

Finally, the mixed micro-operator network [4] entails the functionality of both the open and closed networks by serving customers from both cases with a defined level of isolation between them. The mixed network can be deployed in a situation where a micro-operator is providing network services for a vertical and also responsible for MNO subscribers within the area. Due to the relationship between the micro-operator network and the MNO in a mixed network, two deployment scenarios can exist: Option A and Option B. Option A refers to a scenario where the micro-operator is in need of network resources from the MNO network for wide area access such as getting content from faraway servers, roaming scenarios for tenants at different locations (e.g., multi-site operations) and remote monitoring. Option B refers to the situation where the MNO network needs access to the micro-operator network to serve its subscribers within the micro-operator, very similar to the MNO open network. However, in this case, the micro-operator is responsible for both vertical tenants and MNO subscribers. So, the MNO will be using the micro-operator broadband service to extent the indoor coverage within the vertical. A descriptive diagram representing the three deployment scenarios that can exist for a micro-operator can be seen in Fig. 2.

Fig. 2

Micro-operator deployment scenarios [4]. This figure describes in details each micro-operator network deployment scenarios that can exist. This include the Open, Closed and Mixed micro-operator

3.2 5G network slicing architecture

Network slicing is the mean to logically create network slices, such that each slice is responsible for specific network requirements. Over the years, several standard bodies and different commercial organizations have contributed to defining network slicing and numerous network slicing architectures have been proposed.

(1) From the perspective of standard bodies: The Third Generation Partnership Project (3GPP),¹ the main standard body for mobile communication network, defined the required network slice functionalities to achieve an end-to-end network slice [8, 15]. 3GPP introduced the NSMF which is responsible for creating the NSI, the NSSMF which is responsible for creating the NSSI, and the CSMF which is responsible for transmitting the communication service to users. 3GPP also defined the concept of shared subnet either between two NSSIs or between two NFs. The Next Generation Mobile Network (NGMN) alliance [16] proposed a three layer model in defining network slicing. The layers include the service instance layer, the network slice instance layer and the resource layer. NGMN further defined concepts such as service instance, network slice instance, and network slice blueprint. ITU-T-2020 network framework [17] proposed an architecture to support diverse service requirements by ensuring enough end-to-end network softwarization leveraging existing tools such as SDN/NFV. ITU-T-2020 framework introduced the concept of having multi access technologies with an agonistic common core network that will separate the control plane and the user plane ensuring extensive and independent scalability and flexibility of the network slice. Open Network Foundation (ONF), [18] defined how the SDN architecture will enable a common infrastructure that will efficiently support multiple client network instances. ONF thus introduced the SDN controller client context that will provide an abstraction for network resources while supporting control logic for constituting a slice. ETSI [19] defined a network slice as a graph of network functions (i.e., physical and virtual network functions (PNFs and VNFs)) that are connected together to build the end-to-end network service with specific network requirements and capabilities. ETSI approach is based on how network slicing will be supported based on the ETSI NFV architecture [20]. Furthermore, ETSI proposed the concept of Zero-touch network and Service Management (ZSM)² for achieving full end-to-end automation of network services functionalities and management. While this concept is vital for a full automated end-to-end deployment of network service, it is important to have a well-defined slicing architecture for a micro-operator network, afterwards the network functionalities and can be automated to achieve the proposed design for targeted tenants and end users leveraging ZSM.

(2) Based on research projects: Different research projects have also proposed architectures and end-to-end implementations of network slicing. The 5G SONATA project³ introduced the flexible programmability of network software while developing an orchestration framework for service development purposes. The project developed a Software Development Kit (SDK) component that supports service developers. The 5GEx project⁴ expatiated more on the concept of multi-domain network service orchestration. The proposed architecture in the 5GEx project introduced a Multi-domain Orchestrator (MDO) that exposes the service specification APIs, thus allowing tenants to give their specific requirements under the same administrative domains. 5G Slicenet⁵ project [21] introduced the concept of cognitive multi-domain network slicing. The proposed architecture is divided into two broad domains, the advanced managed domain that will include the infrastructure, service and control layer which are based on existing descriptions, and the innovative management domain which extensively describes the management and orchestration of the network slices based on cognitive operations. The 5G PAGODA project [22] introduced a scalable and sophisticated architecture while extending the existing NFV architecture to suppose different slices across multiple vendor VNFs. This concept extends towards offering an architecture to support multi-domain slicing and federated resource control, introducing the concept of multi-domain service conductor stratum for managing network slices across federated domains [23]. The 5G Transformer project [24] proposed a 3 level architecture that supports federated slicing across multiple domains, the vertical slicer, the service orchestrator and the mobile transport, and the computing platform. The 5GNORMA project [25, 26] introduced a reference architecture with four layers which are the data layer, the control layer, the management and orchestration layer, and the service layer. The 5GNORMA architecture further introduced three SDMs; the Software Defined for Mobile Network control (SDM-C) in the dedicated control layer functions to manage resources assigned to a network slice, thus, every network slice has a SDM-C in the control layer; the Software Defined For Mobile Network Coordinator SDM-X in the common control layer functions to manage the shared resources across different network slices; and the Software Defined for Mobile Network orchestrator (SDM-O) serving as the interface between the infrastructure and the business domains.

(3) From the perspective of open source bodies: Different open source management and orchestration frameworks are also available for the implementation of network slicing. The ETSI Open Source MANO (OSM) [12], is a project that aims to produce a reference implementation technique leveraging the existing ETSI NFV-MANO architectural framework [20], and focusing on the Management and Orchestration (MANO) layer. OSM is open to supporting a wide range of Virtual Infrastructure Managers (VIMs), NFVIs, VNFs, NSs and network slices. Thus, OSM is a management and orchestration tool that manages the life-cycle of resources, virtual machines or network slices. OSM proposed two implementation techniques for network slicing, the Full E2E management also called the Integrated Modeling and the Standalone Management also called the Vanilla NFV/3GPP. The Full E2E management is done in such a way that the network slice can be treated as a meta-Network service. This is to say that the reference ETSI-NFVI architecture is leveraged, where the slicing management functionalities (i.e., CSMF, NSMF, and NSSMF) and the NFVO act like the full Operation and Business Support Systems (OSS/BSS) layer. With this method, the VIMs see these layers as just another service layer that gives information for resource selection. The Standalone Management on the other hand separates the Slicing MANO from the entire OSM ETSI NFV MANO. Thus, the network slice functionalities (i.e., CSMF, NSMF and NSSMF) form a separate standalone body that is connected with the ETSI OSM MANO using the Vanilla interface. The OSM approach is leveraged in this paper for the proposed architecture of network slicing in a micro-operator network with additional improvements. Figure 3 illustrates the ETSI-NFV reference architecture, the Full E2E Management, and the Standalone Management.

Fig. 3

ETSI NFV-MANO framework and OSM slicing implementation technique [12]. This figure presented the ETSI NFV-MANO framework that is used to described network virtualization and the OSM slicing implementation technique. The OSM slicing implementation can be the full E2E management for network slicing and the Standalone management for network slicing

In addition, the Open Network Automation Platform (ONAP) project [27] by Linux foundation is aimed at building a comprehensive and sophisticated NFV implementation framework for a real-time automation of VNFs. Part of ONAP’s future work is to input network slicing automation into their framework. The OpenBaton project [28] is aimed at implementing the ETSI NFV-MANO framework. The architectural implementation supports network deployment over multiple cloud computing platforms. The NFV Orchestrator (NFVO) in the OpenBaton architecture which serves as the core part in resource instantiation and service creation. In relation with the Network Slice Engine, they can be used together for the effective implementation of network slicing. Finally the OpenStack Tacker project by Openstack [29] is focused on building an Open orchestrator for the management of VNFs. OpenStack Tacker uses the Topology and Orchestration Specification for Cloud Applications (TOSCA) language in the VNF catalogue for meta-data definition. The TOSCA language [30] is used to standardize how applications are described in terms of interaction between IT service developer and operators.

3.3 Network slicing description for a 5G micro-operator

Even though the network slicing architecture and implementation for a micro-operator network has not been widely defined yet, some initial work has been laid down in terms of network slicing description for micro-operation deployment scenarios. These works serve as the foundation to the proposed architecture in this paper. The NSI configuration types that can exist for each deployment scenario of a micro-operator are defined in [4]. The NSI configuration types are based on the 3GPP network slice description [4, 8], and they are used to describe how network slicing can be achieved for each deployment scenario of a micro-operator network. According to [4], the NSI configuration types (i.e., Type 1, Type 2 and Type 3) are based on leveraging the concept of shared constituents between NSSIs and NFs within a micro-operator network or with an external network, to determine the type of services each deployment scenario can offer. Type 1 is targeted at tenants with strictly low latency requirements and as such, the slice instance is formed with no shared constituents between either the NFs or NSSIs.

Type 2 is targeted at tenants with less latency requirements, such that the slice instance is formed with shared constituents of NSSIs or NFs between tenants within the same micro-operator network [32]. Type 3 [31] involves slice instances where there can be shared constituents of NSSIs or NFs between the micro-operator network and the MNO network. Type 3 is available for tenants that require external network resources for services such as wide area access, remote monitoring and roaming. Figure 4 describes the NSI configuration types for various deployment scenarios of a micro-operator network.

Fig. 4

NSI configuration types for micro-operator deployment scenarios [4, 31]. This figure show the mapping of different NSI configuration types for each deployment scenario of a micro-operator

3.4 Network slice instance distribution

The idea of having a network slice distributed across different tenants is an important branch of achieving an end-to-end network slicing. Generally, whenever a virtualized slice instance is established across the radio access network (RAN) and core network (CN), it is paramount to direct the communication service from the established slice to a tenant in a dynamic and efficient way throughout the lifecycle of the slice. It should be noted that the distribution of established network slices is always prone to the use case that can exist and thus, different use cases require different approaches for their slice instance distribution. To achieve multi-tenancy slice distribution and resource allocation, authors in [33] introduced the concept of 5G network slice broker to facilitate on-demand resource allocation to each tenant and perform admission control based on monitoring and forecasting. The 5G network slice broker resides with the network provider or the infrastructure provider, where all the required interfaces and functionalities are detailed. However, the approach in [33] only introduced the idea of a multi-tenancy in network slicing without the actual implementation technique on how different NSIs will be transmitted across different tenants. To further support slice distribution across a multi-tenant situation, authors in [34] introduced the concept of having a multi-tenant NFV MANO that will be responsible for resources management and orchestration at the tenant level. The MANO as a Service (MANOasS) is proposed as an extension of the existing ETSI NFV-MANO model [20], by leveraging the virtualization abstraction of the ETSI NFV-MANO to the tenants layer. This is described as the Tenant MANO (t-MANO). Thus, the t-MANO will ensure that each tenant has the capability to manage and orchestrate its own slice instance provided by the network operator. However, this approach adds lots of complication to the distribution of the slice instance with complete resource orchestration at the tenant’s level. By the way, this approach does not go in-line with the 3GPP standard of CSMF handling the slice distribution to different tenants and their end users. As stated earlier, 3GPP [8] introduces the CSMF functionality for the aggregation of slice requests for tenants and the distribution of slice instances as communication services to diverse tenant's end users. However, even though this functionality is introduced by 3GPP, the implementation technique to support different use cases that can exist in a multiple tenant scenario is not addressed. With regards to the implementation techniques, the current OSM [12] implementation covers only the NSMF and the NSSMF, only two out of the three 3GPP defined network slicing functionalities [8]. OSM [12] uses a layered approach in achieving network slicing based on a virtualized network infrastructure. This is done such that the Virtual Machines (VMs) are the basis of the layers having an image instance in a VIM; multiple VMs described together with the Virtual Network Function Descriptor (VNFD) to form the VNF as another layer; different VNFs are described together with Network Service Descriptor (NSD) to form the NS or NSSI, managed by the NSSMF; and finally different NSSIs are described together with a Network Slice Template (NST) to form the NSI, managed by the NSMF. Thus, the current implementation technique covers the NSMF and NSSMF, without the CSMF, which is responsible for aggregating and translating slice requests and determining how the NSIs will be distributed as a communication service across different tenants and their end users.

4 New end-to-end network slicing architecture for micro-operator deployment scenarios

The previous work on the merits and classification of network slicing for a micro-operator network have shown the importance of having a specialized end-to-end network slicing architecture for each deployment scenario for a micro-operator. Other reasons for establishing a new architecture for micro-operator network include the following:

• There are different deployment scenarios, and each deployment scenario within a micro-operator network supports different use cases. As such, the implementation of network slices is dependent to the deployment scenarios, thus it is important that an individual architecture addresses the type of micro-operator network, be it closed, open or mixed.

• The architecture also shows a better and simplified description of the 3GPP defined network slicing functionalities (i.e., NSSMF, NSMF and CSMF) in terms of how orchestrators and managers can be used to achieve these functionalities for an end-to-end network slicing in a micro-operator.

• The architecture is targeted at supporting the concept of multi-tenancy in describing extensively how the communication services from the NSI will be distributed across end users within the micro-operator network.

As highlighted earlier, by leveraging the network slicing management functionalities, we can achieve multi-domain and multi-tenancy across an end-to-end network slice. Multi-tenancy describes how a single network resource can be sliced and maintained across multiple tenants, with each tenant having the ability to determine its own network controlling ability [33]. On the other hand, the concept of network slicing across multiple domains involves having a slice instance whose virtualized resources are administered across multiple infrastructures or across multiple providers and it can be achieved by the proper softwarization of a network [35]. Multi-domain resource allocation broadens the capabilities of a network slice and increases its flexibility. Figure 5 shows our simplified description on how network slicing for different deployment scenarios of a micro-operator will be achieved leveraging multi-domain and multi-tenancy.

Fig. 5

Simplified description of multi-domain using 3GPP functionalities. This figure presents a description of achieving multi-tenancy and multi-domain and their importance in network virtualization

4.1 The micro-operator network slicing architecture

The proposed network slicing architecture for a micro-operator as seen in Fig. 6 is divided into four layers. These include the Multi-tenant layer for implementing the CSMF slice request aggregation and slice instance distribution, the Service layer for OSS/BSS and policy control, the Slicing MANO layer to cover NSMF and NSSMF implementation, and the Resource layer for virtual resource allocation, management and orchestration using ETSI NFV. Each of these layers will contribute to achieving the end-to-end network slicing for a micro-operator network. Figure 6 depicts the x.

Fig. 6

The end-to-end network slicing architecture for a micro-operator network. This figure presents one of the main contribution in this paper which is the end-to-end network slicing architecture for a 5G micro-operator

4.2 Network slicing description for a 5G micro-operator

Even though the network slicing architecture and implementation for a micro-operator network has not been widely defined yet, some initial work has been laid down in terms of network slicing description for micro-operation deployment scenarios. These works serve as the foundation to the proposed architecture in this paper. The NSI configuration makes a clear description on how to achieve multi-tenancy by extending the 3GPP CSMF capabilities to enforce how the network slice communication services will be distributed across different tenants, and subsequently their end users. As such, this layer is extensively described in the next section.

(1) The service layer

As depicted in Fig. 6, the service layer will serve as both a slice service layer and business domain. It manages the slice operation and business support of every tenant while checking the slice request conformity with the SLA. It also attributes the network service and application requirements for each tenant based on the received slice request. In a micro-operator network, the OSS&BSS block will determine the priority at which different tenant requests will be handled according to the mapped set of Key Performance Indicators (KPIs) attributed to each deployment scenario, while the policy and decision block will determine the SLA between the micro-operator network and individual tenants in a closed tenant, or make a confirmation of the subscriber policy in the MNO open case. The application and service block will handle the service and business implementation of the tenants’ slice requests, thus, approving the network slice formation by allocating each tenant’s request a slice_ID. Different slice_ID forwarded to the network slice manager in the slicing MANO layer are attributed to different tenants’ slice requests.

(2) The slicing MANO layer

The slicing MANO layer is one of the most important layers in achieving network slicing for different deployment scenarios of a micro-operator. The slicing MANO layer describes how network requirements for different tenant slice IDs are being converted to network slicing requirements and, ultimately, network slice instances, which are being transmitted back as a communication service to the tenants. The slicing MANO layer implements the NSMF and NSSMF management capabilities of the network slice. All the blocks within the slicing MANO layer operate dependently, and as such, the layer can be explained as follows. Whenever a slice_ID for a network slice is received from the service layer, the network slice manager which also serves as the slice Lifecycle Manager (LCM), will be responsible for handling the end-to-end life cycle of every tenant slice. To identify the exact resource related to each deployment scenario, the network slice manager is connected with a deployment type manager which determines which deployment scenario a tenant’s slice_ID belongs to, either a closed deployment A, closed Deployment B or an Open micro-operator. Hence, while the Network slice manager is in charge of a high-level slice_ID management, the deployment type manager will be responsible for sorting out different deployment scenarios’ resource allocation.

For a proper management of multiple slice requests, the deployment type manager transmits the administrative control of different tenants’ slice requests to the network slice orchestrator which distributes the functionalities amidst the different coordinators. Three coordinators are available to create a level of abstraction between the slice resource selection and the network slice orchestrator. These are Dep. A cord, Dep. B cord and the Open cord. While the deployment type manager is responsible for resource selection based on the tenant’s deployment requirements received, the coordinators are responsible for handling different tenants within each deployment scenario. For example, all tenants belonging to deployment A will be logically coordinated by the Dep. A coordinator, while the resources will be selected by the deployment type manager, and then, the individual NSIs allocated for all tenants in Deployment A will be orchestrated by the Network slice orchestrator using the slice_ID which is in correspondence to the slice request ID. Finally, the slice lifecycle is managed by the network slice manager. The network slice orchestrator and the network slice manager will implement the NSMF capability of creating the NSI, and the communication between them will be formatted in a restful API.

The next stage, after that each tenant cases are separated to their deployment coordination, is the selection of network resources based on the tenant slice_ID. Figure 7 illustrates how the different deployment scenario coordinators are connected to the NSSI orchestrator. The NSSI orchestrator is responsible for the aggregation of NFs from different domains within the micro-operator network. Since deployment B NSI can involve NSSI from an external network, the Dep. B coordinator is also connected to an external NSSI orchestrator which serves as an abstraction layer between the micro-operator and the external network. The Multi-domain manager is responsible of aggregating network resources (i.e., NFs) from different domains of different operators, which is why it is connected to the external NSSI orchestrator. Thus, the micro-operator’s NSSMF capabilities are implemented between the NSSI orchestrator and the Resource aggregator. The Resource aggregator serves as the layer of abstraction between the slicing MANO layer and the resource layer and it is responsible for NF aggregation across multiple tech domains within the micro-operator network.

Fig. 7

End-to-end message sequence diagram for a micro-operator network slicing architecture. This figure presents a step by step sequence of achieving network slicing in a micro-operator based on the presented architecture

(3) The resource layer

The Resource layer describes the implementation of the ETSI NFV-MANO architecture [20] with few modifications. As seen in Fig. 6, the NFV infrastructure layer is the same as the ETSI-NFV infrastructure with a separation of the common control layer functions from the dedicated control layer functions. The reason of this separation is to embed the individual user equipment MDD_ID in the dedicated control layer for the proper differentiation of resources for each layer. This approach is inspired from the implementation technique in [26].

The SDN functionality for data transmission, amidst different VMs in the VIM, is implemented with the Resource aggregator or Resource Orchestrator (RO).

According to OSM [9], the SDN-assist which implements the functionality of the Resource aggregator via the Single Root Input Output Virtualization (SR-IOV) or Passthrough interface, works in such a way that after the instantiation of a VNF in the resource layer, SDN-assist maps each instantiated VM interfaces to an Openflow port, and then creates a data plane network by talking to the SDN controller and connecting appropriate Openflow ports. With this approach, the slicing MANO layer will be able to connect and transfer packets between different VMs. This is similar to the approach proposed in [23] where the resource aggregation serves as the Aggregation RO and the NSSI orchestrator serves as the domain administrator.

4.3 The message sequence diagram for the proposed architecture

The message sequence diagram highlights the message flow from the user equipment slice creation request till when the slice communication service is established. Figure 7 shows the end-to-end sequence diagram for the micro-operator network covering open, closed, and mixed micro-operators.

Since the slicing MANO layer is one of the most important layers for achieving network slicing in a micro-operator network, and for a better understanding of the inter-block operation within this layer, a separate sequence diagram is shown in Fig. 8 to describe the operating sequence extensively in the slicing MANO layer. As presented in the slicing MANO layer, Fig. 8 describes the sequence of operation for the NSMF and NSSMF implementation. The operation in Fig. 8 is represented with a message sequence from 0 to 15. While 0 presents the transfer of individual slice_ID network requirements from the service layer, other operation sequences from 1 to 13, as seen in Fig. 8, describe how the NSMF and NSSMF will manage the creation of individual slices based on the micro-operator deployment scenario and the network requirements. Sequence number 14 presents how the created NSI is transferred back to the tenant, and sequence number 15 presents the management of the created NSI.

Fig. 8

The message sequence diagram for the micro-operator network slicing MANO layer. This figure presents a sequence diagram from the operations in the Slicing MANO layer

5 Network slice communication service distribution technique for multi-tenants

In addition to the network slicing architecture proposed in this paper, we further propose a new framework that will support four situation types that can exist for any use case during a network slice communication service distribution across a multi-tenant network. Basically, after the network slice instances have been established, the distribution of the communication service across different available tenants in the network can be achieved based on the differentiated services. The situation classification is based on the type of use cases that can exist within a tenant in a micro-operator network and it can be defined as follows:

Situation 1 occurs when one slice instance is allocated for one tenant. This situation can be applicable when a tenant’s use case requires a specific network service, such as an eMBB, uRLLC or mMTC service. Thus, only the required service slice will be distributed to the tenant.

Situation 2 describes a situation where one slice instance is to be distributed or allocated across multiple tenants. This situation can happen due to a shared subnet within the network which is now reflected outward to the tenants. Thus, one slice communication service will be shared amidst multiple tenants requiring the same network service.

Situation 3 occurs when a tenant’s use case requires more than one slice instance. This happens when a use case requires multiple differentiated services based on the network requirements. The use cases within a tenant can require an eMBB and a uRLLC slice for high throughput and strictly low latency requirements. As such, the tenant’s network requirements will need different slices allocated to a single use case.

Situation 4 describes a multi-tenant case where different slice instances are allocated for multiple tenants’ use cases. Unlike situation 3 where different slices are allocated to a single tenant’s use case, in this situation, multiple slices services are allocated to multiple tenants.

These situation types can be used to define how the slice allocation will happen for each deployment scenario of a micro-operator network or any other possible use cases targeting for instance UAVs, and industrial robots.

Considering different micro-operator network deployment scenarios, Table 1 highlights a mapped relation between each deployment scenario of a micro-operator and the multitenant-slice situation type that can exist.

Table 1 Micro-operator deployment scenarios mapped with situation types

To describe the network slicing communication service allocation for every possible multitenant-slice situation type, we enhanced the network slicing architecture for a micro-operator (Fig. 9) with focus on the multi-tenant layer of the architecture which determines the implementation of the CSMF and how the communication service for every network slice instance is being distributed across different tenants.

Fig. 9

Micro-operator slicing architecture with focus on the multi-tenant layer [11]. The figure present an extended version of the micro-operator slicing architecture based on Fig. 6 with focus on the multi-tenant layer

In Fig. 9, we present an implementation technique for the CSMF capability with a multi-tenant manager and a communication service orchestrator. The former is responsible for the slice request aggregation and handling for each tenant, and the latter is responsible for the communication service distribution to the required tenants. The reason for implementing the CSMF function with the multi-tenant manager and the communication service orchestrator in Fig. 6, is to be able to separately achieve all possible types of slice requests from every deployment scenario, and to manage all possible situation types that can exist during the slice distribution. This approach will efficiently implement the CSMF.

5.1 The multi-tenant manager

In the micro-operator network, the multi-tenant manager is responsible for the aggregation of different slice requests from individual tenants and forwards those requests to the service layers for policy, charging and operation support. The individual slice requests such as the slice service type (i.e., eMBB, uRLLC, mMTC), for each tenant will come as a slice request ID that will be described in the NST during the implementation phase. Just like a slice broker, every tenant slice request ID is abstracted to the multi-tenant manager and then forwarded through the service layer to the slicing MANO layer where the NST will be implemented, and the slice instance will be created across the RAN and CN. The slice request ID will be dependent on the tenant’s use case, the end users, the deployment scenario, and the situation type to determine the needed resources forming the slice. The slice request will also contain the tenant information such as the deployment type, location of tenants, network requirements, shared constituents, and confirmation if an external resource will be required or not. All these parameters will be abstracted to the slicing MANO layer for the slice instantiation and creation. Then, after the slice has been instantiated, the communication service orchestrator will be responsible for intelligently identifying each tenant’s slice and will allocate the tenants’ slice to the respective end users.

5.2 The communication service orchestrator

The communication service orchestrator extends the full functionalities of the CSMF, where it is responsible for the distribution of “per tenant” instantiated slice (i.e., end-to-end NSI), as an established communication service back to the tenants. The communication service orchestrator will implement this by mapping back the tenant request ID to a slice creation ID. It will also be responsible for combining multiple NSIs (i.e., network slice types), and transmitting them to the respective tenant(s) by ensuring the optimal allocation of resources to different tenants based on their priority which will be determined in the tenant’s SLA.

In order to approach the different situation types that can exist when a slice is to be allocated to multiple tenants, the communication service orchestrator will be implemented in four layers. The layered approach proposed in this paper is similar to the approach used by OSM [12] in the NSI creation. In the proposed technique, at the communication service orchestrator, the basic layer will be an Instantiated NSI. A single NSI will be implemented for the basic situation type that can exist (e.g., situation 1: when one network slice is attributed to a single tenant). As depicted in Fig. 10, each layer will represent each situation in a hierarchical form. Layer 1 will implement situation 1, layer 2 will implement situation 2 while depending on layer 1, layer 3 will implement situation 3 while depending also on layer 1 and layer 4 will implement situation 4 while depending on layer 2 or layer 3. From Fig. 10 it can be seen that each layer is dependent on other layers, this implies that the situation 2, 3, or 4 can only be implemented if there is a layer 1 (i.e. an instantiated NSI). Therefore, the implementation of each layer to achieve the possible situation types can be described as follows:

Fig. 10

Communication service orchestrator implementation of multitenant-slice situation types. The figure presents the layers approach for achieving communication service distribution for each possible situation types that can exist

Layer 1: This will serve as the basic layer, and it will be NSI specific for each tenant. The NSI is allocated to each of the end users of a single tenant. A layer 1 template will be created containing parameters such as the slice creation ID in relation to the slice request ID, the situation types to determine if the slice will be for a single slice, etc. Hence, if the slice is requested for one tenant, Layer 1 is activated and, the slice instance communication service will be allocated to a single tenant.

Layer 2: Layer 2 implementation for multitenant-slice situation type 2, will be achieved with a template containing a layer 1 description. However, in this case, a higher description layer will be implemented. This means that a Layer 2 template will contain a layer 1 description, but a layer 1 description will not contain a layer 2 description as seen in Fig. 4. For layer 2, a service broker will be introduced to manage the network resources of a single network slice instance amidst different tenants. The implementation of the broker will be performed in an action file (i.e., an executable file) that will be described using a NS primitive in Juju charm (i.e., a solution for automating action performed in a virtualized network). In the layer 2 description, the number of tenants will be increased for a single network and hence the service broker action will be implemented.

Layer 3: Layer 3 implementation for multitenant-slice situation type 3 involves a single tenant being allocated multiple slice instances. Where each instance is responsible for specific network services. The implementation of layer 3 will be very vital to achieving the full capabilities of the CSMF and many use cases will require this situation outside a micro-operator, such as the UAV use cases that require eMBB and uRLLC slices, or any use case that requires also mMTC slices. The layer 3 implementation will be achieved by combining multiple layer 1 templates and using a service broker to achieve the combination of two slices for a single tenant. The service broker will also be implemented in an action file described with a Juju charm, which will implement the allocation of both slices to a single tenant. Furthermore, since every layer 1 templates are representing different NSIs identified for a network service, the layer 3 template will specify the required slice instances (i.e., required layer 1 templates) that will be combined. This is based on the slice creation ID. Finally, the service broker can also combine multiple NSIs from single operator or multiple NSIs from multiple operators. The implementation of layer 3 to achieve multi-tenant slice situation type 3 is rather vital to a full CSMF implementation.

Layer 4: Layer 4 implementation for situation type 4 is based on multiple layer 2 (and even layer 3) templates, and the service broker will implement the rest. If a layer 2 template is used, the service broker will combine multiple layer 2 templates and call an action file to combine multiple NSIs. There will be multiple slice instance services implemented for multiple tenants. However, if a layer 3 template is used, that will be easier as only the number of tenants will be increased.

Hence, since the layered approach presented in this paper is hierarchical, layer 4 can only be implemented with layer 2 or layer 3 templates. In the same way, layer 2 or layer 3 can only be implemented with a layer 1 template. As such, layer 4 is indirectly dependent to layer 1. In general, our proposed solution will cover every single future use case that can exist in terms of network slices.

6 Discussion

The research work presented in this paper has focused on a very important technology in the advancement of 5G and beyond, network slicing. The paper showed that even though enormous research is being done towards network slicing for contemporary network, very few research works have been directed towards achieving network slicing for different deployment scenarios of a local 5G micro-operator network. Due to the importance of micro-operator network deployments which offer enormous new business opportunities, it is vital to focus on achieving network slicing architecture for an end-to-end 5G micro-operator network. The network slicing architecture presented in this paper is vital not only as a foundational/generic work with regards to the new local micro-operator deployment model, but also the fact that it followed the approach of a complete network softwarization and virtualization using enabling technologies of SDN/NFV.

The architecture presented in this paper is subdivided into different layer to ensure efficient support of different implementation technique that will cover all possible deployment scenarios. These layers include the multi-tenant layer responsible for the handling multi-tenancy, the service layer which is responsible for operations services and policy management for each created slice instance, the slicing MANO layer which is responsible for the creation and management of network slice subnet instance and network slice instance, and finally the resource layer which is responsible for the instantiation of Virtual and Physical Network functions. The sequence diagram in Figs. 7 and 8, highlight a step by step description by which a network slice can be created and distributed across different deployment scenarios of a micro-operator using the presented architecture.

Considering the multi-tenant layer as seen in Fig. 9, the idea of distributing of slice instance(s) to different tenants either in a micro-operator network or contemporary MNO network, is still a very open research. As such, the paper further presented a generic technique for the distribution of network slice instance as communication service to different tenants and end users in a micro-operator network. To achieve this, we sub-divided the multi-tenant layer into multi-tenant manager for handling request of different tenants, and the communication service orchestrator for the distribution of created slice instance to the appropriate tenants. The paper considered all possible situations that can exist whenever slice instance(s) is to be distributed across a tenant or multiple tenants. As such, the communication service orchestrator is implemented in a layered approach such that different layers can be responsible for each situation type that can exist during slice distribution.

With the presented network slicing architecture for a 5G micro-operator network and the generic communication service distribution technique for slice instances across multi-tenant, continuous work will include the implementation of presented architecture in a virtualized network environment. With this, different performance analysis such as CPU utilization, memory utilization, throughput, and overall latency from the creation of each slice to the distribution can be determined and analyzed thoroughly.

7 Conclusion

In this paper, a sophisticated network slicing architecture for local vertical specific service providers also known as micro-operators is presented. Due to the diverse set of deployment scenarios that are associated with a 5G micro-operator network, the proposed architecture serves as a basis for future works in developing a comprehensive implementation of network slicing for local 5G networks leveraging multi-domains and multi-tenancy. With focus on the multi-tenant layer of the architecture, the paper further presented a generic technique to address how the network slice communication service will be distributed to different tenants and end-users in a micro-operator. To achieve this, we proposed the expansion of the CSMF to accommodate a multi-tenant manager and the communication service orchestrator. The communication service orchestrator will address all multitenant-slice situations types that can exist using the layered approach presented in this paper. In line with the micro-operator slicing architecture presented in the paper, the proposed framework for network slice communication service distribution will serve as a foundational technique for future research work for the integration of the proposed CSMF capabilities with existing orchestration implementations. Future research will also focus on expanding a new set of use cases based on the situation types that can exist. Furthermore, future work will entail using concepts such as the ZSM in the full end-to-end automation of different network services and network management presented in this paper.