基于SDTP的全量信令接收方案的研究*

胡汝荣，雒江涛，罗 鹏

（重庆邮电大学通信网测试技术工程研究中心 重庆 400065）

1 引言

信令监测系统是保障移动通信网络高质量运行、快速响应用户投诉、提升用户感知的重要技术手段[1]。目前电信运营商均建立了较为完备的信令监测系统[2～4]，但这些监测系统都存在各层之间厂商私有化程度较高、模块间采用私有化传输协议、架构封闭接口不开放等限制数据和资源共享的问题。随着电信业务的迅速发展，对信令监测系统提出了更高的要求，信令监测系统正向着规范化、信息共享和基于云计算的方向发展[5～7]。

目前对信令监测系统的研究重点多在于信令的采集、信令的分析处理和结果的统计分析等方面[2～4]，对信令监测系统分层间接口的研究较少，参考文献[1]提出了一种向规范化演进的信令监测系统架构，没有具体提出分层接口的设计与实现方案。

本文基于 SDTP（shared data transport protocol）[8]提出一种适用于规范化的信令监测系统的全量信令接收方案。该方案设计了SDTP通信、排序和分流功能，满足了采集接口和信令共享平台间接口的功能需求，促进了信令监测系统规范化的演进。

2 信令监测系统及接口

2.1 系统架构

信令监测系统的总体架构如图1所示。信令监测系统从结构上可划分为采集层、共享层和应用层，每部分的功能概述如下。

图1 信令监测系统架构

·信令采集层：负责通信网中不同类型链路承载的全量信令数据，并将采集到的信令数据通过汇聚后传输到共享层。

·共享层：负责从底层接收全量信令数据、存储、解析并向应用层提供CDR数据，需要完成和采集层与应用层的交互。

·应用层：主要利用共享层解析后的信令数据进行

统计分析，从而实现业务应用（小区短信、手机报等）和信令监测系统应用（流量分析、用户行为分析等）。

2.2 IF1接口

IF1接口是采集层和共享层之间交互的接口，也是采集层的汇聚设备和共享层接入模块间的接口[8]，主要功能是进行全量信令数据的传输。该接口的数据传输具有如下特点：实时性高、数据量大、过程简单。

在工程应用中，常选择的文件传输协议是FTP（file transfer protocol），本文选择SDTP作为全量信令数据传输协议。SDTP是由中国移动提出的一种实时信令共享协议，FTP和SDTP的对比见表1。

表1 FTP和SDTP的对比

FTP和SDTP都采用客户端和服务端模式工作，且都可以实现客户端主动上传文件到服务端，都采用Socket方式进行通信。FTP是把本地端已经保存好的文件传送到服务端，如果采用FTP，则需要在采集层的汇聚设备中增加数据存储设备，而且数据存储需要一定的时间，不能达到采集数据实时发送的目的，并且SDTP过程更加简单。

SDTP消息结构及流程参见参考文献[8]，在此不赘述。

3 接收方案设计

全量信令接收方案如图2所示。该方案将整个接收分为协议通信模块、排序模块和分流模块，可以使功能独立化，便于维护。协议通信模块是SDTP服务端的实现，完成与SDTP客户端的交互；排序模块从协议通信模块中获取全量信令消息，进行数据分组排序；分流模块按某种维度完成全量信令数据的多路存储。

3.1 协议通信模块

根据SDTP的功能需求，接收模块主要完成采集层汇聚设备中SDTP客户端的连接请求、认证、连接状态检查、全量信令数据的接收。本文采用面向对象的方式，将不同的功能封装成一个类，向外部提供调用接口。各个类介绍如下。

图2 信令接收方案设计

·CSDTP server类：SDTP服务端类，主要接口有开始监听StartListen()、停止监听StopListen()、断开所有客户端的连接DisconnectAllClient()等。

·CSDTP agent类：客户端代理类，功能是和客户端进行交互，主要接口有同步发送消息SendMsgSyn()、异步发送消息SendMsgAsyn()、断开与客户端的连接DisConnect()等。

·CSDTP agent Rcvtask类：接收线程类，功能是接收客户端发送的消息和数据，主要接口有接收RecvFromPeer()、判断接收线程是否在运行IsRunning()等。

·CSDTP agent send task类：功能是客户端发送响应消息，主要接口有同步发送消息SendDataSyn()、异步发送消息SendDataAsyn()、发送消息线程是否在运行IsRunning()等。

·CSDTP listener类：监听类，功能是监听客户端的连接，主要接口有开始监听Start()和结束监听Stop()等。该类负责监听客户端的连接，如果发现有客户端申请连接，则启动认证，若认证成功，则会实例化一个代理类负责与该客户端交互。

由于实际的客户端会有多个，并且全量信令数据量较大，本文采取多线程的工作方式，以提高工作效率，包括服务端主线程、监听线程和多对发送线程、接收线程（一个代理端对应一个发送线程和接收线程）。接收模块伪代码如下：

3.2 排序模块

由于采集层很难实现精确的时间同步，所以接收到的全量信令数据分组可能存在乱序问题。数据排序模块是将数据分组按数据分组头中的时间戳重新进行排序。本模块结合散列索引技术，提出了一种高效、快速的数据排序方法。数据排序有以下几个关键技术。

（1）数据缓存组织结构

用链表结构管理每条数据排序时在内存中的存储，数据在链表中以数据分组中的时间按从小到大顺序存储。链表的节点包含某条全量信令数据本身以及从该条数据中提取出的时间信息，该时间信息用于判断某条消息在链表中的存放位置。

（2）数据分组在数据缓存中快速定位

