信令设计

信令设计（精选9篇）

信令设计 篇1

1 概述

区域人流量分析统计是国家制定政治经济政策, 指导人民生产生活的一项非常重要的参考依据。但长期以来, 统计部门只能依赖于抽样统计[1,2,3]的方式来进行获取。这种方式需要消耗大量的人力物力, 统计周期较长且很难得到一个较准确的数据。而且由于人群的流动性, 实际人群分布数据是一个动态变化的过程, 传统的统计方法根本无法实现对数据的动态掌握。文献[4]中提出了一种利用用双目摄像机原理进行人流量统计的方法, 该方法采用两个CCD摄像机, 运用双目立体视觉技术、摄像机标定算法与立体匹配算法对人流量进行统计。这种统计方式与人工计数方式相比更加智能化, 对铁路站、机场以及一些大型的展览馆比较适合, 但是由于要部署大量的摄像机与服务器, 部署周期较长, 硬件成本较高, 后期维护成本也较高。

随着互联网与移动通信技术的迅速发展, 移动用户占手机使用总人口的比例迅速攀升, 尤其在北京等发达地区, 移动用户已经接近人口总数的80%。因此, 移动用户的分布情况, 可以近似于地区人群的总体分布情况。与此同时公众出行群体中手机持有者的比例也日益上升, 这使人们越来越认识到移动通信网络中的手机信令数据可以作为一种理想出行分析探测器[5]。

目前, 各级政府部门包括国家旅游局、北京市公安局、北京市交通委员会、北京市旅游发展委员会以及北京市各区县相关部门都有关于移动用户资源数据的应用需求[6,7]。如交通规划、交通调查、旅游景区等重点区域的人口流量监测、流动人口监测管理等等, 但由于目前缺乏现网数据统一的处理应用平台, 在之前的客户需求满足上, 出现了需求反应时间长, 效率低下等问题。本文正是基于以上状况结合北京移动信令处理基础平台项目提出了一种利用现网移动信令数据来实时统计区域人流量的系统架构, 该系统已通过北京移动等相关部门的验证, 目前在北京移动昌平机房试运行。

2 系统设计

2.1 原理

实时人流量是交通量的一种, 交通量[8]是指单位时间里通过道路或某一交通小区断面的交通实体数量。基于手机信令的流量统计, 这里的交通实体数量指的是人数基础平台通过移动通信信令进行人流量分析的一个根本性依据是通过移动用户发生的通信事件记录 (如用户呼叫、短信、位置更新等通信事件) 来判断该用户所处的位置。本平台通过对甲方区域信息服务业务系统传送过来的合成后的甲方移动通信网络全网相关接口 (A接口、Mc接口、HSTP等) 的海量用户信令基础信息, 调用相应算法进行存储分析, 并结合GIS技术, 实现甲方网络参数与GIS地图的自动匹配并动态更新, 在保障用户信息安全的同时, 满足政府类客户对特定区域的人口流量、出行统计需求[9,10], 以及甲方内部平台的数据支撑统计需求。

2.2 系统的总体设计

为描述方便现将用到5个接口定义如下:

IF1:基础平台与区域信息服务业务系统之间;

IF2:基础平台与外部政府客户应用系统之间;

IF3:基础平台与VGOP等内部应用系统之间;

IF4:基础平台与EDSMP集团业务管理平台之间;

IF5:基础平台与网运中心网管系统之间

基础平台通过IF1接口从区域信息服务 (RISS) 订阅和接收区域信令事件, 经过数据挖掘和统计分析之后, 通过实时/非实时接口向外部政府客户应用系统和内部业务系统提供基于地理信息系统 (GIS) 的实时监测和历史分析结果。基础平台同时分别通过IF4和IF5与集团业务管理平台 (EDSMP) 和网运中心网管平台互连, 实现与集团业务平台的对接, 以及定期实时接收移动通信网络参数。总体方案如图1所示。

2.3 模块设计

由图1知, 该系统主要有三个部分组成:区域信息服务业务系统、信令处理平台、应用客户端, 本文主要针对该系统核心--信令处理平台的设计而写。信令处理平台主要有入库程序、接口程序、数据库ETL、外部应用、管理五部分组成。其中入库程序部分主要包括目录监控模块、文件生成模块、消息发送模块、消息监控模块;接口程序部分主要包括文件导出、SOCKET服务端、与其他系统的特定接口;数据库ETL部分主要包括存储过程与算法的调用、JOB及管理;外部应用部分主要包括登陆模块、图表展示模块、报表展示模块、文件导出模块;管理部分主要包括客户端模块、分析服务端模块、GIS管理模块、业务定制模块。模块设计详图如图2所示。

入库程序主要接收从甲方区域服务系统采集的现网手机信令数据, 根据配置好的数据库连接字符串, 从数据库读取用户手机归属地, 用户手机型号, 通话监控手机号, 短信监控手机号4个缓存;接口程序负责文件的生成, 数据的接收与发送以及与其它接口的链接;数据库是该信令平台的重要组成部分, 存储所有的存储与分析过程;外部应用主要是数据的前台WEB展示, 要求前台在WEB页面显示登陆信息, 数据能以报表与图表展示;管理模块主要实现平台所有服务器如WEB服务器、GIS服务器的管理以及GIS区域的圈选与相关业务的定制, 如特殊号码监控、通勤出行分析等。

2.4 平台的软件架构图

本系统主要对北京地区的海量移动网络信令数据进行存储、分析、展示, 由由于北京地区人口的流动性较强, 现网信令数据巨大, 那么如何保证系统对数据处理的实时性, 如何保证系统的可靠性与稳定性对整个系统至关重要。本系统的核心在信令数据处理模块, 该模块主要的负责对海量的数据的存储、分析, 该模块的性能直接影响整个系统, 为了提高整个系统的性能, 就必须合理规划该模块软件系统架构, 使其在实时数据的处理分析方面尽量最优。平台软件架构图如图4所示。

系统软件架构分为上下两层, 如图3所示, 从下往上分为基础数据处理层 (BDP:Basic Data Process) 和应用分析处理层 (AAP:Application Analysis Process) 。

基础数据处理层 (BDP) 主要通过IF1接口接收来自区域信息服务业务系统的信令数据。先将接收到的信令数据放入临时缓存, 然后经过压缩、建立原始数据索引、加密等预处理后将数据存放至细节数据库。细节数据库中存放的数据即AAP层进行分析的数据来源。而移动通信网络参数和GIS基础图层数据、基站图层数据等数据则通过IF5接口存放至网络参数存储单元和空间数据库。

应用分析处理层 (AAP) 主要负责根据需求进行进一步数据加工, 并对外提供数据服务。首先将细节数据库中的数据使用包括提取 (Extract) 、转换 (Transform) 和加载 (Load) 的ETL程序集 (应用数据库存储过程, 结合相关算法和分布式数据库等多种技术, 根据不同的业务需求相应设计的专题工具) 来分析统计数据。然后将分析处理结果存放至数据仓库DW1 (外部应用数据仓库) 和DW2 (内部应用数据仓库) 。通过数据服务引擎 (DSE1和DSE2) 和应用接口IF2、IF3来提供人流量和人口出行分析和VGOP等内部应用系统业务请求的分析结果或报表。并通过Web/GIS服务单元, 提供相应的GIS服务。

2.5 数据的处理流程

基础平台接收信令数据和网络参数等基础数据, 经过分析处理形成外部政府客户和内部业务平台所需的报表数据, 完整的数据处理流程如图4所示。

(1) 基础平台接收信令数据, 作为临时数据, 存储在临时数据区;

(2) 临时数据, 结合网络参数等基础数据, 经过预处理过程, 生成细节数据, 存贮在细节数据库;

(3) 细节数据经过ETL工具处理, 根据业务需求, 生成多维报表数据, 存贮在相应的DW中;

(4) 用户接收报表数据;修改或生成新的业务需求并部署给基础平台。

由于现网的手机信令数据是海量的, 所以数据入库前要进行预处理, 系统入库预处理数据流图如图5所示:

数据流向简要说明:

(1) 信令数据接口发送文本数据到远端服务器。

(2) FTP监控程序将远端服务器信令数据流读取到本地, 输出TXT文件。

(3) 数据预处理程序读取本地信令数据流处理后转化成加密后的元数据。将元数据流发送到数据库保存。

(4) ETL程序读取元数据多层处理后, 将加工的统计数据反发送回数据库保存。

(5) 数据库将统计数据按系统请求将被请求数据流发送至应用系统。

3 实现

这里以北京市旅游局指定区域 (天坛公园) 与北京市交通局所指定区域 (北站地区) 统计结果展示为例, 首先北京市旅游局与北京市交通局指出需要统计的区域, 北京市移动根据指定区域汇总区域对应的cellid, 然后将cellid表导入后台, Gis会根据导入cellid自动匹配区域, 然后调用算法, 产生数据, 最后在前台web展示:如图6, 图7所示。

由图6、图7知各景点或者交通枢纽早上1点至早上7点人流量较少, 8时之后逐渐增多, 中午12时左右最多, 下午5时候逐渐减少, 符合实际情况。通过该统计方法我们能利用信令处理平台直观地观察到各区域人流量状况, 图中数据展示已通过北京市相关部门验证, 目前该产品已在北京市移动正式上线运行。

4 结论

论文深入研究了实时性人流量统计方法的原理, 在此基础上设计出基于移动网络信令数据的人流量统计系统中信令处理平台模块, 并基于北京移动信令处理基础平台项目完成了对模块的验证, 成功实现了对各区域实时人流量智能化统计, 并展示出实时数据统计结果。应用该成果我们只需在现有移动网络现网的相应接口上安装信令采集设备, 并将采集到的信令数据传送至专用服务器进行分析、处理, 最后就在web页面展示统计结果。不需要重新部署新的系统, 节省了基础设施投入, 对移动网络不产生任何影响, 而且有利于快速覆盖和应用。

摘要：实时掌握城市交通枢纽、各大旅游景点的人流量状况, 为城市交通规划、旅游景点人力资源配备提供数据支撑已越来越受到相关部门重视。结合北京区域人流量系统项目中移动信令处理基础平台模块提出一种利用现网移动信令数据统计实时人流量数据的架构, 该平台已经过北京移动与北京市旅游委、交通局验证, 目前在北京移动正式运行。

关键词：信令处理平台,区域人流量,系统架构

参考文献

[1]关志超, 胡斌等.基于手机数据的城市交通信息采集技术研究[A].中国智能交通协会论文集[C], 北京:中国智能交通协会, 2012:845-848.

[2]冉斌.手机信令数据在城市交通管理中的应用与展望[A].中国智能交通协会论文集[C], 北京:中国智能交通协会, 2012:18-23.

[3]刘杰, 胡显标等.基于无线通信网络的人员出行信息系统设计与应用.公路交通科技[J], 2009, 26 (12) , 6-8.

[4]张艳琼.基于立体视觉的行人流量分析.计算机测量与控制, 2008, 5 (5) :12-17.

