EMS Functionality Overview
The Element Management System (EMS) provides functionality to provision, manage and monitor network elements (NE).

As recommended by ITU-T, the Element Management System's key functionality is divided into five key areas - Fault, Configuration, Accounting, Performance and Security (FCAPS). Portions of each of the FCAPS functionality fit into the TMN models.

The following grid exhibits a subset of functionality prescribed by ITU-T and Telcordia for the key functional areas.

Effective Development Process for EMS
The different methodologies in managing the development process of EMS solutions can be broadly categorized into:

Considering the facts that the custom built solution is meant to address a set of problems for a specific business need, a custom software solution is not as flexible as the other two methods and is not considered as an effective solution to develop an EMS.

The intent of the following section is to outline differences between the framework and component-based development process.

In the case of framework-based approach, the entire framework is shipped as a monolithic solution for the entire grid of the FCAPS functionality. The framework is delivered to the equipment vendor as a defined set of libraries. The end-user has to customize and deploy the framework. Frameworks generally offer 85% pre-built functionality and 15% of customization opportunities.

In component based approach, only a core set of functionality is initially implemented. The percentage of pre-built functionality is different for each functional area. The percentages of pre-built functionality on each of the key functional areas are indicated in the Figure 2.

The pre-built customizable functionality components can be chosen depending on the type of Network element and the equipment vendor's requirements. Once the customizable components are selected, the components can be assembled together to construct an effective EMS solution.

Such an approach allows the customer to select the components they need for the network environment and reduce the overall cost of the initial solution. For e.g. many network elements do not require alarms correlation, performance metric collection and self-view. In such cases customer need not pay for these components reducing the cost of ownership. The following chart depicts the pre-built and customization percentages in a typical component-based approach. The exact percentages may vary based on the network element.

What are components?
Components are well defined and re-usable feature sets in the system. Interest in the reuse of previously developed components is nothing new.

The component-based development is a natural approach to a solution that transforms a development-intensive grind of code writing and bug fixing, to a more controlled assembly process.

System upgrade becomes the task of replacement of well-bounded functional units of the system. The component-based architecture is a deviation from the exciting approach of software development, which offers clear benefits of reducing the software development time cycle and improving the quality of the delivered applications.

Classification of components
Components are classified based on the level of abstraction and the impact caused by them. Components that are pre-defined for the key functional area are termed as core components and the components that the end-user/equipment vendor can choose to assemble while constructing the EMS are termed as auxiliary components.

The auxiliary components are added to the EMS based on the requirements of the network element and/or by the service provided by the network element.

Again, the addition of components has an impact on the different layers of architecture.

High level Architecture
The following section details the various components participating in the EMS.

CONFIGURATION SERVER
The configuration server is implemented as the middle tier solution. The major function of the configuration server is to act as the façade to the EMS clients. This functionality has been implemented in CORBA/EJB.

Any operational sequence from the client is passed through configuration server. Some of the general tasks are parametric validation, security validation, data fetch, code upload, alarm acknowledge, accounting and creating task schedules.

Technology

DEVICE ADAPTER
The device adapters responsibility is to communicate configuration information to the device and to get information from the device. The device adapter has additional components that are transport dependent, which communicates to the network element.

Technology

FAULT MANAGER
The fault manager performs the key functionality of fault and log management. The basic components of the fault manager are the listener and publisher. Additional components can be added to the fault manager based on the requirement of the EMS

Technology

PERFORMANCE MANAGER
The performance manager is responsible for collecting data from the device at scheduled interval of time. They provide real-time support for receiving diagnostics and metrics data from the device and also to publish the metrics data to configured listeners

Technology

DATABASE SERVER
The database server is used to persist the data. The schema represents the data and the persistence logic of the EMS. To increase the availability of the data, the databases are replicated. The databases need to support heavy transaction rates since there might be multiple listeners configured to listen for alarms and events from the network elements.

Technology

Components and Responsibilities
The data centric portion, which involves multiple interactions to the database, is implemented as stored-procedures and database object solutions. Hence all the stored procedures are candidates of components. The stored procedures can be added/removed while deployment.

WEB SERVER
The web server's responsibility is to cater the requests from the EMS clients. The servlet container/web server hosts the servlets that access the middle tier for operational requirements.

The generic architecture of the EMS Solution is as depicted in Figure 3.

The entire component based approach is as depicted in the following Figure 4. The figure depicts in detail, a complete list of all the components in the model and their interaction for an EJB based deployment.

Since the EMS has to exhibit high availability and reliability, all the server-based solutions can be deployed in multiple servers. This improves scalability and reliability for the EMS solution. A typical blueprint of the deployment model is exemplified in the following diagram.

Case study of CBA - Fault Manager
This sections attempts to expose the insight of the component based design approach used in architecting the fault manager.

However this section does not deal with entire architecture. The major tasks of the fault manager could be summarized as follows

Core Components – Fault Manager
As described above, the core components are the components that are required to implement the minimal functionality of the fault manager.

In this case, the core components would be

Listener components would be to listen to the alarms from the device and/or other components. The listener could implement SNMP, CMIP or TL1 to listen to the events.

Publisher component would publish the events to the clients.

Auxiliary Components – Fault Manager
The following are some examples of auxiliary component and the possible causes to add them into the EMS. This list is not encyclopedic; this is dependant on the key functionality and architecture.

How to add components in the Architecture?
The basic advantage of the component-based architecture is to leverage the fact that the components can be selected and assembled together to make the EMS.

The section deals with a typical solution of adding components and enhancing an EMS using components based approach.

REQUIREMENT
Assume that the EMS has multiple listener components attached through its southbound interface. In this case, there would be heavy traffic, as multiple devices may raise events hence there is a pressing demand for adding an EVENT QUEUE component that improves performance. This component improves performance since, they store the events and the consumer can consume the events asynchronously.

SOLUTION
In this case, as explained the fault manager starts all the components, the listeners (SNMP, TL1), the event queue and the publishers.

The fault manager holds the information of the components and also the component registration information.

So the case of the registration is modeled as

So when the event pops up in the Listener component, the router of the listener transmits to the Event Queue back again, the router of the event queue transmits to the publisher. This is the mechanism with which the inter-component communication is effected.

Standards adhered
The following standards were adhered to, when architecting the component-based architecture.

Benefits of Component Based approach
The benefits of the components based approach have been discussed throughout the paper.

The following summarizes the benefits of component-based approach: