The Service Broker / SCIM market

The concepts of SCIM or Service Broker were introduced in 3GPP IMS specifications, but so far have never been adequately defined (I had the opportunity to address this topic several times).

However, this does not mean that there are no SCIM or Service Broker products (or product components) on the market!

Light Reading has just issued a report called Combining Telco Services: The Network Service Broker Opportunity. As they provide a list of vendors they have surveyed for their report, I decided to have a look at what these companies actually provide by looking at documentation available on their web sites. In this post I will summarize my findings, which are only based on my (potentially erroneous or biased) interpretation of usually high level product descriptions.

Call Control / IN Centric Service Broker / SCIM

Most of these products are presented as equally applicable to Intelligent Networks and IMS, which in some cases might mean that the product is an Intelligent Network one that has been upgraded to support SIP, or that the supplier hopes that what is good for IN will also be good for (telephony-centric) IMS.

As described by Aepona, their Service Broker is primarily a proxy Service Switching Function (SSF) between the switch and multiple IN servers (thus permitting service invocation in multiple servers, what a switch is usually unable to do). As an IMS "SCIM", it performs a similar function between the S-CSCF and multiple ASs. Because of its dual SIP/IN nature, the Service Broker can also serve as a gateway between IMS and IN (the "IM SSF" entity in 3GPP IMS specifications).

The description of the AppTrigger's Ignite Application Session Controller (ASC) includes a "SCIM+". Like Aepona's Service Broker, ASC sits between the network and the "application cloud". IMS is explicitly listed along legacy TDM networks that can appear below the ACS, but the figure on the web page does not show IMS at all, only entities of a fixed IP access network. The product supports Parlay X, MAP/CAMEL and SIP. It also supports SIP to IN interworking (IM SSF).

OpenCloud is the supplier of a JAIN SLEE platform, a standardized Java service execution platform that was initially targeted at new generation IN services (IN services implemented in Java on an open platform and possibly using non-call related service capabilities like location or SMS as part of their logic). Such a platform can also support SIP and Diameter interfaces and can therefore be positioned as a SIP AS platform as well. On their page, Opencloud speak about a Service Interaction SLEE (SIS) for IN, and another one for IMS. The SIS supports service interaction and composition. The SIS can also offload an IN server by supporting some IN logic itself (logic as it is based on an IN service platform).

jNetX is another supplier of a JAIN SLEE platform. I was not able to find any information about a SCIM or Service Broker on their site, but if they have one it is very likely to be similar to what Aepona, AppTrigger and Opencloud offer.

I could not find a precise description of Tekelec's TekSCIM Service Mediator. However, as it is supposed to provide a seamless experience to TDM and IMS users, and its IMS role is to manage and simplify complex service interactions, I assume this is more or less the same type of product.

These products often have a clear interest in a TDM IN context, and I think this should be the primary reason why an operator might be interested in them. On the other hand, I am more doubtful about their value in an IMS context, even for the support of telephony services, and this for the following reasons:

- An IMS S-CSCF has the capability to chain several ASs in SIP signalling, so such a feature supported by a SCIM/SB would be functionally redundant.

- Call control Service Interaction Management is an important issue that has never been addressed in a satisfactory generic manner in IN networks, more especially when implemented in a standalone box outside of application servers. Why would this change now and more especially in an IMS context?

- Unless it is used to emulate the TDM network, IMS is a very different type of network, and SIP has nothing to do with INAP or CAP. What is good and necessary for TDM is not obviously good and necessary in IMS.

- Providing added value call control services in IMS is necessary, but it is not what operators will make money with. A SCIM/SB centered around voice-centric call control is by no means the magic box that will solve all operators' IMS related problems.

- The interest of an IM SSF function is questionable. IN platforms are often old and costly, and operators often have to fully rely on the supplier of the platform for developing new services. Is it interesting for operators to extend the life of these platforms for many years by positioning them in their long term IMS strategy? On the contrary, many would prefer to replace their IN servers by new application servers able to control TDM calls as well as IMS ones, and this is exactly what the ongoing 3GPP IMS Centralized Services (ICS) initiative is trying to achieve.

TCAP / Web Services Gateway

Convergin's Accolade WCS SCIM seems to be a gateway supporting translation between TCAP and web services. It is not clear to me if this is only this and if it is limited to TCAP (leaving the task of supporting CAP, MAP or INAP to the application) or if it also supports a direct translation of these protocols to web services.

