Wednesday, February 20, 2008

3GPP Multimedia Telephony & OMA CPM

In this post, I will address two standardization initiatives that try to define the future of communication services based on IMS, and more especially the support of Multimedia Communication.

As you will see, I have a soft spot for one of them (OMA Converged IP Messaging) and a strong bias against the other (3GPP Multimedia Telephony).

3GPP Multimedia Telephony

3GPP Multimedia Telephony (MMTel for short) has appeared in 3GPP release 7 and will evolve in the next releases. The initiative originates from ETSI TISPAN requirements for fixed networks.

The name always made me mad, but it is actually very telling about what MMTel is today.

The service is "multimedia" in the sense that it permits the combination and dynamic re-negotiation of different media components within an IMS session. Sample components include full duplex voice, real time video, text communication, file transfer (e.g. video clip, audio clip, pictures). Note that there is no explicit mention of applications, and the 3GPP requirements state that a "typical usage" is speech (voice) and speech combined with other media components.

On the other hand, this is a "telephony" service, which seems to anchor its definition to the well-known, decades-old, voice-centric, and circuit-switched implemented telephony service. Basically, you could infer that Multimedia Telephony is an incremental evolution of Voice Telephony with the addition of new media components.

This may lead to potential questions when specifying Multimedia Telephony:
- Is the service only related to person-to-person communication or can it apply to person-to-service interactions? I already showed an example of how a multimedia SIP session can be used in a person-to-service relationship, and you will see below that CPM supports it.
- Are current classical telephony supplementary services applicable in a new world where a session can be established with a service, where SIP URIs will eventually replace telephone numbers, where the protocol and the core network permit to reach the user on a multiplicity of devices, where enablers like group management and presence can change the users' behaviors to communication (e.g. is the user available for voice communication now? What are the alternatives?) as well as the way network-based call handling services can be implemented (using presence to take an informed decision), where users can negotiate the content of a session when establishing it, and where services can easily redirect users to web pages to allow them to decide how a call should be handled?

These questions are not purely theoretical when you consider the current standardization state of MMTel: it solely consists of the specification of how classical telephony services like Original Identification Presentation, Call Forwarding Unconditional or Communication Waiting can be implemented in IMS. The requirements specification clearly states that the behavior of each service, "as perceived by the user, should be consistent with the behavior perceived when using the equivalent services on PSTN/ISDN and CS Mobile networks." Isn't this crystal clear?

As such, at the moment MMTel looks like a vehicle to standardize voice-centric telephony services to be supported by a Telephony Application Server (TAS), which may eventually become a Multimedia Telephony Server when voice is not the only media component supported by a call.

The MMTel initiative can be associated to another 3GPP one called IMS Centralized Services (ICS) which aims at having an IMS-based TAS for both CS telephony and IMS telephony. The approach would eventually deprecate existing IN servers in legacy networks and see them replaced by a TAS. Put together, both initiatives draw the following potential roadmap:
1) A TAS for IMS voice telephony
2) A TAS for both CS and IMS based voice telephony
3) A TAS to support IMS-based Multimedia Telephony
Basically, a TAS at the center of the future telecommunications network.

I personally do not believe at all in this incremental approach to Multimedia Communication, as SIP and IMS will drastically change the way people communicate, leaving plain old telephony as a separate service whose usage will gradually decline as people will adopt a totally new way to communicate. A TAS should therefore be seen as an important box in an IMS network, but a box that will remain focused and essentially unchanged until its termination.

True Multimedia Communication is to be supported by something else, and this is...OMA CPM.

OMA Converged IP Messaging (CPM)

OMA Converged IP Messaging is currently under specification within OMA (the Open Mobile Alliance). In my opinion, this is by far to date the most significant step towards an optimal exploitation of IMS capabilities that I described in the past.

The name of this enabler may be misleading, as it seems to imply that CPM is a pure messaging service, while it is not.

Actually, CPM can be defined as a composite specification addressing two concerns:
- Full IMS messaging (OMA SIMPLE IM), including page mode and session-based approaches, as well as transparent interworking with legacy mobile messaging services (SMS, MMS, OMA IMPS). This could certainly be extended to other messaging services like email or Jabber/XMPP in either future versions of the specification or in smart implementations.
- Multimedia communication as I had the opportunity to describe it in the past.

