CN103139806A - 网管与基站配置数据解耦的方法及基站 - Google Patents

Abstract

本发明涉及一种网管与基站配置数据解耦的方法及基站，其方法包括：基站接收网管下发的对象配置文件；解析对象配置文件，并将对象配置文件中的MO数据转换为表数据。本发明通过网管向基站下发对象配置文件，基站通过MO代理模块将接收的对象配置文件中的MO数据转换为表数据，当基站侧与网管无关的表数据发生变化时，网管无需修改相应的数据，由此实现了部分数据对网管的隐藏，简化了网管配置数据的复杂度，提高了基站网管配置数据版本的稳定性。

Description

网管与基站配置数据解耦的方法及基站

技术领域

本发明涉及移动通信技术领域，尤其涉及一种网管与基站配置数据解耦的方法及基站。

背景技术

在移动通信领域，从2G、3G到4G，无线技术正变得越来越丰富，无线技术的发展催生了网络的融合。基于这种状况，产生了一种无线通信的新的体系结构SDR(Software Defined Radio，软件定义的无线电)，将硬件作为无线通信的平台，通过软件配置来实现多种标准、解调方式、频段支持，把尽可能多的无线通信及个人通信功能通过软件来实现。

对网元级的设备管理，传统通常采用的方法是：网管基于基站数据库表进行配置，当配置发生变化时，在网管上进行整表配置或者增量修改操作，网管根据配置操作的内容生成对应的表数据文件，并发送消息到基站配置管理模块，通知基站配置管理模块获取网管生成的表数据文件。配置管理模块获取到表数据文件后，通知数据库管理系统解析并生效数据。当网管需要从基站反构当前数据时，配置管理模块将当前运行的表数据以文件形式传给网管，网管根据表数据进行显示处理。

随着网络设备内部数据的复杂化，网管需要以更合理的方式为用户提供人性化的操作及界面。但是在传统方式中，网管下发的所有数据均必须直接写入基站数据库表，由此导致前台数据库表的任何改动都会直接波及到网管，如修改字段名字及数据类型、调整字段位置、拆分字节、各种换算等。若基站数据库表改变频繁，网管版本则需跟随基站版本不断更新，甚至基站数据表的一个微小改动，将会导致外场基站版本、LMT(Local Maintenance Terminal，本地维护终端)版本、网管版本的一系列升级，由此降低了外场配置数据版本的稳定性。

发明内容

本发明的主要目的在于提供一种网管与基站配置数据解耦的方法及基站，旨在简化网管与基站数据配置的复杂度，提高基站与网管配置数据版本的稳定性。

为了达到上述目的，本发明提出一种网管与基站配置数据解耦的方法，包括：

基站接收网管下发的对象配置文件；

解析所述对象配置文件，并将所述对象配置文件中的管理对象MO(Managed Object，管理对象)数据转换为表数据。

本发明还提出一种网管与基站配置数据解耦的基站，包括：

接收模块，用于接收网管下发的对象配置文件；

MO代理转换模块，用于解析所述对象配置文件，并将所述对象配置文件中的MO数据转换为表数据。

本发明提出的一种网管与基站配置数据解耦的方法及基站，网管向基站下发对象配置文件，基站通过MO代理模块将接收的对象配置文件中的MO数据转换为表数据，当基站侧与网管无关的表数据发生变化时，网管无需修改相应的数据，由此实现了部分数据对网管的隐藏，简化了网管配置数据的复杂度，提高了基站网管配置数据版本的稳定性。

附图说明

图1是本发明网管与基站配置数据解耦的方法一实施例的流程示意图；

图2a是本发明网管与基站配置数据解耦的方法一实施例中MOM树的一种实例示意图；

图2b是本发明网管与基站配置数据解耦的方法一实施例中MOM树内包容关系示意图；

图2c是本发明网管与基站配置数据解耦的方法一实施例中MOM树内关联关系示意图；

图3是本发明网管与基站配置数据解耦的方法另一实施例的流程示意图；

图4是本发明网管与基站配置数据解耦的基站一实施例的结构示意图；

图5是本发明网管与基站配置数据解耦的基站一实施例中MO代理转换模块的结构示意图；

图6是本发明网管与基站配置数据解耦的基站另一实施例的结构示意图。

