WO2008120885A1 - Method for transmitting messages through inter-working of different type messages - Google Patents

Method for transmitting messages through inter-working of different type messages Download PDF

Info

Publication number
WO2008120885A1
WO2008120885A1 PCT/KR2008/001656 KR2008001656W WO2008120885A1 WO 2008120885 A1 WO2008120885 A1 WO 2008120885A1 KR 2008001656 W KR2008001656 W KR 2008001656W WO 2008120885 A1 WO2008120885 A1 WO 2008120885A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
message
header
integrated
messages
sip
Prior art date
Application number
PCT/KR2008/001656
Other languages
French (fr)
Inventor
Woo Jun Ye
Kang Suk Huh
Tae Soon Choi
Original Assignee
Lg Electronics Inc.
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

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways

Abstract

Provided is a method of transmitting messages through inter-working of different type messages. Specifically, first and second messages generated according to different transfer protocols from each other are generated in a form of an integrated message When the first message includes header fields performing the same functions as header fields of the second message, an integrated header of the integrated message includes one set of those header fields performing the same functions and does not include the other set of those header fields. And an integrated body of the integrated message includes data of each of the first message and the second message.

Description

Description

METHOD FOR TRANSMITTING MESSAGES THROUGH INTER- WORKING OF DIFFERENT TYPE MESSAGES

Technical Field

[1] The present invention relates to a message transfer service, and more particularly, to a method of transmitting messages through inter-working of different type messages. Background Art

[2] In general, message transfer services can be classified into text-based messaging services, voice services, and video services, according to the type of a transmitted object. The text-based messaging services can be sub-classified into unidirectional text-based messaging services and bi-directional text-based messaging services. The unidirectional text-based messaging services include a short messaging service (SMS), a multimedia messaging service (MMS), an E-mail service etc. The bi-directional text- based messaging services include instant messaging services etc.

[3] Each of the message transfer services described above has a unique protocol silo according to the type of a service. That is, each of the message transfer services generates messages and processes received messages, according to its unique transfer protocol. In addition, one message transfer service can use one transfer protocol or a plurality of transfer protocols. That is, a transfer protocol may differ according to the type of a message transfer service and, even in the same message transfer service, a transfer protocol used may differ when a network through which a message is transmitted is changed. When transfer protocols used differ, formats of the messages generated according to respective transfer protocols differ. In the present specification, messages having different formats due to different transfer protocols used to generate and/or transmit a corresponding message are referred to as 'different type messages.'

[4] In general, one terminal supports various types of transfer protocols and thus, various types of messages, that is, a plurality of different type messages, are generated and transmitted using the terminal. Currently, more services are provided using one terminal and thus, the number of different type messages supported in one terminal is gradually increasing. However, in terms of the performance of a terminal and message transmission efficiency, it is ineffective that each of the different type messages is independently generated and transmitted according to respective unique transfer protocols. Therefore, there is a need to develop a method of transmitting messages in order to generate and process an integrated message according to a protocol of any one of at least two different type messages, through inter- working of the different type messages. [5] Meanwhile, an internet protocol multimedia subsystem (IMS) is attracting attentions as a leading information communications technique for providing new multimedia services in an internet protocol (IP)-based next generation communications environment. The IMS is a set of nodes that provides various multimedia services and performs call control in a mobile communications network environment, and enables inter- working between a user's terminal and an IP network so as to provide an IP- based multimedia service using the user's terminal.

[6] As the IMS is regarded as a leading information communications technique for next generations, researches into techniques for providing conventional message transfer services through the IMS are actively carried out. This means transmitting of a conventional service message, for example, a MMS according to a transfer protocol that is used in an IP-based multimedia service through the IMS network. As for the MMS that is a text-based messaging service which enables transmission of multimedia contents, such as letters, images, or animations, the MMS uses as a transfer protocol a wireless session protocol (WSP) or a hyper text transfer protocol (HTTP). On the other hand, there are transfer protocols that can be applied to the IMS network. For example, a session initiation protocol (SIP) can be applied to the IMS network. The SIP is a call control protocol of an application layer, which searches for the location of a target entity to be communicated and generates, modifies, and ends an IP-based multimedia service between user's terminals or between a users' terminal and an entity with an IP address.

[7] According to a conventional method of transmitting a service message, such as an

MMS message, the MMS protocol data unit (PDU) is encapsulated in a body of SIP MESSAGE and the encapsulated MMS PDU is transmitted through the IMS network. However, this method has a limitation on the capacity of data encapsulated in the body of SIP MESSAGE. Specifically, the capacity of data encapsulated may be limited to a predetermined value, for example, 1,300 bytes. Therefore, when the size of MMS PDU to be transmitted is equal to or larger than the predetermined value, the SIP MESSAGE cannot be used. In this case, as in conventional techniques, WSP/HTTP is used to transmit MMS PDU.

