當 UE 打開一個影片應用程式時，實際的用戶流量必須從 gNB 傳到 UPF，然後才能到達數據網路。控制面負責建立 PDU 會議、分配位址並下發轉發規則，但真正在 5G 接取網路和核心網用戶面之間承載用戶 IP 封包的是 GTP-U。理解 GTP-U 不僅僅是記住「UDP 連接埠 2152」和「TEID」。在 5G 中，一條 N3 隧道可能承載多個 QoS Flow，而路徑檢測、未知隧道處理以及移動性事件後的用戶面清理也都依賴 GTP-U 管理訊息。把協定堆疊、隧道、TEID、QFI 和管理流程作為一個完整的用戶面路徑來看，會更容易理解 5G 流量到底是如何到達 UPF 的。
GTP-U 在 5G 架構中的位置
GTP-U 的全稱是 GPRS Tunnelling Protocol for the User Plane，即用於用戶面的 GPRS 隧道協定。在 5G 用戶面架構中，它主要用於在用戶面節點之間封裝和傳輸上層用戶流量。
從 5G 核心網的角度來看，使用 GTP-U 的兩個最常見的介面是 N3 和 N9。N3 連接 gNB 和 UPF，承載無線接取網路與 5G 核心網之間的用戶流量。N9 用於 UPF 之間。在無線接取網路內部，gNB 之間的 Xn-U 介面也可以使用 GTP-U。
這與 5G 控制面架構有很大不同。AMF 和 SMF 等網路功能使用基於服務的介面，主要依賴 HTTP/2，而用戶面路徑繼續使用 GTP-U 來承載用戶的真實流量。5G 轉向基於服務的架構，並不意味著用戶面本身也轉向了 HTTP。
GTP-U 運行在 UDP 之上，繼續使用 UDP 連接埠 2152。如果從用戶的應用程式數據封包向下看協定堆疊，結構可以這樣理解：
應用流量首先成為 TCP 或 UDP 封包，然後成為屬於 UE 的 IP 封包。一旦進入 5G 用戶面，這個原始的用戶封包就被封裝在 GTP-U 內部。之後會添加外層 UDP 標頭、外層 IP 標頭以及用於 GTP-U 端點之間傳輸的下層乙太網路訊框。
這意味著一個封包擷取中可能包含兩組不同的 IP 位址。內層 IP 位址描述的是 UE 與數據網路上應用伺服器之間的通訊，而外層 IP 位址則用於 GTP-U 隧道端點（如 gNB 和 UPF）之間的傳輸。在排查 N3 流量時，混淆內層和外層 IP 標頭是一個常見的困惑來源。
GTP 路徑、隧道和 TEID 有什麼區別？
GTP 路徑、GTP 隧道、隧道端點和 TEID 是密切相關的術語，但它們描述的是 GTP-U 傳輸模型的不同層次。
GTP 路徑可以看作兩個 GTP 隧道端點之間無連接的通訊路徑。如果一個 gNB 和一個 UPF 能夠透過 IP 網路交換 GTP-U 封包，那麼這兩個端點之間就存在一條 GTP 路徑。多條 GTP-U 隧道可以共享同一條路徑。
GTP 隧道代表更具體的邏輯用戶面隧道。一條 GTP-U 隧道透過 TEID、IP 位址和 UDP 傳輸資訊的組合來標識，而隧道端點本身則由節點 IP 位址和 UDP 連接埠來標識。
TEID，即隧道端點識別碼，是 GTP-U 中最重要的欄位之一。在 GTPv1-U 基本標頭中，TEID 為四位元組。當 GTP-U 封包到達接收節點時，接收方使用 TEID 結合本地隧道上下文來確定該封包屬於哪條用戶面隧道，以及應該由哪個 PDU 會議或轉發上下文來處理它。
這也是為什麼 TEID 永遠不應該被孤立地解讀。相同的 TEID 數值可以出現在不同的隧道上下文中。如果這些封包屬於不同的 GTP 端點或不同的方向，它們就不一定屬於同一條隧道。
在查看酬載本身時，還有兩個有用的術語。T-PDU 是原始的上層用戶數據，而 G-PDU 是添加了 GTP-U 標頭之後的 T-PDU。因此，在 N3 上傳輸的並不是 UE 的原始 IP 封包本身，而是經過 GTP-U 封裝的 G-PDU。
GTP-U 也不僅僅用於承載用戶數據。它有自己的管理訊息。因此，在封包擷取中看到 UDP 連接埠 2152 並不自動意味著該封包屬於用戶應用流量。Echo Request、Echo Response、Error Indication、End Marker 以及其他 GTP-U 訊息都使用相同的協定框架。
5G 已經有了 TEID，為什麼還需要 QFI？
如果第一次學習 GTP-U 是從 4G 的角度出發，很容易假設識別出 TEID 就足以識別承載。但在 5G 中，這個假設不再完整。
4G 的 QoS 架構基於 EPS 承載。不同的承載有各自的用戶面傳輸上下文和 GTP-U 隧道，因此隧道和 TEID 天然有助於區分不同的承載流量。
5G 將 QoS 模型改為 PDU 會議加 QoS Flow。一個 PDU 會議可能包含一個或多個 QoS Flow，一個 DRB 也可能承載一個或多個 QoS Flow。然而，N3 並不會為同一個 PDU 會議內的每個 QoS Flow 都建立單獨的 GTP-U 隧道。
換句話說，TEID 可以標識與 PDU 會議關聯的 GTP-U 隧道，但多個 QoS Flow 仍然可能共享同一條隧道。
這就引出了另一個問題：接收節點如何知道單個封包屬於哪個 QoS Flow？
這就是 PDU Session Container 擴展標頭存在的主要原因之一。5G 使用這個 GTP-U 擴展標頭來承載與 PDU 會議相關的用戶面資訊，包括 QFI，即 QoS Flow 識別碼。
QFI 是一個 6 位元的識別碼，用於標識一個 QoS Flow。因此，在分析 5G N3 流量時，TEID 和 QFI 可以在兩個不同的層面上理解：
TEID 標識 GTP-U 隧道或 PDU 會議上下文，而 QFI 標識該隧道內部承載的具體 QoS Flow。
下行 PDU Session Container 還可以攜帶 RQI 和 PPI 等資訊。RQI 用於與反射 QoS 相關的信令，而 PPI 與尋呼策略區分相關，可以在同一個 PDU 會議內為不同類型的流量支援不同的尋呼處理。
GTP-U 基本標頭中的 E 位元表示後面是否跟有擴展標頭。這意味著不是每個 GTP-U 封包都一定攜帶相同的擴展標頭。PDU Session Container 是否存在取決於具體的封包和正在執行的功能。
N3 用戶數據封包實際經歷了什麼？
將前面的概念放到一個真實的上行數據封包流程中，就更容易理解了。
假設一個 UE 正在存取線上影片服務。UE 首先產生應用流量，透過 TCP 或 UDP 承載，然後放入一個普通的 IP 封包中。在這個內層 IP 標頭中，來源位址是 UE 分配到的 IP 位址，目的位址屬於網際網路上的應用伺服器。
當數據封包到達 gNB 時，gNB 並不會簡單地把 UE 的 IP 封包直接轉發給 UPF。它會根據 PDU 會議當前的用戶面上下文進行 GTP-U 封裝。
GTP-U 標頭中包含相應的 TEID。如果數據封包需要標識特定的 QoS Flow，PDU Session Container 還可以攜帶 QFI。然後 gNB 添加 UDP 標頭，目的連接埠為 2152，接著是外層 IP 標頭。
此時，外層 IP 位址不再描述 UE 到網際網路的通訊，而是代表 gNB N3 介面和 UPF N3 介面之間的傳輸關係。
當數據封包到達 UPF 時，過程反轉。UPF 根據外層傳輸資訊接收數據封包，讀取 TEID 以定位正確的用戶面隧道上下文，在需要時處理 QFI 和其他擴展資訊，移除 GTP-U 封裝，然後將原始的 UE IP 封包轉發到數據網路。
使用 Wireshark 或其他封包擷取分析工具排查 N3 流量時，一個有效的方法是從外向內。首先確認外層 gNB 和 UPF 的 IP 位址，然後是 UDP 連接埠 2152，接著是 TEID，再然後是 PDU Session Container 和 QFI（如果存在），最後才檢查用戶的內層 IP、TCP 或 UDP 以及應用層流量。
這種方法通常比從應用封包開始更有效，因為許多 N3 故障是由隧道上下文、TEID 或端點問題引起的，而不是用戶應用本身的問題。
為什麼 GTP-U 需要自己的管理訊息？
雖然 GTP-U 是用戶面協定，但它並不侷限於 G-PDU 用戶數據訊息。它還定義了路徑管理和隧道管理訊息，幫助保持用戶面傳輸的正常運行。
Echo Request 和 Echo Response 檢查路徑可用性
Echo Request 用於檢查 GTP 路徑和對端 GTP 節點是否可達且正常運行。對端以 Echo Response 回應。
這些訊息測試的是兩個 GTP 端點之間的基本關係。如果 gNB 反覆無法收到來自 UPF 的 Echo Response，問題可能不再侷限於某個 UE 或某個 PDU 會議，而是可能表明 GTP 路徑本身或對端節點出了問題。
GTP-U 還定義了 Supported Extension Headers Notification 訊息，允許節點表明它支援哪些 GTP 擴展標頭。當 5G 用戶面功能依賴 PDU Session Container 等擴展標頭時，這一點就變得很重要。
Error Indication 處理未知 TEID
如果 GTP 端點收到一個 G-PDU，但找不到與收到的 TEID 對應的本地 EPS 承載或 PDU 會議上下文，且 TEID 不為零，它就可以向對端發送 Error Indication。
這告訴發送節點，它正在向接收端已不再識別的用戶面隧道轉發數據。
如果在排查過程中反覆出現 Error Indication 訊息，首先應該檢查兩端是否具有一致的 TEID 狀態，以及 PDU 會議更新、移動性流程或用戶面路徑變更是否導致兩端狀態不同步。
End Marker 幫助完成用戶面路徑切換
End Marker 通常與移動性和用戶面路徑切換相關。它表示舊 GTP-U 路徑上的最後一個 G-PDU 已經發送，後續的用戶流量不應再沿著之前的路徑繼續傳輸。
例如，當 UE 從來源 gNB 移動到目標 gNB 時，核心網用戶面路徑也可能發生變化。流量不應該在舊路徑上無限期地繼續下去，否則新舊路徑可能重疊，造成封包順序或轉發問題。
因此，End Marker 並不是簡單的「刪除隧道」通知。它更像是舊用戶面路徑的邊界標記，告知接收端該路徑上的最後一個封包已經送達。
當把這些機制放在一起看時，GTP-U 的角色就更加清晰了。它並不只是一個在用戶 IP 封包前面加上 TEID 的協定，而是一個完整的用戶面隧道框架，可以隨著網路狀態的變化進行標識、監控、管理和更新。
因此，排查 5G GTP-U 問題的實用順序是：首先確認 GTP 端點和路徑是否健康，然後檢查 TEID 和隧道上下文，接著在適用時檢查 PDU Session Container 和 QFI，最後再進入原始的用戶流量。如果問題發生在移動性或路徑更新期間，還應該查看 Error Indication 和 End Marker 訊息。
按照這個順序，N3 封包擷取就從一大堆 UDP 2152 封包變成了一條可以逐層還原的用戶面轉發路徑。
常見問題
UDP 連接埠 2152 上的每個封包都承載用戶流量嗎？
不是。G-PDU 訊息透過 GTP-U 和 UDP 連接埠 2152 承載用戶面數據，但 Echo Request、Echo Response、Error Indication、End Marker 和 Supported Extension Headers Notification 等 GTP-U 管理訊息也使用相同的協定框架。應檢查 GTP-U 訊息類型來確定該封包實際代表什麼。
TEID 必須在整個 5G 網路中全域唯一嗎？
不需要。TEID 不應該被當作整個網路範圍內全域唯一的識別碼。GTP-U 隧道的標識還取決於隧道端點、IP 位址、傳輸資訊和方向。因此，排查問題時應考慮完整的隧道上下文，而不是僅僅比較 TEID 數值。
每個 5G GTP-U 封包都包含 PDU Session Container 嗎？
不是。PDU Session Container 是 GTP-U 擴展標頭，是否存在取決於具體的封包和正在執行的功能。GTP-U 基本標頭中的 E 位元表示後面是否跟有額外的擴展標頭，因此不是每個 N3 封包的標頭結構都相同。
End Marker 是否意味著整個 PDU 會議已經釋放？
不一定。End Marker 主要表示特定 GTP-U 用戶面路徑上的流量已經到達終點，通常出現在移動性事件後的路徑切換過程中。它標記的是該路徑上流量的結束，而不是整個 PDU 會議的釋放流程。
