emerging wireless multimedia services and technologies phần 8 pot

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 th

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 SMSrelies 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 theirknowing the complex technological processes that are behind this service Hence, it is important toallow the personalization of the user interface to be as friendly as possible in order to permit the user toexploit 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 subsectionbelow The structure of a PDU is standardized by the WAP Forum (now OMA) in the WAP-209-MMSencapsulation specification [11]

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 MultipartMessage (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 headerPart1 body

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 isdescribed in Section 10.4

no response message to the delivery report.

Read Reporting

When the originating terminal requested the read-reply in the MMS, the recipient terminal may send anew MMS back to the originating terminal when the user has read the MMS The content of themultimedia 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 ordinarymultimedia message When the originating terminal receives the read-reply, it shall not create a deliveryreport or a read-reply message

An example of a PDU header for MMS delivery (before binary encoding, according to the WAPspecifications) is shown in Figure 10.8

10.3.1.1 The SMIL Language

The Synchronized Multimedia Integration Language (SMIL, pronounced ‘smile’) is an XML-basedlanguage used to ease the organization of media objects contained in an MMS It is the mandatoryformat 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 particularthose needing to represent timing and synchronization For example, SMIL 2.0 components are usedfor integrating timing into XHTML

SMIL 2.0 is defined as a set of markup modules that characterize the semantics and an XML syntax forcertain areas of SMIL functionality

The 3GPP MMS uses a subset of SMIL 2.0 as a format of the scene description [14] MMS clients andservers shall support the 3GPP SMIL Language Profile This profile is a subset of the SMIL 2.0Language Profile, but a superset of the SMIL 2.0 Basic Language Profile 3GPP TS 26.234Recommendation 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 3GPPMMS uses a subset of XHTML 1.1 as a format for scene description MMS clients and servers shall

Content-Type: application/vnd wap.multipart.mixed

Figure 10.8 Example of a MMS PDU header.

support XHTML Mobile Profile, defined by the WAP Forum XHTML Mobile Profile is a subset ofXHTML 1.1, but a superset of XHTML Basic.

SMIL permits the rendering of various media objects that can be organized dynamically on apredefined graphical layout to obtain a complete multimedia presentation In particular, SMIL can beused 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 inregions that can be nested and can contain images, clips or text; the presentation is described in anXML-like mode by means of appropriate tags SMIL also supports a temporal description of thedifferent objects involved in a presentation; in particular, it is possible to synchronize the objects insequence or in parallel (e.g., contemporary sounds or melodies) Moreover, different objects can benested in more complex presentations

With MMS SMIL, a multimedia presentation is composed of a slideshow, using slides with the sameregion configuration, organized (portrait or landscape with various sizes) to contain text, videos orimages Figure 10.9 shows a software tool for a Sony-Ericson mobile phone that helps in composing aslide show with images, sounds and a temporal relation between them

The MMS SMIL profile was initially defined outside standardization in a document called MMSconformance document [16] Such documents provide recommendations to ensure interoperabilitybetween 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 representthe definition of a slide Each media object identified inside the parallel container represents one

Figure 10.9 Composition of an SMIL presentation.

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 tworegions It also contains rules about region dimensions, timing information and maximum imagedimensions

10.4 Transaction Flows

When an MMS is sent, a transaction between the sending terminal, the MMS relay and the receivingterminal is originated using various transport schemes The message exchange entails the followinglogically 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 ofthe 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 URIthrough 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 anM-Acknowledge.ind message to the MMS relay The MMS relay, finally, replies to the messageoriginator 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 differentinterfaces for each kind of flow and to the relative transaction PDUs

M-Send.reqM-Send.conf

M-Delvery.ind

M-Ack.indM-Retrieve.confWSP HTTP-GETM-NotifyRep.indM-Notification.ind

Figure 10.10 MMS transaction flows between originator and recipient.

ID for unique identification) or rejected, specifying the reason (i.e., permanent or transient nature); ifthe submission is accepted, the originator MMSC parses the MMS identifying the recipient MMSCse

and then routes the message to them