Let's start with the messaging features.

Page mode messaging, which is based on the SIP method MESSAGE can be seen as the equivalent to SMS in the SIP/IMS world. A user can send a page mode short message to another user or a group of users. This message is either delivered instantly over the IMS core network or stored for deferred delivery if the recipient is not available.

Session-based messaging is based on a SIP session, with messages delivered through a protocol called MSRP. Session-based messaging essentially serves two requirements that cannot be fulfilled by page mode messaging: the support of chats, in which messages are exchanged between two or more parties within a dialog context; the possibility to send large volume files like music or video clips. In addition, session-based messaging has two important benefits: it minimizes SIP control traffic to session management, and utilizes a specific protocol for the messages itself, permitting to implement an appropriate support in the network; by reusing the concept of SIP session, it permits messaging to be one component among others in a multimedia session.

Interworking with legacy messaging services like SMS and MMS permits CPM to be interesting from the start, as it does not rely only on the initially limited IMS community to deliver its services.

The scope of multimedia communication supported by CPM is very broad.

CPM will support a wide range of discreet (e.g. messaging, files, applications) and continuous (e.g. full duplex voice, video) components. It supports the negotiation of initial components in a session, dynamic renegotiation of components in the session, and does not require any specific component to be part of the session (for instance, it is not mandatory to have a messaging component despite the name of the service). The session can be both person-to-person (2-party or multiparty) or person-to-service (and obviously person-to-person&service).

CPM supports a multi-device approach, making use of SIP convergence capabilities. It permits a user to share an identity between several devices and to use several identities per device. A user may have its CPM session shared between several of its devices on a media per media basis (e.g. video sharing on TV and voice on mobile). Session mobility between devices is also supported (e.g. ongoing session transferred from TV to mobile). The user can also define preferences on how CPM should address communication according to its devices (e.g. IMs should be sent only to mobile).

In summary, CPM supports both of the three axes I defined for an optimal exploitation of IMS capabilities: multimedia communication and user oriented convergence.

CPM supports conferencing through a variety of means supported by SIP and already used in services like PoC or IMS Messaging: sessions to ad-hoc groups (a user sends an INVITE to a group explicitly defined in the INVITE), to pre-defined groups (the INVITE is sent to a PSI identifying a group whose definition is stored in the network), and by adding participants to a session on the fly.

Interworking with non-CPM communication means is not limited to messaging. It also includes interworking with non-IMS voice, such as circuit-switched voice. This will be done by reusing current IMS/CS interworking components.

In addition, CPM supports a converged address book, converged in the sense that it is aimed at being shared by all the devices owned by the user. It also has an archiving functionality, able to store such things as messages, media objects and session histories. It interacts with presence in order to publish or access presence information for a user. CPM will also support web services towards application willing to use its services. An interesting feature is the possibility for users not to divulge their identity when using CPM, by using a nickname for instance.

The CPM architecture is quite straightforward:
- A CPM Client in the device supports CPM from a user perspective.
- A Converged Address Book component supports the address book for multiple devices.
- A Message and Media Storage component archives everything that needs to be archived.
- An Interworking Function supports interworking with non-CPM messaging solutions (voice interworking is supported through the IMS core network).
- A CPM User Prefs component interfaces with the user for CPM customization.
- The CPM Conversation Server supports multimedia sessions, and should in implementations look very similar to what I described here. Like PoC and IMS Messaging, it will be subdivided in a Participating Function dedicated to a specific user in the session (called Personal Multimedia Controller in my post on the subject) and a Controlling Function component supporting features shared by multiple users like conferencing (I called it Multimedia Focus in the same post). These SIP centric components will control media intermediaries for individual components in the multimedia session (I called them Media Mixers). Note that the specification does not mandate network intermediaries for every component, as it allows peer-to-peer media flows between devices when the operator's policies permit it.

Building block standardization approaches

Both specifications can claim (and actually do) a building block approach to standardization. However, there are significant differences between them.

CPM's approach is IMS-centric, as it intends to reuse IMS enablers like the interworking with the circuit-switched network for voice, presence, group management and to make generic and extend architecture patterns that were introduced with the specification of Push To Talk over Cellular and later reused for IMS Messaging (OMA SIMPLE IM).

