CN101212342A - 多版本网元的网络管理方法 - Google Patents

Abstract

本发明公开了一种多版本网元的网络管理方法，该方法包括步骤：将各版本网元信息模型以版本链形式保存于服务器端；客户端从服务器端加载网元对应的信息模型，并加载信息模型中管理对象对应的处理逻辑，将处理逻辑下发给所述网元。本发明不同于现有技术中各版本网元采用不同MOI/MOC管理的方式，而是采用相同的MOI/MOC，通过信息模型指示去动态加载其所对应的处理逻辑，处理逻辑不再与信息模型相挂钩，对于版本不同但处理逻辑相同的网元，只需要加载已有的处理逻辑即可。本发明提升了网管系统的扩展性和可维护性；使不同版本的网元处理逻辑利用率最大化，降低了网元维护管理成本。

Description

多版本网元的网络管理方法

技术领域

本发明涉及电信网络管理技术领域，尤其涉及一种用于管理多版本网元的网络管理方法。

背景技术

电信管理网(Telecommunication Management Network，TMN)是国际电联ITU-T借鉴OSI(开放系统互联参考模型)系统管理(ITU-U X.700/ISO 7498-4)的概念，并在电信领域的应用中有所发展的一项技术。它使得网络管理系统与电信网在标准的体系结构下，按照标准的接口和标准的信息格式交换管理信息，从而实现网络管理功能。TMN基本原理之一就是使管理功能与电信功能分离，网络管理者可以从优先的几个管理节点管理电信网络中分布的电信设备。

在电信系统的网络管理中，一个网管系统往往要管理上千个网元(Network E1ement，NE)，对于每类网元通常采用面向对象的分析技术被抽象为信息模型(Information Model)进行管理、以及抽象成显示模型进行界面显示。对于同类但不同版本的网元也进行抽象成不同的信息模型和显示模型进行管理，也就是说，把不同版本的网元认为是不同类网元进行管理。网管系统对网元的管理对象(Managed Object，MO)的处理逻辑(配置操作)是针对其对应的该网元信息模型的MOI/MOC(管理对象实例/类，一种唯一确定该管理对象实例和类型的标识方式)进行处理。

由于一个网元的管理对象少则几十个多则上千个，当对另一个同类但版本不同的网元进行管理时，由于使用这个网元的同一套MOI/MOC时无法在代码中区分其相同MOI/MOC不同版本的处理逻辑，因此必须使用不同套的MOI/MOC，而在实现中维护MOI/MOC对应其处理逻辑是一件非常繁重的工作，这种网管系统维护的工作量和出现的故障的机率与所管理的网元类型(包括多版本)数量成正比。

可见，由于管理对象的处理逻辑是通过MOI/MOC进行实现，因此该处理逻辑不具有通用性，当增加另一个版本网元时不仅需要再次添加新的处理逻辑，还需要对已有的相同处理逻辑与MOI/MOC进行维护匹配。由于这种实现是嵌在网管系统框架内，因此影响了整个网管系统的扩展性和可维护性；当存在多个版本网元需要管理时，整个网管系统会变得臃肿，维护的工作量大大增加。

发明内容

本发明提供一种方法，实现对多版本网元进行有效的、动态的管理。

为此，本发明采用如下技术方案：

一种多版本网元的网络管理方法，该方法包括步骤：将各版本网元信息模型以版本链形式保存于服务器端；客户端从服务器端加载网元对应的信息模型，并加载所述信息模型中管理对象对应的处理逻辑，将所述处理逻辑下发给所述网元。

优选地，所述方法还包括步骤：设置各管理对象对应的处理逻辑之间的关联操作关系，在加载处理逻辑的同时执行关联操作。

通过以下步骤实现设置关联操作关系：依照管理对象的父管理对象和子管理对象，确定处理逻辑的父处理逻辑和子处理逻辑。

以服务器端的管理信息树作为执行关联操作的参考点；执行关联操作的过程为：将管理对象修改到管理信息树之前，加载处理逻辑预操作，并确保存在父管理对象；将管理对象修改到管理信息树；加载处理逻辑提交后操作，并确保存在子管理对象。

