Review of Typical SCIM Features

I presented how the SCIM was introduced in IMS specifications. In this post, I will provide my opinion on the relevance of the features usually associated to the SCIM.

Architecture Aspects

Before speaking about the functionality of the SCIM, let's consider architecture aspects.

I assume that the SCIM coordinates the execution of individual services on an application server, and does not only sequence the interactions at the application server level. For this, there are standardized mechanisms already, supported by the S-CSCF.

In order to coordinate service execution, the SCIM needs to individually access each service on an application server.

This implies a detailed knowledge of all the services to be invoked and the relationship between them. This is certainly one of the reasons why 3GPP SA2 is so reluctant to standardize a SCIM. This is a complex task and for the first time 3GPP would need to write specifications that address individual services, while so far they have managed to only address interactions between the network and application servers.

This also implies that the interface between the SCIM and application servers supports the identification of each and every service located on them. A nightmare.

A typical usage of the SCIM would permit it to invoke an individual service on AS1, then another one on AS2, and finally a 3rd one back on AS1. This would lead to a very inefficient service execution in the context of real time communication, more especially as a network protocol has to be used for all interactions between the SCIM and the application servers. A proper architecture may prevent such a bad service distribution to happen.

Consequently, from an architecture perspective, the SCIM should preferably be co-located with the services it coordinates. If not all services can be located on the server, the SCIM may use a protocol towards the remote servers, but only as an extension to its local duties. In TR 23.810, this would correspond to the "hybrid" case (section 5.3), in which one of the service brokers in an AS would also serve as a service broker towards other ASs.

Addressing Various Application Server Technologies

One of the main rationales given for introducing a SCIM, and this is part of TR 23.810, is the need to coordinate service exection between the different types of application servers defined in the IMS service architecture: SIP AS, OSA Gateway, IM SSF (gateway to CAMEL/IN).

A first question is: how relevant would it be for an operator to deploy these 3 technologies to implement IMS services?

The SIP AS is clearly a must. Most if not all IMS application servers that exist today are SIP ASs.

For me, a legacy CAMEL/IN server is usually the type of platform an operator has little control on, and is far from optimal to implement new IMS services. Even when using IMS initially for telephony, an operator should consider re-implementing telephony services on a new platform, in order to both benefit from advanced IT environments and enable services that do not only mimic the behavior of their circuit-switched counterparts, and can use such IMS/SIP capabilities as forking or presence.

There is one case where I find relevant the intention to access legacy IN services: when IMS is used to extend an existing circuit-switched telephony service towards VoIP. Basically, the user keeps its circuit-switched telephony services, but sometimes happens to use VoIMS instead of VoCS. In this case the same services must be shared between the two networks, and one option if for IMS to access the legacy services.

There are very few mass deployment of services based on OSA/Parlay, and the APIs (more especially call control) are not optimal for IMS. I think that only a few operators really think of deploying Parlay services over IMS, and if they do so, they might decide that they will concentrate their call control services on this solution.

A second question is: assuming that an operator deploys application servers of different technologies, will these application servers share the control of the same sessions?

This is a key question, as the SCIM would only need to coordinate the different application servers if they intend to impact the same SIP transaction, dialogue or session.

In the case where I see using CAMEL/IN for legitimate reasons, I wonder why there would need to be additional services implemented on a SIP AS. Conversely, if services are implemented on a SIP AS, why would there be the need to coordinate with services implemented on a CAMEL/IN SCP? Of course everything is possible in theory, but some options make more sense than others.

Personally, I see little need for a SCIM to integrate different AS technologies. In any case, the standardized AS chaining mechanism of the S-CSCF can provide support to this hypothetical need.

Service Interaction Management

Classical service interaction management is a voice and call control centric issue.

While I do not discuss the fact that IMS will deal with session control issues, both for voice and non-voice centric sessions, I have several arguments that may mitigate the need for standardizing an entity to handle service interaction management.

First, IMS is not a circuit-switched network, and there are IMS features which may permit to lower the need for service interaction management:

- IMS can support phone numbers (tel uris), but the most natural addressing for IMS and SIP is the SIP uri, which is like an email address (e.g. sip:user@domain). This means that many number translation services may not have a long term future in IMS.

- IMS is a multimedia network which will multiply the means to communicate between users. This may impact the need for call management services.

- SIP forking permits the network to search for a user on various devices. This will make some of the existing call control less relevant than before.

- Presence will permit more intelligent call management services, and will certainly reduce the number of services and the need for supporting service interaction management between them.

- IMS services can more easily interact with users, possibly asking them (caller, callee) how they wish to handle a call. This is in contrast with circuit-switched networks, which have poor user interfaces and therefore need to essentially work autonomously.

My point is not to say that the service interaction management issue will totally disappear in IMS, but that it is likely to be less critical than before, and may not require a standardized SCIM.

Another aspect is the following: how much money will an operator make with call control related services? I think that IMS has value only if it can support other services than voice or basic session control, and if the operator must invest money, this is for revenue generating services. For me, IMS will be successful if call management represents a tiny portion of the services it offers. In this context, the effort placed on addressing the service interaction management issue for IMS is out of proportion with its business importance.

For me, the focus of a part of the industry on service interaction management for IMS comes from the fact that technicians have been working on this issue for long, and prefer to stick to this comfortable topic than invest time and effort to address new problems.

And by the way, why would telecom experts now resolve for IMS the service interaction management issue that eluded them for so many years in the circuit-switched network?

Support of Multimedia Services

Some think that a SCIM is needed to support multimedia communication. By adding a SCIM to a push to talk server and an IMS messaging server, you would support sessions that mix both push to talk and messaging media.

Unfortunately it does not work this way. In order to support multimedia communication you need to have the right architecture in the application layer, and legacy monolithic servers need to be re-engineered for this. There is no magic box to change the situation.

Service Orchestration

The SCIM would be used for service orchestration, i.e. for composing different services together.
This is how I see it, but in order to comply a minimum with the entity introduced in IMS specifications, this orchestration must have something to do with the SIP protocol. Service orchestration related to web services, implemented via BPEL or something else, should not be mixed up with what can be done at the SIP level.

In a future post, I will present my view of a SCIM that can add value to IMS.

Christophe