5G NSA Retainability Signaling overview and Call Drop Failures Possible Causes & Troubleshooting Methods (Article)

5G NSA Retainability Signaling overview and Call Drop Failures Possible Causes & Troubleshooting Methods (Article)

Introduction:

This Article is a deep dive into 5G NSA Retainability Signaling overview and Call Drop Failures Possible Causes & Troubleshooting Methods.

The following topics are explored in this article:

1. SN Release procedure "Call Flow" including Normal and Abnormal Release.

2. 5G Possible Root Causes of Retainability Issues.

3.NSA Drop Related KPIs.

4. 5G NSA Call Drop related Parameters & Features


SN Release procedure - Normal Release

  • The Normal release can be initiated by the Master Node “MN” or Secondary Node “SN” as show in the below figures.
  • The follow is the most common causes for the Normal Release:- MN Initiated SgNB Release Request includes Value Cause: radioNetwork: "User Inactivity“ or "MCG Mobility“.- SN Initiated SgNB Release required includes Value Cause: readioNetwork: "User Inactivity“ or "SCG Mobility“ or "Action Desirable for Radio Reasons“.*Normal release may be initiated by other reasons and causes such as "Handover Desirable for Radio Reasons", "Load Balancing“, etc.
  • The following figure shows an example signaling flow for the MN & SN initiated Secondary Node Release procedure when SN Release is confirmed by SN.

*The main differences in the signaling flow is in step 1 and 2, all remaining call flow is almost the same

1. When the release is initiated by the MN, the MN initiates the procedure by sending the SgNB Release Request message. If data forwarding is requested,

the MN provides data forwarding addresses to the SN.

1.      When the release is initiated by SN, the SN initiates the procedure by sending the SgNB Release Required message which does not contain inter-node message.

 

2.      for MN initiated release, the SN confirms SN Release by sending the SgNB Release Request Acknowledge message. If appropriate, the

SN may reject SN Release, e.g. if the SN change procedure is triggered by the SN.

2-     For SN initiated release, If data forwarding is requested, the MN provides data forwarding addresses to the SN in the SgNB Release Confirm message. The SN may start data forwarding and stop providing user data to the UE as early as it receives the SgNB Release Confirm message.

3/4. If required, the MN indicates in the RRCConnectionReconfiguration message towards the UE that the UE shall release the entire SCG configuration. In case the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration message, it performs the reconfiguration failure procedure.

5. If the released bearers use RLC AM, the SN sends the SN Status transfer.

6. Data forwarding from the SN to the MN takes place.

7. The SN sends the Secondary RAT Data Volume Report message to the MN and includes the data volumes delivered to the UE over the NR radio for the related E-RABs.

8. If applicable, the path update procedure is initiated.

9. Upon reception of the UE Context Release message, the SN can release radio and C-plane related resource associated to the UE context. Any ongoing data forwarding may continue.

Now, let's explain the most common causes of the normal release mentioned above:

1- Normal Release Cause: due to MCG or SCG Mobility:

  • MCG (Triggered by MN) or SCG Mobility (Triggered by SN) is initiated after a secondary node change, as shown in the figure below for SN Change - MN Initiated.
  • As illustrated, after the MN Initiated sgNB addition request to a new SN (Target-SN) and once the request is acknowledged by the Target-SN, the MN initiates an SgNB release request with the cause of MCG Mobility, which is categorized under the normal release.

Below is the 3GPP TS 38.423 definition for both MN & SN Mobility release causes:

2-Normal Release Cause: due to Action-Desirable for Radio Network:

Sometimes, this message might be interpreted as a drop or abnormal release. However, in fact, it is a normal release mainly caused by the NR NSA User being at critical coverage, which is reaching the A2 Threshold for Secondary cell removal, as shown in the figure below. When the signal quality of the Primary Serving Cell (PSCell) consistently diminishes and there is no suitable neighboring cell identified for a PSCell handover, the decision to delete the PSCell can be triggered by event A2.

Below is the 3GPP TS 38.423 definition for Action Desirable for Radio Reasons cause:

3-Normal Release Cause: due to to SgNB User inactivity timer:

The SgNB release due to inactivity timer can be triggered by MN or SN based on the network parameters when the SgNb is in the inactive state:

Below is the 3GPP TS 38.423 definition for User Inactivity cause:


SN Release procedure - Abnormal Release

  • The detection of NR Radio Link Failure (RLF) can be carried out by either the UE(MN) or the gNodeB (SN).
  • A 5G Call Drop (RLF) is identified and declared through various factors, including transmission issues, core problems, 5G Downlink (DL) and Uplink (UL) radio frequency (RF) issues, UE capability issues, 4G RF issues (RRC Reestablishment), and lastly, configuration issues. This possible drop causes will be explained in the next sections.

  • The following figures shows an example signaling flow for the MN & SN initiated Secondary Node Abnormal Release procedure:

