Cable Telephony OSS: Trick or Treat?

As Halloween approaches, it seems appropriate to talk about unseen forces that make cable telephony work. In theory, an operations support system (OSS) works operational magic to move information when needed from any part of a cable operator’s network to where it’s required. Practically, the open questions are: “Is the concept a reality?” And, if so, “Where does an operator get one?” The underlying principles of an OSS have not changed since this column discussed them three years ago. The structure of an OSS can be described by the five-layer telecommunications management network (TMN) model developed by Telcordia, and the processes that support it. Cable OSS design also is influenced by the PacketCable OSS Overview Technical Report PKT-TR-OSSI-V02-991201, which includes the TMN model. The lower three layers of TMN (network element, element manager and network management) are hardware oriented, while the upper two layers (service management and business management) are customer and business oriented. The lower layers are thus associated with issues like port and frame numbers, and card location, while the upper layers look at customer name, address, service subscription and payment type. Some texts limit the definition of OSS to the hardware layers, and refer to the upper layer manager as a backoffice support system (BSS). Common usage, however, merges the two under the umbrella of OSS. The processes supporting the model can be grouped into the three categories of fulfillment, assurance and billing (FAB). Fulfillment processes are concerned with setting up a customer’s service. Assurance processes are in place to guarantee services perform as specified. Billing processes pay the operator for the services provided. Total system manager Given this framework, the ideal OSS is a total system manager that feeds the FAB processes by moving data across the TMN layers and reporting on key parameters needed by the operator to track business performance. To find out how the real world maps into the ideal, I talked to three OSS vendors who sell telephony management solutions to the cable industry. Telution (www.telution.com) is a newcomer that began and grew in the telephone industry with a focus on workflow management for competitive local exchange carriers (CLECs) and incumbent local exchange carriers (ILECs). Lemur Networks (www.lemurnetworks.com) is a cable industry startup that specializes in IP service activation, including provisioning PacketCable network elements for both telephony and data. Alopa (www.alopa.com) has roots in automated provisioning, and is expanding its vision to also include end-to-end subscriber management, workflow and assurance.

Managing the database

Database management is a common thread across all these vendors. Although the functions of the database manager vary by vendor, the mechanics of data management for OSS fit into one of two methods. One implementation is for the system to convert all data to its own model, which provides a constant representation format for everything tracked and managed. An alternative implementation is to keep the data in its native form, and access it via application interfaces (APIs) to other systems based upon standard data models such as XML. The argument for conversion of data to a standard model is that new applications require so many touch points per transaction that systems based upon APIs and XML data transfer will find it hard to sync up, and will be susceptible to missing or inaccurate data. Apollo Guy, director of business development for Lemur Networks, explains it this way: “The Lemur IDATA system has over 1,000 objects that represent data in a cable architecture. Despite its complexity, the object-oriented model is more flexible, because it can be easily manipulated to accommodate relationship changes between services without reliance on costly recoding.” Understanding APIs Individually, APIs are easier to design, but then the OSS needs to tie data from separate systems together. This requires the OSS vendor to have an in-depth understanding of each system and relationships with multiple partners that ensure systems continue to work together as software revisions are released. To make this work, the vendor needs to know the partners and have experience in working with each service. Telution Director of Marketing Rob Kunzler notes yet another reason to use APIs. “There are clearing houses for legacy telephony transactions that, for example, maintain the line information database (LIDB) or location information for E911 calls. A service provider’s OSS needs to interface with these applications that fall outside any internal data model, as well as with the provider’s own legacy systems.”

Alopa believes that the interface task can be made easier by providing “adapters,” which are sets of code that work with XML and APIs. Per Mitch Berman, Alopa vice president of marketing, “these adapters do not require an operator to reformat data from each system, and allow operators to do their own customization of data as new services are added to the marketing mix.”

Playing traffic cop Irrespective of the mechanics of data management, the trend among all these vendors is to position themselves as providers of a solution that can evolve into the “traffic cop” or overall manager of all the operator’s data. However, in practicality, everyone still seems to have a niche. Telution emphasizes its expertise with customer facing data. Lemur focuses on network facing data. Alopa talks about offering “point solutions,” which solve particular process problems like automated provisioning, and then expanding to a full platform.

Even though the vendors are eager to position full OSS solution suites, the appearance in the field of a complete implementation of the TMN model is slow in coming. The reason may be that in the end, operators remain responsible for their own networks. They need to understand both the processes and data structures of legacy and emerging systems and be completely confident of the OSS capability before committing their operations to an automated data management system.

In addition, they need to have the budget to implement the commitment. With so many legacy systems in the field, the task is formidable, and the purchase of a full OSS becomes such a complex sale that operators tend to avoid it until a major business process change drives the decision. In the meantime, much of what is called an OSS continues to be management of only a part of the data needed for system operation. Justin J. Junkus is president of KnowledgeLink, Inc. To discuss this topic further, email him at [email protected].