Nera NMS...XPIC or LAG+XPIC Nera NMS Technical Description Nera Proprietary and Confidential Page 9...

Copyright © 2019 by Nera Telecommunications Ltd. All rights reserved.

NERA NMS TECHNICAL DESCRIPTION

WIRELESS INFRASTRUCTURE NETWORKS NERA TELECOMMUNICATIONS LTD

109 Defu Lane 10 Singapore 539225

Nera NMS Technical Description

Nera Proprietary and Confidential Page 1 of 100

Notice

This document contains information that is proprietary to Nera. No part of this publication may be reproduced, modified, or distributed without prior written authorization of Nera. This document is provided as is, without warranty of any kind.

Statement of Conditions

The information contained in this document is subject to change without notice. Nera shall not be liable for errors contained herein or for incidental or consequential damage in connection with the furnishing, performance, or use of this document or equipment supplied with it.

Open Source Statement

The Product may use open source software, among them O/S software released under the GPL or GPL alike license ("GPL License"). Inasmuch as such software is being used, it is released under the GPL License, accordingly. Some software might have changed. The complete list of the software being used in this product including their respective license and the aforementioned public available changes is accessible on http://www.gnu.org/licenses/.

Information to User

Any changes or modifications of equipment not expressly approved by the manufacturer could void the user’s authority to operate the equipment and the warranty for such equipment.

http://www.gnu.org/licenses/



Table of Contents

1. Nera NMS system overview ....................................................................................... 6

1.1 Nera NMS functionality ................................................................................................................ 7

1.2 Supported Link Configurations .................................................................................................... 8 1.2.1 Supported Radio Link Configurations .......................................................................................... 8 1.2.2 Supported Ethernet Link configurations ...................................................................................... 9 1.2.3 Cascading interfaces .................................................................................................................... 9 1.2.4 Supported STM-1/OC-3 User Links ............................................................................................ 10

1.3 Licensing ..................................................................................................................................... 10

1.4 Standards ................................................................................................................................... 10

1.5 System Requirements ................................................................................................................ 10

2. Nera NMS architecture ............................................................................................ 10

2.1 Application server ...................................................................................................................... 11

2.2 Database server ......................................................................................................................... 12

2.3 Client .......................................................................................................................................... 12

2.4 Northbound interface to higher-order OSS ............................................................................... 12

2.5 Communication ports ................................................................................................................ 13

2.6 Nera NMS server High Availability ............................................................................................. 13

2.7 Nera NMS database High Availability ........................................................................................ 14

3. The graphical Nera NMS user interface .................................................................... 15

3.1 Function scoping ........................................................................................................................ 15

3.2 Discover perspective .................................................................................................................. 16

3.3 Geographical surveillance perspective ...................................................................................... 17

3.4 Logical surveillance perspective ................................................................................................. 18

3.5 Network Explorer perspective ................................................................................................... 19

3.6 Ethernet services perspective .................................................................................................... 20

3.7 TDM services perspective .......................................................................................................... 21

3.8 Alarm workflow perspective ...................................................................................................... 22

3.9 User management perspective .................................................................................................. 23

3.10 Security audit perspective ......................................................................................................... 24

3.11 Help system ................................................................................................................................ 25

4. Topology................................................................................................................. 26

4.1 Logical map view ........................................................................................................................ 26

4.2 Geographical map view.............................................................................................................. 27 4.2.1 Topological links ......................................................................................................................... 28

4.3 Network Explorer map view ...................................................................................................... 29



4.4 Logical tree view ........................................................................................................................ 30

4.5 Geographical tree view .............................................................................................................. 31

4.6 Network Explorer tree view ....................................................................................................... 32

4.7 Open SNMP Adapter .................................................................................................................. 32

5. Configuration management ..................................................................................... 34

5.1 Hardware inventory ................................................................................................................... 35

5.2 Software inventory .................................................................................................................... 35

5.3 Software download .................................................................................................................... 36

5.4 Transmission inventory .............................................................................................................. 37

5.5 Element software management ................................................................................................ 37

5.6 NE configuration file management ............................................................................................ 38

5.7 Report generator ....................................................................................................................... 39 5.7.1 Device performance reports ...................................................................................................... 40 5.7.2 Alarm reports ............................................................................................................................. 41 5.7.3 Inventory reports ....................................................................................................................... 41

5.8 Connection templates ................................................................................................................ 42

5.9 Using FTP/SFTP for data upload and download ......................................................................... 43

6. Maintenance Tools.................................................................................................. 44

6.1 Launch NE tools.......................................................................................................................... 44

6.2 CLI Script Broadcast ................................................................................................................... 45

6.3 Execute Ping and Traceroute ..................................................................................................... 46

7. Fault management .................................................................................................. 47

7.1 Network alarm status ................................................................................................................ 48

7.2 Alarm summary .......................................................................................................................... 49

7.3 Display Active Alarms ................................................................................................................. 49 7.3.1 Display historical alarms ............................................................................................................ 51

7.4 Audible notifications .................................................................................................................. 53

7.5 Email notifications ..................................................................................................................... 53

7.6 On-screen notifications .............................................................................................................. 53

7.7 Alarms customization ................................................................................................................ 53

7.8 Unmodified Trap Forwarding ..................................................................................................... 54

7.9 Alarm-to-service correlation ...................................................................................................... 54

8. End-to-end Ethernet and TDM service management ................................................ 55

8.1 Ethernet services ....................................................................................................................... 56 8.1.1 Flow domains ............................................................................................................................. 56 8.1.2 Flow domain best practices ....................................................................................................... 58 8.1.3 Managing Ethernet services ....................................................................................................... 59



8.1.3.1 Discovering Ethernet services ..................................................................... 59

8.1.3.2 Creating an Ethernet service ....................................................................... 60

8.1.3.3 Deleting an Ethernet service ....................................................................... 61

8.1.3.4 Renaming an Ethernet service ..................................................................... 61

8.1.3.5 Editing an Ethernet service .......................................................................... 61

8.1.3.6 Reapplying an Ethernet service ................................................................... 61

8.1.3.7 Reconciling an Ethernet service .................................................................. 62 8.1.4 Ethernet services – best practices ............................................................................................. 62

8.2 TDM services .............................................................................................................................. 62 8.2.1 TDM Domains ............................................................................................................................ 63 8.2.2 Managing TDM services ............................................................................................................. 63

8.2.2.1 Discovering TDM services ............................................................................ 64

8.2.2.2 Entering STM-1/OC-3 Link Information ....................................................... 64

8.2.2.3 Creating a TDM service ................................................................................ 65

8.2.2.4 Deleting a TDM service ................................................................................ 65

8.2.2.5 Renaming a TDM service ............................................................................. 66

8.2.2.6 Editing a TDM service .................................................................................. 66

8.2.2.7 Reapplying a TDM service ........................................................................... 66

8.2.2.8 Reconciling a TDM service ........................................................................... 66 8.2.3 TDM services – best practices .................................................................................................... 66

9. Performance management ...................................................................................... 68

9.1 Historical performance monitoring ........................................................................................... 68

9.2 Current performance ................................................................................................................. 70

9.3 Performance reports .................................................................................................................. 70 9.3.1 Overview PM report................................................................................................................... 71 9.3.2 Detailed PM report .................................................................................................................... 73

9.4 Network-wide PM reports ......................................................................................................... 74

10. Security management ............................................................................................. 76

10.1 Group administration ................................................................................................................. 76

10.2 User administration ................................................................................................................... 77 10.2.1 Remote user authentication ...................................................................................................... 77

10.2.1.1 Working with a RADIUS Server .................................................................... 78

10.3 Nera NMS licensing overview .................................................................................................... 79

10.4 License details ............................................................................................................................ 79

10.5 Obtaining and installing Nera NMS licenses .............................................................................. 81

11. Functionality table .................................................................................................. 82

12. NE support overview ............................................................................................... 86

12.1 NE support table ........................................................................................................................ 86

13. Appendix - Supported NE types ............................................................................... 89

13.1 Evolution XPAND IP+ family ....................................................................................................... 89



13.2 Evo XP-NexG ........................................................................................................................... 89

13.3 Evo XP-NexG LH ...................................................................................................................... 89

13.4 Evo XP-NexG Edge ................................................................................................................... 89

13.5 Evo XP-NexG Edge+ ................................................................................................................. 90

13.6 EvoTM XP-NGeX ........................................................................................................................... 90

13.7 Evo SmartLink ......................................................................................................................... 90

13.8 EvoTM SMLK-EHP ........................................................................................................................ 90

13.9 Evo Outdoor+ .......................................................................................................................... 91

13.10 EvoTM XP-NGeV .......................................................................................................................... 91

13.11 Evolution Series.......................................................................................................................... 92

13.12 SDH Mux BG-20/20E and BG-30/30E ......................................................................................... 94

13.13 Discontinued Support of Legacy Product Types ........................................................................ 95

14. Abbreviations ......................................................................................................... 96



1. Nera NMS system overview

Nera NMS is a comprehensive Network Management System offering centralized operation and maintenance capability for the complete range of network elements in the Nera product portfolio, consisting of all Microwave Radios, OEM and third party products. Nera NMS is based upon state-of-the-art technology as a scalable, cross-platform system that supports distributed network architecture.

Nera NMS offers full range management of all Nera network elements. It has the ability to perform configuration, fault, performance, and security management. Nera NMS is the user interface to all Nera transmission and access products. Nera NMS’s goal is to present Nera management networks in the simplest possible manner. The software has network auto-discovery and uses the configuration data in the network elements to automatically build the managed network. The various elements and their attributes may be accessed using the intuitive graphical presentation of the element and its components. Nera NMS provides a continuously updated display of network status. Network events are reported from the elements using notifications. An extensive database and context-sensitive help enables the user to analyze and report network events.

Nera NMS provides the following network management functionality:

Fault management

Configuration management

Performance monitoring

Ethernet and TDM service management

Security management

Graphical user interface with multiple maps

Network topology using perspectives and domains

Automatic network element discovery

HW and SW inventory

Software download jobs

Bulk setting of attributes on multiple elements

Report generator

Northbound interface to higher order OSS

Open SNMP Adapter

For a complete list of features, refer to Chapter 11, Functionality table.

Functionality is also maintained during network growth, ranging from the smallest single-server management solution to larger multi-server systems. High availability and reliability is provided through various redundancy schemes, including, optionally, server high availability and database high availability.



1.1 Nera NMS functionality

The Nera NMS system is scalable in both size and functionality.

The Nera NMS server is the basis for any Nera NMS system, providing basic functionality within the Fault, Configuration, Performance, and Security management areas. The NMS Server is by itself an advanced tool for performing operations and monitoring network elements for the entire operational network in real time. The flexible client/server architecture gives operators easy access to all network elements and full control of the system from many different locations.

By selecting from among a set of optional features, the Nera NMS system can be enhanced and tailored to each operator’s individual needs and requirements. With all optional features installed, the Nera NMS system provides the operator with an advanced and sophisticated network management system that will highly increase the efficiency of operations and maintenance in the network.

Nera NMS can handle up to 1000 traps per minute.

For easy integration with external higher-level management systems, a Northbound SNMP interface can be provided.

A complete functionality table for the Nera NMS system appears in Chapter 11, Functionality table.



1.2 Supported Link Configurations

Nera NMS supports numerous link configurations. This section presents a summary of which link configurations are supported by Nera NMS.

1.2.1 Supported Radio Link Configurations

Nera NMS can manage the following types of radio configurations for Evo XP-NexG network elements:

Evo XP-NexG Evo XP-NexG LH

Evo XP-NexG Edge

Evo XP-NexG Edge+

Evo SmartLink

EvoTM SMLK-EHP

