智慧型手機可能已經顯示 5G 圖示，但網頁仍然無法載入。出現這種情況時，第一反應往往是檢查註冊流程：5G-AKA 是否完成？是否收到了 Registration Accept？T3512 是否超時？逐項檢查之後，可能會發現 Registration 流程完全正常，但資料服務仍然不可用。
很多情況下，問題並不在 Registration，而在 PDU Session。Registration 回答的是“UE 能否註冊到 5GS？”，PDU Session Establishment 回答的是下一個問題：“UE 是否真正能夠存取資料網路？”本文從頭到尾梳理 PDU Session Establishment 流程——UE 如何發起會話請求、AMF 如何選擇 SMF、SMF 如何取得訂閱與策略資訊、UPF 如何設定，以及 N3 隧道最終如何建立完成。
UE 完成 5GS Registration 後，AMF 已經保存了使用者識別、行動性、安全以及相關訂閱內容。然而，註冊成功並不意味著使用者平面路徑已經存在。UE 此時可能仍然沒有到 Internet 或企業資料網路的有效路徑。
PDU Session Establishment 使 UE 從“已註冊”進入“能夠承載應用程式流量”的狀態。UE 發起會話請求，網路選擇 SMF 與 UPF，取得與 DNN 和 S-NSSAI 相關的訂閱資料，取得會話策略，在 UPF 中設定 PFCP 規則，並與 gNB 協同建立 N3 隧道。流程結束時，UE 將獲得 IP 位址、QoS 規則以及通往 Data Network 的使用者平面路徑。
如果不把它理解成一條孤立的 NAS 訊息，這個流程會更容易理解。實際上有三件事情在同時發生：會話管理、策略控制以及使用者平面資源設定，最終共同形成一個可用的 PDU Session。
PDU 會話與 5GS 註冊之間的功能邊界
在 5GC 中，Registration 與 PDU Session 的分工很清晰：前者建立網路註冊關係，後者建立資料連線。
Registration 決定 UE 是否能夠接入 5GS。AMF 驗證 UE 身分、執行認證、建立 NAS 安全、取得與行動性相關的訂閱資料，並建立 RM（Registration Management）與 CM（Connection Management）所需的上下文。完成這些步驟後，UE 與核心網路之間的管理關係即建立。
PDU Session 則與實際資料服務直接相關。如果 UE 需要連線至 Internet、建立 IMS 連線或連線企業專用網路，僅完成 Registration 還不夠。網路還需要確定使用哪個 DNN、採用哪個 S-NSSAI、由哪個 SMF 控制會話、由哪個 UPF 承載使用者平面，以及允許的 QoS 和頻寬參數。
與 EPC 對比可以更容易記住這種區別。LTE 使用 PDN Connection 和 EPS Bearer 的概念；在 5GC 中，這一模型被 PDU Session + QoS Flow 取代。PDU Session 建立後，網路建立的是 QoS 規則和 QoS Flow 資源，而不是 LTE 形式的 Default EPS Bearer。
另一個重要點是，PDU Session 不一定必須與初始 Registration 同時建立。UE 可以先完成 Registration，在應用程式真正需要資料服務之前都不建立 PDU Session。例如，設備開機時完成註冊，但可能直到半小時後使用者打開影片應用程式時才建立 PDU Session。
這一區別對訊號追蹤分析非常有用。如果 Registration 已成功完成，但 PDU Session Establishment 沒有完成，反復檢查 5G-AKA、Registration Accept 或 T3512 通常無法解決資料服務問題，因為排查方向已經落在了錯誤的流程上。
PDU 會話請求中的 DNN、S-NSSAI 與請求類型
PDU Session Establishment 由 UE 傳送的一條 NAS 訊息開始。PDU Session Establishment Request 不只是簡單告訴核心網路“我需要資料連線”。請求中攜帶的資訊元素會影響後續的 NF 選擇與會話設定。
一個典型的初始請求可能包含 PDU Session ID、Request Type、PDU Session Type、SSC Mode、DNN 和 S-NSSAI。
PDU Session ID 用於區分同一 UE 所屬的多個會話。一個 UE 可以同時保持多個 PDU Session，例如一個用於 Internet 連線，另一個用於企業專用網路。SUPI 用於識別使用者，但僅憑 SUPI 並不能確定目前正在處理的是哪一個具體的 PDU Session。
DNN 用於識別 UE 希望連線的 Data Network。電信業者 Internet 連線、IMS 與企業網路可能使用不同的 DNN。DNN 還會參與後續流程中的 SMF 選擇、UPF 選擇以及策略決策。
S-NSSAI 將會話關聯到特定的網路切片（Network Slice）。AMF 與 SMF 需要確認所要求的網路切片是否與使用者訂閱、所請求 DNN 以及已部署網路能力相符。
Request Type 用於識別本次請求的場景。除了新建 PDU Session，該流程還可能與現有會話、連線變更或緊急業務場景有關。因此在訊號分析時，不能看到 PDU Session Establishment Request 就預設每次都是同一種場景。
最常見的是 Initial Request：UE 已完成 Registration，現在為指定 DNN 建立一個新的 PDU Session。SMF 選擇、UDM 訂閱資料取得、PCF 策略控制以及 UPF 資源建立，都會圍繞這一會話上下文展開。
AMF 的 SMF 選擇與 SM Context 建立
UE 的 NAS 會話管理訊息首先到達 gNB，隨後透過 NGAP 連同 NR-CGI、TAI 等連線相關資訊一起轉送給 AMF。gNB 不負責做 PDU Session 控制決策，它的作用是把 NAS 資訊傳送到核心網路。
AMF 收到請求後，需要找到能夠為所請求 S-NSSAI 與 DNN 提供服務的 SMF。
在基於服務的 5GC 架構中，AMF 可以透過 NRF 進行 NF 發現。發現條件可能包括目標 NF 類型、所需的 Nsmf_PDUSession 服務、S-NSSAI、DNN 和服務 PLMN。NRF 返回候選 SMF 實例後，AMF 再根據網路策略選擇實際提供服務的 SMF。
隨後，AMF 調用 SMF 的 PDU Session 服務建立一個 SM Context。除了 SUPI、PDU Session ID、DNN 與 S-NSSAI，請求中還會以 N1 SM information 的形式攜帶 UE 原始的 PDU Session Establishment Request。
從這一點開始，會話控制的核心從 AMF 轉移到 SMF。AMF 繼續負責連線與行動性管理，也繼續在 UE 和 SMF 之間轉送 N1 SM 訊號；但如何建立 PDU Session、選擇哪個 UPF、套用哪些策略以及如何設定使用者平面規則，都由 SMF 負責決定。
疑難排解時有一個實際問題很重要：商用網路中看到的 NRF 事務數量不一定與參考訊號圖完全一致。NF 發現結果可能被快取，也可能採用靜態設定，或者由 SCP 提供服務路由。更重要的問題不是追蹤中是否出現某一條特定 NRF 查詢，而是最終選中的 SMF 是否真正支援所需 DNN、S-NSSAI 與服務能力。
UDM 訂閱資料與 PCF 會話策略處理
SMF 明確 UE 請求的會話類型後，仍不能立即建立使用者平面。它首先需要確定該使用者實際被授權建立怎樣的 PDU Session。
在典型流程中，SMF 找到合適的 UDM，將自身註冊為為該 SUPI 和 PDU Session 提供服務的 SMF，並取得與所請求 S-NSSAI 與 DNN 相關的 Session Management Subscription Data。
訂閱資料可能包含允許的 PDU Session Type、SSC Mode、Session-AMBR 以及預設 QoS 相關設置。這些值定義該會話在使用者訂閱層面的邊界。例如，如果 UE 請求 IPv4 PDU Session，SMF 仍需確認該 DNN 是否允許這種 PDU Session Type，以及請求的 SSC Mode 是否被允許。
SMF 還可以訂閱 SM 訂閱資料的變化。如果 UDM 中相關會話管理訂閱資料之後被修改，UDM 可以透過已註冊的 Callback URI 通知目前提供服務的 SMF。
如果部署採用動態 SM Policy Control，SMF 會選擇 PCF 並建立 SM Policy Association。SMF 提供 SUPI、PDU Session ID、DNN、S-NSSAI、UE 位置以及訂閱 QoS 參數等上下文。隨後 PCF 返回已授權的會話策略，其中可能包括 Session-AMBR、預設 QoS 以及其他適用策略規則。
這一階段可以理解為會話參數的匯合過程：
UE 業務請求 → UDM 訂閱限制 → PCF 策略授權 → SMF 最終確定會話控制參數
後續安裝到 UPF 中的 QoS 與轉送規則，都以這些結果為依據。
N4 會話建立與 UPF 使用者平面規則下達
會話參數確定後，SMF 選擇一個能夠為所請求 DNN、S-NSSAI 和 UE 位置提供服務的 UPF，然後透過 N4 介面建立 PFCP Session。
PFCP Session Establishment Request 是 PDU Session Establishment 流程中最關鍵的節點之一。在此之前，網路處理的主要還是抽象的業務需求；到了 N4，這些需求會被轉換成 UPF 可對實際使用者封包執行的規則。
SMF 可以在 UPF 中下達 PDR、FAR、QER 和 URR 規則：
PDR：告訴 UPF 如何識別屬於該 PDU Session 或某一特定業務流的封包；
FAR：定義匹配封包應執行的動作，例如轉送、丟棄、快取或其他適用操作；
QER：在 UPF 中實施所需的 QoS 控制；
URR：定義使用者平面用量統計與上報要求。
這些規則不應被看成四個彼此無關的功能。它們共同定義 UPF 如何處理流量。PDR 負責識別封包流，並引用相應的 FAR、QER 和 URR，使 UPF 知道封包應該發往哪裡、應用程式哪些 QoS 控制以及是否需要統計用量。
當 UPF 接受 PFCP Session Establishment 後，會返回自身的 F-SEID 以及已建立的使用者平面參數。其中最重要的結果之一，就是用於 N3 的 UPF 側使用者平面位址和 TEID。
但此時下行路徑可能仍未完整，因為 gNB 尚未完成其 N3 資源分配。因此，PDU Session Establishment 並不會在一次 PFCP 請求後就結束，流程還需要等待 RAN 完成其使用者平面側的設定。
N1/N2 訊號完成 N3 隧道與 QoS Flow 建立
UPF 側資源準備完成後，SMF 需要透過 AMF 返回兩類不同的資訊。
第一類是 N1 SM information，最終傳送給 UE。其中包含 PDU Session Establishment Accept，以及會話建立後 UE 所需的參數，例如 PDU Session Type、SSC Mode、DNN、S-NSSAI、UE IP 位址、Session-AMBR 和預設 QoS Rule。
第二類是 N2 SM information，目標是 gNB。它告訴 RAN 正在建立哪個 PDU Session、涉及哪些 QoS Flow，以及 N3 應使用哪個 UPF IP 位址與 TEID。
AMF 透過 NGAP 向 gNB 傳送 PDU Session Resource Setup Request。gNB 分配所需的無線與 N3 資源，並把 PDU Session Establishment Accept 轉送給 UE。
資源建立完成後，gNB 返回 PDU Session Resource Setup Response，其中攜帶自身的 N3 使用者平面位址和 TEID，以及成功建立的 QoS Flow 資訊。
這裡有一個關鍵的時序細節。SMF 最初建立 PFCP Session 時，已經知道 UPF 側 N3 資訊，但可能還不知道最終的 gNB 側隧道資訊。gNB 返回其 N3 位址與 TEID 後，AMF 將這些資訊轉送給 SMF。隨後 SMF 使用 PFCP Session Modification 更新 UPF 中相關 FAR，使下行封包能夠封裝到正確的、指向 gNB 的 GTP-U 隧道中。
到這一步，上行與下行使用者平面路徑才真正完整：
UE → gNB → N3 GTP-U → UPF → N6 → Data Network
Data Network → N6 → UPF → N3 GTP-U → gNB → UE
因此，僅收到 PDU Session Establishment Accept 並不能證明所有使用者平面要素都正確。還需要結合實際封包轉送，驗證 N3 隧道參數、PFCP Session Modification 以及最終的 UPF 規則。
PDU 會話建立的訊號疑難排解
PDU Session Establishment 涉及多個網路功能。如果從第一個封包開始逐條對比全部訊息，疑難排解很快會變得混亂。更高效的方法是把流程劃分為幾個檢查點，逐步縮小故障範圍。
確認會話請求正確到達 AMF
首先確認 UE 已完成所需的 5GS Registration。隨後檢查 PDU Session Establishment Request，確認 PDU Session ID、Request Type、DNN、S-NSSAI、PDU Session Type 和 SSC Mode 是否合理。如果請求在入口處就攜帶了無效參數，即使 SMF 與 UPF 狀態正常，也無法建立預期會話。
確認 SMF 建立有效的 SM Context
接下來確認 AMF 選擇了合適的 SMF，並且 Create SM Context 成功。目標不只是在訊號追蹤中找到一條 NRF 訊息，而是確認所選 SMF 支援所需的 DNN、S-NSSAI 和服務能力。
然後確認 UDM 返回的 SM 訂閱資料允許所請求的 PDU Session，並且 PCF 策略與預期 QoS 設定一致。
確認 UPF 與 N3 資源完整
如果控制面已經返回 PDU Session Establishment Accept，但 UE 仍然無法傳輸資料，排查重點應下沈到 N4 與 N3。
按以下順序檢查：
PFCP Session Establishment 是否成功，以及 UPF 是否建立了對應會話；
PDR、FAR、QER 等規則是否與預期流量方向一致；
gNB 是否成功返回其 N3 使用者平面 IP 位址與 TEID；
SMF 是否透過 PFCP Session Modification 將 gNB 隧道資訊更新到 UPF；
N3 上是否實際出現了使用預期 TEID 的 GTP-U 封包；
UPF 是否能夠透過 N6 成功向目標 Data Network 傳送與接收流量。
按照這一順序排查，可以把問題逐步縮小到 NAS、SBI、N4、N3 或 UPF 封包轉送，而不是把整個 5GC 當作一個無法區分的故障範圍。
常見問題
為什麼 UE 已完成 5G 註冊仍然無法連線至 Internet？
Registration 建立 UE 與 5GC 之間的連線、身分、安全和行動性上下文，但不會自動建立使用者資料路徑。在 UE 能夠連線至 Internet 或其他 Data Network 之前，仍需要建立 PDU Session，使 SMF 能夠設定會話參數、UPF 資源以及 N3 使用者平面。
UE 開機時一定會建立 PDU Session 嗎？
不一定。PDU Session 可以在 Registration 前後建立，也可以等到 UE 真正需要資料服務時再發起。5GS 允許 UE 在沒有活動 PDU Session 的情況下保持已註冊狀態，因此不能把 Registration 完成與 PDU Session Establishment 當成同一個事件。
PDU Session Establishment 成功是否意味著 UE 一定能連線至 Internet？
不一定。僅在 NAS 層收到 PDU Session Establishment Accept，並不足以證明資料連線已經成功。實際使用者流量還依賴 gNB 與 UPF 之間的 N3 隧道、UPF 內的 PDR/FAR/QER 規則、N6 連線以及目標 Data Network。即使 UE 已獲得 IP 位址，使用者平面轉送仍然可能存在錯誤。
為什麼 PFCP Session Establishment 之後還會發生 PFCP Session Modification？
在 UPF 中首次建立 PFCP Session 時，gNB 可能尚未完成 N3 資源分配，因此 SMF 可能還不知道最終的 gNB 使用者平面 IP 位址與 TEID。gNB 在 PDU Session Resource Setup Response 中返回這些值後，SMF 透過 PFCP Session Modification 更新 UPF 中相應規則，使下行流量能夠經正確的 N3 GTP-U 隧道傳送。
PDU Session 中的 QFI 與 N4 介面上的 QER 是同一個概念嗎？
不是。QFI 用於識別 5GS 中的 QoS Flow，而 QER 是 SMF 透過 N4 設定到 UPF 的 QoS Enforcement Rule。QER 參與 QoS 執行，並可在適用場景下與 QFI 關聯，但 QFI 本身不是 QER，兩者不能互換理解。
