CDMA20001x EVDO网络MM4+协议监测的实现

张 娇，张治中，陈 慧

(重庆邮电大学通信网与测试技术重点试验室，重庆 400065)

随着移动通信的发展，用户对通信网络的要求也越来越高。然而，由于传统价值链上的运营商对市场的业务需求缺乏一整套灵活的反应机制，使得业务开发周期长、种类不够丰富、收费模式单一，这与现代化通信需求相悖。因此，迫切需要一种新的价值链来促进电信产业的发展。这种新的业务需求被统称为增值业务［1］。增值业务的产生，使得通信网络多元化。与此同时，这也导致了网络负荷的增加。为了保证网络质量，使用户能高效、便捷地使用增值业务，需要对增值业务信令进行监测及分析。通过对增值业务信令的监测，运营商可以有效地把握用户的行为特征。本文针对增值业务中不同运营商多媒体消息互通问题，提供一个完善的、高效率的监测技术方案极。在CDMA20001x EVDO网络中，增值业务位于业务网络中，属于上层网络，通过Pi接口(PDSN与WAP网关)将业务网络与CDMA2000网络相关联［2］。MM4接口在增值业务网络中位于不同网络的MMSC(多媒体信息服务中心)之间，是运营商最为关注的网络监测接口之一，它实现了不同网络之间的信息交互，这是保证增值业务能顺利进行的前提。通过对其接口协议的解码、消息流程操作等精确、全面的监测可以帮助解决不同运营商通信交互存在的问题［3］。作为CDMA2000运营商自定义的MM4接口中的MM4+协议，通过对该协议的分析、解码、CDR(呼叫详细记录)合成、统计和存储等过程，完整地呈现了点对点多媒体消息的流程。与此同时，本文借助哈希索引提出了一种新的CDR存储方法，提高了监测效率。下面对其涉及到的原理及方法进行阐述。

1 MM4+协议及过程

作为CDMA2000运营商自定义的网关间多媒体消息业务交互协议，MM4+协议主要提供了点对点多媒体消息的前转功能。互联网关作为双方网络之间的接口网关，为双方的多媒体消息系统之间进行数据交换提供了一条安全、快捷的通道。互联网关之间采用直接连接或经过第三方网关转接，双方网络通过互联网关实现多媒体消息系统之间的互联［3］。其主要协议层次及具体消息流程如图1所示。

图1 主要协议层次

图1直观地展现了MM4+协议的承载协议层次。MM4+ 协议通过 EthernetII(Physical Layer，Link Layer)、IP、TCP协议承载。在一条MM4+消息中，协议栈解码的先后顺序依次为EthernetII层、IP层以及TCP层，最后是MM4+层。MM4+协议是SMTP协议的一个演进，其在传统的SMTP上新增了多媒体信息功能［4］。在本文中，将SMTP也视为MM4+消息，统一做监测操作。

图2呈现了MM4+协议的消息流程。MM4+协议的消息主要包括路由前转消息、路由前转递送报告消息以及路由前转阅读报告消息。每一种类型的消息都包含有请求和响应2个过程。其中，MM4+_forward.REQ为路由前转请求，MM4+_forward.RES为路由前转响应;MM4+_delivery_report.REQ为路由前转递送报告请求，MM4+_delivery_report.RES为路由前转递送报告响应;MM4+_read_reply.REQ为路由前转阅读报告请求，MM4+_read_reply.RES为路由前转阅读报告响应。其中，MM4+协议的消息格式为基于文本编码的格式，类似于SMTP［5］，如图3所示。

图2 消息流程示意图

图3 MM4+协议消息格式

如图3所示，所有被采集到的数据为二进制比特流形式。通过解码，可以将需要的数据直观地呈现出来。其中在承载协议数据里面，需要提取的数据有:以太层的grekey参数;IP层的源、目的IP地址以及TCP层中的源、目的端口号。这些参数的提取为判断是否为MM4+协议消息以及后面的合成起着至关重要的作用。

2 MM4+协议监测功能整体设计

根据相关测试规范的要求，CDMA20001x EVDO网络MM4接口的MM4+协议监测模块需要实现如下基本功能:协议数据单元的解码与分析、MM4+CDR的合成、消息分类统计以及对统计分析结果的输出等。MM4+协议监测过程中数据消息处理流程如图4所示。

图4 MM4+协议监测功能总体设计流程

