| 網際網路套組 |
| --- |
| 應用層 |
| * BGP
* DHCP
* DNS
* FTP
* HTTP
* HTTPS
* IMAP
* LDAP
* MGCP（英语：）
* MQTT
* NNTP
* NTP
* POP
* ONC/RPC
* RTP
* RTSP
* SIP
* SMTP
* SNMP
* Telnet
* TLS／SSL
* SSH
* XMPP
* *更多...*
 |
| 傳輸層 |
| * TCP
* UDP
* DCCP
* SCTP
* RSVP
* *更多...*
 |
| 網路層 |
| * IP
	+ IPv4
	+ IPv6
* ICMP
* ICMPv6
* ECN
* IGMP
* OSPF
* IPsec
* RIP
* *更多...*
 |
| 連結層 |
| * ARP
* NDP
* Tunnels
	+ L2TP
* PPP
* MAC
	+ Ethernet
	+ DSL
	+ ISDN
	+ FDDI
* *更多...*
 |
| * 
* 论
* 编
 |

**GTP'**（GTP prime）是一个用于GSM和UMTS通信网络的基于IP网络的协议。它可以使用UDP或TCP的传输。尽管GTP'协议的消息结构与GTP相同（包括控制面的GTP-C和用户面的GTP-U），它仍是一个独立协议。GTP'协议使用UDP/TCP端口3386。

GTP'的功能是在GSM、UMTS和LTE核心网中将计费数据从计费数据功能（）传输到计费网关功能（）。计费数据功能是对"计费"这一功能的抽象，以具体网元为例，通常是GGSN或SGSN等。而计费网关功能通常是一台中心服务器，收集各网元的计费数据，再统一传输给网络运营商的计费中心（）最终生成账单。

在3GPP定义的GPRS核心网的Ga接口上使用的是GTP'协议。

GTP'重用了GTP协议的诸多方面，然而在3GPP TS 32.295中却描述为"仅仅部分重用了GTP协议的控制面"。GTP'定义了与GTP不同的消息头结构、独有的消息类型、信元，以及一整套防止计费数据丢失或重复计算的机制。GTP'协议所传输的计费数据记录（英语：）（英語：）以ASN.1协议编码。

消息头结构
-----

GTP'消息头结构如下。

| + | Bits 0-2 | 3 | 4 | 5 | 6 | 7 | 8-15 | 16-31 | 32-47 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 0 | 版本号Version | 协议类型PT [0] | 保留Reserved | 头长度Hdr len | 消息类型Message Type | 消息长度Length | 序列号Sequence Number |

版本号（Version）长度为3比特。与GTP协议的这一字段含义相同。
协议类型（Protocol Type (PT)）长度为1比特。对GTP'协议来说取值必须为0。取值为1表示是GTP协议。
保留（Reserved）长度为3比特，保留不用。取值必须全为1。
头长度（Header Length (Hdr len)）长度为1比特。当版本号取值为0时有意义，此时本字段取值为0表示消息头长度为20字节，取值为1表示消息长度为6字节。当版本号不为0时此位取值必须为0。
消息类型（Message Type）长度为8比特，其值表示该GTP'消息的类型。
消息长度（Length）长度为16比特，其值表示该GTP'消息体长度，不包括消息头本身。
序列号（Sequence Number）长度为16比特，表示该GTP'消息的序号，用于检测消息丢失或重复。

消息类型
----

GTP'协议重用了GTP协议的Version Not Supported、Echo Request和Echo Response这3种消息，此外还定义了如下3对消息。

* Node Alive Request/Response
* Redirection Request/Response
* Data Record Transfer Request/Response

### Node Alive Request/Response

Node Alive消息对用于通知其他网元，本网元已经正常工作。Node Alive Request在网元启动完成时发送，与Echo消息对所提供的通常维60秒间隔的握手机制相比，该消息对能够及时通知对端网元继续之前中断的传输。Node Alive Request也可以用于将其他网元的状态恢复通知给对端网元。

在GTP' version 2中，Node Alive Request支持IPv6地址。

### Redirection Request/Response

Redirection消息对可以用于

1. 由CGF通知CDF，另其将CDR发送给另外的CGF。可用于CGF因维护或发生故障停止服务的场景。
2. 由CGF通知CDF，自己与一个下游网元之间失去连接。

与GTP提供的Echo机制相比，Redirection消息对的好处是，CDF能从Redirection Request消息中得到CGF停止服务的直接或间接的原因。

### Data Record Transfer Request/Response

Data Record Transfer消息对提供了对CDR的可靠传输机制。

#### Data Record Transfer Request

Data Record Transfer Request可以有以下4种功能。

1. 发送数据记录（）：该消息可以携带0条至数条CDR。CDR应以ASN.1编码，通常使用BER（英语：）编码规则，也可以使用PER编码规则。
2. 发送"可能重复"（）的数据记录：该消息可以携带1条至数条已经向其他CGF发送过的CDR。
3. 取消数据记录：该消息通知一个CGF从其"可能重复"缓存中清除1条或多条CDR。
4. 释放数据记录：该消息通知一个CGF处理（使之生效）1条或多条CDR，并从"可能重复"缓存中移除。

Data Record Transfer消息对提供了一套防止丢失或重复计算CDR的机制。其大致机理为，CDF为每一条CDR编制序列号，CGF必须在Data Record Transfer Response消息中逐一对每一个序列号进行确认，未得到确认的CDR将被重传。正常的CDR在被收到后会被转存到非易失性存储设备（例如硬盘）中，但重传的CDR会被标记为"可能重复"，CGF接收到这样的CDR，会存入一个专用的队列中。只有得到CDF的再度确认，才会写入非易失性存储设备。数据记录。此机制细节可以参看3GPP TS 32.295。

发送数据记录时可以携带0条CDR。这使得在CGF重新恢复正常后，CDF可以向CGF发送Data Record Transfer消息，只携带CDR的序列号但不携带CDR，以获取这些CDR在CGF侧的状态。

#### Data Record Transfer Response

该消息携带对CDR传输和处理结果的确认。协议允许CGF在1条Data Record Transfer Response中确认多条Request消息携带的CDR以减少传输，但必须在CDF所指定的超时时长之内回复。

对每个CDR的确认都附带一个原因值。在负载过高时，CGF可以通过特定的原因值拒绝处理CDR，从而使CDF选择其他CGF来处理。

参考文献
----

1. 1 2 3 .  [2016-07-20]. （原始内容存档于2016-02-21） （英语）.
2. ↑ .  [2016-07-20]. （原始内容存档于2016-07-25） （英语）. 章节：10.1.1