Upload
others
View
46
Download
10
Embed Size (px)
Citation preview
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 2 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 3 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 4 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 5 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 6 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 7 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 8 of 100
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
Multi-Carrier ABC of Radio
Protection Groups 2+2
w/wo XPIC
Multi-Carrier ABC of Radio
Protection Groups 1+1
with SD
Multi-Carrier ABC of Radio
Protection Groups 2+2
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 9 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 10 of 100
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 Technical Description
Nera Proprietary and Confidential Page 11 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 12 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 13 of 100
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 Technical Description
Nera Proprietary and Confidential Page 14 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 15 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 16 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 17 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 18 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 19 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 20 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 21 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 22 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 23 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 24 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 25 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 26 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 27 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 28 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 29 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 30 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 31 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 32 of 100
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
Network Explorer tree view
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:
Nera NMS Technical Description
Nera Proprietary and Confidential Page 33 of 100
◦ 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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 34 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 35 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 36 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 37 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 38 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 39 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 40 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 41 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 42 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 43 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 44 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 45 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 46 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 47 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 48 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 49 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 50 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 51 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 52 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 53 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 54 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 55 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 56 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 57 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 58 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 59 of 100
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.
For each service, the severity of the most severe alarm currently raised on the service is displayed.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 60 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 61 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 62 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 63 of 100
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).
Nera NMS Technical Description
Nera Proprietary and Confidential Page 64 of 100
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.
For each service, the severity of the most severe alarm currently raised on the service is displayed.
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 65 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 66 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 67 of 100
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”.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 68 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 69 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 70 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 71 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 72 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 73 of 100
9.3.2 Detailed PM report
The details report displays a list of all performance measurements matching a defined filter.
Detailed performance report
Nera NMS Technical Description
Nera Proprietary and Confidential Page 74 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 75 of 100
Network-wide Performance report
Nera NMS Technical Description
Nera Proprietary and Confidential Page 76 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 77 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 78 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 79 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 80 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 81 of 100
◦ 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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 82 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 83 of 100
Functionality Description
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 84 of 100
Functionality Description
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
Network Explorer tree view
Hierarchical maps
Filtering and sorting options in most views
Nera NMS Technical Description
Nera Proprietary and Confidential Page 85 of 100
Functionality Description
Export of tables in views to file: XLS, CSV, XML formats
Platform optional features Nera NMS database High Availability
Nera NMS server High Availability
Nera NMS Technical Description
Nera Proprietary and Confidential Page 86 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 87 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 88 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 89 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 90 of 100
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).
Nera NMS Technical Description
Nera Proprietary and Confidential Page 91 of 100
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
100 MHz – BPSK to 128 QAM
250 MHz – BPSK to 128 QAM
500 MHz – BPSK to 64 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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 92 of 100
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:
Nera NMS Technical Description
Nera Proprietary and Confidential Page 93 of 100
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:
Nera NMS Technical Description
Nera Proprietary and Confidential Page 94 of 100
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.
Nera NMS Technical Description
Nera Proprietary and Confidential Page 95 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 96 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 97 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 98 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 99 of 100
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
Nera NMS Technical Description
Nera Proprietary and Confidential Page 100 of 100
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