WO2005057873A1

WO2005057873A1 - The implementing method of universal message explainer

Info

Publication number: WO2005057873A1
Application number: PCT/CN2004/001424
Authority: WO
Inventors: Ni Huang; Hao Wang
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2003-12-12
Filing date: 2004-12-07
Publication date: 2005-06-23
Also published as: CN100505743C; CN1627757A

Abstract

The invention discloses a method of decoding and explaining communication interface message, the invention is: first, depicting the message structure in the communication protocol by combining the ASN.1 and encoding decoding control word notation, generating protocol dynamic library; sending the message code flow and protocol dynamic library corresponding to message code flow to message explamer, the message explamer decodes by using function in the public decode function library, in course of decoding, searching whether the type, encode decode control work of cell in the protocol dynamic library is BER, PER or TLV, and using corresponding decoding function to decode and generating message value tree according the celi control word representation; ransacking each node of the value tree, thereby generating formatting text having layered structure and outputting; analyzing output formatting text flow, generating explain relation tree and displaying the relation tree and message code flow in manner of graph.

Description

Implementation method of universal message interpreter

Technical field

The present invention relates to communication technologies, and in particular, to a method for implementing a universal message interpreter in a communication system.

Background technique

Protocols in the field of communications or telecommunications are generally more complex. In the maintenance and testing of communication systems, it is necessary to understand the interaction on the communication interface. Directly observing the binary code stream on the communication interface is often difficult to know its meaning, so the message interpretation function is generally provided on the network management system or signaling tester of the communication system. Form and explain its meaning, as shown in Figure 1.

The original message interpreters were specialized. A message interpreter can only interpret one protocol or similar protocols. With the gradual increase of communication protocols, writing a new interpreter for each protocol appears to be inefficient, and modification and upgrade of the protocol will also lead to modification of the message interpreter.

Before the advent of ASN.1, most message interpreters used a self-defined description language to describe the protocol. With the increasing adoption of ASN.1 in telecommunication protocols, message interpreters have become a natural choice based on ASN.1.

The key technologies of the message interpreter are the analysis and decoding functions of the message, and the data expression ability of the descriptive language.

With the development of information technology, many communication protocols have appeared in the field of telecommunications and computer technology. The purpose of these agreements is to enable the communicating parties to standardize their activities. The agreement guarantees a clear and consistent understanding of the activity.

Descriptions of such protocols were previously provided to users in a standard format in a textual format. Through such protocol text and the diagrams contained in the text, users can clearly understand the interactive process of protocol communication, and the protocol data type and protocol data format used in the interactive process. Although these protocol data types and protocol data formats allow users to clearly understand the data form and content of communication between two or more communication parties, it is difficult for users to use an effective Simple mechanism to check and verify this data. Even though users have developed the corresponding technology spontaneously in order to solve the problems in the actual project, the lack of a unified standard for the use of technology makes interaction between different users more difficult. Therefore, the International Telecommunication Union (ITU-T) proposed a standard protocol data description abstract notation and an abstract protocol data transmission expression method. This is Abstract Syntax Notation One (ASN.1-Abstract Syntax Notation One).

ASN explained the protocol data from two aspects. One aspect is the abstract representation of protocol data, which is described by X.680, X.681, X.682, and X.683, respectively. X.680 specifies the basic techniques of ASN. It clearly states the notation of basic types, the construction method of basic types and composite types, the notation of composite types and the notation of simple type constraints. X.681 describes the construction method of the class, the notation of the class, the notation of the object, the notation of the set of objects, the notation of the value and the set of values. It also gives a more friendly representation when type objects. X.682 focuses on the notation of high-level constraints on types and classes. Its purpose is to minimize the coverage of the values and objects of the original type and the original class. The purpose is to specify the original types and classes. X.683 gives some standard notation for parameterization, so that the protocol description can be more abstract, and the scope and generality of the protocol description can be improved.

Another aspect of ASN.1 is the method of specifying the transmission of abstract protocol data. The essence here includes two aspects, which correspond to the sender and receiver of the communication, respectively. For the sender, it specifies the encoding method of the transmission code stream; for the receiver, it specifies how to decode the transmission code stream into abstract data. In the field of telecommunications, there are currently two widely used ASN encoding methods: one is BER (basic encoding rule) and PER (compression encoding rule). These two coding rules are given in ITU standards X.690 and X.691, respectively. Most protocols developed with ASN.1 use BER or PER coding.

The format of the BER code is relatively simple. It is stipulated that each code usually consists of three parts: identifier, length and content. As shown below:

The BER identifier is determined by the type itself or specified by the user. Identifiers usually have single-byte and multi-byte encodings. The single-byte encoding is shown in the figure:

The category number of the identifier occupies two Bits and is given by the BER standard. 00 indicates the Universal class and ¹ J, 01 indicates the Application class, 10 indicates the Context-specific class, and 11 indicates the Private class. Encoding method. It is 1 when the following content encoding is encoded using the construction method, otherwise it is 0. The identifier can range from 0-30.

When the identifier value exceeds 30, the above identifier encoding needs to be extended. In the extended method, the identifier value part is all set to 1, which is 11111. The extension byte encodes the actual identifier value, but only the lower 7 bits of a byte are used for encoding, and the 8th bit is used to indicate whether the extension byte ends. This bit is set to indicate that there is an extended byte after it; set to 0 indicates that this byte is the last byte of the extension. During encoding, the first extended byte encodes the highest bit code of the identifier value, and the subsequent extended byte encodes the next lowest code of the identifier value, until the last extended byte encodes the lowest bit of the code. The number of extended bytes is the minimum number of bytes for the encoding identifier value.

