IMS Public User Identities (IMPUs)

There might be a few interesting things to say about IMS user identities.

As you certainly know, there can be two sorts of IMS Public User Identities (also known as IMPUs): tel URIs (e.g. tel:+1-234-456789) and sip URIs (e.g. sip:user@operator).

(Note that a SIP URI with an E.164 number in the user part and a parameter "user=phone" is the equivalent to a tel URI and will be treated as such by the IMS core network)

Tel URIs: Smooth Migration From Legacy Telephony

In IMS, tel URIs may be used to address an IMS user or a user in the legacy circuit-switched network.

When the tel URI corresponds to an IMS user, the core network entity called S-CSCF (Serving Call Session Control Function) will be able to resolve it into a SIP URI, thanks to a DNS extension called ENUM,. It will then proceed with the routing of the SIP request within the IMS.

When the tel URI corresponds to a circuit-switched user, the S-CSCF's query to ENUM will fail to resolve the tel URI into a SIP URI. The S-CSCF will then route the call to the circuit-switched network through an appropriate gateway.

Consequently, using a tel URI an IMS user can set up a call with another IMS user or with a legacy telephony user.

Tel URIs also permit IMS users to be called from the circuit-switched network. The CS network routes the call to a voice gateway, which sets up a voice session in the IMS using the original B-party number to form a tel URI. The IMS core then resolves the tel URI into a SIP URI of the IMS user.

In order to support interoperability with the circuit-switched network, IMS users will need to keep legacy phone numbers for years, even if they use SIP URIs in parallel.

SIP URIs: The Future of User Addressing

SIP URIs should eventually dominate and replace phone numbers as the way to address other users in some years from now.

This steady migration from telephone numbers to alphanumerical SIP addresses will be a fundamental element for different types of convergence:

- Convergence between fixed and mobile communication, as mobile and fixed -segregated phone numbers will be replaced by access-agnostic SIP URIs.

- Convergence between telecom and Internet communication, as both can use SIP and SIP URIs.

- Convergence between SIP-based communication (e.g. multimedia sessions, voice, instant messaging) and email through the possibility to use the same address between SIP and the email protocol (e.g. sip:John@service_provider vs. smtp:John@service_provider).

IMPUs Identify Users, Not a Specific Line or Device!

There is a major difference between IMS and pre-IMS addresses. While pre-IMS phone numbers are usually associated to a unique line or device, IMS IMPUs relate to end-users.

In a pre-IMS world, mapping a legacy phone number to multiple devices is an added-value feature requiring a specific implementation in existing fixed and mobile networks.

In contrast, the possibility to concurrently assign an IMPU to multiple devices is a basic IMS feature, supported by the IMS core network (i.e. S-CSCF), without the need for a specific support in the application layer. The dynamic allocation of an IMPU to one or several devices is performed through the IMS registration procedure.

In addition, the possibility for IMS to support multiple access technologies (e.g. cable, xDSL, cellular wireless, non-cellular wireless) makes that an IMPU can concurrently be shared between multiple fixed and mobile devices (e.g. fixed phone, PC, set top box, mp3 player, mobile phone). This is fixed mobile convergence at the user and network level.

Multiple IMPUs for One User

IMS specifications permit a user to have several IMPUs. It is up to the operator to decide how many IMPUs a user will be allowed to have.

Different IMPUs may serve as aliases. These IMPUs are totally inter-changeable, as they are associated to the same set of services and are transparently associated to the same devices. The user may use them to differentiate between different groups of contacts (e.g. friends vs. strangers). A user will typically have a tel URI as alias to a SIP URI (see above).

Different IMPUs may also permit the user to endorse several persona (e.g. member of an association, owner of a private business). In this case, the IMPUs may be associated to different service profiles, and possibly to different devices (but they can also be associated to the same).

One IMPU for All Services, Across All Devices

A feature that may seem to conflict with the previous, and might actually be more essential, is the possibility to associate a single IMPU to virtually all the services of a user.

IMS and SIP can unify all real time 2-party and multi-party person to person communication (e.g. voice, video, instant messaging, deferred messaging), blend communication, content and data together, and support access to user data and information (e.g. presence, user profile, various event packages permitting to access and monitor user-related data and events).

All these communication/content/data services can be accessed through a single user IMPU, which is independent from the devices and access technologies being used. Moreover, if this IMPU corresponds to the user's email address, you can then finally have a unique address on your visit or business cards, and this address may provides access to more services than all the old ones put together.

