基于SDTP的全量信令接收方案的研究*

胡汝榮，雒江濤，羅 鵬

（重慶郵電大學通信網測試技術工程研究中心 重慶 400065）

1 引言

信令監測系統是保障移動通信網絡高質量運行、快速響應用戶投訴、提升用戶感知的重要技術手段[1]。目前電信運營商均建立了較為完備的信令監測系統[2～4]，但這些監測系統都存在各層之間廠商私有化程度較高、模塊間采用私有化傳輸協議、架構封閉接口不開放等限制數據和資源共享的問題。隨著電信業務的迅速發展，對信令監測系統提出了更高的要求，信令監測系統正向著規范化、信息共享和基于云計算的方向發展[5～7]。

目前對信令監測系統的研究重點多在于信令的采集、信令的分析處理和結果的統計分析等方面[2～4]，對信令監測系統分層間接口的研究較少，參考文獻[1]提出了一種向規范化演進的信令監測系統架構，沒有具體提出分層接口的設計與實現方案。

本文基于 SDTP（shared data transport protocol）[8]提出一種適用于規范化的信令監測系統的全量信令接收方案。該方案設計了SDTP通信、排序和分流功能，滿足了采集接口和信令共享平臺間接口的功能需求，促進了信令監測系統規范化的演進。

2 信令監測系統及接口

2.1 系統架構

信令監測系統的總體架構如圖1所示。信令監測系統從結構上可劃分為采集層、共享層和應用層，每部分的功能概述如下。

圖1 信令監測系統架構

·信令采集層：負責通信網中不同類型鏈路承載的全量信令數據，并將采集到的信令數據通過匯聚后傳輸到共享層。

·共享層：負責從底層接收全量信令數據、存儲、解析并向應用層提供CDR數據，需要完成和采集層與應用層的交互。

·應用層：主要利用共享層解析后的信令數據進行

統計分析，從而實現業務應用（小區短信、手機報等）和信令監測系統應用（流量分析、用戶行為分析等）。

2.2 IF1接口

IF1接口是采集層和共享層之間交互的接口，也是采集層的匯聚設備和共享層接入模塊間的接口[8]，主要功能是進行全量信令數據的傳輸。該接口的數據傳輸具有如下特點：實時性高、數據量大、過程簡單。

在工程應用中，常選擇的文件傳輸協議是FTP（file transfer protocol），本文選擇SDTP作為全量信令數據傳輸協議。SDTP是由中國移動提出的一種實時信令共享協議，FTP和SDTP的對比見表1。

表1 FTP和SDTP的對比

FTP和SDTP都采用客戶端和服務端模式工作，且都可以實現客戶端主動上傳文件到服務端，都采用Socket方式進行通信。FTP是把本地端已經保存好的文件傳送到服務端，如果采用FTP，則需要在采集層的匯聚設備中增加數據存儲設備，而且數據存儲需要一定的時間，不能達到采集數據實時發送的目的，并且SDTP過程更加簡單。

SDTP消息結構及流程參見參考文獻[8]，在此不贅述。

3 接收方案設計

全量信令接收方案如圖2所示。該方案將整個接收分為協議通信模塊、排序模塊和分流模塊，可以使功能獨立化，便于維護。協議通信模塊是SDTP服務端的實現，完成與SDTP客戶端的交互；排序模塊從協議通信模塊中獲取全量信令消息，進行數據分組排序；分流模塊按某種維度完成全量信令數據的多路存儲。

3.1 協議通信模塊

根據SDTP的功能需求，接收模塊主要完成采集層匯聚設備中SDTP客戶端的連接請求、認證、連接狀態檢查、全量信令數據的接收。本文采用面向對象的方式，將不同的功能封裝成一個類，向外部提供調用接口。各個類介紹如下。

圖2 信令接收方案設計

·CSDTP server類：SDTP服務端類，主要接口有開始監聽StartListen()、停止監聽StopListen()、斷開所有客戶端的連接DisconnectAllClient()等。

·CSDTP agent類：客戶端代理類，功能是和客戶端進行交互，主要接口有同步發送消息SendMsgSyn()、異步發送消息SendMsgAsyn()、斷開與客戶端的連接DisConnect()等。

·CSDTP agent Rcvtask類：接收線程類，功能是接收客戶端發送的消息和數據，主要接口有接收RecvFromPeer()、判斷接收線程是否在運行IsRunning()等。

·CSDTP agent send task類：功能是客戶端發送響應消息，主要接口有同步發送消息SendDataSyn()、異步發送消息SendDataAsyn()、發送消息線程是否在運行IsRunning()等。

·CSDTP listener類：監聽類，功能是監聽客戶端的連接，主要接口有開始監聽Start()和結束監聽Stop()等。該類負責監聽客戶端的連接，如果發現有客戶端申請連接，則啟動認證，若認證成功，則會實例化一個代理類負責與該客戶端交互。

由于實際的客戶端會有多個，并且全量信令數據量較大，本文采取多線程的工作方式，以提高工作效率，包括服務端主線程、監聽線程和多對發送線程、接收線程（一個代理端對應一個發送線程和接收線程）。接收模塊偽代碼如下：

3.2 排序模塊

由于采集層很難實現精確的時間同步，所以接收到的全量信令數據分組可能存在亂序問題。數據排序模塊是將數據分組按數據分組頭中的時間戳重新進行排序。本模塊結合散列索引技術，提出了一種高效、快速的數據排序方法。數據排序有以下幾個關鍵技術。

（1）數據緩存組織結構

用鏈表結構管理每條數據排序時在內存中的存儲，數據在鏈表中以數據分組中的時間按從小到大順序存儲。鏈表的節點包含某條全量信令數據本身以及從該條數據中提取出的時間信息，該時間信息用于判斷某條消息在鏈表中的存放位置。

（2）數據分組在數據緩存中快速定位

通過鏈表查詢的方式在數據緩存中定位數據分組，應該存放的位置的時間復雜度為O(N)，效率低下。通過設計一個輔助查詢散列表[9]可提高查詢效率。該散列表key值由數據分組時間戳中的s、μs和m_scale（時間窗口大小，取經驗值，一般為100）按式（1）計算得到。

散列表節點存儲的是該時間窗口內，時間戳最大的數據分組在鏈表中的位置。在查找某個數據分組在數據緩存鏈表中的位置時，利用本數據分組時間戳計算key值，查詢到該數據分組屬于某個時間窗口，然后在該時間窗口內比較得到該數據分組應該插入的具體位置。用輔助散列表方式定位的時間復雜度為O(1)。

（3）從緩存中讀出數據條件

因為數據分組在數據緩存鏈表中是按時間戳由小到大的順序存儲的，判斷緩存中首尾分組時間戳之差與系統設定排序的亂序范圍，如果前者大于后者，表示排序范圍已經超過系統值，取出首數據分組存盤。

3.3 分流模塊

分流模塊是將匯聚后的全量信令數據按一定規則分成多路存儲。數據分流的基本原則為：從同一網元設備采集到的數據應存儲到相同的路徑下，這樣做是為了保證多個信令處理進程單獨處理各路信令數據時能夠正常進行。

本文提出按通信網絡中網元的維度進行分路，這樣可以滿足各路流量均衡的要求。現以GSM網絡A+Abis接口為例，A+Abis信令從網元設備BSC采集得到，所以按BSC維度進行分路。從A+Abis的全量信令中，可以得到采集機號、板卡號、端口號、EI號和時隙等信息。通過分析采集機號、板卡號和端口號等信息，可以得到某幾個字段和BSC的映射關系，將這一映射關系保存到XML文件中供分路使用。

分流模塊在接收到排序模塊輸出的順序數據分組時，首先從數據分組頭中提取出確定分路信息的相關字段，然后以此查找XML文件獲取該數據分組應存儲到哪一路。為了提高XML查詢效率，借助散列索引，選取分路信息字段為key，建立分路信息的散列索引表。