[5]杨飞, 裘炜毅.基于手机定位的实时交通数据采集技术[J];城市交通;2005, 3 (4) , 1-3.

[6]张博.基于手机网络定位的OD调查的出行方式划分研究[D].北京:北京交通大学, 2010.

[7]信令处理基础能力平台技术规范书.重邮汇测通信技术有限公司, 2012.9.

[8]北京移动信处理基础平台总体技术要求.中国移动集团北京公司, 2012.8.

[9]赖建辉, 陈艳艳等.基于手机定位信息的地铁乘客出行路径辨识方法[J].计算机应用, 2013, 1 (2) , 3-5.

[10] Goto T, Tagami A, Hasegawa T et al.TCP ThroughputEstimation by Lightweight Variable Packet Size Probing inCDMA2000 1x EV-DO Network[C].9th Annual InternationalSymposium on Applications and the Internet.Bellevue, USA, 2009:1-8.

信令问题被掩盖真相 篇2

关于信令风暴产生的具体原因，一个比较详细的解释是：随着智能终端的增加，使用Push Mail、微博、IM、SNS、浏览网页、下载软件、视频点播等应用的终端不断增加，导致现网用户的话务模型偏离网络初期设计的话务模型，网络设计配置的各项资源无法支撑现网话务模型对应的信令负荷，引发网络拥塞甚至雪崩效应，导致网络不可用。

不过，国内知名电信专家侯自强直接向记者表示，信令风暴问题，现在被运营商出于自身商业利益的考虑极为夸大，技术、设备上进行针对性的优化改进就能解决，而且相关成本投入并不算高。

对于信令风暴问题，其实中国移动等电信运营商早有预见和部署。

信令问题并非症结

2006年7月中国移动通信研究院上交的一份《中国移动信令网演进研究》报告中称：中国移动的信令网HSTP之间，信令负荷持续增加，1/4省达到设备终极容量，需要升级TDM信令网，或者引入IP STP。中国移动现网采用TDM承载方式的七号信令网覆盖全网，随着各业务网络对信令网需求的不断增长，以及信令网IP化承载技术的成熟，信令网向IP化改造将逐渐提上日程。

在这份报告中，中国移动把IMS多媒体通讯系统（如飞信业务）作为未来发展的主流趋势，而信令技术发展趋势是IP化：引入IP信令网。长远来看，在后IMS时期，实现信令IP化后，不需要信令网，信令承载IP化，信令本身IP化。

报告中在对TDM扩容方案和引入IP信令网方案的对比中，还提到，引入IP信令网，未来信令量越大，成本优势越大。报告中最后建议，在2007年积极推动IP信令网的成熟。事实上，3G就主要是采用IP承载方式。

因而，面对传统电信业务本身的激增和移动互联网兴起带来的双重压力，中国移动目前对传统2G、2.5G下TDM信令网的改造升级进度，直接关系到向3G、4G过度时期网络的稳定。毕竟，相比中国联通和中国电信，中国移动的2G/2.5G用户群更为庞大，而投资上千亿元建设TD网络、耗巨资补贴TD手机，结果又是TD数据业务收入很低，仅仅发挥了分流一小部分话音流量的作用。（其实2010年，便有这样一个不了了之的传闻，中国移动要求腾讯额外为手机QQ占用的移动通讯资源付费：可以以信令费的方式支付，也可以从包月付费方式改为短信付费方式。）

当然，另一种说法是，传统 3G 网络更多关注大流量数据传输解决方案，但3G实际流量模型与当初设想大不相符，主流互联网应用为实现永久在线，采用UE向服务器频繁发心跳模式，信令流量大超预期呈几何级增长，3GPP目前也没有定义完整成熟的标准来支撑 MBB 应用层永久在线机制。更有专家称，在4G标准完善过程中也曾讨论过小流量常在线的问题，但最终并未针对这一问题做出根本性改变，依然会受到信令风暴的冲击——业界人士吴鹰则表示：4G成本是3G的1/3，速率是3G的10倍。4G时代将不存在信令问题。

需要说明的是，业界有关信令问题尤其是微信、QQ等小流量移动数据业务的网络优化方法、智能管控和流量经营等方面已经有诸多研究成果。

华为、中兴等电信设备厂商近几年便在致力于解决信令风暴问题，比如华为的解决方案，能优化智能终端信令流程，大幅减少信令流量；优化设备提升RNC和NodeB的信令处理能力；规划Micro微基站，吸收热点信令和话务；通过网优专业服务确保信令风暴方案成功部署。

而中兴通讯的一体化信令风暴解决方案，通过网络信令模型的实时监控和主动通知，实现信令风暴提前预警，让移动网络运营商在应对信令风暴占据时间主动；并提供定制化的信令风暴优化解决方案，减轻信令风暴的影响，最终帮助移动宽带网络运营商避免信令风暴后知后觉并形成危害。

新加坡运营商Starhub早年的处境和如今国内运营商面临的困扰如出一辙，数据业务发展迅速，移动网络信令负荷进入高负载状态。Starhub在采用了华为的智能终端信令风暴解决方案后，第一阶段实际测试结果显示，一个多月时间，约4万部iPhone信令数量就下降了 72.4%。

基础设施投入谁买单

目前而言肯定的是，收费本身并不能解决信令问题，电信运营商需要技术改造升级和持续的网络基础设施建设投资。

微信收费争议的实质其实也就在于，用户或者OTT民营企业是否需要为这笔投资买单。

我们可以从几个角度去分析。第一，运营商从数据业务流量增长上获得的收入，能否抵消信令上的投资？这点已经被相关电信人士所否定。

记者从上述《中国移动信令网演进研究》报告中看到，对于传统的TDM信令网改造，IP域省内信令采用直连疏通，如果省际信令负荷翻1倍，相应成本投入约为6亿元。当然，现在的情况应该要比当时设想的更为复杂。

根本问题在于，是否有一个客观的评估标准，让真实的信令网升级成本透明化？即便最终事实情况需要让OTT民营企业做出补偿，也需要一个公平的机制。即：所收费用是否用于信令网投入、风暴可控时何时终止此项收费。

事实上，腾讯总裁刘炽平不久前表示，微信在心跳方面已经做了许多优化，相比Facebook、MSN，微信的心跳频率只有前两者的1/4。目前针对2G、2.5G网络的信令占用问题，微信已有多个方案，可以较好地大规模降低“心跳”资源占用和成本，下一步会和运营商继续深入探讨这些技术方案，促其早日实现。

通信世界网总编刘启诚认为，腾讯自己投入经费解决信令问题，相当于腾讯就微信占用信令向运营商变相交费了。

第二，如果运营商坚持以成本太高为由延缓信令网改造升级步伐，并提出收费需求，我们是否可以理解为运营商只有自己的OTT业务赚钱，才肯扩展信令网？那政府可视运营商按完全商业企业的原则，而不是按国有企业的原则行事，可以考虑引进竞争，看看引入民营资本竞争后信令的价格水平高，还是独家经营信令费高？

第三，对于运营商和OTT企业而言，其实共同的利益在于，争取国家在宽带基础设施上更多的投入。北京邮电大学经济管理学院教授曾剑秋认为，就国家的宽带战略而言，国家应该承担相应的责任，包括资金应该有多元的渠道，有稳定可靠的资金的形式。

信令设计 篇3

传统的信令监测系统往往以基于网元层面的客观评估方法对网络进行优化和故障诊断，并没有充分考虑网络安全和用户体验[2]。然而，在大数据时代，从用户的角度，海量数据中包含大量用户敏感信息，确保这些信息的安全已受到用户越来越多的关注;从电信运营商的角度，海量数据只是简单存储在服务器中，这些数据中隐含的价值没有得到利用，通过对海量数据的挖掘分析不仅可以按照用户不同需求实现差异化服务，也可以更精细的管理、经营业务。因此，建立一套基于大数据的信令监测系统对用户和电信运营商都具有重要意义。

本文在传统的信令监测系统的基础上，重点研究了大数据的关键技术和数据分析挖掘的方法，设计了一套基于大数据的信令系统监测方案，并详细介绍了该方案在网络优化、业务经营、网络安全3方面的应用。

1 大数据在信令监测系统中的应用

1.1 大数据环境下信令数据特征分析

相比于传统的信令数据，由于通信技术的快速发展和数据流量的急剧增长，现网数据包含信令面和业务面数据以及错综复杂的用户数据，从这些数据中挖掘出的信令数据对信令监测系统有着重要作用。现网信令数据具有大数据特征:

1)数据量巨大。存储的数据量十分庞大，通信技术的快速发展和智能终端的普及，使得信令数据的数据规模从TB级别跃升到PB级别甚至更大，因而对其分析的计算量也大。

2)数据类型多。数据类型非常复杂，不仅仅包括大量的像文本这种结构化和半结构化数据，还包括图片、音频、视频以及地理位置信息等非结构化的数据。

3)价值密度低。对数据的处理挖掘存在潜在的价值，但是大量复杂的不相关数据会导致价值密度低。

4)处理速度快。数据的增长速度快，那么处理速度也要快。处理速度越快，实时性越高，其价值就越大，发挥的效能也就越大，这是大数据区分于传统数据挖掘的本质区别[3]。

1.2 大数据处理在信令监测系统中的应用

由于现网信令数据的大数据特征，不能运用传统的信令监测系统对其进行分析。面对大数据，传统的信令监测系统存在以下几个方面的问题[4]:

1)网络的运行质量在很大程度受数据量的影响，现网数据不仅包括结构化数据，还包括非结构化数据，传统的信令监测系统只适合于分析结构化数据，而不能分析视频数据等非结构化的数据。

2)由于网络链路和数据流量的飞速增长，传统的信令监测系统在海量数据的高效率读写、高并发读写、可扩展性等方面存在缺陷，无法满足海量数据在计算和存储等方面的需求。

3)现网大数据要求信令监测系统能够满足大规模数据挖掘、实时反馈分析结果、实时触点营销等需求，但是传统的信令监测系统因其垂直化的架构设计使得建设成本高，而且服务的响应时间长，难以满足大数据对信令监测系统的要求。

针对上述问题，本文提出的基于大数据平台的信令监测系统，实现了对多样化数据结构、海量信令数据的分析、挖掘和存储，具有建设成本低廉、数据实时处理高效、系统配置灵活、系统扩容平滑等显著优势。信令监测系统的大数据关键技术[5,6,7]主要包括并行计算、分布式数据库、分布式文件系统和云存储等。

1.2.1 并行计算

并行计算是指利用多种计算资源来协同解决同一个计算问题的一种计算手段，能够有效地提高整个系统的处理能力和计算速率。其基本思想是将同一计算问题分配到若干个处理机同时进行计算，即将需要求解的计算任务分解成若干个子任务，各个子任务都由一个独立的处理机来完成并行计算。并行计算系统既可以是含有多个处理机的计算机，也可以是若干个通过某种方式相互连接的计算机集群。

1.2.2 分布式数据库