Evo Outdoor+

1+0 Radio link

1+1 HSB Radio Protection

Groups

2+0 Radio LAG groups

2+0 Radio LAG groups

with XPIC

2+0 XPIC groups

Multi-Carrier ABC (Multi-

Radio) N+0 groups, where

N can be 1 through 8

Multi-Carrier ABC of Radio

Protection Groups 1+1

w/wo XPIC



w/wo XPIC



with SD



with SD

Multi-Carrier 2+0

Multi-Carrier 2+0 with

XPIC

MIMO 2*2 w/wo LAG or

XPIC or LAG+XPIC

MIMO 4*4 w/wo LAG or

XPIC or LAG+XPIC

1+0 Radio link space

diversity w/wo LAG or

XPIC or LAG+XPIC



Note: The radios in a Multi-Carrier ABC group can also be members of an XPIC group.

Nera NMS can manage the following types of radio configurations for Evolution XPAND IP+ network elements:

1+0 radio link

1+1 Radio Protection Groups

1+1 Radio Protection Groups with Space Diversity

1+1 Radio Protection Groups with Frequency Diversity

2+0 XPIC Groups

2+0 Multi-Radio Groups

2+2 HSB Protection Groups

2+2 HSB Protection Groups with Multi-Radio

Nera NMS can manage radio links between Evo XP-NexG / Evo XP-NexG Edge+ devices with an RMC-A card, and Evolution XPAND IP+ R3 or Evolution XPAND IP E+ R3 devices with software releases I7.0, I7.1 and I7.2, where the radio links are in any of the following configurations:

For Evo XP-NexG units: 1+0, 1+1 HSB, and 2+0 LAG links. Note that on the Evolution XPAND IP+/IP E+ side, the LAG must be between slots in a shelf, not separate standalone units.

For Evo XP-NexG Edge+ units: 1+0 and 2+0 LAG Links. Note that on the Evolution XPAND IP+/IP E+ side, the LAG must be between slots in a shelf, not separate standalone units.

Nera NMS can manage the following types of radio configurations for XPAND IP network elements:

1+0 radio link

1+1 Radio Protection Groups

Multi-Channel ABC N+0 groups, where N can be 1 through 8

Note: The radios in a Multi-Carrier ABC group can also be members of an XPIC group.

1.2.2 Supported Ethernet Link configurations

Nera NMS can manage the following types of Ethernet interface configurations:

Standalone Cross-Connect

LAG groups consisting of Ethernet ports

1.2.3 Cascading interfaces

Certain Evo XP-NexG interfaces can be configured to operate as cascading interfaces. Cascading interfaces can handle hybrid Ethernet and Native TDM traffic, enabling operators to create links among multiple Evo XP-NexG units in a node for multi-directional applications based on hybrid Ethernet and Native or pseudowire TDM services. Nera NMS supports cascading interfaces and services that pass through cascading interfaces.



1.2.4 Supported STM-1/OC-3 User Links

STM-1/OC-3 links between a pair of Evo XP-NexG devices or a pair of Evolution XPAND IP+ devices are not automatically discovered by the Nera NMS. A wizard is provided so that the Nera NMS may be informed of such links. The Nera NMS can then manage services over the STM-1/OC-3 links. In some cases these User Links may allow two TDM Domains to be merged into a single domain.

1.3 Licensing

The use of Nera NMS components and features is based on a licensing scheme with a specific customer license file. A Nera NMS license is linked to an active network card in the server. For more information, refer to Nera NMS licensing overview.

1.4 Standards

Nera NMS functionality is based on international recommendations and standards. The following recommendations are applied:

General:

TMF608 MTNM information agreement

Fault management:

ITU-T X.733 alarm reporting function

ITU-T X.734 event report management function

ITU-T X.735 log control function

ITU-T Q.821 alarm surveillance

Performance management:

ITU-T G.826 end-to-end error performance

ITU-T G.784 SDH management

1.5 System Requirements

Refer to the Nera NMS System Requirements document for details on supported operating systems, database versions, HW requirements, etc.

2. Nera NMS architecture

The scalable and distributed Nera NMS architecture gives network operators great flexibility on how to implement, operate, and manage communication networks of various types and sizes. As a network grows, Nera NMS can be scaled accordingly, from a small compact single-server configuration to a large distributed system.

The database server can be setup on the same machine as the Nera NMS server and/or Nera NMS client, or it can be setup on a separate machine.



Nera NMS in a small network

Nera NMS in a large network

2.1 Application server

The application server manages the interaction of all Nera NMS system components. It runs continuously in the background as a service.

The application server, initially developed for Microsoft Windows systems, is also supported for the Solaris 10 operating system. It is based on JAVA/J2EE technology, and is therefore suitable for porting to other platforms as well.



2.2 Database server

The database server stores all data used by the Nera NMS system. The Nera NMS management system supports database products from two different origins:

Oracle, a commercial, proprietary database software vendor

PostgreSQL, a freeware, open-source database software project

For details:

Oracle databases: http://www.oracle.com/database/

PostgreSQL database: http://www.postgresql.org/

Supported database versions: refer to the latest Nera NMS System Requirements document.

2.3 Client

A client provides the user interface to the active services and the network managed by the server. Up to 50 clients can be logged on to the server simultaneously. Clients can be installed separately and are launched on demand and connected to the Nera NMS application server.

Client and server are connected on a TCP/IP based LAN. Interactions between client and server are based on JAVA RMI.

A Nera NMS client can be installed on Microsoft Windows or Sun Solaris platforms.

2.4 Northbound interface to higher-order OSS

The Nera NMS architecture supports an open interface to higher order management network systems or other business operations components.

The Nera NMS SNMP agent provides an FCAPS interface for any SNMP-based network management system to perform fault and inventory management in networks managed by Nera NMS and additionally, PMs may be collected via FTP or another file management system. The agent provides topological information according to the standardized ENTITY-MIB (RFC 2737), and alarm state of the various network elements through proprietary tables and variables given in the proprietary NERA NMS-MIB. State changes are communicated to managers by means of SNMP traps. Nera NMS also enables forwarding of unmodified traps received from NEs to higher-level managers, with an option for using SNMP v3 for alarm forwarding.

The SNMP agent is a specialized client that logs onto the Nera NMS server with a user ID and exposes a set of information through an SNMP interface. The only requirement for the user ID is that it be a member of the predefined "SNMP Agent" user group, or a group with similar action permissions. This gives good control over the part of the network that is exposed to the High Level Manager (HLM), as the resource permissions for the SNMP agent user group can be configured in detail in the exact same way as any other user group defined in Nera NMS.

http://www.oracle.com/database/

http://www.postgresql.org/



The Nera NMS SNMP agent is an optional feature, which requires a separate license. Inventory management is controlled by an additional license.

In addition, Nera NMS offers two different formats for management traps (traps generated by Nera NMS when a problem occurs).

2.5 Communication ports

Management communication between Nera NMS and a network element is based on one of the following:

SNMP over UDP/IP

HTTP over TCP/IP

Two different communication principles are used:

Polling of NE’s from Nera NMS

Notifications sent from NE to Nera NMS.

For specific port numbers in use for client/server and server/database communication, refer to the latest Nera NMS Installation Guide.

2.6 Nera NMS server High Availability

The Nera NMS server can be configured to provide high availability with geographical application redundancy in which two Nera NMS servers are configured so that one is the Primary server, and the other is the Secondary server. At any given time only one of the two servers is Active and the other is on Standby.

The Primary server is the Active server unless it has stopped. In case of failure in the Primary server, the Secondary server becomes the Active server and the Primary server becomes the Standby server. When the Primary server is restored, it switches back to being the Active server (after a pre-configured grace period), and the Secondary server switches back to being the Standby server.

Nera NMS server High Availability is an optional feature, which requires a separate license for both the Primary and the Secondary Nera NMS servers.



Nera NMS server High Availability

2.7 Nera NMS database High Availability

Nera NMS can provide a database high availability setup, in which two Nera NMS databases are configured on separate machines so that one is the Active database, and the other is the Failover database.

At any given time only one of the two databases is active. If the machine hosting the active database is stopped, the server detects the failure and switches to the other (failover) database which then becomes the active database. When the machine that stopped is restarted, the database on that machine becomes the failover database.

The currently active database is regularly replicated to the failover database, at the replication frequency you define.

Note: Database high availability requires that Nera NMS server High Availability also be enabled.



3. The graphical Nera NMS user interface

The Nera NMS user interface enables users to easily navigate between views. The collection of views in the user interface reflects specific ways of working which are referred to as perspectives. The user can organize and move windows and dialogs individually within a perspective.

Nera NMS client GUI

There are nine predefined perspectives to help users navigate within the various working tasks:

Discover perspective

Geographical surveillance perspective

Logical surveillance perspective

Network explorer perspective

Ethernet services perspective

TDM services perspective

Alarm workflow perspective

User management perspective

Security audit perspective

3.1 Function scoping

All network elements shown in Nera NMS are associated with a set of available management functions. Depending on the network element type and user permissions, these functions will vary from element to element. Available scoped functions for a network or a domain are shown by right-clicking the corresponding element or domain icon, either in tree view or map view.



Commands executed from the menu line of the main GUI window are not scoped, i.e., they affect all managed objects in the network.

3.2 Discover perspective

The discovery process is the process by which Nera NMS identifies and manages new network elements. This process is performed from the Discover perspective.

Nera NMS discover perspective

The operator defines IP-address-based search ranges for discovering new elements. The IP addresses defining the range can be in either IPv4 or IPv6 format. The elements discovered in the defined search ranges automatically appear in an Unmanaged elements view.

From Unmanaged elements view, the user can decide which elements to manage. These elements are turned into managed elements by dragging them directly into the preferred domain in the Geographical tree view.



3.3 Geographical surveillance perspective

Geographical surveillance perspective is used for surveillance and management of network elements based on a geographical model.

Nera NMS geographical surveillance perspective

This perspective is tailored to the user whose main task and responsibility is to perform alarm surveillance in the network.

The Active alarms, Historical alarm, and Alarm summary views together with the Geographical map give the operator full control of the total network alarm status.



3.4 Logical surveillance perspective

The Logical surveillance perspective is used for monitoring and managing network elements based on a user-defined logical model.

Nera NMS logical surveillance perspective

This view is for monitoring and managing the network based on a logical model and includes an editor for creating and editing a visual representation of logical domains. The operator can create, browse, delete and move logical domains. The view enables including, moving, and deleting network elements. The domain structure can be used for assigning resource permissions to the user groups in the Group administration view. In the Logical map view / Logical tree view the operator can create domains and sub-domains corresponding to a logical grouping of the network elements.



3.5 Network Explorer perspective

In the Network Explorer perspective, users can monitor and manage NEs based on either the Geographical model or the Logical model. The choice of which model to link to this perspective, is set in the Network Explorer Preferences page.

Any change done to domains and NEs in the Network Explorer perspective, is automatically reflected in the model to which this Network Explorer perspective is linked, and vice versa.

Nera NMS Network Explorer perspective

The Network Explorer map view and Network Explorer tree view, together with the additional NE information provided by the Element Explorer view and link information provided in the Relation Overview view, are good starting points for various maintenance and surveillance tasks regarding configuration and performance of NEs.



3.6 Ethernet services perspective

In the Ethernet services perspective, users can manage the provisioning of end-to-end Ethernet services by using the flow domain navigator, the Ethernet topology view, and the Ethernet services list.

Nera NMS Ethernet services perspective

The user defines Ethernet connectivity using the Flow Domain Navigator. Ethernet connectivity can be viewed using the Ethernet Topology view, which displays flow domains, managed elements, and Ethernet links.

Ethernet services are created using the Ethernet Services wizard.