所述方法还包括，创建处理逻辑集合，所述集合中保存有网元信息模型管理对象对应的处理逻辑；多版本网元信息模型可以指定客户端加载所述集合中相同处理逻辑；并将所述处理逻辑集合保存在服务器端。

各版本网元信息模型以版本链存放，是以某一类网元为一个逻辑载体，在该载体中，按照网元版本划分区域，在每个区域中存放各版本网元信息模型。

客户端从服务器端加载网元对应的信息模型的时机是，每次对网元下发管理命令之前。

保存各版本网元信息模型的同时，记录各信息模型制作的时间戳。

在记录各信息模型制作的时间戳的情况下，客户端从服务器端加载网元对应的信息模型的时机是，客户端第一次启动；并在客户端第一次启动时将信息模型保存到本地；在对网元下发管理命令之前，将本地保存的信息模型时间戳与服务器端信息模型时间戳进行比对，若一致，采用本地信息模型；若不一致，从服务器端重新加载信息模型。

对于上述技术方案的技术效果分析如下：

本发明不同于现有技术中不同版本网元采用不同MOI/MOC管理的方式，而是采用相同的MOI/MOC，通过信息模型指示去动态加载其所对应的处理逻辑，处理逻辑不再与信息模型相挂钩，对于版本不同但处理逻辑相同的网元，只需要加载已有的处理逻辑即可。可见，通过分离信息模型与网元管理对象处理逻辑，提升了网管系统的扩展性和可维护性。由于分离的处理逻辑可供不同版本网元进行动态加载，使不同版本的网元处理逻辑利用率最大化，降低了网元维护管理成本。

附图说明

图1为网络管理系统示意图；

图2为实施例一流程图；

图3为网元版本链结构示意图；

图4为信息模型指示加载处理逻辑示意图；

图5为实施例二各管理对象关系示意图；

图6为实施例二触发器关联操作示意图。

具体实施方式

本发明核心思想是把各版本网元的信息模型与处理逻辑分离，通过信息模型的指示去动态加载处理逻辑。这种方式不但非常有效地进行多版本网元的管理，并且也大幅度提升网管系统自身的可扩展性和可维护性。

下面介绍实施例一：

TMN是一个逻辑上与电信网分离的网络，它通过标准的接口以及通信协议和信息模型，与电信网进行传送/接收管理信息，从而达到对电信网控制和操作的目的。TMN可以从四个方面分别进行描述，即功能体系结构、物理体系结构、逻辑分层体系结构和信息体系结构。本发明对TMN进行改进，从而实现管理多版本网元。下面将着重从物理体系结构和信息体系结构两方面对本发明的实现进行阐述。

本发明的网络管理系统的物理体系结构由物理实体组成，物理实体是指客观存在的计算机软、硬件系统，物理实体之间采用互相支持的标准接口通讯。本发明基本的物理实体包括操作系统(Operating System，OS)、工作站(Work Station，WS)、数据通信网(Digital Communication Network，DCN)和网元，他们之间的接口为标准的Q3接口、F接口或X接口，如图1所示，对图中各物理实体以及Q3接口介绍如下：

①操作系统(OS)：对电信网进行监控、协调和控制的功能实体，通常由一组计算机组成；本发明中OS功能由服务器端实现；

②工作站(WS)：外接管理客户端，用户操作平台；

③数据通信网(DCN)：为各物理实体间提供传输链路的网络；

④网元(NE)：被管电信网中一些电信设备或一些支撑设备；

⑤Q3接口：支持OS与NE互联互通和互操作的标准接口，它向OS输入的信息模型是统一和标准化的。

在网络管理的信息体系结构中，采用面向对象的分析技术，建立了用于表达实际网元的抽象的信息模型，而所有被管资源被抽象为被管对象(MO)，也可以说信息模型是管理对象的数据的组织方式。

如图2所示，实现实施例一的流程包括：

