Custom Search

Element / Network Management System

An element management system (EMS) manages one or more of a specific type of telecommunications network element (NE). Typically, the EMS manages the functions and capabilities within each NE but does not manage the traffic between different NEs in the network. To support management of the traffic between itself and other NEs, the EMS communicates upward to higher-level network management systems (NMS) as described in the telecommunications management network (TMN) layered model. The EMS provides the foundation to implement TMN–layered operations support system (OSS) architectures that enable service providers to meet customer needs for rapid deployment of new services, as well as meeting stringent quality of service (QoS) requirements. The TeleManagement Forum™ common object request broker architecture (CORBA) EMS–to–NMS interface heralds a new era in OSS interoperability by making the TMN architecture a practical reality.

The Role of EMS's in the Five-Layer TMN Hierarchy

The TMN architecture is a reference model for a hierarchical telecommunications management approach. Its purpose is to partition the functional areas of management into layers. The ITU–T defined the TMN architecture in 1988 and it is described in Recommendation M.3010 and other documents. The key benefit of this architecture is to identify five functional levels of telecommunications management: business management layer (BML), service management layer (SML), network management layer (NML), element management layer (EML), and the (increasingly intelligent) NEs in the network element layer (NEL). TMN segregates the management responsibilities based on these layers. This makes it possible to distribute these functions or applications over the multiple disciplines of a service provider and use different operating systems, different databases, and different programming languages. TMN calls for each layer to interface with adjacent layers through an appropriate interface to provide communications between applications, and as such more standard computing technologies can be used. The TMN M.3010 document allows for the use of multiple protocols. This means that open standards such as SNMP and CORBA are consistent with the TMN framework.
TMN model is simple but elegant and has been effectively used to represent the complex relationships within network-management architectures graphically. Originally based on common management information service element (CMISE), the object-oriented technology available at the time of inception in 1988, the model now demonstrates its flexibility with the recent adoption of technologies such as common object request broker architecture (CORBA), as we drive toward a more generic data-processing type of computing. This evolution of CORBA progressed in much the same way as SNMP led its generation of protocol adoption.

EMS's should, by strict adherence with the TMN model, communicate with their NEs by using the common management information protocol (CMIP). This, however, takes no recognition of the fact that most devices deployed in the marketplace use other protocols such as TL1, SNMP, and a variety of proprietary mechanisms. An efficient EMS communicates with its NE using whatever protocol is native to the NE. The effective EMS will also communicate with other higher-level management systems using protocols that are the most cost-effective to implement. Therefore, the TMN layering is achieved by using whatever protocols are appropriate.
The TMN–FCAPS model of OSS tasks is a useful construct and is often referenced. It is, however, too abstract to use to understand the operational contribution and economic value of EMS's.

Service providers (SPs) think in terms of work (and the related cost and time) that must be invested to provide service to customers. A good example of this is a 1997 study by the TeleManagement Forum (formerly the Network Management Forum [NMF]). This study, based on interviews with service providers, identified a number of high-level processes and supporting subprocesses that should be accomplished by each layer of the TMN architecture.

The TeleManagement Forum–defined, high-level processes for which the EML must provide the base data and operations are the following:
  • Service provisioning
  • Network development and planning
  • Network inventory management
  • Network provisioning
  • Service assurance
  • Network maintenance and restoration
  • Network monitoring and control

It is important to understand that EMS's make the link to the NML for tasks such as integrated faultmanagement and flow-through provisioning. The EMS also often provides planning and analysis data directly to the higher-level SML and BML applications via bulk-data-transfer-protocol interfaces. The NML basically has three primary functions:

  • Integrated fault management and causal analysis of multivendor and multitechnology networks
  • Integrated, single screen, end-to-end service provisioning of multivendor and multitechnology networks
  • Integration layer between the EML and the SML; this role is to bring together information from the EMS's that support it, and then integrate, correlate, and in many cases summarize that information, so as to pass on relevant information to service management systems (SMS's); that information generally relates to the characteristics of the network technologies involved but should describe an end-to-end view that is consistent across the (multiple) technologies that are usually required to support a specific  customer service; in the reverse direction, the NML receives information from the SML, processes it, and passes on relevant commands and data to the appropriate EMS; the EMS then sends specific commands to the NE.

EMS's with open, standard, northbound interfaces provide the solid foundation required for service providers to deploy the TeleManagement Forum–defined, high-level processes by applications at the TMN framework network, service, and BML's. EMS's also offer sign ificant value via cost- and time-reducing tasks provided in addition to enabling cost-effective development of the TeleManagement Forum high-level processes.