分布式数据库系统一般使用较小的计算机系统，采用分布式架构对海量数据进行存取，并通过集中服务器对资源进行管理或调度。其基本思想是将原来集中式数据库中的数据分散地存储到多个网络互连的数据存储节点上，从而获取更大的存储容量和更高的并发访问量。由于关系型数据库在处理海量数据时存在一些很难克服的缺点，使得可扩展性和并发性高的非关系型数据库得到快速发展，传统的关系型数据库开始从集中式模型向分布式架构扩展。

1.2.3 分布式文件系统

分布式文件系统是指资源存储在分布于各处且与网络互连的节点上，而不是一定连接在本地节点上的文件系统。其基本思想是通过网络互连的方式将各个节点的存储资源整合在一起，在提供大规模的文件存储能力的同时，还能降低高端服务器的使用成本。分布式文件系统通常采用C/S(客户端/服务器)的设计模式，将数据存放在一个可供多用户访问的服务器集群上。当用户访问分布式文件系统时，首先需要定位用户所需存取数据在集中服务器存放的节点，定位成功之后，分布式数据存取就与传统文件系统下普通的资源存取方式一致。

1.2.4 云存储

云存储是指将存储资源放到云上供用户随时随地通过任何可连网设备存取的网络存储系统。其基本思想是利用网络技术、集群应用或分布式文件系统等技术，将网络中大量的类型各异的存储设备通过软件集合起来协同工作，实现数据存储功能和数据访问功能[8]。

2 基于大数据的信令监测系统设计

在传统信令监测系统的基础上，基于大数据的信令监测系统如图1所示，整个系统采用集群架构和分层分布式的数据处理模式[9]。

2.1 数据采集层

数据采集层主要功能是通过一个或者多个采集点的信令采集设备采集通信网的信令数据与业务数据，如GB接口、IUPS接口等接口的数据，并把这些接口的数据进行整合，即把数据进行过滤、复制、整合处理，实现数据的统一存储。信令采集点的位置一般设在信令转接点、长途局等信令链路比较集中的地方[10]。

2.2 数据处理层

数据处理层主要功能是完成对采集层采集到的信令数据进行处理，包括协议解析、数据转换、批量计算等。该层根据功能可分为以下两大模块。

2.2.1 信令预处理

该模块主要功能是把采集设备采集到的二进制数据流进行预处理，如接口适配、协议解析等，转化成用具有逻辑意义的数据结构并能提供给计算平台的调用。首先，整合后的数据经过接口适配，根据需求的不同选择相应的协议解析方案。协议解析分为两种:一种为只提取消息中的部分关键字段信息，跳过其他字段信息的简单解码;另一种为对信令数据或者业务数据整条消息的所有信息都进行解析并对某些关键字段生成解析说明的详细解码[11]。其中详细解码的流程如图2所示。

经过解码后，需要把同属一个CDR流程的消息进行关联匹配并合成[12]。合成流程如图3所示。

2.2.2 分布式计算平台

经过预处理之后得到原始CDR文件，根据不同的需求经过数据分流分发到各个分布计算流程进行处理。若需要对现网数据进行流量统计、呼损分析、话务统计等实时处理，则选择实时数据流处理流程;若分析用户的群体构成及其偏好或者高精确度与高效率的大数据量处理任务，可以分流到批量式计算处理流程，并把相关数据存入分布式数据库，以供应用层各种业务需求调用[13]。

在批量式计算处理流程中，用户偏好等分析需要对用户使用的业务进行识别，故该流程采用了DPI技术进行业务识别。DPI业务识别流程如图4所示，具体流程如下:

1)读取DPI业务特征库，生成DPI数据字典;

2)读取数据文件，逐条地提取业务数据中的HOST,URL,Refer等字段信息;

3)根据HOST信息，通过DPI数据字典查找相关特征，并与URL、Refer等字段进行比对，若URL等信息与特征相匹配，则识别成功，并把业务信息与HOST等字段进行关联;否则业务信息为空。然后再进行下一条数据识别;

4)把识别的结果录入数据库[14,15]。

2.3 应用层

应用层主要功能是把数据处理层处理得到的数据进行归纳、分析，按照不同的专题应用进行统计，如呼损分析、TOP业务统计、网络优化等。对于各种应用的结果，可选用柱状图、表格、折线图、饼状图等不同形式进行展示。

3 基于大数据的信令监测系统应用分析

信令监测系统的大数据解决方案，实现了对海量数据的并行处理和深度挖掘，相对于传统的信令监测系统，在网络优化、业务经营、网络安全等方面具有显著的优势。

3.1 网络优化

基于大数据的网络优化应用通过信令采集模块采集原始信令数据，并利用大数据平台的处理能力对移动网络各项KPI进行统计挖掘，从而找到影响网络质量的原因。由于我国各地区通信服务水平的差异，三大运营商需要综合协调发展不同的网络类型，如2G、3G、LTE等网络，各类型网络的统计KPI多达百余项，基于大数据的信令监测系统可以对网络问题进行高效处理和实时定位。

以某部专用网(SS7信令系统)中的实测数据作为数据来源，对专用网络下的ISUP呼叫接通率进行统计，统计结果如图5所示。

由图5第一行可得到源信令点和目的信令点之间的呼叫接通率为98.29%，呼叫应答率为74.36%，通信状态良好。

以重庆移动某地区公用网络中采集的数据作为数据来源，对该地区公网网络下的附着成功率和路由区更新成功率进行统计，统计结果如图6、图7所示。

从图6和图7可以得到该地区附着成功率只有40%，路由区更新成功率为90%，网络通信质量较差。

3.2 业务经营

随着OTT应用的爆发式发展，从电信运营商的角度，三大运营面临越来越大的管道压力，并逐步从语音业务转向流量经营。基于大数据的信令监测系统通过对用户海量业务数据的挖掘统计，可以实现用户偏好分析、业务TOP分析、用户流量分析以及夜间高流量用户等分析。通过以上分析，不仅可以提高用户体验，还可以实现业务的精细化经营和用户的差异化服务。

图8展示了在客户端页面中查询出的2015年1月视频用户对3G门户-NBA直播中心的偏好程度分析情况。

从图8中可以看出，通过对当月视频用户使用时长、使用流量和访问次数3个指标的统计分析后可知:行号为1,IMSI为“460026083440797”的用户被划分为强偏好用户;行号为6,IMSI为“460025083291428”的用户被划分为发烧用户。

图9展示了2015年1月—3月根据用户量统计出的电视剧Top10，从图中可以看出，用户量排名前三的都是网络热播剧。

3.3 网络安全

随着业务综合化、开放化和网络融合化的发展，专用网络的安全脆弱性日益显露出来，传统的信令监测系统主要是实现网络优化和故障诊断，在网络安全防护方面相对比较薄弱。基于大数据的信令监测系统通过对各类攻击方式的深度挖掘，能够有效地对攻击行为进行识别，并制定相应的防护方案，从而达到保护网络安全的目的。

3.3.1 骚扰电话拦截

骚扰电话是指攻击者通过合法用户接入，利用电话网资源，骚扰和欺骗合法用户，常见的骚扰电话形式有以下3种:

1)被叫用户听到电话振铃，用户电话振铃却无法正常通话;

2)被叫用户听到电话振铃，主叫号码显示为空号或是公共服务号码;

3)用户听到电话振铃，接通之后转至一段录音。

基于大数据的信令监测系统通过对各类攻击行为的深度挖掘，分析出骚扰电话具有以下攻击特征:

1)振铃时长短;

2)超频呼叫;

3)主叫占比门限高，号码作为主叫呼出的次数占所有呼入呼出次数比例高;

4)用户通常无法正常接听;

5)不产生话单记录。

根据以上骚扰电话的特征，基于大数据的信令监测系统网络安全防护方案如图10所示。

信令消息采集:从链路数据包中过滤出需要处理的信令消息。

呼叫状态恢复:对采集到的信令消息进行解码合成，从中得到每一条呼叫的用户序号、开始时间、结束时间、主被叫号码、接通时长、应答时长、通话时长等表征用户通话过程的行为参数，并为每条呼叫建立记录以供分析。

分析检测:对骚扰电话进行检测，若判断为骚扰电话，则通知系统进行拦截，并保存该号码至骚扰电话黑名单。

行为数据挖掘:将该条呼叫记录与数据库中的海量数据进行深度挖掘分析，如该呼叫主叫占比门限高达90%，则判断该条呼叫的号码为骚扰电话。

识别特征库设置:自动或人为调整分析检测环节中所设置的各种判决门限。

骚扰电话拦截:对骚扰电话进行拦截，并以短信形式预警被叫用户。

以某部队专用网(SS7信令系统)中的实测数据作为数据来源，对号码的接通时长、应答时长等指标统计分析如图11所示。

通过以上统计，基于大数据的信令监测系统可以对专网网络下的各个号码进行全面监控，结合骚扰电话拦截系统，可以全面防范并处理骚扰电话的攻击。

3.3.2 虚假主叫号码识别

虚假主叫主要是通过改变主叫号码来实施欺骗或欺诈，基于大数据的信令监测系统可以通过在汇接层获取主叫号码的海量信令数据，然后通过大数据处理技术与现网识别规则库进行对比，从而最终判断来话路由是否正常。

以某专用网为例，整个虚假主叫号码识别步骤如下:

1)建立全网所有交换局下各用户号码与该信令点编码或IP地址之间的对应关系，形成识别规则库;

2)获取主叫号码和发送呼叫信令的交换局源信令点编码以及IP地址;

3)将提取的关系与识别规则库进行对比;

4)若识别为虚假号码则对用户进行预警。

整个识别流程示意图如图12所示。

以某部队专用网(SS7信令系统)中的实测数据作为数据来源，通过PL/SQL程序在监测系统数据库中查询到5月15日的虚假号码识别结果如图13所示。

从图13中可以看到，5月15日共查询到两个虚假号码，分别是“0603969774”和“0701014331340”。

4 结束语

未来移动通信将迎来大数据时代，如何快速、高效地实现海量数据的处理与挖掘将成为未来建设信令监测系统的研究重点。基于此，本文提出了一套信令监测系统建设方案，该方案基于大数据分析，详细分析了该方案的业务需求和功能架构，重点介绍了该方案在网络优化、业务经营、网络安全三方面应用，验证了其合理性及可行性，为大数据时代背景下信令监测系统的建设提供了重要的理论支撑和实践基础。

摘要：随着计算机技术与通信技术的飞速发展,各种数据流量也随之急剧增加,这给信令数据的采集、存储、分析带来了巨大挑战。在传统信令监测系统的基础上结合大数据特征,设计了该信令监测系统建设方案,讨论了该方案的关键技术和功能架构,详细介绍了该方案在网络优化、业务经营、网络安全三方面的应用,为大数据时代下实现信令监测、提高网络安全,提供了理论支撑和实践基础。

信令设计 篇4

台上，微软和合作伙伴代表坐在高脚凳上，静候台下记者的提问，神情显得很轻松。但这种气定神闲之态只保持了不到一刻钟，就被记者的发问打乱。

“为什么思科不在被邀请之列？”面对这个颇具火药味的问题，让作为东道主的微软负责人张柏舟思索了几秒钟之后，把话筒交给旁边的助理：这个问题你要不要回答？这一举动，引发了台下记者们的一阵笑声。

2007年10月底，在北京亮马河酒店举行的微软“统一沟通”平台方案发布会上出现了以上别开生面的一幕。与此相呼应的是，微软此次会议刻意避开了“统一通信”，而采用了“统一沟通”这个新称谓。同时，包括北电、AVAYA、大北欧等合作伙伴在内大概有近千人到场。而这些大企业，无一不是思科在统一通信领域的直接或间接对手。

具有火药味的提问最终在笑声中被微软高层用官方语言打发掉，但是在对接距离越来越短、气氛越来越紧张的统一通信市场上，微软和思科这对曾经的合作伙伴，现在却成了竞争对手，虽然在表面上彼此之间仍然相互微笑相对，但实际上已随时准备冲向对方。

同床异梦

统一通信融合了计算机网络和传统电信网络，把电话、数据传输、音视频会议、即时通信等所有和沟通相关的应用集成在一起，能够实现任何时间、任何地点、任意设备的沟通。据Gartner数据显示，到2010年，全球统一通信市场规模预计达到100亿美元。

这个百亿美元的巨大市场由于涉及网络硬件和网络软件，史无前例地吸引各方巨头闻风而来。

2007年9月，IBM公布了其统一通信与协作策略工作计划；11月，AVAYA公布统一通信发展路线图；阿尔卡特-朗讯、北电……都在摩拳擦掌。而分属网络通信设备和软件行业巨头的思科和微软，面对这个蛋糕早就垂涎三尺。

和后者相比，占有先天之优的思科已先期介入该市场，占得约4成左右的全球市场份额，并率先于去年10月在香港推出全球首款成熟视频会议系统——网真。不过，思科的暂时领先无碍微软对该市场具有的野心——与几天前思科公司举办的统一通信第一届合作伙伴峰会相比，微软的上述会议规模和安排更为庞大和细致。

关于为何避开“统一通信”而选用“统一沟通”的称谓，微软(中国)有限公司副总经理张柏舟特意强调，微软在“统一通信”的功能上做了延伸，认为统一沟通是指统一通信+软件保障+客户体验，而后两项是微软的优势所在。

所以，从微软的官方语意来看，它和思科并非针尖遇到麦芒。“其实这几年，由于很多业务方面的合作，钱伯斯（思科首席执行官）和鲍尔默（微软首席执行官）在每个季度都有定期的非正式聚会，两个人会讨论关于双方合作的方式和遇到的一些问题，会谈场面看上去其乐融融。”一位业内人士透露。

在9月，思科宣布，除语音邮件和网络会议之外，在线状态信息也被纳入和微软公司统一通信合作计划当中，并表示还要开展更深层次的合作。

“两个公司的状态在商场上也属罕见，作为同一市场上利害关系最明显的对手，却必须合作。即使现在推出了office communications server2007这样的产品，微软也无法提供完整的解决方案，当然思科也不行，所以客户可能混用两家的产品来开发完整的解决方案，这就要求两家公司为了客户要考虑也要密切合作，可是合作又不是出于本意，说不定双方刚刚开会研究技术问题，回去之后就要制订相应的市场战略来应对。”上述人士笑谈。

这并不是笑话。

早在2003年，微软就在购买来的视频公司的基础上推出视频会议软件产品，与思科构成直接竞争关系。今年开始，两家公司开始了针锋相对的收购行为：微软在收购语音识别服务提供商tell me后的第二天，思科就宣布收购了网络视频会议系统提供商网讯，这两起收购都是触角向对方领域的一次延伸，而且时间如此巧合，针锋相对的意味相当强烈。

这种实质存在的对抗，在双方单独面对媒体时表现得愈加明显。钱伯斯曾声称在统一通信领域，思科领先微软至少三年。钱氏话音刚落，第二天的新闻报道就称之为“钱伯斯带着明显嘲讽的语气挖苦微软”。

这种日益增长的对抗情绪在中国市场上同样存在，思科中国一位负责人向《IT时代周刊》谈及了他的看法，他承认微软对思科造成了影响：“思科现在密切关注微软在统一通信市场的动作，它的确是个很大的威胁，但我认为，思科在这个市场上已经有了很长时间的积累，对市场需求的响应速度，以及产品的完备程度都远远好于对方。更何况，作为一个设备供应商，思科在渠道等方面积累的资源占据相当强的优势。”

在没有强劲对手之前，思科在统一通信市场独揽近4成的份额。但这种情况随着微软实力的膨胀正在改变。计世资讯企业系统研究部分析师徐斌说：“虽然微软对于通信领域来说，只是初来乍到，但是它对企业市场的影响力是天然存在的，这对思科来说是不小的挑战。事实上，从近期的市场来看，很多对此感兴趣的企业由于微软的介入而放慢了采购步伐，他们要比较一下，看看微软的产品是不是更好。”

微软合纵连横

2006年7月，微软与北电结成战略联盟，而北电是思科在网络设备领域有直接竞争关系的长期对手，这种联盟无疑让思科感觉到进一步的实质威胁。在战略联盟成立6个月，微软与北电宣布初步合作成果时，思科站出来声称“他们所夸耀的许多新功能我们在几年前就已经开发出来了”。

微软并没有放弃既定的策略：在这个以前从未涉足的领域，为了争取到更大的话语权，微软凭借着强大的号召力，几乎和统一通信市场上除思科外的其他所有厂商建立了合作关系，这其中也包括思科原来和现有的合作伙伴。

“微软统一沟通方案已经有50多家全球合作伙伴，这其中包括系统集成商、电话与设备制造商、电信解决方案提供商以及独立软件供应商，在中国的伙伴包括北电、AVAYA、大北欧等行业内一流的公司。我们将会吸引更多的企业加入到我们的合作伙伴体系中。”张柏舟表示。

“统一沟通说到底是产业链之间、企业联盟之间的竞争。”赛迪顾问软件产业研究中心总经理牟淑慧也认为微软的策略非常正确：“结盟的方式不但能够更快地完善方案扩展应用，同时这样也能够扩展面向用户群的触角，这对思科在渠道和技术方面的优势是很好的抗衡。”

市场形势的风云突变，让思科不得不开始改变策略。2007年10月，思科成立了“统一通信联盟”，为合作伙伴以及第三方厂商提供定期交流的平台，共同开拓统一沟通市场。“除了销售模式的调整，合作伙伴的协同工作也会更加密切。2008财年中，思科希望选出30~50家优选合作伙伴，他们可以得到项目支持以及特殊的折扣支持。在此基础上，我们还会优选出10~15家战略合作伙伴，通过资金的形式支持合作伙伴针对应用进行研发。”思科中国副总裁王昀宣布的政策显示了拉拢合作伙伴的迫切意愿。这又和微软的策略大体相似。

轻言获胜不容易

作为最早进军统一通信领域的思科，几乎可以提供“端到端”的产品体系，同时通过一系列的收购，他们融通了所有网络。所以，当“思科网真会议解决方案”甫一问世，被认为是目前业界最为成熟的企业级统一通信方案，除了技术的优势，思科作为设备制造商所拥有的庞大的渠道合作伙伴以及良好的网络架构，这些优势让思科在市场中一直以近四成的份额独占鳌头。

微软作为一个外来者想在这个领域呼风唤雨也并非没有缘由：统一通信的某些核心领域正是微软的优势所在，微软将通信功能深深根植于桌面以及服务器操作系统，同时，它召集几乎所有统一通信厂商的能量也是其他厂商望尘莫及的，强大的阵线联盟将使客户在产品设计、成本投入和功能创新等方面拥有更多的选择。基于免费捆绑策略，价格也是微软的强项，“如果统一通信基于软件平台的话，因为网络基础设施已经搭建好，所需要的只是一台服务器和PC，这个回报率要比其他方式高出很多。”张柏舟表示。

在纷繁复杂的统一通信战场上，主张语音与数据网络硬件层面融合的思科，提倡在现有网络进行应用软件层面整合的微软，走着截然相反的路。

兄弟登山，各自努力，谁能最先登顶，现在看起来并不那么容易判定。从目前的状况来看，二者自身都还不足够强大。思科的传统优势产品路由器等并不属于企业工作流程中不能替代的部分，怎样打开局面，进入属于企业信息化领域，这对思科是个障碍。而思科虽然与很多厂商组成合作伙伴，但是不同厂商的产品之间是否能够充分集成，也是短时间内不容易克服的问题。

“归根结底，在统一通信市场上，企业的核心竞争力还是对产业链的整合能力。不论是联盟还是收购，关键是整合。”广州葳泽信息网络科技有限公司CEO裴虹表示，统一通信市场上各环节的厂商也要审时度势，寻找有实力的厂商共同壮大。据了解，该公司的目标定位于中小企业市场，提供基于固网智能化、互联网、移动通讯网络的统一通信平台，在业界已有不小的名声。

信令设计 篇5

在多种犯罪预防的手段中, 通信社交圈的分析[1]是重要手段之一, 通过对指定人员通信行为的分析, 分析人员可以达到以下目的:1.关键人员定位;2.协同人员挖掘;3.人员行为梳理 (了解事件发生顺序) 。反恐领域的特殊性导致了其对通信社交圈分析有诸多硬性需求。首先, 用来分析的数据应当尽量全面;其次, 分析速度要快;最后, 对社交圈分析所需的软硬件需求应尽量低, 从而适合大规模推广。

当前, 我国的基层民警大多使用人工的方式进行社交圈分析, 在进行分析之前需要从相关运营商调取人员通信记录, 通过对记录的分析确定下一批待分析的人员名单, 然后再次调取这些人的通信记录, 周而复始。这种人工分析的方式速度缓慢, 分析一个通信行为较活跃人员几小时的通信行为甚至需要一至两天的时间。同时, 人工分析使得分析人员极易疏漏重要信息, 使得分析结果的可靠度下降。虽然当前也存在一些自动化分析软件[2], 但这些软件都无法很好的解决数据来源以及处理问题, 这给用户的使用带来了不便。

为克服传统人工分析方式以及现有软件的不足, 本文所设计的系统以a接口与Abis接口信令[3,4]产生的话单数据作为分析基础, 通过对话单数据的采集、预处理、存储以及分析来生成人员通信社交圈, 有力地提高了分析的速度与准确度并很好地解决了数据的采集以及处理问题。

利用开源软件搭建云服务是现今系统架构的趋势[5,6,7], 本系统采用HBase与HDFS等开源软件搭建了能够为用户提供在线社交圈分析的云服务系统。

1 功能分析

根据本人对目标用户需求的调研, 分析人员在进行社交圈分析时存在以下使用场景:

(1) 已明确目标群体 (多于一人) 并对群体内人员的信息有所了解, 需要查看群体内人员在某一时间范围内的社交行为从而推测事件发生顺序。

