顏蔚冬
【摘 要】中國電信在長期的OSS系統建設過程中,新舊系統數量眾多,存在系統架構不一、技術多樣、接口復雜等問題,無法適應靈活快速支撐業務的要求。由于系統間的接口服務相互調用過多、且缺乏一個統一的管理規范,導致目前接口協議種類過多。為了規范化管理各個系統的接口服務以及系統之間的服務調用,本文在分析OSS系統現狀的基礎上,分析了吉林聯通OSS應用集成平臺建設的需求,基于SOA架構完成了系統總體設計,并對其中的應用集成模塊、服務集成模塊、服務注冊模塊進行了詳細設計與實現。所實現平臺可以統一管理接口服務,屏蔽了系統間互聯的復雜性,達到了《中國電信集團.CTGMBOSS OSS 2.5集成及技術分冊》的要求,平臺上線后實現了吉林聯通OSS域系統間的橫向信息和數據交互,實現了吉林聯通OSS域系統同省OSS域系統間的縱向信息和數據的交互。
【關鍵詞】NGOSS;OSS;電信運營支撐系統;框架
文章編號:ISSN1006—656X(2013)09 -0105-02
一、背景
以移動互聯網、物聯網、云計算為代表的開放融合信息服務成為通信信息服務發展的趨勢,由它們帶來的新型業務模式與傳統電信業務不同,行業應用模式復雜,但業界并沒有進行統一的技術標準和統一平臺規劃,導致缺少統一的業務標準和技術標準,產品、受理和計費流程也不固定,缺乏標準產品和商業模式,在接入上存在很大難度。電信運營商需要投入專業團隊研究新業務形態和新商業模式,改變傳統BOSS支撐模式,進行新網絡、新業務平臺的建設,以滿足用戶對應用的可操作性、可視化等個性化需求的增強。同時,運營商迫切需要通過電信集約化的手段實現對業務和運營支撐的統一化,以降低業務部署和運營難度。
由于三大電信運營商此前運營的業務較為單一,因此三個運營商的支撐系統目前還普遍存在系統架構老化、系統基礎能力弱、標準化水平差、擴展能力不足等四大問題,無法更好地支撐市場發展,需通過推行一體化集約運營型OSS系統來徹底完成底層數據模型以及架構的調整。本文就是針對一體化集約運營型OSS系統的應用方案展開調查研究的。
從整體上看,我國的OSS建設仍處于初級階段,缺乏豐富的理論、技術以及實踐經驗,缺乏普遍認可并可以參照的建設標準和規范模型,運營商和服務商多數根據自己的理解去規劃和建設OSS。因此,對于我國OSS標準的發展,應在以跟蹤、消化為主的基礎上,逐步制定相應的國內規范,發展符合國際潮流和本國實情的OSS標準。
二、NGOSS理論基礎
NGOSS是下一代運營支持系統(Next Generation Operations Support Systems)的縮寫。NGOSS是電信管理論壇(TMF)提出的新一代OSS體系。NGOSS從系統(即插即用規則)、過程(企業事務過程模型)、信息(關聯處理公用數據)、產品四個方面保證OSS體系具備標準化、能夠逐步演化、保證互連互操作(開放)、實現端到端的管理和高度自動化的特點。NGOSS提出一系列的文檔、信息模型和代碼,分析研究企業核心業務流和信息技術,提出一套指導OSS建設的系統框架和設計即插即用的OSS組件方法,幫助開發商迅速開發支撐系統,滿足電信運營商對OSS系統建設的需要,從而使OSS系統設計、開發從滿足個別運營商的個體需求到分析電信運營商的整體需求的范圍上來,進一步使OSS系統的設計、開發進入到一個嶄新時代。貼近運營商需求,使系統開發變得更迅速、更靈活、成本更低是NGOSS的目標。
三、中國電信行業OSS系統現狀及問題分析
中國電信行業OSS系統應用現狀:從2003年起開始規劃自身的BSS/OSS系統,由于電信業務比較復雜,機構分支龐大,所以電信公司主要采取各本地網、各個子系統分別建立、逐步融合的方式,原有系統模塊的劃分有所變化,但各系統功能仍然保留。OSS系統建設目標為:逐漸由本地網集中向省集中過渡,功能模塊之間將共享核心數據模型。
中國電信業OSS系統建設與應用中存在的問題:OSS發展建設缺乏總體框架指導和具體實施規范;無法滿足業務變化的需求;管理流程有待進一步規范;客戶資料系統不完善。
基于以上問題吉林電信公司一體化OSS系統建設與應用應滿足以下幾點要求:集團、省兩級縱向信息/數據交互的需求;集團橫向信息和數據的需求;簡化系統之間網狀互聯接口的需求;統一規范接口標準的需求。
四、吉林電信公司一體化OSS系統方案設計
(一)系統方案設計目標與原則
為了支撐吉林電信OSS域系統間的橫向信息和數據交互需求,以及集團公司OSS系統與省級系統間的縱向信息和數據交互需求,達到市縣OSS系統接口的貫通,滿足吉林電信企業信息化架構的目標。系統建設應達到以下幾個業務目標:實現集團OSS域系統間的橫向信息和數據交互;實現集團OSS域系統同集團其他域系統間的橫向信息和數據交互;實現集團OSS域系統同省OSS域系統間的縱向信息和數據交互;企業外部系統對集團OSS域系統的信息和數據交互技術目標。通過建設總部OSS應用集成平臺,減少集團OSS域內系統間、市與縣級OSS域系統間網狀互連接口,達到接口的統一化和標準化。
系統建設應達到以下幾個技術目標:(1)統一接口服務管理(2)屏蔽系統間互聯的復雜性(3)建立系統之間高效、穩定的接口管理機制(4)接口服務動態發布和擴展能力運用SOA理念,通過組件式模塊化開發,達到系統組件的動態更新與發布,提局系統的穩定性,并提尚系統的橫向與縱向擴展能力。
系統方案設計原則有兩個分別為:面向服務構架和基于SOA設計原則
(二)系統總體技術架構
OSS應用集成平臺系統集成邏輯圖如圖4-1所示。OSS應用集成平臺基于spring的J2EE框架,采用的是infomix數據庫、業務邏輯層、展示層的三層架構。在展示層使用了ExtJs、Struts2,DWR、Flex等技術。在服務端使用了Drools Hibernate、H2等技術。
圖4-1 OSS應用集成平臺系統集成邏輯圖
(三)系統核心業務實體概念模型設計
NGOSS所強調是一個體系概念和結構。在體系概念和結構的指導下,規定和開發具體的標準和技術,在抽象模型和結構的基礎上,研究和選擇適用的分布、數據和信息共享等技術,以構造最有效的系統和應用。
NGOSS的核心框架不使用任何特殊技術,這樣即使使用新出現的技術構建新的織件時,也無需在不同技術間建立接口,只需通過構造適當的適配器就可以實現組件間的通信,從而保證了核別心框架的有效性和連續性。要保證技術獨立性,NGOSS核J自框架需要滿足大量的約束條件,如:不能指定任何特殊的通信協議;必須允許使用同步、異步、準同步的調用方式;不能描述任何業務過程數據;必須定義技術獨立的NGOSS組件如何實現過程中的織州一管理接口等。
雖然NGOSS核心框架不使用任何特殊技術,但是在框架的實現過程中不可能脫離技術。在NGOSS解決方案中,任何基手技術的框架必須聲明執行環境,從而保證織件開發者開發的組織,可以在這種框架實現中的正常工作。
(四)系統界面規劃設計
系統界面規劃如下圖4-2所示:
圖4-2 系統界面規劃
(五)各主要子系統功能描述與業務流程設計
1、子系統的數據(局部)私有化
子系統之間的數據嚴格封裝,一個子系統不允許直接修改另一個子系統的數據,被訪問子系統必須向訪問子系統提供相應的服務訪問接口。
2、子系統劃分
我們可以清晰定義系統的外部接口模塊和土要的系統模塊。接口模塊土要可以分為綜合采集模塊,綜合聯機指令模塊,統一繳費平臺,客服接口平臺,統一接入平臺等系統核心模塊可以分為對計費數據流的處理,綜合計費模塊,綜合帳務處理模塊,對費用管理為土的帳務管理模塊,對工單管理的綜合營業(客戶服務)模塊。
3、子系統分布
接口類:綜合采集,綜合聯機指令,統一接入平臺,統一繳費平臺,客服接口管理平臺。
技術平臺類:系統管理子系統(系統框架),內存數據庫系統
核心類(BSS核心模塊):綜合計費,綜合帳務處理,信用控制模塊,帳務管理模塊,綜合客戶服務
外部應用類:渠道管理支撐系統,客戶管理系統,運維管理子系統,綜合資源管理,經營報表平臺,產品管理系統等。
圖4-3 基于DGOSS的電信業務支撐系統架構
五、吉林電信公司一體化OSS系統方案實施的保障措施
保證OSS系統規劃的科學性、明確OSS系統評估體系的指導性、實施OSS系統技術標準的統一性、保障OSS系統人員培訓的規范性及提高OSS系統管理體制的完善性。
六、結論
在電信技術快速發展及中國電信的市場發展戰略逐步轉移為以客戶為中心的發展策略背景下,借鑒TMF提出的下一代運營支撐系統NGOSS理論體系,充分分析當前OSS系統存在的問題,結合電信運營商制定的企業目標和發展戰略,對所提出的OSS建設方案中的總體技術架構、核心實體模型、界面規劃及核心子系統的業務功能和業務流程進行重點分析設計。
參考文獻:
[1] 陳龍,張春紅,云亮.電信運營支撐系統[M].北京:人民郵電出版社,2005.
[2] 趙慧玲,葉華.以軟交換為核心的下一代網絡技術[M].北京:人民郵電出版社,2002.
[3] 電信管理論壇.運營支撐系統與軟件NGOSS數據模型、體系架構與測試[M].北京:人民郵電出版社,2005:15-20.
[4] 梅斌.電信業務運營支撐系統的發展與演進[M].郵電設計技術,2005-05.
[5] 王君坷,艾波.電信運營支撐系統:軟件體系結構模式系統[M].北京:人民郵電出版社,2006:44,50.
[6] 孔令萍.新一代運營支撐系統體系結構[J].中興通訊技術,2003,(3):60-6.
[7] 盧捍華,王亞石,閔麗娟等.基于NGOSS的OSS/BSS 框架[J].電信科學,2009,(10):57-62.
[8]謝青宇.新一代運營支撐系統與軟件NGOSS:數據模型、體系架構與測試[M].北京:人民郵電出版社,2003.
[9]Sun Microsystem,OSS through JavaTM Initiative Simpling Integration with CommonAPIs, Version.1 April 2001.
[10]TM-Forum TMF050A.NGOSS compliance testing information model and testing rules[S], May 2003.