CN102833100B - 网管与网元的信息交互方法及装置 - Google Patents

Abstract

本申请提供了一种网管与网元的信息交互方法及装置，其中，所述网管与网元的信息交互方法包括：步骤S1，预置命令数据文件和消息结构数据文件；步骤S2，网管发送命令字符串消息到网元；所述命令字符串消息包括命令关键字，输入字段以及对应的字段值；步骤S3，网元根据所述命令字符串消息生成请求消息；具体包括以下子步骤：步骤S4，网元处理所述请求消息，并生成响应消息；具体包括以下子步骤：步骤S5，网元根据所述响应消息生成处理结果字符串；具体包括以下子步骤：步骤S6，网元将所述处理结果字符串返回给网管。本申请可以在命令行网管上增加命令或者对命令参数进行调整时，能够简化程序升级过程，避免设备提供的核心业务发生中断。

Description

网管与网元的信息交互方法及装置

技术领域

本申请涉及无线网络控制的技术领域，特别是涉及一种网管与网元的信息交互方法，以及，一种网管与网元的信息交互装置。

背景技术

通信设备日常运行中，其维护管理通过网管(操作维护中的一种管理站，对设备进行管理和维护)系统来完成。网管台上的操作通过自定义或者标准协议接口下发到网元，从而实现对网元的管理。网管系统根据其操作界面及实现方式可以划分为两种，即图形化网管和命令行网管两种方式。图形化网管就是管理站上运行该设备的客户端程序(B/S架构的网管系统也可以认为属于这一类型，只不过是将客户端程序部署到网管服务器)，网元上运行网管的后端程序，完成对整个网元的管理。命令行网管就是管理站不运行任何客户端程序，也没有网管服务器，仅仅提供标准的Telnet登录，通过在Telnet窗口输入指定的命令来完成对网元的管理(尽管部分命令行网管也提供图形化界面，但其图形化界面仅仅是为了输入方便，没有改变命令行网管实现的本质，因此也认为是命令行网管)。通常的电信设备中，两种管理形式都需要提供，一般情况下，针对Telnet形式的网管，每一条维护命令都需要使用硬编码实现，本申请主要涉及命令行网管的处理方法。

现有技术中，在实现对RNC(无线网络控制器)命令行网管时，主要有两种实现方案，一种是网元对收到的每条命令进行独立编码处理。另外一种是，收到命令行命令后，对于每一条命令单独编码转换为所对应图形化界面操作的消息，即在网元内模拟图形化界面的命令下发过程，并将结果进行修改返回到命令行界面显示。

上述两种方法都存在一个致命的缺陷，就是在命令行网管上增加命令或者对命令参数进行调整时就需要更改网元代码，代码修改后就需要对设备进行软件升级，而由于程序变化带来的升级是非常麻烦的，一般都需要进行设备的重启、切换才能保证升级成功，如此可能导致设备提供的核心业务发生中断，而中断业务又是通信设备所不能容忍的。

因此，本领域技术人员迫切需要解决的一个技术问题在于，用以在命令行网管上增加命令或者对命令参数进行调整时，能够简化程序升级过程，避免设备提供的核心业务发生中断。

发明内容

本申请的目的之一在于，提供一种网管与网元的信息交互方法，用以在命令行网管上增加命令或者对命令参数进行调整时，能够简化程序升级过程，避免设备提供的核心业务发生中断。

相应的，本申请还提供了一种网管与网元的信息交互装置，用以保证上述方法在实际中的应用。

为了解决上述问题，本申请公开了一种网管与网元的信息交互方法，包括：

步骤S1，预置命令数据文件和消息结构数据文件；

步骤S2，网管发送命令字符串消息到网元；所述命令字符串消息包括命令关键字，输入字段以及对应的字段值；

步骤S3，网元根据所述命令字符串消息生成请求消息；具体包括以下子步骤：

子步骤S31，依据所述命令关键字在所述命令数据文件中查找对应的请求消息ID；

子步骤S32，依据所述请求消息ID在所述消息结构数据文件中查找第一消息体长度；

子步骤S33，将所述请求消息ID和第一消息体长度组织为第一消息头；

子步骤S34，将所述输入字段以及对应的字段值组织为第一消息体；

子步骤S35，将所述第一消息头和第一消息体组织为请求消息；

步骤S4，网元处理所述请求消息，并生成响应消息；具体包括以下子步骤：

