CN102857954B - 传输配置数据的处理方法及装置 - Google Patents

Abstract

本发明提供了一种传输配置数据的处理方法及装置，上述方法中，从LMT网管配置系统中抽象出传输配置数据的各个对象；根据Iub口协议栈层次结构分层并封装各个对象；根据预定传输承载方式获取分层后的对象之间的关联关系。根据本发明提供的技术方案，可以基于Iub口协议栈层次结构来直观地展示网管LMT的传输配置数据，节省运营维护成本。

Description

传输配置数据的处理方法及装置

技术领域

本发明涉及通信领域，具体而言，涉及一种传输配置数据的处理方法及装置。

背景技术

随着无线通讯网管技术的日趋成熟，设备运营商在对于升级，管理基站的这一必要的工具网管软件的技术要求已经越来越完善，这不仅仅体现在网管对于数据和信令的处理速度上，对于操作基站的命令的完备性上，用户已经越来越注重网管对于所管理的数据是否能很好的直观抽象，是否可以大大减小运维的人力维护成本，以及是否能够满足越来越被看重的用户体验满意度。

基站网管技术的趋势是，为了实现基站侧数据和网管侧数据的解耦，已经由基于表格形式的高耦合性的数据管理方式演变为基于对象化形式的数据拓扑展现方式。

传输数据模型是基站网管本地维护终端(Local Maintenance Terminal，简称为LMT)的一个重要组成部分，主要展示传输数据的配置方式和依赖关系，当传输数据层发生告警时，需要即时展示其上的告警信息，并且实时提供各个传输数据对象的状态信息。

在本发明对传输数据的抽象之前，业内的主要基站网管软件以及本基站网管软件LMT对于传输数据的管理，是基于表格形式的数据管理方式，每一类传输数据抽象为一张表格，具体传输数据以表记录的形式存在，在LMT中所有传输表格使用树形结构如图1所示，无法体现传输层数据的各层次结构，虽然数据代表着第三代合作伙伴计划(3rd GenerationPartnership Project，简称为3GPP)协议的某些信元，但是无法抽象出协议的层次结构，由于数据之间的依赖关系很复杂，具体可以参见图2，不是一对一的结构，使得运维无法找出数据之间的层次依赖关系，一旦底层传输链路出现故障，由于传输数据展示的不直观，使得运营维护成本非常高。另外由于受限于这种数据的最小单元是表记录的展现方式，使得对应到告警的显示以及状态则需要点击记录后才能获得，用户体验也不好。

发明内容

针对相关技术中传输配置数据展示的不直观，使得运营维护成本非常高的问题，本发明提供了一种传输配置数据的处理方法及装置，以解决上述问题至少之一。

根据本发明的一个方面，提供了一种传输配置数据的处理方法。

根据本发明的传输配置数据的处理方法包括：从本地维护终端LMT网管配置系统中抽象出传输配置数据的各个对象；根据Iub口协议栈层次结构分层并封装各个对象；根据预定传输承载方式获取分层后的对象之间的关联关系。

上述从LMT网管配置中抽象出传输配置数据的各个对象包括：建立LMT网管配置系统与基站之间的通信链路；LMT网管配置系统从基站获取传输配置数据；获取传输层配置数据的各个对象的实例。

上述根据Iub口协议栈层次结构分层并封装各个对象包括：建立对象与Iub口协议栈的信令的对应关系；将对象分别填充到与其对应的信令的Iub口协议栈中预定个数的传输协议块中。

上述根据预定传输承载方式获取分层后的对象之间的关联关系包括：获取根据Iub口协议栈层次结构分层后的对象；根据互联网协议IP传输承载方式获取分层后的对象之间的关联关系。

上述根据预定传输承载方式获取分层后的对象之间的关联关系包括：获取根据Iub口协议栈层次结构分层后的对象；根据异步传输方式ATM传输承载方式获取分层后的对象之间的关联关系。