首先，通过相应接口的数据采集卡将捕获到的数据保存到消息缓存中，此数据包含有MM4+的相关数据。然后将消息缓存中的数据取出来，通过解码器逐层解码(就本协议而言，即依次调用EthernetII解码器、IP解码器、TCP解码器，最后调用MM4+解码器)。MM4+协议解码主要分为合成解码和详细解码。详细解码Fdecode则是使MM4+消息内的信息单元能显示到信令工具中。在详细解码中，首先对传入数据的长度、字节大小等参数进行判断，如果满足条件，则向协议栈申请一张数据表，然后逐字节、逐比特进行解码，并将解码结果填入该数据表中，记录解码结果。最后将数据表添加到链表中，并取出上层数据单元，详细解码操作结束;合成解码parse的作用是为合成代码做提取字段的准备，通过合成解码将到达MM4+解码器的各条消息得到每条消息的呼叫相关信息，上传至协议分析器进行消息合成与统计［6］。由图2可知，MM4接口上的MM4+协议主要有3种CDR，即路由前转消息CDR、路由前转递送报告CDR以及路由前转阅读报告CDR。路由前转消息CDR主要用来记录多媒体消息前转时的类型、方向以及涉及的摘要消息;路由前转递送报告CDR主要用于记录递送报告从接收方互联网关路由前转至始发方互联网关，在MMS用户代理提取MM以后要求接收方互联网关必须给始发方互联网关返回路由前转递送报告;路由前转阅读报告CDR用于记录从接收方互联网关到发送方互联网关阅读报告的路由前转时的类型、方向及其涉及的摘要消息。首先，将底层(主要为EthernetII、IP层、TCP层以及MM4+层)解码器中合成解码提取到的合成所需字段传入合成代码，开始CDR合成。一条MM4+消息进入合成后，首先通过GREkey，源、目的端口号，源、目的IP来确定key值。再通过哈希索引，找到哈希表里生成的 CDRID，根据 CDRID判断CDRBuf是否存在;若存在，则取出CDR，并修改CDR属性;判断CDR是否结束，若结束，则合成完成;若未结束，则修改CDR状态，再将CDR存盘。若不存在，创建新的CDR，设置CDR属性值，并将新的CDR存盘，合成完成。再将得到的呼叫合成结果记录组成的CDR集合与自定义的呼叫统计结果，以文件形式保存在磁盘中。最后，根据用户的需要显示合成统计的结果。

3 哈希索引合成算法

CDR合成主要是根据一些关键参数的查找、匹配来确定是否属于同一个消息流程，通过对关键参数的判断得到传入的消息是否属于同一个CDR，然后建立关联［5］。因此在这个过程中，需要提取一些协议内和协议间进行关联的关键参数。另外，CDR合成涉及大量的查找、匹配，需要建立许多方便查找的索引，所以选取一个较好的建立索引的方法对提高CDR合成效率至关重要。本方案主要采用了Hash索引的方法。哈希算法的本质是构造一个哈希函数，而哈希函数就是关于查找元素与其对应位置的一个具体映射关系。哈希函数的设计很灵活，选取合适的关键字使得哈希函数值都落在允许的范围内即可［6］。不同关键字可能会出现落在同一范围内，这将会出现冲突。最理想的情况是建立查找函数与对应位置一一映射关系。下面针对本协议如何构建哈希函数以及如何选取key值才能使得冲突最小做相关介绍。

本设计构建哈希函数的做法是先将构成key值的关键字(源、目的IP和源、目的端口)做位或运算，然后再将结果与字段grekey相加。具体函数代码如下:

uint32 GetHashValueByMm4PlusKey(const CMM4PlusKey＆key)

{

uint32 uResult=0;

uResult=key.m_uSrcIP|key.m_uDstIP|key.m_uSrcport|key.m_uDstport;

uResult+=key.m_GREKey;

return uResult;

}

为避免冲突，本设计采取的的方法为将IP层的源、目的IP和TCP中源、目的端口以及GRE中的GREKey建立1个key类，通过将key与CDRID做关联，即CHash＜CDRID，CMM4PlusKey＞。通过对这几个字段的判断，便能正确查找到CDR的CDRID，从而找到对应CDR。

4 一种新的CDR存储方法

一个完整的CDR合成流程包括了请求和响应。CDR合成算法主要是根据一些关键参数进行查找、匹配来确定是否属于同一个消息流程，因此在这个过程中，需要一些临时存储方式来保存没有匹配到的消息，在内存分配上比较复杂，涉及动态分配内存［7］。在CDR合成结束后，所有内存会释放。但是有时候需要在CDR释放后再次查询相应的CDR(统称消息回放)用于分析用户信息以及通信网络。故保存CDR显得极为重要。

4.1 CDR合成存储原始操作

原始CDR存储的主要思想为:在合成处理消息时，当一条消息进入合成时，该条消息有一个单独的key，先通过哈希表索引出key对应的CDRID，然后通过CDRID查到对应的CDRBuf，并将该消息保存至CDRBuf中。如果后面进入一条消息为相同CDRID的消息时，即继续添加到相应索引的CDRBuf中;如果进入合成中的消息经哈希索引到一个新的CDRID时，则在CDRBuf中查找对应的CDR，并在CDRBuf中存储。具体流程图如图5所示。

图5 原始CDR存储流程图

