网络信令分析

1、1.1 网络信令分析1.1.1技术框架图信令文件 1 取分 取分析更新信令文件 2信令分析模 1用 信令状 信令文件 3严信令文件 4格信令分析模 2按照时信令分析模 3间信令分 模 顺序基站信令 进行采集信令文件 N信令分析模 N信令管道客 行 数据如：用 更 手机了、用 开机了、用 关机了、用 短信了等等。 有一些 数据，用 在某个基站滞留的 ，某基站人流量分析数据。客 行 数据触 周期 区域配置配置有效信令 型配置触 全程精确 活 的核心是 捕捉用 通信行 ( 信令信息 )， 合用 的 史消 、使用偏好等信息，通 用 信令信息与 目 用 景 置信息匹配， 足匹配条件客 触 行，向用 推送

2、 内容，以达到在适当的 ，以适当的方式，向适当的用 推广适当的 的目的。1.1.2信令数据接口接口编码接口名称描述94001信令用户短信收发消息从信令中产生的用户收发短信的记录94002信令用户终端更换记录用户终端更换记录1 / 3094003信令用户开关机频次记录用户开关机频次记录94004信令用户开关机时间统计用户开关机时间统计94005信令用户小区滞留时间统计用户小区滞留时间统计94006信令关键用户移动轨迹关键用户移动轨迹94007信令基站人流量分析基站人流量分析94008信令基站间人流量分析基站间人流量分析94009信令用户动态通信行为信息用户动态通信行为信息1.1.3信令数据处理要

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

4、析模块轮询读取相应的“快速通道”，根据获取的信令进行一定的计算，并更新“用户信令状态图”和“基站信令视图” 。1.1.5软件部署整个软件部署可与ETL流程调度部署在同一主机上，也可单独部署。1.1.6存储周期信令数据由于其自身特点，更新快，因此无须保存很久。 “用户信令状态视图”和“基站信令视图” 只需要保留当前最新信息即可， 而其它接口信息根据实际需要设置最大保存时间即可。2 / 30网络信令技术实现框架数据信令状态视信令分析结原始信令数图果数据据层获取入库加载节点层信令分析节文件预处理文件获取节信令信令文件采集点节点点系统网络信令处理的技术实现细节3 / 30信令数据采集原理4 / 305

5、 / 306 / 307 / 301.2网络信令分析在经营分析系统中引入实时/ 准实时的网络信令数据将进一步丰富系统应用能力。它可以帮助市场管理和营销人员更为准确的把握用户的行为特征，实现基于事件的营销，为网络规划优化、发现新的业务机遇提供必要的数据支持。Teradata 公司在网络信令应用方面有较为成熟的解决方案，拥有在国外运营商 NIW的成功部署经验。 基于本公司既有经验， 并结合中国移动 NG-BASS1规范要求， Teradata提出如下方案建议。4.8.1技术框架图网络信令分析方案的体系架构如图所示。为了降低投资，提高现有设施的利用率，建议复用现有的小区短信系统和信令监测系统做为获取

6、信令信息的数据源（即信令采集子系统）。信令采集子系统从移动网络中采集A 接口、 A-bis 接口、 Gb接口等的原始信令数据，对原始信令进行初步解码和处理，然后按照中国移动省级NG1-BASS技术规范源系统接口分册 中规定的接口要求传送到经营分析系统的信令处理服务器，对所需信令进行筛选、归并、拼接，然后将实时营销信令触发数据送到TCRM渠道网关互动网关，将待分析数据送到加载服务器加载入数据仓库系统。依据数据时限要求不同，信令数据可以通过两种加载方式：实时/ 准实时加载、定时加载。实时/ 准实时加载通过读取消息队列加载数据入库，定时加载通过批量文件方8 / 30式加载数据入库。信令数据经信令分析

7、模块处理后用于实现上层应用，包括营销管理子系统、信令分析应用和对现有分析应用的增强扩展。在全程精确营销过程中，营销管理子系统（ TCRM）将活动的白名单或缺省用户群规则传送到渠道网关互动网关，当与营销活动相关的实时信令数据被实时传送到渠道网关互动网关时，触发外部执行过程。有关TCRM与渠道网关互动网关的功能介绍请参见有关章节。另一方面营销管理子系统支持将审核后的营销活动白名单、采集区域设置 （ CellID或 MSC ID）等采集控制信息输出到信令处理模块与信令采集子系统（小区短信系统或信令监测系统） ，优化信令数据的采集量，减轻信令采集系统、网络和加载服务器的负荷。图 4.8.1信令采集技术

