网络信令分析.doc

1、1.1 网络信令分析 1.1.1 技术框架图信 令 文 件 1 信 令 文 件 2信 令 文 件 3信 令 文 件 4 信 令 文 件 N 严格按照 时间顺序 进行采集 信 令 分 发 模 块 信 令 分 析 模 块 1信 令 分 析 模 块 2 信 令 分 析 模 块 3 信 令 分 析 模 块 N 信 令 管 道 用 户 信 令 状 态 视 图 基 站 信 令 视 图 读 取 分 析 更 新获 取 分 发 客 户 动 态 行 为 数 据如 ： 用 户 更 换 手 机 了 、 用 户 开 机 了 、 用 户 关 机 了 、 用 户 发 短 信 了 等 等 。还 有 一 些 统 计 数 据 ，

2、 用 户 在 某 个 基 站 滞 留 的 时 间 ， 某 基 站 人 流 量 分 析 数 据 。 1.1.2 信令数据接口 接口编码 接口名称 描述 94001 信令用户短信收发消息 从信令中产生的用户收发短信的记录 94002 信令用户终端更换记录 用户终端更换记录 94003 信令用户开关机频次记录 用户开关机频次记录 94004 信令用户开关机时间统计 用户开关机时间统计 94005 信令用户小区滞留时间统计 用户小区滞留时间统计 94006 信令关键用户移动轨迹 关键用户移动轨迹 94007 信令基站人流量分析 基站人流量分析 94008 信令基站间人流量分析 基站间人流量分析 940

3、09 信令用户动态通信行为信息 用户动态通信行为信息 1.1.3 信令数据处理要求 【数据量与处理性能】 据调研，信令数据的量大约是清单的 4-10 倍， 【接口方式】 文件接口方式。 【数据同步时限】 理应比清单接口的频率还要高，规范要求在 15 分钟之内。 【数据处理流程】 信令接口文件主要经过数据采集、分发，并行处理、并行分析、并行更新视图、并根 据触发规则判断是否需要触发实时营销。 1.1.4 功能模块 序号 模块名称 功能描述 1 信令获取 实时性要求比较高，且必要严格按照时间顺序。 这只能采用单进程方式，降低采集间隔时间的方 式，接口协议仍然为 FTP 2 信令分发 事先为每个分析

4、模块建立一个信令通道。信令分 发模块每读取一条信令，根据信令类型，分发到 一个或多个对应的“快速通道”的队列中。 3 信令分析处理 每个分析模块轮询读取相应的“快速通道” ，根据 获取的信令进行一定的计算，并更新“用户信令 状态图”和“基站信令视图” 。 1.1.5 软件部署 整个软件部署可与 ETL 流程调度部署在同一主机上，也可单独部署。 1.1.6 存储周期 信令数据由于其自身特点，更新快，因此无须保存很久。 “用户信令状态视图”和 “基站信令视图”只需要保留当前最新信息即可，而其它接口信息根据实际需要设置最大 保存时间即可。 网络信令技术实现框架 信 令 采 集 系 统 信 令 分 析

5、 节 点 文 件 预 处 理 节 点 文 件 获 取 节 点 获 取 层 数 据 层 信令文件 信 令 分 析 结 果 数 据 原 始 信 令 数 据 入 库 加 载 节 点 信 令 状 态 视 图 网络信令处理的技术实现细节 信令数据采集原理 1.2 网络信令分析 在经营分析系统中引入实时/准实时的网络信令数据将进一步丰富系统应用能力。 它可以帮助市场管理和营销人员更为准确的把握用户的行为特征，实现基于事件的营 销，为网络规划优化、发现新的业务机遇提供必要的数据支持。 Teradata 公司在网络信令应用方面有较为成熟的解决方案，拥有在国外运营商 NIW 的成功部署经验。基于本公司既有经验，

6、并结合中国移动 NG-BASS1 规范要求， Teradata 提出如下方案建议。 4.8.1 技术框架图 网络信令分析方案的体系架构如图所示。为了降低投资，提高现有设施的利用率， 建议复用现有的小区短信系统和信令监测系统做为获取信令信息的数据源（即信令采 集子系统） 。信令采集子系统从移动网络中采集 A 接口、A-bis 接口、Gb 接口等的原始 信令数据，对原始信令进行初步解码和处理，然后按照中国移动省级 NG1-BASS 技术 规范源系统接口分册中规定的接口要求传送到经营分析系统的信令处理服务器，对 所需信令进行筛选、归并、拼接，然后将实时营销信令触发数据送到 TCRM 渠道网关互 动网

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