(2) 已有明确的目标 (任意数量) , 但不清楚是否还有其他协同人员, 故而需要对某一时间范围内目标人员的短信以及通话联系人进行分析;

针对上述场景, 本系统为社交圈分析提供了两种使用模式:

(1) 针对场景1, 本系统提供组内分析模式。组内分析模式仅对指定的目标人员间的行为进行检索, 生成的社交圈中仅包含指定的目标人员以及他们之间的联系, 分析人员可通过查看社交圈来推断事件的发生顺序。

(2) 针对场景2, 本系统提供组外分析模式。组外分析模式可以对指定的人员进行全量的通信行为检索, 生成的社交圈中包含分析人员指定的目标人员、目标人员的直接联系人以及上述所有人之间的联系, 分析人员可通过查看社交圈来推断目标人员是否还有其他协同人员;

除以上两种可供选择的分析模式外, 分析人员还可以在分析时指定是否只查看短信行为和是否只查看通话行为。

2 关键问题

2.1 数据存储空间

本系统需在海量数据存储的基础上才能运行, 这就要求本系统能够存储足够大量的数据。以浙江某城市为例, 该城市每天产生20G的数据, 而一次社交圈分析至少需要使用30 天的数据才能产生有意义的分析结果。

2.2 业务响应时间

本系统作为在线分析系统, 响应时间的长短对用户体验有重要影响, 响应时间越短, 用户体验越好。本系统在响应时间上存在以下难点:

数据量大, 数据检索时间长。本系统在进行分析之前需要对大量数据进行检索, 如果没有有效的优化措施, 分析业务将在数据检索环节耗费大量时间。

每次分析需要进行多次数据检索。由于本系统针对业务的特殊性, 每次社交圈分析都需要对数据进行多次检索。从以上章节流程说明可见, 除多起始点组内模式外, 其他所有分析都要从起始点开始, 通过起始点的检索才能确定下一次检索的条件, 因此至少需要两次检索。在数据量本就很大的前提下, 多次检索无疑会进一步增加数据检索阶段的耗时。

无法有效利用缓存机制来减少每次检索的耗时。在本业务中, 不仅多个分析请求的起始点间没有关联, 单个分析过程内的多个检索条件也没有明显关联, 整个业务有明显的数据量大、数据复用率低的特点, 因此缓存机制对检索速度的提升没有明显效果。

3 系统设计与实现

3.1 系统结构设计

图1 给出了系统静态结构设计, 根据子系统功能的不同, 系统可划分为话单采集子系统、数据存储子系统、社交圈分析子系统以及前端展示子系统以及管理平台。

其中, 话单采集子系统负责接收信令监测系统发送来的话单数据并对话单数据进行预处理。数据存储子系统负责存储经过了预处理的话单。社交圈分析子系统负责社交圈分析的业务逻辑, 根据用户的业务请求对数据存储子系统中的数据进行分析, 分析结果交由前端展示子系统返回给用户。前端展示子系统是本系统与用户进行交互的接口, 负责分析请求的接收、分析结果的展示等, 前端展示子系统在收到社交圈分析子系统提供的分析结果后, 会将经过了数据可视化处理的数据展现给用户。系统各部分具体功能如下:

(1) 话单采集子系统

话单采集子系统是所有数据的入口, 负责接收和预处理来自信令监测系统的话单数据。话单采集子系统内部分为话单预处理模块与话单采集模块, 话单采集模块定期接收来自信令监测系统的话单数据, 话单预处理模块对接收到的话单进行预处理, 经过处理的数据交由数据存储子系统进行存储。

话单采集模块:话单采集模块负责定期接收来自信令监测系统的数据, 二者使用FTP服务进行数据传输。话单采集模块对接收到的数据进行解压缩操作后交给话单预处理模块进行话单预处理。

话单预处理模块:话单预处理负责对接收到的话单文件进行预处理, 包括无效话单过滤以及关键信息提取。由于采集来的话单可能以不同格式存在, 话单预处理模块还具备对多格式的兼容功能, 其接受指定格式的多种数据, 输出统一格式的数据交由数据存储子系统进行存储。

(2) 数据存储子系统

数据存储子系统是本社交圈分析系统的核心子系统之一, 所有话单数据都存储在其中。话单数据因其数据量大、 随机读取性能要求的特点而存储在HBase[8,9]数据库中。

话单数据:话单数据是经过话单采集子系统预处理的数据, 是本社交圈分析系统的核心数据, 话单数据中包含主被叫号码, 业务发生时间、时长以及业务相关数据。

(3) 社交圈分析子系统

社交圈分析子系统是本社交圈分析系统的业务核心, 负责对数据存储子系统中的数据进行分析, 所有与业务相关的逻辑都由社交圈子系统完成。社交圈子系统在分析结束后, 将完整的社交圈交给前端展示子系统。在与数据存储子系统的交互中, 数据存储子系统只进行数据检索, 数据的分析、汇总以及下一轮查询的查询条件都由社交圈分析子系统完成。

(4) 前端展示子系统

前端展示子系统是本系统与最终用户的接口, 所有与用户的交互都由本子系统完成。在交互部分, 前端展示子系统的功能包括用户注册、用户登录、用户账号信息修改以及用户社交圈分析请求的收集, 收集来的分析请求会交由社交圈分析子系统进行进一步处理。

3.2 数据存储子系统数据结构设计

由于话单数据的数据量大、分析业务对话单随机读取的性能要求高, 故而本系统采用HBase存储话单数据。然而, HBase是列存储性Key-Value数据库, 仅可对row key进行排序和索引 (自动执行) , 有效话单无法直接存储到HBase中去。虽然HBase只有一种固定的索引, 但这种索引在HBase的运行中十分高效, 合理利用这一点可以在避开检索条件单一这项缺点的同时最大化HBase的随机读取性能, 因此, row key的设计就成为了数据结构设计的重点。

一个好的row key设计应当能达到以下目的:

(1) 分散数据, 尽量避免访问热点的出现。HBase集群中的每台服务器节点都保存有一部分的数据, 多节点同时进行数据检索时可以充分发挥系统性能, 相反, 若查询只集中在某几个节点上, 则会严重降低系统性能, 导致业务响应时间的提高。

(2) 减少查询所需时间。可以通过两种途径达到减少查询时间的目的:减少查询次数与减少单次查询所需时间。

在对本系统的业务进行分析后可知, 手机号码与业务开始时间必然出现在检索条件之中, 且对手机号码的检索分为两种情况:全量查询与指定查询。全量查询是指查询与指定单个号码相关的所有数据, 发生在起始点查询阶段;指定查询是指查询两个号码间的通信数据, 发生在直接联系人查询阶段。显然, 指定查询可用全量查询实现, 实现方式为对两个号码中的任意一个进行全量查询, 再以另一个号码对查询结果进行过滤。鉴于过滤操作可以方便地通过HBase提供的filter实现, 故而本系统便以全量查询的方式实现指定查询。

本系统中, row key由单个号码和该次通信的开始时间作为row key, 二者以符号“|”分隔, 其格式为

MDN|start_time

在对话单数据进行存储时, 每条话单中的主被叫分别作为MDN一次, 生成两份话单数据, 同时向数据中插入一个标示通信方向的属性, 数据流程如图2, 数据库中数据结构如表1。

流程说明:

(1) 提取有效话单中的主叫号与开始时间, 按照MDN|start_time的格式组成row key , 同时添加direction列以标示业务的通信方向, 有效话单中的其他数据被放在各自的列中, 数值不变。

(2) 提取有效话单中的被叫号码与开始时间, 按照MDN|start_time的格式组成row key, 同时添加direction列以标示业务的通信方向, 有效话单中的其他数据被放在各自的列中, 数值不变。

在进行数据查询, 全量查询与指定查询两种查询方式需要使用不同的查询命令。

全量查询

全量查询使用scan操作对row key进行检索, 在scan操作中指定row key的起始行与结束行。例如, 查询号码13813800000 在2015 年10 月1 日0 点0 分至2015 年10 月10 日10 点10 分间的通信数据, 就可以使用如下命令在HBase中进行查询

指定查询

指定查询同样使用scan操作, 与全量查询不同的是, 这类查询需要在参数中指定所使用的filter。例如, 查询号码13813800000 与13813811111 在2015 年10月1 日0 点0 分至2015 年10 月10 日10 点10 分间的通信数据, 就可以使用如下命令在HBase中进行查询

由于社交圈分析业务的特殊性, 每次检索的号码都可认为是随机的, 因此以MDN作为row key的起始可以有效分散数据, 避免热点的出现。同时, 这种row key设计最大化利用了HBase对row key的排序机制, 极大优化了单次查询的效率。

3.3 话单采集子系统实现

Python语言能够很容易地实现对文本以及文件系统的操作, 在字符串格式化、移动文件以及删除文件上具有很强的能力, 同时, Python还拥有众多第三方库供调用, 可以实现FTP操作、解压缩操作以及对HDFS的操作等, 本系统使用Python语言实现话单采集子系统。

话单采集子系统以FTP客户端的方式从信令监测系统获取原始信令, 为避免数据的重复下载和遗漏, 约定信令监测系统将话单数据以统一的命名方式存储在固定的目录下, 话单采集子系统中以话单类型、地理位置以及时间的格式保存下载记录, 通过比较信令采集系统中的文件名与下载记录来判断是否有新的数据需要下载。话单文件下载后, 通过逐行读取文件并将有效数据写入新文件的方式生成系统使用的话单文件, 话单文件写入完成后即调用HBase的批量导入功能将数据写入HBase数据库。

3.4 社交圈分析子系统实现

社交圈分析子系统由Java实现, 其运行流程如下:

(1) 接收社交圈分析请求, 根据请求中的内容确定第一次查询所需的查询条件。;

(2) 进行第一次查询, 若为组内分析模式, 则直接跳至步骤4;若为组外分析模式, 则将其中所有人员列为待查人员;

(3) 依次对所有待查人员进行数据查询, 查询条件与步骤1 类似;

(4) 汇总所有数据, 提取数据中的人员关系生成社交圈, 社交圈以二维数据的形式表达, 其中包含人员间的联系、联系类型以及联系次数;

(5) 将生成的社交圈输出至至前端展示子系统。

4 结论

本文给出了较完整的系统实现, 通过对分布式技术的合理利用, 以低成本解决了海量数据的存储与分析问题, 同时, 对第三方信令监测平台的合理利用解决了同类社交圈分析产品数据获取困难的问题。

摘要：随着国际反恐形式的不断严峻, 通信社交圈的获取与分析逐渐成为预防恐怖行动的重要手段之一。为满足社会对通信社交圈进行分析的需求, 本文利用分布式存储技术以及分布式运算技术, 通过对电信信令数据的分析获取人员通信社交圈, 社交圈中的信息可以帮助分析人员快速锁定目标、了解事件发生顺序。与此同时, 本文合理利用了开源软件的特性, 有效降低了系统的开发与维护成本, 适合于大范围推广。本文给出了较为完整的社交圈分析系统的设计方案, 并通过进一步实现证明了方案的可行性。

