Showing posts with label 5GS. Show all posts
Showing posts with label 5GS. Show all posts

Tuesday, 10 November 2020

Network Slicing Tutorials and Other Resources

I have received quite a few requests to do a 5G Network Slicing tutorial but have still not got around to doing it. Luckily there are so many public resources available that I can get away with not doing one on this topic. 


This Award Solutions webinar by Paul Shepherd (embedded below) provides good insights into network slicing, what it is, how it efficiently enables different services in 5G networks, and the architectural changes in 5G required to support it.

Then there is also this myth about 3 slices in the network. The GSMA slice template is a good starting point for an operator looking to do network slicing in their 5G networks. The latest version is 3.0, available here.


As this picture (courtesy of Phil Kendall) shows, it's not a straightforward task.  

Alistair URIE from Nokia Bell Labs points out some common misconceptions people have with Network Slicing:

  1. Multiple slices may share the same cell and the same RU in each slice
  2. Single UE may have up to 8 active slices but must have a single CU-CP instance to terminate the common RRC 
  3. Slicing supports more than 3 slices 

Back in March, China Mobile, Huawei, Tencent, China Electric Power Research Institute, and Digital Domain have jointly released the Categories and Service Levels of Network Slice White Paper to introduce the industry’s first classification of network slice levels. The new white paper dives into the definitions, solutions, typical scenarios, and evolution that make up the five levels of network slices. It serves as an excellent reference to provide guidance in promoting and commercializing network slicing, and lays a theoretical foundation for the industry-wide application of network slicing.

The whitepaper describes the different phases as:

Phase 1 (ready): As mentioned above, the 5G transport network and 5G core network support different software-based and hardware-based isolation solutions. On the 5G NR side, 5QIs (QoS scheduling mechanism) are mainly used to achieve software-based isolation in WAN scenarios. Alternatively, campus-specific 5G NR (including micro base stations and indoor distributed base stations) is used to implement hardware-based isolation in LAN scenarios. In terms of service experience assurance, 5QIs are used to implement differentiated SLA assurance between slices. In terms of slice OAM capabilities, E2E KPIs can be managed in a visualized manner. This means that from 2020 on, Huawei is ready to deliver commercial use of E2E slicing for common customers and VIP customers of the public network and common customer of general industries (such as UHD live broadcast and AR advertisement).

Phase 2 (to be ready in 2021): In terms of isolation, the 5G NR side supports the wireless RB resource reservation technology (including the static reservation and dynamic reservation modes) to implement E2E network resource isolation and slicing in WAN scenarios. In terms of service experience assurance, features such as 5G LAN and 5G TSN are enhanced to implement differentiated and deterministic SLA assurance between different slices. In terms of slice OAM, on the basis of tenant-level KPI visualization, the limited self-service of the industry for rented slices can be further supported. In this phase, operators can serve VIP customers in common industries (such as AR/VR cloud games and drone inspection), dedicated industry customers (such as electric power management information region, medical hospital campus, and industrial campus), and dedicated industry customers (such as electric power production control region and public security).

Phase 3 (to be ready after 2022): In this phase, 5G network slicing supports real dynamic closed-loop SLAs based on AI and negative feedback mechanism, implementing network self-optimization and better serving industries (such as 5G V2X) with high requirements on mobility, roaming, and service continuity. In addition, industry-oriented comprehensive service capabilities will be further enhanced and evolved.

A more technical presentation from Nokia is available here. The video below shows how innovations in IP routing and SDN work together to implement network slicing in the transport domain.

If you know some other good resources and tutorials worth sharing, add them in the comments below.

Related Posts:

Thursday, 10 September 2020

Interfacing HSS and UDM in 5GS with UDICOM (a.k.a NU1 / Nhss)

Back in 2012, we were talking about migration from HLR to HSS. Now we are discussing how to interface HSS to the UDM (Unified Data Management in 5G Core).


In the recent 5G World event, Richard Band, Head of 5G Core, HPE talked about 4G to 5G transition planning. During the talk he mentioned about UDICOM, which is the Standardised new interface between HSS and UDM as defined in 3GPP TS 23.632.


UDICOM allows operators to deploy separate HSS and UDM, even from different vendors. Supported features include:
  • Authentication
  • Single Registration Handover
  • IMS
  • SMS over NAS
3GPP TS 23.632 (Technical Specification Group Core Network and Terminals; User data interworking, coexistence and migration; Stage 2; Release 16) does not use the term UDICOM. It does however describe the interface details, system architecture, system procedures and network function service procedures of UDM-HSS interface.

As can be seen in the picture above, the following reference points are realized by service-based interfaces:
NU1: Reference point between the HSS and the UDM.
NU2: Reference point between the HSS and the 5GS-UDR.

The following Service based interfaces are defined for direct UDM-HSS interworking:
Nudm: Service-based interface exhibited by UDM.
Nhss: Service-based interface exhibited by HSS.

I am not going in more details here but anyone wanting to learn more about the interface should start with 3GPP TS 23.632.

Finally, this talk from HP Enterprise below provides more details of UDICOM.



Related Posts:

Sunday, 19 July 2020

Mobile Initiated Connection Only (MICO) mode in 5G System


Mobile Initiated Connection Only (MICO) mode is designed for IoT devices that send small amounts of data and do not need to be paged. An example of this could be a smart bin that sends a message to the waste collection company saying it is 50% full, etc. This way the bin emptying lorry can plan to empty it in the next collection round. Here there is no reason to page the bin as there is no mobile terminated data that would be required.

MICO mode has to be negotiated between the device and AMF in 5GC. A device in MICO mode cannot be paged as it would not listen to paging to conserve battery power. This extreme power saving mode can ensure that the battery can last for very long time, ideally years thereby making this vision of billions of connected IoT devices a reality.


In an earlier post on RRC Inactive state, we looked at NAS states, along with RRC states. When the UE is in MICO mode, the AMF in 5GC will consider the UE to be unreachable when it is in CM-IDLE state. In addition, a periodic registration timer is also allocated to the MICO mode UEs. The UE has to confirm the MICO mode again during registration update.

The video and presentation are embedded below:





Related Posts:

Monday, 6 July 2020

A Technical Introduction to 5G NR RRC Inactive State


I looked at the RRC Inactive state back in 2017, but the standards were not completely defined. In the meantime standards have evolved and commercial 5G networks are rolling out left, right and centre. I made a short technical introduction to the RRC_INACTIVE state, comparing it with the 4G states in RRC and NAS. I also looked at some basic signalling examples and there are lots of relevant references at the end. Video and slides embedded below.






Related Posts: