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:

Related Posts: 

• The 3G4G Blog: QoS Flow Establishments in 5G Standalone RAN and Core
• The 3G4G Blog: Anomaly Detection and other AI Algorithms in RAN Optimization
• The 3G4G Blog: How to Identify Network Slices in NG RAN
• The 3G4G Blog: Network Slicing in NG RAN
• The 3G4G Blog: Network Slicing Tutorials and Other Resources
• The 3G4G Blog: Artificial Intelligence (AI) / Machine Learning (ML) in 5G Challenge by ITU
• The 3G4G Blog: Conditional Handover (Rel. 16) Explained
• The 3G4G Blog: UE Radio Capability Signaling Optimization (RACS) in Rel. 16 

QoS Flow Establishments in 5G Standalone RAN and Core

Today I launched a new video on my YouTube channel that explains how QoS Flows are established in 5G RAN and Core. It also highlights the main differences between 4G E-RAB handling and 5G QoS Flows.

Related Posts: 

• The 3G4G Blog: Anomaly Detection and other AI Algorithms in RAN Optimization
• The 3G4G Blog: How to Identify Network Slices in NG RAN
• The 3G4G Blog: Network Slicing in NG RAN
• The 3G4G Blog: Network Slicing Tutorials and Other Resources
• The 3G4G Blog: Artificial Intelligence (AI) / Machine Learning (ML) in 5G Challenge by ITU
• The 3G4G Blog: Conditional Handover (Rel. 16) Explained
• The 3G4G Blog: UE Radio Capability Signaling Optimization (RACS) in Rel. 16 

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:

• The 3G4G Blog: Network Slicing in NG RAN 

UE Radio Capability Signaling Optimization (RACS) in Rel. 16

The data volume of UE Radio Capability Information defined in 3GPP 38.306 is already high and will further increase starting with Rel. 16 due to additional supported bands and other features.

Due to this 3GPP has standardized in Release 16 what is called UE Radio Capability Signaling Optimization (RACS) for both, E-UTRAN/EPS and NG RAN/NGC networks. 

Release 16 RACS does not apply to NB-IoT.

The first key element of this feature set is the introduction of a new UE Radio Capability ID that is structured as defined in 3GPP 23.003 and shown in figure 1 below:

Figure 1: UE Radio Capability ID according to 3GPP 23.003

The components of this new ID are:

•    TF - Type Field (TF): identifies the type of UE radio capability ID.

            Type = 0 -> manufacturer-assigned UE radio capability ID
            Type = 1 -> network-assigned UE radio capability ID

•  The Vendor ID is an identifier of UE manufacturer and only present if TF = 0. The vendor IDs are provided by Internet Assigned Numbers Authority (IANA). The complete list of assigned numbers is publicly available here: https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers

•  The Version ID configured by the UE Capability Management Function (UCMF) that is part of the EPS/5GC. The Version ID value makes it possible to detect whether a UE Radio Capability ID is current or outdated.

·      The Radio Configuration Identifier (RCI) identifies the UE radio configuration.

The PLMN-assigned UE Radio Capability ID is assigned to the UE using the Non-Access Stratum UE Configuration Update Command or Registration Accept message (figure 2).

Figure 2: PLMN-assigned UE Radio Capability Update according to 3GPP 23.743

The new UCMF (UE radio Capability Management Function) stores All UE Radio Capability ID mappings in a PLMN and is responsible for assigning every PLMN-assigned UE Radio Capability ID.

Due to introduction of the UMCM in the core networks the new Nucmf service-based interface is defined for the 5GC and new S17 reference point is defined for the EPS as shown in figure 3.

Figure 3: Network Architecture with UCMF according to 3GPP 21.916

Each UE Radio Capability ID stored in the UCMF can be associated to one or both UE radio capabilities formats specified in 3GPP TS 36.331 [LTE RRC] and 3GPP TS 38.331 [NR RRC]. The AMF must only be able ot handle the NR RRC format while the MME uses the LTE RRC format. Which format is required by the UCMF is configurable.

If at any time the AMF/MME has neither a valid UE Radio Capability ID nor any stored UE radio capabilities for the UE, the AMF/MME may trigger the RAN to provide the UE Radio Capability information and subsequently request the UCMF to allocate a UE Radio Capability ID.

In NG RAN the UE Capability Request can be requested by the AMF as a flag in any NGAP Downlink NAS Transport message or by sending a NGAP UE Radio Capability Check Request (for checking compatibility of IMS voice capabilities). This triggers a NR RRC UE Capability Transfer procedure and subsequently NGAP UE Radio Capability Info Indication or NGAP UE Radio Capability Check Response (for IMS voice support parameters).

Using the NGAP UE Capability ID Mapping procedure the NG RAN node is able to request the most recent UE Capability ID mapping information from the core network functions AMF/UCMF. The same functionality is implemented in S1AP for signaling between eNB and MME/UCMF.

If the volume of the LTE/NR RRC UE Capability to be sent by the UE is larger than the maximum supported size of a PDCP SDU (specified in 3GPP 38.323) then the UE Capability Info can be transported in LTE/NR RRC using a chain of UL Dedicated Message Segment messages.

Figure 4: RRC UL Dedicated Segment Message transporting UE Radio Capability Information according to 3GPP 36.331 and 38.331

Each of these message will have a dedicated segment number and the last one has the rrc-MessageSegmentType =  “lastSegment”, which triggers reassembly of the orignal UE Capabability information in the receiving entity.

Understanding the Dual Active Protocol Stack (DAPS) Handover in 5G

In this video I explain the principles and signaling procedures related to the DAPS handover.

The DAPS handover is a new feature for URLLC services defined by 3GPP in Rel. 16.

Related Article:

• Techplayon: 5G NR Dual Active Protocol Stack (DAPS) Handover – 3GPP Release 16

A Look into 5G Virtual/Open RAN - Part 7: Change of gNB-CU-UP without Handover

This will be the last part of my series about Virtual/Open RAN signaling procedures. In this final post (although not the last one on this blog) I would like to present a very unique procedure that emerges from the facts of virtualization and automation of the RAN. And again I would like to present the big picture overview of the scenario that is called "Change of gNB-CU UP" (without handover). The full message flow (ladder diagram) can be found in 3GPP 38.401, chapter 8.9.5.

In the same chapter one can read that the trigger point for starting a change of the gNB-CU UP is quite vague. 3GPP writes: "e.g. a measurement report". However, which particular measurement event should trigger such a procedure? Even when looking into the Rel. 16 versions of 3GPP 38.331 (NR RRC) it becomes evident that all measurement events that are not dealing with NR sidelink or V2X connectivity are triggered by changing reference signal strength or rising interference. 

However, in case of a gNB-CU UP change without handover the UE does not move to a different cell. This makes me think - correct me if I am wrong - the true trigger points for this procedures come form a different entity, e.g. from the AI-driven policies and algorithms of the RAN Intelligence Controller (RIC) that is a fundamental element of the Open RAN architecture.

So what is necessary from a signaling perspective to change the gNB-CU UP during an ongoing connection?

There are new transport network resources aka GTP/IP-Tunnels required to steer the user plane traffic to and through the RAN. A new F1-U tunnel is necessary as well a a new NG-U tunnel, because also the user plane traffic between RAN and the UPF in the 5G core network must be exchange using a new route.

When it is clear which new UP transport tunnels need to be established (and which old ones need to be deleted) it is really simple to understand the overall scenario.

A F1AP UE Context Modification procedure is performed to switch the F1-U tunnel. NGAP Path Switch procedure is performed to switch the NG-U tunnel. And an E1AP Bearer Context Modification procedure is the prerequisite, because it delivers the new UL GTP-TEID for the F1-U tunnel as well as the new DL GTP-TEID for the NG-U tunnel.

Unfortunately the authors of 3GPP 38.401 are not very precise when mentioning protocol procedures defined in other specs. Thus, they speak about "bearer modification" when looking at F1AP and "Path Update" for NGAP.

It is not a big deal, but something you just need to know if you want to analyze real-world message flows of this scenario.

Related Posts:

• 3G4G: Open RAN, OpenRAN and O-RAN

A Look into 5G Virtual/Open RAN - Part 6: Inter-gNB CU Handover involving Xn

In previous blog posts I have discussed intra-gNB-DU handover and inter-gNB-DU handover scenarios.Now it is time to look at inter-gNB-CU handover that uses the Xn interface.

At the RRC protocol layer there will be the measurement setups and measurement reports as in the intra-gNB handover cases. And F1AP UE Context Setup and Release Procedures are identical with the ones discussed for inter-gNB-DU handover. Only the cause values are expected to be different, e.g. "successful handover".

Thus, I do not want to  focus here on la adder diagram call flow (that is by the way very well described in 3GPP 38.401, chapter 8.9.4), but invite you to have a look at a "big picture" that you see below.

(click image to enlarge)

What characterizes the inter-gNB handover is the transfer of the UE RRC/NGAP context form the source gNB-CU to the target gNB-CU. When the Xn interface is available to connect two neighbor gNBs this context transfer is executed using the XnAP Handover Preparation procedure. The Initiating Message of this procedure transfers the UE context parameters to the target gNB-CU. Then embedded in the Successful Outcome message the handover command is sent in return to the source gNB-CU that forwards it to the UE. In addition a temporary user plane transport tunnel for the purpose of data forwarding is established and later on released on the Xn user plane interface.

Once the UE performed the handover on the radio interface all the transport tunnels for the payload transmission need to be switched from the old gNB to the new one. This includes the tunnel to the UPF that is managed by the NGAP. Thus, the target gNB-CU starts the NGAP Path Switch procedure. 

In the target gNB environment it is necessary to establish a new F1AP UE context, new E1AP Bearer Context and new F1-U payload transport tunnel. All this happens BEFORE the Handover Command is sent to the source gNB/UE. And once there is an indication that the handover is completed all the radio and transport resources controlled by the source gNB will be released.

So the figure above looks complicated, but actually the underlying logic of context/data forwarding, radio resource allocation and transport tunnel switching is quite simple.

Special note: In case there is no Xn interface available the UE context/handover information can be transmitted using NGAP Handover Preparation procedure on the source side of the connection and NGAP Handover Resource Allocation procedure on the target side of the connection.

Related Posts:

• A Look into 5G Virtual/Open RAN - Part 7: Change of gNB-CU-UP without Handover
• 3G4G: Open RAN, OpenRAN and O-RAN

Comparing S1AP and NGAP UE Context Release

As an addition to my blog post about the 5G RAN Release procedure I would like to have an in-depth view at the details of NGAP UE Context Release Complete message.

Indeed, the S1AP (known from E-UTRAN) and the NGAP are very similar protocols and when reading the 3GPP specs it is obvious that many message names are identical and the procedures fulfill the same purpose when looking at call scenarios.

However, the difference is visible in the details as one can see when looking at the figure below.

While the S1AP UE Context Release Complete message does not contain any additional information we find in the NGAP UE Context Release Complete the identity of the last serving 5G cell, represented by the NR-CGI, the last visited Tracking Area Identity (TAI) and a list with the IDs of the PDU sessions (E-RABs) that have been terminated when the UE context was released.

This additional information in very valuable for network troubleshooting, since in LTE (S1AP) only the ID (ECGI) of the initial serving cell or a new serving cell ID at inter-node handover was signaled. And if you wanted to know how many E-RABs have been terminated with a S1AP UE Context Release procedure it was necessary to look back into the full sequence of call-related S1AP messages starting with the messages for Initial Context Setup.

All in all, with 5G NGAP trace analysis and the life of RAN engineers becomes easier. Thank you, 3GPP! 

Comparision of S1AP and NGAP UE Context Release Complete Messages

A Look into 5G Virtual/Open RAN - Part 3: Connection Release and Suspend

The 3rd post of this series introduces the details of connection release in the 5G RAN.

Indeed, we find most of the release causes known from E-UTRAN in the 5G specs and it is clear that all protocols that have been involved in the connection setup need to be perform a release procedure at the end of the connection.

However, again the split into different virtual functions brings the demand for some addition messages.