In Case of Master Node “ MN “ initiated the release due to abnormal cause the UE will first report a SCG Failure information to the MN and the message nbsp;includes the failuretypes which can be one of the following causes:

1-     Random Access Problems during Access or Handovers (Unlike 4G, RA Issues are counted as a drop in 5G NSA)

2-     Maximum number of UL RLC retransmissions in is reached: Mostly caused by UL Interference or Poor UL Coverage/Quality

3-     T310Expiry: Mostly caused by Coverage & Quality Issues

4-     SynRecgfail: The UE fails to search for cells (synchronization failure, failure to receive SSB)

5-     RecfgFail: this is mostly caused by Configuration or UE Issues

In Case of Seconday Node “ SN “ initiated the release due to abnormal cause the SN will SgNB Release required with radio network cause: Radio-Connection_with-UE-Lost and this is usually due to two possible causes:

1-     UE is in the uplink out-of-synchronization state due to UL related timers

2-     Maximum number of DL RLC retransmissions in is reached due to DL Coverage (BLER and Poor DL Radio Condition)


Now, let's go through the most possible causes of the 5G NSA abnormal release:

Possible Root Causes of 5G NSA Retainability Issues

  • The detection of NR Radio Link Failure (RLF) can be carried out by either the UE(MN) or the gNodeB (SN).
  • A 5G Call Drop (RLF) is identified and declared through various factors, including and not limited to the following:
  1. 4G RF issues (RRC Reestablishment)
  2. Core problems.
  3. Transmission issues
  4. 5G Downlink (DL) and Uplink (UL) radio
  5. RF issues
  6. UE capability issues
  7. Configuration issues.

1-4G RF issues (RRC Reestablishment)

This is mainly RF issues in the 4G Leg. For example RRC Reestablishment failure.

As shown in the figure below, after the SgNB Addition was completed, the eNodeB (MN) initiated an e-RAB Modification indication to the MME to change the traffic path from SGW to MN to SGW to SN. During the path switch exchange, there might be scenarios where the MME does not reply to the E-RAB Modification indication, and this will be counted as a 5G NSA Drop.

3-Transmission Fault

This might be caused by an X2 interface fault during transmission over X2-U. For example, in the scenario assumed below, there was an X2 Link fault during the SN change procedures, which might lead to a drop.

4-5G MAX DL RTX Reached

As shown in the figure below, once the maximum number of DL RLC Retransmissions reaches the configured threshold, the g-NB (SN) will initiate an SgNB Release Required message, which causes radio-connection-with-UE-Lost.

5-Random Access Problems

In 5G NSA, RACH procedures towards the 5G Leg start after the SgNB addition procedure is completed. Accordingly, any failures in the RA Process will lead to a 5G NSA Drop. As shown in the figure below, once the RA Process fails, the UE initiates an SCG Failure information with the cause randomAccessProblem to the eNodeB (MN). Then, the MN initiates an SgNB Release request due to RAProblem to the SN.

6-MAX UL RLC RTX Reached

During 5G NSA UL Data transfer, the UE might face a UL Interference or Poor UL Coverage/Quality which might lead into problems in UL Packets delivery. As shown in the figure below, once the maximum number of UL RLC Retransmissions reaches the configured threshold, the UE reported a SCG Failure information with cause rlc-MaxNumRetx then the e-NB (SN) will initiate an SgNB Release request message, which includes the same cause.

7-T310Expiry

UE will report SCG Failure information with cause When Radio Link Failure is detected is detected due to T310 expires, for example assume that the current DL BLER is 11% or more for the UE. In this scenario, if the Out-Of-Sync indications reach the n310 value, the T310 timer starts, giving the UE a chance to sync back. If the UE doesn't hit the BLER-In target within the set thresholds during the T310 timer, the RLF Layer steps in. When the T310 Timer runs out without success, the UE declares a radio link failure. In the picture below, once the UE declares RLF and T310 Timer expires, the T311 timer begins. It waits for the UE to kick off RRC Connection Reestablishment. If the UE didn’t recover the connection before T310 Expiry, a drop occurs.


Retainability identification from KPIs

As shown below, from the drop-related counters, you can identify the top drop signatures.


The figure below summarizes the parameters/features where you can tune to improve the 5G NSA Drop rate.

References:

3GPP TS 37.340 version 15.5.0 Release 15

3GPP TS 38.423 version 16.2.0 Release 16