UE 可能长时间未接入网络，直至满足 AMF 的隐式注销定时器条件。此时，问题已不再是 UE 如何完成注册，而且网络可能已无法向 UE 送达 NAS 注销消息。网络需要决定如何处理 AMF 仍为该 UE 保存的签约数据、移动性管理上下文，以及 UDM 中的订阅和注册状态。
AMF Purge（AMF 清除）负责这一清理阶段。3GPP 将该流程定义为 Purge of Subscriber Data in AMF（清除 AMF 中的用户签约数据）。在 UE 完成隐式或显式注销后，AMF 可以删除本地存储的用户签约数据和 MM Context（移动性管理上下文），并终止与 UDM 维持的相关关联关系。
因此，分析 Purge 流程时，不应重新从 Registration Request、Authentication 或 Registration Accept 开始。重点应放在注册关系已经结束后，AMF 与 UDM 如何清理失效的注册相关状态。
Purge、注册与网络发起注销之间的区别
Purge 有时会与注销混淆，因为它可能发生在隐式注销条件满足之后，但两者并非同一流程。
| 流程 | 主要目的 | 需要检查的典型信令 |
|---|---|---|
| 初始注册 | 建立 UE 与 5GS 之间的注册关系 | Registration Request / Accept |
| 网络发起的注销 | 终止现有的 5GS 注册关系 | Deregistration Request 及相关清理信令 |
| AMF Purge 清除 | 从 AMF 删除过期的用户签约数据与 MM Context，并清理 UDM 中的相关状态 | SDM Unsubscribe 与 UECM Deregistration |
在隐式注销场景下，UE 可能已经长时间无法联系，因此 Purge 流程本身不需要 UE 参与。即使信令跟踪中没有 UE 侧的注册或注销 NAS 消息，也不代表未执行 Purge。
更准确地说，注销用于确定 UE 不再维持当前的 5GS 注册关系，而 Purge 则清除与该关系相关、残留在 AMF 和 UDM 中的状态。
要了解网络为何终止 UE 的注册，请参阅5GC 核心网网络发起的注销流程。Purge 流程接续注销之后的 AMF 侧清理工作。
AMF Purge 的触发条件与清理范围
典型触发条件是 AMF 侧用于隐式注销的定时器达到规定条件。网络不能再将 UE 视为正常注册状态，因此需要清理剩余的上下文。
AMF 主要需要处理两类状态。
第一类是Subscriber Data（用户签约数据）。UE 注册期间，AMF 可能从 UDM 获取并保存与接入和移动性管理相关的签约数据。AMF 也可能建立 SDM Subscription，以便相关用户签约数据变化时由 UDM 通知 AMF。
第二类是MM Context（移动性管理上下文），其中包含 AMF 用于管理 UE 注册和移动性状态的信息。当 UE 不再维持当前注册关系时，这些本地上下文不应无限期占用资源。
因此，Purge 是删除旧状态，而不是创建新状态。典型清理操作包括：
取消 AMF 在 UDM 中建立的用户签约数据订阅；
在 UDM 中注销 AMF 的 UECM 注册记录；
删除 AMF 本地存储的 UE 用户签约数据和 MM Context；
使 AMF 保存的 UE 注册状态与实际已注销状态保持一致。
SDM 取消订阅与 UECM 注销信令
从 SBI 信令跟踪的角度看，AMF Purge 的主要交互序列相对简短，集中发生在 AMF 与 UDM 之间。
取消 SDM 订阅
AMF 首先需要删除此前创建的用户签约数据订阅。在 HTTP/2 跟踪中，可以观察到类似以下操作：
DELETE /nudm-sdm/v2/{SUPI}/sdm-subscriptions/{subscriptionId}
UDM 使用 Subscription ID 定位并删除对应的订阅关系。删除完成后，UE 的用户签约数据即使再次发生变化，也不会再通过已删除的订阅向该 AMF 发送通知。
正常情况下，UDM 可返回 204 No Content，表示订阅已成功删除。
在 UECM 中注销 AMF
随后，AMF 需要更新 UDM UECM 中的注册状态。在实际网络信令跟踪中，这可能表现为对 AMF 3GPP Access Registration 资源的更新，请求中同时携带 GUAMI 与 PurgeFlag=true。
UDM 根据收到的信息核对对应的 AMF 注册记录。如果 GUAMI 与存储的服务 AMF 信息匹配，注册数据便会体现 Purge 状态，表明服务 AMF 已完成该 UE 所需的注销和清理。
成功处理后，UDM 也可以返回 204 No Content。至此，AMF 与 UDM 之间的两项主要关联关系已完成清理：
SDM Subscription 已被删除；
UECM 中的 AMF Registration 已完成注销/Purge 处理。
最后，AMF 删除本地保存的 UE 上下文，并将相应的注册管理状态转为 RM-DEREGISTERED。
AMF Purge 信令跟踪中的检查要点
排查 AMF Purge 问题时，不应从 Registration Request 开始，通常也无需先检查 gNB 或 UPF。核心问题是 AMF 与 UDM 之间的状态是否一致。
实用检查点包括：
SDM Subscription：确认 AMF 针对正确的 SUPI 和 Subscription ID 发送 Unsubscribe 请求；
UDM Response：确认 SDM 删除操作成功完成，且 UDM 已移除原订阅关系；
UECM Registration：确认 AMF 对正确的接入类型和 UE 注册记录执行 Deregistration；
GUAMI：确认请求携带的 GUAMI 与 UDM 中保存的服务 AMF 信息一致；
PurgeFlag：确认请求正确标识了 Purge 清除操作；
AMF Local Context：确认 UDM 侧操作完成后，AMF 确实删除了相关用户签约数据和 MM Context。
如果 SDM Subscription 已被删除，但 AMF 仍保留旧的 MM Context，问题更可能出在 AMF 本地清理环节。如果 SDM Unsubscribe 本身失败，则应进一步检查 Subscription ID、SUPI 及 UDM 中保存的对应订阅关系。
因此，不应仅凭某条 NAS 消息是否出现来判断 Purge 是否完成。更可靠的标准是：AMF 本地上下文、UDM 数据订阅和 UECM 注册状态是否均与 UE 已不再注册的事实一致。
常见问题
AMF Purge 与隐式注销是同一个流程吗？
并不完全相同。隐式注销可能触发后续的 Purge 处理；Purge 更具体地指 AMF 在注销后清理用户签约数据和 MM Context，并删除 UDM 中相关的 SDM 订阅与 UECM 注册记录。
AMF Purge 需要 UE 发送 NAS 消息吗？
不一定。在隐式注销场景下，UE 可能已经无法联系。Purge 的主要信令发生在 AMF 和 UDM 之间，因此跟踪中可能没有 UE 侧的 Registration Request 或 Deregistration Request。
Nudm_SDM_Unsubscribe 有什么作用？
它用于删除 AMF 此前为该 UE 建立的用户签约数据订阅。订阅取消后，UDM 不再通过该订阅向相应 AMF 发送后续的用户签约数据变更通知。
PurgeFlag 的用途是什么？
Purge 期间的 UECM Deregistration 可携带与 Purge 相关的指示，使 UDM 知道 AMF 正在清理对应的注册关系。分析信令时，应将 PurgeFlag 与 GUAMI 以及对应的 UECM Registration 结合判断。
为何在 Purge 流程中不重新执行注册？
Purge 用于清理已经结束的旧注册关系，不负责建立新关系。如果 UE 之后再次接入 5GS，则会根据当时的 UE 与网络状态进入相应的 Registration 流程；那是另一组独立的信令交互。