为了使本发明的技术方案更加清楚、明了，下面将结合附图作进一步详述。

具体实施方式

本发明实施例解决方案主要是：网管向基站下发对象配置文件，基站通过MO代理模块将接收的对象配置文件中的MO数据转换为表数据，当基站侧与网管无关的表数据发生变化时，网管无需修改相应的数据，由此简化网管配置数据的复杂度，提高基站网管配置数据版本的稳定性。

如图1所示，本发明一实施例提出一种网管与基站配置数据解耦的方法，包括：

步骤S101，基站接收网管下发的对象配置文件；

本实施例是将现有技术的面向表的数据配置通过面向数据抽象的配置来实现。

数据抽象是运用面向对象的设计原理对基站管理资源进行建模，这种抽象的模型称为管理对象模型(MOM，Managed Object Model)，MOM定义了模型化管理资源的方法以及管理者与被管理者之间信息传递的结构。

MOM描述的对象是管理对象(MO)，网管通过对MO的增、删、改、操作来实现对基站的管理。应用面向对象的概念，对于每个要管理的网络资源，均抽象成管理对象MO。MO对资源的抽象能够反映出资源的特性以及对该资源实施管理操作的结果。

一个MO代表了基站中一种可被管理的资源，这些资源可以是物理资源(如单板)或逻辑资源(如软件、协议等)。资源一般都有可供配置的参数、状态、操作，对应的被抽象为MO的属性、状态和动作。

其中，MO具有以下特征：

属性(Attribute)：MO均具有属性，属性都有相关的值，属性的值在MO的范围内可见；属性的值能够决定MO的行为；对属性的操作通过对MO的操作来实现，通过向MO送出读或写请求，可以观察和修改MO的属性值；协议规定不能直接对MO的属性进行直接操作，可以定义MO内部个别属性间的约束条件，对属性值的操作必须满足规定的约束；同时，在定义中声明对MO属性允许的操作，如只读、读写等。

动作(Action)：动作是对MO的操作，常见的动作有：复位、闭塞/解闭塞、主备倒换、状态查询等。

通知(Notification)：通知是在MO内部发生一定事件时，由管理对象发出的信息，常见的通知有：对象创建、对象删除、属性改变、状态改变、告警、通知等。

行为(Behavior)：行为规定了MO与其对应资源、MO之间的作用方式。MO类的行为规定了：属性、操作和通知的语义；MO触发管理操作后的响应；通知发出的环境；个别属性值的依赖关系；对参与的MO间的关系影响；属性的完整性约束；操作和通知有效的前提条件；标识管理操作和通知发出处理结果的条件；MO生命周期内有效的不变因素和描述MO操作条件中的不变因素；MO的同步特性等。

MOM相当于一棵包容树，树节点即为MO，一个典型的MOM树的示例如图2a所示。每个MO具有一个识别名，识别名属性的名称由MO类名+Id组成，如SubRack类中的识别名属性为SubRackId。MO类名称和识别名属性的值组成了相对识别名(RDN)，某个分支上所有MO的RDN合在一起组成了本地识别名(LDN)。

MO类之间有两种基本的关系：包容关系、关联关系。其中：

包容关系可以看作是父子关系，即父MO包含子MO，子MO中具有一个parentLDN属性，该parentLDN即父节点的LDN，对于一个确定的子MO实例而言，有且仅有一个父节点实例。如图2b所示，MO_X是MO_Y的父，一个MO_X实例中可以包含0到2个MO_Y实例。如果MO_X不存在，则不能创建MO_Y，同样，删除MO_X时，如果还有子节点，则此MO_X不能被删除，其中，有一种例外情况是，若删除MO_X时，MO_X的所有子节点都是SystemCreated属性的子节点，则可以删除MO_X，这些SystemCreated属性的子节点会随父节点一起自动删除。

关联关系是一种引用与被引用的关系，一个MO实例可以同时被多个同类或不同类的MO实例引用，也可以同时引用多个其它同类或不同类的MO实例。如图2c所示，MO_X引用到MO_Y，MO_Y被MO_X引用，一个MO_X实例中可以引用0到2个MO_Y实例，一个MO_Y实例可以被0到3个MO_X实例引用。其中，MO_X中的refMO_Y属性，表示引用的MO_Y的LDN，反过来，MO_Y中的reservedByMO_X属性，表示被引用的MO_X的LDN。

