Conservative & Progressive Application Layers

The IMS and related IETF specifications define a long list of ingredients that can be used to make a lot of meals (from the pizza to the gourmet menu). The only problem is that so far nobody has delivered any cookbook for it.

From this set of ingredients, you can roughly implement two application layers: a conservative and a progressive one.

I believe that these two application layers make sense, for different and complementary reasons.

The conservative application layer basically re-implements legacy services (e.g. telephony) or services which follow the typical silo mindset of legacy telecommunication services (e.g. push to talk) over an architecture which can support them, but is far from being used at its full potential. They are usually implemented with the support of black boxes in the application layer.

Everything standardized and delivered today in the context of IMS can be tagged as "conservative".

The most important service in the conservative IMS application layer is telephony. It makes sense to implement (first line) telephony services on IMS, for fixed operators who want to phase out their old, heterogeneous and expensive circuit-switched infrastructure. It also makes sense for mobile operators who wish to extend cellular telephony over circuit-switched to IMS-based telephony making use of unlicensed wireless access (e.g. WiFi, WiMax).

As for the other early IMS services implemented in a silo manner like push to talk, IMS messaging, or services combining voice on circuit-switched with data transfer (e.g. pictures, video streaming) on IMS, they may address short term business opportunities.

A great advantage with IMS services implemented in the conservative application layer is that they fit perfectly with legacy organizations, legacy business models, legacy standardization-driven development lifecycles, legacy relationships between operators and vendors, and legacy mindsets. This is not surprising as this application layer is the direct result of all this legacy.

The conservative application layer is certainly necessary to the progressive one, as it constitutes an initial motivation for operators to deploy IMS, as it does not change everything overnight for them, and as it can be seen as a first step towards something else.

This something else is the progressive application layer, which is necessary to the conservative one as it shows that IMS can play a significant role in the rapidly changing world of converging Internet, telecommunications and advanced IT.

I do not believe in the benefit of an IMS network that would limit itself to re-creating a telecommunication world that is clearly reaching its limits. This is a reason why I find the concept of communication services, as pushed by some in 3GPP, very dangerous, as it seems to define as a target an IMS application layer based on the recreation of service silos that are only marginally different from the existing ones.

Most of my posts on this blog are about the progressive application layer, but to make it short I see it based on the three pillars I introduced in my very first posts on this blog.

Multimedia Communication permits two major things:

- Switching between alternative communication means without stopping a session (e.g. messaging to voice, voice to video, video to messaging)

- Freely combining communication, content and application sharing within the same session.

IMS-enabled fixed mobile convergence permits to potentially provide every service to every device using any type of access technology to connect with the network. This is a network and user-centric convergence, which does not rely on any specific feature from devices, other than their ability to register with IMS. The key IMS concept enabling this convergence is the ability for the user to share an identity between multiple devices.

Finally, the inherent characteristics of SIP as a protocol and IMS as a powerful service framework (many posts related to this), combined with an extensive use of web services, service mashups and Service Oriented Architecture principles, can lead to an explosion of new service opportunities. These are typically services for which my 8 year old son and my telecom illiterate neighbour might have better ideas than me. Some of these services might have very short lifecycles and may target niche market segments.

Such a progressive IMS application layer might be more about a new user experience than a set of easily identifiable services. It may come with a new set of partnerships between telecom operators and 3rd parties, as well as new business models.

In order to be possible, such a progressive application layer must be supported by advanced and open service platforms, enabling the agility required by new services, as well as the possibility to optimally connect and combine the IMS, Internet and IT domains.

Such a progressive application layer will take time to happen, and comes with many challenges. Some of these challenges are technical, but I would tend to think that most are cultural and organizational, and nothing at the moment ensures that the telecom industry will be able to exploit the potential of the technology and to successfully deploy an optimal IMS application layer.

The difficulties associated to the progressive application layer make me think that it is urgent to create a common understanding of what this progressive application layer would be able to deliver and how it may look like. This blog is a modest attempt at contributing to this.

I also believe that operators should adopt an iterative and empirical experience of what IMS can deliver, beyond the wonderful voice and rich voice services.

For this, it is important to have IMS deployed, initially for the support of a conservative application layer, with the consideration that this conservative application layer can only be a first step and not an end in itself.

Once IMS has been deployed the question can shift from "do we really need IMS?" to "how can we make an optimal use of this f*** IMS we spent so much f*** money on?".

In my mind, an optimal scenario is one of operators deploying IMS to support initial products based on a conservative application layer. Then, in parallel, they start investing time and thoughts about the progressive application layer, speaking to vendors they are not used to, trialling ideas, exploring different directions, and starting to deploy simple innovative services to explore the market and the power of the technology. Slowly, the progressive application layer would mature, grow in terms of usage, and define a new user experience. Then, one day, it could fully take control and replace the conservative application layer.

I really see two physically separated application layers (through some overlaps may exist), using different service platforms and delivering different types of services.

The burgeoning progressive application layer needs not to disrupt the business generated by the conservative one. On the other hand, I do not believe that it is realistic to think that a conservative application layer can smoothly evolve towards a progressive one. There is a clear revolutionary step, and it is better to start the progressive application layer from a clean shit (of course, I am making quite arbitrary statements here, that need to be adapted and possibly corrected on a case by case basis).

For instance, you may decide that in order to support telephony services on IMS you can rely on black box application servers that just deliver the usual goods in a cost effective manner, while multimedia communication and associated services making use of such an enabler like presence will be delivered on a new generation of service platforms, to be introduced in parallel.

The conservative and progressive application layers would co-exist and even interwork for some years. In the next post I will explain of this can be done.

Christophe

PS: I have a few slides on this subject, that I had the opportunity to present in a conference. Feel free to email me to get them.