关键词：计算机应用技术,信令,社交圈分析,分布式

参考文献

[1]刘霞.基于电信通话记录的数据挖掘[J].计算机与现代化, 2008 (6) :36-38.

[2]王洋.多格式通信记录分析软件的设计与实现[D].天津:南开大学, 2011.

[3]邬丽芬, 张治中, 代琦.TD-SCDMA网络Iu-CS接口CDR合成监测设计与实现[J].电视技术, 2011, 05:109-112.

[4]黄璇婧.信令采集与监测系统研究和应用[D].上海:上海交通大, 2011.

[5]李冠辰.一个基于hadoop的并行社交网络挖掘系统[J].软件, 2013, 34 (12) :127-131.

[6]姜福成.云计算的基础结构设计和云应用服务[J].软件, 2014, 35 (7) :97-102.

[7]陈韶男.基于云计算的企业车辆监控管理平台的设计[J].软件, 2014, 35 (8) :104-109.

[8]Chang, Fay.Bigtable:A distributed storage system for structured data[J].ACM Transactions on Computer Systems (TOCS) , 2008.

信令设计 篇6

为了充分发挥安全防范技术在各项公安业务中的支撑作用,促进安全防范技术与公安业务工作的紧密融合,在全国范围内开展了城市报警与监控系统建设“31 1 1”试点工程。为避免“3111”工程中软硬件资源的重复建设,在各个系统之间实现互连互通,特制定了《城市监控报警联网系统技术标准》系列标准,为平安城市视频信息的综合应用打下了坚实的基础。以开放性、分布性和综合性为主要特征的下一代网络(NGN)正在实现多网合一、IP承载、业务接口开放、数据和多媒体传输等,为互连互通提供了必要的网络物理环境。

在此基础上,视频监控系统实现互连互通需要网络控制协议。SIP(Session Initiation Protocol)作为基于Internet环境的一种信令控制协议,突破了H.323协议集中、层次控制的传统设计思想,其核心思想是邀请新成员加入一个已经存在的会话或创建一个新的会话,各成员之间可以通过组播、单播或两者结合的方式进行交互,从而具有可扩展性、灵活性、互操作性、可重用性等多种优良特性。因此,SIP信令天然适合IP视频监控系统大规模联网、分布式部署、智能化监控的要求,是视频监控系统信令机制发展的必然趋势。

2 视频监控中信令系统的特点及现状

监控系统作为通信系统的一种,采用相应的信令机制使系统内所有设备协同工作,使系统正常运行。信令系统是通信网的神经系统,是通信网必不可少的重要组成部分。信令是一种机制,通过这种机制,构成通信网的用户终端,各个业务节点可以相互交换各自的状态信息和提出对其他设备的接续要求,从而使网络作为一个整体运行。

监控系统的发展趋势是大规模联网、分布式部署、智能化监控,这就要求相应的信令机制的特点如表1所示。

但是,目前的监控系统各厂商自成体系,没有统一的信令标准,无法互连互通,难以实现大规模组网。监控信令标准化是必然趋势,相关行业标准《城市监控报警联网系统技术标准》正在制定中。SIP协议具有简单易用、移动性好、可扩展性好等优势,采用SIP信令作为监控控制信令已成业界共识。目前业界已实现SIP协议的厂商很少,实现了SIP的厂商也只是采用SIP承载私有协议,所以,视频监控系统中的SIP信令系统的设计和互连互通将是各个厂商要突破的关键技术。

3 SIP信令的控制模式和分布式架构

SIP协议的通信方式是一个分布的、客户机/服务器(Client/Server,C/S)、水平的控制结构,采用多点控制单元(MCU)或全互连的方式代替组播发起多方呼叫,透明地支持名字映射和重定向服务,分为呼叫信令、注册信令和重定向信令等模块[1],通过其他相关或独立的协议体系提供其他相关或独立的功能和业务。其采用C/S结构的消息机制,对呼叫的控制是将控制信息封装到消息的头域中,通过消息的传递来实现。因此,SIP系统的终端比较智能化,不只提供数据,还提供呼叫控制信息,其他各种服务器则用来进行定位、转发或接收消息。这样,SIP将网络设备的复杂度推向了网络终端设备,因此更适于构建智能型的用户终端。其分布式架构如图1所示。

SIP是一个分层结构的协议,其行为根据一组平等独立的处理阶段来描述,每一阶段之间只是松耦合。协议分层描述是为了表达从而允许功能的描述可在一个部分跨越几个元素,某元素包含某层是指它顺从该层定义的规则集。SIP通信步骤:1)登记,发起和定位用户;2)进行媒体协商,通常采用SDP方式来携带媒体参数;3)由被叫方来决定是否接纳该呼叫;4)呼叫媒体流建立并交互;5)呼叫更改或处理如呼叫转移;6)呼叫终止。

4 SIP信令系统的最小实现设计

数字视频监控系统实现SIP信令的协商和控制,由视音频编码器、视音频解码器、SIP服务器、媒体服务器及客户端等主要组件构成。充分分析网络视频监控的需求,该信令系统采用信令控制与媒体流交换分离的机制,监控系统中的音视频流不由SIP服务器集中管理,而通过网络的处理交换以分布式形式分发至媒体服务器,避免了处理媒体流的性能压力而造成系统瓶颈,从而可实现监控规模的无限制扩展。信令体系整体框图见图2。

4.1 注册和注销信令

视频编解码器采用REGISTER的方法进行注册和注销。按照安全的级别分类,分为符合标准的认证注册、基于口令的双向认证注册和基于数字证书的双向认证注册。REGISTER方法的头域WWW-Authenticate和Authorization来实现双向认证。WWW-Authenticate的值为Digest时,携带realm和nonce参数,Authorization的值为Digest;Authorization的值为Digest时,携带username,realm,nonce,uri,response和algorithm 6个参数。其流程信令如图3所示。

4.2 实时媒体点播信令

实时点播采用INVITE方法实现会话连接,采用RTP/RTCP实现媒体传输,如图4所示。实现媒体点播时,应考虑单域点播和跨域点播两种情况。单域内点播是目标设备的实时媒体流通过本域内的媒体服务器转发给视频编码器;跨域点播是域内实时媒体流的转发与单域内点播相同,域间实时媒体流通过不同域内的媒体服务器进行转发[2]。INVITE,200 OK,ACK及BYE中携带的请求和应答消息体采用SDP协议。z发送给媒体服务器的消息的消息头应包括Subject字段,该字段表示媒体服务器的媒体传输路径中前一跳设备、后一跳设备的设备编码和媒体流序列号。信令体系框图图如图4所示。

4.3 报警控制信令

报警事件通知和转发的信令采用MESSAGE协议,消息头字段Content-type为Application/MANSCDP+XML。XML消息体由命令类型(CmdType)、命令序列号(SN)、设备编码(DeviceID)、报警级别(AlarmPriority)、报警时间(AlarmTime)、报警方式(AlarmMethod)等构成。MESSAGE消息头增加一个扩展的消息头Event来区别报警的类型。信令体系框图如图5所示。

5 小结

SIP以其简单、可扩展、灵活等特点已成为当今网络研究与应用开发的热点,SIP技术在VoIP等领域取得较快的发展[3]。笔者结合公安领域项目开发的经验,针对当前安防视频监控的发展趋势,在充分研究数字网络视频监控和SIP技术的基础上阐述了SIP信令系统的设计方案,满足了网络监控市场蓬勃发展的需求,尤其适用于大规模的城域监控,对今后开发数字安防系统具有借鉴作用。

摘要：针对现有视频监控系统的状况及特点，探讨了如何实现视频监控领域内大范围的互连互通，最大限度地进行资源共享。在深入研究会话启动协议(SIP)的基础上，根据制定的《城市监控报警联网系统技术标准》，提出了数字网络视频监控系统中SIP信令系统的设计方法．为“平安城市”的建设提供技术方案。

关键词：SIP协议,数字网络视频监控,“3111”试点工程,信令机制

参考文献

[1]白建军，彭晖，田敏．SIP揭密[M]．北京：人民邮电出版社，2003：108-141．

[2]城市监控报警联网系统技术标准第五部分：信息传输/交换/控制技术要求[S]．2008．

信令设计 篇7

1 需求及关键问题分析

1.1 需求

系统具备交通拥堵状况信息的自动识别功能,可以分析出拥堵路段。分析出拥堵区域和即将进入拥堵区域的人群,向其发送拥堵原因解释或绕行建议信息,并提供交通突发事件的事件预警信息。系统识别用户移动信令数据、交通状况必须有较高准确率,在应对交通拥堵的同时避免扰民。

1.2 关键问题分析

1.2.1 预测模型组合及决策、发布过程

(1)路段平均速度模型——路段通行能力(天气、节假日、历史数据);

(2)路段话务量行为分析(用户、位置、变化曲率);

(3)路段、基站出入流量的平衡判断(入流量、出流量、平衡曲线);

(4)信息发布及流程。

1.2.2 车辆识别与容量模型问题

(1)路边停靠的车辆、相关服务区、高速旁边省道、超市、菜市场、小区用户等问题的存在,需要进行用户剔除;

(2)同一时刻路段上行驶的车辆(且被准确识别)数量超过多少辆满足基本的预测容量。

1.2.3 数据预处理及数据纠错、弥补

(1)重复数据(1车n车)如何识别和处理;

(2)错误数据如何识别和处理;

(3)部分字段数据缺失如何识别和处理。

1.2.4 交通状态判断标准模型

(1)交通拥挤的相关指标超过什么阀值才需要交通管理者进行干预或进行相关预警;

(2)需要对“拥堵路段”进行分析和预警,必须有拥堵评价规则体系。

1.2.5 路段划分与基站静态位置

(1)对道路进行路段划分是路段平均速度估计的前提和基础;

(2)用子路段的平均速度就可以较合理地表现整条道路当前的交通状态。

1.2.6 数据采集及时间间隔模型分析

间隔太小,车辆的运行位置及状态只有微小的改变或不变。间隔大,将漏掉许多重要数据,影响分析效果。

2 关键模型及算法

2.1 数据采集及时间间隔模型分析

若采集间隔太小,车辆的运行位置及状态只有微小的改变,甚至不变(受基站覆盖范围和切换的快慢影响),同时大量数据传输、处理会增加数据采集成本及加大“信令共享平台”接口负荷。若数据采样时间间隔增大,虽然可以降低采集成本,但同时也将漏掉许多重要数据,这会降低对车辆及其行驶路径的跟踪精度,影响道路交通运行状态的监控效果。系统数据采集周期应可以配置,可根据实际情况或相关经验进行调整。

2.2 车辆识别与容量模型分析(识别目标群体)