子步骤S41，依据所述请求消息ID在预置的命令数据文件中查找对应的响应消息ID；

子步骤S42，依据所述响应消息ID在预置的消息结构数据文件中查找获得第二消息体长度；

子步骤S43，将所述响应消息ID和第二消息体长度组织为第二消息头；

子步骤S44，将所述网元处理请求消息的处理结果信息组织为第二消息体；

子步骤S45，将所述第二消息头和第二消息体组织为响应消息；

步骤S5，网元根据所述响应消息生成处理结果字符串；具体包括以下子步骤：

子步骤S51，网元根据所述响应消息ID和第二消息体长度在预置的消息结构数据文件中查找对应的返回内容字段；

子步骤S52，对应所述返回内容字段组织所述处理结果信息，形成处理结果字符串；

步骤S6，网元将所述处理结果字符串返回给网管。

优选地，在所述步骤S4之前，还包括：

网元根据所述请求消息ID分发请求消息。

优选地，所述预置的命令数据文件包括命令关键字、实际输入字段个数、输入字段名称、输入字段值、请求消息ID、响应消息ID。

优选地，所述预置的消息结构数据文件包括请求消息ID、响应消息ID、结构体叶子成员个数、结构体叶子成员占用内存大小、结构体叶子节点的偏移、回显标签、缺省取值、友好名。

优选地，所述请求消息中还包括消息序列号。

优选地，所述响应消息中还包括消息序列号。

本申请实施例还公开了一种网管与网元的信息交互装置，包括：

预置数据文件模块，用于预置命令数据文件和消息结构数据文件；

位于网管的命令字符串消息发送模块，用于发送命令字符串消息到网元；所述命令字符串消息包括命令关键字，输入字段以及对应的字段值；

位于网元的请求消息生成模块，用于根据所述命令字符串消息生成请求消息；具体包括以下子模块：

请求消息ID查找子模块，用于依据所述命令关键字在预置的命令数据文件中查找对应的请求消息ID；

第一消息体长度查找子模块，用于依据所述请求消息ID在预置的消息结构数据文件中查找第一消息体长度；

第一消息头子模块，用于将所述请求消息ID和第一消息体长度组织为第一消息头；

第一消息体组织子模块，用于将所述输入字段以及对应的字段值组织为第一消息体；

请求消息组织子模块，用于将所述第一消息头和第一消息体组织为请求消息。

位于网元的响应消息生成模块，用于处理所述请求消息，并生成响应消息；具体包括以下子模块：

响应消息ID查找子模块，用于依据所述请求消息ID在预置的命令数据文件中查找对应的响应消息ID；

第二消息体长度查找子模块，用于依据所述响应消息ID在预置的消息结构数据文件中查找获得第二消息体长度；

第二消息头组织子模块，用于将所述响应消息ID和第二消息体长度组织为第二消息头；

第二消息体组织子模块，用于将所述网元处理请求消息的处理结果信息组织为第二消息体；

响应消息组织子模块，用于将所述第二消息头和第二消息体组织为响应消息。

位于网元的处理结果字符串生成模块，用于根据所述响应消息生成处理结果字符串；具体包括以下子模块：

返回内容字段查找子模块，用于网元根据所述响应消息ID和第二消息体长度在预置的消息结构数据文件中查找对应的返回内容字段；

处理结果字符串形成子模块，用于对应所述返回内容字段组织所述处理结果信息，形成处理结果字符串。

位于网元的处理结果字符串返回模块，用于将所述处理结果字符串返回给网管。

优选地，所述装置还包括：

请求消息分发模块，用于网元根据所述请求消息ID分发请求消息。

优选地，所述预置的命令数据文件包括命令关键字、实际输入字段个数、输入字段名称、输入字段值、请求消息ID、响应消息ID；

所述预置的消息结构数据文件包括请求消息ID、响应消息ID、结构体叶子成员个数、结构体叶子成员占用内存大小、结构体叶子节点的偏移、回显标签、缺省取值、友好名。

优选地，所述请求消息中还包括消息序列号，所述响应消息中还包括消息序列号。

与现有技术相比，本申请包括以下优点：