This tutorial supports and represents the value contribution of the EMS with a four-function model. This model incorporates all tasks performed by an EMS and includes the following:

  • Function 1: service provisioning
  • Function 2: service assurance
  • Function 3: EMS and NE operations support
  • Function 4: automation enabler

Topics 5 through 8 describe typical tasks that legitimately belong in the four-function domain of an EMS. These tasks represent significant potential cost savings and revenue generation for service providers. EMS's are now valuable components of the network in their own right and not mere extensions of the NE craft interface as EMS's have often been perceived in the past. Not all EMS's will perform all of these tasks; some will perform these tasks and more; and some will perform unique tasks that target the requirements of a particular NE.

This four-function model is meant  to serve as a useful guide to service providers for evaluating the array of choices for managing the  NEs in their own unique operating and business context. A user working through the EMS graphical user  interface (GUI) may accomplish some or all of the tasks within each of the EMS four-function model. Whether or not a specific function is accomplished via the EMS GUI depends upon whether or not the task is subsumed in an application performed at a higher level.

A Four-Function EMS Model:

Network EMS Software Architecture

An EMS's architecture should meet some of the following basic requirements:

  • It should provide the correct level of management functionality appropriate to the device and to the management environment.
  • It should be scalable to grow with the requirements and complexity of the network.
  • It should be distributable in order to support such scalability and to provide a level of high availability.

Database technology is a critical part of any credible EMS strategy. Figure 16 shows an example of element management–software architecture that meets the above requirements. Client Server interfaces that were traditionally proprietary or remote procedure call (RPC) are now evolving toward CORBA, distributed component object model (DCOM), Java/Web Server, or other proprietary interfaces.


EMS–Related Standards and Standards Organizations

ITU

The International Telecommunications Union (ITU) is the body charged with global responsibility for telecommunications standards. Their work is sponsored by service providers and PTTs from around the world, as well as large equipment vendors and national standards organizations. The ITU–T within the ITU has defined the TMN reference model for network management as well as the CMIP protocol and information models covering a range of technologies. The seminal reference document for the TMN model is M3010.
Web Site:
http://www.itu.ch

The original seven regional Bell operating companies (RBOCs) originally jointly owned Bellcore in the United States. It had a dual role in providing software for telecommunications management and defining standards for adoption by the RBOCs. These standards covered all aspects of telecommunications from physical cabling specifications to network management information modeling. Telcordia is now independently owned by SAIC and is addressing the network management of telecommunications networks using its existing technologies combined with advanced technology programs.
Web Site:
http://www.ericsson.com

Tele Management Forum

Tele Management Forum, formerly the NMF, is a nonprofit, global organization that provides the telecom industry with leadership on the most effective ways to streamline the management of communications networks and services. The Tele Management Forum SMART TMN program helps members develop pragmatic solutions for automating the key business processes necessary for success in today's competitive market.
Web Site:
http://www.tmforum.org

OMG

The Object Management Group (OMG) has a membership of over 800 software vendors, software developers, and end users. The OMG promotes CORBA as the middleware that's everywhere through its worldwide standard specifications: CORBA/Object Services, Internet Facilities, and Interface specifications. Established in 1988, the mission of OMG is to promote the theory and practice of object technology for the implementation of distributed computing systems. The goal is to provide a common architectural framework for object-oriented applications based on widely available interface specifications. In addition to its initial use for diverse information systems (IS) applications, CORBA has gained widespread acceptance as the object-oriented distributed computing protocol for network management applications. For this reason, the OMG has a separate telecommunication subgroup to ensure that the tools and methodologies evolve to meet the unique needs of the telecommunications application environment.
Web Site:
http://www.omg.org

SIF, ATMF, and ADSLF

These are industry bodies that, in general, promote standardization within their technology domains. In most cases, such standardization also covers management activities. The organizations typically define information models for managing the equipment and specify which management protocols are to be used.
SONET Interoperability Forum (SIF) Web Site:
http://www.atis.org/
Asynchronous Transfer Mode Forum (ATMF) Web Site: http://www.atmf.com
Asymmetric Digital Subscriber Line Forum (ADSLF) Web Site: http://www.adslf.com
 

Software Blogs - BlogCatalog Blog Directory
 
 
 
 

Make a free website with Yola