(void)

CPIM IP IMS MMS OMA SIMPLE SIP SMS

In today's world there are many different types of messaging services available both in the wired and wireless worlds. Some services are supported in both, others are only found in one. For example, SMS has been designed for a wireless environment, whereas Instant Messaging has been designed for a wired environment. The expectations of these services also differ in that some services are designed to be used in what is perceived as 'real time' and others are designed as a 'mailbox' service where the message is stored ready for collection or delivery at a later date. This clause investigates current messaging services and examines the expectations and differences between them. In summary this clause highlights the important fact that services where the message is delivery in what is perceived as real time by the user, are currently only being offered within the wired world, whereas all standardized services within the wireless world can be classed as non-real time. Introducing what is perceived as real time services into the wireless world brings many challenges not currently experienced in the wired environment. For example bandwidth, limited footprint/memory in the terminal, charging and billing. It is therefore important to consider the issues and impacts that surround these types of services when deploying in a wireless world. The messaging services covered in this clause are as follows:

The SMS messaging service allows a message to be created on a mobile device irrespective of whether the device is connected to a network or not. Once connected to an appropriate network, the user can send the message to the originators home SMSC, where it is stored until it is possible for the SMSC to deliver the message to the recipient. (please note that it is technically possible to send the message to any SMSC). Because of the short delivery times sometimes experienced by users of the SMS service, it could be perceived as being a real time service. However, 'real time' delivery cannot be guaranteed due to the fact that there is no communications association between the originator and the recipient, only the originator and the SMSC, and therefore the SMS service should not be considered as a 'real time' service.

SMS has been very successful messaging service within in the second-generation GSM system. In the third generation mobile system it is envisaged that the Multimedia Messaging Service, MMS, shall succeed this easy to use, non real-time text transmission service. The MMS will allow users to send and receive messages exploiting the whole array of media types available today e.g. text, images, audio, video, while also making it possible to support new content types as they become popular. As with SMS, the MMS message is created using the application on the device. Again, the device does not have to be connected to a network in order to create a message. Once connected to the network the message can be sent from the device to the originators MMS server, again similar to the SMS implementation. This can be classed as the originating process. However, the MMS delivery process differs to that of the SMS in that instead of sending the message directly to the recipient, the MMS server forwards the message to the recipient's MMS mailbox. Depending on the architecture, the recipient may be notified that a new MMS message has arrived in their inbox from which the recipient can then connect to their mailbox to retrieve the message or have the message pushed to them. Unlike SMS where there is a degree of expectancy of a 'real time' service, users may perceive that the service is non real time. Neither the originator nor the recipient perceives that the message will be delivered in real time, more of a service where a message can be deposited and retrieved at the recipients will.

Instant Messaging is becoming popular within the Internet world although interoperability between services is not widely available. The popularity is party due to the attraction of users being able to converse with one another without the need for voice. There are many scenarios where this is an advantage for example noisy areas such as the pit lanes used in F1 motor racing. The expectation of the service from a users viewpoint is to be able to communicate with other users in real time. Therefore the service relies on a communications association between the originator and the recipient in order to meet this expectation. The service is primarily text based, although most services allow for various attachments to be added; however the delivery expectation of the attachment is not consider to be real time. Most applications include access to a 'Presence' service to allow users to see who is available for Instant Messaging, however this is not mandatory. If the recipient is not available then most Instant Messaging services allow for the storage of a message until the recipient becomes available, acting in a very similar manner to that of SMS. In terms of the originating and delivery process there is a requirement to provide what is perceived as a real time connection between the two parties for the basic transfer of messages between the parties, however for attachments the perception is that these will be delivered in a background mode.

Chat has established itself within the Internet environment as a popular service. The service enables people to send text to a central point (chat server) allowing all of those users who are connected to the central point to view the text. Interoperability between 'Chat' rooms is not seen to be necessary within the Internet world as all users have the capability (if not the authorisation) to join the same chat room. However, Chat may evolve into a messaging service that requires 'Chat' rooms to interoperate, but for the foreseeable future this is not a requirement. Chat rooms can be divided into two categories, Private and Public, each providing a very similar service but different in the authorisation of use. The Chat services of today are primarily text based, allowing messages to be sent to all those within the chat room or to selected users. Likewise attachments can be sent but as with the Instant Message service the expected delivery of these is not considered to be 'real time'. In terms of the originating and delivery process there is a requirement to provide what is perceived as a real time connection between the originator and the recipients.

