现场排障时，一个很容易出现的误区是看到RRC Release就认为UE去注册已经结束。无线连接确实可能已经断开，UE也可能停止发送数据，但AMF中的注册上下文、SMF中的PDU Session、UPF中的N4会话、PCF中的策略关联以及UDM中的注册记录，并不会仅仅因为“信号没了”就在同一时刻全部消失。抓取信令时真正需要关注的是Deregistration Request之后跨网元展开的清理链：AMF如何确定去注册范围，SMF如何指示UPF移除用户面资源，以及PCF和UDM中的关联应释放到什么程度。
UE发起的去注册 是将已经注册的UE有序退出5GS的受控流程。流程从NAS Deregistration Request开始，可能涉及释放PDU Session、删除UPF中的N4会话和用户面隧道、终止SM Policy与AM Policy关联、移除UDM中的相关注册状态，最后释放UE与接入网之间的信令连接。正常去注册与关机在流程前半段看起来可能相似，但结束方式不同：前者会等待Deregistration Accept，后者不会为了接收确认而继续保持在线。抓包分析时很容易忽略这一差异。
为什么去注册不只是把UE标记为离线？
UE完成Initial Registration并建立PDU Session后，5GC保存的并不是一个简单的“在线”标志。AMF维护注册和移动性上下文，SMF管理PDU Session上下文，UPF保存N4 Session以及FAR、QER、URR等用户面转发资源，UDM保存AMF与SMF注册关系，PCF还可能维护AM、UE或SM Policy Association。
如果UE只是从网络中消失，这些资源并不会在完全相同的时刻自动清除。尤其是在仍存在一个或多个PDU Session时，网络需要明确哪些会话应被释放、哪些用户面规则应被删除，以及哪些订阅或策略关联已经没有继续保留的必要。
因此，UE发起的去注册会执行一次 对注册状态及其关联资源的有序拆除：
UE指示当前5GS注册应结束
→ AMF确定去注册范围
→ 释放相关PDU Session
→ SMF指示UPF移除用户面资源
→ 删除会话与策略关联
→ 移除注册状态
→ 释放接入侧信令连接
这也是为什么不能把去注册与RRC Release或普通N2连接释放混为一谈。RAN连接释放只表示当前接入信令连接已经结束；去注册处于更高层级，会移除5GS注册关系以及与之关联的会话和策略状态。如果抓包里只看到RRC Release，就直接认定UE已经去注册，很容易把“接入连接释放”和“注册关系移除”混淆。
Deregistration Request如何定义UE以何种方式、从哪种接入退出？
当UE主动离开5GS时，会向AMF发送NAS Deregistration Request。做信令分析时，首先应检查的不是后续是否出现PFCP消息，而是请求中携带的Deregistration type和Access Type。
Deregistration type首先告诉网络，该流程是否属于 关机 场景。从工程角度看，UE发起的去注册常见于两种情况：正常去注册，即UE按正常流程有序退出；以及关机，即UE指示自己即将关机或进入等效的关闭状态。
Access Type回答的是另一个问题：实际要去注册的是哪一种接入。UE可以只从3GPP接入去注册，也可以只从非3GPP接入去注册；当同一PLMN中的两种接入都由同一个AMF服务时，流程也可以按适用条件覆盖两者。因此，“UE去注册”并不一定意味着与该UE相关的所有接入状态都会一次性删除。
Deregistration Request还会携带UE身份信息。当存在有效的5G-GUTI时，UE可以利用它帮助AMF把该NAS消息关联到现有UE上下文。如果没有有效的5G-GUTI，身份处理则取决于UE当前可用的5GS身份。对AMF而言，只有把这条NAS消息正确映射到已有UE上下文，才能释放正确的PDU Session和策略关联。
在正常去注册中，UE发送请求后会等待网络确认完成；在关机中，目标是尽快送达“我要离开”的指示，然后继续关机流程，因此处理方式不同。正常去注册可以使用T3521监控UE等待Deregistration Accept的时间，而关机不会以同样方式等待网络确认。
为什么AMF首先要检查UE是否仍有PDU Session？
AMF收到Deregistration Request后，一个关键判断就是目标接入上是否仍存在已建立的PDU Session。
如果UE没有相关PDU Session，就不存在需要单独拆除的用户面会话，流程可以明显缩短。但如果仍有一个或多个PDU Session处于活动状态，AMF就不能只删除自己的注册上下文，因为SMF和UPF仍会把这些会话视为存在。
对于每个需要释放的PDU Session，AMF可以向对应SMF调用 Nsmf_PDUSession_ReleaseSMContext。可以把它理解为AMF向会话管理层发出的明确指令：UE正在离开目标接入，因此相关SM Context不应继续维护。只有收到这一指令后，SMF才能继续删除N4会话、终止策略关联并清理UDM中的相关注册状态。
这也体现了去注册与单独PDU会话释放之间的区别。释放一个PDU Session并不意味着UE离开5GS，UE仍可以保持5GS Registered；而当UE发起去注册时，与目标接入相关的PDU Session通常都需要作为整体去注册流程的一部分被清理。
因此，如果抓包中出现Deregistration Request，但之后没有Nsmf_PDUSession_ReleaseSMContext，不应立即判断为信令缺失。首先要确认UE在对应Access Type上是否真的已经建立PDU Session。如果本来就没有PDU Session，那么没有N4释放流程可能正是正确的流程表现。
SMF和UPF如何真正拆除用户面？
AMF向SMF发送PDU Session释放请求后，SMF负责移除对应的用户面资源。如果存在UPF会话，SMF会通过N4接口释放它。
典型情况下，SMF会发送 PFCP Session Deletion Request。UPF根据对应的F-SEID或N4 Session上下文删除用户的转发状态，并返回PFCP Session Deletion Response。随后，与该PDU Session相关的用户面隧道、转发规则及关联上下文都会被移除。清理范围并不只是一条隧道，还包括该N4 Session关联的规则状态，例如FAR、QER、URR以及其他适用规则。
其控制关系可以概括为：
UE → AMF：我要去注册
→ AMF → SMF：释放该UE的PDU Session上下文
→ SMF → UPF：删除N4 Session和用户面资源
→ UPF → SMF：确认删除
→ SMF → AMF：SM Context释放完成
如果会话使用动态PCC，SMF还可能需要终止对应的SM Policy Association，例如通过Npcf_SMPolicyControl_Delete。若被释放的会话是该SMF针对相应DNN和S-NSSAI管理的最后一个PDU Session，SMF还可以取消订阅UDM中的Session Management Subscription Data变更，并通过Nudm_UECM_Deregistration从UDM中移除SMF与对应DNN/PDU Session之间的关联。
从UPF抓包角度看，去注册真正到达用户面的节点并不是NAS Deregistration Request本身，而是后续的N4 Session Release。只有这一步完成后，原PDU Session对应的转发资源才真正从用户面被移除。
为什么UDM和PCF还需要进一步清理上下文？
PDU Session释放完成后，用户面可能已经不存在，但5GC中仍可能保留控制面关联。要让去注册真正完成，网络还需要判断哪些订阅、注册和策略关系仍然有效，哪些应当移除。
在会话管理侧，如果SMF已经不再为相关DNN和S-NSSAI服务该用户的最后一个PDU Session，它可以取消订阅UDM中的SM Data更新，并移除相应的SMF Registration。这样可以避免UDM继续向已经不再服务该会话的SMF发送Session Management更新。
在接入和移动性策略侧，如果UE已经不再通过任何相关Access Type保持注册，而AMF与PCF之间存在AM Policy Association，AMF就需要终止这一关联。若存在UE Policy Association，在满足相应条件时也应释放。如果AMF已经不再为该UE维护任何有效注册，那么UDM中的AMF注册关系也可能需要通过Nudm_UECM_Deregistration移除。
这里有一个重要边界： 不要因为发生一次去注册，就假定所有PCF和UDM上下文都必须消失。 如果UE仍通过另一种Access Type保持注册，或者同一个SMF仍在为该UE管理其他相关PDU Session，那么某些关联仍然可能需要保留。
因此，去注册清理并不是一套固定的DELETE请求序列。它遵循一个原则： 只移除那些因为本次去注册而失去业务意义的状态，同时保留仍被其他接入或会话使用的上下文。 在多接入和多PDU Session部署中，这是最容易被误判的地方之一。
为什么正常去注册和关机的结束方式不同？
正常去注册和关机在流程前半段都可能触发PDU Session和核心网资源释放，但UE侧的结束方式不同。
在正常去注册流程中，UE发送Deregistration Request后会等待网络确认。AMF完成适用处理后，会返回 Deregistration Accept，明确告知UE网络已经接受去注册。T3521等NAS机制可以用于监控这一等待时间。如果T3521超时，UE会按照协议规定执行重传或异常处理，而不是直接假定去注册已经完成。
如果去注册针对3GPP接入，并且AMF与NG-RAN之间仍存在N2信令连接，AMF随后还可以继续执行N2 UE Context Release，以终止对应的接入侧信令连接。
关机则不同。UE即将关机，因此为了等待确认消息而继续保持在线并没有太大意义。当Deregistration type指示关机时，AMF不会像正常去注册那样要求UE在退出前必须收到Deregistration Accept。UE尽力发送Deregistration Request后，即可继续执行关机流程。
这一差异在抓包中尤其重要：
正常去注册
Deregistration Request
→ 核心网释放相关资源
→ Deregistration Accept
→ 信令 / AN释放
关机
Deregistration Request
→ 核心网释放相关资源
→ UE在完成关机前不会等待Deregistration Accept
因此，在关机抓包中看不到Deregistration Accept，并不自动意味着流程失败。第一步应检查Deregistration type究竟是正常去注册还是关机。如果UE已经关机、无线链路丢失，或没有足够时间接收响应，网络后续可以依靠Mobile Reachable Timer和Implicit Deregistration等机制处理UE异常消失的情况。
常见问题
UE关机时一定能把Deregistration Request送到AMF吗？
不能保证。关机流程设计为UE在关机前尽最大努力发送去注册请求，但如果UE已经失去覆盖、无线链路故障或电源突然消失，网络可能根本收不到该请求。这也是为什么5GC仍需要Mobile Reachable Timer和Implicit Deregistration等网络侧机制来处理突然消失的UE。
UE去注册一定会触发PFCP Session Deletion吗？
不一定。如果目标Access Type上没有已建立的PDU Session，就没有对应的N4用户面会话需要释放，因此与PDU Session清理有关的SMF和UPF步骤可能不会出现。只有实际存在相关PDU Session及其用户面资源时，才需要PFCP Session Deletion。
去注册和PDU会话释放是同一个流程吗？
不是。PDU会话释放用于移除某一个具体的数据会话，UE仍可以保持5GS Registered；去注册则用于移除UE与5GS之间的注册关系。UE去注册时，现有PDU Session通常需要作为关联资源一并释放，但两者处于不同层级，目的也不同。
为什么UE去注册后仍可能保留部分UDM或PCF上下文？
首先应确认去注册针对的是哪一种Access Type，以及UE是否仍通过另一种接入保持注册。如果UE仍有另一条有效接入、其他仍在使用的PDU Session或策略关系，就可能需要继续保留部分上下文。不能把去注册理解为无条件删除整个5GC中与UE相关的所有状态。
