KR100430275B1 - The protocol for the multimedia message service and thereof method - Google Patents

Abstract

The present invention relates to a protocol for providing a multimedia service and an interworking method thereof, and more particularly, to interworking with an MMS proxy / relay server and an IP content server for providing a MMS (MULTIMEDIA MESSAGE SERVICE), as well as other MMS servers. It relates to a protocol for interworking.

The present invention provides a protocol for efficiently handling interworking between MMS servers or other servers other than MMS, and therefore, there is an effect of implementing a large-capacity, high-quality multimedia service.

In addition, the present invention, through the initial one session connection through the authentication process, there is an effect of maintaining the connected session.

Description

Protocol for providing multimedia service and interworking method {THE PROTOCOL FOR THE MULTIMEDIA MESSAGE SERVICE AND THEREOF METHOD}

The present invention relates to a protocol for providing a multimedia service and an interworking method thereof, and more particularly, an interworking between an MMS proxy / relay server and an IP (INTERNET PROTOCOL) content server for providing MMS (MULTIMEDIA MESSAGE SERVICE). It is about protocol for interworking with MMS server.

In the wireless terminal market, a WAP (WIRELESS APPLICATION PROTOCOL) 1.x standard has been enacted and used for a wireless data service that can provide IP processing and Internet services in a terminal.

The WAP method mainly provides a simple text menu type service optimized for a low bandwidth and low specification terminal. The SMS (SHORT MESSAGE SERVICE) used in GSM or IS-41 also has a short text message of about 100 bytes. The delivery service is performed.

MMS is to escape from the text-based service to accommodate a variety of high-quality multimedia, the system consists of a proxy / relay server for IP network interworking and multimedia message processing, and a server for storing and managing messages .

The MMS proxy / relay server uses the SMTP (SIMPLE MESSAGE TRANSFER PROTOCOL) and HTTP (HYPER TEXT TRANSFER PROTOCOL) protocols for interworking with the mail service and the WAP service currently performed in the IP network, and the other MMS proxy / relay. The SMTP protocol is also used for interworking between servers.

Figure 1 shows a conventional MMS protocol stack, as shown, MMS UA uses WSP (WIRELESS SESSION PROTOCOL), HTTP protocol for interworking with the MMS proxy / relay through the WAP gateway, respectively.

In addition, MMS proxy / relay uses the SMTP protocol widely known as the current mail protocol for interworking with other MMS proxy / relay.

The process of the MMS service is as follows.

First, a mail message to which a multimedia file sent by a message sender is received by using a mail server SMTP protocol through an internet network. At this time, the multimedia message processing unit refers to the mail recipient profile and converts mail parsing and media (text, image) in the mail to be optimized for the receiver terminal.

The profile information includes information on terminal usage, that is, whether MMS is supported, resolution, number of colors supported, memory capacity, and the like.

The MMS notifies the terminal of the arrival of the message. In this case, by using the HTTP protocol, a notification message (M-notification.ind) is transmitted to a terminal through a WAP session through interworking with WAP G / W (GATEWAY), or interworking with an existing SMSC (SHORT MESSAGE SERVICE CENTER). You can be notified of your arrival via text message.

The message arrival notification includes URI (UNIFORM RESOURCE INDICATOR) information in which the message is stored, and a scheduled transmission method that can deliver a message at a desired time by using a scheduling technique for managing the message arrival notification message as described above. Also used.

The terminal receiving the message arrival notification first transmits a response message (M-notifyresp.ind) to the notification message, and may receive, reject or delete the corresponding message.

If received, the HTTP GET method uses the URI of the message.

The MMS encapsulates the converted message in HTTP and delivers the message to the terminal through a WSP session.

On the contrary, it is also possible to convert the multimedia message (M-send.req) prepared by the terminal into an MMS message or a mail format in MMS and then transmit it to the Internet or MMS supporting terminal.

