CN1627757A

CN1627757A - 通用消息解释器的实现方法

Info

Publication number: CN1627757A
Application number: CN 200310123617
Authority: CN
Inventors: 黄泥; 王灏
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2003-12-12
Filing date: 2003-12-12
Publication date: 2005-06-15
Anticipated expiration: 2023-12-12
Also published as: CN100505743C; WO2005057873A1

Abstract

本发明公开了一种通讯接口消息的解码和解释的方法，该方法为：首先用ASN.1结合编码解码控制字记法对通信协议中的消息结构进行描述，生成协议动态库；将消息码流和该消息码流对应的协议动态库传递给消息解释器，消息解释器调用公共的解码函数库中的函数进行解码，在解码过程中查询协议动态库中各个信元的类型、编码解码控制字－是BER、PER还是TLV，并根据信元的编解码控制字代表分别调用相应的解码函数进行解码并形成一个消息值树；遍历值树的每个节点，从而把整个消息的内容生成具有层次结构的格式化文本并输出；分析输出的格式化文本流，形成解释关系树并将该关系树和消息码流以图形化的方式显示出来。

Description

通用消息解释器的实现方法

技术领域

本发明涉及通信技术，尤其涉及通信系统中通用消息解释器的实现方法。

背景技术

通信或电信领域的协议一般都较为复杂，在通信系统的维护和测试中，需要了解通信接口上的交互情况，直接观察通信接口上的二进制码流往往很难知道其含义，在通信系统的网管系统或信令测试仪等系统上一般都提供消息解释功能，把需要观察的码流转换成易理解的形式并解释其含义，如图1所示。

最初的消息解释器都是专用型的，一种消息解释器只能解释一种协议或者相类似的一些协议。随着通信协议的逐渐增多，为每一种协议编写一个新的解释器就显得效率很低了，而且协议的修改和升级也会导致消息解释器的修改。

在ASN.1出现以前，大部分消息解释器都是采用自己定义的描述语言来进行协议的描述的。随着电信协议采用ASN.1越来越多，消息解释器基于ASN.1就成为一种自然的选择。

消息解释器的关键技术就是消息的分析和解码功能，以及描述性语言的数据表达能力。

随着信息技术的发展，在电信领域和计算机技术领域出现了很多通信协议。这些协议的目的是使得通信的双方对它们将要进行的活动能够规范化的进行。协议保证了对活动认知的明确性和一致性。

这种协议的描述，在以前通常都是以一种文本化的格式通过标准的形式提供给用户。通过这样的协议文本和文本中包含的图示，用户可以清晰的了解协议通信的交互过程，以及交互过程中使用的协议数据类型和协议数据格式。这些协议数据类型和协议数据格式虽然使得用户可以清晰的认识到通信双方或者多方之间交互的数据形式和内容，但是用户却难以使用一种有效的简单的机制去检查和验证这些数据。即使为了解决工程实际当中的问题，用户自发研制出了相应的技术，但是缺乏统一的技术使用标准，使得各个不同用户之间交互变得更加困难。于是，国际电联(ITU-T)提出了标准的协议数据描述抽象记法以及抽象协议数据的传输表达方法。这就是抽象语法记法1(ASN.1-AbstractSyntax Notation One)。

ASN从两个方面对协议数据进行了说明。一个方面是协议数据的抽象表达方法，分别由X.680，X.681，X.682和X.683进行说明。X.680规定了ASN的基本技法。它明确的说明了基本类型记法，基本类型构造复合类型的构造方法以及复合类型的记法和简单类型约束的记法。X.681说明了类的构造方法、类的记法、对象的记法，对象集合记法，值以及值集合的记法。它还给出了类型对象化时一种较为友好的表示方法。X.682则集中考虑如何对类型和类进行高级约束的记法，它的目的是尽量缩小原类型和原类的值和对象的涵盖范围，目的在于更加具体化原类型和类。X.683给出了参数化的一些标准记法，这样使得协议描述能够更加抽象化，进而提高协议描述的适用范围和通用性。

ASN.1的另一方面是规定抽象协议数据的传输表达方法。这里的实质包含两个方面，分别对应着通信的发送方和接收方。对于发送方，它规定了传输码流的编码方法；而对于接收方，它规定了如何将传输码流解码成抽象数据的方法。在电信领域，目前得到广泛的ASN编码方法有两种：一种是BER(基本编码规则)和PER(压缩编码规则)。这两种编码规则分别在国际电联标准的X.690和X.691中给出。用ASN.1制定的协议大都采用了BER或者PER编码方式。

BER编码的格式比较简单，规定通常每一种编码都由三部分组成：标识符、长度和内容组成。如下图所示：

BER标识符由类型自身决定或者由用户指定得到。标识符通常有单字节方式和多字节两种编码方式。单字节的编码方式如图所示：

标识符的类别号占用两个Bits，由BER标准给出。00表示Universal类别，01表示Application类别，10表示Context-specific类别，11表示Private类别。编码方式，当后边的内容编码使用构造方式编码时为1，否则为0。标识符的取值范围为0-30。

当标识符值超过30时，需要对上边的标识符编码做扩展。扩展的方法时将标识符值部分全置为1，也就是11111。扩展字节对实际的标识符值进行编码，但是编码时只使用一个字节的低7位，而第8位用来说明扩展字节是否结束。该位置1，表示后面还有扩展字节；置0表示本字节是扩展的最后一个字节。在编码时，第一个扩展字节编码标识符值的最高位码子，后续扩展字节编码标识符值的次低位码子，直到最后一个扩展字节编码最低位的码子。扩展字节的个数为编码标识符值的最小字节数。

BER长度用来编码内容部分占用的实际字节个数。长度的编码有确定格式和不确定格式两种。确定格式有长格式和短格式两种。短格式用来编码长度值小于等于127的编码形式。长格式编码长度值超过127的编码形式。