Email is used everyday and can be viewed as probably the most popular method of messaging currently available. The architecture for email is well known and established, with protocols that allow interoperability between various email systems. Email is very similar to that of MMS described earlier in that it is a non-real time service where the originator does not rely on the fact the recipient of the message is on-line using the system. The messaging service allows a user to deposit a message in the mailbox of the recipient to be collected/read by the recipient at an appropriate time. In terms of the originating and delivery process there is no requirements for a real time connection. Neither the originator nor the recipient perceives that the message will be delivered in real time.

As 3GPP has developed the concept of IMS it is thought useful to consider how a SIP based IP network can be utilised to provide messaging capabilities. One of the chief characteristics of SIP is its ability to rapidly and efficiently create real-time sessions between groups of users. It therefore appears that SIP based messaging would be a potential candidate to provide the equivalent of "Chat Room" and "Instant Messaging" (IM) type services found on the Internet today. Typical characteristics instant messaging are instant delivery of the messages to the targeted recipient(s) and interaction with presence information where users are able to see who is on-line as well as their status. A chat room is a "place" where multiple persons can join, follow and contribute to the ongoing discussion and leave the "room" at any time. Chat rooms are more permanent in nature when compared to IM exchanges and may be created by users or service providers. Additionally, chat rooms can be further divided to the private and public chat rooms. Normally, users who are participating in chat room will receive all the messages that are sent by the other participants. Similarly, the users are also able to send private messages to the chat room or even privately to some participant. Unfortunately, the most popular internet based instant messaging services are usually based upon closed and proprietary protocols which has made it impossible for different service providers to allow interoperable messaging between their respective users. Additionally, internet based services do not take into consideration the wireless environment and the needs of operators to provide services that are commercially viable by for example, providing support for charging. This report will further elaborate the essential messaging characteristic of these services and state how they may be enhanced, e.g. operators may be able to create and then advertise chat rooms containing specific content where users who join the room may be charged an 'entrance' fee,

Because of the emergence of Presence and Instant Messaging as a powerful new medium of communications over the Internet using independent, non-standard and non-interoperable protocols developed by various vendors, the IETF set the goal in the late 1990s to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. For this purpose a new IETF working group IMPP, (Instant Messaging and Presence Protocol) was created to perform this work. In 2000 RFC 2779 was created which defines a minimal set of requirements that an Instant Messaging and Presence Protocol must meet. In RFC 2778 a model of a presence and instant messaging system was also created. Following the creation of RFC 2778 and RFC 2779 the IETF set about determining the appropriate protocol mechanisms to fulfil these requirements and functional model. Some proposals were based on SMTP the protocol used by email and MMS. However the conclusion of this discussion was that SMTP and email protocols while be ideal for store and forward type of messaging that is email were not appropriate candidates for extending to me the real time delivery and conversational style requirements for Instant Messaging and Chat. The proposal that attracted the most support was to base the presence and messaging protocol on the protocol and mechanisms defined in RFC 3261, SIP. A new IETF working group, SIMPLE, (SIP for Instant Messaging and Presence Leveraged Extensions) was created to perform the work on the protocol for Presence and Instant messaging. The output of this group has been a number of Internet drafts including draft-ietf-sip-message [5] which defines a new SIP method the MESSAGE method which is designed to deliver instant messages for instant messaging and chat applications. This is currently in IESG last call and is about to become approved and published as an RFC. Work in IETF on SIMPLE is continuing including using content indirection for delivery of very large message content MSN Messenger is already has support for SIP and AOL has announced that they will support SIMPLE for interoperability with other external Instant Messaging and Presence applications. These two Internet messaging systems together service a large majority of the current Internet messaging users and systems. SIMPLE being based on SIP will easily operate using the existing 3GPP IMS or can be implemented using just the 3GPP PS domain using GSM or UMTS access. SIMPLE is also compatible and easily integrated with the 3GPP Presence Service, which is based on the SIMPLE model and protocols. 3GPP IMS already supports the SIP MESSAGE method. SIMPLE meets the requirements outlined in this report for real time immediate messaging and work is proceeding in IETF on extending SIMPLE for session based messaging. SIMPLE is also meets most of the requirements for deferred messaging however it does not currently support email addressing and the work on content indirection is ongoing. SIMPLE is of course compatible with CIPM and SIMPLE based Instant messaging and Presence systems

