PDF of this tutorial
Figure 12. The NOC as It Would Be if TMN Stopped at the EML
An EMS acts as the sole repository of all management information for its domain. It offers summarized views of that information as well as command and control capability to the NML via a northbound interface. Therefore, the EMS performs the following functions.
- information storage—requires the EMS to store all the management information collected from the NEs
- modeling of EMS domain—involves the creation of an appropriate information model with which to organize the storage of the management information and through which to offer control of the subnetwork
- normalization of EML—involves mapping the specific information model of the EML onto a generic subnetwork model recognized by the NML; this mapping effectively hides the unique specifics of the NE layer and exposes a generic subnetwork model that is technology independent.
- northbound interface—involves support for a specific protocol or mechanism for distributed communications between the EMS and the NMS; this interface is used to enable management-system automation whereby NE resources can be controlled indirectly from the NMS GUI without the intervention of an EMS operator.
- single screen multivendor cross-domain management—requires the EMS to send over the northbound interface, the information required by an NMS to provide integrated multivendor end-to-end management from a technology and NE–vendor independent human interface; for those functions that are best provided by the EMS interface, a cut-through mechanism enables NMS NOC technicians to open a window on their NMS workstation screen directly into the EMS; this window can be on the screen at the same time as the related NMS screen.
Representative Northbound Interfaces
- TL1—northbound interface to send filtered alarms to an NML fault management system and, for some EMSs, a bidirectional TL1 interface for flow-through provisioning from an NML system
- ODBC—interface for bulk data transfer to either an EMS report generator or to external analysis and reporting applications and, for some EMSs, a bidirectional open database connectivity (ODBC) interface for flow-through provisioning from an NML system
- SNMP—interface for less complex NE–EMS systems to send traps (faults) to an NML fault management system and, for some EMSs, a bidirectional SNMP interface for flow-through provisioning from an NML system
- Q3/CMISE—bidirectional CORBA interface from the TeleManagement Forum for advanced NEs to send filtered alarms to an NML fault management system to enable flow-through provisioning from an NML
A Breakthrough in Open EML–to–NML Interfaces
The TeleManagement Forum CORBA "NML–EML Interface for Management of SONET/synchronous digital hierarchy (SDH) Networks" project heralds a new era in OSS interoperability. This is a ground-braking effort in developing an interface that will make it easier for service providers to manage their multivendor networks from a single client workstation (see Figure 13).
Figure 13. A Breakthrough in a Global Open EML to NML Interface Standard
The initial group of companies that developed the first draft specification included Fujitsu, Lucent Technologies, and Tellabs. This group of companies focused their joint effort on the element management layer to network management layer (EML–to–NML) interface using CORBA as the basis for the open interface. This was demonstrated at the NFOEC Conference in Orlando, Florida (September 1998) and the TeleManagement World Conference in Dallas, Texas (October 1998). The NML system was the Lucent ITM–NM network management system implemented on a UNIX platform (see Figure 14). It communicated via CORBA interfaces to the following:
- a Fujitsu NETSMART™ EMS implemented in Java on a Sun Solaris™ platform that managed an OC–3 UPSR ring with FLM™ 150 ADMs
- a Tellabs TITAN™ 5500 EME, using Euristix RACEMAN™ technology based on Windows NT™, that managed a TITAN 5500 SONET wideband digital cross-connect system
- a Lucent ITM–SNC™ EMS implemented on a UNIX platform that managed an OC–3 UPSR ring with Lucent DDM™–2000 ADMs
Figure 14. The NFOEC and TeleManagement World Multivendor CORBA Configuration
The demonstration showed point-and-click, A-to-Z provisioning on the Lucent ITM–NM network management system of a DS–3 circuit from the A point on an ADM on the Fujitsu ring through the TITAN 5500 DCS to the Z end on an ADM on the Lucent ring. This was an industry first and will lead the way to wide implementation of standards-based, easy-to-manage, multivendor networks.
As of August 1999, the draft working group included the initial three companies plus Nortel Networks, Siemens AG, and Telcordia Technologies (formerly Bellcore). The draft working group presents its recommendations to the TM Forum for comment and revision. As of August 1999, the TM Forum Information Modeling (SSIM) Team consisted of representatives MCI WorldCom (service provider sponsor), Tellabs, Fujitsu, ADA, Ciena, DSC, ECI Telecom, Lucent Technologies, Nortel Networks, Siemens AG, Telcordia Technologies, TTI–Telecom, and Vertel.
Note: that at the September 1999 NFOEC '99 conference, the demonstration in Figure 14 was expanded to include NEs and EMSs from Nortel Networks, Siemens AG, and Telcordia Technologies (formerly Bellcore).
The initial TM Forum–approved CORBA model is TM Forum 509, released in September 1999. It is important to note that the TM Forum has approved development of extensions to the SONET/SDH model to encompass support for asynchronous transfer mode (ATM) and dense wave division multiplexing (DWDM) technologies. It is safe to predict that integrated, open, standard CORBA EML–to–NML modeled interfaces will support the emerging NE technologies.
Why is this important?
The rapid introduction of increasingly complex NEs has now made it virtually mandatory for providers of telecommunications equipment to offer a TMN–compliant EML–EMS application to support each unique NE type. Early versions of EMSs typically offered only a one-way fault management TL1 EML–to–NML interface. TL1 was offered because it provided a somewhat standard interface that NML system providers could reasonably implement in their multivendor NMSs.
To be competitive, SPs must quickly bring innovative services to market. This requires SPs to quickly deploy next-generation NEs and creatively apply them to meet end-customer needs. New NEs must be easy to integrate into the existing network management fabric for integrated fault management, flow-through service provisioning, QoS/performance management, billing, security, and—as applicable—end-customer network management.
Interconnecting the Upper Four TMN Layers
Typical pictorial representations of the TMN layered architecture as a pyramid or a vertical stack could lead one to believe that all transactions flow up and down and are processed at each layer. This is not necessarily true for the following reasons:
- Some applications, such as analysis and reporting of data collected by an EMS, may be retrieved directly via an interface such as ODBC by an SML application.
- All TMN–layer applications may not be performed by the same corporate entity; for example, a service provider may own the physical network and sell products and services to end-customers; that same service provider may also sell wholesale capacity to other service providers that sell their own branded products and services to end-customers; in this case, each service provider has its own SML and BML systems.
- Large-end customers increasingly want to buy network capacity and do the final stages of service provisioning via a service offering called customer network management (CNM).
- All service providers who buy wholesale from other service providers have QoS agreements that they must monitor and enforce; this requires OSS–to–OSS communication interfaces that are far different from an "up and down the TMN stack" that was envisioned by the ITU–T when it developed the TMN architecture in 1988.
Figure 15 depicts the fact that task-specific OSS–to–OSS communications based on task-appropriate protocols must be supported by applications at all the TMN layers.
Figure 15. Use of Appropriate Interface Standards to Match Work Flow Processes
