AMF purge is the optional removal of locally stored subscriber data and mobility management (MM) context after a UE has been implicitly or explicitly deregistered. The associated UDM signaling cancels subscription-data notifications and marks the relevant access registration as purged. It does not delete the subscriber's provisioned account.
A typical investigation begins with an unreachable UE and an old AMF context. The engineering question is whether that context can be discarded, which UDM relationships must change, and whether newer or still-valid registration state will remain protected. The main exchanges are Nudm_SDM_Unsubscribe and Nudm_UECM_Deregistration.
When AMF Purge Follows Deregistration
3GPP names the procedure Purge of subscriber data in AMF. In TS 23.502, Release 18, clause 4.5.3, purging the local subscriber data and MM context is an implementation option after deregistration. If the AMF takes that option, it must perform the associated unsubscribe and deregistration operations toward the UDM.
This distinction matters when a timer expires. The timer conditions belong to reachability and implicit deregistration handling; they do not establish a universal purge timer or require immediate deletion of every UE record. First establish why the relevant registration ended, then determine whether the AMF chose to purge the retained context.
| Procedure | Purpose | Evidence to examine |
|---|---|---|
| Initial Registration | Establish access and mobility registration | Registration Request, subscription retrieval and Registration Accept |
| Deregistration | End registration for the applicable access | Trigger, access scope, NAS exchange when applicable and registration state |
| AMF purge | Discard retained local data and synchronize the UDM | Local cleanup, SDM Unsubscribe and UECM purge indication |
The network-initiated deregistration procedure covers the preceding decision and any UE-facing notification. Purge itself needs no new Registration Request or NAS Deregistration Accept from the UE. In an implicit case, the UE may already be unavailable.
What Is Removed and What Can Remain
Keep three kinds of state separate. The AMF's subscriber-data copy contains information obtained for access and mobility handling. Its MM context supports the UE's mobility and registration management. An SDM subscription is a separate notification relationship through which the UDM reports changes to subscribed data.
The UDM also maintains AMF registration information through UE Context Management (UECM). During purge, this information is updated with a purged indication for the relevant access. Describing the operation simply as “delete the UDM registration” obscures the difference between removing an SDM subscription resource and modifying an AMF registration resource.
Nor is purge equivalent to withdrawing service entitlement. The provisioned subscription remains a separate concern. A UE returning later follows the appropriate registration procedure, with access decided against the subscription and network conditions then in force. The Initial Registration signaling flow covers identity, authentication and rebuilding the necessary serving context.
Access scope is essential when 3GPP and non-3GPP access coexist. Ending registration over one access is not evidence that the UE has no valid relationship over the other. Before treating remaining context as a leak, identify which access ended and what remaining state still needs it. Similarly, use the PDU Session Release procedure to investigate SMF and UPF session resources; their deletion is not proved by an AMF purge acknowledgment.
SDM Unsubscribe Removes the Notification Subscription
The reference flow begins its UDM exchanges after the local subscriber data and MM context have been purged. It shows an SDM Unsubscribe request and response, followed by a UECM Deregistration request and response. Local deletion should therefore not be presented as a mandatory final action that occurs only after both UDM responses.
For an individual SDM subscription, the AMF sends HTTP DELETE to the subscription resource previously identified by the Location header when it was created. An illustrative path is:
SDM subscription resource
DELETE {apiRoot}/nudm-sdm/v2/{supi}/sdm-subscriptions/{subscriptionId}Use the actual stored subscription URI and deployed API version when correlating packets. The example is a resource pattern, not a substitute for the URI returned by the UDM. Match the SUPI, subscription ID and originating AMF so a subscription from a different context is not mistaken for the obsolete one.
Successful removal returns 204 No Content. TS 29.503 clause 5.2.2.4.2 also describes 404 Not Found when no valid subscription is available, such as an unknown subscription ID. A 404 warrants checking earlier deletion attempts and the original creation response. It does not, by itself, establish that the entire purge succeeded.
After removal, that subscription no longer provides future data-change notifications to the AMF. Other subscriptions for the same subscriber must be assessed separately. Any corresponding UDM-to-UDR handling belongs to the UDM side of the procedure and should not be assumed visible in an AMF-only capture.
UECM Deregistration Sets the Access-Specific Purge Flag
For AMF deregistration, the service-operation name does not imply HTTP DELETE. TS 29.503, Release 18, clauses 5.3.2.4.2 and 5.3.2.4.3 map it to PATCH on the applicable AMF registration resource:
Access-specific UECM resources
PATCH {apiRoot}/nudm-uecm/v1/{ueId}/registrations/amf-3gpp-access
PATCH {apiRoot}/nudm-uecm/v1/{ueId}/registrations/amf-non-3gpp-accessHere, {ueId} is the SUPI for this operation. The modification data includes guami and purgeFlag: true. These are the JSON attribute spellings; “PurgeFlag” is also used as a specification type name. Do not invent an additional purge endpoint or treat the two access resources as interchangeable.
The UDM validates the received GUAMI against the stored registration before setting the flag. A successful request receives 204 No Content; a GUAMI mismatch results in 403 Forbidden. The modification tables in clauses 6.2.6.2.7 and 6.2.6.2.8 specifically require rejection when the MCC, MNC, AMF Region ID or AMF Set ID differs.
This validation is relevant to delayed cleanup from an older serving context. As a troubleshooting inference, a mismatch may indicate that serving registration has changed, rather than that cleanup should be forced through. Compare registration history and request ownership before attributing every 403 to an authorization configuration problem.
How to Diagnose an Incomplete AMF Purge
Correlate local AMF logs with SBI transactions. An HTTP success response confirms the individual UDM operation, while local context removal needs separate evidence. Registration management has already entered the relevant deregistered condition before this purge procedure; the last UECM response should not be treated as the event that first makes the UE RM-DEREGISTERED.
| Observation | Next check |
|---|---|
| SDM DELETE returns 404 | Recover the original subscription URI and check earlier removal or retry history. |
| UECM PATCH returns 403 | Compare the request GUAMI with current stored registration and recent AMF changes. |
| SDM removal succeeds but UECM update fails | Track both outcomes separately; notification cleanup does not prove the purged indication was recorded. |
| UDM operations succeed but local context remains | Check whether purge was selected, local deletion logs, and any still-valid access state. |
| Only one access is purged | Verify the other access's actual registration before treating its retained state as an error. |
For each attempt, record the SUPI, serving AMF, access resource, subscription URI, response status and timestamp. Distinguish a retried old request from a new registration for the same subscriber. A timeout is an unknown transaction outcome until correlated with server-side processing; it is not proof that the UDM made no change.
FAQs
Why can log timestamps appear to contradict the procedure order?
First check clock synchronization, log buffering and whether an entry records request creation, transmission, processing or completion. Compare transaction identifiers and both sides of the exchange before concluding that the implementation reordered the procedure. A log's display order is not necessarily its processing order.
How should a purge trace be prepared for external support?
Remove credentials, tokens and unnecessary subscriber data. Replace subscriber identifiers consistently so transactions can still be correlated, and preserve the relevant access type, response cause, timestamps and version information. Share the trace through the operator's approved support process.
Which specification version should a deployment investigation use?
Start with the network's declared release, supported API versions and implementation documentation. The references here identify the Release 18 revisions used for this explanation. Compare any relevant changes before applying their details to a different release or software build.
