CN1301018C - Information treatment method in communication system - Google Patents

Abstract

The invention discloses a message processing method in a communication system. The method stores the attribute of each message in a message set as an attribute body; the attribute of the message includes: parameters that need to be coded and sent in the message; When sending a message, search for the attribute body corresponding to the message according to the parameter encoding code in the message, encode the parameters described in the attribute body and then send it; when receiving a message, search for the attribute body corresponding to the message, and use the attribute body description The parameters are decoded. With the above solution, only one set of common codes can be used for the encoding and decoding of each message, so it will have better code reusability and portability; and it will make the development cycle of the message processing method short and stable. And it has good compatibility and maintainability.

Description

A message processing method in a communication system

technical field

The invention relates to an information processing method in a communication system, in particular to a processing method for sending and receiving messages.

Background technique

In the end-to-end communication process in the communication system, a large number of messages need to be sent and received. For example, the mobile application part (MAP, Mobile application part) in the mobile communication system is responsible for a large number of mobile-related information in the switch. Make message processing. Due to the rapid development of data transmission protocols and services in the communication system, many new business operations and parameters are often generated or changed. Therefore, it is necessary to solve the problems of large amount of code, redundancy, and poor compatibility in the process of message processing in the system. , while improving the reusability, reliability, and maintainability of the code, it has become an urgent problem that people need to solve.

Take the MAP in the mobile communication system as an example, including the Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA) and Wider Code Division Multiple Access (WCDMA) systems. The code structures in their MAPs are very similar to send Taking a location registration message as an example, the processing method is as follows:

Location registration message processing function

{encode user's ESN (Equipment Serial Number);

The MSCID (mobile exchange identification number) of the encoding exchange;

...

After encoding all the parameters of the location registration

Send a message to HLR;

.....}

That is to say, the location registration message processing function encodes all the specific parameters of the message one by one, and then sends the encoded message to the home location register (HLR) of the system. Similar to the processing method of the above-mentioned location registration message, because each message in the MAP may have many parameters, and each parameter is also implemented by a separate code, the code structure will inevitably be complicated and redundant. Once the protocol responsible for message transmission changes, or the parameter requirements for transmission change, or the attributes of some parameters change, such as the length of the parameter changes, etc., it is necessary to modify the source code in the message processing method, which is very difficult to maintain. inconvenient. At the same time, if new messages and parameters need to be added due to business development, such as monitoring functions, location business functions, etc., many source code functions need to be added to the processing code of the original method, which will lead to unstable performance of the message processing method .

It can be seen from the above that the existing message processing method adopts the method of encoding each parameter of a specific message. Since each message has many parameters, for many messages, if there are parameter encoding methods, the same In some cases, there will be code redundancy to complete the same functional operation and diversification of implementation methods, which will make the code complicated and unclear. For example, in the processing method of the above-mentioned position registration message, the functions of encoding ESN, MSCID, etc. are public, and many messages may be used, so when other message processing methods also need the above-mentioned public encoding function, according to the existing message processing method, It will inevitably make the code of the entire MAP part redundant and complicated, and the code structure is not clear. At the same time, the code is not easy to maintain and the sharing is very poor. For example, the MAP parameter definitions of the GSM system and the MAP system of the CDMA system are completely different, so the respective codes are completely different, which not only prevents code sharing, but also increases maintenance costs.

Contents of the invention

The purpose of the present invention is to provide a message processing method in a communication system with simple code, less redundancy, easy maintenance and good shareability.

In order to achieve the above purpose, the present invention provides a message processing method in a communication system, including:

Store the attributes of each message in a message set as an attribute body; the attributes of the message include: parameters that need to be encoded and sent in the message;

When sending a message, the attribute body corresponding to the message is searched according to the parameter encoding code in the message, and the parameters described in the attribute body are encoded and then sent.

Optionally, the method further includes: when receiving a message, searching for an attribute body corresponding to the message, and using the parameters described in the attribute body to decode.

Preferably, a message description table is established as a carrier for storing message attributes; the message description table includes the following fields:

Parameter name, used to describe the name of the parameter;

Parameter type, used to describe the nature of the parameter;

Parameter length, used to describe the length of the parameter;

