一个5G UE可以在无线覆盖正常、甚至仍有活动PDU会话的情况下，由AMF突然向其发送网络侧发起的Deregistration Request。此时UE并未关机，也没有主动发送自己的Deregistration Request。
这种行为并不矛盾。5GC中的注册关系并不一定要由UE来终止。运维操作、UE长时间不可达、AMF内部状态处理，或UDM中用户5G订阅被撤销，都可能促使网络终止现有注册。分析信令时，最重要的问题并不只是UPF资源最终是否被删除，而是 谁首先作出去注册决定、UE是否仍能收到通知、网络是否要求重新注册，以及哪些信令消息可能在正常情况下根本不会出现。
谁可以决定让已注册UE退出5GS？
理解网络侧发起的去注册，首先要区分“发起”和“触发”。该流程最终由AMF发起并执行，但促使AMF这样做的原因并不一定来自AMF内部。
第一类情况从AMF开始。运维人员可能为了维护、用户迁移或其他网络管理目的，显式将用户去注册，迫使当前处于RM-REGISTERED状态的UE退出现有注册。另一类是隐式去注册。如果网络在满足相关计时器条件后仍无法确认UE可达，AMF可以在不等待UE主动发起任何操作的情况下开始清理上下文。
第三条路径从UDM开始。例如，当运营商撤销用户的5G业务订阅时，UDM会首先知道订阅状态已发生变化。UDM不会直接向UE发送NAS信令，而是通知当前为该UE提供服务的AMF，再由AMF将这一核心网决定转化为网络侧发起的去注册流程。
从网络功能关系来看，主要来源可以概括为：
AMF显式发起： 运维操作、用户迁移或其他网络管理目的；
AMF隐式去注册： 去注册计时器或可达性条件满足，UE已不能再被视为正常注册；
UDM触发的去注册： 例如用户订阅被撤销，UDM通知AMF对UE执行去注册。
无论最初原因是什么，最终目标相同：原有5GS注册关系不再有效，UE从RM-REGISTERED转换为RM-DEREGISTERED。
为什么显式去注册和隐式去注册在抓包中看起来差别很大？
两种流程最终都会使UE退出注册状态，但其信令表现可能明显不同。
在显式去注册中，网络通常仍能与UE通信。AMF可以发送NAS Deregistration Request，通知UE当前注册即将终止。如果UE仍可达，它可以返回Deregistration Accept，随后网络继续释放剩余上下文和接入侧信令连接。
隐式去注册的起点不同。它通常发生在UE长时间没有重新出现或响应，以至于网络无法继续确认其可达之后。此时再发送Deregistration Request可能已经没有意义，因为UE可能已经关机、离开覆盖范围或以其他方式断开连接。
因此，隐式去注册在抓包中可能只表现为网络侧上下文清理，而不会出现完整的Deregistration Request → Deregistration Accept交互。
由此可以得到一条实用的抓包分析规则： 没有看到网络发往UE的Deregistration Request，并不能证明网络侧发起的去注册没有发生。 在隐式场景中，网络之所以进行清理，恰恰可能是因为UE已经无法参与信令交互。
UDM如何把订阅撤销决定传递给AMF？
用户业务资格发生变化，是网络侧发起去注册最典型的场景之一。假设UE已在访问网络完成注册并建立业务，但归属网络随后撤销了用户的5G订阅。最先感知这一订阅变化的是UDM，而不是gNB或UE。
UDM可以通过AMF先前登记的回调URI向服务AMF发送Deregistration Notification。典型情况下，该通知可以携带 SUBSCRIPTION_WITHDRAWN 等原因，并标明相关Access Type，例如3GPP_ACCESS。
只有在收到该通知后，AMF才进入面向UE的网络去注册流程。随后AMF可以通过gNB向UE发送NAS Deregistration Request。除UE身份和Access Type外，其中一个特别重要的字段是 re-registration required（需要重新注册）。
该字段表示网络是否要求UE在去注册后重新执行Registration。不能把它理解为所有网络侧发起的去注册都会强制UE重新注册并且一定成功。在某些场景中，网络可能只是希望UE离开当前AMF或重建注册上下文。如果用户已经失去5G业务资格，后续Registration是否成功仍是另一项独立判断。
UDM到AMF的通知处理完成后，AMF向UDM返回相应确认。到此，控制链已经从“订阅状态发生变化”转变为“服务AMF正在执行去注册”。
网络决定让UE去注册后，后端资源如何清理？
从这一阶段开始，部分资源释放步骤与UE侧发起的去注册相同，没有必要再机械重复每一条N4、PCF和UDM消息。更重要的是理解为什么在网络侧发起的流程中仍必须执行这些清理。
UE可能已经有一个或多个活动PDU会话。一旦AMF决定终止注册，就需要通知相关SMF释放这些会话。随后SMF负责处理UPF侧的用户面资源和N3路径，并终止已经失去有效业务上下文的SM Policy关系。UDM中的订阅或注册关系也可以根据剩余会话状态进行清理。
AMF自身也可能需要释放接入与移动性策略关系，包括AM Policy Association以及适用的UE Policy Association。否则可能出现UE已经不再注册，但PCF、SMF或UDM中仍保留着表明业务仍在继续的关系，造成网络状态不一致。
真正困难的地方不是“尽量多删”。网络必须理解当前Access Type以及仍然有效的业务状态。如果UE还通过另一种接入保持注册，或某些上下文仍被其他会话使用，就不应该删除全部UE状态。
因此，在看到网络侧发起的Deregistration Request之后，排障不应纠结是否出现了完全相同的14条消息。应确认应该释放的PDU会话是否真正释放、过期的策略关系是否终止，以及仍应有效的上下文是否被保留。
AMF显式踢除与UDM撤销订阅有什么区别？
这两种流程的后半段看起来可能非常相似，因为最终都依赖AMF让UE去注册，并可能进入相同的PDU会话和策略清理逻辑。但它们的起点不同。
如果运维人员在AMF上显式移除UE，第一项关键动作直接来自AMF。在此之前不会有UDM发送的Deregistration Notification。AMF已经掌握去注册的运维原因，因此可以直接向UE发送Deregistration Request。
如果用户的5G业务已经被撤销，起点则是UDM。在AMF采取动作之前，通常会先收到UDM的去注册通知。在多NF抓包中，这一区别非常有用，因为它可以说明 是谁最先决定终止现有注册关系，而不是把后续所有清理信令都当成同一种场景。
在AMF迁移或AMF池内重新分配用户时，还应结合UE后续是否进入新的Registration流程，一起检查Deregistration Request中的re-registration required要求。在这种情况下，去注册可能只是把UE转移到另一个服务AMF的一步，而不是永久终止用户的5G业务。
Subscription Withdrawal在性质上不同，因为它代表用户业务资格发生变化。即使NAS流程允许UE再次尝试Registration，核心网仍会根据更新后的订阅状态重新评估该请求。
抓包分析先看第一条消息是谁发出的
分析网络侧发起的去注册时，可以将流程拆成四个阶段： 来源 → 通知 → 资源清理 → UE响应。
第一，确定来源。如果最早的相关消息是UDM发往AMF的Deregistration Notification，说明流程由UDM侧事件触发。如果AMF直接向UE发送Deregistration Request，则更可能是AMF显式发起的场景。如果两者都没有出现，但网络开始移除UE上下文，则应考虑隐式去注册。
第二，检查NAS方向。在网络侧发起的去注册中，Deregistration Request的方向是 AMF → UE。这与UE侧发起的去注册方向相反。消息名称可能完全相同，因此方向非常重要。
第三，检查UE是否返回Deregistration Accept。在显式去注册中，如果UE仍然可达，通常能看到该响应。隐式去注册时UE可能已经不可达，因此这一步可能不会出现。
第四，核对后端资源。如果UE此前存在PDU会话，应确认对应SMF和UPF资源是否已释放。如果流程源自UDM或涉及策略状态，也要检查UDM与PCF关系。
一套实用的分析顺序是：
确定由哪个NF发起或触发该流程；
确认Deregistration Request方向和Access Type；
检查re-registration required是否与当前场景一致；
确认UE是否返回Deregistration Accept；
核对现有PDU会话和用户面资源是否已经释放；
最后确认UE注册状态已经离开RM-REGISTERED。
这种分析方式比机械地对照某个编号流程、检查是否少了一条HTTP/2消息更接近真实排障。网络侧发起的去注册可能由多种原因引起，因此不同场景从第一条消息开始就可能不同。
常见问题
网络侧发起的去注册一定会向UE发送Deregistration Request吗？
不一定。显式去注册时，如果UE可达，AMF通常会发送Deregistration Request。隐式去注册往往发生在UE长时间不可达之后，因此网络可能直接清理注册上下文，而抓包中不会出现NAS Deregistration Request。
UDM可以直接让UE去注册吗？
UDM主要负责用户及订阅数据。订阅撤销等事件可以触发去注册，但真正面向UE执行网络侧Deregistration Request的仍是服务AMF。抓包分析应区分 UDM触发 和 AMF发起 的去注册。
如果re-registration required设为1，是否意味着UE一定能够再次注册成功？
不。该字段表示网络要求UE重新执行Registration，但新的Registration是否被接受，还取决于用户业务资格、接入限制、网络策略以及最初去注册的原因。如果订阅已经被撤销，UE再次尝试Registration并不保证5GC会接受。
资源释放步骤与UE侧发起的去注册完全不同吗？
不。触发方向不同，但一旦网络决定终止注册，现有PDU会话、UPF资源和策略关系的清理与UE侧发起的去注册可能高度重合。更有用的区别是：谁启动了流程、NAS消息方向、是否期望UE确认，以及是否要求重新注册。
