5G Network Reject Behavior

Introduction

Mobile networks must operate efficiently to provide subscribers with the best service possible. Many mechanisms are in place to optimize each network, and how those mechanisms are configured is left to the network providers. That being said, there are reasons that certain devices cannot access certain networks, and the devices need to be notified of why they cannot select a cell that is attractive enough to camp on. One of those mechanisms is Network reject causes, which differ between mobility and session management. There is also a spectrum of scenarios that cannot be duplicated with some of the software and hardware limitations I currently have with my lab setup. Still, I will cover as much of this behavior as possible in this article.

Scenarios

As I mentioned, there are many scenarios that a UE may encounter when receiving reject cause messages from the network. These are covered in depth in 3GPP TS 24.501 – I will reference the appropriate section in the spec according to the latest release when writing this post (v.17.12.0).

• Non-integrity-protected reject messages (4.4.4.2, 4.4.4.3)
  • Authentication Reject
  • Registration Reject
  • Service Reject
  • Security Mode Reject
• Network congestion
• Mismatching network and UE capabilities/parameters
• Blacklisted devices
• Stale vectors and parameters

Mobility Management (8.2)

Mobility Management rejects are sent by the AMF for various scenarios. The reject causes below are used for REGISTRATION REJECT, AUTHENTICATION FAILURE, SECURITY MODE REJECT, 5GSM STATUS and more.

5GMM Reject Cause (9.11.3.2)

This is not the full list of Reject causes

Authentication Failure (8.2.4)

(20 MAC Failure) Authentication failure is sent by the UE and occurs when the UE’s USIM detects that the MAC in the AUTHENTICATION REQUEST is stale. This is common when the Keys in the subscriber database do not match the keys stored on the SIM card.

(21 Synch Failure) Authentication failure is sent by the UE when the UE’s USIM detects the AUTHENTICATION REQUEST Sequence Number (SQN) is out of range. When the 5GC receives this message, the UDM and AUSF may re-send new Authentication vectors to the UE. If the 5GC receives two AUTHENTICATION FAILURE cause 21 messages from the UE, the network will send the UE an AUTHENTICATION REJECT message.

Authentication Reject (8.2.5)

The network sends the AUTHENTICATION REJECT message upon receiving an AUTHENTICATION FAILURE message from the UE. This terminates the 5G AKA procedure. Certain AUTHENTICATION FAILURE messages have higher thresholds for the network to send the AUTHENTICATION REJECT message.

In this example, I changed the UE “K” value so that a mismatch occurs.

The UE receives the AUTHENTICATION REQUEST from the 5GC and determines the MAC is stale and sends AUTHENTICATION FAILURE with cause 20.

The 5GC then sends the UE an AUTHENTICATION REJECT message and terminates the 5G AKA process.

Registration Reject (8.2.9)

Registration Reject cause codes can be configured with Open5GS in the amf.yaml config file

There are a handful of various behaviors a UE will conduct upon receiving a Registration Reject message. This is generally the first type of rejection a UE may encounter during the initial Registration procedure. The UE can also be rejected during mobility and periodic registration events. For certain reject causes, the UE holds a record known as the “Registration Attempt Counter” which limits the number of subsequent network rejects. This counter resets when the UE is powered back on, completes a successful registration, or selects a new PLMN.

Some of the more common reject causes that are encountered are…

(15 No Suitable Cells in Tracking Area) Normally, this occurs if the UE is not in the Serving network subscriber database or requests service when it is not allowed in the user’s subscription.

• Registration Attempt Counter: 1
• UE Behavior: UE will be rejected from the serving Tracking Area and receive an RRC Release message that puts the UE back into idle mode. The UE will search for another Tracking Area in its configured PLMN.

(22 Congestion) Sent by the network when there is no channel available, resources are not available, or is otherwise “busy”.

• UE Behavior: The UE will be rejected and attempt Registration again after ~10 seconds. The UE will attempt this 5 times. If the UE has not successfully registered with the network, then the UE will enter Idle mode. After ~12 minutes, the UE will re-attempt to register with the network if it has not successfully registered elsewhere.
  • T3502 Timer defines 12 minutes from Registration Failure to next Registration attempt.

Here, you can see from the amf.log that the AMF receives a REGISTRATION REQUEST every ~10 seconds for five consecutive iterations. At that point, the UE starts the T3502 timer (12 minutes).

(11 PLMN Not Allowed) This is an interesting reject code. You would think that if a UE was not allowed to access a PLMN it would not attempt to re-register with that PLMN. Though with any testing I have conducted using this reject code, the UE continuously attempts to Register with the network with no observed limit to the number of attempts.

When the UE sends its initial REGISTRATION REQUEST it includes its last assigned 5G GUTI and TAI

After receiving the REGISTRATION REJECT with cause 11 it erases its last known GUTI and TAI and sends a REGISTRATION REQUEST with it’s SUCI and no TAI information

UE Emulators (UERANSIM and srsUE) only receive a single reject and do not re-attempt Registration Procedure with the network.

UERANSIM outputs “UE switches to state “5U3-ROAMING-NOT-ALLOWED” followed by “MM-DEREGISTERED/PLMN-SEARCH” which is in line with the 3GPP spec regarding this reject cause (5.5.1.2.5 – Initial Registration not accepted by the network)

Lastly, UERANSIM enters state “5GMM-DEREGISTERED/NO-CELL-AVAILABLE” after no other cells are found for selection.

srsUE has very similar behavior to UERANSIM

The amf.log shows the 5GC receiving the REGISTRATION REQUEST, followed by the REGISTRATION REJECT, which is sent to the gNB. The AMF also conducts the UE Context Release command internally and to the gNB, the gNB responds with UE Context Release Complete.

5GMM Status (8.2.29)

The 5GMM STATUS message is sent by the UE or by the AMF at any time to report certain error conditions.

      3GPP TS 24.501 – 8.2.29 “5GMM Status”

(91 DNN not supported or not subscribed in the slice)

In this scenario, I set the DNN/APN in the subscriber database to ‘internet’ when the UE’s APN was configured for ‘apn’.

The UE Registers with the network and then submits the PDU SESSION ESTABLISHMENT REQUEST with ‘DNN: apn’.

UE Behavior: In the following pcap overview, you can see that the UE sends a PDU SESSION ESTABLISHMENT REQUEST approximately every 16 seconds. This is due to the T3580 timer that defines the UE sending the PDU SESSION ESTABLISHMENT REQUEST and is in the state of “PDU Session Active Pending.”

Conclusion

This only scratches the surface regarding reject causes, behaviors, scenarios, and more. I will cover more of these in follow-up posts and update any new findings. Thanks for reading!