現場故障排除時，一個很容易出現的誤區是看到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相關的所有狀態。
