Network Slicing is a 5G-enabled technology that allows the creation of an E2E Network instance across the Mobile Network Domains (Access, Transport, & Core). Each slice is ideally identified with specific network capabilities and characteristics.

The technique of provisioning a Dedicated E2E Network Instance to End users, Enterprises, & MVNOs is called “Slicing” where one Network can have multiple slices with different Characteristics serving different use cases.

The technology is enabled via an SDN/NFV Orchestration framework that provides Full Lifecycle management for the Slices enabling the dynamic slicing (on-demand instantiation & termination for Slices) with full-Service Assurance Capabilities.

The Concept is not relatively new where the Mobile Broadband Network has always succeeded to provide services to end-users via partitioning the network through Bearers & APNs. Below is how the evolution looks like transiting from one Network serving all services to Dedicated Core Network Instances serving more targeted segments.

With the introduction of 5G, the 4G Dedicated Core logic evolved to be 5G Network Slicing with a standard framework that advocates 4 standard slices to be used for global Interoperability (eMBB, uRLLC, MIoT, & V2X)and allowing more space for dynamic slices addressing different Marketing Segments. These slices are globally identified by Slice/Service Type (SST) which maps to the expected network behavior in terms of services and characteristics.

New terms and concepts are introduced with Network Slicing such as 

• Network Slice Instance (NSI) - 3GPP Definition - A set of Network Function instances and the required resources (e.g. compute, storage and networking resources) which form a deployed Network Slice. 
• Network Slice Subnet Instance (NSSI) - 3GPP Definition - A representation of the management aspects of a set of Managed Functions and the required resources (e.g. compute, storage and networking resources). 

If the above definitions are not clear, then the below diagram might clarify it a little bit. It is all about the customer-facing service (Network Slice as a Service) and how it is being fulfilled.

I'd say that the Core NSSI is the most popular one with a clear framework defined by 3GPP where the slicing logic is nicely explained in many contexts. However, the slicing on the RAN side seems to be vague in terms of technical realization and the use case. So, what's happening on the radio?!

The NG-RAN, represented by gNB consists of two main functional blocks (DU, Distributed Unit) & (CU, Centralized Unit) as a result of the 5G NR stack split where the CU is further split to CU-CP & CU-UP.

Basically, a gNB may consist of a gNB-CU-CP, multiple gNB-CU-UPs & multiple gNB-DUs with the below regulations

• One gNB-DU is connected to only one gNB-CU-CP.
• One gNB-CU-UP is connected to only one gNB-CU-CP; 
• One gNB-DU can be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP.

The Location of CU can vary according to the CSP strategy for Edge and according to the services being offered. There can be possible deployments in Cell Sites, Edge DCs, & Aggregation PoPs.

The CU-UP is a perfect fit for the Radio Network Sub Slice.

But Is there a framework to select the CU-UP based on Network Slice Assistance Info?!

Ideally, The CU-CP must get assistance information to decide which CU-UP will serve the particular PDU. Let's explore that in the 5G (UE Initial Access) Call flow below

At one step, in RRCSetupComplete message, the UE declares the requested Network Slice by having the NSSAI (Network Slice Selection Assistance Information) that maps to SST (Slice/Service Type). However, this info is not used to select CU-UP but can be used by CU-CP to select the Serving AMF.

The mapping between PDU Session(s) and S-NSSAI is sent from AMF to gNB-CU-CP in Initial Context Setup Request message. This looks like the perfect input to build logic for Selecting the gNB-CU-UP but looking to the standards, one may realize that the mechanism for selecting the gNB-CU-UP is not yet clear and missing in 3GPP.

Although it is mentioned in many contexts in 3GPP Specifications that the CU-CP selects the appropriate CU-UP(s) for the requested services of the UE, the full picture for the E1 Interface is not yet clear especially for such detailed selection process

This will definitely impact the early plans to adopt a standard RAN Slicing Framework.

The conclusion from my side and after spending some time assessing the Network Slicing at the RAN Side is summarized in the below points.

It is very early at this stage to talk about a standard framework for 5G RAN Slicing.

The first wave for Network slicing will be mainly around slicing in the core domain.

RAN Slicing is a part of an E2E Service (NSaaS) that is dynamic by nature. An Orchestration Framework is a must.

5G Network slicing is one of the most trending 5G use cases. Many operators are looking forward to exploring the technology and building a monetization framework around it. It is very important to set the stage for such technology by investing in enablers such as SDN/NFV, automation, & orchestration. It is also vital to do the necessary reorganization, building the right organizational processes that allow exposing and monetizing such service in an agile and efficient manner.

See you in the next article...