[8] FIG. 1 illustrates the format of a message in which MMS PDU is encapsulated in the body of SIP MESSAGE. In FIG. 1, SIP MESSAGE 10 to the left is a case in which data, that is, multimedia contents are not included in the MMS PDU and SIP MESSAGE 10 to the right does is a case in which data are not included in the MMS PDU. Referring to FIG. 1, the SIP MESSAGE 10 includes an SIP MESSAGE header 12 and an SIP MESSAGE payload 14. And both a MMS PDU 14a header and a MMS PDU body 14b are encapsulated and included in the SIP MESSAGE payload 14 or only a MMS PDU 14a header is encapsulated and included in the SIP MESSAGE pay load 14.

[9] However, the conventional method of transmitting messages using different transfer protocol according to the size of MMS PDU to be transmitted has two problems. The first problem is that SIP MESSAGE 10 of FIG. 1 includes header information of two different type messages and thus header fields performing the same functions may be repeated. Specifically, even if some of the SIP header fields in SIP MESSAGE header 12 perform the same functions as some of the MMS header fields in the MMS PDU header 14a, the SIP MESSAGE 10 illustrated in FIG. 1 includes all the SIP header fields and the MMS header fields. Table 1 shows an example of same function- performing header fields of the SIP MESSAGE header 12 and the MMS PDU header 14a. That is, according to the conventional method of transmitting messages in which all the MMS header fields of the MMS header 14a are encapsulated and included in the SIP MESSAGE body 14, header fields performing the same functions are repeatedly included in the SIP MESSAGE 10. Therefore, the size of a transfer message is unnecessarily increased and the transmission efficiency may be decreased.

[10] Table 1

Figure imgf000005_0001

[H] The second problem of the conventional method of transmitting messages is that all MMS PDUs cannot be transmitted using the same transfer protocol. Specifically, according to the conventional method, when the size of the MMS PDU is smaller than 1,300 bytes, an SIP is used as a transfer protocol, but when the size of the MMS PDU is equal to or larger than 1,300 bytes, WSP/HTTP is used as a transfer protocol. As a result, each of a terminal and a server should support both SIP and WSP/HTTP as a transfer protocol. To this end, each of the terminal and the server should have two types of protocol stacks and enablers, which causes the terminal and the server to be more complex. Disclosure of Invention Technical Problem

[12] An objective of the present invention is to prevent an ineffective message transmission caused by generating and transmitting at least two different type messages having different formats according to respective unique transfer protocols.

[13] Another objective of the present invention is to provide a method of transmitting messages in which, even when different type messages are transmitted, header in- formation included in a transfer message may not be repeated and data can be transmitted according to the same transfer protocol irrespective of the size of the transfer message. Technical Solution

[14] According to an aspect of the present invention, there is provided a method of transmitting messages through inter-working of different type messages, specifically, transmitting first and second messages generated according to different transfer protocols from each other in a form of an integrated message, the method comprising: forming an integrated header comprising one set of header fields common to the first and second messages; forming an integrated body comprising data of each of the first and second messages; and generating and transmitting an integrated message comprising the integrated header and the integrated body.

[15] According to an aspect of the present invention, there is provided method of transmitting messages through inter-working of different type messages, specifically, transmitting first and second messages generated according to different transfer protocols from each other in a form of an integrated message, the method comprising: generating the first message; when the size of the first message is smaller than a predetermined threshold value and the first message comprises header fields performing the same functions as header fields of the second message, inserting header fields of a message having priority selected from the first and second messages to a header of the second message, and inserting data of the first message to a body of the second message.

Advantageous Effects

[16] According to an embodiment of the present invention, messages can be effectively transmitted by forming and transferring a new type of an integrated message through inter-working of at least two different type messages having different formats. Specifically, according to embodiments of the present invention, when header fields of one type of message perform the same functions as header fields of another type of message, only one set of header fields is inserted to the integrated message, and thus, the size of the message to be transmitted can be minimized and high transfer efficiency can be obtained.

[17] In addition, according to a method of transmitting through inter- working of different type messages according to an embodiment of the present invention, a service message, such as an MMS message, can be efficiently transmitted through other networks, for example, an IMS network, and messages can be transmitted using the same transfer protocol without any consideration of the size of the messages to be transmitted. Brief Description of the Drawings

[18] FIG. 1 illustrates the format of a message in which MMS PDU is encapsulated in a

SIP MESSAGE body.

[19] FIGS. 2 and 3 illustrate formats of different type messages having different formats generated according to different transfer protocols.

[20] FIG. 4 illustrates an example of an integrated message generated using the message illustrated in FIG. 2 and the message illustrated in FIG. 3.

[21] FIG. 5 shows a block diagram illustrating system architecture for transmitting an

MMS message through an IMS network, according to an embodiment of the present invention.

[22] FIG. 6 is a flow chart illustrating a method of transmitting MMS PDU using SIP

MESSAGE or MSRP, according to an embodiment of the present invention.

[23] FIG. 7 illustrates an example of SIP MESSAGE generated according to an embodiment of the present invention.

