WO2005057873A1 - Procede de mise en oeuvre d'un dispositif universel expliquant les messages - Google Patents

Procede de mise en oeuvre d'un dispositif universel expliquant les messages Download PDF

Info

Publication number
WO2005057873A1
WO2005057873A1 PCT/CN2004/001424 CN2004001424W WO2005057873A1 WO 2005057873 A1 WO2005057873 A1 WO 2005057873A1 CN 2004001424 W CN2004001424 W CN 2004001424W WO 2005057873 A1 WO2005057873 A1 WO 2005057873A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
decoding
encoding
protocol
type
Prior art date
Application number
PCT/CN2004/001424
Other languages
English (en)
Chinese (zh)
Inventor
Ni Huang
Hao Wang
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2005057873A1 publication Critical patent/WO2005057873A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]

Definitions

  • the present invention relates to communication technologies, and in particular, to a method for implementing a universal message interpreter in a communication system.
  • 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 key technologies of the message interpreter are the analysis and decoding functions of the message, and the data expression ability of the descriptive language.
  • 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.
  • 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.
  • ASN.1 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.
  • ASN encoding methods 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 1 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.
  • 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.
  • 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.
  • 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) 0 so that the actual length of the content part is the number of bytes occupied by the encoded stream between 0x80 and E0C.
  • EOC End Of Contents
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • PER coding 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.
  • 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.
  • 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.
  • 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.
  • the type does not give a specific upper and lower bound on the set value. Special treatment is given to these two special cases.
  • 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.
  • the value of the element itself in the value set is encoded.
  • 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. .
  • 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.
  • 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.
  • 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)
  • 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.
  • Method 1 Responsible for the decoding of a protocol through a dedicated piece of program code; however, this method has the following disadvantages:
  • 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.
  • BER basic encoding rules
  • PER compression encoding rules
  • the custom description language requires extra learning time, and lacks materials and development tools.
  • 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.
  • the present invention provides the following technical solutions:.
  • a method for decoding a communication interface message includes the following steps:
  • each node of the message value tree corresponds to one cell of the message, where:
  • 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;
  • PER compression coding rule
  • TLV type-length-value notation
  • 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;
  • 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.
  • Figure 1 is a schematic diagram of the interface message interpretation result
  • FIG. 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. 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
  • FIG. 8 is a decoding flowchart.
  • TLV type-length-value
  • 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.
  • TLV code control provided to users is as follows:
  • General Encoding Control Gives the overall encoding rules and encoding constraints and controls.
  • the expression in this section is "A
  • 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
  • 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.
  • control items of each part of TLV are as follows:
  • 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.
  • 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.
  • 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.
  • the LEN control item takes a parameter to indicate how many bits the V 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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 is interpreted.
  • 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.
  • PER compression coding rule
  • TLV type-length-value notation
  • the encoding and decoding engine traverses the value tree to generate hierarchical formatted text
  • 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.
  • 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:
  • ThreeByte ⁇ V, V
  • HexString :: VisibleString (FROM (48..57
  • 65..70))- ⁇ '. ⁇ .'9', ' ⁇ '. HexStringl :: VisibleString (FROM (48..57))
  • Dtmfstring "VisibleString (FROM (48..57
  • 65..70))-Printablestring:: ⁇ V, V
  • the ASN compiler 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.
  • 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.
  • the implementation of the present invention separates the compiler and the codec.
  • 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.
  • the intermediate form of the abstract value is the intermediate form of the abstract type, it has the same tree structure hierarchy.
  • 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.
  • the decoding process reconstructs the intermediate form of the abstract value according to the code stream, that is, the abstract value tree.
  • the intermediate form of the abstract type must be specified as the basis for decoding.
  • the abstract value intermediate form and the abstract value tree have the same meaning
  • 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.
  • 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.
  • 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.
  • 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.
  • initialize the engine creates 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
  • 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.
  • the decoding library PER library, BER ⁇ , TLV library, etc.
  • 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.
  • the codec engine 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • SCCP can be individually coded after overall coding control, SCCP special needs coding can be completed.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • the protocol is described as follows:
  • 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.
  • INT8 is generated by the basic type INTEGER V, VLEN-8 0--255
  • UINT8 is generated by the basic type INTEGER V, V
  • Blue T16 is generated by the basic type INTEGER V, VLen-16 0-65535
  • 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:
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)