This is illustrated in figure 1 for the a release due to "user inactivity", which means: the gNB-CU UP detected that for a define time (typical settings for the user inactivity timer are expected to be between 10 and 20 seconds) no downlink payload packets have been arrived from the UPF to be transmitted.

So the gNB-CU UP sends an E1AP Bearer Context Inactivity Notification message to the gNB-CU CP that triggers the release procedures on NGAP, F1AP, RRC and E1AP. The RRC Releases message is transported over the F1 interface to the gNB-DU where is forwarded across the radio interface to the UE.

Figure 1: Connection Release due to "user inacativity"

An alternative to the connection release is the RRC Suspend procedure shown in figure 2. Here the UE is ordered to switch to the RRC Inactive state, which allows a very quick resume of the RRC connection when necessary.

Figure 2: RRC Connection Suspend

In case of suspending the RRC connection the RRC Release message contains a set of suspend configuration parameters. The probably most important one is the I-RNTI, the (RRC) Inactive Radio Network Temporary Identity.

If the RRC connection is suspended, F1AP and E1AP Contexts are released, but the NGAP UE Context remains active. Just NGAP RRC Inactivity Transition Report is sent to the AMF.

Related Posts:

• A Look into 5G Virtual/Open RAN - Part 4: Intra-gNB DU Handover
• 3G4G: Open RAN, OpenRAN and O-RAN

EPS Fallback in 5G Standalone Deployments

It can be expected that later this year some mobile network operators will launch their initial 5G standalone (5G SA) deployments.

Nevertheless there will remain areas with temporary or permanently weak 5G NR coverage. One possible reason might be that even when 5G and LTE antennas are co-located, which means: mounted at the same remote radio head, the footprint of the 5G NR cell is significantly smaller when it uses a higher frequency band than LTE - see figure 1.

Figure 1: Smaller footprint of co-located 5G NR cell with higher frequency

Especially UEs making Voice over New Radio (VoNR) calls from the 5G cell edge have a high risk of experiencing bad call quality, in worst case a call drop. To prevent this the UE is forced  during the voice call setup towards 5G core network (5GC) to switch to a LTE/EPS connection where the radio conditions are better for the voice service.

The same procedure for which the term "EPS Fallback" was coined by 3GPP also applies when the UE is served by a 5G cell that is not configured/not optimized for VoNR calls or when the UE does not have all needed VoNR capabilities.

Figure 2: Two options for EPS fallback

When looking at the RAN there are two options for executing the EPS Fallback as shown in figure 2.

In option A the 5G radio connection is released after the initial call attempt is successfully finished and with the 5G RRC Release the UE is ordered to reselect to a 4G cell where a new radio connection is started for the VoLTE call. In this case the UE context is transferred from the AMF to the MME over the N26 interface. 3GPP seems to use also the term "RAT fallback" for this option.

Option B is to perform a 5G-4G inter-RAT handover. Here the session management and user plane tunnels in the core network are handed over from SMF/UPF to MME/S-GW in addition. This is realized with the GTPv2 Forward Relocation procedure on N26 interface.

All in all the EPS fallback is expected to cause an additional call setup delay of approximately 2 seconds.

For the inter-RAT handover case it is easy to detect from signaling information that an EPS fallback was triggered. In the source-eNodeB-to-target-eNodeB-transparent-container sent by the gNB to the eNB a boolean "IMS voice EPS fallback from 5G" indicator will be found that is set to "true". This container is named according to the receiving entity and will be carried by the NGAP Handover Preparation, GTPv2 Forward Relocation Request and the S1AP Handover Request messages.

If a redirection for Voice EPS Fallback is possible or not is indicated in the NGAP Initial Context Setup Request, Handover Request (during 5G intra-system handover) and Path Switch Request Acknowledge (after Xn handover) messages, all sent by the AMF to the gNB.

Further the NGAP protocol provides the cause value "IMS voice EPS fallback or RAT fallback triggered" in the PDU Session Resource Modify Response message indicating that a requested VoNR session cannot be established.  

An excellent, very detailed description of N26 interface functionality and testing ia available here.