综合网管和资源管理系统的关系.docx

综合网管和资源管理系统的关系.docx

《综合网管和资源管理系统的关系.docx》由会员分享，可在线阅读，更多相关《综合网管和资源管理系统的关系.docx（17页珍藏版）》请在冰豆网上搜索。

综合网管和资源管理系统的关系

综合网管的资源需求和互联接口的建议

第 1 章 资源管理系统的现状

北京电信的资源调度管理系统由北京华胜鸣天科技有限公司

于 2002 年开始承建，现已基本建设完成。

1.1 资源管理系统的网络

资源管理系统涵盖的网络包括：

传输网、数据网、交换网等。

1.2 资源管理系统的功能

北京电信的资源调度管理系统实现了基础空间信息管理、管道/杆路

网络资源管理、电缆网络资源管理、光缆网络资源管理、传输网络

资源管理、交换网络资源管理、数据网络资源管理、线路设计、资

源调度方案设计及调度管理、综合查询、统计、分析。

1.3 资源管理系统存放的数据

资源管理系统存放的数据包括：

基础空间信息：

局站、机房、背景地图（道路、居民地、河流、铁路、

绿地......）

管道/杆路网络资源：

人/手井、管道段、管孔、子管、电杆、吊线、

线担/支架/抱箍、吊瓶/线夹、杆路路由等

电缆网络资源：

电缆段、电缆附件信息（传感器、分歧接头、气门、

Comment [leiming1]:

 有接入网吗？

Comment [leiming2]:

 有该功能吗？

余长点等）、MDF、交接箱、分线盒等

光缆网络资源：

光缆段、光缆附件信息（光纤接头盒、余长点）、

ODF、光交接箱、光分纤设备等

传输网络资源：

DWDM/PDH/SDH 设备物理资源、

DWDM/PDH/SDH 逻辑资源（如光波道、段、通道、槽道、电路等）

接入网络资源：

IDLC 设备及逻辑资源、PON 设备及逻辑资源、

FWA 设备及逻辑资源（基站设备、基站控制器、固定用户站设备）、

xDSL 设备及逻辑资源、以太网接入设备资源等。

数据网络资源：

ATM、IP、DDN、帧中继、分组交换等网络设备资

源及逻辑资源

交换网络资源：

交换节点、固定电话网络交换机、局号资源、MDF

横列、中继电路、信令链路等。

动力资源：

电源设备：

发电机、高压变配电、低压配电、变流设备

（开关整流器、相控整流器）、直流配电、蓄电池组、UPS、逆变器等；

空调设备：

中央空调、专用空调（恒温恒湿空调）、分体空调等。

时钟资源：

BITS 设备、时钟通道。

业务资源：

业务类型、业务实例。

客户资源：

客户类型、客户实例。

综合管理功能

网管系统

资源管理系统

备注

故障的定位

实时告警

基于拓扑的故障

的相关性分析

实时告警，逻辑资源数据

物理资源数据

故障对业务和客

户的影响

实时告警，逻辑资源数据

业务、客户数据

网络资源的综合

呈现

逻辑资源数据

业务、客户、物理

资源数据

业务开通

业务开通指令

业务资源的预占，

规划和状态查询

端到端的业务管

理

网络性能数据

业务资源

第 2 章 综合网管对资源数据的需求

2.1 综合网管系统和资源数据的关系

联想提供的综合网管产品是一个完整的 OSS 系统，除了包含了

基本的故障管理和性能管理等网管功能外，同时提供和资源管理系

统的紧密集成，支持网络资源的综合呈现，支持故障对业务和客户

的影响分析，支持端到端的业务的管理，支持用户订单的处理，实

现业务的快速开通等综合管理功能。

这些功能是通过对告警数据、

性能数据，逻辑资源数据、物理资源数据、业务资源数据的综合分

析和处理实现的，其中告警数据、性能数据和逻辑数据可以通过网

管系统对智能网络设备的数据得到，但物理资源数据和业务资源数

据不能直接从网络设备中得到，需要从企业的资源管理系统获取。

下表为综合管理功能对资源数据的依赖关系:

由此可见，综合网管系统的功能和资源数据是紧密相关的，是以

资源数据的分析为基础的，北京电信的综合网管的建设必须将现有