Message Notification This message is created by the recipient MMSC and sent to the recipient MMSclient as part of a WAP-PUSH (encapsulated in several SMS) or as part of a data connection Thenotification message PDU (M-notification.ind) delivered to the recipient MSS client is composedonly of a header (essential information is contained in this PDU) The MMS client confirms thecorrect 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 todefer the message retrieval or to do it immediately

Message Retrieval This is the procedure for the delivery of a multimedia message from the recipientMMSC to the recipient MMS client and it occurs after the corresponding notification is received bythe recipient MMS client First, a retrieval request (WSP/HTTP GET.req) is issued; then, if themessage retrieval is successful, the retrieval confirmation (M-retrieve.conf) is returned with themultimedia message contained in the PDU body It is possible to perform an immediate retrieval; inthis case, the client starts the retrieval procedure automatically after the receipt of the relativenotification Otherwise, in deferred retrieval, the MMS client informs the MMSC that the messagecorresponding to the notification may be retrieved later, not automatically

Delivery Report The originator of the message can request the delivery report for every MMSrecipient Such a report specifies whether the message has been successfully retrieved or deleted orrejected or forwarded by the recipient MMS client; an indeterminate state is used if the message issent to a message system where the delivery report is not supported The forwarding of a deliveryreport to the MMSC is carried out over the MM4 interface, but the delivery from the MMSC to theoriginator 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 torequest a read report for the submitted message; such a report is made for every recipient and itnotifies if the message was read or deleted without being read A read report can be generated in twodifferent 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 thestatus 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.

(2) Second method, allowed from Release 1.1 Two PDUs are used: the first (M-read-rec.ind) from therecipient 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, containingthe read report.

Message Forward Another capability of MMS clients (from MMS Release 1.1) is to support theforwarding of MMS (i.e., to an e-mail server) For this kind of request, the M-forward.req PDU isused with the related confirmation (M-forward.conf) Note that if the MMBox is not supported by theoriginator 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 aswell 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 Release1.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 fromMMSC (M-Mbox-upload.req);

delete a message (or more messages) from the MMBox in a single transaction (with delete.req PDU);

M-Mbox-view information on the contents of the MMBox: the MMS client can request information aboutmessage 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 notechnical 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 theMMSC to exchange messages with external servers There are various mechanisms for discoveringincoming 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 externalmessaging 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-basedMIME representation for the transfer through SMTP

Routing forward a delivery report This request allows the transfer of a delivery report between twoMMSCs, that is the originator MMSC and the recipient MMSC The recipient MMSC can requestsuch 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 therecipient MMSC

Routing forward a read report It is used for the transfer of a read report between two MMSCs Therequest 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 networkentities such as the HLR Similarly to the MM2 reference point, at present no technical realization of theMM5 interface has been standardized

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 transactionflow 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 theMMS provider and the VASP (see Figure 10.11) This section contains a detailed description of theMM7 transaction flows

The VAS server can perform several operations such as authentication, authorization, confidentialityand 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 sharedbetween them or neither the recipient nor the VASP Note that a VASP needs commercial agreementswith the MMS provider to apply one of the previous billing options, and has to control how messagecontents 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 thequick and cost-effective deployment of revenue-generating mobile services by means of systemintegration The mobile Web service interfaces are standardized by OMA, 3GPP and W3C Suchinterfaces will be implemented on the basis of widely accepted standard technologies, like SOAP, XML,

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, whereasSOAP is a simple communication protocol (HTTP is the underlying protocol); they allow open-sourcedevelopment of software and together provide a single and transport-neutral method of contentsdeveloped for different types of terminals like PCs, PDAs and, of course, mobile phones In thisenvironment, a VASP can use the HTTP POST method to exchange SOAP messages; the SOAPprocessing is simple, since it requires only HTTP and XML libraries for HTTP authenticationmechanisms.

OSA supports network functionalities such as discovery and authentication Moreover, it can enablenew services without stopping already-in-progress applications

It is important to note that there are other proprietary mechanisms that could be used to deliver VASPmessages:

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 Webserver