Abstract

La présente invention concerne un procédé de décodage et d'explication d'un message d'interface de communication qui consiste tout d'abord à présenter la structure du message dans le protocole de communication et ce par combinaison du ASN.1 et de la notation des mots de commande de codage décodage; à générer une bibliothèque dynamique de protocoles; à envoyer le flux de code du message et la bibliothèque dynamique de protocoles correspondant au flux de code du message à un dispositif expliquant les messages, ce dernier effectuant le décodage au moyen d'une fonction présente dans la bibliothèque de fonctions de décodage publique, pendant le décodage, il se produit une recherche du type de travail de commande de codage décodage de la cellule dans la bibliothèque dynamique de protocoles pour définir s'il s'agit de BER, PER ou TLV; à utiliser la fonction de décodage correspondante pour décoder et à générer un arbre de valeurs de message en fonction de la représentation des mots de commande de la cellule; à hiérarchiser chaque noeud de l'arbre de valeurs, ce qui génère ainsi un texte de mise en forme présentant une structure en couches et le produit en sortie; à analyser le flux de texte de mise en forme produit, à générer un arbre de relations d'explication et à présenter l'arbre de relations et le flux de code du message sous forme d'un graphique.
PCT/CN2004/001424 2003-12-12 2004-12-07 Procede de mise en oeuvre d'un dispositif universel expliquant les messages WO2005057873A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN 200310123617 CN100505743C (zh) 2003-12-12 2003-12-12 通用消息解释器的实现方法
CN200310123617.4 2003-12-12

Publications (1)

Publication Number Publication Date
WO2005057873A1 true WO2005057873A1 (fr) 2005-06-23

Family

ID=34661437

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2004/001424 WO2005057873A1 (fr) 2003-12-12 2004-12-07 Procede de mise en oeuvre d'un dispositif universel expliquant les messages

Country Status (2)