More Enablers for Services

The possibility to access a plethora of services through a single IMPU can also be extremely beneficial to services themselves.

Consider the following example (which may not be that interesting from a service perspective, but this is not the point).

John sends an electronic birthday card to Mary through IMS deferred messaging (i.e. the message will be delivered to Mary as soon as she is able to receive it). A service associated to John intercepts the SIP service request, extracts Mary's IMPU from it and generates a presence request on behalf of John and addressed to Mary's IMPU. Mary's presence server answers with a set of information related to Mary, according to John's authorization to access it. This information may be very rich about Mary, the means and addresses to communicate with her, her devices, the applications she uses, and various availability and preference information about them. John's service may use this information to suggest additional or alternative ways to deliver the electronic birthday card (e.g. email). It may also suggest to store elements of this information in various repositories, such as John's address book.

This example shows that even if a an IMS subscriber still makes use multiple identities and addresses (for instance addresses related to Internet services), one of them may be used as the key to dynamically discover all others.

It also shows that a service which had never heard about a user can discover a whole lot of information about this user and use it for the delivery of sophisticated services. In the example, I used presence, which by itself can be a very rich set of information, but this could be extended to much more than this.

Christophe

An IMS Application Server in Context

The figure above (click to enlarge) shows how an IMS application server can fit in a service delivery context that includes a legacy telecommunications environment, the Internet, the IT environment of the users it provides services to, and (of course) the IMS.

This picture might not be perfect (though I like the shades of blue), but let me know if you can find much better in the current IMS literature.

A specific instance of an IMS application server may only implement a subset of the features shown in this figure, depending on the capabilities of the platform supporting it, and its potential specialization based on the logic it supports.

It is not the purpose of this post to discuss the technologies that can be used to support such an IMS application server. However, if you look for platforms able to support most of what is implied here, J2EE and JAIN SLEE are certainly the best candidates, and a combination of both might be the winning ticket right now.

Pre-IMS Context (white boxes, black arrows)

The white boxes and black arrows represent the typical pre-IMS context of an application server, that applies to most current Service Delivery Platforms (SDPs).

Applications implemented on the application server can make use of a set of network capabilities such as call control, location, SMS, MMS.

Each set of capabilities is supported by a dedicated network server (e.g. switch, location server) and through a specific network to network interface (e.g. INAP, MLP).

On top of these protocols, the typical SDP provides for the service logic it hosts such features as horizontalization (e.g. hiding of the underlying stove pipes), homogenization (e.g. via a set of similar APIs), simplification (e.g. hiding details of ugly telecom protocols), and abstraction (e.g. permitting to manipulate a call at a high level).

It also exposes the capabilities to 3rd party service providers, through CORBA APIs (e.g. Parlay Classic) or web services (e.g. Parlay X).

The set of capabilities available to service logic in the SDP and to 3rd party service providers is limited and static. It followed a very slow standardization and implementation process, starting with the standardization of the network enabler (e.g. IN), and finishing with the implementation of (standardized) web services (e.g. call control). This means several years.

IMS, and more generally the move to all-IP can change all this and make the picture more colorful.

Where is the IMS Core Network? (lower part)

You might have noticed that the figure does not show any IMS core network entity (e.g. CSCFs, HSS, gateways).

This is not because they are not there or they are not important to the IMS service architecture. Actually, without them, the IMS service architecture would not exist at all!

The point is that the IMS core network itself is of limited relevance from an application perspective, compared to the sophisticated SIP routing mechanisms it provides. This is an aspect that is usually overlooked, as the IMS core network is often the tree that hides the forest to those who try to understand the IMS service architecture.

For instance, I believe that ISC (IMS Service Control) should not be considered as an interface between the S-CSCF and the IMS application server, like INAP is an interface between a switch and an Intelligent Network server. ISC is just the SIP road that permits to connect the IMS application server to the IMS/SIP motorway that connects all the blue entities in the lower half of the picture.

One of my core beliefs is that, among all the benefits the IMS core network can provide to its application layer, one of the most important should be its transparency. An application should only care about what the IMS architecture can provide to it, not about the sophisticated details of how this is done. The application should only know that by issuing this SIP message to this user identity, it will be able to magically access this enabler (e.g. the presence information of this user), and that is all. This is unfair for the hundreds of pages that specify the IMS core network, and the thousands of workers that implement or will operate it, but life is unfair.

SOA and UOA (upper vs. lower parts)