步骤201：将信息模型和显示模型存放在服务器端，并且将同类但不同版本网元的信息模型和显示模型以版本链的形式存放，对于不同版本的信息模型和显示模型采用同一套MOI/MOC；

如图3所示，信息模型/显示模型以版本链存放是以某一类网元为一个逻辑载体，在该载体中，按照该网元的版本划分区域，在每个区域中存放各版本网元的信息模型/显示模型。还可以记录该信息模型/显示模型制作的时间戳，所谓时间戳是指该信息模型/显示模型的制作时间，通过时间戳，能够区分各版本网元的信息模型和显示模型。若没有记录时间戳的情况下，可在每个区域上增加区域标识、或在每个信息模型/显示模型上增加版本标识来区分各版本模型。

网管系统根据所管理网元类型以及其版本号从版本链中获取对应的信息模型和显示模型，所有与其相关的业务逻辑的实现通过信息模型和显示模型中指定的信息动态加载。

步骤202：在网管系统中单独创建存储网元被管对象的处理逻辑集合，保证其与网元信息模型/显示模型的互相独立；

其中，只要保证网元被管对象处理逻辑集合与网元信息模型/显示模型在逻辑上相互独立就能满足本发明的要求，所以处理逻辑集合可以被保存在服务器端，也可以被保存在服务器端之外的区域，但是要保证随着网络管理系统业务管理情况的变化而更新。

步骤203：客户端动态加载信息模型/显示模型；

当客户端第一次启动时向服务器端加载其所管理网元的信息模型和显示模型，并且保存到本地，下次启动时，从本地读取信息模型和显示模型并且根据各个模型中的时间戳与服务器端该模型的时间戳比对，如果不一致，则从服务器端加载该模型替换原有保存的。这样既能保证客户端加载的效率，又能保证网管系统对网元管理的变化与客户端的无关性。而且，由于信息模型/显示模型是保存在服务器端的，每次客户端启动时向服务器端获取模型数据，因此当网元处理逻辑发生变化时，只需要更改服务器端的模型数据，而客户端无需做任何改动。由于在现行的网管系统中客户端的数量往往有众多，采用这种方式后会大大降低维护客户端处理逻辑变化的工作量。

除了上述描述的在客户端第一次启动时加载并保存、以后比对时间戳来加载信息模型/显示模型的方式外，也可以在每次对网元发起管理命令时，都从服务器端加载信息模型/显示模型，采用这种实时加载的方式能够确保加载的是服务器端最新更新的模型，所以就不需要通过比对时间戳来确定信息模型/显示模型的更新情况。

步骤204：客户端动态加载信息模型指定的处理逻辑，并下发给网元。

如4所示，为信息模型指示加载处理逻辑示意图。图中存在两个版本的网元信息模型，版本一的信息模型包括管理对象A、管理对象B、管理对象C和管理对象D1的逻辑关系；而版本二的信息模型包括管理对象A、管理对象B、管理对象C和管理对象D2的逻辑关系；那么在实际操作中，对版本一网元进行管理时，会根据版本一信息模型的指示去处理逻辑集合中加载管理对象A、B、C和D1的处理逻辑；对版本二网元进行管理时，会根据版本二信息模型的指示去处理逻辑集合中加载管理对象A、B、C和D2的处理逻辑。

可见，版本一和版本二中都需要执行管理对象A、B和C的处理逻辑，若采用现有技术中的信息模型MOI/MOC与处理逻辑挂钩的方式，不得不采用两套MOI/MOC分别对应两套处理逻辑组合，那么管理对象A、B和C的处理逻辑虽然重复也不得不分别保存，不能实现共用。而采用步骤204根据信息模型指示动态加载的方式，不但不需要维护两MOI/MOC，而且实现了对重复管理对象处理逻辑(A、B、C)的共用，占用网络网络系统更少的资源，却能实现效率更高的管理。

下面介绍实施例二：

在实施例一的基础上，实施例二对各管理对象处理逻辑(触发器)进行了关联设置，使不同版本网元处理逻辑共用最大化。

