KR20080090250A - Message transmission method through interworking of heterogeneous messages - Google Patents

Abstract

Disclosed is a message transmission method through interworking heterogeneous messages having different transmission protocols. In the message transmission method according to an embodiment of the present invention, a first message and a second message having different transmission protocols are generated and transmitted as one unified message. In generating the unified message, header fields having a common function among the header fields of the first message and the header messages of the second message form an unified header part such that only the header fields of any one message are included. Do not duplicate common header fields. The integrated body part of the integrated message is configured to include data of the first message and the second message. According to this embodiment of the present invention, it is possible to transmit heterogeneous messages having different formats into a unified message having one unified format. Particularly, since unified messages do not include duplicate header fields having common functions, Efficient message transmission is possible.

Description

Method for transmitting messages through inter-working of different type messages}

The present invention relates to a message transmission service, and more particularly, to a method for transmitting a message through interworking between messages having different formats.

The message transfer service may be roughly classified into a text-based messaging service, a voice service, and a video service according to the type of a transport object. The text-based message service can be further divided into a one-way text-based service and a two-way text-based service, which include a short messaging service (Short Messaging Service, SMS), a multimedia messaging service (MMS), and an email ( E-mail) services, and the bi-directional text-based services include instant messaging services.

Each of the various message transfer services has its own protocol silo according to the type of service. That is, the message transmission services generate a message according to a transport protocol unique to each service, and process the received message according to a corresponding transport protocol. In addition, there may be one transport protocol that may be used for one message transmission service, and there may be many. As a result, the transmission protocol is different according to the type of the message transmission service, and even if the same message transmission service is different, the transmission protocol used may be different if the network where the message is transmitted is different. If the transmission protocol used is different, the format of the message generated according to each transmission protocol is also different. In this specification, messages having different formats due to different transport protocols used to generate and / or transmit a corresponding message are referred to as 'heterogeneous messages'.

In general, since one terminal supports various types of transport protocols, the number of types of messages, that is, heterogeneous messages, generated and transmitted through one terminal is large. At present, since the number of services provided by the terminal is diversified, the number of heterogeneous messages supported by one terminal is gradually increasing. However, in consideration of the performance of the terminal and the efficiency of message transmission, it is not very efficient to separately generate and transmit many kinds of heterogeneous messages according to its own transmission protocol. Accordingly, a new message transmission procedure for generating and processing an integrated message according to any one transport protocol is required through mutual interaction between two or more heterogeneous messages.

Meanwhile, the Internet Protocol Multimedia Subsystem (IMS) is attracting attention as a core information communication technology for providing new multimedia services in an Internet Protocol (IP) based next generation communication environment. IMS is a set of nodes that provide various multimedia services and perform call control in the environment of mobile communication network, and make it possible to provide IP-based multimedia service using user terminal by facilitating interoperability between user terminal and IP network. give.

As IMS has emerged as a next-generation core information and communication technology, studies are being actively conducted to provide existing message transmission services through IMS network. This means that existing service messages, such as MMS messages, are transmitted in accordance with a transport protocol that can be used for IP-based multimedia services over an IMS network. For example, MMS, which is a text-based messaging service capable of transmitting multimedia content such as text, pictures, and animations, is described as an example of the current Wireless Session Protocol (WSP) or Hyper Text Transfer Protocol (HTTP). Is used as the transport protocol. On the other hand, one of the transport protocols applicable to the IMS network is the Session Initiation Protocol (SIP). SIP is an application layer call control protocol for creating, modifying and terminating an IP-based multimedia service session between a user terminal or between a user terminal and an entity having an IP address. .

According to the existing message transmission method proposed to provide a service message such as an MMS message through an IMS network, an MMS protocol data unit (PDU) is encapsulated in a body part of a SIP MESSAGE. Encapsulation) to transmit. However, in this method, since the capacity of data that can be included in the body part of the SIP MESSAGE is limited to a predetermined size (for example, 1300 bytes), when the size of the MMS PDU to be transmitted is larger than the predetermined size, SIP MESSAGE cannot be used. Therefore, in this case, the MMS PDU is transmitted using WSP / HTTP as in the conventional method.