As I wrote in an earlier post, the IMS service architecture as it is depicted in 3GPP specifications is like a picture of a person which would only show its lower half. The reason for this is that 3GPP IMS specifications are core network centric, and only address the relationship between the IMS application server and the core network.

Whereas the pre-IMS application server only exposes a few web services to (hypothetical) 3rd party applications, the future application server should be an integral part of a service oriented architecture, in which applications deployed in the operator's domain could as much be consumers of 3rd party services as they expose some, and could as well integrate with the user's IT environment (e.g. calendar, applications running at home or in the office).

This Internet and IT -centric dimension of the application layer is complemented with its IMS and SIP counterpart (SIP is not the only service protocol that will be used in the IMS, and IMS is not the only network making use of SIP), which adds user orientation to the global service architecture.

To over-simplify, the service oriented architecture routes service requests according to the identity of services, while the user oriented architecture enabled by IMS and SIP can route service requests according to user identities, service identities, or a combination of both. As a consequence, the identity of a user placed in a SIP message (as originator or recipient) may impact service routing and direct the SIP service request to network-based applications serving the user, client or endpoint applications serving the user, or the user itself.

In terms of semantic, it is time for the large part of the telecom industry that still ignores it to understand that the concept of SIP session is much broader than its legacy "call" counterpart, and that SIP is not limited to session control. There are other SIP methods and mechanisms which could be of great interest in the future application layer (e.g. SIP event packages), and which sometimes overlap with the semantic usually associated to web services (e.g. will you use a web service or a SIP SUBSCRIBE to access user information?).

IMS Capabilities: Numerous, Dynamic and Everywhere (lower part left)

The semantic power of SIP, as well as its extreme extensibility and versatility compared to telecom protocols (just look at the rate new SIP drafts pop up in the IETF) make that capabilities usable by applications can be varied, dynamic and multiple.

These capabilities will seldomly be located in standardized network servers like today.

Some will be located in IMS application servers. Every new IMS application exhibiting a SIP interface to end users might be usable as an enabler by other applications using the same SIP interface. Some of these applications could themselves be used as enablers, and so on,

Other capabilities will be located in endpoint servers and devices connected to the IMS, including those associated to end users in a fixed mobile converged environment (e.g. mobile phone, PC at home, home gateway, set top box, fixed phone). Every new application deployed in these endpoints and devices may give birth to new enabling capabilities usable by the IMS application layer. Just to take an example, there exists today a SIP event package that can be used to monitor the activity of a user on a keyboard.

Access to these enablers located in network application servers, IMS devices and enpoint servers, can cross network boundaries. This is, an application located in operator X's network can access an enabler located in or registered with operator Y's network or in the Internet. For instance, an application associated to John, subscriber of operator X, can access the presence of Alice, subscriber of operator Y, and the presence of Bob, located in the Internet.

Web Services, SOA: Much More Possibilities (upper part center)

The multiplicity and dynamicity of IMS service capabilities permits the operator to offer a much richer and differentiated set of IMS services to 3rd party service providers.

Besides the usual communication-related suspects, a large portion of these services are likely to be informational: information about the user, its preferences, its data, its applications, its devices, its activity, etc. It will be the responsibility of the operator to preserve the intimacy and privacy of the users.

The dynamic approach implies that operators will have to rely less on standards and more on differentiation in order to attract third party service providers. This is one example, among others, about the need for the telecom industry to find a new balance between standardization and differentiation.

Web services are not the only way to integrate 3rd party services in the operator's offer. This integration can also be performed on a more horizontal axis.

3rd Party Services Integrated Through End-to-End SIP (bottom part right)

