網(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)機頻次記錄用戶開關(guān)機頻次記錄94004信令用戶開關(guān)機時間統(tǒng)計用戶開關(guān)機時間統(tǒng)計94005信令用戶小區(qū)滯留時間統(tǒng)計用戶小區(qū)滯留時間統(tǒng)計94006信令關(guān)鍵用戶移動軌跡關(guān)鍵用戶移動軌跡94007信令基站人流量分析基站人流量分析94008信令基站間人流量分析基站間人流量分析94009信令用戶動態(tài)通信行為信息用戶動態(tài)通信行為信息1.1.3 信令數(shù)據(jù)處理要求【數(shù)據(jù)量與處理性能】據(jù)調(diào)研，信令數(shù)據(jù)

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

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

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

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

6、CRM與渠道網(wǎng)關(guān)互動網(wǎng)關(guān)的功能介紹請參見有關(guān)章節(jié)。另一方面營銷管理子系統(tǒ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ù)器的負荷。圖4.8.1信令采集技術(shù)框架圖4.8.2信令采集內(nèi)容和容量估算l 原始信令數(shù)據(jù)量估算主要采集用戶位置更新信令、用戶附著網(wǎng)絡(luò)/去附著信令、呼叫接續(xù)信令、raw-CDR等。原始信令數(shù)據(jù)處理流程如下圖所示。MSCMSCMSCDXC信令采集服務(wù)器信令處理服務(wù)器01001010100101二進制數(shù)據(jù)二進制數(shù)據(jù)將信令數(shù)據(jù)

7、進行IP層打包信令采集子系統(tǒng)DCNDCNDCN經(jīng)營分析系統(tǒng)DXC加載服務(wù)器信令處理服務(wù)器圖4.8.2信令處理數(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ù)器對信令進行拆包解碼，并按業(yè)務(wù)需要進行處理，輸出ss7解碼后信令消息，如用戶附著、位置區(qū)更新、路由區(qū)更新、呼叫建立、釋放、切換、會話建立與或原始話單，并送到經(jīng)營分析系統(tǒng)端的信令處理服務(wù)

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

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

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

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

12、現(xiàn)，消息平臺基于規(guī)范所要求的tcp/udp網(wǎng)絡(luò)協(xié)議之上實現(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ù)據(jù)流程和處理模塊如圖所示。圖4.8.4-1實時信令處理流程實時信令處理流程圖4.8.4-2實時信令處理流程在實際應(yīng)用中，應(yīng)根據(jù)營銷活動的需求，設(shè)置信令的篩選處理規(guī)則和實時要求，并綜合規(guī)劃所有營銷活動、網(wǎng)絡(luò)信令分析所需要的信令處理作業(yè)，提供不同的處理時限。4.8.5應(yīng)用功能模塊Teradata 的網(wǎng)絡(luò)數(shù)據(jù)倉庫解決方案可以提供以下功能。圖4.8.5-1 Teradata

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

14、數(shù)據(jù)倉庫中盡量存儲盡可能少的數(shù)據(jù)，并且盡可能減少或者更好的組織對于數(shù)據(jù)倉庫的訪問。2. 系統(tǒng)擴展性的考慮：滿足信令處理需求復雜多變的情況。在有新的信令處理需求時，盡可能在不重起系統(tǒng)，不重新部署的情況下進行處理。3. 處理效率的考慮：盡可能減少重復的處理和不必要的查詢等；盡可能利用宿主系統(tǒng)的系統(tǒng)特性（比如一些數(shù)據(jù)存儲或者處理的特性）；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ò)廠商單獨建設(shè)。2. 數(shù)據(jù)倉庫用以存儲網(wǎng)絡(luò)信令分析得到的結(jié)果，供上

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

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

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

18、告的主叫的IMSI，對收發(fā)短信報告和VLR報告為報告的IMSI09A_LACA_LACNUMBER(5)語音報告的主叫的LAC，對收發(fā)短信報告和VLR報告為報告的LAC10B_CELLB_CELLNUMBER(5)語音報告的被叫CELL，對收發(fā)短信報告和VLR報告無效。11B_IMEIB_IMEINUMBER(16)語音報告的被叫IMEI，對收發(fā)短信報告和VLR報告無效。12B_IMSIB_IMSINUMBER(16)語音報告的被叫IMSI，對收發(fā)短信報告和VLR報告無效。13B_LACB_LACNUMBER(5)語音報告的被叫LAC，對收發(fā)短信報告和VLR報告無效。14A_DIRECTION

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

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

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

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

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

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

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

26、信令進行處理，并更新基站的信令視圖?；镜男帕钜晥D中保存的是基站信令的歷史信息，主要內(nèi)容有：n 基站中的用戶數(shù)n 基站當前時段的通話人數(shù)n 基站當前時段的通話時長n 基站當前時段的通話次數(shù)n 基站當前時段的計費時長n 等等l 客戶網(wǎng)絡(luò)使用情況處理器作用是通過對輸入的信令的分析，結(jié)合用戶信令視圖信息，更新客戶網(wǎng)絡(luò)使用情況統(tǒng)計表。l 基站人流量處理器作用是通過對輸入的信令的分析，結(jié)合基站信令視圖信息，更新基站人流量統(tǒng)計表。l 用戶停留時間處理器作用是通過對輸入的信令進行分析，結(jié)合用戶信令視圖信息，更新用戶在某小區(qū)的停留時間表。l 數(shù)據(jù)倉庫同步模塊該模塊的作用是將信令處理系統(tǒng)中的分析結(jié)果定期向數(shù)據(jù)倉

27、庫中同步。信令處理系統(tǒng)是一個實時處理的系統(tǒng)。為了盡可能減小對于數(shù)據(jù)倉庫的沖擊，信令處理系統(tǒng)每隔一定時間才向數(shù)據(jù)倉庫中同步一次變化了的處理結(jié)果。同步的時間間隔可以根據(jù)當?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è)計用以存儲處理層處理得到的結(jié)果以及一些處理過程中需要的一些中間結(jié)果。為了簡化開發(fā)的難度，提高開發(fā)的效率，建議數(shù)據(jù)層采用數(shù)據(jù)庫來進行存儲和操作。數(shù)據(jù)庫可以選用通用數(shù)據(jù)庫

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

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

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

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

32、值為：C=2分鐘， N=10。 任何一方都可以關(guān)閉一個TCP連接，要求雙方發(fā)送一個終斷消息信號關(guān)閉自己的通訊信道。一方可以在另一方之前關(guān)閉?；蛘唠p方同時關(guān)閉TCP連接。1.4.2 通信交互過程服務(wù)端客戶端申請連接發(fā)送業(yè)務(wù)數(shù)據(jù)1確認連接發(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) 客

33、戶端發(fā)出連接請求。2) 服務(wù)端驗證客戶端的連接請求，并返回連接響應(yīng)。3) 客戶端向服務(wù)端發(fā)送訂制業(yè)務(wù)數(shù)據(jù)規(guī)則消息進行業(yè)務(wù)數(shù)據(jù)的訂制。每一個客戶端每一次連接在同一時段最多只能存在定制一條業(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ù)實際情況需要取消指定的訂制業(yè)務(wù)規(guī)則，發(fā)送取消訂制業(yè)務(wù)規(guī)則請求。8) 服務(wù)端接受取消訂制業(yè)

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