在根据预定传输承载方式获取分层后的对象之间的关联关系之后，还包括：获取各个对象的告警信息；对各个对象对应的最高等级告警增加标识信息。

在根据预定传输承载方式获取分层后的对象之间的关联关系之后，还包括：获取传输协议块中各个对象的状态信息；判断是否存在故障的对象；对存在故障的对象增加故障指示信息。

根据本发明的另一方面，提供了一种传输配置数据的处理装置。

根据本发明的传输配置数据的处理装置包括：抽象模块，用于从本地维护终端LMT网管配置系统中抽象出传输配置数据的各个对象；分层封装模块，用于根据Iub口协议栈层次结构分层并封装各个对象；第一获取模块，用于根据预定传输承载方式获取分层后的对象之间的关联关系。

上述抽象模块包括：第一建立单元，用于建立LMT网管配置系统与基站之间的通信链路；第一获取单元，用于使LMT网管配置系统从基站获取传输配置数据；第二获取单元，用于获取传输层配置数据的各个对象的实例。

上述分层封装模块包括：第二建立单元，用于建立对象与Iub口协议栈的信令的对应关系；填充单元，用于将对象分别填充到与其对应的信令的Iub口协议栈中预定个数的传输协议块中。

上述第一获取模块包括：第三获取单元，用于获取根据Iub口协议栈层次结构分层后的对象；第四获取单元，用于根据互联网协议IP传输承载方式或者异步传输方式ATM传输承载方式获取分层后的对象之间的关联关系。

上述装置还包括：第二获取模块，用于获取各个对象的告警信息；第一处理模块，用于对各个对象对应的最高等级告警增加标识信息。

上述装置还包括：第三获取模块，用于获取传输协议块中各个对象的状态信息；判断模块，用于判断是否存在故障的对象；第二处理模块，用于对存在故障的对象增加故障指示信息。

通过本发明，基于Iub口协议栈对LMT传输配置数据进行建模，解决了相关技术中传输配置数据展示的不直观，使得运营维护成本非常高的问题，本发明提供了一种传输配置数据的处理方法及装置，进而可以基于Iub口协议栈层次结构来直观地展示网管LMT的传输配置数据，节省运营维护成本。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是传输数据表格化树形展示方式的截屏图；

图2是传输数据表格化展示的关联关系的截屏图；

图3是根据本发明实施例的传输配置数据的处理方法的流程图；

图4是3GPP的Iub口协议栈的示意图；

图5是3GPP的Iub口的逻辑示意图；

图6是根据本发明优选实施例的传输数据对象化后抽象类图；

图7是根据本发明优选实施例的IP承载方式的关联图；

图8是根据本发明优选实施例的异步传输方式(Asynchronous Transfer Mode，简称为ATM)的承载方式的关联图；

图9是根据本发明优选实施例的保存MO对象属性信息的Excel模板文件的示意图；

图10是根据本发明优选实施例的Excel格式MO对象模板文件导入并下发到基站的流程图；

图11是根据本发明优选实施例的LMT对象化展示的传输MO对象显示的拓扑图；

图12是根据本发明优选实施例的传输MO对象告警显示的拓扑图；

图13是根据本发明优选实施例的传输MO对象状态显示的拓扑图；

图14是根据本发明优选实施例的LMT传输数据对象化展现全界面布局的示意图；

图15是根据本发明实施例的传输配置数据的处理装置的结构框图；

图16是根据本发明优选实施例的传输配置数据的处理装置的结构框图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

图3是根据本发明实施例的传输配置数据的处理方法的流程图。如图3所示，该传输配置数据的处理方法主要包括以下处理：

步骤S302：从LMT网管配置系统中抽象出传输配置数据的各个对象；

步骤S304：根据Iub口协议栈层次结构分层并封装各个对象；

步骤S306：根据预定传输承载方式获取分层后的对象之间的关联关系。