本申请通过结合网管需要使用的命令和该命令所要使用的自定义接口之间的关系，生成数据文件，当命令行网管发送命令字符串消息至网元时，网元根据数据文件对命令字符串消息进行编码，形成图形化网管发送给网元的消息形式，网元处理完消息之后返回响应消息，网元根据数据文件对所述响应消息解码，形成命令行网管可以识别的消息格式返回至命令行网管。这样对于新增命令或者在命令行网管上增加命令或者对命令参数进行调整时，只要图形化网管中已经实现，就不需要更改程序，只需改变数据文件，再重新加载数据文件即可，从而能够大大简化程序升级过程，同时也避免了对设备提供的核心业务发生中断的情形，提高通信设备运行的安全性与稳定性。

附图说明

图1是一种图形化网管与网元交互的流程图；

图2是一种命令行网管与网元交互流程图；

图3是本申请的一种网管与网元的信息交互方法实施例的步骤流程图；

图4是本申请第一消息体处理步骤流程图；

图5是本申请返回网管的处理结果字符串生成步骤流程图；

图6是本申请的一种网管与网元的信息交互方法实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

为使本领域技术人员更好地理解本申请，以下对图形化网管和命令行网管的基本原理简单说明。

参照图1所示的图形化网管和网元的交互流程图，具体可以包括以下步骤：

步骤11，网管下发命令消息到网元。

步骤12，网元根据消息ID进行分发，并调用相应模块处理具体消息。

步骤13，网元将处理结果返回给网管。

由于图形化网管前端运行客户端软件，因此其组包(编码)和解包(解码)工作都可以由客户端程序完成。其中，组包(编码)指的是，将操作人员的输入格式化为网管和网元之间定义的接口消息码流；解包(解码)则指的是将网元返回的消息码流根据定义格式化为操作人员可理解的显示格式。

参照图2所示的命令行网管和网元的交互流程图，具体可以包括以下步骤：

步骤21，网管下发命令字符串消息到网元。

步骤22，网元解析命令字符串消息并进行编码，形成图形化网管下发命令消息的格式。

步骤23，网元根据消息ID进行分发，并调用相应模块处理具体消息。

步骤24，网元将返回给图形化网管格式的响应消息拦截，并进行解码，形成返回给命令行网管的处理结果字符串。

步骤25，网元将格式化后的处理结果字符串返回给命令行网管。

由于命令行网管没有运行客户端程序，所以不具备编码、解码能力，因此对于命令行网管来说，命令字符串消息的编码、解码就是关键之处。

本申请实施例的核心构思之一在于，通过结合网管需要使用的命令和该命令所要使用的自定义接口之间的关系，生成数据文件(其中包括命令数据文件和结构体数据文件)，通过数据文件驱动，网元使用一种通用的处理方法即可满足命令行网管的需求。在命令行网管上增加命令或者对命令参数进行调整时，只需要更新数据文件，不需要对设备进行重启或者切换，只需要重新加载数据文件即可生效。

参照图3，示出了本申请一种网管与网元的信息交互方法实施例步骤流程图，具体可以包括以下步骤：

步骤S1，预置命令数据文件和消息结构数据文件；

在本申请的一种优选实施例中，所述预置的命令数据文件包括命令关键字、实际输入字段个数、输入字段名称、输入字段值、请求消息ID、响应消息ID。

在本申请的一种优选实施例中，所述预置的消息结构数据文件包括请求消息ID、响应消息ID、结构体叶子成员个数、结构体叶子成员占用内存大小、结构体叶子节点的偏移、回显标签、缺省取值、友好名。

步骤S2，网管发送命令字符串消息到网元；所述命令字符串消息包括命令关键字，输入字段以及对应的字段值；

作为本申请实施例具体应用的一种示例，所述命令字符串消息的格式可以为：

命令关键字：Param1＝value1，Param2＝value2，…；(其中，Param代表输入字段，value代表输入字段值)

例如，执行获取CPU占用率的命令字符串消息为：

GET CPULOAD：Shelf＝1，Frame＝1，Slot＝1，CpuNo＝1；

在实际中，网管会将包含命令关键字，输入字段以及对应的字段值的命令字符串消息发送到网元。

步骤S3，网元根据所述命令字符串消息生成请求消息；具体包括以下子步骤：

子步骤S31，依据所述命令关键字在预置的命令数据文件中查找对应的请求消息ID；

子步骤S32，依据所述请求消息ID在预置的消息结构数据文件中查找第一消息体长度；

子步骤S33，将所述请求消息ID和第一消息体长度组织为第一消息头；

子步骤S34，将所述输入字段以及对应的字段值组织为第一消息体；

子步骤S35，将所述第一消息头和第一消息体组织为请求消息。

为便于本领域技术人员更好地理解本申请，可以参照如以下表1所示的命令清单：

表1：

表1中的第一列为命令关键字。第二列为命令关键字的中文说明。第三列是使用该命令时用户需要输入的字段。多个输入字段之间使用“、”符号分隔。第四列是命令在网元执行时所需要的消息ID(请求消息ID)，“＝”符号后是该消息ID的实际取值。第五列是该命令在网元执行所携带的消息结构体名称(请求消息ID对应的消息结构体名称)。第六列是网元执行完命令后返回给网管的消息ID(响应消息ID)，同样“＝”符号后是该消息ID的实际取值。第七列是网元执行完命令后返回给网管的消息结构体名称(响应消息ID对应的消息结构体名称)。

本领域技术人员还可以参照如以下表2所示的消息结构体清单：

表2：

表2中第一列为消息结构成员的描述，采用层次化的结构，描述了消息结构中的所有成员。第二列为结构体叶子成员占用内存大小(单位：字节)。第三列为消息结构体叶子成员在相对于其实际位置的偏移。第四列表示消息结构体中的成员是否需要在命令行网管台上显示，用于命令执行完成后将结果显示在命令行网管上(因为部分结构成员仅仅是做为程序控制而用，对于用户来讲，没有意义)。第五列是消息结构体成员的缺省取值(用户在输入命令时，并不是需要输入所有的成员，当没有输入时，则取默认值)。第六列消息结构成员的友好名，该友好名是用户输入的标识，另外也是回显给用户的标识。

需要说明的是，以上表1，表2仅仅用于在本说明书中说明本申请的相关技术特征，并不要求在实际中生成上述表格。

在实际中，在网管和网元之间使用自定义接口的前提下，结合命令行网管需要使用的命令和该命令所要使用的自定义接口之间的关系，生成数据文件，所述数据文件可以分为两个，一个为命令数据文件，一个为消息结构数据文件。

作为本申请实施例具体应用的一种示例，在具体实现中，所述数据文件的格式可以使用定长和变长两种格式，变长格式指的是每一条命令的输入字段的个数、字段长度等信息的存储空间并不相同，需要根据其实际长度来决定。定长格式指的是，即每一条命令的信息占用固定的存储空间。如果为了节省存储空间数据文件也可以使用变长格式。为了方便数据文件的解析则可以使用定长格式。为了描述简单，本申请实施例使用定长格式。

具体而言，所述命令数据文件即对应于以上表1所示的命令清单，将命令清单中的描述转换为特定的数据格式。即所述命令数据文件中可以包括命令关键字、实际输入字段个数、输入字段名称、输入字段值、请求消息ID、响应消息ID等。所述消息结构数据文件即对应于以上表2所示的消息结构体清单，将消息结构体清单中的描述转换为特定的数据格式。即可以包括请求消息ID、响应消息ID、结构体叶子成员个数、结构体叶子成员占用内存大小、结构体叶子节点的偏移、回显标签、缺省取值、友好名等。本领域技术人员可以根据实际情况任意设置所述命令数据文件和消息结构数据文件的内容，本申请对此不作限制。

例1，一种命令数据文件的示例如下：

例2，一种消息结构数据文件的示例如下：

在具体实现中，网元可以根据命令关键字在所述命令数据文件中查找到对应的请求消息ID，再依据所述请求消息ID在所述消息结构数据文件中查找到第一消息体长度，即消息结构体中的叶子成员占用内存大小，然后将所述请求消息ID和第一消息体长度组织为第一消息头。

作为本申请实施例具体应用的一种示例，所述第一消息头可以按照如下格式组织：

请求消息ID

第一消息体长度

参照图4，示出了一种在子步骤S34中将所述输入字段以及对应的字段值组织为第一消息体的处理流程图，所述子步骤S34可以理解为，将命令行网管发送的命令字符串消息经解析后变换成图形化网管发送网元的消息形式，具体可以包括以下子步骤：

子步骤41，获取结构体成员占用内存大小，并开辟同等大小缓冲区；

子步骤42，循环计数开始，设置LOOP1＝0；

子步骤43，判断所述LOOP1是否大于或等于结构体叶子成员个数，若是，则进程结束，若否，则执行子步骤44；

子步骤44，LOOP1加1；

子步骤45，判断结构体叶子成员是否有友好名，若有，则执行子步骤46，若无，则将结构体叶子成员的默认值拷贝到缓冲区；

子步骤46，设置LOOP2＝0；

子步骤47，判断所述LOOP2是否大于实际输入字段个数，若是，则将结构体叶子成员的默认值拷贝到缓冲区，若否，则执行子步骤48；

子步骤48，LOOP2加1；

子步骤49，判断输入字段名称是否匹配结构体叶子成员的友好名，若是，则执行步骤50，若否，则返回子步骤47；

子步骤50，将输入字段对应的值拷贝到缓冲区并返回子步骤43。

上述步骤完成后，缓冲区内形成第一消息体。

在实际中，还可以在所述请求消息中添加消息序列号作为当前请求消息的身份标识。

例如，对于获取CPU占有率的命令字符串消息，可以采用以下格式组织第一消息体：

消息序列号

架

框

槽

CPU号

为使本领域技术人员更好的理解本申请，以下通过一个具体示例对网元根据命令字符串消息生成请求消息的过程进一步说明：

网管下发了如下一条获取CPU占用率的命令字符串消息到网元：

GET CPULOAD：Shelf＝1，Frame＝1，Slot＝1，CpuNo＝1；

网元解析接收到的上述命令字符串消息，根据规定格式来分离关键字、输入字段以及输入字段值。

在实际中，网元可以采用正则表达式对命令字符串消息进行解析。网元收到上述命令消息字符串后，采用正则表达式解析的方式解析为：

命令关键字＝GET CPULOAD；

字段1＝Shelf；字段1取值＝1；

字段2＝Frame；字段2取值＝1；

字段3＝CpuNo；字段3取值＝1。

网元依据命令关键字GET CPULOAD在以上表1及对应的命令数据文件中查找到请求消息ID为：OAMS_O_GET_CPULOAD_REQ_MSG，再依据所述请求消息ID在消息结构数据文件中查找到对应的第一消息体长度为8字节，然后再将所述请求消息ID和对应的第一消息体长度组织为第一消息头为：

其中，所述请求消息ID与第一消息体长度所占位数均为4字节。在本申请的一种优选实施例中，所述请求消息中还包括消息序列号。

在实际中，还可以在所述请求消息中添加消息序列号作为当前请求消息的身份标识，网元将输入字段以及对应的字段值组织为第一消息体为：

消息序列号＝0

Shelf＝1

Frame＝1

Slot＝1

CpuNo＝1

其中，所述消息序列号所占为4字节，所述输入字段以及对应的字段值所占位数均为1字节，共8字节。网元将所述第一消息头和第一消息体组织为请求消息，形成获取CPU占有率的请求消息为：

获取CPU占有率的请求消息ID与第一消息体所占长度均为4字节，即所述第一消息头共占位数为8字节。消息序列号所占位数4字节，所述输入字段以及对应的字段值所占位数均为1字节，即所述第一消息体所占位数为8字节。

当然，上述生成请求消息的方式仅仅用作示例，本领域技术人员根据实际情况采用任一种请求消息的生成方式均是可行的，本申请对此无需加以限制。

步骤S4，网元处理所述请求消息，并生成响应消息；具体包括以下子步骤：

子步骤S41，所述依据请求消息ID在预置的命令数据文件中查找对应的响应消息ID；

子步骤S42，依据所述响应消息ID在预置的消息结构数据文件中查找获得第二消息体长度；

子步骤S43，将所述响应消息ID和第二消息体长度组织为第二消息头；

子步骤S44，将所述网元处理请求消息的处理结果信息组织为第二消息体；

子步骤S45，将所述第二消息头和第二消息体组织为响应消息。

在具体实现中，网元可以根据请求消息ID在命令数据文件查找到对应的响应消息ID，并根据响应消息ID在消息结构数据文件中查找获得第二消息体长度，然后将响应消息ID和第二消息体长度组织为第二消息头。

作为本申请实施例具体应用的一种示例，所述第二消息头可以按照如下格式组织：

第二消息头：

响应消息ID

第二消息体长度

网元处理请求消息的处理结果信息组织为第二消息体。在实际中，还可以在所述响应消息中添加消息序列号作为当前响应消息的身份标识。优选的是，可以在处理结果信息中加入表征当前处理结果成功或失败的返回码。

例如，执行获取CPU占用率的第二消息体可以采用如下格式：

消息序列号

返回码

