网络信令分析.docx

1、网络信令分析1.1网络信令分析1.1.1技术框架图1.1.2信令数据接口接口编码接口名称描述94001信令用户短信收发消息从信令中产生的用户收发短信的记录94002信令用户终端更换记录用户终端更换记录94003信令用户开关机频次记录用户开关机频次记录94004信令用户开关机时间统计用户开关机时间统计94005信令用户小区滞留时间统计用户小区滞留时间统计94006信令关键用户移动轨迹关键用户移动轨迹94007信令基站人流量分析基站人流量分析94008信令基站间人流量分析基站间人流量分析94009信令用户动态通信行为信息用户动态通信行为信息1.1.3信令数据处理要求【数据量与处理性能】据调研，信令

2、数据的量大约是清单的4-10倍，【接口方式】文件接口方式。【数据同步时限】理应比清单接口的频率还要高，规范要求在15分钟之内。【数据处理流程】信令接口文件主要经过数据采集、分发，并行处理、并行分析、并行更新视图、并根据触发规则判断是否需要触发实时营销。1.1.4功能模块序号模块名称功能描述1信令获取实时性要求比较高，且必要严格按照时间顺序。这只能采用单进程方式，降低采集间隔时间的方式，接口协议仍然为FTP2信令分发事先为每个分析模块建立一个信令通道。信令分发模块每读取一条信令，根据信令类型，分发到一个或多个对应的“快速通道”的队列中。3信令分析处理每个分析模块轮询读取相应的“快速通道”，根据获

3、取的信令进行一定的计算，并更新“用户信令状态图”和“基站信令视图”。1.1.5软件部署整个软件部署可与ETL流程调度部署在同一主机上，也可单独部署。1.1.6存储周期信令数据由于其自身特点，更新快，因此无须保存很久。“用户信令状态视图”和“基站信令视图”只需要保留当前最新信息即可，而其它接口信息根据实际需要设置最大保存时间即可。信令数据采集原理1.2网络信令分析在经营分析系统中引入实时/准实时的网络信令数据将进一步丰富系统应用能力。它可以帮助市场管理和营销人员更为准确的把握用户的行为特征，实现基于事件的营销，为网络规划优化、发现新的业务机遇提供必要的数据支持。Teradata公司在网络信令应用

4、方面有较为成熟的解决方案，拥有在国外运营商NIW的成功部署经验。基于本公司既有经验，并结合中国移动NG-BASS1规范要求，Teradata提出如下方案建议。 4.8.1 技术框架图网络信令分析方案的体系架构如图所示。为了降低投资，提高现有设施的利用率，建议复用现有的小区短信系统和信令监测系统做为获取信令信息的数据源（即信令采集子系统）。信令采集子系统从移动网络中采集A接口、A-bis接口、Gb接口等的原始信令数据，对原始信令进行初步解码和处理，然后按照中国移动省级NG1-BASS技术规范源系统接口分册中规定的接口要求传送到经营分析系统的信令处理服务器，对所需信令进行筛选、归并、拼接，然后将实

5、时营销信令触发数据送到TCRM渠道网关互动网关，将待分析数据送到加载服务器加载入数据仓库系统。依据数据时限要求不同，信令数据可以通过两种加载方式：实时/准实时加载、定时加载。实时/准实时加载通过读取消息队列加载数据入库，定时加载通过批量文件方式加载数据入库。信令数据经信令分析模块处理后用于实现上层应用，包括营销管理子系统、信令分析应用和对现有分析应用的增强扩展。在全程精确营销过程中，营销管理子系统（TCRM）将活动的白名单或缺省用户群规则传送到渠道网关互动网关，当与营销活动相关的实时信令数据被实时传送到渠道网关互动网关时，触发外部执行过程。有关TCRM与渠道网关互动网关的功能介绍请参见有关章节

6、。另一方面营销管理子系统支持将审核后的营销活动白名单、采集区域设置（Cell ID或MSC ID）等采集控制信息输出到信令处理模块与信令采集子系统（小区短信系统或信令监测系统），优化信令数据的采集量，减轻信令采集系统、网络和加载服务器的负荷。图4.8.1信令采集技术框架图4.8.2 信令采集内容和容量估算原始信令数据量估算主要采集用户位置更新信令、用户附着网络/去附着信令、呼叫接续信令、raw-CDR等。原始信令数据处理流程如下图所示。图4.8.2信令处理数据流图1.DXC将MSC信令收敛后,传送给信令采集服务器，DXC最大输出速率=采集板卡数*端口数/板卡*端口速率，假设信令采集服务器通畅的

