5G Stuff: Network Slicing (Part 1)

As part of 5G System architecture, 3GPP has come up with another concept, from the networks or operators p.o.v, called Network slicing based on the Services or Features to be served in the whole PLMN. This concept looks similar to filtering the services based on the QoS profiles so far being used in 2G/3G/4G systems. This time a specific name being used. This allows operators virtually create networks to cater the different needs based on functionality, performance, specific users etc.

Functionality can be categorized as priority, charging, policy control, security and mobility.

Performance is related to latency, mobility,  availability, reliability, data rates etc.

Users are MPS (Multimedia Priority Service) users, Public safety, corporate customers, roamers, hosting an MVNO (Mobile Virtual Network Operator)

From this concept, network slice may be defined as piece of network to service some set of services. Below diagram explain the rest of the concept easily. Based on this, some of the core network elements may be common to some slices and some may be specific to each slice. Network creates instances of the required elements for each slice in the core network.

As mentioned in my earlier post (5G Identifiers (SUPI, PEI, GUTI...), S-NSSAI, NSSAI, SST, SD etc are the terms being used to explain the Network slicing concept and how UE is addressed.  

An S-NSSAI is comprised of SST and SD (optional) fields. An SST can be standardised (no SD) or non-standardised (either standardised SSD + non-standardised SD or non-standardised SST + no SD). Non-standardised S-NSSAI shall not be used in other PLMNs.  

Below table shows the Standardised SST values in a way for establishing the global interoperability for slicing (which recalls me a familiar triangle which explains 5G use cases)

Slice/Service type	SST value	Characteristics.
eMBB	1	Slice suitable for the handling of 5G enhanced Mobile Broadband.
URLLC	2	Slice suitable for the handling of ultra- reliable low latency communications.
MIoT	3	Slice suitable for the handling of massive IoT.

During the initial access to the network, below NSSAIs are defined which is mentioned in one logical order (as I understood).

1. Configured S-NSSAI - NSSAI provisioned in the UE applicable to one or more PLMNs. 

2. Requested S-NSSAI - NSSAI provided by the UE to the Serving PLMN during registration. Here the serving AMF, Network slice (s), Network Slice instances (s) are selected. 5G RAN use this information in AS signaling until 5GC issues the Allowed S-NSSAI (see below). When the UE provides 5G-GUTI, RAN will NOT use this Requested S-NSSAI for routing.

3. Allowed S-NSSAI - NSSAI provided by the Serving PLMN during e.g. a Registration procedure, indicating the S-NSSAIs values the UE could use in the Serving PLMN for the current registration area. 5GC will inform RAN and issue this Id after successful registration and is responsible for selection of the Network Slice Instance. 

There can be at most 8 S-NSSAIs in Allowed and Requested NSSAIs sent in signaling messages between the UE and the network.

As per the operator need or plan one Network Slice Instance can provide one or more S-NSSAIs and one S-NSSAI can be mapped to one or more Network Slice Instances. 

Further, to look from the tracking areas p.o.v, multiple Network Slice Instances mapped to one S-NSSAI may be available in one or more tracking areas. In one tracking area case, the AMF instance which is serving the UE is common to one or more Network Slice Instances.

This slicing concept itself will require more details, which will be continued in my next blogs.

Sources: 
3GPP TS 23501, sec 5.15
3GPP TS 22261, sec 6.1