When sending a message, look up the attribute body corresponding to the message from the message description table according to the parameter encoding code in the message.

Optionally, the attribute body of each message is stored in its own message description table.

Preferably, an index table of the message description table is established for locating the message description table.

Optionally, the index table includes the following fields:

Message name, used to describe the name of the message;

Message type, used to describe the call relationship of message parameters;

Description table name, used to describe the name of the message description table.

Preferably, the message description table is maintained in the background through the operation and maintenance console of the system.

Optionally, a message description table is established as a carrier for storing message attributes; the message description table includes the following fields:

Message name, used to describe the name of the message;

Message type, used to describe the call relationship of message parameters;

Parameter name, used to describe the name of the parameter;

Parameter type, used to describe the nature of the parameter;

Parameter length, used to describe the length of the parameter.

Preferably, attribute bodies of all messages are uniformly stored in a message description table.

Since the present invention stores the attributes of each message in a message set as an attribute body, when sending a message, as long as the attribute body corresponding to the message is found, the parameters described by the attribute body can be encoded and then sent; similarly, When receiving a message, it is also possible to assist in decoding the message parameters according to the found attribute body of the message; using the above method, the encoding and decoding of each message can only use a set of common codes, so it will have better code reliability. Reusability and portability; in addition, using the above method, for any business, whether it is a new business or an old business, as long as a message description table is established according to the attributes of the business message, a set of common coding methods can be used to realize the processing of the message , so that the development cycle of the message processing method is short and the stability is good; at the same time, the change of different message processing methods can be realized only by dynamically modifying the message description table, so this method has good compatibility and maintainability sex.

Description of drawings

Fig. 1 is a schematic flow chart of sending messages in the present invention;

Fig. 2 is a schematic diagram of the dynamic maintenance of the message description table of the method of the present invention.

Detailed ways

Taking the implementation of MAP in the mobile communication system as an example, the present invention will be further described in detail in conjunction with the accompanying drawings.

The MAP of the communication system is actually a collection of messages and message processing procedures. Since each message contains many parameters, encoding and sending the parameters of these messages is to realize MAP. Take the feature request (FeatureRequest) message in the ANSI41D (Chinese) protocol as an example. It is a message sent from the mobile switching center (MSC) of the system to the home location register (HLR). Parameters, in order to send the message to the HLR, it is necessary to encode the corresponding parameters included in the message before sending. Since each sent message in the existing method has its own processing procedure, the realization of each processing procedure has its own code, which makes the whole MAP both huge and cumbersome to implement. The reason for these problems is actually very simple. During the processing of different messages, the parameter encoding codes of many messages are common or the same. In the process of processing different parameters, many processes may need to call these different parameter encoding codes, which will inevitably lead to the process of calling a set of encoding codes for parameters appearing multiple times in the entire MAP, thus causing MAP code redundancy and difficulty Maintenance, poor sharing, and difficulty in upgrading. In fact, the reason for the problem of the existing method lies in its processing process. The processing process of the existing method is based on the parameters of the specific message. In this way, it is necessary to determine the encoding code for the parameter according to the parameter of the message during the processing of the message. Assuming that during the processing of two messages, there is a parameter that needs to call the same encoding code, then a set of exactly the same encoding code needs to be called twice, and the same calling code will be repeated in the entire MAP Appear. If a new control message is added in the MAP due to the increase of the service, a processing procedure shall be constructed for the message using the existing parameter encoding code.

It can be seen from the above that if the message processing method in MAP is changed to use the encoding code of the message parameter as the core, and use a set of encoding codes to construct the process, that is, to use a set of parameter encoding codes, no matter which message is processed, the message will be used The parameters that need to be encoded to adapt to the process will solve the problem of existing methods. For example, when upgrading the MAP, that is, adding a new message, it is no longer necessary to consider the process of processing the message and the codes that need to be used in the process.

The present invention is specifically implemented in this way: if the messages in the MAP are regarded as a collection of messages, then the attributes of each message in the message collection are stored as attribute bodies respectively, and the attributes of the messages described here are the The parameters to be sent need to be encoded; in this way, when processing the message, such as when sending a message, use the existing parameter encoding code to search for the attribute body corresponding to the message, encode the parameters described in the attribute body and send it. When receiving a message, the parameter of the received message can be directly decoded, or the attribute body corresponding to the message can be searched, and the parameter described by the attribute body can be used to decode the parameter to make the parameter decoding more accurate.

