跳转到内容

GTP'

本页使用了标题或全文手工转换
维基百科,自由的百科全书

GTP'(GTP prime)是一个用于GSMUMTS通信网络的基于IP网络的协议。它可以使用UDPTCP的传输。尽管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,所以常使用不同的发送方端口号。

参考文献