相关技术中，网管软件LMT对于传输配置数据的管理，主要是基于表格形式的数据管理方式，对于该管理方式，无法抽象出协议的层次结构，而且数据之间的依赖关系很复杂，不是一对一的结构，使得运维无法找出数据之间的层次依赖关系，一旦底层传输链路出现故障，由于传输数据展示的不直观，使得运营维护成本非常高。采用图3所示的传输配置数据的处理方法，基于I ub口协议栈对LMT传输配置数据进行建模，可以使得传输数据的层次结构和依赖关系(即上述关联关系)能够得以清晰地展现，进而可以直观地展示网管LMT的传输配置数据，节省运营维护成本。

优选地，上述步骤S302可以进一步包括以下处理：

(1)建立LMT网管配置系统与基站之间的通信链路；

(2)LMT网管配置系统从基站获取传输配置数据；

(3)获取传输层配置数据的各个对象的实例。

已知NodeB和RNC是两个独立的网元，连接他们的接口就是Iub口。无线接入网网元在功能上一般分为无线网络(层)和传输网络(层)两部分，所谓的传输配置数据就是在Iub接口中传送无线网络层和传输网络层的信令和用户信息。

3GPP把NodeB的Iub口上传递的信息，在垂直方向划分成了3个“逻辑平面”：无线网络控制面，传输网络控制面，用户面，具体可以参见图4。

从3GPP的Iub口协议栈可以看到，无线网络控制面(Radio Network ControlPlane)分为两部分：

第一部分，属于无线网络层(Radio Network Layer)，是“NodeB应用部分(NodeBApplication Part)”，这部分所遵循的协议，就是“NBAP”协议。

第二部分，属于传输层(Transport Layer)，毕竟NodeB和RNC各自独立需要传输网络来承载待交换的信息，这部分传输层的作用就是承载NBAP协议信息，保障RNC和NodeB顺利的完成NBAP交流。

也就是说，LMT的传输数据层就是为NBAP信令提供承载，这部分传输配置数据对象的配置是事先NodeB和RNC约定好的，各自通过各自的网管软件来配置相应的参数。

协议栈按照其中的信元进一步抽象为3GPP的Iub口逻辑面的层次结构，即LMT的传输数据层的建模模型的原型如图5所示，基于此协议栈模型LMT对其传输数据的拓扑展示做了进一步的抽象。

在优选实施过程中，为了基于Iub口协议栈对LMT传输配置数据进行建模，需要首先把网管管理的传输数据抽象为各个对象(以下称为MO对象)，建立出LMT的传输数据的MO对象模型，传输资源MO以TransportNetwork为根节点，按照基站与上级网元RNC/BSC之间的Iub和Abis接口传输协议栈进行建模(LTE中是基站与CN的对接)，从物理层到应用层依次将以太网口、E1\T1口、互联网协议(Internet Protocol，简称为IP)、异步传输方式(Asynchronous Transfer Mode，简称为ATM)、NBAP、BTSM等资源抽象出来，传输数据对象化后的设计如图6所示。

在优选实施过程中，在LMT传输对象化设计以后，可以按照原来的LMT传输表数据解耦合的设计，提取出如图6的20个传输类对象，每个类的设计定义出了这个类的基本属性(例如，传输链路号，端口号等等的基本信息)，其中，各个传输类之间由于协议层次关系，也存在的一定的关联关系，例如，高层链路的MO必须依赖于底层链路的MO而存在，由此参照实际传输配置中的真实场景，提取出两种传输承载方式——IP传输承载方式如图7和ATM传输承载方式如图8，接下来采用已经设计好的MO属性模型和依赖关系生成需要的可以下发到前台基站去的一整套相互依赖的MO传输数据对象。

之后可以将设计好的20个MO数据以Excel格式的文件保存，每个页面存储一个传输数据对象如图9所示，每个页面中定义了这个MO对象的基本属性，基本属性的取值范围，值的类型等等，此外，还包括了这个MO对象所依赖的MO对象的属性值，以便可以依此找到其关联的MO对象，之后执行Excel格式MO对象模板文件导入并下发到基站的流程，以下结合图10进一步描述该流程。