1 is a diagram illustrating a format of a message in which an MMS PDU is encapsulated in a body part of a SIP MESSAGE. In FIG. 1, the SIP MESSAGE 10 on the left side is a case where data, that is, multimedia content is included in the MMS PDU, and the SIP MESSAGE 10 on the right side is no data. Referring to FIG. 1, the SIP MESSAGE 10 includes a header part (SIP MESSAGE Header) 12 and a body part (SIP MESSAGE Payload) 14, and the body part 14 includes a header part 14a of an MMS PDU. Both the body part 14b and the body part 14b are encapsulated, or only the header part 14a of the MMS PDU is encapsulated.

However, the existing message transmission method using different transport protocols according to the size of the MMS PDU has the following two problems.

The first problem is that since the SIP MESSAGE 10 of the format shown in FIG. 1 includes header information of both heterogeneous messages, header fields that perform the same function may be duplicated. More specifically, there is a duplication of functions among the SIP header field included in the header part 12 of the SIP MESSAGE and the MMS header fields included in the header part 14a of the MMS PDU. The SIP MESSAGE 10 shown in Fig. 2 includes both header fields regardless of whether the functions are common. Table 1 shows an example of header fields where functions are common to each other in the header part 12 of the SIP MESSAGE and the header part 14a of the MMS PDU. As a result, the existing message transmission method of encapsulating the header part 14a of the MMS PDU and including it in the body part 14 of the SIP MESSAGE includes duplicate header fields that perform the same function. Unnecessarily increasing can reduce the transmission efficiency.

The second problem of the conventional message transmission method is that not all MMS PDUs can be transmitted using the same transport protocol. That is, according to the conventional method, when the size of the MMS PDU is smaller than 1300 bytes, SIP is used as a transport protocol, but when 1300 bytes or more is used, WSP / HTTP is used as the transport protocol. As a result, both the terminal and the server must support both SIP and WSP / HTTP as transport protocols, and for this purpose, they must have two types of protocol stacks and enablers, respectively. This complicates the configuration of the terminal and server.

One problem to be solved by the present invention is to prevent inefficient message transmission which can be caused by generating two or more heterogeneous messages of different formats according to their own transport protocols, and transmitting the same.

Another problem to be solved by the present invention is not only to prevent duplication of header information included in a transmission message even when transmitting a heterogeneous message, but also to transmit data according to the same transport protocol regardless of the size of the message. To provide a transmission procedure.

The message transmission method according to an embodiment of the present invention for achieving the above object is a method for transmitting a first message and a second message having different transmission protocols as one unified message, common header field of the first message And forming an integrated header part including only a common header field of any one of the common header fields of the second message, forming an integrated body part including data of the first message and the second message, and Generating and transmitting an integration message including the integration header part and the integration body part.

The message transmission method according to another embodiment of the present invention for achieving the above object is a method for transmitting a heterogeneous message having a different transmission protocol as a single integrated message, generating a first message, the message of the first message A message having a higher priority among the first message and the second message when the size is smaller than a predetermined threshold and there is a header field having a common function with the header field of the second message among the header fields of the first message. And including only the header field of the second message in the header part of the second message, and including the data of the first message in the body part of the second message.

According to an embodiment of the present invention, a new type of integrated message is configured and transmitted through the interworking of two or more heterogeneous messages having different formats, thereby enabling efficient message transmission. Particularly, in the embodiment of the present invention, header fields whose functions are duplicated among heterogeneous messages may be included in only one header field included in one message in the integrated message, thereby minimizing the size of the transmitted message and improving transmission efficiency. have.

According to the message transmission procedure through interworking heterogeneous messages according to an embodiment of the present invention, it is not only possible to efficiently transmit a service message such as an MMS message through another network (eg, an IMS network), It is possible to send a message using the same transport protocol regardless of the size of the message.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. The following embodiments are intended to illustrate the technical idea of the present invention by way of example, these embodiments should not be construed as limiting the scope of the invention.

First, a description will be given of a procedure for constructing an integrated message by interworking two or more heterogeneous messages according to the first embodiment of the present invention. Hereinafter, a description will be given of configuring an integrated message from two heterogeneous messages. However, embodiments of the present invention described below may be equally applicable to a configuration of an integrated message from three or more heterogeneous messages.