The BER length is used to encode the actual number of bytes occupied by the content portion. There are two types of length encoding: definite format and indeterminate format. Make sure there are two formats, long format and short format. The short format is used to encode the length value of 127 or less. Long-form coded encodings whose length values exceed 127.

The short format length encoding occupies one byte. The lower 7 bits are used for encoding, the most significant bit is not used and is set to 0.

Long format length encoding occupies multiple bytes.笫 A byte is the initial byte. Its highest bit (eighth bit) is set to 1, and the lower 7 bits are used to indicate the number of bytes used for length encoding. The subsequent bytes are used to encode the actual length. When encoding, if the encoding byte exceeds 1 byte, the 8 bits of the first byte represent the highest weight bits of the length encoding, the subsequent bytes represent the next highest weight bits, and so on until the last byte Represents the least weighted bit of the length encoding. However, only 7 for the initial byte is used to indicate the number of bytes occupied by the length encoding, so it limits the actual number of bytes occupied by the long format length encoding to not exceed 127 bytes.

The indeterminate format is usually used by the user when the encoding cannot determine the length of the content part in advance. The length part takes one byte, and the value of this byte is set to 0x80 (binary 10000000). Then immediately after it code the content part. After encoding the entire content part, two bytes with a value of 0 are appended at the end. Call these two bytes EOC (End Of Contents) ₀ so that the actual length of the content part is the number of bytes occupied by the encoded stream between 0x80 and E0C.

The BER content is used to encode the ASN abstract value. These values can be of any type specified in ASN.1. The encoding of each type value is determined by the type itself, but its format is composed of the three parts described above, namely the identifier part, the length part, and the content part.

The protocol data of a protocol can be described using the ASN.1 abstract class or abstract type. A template representing the protocol data is formed. In the description of actual protocol data, a protocol template starts with a composite type, and this composite type is called a Gen type in the following description. If this protocol data template is instantiated using abstract data, a communication message often used in communication protocols is formed.

If in the engineering practice, it is necessary to perform BER encoding on the communication message, then perform BER encoding on each abstract value constituting the communication message. How each abstract value is encoded depends entirely on the ASN type corresponding to this abstract value. Each type of encoding method is specified by ITU-T standard X.690. However, the encoding format consists of the three parts described above.

It can be known from this that BER coding technology starts coding from a root-type abstract data. First encode its identifier part, then the length part, then the content part. The content part encodes its various components according to the rules of the root type. For each component, the identifier part is still encoded first, then the length part, and finally the content part. If the components are still abstract data of the composite type, the coding process continues until the entire coding is completed.

In terms of form, BER coding is to start from the root type, and repeat the identifier, length, and content, and then the identifier, length, and content are nested in the content, and then the indicator, length, and content are nested in the content ... ., Until the end of the simple type identifier, length, content. Then backtrack, then nest, backtrack ... Until the entire root type abstract value components have become the form of identifier, length, content.

On the basis of BER, a PER coding scheme is proposed. It solves the shortcomings of the BER code stream being too long, and also largely gets rid of the impact of the identifier (TAG). Most of the type encoding does not depend on TAG, and TAG is not encoded when encoding.

The general idea of PER coding is this: The coding mode of identifier, length, and content is no longer used. When encoding, you only care about this part of the content, and try to compress the encoding as much as possible to minimize the number of bits in the resulting code stream.

The method of compression is to use the least number of bits to convey the information on the basis of effectively expressing the information. For example, in BER, the Boolean type requires three fields of identifier, length, and content, that is, three bytes to encode, and the resulting code stream has 24 bits. In PER coding, a Boolean type, which has only two values, can be completed by only one bit. Because a type is essentially a collection of values. The various types of constraints are to narrow the scope of this set, so that it can more accurately express the required information. Compression coding (PER) is based on this essence. For these value sets (including types and constraint types), instead of using the original value of each element of the original value set, the offset of the set element relative to the small value boundary of the set is used. coding. When both the upper and lower bounds of the value set exist, and in an appropriate range, such as 64K, each value in the value set is encoded using the number of bits that represent the least amount of this range, taking into account the appropriate increase in transmission requirements This number of bits is preferably a multiple of eight. Of course, sometimes the type does not give a specific upper and lower bound on the set value. Special treatment is given to these two special cases.

For no lower bound and no upper bound, the offset of the lower bound is still used to encode the value, but the number of bits used for encoding is a multiple of at least 8 bits required to encode this offset.

For the case where there is neither an upper bound nor a lower bound, the value of the element itself in the value set is encoded. Similarly, the number of bits required for encoding is a multiple of at least 8 bits required to encode this value, which is the same as the content part of the BER. .

For the case where there is only an upper bound and no lower bound, the coding depends on the specific situation. For things like strings, upper and lower bounds of sequences, and so on. No lower bound is equivalent to zero, so use zero as the lower bound. Otherwise, when the lower bound cannot be determined in actual application, it is treated the same as the case where there is neither the upper bound nor the lower bound.

In PER encoding, each type of encoding also has an optional length part. But it only needs to be coded into the code stream to indicate the length of the value encoding only when the exact length of the value encoding cannot be determined through constraints and actual encoding rules.

Similar to the length part, PER also has a part similar to the BER identifier, but here is a new name called preamble (preamble d, its appearance is still optional, only when some component types of the composite type are optional) The header is used only if it has a default value, or if the composite type has special extended attributes, and it is encoded.