The first thing to say is that this does not correspond at all to what someone can expect from a product called "SCIM".

The second thing to say is that, whether the name is appropriate or not, this component can be very interesting in an IMS context, when it is associated to an IP-centric service platform, which lacks native support of legacy SS7-based protocols to access legacy service capabilities in the TDM network. This is typically the case of J2EE platforms supporting SIP servlets for IMS, which are offered by well known companies like IBM, Oracle or Sun.

These platforms are ideal to implement innovative IMS applications which can combine usage of SIP, HTTP, Diameter and web services, thus permitting convergence between the Internet, Enterprise IT and the new Telco domains. So far, the lacking capability has been the possibility to conveniently connect with the legacy TDM telco world (OSA/Parlay gateways have not proved to be simple and cost effective enough).

I do not think that such a product would allow a J2EE server to become a suitable platform to implement classical IN services. On the other hand, they could permit to implement new TDM-centric services that make use of IMS enablers like presence or instant messaging, or IMS-centric services that need to use TDM capabilities like starting a pure TDM call.

Consequently, this is not a surprise if Convergin seems to be in business with the J2EE suppliers I mentioned.

SIP-level Orchestration Engine

This is the approach adopted by suppliers of J2EE platforms (IBM, Oracle/BEA, Sun?), which usually clearly distinguish between the need to orchestrate web services, using a standard like BPEL, and the need to orchestrate services invoked through SIP requests. Differences may lie in both semantical and performance aspects.

In this context, the SCIM/SB corresponds to the concept of application router, defined in JSR 289, the latest SIP servlets specification. The original mechanism specified for invoking SIP servlet applications, based on servlet mapping rules that are quite similar to web servlet mapping rules in the fact that they rely on a quite simplistic analysis of incoming SIP messages, has proved to be inadequate for a proper selection and composition of IMS services hosted by a J2EE platform. The application router permits to replace the servlet mapping rules by an intelligent component tailored to the needs of the operator.

The intelligence itself is not standardized, and this is therefore an important differentiation area for suppliers or for operators who may decide to specify and possibly implement their own application router.

The service invocation and chaining logic may take into account subscription information (which services the user is subscribed to) as well as other information related to the user, such as presence, service preferences (e.g. the user wants this service to be executed at certain times) or calendar information.There might also be more or less sophisticated rules related to the composition of services.

The ideas for a SCIM I exposed on this blog fit in this context, with the concern to remain as simple as possible and avoid too much intelligence, complexity and processing delays in this component. I think that the suppliers of J2EE platforms are trying to offer the possibility for more sophisticated rules, adding both more potential and more risks to the concept.

Global Orchestration Engine

This seems to be the case for the Alcatel-Lucent Service Broker, implemented by Bell Labs, which is part of the Alcatel Lucent Service Delivery Platform (SDP). The component supports both SIP and web services interfaces, and examples given illustrate access to user subscription information, service preferences, presence, as well as access to other services like IPTV through web services.*

This Service Broker therefore seems to be an integrated equivalent to the combination of a web services orchestration engine and a SIP application dispatcher as proposed by J2EE suppliers.

A potential reason for this difference is that Alcatel Lucent provide their own SIP servlets container, which is a standalone component that needs to be integrated with a third party J2EE platform for converged services. The service broker would therefore permit integration with J2EE web containers (integration which is much tighter in J2EE platforms supporting both web and SIP servlets) and would transfer web services orchestration to the Alcatel Lucent SIP-centric component as well.

Such an approach might offer advantages, more especially in terms of performance, but could also come with associated complexity, a lack of compliance to web services orchestration standards, and the gain obtained through a tighter integration of different orchestrations may also lead to less flexibility for the operator. However, this would be an aspect to investigate.

Service Management Mediation

Leapstone's CCE ServiceBroker is a tool that applies both to legacy networks and IMS. It aims at making easier the management and provisioning of packaged services, including subscriber management and live management of composition and interaction rules between blended services.

From an IMS perspective, this means that the operator may use serviceBroker to define service composition rules and to generate appropriate data for an HSS (Initial Filter Criteria) and a SCIM, as well as for other network databases.

As such, ServiceBroker appears to be a management complement associated to what is usually called a SCIM or Service Broker. More generally, this is a service and subscriber management mediation tool as can already be found on the
market, but enriched with IMS-specific service composition requirements.

