IEC: On-Line Education: WPF: Element Management Systems (EMSs)

There are several options for service providers or end-customers to achieve various levels of EMS functionality. Two major factors to be weighed in an EMS analysis are the following:

Concurrency: the old adage in real estate is that there are three factors to consider: location, location, and location. With EMSs, there are also three factors: concurrency, concurrency, and concurrency. What is concurrency? Concurrency means that a new release of the EMS software is available when a new version or release of an NE is ready to be deployed in a network. New NE releases usually add new alarms, commands, and other features that must be accommodated by the EMS. Concurrency is less difficult to achieve if the EMS and NE work together to produce a timely, consistent solution.

The specific features of the four-function EMS components that are required; different providers of EMS software offer different levels of functionality. For example, see Figure 16, the Euristix RACEMAN EMS architecture.

Categories of EMS Software Providers

There are several categories of EMS software providers. Each category broadly defines the potential extent to which an EMS software provider in that category can provide various levels of functionality:

Independent software vendors (ISVs)—ISVs are software companies that specialize in network management software; there are two types:

those that provide software products, usually at multiple TMN layers, directly to service providers and to end customers (Telcordia Technologies is a special case of this because of its unique historical genesis as Bell Labs, then Bellcore, a Bell System–owned network management software provider. Now privately owned by SAIC, Telcordia—while still an entrenched provider to the RBOCs—finds itself competing for business with both the RBOCs and other SPs to which Telcordia now markets its software and services).

those that provide tools, core platforms, and turnkey applications on an original equipment manufacturer (OEM) basis to NE vendors who use these products in their branded products; these offerings are appealing to many NE providers because the development of an EMS can be quite complex; it requires a wide range of knowledge and skills related to protocols, data networking, GUI development, and database technologies as well as knowledge of the target NEs; an NE vendor, while having a complete knowledge of the target NEs and the management tasks required, may not have access to the other skills required; recently, a large number of tools and platform components have become available from independent software vendors; such tools include protocol stacks, manager development toolkits, EMS toolkits, and GUI modules; while these tools assist in the development of the EMS, a developer still requires lead-time and extensive skills to turn the tools and components into an EMS

NE vendors—there are two types:

those that provide EMSs only for their NEs and do not provide NML, SML, or BML systems

those that provide EMSs for their own NEs and also provide offerings at the NML and possibly at the SML and BML

SP and end-customer NMS development organizations—some large SPs and end-customers, responding to either the dearth (until recently) of NE vendor-provided EMSs or adequate ISV–provided NML, SML, and BML systems, have large in-house OSS development organizations

What Is the Typical Scope of Functionality Provided by Each Category?

The following are the typical expected levels of functionality for each category of EMS software providers. These statements reflect the general historical offerings of EMS software providers. EMS selection teams should determine the precise current offerings and planned enhancements for each EMS provider they are considering. The following observations correlate with the above numbering scheme for categories of EMS providers.

ISVs

These software providers have had reasonable success with the fault and alarm-management tasks of the service assurance function. It is relatively easy to parse ASCII–TL1 alarm streams from multivendor NEs and present a composite view. They have had less success with the service provisioning function. They typically offer little with respect to the EMS and NE operational efficiency function. Automation enabling with respect to other OSSs is often done via proprietary interfaces. Telcordia and TTI–Telecom have, however, successfully done some level of flow-through provisioning while working directly through the TL1 and PDS–NE interfaces. It is important to note that both companies now actively support the TM Forum CORBA standards. They recognize that full-featured management of diverse technologies will only be feasible by employing a well-supported standard EML–to–NML interface.

Tool and platform component providers and developers on an OEM basis typically provide their software and services to NE vendors who offer NE–vendor-branded and fully supported EMSs.

NE vendors

Those that provide EMSs only for their NEs and do not provide NML, SML, or BML systems typically provide EMSs that offer rich feature sets in all four functions of service provisioning, service assurance, EMS and NE operational efficiency, and automation enabling. These NE vendors focus on using open, standard interfaces to NML, SML, and BML systems. Their approach with service providers is "We will collaborate with the NML, SML, and BML vendors that you specify to ensure that our NEs are well-managed in your unique multivendor NE and multivendor OSS environment."

Those that provide EMSs for their own NEs and also provide offerings at the NML and possibly at the SML and BML have taken two approaches:

They act like an ISV and directly manage NEs from other vendors much like ISVs. They usually experience the same mixed results with respect to the level of features offered. For these software providers, managing other vendors' NEs directly was in response to the dearth of NE vendor EMSs with open, standard northbound interfaces.

This direct NE management approach is changing with the increasingly wider availability of NE vendor EMSs with standard interfaces such as ODBC and TeleManagement Forum–sponsored CORBA EML–to–NML interface. NE vendors who compete with each other now collaborate to have their EMSs interoperate with competitors' NML systems. Lucent Technologies, Nortel Networks, and Siemens AG are NE vendors that offer multivendor NMSs that support the TM Forum CORBA interface. They are also active in the evolution of the CORBA model.

Self-Test >>