[24] FIG. 8 illustrates an example of SIP INVITE generated according to an embodiment of the present invention.

[25] FIG. 9 illustrates an example of MSRP SEND generated according to an embodiment of the present invention.

[26] FIG. 10 illustrates a message flow diagram illustrating a part of a method of transmitting an MMS message using SIP MESSAGE, according to an embodiment of the present invention.

[27] FIG. 11 illustrates a message flow diagram illustrating a part of a method of transmitting an MMS message using MSRP SEND, according to another embodiment of the present invention.

Best Mode for Carrying Out the Invention

[28] The present invention will now be described more fully with reference to the accompanying drawings, in which exemplary embodiments of the invention are shown. The invention may, however, be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the invention to those skilled in the art.

[29] First, a method of forming an integrated message through inter- working of at least two different type messages, according to a first embodiment of the present invention, will now be described in detail. In the current embodiment, the integrated message is formed from two different type messages. However, the current embodiment can also be applied when the integrated message is formed from at least three different type messages, which will be described in another embodiment of the present invention later.

[30] FIG. 2 illustrates the format of a first message 20 generated according to a first transfer protocol, and FIG. 3 illustrates the format of a second message 30 generated according to a second transfer protocol. The first transfer protocol and the second transfer protocol are different from each other, and thus, the first message 20 and the second message 30 are different type messages having different formats. For example, the first transfer protocol is a SIP, and the second transfer protocol is a WSP/HTTP. However, the current embodiment is not limited to the types of transfer protocols described above.

[31] Referring to FIGS. 2 and 3, the first message 20 includes a first header 22 and a first body 24, and the second message 30 includes a second header 32 and a second body 34. Each of the first header 22 and the second header 32 includes a plurality of header fields. Specifically, the first header 22 include first header fields denoted by al, a2, ... , ak, bl, b2, ... , bl and the second header 32 include second header fields denoted by cl, c2, ... , ck, dl, d2, ... ,dm. In this regard, a first subset {al, a2, ... , ak} of the first header fields consists of header fields performing the same function as header fields of a first subset {cl, c2, ... , ck} of the second header 32 (hereinafter, in different type messages, header fields performing the same functions are referred to as 'common header fields.') For example, the header field al performs the same function as the header field cl, the header field a2 performs the same function as the header field c2...a header field ak performs the same function as a header field ck. However, the second subset {bl, b2, ... , bl} of the first header fields consists of header fields which are unique for the first transfer protocol and the second subset {dl, d2, ... ,dm} of the second header fields consists of header fields which are unique for the second transfer protocol, (hereinafter, in different formats of messages, header fields that are unique for respective messages are referred to as 'unique head fields.')

[32] For example, let's assume that the first message 20 is SIP MESSAGE and a second message 30 is MMS PDU. In this case, the first header fields {al, a2, ... , ak, bl, b2, ... , bl} are header fields of the SIP MESSAGE, and the second header fields {cl, c2, ... , ck, dl, d2, ... ,dm} are header fields of the MMS PDU. In addition, 'From', 'Subject', and 'Expires' shown in Table 1 above are common header fields and belong to {al, a2, ... , ak}, and 'M-Notification.ind.From', 'M-Notification.ind.Subject', and 'M-Notification.ind.Expiry' are also common header fields and belong to {cl, c2, ... ,ck}. On the other hand, unique header fields of the SIP MESSAGE belong to {bl, b2, ... , bl}, and unique header fields of the MMS PDU belong to {dl, d2, ... ,dm}.

[33] FIG. 4 illustrates the format of an integrated message 40 generated using the first message 20 and the second message 30, according to an embodiment of the present invention. Referring to FIG. 4, the integrated message 40 includes an integrated header 42 and an integrated body 44.

[34] The integrated header 42 is generated using the first header fields {al, a2, ... , ak, bl, b2, ... , bl} and the second header fields {cl, c2, ... , ck, dl, d2, ... ,dm}. Specifically, the integrated header 42 includes only one set of common header fields. In other words, the other set of common header fields may not be included in any in the integrated header 42. In the previously described example, the first subset {al, a2, ... , ak} of the first header fields and the first subset {cl, c2, ... , ck} of the second header fields are common header fields, and thus the integrated header 42 may include the first subset {al, a2, ... , ak} or the first subset {cl, c2, ... , ck}. For example, as illustrated in FIG. 4A, the integrated head part 42 includes the header fields {al, a2, ... , ak}. In this case, the header fields {cl, c2, ... , ck} may not be included in any in the integrated message 40. The integrated header 42 includes the unique header fields {bl, b2, ... , bl} of the first message 20 and the unique header fields {dl, d2, ... ,dm} of the second message 30.

[35] Referring to FIG. 4, the integrated body 44 includes an integrated data generated using a first data of the first body 24 and a second data of the second body 34. The integrated body 44 may include the first data and the second data, one of the first data and the second data, or a new type of data generated by modifying the first data and the second data. Meanwhile, when only one of the first body 24 and the second body 34 include data, the integrated body 44 may include the data.