In order to make searching for parameters that need to process messages faster, a message description table can be established in practice as a carrier for storing message attributes or parameters; the message description table includes the following fields:

Parameter name, used to describe the name of the parameter;

Parameter type, used to describe the nature of the parameter;

Parameter length, used to describe the length of the parameter.

It can also include other auxiliary management fields, such as a parameter description field. The actual message description table that the present invention adopts when processing MAP message as following table 1, in this message description table, enumerates the FeatureRequest message of ANSI41D agreement, and the length field wherein comprises two parts: minimum length and maximum length.

Table 1: parameter name Parameter Type length describe Digits (dialed) required minimum length The maximum length Description of what this parameter does BILLID optional minimum length The maximum length Description of what this parameter does ... ... ... ... ...

In the above table, the specific parameter name of the FeatureRequest message is described, such as Digits (dialed); the nature of its type is the nature of the parameter, such as: optional, mandatory, etc.; the length field describes the minimum length and The maximum length value; the description field is used to describe the function of this parameter.

In the specific implementation of the present invention, it is necessary to store the attribute body of each message in its own message description table similar to the above, that is, fill in all the parameters of the message in the above description table.

FIG. 1 is a schematic flow chart of sending messages in the present invention. As shown in Fig. 1, when the application program sends a message to the remote end in step 1, it needs to search the message description table of the message to obtain the parameters of the message that need to be encoded and sent. Therefore, in step 2, the corresponding parameter description table is searched according to the information provided by the message, and then in step 3, the found parameters of the message to be encoded are transmitted to the application program, and then in step 4, the program encodes the parameters and sends them out. It can be seen that the actual application program unifies the query of message parameters and the encoding and sending of message parameters into a whole to form a common operation. The object or parameter of this common operation is the specific message description table, regardless of the number of message description tables, How the content changes will not affect this public operation. As long as the public application program provides the message name of the message to be sent, the message description table of the message can be found, so as to encode the parameters in the message description table and realize the transmission of the message.

In the specific implementation of the process shown in FIG. 1 , the two processes of searching for message parameters and encoding parameters are integrated into a unified process. Assuming that the name of the process is "send message", then sending a message (message name) can send out the parameter code of the message provided by the message name in brackets. Similarly, the implementation of receiving a message can be the same as that of sending a message, and finally a unified process is formed. It can be seen that by adopting the method of the present invention, it is relatively simple to add a new message, just increase the message description table of the fixed template, and then call the two unified processes of sending a message and receiving a message, which can be realized. Since the operation process of sending and receiving messages is public, this may make the public operation for signaling interaction more reliable due to its stability, thereby effectively improving the stability and reliability of the message processing method; The development is simple and easy, and the development cycle is shortened. The main work can be completed only by completing a description table.

When the present invention is implemented, in order to improve the speed of locating a message description table in a message collection, an index table of all message description tables in the message collection can be established, and the index table can include the following fields:

Message name, used to describe the name of the message;

Message type, used to describe the call relationship of message parameters;

Description table name, used to describe the name of the message description table.

Of course, other auxiliary management fields can also be added in the above table, as explained in the description table. In this way, by providing the message name and type for the sending or receiving process of the message, the corresponding message description table and feedback parameters can be obtained.

It should be noted that since different parameters may need to be processed when processing a message, it is necessary to provide the message type, that is, the call relationship to determine the set of parameters that need to be obtained each time a message is sent or received. For example: when sending and processing the FeatureRequest message, the application also provides the call message type (Invoke), then when sending and processing the message, it will send a message composed of different parameter sets than those provided by other message types . In order to realize the above operations, the parameters of a message can be stored in different message description tables according to different types of a message, so as to facilitate the processing of different parameter sets. For example, the process of sending the Invoke type of FeatureRequest message:

Initiate a message (FeatureRequest, Invoke)

{

Find the corresponding description table according to FeatureRequest and Invoke, and get all the parameters of the message operation from the description table;

for(ii=0; ii<the maximum number of parameters describing the table; ii++)

{Judge the type and length of each parameter;

Encode for each parameter; }

}