本实施例首先在网管端配置对象配置文件，该对象配置文件中包含MO数据，由此，网管向基站前台下发的配置数据由现有的表数据改为MO数据。

步骤S102，解析对象配置文件，并将对象配置文件中的MO数据转换为表数据。

本实施例在基站侧新增一个MO代理转换模块，该MO代理转换模块运行在MGR进程(平台管理进程)中，用来实现MO数据到表数据的转换，具体包括MoAgent、MoSave、MoSync以及DV线程，其中：

MoAgent的功能包括MoTree的维护、MO转表、前后台事物操作流程控制(整表、增量等)；

MoSave的功能包括MO文件的存盘；

MoSync的功能包括MO数据主备板同步；

DV的功能包括数据版本文件的加载和激活。

MO到数据库表、MO属性到数据库表字段转换的信息在MoAgent中注册，MoAgent中构造主、备两棵MoTree，所有的操作在备树上进行，操作成功后，再进行主备树的切换和主备树的同步，这样便于数据异常导致转换失败后的数据回滚。每个MO对象可以通过一个C++类来实现，所有MO对象拥有一个共同的基类MoBase，基类中存储父子关系、引用关系、属性列表等，MO转表由MO对象驱动表生成，即MO对象发生了变化后，遍历MO对象，根据注册信息生成关联的数据库表记录。

网管下发的增量对象配置文件或整表对象配置文件通过MO代理转换模块转换成数据库表记录，具体过程为：基站前台在接收到网管下发的对象配置文件后，通过基站中的MO代理转换模块对接收的对象配置文件进行解析，将对象配置文件中的MO数据转换为表数据。首先，解析出对象配置文件中的每一个MO数据，然后，根据预先配置的MO与表、MO属性与表字段的对应关系，将每一MO数据转换为表数据。

在基站中，预先根据MO数据的属性配置有各MO数据与表数据之间的对应关系。基站中的MO代理转换模块将对象配置文件中MO数据转换为表数据时，在表数据中相应的字段中填写对应的MO数据的属性值或者根据MO数据的属性生成的值。对于表数据中与MO数据的属性无关的字段，则以默认值代替。

转换完成后，通过MO代理转换模块通知基站前台的数据库生效数据，同时，在基站的FLASH上保存一份和表数据匹配的持久化MO数据，网管在接入或者数据反构需要从基站前台同步数据时，基站可以将MO数据传给网管。

通常，基站将配置数据分为三类，网管配置的数据、根据网管配置生成的数据以及基站内部数据，其中，网管配置的数据和根据网管配置生成的数据是数据对象化关心的数据；基站内部数据由基站自身生成，不需要网管配置或MO转换，与网管和MO代理转换模块均不相关。

对于网管配置的数据，网管在配置时，可以抽象为某一MO的一个属性或者多个MO的多个属性。对于根据网管配置生成的数据，由MO代理转换模块，通过配置的MO数据按照前台给定的规则生成，网管不需要配置。

因此，通过上述转换的方式实现了网管和基站配置数据的解耦，当基站表数据发生变化时，如果不牵涉到MO接口数据，网管则不会再被波及，无需对配置数据格式进行修改，从而实现了基站在某些数据上对网管的隐藏，用户只需要关心必须配置的参数即可，由此简化了配置的复杂度。同时，抽象的对象更符合用户的认知习惯，更容易被用户理解。

如图3所示，本发明另一实施例提出一种网管与基站配置数据解耦的方法，在上述实施例的基础上，在上述步骤S101之前还包括：

步骤S100，基站配置MO与表、MO属性与表字段的对应关系。

在上述步骤S102之后还包括：

步骤S103，基站在本地保存与表数据匹配的MO数据。

步骤S104，当网管需要从基站同步数据时，基站将本地保存的MO数据传给网管。

步骤S105，基站接收网管下发的版本更新后的对象配置文件。

本实施例与上述实施例的区别在于，本实施例中，基站在通过MO代理转换模块对接收的对象配置文件进行转换前，还需配置MO与表、MO属性与表字段的对应关系，以便MO代理转换模块可以根据配置的MO与表、MO属性与表字段的对应关系，将每一MO数据转换为表数据。