8、框架图4.8.2信令采集内容和容量估算原始信令数据量估算主要采集用户位置更新信令、用户附着网络/ 去附着信令、 呼叫接续信令、 raw-CDR等。原始信令数据处理流程如下图所示。9 / 30MSC信令采集子系统经营分析系统D0100101MSCX二进制数据CMSC DCN 0100101DX二进制数据C信 将信令数令 据进行 IP采 层打包集服 DCN务器信信令令处处加理理载服 DCN服服务务务器器器图 4.8.2 信令处理数据流图1. DXC将 MSC信令收敛后 , 传送给信令采集服务器， DXC最大输出速率 =采集板卡数 *端口数 / 板卡 * 端口速率，假设信令采集服务器通畅的忙闲系数为

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

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

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

12、移动轨迹268G32byte*用户数 *20 个小区 *30 天基站人流量分析1.28G假设 15分钟每小区一条记录，假设小区数为1 万。48byte*24*30* 小区数 *4基站间人流量分析1.6G假设 15分钟每小区一条记录，每小区6 个邻小区，小区数为 1万。 40byte*24*30* 小区数 *6( 邻小区数 )*4总计约为600G/月网络信令数据量异常庞大， 任何一项信令数据的采集开启都会对网络交换机、 DCN、信令采集子系统、信令处理模块带来巨大的处理压力，同时需要占用大量的容量存储，因此在信令数据的引入前期， 本公司建议采用以需求为驱动的接口采集方式。 具体而言，包括以下几类

13、降低采集压力和存储压力方式可供选择：实时营销类数据将客户分析及运营模块中市场分析和营销策划阶段形成的规则传递到信令采集子系统，用于筛选出所需的触发信令，然后再将筛选后数据送入执行触发环节。数据分析类数据根据分析需求不同，可以采用抽样、指定用户抽样方式降低数据量。另外部分分析并不需要持续每月进行， 例如用户滞留小区分析， 可以将采集量较大的接口错月轮流采集。4.8.3接口方式提供批量文件接口方式和实时消息两种方式。实时消息方式可以基于消息平台实现，消息平台基于规范所要求的tcp/udp网络协议之上实现。11 / 304.8.4数据处理流程数据仓库系统的数据加载的策略是根据具体的数据特征制定的。T

14、eradata为网络信令数据提供两种数据加载策略：批量文件加载、 消息实时加载两种。具体数据流程和处理模块如图所示。图 4.8.4-1实时信令处理流程实时信令处理流程图 4.8.4-2 实时信令处理流程在实际应用中，应根据营销活动的需求，设置信令的筛选处理规则和实时要求，并综合规划所有营销活动、网络信令分析所需要的信令处理作业，提供不同的处理时限。4.8.5应用功能模块12 / 30Teradata的网络数据仓库解决方案可以提供以下功能。图 4.8.5-1 Teradata NIW解决方案根据 NG-BASS1规范要求，将首先考虑以下应用的建设：图 4.8.5-2 中国移动信令分析解决方案图应

15、用数据存储周期建议与现有应用相同，采用6+1 方式。13 / 301.3 网络信令分析方案网络信令分析主要有以下的难点：1. 数据量大，对存储的要求以及写入效率等会有极高的要求2. 要求具有实时性，因此对于处理的效率会产生比较严格的要求3. 各种处理过程中的逻辑比较复杂，如果设计不好，会产生大量重复的计算，极大的加大计算量因此，为了解决上述的问题，提出了基于管道过滤器模式的技术架构，并且支持分布式、伸缩性，以及规则的扩展性等。网络信令分析系统的架构设计原则：1. 充分考虑对于数据仓库的影响。在数据仓库中尽量存储尽可能少的数据，并且尽可能减少或者更好的组织对于数据仓库的访问。2. 系统扩展性的考

