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