[36] According to an aspect of the current embodiment, the integrated message 40 may have the same format as a message generated according to the first transfer protocol or the second transfer protocol, that is, the first message 20 or the second message 30. For example, when the first message 20 is an SIP-based message and the second message 30 is an MMS message, the integrated message 40 can be the SIP-based message or WSP/HTTP-based message. However, the format of the integrated message 40 may be different from the format of the message generated according to the first transfer protocol or the second transfer protocol.

[37] As described above, according to the current embodiment of the present invention, the integrated header 42 includes header fields generated according to two types of transfer protocols. The current embodiment may be applied when header fields are based on the same requests for comment (RFC), for example, when header fields of MMS PDU and header fields of the SIP-based message are used. However, the current embodiment can also be applied to other cases.

[38] Then, a method of generating and transmitting an integrated message through inter- working of different type messages, according to a second embodiment of the present invention, will now be described in detail. The current embodiment will be described about a method of transmitting a service message, such as an MMS message, through an IMS network. However, the present invention is not limited to the description described above. For example, the present invention can be applied when a service message is transmitted through other networks instead of the IMS network, or when other service messages, instead of the MMS message, are transmitted through the IMS network.

[39] FIG. 5 shows a block diagram illustrating exemplary system architecture for transmitting an MMS message through an IMS network, according to an embodiment of the present invention. Referring to FIG. 5, the system architecture includes a terminal 100, a visited IMS core 200, and a home IMS core 300. In the system architecture of FIG. 5, the terminal 100 makes an access through a visited IMS network to a home IMS network. Meanwhile, when the terminal 100 makes an access directly to the home IMS network, the visited IMS core 200 may be omitted.

[40] The terminal 100 may be called a device, a user equipment of a universal mobile telecommunication system (UMTS), or a mobile station (MS) of a global system for mobile communication (GSM) or inter standard-95 (IS-95). However, the terminal 100 can also be called others. The terminal 100 includes a controller 110 controlling operation of functional entities in the terminal 100 and a transceiver 130 transmitting and receiving a message. The terminal 100 can include at least one conventional service message client (not shown), such as an MMS client.

[41] The terminal 100 according to the current embodiment of the present invention may further include an integrated messaging agent 120 that is a functional entity for generating and transmitting an integrated message through inter-working of different type messages and processing a received integrated message. That is, the integrated messaging agent 120 is a functional entity for generating an integrated message through inter-working of at least two different type messages according to an embodiment of the present invention. For example, when header fields of each of a plurality of different type messages perform the same functions, the integrated messaging agent 120 may include only one set of common header fields in a header of an integrated message, and other sets of common header fields may not be included in the header of the integrated message. In addition, the integrated messaging agent 120 may include all unique header fields of the different type messages in the header of the integrated message. Alternatively, the integrated messaging agent 120 may include unique header fields of some of the different type messages in the header of the integrated message, and encapsulates unique header fields of the other type messages and includes the encapsulated unique header fields in a body of the integrated message.

[42] In the current embodiment, an MMS message is transmitted through an IMS network, the integrated messaging agent 120 may act as a functional entity for inserting a service message, such as MMS PDU, to a message having a format different from that of the MMS PDU, such as an SIP-based message. For example, the integrated message generated by the integrated messaging agent 120 may be a SIP- based message having the format illustrated in FIG. 4.

[43] Each of the visited IMS core 200 and the home IMS core 300 is a set of control nodes providing various multimedia services using SIP and performing a SIP-based call control in a mobile communications network environment. The visited IMS core 200 includes a proxy call session control function (P-CSCF) 210, and the home IMS core 300 includes a serving call session control function (S-CSCF) 310 and an application server (AS) 320.

[44] The P-CSCF 210 and the S-CSCF 310 register the terminal 100 and route SIP signaling to an appropriate server. In general, CSCFs can be categorized into a proxy CSCF (P-CSCF), a serving CSCF (S-CSCF), an interrogating-CSCF (I-CSCF), according to a logical role. Among them, the P-CSCF is a first contact point which is first passed by to make an access to the visited IMS core 200 and the home IMS core 300. The S-CSCF substantially processes various sessions in the IMS network, and when an integrated message is received, the S-CSCF routes the received integrated message to an appropriate AS 320. FIG. 5 illustrates only CSCFs necessarily required to describe the current embodiment, that is, only the P-CSCF 210 of the visited IMS core 200 and the S-CSCF 310 and AS 320 of the home IMS core 300 are illustrated and other functional entities are not illustrated in FIG. 5. This is to easily describe the current embodiment. Herein, signaling through the visited IMS core 200 and the home IMS core 300 is performed according to a conventional signaling protocol. Therefore, signaling performed within each of the visited IMS core 200 and the home IMS core 300 or between the visited IMS core 200 and the home IMS core 300 will not be described in detail.