In the prior art, there are two main methods for message interpretation of a communication interface:

Method 1: Responsible for the decoding of a protocol through a dedicated piece of program code; however, this method has the following disadvantages:

1. High requirements for users. Users not only need to understand the details of the protocol, but also need to implement the analysis process of all messages in the protocol. 2. Maintenance is difficult. Modification of the protocol requires re-modification and code compilation.

3. Poor scalability. New protocols need to be written.

Method 2: A message interpreter using a custom description language provides a protocol description description file for each supported protocol. The description language uses the standard ASN.1, and the encoding method uses basic encoding rules (BER) and compression encoding rules ( PER), the message interpreter only needs to write a new protocol description file when adding support for a new protocol. Although the second method is adopted to make the common part of the message interpreter reusable, it still has the following disadvantages:

1. The data description ability of the custom description language is limited, and it cannot directly handle a large number of protocols that provide ASN.1 descriptions. It needs to provide additional conversion functions to assist implementation.

2. The custom description language requires extra learning time, and lacks materials and development tools.

3. The description language adopts the standard ASN.1. Currently, only two commonly used encoding methods: BER and PER are used in the ASN.1 standard. Pure ASN.1 cannot decode the message stream without the ASN.1 protocol. Poor sex.

Summary of the invention

An object of the present invention is to provide a method for implementing a universal message interpreter, so as to solve the problem of poor generality and scalability in the prior art.

To solve the above problems, the present invention provides the following technical solutions:.

A method for decoding a communication interface message includes the following steps:

A. Obtain the message code stream from the communication interface;

B. Call the protocol message structure description information corresponding to the protocol used by the message code stream, and call the corresponding decoding function to decode the message code stream segment by segment according to the encoding and decoding control word of each cell in the description information to form the message value Tree, each node of the message value tree corresponds to one cell of the message, where:

If the protocol codec control word of a cell is expressed as a basic encoding rule (BER), then call

BER decoding function to decode;

If the codec control word of the cell is expressed as a compression coding rule (PER), then the decoding function of the PER is called for decoding; If the codec control word of the cell is represented as type-length-value notation (TLV), then the decoding function of the TLV is called for decoding;

If the codec control word of a cell is expressed as a combination of multiple items in BER, PER, and TLV, the corresponding decoding function is called for decoding;

C. Traverse the message value tree, and output a decoded character string for each cell according to its format. According to the above method:

It also includes the steps: Output the string into hierarchical formatted text. The output text stream is analyzed through a graphical interface (GUI) to form an explanatory relation tree, and the relation tree and the message code stream are displayed on the graphical interface.

Before performing step A, the abstract syntax mark 1 (ASN.1) is combined with the encoding and decoding control word to describe the protocol to be interpreted and form protocol message structure description information, and then generate the protocol dynamic library for the description information to be called; The codec control word is added to the type definition in the ASN.1 text.

The encoding and decoding control word may be one of BER, PER, and TLV, or multiple combinations of BER, PER, and TLV.

A C language program that implements the constraint relationship between cells is embedded in the ASN.1 text and is included in the generated protocol dynamic library; the program is executed after decoding is completed to complete the custom constraint limit.

The invention has the following beneficial effects:

1. It greatly reduces the development workload of telecommunication network management systems, telecommunication system test tools, and test instruments supporting multiple protocol interpretations.

2. The versatility and scalability of the message interpreter have been improved. The GUI and the encoding and decoding engine can be kept stable. To add a protocol support, you only need to provide the ASN.1 file corresponding to the protocol.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a schematic diagram of the interface message interpretation result;

2A is a block diagram of a message interpreter system according to the present invention;

FIG. 2B is a main flowchart of the present invention;

FIG. 3 is a schematic diagram showing a graphic interface displaying a message code stream and interpreting a message; FIG.

FIG. 4 is a schematic diagram of encoding and decoding; FIG. 5 is a schematic diagram of communication equipment networking;

FIG. 6 is a schematic diagram of a description structure of a protocol message;

Figure 7 is a protocol message type tree;

Figure 8 is a decoding flowchart.

detailed description

In the present invention, a type-length-value (TLV) coding control method is adopted to solve a protocol that is not defined by ASN.1 using ASN.1, and the TLV coding control method is described as follows:

T: Control of type identification, similar to the identifier (TAG) in BER, but its type value has nothing to do with BER type value.

L: Represents the control of the length part, similar to the length in the BER, but not only the length of the content part, but also various length-related coding controls.

V: Indicates the encoding control of the value part. This part has various control settings for the BER content part and the PER compression encoding method and value part.

The form of TLV code control provided to users is as follows:

"<Overall coding control, sub-control>"

Enclose the entire control with "<>" and separate each control with ",".

General Encoding Control (General Control): Gives the overall encoding rules and encoding constraints and controls. The expression in this section is "A | Bab ,,". The value of A can be BER, PER, SCCP, T, TV, V, TLV, LTV, LV, etc. The value of B is various related to encoding. Controls and constraints. Its values can be big and small: ENDIAN, alignment: BOUNDARY, PER alignment: PERALIGN, construction or tube coding: CONSTRUCTED / SIMPLE. A and b are optional parameters. For example, alignment requires a parameter Indicates whether to perform alignment. <TV | BOUNDARY-ALIGN> represents TV-type encoding, and the alignment is adopted during encoding.

Subcontrol: Further explanation of the overall control. The representation in this section is the same as the representation of the overall coding control. "The wide left side represents the control name, and the right side of T is separated by"-". The first part represents the control item, and the second and subsequent parts represent the first parameter of the control item, the second parameter, in that order. By analogy.

