分类：
2007-01-22 10:25:41
/*这是一篇翻译的文章，原文请看
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在电信网络中所处的位置
一个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构架模型
如图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有三个主要功能：
※对基于不同客户和技术的网络进行集成化的出错管理和故障分析
※对基于不同客户和技术的网络，能够有集成化的单屏幕端到端的服务规范
有一个开放、标准、北行接口的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.自动发现设备和交叉连接
不显示自动发现的提供有参数的设备，这些设备存在EMS数据库之中，是在其他的服务提供、服务保障、自动配置开关和操作部分之中使用。
大多数技术员、专家和商务人士都很熟悉建立在窗口平台下的程序，点击图形，下拉菜单和对话框等使的EMS接口更加直观。
图4 用图形界面和下拉菜单简化操作和配置
一个经过良好设计的用户接口能在一个屏幕中显示那些技术无关联但逻辑上有关系的功能。
这个屏幕中有简单的工作流程并包含了一些默认值和可选项来节省时间和减少错误。图5是一个HFC电话系统。它提供了在客户房间的远程服务单元（RSU）和位于电话SP中心的主机数据终端（HDT）联合多点RF收发器（MRF）信息。
图5. 在同一个屏幕中显示逻辑相关功能
完成配置和提供RSU和相关支持MRF的下一步是激活用户的服务。图6显示的是激活家中的电话服务和SP的语音交换连接的画面。
图6. 在单屏幕中显示客户激活和服务事件
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. 一个报警窗口，有能够找到到所受影响的设备信息的链接
根据SP的各自不同的方法、手续和组织，NOC中的专家可能会在服务保障中被分配不同的任务。图8显示的是一张警报过滤的屏幕，它使得专家能够从职责最优化的角度去观察和管理警报事件。
图8.配置警报过滤机制的窗口
服务质量
※EMS通过侦测SLIPS和BER之类的错误获取性能信息并把它发送到NML的出错管理。这些数据可以在性能影响到客户使用之前分析恶化的原因。
※EMS能够存储从NE来的性能度量（PM）数据并提供给EMS的报告生成器和SML的性能管理和QoS系统使用。
※在NE和EMS的支持下，EMS有时提供了NE设备和通信设备的性能诊断能力，这种诊断可以是按照日程表来的，也可以是有要求时才提供。
QoS组件的一个关键能力是能够快速精确地指出问题的原因，从而能够迅速修复，获得可能的最短修复时间（MTTR）。有些情况下，修复功能可以在NOC处修复，或者客户在NOC专家的指导下修复。图9显示的电话程序能够远程的对在客户房间的RSU进行诊断和测试从而判断问题出在客户电话设备上还是内部配线上。
图9.电话系统的EMS争端屏幕
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.任务向导引导专家完成复杂任务
EMS的数据库中存有丰富的信息，这些信息可以改进服务、节省时间和成本。大多数EMS都提供有一个标准报告库和报告生成器，并可以将数据导出到其他专业的分析程序中（图11）。
图11.一个EMS所提供的报告例子
8、自动开关
图12..如果TMN的EML停止工作，NOC将会编程测样子
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接口标准的突破
开发第一版草案的公司有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
最初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.使用适当的接口标准来满足工作流程
9、网络EMS软件构架
EMS构架需要满足以下基本要求：
※它应能根据设备和管理环境提供相适应的管理功能水平
※它应能通过升级来满足不断增长着的需求和日趋复杂的网络
※它应能分布部署来获得更高的可用性和可量度性
数据库技术是所有可信赖EMS中的关键部分。图16是一个能够满足以上要求的网元管理软件构架的例子。客户端的服务器接口从前是远程过程调用（RPC）现在演化到CORBA、DCOM、Java/Web Server、或其他适当的接口。
图16网元管理软件构架的层次视图
