For me, multimedia communication is one of the three axes around which IMS can revolution telecommunications.
Multimedia communication is a central capability of the SIP protocol as specified by the IETF. It permits to combine and dynamically add, remove or replace any type of communication components (e.g. messaging, voice, video) and application components (e.g. gaming, shared browsing, whiteboard) whithin the same SIP session.
Multimedia communication should not be mixed up with early IMS rich voice services, which aim at adding specific media components to a voice-centric session. There might be - sensitive telecom people please directly jump to the next sentence - multimedia sessions without a voice component from beginning to end. However, voice is likely to remain the privileged way to communicate for long, and therefore one of the main components in multimedia sessions.
In this post I will try to describe the current status of multimedia communication in both existing IMS implementations and in standardization.
Implementations: Devices Can Do It, Application Layer Cannot
In my first post on multimedia communication I identified 3 related challenges for the operator. The first one is to simply enable multimedia communication in an IMS network.
Multimedia session management is a natural peer to peer feature of SIP, and can therefore be easily supported by devices. In the mobile industry, most of the IMS client frameworks I have seen are able to support multimedia sessions.
The IMS core network is not an issue either, as it can support any type of session.
Problems concentrate in the application layer, as early IMS application and media servers are dedicated to the support of single medium sessions, with the medium being voice, video, voice bursts (push to talk over cellular), or messaging.
This implies that as soon as an application server is chained in the signaling path of an IMS session, it is likely that this session can only support a single medium. "Fortunately", current IMS clients are implemented to also support a single medium in a session.
Standardization Overview
ETSI TISPAN seems to essentially see IMS as a new telephony network over IP. In cooperation with 3GPP, the group has been pushing for the standardization of services that simply replicate existing circuit-switched services.
OMA (Open Mobile Alliance) is the main standardization body for IMS services/enablers. This is therefore the main responsible for the extreme silo-ization of early IMS services.
However, this is also from OMA that the light may come through the Converged IP Messaging (CPM) work item. Despite its name (is it to deceive enemies of multimedia communication?) CPM requirements cover the full scope of multimedia communication, both for 2-party and for multiparty sessions. CPM might be THE most important item under specification these days.
By having a look at the contributions for CPM over the past months I have the feeling that this item has been strongly pushed by operators, and that apart from a few exceptions major telco vendors' involvement has been lagging a little bit.
Requirements have been defined, architecture work has just started.
I hesitate to even mention it but 3GPP has an R7 work item called "Multimedia Telephony". For me the terms "multimedia" and "telephony" cannot be associated, as telephony is an old circuit-switched centric concept, and it does not make sense to consider that multimedia communication can be reduced to a telephony service in which voice is replaced by several media components. Not only multimedia communication deals with combining multiple media components in a single session, but it also will totally change the way to communicate, and this new communication paradigm will not be called "telephony".
This said, the name accurately reflects the content of specifications: it might be about multimedia, but it is definitely about telephony. The current multimedia telephony specifications simply define how such services as call waiting, call hold or call barring can be implemented in IMS.
Why is it so Hard?
As usual this is mainly about culture and organizations.
For instance, voice has always been voice and messaging has always been messaging. In legacy networks, these services have nothing in common. They are owned by different organizations within the vendor and operator companies. These organizations do not speak to each other and multimedia communication could even threaten their very existence as separate entities.
OMA is a standardization that used to specify only silo services before IMS services were pushed in by a few companies. The OMA organization is totally fragmented, and the OMA architecture group has never been an overall architecture group, such as WG SA2 is in 3GPP.
There might also be a business issue: as a supplier, is it more interesting to implement and sell, say, 5 silo services, or is it better to integrate all these services in a more coherent and compact architecture?
When is There a Real Risk to Miss the Multimedia Communication Bandwagon?
The first risk is when standardization or a supplier proposes to "enrich" a silo service with one or two more media components, e.g. messaging added to push to talk. An operator may end up having in its network a voice server also supporting messaging, next to a messaging server also supporting voice. Suppliers may be happy to upgrade their silo servers, but the losers will be the operator and the end-user.
Otherwise, if you consider early IMS services for communication...
Voice-centric telephony is not an issue. The service is so important that it will remain for years, more especially as long as the circuit-switched network exists. It therefore makes sense for an operator to deploy IMS for voice telephony. However, as the motivation is usually cost reduction, the operator may prefer to minimize the costs for the IMS telephony application servers and go for cheap black boxes that implement the most important telephony added value services (unless the operator already uses an open platform like JAIN SLEE for IN). Investments for more open platforms can be targeted at multimedia communication and other IMS advanced services.
Push to talk over cellular is not a successful enough service to be an issue.
The real risk for an operator to waste money is for IMS session-based messaging. This chat and instant messaging service is very important, and an investment in a silo implementation may not be future proof.
In a next post, I will address architecture aspects for supporting multimedia communications.
Christophe
Subscribe to:
Post Comments (Atom)
Stumble It!
4 comments:
Hi Christophe, very insightful blog - congrats. What I'd be interested in seeing is your thoughts on "IMS handsets". As we all know, the network has to be deployed, i.e. 3G, before the Nokia, SonyEricsson, Moto, Samsung, et al can move new handsets into the subscribers hands. However, IMS is a radically different beast. Yes, a 2G or 3G phone can "connect", but they won't benefit from an IMS UI, and yet I don't see 3GPP or any other group trying to standardize an IMS UI. Won't this be an issue when, if susbcriber A (say Joe) has a Nokia 3G phone and tries to use IMS services for a multimedia session with subscriber B (say Mary) who has a SonyEricsson IMS phone ... my worry is that unless there is a lot of smarts "in the network" some capabilities and functions just won't work; and we all know that a bad initial experience tends to have major negative effects ... we all remember ... W A P ;-)
Hi Gerry,
You highlight a fundamental issue for IMS in the mobile world. There have been activities to standardize APIs, like JSR 281, but this is just a small part of what is needed. There is a need for a standardized service framework in the client, that would permit to easily deploy and make co-exist IMS applications, hopefully in a plug and play manner. Then, on top, there are these user interface aspects that should not be underestimated, as it is essential to present services to users in an intuitive way. You can deploy as many services as you want, if they are not easily accessible they will fail.
This is a reason why I think PCs might be the initial devices where innovative IMS services can be introduced. Successful services in these devices could boost the required evolution of mobile handsets.
Christophe
Hi Cristophe,
You highlighted JSR 281, which, in theory could produce a standardized service framework; however a) JSR281 seems a liitle too POC/GLM focussed, b) JSR281 seems to be running late (I've only looked at their schedule versus what they've currently delivered) and c) its unclear (at least to me) how widely it will be adopted; in fact, I see the OMA Converged IP Messaging (CPM) as possibily being more applicable - and offer a wider "adoption" base? The plug & play "IMS service" deployment capability is again a key feature/function - what I'd like some Standards Body to pick up on is IMS Service Compatibility testing, to ensure IMS_Service_C doesn't stomp over already installed IMS_Service_A and IMS_Service_B in the handset.
I can see where you're going with your idea that the PC might be the initial IMS service device. My concern here is twofold: the "Internet mentality" i.e. everything if free; and while VoIP services have taken off - combinatorial IMS media-services may still come through in a silo'd manner, even some current "IMS services" seem to be a little silo'd in their actual implementation. So my view is that mobile phones will actually determine the success of IMS, and that maybe the education of the IMS service consumer base is something that needs to be addressed a little more urgently.
As more "eventual IMS subscribers" read your blog .. this will definitely help :-)
You have very good points.
It is true that JSR 281 is very PoC-centric, while I doubt PoC will ever be used for many mass market services. The group management part is more interesting as user groups should be a great enabler in the future. I think part of the problem is that JSR 281 was specified by vendors which simply intended to boost the sales of their early IMS silos. From recent discussions with suppliers of IMS client frameworks, I can also see that adoption is not a given yet.
GSMA could possibly play the role you want for testing service compatibility, more especially if operators that are pushing CPM in OMA make the same effort in GSMA.
You have a point about PCs, but I still think that technically this is the easiest way to start.
Christophe
Post a Comment