1、電信綜合網管系統中的數據管理摘要 從綜合網管的定義和地位出發，討論了電信綜合網管系統中數據管理的重要性及其數據的特點，并介紹了一種應用在電信綜合網管系統中的數據管理 方案，說明了該模型的優點。1、電信綜合網管系統定義及其在OSS中的地位如圖1所示，OSS系統由資源管理系統、網管系統（包括綜合網管系統和專業網管系統EMS/NMS）和運維管理系統三部分構成，是一個統一的業務支 撐和業務保障系統。它的主要任務是管理全專業的通信資源和業務資源，對業務提供與保障提供監控和管理的手段，并界、財務、建設、采購等部門有著 明確的界面與分工。在OSS系統中，資源管理系統負責實現自動半自動化的資源調配；綜合專業網

2、管系統完成對故障和服務質量的管理;運維管理系統完成 單據流轉、專家庫等其它運維功能。綜合網管系統是OSS系統中的一個重要組成部分，它集成了多專業、多廠家的網元設備進行綜合管理，在實現故障管理能管理的基礎上，結合資源信 息和客戶信息，向電信運營商提供以大客戶為中心的，面向客戶的服務支持，實現電信運營商積極倡導的服務質量保證。宙分帽我基配置MiH弟喉it宙分帽我基配置MiH弟喉it做定密客r中眸2冬也 /月畢配襯、將孔他壞圖1 OSS系統的定位與邊界綜合網管系統與多個外部系統存在著數據交換：（1）專業網管系統但MS/NMS）:綜合網管系統從中采集得到網絡配置、告警與性能等數據；（2）資源管理系統：

3、資源管理系統從綜合網管系統中得到網絡上采集得到的設備配置數據，而綜合網管系統則從資源管理系統中獲取客戶、電路等業務 共享數據；（3）運維管理系統：綜合網管系統根據告警信息，產生出各種工單發送給運維管理系統；2、電信綜合網管中數據管理的重要性及其特點對于綜合網管系統，其核心價值在于對電信網絡的綜合管理和大客戶服務質量的重點保障而要實現這種價值，綜合的數據管理就是必不可少的。不管是 網絡告警的準確定位、專業內/跨專業的根告警關聯性分析，還是針對告警的業務、客戶影響分析，都必須要有全面而準確的網絡配置數據和關聯業務數據作 為分析的基礎。綜合系統的意義就在于將各方面的數據在自身的平臺中進行整合后，加工

4、成有用的信息，并體現在上層的綜合應用中。資源管理系統的數據管理目標在于面向業務調度、核查網絡資源而對于綜合管理系統來說，這個目標則是面向業務保障、支撐網絡運營，因此綜合網管 系統的數據管理側重點與資源管理系統也存在不同，必須針對綜合網管系統的管理需求來進行數據模型管理。在大部分情況下，綜合網管系統只關心數據對象本身，其屬性更多的是作為對象的附加描述而存在針對屬性的操作也很少；因此在數據建模的時候我 們就可以忽略對象的細節內容，而將對象本身作為建模的重點。在綜合網管系統中，不管是告警關聯性分析，還是業務影響性分析，其分析的數據重點都在于網絡數據與網絡數據之間的關系者網絡數據與業務數據 之間的關系

5、，這就決定了數據建模的另一個關鍵點是對象間關系的管理。對于綜合網管系統，其數據主要來源有兩種從資源管理系統中獲取業務數據、從專業網管系統中獲取網絡數據。由于接入設備多種多樣，涉及了各種專 業和各種廠商，導致了綜合網管系統內的配置數據呈現出數據量大、種類多、信息模型差異大的特點；而在綜合網管系統和資源管理系統之間存在的大批量的 實時/準實時數據交互，也同時要求數據建模能適應這種頻繁的數據交換活動。3、數據管理方案介紹根據以上說明，我們對電信綜合網管系統中的數據管理有了一個初步的認識。下面，就從對象建模和關系建模兩個方面簡述一種數據管理方案。3.1對象建模過程網絡環境下資源的表示是網絡管理的一個關

6、鍵問題，目前一般采用所謂“被管對象” MOnagedObject，可縮寫為MO）來表示網絡中的資源ISO認為， 被管對象是從OSI角度所看的OSI環境下的資源，這些資源可以通過使用）SI管理協議而被管理。另一個關鍵概念是所謂的“管理信息庫 Management Information Base，可縮寫為MIB），MIB是被管對象的一個概念上的集合，所有相關的網絡管理客體信息都放在此信息庫中。在專業網管系統中，其北向接口的網絡協議一般為:SNMP （簡單網絡管理協議）、CORBA （公共對象請求代理架構）、CMIP （公共管理信息協議）或者廠 家私有協議；其中，SNMP和CMIP均是基于MO和M

