網(wǎng)絡(luò)信令分析

1、1.1 網(wǎng)絡(luò)信令分析1.1.1 技術(shù)框架圖1.1.2 信令數(shù)據(jù)接口接口編碼接口名稱描述94001信令用戶短信收發(fā)消息從信令中產(chǎn)生的用戶收發(fā)短信的記錄94002信令用戶終端更換記錄用戶終端更換記錄94003信令用戶開關(guān)機(jī)頻次記錄用戶開關(guān)機(jī)頻次記錄94004信令用戶開關(guān)機(jī)時(shí)間統(tǒng)計(jì)用戶開關(guān)機(jī)時(shí)間統(tǒng)計(jì)94005信令用戶小區(qū)滯留時(shí)間統(tǒng)計(jì)用戶小區(qū)滯留時(shí)間統(tǒng)計(jì)94006信令關(guān)鍵用戶移動(dòng)軌跡關(guān)鍵用戶移動(dòng)軌跡94007信令基站人流量分析基站人流量分析94008信令基站間人流量分析基站間人流量分析94009信令用戶動(dòng)態(tài)通信行為信息用戶動(dòng)態(tài)通信行為信息1.1.3 信令數(shù)據(jù)處理要求【數(shù)據(jù)量與處理性能】據(jù)調(diào)研，信令數(shù)據(jù)

2、的量大約是清單的4-10倍，【接口方式】文件接口方式?！緮?shù)據(jù)同步時(shí)限】理應(yīng)比清單接口的頻率還要高，規(guī)范要求在15分鐘之內(nèi)?！緮?shù)據(jù)處理流程】信令接口文件主要經(jīng)過數(shù)據(jù)采集、分發(fā)，并行處理、并行分析、并行更新視圖、并根據(jù)觸發(fā)規(guī)則判斷是否需要觸發(fā)實(shí)時(shí)營銷。1.1.4 功能模塊序號模塊名稱功能描述1信令獲取實(shí)時(shí)性要求比較高，且必要嚴(yán)格按照時(shí)間順序。這只能采用單進(jìn)程方式，降低采集間隔時(shí)間的方式，接口協(xié)議仍然為FTP2信令分發(fā)事先為每個(gè)分析模塊建立一個(gè)信令通道。信令分發(fā)模塊每讀取一條信令，根據(jù)信令類型，分發(fā)到一個(gè)或多個(gè)對應(yīng)的“快速通道”的隊(duì)列中。3信令分析處理每個(gè)分析模塊輪詢讀取相應(yīng)的“快速通道”，根據(jù)獲取

3、的信令進(jìn)行一定的計(jì)算，并更新“用戶信令狀態(tài)圖”和“基站信令視圖”。1.1.5 軟件部署整個(gè)軟件部署可與ETL流程調(diào)度部署在同一主機(jī)上，也可單獨(dú)部署。1.1.6 存儲(chǔ)周期信令數(shù)據(jù)由于其自身特點(diǎn)，更新快，因此無須保存很久?！坝脩粜帕顮顟B(tài)視圖”和“基站信令視圖”只需要保留當(dāng)前最新信息即可，而其它接口信息根據(jù)實(shí)際需要設(shè)置最大保存時(shí)間即可。網(wǎng)絡(luò)信令技術(shù)實(shí)現(xiàn)框架網(wǎng)絡(luò)信令處理的技術(shù)實(shí)現(xiàn)細(xì)節(jié)信令數(shù)據(jù)采集原理1.2 網(wǎng)絡(luò)信令分析在經(jīng)營分析系統(tǒng)中引入實(shí)時(shí)/準(zhǔn)實(shí)時(shí)的網(wǎng)絡(luò)信令數(shù)據(jù)將進(jìn)一步豐富系統(tǒng)應(yīng)用能力。它可以幫助市場管理和營銷人員更為準(zhǔn)確的把握用戶的行為特征，實(shí)現(xiàn)基于事件的營銷，為網(wǎng)絡(luò)規(guī)劃優(yōu)化、發(fā)現(xiàn)新的業(yè)務(wù)機(jī)遇提供

4、必要的數(shù)據(jù)支持。Teradata公司在網(wǎng)絡(luò)信令應(yīng)用方面有較為成熟的解決方案，擁有在國外運(yùn)營商N(yùn)IW的成功部署經(jīng)驗(yàn)?；诒竟炯扔薪?jīng)驗(yàn)，并結(jié)合中國移動(dòng)NG-BASS1規(guī)范要求，Teradata提出如下方案建議。 4.8.1技術(shù)框架圖網(wǎng)絡(luò)信令分析方案的體系架構(gòu)如圖所示。為了降低投資，提高現(xiàn)有設(shè)施的利用率，建議復(fù)用現(xiàn)有的小區(qū)短信系統(tǒng)和信令監(jiān)測系統(tǒng)做為獲取信令信息的數(shù)據(jù)源（即信令采集子系統(tǒng)）。信令采集子系統(tǒng)從移動(dòng)網(wǎng)絡(luò)中采集A接口、A-bis接口、Gb接口等的原始信令數(shù)據(jù)，對原始信令進(jìn)行初步解碼和處理，然后按照中國移動(dòng)省級NG1-BASS技術(shù)規(guī)范源系統(tǒng)接口分冊中規(guī)定的接口要求傳送到經(jīng)營分析系統(tǒng)的信令處理

