Network Slicing is a popular buzzword. You hear it everywhere, whether it’s referring to LTE or next-generation 5G technology.
What exactly is network slicing? Basically, it provides differentiated treatment depending on user requirement and improves the efficiency of network resources. In network slicing, customized networks are created and based on user requirements, mobility management entity (MME) providing the required service is selected.
Recently, there has been an increase in the demand to reduce the cost of network infrastructure. Network slicing provides a way to allocate the right resources for the right type of services. This helps reduce the complexity and the cost from a network-deployment perspective.
3GPP is working on 5G network slicing adding more details for different use cases. In Release 13, 3GPP introduced the streamlined version of network slicing called Dedicated Core Network (DECOR). DECOR introduces a service-based core network so that a user will be served a core network entity based on their service requirements. In DECOR, eNodeB selects the core network node based on information received from the user equipment (UE). On receiving the NAS Attach Request, the core network selects the MME based on the user’s subscription information and redirects UE to select MME. This helps achieve the intent of network slicing by connecting UE to a customized core network.
UE sends the NAS Attach Request to eNodeB in an RRC Connection Setup Complete message. Based on information provided by UE, eNodeB selects the MME and sends an Initial UE Message to MME carrying the NAS Attach Request message. In DECOR, the core network checks for the subscription of UE and, if required, sends a NAS Reroute Request message back to eNodeB. In the NAS Reroute Request, MME provides the MME Group ID and may also include GUTI. With GUTI, eNodeB can select the previously registered dedicated MME that may have stored the UE context already. If UE is newly entering the pool identified by the MME Group Id, the NAS Reroute Request will not carry GUTI information. In this case, eNodeB uses the MME Group Id and selects MME by performing a load balancing function.
The implementation of DECOR requires modifications at eNodeB and core networks for handling the NAS Reroute Request. This does not require any modification at the UE in the current phase of specification. The core network itself decides about rerouting without involving UE based on the UE usage or subscription data. Thus, the core network can redirect any UE just based on its usage and irrespective of release supported by UE.
In 3GPP Release 14, the enhanced DECOR has been defined. In eDECOR, the UE provides the DCN selected last time in RRC Connection Setup Complete. Based on DCN Id, eNodeB routes the Initial UE Message to the correct MME in one go. This does not require a reroute from MME and hence, reduces the signaling and latency.
The eDECOR readiness depends on many network elements including UE. Although it reduces the signaling, it requires modification in the UE. The UE has to provide the DCN ID whereas, in the case of DECOR, no changes are required at the UE so any UE can be redirected based on its usage type. For realization of eDECOR, operators must wait for Release 14 capable UEs with support of eDECOR. This requires a push from mobile operators. The support in the UE will be a big challenge whereas DECOR trials have already started.
More use cases and scenarios are being studied in 5G, which will add value to the network.
DECOR is going to be very useful mainly for the UEs that wants a specific service. One other advantage is better utilization of the network infrastructure especially for industries which are providing different IoT application support.