如图10所示，该流程可以包括以下处理：

步骤S1002：导入excel格式的对象文件；

步骤S1004：编辑文件，写入MO对象的属性字段的数值；

步骤S1006：生成MO对象之间的关联关系；

步骤S1008：检测MO属性值的合法性，即判断MO属性值是否符合数据范围；

步骤S1010：按照业务需要的约束关系检查Mo的配置约束关系；

步骤S1012：比较相邻的两次配置之间的数据对象的异同，以判断是否有必要用数据的增量同步或者是全同步的方式下发到基站；

步骤S1014：转为基站可以识别的XML模板文件，下发到基站。

按此下发数据的方式，运维和用户可以通过仅仅修改excel配置文件，只用填写传输对象的属性值和其关联的传输对象的属性值即能完成传输数据的下发基站配置，完全不需要关心数据的依赖关系的具体细节。

按照以上方式，LMT传输数据可以通过更改excel文件并导入来最终更改下发的基站的数据配置，数据的修改非常灵活。但是仅仅更改数据灵活对于运维来说是不够的，传输数据涉及到非常多的Iub协议的细节，这些细节运维人员可能是不需要关心的，这就需要一个直观有层次的展现方式，可以使得运维人员不用关心协议的具体细节，就可以看到LMT传输数据的层次依赖关系，这样才可以从根本上提高运维人员的维护效率，因此需要关联LMT传输数据的展示图，从Iub协议栈逻辑图中抽象出来。

优选地，上述步骤S304可以进一步包括以下处理：

(1)建立对象与Iub口协议栈的信令的对应关系；

(2)将对象分别填充到与其对应的信令的Iub口协议栈中预定个数的传输协议块中。

在优选实施过程中，按照3GPP的Iub口协议，分类已经设计好的20个MO传输对象，可以把传输拓扑图分成预定个数的协议块(例如，11个)：

(1)Physical Layer：等同于Iub协议逻辑图的物理层，用于填充物理层对象，包括IP端口以及ATM端口。

(2)ATM Link：等同于Iub协议逻辑图ATM承载中的ATM层，填充AtmLayerLink对象。

(3)Ethernet/PPP Link：等同于Iub协议逻辑图Data Link层，填充数据链路对象，包括Ethernet、HDLC以及PPP。

(4)IP：等同于Iub协议逻辑图IP层，填充IP对象。

(5)SCTP：等同于Iub协议逻辑图SCTP层，填充SCTP对象。

(6)UDP/RTP：等同于Iub协议逻辑图UDP层，填充UDP/RTP对象。

(7)AAL2：等同于Iub协议逻辑图AAL2层，填充AAL2对象

(8)SaalUni：等同于Iub协议逻辑图AAL5/SSCOP/SSCF-UNI层，填充SaalUni对象。

(9)ALCAP：等同于Iub协议逻辑图ALCAP层，填充ALCAP对象。

(10)NbapCSignalling/NbapDSignalling/BTSM：等同于Iub协议逻辑图NBAP层，填充NBAP对应对象

(11)Iub/Aibs DataStream：等同于Iub协议逻辑图Channels层，填充Iub/AibsDataStream对象。

至此，LMT传输数据的20个MO对象，已经以Iub协议逻辑图为原型建模，填充到了LMT拓扑展示协议栈图的11个协议块中，完成了传输数据的分层设计，生成LMT传输数据拓扑展示的建模效果图如图11所示。

优选地，上述步骤S306可以进一步包括以下处理：

(1)获取根据Iub口协议栈层次结构分层后的对象；

(2)根据IP传输承载方式获取分层后的对象之间的关联关系。

优选地，上述步骤S306还可以进一步包括以下处理：

(1)获取根据Iub口协议栈层次结构分层后的对象；

(2)根据ATM传输承载方式获取分层后的对象之间的关联关系。