The Flow Domain Navigator and Ethernet Topology views, together with the additional service information provided by the Ethernet Service Path, Ethernet Service Ports and scoped Ethernet Services views, give the user full control of the entire Ethernet network.



3.7 TDM services perspective

In the TDM services perspective, the user can manage the provisioning of end-to-end TDM trails by using the TDM Domain navigator, the TDM topology view, and the TDM services list.

Nera NMS TDM services perspective

Elements are grouped into TDM domains based on connectivity and by making initial use of the grouping in the Ethernet Flow Domain Navigator. The TDM subnetworks can be viewed using the TDM Topology view, which displays TDM domains, managed elements, and their TDM connections.

TDM services are created using the TDM Services wizard.

Information about existing STM-1/OC-3 links, which cannot be automatically discovered by Nera NMS, is entered into the Nera NMS database using the Create STM-1/OC-3 User Link wizard.

The TDM Doman Navigator and TDM Topology views, together with the additional information provided by the associated TDM Service Ports, TDM Service Path and scoped TDM Services views, give the operator full control of the total TDM network.



3.8 Alarm workflow perspective

Nera NMS alarm workflow perspective

Nera NMS provides a preset perspective that helps focus on the alarm workflow. The alarms initially appear in the Active un-acknowledged view, and eventually end up in the Historical acknowledged view. The two intermediate views show whether the alarm is cleared before it was acknowledged or vice versa.

The purpose of this perspective is to inform the user of all problematic situations in the managed network. The workflow focus helps the user to choose the appropriate corrective actions for both intermittent problems and more persistent issues.



3.9 User management perspective

The User management perspective handles users and user groups, as well as permission assignment and restrictions for user groups.

Nera NMS user management perspective

The User administration view is used to manage users: create new users, change passwords, and block, delete and/or allocate permissions by assigning users to groups.

The Group administration view is used to create user groups and assign permissions for each group. The user can control access permissions based on geographical and logical domains, as well as operational tasks.



3.10 Security audit perspective

The Security audit perspective is used for logging the events arising from user activities.

Nera NMS security audit perspective

The system administrator can block or delete user accounts to prevent unwanted operations.



3.11 Help system

Nera NMS offers an extensive help system describing the features and options, and guides the user through the operation of the program.

Nera NMS help system



4. Topology

The geographic and logical topology within Nera NMS provides a visual representation of the geographical and logical placement of the managed network elements. The network explorer topology mirrors either the geographical or logical models, as set by the user, and it provides additional link information between network elements.

The network topology can be represented in the following views:

Logical map view

Geographical map view

Network Explorer map view

Logical tree view / Hierarchical tree structures

Geographical tree view

Network Explorer tree view

Open SNMP Adaptor for discovering and managing SNMP elements that are not fully integrated into Nera NMS

4.1 Logical map view

The Logical map view is used for monitoring and managing your network based on a logical model. In the Logical map view, you can create domains and sub-domains corresponding to a logical grouping of network elements. Examples of logical models are:

Element type, element sub-type, etc.

Transmission capacity (e.g., 155/145Mb, 45/34Mb, 1.5/2Mb, etc.)

Logical map view



4.2 Geographical map view

The Geographical map view is used for monitoring and managing the network based on a geographical model and includes an editor for creating geographical maps. A map is built by creating a set of polygon objects reflecting the nature of the network, including logical or geographical clusters of objects, or single elements. Map objects may or may not have dynamic alarm coloring and state information.

The geographical map can be designed with several domains (regions) and sub-domains. It is possible to navigate between maps by clicking on map objects (domains, elements or other objects).

Geographical map view



4.2.1 Topological links

A topological link represents the physical interconnection between two managed elements, and is configured in Nera NMS by manual insertion. The topological links interconnect managed elements within the same domain. (Future functionality will enable inter-domain links.) The topological links may be displayed in GUI maps to show the connectivity in the managed network. If the end points of a link are associated with physical termination points in the end nodes, the link will display alarm coloring for the connection based on the status of the associated attributes.

Topological links



4.3 Network Explorer map view

The Network Explorer map view is used for monitoring and managing the network based on the model to which this view is linked - either the Geographical model or the Logical model. In addition, the Network Explorer map view displays the link name of each link, and the radio link ID of each radio link.

Network Explorer map view

The Relation Overview view, linked to the Network Explorer map view, provides detailed information about any relation selected in the map, whether it is a connection between two NEs, two domains, or between an NE and a domain.



4.4 Logical tree view

The Logical tree view is used for organizing and monitoring equipment based on a logical model of the network. This view enables users to browse the domains and each NE and its equipment (racks, ports, slots, ODUs, etc.). The view reflects the structure of each NE type.

Logical tree view



4.5 Geographical tree view

The Geographical tree view is used for organizing and monitoring the equipment based on a geographical model of the network. This view enables users to browse the domains and browse each NE and its equipment (racks, ports, slots, ODUs, etc.). The view reflects the structure of each NE type.

The Geographical tree view enables users to include, move and delete NEs.

Geographical tree view



4.6 Network Explorer tree view

This is a view for organizing and monitoring your equipment based on a hierarchical model of your network. The view allows you to browse the domains and NEs, create new domains, as well as to include, move and delete NEs


The Element Explorer view, which displays NE hardware configuration, is permanently linked with the Network Explorer tree so that each time an NE is selected in the tree, the Element Explorer view displays the selected NE’s hardware configuration.

4.7 Open SNMP Adapter

The purpose of Open SNMP Adapter is to discover and manage SNMP elements that are not fully integrated in Nera NMS. These types of elements are called open SNMP network elements (open SNMP NEs).

The following are the main features and capabilities of the open SNMP adapter:

Discover any SNMP equipment (SNMP version v1 and v2c)

Set any discovered SNMP equipment to managed state

Only NE node is shown in tree views

Connection polling

Allow configuration of launching of external tools

Allow configuration of alarm handling through Open SNMP Interface view:



◦ Reconcile current alarm table

◦ Reconcile current alarms given as single OIDs

◦ Reconcile current alarms given as single OIDs using a mask

Report - The NE Types Overview report displays a chart indicating how many elements of open SNMP NE type are managed by Nera NMS within the scope of the report.

Open SNMP Interface view

The view consists of an Open SNMP Configurations area containing a tree view with all configurations defined and an area containing details about the currently selected configuration.

Once created, an open SNMP configuration consists of four pages where the user can edit different settings needed to get information from the element:

Open SNMP Configuration

Alias List

Current Alarm Table

Current Alarm List

For an open SNMP configuration, it is possible to disable both strategies (Current Alarm Table or Current Alarm List) or enable only a single strategy at a time. When a strategy is enabled, the other one will automatically be disabled.



5. Configuration management

Nera NMS enables users to display and manage network element configurations. Common operational configuration functions are available to groups of similar NEs, making it easy to get an overview of the installed equipment and to perform maintenance operations on a large set of network elements in a single operation.

For detailed configuration of a specific NE, Nera NMS provides a function for scoped launching of the corresponding NE configuration tool.

Typical configuration operations are:

Display hardware inventory

Display software inventory/Activate software/Reset software

Manage software download

Manage NE configuration files

Display licensing view

Create reports

Scheduled clock synchronization of NEs

Security templates

Launch NE tools

Broadcast a CLI script to a group of devices



5.1 Hardware inventory

The Hardware inventory view displays an overview of currently available hardware with related data.

Hardware inventory view

5.2 Software inventory

The Software inventory view displays available software memory banks for the NE selection. Each row displays the status of a memory bank and details about the corresponding stored software.

SW components can be restarted or activated from this view.

Software inventory view



5.3 Software download

A software download wizard provides functions for downloading software from the network management system to multiple selected NEs in one single operation.

Software download job

When the software download job is created, the software download process can be monitored and managed through the Software Download Jobs view. This view displays details on all software download jobs performed from Nera NMS, including progress and status on the download processes for each individual NE included in a job.

The user can create new jobs, modify jobs, start and stop jobs, or schedule jobs for a future date and time from this view.

Software download jobs



5.4 Transmission inventory

The Transmission inventory view presents configuration information for managed radios.

Transmission inventory view

5.5 Element software management

The Element Software Management view enables you to upload device software zip files from an external FTP server to the Nera NMS server. The uploaded files may then be used in software download operations, as described in the Software download section.

Element Software Management view



5.6 NE configuration file management

For easy storage and restore of the NE configuration settings, a utility for NE configuration file backup and restore has been provided. This enables the Nera NMS operator to restore a network element to a previously used configuration, which can be useful in case of major hardware changes or complete re-installation at the radio site.

A configuration backup can be manually created at any time, for one single NE, a domain or a complete network. The backup will be time-stamped and tagged to the actual NE before it is saved to the backup file repository.

An automatic configuration backup can also be scheduled to occur at a specified frequency. The automatically-created backups are named and saved in the same fashion as the manually-created backups, and are listed and managed in the same Configuration File Management view.

The configuration of an NE can be restored by specifying the backup configuration file to use for the restore.

The backup and restore operations require the use of FTP/SFTP.

NE configuration file management

Valid configuration files acquired from other external sources can also be added to the Nera NMS configuration file management system.



5.7 Report generator

A separate report generator is included in the Nera NMS system. Most of the pre-defined reports can be run against data in the database with a user-defined scope: on a single NE, a domain, or a complete network.

A Scheduled Reports Preferences page enables setting the location where reports are saved.

Nera NMS report generator

The following report types are included:

Overview of the most frequently occurring alarms, overall and per NE

Overview of NE types managed by the Nera NMS system

Hardware/software inventory

Network G.826 Performance reports, overview and details.

Scheduled reports



Report output is shown as a separate view, which can be exported to PDF or Microsoft Office formats. An example for an exported Alarm frequency report is shown below.

Report output example

5.7.1 Device performance reports

An additional Performance Report mechanism provides, for a specific device, various types of performance reports depending on the device type:

Interface Performance Report

Radio Performance Report

RMON Report

Trails Performance Report

Enhanced Radio Performance Report

Enhanced Radio Ethernet Performance Report

The reports can be generated through the GUI or by using the pmreport command line interface (CLI) command. The reports display PM counters for all the enabled ports of the specified devices.



5.7.2 Alarm reports

An Alarm Reports mechanism enables generating reports listing all alarms, or Nera NMS alarms only, or alarms associated with specific devices or time periods only.

The Alarm Reports mechanism provides the following types of reports:

Alarm Log Report – listing current and historical alarms

Current Alarms Report– listing current alarms

Alarmed NEs Report – listing NEs ordered by number of alarms on the NE

Alarm Frequency Report – listing the most frequent logged alarms in the specified period

Alarm Frequency by NE Report – listing the most frequent logged alarms in the specified period, by NE

The reports can be generated using the alarmreport command line interface (CLI) command.

5.7.3 Inventory reports

An Inventory Report mechanism enables generating various inventory reports. The reports display up-to-date information regarding the link, and 24 hours of link PM counters.

The reports can be generated through the GUI or by using the inreport command line interface (CLI) command.

The Inventory Report mechanism provides the following types of reports:

Frequency Change Report – provides information about changes in Tx and Rx frequency of radio ports in network elements

Full Link Report – provides up-to-date information regarding the link as well as 24 hours of link PM counters

Network Element Report – provides status information and data about network elements

Radio Report – provides information about radio interfaces

Link Report – provides data about links, such as transmit and receive frequencies and slot number locations

Licensing Report – provides data about the licenses enabled for each network element

Versions Report – provides data about the software and firmware versions installed on network elements

Serial Numbers Report – displays the serial number for each network element



5.8 Connection templates