FIG. 2A illustrates the format of the first message 20 generated according to the first transmission protocol, and FIG. 2B illustrates the format of the second message 30 generated according to the second transmission protocol. The first and second transport protocols are different from each other, and therefore, the first message 20 and the second message 30 are heterogeneous messages having different formats. For example, the first transport protocol may be SIP and the second transport protocol may be WSP / HTTP, although the present embodiment is not limited thereto.

Referring to FIGS. 2A and 2B, the first message 20 and the second message 30 may include the first header part 22 and the first body part 24, the second header part 32, and the second message, respectively. Body part 34. The first header part 22 and the second header part 32 each include a plurality of header fields. Hereinafter, for convenience of description, the first header field 22 may include {a ₁ , a ₂ ,. , a _k , b ₁ , b ₂ ,... , b _l } and the second header field 32 indicates {c ₁ , c ₂ ,. , c _k , d ₁ , d ₂ ,. , d _m } Here, the first subset of the first header field 22 {a ₁ , a ₂ ,... , A _k} in the header fields that are part of its functions are, respectively, a second first portion of the header field 32 set {c _1, c _2, ... , c _k } equal to any one of the header fields (hereinafter, a header field having the same function in a message of a different format is called a 'common header field'). For example, the functions of the header field a ₁ and the header field c ₁ , the header field a ₂ and the header field c ₂ , and the header field a _k and the header field c _k may be common to each other. In contrast, the second subset of the first header field 22 {b ₁ , b ₂ ,... , b _l } is composed of header fields that do not have the same function in the second transport protocol and are unique to the first transport protocol, whereas the second subset of the second header field 32 {d ₁ , d ₂ ,.. , d _m } consists of header fields that do not have the same function in the first transport protocol and are unique to only the second transport protocol (hereinafter, in a message of a different format, the function is unique to that message). Fields are called 'unique head fields').

For example, assume that the first message 20 is a SIP MESSAGE and the second message 30 is an MMS PDU. In this case, the first header field 22 is {a ₁ , a ₂ ,... , a _k , b ₁ , b ₂ ,... , b _l } are header fields of SIP MESSAGE, and the second header field 32 is {c ₁ , c ₂ ,... , c _k , d ₁ , d ₂ ,. , d _m } are header fields of the MMS PDU. In addition, 'From', 'Subject', and 'Expires' disclosed in Table 1 above are common header fields {a ₁ , a ₂ ,... , a _k }, and 'M-Notification.ind.From', 'M-Notification.ind.Subject', and 'M-Notification.ind.Expiry' are also common header fields: {c ₁ , c ₂ , … , c _k }. In contrast, the unique header fields of SIP MESSAGE are {b ₁ , b ₂ ,... , b _l }, and the unique header fields of the MMS PDU are {d ₁ , d ₂ ,... , d _m }.

FIG. 3 is a diagram illustrating a configuration of an integrated message 40 that is an example of a message generated using the first message 20 and the second message 30. Referring to FIG. 3A, the integration message 40 includes an integration header part 42 and an integration body part 44.

The merge header part 42 is composed of the first header field 22 {a ₁ , a ₂ ,... , a _k , b ₁ , b ₂ ,... , b _l } and the second header field 32 {c ₁ , c ₂ ,... , c _k , d ₁ , d ₂ ,. , d _m }. More specifically, the unified header part 42 may include only the common header field of any one message among the common header fields of the two messages. The common header field of another message not included in the unified header part 42 may not be included anywhere in the unified message 40. In the above-described example, the header fields {a ₁ , a ₂ ,... , a _k } and the head field {c ₁ , c ₂ ,... in the second header field 32. , c _k } are the common header fields, respectively, so that the unified header part 42 is the {a ₁ , a ₂ ,... , a _k } and {c ₁ , c ₂ ,... , c _k } may include only one. For example, as shown in FIG. 3A, header fields {a ₁ , a ₂ ,... , a _k } may be included in the integration head part 42. And in this case the header fields {c ₁ , c ₂ ,... , c _k } are not included anywhere in the integration message 40. And the unified header part 42 may include the unique header fields {b ₁ , b ₂ ,...) Of the first message 20. , b _l } and the unique header field {d ₁ , d ₂ ,..., of the second message 30. , d _m } are included.

