Gn接口彩信监测技术研究

爱卫生

本文摘自2010年亚太地区信息论学术会议。会议地点：中国西安【作者】 胡锡哲； 雒江涛； 宋光秀；【机构】 重庆邮电大学通信网与测试技术重点试验室；

【摘要】 本文首先介绍了WAP2.0协议栈,然后对其承载的彩信业务流程进行了分析,最后在此基础上研究并提出了一种有效监测彩信业务的方案,该方案主要利用哈希表、面向对象等技术手段,包含协议解码、协议关联及呼叫合成等步骤。现网测试表明此方案效果良好。

【关键词】 彩信业务； 协议解码； 协议关联； 呼叫合成；

1引言

MMS是Multimedia Messaging Service的简称，MMS的标准由OMA(Open Mobile Alliance，开放式移动联盟）

和3GPP(3rd Generation Partnership Project，第三代合作伙伴计划）所制订，中文为彩信业务。

随着MMS的不断扩展，利用MMS传送垃圾彩信、色情彩信、病毒彩信等违法和不良信息的现象也随之出现并呈蔓延趋势，要遏制这些不良现象的发展，需要从MMS监测技术入手，根据现网信令进行统计发现，现网WAP1.x和WAP2.0两种版本比例大约为1:3。

本文作者就以上问题，研究了一种WAP2.0承载的MMS监测方案。该方案从协议栈的解码入手，从原始数据中提取关键字段，结合协议标准，利用Hash算法、面向对象技术等实现CDR(Calling Detail Record，呼叫详单）合成，并最终统计相关数据。

2 WAP2.0协议栈

WAP不是一个单纯协议，而是一个协议族，它被广泛用于多种网络体系的分组业务承载。相对于WAP1.x版本，WAP2.0除了增加了对多媒体业务等上层应用的技术要求外，为了适应无线环境的变化和市场需求，还引进了对TCP/IP协议族的支持。

WAP2.0版本采用分层设计，每层都为上层提供一个接入点，并且还可以接入其他服务和应用程序，其具体层次结构如图1所示。在WAP2.0协议栈中，MMS通过HTTP承载。

3 MMS流程

彩信和其它WAP应用的架构类似，都要经过WAP Gateway中转。彩信不直接投递给接收方，而是先发送给一个中间服务器MMS Proxy-Relay。MMS Proxy-Relay暂时保存彩信，然后通过PUSH协议给彩信接收方发送一个通知，彩信接收方收到通知后从MMS Proxy-Relay上获取彩信内容。图2包含彩信回执的彩信完整收发流程。

4 MMS业务监测的实现

4.1 MMS数据采集

Gn接口是SGSN和GGSN之间的接口，在现网测试采集数据过程中，为了不影响网络通信，局方一般采用交换机做镜像端口的办法，采集机连接交换机的镜像端口采集数据，如图3所示：

原始数据由采集机配置的采集卡采集所得，然后交由后台处理设备，对消息先进行缓存排队处理，最后被解码模块调用解析。

4.2 MMS协议栈解码

对Gn接口采集到的WAP2.0承载的MMS消息，必须逐层的判断上层协议类型，当判断到HTTP协议时，如果HTTP的净荷中Content-Type字段为application/vnd.wap.mms-message，那么可以判定此HTTP包承载的是MMS，如果Content-Length字段值同时不等于0，需要取出HTTPSDU(即MMSPDU)进行解码。特殊情况，M-Send.req和M-Retrieve.conf消息由于携带有彩信信息，可能在多个HTTP报文中分片发送，所以需要进行分片重组才能正确解码MMSPDU。如图4所示，第一步判定HTTP承载的是MMS，第二步取出HTTPSDU,第三步重组MMSPDUoMMS头域信息一定存在于第一个分片包中，只有MMS消息体部分可能存在分片现象。

得到完整的MMSPDU后，则利用C语言的指针的灵活性，按照协议规范偏移比特位，将二进制数据解析为协议规范对应的有用信息，并在解码结果结构体中保存需要的字段值，同时记录已偏移比特和剩余长度，直至剩余长度为0，解码结束。根据标准规范[3]中对MMSPDU的头域格式及编码规则的定义，在头域中的必选字段有X-Mms-Message-Type、X-Mms-Transaction-ID、X-Mms-MMS-Version，其他诸如Data、To等字段则为可选或者多选一。而对于头域的值编码，由于每个字段都有标识指示，所以编码不必全局唯一。MMS消息体主要是通过SMIL(SynchronizedMultimediaIntegrationLanguage，同步多媒体集成语言）语言把不同性质的内容组合在一起。

如有原始十六进制数据“8C849869765030303079456D463130008090.”，根据头域格式可知0x8C代表X-Mms-Message-Type，接下来的一个字节0x84是它的值，代表消息类型M-Retrieve.conf,0x98代表X-Mms-Transaction-ID，后续数据是它的值，直到0x80标识了X-Mms-MMS-Version。MMSPDU的解码可以按照先解必选字段、后解自定义域，最后解消息体的顺序依编码规则逐步解码。

4.3MMS CDR合成

CDR合成也叫消息流程合成，它是完成更直观分析的基础，可以把它的理解为：对网络中消息按信令流程进行归类，并用索引方式把这些消息联系到一起，重现一次完整的呼叫过程，然后才便于完成诸如呼叫跟踪和呼损统计等高级功能。

在MMS CDR合成功能的实现过程中，采用了Hash(哈希）算法通过消息中的Key查找合成中的CDR，从而判断该条消息属于哪一次呼叫。考虑到CDR的庞大数量，为了避免内存的过度消耗，采用文件的方式组织所有合成中和合成完的CDR，把所有的CDR都顺序存储在文件当中，并建立索引文件，以便能够通过索引迅速搜索到相应的CDR。

因为要进行WAP2.0承载的MMS业务，必须先在移动终端和彩信服务器间建立TCP连接，所以同一次MMS业务的所有消息一定在同一条TCP连接中，因此可以利用源目的IP地址及源目的TCP端口号构成的四元组作为MMS Hash表的Key值。又因为同一次呼叫的请求响应方向相反，所以必须做操作符重载，将源目的IP地址及源目的TCP端口号与索引值刚好两两相反的消息也纳入同一条CDR。

boolCMMSKey:perator==(constCMMSKey&Key)
{
return(m_uDstIP==Key.m_uDstIP&&m_uSrcIP==Key.m_uSrcIP&&m_uDstPort==Key.m_uDstPort&&m_uSrcPort==Key.m_uSrcPort)
||(m_uDstIP==Key.m_uSrcIP&&m_uSrcIP==Key.m_uDstIP&&m_uDstPort==Key.m_uSrcPort&&m_uSrcPort==Key.m_uDstPort);
}

MMS的CDR合成步骤为：

合成解码模块的解码结果送入CDR合成模块，提取Callinfo信息，以IP中的源IP和目的IP、TCP中的源端口和目的端口做Key值，在MMSCDR合成Hash表中检索。

如果该条消息的Key在Hash表中未找到匹配项，并且消息类型是M-Send.req，则在表中新建CDR；如果该条消息的Key在Hash表中未找到匹配项，但不是M-Send.req消息类型，则认为该消息对应的呼叫不完全，没有统计意义，故舍去；如果找到了匹配项，则返回值就是该CDR的CDRID和存储位置的类指针，于是可以将该消息提取的字段继续填充到CDR中，以完善该CDR。

在MMSCDR合成中，MO(主叫）过程就是彩信发送方把彩信发送给MMSProxy-Relay的过程，MMSProxy-Relay在收到彩信后会给发送方一个确认消息，所以以M-Send.req作为起始消息，以M-Send.conf作为结束消息。MT(被叫）过程是一个标准的WAPGET过程，所以以HttpGet作为起始消息，以M-Retrieve.conf作为结束消息（实际上接收方可能还会返回一条M-Acknowlegde.ind)。

在M-Send.req消息中，可以从协议栈的解码结果中提取出SGSN、GGSN、发送或接收时间、CDR类型、主叫号码、被叫号码、PDP地址、WAP版本号等信息，其中PDP地址可以用于MO过程中没有主叫号码信息时，与GTP协议关联，确定主叫号码。

在M-Send.conf和M-Retrieve.conf消息中，可以确定失败原因、业务时延、主被叫标识，并且可以据此填写成功失败标识。

由于在现网通信中，有些彩信过程是失败的，如果仅考虑正常的规范的彩信流程，会导致这些失败的CDR—直得不到关闭，从而逐步耗尽系统资源，导致软件崩溃，为了关闭这些失败的CDR，不但需要在代码中增强容错能力，还要运用超时机制，本方案的超时原理为从新建CDR起，超过一定时间后，CDR没有正常关闭，则判定CDR失败，同时关闭该CDR。

5实测数据及结果验证

通过用Gn接口的数据在平台上进行测试，本MMS协议监测方案能有效解析数据、合成CDR。图5实测结果图。图中中间绿色部分是CDR记录，每行为一条CDR记录，每列为其CDR属性字段，提取的属性可依据具体的统计指标需求配置；中间的流程图对应了该条CDR的信令流程，80和1037分别是源目的端口号，最后一条消息中的200是HTTP的正确响应码；右侧树形目录是对报文的详细解码，逐层、逐字段解析了报文；底部蓝色区域是报文的原始数据，红色突出显示的是在详细解码栏中被选取部分的原始数据。

6结束语

本方案可以有效解析并合成在现网中WAP2.0协议栈承载的MMS消息。通过采取Hash技术，实现了MMS过程的合成和各种指标的统计，全面有效的实现了对网络中MMS业务的监测。通过对各子模块进行的单元测试和软件集成后的现场测试，充分证明了该监测设计方案的可行性和有效性，各项指标均符合协议监测的各项规范。为进一步的用户行为分析提供了技术支持。

致谢

感谢舒忠玲、袁亮等人搭建了实验平台，并悉心指导模块的测试用例。

References(参考文献）

[1]ChinaMobile Communications Corporation.GPRS End-To-End Optimization of Project Data Business Group Summary Report[R].2008(Ch).
中国移动通信集团.GPRS端到端优化项目数据业务组总结报告[R].2008.

[2] DiboLv,QiongWang.Key Techniques Research for Transmitting MMS[J].Electronic Test.2008(3)(Ch).
吕迪波，王琼.MMS发送关键技术研究[J].电子测试.2008(3).

[3] OMA-MMS-ENC-V1_2-20050301-A.Multimedia Messaging Service Encapsulation Protocol Approved Version1.2-01[S].Mar2005.

[4] OMA-MMS-CONF-V1_20050301-A. MMS Conformance Document Approved Version1.2-01[S].Mar2005.

[5] ZhangQiang,ZhouWei..Research and Implementation of the SM Protocol in GPRS Network Monitor[J].Electronic Test.2009(8)(Ch).张强，周讳.SM协议在GPRS网络监测中的研究与实现[J].电子测试.2009(8).

[6] WangJilong.Research and Development of Gi Interface Monitoring Technology for GPRS[D].Chongqing University of posts and telecommunications.2009(Ch).王吉龙.GPRS网络Gi接口监测技术的研究与开发[D].重庆邮电大学.2009

花亊未了

文章很不错嘛，重邮不错