Such a tool is very important but also requires ad-hoc adaptations in order to fit in specific environments, considering that management interfaces are usually vendor-specific. Concerning the SCIM/SB, this is even worse as this component is not standardized and leaves room for very different implementations, as can be seen in this post.

Other SCIMs / Service Brokers

Considering the list provided by Light Reading, I was not able to find anything about the Ericsson and Huawei implementations of the concept.

Conclusions

The concept of SCIM / Service Broker, which is part of IMS specifications but has never been specified, leaves room to multiple interpretations and very different products claiming this label can be found on the market.

You can basically find two mainstream interpretations:

- The SCIM / SB is a standalone component that takes care of classical call control and IN issues related to the support of multiple application servers and complex interactions between call control services. The concept is primarily aimed at legacy networks and is also promoted as being equally applicable (and important) for IMS. The telephony context is clear and while everyone can have its own opinion on the interest of such a product for IMS, I will assume that no-one can seriously claim that this component will help an operator finding new sources of revenue with IMS (the key term here is "leveraging", applied to TDM and IMS in the context of telephony).

- The SCIM / SB is a component part of a service delivery platform, and its aim is to complement what the IMS core network component called S-CSCF can do for the composition and "blending" of several services. Such a SCIM / SB can be specialized in SIP-level orchestration (a dedicated engine will do the equivalent for web services) or can address both SIP and web services orchestration.

The first interpretation is closer to the initial motivation for introducing the concept in 3GPP specifications, while the second is closer to what the real IMS need actually is.

A major architecture difference between the two interpretations is that the first one is a standalone product standing between the IMS core network and application servers, while the second is an added-value component of a more comprehensive product usually called service delivery platform in the telecom context (an application server in its own right).

The description I made of a SCIM on this blog is essentially one of the second category. However, since then I thought a little bit about what a standalone SCIM / SB could be, in the terms of which value it could provide to a SCIM / SB embedded in a service platform can do.

I cannot divulge here the content of these thoughts, as they are being discussed with a customer company of Arismore, but to make it short I think there is a lot of added-value a standalone SCIM / Service Broker could add to a service platform -embedded one, while being very different from what the market has to offer right now. More especially, such a product would have no relationship to IN and call control.

If you are knowledgeable in some of the products I surveyed in this post, do not hesitate to contact me in order to correct or complement it. I will gladly compile and post feedbacks, including those that make a point against my assertions.

Christophe

Here is my SCIM

I am far from convinced that the SCIM, as it is usually promoted by suppliers, or as it is currently being standardized by 3GPP under the name of Service Broker, is an essential feature for an IMS that does not limit itself to the reimplementation of legacy telephony over IP.

It can be argued that what I am going to describe in this post is not a SCIM. I would prefer to give it another less ambiguous name, such as Service Dispatcher (Service Broker is already taken). The concept was already discussed with a big IT supplier, and may eventually be implemented as part of their service platform.

Personalized Service Chaining

For me, one of the great features of the IMS service architecture is the possibility to chain services on the SIP signalling path and to have this chaining personalized for each user.

IMS service chaining is based on service profiles, stored in the HSS, and associated to IMS Public User Identities (IMPUs). In practice the same service request originated by or addressed to two different IMPUs can be chained totally differently for each of these IMPUs. The two IMPUs may either be associated to different users, or may implement different personas for the same user.

Service chaining can be very interesting for composing IMS services. There might be several cases (see also this post):
- Two chained services may exert control on the same end-to-end SIP transaction or dialogue, without having to be aware of each other. This is for instance the case when a voice call continuity service (VCC) is composed with other session management services. As long as VCC and the other session management features are chained in the right order, end-to-end behavior will remain consistent. In practice, many typical service interaction management use cases can be solved through a proper chaining of services on SIP signalling.
- A service may impact end-to-end signalling with the knowledge of how service logic further down the chain will react to the change.
- A service may initiate new SIP interactions as a consequence of being in the SIP signalling path (e.g. send an IM to a user)
- A service may monitor SIP signalling without any intention to impact it (e.g. a messaging archive).

It is important to note that service chaining on SIP signalling is very interesting, but is not the panacea to address all service composition use cases. More especially, it may need to be complemented with more classical web service orchestration higher up in the service logic.

Need to Complement S-CSCF Service Chaining

