Susie had been using Instant Messaging (IM) with her wireless carrier for eight months when she decided to add Push To Talk (PTT) as well. While she was quite happy with the first service, and had heard many good things about the second service from her friend, she was not at all satisfied with how the two services worked together—or rather didn’t work together. “Why do I have to input my contact information twice?” she asked the customer service rep for the third time in as many days. She did not get a good answer from anyone she spoke to about it. Little did she know that her IM and PTT services, based on a Next Generation Network (NGN) framework called the IP Multimedia Subsystem (IMS), simply don’t work together the way they should. The network interactions between the different application nodes are too complex without SCIM mediation and the applications also do not share the same presence information or group address list. These issues should, of course, be transparent to Susie. All she knows and cares about is that she does not want to input information more than once.
One little known network element crucial to the success of IMS, and thus to the future of NGN communications, is the Service Capability Interaction Manager (SCIM). Its role is to provide service orchestration and brokering between the IMS networks elements, leaving core functionality such as the Call Session Control Function (CSCF) to focus on signaling mediation between the network elements. While many early IMS-based applications will not require the SCIM, it will be vitally important for the network operators to deploy an SCIM as part of their IMS deployments or risk service problems as they add multiple applications. This is due to the fact that the IMS-based applications require complex and interdependent interactions between various network elements, often involving ad hoc multimedia attachment to media with various protocols and Quality of Service (QoS) requirements.
In many application scenarios, special logic may be required to handle certain message sequences. For example, multiple SCPs/Application Servers are registering for notification of certain events in the network. These have to be aggregated during the registration time and de-aggregated and sent to appropriate Application Servers/SCPs when the event is generated by the network. Example in GSM is handling of RRB and ERB when SCIM is appearing as a single Virtual SCP to MSC and connecting to multiple SCPs. All applications that use RRB and ERB will need this type of logic. Suffice to say that service interaction is a complex issue that becomes even more complicated when a generic solution is provided that is service transparent (i.e., service logic is not pre-known and must be discovered as part of the service mediation process). For this reason, bundling SCIM type functionality inside other network elements such as the MSC, STP, SCP, CSCF or App Server is not recommended.
It just so happened that, about two months after a different wireless carrier implemented SCIM functionality into its IMS infrastructure, Susie was talking to a friend who used IM, PTT and a new service called dynamic address book. Her friend, Rick, said that the service worked well. “It’s great! I only input my contacts on the Web and determine who is related to which service and what permissions they have to communicate with me. That’s it!” Rick showed Susie how easy it was to use. She signed up with the new carrier the very next day. Her old carrier never even knew why she had left. Had they understood the problem in the first place, she might have still been with them!