[45] The AS 320 is a server supporting various application services which can be provided through the IMS network. Since the current embodiment is described with reference to transmission of an MMS message through the IMS network, the AS 320 includes an MMS Relay/Server. Accordingly, when the current embodiment is applied to transmission of other kinds of service messages through an IMS network, the AS 320 includes a server for transmitting the message services.

[46] A method of transmitting messages using the system architecture illustrated in FIG.

5 will now be described in detail with reference to FIG. 6. FIG. 6 is a flow chart illustrating a method of transmitting an MMS PDU using a SIP or a SIP-based protocol, according to an embodiment of the present invention.

[47] Referring to FIG. 6, a service message that is to be transmitted through an IMS network, for example, MMS PDU that is an MMS message is generated (SlO). The MMS PDU may be generated by a client independently included in the terminal 100, or in other embodiments, by a functional entity including the integrated messaging agent 120 of FIG. 5.

[48] After the MMS PDU is generated, operations for generating a SIP-based message to which the MMS PDU is to be inserted are performed. However, when the SIP-based message that has a limitation on the size of a message to be inserted, which is the same as SIP MESSAGE, is used, before the SIP-based message is generated, it is determined whether the size of the generated MMS PDU is equal to or larger than a predetermined threshold value (S20.) When SIP MESSAGE is used as the SIP-based message, the threshold value may be the size of a memory to be able to be inserted to SIP MESSAGE, for example, 1,300 bytes.

[49] When the size of MMS PDU is smaller than the threshold value, for example, 1,300 bytes in operation S20, the SIP MESSAGE is generated (S30.) In the SIP MESSAGE generated in operation S30, only some of header fields of the header include information, data-related header fields of the header inserted to the body (for example, a contents-type header field) may not include any information. The body of the SIP MESSAGE may include no data.

[50] Then, header fields of MMS PDU are inserted to the header of the SIP MESSAGE

(S50.) When all the header fields of MMS PDU are inserted to the header of the SIP MESSAGE, a header of SIP MESSAGE to be generated include header fields performing the same functions. To prevent this problem, the current embodiment may use the rule described with reference to the first embodiment. In this case, the SIP MESSAGE acts as an integrated message.

[51] Specifically, among header fields common to MMS PDU and SIP MESSAGE, only one set of header fields of SIP MESSAGE is inserted to the header of the integrated message. That is, the other set of header fields of MMS PDU is not inserted to the header of SIP MESSAGE. In other words, among head fields common to MMS PDU and SIP MESSAGE, the common header fields of SIP MESSAGE have priority over the common header fields of MMS PDU. Unique header fields of SIP MESSAGE and unique header fields of MMS PDU are inserted to the header of SIP MESSAGE.

[52] Then, a contents-type header field of SIP MESSAGE is set as information indicating the type of contents inserted to the body of the SIP MESSAGE (S60.) Since the current embodiment is described with reference to transmission of MMS message through IMS network, the contents-type header field may be set as information indicating multimedia contents, for example, 'multipart/related.' Then, multimedia contents included in a body of MMS PDU are inserted to a body of SIP MESSAGE (S70), and then SIP MESSAGE is completed using a conventional method (S80). The operations S70 and S 80 may be the same as a conventional method and thus will not be described in detail herein. As a result of the operation S 80, the integrated message having the same format as SIP MESSAGE is generated. An example of the generated integrated message is illustrated in FIG. 7. In FIGS. 7-9, the underline is used only for emphasis.

[53] On the other hand, when the size of MMS PDU is equal to or larger than the threshold value in operation S20, operations for transmitting messages are performed using a method of transmitting a large message. To transmit a large message through the IMS network, for example, an SIP session is set between a transmitting side and a receiving side and then a message is transmitted through the set SIP session. For example, a message having a size greater than a predetermined threshold value, for example, 1,300 bytes can be transmitted by using MSRP that is a transfer protocol for transmitting messages through the SIP session. Therefore, according to the current embodiment, operations S41-S43 for setting SIP session between the transmitting side and the receiving side are performed first. In this regard, since, in general, message transmission services, such as MMS, are provided without the consent of the other party, the SIP session may be automatically set without the content of the side receiving MMS PDU, which will be described in detail.

[54] To set the SIP session, first, the terminal 100 acting as the transmitting side generates a session invitation message (S41). The session invitation message may be SIP INVITE. To automatically set SIP session by transmitting the session invitation message, however, the transmitting side should inform the fact that the SIP session is set to transmit MMS PDU to the receiving side. To this end, there is a need to insert information indicating the fact to the session invitation message. The information inserting method is not limited. For example, any one of header fields included in a header of the session invitation message can be used to inform the fact. Specifically, an MMS feature-tag is defined as 'mms-pdu', and the MMS feature-tag can be inserted to a contact header field of SIP INVITE (S42). Alternatively, instead of an existing SIP header field, a new SIP header field to which the information is to be inserted is generated and the information may be inserted to the new SIP header field. FIG. 8 is a view illustrating an example of a header of SIP INVITE in which an MMS feature-tag defined as 'mms-pdu' is inserted to the contact header field. Then, the transmitting side transmits to the receiving side the session invitation message including the fact that the SIP session is set to transmit MMS PDU to the receiving side (S43). The receiving side receives the session invitation message, identifies with the information included in the received message that the session invitation message is set to transmit MMS PDU, and transmits an approval message, for example, a 200 OK message to the receiving side. When the session invitation message and the approval message are exchanged as described above, SIP session is set between the transmitting side and receiving side of MMS PDU. Then, the transmitting side transmits a message using a predetermined protocol, such as MSRP, through the SIP session (S44). A method of transmitting messages using MSRP is not related to features of the current embodiment and thus will not be described in detail.