I do not support the opinion that the current specification for service profiles (initial filter criterias) and for service chainiing by the S-CSCFare too limited and should be extended to handle more criteria such as time or presence information. I find that the current mechanism is both efficient and reasonably simple. If more advanced mechanisms are necessary, they should be implemented in the IT-centric application layer, possibly in the SCIM.

On the other hand, taken in isolation, S-CSCF -based service chaining is not enough, and it has the following issues:
1) It may lead to a heavy processing by the S-CSCF of SIP interactions with application servers, in addition to the other tasks it already has, i.e. virtually doing everything in the IMS core network (e.g. user registration & authentication, end-to-end SIP routing, generation of charging information, etc).
2) Multiple SIP based interactions between the S-CSCF and application servers may lead to bad end-to-end latency for service delivery. These latency issues may potentially lead the operator to limit service chaining for the sake of service usability.
3) Chaining actually concerns application servers, and not individual services hosted by each of these application servers.

Issues #1 and #2 should be addressed via service co-location. It should be possible for an operator to co-locate on the same server, for a given user, services that are likely to be chained together or that generate other SIP interactions (e.g. presence based service accesses presence).

This requires a change of mindset for service topology from a service centric to a user centric approach. Instead of having a server = service(s) approach in which, for instance, presence is implemented a dedicated server aiming at serving all users, personal services should be deployed as much as possible according to a server = users approach. In this context, presence, which is the prototype personal service, could be implemented as an application co-located with other applications using it as an enabler, on application server instances each serving a subset of the users.

Such a service co-location approach reinforces the need for the adoption of standard and open IT-centric service platforms that I already mentioned.

#3 requires the possibility to chain services together at a finer granularity than the S-CSCF, and to do it inside the application server itself. Service co-location makes this need even more essential.

Main Features of the SCIM

In this context, the SCIM performs in the application server, and at service level, what the S-CSCF does in the network and at application server level. Its role is therefore to select and chain the services that need to be executed when a SIP standalone or initial request reaches the application server.

The SCIM exploits and complements the IMS capability to have a personalized chaining (composition) of services on the signalling path associated to a SIP request. Of course, SIP requests may relate to a large variety of services, and are not limited to telephony or even to session control.

The SIP chaining mechanism of the SCIM is very similar to the one supported by the S-CSCF. The user "service profile" used by the SCIM might have similarities and differences with the initial filter criteria of the service profile used by the S-CSCF. All potential enrichments desired for chaining decisions can be implemented at the SCIM level.

The SCIM is one of the orchestration mechanisms supported by an IMS application server, which is SIP centric. Web Services oriented service orchestration is to be supported by a complementary component of the platform.

The platform is typically implemented as a JAIN SLEE or Java EE (J2EE) server supporting SIP servlets. In the latter case, the SCIM can be implemented as an application router in JSR 289.

Such a SCIM aims at enriching the user oriented nature of the IMS service architecture and at providing a highly customizable and differentiated service experience between IMS users. At the same time, it can fulfill many typical service interaction management use cases that are targeted by service broker standardization.

Other Potential Features for the SCIM

I like the idea of keeping a SCIM well focused and simple enough to be managed. However, the core functionality described above can be extended directly in the SCIM, or through some complementary components added to it.

Here follow some examples.

An IMS application server needs to follow some rules when interacting with the IMS core network. For instance, when a service initiates a SIP request out of the blue, it needs to include relevant information such as a an original ID for the SIP dialogue/transaction or a charging vector, and it may be mandated to route the request to a specific S-CSCF when this request is initiated on behalf of a user. This task may be handled by the SCIM, if it is not by another component or by the application itself.

As part of its service selection and chaining task, the SCIM may forward a SIP message to remote application servers. By doing so it partly takes over the responsibility of the S-CSCF and permits to offload the IMS core network from a part of application layer related SIP interactions.

A remote application server may not comply with IMS extensions to SIP, and may therefore not be able to exploit them (for instance, a non IMS application server may not be able to extract the asserted identity of the request initiator from the 3GPP specific P-Asserted-Identity header). In this case the SCIM may adapt SIP messages between between IMS and the non-IMS application server.

A remote application server may belong to a 3rd party service provider. The SCIM or a complementary component may support policies for interactions with this 3rd party.

The SCIM may possibly translate SIP requests into web service requests or other application-related interfaces.

July 6th 2007 update: I made another post on this subject, with figures.

Christophe

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