A Connection template contains a list of attributes used when setting up connections for this NE type. The available attributes are dependent on the NE type, and may include parameters for authentication, such as usernames, passwords, and SNMP community names. The Connection template may also contain attributes regarding polling of NE connectivity status, IP Address family, Trap Manager lists, NTP Server configuration, and UTC and DST configuration. For Evolution XPAND IP+ and Evo XP-NexG devices, the Connection template also includes the option of secured access to NEs using HTTPS and SFTP, the use of SNMP v3, and scheduling regular backup of devices’ configuration files.

Connection templates view

Connection templates are assigned to the various NEs through a Connection template assignment view.



Connection templates assignment view

5.9 Using FTP/SFTP for data upload and download

Nera NMS can function as an FTP or SFTP client for various tasks, such as software upgrade and configuration backup, export, and import. To use FTP/SFTP, you can install FTP/SFTP server software on the same machine as the Nera NMS server, and enter the settings of the FTP/SFTP server in the External FTP/SFTP Server Preferences page.

You can then upload various software files to Nera NMS and then download them to specified NEs.



6. Maintenance Tools

Various NE maintenance options are available from within Nera NMS. They include:

Launching a configuration tool for a selected NE

Running CLI commands contained in a script file on specified NEs, and viewing the output

Executing ping and traceroute on specified NEs, and viewing the results

6.1 Launch NE tools

For detailed configuration of individual NEs, Nera NMS provides a function to launch a scoped NE configuration tool for a selected NE.

The Administrator configures the external tools to be associated with the various NE types and can also link various attributes obtained from the server to corresponding launch arguments on the external tool (like IP address, NE identification, authentication credentials). The configuration tool for a specific NE can then be launched from the context menu on the NE symbol in the Nera NMS client.

NE configuration tools



6.2 CLI Script Broadcast

Nera NMS provides a convenient CLI Script Broadcast function that enables commands contained in script files to be issued to a user-selected list of Evolution XPAND IP+ and Evo XP-NexG network elements.

Nera NMS imports the text file containing the CLI script. A telnet session is established with each of the devices one at a time, sequentially, and in the order defined by the user. Each command in the script is issued over the telnet session. Commands are issued serially and only after the previous command has been completed.

The output appears on screen and can also be saved to a file.



6.3 Execute Ping and Traceroute

Nera NMS provides a function to execute a ping or traceroute for one or more selected NEs. The command is run on the group of devices you specify, in the order you specify. You can also set the ping parameter values (such as Packet size) and the traceroute parameter values (such as Max number of hops).

The output appears on screen and can also be saved to a file.

Ping/Traceroute view



7. Fault management

Nera NMS provides the tools for acquisition, storage, and presentation of alarms and events from the managed network.

Typical fault management tasks include:

Alarm acquisition in the form of notification reception from NEs

Display network alarm status in multiple ways

Coloring of graphical objects in the network views

Display new (un-acknowledged) alarms and old (acknowledged) alarms independently.

Propagation of the highest severity level upwards in the network display hierarchy.

Display alarm summary count

Display current alarms

Alarms acknowledging, un-acknowledging and commenting

Audible notifications upon severity level increase.

Display historical alarms; specify advanced filters/queries.

Customize alarms for selected NE types (alarm text, severity and blocking) for a selection of NEs through alarm templates.



7.1 Network alarm status

The status of the network and network elements is displayed through a graphical object coloring scheme in the graphical views. When the network is structured into a hierarchy of administrative domains, the alarm severity colors are propagated upwards in the hierarchy.

To ensure that new events are always in focus, there are two levels of alarm coloring and propagation:

The highest un-acknowledged (new) alarm severity status is displayed in the fill area of the graphical symbol.

The highest acknowledged (old) alarm severity status is displayed as a thin frame around the graphical symbol.

The graphical symbols in the map views also display the number of alarms of the highest severity for both acknowledged and un-acknowledged alarms. The coloring scheme used for each severity level can be configured in the Preferences dialog box.

Network alarm status



7.2 Alarm summary

The Alarm summary view displays an overview of all alarms for all managed NEs and provides a quick overview of the alarm status in the entire network.

The view displays the Severity count graph: a graphical presentation of alarms of each severity category in the entire network. The graph includes a bar for each of the categories Critical, Major, Minor, Warning, Indeterminate, and Info.

The view will only present active alarms, i.e., clearable alarms in a raised state, and not those that have been cleared. The same alarm state is presented in the Active alarms view.

Whenever an alarm is cleared on the equipment, it disappears from the Alarm summary view, but can be found in the Historical alarms view.

Alarm summary

By clicking one of the severity bars, a filtered Active alarms view containing the alarms of the selected severity level is opened.

7.3 Display Active Alarms

The Active Alarms view presents active alarms for a selected scope, and allows the operator to acknowledge alarms which have been followed up. By default, acknowledged (acked) and unacknowledged (unacked) alarms are presented in separate, side-by-side views.

An active alarm is a clearable alarm in the raised state (i.e., not yet cleared). Whenever an alarm is cleared, it is removed from the table, but can still be found in a corresponding scope in the Historical alarms view.



Active alarms – unacked only and acked only

Each user can select which attributes are shown in the alarms table and the order in which they appear. Users can sort the table in ascending or descending based on any column.

The Active alarms view contains two powerful filtering mechanisms for further drill-down within the current scope. It is possible to show or hide alarms based on their acknowledgement status, or, using an instant filtering function to show only alarms that contain a certain textual pattern in one or more attribute.

Alarm filters



7.3.1 Display historical alarms

Historical alarms include alarms that have been raised and then cleared, as well as events, which are non-clearable. The Historical alarms view displays, side-by-side, tables of all historical alarms and events, both acknowledged and unacknowledged, for a selected scope. Whenever an alarm appears in the Historical alarms table it will disappear from any table with the same scope in the Active alarms view.

Historical alarms

The advanced filter function in the Historical alarms view can help users analyze situations with errors or poor performance in the network. By studying other errors and the order they appeared for the NE, this view can help users to identify and solve the "root cause problem".

The Time slider function enables you to navigate quickly in a large data set. The Time slider displays a histogram of the number of alarms occurring along the time axis, and the area indicated with green color shows what time interval is currently presented in the alarm table. It is possible to expand this time interval, or to zoom in for a further detailed histogram.

It is possible to set up auto-refresh of the Historical alarms view.

A Historical Alarms Preferences page enables setting the maximum number of alarms you can view per read size in the Historical Alarms view.



The Historical alarms table can display the following fields for each alarm:

Historical alarms

Field Name Explanation

Resource Name Source of alarm - the network resource that generated the

alarm.

Alarm Text Displays the most likely reason for the alarm. Similar to "Native

Probable Cause", as defined in TMF608. This is a textual

description of the cause of the alarm, displayed exactly as sent

from the NE or portrayed in the EMS user interface. The text can

be customized using the Alarm Templates view.

Severity One of the possible alarm severities: Critical, Major, Minor,

Warning, Indeterminate or Info. Severities can be customized

using the Alarm Templates view.

Raised Time (NE) The time on the NE when the alarm was raised.

Cleared Time (NE) The time on the NE when the alarm was cleared.

Acknowledged Checked if the alarm has been acknowledged.

Probable Cause A mapping of the Probable Cause Qualifier and/or Native

Probable Cause with a set of predefined Probable Causes as

defined in TMF608.

Probable Cause

Qualifier

A code for uniquely identifying the alarm, e.g., used in the Alarm

Templates view.

Alarm type A text which identifies the type of alarm. Used internally to map

the alarm to a corresponding name.

The value is one of the following (as defined in TMF608 and

specified by X.733:EventType):

communicationsAlarm

environmentalAlarm

equipmentAlarm

processingErrorAlarm

qualityOfServiceAlarm

Raised Time

(System)

The time when Nera NMS received the alarm raised event.

Cleared Time

(System)

The time when Nera NMS received the alarm cleared event.

Is Clearable Y if the alarm/event represents a condition that will be restored

at a later time (otherwise blank).

Additional Text Alarm text extension.

http://127.0.0.1:50188/help/topic/no.nera.networks.ngnms.richclient.help/html/Alarm_Templates(en).htm



7.4 Audible notifications

Nera NMS is capable of playing selected sound files based on user configurable criteria such as alarm name, alarm severity and alarm type. The selected sound files can be played once or continuously until the raised or cleared alarm is acknowledged by the user. For elements under maintenance, the alarm sound may be temporarily or permanently disabled (muted).

7.5 Email notifications

Nera NMS can issue email notifications to selected recipients based on user configurable criteria such as alarm name, alarm severity and alarm type.

7.6 On-screen notifications

Nera NMS can issue on-screen notifications to selected recipients based on user configurable criteria such as alarm name, alarm severity and alarm type.

7.7 Alarms customization

Nera NMS provides functions for customizing the alarms through alarm templates. The predefined alarm text and severity level of individual alarms can be modified, and individual alarms can be blocked from being logged and reported.

Alarm customization templates

Alarm templates are assigned to the various NEs through an Alarm template assignment view.



7.8 Unmodified Trap Forwarding

Nera NMS provides the capability to forward to one or more OSS network management systems unmodified network element traps and events that arrive from network devices. In addition, Nera NMS also forwards management alarms, such as security, license, and redundancy. Trap forwarding is enabled and configured via the Northbound SNMP Settings view.

Northbound SNMP settings view

7.9 Alarm-to-service correlation

Nera NMS provides an Alarm to Service correlation feature. For each alarm raised on an Evo XP-NexG, Evolution XPAND IP+, or XPAND-IP device, the user can display a list of all the confirmed end-to-end services that are affected by the alarm. A single list of all Ethernet and TDM services is displayed. By selecting an individual service from the list, the user can navigate to the service perspective to display the complete details of the service.

Alarm-to-service correlation



8. End-to-end Ethernet and TDM service management

Nera NMS provides advanced functions for end-to-end Ethernet and TDM service management.

Network discovery

In addition to the automated discovery of NEs and general network topology, Nera NMS also performs automated discovery of the connectivity in relation to services. This means that all potential service-carrying connections are automatically discovered and offered as available resources for subsequent service provisioning.

Service discovery

Upon connecting to an existing network, Nera NMS offers automatic discovery of all services currently configured on each NE (dependent on NE capabilities). Any service that is discovered can, by operator decision, be included under Nera NMS management, or left “as is”.

Once managed by Nera NMS, the discovered services are covered by the same functionality as services created from Nera NMS, including Service Alarms, Service State, Service Editing, general Service Displays, and all reporting, statistics and historical data records.



Service creation wizard

Nera NMS provides two intuitive and powerful Wizards, one for Ethernet Services and one for TDM Services, that guide the user through the entire service provisioning workflow. Services are created by automated routing between the selected end points.

The path of the service being created is displayed to the user before the user confirms the creation of the service.

Service monitoring

Managed services are monitored for operational state (“Service State”, i.e., enabled, disabled, pending, and various fault states). Alarms that are generated on the ports involved in a service are associated with the service in order to provide the alarm state of each service (“Service Alarms”).

Highest Alarm Severity

For each service, the severity of the most severe alarm currently raised on the service is displayed.

8.1 Ethernet services

8.1.1 Flow domains

In the Ethernet services perspective, the devices deployed in the network are divided into domains that are referred to as Flow Domains. Each flow domain contains a group of devices from the same family (Evolution, Evolution XPAND IP+, Evo XP-NexG) that have Ethernet connectivity between them and are of the same VLAN Type, either C-VLAN or S-VLAN.



Note that Ethernet connectivity may be achieved over various physical media: Category 5 cables, single (1+0) radio links, a pair of radios configured as a radio protection group (1+1), a pair of radios configured as an XPIC group, multiple radios in a LAG group, or multiple radios in a Multi-Carrier ABC group.

