2. 術語定義和縮略語
|
英文縮寫 |
英文全稱 |
中文全稱 |
|
OneCM |
One ChinaMobile |
“一箇中國移動” |
|
OneOSS |
Open Next_Generation oriented Evolutional Operational Support System |
開放下一代網絡運維支撐系統 |
|
BSS |
Business Support System |
業務支撐系統 |
|
OSS |
Operation Support System |
網絡運維支撐系統 |
|
OSI |
Open System Interconnection |
開放系統互聯（模型） |
|
eTOM |
enhanced Telecom Operation Map |
增強電信運營模型圖 |
|
TMF |
Telecom Management Forum |
電信管理論壇 |
|
NGOSS |
New Generation Operation Systems & Software |
新一代運營系統和軟件 |
|
BPM |
Business Process Management |
業務流程管理 |
3. 引言
中國移動在規範中按照“OneOSS”思路，引入TMF的相關概念，希望在3G網管建設中改變原來按專業進行建設爲跨專業綜合建設，面向全網進行集中監控、集中維護和集中管理，採用標準化技術體系和EAI技術提供綜合解決方案，以提高運營效率、提升整體效能、發揮最大效益，從而獲取競爭優勢、打造世界級運營服務能力。
4. CMCC-3G網管架構介紹
4.1.技術背景
4.1.1. 中國移動OSS運維背景
中國移動作爲世界上最多用戶的運營商，網絡結構非常複雜，涉及到設備廠商相當多，根據中國移動“OneCM”戰略，今後中國移動的網管建設方式，將由3級改爲2級，如下圖所示：
同時目前情況網管OSS大部分是按專業建設，存在多種OSS,每一種OSS都同網絡緊密相聯，並且相當程度上延遲於網絡發展，無法應對當前快速變化的網絡產品和服務。
4.1.2. NGOSS TNA技術介紹
4.2.OneOSS框架圖
中國移動提出的技術架構是以NGOSS TNA爲指導，基於總線和組件構建的技術中立架構，統稱爲OneOSS（Open Next_Generation oriented,Evolutional Operational Support System）架構，如下圖所示：
OneOSS技術架構具有如下特點：
Ø 基於已存在的系統
Ø 統一的流程調度、接口、數據模型、和訪問門戶
Ø 結構化、共享、層次化、合約、客戶化
Ø 由系統功能結構轉化系統技術結構
Ø 不直接面向被管網元
在每一個子系統中又定義如下三層技術架構：
4.3.技術選型
4.3.1. EAI總線
規範針對以前遺留下來的異構系統、應用、商務流程以及數據源構成，要求將這些應用軟件和硬件有機的整合在同一個平臺系統上實現信息的交互和共享，建議使用EAI技術在初級的單元式的企業應用系統建設的基礎上實現更高級的企業信息系統。
EAI進行應用集成分爲以下幾個集成類型：
|
集成名稱 |
集成說明 |
適用場合 |
|
數據集成（D2D） |
數據的規範化和標準化是數據集成的基礎，數據集成的目的是形成統一的數據視圖，也就是說數據模型在邏輯上必須是統一，物理上可以分佈存儲，即通過週期性的同步各數據庫的數據來實現統一。
|
對所有的應用而言，只需通過相同的數據模型訪問數據庫，而無需關心各個物理數據庫的模型和結構的不同，實現容易，擴展困難。 |
|
應用集成（A2A） |
以流程驅動技術爲核心，通過流程與服務的有機配合達到在不同系統直接的分工合作 |
有效的解決不同系統的數據模型的一致性、技術路線的不同、軟硬件平臺的異構，並使企業可以快速推出新業務，以客戶爲中心實現個性化定製服務。 |
|
商業邏輯層集成（B2B） |
基於A2A，直接面向分佈式商業對象等商業流程服務。 |
|
|
用戶接口層集成（I/I） |
使用一些遺留下來接口協議 |
老系統 |
EAI實施的通常的有四個技術方案：
1) 點到點消息技術
採用點到點的客戶化接口定義（API）或基於消息的中間件工具（MQ），系統間爲鬆耦合。
2) MessageBus 集成平臺技術
以交換中心或平臺（對各個專業子系統的應用間的請求消息進行路由等處理）和適配器（負責連接到各個專業子應用系統），用來解決企業內部應用系統間的信息共享，系統採用基於消息總線的框架結構，集成平臺完成數據轉換、規則處理及交易完整性控制功能。
3) Process Integration
將工作流管理器（或流程編排系統或服務編排系統）作爲業務支撐系統的核心，將業務系統構造於標準的工作流基礎上，實現業務邏輯和應用邏輯的剝離。
4) WWW Integration
一般不適合於網管架構。暫不說明
4.3.2. 系統平臺基礎架構
規範對這一塊未進行清晰定義，規範中要求整個平臺按NGOSS TNA（如下圖）提供基礎服務，但對每一個子系統，除了三層架構之個，還要求提供一些公用服務，如日誌管理、權限管理和自身管理，因此，未來在這兩塊之間是否需要進行互通，或者由什麼系統來提供系統平臺基礎架構支持，還未進行清楚定義。
4.3.3. 接口實現技術比較
|
技術名稱 |
技術說明 |
適用場合 |
|
WebService |
基於Http，數據以xml或Infoset方式以Soap協議進行傳遞，標準開放，安全性差，不保證可靠 |
非實時大數據量交換 |
|
Corba |
跨平臺、跨系統、跨語言、性能高，穩定，擴展性好，系統耦合度高 |
實時大數據量 |
|
MQ/JMS |
基於MOM，可靠，成熟商業，有事務支持， |
數據可靠性要求較高或實時大數據量 |
|
FTP |
文件傳輸協議 |
文件數據 |
|
Socket |
基於TCP/IP協議進行點對點傳輸 |
實時或者大數據量 |
|
中間表 |
同步到某一個數據庫 |
不同平臺的應用 |
4.3.4. 接口OSS/J可行性
OSS/J（OSS Through Java）是以JAVA技術爲動力的新一代的OSS/BSS解決方案。是由OSS Through Java Initiative的工作組提出，這個工作組由衆多的業界新技術的倡導者（例如Motorola，Nokia，Sun, BEA, IBM）派出的專家於2000年組成，工作組利用JAVA技術，爲OSS/BSS定義實現了一系列的開放的標準API，提供給OSS/BSS的開發者使用。同時，OSS/J並不是要定義另一個通用的OSS/BSS集成框架。OSS/J的API定義遵守了NGOSS eTOM （enhanced Telecom Operations Map）的規定，並以該框架爲基礎，提出了採用JAVA技術的實現方案，因此，對所有接口統一採用OSS/J規範中的接口保證相互調用。