Operations and business support systems (OSS/BSS) have been the center of network operator IT projects from the very first days of computing. As “vertical applications” for providers, they’re the heart of profitability
Another way of looking at operations and business support, and at service management in particular, is as a customer experience model.
Tom Nolle, President, CIMI Corp.
OSS/BSS may be the most structured and standardized of all vertical applications, but that doesn’t mean that it doesn’t need to change. In fact, OSS/BSS is on the verge of changing to emphasize the customer experience that focuses on the quality of experience (QoE) of the user.
Customer experience: Where XML-driven OSS and service management meet
By way of background, operations systems have traditionally been differentiated from network management systems, with OSS managing the operations personnel and the business activity and network management systems managing the devices. A certain tension or competition has always existed between their missions, yet the two came together in the area of service management.
Service management was expressed as the top layer of the original network management stack (which includes element management, network management and service management). Service management has also become a focus of OSS/BSS through the TM Forum Service Delivery Framework (SDF) work.
Yet another way of looking at operations and business support, and at service management in particular, is as a customer experience model, which is implicit in the way over-the-top (OTT) providers offer their services. This model unifies network and operations management with services, but it focuses the unification around the quality of experience of the user.
In an experience-centric management model, everything starts with a user commitment to an experience or service based on an offering by a provider. In TMF terms, this would be the NGOSS Contract. The goal in experience-centric OSS/BSS design is to make that commitment into something that can be processed by software to create the service or experience the customer wants.
In order for that to happen, the commitment must be expressed in some standard form using a machine-readable structure. XML is the most widely accepted language for this mission because it is easily processed using a variety of standard software tools.
An XML metadata description of a service order could be translated by OSS/BSS systems into a set of requests for provisioning steps already defined in both management practices and formal standards (the TMF eTOM standard, for example). The service contract becomes a kind of shopping list for functionality of OSS/BSS systems, replacing a more traditional static application model that’s specific to the types of service being created. Instead of having an “IPTV application” or “VPN application,” the operator has a single application that parses XML metadata to create either of these services, and many more.
Ongoing service management: Taking a metadata-driven approach
The same metadata-driven approach can be used for service management once the service has been provisioned, and even to tear down when the service has been fulfilled. In effect, the metadata contract is used as a kind of script to define how service events in the service delivery state of the contract should be managed. As such, the contract data must include definitions of service policies that can be applied as various issues—ranging from normal requests for service changes to fault events—that are encountered in the lifetime of the service.
Ongoing service management poses a more complex problem than service creation or provisioning, however. The difficulty is that in networks based on IP and even Ethernet, current practice is to establish traffic policies to create service level parameters (QoS) rather than to “provision” discrete resources for each service. That’s particularly true for consumer services where per-service provisioning could never scale. Where networks provide class of service management of QoS, the network layer and network management systems processes will normally attempt to remedy any problems at the service class level. As a result, faults may never appear at the service level at all. Where they do, operators may not want to handle them for the same reasons of scalability.
The solution to this problem as it emerges in operations centers of carriers worldwide is to let “collective processes” manage service classes and process per-service alerts where the two following conditions must be met:
- The collective processes managing class-of-service handling have failed to meet their service-level agreement (SLA). In many cases, operators also want these processes to have run their course and have failed to produce a remedy as well.
- The service itself is one where discrete fault management of faults is applied. That means that many consumer services will never see any in-service event other than the completion of the service’s mission, which is a signal to decommission the service.
Quality of experience OSS/BSS model evolves with standards and software in flux
OSS/BSS functionality at the level of individual service tasks isn’t impacted by the shift to a customer experience-driven model for service management, but the model impacts OSS/BSS logic in that it demands more effort to be focused on the design of the service metadata and the interpretation of that metadata, and less time focused on the management of service-specific applications.
The industry is evolving to support this, but both the standards processes and the OSS/BSS software are still in a state of flux. Some new operations software vendors are springing up to provide the metadata management portion of the customer experience-driven OSS/BSS implementation, and then using standard application program interfaces (APIs) to invoke traditional OSS/BSS functions.
Operations processes also need to adapt to the new model, since in the customer experience model of OSS/BSS, human intervention is greatest at the service design level when templates and policies are authored, and in post-mortem analysis of service failures or customer complaints that indicate that the system isn’t working as planned. It’s important to ensure that where such problems are encountered, they are solved within the framework of the experience-driven OSS/BSS model, or the operations software will tend to gradually revert to the older system, which may have a problem scaling to the level needed to support modern consumer broadband services.
About the author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982. He is the publisher of Netwatcher, a journal addressing advanced telecommunications strategy issues. Check out his SearchTelecom.com networking blog, Uncommon Wisdom.
This was first published in April 2011