Showing posts with label NG RAN. Show all posts
Showing posts with label NG RAN. Show all posts

Thursday, 4 November 2021

Voice over New Radio (VoNR) Establishment and Release between NG RAN and 5G Core

In this video I explain how QoS Flows for VoNR are established and released especially on N2 reference point between 5G Core and NG RAN.

The pervious video about generic aspects of "QoS Flow Establishments in 5G Standalone RAN and Core" you will find in the first link of the Related Posts listed below:

Tuesday, 12 October 2021

Monday, 29 March 2021

5G RAN Functional Splits

I have been meaning to write a post on RAN functional splits and even make a video. Recently I came across multiple of these things so I am taking a shortcut by posting them here. 

The first is this basic introductory video from Parallel Wireless where they explain why you need RAN splits providing examples of various functional splits for 4G and 5G mobile networks. It is embedded below:

The next one is slightly detailed video from the book "5G Radio Access Network Architecture: The Dark Side of 5G" by Sasha Sirotkin (Editor). I wrote a review of the book here and Sasha kindly made a video for our channel which is embedded below:

Finally, RCR Wireless published an article looking at the 5G functional splits in detail, by Ankur Sharma, Associate Vice President, Product Management and Strategy, Radisys. The article 'Exploring functional splits in 5G RAN: Tradeoffs and use cases' is available here.

Feel free to suggest other videos, articles, etc. in comments.

Related Posts:

Friday, 5 March 2021

How to Identify Network Slices in NG RAN

In my last post I described how NG RAN resources can be divided into network slices. 

Now I would like to show how these network slices and the traffic they carry can be identified. 

The key to this is a parameter from the NG Application Protocol (NGAP) called the Single Network Slice Selection Assistance Information (S-NSSAI). When configuring virtual network functions in NG RAN there are lists of S-NSSAI exchanged, e.g. between gNB-CU CP and AMF during NGAP Setup procedure, to negotiate which network slices have to be supported in general. 

When it comes to connection establishment starting with NGAP Initial Context Setup for each PDU session that is established its individual S-NSSAI is signaled. 

The S-NSSAI - as show in the figure below - consists of two parameters, the Slice/Service Type (SST - 8 bit) and the optional Slice Differentiator (SD - 24 bit). The exact format and numbering ranges are defined in 3GPP 23.003.

3GPP 23.501 defines a set of default values for SST as listed in the following table:

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.

V2X

4

Slice suitable for the handling of V2X services.

So when looking back at the figure it emerges that for each subscriber represented by an IMSI the SST allows to identify which services are running. 

On the other hand allows to see if in which virtual network the subscriber is active. In my example I have defined that the resources are shared among a Public MNO that I consider the owner of the network hardware and two different private (campus) networks. While IMSI 1 and IMSI 2 are not allowed to use any other network slice the IMSI 3 is allowed to "roam" betweent the public slice and the two private network slices. This explains why a slice-specific authentication functionality as defined in Rel. 16 is necessary. 

Related Posts:

Thursday, 17 December 2020

Conditional Handover (Rel. 16) Explained

Although a couple of SON mobility robustness features have been introduced in LTE radio networks it is still a common problem in some network areas that a high number of handover failures leads to higher drop rates and large numbers of RRC Re-Establishments.

Often these problems occur due to quickly changing radio conditions in the handover preparation phase or after handover execution attempt. 

SON algorithms cannot cope with these dynamic changes of the environment, but improvement is possible if the UE itself is enabled to constantly monitor the radio quality during the handover procedure and finally select the best possible target cell from a list of candidate neighbors. This new feature defined in 3GPP Release 16 for both, NG RAN (5G SA NR) as well as E-UTRAN (LTE), is called "Conditional Handover". The figure below illustrates how it works.

(click on the picture to enlarge)

Step 1 is the RRC Measurement Report indicating that handover to a neighbor cell is required. However, this message contains a list of candidate neighbor cells.

In the figure it is assumed that each of these candidate cells is controlled by a different gNB. Hence, 3 XnAP Handover Preparation procedures are performed and each potential target gNB allocates radio resources for the UE and provides a handover command (NR RRC Reconfiguration message) that is sent back to the source gNB (step 2).

In step 3 the source gNB builds the conditional handover command, which is a NR RRC Reconfiguration message that contains a list of conditional reconfiguration options plus additional RRC measurement configurations that enable the UE to find out which of the possible target cells is the best fit. 

In step 4 the UE makes its handover decision and moves to the cell controlled by target gNB 1.

Here it sends in step 5 the NR RRC Reconfiguration Complete message. 

The target gNB 1 detects the handover completion based on the reception of the NR RRC Reconfiguration Complete message, performs NGAP Path Switch procedure (not shown in figure) and triggers the release of the UE context in source gNB on behalf of sending the XnAP UE Context Release message (step 6).

With this information the source gNB also detects the successful handover completion and orders in step 7 the release of the radio resources provided by target gNB 2 and 3 to which it sends the new XnAP Conditional Handover Cancel message.

As mentioned before the conditional handover is also possible for LTE radio connections. In this case X2AP is used instead of XnAP and LTE RRC instead of NR RRC.

The conditional handover can be performed for all kind of intra-eNB/gNB handover and X2/Xn handover. However, S1/N2 (NG-C) conditional handover is not allowed.