WebNMS White Paper Motorola (NSN) Element …4900 Hopyard Rd., Suite 310 Pleasanton, CA 94588 USA +1 925 924 9500 WebNMS White Paper Motorola (NSN) Element Manager HRPDA (EMH) 4 Configuration

4900 Hopyard Rd., Suite 310Pleasanton, CA 94588 USAwww.webnms.com+1 925 924 9500

2012 ZOHO Corporation WebNMS is a trademark of ZOHO Corporation

All other trademarks are property of their respective owners.

Motorola EVDO Data Call Management system named EMH—Element Manager HRPDA—has two types of Network Elements, namely the Shelf-M Software residing in an ATCA Cage hardware and MCC-DO Software that are installed in the call routing base stations. The Shelf-M Software communicates to the external world via a Motorola-specific proprietary protocol named CNEOMI. CNEOMI uses SNMP as the base protocol with its own specifications to perform Method Invocations, maintain sequences, etc. MCC-DO communicates via SNMP. The Shelf-M software resides in a Cage containing 14 blades, each having a hardware slot with Monte Vista Linux installed on them.

Since the amount of management activities to be performed on the Network Elements is huge, the EMS was built as a distributed system. The EMS contains two different applications: one is the WebNMS Back End and Front End combo named as the EMH Core Server, and the other is the Management Server equivalent, the EMH Mediation Server. The EMH Core is the centralized repository of the Management data and it directs the Mediation Server to perform the management activities. It can also directly talk to the Network Elements as needed. The EMH Core also acts as an interface to the Motorola Northbound Client named AEMS which directs the EMH Application to perform the management activities. The EMH Mediation Server performs most of the Network-Facing functionalities on the Network Elements. The EMH Core and Mediation Servers are all designed with Failover Mechanism, Load Balancing of the Management Activities assigned to the Mediation Servers, etc. Each section below talks about the functional management modules and the way each is achieved in the EMH System using the WebNMS Framework product.

WebNMS White Paper

Motorola (NSN) Element Manager HRPDA (EMH)ContactEric WegnerBusiness Development ManagerWebNMS, a division of ZOHO [email protected]


WebNMS White PaperMotorola (NSN) Element Manager HRPDA (EMH)

2

EMH Core ServerThis Back End/Front End combination of the WebNMS Framework acts as the centralized repository of all the Management Data (Inventory, Fault, Performance and Configuration Tasks, etc.). The EMH Core has a Northbound AEMS Interface which receives requests from the Motorola OSS Client. It also notifies the OSS about the Fault and other intimations which are received from the Network Elements. The EMH Core stores the data to a replicated database. In addition to the OSS client, management activities like Provisioning, Configuration, and Fault Management activities can be initiated in the EMH using the EMH Configuration Management GUI. The EMH Configuration Management GUI is built using the WebNMS Client Framework. The various functions that the client is capable of are captured under relevant sections.

EMH Mediation ServerThe Mediation Server performs all the Network Facing functionalities. The EMH System can have one EMH Core Server (with Standby for failover) and any number of Mediation Servers which are installed in different cards in the ATCA Cage. This architecture is to enhance the scalability and performance of the overall system. The EMH Core communicates with the EMH Mediation via a TCP Communication channel. The EMH Core sends commands to all the Mediation Servers if any action has to be performed on the NE. The Mediation also listens for the INFORM and Trap Notifications from the NEs and sends them across to the Core via the TCP Communication Channel.

Provisioning & DiscoveryThe Network Elements are added to the EMH System using the EMH Configuration Management GUI. The Configuration Management GUI has two different wizards created using the WebNMS Chassis Framework to add the two types of Network Elements. There are validations performed to check the number of slots available and the overall system capacity and a set of pre-defined rules while adding the Network Elements. There will be associations and mappings created between the associated Network Elements while provisioning them itself. After the provisioning, the EMH Core will try to discover the Network Element and synchronize it with the desired configuration including the software version and the various call-processing components that are to be installed on the target hardware. The various managed objects in the system are handled as extended Managed Objects with the required Containment hierarchy using the WebNMS Framework Topology Module API. After successful initialization, the EMH Core Server will assign the Network Element to an available Mediation Server after load balancing. In addition to the Network Elements, in EMH Solution, the EMS and the Mediation Server instances will also be modeled as a Managed Object and they are managed for their Faults, Software Version, etc.