3, the integrated body part 44 includes integrated data generated by using the first data of the first body part 24 and the second data of the second body part 34. The integrated body part 44 may include both the first data and the second data, or may include only one, or may include new types of data generated by modifying the first data and the second data. In addition, only one of the first body part 24 and the second body part 34 may include data. In this case, the integrated body part 44 may include only the data.

According to one aspect of this embodiment, the integrated message 40 has the same format as the message generated according to the first transport protocol or the second transport protocol, ie the first message 20 or the second message 30. It may be a message. For example, when the first message 20 is a SIP-based message and the second message is an MMS message, the integrated message 40 may be a message using SIP or a message using WSP / HTTP. However, the integrated message 40 may have a different format than the message generated according to the first transmission protocol or the second transmission protocol.

According to the embodiment of the present invention described above, the integrated header part 42 includes both header fields corresponding to two types of transmission protocols. Such an embodiment is preferably applied when the Request For Comment (RFC) based on the same, such as a header field of an MMS PDU or a header field of a SIP-based message, is not limited thereto.

Next, a procedure of generating and transmitting an integrated message through interworking of heterogeneous messages according to a second embodiment of the present invention will be described. In an embodiment of the present invention described below, a service message, for example, an MMS message is transmitted through an IMS network as an example, but the present invention is not limited thereto. For example, the present invention can be equally applied to a case where a service message is transmitted through a network other than the IMS network, or a service message other than an MMS message is transmitted through the IMS network.

4 is a block diagram illustrating a system architecture for transmitting an MMS message through an IMS network according to an embodiment of the present invention. Referring to FIG. 4, the system architecture includes a terminal 100, a visited IMS core 200, and a home IMS core 300. The system architecture of FIG. 4 is a case where the terminal 100 accesses a visited IMS network. When the terminal 100 accesses a home IMS network, the visited IMS core 200 may be omitted.

The terminal 100 may be a device, a user equipment in a universal mobile telecommunication system (UMTS), a mobile station in a global system for mobile communication (GSM) or an inter standard-95 (IS-95). ) May be called, but the name is not particularly limited. The terminal 100 includes a controller 130 for controlling the operation of functional entities therein and a transceiver 130 for transmitting and receiving messages. The terminal 100 may also include one or more existing service message clients (not shown), such as an MMS client.

In addition, the terminal 100 according to an embodiment of the present invention further includes a unified messaging agent 120 which is a functional entity for generating and transmitting an integrated message through interworking of heterogeneous messages and processing a received integrated message. . That is, the unified messaging agent 120 is a functional entity for generating a unified message through interworking two or more heterogeneous messages according to an embodiment of the present invention. For example, the Unified Messaging agent 120 may be configured to include only common header fields included in any one of the heterogeneous messages of common message fields whose common functions are common among the header fields of the plurality of heterogeneous messages. Included in the header part, header fields included in other messages are not included anywhere in the unified message. The unique header fields of each of the heterogeneous messages are all included in the header part of the unified message, or only the unique header fields of some messages are included in the header part of the unified message, and the unique header fields of the remaining messages are the body part of the unified message. It can also be encapsulated in.

Since the present embodiment is for transmitting an MMS message through the IMS network, the integrated messaging agent 120 is a functional entity for inserting a service message such as an MMS PDU or the like into a message having a different format than that of a SIP-based message. You can see. For example, the unified message generated at unified messaging agent 120 can be a SIP-based message having the format shown in FIG. 3.

The visited IMS core or home IMS core (200, 300) is a set of control nodes for providing various multimedia services and SIP-based call control in a mobile communication network environment. The IMS cores 200 and 300 include a proxy call session control function (CSCF) 210 and 310 and an application server (AS) 200.

CSCF (210, 310) serves to register the terminal 100 and to route the SIP signaling to the appropriate server, generally according to its logical role P-CSCF (Proxy CSCF), S-CSCF (Serving CSCF), I-CSCF (Interrogating-CSCF) and the like. Among these, P-CSCF is the first contact point that is first passed for access to the IMS cores 200 and 300. The S-CSCF serves to actually handle various sessions in the IMS network and, when an integrated message is received, routes the session to the appropriate AS 320. In FIG. 4, only the CSCF necessary to describe an embodiment of the present invention, that is, the P-CSCF 210 of the visited IMS core 200 and the S-CSCF 310 and the AS 320 of the home IMS core 300 are shown. And the illustration of other functional entities is omitted. This is for convenience only. In addition, since signaling through the IMS cores 200 and 300 is performed according to a conventional signaling protocol, detailed descriptions of the signaling performed in each IMS core 200 and 300 or between the IMS cores 200 and 300 are described here. Description is omitted.

The AS 320 is a server for supporting various application services that can be provided through the IMS network. In the present embodiment, since an example for transmitting an MMS message through an IMS network is described as an example, the AS 320 includes an MMS relay or an MMS server. Therefore, when an embodiment of the present invention transmits another kind of service message through the IMS network, the AS 320 includes a server for the corresponding message transmission service. Next, a message transmission procedure using the system architecture shown in FIG. 4 will be described with reference to FIG. 5. 5 is a flowchart illustrating a procedure of transmitting an MMS PDU using a SIP or a SIP-based protocol according to an embodiment of the present invention.

Referring to FIG. 5, first, an MMS PDU, which is a service message to be transmitted through an IMS network, for example, an MMS message, is generated (S10). The MMS PDU may be generated by an MMS client separately provided in the terminal 100 or, according to an embodiment, by using another functional entity included therein by the unified messaging agent 120 of FIG. 4. have.

After creating an MMS PDU, a procedure for generating a SIP-based message into which an MMS PDU is inserted is performed. However, when using a SIP-based message that has a limitation on the size of a message that can be inserted such as SIP MESSAGE, the procedure for determining whether the size of the generated MMS PDU is greater than a predetermined threshold before generating the SIP-based message. First, it is performed (S20). If one of the SIP-based messages used is SIP MESSAGE, the threshold may be a size that can be inserted into SIP MESSAGE, eg 1300 bytes.

As a result of the determination in step S20, if the size of the MMS PDU is smaller than the threshold (eg, 1300 bytes), a SIP MESSAGE is generated (S30). The SIP MESSAGE generated in this step contains information only in a part of the header field of the header part, and no information is provided in the header field (for example, the content type header field) related to the data inserted into the body part in the header part. Not included. The body part of the SIP MESSAGE does not contain any data.

Next, a procedure of inserting the header field of the MMS PDU into the header part of the SIP MESSAGE is performed (S50). If all of the header fields of the MMS PDU are inserted into the header part of the SIP MESSAGE, the header fields of the generated SIP MESSAGE are duplicated. In the present embodiment, in order to prevent such a problem, the above-described rules described in the first embodiment of the present invention can be applied. In this case, SIP MESSAGE performs the function as an integrated message.

More specifically, among the header fields of the MMS PDU and the SIP MESSAGE, the function is common to include only the header field of the SIP MESSAGE in the header part of the unified message. That is, among the MMS PDU header fields, the function is common to the header field of the SIP MESSAGE, that is, the common header field of the MMS PDU is not included in the header part of the SIP MESSAGE. This gives priority to the common header field of the SIP MESSAGE among the common head field of the MMS PDU and the common header field of the SIP MESSAGE. The unique header field of the SIP MESSAGE and the unique header field of the MMS PDU are inserted into the header part of the SIP MESSAGE.

Subsequently, the content type header field (Content-Type) of the SIP MESSAGE is set to information indicating the type of content to be inserted into the body part of the SIP MESSAGE (S60). Since the present embodiment is for transmitting an MMS message using an IMS network, the content type header field may be set to information indicating multimedia content, for example, 'multipart / related'. Subsequently, multimedia content in the body part of the MMS PDU is inserted into the body part of the SIP MESSAGE as it is (S70), and then the remaining procedures for completing the SIP MESSAGE are performed according to a conventional procedure (S80). Since the detailed procedures in the above steps S70 and S80 are the same as in the prior art, detailed description thereof will be omitted here. As a result of step S80, an integrated message having the same format as that of the SIP MESSAGE is generated. An example of the generated integrated message is shown in FIG. 6A.