同时，本实施例中，基站在通过MO代理转换模块完成数据转换后，还在本地保存与表数据匹配的MO数据，以便当网管需要从基站同步数据时，基站将本地保存的MO数据传给网管。

此外，在本实施例中，当基站配置数据中需要网管配置的数据发生变化时，比如MO属性发生变化时，则需要网管对配置数据进行版本更新。其中：网管更新对象配置文件的过程包括：网管在导入对象配置文件时，根据当前配置策略对比从基站获取的对象配置文件，标识出对应的需要修改、删除或增加的MO数据，并根据相应的标识生成版本更新后的对象配置文件。

具体地，网管根据实际情况及基站反馈的数据信息制定配置策略，并根据当前的配置策略，比如需要对之前下发的对象配置文件中的MO属性进行修改，或者需要增加、删除之前下发的对象配置文件中的MO数据，对比之前下发的对象配置文件，标识出对应的需要修改、删除或增加的MO数据，然后根据相应的标识生成版本更新后的对象配置文件。

或者，网管从基站侧获取的对象配置文件中的MO属性需要修改、删除或新增，则标识出对应的需要修改、删除或增加的MO数据，然后根据相应的标识生成版本更新后的对象配置文件。

当网管完成配置数据的版本更新后，将再次生成的对象配置文件下发至基站，基站再次接收网管下发的版本更新后的对象配置文件，并通过MO代理转换模块将对象配置文件中的MO数据转换为表数据。由此，实现了网管对基站配置数据的新增、删除与修改等管理操作，提高了网管工作效率以及网管对基站配置数据管理的有效性。

本实施例通过网管向基站下发对象配置文件，基站通过MO代理模块将接收的对象配置文件中的MO数据转换为表数据，当基站侧与网管无关的表数据发生变化时，网管无需修改相应的数据，由此实现了部分数据对网管的隐藏，简化了网管配置数据的复杂度，提高了基站网管配置数据版本的稳定性；同时实现了网管对基站配置数据的新增、删除与修改等管理操作，提高了网管工作效率以及网管对基站配置数据管理的有效性。

如图4所示，本发明一实施例提出一种网管与基站配置数据解耦的基站，包括：接收模块301以及MO代理转换模块302，其中：

接收模块301，用于接收网管下发的对象配置文件；

MO代理转换模块302，用于解析对象配置文件，并将对象配置文件中的MO数据转换为表数据。

本实施例是将现有技术的面向表的数据配置通过面向数据抽象的配置来实现。

数据抽象是运用面向对象的设计原理对基站管理资源进行建模，这种抽象的模型称为管理对象模型(MOM，Managed Object Model)，MOM定义了模型化管理资源的方法以及管理者与被管理者之间信息传递的结构。

MOM描述的对象是管理对象(MO，Managed Object)，网管通过对MO的增、删、改、操作来实现对基站的管理。应用面向对象的概念，对于每个要管理的网络资源，均抽象成管理对象MO。MO对资源的抽象能够反映出资源的特性以及对该资源实施管理操作的结果。

一个MO代表了基站中一种可被管理的资源，这些资源可以是物理资源(如单板)或逻辑资源(如软件、协议等)。资源一般都有可供配置的参数、状态、操作，对应的被抽象为MO的属性、状态和动作。

其中，MO具有以下特征：

属性(Attribute)：MO均具有属性，属性都有相关的值，属性的值在MO的范围内可见；属性的值能够决定MO的行为；对属性的操作通过对MO的操作来实现，通过向MO送出读或写请求，可以观察和修改MO的属性值；协议规定不能直接对MO的属性进行直接操作，可以定义MO内部个别属性间的约束条件，对属性值的操作必须满足规定的约束；同时，在定义中声明对MO属性允许的操作，如只读、读写等。

动作(Action)：动作是对MO的操作，常见的动作有：复位、闭塞/解闭塞、主备倒换、状态查询等。

通知(Notification)：通知是在MO内部发生一定事件时，由管理对象发出的信息，常见的通知有：对象创建、对象删除、属性改变、状态改变、告警、通知等。