5、服務(wù)器，對所需信令進(jìn)行篩選、歸并、拼接，然后將實(shí)時(shí)營銷信令觸發(fā)數(shù)據(jù)送到TCRM渠道網(wǎng)關(guān)互動(dòng)網(wǎng)關(guān)，將待分析數(shù)據(jù)送到加載服務(wù)器加載入數(shù)據(jù)倉庫系統(tǒng)。依據(jù)數(shù)據(jù)時(shí)限要求不同，信令數(shù)據(jù)可以通過兩種加載方式：實(shí)時(shí)/準(zhǔn)實(shí)時(shí)加載、定時(shí)加載。實(shí)時(shí)/準(zhǔn)實(shí)時(shí)加載通過讀取消息隊(duì)列加載數(shù)據(jù)入庫，定時(shí)加載通過批量文件方式加載數(shù)據(jù)入庫。信令數(shù)據(jù)經(jīng)信令分析模塊處理后用于實(shí)現(xiàn)上層應(yīng)用，包括營銷管理子系統(tǒng)、信令分析應(yīng)用和對現(xiàn)有分析應(yīng)用的增強(qiáng)擴(kuò)展。在全程精確營銷過程中，營銷管理子系統(tǒng)（TCRM）將活動(dòng)的白名單或缺省用戶群規(guī)則傳送到渠道網(wǎng)關(guān)互動(dòng)網(wǎng)關(guān)，當(dāng)與營銷活動(dòng)相關(guān)的實(shí)時(shí)信令數(shù)據(jù)被實(shí)時(shí)傳送到渠道網(wǎng)關(guān)互動(dòng)網(wǎng)關(guān)時(shí)，觸發(fā)外部執(zhí)行過程。有關(guān)T

6、CRM與渠道網(wǎng)關(guān)互動(dòng)網(wǎng)關(guān)的功能介紹請參見有關(guān)章節(jié)。另一方面營銷管理子系統(tǒng)支持將審核后的營銷活動(dòng)白名單、采集區(qū)域設(shè)置（Cell ID或MSC ID）等采集控制信息輸出到信令處理模塊與信令采集子系統(tǒng)（小區(qū)短信系統(tǒng)或信令監(jiān)測系統(tǒng)），優(yōu)化信令數(shù)據(jù)的采集量，減輕信令采集系統(tǒng)、網(wǎng)絡(luò)和加載服務(wù)器的負(fù)荷。圖信令采集技術(shù)框架圖4.8.2信令采集內(nèi)容和容量估算l 原始信令數(shù)據(jù)量估算主要采集用戶位置更新信令、用戶附著網(wǎng)絡(luò)/去附著信令、呼叫接續(xù)信令、raw-CDR等。原始信令數(shù)據(jù)處理流程如下圖所示。MSCMSCMSCDXC信令采集服務(wù)器信令處理服務(wù)器01001010100101二進(jìn)制數(shù)據(jù)二進(jìn)制數(shù)據(jù)將信令數(shù)據(jù)進(jìn)行IP層

7、打包信令采集子系統(tǒng)DCNDCNDCN經(jīng)營分析系統(tǒng)DXC加載服務(wù)器信令處理服務(wù)器圖信令處理數(shù)據(jù)流圖1. DXC將MSC信令收斂后,傳送給信令采集服務(wù)器，DXC最大輸出速率=采集板卡數(shù)*端口數(shù)/板卡*端口速率，假設(shè)信令采集服務(wù)器通暢的忙閑系數(shù)為0.4，則采集服務(wù)器最大輸入速率=DXC最大輸出速率*0.4；2. 信令采集服務(wù)器采集數(shù)據(jù)后,將全部數(shù)據(jù)打包送給信令采集子系統(tǒng)的信令處理服務(wù)器，信令處理服務(wù)器對信令進(jìn)行拆包解碼，并按業(yè)務(wù)需要進(jìn)行處理，輸出ss7解碼后信令消息，如用戶附著、位置區(qū)更新、路由區(qū)更新、呼叫建立、釋放、切換、會(huì)話建立與或原始話單，并送到經(jīng)營分析系統(tǒng)端的信令處理服務(wù)器。3. 經(jīng)營分析系

8、統(tǒng)端的信令處理服務(wù)器根據(jù)業(yè)務(wù)需要選擇一定的規(guī)則對數(shù)據(jù)進(jìn)行過濾，拼接，實(shí)時(shí)觸發(fā)數(shù)據(jù)直接送營銷管理平臺(tái)渠道網(wǎng)關(guān)互動(dòng)網(wǎng)關(guān)實(shí)現(xiàn)全程精確營銷，非實(shí)時(shí)數(shù)據(jù)加載到數(shù)據(jù)倉庫用于實(shí)現(xiàn)信令分析等應(yīng)用。輸出數(shù)據(jù)規(guī)模直接與業(yè)務(wù)規(guī)則相關(guān)，例如營銷活動(dòng)的活動(dòng)名單，營銷活動(dòng)的區(qū)域等。輸出數(shù)據(jù)量=實(shí)時(shí)營銷觸發(fā)數(shù)據(jù)+信令分析數(shù)據(jù)4. 以某200萬用戶的地區(qū)為例，共60塊采集卡，則信令采集子系統(tǒng)信令處理服務(wù)器最大輸入速率=60塊采集卡*8個(gè)端口*2M/s*0.4(忙閑系數(shù))=384M/s=1.3T/H。5. 為減輕經(jīng)分系統(tǒng)信令處理服務(wù)器負(fù)荷，建議信令采集子系統(tǒng)的信令處理服務(wù)器盡可能的完成信令初步篩選處理，降低輸出數(shù)據(jù)量。 l 匯