需要注意的是，上述预定传输承载方式包括但不限于IP传输承载方式和ATM传输承载方式，当然也可以是其他传输承载方式。

在优选实施过程中，LMT传输数据对象化以后，基于预定传输承载方式(例如，IP传输承载方式和ATM传输承载方式)，可以最终抽象出多种MO对象分层后的关联关系，具体地，IP承载方式关联关系如图7所示，ATM承载方式关联关系如图8所示。

通过上述处理，与网管LMT传输数据现有展现方式相比较，引入了3GPP的Iub口协议栈结构，在此基础上建模，提取抽象了传输数据的协议栈层次模型，这种传输数据的拓扑展现方式使得传输层展现层次清晰，非常直观，一方面这种简明的展现方式降低了运维的维护难度，另一方面这种基于协议栈的传输数据依赖方式，也极大地满足了的用户体验。

优选地，在执行步骤S306之后，还可以包括以下处理：

(1)获取各个对象的告警信息；

(2)对各个对象对应的最高等级告警增加标识信息。

在优选实施过程中，可以提供传输MO对象显示拓扑图告警显示的功能，具体地，获取各个MO对象的告警信息，按最高告警等级增加标识信息(例如，填充颜色)，每个协议块中根据告警视图获取最高级别告警，根据告警级别渲染颜色。如图12所示，ATMLink的最高级别告警为严重告警，渲染为红色(参见图中阴影部分)。

优选地，在执行步骤S306之后，还可以包括以下处理：

(1)获取传输协议块中各个对象的状态信息；

(2)判断是否存在故障的对象；

(3)对存在故障的对象增加故障指示信息。

在优选实施过程中，可以提供传输MO对象显示拓扑图状态显示的功能，获取各个对象的状态，获取是否存在故障的MO对象，如果某协议块的MO对象存在故障，则在该协议块上增加故障指示信息(例如，增加小圆点显示为故障)。如图13所示，ATMLink存在有故障的MO对象，增加黑色小圆点。

通过上述处理，在传输数据对象化抽象后，其上挂告警的展现和对状态展示的支持，这种直观明了的拓扑展现方式使得网管LMT对于传输数据的处理和展示上日趋标准化和专业化。

传输资源全界面视图的示例可以参见图14的描述，图14的左半部分为传输MO对象显示拓扑图，右半部分是具体选择协议块对应的MO对象状态列表，在该列表中可以对选择的单个MO对象进行操作；以及选择协议块对应的MO对象的告警视图。

图15是根据本发明实施例的传输配置数据的处理装置的结构框图。如图15所示，该传输配置数据的处理装置包括：抽象模块10，用于从LMT网管配置系统中抽象出传输配置数据的各个对象；分层封装模块20，用于根据Iub口协议栈层次结构分层并封装各个对象；以及第一获取模块30，用于根据预定传输承载方式获取分层后的对象之间的关联关系。

在图15所示的传输配置数据的处理装置中，抽象模块10、分层封装模块20、以及第一获取模块30相互结合，基于Iub口协议栈对LMT传输配置数据进行建模，可以使得传输数据的层次结构和依赖关系(即上述关联关系)能够得以清晰地展现，进而可以直观地展示网管LMT的传输配置数据，节省运营维护成本。

优选地，如图16所示，上述抽象模块10可以进一步包括：第一建立单元100，用于建立LMT网管配置系统与基站之间的通信链路；第一获取单元102，用于使LMT网管配置系统从基站获取传输配置数据；第二获取单元104，用于获取传输层配置数据的各个对象的实例。

优选地，如图16所示，分层封装模块20可以进一步包括：第二建立单元200，用于建立对象与Iub口协议栈的信令的对应关系；填充单元202，用于将对象分别填充到与其对应的信令的Iub口协议栈中预定个数的传输协议块中。

优选地，如图16所示，第一获取模块30可以进一步包括：第三获取单元300，用于获取根据Iub口协议栈层次结构分层后的对象；第四获取单元302，用于根据IP传输承载方式或者ATM传输承载方式获取分层后的对象之间的关联关系。

