Tech-invite3GPPspaceIETF RFCsSIP
Top   in Index   Prev   Next

TR 22.940
IMS Messaging

V17.0.0 (PDF)  2022/03  21 p.
V16.0.0  2020/06  21 p.
V15.0.0  2018/06  21 p.
V14.0.0  2017/03  22 p.
V13.0.0  2016/01  21 p.
V12.0.0  2014/10  21 p.
V11.0.0  2012/09  21 p.
V10.0.0  2011/04  21 p.
V9.0.0  2009/12  21 p.
V8.0.0  2009/01  21 p.
V7.0.0  2006/01  21 p.
V6.0.0  2002/12  21 p.
Miss Miettinen, Natalia

Content for  TR 22.940  Word version:  17.0.0

Here   Top


0  Introductionp. 5

This Technical Report identifies the issues and needs surrounding messaging solutions related to the 3GPP IP Multimedia Subsystem (IMS).
The report is designed to identify essential messaging requirements, taking into consideration use cases that illustrate the needs of both service providers and users.
The report also highlights and contrasts the messaging capabilities of the 3GPP Multimedia Messaging Service and how these messaging capabilities might relate to or interact with the messaging services running in IMS.
An evaluation of various messaging solutions and technologies is provided together with an analysis on how they relate to the identified requirements. Finally, conclusions are drawn on the possible actions 3GPP may wish to take in regards to potential future work.
To encourage rapid end-user adoption and to protect existing operator investments, IMS Messaging is an evolution and enhancement of the current 3GPP multimedia messaging user experience.
IMS messaging mechanisms should re-use industry wide specifications as far as possible and propose extensions as necessary.
It is a goal of IMS Messaging to leverage the popularity of existing messaging services by supporting end-user friendly interfaces and features, flexible service offerings and to adopt and support existing pre and post-paid billing models.

1  Scopep. 6

The objective of this Technical Report is to:
  1. Describe use cases that illustrate the service requirements for IMS messaging.
  2. Derive the broad 3GPP requirements for IMS messaging services.
  3. Investigate the possible requirements for interworking with networks outside the 3GPP domain
  4. Develop an analysis of the possible interaction between IMS messaging services and existing 3GPP messaging services (SMS, EMS and MMS) as well as other relevant 3GPP services such as presence IMS group management and so on.
  5. Identify possible routes to standardization by:
    1. Adopting existing and emerging standards, e.g. OMA, IETF.
    2. Modifying and enhancing existing and emerging standards.
    3. Developing of new standards.

2  Referencesp. 6

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
TS 22.141: 3rd Generation Partnership Project; Technical Specification Group Services and Systems Aspects; Presence Service, Stage 1
RFC 2779:  "Instant Messaging / Presence Protocol Requirements"
RFC 2778:  "A Model for Presence and Instant Messaging"
RFC 3261:  "SIP: Session Initiation Protocol"
draft-ietf-sip-message-07.txt  "Session Initiation Protocol Extension for Instant Messaging" September 2002.
TS 22.140: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Stage 1, Multimedia messaging service
TS 22.250: 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Stage 1, IMS Group Management

3  Definitions, symbols and abbreviationsp. 7

3.1  Definitionsp. 7


3.2  Abbreviationsp. 7

Internet Protocol
IP Multimedia Subsystem
Multimedia Messaging Service
Open Mobile Allicance
SIP for Instant Messaging and Presence Leveraged Extensions
Session Initiation Protocol
Short Message Service

4  Messaging servicesp. 7

4.1  Backgroundp. 7

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:

4.2  SMSp. 7

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.

4.3  MMSp. 7

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.

4.4  Instant Messagingp. 7

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.

4.5  Chatp. 7

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.

4.6  Emailp. 7

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.

4.7  Messaging in the IMSp. 7

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,
Copy of original 3GPP image for 3GPP TS 22.940, Fig. 1: Example IMS messaging service: Chat room
Figure 1: Example IMS messaging service: Chat room
(⇒ copy of original 3GPP image)

5  Current messaging standardisation summaryp. 7

5.1  CPIM and SIMPLE work in IETFp. 7

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

5.2  Wireless Village and OMA messaging workp. 7

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.

5.3  3GPP work on existing messaging standardsp. 7

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.

6  IMS Messagingp. 7

6.1  Messaging typesp. 7

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.

6.2  Use Casesp. 7

NOTE: Use cases are not exhaustive, variations are possible

6.2.1  Instant Messaging with immediate deliveryp. 7

The user, "Harry" can see from his buddy list that "Jane" is ready to receive messages. Harry wants to send a immediate message to Jane to see if she would like to met up for coffee
Harry sends a message to Jane and she replies, suggesting that they meet in five minutes at a particular coffee bar.
The above scenario shows a successful message transfer between Harry (the sender) and Jane (the recipient). Considerations should be taken when the delivery of the massage can not take place, which could be a network issue (e.g. due to loss over coverage) or a user choice (e.g. changes to the profile). The application may then inform Harry that the deliver of the message to Jane has been unsuccessful.