9、總?cè)霂鞌?shù)據(jù)量估算NG-BASS1中規(guī)定的源系統(tǒng)接口內(nèi)容及估算，存儲(chǔ)周期為1個(gè)月。使用參數(shù)：1500萬用戶，1.4*109條短信，每用戶平均每天出入20個(gè)小區(qū)，每日70%用戶會(huì)有開關(guān)機(jī)操作，小區(qū)數(shù)為1萬，每個(gè)小區(qū)的鄰小區(qū)為6個(gè)。數(shù)據(jù)接口容量估算估算方法用戶短信收發(fā)消息10.3G該類消息與短信話單存在重復(fù)，因此不在倉庫存放，僅將其中的LAC地址和Cell標(biāo)識填入現(xiàn)有的短信話單中，用于改進(jìn)區(qū)域化管理中的相關(guān)算法。月新增容量為8byte*月短信話單量。1.4*109*8用戶終端更換記錄<10G用戶開關(guān)機(jī)頻次記錄6.45G22byte*用戶數(shù)*70%*30天。用戶開關(guān)機(jī)時(shí)間統(tǒng)計(jì)26.82G32by

10、te*用戶數(shù)*2條/天*30天用戶小區(qū)滯留時(shí)間統(tǒng)計(jì)293G與各地平均用戶運(yùn)動(dòng)特征和網(wǎng)絡(luò)覆蓋范圍有關(guān)。35byte*20個(gè)小區(qū)*30天*用戶數(shù)。關(guān)鍵用戶移動(dòng)軌跡268G32byte*用戶數(shù)*20個(gè)小區(qū)*30天基站人流量分析1.28G假設(shè)15分鐘每小區(qū)一條記錄，假設(shè)小區(qū)數(shù)為1萬。48byte*24*30*小區(qū)數(shù)*4基站間人流量分析1.6G假設(shè)15分鐘每小區(qū)一條記錄，每小區(qū)6個(gè)鄰小區(qū)，小區(qū)數(shù)為1萬。40byte*24*30*小區(qū)數(shù)*6(鄰小區(qū)數(shù))*4總計(jì)約為600G/月網(wǎng)絡(luò)信令數(shù)據(jù)量異常龐大，任何一項(xiàng)信令數(shù)據(jù)的采集開啟都會(huì)對網(wǎng)絡(luò)交換機(jī)、DCN、信令采集子系統(tǒng)、信令處理模塊帶來巨大的處理壓力，同時(shí)需要

11、占用大量的容量存儲(chǔ)，因此在信令數(shù)據(jù)的引入前期，本公司建議采用以需求為驅(qū)動(dòng)的接口采集方式。具體而言，包括以下幾類降低采集壓力和存儲(chǔ)壓力方式可供選擇：Ø 實(shí)時(shí)營銷類數(shù)據(jù)將客戶分析及運(yùn)營模塊中市場分析和營銷策劃階段形成的規(guī)則傳遞到信令采集子系統(tǒng)，用于篩選出所需的觸發(fā)信令，然后再將篩選后數(shù)據(jù)送入執(zhí)行觸發(fā)環(huán)節(jié)。Ø 數(shù)據(jù)分析類數(shù)據(jù)根據(jù)分析需求不同，可以采用抽樣、指定用戶抽樣方式降低數(shù)據(jù)量。另外部分分析并不需要持續(xù)每月進(jìn)行，例如用戶滯留小區(qū)分析，可以將采集量較大的接口錯(cuò)月輪流采集。4.8.3接口方式提供批量文件接口方式和實(shí)時(shí)消息兩種方式。實(shí)時(shí)消息方式可以基于消息平臺(tái)實(shí)現(xiàn)，消息平臺(tái)基于規(guī)范

12、所要求的tcp/udp網(wǎng)絡(luò)協(xié)議之上實(shí)現(xiàn)。4.8.4數(shù)據(jù)處理流程數(shù)據(jù)倉庫系統(tǒng)的數(shù)據(jù)加載的策略是根據(jù)具體的數(shù)據(jù)特征制定的。Teradata 為網(wǎng)絡(luò)信令數(shù)據(jù)提供兩種數(shù)據(jù)加載策略：批量文件加載、消息實(shí)時(shí)加載兩種。具體數(shù)據(jù)流程和處理模塊如圖所示。圖-1實(shí)時(shí)信令處理流程實(shí)時(shí)信令處理流程圖-2實(shí)時(shí)信令處理流程在實(shí)際應(yīng)用中，應(yīng)根據(jù)營銷活動(dòng)的需求，設(shè)置信令的篩選處理規(guī)則和實(shí)時(shí)要求，并綜合規(guī)劃所有營銷活動(dòng)、網(wǎng)絡(luò)信令分析所需要的信令處理作業(yè)，提供不同的處理時(shí)限。4.8.5應(yīng)用功能模塊Teradata 的網(wǎng)絡(luò)數(shù)據(jù)倉庫解決方案可以提供以下功能。圖-1 Teradata NIW 解決方案根據(jù)NG-BASS1規(guī)范要求，將首

13、先考慮以下應(yīng)用的建設(shè)：圖-2 中國移動(dòng)信令分析解決方案圖應(yīng)用數(shù)據(jù)存儲(chǔ)周期建議與現(xiàn)有應(yīng)用相同，采用6+1方式。1.3 網(wǎng)絡(luò)信令分析方案網(wǎng)絡(luò)信令分析主要有以下的難點(diǎn)：1. 數(shù)據(jù)量大，對存儲(chǔ)的要求以及寫入效率等會(huì)有極高的要求2. 要求具有實(shí)時(shí)性，因此對于處理的效率會(huì)產(chǎn)生比較嚴(yán)格的要求3. 各種處理過程中的邏輯比較復(fù)雜，如果設(shè)計(jì)不好，會(huì)產(chǎn)生大量重復(fù)的計(jì)算，極大的加大計(jì)算量因此，為了解決上述的問題，提出了基于管道過濾器模式的技術(shù)架構(gòu)，并且支持分布式、伸縮性，以及規(guī)則的擴(kuò)展性等。網(wǎng)絡(luò)信令分析系統(tǒng)的架構(gòu)設(shè)計(jì)原則：1. 充分考慮對于數(shù)據(jù)倉庫的影響。在數(shù)據(jù)倉庫中盡量存儲(chǔ)盡可能少的數(shù)據(jù)，并且盡可能減少或者更好的組

