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.