假設一個已經建立且一直正常承載業務流量的PDU會話。UE已分配IP位址，gNB維護對應的PDU會話資源和QoS流，UPF中也存在用於用戶面轉發的活動中的PFCP會話。如果用戶決定斷開資料連線、策略功能要求終止會話，或網路判定該會話不應繼續保持，5GC此時所執行的就不再是修改少量QoS參數，而是需要同時拆除控制面與用戶面中的相關會話狀態。
這正是 PDU會話釋放的作用。該過程規定如何移除已建立的PDU會話：清除UE側5GSM上下文，釋放RAN資源，刪除UPF中的N4會話及轉發狀態，並在適用情況下終止關聯的策略關係。最終目的是使AMF、SMF、gNB、UPF和UE達到一致狀態，即該PDU會話已不復存在。
該流程與註冊流程並非同一層面的操作。UE可以釋放一個PDU會話而繼續保持5GS註冊狀態，其他處於活動狀態的PDU會話也可以繼續運行。分析這類訊號傳遞時，重點應放在跟蹤 特定PDU會話ID所關聯的資源如何從UE、RAN、SMF、UPF及策略控制層中被移除，而不是從Registration Request重新開始分析整段訊號傳遞。
會話釋放與建立、修改及去註冊的邊界
PDU會話建立、修改、釋放以及5GS去註冊可能出現在同一組訊號傳遞追蹤中，但它們解決的是完全不同的問題。
| 流程 | 主要目的 | 最終狀態 |
|---|---|---|
| PDU會話建立 | 創建新的資料會話及用戶面資源 | 新的PDU會話進入活動狀態 |
| PDU會話修改 | 修改QoS、策略或現有會話資源 | PDU會話繼續保持活動狀態 |
| PDU會話釋放 | 終止指定PDU會話並釋放其資源 | 該PDU會話不再存在 |
| 5GS去註冊 | 終止UE與5GS之間的註冊關係 | UE退出相應的5GS已註冊狀態 |
會話釋放與去註冊尤其容易混淆。假設UE同時維護一個用於互聯網接入的PDU會話和另一個用於企業專網的PDU會話。釋放其中一個不會自動刪除另一個，也不一定會清除AMF中的UE註冊上下文。
同樣不能把RRC Release視為PDU會話釋放。RRC Release主要改變UE與gNB之間的無線連接狀態，此時核心網路中的PDU會話仍可能保持活動。相比之下，PDU會話釋放會移除與指定 PDU會話ID關聯的會話資源。
有關會話最初如何建立，可參閱5GC核心網路PDU會話建立流程。如果會話仍保持活動狀態，只是QoS或策略參數發生變化，可參閱5GC核心網路PDU會話修改流程。
PDU會話釋放的主要觸發條件
PDU會話釋放可以從網路中的不同位置發起。活動會話可能因UE操作、策略控制決策、網路狀態不一致或資源相關條件而被終止。
常見的觸發情形包括：
-
UE觸發： 當不再需要當前資料會話時，UE發送PDU Session Release Request；
-
PCF觸發： 由於業務授權、使用條件或其他策略要求不再允許會話保持活動，策略控制要求終止會話；
-
AMF觸發： AMF發現UE與網路中的PDU會話狀態不一致，或關聯的網路切片已不可用；
-
RAN觸發： 例如，某PDU會話關聯的所有QoS流均已釋放，RAN向核心網路報告相應狀態；
-
SMF觸發： SMF依據本地策略或從UDM、CHF等網元獲得的資訊，判定該會話應當終止。
由於初始觸發可能來自不同網元，前幾步訊號傳遞並不總是相同。但流程最終都會由SMF協調，因為SMF維護PDU會話控制上下文，並負責協調UPF用戶面、AMF/RAN接入資源以及PCF策略關係。
分析封包追蹤時，首先識別 最初由哪個實體請求釋放 ，通常比直接從PDU Session Release Command開始更有價值。UE發送的Release Request表示流程由UE發起；PCF發出的終止通知表示釋放由策略驅動；AMF請求釋放SM Context則屬於另一種網路觸發分支。
UE發起釋放時的N1、N2與N4訊號傳遞
UE發起的釋放流程能清晰展示不同層面上的會話資源如何被移除。
假設UE當前使用PDU會話ID 5接入資料服務。當設備不再需要該會話時，會生成 PDU Session Release Request ，並通過N1 SM Container發送。gNB使用UL NAS Transport將NAS訊息轉發給AMF，隨後AMF確定負責該PDU會話ID的SMF。
在基於服務的接口上，AMF通過已有的SM Context轉發釋放請求，例如調用Nsmf_PDUSession_UpdateSMContext。這裡並不是新建SM Context；上下文已經存在，AMF是在通知SMF該活動會話已進入釋放流程。
隨後SMF處理用戶面清理。對於已有的N4會話，SMF向UPF發送 PFCP Session Deletion Request 。UPF移除相應PFCP會話關聯的用戶面狀態，並返回PFCP Session Deletion Response。
這與PDU會話修改期間的PFCP Session Modification有本質區別。Modification是在已有N4會話中更新規則，而Deletion則從UPF中刪除整個會話級狀態。
開始清理用戶面後，SMF為RAN和UE準備相關資訊：
-
N2 SM： 指示gNB釋放對應的PDU會話資源；
-
N1 SM： 向UE傳遞PDU Session Release Command。
AMF通過NGAP向gNB發送PDU Session Resource Release Command，該訊息可以攜帶需要轉發給UE的NAS PDU Session Release Command。gNB釋放與該PDU會話相關的接入側資源後，返回PDU Session Resource Release Response。
UE收到Release Command後，刪除本地PDU會話上下文，並發送 PDU Session Release Complete 作為5GSM層面的確認。
典型的UE發起釋放流程可概括為：
UE釋放請求 → AMF → SMF → PFCP會話刪除 → N2資源釋放 → PDU會話釋放命令 → UE釋放完成
如果UE最初處於CM-IDLE狀態，實際網路可能需要先執行Service Request，以恢復繼續釋放流程所需的訊號傳遞連接。因此，不能預期所有封包追蹤都從相同的無線連接狀態開始。
網路發起釋放與PCF策略終止
在網路發起的釋放過程中，UE不會先發送PDU Session Release Request。狀態變化可能從策略控制層或其他核心網路功能開始。
以PCF觸發為例：PDU會話原本正常承載流量，但PCF隨後依據策略決定終止該會話。PCF通過為現有策略關聯建立的通知機制向SMF發送通知。
SMF收到策略驅動的釋放觸發後，仍須拆除用戶面。因此，在SMF經AMF發送所需的N1和N2資訊之前，訊號傳遞追蹤中就可能出現PFCP Session Deletion Request及Response：
SMF → AMF → gNB / UE
AMF的N1N2 Message Transfer可以同時攜帶與PDU會話資源釋放相關的N2資訊，以及發往UE的PDU Session Release Command。
從UE角度看，無論初始釋放由PCF、SMF還是其他網元觸發，只要執行顯式NAS釋放流程，網路仍會發送 PDU Session Release Command，隨後UE返回 PDU Session Release Complete。
但從核心網路訊號傳遞追蹤角度看，僅憑這兩條NAS訊息無法確定最初的觸發源。重要證據出現在Release Command之前：可能是PCF策略終止、AMF請求釋放SM Context、RAN相關事件或SMF本地決策。
這一區別對技術分析和故障排查都很重要： PDU Session Release Command表示網路正在指示UE終止會話，但該訊息本身並不能說明最初由哪個實體觸發釋放。
UPF、RAN及策略上下文中的資源清理
不能僅因UE無法繼續發送數據，就認定PDU會話釋放已經完成。對於具體釋放場景，該PDU會話關聯的資源還必須在相關網元中得到清理。
N4刪除UPF會話
PFCP Session Deletion是用戶面清理的關鍵步驟。當UPF刪除對應的N4會話後，該會話關聯的PDR、FAR、QER、URR及其他適用轉發狀態不再作為已釋放PDU會話的一部分發揮作用。
隨著會話生命週期結束，與該PDU會話相關的N3資源及其他適用的用戶面終止資源也會被釋放。
N2釋放gNB資源
gNB維護與PDU會話及其QoS流關聯的接入側資源。收到PDU Session Resource Release Command後，RAN刪除相關資源，並透過對應的回應訊息向核心網路報告結果。
因此，PFCP Session Deletion成功本身不足以證明整個PDU會話釋放已完成。如果UPF已完成清理，但gNB仍保留PDU會話資源，網路依然處於狀態不一致的情況。
UE刪除自身的5GSM會話上下文
UE收到PDU Session Release Command後清除本地會話上下文，並以PDU Session Release Complete確認。對於IP類型的PDU會話，關聯的IP位址或前綴也進入釋放流程。
SMF通知AMF並清理策略狀態
當會話進入Released狀態時，SMF可以向AMF發送SM Context Status Notification，使AMF同步其保存的會話狀態。
如果該PDU會話具有SM Policy Association，相應PCF策略關係也須按適用分支終止或刪除。如果它是最後一個需要特定DNN、S-NSSAI或訂閱相關狀態的會話，在符合條件時，SMF還可能進一步執行涉及UDM或UDR的訂閱或註冊狀態清理。這些都是有條件的操作，並非每次釋放都會發生。
因此，清理對象是圍繞PDU會話ID建立的一組狀態，而不只是單條隧道：
UE上下文 + RAN資源 + SM上下文 + UPF N4會話 + 策略關聯
通過訊號傳遞追蹤驗證釋放是否完成
從用戶體驗上不一定容易發現PDU會話釋放失敗。UE可能已停止傳輸數據，但一個或多個核心網路網元中仍保留過期狀態。另一些情況下，UE已刪除本地會話，而UPF中的PFCP會話仍處於活動狀態。
比起死記各種可能的訊息順序，更有效的排障方式是圍繞受影響的PDU會話ID建立一組檢查點。
-
確認被釋放的會話： 將分析鎖定在正確的PDU會話ID上，避免把其他併發會話的訊號傳遞混入當前跟蹤；
-
確認觸發源： 判斷最初事件是UE Release Request、PCF終止通知、AMF請求，還是其他網路側事件；
-
驗證SMF處理： 確認請求已到達負責該PDU會話的SMF，且SMF已進入釋放流程；
-
檢查N4資源： 確認PFCP Session Deletion Request和Response已完成，原有UPF會話規則已刪除；
-
檢查N2資源： 確認gNB收到PDU會話資源釋放訊號傳遞，並返回相應的釋放結果；
-
檢查N1狀態： 在適用的顯式NAS釋放流程中，確認UE已收到Release Command並返回PDU Session Release Complete；
-
驗證最終狀態： 確認AMF中的PDU會話狀態、SMF上下文以及任何PCF關聯均與Released結果一致。
例如，如果UE已返回PDU Session Release Complete，但UPF中仍存在對應PFCP會話，應首先排查SMF和N4資源清理。如果PFCP狀態已刪除，但gNB仍保存相關PDU會話資源，則下一步應檢查N2釋放路徑。
反過來，如果沒有PDU Session Release Request、Release Command或相應核心網路資源清理，僅看到RRC Release也不足以認定PDU會話已經終止。
不同規範層級使用的訊息名稱也可能造成混淆。某些流程說明可能將某一步稱為“PDU Session Release Ack”，而UE接收PDU Session Release Command後實際發送的5GSM NAS訊息是 PDU Session Release Complete。分析空中介面及NAS訊號傳遞追蹤時應以實際Message Type為準。
因此，更可靠的完成判據是： 與原PDU會話ID關聯的狀態是否已從UE、RAN、SMF和UPF中移除，而不是某條特定的“最終”訊息是否出現？
常見問題
PDU會話釋放會使UE去註冊嗎？
不一定。PDU會話釋放只終止指定的資料會話。UE可以繼續保持5GS已註冊狀態，也可以繼續使用其他活動PDU會話。去註冊才是終止UE與5GS之間註冊關係的流程。
PDU會話釋放會釋放UE的IP位址嗎？
對於IP類型的PDU會話，與之關聯的IP位址或前綴屬於需要釋放的資源。流程完成後，該地址不應再作為已釋放PDU會話的有效用戶面地址使用。位址集區回收及後續是否重新分配取決於網路實現。
PFCP會話刪除等同於PDU會話釋放嗎？
不是。PFCP Session Deletion是SMF通過N4刪除UPF會話及其用戶面規則的流程。它通常是PDU會話釋放的重要環節，但完整釋放還可能涉及UE、RAN、AMF、PCF及其他相關上下文。
PDU會話釋放與PDU會話修改的主要區別是甚麼？
PDU會話修改是在保持原會話活動的同時調整QoS、策略或相關資源。PDU會話釋放則終止指定會話並移除相關資源。如果同一PDU會話ID仍有效且繼續承載流量，通常不能認為釋放已經完成。
UE已發起釋放請求，網路為甚麼還要發送PDU Session Release Command？
UE Release Request表達的是UE終止會話的請求，但SMF仍須協調UPF、RAN及UE中的狀態。網路進入釋放流程後，PDU Session Release Command指示UE清除對應的5GSM會話上下文，隨後UE以PDU Session Release Complete作出回應。
