5G Network-Initiated Deregistration Procedure Call Flow
5G network-initiated deregistration is the control procedure used when the core decides the UE must stop using its current registration context.
It combines reachability handling, NAS deregistration signaling, and cleanup of access or session state so the old registration does not remain partially active.
Introduction
The network-initiated deregistration procedure is different from UE-originated deregistration because the decision starts inside the network rather than at the UE.
In live traces it often appears after paging support, AMF policy action, security-related cleanup, or context correction after service inconsistencies. The practical analysis goal is to verify that the UE received the request, understood which registration branch was being removed, and that the network cleaned up the remaining state consistently.
What Is Network-Initiated Deregistration in Simple Terms?
- What starts the procedure: The network decides that the UE registration must be withdrawn.
- What the UE and network want to achieve: Remove outdated or invalid 5G registration state cleanly.
- What success looks like: The UE receives Deregistration Request, returns Deregistration Accept, and later performs fresh registration when needed.
- What failure means: The UE never got the order, the response was lost, or part of the network kept stale context after cleanup.
Why this procedure matters
This procedure is one of the cleanest ways to retire invalid 5G registration state. If engineers miss it, later registration or service problems can be misdiagnosed as random mobility or session faults when they are actually leftovers from incomplete deregistration cleanup.
Quick Fact Sheet
| Procedure name | 5G Network-Initiated Deregistration Procedure |
|---|---|
| Domain | 5G NR + 5GC registration removal and service withdrawal |
| Main trigger | Core network decides the UE registration context must be removed or invalidated |
| Start state | UE is registered and reachable, or at least known, in the 5GC |
| End state | UE registration context is released or marked unusable, and the UE must not rely on the old access context |
| Main nodes | UE, gNB, AMF, UDM, SMF |
| Main protocols | NAS, RRC, NGAP, service and session release coordination |
| Main success outcome | UE receives deregistration instruction, confirms with Deregistration Accept, and associated access or session context is cleaned up |
| Main failure outcome | UE misses the deregistration signaling, context remains partially stale, or later access attempts hit inconsistent state |
| Most important messages | Deregistration Request (UE terminated), Deregistration Accept, paging or access restoration when needed |
| Main specs | TS 23.502, TS 24.501, TS 38.300, TS 38.331 |
Preconditions
- The UE has an existing 5G registration context known to the AMF.
- The network has a reason to invalidate or remove that context.
- The access side can either reach the UE immediately or restore enough signaling to deliver the NAS request.
- Session-side cleanup logic is available if active or resumable PDU sessions are affected.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Receives the network deregistration order, clears the affected registration context, and answers with Deregistration Accept when reachable. |
| gNB | Provides the radio and N2 transport path so the AMF can reach the UE, often after paging or temporary access restoration. |
| AMF | Starts the network-initiated deregistration path, tracks the affected UE registration, and coordinates cleanup with access and session functions. |
| UDM | May influence the deregistration trigger when subscription, reachability, or policy context changes require the old registration to be withdrawn. |
| SMF | Releases or updates session-side context when deregistration impacts active or resumable PDU sessions. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| NR-Uu | UE <-> gNB | Carries paging response behavior, temporary access restoration, and the NAS deregistration message toward the UE. |
| N1 | UE <-> AMF | Carries Deregistration Request and Deregistration Accept. |
| N2 | gNB <-> AMF | Carries UE context and paging-related control signaling so the AMF can deliver the deregistration order. |
| N11 | AMF <-> SMF | Used when deregistration forces session cleanup, deactivation, or policy-driven release handling. |
End-to-End Call Flow
UE gNB AMF SMF / UDM
| | | |
|<----- Paging ----| | |
|-- temporary access restore -------->| |
|<-- Deregistration Request ----------| |
|-- Deregistration Accept ----------->| |
| | |-- cleanup -------->|
| | |<-- release done ---|
|==== Old registration context removed ===================>|Major Phases
| Phase | What happens |
|---|---|
| 1. Deregistration decision | The core determines that the current UE registration must be withdrawn because of subscription, administrative, security, or reachability reasons. |
| 2. UE reachability handling | If the UE is not already in active signaling state, the network restores enough access context to deliver the NAS deregistration message. |
| 3. NAS deregistration delivery | The AMF sends Deregistration Request so the UE knows the old registration is no longer valid. |
| 4. UE confirmation and context removal | The UE clears the affected context and returns Deregistration Accept when possible. |
| 5. Cleanup | The network removes remaining access or session state so later service attempts do not keep using stale registration context. |
Step-by-Step Breakdown
Network decides to remove the UE registration
Sender -> receiver: Core policy or mobility logic -> AMF
Message(s): Internal deregistration trigger, subscription or administrative action
Purpose: Start a controlled teardown of the old 5G registration context.
State or context change: The AMF marks the current registration as no longer acceptable for continued service.
Note: Read the trigger carefully because it explains whether the later failure is policy-driven, security-driven, or just cleanup after topology change.
Reachability and access restoration if needed
Sender -> receiver: AMF -> gNB -> UE
Message(s): Paging or temporary signaling restoration
Purpose: Ensure the UE can actually receive the deregistration order.
State or context change: The UE becomes reachable enough for the N1 NAS exchange.
Note: If the UE never gets the deregistration message, later traces may look like random registration failure when the real issue was delivery.
Network sends Deregistration Request
Sender -> receiver: AMF -> UE
Message(s): Deregistration Request (UE terminated)
Purpose: Tell the UE that the old registration is being terminated by the network.
State or context change: The UE must stop trusting the previous registration state and prepare to clear related context.
Note: The deregistration type and cause are the first items to inspect when deciding how broad the cleanup should be.
UE clears context and responds
Sender -> receiver: UE -> AMF
Message(s): Deregistration Accept
Purpose: Confirm that the UE received the network order and removed the relevant registration context.
State or context change: The old registration becomes formally closed on both UE and network sides.
Note: Missing Accept does not always mean the UE ignored the request; sometimes the radio leg or relay path was lost during cleanup.
Network releases remaining service state
Sender -> receiver: AMF <-> SMF and access side
Message(s): Context release and session cleanup handling
Purpose: Prevent stale access or session resources from surviving after deregistration.
State or context change: The UE must use a fresh registration path before normal service resumes.
Note: This phase explains why data or paging can still fail even after a seemingly clean NAS deregistration exchange.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| Deregistration Request (UE terminated) | NAS | AMF -> UE | Orders the UE to clear the current registration context. | Inspect the deregistration type, cause, and whether the UE had to be paged first. |
| Deregistration Accept | NAS | UE -> AMF | Confirms that the UE accepted network-initiated deregistration. | Check whether it arrives on time and whether the right registration branch is being cleared. |
| Paging | RRC | Network -> UE | Makes the UE reachable so the AMF can deliver the deregistration order when the UE is passive. | Confirm that the page reaches the UE on the right tracking area and serving cell. |
| Service Request | NAS | UE -> AMF | May appear only as temporary access restoration support before deregistration delivery. | Do not misread it as successful service continuation if a deregistration sequence follows immediately after. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Deregistration type | Tells the UE what kind of registration removal is being requested. | Deregistration Request | Defines how much context the UE should clear and what follow-up behavior is expected. | Wrong interpretation can cause partial cleanup or confusing retries. |
| 5G-GUTI or UE identity | The identity tying the deregistration to the correct registration context. | N1 and N2 context correlation | Lets you prove the network removed the intended UE state. | Stale identity leads to traces that look mismatched or duplicated. |
| Cause or trigger context | Reason the network initiated deregistration. | Deregistration Request and AMF-side context | Explains whether the path is administrative, security, policy, or mobility-driven. | If absent from your analysis, you can misclassify a valid deregistration as a fault. |
| Session cleanup indicators | Whether PDU sessions also need release or deactivation work. | AMF/SMF coordination after deregistration | Useful for predicting whether the next UE action should be fresh registration plus session rebuild. | Partial session cleanup often leaves misleading downstream failures. |
| Paging and access state | How the UE became reachable for the order. | Paging and context restore path | Separates delivery failures from actual NAS rejection or UE noncompliance. | Wrong TAC, stale gNB context, or paging timeout. |
Success Criteria
- The network reaches the UE and delivers the deregistration order cleanly.
- The UE returns Deregistration Accept or otherwise behaves consistently with context removal.
- The AMF and any affected session functions release the stale state cleanly.
- Later access attempts use a fresh registration path instead of misusing old context.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| Deregistration Request never reaches the UE | The UE was not reachable or the access restore leg failed. | Paging outcome, temporary access setup, and N2 context delivery. | Paging, Deregistration Request | NR-Uu, N2, N1 | Treat this as a delivery issue first. The AMF may have behaved correctly while the UE never saw the order. |
| UE sends no Deregistration Accept | The UE did not complete the return leg or the response was lost. | Uplink NAS relay, radio continuity, and whether the UE cleared context locally anyway. | Deregistration Accept | N1, NR-Uu, N2 | Look for partial completion rather than assuming the UE ignored the request. |
| Later service attempts fail unexpectedly | Old session or access state survived in one part of the network. | AMF/SMF cleanup and the next Registration Request. | Deregistration Request, Registration Request | N1, N11 | This usually means cleanup was asymmetric, not that deregistration itself was unnecessary. |
| Repeated paging before deregistration | The network is trying to reach a UE that is only intermittently reachable. | Paging history, TAC correctness, and cell-level response timing. | Paging | NR-Uu, N2 | Fix reachability first or the deregistration procedure will keep appearing incomplete. |
What to Check in Logs and Traces
- Start by proving the network had a real reason to withdraw the registration, such as policy, security, subscription, or context-correction handling.
- Check how the UE became reachable for the deregistration order and whether paging succeeded cleanly.
- Inspect the deregistration type and cause in Deregistration Request.
- Verify whether Deregistration Accept returned or whether cleanup continued without a clean UE response.
- Use the next registration or service attempt to confirm that the old state was really retired across the network.
Related Pages
Related sub-procedures
Related message reference pages
Related troubleshooting pages
Notes
Network-initiated deregistration is a cleanup and control-consistency procedure. Many apparent failures are really reachability or asymmetric cleanup problems rather than incorrect deregistration logic.
FAQ
What is network-initiated deregistration in 5G?
It is the procedure where the network tells the UE that its current registration context must be removed or is no longer valid.
Why would the network deregister a UE?
Common reasons include policy or subscription changes, security concerns, administrative cleanup, or context consistency issues after mobility or failures.
Does the UE always answer with Deregistration Accept?
That is the normal clean outcome when the UE receives the NAS request and can respond over the available access path.
What happens after network-initiated deregistration?
The UE normally needs a fresh registration path before normal 5G service can continue.
What should I inspect first in a failed trace?
Start with whether the UE was reachable enough to receive Deregistration Request, then check the deregistration type, the Accept, and the downstream cleanup.