具体是，在实施例一步骤202中，预先设置管理对象处理逻辑的调用顺序，而调用顺序的参考点是管理信息树(Management Information Tree，MIT)。MIT是服务器端的数据库，用于保存网管系统的配置数据，在网络管理系统中，不论增加、修改或删除网元被管对象处理逻辑，都会体现到MIT上，而增加或删除都可以看作是对管理对象的修改。那么就利用这一点，在对某一个管理对象修改到MIT之前调用触发器的预操作，修改到MIT之后再调用触发器的提交后操作，每一类管理对象只依赖其父管理对象以及子管理对象，简化处理逻辑，多层的依赖可以按照父子关系进行递归依赖实现。触发器调用都体现到MIT后，把触发生成的所有操作发送至网元。

现假设在管理某网元时，增加了管理对象A，管理对象A在修改到MIT之前依赖管理对象B1，管理对象B1在修改至MIT之前依赖管理对象C1，然后管理对象B1在修改到MIT之后需依赖管理对象C2；管理对象A在修改到MIT之后依赖管理对象B2，管理对象B2在修改至MIT之后依赖管理对象C3。参见图5为管理对象A、B1、C1、C2、B2和C3之间的逻辑关系。依照管理对象的父管理对象和子管理对象，确定处理逻辑的父处理逻辑和子处理逻辑。

那么，如图6，有关增加管理对象A的处理逻辑包括：

(1)管理对象A在修改到MIT之前加载管理对象A触发器预操作；

(2)在管理对象A触发器预操作中检查是否存在管理对象B1，如果不存在则在触发器预操作中创建管理对象B1；

(3)在把管理对象B1修改到MIT之前加载管理对象B1的触发器预操作；

(4)在管理对象B1触发器预操作中检查是否存在管理对象C1，如果不存在则在触发器预操作中创建管理对象C1；

(5)在管理对象B1触发器预操作中把管理对象C1修改到MIT之前加载管理对象C1的触发器预操作；

(6)在管理对象B1触发器预操作中把管理对象C1修改到MIT；

(7)在管理对象B1触发器预操作中把管理对象C1修改到MIT之前加载管理对象C1的触发器提交后操作；

(8)在管理对象B1触发器预操作中调用管理对象C1触发器全部结束后返回至管理对象A触发器预操作中；

(9)在管理对象A触发器预操作中把管理对象B1修改到MIT；

(10)在管理对象A预操作中把管理对象B 1修改至MIT后调用管理对象B1的触发器提交后操作；

(11)在管理对象B1触发器提交后操作中检查是否存在管理对象C2，如果不存在则创建管理对象C2；

(12)在管理对象B1触发器提交后操作中把管理对象C2修改到MIT之前加载管理对象C2的触发器预操作；

(13)在管理对象B1触发器提交后操作中把管理对象C2修改至MIT；

(14)在管理对象B1触发器提交后操作中把管理对象C2修改到MIT之后加载管理对象C2的触发器提交后操作；

(15)把管理对象A修改至MIT后加载管理对象A的触发器提交后操作；

(16)在管理对象A触发器提交后操作中检查是否存在管理对象B2，.......以下类推。

这种方式使关联操作的处理逻辑简单化。比如，在实际网管系统中创建一个通讯小区是一件非常复杂的关联操作，需要输入小区的基本信息，才能够自动创建小区载频、时隙和算法等。当采用上述实施例二这种关联操作时，小区的处理逻辑只需判断是否存在载频，若不存在则创建载频，而载频的处理逻辑只需判断是否存在时隙，如果不存在则创建时隙，以此类推。如果不同版本网元在创建小区的处理逻辑只区别在载频上，那么只需要替换该版本载频处理逻辑即可。

最后，结合实施例一和实施例二，通过一个具体应用对本发明实施流程进行阐述。

假设网络管理系统中存在两个同类不同版本的待管网元，例如RNCv1.0和RNCv1.1，分别记为网元1和网元2；网元1包括管理对象A、B，它们关系为父子；网元2包括管理对象A、B、C，A和B、B和C关系均为父子。那么，对于网元1和网元2的管理包括如下步骤：