CPU占有率

为使本领域技术人员更好的理解本申请，以下通过一个具体示例对网元生成响应消息的过程进一步说明：

网元可以根据请求消息ID：OAMS_O_GET_CPULOAD_REQ_MSG在以上表2及对应的命令数据文件查找到对应的响应消息ID为：OAMS_O_GET_CPULOAD_RSP_MSG，根据响应消息ID在消息结构数据文件中查找获得第二消息体长度为12字节，然后将响应消息ID和第二消息体长度组织为第二消息头为：

其中，所述响应消息ID与第二消息体长度所占位数均为4字节。在本申请的一种优选实施例中，所述响应消息中还包括消息序列号。

在实际中，可以在所述响应消息中添加消息序列号作为当前响应消息的身份标识，网元根据处理请求消息的处理结果信息组织的第二消息体为：

消息序列号＝0

Code＝0

CPU＝60

其中，所述消息序列号、返回码以及CPU占有率所占位数均为4字节，共12字节。

网元将所述第二消息头和第二消息体组织为响应消息，形成获取CPU占有率的响应消息为：

所述获取CPU占有率的响应消息ID以及第二消息体长度所占位数均为4字节，即第二消息头所占位数为8字节。消息序列号、返回码以及CPU占有率所占位数均为4字节，共12字节，即第二消息体所占位数为12字节。

在本申请的一种优选实施例中，在所述步骤S4之前，还可以包括以下步骤：

网元根据所述请求消息ID分发请求消息。

在具体实现中，网元根据请求消息ID分发请求消息，并调用相应的模块进行处理。

步骤S5，网元根据所述响应消息生成处理结果字符串；具体包括以下子步骤：

子步骤S51，网元根据所述响应消息ID和第二消息体长度在预置的消息结构数据文件中查找对应的返回内容字段；

子步骤S52，对应所述返回内容字段组织所述处理结果信息，形成处理结果字符串。

具体实现中，网元将返回给命令行网管的响应消息根据响应消息ID在消息结构数据文件中查找到对应的返回字段，并对应返回内容字段组织网元的处理结果信息，形成返回给命令行网管的处理结果字符串。

参照图5，所述步骤S5即为解码过程，将网元返回给图形化网管的二进制码流格式化为命令行网管所能显示的明文字符串，形成处理结果字符串，具体可以包括以下步骤：

子步骤51，网元根据响应消息ID在消息结构数据文件中找到对应的数据结构信息；

子步骤52，循环计数开始，设置LOOP＝0；

子步骤53，判断结构体叶子成员个数是否大于LOOP，若是，则进程结束，若否，则执行子步骤54；

子步骤54，LOOP加1；

子步骤55，判断结构体叶子成员是否需要显示，若是，则执行子步骤55，若否，则执行子步骤53；

子步骤56，判断结构体叶子成员是否有友好名，若是，则执行步骤57，若否，则返回子步骤53；

子步骤57，对应友好名格式化处理结果信息并返回子步骤53。

为使本领域技术人员更好的理解本申请，以下通过一个具体示例对网元根据响应消息生成处理结果字符串的过程进一步说明：

在本实施例具体应用的一种示例中，网元返回的获取CPU占有率的响应消息为：

网元根据响应消息ID：OAMS_O_GET_CPULOAD_RSP_MSG，在消息结构数据文件中找到对应的数据结构信息，格式化处理结果信息，生成处理结果字符串为：

CpuLoad＝60。

步骤S6，将所述处理结果字符串返回给网管。

在本实施例具体应用的一种示例中，获取CPU占有率返回给命令行网管的结果字符串结果如下：

Code＝0

CpuLoad＝60。

其中，返回码Code＝0表示命令字符串消息执行成功，若Code＝1则表示命令字符串消息执行失败。

为了提高系统的执行效率，系统在初始化或者在升级的时候，可以将数据文件加载到内存中。本申请着重强调网管的输入及对网管的输出，对于命令的真正执行并不做任何解释，只是认为简单的调用网元中某个模块的接口。另外，只要使用了本申请所描述或者类似的命令清单及消息结构体的设计方法，以及以命令清单、消息结构体清单所转换的数据文件进行编码、解码来实现的统一处理编程方法，即可认为采用了本申请。本申请尽管侧重描述了以自定义接口为基础的网管系统，但该方法同样适用使用以SNMP(Simple Network Management Protocol，简单网络管理协议)等标准协议为接口的网管系统，因此也可认为该方案和网管接口定义没有必然的关系。本申请可以用于电信网络设备中的接入网、核心网等的命令行接口。本申请避免了重复编程，本申请可以复用图形化网管已经存在的处理过程。对于新增命令，只要图形化网管中已经实现，就不需要更改程序，只需要更改命令清单、消息结构体清单，然后转换为数据文件，再重新加载数据文件即可，从而也避免了对设备业务的中断。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