14、織對于數(shù)據(jù)倉庫的訪問。2. 系統(tǒng)擴(kuò)展性的考慮：滿足信令處理需求復(fù)雜多變的情況。在有新的信令處理需求時(shí)，盡可能在不重起系統(tǒng)，不重新部署的情況下進(jìn)行處理。3. 處理效率的考慮：盡可能減少重復(fù)的處理和不必要的查詢等；盡可能利用宿主系統(tǒng)的系統(tǒng)特性（比如一些數(shù)據(jù)存儲(chǔ)或者處理的特性）；4. 系統(tǒng)伸縮性的考慮：通過支持分布式和并行能力的方式滿足系統(tǒng)得伸縮性要求。1.3.1 方案總體介紹網(wǎng)絡(luò)信令分析系統(tǒng)的技術(shù)框架如上圖中所示。 1. 信令采集系統(tǒng)為網(wǎng)絡(luò)信令分析系統(tǒng)提供網(wǎng)絡(luò)信令。一般有網(wǎng)絡(luò)廠商單獨(dú)建設(shè)。2. 數(shù)據(jù)倉庫用以存儲(chǔ)網(wǎng)絡(luò)信令分析得到的結(jié)果，供上層應(yīng)用使用。3. 網(wǎng)絡(luò)信令分析系統(tǒng)由信令過濾分發(fā)系統(tǒng)合信令處

15、理系統(tǒng)和信令處理系統(tǒng)組成。l 信令分發(fā)過濾系統(tǒng)：由于信令數(shù)據(jù)量大，并且有一定的實(shí)時(shí)要求，因此只靠單個(gè)的進(jìn)程甚至單臺(tái)設(shè)備可能無法完成信令數(shù)據(jù)的處理。因此，在進(jìn)行架構(gòu)設(shè)計(jì)的時(shí)候允許用戶采用多個(gè)節(jié)點(diǎn)進(jìn)行信令的并行處理。這里所說的節(jié)點(diǎn)，在實(shí)現(xiàn)中對應(yīng)的是主機(jī)。l 信令處理系統(tǒng)：完成從輸入的單條的信令數(shù)據(jù)到得到最終需要的信令分析結(jié)果的全過程，也是整個(gè)系統(tǒng)中最為復(fù)雜的部分。得到的結(jié)果中需要保存的部分都寫入到數(shù)據(jù)倉庫中。網(wǎng)絡(luò)分析中的數(shù)據(jù)流圖如下圖所示：1.3.2 對于信令采集系統(tǒng)的要求在本方案中不包含對信令采集系統(tǒng)的設(shè)計(jì)及實(shí)現(xiàn)。信令采集系統(tǒng)一般由網(wǎng)絡(luò)廠商實(shí)現(xiàn)。信令數(shù)據(jù)類型及格式要求一般來說，信令采集系統(tǒng)的接口

16、傳輸內(nèi)容應(yīng)包括：用戶開機(jī)、關(guān)機(jī)、主叫開始、主叫掛機(jī)、被叫開始、被叫掛機(jī)、發(fā)送短信、接收短信、位置變更等行為信息和用戶當(dāng)前所在位置區(qū)LAC_ID，小區(qū)代碼CELL_ID，IMSI、IMEI等屬性信息。具體接口傳輸內(nèi)容可參考下表，根據(jù)本地實(shí)施情況具體確定。屬性編碼屬性名稱屬性描述類型備注01city_id本地網(wǎng)標(biāo)識CHAR(3)本地網(wǎng)標(biāo)識02Report_type報(bào)告類型CHAR(1)報(bào)告類型1：語音報(bào)告2：收發(fā)短信報(bào)告3：VLR報(bào)告03SMS_TYPE短信類型NUMBER(3)只對收發(fā)短信報(bào)告有效。（0：mosm發(fā)、2:mtsm收）04VLR_Report_ReasonVLR報(bào)告類型NUMBER

17、(5)只對VLR報(bào)告有效:1 = 正常位置更新2 = 周期性位置更新3 = Imsi attach（手機(jī)開） 4 = Imsi detach （手機(jī)關(guān)）05MSISDNMSISDNVARCHAR2(18)報(bào)告的手機(jī)號碼，只對收發(fā)短信報(bào)告和VLR報(bào)告有效。06A_CELLA_CELLNUMBER(5)語音報(bào)告的主叫的CELL，對收發(fā)短信報(bào)告和VLR報(bào)告為報(bào)告的CELL07A_IMEIA_IMEINUMBER(16)語音報(bào)告的主叫的IMEI ，對收發(fā)短信報(bào)告和VLR報(bào)告為報(bào)告的IMEI08A_IMSIA_IMSINUMBER(16)語音報(bào)告的主叫的IMSI，對收發(fā)短信報(bào)告和VLR報(bào)告為報(bào)告的IMS