Let us focus on the delivery of VAS over MM7 The MMSE allows VASs that may be supplied by thenetwork operator or by third party VAS providers; hence, it is important to define how these VASPsinterwork 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 beassociated 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 thesubmission 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 ofthe 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

RelayMMS User

Agent A

MMS VASApplications

SOAP overHTTP

Figure 10.11 VASP-relay-user interactions in the MMS reference architecture.

Class, specifying the category of the message content (i.e., advertisement, information, etc.);

Service code, for billing purposes;

Time stamping, with time and date of the request;

Time constraints, for example a validity period;

Reply charging, specifying if the message will be paid by the VASP and the related constraints (i.e., size);

Reporting, because the VAS application can request the delivery and/or read–reply reports;

Restrictions of content adaptation;

Content type of the message

If the submission request is successful, the MMSC sends an acknowledgment message (MM7_submit.res) with a response associated to the features described below:

MM7 version, message type and transaction ID;

Message ID, to the VAS application, if the submission request is accepted by the MMSC;

Request status of the submission request (successful or failed due to an error)

Message Cancellation and Replacement

If an MMS submission was successful (according to the previous point), the VAS application can cancelthe sent message or the submitted message can be replaced by a new one (only if this message has notyet been forwarded or retrieved by the recipient)

In the first case, the request to cancel the message (MM7_cancel.req) is associated with:

MM7 version, message type and transaction ID;

Authorization;

Addressing, where the originator is specified;

Message ID, to which the request applies, provided by the MMSC as part of the response.The features of a replacement request (MM7_replace.req) are:

Content adaptation restrictions, for adaptation or not;

Service code, used by the MMS provider for billing purposes;

The acknowledgments are MM7_cancel.res and MM7_replace.res, respectively, and are associated with:

MM7 version, message type and transaction ID;

Request status of the cancellation/replacement request (successful or failed due to an error).Delivery and Read–reply Reports

Delivery reports and read–reply ones can be requested by a VAS application as part of a messagesubmission request If these functionalities are allowed by the message recipient, the MMSC generatesthese reports and sends them to the VAS application First, the MMSC has to send, respectively, theMM7_delivery_report.req and the MM7_read_reply_report.req requests to the VAS application, withthe following features:

MM7 version, message type and transaction ID;

Addressing, where the originator is specified;

Message ID, to which the report is related, is provided by the MMSC as part of the response;

Time stamping, indicating time and date of the message handling;

Message status, for instance, retrieved, deleted, etc

Then, the VAS application acknowledges with MM7_delivery_report.res and t.res respectively, associated with:

MM7_read_reply_repor-
MM7 version, message type and transaction ID;

Request status of the report request (successful or failed due to an error)

Message Delivery

The MMSC can request the delivery of a message to the VAS application (MM7_deliver.req) Such arequest is associated with several features:

Addressing, where both the originator and the recipients are specified;

Authentication, provided by the MMSC as part of the request;

MM7 version, message type and transaction ID;

Linked message ID, used by the VAS application for handling a subsequent submission of a messagerelated to a previously delivered message;

Message subject;

Priority;

Class, specifying the category of the message contents;

Time Stamping, containing time and date of message submission;

Reply charging, specifying if the message will be paid for by the VASP and the related constraints(i.e., size);

Content type

When the delivery request arrives to the VAS application, it acknowledges with a response message(MM7_delivery.res) with the following features:

MM7 version, message type and transaction ID;

Service code, used by the MMS provider for billing purposes;

Request status

Message Errors

If an error occurs during a request or a process, two generic error notifications can be used:MM7_RS_error.res (for MMSC to inform the VAS application about a request processing error) andMM7_VAS_error.res (for a VAS application to inform the MMSC about a request processing error) thatare associated with the following features:

MM7 version, message type and transaction ID;

Error status, indicating the type of error that has occurred

10.5.1 Survey of MMS-based Services

Many types of services can be provided by means of the MMS architecture, taking into accountinteractivity, entertainment and personalization This section is devoted to giving an overview ofdifferent MMS-based services that can be attractive for users

We can consider the following different typologies of multimedia messaging services:

mobile personal communications;

mobile dating;

More details on all the above service categories are provided below.

Mobile Personal Communications