On the other hand, Multimedia Telephony's approach is pre-IMS centric. The goal is to create within IMS building blocks which mimic pre-IMS voice-centric telephony, with the hope (illusion?) that a multimedia communication experience can be created through the reuse of these basic building blocks that totally ignore the capabilities of IMS.

The reader can make its own opinion on the advantages and drawbacks of both approaches.

For my part, if I was an operator, I would be very suspicious about suppliers coming with a story of a Multimedia Telephony server defined as an extension of a short-term Telephony Application Server, and would ask them about the positioning of this product with regards to CPM.

On the other hand, I would mandate from the potential suppliers of IMS Messaging products to provide a CPM-ready solution with a clear roadmap. Considering that IMS Messaging is a brand new IMS specification, it may be a big mistake to purchase in 2008 or 2009 a solution that has no clear path towards the next big thing: CPM.

Links to publicly available specifications:
OMA CPM: nothing as this is work in progress
Multimedia Telephony Requirements: TS 22.173
Multimedia Telephony Architecture: section 4.16 in TS 23.228 (the AS for Multimedia Telephony is unambiguously called TAS)
Multimedia Telephony Protocol Details: TS 24.173
Architecture for IMS Centralized Services: TS 23.292



Antoine said...

Hello Christophe,

Thanks for your blog first, even if I had the occasion to write you this. I have two questions for you :
1/ How is CPM related to what has been annonced by Ericsson (MCS) or by Orange, Telefonica et al. (the Rich Communication Services initiative) ? These different actors announced something really similar to what you described as the promises of CPM (converged address book...).
2/ What will it bring beyond the functionnalities of different ASes (IM, Presence, RLS) and related XDMSes ?
I would really like to get your views on that.

Christophe Gourraud said...

Hi Antoine,


From the description in the press release, the Rich Communication Suite looks like the packaging of pre-CPM 3GPP and OMA services.

The "Enhanced Phonebook" is the enrichment of the phone book with presence information. The CPM converged address book will certainly be the same thing, or an extension of it.

Enhanced Messaging is likely to be OMA SIMPLE IM (that I called "IMS Messaging" - the 3GPP term - in my post). It is based on both SIP MESSAGE and SIP session based messaging and supports three types of IM:
- Pager Mode IM (short text messages based on SIP MESSAGE)
- Large Message Mode IM (pager message with attachments implemented through SIP session based messaging)
- IM sessions/chats between two or more parties

This could also include what has been standardized by 3GPP as "SMS over generic IP access". This includes two things:
- The support of SMS over IP through the encapsulation of the SMS in the body of a SIP MESSAGE
- Service-level interworking between Pager Mode Messaging and SMS

CPM will include all of this.

Finally, enriched call has been standardized in 3GPP as "combining circuit switched and IMS services". It permits to combine a voice call performed over the CS network with additional content exchanged through the IMS. It also permits the interworking between a full IMS client (supporting both voice and the enrichment through IMS) and a client supporting voice over CS and enrichment over IMS.

Therefore, in summary, the Rich Communication Suite is a packaging of what can be done before CPM is there. CPM largely builds on these blocks, consolidates them, and extends them towards a real multimedia experience. RCS is still an addition of silo communication services (enhanced messaging and enriched voice), while CPM removes the silos and integrates everything together.


CPM clearly integrates with and reuses presence and RLS.

On the other hand, CPM is a functional superset of OMA SIMPLE IM.

There are therefore two possibilities:
- The operator deploys an OMA SIMPLE IM solution that can evolve and be part of CPM. This is perfect.
- The operator deploys an ill-architectured OMA SIMPLE IM solution that cannot easily evolve into CPM. Migration might be more costly.

This is what I tried to explain at the end of my post.


Aayush said...

Hi Christophe,
talking of IMS services in general, our company is planning to deploy services on a standardized service delivery platform (JSLEE given in JSR 240).
I personally believe that such a platform will open great opportunities for deploying IMS SIP based services, as well as combining and chaining web based services with IMS apps to create a confluence of services. What do you think about JSLEE as a potential services plane for the IMS?

Christophe Gourraud said...

Hi Aayush,

I intend to dedicate a post on standard service platforms like JSLEE and J2EE in the future.

I have a good opinion on JSLEE, but I would tend to favor J2EE in the long run and for service innovation.

