Why Registration Matters
Every UE interaction with a 5G network begins with the Registration procedure. Until the UE completes registration, it cannot request PDU sessions, receive paging, or execute any service. The procedure is defined in 3GPP TS 24.501 Section 5.5.1 and involves coordinated signaling across the UE, gNB, AMF, AUSF, UDM, and SEAF.
Registration serves four distinct purposes: initial registration after power-on, mobility registration when the UE enters a new registration area, periodic registration to confirm the UE is still reachable, and emergency registration for unauthenticated emergency services.
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 |
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)
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)
- 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.