[55] Then, a method of transmitting an MMS message to the MMS relay/server 320 from the terminal 100 using the SIP-based message generated as illustrated in the flow chart of FIG. 6 through IMS network will now be described in detail.

[56] FIG. 10 is a message flow diagram illustrating a method of transmitting an MMS message through the IMS network, according to an embodiment of the present invention. According to the current embodiment, since the size of MMS PDU to be transmitted is smaller than a predetermined size, MMS PDU is inserted to SIP MESSAGE and then transmitted from the terminal 100 to the MMS relay/server 320 that is an AS of the home IMS core 300. In the current embodiment, the terminal 100 is connected to a visited IMS network. When the terminal 100 is connected to the home IMS core 300, the P-CSCF 210 illustrated in the message flow chart is omitted and the terminal 100 directly exchanges a message with the home IMS core 300.

[57] First, SIP MESSAGE including MMS PDU is generated in a terminal 100. When the size of MMS PDU to be transmitted is smaller than a predetermined size, for example, 1,300 bytes, the terminal 100 generates an integrated message (that is, an integrated message of SIP MESSAGE including MMS PDU) through inter- working of MMS PDU and SIP MESSAGE message. The integrated message is generated according to, for example, operations S30, and S50- S80 illustrated in 6, and an example of the generated integrated message may be the SIP MESSAGE message illustrated in FIG. 7.

[58] Then, the terminal 100 transmits the SIP MESSAGE generated according to a conventional SIP protocol to the MMS Relay/Server 320 acting as an AS (SlOl). Specifically, the terminal 100 transmits the generated SIP MESSAGE to the P-CSCF 210, and the P-CSCF210 transmits the received SIP MESSAGE to the S-CSCF 310. Then, the S-CSCF 310 identifies whether the received SIP MESSAGE is related to MMS and transmits the SIP MESSAGE to the MMS Relay/Server 320 of the home IMS core 300. The MMS Relay/Server 320 is an application server relating to MMS. The home IMS core 300 includes, in addition to the MMS Relay/Server 320, an AS related to MMS, other types of application servers.

[59] According to the present embodiment, the S-CSCF310 may identify that the received SIP MESSAGE is related to MMS, using various methods. For example, for identification, the S-CSCF310 may use the fact that header fields of the received SIP MESSAGE include a unique header field of MMS message (for example, a header field having the type of 'X-Mmx- ...')

[60] Then, a conventional message process method according to SIP is used. Operations S 102 and S 103 exemplarily show the exchange of an acknowledgement message and an approval message between the MMS Relay/Server 320 and the terminal 100, and the present invention is not limited thereto. Referring to FIG. 10, the MMS Relay/ Server 320 transmits an acknowledgement message for the received SIP MESSAGE to the terminal 100 (S 102). The acknowledgement message may be, for example, a 200 OK message, and the 200 OK message is transmitted to the terminal 100 through the S-CSCF 310 and the P-CSCF 210. When the terminal 100 receives the acknowledgement message, the terminal 100 transmits an approval message, for example, an ACK message to the MMS Relay/Server 320 through the P-CSCF 210 and the S-CSCF 310.

[61] The MMS Relay/Server 320 extracts an MMS message from the received SIP

MESSAGE and processes the extracted MMS message. In the current embodiment, the received SIP MESSAGE is processed using unlimited methods in the MMS Relay/ Server 320. For example, the MMS Relay/Server 320 obtains various types of information required to transmit the MMS message by using common header fields of SIP MESSAGE and unique header fields of MMS PDU in a header of SIP MESSAGE, and transmits MMS PDU received according to conventional WSP/HTTP or SIP to an UE(not shown) of the receiving side transmission using the obtained information.

[62] FIG. 11 illustrates a message flow diagram illustrating a part of a method of transmitting an MMS message through IMS network in the system architecture of FIG. 5, according to another embodiment of the present invention. The current embodiment is the same as the embodiment which has been described with reference to FIG. 10, except that since the size of MMS PDU to be transmitted is equal to or larger than a predetermined size, a SIP session is set and then an integrated message is transmitted through the set SIP session. The current embodiment uses MSRP that is a protocol for transmitting messages through SIP session. In this regard, MMS PDU is inserted to, for example, MSRP SEND and then transmitted. Hereinafter, the current embodiment will now be described in detail with reference to the difference from the embodiment which has been described with reference to FIG. 10.