For example, before a type description in the protocol, you see the following form:

<TLV | E DIAN-BIG, T | LEN-8, L | LEN-16 | SCALE-3, V | CHECKSUM-XOR> This means that the modified type will be encoded using TLV rules in the future. The T part uses 8 bits for encoding; the L part uses 16 bits for encoding, and its value scale is 3 bits, that is, if the value of the L part is 5, the total bits occupied by the length part are 5x3 = 15 bits After encoding this type of value, you need to use XOR to perform face detection and calculation.

The control items of each part of TLV are as follows:

Part T:

The LEN control item takes a parameter to indicate how many bits the T part uses for encoding. Such as TLEN-8.

The ENDIAN control item has a parameter with values BIG and LITTLE, indicating whether this part is big-endian or little-endian.

Part L:

The LEN control item takes a parameter to indicate how many bits the L part uses for encoding. The ENDIAN control item has a parameter with values BIG and LITTLE, indicating whether this part is big-endian or little-endian.

SCALE control with a parameter specifying the scale of the L-part values. This breaks the limit of the L-part value in bytes. The number of parameters is the number of bits on the L scale. For example, SCALE-2, the value of L part is 3, so its meaning is 3 2 bits. The parameter can also take special values, such as CMPNT, which indicates that the length scale is a logical unit of the current type encoding. For example, using it to modify a character string means that the number of characters is taken on a scale, regardless of how many bits the character itself is encoded with.

The ADD / SUB control item takes a parameter, which indicates that the value of L should increase / decrease the number given by the parameter.

The SELF control has no parameters, indicating that the value of L needs to increase the number of bytes occupied by the L part itself.

The SCCPLEN control item has no parameters, which means that when the length is less than 255, one byte is used for encoding. When it is greater than 255, three bytes are used for encoding, the first byte is encoded as Oxff, and the next two bytes are used for length encoding.

The TO control item takes two parameters, the first parameter represents the control sub-item, and the second represents the length that needs to be filled when completing. There are three control items: VALIGN, ALIGN, value control. VALIGN indicates that the value encoding is aligned according to its scale. The shortcomings are complemented by the bit value given by the parameter. The ALIGN value is encoded to the byte boundary, and the insufficient part is completed using the bit value given by the parameter. The value control item is relatively special. Its form is TO-16-0, which indicates that the encoding of the value needs to occupy a fixed 16 bytes. If the encoding is less than 16 bytes, the value is less than 0 to 16 bytes.

Part V:

The LEN control item takes a parameter to indicate how many bits the V part uses for encoding.

Dummy control with two parameters. This parameter mainly deals with the problem that one component encoding is divided by multiple components in the composite type. The first parameter indicates the number of bits of the first part of the code that is divided, and the second parameter indicates the number of components of the original code.

EBIT control with one parameter. When the coded code stream has multiple bytes, the leftmost bit of each byte determines whether the next byte represents the code stream. The leftmost bit is set with the given parameter, which indicates that the following bytes also belong to the code stream. If it is the last byte, the left bit sets the value of the inverted parameter.

DN control with one parameter. The BCD of the control telephone number indicates that if the encoding is not on a byte boundary, the use parameter is insufficient to the byte boundary.

The M1 control item encodes a bit parity bit according to the number of phone numbers before encoding the phone number. When the phone number is even, it is set to 0, otherwise it is set to 1. When the entire encoding is not on a byte boundary, the value given using the parameter is not sufficient on the byte boundary.

TRAIL control with one parameter. After encoding, use the value specified by the parameter as the encoding terminator.

The PERALIGN control has no parameters, indicating that the codes are aligned according to the alignment of the PER.

CHOICE type control:

V itself modifies the control effect of the CHOICE type, using the index to select the components of the CHOICE. The TV itself modifies the control of the CHOICE type, using the tag value to select the CHOICE component.

WHEN control with a conditional expression that calculates the expression based on the value of a known component Expression, select the component whose expression is true.

The UNION control takes a parameter that controls the encoding length of the CHOICE component. The maximum length of the component type is used as the length of the entire encoding, which is similar to C language UNION. If the actual encoding is insufficient for the maximum length, the value given by the parameter is used to fill the maximum length.

Overall coding control:

ENDIAN control, with a parameter, the values are BIG and LITTLE, indicating whether it is big-endian or little-endian encoding.

BOUNDARY control, with a parameter, the values are ALIGN and NONALIGN, indicating whether the encoding starts from an entire byte boundary.

PERALIGN control: Takes a parameter with values of ALIGN and NONALIGN, indicating whether to perform encoding in PER alignment or encoding in non-alignment. Only valid for PER. It has no effect on other BER, TLV, SCCP, etc.

C language function control:

WHEN control: Modifies the component of the composite type, which is used to execute a C-style expression to complete the selection control.

EMBED EXEC control item: It is defined in any blank part described in the protocol ASN. The content is the embedded C language program or function library, which can be used in WHEN calculation expression.

EXPORT control: Outputs the value of the current component to an external C variable.

IMPORT control: The value of an external C variable is introduced into the current ASN description, which is used to dynamically calculate certain constraints.

Referring to FIG. 2, the message interpreter of the present invention is mainly composed of a codec engine and a graphical interface (GUI):

Encoding and decoding engine: Responsible for decoding the input code stream according to the selected protocol dynamic library, and constructing formatted text that outputs the interpretation information of the decoded message.

GUI: The main function is to analyze the formatted text, display the format of the message interpretation content, and complete the human-computer interaction function.

The main process of message interpreter decoding is as follows:

1. Obtain the protocol dynamic library corresponding to the protocol and the message code stream to be interpreted from the communication interface. Before interpreting the message stream, the user uses ASN.1 text to describe the protocol they need to interpret. The ASN.1 file is compiled into a C file by the ASN conversion program. The C file is compiled and linked into A protocol dynamic library of protocol characteristic information. For protocols not defined by ASN.1, the combination of ASN.1 and the aforementioned TLV coded control word is used for description.

The protocol dynamic library is composed of ASN.1 text input by the user, and contains information such as the structure information of all messages in the protocol, and the relationship between the cells.

The protocol used by the user to enter a message stream to be interpreted.

2. The encoding and decoding engine decodes the message stream to be interpreted according to the protocol dynamic library to form a message value tree. Each node on the tree is a cell of the message. Wherein during decoding: if the protocol codec control word of the cell is expressed as a basic coding rule (BER), then call

The decoding function of BE performs decoding; if the codec control word of the cell is expressed as a compression coding rule (PER), the decoding function of the PER is called for decoding; if the codec control word of the cell is expressed as type-length-value notation (TLV), calling the decoding function of the TLV for decoding; if the codec control word of the cell is expressed as a combination of multiple items in BER, PER, and TLV, the corresponding decoding functions are respectively called for decoding.

3. The encoding and decoding engine traverses the value tree to generate hierarchical formatted text;

Below is an example

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 mode connection

9> DO 1101—- T ciphering key sequence

--— 0000: 0, through Possible values for the ciphering key

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

11> 00 0-. Spare 1: 0x0 (0)

..revision level: 0, reserved for phase 1

..es ind: 0, controlled Early Classmark Sending option is

—- 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 notifications wanted

—0 fc: 0, the MS does not support the E GSM or R

GSM band

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. The GUI interface analyzes the output text stream of the codec engine and forms an interpretation relation tree, and displays this relation tree and code stream on the interface to complete the entire message interpretation process. The display interface is shown in Figure 3.

In the present invention, the ASN compiler supports encoding and decoding control such as TLV, and the encoding and decoding control words can be mixed with BER and PER ^. The standard ASN.1 specification only supports the use of BER or PER encoding rules for the entire file or module. The following is part of the ASN text of the ITU-T H.248 protocol. In practice, either the BER rule or the PER rule is used. As follows:

MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS :: = BEGIN

MegacoMessage :: = SEQUENCE

{

authHeader [0] IMPLICIT AuthenticationHeader

OPTIONAL,

mess [1] IMPLICIT Message

}

AuthenticationHeader: = SEQUENCE

{

secParmlndex [0] IMPLICIT S ecurityParmlndex,

seqNum [1] IMPLICIT SequenceNum, ad [2] IMPLICIT AuthData

}

SecurityParmlndex :: = OCTET STRING (SIZE (4)) 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

{

messageEiTor [0] IMPLICIT ErrorDescriptor, transactions [1] EXPLICIT SEQUENCE OF

Transaction

},

}

Obviously, using only two rules, BER and PER, cannot meet various coding and decoding requirements in practical applications.

By adding parentheses "<>" in each type definition in the ASN text, put the encoding and decoding control word you want in the brackets. Through automatic inheritance of encoding control words, if you want to use a uniform one in a module This type of encoding rules only needs to specify the encoding rules in its parent type, and the child type will automatically inherit the encoding rules of the parent type. The specified encoding rules displayed at the child type will override the inherited encoding rules, so that the user can specify Each type of encoding and decoding rules does not require major changes to the ASN syntax. The following is an example of specifying each type of encoding and decoding rules in ASN text, where the part in "<>" is the encoding and decoding control word . As follows:

Bitl: = <V, V | LEN- 1> INTEGER (0..1)

Bit2 :: = <V, V | LEN-2> INTEGER (0..3)

Short :: = <V, V | LEN- 16> INTEGER (0..0xf ff)

ThreeByte:: = <V, V | LEN-24> INTEGER (0..0xffffff)

INT :: = <V, V | LEN-32> INTEGER (0..0xffffffff) SevenByte :: = <V, V | LEN-56> INTEGER (O..Oxffffffffffffff)

HexString :: = VisibleString (FROM (48..57 | 65..70))-Ό '. · .'9', 'Α'. HexStringl :: = VisibleString (FROM (48..57))

Dtmfstring: "VisibleString (FROM (48..57 | 65..70))-Printablestring:: = <V, V | LEN-8> PrintableString

Valuea :: = Byte (OxAl)

Valuef :: = Bit4 (15)

, , , small ·!·

-Sytem Message

,

MsgEnter:-<V> SEQUENCE

{

mtpLeveBHead MTPLeveBHead,

label Label,

msg-type Msg-type

MTPLeveBHead :: = <V> SEQUENCE

{

servicelndicator <V ₅ V | LEN-4> ENUMERATED

{

isup (5)

}

, spare 1 Bit2

, networkIndicator <V, V | LEN-2> ENUMERATED

{

nationalNetwork (2)

} One 1.7—

}

Label :: = <V> SEQUENCE

{

destination-point-code <V ₅ V | LEN-24> INTEGER (0..0xFFFFFF),

originating-point-code <V, V | LEN-24> INTEGER (COxFFFFFF),

link-select-code <PER> INTEGER (0..0xFF), circuit-identification-code <BER> INTEGER (0..0xFFFF)

}

When the ASN compiler compiles ASN text, it generates a Ttype structure for each type. The Ttype structure contains the encoding and decoding control rules for each type. That is, the part in the "<>" in the ASN text in the above example can be BER, PER or custom TLV. The user does not display the defined type and will automatically calculate his codec control word based on the inheritance relationship.

Within the codec public function library, a set of codec functions are implemented for the BER, PER, and TLV rules. The codec library provides users with a unified codec function interface. Its implementation principle is to call the encoding and decoding function of the corresponding encoding rule for encoding and decoding according to the records of the encoding rules in the type Ttype to be decoded. For example, when decoding the link-select-code cell in the example, the decoding function of the PER rule is called to decode, and when the circuit-identification-code is decoded, the decoding function of the BER rule is called to decode. When the decoding reaches the originating-point-code cell, the cell of the TLV rule is automatically called for decoding. In this way, a variety of encoding and decoding rules are mixed in one module. At the same time, it ensures that when new coding and decoding rules appear, it is very easy to expand, as shown in Figure 4 below.

Compared with the traditional implementation, the implementation of the present invention separates the compiler and the codec. In this way, the compiler and codec are relatively independent, and any extension to the codec will not have any impact on the compiler. The compiler translates the abstract description of ASN.1 into the abstract type intermediate form of the target programming language, and the user instantiates this abstract type intermediate form to form an abstract value intermediate form. Because the intermediate form of the abstract value is the intermediate form of the abstract type, it has the same tree structure hierarchy. At the same time, each node of the value (tree) corresponds to each node of the type (tree), and each node in the value tree is an instantiation of a node of the corresponding type tree. It is because of this relationship that in the unified interface of all codec functions, there is no need to specify the abstract type intermediate form, because the abstract value intermediate form can refer to the corresponding abstract type intermediate form.

But for the decoding process, it reconstructs the intermediate form of the abstract value according to the code stream, that is, the abstract value tree. In this way, in the unified interface of the decoding function, the intermediate form of the abstract type must be specified as the basis for decoding. In the following description, the abstract value intermediate form and the abstract value tree have the same meaning, and the abstract type intermediate form and the abstract type tree have the same meaning.

The unified interface of the encoding function is given by five parameters: a buffer pointer for storing the result code stream; the buffer size indicating the buffer storage capacity; the starting position of the encoding (relative to the buffer Start position); the actual encoding length returned to the user; an abstract value tree pointer representing abstract data.

The unified interface of the decoding function is composed of six parameters: a buffer pointer that stores the stream to be decoded; the length of the stream; the starting position of the decoding start (relative to the starting position of the buffer); The decoding length of the user; an abstract type tree pointer representing the decoding basis, which can be a subtree of the overall abstract type tree; and finally, an abstract value tree representing the decoding result returned to the user.

The core of the entire codec process is the codec engine, which is essentially a scheduler, and the scheduling is based on the abstract type intermediate form (abstract type tree) generated by the ASN compiler. The abstract type tree contains encoding control information, which is specified by the user when writing the ASN description file. Depending on the codec control information, the codec engine completes the codec control specified by the user on the one hand, and calls the specific codec function in the codec library on the other hand to complete the codec. After the codec is completed, the codec engine checks whether the user has embedded the target language program code that implements the constraint relationship between the cells. If so, run the user-defined program to complete the custom constraint restrictions. In this way, the codec engine has four main tasks: initialize the engine, create a running environment in which the user embeds the target program code; search for a suitable encoding function to complete the encoding; retrieve a suitable decoding function, complete the decoding; for each abstract value node Find and run user embed code. When encoding, the user sends an encoding request to the codec module through an API function. The API encoding function obtains the abstract value tree provided by the user, and then allocates a data buffer for the resulting code stream. After preparing the encoding relative position and storing the parameters of the actual encoding length and the abstract value tree, control is passed to the codec engine. The codec engine refers to each node of the abstract value, references its corresponding abstract type node, takes its encoding control, analyzes it, and sets various encoding control parameters. Obtain appropriate 'codec functions in the decoding library (PER library, BER 庠, TLV library, etc.) for encoding. Because the abstract value is a tree-like structure in nature, the search engine will call each codec function recursively according to the instructions of the codec control to complete the encoding of the entire message.

When decoding, the user sends a decoding request to the codec module through the API function. The API decoding function searches the protocol database according to the protocol name provided by the user to find the abstract type tree that needs to be decoded. Then prepare other decoding standard interface parameters, and finally give control to the decoding engine. The decoding engine extracts the encoding control according to the description of the abstract type tree, sets the corresponding control parameters, and according to the type tree, calls the decoding function in the corresponding decoding library recursively to complete the decoding of the entire code stream. The actual decoded length and an abstract value tree reflecting the decoded result are then returned to the user.

Before the codec engine works, it always initializes the codec engine. This initialization work mainly completes the allocation of the storage space of the user-defined export encoding, so that it is convenient for the codec engine to perform the corresponding import and export and the operation of the functional relationship in the future. Initialization is performed only once in each API codec. The codec engine always completes the above encoding or decoding process when iterative encoding and decoding, and then executes the user-defined codec control program of the abstract type tree. After the codec engine completes the entire codec process, it returns control to the codec's API functions, and finally returns to the user program for execution.

First, the compiler compiles the ASN description file into an intermediate form of the ASN abstract type (the abstract form TType of the target language and a small number of values TValue). This form is exactly the same for all ASN types. At the same time, the compiler also compiles the intermediate form of the abstract value (the abstract form form of the target language TValue) for the values that exist in the ASN description file such as the default value, object identifier, and so on, and then the compiler types the TType and TValue that exist at this time. Connected. But at this time, the abstract type intermediate form (TType) is conceptually only the target language version of the ASN abstract description, and it is not a form that is actually applied to actual applications. In order to get from the description of this message template format To the message, data instantiation must be performed on the intermediate format of this ASN abstract type. The task of completing data instantiation is accomplished by the abstract type instantiation module. The user can complete the production of the message through this module, and the processed result is the intermediate form of the abstract value. This intermediate form is also structurally the same for all types.

The encoding process of the codec module is like this. The abstract type instantiation module completes the process of TValue construction, and also completes the matching of the abstract value TValue (tree) and the abstract type TType (tree). This matching process ensures that each node in the TValue (tree) is associated with the corresponding node in the TType (tree), that is, each value node has a type node corresponding to it. After processing in this way, the parameters of all encoding functions become extremely simple, requiring only four parameters: a pointer to the TValue abstract value (tree), an encoding buffer, the starting position of the encoding, and the size of the encoding buffer. Since all encoding functions are such a unified interface, it is possible to implement a specific encoding rule encoding function for each ASN abstract type very independently. That is, for BER, implement a BER encoding function for each ASN abstract type, and for PER, implement an encoding function for each abstract type. Of course, it can also be used for other such as TLV (original encoding rules), XER (XML encoding rules) ) Create an encoding function. The establishment of each set of encoding rule modules will not affect other existing encoding modules, and as long as the encoding engine can find the corresponding encoding rule module through encoding control. The coding engine in the coding module, through the guidance of coding control, recursively calls the coding function of the corresponding ASN abstract type in the corresponding coding rule module to complete the coding process.