16、虑：满足信令处理需求复杂多变的情况。在有新的信令处理需求时，尽可能在不重起系统，不重新部署的情况下进行处理。3. 处理效率的考虑：尽可能减少重复的处理和不必要的查询等；尽可能利用宿主系统的系统特性（比如一些数据存储或者处理的特性）；4. 系统伸缩性的考虑： 通过支持分布式和并行能力的方式满足系统得伸缩性要求。14 / 301.3.1 方案总体介绍数据客户网络使用情况分析表基站人流量分析表网元收益分析表用户停留时间表仓库信令信处令理处网络系理信令统主分析机系统1信令过滤分发系统信令采集系统数客户网络使用情况分析基站人流量分析网元收益分析据用户信令状态视图基站信令视图层.信数据仓库同步模块信令处令

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

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

19、隔一定时间批量写入数据仓库网络信令分析系统数据流图1.3.2 对于信令采集系统的要求在本方案中不包含对信令采集系统的设计及实现。信令采集系统一般由网络厂商实现。信令数据类型及格式要求一般来说，信令采集系统的接口传输内容应包括：用户开机、关机、主叫开始、主叫挂机、被叫开始、被叫挂机、发送短信、接收短信、位置变更等行为信息和用户当前所在位置区 LAC_ID ，小区代码 CELL_ID ， IMSI 、 IMEI 等属性信息。具体接口传输内容可参考下表，根据本地实施情况具体确定。属性编码属性名称属性描述类型备注01city_id本地网标识CHAR(3)本地网标识报告类型CHAR(1)报告类型02Re

20、port_type1：语音报告2：收发短信报告3：VLR 报告短信类型NUMBER(3)只对收发短信报告有03SMS_TYPE效。（ 0： mosm 发、2:mtsm 收）VLR 报告类NUMBER(5)只对 VLR 报告有效 :VLR_Report_Reas型1 = 正常位置更新042 = 周期性位置更新on3 = Imsi attach （手机开）16 / 3005MSISDNMSISDN06A_CELLA_CELL07A_IMEIA_IMEI08A_IMSIA_IMSI09A_LACA_LAC10B_CELLB_CELL11B_IMEIB_IMEI12B_IMSIB_IMSI13B_LA

21、CB_LACA_DIRECTION_A 方向号码14NUMBERB_DIRECTION_B 方向号码15NUMBER报告生成时16REPORT_TIME间4 = Imsi detach （手机关）VARCHAR2报告的手机号码，只(18) 对 收 发 短 信 报 告 和VLR 报告有效。NUMBER(5)语 音 报 告 的 主 叫 的 CELL ，对收发短信报告和 VLR 报告为报告的 CELLNUMBER(1语 音 报 告 的 主 叫 的6) IMEI ，对收发短信报告和 VLR 报告为报告的 IMEINUMBER(1语 音 报 告 的 主 叫 的6) IMSI ，对收发短信报告和 VLR

22、报告为报告的 IMSINUMBER(5)语 音 报 告 的 主 叫 的LAC ，对收发短信报告和 VLR 报告为报告的 LACNUMBER(5)语 音 报 告 的 被 叫CELL ，对收发短信报告和 VLR 报告无效。NUMBER(1语 音 报 告 的 被 叫6) IMEI ，对收发短信报告和 VLR 报告无效。NUMBER(1语 音 报 告 的 被 叫6) IMSI ，对收发短信报告和 VLR 报告无效。NUMBER(5)语 音 报 告 的 被 叫 LAC ，对收发短信报告和 VLR 报告无效。VARCHAR2语音报告及收发短信(32) 报告的主叫，对 VLR 报告无效。VARCHAR2语音

23、报告及收发短信(32) 报告的被叫，对 VLR 报告无效。TIMESTAM产生报告的时间, 24P(19)小 时 制 ， YYYY-MM-DD17 / 30HH:MM:SS信令采集系统信令提供方式要求信令采集系统可以采用文件接口方式或者实时接口方式提供信令数据。具体的实现方式根据当地实现情况确定。1.3.3 信令过滤分发系统的设计信令过滤分发系统的作用是对信令采集系统得到的信令进行初步的过滤，转换，清洗，并分发到信令处理主机上的各个处理节点。根据需要， 也可以在该系统中实现原始信令的存储。对于有些省份的信令采集系统，本身就支持信令的分发，这样就可以不再重复实现信令分发系统。一般可以支持不同IM