优选地，如图16所示，上述传输配置数据的处理装置还可以包括：第二获取模块40，用于获取各个对象的告警信息；第一处理模块50，用于对各个对象对应的最高等级告警增加标识信息。

优选地，如图16所示，上述传输配置数据的处理装置还可以包括：第三获取模块60，用于获取传输协议块中各个对象的状态信息；判断模块70，用于判断是否存在故障的对象；第二处理模块80，用于对存在故障的对象增加故障指示信息。

在优选实施过程中，如图6所示，抽象模块10获取传输配置数据对象化后抽象的MO对象，分层封装模块20按3GPP的Iub口协议层逻辑(如图5所示)分层并封装MO对象，建模生成传输MO对象显示拓扑图(如图11所示)。具体包括以下处理：

(1)获取跟传输业务相关的所有的MO对象；

(2)按协议栈划分上述MO对象，生成传输MO对象显示拓扑图。

例如，按3GPP的Iub口协议，拓扑图分成11个协议块：

(1)Physical Layer：填充物理层对象，包括IP端口以及ATM端口。

(2)ATM Link：填充AtmLayerLink对象。

(3)Ethernet/PPP Link：填充数据链路对象，包括Ethernet、HDLC以及PPP。

(4)IP：填充IP对象。

(5)SCTP：填充SCTP对象。

(6)UDP/RTP：填充UDP/RTP对象。

(7)AAL2：填充AAL2对象。

(8)SaalUni：填充SaalUni对象。

(9)ALCAP：填充ALCAP对象。

(10)NbapCSignalling/NbapDSignalling/BTSM：填充NBAP对应对象

(11)Iub/Aibs DataStream：填充Iub/AibsDataStream对象。

LMT传输数据的20个MO对象，已经以Iub协议逻辑图为原型建模，填充到了LMT拓扑展示协议栈图的11个协议块中，完成了传输数据的分层设计，生成LMT传输数据拓扑展示的建模效果图如图11所示。

之后，第一获取模块30根据预定传输承载方式获取分层后的对象之间的关联关系。具体地，LMT传输数据对象化以后，基于主要的传输承载方式，最终可以抽象出两种MO对象分层后的关联关系，IP传输承载方式关联关系如图7所示，ATM传输承载方式关联关系如图8所示。

在优选实施过程中，可以提供传输MO对象显示拓扑图告警显示的功能，具体地，第二获取模块40获取各个MO对象的告警信息，第一处理模块50按最高告警等级增加标识信息(例如，填充颜色)，每个协议块中根据告警视图获取最高级别告警，根据告警级别渲染颜色。如图12所示，ATMLink的最高级别告警为严重告警，渲染为红色(参见图中阴影部分)。

在优选实施过程中，还可以提供传输MO对象显示拓扑图状态显示的功能，第三获取模块60获取各个对象的状态，判断模块70判断是否存在故障的MO对象，如果某协议块的MO对象存在故障，第二处理模块80在该协议块上增加故障指示信息(例如，增加小圆点显示为故障)。如图13所示，ATMLink存在有故障的MO对象，增加黑色小圆点。

生成的传输资源全界面视图具体参见图14，图14的左半部分为传输MO对象显示拓扑图，右半部分是具体选择协议块对应的MO对象状态列表，在该列表中可以对选择的单个MO对象进行操作；以及选择协议块对应的MO对象的告警视图。

如果某协议块没有存在对应的MO对象，可以将该协议块显示为下陷状，在具体操作中，将鼠标移动到该协议块提示用户未安装。

需要注意的是，上述传输配置数据的处理装置可以设置于LMT网管系统中。