7、忙闲系数为0.4，则采集服务器最大输入速率=DXC最大输出速率*0.4；2.信令采集服务器采集数据后,将全部数据打包送给信令采集子系统的信令处理服务器，信令处理服务器对信令进行拆包解码，并按业务需要进行处理，输出ss7解码后信令消息，如用户附着、位置区更新、路由区更新、呼叫建立、释放、切换、会话建立与或原始话单，并送到经营分析系统端的信令处理服务器。3.经营分析系统端的信令处理服务器根据业务需要选择一定的规则对数据进行过滤，拼接，实时触发数据直接送营销管理平台渠道网关互动网关实现全程精确营销，非实时数据加载到数据仓库用于实现信令分析等应用。输出数据规模直接与业务规则相关，例如营销活动的活动名单

8、，营销活动的区域等。输出数据量=实时营销触发数据+信令分析数据4.以某200万用户的地区为例，共60块采集卡，则信令采集子系统信令处理服务器最大输入速率=60块采集卡*8个端口*2M/s*0.4(忙闲系数)=384M/s=1.3T/H。5.为减轻经分系统信令处理服务器负荷，建议信令采集子系统的信令处理服务器尽可能的完成信令初步筛选处理，降低输出数据量。 汇总入库数据量估算NG-BASS1中规定的源系统接口内容及估算，存储周期为1个月。使用参数：1500万用户，1.4*109条短信，每用户平均每天出入20个小区，每日70%用户会有开关机操作，小区数为1万，每个小区的邻小区为6个。数据接口容量估算

9、估算方法用户短信收发消息10.3G该类消息与短信话单存在重复，因此不在仓库存放，仅将其中的LAC地址和Cell标识填入现有的短信话单中，用于改进区域化管理中的相关算法。月新增容量为8byte*月短信话单量。1.4*109*8用户终端更换记录10G用户开关机频次记录6.45G22byte*用户数*70%*30天。用户开关机时间统计26.82G32byte*用户数*2条/天*30天用户小区滞留时间统计293G与各地平均用户运动特征和网络覆盖范围有关。35byte*20个小区*30天*用户数。关键用户移动轨迹268G32byte*用户数*20个小区*30天基站人流量分析1.28G假设15分钟每小区一

10、条记录，假设小区数为1万。48byte*24*30*小区数*4基站间人流量分析1.6G假设15分钟每小区一条记录，每小区6个邻小区，小区数为1万。40byte*24*30*小区数*6(邻小区数)*4总计约为600G/月网络信令数据量异常庞大，任何一项信令数据的采集开启都会对网络交换机、DCN、信令采集子系统、信令处理模块带来巨大的处理压力，同时需要占用大量的容量存储，因此在信令数据的引入前期，本公司建议采用以需求为驱动的接口采集方式。具体而言，包括以下几类降低采集压力和存储压力方式可供选择：实时营销类数据将客户分析及运营模块中市场分析和营销策划阶段形成的规则传递到信令采集子系统，用于筛选出所需

11、的触发信令，然后再将筛选后数据送入执行触发环节。数据分析类数据根据分析需求不同，可以采用抽样、指定用户抽样方式降低数据量。另外部分分析并不需要持续每月进行，例如用户滞留小区分析，可以将采集量较大的接口错月轮流采集。4.8.3 接口方式提供批量文件接口方式和实时消息两种方式。实时消息方式可以基于消息平台实现，消息平台基于规范所要求的tcp/udp网络协议之上实现。4.8.4 数据处理流程数据仓库系统的数据加载的策略是根据具体的数据特征制定的。Teradata 为网络信令数据提供两种数据加载策略：批量文件加载、消息实时加载两种。具体数据流程和处理模块如图所示。图4.8.4-1实时信令处理流程实时信

12、令处理流程图4.8.4-2实时信令处理流程在实际应用中，应根据营销活动的需求，设置信令的筛选处理规则和实时要求，并综合规划所有营销活动、网络信令分析所需要的信令处理作业，提供不同的处理时限。4.8.5 应用功能模块Teradata 的网络数据仓库解决方案可以提供以下功能。图4.8.5-1 Teradata NIW 解决方案根据NG-BASS1规范要求，将首先考虑以下应用的建设：图4.8.5-2 中国移动信令分析解决方案图应用数据存储周期建议与现有应用相同，采用6+1方式。1.3网络信令分析方案网络信令分析主要有以下的难点：1.数据量大，对存储的要求以及写入效率等会有极高的要求2.要求具有实时性