24、SI 段的信令通过不同的UDP 端口进行发送。信令分发的规则也就是信令分发系统向信令处理系统的各个节点上分发信令的规则。由于每个用户信令的统计结果具有时间依赖性（比如要计算一个用户在小区的停留时间，需要用户进入小区的时刻），如果一个用户可以在不同的节点上进行处理，就会造成节点之间的耦合，需要在节点之间交换数据，造成网络流量的增大，并增大设计的复杂度。因此，分发的规则应该能够保证同一个用户的信令始终被分发到同一个节点上。在信令中，对用户是通过IMSI 来进行标识的。因此，通过划分不同的IMSI 段，或者通过具有某种特征的IMSI （比如满足某种形式的正则表达式），被分发到相同的节点上。在确定分发

25、规则时，应该确保分发到各个节点上的信令量在一定程度上达到平衡。信令原始数据的存储由于信令的数据量比较大，因此在数据仓库中尽量只存储业务有意义的信令分析结果数据，以及一些营销的用户接触数据（将来如果有对于营销活动过程中其他指标进行监控的数据，可能也会要求写入到数据仓库中）。而在数据仓库中不存储原始的信令数据。可以在信令分发系统保存信令的原始数据。原因是如果通过信令处理系统进行保存，可能会使信令的存储分散在系统的多台设备上，会对将来的一些分析或者应用造成不便；并且信令分发系统的压力相对较小，不会增加信令处理系统的压力。信令原始数据建议以文件的形式进行保存。存储的周期可以根据规范的要求，结合当地18

26、 / 30的业务需求以及存储设备的状况确定。存储的目录结构设计及命名规范、文件的划分等结合本地情况制定。信令过滤分发系统与其他系统的接口方式信令过滤分发系统与信令采集系统的接口形式由信令采集系统的信令提供方式的实现确定。一般来说可以以文件方式或者实时方式（如通过Socket）实现。信令过滤分发系统与信令处理接口的实现通过scoket 方式实现。1.3.4 信令处理系统的设计信令处理系统完成信令的处理，得到信令分析的结果，并会将结果写入到数据仓库中。为了信令系统的伸缩性，信令系统可以分布在多台主机上执行；在同一台主机上，可以有不同的处理单元（一般对应进程或者不同的线程）并行。信令处理系统由以下四

27、层组成：信令获取层，功能层，处理层，以及数据层。信令获取层的设计接收信令过滤分发系统分发的数据（在没有实现信令过滤分发系统的时候，是接收信令采集系统的信令） ，并将其进行缓存，供处理。功能层的设计是对信令处理系统中的一些常用功能进行封装。功能模块主要有：数据仓库操作模块和缓存操作模块，以及信令处理数据库封装模块。数据仓库操作模块主要是对于数据仓库的操作功能的封装。这一方面，可以适应不同的数据库的类型；另一方面，可以适应不同的数据仓库的写入机制。信令处理数据库操作模块在信令处理的过程中，存在大量的查询、检索等的过程。为了简化系统开发的难度，提高系统开发效率，信令处理系

28、统采用数据库存储各种信令分析的历史信息及一些分析结果。信令处理数据库操作模块的目的就是封装对于信令处理数据库的操作，以便数据库的选型的变化不影响上层逻辑的实现。19 / 30缓存操作模块有多种不同的对数据进行缓存的技术。本模块的目的就是封装数据缓存操作功能，以使得数据缓存技术不同的选择，不影响上层业务。处理层的设计对信令进行处理。一般来说，处理层会有一系列并行的处理单元，每个处理单元中都有一个信令处理线程或者进程。并行的处理单元的形式和数目，根据本地情况确定。处理层有由数据仓库同步模块和一系列的信令处理器组成。信令处理器又包括用户信令视图处理器，基站信令视图处理器，客户网络使用情

