网络信令分析.docx
《网络信令分析.docx》由会员分享，可在线阅读，更多相关《网络信令分析.docx（30页珍藏版）》请在冰豆网上搜索。
网络信令分析
1.1网络信令分析
1.1.1技术框架图
1.1.2信令数据接口
接口编码
接口名称
描述
94001
信令用户短信收发消息
从信令中产生的用户收发短信的记录
94002
信令用户终端更换记录
用户终端更换记录
94003
信令用户开关机频次记录
用户开关机频次记录
94004
信令用户开关机时间统计
用户开关机时间统计
94005
信令用户小区滞留时间统计
用户小区滞留时间统计
94006
信令关键用户移动轨迹
关键用户移动轨迹
94007
信令基站人流量分析
基站人流量分析
94008
信令基站间人流量分析
基站间人流量分析
94009
信令用户动态通信行为信息
用户动态通信行为信息
1.1.3信令数据处理要求
【数据量与处理性能】
据调研，信令数据的量大约是清单的4-10倍，
【接口方式】
文件接口方式。
【数据同步时限】
理应比清单接口的频率还要高，规范要求在15分钟之内。
【数据处理流程】
信令接口文件主要经过数据采集、分发，并行处理、并行分析、并行更新视图、并根据触发规则判断是否需要触发实时营销。
1.1.4功能模块
序号
模块名称
功能描述
1
信令获取
实时性要求比较高，且必要严格按照时间顺序。
这只能采用单进程方式，降低采集间隔时间的方式，接口协议仍然为FTP
2
信令分发
事先为每个分析模块建立一个信令通道。
信令分发模块每读取一条信令，根据信令类型，分发到一个或多个对应的“快速通道”的队列中。
3
信令分析处理
每个分析模块轮询读取相应的“快速通道”，根据获取的信令进行一定的计算，并更新“用户信令状态图”和“基站信令视图”。
1.1.5软件部署
整个软件部署可与ETL流程调度部署在同一主机上，也可单独部署。
1.1.6存储周期
信令数据由于其自身特点，更新快，因此无须保存很久。
“用户信令状态视图”和“基站信令视图”只需要保留当前最新信息即可，而其它接口信息根据实际需要设置最大保存时间即可。
信令数据采集原理
1.2网络信令分析
在经营分析系统中引入实时/准实时的网络信令数据将进一步丰富系统应用能力。
它可以帮助市场管理和营销人员更为准确的把握用户的行为特征，实现基于事件的营销，为网络规划优化、发现新的业务机遇提供必要的数据支持。
Teradata公司在网络信令应用方面有较为成熟的解决方案，拥有在国外运营商NIW的成功部署经验。
基于本公司既有经验，并结合中国移动NG-BASS1规范要求，Teradata提出如下方案建议。
4.8.1技术框架图
网络信令分析方案的体系架构如图所示。
为了降低投资，提高现有设施的利用率，建议复用现有的小区短信系统和信令监测系统做为获取信令信息的数据源（即信令采集子系统）。
信令采集子系统从移动网络中采集A接口、A-bis接口、Gb接口等的原始信令数据，对原始信令进行初步解码和处理，然后按照《中国移动省级NG1-BASS技术规范源系统接口分册》中规定的接口要求传送到经营分析系统的信令处理服务器，对所需信令进行筛选、归并、拼接，然后将实时营销信令触发数据送到TCRM渠道网关互动网关，将待分析数据送到加载服务器加载入数据仓库系统。
依据数据时限要求不同，信令数据可以通过两种加载方式：
实时/准实时加载、定时加载。
实时/准实时加载通过读取消息队列加载数据入库，定时加载通过批量文件方式加载数据入库。
信令数据经信令分析模块处理后用于实现上层应用，包括营销管理子系统、信令分析应用和对现有分析应用的增强扩展。
在全程精确营销过程中，营销管理子系统（TCRM）将活动的白名单或缺省用户群规则传送到渠道网关互动网关，当与营销活动相关的实时信令数据被实时传送到渠道网关互动网关时，触发外部执行过程。
有关TCRM与渠道网关互动网关的功能介绍请参见有关章节。
另一方面营销管理子系统支持将审核后的营销活动白名单、采集区域设置（CellID或MSCID）等采集控制信息输出到信令处理模块与信令采集子系统（小区短信系统或信令监测系统），优化信令数据的采集量，减轻信令采集系统、网络和加载服务器的负荷。
图4.8.1信令采集技术框架图
4.8.2信令采集内容和容量估算
●原始信令数据量估算
主要采集用户位置更新信令、用户附着网络/去附着信令、呼叫接续信令、raw-CDR等。
原始信令数据处理流程如下图所示。
图4.8.2信令处理数据流图
1.DXC将MSC信令收敛后,传送给信令采集服务器，DXC最大输出速率=采集板卡数*端口数/板卡*端口速率，假设信令采集服务器通畅的忙闲系数为0.4，则采集服务器最大输入速率=DXC最大输出速率*0.4；
2.信令采集服务器采集数据后,将全部数据打包送给信令采集子系统的信令处理服务器，信令处理服务器对信令进行拆包解码，并按业务需要进行处理，输出ss7解码后信令消息，如用户附着、位置区更新、路由区更新、呼叫建立、释放、切换、会话建立与或原始话单，并送到经营分析系统端的信令处理服务器。
3.经营分析系统端的信令处理服务器根据业务需要选择一定的规则对数据进行过滤，拼接，实时触发数据直接送营销管理平台渠道网关互动网关实现全程精确营销，非实时数据加载到数据仓库用于实现信令分析等应用。
输出数据规模直接与业务规则相关，例如营销活动的活动名单，营销活动的区域等。
输出数据量=实时营销触发数据+信令分析数据
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个。
数据接口
容量估算
估算方法
用户短信收发消息
10.3G
该类消息与短信话单存在重复，因此不在仓库存放，仅将其中的LAC地址和Cell标识填入现有的短信话单中，用于改进区域化管理中的相关算法。
月新增容量为8byte*月短信话单量。
1.4*109*8
用户终端更换记录
<10G
用户开关机频次记录
6.45G
22byte*用户数*70%*30天。
用户开关机时间统计
26.82G
32byte*用户数*2条/天*30天
用户小区滞留时间统计
293G
与各地平均用户运动特征和网络覆盖范围有关。
35byte*20个小区*30天*用户数。
关键用户移动轨迹
268G
32byte*用户数*20个小区*30天
基站人流量分析
1.28G
假设15分钟每小区一条记录，假设小区数为1万。
48byte*24*30*小区数*4
基站间人流量分析
1.6G
假设15分钟每小区一条记录，每小区6个邻小区，小区数为1万。
40byte*24*30*小区数*6（邻小区数）*4
总计
约为600G/月
网络信令数据量异常庞大，任何一项信令数据的采集开启都会对网络交换机、DCN、信令采集子系统、信令处理模块带来巨大的处理压力，同时需要占用大量的容量存储，因此在信令数据的引入前期，本公司建议采用以需求为驱动的接口采集方式。
具体而言，包括以下几类降低采集压力和存储压力方式可供选择：
Ø实时营销类数据
将客户分析及运营模块中市场分析和营销策划阶段形成的规则传递到信令采集子系统，用于筛选出所需的触发信令，然后再将筛选后数据送入执行触发环节。
Ø数据分析类数据
根据分析需求不同，可以采用抽样、指定用户抽样方式降低数据量。
另外部分分析并不需要持续每月进行，例如用户滞留小区分析，可以将采集量较大的接口错月轮流采集。
4.8.3接口方式
提供批量文件接口方式和实时消息两种方式。
实时消息方式可以基于消息平台实现，消息平台基于规范所要求的tcp/udp网络协议之上实现。
4.8.4数据处理流程
数据仓库系统的数据加载的策略是根据具体的数据特征制定的。
Teradata为网络信令数据提供两种数据加载策略：
批量文件加载、消息实时加载两种。
具体数据流程和处理模块如图所示。
图4.8.4-1实时信令处理流程
实时信令处理流程
图4.8.4-2实时信令处理流程
在实际应用中，应根据营销活动的需求，设置信令的筛选处理规则和实时要求，并综合规划所有营销活动、网络信令分析所需要的信令处理作业，提供不同的处理时限。
4.8.5应用功能模块
Teradata的网络数据仓库解决方案可以提供以下功能。
图4.8.5-1TeradataNIW解决方案
根据NG-BASS1规范要求，将首先考虑以下应用的建设：
图4.8.5-2中国移动信令分析解决方案图
应用数据存储周期建议与现有应用相同，采用6+1方式。
1.3
网络信令分析方案
网络信令分析主要有以下的难点：
1.数据量大，对存储的要求以及写入效率等会有极高的要求
2.要求具有实时性，因此对于处理的效率会产生比较严格的要求
3.各种处理过程中的逻辑比较复杂，如果设计不好，会产生大量重复的计算，极大的加大计算量
因此，为了解决上述的问题，提出了基于管道——过滤器模式的技术架构，并且支持分布式、伸缩性，以及规则的扩展性等。
网络信令分析系统的架构设计原则：
1.充分考虑对于数据仓库的影响。
在数据仓库中尽量存储尽可能少的数据，并且尽可能减少或者更好的组织对于数据仓库的访问。
2.系统扩展性的考虑：
满足信令处理需求复杂多变的情况。
在有新的信令处理需求时，尽可能在不重起系统，不重新部署的情况下进行处理。
3.处理效率的考虑：
尽可能减少重复的处理和不必要的查询等；尽可能利用宿主系统的系统特性（比如一些数据存储或者处理的特性）；
4.系统伸缩性的考虑：
通过支持分布式和并行能力的方式满足系统得伸缩性要求。
1.3.1方案总体介绍
网络信令分析系统的技术框架如上图中所示。
1.信令采集系统为网络信令分析系统提供网络信令。
一般有网络厂商单独建设。
2.数据仓库用以存储网络信令分析得到的结果，供上层应用使用。
3.网络信令分析系统由信令过滤分发系统合信令处理系统和信令处理系统组成。
●信令分发过滤系统：
由于信令数据量大，并且有一定的实时要求，因此只靠单个的进程甚至单台设备可能无法完成信令数据的处理。
因此，在进行架构设计的时候允许用户采用多个节点进行信令的并行处理。
这里所说的节点，在实现中对应的是主机。
●信令处理系统：
完成从输入的单条的信令数据到得到最终需要的信令分析结果的全过程，也是整个系统中最为复杂的部分。
得到的结果中需要保存的部分都写入到数据仓库中。
网络分析中的数据流图如下图所示：
1.3.2对于信令采集系统的要求
在本方案中不包含对信令采集系统的设计及实现。
信令采集系统一般由网络厂商实现。
信令数据类型及格式要求
一般来说，信令采集系统的接口传输内容应包括：
用户开机、关机、主叫开始、主叫挂机、被叫开始、被叫挂机、发送短信、接收短信、位置变更等行为信息和用户当前所在位置区LAC_ID，小区代码CELL_ID，IMSI、IMEI等属性信息。
具体接口传输内容可参考下表，根据本地实施情况具体确定。
属性编码
属性名称
属性描述
类型
备注
01
city_id
本地网标识
CHAR（3）
本地网标识
02
Report_type
报告类型
CHAR
（1）
报告类型
1：
语音报告
2：
收发短信报告
3：
VLR报告
03
SMS_TYPE
短信类型
NUMBER（3）
只对收发短信报告有效。
（0：
mosm发、2:
mtsm收）
04
VLR_Report_Reason
VLR报告类型
NUMBER（5）
只对VLR报告有效:
1=正常位置更新
2=周期性位置更新
3=Imsiattach（手机开）
4=Imsidetach（手机关）
05
MSISDN
MSISDN
VARCHAR2（18）
报告的手机号码，只对收发短信报告和VLR报告有效。
06
A_CELL
A_CELL
NUMBER（5）
语音报告的主叫的CELL，对收发短信报告和VLR报告为报告的CELL
07
A_IMEI
A_IMEI
NUMBER（16）
语音报告的主叫的IMEI，对收发短信报告和VLR报告为报告的IMEI
08
A_IMSI
A_IMSI
NUMBER（16）
语音报告的主叫的IMSI，对收发短信报告和VLR报告为报告的IMSI
09
A_LAC
A_LAC
NUMBER（5）
语音报告的主叫的LAC，对收发短信报告和VLR报告为报告的LAC
10
B_CELL
B_CELL
NUMBER（5）
语音报告的被叫CELL，对收发短信报告和VLR报告无效。
11
B_IMEI
B_IMEI
NUMBER（16）
语音报告的被叫IMEI，对收发短信报告和VLR报告无效。
12
B_IMSI
B_IMSI
NUMBER（16）
语音报告的被叫IMSI，对收发短信报告和VLR报告无效。
13
B_LAC
B_LAC
NUMBER（5）
语音报告的被叫LAC，对收发短信报告和VLR报告无效。
14
A_DIRECTION_NUMBER
A方向号码
VARCHAR2（32）
语音报告及收发短信报告的主叫，对VLR报告无效。
15
B_DIRECTION_NUMBER
B方向号码
VARCHAR2（32）
语音报告及收发短信报告的被叫，对VLR报告无效。
16
REPORT_TIME
报告生成时间
TIMESTAMP（19）
产生报告的时间,24小时制，YYYY-MM-DDHH:
MM:
SS
信令采集系统信令提供方式要求
信令采集系统可以采用文件接口方式或者实时接口方式提供信令数据。
具体的实现方式根据当地实现情况确定。
1.3.3信令过滤分发系统的设计
信令过滤分发系统的作用是对信令采集系统得到的信令进行初步的过滤，转换，清洗，并分发到信令处理主机上的各个处理节点。
根据需要，也可以在该系统中实现原始信令的存储。
对于有些省份的信令采集系统，本身就支持信令的分发，这样就可以不再重复实现信令分发系统。
一般可以支持不同IMSI段的信令通过不同的UDP端口进行发送。
●信令分发的规则
也就是信令分发系统向信令处理系统的各个节点上分发信令的规则。
由于每个用户信令的统计结果具有时间依赖性（比如要计算一个用户在小区的停留时间，需要用户进入小区的时刻），如果一个用户可以在不同的节点上进行处理，就会造成节点之间的耦合，需要在节点之间交换数据，造成网络流量的增大，并增大设计的复杂度。
因此，分发的规则应该能够保证同一个用户的信令始终被分发到同一个节点上。
在信令中，对用户是通过IMSI来进行标识的。
因此，通过划分不同的IMSI段，或者通过具有某种特征的IMSI（比如满足某种形式的正则表达式），被分发到相同的节点上。
在确定分发规则时，应该确保分发到各个节点上的信令量在一定程度上达到平衡。
●信令原始数据的存储
由于信令的数据量比较大，因此在数据仓库中尽量只存储业务有意义的信令分析结果数据，以及一些营销的用户接触数据（将来如果有对于营销活动过程中其他指标进行监控的数据，可能也会要求写入到数据仓库中）。
而在数据仓库中不存储原始的信令数据。
可以在信令分发系统保存信令的原始数据。
原因是如果通过信令处理系统进行保存，可能会使信令的存储分散在系统的多台设备上，会对将来的一些分析或者应用造成不便；并且信令分发系统的压力相对较小，不会增加信令处理系统的压力。
信令原始数据建议以文件的形式进行保存。
存储的周期可以根据规范的要求，结合当地的业务需求以及存储设备的状况确定。
存储的目录结构设计及命名规范、文件的划分等结合本地情况制定。
●信令过滤分发系统与其他系统的接口方式
信令过滤分发系统与信令采集系统的接口形式由信令采集系统的信令提供方式的实现确定。
一般来说可以以文件方式或者实时方式（如通过Socket）实现。
信令过滤分发系统与信令处理接口的实现通过scoket方式实现。
1.3.4信令处理系统的设计
信令处理系统完成信令的处理，得到信令分析的结果，并会将结果写入到数据仓库中。
为了信令系统的伸缩性，信令系统可以分布在多台主机上执行；在同一台主机上，可以有不同的处理单元（一般对应进程或者不同的线程）并行。
信令处理系统由以下四层组成：
信令获取层，功能层，处理层，以及数据层。
1.3.4.1信令获取层的设计
接收信令过滤分发系统分发的数据（在没有实现信令过滤分发系统的时候，是接收信令采集系统的信令），并将其进行缓存，供处理。
1.3.4.2功能层的设计
是对信令处理系统中的一些常用功能进行封装。
功能模块主要有：
数据仓库操作模块和缓存操作模块，以及信令处理数据库封装模块。
●数据仓库操作模块
主要是对于数据仓库的操作功能的封装。
这一方面，可以适应不同的数据库的类型；另一方面，可以适应不同的数据仓库的写入机制。
●信令处理数据库操作模块
在信令处理的过程中，存在大量的查询、检索等的过程。
为了简化系统开发的难度，提高系统开发效率，信令处理系统采用数据库存储各种信令分析的历史信息及一些分析结果。
信令处理数据库操作模块的目的就是封装对于信令处理数据库的操作，以便数据库的选型的变化不影响上层逻辑的实现。
●缓存操作模块
有多种不同的对数据进行缓存的技术。
本模块的目的就是封装数据缓存操作功能，以使得数据缓存技术不同的选择，不影响上层业务。
1.3.4.3处理层的设计
对信令进行处理。
一般来说，处理层会有一系列并行的处理单元，每个处理单元中都有一个信令处理线程或者进程。
并行的处理单元的形式和数目，根据本地情况确定。
处理层有由数据仓库同步模块和一系列的信令处理器组成。
信令处理器又包括用户信令视图处理器，基站信令视图处理器，客户网络使用情况处理器，基站人流量处理器，用户停留时间处理器等。
根据用户业务需要，可以进一步添加不同的处理器。
●用户信令视图处理器
作用是对输入的信令进行处理，更新用户的信令视图。
用户信令视图中保存用户信令的历史信息，主要内容有：
⏹IMSI
⏹MSISDN
⏹用户的基本信息（品牌，年龄层次等）
⏹最后一次信令的时间
⏹用户的开关机状态
⏹当前所在的小区
⏹用户进入当前小区的时间
⏹用户的最新的IMEI
⏹等等
●基站信令视图处理器
作用是对输入的信令进行处理，并更新基站的信令视图。
基站的信令视图中保存的是基站信令的历史信息，主要内容有：
⏹基站中的用户数
⏹基站当前时段的通话人数
⏹基站当前时段的通话时长
⏹基站当前时段的通话次数
⏹基站当前时段的计费时长
⏹等等
●客户网络使用情况处理器
作用是通过对输入的信令的分析，结合用户信令视图信息，更新客户网络使用情况统计表。
●基站人流量处理器
作用是通过对输入的信令的分析，结合基站信令视图信息，更新基站人流量统计表。
●用户停留时间处理器
作用是通过对输入的信令进行分析，结合用户信令视图信息，更新用户在某小区的停留时间表。
●数据仓库同步模块
该模块的作用是将信令处理系统中的分析结果定期向数据仓库中同步。
信令处理系统是一个实时处理的系统。
为了尽可能减小对于数据仓库的冲击，信令处理系统每隔一定时间才向数据仓库中同步一次变化了的处理结果。
同步的时间间隔可以根据当地情况确定，一般说来，应该在1分钟或者1分钟以上，但应该小于规范中所要求的15分钟。
向数据仓库中同步的内容应该只包含分析的最终结果的变化部分。
对于分析所需的中间结果，如用户信令统一视图和基站信令统一视图等，建议不向仓库中更新。
●信令处理流程
1.3.4.4数据层的设计
用以存储处理层处理得到的结果以及一些处理过程中需要的一些中间结果。
为了简化开发的难度，提高开发的效率，建议数据层采用数据库来进行存储和操作。
数据库可以选用通用数据库（如MySQL）或者内存数据库。
建议选用内存数据库，推荐使用Asiainfo的MDB或者Oracle的TimesTen。
1.3.5系统的部署
信令分析系统的部署图如上面所示。
说明：
1、信令采集系统一般由网络信令厂商开发和部署。
2、信令处理系统中采用数据库来进行数据的存储和检索。
信令处理数据库根据本地情况，可能单独部署，也可能部署在某一个信令处理主机或者信令过滤分发系统主机上。
3、信令处理主机根据本地的情况，可能采用一台或者一台以上的主机。
4、部署图中的各个接口实现的方式说明：
（1）信令采集系统和信令过滤分发系统之间的接口。
可以采用文件接口或者实时接口（如Socket等）实现。
（2）信令过滤分发系统与信令处理主机之间的接口。
采用实时接口实现。
（3）信令处理主机和信令处理数据库之间的接口。
采用ODBC或者数据库提供的SDK开发包实现。
（4）信令处理主机和数据仓库之间的接口。
采用ODBC或者数据库提供的SDK开发包实现。
1.4
网络信令分析
给出网络信令分析的详细技术框架图，阐明信令数据类型、数据量与处理性能、接口方式、数据同步时限、数据处理流程、功能模块、软件部署等。
说明结果数据的类别和存储周期。
网络信令分析是NG1-BASS本期建设的内容之一，本期广东移动在经营分析系统中的全程精确营销平台引入了网络信令接口和网络信令分析应用。
目前已接入地市A接口数据。
广东移动经营分析系统网络信令分析应用遵循了集团公司NG1-BASS规范实现，图4-8-1是集团公司NG1-BASS关于网络信令分析功能的框架图：
图4-8-1网络信令分析流程
网络信令数据通过业务支撑网中的信令采集子系统实时向经营分析系统发送SOCKET报文信息，通过经分系统的CMP信令采集模块获取信令数据，并设定每N（可配置，当前设置为10分钟）分钟生成一个数据文件，以文件接口的方式接入经分系统。
经分通过装载模块加载信令数据，经由调度模块产生作业链，对加载的数据进行计算分析，此过程通过全程精确营销系统关系数据库的存储过程实现。
整个网络信令分析过程采用广东移动经分系统通用的作业流程进行处理。
1.4.1系统组网结构
系统组网结构图如下图所示：
图4-8-2网络信令长连接的通信流程
双方（此处所说双方指全程精确营销与信令采集系统，下文同）采用SOCKET方式，信令解码服务器作为服务端，精确化营销系统接口机作为客户端。
服务端与客户端之间进行信息交互时，采用长连接方式。
所谓长连接，指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要客户端发链路检测包以维持此连接。
通信双方以客户-服务器方式建立TCP连接，用于双方信息的相互提交。
当信道上没有数据传输时，客户端应每隔时间C发送链路检测包以维持此连接，如果连续发送N-1次后都未得到响应则断开此连接。
参数C、N原则上应可配置，现阶段建议取值为：
C=2分钟，N=10。
任何一方都可以关闭一个TCP连接，要求双方发送一个终断消息信号关闭自己的通讯信道。
一方可以在另一方之前关闭。
或者双方同时关闭TCP连接。
1.4.2通信交互过程
升级会员 