本地網(wǎng)OSS演進策略

摘要　針對目前電信運營商對網(wǎng)絡(luò)OSS規(guī)劃建設(shè)的要求。提出可行的本地網(wǎng)OSS演進策略，并對該策略作了詳細(xì)介紹。

關(guān)鍵詞　OSS　EMS　網(wǎng)管

1、背景

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

　　建設(shè)本地網(wǎng)綜合化集中維護體系的一個關(guān)鍵環(huán)節(jié)是OSS(運維支撐系統(tǒng))的規(guī)劃建設(shè)，這是與業(yè)務(wù)和網(wǎng)絡(luò)都相關(guān)的一個全新的體系架構(gòu)，因此具有一定的難度和挑戰(zhàn)性。其難度不僅體現(xiàn)在單個系統(tǒng)的工程量上，更體現(xiàn)在如何融入綜合化集中維護體系中。

　　電信運營商對今后數(shù)年的OSS建設(shè)都有了明確的目標(biāo)和規(guī)劃。但是OSS的演進需要有一個科學(xué)、合理的發(fā)展策略。

2、需要注意的問題

　　本地網(wǎng)OSS的建設(shè)需要注意下列問題。

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

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

　　(3)注重接口標(biāo)準(zhǔn)化工作。OSS的接口包括EMS/網(wǎng)元網(wǎng)管接口、OSS系統(tǒng)之間的接口以及OSS與BSS/MSS接口3類。接口的標(biāo)準(zhǔn)化工作直接關(guān)系到OSS的功能和綜合應(yīng)用水平。

　　(4)注重數(shù)據(jù)維護。鑒于OSS與業(yè)務(wù)的聯(lián)系越來越緊密，網(wǎng)管數(shù)據(jù)的準(zhǔn)確性和完整性越來越重要，需要采取與業(yè)務(wù)系統(tǒng)類似的嚴(yán)格管理制度和流程保證。

3、演進策略

　　本地網(wǎng)的OSS總體演進策略如圖1所示。


圖1　本地網(wǎng)OSS演進策略

　　從圖1中可以看出，本地網(wǎng)OSS的演進是在兩個維度上進行的：一是傳統(tǒng)的網(wǎng)管分層模型，由底層網(wǎng)管一直到業(yè)務(wù)管理的發(fā)展過程；二是從孤立系統(tǒng)→數(shù)據(jù)集中→數(shù)據(jù)比對→數(shù)據(jù)交互→數(shù)據(jù)同步→系統(tǒng)整合的數(shù)據(jù)整合過程。通過對數(shù)據(jù)整合過程的細(xì)分，可以使得OSS的演進路線更加清晰。

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

　　3.1　EMS/網(wǎng)元的網(wǎng)管接口

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

　　3.2　專業(yè)集中網(wǎng)管

　　專業(yè)集中網(wǎng)管建設(shè)是本地網(wǎng)OSS體系的基礎(chǔ)和關(guān)鍵環(huán)節(jié)之一，特別是對于大型本地網(wǎng)來說，應(yīng)先按專業(yè)(包括交換、傳輸、數(shù)據(jù)、電源等)建設(shè)集中網(wǎng)管，然后再建設(shè)綜合網(wǎng)管。

　　專業(yè)網(wǎng)管應(yīng)充分注重端到端管理(包括接入端設(shè)備如PDH、協(xié)議轉(zhuǎn)換器等)功能，能提供面向客戶和業(yè)務(wù)的網(wǎng)絡(luò)視圖，以及相關(guān)的告警和性能數(shù)據(jù)分析。

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

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

　　3.3　資源管理系統(tǒng)

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

　　另一方面，網(wǎng)管的網(wǎng)絡(luò)配置和故障信息來自于實際設(shè)備，對資源管理系統(tǒng)的網(wǎng)絡(luò)資源校對和更新有重要意義。因此需要努力實現(xiàn)網(wǎng)管系統(tǒng)和資源管理系統(tǒng)之間的數(shù)據(jù)交互和共享。