8、支持将审核后的营销活动白名单、采集区域设置（Cell ID 或 MSC ID）等采集控制信息输出到信令处理模块与信令采集子系统（小区短信系统 或信令监测系统） ，优化信令数据的采集量，减轻信令采集系统、网络和加载服务器的 负荷。 图 4.8.1 信令采集技术框架图 4.8.2 信令采集内容和容量估算 原始信令数据量估算 主要采集用户位置更新信令、用户附着网络/去附着信令、呼叫接续信令、raw- CDR 等。原始信令数据处理流程如下图所示。 MSC MSC MSC D X C 信 令 采 集 服 务 器 信 令 处 理 服 务 器 0100101 0100101 二进制数据 二进制数据 将信令数

9、 据进行IP 层打包 信令采集子系统 DCN DCN DCN 经营分析系统 D X C 加 载 服 务 器 信 令 处 理 服 务 器 图 4.8.2 信令处理数据流图 1. DXC 将 MSC 信令收敛后,传送给信令采集服务器，DXC 最大输出速率=采集板卡数* 端口数/板卡*端口速率，假设信令采集服务器通畅的忙闲系数为 0.4，则采集服 务器最大输入速率=DXC 最大输出速率*0.4； 2. 信令采集服务器采集数据后,将全部数据打包送给信令采集子系统的信令处理服务 器，信令处理服务器对信令进行拆包解码，并按业务需要进行处理，输出 ss7 解 码后信令消息，如用户附着、位置区更新、路由区更新

10、、呼叫建立、释放、切换、 会话建立与或原始话单，并送到经营分析系统端的信令处理服务器。 3. 经营分析系统端的信令处理服务器根据业务需要选择一定的规则对数据进行过滤， 拼接，实时触发数据直接送营销管理平台渠道网关互动网关实现全程精确营销， 非实时数据加载到数据仓库用于实现信令分析等应用。输出数据规模直接与业务 规则相关，例如营销活动的活动名单，营销活动的区域等。 输出数据量=实时营销触发数据+信令分析数据 4. 以某 200 万用户的地区为例，共 60 块采集卡，则信令采集子系统信令处理服务器 最大输入速率=60 块采集卡*8 个端口*2M/s*0.4(忙闲系数)=384M/s=1.3T/H。

11、 5. 为减轻经分系统信令处理服务器负荷，建议信令采集子系统的信令处理服务器尽 可能的完成信令初步筛选处理，降低输出数据量。 汇总入库数据量估算 NG-BASS1 中规定的源系统接口内容及估算，存储周期为 1 个月。 使用参数：1500 万用户，1.4*109 条短信，每用户平均每天出入 20 个小区，每日 70% 用户会有开关机操作，小区数为 1 万，每个小区的邻小区为 6 个。 数据接口 容量估算 估算方法 用户短信收发消息 10.3G 该类消息与短信话单存在重复，因此不在仓库存放，仅将其中 的 LAC 地址和 Cell 标识填入现有的短信话单中，用于改进区域 化管理中的相关算法。月新增容

12、量为 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 分

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

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

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

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

17、查询等；尽可能利用宿主 系统的系统特性（比如一些数据存储或者处理的特性） ； 4. 系统伸缩性的考虑：通过支持分布式和并行能力的方式满足系统得伸缩性要求。 1.3.1 方案总体介绍 信令过滤 分发系统 信 令 处 理 系 统 数据 仓库 信 令 处 理 主 机 2 信 令 处 理 主 机 1 信 令 处 理 主 机 n . . . 信令采集系统 信令采 集系统 信令获取层 数 据 层 用户信令状态视图 基站信令视图 处 理 层 网 络 信 令 分 析 系 统 技 术 框 架 图 信令过滤 原始信令存储 基站人流量分析 网元收益分析客户网络使用情况分析 基站人流量分析表 用户停留时间表客户网络使

