that ease the exploration of contents. As for sending and receiving MMS in a person-to-person context, using it will be of a degree of complexity similar to that of SMS. Note that the current success of SMS relies exactly on the ease of use and management of SMS. Moreover, usability refers to the easy use of the MMS technology by a customer without their knowing the complex technological processes that are behind this service. Hence, it is important to allow the personalization of the user interface to be as friendly as possible in order to permit the user to exploit completely the potentialities of MMS. 10.3 MMS Format When an MMS is sent, it is forwarded as a Protocol Data Unit, PDU, as described in the subsection below. The structure of a PDU is standardized by the WAP Forum (now OMA) in the WAP-209-MMS encapsulation specification [11]. 10.3.1 MMS PDU MMS uses several types of PDUs to perform transactions that are described in Section 10.4. Here, the contents of the PDUs are described. The PDU of an MMS consists of a header that contains specific information about message transactions, and a body. The message body may contain any content type such as text, image, audio and video. The message body is used only when an MMS is sent or retrieved. All other PDUs contain only the header. In the MMS body, every part needs a further header with the related content type (e.g., image, text, etc.) and content location (e.g., picture1.jpg, text1.txt) [12]; such segmentation is called Multipart Message (MM), as shown in Figure 10.7. Below are described some different fields that may be present in the MM header [13]:  X-Mms-Message Type, specifying the transaction type;  X-Mms-Transaction-ID, identifying univocally the message;  X-Mms-Version, specifying the MMS version used for this message;  To/From, about the sender and the recipient of the message;  Subject of the message;  Date of the message transaction;  Content-Type, defining the content of the MMS (i.e., image, sound or text). MM header Part1 header Part2 header Part1 body Part2 body text image MM body MM header Figure 10.7 MMS PDU format. 302 Multimedia Messaging Service (MMS) In what follows, the header fields are described for the eight main PDUs. The name of an optional field is enclosed in square brackets; all other fields are mandatory. Note that the use of the PDUs below is described in Section 10.4. M-Send.req The message body follows the headers. The transaction identifier is created and used by the sending client and it is unique for the transaction. X-Mms-Message-Type X-Mms-Transaction-ID X-Mms-MMS-Version [Date] From To, Cc, or Bcc [Subject] [X-Mms-Message-Class] [X-Mms-Expiry] [X-Mms-Delivery-Time] [X-Mms-Priority] [X-Mms-Sender-Visibility] [X-Mms-Delivery-Report] [X-Mms-Read-Reply] Content-Type M-Send.conf When the MMS relay has received the send request, it transmits back a response message to the mobile terminal indicating the status of the operation. The MMS relay must always assign an ID to the message when successfully received. X-Mms-Message-Type X-Mms-Transaction-ID X-Mms-MMS-Version X-Mms-Response-Status [X-Mms-Response-Text] [Message-ID] M-Notification.ind MMS notifications inform the mobile terminal about the contents of a received message. The purpose of the notification is to allow the client to fetch automatically a message from the location indicated in the notification. The transaction ID is created by the MMS relay and it is unique up to the following M-Notify-Resp only. If the MMS client requests a deferred delivery with M-NotifyResp, the MMS relay may create a new transaction ID. X-Mms-Message-Type X-Mms-Transaction-ID X-Mms-MMS-Version [From] [Subject] X-Mms-Message-Class MMS Format 303 X-Mms-Message-Size X-Mms-Expiry X-Mms-Content-Location M-NotifyResp.ind The purpose of this message is to acknowledge the transaction to the MMS relay. X-Mms-Message-Type X-Mms-Transaction-ID X-Mms-MMS-Version X-Mms-Status [X-Mms-Report-Allowed] M-Retrieve.conf A client shall retrieve messages by sending a WSP get request to the MMS relay containing a URI to the received message. If successful, the response to the retrieve request will contain headers and the body of the incoming message. X-Mms-Message-Type [X-Mms-Transaction-ID] X-Mms-MMS-Version [Message-ID] Date [From] [To] [Cc] [Subject] [X-Mms-Message-Class] [X-Mms-Priority] [X-Mms-Delivery-Report] [X-Mms-Read-Reply] Content-Type M-Acknowledge.ind An MMS acknowledge message confirms the delivery of the message from the receiving terminal to the MMS relay. X-Mms-Message-Type X-Mms-Transaction-ID X-Mms-MMS-Version [X-Mms-Report-Allowed] M-Delivery.ind An MMS delivery report must be sent from the MMS Relay to the originating mobile terminal when the originator has requested a delivery report and the recipient has not explicitly requested for denial of the report. There will be a separate delivery report from each recipient. There is no response message to the delivery report. X-Mms-Message-Type X-Mms-MMS-Version Message-ID To Date X-Mms-Status 304 Multimedia Messaging Service (MMS) Read Reporting When the originating terminal requested the read-reply in the MMS, the recipient terminal may send a new MMS back to the originating terminal when the user has read the MMS. The content of the multimedia message is a terminal implementation issue. The read-reply MMS must have the Message- Class as Auto in the message. The MMS relay must deliver the read-reply message as an ordinary multimedia message. When the originating terminal receives the read-reply, it shall not create a delivery report or a read-reply message. An example of a PDU header for MMS delivery (before binary encoding, according to the WAP specifications) is shown in Figure 10.8. 10.3.1.1 The SMIL Language The Synchronized Multimedia Integration Language (SMIL, pronounced ‘smile’) is an XML-based language used to ease the organization of media objects contained in an MMS. It is the mandatory format for media synchronization and scene description of multimedia messaging. The current SMIL release is 2.0, which has the following design goals:  To define an XML-based language that allows authors to write interactive multimedia presentations. Using SMIL 2.0, an author can describe the temporal behavior of a multimedia presentation, associate hyperlinks with media objects and describe the layout of the presentation on the display.  To allow reusing of SMIL 2.0 syntax and semantics in other XML-based languages, in particular those needing to represent timing and synchronization. For example, SMIL 2.0 components are used for integrating timing into XHTML. SMIL 2.0 is defined as a set of markup modules that characterize the semantics and an XML syntax for certain areas of SMIL functionality. The 3GPP MMS uses a subset of SMIL 2.0 as a format of the scene description [14]. MMS clients and servers shall support the 3GPP SMIL Language Profile. This profile is a subset of the SMIL 2.0 Language Profile, but a superset of the SMIL 2.0 Basic Language Profile. 3GPP TS 26.234 Recommendation has an informative Annex B that provides guidelines for SMIL content authors [15]. Additionally, 3GPP MMS should provide the following format: XHTML Mobile Profile. The 3GPP MMS uses a subset of XHTML 1.1 as a format for scene description. MMS clients and servers shall X-Mms-Message-Type : m-send-req X-Mms-Transaction-ID : 13452917 X-Mms-Version : 1.0 To : +393475946381/TYPE=PLMN From: +393389234175/TYPE=PLMN Subject: Test MMS message Date: 4 Oct 07:13:01 2003 Content-Type: application/vnd. wap.multipart.mixed Figure 10.8 Example of a MMS PDU header. MMS Format 305 support XHTML Mobile Profile, defined by the WAP Forum. XHTML Mobile Profile is a subset of XHTML 1.1, but a superset of XHTML Basic. SMIL permits the rendering of various media objects that can be organized dynamically on a predefined graphical layout to obtain a complete multimedia presentation. In particular, SMIL can be used to define a presentation as:  to set-up the temporal behavior of the different involved objects;  to describe the layout;  to associate media objects to hyperlinks;  to define conditional contents on the basis of several properties. Designers of SMIL presentations can use a spatial description, where the rendering space is organized in regions that can be nested and can contain images, clips or text; the presentation is described in an XML-like mode by means of appropriate tags. SMIL also supports a temporal description of the different objects involved in a presentation; in particular, it is possible to synchronize the objects in sequence or in parallel (e.g., contemporary sounds or melodies). Moreover, different objects can be nested in more complex presentations. With MMS SMIL, a multimedia presentation is composed of a slideshow, using slides with the same region configuration, organized (portrait or landscape with various sizes) to contain text, videos or images. Figure 10.9 shows a software tool for a Sony-Ericson mobile phone that helps in composing a slide show with images, sounds and a temporal relation between them. The MMS SMIL profile was initially defined outside standardization in a document called MMS conformance document [16]. Such documents provide recommendations to ensure interoperability between MMS devices produced by different manufacturers. They identify SMIL 2.0 features that can be used for constructing the slideshow that should have a sequence of parallel containers that represent the definition of a slide. Each media object identified inside the parallel container represents one Figure 10.9 Composition of an SMIL presentation. 306 Multimedia Messaging Service (MMS) component of a slide. The MMS Conformance document also specifies that a slide may be composed of a text region only, of an image region only (this can contain either an image or a video clip), or of two regions. It also contains rules about region dimensions, timing information and maximum image dimensions. 10.4 Transaction Flows When an MMS is sent, a transaction between the sending terminal, the MMS relay and the receiving terminal is originated using various transport schemes. The message exchange entails the following logically separate transactions (see Figure 10.10). (1) The MMS client of the originator sends a message to MMS relay (M-Send.req, M-Send.conf). (2) The MMS relay notifies the MMS client of the recipient about a new message (M-Notification.ind, M-NotifyResp.ind). (3) This MMS client fetches a message from the MMS relay (M-Retrieve.conf). (4) This MMS client sends a retrieval acknowledgement to the MMS relay (M Acknowledge.req). (5) The MMS relay sends a delivery report about a sent message to the MMS client of the originator (M-Delivery.ind). We now provide more details about the transaction flows shown in Figure 10.10. If a user agent creates an MMS, it sends an M-Send.req to the MMS relay (which replies with an M-Send.conf) by means of the WSP/HTTP-POST method. Then, the MMS relay sends, by means of WAP-PUSH, an M- Notification.ind (containing the MMS URI as data) to the receiving terminal for an incoming multi- media message, waiting for a reply (M-NotifyReport.ind). The MMS then is retrieved by using the URI through a WSP/HTTP GET connection [3]. Then, the user receives the MMS in the body of the PDU, named M-Retrieve.conf. The MMS client may further acknowledge the message retrieval by sending an M-Acknowledge.ind message to the MMS relay. The MMS relay, finally, replies to the message originator with an M-Delivery.ind message by means of WAP-PUSH. It is possible to analyze in detail the MMS transaction flows by referring both to the different interfaces for each kind of flow and to the relative transaction PDUs. M-Send.req M-Send.conf M-Delvery.ind M-Ack.ind M-Retrieve.conf WSP HTTP-GET M-NotifyRep.ind M-Notification.ind Originator MMS Relay Recipient Figure 10.10 MMS transaction flows between originator and recipient. Transaction Flows 307 MM1 The different operations and transaction flows that are possible over the MM1 interface are described below.  Message Submission. This is the submission of an MMS from its originator (i.e., the client on the mobile phone) to the related MMSC. The originator needs a circuit-switched (i.e., GSM) or a packed- switched (i.e., GPRS) connection through a (usually dedicated) WAP gateway to reach the MMSC. For this transaction flow the message submission PDU (M-send.req) and the relative confirmation (M-send.conf) are generated, and the originator MMS client may provide date and time of the submission request, otherwise provided by the MMSC. At least one recipient shall be provided by the MMS client to the MMSC; if a Multimedia Message Box (MMBox) is not supported by the MMSC, the MMBox-related parameters are ignored. The client can request to pay for a reply message. If this functionality is not supported by the MMSC, it will generate an error message. Finally, the submission request can be accepted by the MMSC with a confirmation (using parameter Message- ID for unique identification) or rejected, specifying the reason (i.e., permanent or transient nature); if the submission is accepted, the originator MMSC parses the MMS identifying the recipient MMSCs e and then routes the message to them.  Message Notification. This message is created by the recipient MMSC and sent to the recipient MMS client as part of a WAP-PUSH (encapsulated in several SMS) or as part of a data connection. The notification message PDU (M-notification.ind) delivered to the recipient MSS client is composed only of a header (essential information is contained in this PDU). The MMS client confirms the correct receipt of the notification with the response (M-notify-resp.ind), which is still only composed of a header. In this response the X-Mms-Status parameter is used to select different actions in order to defer the message retrieval or to do it immediately.  Message Retrieval. This is the procedure for the delivery of a multimedia message from the recipient MMSC to the recipient MMS client and it occurs after the corresponding notification is received by the recipient MMS client. First, a retrieval request (WSP/HTTP GET.req) is issued; then, if the message retrieval is successful, the retrieval confirmation (M-retrieve.conf) is returned with the multimedia message contained in the PDU body. It is possible to perform an immediate retrieval; in this case, the client starts the retrieval procedure automatically after the receipt of the relative notification. Otherwise, in deferred retrieval, the MMS client informs the MMSC that the message corresponding to the notification may be retrieved later, not automatically.  Delivery Report. The originator of the message can request the delivery report for every MMS recipient. Such a report specifies whether the message has been successfully retrieved or deleted or rejected or forwarded by the recipient MMS client; an indeterminate state is used if the message is sent to a message system where the delivery report is not supported. The forwarding of a delivery report to the MMSC is carried out over the MM4 interface, but the delivery from the MMSC to the originator MMS client is through the MM1 interface (with M-delivery.ind PDU).  Read Report. Another possibility for the MMS originator during the message submission phase is to request a read report for the submitted message; such a report is made for every recipient and it notifies if the message was read or deleted without being read. A read report can be generated in two different ways if allowed by the MMS recipient: (1) First method, allowed from Release 1.0. The recipient MMS client sends the read report in a PDU (with M-send.req PDU) to the message originator by using the MM1 interface and including the status of the corresponding multimedia message. e The originator MMSC denotes the MMSC of the mobile phone generating the multimedia message; the recipient MMSC denotes the MMSC of the mobile phone that receives the multimedia message. These two MMSCs are different in the case that the MMS has to cross networks of different operators. 308 Multimedia Messaging Service (MMS) (2) Second method, allowed from Release 1.1. Two PDUs are used: the first (M-read-rec.ind) from the recipient MMS client to its MMSC (over MM1) and then to the originator MMSC (over MM4); the second (M-read-orig.ind) from the originator MMSC to the originator MMS client, containing the read report.  Message Forward. Another capability of MMS clients (from MMS Release 1.1) is to support the forwarding of MMS (i.e., to an e-mail server). For this kind of request, the M-forward.req PDU is used with the related confirmation (M-forward.conf). Note that if the MMBox is not supported by the originator MMSC, the parameters of the forward request are ignored. However, if the forward request is accepted by the MMSC, it inserts the address of the forwarding MMS client in the ‘from’ field as well as a sequence number in the message to be forwarded (it can additionally insert date and time). The MMSC can forbid the forwarding of a message if it contains protected media objects.  MMBox Interactions: If MMBox is supported by the corresponding MMSC (from MMS Release 1.2), the MMS client can: employ the MMSC (M-Mbox-store.req) to store a message in the MMBox; update the messages already stored in the MMBox; upload a message to the MMBox, for messages created by the user or previously retrieved from MMSC (M-Mbox-upload.req); delete a message (or more messages) from the MMBox in a single transaction (with M-Mbox- delete.req PDU); view information on the contents of the MMBox: the MMS client can request information about message parameters or message contents (using M-Mbox-view.req PDU). MM2 The MM2 interface and its transaction flows are implemented in a proprietary manner because no technical realization of this reference point has been specified by standardization organizations. MM3 As seen in the above Section 10.2.2 on MMS interfaces, the MM3 reference point is used to permit the MMSC to exchange messages with external servers. There are various mechanisms for discovering incoming messages from external messaging servers: forwarding of the message to the MMSC; notifying the MMSC for a message waiting for retrieval; polling made by the MMSC to external messaging servers for incoming messages. It may be necessary for the MMSC to perform the conversion of the MMS in an appropriate format (supported by the external server), for example in a text-based MIME representation for the transfer through SMTP. MM4 At present, only one technical realization is available for this interface, standardized by 3GPP, using SMTP and based on the transaction flows described for the MM1 interface.  Routing forward a message. This request is made by an originator MMSC to transfer an MMS to a recipient MMSC (MM4-forward.req). If it is possible, the recipient MMSC replies with a forward response (MM4-forward.res) composed by several parameters. If errors occur during the request process phase, an error code is generated.  Routing forward a delivery report. This request allows the transfer of a delivery report between two MMSCs, that is the originator MMSC and the recipient MMSC. The recipient MMSC can request such a report (MM4-delivery_report.req) from the originator MMSC that thus sends its response (MM4-delivery_report.res). Several states can be reported: ‘expired’, ‘retrieved’, ‘deferred’, ‘inde- terminate’, ‘forwarded’, ‘unrecognized’, and the value of the ‘sender’ field is the address of the recipient MMSC. Transaction Flows 309  Routing forward a read report. It is used for the transfer of a read report between two MMSCs. The request to forward a read report is made by the recipient MMSC (with MM4-read_reply_report.req); then, the originator MMSC acknowledges this request with the response (MM4-read_reply_repor- t.res). Two read states are reported over MM4, that is ‘read’ or ‘deleted without being read’. MM5 As seen previously, the transaction flows over this interface connect the MMSC with other network entities such as the HLR. Similarly to the MM2 reference point, at present no technical realization of the MM5 interface has been standardized. MM6 This interface supports flow interactions between the MMSC and user databases; this reference point has yet to be standardized. MM7 To enable interactions between VAS applications and MMSC, MM7 implements the following kinds of transactions:  message submission;  message delivery;  message cancellation and replacement;  delivery report;  read report;  message errors (MMSC error or VASP error). A more detailed description of the above transaction flows over MM7 is provided in the Section 10.5, which deals with MMS-based VAS, since MM7 is actually the interface for VAS. MM8 Over this interface, network operators use proprietary transport protocols since at present a transaction flow is not standardized for sending charging data from the MMSC to the billing system. 10.5 MMS-based Value-added Services In order to enable VASPs to support many multimedia contents (i.e., MMS) for multiple devices, the MM7 interface has been standardized by 3GPP, enabling communications between the MMSC of the MMS provider and the VASP (see Figure 10.11). This section contains a detailed description of the MM7 transaction flows. The VAS server can perform several operations such as authentication, authorization, confidentiality and charging information. All these operations have to be supported by the standard interface and will be discussed in more detail below. As for charging, the VAS server can indicate, in the case of message submission, which part is going to pay for message handling: the VASP, the recipient (one or more), both of them, with the cost shared between them or neither the recipient nor the VASP. Note that a VASP needs commercial agreements with the MMS provider to apply one of the previous billing options, and has to control how message contents are redistributed using appropriate DRM mechanism defined in the MMS 1.2 standard. The use of common standard-based Web service interfaces will allow the possibility of supporting the quick and cost-effective deployment of revenue-generating mobile services by means of system integration. The mobile Web service interfaces are standardized by OMA, 3GPP and W3C. Such interfaces will be implemented on the basis of widely accepted standard technologies, like SOAP, XML, 310 Multimedia Messaging Service (MMS) WSDL (Web Services Description Language) and HTTP. The first two technologies, SOAP and XML, are part of the OSA standard, defined by W3C. XML allows a general data representation, whereas SOAP is a simple communication protocol (HTTP is the underlying protocol); they allow open-source development of software and together provide a single and transport-neutral method of contents developed for different types of terminals like PCs, PDAs and, of course, mobile phones. In this environment, a VASP can use the HTTP POST method to exchange SOAP messages; the SOAP processing is simple, since it requires only HTTP and XML libraries for HTTP authentication mechanisms. OSA supports network functionalities such as discovery and authentication. Moreover, it can enable new services without stopping already-in-progress applications. It is important to note that there are other proprietary mechanisms that could be used to deliver VASP messages:  by employing SMTP – the MMS content is attached to an e-mail sent to ‘phonenumber@mms. domain’;  by using an HTTP POST with the MIME content type set as ‘multipart/form-data’;  by means of an HTTP GET, if the MMS content is precompiled and resides on an external Web server. Let us focus on the delivery of VAS over MM7. The MMSE allows VASs that may be supplied by the network operator or by third party VAS providers; hence, it is important to define how these VASPs interwork with the MMS relay/server. Message Submission from a VAS A VAS application can send a submission request (MM7_ submit.req) for an MMS to the MMSC (directed to one or more recipients or a distribution list) over the MM7 interface. This request can be associated with several features:  Authorization, with identification of both the service and the VASP;  Addressing, where the recipient(s) is specified (the address of the originator may be present in the submission request);  MM7 version, message type and transaction ID, for a quick link for the corresponding response;  Linked message ID, for the association with a previous message that had an identification as part of the submission request;  Message subject, that is a short text provided by the originator (like the subject of an e-mail);  Priority, indicating the importance of the message; MM1 MM7 Relay MMS User Agent A MMS VAS Applications SOAP over HTTP Figure 10.11 VASP-relay-user interactions in the MMS reference architecture. MMS-based Value-added Services 311 [...]... infrastructure and devices, the basic system concepts for IMP include:      end-to-end transport of messages, presence and control; distribution of function between edge and core network; resource consumption, particularly in wireless handsets and networks; systems architecture for scalability and reliability; security; 326 Instant Messaging and Presence Service (IMPS)  gateways to other services;  APIs and. .. 11] IETF XMPP standardized the core XML protocol used by Jabber [4, 5] Leading wireless handset manufacturersa formed the Wireless Village consortium in 2001 and produced specifications for a standard protocol In 2002 the Wireless Village work was moved into the Open Mobile Alliance (OMA), which has published an updated set of Wireless Village specifications [12] a Ericsson, Motorola and Nokia Client... features and Web services infrastructure, including HTTP, TCP/IP, XML and SOAP 11 Instant Messaging and Presence Service (IMPS) John Buford and Mahfuzur Rahman 11.1 Introduction An instant messaging and presence service (IMPS) supports a community of users to exchange messages in real time and share their online status This service is a linkage to other services such as file transfer, telephony and online... application level, and is compliant with IETF RFC 27 78 [8] , RFC 2779 [9] and the IMPP CPIM [22] model The protocols may run over different transport layer and bearer protocols 11.4.1.2 Presence and Instant Messaging Service Instant Messaging Service WV uses standard MIME (Multipurpose Internet Mail Extensions) encoding so that instant messages can carry a variety of content types Out-of-band multimedia content... Horoscopes MMS will make horoscopes look (and sound) much better than via SMS, but the basic functionality of the service could remain the same Location-based Services Other candidate services that are suitable for employing MMS are location-based services that use positioning technologies With MMS, service operators can deliver services that might include:  maps and routing;  location of the nearest... publish/subscribe mechanism for presence has become central to other applications such as voice calls, online gaming and collaboration Emerging Wireless Multimedia: Services and Technologies Edited by A Salkintzis and N Passas # 2005 John Wiley & Sons, Ltd 320 Instant Messaging and Presence Service (IMPS) A user has a live view of the presence of his online associates or buddies When a buddy’s presence changes,... OMA Wireless Village Wireless Village (WV) [12] is an open specification for mobile IMP services (see Figure 11.6) This system is designed for the mobile environment and is being standardized by the OMA (Open Mobile Alliance) The specification is primarily dedicated to 2G and 2.5G communication networks The goal of Wireless Village is to deliver symmetrical IMP communication between any mobile device and. .. - Wireless Village - CSP / CLP / SSP CPIM Session - HTTP, SIP, WSP / WTP Security - TLS, WTLS Transport - TCP, UDP, WDP SMS IP over 2.5G / 3G Wireless Mobile IP Figure 11.7 Wireless Village protocol suite [12] CLP is designed to provide the Wireless Village server and the CLI client with the means to communicate and interact with each other to support the IMP services in a legacy CLI client The Wireless. .. interoperability, security, manageability and evolution have motivated several standardization efforts Beginning in 19 98, the IETF’s IMPP (Instant Messaging and Presence Protocol) Working Group developed a model [8] and a set of protocol requirements [9] Figure 11.3 shows the key IMP elements in the IMPP model There are two services – Instant Message Service and Presence Service The Instant Message... Yahoo! and MSN followed in 1997, 19 98 and 1999, respectively In 19 98 Jeremie Miller developed Jabber [3], an open-source IMP system that has grown into a large community Jabber uses a standard protocol [4, 5] based on XML SMS (Short Message Service) [6] and its successor MMS (Multimedia Messaging Service) [7] are distinguished from IM in that they provide store -and- forward messaging without presence . standard technologies, like SOAP, XML, 310 Multimedia Messaging Service (MMS) WSDL (Web Services Description Language) and HTTP. The first two technologies, SOAP and XML, are part of the OSA standard,. manageability and evolution have motivated several standardization efforts. Beginning in 19 98, the IETF’s IMPP (Instant Messaging and Presence Protocol) Working Group developed a model [8] and a set. Internet Message Format, IETF RFC 282 2, April 2001. [7] P. Faltstrom, E.164 number and DNS, IETF RFC 2916, September 2000. [8] Wireless Application Protocol Forum, Ltd, Multimedia Messaging Service,