参照图6，示出了本申请一种网管与网元的信息交互装置实施例步骤流程图，具体可以包括以下模块：

预置数据文件模块S201，用于预置命令数据文件和消息结构数据文件；

在本申请的一种优选实施例中，所述预置的命令数据文件包括命令关键字、实际输入字段个数、输入字段名称、输入字段值、请求消息ID、响应消息ID。

所述预置的消息结构数据文件包括请求消息ID、响应消息ID、结构体叶子成员个数、结构体叶子成员占用内存大小、结构体叶子节点的偏移、回显标签、缺省取值、友好名。

位于网管的命令字符串消息发送模块S202，用于发送命令字符串消息到网元；所述命令字符串消息包括命令关键字，输入字段以及对应的字段值；

位于网元的请求消息生成模块S203，用于根据所述命令字符串消息生成请求消息；具体可以包括以下子模块：

请求消息ID查找子模块，用于依据所述命令关键字在预置的命令数据文件中查找对应的请求消息ID；

第一消息体长度查找子模块，用于依据所述请求消息ID在预置的消息结构数据文件中查找第一消息体长度；

第一消息头子模块，用于将所述请求消息ID和第一消息体长度组织为第一消息头；

第一消息体组织子模块，用于将所述输入字段以及对应的字段值组织为第一消息体；

请求消息组织子模块，用于将所述第一消息头和第一消息体组织为请求消息。

在本申请的一种优选实施例中，所述请求消息中还包括消息序列号。

位于网元的响应消息生成模块S204，用于处理所述请求消息，并生成响应消息；具体可以包括以下子模块：

响应消息ID查找子模块，用于依据所述请求消息ID在预置的命令数据文件中查找对应的响应消息ID；

第二消息体长度查找子模块，用于依据所述响应消息ID在预置的消息结构数据文件中查找获得第二消息体长度；

第二消息头组织子模块，用于将所述响应消息ID和第二消息体长度组织为第二消息头；

第二消息体组织子模块，用于将所述网元处理请求消息的处理结果信息组织为第二消息体；

响应消息组织子模块，用于将所述第二消息头和第二消息体组织为响应消息。

在本申请的一种优选实施例中，所述响应消息中还包括消息序列号。

在本申请的一种优选实施例中，在所述装置还包括：

请求消息分发模块，用于网元根据所述请求消息ID分发请求消息。

位于网元的处理结果字符串生成模块S205，用于根据所述响应消息生成处理结果字符串；具体可以包括以下子模块：

返回内容字段查找子模块，用于网元根据所述响应消息ID和第二消息体长度在预置的消息结构数据文件中查找对应的返回内容字段；

处理结果字符串形成子模块，用于对应所述返回内容字段组织所述处理结果信息，形成处理结果字符串。

位于网元的处理结果字符串返回模块S206，用于将所述处理结果字符串返回给网管。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请的实施例可提供为方法、装置、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请所提供的一种网管与网元的信息交互方法和装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种网管与网元的信息交互方法，其特征在于，包括： 

步骤S1，预置命令数据文件和消息结构数据文件； 

步骤S2，网管发送命令字符串消息到网元；所述命令字符串消息包括命令关键字，输入字段以及对应的字段值； 

步骤S3，网元根据所述命令字符串消息生成请求消息；具体包括以下子步骤： 

子步骤S31，依据所述命令关键字在所述命令数据文件中查找对应的请求消息ID； 

子步骤S32，依据所述请求消息ID在所述消息结构数据文件中查找第一消息体长度； 

子步骤S33，将所述请求消息ID和第一消息体长度组织为第一消息头； 

子步骤S34，将所述输入字段以及对应的字段值组织为第一消息体； 

子步骤S35，将所述第一消息头和第一消息体组织为请求消息； 

步骤S4，网元处理所述请求消息，并生成响应消息；具体包括以下子步骤： 

子步骤S41，依据所述请求消息ID在预置的命令数据文件中查找对应的响应消息ID； 