The above process is shown in FIG. Figure 2 shows a conventional MMS transaction flow, as shown, when the MMS UA (user terminal) to be sent to the M-Send.req message to MMS proxy / relay, MMS proxy / relay is a response message for this Send M-Send.conf to the user terminal and send the arrival notification message M-Notification to the receiving user terminal.

The receiver sends M-Notifyresp.ind a response message for arrival notification to MMS proxy / relay, or receives an actual MMS message M-retrieve.conf through a WSP GET request.

When the receiving user terminal receives the MMS message M-retrieve.conf, the response message M-Acknowedge.ind is transmitted to the MMS proxy / relay.

After that, when the MMS proxy / relay requests the sender for information on whether the message has been delivered to the receiver, the MMS proxy / relay transmits an acknowledgment message M-Delivery.ind to the sender.

However, in the prior art using the SMTP protocol as shown in FIG. 3 showing the interworking between the MMS proxy / relay and FIG. 4 showing the interworking between the MMS proxy / relay and the VAS server, one message transmission or reception is performed. In order to solve this problem, a number of transactions are required, which consumes a lot of system resources due to unnecessary bandwidth occupancy and frequent connection attempts of the network, and also causes transmission speed and efficiency degradation on the network.

In addition, unencrypted messages are less reliable when passing messages between users.

When interworking with a value added service (VAS) server that requires a large amount of processing, it is difficult to expect a smooth message transmission and reception with an existing server that can only transmit or receive simple text of low capacity such as HTTP.

An object of the present invention is to provide a protocol (hereinafter referred to as MMPP,) for interworking between MMS proxy / relay or MMS proxy / relay and a VAS server.

1 illustrates a conventional MMS protocol stack.

2 shows a conventional MMS transaction flow.

3 shows the interworking between the conventional MMS proxy / relay.

4 shows the interworking between the conventional MMS proxy / relay and the VAS server.

5 illustrates MMPP session connection and disconnection in the present invention.

Figure 6 shows a transaction according to each message type in the present invention.

Figure 7 shows the overall MMPP transaction between MMS RELAY in the present invention.

8 illustrates the transaction of ABSTRACT and LINKSTATE in the present invention.

The present invention for achieving the above object, in the protocol for interworking between MMS server or MMS server and other servers to provide MMS (MULTIMEDIA MESSAGE SERVICE) over an IP network or a wireless communication network, the protocol Is characterized by continuing to maintain a session with the first mutual connection, and mutual data transmission based on maintaining the session connection.

The present invention also relates to a method of interworking a protocol for providing a multimedia service between an MMS server or another server other than an MMS server through an IP network or a wireless communication network, the Mp-Connect.req for session connection at a sending server. Transmitting a message to a receiving server, transmitting a Mp-Connect.resp message, which is a response to the Mp-Connect.req message, to a sending server, and maintaining a session through connection establishment as described above. Sending / receiving MMPP message to each other, and sending and receiving the message of ending session, Mp-Close.Req message to the sending server, and sending the response message, Mp-Close.Resp message to the receiving server. It characterized in that it comprises a process of ending.

The present invention also provides a method for interworking a protocol for providing a multimedia service through an IP network or a wireless communication network. The method of transmitting a message from a user terminal to an MMSE or a VAS includes an MMP message transmitted from a user terminal. The MMS message (m-send.req) is transmitted to the MMSE or VAS server through the user terminal, and the MMS message (mp-delivery.req) is transmitted from the MMS proxy server to the VAS or MMSE. It characterized in that it comprises a process of transmitting to.

