During field troubleshooting, one of the easiest mistakes is to see an RRC Release and assume that UE deregistration has already finished. The radio connection may indeed be gone and the UE may have stopped sending data, but the registration context in the AMF, the PDU Session in the SMF, the N4 session in the UPF, policy associations in the PCF and registration records in the UDM do not disappear at the same moment simply because "the signal is gone." What matters in a signaling trace is the cross-NF cleanup chain that follows the Deregistration Request: how the AMF determines the deregistration scope, how the SMF instructs the UPF to remove user-plane resources, and how far PCF and UDM associations should be released.
UE-initiated Deregistration is the controlled procedure for taking an already registered UE out of the 5GS. It begins with a NAS Deregistration Request and may involve releasing PDU Sessions, deleting N4 sessions and user-plane tunnels in the UPF, terminating SM Policy and AM Policy associations, removing related registration state in the UDM, and finally releasing the signaling connection between the UE and the access network. Normal de-registration and Switch off may look similar during the first part of the procedure, but they end differently: one waits for a Deregistration Accept, while the other does not remain online just to receive confirmation. This distinction is easy to miss when analyzing traces.
Why Is Deregistration More Than Simply Marking the UE Offline?
After a UE completes Initial Registration and establishes a PDU Session, the 5GC does not store just a single "online" flag. The AMF maintains registration and mobility context, the SMF manages PDU Session context, the UPF holds the N4 Session together with user-plane forwarding resources such as FARs, QERs and URRs, the UDM stores AMF and SMF registration relationships, and the PCF may maintain AM, UE or SM Policy Associations.
If the UE simply disappears from the network, these resources are not automatically removed at exactly the same time. This is especially important when one or more PDU Sessions still exist. The network needs to know which sessions should be released, which user-plane rules should be deleted, and which subscriptions or policy associations no longer have any reason to remain.
UE-initiated deregistration therefore performs an orderly teardown of the registration state and its associated resources:
UE indicates that the current 5GS registration should end
→ AMF determines the deregistration scope
→ Related PDU Sessions are released
→ SMF instructs the UPF to remove user-plane resources
→ Session and policy associations are deleted
→ Registration state is removed
→ Access-side signaling connection is released
This is why Deregistration should not be confused with RRC Release or an ordinary N2 connection release. A RAN connection release only means that the current access signaling connection has ended. Deregistration operates at a higher level and removes the 5GS registration relationship together with the session and policy state associated with it. If a trace only shows RRC Release, concluding that the UE has already deregistered can easily mix up "access connection release" with "registration removal."
How Does the Deregistration Request Define How and From Which Access the UE Leaves?
When the UE actively leaves the 5GS, it sends a NAS Deregistration Request to the AMF. For signaling analysis, the first things to inspect are not whether PFCP messages appear later, but the Deregistration type and Access Type carried in the request.
The Deregistration type first tells the network whether the procedure is a Switch off case. In engineering terms, UE-initiated deregistration commonly appears in two situations: Normal de-registration, where the UE performs an orderly exit, and Switch off, where the UE indicates that it is about to power down or enter an equivalent shutdown condition.
Access Type answers a different question: which access is actually being deregistered. The UE may deregister only from 3GPP access, only from non-3GPP access, or, when both access types in the same PLMN are served by the same AMF, the procedure can cover both as applicable. Therefore, "UE deregistration" does not always mean that every access state associated with that UE is removed at once.
The Deregistration Request also carries UE identity information. When a valid 5G-GUTI is available, the UE can use it to help the AMF associate the NAS message with the existing UE context. If no valid 5G-GUTI is available, identity handling depends on the 5GS identity currently available to the UE. From the AMF's perspective, correctly mapping this NAS message to the existing UE context is a prerequisite for releasing the correct PDU Sessions and policy associations.
With Normal de-registration, the UE sends the request and waits for the network to confirm completion. With Switch off, the objective is to deliver the "I am leaving" indication as quickly as possible and then continue the shutdown process, so the handling is different. Normal de-registration may use T3521 to supervise the period in which the UE waits for Deregistration Accept, whereas a Switch off procedure does not wait for network confirmation in the same way.
Why Does the AMF First Check Whether the UE Still Has a PDU Session?
After receiving the Deregistration Request, one of the AMF's key decisions is whether any established PDU Sessions still exist on the target access.
If the UE has no relevant PDU Session, there is no user-plane session to tear down individually, so the procedure can be significantly shorter. If one or more PDU Sessions are still active, however, the AMF cannot simply delete its own registration context because the SMF and UPF would still regard those sessions as existing.
For each PDU Session that needs to be released, the AMF can invoke Nsmf_PDUSession_ReleaseSMContext toward the corresponding SMF. This can be understood as an explicit instruction from the AMF to the session-management layer: the UE is leaving the target access, so the related SM Context should no longer be maintained. Only after receiving this instruction can the SMF continue deleting the N4 session, terminating policy associations and cleaning up relevant UDM registration state.
This also highlights the difference between Deregistration and a standalone PDU Session Release. Releasing one PDU Session does not mean that the UE leaves the 5GS; the UE may remain 5GS Registered. By contrast, when the UE initiates deregistration, any PDU Sessions associated with the target access normally need to be cleaned up as part of the wider deregistration procedure.
Therefore, if a trace shows a Deregistration Request but no Nsmf_PDUSession_ReleaseSMContext afterward, this should not immediately be treated as missing signaling. First confirm whether the UE actually had a PDU Session established on the relevant Access Type. If no PDU Session existed, the absence of an N4 release procedure may be exactly what the flow requires.
How Do the SMF and UPF Actually Tear Down the User Plane?
Once the AMF sends the PDU Session release request to the SMF, the SMF takes responsibility for removing the associated user-plane resources. Where a UPF session exists, the SMF releases it through the N4 interface.
In a typical case, the SMF sends a PFCP Session Deletion Request. The UPF uses the corresponding F-SEID or N4 Session context to remove the user's forwarding state and returns a PFCP Session Deletion Response. The user-plane tunnels, forwarding rules and related context associated with the PDU Session are then removed. The cleanup is not limited to a single tunnel; it also removes the rule state associated with that N4 Session, including FARs, QERs, URRs and other applicable rules.
The control relationship can be summarized as:
UE → AMF: I want to deregister
→ AMF → SMF: Release this UE's PDU Session Context
→ SMF → UPF: Delete the N4 Session and user-plane resources
→ UPF → SMF: Confirm deletion
→ SMF → AMF: SM Context release completed
If the session uses dynamic PCC, the SMF may also need to terminate the corresponding SM Policy Association, for example through Npcf_SMPolicyControl_Delete. When the released session is the last PDU Session managed by that SMF for the relevant DNN and S-NSSAI, the SMF may also unsubscribe from Session Management Subscription Data changes in the UDM and use Nudm_UECM_Deregistration to remove the association between the SMF and the corresponding DNN/PDU Session from the UDM.
From a UPF trace perspective, the point where deregistration actually reaches the user plane is not the NAS Deregistration Request itself, but the subsequent N4 Session Release. Only when this step is completed are the forwarding resources belonging to the original PDU Session actually removed from the user plane.
Why Do the UDM and PCF Still Need Additional Context Cleanup?
Once PDU Session release is complete, the user plane may already be gone, but control-plane associations can still remain in the 5GC. For Deregistration to fully complete, the network must determine which subscriptions, registrations and policy relationships are still valid and which should be removed.
On the session-management side, if the SMF no longer serves the user's last PDU Session for the relevant DNN and S-NSSAI, it can cancel its subscription to SM Data updates in the UDM and remove the related SMF Registration. This prevents the UDM from continuing to send Session Management updates to an SMF that no longer serves that session.
On the access and mobility policy side, if the UE is no longer registered through any relevant Access Type and an AM Policy Association exists between the AMF and PCF, the AMF needs to terminate that association. Where a UE Policy Association exists, it should also be released when the applicable conditions are met. If the AMF no longer maintains any valid registration for that UE, the AMF registration relationship in the UDM may also need to be removed through Nudm_UECM_Deregistration.
There is an important boundary here: do not assume that every PCF and UDM context must disappear simply because one Deregistration procedure occurs. If the UE remains registered through another Access Type, or if the same SMF still manages other relevant PDU Sessions for that UE, some associations may still be required.
Deregistration cleanup is therefore not just a fixed sequence of DELETE requests. It follows one principle: remove only the state that has lost its business meaning because of this deregistration, while preserving context that is still being used by another access or session. This is one of the easiest areas to misinterpret in multi-access and multi-PDU-Session deployments.
Why Do Normal De-registration and Switch Off End Differently?
Normal de-registration and Switch off may both trigger PDU Session and core-network resource release during the first part of the procedure, but they differ in how the UE side reaches completion.
In a normal de-registration procedure, after sending the Deregistration Request, the UE waits for network confirmation. Once the AMF completes the applicable processing, it returns a Deregistration Accept, explicitly informing the UE that the network has accepted the deregistration. NAS mechanisms such as T3521 may supervise this waiting period. If T3521 expires, the UE follows the protocol-defined retransmission or exception handling rather than simply assuming that deregistration has completed.
If the deregistration applies to 3GPP access and an N2 signaling connection still exists between the AMF and NG-RAN, the AMF can then continue with N2 UE Context Release to terminate the corresponding access-side signaling connection.
Switch off is different. The UE is about to power down, so there is little value in keeping it online simply to wait for a confirmation message. When the Deregistration type indicates Switch off, the AMF does not handle the UE side in the same way as Normal de-registration by requiring a Deregistration Accept before the UE exits. Once the UE has made a best effort to deliver the Deregistration Request, it can continue the shutdown process.
This distinction is particularly important in packet traces:
Normal de-registration
Deregistration Request
→ Core network releases related resources
→ Deregistration Accept
→ Signaling / AN Release
Switch off
Deregistration Request
→ Core network releases related resources
→ UE does not wait for Deregistration Accept before completing shutdown
Therefore, the absence of Deregistration Accept in a power-off trace does not automatically mean the procedure failed. The first step is to check whether the Deregistration type is Normal de-registration or Switch off. If the UE has already powered down, lost the radio link or had insufficient time to receive a response, the network may later rely on mechanisms such as the Mobile Reachable Timer and Implicit Deregistration to deal with abnormal UE disappearance.
FAQ
Is the UE Guaranteed to Deliver Deregistration Request to the AMF When It Powers Off?
No. The Switch off procedure is designed so that the UE makes a best effort to send the deregistration request before shutting down, but the network may never receive it if the UE has already lost coverage, the radio link has failed or power disappears suddenly. This is why the 5GC still needs network-side mechanisms such as the Mobile Reachable Timer and Implicit Deregistration to deal with UEs that disappear unexpectedly.
Does UE Deregistration Always Trigger PFCP Session Deletion?
No. If there is no established PDU Session on the target Access Type, there is no corresponding N4 user-plane session to release, so the SMF and UPF steps associated with PDU Session cleanup may be absent. PFCP Session Deletion is required only when a relevant PDU Session and its user-plane resources actually exist.
Are Deregistration and PDU Session Release the Same Procedure?
No. PDU Session Release removes a specific data session while the UE can remain in the 5GS Registered state. Deregistration removes the UE's registration relationship with the 5GS. When the UE deregisters, existing PDU Sessions normally need to be released as associated resources, but the two procedures operate at different layers and have different purposes.
Why Can Some UDM or PCF Context Still Remain After UE Deregistration?
First check which Access Type the Deregistration applies to and whether the UE remains registered through another access. If the UE still has another valid access, other PDU Sessions or policy relationships that remain in use, some context may need to be retained. Deregistration should not be interpreted as an unconditional deletion of every piece of UE state across the entire 5GC.