18、I09A_LACA_LACNUMBER(5)語音報(bào)告的主叫的LAC，對收發(fā)短信報(bào)告和VLR報(bào)告為報(bào)告的LAC10B_CELLB_CELLNUMBER(5)語音報(bào)告的被叫CELL，對收發(fā)短信報(bào)告和VLR報(bào)告無效。11B_IMEIB_IMEINUMBER(16)語音報(bào)告的被叫IMEI，對收發(fā)短信報(bào)告和VLR報(bào)告無效。12B_IMSIB_IMSINUMBER(16)語音報(bào)告的被叫IMSI，對收發(fā)短信報(bào)告和VLR報(bào)告無效。13B_LACB_LACNUMBER(5)語音報(bào)告的被叫LAC，對收發(fā)短信報(bào)告和VLR報(bào)告無效。14A_DIRECTION_NUMBERA方向號碼VARCHAR2(32)語音報(bào)告及收

19、發(fā)短信報(bào)告的主叫，對VLR報(bào)告無效。15B_DIRECTION_NUMBERB方向號碼VARCHAR2(32)語音報(bào)告及收發(fā)短信報(bào)告的被叫，對VLR報(bào)告無效。16REPORT_TIME報(bào)告生成時(shí)間TIMESTAMP(19)產(chǎn)生報(bào)告的時(shí)間, 24小時(shí)制，YYYY-MM-DD HH:MM:SS信令采集系統(tǒng)信令提供方式要求信令采集系統(tǒng)可以采用文件接口方式或者實(shí)時(shí)接口方式提供信令數(shù)據(jù)。具體的實(shí)現(xiàn)方式根據(jù)當(dāng)?shù)貙?shí)現(xiàn)情況確定。1.3.3 信令過濾分發(fā)系統(tǒng)的設(shè)計(jì)信令過濾分發(fā)系統(tǒng)的作用是對信令采集系統(tǒng)得到的信令進(jìn)行初步的過濾，轉(zhuǎn)換，清洗，并分發(fā)到信令處理主機(jī)上的各個(gè)處理節(jié)點(diǎn)。根據(jù)需要，也可以在該系統(tǒng)中實(shí)現(xiàn)原始信

20、令的存儲(chǔ)。對于有些省份的信令采集系統(tǒng)，本身就支持信令的分發(fā)，這樣就可以不再重復(fù)實(shí)現(xiàn)信令分發(fā)系統(tǒng)。一般可以支持不同IMSI段的信令通過不同的UDP端口進(jìn)行發(fā)送。l 信令分發(fā)的規(guī)則也就是信令分發(fā)系統(tǒng)向信令處理系統(tǒng)的各個(gè)節(jié)點(diǎn)上分發(fā)信令的規(guī)則。由于每個(gè)用戶信令的統(tǒng)計(jì)結(jié)果具有時(shí)間依賴性（比如要計(jì)算一個(gè)用戶在小區(qū)的停留時(shí)間，需要用戶進(jìn)入小區(qū)的時(shí)刻），如果一個(gè)用戶可以在不同的節(jié)點(diǎn)上進(jìn)行處理，就會(huì)造成節(jié)點(diǎn)之間的耦合，需要在節(jié)點(diǎn)之間交換數(shù)據(jù)，造成網(wǎng)絡(luò)流量的增大，并增大設(shè)計(jì)的復(fù)雜度。因此，分發(fā)的規(guī)則應(yīng)該能夠保證同一個(gè)用戶的信令始終被分發(fā)到同一個(gè)節(jié)點(diǎn)上。在信令中，對用戶是通過IMSI來進(jìn)行標(biāo)識的。因此，通過劃分不同

21、的IMSI段，或者通過具有某種特征的IMSI（比如滿足某種形式的正則表達(dá)式），被分發(fā)到相同的節(jié)點(diǎn)上。在確定分發(fā)規(guī)則時(shí)，應(yīng)該確保分發(fā)到各個(gè)節(jié)點(diǎn)上的信令量在一定程度上達(dá)到平衡。l 信令原始數(shù)據(jù)的存儲(chǔ)由于信令的數(shù)據(jù)量比較大，因此在數(shù)據(jù)倉庫中盡量只存儲(chǔ)業(yè)務(wù)有意義的信令分析結(jié)果數(shù)據(jù)，以及一些營銷的用戶接觸數(shù)據(jù)（將來如果有對于營銷活動(dòng)過程中其他指標(biāo)進(jìn)行監(jiān)控的數(shù)據(jù)，可能也會(huì)要求寫入到數(shù)據(jù)倉庫中）。而在數(shù)據(jù)倉庫中不存儲(chǔ)原始的信令數(shù)據(jù)?？梢栽谛帕罘职l(fā)系統(tǒng)保存信令的原始數(shù)據(jù)。原因是如果通過信令處理系統(tǒng)進(jìn)行保存，可能會(huì)使信令的存儲(chǔ)分散在系統(tǒng)的多臺(tái)設(shè)備上，會(huì)對將來的一些分析或者應(yīng)用造成不便；并且信令分發(fā)系統(tǒng)的壓力相對

22、較小，不會(huì)增加信令處理系統(tǒng)的壓力。信令原始數(shù)據(jù)建議以文件的形式進(jìn)行保存。存儲(chǔ)的周期可以根據(jù)規(guī)范的要求，結(jié)合當(dāng)?shù)氐臉I(yè)務(wù)需求以及存儲(chǔ)設(shè)備的狀況確定。存儲(chǔ)的目錄結(jié)構(gòu)設(shè)計(jì)及命名規(guī)范、文件的劃分等結(jié)合本地情況制定。l 信令過濾分發(fā)系統(tǒng)與其他系統(tǒng)的接口方式信令過濾分發(fā)系統(tǒng)與信令采集系統(tǒng)的接口形式由信令采集系統(tǒng)的信令提供方式的實(shí)現(xiàn)確定。一般來說可以以文件方式或者實(shí)時(shí)方式（如通過Socket）實(shí)現(xiàn)。信令過濾分發(fā)系統(tǒng)與信令處理接口的實(shí)現(xiàn)通過scoket方式實(shí)現(xiàn)。1.3.4 信令處理系統(tǒng)的設(shè)計(jì)信令處理系統(tǒng)完成信令的處理，得到信令分析的結(jié)果，并會(huì)將結(jié)果寫入到數(shù)據(jù)倉庫中。為了信令系統(tǒng)的伸縮性，信令系統(tǒng)可以分布在多臺(tái)主