At the moment, I would say that JSLEE and J2EE are quite complementary, and integrating the two together might be a great combo for some time.

JSLEE is more telecom and network protocol centric, while J2EE is better for logic that mixes SIP with web pages, or IMS and web services.

JSLEE is certainly better adapted at the moment for classical telecom services with classical telecom requirements.

The developers community is and is likely to remain much more limited for JAIN SLEE than for J2EE.

JSLEE can be used in the legacy telecommunications network (including circuit switched IN) while J2EE has difficulties to integrate with non-IP protocols.

JSLEE might therefore be an optimal choice for operators who want to deploy voice services that are applicable to both CS and IMS.

The combination of JSLEE with J2EE would permit to use J2EE for integration with the advanced Internet and IT world, while JSLEE would take care of classical, carrier grade components of IMS services. Moreover, JSLEE would permit to complement J2EE with access to legacy telecom enablers like circuit-switched voice, access to the HLR, to SMS or location. Finally JSLEE could be used as a generic platform for protocol conversion, like SIP <-> XMPP/Jabber or SIP <-> Microsoft SIP.


Aayush said...

Thanks for the reply Christophe..there are 2 more points that caught my eye in this post..

1)"A user may have its CPM session shared between several of its devices on a media per media basis (e.g. video sharing on TV and voice on mobile)."

This is ok. A user may have a common IMPU shared by two IMPI' IMPI is being used for voice and the other for video.

2) "Session mobility between devices is also supported (e.g. ongoing session transferred from TV to mobile)"

This is AMAZING.This is something I have heard of..and I would definitely want to know more. How is one session transferred to the TV? By SIP REFER or something? Maybe the TV/Set-top-box also has an IMS client?

Christophe Gourraud said...

There is ongoing work in the IETF to address the issue of session mobility for SIP.

I am not sure if there is a reference work at the moment, but I found this draft that seems to be evolving over time:

Yes, I would assume that a solution would be to have an IMS client supporting session mobility in the set top box.


ann.c.tan said...

hi christophe,

would you know of any readily available technical specs of CPM? Something that describes page-mode and session-based instant messaging complete with Messaging flow (much like TS 24.228'S format).

Nightcrawl said...


After all these months, there is any update for the CPM specification status?

JaeSeung said...

I'm just a visitor.
But thanks for interesting post.
Regarding session mobility, 3GPP has recently standardized session continuity including device transfer.
Initially it was discussed in TR23.893 Feasibility study in Multimedia Session Continuity.
And now device transfer issue is being standardized in TR 23.838.

Hope this is helpful.

Jack Chrysler said...
This comment has been removed by the author.
Anonymous said...

I think, that you are not right. Write to me in PM, we will talk.

Paul said...

Hi Christophe
How is CPM different from RCS (the GSMA initiative)? said...

Thanks for this article, really useful piece of writing.

Anonymous said...

I am extremely impressed together with your writing talents and also with the layout for your weblog.
Is that this a paid subject matter or did you customize it yourself?

Either way stay up the nice high quality writing, it is rare to
see a great weblog like this one nowadays.

My webpage > firewood sheds

Anonymous said...

This post will help the internet users for creating new
blog or even a weblog from start to end.
Feel free to visit my web blog ; Photography Tricks

Anonymous said...

I blog often and I seriously thank you for your content.
This great article has really peaked my interest. I will bookmark your blog and keep checking for
new information about once a week. I subscribed to your Feed as well.
my site :: insurance

Anonymous said...

Definitely believe that that you stated. Your favourite reason appeared to be on the
net the simplest thing to be aware of. I say to you, I certainly get annoyed at the
same time as other people consider worries that they plainly don't understand about. You managed to hit the nail upon the top and also outlined out the entire thing without having side effect , people could take a signal. Will likely be again to get more. Thank you
Also visit my web site :: Pre-owned boats ecommerce specialist

Anonymous said...

You need to be a part of a contest for one
of the most useful websites on the web. I will recommend this website!

Stop by my weblog; calories walking

Anonymous said...

Outstanding post but I was wanting to know if you could write a litte more on this topic?
I'd be very grateful if you could elaborate a little bit further. Cheers!

Feel free to surf to my website: Xxx-Fuck.Net