| |
| DMS Technology Overview |
The Dhyan Management System (DMS) is a flexible and powerful network management software technology that is the base for the customized NMS/EMS solutions we deliver to our customers. DMS is based on robust, standards-based technology that we customize and configure to provide management solutions in multiple market spaces.
DMS is the underlying technology for Dhyan NetMan, our telecom and data networking management suite, as well as Dhyan SmartMan, our Smart Grid management software for the energy market. Although each market, and indeed each customer, has certain unique requirements for the network elements to be managed, the interfaces required, and myriad product specifics, they share a need for certain core functions in the management system.
In this section we present our approach to developing software for a Network/Element Management System that can be used, and has been frequently been used, to provide high quality, high performance custom management solutions for a variety of network environments.
Note: for brevity, below we refer to an Element Management System (EMS), but the material applies to a Network Management System (NMS) as well.
|
|
| |
| EMS Functionality Overview |
The Element Management System (EMS) provides the functionality to provision, manage and monitor network elements.
As recommended by ITU-T, the Element Management System's key functions are 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 shows a subset of the functionality prescribed by ITU-T and Telcordia for each of the key areas. |
|
Fault |
Configuration |
Accounting |
Performance |
Security |
Alarm handling |
Auto Discovery |
Service Usage |
Performance Monitoring |
Prevention |
Alarm correlation |
Network provisioning |
Service level agreements |
Report Generation |
Authentication |
Alarm forwarding |
Auto back up and recovery |
Billing |
Data Collection and Correlation |
System Access Control |
| Filtering and Filter management |
Service Activation |
- |
- |
Detection |
| Log management |
Software upgrade to devices |
- |
- |
Intrusion Recovery |
Threshold based reporting |
Inventory management |
- |
- |
Containment and Recovery |
|
|
| |
| An Effective Development Process for an EMS |
The different methodologies for managing the development process of EMS solutions can be broadly categorized into these three approaches:
|
 |
Custom built solution |
|
Framework based solution |
|
Component based solution |
|
A custom built solution is meant to address a set of problems for a specific business need, and is sometimes the best solution for that need. However, since the requirements for network management will evolve over time, and different network designs require alternative features, a custom software solution is not as flexible as the other two methods. Therefore the custom solution is not an effective approach to developing an EMS technology base that can be used for a wide range of network scenarios and element types.
Therefore, a flexible, long term technology base for NMS/EMS applications would use either a framework or component based approach. The differences between the two approaches are outlined below.
|
| Framework |
With the framework-based approach, the entire framework is shipped as a monolithic solution for the entire range of FCAPS functionality. The framework is delivered to the equipment vendor as a defined set of libraries. The vendor then has to customize and deploy the framework. Because a framework product is monolithic, most functionality is unchangeable, with customization being done via API’s. Framework-based solutions typically have about 85% of the functionality pre-built and fixed, with the ability to customize the remaining 15%. |
|
| |
| Components |
In a component-based approach, only a core set of functionality is initially implemented, which allows more flexibility in adding new or substantially modified features. The percentage of pre-built functionality is different for each functional area. An example of the percentages of pre-built functionality on each of the key functional areas is indicated in 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 vendor to select the components needed for the network environment and reduce the overall cost of the initial solution. For example, some network elements do not require alarm correlation, performance metric collection and self-view. In such cases, the customer need not pay for these components, which in turn reduces 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. Reuse of previously developed components is not a new concept. In fact, 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 replacing of well-bounded functional units of the system. A component-based architecture offers the clear benefits of reducing the software development time cycle and improving the quality of the delivered applications, which in turn leads to a shorter time from beginning of a project to availability of the finished custom package. |
| |
| Classification of components |
Components are classified based on the level of abstraction and the impact that each one has on the overall system. Components that are pre-defined for a given key functional area are considered core components. Components that the end-user/equipment vendor can choose to assemble while constructing the EMS are considered to be auxiliary components.
In a typical Dhyan engagement, 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. Because of the breadth of components already developed by Dhyan, changes to the core components are seldom required. |
| |
| For More information |
| This section has provided a brief summary of one of the architectural tradeoffs that went into developing DMS, the technology used to develop our customized management solutions. For more information, or a product briefing, please get in touch via our page. |
| |
| |