23、機(jī)上執(zhí)行；在同一臺(tái)主機(jī)上，可以有不同的處理單元（一般對應(yīng)進(jìn)程或者不同的線程）并行。信令處理系統(tǒng)由以下四層組成：信令獲取層，功能層，處理層，以及數(shù)據(jù)層。 信令獲取層的設(shè)計(jì)接收信令過濾分發(fā)系統(tǒng)分發(fā)的數(shù)據(jù)（在沒有實(shí)現(xiàn)信令過濾分發(fā)系統(tǒng)的時(shí)候，是接收信令采集系統(tǒng)的信令），并將其進(jìn)行緩存，供處理。 功能層的設(shè)計(jì)是對信令處理系統(tǒng)中的一些常用功能進(jìn)行封裝。功能模塊主要有：數(shù)據(jù)倉庫操作模塊和緩存操作模塊，以及信令處理數(shù)據(jù)庫封裝模塊。l 數(shù)據(jù)倉庫操作模塊主要是對于數(shù)據(jù)倉庫的操作功能的封裝。這一方面，可以適應(yīng)不同的數(shù)據(jù)庫的類型；另一方面，可以適應(yīng)不同的數(shù)據(jù)倉庫的寫入機(jī)制。l 信令處理數(shù)據(jù)

24、庫操作模塊在信令處理的過程中，存在大量的查詢、檢索等的過程。為了簡化系統(tǒng)開發(fā)的難度，提高系統(tǒng)開發(fā)效率，信令處理系統(tǒng)采用數(shù)據(jù)庫存儲(chǔ)各種信令分析的歷史信息及一些分析結(jié)果。信令處理數(shù)據(jù)庫操作模塊的目的就是封裝對于信令處理數(shù)據(jù)庫的操作，以便數(shù)據(jù)庫的選型的變化不影響上層邏輯的實(shí)現(xiàn)。l 緩存操作模塊有多種不同的對數(shù)據(jù)進(jìn)行緩存的技術(shù)。本模塊的目的就是封裝數(shù)據(jù)緩存操作功能，以使得數(shù)據(jù)緩存技術(shù)不同的選擇，不影響上層業(yè)務(wù)。 處理層的設(shè)計(jì)對信令進(jìn)行處理。一般來說，處理層會(huì)有一系列并行的處理單元，每個(gè)處理單元中都有一個(gè)信令處理線程或者進(jìn)程。并行的處理單元的形式和數(shù)目，根據(jù)本地情況確定。處理層有由數(shù)據(jù)倉庫

25、同步模塊和一系列的信令處理器組成。信令處理器又包括用戶信令視圖處理器，基站信令視圖處理器，客戶網(wǎng)絡(luò)使用情況處理器，基站人流量處理器，用戶停留時(shí)間處理器等。根據(jù)用戶業(yè)務(wù)需要，可以進(jìn)一步添加不同的處理器。l 用戶信令視圖處理器作用是對輸入的信令進(jìn)行處理，更新用戶的信令視圖。用戶信令視圖中保存用戶信令的歷史信息，主要內(nèi)容有：n IMSIn MSISDNn 用戶的基本信息（品牌，年齡層次等）n 最后一次信令的時(shí)間n 用戶的開關(guān)機(jī)狀態(tài)n 當(dāng)前所在的小區(qū)n 用戶進(jìn)入當(dāng)前小區(qū)的時(shí)間n 用戶的最新的IMEIn 等等l 基站信令視圖處理器作用是對輸入的信令進(jìn)行處理，并更新基站的信令視圖?；镜男帕钜晥D中保存的是

26、基站信令的歷史信息，主要內(nèi)容有：n 基站中的用戶數(shù)n 基站當(dāng)前時(shí)段的通話人數(shù)n 基站當(dāng)前時(shí)段的通話時(shí)長n 基站當(dāng)前時(shí)段的通話次數(shù)n 基站當(dāng)前時(shí)段的計(jì)費(fèi)時(shí)長n 等等l 客戶網(wǎng)絡(luò)使用情況處理器作用是通過對輸入的信令的分析，結(jié)合用戶信令視圖信息，更新客戶網(wǎng)絡(luò)使用情況統(tǒng)計(jì)表。l 基站人流量處理器作用是通過對輸入的信令的分析，結(jié)合基站信令視圖信息，更新基站人流量統(tǒng)計(jì)表。l 用戶停留時(shí)間處理器作用是通過對輸入的信令進(jìn)行分析，結(jié)合用戶信令視圖信息，更新用戶在某小區(qū)的停留時(shí)間表。l 數(shù)據(jù)倉庫同步模塊該模塊的作用是將信令處理系統(tǒng)中的分析結(jié)果定期向數(shù)據(jù)倉庫中同步。信令處理系統(tǒng)是一個(gè)實(shí)時(shí)處理的系統(tǒng)。為了盡可能減小對