子步骤S42，依据所述响应消息ID在预置的消息结构数据文件中查找获得第二消息体长度； 

子步骤S43，将所述响应消息ID和第二消息体长度组织为第二消息头； 

子步骤S44，将所述网元处理请求消息的处理结果信息组织为第二消息体； 

子步骤S45，将所述第二消息头和第二消息体组织为响应消息； 

步骤S5，网元根据所述响应消息生成处理结果字符串；具体包括以下子步骤： 

子步骤S51，网元根据所述响应消息ID和第二消息体长度在预置的 消息结构数据文件中查找对应的返回内容字段； 

子步骤S52，对应所述返回内容字段组织所述处理结果信息，形成处理结果字符串； 

步骤S6，网元将所述处理结果字符串返回给网管。 

2.根据权利要求1所述的方法，其特征在于，在所述步骤S4之前，还包括： 

网元根据所述请求消息ID分发请求消息。 

3.根据权利要求1或2所述的方法，其特征在于，所述预置的命令数据文件包括命令关键字、实际输入字段个数、输入字段名称、输入字段值、请求消息ID、响应消息ID。 

4.根据权利要求1或2所述的方法，其特征在于，所述预置的消息结构数据文件包括请求消息ID、响应消息ID、结构体叶子成员个数、结构体叶子成员占用内存大小、结构体叶子节点的偏移、回显标签、缺省取值、友好名。 

5.根据权利要求1或2所述的方法，其特征在于，所述请求消息中还包括消息序列号。 

6.根据权利要求1所述的方法，其特征在于，所述响应消息中还包括消息序列号。 

7.一种网管与网元的信息交互装置，其特征在于，包括： 

预置数据文件模块，用于预置命令数据文件和消息结构数据文件； 

位于网管的命令字符串消息发送模块，用于发送命令字符串消息到网元；所述命令字符串消息包括命令关键字，输入字段以及对应的字段值； 

位于网元的请求消息生成模块，用于根据所述命令字符串消息生成请求消息；具体包括以下子模块： 

请求消息ID查找子模块，用于依据所述命令关键字在预置的命令数据文件中查找对应的请求消息ID； 

第一消息体长度查找子模块，用于依据所述请求消息ID在预置的消息结构数据文件中查找第一消息体长度； 

第一消息头子模块，用于将所述请求消息ID和第一消息体长度组织为第一消息头； 

第一消息体组织子模块，用于将所述输入字段以及对应的字段值组织为第一消息体； 

请求消息组织子模块，用于将所述第一消息头和第一消息体组织为请求消息；

位于网元的响应消息生成模块，用于处理所述请求消息，并生成响应消息；具体包括以下子模块： 

响应消息ID查找子模块，用于依据所述请求消息ID在预置的命令数据文件中查找对应的响应消息ID； 

第二消息体长度查找子模块，用于依据所述响应消息ID在预置的消息结构数据文件中查找获得第二消息体长度； 

第二消息头组织子模块，用于将所述响应消息ID和第二消息体长度组织为第二消息头； 

第二消息体组织子模块，用于将所述网元处理请求消息的处理结果信息组织为第二消息体； 

响应消息组织子模块，用于将所述第二消息头和第二消息体组织为响应消息； 

位于网元的处理结果字符串生成模块，用于根据所述响应消息生成处理结果字符串；具体包括以下子模块： 

返回内容字段查找子模块，用于网元根据所述响应消息ID和第二消息体长度在预置的消息结构数据文件中查找对应的返回内容字段； 

处理结果字符串形成子模块，用于对应所述返回内容字段组织所述处理结果信息，形成处理结果字符串； 

位于网元的处理结果字符串返回模块，用于将所述处理结果字符串返回给网管。 

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

请求消息分发模块，用于网元根据所述请求消息ID分发请求消息。 

9.根据权利要求7或8所述的装置，其特征在于，所述预置的命令数据文件包括命令关键字、实际输入字段个数、输入字段名称、输入字段值、请求消息ID、响应消息ID； 

所述预置的消息结构数据文件包括请求消息ID、响应消息ID、结构体叶子成员个数、结构体叶子成员占用内存大小、结构体叶子节点的偏移、回显标签、缺省取值、友好名。 

10.根据权利要求7或8所述的装置，其特征在于，所述请求消息中还包括消息序列号，所述响应消息中还包括消息序列号。