7、IB概念對網絡進行管理。對于綜合網管系統，由于大量數據均是從專業網管中采集得到的，使MO和MIB 的概念進行數據管理也是順理成章的事情。根據抽象層次不同，我們可以將MO分為被管對象類（ManagedObjectClass，可縮寫為MOC）和被管對象實例（Managed ObjectInstance，可縮寫為MOI）， 分別描述數據類和數據實例。3.1.1被管對象類（MOC）被管對象類（MOC）用來描述資源對象的類別，比如：機框、插盤、端口、交換機、傳輸網元、阿爾卡特傳輸網tEWSD交換機，每個被管對象類MOC） 都用唯一標識（OID）來確定。被管對象類（MOC）之間存在著繼承關系，所有的dOC

8、會組織成一個具有繼承關系的層次結構。例如：對于“華為傳輸網元”和“阿爾卡特傳輸網元”， 我們可以將其抽象為“傳輸網元”，繼而將其抽象為“網元”，如圖所示。圖2管理對象類（MOC）之間的繼承關系一組存在包含關系的被管對象類MOC）組合在一起，就可以形成一棵管理信息樹MIB樹）。在綜合網管系統中，管理信息樹MIB樹）的構成并不是任 意的，而是與特定廠商、特定設備相關的，由特定設備本身決定。當綜合網管接入設備時，可以根據設備的具體情況構造出一棵特定的管理信息樹樹）。 如：對于華為傳輸網元，其管理信息樹（MIB樹）結構形式可能為“系統一網元一機架一機框一插板一端口一時隙”如圖3所示；但對于阿爾卡特傳輸

9、網元， 其管理信息樹（MIB樹）結構形式則可能與之不同，表現為“系統一網元一機框一插板一端口一時隙”。系統提供被管對象類模板對被管對象類MOC）進行定義，描述類的繼承關系以及屬性定義，對于行為、動作和通知則不做約定。3.1.2被管對象實例（MOI）被管對象實例MOI）表示在所要管理的網絡中，需要網管系統管理的各種實際存在的資源對象在網管系統中的“映像”，代表一個實際存在的資源對象， 是MOC的實例化。圖3華為傳輸設備的管理信息樹MIB樹）按照管理對象類（MOC）的管理信息樹（MIB樹）定義，相應的被管對象實例（MOI）對象之間也會存在包含關系，并組合形成一棵更大的被管對象實例MOI） 包含樹。

10、被管對象實例（MOI）的名稱即是按照該包含樹的結構描述的，這種描述與它在實際設備中的所表現出來的層次相一致。例如：/System=sampleSystem1/Subnetwork=sampleSubnetwork3/NE=sampleNE3即表示一個網元，它是屬于系統（System）為 “sampleSystem1”，位于子網（Subnetwork）“sampleSubnetwork3”中，網元（NE）標識為 “SampleNE3”。雖然本數據管理方案借鑒了SNMP和CMIP的建模思想，卻根據綜合網管系統的實際情況，并結合SNMP和CMIP在使用中遇到的問題，對其信息模型增加或 者簡化了部分內

11、容，形成了一個特有的解決方案。該解決方案與NMP、CMIP信息模型的比較如表1所示。表1信息模型比較如表1所示，本數據管理方案結合了SNMP和CMIP模型的優點，采用了相對簡單的面向對象建模方式，避免了:NMP數據抽象度不夠導IB混亂無法實 現通用管理、而CMIP又過于復雜難于實現的缺點，比較適合綜合網管系統的使用。3.2關系建模過程對于綜合網管系統，對象間的關系管理則是更重要的內容。在綜合網管系統中，存在“承載關系”、“拓撲關系”、“包含關系”等多種數據關系，對這 些關系如何定義、抽象和管理，一直是網絡管理信息模型沒有涉及的部分。在本數據管理方案叫們將這些“善變的關系”也進行了對象建模，并作

12、為管理 的重點內容。被管對象間的復雜關系，我們通過定義各種“關系類”來抽象用具體的關系實例”來確定；某種被管對象（實例）與其他被管對象（實例）具有哪種 關系，可以通過設置這種被管對象（實例）進入和退出某種關系類，來實現關系的管理。用戶可通過設置這些關系，實現從不同的視角來觀察對象。資源對象間的關系，可以通過類和實例兩個層面來定義：第一層面，關系類（Relationshipclass，可縮寫為RC），用于描述具體被管對象類MOC）間的關系。例如描述“交換網元”類與“中繼”類之間存在 “交換網元-中繼的拓撲關系”，還可以描述“傳輸網元”與“段”之間存在“傳輸網-段的拓撲關系”。關系類之間也會存在繼