Although MMS is used to communicate between two people, some audio features of an MMS allow it to

be used as advanced voice mail If the end-user is not available, a remote server can store the message inMMS format

Mobile Information Services

MMS provides a richer way to deliver information than SMS MMS could be particularly suited forrepresenting sporting events (i.e., sporting action), finance (i.e., some financial graphs) and news, ingeneral The key element for information services is that they be provided in a format that is compactand easy to view; this is exactly what MMS can do For example, a Japanese application called

‘Namidensetsu’ provides sea, wave and weather information on surfing locations

Mobile Marketing

This type of service is well suited for MMS due to its graphical potentials; it can be a good complement

to branding and advertising campaigns For example, a user could opt to receive a free informationservice from a movie studio, which could increase interest in its products by distributing MMS messages(e.g., video clips)

Mobile Dating

The convenience and the privacy of MMS mean that mobile dating can be a very popular service, betterthan the related Internet-based version It is possible to have different types of messages: first textmessages, then audio communication followed by pictures and video messages if both parties agree tomaintain this type of contact (thus preventing a malicious use of this service)

Collectable cards MMS can deliver this service where users pay to receive a random set of cards(messages); in addition to the revenues generated by the delivery of each card, the service alsogenerates traffic by allowing users to exchange cards between themselves

Celebration cards These are prepackaged MMS, such as birthday cards, similar to the gift cards sold

in shops

Adult services This will play an important part in mobile data services, but these services are critical

to be managed for many operators Mobile terminals have small displays, they are personal, portableand can allow a discreet reception of such contents

Quizzes and competitions MMS can allow service providers to deliver quizzes in a more compellingway than by means of simple text (SMS); these competitions can be sponsored by an advertiser orpaid for by the users themselves.

Horoscopes MMS will make horoscopes look (and sound) much better than via SMS, but the basicfunctionality of the service could remain the same

Location-based Services

Other candidate services that are suitable for employing MMS are location-based services that usepositioning technologies With MMS, service operators can deliver services that might include:

maps and routing;

location of the nearest point of interest;

information about locations

Note that it is quite important for a VASP to be able to deliver location-based services using MMS ratherthan to require an application to be downloaded to support the service, which would severely limit thepotential market for any service unless the application can be easily installed In this regard, the PALIO(Personalised Access to Local Information and services for tOurists) IST project developed a service forproviding location-aware information to tourists on traffic jams, museums, restaurants, hotels, etc [17].This experimental service has been based on simple textual contents (i.e., SMS), but it could be easilyenriched by introducing MMS (providing museum photos, traffic maps or audio files), thus addingfurther value to the service itself

10.6 MMS Development Tools

In order to facilitate the introduction of MMS in the market with a consistent set of services, manytelecommunication companies provide tools to develop MMS software applications There are severaltools that permit the implementation of MMS-based applications in an easy way with several libraries.This section looks at some key examples

Sony-Ericsson enables the download of the following tools from the developer on-line resources,known as Ericsson Mobility World [18]:

MMS composer This creates MMS messages containing a scene description by using a PC and, then,forwards these messages to a handset connected via serial cable

AMR (Adaptive MultiRate) and WAV (Waveform data) conversion tool This has a graphical or DOSinterface for the conversion of a WAV file in AMR format (and vice versa)

Nokia provides the following set of development tools and guidelines at the Nokia developerForum [19]:

Emulator for MMSC interface This emulates the MM7 interface (at present, the Nokia MMSC isbased on proprietary HTTP-based commands)

MMS Java library This includes message creation, encoding, decoding and sending to an MMSCemulator for the development of Java MMS-based applications

MMS developer’s suite This tool facilitates the creation of MMS with rich presentations (add-on forAdobe GoLive)

Series 60 SDK Symbian OS and MMS extension This is a PC emulator for creating and testingapplications for mobile phones based on the ‘Series 60’ platform

Mobile Internet Toolkit This tool allows the testing of multimedia messages and the creation ofmessages from many media objects

Another tool for MMS development is MMS SDK by Openwave [20] It operates at the MM7 interface,simplifies the development of MMS applications and can be used in combination with other Openwavesoftware to view how MMS messages would appear on handsets It includes the following components:

MMS Library This contains the tools necessary to develop MMS applications based on the MM7protocol

MM7 Protocol This provides a means of sending value-added service contents from third parties tosubscribers;

MMS Library API This encapsulates the MM7 standard protocol in a Java API for the development

of third party applications that can send multimedia messages to and from an MMSC

MMS Library Authentication and Security This provides standalone applications supporting securecommunication using HTTP client authentication schemes and the Secure Socket Layer (SSL)protocol

Finally, the MMS Suite is a tool provided by one of the largest open-source software developmentWebsites, SourceForge [21] This Java-based software allows the creation of MMS documents with

an unlimited number of pages that can be viewed with a mobile phone-like viewer It is also possible

to add images, sounds and text to a page (the following formats are supported: JPG, GIF and WAV)and it is possible to specify the layout of an MMS document MMS Suite runs on Linux, Mac orWindows

Note that for both the Sony-Ericsson and the Nokia tools, the access to resources for developersrequires prior online registration

10.7 MMS Evolution

Multimedia messaging as well as SMS may support the society by increasing interactions betweenpeople Hence, by combining such novel services with location awareness, it is possible to provide theusers with timely and location-dependent services In addition to this, dynamic discussion groups andvirtual meetings can be supported Naturally, these innovative trends for MMS-based services also callfor new rules in order to distinguish useful messaging from spamming Personalization and adaptationplay a fundamental role in addressing these problems In this way, the new technologies can provide realsupport in everyday life for people such as citizens, workers, travelers and tourists

MMS is attractive as it can provide the basis for novel services For instance, a type of surveillance and remote control system that periodically sends (or in particular conditions) a user (orspecialized security system) images of their home when they are away This approach is also importantfor the remote control of plants, etc Another significant example for the future evolution of MMS-basedservices can be guide services realized with maps sent through MMS Finally, many other applicationscan be foreseen, for advertising products, etc

video-As for the technological evolution of multimedia messaging, we can consider that differentapproaches are possible In particular, we can refer here to MExE, a protocol that is able to provide

a standardized environment to support different applications on mobile terminals In fact, it can providesmart menus, personalized interfaces through the support of operators and service providers Moreover,

we can distinguish the following different MExE groups, depending on the potentialities of mobileterminals:

Classmark 1, for WAP-enabled mobile phones with the possibility to access limited contents on theWeb;

Classmark 2, for mobile phones that support the JavaPhone Application platform It is possible tosupport Java Applets on mobile phones with reduced processing capabilities for messaging,calendars, management of list of addresses, etc.;

Classmark 3, for mobile smart-phones that support Java 2 Micro Edition (J2ME) In this case, morecomplex applications can be supported;

Classmark 4, for enhanced mobile phones that employ Common Language Infrastructure (CLI)Compact Profilef, providing an open development environment for applications written in differentlanguages (e.g., Visual Basic) A minimal set of libraries and functionalities is specified in order tomanage protocols such as HTTP, SOAP, etc

Through the evolution from Classmark 1 to Classmark 4, an enhancement of MMS-based services isexpected in the future years

References

[1] Simon Buckingham, Next Messaging: From SMS to EMS to MMS, Mobile Lifestreams, December, 2000 [2] Jarkko Sevanto, Multimedia Messaging Service for GPRS and UMTS, Wireless Communications and Network- ing Conference, Vol 3, pp 1422–1426, 1999.

[3] 3GPP, Multimedia Messaging Service (MMS); Functional description; Stage 2; TS 23.140, Releases 1999, 4, 5 and 6.

[4] Website http://www.lebodic.net/mms_resources.htm

[5] Wireless Application Protocol Forum, Ltd, Multimedia Messaging Service, Architecture Overview tion, WAP-205-MMSArchOverview-20010425-a, April 2001.

Specifica-[6] P Resnick, Internet Message Format, IETF RFC 2822, April 2001.

[7] P Faltstrom, E.164 number and DNS, IETF RFC 2916, September 2000.