Dividing the network into flow domains provides the following advantages:

The network view is simplified.

Management of the whole network is partitioned into smaller “clouds”.

Different technologies are contained / hidden within separate domains.

The network details are hidden so that services can be rapidly and easily configured.

The following diagram shows a network of Evo XP-NexG, Evolution XPAND IP+, and XPAND IP devices, as well as edge routers, divided into domains according to the Ethernet VLAN Type of the devices and the equipment type.

The main S-VLAN core ring network of Evo XP-NexG devices connects smaller C-VLAN domains together.

The C-VLAN domains are of different equipment types:

◦ The blue domain consists of Evolution XPAND IP+ devices.

◦ The purple domain consists of XPAND IP devices.

◦ The green domain consists of Evo XP-NexG devices.

Flow Domains Example

Once devices are included in a flow domain, Ethernet services can then be created from any of the flow domain’s edge points (UNI ports) to any other edge point (UNI port) within the same domain. Only the traffic configuration ingressing or egressing at the UNI ports needs to be defined. Nera NMS takes care to configure



all the network ports (NNI ports) within the domain (refer to Managing Ethernet services for further details).

In the network shown above, the UNI ports are marked. The three ports that connect between the different flow domains are also UNI ports. The ports that connect devices within the same flow domain are NNI ports (not marked) and these may be Ethernet ports or Radio ports connecting over various physical media: Category 5 cables, single (1+0) radio links, a pair of radios configured as a radio protection group (1+1), a pair of radios configured as an XPIC group, multiple radios in a LAG group, or multiple radios in a Multi-Carrier ABC group.

Nera NMS provides a number of very versatile views that provide easy management of the flow domains:

The Flow Domain Navigator is a powerful tool for viewing and navigating between the different flow domains.

Ethernet Topology view enables the operator to view all the flow domains in the network and to zoom into and out of one flow domain, showing the connectivity between devices within the flow domain.

The following actions can be performed on a flow domain:

Create a flow domain

Delete a flow domain – All services that exist within the flow domain must first be removed at least from the Nera NMS Database (refer to Deleting an Ethernet service), before the flow domain can be deleted.

Merge two flow domains – flow domains may be merged when Ethernet Connectivity of the same Vlan-Type (S-Vlan / C-Vlan) exists between the domains.

Rename a flow domain

8.1.2 Flow domain best practices

The flow domain should always encompass as large a network as possible.

For a given device to be included in a flow domain, all its peer devices (that are connected to it via radio links or Ethernet links) should also be “managed” by Nera NMS so that they will also be included in the same flow domain.

Ensure that for all devices, there is at least one existing service (for example, the Management Service) with service points, having the correct network VLAN Type, assigned to all the Network Ports (NNIs). Ensure that the network is configured consistently with the same VLAN Type.

It is not recommended to “Delete” from Nera NMS devices that are part of a flow domain as this can have the effect of dividing the flow domain into two separate domains.

“Suspect” links (link went down) should not be deleted from Nera NMS unless the equipment is physically removed.



8.1.3 Managing Ethernet services

Ethernet services can be managed as soon as the flow domains have been configured. Services that are already provisioned on the devices are discovered automatically by Nera NMS.

There are two types of Ethernet Services: E-Line services and E-LAN services.

The following actions can be performed on existing services:

Edit – Change the parameters of a service.

Reapply – Re-provision the service information on the device if the configuration information has been changed or removed.

Rename – Change the name of the service.

Delete – Remove the service.

For all services that are managed by Nera NMS, you can:

View an Ethernet topology map showing all the devices included in the service.

View all alarms associated with the ports along the path of the service.

View the Performance Monitoring data, current performance, and historical performance for the ports along the path of the service (not supported for the Evo XP-NexG family of devices).

8.1.3.1 Discovering Ethernet services

Nera NMS discovers and displays all the services that exist within a flow domain. Discovered services not currently in the Nera NMS database must be “confirmed” before they can be managed. For all “confirmed” services, the Administrative State and Operational State are displayed on three levels:

Service level – For the end-to-end service.

Service fragment (device) level – For each fragment in the service.

Service port level – For each service port in each fragment.

For services which are not in the “enabled” operational state, information is provided indicating the source of the problem.




8.1.3.2 Creating an Ethernet service

A creation wizard is provided to guide you through the configuration of a service. The endpoints of the service must be configured with the type and VLAN ID of the traffic at the ingress and egress UNI ports of the flow domain.

Nera NMS calculates all the possible paths between the end-points and configures the service on all the ports along each of these paths. When the network is built with rings, this provides automatic protection for the service.

Note that if the network is built of rings, the MSTP or G.8032 protocols for the prevention of Ethernet loops must be invoked on each device in the ring using the device’s EMS.

For Evolution XPAND IP+ and Evolution devices, the wizard enables the configuration of tagged or untagged traffic. The chosen VLAN ID is used both at the UNIs and throughout the network as the transport VLAN ID. The services are restricted to E-Line services with two endpoints.

For Evo XP-NexG devices, traffic classification and encapsulation (VLAN IDs) can be configured for each endpoint separately. Both E-line (two endpoints) and E-LAN (more than two endpoints) services can be configured.



UNI Classifications and Encapsulations per VLAN Type

Flow Domain VLAN Type

Classifications Available at the UNIs

Encapsulations

C-VLAN dot1q Tagged or Untagged

S-VLAN

dot1q Tagged or Untagged

AllToOne All dot1q tags

Bundle-C List or ranges of dot1q tags and/or

untagged packets

Bundle-S List or ranges of dot1q tags and/or

untagged packets with a single

additional outer s-tag

8.1.3.3 Deleting an Ethernet service

You can delete a service in any of the following ways:

Delete the service only from the Nera NMS database, leaving the service configured on the devices.

Delete the service both from the Nera NMS database and from the devices, removing the service completely from Nera NMS and from the devices.

8.1.3.4 Renaming an Ethernet service

The rename option can be used to change the name of the service. The name will be updated only in the Nera NMS database.

8.1.3.5 Editing an Ethernet service

Using the Edit Wizard, you can modify the information that was used to define the service.

As a general rule, the service will be deleted from the devices and re-created. In this case, traffic is affected.

If an endpoint is added or additional VLANs are added to a service with Bundle-C encapsulation, traffic is not affected.

8.1.3.6 Reapplying an Ethernet service

This option is only available if differences have been identified between the Nera NMS database and the actual configuration on the device, and these differences can be resolved by configuring the device again with the original configuration.

During Reapply, the information in the database is written down to the device. This operation is expected to affect traffic.



8.1.3.7 Reconciling an Ethernet service

Following a reconcile – whether manual or automatic – any changes made to a service on the devices are identified by Nera NMS. Major changes are displayed by a change in the Operational Status to “Misconfigured”, “Missing”, or “Broken”. New service points or fragments are displayed as “Unconfirmed”.

Nera NMS can be aligned with the changes on the device by deleting the service from the Nera NMS database only. Then, when the service is automatically discovered again by Nera NMS, the service should be “confirmed”. Upon confirmation, the Nera NMS database is updated.

On the other hand, to remove the changes from the device and keep the initial configuration, if the Reapply option has become active, it can be used to restore the original service and re-configure the device. This affects traffic.

8.1.4 Ethernet services – best practices

Services should be managed only via Nera NMS. This includes all creation, deletion, and modification of the services.

If you need to modify any of the advanced service parameters via the EMS, use the Reconcile command on Nera NMS so that Nera NMS can update its database accordingly. Always allow at least one minute for the Reconcile process to be completed and for the Nera NMS database to be updated.

To ensure that the most up-to-date information is displayed, use the Refresh command.

For Evo XP-NexG devices, ensure that the Admin State of the card is set to Up:

◦ On the chassis.

◦ On the Interface Manager.

Where possible, the network ports (ports that connect to other network equipment) should all have the same Vlan classification, either S-Vlan or C-Vlan.

If any configuration is carried out by the EMS, care should be taken to:

◦ Always set an SNP service point on NNI ports and an SAP service point on UNI ports.

◦ For each logical port associated with a specific service, there should never be more than a single service point.

◦ The Transport VLAN ID should be unique per service within the flow domain; that is, no two services should use the same transport VLAN ID.

◦ The Service Type P2P should be avoided.

◦ The following Service Classification should be avoided: Q-in-Q. Instead, a Bundle-S should be used with a single C-Vlan.

8.2 TDM services

Network elements can be configured to work in accordance with either ETSI or ANSI (FCC) standards. Nera NMS can manage TDM Services in either configuration.



8.2.1 TDM Domains

In the TDM services perspective, the devices deployed in the network are divided into domains that are referred to as TDM Domains. The TDM domains are inherited from the Ethernet perspective but may be modified by informing Nera NMS of any STM-1/OC-3 links that may exist between devices (refer to Entering STM-1/OC-3 Link Information).

8.2.2 Managing TDM services

The domains that are configured for Ethernet Services are also used by Nera NMS to provide the information it needs for learning the network topology. Therefore, the flow domains should be configured before managing the TDM services.

Services that are already provisioned on the devices are discovered automatically by Nera NMS.

Nera NMS supports protected and unprotected TDM services for all device types. Nera NMS also supports the use of STM-1/OC-3 protection groups as TDM service endpoints for Evo XP-NexG devices.

The following actions can be carried out on existing services:

Edit – Change the parameters of a service.

Reapply – Re-provision the service information on the device if the configuration information has been changed or removed.

Rename – Change the name of the service.

Delete – Remove the service.

New services may be created by using the creation wizard.

For all services that are managed by Nera NMS, you can:

View the topology map showing all the devices included in the service.

View all alarms associated with the ports along the path of the service.

View the Performance Monitoring data, current performance, and historical performance for the ports along the path of the service (not supported for the Evo XP-NexG family of devices).



Viewing alarms associated with TDM service

8.2.2.1 Discovering TDM services

Nera NMS discovers and displays any existing services. Discovered services not currently in the Nera NMS database must be “confirmed” before they can be managed. For all “confirmed” services, the Administrative State and Operational State are displayed on three levels:

Service level – For the end to end service.

Service fragment (device) level – For each fragment in the service.

Service port level – For each service port in each fragment.

For services which are not in the “enabled” operational state, information is provided indicating where the problem lies.


Flow domains should be created prior to service discovery to ensure that Nera NMS has a complete topological picture of the network.

8.2.2.2 Entering STM-1/OC-3 Link Information

Nera NMS provides a Create STM-1/OC-3 User Link wizard for informing Nera NMS of existing STM-1/OC-3 links between devices. Because these types of links cannot be automatically discovered by Nera NMS, you should use the wizard to inform Nera NMS of such links so that these connections will be taken into account where relevant. For example, in the TDM Topology map and in the Create TDM Service wizard.

The Create STM-1/OC-3 User Link wizard is only relevant for Evolution XPAND IP+ and Evo XP-NexG devices.

The following limitations apply to STM-1/OC-3 User Links between Evolution XPAND IP+ devices:

You cannot create User Links between Evolution XPAND IP+ slots in the same shelf.



The following limitations apply to STM-1/OC-3 User Links between Evo XP-NexG devices:

You cannot create User Link to User Link Cross-Connects.

At an Endpoint node, where a TDM protected service is configured to diverge and one of the links is an STM-1/OC-3 User Link, that User Link must always be configured on the Protecting Path of a TDM 1+1 service; and in addition that User Link may not participate in a TDM 1:1 service (neither on the Working path nor on the Protecting path).

You cannot create TDM protected services over a device through which both the working trail and protecting trail pass, and where one of the paths (Working or Protecting) diverges over an STM-1/OC-3 User Link.

The STM User link cannot be the last link of a trail that connects to a device on which the dual homing edge point of that trail is configured.