综上所述，借助本发明提供的上述实施例，实现了如下技术效果：(1)传输数据查询结果清楚并直观，进而方便了业务的运营维护。(2)传输数据的展现更加标准和专业，使其在数据展现上更贴近协议栈，使得运维可以不需了解协议的具体细节能够清楚知道传输数据在协议栈中的层次，大大方便了链路故障时运维对于故障的排查。(3)传输数据视图直接展现对象的告警和状态，实现了拓扑图展现的信息最大化。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种传输配置数据的处理方法，其特征在于，包括：

从本地维护终端LMT网管配置系统中抽象出传输配置数据的各个对象；

根据Iub口协议栈层次结构分层并封装所述各个对象；

根据预定传输承载方式获取分层后的对象之间的关联关系；

所述根据预定传输承载方式获取分层后的对象之间的关联关系包括：获取根据所述Iub口协议栈层次结构分层后的对象；根据互联网协议IP传输承载方式获取所述分层后的对象之间的关联关系。

2.根据权利要求1所述的方法，其特征在于，所述从LMT网管配置中抽象出传输配置数据的各个对象包括：

建立所述LMT网管配置系统与基站之间的通信链路；

所述LMT网管配置系统从所述基站获取所述传输配置数据；

获取所述传输层配置数据的所述各个对象的实例。

3.根据权利要求1所述的方法，其特征在于，所述根据Iub口协议栈层次结构分层并封装所述各个对象包括：

建立所述对象与所述Iub口协议栈的信令的对应关系；

将所述对象分别填充到与其对应的信令的所述Iub口协议栈中预定个数的传输协议块中。

4.根据权利要求1所述的方法，其特征在于，所述根据预定传输承载方式获取分层后的对象之间的关联关系包括：

获取根据Iub口协议栈层次结构分层后的对象；

根据异步传输方式ATM传输承载方式获取所述分层后的对象之间的关联关系。

5.根据权利要求1至4中任一项所述的方法，其特征在于，在根据预定传输承载方式获取分层后的对象之间的关联关系之后，还包括：

获取所述各个对象的告警信息；

对所述各个对象对应的最高等级告警增加标识信息。

6.根据权利要求1至4中任一项所述的方法，其特征在于，在根据预定传输承载方式获取分层后的对象之间的关联关系之后，还包括：

获取所述传输协议块中所述各个对象的状态信息；

判断是否存在故障的对象；

对所述存在故障的对象增加故障指示信息。

7.一种传输配置数据的处理装置，其特征在于，包括：

抽象模块，用于从本地维护终端LMT网管配置系统中抽象出传输配置数据的各个对象；

分层封装模块，用于根据Iub口协议栈层次结构分层并封装所述各个对象；

第一获取模块，用于根据预定传输承载方式获取分层后的对象之间的关联关系；

其中，所述第一获取模块包括：第三获取单元，用于获取根据所述Iub口协议栈层次结构分层后的对象；第四获取单元，用于根据互联网协议IP传输承载方式或者异步传输方式ATM传输承载方式获取所述分层后的对象之间的关联关系。

8.根据权利要求7所述的装置，其特征在于，所述抽象模块包括：

第一建立单元，用于建立所述LMT网管配置系统与基站之间的通信链路；

第一获取单元，用于使所述LMT网管配置系统从所述基站获取所述传输配置数据；

第二获取单元，用于获取所述传输层配置数据的所述各个对象的实例。

9.根据权利要求7所述的装置，其特征在于，所述分层封装模块包括：

第二建立单元，用于建立所述对象与所述Iub口协议栈的信令的对应关系；

填充单元，用于将所述对象分别填充到与其对应的信令的所述Iub口协议栈中预定个数的传输协议块中。

10.根据权利要求7至9任一项所述的装置，其特征在于，还包括：

第二获取模块，用于获取所述各个对象的告警信息；

第一处理模块，用于对所述各个对象对应的最高等级告警增加标识信息。

11.根据权利要求7至9任一项所述的装置，其特征在于，还包括：

第三获取模块，用于获取所述传输协议块中所述各个对象的状态信息；

判断模块，用于判断是否存在故障的对象；

第二处理模块，用于对所述存在故障的对象增加故障指示信息。