5G Troubleshooting

Registration Reject Cause Analysis

REGISTRATION REJECT means the network received the registration attempt and actively rejected it. This is different from access barring, RRCReject, or a transport problem where the message never reaches the core. This page helps you decode the reject itself, starting with the 5GMM cause, any retry or back-off timers, and the most likely core, mobility, subscription, or policy problem behind it.

Use this page after you have already confirmed that the UE got far enough to send a valid Registration Request and receive an explicit NAS response.

Where Registration Reject Sits in the Procedure Chain

Use this page only when a real explicit reject exists, not when access, RRC, or NGAP delivery failed before the AMF returned a NAS outcome.

Before reject can happen

  • UE selected a suitable cell
  • access and RRC establishment succeeded far enough
  • Registration Request was delivered toward the AMF
  • identity and early registration processing began

Baseline Successful Flow vs Reject Flow

Use these simplified ladders to separate a clean registration outcome from a true explicit reject path.

Call Flow: Successful Registration

Successful 5G registration call flow Registration Request is forwarded to the AMF side, checks complete successfully, and Registration Accept returns to the UE. UE gNB / NG-RAN AMF / AUSF / UDM 1. Registration Request 2. Authentication, policy, security, and mobility checks 3. Registration Accept

Call Flow: Explicit Registration Reject

Explicit 5G Registration Reject call flow Registration Request reaches the AMF side, reject checks run, and Registration Reject returns with cause and optional timer or NSSAI information. UE gNB / NG-RAN AMF / AUSF / UDM 1. Registration Request 2. Identity, auth, mobility, subscription, or slice checks produce an explicit NAS denial 3. Registration Reject 4. 5GMM cause plus optional timers, Rejected NSSAI, or EAP message

Fast Triage by Cause Family

Group the reject into a cause family first, then decide which logs, timers, and policy systems actually matter.

Identity and authentication family

  • illegal UE
  • UE identity cannot be derived by the network
  • synch failure

Mobility and area restriction family

  • PLMN not allowed
  • tracking area not allowed
  • roaming not allowed in this tracking area
  • no suitable cells in tracking area

Service and subscription restriction family

  • 5GS services not allowed
  • non-3GPP access to 5GS not allowed
  • N1 mode not allowed

Security mismatch family

  • UE security capabilities mismatch

Congestion and retry-control family

  • congestion
  • network-controlled back-off behavior with T3346 or T3502

Slice and serving-network authorization family

  • no network slices available
  • serving network not authorized

Registration Reject Message Checkpoints

Registration Reject is more than a single cause code. Timer and NSSAI context can change the right troubleshooting branch completely.

Mandatory first check

Optional IEs that change troubleshooting

Why these IEs matter

Timer values change retry behavior, and Rejected NSSAI can show that the denial is slice-specific rather than a total mobility or subscription failure.

Identity and Authentication Reject Causes

These causes point first to identity handling, subscriber state, authentication consistency, or AUSF and UDM-side context. For the identifier relationships behind this branch, see 5GS UE and Network Identities.

Example: Cause #9 identity-derivation failure

Observed behavior
- Registration Request is delivered
- UE receives Registration Reject with 5GMM cause #9

Interpretation
- the network could not derive UE identity from the available registration context

First checks
- SUCI or 5G-GUTI presence and correctness
- AMF context lookup result
- UDM or subscriber identity correlation
- recent identity or key rollover issues

When a reject depends on how the network reads SUCI, SUPI, or 5G-GUTI, use 5GS UE and Network Identities before diving deeper into AMF, AUSF, or UDM logs.

Mobility and Area Restriction Reject Causes

These causes normally point to PLMN, tracking-area, roaming, or mobility-area restrictions rather than authentication or radio quality.

Example: Cause #12 versus #15

Observed behavior
- UE camps and accesses the network
- Registration Reject is returned with cause #12 or #15

Interpretation
- #12 usually points to a direct tracking-area restriction
- #15 points to no suitable cells in the tracking area and has a different operational meaning

First checks
- TAC or TAI planning
- UE forbidden-area handling
- subscription mobility restrictions
- neighbor and reselection design

Service and Subscription Restriction Reject Causes

These causes should move the investigation toward subscription entitlements, access-type policy, and serving-network authorization rather than PHY or RRC behavior.

Security Capability Reject Causes

Cause #23 is high value because it is usually deterministic and ties directly to capability signaling or policy mismatch, not generic radio instability.

Congestion and Retry-Control Reject Causes

Decode both the reject cause and the timer context. A repeat failure may actually be correct UE back-off behavior after an explicit network instruction.

Example: Cause #22 with timer-driven back-off

Observed behavior
- Registration Reject received with cause #22
- T3346 or T3502 is present

Interpretation
- network is applying explicit retry control
- repeated immediate registration attempts may be expected to stop or be delayed

