博主未授权任何人或组织机构转载博主任何原创文章，感谢各位对原创的支持！
博主链接
本人就职于国际知名终端厂商，负责modem芯片研发。
在5G早期负责终端数据业务层、核心网相关的开发工作，目前牵头6G算力网络技术标准研究。
博客内容主要围绕：
5G/6G协议讲解
算力网络讲解（云计算，边缘计算，端计算）
高级C语言讲解
Rust语言讲解
文章目录
- GTP-U协议介绍
-
- 一、GTP-U协议栈介绍
-
- [1.1 数据传输协议栈](#1.1 数据传输协议栈)
- [1.2 信令传输协议栈](#1.2 信令传输协议栈)
- [二、GTP-U Header介绍](#二、GTP-U Header介绍)
-
- [2.1 固定部分](#2.1 固定部分)
- [2.2 扩展字段](#2.2 扩展字段)
- 三、扩展头介绍
-
- [3.1 NR相关的扩展头介绍](#3.1 NR相关的扩展头介绍)
- 四、控制相关的信令
-
- [4.1 路径管理消息](#4.1 路径管理消息)
- [4.2 隧道管理消息](#4.2 隧道管理消息)
- 参考
GTP-U协议介绍
一、GTP-U协议栈介绍
1.1 数据传输协议栈
T-PDU（Transport PDU） ：用户数据包，如IP数据报，是指终端与外部包数据网络中的网络实体之间发送的用户数据包。
G-PUD（GTP encapsulated user Plane Data Unit）：用户数据包（T-PDU）加上GTP-U报头，在GTP网络节点之间发送的数据包。
用户数据包（T-PDU）封装上GTP-U包头之后，通过UDP/IP发送出去。
1.2 信令传输协议栈
IE：Information Element
使用传输GTP-U路径和隧道管理相关的消息，不同的消息类型具有不同的数据结构，将这些不同的数据结构统称为IE。
NOTE：在实现的时候，需要注意GTP-U具有熟知目标端口号2152。
二、GTP-U Header介绍
GTP-U的头由两部分组成，第一部分是固定部分，长度为8 bytes；第二部分是扩展部分，根据第一部分相关flag的值，确实是否存在或者有效。下面先介绍固定部分的参数含义。
2.1 固定部分
固定部分的长度为8 bytes，如下图所示部分：
其中，
-
Version field：指示GTP-U协议版本，目前固定是1；
-
Protocol Type（PT）：用于区分GTP和GTP' 协议，对于GTP协议来说设置为1，GTP' 协议设置为0；
-
Extension Header flag（E）：指示Next Extension Header Type字段是否有效；
-
Sequence number flag（S）：指示Sequence Number字段是否有效；
-
N-PDU Number flag（PN）：指示N-PDU Number字段是否有效；
-
Message Type：指示GTP-U消息的类型，支持的消息类型如下；
-
Length：指示GTP-U消息的长度，单位是byte，长度不包括固定字段（即前8 bytes）。如果存在扩展字段，则应该计算到Length中；
-
Tunnel Endpoint Identifier（TEID）：唯一标识一个GTP隧道的端点。此值由接收端分配，通过控制平面消息传输给发送端。发送端在发送消息时携带接收端的TEID，标识此消息是发送给那个接收端。通常情况下不应该为0，但是为了后向兼容，如果接收端通知TEID为0，发送端也要视为正常情况处理。对于Echo Request/Response、Supported Extension Headers notification、Error Indication消息，需要将TEID设置为0；
2.2 扩展字段
GTP-U有3个扩展字段，
其含义如下：
- Sequence Number：因为UDP不支持按序传输，为了支持按序传输，需要通过该字段为每个G-PDU消息增加序号；
- N-PDU Number：该字段用于SGSN间路由区域更新过程和一些系统间切换过程（例如，2G和3G无线接入网络之间）。该字段用于协调MS和SGSN之间的公认通信模式的数据传输。该字段的确切含义取决于具体场景（例如，对于GSM/GPRS到GSM/GPRS，SNDCP N-PDU号在这个字段中）；
- Next Extension Header Type：指示此字段后面的扩展头类型，支持的扩展类型值如下所示；
NOTE：如果E、S、PN中的任意一个字段有效（置为1），则上述扩展字段都会出现，但只有有效字段对应的扩展字段的值才有意义。例如E=1，S=0，PN=0，则Sequence Number、N-PDU Number和Next Extension Header Type都存在，但是只有Next Extension Header Type的值有意义。
三、扩展头介绍
扩展头的消息结构如下：
- Extension Header Length：指示特定扩展头的长度，其长度是4的倍数，即以4字节为单位；
- Extension Header Content：由具体的扩展头类型确定；
- Next Extension Header Type：指示此字段后面的扩展头类型，如果没有此值应该为0；
3.1 NR相关的扩展头介绍
| 扩展头 | 含义 |
|---|---|
| UDP Port | 在Error Indication消息中指示发送此错误消息的端口号 |
| PDCP PDU Number | 在NR中用于基于Xn和N3切换中的数据转发 |
| Long PDCP PDU Number | 在NR中用于基于Xn和N3切换中的数据转发，对应于PDCP SN长度为18bit |
| NR RAN Container | 这个扩展头可以在G-PDU中通过NG-RAN中的X2-U、Xn-U和F1-U用户平面接口传输，对于EN-DC来说，可以在E-UTRAN中传输。带有这个扩展头的G-PDU消息可以在没有T-PDU的情况下发送 |
| PDU Session Container | 这个扩展头可以在N3和N9用户平面接口，即NG-RAN和UPF之间或两个UPF之间传输 |
四、控制相关的信令
GTP-U隧道用于在给定的一对GTP-U隧道端点之间携带封装的T-PDU和信令消息。GTP头中的TEID指示一个特定的T-PDU属于哪个隧道。通过这种方式，可以在一对隧道端点之间通过GTP-U复用和解复用数据包。TEID的值会在GTP-C创建PDP上下文和RAB分配过程中进行协商。
GTP-U信令消息分为路径管理消息和隧道管理消息。
4.1 路径管理消息
- Echo Request/Echo Response：GTP-U端可能会在路径上向另一端发送一个Echo请求，以确定另一端是否还活着(参见"路径失败"一节)。可以为使用中的每个路径发送Echo请求消息。如果至少有一个PDP上下文、EPS Bearer上下文、PDU Session上下文、MBMS UE上下文或MBMS Bearer上下文使用了到另一端GTP-U的路径，则认为该路径已被使用。发送Echo请求消息的时间和频率取决于具体的实现，但在每个路径上发送Echo请求的频率不应超过60秒；
- Supported Extension Headers Notification：此消息表示指定IP地址上的GTP实体可以支持的扩展头列表。只有在GTP实体需要强制支持某个扩展头，但GTP实体尚未升级以支持该扩展头的情况下，才会发送此消息。发送此消息的GTP端点被标记为不支持某些扩展头。对端GTP实体可能会重试使用该节点的所有扩展标头，以尝试验证它已经升级；
4.2 隧道管理消息
- Error Indication：当接收端发生错误的时候，向发送端发送错误原因，并指示哪个接收端发送的错误；
- End Marker：表示给定隧道的有效载荷流结束，即在该隧道的End Marker消息之后到达的G-PDU可能会被静默丢弃。如果接收到带有TEID且没有上下文的End Marker消息，则接收方将忽略此消息；
- Tunnel Status：隧道状态信息是可选的。一个GTP-U实体如果支持该消息，可以向对端GTP-U实体发送一条或多条隧道状态消息，提供发送方GTP-U实体中与对应GTP-U隧道相关的状态信息；
参考
- TS 29.281