27、于數(shù)據(jù)倉庫的沖擊，信令處理系統(tǒng)每隔一定時(shí)間才向數(shù)據(jù)倉庫中同步一次變化了的處理結(jié)果。同步的時(shí)間間隔可以根據(jù)當(dāng)?shù)厍闆r確定，一般說來，應(yīng)該在1分鐘或者1分鐘以上，但應(yīng)該小于規(guī)范中所要求的15分鐘。向數(shù)據(jù)倉庫中同步的內(nèi)容應(yīng)該只包含分析的最終結(jié)果的變化部分。對于分析所需的中間結(jié)果，如用戶信令統(tǒng)一視圖和基站信令統(tǒng)一視圖等，建議不向倉庫中更新。l 信令處理流程 數(shù)據(jù)層的設(shè)計(jì)用以存儲(chǔ)處理層處理得到的結(jié)果以及一些處理過程中需要的一些中間結(jié)果。為了簡化開發(fā)的難度，提高開發(fā)的效率，建議數(shù)據(jù)層采用數(shù)據(jù)庫來進(jìn)行存儲(chǔ)和操作。數(shù)據(jù)庫可以選用通用數(shù)據(jù)庫（如MySQL）或者內(nèi)存數(shù)據(jù)庫。建議選用內(nèi)存數(shù)據(jù)庫，推薦使用

28、Asiainfo的MDB或者Oracle的TimesTen。1.3.5 系統(tǒng)的部署信令分析系統(tǒng)的部署圖如上面所示。說明：1、信令采集系統(tǒng)一般由網(wǎng)絡(luò)信令廠商開發(fā)和部署。2、信令處理系統(tǒng)中采用數(shù)據(jù)庫來進(jìn)行數(shù)據(jù)的存儲(chǔ)和檢索。信令處理數(shù)據(jù)庫根據(jù)本地情況，可能單獨(dú)部署，也可能部署在某一個(gè)信令處理主機(jī)或者信令過濾分發(fā)系統(tǒng)主機(jī)上。3、信令處理主機(jī)根據(jù)本地的情況，可能采用一臺(tái)或者一臺(tái)以上的主機(jī)。4、部署圖中的各個(gè)接口實(shí)現(xiàn)的方式說明：（1） 信令采集系統(tǒng)和信令過濾分發(fā)系統(tǒng)之間的接口?？梢圆捎梦募涌诨蛘邔?shí)時(shí)接口（如Socket等）實(shí)現(xiàn)。（2） 信令過濾分發(fā)系統(tǒng)與信令處理主機(jī)之間的接口。采用實(shí)時(shí)接口實(shí)現(xiàn)。（3）

29、信令處理主機(jī)和信令處理數(shù)據(jù)庫之間的接口。采用ODBC或者數(shù)據(jù)庫提供的SDK開發(fā)包實(shí)現(xiàn)。（4） 信令處理主機(jī)和數(shù)據(jù)倉庫之間的接口。采用ODBC或者數(shù)據(jù)庫提供的SDK開發(fā)包實(shí)現(xiàn)。1.4 網(wǎng)絡(luò)信令分析給出網(wǎng)絡(luò)信令分析的詳細(xì)技術(shù)框架圖，闡明信令數(shù)據(jù)類型、數(shù)據(jù)量與處理性能、接口方式、數(shù)據(jù)同步時(shí)限、數(shù)據(jù)處理流程、功能模塊、軟件部署等。說明結(jié)果數(shù)據(jù)的類別和存儲(chǔ)周期。網(wǎng)絡(luò)信令分析是NG1-BASS本期建設(shè)的內(nèi)容之一，本期廣東移動(dòng)在經(jīng)營分析系統(tǒng)中的全程精確營銷平臺(tái)引入了網(wǎng)絡(luò)信令接口和網(wǎng)絡(luò)信令分析應(yīng)用。目前已接入地市A接口數(shù)據(jù)。廣東移動(dòng)經(jīng)營分析系統(tǒng)網(wǎng)絡(luò)信令分析應(yīng)用遵循了集團(tuán)公司NG1-BASS規(guī)范實(shí)現(xiàn)，圖4-8-

30、1是集團(tuán)公司NG1-BASS關(guān)于網(wǎng)絡(luò)信令分析功能的框架圖：圖4-8-1網(wǎng)絡(luò)信令分析流程網(wǎng)絡(luò)信令數(shù)據(jù)通過業(yè)務(wù)支撐網(wǎng)中的信令采集子系統(tǒng)實(shí)時(shí)向經(jīng)營分析系統(tǒng)發(fā)送SOCKET報(bào)文信息，通過經(jīng)分系統(tǒng)的CMP信令采集模塊獲取信令數(shù)據(jù)，并設(shè)定每N（可配置，當(dāng)前設(shè)置為10分鐘）分鐘生成一個(gè)數(shù)據(jù)文件，以文件接口的方式接入經(jīng)分系統(tǒng)。經(jīng)分通過裝載模塊加載信令數(shù)據(jù)，經(jīng)由調(diào)度模塊產(chǎn)生作業(yè)鏈，對加載的數(shù)據(jù)進(jìn)行計(jì)算分析，此過程通過全程精確營銷系統(tǒng)關(guān)系數(shù)據(jù)庫的存儲(chǔ)過程實(shí)現(xiàn)。整個(gè)網(wǎng)絡(luò)信令分析過程采用廣東移動(dòng)經(jīng)分系統(tǒng)通用的作業(yè)流程進(jìn)行處理。1.4.1 系統(tǒng)組網(wǎng)結(jié)構(gòu)系統(tǒng)組網(wǎng)結(jié)構(gòu)圖如下圖所示：圖4-8-2 網(wǎng)絡(luò)信令長連接的通信流程雙方