　　在資源管理系統(tǒng)的完善過程中，要特別注意理順各專業(yè)網(wǎng)絡(luò)之間的關(guān)聯(lián)關(guān)系，這主要表現(xiàn)為傳輸網(wǎng)絡(luò)與交換中繼群、信令鏈路、數(shù)據(jù)中繼/電路的承載關(guān)系，以及各類數(shù)據(jù)網(wǎng)絡(luò)(IP、ATM/FR、DDN)之間的承載/對接關(guān)系。

　　作為前后臺信息共享的一個重要紐帶，資源管理系統(tǒng)的業(yè)務(wù)、產(chǎn)品、客戶標(biāo)識應(yīng)與前端保持一致。隨著CRM系統(tǒng)的建設(shè)，以及資源管理系統(tǒng)與“九七”系統(tǒng)的逐步融合，應(yīng)大力推進該項工作，逐步實現(xiàn)前后臺數(shù)據(jù)的暢通流轉(zhuǎn)。

　　3.4　OSS系統(tǒng)間的數(shù)據(jù)接口

　　OSS系統(tǒng)間的數(shù)據(jù)接口主要體現(xiàn)為網(wǎng)管系統(tǒng)、資源管理系統(tǒng)和工單系統(tǒng)之間的接口，其中網(wǎng)管系統(tǒng)和資源管理系統(tǒng)之間的接口是最重要的，在建設(shè)綜合告警系統(tǒng)時，需要重點考慮。在這個接口中，首先應(yīng)該重點突破傳輸專業(yè)，這是因為傳輸網(wǎng)絡(luò)是業(yè)務(wù)網(wǎng)絡(luò)的主要載體，并且傳輸資源管理工作開展最早、最完善。

　　網(wǎng)管和資源管理系統(tǒng)的數(shù)據(jù)交互需要建立在網(wǎng)絡(luò)資源標(biāo)識和信息模型統(tǒng)一的基礎(chǔ)上，例如，當(dāng)資源管理系統(tǒng)向網(wǎng)管系統(tǒng)提交電路資料時，網(wǎng)管系統(tǒng)應(yīng)能夠識別該電路兩端所在端口，這樣才能將電路資料與網(wǎng)管數(shù)據(jù)庫中的路徑對應(yīng)起來。由于歷史原因，兩個系統(tǒng)不能識別對方提供的資源標(biāo)識，因此在建立接口前，首先要做好模型匹配和數(shù)據(jù)比對工作。

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

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

　　通過數(shù)據(jù)比對，使得網(wǎng)管和資源管理系統(tǒng)的資源數(shù)據(jù)基本一致，在此基礎(chǔ)上，可建立數(shù)據(jù)交互接口。資源管理系統(tǒng)的客戶、業(yè)務(wù)、網(wǎng)絡(luò)承載關(guān)系信息和網(wǎng)管系統(tǒng)的配置、故障信息都可以通過定時或人工觸發(fā)的方式提交給對方。

　　通過數(shù)據(jù)交互，各系統(tǒng)之間的數(shù)據(jù)逐步趨于一致，在達到較高的水平后，可考慮實施數(shù)據(jù)同步，各系統(tǒng)之間可通過企業(yè)級的EAI數(shù)據(jù)總線，實現(xiàn)實時消息傳遞和數(shù)據(jù)更新。

　　3.5　綜合網(wǎng)管應(yīng)用

　　綜合網(wǎng)管應(yīng)用的第一步應(yīng)該是實現(xiàn)網(wǎng)管數(shù)據(jù)的集中分析。這是因為網(wǎng)管本身作為生產(chǎn)系統(tǒng)往往負(fù)荷較重，難以承擔(dān)長周期、復(fù)雜的分析運算，需要將告警和性能數(shù)據(jù)導(dǎo)入數(shù)據(jù)倉庫，進行集中分析。在數(shù)據(jù)交互階段，可在原有集中分析功能的基礎(chǔ)上，實現(xiàn)綜合分析。通過強大的數(shù)據(jù)倉庫平臺，采集所有專業(yè)網(wǎng)絡(luò)的資源、告警和性能數(shù)據(jù)，進行跨專業(yè)分析。