CDRBuf存盘的优点在于在原始数据很大但服务器内存有限的情况下，起一个缓存的作用，避免了数据“拥塞”，同时为消息回放流程提供了条件。但是在CDR合成中，若需添加、修改字段时，必须先修改CDR，然后通过哈希表查到CDRBuf，修改CDRBuf内CDR的值，才能保证用户从CDRBuf中查到最准确的信息。这样做的缺点是信令处理效率低下。随着当代网络的日益强大，用户对效率的更高追求，提出了一种新的CDR存储方案。

4.2 一种新的CDR合成存储操作

为了提高效率，提出了一种新的解决方案，即舍弃CDRBuf，直接通过哈希表获取CDR，然后通过一个写文件操作进行存盘，这样使处理速度变快，为与日俱增的现网数据处理提供极大的好处。流程图如图6所示。

图6 新的CDR存储流程图

本设计不再使用CDRBuf，而是通过key值索引，直接将CDR存入哈希表中。在1个CDR合成操作完成后，直接通过写文件操作将CDR写入MR文件中。这样做的好处是:在查找、修改流程的具体内容时，不再需要修改完CDR后，还需通过CDRID关联查找到CDRBuf再做修改，然后才能完成的状态。这样使得实时数据的处理速度得到了很大提高，这也与新网络时代对通信效率的高要求相吻合。

4.3 新旧CDR合成存储的比较

在原始的CDR合成存储中，通过CDRBuf存储CDR。其作用在于在硬盘文件存取慢的情况下，起一个缓存的作用，这样做的好处是避免了数据“拥塞”。CDRBuf为消息回放流程提供了条件。但是，在CDR合成中，因为用户是从CDRBuf文件中查询消息流程，所以在合成操作中，若需要修改、添加CDR，必须从CDRBuf中取出对应的CDR，对它进行相应的操作，操作完成后，还需要再将修改后的CDR放回CDRBuf中。很明显，这样的操作使得监测效率变低，与当代高效率需求相悖。新的CDR存储舍弃了CDRBuf，直接通过哈希表获取CDR，然后通过一个写文件操作进行存盘，这样做的好处是:在添加、修改流程的具体内容时，不用再从CDRBuf文件中取和存CDR，而是直接在哈希表里面做相应操作后再统一存盘，这样使监测效率提高，为与日俱增的现网数据处理提供极大的便捷。这也与新网络时代对通信效率的高要求相吻合。

5 实测数据及结果分析

图7为一个正常消息流程的监测结果图。其右侧位置为详细解码结果。详细解码能将MM4+协议栈中的各层不同协议的具体字段及对应值清晰地呈现给用户以及运营商，让其对MM4+协议栈结构及信息单元有了更加深入的了解，为点对点多媒体消息业务监测技术的发展提供了基础。MM4+协议合成模块监测结果及流程图如图7原始数据上面部分所示。以路由前转消息为例(另外2种消息类似)，此为1个完整的路由前转消息CDR，其中，10.137.17.55和10.137.19.130分别代表2个互联网关地址，本条CDR一共包含2条消息。第1条为前转请求消息;第2条为前转响应消息。第2条消息表明针对IWGW1向IWGW2的前转请求，IWGW2给予了1个回复，即不同运营商间的多媒体消息发送成功。

图7 实测数据结果显示(截图)

6 小结

通过对CDMA2000网络MM4+协议模块的监测研究，结合协议内和协议间的关联，利用高效的哈希索引算法以及一种新的CDR存储方案，极大提高了协议关联以及CDR合成及统计效率。本设计已应用到“重邮汇测CDMA2000网络增值业务监测系统”中，并通过了现网数据的测试，验证了本设计理论的有效性和可靠性。

［1］陶蒙华.电信增值业务平台的体系架构极其发展趋势［J］.移动通信，2005(6):40－43.

［2］QB－W－XXX－2011，中国电信业务网络设备技术规范——移动增值业务信令监测(全国)技术规范［S］，2011.

［3］Q/CT 2052—2008，中国电信CDMA业务网络接口协议技术规范M1/M4/M7接口协议规范［S］.2009.

［4］IETF STD 0010(RFC 2821):“简单邮件传输协议”(Simple Mail Transfer Protocol)［EB/OL］.［2013－02－10］.http://www.ietf.org/rfc/rfc2821.txt.

［5］IETF RFC 2046:“多用途因特网邮件扩展(MIME)第2部分:媒体类型”(Multipurpose Internet Mail extension(MIME)Part Two:Media Types)［EB/OL］.［2013－02 －10］.http//www.ietf.org/rfc/rfc2046.txt.

［6］宋光秀，张治中，王玮，等.TD－SCDMA网络Iub接口RRC协议监测研究与实现［J］. 电视技术，2010，34(11):124.

［7］夏鞑，雒江涛，张治中.TD－SCDMA测试仪中Iub接口CDR的合成方案［J］.重庆邮电大学学报:自然科学版，2007，19(1):35－38.