fbpx
维基百科

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,所以常使用不同的发送方端口号。

参考文献 编辑

  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 

此條目需要更新, 2019年7月11日, 請更新本文以反映近況和新增内容, 完成修改後請移除本模板, prime, 是一个用于gsm和umts通信网络的基于ip网络的协议, 它可以使用udp或tcp的传输, 尽管协议的消息结构与gtp相同, 包括控制面的gtp, c和用户面的gtp, 它仍是一个独立协议, 协议使用udp, tcp端口3386, 的功能是在gsm, umts和lte核心网中将计费数据从计费数据功能, charging, data, function, 传输到计费网关功能, charging, gat. 此條目需要更新 2019年7月11日 請更新本文以反映近況和新增内容 完成修改後請移除本模板 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 目录 1 消息头结构 2 消息类型 2 1 Node Alive Request Response 2 2 Redirection Request Response 2 3 Data Record Transfer Request Response 2 3 1 Data Record Transfer Request 2 3 2 Data Record Transfer Response 3 注释 4 参考文献消息头结构 编辑GTP 消息头结构如下 Bits 0 2 3 4 5 6 7 8 15 16 31 32 470 版本号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 ResponseNode Alive Request Response 编辑 Node Alive消息对用于通知其他网元 本网元已经正常工作 Node Alive Request在网元启动完成时发送 与Echo消息对所提供的通常维60秒间隔的握手机制相比 该消息对能够及时通知对端网元继续之前中断的传输 Node Alive Request也可以用于将其他网元的状态恢复通知给对端网元 在GTP version 2中 Node Alive Request支持IPv6地址 Redirection Request Response 编辑 Redirection消息对可以用于 由CGF通知CDF 另其将CDR发送给另外的CGF 可用于CGF因维护或发生故障停止服务的场景 由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种功能 发送数据记录 Data Record 该消息可以携带0条至数条CDR CDR应以ASN 1编码 通常使用BER 英语 X 690 BER encoding 编码规则 也可以使用PER编码规则 发送 可能重复 possibly duplicated 的数据记录 该消息可以携带1条至数条已经向其他CGF发送过的CDR 取消数据记录 该消息通知一个CGF从其 可能重复 缓存中清除1条或多条CDR 释放数据记录 该消息通知一个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来处理 注释 编辑 GTP 协议的Request消息发给端口3386 也可以配置为其他端口 而发送方的端口是本地分配的 Response消息的发送 接受方端口号与Request消息的相反 1 GTP协议的Request消息同样允许本地分配发送方端口号 2 但通常会使用与接收方相同的知名端口号2123 2152 因为可以用TEID Tunnel Endpoint IDentifier 来区分不同的tunnel GTP 协议没有TEID 所以常使用不同的发送方端口号 参考文献 编辑 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 英语 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 amp oldid 68519128, 维基百科,wiki,书籍,书籍,图书馆,

文章

,阅读,下载,免费,免费下载,mp3,视频,mp4,3gp, jpg,jpeg,gif,png,图片,音乐,歌曲,电影,书籍,游戏,游戏。