18、用情况分析表 信令分发 功 能 层 数据仓作操作模块 信令缓存功能模块 信令处理数据库操作模块 网络 信令 分析 系统 用户信令视图处理器 客户网络使用情况处理器 基站信令视图处理器 基站人流量处理器 用户停留时间处理器 网元收益分析表 数据仓库同步模块 网络信令分析系统的技术框架如上图中所示。 1. 信令采集系统为网络信令分析系统提供网络信令。一般有网络厂商单独建设。 2. 数据仓库用以存储网络信令分析得到的结果，供上层应用使用。 3. 网络信令分析系统由信令过滤分发系统合信令处理系统和信令处理系统组成。 信令分发过滤系统：由于信令数据量大，并且有一定的实时要求，因此只靠单 个的进程甚至单台

19、设备可能无法完成信令数据的处理。因此，在进行架构设计 的时候允许用户采用多个节点进行信令的并行处理。这里所说的节点，在实现 中对应的是主机。 信令处理系统：完成从输入的单条的信令数据到得到最终需要的信令分析结果 的全过程，也是整个系统中最为复杂的部分。得到的结果中需要保存的部分都 写入到数据仓库中。 网络分析中的数据流图如下图所示： 信令采集系统 信令过滤分发系统 数据仓库 信令文件 ， 单条或多条信令数据 信令获取层 信 令 处 理 器 P u l l 数据 ， 得到的 是单条信令数据 . . . 信 令 处 理 系 统 数据仓库写入 发生变化的分析结果 数据仓库写入 处 理 节 点 1 处

20、 理 节 点 2 处 理 节 点 n 处 理 单 元 1 处 理 单 元 2 处 理 单 元 n . . . 网络信令分析系统数据流图 P u s h 数据 ， p u s h 出的是单 条信令数据 每隔一定时间批量写入 1.3.2 对于信令采集系统的要求 在本方案中不包含对信令采集系统的设计及实现。信令采集系统一般由网络厂商实现。 信令数据类型及格式要求 一般来说，信令采集系统的接口传输内容应包括：用户开机、关机、主叫开始、主叫挂 机、被叫开始、被叫挂机、发送短信、接收短信、位置变更等行为信息和用户当前所在位 置区 LAC_ID，小区代码 CELL_ID，IMSI、IMEI 等属性信息。 具

21、体接口传输内容可参考下表，根据本地实施情况具体确定。 属性编码 属性名称 属性描述 类型 备注 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 = Imsi attach（手机 开） 4 =

22、Imsi detach （手 机关） 05 MSISDN MSISDN VARCHAR2 (18) 报告的手机号码，只 对收发短信报告和 VLR 报告有效。 06 A_CELL A_CELL NUMBER(5) 语音报告的主叫的 CELL，对收发短信 报告和 VLR 报告为 报告的 CELL 07 A_IMEI A_IMEI NUMBER(1 6) 语音报告的主叫的 IMEI ，对收发短信 报告和 VLR 报告为 报告的 IMEI 08 A_IMSI A_IMSI NUMBER(1 6) 语音报告的主叫的 IMSI，对收发短信报 告和 VLR 报告为报 告的 IMSI 09 A_LAC A_L

23、AC NUMBER(5) 语音报告的主叫的 LAC，对收发短信报 告和 VLR 报告为报 告的 LAC 10 B_CELL B_CELL NUMBER(5) 语音报告的被叫 CELL，对收发短信 报告和 VLR 报告无 效。 11 B_IMEI B_IMEI NUMBER(1 6) 语音报告的被叫 IMEI，对收发短信报 告和 VLR 报告无效。 12 B_IMSI B_IMSI NUMBER(1 6) 语音报告的被叫 IMSI，对收发短信报 告和 VLR 报告无效。 13 B_LAC B_LAC NUMBER(5) 语音报告的被叫 LAC，对收发短信报 告和 VLR 报告无效。 14 A_D