On the other hand, when it is determined in step S20 that the size of the MMS PDU is greater than or equal to the threshold, a procedure for transmitting a message is performed in a manner capable of transmitting a larger capacity message. One of the methods for transmitting a large capacity message through the IMS network is to first establish a SIP session between the sender and the receiver, and then transmit the message through the established SIP session. For example, using MSRP, which is one of the transport protocols for transmitting a message through a SIP session, a message having a capacity larger than a predetermined threshold (eg, 1300 bytes) can be transmitted. Therefore, in the embodiment of the present invention, a procedure (S41 to S43) of establishing a SIP session between a transmitting side and a receiving side is first performed. However, since a message transmission service such as MMS is generally performed without the other party's consent, it is preferable that the SIP session is automatically set up without the agreement of the side receiving the MMS PDU. This will be described in more detail below.

In order to establish a SIP session, first, the terminal 100, which is a transmitting party, generates a session invitation message (S41). The session invitation message may be SIP INVITE, for example. However, in order to automatically establish a SIP session through the transmission of a session invitation message, the transmitting side should inform the receiving side that the reason for establishing the SIP session is to transmit the MMS PDU. To this end, it is necessary to include information indicating the fact in the session invitation message, there is no particular limitation on how to include the information. For example, any one field included in the header part of the session invitation message may be used. More specifically, a method of defining an MMS feature tag (MMS Feature-tag) as 'mms-pdu' and inserting the MMS feature tag into a Contact Header field of a SIP INVITE may be used (S42). Alternatively, the information may be included by creating a new SIP header field for inserting the information instead of the existing SIP header field. FIG. 6B is a diagram illustrating an example of a header part of SIP INVITE in which an MMS feature tag defined as 'mms-pdu' is inserted into a contact header field. Subsequently, the transmitter transmits a session invitation message including information indicating that it is for transmitting the MMS PDU to the receiver (S43). The receiving side receiving the session invitation message confirms that the corresponding session invitation message is for transmitting the MMS PDU through the information included in the received message, and transmits an acknowledgment message, for example, a 200 OK message. In this way, after the exchange of the session invitation message and the acceptance message is made, a SIP session is established between the transmitting side and the receiving side of the MMS PDU. The sender transmits a message using a predetermined protocol (eg, MSRP) through the SIP session (S44). A detailed procedure of transmitting a message using the MSRP is irrelevant to the features of the present embodiment, and thus a detailed description thereof will be omitted.

Next, a procedure of transmitting an MMS message from the terminal 100 to an MMS relay or server (MMS Relay / Server) 320 through the IMS network using the SIP-based message generated according to the flowchart shown in FIG. 5 will be described. do.

FIG. 7 is a message flow diagram illustrating a procedure for transmitting an MMS message through an IMS network according to an embodiment of the present invention in the system architecture of FIG. 4. In the present embodiment, the size of the MMS PDU to be transmitted is smaller than a predetermined size, and then inserted into the SIP MESSAGE and transmitted from the terminal 100 to the MMS Relay / Server 320 which is one of the ASs of the IMS core 300. To show. In this embodiment, the terminal 100 is connected to the visited IMS network, and when the terminal 100 is connected to the home IMS network, the P-CSCF 200 is omitted from the message flow chart. Direct exchange of messages is made between the terminal 100 and the home IMS core 300.

First, a process of generating a SIP MESSAGE into which an MMS PDU is inserted in the terminal 100 is performed. When it is determined that the size of the MMS PDU to be transmitted is smaller than a predetermined size, for example, 1300 bytes, the terminal 100 interworks with the MMS PDU and the SIP MESSAGE message. MESSAGE). The integrated message is generated according to the procedure shown in steps S30 and S50 to S80 shown in FIG. 5, for example, and an example of the generated integrated message may be the SIP MESSAGE message shown in FIG. 6A.