Fault ManagementManaging the Faults is one of the important functionalities in any Network Management System. In EMH, the WebNMS Framework’s Trap Filters are used to receive the INFORM Notifications from the NEs. Notifications will be listened at two different ports to handle large incoming event rate. Both the Core Server and the Meditation Server are capable of receiving the Notifications as the initialization sequence and Status Polling of the Network Elements are based on the Incoming Notifications. The Notification Receiver framework is also used to retrieve response messages as INFORM Requests and Traps which notify of an action completed in the NE which was triggered by the EMH System. The Notification Receiver is easily configurable with a new set of Notifications without code changes as the Notification Receiver parsed the Notifications based on a configurable XML file.



3

Northbound AgentThis is the Northbound JMX SNMP Adaptor layer implemented using the Agent Toolkit Java Edition Product. This is integrated into the NMS as a separate Module using the Module integration functionality of the WebNMS Framework. This takes care of processing the OSS CNEOMI Requests. The Agent is also responsible for forwarding the Notifications from the EMH to the OSS.

SynchronizationIt is a mandatory requirement in all the Network Element Management systems that the data that is present in the NMS database be in sync with that of the Device status. Hence there is a need to perform synchronization with the Devices during planned maintenance cycles or after a failover or unexpected network breakages. The EMH System performs all the necessary types of synchronizations like the Inventory Information, Fault Information and Software Information that is available in the Network Element is in sync with what the information it has. Various synchronization activities are performed using various WebNMS functional modules. The synchronization can also be triggered manually using the Northbound Interface.

Event CorrelationSince there are lot of associations and mappings between the managed entities in the EMH System, there are possibilities that the same fault scenario can trigger two or more notifications from different entities. Hence there is a strong and compelling need to have a Correlation engine for the Fault generated and the various state transitions of the Managed Objects. The EMH Correlation Engine is so powerful that it takes care of avoiding duplicates, consolidating events, suppressing events based on the state change of the Managed Objects all based on a configuration rules file and a configurable timer window.

Performance Management In EMH, the Performance Data will be retrieved from both of the Network Elements by sending SNMP Set Requests. The NEs will upload a binary file to the Mediation Server and send a Notification informing of the file transfer completion. The Mediation will parse the received binary file and convert them to a CSV file and transfer it to the Core. The EMH Core will perform concatenation of the files from various Mediation servers and create a consolidated archive file.



4

Configuration ManagementThe WebNMS Configuration Managements is largely used for the EMH functionalities. Activities like Software Load Management, Test Management, Performance Management, etc., all use the NMS Configuration Management Task API. Each operation that is performed on the Network Element will be a SNMP Set Request and will have its own pre-requisites to be satisfied. There is a sequence of flow for each operation and there will be response handling for each request. All these are handled using the WebNMS Framework’s Configuration Management APIs.

Software Load ManagementIn the EMH System, Software Synchronization is one of the most important functions. The EMH, as part of the initial communication with the Network Elements, will synchronize the software version that is running on them as needed. The EMH itself can be upgraded or downgraded by the OSS automatically. The software upgrade process will take care of updating the Standby, Active Cores, and the Mediations all seamlessly.

Load Balancing Of Network Elements Across Mediation ServersIn the EMH distributed architecture, there is a need to distribute the Network Elements that are being managed evenly across the available mediations. This implementation was done in the EMH based on the Network Element type and the number of them in each Mediation Server.

Other ImplementationsIn addition to the various functional modules that were mentioned above, the EMH system has additional functionality such as License Management, Neighbor Management, Call Trace Management, etc., using the NMS Framework’s APIs.

ContactEric WegnerBusiness Development ManagerWebNMS, a division of ZOHO [email protected]



5

Customers

Documents

WebNMS White Paper Motorola (NSN) Element …4900 Hopyard Rd., Suite 310 Pleasanton, CA 94588 USA +1 925 924 9500 WebNMS White Paper Motorola (NSN) Element Manager HRPDA (EMH) 4 Configuration