原文: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">