13、，因此对于处理的效率会产生比较严格的要求3.各种处理过程中的逻辑比较复杂，如果设计不好，会产生大量重复的计算，极大的加大计算量因此，为了解决上述的问题，提出了基于管道过滤器模式的技术架构，并且支持分布式、伸缩性，以及规则的扩展性等。网络信令分析系统的架构设计原则：1.充分考虑对于数据仓库的影响。在数据仓库中尽量存储尽可能少的数据，并且尽可能减少或者更好的组织对于数据仓库的访问。2.系统扩展性的考虑：满足信令处理需求复杂多变的情况。在有新的信令处理需求时，尽可能在不重起系统，不重新部署的情况下进行处理。3.处理效率的考虑：尽可能减少重复的处理和不必要的查询等；尽可能利用宿主系统的系统特性（比如一

14、些数据存储或者处理的特性）；4.系统伸缩性的考虑：通过支持分布式和并行能力的方式满足系统得伸缩性要求。1.3.1方案总体介绍网络信令分析系统的技术框架如上图中所示。 1.信令采集系统为网络信令分析系统提供网络信令。一般有网络厂商单独建设。2.数据仓库用以存储网络信令分析得到的结果，供上层应用使用。3.网络信令分析系统由信令过滤分发系统合信令处理系统和信令处理系统组成。信令分发过滤系统：由于信令数据量大，并且有一定的实时要求，因此只靠单个的进程甚至单台设备可能无法完成信令数据的处理。因此，在进行架构设计的时候允许用户采用多个节点进行信令的并行处理。这里所说的节点，在实现中对应的是主机。信令处理系

15、统：完成从输入的单条的信令数据到得到最终需要的信令分析结果的全过程，也是整个系统中最为复杂的部分。得到的结果中需要保存的部分都写入到数据仓库中。网络分析中的数据流图如下图所示：1.3.2对于信令采集系统的要求在本方案中不包含对信令采集系统的设计及实现。信令采集系统一般由网络厂商实现。信令数据类型及格式要求一般来说，信令采集系统的接口传输内容应包括：用户开机、关机、主叫开始、主叫挂机、被叫开始、被叫挂机、发送短信、接收短信、位置变更等行为信息和用户当前所在位置区LAC_ID，小区代码CELL_ID，IMSI、IMEI等属性信息。具体接口传输内容可参考下表，根据本地实施情况具体确定。属性编码属性名

16、称属性描述类型备注01city_id本地网标识CHAR(3)本地网标识02Report_type报告类型CHAR(1)报告类型1：语音报告2：收发短信报告3：VLR报告03SMS_TYPE短信类型NUMBER(3)只对收发短信报告有效。（0：mosm发、2:mtsm收）04VLR_Report_ReasonVLR报告类型NUMBER(5)只对VLR报告有效:1 = 正常位置更新2 = 周期性位置更新3 = Imsi attach（手机开） 4 = Imsi detach （手机关）05MSISDNMSISDNVARCHAR2(18)报告的手机号码，只对收发短信报告和VLR报告有效。06A_CE

17、LLA_CELLNUMBER(5)语音报告的主叫的CELL，对收发短信报告和VLR报告为报告的CELL07A_IMEIA_IMEINUMBER(16)语音报告的主叫的IMEI ，对收发短信报告和VLR报告为报告的IMEI08A_IMSIA_IMSINUMBER(16)语音报告的主叫的IMSI，对收发短信报告和VLR报告为报告的IMSI09A_LACA_LACNUMBER(5)语音报告的主叫的LAC，对收发短信报告和VLR报告为报告的LAC10B_CELLB_CELLNUMBER(5)语音报告的被叫CELL，对收发短信报告和VLR报告无效。11B_IMEIB_IMEINUMBER(16)语音报告

18、的被叫IMEI，对收发短信报告和VLR报告无效。12B_IMSIB_IMSINUMBER(16)语音报告的被叫IMSI，对收发短信报告和VLR报告无效。13B_LACB_LACNUMBER(5)语音报告的被叫LAC，对收发短信报告和VLR报告无效。14A_DIRECTION_NUMBERA方向号码VARCHAR2(32)语音报告及收发短信报告的主叫，对VLR报告无效。15B_DIRECTION_NUMBERB方向号码VARCHAR2(32)语音报告及收发短信报告的被叫，对VLR报告无效。16REPORT_TIME报告生成时间TIMESTAMP(19)产生报告的时间, 24小时制，YYYY-MM