的资源管理系统中的与网管相关的数据通过专用的数据接口集成进

来。

2.2 综合网管需要的资源数据

综合网管需要的资源数据主要是指与网管的功能紧密相关的，

从网络设备和网元管理系统无法自动提取的设备的相关描述信息、

网络的物理连接关系数据以及和网络所承载的业务和用户等资源数

据，具体包括以下内容：

●地理层次结构

●资源类型

●专业网

●设备功能

●设备技术

●复用层次

●电路类型

●资源的状态信息

●路由类型

●服务类型

●厂商

●站点

●位置

●客户信息

●设备类型

●设备

●缆线段

●缆线传导介质

●电路

●路由段

●端口

●通道

●服务

●服务资源

详细描述请见文档:

Data import to Netrac Inventory database.doc

2.3 资源数据的有效性对综合网管的影响

资源数据的有效性主要是指其完整性和正确性以及和实际网络

配置状态的一致性，因为经过上面的分析可以看出：

许多综合管理

功能是通过对的资源数据的分析做出的，所以资源数据的有效性将

直接影响到综合网管的管理功能，例如：

无法完成基于网络物理结

构的告警相关性分析，无法实现快速的业务开通等等。

第 3 章 互联接口技术建议

3.1 综合网管系统与资源管理系统的互联点

综合网管系统与资源管理系统是两套完全独立建设的系统，但

同属于电信运营支撑系统的范畴，两套系统在数据和业务上存在着

互补性，综合网管系统要利用资源数据进行面向全网的综合分析，

而分析结果则可以在资源管理系统里进行呈现，另一方面，综合网

管系统还可以向资源管理系统提供动态的配置数据，使得资源管理

系统能够动态且自动地呈现出网络的运营状态，因此，在两套系统

之间很自然地就要实现数据和业务的互联互通。

为了实现两系统在数据和业务上的互联互通，需要在两系统间

定义互联互通的协议，并通过相应的接口来实现。

从数据和业务两

个层面来考虑，相应的定义“数据接口”和“功能接口”。

3.1.1数据接口

数据接口是最基本的互联互通协议，通过数据接口，两系统可

以实现数据的共享和互访，避免了在两套系统内各自维护不一致数

据所造成的额外投资和额外工作量，实现了数据的高利用率和一致

性、完整性。

数据是电信运营支撑系统的基础，如果在电信运营支撑系统内

出现数据在一致性和完整性上的缺陷，那么除了上面提到的额外投

资和额外工作量外，电信运营支撑系统在功能上也不能够对业务实

施强有力的支撑，例如，如果综合网管系统没有完整的资源数据，

那么在网络故障的管理上，我们就很难判断出故障点，以及故障所

造成的影响。

通过数据接口，我们在最基本的层面上实现了两系统的互联互

通，为更进一步通过“功能接口”来实现两系统的互融提供了坚实

的基础。

3.1.2功能接口

功能接口是面向业务的互联互通协议，通过功能接口，两系统

可以实现应用功能的互访，从而实现业务的互通，例如，综合网管

系统对故障进行分析，其分析结果可以通过调用资源管理系统的相

应呈现功能，在资源管理系统里呈现出来，另一方面，资源管理系

统也可以通过功能接口向综合网管系统主动地发起对网络的分析和

管理请求。

通过功能接口，使得两系统能够相互配合实施业务支撑，比如，

业务的受理与开通，无论单独的资源管理系统，还是单独的综合网

管系统，都是无法独立完成，在进行业务受理与开通时，首先需要

在资源管理系统里查询相关资源的状态并实施预占，然后再在综合

网管系统里实施具体的配置与测试等操作，最后返回到资源管理系

统里将预占的资源修订为实占，从而完成业务的开通，在这个流程

中，如果没有功能接口的支持，我们只能在两个系统间进行切换操

作，不仅不方便，还很容易出错。

而通过功能接口，我们就可以构

造出一个统一的界面来实施业务，这里获得的好处，不仅是操作上

的方便或高效，更重要的是我们能够对业务流程实施控制和管理。

3.2 互联互通接口要考虑的问题

在定义互联互通接口时，要着重考虑如下几方面的问题：

3.2.1安全性

