Multivendor network elements stress legacy operation support systems
Multivendor network elements stress legacy operation support systems
A lack of standards, rapidly advancing multivendor technology, and new competition are challenging service providers and suppliers.
Leif Hoglund RHK Inc.
As competition heats up among telecommunications operators, reliability, service-level agreements, and customer-care features are becoming the basis for service differentiation. The need to evolve operation support systems (OSSs) for managing networks that support these features is critical. For the regional Bell operating companies to play in this game, it`s no longer satisfactory to depend on operations systems modifications for the integration of network elements (osmine) to make changes to their OSSs--especially when new features are delayed by a year or more and in some cases can`t be supported by the legacy systems.
Some Synchronous Optical Network (SONET) and wavelength-division multiplexing (WDM) vendors have recognized that deployment of their new technologies is actually being slowed by the inability of legacy OSSs to keep pace with changing technology. As a result, vendors have started to offer element management systems (EMSs) and network management systems (NMSs) as Bell Communications Research (Bellcore) replacements. If the RBOCs adopt these proprietary systems, they face a difficult integration problem--operations must deal with multiple systems. This problem cuts across all operational processes: traditional provisioning, fault management, and service activation. However, new entrants in the market, such as competitive local-exchange carriers (CLECs), can immediately take advantage of these new technologies.
State of flux
Less than a decade ago, the public network was primarily run by RBOCs that had a monopoly on local markets. Because more than 80% of the OSSs deployed by the RBOCs were--and still are--provided by Bellcore, the environment in which equipment had to operate was consistent. Bellcore requires osmine to manage changes to its OSS that are specific to each vendor`s equipment or equipment type. This ponderous process is only able to keep pace with incremental equipment upgrades and service developments; it has been completely ineffective in a competitive environment where fast deployment of equipment and services is crucial.
Today, an onslaught of service providers, each with some new twist on how it will approach the market, has led to a proliferation of features and equipment options. As competition increases, the ability to isolate faults and troubleshoot problems across network boundaries is critical. Problems can originate with end users, with the service provider`s own network, or with another carrier. This wide array of potential errors puts a greater burden on OSSs.
With multiple service providers competing for customers, all functions from order entry to service activation, repair, and billing must be done faster, more efficiently, and with greater focus on customer satisfaction than in the past. At the same time, many new services have virtual bandwidth capabilities and permit statistical multiplexing with other users. Although these new services are more flexible and cost-effective than dedicated leased lines, their customers` services typically demand performance statistics to back up service claims.
Older OSSs were designed with the assumption that a single service provider would monopolize the market. Today, customers expect OSSs to offer a strategic advantage.
Legacy OSS limitations
The largest obstacle to extensive deployment of WDM systems in metropolitan networks by RBOCs is the inability of existing management systems to work with new technology, where a single fiber pair supports multiple SONET paths. The trunk inventory record-keeping systems currently used by RBOCs are built on the model of a copper-based physical plant and circuit-based network. They can`t resolve issues resulting from new technologies like Asynchronous Transfer Mode (ATM) and WDM such as the provisioning of virtual circuits and the bidirectional assignment of multiple wavelengths on a single fiber.
But OSS replacement costs can be high. Besides the cost of establishing new databases, the replacement of current OSSs would require operators to re-define operational procedures for every task from network planning and installation to activating a new subscriber and handling complaint calls. Therefore, during a long transition period, an operator must support a dual set of operating procedures with staff trained on both old and new OSSs and a clear definition about which subscribers and network segments are handled by which set of procedures.
Despite high costs, the RBOCs have been forced to change. For the first time, RBOCs are considering a variety of EMSs and NMSs from vendors to manage new services on their networks. The same is true for SONET backbone infrastructures where the system capabilities outstrip the legacy management system`s ability to take advantage of these improvements. It is especially true of dense wavelength-division multiplexing (DWDM) systems, where the technical advances can`t even be modeled in some traditional databases.
SONET and WDM
SONET crossconnect equipment is supported in some legacy OSSs, but multiplexers are normally managed with a vendor-provided EMS. Most legacy NMSs don`t support the advanced features offered by a vendor-specific EMS. The lack of full-featured support in Bellcore OSSs for SONET network elements has been cited by several RBOCs as a barrier to higher volume deployment. Some of the important features offered by SONET vendors are the ability to auto- or self-register the inventory database, and the capacity to offer enhanced provisioning.
Legacy OSSs can be used to manage some functions of WDM systems in the comparatively simple networks designed to relieve fiber exhaust. But legacy systems cannot manage bi-directional operation, and there are significant craft issues around fault management. The lack of a WDM flow-through operational model in legacy OSSs will delay the deployment of optical rings and other configurations that cannot be modeled as circuits. As a result, vendors are offering NMSs specifically designed for WDM technology.
A host of software vendors have emerged in the last three years, and established suppliers such as Lucent Technologies, Nortel Networks, Bellcore, Ericsson, and Alcatel have introduced new products. Software such as Lucent`s Integrated Transport Management, Nortel`s Integrated Network Management, and Bellcore`s Transport EMS are all aimed at the management of new transport technologies. The lack of a clear front-runner in this market space, though, means that network-element vendors may have to interface with several of these network-management products and comply with different interface protocols for each of these major NMS providers.
Lack of interface standards
Even when new features are well understood and modeled appropriately in whatever management system the service provider is using, there is no accepted standard. Managing a network with diverse equipment is tough, and it is virtually impossible to take advantage of new network-element features in such an environment. For example, fault correlation and trouble isolation are never supported across EMSs, and even provisioning often involves several EMSs or manual entry.
In the face of a growing number of operators with very different management requirements, budgets, and a general lack of consensus about standards, vendors are playing a crap shoot. While network element vendors are eager to support a common interface, these companies also can`t agree on which technology should be the standard. The following interface technologies define the current landscape:
Transaction language-1 (TL-1) is used by most deployed intelligent network elements, especially for SONET equipment, but it`s inadequate for new technologies. Of course, it doesn`t help that there are many different implementations of TL-1, which is not considered an open standard interface. Despite this situation, a vendor selling to RBOCs right now is advised to offer a TL-1 interface if the network elements are to interface directly with legacy NMSs, such as operational provisioning systems/ intelligent network element or network monitoring analysis.
Common management information protocol (CMIP) is the most feature-rich interface option but it`s unwieldy and expensive to implement. The data people don`t use it, so CMIP may be fighting the tide. Telecommunications operators like CMIP, however, and most seem to be migrating in this direction.
Simple network management protocol (SNMP) is easy to implement and widely deployed in the enterprise market. Since the data-communications world has embraced it, many telecommunications operators are deploying SNMP network elements. But for large operators, SNMP really doesn`t cut the mustard in its current form. The need to filter commands and scope for certain elements is absolutely crucial to such operators.
Common object request broker architecture (CORBA) is gaining support from many suppliers. Several vendors of network and service management products have begun implementing CORBA interfaces, but CORBA has its own technical limitations. Most significantly, the alarm notification mechanism described by CORBA does not map well to a large network of network elements reporting status.
As a result, there is no single protocol, let alone equipment model or interface specification, that a network-element vendor can implement that supports the operations of all of its customers. The protocol standard the vendor must support is almost entirely determined by the customer or market segment. For public networks built primarily to handle data or Internet protocol traffic, SNMP is used almost exclusively. Because of the SONET backbone used in such networks, there is also a percentage of network elements that are TL-1 based. Conversely, most that are embedded in telecommunications-based networks and report to legacy OSSs will be using TL-1, with some newer equipment for transport beginning to use CMIP and data equipment for ATM and frame relay using SNMP.
As voice and data networks converge, neither TL-1 nor SNMP is likely to be the predominant choice. CORBA is an emerging standard and preferred by many equipment vendors for its simplicity. CMIP, however, is well-defined now and supported by some OSSs offered today.
Lacking concrete direction from the operator community, some network-element vendors, in concert with the TeleManagement Forum (TMF, formerly the Network Management Forum), have taken the initiative to test common interfaces in prototype products. The most significant collaboration is the TMF`s Connection Management/Interoperability Catalyst Group, in which Lucent, Fujitsu, Tellabs, and Nortel demonstrated a CORBA interface between several EMSs and Lucent`s Integrated Network Management software. End-to-end connection management within a multivendor network was demonstrated at the National Fiber Optic Engineering Conference and TMW (TeleManagement World) in September 1998. Although this interface is not yet part of any released product, the project indicates that vendors understand it is in their best interests to define standards.
CLECs` OSS challenges
CLECs have their own OSS problems. Typically, as a CLEC enters the market, capital costs cover the engineered network equipment, and little thought is given to OSS scalablity. OSS costs are often actively minimized. As the CLEC grows, either by acquisition or by adding regions, there is a tendency for each region to become a self-contained island of integrated functionality with little outside communication. Inevitably, patchwork solutions are developed to provision a circuit or trunk group that originates in one region and terminates in another.
At some point, the operator finds that overall management of the network has become impossible because it has multiple testing, billing, or provisioning systems. If the operator has grown through acquisition, then the result is a lack of commonality from system to system and a complete duplication of all functions.
As CLECs have grown over the past decade, many have, or will soon reach, the point at which significant action must be taken. MCI WorldCom is in the midst of OSS integration, as are ICG Communications Inc., Intermedia Communications Inc., and others.
The result is a huge opportunity for network-management products. RHK`s estimate of the market opportunity for network management in North America alone is more than $2.3 billion in 1998, and significant growth is forecast in the coming years.u
Leif Hoglund is director of network management at telecommunications market researcher RHK Inc. (South San Francisco, CA).