由于信息共享、路边停靠的车辆、相关服务区、高速旁边省道、超市、菜市场和小区用户等问题的存在,需要进行用户剔除,精确目标群体。Ruey Long Cheu等人利用Intergation仿真软件的研究结果表明:若路段平均速度的允许误差小于5Km/h,欲达到95%的估计准确率,则需同一时刻路段上行驶的车辆(且被准确识别)数量超过10辆。所以,需要进行用户剔除规则配置和采集车辆容量配置,确保提高分析的准确度。

2.3 数据预处理及数据纠错、弥补模型分析

由于信号盲区、通信故障等原因,采集的数据不可避免地存在一些故障,为了保证数据的可靠性,针对数据可能存在的问题,需要对异常数据进行识别或修复。如重复数据、错误数据、部分字段缺失数据等。

2.4 车辆方向的判断模型及算法分析

基于2个以上基站相对位置的判断方法:通过经过基站A、B的时间,如T2>T1,以及基站静态位置的方向关系来判定。如图1所示。

2.5 交通状态判断标准模型及算法分析

有些交通波动会在道路的瓶颈处产生短时的车辆排队,但这种车辆排队往往能够自行缓解。那么到底什么程度才算是交通拥挤?交通拥挤的相关指标超过什么阀值才需要交通管理者进行干预或进行相关预警?对高速“拥堵路段”进行分析和预警,必须有拥堵评价规则配置。可以考虑采用聚类分析法等国际成熟模型、算法进行分析。

2.6 路段划分与基站静态位置分布模型分析

对道路进行路段划分是估计路段平均速度的前提和基础。对于一条实际的道路,必然会存在十字路口、弯道、信号灯等会引起道路车流明显变化的道路基础设施。若是将整条道路看作一个整体进行估计,得到的结果必然会存在较大误差,所以,应以基础设施信息为依据对道路实行合理的路段划分,分别考察车流在各个路段上的行驶情况,才能获得较为合理的交通状态信息。

采用路段划分技术把道路分成若干个虚拟的子路段,再分别得出各个子路段的平均速度,用子路段的平均速度就可以较合理地表现整条道路当前的交通状态。

2.7 路段平均速度模型及算法分析

定义路段R1,并且包括基站{A0,A1,A2,A3…An},且A0至A1的固定距离为L1,当车C,从进入A0基站T0时刻,到切换至A1时为T1,则V1=L1/(T1-T0)。当经过n个切换后,得到该车在R1路段的平均速度为:。

2.8 路段、基站出入流量的平衡判断

进出某个区域的基站出入流量在统计上是平衡的,当某个区域基站出入流量不均等,则可以认为存在交通突发事件的可能性。区域基站出入流量平衡曲线如图2所示。

2.9 预测模型组合及决策、发布过程

影响因素的抽象、分解、组合,具体如下。

影响因素:平均速度(天气、节假日、历史数据)、话务量(用户、位置、变化曲率)、流量(入流量、出流量、平衡曲线);

其他判断因素:如主叫号码是122、120、110、119等用户行为进行进一步判断是否为突发事件或拥堵严重;

信息发布及流程:拥堵信息发布流程、突发事件预警发布流程、目标人群确认流程、短信通知发布流程。

3 系统实现方案

3.1 系统架构

系统架构图如图3所示。

3.2 业务功能模块

系统功能:包括接口域、配置域、模型域、展现域、平台域等功能模块。

接口域:负责采集信令数据以及与第三方系统的交互。

配置域:负责系统静态信息的配置以及维护。主要包括拥堵级别配置、路段库配置、综合调度类配置、基站库配置、环境变量配置、出入路口配置、收费站信息配置、黑白名单配置、任务周期配置和预警信息配置等配置功能。

模型域:系统的主体部分,负责数据清洗、交通拥堵预测等任务。主要包括数据挖掘模型、干扰识别模型、业务模型、重要参数管理、事件库管理和异常管控等功能模块。

展现域:负责交通拥堵信息展示等系统展示功能,主要包括GIS及门口展示、掌上应用两大功能模块。

平台域:主要包括短信发送平台、规则决策平台、报表平台、移动应用平台等模块。

4 结语

基于移动信令分析的交通流量实时监控系统的建立,能够对交通状况、突发事件及时监控、预测、报警,及时发送交通状况信息,进而对车辆进行正确疏导,及时制定应急预案,对即将进入拥堵路段的车辆及时分流,使交通资源得到合理配置,缓解交通拥堵状况具有很强的现实意义。未来打造基于该扩展架构的能力平台,在各行业进行推广应用,如交通行业、旅游景区、学校、商场、医院和体育场馆等。

摘要：基于手机信令的分析技术建设交通流量实时监控及交通状况发布系统,系统通过IF2接口从移动信令监测共享平台获取信令数据并对数据进行分析,根据用户话单数据分析及路段定义计算出路段行驶速度,根据预先设置的门限产生路段拥堵状态,通过短信、多媒体等方式将交通信息及时推送给目标用户,及时避免拥堵,提高出行效率。

关键词：信令,模型分析,算法

参考文献

[1]周蔚吾.城市道路交通畅通化设计技术[M].北京:知识产权出版社,2013.

[2]交通运输部道路运输司.城市交通拥堵治理实践[M].北京:人民交通出版社,2013.

[3]陆化普,王长君,陆洋.城市交通拥堵机理与对策[M].北京:中国建筑工业出版社,2014.

[4]戴维·R·安德森.数据、模型与决策[M].北京:机械工业出版社,2003.

[5]Dorian Pyle.业务建模与数据挖掘[M].北京:机械工业出版社,2005.

信令设计 篇8

关键词：移动安全,用户信息,协议栈,短信抹除,采集系统

引言

近二十年来, 移动通信已从第一代模拟语音通信发展到以高速数据传输和宽带多媒体服务的第三代移动通信。然而移动通信的广泛应用在给人们带来便利的同时, 也带来安全问题, 如手机银行欺诈、扣费病毒软件、各类垃圾信息等[1]。为有效防范和处置用户信息安全隐患, 在开发测试、统计分析、投诉处理和精确营销等活动中, 需要对提取的用户信息 (如通信信息, 包括语音、短信、彩信和GPRS详单, 内含主叫号码、主叫位置、被叫号码、开始通信时间、时长、流量、金额等信息) 进行模糊化处理, 降低安全风险, 避免批量泄露[2]。

在现网监测和维护中, 信令监测系统要求实时高效处理海量的信令数据, 而一部分信令数据包含了用户信息。例如, SMS (短消息服务, Short Message Service) 消息携带了用户短信内容, 在不影响系统整体性能的的前提下必须对用户数据部分进行处理, 为此, 论文提出了短信抹除方案并实现了用户数据的屏蔽。

1 短信抹除原理