31、（此處所說雙方指全程精確營銷與信令采集系統(tǒng)，下文同）采用SOCKET方式，信令解碼服務(wù)器作為服務(wù)端，精確化營銷系統(tǒng)接口機(jī)作為客戶端。服務(wù)端與客戶端之間進(jìn)行信息交互時(shí)，采用長連接方式。所謂長連接，指在一個(gè)TCP連接上可以連續(xù)發(fā)送多個(gè)數(shù)據(jù)包，在TCP連接保持期間，如果沒有數(shù)據(jù)包發(fā)送，需要客戶端發(fā)鏈路檢測包以維持此連接。通信雙方以客戶-服務(wù)器方式建立TCP連接，用于雙方信息的相互提交。當(dāng)信道上沒有數(shù)據(jù)傳輸時(shí)，客戶端應(yīng)每隔時(shí)間C發(fā)送鏈路檢測包以維持此連接，如果連續(xù)發(fā)送N-1次后都未得到響應(yīng)則斷開此連接。 參數(shù)C、N原則上應(yīng)可配置，現(xiàn)階段建議取值為：C=2分鐘， N=10。 任何一方都可以關(guān)閉一個(gè)TCP

32、連接，要求雙方發(fā)送一個(gè)終斷消息信號關(guān)閉自己的通訊信道。一方可以在另一方之前關(guān)閉?；蛘唠p方同時(shí)關(guān)閉TCP連接。1.4.2 通信交互過程服務(wù)端客戶端申請連接發(fā)送業(yè)務(wù)數(shù)據(jù)1確認(rèn)連接發(fā)送業(yè)務(wù)數(shù)據(jù)2發(fā)送業(yè)務(wù)數(shù)據(jù)N連接響應(yīng)訂制業(yè)務(wù)數(shù)據(jù)響應(yīng)1訂制業(yè)務(wù)數(shù)據(jù)規(guī)則1取消業(yè)務(wù)數(shù)據(jù)響應(yīng)1取消業(yè)務(wù)數(shù)據(jù)規(guī)則1Active響應(yīng)Active請求斷開響應(yīng)斷開請求業(yè)務(wù)數(shù)據(jù)響應(yīng)1業(yè)務(wù)數(shù)據(jù)響應(yīng)2業(yè)務(wù)數(shù)據(jù)響應(yīng)N圖4-8-3 通訊交互流程客戶端與服務(wù)端的通信主體上包含六部分，連接消息、訂制業(yè)務(wù)數(shù)據(jù)規(guī)則消息、發(fā)送業(yè)務(wù)數(shù)據(jù)消息、取消業(yè)務(wù)數(shù)據(jù)規(guī)則消息、鏈路測試消息、斷開消息。1) 客戶端發(fā)出連接請求。2) 服務(wù)端驗(yàn)證客戶端的連接請求，并返回連

33、接響應(yīng)。3) 客戶端向服務(wù)端發(fā)送訂制業(yè)務(wù)數(shù)據(jù)規(guī)則消息進(jìn)行業(yè)務(wù)數(shù)據(jù)的訂制。每一個(gè)客戶端每一次連接在同一時(shí)段最多只能存在定制一條業(yè)務(wù)數(shù)據(jù)規(guī)則；如果需要重新定制業(yè)務(wù)數(shù)據(jù)規(guī)則，必須先取消上一條業(yè)務(wù)數(shù)據(jù)規(guī)則，否則服務(wù)器端返回定制失敗的響應(yīng)。4) 服務(wù)端接受訂制業(yè)務(wù)數(shù)據(jù)規(guī)則請求，并返回訂制是否成功的響應(yīng)。5) 服務(wù)端接受了訂制規(guī)則，并訂制成功后，就開始連續(xù)發(fā)送符合規(guī)則的業(yè)務(wù)數(shù)據(jù)信息到客戶端。6) 客戶端接收業(yè)務(wù)數(shù)據(jù)后返回業(yè)務(wù)數(shù)據(jù)消息的響應(yīng)。7) 客戶端可以根據(jù)實(shí)際情況需要取消指定的訂制業(yè)務(wù)規(guī)則，發(fā)送取消訂制業(yè)務(wù)規(guī)則請求。8) 服務(wù)端接受取消訂制業(yè)務(wù)規(guī)則請求，取消指定的訂制業(yè)務(wù)規(guī)則，并返回消息響應(yīng)。9) 客

34、戶端在信道上沒有數(shù)據(jù)傳輸時(shí)，應(yīng)在間隔固定時(shí)間后發(fā)送鏈路檢測包以維持此連接，服務(wù)器端返回消息響應(yīng)。10) 無論服務(wù)端還是客戶端，任何一方都可以關(guān)閉連接，要求雙方發(fā)送一個(gè)終斷請求消息信號關(guān)閉自己的通訊信道并返回消息響應(yīng)。一方可以在另一方之前關(guān)閉?；蛘唠p方同時(shí)關(guān)閉TCP連接。1.4.3 流量控制消息采用并發(fā)方式發(fā)送，加以滑動(dòng)窗口流量控制，窗口大小參數(shù)W可配置，現(xiàn)階段配置為100，即接收方在應(yīng)答前一次收到的消息最多不超過100條。該滑動(dòng)窗口機(jī)制主要基于CMP_DATA和CMP_DATA_RESP的消息交互進(jìn)行。1.4.4 信令分析方法圖4-8-4 網(wǎng)絡(luò)信令分析方法廣東移動(dòng)經(jīng)分系統(tǒng)信令分析模塊中，信令分析模塊由一系列SQL存