从哪几方面去分析CAP消息？

　　1 引 言
　　通信网络测试仪中的信令分析，针对的是协议栈一系列的传输层和应用层协议。仪表协议分析的基础，要能够实现对所接收到的网络数据进行译码解析，并在此功能上进行更高级的统计追踪功能。在进行协议分析时，鉴于协议之间消息格式和处理机制的不同，以及软件模块化的实现要求，采取以单个协议进行模块封装的办法是更有效的，其好处在于能够忽略协议问功能和格式的细微差别，对单个协议的分析方法也能在很大程度上推广到其他协议。
　　本文研究的主要内容是CAP消息的分析，一方面描述如何根据协议标准中规定的协议消息结构进行解码，另一方面结合实际情况探讨CAP消息的统计及呼叫数据记录合成等功能。
　　2 CAP协议概述
　　智能网是通信技术和计算机技术相融合的经典范例，其基本思想是将业务控制智能从交换网络中分离出来，以No.7信令系统为桥梁，使交换网络的控制信息与大容量分布式数据库联系起来，集中控制，以方便新业务的引入和快速适应不断变化的市场需求，不必像过去那样在大范围多机种的交换机上进行繁杂的修改。
　　为了在移动通信系统中引入智能网，欧洲电信标准研究所（ETSI）于1997年在GSM Phase 2+上定义了CAM-EL（Customised Applications for Mobile network EnhancedLogic，移动网络增强逻辑的客户化应用协议）。CAMEL协议的特征是为用户提供一种网络无关的业务一致性。即使用户不在其所归属的公共陆地移动网络（HPLMN）中CAMEL协议也可以作为一种手段帮助网络运营者向用户提供特定的业务。CAP（CAMEI，Application Part）是CAMEL的应用部分，他基于智能网的INAP协议。CAP协议描述了移动智能网中各个功能实体之间的标准
　　通信规程［1，2］。
　　CAP作为应用层协议，与INAP，MAP同属于TCAP的用户，他们在七号信令系统中的位置如图1所示。
　　
　　移动智能网系统中的各个设备往往是各个不同的厂家提供的，CAP定义的精确和无二义性就变得非常重要。目前CAP的语法的定义使用ASN.1。
　　ASN.1（Abstract Syntax NotationOne）就相当于描述传送语法的一种语言，他定义的编码规则也就是从不同的协议语言到统一的传送语法之间的转换规则。因此，在具体实现时，必须在发送方设置一个ASN.1编码器，将发送方所要传送的符合发送方编程语法的消息格式转换成为符合ASN.1编码规则的格式然后再发送出去，然后在接收方设置一个ASN.1解码器，将接收到的符合ASN.1编码规则的消息格式解码为符合接收方协议语法的消息格式。这样，经ASN.1描述的信息独立于任何应用系统及传送网络，不会因为应用环境的不同而引起二义性的解释。
　　ISO在制定ASN.1的同时也推出了ASN.1的两种编码规则，一是基本编码规则（Basic Encode Rule，BER），详细内容请见X.690；另一个是数据包编码规则（Packet EncodeRule，PER），详细内容请见X.691。BER和PER实际上都是一种传送语法，他可以把复杂的用抽象语法描述的数据结构表示成简单的数据流，从而便于在通信线路上传送。PER就是在BER的基础上，以减少编码开销为目的而设计的编码规则，相对BER编码更加精简，但目前的通信协议仍以BER编码居多，CAP协议遵循BER编码规则。
　　3 CAP软件模块系统设计
　　3.1 CAP软件模块的设计要求
　　对于通信网络测试仪器的软件模块，CAP模块需要满足CAP消息的详细解码，信息提取、统计，CDR合成，过滤等功能。其设计主要考虑以下方面：
　　（1）软件的面向对象及模块化设计
　　在面向对象思想下采用模块化设计，模块内部的结构清晰易懂，各模块之间相对独立。这样便于检查错误，节省开发时间，提高了软件系统的稳定性、可修改性和重用性。
　　（2）与数据库的配合
　　通信测试系统涉及到数量相当大的数据库文件系统，信息提取，消息统计及CDR合成均需要同数据库配合，因此，在软件模块设计期间要考虑模块的数据库实现问题。
　　（3）模块的效率问题
　　为满足测试仪表长时间大负荷监控和实时解码统计等功能，模块必须提高运行效率。为了更好地提高软件的性能，在软件设计上，可以考虑采取多线程，流水线技术。
　　3.2 CAP模块的结构分析
　　系统分析在用户需求的基础上，采用面向对象的思想对CAP模块具体分析，划分系统的各个部分，明确他们之间的层次关系，然后将各个部分作为一个对象进行功能分析，对每一层次的数据进行加工处理，并向上一层提供必要的支持。根据软件总体架构方案协议消息处理流程如图2所示。
　　
　　其中，采集卡捕获到的数据首先保存在消息缓存中；解码器从消息缓存中取出消息逐条进行粗略解码，获得每帧数据的帧信息和呼叫信息；这两类信息按照协议类别交给呼叫合成器进行呼叫合成，得到每个协议的CDR集合，保存在CDR缓存中；根据用户需要进行显示和统计。统计功能可以直接面向CDR缓存进行，也可以先将CDR输入数据库，在数据库中进行统计，然后输出统计结果。对于CAP模块，我们主要实现CAP解码器和呼叫合成器的
　　设计与实现。
　　3.3 CAP软件模块研究与实现
　　3.3.1 CAP协议解码分析
　　在对CAP进行解码分析前，首先要知道BER编码的基本编码格式。BER以8 b为一个基本传送单位。对于每个所传送的值，无论是基本类型还是构造类型，都由TLV三个字段组成。TLV分别指标识类型标识符域（TAG）、数据长度域（LENGTH）和数据域（VALUE）字段。其中，数据域可以多重嵌套其他数据元素的TLV字段。BER编码的具体格式如图3所示。
　　
　　在CAP协议描述中，以localValue，length，operator-code，errorcode分别对应BER编码中的TLV，组成树状数据结构图，具体解码设计将在下面分析。
　　3.3.2 解码器实现方案
　　在通信测试仪表中主要是对协议及信令的PDU进行操作，为满足对PDU的公共操作我们制定了CPdu基类，主要实现对PDU的创建、删除、合并、内存管理、长度检查、指针操作等基本功能。在继承CPdu类的基础上，我们派生出CPduCap类，在类CPduCap中设定外部接口函数int Deeode（CString&res），完成详细解码过程，并通过引用传递的方式将解码结果置于CString类型的字符串内，便于主控方调用解码结果。返回值结果定义如下：1：非本层PDU，不操作res；0：成功解码；1：本层PDU，解码出错，错误信息加到结果字符串中。
　　由于ASN.1语法的特点，Decode（CString＆res）函数采用树状遍历嵌套调用的方式进行解码，直至解到BER的基础函数为止。
　　在基础解码函数中，我们大量使用C++标准模板库中的模板类：容器std：：vector。vector是一个多功能的，能够操作多种数据结构和算法的模板类和函数库，在ASN．1复杂数据机构的环境下，vector的使用方便了对各种数据类型进行读取、存储、转换操作。
　　详细解码的实现是对通信协议进行深层次分析，以及统计、CDR合成的基础，下面主要关注CAP CDR合成的实现。
　　3.3.3 呼叫合成器实现方案
　　呼叫合成器的主要功能就是根据到达的帧信息和呼叫信息，将帧消息按呼叫归类，即把消息ID加入到相应的CDR记录中，并在呼叫结束时通知CDR缓存。CDR（calldata record）在PSTN中表示呼叫数据记录，现在延伸意思为一个完整的流程，CDR合成是上述功能的基础，对网络中消息按信令流程进行归类，并用索引方式把这些消息联系到一起，然后才便于完成诸如呼叫跟踪和呼损统计等高级功能。CDR合成算法主要是根据一些关键参数进行查找、匹配来确定是否属于同一个消息流程，因此在这个过程中，需要一些临时存储方式来保存没有匹配到的消息，在内存分配上比较复杂，涉及动态分配内存。
　　移动智能网应用部分（CAP）是在7号信令的SCCP/TCAP之上的，即CAP为TCAP的用户（也称TC用户），直接与TCAP的成分子层相连。CAP使用TCAP所提供的TC请求原语将要发送的CAP消息传送至TCAP成分子层，然后再通过TCAP的事物处理子层、SCCP以及MTP将消息发到对端，或者使用TCAP所提供的指示原语接收对端发来的CAP消息。
　　TCAP有两个重要概念：对话和操作。在网络中一对节点之间使用TCAP进行的所有通信都被结构化为对话。例如，为处理一个智能呼叫而在SSP和SCP之间进行的所有通信可构成一个对话。在对话过程中交换的信息元素称为操作，CAP协议的消息即存放在这些信息元素中传输。操作由源TC用户调用，请求目的地TC用户执行该操作指定的动作。在这个过程中，每个成份处理TC原语均带有一个事务ID（也称对话ID），成份子层收到此原语后，就将收到的对话ID与其相同的所有成份分配给这一对话。因此，我们在CAP的CDR过程中，以Transac-tionID作为关键字CDR ID在数据结构中进行查找，匹配，确定惟一的CDR流程。TransactionID又分源事务ID和目的事务ID，分别存在于不同的TC原语中。
　　在呼叫合成实现中，最主要有两个方法：
　　（1）设定CDR缓存的方法void SetCdrBuffer（CAPCDR BUF*pBuf）：其中CAP CDR BUF是包含CCapCDR的CDR缓存模板类，此函数指定了CDR记录缓存的位置。
　　（2）CDR处理函数：void Handle（const CallInfoCap&CapInfo，const NgnPktInfo＆ PktInfo）。他是进行呼叫合成的核心，也是设计的关键。他有两个参数，分别是该协议呼叫信息和数据帧信息。其基本流程如图4所示。
　　其中，判断某CDR是否已缓存，通知CDR缓存该CDR已结束和向缓存中添加新的CDR都需要调用CDR缓存模板类的方法，对于CAP协议的CDR子类：CCapCDR，声明一个CAP CDR缓存类型方法如下：ty-pedef CCallBufCAP CDR BUF。
　　在缓存操作中的具体实现如下：
　　（1）查询某CDR是否已缓存，利用CDR缓存的Search方法：
　　newCdr.nLinkID=nLinkld：
　　//设定关联属性（根据协议类型增加）
　　_tcscpy（newCdr.Call ID，Caplnfo.Call ID）；
　　CCapCDR*pFind=m pCdrBuf=-＞Search（newCdr）;
　　//查询该CDR是否已存在
　　（2）向缓存中添加新的CDR：使用InsertNewCDR方法：
　　CCapCDR*pFind=m pCdrBuf-＞InsertNewCDR（newCdr）；
　　（3）通知缓存某CDR已结束：
　　bool bReturn=m pCdrlBuf-＞CallCompleted（*pFind）；CDR呼叫其他相关分析在此不再赘述。
　　4 软件运行实现结果
　　在模块的整个开发流程中，每一步都要进行软件的测试工作，以保证整个模块开发工作的正确性。下面是软件实测后进行CDR合成的结果，可以从图5中看到，软件实现了CAP的CDR功能，点击单条消息名称可以看到消息的关键数据，在此不再进行演示。
　　
　　
　　5 结 语
　　采用面向对象的思想，通过C++语言，我们实现了CAP软件模块。在模块开发流程结束后，通过现场测试，该软件模块完全符合中国移动《软交换测试仪表测试规范（征求稿）》中对移动智能网测试的要求，目前该软件模块已运用于商用通信测试仪表中。