First checks
- timer value in the reject
- AMF congestion condition
- area-specific or AMF-specific overload pattern
- whether multiple UEs in the same area see the same timer-driven denial

Slice and NSSAI-Related Reject Analysis

Cause #62 plus Rejected NSSAI is not the same as a pure mobility or authentication denial. It usually points to slice availability, authorization, or area support.

Example: Cause #62 with Rejected NSSAI

Observed behavior
- Registration Reject received
- 5GMM cause #62
- Rejected NSSAI present

Interpretation
- network is denying registration in the requested slice context
- this may be area-specific, subscription-specific, or AMF or slice-support-specific

First checks
- requested NSSAI
- allowed NSSAI from subscription data
- slice support in the serving area
- AMF slice policy and routing

Registration Reject Cause Decoder Table

Use this table only after you confirm a true explicit Registration Reject case.

Identity / Authentication

  • #3 Illegal UE
  • #9 UE identity cannot be derived by the network
  • #21 Synch failure

Mobility / Area

  • #11 PLMN not allowed
  • #12 Tracking area not allowed
  • #13 Roaming not allowed in this tracking area
  • #15 No suitable cells in tracking area

Service / Mode / Access

  • #7 5GS services not allowed
  • #27 N1 mode not allowed
  • #72 Non-3GPP access to 5GS not allowed
  • #73 Serving network not authorized

Security

  • #23 UE security capabilities mismatch

Congestion / Retry

  • #22 Congestion

Slice / Policy

  • #62 No network slices available

Practical Troubleshooting Workflow

Decode the cause family first, then pull the right system logs and retry context instead of treating every reject as a generic registration failure.

2. Capture the first hard evidence

  • exact 5GMM cause
  • T3346 or T3502 if present
  • Rejected NSSAI if present
  • EAP message if present

3. Map the cause into a root-cause family

  • identity or authentication
  • mobility or area
  • subscription or service
  • security capability
  • congestion or retry
  • slice or network authorization

4. Correlate with the right systems

  • AMF logs
  • AUSF or UDM logs
  • subscription and roaming policy
  • slice policy and area support
  • UE NAS trace and timers

5. Avoid false branches

  • do not treat Registration Reject like RRCReject
  • do not blame NGAP delivery if reject is explicit and decoded
  • do not start slice troubleshooting for a pure identity or area cause

Evidence Checklist for Escalation

Escalation should carry the reject itself, the timer and NSSAI context, and the minimum core and mobility identifiers needed to explain why the denial occurred.

Minimum core evidence

  • AMF decision reason
  • AUSF or UDM result if authentication-related
  • subscription policy if service-related
  • slice admission or authorization result if NSSAI-related

Minimum radio and context evidence

  • current PLMN
  • current TAC or TAI
  • roaming state
  • selected cell and area
  • whether earlier access and RRC establishment succeeded normally

Minimum identifiers

  • SUPI or masked identity
  • 5G-GUTI if present
  • AMF identity
  • TAC or TAI
  • requested NSSAI if relevant

Specification Map

  • TS 24.501: Registration Reject message, 5GMM causes, and timer behavior
  • 5G Timers and Constants: timer reference for T3346, T3502, and related retry timing context
  • TS 23.502: registration procedure context over 3GPP access
  • TS 38.331: only relevant as precondition context when access succeeded before reject

FAQ

What is the difference between Registration Reject and RRCReject?

Registration Reject is an explicit NAS denial from the network after the registration procedure has already reached the AMF-side decision path. RRCReject is earlier and blocks the UE at the radio-access stage before a full NAS registration outcome exists.

Which Registration Reject causes point to area restrictions?

The most useful area-related causes are #11, #12, #13, and #15. Those usually point to PLMN selection, tracking-area policy, roaming restrictions, or mobility-area constraints rather than authentication failure.

Which causes usually point to authentication or identity problems?

The highest-value identity and authentication causes are #3, #9, and #21. Those usually push the investigation toward identity derivation, subscriber context, USIM state, or AUSF and UDM-side consistency.

When does cause #62 indicate slice-related denial?

Cause #62 becomes especially meaningful when Rejected NSSAI is also present or when the requested NSSAI clearly differs from what the serving area or subscription allows. That usually points to slice availability, slice authorization, or AMF slice-support scope.

Why do T3346 or T3502 matter in Registration Reject analysis?

Those timers change the UE retry behavior after an explicit reject. A repeat registration failure may actually be the UE correctly obeying network back-off instructions, so timer context matters as much as the reject cause in congestion and retry analysis.

When should I treat Registration Reject as a subscription issue instead of a radio issue?

Treat it as a subscription, service, or policy issue once you have confirmed a real explicit Registration Reject was delivered and decoded. At that point the failure is no longer a pure access or transport problem, because the network has already reached a NAS decision and sent a rejection back to the UE.

Related Pages