　　當(dāng)網(wǎng)管和資源管理系統(tǒng)進行了一定程度的數(shù)據(jù)比對并且資源管理系統(tǒng)中明確了跨專業(yè)承載關(guān)系后，可考慮建設(shè)綜合告警系統(tǒng)，即采集各專業(yè)網(wǎng)絡(luò)的告警信息，進行集中呈現(xiàn)和關(guān)聯(lián)性分析(包括跨專業(yè)關(guān)聯(lián)和客戶關(guān)聯(lián))。綜合告警系統(tǒng)有建設(shè)獨立的綜合告警系統(tǒng)或采用綜合告警視圖方式兩種建設(shè)思路。

　　建設(shè)獨立的綜合告警系統(tǒng)需要建立與資源管理系統(tǒng)、專業(yè)集中網(wǎng)管和網(wǎng)元/EMS的各種接口，交互大量數(shù)據(jù)，特別是與資源管理系統(tǒng)的動態(tài)接口比較復(fù)雜。因此建議系統(tǒng)建設(shè)分兩步走：第一步先建設(shè)一個面向大客戶的網(wǎng)管系統(tǒng)，人工整理與大客戶相關(guān)的資料，對大客戶相關(guān)的告警進行跨專業(yè)分析；第二步建立與資源管理系統(tǒng)的接口，并逐步將管理范圍擴大到全網(wǎng)。

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

　　采用視圖方式而不是新建獨立系統(tǒng)實現(xiàn)綜合告警處理的好處在于：不僅可以節(jié)省投資、避免數(shù)據(jù)的冗余，而且能夠降低接口開放難度，各專業(yè)網(wǎng)管和資源管理系統(tǒng)只需提供可參數(shù)化調(diào)用的Web接口即可。缺點是告警關(guān)聯(lián)性的自動分析功能較弱。

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

　　3.6　電子工單系統(tǒng)

　　運維工單系統(tǒng)主要包括故障單處理、電子運維管理和業(yè)務(wù)開通3個方面。現(xiàn)階段，各地一般都建有故障單處理系統(tǒng)，業(yè)務(wù)開通系統(tǒng)則往往依附于資源管理系統(tǒng)。相當(dāng)一部分地區(qū)的工單系統(tǒng)存在著分散建設(shè)、功能不完善的問題。

　　從綜合化集中維護管理的角度出發(fā)，可以適當(dāng)超前建設(shè)統(tǒng)一的電子工單平臺，實現(xiàn)業(yè)務(wù)開通、局?jǐn)?shù)據(jù)制做、故障處理、應(yīng)急調(diào)度、網(wǎng)絡(luò)割接、作業(yè)維護、機房值班等統(tǒng)一閉環(huán)管理，以及統(tǒng)一的工作考核、流程優(yōu)化、人員優(yōu)化和成本控制評估。另外，需要重視統(tǒng)一認(rèn)證平臺的建設(shè)，以實現(xiàn)一次登錄即能訪問所有OSS系統(tǒng)的功能。

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

　　在數(shù)據(jù)交換階段，電子工單平臺應(yīng)重點建立與網(wǎng)管系統(tǒng)和資源管理系統(tǒng)的接口，實現(xiàn)重要故障自動派發(fā)工單、網(wǎng)絡(luò)資源數(shù)據(jù)交互等功能。在數(shù)據(jù)同步階段，電子工單平臺可通過EAI數(shù)據(jù)總線，與OSS、BSS和MSS各系統(tǒng)交互消息，實現(xiàn)流程與數(shù)據(jù)的同步。在系統(tǒng)整合階段，通過與綜合網(wǎng)管功能的配合，最終實現(xiàn)流程的過程控制。

4、結(jié)束語

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