The OSS integration Holy Grail: Openness and flexibility

Operations support can be one of the most complex, difficult jobs within a large telecommunications service provider. All of the major carriers in North America today are faced with supporting multiple billing systems and far too many legacy platforms with proprietary interfaces and inflexible management capabilities. Every time a new system is introduced to the network, complexity often increases exponentially. Exacerbating the situation, the convergence of wireline, wireless, and broadband networks and services can create an integration and support nightmare. Thus, one of biggest hurdles a vendor faces in providing new products and services to carriers is approval from the operations support team. This article provides insight into how these hurdles can be overcome and pave the way for adoption of new VoIP platforms and services within a legacy network.

Historically, traditional equipment manufacturers in the telecommunications industry have developed proprietary hardware and software products. These legacy systems were never designed or intended to share information with other network elements. Since only trained specialists could work with this equipment, carriers were forced to work with incumbent vendors who would typically charge premium fees and require long lead times. The resulting networks and infrastructure also created high switching costs for carriers looking to change vendors for similar products or deploy new products and services based on new technology. However, carriers today require that new products employ an open systems architecture and adhere to industry standards so they can reduce the costs of ongoing operations and have the flexibility to use a multi-vendor approach in infrastructure deployments.

Several industry organizations have focused on the area of Operations Support Systems (OSS) in order to address the challenges carriers face. One example is the TeleManagement Forum (TMF), a non-profit group whose goal is to "facilitate the rapid development of flexible, low cost of ownership, OSS/BSS solutions to meet the business needs of today's cost conscious, competitive, and rapidly evolving telecom environment." TMF has developed a powerful reference model called the Next Generation OSS (NGOSS). In May 2004, the International Telecommunications Union (ITU-T), a leading publisher of telecommunications technology, regulatory and standards information, formally approved the first TMF standard as an ITU-T Recommendation. The International Engineering Consortium, a similar non-profit organization, also provides several whitepapers, tutorials, and other information on OSS systems. With the broad adoption of Internet technologies such as HTML and Web services, the Internet Engineering Task Force has also contributed to the development of new OSS solutions. Finally, the International Organization for Standardization has played a significant role in influencing most of the standards in use today.

While many of these organizations provide abstract reference models and frameworks, other industry standard technologies address specific product implementations and include languages and protocols such as Simple Network Management Protocol (SNMP), Common Object Request Broker Architecture (CORBA), Extensible Markup Language (XML), and other Web services such as Simple Object Access Protocol (SOAP).

SNMP is a network management protocol that coordinates information exchange between various network elements. SNMP runs in the application layer (OSI layer 7) and has achieved wide adoption within the industry. SNMP often accesses hierarchically structured objects called Management Information Base, or MIBs. These MIBs contain information on managed objects such as application servers, media servers, softswitches, and other network elements. SNMP is currently in its third version (SNMPv3) although many existing deployments are based on earlier versions.

CORBA specifications are provided by the Object Management Group (OMG), a non-profit consortium that produces and maintains specifications for software interoperability. The primary benefit of the CORBA object broker model is that the data processing is abstracted from the type of computer hardware, operating system, programming language, network, and implementation vendor.  Put in another way, "separation of interface from implementation" is the essence of CORBA. Wide adoption of CORBA interfaces translates into a high degree of interoperability between vendor platforms. CORBA technology falls into the category of "middleware" and has proven highly reliable even in deployments requiring a large number of clients with significant transaction volume and throughput.

Internet technology, including XML and Web services, has seen broad, rapid adoption within the OSS community. As more user interfaces become "Web-enabled," both OSS administrators and even end-users can use a standard web browser to provision, configure, and maintain services. In fact, all major vendors today use Internet technology for a significant portion (if not all) of their user interfaces. Beyond the user interface, or presentation layer, Web services also provide a consistent method of back-end data transfer and processing. SOAP codifies the practice of using XML and HTTP as a method invocation mechanism and, similar to CORBA, provides an added layer of abstraction.

Most network elements available today include various components designed to meet specific OSS requirements of Operations, Administration, Maintenance, and Provisioning (OAM&P). For example, an Element Management System (EMS) monitors network elements and provides interfaces for configuration, maintenance, and other operational activities. Service Management Systems (SMS) provide interfaces for provisioning services and subscription management. For many network elements, the EMS and SMS combine to provide a complete solution to carrier OSS requirements.

