The key challenge for service providers, original equipment manufacturers (OEMs), software vendors, and integrators is to develop TMN–conformant, robust applications that can perform varied network management operations in a changing, multivendor, multiplatform network. Service providers and independent software vendors need to deploy solutions that:

1. reduce time to market
2. reduce cost
3. support increasing demands for higher quality
4. incorporate legacy systems and are future-proof
5. conform to industry standards for TMN

Integrating Legacy Equipment

Legacy network equipment and systems, which are generally not TMN–conformant, understand ASCII messages, not TMN–conformant operations. The ASCII messages are often proprietary to a specific vendor or platform. TMN's standard interfaces provide for a machine-readable, programmatic interface to an NE's ASCII message-based or bitstream, informally-defined information model.

By defining standard interfaces, TMN does not mandate that network elements themselves be replaced with CMIP–conformant hardware or management messages. By allowing for intelligent mediation components, Q-adapters, and MDs, TMN enables companies to bring all systems and equipment into a distributed, scalable, and interoperable managed solution.

A Q-adapter can impose a machine-readable, object-oriented structure on a flat proprietary or legacy information model. An example of an NE with an informal, flat information model would be an NE that is managed by ASCII–based TL1 messages. These messages are human-readable, but are formally defined only as hard-copy message definitions.

By using a Q-adapter to derive information from messages, and then interpreting between that information and an object-oriented, machine-readable form, a systems developer can expose a machine-manageable interface to the OS.

Figure 6. A Q-adapter Translates Between CMIP/Q3 and Proprietary Interfaces

Another use for a Q-adapter would be the integration of a legacy enterprise network into the TMN infrastructure. Most enterprise networks manage resources by using the SNMP services. By adapting between SNMP and CMIP, the legacy network can be brought into the TMN realm.

Sometimes Q-adaption is all that is needed to convert an NE's interface to one that an OS can use. Often, however, further refinement is needed. A MD can further reconstitute or impose structure on this interface so that it matches the OS application's expected format.

Standardized, Object-Oriented Programmatic Interface

The recently introduced TMN/C++ application-programming interface (API) is being promoted by NMF and is referred to as the NMF API. The NMF API offers a standardized, object-oriented API for telecommunications management applications. The architecture comprises three modular, layered APIs.

• A managed object interface (the GDMO/C++ API) provides a framework for accessing and implementing managed objects in a hierarchical, tree-like model.
• A service interface (the CMIS/C++ API) provides for the basic management information model services, which include:
  • the sending and receiving of requests and responses that create and delete objects, as well as get and set their attributes
  • the reporting of events that occur in the network
• A data interface (the ASN.1/C++ API) defines a role-independent interface to the data itself and to its encoding.

Figure 7. NMF's TMN/C++ High-Level API

Prior to the NMF API, there were already some widely accepted standard APIs for TMN applications. The most common was XMP/XOM, which provided a C-language API for managing objects. The utility of XMP/XOM as an API in the TMN domain, however, was hampered by its high degree of abstraction. It was and is generally perceived as difficult to use, and most TMN platforms that boast XMP/XOM compliance also offer more easy-to-use API layers to hide it.

The NMF API overcomes the difficulties of this previous API, and provides a more natural development language (C++), straightforward interfaces, and platform-independent exposed interfaces. The NMF API provides the following advantages:

• The NMF API's platform-independent API has reusable C++ classes, so interface codes can be reused across diverse applications from built-in NE agents to large applications for SML platforms. This reduces time to market, lowers development costs, and shortens the learning curve for a development team.

The NMF API also supports two distinct application types: specific and generic. Specific applications implement a static information model. Generic applications provide for changing management information and dynamically interpret network changes into the information model.

• Ease of use mandates that the programming language be the most natural for expressing the nature of managed resources as objects, so the NMF API uses the C++ language. C++, with its compartmentalized class representation, exposes the network's information model but hides its complexities behind the public methods and data types of specific classes.

• The NMF API provides for complete representation of the TMN model GDMO, common management information service element (CMISE), and ASN.1. Development efforts do not need to restrict functionality or to impose unnecessary limitations based on some subset of the information model.

Tools to Automate TMN–Conformant Application Building

Tools are available that automate the task of building TMN–conformant agent or manager applications. TMN agent and manager toolkits can be implemented and customized to match your company's GDMO/ASN.1 MIB representations. These products should have the following features in order to maximize the advantages of TMN and to most productively support a TMN infrastructure:

• dynamic information modeling—the ability to add or change the network configuration or functionality without reinstalling or recompiling applications and implementations

• automated prototyping—tools that can compile GDMO/ASN.1 information models and produce model-specific exposed C++ interfaces and other required reports and data formats

• system-management functions (SMFs)—generate, filter, forward, and log incoming events and alarms

• platform-independent interfaces and tools—testing and simulation tools that focus on the behavior of a manager or agent, not on its implementation; these tools should be able to act in the role of agent, manager, or both. MIB–building tools that help the developer to construct a GDMO/ASN.1–conformant information model for any managed network.

• Q-adaption capability or compatibility—the ability to interface to and thus integrate legacy NEs (such as TL1 message-based equipment types) as well as enterprise network systems (SNMP–based information)

• conformance to all TMN standards—implementation of service, data, and managed object layers of the NMF API, and support for specific and generic application types