KR100659584B1 - Method of exchanging messages - Google Patents

Abstract

The present invention relates to a message exchange method. In a start phase, when a sequence message in which a message exchange order and a message format are sent is sent, a receiving application defines and interprets the sequence message according to its protocol version. By exchanging messages in a defined format in a defined order and recognizing the components of the message in a defined way, seamless message exchange is possible between applications implementing different versions of the protocol, and any change in the order of message exchange is possible. It is easy to extend messages such as and add components. It can be applied to message exchange between telematics device and service server.

Application protocol, application, message exchange, message format, sequence message

Description

How to exchange messages {Method of exchanging messages}

1 is a flowchart illustrating a conventional message exchange method according to a telematics application protocol.

2A to 2C are exemplary diagrams for explaining an example of a conventional message format.

3 is a flowchart illustrating a message exchange method according to the present invention.

4 is an exemplary diagram for explaining an example of a sequence message format according to the present invention;

5A to 5C are exemplary views for explaining an example of a message format according to the present invention.

The present invention relates to a message exchange method, and more particularly, to a message exchange method capable of exchanging messages between application programs that implement different versions of a protocol.

With the development of various interface technologies, wired / wireless communication technologies and internet-based technologies, recently, telematics devices are installed in vehicles, and various information and services are provided for driver safety and convenience through telematics devices capable of bidirectional communication. It is becoming.

Such a telematics service is performed through a predetermined service server, and information exchange between the service server and the telematics device is performed through a telematics application protocol.

In general, telematics application protocols include messages exchanged between applications and a message sequence that indicates the order in which messages are exchanged. Since telematics applications can exchange messages only by implementing the message format and message sequence defined by the application protocol, the versions of the application protocol should basically be the same.

Conventional telematics application protocols define a variety of application use cases and define message formats and message sequences used for each use case.

FIG. 1 is a flowchart illustrating a conventional message exchange method according to a telematics application protocol, and will be described using an emergency call use case as an example. 2A to 2C illustrate message formats exchanged in case of an emergency call use case proposed by ERTICO as an example of a conventional message format for explaining FIG. 1 ("GTP (Global Telematics Protocol) Application Protocol Encoding Specification"). , Telematics Forum, March 2003).

Referring to FIG. 1, when an emergency occurs, a driver or a passenger of a vehicle may notify an emergency situation to a service server through an input device of a telematics device. When a command is input through an input device, an application program of the telematics device generates an emergency call request message and transmits it to the service server.

FIG. 2A is a format of the emergency call request message, and includes a header, a version, a time stamp, a vehicle location, a vehicle type, and a breakdown status for displaying a message. ), Data about components such as information type and size are allocated bit by bit.

When the emergency call request message is delivered to the service server, the application of the service server generates an emergency call reply message and transmits it to the telematics device, and if necessary, makes a voice call with the service center. To lose.

FIG. 2B is a format of the emergency call response message, and includes a header, a version, various commands (ECall CintroFlag1, Transmit Units), a device operation command (ECall CintroFlag2), and a phone number of a service server. Data about components such as Number) is allocated bit by bit.

When the above process is completed, the application program of the service server generates a Terminate message and transmits it to the telematics device.

2C shows a format of the termination message, in which data about components such as a header is allocated bit by bit.

As described above, the message exchange is performed only in the defined order, and the message exchange is possible only through the application protocol of the same version. In other words, after encoding data of an application program into a fixed message according to an application protocol, message exchange was performed in a defined order. Therefore, it is not possible to add a new message or component or change the message sequence, and to add a new component or change the message sequence, there is a disadvantage in that the protocol processing apparatus must be reimplemented.

The present invention has been made in view of the above-described disadvantages, and provides a message exchange method that enables smooth message exchange between applications implementing different versions of the protocol, and facilitates the addition of messages and the change of message sequences. Its purpose is to.

In the message exchange method according to the present invention for achieving the above object, the transmitting unit transmits a sequence message in which a use case, a message exchange order and a format are defined to a receiving unit through an application program, and the receiving unit transmits the sequence message to an application program. Confirming that the use case of is implemented, and transmitting a confirmation message to the transmitter, wherein the transmitter and the receiver exchange messages of the format according to the message exchange order, wherein one of the transmitter and the receiver is And transmitting a termination message through the application program.

The format of the message and the components of the message are previously defined in an application program of the transmitter and the receiver, and versions of an application protocol implemented by applications of the transmitter and the receiver are different from each other.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. The following embodiments are provided to those skilled in the art to fully understand the present invention, and may be modified in various forms, and the scope of the present invention is limited to the embodiments described below. no.

3 is a flowchart illustrating a message exchange method according to a preferred embodiment of the present invention. For convenience of description, a message exchange between a telematics device and a service server will be described as an example.

First, in the starting step, the application program of the message sender (eg, the telematics device) transmits a sequence message in which the message exchange order and the message format are defined to the message receiver (eg, the service server) (step 101). .

As shown in FIG. 4, the sequence message includes identifiers (SEND and RECV) defining an exchange order such as a UseCase, a REQUEST message, a REPLY message, a VOICE CALL, and the like. Message formats (REQUEST DTD, REPLY DTD), identifiers (SEND and RECV) and message format (TERMINATE DTD) are defined that define the exchange order of the end message. The use case represents a service provided by the service server, and the type of service may be an emergency call required for emergency rescue, a location tracking request of a vehicle, a traffic information request, and the like.