24、IRECTION_NUMBER A 方向号码 VARCHAR2 (32) 语音报告及收发短信 报告的主叫，对 VLR 报告无效。 15 B_DIRECTION_NUMBER B 方向号码 VARCHAR2(32) 语音报告及收发短信报告的被叫，对 VLR 报告无效。 16 REPORT_TIME 报告生成时 间 TIMESTAM P(19) 产生报告的时间, 24 小时制，YYYY- MM-DD HH:MM:SS 信令采集系统信令提供方式要求 信令采集系统可以采用文件接口方式或者实时接口方式提供信令数据。具体的实现方式 根据当地实现情况确定。 1.3.3 信令过滤分发系统的设计 信令过滤分发系

25、统的作用是对信令采集系统得到的信令进行初步的过滤，转换，清洗， 并分发到信令处理主机上的各个处理节点。根据需要，也可以在该系统中实现原始信令的 存储。 对于有些省份的信令采集系统，本身就支持信令的分发，这样就可以不再重复实现信令 分发系统。一般可以支持不同 IMSI 段的信令通过不同的 UDP 端口进行发送。 信令分发的规则 也就是信令分发系统向信令处理系统的各个节点上分发信令的规则。 由于每个用户信令的统计结果具有时间依赖性（比如要计算一个用户在小区的停留时间， 需要用户进入小区的时刻） ，如果一个用户可以在不同的节点上进行处理，就会造成节点之 间的耦合，需要在节点之间交换数据，造成网络流量

26、的增大，并增大设计的复杂度。因此， 分发的规则应该能够保证同一个用户的信令始终被分发到同一个节点上。 在信令中，对用户是通过 IMSI 来进行标识的。因此，通过划分不同的 IMSI 段，或者 通过具有某种特征的 IMSI（比如满足某种形式的正则表达式） ，被分发到相同的节点上。 在确定分发规则时，应该确保分发到各个节点上的信令量在一定程度上达到平衡。 信令原始数据的存储 由于信令的数据量比较大，因此在数据仓库中尽量只存储业务有意义的信令分析结果数 据，以及一些营销的用户接触数据（将来如果有对于营销活动过程中其他指标进行监控的 数据，可能也会要求写入到数据仓库中） 。而在数据仓库中不存储原始的信

27、令数据。 可以在信令分发系统保存信令的原始数据。原因是如果通过信令处理系统进行保存，可 能会使信令的存储分散在系统的多台设备上，会对将来的一些分析或者应用造成不便；并 且信令分发系统的压力相对较小，不会增加信令处理系统的压力。 信令原始数据建议以文件的形式进行保存。存储的周期可以根据规范的要求，结合当地 的业务需求以及存储设备的状况确定。存储的目录结构设计及命名规范、文件的划分等结 合本地情况制定。 信令过滤分发系统与其他系统的接口方式 信令过滤分发系统与信令采集系统的接口形式由信令采集系统的信令提供方式的实现确 定。一般来说可以以文件方式或者实时方式（如通过 Socket）实现。 信令过滤分

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

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

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

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

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

33、流程 获取信令 ， 分析发生该信令的 I M S I 以及基站 I D 根据 I M S I , 到用户信令视图中查找用户的历史信息 根据基站 I D ， 到基站信令视图中查找对应的基站 更新客户网络使用情况表 更新基站人流量统计表 更新用户停留时间表 更新用户信令视图 更新基站信令视图 。 是否退出 ？ Y N 1.3.4.4 数据层的设计 用以存储处理层处理得到的结果以及一些处理过程中需要的一些中间结果。 为了简化开发的难度，提高开发的效率，建议数据层采用数据库来进行存储和操作。数 据库可以选用通用数据库（如 MySQL）或者内存数据库。 建议选用内存数据库，推荐使用 Asiainfo 的

34、 MDB 或者 Oracle 的 TimesTen。 1.3.5 系统的部署 经分数据仓库 信令采集系统 信令过滤分发系统 信令处理数据库 信令采 集系统 信令处 理系统 经分 系统 信令处理主机 1 信令处理主机 2 信令处理主机 n . . . 1 2 2 2 3 3 3 4 4 4 网 络 信 令 分 析 系 统 部 署 图 信令分析系统的部署图如上面所示。 说明： 1、信令采集系统一般由网络信令厂商开发和部署。 2、信令处理系统中采用数据库来进行数据的存储和检索。信令处理数据库根据本地情 况，可能单独部署，也可能部署在某一个信令处理主机或者信令过滤分发系统主机上。 3、信令处理主机根据