短格式长度编码占用一个字节。编码时使用低7位，最高位不被使用，并且被置为0。

长格式长度编码占用多个字节。第一个字节为初始字节，它的最高位(第8位)置为1，低7位用来表示长度编码使用的字节数。后续字节用来编码实际的长度。在编码时，如果编码字节超过1个字节，则第一个字节的8位表示长度编码的最高权值位，后续字节表示次高权值位，依次类推，直到最后一个字节表示长度编码最低权值位。但是用于初始字节只有7为用来表示长度编码占用的字节数，所以它就限制了长格式长度编码占用的实际字节数不能超过127个字节。

不确定格式通常被用户用在编码事先不能确定内容部分长度的场合。长度部分占用一个字节，这个字节的值被置为0x80(二进制10000000)。然后紧接着它的后面编码内容部分。整个内容部分编码完成后，最后附加两个值为0的字节。将这两个字节叫做EOC(End Of Contents)。这样内容部分实际的长度就是处于0x80和EOC之间的编码流占用的字节数。

BER内容用来编码ASN抽象值。这些值可以是ASN.1规定的任意类型。每一个类型值的编码都是由类型本身决定，但是它的格式都是由上面叙述的三部分构成，即标识符部分、长度部分和内容部分。

一个协议的协议数据可以使用ASN.1抽象类或者抽象类型进行描述，从而形成一个表示协议数据的模板。在实际协议数据的描述中，一个协议模板都是由一个复合类型开始，而这个复合类型，在以后的描述中叫做根类型。如果使用抽象数据实例化这个协议数据模板，就形成了通信协议种经常使用的通信消息。

如果在工程实际当中，需要对通信消息进行BER编码，那么就对构成通信消息的每一个抽象值进行BER编码。而每一个抽象值如何编码，这完全决定于和这个抽象值对应的ASN类型。每一种类型的编码方法由ITU-T的标准X.690规定。但编码的格式由前面叙述的三部分构成。

从这里可以得知，BER编码技术就是从一个根类型的抽象数据开始进行编码。首先编码它的标识符部分，然后是长度部分，接着是内容部分。内容部分，按照根类型的规定，编码它的各个组成部分。对于各个组成部分，仍然是先编码标识符部分，然后是长度部分，最后是内容部分。如果组成部分仍然是复合类型的抽象数据，则继续递规上边的编码过程，直到完成整个编码。

BER编码从形式上看就是从根类型开始，不断重复标识符、长度、内容，内容中再嵌套标识符、长度、内容，然后内容再嵌套表示符、长度、内容，......，直到最后简单类型的标识符、长度、内容。然后回溯，然后再嵌套，再回溯......。直到整个根类型抽象值的成分都变成了标识符、长度、内容这种形式。

在BER基础上提PER编码方案。它解决了BER编码流过长的缺点，也从很大程度上摆脱了标识符(TAG)的影响，主要是大部分的类型编码不依赖于TAG，并且编码时，并不对TAG进行编码。

PER编码的大体思想是这样的：不再使用标识符、长度、内容这样的编码的模式。在编码的时候仅仅关心内容这一个部分，而且在具体编码时尽量对编码进行压缩，使得结果码流的比特数最少。

压缩的方法是在有效表达信息的基础上，尽量使用最少的比特数传达信息。比如在BER中，布尔类型需要标识符、长度、内容三个域即三个字节编码，结果码流就有24个比特。而在PER编码中，表达布尔类型这种只含有两个值的类型，只需要1个比特就可以完成任务。

由于类型从本质上讲就是值的集合。类型的各种约束就是缩小这种集合的范围，使之更能准确的表达所需的信息。压缩编码(PER)就是利用这个本质进行，对这些值集合(包括类型和约束类型)不在使用原来值集合每一元素的本身的值，而是使用集合元素相对于集合小值边界的偏移进行编码。当值集合的上界和下界都存在，而且在一个适当的范围比如64K，则值集合中的每一个值都使用表示这个范围最少的比特数进行编码，同时考虑到传输的要求适当的增大这个比特数，使之最好是8的倍数。当然有时类型并没有给出具体的集合值的上界和下界。对于这两种特殊情况进行特殊的处理。

对于没有只有下界没有上界，仍然使用对下界的偏移对值进行编码，但是编码使用的比特位数是编码这个偏移所需的最少8比特的倍数。

对于既没有上界也没有下界的情况，对值集合中元素本身的值进行编码，同样编码所需的位数是编码这个值所需的最少8比特的倍数，也就是和BER的内容部分相同。

对于只有上界没有下界的情况，编码视具体的情况而定。对于像字符串、序列的上下界等等。没有下界和下界为零是等效的，则使用零作为下界。否则，在实际应用中也不能确定下界时，就和既没有上界也没有下界的情况等同对待。

在PER编码中，每一种类型的编码也有可选的长度部分。但它仅仅在通过约束和实际的编码规则无法断定值编码确切长度时，才需要编入码流中，指示值编码的长度。

和长度部分有些类似，PER也有类似于BER标识符的部分，但是这里有一个新的名字叫做报头(preamble)。它的出现仍然是可选的，仅仅当复合类型的某些成分类型是可选的或者具有缺省值，或者这个复合类型具有特殊的扩展属性时，才使用报头，并且对它进行编码。

在现有技术中，对通信接口的消息解释主要有两种方法：

方法一、通过专用的一段程序代码来负责一种协议的解码；但该方法存在以下不足：

1、对用户的要求高，用户不仅需要了解协议的细节，还需要实现协议中所有消息的分析过程。

2、维护困难，协议修改都需要重新修改、编译代码。

3、扩展性差，新增加协议需要新写代码。

