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

Standardization: SCIM & Service Broker

Here is a first post of a series dedicated to the SCIM concept, which is part of IMS specifications.

In this post, I will describe how the concept was introduced, how it has been handled and actually how it is currently being addressed under a new name: Service Broker.

The SCIM

SCIM stands for "Service Capability Interaction Manager". This entity was first proposed in 3GPP in April 2001, in a contribution made by one of the major telco suppliers.

The purpose of the SCIM was "service capability coordination" (nothing more concrete). The contribution proposed the SCIM as a standalone entity located between the S-CSCF and the IMS application servers. It interfaced with the S-CSCF and the application servers through the same SIP+ reference point (which would later become ISC). Reasons given for its definition as a separate entity from the S-CSCF were that it logically belonged in the application layer and that, unlike the S-CSCF, it would use non standardized data to perform its duties.

This SCIM was clearly derived from the "service interaction management" issue, which is well known in Intelligent Networks, and deals with the coordinated execution of potentially conflictual call control -related services (e.g. call forwarding and call screening). The new IMS entity owed its name to the fact that 3GPP had just decided to standardize "service capabilities" instead of "services".

The contribution caused a little bit of trouble, as service interaction management is considered as a serious matter in telecommunications, and cannot be dismissed like that. However, other vendors did not want to start standardizing a SCIM in 3GPP, maybe because of the complexity of the issue, or because some already felt that IMS was not simply a voice-centric network.

The result was that two of the other vendors proposed to move up the SCIM in the service architecture, and instead of defining it as a standalone entity, they managed to get it located inside of the SIP Application Server. In a standardization body whose role is to standardize boxes and protocols between them, placing a box inside another box is a simple and diplomatic way to kill it from a standardization perspective.

As a consequence, the standardization of the SCIM was limited to a few fluffy sentences in a couple of 3GPP specifications. The SCIM could then be forgotten.

However, years later, as the IMS hype started, some operators started to ask for SCIMs, and some suppliers started to propose something called "SCIM".

It seems that, as the IMS application layer was under-defined, the SCIM became for some the magic box that would answer all the unresolved questions. This is to the point that there exists a Wikipedia entry for it (July 3rd 2007 update: the SCIM definition has been much extended since I originally wrote this post).

The Service Broker

At the begining of 2005, a new work item for 3GPP R7 was defined, which aimed at specifying a service broker in the context of OSA/Parlay, in order to "enable detection and resolution of service interaction". The work item proposal mentioned that the service broker could also support the IMS SCIM, but this was removed from the final version. However, the technical report initiated by 3GPP CT5 (OSA/Parlay) stated that the service broker "should be able of brokering non OSA applications, such as those hosted by a SIP AS and/or legacy services." In clear, the intention was to standardize the SCIM, and to make it part of an OSA/Parlay solution.

As an entity under the control of a group dedicated to OSA/Parlay, the service broker had no chance to be accepted as a SCIM. IMS is standardized by other 3GPP groups, and more especially 3GPP SA2 for its architecture. Some of the companies supporting the service broker therefore proposed to extract it from CT5 and to have it standardized by another group. 3GPP SA2 was reluctant to standardize it (same situation as in 2001 for the SCIM), but was asked to proceed.

The sample use cases given to motivate the need to standardize a service broker for IMS were totally voice-centric, thus clearly positioning the service broker in the same "service interaction management" context as the initial SCIM. I personally found that the use cases were artificial and exhibited a lack of knowledge of how the IMS service architecture works.

Progress on the service broker, documented in TR 23.810 as part of 3GPP R8, has been quite slow until now. At the time I am writing, the content of the TR (version 0.4) is still very high level, and nothing ensures that it will lead to anything concrete. The TR systematically refers to "SIP sessions", and the only example given is totally voice centric (freephone, voice activated dialling, call barring). Different architecture alternatives are given, including one (service broker in AS) which could lead to the conclusion that 3GPP should not further standardize the concept.

I am personally concerned when I see 3GPP devoting so much effort (OK, maybe not that much) to standardize a function without a clear understanding of the problems it is supposed to solve. There already exist parts of 3GPP specifications which are useless, and I would not be surprised if the service broker was also one of these, assuming that the current effort leads to a concrete outcome.

An example of dispensable 3GPP concept is the "subsequent filter criteria". sFCs were introduced at the same time as initial filter criteria (iFCs) and in theory permit an application server to dynamically set filter criteria in the S-CSCF after having been triggered through initial filter criteria. sFCs are the equivalent to dynamic triggers in IN, that permit an IN application to dynamically set new trigger points in the switch. The only problem with subsequent filter criteria is that they do not make sense with the decision to base ISC on SIP, because the concept is incompatible with basic SIP routing mechanisms. Though introduced in 3GPP R5, subsequent filter criteria have never been standardized and are likely to never be. I am citing subsequent filter criteria because the TR for the service broker mentions them (section 5.2), which seems to confirm the IN culture of contributors to the concept.

In the next post I will expose why I do not like ideas usually associated to the SCIM / Service Broker concept.

Christophe