UMTS - GPRS 隧道协议
GPRS 隧道协议 (GTP) 的生成实际上是不可能的，但也不希望为新系统提供它，但是，另一方面，为了能够与旧版 PS 世界顺利交互并支持最新系统所需的功能，也需要进行改进，这是可以理解的。
GPRS 隧道协议 (GTP)
GTP 协议专为 GPRS 中数据单元和控制消息的隧道传输和封装而设计。 自20世纪90年代末设计以来，经过大规模部署，积累了丰富的经验。
演进 3GPP 系统的 GTP 有两种变体：控制平面和用户平面。 GTP-C管理控制面信令，除了用户纯度上的数据传输协议外，还需要GTP-U； 它被称为用户平面。 当前适用于 EPS 的版本是 GTPv1 US 和 GTPv2-C。
GTP 的独特之处在于它支持其主要 GTP 隧道持有者内的流量分离，或者换句话说，能够将它们组合在一起并处理载波。 GTP隧道的端点通过TEID（隧道端点标识符）来标识； 它们由对等实体分配给上行链路和下行链路的本地级别，并在它们之间横向报告。 TEID 通过 S5 和 S8 上的具体示例 PDN 连接以及 S3 / S4 / S10 / S11 接口上的 EU 以不同的粒度使用。
GPRS隧道协议的控制平面
GTPv2-C 用于 EPC 信令接口（包括至少版本 8 的 SGSN）。 例如 −
- S3（SGSN 和 MME 之间），
- S4（SGSN 和服务 GW 之间），
- S5 和 S8（服务 GW 和 PDN GW 之间），
- S10（两个 MME 之间），以及
- S11（MME 和服务 GW 之间）。
与此对应，一个典型的GTPv2-C协议数据单元如上图所示，具体部分GTP前面是IP和UDP头，它由标头 GTPv2-C 和包含数量、长度和格式可变的信息 GTPv2-C 的部分组成，具体取决于消息的类型。 由于不支持协议版本的回显和通知，因此不存在TEID信息。 在这个版本的协议中，版本显然被坚定地设置为2。
GTP 有一个复杂的遗留扩展头机制； 大多数 GTPv2-C 中未使用它。 消息类型在第二个字节中定义（因此最多可以定义 256 个消息以供将来扩展）。 下表提供了当前定义的 GTPv2-C 消息的概述。 消息的长度以字节 3 和 4 编码（以字节为单位测量，不包含前四个字节本身）。
TEID是隧道端点的ID，对端/接收端的单个值； 它允许在必须区分 GTP 隧道上非常频繁的情况下，在一端复用和解复用隧道。
| 消息类型 | 消息 | 附加说明 |
|---|---|---|
| 0 | Reserved | 永远不得使用（故意从协议中排除，以强制执行显式设置） |
| 1/2 | Echo Request/ Response | 用于探测发送节点是否支持GTP版本。 |
| 3 | Version Not Supported Indication | 包含发送节点支持的最新GTP版本。 |
| 4/5 | Direct Transfer Request/ Response | 用于 S101 接口上的隧道信令消息，以优化 HRPD 接入与 MME 之间的切换 |
| 6/7 | Notification Request/ Response | 用于HRPD接入节点和MME之间S101上的隧道通知 |
| 25/26 | SRVCC PS to CS request | 用于触发并确认SGSN/MME与MSC服务器之间的SRVCC发起 |
| 27/28 | SRVCC PS to CS complete Notification | 用于指示并确认MSC服务器与SGSN/MME之间SRVCC的完成 |
| 32/33 | Create Session Request | 用于建立两个节点之间的连接 |
| 34/35 | Modify Bearer Request | 用于修改单个或多个承载的属性，包括承载上下文信息 |
| 36/37 | Delete Session Request | 拆除 GTP 控制会话 |
| 38/39 | Change Notification request | 用于报告位置信息 |
| 66/67 | Delete bearer command/ failure indication | 指示节点删除承载并返回确认 |
| 68/69 | Bearer resource command/ failure indication | 用于分配或修改资源 |
| 73 | Stop paging indication | 从SGW发送到MME或SGSN |
| 95/96 | Create bearer request/ response | 指示节点安装承载并确认 |
| 97/98 | Update bearer request | 用于从用户面通知控制面节点承载变化 |
增强型 GTPv1-U
GTP-U仅进行了微小但有效的改进，因此认为没有必要加强协议版本数。 因此，我们仍然期望 GTPv1-U，但至少是最新的 Rel. 8。
协议栈本质上与 GTPv2-C 相同，只是相应地替换了层名称和协议。 扩展头机制保持不变； 如有必要，它允许插入两个元素。
触发消息的UDP源端口（两个八位字节）；
PDCP PDU 编号 − 与无损失特征转移相关； 在这种情况下，数据包需要在 EPC 中编号（两个八位字节）。
改进在于在用户平面传输"终端市场"的能力。 它用在 eNodeB 间切换过程中，并给出在数据包之后立即激活路径的指示，例如，该功能对于 pre-Rel.8 来说不是必需的，因为 GTP-U 并未在无线接入节点中结束（即不是 在 BS 或 NodeB 中）仅存在少量消息。 GTPv1-U，它们列于上表中。
很明显，事实上，通过 GTPv1-U（回声机制和末端标记）可以实现非常有限的信号传递。 传输真实用户数据的唯一消息是255类型，即所谓的G-PDU消息； 标头之后它携带的唯一信息是来自用户或外部 PDN 设备的原始数据包。
并非所有 GTP-U 隧道实例都列在参考架构中（其目的是捕获网络节点之间不再存在的关联）； 临时隧道是可能的 −
两个Serving GW之间，适用于基于S1的转移，业务移动GW的情况；
在两个 SGSN 之间，对应于前面的情况，但在传统 PS 网络中；
两个RNC之间，适用于3G PS网络中RNC的迁移（与EPC无关，这里只是为了完整而提及）。
