Co-existence of Conservative & Progressive Application Layers

In my last post, I described two IMS application layers, which may be seen either as conflicting or as complementing each other.

The conservative IMS application layer is the one that can be seen right now in early IMS deployments. It either re-implements legacy services (e.g. telephony) or implements new ones in a legacy silo and black box manner (e.g. push to talk, early presence).

The progressive IMS application layer is essentially in the mind of a few people and in some labs (actually it is interesting to see that NEPs tend to promote IMS using rather progressive demos, while at the same time they only propose a very conservative application layer to their customers). The OMA Converged IP Messaging (CPM) work item might be the very first attempt at standardizing something in the progressive IMS application layer, but it is not very advanced yet.

The progressive application layer would fully exploit the multimedia capabilities, fixed mobile convergence, and powerful service control characteristics of IMS and its core protocol, SIP. It would also be based on a new generation of open service platforms, provided by leading IT companies, and able to optimally combine the protocols and services originating from the IMS, Internet and IT domains.

Alternative But Compatible Communication Paradigms

A major difference between the conservative and progressive application layers is that the former recreates communication silos (e.g. voice, messaging, voice bursts, video) while the latter would permit the user to freely switch between communication media (e.g. messaging to voice), and to arbitrarily mix content, data, and communication components in a single session. In this context, a progressive IMS application layer is as much about integrating services together as it is about delivering new services.

Multimedia communication is a superset of legacy single medium communication. While it is possible to combine multiple media components in a multimedia session, it is also possible to start a multimedia session with a single component (e.g. voice), keep this single component during the session, and terminate the session as it started, with this single component.

Consequently, a progressive IMS application layer supporting multimedia communication can accomodate:
- Users whose communication style is still formatted by decades of silo communication services, and a habit not to mix communication and data/content services;
- IMS clients that are specialized in the support of one or few media components (e.g. voice-only clients);
- Interaction between multimedia communication clients and silo communication clients.

The last bullet is of particular importance, as it permits multimedia communication to be introduced without any disruption. Multimedia communication clients can interwork with each other and use the full potential of SIP multimedia sessions, as they can interwork with silo communication clients and, through IMS circuit-switched gateways, with legacy telephones.

When a multimedia communication client interworks with a silo communication client, content of the session is limited by the capability of the silo communication client. End-to-end negotiation/re-negotiation of the session (possibly with the support of network entities) will ensure the coherence of the session content between the endpoints (e.g. the attempt to re-negotiate a voice session into a video one will be rejected if the multimedia communication client interacts with a voice-only client).

Different Public User Identities For Different Services

Let us consider the situation in which the operator has deployed application servers in the conservative application layer, which support voice services (e.g. call control, conferencing), videotelephony, push to talk, and IMS messaging (though I think it would be better to avoid deploying a messaging silo in IMS).

The operator is now introducing a progressive application layer which is able, for a start, to support any of the above media in the same session, with the possibility to freely switch between them, both for 2-party calls and conferencing. Note that once you have the right multimedia architecture in the progressive application layer, you can incrementally improve its media support over time (i.e. you can add new media support as needed or possible).

How can these two application layers, supporting different user experiences, co-exist in the same network?

The answer is simple:
- As access to the IMS application layer is determined by service profiles stored in the HSS (*), a service profile can provide access to the silo communication services, while another can provide access to multimedia communication services.
- As service profiles are associated to Public User Identities (IMPUs), some IMPUs can be link to a silo communication experience, while others can be associated to a multimedia communication experience.
- As the IMS application layer clearly distinguishes between the different parties of a session, it is possible for users with different service profiles to communicate, with each accessing its own (conservative or progressive) set of services.

This implies that users which do not use IMS services (e.g. legacy telephony users), users with a conservative IMS service profile, and users with a progressive IMS service profile can all communicate together. Obviously, users with a progressive IMS service profile will enjoy a richer communication experience with users sharing a similar service profile and users making use of rich Internet clients.

This also implies that the same user can alternatively benefit from a conservative or progressive service profile depending on the public user identity it uses, i.e. the persona it has decided to take.

While this is not a mandatory approach, a quite convenient way to allocate IMPUs for conservative and progressive application layers could be the following:
- Legacy identities based on E.164 numbers (e.g. tel:+151412345) remain associated to a silo communication experience.
- New IMS identities based on SIP URIs (e.g. sip:user@operator.com) are associated to the new communication experience (however, in order to be contacted by legacy phones, there should still be an E.164 alias associated to the SIP URI).

This clear distinction based on identity types would permit to clearly introduce the new service paradigm in the mind of users as new email-like user identities are introduced. The new addressing approach based on SIP URIs would also permit to better support fixed mobile service convergence, as these identities do not have to be associated to a specific access type (in comparison to mobile and fixed E.164 numbers).

From Black Boxes To Open Service Platforms

Another possible difference between a conservative and a progressive application layer lies in the way the application layer is implemented. A conservative application layer will typically make use of proprietary platforms dedicated to the support of a single service (e.g. push to talk), while the progressive application layer will make use of standard and open service platforms (e.g. J2EE or JAIN SLEE based), permitting the co-location of services, as well as faster service development and evolution cycles.

Let us imagine that an operator initially deploys a 1st generation presence server, implemented on a proprietary platform, and totally dedicated to the support of presence, without any possibility to co-locate presence with services that make use of it as an enabler (e.g. incoming call handling based on presence).

As part of the introduction of a progressive application layer, the operator has the possibility to change from a server (black box) to an application (white box) paradigm. Presence can now be deployed as an application on a set of service platform instances, and be co-located with other applications according to, e.g. signaling traffic optimization criteria.

How can the migration from a silo implementation to a horizontal implementation take place?

The answer relies once more in the usage of service profiles.

The operator can decide to deploy the new presence application in parallel to the existing silo server(s). New subscribers will be allocated to the new presence implementation through a service profile pointing at the new presence implementation address.

The operator can then start the migration of existing subscribers from the old implementation to the new one at the pace it decides.

The migration implies a change of application server address in the service profiles stored in the HSS. A priori, existing clients need not be impacted by the change (i.e. no need to change the configuration in the IMS client) and the transition from the old implementation to the new one can therefore be transparent to them.

Co-existence and Smooth Transition

Comments to my recent posts as well as emails I received tend to paint a quite pessimistic picture about the ability of the telecom industry to use IMS for something else than the re-creation of pre-IMS service silos.

However, as a technician, I can tell that one of the "cool" features of IMS is that it can accommodate the co-existence and interworking between services implemented in the traditional telecom silo way and services (or more appropriately a user experience) making use of new paradigms. Moreover, IMS can enable a smooth and seamless transition from one to the other.

If the industry ever misses its necessary re-invention, I hope it will have the decency not to blame the technology for it :)

Christophe

(*): I often mention IMS service profiles and initial filter criteria, but never described them in details. I could dedicate a few posts to this. However, as describing standard features is not the most exciting type of post to write, I hesitate to do it. If you think this would be needed, just email me or write a comment.