The above-mentioned FeatureRequest is the message operation code, which indicates the operation of each specific message; the message type is Invoke, which is used to indicate the specific message description table.

When implementing the present invention, if the scheme of storing the parameters of a message into different message description tables according to the different types of a message is not adopted, it is necessary to judge and other methods before the encoding operation of the specific parameters, just like this It takes more time.

When the present invention is implemented, a message description table with the following structure can also be set up as a carrier for storing message attributes; the message description table includes the following fields:

Message name, used to describe the name of the message;

Message type, used to describe the call relationship of message parameters;

Parameter name, used to describe the name of the parameter;

Parameter type, used to describe the nature of the parameter, such as optional or mandatory;

Parameter length, used to describe the length of the parameter;

A description that explains what the message or parameter does.

If the message description table with the above structure is adopted, the attribute bodies of all messages, that is, all parameters and descriptions of all messages can be stored in one message description table. In this way, the process described in FIG. 1 will not change, but there are slight adjustments in the specific steps of message search and parameter encoding.

In the present invention, no matter the parameters of each message in a message set are stored in separate description tables one by one, or stored in a description table, in the normal operation of switching equipment, such as switches or routers, if the message needs To add or modify existing message parameters, you can dynamically modify, delete, and add these message description tables through the background operation and maintenance console OMC to ensure message compatibility. For the specific maintenance schematic diagram, refer to Figure 2 , Figure 2 is described by taking the switch as an example. Assuming that the parameters of each message in a message set are stored in separate description tables one by one, when maintaining the message description tables that need to be maintained, the commands in the form of Table 2 below can be issued through the OMC operation and maintenance desk :

Table 2: information operation type modification type parameter name Parameter Type length describe

For the meaning of the fields, refer to the following description:

Message, specific message, such as FeatureReqeust above.

Operation type: the calling relationship of parameters, such as Invoke, Return, Result, etc.

Modification type: modify, add, or delete.

Parameter name: a specific parameter name, such as Digits (Dialed) in Table 1 above.

Parameter type: optional, required, etc.

Length: the maximum and minimum length value of this parameter

Description: The expression that specifies the function of this parameter.

After the switch receives the command, it updates the content in the parameter description table through an internal function call, thereby dynamically updating the information in the switch. This is a very good design idea for improving the compatibility of online devices.

Claims (9)

1. A message processing method in a communication system, comprising: Store the attributes of each message in a message set as an attribute body; the attributes of the message include: parameters that need to be encoded and sent in the message; When sending a message, the attribute body corresponding to the message is searched according to the parameter encoding code in the message, and the parameters described in the attribute body are encoded and then sent. 2. The message processing method according to claim 1, further comprising: when receiving a message, searching for an attribute body corresponding to the message, and using the parameters described in the attribute body to decode. 3. The message processing method according to claim 1 or 2, characterized in that: a message description table is established as a carrier for storing message attributes; the message description table includes the following fields: Parameter name, used to describe the name of the parameter; Parameter type, used to describe the nature of the parameter; Parameter length, used to describe the length of the parameter; When sending a message, look up the attribute body corresponding to the message from the message description table according to the parameter encoding code in the message. 4. The message processing method according to claim 3, characterized in that: the attribute body of each message is stored in its own message description table. 5. The message processing method according to claim 4, characterized in that an index table of the message description table is established for locating the message description table. 6. The message processing method according to claim 5, wherein the index table includes the following fields: Message name, used to describe the name of the message; Message type, used to describe the call relationship of message parameters; Description table name, used to describe the name of the message description table. 7. The message processing method according to claim 3, characterized in that: the message description table is maintained through the background of the system's operation and maintenance console. 8. The message processing method according to claim 1 or 2, characterized in that: a message description table is established as a carrier for storing message attributes; the message description table includes the following fields: Message name, used to describe the name of the message; Message type, used to describe the call relationship of message parameters; Parameter name, used to describe the name of the parameter; Parameter type, used to describe the nature of the parameter; Parameter length, used to describe the length of the parameter. 9. The message processing method according to claim 8, characterized in that: the attribute bodies of all messages are uniformly stored in a message description table.

Images