The decoding process is similar to the encoding process. Its decoding function implements a decoding function for each ASN abstract type for each encoding rule. And the parameters of all decoding functions are exactly the same: a TType type that indicates the type of code stream, a TValue that stores the message instance, a buffer containing the code stream, an actual decoding length that is output to the user, and an indication of the code stream The parameter of the buffer size. Depending on the encoding control in the TType, the decoding engine searches for the decoding function of the corresponding ASN abstract type, completes the decoding of this abstract type, and stores the decoded data in TValue.

From the above description:

The LEN control is introduced for the T part to specify the length of the T part. Part T uses this length for encoding. It can take all the values that this bit length can represent, thus breaking the limit of one byte (8 bits) that can only represent 0-30.

Each component of the protocol can specify their overall encoding control, so, you can Realize mixed encoding of BER, PER, SCCP, TLV, TV, V, LV, LTV, T, etc., greatly increasing the flexibility of encoding. Because SCCP can be individually coded after overall coding control, SCCP special needs coding can be completed. At the same time, the arbitrary selection of the coding control of T, L, and V can meet the requirement that the user can only need one, two, or all three of the TLVs for dynamic combination coding. PER can perform alignment and non-alignment encoding of PER through its own encoding control. By specifying different PER alignment methods for different parts, PER can even achieve mixed encoding of different alignment types of PER.

At the same time, each part has ENDIAN encoding control, so it can realize mixed endianness control. Control functions such as the identifier part, length part, content part alignment, big and small end, encoding bit number control, length field encoding meaning setting, length field numerical scale, etc. can be completed by setting each control item.

Finally, since control items controlled by C language functions can be added to the protocol description, in this way, the relationship between components can be described by C language relational expressions, thereby completing the function of constraint control between components. Each value can be output through EXPORT, and then the function in EMBED C is called for processing. Finally, it can be set to the value through IMPORT, so that the relevant value can be calculated from one or more known values.

The following describes the decoding with specific examples:

Referring to FIG. 6, communication device A is connected to device B and device C, and communication between devices A and B is performed according to a communication protocol Protocol AB, and communication between devices A and C is performed according to a communication protocol Protocol AC. The message interpretation process is as follows:

1. Add encoding and decoding control words to the ASN.1 text to describe the message structure of the protocol AB and protocol AC.

Use the compiler to convert ASN.1 text information into protocol message structure description information (protocol dynamic library) that can be recognized by the decoding library function: ab.dll, ac.dll

2. When in use, capture the message code stream of communication between device people, B and devices A and C, and pass the message code stream and its corresponding protocol dynamic library to the message interpreter.

3. The message interpreter uses a common decoding function library to decode the message code stream according to the message structure defined in the protocol dynamic library to form a decoded message value tree.

4. In order to facilitate people to read the information of the message, the message interpreter follows the class of each node in the value tree. Type the corresponding string, and the interpreter traverses each node of the value tree, so as to generate and output the formatted text with hierarchical structure for the entire message content; in order to observe the message graphically, analyze the output formatted text stream to form Interpret the relationship tree and graphically display the relationship tree and message code stream.

For example, the protocol is described as follows:

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

{

al INT8,

bl Strua

}

Strua :: = <V> SEQUENCE

{

a UINT8,

b UINT16

}

The message structure of the protocol contained in the converted protocol dynamic library is a table that records the various types of definitions in the protocol and a protocol message type that reflects the various types of relationships in the protocol and the composition of the messages in the protocol. Tree, see Figure 7 and the table below.

Type type information codec control constraint other

INT8 is generated by the basic type INTEGER V, VLEN-8 0--255

UINT8 is generated by the basic type INTEGER V, V | LEN-8 -128—127

Blue T16 is generated by the basic type INTEGER V, VLen-16 0-65535

