Registration Types
3GPP defines the registration type in the 5GS registration type IE carried in the Registration Request message. The encoding uses a 3-bit value per TS 24.501 Table 9.11.3.7.1.
| Registration Type | Bit Value | Trigger | AMF Behavior |
|---|
| Initial registration | 001 | Power-on, USIM change, entering new PLMN | Full authentication, new GUTI allocation |
| Mobility registration update | 010 | UE moves outside current registration area | TAI list update, optional re-authentication |
| Periodic registration update | 011 | T3512 timer expiry | Confirms UE reachability, resets implicit deregistration timer |
| Emergency registration | 100 | Emergency call without normal registration | Limited service, no NSSAI negotiation |
Complete Message Flow
The initial registration procedure involves a minimum of 8 NAS messages exchanged between the UE and the network. The table below captures the full sequence as specified in TS 24.501 Section 5.5.1.2.
| Step | Direction | Message | Key Actions |
|---|
| 1 | UE -> gNB | RRC Setup Request | Triggers RRC connection establishment |
| 2 | UE -> AMF | Registration Request | Carries 5GS mobile identity (SUCI or 5G-GUTI), requested NSSAI, UE security capability |
| 3 | AMF -> AUSF | Nausf_UEAuthentication_Authenticate | AMF initiates authentication via SBI; AUSF fetches vectors from UDM |
| 4 | AMF -> UE | Authentication Request | Contains RAND and AUTN from the AV; triggers USIM-based verification |
| 5 | UE -> AMF | Authentication Response | Returns RES* computed by the USIM |
| 6 | AMF -> UE | Security Mode Command | Selects ciphering algorithm (e.g., NEA2) and integrity algorithm (e.g., NIA2); includes IMEISV request |
| 7 | UE -> AMF | Security Mode Complete | Confirms security activation; may include the Registration Request in a NAS container for integrity protection |
| 8 | AMF -> UDM | Nudm_UECM_Registration | Registers AMF address in UDM for this SUPI |
| 9 | AMF -> UE | Registration Accept | Assigns 5G-GUTI, TAI list, allowed NSSAI, T3512 value, LADN information |
| 10 | UE -> AMF | Registration Complete | Acknowledges new 5G-GUTI; completes the procedure |
In production networks, steps 3-5 may be skipped if the AMF already holds a valid security context from a previous registration (e.g., during mobility registration update).
Registration Request IE Breakdown
The Registration Request is the most information-dense NAS message the UE sends. Its full IE structure is specified in TS 24.501 Table 8.2.6.1.1. Below are the critical IEs that engineers must understand.
| IE Name | IEI | Length | Purpose |
|---|
| 5GS registration type | -- | 1/2 octet | Indicates initial, mobility, periodic, or emergency |
| 5GS mobile identity | -- | Variable | SUCI (encrypted SUPI) for initial, 5G-GUTI for subsequent |
| NAS key set identifier | -- | 1/2 octet | Identifies the cached ngKSI for security context reuse |
| Requested NSSAI | 2F | 4-74 octets | List of S-NSSAIs the UE wants; each is SST (1 byte) + optional SD (3 bytes) |
| UE security capability | 2E | 4-10 octets | Bitmask of supported 5G-EA and 5G-IA algorithms |
| 5GMM capability | 10 | 3-15 octets | Indicates support for features like S1 mode, LPP, HO attach |
| UE status | 2B | 3 octets | Reports whether UE has valid EPS bearer context |
| Additional GUTI | 77 | 13 octets | 4G GUTI for interworking during EPS-to-5GS mobility |
| Requested DRX parameters | 51 | 3 octets | Extended DRX cycle preference for power saving |
SUCI Encoding
When the UE performs initial registration without a valid 5G-GUTI, it must send the SUCI (Subscription Concealed Identifier). The SUCI is generated by encrypting the MSIN portion of the SUPI using the ECIES-based protection scheme defined in TS 33.501 Section 6.12. The home network public key is provisioned on the USIM. This prevents IMSI catching attacks that plagued 4G.
NSSAI Negotiation
The UE sends its Requested NSSAI containing up to 8 S-NSSAIs. The AMF compares this against the Configured NSSAI from the UDM and the Subscribed S-NSSAIs to produce the Allowed NSSAI returned in the Registration Accept. If the requested slice is not available in the current registration area, the AMF may trigger a re-routing to a target AMF that serves that slice.
Timer Framework
NAS timers govern retransmission, backoff, and periodic behavior. Misconfigured timers are a frequent cause of registration storms and signaling overload. The key timers are specified across TS 24.501 Sections 10.2 and 10.3.
| Timer | Started At | Default Value | Expiry Action | Configurable By |
|---|
| T3510 | UE sends Registration Request | 15 s | UE retransmits Registration Request (up to 5 attempts) | UE implementation |
| T3502 | Registration reject with cause #22 | 12 min | UE reattempts registration | Network (via Registration Reject IE) |
| T3511 | Registration reject with certain causes | 10 s | UE retries registration | UE implementation |
| T3512 | Registration Accept received | 54 min | Triggers periodic registration update | Network (via Registration Accept IE) |
| T3346 | Congestion-based reject (cause #22) | 1-1860 s | UE waits before retry; honors back-off | Network (mandatory) |
| T3510 (extended) | Registration in high-load scenario | 15 s base | Exponential backoff with randomization | UE implementation |
Timer Interaction Example
Consider a UE that sends a Registration Request and starts T3510 (15 s). If the network is overloaded and the AMF sends a Registration Reject with cause #22 (Congestion) and a T3346 value of 120 seconds, the UE must:
- Stop T3510
- Start T3346 with the network-provided value (120 s)
- Not attempt any registration or service request until T3346 expires
- After T3346 expiry, start T3502 (12 min) if no other trigger occurs
This backoff mechanism, introduced in Release 15 and refined in Release 16, prevents signaling storms during mass-event scenarios (stadiums, natural disasters).
5GMM Cause Codes
When registration fails, the AMF includes a cause code in the Registration Reject message. Engineers troubleshooting registration failures must map these codes to root causes. The full list is in TS 24.501 Table 9.11.3.2.1.
| Cause Code | Value | Meaning | Typical Root Cause |
|---|
| #3 | Illegal UE | USIM barred or blacklisted | Stolen device, operator block |
| #5 | PEI not accepted | IMEI check failed | Device on EIR blacklist |
| #7 | 5GS services not allowed | Subscription does not permit 5G | 4G-only subscription |
| #9 | UE identity cannot be derived | GUTI resolution failed | AMF lost context after restart |
| #10 | Implicitly de-registered | Periodic registration timer expired | UE was unreachable too long |
| #11 | PLMN not allowed | Roaming restriction | UE in non-roaming PLMN |
| #22 | Congestion | Network overload | High signaling load, T3346 backoff |
| #27 | N1 mode not allowed | UE attempted 5G on restricted cell | Coverage or policy restriction |
| #71 | ngKSI already in use | Security context collision | Rare; AMF key management issue |
| #72 | Non-3GPP access to 5GCN not allowed | N3IWF access rejected | Subscription restriction |
Configuration Update Command — the message the spec search always lands on
The registration procedure gets most of the attention, but the message engineers
actually search for by name is CONFIGURATION UPDATE COMMAND (TS 24.501
§5.4.4). It is what the AMF sends when the UE is already registered and something
it was told earlier has changed.
It carries any of: a new 5G-GUTI, an updated TAI list, a revised Allowed NSSAI,
network name and time zone, or a rejected-NSSAI list.
Two bits inside it cause nearly all the confusion.
Registration Requested. If set, the UE must run a registration procedure
after acknowledging. That is why traces show a UE sitting in 5GMM-REGISTERED
and then registering again — it looks like a loop until you know this bit exists.
It is not a fault, and it is how the network forces a re-registration without
tearing anything down.
Acknowledgement Requested. If set, the UE replies with CONFIGURATION UPDATE
COMPLETE. If it is not set, the UE stays silent. An absent COMPLETE is not a missing message — check the bit before you raise a defect.
The AMF guards its side with a retransmission timer. If you see the same
CONFIGURATION UPDATE COMMAND four times at even spacing, the AMF is not
confused; it is retransmitting because no acknowledgement came back, and the
question to ask is why the UE did not answer.
Authentication Reject: the one that does not retry
Every other reject on this page leads to a retry, a back-off, or a search for a
different cell. AUTHENTICATION REJECT does not.
On receiving it, the UE deletes its 5G security context and treats the USIM as
invalid for 5GS until the card is power-cycled. No timer releases it. There
is no attempt counter to exhaust.
That severity is deliberate. A false authentication reject is a denial of service
against one subscriber, which is exactly why the message is integrity-protected
and why a fake base station cannot simply broadcast it.
Two practical consequences:
- In the lab, a device that "stopped attaching for no reason" has often been
handed an AUTHENTICATION REJECT earlier in the session. Reboot before you
debug further, or you are chasing state rather than a fault.
- In the field, it means the failure is on the credential path — the USIM,
the UDM subscription, or the AUSF — never the radio. It is worth skipping the
RF investigation entirely.
Do it on a real trace
Everything above is the theory. The trace is where you find out which case you
are actually in.
The free packet-trace lab below is a registration that fails end to end. Find the
REGISTRATION REJECT, read the 5GMM cause value out of the NAS payload, and decide
whether the fix belongs on the device or in the subscription. Roughly fifteen
minutes, and it is the exact skill the tables on this page support.
→ 5G Registration Failure — packet trace lab — free with an account, no card required.
Worked Example: Tracing a Registration Failure
Scenario: A UE in Tokyo powers on and attempts initial registration on NTT DOCOMO's n78 (3.5 GHz) cell. The Wireshark trace shows:
- Registration Request sent with SUCI (null scheme, MSIN in cleartext -- test USIM)
- Authentication Request/Response completes successfully (RES matches XRES)
- Security Mode Command/Complete activates NEA1/NIA1
- Registration Reject received with cause #7 (5GS services not allowed)
Root cause: The subscription profile in UDM has
RAT-Restrictions = E-UTRA only. The subscriber's plan does not include 5G access. Resolution: Update the subscription in UDM to include
NR in the allowed RAT types.
NTT DOCOMO reported that during their 5G launch in March 2020, approximately 2.3% of initial registration attempts failed with cause #7 due to SIM provisioning delays in the BSS-to-UDM synchronization pipeline.
Worked Example: Calculating Registration Signaling Load
Scenario: An operator with 500,000 5G subscribers in a metro area needs to estimate periodic registration signaling load on the AMF.
Given:
- T3512 = 54 minutes (default)
- 70% of subscribers are connected (350,000 UEs actively registered)
- Each periodic registration generates 4 NAS messages (Request, Security Mode Command/Complete, Accept)
Calculation:
- Registrations per hour per UE = 60 / 54 =
1.11
- Total registrations per hour = 350,000 x 1.11 =
388,500
- NAS messages per hour = 388,500 x 4 =
1,554,000
- NAS messages per second = 1,554,000 / 3600 =
431.7 msg/s
A commercial AMF (e.g., Ericsson Cloud Core AMF) is typically rated for 50,000-100,000 NAS transactions per second, so this load is well within capacity. However, during mass mobility events (commuter trains), the AMF may see 10x spikes in mobility registration updates.
Real Operator Deployments
SK Telecom (South Korea) published data from their Seoul 5G SA network showing a mean initial registration time of
340 ms from Registration Request to Registration Accept, measured across 12 million registration events in Q4 2023. Their AMF processes approximately 8,500 registration transactions per second during peak hours.
Verizon (US) reported that after migrating from NSA to SA mode in C-band markets, the registration success rate improved from 98.2% to 99.6%. The primary improvement came from eliminating the dependency on the EPC for authentication, which removed an inter-system signaling hop that contributed to T3510 timeouts.
Common Troubleshooting Patterns
- Repeated T3510 expiry: Indicates the AMF is not responding. Check SCTP association between gNB and AMF, verify N2 connectivity.
- Cause #9 loops: The UE sends a 5G-GUTI that the AMF cannot resolve. Typically caused by AMF failover where the new AMF does not have the UE context. The UE should fall back to SUCI-based registration.
- NSSAI mismatch: UE receives an empty Allowed NSSAI. Verify that the requested SST/SD combination exists in the AMF's NSSAI configuration and the UDM subscription data.
- Security mode rejection: UE rejects the Security Mode Command if the replayed UE security capability does not match what it sent. This is a man-in-the-middle detection mechanism per TS 24.501 Section 5.4.2.3.
> Key Takeaway: The 5G registration procedure is a multi-step NAS exchange that establishes the UE's identity, security context, and slice access. Mastering the message flow, IE structure, timers, and cause codes is essential for anyone working in 5G core network engineering or troubleshooting.