Most EMSs adhere to the ITU-T operational management architecture, which supports the general functional areas of Fault Management, Configuration Management, Accounting Management, Performance Management, and Security Management (FCAPS). Fault Management includes alarm classification, real-time alarm processing, notification, and correlation of critical events. Configuration Management supports multi-cluster management with centralized management of geographically diverse infrastructure. Accounting Management refers to system accounting data such as the number of concurrent users logged in, number of active sessions, number of provisioning commands executed, number of security alerts generated, etc. Performance Management generally covers issues related to CPU utilization, disk and memory usage, and monitoring and graphing of collected data. Finally, Security Management should monitor users, provide robust multi-level access control, and support audit trail logs that include unauthorized access attempts. In addition to supporting the standards and frameworks mentioned above, carriers also look for vendors to provide additional features beyond these basic requirements. For example, built-in libraries of customizable MIBs can reduce integration and on-going operational costs.

The SMS addresses service provisioning and subscriber management functions. In addition to FCAPS, other general requirements for the EMS/SMS include fault tolerance and high availability. These requirements are generally met with a combination of hardware and software redundancy, monitoring, and sophisticated data versioning coupled with database re-syncing in case of failure. For carriers looking to wholesale/resell services to corporate customers, the SMS must support multi-tiered access control with partitioned customer data for complex billing and provisioning scenarios.

In a recent deployment with an international long distance carrier, an Account Codes application running on an application server was integrated into an existing TDM and VoIP network. The Account Code application provides account verification for long distance calls prior to call completion. The incoming call is screened against lists of valid codes required to complete the call. Depending on the rule set, the call is passed on for completion or terminated with the appropriate message.

Previously, the Account Codes application was running on legacy Class 4/5 switches in the service provider's network. Ongoing operations and maintenance of these switches was incurring significant costs, particularly when changes need to be made to the Account Codes application. Because of the proprietary nature of this legacy equipment, the service provider was dependent on the original equipment vendor to provide application updates and changes. These services were not only expensive; they also would typically take several months to implement. The service provider identified this issue early on and decided that one of the key criteria of a new application platform would be retaining control over the application behavior so that they could implement changes themselves. In the area of application control, one critical requirement was to create and maintain the provisioning aspects of the Account Code application. They needed a platform that provided fine-grained control of all aspects of provisioning new accounts. In fact, they wanted an API in which they could invoke provisioning commands themselves. This would give them complete control without any involvement from the platform vendor. Other requirements included APIs and MIBs for configuration, management and monitoring of hardware and platform and application software components, including both IP and TDM protocol layers, integration with their OSS, and Web-based OA&M functionality.

A major European PTT wanted to provide value-added services to large, multinational corporations in a cost-effective way. Many of these companies have multiple branch offices in several European countries as well as Asia and North America. The PTT decided to provide Voice Virtual Private Network services (Voice VPN) to these corporations so that they could cost-effectively communicate across multiple office locations. Voice VPN allows enterprises to logically implement the equivalent of a private voice network that physically interconnects multiple office locations using shared PSTN/Voice over IP networks without incurring the capital equipment and operating expenses of a dedicated private network with leased lines. One of the key challenges of this service offering is providing a wholesale/resell model with built-in support for managing, provisioning, and billing the carrier's customers and the carrier customer's end-users. In this scenario, the network provider, service provider, enterprise, and end-user each had a unique role with associated tasks and requirements. For example, the enterprise could provision users, generate reports, and configure services only within their company. The billing and reporting data had to be partitioned to provide security, privacy, and comply with all regulations and standard operating procedures. Few vendors in the industry today meet all the requirements of these complex scenarios.

Customized bundles of next-generation services deployed across wireless, wireline, and broadband networks hold promise for increasing carrier revenues. At the same time, new technologies for reducing operational expenses strengthen the business case for near-term VoIP deployments. However, none of the goals can be achieved without proper OSS integration and clear cost reductions of OSS expenses. All new products and services must provide a carrier with standards-based OSS components that demonstrate a high degree of openness and flexibility.

Bryan Michael is director of marketing at BayPackets and may be contacted at bryan.michael@baypackets.com.

Visit BayPackets online.