35、本地的情况，可能采用一台或者一台以上的主机。 4、部署图中的各个接口实现的方式说明： （1） 信令采集系统和信令过滤分发系统之间的接口。可以采用文件接口或者实时接 口（如 Socket 等）实现。 （2） 信令过滤分发系统与信令处理主机之间的接口。采用实时接口实现。 （3） 信令处理主机和信令处理数据库之间的接口。采用 ODBC 或者数据库提供的 SDK 开发包实现。 （4） 信令处理主机和数据仓库之间的接口。采用 ODBC 或者数据库提供的 SDK 开 发包实现。 1.4 网络信令分析 给出网络信令分析的详细技术框架图，阐明信令数据类型、数据量与处理性能、接口 方式、数据同步时限、数据处理流

36、程、功能模块、软件部署等。说明结果数据的类别和存 储周期。 网络信令分析是 NG1-BASS 本期建设的内容之一，本期广东移动在经营分析系统中的全 程精确营销平台引入了网络信令接口和网络信令分析应用。目前已接入地市 A 接口数据。 广东移动经营分析系统网络信令分析应用遵循了集团公司 NG1-BASS 规范实现，图 4- 8-1 是集团公司 NG1-BASS 关于网络信令分析功能的框架图： 图 4-8-1 网络信令分析流程 网络信令数据通过业务支撑网中的信令采集子系统实时向经营分析系统发送 SOCKET 报 文信息，通过经分系统的 CMP 信令采集模块获取信令数据，并设定每 N（可配置，当前设

37、置为 10 分钟）分钟生成一个数据文件，以文件接口的方式接入经分系统。 经分通过装载模块加载信令数据，经由调度模块产生作业链，对加载的数据进行计算 分析，此过程通过全程精确营销系统关系数据库的存储过程实现。 整个网络信令分析过程采用广东移动经分系统通用的作业流程进行处理。 1.4.1 系统组网结构 系统组网结构图如下图所示： 图 4-8-2 网络信令长连接的通信流程 双方（此处所说双方指全程精确营销与信令采集系统，下文同）采用 SOCKET 方式，信 令解码服务器作为服务端，精确化营销系统接口机作为客户端。服务端与客户端之间进行 信息交互时，采用长连接方式。所谓长连接，指在一个 TCP 连接上

38、可以连续发送多个数据 包，在 TCP 连接保持期间，如果没有数据包发送，需要客户端发链路检测包以维持此连接。 通信双方以客户-服务器方式建立 TCP 连接，用于双方信息的相互提交。当信道上没有 数据传输时，客户端应每隔时间 C 发送链路检测包以维持此连接，如果连续发送 N-1 次后 都未得到响应则断开此连接。 参数 C、N 原则上应可配置，现阶段建议取值为：C=2 分钟， N=10。 任何一方都可以关闭一个 TCP 连接，要求双方发送一个终断消息信号关闭自己的通讯 信道。一方可以在另一方之前关闭。或者双方同时关闭 TCP 连接。 1.4.2 通信交互过程 服务端 客户端 申请连接 发送业务数据

39、 1 确认连接 发送业务数据 2 发送业务数据 N 连接响应 订制业务数据响应 1 订制业务数据规则 1 取消业务数据响应 1 取消业务数据规则 1 Active 响应 Active 请求 断开响应 断开请求 业务数据响应 1 业务数据响应 2 业务数据响应 N 图 4-8-3 通讯交互流程 客户端与服务端的通信主体上包含六部分，连接消息、订制业务数据规则消息、发送 业务数据消息、取消业务数据规则消息、链路测试消息、断开消息。 1) 客户端发出连接请求。 2) 服务端验证客户端的连接请求，并返回连接响应。 3) 客户端向服务端发送订制业务数据规则消息进行业务数据的订制。每一个客户端每一 次连接