3rd party applications located in the IMS (e.g. in a different operator's network) or in a non-IMS network (e.g. the Internet) can have an end-to-end SIP interaction with the IMS clients of the operator's subscribers. These rd party applications may either be network-based (e.g. implemented in an IMS application server) or device/endpoint server based.

This end-to-end service interaction can be placed under the control of the IMS application server, as soon as the service profile of the user is provisioned with an initial filter criteria that identifies end-to-end SIP signaling between the user and the 3rd party application.

For instance, routing of SIP signaling to the IMS application server may be determined by the fact that the SIP request is addressed to a specific SIP URI (e.g. sip:this_service@3P_SP.com), a specific SIP URI domain (e.g. 3P_SP.com), or because the SIP request explicitly identifies a 3rd party application in a SIP header or in an SDP (session description protocol) body. For instance, the name of a game could appear in the session description of a SIP INVITE aiming at starting a gaming session.

Service logic inserted in the signaling path between the user and the 3rd party service can serve various purposes: control, charging, monitoring, adding value. Do not overlook the latest item: telecommunications should not be only about control and charging.

3rd Party Services Through SIP Indirection or Inclusion in SIP Session (same)

This is just a variant of the previous one.

This case differs from the one above because SIP interaction only takes place between the user and the service logic hosted in the IMS application server.

The 3rd party logic or content is accessed/controlled through other protocol(s) than SIP (e.g. HTTP, RTSP, web services).

I already gave an example of such an integration through SIP indirection. In the future, I will post another one showing inclusion of 3rd party content in a SIP session controlled by the operator.

The Ut Reference Point (lower part left)

The picture shows the support of the Ut interface which, in the IMS service architecture, permits an IMS client to interface with the IMS Application Server using XCAP (HTTP-based protocol that manipulates XML documents) for service data management.

I extended this interface to HTTP in general, as it is very important to permit that IMS clients interact with service logic through advanced web-based user interfaces. Other relevant protocols may be added as needed.

Conversion Between SIP and Non-IMS Protocols (upper part right)

It can be rightfully argued that this should not be part of the SOA layer, but please bear with it.

The IMS service architecture makes it very convenient to detect and divert SIP signaling which needs to be converted into another protocol (e.g. Jabber/XMPP, OMA IMPS CSP) to an IMS application server serving as gateway towards this other protocol. Conversely, the IMS Application Server can receive non-IMS messages and convert them towards SIP for interaction with IMS clients.

This approach is currently used in 3GPP for the support of SMS over generic IP access (which encapsulates legacy SMS's into SIP IMS Messaging).

Note that the IMS core network only supports protocol conversion from/to legacy circuit-switched networks for voice calls. The rest is up to the application layer.

Christophe

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.

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.

The Beatles & The Stones

The summary of a new report by Light Reading titled Telco Web 2.0 Mashups: A New Blueprint for Service Creation makes me think of the Beatles v. Stones battle.

Obviously, in the 60's the Beatles and the Rolling Stones were foes to death, and history can tell that only one of these two bands was great. Which one?

The report apparently highlights the need for operators to rapidly embrace a web services and service mashups approach. Fine, I totally agree with this.

My problem is when IMS and SIP are presented as an alternative to this approach. In this report this is clearly the bad one, as everybody knows that you cannot implement both web services and SIP/IMS and combine the two for an optimal usage.

When will the industry stop looking for the silver bullet? The unique technical solution, the unique business model that will answer all problems?

A core thesis I am trying to develop in this blog is that SOA/web services and IMS/SIP can be combined together to form a new paradigm (User Oriented Architecture) which, like the bands cited above would be more than the sum of its parts.

Another summary of the report cites JAIN SLEE as the service creation/execution environment in the context of IMS. I like JAIN SLEE and I think it can play an interesting role in IMS and across IMS and other networks.

However, it would be more interesting if the summary mentioned Java EE (J2EE) as well, as it could show that the Web Services / SIP picture is not that black and white. J2EE platforms fit very well in a web services world and I know at least three of the main J2EE platform suppliers which include SIP servlet support at the core of their platform. This means that there exist on the market platforms that can be used to implement services that are both web services and SIP/IMS centric. Unless of course this is strictly forbidden by both IMS and Web Services purists (I already had the opportunity to write about the artificial separation between IMS and Web Services chapels).

Why should the telecom industry just follow the steps of Internet companies and not try to bring its own contribution to the future, by integrating and enriching what exists today?

Christophe

IMS Communication Services: Latest News

Last week, the 3GPP CT plenary meeting decided to align on the IETF approach for the handling of communication services. This can be seen in a Liaison Statement to the IETF available on the 3GPP web site.

The worst has been avoided for now, as the alternative proposal (which lost) had two important drawbacks:
1) It reused a standard IETF mechanism (feature tag used in the Accept-Contact header) with a different, 3GPP-specific semantic.
2) It made the concept of communication service directly manipulated by IMS clients, which could have a huge impact on interoperability aspects with non IMS clients, and would have driven the implementation of mobile handsets for the years to come.

The IETF alternative limits the mandatory identification of communication services within the IMS network, which interprets SIP signaling generated by clients and derives the communication service ID from it.

Easier to Eventually Get Rid of It

As a network centric concept, the communication service ID is less intrusive and easier to control by operators (compared to the case where it would be client-centric). It can certainly be used for early IMS silo services, and then be discarded when more multimedia services are deployed.