4 方案測試驗證

本方案的測試為局域網內的測試，測試環境如圖3所示。選擇兩臺部署有SDTP客戶端程序的小型服務器模擬匯聚設備，服務器中存儲有大量從現網采集的原始信令數據。一臺部署有按本方案實現的信令接收程序的中型服務器，模擬信令共享平臺的接收服務器。

接收服務器輸出日志如下：

2013-4-22 15:38:12.673@LM_INFO MsgCapture start!

2013-4-22 15:38:12.681 @LM_DEBUG Listen on 192.168.2.100.7500 successfully!

Listen on 192.168.2.100.7501 successfully!

2013-4-22 15:42:53.798@LM_DEBUG CSDTPAgent1 start!

2013-4-22 15:42:55.087 @LM_INFO Client 192.168.2.2:6000 has connected with server!

2013-4-22 15:42:55.096@LM_INFO Negotiation passed.

2013-4-2215:42:55.098@LM_INFO Receivedauth message,username=test1,pwd=123

2013-4-22 15:42:55.099@LM_INFO LinkAuth passed!

2013-4-22 15:42:55.103@LM_INFO Received Notify SignalData Request!

2013-4-22 15:42:55.105@LM_INFO Ready to Receive SignalData!

…

從日志中可看到，SDTP服務端程序啟動時，首先啟動了兩個監聽線程，端口分別為7500和7501，當服務端監聽到有客戶端連接服務器時，服務端啟動客戶端代理CSDTP agent1；接著客戶端成功與服務端代理連接，當TCP連接建立后，開始版本協商和客戶端鑒權，二者都順利通過；最后是全量信令數據的發送過程。

對于排序功能的測試，本文用到了自己開發的數據分組亂序檢查工具（其原理是比較相鄰數據分組的時間戳），對未加載排序模塊和加載排序模塊后的數據進行檢測，結果見表2。

從表2中可看到，在沒有加載排序模塊時，服務端收到的數據分組存在大量亂序，所占比例為10.18%左右。加載排序模塊后，排序時間為3 s時，亂序時間小于3 s的已經被重新排序，但仍然存在亂序時間大于3 s的情況，亂序平均值為8.72 s，比未加載排序模塊時有所增加，表明亂序時間大于3 s的數據分組比例較大，測試出亂序分組的比例為8.74%，比未加載排序模塊時下降了1.44%；排序時間設置為10 s時，由于數據分組最大的亂序時間小于10 s，所以所有數據分組均被排序模塊排為正序。

圖3 測試環境

表2 不同排序時間下亂序統計

5 結束語

基于SDTP提出的全量信令接收方案是一個行之有效的方案，解決了信令監測系統采集層和信令共享平臺間的信令傳輸私有化、原始信令數據共享率低下問題。該方案設計的三大功能基本能滿足信令共享平臺接收信令數據的需要，且數據接收能力強。未來的研究方向是如何將該方案與云計算和云存儲相結合，并將結合后的方案運用于基于云計算的信令監測系統中。

1 韋薇，張揚.信令監測系統架構規范的演進.電信工程技術與標準化,2011(4):48～52

2 李勇,雒江濤,黃建.軟交換網絡集中監測系統SIP監測方案.電訊技術,2012,52(1):101～104

3 史鵬利.河北聯通移動分組網信令監測系統的研究及設計.北京郵電大學碩士學位論文,2012

4 方曉農.信令監測系統全國聯網方案探討.數據通信,2012(5):38～45

5 陳璟飛.綜合信令業務支撐云平臺.電信網技術,2013(1):58～62

6 徐雷,張云勇,陸斌等.基于云計算的信令監測平臺研究.電信網技術,2011(5):1～4

7 中國移動通信集團公司.信令監測系統接口規范——信令采集網關分冊,2012

8 嚴蔚敏,吳偉民．數據結構．北京：清華大學出版社,2003