19、-DD HH:MM:SS信令采集系统信令提供方式要求信令采集系统可以采用文件接口方式或者实时接口方式提供信令数据。具体的实现方式根据当地实现情况确定。1.3.3信令过滤分发系统的设计信令过滤分发系统的作用是对信令采集系统得到的信令进行初步的过滤，转换，清洗，并分发到信令处理主机上的各个处理节点。根据需要，也可以在该系统中实现原始信令的存储。对于有些省份的信令采集系统，本身就支持信令的分发，这样就可以不再重复实现信令分发系统。一般可以支持不同IMSI段的信令通过不同的UDP端口进行发送。信令分发的规则也就是信令分发系统向信令处理系统的各个节点上分发信令的规则。由于每个用户信令的统计结果具有时间依

20、赖性（比如要计算一个用户在小区的停留时间，需要用户进入小区的时刻），如果一个用户可以在不同的节点上进行处理，就会造成节点之间的耦合，需要在节点之间交换数据，造成网络流量的增大，并增大设计的复杂度。因此，分发的规则应该能够保证同一个用户的信令始终被分发到同一个节点上。在信令中，对用户是通过IMSI来进行标识的。因此，通过划分不同的IMSI段，或者通过具有某种特征的IMSI（比如满足某种形式的正则表达式），被分发到相同的节点上。在确定分发规则时，应该确保分发到各个节点上的信令量在一定程度上达到平衡。信令原始数据的存储由于信令的数据量比较大，因此在数据仓库中尽量只存储业务有意义的信令分析结果数据，以

21、及一些营销的用户接触数据（将来如果有对于营销活动过程中其他指标进行监控的数据，可能也会要求写入到数据仓库中）。而在数据仓库中不存储原始的信令数据。可以在信令分发系统保存信令的原始数据。原因是如果通过信令处理系统进行保存，可能会使信令的存储分散在系统的多台设备上，会对将来的一些分析或者应用造成不便；并且信令分发系统的压力相对较小，不会增加信令处理系统的压力。信令原始数据建议以文件的形式进行保存。存储的周期可以根据规范的要求，结合当地的业务需求以及存储设备的状况确定。存储的目录结构设计及命名规范、文件的划分等结合本地情况制定。信令过滤分发系统与其他系统的接口方式信令过滤分发系统与信令采集系统的接口

22、形式由信令采集系统的信令提供方式的实现确定。一般来说可以以文件方式或者实时方式（如通过Socket）实现。信令过滤分发系统与信令处理接口的实现通过scoket方式实现。1.3.4信令处理系统的设计信令处理系统完成信令的处理，得到信令分析的结果，并会将结果写入到数据仓库中。为了信令系统的伸缩性，信令系统可以分布在多台主机上执行；在同一台主机上，可以有不同的处理单元（一般对应进程或者不同的线程）并行。信令处理系统由以下四层组成：信令获取层，功能层，处理层，以及数据层。1.3.4.1信令获取层的设计接收信令过滤分发系统分发的数据（在没有实现信令过滤分发系统的时候，是接收信令采集系统的信令），并将其进

23、行缓存，供处理。1.3.4.2功能层的设计是对信令处理系统中的一些常用功能进行封装。功能模块主要有：数据仓库操作模块和缓存操作模块，以及信令处理数据库封装模块。数据仓库操作模块主要是对于数据仓库的操作功能的封装。这一方面，可以适应不同的数据库的类型；另一方面，可以适应不同的数据仓库的写入机制。信令处理数据库操作模块在信令处理的过程中，存在大量的查询、检索等的过程。为了简化系统开发的难度，提高系统开发效率，信令处理系统采用数据库存储各种信令分析的历史信息及一些分析结果。信令处理数据库操作模块的目的就是封装对于信令处理数据库的操作，以便数据库的选型的变化不影响上层逻辑的实现。缓存操作模块有多种不同

24、的对数据进行缓存的技术。本模块的目的就是封装数据缓存操作功能，以使得数据缓存技术不同的选择，不影响上层业务。1.3.4.3处理层的设计对信令进行处理。一般来说，处理层会有一系列并行的处理单元，每个处理单元中都有一个信令处理线程或者进程。并行的处理单元的形式和数目，根据本地情况确定。处理层有由数据仓库同步模块和一系列的信令处理器组成。信令处理器又包括用户信令视图处理器，基站信令视图处理器，客户网络使用情况处理器，基站人流量处理器，用户停留时间处理器等。根据用户业务需要，可以进一步添加不同的处理器。用户信令视图处理器作用是对输入的信令进行处理，更新用户的信令视图。用户信令视图中保存用户信令的历史信

