当 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 会话的释放流程。