6.2.2  Instant Messaging With "Delivery at a later date"p. 7

This is a similar scenario as for simple instant messaging above in that the user Harry can see from the Buddy list that Jane is unable to receive messages, however Harry decides to send an immediate message t o Jane anyway.
Harry sends a message to Jane. The system determines that Jane is unable/unwilling to receive the message and indicates to Harry that the message will be delivered at a later date or deleted
Harry may chose an alternative messaging service to achieve this.

6.2.3  Sending a document during an instant message exchange.p. 7

Harry sees a model car that he thinks is the one that Jane has been looking for. He sees that she is available, but in a meeting. He wants to know if this is the right model before he buys it.
Harry sends Jane a message and a photo of the model car. Jane responds with a text message and has not interrupted her meeting.
The mechanism used to send the photo does not affect the expectation of the user during the instant message exchange.

6.2.4  Delivery of documents at a later datep. 7

Harry and Jane are chatting about a problem that they are both working on. Harry realises that he has a useful document for Jane to read at a later date. Jane is unable to receive the document now, but wants to collect it from her mailbox at a later date. This is equivalent to someone saying "I'll e-mail you that document in a minute" when they are having a voice conversation.
Harry sends Jane a message "I'll send you a copy of the report to your e-mail so that you can receive it later". He then sends the document to her e-mail account.

6.2.5  Message Filteringp. 7

Harry has an instant message identity that is publicly available. His subscription with the service provider is such that he has a filter set that after a particular time (e.g. 1800) all messages are diverted to a mail box.
Instant messages sent to Harry are diverted to a mail box from which Harry can retrieve at a later date.
Harry may wish to be notified that an instant message has been delivered to his mail box.

6.2.6  Chat Roomp. 7

Harry and Jane are chatting about a problem that they are both working on. They realise that they need other colleagues to provide input to the problem.
Harry creates a messaging session and invites all the co-workers to participate in a discussion.

6.2.7  Sending a document during a chat room sessionp. 7

Harry , Jane and Peter are discussing a place to meet. Harry provides directions in the form of a map that he has available.
Harry sends a message to Jane and Peter with the attached map. The system determines that Jane is unable to accept the attached map due to for example a rejection by Jane's UE due to lack of memory.
The system determines that Jane is unable to accept the attached map due to for example a rejection by Jane's UE due to lack of memory. Jane wishes to retrieve the map at a later time e.g. after she's been able to make more memory available.

6.2.8  Location and Presence Enhanced Messagingp. 7

IMS Messaging Clients can utilize location and presence information from the IMS Core Network to enhance the messaging experience.
  • At 5 minutes before noon Mark decides he'd like to get together with friends for lunch.
    • Mark looks at the buddy list on his handset to see the status of his friends. After examining location, availability, who's online and who's busy, he chooses Sally.
    • Mark is offered a menu with options to call, IM, MM, or leave voicemail for Sally. Since Sally's status indicates that she's online, he chooses to send an immediate message inviting her to lunch at the Ritz. Sally accepts the invitation by sending a return IM.
  • Alternatively, Mark could choose initiate a group chat session, inviting as participants all friends in his buddy list, indicating that only those within a 5 mile radius should be included.
    • Once the chat session is established, Mark then invites the group to lunch, leading to a vigorous exchange of messages between the participants regarding which restaurant they will choose.

6.2.9  IMS Messaging Selects Appropriate Delivery Methodsp. 7

The IMS Messaging Service can select the appropriate message type depending on the status and preferences of the recipient, and upon the preferences of the sender.
  • Sally is flying to New York City. Jason is already in NYC. Sally's phone is offline.
    • Jason sends a message - it can not be delivered until Sally lands so the IMS Messaging Service automatically stores the messaging, waiting for Sally to be available. When Sally lands and turns on her phone the message is delivered to Sally. "Meet us at Joe's Restaurant".
    • Having seen Jason's message. Sally needs directions. She replies to Jason's message. She sends IM to Jason "Where's the Bar?". Jason is on home on his PC. The message routed to the IMS Messaging client running on the home PC. Jason replies with directions + Map from his home PC. Sally gets the message with the map and is on her way.
  • Alan carries a phone and a PDA. He sets a rule that multimedia messages (messages with attachments) be delivered to his PDA, but all text messages be delivered to his phone.
  • Vic has a pager, phone and a PC. For certain classes of important messages notification is sent to all devices. Vic can choose to pick up message from most relevant device.

6.2.10  IMS Messaging Service Provides Added Value to Messages Through Network Based Servicesp. 7