25、息，主要内容有：IMSIMSISDN用户的基本信息（品牌，年龄层次等）最后一次信令的时间用户的开关机状态当前所在的小区用户进入当前小区的时间用户的最新的IMEI等等基站信令视图处理器作用是对输入的信令进行处理，并更新基站的信令视图。基站的信令视图中保存的是基站信令的历史信息，主要内容有：基站中的用户数基站当前时段的通话人数基站当前时段的通话时长基站当前时段的通话次数基站当前时段的计费时长等等客户网络使用情况处理器作用是通过对输入的信令的分析，结合用户信令视图信息，更新客户网络使用情况统计表。基站人流量处理器作用是通过对输入的信令的分析，结合基站信令视图信息，更新基站人流量统计表。用户停留时间处

26、理器作用是通过对输入的信令进行分析，结合用户信令视图信息，更新用户在某小区的停留时间表。数据仓库同步模块该模块的作用是将信令处理系统中的分析结果定期向数据仓库中同步。信令处理系统是一个实时处理的系统。为了尽可能减小对于数据仓库的冲击，信令处理系统每隔一定时间才向数据仓库中同步一次变化了的处理结果。同步的时间间隔可以根据当地情况确定，一般说来，应该在1分钟或者1分钟以上，但应该小于规范中所要求的15分钟。向数据仓库中同步的内容应该只包含分析的最终结果的变化部分。对于分析所需的中间结果，如用户信令统一视图和基站信令统一视图等，建议不向仓库中更新。信令处理流程1.3.4.4数据层的设计用以存储处理层

27、处理得到的结果以及一些处理过程中需要的一些中间结果。为了简化开发的难度，提高开发的效率，建议数据层采用数据库来进行存储和操作。数据库可以选用通用数据库（如MySQL）或者内存数据库。建议选用内存数据库，推荐使用Asiainfo的MDB或者Oracle的TimesTen。1.3.5系统的部署信令分析系统的部署图如上面所示。说明：1、信令采集系统一般由网络信令厂商开发和部署。2、信令处理系统中采用数据库来进行数据的存储和检索。信令处理数据库根据本地情况，可能单独部署，也可能部署在某一个信令处理主机或者信令过滤分发系统主机上。3、信令处理主机根据本地的情况，可能采用一台或者一台以上的主机。4、部署图

28、中的各个接口实现的方式说明：（1）信令采集系统和信令过滤分发系统之间的接口。可以采用文件接口或者实时接口（如Socket等）实现。（2）信令过滤分发系统与信令处理主机之间的接口。采用实时接口实现。（3）信令处理主机和信令处理数据库之间的接口。采用ODBC或者数据库提供的SDK开发包实现。（4）信令处理主机和数据仓库之间的接口。采用ODBC或者数据库提供的SDK开发包实现。1.4网络信令分析给出网络信令分析的详细技术框架图，阐明信令数据类型、数据量与处理性能、接口方式、数据同步时限、数据处理流程、功能模块、软件部署等。说明结果数据的类别和存储周期。网络信令分析是NG1-BASS本期建设的内容之一

29、，本期广东移动在经营分析系统中的全程精确营销平台引入了网络信令接口和网络信令分析应用。目前已接入地市A接口数据。广东移动经营分析系统网络信令分析应用遵循了集团公司NG1-BASS规范实现，图4-8-1是集团公司NG1-BASS关于网络信令分析功能的框架图：图4-8-1网络信令分析流程网络信令数据通过业务支撑网中的信令采集子系统实时向经营分析系统发送SOCKET报文信息，通过经分系统的CMP信令采集模块获取信令数据，并设定每N（可配置，当前设置为10分钟）分钟生成一个数据文件，以文件接口的方式接入经分系统。经分通过装载模块加载信令数据，经由调度模块产生作业链，对加载的数据进行计算分析，此过程通过

30、全程精确营销系统关系数据库的存储过程实现。整个网络信令分析过程采用广东移动经分系统通用的作业流程进行处理。1.4.1系统组网结构系统组网结构图如下图所示：图4-8-2 网络信令长连接的通信流程双方（此处所说双方指全程精确营销与信令采集系统，下文同）采用SOCKET方式，信令解码服务器作为服务端，精确化营销系统接口机作为客户端。服务端与客户端之间进行信息交互时，采用长连接方式。所谓长连接，指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要客户端发链路检测包以维持此连接。通信双方以客户-服务器方式建立TCP连接，用于双方信息的相互提交。当信道上没有数据传输时，客户端应每隔时间C发送链路检测包以维持此连接，如果连续发送N-1次后都未得到响应则断开此连接。 参数C、N原则上应可配置，现阶段建议取值为：C=2分钟， N=10。 任何一方都可以关闭一个TCP连接，要求双方发送一个终断消息信号关闭自己的通讯信道。一方可以在另一方之前关闭。或者双方同时关闭TCP连接。1.4.2通信交互过程