行为(Behavior)：行为规定了MO与其对应资源、MO之间的作用方式。MO类的行为规定了：属性、操作和通知的语义；MO触发管理操作后的响应；通知发出的环境；个别属性值的依赖关系；对参与的MO间的关系影响；属性的完整性约束；操作和通知有效的前提条件；标识管理操作和通知发出处理结果的条件；MO生命周期内有效的不变因素和描述MO操作条件中的不变因素；MO的同步特性等。

MOM相当于一棵包容树，树节点即为MO，一个典型的MOM树的示例如图2a所示。每个MO具有一个识别名，识别名属性的名称由MO类名+Id组成，如SubRack类中的识别名属性为SubRackId。MO类名称和识别名属性的值组成了相对识别名(RDN)，某个分支上所有MO的RDN合在一起组成了本地识别名(LDN)。

MO类之间有两种基本的关系：包容关系、关联关系。其中：

包容关系可以看作是父子关系，即父MO包含子MO，子MO中具有一个parentLDN属性，该parentLDN即父节点的LDN，对于一个确定的子MO实例而言，有且仅有一个父节点实例。如图2b所示，MO_X是MO_Y的父，一个MO_X实例中可以包含0到2个MO_Y实例。如果MO_X不存在，则不能创建MO_Y，同样，删除MO_X时，如果还有子节点，则此MO_X不能被删除，其中，有一种例外情况是，若删除MO_X时，MO_X的所有子节点都是SystemCreated属性的子节点，则可以删除MO_X，这些SystemCreated属性的子节点会随父节点一起自动删除。

关联关系是一种引用与被引用的关系，一个MO实例可以同时被多个同类或不同类的MO实例引用，也可以同时引用多个其它同类或不同类的MO实例。如图2c所示，MO_X引用到MO_Y，MO_Y被MO_X引用，一个MO_X实例中可以引用0到2个MO_Y实例，一个MO_Y实例可以被0到3个MO_X实例引用。其中，MO_X中的refMO_Y属性，表示引用的MO_Y的LDN，反过来，MO_Y中的reservedByMO_X属性，表示被引用的MO_X的LDN。

本实施例首先在网管端配置对象配置文件，该对象配置文件中包含MO数据，由此，网管向基站前台下发的配置数据由现有的表数据改为MO数据。

基站侧通过接收模块301接收网管下发的对象配置文件；并通过MO代理转换模块302解析对象配置文件，将对象配置文件中的MO数据转换为表数据。

本实施例在基站侧新增一个MO代理转换模块302，该MO代理转换模块302运行在MGR进程(平台管理进程)中，用来实现MO数据到表数据的转换，具体包括MoAgent、MoSave、MoSync以及DV线程，其中：

MoAgent的功能包括MoTree的维护、MO转表、前后台事物操作流程控制(整表、增量等)；

MoSave的功能包括MO文件的存盘；

MoSync的功能包括MO数据主备板同步；

DV的功能包括数据版本文件的加载和激活。

MO到数据库表、MO属性到数据库表字段转换的信息在MoAgent中注册，MoAgent中构造主、备两棵MoTree，所有的操作在备树上进行，操作成功后，再进行主备树的切换和主备树的同步，这样便于数据异常导致转换失败后的数据回滚。每个MO对象可以通过一个C++类来实现，所有MO对象拥有一个共同的基类MoBase，基类中存储父子关系、引用关系、属性列表等，MO转表由MO对象驱动表生成，即MO对象发生了变化后，遍历MO对象，根据注册信息生成关联的数据库表记录。

网管下发的增量对象配置文件或整表对象配置文件通过MO代理转换模块302转换成数据库表记录，具体过程为：基站前台在接收到网管下发的对象配置文件后，通过基站中的MO代理转换模块302对接收的对象配置文件进行解析，将对象配置文件中的MO数据转换为表数据。MO代理转换模块302首先解析出对象配置文件中的每一个MO数据，然后，根据预先配置的MO数据与表数据的对应关系，将每一MO数据转换为表数据。

在基站中，预先根据MO数据的属性配置有各MO数据与表数据之间的对应关系。基站中的MO代理转换模块302将对象配置文件中MO数据转换为表数据时，在表数据中相应的字段中填写对应的MO数据的属性值或者根据MO数据的属性生成的值。对于表数据中与MO数据的属性无关的字段，则以默认值代替。