[63] Referring to FIG. 11, a terminal 100 generates a session invitation message for setting an SIP session, for example, SIP INVITE and the generated SIP INVITE is transmitted to an MMS Relay/Server 320 through a P-CSCF 210 and an S-CSCF 310 (S201). The SIP INVITE includes information indicating that a message to be transmitted though the SIP session to be set is an MMS message. For example, the information is formed by setting a feature tag of a contact header field of SIP INVITE as '+mms-pdu,' and an example of the information may be the message illustrated in FIG. 8. The S-CSCF 310 may transmit the received SIP INVITE to the MMS Relay/Server 320 among various ASs. The S-CSCF 310 may identify that the message is related to MMS using, for example, information included in the contact header field.

[64] Then, a conventional reply method is used with respect to the SIP INVITE, thereby completing the method of setting an SIP session. Operations S202 and S203 illustrated in FIG. 11 show an example of the reply method. Referring to FIG. 11, the MMS Relay/Server 320 transmits 200 OK that is a reply message for the received SIP INVITE to the terminal 100 through the S-CSCF 310 and the P-CSCF 210. The terminal 100 transmits ACK that is a replay message for the received 200 OK message to the AS 320 through the P-CSCF 210 and the S-CSCF 310. Through the exchange of the session invitation message and the reply message, a unidirectional SIP session is set between the transmitting side and the receiving side.

[65] Then, the terminal 100 performs operations for transmitting MMS PDU through the set SIP session. The MMS PDU may be transmitted using MSRP that is a protocol for transmitting messages through the SIP session. To this end, the terminal 100 generates a message using MSRP, for example, an integrated message through inter- working between MSRP SEND and MMS PDU to be transmitted (that is, MSRP SEND including MMS PDU.) The integrated message may be generated according to the method of generating an integrated message according to the first embodiment described above, and an example of the generated integrated message is illustrated in FIG. 9. Referring to FIG. 9, the integrated message has the same format as MSRP SEND, and a header of the integrated message further includes unique header fields of MMS PDU. That is, among header fields of MMS PDU, header fields of MMS PDU performing the same functions as header fields of MSRP SEND, that is, common header fields of MMS PDU are not included in MSRP SEND that is the integrated message. A body of the integrated message includes data of a body of MMS PDU.

[66] Referring to FIG. 11, the terminal 100 transmits MSRP SEND including MMS

PDU to the MMS Relay/Server 320 that is an AS through the P-CSCF 210 and the S- CSCF 310 according to a conventional message transmission method using the SIP session (S204). Then, a conventional message process method according to a SIP is used. For example, the MMS Relay/Server 320 transmits an acknowledgement message, for example, a 200 OK message to the terminal 100 through the S-CSCF 310 and the P-CSCF 210.

[67] While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present invention as defined by the following claims. Industrial Applicability [68] The present invention relates to a message transfer service using a wireless communications network.

Claims

Claims
[1] A method of transmitting messages through inter-working of different type messages, specifically, transmitting first and second messages generated according to different transfer protocols from each other in a form of an integrated message, the method comprising: forming an integrated header comprising one set of header fields common to the first message and second messages; forming an integrated body comprising data of each of the first and second messages; and generating and transmitting the integrated message comprising the integrated header and the integrated body. [2] The method of claim 1, wherein the integrated header further comprises unique header fields of the first message and unique header fields of the second message. [3] The method of claim 2, wherein the common and unique header fields of the first message and the common and unique header fields of the second message are based on the same requests for comments (RFC). [4] A method of transmitting messages through inter-working of different type messages, specifically, transmitting first and second messages generated according to different transfer protocols from each other in a form of an integrated message, the method comprising: generating the first message; inserting header fields of a message having priority selected from the first and the second messages to a header of the second message, when the size of the first message is smaller than a predetermined threshold value and the first message comprises header fields performing the same functions as header fields of the second message, and transmitting the second message with data of the first message inserted to a body of the second message. [5] The method of claim 4, wherein the first message is multimedia messaging service (MMS) message, and the second message is a SIP-based message. [6] The method of claim 4, wherein the header further comprises a content-type header field which is set as information indicating a type of data of the first message. [7] The method of claim 4, wherein unique header fields of the first message performing functions different from header fields of the second message are inserted to the header of the second message. [8] The method of claim 4, when the size of the first message is equal to or larger than the threshold value, further comprising generating a session invitation message comprising a header field having a feature tag defining the first message. [9] The method of claim 8, wherein the session invitation message is transmitted to connect a transmitting side to a receiving side through a session initiation protocol (SIP) session, and the second message is transmitted using a message session relay protocol
(MSRP) through the SIP session.
PCT/KR2008/001656 2007-04-02 2008-03-25 Method for transmitting messages through inter-working of different type messages WO2008120885A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US90967307 true 2007-04-02 2007-04-02
US60/909,673 2007-04-02
KR10-2007-0092059 2007-09-11
KR20070092059A KR20080090250A (en) 2007-04-02 2007-09-11 Method for transmitting messages through inter-working of different type messages