The UE 100 transmits the SIP MESSAGE generated according to the conventional SIP protocol to the MMS Relay / Server 320 which is an application service (S101). More specifically, the terminal 100 transmits the generated SIP MESSAGE to the P-CSCF 210, and the P-CSCF 210 transfers the received SIP MESSAGE back to the S-CSCF 310. The S-CSCF 310 confirms that the received SIP MESSAGE is related to the MMS, and then transfers it to the MMS Relay / Server 320, which is an application server related to the MMS, among various application servers existing in the home IMS core 300. To pass.

According to the present embodiment, the S-CSCF 310 may recognize that the SIP MESSAGE received through various methods is related to the MMS. One way is to take advantage of the fact that the header field of the received SIP MESSAGE contains the unique header field of the MMS message (eg, a header field of the form 'X-Mmx-…').

After that, the procedure proceeds according to the normal message processing procedure defined in SIP. The procedure of steps S102 and S103 described below shows an example of a procedure of exchanging an acknowledgment message and an acknowledgment message between the AS 320 and the terminal 100, and embodiments of the present invention are not limited thereto. It is self-evident. Referring to FIG. 7, the MMS Relay / Server 320 transmits an acknowledgment message for the received SIP MESSAGE to the terminal 100 (S102). The acknowledgment message may be, for example, a 200 OK message, which is transmitted to the terminal 100 via the S-CSCF 310 and the P-CSCF 210. The terminal 100 receiving the acknowledgment message transmits an acknowledgment message, for example, an ACK message, to the AS 320 via the P-CSCF 210 and the S-CSCF 310.

The MMS Relay / Server 320 extracts and processes an MMS message from the received SIP MESSAGE. In this embodiment, there is no particular limitation on a specific procedure for processing the SIP MESSAGE received by the MMS Relay / Server 320. For example, the MMS Relay / Server 320 obtains various information necessary for transmitting an MMS message through a common header field of a SIP MESSAGA and a unique header field of an MMS PDU included in a header part of a SIP MESSAGE, and uses the same. The MMS PDU received according to the existing WSP / HTTP or SIP can be transmitted to a receiving UE (not shown).

8 is a message flow diagram illustrating a part of a process of providing an MMS through an IMS network according to another embodiment of the present invention in the system architecture of FIG. 4. This embodiment is different from the embodiment described with reference to FIG. 7 in that the size of the MMS PDU to be transmitted is greater than or equal to a predetermined size, so that a SIP session is first established and then an integrated message is transmitted through the established SIP session. According to this embodiment, MSRP, which is one of transport protocols for transmitting a message through a SIP session, is used. In this case, the MMS PDU is inserted into the MSRP SEND and transmitted, for example. Hereinafter, the present embodiment will be described focusing on differences from the embodiment described with reference to FIG. 7.

Referring to FIG. 8, the terminal 100 generates a session invitation message, for example, a SIP INVITE for establishing a SIP session, and the generated SIP INVITE is an MMS via the P-CSCF 210 and the S-CSCF 310. The relay / server 320 is transmitted (S201). The SIP INVITE includes information indicating that the message to be transmitted through the established SIP session is an MMS message. For example, the information may be a property tag in the contact header field of the SIP INVITE set to '+ mms-pdu', an example of which may be the message shown in FIG. 6B. The S-CSCF 310 delivers the received SIP INVITE to the MMS Relay / Server 320 among various ASs. For example, the S-CSCF 310 uses the information included in the contact header field to know that the message is related to the MMS. Can be.

In addition, the normal response procedure for the SIP INVITE proceeds to complete the procedure for establishing a SIP session. Steps S202 and S203 shown in Fig. 8 show an example of this response procedure. Referring to FIG. 8, the AS 320 transmits a 200 OK to the terminal 100 via the S-CSCF 310 and the P-CSCF 210 in response to the received SIP INVITE. The terminal 100 transmits an ACK to the AS 320 via the P-CSCF 210 and the S-CSCF 310 in response to the received 200 OK message. Through the exchange of the session invitation message and the response message, a one-way SIP session is established between the sender and the receiver.