FIG. 4 is an example of a sequence message for better understanding of the present invention. Although the format of the sequence message is defined in the form of a document type definition (DTD), it may be defined in various formats such as XML. By defining the format of the message in this way, the receiving application can easily interpret the message.

The application program on the receiving side receives the sequence message (step 102), and checks whether the use case is implemented in the application program on the receiving side (step 103). That is, it is checked whether the message format and the component recognition method for the use case are defined in the application program.

If the message format for the use case is not defined in step 103, since message exchange is not possible, an end message is generated and transmitted to the sender (step 104). The application program of the transmitting side receives the message transmitted from the receiving side (step 105), checks whether the message transmitted from the receiving side is the ending message (step 106), and terminates the session if it is the ending message (step 106). 107).

On the other hand, if the message format for the use case is defined in step 103, message exchange is possible, so the application program on the receiving side generates an acknowledgment message and transmits it to the transmitting side (step 108), and performs a message exchange. Prepare (step 109).

Receiving the confirmation message sent from the receiving side (step 105), the application program on the sending side confirms that the confirmation message is not an end message (step 106), and prepares for message exchange (step 110).

Thereafter, the application program of the transmitting side generates a Call Request message in the order defined in the sequence message and transmits it to the receiving side (step 111). At this time, the application program of the sender uses an identifier (SEND) indicating a transmission, and generates a message using only components that can be transmitted. If you use an undefined component, the component displays a null value.

FIG. 5A is an example of an emergency call request message in a use case according to the present invention, and includes a header, a version, a timestamp, a vehicle location, and a vehicle type. ), Data related to components such as a cause of failure (BreakDownStatus) and a type of information are included.

The application program on the receiving side recognizes a component in the call request message and performs processing for the component (step 112). At this time, since the message format and the component recognition method are defined by the sequence message in the receiving application, the component is extracted according to the defined method. An XML query processor or the like may be used to extract the component, and the component may be recognized by a method of detecting a tag in the message. For example, the corresponding component may be recognized by a method of detecting a letter (eg, V, T, L, V, B, I, etc.) included in each component. When the components are recognized through the tag detection method as described above, the order of the components may be arbitrarily changed, thus making the creation and modification of the message easier.

The application program on the receiving side generates a call reply message (Call Reply) for the call request message and transmits it to the transmitting side (step 113). At this time, the receiving application uses an identifier (RECV) indicating the transmission of the request. 5B illustrates an example of an emergency call reply message in a use case according to the present invention, including a header, a version, various commands (ECallCtrlFlag1, TransUnit), and a device operation command (ECallCtrlFlag2). Data relating to components such as errors, errors, and telephone numbers (Transmit, Phone No.) such as a service server.

The application program on the sending side recognizes the component in the call response message and performs processing for the component (step 114). In this case, the application program of the transmitting side may recognize the component by a method of detecting a tag in the message, similarly to the application program of the receiving side.

Thereafter, the transmitting side and the receiving side exchange messages and calls of a format defined according to the message exchange order defined in the sequence message. When the message exchange is completed, the sending or receiving application program transmits a Terminate message to the other party. FIG. 5C is an example of an emergency call terminate message in a use case according to the present invention, and includes data regarding components such as a header.

Messages exchanged in accordance with the present invention may be written, for example, in an XML document. In addition, the elements of the message may be defined as XML elements and the like, and are preferably defined as unique names for easy recognition. In order to be able to exchange messages according to the present invention, a message format and a method of recognizing the components must be previously defined in an application program.

As described above, the optimum embodiment of the present invention has been disclosed through the detailed description and the drawings. The terms are used only for the purpose of describing the present invention and are not used to limit the scope of the present invention as defined in the meaning or claims. Therefore, those skilled in the art will understand that various modifications and equivalent other embodiments are possible from this. Therefore, the true technical protection scope of the present invention will be defined by the technical spirit of the appended claims.

As described above, according to the present invention, when a sequence message in which a use case, a message exchange order, and a format are defined is sent at the start stage, the receiving application defines and interprets the sequence message according to its protocol version. Applications that implement different versions of the protocol by exchanging messages in a defined format in a defined order and recognizing the components of the message in a defined manner, for example extending the protocol to add additional information to the message, Seamless message exchange is also possible between an application (A) modifying a message exchange sequence and an application (B) implementing an unmodified protocol using a given message format and message sequence. In addition, since it is easy to extend a message such as changing a message format or a message sequence or adding a component without changing the protocol of the telematics device, it is possible to provide various telematics services and provide convenience to a service provider and a user.

Claims (7)

Sending, by the sender, a sequence message defining a use case, message exchange order, and format to the receiver through an application program; Checking, by the receiver, whether a use case of the sequence message is implemented in an application program, and transmitting a confirmation message to the transmitter; And the transmitting unit and the receiving unit exchange messages of a format defined in the sequence message according to a message exchange order defined in the sequence message. The message exchange method of claim 1, wherein a format of the message and a component of the message are predefined in an application program of the transmitter and the receiver. The method of claim 1, wherein versions of an application protocol implemented by an application program of the transmitter and the receiver are different from each other. 2. The method of claim 1, wherein an identifier is used to define the message exchange order. 2. The method of claim 1, wherein the message format is one of DTD and XML. The message exchange method of claim 1, further comprising transmitting an end message through an application program at one of the transmitter and the receiver. The method of claim 1, wherein the transmitter is a telematics device and the receiver is a service server.

Images