林蓓，李春梅，李秉智 重慶郵電學院
摘 要：七號信令網是電信網的重要組成部分，其運行質量直接影響到電信網及其各種業務的運行穩定性和實際效益。為了保證七號信令網的正常高效運行，七號信令集中監測系統已成為七信號進行集中監測和管理的重要工具，文章在分析七號信令集中監測系統框架的基礎上，提出了在系統中建立多個數據庫和數據倉庫相結合的方案進行數據管理，然后對數據管理系統的組成結構、邏輯結構、數據存儲與應用做了進一步的研究。
關鍵詞：七號信令；數據倉庫；關系型數據庫
0 引 言
七號信令網是電信網的三大支撐網之一，是電信網的重要組成部分，是發展綜合業務、智能業務以及其他各種新業務的必備條件。到目前為止，我國已經組成了由高級信令轉接點（HSTP）、低級信令轉接點（LSTP）和大量的信令點（SP）組成的三級七號信令網，使得七號信令網真正成為名副其實的電信網的神經網和支撐網。為了保證七號信令網的正常高效運行，七號信令集中監測系統作為對七號信令進行集中監測和管理的重要工具應運而生。七號信令集中監測系統通過直接采集七號信令的原始數據進行分析處理，提供對七號信令網實時動態監測，以及各種用戶信令的各種微觀分析［1］。目前，七號信令集中監測系統的功能模塊已覆蓋了固定電話網和GSM移動通信網的所有信令監測項，并正在向GPRS和CDMA移動通信網的集中監測進行功能擴展。
在七號信令網的監測中會不間斷地產生大量的業務數據，為了完成對這些數據的有效管理，建立數據庫則必不可少。對于單個信令點監測可采用關系型數據庫，因這已是很成熟的技術，故對孤立的單個信令點或信令轉接點的監測易實現，但對于涉及全網的監測和復雜查詢，就需要使用數據倉庫技術對來自各單個監測點的結果進行綜合，并由它來對涉及多個點的信令業務進行監測顯示。如何應用數據庫與數據倉庫技術結合來解決多級信令網監測中的數據管理問題將是討論的重點，在提出自己的實施方案后，將圍繞它在數據管理系統的組成結構、邏輯結構、數據存儲與應用上分別論述。
1 集中監測系統總體結構
系統總體設計采用自頂向下的綜合設計方式，在系統實現上采用自頂向下及自底向上相結合的開發方式，總體采用層次模塊化結構。 七號信令集中監測系統通過采集原始信令信息，實現從單個局站到省市級信令網的集中監測。為了完成系統的實時監測和告警顯示功能，監測系統劃分為信令采集子系統、節點機及其掛接的查詢終端子系統、中心站及其掛接查詢終端子系統（見圖1）。各子系統間的通信連接視其遠近可采用局域網或廣域網，在廣域網中通信兩端使用網絡通信中間件，以保證各種業務應用在不同系統平臺之間穩定可靠，完整地傳送、交換數據信息。
采集子系統主要由多個信令監測子架構成，完成數據采集與數據預處理的功能，并將預處理的數據送往節點機服務器中。
節點機及其掛接的查詢終端子系統中，節點機服務器通過局域網與多個信令監測子架相連接，對采集的信息進行分析處理后，生成記錄，交由數據庫管理，同時監控與中心站服務器間的數據傳送，而該節點機所掛接的查詢終端作為數據顯示的前端部件，完成較小信令網范圍內的各項系統功能。
中心站服務器通過廣域網從各個節點機接受數據，進行綜合分析和匯總處理，在數據倉庫中保存全網的業務記錄，并將記錄提供給其掛接的查詢終端，生成圖形顯示，另外中心站還提供與其它管理系統進行信息互通的功能。
2 集中監測系統中的數據庫設計
2．1 數據庫與數據倉庫組成的數據管理系統
七號信令集中監測系統的數據處理采用分層結構。若信令監測子架中完成的數據預處理為第一層；節點機服務器上的數據庫就為第二層；中心站服務器上的數據倉庫為第三層。除了第一層外，其它兩層都用于完成數據管理。在每個節點機中完成數據的初步分析，生成各種關系的記錄，并保證一定數量的客戶端的實時查詢要求，有必要在其上建立一個獨立的關系型數據庫。而中心站主要對各節點機數據庫中的記錄進行抽取，合成全局模式下的記錄，并滿足客戶端的聯機分析處理要求，這可以通過在中心站中建立數據倉庫來實現。
在節點機中要選擇合適的數據庫產品，目前的關系型數據庫產品主要有大中小3種類型。大型關系數據庫有oracle和DB2，中型關系數據庫有Microsoft的SQLServer，小型的有Access和VisualFoxpro，大型關系數據庫在安全性、穩定性及多用戶并行處理性能方面比中小型數據庫有明顯的優勢。節點機需要對信令點進行不間斷的監測，這要求系統有較高的穩定性；并且數據更新與多客戶端顯示查詢會交織產生，因而需要數據庫管理系統有很強的并行處理能力。此外，大型關系數據庫產品的開發工具包中還提供了C／C＋＋、Java、sql等應用編程的跨平臺通用接口，這無疑增強了系統實現上的多樣性與可移植性［2］。中心站連接多個節點機組成星型結構，可將多個節點機中收集來的呼叫信息加以識別與合成，來產生全網監測的呼叫業務消息。并且，這些全網監測信息在產生后就不再更改（除了超過五年的數據要清空外），同時所連接客戶端提出的是聯機分析處理（OLAP）請求。這就要求將多個節點機中的消息按統一格式存儲于中心站上，所以將各節點機作為數據源，在中心站上建立數據倉庫是完成本系統監測任務的要求。
由多個大型關系數據庫與數據倉庫構成的星形結構數據管理系統有以下優點。
（1）層次化的管理結構，節點機上大型關系數據庫為第一層，完成對本節點所監測的原始信令信息與分析所得的關系元組的管理；中心站數據倉庫為第二層，完成對各節點機的消息的集中式管理；
（2）較強的事務處理能力，用節點機對客戶端的單點查詢與更新要求作出有效回應，用中心站數據倉庫滿足客戶端對全網聯機分析處理（可被視為長事務）的要求。
2．2 數據存儲的邏輯結構
2．2．1 節點機數據庫上的關系集合與組織
節點機直接監測信令點，故節點機上數據庫中的關系集合最復雜，按各種關系的用途與內容可將其分為以下3類。
（1）首先數據庫中需記錄所監測的信令點、信令鏈路、信令采集子架和節點機本身的信息，這類型關系元組的正確生成是信令消息成分的提取和客戶端的查詢的先決條件。
（2）七號信令系統本身是由具有類似OSI層次化模型的多層協議所構成。以GSM系統為例，從實現應用層功能的MAP，CAP，INAP協議，到實現表示層、會話層功能的TCAP協議，一直到實現傳輸層功能的SCCP協議和實現網絡層、數據鏈路層、物理層功能的MTP協議，每種協議都有其固定的數據包格式，而上層產生的數據包又被下層的數據包所封裝。實際采集到的一條完整的信令消息嵌套式地包含了多種協議的數據包包頭和終端的用戶信息，所以分析一條完整的信令消息可以得到對應不同協議的各個關系的元組。這類的關系集合實用于協議初步分析的結果保存。 （3）第三類關系集合用于對信令消息的進一步分析和記錄保存，并且可以分為兩類：一類是將多條信令消息按一次呼叫過程或其它某種信令過程相結合所分析得出關系元組，這類關系元組有些是描述了TUP，ISUP的詳細呼叫記錄，有些則記錄了應用層協議（如MAP、CAP、A接口）的詳細事務，通常這類關系集合也是中心站數據倉庫需要的邏輯模式；另一類關系集合是在單條信令消息分析時，將數據鏈路和各協議層所出現的錯誤信息提出，生成多種告警關系。該類關系對實時系統監測是十分重要的。
2．2．2 中心站數據倉庫上的存儲結構
客戶端在對中心站的事務請求中關心的是較長時間段內信令點間的信令消息交互的情況，而不是某時刻單條信令消息的分析結果。故數據倉庫中的數據就可以保持較高的密度級，而由各個數據庫存放信令消息分析的細節。具體而言，中心站將多個節點機中的分析結果抽取合成為詳細呼叫記錄，并以此為事實表，將信令點記錄、信令業務設置、數據入庫時間為維表來構成適合聯機分析處理的多維數據存儲結構［3］。 2．3 數據的更新策略
數據在各節點機的更新主要有2種情況，一是用戶在對數據庫查詢后，對基本設置類表項的更改，這里須考慮給用戶所用帳號賦予更新某些對象的權限，并注意多個用戶并行地對相同表項提出更新要求時，選用適當的數據庫并發控制機制，以滿足應用的實時性與并行性要求［4］。另一種更新是持續的大量的信令消息分析后的表項更新，在這種情況下一個表在一小時內會多加入幾十萬條全新的記錄，并且為了保證數據庫只保留3個月的數據，還需對當前系統時間的前3個月的數據進行清除。這些更新要求在一天的0點至8點很少外，在其他16 h內都會保持較多數據量的更新操作。此時采用單條數據刪除與插入會造成較大的系統時延，一種改進的辦法就是利用此類表都采用了入庫時間作為主鍵，將表內的表項按入庫時間每小時分一個區來存儲，在系統運行時直接把前3個月某小時的數據區整個清除掉，再在新系統的當前時間分區內插入新的表項。如果再配合上節點機服務器的CPU與冗余磁盤陣列，可以使此類的數據更新有較高的并行性［5，6］。
中心站的數據倉庫中數據的更新是在特定時段內完成的，而在較長時段內的數據倉庫主要在處理客戶端的復雜查詢。這就決定了數據倉庫中的數據雖也具有一定的實時性，但比節點機數據庫中在信令網運行時同步產生的數據就有一定滯后，不過這種滯后尚在系統應用許可的范圍內。因此我們就選擇在每日的0點至8點（即節點機數據庫中很少有新數據入庫的時候）對各節點機數據庫中的數據進行抽取合成，將產生的綜合數據放于數據倉庫中，到時也會將超過5年的過時數據清理掉。
2．4 數據倉庫的應用實現
系統在用于信令網監測的實施時，對信令網管理用戶提出的聯機分析處理任務可由客戶端、中心站共同來完成。這其中數據倉庫的建立，本系統采用了并行關系數據庫來作為數據倉庫引擎，完成數據管理；用中心站應用層軟件完成數據抽取；用中心站所掛接的客戶端來實現數據表現［3］。數據倉庫的應用實現如下。
（1）應用層軟件利用中心站與節點機的通信通道連接各個數據庫和數據倉庫后，在特定時段內將各數據庫中的記錄查詢結果集中于中心站，然后根據源、目的信令點與信令時序分離于各節點機的分析結果排序、整合，待完成生產記錄的完整性、一致性檢驗后，交由數據倉庫引擎入庫。
（2）數據倉庫引擎根據更新表空間在磁盤陣列上的位置，由散列算法算出新紀錄的可放入的空閑空間地址，然后跳過操作系統由磁盤控制器直接在多個磁盤上并行寫入新記錄，另一方面，當數據倉庫引擎接受到查詢請求，會根據合理的查詢計劃，利用磁盤陣列并行地讀出符合要求的記錄，數據倉庫引擎由此完成數據管理的基本任務。
（3）客戶端選用適合信令網管理的數理統計方法，將數據倉庫中查詢的結果進行統計，并算出指點網段的性能監測參數，再以表格或直方圖的形式表示出來，以此完成數據倉庫的數據表現。
3 數據管理系統特性
通過對七號信令監測系統的組成成分的分析，選擇了在節點機和中心站上建立數據庫和數據倉庫，由此構成了適合系統要求的數據管理系統。對于所設計的數據管理系統，具有以下特性。
（1）系統商業化程度較高。無論是節點機上的大型關系數據庫還是中心站上的并行關系數據庫都是完善的數據庫產品，它們的管理系統由緊密結合在一起的各功能模塊組成，包括編譯器、執行引擎、并發控制、日志管理、緩沖和磁盤管理器等；除了能夠快速執行用戶的數據定義和數據管理請求外，還能順利地完成日志管理、數據庫備份和恢復等工作。
（2）較強的查詢能力。為了系統的高可用性，可以同時運行數據庫服務器的多個實例對一個數據庫進行訪問。并可將用戶的查詢細分為全網綜合查詢與單信令點查詢，并在中心站和節點機上分別完成。
（3）數據庫的完善安全機制。數據庫系統能夠嚴格控制數據與存儲資源的分配使用，并對用戶進行權限管理，對數據庫系統內部活動進行審計。
（4）較好的應用擴展性。由于設計了以中心站數據倉庫為中心，結合多個節點機的關系型數據庫的數據管理體系，在系統監測對象由GSM變為GPRS或者是CDMA時，只在節點機和中心站更新協議分析模塊即可完成監測系統的平滑升級。
參考文獻
［1］ VI．0－2000．GSM七號信令集中監測系統技術規范［S］．
［2］ 厄曼（美）．OracleqiPL／SQL程序設計［M］．陳維軍譯．北京：機械工業出版社，2002．
［3］ 鄧蘇．數據倉庫原理與應用［M］．北京：電子工業出版社，2002．
［4］ 廖朝暉，張鵬珊．并行數據庫系統目標、體系結構及研究方向［J］．計算機科學，1994，21（6）： 23－28．
［5］ HECTOR Garcia－Molina．Databse SystemImplementation［M］．U．S．A，Prentice HallPress，2000．
［6］ STEVE Bobrowski．Oracle8 Architecture［M］．U．S．A，Oracle Press，1998．
［7］ 席海峰，蹇潔．中國七號信令網及其集中監測系統［J］．重慶：重慶郵電學院學報（自然科學版），2000，12（2）：51－53．
［8］ 張治中，張云麟，程方．七號信令實測方法［J］．重慶郵電學院學報（自然科學版），2000，12（2）：38－40．