The present invention also relates to a protocol interworking method for providing a multimedia service through an IP network or a wireless communication network, when a user terminal 1 to a terminal 2 is to transmit a message, a session from the receiving MMS server to the sending MMS server Sending a connection request message (Mp-Connect.Req), sending a connection response message (Mp-Connect.Resp) from the sending server to the receiving server, making a session connection, and connecting the session to enable communication If so, the transmitting terminal 10 transmits a message (M-Send.Req) to the transmitting server, and the server transmits a response message (M-Send.Conf) to the terminal, and the transmitting side The server transmits the message (Mp-Send.Req) received from the terminal to the receiving server, the receiving server transmits a response message (M-Send.Conf) for this, and the receiving server at the receiving side Arrival notification message to the terminal (M- In the process of transmitting a notification message, the receiving terminal transmits a response message (M-Notifyresp.Ind), and when the receiving terminal requests an actual message (WSP GET), the server sends the actual message (M-Notify Resp. Ind). and a process of sending a response message (M-Acknowledge.ind) to the receiving terminal.

Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings.

SMTP, which is currently a protocol used in MMS proxy / relay servers or in a VAS, cannot use a connection keeping method, but in the present invention, a message structure consisting of a header and a body, a transmission flow and a connection protocol, The MMPP protocol, which consists of the user and message authentication part, authenticates through the initial mutual connection, and maintains the connected session while maintaining the message flow between MMS proxy / relay servers or the VAS server.

Maintaining such a session improves transmission efficiency by eliminating the overhead of connection / connection authentication per message.

In order to maintain such a session, a separate message must be added in addition to the existing MMS message.

Additional messages include Mp-Connect.req, Mp-Connect.resp, Mp-Close.req, and Mp-Close.resp, and the connection protocol of MMPP (MULTIMEDIA MESSAGE PEER TO PEER PROTOCOL), which is a protocol proposed by the present invention. Each function will be described with reference to FIG. 5.

5 illustrates MMPP session connection and disconnection. As shown, the VAS or MMS relay server 1 and the MMS relay server 2 is shown a session connection and disconnection.

First, the Mp-Connect.req message for session connection is sent to MMS relay server 2 from VAS or MMS relay server 1.

The Mp-Connect.req message includes user information (ID, PASSWORD) for authentication, and has a 'connect-type' field, which is a field for determining an initial session type. Is determined as follows.

1) SND_CON: Dedicated session for sending messages only.

2) RCV_CON: Dedicated session for receiving messages only.

3) DUP_CON: Session capable of both sending and receiving messages

In response to the Mp-Connect.req message, the MMS relay / server2 transmits the Mp-Connect.resp message to the VAS or the MMS relay / server1, and gives a session-ID to distinguish each session. .

Each session is classified by the given session-ID, and message classification by transaction is distinguished through a combination of the existing Transaction-ID and session-ID.

When the session is maintained through the connection setup as described above, the MMPP message is transmitted to and received from each other, ③, the actual request and response message follow the existing MMS message field and format as it is, and the session-ID field is added thereto.

After sending / receiving message, send Mp-Close.Req message, which is session termination message including session-ID of the session, to VAS or MMS relay / server1④, and reply message Mp-Close.Resp message to MMS relay / server2. Send to end the session.

By maintaining the session as described above, each message transaction can be made without disconnection every time, and the authentication problem of the connection state can be solved only by the first connection authentication (user authentication).

If there is no message flow for a certain period of time, MMS proxy / relay can reduce the unnecessary session connection by disconnecting by performing 'connect time out'.

Interworking with the existing MMS proxy / relay or IP content server that does not support MMPP is interworking using the SMTP protocol of the existing protocol, and interworking with the server that supports MMPP is interworking through MMPP.

The transmission flow in the MMPP will be described with reference to FIG. 6. 6 illustrates a transaction according to each message type. (A) When an MMS message is transmitted from an existing MMS agent terminal (MUA1), a corresponding MMS proxy / relay uses a MMPP protocol through a session in which the MMS message is received. Shows the transfer to proxy / relay, after which the same transaction flow as the existing MMS.

Send MMS message (m-send.req) to be transmitted from terminal 1 to terminal 2 to MMS proxy server 1 ①, MMS proxy server 1 sends this MMS message (mp-send.req) to the receiving server MMS proxy server ② and 2, and also transmits a message (m-send.conf) indicating that the MMS message (mp-send.conf) has been sent to the terminal 1.

