How to Keep IMS from Becoming Yet Another Silo

In addition, many players also are trying to determine whether IMS’ initial purpose should be to facilitate fixed mobile convergence, support next-generation services, or both.

While concentration on these issues continues, it would be to the advantage of everyone involved in IMS to add one more important requirement to the mix: centralized service management. A critical gap threatens to deflate the promise of IMS and turn it into just another silo in carriers’ networks. The gap is created by the fact that although the IMS architecture itself is meant to handle the complexities of creating, authorizing and delivering disaggregated services across multiple networks and access media, it does not provide the associated OSS service management functionality that is necessary to turn the whole process into a billable service.

Missing link

Simply put, the IMS landscape is missing centralized OSS service management systems that will provide IMS elements with needed service-oriented rules and business policies, as well as links to OSS/BSSs in both the legacy and IMS domains. Centralized management will enable customers to use old and new services and enable operators to create, configure, provision, assure and bill for those services. From an operations perspective, centralized service management orchestration will provide the necessary “marching orders” to IMS elements for each session. This is critical, because many IMS sessions will be highly individualized and tailored to the consumer’s preferences and usage history.

The IMS business case for most service providers requires that they introduce the new domain in phases. As they migrate to IMS, service providers will not be scrapping their legacy platforms in the foreseeable future. With the proper OSS integration framework between the two domains provided by centralized service management, IMS will enable service providers to add new services to their legacy infrastructures with greater ease. It will also allow them to make legacy services such as voice mail or caller ring-back tones available to IMS sessions.

Adding an overarching centralized service management system in a pre-IMS environment will enable service providers to accomplish three key tasks that will smooth their migration to IMS:

1. Support existing silos (legacy services and functions) in legacy networks as they phase in their IMS architectures.

2. Manage new services supported by their IMS architectures.

3. Enable necessary service-to-network technology abstraction between legacy and IMS domains as services are turned up in the IMS domain.



Legacy support

IMS is very new, but service providers have embraced the need for IMS, or something very much like it, in the future. At the moment, however, no one knows just how long it will take for IMS to blossom or how much of a role it will play during its initial phases. As a result, service providers want a way to evolve into IMS as it matures. They are willing to cap their existing silos and grow their networks in the direction of IMS, but they lack the flexibility and the OSS tools that would enable them to create a strategy and proceed accordingly.

When plotting their migration to IMS, service providers want the flexibility to do what they want to do when they want to do it. Phased introduction means that service providers must rely on their legacy systems to provide revenue-generating services for as long as necessary. Because it ties their existing silos to IMS, the centralized service management system helps service providers continue to provide legacy services and features to customers during the migration process. It also keeps IMS from becoming a silo that requires its own management systems. Furthermore, it is a safe bet that some legacy services may never migrate to IMS, so the ability to tie legacy domains to the IMS domain for the foreseeable future is important to service providers.

IMS support

As IMS services are rolled out, a centralized service management system will provide the necessary capability to manage the horizontal network technology layers (DSL, DOCSIS, PacketCable, Wi-Fi, WiMax, GSM, CDMA and others) within the IMS architecture. While IMS service delivery elements—home subscriber server (HSS), call session control function (CSCF), service delivery platforms (SDPs), application servers, etc.—are capable of setting up and tearing down sessions on the fly, they cannot manage themselves.

Because services are specific to each individual each and every time a session is established, the IMS elements need to be told what limits, preferences and features are available to the end user who will be billed for event and on-demand service requests. The centralized service management system provides the necessary interfaces between the IMS elements and the resources (such as presence and location servers, entitlement servers and so on) that contain information relating to that end user.

As service providers introduce sophisticated services that rely on flexible, yet specific, billing capabilities, their IMS elements will need access to new levels and layers of billing information as it pertains to each end user. It will be advantageous to be able to update individual end user information during each session. For example, an end user may wish to pay for extra bandwidth for a specific session. Or users may want to update their feature sets, profiles or buddy lists going forward.

The IMS elements must have a way to access this information in order for service providers to squeeze the most profit out of their new services. A centralized service management system enables their IMS elements to access static and dynamic information.

Migration support

As there are very few green field IMS deployments, most service providers plan to implement a phased migration. For this reason, service providers need a way to abstract the network elements, features and functionality that are being replaced as new IMS elements are added to take their place. Abstraction will also be of use when adding an element (such as an SDP or application server) to support a new service, feature, or OSS/BSS capability.

It is highly unlikely that service providers will dismantle their legacy OSS/BSSs. Those that do not want to recreate their customer information databases in the IMS domain will benefit a great deal if the information in these systems can be accessed by elements or OSS/BSSs created in the IMS domain, and vice versa. Because it wraps around legacy silos and the IMS domain, the centralized service management system is critical to providing an open and federated information model so that an integrated view of the subscriber’s profile is managed for all services.

By providing this kind of support, a centralized service management system facilitates a better quality of experience (QoE) for service providers’ customers. Excellent QoE is essential for IMS to succeed. In no way can the end user be weighed down by inelegant features and functionality or inaccurate billing. End users do not want to have to reintroduce themselves to the IMS network, or for that matter even be aware of it.

The complexity of the network, especially during migration to IMS, must remain hidden from end users. This is tricky for service providers, because the particulars for each end user will be in play during each session and will generally carry more importance than ever before. Centralized service management helps reduce confusion and hide complexity, because it provides a common subscriber view and an integrated view of the service delivery network. It also interfaces to existing information that service providers would otherwise have to recreate in order to begin serving their existing customer base in the IMS domain while they continue offering services in the legacy domain. Trying to operate these domains separately would simply undermine the purpose of IMS technology—to deliver integrated services anyplace, anywhere and anytime customers want them.

Paul Scarff is director of wireless OSS solutions at Sigma Systems (www.sigma-systems.com). He can reached at Paul.Scarff@sigma-systems.com.