arch
Network slicing is a 5G cutting edge technology that enables the creation of multiple virtual networks on top of shared physical infrastructure, allowing operators to provide portions of their networks that fit the requirements defined by various vertical industries. A network slice can be described as the collection of multiple sub-slices of different domains, such as the Core Datacenter, the Transport network, and one or numerous Edge Locations. The figure below depicts some examples of 5G Network Slices:
Katana Slice Manager is a centralized software component that provides an interface for creating, modifying, monitoring, and deleting slices. Through the North Bound Interface (NBI), the Slice Manager receives the Network Slice Template (NEST) for creating network slices and provides the API for managing and monitoring them. Through the South Bound Interface (SBI), it communicates with the Network Sub-Slice Manager components of the Management Layer, namely the Virtual Infrastructure Manager (VIM), the NFV Orchestrator (NFVO), the Element Management System (EMS), and the WAN Infrastructure Management (WIM).
Katana Slice Manager is based on a highly modular architecture, built as a mesh of microservices, each of which is running on a docker container. The key advantages of this architectural approach are that it offers simplicity in building and maintaining applications, flexibility and scalability, while the containerized approach makes the applications independent of the underlying system.
Through the North Bound Interface (NBI), the Slice Manager interacts with a Coordination Layer. It receives the NEtwork Slice Template (NEST) for creating network slices and provides the API for managing and monitoring them. Through the South Bound Interface (SBI), it communicates with the components of the Management and Orchestration Layer (MANO), namely the NFV Orchestrator (NFVO), the Element Management System (EMS) and the WAN Infrastructure Management (WIM), in order to manage the functions in the network.
The network slice is defined using the NEST a descriptor where the network slice characteristics and parameters are described, such as the list of NFV components (Network Services) that need to be instantiated, WAN configuration, QoS, monitoring level, Life-Cycle stages, etc. The NEST must be written in a human/machine readable language, i.e. JSON or YAML. Based on the on-boarded NEST, Slice Manager has to make the mapping between the available data plane resources and the described slice requirements, in order to create a requested slice.
An example of the workflow for the instantiation and the configuration of a Network Slice is the following:
The network operator requests the creation of a new slice using Slice Manager’s NBI, selecting a particular slice profile, in order to deploy his Communication Service (i.e. comprising of a number of NS plus, not mandatory, a 5G NC system).
- A Slice Creation request is sent to the Slice Manager along with a Generic network Slice Template (GST) that describes the slice parameters and requirements.
- Slice Manager runs the Slice Mapping module, which is responsible for mapping the GST request with a particular NEtwork Slice Template (NEST) that is supported by the infrastructure.
- Slice Manager runs the Placement process based on the to determine where to instantiate each Network Service and creates the Network Graph for the slice.
- Following the placement decisions, the Slice Manager communicates with the VIM, WIM and EMS in order to provision resources (Sub-Network Slices).
- VIM creates a new tenant for the slice.
- WIM creates virtual links or/and flows on SDN switches with specific resource-QoS requirements, as declared in the NST, in order to activate appropriate traffic steering.
- EMS provides the required resources and configurations (e.g. associate traffic or user ids to APNs, spectrum frequency allocation, bandwidth, etc.).
- Slice Manager communicates with the NFVO in order to make the deployment and instantiation of the Network Services included in the Communication Service.
- Slice Manager returns a slice id to the Operator/Coordination Layer, for further management and monitoring purposes.
The 5GENESIS Slice Manager is based on a highly modular architecture, built as a mess of microservices, each of whom is running on a docker container. The key advantages of this architectural approach are that it offers simplicity in building and maintaining applications, flexibility and scalability, while the containerized approach makes the applications independent of the underlying system. The Figure below shows an overview of the building blocks that comprise the 5GENESIS Slice Manager.
The North Bound Interface API module implements RESTful APIs, that can be consumed by a component of the coordination layer, e.g. the Experiment Lifecycle Manager, a user/experimenter or the Slice Manager administrator. Refer to NBI Page for a detailed documentation of the NBI REST APIs. In addition to that, two lightweight modules will be included in Slice Manager packages, allowing a user or an administrator to interact with it, consuming the RESTful APIs.
The Command Line Tool module creates a group of BASH commands that a user or administrator can run on the terminal of the host where the Slice Manager is installed, in order to interact with it. These commands are built to consume the RESTful APIs that the Slice Manager offers. Refer to CLI documentation page.
A lightweight web UI will be installed as part of the Slice Manager stack. The web UI will consume the Northbound APIs in order to interact with the Slicing Lifecycle Manager and the repositories. It will also include a guide that will help the Slice Manager user to create a new slice. Refer to GUI documentation page.
This module is the brain of the 5GENESIS Slice Manager, implementing the Create, Read, Update and Delete (CRUD) functions. The role of this component is twofold. On one hand, it receives requests from the NBI API module and takes any necessary actions for the activation, modification or deactivation of a network slice. On the other hand, it receives messages from the Slice Monitoring module, regarding the status change of a deployed slice. It interacts with the other components of the Slice Manager, in order to trigger the process that needs to start, depending on the received messages. Finally, this module hosts a very important process that runs during the slice creation phase, the placement process. This process is responsible for optimally selecting the infrastructure resources to be used for a new slice, based on the slice requirements, as they are described in the NST, and the available resources of the infrastructure layer.
Immediately after the receiving the GST for the creation of a new Slice, Slice Manager runs the Slice Mapping process. This process is responsible for mapping the GST request with a particular NEtwork Slice Template (NEST) that is supported by the infrastructure.
The Slice Provisioning module receives requests from the Slicing Lifecycle Manager service in order to set up, configure or delete the Wide Area Network paths, the isolated NFVI tenant spaces and all the required Network Services, to configure the radio component parameters and register the newly created slice to the Monitoring system. It does so by using the VIM, NFVO, NMS and Monitoring Plugins of the Adaptation Layer.
The Slice Monitoring module is responsible for monitoring the health and the status of every deployed slice. It uses the Adaptation Layer plugins to send status check messages to the MANO components below the Slice Manager and reports any slice status change to the Slicing Lifecycle Manager service.
The Adaptation Layer module provides a level of abstraction regarding the underlaying layer technology, making it feasible for the Slice Manager to operate over any MANO layer component without any modifications to its core functionality, as long as the proper plugin has been loaded. This module is comprised of VIM, NFVO, NMS and Monitoring plugins, one for each of the MANO layer components that the Slice Manager supports. The responsibility for each plugin is to receive request messages from the Slicing Lifecycle Manager and translate them to the proper API call of the supported component. After that, it is in charge of properly handling the responses from the underlying components to the API calls.