13、承關系，如交換網元-中繼的拓撲關系”和傳輸網元段的拓撲關系”，我們可以將其進一步抽象成為“拓撲關系”對拓撲 關系”，我們可以描述為：三元關系、參與對象為一個線對象和兩個端點對象、線對象的兩端為兩個端點對象；對于“交換網元繼的拓撲關系”，則除了 以上定義之外，還需增加描述：線對象為中繼（實例）、點對象為交換網元（實例）。通過關系類（RC）之間的繼承，使對象間關系在不同層次上都有相應的類對其進行描述，滿足了系統在不同場合對關系進行分析的需要。例如：“拓撲關 系”類，就可以在繪制全網拓撲圖時使用；而在繪制交換網絡拓撲圖時，則會使用到“交換網-中繼的拓撲關系”類。第二層面，關系實例Relationsh

14、ip Instance可縮寫為RI），用于確定具體被管對象實例MOI）之間的關系，是關系類RC）的實例化。例如沈陽 市名為NE666交換網元與NE888交換網元之間存在直達中繼I666-888，則這3個實體之間構成一個“交換網元中繼的拓撲關系”，是一條拓撲關系的實例。通過類與實例兩個層面的描述，從抽象到具體逐步將對象間關系描述清楚，這就是我們所建立的關系模型；該模型實現了資源對象與對象間關系的分離 管理，將對象間的耦合度降到了最低，也有利于關系的維護和管理。在具體系統實現時，我們可以將成與RO分別建表存儲，從物理上實現對象與關系的分離管理，僅依靠表之間的外鍵實現關聯。下面，我們以一種狀態計算引

15、擎為例，說明這種方案在業務影響分析中的應用。該狀態計算引擎描述如下：（1）對每一個需要監控的被管對象實例MOI）建立一個狀態對象（State Element，可縮寫為SE），用來記錄當前被管對象實例MOI）的狀態。（2）狀態對象（SE）之間存在一種特殊的關系：源目的（source-target）關系，這種關系被用來進行狀態傳播。一旦源source）對象的狀態取值發 生變化時，目的（target）對象的狀態就會被重新計算。如果該目的target）對象是另一個狀態對象SE）的源（Source），那么這種傳播過程將會繼續下 去，直至不存在源目的（Source-target）關系。（3）狀態的計算是通

16、過狀態對象SE）內部一個特定的狀態計算公式進行的，該公式可與被管對象實例MOI）所屬的被管對象類（MOC）相關。當狀態 對象（SE）接收到一個告警事件或者與其相關的源source）對象狀態發生變化時，該公式才會被觸發。此時狀態對象（SE）的狀態取值會根據計算出的結 果進行修改，并有可能觸發上送一個新的告警事件。（4）告警上送和狀態傳播的具體過程如圖I所示。Alam ,II,Alam ,II,Action, for xampis 051- event圖4告警上送和狀態傳播根據我們對于被管對象類（MOC）與被管對象實例（MOI ）的定義，我們可以抽象出以下幾類狀態對象（SE）:客戶（custome

17、r）、業務（servicePackage）、 通路（trail）、通道終結點（snc endpoint）、永久虛電路（pvc），并在他們之間建立源目的（source-target）關系。如圖5所示，當通道終結點snc endpoint）實體有告警產生時，狀態就會按照箭頭所示進行傳播，最后影響到特定的業務、特定的客戶。根據這種原則， 我們可以建立更加復雜的傳播關系，處理更加復雜的業務分析問題。圖5狀態傳播示例4、該方案的優點從系統建設來說，使用該數據管理方案恰好滿足了綜合網管系統中數據量為、類多、信息模型差異大的特點，大大增強了系統的擴展性和對不同設備接 入的包容性，同時也有利于與資源系統的數據

18、交換。（1）以新設備接入為例，無論該設備網管采用何種網絡協議進行管理，我們均可將其納入本數據模型中，而不僅限于支持P的設備。當系統需要接入 一種新設備時，用戶只需重新定義一套被管對象類MOC）、一棵該設備相關的MIB樹和若干關系類，即可以在不影響系統框架，不影響原有功能，且不修改 系統代碼的情況下，接入該新設備；系統需要新開發的內容只僅僅限定在接入模塊部分，即插即用成為可能。（2）在現階段，資源管理系統一般是個靜態的系統，數據來源主要靠人工錄入和核對，很容易造成數據缺失和錯誤；資源管理系統如果想要得到真實的 網絡信息，從綜合網管系統中獲取是一個比較好的方案。而開放這個數據接口，需要對綜合網管系統和資源管理系統的數據模型進行轉換。資源管理系統是 一個面向業務的系統，其網絡數據也是按照面向業務的原則進行建模，挨棄了與設備有關的物理細節，只關心設備的共有特性；而這就要求綜合網管系統中的 數據模型也能滿足設備無關的條件。在本數據方案中，通過具有繼承關系的被管對象類MOC）、關系類（RC）的定義，抽取了數據的共性，使得綜合網管系 統的模型與資源管理系統的模型之間的轉換相對容易，模型映