转换完成后，通过MO代理转换模块302通知基站前台的数据库生效数据，同时，在基站的FLASH上保存一份和表数据匹配的持久化MO数据，网管在接入或者数据反构需要从基站前台同步数据时，基站可以将MO数据传给网管。

通常，基站将配置数据分为三类，网管配置的数据、根据网管配置生成的数据以及基站内部数据，其中，网管配置的数据和根据网管配置生成的数据是数据对象化关心的数据；基站内部数据由基站自身生成，不需要网管配置或MO转换，与网管和MO代理转换模块302均不相关。

对于网管配置的数据，网管在配置时，可以抽象为某一MO的一个属性或者多个MO的多个属性。对于根据网管配置生成的数据，由MO代理转换模块，通过配置的MO数据按照前台给定的规则生成，网管不需要配置。

因此，通过上述转换的方式实现了网管和基站配置数据的解耦，当基站表数据发生变化时，如果不牵涉到MO接口数据，网管则不会再被波及，无需对配置数据格式进行修改，从而实现了基站在某些数据上对网管的隐藏，用户只需要关心必须配置的参数即可，由此简化了配置的复杂度。同时，抽象的对象更符合用户的认知习惯，更容易被用户理解。

具体实施过程中，如图5所示，上述MO代理转换模块302包括：解析单元3021以及转换单元3022，其中：

解析单元3021，用于解析出对象配置文件中的每一个MO数据；

转换单元3022，用于根据预先配置的MO与表、MO属性与表字段的对应关系，将每一MO数据转换为表数据。

在转换时，转换单元3022根据预先配置的MO与表、MO属性与表字段的对应关系，在表数据中相应的表字段内填写对应的MO数据的属性值或者根据MO数据的属性生成的值。对于表数据中与MO数据的属性无关的字段，则以默认值代替。

如图6所示，本发明另一实施例提出一种网管与基站配置数据解耦的基站，在上述实施例的基础上，还包括：

配置模块300，用于配置MO与表、MO属性与表字段的对应关系。

存储模块303，用于在本地保存与表数据匹配的MO数据。

发送模块304，用于当网管需要从基站同步数据时，将存储模块保存的MO数据传给所述网管。

本实施例中，上述接收模块301还用于接收网管下发的版本更新后的对象配置文件。

本实施例与上述实施例的区别在于，本实施例中，基站在通过MO代理转换模块302对接收的对象配置文件进行转换前，还需通过配置模块300配置MO与表、MO属性与表字段的对应关系，以便MO代理转换模块302可以根据配置的MO与表、MO属性与表字段的对应关系，将每一MO数据转换为表数据。

同时，本实施例中，基站在通过MO代理转换模块302完成数据转换后，还通过存储模块303在本地保存与表数据匹配的MO数据，以便当网管需要从基站同步数据时，基站将本地保存的MO数据通过304传给网管。

此外，在本实施例中，当基站配置数据中需要网管配置的数据发生变化时，比如MO属性值发生变化时，则需要网管对配置数据进行版本更新。其中：网管更新对象配置文件的过程包括：网管在导入对象配置文件时，根据当前配置策略对比从基站获取的对象配置文件，标识出对应的需要修改、删除或增加的MO数据，并根据相应的标识生成版本更新后的对象配置文件。

具体地，网管根据实际情况及基站反馈的数据信息制定配置策略，并根据当前的配置策略，比如需要对之前下发的对象配置文件中的MO属性进行修改，或者需要增加、删除之前下发的对象配置文件中的MO数据，对比之前下发的对象配置文件，标识出对应的需要修改、删除或增加的MO数据，然后根据相应的标识生成版本更新后的对象配置文件。

或者，网管从基站侧获取的对象配置文件中的MO属性需要修改、删除或新增，则标识出对应的需要修改、删除或增加的MO数据，然后根据相应的标识生成版本更新后的对象配置文件。

当网管完成配置数据的版本更新后，再次生成对象配置文件下发至基站，基站接收模块301再次接收网管下发的版本更新后的对象配置文件，并通过MO代理转换模块302将对象配置文件中的MO数据转换为表数据。由此，实现了网管对基站配置数据的新增、删除与修改等管理操作，提高了网管工作效率以及网管对基站配置数据管理的有效性。