Msg composite type by {UINT8 UNIT16} V None

Two type generation

Strua composite type by {I T8 Strua} V None

Two type generation Taking the above structure as an example, the code stream is: 0x80 0xf5 0x00 0xF4, and the protocol is ab. Refer to FIG. 7 and FIG. 8. The decoding process is as follows:

1. Load the protocol dynamic library, find the root node of the message recorded in the protocol dynamic library, and construct the decoded message value tree from the root node.

The message interpreter loads the protocol ab.dll into the memory, and the structure of the message of the protocol ab and various types of definition information used in the structure are put into the memory and can be queried.

2. According to the node encoding and decoding control words (BER, PER, TLV) and the subtypes of the combined type, find the node whose first type is the basic type from its children or grandchildren.

The root node of the protocol message found from ab.dll is Msg, which is a conforming type, and the encoding control word is V. According to the decoding rules of the TLV, the V composite type node itself does not generate a code stream, so the root node can be constructed based on the information of the type tree directly on the value tree generated by the encoding, and then the information from the code stream should correspond His son decodes it. 笫 A son is al and the type is INT8. It can be found from the type table that INT8 is INTERGER and the encoding control word is V.

V | LEN-8, the constraint is -128..127, can decode al.

3. Call the corresponding decoding function of the basic type, decode it into a node on the value tree of the cell, and record the position where the input code stream has been decoded.

It is learned from the LEN-8 control word that this cell occupies one byte after encoding, so a byte 0X80 is taken from the code stream, the value of this cell has been done, and the decoding has been recorded to the second of the code stream. Bytes.

4. Recursively complete the construction of each node on the value tree from top to bottom and from left to right. The length of the decoded code stream is increasing. By the time the decoding is completed, the length of the decoded code stream is exactly equal to the code stream length, and the entire value tree is constructed.

The cells bl, a, and b are solved in turn, and the value tree of the message is gradually generated, and the message decoding process is completed.

The decoded message is as follows:

Msg

0〉 80 10000000 .... al: -0x80 (-128)

.... bl

1> F5 11110101 ...... a: 0xf5 (245) 2> 00 00000000

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

The interface message interpreter of the present invention works on the basis of a general description of the protocol. In this way, when the protocol changes, as long as the description of the protocol is changed, there is no need to modify the program of the interface message interpreter itself, so that it has the greatest general Sex. Due to the widespread use of ASN.1, many standard interface protocols are described in ASN.1 language, which can save a lot of protocol description workload. In order to solve the problem of not describing the protocol formulated by ASN.1, the encoding control word of TLV is extended on ASN.1, the protocol is expressed by an extensible notation, and the C code can be embedded in the description file Processing the code stream makes it possible to describe these protocols with ASN.1 and is more convenient. The invention solves the shortcomings of existing message interpreters, such as poor generality and difficult expansion, adopts the ASN.1 standard in the description file, and extends the encoding and decoding methods supported by the ASN.1 standard so that it can well support It is not a protocol that uses ASN.1 to describe the message structure, which makes the application of this scheme wider.

Claims

Rights request

1. A method for implementing a universal message interpreter, which is characterized by including steps:

A. Obtain the message code stream from the communication interface;

B. Call the protocol message structure description information corresponding to the protocol used by the message code stream, and call the corresponding decoding function to decode the message code stream piece by piece according to the encoding and decoding control word of each cell in the description information to form the message value Tree, each node of the message value tree corresponds to one cell of the message, where:

If the cell's protocol codec control word is expressed as the basic coding rule BER, the decoding function of the BER is called for decoding;

If the codec control word of the cell is expressed as the compression coding rule PER, then the decoding function of the PER is called for decoding;

If the codec control word of a cell is represented as a type-length-value notation TLV, the decoding function of the TLV is called for decoding;

If the codec control word of a cell is expressed as a combination of multiple items in BER, PER, and TLV, then the corresponding decoding functions are called for decoding;

C. Traverse the message value tree, and output a decoded character string for each cell according to its format.

2. The method according to claim 1, wherein in step C, a character string is generated into a formatted text stream with a hierarchical structure and output.

3. The method according to claim 2, further comprising: E: analyzing the output text stream through a graphical interface GUI to form an explanatory relation tree, and combining the relation tree and the message on the graphical interface The code stream is displayed.

4. The method according to claim 1, 2 or 3, wherein the decoding in step B comprises the steps:

Find the root node of the message from the description information of the protocol message structure, and construct a value tree of the decoded message starting from the root node;

According to the node encoding and decoding control word and the subtype of the combined type, find the node whose first type is the basic type from its child node or grandchild node;

Call the decoding function corresponding to the basic type of codec control word, decode it into a node on the value tree of the cell, and record the position where the input code stream has been decoded; The construction of each node on the value tree is completed in turn to form the entire value tree.

5. The method according to claim 1, further comprising the step of: before performing step A, combining the abstract syntax mark 1 (ASN.1) with the encoding and decoding control word to describe the protocol to be interpreted and The protocol message structure description information is formed, and then the description information is used to generate a protocol dynamic library for invocation.

6. The method according to claim 5, wherein the codec control word is added to a type definition in the ASN.1 text.

7. The method according to claim 5 or 6, wherein the encoding and decoding control word is one of BER, PER, and TLV, or multiple combinations of BER, PER, and TLV.

8. The method according to claim 5 or 6, characterized in that: the C language program that implements the constraint relationship between cells is embedded in the ASN.1 text and is included in the generated protocol dynamic library; Execute this procedure to complete the custom constraint restrictions.