5GC Core Network AMF-Initiated Purge Procedure

A UE may remain absent from the network long enough for the AMF's implicit deregistration timer conditions to be met. At that point, the issue is no longer how the UE completes Registration, and there may not even be a NAS deregistration message that can still be delivered to the UE. The network instead has to decide what to do with the subscription data, mobility management context, and UDM subscription and registration state that the AMF still holds for that UE.

AMF Purge handles this cleanup stage. 3GPP defines the procedure as Purge of Subscriber Data in AMF. After implicit or explicit deregistration of the UE, the AMF may remove locally stored Subscriber Data and MM Context and terminate the related relationships it maintains with the UDM.

Purge analysis therefore should not restart from Registration Request, Authentication or Registration Accept. The focus is on how stale registration-related state is cleaned up between the AMF and UDM after the registration relationship has already ended.

Boundary Between Purge, Registration and Network-Initiated Deregistration

Purge is sometimes confused with Deregistration because it can follow an implicit deregistration condition, but the two procedures are not the same.

In an implicit deregistration scenario, the UE may have been unreachable for an extended period, so the Purge procedure itself does not require UE participation. The absence of UE-side Registration or Deregistration NAS messages in a trace does not mean that Purge has not occurred.

More precisely, Deregistration determines that the UE no longer maintains the current 5GS registration relationship, while Purge removes the remaining AMF and UDM state associated with that relationship.

To review why the network terminates the UE's registration, see    5GC Core Network Network-Initiated Deregistration Procedure.    The Purge procedure continues from the AMF-side cleanup that follows deregistration.

AMF Purge Triggers and Cleanup Scope

A typical trigger occurs when the AMF-side timer conditions used for implicit deregistration are met. The network can no longer continue treating the UE as normally registered, so it proceeds with cleanup of the remaining context.

The AMF mainly needs to deal with two categories of state.

The first is Subscriber Data. During UE registration, the AMF may retrieve and store subscription data related to access and mobility management from the UDM. It may also establish an SDM Subscription so that the UDM can notify the AMF when relevant subscriber data changes.

The second is the MM Context. This context contains information the AMF uses to manage the UE's registration and mobility state. Once the UE no longer maintains the current registration relationship, this local context should not remain allocated indefinitely.

Purge therefore removes old state rather than creating new state. Typical cleanup includes:

• Canceling the AMF's Subscriber Data subscription in the UDM;

• Deregistering the AMF's UECM registration in the UDM;

• Removing the UE Subscriber Data and MM Context stored locally in the AMF;

• Aligning the UE registration state stored by the AMF with the actual deregistered state.

SDM Unsubscribe and UECM Deregistration Signaling

From an SBI trace perspective, the main AMF Purge signaling sequence is relatively short and is concentrated between the AMF and UDM.

Canceling the SDM Subscription

The AMF first needs to remove the Subscriber Data subscription that was created earlier. In an HTTP/2 trace, an operation similar to the following can be observed:

DELETE /nudm-sdm/v2/{SUPI}/sdm-subscriptions/{subscriptionId}

The UDM uses the Subscription ID to locate and delete the corresponding subscription relationship. After the subscription is removed, subsequent changes to the UE's Subscriber Data are no longer reported to that AMF through the deleted subscription.

Under normal conditions, the UDM can return 204 No Content to indicate that the subscription has been successfully removed.

Deregistering the AMF in UECM

The AMF then needs to update its registration state in UDM UECM. In a live network trace, this can appear as an update to the AMF 3GPP Access Registration resource, with the request carrying the GUAMI together with PurgeFlag=true.

The UDM checks the corresponding AMF registration record using the received information. If the GUAMI matches the stored serving AMF information, the Purge state is reflected in the registration data, indicating that the serving AMF has performed the required deregistration and cleanup for the UE.

After successful processing, the UDM can again return 204 No Content. At this point, the two main relationships between the AMF and UDM have been cleaned up:

1. The SDM Subscription has been removed;

2. The AMF Registration in UECM has completed the Deregistration/Purge handling.

Finally, the AMF removes the UE context stored locally and moves the corresponding registration management state to RM-DEREGISTERED.

What to Check in an AMF Purge Trace

AMF Purge troubleshooting should not begin from Registration Request, and there is usually no need to start with the gNB or UPF. The main issue is state consistency between the AMF and UDM.

Useful checkpoints include:

• SDM Subscription: verify that the AMF sends Unsubscribe for the correct SUPI and Subscription ID;

• UDM Response: confirm that the SDM deletion completes successfully and that the UDM removes the original subscription relationship;

• UECM Registration: verify that the AMF performs Deregistration against the correct Access Type and UE registration record;

• GUAMI: confirm that the GUAMI carried in the request matches the serving AMF information stored by the UDM;

• PurgeFlag: confirm that the request correctly identifies the operation as Purge handling;

• AMF Local Context: after the UDM-side operations complete, verify that the AMF actually removes the relevant Subscriber Data and MM Context.

If the SDM Subscription has already been removed but the AMF continues to retain the old MM Context, the problem is more likely to be in local AMF cleanup. If SDM Unsubscribe itself fails, the next checks should include the Subscription ID, SUPI and the corresponding subscription relationship stored in the UDM.

Purge completion should therefore not be judged by the appearance of a particular NAS message. A more reliable criterion is whether the AMF local context, UDM data subscription and UECM registration state are all consistent with the fact that the UE is no longer registered.

FAQ

Is AMF Purge the Same as Implicit Deregistration?

Not exactly. Implicit deregistration can lead to subsequent Purge handling, but Purge more specifically refers to the AMF cleaning up Subscriber Data and MM Context after deregistration and removing the related SDM subscription and UECM registration in the UDM.

Does AMF Purge Require the UE to Send a NAS Message?

Not necessarily. In an implicit deregistration scenario, the UE may already be unreachable. The main Purge signaling occurs between the AMF and UDM, so a trace can contain no UE-side Registration Request or Deregistration Request.

What Does Nudm_SDM_Unsubscribe Do?

It removes the Subscriber Data subscription that the AMF previously established for the UE. After the subscription is canceled, the UDM no longer sends subsequent subscriber-data change notifications to that AMF through the deleted subscription.

What Is the Purpose of PurgeFlag?

UECM Deregistration during Purge can carry a Purge-related indication so that the UDM knows the AMF is performing cleanup of the corresponding registration relationship. In trace analysis, PurgeFlag should be interpreted together with the GUAMI and the related UECM Registration.

Why Is Registration Not Performed Again During the Purge Procedure?

Purge handles cleanup after an old registration relationship has ended; it does not establish a new one. If the UE later accesses the 5GS again, it enters the appropriate Registration procedure based on its current UE and network state. That is a separate signaling sequence.