Subsequently, the terminal 100 performs a procedure for transmitting the MMS PDU through the established SIP session. The MMS PDU may be transmitted using MSRP, which is one of message transmission protocols through a SIP session. To this end, the terminal 100 first generates an integrated message (ie, MSRP SEND with an MMS PDU inserted) through interworking of a message using MSRP, for example, MSRP SEND and an MMS PDU to be transmitted. The integrated message may be generated according to the configuration procedure of the integrated message according to the first embodiment of the present invention described above. An example of the generated integrated message is illustrated in FIG. 6C. Referring to FIG. 6C, the integrated message is a message having the same format as the MSRP SEND, and the header part further includes a unique header field of the MMS PDU. That is, among the header fields of the MMS PDU, the header field of the MSRP SEND has a common function, that is, the common header field of the MMS PDU is not included in the MSRP SEND. The body part of the integration message includes data in the body part of the MMS PDU.

8, the terminal 100 identifies the MSRP SEND with the MMS PDU inserted through the P-CSCF 210 and the S-CSCF 310 according to a normal message transmission procedure through a SIP session. Transmit to MMS Relay / Server 320 (S204). After that, the procedure proceeds according to the normal message processing procedure defined in SIP. For example, the MMS Relay / Server 320 sends an acknowledgment message such as a 200 OK message to the S-CSCF 310 and the P-CSCF 210. Is transmitted to the terminal 100 via).

The embodiments of the present invention described in detail above are merely illustrative of the technical idea of the present invention, and should not be construed as limiting the technical idea of the present invention by the embodiments. The protection scope of the present invention is specified by the claims of the present invention described later.

1 is a diagram illustrating a format of a message in which an MMS PDU is encapsulated in a body part of a SIP MESSAGE.

2A and 2B are diagrams schematically illustrating formats of heterogeneous messages generated according to different transport protocols and having different formats.

3 is a diagram illustrating an example of an integrated message generated using the message shown in FIG. 2A and the message shown in FIG. 2B.

4 is a block diagram illustrating a system architecture for transmitting an MMS message through an IMS network according to an embodiment of the present invention.

5 is a flowchart illustrating a procedure of transmitting an MMS PDU using SIP MESSAGE or MSRP according to an embodiment of the present invention.

6A illustrates an example of a SIP MESSAGE generated according to an embodiment of the present invention.

6B is a diagram illustrating an example of a SIP INVITE generated according to an embodiment of the present invention.

6C illustrates an example of an MSRP SEND generated according to an embodiment of the present invention.

7 is a message flow diagram illustrating a part of a procedure for transmitting an MMS message using SIP MESSAGE according to an embodiment of the present invention.

8 is a message flow diagram illustrating a part of a procedure for transmitting an MMS message using MSRP SEND according to another embodiment of the present invention.

Claims (9)

In the method of transmitting a first message and a second message different from each other in a single integrated message, The common function of the header field of the first message and the header field of the second message forms an integrated header part including only the header field of any one message, Forming an integrated body part comprising data of the first message and the second message, and And transmitting and generating an integrated message including the integrated header part and the integrated body part. The method of claim 1, wherein the integrated header part includes both a header field unique to the first message and a header field unique to the second message. 3. The method of claim 2, wherein the header field of the first message and the header field of the second message have the same Requests For Comments (RFCs). In a method for transmitting heterogeneous messages having different transport protocols in one unified message, Create a first message, In the case where the size of the first message is smaller than a predetermined threshold and there is a header field having a common function with the header field of the second message among the header fields of the first message, the first message and the second message may be used. Include only the header field of the high priority message in the header part of the second message, and And transmitting the data of the first message by including the data of the first message in a body part of the second message. The method of claim 4, wherein the first message is a multimedia messaging service (MMS) message, and the second message is a SIP-based message. 6. 5. The method of claim 4, wherein the header part further comprises a content type header field set as information indicating a data type of the first message. 6. 5. The interworking of heterogeneous messages according to claim 4, wherein the header field of which the function of the header field of the second message is not common in the header field of the first message is included in the header part of the second message. 6. How messages are sent via The method of claim 4, further comprising: generating and transmitting a session invitation message including a header field set as a property tag defining the first message when the size of the first message is larger than the threshold. Method of transmitting a message through the interworking of heterogeneous messages. The method of claim 8, Send the session invitation message to connect a Session Initiation Protocol (SIP) session between a sender and a receiver, and And transmitting the second message using a message session relay protocol (MSRP) through the SIP session.

Images