方法二、采用自定义描述语言的消息解释器，对每一个支持的协议都提供一个协议描述描述文件，描述语言采用标准的ASN.1，编码方式用基本编码规则(BER)和压缩编码规则(PER)，消息解释器增加对新协议支持时只需要编写新的协议描述文件。虽然采用方法二使得消息解释器的公共部分可以得到很好的重用，但仍存在以下缺点：

1、自定义描述语言的数据表达能力有限，不能直接处理大量提供ASN.1描述的协议，需要提供额外的转换功能来辅助实现。

2、自定义的描述语言需要付出额外的学习时间，而且资料和开发工具缺乏。

3、描述语言采用标准ASN.1，目前ASN.1标准中使用的只有BER，PER两种常用编码方式，而用纯ASN.1不能对没有采用ASN.1协议的消息码流进行解码，通用性差。

发明内容

本发明的目的在于提供一种通用消息解释器的实现方法，以解决现有技术存在通用性和扩展性差的问题。

为解决上述问题，本发明提供下述技术方案：

一种通讯接口消息的解码方法，该方法包括步骤：

1、一种通用消息解释器的实现方法，其特征在于包括步骤：

A、从通讯接口获取消息码流；

B、调用消息码流采用的协议所对应的协议消息结构描述信息，根据该描述信息中各信元的编码解码控制字调用相应的解码函数对所述消息码流进行逐段解码，形成消息值树，该消息值树的每个节点对应消息的一个信元，其中：

如果信元的协议编解码控制字表示为基本编码规则(BER)，则调用BER的解码函数进行解码；

如果信元的编解码控制字表示为压缩编码规则(PER)，则调用PER的解码函数进行解码；

如果信元的编解码控制字表示为类型-长度-值记法(TLV)，则调用TLV的解码函数进行解码；

如果信元的编解码控制字表示为BER、PER和TLV中多项的组合，则分别调用对应的解码函数进行解码；

C、遍历所述消息值树，对每个信元按其格式输出解码后的字符串。

根据上述方法：

步骤C中，将字符串生成具有层次结构的格式化文本流后输出。

通过图形界面(GUI)分析输出的文本流，形成解释关系树，并在该图形界面上将关系树和消息码流显示出来。

在进行步骤A之前，将抽象语法记号1(ASN.1)与编码解码控制字结合对需要解释的协议进行描述并形成协议消息结构描述信息，再将该描述信息生成协议动态库供调用；所述编码解码控制字添加在ASN.1文本中的类型定义处。

所述的编码解码控制字可为BER、PER和TLV之一，或者为BER、PER和TLV的多项组合。

所述ASN.1文本中嵌入有实现信元间约束关系的C语言程序并包含在生成的协议动态库中；当完成解码后执行该程序，完成自定义约束限制。

本发明具有以下有益效果：

1、大大降低了电信网管系统，电信系统测试工具，测试仪器支持多种协议解释的开发工作量。

2、提高了消息解释器的通用性和可扩展性，其中的GUI、编码解码引擎等都可以保持稳定，增加一个协议的支持只用提供协议对应的ASN.1文件即可。

附图说明

图1为接口消息解释结果示意图；

图2A为本发明的消息解释器系统框图；

图2B为本发明的主要流程图；

图3为图形界面显示消息码流和解释消息的示意图；

图4为编解码示意图；

图5为通信设备组网示意图；

图6为协议消息描述结构示意图；

图7为解码流程图。

具体实施方式

本发明通过采用类型-长度-值(TLV)编码控制方法来解决用ASN.1描述非ASN.1定义的协议，对TLV编码控制方法说明如下：

T：表示类型标识的控制，类似于BER中的标识符(TAG)，但是它的类型取值却与BER类型取值毫无关系。

L：表示长度部分的控制，类似于BER中的长度，但是不仅仅表示内容部分的长度，而且标示着各种与长度有关的编码控制。

V：表示值部分的编码控制，这部分兼有BER内容部分和PER压缩编码的方法和值部分各种控制设置。

TLV编码控制提供给用户使用的形式如下：

“<总体编码控制，子控制>’’

整个控制用“<台>”括起来，各个控制之间用“，”隔开。

总体编码控制(GeneralControl)：给出总的编码规则和编码约束和控制。本部分的表示形式是“A|B-a-b”。A的取值可以为BER、PER、SCCP、T、TV、V、TLV、LTV、LV等等。B的取值是各种与编码有关的控制和约束。它的取值可以为大小端：ENDIAN，对齐：BOUNDARY，PER方式对齐：PERALIGN，构造或者简单编码：CONSTRUCTED/SIMPLE。a、b分别为可选的参数。比如对齐需要一个参数指示是否进行对齐。<TV|BOUNDARY-ALIGN>表示TV形式的编码，编码时采取对齐方式。

子控制(Subcontrol)：对总体的控制进行进一步的说明。本部分的表示形式和总体编码控制的表示形式相同。“|”的左边表示控制名，“|”右边用“-”隔开的每个部分，第一部分表示控制项，第二个部分以及以后的部分表示控制项的第一个参数，第二个参数，依次类推。

例如，在协议中某一个类型描述前，看到下面的形式：

这表示被修饰类型将来采用TLV规则进行编码。T部分使用8个比特进行编码；L部分使用16个比特进行编码，它的值尺度是3个比特，就是说如果L部分的值是5，则长度部分占用的总的比特是5×3＝15比特；对本类型的值进行完编码后，需要使用异或(XOR)进行检验和计算。

TLV各个部分的控制项如下：

T部分：

LEN控制项，带一个参数，用来指示T部分使用多少个比特进行编码。如T|LEN-8。

ENDIAN控制项，带有一个参数，取值为BIG和LITTLE，表示本部分是大端编码还是小端编码。

L部分：

LEN控制项，带一个参数，用来指示L部分使用多少个比特进行编码。