Publications (1)

Publication Number Publication Date
WO2008120885A1 true true WO2008120885A1 (en) 2008-10-09

Family

ID=39808440

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2008/001656 WO2008120885A1 (en) 2007-04-02 2008-03-25 Method for transmitting messages through inter-working of different type messages

Country Status (1)

Country Link
WO (1) WO2008120885A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010096922A1 (en) * 2009-02-27 2010-09-02 Research In Motion Limited Systems and methods for protecting header fields in a message
WO2010096921A1 (en) * 2009-02-27 2010-09-02 Research In Motion Limited Systems and methods for protecting header fields in a message
US8326931B2 (en) 2009-02-27 2012-12-04 Research In Motion Limited Systems and methods for protecting header fields in a message
US8499045B2 (en) 2009-02-27 2013-07-30 Research In Motion Limited Systems and methods for protecting header fields in a message

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002100066A1 (en) * 2001-06-06 2002-12-12 Nokia Corporation Method and device for messaging
US6804238B1 (en) * 1998-12-29 2004-10-12 International Business Machines Corporation System and method for transmitting compressed frame headers in a multiprotocal data transmission network
WO2008048829A2 (en) * 2006-10-17 2008-04-24 Fiberweb Simpsonville, Inc. Apertured nonwoven fabric and process and apparatus for producing same

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6804238B1 (en) * 1998-12-29 2004-10-12 International Business Machines Corporation System and method for transmitting compressed frame headers in a multiprotocal data transmission network
WO2002100066A1 (en) * 2001-06-06 2002-12-12 Nokia Corporation Method and device for messaging
WO2008048829A2 (en) * 2006-10-17 2008-04-24 Fiberweb Simpsonville, Inc. Apertured nonwoven fabric and process and apparatus for producing same

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010096922A1 (en) * 2009-02-27 2010-09-02 Research In Motion Limited Systems and methods for protecting header fields in a message
WO2010096921A1 (en) * 2009-02-27 2010-09-02 Research In Motion Limited Systems and methods for protecting header fields in a message
US8326931B2 (en) 2009-02-27 2012-12-04 Research In Motion Limited Systems and methods for protecting header fields in a message
US8463863B2 (en) 2009-02-27 2013-06-11 Research In Motion Limited Systems and methods for protecting header fields in a message
US8499045B2 (en) 2009-02-27 2013-07-30 Research In Motion Limited Systems and methods for protecting header fields in a message
US9350689B2 (en) 2009-02-27 2016-05-24 Blackberry Limited Systems and methods for protecting header fields in a message

Similar Documents

Publication Publication Date Title
US20040243680A1 (en) System, apparatus, and method for providing multi-application support using a single protocol stack
US20070259651A1 (en) Method and system of forwarding capability information of user equipment in Internet Protocol Multimedia Subsystem network
US20050050194A1 (en) Method and system for proxying a message
US20060203979A1 (en) Transferring state information in a network
US20060050648A1 (en) Reducing storage requirement for route information
US20090013078A1 (en) Optimized Signaling Protocol, Including Session Initiation Protocol (SIP), in a Communications Environment
US20070184860A1 (en) Mechanism for controlling a transmission of data messages to user equipment by an external gateway
US20100093346A1 (en) Session update using management of capability of terminal
US20050226174A1 (en) Method and apparatus to convey a URI for content indirection use in SIP
US20040103157A1 (en) Store-and-forward server and method for storing and forwarding for instant messaging service implemented in IP multimedia core network subsystem (IMS)
US20100087215A1 (en) Method, system, and message service interworking module for implementing message service interworking
US7701974B2 (en) Routing information processing for network hiding scheme
US20110072099A1 (en) message delivery mechanism
CN1929457A (en) Method for message intercommunication of IMS domain and CS domain
US20070076751A1 (en) Method and apparatus for instant messaging
US20090075642A1 (en) Method and devices for relayed peer-to-peer communications between terminals in mobile networks
US7574203B2 (en) Method for retrieving and delivering multimedia messages using the session initiation protocol
US20100077057A1 (en) File Transfer in Conference Services
EP1672866A1 (en) Method and system to the instant transfer of multimedia files between mobile radio users within the scope of combinational services
US20100011069A1 (en) Exchange of messages and sessions
US20100169483A1 (en) Capability Service in Communications System
US20100215036A1 (en) Method for transferring session in converged internet protocol messaging system
US20100023625A1 (en) Terminal unit for handling session on the basis of session initiation protocol, method of transmitting and receiving thereof
US20080114850A1 (en) Method and Arrangement for Communicating Multimedia Content
WO2010099829A1 (en) Capability query handling in a communication network

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08723692

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08723692

Country of ref document: EP

Kind code of ref document: A1