Abstract:
A method for retrieving an MMS message, to be executed at an MMS User Agent, involves: generating an MMS subscription request; sending said MMS subscription request to an MMS server; receiving an MMS notification of an MMS message from the MMS server; in response to receiving said MMS notification, generating an MMS message retrieval request for retrieving said MMS message; sending said MMS message retrieval request to the MMS Server; receiving an MMS message retrieval comprising said MMS message; and in response to receiving said MMS message retrieval from the MMS Server, sending an acknowledgment to the MMS Server. herein the improvement is that: The MMS subscription request is sent using a SIP method SUBSCRIBE. The MMS notification is received using a SIP method NOTIFY. The MMS message retrieval request is sent using a SIP method FETCH. The acknowledgment is sent using a SIP method INFORM.

Description:
FIELD OF THE INVENTION 
   The invention relates to retrieving and delivering of multimedia messages using the Session Initiation Protocol. 
   DISCUSSION OF BACKGROUND ART 
   Multimedia Messaging Service MMS has in its present form been defined in standard 3GPP TS 23.140 “3rd Generation Partnership Project; Technical Specification Group Terminals; Multimedia Messaging Service (MMS); Functional description; Stage 2 (Release 6)”. The architecture of the networks involved as well as functions of different modules, especially the MMS User Agent and the MMS Relay/Server (below referred to as MMS Server), are described in more detail therein. 
   Notifications of incoming MMS messages are delivered from the MMS server to the MMS User Agent by using WAP push. The MMS User Agent sends a WAP or HTTP GET in order to make the MMS server send an MMS message. 
   The transfer of Multimedia Messaging Services MMS messages is usually performed using the Wireless Application Protocol WAP or Hypertext Transport Protocol HTTP. Retrieval of an MMS message is then performed by sending a WAP or HTTP GET request, respectively. 
   Messaging services implemented for the IP Multimedia core network Subsystem IMS network are currently under discussion in the 3GPP. The IMS messaging services comprise messaging types immediate messaging, deferred delivery messaging, and session-based messaging. In immediate messaging, a message is delivered immediately from one user to another, whereas in deferred messaging it is delivered as soon as the recipient becomes available. In session-based messaging, a session has to be set up before any other communication can take place. 
   In the IMS network, the Session Initiation Protocol SIP is used for creating, modifying, and terminating sessions with one or more participants. Two methods defined in the SIP are SUBSCRIBE and NOTIFY. SUBSCRIBE is used by a subscriber terminal to subscribe to event packages at proxies or servers. Whenever an event belonging to the subscribed event package is triggered, the terminal is informed by using the SIP method NOTIFY. 
   It may be commercially of vital importance to be able to retrieve MMS messages directly from within IMS. This has, nevertheless and in spite of hard work, been impossible until now. 
   SUMMARY OF THE INVENTION 
   It is an objective of the invention to bring about new features to the Session Initiation Protocol SIP with which Multimedia Messaging Services MMS messages can be retrieved or delivered using the SIP protocol only. 
   The object of retrieving MMS messages using the SIP protocol can be achieved with a method according to the independent claim  1 , or by using a terminal according to the independent claim  4 . 
   The object of delivering MMS messages using the SIP protocol can be achieved with a method according to the independent claim  5 , or by using an MMS server according to the independent claim  8 . 
   Dependent patent claims describe various advantageous embodiments of the invention. 
   ADVANTAGES OF THE INVENTION 
   The devices and methods according to the invention enable using the SIP as single transport protocol for retrieving and delivering MMS messages. In this manner, the terminals do not need to have other protocols than SIP supported by their protocol stack, thereby helping to reduce manufacturing cost of the terminals. Further, because there are less protocols needed in the protocol stack, the probability for errors in the software is reduced, therefore also shortening testing period of the devices, resulting in a shorter time-to-market. 

   
     SHORT DESCRIPTION OF THE DRAWINGS 
     In the following, the preferred embodiments of the invention are described in more detail with reference to the accompanying drawings  1  to  4 , of which: 
       FIG. 1  shows a mobile network comprising also IP Multimedia core network Subsystem; 
       FIG. 2  shows the structure of a new SIP message used for retrieving or delivering an MMS message; 
       FIGS. 3   a  and  3   b  show the structure of two different SIP messages; and 
       FIG. 4  shows messaging ( 41 ) used for subscribing an event package, messaging ( 43 ) used for notifying a terminal upon receipt of an MMS message, and messaging ( 45 ) used for downloading an MMS message to a subscriber terminal. 
   

   DETAILED DESCRIPTION OF THE INVENTION 
     FIG. 1  shows a terminal  101  within a Radio Access Network RAN  11  of a mobile network  12 . The RAN  11  comprises a plurality of Base Stations BS  103  controlled by a Radio Network Controller RNC  105 , the terminal  101  communicating with the mobile network  12  wirelessly via a BS  103 . Typically, one mobile network  12  comprises a plurality of RNC  105 , but for simplicity  FIG. 1  shows only one such RNC  105 . 
   A terminal  101  has communication means  165 , preferably those as commonly used for radio communications, and all related means for enabling a successful communication with the mobile network  12 . Within the terminal  101 , the processing unit  170  uses the communication means  165  in order to transmit and receive data. Both data to be transmitted and data received are filtered via the protocol stack  175  before any further operations are performed on them. The terminal  101  may have a plurality of applications stored in its memory. These applications include also an MMS User Agent  180  which takes care of all MMS specific interactions between the home network  14  and the terminal  101 . The applications are run in the processing unit  170  and they use data obtained through the communication means  165  and filtered through the protocol stack  175 . 
   For packet traffic, the mobile network  12  comprises a Serving GPRS Support Node SGSN  107  and Gateway GPRS Support Node GGSN  109 . The terminal  101  obtains an IP address which is reserved up to the GGSN  109 . The traffic between the terminal  101  and the GGSN  109  goes then on the GPRS Tunneling Protocol GTP protocol layer through the SGSN  107  and the RAN  11 , wherein there are further specific radio interface layer protocols facilitating resource-efficient data transport over the air interface. As the skilled person appreciates, a more detailed description of the related protocols can be found in any of the various standards defining these mechanisms. 
   The terminal  101  may be roaming under mobile network  12  even though its home network  14  were elsewhere. The transmission of packet data is then performed either directly between the terminal  101  and its home network  14  or via any other network, especially the Internet  13 . 
   The home network  14  comprises a Home Service Server HSS  115  which includes subscriber data and knows under which mobile network  12  the terminal  101  is roaming. A Serving Call State Control Function S-CSCF  113  is located in the home network  14  of the terminal  101 . If the terminal  101  is roaming under another mobile network  12 , then the S-CSCF  113  of home network  14  is used via a Proxy Call State Control Function P-CSCF  111 . The P-CSCF  111  includes data about services subscribed for the terminal  101 ; this data has been transmitted from the S-CSCF  113  to the P-CSCF  111  as a response to a query sent by the P-CSCF  111 . 
   In mobile telecommunication systems, such as in GSM and UMTS, the SIP is used for the IP multimedia core network Subsystem IMS. The IMS includes P-CSCF  111 , S-CSCF  113 , and servers providing some of the services. Especially for MMS messages, MMS server  130  is used as the server providing all MMS related services. 
   The MMS server  130  comprises communication means  185  for communication between terminals  101 , with other MMS servers  130 , and with servers in the Internet  13 . The processing unit  190  of the MMS server  130  uses the communication means  185  as well as the protocol stack  195 . The protocol stack  195  comprises IMS protocols enabling provision of different services. The protocol stack  195  may further comprise an MMS specific part. The MMS server  130  is running an MMS application  196  which takes care of registering event packet subscriptions, notifying subscriber terminals of received MMS messages belonging to a subscribed event packet, and delivering MMS retrievals in response to receiving MMS retrieval requests. 
     FIG. 2  shows the structure of the MMS part of the new SIP messages  20  used for subscribing an event package, or retrieving or delivering an MMS message. The SIP message  20  comprises fields  21  (X-Mms_Message-Type),  22  (X-Mms-Transaction ID),  23  (X-Mms-MMS Version),  24  (To), and  25  (From). These fields  21  to  25  are usually carried in the header of the SIP message  20 . 
     FIGS. 3   a  and  3   b  show the structures of two different SIP messages  20 . The SIP message  20   a  used for carrying MMS subscription request message M 401  is shown in  FIG. 3   a  and comprises in its field  21  identifier “m-sreq” and further in field  36 A flag “yes”. The SIP message  20   b  used for carrying MMS subscription response message M 403  is shown in  FIG. 3   b  and comprises in field  21  identifier “m-sref”, and further an acknowledgement “OK” in field  36 B. 
   The skilled person appreciates that the examples shown in  FIGS. 2 ,  3   a , and  3   b  are schematic of their nature. More detailed description for all header and message formats can be found in IETF specifications RFC 3261 and 3265. RFC 3261 introduces the SIP and RFC 3265 introduces the SIP-Specific Event Notification. Both of these specifications define also the SIP methods later referred to in this description. 
   Dashed box  41  in  FIG. 4  shows how an event package is subscribed. The MMS User Agent  180  requests by sending MMS subscription request M 401  to the MMS Server  130  that the MMS Server  130  uses a SIP method NOTIFY for sending MMS notifications. MMS subscription request M 401  has a form of message  20   b  shown in  FIG. 3   b , and it is sent by the terminal  101  as soon as it has been switched on for the first time and has network coverage. The MMS subscription request M 401  is acknowledged by the MMS Server  130  with an MMS subscription response M 403 . 
   Dashed box  43  shows how the terminal  101  is informed upon receipt of MMS message N 404 . As soon as the MMS Server  130  receives the MMS message N 404  which belongs to a subscribed event package, it sends MMS notification M 405  to the MMS User Agent  180  informing it that the MMS message N 404  has arrived at the MMS Server  130 . The MMS User agent  180  responds to MMS notification M 405  with MMS notification response M 407 . 
   Dashed box  45  shows how the MMS message N 404  received by the MMS Server  130  can be downloaded to the terminal  101 . In response to the MMS notification M 405 , the MMS User Agent  180  can decide to download the MMS message N 404  by sending an MMS message retrieval request M 409  to the MMS Server  130 . MMS message retrieval request M 409  is a SIP FETCH message. 
   In response to receiving MMS message retrieval request M 409  the MMS Server  130  sends MMS message retrieval M 411  to the MMS Server  130 . MMS message retrieval M 411  includes the contents of MMS message N 404 . 
   The MMS User Agent  180  acknowledges the receipt of the MMS message retrieval M 411  by returning MMS message retrieval acknowledgement M 413 . In response to receiving MMS message retrieval acknowledgment M 413  the MMS Server  130  responds with acknowledgement M 417 . 
   MMS subscription request M 401 ; MMS subscription response M 403 ; MMS notification M 405 ; MMS notification response M 407 ; MMS message retrieval request M 409 ; MMS message retrieval M 411 ; and MMS message retrieval acknowledgement M 413  all have structures similar to those shown in  FIGS. 3   a  and  3   b  except that the value in field  21  is changed accordingly to identify the kind of the message. The structure of these messages is otherwise as defined in 3GPP, TS 23.140 already referred above. 
   Messages M 401  to M 417  communicated between the terminal  101  and the MMS Server  130  are routed via BS  103 , SGSN  107 , GGSN  109 , P-CSCF  111 , and S-CSCF  113 , if necessary. 
   For MMS subscription request M 401  the header field “event” is set to value “mms” identifying the purpose of the MMS subscription request M 401 , i.e. that the MMS User Agent  180  requests the MMS Server  130  to use the SIP method notify for sending MMS notifications M 405 . 
   As in MMS subscription request M 401 , also in MMS notification M 405  the header field “event” is set to value “mms”, this informing the terminal  103  about the incoming MMS notification in MMS notification M 405 . 
   Messages M 401  to M 417  comprise SIP-specific header fields and MMS level header fields. 
   The MMS subscription request M 401  is sent using the SIP method SUBSCRIBE. The MMS subscription request M 401  comprises an event identifier defining that the SIP method NOTIFY is to be used for sending MMS notifications M 405 . After receiving an MMS notification M 405 , the terminal  101  generates and sends an MMS message retrieval request M 409   
   In the first embodiment, the MMS level header fields are added to the header fields in the messages M 401  to M 417 . Then the S-CSCF  113  analyses the SIP headers of each incoming message. If any MMS-specific headers is detected, for example by detecting a keyword “X-Mms-” in the fields, the S-CSCF  113  routes the message to the MMS Server  130 . Similarly, all SIP messages received by the terminal  101  are checked for any MMS-specific headers, and if any is found, the message is passed to the MMS User Agent  180 . An advantage of such a header structure is that all both SIP and MMS headers have a similar format and coding. In particular for a SIP-only terminal this reduces the implementation effort since a single coding scheme can be applied to the SIP protocol stack as well as to the application level. 
   In the second embodiment, the header fields of the SIP messages comprise SIP-specific header fields only. In this approach the MMS information is an attachment of the SIP message. The S-CSCF  113  checks if the attachment is an MMS message. If in the header field “Content-Type:” a keyword “application/vnd.wap.mms-message” is detected, this is most probably the case, and the message is then routed to the MMS Server  130 . The header field “Content-Type:” of SIP messages received by the terminal  101  is in the same manner checked. If the header field comprises “application/vnd.wap.mms-message”. The SIP message is passed to the MMS User Agent  180 . An advantage of such a header structure and encoding is that in this manner a better compatibility with currently existing MMS systems can be achieved. In particular, terminals comprising a current MMS client software which is only ported to a SIP protocol stack, no extra encoder or decoder for processing the messages M 401  to M 417  is needed therefore making it easier to implement a terminal  101  supporting MMS functionalities. 
   Some of the acknowledgement messages, i.e. MMS subscription response M 403 , MMS notification response M 407 , and MMS message retrieval M 411  are 200 OK messages. Further, they comprise relevant MMS headers, and MMS message retrieval M 411  further includes the MMS message N 404  received by the MMS Server  130 . All these acknowledgement messages may either comprise SIP-specific header fields or in addition to the SIP-specific header fields also some MMS-specific header fields. In the former case the other data necessary is embedded in the payload. 
   The other acknowledgement messages, i.e. MMS message retrieval acknowledgement M 413  and acknowledgement M 417  are 200 OK messages too. Contrary to other 200 OK messages described above, they comprise no MMS-specific information. 
   LIST OF USED REFERENCE NUMERALS 
   
       
         11  Radio Access Network RAN 
         12  mobile network 
         14  home network 
         101  terminal 
         103  Base Station BS 
         105  Radio Network Controller RNC 
         107  Serving GPRS Support Node SGSN 
         109  Gateway GPRS Support Node GGSN 
         111  Proxy-Call State Control Function P-CSCF 
         113  Serving Call State Control Function S-CSCF 
         115  Home Service Server HSS 
         130  MMS Server 
         165  communication means 
         170  processing unit 
         175  protocol stack 
         180  MMS User Agent 
         185  communication means 
         190  processing unit 
         195  protocol stack 
         196  MMS application