8.2.2.3 Creating a TDM service

Nera NMS provides a TDM service creation wizard to guide users through configuration of the service. The user selects the service endpoints. Nera NMS then calculates a possible path between the endpoints. The user can modify the suggested path by adding and deleting service points.

The wizard enables the configuration of protected and unprotected services. ETSI (E1/STM-1) and ANSI (DS1/OC-3) modes are supported.

8.2.2.4 Deleting a TDM service

You can delete a service in any of the following ways:

Delete the service only from the Nera NMS database, leaving the service configured on the devices.

Delete the service both from the Nera NMS database and from the devices, removing the service completely from Nera NMS and from the devices.



8.2.2.5 Renaming a TDM service

The rename option can be used to change the name of the service. The name will be updated only in the Nera NMS database.

8.2.2.6 Editing a TDM service

Using the Edit Wizard, you can modify the information that was used to define the service.

The service will be deleted from the devices and re-created. This will affect traffic.

8.2.2.7 Reapplying a TDM service

This option is only available if differences have been identified between the Nera NMS database and the actual configuration on the device, and these differences can be resolved by configuring the device again with the original configuration.

During Reapply, the information in the database is written down to the device. This operation is expected to affect traffic.

8.2.2.8 Reconciling a TDM service

Following a reconcile – whether manual or automatic – any changes made to a service on the devices are identified by Nera NMS. Major changes are displayed by a change in the Operational Status to “Misconfigured”, “Missing”, or “Broken”. New service points or fragments are displayed as “Unconfirmed”.

Nera NMS can be aligned with the changes on the device by deleting the service from the Nera NMS database only. Then, when the service is automatically discovered again by Nera NMS, the service should be “confirmed.” Upon confirmation, the Nera NMS database is updated.

On the other hand, to remove the changes from the device and keep the initial configuration, if the Reapply option has become active, it can be used to restore the original service and re-configure the device. This affects traffic.

8.2.3 TDM services – best practices

Services should only be managed via Nera NMS. This includes all creation, deletion, and modification of the services.

Should there be a need to modify any of the advanced service parameters via the Web EMS, use the Reconcile command on Nera NMS so that Nera NMS can update its database accordingly. Always allow at least one minute for the Reconcile process to be completed and for the Nera NMS database to be updated.

The flow domains should be configured before handling TDM services, to ensure that Nera NMS has a complete topological picture of the network.

To ensure that the most up-to-date information is displayed, use the Refresh command.



For Evo XP-NexG devices:

Ensure that the Admin State of the card is set to Up:

◦ On the chassis.

◦ On the Interface Manager.

◦ On the TDM Interface for E1/DS1 (relevant for LIC-T16 cards).

Protected TDM services may not have the source point and a Dual Homing Edge point on the same device.

If you must set up services via the EMS:

◦ VC IDs should be kept unique per network domain; that is, no two services should use the same VC ID.

◦ The Trail ID should be unique per network domain.

◦ Avoid using the “Front Panel” timing option on the Evo XP-NexG device.

For Evolution XPAND IP+ devices:

The main slot of an Evolution XPAND IP+ shelf should not be configured in Pipe Mode.

An STM-1 link should not be connected between two slots in the same chassis, as the backplane connects between them.

Avoid mixing Evolution XPAND IP+ slots of the same shelf in Managed (C-Vlan) and Metro (S-Vlan) modes.

Due to an NMS limitation, connect the Evolution XPAND IP+ slots of a single chassis with Ethernet cables to ensure that the largest possible TDM domain is inherited from the Ethernet Perspective.

Avoid TDM services over Evolution XPAND IP+ devices that have Evolution XPAND IP+ PIPE devices at the edge of the domain (device B in the diagram) and which are connected to additional device(s) only via an STM-1 link (device C in the diagram); such services will be shown as two partial services that are “broken”.



9. Performance management

Nera NMS provides functions for collecting, storing and displaying performance data from the network elements.

Typical performance management tasks include:

Historical performance monitoring

Supporting various types of performance data:

◦ Analog measurement values

◦ G.826 measurements

Displaying stored performance data in tabular and chart views

Current performance:

◦ Continuously collecting and storing performance data at 1-min, 15-min, 24-hour, and monthly intervals.

◦ Retrieving and displaying current performance counters, cumulative, 1-min/15-min/24-hour/month registers, and analog measurement values.

Performance counter reset for cumulative register

Network-wide performance information collection

9.1 Historical performance monitoring

The Historical performance monitoring function collects and stores performance data of specified NEs continuously and enables various ways of displaying the stored data.

The performance data to be collected and the corresponding measurement granularity (interval) can be set up efficiently via performance templates. The available performance data depends on the capability of the specific NE type.

Performance monitoring templates



The Historical performance table view displays the stored PM data and analog measurements in a tabular form or as a time series graph.

Historical performance view

The Time series graph displays the measurements in a chart over the selected time period. The chart properties can be customized.

Performance time series graphs



9.2 Current performance

Current performance monitoring implies retrieving and displaying snapshots of the various performance counters, 1-min/15-min/24-hour/month registers and analog measurement values at the NE.

Current performance view

9.3 Performance reports

The reporting functionality, available through the graphical UI, enables a quick overview as well as detailed analysis of the performance of the managed network.

GUI-generated Performance reports

Reports covering performance measurements can be launched from the Views menu > Reports.



9.3.1 Overview PM report

The Overview report displays a summary of performance measurements (G826 parameters) as defined with a filter. The values of each performance parameter type are the sum of all individual measurements of that type in the time interval specified in the filter.

Two graphical charts are displayed based on these selections.

Performance overview report



Summarized Performance Data for PMP Type (x- axis: time, y-axis: measurement value)

In this graph, it is normally easy to detect which types of errors dominate the overall performance, and how these are distributed in time. Based on this, further investigations can focus on a specific window of time.

Summarized Performance Data for Network Elements| (x-axis: Network Elements, y-axis: measurement value)

This graph displays the occurrence of performance errors for each network element, accumulated for the selected time interval. Any network element with a high number of errors is easily spotted, and may then be subject to further investigations.



9.3.2 Detailed PM report

The details report displays a list of all performance measurements matching a defined filter.

Detailed performance report



All collected PM data from all network elements matching the filter is displayed in tabular form, in which the detailed counters can be inspected. The table can be sent to a printer or exported in to a PDF or XLS file for further analysis and visualization.

Before printing, bear in mind that with a high number of active counters and/or selected network elements, this table can become very large.

9.4 Network-wide PM reports

The performance reports mechanism supports the generation of various performance reports for Evolution XPAND IP+ and Evo XP-NexG devices. Reports can be generated either through the GUI (by selecting Performance > Performance Tables from the right-click menu of an NE select in a topology tree or map) or using the pmreport CLI command. The performance reports can be generated whether the Nera NMS server is running on a Windows or Solaris machine, and are available whether the database is Postgres or Oracle.

You can generate any of the following types of performance reports:

Interface Performance Report, for the following interfaces:

◦ Ethernet Radio – relevant for Evolution XPAND IP+ and Evo XP-NexG devices

◦ E1/DS1 – relevant for Evolution XPAND IP+ and Evo XP-NexG devices

◦ STM1/OC3 – relevant for Evolution XPAND IP+ and Evo XP-NexG devices

Radio Performance Report – available for Evolution XPAND IP+ and Evo XP-NexG devices

RMON Report– available for Evolution XPAND IP+ and Evo XP-NexG devices

Trails Performance Report– available for Evolution XPAND IP+ and Evo XP-NexG devices

Enhanced Radio Performance Report – available for Evolution XPAND IP+ devices. This report can only be generated using the CLI.

Enhanced Radio Ethernet Performance Report – available for Evolution XPAND IP+ devices

The reports display PM counters for all the enabled ports of the specified devices. With the exception of the RMON report, Nera NMS can generate a 15-minute interval report, a summarized daily report, a summarized weekly report, or a summarized monthly report. For RMON, no summary reports are available.



Network-wide Performance report



10. Security management

Nera NMS’s security management is role-based. It is handled through group administration and user administration functions.

10.1 Group administration

The Group administration view is used when creating new user groups and assigning permissions to each group. Specific group permission consists of a combination of resource permissions and action permissions.

The Administrators and Security Officers groups are built in to Nera NMS and cannot be deleted. Members of the Administrators groups are granted all Nera NMS permissions. Members of the Security Officers groups are granted only the permissions necessary for performing group and user administrative functions, including granting any and all permissions to selected groups and users.

Group administration view

Resource Permissions displays the domains (sub-networks) for the selected group name. Permissions can be changed by checking or un-checking the checkboxes in the Resource permissions tree. The users in a specific group can only see the domains to which the group has been granted resource permissions; all other domains are hidden.

Action Permissions displays the areas of functionality to which the selected group is granted permission.



10.2 User administration

Individual users are defined in the User administration view and assigned to a single group. From this view, a user can be created, deleted, blocked, or un-blocked, and the user’s password can be changed.

User administration view

All user events are logged to the database and can be displayed in the Audit Log view.

Audit Log view

10.2.1 Remote user authentication

Nera NMS enables authenticating users from a remote server via the RADIUS authentication protocol. Using the RADIUS Server configuration page in Nera NMS preferences, the operator specifies the necessary details and enables or disables RADIUS authentication.



RADIUS configuration page in Preferences

Users authenticated through RADIUS are treated as Nera NMS users for all purposes. Nera NMS supports RADIUS authentication for the following servers:

Free Radius

Radius on Windows Server

◦ 1st choice - Windows Server 2008 (NPS - Network Policy Server)

◦ 2nd choice - Windows Server 2003 (IAS - Internet Authentication Service)

Nera NMS supports RADIUS according to RFC 2865.

10.2.1.1 Working with a RADIUS Server

When Nera NMS works with RADIUS, the usernames and passwords should be configured only on the RADIUS server, and not configured in Nera NMS. However, the groups to which these users are assigned on the RADIUS server should exist with certain privileges in Nera NMS as well.

For example:

On the RADIUS Server: User1 (with password “user1”) is assigned to Group1. The Radius Client policy should allow this group to have access.

In Nera NMS: In the User Management Perspective, only Group1 should be created and privileges should be assigned to it.



When User1 tries to log into Nera NMS, Nera NMS contacts the RADIUS Server and checks whether the group existing in its User Management Perspective exists also on the RADIUS Server.

Because the group exists and the policy allows group members to connect, and because User1 is in the group, User1 is allowed to log into Nera NMS with the privileges that were assigned to Group1. After the first log in, the user User1 will also be automatically added in Nera NMS, and assigned to Group1. (Note however that Nera NMS will continue contacting the RADIUS server and checking whether the user and the group are allowed, every time the user logs in.)

RADIUS and Northbound Interface

Note that when RADIUS authentication is Enabled, the Northbound Interface user will also be authenticated via the RADIUS server, therefore a Northbound Interface user group must be defined in the RADIUS server.

10.3 Nera NMS licensing overview

Nera NMS licensing is feature-based and scalable. Feature-based license scalability allows you to add features and capacity as needed.

New Nera NMS installations include a temporary license, provided with the installation. The temporary license is valid for 30 days. During those 30 days, the user can contact Customer Support to obtain a permanent license. Major version upgrades, and upgrading of license capabilities, also require a new license installation.

License capacity is calculated per radio to be managed, not per network element. For example, a network element with four radios is counted as four licensed elements, not as one.

10.4 License details

The Nera NMS licensing structure was revolutionized to provide simpler and more scalable offers. The new structure is composed of the following:

Standard NMS Package

Pro NMS Package

Upgrade from Standard to Pro NMS Package

Open SNMP Manager

Package Name Description P/N