The IMS Messaging Service provides users a rich filtering mechanism that enables protection from unwanted messages and control over the messaging environment. IMS also enables service providers and end-users to save their messages for future reference.
  • Lisa sets up message filters that choose to only deliver messages from co-workers and those friends she's placed on her buddy list. All other messages are refused by the service.
  • Lionel is at work and IMs with Jason who mentions a URL. Later, at home, Lionel wants to retrieve and goes back to that IM thread to get the URL.
  • Mark joins group that is in progress. He wants to see the conversation thread from before he joined. Mark chooses to view the previous 25 minutes of the conversation to catch up on what is being discussed.

6.2.11  IMS Messaging Support for Value Added Service Providersp. 7

The IMS Messaging Service enables Value Added Service offerings. The Value Added Service Providers use user profile information in addition to presence and location to provide personalized service.
  • FAN Club Services (ie: Swarming) - Betsy is a member of a famous personality's spotters group chat based service.
  • Updates on location and photos of the action at those location are sent to the group as submitted by chat participants. Betsy only hears about these activities if she is within 5 miles.
  • Betsy is in central London and doesn't get messages about his activities at the football match on the outskirts of London (too far away).
  • Later - He appears at a trendy central London nightclub and Betsy is alerted and automatically placed into the chatroom. She swarms.

6.3  Interaction with other Featuresp. 7

6.3.1  MMSp. 7

Deferred messaging is already supported within 3GPP systems in the form of MMS. In some use cases the sender deliberately selects which messages should be deferred, or agrees to defer the message when the network is unable to deliver. In either case, a solution should be found that allows messaging within the IMS to interact with the MM S, so that Deferred messaging is supported by the existing capabilities of the MMS.
MMS supports the conversion of media when the sent format is not supported by the recipient's UE. This may be a useful feature in immediate ,messaging if the conversion can be done in "real time". The capability which detects the UE capabilities and converts the media should be a common capability for IMS messaging and MMS.

6.3.2  IMS Group Managementp. 7

Chat rooms support a group of users who are participating or can participate in a "chat session". IMS messaging should make use of the IMS Group Management TS 22.250 capability for the support of multiparty sessions.

6.3.3  Presencep. 7

IMS messaging should interact with the Presence capability being defined for 3GPP [1].

6.4  Messaging Interoperabilityp. 7

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.
Copy of original 3GPP image for 3GPP TS 22.940, Fig. 2: IMS messaging overview
Figure 2: IMS messaging overview
(⇒ copy of original 3GPP image)
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.

7  Deferred delivery messaging requirementsp. 7

Deferred delivery messaging requirements shall be able to provide the same functionality as specified in the MMS stage 1 TS 22.140. For the purposes of the requirements for IMS messaging in this report, the terminology "MMS" in TS 22.140 maps to "IMS messaging" and the terminology "MM" in TS 22.140 maps to "message".
In addition to the requirements stated in TS 22.140 it is required, that IMS addressing is supported i.e. it shall be possible to send multimedia messages to an IMS public identity of a subscriber.

8  Open Issuesp. 7

The purpose of the clause is to provide a list of open issues that were identified. These issues are:
  • Session based messaging may need new requirements to enable fetching message log e.g. after a loss of radio coverage
  • Use of e-mail addresses requires more consideration
  • Address translation/mapping requires more analysis

9  Conclusions and Recommendationp. 7

This technical report has analysed how messaging in the IMS can be provided in a way that is complementary to existing messaging capabilities available in 3GPP.
It has already been agreed in this report that requirements for deferred messaging match closely those of MMS however some enhancements may be required such as support for SIP URLs and IMS modifications to the signaling transport to align with the IMS. It is therefore recommended that an evolution of the current 3GPP MMS specifications is considered as a basis for IMS deferred messaging.
CPIM and SIMPLE meets most of the requirements for Immediate messaging and work is ongoing regarding Session based messaging within SIMPLE and has the advantage of interoperating with external instant messaging systems and compatibility with IMS and the 3GPP Presence Service. It is therefore recommended that an evolution of the SIMPLE work is considered as a basis for Immediate and Session based messaging. The IETF is still open to taking on board additional 3GPP requirements for SIMPLE and that the best way forward for meeting the additional requirements for Immediate Messaging and Session based messaging is through influencing IETF SIMPLE work.
This report also makes the following recommendations :
  • The filtering of SPAM and offensive content etc although an important issue that was of interest to a number of parties, is outside the scope of this report as an application/service issue
  • IMS messaging should make use of the IMS Group Management capability for the support of multiparty sessions.
  • All the messaging types are seen as equally important from the SA1 point of view.

A  Architecture considerationsp. 7

A.1  Introductionp. 7

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.

A.2  SMSp. 7

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.

A.3  MMSp. 7

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.

A.4  Instant Messagingp. 7

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.

A.5  Chatp. 7

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.

A.6  Emailp. 7

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.

$  Change historyp. 7

Up   Top