51学通信技术论坛

 找回密码
 立即注册
搜索
查看: 7612|回复: 10
打印 上一主题 下一主题

Gn口协议及其各协议的字段内容分别是哪些? [复制链接]

Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7

版主

跳转到指定楼层
楼主
发表于 2012-10-27 22:09:47 |只看该作者 |倒序浏览
一键分享 一键分享
想问下,Gn口是承载着各种协议的吧?从GGSN和SGSN之间采集这些数据的时候,这些协议之间各个字段分别是什么呢?还是说不同的设备生产商拥有不同的字段名称?
以后要多来论坛学习学习~~ <img src="static/image/smiley/comcom/1.gif" c ...

Rank: 9Rank: 9

懒

沙发
发表于 2012-10-27 22:41:52 |只看该作者

是这样的。Gn接口目前采用的协议是GTPV1版本,所用到的所有消息均在TS29.060中的第7章(GTP Messages and Message Formats)中有详细说明。不是各厂家随便定的。是有统一的规范的。

以下列出Gn接口中所有的消息名称。如下所示:

(最常用的包括Create PDP Context Request/Response、Delete PDP Context Request/Response、Modify PDP Context Request/Response、SGSN Context Request/Response消息等等)。

7 GTP Messages and Message Formats 19
7.1 Message Formats 19
7.1.1 Presence requirements of Information Elements 21
7.2 Path Management Messages 21
7.2.1 Echo Request 21
7.2.2 Echo Response 22
7.2.3 Version Not Supported 22
7.2.4 Supported Extension Headers Notification 22
7.3 Tunnel Management Messages 23
7.3.1 Create PDP Context Request 23
7.3.2 Create PDP Context Response 26
7.3.3 Update PDP Context Request 30
7.3.4 Update PDP Context Response 34
7.3.5 Delete PDP Context Request 38
7.3.6 Delete PDP Context Response 39
7.3.7 Error Indication 40
7.3.8 PDU Notification Request 40
7.3.9 PDU Notification Response 41
7.3.10 PDU Notification Reject Request 42
7.3.11 PDU Notification Reject Response 42
7.3.12 Initiate PDP Context Activation Request 43
7.3.13 Initiate PDP Context Activation Response 44
7.4 Location Management Messages 45
7.4.1 Send Routeing Information for GPRS Request 45
7.4.2 Send Routeing Information for GPRS Response 45
7.4.3 Failure Report Request 46
7.4.4 Failure Report Response 46
7.4.5 Note MS GPRS Present Request 47
7.4.6 Note MS GPRS Present Response 47
7.5 Mobility Management Messages 48
7.5.0 General 48
7.5.1 Identification Request 48
7.5.2 Identification Response 49
7.5.3 SGSN Context Request 49
7.5.4 SGSN Context Response 51
7.5.5 SGSN Context Acknowledge 53
7.5.6 Forward Relocation Request 54
7.5.7 Forward Relocation Response 57
7.5.8 Forward Relocation Complete 59
7.5.9 Relocation Cancel Request 59
7.5.10 Relocation Cancel Response 59
7.5.11 Forward Relocation Complete Acknowledge 59
7.5.12 Forward SRNS Context Acknowledge 60
7.5.13 Forward SRNS Context 60
7.5.14 RAN Information Management Messages 61
7.5.14.1 RAN Information Relay 61
7.5A  MBMS Messages 61
7.5A.1 UE Specific MBMS Messages 61
7.5A.1.1 MBMS Notification Request 61
7.5A.1.2 MBMS Notification Response 62
7.5A.1.3 MBMS Notification Reject Request 63
7.5A.1.4 MBMS Notification Reject Response 64
7.5A.1.5 Create MBMS Context Request 64
7.5A.1.6 Create MBMS Context Response 66
7.5A.1.7 Update MBMS Context Request 68
7.5A.1.8 Update MBMS Context Response 69
7.5A.1.9 Delete MBMS Context Request 71
7.5A.1.10 Delete MBMS Context Response 72
7.5A.2 Service Specific MBMS Messages 72
7.5A.2.1 MBMS Registration Request 73
7.5A.2.2 MBMS Registration Response 73
7.5A.2.3 MBMS De-registration Request 75
7.5A.2.4 MBMS De-Registration Response 75
7.5A.2.5 MBMS Session Start Request 76
7.5A.2.6 MBMS Session Start Response 77
7.5A.2.7 MBMS Session Stop Request 79
7.5A.2.8 MBMS Session Stop Response 79
7.5A.2.9 MBMS Session Update Request 80
7.5A.2.10 MBMS Session Update Response 81

再以Create PDP Context Response消息为例,消息中的内容也是定义好的。如下:

Table 6: Information Elements in a Create PDP Context Response

Information element

Presence requirement

Reference

Cause

Mandatory

7.7.1

Reordering required

Conditional

7.7.6

Recovery

Optional

7.7.11

