综合网管的资源需求和互联接口的建议
第1章 资源管理系统的现状
北京电信的资源调度管理系统由北京华胜鸣天科技有限公司于2002年开始承建，现已基本建设完成。
1.1 资源管理系统的网络
资源管理系统涵盖的网络包括：传输网、数据网、交换网等。
1.2 资源管理系统的功能
北京电信的资源调度管理系统实现了基础空间信息管理、管道艾特所有人/杆路网络资源管理、电缆网络资源管理、光缆网络资源管理、传输网络资源管理、交换网络资源管理、数据网络资源管理、线路设计、资源调度方案设计及调度管理、综合查询、统计、分析。
1.3 资源管理系统存放的数据
资源管理系统存放的数据包括：
基础空间信息：局站、机房、背景地图(道路、居民地、河流、铁路、绿地......)
管道/杆路网络资源：人/手井、管道段、管孔、子管、电杆、吊线、线担/支架/抱箍、吊瓶/线夹、杆路路由等
电缆网络资源：电缆段、电缆附件信息(传感器、分歧接头、气门、余长点等)、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 功能接口
2023春节高速路免费的时间表功能接口是面向业务的互联互通协议，通过功能接口，两系统可以实现应用功能的互访，从而实现业务的互通，例如，综合网管系统对故障进行分析，其分析结果可以通过调用资源管理系统的相应呈现功能，在资源管理系统里呈现出来，另一方面，资源管理系统也可以通过功能接口向综合网管系统主动地发起对网络的分析和管理请求。
通过功能接口，使得两系统能够相互配合实施业务支撑，比如，业务的受理与开通，无论单独的资源管理系统，还是单独的综合网管系统，都是无法独立完成，在进行业务受理与开通时，首先需要在资源管理系统里查询相关资源的状态并实施预占，然后再在综合网管系统里实施具体的配置与测试等操作，最后返回到资源管理系统里将预占的资源修订为实占，从而完成业务的开通，在这个流程中，如果没有功能接口的支持，我们只能在两个系统间进行切换操作，不仅不方便，还很容易出错。而通过功能接口，我们就可以构造出一个统一的界面来实施业务，这里获得的好处，不仅是操作上的方便或高效，更重要的是我们能够对业务流程实施控制和管理。
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。因此这种接口技术的典型实现方式就是开放数据库视图，或者通过平面数据文件进行导入导出。
第三，这种接口技术很难维持数据的一致性，由于两个系统内在的数据模型是异构的，资源管理系统能够开放的数据接口只能够做到依据其内在的数据模型而开放，因此，综合网
管系统并不能够直接使用从接口中获取的数据，需要对其进行再加工，转换成综合网管系统内部的数据模型，这样同一个东西就被存储在了两个不同的地方，在没有额外的机制保证下，这种存储在两个系统中的数据极易发生不一致，只要资源管理系统对数据进行了变更，综合网管系统内的资源数据就处于不一致的状态，直至综合网管系统重新从资源管理系统中获取数据。