维基百科

GTP'

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

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

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

GTP'重用了GTP协议的诸多方面，然而在3GPP TS 32.295中却描述为“仅仅部分重用了GTP协议的控制面”[1]。GTP'定义了与GTP不同的消息头结构、独有的消息类型、信元，以及一整套防止计费数据丢失或重复计算的机制。GTP'协议所传输的计费数据记录（英语：Charging_data_record）（英语：CDR，Charging Data Record）以ASN.1协议编码[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. 发送数据记录（Data Record）：该消息可以携带0条至数条CDR。CDR应以ASN.1编码，通常使用BER（英语：X.690#BER_encoding）编码规则，也可以使用PER编码规则。
  2. 发送“可能重复”（possibly duplicated）的数据记录：该消息可以携带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. ^ GTP'协议的Request消息发给端口3386（也可以配置为其他端口），而发送方的端口是本地分配的；Response消息的发送、接受方端口号与Request消息的相反。[1]GTP协议的Request消息同样允许本地分配发送方端口号，[2]但通常会使用与接收方相同的知名端口号2123/2152，因为可以用TEID（Tunnel Endpoint IDentifier）来区分不同的tunnel。GTP'协议没有TEID，所以常使用不同的发送方端口号。

参考文献

编辑
  1. ^ 1.0 1.1 1.2 3GPP TS 32.295 v12.2.0 Telecommunication management; Charging management; Charging Data Record (CDR) transfer. [2016-07-20]. （原始内容存档于2016-02-21） （英语）. 
  2. ^ 3GPP TS 29.060 Technical Specification Group Core Network and Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface. [2016-07-20]. （原始内容存档于2016-07-25） （英语）. 章节：10.1.1 
检索自“https://zh.wikipedia.org/w/index.php?title=GTP%27&oldid=68519128”