Wednesday, May 9, 2007

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

12 comments:

Anonymous said...

Hi !
I just found your blog and read it from the start up until now...great reading, clear and concise...please more !

Thanks

Christophe Gourraud said...

Many thanks for the kind words. This is really appreciated.
Christophe

Anonymous said...

Great reading. Thanks. Just as an aside - where would you put AS load balancing and failover. Do you see the need of a layer in between the S-CSCF and the AS or is this strictly an AS function. Also what do you see as the typical ratio of S-CSCF to AS. Is that a 1:m or a n:1 relationship or would it be a (m:n retlationship i.e many S-CSCF's interacting with many As's. Thanks.

Christophe Gourraud said...

Hi,
The user-centric nature of the IMS service architecture, which permits to distribute subsets of users to different AS instances, already provides a load balancing mechanism.
Otherwise, the open service platforms I have seen so far from major IT vendors have load balancing and failover support as part of their design.
Finally 3GPP TR 23.818 (that you can access from the link to the 3GPP spec matrix on the side) has in appendix C a set of approaches that can be used for this as well. The approach in C4 would make use of a "representative AS". Personally, I like the proposal in C5, which uses DNS and AS address caching in the S-CSCF. It can easily be used for supporting load balancing and failover as well.
Hope it answers your question.
Christophe

byte1 said...

Hi

byte1 said...

I just found this site. It provides very good information. Very rarely do I get information that addresses more than one point of view. Your articles incorporate the standards, business needs, vendors, and providers points of view amongst others in a well thought out manner.
Will be recommending this site to others.

Christophe Gourraud said...

Thanks a lot for your kind words and for the support.
Christophe

Anonymous said...

I am inline with you all the way except your statement about "implementing a service chain of a user in dedicated AS" to overcome latency etc. In my understanding this is return to "Stone Age = IMS in a Box" days. "Enabling multiple services across multiple AS(s) , specially from different vendors " is one of the biggest goals of IMS. Anyway this is me :-)

Christophe Gourraud said...

Hi fenar,

You are right, but my point should not be caricatured either.

I totally agree that the possibility to have a multivendor application layer with the possibility to chain several ASs from different vendors in the SIP signalling path is a great advantage of IMS.

On the other hand, if I need to chain 5 services in the signalling path, it may be good to have, say 2 ASs to chain instead of 5. This implies that several services are co-located on an AS, instead of having one AS per service. The SCIM may be useful in this case.

This has to be considered more especially when you start to think about non-standardized innovative services that the operator would like to purchase as applications (not boxes)to be deployed on standard service platforms like J2EE or JAIN SLEE.

Christophe

Unknown said...
This comment has been removed by the author.
Unknown said...

Hi,
I'm studying about Service Broker and SCIM, and your posts about IMS, SCIM is much useful for me, many thank for your post. Could you help me a question ??? What is function of SCIM when blending two service in same application server, two service in two application server at same domain and the third case, two service in two AS at two domains... And in each case, what is defference. Thanks.

Jeanna said...

I saw really much worthwhile info in this post!