SCALE控制项，带有一个参数指定L部分值的尺度。这样可以打破L部分值的尺度是字节的限制。参数是多少，L尺度就是多少个比特。比如SCALE-2，L部分的值是3，那么它的含义就是3个2比特。参数还可以取特殊值，比如CMPNT，表示长度的尺度是当前类型编码的逻辑单位。比如用它修饰字符串，就表示尺度取字符的个数，而不管字符本身是用多少个比特编码。

ADD/SUB控制项，带一个参数，表示L的值在原来的基础上还要增加/减少参数给定的数量

SELF控制项，没有参数，表示L的值需要增加L部分本身编码占用的字节数。

SCCPLEN控制项，没有参数，表示当长度小于255时，使用一个字节进行编码。大于255时使用三个字节进行编码，第一个字节编码为0xff，后边两个字节进行长度编码

TO控制项，带两个参数，第一个参数表示控制子项，第二个表示补齐时需要填充的长度。总共有三个控制子项：VALIGN、ALIGN、值控制项。VALIGN指值编码按照它的尺度进行对齐，不足部分，用参数给定的比特值补齐。ALIGN值编码要补齐到字节边界上，不足部分使用参数给定的比特值补齐。值控制项比较特殊，它的形式为TO-16-0，表示值的编码需要占用固定16个字节，如果编码不足16个字节，则用0不足到16个字节。

V部分：

LEN控制项，带一个参数，用来指示V部分使用多少个比特进行编码。

Dummy控制项，带有两个参数。这个参数主要处理复合类型中一个成分编码被多个成分完整编码分割的问题。第一个参数表示被分割的第一部分编码的比特数，第二个参数表示分割本称分编码的成分个数。

EBIT控制项，带一个参数。当编码的码流有多个字节长度时，每一个字节最左边一位决定下一个字节是否表示码流。用给定的参数设定最左位，表示后边的字节还属于码流。如果是最后一个字节，则左位设定参数取反后的值。

DN控制项，带一个参数。控制电话号码的BCD表示，如果编码没有在字节边界上，使用参数不足到字节边界上。

MI控制项，在编码电话号码之前，先根据电话号码个数的编码一个比特的奇偶位，当电话号码为偶数，置为0，否则置为1。当整个编码不在字节边界时，使用参数给定的值不足到字节边界上。

TRAIL控制项，带一个参数。进行完编码后，使用参数指定的值作为编码的结束符。

PERALIGN控制项，没有参数，表示编码按照PER的对齐方式进行对齐。

CHOICE类型控制项：

V自身修饰CHOICE类型的控制作用，使用索引选择CHOICE的成分。

TV本身修饰CHOICE类型的控制作用，使用标签值选择CHOICE成分。

WHEN控制项，带有一个条件表达式，根据已知成分的值，计算表达式，选取表达式为真的成分。

UNION控制项，带一个参数，控制CHOICE成分的编码长度使用成分类型中最大长度作为整个编码的长度，有点类似于C语言的UNION。如果实际的编码不足最大长度，使用参数给定的值填充到最大长度。

总体编码控制：

ENDIAN控制项，带有一个参数，取值为BIG和LITTLE，表示是大端还是小端编码。

BOUNDARY控制项，带有一个参数，取值为ALIGN和NONALIGN，表示编码是否从整字节边界开始。

PERALIGN控制项：带一个参数，取值为ALIGN和NONALIGN，表示是执行PER对齐方式的编码，还是非对齐方式的编码。仅仅对于PER有效。对其他BER、TLV、SCCP等等无效。

C语言函数控制：

WHEN控制项：修饰复合类型的成分，用来执行一个C语言风格的表达式，完成选择控制。

EMBED EXEC控制项：定义在协议ASN描述的任何空白部分，内容是内嵌的C语言程序或者函数库，可以在WHEN计算表达式时使用。

EXPORT控制项：将当前成分的值输出到一个外部C变量中。

IMPORT控制项：将外部C变量的值引入到当前的ASN描述中，用于动态计算某些约束。

参阅图2所示，本发明的消息解释器主要由编码解码引擎和图形界面(GUI)两部分组成：

编码解码引擎：负责根据选取的协议动态库对输入的码流进行解码，并构造输出解码后消息的解释信息的格式化文本。

GUI：主要功能是对格式化文本进行分析，并将消息解释内容的格式显示出来，并完成人机交互功能。

消息解释器解码的主要处理过程如下：

1、获取协议对应的协议动态库和从通信接口获取需解释的消息码流。

在解释消息码流前，用户用ASN.1文本描述其需要解释的协议，通过ASN转换程序将ASN.1文件编译成C文件；用C语言编译器和链接器将C文件编译，链接成含有该协议特征信息的协议动态库。对于非ASN.1定义的协议，采用ASN.1与前述的TLV编码控制字相结合的方式进行描述。

协议动态库由用户输入的ASN.1文本构成，包含了协议中所有消息的结构信息，以及信元之间的相互关系等信息。

由用户输入需要解释的消息码流所采用的协议。

2、编码解码引擎根据协议动态库对需解释的消息码流进行解码，形成一棵消息的值树，树上的每一个节点就是消息的一个信元。其中在解码时：

如果信元的协议编解码控制字表示为基本编码规则(BER)，则调用BER的解码函数进行解码；如果信元的编解码控制字表示为压缩编码规则(PER)，则调用PER的解码函数进行解码；如果信元的编解码控制字表示为类型-长度-值记法(TLV)，则调用TLV的解码函数进行解码；如果信元的编解码控制字表示为BER、PER和TLV中多项的组合，则分别调用对应的解码函数进行解码。

3、编码解码引擎遍历值树，生成有层次的格式化文本；

下面是一个例子

SysMsg

0> 00 00000000 ..sender mid：0x0(0)

1> 00 00000000 ..sender pid：0x0(0)

2> 00 00000000 ..receiver mid：0x0(0)

