.gif)
IMS-OSS/BSS
IMS is missing centralised OSS service management systems that will provide IMS elements with needed service oriented rules and business policies, says Paul Scarff
As the telecommunications industry continues to try to get its arms around the complexity of delivery architectures and operational management of IP multimedia subsystem (IMS), service providers and equipment manufacturers are focusing their attention on the IMS business case and on getting a better understanding of the technology from a deployment and operational support systems perspective. In addition, many players are also trying to determine whether IMS’ initial purpose should be to facilitate fixed mobile convergence, support next-generation services, or do 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: 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.
The gap is created by the fact that while the IMS architecture itself is meant to handle the complexities of creating, authorising 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 centralised 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. Centralised 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, centralised service management orchestration will provide the necessary ‘marching orders’ to IMS elements for each session, of which many will be highly individualised 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 centralised service management, IMS will enable service providers to add new services to their legacy infrastructures with greater ease. And, it will allow them to make legacy services such as voice mail or caller ring-back tone available to IMS sessions.
The addition of an overarching centralised 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 service providers 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
While IMS is very, very new, service providers have embraced the fact that there is a 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 are looking for a means of evolving 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 enable them 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 centralised service management system helps service providers continue to provide legacy services and features to customers during the migration process. And it also keeps IMS from becoming a silo that requires its own management system(s). 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.
IMS support
As IMS services are rolled out, a centralised service management system will provide the necessary capability to manage the horizontal network technology layers (eg DSL, DOCSIS, PacketCable, WiFi, WiMax, GSM, CDMA, etc.) within the IMS architecture. While IMS service delivery elements (i.e. HSS, CSCF, 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 their event and on-demand service requests. The centralised service management system provides the necessary interfaces between the IMS elements and the resources (eg presence and location servers, entitlement servers, etc.) that contain information relating to that end user.
As sophisticated services that rely on flexible, yet specific, billing capabilities are introduced by service 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 centralised service management system provides their IMS elements with the ability to access to static and dynamic information.
Migration support
As there are very few greenfield IMS deployments, most service providers plan to implement a phased migration to IMS. For this reason, service providers are in need of 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 (eg SDP, application server, etc.) to support a new service, feature, or OSS/BSS capability.
It is highly unlikely that service providers will dismantle legacy 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 centralised service management system is critical to providing an open, federated information model so that an integrated view of the subscriber’s profile is managed for all services.
By providing this kind of support, centralised 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 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. Centralised service management helps keep confusion and complexity hidden because it provides a common subscriber view, an 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, Sigma Systems and can be contacted via e-mail: Paul.Scarff@sigma-systems.com www.sigma-systems.com
Share this article with others
Post to del.icio.us
Printed from http://www.eurocomms.com/features/111232/IMS-OSS%252FBSS.html
Comment on this article
Skip to comments
We encourage users to analyse, comment on and even challenge European Communications's articles, including the one above - 'IMS-OSS/BSS'
User reviews and comments that include profanity or personal attacks or other inappropriate comments or material will be removed from the site.
Additionally, entries that are unsigned or contain "signatures" by someone other than the actual author will be removed. We will take steps to block users who violate any of our posting standards, terms of use or privacy policies or any other policies governing this site.