An RRC Release does not prove that a UE has deregistered. A registered UE can release its access signaling connection while the AMF retains registration context and the SMF retains PDU Sessions. UE-initiated deregistration instead begins with a NAS Deregistration Request and ends the registration for the indicated access.
For trace analysis, follow the request scope, applicable session and policy cleanup, and the expected NAS response. The AMF, SMF, UPF, PCF and UDM hold different parts of this state; they do not all delete every UE record at the same instant.
Read the deregistration scope first
The UE sends Deregistration Request toward the AMF using its 5G-GUTI. Check Deregistration type, including the Switch off indication, and Access Type. The target can be 3GPP access, non-3GPP access, or both when the two accesses are served by the same AMF. The access carrying the request need not be the access being removed.
At NAS encoding level, access type is part of the de-registration type information element, not a separate field with the illustrative IEI shown below. Identity and integrity protection must be checked against the actual NAS context; an unprotected or unverifiable request can require security handling before cleanup.
Release the PDU Sessions that belong to the target access
If no PDU Session exists over the target access, the session-release steps are skipped. Otherwise, the AMF sends Nsmf_PDUSession_ReleaseSMContext to the relevant SMF for each affected session. A standalone PDU Session Release removes a data session while registration can remain valid; deregistration has a wider scope. For a multi-access (MA) PDU Session with user-plane resources on both accesses, deregistration from one access releases only that access's user-plane resources; the session can remain on the other access.
The SMF releases allocated session resources, such as the IP address or prefix, and requests N4 session release from the applicable UPFs. On N4, PFCP Session Deletion Request and PFCP Session Deletion Response identify the deletion exchange. Successful deletion removes that PFCP session and its associated rules, including applicable PDRs, FARs, QERs and URRs, and releases associated tunnel resources.
The SMF returns the SM-context release response. In home-routed roaming, V-SMF and H-SMF coordination also applies. The reference flow has conditional ordering: when secondary RAT usage reporting is required, the AMF performs the NAS acceptance and access release first, obtains the usage data, and then continues session and policy cleanup.
Remove obsolete policy and UDM associations conditionally
If dynamic PCC applies, the SMF terminates the SM Policy Association, using Npcf_SMPolicyControl_Delete as applicable. For the last PDU Session that the SMF handles for the UE and the associated DNN and S-NSSAI, it uses Nudm_SDM_Unsubscribe and Nudm_UECM_Deregistration to remove the relevant subscription and SMF registration association in the UDM.
The AMF terminates existing AM Policy and UE Policy Associations when the UE is no longer registered over any access. Do not infer that the subscriber profile, historical charging data or every UDM record must be erased. Another registered access or session can still require context; verify the exact association and scope.
Normal de-registration and Switch off end differently
For Normal de-registration, the UE expects Deregistration Accept and uses T3521 to supervise the response, following the specified retry and failure rules if it expires. The AMF also releases the relevant N2 signaling connection when it exists, for NG-RAN or the applicable non-3GPP access gateway.
For Switch off, the AMF does not send Deregistration Accept. The UE does not wait for that confirmation before shutdown. An absent response in this case is expected behavior, not evidence by itself of failed deregistration.
A request may never reach the AMF after sudden power loss or loss of coverage. That abnormal disappearance is handled by network reachability supervision and, when its conditions are met, implicit deregistration. It is distinct from a successfully received switch-off request.
A practical trace checklist
Confirm UE-to-AMF direction, the 5G-GUTI, integrity result, deregistration type and target access.
Establish whether affected PDU Sessions and N4 contexts existed before looking for release messages.
Correlate AMF-to-SMF, SMF-to-UPF and policy/UDM transactions by UE and session identity; check responses and retained state.
Expect NAS acceptance only for the applicable non-switch-off case, and account for access release and conditional usage-reporting order.
FAQs
Is switch-off request delivery guaranteed?
No. Sudden loss of power or radio coverage can prevent delivery. A missing request does not prove that the AMF has already removed registration state.
Does every deregistration contain PFCP deletion?
No. With no relevant established PDU Session or N4 context, there is nothing corresponding to delete. Investigate the prior session state before classifying missing PFCP messages as a fault.
Can another access remain registered?
Yes. Deregistration can target one access. Check the indicated scope before expecting AM Policy or UE Policy Association termination or removal of all session state.
How does network-initiated deregistration differ?
The NAS request travels from AMF to UE, or is absent for implicit deregistration. The trigger and expected response differ, even though some backend cleanup steps overlap.
Related procedures and standards
For the opposite trigger direction, see network-initiated deregistration. To understand idle reachability before implicit cleanup, see periodic registration update.
The procedure above follows 3GPP TS 23.502 clause 4.2.2.3.2, NAS behavior in 3GPP TS 24.501 clause 5.5.2.2 and timer tables, and PFCP deletion in 3GPP TS 29.244 clause 6.3.4. Match the release and supported features to the deployment being analyzed.
