MMS Architecture and  Transaction Flows Mobile Messaging  G. Le Bodic PART 5
Course Contents Part 8 Instant Messaging and IMS Messaging Part 7 Mobile Email Day 2 Day 1 Part 6 MMS: Design of multimedi...
MMS Architecture and  Transactions Flows <ul><li>Architecture of MMS </li></ul><ul><ul><li>Interfaces </li></ul></ul><ul><...
MMS architecture
MMS interfaces (1/3) <ul><li>The  MM1 interface  is a key interface in the MMS environment. It allows interactions between...
MMS interfaces (2/3) <ul><li>The  MM4 interface  is the interface between two MMSCs. This interface is necessary for excha...
MMS interfaces (3/3) <ul><li>The  MM7 interface  fits between the MMSC and external Value Added Service (VAS) applications...
MMS centre <ul><li>MMSC is responsible for handling transactions from MMS phones and transactions from other messaging sys...
MMSC performance <ul><li>The typical measure of performance for an MMSC is the  message per second , abbreviated MPS. </li...
MMS client <ul><li>MMS-enabled mobile devices and which offers the following features:  </li></ul><ul><ul><li>Management o...
Transcoder <ul><li>The MMSC can request an external  Transcoder  to convert media objects to other content types (content ...
User repository <ul><li>The user directory can be a database  internal  or  external  to the MMSC. </li></ul><ul><li>Exter...
WAP 1.x realisation of MMS
Content adaptation
Content adaptation &quot;Yes&quot; or &quot;No&quot; Request that MMSC performs no content adaptation. MmsSuppressionConte...
Content adaptation: UAProf (1/3) http://www.lebodic.net/mms_resource.htm <ul><li>List of phone capabilities (as advertised...
Content adaptation:  UAProf (2/3)
Content adaptation: UAProf (3/3) http://www.sonyericsson.com/UAProf/T610R301.xml
Streaming
Streaming protocols: RTP <ul><li>The  Real-Time Transport Protocol  (RTP) is a generic transport protocol allowing the tra...
Streaming protocols: RTSP <ul><li>With the  Real-Time Streaming Protocol  (RTSP),  the MMS client can control the way the ...
Charging <ul><li>Charging Data Records (CDRs) are generated by the MMSC on occurrence of predefined events. </li></ul>MM7R...
Transactions Flows <ul><li>Nominal use cases </li></ul><ul><li>MM1 interface (MMS client to MMSC) </li></ul><ul><li>MM4 in...
Person to person (1/2) <ul><li>Exchange of a message in the same MMS environment. </li></ul>
Person to person (2/2) <ul><li>Exchange of a message between two distinct MMS environments. </li></ul>
Content to person (2/2) <ul><li>Exchange of a message between a value-added service provider and a mobile user, and vice-v...
MM1 interface <ul><li>MM1 interface allows interactions between  the MMS client and the  MMSC: </li></ul><ul><li>Three typ...
MM1: protocol data units MMbox message deletion confirmation M-Mbox-Delete.conf 1.2 MMbox message deletion request M-Mbox-...
MM1: message submission <ul><li>In WAP technical realizations of MMS, the mobile device establishes a data connection with...
MM1: submission request (1/2) O 1.0 Request for a delivery report. This parameter indicates whether or not delivery report...
MM1: submission request (2/2)  1.0 Content type of the multimedia message. (e.g.  application/vnd.wap.multipart.related )...
MM1: submission response  1.2 MMBox message textual status - Textual description qualifying the value assigned to the  X-...
MM1: WAP encapsulation <ul><li>Request and response PDUs are transferred from the MMS client to the MMSC as part of a WSP/...
MM1: Binary encoding <ul><li>MMS standards published by OMA define an encoding of MMS PDUs. For instance a submission PDU ...
MM1: message notification (1/3) <ul><li>Notification that a message is awaiting retrieval. </li></ul><ul><li>Two transacti...
MM1: message notification (2/3) <ul><li>Upon receipt of the notification, the MMS client can perform the following actions...
MM1: message notification (3/3) <ul><li>The notification is typically encoded as part of one or two SMS messages (WAP push...
MM1: message retrieval (1/2) <ul><li>Retrieval of the multimedia message from the MMSC. </li></ul><ul><li>Prerequisite : n...
MM1: message retrieval (2/2) <ul><li>As for the notification, two transaction flows: </li></ul><ul><ul><li>Immediate retri...
MM1: delivery report (1/2) <ul><li>During message submission, the originator MMS client has the possibility of requesting ...
MM1: delivery report (2/2) <ul><li>As the notification, the delivery report is provided as part of a WAP push (typically c...
MM1: read report (1/2) <ul><li>During message submission, the originator MMS client has the possibility of requesting the ...
MM1: read report (2/2) <ul><li>The MMS client can generate the read report according to two different methods:  </li></ul>...
MM1: message forward (1/2) <ul><li>Once a notification has been received by the recipient MMS client, the user has the pos...
MM1: message forward (2/2) <ul><li>The MMSC can assign the previous address assigned to the  From  parameter to a new inst...
MM1: multimedia message boxes <ul><li>Several additional MM1 protocol data units:  </li></ul><ul><li>Store message in MMBo...
MM4 interface <ul><li>MM4 interface allows interactions between  two MMSCs. </li></ul><ul><li>Interactions between two MMS...
MM4: protocol data units <ul><li>MM4 interface has 6 PDUs </li></ul><ul><li>SMTP  is a basic protocol for exchanging messa...
Message routing over MM4 (1/2) <ul><li>The originator MMSC has to determine the IP address of the recipient MMSC in order ...
Message routing over MM4 (2/2) <ul><li>Physical connection  enabling MM4 interworking typically relies on: </li></ul><ul><...
MM4: Transaction flows <ul><li>Six PDUs for three MM4 transactions:  </li></ul><ul><li>Forward of message Response is opti...
MM4: example
MM7 interface <ul><li>MM7 interface allows interactions between  the MMSC and appli- cations of value-added service provid...
MM7: protocol data units <ul><li>MM7 interface has 14 PDUs for 8 transactions: </li></ul>Rel-5 Error indication from the V...
MM7: SOAP over HTTP <ul><li>MM7 interface is published by 3GPP TS 23.140 (from Release 5).  </li></ul><ul><li>MM7 is based...
MM7: Introduction to SOAP <ul><li>SOAP is a lightweight protocol for the exchange of information in distributed environmen...
MM7: Introduction to SOAP <ul><li>A SOAP message, represented using XML, consists of a SOAP envelope, a SOAP header, a SOA...
MM7: Introduction to SOAP
MM7: graphical convention
MM7: submission Transaction flow Response Request
MM7:  submission,  example Request
MM7: submission, example Response
MM7: delivery Transaction flow Response Request
MM7: cancel Transaction flow Response Request
MM7: replace Transaction flow Response Request
MM7: delivery report Transaction flow Response Request
MM7: read report Transaction flow Response Request
MM7: generic error handling Transaction flows Response
MM7: Nokia implementation (1/2) <ul><li>External Application Interface  (EAIF) enables multimedia messaging services to be...
MM7: Nokia implementation (2/2) <ul><li>In EAIF, HTTP POST requests are used to carry the MMS PDU, containing the MMS cont...
Upcoming SlideShare
Loading in …5
×

Mobile Messaging - Part 5 - Mms Arch And Transactions

12,305 views

Published on

This is a presentation I prepared for a lecture on mobile messaging. It covers MMS (Multimedia Messaging Service) - Architecture and Transactions.

Mobile Messaging - Part 5 - Mms Arch And Transactions

  1. 1. MMS Architecture and Transaction Flows Mobile Messaging G. Le Bodic PART 5
  2. 2. Course Contents Part 8 Instant Messaging and IMS Messaging Part 7 Mobile Email Day 2 Day 1 Part 6 MMS: Design of multimedia content and application development Part 5 MMS: Architecture and Transaction Flows Part 4 Short Message Service Part 3 Messaging Services in Europe and elsewhere Part 2 Standardization Part 1 Introduction to mobile communications networks
  3. 3. MMS Architecture and Transactions Flows <ul><li>Architecture of MMS </li></ul><ul><ul><li>Interfaces </li></ul></ul><ul><ul><li>MMS centre </li></ul></ul><ul><ul><li>MMS client </li></ul></ul><ul><ul><li>Transcoder </li></ul></ul><ul><ul><li>User directory </li></ul></ul><ul><li>WAP 1.x realisation of MMS </li></ul><ul><li>MMS interfaces </li></ul><ul><li>Content adaptation </li></ul><ul><li>Phone capabilities </li></ul><ul><li>Charging </li></ul><ul><li>Streaming (RTP and RTSP) </li></ul>Part. 5 <ul><li>Transaction Flows: </li></ul><ul><ul><li>Nominal use cases </li></ul></ul><ul><ul><li>MM1 interface (MMS client to MMSC) </li></ul></ul><ul><ul><li>MM4 interface (MMSC to MMSC) </li></ul></ul><ul><ul><li>MM7 interface (MMSC to VAS application) </li></ul></ul>
  4. 4. MMS architecture
  5. 5. MMS interfaces (1/3) <ul><li>The MM1 interface is a key interface in the MMS environment. It allows interactions between the MMS client, hosted in the mobile device, and the MMSC. </li></ul><ul><li>The MM2 interface is the interface between the two internal elements composing the MMSC: the MMS server and the MMS relay. Most commercial solutions offer a combined relay and server in the form of an MMSC. </li></ul><ul><li>The MM3 interface is the interface between an MMSC and external servers. Transactions invoked over this interface allow the exchange of messages between MMSCs and external servers such as email servers and SMS Centres (SMSCs). </li></ul>
  6. 6. MMS interfaces (2/3) <ul><li>The MM4 interface is the interface between two MMSCs. This interface is necessary for exchanging multimedia messages between distinct MMS environments (e.g. between two distinct mobile networks). </li></ul><ul><li>The MM5 interface enables interactions between the MMSC and other network elements. For instance, an MMSC can request routing information from the Home Location Register (HLR) or from a Domain Name Server (DNS). </li></ul><ul><li>The MM6 interface allows interactions between the MMSC and user databases (e.g. presence server). The </li></ul>
  7. 7. MMS interfaces (3/3) <ul><li>The MM7 interface fits between the MMSC and external Value Added Service (VAS) applications. This interface allows a VAS application to request services from the MMSC (message submission, etc.) and to obtain messages from remote MMS clients. </li></ul><ul><li>The MM8 interface enables interactions between the MMSC and a billing system. 3GPP has standardized Charging Data Records (CDR) that are generated by the MMSC on the occurrence of certain events (e.g. message submission, message retrieval, etc.). </li></ul>
  8. 8. MMS centre <ul><li>MMSC is responsible for handling transactions from MMS phones and transactions from other messaging systems (e.g. other MMS systems, email systems, etc.). </li></ul><ul><li>MMSC is also in charge of temporarily storing messages that are awaiting retrieval from recipient MMS clients . </li></ul><ul><li>MMSC may also support a persistent message store where users can store messages persistently in their MMBoxes. </li></ul><ul><li>MMSC may rely on the WAP content negotiation mechanism to adapt multimedia messages to the capabilities of receiving devices. </li></ul>
  9. 9. MMSC performance <ul><li>The typical measure of performance for an MMSC is the message per second , abbreviated MPS. </li></ul><ul><li>The definition of MPS must include the definition of a traffic model: </li></ul><ul><ul><li>Percentage of mobile originated traffic to MM1, MM3, MM4, etc. </li></ul></ul><ul><ul><li>Percentage of traffic requiring transcoding </li></ul></ul><ul><ul><li>Size and message contents </li></ul></ul><ul><ul><li>Percentage of prepaid/postpaid customers, etc. </li></ul></ul><ul><li>For large networks, the MMSC can face peak loads of several hundreds of MPS (Christmas, goal alert, etc.). </li></ul>
  10. 10. MMS client <ul><li>MMS-enabled mobile devices and which offers the following features: </li></ul><ul><ul><li>Management of message, notification and reports </li></ul></ul><ul><ul><li>Message composition </li></ul></ul><ul><ul><li>Message rendering </li></ul></ul><ul><ul><li>Configuration of MMS preferences and connectivity parameters </li></ul></ul><ul><ul><li>Handling of a remote message box </li></ul></ul>
  11. 11. Transcoder <ul><li>The MMSC can request an external Transcoder to convert media objects to other content types (content adaptation to recipient capabilities). </li></ul><ul><li>The Standard Transcoding Interface (STI) bridging the MMSC and the Transcoder is based on: </li></ul><ul><ul><li>Messages (business logic in the Transcoder) </li></ul></ul><ul><ul><li>Media objects (business logic in the MMSC) </li></ul></ul><ul><li>Two classes of degradation due to transcoding activities: </li></ul><ul><ul><li>Minor degradation </li></ul></ul><ul><ul><li>Major degradation </li></ul></ul>
  12. 12. User repository <ul><li>The user directory can be a database internal or external to the MMSC. </li></ul><ul><li>External repositories are typically implemented as LDAP directories . </li></ul><ul><li>For large networks, the user repository can hold information for several millions MMS subscribers. </li></ul>
  13. 13. WAP 1.x realisation of MMS
  14. 14. Content adaptation
  15. 15. Content adaptation &quot;Yes&quot; or &quot;No&quot; Request that MMSC performs no content adaptation. MmsSuppressionContentAdaptation &quot;TX&quot;, &quot;IB&quot;, &quot;IR&quot;. <ul><li>List of message content classes supported by the MMS client: </li></ul><ul><li>TX for the text class </li></ul><ul><li>IB for the image basic class </li></ul><ul><li>IR for the image rich class </li></ul><ul><li>VB for the video basic class </li></ul><ul><li>VR for the video rich class </li></ul>MmsContentClass &quot;SMIL-CONF-1-2&quot;, &quot;SMIL-3GPP-R4&quot;. <ul><li>List of supported SMIL profiles supported by the MMS client: </li></ul><ul><li>SMIL-CONF-1-2 for the SMIL profile defined in [OMA-MMS-Conf] version 1.2 </li></ul><ul><li>SMIL-3GPP-R4 for the SMIL profile defined in [3GPP-26.234] Release 4 </li></ul><ul><li>SMIL-3GPP-R5 for the SMIL profile defined in [3GPP-26.234] Release 4 </li></ul>MmsSmilBaseSet &quot;Yes&quot; or &quot;No&quot; Whether or not the MMS client supports streaming MmsCCPPStreamingCapable &quot;1.0&quot;, &quot;1.1&quot; List of supported MMS version. MmsVersion &quot;base64&quot;, &quot;quoted-printable&quot;. List of supported transfer encoding methods. MmsCCPPAcceptEncoding &quot;en&quot;, &quot;fr&quot; for, respectively, English and French. List of supported languages. MmsCCPPAcceptLanguage &quot;US-ASCII&quot; or &quot;ISO-8859-1&quot; List of supported character sets. MmsCCPPAcceptCharSet &quot;image/jpeg&quot;, &quot;audio/amr&quot; List of supported content types. MmsCCPPAccept 640x480 Maximum image dimensions expressed in pixels. MmsMaxImageResolution 30720 Maximum message size expressed in bytes. MmsMaxMessageSize Examples Description Attribute name
  16. 16. Content adaptation: UAProf (1/3) http://www.lebodic.net/mms_resource.htm <ul><li>List of phone capabilities (as advertised in user agent profiles) available from lecturer’s website (121 phones). </li></ul>
  17. 17. Content adaptation: UAProf (2/3)
  18. 18. Content adaptation: UAProf (3/3) http://www.sonyericsson.com/UAProf/T610R301.xml
  19. 19. Streaming
  20. 20. Streaming protocols: RTP <ul><li>The Real-Time Transport Protocol (RTP) is a generic transport protocol allowing the transfer of real-time data from a server. </li></ul><ul><li>This communication enables the delivery of streamable content, stored in the media server, to the MMS client in streaming mode. </li></ul><ul><li>RTP usually relies on the connection-less User Datagram Protocol (UDP) (itself relying on the IP protocol). </li></ul><ul><li>RTP is defined by the IETF in RFC-1889. </li></ul><ul><li>RTP offers the following functions </li></ul><ul><ul><li>Sequence numbering </li></ul></ul><ul><ul><li>Time-stamping </li></ul></ul><ul><ul><li>Payload-type identifier </li></ul></ul>
  21. 21. Streaming protocols: RTSP <ul><li>With the Real-Time Streaming Protocol (RTSP), the MMS client can control the way the streamable content is delivered from the media server. </li></ul><ul><li>The MMS client instructs the media server to start, pause and play the message content during the content delivery and rendering. </li></ul><ul><li>In other words, with RTSP, the MMS client can control the content delivery from the media server in the same way as a person controls a VCR with a remote controller. </li></ul><ul><li>This is why RTSP is sometimes known as a ‘network remote control’ for multimedia servers. </li></ul><ul><li>RTSP is defined by the IETF in RFC-2326. </li></ul>
  22. 22. Charging <ul><li>Charging Data Records (CDRs) are generated by the MMSC on occurrence of predefined events. </li></ul>MM7RRs-CDR VAS MM7 Read report response MM7RRq-CDR VAS MM7 Read report request MM7DRRs-CDR VAS MM7 Delivery report response MM7DRRq-CDR VAS MM7 Delivery report request MM7R-CDR VAS MM7 Message replace MM7C-CDR VAS MM7 Message cancel MM7DRs-CDR VAS MM7 Delivery response MM7DRq-CDR VAS MM7 Delivery request MM7S-CDR VAS MM7 Message submission Bx1D-CDR MMBox MM1 Message deletion Bx1U-CDR MMBox MM1 Message upload Bx1V-CDR MMBox MM1 Message view Bx1S-CDR MMBox MM1 Message store F-CDR Forwarding n/a Forwarding RMD-CDR Recipient n/a Recipient message deletion R4RRs-CDR Recipient MM4 Read-reply report response R4RRq-CDR Recipient MM4 Read-reply report request R1RR-CDR Recipient MM1 Read-reply recipient R4DRs-CDR Recipient MM4 Delivery report response R4DRq-CDR Recipient MM4 Delivery report request R1A-CDR Recipient MM1 Acknowledgement R1Rt-CDR Recipient MM1 Message retrieval R1NRs-CDR Recipient MM1 Notification response R1NRq-CDR Recipient MM1 Notification request R4F-CDR Recipient MM4 Message forward OMD-CDR Originator n/a Originator message deletion O1R-CDR Originator MM1 Read-reply originator O4R-CDR Originator MM4 Read-reply report O1D-CDR Originator MM1 Delivery report O4D-CDR Originator MM4 Delivery report OFRs-CDR Originator MM4 Forward response O4FRq-CDR Originator MM4 Forward request O1S-CDR Originator MM1 Message submission CDR name Category Interface Event
  23. 23. Transactions Flows <ul><li>Nominal use cases </li></ul><ul><li>MM1 interface (MMS client to MMSC) </li></ul><ul><li>MM4 interface (MMSC to MMSC) </li></ul><ul><li>MM7 interface (MMSC to VAS application) </li></ul><ul><ul><li>Standard implementation of MM7 </li></ul></ul><ul><ul><li>Alternative proprietary implementations </li></ul></ul>
  24. 24. Person to person (1/2) <ul><li>Exchange of a message in the same MMS environment. </li></ul>
  25. 25. Person to person (2/2) <ul><li>Exchange of a message between two distinct MMS environments. </li></ul>
  26. 26. Content to person (2/2) <ul><li>Exchange of a message between a value-added service provider and a mobile user, and vice-versa. </li></ul>
  27. 27. MM1 interface <ul><li>MM1 interface allows interactions between the MMS client and the MMSC: </li></ul><ul><li>Three types of PDUs can be invoked over the MM1 interface: </li></ul><ul><ul><li>Request : N ame of a request PDU is suffixed with .req (e.g. M-send.req). </li></ul></ul><ul><ul><li>Confirmation/response : Name of a confirmation PDU is suffixed with .conf (e.g. M-send.conf). </li></ul></ul><ul><ul><li>Indication : Name of an indication PDU is suffixed with .ind (e.g. M-notification.ind). An indication is not confirmed. </li></ul></ul>
  28. 28. MM1: protocol data units MMbox message deletion confirmation M-Mbox-Delete.conf 1.2 MMbox message deletion request M-Mbox-Delete.req Message deletion from MMbox MMbox message upload confirmation M-Mbox-Upload.conf 1.2 MMbox message upload request M-Mbox-Upload.req Message upload to MMbox MMbox contents view confirmation M-Mbox-View.conf 1.2 MMbox contents view request M-Mbox-View.req View contents of MMbox MMbox message store/update confirmation M-Mbox-Store.conf 1.2 MMbox message store/update request M-Mbox-Store.req Message store or update into MMbox Message forward confirmation M-forward.conf 1.1 Message forward request M-forward.req Message forward Read report indication (originator MMSE) M-read-orig.ind 1.1 Read report indication (recipient MMSE) M-read-rec.ind Read report 1.0 Delivery report indication M-delivery.ind Delivery report 1.0 Message retrieval acknowledgement indication M-acknowledge.ind Message retrieval confirmation M-retrieve.conf 1.0 Message retrieval request WSP/HTTP GET.req Message retrieval Message notification response indication M-notifyresp.ind 1.0 Message notification indication M-notification.ind Notification Message submission confirmation M-send.conf 1.0 Message submission request M-send.req Message submission From OMA Description PDU name Transaction
  29. 29. MM1: message submission <ul><li>In WAP technical realizations of MMS, the mobile device establishes a data connection with the network. This allows the MMS client to communicate with the MMSC. </li></ul><ul><li>This data connection can rely on a circuit-switched data connection (e.g. GSM) or a packet switched connection (e.g. GPRS). </li></ul><ul><li>The connection is typically established through a WAP gateway in a WAP 1.x configuration </li></ul>
  30. 30. MM1: submission request (1/2) O 1.0 Request for a delivery report. This parameter indicates whether or not delivery report(s) are to be generated for the submitted message. Two values can be assigned to this parameter: 'yes' (delivery report is to be generated) or 'no' (no delivery report requested). If the message class is 'auto', then this parameter is present in the submission PDU and is set to 'no'. X-Mms-Delivery-Report O 1.0 Visibility of the sender address. This parameter is either set to 'show' (default) for showing the sender address to recipient(s) or 'hide' for hiding the sender address to recipient(s). From MMS 1.2, 'show' is not anymore the default value for this parameter. If this parameter is not present in an MMS 1.2 PDU, then network preferences for the sender anonymity feature are used. X-Mms-Sender-Visibility O 1.0 Priority such as 'low', 'normal' (default) or 'high'. X-Mms-Priority O 1.0 Earliest delivery time. Default value for this parameter is 'immediate delivery'. X-Mms-Delivery-Time O 1.0 Expiry date. Default value for this parameter is 'maximum'. X-Mms-Expiry O 1.0 Message class such as 'auto' (automatically generated by the MMS client), 'personal' (default), 'advertisement' and 'informational'. Other classes can also be defined in the form of text strings. X-Mms-Message-Class O 1.0 A short textual description for the message. Subject O 1.0 One or multiple addresses (phone number or email address) for message recipient(s). Secondary recipients / blind copy. Bcc O 1.0 One or multiple addresses (phone number or email address) for message recipient(s). Secondary recipients. Cc O 1.0 One or multiple addresses (phone number or email address) for message recipient(s). Primary recipients. To  1.0 Address of the originator MMS client (phone number or email address) or 'insert token' if the originator address is to be provided by the MMSC. From O 1.0 Date and time of message submission. Date  1.0 MMS protocol version such as 1.0, 1.1 or 1.2. X-Mms-MMS-Version  1.0 Unique identifier for the submission transaction. X-Mms-Transaction-ID  1.0 MMS protocol data unit type. Value: M-send-req X-Mms-Message-Type St. From OMA Description Parameter name
  31. 31. MM1: submission request (2/2)  1.0 Content type of the multimedia message. (e.g. application/vnd.wap.multipart.related ). Content-Type  1.2 MMBox message flag – This parameter indicates the list of flags associated to a message stored in the MMBox (considered only if X-Mms-Store is set to 'yes'). X-Mms-MM-Flags  1.2 MMBox message state – When X-Mms-Store is set to 'yes', this parameter indicates the message state in the originator's MMBox (e.g. sent, draft, etc.). If X-Mms-Store is set to 'yes' and if this parameter is not present then the message default state is 'sent'. X-Mms-MM-State  1.2 MMBox storage request - This parameter indicates whether the originator MMS client requests to save the message in the originator's MMBox in addition from sending it. X-Mms-Store  1.1 Reply charging – identification. This parameter is inserted in a reply message only and refers to the original message identifier ( Message-ID parameter). X-Mms-Reply-Charging-ID  1.1 Reply charging – maximum message size. This parameter specifies the maximum size for message replies. This parameter is only present in the PDU if reply charging is requested. X-Mms-Reply-Charging-Size  1.1 Reply charging – deadline. This parameter specifies the latest time for the recipient(s) to submit a message reply. This parameter is only present in the PDU if reply charging is requested. X-Mms-Reply-Charging-Deadline  1.1 Request for reply charging. The presence of this parameter indicates that reply charging is requested by the message originator. Two values can be assigned to this parameter: 'requested' when the originator is willing to pay for the message reply(s) or 'requested text only' when the originator is willing to pay for message reply(s) containing text only. In any case, two parameters (reply message size and reply deadline) specify conditions for the message reply to be paid for by the originator. X-Mms-Reply-Charging  1.0 Request for a read report. This parameter indicates whether or not read reports are to be generated for the message. Two values can be assigned to this parameter: 'yes' (read report is to be generated) or 'no' (no read report requested). If the message class is auto, then this parameter is present in the submission PDU and is set to 'no'. X-Mms-Read-Report
  32. 32. MM1: submission response  1.2 MMBox message textual status - Textual description qualifying the value assigned to the X-Mms-Store-Status parameter. X-Mms-Store-Status-Text  1.2 MMBox message status - This parameter is present only if the two following conditions are fulfilled: - the originator MMSC supports the MMBox feature - the X-Mms-Store parameter was present in the corresponding submission request When available, this parameter indicates whether or not the submitted message has been successfully stored in the MMBox. See status codes in Appendix D. X-Mms-Store-Status  1.2 Reference to the message stored in the MMBox - This parameter is present only if the three following conditions are fulfilled: - the originator MMSC supports the MMBox feature - the X-Mms-Store parameter was present in the corresponding submission request - the X-Mms-Store-Status indicates 'success' When available, this parameter provides a reference to the message stored in the MMBox (reference used later for message retrieval or view request). X-Mms-Content-Location  1.0 Message unique identifier. This identifier is always provided by the MMSC if the submission request is accepted. Message-ID  1.0 Human readable description of the transaction status. X-Mms-Response-Text  1.0 Status code for the submission transaction. The submission request can be accepted or rejected (permanent or transient errors). See status codes in Appendix B. X-Mms-Response-Status  1.0 MMS protocol version such as 1.0, 1.1 or 1.2. X-Mms-MMS-Version  1.0 Unique identifier for the submission transaction. The same as the one for the corresponding submission request. X-Mms-Transaction-ID  1.0 MMS protocol data unit type. Value: M-send-conf X-Mms-Message-Type St. From OMA Description Parameter name
  33. 33. MM1: WAP encapsulation <ul><li>Request and response PDUs are transferred from the MMS client to the MMSC as part of a WSP/HTTP Post request: </li></ul><ul><li>At the WSP/HTTP layer, an MMS PDU is marked with the following content type: </li></ul><ul><ul><li>application/vnd.wap.mms-message </li></ul></ul>
  34. 34. MM1: Binary encoding <ul><li>MMS standards published by OMA define an encoding of MMS PDUs. For instance a submission PDU (message sending) is encoded as follows: </li></ul>X-Mms-Message-Type: M-send.req X-Mms-Transaction-ID: 0123456789 X-Mms-MMS-Version: 1.0 From: +33144556677/TYPE = PLMN To: +33111223344/TYPE = PLMN Subject: A stay in Velen. Content-type: application/vnd.wap.multipart.related start = <0000> type = “application/smil”
  35. 35. MM1: message notification (1/3) <ul><li>Notification that a message is awaiting retrieval. </li></ul><ul><li>Two transaction flows: </li></ul><ul><ul><li>Immediate retrieval </li></ul></ul><ul><ul><li>Deferred retrieval </li></ul></ul>
  36. 36. MM1: message notification (2/3) <ul><li>Upon receipt of the notification, the MMS client can perform the following actions: </li></ul><ul><ul><li>Message rejection : The message is rejected without being retrieved by the recipient MMS client. </li></ul></ul><ul><ul><li>Immediate message retrieval : The message is immediately retrieved without user explicit request. </li></ul></ul><ul><ul><li>Indication message awaiting retrieval : The MMS client notifies the user that a message awaits retrieval. In this mode, the user can retrieve the message later at his/her own convenience (deferred message retrieval). With the notification, the user also has the possibility of forwarding the message to other recipients without having to retrieve the message first (from MMS 1.1 only). The user can also instruct the MMS client to delete the notification. </li></ul></ul><ul><li>An important parameter of the notification indication PDU is the X-Mms-Content-Location parameter. It indicates the location from which the message can be retrieved. For instance: </li></ul><ul><li>http://mmsc.vodafone.com/message-id-634 </li></ul>
  37. 37. MM1: message notification (3/3) <ul><li>The notification is typically encoded as part of one or two SMS messages (WAP push). </li></ul><ul><li>Alternatively, the WAP push can directly been delivered via an already opened GPRS session. </li></ul>X-Mms-Message-Type: M-notification.ind X-Mms-Transaction-ID: Transaction-123456789-abcdefg X-Mms-MMS-Version: 1.0 From: +336666666666/TYPE=PLMN X-Mms-Message-Class: Personal X-Mms-Message-Size: 120 X-Mms-Expiry: 172800 X-Mms-Content-Location: http://mms.vodafone.com:8002/message-123456 TP-Protocol-Identifier: 0x00 TP-Data-Coding-Scheme: 8-bit data. TP-User-Data: as shown below
  38. 38. MM1: message retrieval (1/2) <ul><li>Retrieval of the multimedia message from the MMSC. </li></ul><ul><li>Prerequisite : notification has been sent out. </li></ul><ul><li>Alternatively, the WAP push can directly been delivered via an already opened GPRS session. </li></ul>
  39. 39. MM1: message retrieval (2/2) <ul><li>As for the notification, two transaction flows: </li></ul><ul><ul><li>Immediate retrieval </li></ul></ul><ul><ul><li>Deferred retrieval </li></ul></ul>
  40. 40. MM1: delivery report (1/2) <ul><li>During message submission, the originator MMS client has the possibility of requesting the generation of delivery report(s) for the submitted message. </li></ul><ul><li>If such a request has been made, a delivery report is generated for each one of the message recipients on the occurrence of the following events: </li></ul><ul><ul><li>Message has been successfully retrieved by the recipient MMS client. </li></ul></ul><ul><ul><li>Message has been deleted (e.g. validity period has expired). </li></ul></ul><ul><ul><li>Message has been rejected by the recipient MMS client. </li></ul></ul><ul><ul><li>Message has been forwarded by the recipient MMS client. </li></ul></ul><ul><ul><li>Message status is indeterminate (e.g. message has been transferred to a messaging system where the concept of delivery report is not fully supported). </li></ul></ul>
  41. 41. MM1: delivery report (2/2) <ul><li>As the notification, the delivery report is provided as part of a WAP push (typically conveyed as an SMS). </li></ul> 1.0 Status of corresponding message such as 'expired', 'retrieved', 'rejected', 'forwarded', or 'indeterminate'. X-Mms-Status  1.0 Date and time the message was retrieved, has expired, etc. Date  1.0 Address of the message recipient. To  1.0 Identifier of the message to which the report relates. This identifier is used for correlating the delivery report with the original message. Message-ID  1.0 MMS protocol version such as 1.0, 1.1 or 1.2. X-Mms-MMS-Version  1.0 MMS protocol data unit type. Value: M-delivery-ind X-Mms-Message-Type St. From OMA Description Parameter name
  42. 42. MM1: read report (1/2) <ul><li>During message submission, the originator MMS client has the possibility of requesting the generation of read report(s) for the submitted message. </li></ul><ul><li>If such a request has been made, a read report may be generated for each one of the message recipients on the occurrence of the following events: </li></ul><ul><ul><li>Message has been read. </li></ul></ul><ul><ul><li>Message has been deleted without being read. </li></ul></ul>
  43. 43. MM1: read report (2/2) <ul><li>The MMS client can generate the read report according to two different methods: </li></ul><ul><li>The first method , introduced in MMS 1.0, lets the MMS client submit a normal message addressed to the message originator with the M-send.req PDU over the MM1 interface. </li></ul><ul><li>The second method , applicable from MMS 1.1, consists in using a set of two MM1 PDUs dedicated to read reports. </li></ul>
  44. 44. MM1: message forward (1/2) <ul><li>Once a notification has been received by the recipient MMS client, the user has the possibility to retrieve or reject the corresponding message. </li></ul><ul><li>In addition, from MMS 1.1, the recipient MMS client may also support the forward of a message that has not yet been retrieved from the MMSC. </li></ul>
  45. 45. MM1: message forward (2/2) <ul><li>The MMSC can assign the previous address assigned to the From parameter to a new instance of the X-Mms-Previously-Sent-By parameter and associates a sequence number to this parameter. </li></ul><ul><li>Example: </li></ul><ul><li>A date of forward is also associated to each message forwarder. </li></ul><ul><li>This information can be presented to the subsequent recipients of the message. </li></ul>X-Mms-Previously-Sent-By: 0, Gwenael <gwenael@lebodic.net> X-Mms-Previously-Sent-By: 1, +33612345678/TYPE=PLMN X-Mms-Previously-Sent-By: 2, +33698765432/TYPE=PLMN
  46. 46. MM1: multimedia message boxes <ul><li>Several additional MM1 protocol data units: </li></ul><ul><li>Store message in MMBox : MMS client instructs the MMSC to store a message, which has yet to be retrieved, in the MMBox. </li></ul><ul><li>Update message in MMBox : The MMS client instructs the MMSC to update the state and/or flags of a message in the MMBox. </li></ul><ul><li>MMS client request information about one or more multimedia messages that are stored in the user’s MMBox </li></ul><ul><li>MMS client has the possibility to delete one or more messages from the MMBox with a single transaction </li></ul><ul><li>MMS client has the possibility to upload a message in the MMBox </li></ul>
  47. 47. MM4 interface <ul><li>MM4 interface allows interactions between two MMSCs. </li></ul><ul><li>Interactions between two MMSCs are required for Interconnect but not for Roaming . </li></ul><ul><li>Transactions specified for the MM4 interface are conveyed over the Simple Mail Transfer Protocol (SMTP): </li></ul>
  48. 48. MM4: protocol data units <ul><li>MM4 interface has 6 PDUs </li></ul><ul><li>SMTP is a basic protocol for exchanging messages between Mail User Agents (MUAs). </li></ul><ul><li>In the Internet domain, SMTP has become the de facto email transfer protocol for exchanging messages. </li></ul><ul><li>Specifications of SMTP have been published by the Internet Engineering Task Force (IETF) in [RFC-2821] ([RFC-2821] obsoletes [RFC-821]). </li></ul>Confirmation for read report forward MM4_read_reply_report.RES Rel-4 Request for read report forward MM4_read_reply_report.REQ Routing forward a read report Confirmation for delivery report forward MM4_delivery_report.RES Rel-4 Request for delivery report forward MM4_delivery_report.REQ Routing forward a delivery report Message forward confirmation MM4_forward.RES Rel-4 Message forward request MM4_forward.REQ Routing forward a message. From 3GPP Description PDU name Transaction
  49. 49. Message routing over MM4 (1/2) <ul><li>The originator MMSC has to determine the IP address of the recipient MMSC in order to route the message with SMTP. </li></ul><ul><li>IMSI-based method: compliant with the Mobile Number Portability (MNP) requirements. Steps: </li></ul><ul><ul><li>MMSC interrogates the recipient HLR in order to get the IMSI of recipient phone number (via MM5 interface). </li></ul></ul><ul><ul><li>With the IMSI, the originator MMSC extracts the Mobile Network Code (MNC) and the Mobile Country Code (MCC). </li></ul></ul><ul><ul><li>With the MNC and MCC, the originator MMSC obtains the recipient MMSC FQDN by interrogating a local database (look-up table or constructing it via GSMA naming convention). </li></ul></ul><ul><ul><li>With the MMSC FQDN, the originator MMSC retrieves the MMSC IP address by interrogating the DNS. </li></ul></ul><ul><li>Unbundling is performed by the MMSC. </li></ul>
  50. 50. Message routing over MM4 (2/2) <ul><li>Physical connection enabling MM4 interworking typically relies on: </li></ul><ul><ul><li>National leased lines (for national interworking) </li></ul></ul><ul><ul><li>IP-VPN over the Internet </li></ul></ul><ul><ul><li>GPRS Roaming Exchange (GRX) services </li></ul></ul><ul><li>Application-level (MM4) topology relies on: </li></ul><ul><ul><li>Peering: proven for national interworking but does not scale well for international interworking. </li></ul></ul><ul><ul><li>Hub concept: not proven yet but is expected to facilitate MMS international interworking . </li></ul></ul>
  51. 51. MM4: Transaction flows <ul><li>Six PDUs for three MM4 transactions: </li></ul><ul><li>Forward of message Response is optional </li></ul><ul><li>Delivery report The different delivery states that can be reported over the MM4 interface are as follows: </li></ul><ul><ul><li>Expired </li></ul></ul><ul><ul><li>Retrieved </li></ul></ul><ul><ul><li>Deferred </li></ul></ul><ul><li>Read report The different read states that can be reported over the MM4 interface are as follows: </li></ul><ul><ul><li>Read </li></ul></ul><ul><ul><li>Deleted without being read. </li></ul></ul><ul><ul><li>- Indeterminate </li></ul></ul><ul><ul><li>- Forwarded </li></ul></ul><ul><ul><li>- Unrecognized. </li></ul></ul>
  52. 52. MM4: example
  53. 53. MM7 interface <ul><li>MM7 interface allows interactions between the MMSC and appli- cations of value-added service providers. </li></ul><ul><li>MM7 is realised with SOAP requests over the HTTP protocol: </li></ul>
  54. 54. MM7: protocol data units <ul><li>MM7 interface has 14 PDUs for 8 transactions: </li></ul>Rel-5 Error indication from the VAS application to the MMSC MM7_VASP_error.RES VASP error Rel-5 Error indication from the MMSC to the VAS application MM7_RS_error.RES MMSC error Read report response MM7_read_reply_report.RES Rel-5 Read report request MM7_read_reply_report.REQ Read report Delivery report response MM7_delivery_report.RES Rel-5 Delivery report request MM7_delivery_report.REQ Delivery report Message replacement response MM7_replace.RES Rel-5 Message replacement request MM7_replace.REQ Replacement Message cancellation response MM7_cancel.RES Rel-5 Message cancellation request MM7_cancel.REQ Cancellation Message delivery response MM7_deliver.RES Rel-5 Message delivery request MM7_deliver.REQ Message delivery Message submission response MM7_submit.RES Rel-5 Message submission request MM7_submit.REQ Message submission From 3GPP Description PDU name Transaction
  55. 55. MM7: SOAP over HTTP <ul><li>MM7 interface is published by 3GPP TS 23.140 (from Release 5). </li></ul><ul><li>MM7 is based on the Simple Object Access Protocol (SOAP) with HTTP at the transport layer. </li></ul><ul><li>Proprietary MM7 implementations rely on the transfer of proprietary commands over either SMTP or HTTP. </li></ul><ul><li>SOAP messages are structured according to SOAP technical specifications published by W3C. </li></ul><ul><li>Several versions of the schema for the MM7 interface are available and each one corresponds to a specific version of the 3GPP standard : </li></ul>http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/ v5.6.0 REL-5-MM7-1-3 v5.5.0 REL-5-MM7-1-2 v5.4.0 REL-5-MM7-1-1 v5.3.0 REL-5-MM7-1-0 Corresponding version of [3GPP-23.140] Schema name
  56. 56. MM7: Introduction to SOAP <ul><li>SOAP is a lightweight protocol for the exchange of information in distributed environments such as the MMSE. </li></ul><ul><li>All SOAP messages are represented using XML. </li></ul><ul><li>SOAP specifications consist of three distinct parts: </li></ul><ul><ul><li>Envelope </li></ul></ul><ul><ul><li>Set of encoding rules </li></ul></ul><ul><ul><li>Convention for representing remote procedure calls </li></ul></ul><ul><li>SOAP may be used over a variety of transport protocols. In the MMSE, for the realization of the MM7 interface, SOAP is used over the HTTP transport protocol. </li></ul>
  57. 57. MM7: Introduction to SOAP <ul><li>A SOAP message, represented using XML, consists of a SOAP envelope, a SOAP header, a SOAP body and an optional SOAP attachment. </li></ul><ul><li>For messages containing a SOAP envelope only, the media type text/xml is used. If the SOAP message also contains an attachment, then the media type multipart/related is used and the SOAP envelope is identified with the Start parameter of the Content-Type . </li></ul><ul><li>Each part of the SOAP message has, at least, the two parameters Content-Type and Content-ID . </li></ul>
  58. 58. MM7: Introduction to SOAP
  59. 59. MM7: graphical convention
  60. 60. MM7: submission Transaction flow Response Request
  61. 61. MM7: submission, example Request
  62. 62. MM7: submission, example Response
  63. 63. MM7: delivery Transaction flow Response Request
  64. 64. MM7: cancel Transaction flow Response Request
  65. 65. MM7: replace Transaction flow Response Request
  66. 66. MM7: delivery report Transaction flow Response Request
  67. 67. MM7: read report Transaction flow Response Request
  68. 68. MM7: generic error handling Transaction flows Response
  69. 69. MM7: Nokia implementation (1/2) <ul><li>External Application Interface (EAIF) enables multimedia messaging services to be developed to the Nokia MMSC. </li></ul><ul><li>EAIF is Nokia’s proprietary MM7 interface. </li></ul><ul><li>The application may send charging information to the MMSC as tariff classes. Based on the tariff classes, MMSC will create charging data records for the subscriber. </li></ul><ul><li>In EAIF HTTP 1.1 is used. The POST method is used to carry MMS messages and delivery reports to/from the MMSC. </li></ul>
  70. 70. MM7: Nokia implementation (2/2) <ul><li>In EAIF, HTTP POST requests are used to carry the MMS PDU, containing the MMS content, between the MMSC and applications. HTTP headers and MMS specific HTTP extension headers are used to carry some additional data, e.g. routing information. MMS PDUs are binary encoded accorting to the standards. </li></ul><ul><li>The operator may decide to utilize SSL in EAIF to secure the MMS traffic between the MMSC and applications. SSL can be used to both authentication and traffic encryption. The supported versions in EAIF from SSL are SSL 2 and SSL 3. Also TLS 1 can be used. </li></ul>

×