5G NR Initial Registration Procedure Call Flow
5G NR Initial Registration is the 5GS entry procedure that turns a reachable NR UE into a registered subscriber with valid identity, authentication, and NAS security context.
It joins RRC access, NAS registration, subscriber authentication, and security activation into one control path.
Introduction
The 5G Initial Registration procedure appears when the UE powers on, loses old registration context, or otherwise needs a fresh registration inside the 5G core.
The main nodes are the UE, gNB, AMF, AUSF, and UDM. The final messages tell you whether the UE truly reached a usable registered state for later service procedures.
What Is Initial Registration in Simple Terms?
- What starts the procedure: The UE needs fresh 5GS registration and no longer has usable registration context.
- What the UE and network want to achieve: Create a valid 5GS registration with authentication and protected NAS signaling.
- What success looks like: The UE receives Registration Accept and returns Registration Complete.
- What failure means: The procedure stops on access, identity, authentication, security, or policy-related registration failure.
Why this procedure matters
Initial Registration is the baseline 5G onboarding procedure. It determines whether the UE is known, trusted, reachable, and allowed to continue toward sessions, paging, mobility, and IMS-based services.
Quick Fact Sheet
| Procedure name | 5G NR Initial Registration Procedure |
|---|---|
| Domain | 5G NR + 5GC access and registration |
| Main trigger | UE powers on, loses stored context, or needs a fresh 5GS registration |
| Start state | UE can access NR radio but does not yet have usable 5GS registration context |
| End state | UE is registered in 5GS with valid security context and is reachable for later services |
| Main nodes | UE, gNB, AMF, AUSF, UDM |
| Main protocols | RRC, NAS, NGAP, service-based core authentication and subscriber handling |
| Main success outcome | Registration Accept and Registration Complete finalize a valid registered state |
| Main failure outcome | Registration Reject, authentication failure, security failure, or rejected slice or policy context |
| Most important messages | Registration Request, Authentication Request, Authentication Response, Security Mode Command, Registration Accept, Registration Complete |
| Main specs | TS 23.502, TS 24.501, TS 33.501, TS 38.300, TS 38.331 |
Preconditions
- The UE can access a valid NR cell and build the radio-control path.
- The UE has usable identity context such as SUCI or recoverable temporary identity.
- The AMF can reach subscriber and authentication functions needed for registration validation.
- The UE supports the NAS and security capabilities needed for protected continuation.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Starts the registration path, provides identity and capability context, completes authentication, and confirms the accepted registration result. |
| gNB | Provides NR radio access and forwards NAS signaling between the UE and the AMF. |
| AMF | Owns the registration control flow, validates UE identity and security context, and returns the final registration result. |
| AUSF | Supports subscriber authentication for the UE during the 5GS entry procedure. |
| UDM | Provides subscriber profile, subscription, and identity-related data used during registration. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| NR-Uu | UE <-> gNB | Carries RRC setup and the NAS containers that start the 5GS registration procedure. |
| N1 | UE <-> AMF | Carries Registration Request, authentication, security, and registration completion signaling. |
| N2 | gNB <-> AMF | Carries control-plane relay signaling between the access network and the AMF. |
| N8 / N12 | AMF <-> UDM / AUSF | Carry subscriber-data and authentication handling during 5GS onboarding. |
End-to-End Call Flow
UE gNB AMF AUSF / UDM
| | | |
|-- RRC Setup ---->| | |
|-- Registration Request ----------->| |
| | |-- auth / profile ->|
| | |<-- vectors / data --|
|<-- Authentication Request ---------| |
|-- Authentication Response -------->| |
|<-- Security Mode Command ----------| |
|-- Security Mode Complete --------->| |
|<-- Registration Accept ------------| |
|-- Registration Complete ---------->| |Major Phases
| Phase | What happens |
|---|---|
| 1. Access setup | The UE first establishes the radio-control path so it can deliver the first NAS registration message. |
| 2. Registration start | The UE sends Registration Request with identity, registration type, capabilities, and requested slice context. |
| 3. Authentication and security | The network validates the subscriber and activates NAS protection before allowing later registration continuation. |
| 4. Registration acceptance | The AMF returns Registration Accept with the final registration outcome and updated context. |
| 5. Completion | The UE sends Registration Complete and the registration path closes cleanly. |
Step-by-Step Breakdown
RRC access establishment
Sender -> receiver: UE -> gNB
Message(s): RRC Setup Request, RRC Setup, RRC Setup Complete
Purpose: Open the first dedicated radio-control path needed for the NAS registration exchange.
State or context change: UE moves from basic cell access toward a signaling-ready state.
Note: If this leg fails, the rest of the registration analysis is meaningless because NAS never really started.
Registration Request delivery
Sender -> receiver: UE -> gNB -> AMF
Message(s): Registration Request
Purpose: Start the 5GS registration procedure using fresh or recoverable UE identity context.
State or context change: AMF creates the early registration transaction and begins evaluating identity, subscription, and requested slice context.
Note: Registration type, SUCI or GUTI use, requested NSSAI, and UE security capability are the first high-value checks here.
Authentication procedure
Sender -> receiver: AMF <-> AUSF / UDM and AMF -> UE -> AMF
Message(s): Authentication Request, Authentication Response
Purpose: Verify that the UE is a legitimate subscriber before allowing the registration to continue.
State or context change: Subscriber identity and authentication state become trusted enough for protected continuation.
Note: RAND, AUTN, RES*, and any sync-failure branch are the first items to inspect when registration stalls at authentication.
NAS security activation
Sender -> receiver: AMF -> UE -> AMF
Message(s): Security Mode Command, Security Mode Complete
Purpose: Activate NAS encryption and integrity protection for later registration signaling.
State or context change: The registration exchange transitions from early unprotected handling into protected NAS signaling.
Note: Algorithm negotiation mistakes often surface here even when identity and authentication looked healthy.
Registration acceptance and completion
Sender -> receiver: AMF -> UE -> AMF
Message(s): Registration Accept, Registration Complete
Purpose: Return the final registration result and let the UE confirm it applied the accepted context.
State or context change: UE becomes registered and reachable inside the 5GS.
Note: Read the accepted registration area, allowed NSSAI, and returned identity context before assuming later service problems are unrelated.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| Registration Request | NAS | UE -> AMF | Starts the initial 5GS registration path. | Inspect registration type, identity, requested NSSAI, and UE security capability. |
| Authentication Request | NAS | AMF -> UE | Challenges the UE using the 5G subscriber authentication path. | Check RAND, AUTN, timing, and whether the branch matches the subscriber scenario. |
| Security Mode Command | NAS | AMF -> UE | Activates protected NAS continuation after authentication succeeds. | Verify selected algorithms and whether the UE confirms them cleanly. |
| Registration Accept | NAS | AMF -> UE | Returns the accepted registration result and related mobility or slice context. | Check allowed NSSAI, registration area, assigned identity, and timer values. |
| Registration Complete | NAS | UE -> AMF | Closes the registration transaction after the UE accepts the result. | Confirm it arrives promptly and under the expected protected NAS state. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Registration type | The specific registration branch the UE is requesting. | Registration Request | Separates initial registration from mobility, periodic, or emergency update branches. | Wrong branch interpretation sends the analysis in the wrong direction. |
| SUCI or 5G-GUTI | UE identity used at registration start. | Registration Request | Determines how the AMF resolves the subscriber and whether old context can be reused. | Stale identity, malformed SUCI, or wrong expectation about prior context. |
| Requested NSSAI | Slice preferences or requested slice identifiers. | Registration Request and Registration Accept | Explains whether slice admission later affects the registration result. | Unsupported or unauthorized slice requests. |
| UE security capability | Algorithms and capabilities the UE says it supports. | Registration Request and Security Mode Command | Drives protected NAS continuation after authentication. | Capability mismatch or unsupported algorithm negotiation. |
| Allowed NSSAI and timers | Returned service and mobility context after registration succeeds. | Registration Accept | Explain later service access, paging, and update behavior. | Registration succeeds but later service fails because accepted context is narrower than expected. |
Success Criteria
- The UE establishes the first dedicated access signaling path successfully.
- Registration Request reaches the AMF with valid identity and requested context.
- Authentication and NAS security complete cleanly.
- The UE applies Registration Accept and closes the flow with Registration Complete.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| Registration Request is never processed cleanly | The RRC access leg failed or the first NAS relay was incomplete. | RRC setup, Initial UE Message correlation, and first NAS container delivery. | RRC Setup Complete, Registration Request | NR-Uu, N2 | Confirm that the access-side path really delivered the NAS request to the AMF. |
| Authentication fails or restarts repeatedly | Subscriber credentials, sync state, or home-side authentication context are inconsistent. | Authentication Request, Authentication Response, and any failure cause. | Authentication Request, Authentication Response | N1, N8, N12 | Decide whether the issue is sync recovery, hard reject, or capture incompleteness before changing UE assumptions. |
| Security Mode does not complete | Security capability negotiation failed or NAS protection could not continue cleanly. | Selected algorithms, UE capability, and Security Mode Complete timing. | Security Mode Command, Security Mode Complete | N1 | Treat it as a protected-signaling failure rather than a generic registration reject. |
| Registration Accept is sent but the UE never completes | UE did not apply the accepted context fully or the final uplink message was lost. | Registration Accept contents and Registration Complete timing. | Registration Accept, Registration Complete | N1, NR-Uu, N2 | Confirm whether the UE received the final registration result and whether the return NAS path was intact. |
| Registration is accepted but later service still fails | The registration succeeded, but the returned area, slice, or policy context does not support the expected next procedure. | Allowed NSSAI, registration area, timer values, and the first failing later procedure. | Registration Accept | N1 | Read the accepted context before assuming the failure belongs only to session or IMS procedures. |
What to Check in Logs and Traces
- Start with the registration type and UE identity before analyzing the rest of the trace.
- Correlate the first NAS message with the RRC setup and the Initial UE Message path.
- Check the full authentication branch before assuming the reject is caused by radio conditions.
- Inspect the selected security algorithms and the UE capability that led to them.
- Confirm the UE returned Registration Complete after Registration Accept.
Related Pages
Related sub-procedures
- 5G Authentication Procedure
- 5G NAS Security Mode Procedure
- 5G Mobility Registration Update
- 5G PDU Session Establishment
Related message reference pages
Related troubleshooting pages
Notes
Initial Registration creates fresh 5GS state. The most useful checks are the registration type, the identity used at start, the authentication result, and whether the UE really completed the final NAS step.
FAQ
What is 5G NR Initial Registration?
It is the first 5GS registration procedure that gives the UE a valid registered state in the 5G core.
How is it different from registration update?
Initial Registration creates the first usable registration context, while update procedures refresh an already registered UE.
What confirms success?
A clean Registration Accept followed by Registration Complete is the practical success pattern.
Does Initial Registration always include authentication?
In normal fresh 5GS onboarding analysis, yes, authentication is expected before protected continuation.
What should I inspect first in a failed trace?
Start with the first failing transition: RRC access, Registration Request content, authentication, security activation, or final acceptance.