3> 00 00000000 ..receiver pid：0x0(0)

4> 00 00000000

5> 0C 00001100 L ..msg

6> 00 0000---- ....protocol discrimator：0，group call control

----0000 ....transaction identifier：0x0(0)

>>Layer3

7> 17 00010111 T ....cmServiceRequest

8> C1 1100---- T ......cm service type

----0001 ......：1，mobile origin call estab or packet modeconnection

9> D0 1101---- T ......ciphering key sequence

----0000 ......：0，through Possible values for the ciphering key

10> 03 00000011 L ......mobile station

11> 00 0------- ........sparel：0x0(0)

-00----- ........revision level：0，reserved for phase 1

---0---- ........es ind：0，controlled Early Classmark Sending optionis

----0--- ........a51：0，encryption algorithm A51 available

-----000 ........rf power capability：0，class 1

12> 00 0------- ........spare2：0x0(0)

-0------ ........ps capa：0，ps capability not present

--00---- ........ss Screen Indicator：0，defined in 0408 0

----0--- ........sm capa：0，mobile station does not support mobile

-----0-- ........vbs：0，no VBS capability or no notifications wanted

------0- ........vgcs；0，no VGCS capability or no notificationswanted

-------0 ........fc：0，the MS does not suppon the E GSM or R GSMband

13> 00 0------- ........cm3：0，the MS does not support any options that are

-000---- ........spare3：0x0(0)

----0--- ........soLSA：0，the ME does not support SoLSA

-----0-- ........cmsp：0，cmsp not supported

------0- ........a53：0，encryption algorithm A53 not available

-------0 ........a52：0，encryption algorithm A52 not available

14> 03 00000011 L ......mobile identity

4、GUI界面对编解码引擎的输出文本流分析并形成解释关系树，并在界面上将此关系树和码流显示出来，完成整个消息解释过程。显示界面如图3所示。

在本发明中，ASN编译器中支持TLV等编解码控制，且编码解码控制字可同BER、PER规则混用。标准的ASN.1规范中是只支持对整个文件或者模块选定使用BER或者PER编码规则的，下面是ITU-T H.248协议的ASN文本的一部分。实际使用时要么使用BER规则，要么使用PER规则。如下所示：

    MEDIA-GATEWAY-CONTROL  DEFINITI0NS  AUTOMATIC TAGS∷＝
BEGIN

　　MegacoMessage∷＝SEQUENCE

　　{

　　    authHeader    [0]IMPLICIT    AuthenticationHeader OPTIONAL，

　　    mess          [1]IMPLICIT    Message

　　}

　　AuthenticationHeader∷＝SEQUENCE

　　{

　　     secParmIndex   [0]IMPLICIT   SecurityParmIndex，

　　     seqNum         [1]IMPLICIT   SequenceNum，

　　     ad             [2]IMPLICIT   AuthData

　　}

　　SecurityParmIndex∷＝OCTET STRING(SIZE(4))
        <!-- SIPO <DP n="14"> -->
        <dp n="d14"/>
　　SequenceNum        ∷＝OCTET STRING(SIZE(4))

　　AuthData           ∷＝OCTET STRING(SIZE(12..32))

　　Message∷＝SEQUENCE

　　{

　　     version          [0]IMPLICIT INTEGER(0..99)，

　　     --The version of the protocol defined here is equal to 1.

　　     mId                  [1]EXPLICIT MId，             --Name/address of
message originator

　　          messageBody  [2]EXPLICIT            CHOICE

　　          {

　　                  messageError [0]IMPLICIT    ErrorDescriptor，

　　                  transactions [1]EXPLICIT SEQUENCE OF Transaction

　　          }，

　　          ...                                                

　　   }

显然只用BER、PER两种规则是无法满足实际应用中多种多样的编码解码需求的。

通过在ASN文本中每个类型定义处加入括号“<>”，在括号中放入用户希望的编码解码控制字。通过编码控制字的自动继承，如果用户希望在一个模块中用统一的一种编码规则，只需要在其父类型中指定编码规则，子类型就会自动继承父类型的编码规则，在子类型处显示的指定编码规则会覆盖调继承来的编码规则，这样用户就可以指定每种类型的编码解码规则，同时又不需要对ASN语法做大的改动。下面是一个在ASN文本中指定各个类型的编解码规则的例子，其中“<>”中的部分就是编码解码控制字。如下所示：

　　Bit1  ∷＝＜V，V|LEN-1＞INTEGER(0..1)

　　Bit2  ∷＝＜V，V|LEN-2＞INTEGER(0..3)
        <!-- SIPO <DP n="15"> -->
        <dp n="d15"/>
　　Short∷＝＜V，V|LEN-16＞INTEGER(0..0xffff)

　　ThreeByte∷＝＜V，V|LEN-24＞INTEGER(0..0xffffff)

　　INT∷＝＜V，V|LEN-32＞INTEGER(0..0xffffffff)

　　SeVenByte∷＝＜V，V|LEN-56＞INTEGER(0..0xffffffffffffff)

　　HexString  ∷＝VisibleString(FROM(48..57|65..70))    --′0′...′9′，′A′...′F′

　　HexStringl  ∷＝VisibleString(FROM(48..57))

　　Dtmfstring∷＝VisibleString(FROM(48..57|65..70))--

　　Printablestring∷＝＜V，V|LEN-8＞PrintableString

　　Valuea∷＝Byte(0xA1)

　　Valuef∷＝Bit4(15)

　　--              *****************************

　　--                     Sytem  Message

　　--              *****************************

　　MsgEnter∷＝＜V＞SEQUENCE

　　{

　　   mtpLevel3Head     MTPLevel3Head，

　　   label      Label，

　　   msg-type      Msg-type

　　}

　　MTPLevel3Head∷＝＜V＞SEQUENCE