The MMS proxy server 2 sends the MMS arrival notification message (m-notification.ind) sent to the terminal 2 and indicates that the message has been received by the MMS proxy server 1 (mp-send.conf). Send notification response message (m-notifyresp.ind) to MMS proxy server 2.

The terminal 2 receiving the MMS message requests the actual message from the MMS proxy server 2 (HTTP (GET)) ⑦, and the MMS proxy server 2 sends the actual message (m-retrieve.conf) to the terminal 2⑧.

The terminal 2 sends a response message (m-acknowedge.ind) to the actual message to the MMS proxy server 2 ⑨, and the MMS proxy server 2 to inform the MMS proxy server 1 that the message has been sent to the terminal 2 (mp-delivery.ind). ), And MMS proxy server 1 informs terminal 1 of this.

6 (b) shows a transaction transmitted to a MULTIMEDIA MESSAGE SERVICE ENVIRONMENT (MMSE) or a VAS server through an MMPP session in which an MMS message transmitted from a user terminal MUA is maintained.

In this case, the MMS message received at the MMS proxy / relay is called Mp-Send.Req, and the MMS message received at the VAS is called Mp-Delivery.Req.

When the user terminal transmits the MMS message (m-send.req) to the MMS proxy server ①, the MMS proxy server transmits the MMS message (mp-delivery.req) to the VAS or MMSE ②.

MMS proxy server confirms delivery by receiving response message (m-send.conf) for m-send.req message and response message (mp-delivery.conf) ④ for mp-delivery.req from ③, VAS or MMSE. Send a message (m-delivery.ind) to the user terminal ⑤.

7 shows the overall MMPP transaction between MMS RELAY servers in the present invention. As shown, assuming that a message is sent from a user terminal 1 (originator MMS UA) 10 to a user terminal 2 (recipient MMS UA) 40, the receiving side MMS server 30 at the receiving side MMS server 30 first. (originator MMS relay server) 20 sends a session connection request message Mp-Connect.Req including a field capable of bidirectional communication, and the sender server 20 transmits a connection response message Mp-Connect. Session connection is performed by sending Resp to a recipient MMS relay server 30 (S10).

When the session connection is maintained to enable bidirectional communication, the transmitting terminal 10 transmits a message (M-Send.Req) from the transmitting terminal 10 to the transmitting server 20, and the server responds to the response message (M-Send.Conf). Send to the terminal (S20).

The transmitting server 20 transmits a message (Mp-Send.Req) received from the terminal to the receiving server 30, and the receiving server transmits a response message (M-Send.Conf) thereto ( S30).

The receiving server 30 transmits an arrival notification message (M-Notification.Ind) to the receiving terminal 40, and the receiving terminal 40 transmits a response message (M-Notifyresp.Ind) thereto (S40). ).

When the receiving terminal 40 requests the actual message (WSP GET), the server 30 transmits the actual message (M-retrieve.conf) to the receiving terminal 40 (S50), and the receiving terminal 40 ) Sends a response message (M-Acknowledge.ind) for this (S60).

When the receiving server 30 transmits a delivery confirmation message (Mp-delivery.ind) to the transmitting server 20 to notify that the message has been delivered (S70), the transmitting server 20 transmits to the transmitting terminal 10. By transmitting the delivery confirmation message (M-delivery.ind) so that the user can know that the message has been delivered (S80).

When all messages are sent, the MMS relay server 30 sends a message (Mp-Close.req) requesting the end of the session, and the transaction is terminated by receiving a response message (Mp-Close.resp) from the counterpart server. (S90).

Mp-Query.Req for requesting summary information of MMS message, Mp-Query.Resp for the response message, Mp-Linkstate for requesting session state and response .Req and its response message, Mp-Linkstate.Resp, are added.

In addition, the message for each type used in the MMPP does not deviate from the message frame currently recommended by the WAP forum, and additional fields are further included in the existing MMS header.