Tunnel Endpoint Identifier Data I

Conditional

7.7.13

Tunnel Endpoint Identifier Control Plane

Conditional

7.7.14

NSAPI

Optional

7.7.17

Charging ID

Conditional

7.7.26

End User Address

Conditional

7.7.27

Protocol Configuration Options

Optional

7.7.31

GGSN Address for Control Plane

Conditional

GSN Address 7.7.32

GGSN Address for user traffic

Conditional

GSN Address 7.7.32

Alternative GGSN Address for Control Plane

Conditional

GSN Address 7.7.32

Alternative GGSN Address for user traffic

Conditional

GSN Address 7.7.32

Quality of Service Profile

Conditional

7.7.34

Charging Gateway Address

Optional

7.7.44

Alternative Charging Gateway Address

Optional

7.7.44

Common Flags

Optional

7.7.48

APN Restriction

Optional

7.7.49

MS Info Change Reporting Action

Optional

7.7.80

Bearer Control Mode

Optional

7.7.83

Evolved Allocation/Retention Priority I

Optional

7.7.91

APN-AMBR

Optional

7.7.98

GGSN Back-Off Time

Optional

7.7.102

Private Extension

Optional

7.7.46


www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7

版主

板凳
发表于 2012-10-27 23:17:09 |只看该作者
爱卫生 发表于 2012-10-27 22:41
是这样的。Gn接口目前采用的协议是GTPV1版本,所用到的所有消息均在TS29.060中的第7章(GTP Messages and M ...

恩,我现在主要开始接触信令监测方面的工作。情况是这样的,我们从中兴的采集设备上采集信令话单--即原始信令话单,其中包含很多的字段,然后我们通过采集设备将这些话单进行数据处理,分析,最终能够知道某些终端、业务比较受欢迎等等事项,那么我们想要知道所有的从中兴设备上出来的字段,是不是和GTPv1.0有些不一样呢?如下为中兴提供的字段
      <attr type="11" pos="0" len="8" flag="0">btime</attr>
      <attr type="11" pos="10" len="8" flag="0">rsptime</attr>
      <attr type="11" pos="20" len="8" flag="0">endtime</attr>
      <attr type="12" pos="30" len="4" flag="0">oip</attr>
      <attr type="12" pos="40" len="4" flag="0">dip</attr>
      <attr type="12" pos="50" len="4" flag="0">userip</attr>
      <attr type="12" pos="60" len="4" flag="0">desip</attr>
      <attr type="6" pos="70" len="4" flag="0">eventtype</attr>
      <attr type="6" pos="80" len="4" flag="0">cause</attr>
      <attr type="6" pos="90" len="4" flag="0">contentlength</attr>
      <attr type="6" pos="100" len="4" flag="0">recvpacket</attr>
      <attr type="6" pos="110" len="4" flag="0">sendpacket</attr>
      <attr type="6" pos="120" len="4" flag="0">recvoct</attr>
      <attr type="6" pos="130" len="4" flag="0">sendoct</attr>
      <attr type="4" pos="140" len="2" flag="0">oport</attr>
      <attr type="4" pos="150" len="2" flag="0">dstport</attr>
      <attr type="4" pos="160" len="2" flag="0">wlac</attr>
      <attr type="4" pos="170" len="2" flag="0">wrac</attr>
      <attr type="6" pos="180" len="4" flag="0">cell</attr>
      <attr type="4" pos="190" len="2" flag="0">wfrontid</attr>
      <attr type="2" pos="200" len="1" flag="0">protocoltype</attr>
      <attr type="2" pos="210" len="1" flag="0">interfacetype</attr>
      <attr type="2" pos="220" len="1" flag="0">ucrattype</attr>
      <attr type="2" pos="230" len="1" flag="0">waptype</attr>
      <attr type="2" pos="240" len="1" flag="0">tdrtype</attr>
      <attr type="0" pos="250" len="16" flag="0">imsi</attr>
      <attr type="0" pos="260" len="26" flag="0">imei</attr>
      <attr type="0" pos="270" len="63" flag="0">uchapn</attr>
      <attr type="0" pos="280" len="26" flag="0">msisdn</attr>
      <attr type="0" pos="290" len="32" flag="0">useragent</attr>
      <attr type="0" pos="300" len="64" flag="0">url</attr>
      <attr type="0" pos="310" len="50" flag="0">host</attr>
      <attr type="0" pos="320" len="26" flag="0">callingnum</attr>
      <attr type="2" pos="330" len="1" flag="0">ucostype</attr>
      <attr type="2" pos="340" len="1" flag="0">ucbrowsertype</attr>
      <attr type="6" pos="350" len="4" flag="0">uireqnum</attr>
      <attr type="6" pos="360" len="4" flag="0">uiupdelay</attr>
      <attr type="6" pos="370" len="4" flag="0">uidowndelay</attr>
      <attr type="6" pos="380" len="4" flag="0">uiuplossnum</attr>
      <attr type="6" pos="390" len="4" flag="0">uidownlossnum</attr>
      <attr type="6" pos="400" len="4" flag="0">uiuppayload</attr>
      <attr type="6" pos="410" len="4" flag="0">uidownpayload</attr>
      <attr type="6" pos="420" len="4" flag="0">uiservicetype</attr>
      <attr type="9" pos="430" len="8" flag="0">ullprocessid</attr>
以后要多来论坛学习学习~~ <img src="static/image/smiley/comcom/1.gif" c ...

使用道具 举报

Rank: 9Rank: 9

懒

地板
发表于 2012-10-27 23:51:18 |只看该作者
tonyhe 发表于 2012-10-27 23:17
恩,我现在主要开始接触信令监测方面的工作。情况是这样的,我们从中兴的采集设备上采集信令话单--即原始 ...

了解。

只能说部分是,例如IMSI、IMEI。但这并不是说中兴不合规范。因为信令话单不光是采集GTP层的数据。还有IP层、传输层的数据以及字节数统计等等。有些字段可能经过中兴自己的命名重新定义过了。例如后面有很多uid开头的字段,这些规范里没有直接说明,具体应该找中兴了解这些字段的内容是什么。例如uchapn不是标准规范中定义的名称,但也可能是中兴自己重新命了个名字,就是代表用户请求的APN(只是打个比方哈)。

www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7

版主

5#
发表于 2012-10-28 07:58:27 |只看该作者
爱卫生 发表于 2012-10-27 23:51
了解。 只能说部分是,例如IMSI、IMEI。但这并不是说中兴不合规范。因为信令话单不光是采集GTP层的数据。 ...

那我就有点不太明白了,Gn口不是采用的GTPv1的标准么?而信令话单却又是不单采集GTP层,还采集IP层,传输层等数据,那么说Gn口同时可以采集这么多数据么?这个不是和Gn口是
GTPv1标准冲突了么?还是说信令话单将多个不同层次的协议上的数据采集过来,然后在设备比如中兴或者华为的上进行一定的整合才形成的?如果是这样的话,那IP层等数据又是从哪个口上出来的?

以后要多来论坛学习学习~~ <img src="static/image/smiley/comcom/1.gif" c ...

使用道具 举报

Rank: 9Rank: 9

懒

6#
发表于 2012-10-28 11:10:07 |只看该作者

没有冲突啊。Gn接口是一个逻辑接口,是有自己的协议栈的。GTP只是Gn接口的应用层协议。它仍然需要底层的IP层的承载。具体的协议栈是:

GTP-C:

GTP-C

UDP

IP

Eth

Physical

GTP-U:

用户Payload

GTP-U

UDP

IP

Eth

Physical

所以,采集的不光是最上层GTP协议本身的信息。还有下面的IP层信息等,可用于流量统计。另外,设备收到报文和发送的时间也是可以统计出来的。

www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7

版主

7#
发表于 2012-10-28 23:34:59 |只看该作者
那就是说从中兴设备上出来的原始信令话单中就已经包含了经过处理的各字段,其中已经含有了IP层,GTP层,UDP层,以太网层和物理层的吧?

使用道具 举报

Rank: 8

VIP 论坛核心会员 特殊贡献奖

8#
发表于 2012-10-29 13:42:02 |只看该作者
我们从中兴的采集设备上采集信令话单--即原始信令话单

楼主还是去找管中兴采集设备的人吧。别纠结GTP的事了。楼主设备的采集点和楼主发出来的信息表明,楼主要采集的东西压根就不是标准Gn接口GTP数据包。

楼主所谓的“原始信令话单”只是针对你们自己系统而言。
对于通用的GPRS技术/网络而言,压根就没有原始信令话单这种说法。
信令就是信令,各个接口有各个接口的编码规范,各厂商都要遵循;
话单就是话单,原始话单也都是遵循基本固定的编码方式(ASN.1),厂商之间的差别最大也就是传输方式不同而已(FTP,GTP')。

使用道具 举报

Rank: 3Rank: 3Rank: 3

9#
发表于 2012-10-31 14:30:20 |只看该作者
学习了。原始信令话单这个是在运营商经常说

使用道具 举报

Rank: 1

10#
发表于 2013-2-17 13:55:50 |只看该作者
这个是ZXT2000的东西,类似于功能更为强大的信令分析仪。

楼主还是找中兴的支持工程师看看,或者打中兴800咨询。

使用道具 举报

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

11#
发表于 2013-12-27 09:20:53 |只看该作者
这种情况的确应该找提供话单的厂家来解释,而不是自己费力气去研究GTP或者信令

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

站长邮箱|Archiver|51学通信 ( 粤ICP备11025688 )

GMT+8, 2024-11-1 08:30 , Processed in 0.024290 second(s), 13 queries .

Powered by Discuz! X2

© 2001-2011 Comsenz Inc.

回顶部