　　{

　　  serviceIndicator＜V，V|LEN-4＞ENUMERATED

　　  {

　　  isup            (5)
　　  }

　　  ，spare1                     Bit2

　　  ，networkIndicator＜V，V|LEN-2＞ENUMERATED

　　  {
        <!-- SIPO <DP n="16"> -->
        <dp n="d16"/>
　　    nationalNetwork    (2)

　　  }

　　}

　　Label∷＝＜V＞SEQUENCE

　　{

　　    destination-point-code        ＜V，V|LEN-24＞INTEGER(0..0xFFFFFF)，

　　    originating-point-code        ＜V，V|LEN-24＞INTEGER(0..0xFFFFFF)，

　　    link-select-code              ＜PER＞INTEGER(0..0xFF)，

　　    circuit-identification-code   ＜BER＞INTEGER(0..0xFFFF)

　　}

ASN编译器对ASN文本进行编译时，对每个类型都生成一个Ttype结构，Ttype结构中就包含每个类型的编码解码控制规则，即上面例子ASN文本中“<>”里的部分，可以是BER，PER或者自定义的TLV。用户没有显示定义的类型也会根据继承关系自动计算出他的编解码控制字。

在编码解码公共函数库内部，对BER，PER，TLV规则都分别实现了一套编码解码函数。编码解码库中为用户提供统一的编码解码函数接口。其实现原理是根据需解码的类型Ttype中的编码规则的记录，调用所对应的编码规则的编码解码函数进行编码解码。如对例子中的link-select-code信元进行解码时会调用PER规则的解码函数进行解码，而对circuit-identification-code进行解码时会调用BER规则的解码函数进行解码。解码进行到originating-point-code信元时又会自动调用TLV规则的信元进行解码。这样就实现多种编码解码规则在一个模块中的混用。同时又保证了出现新的编码解码规则时，扩充起来非常容易，如下图4所示。

与传统的实现方式相比，本发明的实现是将编译器和编解码进行了分离。这样，编译器和编解码相对独立，对于编解码的任何扩充，对于编译器不会产生任何影响。编译器将ASN.1的抽象描述，翻译成目标编程语言的抽象类型中间形式，用户将这个抽象类型中间形式进行实例化，形成抽象值中间形式。

由于抽象值中间形式是抽象类型的中间形式具有相同的树状结构层次。同时值(树)的每一个节点和类型(树)中的每一个节点一一对应，值树中的每一个节点都是相应类型树节点的实例化。正是有这样的关系，所有编解码函数的统一接口中，不需要说明抽象类型中间形式，因为通过抽象值中间形式，可以引用到相应的抽象类型中间形式。

但是对于解码过程来说，它是根据码流重新构造抽象值中间形式，也就是抽象值树的。这样，在解码函数的统一接口中必须说明抽象类型中间形式作为解码的依据。在后面的描述中，抽象值中间形式和抽象值树具有相同意义，抽象类型中间形式和抽象类型树具有相同意义。

编码函数的统一接口由五个参数给出：一个用于存储结果码流的缓冲区指针；表示缓冲区存储能力的缓冲区大小；表示本次编码起始位置(相对于缓冲区起始位置)；返回给用户的实际编码长度；代表抽象数据的抽象值树指针。

解码函数的统一接口由六个参数构成：一个存储这待解码码流的缓冲区指针；码流长度；表示本次解码开始的起始位置(相对于缓冲区的起始位置)；返回给用户的解码长度；表示解码依据的抽象类型树指针，它可以是总体抽象类型树的一个子树；最后是返回给用户的表示解码结果的抽象值树。

整个编解码过程的核心是编解码引擎，它本质上是一个调度器，调度的依据是由的ASN编译器产生的抽象类型中间形式(抽象类型树)。抽象类型树中包含有编码控制信息，这个控制信息由用户在书写ASN描述文件时指定。依赖于这些编解码控制信息，编解码引擎一方面完成用户指定的编解码控制，一方面调用编解码库中具体的编解码函数，完成编解码。在完成了编解码以后，编解码引擎检查用户有没有嵌入实现信元间约束关系的目标语言程序代码。如果有，运行用户定义程序，完成自定义约束限制。这样，编解码引擎就有四项主要的任务：初始化引擎，创建用户嵌入目标程序代码的运行环境；搜索合适的编码函数，完成编码；检索合适的解码函数，完成解码；为每一个抽象值节点，查找并运行用户嵌入代码。

编码时，用户通过API函数向编解码模块发出编码请求。API编码函数获取用户提供的抽象值树，接着为结果码流分配一个数据缓冲区。在准备好编码相对位置和存储实际编码长度的参数以及抽象值树以后，将控制权交给编解码引擎。编解码引擎，针对于抽象值的每一个节点，引用和它对应的抽象类型节点，取它的编码控制，进行分析，设置了各种编码控制参数后，根据编码控制中的编码指示，从编解码库(PER库、BER库、TLV库等等)中获取合适的编解码函数进行编码。由于抽象值从本质上是树状的结构，所以搜索引擎会根据这个特点，按照编解码控制的指示，递规调用各个编解码函数，完成整个消息的编码。

解码时，用户通过API函数向编解码模块发出解码请求。API解码函数根据用户提供的协议名，搜索协议数据库，找到需要解码码流的抽象类型树。然后准备好其他的解码标准接口参数，最后将控制权交给解码引擎。解码引擎根据抽象类型树的说明，提取编码控制，设置完相应的控制参数，依据类型树，递规调用相应解码库中的解码函数，完成整个码流的解码工作。然后将实际解码长度和反映解码结果的抽象值树返回给用户。

编解码引擎在工作前，总是先初始化编解码引擎。这个初始化工作，主要完成用户自定义导出编码的存储空间的分配工作，这样，便于以后编解码引擎执行相应的导入导出以及函数关系式的运行工作。初始化工作，在每一API编解码中只进行一次。编解码引擎在递规编解码时，总是先完成上面的编编码或者解码过程，然后执行抽象类型树用户自定义的编解码控制程序。当编解码引擎完成整个的编解码过程后，将控制权重新交给编解码的API函数，最终返回到用户程序中执行。

首先编译器将ASN描述文件编译成ASN抽象类型的中间形式(目标语言的抽象形式TType和少量值TValue)。这种形式对所有的ASN类型来说，形式上完全相同。同时编译器还为缺省值、对象标识符等等在ASN描述文件中存在的值，编译抽象值的中间形式(目标语言的抽象形式形式TValue)，然后编译器将此时存在的TType和TValue关联起来。但是此时的抽象类型中间形式(TType)在概念上仅仅是ASN抽象描述的目标语言版本，还不是实实在在运用到实际应用中的形式。为了能从这种消息模板格式的描述中得到消息，就必须对这个ASN抽象类型的中间格式进行数据实例化。完成数据实例化的任务是由抽象类型实例化模块完成。用户通过这个模块可以完成消息的制作，而它加工后的结果就是抽象值的中间形式。这种中间形式在构成上也是所有类型都是一样的。

编解码模块的编码过程是这样的。抽象类型实例化模块完成TValue构造的过程，同时也完成抽象值TValue(树)与抽象类型TType(树)的匹配工作。这个匹配过程保证TValue(树)中的每一个节点与TType(树)中的相应节点关联，即每一个值节点均有一个类型节点与之对应。这样处理以后，所有编码函数的参数就变得极为简单，只需四个参数：一个TValue抽象值(树)的指针，一个编码缓冲区，编码的起始位置，和编码缓冲的大小。由于所有的编码函数都是这样统一的接口，所以就可以非常独立地为每一个ASN抽象类型实现一个特定编码规则的编码函数。也就是对于BER，为每一个ASN抽象类型实现个BER编码函数，对于PER，为每一个抽象类型实现一个编码函数，当然也可以为其他如TLV(自创的编码规则)、XER(XML编码规则)创建编码函数。每一套编码规则模块的建立都不会影响其他现有的编码模块，而且只要的编码引擎能够通过编码控制找到相应的编码规则模块即可。编码模块中的编码引擎，通过编码控制的指导，递规调用相应编码规则模块中相应的ASN抽象类型的编码函数，完成编码过程。

解码过程和编码过程类似。它的解码函数针对每一个编码规则为每一个ASN抽象类型实现一个解码函数。而且所有解码函数的参数完全一样：一个表示码流类型的TType类型，一个用来存储消息实例的TValue，一个包含由码流的缓冲区，一个输出给用户的实际解码长度，和指示码流缓冲区大小的参数。依赖于TType中的编码控制，解码引擎，搜索相应ASN抽象类型的解码函数，完成本抽象类型的解码，将解码后的数据存储到TValue中。

从上述描述可知：

为T部分引入LEN控制项，用来指定T部分的长度。T部分使用这个长度进行编码，它可以取这个比特长度所能表示的所有的值，从而突破一个字节(8个比特)只能表示0-30的限制。

协议中每一个组成部分都可以指定它们的总体编码控制，所以，可以实现BER、PER、SCCP、TLV、TV、V、LV、LTV、T等等混合编码，大大增加编码的灵活性。因为进行总体编码控制以后，可以对SCCP进行单独的编码，所以可以完成SCCP特殊需求编码。同时T、L、V的编码控制的任意取舍性，可以满足用户可以只需要TLV三者中的一个、两个、或三者都有的动态组合编码。PER通过它自己的编码控制可以完成PER的对齐、非对齐编码，通过为不同的部分指定不同的PER对齐方式，甚至可以实现PER不同对齐类型的混合编码。

同时每一个部分都有ENDIAN编码控制，因此可以实现混合的大小端控制。BER的标识符部分、长度部分、内容部分的对齐、大小端、编码位数控制、长度域编码含义设置、长度域数值尺度等等控制功能可以通过设置各个控制项来完成。

最后，由于在协议描述可以添加C语言函数控制的控制项，这样，可以将成分之间的关系通过C语言的关系表达式进行描述，从而完成成分之间的约束控制的功能。每一个值都可以通过EXPORT进行输出，然后调用EMBED C中函数进行处理，最后可以通过IMPORT设置到值中，这样可以通过一个或者多个已知值计算相关值。

下面结合具体实例对解码进行说明：

参阅图6所示，通信设备A与设备B和设备C相连，设备A和B之间按照通信协议Protocol AB进行通信，设备A和C之间按照通信协议Protocol AC进行通信。消息解释过程如下：

1、在ASN.1文本中加入编码解码控制字描述协议AB和协议AC的消息的结构。

利用编译器将ASN.1文本信息转换成解码库函数可以识别的协议消息结构描述信息(协议动态库)：ab.dll，ac.dll

2、在使用时，捕获设备A、B之间和设备A、C之间通信的消息码流，将消息码流和其对应的协议动态库传递给消息解释器；

3、消息解释器利用公共的解码函数库，按照协议动态库中定义的消息结构对消息码流进行解码，构成一个解码后的消息值树。

4、为了方便人阅读消息的信息，消息解释器按照值树上各个节点的类型输出相应的字符串，解释器遍历值树的每个节点，从而把整个消息的内容生成具有层次结构的格式化文本并输出；为了图形化的观察消息，分析输出的格式化文本流，形成解释关系树并将该关系树和消息码流以图形化的方式显示出来。

如，协议描述如下：

　　UINT8 ∷＝＜V，V|LEN-8＞INTEGER(0..255)

　　INT8  ∷＝＜V，V|LEN-8＞INTEGER(-128..127)

　　UINT16∷＝＜V，V|LEN-16＞INTEGER(0..65535)