The MMPP header also accepts the header of the existing MMS message as it is, and further includes an additional header field to be used in the network connection mechanism.

The additional header field includes a previously described session-ID field and an authentication key field.

The authentication key field is used for 64-bit or 128-bit user or message authentication. Upon initial connection, the user MMPP message of the field value can be divided into a number according to the message type.

For reference, Tables 1 to 12 show message formats added in MMPP.

The MMSE may receive a summary message of a message by querying a header or other summary information of a specific message while maintaining a connection.

In addition, the MMSE may transmit the ID of a specific message during the session maintenance state, and receive various types of information such as MMS message arrival time, notification message transmission time, MMS message transmission time and the like in response message form including header information of the corresponding message.

Query request operation of MMSE is performed by sending Mp-Abstract.Req message to MMS proxy / relay, and is responded through Mp-Abstract.Conf message containing actual MMS message information.

The actual message information is displayed in the body of Mp-Abstract.Res according to RFC822 message rules. Each summary that is displayed is the management of link status and MMPP authentication. It can be added and deleted, and the contents of the summary information can be adjusted by setting the Mp-Abstract.Req message query type.

As shown in FIG. 8, when the summary information (Mp-Abstract.Req) is transmitted to the MMS proxy / relay server from the MMSE capable of transmitting and receiving session maintenance status information, the server responds to the response message (Mp-Abstract.Conf). To the MMSE (T10).

The MMSE sends the Mp-Linkstate.Req message including the session ID to the MMS proxy / relay, and the MMS proxy / relay receiving the message responds to the MMSE with the information on the session in the Mp-Linkstate.Resp message. (T20), the MMSE may check the current connection type and connection state through the corresponding response message.

To check the link status, it is possible to send the ID of the session.

The header of the MMPP accepts the header of the existing MMS message as it is, and additionally includes a key field for user or message authentication. The key field has a 64-bit or 128-bit size and is used as a key value for user authentication, decryption, and message authentication. In particular, user authentication (or connection request server authentication) is the first time authentication in session maintenance with initial connection. You can keep that state through work.

The present invention provides a protocol for efficiently handling interworking between MMS servers or other servers other than MMS, and therefore, there is an effect of implementing a large-capacity, high-quality multimedia service.

In addition, the present invention, through the initial one session connection through the authentication process, there is an effect of maintaining the connected session.

Claims (19)

