Untangling the OSS

Service delivery platforms (SDPs) may enable carriers to be flexible and quick in their service creation and delivery, but the back-office systems need to be able to keep up with the provisioning, tracking, billing and assurance for what is an increasingly complex service environment. The complexity of the next-generation network services and strict user demands regarding quality require some form of constant management throughout the service lifecycle. With any number of legacy, siloed and fragmented systems in place, that will be no easy task.

“The service portfolio that providers can offer is expanding dramatically,” says Oracle Corp.’s Indu Kodukula, vice president of product management. “Services are more dynamic, personalized, and user-context aware. To properly capitalize on this expanded service portfolio, service providers have to solve the problem of rapidly integrating service execution with OSS/BSS systems in a flexible, cost-effective and timely manner. Service providers also must deal with the massively customizable nature of new services and allow for near real-time bidirectional interaction between OSS/BSS systems and service execution.” For example, a bandwidth-on-demand service would require that the DSL bandwidth on a subscriber line be tripled within seconds of the subscriber requesting such a service from a self-help portal.

To help operators along, the SDP OSS footprint now is defined by the TeleManagement Forum’s eTOM, or enhanced Telecom Operations Map, which describes the full scope of business processes required by a service provider and defines the key elements and how they interact, creating a guidebook. The TMF also recently launched Project Landscape, to explore the wide view of all carrier systems in order to understand the total impact of the network and service creation on the OSS.

To many, these efforts as well as the implementation of standard interfaces between systems represents the only way through the tangled, interconnected mess of the back office, once rapid service innovation and on-the-fly delivery comes to fruition. “Previously, the domain of the SDP has been strictly limited to service creation and execution,” says Cassandra Millhouse, product marketing manager for Cramer, Amdocs Ltd.’s OSS division. “The SDP is now seen as a point of integration between the service creation and execution capabilities, where developers can build and deploy innovative services based upon standard interfaces.”

One example would be SIP servlets that can support functions required within OSS architectures such as service and network activation. “The SDP, through SOA-based frameworks, provides the ability to orchestrate OSS functions into business process workflows,” says Millhouse. “This enables services to be fulfilled at all the layers within an NGN architecture. It is essential that these workflows be transaction-based so that process, fallout and jeopardy management can be supported within the operations environment.”

Also, some vendors are offering centralized platforms to smooth over existing, non-standardized OSS fragmentation. “The need to orchestrate these balkanized back-office silos becomes paramount to succeed in the development of converged services,” says Omar Téllez, executive vice president of marketing at Synchronoss Technologies Inc. “A centralized platform such as our ConvergenceNow addresses these issues head on, and orchestrates the siloed OSS/BSS infrastructure to streamline the activation and provisioning of these elements.”

Duby Yoely, vice president of solution engineering at TTI Telecom, says the situation will force the implementation of an end-to-end, multi vendor manager-of-managers, or “MOM,” with proactive capabilities, even leading toward an automated NOC in some cases. “We used to see perhaps one to two vendors involved in a legacy service delivery chain, but we can expect to see five, 10, or more when it comes to NGNs. So clearly, somebody is going to have to make sure that all of these components run smoothly,” says Yoely. “To accomplish this, SDPs and the service management OSS will have to be able to interact with each other. This includes support for all standard bidirectional APIs in a real-time environment; not only providing data (measurements, alarms, status), but also receiving and implementing commands as well.”

Sigma Systems is on a similar track. “SDP and/or SIP application server capabilities aren't really reused in an integrated fashion today, because services in many cases are still provisioned and operated from standalone silos,” says Preston Gilmer, vice president of product marketing at Sigma Systems. “The whole point of investing in IMS is to change this model. A centralized OSS service fulfillment system would provide the over-arching business and process orchestration that enables an operator to build services that are greater than the sum of their parts.”

Gilmer says that OSS “macro-orchestration” within the fulfillment architecture would address these key operational requirements for service providers:

• How services are ordered or supported
• Network bandwidth availability checking and device qualification
• Subscriber authentication and authorization processes
• How self-care for new services is enabled
• How billing is set up and executed
• How diagnostic processes for service assurance are carried out

One thing is for certain: providers cannot ignore the need to prepare the back-office for the SDP era. For big incumbents, it still can take up to 18 months for OSS/BSS systems to catch up and understand fully that a new service exists. For smaller operators, it’s typically 9-12 months. “So, to unleash the full potential of SDPs, service providers must address the bottlenecks that OSS/BSS currently represent,” says Axiom Systems’ vice president of architecture and strategy, Brian Naughton. “There is no point in being able to rapidly create new services if the rollout and management of them cannot keep pace.”

Find out more about SDP and how it relates to IMS, SOA and Web 2.0, by reading “SDPs PDQ: Why New Service Creation Platforms Do It Better, Faster, Cheaper” in the August issue of xchange.

Amdocs Ltd. www.amdocs.com
Axiom Systems www.axiomsystems.com
Oracle Corp. www.oracle.com
OSS Observer LLC www.ossobserver.com
Sigma Systems www.sigma-systems.com
Synchronoss Technologies Inc. www.synchronoss.com
TeleManagement Forum www.tmforum.org
TTI Telecom www.tti-telecom.com

Share this article: Email, Slashdot, Digg, Del.icio.us, Yahoo!MyWeb, Windows Live Favorites, Furl
Add this article feed to: RSS, My Yahoo, Newsgator, Bloglines