Country Link
CN (1) CN100505743C (fr)
WO (1) WO2005057873A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2473180C2 (ru) * 2008-07-02 2013-01-20 Зте Корпарейшн Способ обработки данных связи tlv-формата
EP3257235A4 (fr) * 2015-02-10 2018-02-21 Telefonaktiebolaget LM Ericsson (publ) Procédé et appareil de médiation de données
CN111817727A (zh) * 2020-06-28 2020-10-23 积成电子股份有限公司 一种适用于dl/t860标准的per编码器实现方法

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1859359B (zh) * 2005-07-12 2010-08-25 上海华为技术有限公司 用抽象语法规则描述的通信协议的实现方法及其装置
CN100579120C (zh) * 2005-12-31 2010-01-06 中兴通讯股份有限公司 基于asn.1定义的pdu编解码代码自动生成的实现方法
CN101370003B (zh) * 2007-08-14 2012-08-08 大唐移动通信设备有限公司 用于定制通讯协议的方法和装置、转换通讯协议描述的方法和装置
CN101179580B (zh) * 2007-12-12 2010-08-11 北京北方烽火科技有限公司 一种用于实现WiMAX系统消息编解码的方法
CN102281259B (zh) * 2010-06-11 2014-01-29 深圳市金蝶中间件有限公司 对请求信息进行解码的方法及装置
CN102270223B (zh) * 2011-06-22 2017-03-29 中兴通讯股份有限公司 消息解码库的生成方法、装置及消息解码方法、装置
CN104142816B (zh) * 2013-05-10 2018-05-15 中国电信股份有限公司 用户卡片及其cdma短信解析方法
CN105740292B (zh) * 2014-12-12 2019-06-28 深圳市中兴微电子技术有限公司 一种解码方法及装置
CN105139053B (zh) * 2015-10-15 2018-01-30 江苏本能科技有限公司 射频识别读写器接口协议调试装置及方法
CN111131403A (zh) * 2019-12-06 2020-05-08 深圳猛犸电动科技有限公司 一种物联网设备的消息编解码方法及装置
CN113742294A (zh) * 2021-08-23 2021-12-03 宜通世纪科技股份有限公司 一种asn.1-per信令消息解码方法、系统、装置及介质
CN115190184B (zh) * 2022-06-14 2023-06-23 深圳市圣麾科技有限公司 一种二进制消息信元编辑方法、系统及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0520708A2 (fr) * 1991-06-28 1992-12-30 Digital Equipment Corporation Méthode et appareil pour convertir des syntaxes abstraites de haut niveau en une forme intermédiaire
JPH08106424A (ja) * 1994-10-06 1996-04-23 Nec Corp Ｏｓｉ管理システムにおけるｍｉｂのデータ実装方式

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0520708A2 (fr) * 1991-06-28 1992-12-30 Digital Equipment Corporation Méthode et appareil pour convertir des syntaxes abstraites de haut niveau en une forme intermédiaire
JPH08106424A (ja) * 1994-10-06 1996-04-23 Nec Corp Ｏｓｉ管理システムにおけるｍｉｂのデータ実装方式

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2473180C2 (ru) * 2008-07-02 2013-01-20 Зте Корпарейшн Способ обработки данных связи tlv-формата
EP3257235A4 (fr) * 2015-02-10 2018-02-21 Telefonaktiebolaget LM Ericsson (publ) Procédé et appareil de médiation de données
US10511720B2 (en) 2015-02-10 2019-12-17 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for data mediation
CN111817727A (zh) * 2020-06-28 2020-10-23 积成电子股份有限公司 一种适用于dl/t860标准的per编码器实现方法
CN111817727B (zh) * 2020-06-28 2024-04-09 积成电子股份有限公司 一种适用于dl/t860标准的per编码器实现方法

Also Published As

Publication number Publication date
CN100505743C (zh) 2009-06-24
CN1627757A (zh) 2005-06-15

Similar Documents

Publication Publication Date Title
WO2005057873A1 (fr) Procede de mise en oeuvre d'un dispositif universel expliquant les messages
US7219328B2 (en) Model-based composable code generation
CA2244918C (fr) Unite d'interconnexion et de gestion et procede de production d'une telle unite
US7353296B2 (en) Method for performing data structure conversions
ES2659396T3 (es) Método para procesar formato TLV de datos de comunicación
US20050278693A1 (en) Distribution adaptor for network management application development
EP2124419A1 (fr) Dispositif de gestion orienté objets pour message asn.1
CN103513976B (zh) 业务流程建模方法及装置
CN101197818A (zh) 一种asn.1报文面向对象的处理方法
CN109683873B (zh) 利用asn1规则的航天信息接口编码方法及系统架构
CN113742294A (zh) 一种asn.1-per信令消息解码方法、系统、装置及介质
CN113162977A (zh) 一种信息处理方法及装置、设备、存储介质
CN104077414B (zh) 一种应用于lte网络信号的解码装置及其解码方法
CN107832046A (zh) 数据生成方法及装置
Deri et al. An object-oriented approach to the implementation of OSI management
CN111913714B (zh) 一种基于Thrift的变电站站控层通讯服务映射方法及装置
Lee Translation of GDMO/ASN. 1 to Java objects for network management
Cleghorn et al. ASNST: An abstract syntax notation-one support tool
CN114661955A (zh) 一种配置化的xml报文解析方法、系统、装置和存储器
US7730103B2 (en) Apparatus and method for efficient encoding of application definition using contiguous arrays
CN113992549A (zh) 一种测试方法、装置、电子设备及存储介质
Horowitz Bringing java to TMN
Hall Generation of Restful API Proxy Service from Soap Service
CN109284087A (zh) 一种基于cim模型开发mof文件的方法、装置及设备
Yuen et al. Simplified message transformation for optimization of message processing in 3G-324M control protocol

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase