作者：嚴昌權  潘鴻雷  張穎峰

    摘要：針對目前電信運營商對網絡OSS規劃建設的要求。

    提出可行的本地網OSS演進策略，并對該策略作了具體介紹。

    要害詞：OSSEMS  網管

    1、背景

    為了在網絡服務質量、維護成本方面與國際先進水平接軌，國內各大運營商正在逐步建立綜合化集中維護體系。本地網的網絡運維工作逐步走向集中化、綜合化、流程化和客戶化。

    建設本地網綜合化集中維護體系的一個要害環節是OSS(運維支撐系統)的規劃建設，這是與業務和網絡都相關的一個全新的體系架構，因此具有一定的難度和挑戰性。其難度不僅體現在單個系統的工程量上，更體現在如何融入綜合化集中維護體系中。

    電信運營商對今后數年的OSS建設都有了明確的目標和規劃。但是OSS的演進需要有一個科學、合理的發展策略。

    2、需要注重的問題

    本地網OSS的建設需要注重下列問題。

    (1)注重治理和規劃，不要片面追求新技術。實際上，OSS的水平主要取決于規劃和治理水平，而不是技術水平。對OSS來說，治理的重要性體現在兩個方面：一是OSS建設必須適應運維治理的需要；二是OSS建設維護本身也需要嚴格的治理手段。

    (2)循序漸進，量力而行。一味地貪大求全，不僅會造成投資的浪費，而且大量堆積的工程量也是無法承擔的。

    (3)注重接口標準化工作。OSS的接口包括EMS/網元網管接口、OSS系統之間的接口以及OSS與BSS/MSS接口3類。接口的標準化工作直接關系到OSS的功能和綜合應用水平。

    (4)注重數據維護。鑒于OSS與業務的聯系越來越緊密，網管數據的準確性和完整性越來越重要，需要采取與業務系統類似的嚴格治理制度和流程保證。

    3、演進策略

    本地網的OSS總體演進策略如圖1所示。

    圖1  本地網OSS演進策略

    從圖1中可以看出，本地網OSS的演進是在兩個維度上進行的：一是傳統的網管分層模型，由底層網管一直到業務治理的發展過程；二是從孤立系統→數據集中→數據比對→數據交互→數據同步→系統整合的數據整合過程。通過對數據整合過程的細分，可以使得OSS的演進路線更加清楚。

    OSS的數據比對工作主要體現在網管系統和資源治理系統之間，由于兩者的信息模型、命名規則不盡相同，因此需要花費大量的時間和人力來實施比對和修正工作，假如這一步工作做不好，整個數據整合工作都將難以繼續。在此基礎上，可以初步建設資源治理系統和網管系統之間的接口，實現定時的、人工校對的數據交互。數據交互階段是OSS體系建設的第一個里程碑，在這一階段，實際上需要的大部分功能都可以實現了。根據目前的實際情況估計，到達數據交互階段大概需要1～2年的時間。后面的數據同步和系統整合工作，難度都比較大，其實施情況會受到技術水平、治理水平和運營商的戰略規劃等因素的影響。

    3.1EMS/網元的網管接口

    有些類型的網元本身具有網管接口，有些則需要通過EMS(子網治理系統)提供網管接口。EMS/網元的網管接口功能直接決定了網管的操作功能。由于歷史原因，目前某些種類EMS/網元的接口功能尚不完善，例如，傳輸EMS北向接口的向下配置功能普遍不成熟，部分廠商的傳輸網元甚至不能上報較完整的配置信息。這需要運營商和廠商共同努力解決，制定網管接口功能需求和技術規范，并從計劃建設開始就嚴格把關，逐步形成網管接口技術與網絡設備同步發展的良性循環。

    3.2專業集中網管

    專業集中網管建設是本地網OSS體系的基礎和要害環節之一，非凡是對于大型本地網來說，應先按專業(包括交換、傳輸、數據、電源等)建設集中網管，然后再建設綜合網管。

    專業網管應充分注重端到端治理(包括接入端設備如PDH、協議轉換器等)功能，能提供面向客戶和業務的網絡視圖，以及相關的告警和性能數據分析。

    可以預計，近期國內電信網的結構將會發生很大變化，包括NGN、固網智能化、3G網絡等新技術將會廣泛應用。一方面，專業集中網管要能適應網絡的發展變化，例如，本地交換網向NGN、固網智能化轉變后，本地交換網管應進行相應的升級改造，以具備對新增和改造設備的治理能力；另一方面，這些新型網絡大部分是承載在現有網絡之上，這就要求各專業網管能夠靈活地定制新業務的治理功能，例如，提供3G網的傳輸、數據電路視圖和相關的告警、性能分析。

    在專業網管發展初期，另一個需要重視的問題是網管與網元/EMS配置信息的同步。這是因為在初期網元配置操作仍然是在EMS或直接在網元上進行，大量的配置變動需要及時反映到網管系統中。配置信息的同步在初期可采用定時或人工觸發的方式，并逐步過渡到實時同步。

    3.3資源治理系統

    資源治理系統保存了業務、客戶以及網絡承載關系信息，這些都是綜合網管系統進行面向客戶/業務和跨專業分析需要的重要數據。因此，資源治理系統的完善程度直接關系到OSS體系演進的成敗，在系統未完善之前，不應急于建設綜合網管應用(如綜合告警系統)。

    另一方面，網管的網絡配置和故障信息來自于實際設備，對資源治理系統的網絡資源校對和更新有重要意義。因此需要努力實現網管系統和資源治理系統之間的數據交互和共享。

    在資源治理系統的完善過程中，要非凡注重理順各專業網絡之間的關聯關系，這主要表現為傳輸網絡與交換中繼群、信令鏈路、數據中繼/電路的承載關系，以及各類數據網絡(ip、ATM/FR、DDN)之間的承載/對接關系。

    作為前后臺信息共享的一個重要紐帶，資源治理系統的業務、產品、客戶標識應與前端保持一致。隨著CRM系統的建設，以及資源治理系統與“九七”系統的逐步融合，應大力推進該項工作，逐步實現前后臺數據的暢通流轉。

    3.4OSS系統間的數據接口

    OSS系統間的數據接口主要體現為網管系統、資源治理系統和工單系統之間的接口，其中網管系統和資源治理系統之間的接口是最重要的，在建設綜合告警系統時，需要重點考慮。在這個接口中，首先應該重點突破傳輸專業，這是因為傳輸網絡是業務網絡的主要載體，并且傳輸資源治理工作開展最早、最完善。

    網管和資源治理系統的數據交互需要建立在網絡資源標識和信息模型統一的基礎上，例如，當資源治理系統向網管系統提交電路資料時，網管系統應能夠識別該電路兩端所在端口，這樣才能將電路資料與網管數據庫中的路徑對應起來。由于歷史原因，兩個系統不能識別對方提供的資源標識，因此在建立接口前，首先要做好模型匹配和數據比對工作。

    模型匹配實際上就是網管系統和資源治理系統之間信息模型的映射或調整，包括物理資源(如板卡、端口)和邏輯資源(如時隙、槽路)。當前兩個系統之間的信息模型差異一般是設備槽位、板卡、端口、時隙等命名和編號的不一致，以及系統本身無需關注的對象造成的差異，因此匹配起來是比較輕易的。

    網管中的網元命名與資源治理系統往往不一致，因此數據比對的第一步工作是建立兩個系統網元命名的一一映射關系，然后再利用比對工具，通過模型對照，對網元的物理資源和邏輯資源進行自動比對和人工修正完善。網元名稱的比對應盡早進行，不必等到綜合告警系統建設時才開始。

    通過數據比對，使得網管和資源治理系統的資源數據基本一致，在此基礎上，可建立數據交互接口。資源治理系統的客戶、業務、網絡承載關系信息和網管系統的配置、故障信息都可以通過定時或人工觸發的方式提交給對方。

    通過數據交互，各系統之間的數據逐步趨于一致，在達到較高的水平后，可考慮實施數據同步，各系統之間可通過企業級的EAI數據總線，實現實時消息傳遞和數據更新。

    3.5綜合網管應用

    綜合網管應用的第一步應該是實現網管數據的集中分析。這是因為網管本身作為生產系統往往負荷較重，難以承擔長周期、復雜的分析運算，需要將告警和性能數據導入數據倉庫，進行集中分析。在數據交互階段，可在原有集中分析功能的基礎上，實現綜合分析。通過強大的數據倉庫平臺，采集所有專業網絡的資源、告警和性能數據，進行跨專業分析。

    當網管和資源治理系統進行了一定程度的數據比對并且資源治理系統中明確了跨專業承載關系后，可考慮建設綜合告警系統，即采集各專業網絡的告警信息，進行集中呈現和關聯性分析(包括跨專業關聯和客戶關聯)。綜合告警系統有建設獨立的綜合告警系統或采用綜合告警視圖方式兩種建設思路。

    建設獨立的綜合告警系統需要建立與資源治理系統、專業集中網管和網元/EMS的各種接口，交互大量數據，非凡是與資源治理系統的動態接口比較復雜。因此建議系統建設分兩步走：第一步先建設一個面向大客戶的網管系統，人工整理與大客戶相關的資料，對大客戶相關的告警進行跨專業分析；第二步建立與資源治理系統的接口，并逐步將治理范圍擴大到全網。

    綜合告警視圖不會保存告警和網絡資源數據，而是通過Web技術，從各專業網管和資源治理系統提取關聯的告警和資源數據進行集中呈現。例如，對于某交換中繼電路全阻的故障，網管人員可以在Web界面上點擊該中繼，然后通過Web頁面到資源治理系統中查找相關的傳輸2Mit/s電路，然后再到傳輸網管中去尋找該電路相關的告警并顯示在網頁上，從而使網管人員能夠進行跨專業的故障定位。

    采用視圖方式而不是新建獨立系統實現綜合告警處理的好處在于：不僅可以節省投資、避免數據的冗余，而且能夠降低接口開放難度，各專業網管和資源治理系統只需提供可參數化調用的Web接口即可。缺點是告警關聯性的自動分析功能較弱。

    建設功能齊全的綜合網管系統將是一個長期努力的過程，只有在OSS各種接口功能都比較完善、數據基本統一了以后，才可以考慮建設綜合網管平臺，替代原有各專業網管，實現所有網管功能。

    3.6電子工單系統

    運維工單系統主要包括故障單處理、電子運維治理和業務開通3個方面。現階段，各地一般都建有故障單處理系統，業務開通系統則往往依附于資源治理系統。相當一部分地區的工單系統存在著分散建設、功能不完善的問題。

    從綜合化集中維護治理的角度出發，可以適當超前建設統一的電子工單平臺，實現業務開通、局數據制做、故障處理、應急調度、網絡割接、作業維護、機房值班等統一閉環治理，以及統一的工作考核、流程優化、人員優化和成本控制評估。另外，需要重視統一認證平臺的建設，以實現一次登錄即能訪問所有OSS系統的功能。

    隨著NGN、固網智能化、3G等技術的不斷應用，原有維護體制和流程必將發生重大變化，這就要求電子工單平臺在維護組織和維護流程這兩個方面有靈活的定制能力，以適應不斷變化的需求。

    在數據交換階段，電子工單平臺應重點建立與網管系統和資源治理系統的接口，實現重要故障自動派發工單、網絡資源數據交互等功能。在數據同步階段，電子工單平臺可通過EAI數據總線，與OSS、BSS和MSS各系統交互消息，實現流程與數據的同步。在系統整合階段，通過與綜合網管功能的配合，最終實現流程的過程控制。

    4、結束語

    本地網的OSS體系建設是一項復雜而艱巨的任務，不僅需要制定合理的演進策略，而且要在治理手段、組織實施等方面給予充分保障。本文討論的演進策略不僅適用于較大規模的本地網，對于中小省份的全省集中OSS建設也有一定的參考價值。