The Wireless Village Forum that is now part of the Open Mobile Alliance (OMA) has also been working on Presence and Instant Messaging for wireless and the result of this work has been Wireless Village 1.0. However unlike CPIM and SIMPLE Wireless Village 1.0 only addresses Instant Messaging within the Wireless space and does not address the issue of seamless interoperation with other Internet based Instant messaging services. Wireless Village 1.0 is based on WAP and HTTP mechanisms and as such can operate in either the 3GPP CS or PS domain using GSM or UMTS access. Wireless Village is now starting work on Wireless Village 2.0. The work on 2.0 is not particularly well advanced but there are proposals within OMA that 2.0 should be based on CPIM and SIMPLE. Wireless village is currently not compatible with CIPM and SIMPLE based Instant messaging and Presence systems including the 3GPP Presence Service or with 3GPP IMS addressing and routing mechanisms.

GSM and 3GPP has had a long experience with working with messaging. SMS was part of the original GSM standard and its use has greatly exceeded all expectations experiencing a growth comparable with that of instant messaging in the Internet. SMS has recently been enhanced to support graphics and small pictures and now a new standard has been developed MMS for delivering multimedia messages such as colour pictures. MMS is store and forward type messaging similar to email and can use email addresses where as SIMPLE does not. MMS is based on the IETF email protocol SMTP. MMS meets most of the requirements outlined in this report for deferred messaging however it does not meet the requirements for real time immediate messaging or session based messaging. MMS also requires some work to make it suitable to for the current 3GPP IMS such as support for SIP URLs and compatibility with IMS signalling routing mechanisms. MMS inter-works well with email systems but is not compatible with CIPM and SIMPLE based instant messaging and Presence systems including the 3GPP Presence Service.

Messaging can be divided to two different main classes based on the expectation of the sender. The sender either expects the message to be delivered immediately or he does not care so much whether the message is delivered immediately or later. In the latter (deferred delivery messaging) case, the sender assumes that message will be delivered to the recipient and network utilize store-and-forward capabilities to provide higher probability of reliable delivery or to support delivery time definitions set by the sender. The immediate case can be further divided to two different sub-classes based on the actions required form the user before he can encage to communication. The user can both send and receive messages without any prior actions or he may be required to join to a messaging session before the message exchange can take place. The messaging types considered in this report are

• Immediate messaging: The sender expects immediate message delivery in (near) real time fashion.
• Deferred delivery messaging: The sender expects the network to deliver the message as soon as the recipient becomes available.
• Session based messaging: The sender(s) and the receiver(s) have to join to a messaging session e.g. chat room, before message exchange can take place.

NOTE: Use cases are not exhaustive, variations are possible

It is vital that the interface between messaging systems should be standardised in order to allow messages to be transported between PLMNs, and to be correctly rendered both by different terminals types and devices from different manufacturers. Figure 2 below illustrates the scope of this report and how messaging service residing in the IMS should interact with 2G networks and the Internet. It is envisaged that IMS messaging will be a way to allow messaging between a varieties of different network types. For example, it should be possible for PLMN B to create a chat room that can be accessed via users of other 3G PLMNs, 2G PLMNs and on the Internet. However, unlike many messaging systems found on the Internet, the interface between PLMNs should allow for a complete set of features to allow the controlled exchange of important messaging related information such as presence and charging data.

In order to achieve the required level of interoperability the following should be considered:

1. content formats;
2. content adaptation;
3. transport protocols;
4. user addressing formats; and
5. interworking functions.

In today's world there are many different types of messaging services available both in the wired and wireless worlds. Some services are supported in both, others are only found in one. Each service has it's own individual characteristics, however in general messaging services are made of messages that require immediate delivery, and messages that do not require immediate delivery. This clause examines the architectural issues surrounding the delivery of these types of messages by looking at the current messaging services as mentioned in the 'Background' section.