40、在同一时段最多只能存在定制一条业务数据规则；如果需要重新定制业务数据 规则，必须先取消上一条业务数据规则，否则服务器端返回定制失败的响应。 4) 服务端接受订制业务数据规则请求，并返回订制是否成功的响应。 5) 服务端接受了订制规则，并订制成功后，就开始连续发送符合规则的业务数据信息到 客户端。 6) 客户端接收业务数据后返回业务数据消息的响应。 7) 客户端可以根据实际情况需要取消指定的订制业务规则，发送取消订制业务规则请求。 8) 服务端接受取消订制业务规则请求，取消指定的订制业务规则，并返回消息响应。 9) 客户端在信道上没有数据传输时，应在间隔固定时间后发送链路检测包以维持此连接， 服

41、务器端返回消息响应。 10) 无论服务端还是客户端，任何一方都可以关闭连接，要求双方发送一个终断请求消息 信号关闭自己的通讯信道并返回消息响应。一方可以在另一方之前关闭。或者双方同 时关闭 TCP 连接。 1.4.3 流量控制 消息采用并发方式发送，加以滑动窗口流量控制，窗口大小参数 W 可配置，现阶段配 置为 100，即接收方在应答前一次收到的消息最多不超过 100 条。该滑动窗口机制主要基 于 CMP_DATA 和 CMP_DATA_RESP 的消息交互进行。 1.4.4 信令分析方法 图 4-8-4 网络信令分析方法 广东移动经分系统信令分析模块中，信令分析模块由一系列 SQL 存储过程

42、和 ILOG 规 则引擎实现，每次对当次采集的信令数据装载，并根据相应配置规则策略调用相应的分析 子模块，由该分析子模块实现对具体的用户行为和基站情况进行分析计算。每个模块响应 一种或多种信令类型，如 IMEI 比对子模块，只处理用户开机信令，开关机频度分析模块 响应用户的开机信令和关机信令。 子模块按照功能划分为两类，一类是在信令分析流程中不需要查询用户历史状态的子 模块。如通信行为汇总子模块，其功能是直接判断信令中用户的通信行为，对满足条件的 信息直接进行记录。例如在通过 NG1-BOSS 系统获取的短信清单中，用户发送短信时所处 的基站小区代码缺失，而在短信发送信令中可以捕获相应的信息。

43、通信行为汇总模块响应 短信发送信令，并将之记录到数据层中，为做经营分析系统片区化管理工作中的补充数据。 另一类子模块在进行分析时需要查询用户的历史状态，或者需要查询基站小区的历史 情况，根据历史情况与当前正在处理信令进行比对和处理。如用户滞留时间分析子模块， 当接收到用户位置变更信令后，从历史信息中查询用户上一次所处的基站小区代码和进入 该区域的时间，然后与信令中的当前基站小区代码进行比对，当发现用户的位置发生变化 时，再计算用户在上一个基站小区中滞留的时间，当时间超过一定的阈值后，记录用户滞 留该基站小区的信息。又如 IMEI 比对子模块响应用户的开机信令后，从用户历史状态中 查询用户上一次

44、登记的 IMEI 号码，再与信令中的当前 IMEI 进行对比，如果发现 IMEI 信 息发生了变化，说明用户更换了手机，该信息作为用户换机记录存入数据层中。 在网络信令分析模块中通过用户信令状态视图和基站信令视图两个物理实体存放用户 和基站的状态信息。在用户信令状态视图中存放每个用户当前的开停机状态、上次登记的 IMEI、当前所处基站小区等信息；在基站信令视图，存放每个基站小区中当前用户数量和 用户在基站小区间的流动情况。各个子模块均从这两个视图中查询历史信息。 将分析后的客户动态行为数据存储到数据层中，进一步丰富客户信息知识库，满足市 场营销、客户服务和客户管理等多种工作的需要。另外分析后的基站流量数据可以作为渠 道选址、网络优化等工作的重要参考。 广东移动经分系统目前已经完成的信令分析应用包括客户到达机场/车站营销，位置变 化分析，售卡渠道归属分析等。 1.4.5 数据存储周期 广东移动经分系统网络信令分析应用接入数据量巨大，业务应用更关心实效性，因而 对于数据存储周期定义必须严格控制。当前 A 接口的接口数据存储周期为一天，即在所有 处理正确执行的前提下，每天系统会自动清除上一天的接入数据；对于应用发生错误的时 候，允许 5 天的数据滞留。 此外，由于汇总的分析数据是经分系统的补充，其存储周期将参考经分系统相关应用 的数据存储周期进行规划。