29、况处理器，基站人流量处理器，用户停留时间处理器等。根据用户业务需要，可以进一步添加不同的处理器。用户信令视图处理器作用是对输入的信令进行处理，更新用户的信令视图。用户信令视图中保存用户信令的历史信息，主要内容有：IMSIMSISDN用户的基本信息（品牌，年龄层次等）最后一次信令的时间用户的开关机状态当前所在的小区用户进入当前小区的时间用户的最新的IMEI等等基站信令视图处理器作用是对输入的信令进行处理，并更新基站的信令视图。基站的信令视图中保存的是基站信令的历史信息，主要内容有：基站中的用户数基站当前时段的通话人数基站当前时段的通话时长20 / 30基站当前时段的通话次数基站当前时段的计费时长

30、等等客户网络使用情况处理器作用是通过对输入的信令的分析，结合用户信令视图信息，更新客户网络使用情况统计表。基站人流量处理器作用是通过对输入的信令的分析，结合基站信令视图信息，更新基站人流量统计表。用户停留时间处理器作用是通过对输入的信令进行分析，结合用户信令视图信息，更新用户在某小区的停留时间表。数据仓库同步模块该模块的作用是将信令处理系统中的分析结果定期向数据仓库中同步。信令处理系统是一个实时处理的系统。为了尽可能减小对于数据仓库的冲击，信令处理系统每隔一定时间才向数据仓库中同步一次变化了的处理结果。同步的时间间隔可以根据当地情况确定，一般说来，应该在1 分钟或者 1 分钟以上，但应该小于规

31、范中所要求的15 分钟。向数据仓库中同步的内容应该只包含分析的最终结果的变化部分。对于分析所需的中间结果，如用户信令统一视图和基站信令统一视图等，建议不向仓库中更新。信令处理流程21 / 30获取信令，分析发生该信令的IMSI 以及基站 ID根据 IMSI, 到用户信令视图中查找用户的历史信息根据基站 ID ，到基站信令视图中查找对应的基站更新客户网络使用情况表更新基站人流量统计表N更新用户停留时间表。更新用户信令视图更新基站信令视图是否退出？Y数据层的设计用以存储处理层处理得到的结果以及一些处理过程中需要的一些中间结果。为了简化开发的难度，提高开发的效率，建议数据层采用数据库来

32、进行存储和操作。数据库可以选用通用数据库（如MySQL ）或者内存数据库。建议选用内存数据库，推荐使用Asiainfo 的 MDB 或者 Oracle 的 TimesTen。22 / 301.3.5 系统的部署经分系统经分数据仓库444.333信令处理系统信令处理主机1 信令处理主机 2信令处理主机 n222信令处理数据库信令过滤分发系统1信令采集系统信令采集系统网络信令分析系统部署图信令分析系统的部署图如上面所示。说明：1、信令采集系统一般由网络信令厂商开发和部署。2、信令处理系统中采用数据库来进行数据的存储和检索。信令处理数据库根据本地情况，可能单独部署，也可能部署在某一个信令处理主机或者

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

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

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

36、连续发送多个数据包，在 TCP连接保持期间，如果没有数据包发送，需要客户端发链路检测包以维持此连接。通信双方以客户 - 服务器方式建立 TCP连接，用于双方信息的相互提交。当信道上没有数据传输时， 客户端应每隔时间C发送链路检测包以维持此连接，如果连续发送N-1 次后都未得到响应则断开此连接。参数 C、 N 原则上应可配置，现阶段建议取值为：C=2分钟， N=10 。任何一方都可以关闭一个TCP连接，要求双方发送一个终断消息信号关闭自己的通讯信道。一方可以在另一方之前关闭。或者双方同时关闭TCP连接。26 / 301.4.2通信交互过程服务端客户端申 接确 接 接响 制 数据 1 制 数据响 1 送 数据1 送 数据2 送 数据N 数据响 1 数据响 2 数据响 N取消 数据 1取消 数据响 1Active 求Active 响 断开 求断开响 图 4-8-3 通讯交互流程客 户端与服务端的通信主体上包含六部分， 连接消息、 订制业务数据规则消息、 发送业务数据消息、取消业务数据规则消息、链路测试消息、断开消息。1) 客户端发出连接请求。2) 服务端验证客户端的连接请求，并返回连接响应。3)客户端向服务端发送订制业务数据规则消息进行业务数据的订制。每一个客户端每一次连接在同一时段最多只能存在定制一条业务数据规则；如果需要重新定制业务数据规则，必须先取消上