IMS’ Lack of OSS Functionality Could Relegate It to Silo Status

By Paul Scarff

The telecom industry continues to grapple with the complexity of delivery architectures and operational management of IP multimedia subsystems (IMS), leaving service providers and equipment manufacturers with their sights set on the IMS business case as well as determining whether IMS’ initial role is to enable fixed/mobile convergence or support next-generation services — or both. But while determining IMS’ role is important, another requirement must not be forgotten: The need to close a critical gap that threatens to deflate the promise of IMS and turn it into just another silo in carriers’ networks.

This gap exists because 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.

Bridging the Gap

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.

From an operations perspective, centralized service management orchestration will provide the necessary “marching orders” to IMS elements for each session, of which many will be highly individualized and tailored to the consumer’s preferences and usage history. Centralized management will enable customers to use old and new services and enable operators to create, configure, provision, assure, and bill for those services.

Most service providers will introduce the new domain in phases. As they migrate to IMS, service providers won’t scrap legacy platforms for the foreseeable future. Instead, 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. In addition, it will allow them to make legacy services such as voice mail or caller ring-back tones available to IMS sessions.

The addition of an overarching centralized service management system in a pre-IMS environment will enable service providers to support existing silos (legacy services and functions) in legacy networks as service providers phase in their IMS architectures; manage new services supported by their IMS architectures; and, enable necessary service to network technology abstraction between legacy and IMS domains as services are turned up in the IMS domain.

Evolution, Not Revolution

While IMS is very, very new, service providers have accepted that there is a need for IMS, or something like it, in the future. 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 are looking for a means of evolving into IMS as it matures and are willing to cap their existing silos and grow their networks in the direction of IMS. The challenge, however, is that they lack the flexibility and the OSS tools that enable them to create a strategy and proceed accordingly.

What they want is the flexibility to do what they want to do when they want to do it. Phased introduction means 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, while keeping IMS from becoming a silo that requires its own management system.
IMS will enable service providers to add new services to their legacy infrastructures with greater ease.
Furthermore, it is a safe bet that some legacy services may never migrate to IMS, so the ability to tie their legacy domains to the IMS domain for the foreseeable future is important to service providers.

Managing IMS

As IMS services are rolled out, a centralized service management system will provide the necessary capability to manage the horizontal network technology layers, including DSL, DOCSIS, PacketCable, WiFi, WiMax, GSM, and CDMA, within the IMS architecture. While IMS service delivery elements such as HSS, CSCF, SDPs, and Application Servers are capable of setting up and tearing down sessions on-the-fly, they cannot manage themselves.

IMS elements need to be told what limits, preferences, and features are available to the end user who will be billed for their event and on-demand service requests because services are specific to each individual each and every time a session is established.

The centralized service management system provides the necessary interfaces between the IMS elements and the resources including presence and location servers as well as entitlement servers that contain information relating to that end user.

As sophisticated services that rely on flexible, yet specific, billing capabilities are introduced by services providers, 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 have the ability to update individual end user information on a per session basis. For example, an end user may wish to pay for extra bandwidth for a specific session. Or they may want to update their feature sets, profile, or buddy list going forward.

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

Managing the Migration

Most service providers plan to implement a phased migration to IMS, so they need a means of abstracting 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 (e.g., SDP, application server, etc.) to support a new service, feature, or OSS/BSS capability.

It is highly unlikely that service providers will dismantle legacy their OSS/BSSs, so service providers that do not want to recreate their customer information databases in the IMS domain will benefit a great deal if the information these systems hold 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 silo, 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, centralized service management system facilitates a better quality of experience (QoE) for a service provider’s customers.

Excellent QoE is essential for IMS to succeed. In no way can the end user be weighed down by ‘klugey’ features and functionality or inaccurate billing. End users do not want to have to reintroduce themselves to the IMS network, or even be aware of it for that matter.

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 related to each end user will be in play during each session and generally be of more importance than ever before.

Centralized service management helps keep confusion and complexity hidden because it provides a common subscriber view, integrated view of the service delivery network and interfaces to existing information that service providers would otherwise have to completely recreate in order to begin serving their existing customer base in the IMS domain while they continue offering services in the legacy domain.

Paul Scarff is Director of Wireless OSS Solutions at Sigma Systems (news - alert). For more information, please visit the company online at www.sigma-systems.com.

[Return To The Table Of Contents ]