This can therefore be a short-term concept serving short-term requirements.

The Concept Could Be Useful Even in the Long Term

Moreover, it could evolve into something actually interesting in the context of a more progressive vision of IMS services.

At the moment, the S-CSCF uses initial filter criteria in order to dispatch SIP requests to the application layer. The evaluation of filter criteria implies an analysis of the SIP requests (method, direction, content).

As the result of this analysis is not documented in the SIP request forwarded to the application server, the application server (potentially the SCIM into it) needs to perform a new and somehow redundant analysis of the SIP request in order to determine which services should be invoked.

A communication service ID header could permit an identification of the initial filter criteria that led to the forwarding to the application server, that could be used by the AS as part of its own analysis of the incoming SIP request.

Obviously, in this context the ID would not identify a service, but rather a set of criteria associated to a SIP request, and which can be used as information (among other) to invoke service logic in application servers.

Still Some Risks

From the LS to the IETF you cannot determine that the risk for communication services creating an IMS walled garden and limiting potential for service innovation has been averted for good.

The LS explicitly mentions the need to comply with requirements written in TS 23.228. The problem is that the most dangerous aspects of communication services are described in TS 23.228 (see last post).

On the other hand, the IETF could also rightly underline that TS 23.228 includes incompatible requirements, as I tried to explain in my last post. More especially, some requirements describing a 3GPP-specific concept of communication service directly conflict with others asking to preserve SIP capabilities and interworking with non-IMS networks.

In any case, one of the important requirements in TS 23.228 is that it should be possible for an IMS client or an IMS network not to make use of communication services. This optionality should ensure holes in the hypothetical walls of the IMS garden.

I am therefore reasonably confident that things will turn out in the right direction, once the IETF identifies these incompatibilities and proposes to resolve them by removing the dangerous requirements. The CT plenary decision from last week seems to express the importance that 3GPP places into being interoperable with other SIP networks.

Christophe

April 2009 update: the concept of Communication Service as finally specified is described here.

IMS Communication Services: Uncut Version

In my last post, I presented a light version of the 3GPP concept of Communication Service, which focuses on the identification in SIP signalling of the service a user intends to use.

However, the standardization of communication services started nearly 18 months ago, and from contributions to the subject you can draw a quite precise picture of what IMS services could be, would all the proposed requirements be approved by 3GPP and implemented in products.

The text below written in italic is my own rephrasing of requirements that were proposed for communication services (I usually try to stay close to the original wording). All these requirements can be found in public documents: contributions to 3GPP SA2, text in chapter 4.13 of TS 23.228 7.x.x, a draft submitted to the IETF, and contributions to 3GPP CT1.

A communication service is the aggregation of one or several media components. The rules that govern this aggregation are implemented by service logic. A service description specifies the possible behavior and states, e.g. the allowed media combination and state transitions. If an IMS client would like to perform a change in a session which is not part of the service definition, it shall establish a new session.

The lack of support of true multimedia making use of intrinsic SIP capabilities is not a defect of early IMS silo services, that needs to be fixed as soon as possible. This is a feature of 3GPP introduced in R7. Such a requirement could install silos in standard compliant IMS deployments for many years.

The approach is clearly restrictive. IMS clients are placed under control, and service logic is implemented to prevent them from accessing non allowed multimedia features.

Multimedia may be possible, but through multiple parallel sessions. Such an approach may imply a complex interface towards the end-user, who would need to explicitly control parallel sessions. Alternatively, it would require the implementation of a ad-hoc client able to hide the multiplicity of sessions to the end-user. This latter option would have the "merit" to both clearly identify what is needed (i.e. a single service session) and demonstrate that communication services prevent to do it in a natural way (i.e. a single SIP session). Simulating multimedia sessions through multiple more restricted sessions would certainly incur complexity and costs. No need to say that such strange SIP clients would be very different from non-IMS SIP clients, thus re-inforcing IMS as a world apart.

Communication services are either standardized (e.g. push to talk) or proprietary and specific to an operator or an enterprise.

Every SIP message initiated by an IMS client must include a requested IMS Communication Service. A session can only be started between two clients if they share the same IMS Communication Service. Within the client, the Communication Service ID is used to dispatch the message to the correct application.

The first statement seems to imply an opening of the concept to non standardized communication services including, why not?, more innovative and multimedia ones.

