Unraveling SCIM for IMS

Implementing a solution drawn from standards-based specifications often exposes some gaps that are left to the creativity of the implementers. This classic gap often is perceived as a consequence of a difference in thinking between researchers and practitioners. However, in reality, there are three factors contributing to this. First, because of the long, drawn-out standardization process, it is always a challenge to put a complete solution on paper. The other two factors are advances in technology and changes in market needs – both of which are likely to happen before the standard becomes implemented.

The Service Capability Interaction Manager (SCIM) is one such example of this classical chasm. The early IMS standards briefly mentioned this but did not define any details. Now this has become more prominent as we move from proof-of-concept solitary IMS applications toward deployments that rely upon multiple service interaction. The problem is still the unsolved feature interaction reminiscent of the early IN days.

The IMS reference architecture, based on best-of-breed telecom solutions, supports separating the service plane from the control plane. This offers the extensibility for new service logic without an impact to the CSCF (Call Session Control Function). There are two options for the service environment: services that are being developed from scratch and traditional or legacy services. We see a new generation of services that are purely SIP-based or that co-exist with legacy services, where the service providers have a significant investment. Four scenarios that call for the SCIM are outlined below.

The foremost driver for the SCIM is Combinational Services. One of the benefits that IMS promises to offer is a new and unique user experience.

The reference architecture is intended to provide a rich set of multimedia services. As service providers get a better grasp of monetizing multimedia, the excitement is growing about how to blend services, as opposed to simply bundling them. This paradigm was fairly limited with traditional voice-based telecommunications.

The consumers now are expecting Internet-like services on mobile devices. Consider an analogy to a mashup (a Web application that combines content from more than one source) on a Google map that extends the value of a plain satellite image and a street address lookup. Augmenting that with a push-to-talk feature to invoke a session with a pizzeria gives the consumer a new experience for replacing Yellow Pages.

Continuing the same line of thinking to further illustrate, blending the potential of IPTV with location, messaging and presence services creates a potential for services beyond text-based televoting. What this pushes for is a more intelligent element to control a set of disparate services. This takes us to the next point, which is to better understand why the current scheme has its own limitations.

The second push for the SCIM is the limitation of the Initial Filter Criteria. Service invocation in the IMS is done by a trigger mechanism (which bears similarity to the IN world). The Serving-CSCF (S-CSCF) obtains the Initial Filter Criteria (IFC) from the HSS (Home Subscriber Server) for a registered subscriber. When the subscriber sends a SIP command INVITE, for instance, for the multimedia session that one is requesting, the S-CSCF cascades through the IFC and sends the invocation to the necessary application servers based on priority. While the S-CSCF has been enabled to invoke multiple sessions in a sequence, even fork them, it is assumed that once the control is handed over to an application server, it will be the responsibility of the application server to coordinate with other services.

Here is the problem. To implement a service that requires combinational services, such as starting a push-to-talk session from a Google mashup as described earlier, the control must shift between the two applications dynamically under the direction of the user. This also exposes the issue that the IFC can cascade through services, but does not allow interleaving on a dynamic nature.

The third point that builds the case for the SCIM is Legacy Interworking. For service providers, IMS is a great vehicle for lowering capex and opex and for building differentiated services for future communication networks. However, the challenge for them is to harness effectively the substantial revenue-generating service infrastructure both within their network and externally, such as messaging, voice mail and location.

Adding to this, the initial IMS vision of only CAMEL (an ITU services standard) services (or OSA) representing a vast legacy infrastructure also falls short. The CDMA networks are not CAMEL-based, but use WIN instead. Apart from roaming and prepaid, few CAMEL services have been deployed. So how would a service provider leverage an investment in, say, a ringback tone platform or in a network-based location infrastructure?

And orchestration between the new generations of services requires both. For instance, sending an SMS message while watching “American Idol” on IPTV can be done by the click of a button, but it requires that the application server understands that an SMS gateway needs to be used to send the message. So should IMS push the burden of network technology awareness to application server platforms or instead provide a platform to invoke the services in a more agnostic manner?

And finally, there is the convergence with the Internet. There are more than a billion Internet users, and they have come to expect Internet services on their mobile devices.

This, again, calls for the ability to orchestrate between Internet access and other services. So do IMS application servers have centralized access mechanisms for Internet services, or does each one have its own interface? In other words, does all the presence access get centralized or do specialized services access the Internet with their own interfaces?

Given this discussion, the nature of the problems to be solved now requires the Service Capability Interface Manager (SCIM). This is not the true SCIM that was conceived of five years ago, but certainly seems to be what is now needed. In order not to offend the purists, let’s call this functional element the Enhanced SCIM, or the E-SCIM.

The E-SCIM can be perceived as an application server platform that has the ability to route, broker and deliver to specialized application servers. To the SCSF, it simplifies the execution logic of the IFC by interacting with a single entity and follows the design tenet laid out of pushing control to the application server, which in this case is the E-SCIM.

Therefore, the broad functions of the E-SCIM are to provide the following:

• Registration of services
• Invocation of services
• Brokering between services
• Cascading through services by static rules
• Cascading through services through dynamic user interaction
• Routing and load balancing between homogenous application servers
• Providing a user identity for application server-invoked services.

The implementation of the E-SCIM can be done with the servlet or a similar model, where servlets can be invoked through a rule-based engine. The more challenging part is to gauge the interfaces to various application servers. The natural choice is to extend the ISC interface toward the application servers as well, which provides a homogenous view to both SIP and legacy servers. Service requests from an application server may require support for additional mechanisms that need further analysis. A servlet having the ability to handle such requests from SOAP could be an option. It would be ideal to contain this within a SIP interface.

Having seen the need for such a functional element, let us examine how it will fit into the architecture physically. Posing this question to implementers will lead to different results.

A SIP application server platform vendor such as BEA, IBM or Ubiquity may benefit by extending this functionality within its platform. A softswitch vendor enhancing its offering to IMS may opt to implement this function as a part of their feature server. A wireless core network infrastructure provider such as Ericsson, Lucent or Nortel may choose to implement it as a separate physical element.

Regardless of the implementation approach, the service providers are giving this function a major thrust, as the timelines for the IMS rollouts draw closer.

Arun Handa is CTO for IntelliNet Technologies, a provider of next-generation network convergence and application development solutions for PSTN, cellular, wireless and IP Multimedia Subsystem (IMS) networks. He can be reached at ahanda@intellinet-tech.com.

Share this article: Email, Slashdot, Digg, Del.icio.us, Yahoo!MyWeb, Windows Live Favorites, Furl
Add this article feed to: RSS, My Yahoo, Newsgator, Bloglines