　　Msg∷＝＜V＞SEQUENCE

　　{

　　  a1 INT8，

　　  b1 Strua

　　}

　　Strua∷＝＜V＞SEQUENCE

　　{

　　  a UINT8，

　　  b UINT16

　　}

转换后的协议动态库中含有的协议的消息结构是一个记录协议中各种类型定义的一个表格和一个反映协议中各种类型的相互关系和协议中消息的组成关系的一棵协议消息的类型树，参阅图7和下表所示。

类型	类型信息	编码解码控制字	约束	其他
类型	类型信息	编码解码控制字	约束	其他	INT8	由基本类型INTEGER生成	V，V\|LEN-8	0--255

UINT8	由基本类型INTEGER生成	V，V\|LEN-8	-128-127
UINT8	由基本类型INTEGER生成	V，V\|LEN-8	-128-127	UINT16	由基本类型INTEGER生成	V，V\|LEN-16	0--65535
Msg	复合类型由{UINT8 UNIT16}两个类型生成	V	无	UINT16	由基本类型INTEGER生成	V，V\|LEN-16	0--65535
Msg	复合类型由{UINT8 UNIT16}两个类型生成	V	无	Strua	复合类型由{INT8 Strua}两个类型生成	V	无

以上面的结构为例子，码流为：0x80 0xf5 0x00 0xF4，协议为ab，参阅图7、图8，解码过程如下：

1、装入协议动态库，找到协议动态库中记录的消息的根节点、从根节点开始构造解码后消息的值树。

消息解释器将协议ab.dll装入到内存中，协议ab的消息的结构和结构中所用到的各种类型定义的信息就放到内存中，可以查询到。

2、根据节点编码解码控制字(BER，PER，TLV)以及该组合类型的子类型，往其儿子节点或者孙子节点中查找到第一个类型是基本类型的节点。

从ab.dll中发现协议的消息的根节点是Msg，其是符合类型，编码控制字是V。根据TLV的解码规则，V复合类型节点本身不产生码流，因此可以在编码产生的值树上直接根据类型树的信息构造出这个根节点，然后在从码流中取信息对应该对其儿子进行解码，第一个儿子是a1，类型是INT8，从类型表中可以查到是INT8就是INTERGER，编码控制字为V，V|LEN-8，约束是-128..127，可以对a1进行解码。

3、调用该基本类型的对应的解码函数，解码成该信元的值树上的一个节点，并记录输入码流已经解码到的位置。

从LEN-8控制字得知，这个信元编码后占用一个字节，因此从码流中取出一个字节0X80，做过a1这个信元的值，并记录解码已经进行到码流的第二个字节。

4、从上到下、从左到右递归着依次完成值树上各个节点的构造。已经解码的码流长度，不断增加。到解码完成时，已经解码的码流长度正好等于码流长度，整棵值树构造完成。

依次下去解出信元b1，a，b，逐步生成了消息的值树，就完成了消息的解码过程。

解码后的消息如下：

Msg

0> 80 10000000 ....a1：-0x80(-128)

....b1

1> F5 11110101 ......a：0xf5(245)

2> 00 00000000

3> F4 11110100 ......b：0xf4(244)

本发明的接口消息解释器是在协议通用描述的基础上工作的，这样当协议变化的时候，只要更改协议的描述，而不必去修改接口消息解释器本身的程序，使其具有最大限度的通用性。由于ASN.1的广泛使用，很多标准接口协议都采用ASN.1语言做了描述，可以节省大量协议描述工作量。为了解决不是采用ASN.1制定的协议的描述问题，在ASN.1的上扩展了TLV的编码控制字，用一种可扩展的记法来表示协议的，在描述文件中可嵌入C代码对码流进行处理，使得用ASN.1来描述这些协议成为可能，并且较为方便。本发明解决了已有消息解释器通用性差，扩展较困难的缺点，在描述文件上采用ASN.1标准，并对ASN.1标准所支持的编码解码方式进行了扩充使其可以很好的支持不是采用ASN.1描述消息结构的协议，使得此方案的应用范围更广。

Claims

1、一种通用消息解释器的实现方法，其特征在于包括步骤：

A、从通讯接口获取消息码流；

2、如权利要求1所述的方法，其特征在于，所述的方法还包括：D：将字符串生成具有层次结构的格式化文本流后输出。

3、如权利要求2所述的方法，其特征在于，所述的方法还包括：E：通过图形界面(GUI)分析输出的文本流，形成解释关系树，并在该图形界面上将关系树和消息码流显示出来。

4、如权利要求1、2或3所述的方法，其特征在于，步骤B中解码包括步骤：

从协议消息结构描述信息中找到消息的根节点，并从根节点开始构造解码后消息的值树；

根据节点编码解码控制字以及该组合类型的子类型，往其儿子节点或者孙子节点中查找到第一个类型是基本类型的节点；

调用该基本类型的编解码控制字对应的解码函数，解码成该信元的值树上的一个节点，并记录输入码流已经解码到的位置；

依次完成值树上各个节点的构造，构成整棵值树。

5、如权利要求1所述的方法，其特征在于，在进行步骤A之前，还包括步骤：将抽象语法记号1(ASN.1)与编码解码控制字结合对需要解释的协议进行描述并形成协议消息结构描述信息，再将该描述信息生成协议动态库供调用。

6、如权利要求5所述的方法，其特征在于，所述编码解码控制字添加在ASN.1文本中的类型定义处。

7、如权利要求5或6所述的方法，所述的编码解码控制字可为BER、PER和TLV之一，或者为BER、PER和TLV的多项组合。

8、如权利要求5或6所述的方法，其特征在于，所述ASN.1文本中嵌入有实现信元间约束关系的C语言程序并包含在生成的协议动态库中；当完成解码后执行该程序，完成自定义约束限制。