GSM网络Abis接口的短信业务承载信令的协议栈[3如图1。层一是基于硬件的底层驱动程序, 接收和发送数据至传送的物理链路[3];层二是LAPD (D信道链路接入协议, Link Access Protocol of D-Channel) 协议;层三是BTSM (基站收发信台管理, Base Transceiver Station Management) , 部分消息由该实体处理。短信业务相关消息属于非接入层协议—SMS[4,5]。它包含两个子层:RP和TP, 其中短信的内容由TP的SMS Submit和SMS Deliver携带, 前者用于MT (手机接收, Mobile Terminating) 短信过程, 后者用于MO (手机发送, Mobile Originating) 短信过程。短信内容都包含在TP-User-Data字段中。

系统将识别到的原始信令中两种消息的TP-UserData字段用同一个字母覆盖 (比如‘E’) , 然后将修改后数据转发到相应端口, 即可实现短信内容的屏蔽。

2 方案设计

信令监测系统主要采用三层结构:采集层, 共享层, 应用层。采集层主要负责以不同的采集方式从各个接口采集和预处理信令数据;信令处理共享层主要负责对数据进行解码和CDR合成、完成相关的统计分析信息;应用层主要完成对信令共享数据的调用和呈现以及是实现与用户的交互, 也可以扩展其他业务功能[6]。理论上, 在采集系统和信令处理系统中植入抹除模块都可实现短信内容抹除。若在解码器里设计抹除模块, 解码过程除了对数据解析还需处理短消息, 使得采集层和共享层功能划分不明确;此外, 信令处理系统复杂不易纠错, 读入数据需要进行队列操作, 增加系统开销, 降低系统性能。

因此, 在采集系统里进行短信抹除。采集系统对于捕获到的每个数据包都会调用抹除模块进行处理, 对处理速度提出了很高的要求。需要每秒能处理10万个以上的数据包。因此, 除了提取必要的信息外, 应采用跳指针的方式, 尽快判别本包是不是Abis接口短信包, 如果是, 则进行短信抹除;如果不是则立即返回。

2.1 SMS消息识别

SMS消息属于层3信息, 自下而上由LAPD和BTSM承载。LAPD层有固定的帧结构, BTSM层则需根据消息组识别消息。

根据BTSM协议规范可知, 该层依据信道将各类消息分成4组, 分别为无线链路层管理消息、专用信道管理消息、公共信道管理消息和TRX管理消息。SMS消息由无线链路层的数据请求和数据指示消息携带[7,8]。

2.2 外部函数接口设计

模块外部接口为Erase SMS (void*p Data, intn Length, intn Offset) , 其中p Data指向3.0数据包的包头, 为Packet_Header_NGN30结构体, n Length为p Data指向的内存块的长度, 为包括消息头和消息体的数据的长度, n Offset表示SMS包包头相对于原始信令LAPD包头的偏移量。从缓冲区取出的数据含3.0数据包头24字节, 因此, 传进的参数n Offset设为24。

2.3 内部函数接口设计

把Erase SMS过程中, 需要的各个步骤编写为比较独立的小函数, 比如判断是否是LAPD?是否是BTSM?是否是SMS?定义一套本函数体系, 逐个编码完成。

在模块内部设计3个函数接口, 分别为CheckBTSMWi thLAPD、Check SMSWithBTSM和Erase。Check BTSMWith LAPD过程判断数据是否为Abis接口数据包, 依据采集卡的板卡类型和链路类型即可实现Abis口消息的判别。识别出Abis口消息, 根据LAPD层帧类型指针跳3或4个字节。在BTSM层调用Check SMSWith BTSM, 依据消息组和消息类型识别携带SMS消息的数据。当消息组为1同时消息类型值为1或2时有可能携带sms消息。跳过BTSM层, 取出层3信息的消息类型值, 如果为9, 则为sms消息。短信内容抹除流程如图2。其中, TPVP是否存在, 都需要计算TP用户数据真实长度。

3 测试方法

3.1 功能测试

在采集系统中添加抹除模块, 当系统每收到一条消息就调用一次Erase SMS接口。测试流程从单条数据到多条数据进行。

(1) 单条数据测试

在NGN在线监测系统中, 查询携带SMS信息的消息, 以其中一条消息的ID号为依据, 单步跟踪调试消息, 初步检查方案的准确性;

(2) 多条数据测试, 把经过抹除模块的所有消息ID输出到一个文件下

在程序中单步跟踪消息ID号这种方法是有限而且低效的, 因此, 在确保跟踪的消息成功处理短信内容后, 需要查询大量的消息是否含有SMS信息。本测试方法中, 数据经过Erase SMS处理后, 记录有可能抹除短信内容的消息ID, 同时将ID输出到一个txt文件中。

在NGN仪表中过滤出SMS消息, 与文件的消息ID比较。在文件中, 随机抽取ID作进一步检查。经多次测试, 消息中有些不含有用户数据而误抹除了, 必须修正方案。

(3) 多次生成文件, 修正误抹除的短信

在多数据测试阶段记录误抹除的短信ID, 继续单步调试, 在被叫过程中添加TP类型指示是否为2判断条件, 重新生成txt文件。使用Beyond Compare对比两次生成的文件, 证实新增判断条件的可靠性。此外, 用户有效数据由长度指示决定, 用户内容可能比长度指示长, 在抹除操作前, 必须进行用户数据长度判断。当实际数据内存块的长度小于或等于传进的数据包长度时, 抹除短信内容;否则, 保护当前的数据, 不做任何处理。

3.2 性能测试

进行短信抹除模块性能测试, 要选取最能体现其性能的指标[9]。本文采用系统执行时间作为性能指标。为方便查看消息, 在分层设计模块接口时, 编写打印信息代码, 但系统处理3.03G的数据需要90分钟, 系统运行效率很低, 而不添加该类信息, 系统处理完相同大小的数据只需5分钟。因此, 在处理LAPD和BTSM层时, 如果判断出不是当层消息, 则立即返回, 无需打印任何信息。

此外, 以携带SMS信息的消息为查询目标, 估算可能出现SMS消息的最短长度, 在Erase SMS过程过滤出包长度大于14的包, 提高系统运行速率。

4 结果分析

图3是ID号为56968的原始消息数据截图。从图中可以看出, 该条消息存在短信息内容, 从0x C3到0x03共计54字节。

图4是从内存中取出的短信息内容。以内存地址0x1F9BD4B4为起始地址, 取出54字节长度的数据。从截图看出, 地址从0x1F9BD4B4到0x1F9BD4E6这一内存块数据与图3的短信内容一致。

图5是短信内容抹除后截图。从0x C3到0x03共54字节置0。特别指出, 部分SMS消息的短信内容含有包头, 在不影响信令解码的前提下, 本文将其一并置0。图6是短信内容含有5字节包头的SMS消息, 图7是相应的短信抹除截图。

5 小结

为防止短信TP用户数据泄露, 在Abis接口信令监测系统中, 笔者设计了短信抹除模块。论文根据GSM网络Abis接口协议栈分层设计模块接口, 采用跳指针的方法逐层编码。系统选择VS2010开发环境编码调试, 结合Beyond Compare工具从功能和性能两方面进行测试确保方案的准确可靠。模块已用于信令监测系统的采集子系统中, 经现网测试, 系统运行稳定。

参考文献

[1] 陈桂香, 姜劲蕾.世界移动通信安全与合法截听规制[J].中国安全防范认证, 2011:50-55

[2] 中国移动客户信息安全保护技术要求[EB/OL].http://wenku.baidu.com/view/47b6a544a8956bec0975e353.html. (2012-04) .2013-06-03

[3] 华为技术有限公司.M900/M1800基站子系统信令分析手册[J].2003

[4] ETSI TS 124 011 v4.1.1 (2002-06) .Digital cellular telecommunications system (Phase 2+) ;Universal mobile telecommunications system (UMTS) ;Point-to-Point (PP) short message service (SMS) support on mobile radio interface (3GPP TS 24.011 version 4.1.1 Release 4) [EB/OL].http://www.etsi.org/deliver/etsi_ts/124000_124099/124011 /04.01.01_60/ts_124011v040101p.pdf.2013-06-03

[5] ETSI TS 123 040 v4.9.0 (2004-09) .Digital cellular telecommunications system (Phase 2+) ;Universal mobile telecommunications system (UMTS) ;Technical realization of short message service (SMS) (3GPP TS23 .040 version 4.9.0 release 4) [EB/OL].http://www.etsi.org/deliver/etsi_ts/123000_123099/123040/04.09.00_60/ts_123040v040900p.pdf.2013-06-03

[6] 夏颖, 张治中.CDMA2000系统信令监测方案设计[J].数字通信, 2009, 5:73-76

[7] ETSI TS 100 596 v7.1.0 (1999-07) .Digital cellular telecommunications systems (Phase 2+) ;Base station controller–Base transceiver station (BSC-BTS) interface;Layer 3 specification (GSM 08.58 version 7.1.0 release1998) [S]

[8] ETSI TS 100 940 v7.8.0.Digital cellular telecommunications systems (Phase 2+) ;Mobile radio interface layer 3specification (GSM 04.08 version 7.8.0 release 1998) [S].2000, 10

信令中继系统的研究 篇9

信令系统是用户话机与交换机之间及交换机和交换机之间控制接续、协调工作, 完成呼叫接续所使用的一种通信语言。从最早步进制交换局采用的直流脉冲信令, 到纵横制交换局采用的多频互控信令, 到程控交换局采用的公共信道信令——NO.7信令。信令系统容量增大, 传送效率更快, 而且可以传送除电路接续信令外的各种业务的控制信令和数据, 从而推动了通信网向智能化、综合化和个人化的发展。

中继是交换局与交换局之间或中心局与模块局之间相连采用的连接方式, 它们之间连接的线路称为中继线路。中继线路中传送的数据包括话路信号及各种控制信令。

2中继数据

交换局之间要实现电话互通, 硬件上要满足:局间数字中继板使用中继电缆相连接;局内数字中继板与协议处理板的设置;中继数据的设置。这里以华为数字程控交换机C&C08为例, 介绍如何实现局间电话互通。

2.1 局间数字中继板的连接

C&C08数字中继板 (DTM) 可以提供2个E1接口, 能提供75Ω和120Ω两种中继电缆, 通过DTM板上的开关不同的拨法, 来进行阻抗匹配不同的中继电缆。交换局内中继电缆一端由中继板E1接口引出, 另一端引入机房数字配线架上, 通过传输设备与对端交换局中继板相连。

2.2 数字中继板与协议处理板设置

根据局间信令方式的区别, DTM板可以设置为不同的类型。比如, 采用七号信令方式, 将DTM板配置成TUP;采用ISDN方式, 将DTM配置为ISUP;采用一号信令方式, 将DTM配置成DT等。局间实现七号中继时, 协议处理板需配LAPN7板或NO7板, 其中LAPN7提供4路链路, NO7提供2路链路;实现一号中继时, 需配MFC板, 完成多频信号的接收和发送。

2.3 中继数据相关概念

中继数据包括七号信令中继数据、中国一号信令中继数据、PRA中继数据、V5中继数据及模拟中继数据等。中继数据涉及的概念包括:局向, 目的信令点, 路由和子路由, 路由选择源码和路由选择码。

局向是两个交换局之间若存在直达话路, 则两个交换局互称为一个局向。目的信令点是从本局信令点角度出发, 在本局信令点所在的所有信令网络中可见的信令点。其中, 有直达信令链路的称为相邻信令点;没有直达信令链路但有直达话路的称为非相邻信令点。若两个交换局间有直达的话路, 则认为它们之间存在一条子路由。路由选择源码是针对不同的呼叫源, 在不同的出局路由选择策略上的分类产生, 路由选择源码与呼叫源相对应。路由选择码是指不同的出局字冠, 在出局路由选择策略上的分类号, 路由选择码与呼叫字冠相对应。

3中继数据的设置

本节主要介绍七号中继数据的设置, 七号中继数据涉及到中继话路部分及七号链路数据部分。七号信令的中继数据设定原则为:先做链路部分, 再做话路部分, 并且应严格按照先后次序进行。

3.1 中继准备数据

在设置中继数据之前, 应设置相关的准备数据, 包括设置呼叫源和设置时间索引。

呼叫源是用户或中继群的集合, 同一呼叫源中的用户及入中继有着相同呼叫属性。使用命令:ADD CALLSRC, 增加呼叫源码。时间索引值在路由分析中参与路由的选择, 从而达到动态选择路由的目的。时间索引值为默认值, 一般不需修改。使用命令:ADD TMIDX, 进行设置。

3.2 七号中继链路数据

在做好中继准备数据后, 接着进行七号链路数据的配置, 设置顺序如下进行:设置本局信息 (SET OFI) →增加MTP (消息传递部分) 目的信令点 (ADD N7DSP) →增加MTP链路集 (ADD N7LKS) →增加MTP路由 (ADD N7RT) →增加MTP链路 (ADD N7LNK) 。

3.3 七号中继话路数据

中继话路数据的设置顺序为:增加局向 (ADD OFC) →增加子路由 (ADD SRT) →增加中继群 (ADD N7TG) →增加中继电路 (ADD N7TKC) →增加路由 (ADD RT) →增加路由分析 (ADD RTANA) →增加被叫字冠 (ADD CNACLD) 。

4中继系统故障处理

4.1 中继系统常见故障现象

根据故障的性质, 中继系统常见故障的现象可分为:中继电路异常, 具体表现为:电路状态显示为故障、闭塞、未知、未安装等异常状态;中继电路维护异常, 具体表现为:不能对中继电路执行闭塞、解除闭塞、复原等维护操作;信令链路异常, 具体表现为:断链、链路不稳定、链路阻塞、链路拥塞等;局间信令配合异常, 具体表现为:不能接续、主叫号码发送异常等。

4.2 中继系统故障产生的常见原因

引起中继、信令系统故障的常见原因主要有以下几种:1) 传输故障。传输中断、误码率高。由于中继线接触不良或阻抗不匹配所引起的通话噪音、七号链路不稳定;鸳鸯线。由于两对中继线相互岔接或局间CIC电路号对错引起局间通话占用这些中继时出现单通或不通话。2) 交换机硬件故障。包括中继硬件故障, 如数字中继板、协议处理板故障等;中继HW线配线异常;相关硬件系统故障, 如主节点板、主处理机板及交换网板故障引起中继系统故障。3) 局间信令配合或对端局问题。包括局间电路识别码CIC不匹配, 造成TUP/ISUP电路未知;信令链路编码SLC不匹配, 造成信令链路出现不稳定等。4) 交换机数据设置错误问题。包括中继电路数据未配置;主叫号码相关数据设置不当;电路增益设置不当;系统参数设置不当等。

4.3 中继故障处理思路

维护人员能通过告警信息、维护台控制面板、对端局申告、用户申告、话务统计信息等途径判断中继故障, 进而能判断故障原因, 定位故障, 根据原因检查相关硬件配线、倒换或更换单板、检查数据配置等方式处理故障。

5总结

一个完善的信令系统是保障电信网正常运行, 完成交换网络中任意用户之间通信的重要部分, 它是通信网的神经系统, 熟悉并掌握中继数据的设置与故障分析排除, 是实现交换局间互通的必要条件。

参考文献

[1]刘华东.现代通信技术实用全集[M].宁夏:宁夏人民出版社, 2007.