5G Slicing: Concepts, Architectures, and Challenges

Architectures

This is the third in my series of blogs where I try to lay down the basic tenants of 5G network slicing. Network slicing is perhaps the latest in hyped technologies, which everyone is talking about, but not yet implementing. And while it makes sense at the theoretical level, many still don’t understand how to go about laying the foundations.

After having delved into basic concepts in my previous blogs, in this blog I will focus on the architectural aspects of implementing network slicing.
 

SDN Network slicing architecture 

There are several SDN architectures, which meet the criteria of 5G. Regardless of preference, the chosen architecture should comprise of an intermediate control plane, which dynamically configures and abstracts the underlying forwarding plane resources to deliver tailored services to tenants/clients located in the application plane. This, aligned with the requirements of 5G network slicing, needs to support a wide range of service demands in a fast/changes/ robust and cost-effective way. Thus, the SDN architecture is an appropriate tool for supporting the key principles of slicing.

So how can SDN architecture be applied to enable and support slicing in 5G networks?

SDN architectural components include:

• A resource is anything that can be utilized to provide services in response to client requests. This includes infrastructure resources, like cloud nodes and containers. But also network services. 
• A controller is a logically centralized entity instantiated in the control plane which run-time operates SDN resources to deliver services in an optimal way. The SDN controller carries out the abstraction and the aggregation/partitioning of the underlying resources. The interplay of this controller functionality enables the fulfillment of the diverging service demands from all clients while preserving the isolation among them.
• An SDN architecture should also include an administrator Its tasks consist of instantiating and configuring all controllers, including the creation of both server contexts and client contexts and the definition of their associated policies. A context represents all the information the controller needs to interact with a set of underlying resources.

Another key functional aspect that makes SDN architecture a match for 5G slicing is recursion. Recursion enables the SDN control plane to involve multiple, hierarchically arranged controllers that extend the client-server relationships at several levels.  SDN can support a recursive composition of slices. Thus a controller can utilize the resource/s it has access to via its server context/s to define, scale and deliver new resources (and hence new slices) to its own clients, which might also be SDN controllers.

NFV slicing architecture 

The SDN architecture described gives a comprehensive view of the control plane functionalities enabling slicing. However, it lacks capabilities that are vital to efficiently manage the lifecycle of network slices and its constituent resources. In this respect, the NFV architecture is ideal to play this role, as it manages the infrastructure resources and orchestrates the allocation of such resources needed to realize VNFs and network services.

The NFV architecture comprises the following entities:

• Network Functions Virtualization Infrastructure (NFVI): a collection of resources used to host and connect the VNFs. While the broad scope of SDN makes resources a generic concept, the definition of a resource in the NFV framework comprises only the infrastructure resources.
• VNFs: software-based implementation of NFs which run over the NFVI.
• Management and Orchestration (MANO): performs all the virtualization-specific management, coordination and automation tasks in the NFV architecture. The MANO framework comprises three functional blocks:

1. Virtualized Infrastructure Manager (VIM): responsible for controlling and managing the NFVI resources.
2. VNF Manager (VNFM): performs configuration and lifecycle management of the VNF(s) on its domain.
3. Orchestrator: according to ETSI, it has two set of functions performed by Resource Orchestrator (RO) and Network Service Orchestrator (NSO) respectively. RO orchestrates the NFVI resources across (potentially different) VIMs. NSO performs the lifecycle management of network services, using the capabilities provided by the RO and the (potentially different) VNFMs.

• Network Management System (NMS): framework performing the general network management tasks. Although its functions are orthogonal to those defined in MANO, NMS is expected to interact with MANO entities by means of a clear separation of roles. NMS comprises:
  Element Management (EM): anchor point responsible for the FCAPS (Fault, Configuration, Accounting, Performance, and Security) of a VNF.

• Operation/Business Support System (OSS/BSS): a collection of systems and management applications that network service providers use to provision and operate their network services. In terms of the roles we consider in Section 2, tenants would run these applications.

SDN & NFV Working together

To coordinate amongst the different levels of controllers and VNFs, ETSI proposes adding additional SDN controllers in the architecture. Each controller will centralize the control plane functionalities and provide an abstract view of all the connectivity-related components it manages. These controllers include:

• Infrastructure SDN controller (IC): to set up and manage the underlying network resources to provide the required connectivity for a variety of VNFs (and VNF components). Managed by the VIM, this controller may change infrastructure behavior on-demand according to VIM specifications, adapted from tenant requests.
• Tenant SDN controller (TC): instantiated in the tenant domain as one of the VNFs or as part of the NMS, this second controller dynamically manages the pertinent VNFs used to realize the tenant’s network service (s). These VNFs are the underlying forwarding plane resources of the TC. The operation and management tasks that the TC carries out are triggered by the applications running on top of it, e.g. the OSS.

Both controllers manage and control their underlying resources via programmable southbound interfaces, implementing protocols like OpenFlow or NETCONF. However, each controller provides a different level of abstraction. While the IC provides an underlay to support the deployment and connectivity of VNFs, the TC provides an overlay comprising tenant VNFs that, properly composed, define the network service(s) such tenant independently manages on its slice(s).

These different ‘controller’ views, have repercussions on the way they operate. The IC is not aware of the number of slices that utilize the VNFs it connects, nor the tenant(s) which operate these slices. On the other hand, for the TC, the network is abstracted in terms of VNFs, so it has no knowledge of how these VNFs are physically deployed. Despite their different levels of abstraction, both controllers have to coordinate and synchronize their actions. Note that the service and tenant concept mentioned here can be extended to higher abstraction layers by simply applying the recursion principle.

Join me in my next blog as I discuss how SDN and NFV come together to provide network slicing.