应该引入完善的认证与授权机制，以保证对数据和功能的访问是

受控的，避免非法的操作，以及有意或无意的操作对系统所造成不

良干扰，例如，没有限制的增删数据就会造成系统数据的混乱。

3.2.2隔离性

虽然综合网管系统与资源管理系统存在互补性，但由于这两个系

统所处理的问题域并不相同，有着各自的私有数据和私有功能，因

此互联互通接口要有很好的隔离措施，保证私有数据和私有功能的

安全。

3.2.3灵活性

综合网管系统和资源管理系统作为两个独立建设的系统，其实

施技术都不尽相同，存在着不同的技术理念，数据在定义、格式等

方面都有较大的差异性，因此，互联互通接口要有足够的灵活性来

解决这些差异性所造成的问题，例如，定义不同的数据转换规则，

从而保证数据在两个系统间平滑的转移。

另外，综合网管系统与资源管理系统的互联互通并不是从一开

始就明确所有的需求，这是一个随着认识的深入而逐步完善的过程。

因此，互联互通接口要有足够的能力来适配新需求的出现。

3.2.4扩展性

互联互通接口当前首要的是要解决综合网管系统和资源管理系

统之间的关系，但互联互通接口也潜在地要解决与其它系统（计费、

营帐等）的关系，因此，互联互通接口在技术上要有良好的扩展能

力，例如，对 J2EE、CORBA 等技术的支持，以方便的扩展到其它

技术领域和问题领域。

3.2.5数据一致性

通过互联互通接口，综合网管系统/资源管理系统都不再是单纯

的面对存储在自身系统内的数据，也有操控对端数据的能力，因此，

互联互通接口必须要承担起维持两系统间的数据一致性的责任。

3.2.6高效性

互联互通接口要保证适当的运行效率，根据需求提供实时或准实时的交互性能。

3.3 互联互通接口的技术架构

基于上述对互联接口在安全、灵活、扩展等方面的考虑，互联接口适宜采用“桥接

器（Bridge Connector）”技术来实现，其技术架构如下图所示：

技术架构图

桥接器独立于综合网管系统和资源管理系统，它既不属于综合

网管系统，也不属于资源管理系统，而是介于两者之间的一个中间

层。

通过桥接器，我们可以在综合网管系统和资源管理系统这两个

异构系统间建立起稳定可靠的连接，实现数据共享和平滑互访，实

现系统功能的相互调用，满足安全性、隔离性、灵活性、扩展性、

数据一致性等多方面的要求。

3.3.1为什么要构建桥接器

当我们考虑到要在两个系统之间开放互联互通接口的时候，通

常我们的第一个原始想法就是两个系统互相直接向对端开放接口，

如下图所示：

直接开放接口

然而这种直接开放接口的技术具有很大的局限性：

首先，这是一种僵化的手段，资源管理系统暴露给综合网管系

统的接口，依赖于综合网管系统对资源管理系统所提出的需求，也

就是说接口与具体的需求是紧密绑定的，一旦需求发生变化，那么，

接口也要跟着变化，否则就不可能实现访问。

最简单的情形，综合

网管系统要求增加访问资源数据的属性字段，资源管理系统的接口

就必须要进行改写，增加这些属性字段。

其次，这种接口技术只能实现数据层的互联，而不能（或者很

困难）实现业务层功能的互联，因为两个系统是异构的，采用的是

不同的技术和系统平台，因此两个系统要实现直接的功能互访相当

困难，除非它们同时遵循相同的体系规范，如 J2EE。

因此这种接口

技术的典型实现方式就是开放数据库视图，或者通过平面数据文件

进行导入导出。

第三，这种接口技术很难维持数据的一致性，由于两个系统内

在的数据模型是异构的，资源管理系统能够开放的数据接口只能够

做到依据其内在的数据模型而开放，因此，综合网管系统并不能够

直接使用从接口中获取的数据，需要对其进行再加工，转换成综合

网管系统内部的数据模型，这样同一个东西就被存储在了两个不同

的地方，在没有额外的机制保证下，这种存储在两个系统中的数据

极易发生不一致，只要资源管理系统对数据进行了变更，综合网管

系统内的资源数据就处于不一致的状态，直至综合网管系统重新从

