Service Capability Interaction Manager
From Wikipedia, the free encyclopedia
 |
The introduction to this article provides insufficient context for those unfamiliar with the subject. Please help improve the article with a good introductory style. |
A Service Capability Interaction Manager (or SCIM) orchestrates service delivery among application server platforms within the IP Multimedia Subsystem architecture.
The Service Capability Interaction Manager (SCIM) was introduced in 3GPP TS 23.002, Figure 6a: Functional architecture for the provision of service in the IMS as a function within the "SIP Application Server" domain of the IMS architecture. Although there is only a small amount of text in the 3GPP Release 6 specifications describing this function it is clear that it is intended to be a placeholder for an obviously necessary but vendor-defined solution to a common problem: orchestration of interaction between "Capabilities" in the larger network which are represented as SIP Application Server instances.
In practical terms, a "capability" is a system component that may be used (presumably with other components) to implement a "service" that is packaged and delivered to end users of the network. For example, a group list server and a presence server may both be considered "capabilities" that are used to implement a sophisticated conferencing service.
The implementation of a specialized SIP application Server (or feature of one) that qualifies as an SCIM is somewhat challenging, however. The issue is not the technologies or expertise required - in fact this is almost impossible to even evaluate. The real issue is the lack of a standard definition of the types of service capabilities that must interact. In practice, most commercial networks are already comprised of a number of existing systems built according to standards and with technologies that pre-date the IMS. In some cases, service providers expect those capabilities to be available to newer IMS services. In other cases, service providers may already have chosen IT-centric technologies to implement capabilities that should be re-used in an IMS context. What seems fairly obvious at this point that the term SCIM actually refers to an entire class of functions and not to a single implementable solution to this fairly broad problem. What could be inferred, though, is that there are likely a few specific types of SCIM that can be identified. Bear in mind, of course, that this is a subjective categorization based on contact with service providers and there are many grey areas.
Some possible types of SCIM:
AS Internal Function - SCIM that are implemented as request dispatchers within the local execution environment for service logics. This type of SCIM is merely a reference to the ability of a SIP Application Server to selectively invoke specific service logics based on the nature of the SIP request. In the case of the SIP Servlet API, for example, the SIP Servlet Container uses Servlet Mapping Rules declared in the deployment descriptors for the applications to select the specific Servlets which will be invoked to receive a given SIP Request Object (and in which order). Most SIP Application servers will use a similar mechanism for selectively invoking components, although these will generally be proprietary and tightly coupled with the implementation technology in use.
SIP Broker - SCIM that manage interaction between components that implement SIP proxies or user agents. This type of SCIM is likely the most intuitive to network architects focused on the problem of multi-vendor service delivery platforms designed to maximally exploit the full capabilities of the signaling system (control plane) of the network. These implementations generally involve the use of Back-to-Back (SIP) User Agents and complex routing and sequencing rule engines (often somewhat similar to the Serving Call Session control Function itself in many ways).
Service Brokers - SCIM that manage interaction between service capabilities that are exposed using WSDL and SOAP-based abstractions of the IMS network. This type of SCIM necessarily involves abstraction of the SIP protocol. SIP is the IMS service Control (ISC) interface used between the core network (Serving Call Session Control Function) and the service capabilities in point. Since SIP is not generally translated directly into SOAP messages (for a number of reasons this is neither practical nor desirable) it stands to reason that the invocation of component service logics is based on an abstract view of the underlying network more appropriate to session-ess, message-passing. These types of SCIM generally model interaction between services as business processes.
Legacy/NGN - SCIM that manage interaction between SIP features and legacy signaling system components. This type of SCIM is potentially the least well understood as a "generic" solution, since the specific legacy interfaces needed vary widely between Circuit Switched core network implementations (from region to region and vendor to vendor). In legacy networks, features such as voicemail, call display, call forwarding, etc. are implemented on vendor-specific switching platforms and generally support INAP or CAMEL interfaces. These types of SCIM generally include a protocol mapping function in addition to a triggering and routing function. These types of SCIM are often tightly coupled with the legacy feature implementations and often this type of SCIM is embedded within legacy Feature Servers.
Service-Type Optimized - SCIM that are optimized for a particular type of service, rather than a particular set of implementation technologies. Another approach to the SCIM seems to be gaining some prominence, particularly amongst the traditional Network Equipment Providers. In the interest of improved signaling efficiency the SCIM is integrated with components which support the signaling procedures common to a given type of service. For example, a telephony SCIM would be integrated with generic implementations of components which support the standard procedures for negotiation of media types, control of media servers for telephony, call transfer, call waiting, call hold, add/drop media and so on. These components are then exposed to other components via protocol-non-specific interfaces through which additional service logic or content is introduced that allow the service to be customized. This approach is based on an observation that there are often distinct differences between workflows for full-duplex media sessions, half-duplex media sessions and messaging sessions and further presumes that these types of sessions to not evolve into one another during typical use of the system. In such a case, a telephony session may include the ability to add or drop participants, but it will likely never become a full-fledged conference. In this case, a group of colleagues sharing an ad hoc call could agree to move to a conference bridge and thereby start an entirely new session which would (beneath the covers) involve a completely different SCIM function and set of applications.
For each of these different SCIM types, and for the general notion of the SCIM, the problem which is most difficult is the lack of a clear component model for the IMS. Although, as I have noted previously, the IMS does offer many clues and suggestions in a case-by-case way, there is no real clarity around what a typical component should be and how they should therefore interact. SIP does offer a powerful routing capability that allows for an aspect-oriented approach to application composition in some cases. This capability is heavily exploited by the IMS reachability subsystem (the Home Subscriber Server and Call Session Control Functions) as a means of separating operational system aspects from the functional system aspects relevant to any given application implementer or user. This chaining of components is very useful but it is not truly sufficient for all cases.
An interesting observation that can be made about this list is that the types of SCIM functions (with te exception of the 'Service-Type Optimized' variety) seem to parallel the different types of Application Support functions and Application Servers introduced as part of the IMS architecture illustrated by TS 23.002, Figure 6a: Functional architecture for the provision of service in the IMS. This implies that, to some extent, the relationship between the Serving CSCF and the different AS types may not be sufficiently clear in the base 3GPP Release 6 specifications. This uncertainty, coupled with the obvious need for an SCIM of one type or another in virtually every IMS deployment, greatly increases the relative value of a flexible implementation technology for both service logics (features or components) and potentially for the Serving Call Session Control Function. In fact, in smaller IMS or IMS-like deployments, it may be sensible to group many of the functions of the SCIM, Serving CSCF and Application Server containers together in a single implementation.
While there remains a good deal of uncertainty about the exact direction that the industry will take in the long term, an application-middleware approach to the problems of component implementation and interaction may offer the best overall balance of cost, flexibility and efficiency. In many cases, particularly in the near and medium terms, the ideal solution to the challenge of the SCIM will be the implementation of all related functions (Serving CSCF, SCIM and service components) using a common programming model and shared execution environment.
The substantial differences between the needs of different communications service providers, both in terms of the technology employed and the business problems being addressed, make it unlikely that our industry will arrive at a real consensus any time soon. While the debate within the industry about the exact nature of the SCIM problem is likely to continue for some time, there is certainly no shortage of need for products which solve it in one way or another.