通过链表查询的方式在数据缓存中定位数据分组，应该存放的位置的时间复杂度为O(N)，效率低下。通过设计一个辅助查询散列表[9]可提高查询效率。该散列表key值由数据分组时间戳中的s、μs和m_scale（时间窗口大小，取经验值，一般为100）按式（1）计算得到。

散列表节点存储的是该时间窗口内，时间戳最大的数据分组在链表中的位置。在查找某个数据分组在数据缓存链表中的位置时，利用本数据分组时间戳计算key值，查询到该数据分组属于某个时间窗口，然后在该时间窗口内比较得到该数据分组应该插入的具体位置。用辅助散列表方式定位的时间复杂度为O(1)。

（3）从缓存中读出数据条件

因为数据分组在数据缓存链表中是按时间戳由小到大的顺序存储的，判断缓存中首尾分组时间戳之差与系统设定排序的乱序范围，如果前者大于后者，表示排序范围已经超过系统值，取出首数据分组存盘。

3.3 分流模块

分流模块是将汇聚后的全量信令数据按一定规则分成多路存储。数据分流的基本原则为：从同一网元设备采集到的数据应存储到相同的路径下，这样做是为了保证多个信令处理进程单独处理各路信令数据时能够正常进行。

本文提出按通信网络中网元的维度进行分路，这样可以满足各路流量均衡的要求。现以GSM网络A+Abis接口为例，A+Abis信令从网元设备BSC采集得到，所以按BSC维度进行分路。从A+Abis的全量信令中，可以得到采集机号、板卡号、端口号、EI号和时隙等信息。通过分析采集机号、板卡号和端口号等信息，可以得到某几个字段和BSC的映射关系，将这一映射关系保存到XML文件中供分路使用。

分流模块在接收到排序模块输出的顺序数据分组时，首先从数据分组头中提取出确定分路信息的相关字段，然后以此查找XML文件获取该数据分组应存储到哪一路。为了提高XML查询效率，借助散列索引，选取分路信息字段为key，建立分路信息的散列索引表。

4 方案测试验证

本方案的测试为局域网内的测试，测试环境如图3所示。选择两台部署有SDTP客户端程序的小型服务器模拟汇聚设备，服务器中存储有大量从现网采集的原始信令数据。一台部署有按本方案实现的信令接收程序的中型服务器，模拟信令共享平台的接收服务器。

接收服务器输出日志如下：

2013-4-22 15:38:12.673@LM_INFO MsgCapture start!

2013-4-22 15:38:12.681 @LM_DEBUG Listen on 192.168.2.100.7500 successfully!

Listen on 192.168.2.100.7501 successfully!

2013-4-22 15:42:53.798@LM_DEBUG CSDTPAgent1 start!

2013-4-22 15:42:55.087 @LM_INFO Client 192.168.2.2:6000 has connected with server!

2013-4-22 15:42:55.096@LM_INFO Negotiation passed.

2013-4-2215:42:55.098@LM_INFO Receivedauth message,username=test1,pwd=123

2013-4-22 15:42:55.099@LM_INFO LinkAuth passed!

2013-4-22 15:42:55.103@LM_INFO Received Notify SignalData Request!

2013-4-22 15:42:55.105@LM_INFO Ready to Receive SignalData!

…

从日志中可看到，SDTP服务端程序启动时，首先启动了两个监听线程，端口分别为7500和7501，当服务端监听到有客户端连接服务器时，服务端启动客户端代理CSDTP agent1；接着客户端成功与服务端代理连接，当TCP连接建立后，开始版本协商和客户端鉴权，二者都顺利通过；最后是全量信令数据的发送过程。

对于排序功能的测试，本文用到了自己开发的数据分组乱序检查工具（其原理是比较相邻数据分组的时间戳），对未加载排序模块和加载排序模块后的数据进行检测，结果见表2。

从表2中可看到，在没有加载排序模块时，服务端收到的数据分组存在大量乱序，所占比例为10.18%左右。加载排序模块后，排序时间为3 s时，乱序时间小于3 s的已经被重新排序，但仍然存在乱序时间大于3 s的情况，乱序平均值为8.72 s，比未加载排序模块时有所增加，表明乱序时间大于3 s的数据分组比例较大，测试出乱序分组的比例为8.74%，比未加载排序模块时下降了1.44%；排序时间设置为10 s时，由于数据分组最大的乱序时间小于10 s，所以所有数据分组均被排序模块排为正序。

图3 测试环境

表2 不同排序时间下乱序统计

5 结束语

基于SDTP提出的全量信令接收方案是一个行之有效的方案，解决了信令监测系统采集层和信令共享平台间的信令传输私有化、原始信令数据共享率低下问题。该方案设计的三大功能基本能满足信令共享平台接收信令数据的需要，且数据接收能力强。未来的研究方向是如何将该方案与云计算和云存储相结合，并将结合后的方案运用于基于云计算的信令监测系统中。

1 韦薇，张扬.信令监测系统架构规范的演进.电信工程技术与标准化,2011(4):48～52

2 李勇,雒江涛,黄建.软交换网络集中监测系统SIP监测方案.电讯技术,2012,52(1):101～104

3 史鹏利.河北联通移动分组网信令监测系统的研究及设计.北京邮电大学硕士学位论文,2012

4 方晓农.信令监测系统全国联网方案探讨.数据通信,2012(5):38～45

5 陈璟飞.综合信令业务支撑云平台.电信网技术,2013(1):58～62

6 徐雷,张云勇,陆斌等.基于云计算的信令监测平台研究.电信网技术,2011(5):1～4

7 中国移动通信集团公司.信令监测系统接口规范——信令采集网关分册,2012

8 严蔚敏,吴伟民．数据结构．北京：清华大学出版社,2003