原文：http://blog.chinaunix.net/u/12631/showart_235839.html
/*這是一篇翻譯的文章，原文請看? http://www.iec.org/online/tutorials/ems/index.html
Element Management Systems
網元管理系統（
EMS
）
定義
網元管理系統
(EMS)
是
管理特定類型的一個或多個電信網絡單元（
NE
）的系統。一般來說，
EMS
管理著每個
NE
的功
能和容量，但并不理會網絡中不同
NE
之間的交流。為了支持
NE
間的
交流，
EMS
需要與更高一級的網絡管理系統（
NMS
）
進行通信，
NMS
也是電信管理網絡（
TMN
）
層次模型中的一元。
EMS
是基于
TMN
層次模型的運作支持系統（
OSS
）構架的基礎，這個構架使得服務提供商
(SP)
能
夠滿足客戶對高速發展著的服務的需求，同時也能滿足嚴厲的服務質量（
QOS
）
要求。電信管理論壇
(TelManangement
Forum)
公共對象請求代理結構（
CORBA
）
EMS
到
NMS
接口的出現宣告以
TNM
為
構架的具有協同工作能力的
OSS
進入了實用時代。
總覽
這個教程提供了一個
EMS
在
電信網絡中所扮演角色的全面闡述；
EMS
領域的功能、職責；不同的單元管理方法之間的區別。希望這些能增進讀者對這些不斷擴展中的多接口組
件的理解。
主題
1
、
EMS
在電信網絡構架中的位置
2
、
EMS
在五層
TMN
中的作用
3
、
OSS
的
TMN FCAPS
模型
4
、四功能
EMS
模型
5
、服務提供
6
、服務保障
7
、
EMS
和
NE
的運營支持
8
、自動配置
9
、
EMS
軟件的構架
?
1
、
EMS
在電信網絡構架中的位置
在過去的十年中，電信網絡一直處在變遷之中。那些語音傳輸老網絡相當簡單，它們主要是基于銅環的客戶
電話交換網絡。這些網絡正在向集成有訪問、傳輸、語音交換、高速數據和視頻等設計的方向發展。這將需要采用眾多復雜的技術，因此每一個有著不同復雜技術的
網絡單元都有相應的
EMS
來管理，從而使技術的能力得以利用，技術的復雜性被屏蔽了。
?
圖
1
是一個
EMS
在網絡中所處位置的概念性視圖。今天的網絡是由眾多供應商的
NE
組成的。不同于
NE
與
NE
，
NE
與
EMS
之間的通信協議由供應商提供，比如
TL1,PDS Snyder,
信號網絡管理協議
SNMP,
通
用管理信息服務單元
CMISE
。如圖
1
所示，
NE
與相對應的
EMS
通
信，
EMS
通過私有的或可能是公共的規范化的北行接口與更高的
NMS
通信，
NMS
負責集成不同供應商的網絡管
理。
圖
1. EMS
在電信網絡中所處的位置
500)this.width=500;" border="0">
一個
EMS
通常是用來配置一組相同類型
或系統的
NE
，比如數字交叉連接系統（
DCS
），
通過光網絡環
(SONET)
添加丟棄多元編碼器
(ADMs)
，或者一個混合光纖
/
電纜（
HFC
）有線電話系統。
EMS
的扮演的角色是控制管理范圍內所有方面和確保資源的充分利用。
EMS
抽象出相關
NE
技術
細節的外貌，并把這些信息通過北行接口傳送到更高一級的管理系統中。
?
EMS
是電信管理解決總體方案中的關鍵部分。只有
EMS
是
需要對其所屬范圍內所有
NE
的管理內容負責。
EMS
是
NE
與
NMS
層交換控制和數據信息的唯一
媒介。因此，
EMS
與特定網絡單元的類型密切相關，必須與這些
NE
一
起部署從而能夠激活和管理這些
NE
的功能。
?
2
、
EMS
在五層
TMN
中的作用
TMN
構架是一個電信管理辦法的參考模型。它的目的是把各種的功能分配到不同的層次之中。國際電信聯盟－電
信標準部
(ITU-T)
在
1988
年定義了
TMN
構架，詳細說明在
M.3010
和其他文檔之中。
?
這個構架最大的作用是確定了電信管理中的五個功能水準：商務管理層（
BMS
），服務管理層（
SML
），
網絡管理層（
NML
），網元管理層（
EMS
）
和由日益職能化的網元組成的網元層（
NEL
）。
TMN
根據這些層次分離了管理職
責。這使得在不同的
SP
、
OS
、數據庫和編程語言中分派功能
進而協同工作成為了可能。
?
TMN
要求每一層都要提供與相鄰層交互的接口，這個接口支持在應用程序之間通信，接口可以采用標準的計算機
技術。
TMN M.3010
文件允許使用多種協議。這意味著
SNMP
和
CORBA
之類開放的協議也可以包含在
TMN
框
架之中。
圖
2.
五層
TMN
構架模型
500)this.width=500;" border="0">
如圖
2
所示，
TMN
模型簡單而明了，它可以很有效的表示網絡管理構架中的那些復雜的關系。相對于起初的通用管理信息服務
單元（
CMISE
），面向對象技術在
1988
年
獲得認可，在
CORBA
等采用它的技術中，面向對象技術顯示出了很強的適應性。
CORBA
的進步與
SNMP
在協議方面的進步很類
似。
?
在
TMN
模型中，
EMS
需要被嚴格履行，它通過使用通用管理信息協議（
CMIP
）
與
NE
通信。然而
CMIP
并
沒有得到公共認可，市場上大多數設備在使用
TL1,SNMP
和其他多種機制。一個高效
的
EMS
使用什么協議與
NE
通信
其實取決于
NE
。高效的
EMS
同
樣需要與其他高級管理系統通信，這時就需要使用最為節省成本的協議。因此，無論使用何種協議在
TMN
中
都是被允許的。
?
3
、
OSS
的
TMN FCAPS
模型
作為
TMN
層次結構的補充，
ITU-T
同時劃分出了系統提供的五個通用的管理職能出錯、配置、計費、性能和安全（
FCAPS
）
.
這種分類并非專屬于電信網絡管
理系統的某一層中。
FCAPS
的想法來源于
ITU-T
的
建議，它描述了在管理系統所處理的五種不同的信息。
FCAPS
在
TMN
的各個層次中被處理。例如
,EML
的
出錯管理是記錄下每個警告或事件。
EMS
就過濾這些警告然后發送給
NMS
，
NMS
通過各個節點警告的關聯性來判斷故障的原因。
FCAPS
的功能一部分子集列在表一中
表
1. FCAPS
功能子集
|
Fault Management
|
Configuration Management
|
Accounting Management
|
Performance Management
|
Security Management
|
|
alarm handling
|
system turn-up
|
track service usage
|
data collection
|
control NE access
|
|
trouble detection
|
network provisioning
|
bill for services
|
report generation
|
enable NE functions
|
|
trouble correction
|
autodiscovery
|
?
|
data analysis
|
access logs
|
|
test and acceptance
|
back up and restore
|
?
|
?
|
?
|
|
network recovery
|
database handling
|
?
|
?
|
?
|
?
如果要深入了解
FCAPS
，
學習他們在
EMS
中的實際功用是很有必要的。
?
4
、四功能
EMS
模型
介紹
有了
EMS,
您不必了解電信管理網絡框
架中的任何細節。盡管網元管理層是
TMN
五級塔中的最有價值的部分，真正需要了解的是：
EMS
總管著不同廠商的產品。
－
Dan O'Shea,Supplements Editor
"Taming the Elements,"Telephony,
September 14.1998
?
TMN
的
FCAPS
模型非常有用因而被經常
提及。但是，它過于抽象使得
EMS
難以操作和評價其經濟價值。
?
SP
認為工作（和其相關的開銷和時間）必須專著在為客戶提供服務上。
TeleManagement Forum
（之前的網絡管理論壇
[NMF]
）
于
1997
年的研究就是個好例子。這份基于對
SP
充
分了解的研究確定了一系列的高水準的
TMN
構架中每一層需要完成的程序以及其支援子程序。
?
TeleManagement Forum
所定義的
EML
必
須提供的基礎數據和操作高水準程序為：
0
服務提供
1
網絡開發與規劃
2
網絡目錄管理
3
網絡提供
4
服務保障
5
網絡維護和恢復
6
網絡監視和控制
?
理解
EMS
有與
NML
的連接是很重要的，這種連接用來交換比如集成的出錯管理和流量規范等信息。
EMS
也經常用大數據傳輸協議接口直接對更高的
SML
和
BML
提供計劃和分析數據。基本上，
NML
有
三個主要功能：
※
對基于不同客戶和技術的網絡進行集成化的出錯管理和故障分析
※
對基于不同客戶和技術的網絡，能夠有集成化的單屏幕端到端的服務規范
※
是
EML
和
SML
中間的集成層；從眾多
EML
中
收集信息，然后集成之、聯系之，對信息歸納，從而能夠把相關的信息傳給
SML;
這
些通常是與相應網絡技術相關聯的端到端信息，當然這些技術是為了滿足顧客的特定需求而導入的；相反方向
NML
從
SML
接收信息，處理后把相關命令
和數據傳給相應的
EMS
；再由
EMS
把命令發送給
NE
。
?
有一個開放、標準、北行接口的
EMS
是
SP
開發
TeleManagement Forum
所定義的高水準
TMN
框架
NML
、
SML
和
BML
應用的堅強基礎。
EMS
也在
TeleManagement Forum
所定義的成本效益開發中有重要意義。
?
本教程整理了四功能
EMS
模
型，這個模型合并了
EMS
的所有任務，它包括
:
功能
1
：服務提供
功能
2
：服務保障
功能
3
：
EMS
和
NE
運營支持
功能
4
：自動開關
?
從主題
5
到
8
將描述這四個功能領域的典型任務。這些任務對
SP
的
減耗和增收有著潛在意義。
EMS
已經成為了一個很有價值的部分而不僅僅是
NE
接
口的擴展。并非所有的
EMS
都將完成這些任務，有些可能會更多有些可能根據特定的
NE
只完成其中的一個。
?
本四功能模型僅給
SP
為自
己的
NE
決定管理功能時提供一個參考。在
EMS
圖
形用戶接口（
GUI
）前的用戶可以完成一些或全部四任務模型
EMS
所
提供的任務。
EMS GUI
的某個特定功能是否完成取決于更高級的管理系統中是否已經包含了這個任務。
?
5
、服務提供
服務提供是使電信網能夠被網絡客戶或用戶所使用的所有過程。這些過程是多面的，包含有與安裝設備、規
劃容量、提供容量、升級和保護
NE
數據庫的完整性相關的任務。
EMS
是
NML
、
SML
和
BML
能否達到
TeleManangement Forum
所規定的高水準流程的關鍵。下面是三個由
EMS
服務提供所支持的高水準流程：
※
網絡開發與規劃
※
網絡目錄管理
※
網絡提供
這些高水準流程由下面這些支撐
EMS
的
塊完成：
※
目錄管理支持
包括維護一個在子網中安裝的
NE
資源
的目錄來支持服務提供，包括地址收集、設備數、模塊數、序列號、版本、安裝日期等等。
?
※
配置管理支持
子網資源、拓撲圖、冗余等的總量控制；包括安裝和開啟新的設備資源；
可能包括資源的分派比如路由和服務區域、設備的控制和子網防護開關；可能也包括為共享而分割物理子網資源成虛擬私網。
※服務供應支持
包括網絡的創建或者子網功能的激活以及在客戶需求擴展時如何完成。這些連接或功能可能納入計費系統或
者向客戶許諾的
QoS
水平來決定。
※
服務使用支持
包括客戶子網資源使用情況的度量，這是計費的基礎，只在申請有付費功能的
NE
時才會調用，比如連接或者設置。
?
在
EMS
中的任務
下面這些例子是在
EMS
中
所要完成的任務
?
安裝
NE
※
加
載表格和參數來安裝新
NE
。
※
自
動發現
NE
設備并更新
EMS
數
據庫。
※
構
造一個基于自動發現結果的圖形來報告新
NE
情況。
※
建
立和核查與高級
OSS
的連接。
?
提供和計劃容量
※
自動發現已有設備的環組件，比如交叉連接。
※
從
EMS GUI
或者
NML
的流通道輸入一個新的環組
件。
※
提
供給
SML
目錄系統如下信息：
NE
的模
式數、序列號、未使用的設備等。
※
提供比如交叉連接等環組件的可用容量信息。
?
升級
NE
※
自動發現新設備
※
下
載
NE
軟件包
※
下
載
NE
升級包
※
維
護不斷發布的
EMS
和
NE
軟硬件
?
保護
NE
和
EMS
數據庫的完整性
※
備
份和恢復
NE
運作數據庫。
※
校
驗
NE
與
EMS
連接狀態，如果連接失敗了，
當重新建立連接時
※
EMS
重新同步數據到當前
NE
狀
態。
※
確
保當前運作的完整性，
EMS
周期性的用
NE
自動
發現機制同步數據庫。
?
現代
EMS
經常用自動發現機制來增進準
確度和減少乏味的數據勞動造成的消耗。圖
3
表明
EMS
有如下能力：
※
自動發現所有設備并自動在倉架槽上繪制圖形。
※
自動上傳所有明顯的警報和事件到出錯窗口（在屏幕的底部）。
※
自動發現所有交叉連接并創建相應的圖形表示。
圖
3.
自動發現設備和交叉連接
500)this.width=500;" border="0">
不顯示自動發現的提供有參數的設備，這些設備存在
EMS
數據庫之中，是在其他的服務提供、服務保障、自動配置開關和操作部分之中使用。
?
大多數技術員、專家和商務人士都很熟悉建立在窗口平臺下的程序，點擊圖形，下拉菜單和對話框等使的
EMS
接口更加直觀。
圖
4
用圖形界面和下拉菜單簡化操作和配置
500)this.width=500;" border="0">
一個經過良好設計的用戶接口能在一個屏幕中顯示那些技術無關聯但邏輯
上有關系的功能。
這個屏幕中有簡單的工作流程并包含了一些默認值和可選項來節省時間和減少錯誤。圖
5
是一個
HFC
電話系統。它提供了在客戶房
間的遠程服務單元（
RSU
）和位于電話
SP
中心
的主機數據終端（
HDT
）聯合多點
RF
收發
器（
MRF
）信息。
圖
5.
在同一個屏幕中顯示邏輯相關功能
500)this.width=500;" border="0">
完成配置和提供
RSU
和
相關支持
MRF
的下一步是激活用戶的服務。圖
6
顯示的
是激活家中的電話服務和
SP
的語音交換連接的畫面。
圖
6.
在單屏幕中顯示客戶激活和服務事件
?
500)this.width=500;" border="0">
6
、服務保障
在
QoS
水平下提供服務給客戶后，
SP
必須確保出售的服務已經到貨了。在
EMS
領
域，這包括網絡資源的出錯管理和性能管理。
?
EMS
在維護
NE
和傳輸設備的完善中是關鍵角
色。它聯合
NML
和
SML
中的其他系統來完成這個任
務。
NE
錯誤、事件、技術員的動作和性能數據等都主要存在
EMS
中。
EMS
是
NML
和
SML
去完成
Telemanagement Forum
所定義的高水準流程的關鍵程序。下面是由
EMS
服
務保障所支持五級模型中的兩個功能。
※
網絡維護和恢復
※
網絡監視和控制
?
這些高水準流程由一下這些支撐
EMS
的
塊完成。
※
出錯管理支持
包括監視網路資源以發現故障、搶占錯誤和探測錯誤。錯誤發現之后，操
作員必須盡快研究問題、修理和恢復網絡。再出錯管理確認服務已經可用。
?
※
性能數據收集支持
包括周期性收集質量信息用以刻畫服務時網絡資源的性能。它也能增進對
網絡趨勢的了解，指出物理資源的周期性逐步降級等情況。
?
※
資源利用和數據收集支持
包括收集分配給客戶的網絡資源利用水平。這些數據可以用來判斷服務產品是否與客戶的使用特征相吻合。
也可以用來在
QoS
遭到困難之前給出服務升級的建議。
?
QoS
保障支持
包括確保網絡性能中有多少保留。這需要預先監控網絡的錯誤、性能和利
用率參數并在服務質量下降之前搶先給出警示。
?
在
EMS
中的任務
以下例子是在
EMS
中
的所需要完成的任務：
?
錯誤隔離
※
高
級的
NML
出錯管理和
SML
故
障處理規劃提供第一層預警，并指出的問題的源頭。技術人員進而使用
EMS
數
據庫和
EMS
工具做精確的診斷。
※
很
多
EMS
提供有一個簡單的方法來調用和顯示
NE
診
斷工具的結果進而隔離錯誤。
?
?
EMS
提供了一個或更多的錯誤窗口來顯示領域內
NE
的
警報和事件的詳細信息。警報是一個特殊問題的指示器，它使用預先定義好的動作來觸發一個警報。事件被觸發時發送一條與錯誤一起顯示在警告窗口的訊息。事件
機制的一個比較常見的用途是偵測正在不斷惡化的傳輸設備的狀態并在影響到客戶之前對其作出預警。比如位錯誤（
BER
）和
SLPS
。圖
7
顯示的是一個高級的
troubleshooting
功能，點擊警報將描述所受影響的設備信息。這種機制使得在網絡運營中心（
NOC
）的專家指導遠程設備側操作員到正確的倉架槽中更換問題卡板成為了可能。
圖
7.
一個報警窗口，有能夠找到到所受影響的設備信息的鏈接
?
500)this.width=500;" border="0">
根據
SP
的各自不同的方法、手續和組
織，
NOC
中的專家可能會在服務保障中被分配不同的任務。圖
8
顯示的是一張警報過濾的屏幕，它使得專家能夠從職責最優化的角度去觀察和管理警報事件。
圖
8.
配置警報過濾機制的窗口
500)this.width=500;" border="0">
服務質量
※
EMS
通
過偵測
SLIPS
和
BER
之類的錯誤獲取性能信息并把
它發送到
NML
的出錯管理。這些數據可以在性能影響到客戶使用之前分析惡化的原因。
?
※
EMS
能
夠存儲從
NE
來的性能度量（
PM
）數
據并提供給
EMS
的報告生成器和
SML
的
性能管理和
QoS
系統使用。
?
※
在
NE
和
EMS
的支持下，
EMS
有時提供了
NE
設備
和通信設備的性能診斷能力，這種診斷可以是按照日程表來的，也可以是有要求時才提供。
?
QoS
組件的一個關鍵能力是能夠快速精確地指出問題的原因，從而能夠迅速修復，獲得可能的最短修復時間（
MTTR
）。有些情況下，修復功能可以在
NOC
處
修復，或者客戶在
NOC
專家的指導下修復。圖
9
顯示的
電話程序能夠遠程的對在客戶房間的
RSU
進行診斷和測試從而判斷問題出在客戶電話設備上還是內部配線上。
圖
9.
電話系統的
EMS
爭端屏幕
500)this.width=500;" border="0">
7
、
EMS
和
NE
運營支持
競爭使得
SP
不斷降低網絡運營成本，同時
新服務的復雜程度卻成指數增長，因此
SP
必須用更少的錢做更多的事情。其中最為有意義的一項是需要多少訓練有素的專家來完成工作，因為如下
原因使得這種情況更為復雜：
※
越
來越多來自不同廠商的
NE
出現在市場上。
※
NE
正
在飛速發展者
※
訓練有素的專家總是短缺的
※
勞動指出不許保持在低水平，同時能夠保證提供高質量創新性的服務
※
SP
知
道必須對效率不高的員工進行
NE
培訓
以上這些總是缺乏有力的支持，盡管如此還是需要大量有著
NE
和
EMS
知識的員工。沒有訓練有素的
員工時
SP
需要一個更敏銳的系統管理流程。
?
要戰勝這些挑戰就需要一些以完成任務為最終目標而且能夠使效率和適應性最大化的工具支持。因而，
EMS
需要有如下這些特性：
※
易用
需要一個直觀的、面向任務的
GUI
來
在最短的時間內顯示出運營的各種功能。
?
※
上下文相關的幫助
使得專家能夠完成那些遇到的頻率不高或者他們從未接觸到的任務。
?
※
統一的桌面
允許工作在
NML
、
SML
或者
BML
的用戶直接打開任何
EMS
的窗口，允許
EMS
直
接打開其所管理的
NE
的管理窗口。
?
※
低成本運營平臺
目標是使用總成本（獲取、運行）最低化的
EMS
運
行平臺。計算平臺比如
Windows
NT
等能夠滿足電信的健壯性、可量測性和性能的要求。
?
※
遠程訪問
運行運營人員從任何地方訪問管理信息；這種分布式工作模式大大提高了出錯時的反映速度。在今天的互聯
網世界中，這意味著瘦客戶端工作站可通過
Internet
和
SP
的
Intranets
來操作。
?
圖
3
到
9
提供了一個有效的人機界面設計，它減少了訓練和技能的要求、增進了正確性、節省了時間和成本。圖
10
顯示的是上下文相關幫助更加明顯的減少了技能和訓練需求，它可以引導用戶一步一步的完成復雜任務。
圖
10.
任務向導引導專家完成復雜任務
500)this.width=500;" border="0">
EMS
的數據庫中存有豐富的信息，這些信息可以改進服務、節省時間和成本。大多數
EMS
都提供有一個標準報告庫和報告生成器，并可以將數據導出到其他專業的分析程序中（圖
11
）。
圖
11.
一個
EMS
所提供的報告例子
500)this.width=500;" border="0">
8
、自動開關
圖
12..
如果
TMN
的
EML
停止工作，
NOC
將會編程測樣子
500)this.width=500;" border="0">
?
EMS
扮演者其所屬范圍內所有管理信息負責人的角色。就像命令和控制信息等一樣，它還通過北行接口提供給
NML
這些信息的摘要。因而，
MES
有
如下功能
:
※
信息存儲
要求
EMS
把所有從
NE
收集來的信息存儲下來
?
※
模
擬
EMS
域
包括創建相應的信息模型，用來組織管理信息的存儲，這些信息可以提供
子網的控制能力。
?
※
EML
的
標準化
包括把
EML
的專業信息模型映射成能夠為
NML
識別的通用子網模型，這種映射能夠有效的隱藏起
NE
層
的細節而突出那些與特定技術無關的子網模型。
?
※
北行接口
包括對用來在
EMS
和
NMS
之間通訊的協議和機制的支持；這種接口用來開啟管理系統自動機制，這也是為何
NE
資源能夠在不需要
EMS
干
涉的情況下由
NMS GUI
間接控制的原因。
?
※
單屏幕多廠商交叉域的管理
需要
EMS
能夠通過北行接口發送
NMS
所需要的信息，需要
EMS
從
NE
供應商們各自獨立的人機接口或某種技術中實現集成化的端到端管理；
EMS
最好提供一個切入機制，通過這個機制能夠允許
NOC
中
的專家在
NMS
工作站屏幕上直接打開相應的
EMS
的
窗口，這個窗口也能同時在其他相關
NMS
屏幕上顯示。
?
典型的北行接口
※
TL1
一個可以用來發送過濾后的警報信息到
NML
出
錯管理系統的接口。
?
※
開
放數據庫連接（
ODBC
）
EMS
報告生成器或其他分析和報告程序所使用的大數據傳輸接口。
?
※
SNMP
見到
NE-EMS
接口系統，用來發送陷
阱（錯誤）到
NML
出錯管理系統。
?
※
Q3/CMISE
TeleManagement Forum
為高級
NE
發送過濾后警報到
NML
出錯管理系統的而制定的雙向
CORBA
接
口。
?
開放
EML
到
NML
接口的突破
TeleManagement Forum CORBA "
為管理
SONET/
同步數據層次（
SDH
）網絡的
NML-EML
接口
"
項目宣告了
OSS
實
用時代的來臨。開發一種能夠使
SP
從單個終端就能更容易的管理來自不同廠商的網絡的接口（圖
13
），這個在重重困難中的努力。
圖
13.
全球
EML
到
NML
接口標準的突破
500)this.width=500;" border="0">
開發第一版草案的公司有
Fujitsu
、
Lucent
Technologies
和
Tellabs
。這些公司組成的小組將主要精力放在了網元管理層到網絡管理層上（
EML-NML
）的以
CORBA
為基礎的開放式接口上。
并在
Orlando Florida
舉行的
NFOEC(1998.9)
大會
和
TeleManangement
World Conference(1998.10)
大會
上做了演示。
NML
是一個運行于
UNIX
平
臺上的
Lucent ITM-NM
網絡管理系統（圖
14
），
它通過
CORBA
接口與以下部分通訊：
※
運
行于
Sun Solaris
平臺下的
Java
編
寫的
Fujitsu
NETSMART EMS
程序，它管理著有
FLM 150 ADM
的
OC-3 UPSR
環
※
基
于
Windows NT
平臺采用了
Euristix RACEMAN
技術的
Tellabs TITAN 5500 EME
系統，它管理著一臺
TITAN
5500 SONET
款待數字交叉連接系統
※
基
于
UNIX
平臺的
Lucent ITM-SNC EMS,
它管理一臺有著
Lucent
DDM-2000 ADM
的
OC-3 UPSR
環。
?
演示表明，
Lucent ITM-NM
網絡管理系統提供了從
Fujitsu
上
DS-3 ADM
的
A
點通過
TITAN 5500 DCS
到達
Lucent
上的
Z
點的機制。這是工業界首次主導這種基于標準、易管理、多廠商網絡的應用。
?
1999
年
8
月，草案工作小組在原來三家公司
的基礎上又加入了
Nortel
Networks, Siemens AG
和
Telcordia Technologies(
從前的
Bellcore)
。草案小組把
它推薦到
TM Forum
審議。最終在
1999
年
8
月，由來自
MCI WorldCom
、
Tellabs
、
Fujitsu
、
ADA
、
Ciena
、
DSC
、
ECI
、
Telecom
、
Lucent Technologies
、
Nortel Networks
、
Siemens AG
、
Telcordia Technologies
、
TTI-Telecom
和
Vertel
的代表組成了
TM Forum Information
Modeling(SSIM)
小組。
?
注意
:
在
1999
年
9
月
NFOEC'99
會議上，圖
14
所示
的演示已經被擴張到包含了
Nortel
Networks
、
Siemens AG
和
Telcordia Technologies
的
NE
和
EMS
的系統。
圖
14. The NFOEC
和
TeleManagement World
Multivendor CORBA Configuration
500)this.width=500;" border="0">
最初
TM Forum
通過的
CORBA
模型是
1999
年
9
月的
TM Forum 509
。
TM Forum
已經批準了
SONET/SDH
模型的擴展，包含有對異步傳輸模式（
ATM
）和高密度多工分波器
(DWDM)
技術的支持。可以預見，集成化、開放式的標準
CORBA EML
到
NML
模型接口將能夠支持不斷發展著的
NE
技
術。
?
為什么重要？
越來越復雜的
NE
使得
電信設備供應商必須提供一個能適應
TMN
構架的
EML-EMS
應用來支持各自不
同的
NE
類型。早期版本的
EMS
只
提供一種
TL1 EML
到
NML
的出錯管理接口。之所以使用
TL1
是因為它是一種能夠為
NML
所
管理的不同廠商所提供的
NMS
系統所接受的標準。
?
因為競爭，
SP
必須
盡快把新服務推向市場。這要求
SP
能夠快速的獲得下一代
NE
并創
造性的用他們滿足客戶的需求。新
NE
必須能夠很容易的集成進現有網絡管理結構的集成出錯管理、流服務、
QoS/
性能管理、計費、安全和能夠適應終端用戶的網絡管理。
?
與上面的四層
TMN
互
連
經典的
TMN
層次結構模型是金字塔型上下
垂直的圖示，它容易使人覺得所有通訊都是從相鄰層向上或下流動的；因為以下這些原因使得這種想法并不完成正確：
※
比
如對
EMS
收集來的數據進行分析和報告的程序，它們可能直接由
SML
程序通過
ODBC
之類的協議接口來傳輸。
※
并
不是所有
TMN
層程序都術語同一個團體；比如：一個
SP
可
能擁有一個網絡并把產品和服務賣給客戶；同時它可能還把自己的帶寬資源賣給其他
SP
，這
時每個
SP
都由自己單獨的
SML
和
BML
。
※
大
客戶日益需要購置自己的網絡能力并利用一種客戶網絡管理（
CNM
）的系統來提供網絡服務。
※
從
其他
SP
處購買服務的
SP
們都
在合同種對
QoS
有約定，這要求
OSS
到
OSS
端的通訊接口，與
1988
年
ITU-T
所開發的
TMN
構架所謂的“上下
TMN
棧”式完全不同。
?
圖
15
描述的是基于特定任務的
OSS
到
OSS
的通訊必須在
TMN
的每個層都得到支持。
圖
15.
使用適當的接口標準來滿足工作流程
500)this.width=500;" border="0">
?
9
、網絡
EMS
軟件構架
EMS
構架需要滿足以下基本要求：
※
它應能根據設備和管理環境提供相適應的管理功能水平
※
它應能通過升級來滿足不斷增長著的需求和日趨復雜的網絡
※
它應能分布部署來獲得更高的可用性和可量度性
?
數據庫技術是所有可信賴
EMS
中
的關鍵部分。圖
16
是一個能夠滿足以上要求的網元管理軟件構架的例子。客戶端的服務器接口從前是遠程過程調用（
RPC
）現在演化到
CORBA
、
DCOM
、
Java/Web Server
、
或其他適當的接口。
圖
16
網元管理軟件構架的層次視圖
500)this.width=500;" border="0">