About 2 years ago I did a couple of projects around the SCIM (Service Capability Interaction Manager). It’s an illusive component within the IMS (IP Multimedia Subsystem) standards, because it’s only described in one paragraph of the 3GPP R7 (3rd Generation Project Partnership Release 7) standards issued earlier this year. The SCIM isn’t standardized, it’s mentioned. The SCIM enables service logic across multiple application servers to be combined, e.g. a customer is on a video call and during the call wants to record the voice for ‘speak to text’ conversion.
As I read the current marketing materials appearing on SCIM you’d think it was a critical mature component, essential to implementing any type of Web2.0 mash-up within an IMS framework. A Web 2.0 mash-up is combining data and applications from different sources to create a new application. If you want to find out more, check out some examples at this Web 2.0 list website.
In examining the SCIM market you find three groups of suppliers claiming they do it, i.e. application servers (e.g. Ubiquity), stand-alone SCIMs (e.g. Convergin) or S-CSCFs (Serving – Call Session Control Function) suppliers (e.g. Ericsson). And then when you scratch the surface a little more you find another three adjacent groups: i.e. legacy services interaction managers, service brokers and SIP (Session Initiation Protocol) service interaction managers. Here you find suppliers such as AePONA and jNETx. So is the SCIM a software module, an independent network element, a specialized application server, and is it IMS / IP / SIP / legacy centric?
Many IMS courses and books do not even mention the SCIM. If an operator has a single vendor application server supplier they may not require a SCIM. However, it would appear essential if the operator has a switch and SCP (Service Control Point) from different vendors, or if the oeprator has an existing SIP infrastructure they need to migrate to IMS, or if they want to re-use their legacy service logic, or if the operator wants to use 3rd party SIP applications.
In addition the SCIM can be used for conditional service invocation. For example, your schedule says you’re in an internal company meeting, so when you’re in a meeting call completion is dependent upon who is calling (priorities could be set in either your user profile or address book). The SCIM enables multiple data sources to be brought into the routing decision, making your communications work better. The SCIM can also intercept messages to implement different classes of service (business and economy), and enable convergence between Service Management and the SCIM; enabling customers to self-provision new capabilities and services. The SCIM has a much broader scope that just enabling service logic across different application servers in IMS.
The SCIM would appear to be at the nexus of legacy infrastructure, the SDP (Service Delivery Platform) and IMS. Should its standardization sit within 3GPP, or within a supplier group such as the SDP Alliance, or should multiple incompatible solutions be produced to let the market decide?
Standards bodies are creating reams of complex standards, IMHO standards engineers should only ever serve a term of one year to avoid standards being created to keep themselves in a job. Some standard are way ahead of the reality in operators networks, e.g. some operators are struggling to upgrade their networks to 3GPP R4, while R8 is currently being defined. Earlier in my career I helped set up the FSAN (Full Service Access Network) initiative. A small group of operators that successfully specified the PON systems being deployed today by operators such as Verizon for their FiOS deployment.
My recommendation is a small group of operators need to get together and define a common strategic services roadmap to set the requirements, and based on those requirements specify a vastly simplified services layer. Else operators are currently running a serious risk of missing the last best chance to avoid commoditization into bit-pipes.
Although the article in this page is quite old information, I felt compelled to say that I disagree with you regarding the standards groups. Folks in those groups are not around to just keep themselves employed, they actually do care and want to produce quality and USEFUL standards. After all, their names are attached to them!
Hi, thanks for your comment. I agree the people involved do want to produce useful standards. However, without clear market requirements its hard to do what is really required. And similarly it is hard for the marketing people to define what is really required. I have worked in many telco standards groups and there are too many academic arguments and vendor politics for them to be effective. Telecom needs to redefine how it creates standards, the ivory tower of the standards group is no longer appropriate. For example, the I,C,S CSCF today really doesn’t make sense for IMS, yet the standard remains difficult to adapt. We must look to the internet where people are more willing to experiment and discover what works best in the market, then create industry norms, and allow adaptation as technology and markets change. Its a more evolutionary process where there’s lots of variations and the most appropriate survives to mass market success and continues to adapt; rather than a grand design created by a standards group. Also standards involvement should have term limits, there are too many career standards people in telecom who lack customer facing experience in my opinion. Alan