Standard NMS SW

Package (price per

TRX)

Nera NMS Application Server

TRX Licenses

50 Concurrent Clients

Services End-to-end Provisioning

NM_STD_TRX



Package Name Description P/N

Pro NMS SW Package

(price per TRX)

Nera NMS Application Server

TRX Licenses

50 Concurrent Clients

Services End-to-end Provisioning

SNMP Northbound Interface (Alarms &

Inventory)

Scheduled Reports

Alarm-to-Service Correlation

CLI Script Broadcasting

RADIUS Authentication

NM_PRO_TRX

Upgrade from

Standard to Pro NMS

SW Package

(price per TRX)

SNMP Northbound Interface (Alarms &

Inventory)

Scheduled Reports

Alarm-to-Service Correlation.

CLI Script Broadcasting

RADIUS Authentication

NM_STD_PRO_UPG

Open SNMP Manager

(price per 3rd party

Network Element)

Open SNMP Manager, which enables

management of any 3rd- party element that

supports SNMP

OpenSNMPManager

Please note:

The Nera NMS server High Availability (HA) license is not part of the Standard or Pro packages, and can be added to either of these packages. The HA license part numbers are as follows:

◦ NM_PRO_TRX_HA - Nera NMS High availability for TRX Pro package (price per Trx)

◦ NM_STD_TRX_HA - Nera NMS High availability for TRX Std package (price per Trx)

Both Nera NMS servers participating in a Server High Availability setup require the same license (including High Availability).

The Server High Availability license enables also the option of configuring database High Availability. Keep in mind that in a setup employing both Server High Availability and Database High Availability, all participating servers require the same license (including High Availability).

The following Server + Database High Availability configurations are supported:

◦ Server High Availability and Database (Postgres) High Availability on Solaris and Windows: four servers are required, two for Server HA and two for Database HA. All four machines must have the same OS, which can be either Windows or Solaris.



◦ Server High Availability and Oracle RAC: three servers are required, two for Server HA and one for Oracle RAC. The two Server HA machines must have the same OS, which must be Solaris. The Oracle RAC machine can have either a Solaris or Windows OS.

10.5 Obtaining and installing Nera NMS licenses

To install a Nera NMS license after purchase:

1 Install Nera NMS. Following completion of Nera NMS installation, System Manager is automatically launched and opens the Initial Setup wizard, beginning with License Import.

2 In the Import License window, click Use Temporary License to load the temporary license file provided with the installation.

3 A temporary license, that will expire in 30 days, is loaded. Copy the Activation key, appearing at the bottom of the Wizard’s Import License window.

4 The temporary license file is valid for 30 days. During that time, contact Customer Support to obtain a permanent license, and send them the Activation key of the temporary license. You will then be requested to send your business details.

5 When you receive the permanent license, run System Manager’s Import License wizard to Import the permanent license.

6 Copy down the License no. of the permanent license (displayed in the System Manager’s License Administration tab) and save it in a safe place.

To install a license in the case of a major version upgrade:

1 Access the System Manager’s License Administration tab, and copy down your current License No.

2 Contact Customer Support and send them the current License No. Specify also the Nera NMS version to which you wish to upgrade.

3 When you receive the new permanent license, compatible with the Nera NMS version to which you wish to upgrade, save it on your system.

4 After upgrading Nera NMS to the new version, run the System Manager’s NMS Initial Setup wizard, and Import the new permanent license.



11. Functionality table

This section describes the main functionality provided by Nera NMS. Detailed support within each function area depends on specific NE type and in some cases the HW/SW version of the NE and its installed modules.

Functionality table

Functionality Description

Number of managed network

elements

1-10000 (Depending on license)

Client/Server Supported operating systems: Refer to the Nera NMS System

Requirements document for details

Communication protocol: Java RMI over TCP/IP

Number of clients: 1-30 (Depending on license)

Security management Integrated HTML help

Context sensitive help

Group administration

User accounts administration

Resource permissions

Geographical

Logical

Action permissions

Administration

Configuration

Discover

Fault

Performance

Northbound interface

Preferences

Topology

User levels: configurable resource and action permissions

Audit logging

Advanced log filtering

Performance management Performance collection

Advanced collection filtering

Granularity/Intervals: 1min/15min/24hour/month

Logging




Performance display

Time slider histogram

Advanced view filtering

Tabular view

Time series chart view

Current performance

Reset performance counters

G.826 registers

G.821 registers

Ethernet statistics

Note: From Release R15B02, the Network-wide PM reports

mechanism should be used for Evolution XPAND IP+ and Evo XP-

NexG devices.

ACM statistics

Analog values (RF input level, TX output power, Voltage, Current

load, Temperature)

Fault management Alarm acquisition

Network/NE status

Alarm summary

Active / Current alarms

Acknowledge alarm

Un-acknowledge alarm

Comment alarm

Fault severities: Critical, Major, Minor, Warning, Indeterminate,

Info

Historical alarms view with auto refresh option

Time slider histogram of recorded alarms

Advanced log filtering

Quick filtering

Alarm customization

Alarm severity editing

Alarm name editing

Alarm blocking

Severity color customization

Multiple instances of alarm lists with same scope




Custom naming of window titles

Optional fault management

features

Audible notifications (Configurable criteria and sounds)

Email notifications (Configurable criteria and recipients)

On-screen notifications (Configurable criteria and recipients)

Configuration management Network element and topology auto discovery

Serial connections

IP connections

HW inventory

SW inventory with reconcile

SW download

SW Activation/Reset

NE configuration file management (backup and restore)

NE clock synchronization, SNTP server setting (single NE and bulk

setting)

DST and UTP Settings

Trap receiver setting (Single NE and bulk setting)

Launch external tools

Service management TDM Services

Ethernet Services

Service discovery

Service provisioning

Auto-routing of services

Service alarms

Highest Alarm Severity

Alarm to Service Correlation

Optional features Northbound SNMP agent (Fault and inventory data)

Open SNMP Adapter

Scheduling of report generation to file

Export to file: PDF, MS Office formats

Graphical user interface Geographical tree view

Logical tree view


Hierarchical maps

Filtering and sorting options in most views




Export of tables in views to file: XLS, CSV, XML formats

Platform optional features Nera NMS database High Availability

Nera NMS server High Availability



12. NE support overview

12.1 NE support table

NE Specific

Supported Features

BG-204

BG-304

Evolution Series

Evolution XPAND IP+

Evo XP-NexG

Evo XP-NexG LH

Evo XP-NexG Edge /Edge+ Evo XP-NGeX

Evo SmartLink/ Outdoor+

Evo XP-NGeV Evo SMLK-EHP

Protocols used by Nera NMS

SNMP, v1 x

SNMP, v2c x x x x x x x

SNMP, v3 x x x x x

HTTP x x x x x x x

HTTPS x5 x x x x x

FTP x x x x x

SFTP x x x x x

NE topology x x x x x x

Automatic discovery of links x1 x1 x x x x1

Fault

Active alarms x x x x x x x

Events, (non-clearable alarms) x x x x x x x

Traps x x x x x x x

Polling x x x x x x x



Manual reconciliation x x x x x x x

Alarm to Service Correlation x x x x x

Performance

G.826 (SES, ES, UAS, BBE) x x x x x x

Received Power Level (RPL) x x x x x x

Transmitted Power Level (TPL) x x x x x x

CPE statistics

MSE statistics x x x x

Analog measurements

Reset counters x

Ethernet utilization x3 x

ACM statistics x x x x x x

Performance Management statistics x x x x x

RMON counter x x x x x

Configuration

HW inventory x x x x x x

SW inventory x x x x x x x

Transmission inventory x2 x x x x x

CPE inventory

SW download x x x x x x

SW Activation/Reset x x x x x x



NE configuration file management x x x x x x

NTP/SNTP services x x x x x

Launch external application x x x x x x x

Service management

Ethernet services x1 x1 x x x

TDM services x1 x1 x x x

Service discovery x1 x1 x x x

Service provisioning x1 x1 x x x

Service alarms x1 x1 x x x

Service editing x1 x1 x x x

Service state monitoring x1 x1 x x x

Security, Authentication/Authorization

SNMP: R+RW community names x x x x x x x

HTTP: login, username/password x x x x x x

Footnotes:

1 On Evolution Series XPAND IP (SW >= R4B00), on Evolution XPAND IP+/ Evolution XPAND IP E+ / EvoTM Outdoor (SW >=6.6) and on Evolution XPAND

IP+ (SW >=6.3)

2 RX/TX frequency, ATPC, Space diversity for all Evolution Series radios. Bandwidth, Capacity and TDM capacity supported for Evolution XPAND IP and

Evolution MicroIFU.

3 Evolution XPAND IP only.

4 NE clock should be set to GMT/UTC time in order to avoid ambiguous interpretation of time stamps

5 Supported for Evolution XpandIP+ only



13. Appendix - Supported NE types

This section lists and describes the network element types supported by Nera NMS.

13.1 Evolution XPAND IP+ family

The Evolution XPAND IP+ family is a carrier-grade, wireless Ethernet backhaul product line. The series includes both TDM and Ethernet high capacity devices. All products in the Evolution XPAND IP+ and Evo XP-NexG family are tightly coupled with Nera’s advanced microwave radio and are fully managed by a state-of-the-art management system to provide a full solution for mobile backhaul, private networks, and last mile wireline networks. Evolution XPAND IP+ supports the entire licensed spectrum, from 6GHz to 42GHz, on all approved ETSI and ANSI (FCC) channels. The Evolution XPAND IP+ product line offers wide capacity ranges from 10Mbps to 1Gbps per radio carrier along with enhanced power adaptive ACM (Adaptive Coding & Modulation), Cross Polarization Interference Canceller (XPIC), asymmetrical link support which improves utilization. and header and payload compression mechanisms for maximum spectral efficiency.

13.2 Evo XP-NexG

Evo XP-NexG is a highly modular and flexible cellular backhaul product that is optimized for nodal deployment, with a small footprint, high density, and a high degree of scalability and availability. An Evo XP-NexG system is based on a chassis, which is provided in sizes that fit a single rack unit or two rack units, and which contains five or ten slots for any mix of Ethernet, TDM, and radio cards.

Evo XP-NexG supports RFU-D, RFU D-HP, RFU-E, RFU-S, RFU-C, and 1500HP/RFU-HP.

13.3 Evo XP-NexG LH

Evo XP-NexG LH combines the Evo XP-NexG IDU with one or more RMC-E radio modem cards and Evolution LH transceivers (XCVRs) to provide a versatile and cost-effective microwave radio solution for long distance, high capacity telecommunication networks. The Evolution XCVR is a high transmit power transceiver designed for long haul applications with multiple carrier traffic. Evolution’s patented dynamic biasing technology enables it to deliver high transmit power with low power consumption and lower heat dissipation.

13.4 Evo XP-NexG Edge

Evo XP-NexG Edge is a compact, split-mount hauling solution for edge and rings nodes. Its fixed configuration and low power consumption make it simple to install and maintain. Hosting the common capabilities of the Evo XP-NexG platform, it provides a cost-effective, reliable and flexible hauling solution. Evo XP-NexG Edge provides one or two radio interfaces, six Ethernet interfaces, and optionally a 16 channel E1/T1 interface.



13.5 Evo XP-NexG Edge+

Evo XP-NexG Edge+ is based on the same architecture and technology as Evo XP-NexG and Evo XP-NexG Edge, and supports essentially the same feature set. Evo XP-NexG Edge+ takes the fixed form factor of Evo XP-NexG Edge, sized to fit in a single rack unit, and adds two expansion slots for additional TDM line cards and/or radio modem cards. Evo XP-NexG Edge+ includes a dual-feed power interface which can be connected to separate power supplies for power redundancy.