步骤1：启动服务器，初始化网元1、网元2的信息模型/显示模型，并以版本链形式保存；两个网元的信息模型/显示模型统一采用相同的MOI/MOC，但标以不同的时间戳信息；

步骤2：初始化处理逻辑集合，此集合包括管理对象A、B和C处理逻辑，而且，预置各处理逻辑之间的关联操作关系；

步骤3：启动客户端，通过DCN从服务器加载网元1和网元2的信息模型/显示模型，并保存到本地；下次启动时检查本地信息模型/显示模型时间戳与服务器时间戳是否一致，如果一致则加载本地模型，否则从服务器加载；

步骤4：客户端接收管理员指示，要求对网元2进行管理；客户端实时从网元2接收配置数据，并通过网元2的信息模型解析配置数据，分析网元2当前状况；

步骤5：通过步骤4的分析结果，判断出需要对网元2增加管理对象B；那么，客户端根据网元2信息模型指示，从处理逻辑集合加载管理对象B的处理逻辑；而管理对象B的处理逻辑与管理对象A、C具有关联操作，则需要按照关联操作，完成增加管理对象B的任务；

步骤6：客户端将有关增加管理对象B涉及的处理逻辑信息，通过DCN发送给网元2，对其进行控制。

在本发明中，除非要向管理员显示网元管理结果时需要构建和加载显示模型，别的情况下仅由信息模型的指示加载处理逻辑，就能实现对各版本网元的管理。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种多版本网元的网络管理方法，其特征在于包括：

将各版本网元信息模型以版本链形式保存于服务器端；

客户端从服务器端加载网元对应的信息模型，并加载所述信息模型中管理对象对应的处理逻辑，将所述处理逻辑下发给所述网元。

2.根据权利要求1所述的多版本网元的网络管理方法，其特征在于还包括：设置各管理对象对应的处理逻辑之间的关联操作关系，在加载处理逻辑的同时执行关联操作。

3.根据权利要求2所述的多版本网元的网络管理方法，其特征在于，通过以下步骤实现设置关联操作关系：

依照管理对象的父管理对象和子管理对象，确定处理逻辑的父处理逻辑和子处理逻辑。

4.根据权利要求3所述的多版本网元的网络管理方法，其特征在于，以服务器端的管理信息树作为执行关联操作的参考点，执行关联操作的过程为：

将管理对象修改到管理信息树之前，加载处理逻辑预操作，并确保存在父管理对象；

将管理对象修改到管理信息树；

加载处理逻辑提交后操作，并确保存在子管理对象。

5.根据权利要求1至4中任一项所述的多版本网元的网络管理方法，其特征在于还包括，创建处理逻辑集合，所述集合中保存有网元信息模型管理对象对应的处理逻辑；同类各版本网元信息模型可以指定客户端加载所述集合中相同处理逻辑。

6.根据权利要求5所述的多版本网元的网络管理方法，其特征在于还包括，将所述处理逻辑集合保存在服务器端。

7.根据权利要求1至4中任一项所述的多版本网元的网络管理方法，其特征在于，各版本网元信息模型以版本链存放，是以某一类网元为一个逻辑载体，在该载体中，按照网元版本划分区域，在每个区域中存放各版本网元信息模型。

8.根据权利要求7所述的多版本网元的网络管理方法，其特征在于，客户端从服务器端加载网元对应的信息模型的时机是，每次对网元下发管理命令之前。

9.根据权利要求7所述的多版本网元的网络管理方法，其特征在于，保存各版本网元信息模型的同时，记录各信息模型制作的时间戳。

10.根据权利要求9所述的多版本网元的网络管理方法，其特征在于，

客户端从服务器端加载网元对应的信息模型的时机是，客户端第一次启动；并在客户端第一次启动时将信息模型保存到本地；

在对网元下发管理命令之前，将本地保存的信息模型时间戳与服务器端信息模型时间戳进行比对，若一致，采用本地信息模型；若不一致，从服务器端重新加载信息模型。

Images