本发明实施例网管与基站配置数据解耦的方法及基站，网管向基站下发对象配置文件，基站通过MO代理模块将接收的对象配置文件中的MO数据转换为表数据，当基站侧与网管无关的表数据发生变化时，网管无需修改相应的数据，由此实现了部分数据对网管的隐藏，简化了网管配置数据的复杂度，提高了基站网管配置数据版本的稳定性。同时实现了网管对基站配置数据的新增、删除与修改等管理操作，提高了网管工作效率以及网管对基站配置数据管理的有效性。

以上所述仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (15)

1.一种网管与基站配置数据解耦的方法，其特征在于，包括：

基站接收网管下发的对象配置文件；

解析所述对象配置文件，并将所述对象配置文件中的管理对象MO数据转换为表数据。

2.根据权利要求1所述的方法，其特征在于，所述解析所述对象配置文件，并将所述对象配置文件中的MO数据转换为表数据的步骤包括：

解析出所述对象配置文件中的每一个MO数据；

根据预先配置的MO与表、MO属性与表字段的对应关系，将每一所述MO数据转换为表数据。

3.根据权利要求2所述的方法，其特征在于，所述根据预先配置的MO与表、MO属性与表字段的对应关系，将每一所述MO数据转换为表数据的步骤包括：

根据预先配置的MO与表、MO属性与表字段的对应关系，在表数据中相应的表字段内填写对应的MO数据的属性值或者根据MO数据的属性生成的值。

4.根据权利要求1所述的方法，其特征在于，所述基站解析所述对象配置文件，并将所述对象配置文件中的MO数据转换为表数据的步骤之后还包括：

所述基站在本地保存与所述表数据匹配的MO数据。

5.根据权利要求4所述的方法，其特征在于，所述基站在本地保存与所述表数据匹配的MO数据的步骤之后还包括：

当所述网管需要从基站同步数据时，所述基站将本地保存的所述MO数据传给所述网管。

6.根据权利要求1-5中任一项所述的方法，其特征在于，所述基站解析所述对象配置文件，并将所述对象配置文件中的MO数据转换为表数据的步骤之后还包括：

所述基站接收所述网管下发的版本更新后的对象配置文件。

7.根据权利要求6所述的方法，其特征在于，所述网管更新对象配置文件的过程包括：

网管在导入对象配置文件时，根据当前配置策略对比从基站获取的对象配置文件，标识出对应的需要修改、删除或增加的MO数据，并根据相应的标识生成版本更新后的对象配置文件。

8.根据权利要求6所述的方法，其特征在于，还包括：

所述基站配置所述MO与表、MO属性与表字段的对应关系。

9.一种网管与基站配置数据解耦的基站，其特征在于，包括：

接收模块，用于接收网管下发的对象配置文件；

MO代理转换模块，用于解析所述对象配置文件，并将所述对象配置文件中的MO数据转换为表数据。

10.根据权利要求9所述的基站，其特征在于，所述MO代理转换模块包括：

解析单元，用于解析出所述对象配置文件中的每一个MO数据；

转换单元，用于根据预先配置的MO与表、MO属性与表字段的对应关系，将每一所述MO数据转换为表数据。

11.根据权利要求10所述的基站，其特征在于，所述转换单元还用于根据预先配置的MO与表、MO属性与表字段的对应关系，在表数据中相应的表字段内填写对应的MO数据的属性值或者根据MO数据的属性生成的值。

12.根据权利要求9所述的基站，其特征在于，所述基站还包括：

存储模块，用于在本地保存与所述表数据匹配的MO数据。

发送模块，用于当所述网管需要从基站同步数据时，将所述存储模块保存的所述MO数据传给所述网管。

13.根据权利要求9-12中任一项所述的基站，其特征在于，所述接收模块还用于接收所述网管下发的版本更新后的对象配置文件。

14.根据权利要求13所述的基站，其特征在于，所述网管更新对象配置文件的过程包括：网管在导入对象配置文件时，根据当前配置策略对比从基站获取的对象配置文件，标识出对应的需要修改、删除或增加的MO数据，并根据相应的标识生成版本更新后的对象配置文件。

15.根据权利要求13所述的基站，其特征在于，所述基站还包括：

配置模块，用于配置所述MO与表、MO属性与表字段的对应关系。

Images