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
Registration outcome branches
- Registration Accept
- Registration Reject
- lower-layer failure with no explicit reject
- release or retry without NAS reject
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
Call Flow: Explicit Registration Reject
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.
- Cause #3: Illegal UE
- Cause #9: UE identity cannot be derived by the network
- Cause #21: Synch failure
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.
- Cause #11: PLMN not allowed
- Cause #12: Tracking area not allowed
- Cause #13: Roaming not allowed in this tracking area
- Cause #15: No suitable cells in tracking area
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.
- Cause #22: Congestion
T3346handlingT3502handling
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.
- Cause #62: No network slices available
Rejected NSSAIinterpretation- Requested NSSAI versus allowed NSSAI
- Slice availability versus slice authorization
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.
1. Confirm it is a true Registration Reject case
- Registration Request sent
- explicit Registration Reject received
- reject decoded successfully
2. Capture the first hard evidence
- exact
5GMM cause T3346orT3502if presentRejected NSSAIif presentEAP messageif 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 NAS evidence
- Registration Request
- Registration Reject
- decoded
5GMM cause - optional timer values
Rejected NSSAIif present
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 behavior5G Timers and Constants: timer reference forT3346,T3502, and related retry timing contextTS 23.502: registration procedure context over 3GPP accessTS 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.