In the protocol for providing a multimedia service between the MMS server or another server other than the MMS server through an IP network or a wireless communication network, The protocol is a multimedia service, characterized in that the session connection message between the MMS server or another server other than the MMS server to continue to maintain the session in the first mutual connection, and the data transmission between each other based on the session connection maintenance. Protocol to provide. The method of claim 1, A server for maintaining a session connected to each other may query a header or other summary information of a specific message and receive the summary information of the corresponding message. The method of claim 1, The server, which is connected to each other and maintains a session, may receive various types of information such as MMS message arrival time, notification message transmission time, MMS message transmission time, etc., including header information of the corresponding message, by sending an ID of a specific message. Protocol for providing a multimedia service, characterized in that. The method of claim 1, The protocol is a protocol for providing a multimedia service, characterized in that to maintain the session on the first connection by removing the overhead of connection and authentication per message. The method of claim 4. The session maintenance is a protocol for providing a multimedia service, characterized in that if there is no message transmission and reception for a predetermined time. The method of claim 1, The header of the message of the protocol is a protocol for providing a multimedia service, characterized in that the additional header field of the session ID field and the authentication key field to the existing MMS message header. The method of claim 1, The actual message transmitted in the BODY portion of the message of the protocol is in accordance with the RFC822 protocol. In a method of interworking a protocol for providing a multimedia service through an IP network or a wireless communication network, Transmitting the Mp-Connect.req message for the session connection from the sending server to the receiving server; Transmitting a Mp-Connect.resp message, which is a response message to the Mp-Connect.req message, to a sender server; If the session is maintained through the connection setting as described above, the process of transmitting and receiving MMPP messages with each other, After the sending and receiving of the message, the process of sending the session termination message Mp-Close.Req message to the sending server, Method of interworking protocol for providing a multimedia service comprising the step of ending the session by sending a response message Mp-Close.Resp message to the receiving server. The method of claim 8, The Mp-Connect.resp message and the Mp-Close.resp message are interworking protocols for providing a multimedia service, characterized in that the session ID is assigned to distinguish each session. The method of claim 8, The Mp-Connect.req message interworking method for providing a multimedia service, characterized in that it comprises user information (ID, PASSWORD) for authentication. The method of claim 10, The Mp-Connect.req message has a 'connect-type' field, which is a field for determining an initial session type, and according to the value of this field, the corresponding session type is SND_CON: a dedicated session for message transmission only or RCV_CON: message reception only. Dedicated session or DUP_CON: A method for interworking with a protocol for providing a multimedia service, characterized in that determined as a session capable of both transmitting and receiving messages. In a method of interworking a protocol for providing a multimedia service through an IP network or a wireless communication network, The method for transmitting a message from the user terminal to the MMSE or VAS, MMS message transmitted from the user terminal is transmitted to the MMSE or VAS server through the MMPP session, Transmitting the MMS message (m-send.req) from the user terminal to the MMS proxy server, and transmitting the MMS message (mp-delivery.req) to the VAS or MMSE from the MMS proxy server. Interworking method of protocol for providing multimedia service. The method of claim 12, The session interworking method for providing a multimedia service, characterized in that the connection is maintained through the initial connection process. The method of claim 12, The MMS proxy server receives a response message (m-send.conf) for the m-send.req message and a response message (mp-delivery.conf) for mp-delivery.req from VAS or MMSE. A method of interworking with a protocol for providing a multimedia service, further comprising transmitting (m-delivery.ind) to a user terminal. In a method of interworking a protocol for providing a multimedia service through an IP network or a wireless communication network, Transmitting a session connection request message (Mp-Connect.Req) from the receiving MMS server to the sending MMS server when the user terminal 1 wants to send a message from the terminal 2 to the terminal 2; Sending a connection response message (Mp-Connect.Resp) from the sending server to the receiving server to perform a session connection; When the session connection is maintained to enable communication, the transmitting terminal 10 transmits a message (M-Send.Req) to the transmitting server, and the server transmits a response message (M-Send.Conf) thereto. Process, The transmitting server transmits a message (Mp-Send.Req) received from the terminal to the receiving server, and the receiving server transmits a response message (M-Send.Conf) to the receiving server; Transmitting an arrival notification message (M-Notification.Ind) from the receiving server to the receiving terminal, and transmitting a response message (M-Notifyresp.Ind) to the receiving terminal; When the receiving terminal requests the actual message (WSP GET), the server sends the actual message (M-retrieve.conf) to the receiving terminal, and the receiving terminal sends a response message (M-Acknowledge.ind) to the receiving terminal. Protocol interworking method for providing a multimedia service, characterized in that it comprises a process. The method of claim 15, The session connection request message (Mp-Connect.Req) further comprises a field for enabling bidirectional communication or one-way communication method of the protocol for providing a multimedia service. The method of claim 15, The Mp-Connect.Resp message interworking method for providing a multimedia service, characterized in that it further comprises a session ID to distinguish the session. The method of claim 15, When the receiving server sends a delivery confirmation message (Mp-delivery.ind) to the sending server to inform that the message has been delivered, the sending server sends a delivery confirmation message (M-delivery.ind) to the sending terminal Protocol interworking method for providing a multimedia service, characterized in that it further comprises. The method of claim 15, After the message transmission is completed, the MMS relay server transmits a message (Mp-Close.req) requesting the end of the session, and the transaction is terminated by receiving a response message (Mp-Close.resp) from the counterpart server. Protocol interworking method for providing a multimedia service, characterized in that it further comprises.