[8] Wireless Application Protocol Forum, Ltd, Multimedia Messaging Service, Client Transactions Specification, WAP-206-MMSCTR-20020115-a, January 2002.

[9] 3GPP, Open Service Access (OSA) Application Programming Interface (API); Part 1: Overview, TS 29.198-01, Version 6.0.1, February, 2004.

[10] Eurescom P920 project, Deliverable ‘UMTS network aspects’, January 2001.

[11] Wireless Application Protocol, Ltd, MMS Encapsulation Protocol, WAP-209-MMSEncapsulation-20020105-a, January 2002.

[12] Nokia, MMS Center Application Development Guide, Version 1.0, March 4, 2002 (available at the Website www.forum.nokia.com/).

[13] Nokia How To Create MMS Services, Version 3.1, August 28, 2002 (available at the Website www.forum nokia.com/).

[14] 3GPP, Transparent end-to-end packet switched streaming service (PSS); 3GPP SMIL Language Profile, TS 26.246, V6.0.0 (2004-06).

[15] 3GPP, Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs, TS 26.234 V6.1.0 (2004-09).

[16] Open Mobile Alliance, MMS Conformance Document 1.2, OMA-MMS-CONF-v1_2-20040727-C, July 2004 [17] PALIO Project home page http://www.palio.dii.unisi.it/

[18] Ericsson Mobility Word Website http://www.ericsson.com/mobilityworld

[19] Nokia Developer Forum Website http://www.forum.nokia.com

[20] Openwave Website http://developer.openwave.com/dvl/tools_and_sdk/openwave_mobile_sdk/mms_sdk [21] SourceForge Website http://sourceforge.net

f CLI Compact Profile specifies a minimal set of class libraries, supporting both common runtime library features and Web services infrastructure, including HTTP, TCP/IP, XML and SOAP.

as standards-based IMP systems become more prominent.

11.1.1 Basic Concepts

Following the rapid growth in the 1990s of consumer adoption of Internet services including e-mail andthe web, instant messaging has become a mass market phenomena Online international communities ofmillions of users have been drawn to instant messaging (IM) service providers such as AOL AIM/ICQ,Microsoft Messenger and Yahoo! Messenger As IM popularity has grown, other uses in enterprise andconsumer applications have emerged, including team collaboration, online gaming and news distribu-tion

Cellular service providers, which have provided two-way paging and SMS messaging services sincethe early 1990s, have more recently added instant messaging clients for the leading IM services This isexpected to fuel further growth in the use of IM Awareness of the mobile user’s location is also enablingnew IMP applications

The real-time character of instant messaging produces the experience of live conversation, albeit intext Associated with this conversation is mutual awareness of the conversant’s state, in IM terminologythis awareness of other user’s states is referred to as the user’s presence In typical IM systems, a usersets his presence state and makes the presence state available for other users by publishing it Users whowish to receive the published changes subscribe to it and, if authorized by the publisher, receive updateswhen the state changes

Although instant messaging and presence are closely associated, the publish/subscribe mechanism forpresence 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

A user has a live view of the presence of his online associates or buddies When a buddy’s presencechanges, for example, indicating that the user is available, the user detecting the change canimmediately initiate an invitation to the buddy to join an IM session, an online game or a multimediacall In this way, a user’s view of the active set of presence subscriptions is a launching point for avariety of multi-party interactions However because of the close association of instant messaging andpresence functions, it is convenient to refer to IMP with the understanding that the broader set ofinteractions is intended.

11.1.2 Brief History

Today’s IMP systems are built on the legacy of early bulletin board systems (BBSs), which werefollowed in the late 1980s by distributed chat systems The earliest Internet-based chat system, InternetRelay Chat (IRC) is still in use today with thousands of sites worldwide

IRC, developed by Jarkko Oikarinen in 1988, is a multi-user chat system where participants convene

on ‘channels’, usually with a topic of conversation, to talk in public or private groups (see Figure 11.1)

It consists of various separate networks of IRC servers The largest IRC networks are EFnet (the originalIRC net), Undernet, IRCnet, DALnet and NewNet Each IRC server hosts a set of channels and acts as arelay for clients that are connected to channels hosted by other servers [1] Clients and serverscommunicate using the standard IRC protocol

Mirabilis launched the ICQ (‘I seek you’), the first instant messaging and presence service [2] in

1996 AOL’s AIM, Yahoo! and MSN followed in 1997, 1998 and 1999, respectively

In 1998 Jeremie Miller developed Jabber [3], an open-source IMP system that has grown into a largecommunity Jabber uses a standard protocol [4, 5] based on XML SMS (Short Message Service) [6] andits successor MMS (Multimedia Messaging Service) [7] are distinguished from IM in that they providestore-and-forward messaging without presence

Figure 11.1 IRC chat session (source: www.joher.com).

11.1.3 Standardization

Basic IMP systems design is well understood and multiple large-scale proprietary implementations havebeen operating for years In the last few years, issues of interoperability, security, manageability andevolution have motivated several standardization efforts Beginning in 1998, the IETF’s IMPP (InstantMessaging and Presence Protocol) Working Group developed a model [8] and a set of protocolrequirements [9]

Figure 11.3 shows the key IMP elements in the IMPP model There are two services – InstantMessage Service and Presence Service The Instant Message Service has two clients The Sender sendsinstant messages; the Instant Inbox receives instant messages Messages may be filtered; delivery rulesdefine the filters

Presence Service has two clients The Presentity (Presence Entity) publishes presence information.The Watcher receives presence information The Watcher can be a Fetcher that receives presenceinformation on a demand basis or a Subscriber that requests a subscription to a Presentity TheSubscriber receives presence information via notification when the Presentity publishes it These entitiesinteract with users (principals) through User Agents (UA), which represents the user interface function.Presence Information is a sequence of tuples, each includes:

Status (e.g., online/offline/busy/away/do not disturb)

Open: IM accepted; Closed: IM not accepted;

Communication address (contact address, contact type)

The Presence Service may make information about a Watcher available to other Watchers For example,what is the list of Presentities that Tom’s Watcher subscribes to or what are the Presentities that Sue’sWatcher has received presence information for in the last eight hours? There are visibility rules that

Server 15 Server 13 Server 14

Server 11 Server 1 Server 12

Server 7

Server 2 Server 3

Server 4 Server 5 Server 6

Server 8 Server 9 Server 10

Figure 11.2 IRC server network [1] is a spanning tree over which messages from clients are routed.

constrain how the Presence Service makes this available The Watcher UA specifies the visibility rulesfor its associated Watcher entity.

The IMPP Protocol requirements [9] cover the following aspects:

The relationship between presence service and instant message service;

interoperability across domains;

dimensions of scalability, including entities, domains and subscriptions;

access control;

end-to-end signaling and transport through proxies and firewalls;

security, including message encryption and authentication

The work on standard protocols then proceeded within IETF by two separate approaches The SIP(Session Initiation Protocol) Working Group launched the SIMPLE Working Group, which is devel-oping specifications for IMP that are compatible with the SIP specifications [10, 11] IETF XMPPstandardized the core XML protocol used by Jabber [4, 5]

Leading wireless handset manufacturersa formed the Wireless Village consortium in 2001 andproduced specifications for a standard protocol In 2002 the Wireless Village work was moved into theOpen Mobile Alliance (OMA), which has published an updated set of Wireless Village specifications[12]

a Ericsson, Motorola and Nokia.

A broad set of security issues includes:

Spam, or unsolicited messages;

messages or downloaded content containing viruses;

denial of service attacks;

11.2.1 Desktop

Figure 11.4 shows the contact list and messaging windows for Yahoo! Messenger The contact list showsthe list of buddies and their presence status An IM session with one or more buddies can be launchedfrom the contact list The chat window shows message exchange between two buddies New messagescan be entered in the lower part of the window

11.3 Design Considerations

Before describing specific systems, this section first reviews the basic functional elements of an IMPsystem Some of the key systems design issues are then described Finally, the basic end-to-end systemarchitecture choices are discussed

11.3.1 Basic Functional Elements

There are six functional elements:

(1) addressing and identification;

(2) address books and contact lists;

(3) messaging and content encoding;