5G Deregistration Procedure Call Flow
5G Deregistration is the controlled teardown procedure used when the UE decides to remove its current 5GS registration state.
It joins NAS deregistration signaling, core cleanup, and access or session release so stale registration context does not linger after the UE leaves service.
Introduction
The UE-originated deregistration procedure matters because registration teardown is just as important as registration setup. A network that keeps stale state after deregistration can create confusing paging, mobility, and session failures later.
This page focuses on the branch that starts at the UE. The separate network-initiated deregistration page covers the case where the core starts the removal.
What Is Deregistration in Simple Terms?
- What starts the procedure: The UE decides to leave its current 5G registration state.
- What the UE and network want to achieve: Remove the old registration cleanly and release dependent context.
- What success looks like: The network processes Deregistration Request and the old registration is no longer used.
- What failure means: Some access, mobility, or session state survived after the deregistration branch.
Why this procedure matters
Deregistration is the boundary that tells the network to stop treating a UE as currently registered. If that boundary is handled poorly, engineers often see the symptom later as strange paging, failed service request, or stale session behavior rather than as an obvious deregistration problem.
Quick Fact Sheet
| Procedure name | 5G Deregistration Procedure |
|---|---|
| Domain | 5G NR + 5GC registration teardown and context removal |
| Main trigger | UE decides to leave service or stop using its current registration context |
| Start state | UE is registered in 5GS and may still have active reachability or session context |
| End state | UE registration state is removed and the old access or session context must no longer be used |
| Main nodes | UE, gNB, AMF, SMF |
| Main protocols | NAS, NGAP, RRC, session cleanup signaling |
| Main success outcome | Deregistration Request is processed, Deregistration Accept is exchanged when expected, and the UE state is removed cleanly |
| Main failure outcome | The UE or network keeps partial stale context, or the old state is not removed consistently |
| Most important messages | Deregistration Request, Deregistration Accept, UE context release, related session cleanup |
| Main specs | TS 23.502, TS 24.501, TS 38.300, TS 29.244 |
Preconditions
- The UE currently has a valid 5GS registration context.
- The UE can still reach the network well enough to send the deregistration request.
- The AMF can process the removal and coordinate any dependent cleanup.
- If PDU sessions are active or resumable, the session side can also clear them consistently.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Starts the deregistration branch when it powers off, disables service, or otherwise decides to leave the current 5GS registration state. |
| gNB | Relays the NAS deregistration exchange and helps remove access-side UE context. |
| AMF | Processes deregistration, coordinates context removal, and ensures later access attempts use a fresh path. |
| SMF | Supports session release or cleanup when deregistration affects active or resumable PDU sessions. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| NR-Uu | UE <-> gNB | Carries the radio path for the NAS deregistration exchange while the UE is still reachable. |
| N1 | UE <-> AMF | Carries Deregistration Request and Deregistration Accept. |
| N2 | gNB <-> AMF | Relays the deregistration signaling and later access-context release handling. |
| N11 | AMF <-> SMF | Coordinates session cleanup when deregistration implies PDU-session removal or deactivation. |
End-to-End Call Flow
UE gNB AMF SMF
| | | |
|-- Deregistration Request ---------->| |
| | |-- cleanup ------>|
| | |<-- release done -|
|<-- Deregistration Accept -----------| |
|==== old registration context removed =================>|Major Phases
| Phase | What happens |
|---|---|
| 1. Deregistration trigger | The UE decides it should no longer remain registered, often because of power-off, service disablement, or planned exit from current network use. |
| 2. NAS Deregistration Request | The UE sends Deregistration Request to tell the core to remove the current registration context. |
| 3. Network cleanup decision | The AMF decides what access, mobility, security, and session state must be cleared. |
| 4. Deregistration acceptance | The network returns Deregistration Accept when the branch expects explicit confirmation. |
| 5. Context release | Access-side and session-side context are removed so the old registration cannot be reused accidentally. |
Step-by-Step Breakdown
UE decides to leave the current registration state
Sender -> receiver: UE internal mobility or power-management logic
Message(s): Local trigger such as switch-off, service disablement, or planned detach behavior
Purpose: Start a controlled teardown of the current 5GS registration.
State or context change: UE transitions from active registered use toward deliberate registration removal.
Note: The first useful question is whether this is a clean UE-originated branch or whether later traces actually belong to network-initiated deregistration instead.
UE sends Deregistration Request
Sender -> receiver: UE -> gNB -> AMF
Message(s): Deregistration Request
Purpose: Tell the network which registration branch is being removed and under what UE-side condition.
State or context change: AMF starts removing the current UE registration state.
Note: Deregistration type, switch-off behavior, and UE identity are the first fields to inspect.
AMF processes the removal
Sender -> receiver: AMF and optionally SMF
Message(s): Context cleanup and possible session release handling
Purpose: Release registration, mobility, and session state so later network behavior is consistent.
State or context change: The old UE registration becomes invalid for later paging, service request, and mobility handling.
Note: Many downstream issues come from cleanup that was only partially completed, not from the initial request itself.
Network returns Deregistration Accept
Sender -> receiver: AMF -> UE
Message(s): Deregistration Accept
Purpose: Confirm the deregistration result when the UE remains reachable for an explicit response.
State or context change: UE and core agree that the current registration has been removed.
Note: In switch-off variants, practical trace behavior can differ, so always read the branch details before calling the message missing or abnormal.
Remaining access and session resources are released
Sender -> receiver: AMF <-> gNB and AMF <-> SMF
Message(s): UE context release and session cleanup
Purpose: Prevent paging, service restoration, or traffic from trying to reuse stale state.
State or context change: Any later service must start from a fresh registration or fresh session path.
Note: If later traces still show old context being used, the cleanup phase is usually where the inconsistency started.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| Deregistration Request | NAS | UE -> AMF | Starts UE-originated removal of the current registration context. | Check deregistration type, UE identity, and switch-off related indicators. |
| Deregistration Accept | NAS | AMF -> UE | Confirms that deregistration was processed. | Verify whether this branch should include explicit Accept and whether the UE remained reachable for it. |
| UE context release | NGAP | AMF <-> gNB | Removes access-side state after deregistration processing. | Check that RAN-side context actually cleared after the NAS exchange. |
| PDU session cleanup | Core/session | AMF <-> SMF | Releases or deactivates session-side state tied to the old registration. | Confirm that lingering sessions do not survive unexpectedly after deregistration. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Deregistration type | Identifies which registration or service context the UE wants to remove. | Deregistration Request | Defines the exact cleanup scope expected in the network. | If misread, engineers can overestimate or underestimate the intended teardown. |
| Switch-off indication | Shows whether the UE is leaving because it is powering down. | Deregistration Request | Affects what follow-up signaling is realistic to expect. | Misreading this can make a normal switch-off branch look incomplete. |
| UE identity | Identity used to tie the request to the correct registration context. | Deregistration Request and N2 correlation | Lets you verify that the right UE state was removed. | Stale or mismatched identity can confuse trace correlation. |
| Session cleanup scope | Indicates how much PDU-session state must also be removed. | AMF and SMF follow-up handling | Explains whether later traffic failures are normal after deregistration or signs of inconsistent cleanup. | Partial cleanup often leaves misleading downstream symptoms. |
| Post-deregistration reachability state | Whether the UE is still page-able or should now require fresh registration. | AMF state and later traces | Confirms the operational effect of deregistration. | Old reachability state can linger incorrectly if cleanup failed. |
Success Criteria
- The UE sends a valid Deregistration Request using the correct branch.
- The AMF removes the associated registration and mobility context cleanly.
- Any related session-side state is also cleaned up when needed.
- Later network behavior no longer depends on the old registration state.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| Deregistration Request never reaches the AMF | The UE lost access before NAS delivery or the relay path failed. | RRC state, uplink NAS relay, and gNB forwarding. | Deregistration Request | NR-Uu, N2, N1 | Separate access failure from deregistration-logic failure. |
| Deregistration appears successful but paging still happens later | Old reachability or access context survived after cleanup. | AMF state, UE context release, and later paging traces. | Deregistration Accept, Paging | N1, N2 | Focus on incomplete cleanup rather than assuming the UE remained validly registered. |
| PDU sessions still look active after deregistration | Session-side release was only partial or delayed. | AMF/SMF cleanup, session state, and later traffic attempts. | Deregistration Request and session cleanup signals | N11, N4 | Correlate deregistration with the actual session release outcome. |
| UE immediately re-registers after deregistration | The UE intentionally cleared state and then needed fresh service again, or the original deregistration was triggered by transient conditions. | Deregistration type, trigger reason, and the following Registration Request. | Deregistration Request, Registration Request | N1, N2 | This is not always a fault. Check whether the user or device behavior made re-registration expected. |
What to Check in Logs and Traces
- Start with the deregistration type before analyzing cleanup behavior.
- Check whether a switch-off indication is present, because it changes what later signaling is realistic.
- Correlate the UE identity in the NAS request with the access and core context being removed.
- Inspect whether UE context release and any session cleanup actually followed the NAS exchange.
- Use the first later trace after deregistration to confirm that the network really stopped treating the UE as registered.
Related Pages
Related sub-procedures
Related message reference pages
Related troubleshooting pages
Notes
Deregistration is only complete when later network behavior stops using the old context. The best proof is clean teardown plus a fresh registration requirement for any later service need.
FAQ
What is 5G Deregistration?
It is the procedure used to remove a UE registration context from the 5G system so the old state is no longer valid.
How is it different from network-initiated deregistration?
UE-originated deregistration starts at the UE. Network-initiated deregistration starts at the core and is described separately.
Does deregistration always release sessions too?
Often yes in practical deployments, but the exact cleanup scope depends on the deregistration branch and operator handling.
What confirms success?
A valid Deregistration Request, expected network cleanup, and no further reliance on the old registration state.
What should I inspect first?
Start with the deregistration type, switch-off behavior, and whether the later network state really stopped using the old context.