However, this openness looks very artificial when you see that communication service IDs must be part of all SIP signalling and directly govern the ability to start a session between two clients.

Let's take an example.

An operator decides to introduce a new communication client, enabling the user to freely switch between messaging/chat and voice communication inside one session. In a normal SIP world, such a client can establish sessions with voice-only clients, as well as with messaging-only clients. The only restriction is that the transition to another media component is not possible with these peer clients. The new service is therefore both compatible with legacy clients and with new or more sophisticated multimedia clients introduced by this and other service providers, in the IMS, in the enterprise or in the Internet.

In the wonderful world of communication services, the situation is different. The operator must create a new communication service ID for the service. Because this communication service ID is different from the voice-only and messaging-only ones, it is not possible to start a session with legacy clients. Session setup will also fail with (a priori) compatible clients introduced by other operators but using a different ID. As a consequence, the service will have great difficulties to take off as it is likely that most attempts to set up a session with it will fail. It is certainly better for the operator to wait for standardization to introduce the service.

As the concept of communication service does not exist outside of IMS, the mandatory nature of its usage makes interoperability with non IMS clients virtually impossible. Consequently, the new service will not even be able to setup sessions with clients that are not subject to communication service limitations.

The hypothetical adoption of the requirements described above would therefore both create an IMS walled garden and make very difficult the introduction of innovative and operator-specific multimedia services within this walled garden.

Added-value applications deployed over IMS must make use of Communication Services. When a client intends to access such an application, the SIP signalling must include two identities: the identity of the application and the identity of the communication service it uses.

There is plenty to say about this proposal...

First it gives the impression of a willingness to favor service innovation. However, in a context where communications services consist of voice, push to talk over cellular (i.e. voice without the quality) and messaging, how different can these applications be from those that can make use today of circuit switched voice, SMS and MMS?

The approach seems to enforce the usage of silos mimicking pre-IMS services, as the only way to deliver non standardized services in the IMS. Non standardized services need to follow the rails (pipes?) strictly and arbitrarily defined by standardization, and which are more or less the same as before. Any multimedia service that would make use of standard (e.g. RTSP) or application-level protocols that are not part of a communication service definition are outlawed by 3GPP standards.

You may imagine that new communication services, permitting more innovative services will be introduced in the future. In 3GPP R8? R9? In any case, this is likely to be in several years from a product perspective. Strictly controlled, innovation has to follow the roadmap defined by 3GPP and the companies that control it.

Another interesting aspect of this approach is that it creates a two-tiered IMS application layer in both IMS clients and in the network. This layered architecture is explicit in a figure introduced in TS 23.228 chapter 4.13.

The bottom part of this layer consists of the standardized communication services, which are very telco centric and demand carrier grade characteristics to control undisciplined clients. I guess classical network equipment providers are the best placed to deliver these as black boxes.

The upper part is the innovative one, the more IT layer. It has to rely on the lower part, certainly through a set of interfaces like OSA/Parlay or web services. As I wrote above, room for innovation is strictly limited.

In past posts, I described my belief that for the benefit of the industry, the whole IMS application layer should belong to advanced and open IT platforms, benefiting from the huge community of Java developers and the ability for people with good ideas to easily and rapidly develop them.

Communication services as described in these requirements would lead to a marginalization of this IT layer and its tight control by the telco one below. It would actually recreate the current telecom situation, in which there are so few ammunitions to create innovative services that innovation can hardly take place.

If you consider that there might be an ongoing fight between old school NEPs and IT companies (or NEPs clearly embracing an IT strategy) for the control of the future telecom application layer, communication services look like a powerful weapon for the former against the latter.

Communication services should not adversely impact interoperability with external SIP and circuit-switched networks. It shall be possible for IMS clients and IMS networks to support communication that do not make use of a communication service ID. The usage of communication service identifiers shall not restrict the inherent capabilities of SIP.

All these requirements can be found in TS 23.228 together with some of the seemingly contradicting requirements above. This shows that some companies in 3GPP (vendors, operators) do not support the idea of an IMS walled garden and are afraid of the potential consequences of communication services on the ability of IMS to innovate and to be open to other domains.

This is an important thing to take into account. 3GPP consists of a variety of visions which sometimes oppose each other. It would be wrong to say that 3GPP as a whole supports the most extreme definition of communication services, and I would tend to think that, well informed on the potentially negative effects of these concepts, the great majority of 3GPP companies would not endorse them.

Christophe

April 2009 update: the concept of Communication Service as finally specified is described here.