13.6 EvoTM XP-NGeX

EvoTM XP-NGeX is a split-mount edge node that delivers multi-Gbps radio capacity to the transport network. It provides operators with the simplicity that comes with deploying a very compact, fixed configuration node, helping operators to meet their operational efficiency targets.

EvoTM XP-NGeX contains four 1 GbE combo interfaces, one 2.5/1 GbE combo interface, two combo (RJ-45 or SFP) radio interfaces, and an additional interface that can be configured as a combo (RJ-45 or SFP) radio interface or a 1 GbE interface.1

For TDM traffic, EvoTM XP-NGeX includes a 16 x E1/DS1 interface.

EvoTM XP-NGeX can be used with MultiCore RFU-D, MultiCore high-power RFU-D-HP, E-Band RFU-E, and single core RFU-S.

13.7 Evo SmartLink

Evo SmartLink represents a new generation of radio technology, capable of high bit rates and longer reach, and suitable for more diverse deployment scenarios. Evo SmartLink is a dual-core compact, all-outdoor backhaul Ethernet product that combines radio, baseband, and Carrier Ethernet functionality in a single, durable box for outdoor installations.

Evo SmartLink offers the convenience of an easy installation procedure, and full compatibility with ODU-SP antennas. It is designed for use in network configurations which require high capacity solutions. Evo SmartLink covers the entire licensed frequency spectrum (6-42GHz) and offers a wide capacity range, including Header De-Duplication.

13.8 EvoTM SMLK-EHP

EvoTM SMLK-EHP is a high-power version of Nera’s ground-breaking MultiCore Evo SmartLink, operating in the 4-11 GHz bands and providing TX power of up to 35 dBm. Together, Evo SmartLink and EvoTM SMLK-EHP represent a new generation of

1 In NeraOS 10.0, only one radio interface can be used per EvoTM XP-NGeX unit. When used with a

MultiCore RFU (RFU-D or RFU-D-HP), this interface can support two radio carriers. However, the

second carrier must be part of a Multi-Carrier ABC group in order to be utilized.

Also, in NeraOS 10.0, up to four Ethernet interfaces can be used (GbE 1-4/SFP 1-4).



radio technology, capable of high bit rates and longer reach, and suitable for diverse deployment scenarios.

Evo SmartLink and EvoTM SMLK-EHP are the first true MultiCore systems in the industry which utilize parallel radio signal processing in a compact, all-outdoor device combining radio, baseband, and Carrier Ethernet functionality to offer a future proof solution for PtP connectivity applications.

Evo SmartLink and EvoTM SMLK-EHP support cutting edge capacity-boosting techniques, such as LoS MIMO, QPSK to 2048 QAM, and Header De-Duplication, to offer a high capacity solution for every network topology and every site configuration.

13.9 Evo Outdoor+

Evo Outdoor+ is an all-outdoor solution for backhaul sites. It runs under EvoOS, the high-performance, internetworking operating system, and supports all common features of the Evo XP-NexG platform in a compact, environmentally friendly architecture.

Evo Outdoor+ supports cutting edge capacity-boosting techniques, such as QPSK to 2048 QAM and Header De-Duplication, to offer a high capacity solution for every network topology and every site configuration. Its green, compact, all-outdoor configuration makes Evo Outdoor+ ideal for any location.

13.10 EvoTM XP-NGeV

EvoTM XP-NGeV is a compact and versatile high capacity backhaul Ethernet system which operates in the V-band frequency range. Its light weight and small footprint make it versatile for many different applications. Thanks to its small footprint, low power consumption, and simple installation, EvoTM XP-NGeV can be installed in many different types of remote outdoor locations.

The system operates over 50 – 500 MHz channels to deliver up to 2.5 Gbps of Ethernet throughput in several system configurations.

50 MHz – BPSK to 128 QAM




EvoTM XP-NGeV runs the same NeraOS software as the rest of the Evo XP-NexG platform, enabling it to provide the same Ethernet services model and other advanced radio, Ethernet, and management features as Evo SmartLink, Evo Outdoor+, and Evolution XPAND IP E+.

EvoTM XP-NGeV is available with a single hardware version that covers the entire V-band spectrum.



13.11 Evolution Series

The Evolution Series is a point-to-point microwave radio system in licensed frequency bands from 5 GHz to 38 GHz. Its transmission capacity is scalable between 6 Mb/s and 600 Mb/s based on a common software defined platform.

Evolution Series radios can be configured with a browser like Internet Explorer. You can launch the Evolution Manager and the Evolution Manager in Default Browser tools from Nera NMS External Tools.

Evolution equipment model

Physical ports on evolution equipment are visible as PTPs (Physical Termination Points) in the Nera NMS equipment model.

The following figure is a side by side example of how ports on a 7+1 system is translated in Nera NMS, with the physical model to the left and the equipment model to the right:

PTP names for evolution elements are constructed in Nera NMS from the corresponding location on the physical unit, using a frame.slot.port or frame.slot.antenna direction. channel naming convention. This is illustrated for a radio port in the following diagram:



The naming convention explains the previous 7+1 example as follows:

Ethernet ports: The unit consists of four frames, configured with an su card in slot 1 in frame 1 providing four Ethernet ports. The four Ethernet ports are visible as four Ethernet PTPs in the equipment model. Their labels in the Nera NMS model describe their positions in the physical unit.

For instance eth-1.1.2 indicates that this PTP corresponds to the physical port in frame 1 (see evolution manual for frame numbering), slot 1 (see evolution manual for slot numbering), port 2 (counting from the left on face of the card). In the example the red color on this particular PTP indicates an alarm condition on the particular port.

Radio ports: The unit is configured for transmitting on 8 radio channels in a particular direction, “Antenna Direction 1.“ Of the radio channels, 7 are regular channels, 1 is a protection channel. All this information can be read from the labels of the PTPs.

For instance radio-3.5.Antenna Direction 1.5 indicates that this PTP corresponds to the radio connected to the riu card in frame 3, slot 5. The radio is transmitting in Antenna Direction 1 on channel 5. The identifier “Antenna Direction 1” is a user configurable name read from the element. Channels are numbered 1-7 or postfixed with P for protection. In the example, the yellow color on this particular PTP indicates an alarm condition on the particular channel.

STM ports: The unit is also configured with 7 line-side, electrical 155Mb line cards. There is one card in frame 1 (bottom), and two in each of the other frames. The same rules apply for naming the STM PTPs as for Ethernet ports and radio connections.

For instance stm1-4.3 indicates that this PTP corresponds to the stm1 port provided by the card in frame 4, slot 3.

Native naming

In some cases it may be desirable to see the native name of a resource shown in Nera NMS. For entities that has a direct equivalent in the Nera NMS model (some do not), the native name can be seen in the Properties view under the nativeEMSName property.

The figure below shows an alarm on a resource in Evolution web configurator:



The figure below shows the alarm on an equivalent resource in Nera NMS:

13.12 SDH Mux BG-20/20E and BG-30/30E

The SDH Mux BG-20 is a compact Multi-Service Provisioning Platform with STM-1 and STM-4 capability and a capacity up to 16 VC4.

The extension shelf BG-20E provides additional slots for various traffic modules, increasing the total interfacing capacity of the BG-20.

The SDH Mux BG-30 is a compact Multi-Service Provisioning Platform with STM-1, STM-4 and STM-16 capability and a capacity up to 64 VC4.

The extension shelf BG-30E provides additional slots for various traffic modules, increasing the total interfacing capacity of the BG-30.

The BG-20/BG-30 elements can be configured with the LCT-BGF and the EMS-BGF applications.



13.13 Discontinued Support of Legacy Product Types

From R17A00, Nera NMS no longer supports the following legacy devices:

◦ City-Link

◦ City-Link FE

◦ Compact-Link

◦ FlexLink

◦ InterLink

◦ N2N

◦ NetLink

◦ NL 18x-A1

◦ NL 29x

◦ NL24x

◦ Smartconnect

◦ SmartMetro

◦ SmartNodeA

◦ SmartNodeC

◦ Smartpack

◦ SmartSeries

◦ WiLink I



14. Abbreviations

A

ABC Adaptive Bandwidth Control

ACM Adaptive Coding and Modulation

ADM Add/Drop Multiplexer

ANSI American National Standards Institute

ATPC Automatic Transmit Power Control

B

BBE Background Block Error

C

CLI Command Line Interface

C-VLAN Classified Virtual Local Area Network

D

dBM Decibel per milliwatt

DM Degraded Minutes

DST Daylight Savings Time

E

E-LAN Ethernet Local Area Network

EMS Element Management System

ES Errored Second

ETSI European Telecommunications Standards Institute

F

FCAPS Fault, Configuration, Accounting, Performance, and

Security

FCC Federal Communications Commission

FTP File Transfer Protocol



G

GbE Gigabit Ethernet

Gbps Gigabits per second

GHz Gigahertz

GMT Greenwich Mean Time

GUI Graphical User Interface

H

HA High Availability

HBS Base station units

HSU Subscriber Units

HTTP Hypertext Transfer Protocol

HTTPS Secured Hypertext Transfer Protocol

HW Hardware

I

IDU Indoor Unit

IP Internet Protocol

ISO International Organization for Standardization

ITU International Telecommunication Union

J

J2EE Java Platform, Enterprise Edition

L

LAG Link Aggregation Group

LAN Local Area Network

LH Long Haul

LIC Line Interface Card

LOS Loss of Signal

M

MIB Management Information Base



M

MIMO Multiple-Input and Multiple-Output

MSTP Multiple Spanning Tree Protocol

MTBF Mean Time Between Failures

MTNM Multi-Technology Network Management

N

NE Network Element

NLOS Non-Line Of Sight

NNI Network-to-Network Interface

NMS Network Management System

NTP Network Time Protocol

O

OC Optical Carrier

OCB Outdoor Circulator Box

ODU Out-Door Unit

OEM Original Equipment Manufacturer

OID Object Identifier

OSS Operations Support System

P

P2P Peer to Peer

PM Performance Monitoring

PtMP Point-to-Multi Point

PTP Physical Termination Point

Q

QAM Quadrature Amplitude Modulation

Q-in-Q 802.1Q tunneling

QPSK Quadrature Phase-Shift Keying



R

RFU Radio Frequency Unit

RMI Java Remote Method Invocation

RMON Remote Network Monitoring

RPL Received Power Level

S

SAP Service Access Point

SD Space Diversity

SDH Synchronous Digital Hierarchy

SFP Small Form-factor Pluggable transceiver

SFTP Secure File Transfer Protocol

SNMP Simple Network Management Protocol

SNP Service Network Point

SNTP Simple Network Time Protocol

SONET Synchronous Optical Networking

STM Synchronous Transport Module

S-VLAN Service Virtual Local Area Network

T

TDM Time Division Multiplexing

TFTP Trivial File Transfer Protocol

TM Terminal Multiplexer

TMF TeleManagement Forum

TPL Transmitted Power Level

TRX Transceiver

U

UAS Unavailable Seconds

UAT UnAvailable Time

UDP User Datagram Protocol

UNI User Network Interface

UTC Coordinated Universal Time



V

VLAN Virtual Local Area Network

W

WAN Wide Area Network

Web EMS Web-Based Element Management System

WiMAX Worldwide Interoperability for Microwave Access

X

XCVR Transceiver

XLS Microsoft Excel file format

XPIC Cross Polarization Interference Cancellation

Nera NMS...XPIC or LAG+XPIC Nera NMS Technical Description Nera Proprietary and Confidential Page 9...

Documents

Transcript of Nera NMS...XPIC or LAG+XPIC Nera NMS Technical Description Nera Proprietary and Confidential Page 9...