Although the expectation of the user has moved towards the SMS service appearing to be real time, the fact of the matter remains that the SMS service is not a real time service since there is no communications association between the originator and the recipient. Therefore the message type that is used in this service is classed as 'Non-Immediate Messages'. However, the fact that the message is classed as 'Non-Immediate' does not preclude the fact that the delivery of the message may still appear to be 'real time' to the user. From an architectural viewpoint the question is raised as to whether or not developments to the IMS are required in order to support this service.

With MMS there is no expectation from the user for the message to be delivered in 'real time'. Currently the expectation is similar to that of e-mail where the originator sends to message to a mailbox. Therefore, since there is no communications association between the originator and the recipient the messages can be classed as 'Non-Immediate Messages'. As with the SMS service this does not preclude the fact that the message could be delivered in what appears to be 'real time'. As with SMS, the question has to be raised as to whether or not there are requirements to develop the IMS to be able to meet these requirements.

When using the Instant Message service, the user's expectation is that the communication between themselves and the recipient is 'real time'. To meet this expectation it is important to have a communication association between the originator and the recipient. The following are two examples of how this could be achieved: Scenario 1: In this scenario, an IMS session is set-up between the originator and the recipient. Each terminal has an Instant Message application capable of creating messages in a standardised way to ensure interoperability with other terminals that also have the same ability. Although this scenario provides a simple solution, implementation of the service remains complicated and restrictive. For example, the service is being provided via the terminal, and not being provided by the operator. How will the operator charge for the service? Is the implementation efficient in providing such a service? This would also mean that every service that makes use of 'Immediate Type' messaging would require the application to be built in or be able to download to the terminal as necessary. Because of these issues it is suggested that this type of solution is not considered for deploying services that utilise 'Instant Messaging' types. Scenario 2: In this scenario it is assumed that the Instant message can be conveyed over the IMS signalling path, this would require further study as to the maximum size of the message that can be transferred to enable the operator to provide a service that is perceived as real time. It is noted that on some occasions users transfer attachments between each other, however the user's expectation is that these are not delivered in 'real time'. Therefore, attachments would not be considered as messages carried IMS signalling path. Instead it is suggested that a separate context is established for the transfer of such a file. Using this scenario has a distinct advantage over the use of MMS in the case where the user is roaming. This is discussed as follows: Consider the following scenario where User A, who is a UK registered user roaming in France is holding an Instant Messaging session with User B, who is a French registered user roaming in the UK. In this scenario where User A sends User B a message irrespective of the solution used, IMS or MMS, the message trombones across the operator's roaming boarders three times. However the key difference is that within an IMS solution there is a communication association between the originator and the recipient, where as with the MMS solution the association is between the originator and the MMS server. Now consider the scenario where during the message session User A wants to send User B a photo which is in the region of 500K. In the case of the MMS deployment, the 500K file is sent from User A to MMS Server of User A positioned in the UK. From there the 500K file is forwarded to the MMS server of User B in France. The 500K file is then sent to or retrieved by User B in France. As can be seen the trombone effect is now a serious problem in terms of efficiency and cost. If this scenario is now compared to the scenario where a separate session is created to transfer the attachment it can be seen that the 500K file only crosses the operator roaming boundary once. Clearly, a far more efficient solution. Further study is required into the charging and billing issues but from early investigation this solution does provide the operator with various options.

The Chat service as noted in the previous section, is very similar to that of Instant Message type services where the expectation of the user is that an originated message reaches the recipients in what is perceived as 'real time'. Therefore it is important that there is a communication association between the originator and the recipients. The main difference between the Chat Service and the Instant Message service is that in general Instant Messaging is between two users, whereas chat is normally between a group of people. However it is the fact that the user's expectation is 'real time' leads to the question as to whether or not an IMS signalling path could not be used. As mentioned earlier Chat rooms can be split into two categories, Public and Private. However the deployment is very similar in both cases An IMS signalling path may be used to carry the message to the Chat Server which distributes the message in a similar way to that of Instant Messaging. As with Instant Messaging, a majority of the message are short bursts of text, however it is important to consider attachments and how they will be dealt with. This is for further study.

This is similar to that of the MMS architecture. Email is not classed as real-time and therefore there is no requirement for the IMS to establish a real time connection between the device and the email server, irrespective of the email service provider.