资源管理系统中获取数据。

第四，扩展性差，由于这种直接接口是针对了某些具体的需求

而设定的，因此，第三方应用就不可能使用这些接口，而必须在两

系统间进行需求界定，然后开发开放相应接口。

因此，对于存在有

很多个独立系统的情形，这种直接接口技术的可实现性就变得很低，

很难想象开发和维护一大堆接口的工作量是多么巨大。

由于桥接器能够内建多种机制来保证安全性、隔离性、灵活性、

扩展性、数据一致性等多方面的要求，因此桥接器是实现互联互通

接口的比较好的技术手段。

桥接器就好像是多个独立应用系统间的

交通枢纽，各应用系统之间不需要发生直接的联系，而是经过桥接

器的调度。

3.3.2桥接器的技术实现

3.3.2.1基本原理

桥接器的基本技术原理如下图所示：

基本原理图

详述如下：

适配器（Adapter）

适配器是在应用系统与桥接器之间建立访问联系的构件，适配器

实现如下（主要）功能：

⏹ 采取适当的技术（如 Socket、RMI-IIOP、DB connection 等）

实现应用系统与桥接器的可靠连接

⏹ 应用系统通过 Adapter-Agent 在桥接器中注册允许被访问的功

能

⏹ 应用系统通过 Adapter-Agent 调用注册在桥接器中的功能

⏹ 桥接器通过 Adapter-Agent 识别应用系统的数据模型

⏹ 应用系统通过 Adapter-Agent 向桥接器上报数据

⏹ 桥接器通过 Adapter-Agent 向应用系统传送数据

其中，Agent 是桥接器所规范由应用系统来实现，也就说应用系

统必须遵循 Agent 规约并实现 Agent，Agent 规约规定了如下（主要）

内容：

Ø 应用系统数据模型的元数据表达

Ø 应用系统被访功能的调用机制

Ø 应用系统与桥接器之间的消息格式

Ø 应用系统必须实现的接口方法

功能注册（Function Registry）与功能调度（Function Dispatcher）

功能的注册/调度机制实现了分布式的远程功能调用，当一个应

用系统打算使用另一个应用系统的功能的时候，它只需要在桥接

器中的功能注册表里找到该功能的入口，即可像在本系统内一样

访问该功能。

数据类型映射（DataTypeMapping）与数据转换（Data

Transformer）

由于两个应用系统的数据模型是不一样的，因此，要实现两系统

间数据的平滑访问，就必须在两种数据模型间进行必要的数据转

换。

桥接器可以获取应用系统的数据模型的元数据表达，然后在两个

应用系统的数据模型间建立起数据类型的映射关系（由系统管理

员配置），这样，当数据在两个系统间发生传送时，桥接器就会

依据数据类型映射将数据自动转换到新的数据模型下，从而被识

别。

3.3.2.2具体实现

J2EE 是实现桥接器的理想技术，因为 J2EE 提供了很多标准的服

务，能够对桥接器的实现提供全面的支持：

Ø J2EE 的认证与授权服务（JAAS）为桥接器的认证与授权功

能提供了实现基础

Ø J2EE 的 JNDI/RMI-IIOP 为桥接器实现功能的注册与调度提供

了实现基础

Ø J2EE 的消息服务（JMS）为实现数据的可靠传送提供了实现

基础

Ø J2EE 的事务服务（JTS）为一致可靠的数据访问和功能访问

提供了实现基础

Ø J2EE 的连接器架构（JCA）为桥接器平滑升级到 EAI 应用提

供了实现基础

3.3.2.3关于大数据量的数据传递问题

在综合网管系统和资源管理系统之间进行数据互访，不可避免地

会面临大数据传递的问题，桥接器是如何处理的呢？

在保持数据一致性的前提下，桥接器针对两种情形提供两种手段：

（1）快照（Snapshot）访问

对于快照型的数据访问，桥接器通过提供快速的数据拷贝服务

（如：

FTP Service）来实现高速高性能数据传递。

（2）联机访问

对于联机数据访问，桥接器向应用系统提供一个数据迭代器，应

用系统每次从迭代器中取出一部分数据进行处理。

迭代器可以有效

地解决数据的脏读（dirty reads）、虚读（phantoms）等问题。