NetAct™ Cloud 22 FP2205

(VMware)

Functional Specification for SNMP

Northbound Interface
DN0973977
Issue: 6-2 Final

© 2023 Nokia. Nokia Confidential Information

Use subject to agreed restrictions on disclosure and use.

Functional Specification for SNMP DN0973977 6-2 Disclaimer
Northbound Interface

Nokia is committed to diversity and inclusion. We are continuously reviewing our customer documentation and consulting with standards
bodies to ensure that terminology is inclusive and aligned with the industry. Our future customer documentation will be updated accordingly.

This document includes Nokia proprietary and confidential information, which may not be distributed or disclosed to any third parties without
the prior written consent of Nokia.

This document is intended for use by Nokia’s customers (“You”/”Your”) in connection with a product purchased or licensed from any company
within Nokia Group of Companies. Use this document as agreed. You agree to notify Nokia of any errors you may find in this document;
however, should you elect to use this document for any purpose(s) for which it is not intended, You understand and warrant that any
determinations You may make or actions You may take will be based upon Your independent judgment and analysis of the content of this
document.

Nokia reserves the right to make changes to this document without notice. At all times, the controlling version is the one available on Nokia’s
site.

No part of this document may be modified.

N O WA RRA NT Y O F AN Y KI ND , EI T HER EXPR ES S OR I M P L I E D , I N C L U D I N G B U T N O T L I M I T E D TO A N Y

WARR ANT Y OF AVA IL ABI LI T Y, AC CU RAC Y, R EL I A B I L IT Y, T I T L E , N O N - I N F R I N G E M E N T, M E R C H A N TA B I L I TY
OR F IT NE SS FO R A PA RT ICU LAR PU RPO SE, I S M A D E IN R E L AT I O N TO T H E C O N T E N T O F T H I S D O C U M E N T.
IN NO EVEN T WI L L NOK IA B E LI ABLE F OR AN Y DA M A G E S , I N C L U D I N G B U T N O T L I M I T E D TO S P E C I A L ,
D IRE CT, IN D IRECT, I NCI DE NTAL OR C ON SEQ UE N T IA L OR A N Y L O S S E S , S U C H A S B U T N O T L I M I T E D TO LO SS
OF PRO F IT, REVE NU E, B US IN ESS IN T ER RU PT I ON , B U S I NE S S O P P O RT U N I T Y O R D ATA T H AT M AY A R I S E
FRO M T HE USE O F TH IS DO CU M EN T O R T HE IN F OR M AT IO N I N I T, E V E N I N T H E C A S E O F E R R O R S I N O R
OM IS SI O NS FRO M T HI S DOC UM EN T O R IT S CO NT E N T.

This document is Nokia’ proprietary and confidential information, which may not be distributed or disclosed to any third parties without the
prior written consent of Nokia.

Copyright and trademark: Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be
trademarks of their respective owners.

© 2023 Nokia.

© 2023 Nokia. Nokia Confidential Information

Use subject to agreed restrictions on disclosure and use.

Functional Specification for SNMP DN0973977 6-2 Table of Contents
Northbound Interface

Contents
1 Introduction...................................................................................................................................................... 5
1.1 General Principles..................................................................................................................................... 5

2 General SNMP NBI features........................................................................................................................... 7

2.1 Unified NBI for different domains and network technologies....................................................................7
2.2 Support of multiple NMS...........................................................................................................................7
2.3 NBI communication surveillance............................................................................................................... 8
2.4 Handling of communication problems on lower interface levels...............................................................8
2.5 Provision of NBI synchronization mechanisms.........................................................................................9
2.6 License-controlled NBI functionality.......................................................................................................... 9

3 System management functionality.............................................................................................................. 10

3.1 NMS registration in SNMP Agent........................................................................................................... 10
3.2 Notifications about SNMP Agent start-up and controlled shut-down...................................................... 10
3.3 Notifications about loss of management information..............................................................................11
3.4 Retrieval of NBI versions supported by SNMP Agent............................................................................ 11
3.5 Setting time period for heartbeat notifications........................................................................................ 12
3.6 Setting time period for alarm summary notifications.............................................................................. 12
3.7 Management of event reporting..............................................................................................................12
3.7.1 Filter settings...................................................................................................................................14
3.7.2 Reliable event reporting..................................................................................................................15
3.7.2.1 Retransmission of lost traps...................................................................................................16
3.7.2.2 End of sequence notification..................................................................................................19
3.8 Fault management.................................................................................................................................. 20
3.8.1 Supported alarm parameters.......................................................................................................... 20
3.8.2 Notification of a new alarm occurrence..........................................................................................27
3.8.3 Notification about alarm acknowledgment or unacknowledgment..................................................27
3.8.4 Notification about alarm clearing.................................................................................................... 28
3.8.5 Notification about alarm summary status....................................................................................... 28
3.8.6 Notification about alarm parameter(s) changed............................................................................. 29
3.8.7 NMS requests alarm synchronization.............................................................................................29
3.8.8 NMS triggers alarm acknowledgment/unacknowledgment.............................................................30
3.8.9 NMS triggers alarm clearing...........................................................................................................31
3.8.10 NMS triggers immediate sending of alarm summary notification................................................. 31
3.8.11 Handling of SNMP agent processing errors................................................................................. 32
3.9 Topology data management....................................................................................................................32
3.9.1 Notification about new network resource creation......................................................................... 32
3.9.2 Notification about network resource deletion................................................................................. 33
3.9.3 Synchronization of topology data using MIB variable.................................................................... 34

4 Feature summary...........................................................................................................................................35
4.1 NMS requests..........................................................................................................................................35
4.2 Spontaneous traps.................................................................................................................................. 36

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 3

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Table of Contents
Northbound Interface

4.3 Traps sent after NMS requests...............................................................................................................38

5 Use case examples and related sequence diagrams................................................................................ 41

5.1 NMS requests filtering of notifications.................................................................................................... 41
5.2 NMS sets time period for sending alarm summary notifications............................................................ 42
5.3 NMS requests global alarm synchronization by setting MIB variable getActiveAlarms.......................... 43
5.4 NMS requests retransmission of alarm traps......................................................................................... 45
5.5 NMS triggers alarm acknowledgment.....................................................................................................46

6 NetAct configuration capabilities for SNMP-based NBI............................................................................ 49

7 Restrictions in the current NBI version...................................................................................................... 50

8 MIB structure..................................................................................................................................................51

9 List of abbreviations..................................................................................................................................... 54

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 4

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Introduction
Northbound Interface

1 Introduction
This document describes from a functional point of view (that is, as seen by operators in charge of net-
work management) the SNMP-based northbound FM/CM-oriented interface (in the following called
NBI) between NetAct (as Nokia Element Manager, EMS) and Operations Support Systems (OSS) on
Network Management Layer.

The related MIB definitions are described in dedicated documents.

While the lower management interfaces between network elements (NE) and NetAct are usually man-
ufacturer-dependent (because of various supported NE types and technologies with different manage-
ment interfaces and object models), the main reason for the provision of NBI is to facilitate an easy in-
tegration of Nokia (and related third-party) equipment in a multi-vendor environment and to provide a
unified network management view despite of the details of underlying interface technologies.

To fulfill these requirements the SNMP Agent provides a mediation application function (based on Net-
Act FM and CM platforms) which converts and maps the management information received by or gen-
erated in NetAct into the information required at NBI.

Main targets of the SNMP-based NBI:

• Support fault management related supervision of network elements (and NetAct itself) used in
different domains and network technologies. To support fault management features, information
about the topology of the managed network (so-called CM) is needed as well.
• The interface is based on generic, domain & technology independent alarm (ITU-T X.733) and
topology data definitions. Despite of this generic approach, the operator working on NMS is able
to unambiguously identify the origin of an alarm (physical or logical faulty network resource) in the
managed network.

The supported protocols are SNMPv2c and SNMPv3.

Note: In this document, the term SNMP Agent means the functionality provided by different
products of the NetAct Base family towards higher management systems, while the NMS
provides the SNMP Manager functionality. Both entities use the defined MIB for the provision
of the described northbound interface features.

1.1 General Principles

According to TMN principles, Operations Support Systems on Network Management System (NMS)
layer provide management services and functions related to an area consisting of several regions, and
each of them is usually supervised by one Element Management System (NetAct).

Note:

Currently only one active SNMP Agent instance is supported in NetAct.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 5

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Introduction
Northbound Interface

To give to a superior NMS a real-time supervision capability about the managed network, NetAct has
to provide information about:

• Alarm and topology-related event occurrence in NetAct, NE and about connections between Net-
Act and NE.
• Other events, for example, notification informing about start and controlled shut-down of the SN-
MP Agent.
• Network topology (for example, which network elements and network resources the network is
composed of).

For this purpose, the SNMP Agent forwards spontaneous notifications (traps) in real-time to the regis-
tered NMS to indicate, for example:

• The occurrence, acknowledgment, changing and clearing of alarms within NetAct or NE, so that
related alarm information can be updated.
• Creation or deletion of network resources, so that data about network topology can be updated.

Each connected NMS is able to control the real-time forwarding of traps over NBI by its own filter set-
tings.

Additionally the SNMP Agent provides periodic notifications (for example, heartbeat or alarm summa-
ry information) as well as management information on NMS demand, for example, after receiving re-
quests for synchronization of alarms or topology data.

The NMS management capability is described in the next sections according to the following functional
groups:

• Generic SNMP NBI features

• System management features

In addition, the document describes the main use cases (including their related data flows) and the
layout of current MIB modules.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 6

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 General SNMP NBI features
Northbound Interface

2 General SNMP NBI features

2.1 Unified NBI for different domains and network technologies

Under the consideration of customer requirements for common management operations, one major
target is that the provision of a common NBI can manage different telecom domains and network tech-
nologies in a unified manner.

The provision of harmonized NBI features for different domains and network technologies strongly de-
pends on the capabilities of the managed NEs (for example, different alarm parameters might not be
present in the notifications generated by some NEs), of the underlying NetAct platforms and the con-
figurable facilities offered by the SNMP Agent itself.

Despite of its benefits about common management capabilities, the following generic approaches
must be taken into account:

• Domain-specific expectations about the granularity of the supported object model. Also in the case
of a very rough network resource modeling (for example, supporting only objects representing
NetAct and the managed NEs), significant alarm information generated in NEs is fully available in
the traps forwarded on SNMP-based NBI, that is, NMS operators are able to identify the faulty NE
resource.
• Domain or technology specific management information. The use of domain-specific
probableCause values is defined in well-established standards, for example, ITU-T, 3GPP or
TMF.

2.2 Support of multiple NMS

The following items must be taken into account:

• The increasing complexity of networks to be managed.

• The need to provide a NBI solution open for future extensions.

The SNMP-based NBI is designed for supporting multiple NMS.

Such configurations is redundant NMS configurations or separation of systems management functions

on different NMS when it is related to for example, the support of multiple NMS in huge networks while
one NMS is assigned for the supervision of a dedicated network region.

All registered NMS communicating with NetAct uses the same SNMP NBI version.

To clearly recognize a requesting NMS, an unambiguous NMS identifier is needed in the

varbind list of SET requests. For any alarm related or topology related operations, such as alarm
acknowledgement, alarm unacknowledgement, alarm clear, alarm summary, alarm synchronization,

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 7

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 General SNMP NBI features
Northbound Interface

and topology synchronization, triggered by the requesting NMS, an unambiguous NMS identifier
nbiRequestingNmsName is needed.

For modifying any filter related configurations defined in the nms_conf.xml file, the NMS identifier
nbiRequestingNmsName is not needed in the SET request. The destination data in the NMS
registration table (see NMS registration in SNMP Agent) are used by the SNMP Agent in the
response.

More details about the used syntax are available in the MIB definitions.

Note:

• The parallel processing of several requests (triggered by one or different NMS) is

supported as follows:

1. The second request of another type than the first (still in execution) request can be
processed in parallel to the first one.
2. The second request of the same type as the first (still in execution) request is,
depending on the type, either rejected or queued (that is, the immediate response
sent to the NMS originating the second request means only acceptance) and
processed after the execution of the first one is finished.
• Two SNMP NBI versions may use the same MIB version, but can have different
behaviors towards the external NMS (for example, if some functional restrictions in the
older version are removed).

2.3 NBI communication surveillance

To detect NBI communication problems as early as possible (especially important for a real-time man-
agement interface), a surveillance mechanism based on periodic generation and forwarding of so-
called heartbeat notifications is provided.

The NMS operator is able to retrieve the current time period used for the generation of heartbeat notifi-
cations and also to change this value. For more information, see Setting time period for heartbeat noti-
fications.

In case of multiple NMS configurations, the same heartbeat period is valid for all active northbound in-
terfaces.

A change of the heartbeat period triggered by one NMS is notified to all registered NMS. The new peri-
od value is valid for all NMS beginning in the new settings.

2.4 Handling of communication problems on lower interface levels

Alignment mechanisms supported by NetAct southbound interfaces towards the managed NEs ensure
that NetAct management information is synchronized with the real network condition.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 8

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 General SNMP NBI features
Northbound Interface

These procedures are transparent to the NBI, that is, the SNMP Agent forwards to all registered NMS
only the differences between the old and the new network conditions (as far as such notifications are
not filtered out according to current NBI filter settings).

For example, during the NetAct-NE alignment, NetAct compares the new and the old alarm condition
and handle it as follows:

• For each alarm present in the new alarm condition but not in the old one, NetAct forwards an ac-
tive alarm trap to the registered NMS.
• For the same unchanged alarm (that is, no change of acknowledgment state or other parameters)
present in both the new and old alarm conditions, no event report is sent towards NMS.
• For each alarm present in the old alarm condition but not in the new one, an appropriate cleared
alarm report (and, if necessary, an additional acknowledged alarm) is generated by NetAct and
forwarded to NMS.

Failures at the NetAct-NE interfaces followed by NetAct-NE synchronization do not lead to duplicated
alarm reports towards NMS.

2.5 Provision of NBI synchronization mechanisms

On NMS request, synchronization mechanisms are provided at any time (not only after interruption
and re-establishment of NBI communication) over the SNMP-based NBI. Such mechanism is related
to alarms as well as network topology data, and they provide each NMS with the means for whole or
partial alignment of its management information with the data available in the managed NetAct.

Synchronization-related management information provided by the SNMP Agent is unambiguously cor-

related with previous NMS requests, that is, the response is forwarded only to the requesting NMS.

2.6 License-controlled NBI functionality

A valid license is a prerequisite for using the SNMP-based NBI. The license validity is checked accord-
ing to a configurable time intervals.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 9

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

3 System management functionality

For the sake of readability, the names of the SNMP objects described in this specification do not con-
tain the prefix nbi used in the MIB definitions.

3.1 NMS registration in SNMP Agent

Each NMS which communicates with NetAct via SNMP NBI needs to be registered in the SNMP
Agent.

The registration information for each NMS is pre-configured in NetAct and contains the following infor-
mation:

• NMS identifier (table index, like snmpTargetAddrName in the standard

snmpTargetAddrTable)
• active NBI version (currently for all connected NMS only one NBI version is supported)
• eventTypeFilter
• objectInstanceFilter
• severityFilter

Note:

• If NAT is needed for the communication between NMS and NetAct, the standard
snmpTargetAddrTable contains the IP address and trap port number of the related NAT
system.
• In case one NMS (SNMP Manager) does not support the filter setting via NBI, the values of the
filter settings may be pre-configured according to default values.
• At every restart and also periodically the SNMP Agent evaluates the pre-configured and
persistently stored registration information and populates both the snmpTargetAddrTable and
nmsRegistrationTable accordingly. For example, if a further NMS communicates with NetAct,
the registration configuration is enhanced locally in NetAct. And subsequently, an additional table
row is generated without restarting the SNMP Agent. In the nmsRegistrationTable, one
NMS can only change its filter constructs related to forwarding of notifications, but not any other
parameters (see Filter settings as well).

3.2 Notifications about SNMP Agent start-up and controlled shut-down

These notifications are sent to each registered NMS as follows:

• startUpNotification: the SNMP Agent has been (re-)started and successfully initialized.

The receiving of a startUpNotification is used by each SNMP Manager as follows:

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 10

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

– If the configurable parameter onlyFMsupported is set to true (default value), NMS uses
the notification as a signal to trigger only synchronization of alarms.
– If the configurable parameter onlyFMsupported is set to false, NMS uses the notification
as a signal to trigger both synchronization of alarms and topology data.

• shutDownNotification: The SNMP Agent is shutdown in a controlled manner. This notification

informs the NMS that SNMP Agent encounters a problem and the current management
information may not correspond to the real network condition anymore. The communication will be
resumed after a new startUpNotification is generated.

Both the startUpNotification and shutDownNotification contain the current local NetAct
time (including time zone information) as additional data.

3.3 Notifications about loss of management information

If the rate of incoming notifications exceeds the buffering capacity of the SNMP Agent or loss of infor-
mation occurs, the following notifications are sent to each registered NMS:

• The configurable parameter onlyFMsupported is set to true (default value).

The SNMP Agent sends startUpNotification to be used by each SNMP Manager as a

signal to trigger only synchronization of alarms.

• The configurable parameter onlyFMsupported is set to false.

The SNMP Agent sends syncRequestedNotification to be used by each SNMP Manager

as a signal to trigger a synchronization of alarms or topology data according to the value of the
parameter requestedSyncType.

Also the syncRequestedNotification contains the current local NetAct time (including time zone
information) as additional data.

3.4 Retrieval of NBI versions supported by SNMP Agent

One NBI version is unambiguously identified by one major digit and one minor digit, for example, Ver-
sion is 3.2 (major version is 3, and minor version is 2).

By retrieving the nmsRegistrationTable, each NMS is able to get the NBI version which is
currently activated on its own northbound interface.

In multi-manager configurations, currently the same NBI version (active version) is used by all regis-
tered NMS.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 11

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

3.5 Setting time period for heartbeat notifications

The SNMP Agent availability can be checked by each registered NMS because of the expected
periodic reception of a so-called heartbeatNotification.

Using a Get request about the MIB variable heartbeatPeriod, each NMS is able to retrieve the
time period currently used by SNMP Agent to generate heartbeat notifications. At NetAct start-up time,
a default value (for example, 5 minutes) pre-configured in the SNMP Agent is used.

With a Set request using the MIB variable heartbeatPeriod, one NMS (unambiguously identified
by its requestingNmsName) may change the heartbeat period value. The change is notified to all
NMS by the dedicated changedPeriodNotification. The new time period (possible values: 0 - 60
minutes) is valid for all NMS starting in the new settings.

If the changed value is set to 0, the sending of heartbeat notifications is turned off. If the new value is
invalid, the old period is still used.

3.6 Setting time period for alarm summary notifications

The alarmSummaryNotification, generated by SNMP Agent and forwarded to all registered
NMS, facilitates the periodical check of alarm synchronization status between each NMS and NetAct.

Using a Get request about the MIB variable alarmSummaryPeriod, each NMS is able to retrieve the
current time period used by SNMP Agent to generate summary notifications. At NetAct start-up time, a
default value (for example, 1 hour) pre-configured in the SNMP Agent is used.

With the Set request using the MIB variable alarmSummaryPeriod, one NMS (unambiguously
identified by its requestingNmsName) may change the summary period value. The change is notified
to all NMS using the changedPeriodNotification. The new time period is valid for all NMS
starting in the new settings.

If the new value is set to 0, the sending of alarm summary notifications is turned off. If the new value is
invalid, the old period is still used.

Note: In addition or as alternative to the periodic sending, the SNMP Agent supports the
generation and forwarding of an alarm summary notification on a dedicated NMS request.

3.7 Management of event reporting

For efficient management capability on NMS level, the forwarding of traps over SNMP NBI is con-
trolled by NMS operators, that is, each NMS only receives the notifications needed for fulfilling its man-
agement scope.

The NBI supports the following notification types:

Start Up It is generated:

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 12

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

• either after every SNMP Agent (re-)starts.

• or when SNMP Agent recognizes the need of
alarms synchronization and the value of con-
figurable parameter onlyFMsupported is
set true (default value).

Shut Down It is generated every time when a controlled shut

down of the SNMP Agent is initiated.

Sync Requested It is generated when SNMP Agent recognizes the

need for alarms and/or topology data synchro-
nization and the value of the configurable para-
meter onlyFMsupported is set false.

New alarm It represents a new alarm generated in a man-

aged NE or in NetAct itself.

Note: In this version security-related

alarms (integrityViolation, op-
erationalViolation, physi-
calViolation, securitySer-
viceOrMechanismViolation,
timeDomainViolation) are not yet
supported.

Alarm ack change It is generated when every time an alarm has

been acknowledged or unacknowledged (either
on NetAct or on NMS).

Alarm clear It is generated every time when an alarm is

cleared either automatically in the managed net-
work or manually by operators (either on NetAct
or on NMS).

Alarm changed It is generated every time when one or more pa-

rameters excluding the acknowledgment state of
an alarm has/have changed.

Alarm summary It is generated by the SNMP Agent (periodical-

ly and also on NMS request) and provides each
NMS with the capability to control its alarm syn-
chronization status.

Alarm Sync It is generated as a response to an NMS alarm

synchronization request and each returned alarm
contains the full information.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 13

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

End of sequence It notifies the NMS about the end of a notifica-

tions sequence sent as a response to a previous
NMS request. It contains among others informa-
tion about the overall processing result and the
number of previously sent notifications.

Object creation It indicates the creation of a new managed net-

work resource.

Object deletion It represents the deletion of a managed network

resource.

Topology Sync It is generated as a response to a NMS topology

synchronization request and contains information
about managed network resources (either for all
or base-objects-related topology information).

Heartbeat It is periodically generated by SNMP Agent and

provides NMS with the capability to check the
availability of SNMP Agent and NBI communica-
tion.

Changed trap period It is generated by SNMP Agent and sent to all

NMS if the time period for sending either alarm
summary or heartbeat notifications has been
changed.

Table 1:

3.7.1 Filter settings

Each registered NMS may define filter settings about the information to be forwarded over its own SN-
MP-based NBI. In addition, configurable filter settings locally defined in NetAct are supported.

Filter constructs are set over NBI depending on:

Notification type NMS request may indicate the types of notifications to be filtered out
on NBI (this concerns all notification types forwarded over NBI).

Object instance Notifications generated by the network resources indicated in the

NMS request cannot be forwarded on NBI.

Alarm severity NMS request may indicate the values of the parameter per-
ceivedSeverity for which the related alarms shall not be forward-
ed.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 14

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

Working set Each registered higher level system can set one working set, and the
notifications can be filtered in or out according to the DNs in working
set.

To create, modify and delete working set, see Managing working sets
in Working Set Manager Help.

Operators from higher level system can set, get or modify the
working set settings from the /etc/opt/oss/global/nbisnmp/
conf/mf-conf/nms-conf.xml file.

Using Get requests, one NMS operator is able to retrieve the current filter settings from the
nmsRegistrationTable (one table row is assigned to each registered NMS).

Triggering a Set request, one NMS (unambiguously identified by its requestingNmsName) may
change the filter settings for his NBI using a combination of MIB variables eventTypeFilter,
objectInstanceFilter and severityFilter.

For a user-friendly solution the filter settings are stored persistently, for example, if SNMP Agent
(re)starts, the NMS operators do not need to define again the filter settings for notification forwarding.

Note:

• Each NMS may define the filter according to the information to be received over its SNMP-based
southbound interface. As long as NMS operators do not set a filter or in the case some third-party
NMS do not support filter setting capability over NBI, the SNMP Agent will use pre-defined filter
settings by default (nevertheless also in this case one NMS is able to retrieve the currently used
filter settings).
• The SNMP Agent may reject the NMS request if the filter setting is invalid.
• The filter settings apply for both real-time event forwarding and synchronization triggered by
setting MIB variables. If the event is retransmitted, no filtering is needed, since the buffered events
already passed the current filter checks.

3.7.2 Reliable event reporting

Since the SNMP-based northbound interface uses User Datagram Protocol (UDP) as preferred under-
lying (connectionless) network protocol, neither the delivery of data packets, nor their reception in the
right sequence order can be guaranteed. No error messages are generated, even if communication
problems occurs. It is also possible that one NMS is temporarily not active and the notifications sent by
SNMP Agent during the down-time need to be retransmitted. All these potential scenarios make SN-
MP an unreliable management protocol.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 15

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

To identify a potential loss of notifications on NMS level as early as possible, a mechanism providing
correct synchronization of NMS management information with the real network condition is supported
at SNMP-based NBI.

This mechanism is based on the following concept:

1. Sequential numbering of all forwarded notifications (alarms, alarm summary notifications, topology-
related notifications, heartbeat notifications and so on.)

The SNMP Agent assigns to each notification which passed the NMS-specific filter and is
subsequently forwarded an unambiguous sequence number (MIB variable sequenceId) on NBI.

Because the filter settings may be NMS-specific, the sequence number is maintained in the SNMP
Agent separately for each registered NMS.

If SNMP Agent (re-)starts, each sequence number is initialized (value 1) and is incremented by 1
every time a new spontaneous notification is forwarded to the related NMS. When the maximum
value 2147483647 is reached, the next value to be used is 1 again.
2. Buffering of forwarded notifications for possible retransmission needs

The SNMP Agent stores a configurable amount of the most recently forwarded notifications (which
successfully passed the filter settings) in (logically) NMS-specific event buffers.

The event buffer contains the complete trap information. Once the buffer capacity is full, the old
traps are overwritten by new ones (ring buffer approach).

If DCN outage occurs (that is, no communication between NetAct and NMS), the buffering of notifi-
cations still continues to bridge short-time communication interruptions.

Note:

• The buffered notifications are not stored persistently.

• If one NMS changes its filter settings, the already buffered notifications (stored according to
the previous filter settings) are not impacted.

3.7.2.1 Retransmission of lost traps

The possible loss of traps can be detected by the SNMP Manager in two ways:

1. Gap between the sequenceId values of two consecutively received spontaneous notifications
(that is, notifications went lost because of short time disturbances within the communication
network).

A dedicated retransmission request (all traps) can be triggered by SNMP Manager using a
Set request about MIB variables retransmitTrapIds and requestingNmsName. The
notifications to be retransmitted are identified as a range in format <first sequenceId>-<last
sequenceId>.

No additional filtering processing is necessary, because the buffered notifications already passed
the filter tests.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 16

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

After all missing traps are sent, the endOfSequence notification indicates the number of
previously forwarded traps to the requesting NMS.
2. After the re-establishment of the communication with the SNMP Agent, the SNMP Manager checks
if there is a gap between the sequenceId value of the first received trap after communication re-
establishment and the sequenceId value of last trap received before communication interruption.
Then, SNMP Manager triggers the retransmission of the lost information.

The components of the range to be set in the variable retransmitTrapIds have the format as
follows:

• first sequenceId = sequenceId of last received notification before communication

interruption + 1
• last sequenceId = sequenceId value of the newest received notification - 1.

• If the whole amount of data to be retransmitted is still available in event buffer, the request can
be successfully executed.
• If the lost information is (partly or completely) not available in the event buffer, the request
is rejected by SNMP Agent and SNMP Manager has to trigger subsequently overall
synchronization request (for alarms and/or topology data).

If these retransmission requests are used in multiple NMS configurations, it is ensured that the
retransmitted traps and the final endOfSequence notification are forwarded only to the requesting
NMS.

As example, the following figure emphasizes (among other aspects) the SNMP components involved
in the provision of a reliable alarm reporting on SNMP-based NBI:

In this way the NBI achieves a connectionless with guaranteed delivery communication paradigm.

For more details concerning retransmission processing, see examples in NMS requests retransmis-
sion of alarm traps.

Figure 1: Overview of alarms management shows the overview of alarm management.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 17

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

Figure 1: Overview of alarms management

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 18

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

NEs are integrated to NetAct through the Southbound Mediation, and NMSs are integrated through the
SNMP NBI. All the alarms coming from the NEs are collected through the Southbound Mediation and
saved in the Alarm database in NetAct.

Types of alarm managements:

• SNMP NBI forwards new (spontaneous) alarms from the Alarm database to NMSs after process-
ing and filtering. The alarm is assigned an unambiguous sequenceId for each NMS and is stored
in local Event buffer as well.
• NMS sends a set request to SNMP NBI to trigger alarm synchronization.
• NMS sends a set request with sequenceId to SNMP NBI to trigger alarm retransmission, and the
requested alarms are fetched from the local Event Buffer.

The synchronization request must be achieved to the SNMP Agent first. Then the SNMP Agent trans-
fers it to the databases.

3.7.2.2 End of sequence notification

The endOfSequenceNotification is used at the processing end of such NMS requests, whose
response is sent as the sequence of single traps.

This happens when the following MIB variables are set by a registered NMS (unambiguously identified
by its requestingNmsName):

• getAllAlarms
• getActiveAlarms
• retransmitTrapIds
• acknowledgeAlarms
• unacknowledgeAlarms
• clearAlarms
• getTopologyData

After sending the last response trap, this notification is forwarded to registered NMS and includes the
following object information:

• processingStatus (possible values: success, partialSuccess, failure).

• NmsUser is the optional data only used for NMS alarm handling requests (acknowledgeAlarms,
unacknowledgeAlarms, clearAlarms).
• NmsName has the same value as included in the NMS request and may be used by the SNMP
Manager application to correlate this notification with the previous request.
• NmsRequestType indicates the type of the NMS request which the current end of sequence
notification is related to.
• noOfResponseTraps offers NMS the capability to check whether all previously sent traps about
the NMS request have been received.
• failureReason is set when the object processingStatus has the value partialSuccess
or failure (otherwise it is an empty string).

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 19

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

Note:

• Depending on the NMS request type, both the sequence of returned notifications and the
endOfSequence notification is sent only to requesting NMS or to all registered NMS as follows:

1. For alarm handling requests (acknowledgeAlarms, unacknowledgeAlarms, clearAlarms),

the alarm-related notifications are sent to all NMS (NMS-specific filter settings are taken into
account), but the endOfSequence notification only to the requesting NMS.
2. For getActiveAlarms, getAllAlarms or getTopologyData synchronization and
retransmission requests, the notifications are sent only to the requesting NMS.
• The unambiguous requestingNmsName information is present in each NMS request.
• A possible loss of endOfSequence notification is a special case. If the processing of a NMS
request implies the reception of a sequence of notifications, the NMS has to use a timer about the
reception of the endOfSequence notification. Missing this notification indicates that the request
has not been processed correctly and it is repeated.

3.8 Fault management

This section describes the requests, responses and traps related to the overall fault management
area. For more details, see the examples in Use case examples and related sequence diagrams.

Some of the described NMS requests imply an automatic update of NetAct user interface as well (for
example, updated NetAct alarm list because of NMS-triggered alarm acknowledgment).

3.8.1 Supported alarm parameters

Generally the information conveyed in alarm traps is based on ITU-T X.721 / X.733 and FM platform
specified definitions. Because of the domain-and-network-technology-independent handling of alarms
by the NetAct platform, a harmonized alarm structure on SNMP NBI is ensured. Although all alarms
(generated in the managed NEs and in NetAct itself) use the same format, the support of some alarm
parameters depends on both the capabilities of the managed NEs and of the FM platform in NetAct.

The table at the end of this section indicates which parameters are mandatory (for one or several
alarm notification types; marked with M below) or optional (that is, configurable according to the need
of the operators and included in the optionalInformation parameter) and also the content of
different alarm notification types.

sequenceId (M) The value of this parameter indicates that the se-
quence number of the event is forwarded over
one specific SNMP-based NBI. Gaps in this iden-
tifier may indicate that the loss of events is for-
warded to the current NMS.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 20

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

This parameter is a positive integer number used

and incremented for each trap which passed the
NMS-specific filter check. If the maximum value
is reached, for the next event the sequenceld
value is wrapped back to the initial value 1 (value
zero is not used).

alarmId (M) This parameter identifies a new alarm within the

NetAct scope (that is, it has the same value for all
registered NMS) and is used in all subsequent re-
quests and notifications (for example, acknowl-
edgment, unacknowledgment, changing, clear-
ing) dealing with this alarm. It is the representa-
tion of a positive integer number in string format,
incremented for every new alarm. If the maxi-
mum value is reached, the alarmId, the value is
wrapped back to the initial value 1 (value 0 is not
used) for the next alarm.

alarmType (M) This parameter identifies the following alarm

types defined in ITU-T X.733 / X.721: communi-
cationsAlarm, qualityOfServiceAlarm,
processingErrorAlarm, equipmentA-
larm, environmentalAlarm.

objectInstance (M) This parameter identifies the faulty network re-

source within NetAct or a managed NE as pro-
vided by the NetAct FM platform (this offers NMS
operator a precise information about the original
faulty resource).

Note: The maximum length of the ob-

ject instance representation is 256
characters.

eventTime (M) This parameter indicates the date and time of the
alarm notification generation (which may differ
from the alarmTime defined below) as DateAnd-
Time format (including UTC offset).

alarmTime (M) This parameter indicates the date and time (in-
cluding UTC offset) of alarm generation in the
faulty network resource. The parameter must be
present in new, changed and synchronization
alarm notifications.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 21

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

probableCause (M) The used values are in accordance with domain

or technology-specific standards.

specificProblem (M) This parameter contains a textual description of

the alarm meaning (including internal parame-
ters specificProblem and alarmText), provid-
ing more detailed information about the probable
alarm cause.

perceivedSeverity (M) The used values are in accordance with ITU-TX.

721 / X.733 definitions.

proposedRepairAction (M) This parameter (if supported by the managed

NE) contains operator advices for removing the
fault reason and it is present in new, changed
and synchronization alarm notifications.

additionalText (M) It may contain further information provided in

the original alarm as a concatenation of different
name-value strings and includes information
from the different additionalText attributes
supported in the FM platform.

Note: All sub-strings in the alarm pa-

rameter additionalText are sepa-
rated by a dedicated, in NetAct config-
urable character (the selected charac-
ter should not be contained in the sub-
strings). Currently, the symbol | is used
as separator (default separator).

If any of the additionalText

attributes is missing, then an empty
value is sent for that corresponding
additionalText attribute along with
the | separator.

ackState (M) This information, present only in acknowledged

or unacknowledged and synchronized alarm no-
tifications, indicates whether the alarm has been
already acknowledged or unacknowledged. If an
alarm has been not yet acknowledged:

• In a new alarm notification all acknowledg-

ment-related parameters (ackState, ack-
Time, ackUser) are not present

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 22

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

• In an alarm synchronization notification all

acknowledgment-related parameters (ackS-
tate, ackSystemId, ackTime, ackUser)
have empty values.

ackSystemId (O) This information, present only in acknowledged

or unacknowledged and synchronized alarm no-
tifications, indicates the management system in
which the alarm has been already acknowledged
or unacknowledged. If the higher level system
does not support this parameter, the value is an
empty string.

ackTime (M) This information, present only in acknowledged

or unacknowledged and synchronized alarm no-
tifications, indicates the time (including UTC off-
set) that an alarm has been acknowledged or un-
acknowledged by operators or automatically by a
management system.

ackUser (M) This information, present only in acknowledged

or unacknowledged and synchronized alarm
notifications, indicates the identification of the
user who acknowledged or unacknowledged the
alarm. For auto-acknowledgment, the generic
value generated by the FM platform is valid on
northbound interface as well.

clearSystemId (O) This information, present only in cleared and

synchronization alarm notifications, indicates
the management system on which the alarm
has been cleared. If the higher level system
does not support this parameter, the value is an
empty string. If the alarm is not yet cleared, all
cleared-related parameters (clearSystemId,
clearTime, clearUser) in an alarm synchro-
nization notification have empty values.

clearTime (M) This information, present only in cleared and

synchronization alarm notifications, indicates
the time (including UTC offset) that an alarm
has been cleared (that is, the fault reason is not
longer available) either automatically by system
or manually by operators.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 23

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

clearUser (M) This information, present only in cleared and syn-

chronization alarm notifications, indicates the
identification of the user who manually cleared
the alarm.

optionalInformation (M) This parameter may contain additional alarm-re-

lated information according to the configuration
by the customers. Following optional data sepa-
rated by a dedicated, in NetAct configurable char-
acter, may be added to the alarm content:

• NEName
• siteObjAddress
• siteObjName
• siteObjDN
• controlObjSiteAddress
• controlObjMR
• controlObjName
• probabaleCauseText
• originalSeverity
• maintenanceRegionDN
• maintenanceRegion
• originalAlarmId
• alarmCount
• enrichmentTag
• relatedDNs

Note:

• If any of the above optionalIn-

formation attributes is config-
ured to true as described in Con-
figuring notification enrichment
function in Configuring SNMP
Northbound Interface, then a key-
value pair is added as the value for
the nbiOptionalInformation
field in the related notification.

For example, if the NEName,

maintenanceRegion,
originalSeverity,
probableCauseText, and
maintenanceRegionDN

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 24

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

attributes are configured

to true for the
nbiAlarmNewNotification
enrichment function, then the
nbiOptionalInformation field
contains the following value in the
related notification:

NSN-SNMP-NBI-
FAULTMANAGEMENT-
MIB::nbiOptionalInformati
on="NEname=Flexi NG|
maintenanceRegion=mrname
5|
originalSeverity=indetermi
nate|
probableCauseText=High
Temperature|
maintenanceRegionDN=MRC-
5/MR-5"

In case, if the NEName is not

available, then the NEName
attribute contains an empty value,
with other attributes separated by a
| separator:

NSN-SNMP-NBI-
FAULTMANAGEMENT-
MIB::nbiOptionalInformati
on="NEname=|
maintenanceRegion=mrname
5|
originalSeverity=indetermi
nate|
probableCauseText=High
Temperature|
maintenanceRegionDN=MRC-
5/MR-5"

• By default (without configuration

by the customers), the nbiOp-
tionalInformation field has an
empty string value:

NSN-SNMP-NBI-
FAULTMANAGEMENT-

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 25

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

MIB::nbiOptionalInforma
tion=""

The following table indicates which parameters are present in different alarm notification types. Leg-
end:

y Alarm parameter is always available.

c Alarm parameter is always available, but it may have empty value.

d Alarm parameter availability depends on configuration settings, but it may have empty val-
ue.

n Alarm parameter is not available.

* Alarm parameters or related notifications are not yet supported.

Notification Parameters Alarm notification

New AckChanged Changed Comment Cleared Sync

alarm alarm alarm alarm * alarm alarm

sequenceId y y y y y y

alarmId y y y y y y

alarmType y y y y y y

objectInstance y y y y y y

eventTime y y y y y y

alarmTime y n y n n y

probableCause y y y y y y

specificProblem c d c c d c

perceivedSeverity y y y y y y

proposedRepairAction c* n c* n n c*

additionalText c c c c c c

ackState n y n n n c

ackSystemId n c n n n c

ackTime n y n n n c

ackUser n c n n n c

clearSystemId n n n n c c

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 26

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

clearTime n n n n y c

clearUser n n n n c c

optionalInformation c c c c c c

3.8.2 Notification of a new alarm occurrence

New alarms of any standardized perceivedSeverity value (excluding the value cleared)
received from the managed NE or generated by NetAct itself are converted in SNMP traps according
to the alarmNewNotification syntax and subsequently sent (under consideration of current filter
settings) in real-time to the registered NMS.

The detailed information received from affected resource (and stored in NetAct alarm database) is in-
cluded in the alarm notification forwarded to NMS.

A new alarm notification contains also an unambiguous, NMS-specific sequenceId value, allowing
each NMS to easily detect a possible loss of traps. In such cases, an NMS may trigger the re-
transmission of dedicated alarms (see descriptions in NMS requests retransmission of alarm traps).

3.8.3 Notification about alarm acknowledgment or unacknowledgment

An acknowledgment alarm generated in NetAct (either for acknowledgment triggered by NetAct
operators or automatically by NetAct system itself or after successful processing of an NMS
acknowledgment request) is mapped into an alarmAckChangedNotification and forwarded
(under consideration of current filter settings) in real-time to all registered NMS.

The notification contains all filterable parameters (see Filter settings) and parameters present in the
original alarm and, in addition, the so-called acknowledgment history information: acknowledgment
state, acknowledgment system identifier, acknowledgment time and operator identifier.

On SNMP NBI the correlation between the original (new) alarm and the acknowledgment or
unacknowledgment alarm notification is unambiguously recognized by the same alarmId value.

If an already acknowledged alarm is unacknowledged, the structure of the alarm unacknowledgment

notification forwarded to NMS is the same as the acknowledgment operation (only the object
ackState now has the value unacknowledged).

Note:

• If an alarm has not been acknowledged, it is forwarded to all NMS without acknowledgment
information.
• If an alarm has been acknowledged and then unacknowledged:

1. At the unacknowledgment time it is forwarded like an alarm report with the current
unacknowledgment information.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 27

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

2. If subsequently alarm synchronization is triggered by one NMS, the alarm information contains
only the unacknowledgment information. The NMS operator recognizes, that this alarm has
been acknowledged first and unacknowledged then.

3.8.4 Notification about alarm clearing

A cleared alarm received from the managed NE or generated by NetAct itself (for example, after a
corresponding NMS request) is mapped into a related alarmClearedNotification and forwarded
(under consideration of current filter settings) in real-time to all registered NMS.

This notification contains all parameters that are filterable and present in the original alarm notification,
while the perceivedSeverity value is set as cleared. In addition, the values of the parameters
clearTime, clearSystemId and clearUser indicate the time, the management system identifier
and (about manual clearing) the user identification.

At SNMP NBI the correlation between the original (new) alarm and the cleared alarm is recognized by
the same alarmId value.

Cleared alarms generated in managed NEs without corresponding active alarms in NetAct alarm data-
base are not forwarded to NMS.

3.8.5 Notification about alarm summary status

The SNMP Agent can be configured to generate periodically so-called alarm summary notifications
about the operational conditions of managed elements (including NetAct). Additionally this notification
can be generated on dedicated NMS request (seeNMS triggers immediate sending of alarm summary
notification).

Providing a quick overview about the network condition, the summary information facilitates the verifi-
cation of alarm synchronization status between each NMS and NetAct.

The alarmSummaryNotification contains the NetAct current time, the state of NetAct
synchronization with regard to the managed NEs, and the number of current alarms sorted according
to their severity values (this includes the cleared but not yet acknowledged alarms). Because the
notification takes into account the available NMS-specific filter settings defined for event forwarding,
the contents is NMS-specific.

By default, the time period for sending alarm summary notifications is pre-configured in NetAct. In
addition, NMS operators have the capability to change the time period value using the MIB variable
alarmSummaryPeriod (see Setting time period for alarm summary notifications and use case
descriptionNMS sets time period for sending alarm summary notifications).

If the variable is set to 0, the periodic sending of the summary notification is turned off.

Note:

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 28

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

• The provision of periodic alarm summary information is especially useful for simple third-party
SNMP Managers, which does not support more sophisticated mechanisms (like retransmission of
traps described in Retransmission of lost traps) for discovering lost traps.
• For multiple NMS, the same alarm summary time period value is valid for all active northbound
interfaces. This periodic notification does not replace the sending of heartbeat notifications, and is
usually generated in shorter time intervals.
• When the NMS is configured with working set filter, the number of current alarms in the alarm
summary notification might be affected.

3.8.6 Notification about alarm parameter(s) changed

Changed alarms received from the managed NE or generated by NetAct itself are converted in
SNMP traps according to the alarmChangedNotification syntax and subsequently sent (under
consideration of current filter settings) in real-time to the registered NMS.

The detailed changed information received from affected resource (and stored in NetAct alarm data-
base) is included in the alarm notification forwarded to NMS.

The notification contains all parameters that are filterable (see Filter settings) and present
in the original alarm, and the so-called changed information such as specificProblem,
perceivedSeverity.

On SNMP NBI the correlation between the original (new) alarm and the changed alarm notification is
unambiguously recognized by means of the same alarmId value.

3.8.7 NMS requests alarm synchronization

This functionality provides each registered NMS with the capability to align its alarms information with
the real alarms conditions in NetAct. Generally the feature may be triggered by NMS operators at any
time, but it is strongly recommended at least in the following cases:

• First NMS-NetAct communication.

• NMS receives a startUpNotification or a syncRequestedNotification (with
requestedSyncType parameter set to value alarms).

The NMS-specific filter settings about real-time event reporting apply also for the alarm synchroniza-
tion response, independently of the used option.

It is possible that some of the alarms returned because of a synchronization request have been
already sent to NMS at the time of event occurrence. To avoid alarm duplication, the NMS has to
check whether the alarmId value in the synchronization trap is already available in its alarm list and.
In this case, check whether an update of its alarm information is needed.

The forwarding of new alarms during alarm synchronization is supported.

For triggering alarm synchronization the MIB variables getActiveAlarms or getAllAlarms are
set either to the value all or to a DN identifier of a NE (in the latter case only alarms originated in the
indicated network element are returned).

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 29

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

The SNMP Response PDU indicates either the rejection or the acceptance of the NMS request, but
not the successfully completion of the initiated job.

Once all required alarm traps (according to alarmSyncNotification syntax) have been forwarded
to NMS, an endOfSequence notification (which includes the number of previously forwarded traps) is
sent to the requesting NMS.

If synchronization requests are used in multiple NMS configurations, the alarm notifications and the
final endOfSequence notification are forwarded only to the requesting NMS.

Generally the alarm parameters sent as a consequence of an NMS synchronization request have the
same values as in the alarm notification forwarded in real-time to the NMS. Additional parameters (for
example, when an alarm has been acknowledged in the meantime) are possible as well.

After successful processing of the NMS request, the related MIB variable is automatically reset by SN-
MP Agent to the default value (empty string).

3.8.8 NMS triggers alarm acknowledgment/unacknowledgment

In a management hierarchy containing NetAct and NMS systems, the handling of alarms (that is, im-
plicitly also their acknowledgment or unacknowledgment) can take place on both management levels,
usually at different times.

The SNMP NBI supports the co-operative alarm acknowledgment functionality, and offers a better
alarm handling coordination between operators working on different management systems.

The feature makes distinction only between two so-called acknowledgment state values, that is,
unacknowledged and acknowledged. An acknowledged alarm is still managed on NBI only if it is
still active. Generally NetAct alarm list contains both active (not yet acknowledged, acknowledged or
unacknowledged) and cleared (not yet acknowledged or unacknowledged) alarms.

When alarms are acknowledged on NMS level (that is, manually by NMS operator or automatically
by NMS system) the MIB variable acknowledgeAlarms is set to true (1) and the Set request
contains also the list of alarm identifiers (alarmIdList), the operator identifier (ackUser, see
use case in NMS triggers alarm acknowledgment), the requestingNmsName and (optionally) the
ackSystemId.

Note: In the Alarm List of Monitor application, the value in the column Acknowledgment
User is combined with the ackUser and ackSystemId, which is separated by |, and the
maximum length is 64.

The alarm database in NetAct and also the presentation of acknowledged alarms on NetAct user
interface are subsequently updated. After successful processing the NMS request, the SNMP
Agent generates for each alarm a corresponding ack changed notification (see Notification about
alarm acknowledgment or unacknowledgment) and forwards them (under consideration of current
filter settings) to the registered NMS (including the requesting NMS). Finally an endOfSequence
notification (which includes the number of previously forwarded notifications) is sent to the registered
NMS.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 30

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

If one or several alarms are acknowledged by mistake, one NMS operator could want to un-
acknowledge them, that is, the alarm(s) are set in the state unacknowledged using the MIB variable
unacknowledgeAlarms in a similar way.

If the NMS request contains also identifiers of alarms not available anymore in the NetAct alarm
database, the NMS receives less notifications than the number of alarms indicated in the request. In
such cases the parameter processingStatus in the endOfSequence notification has the value
partialSuccess.

After successful processing of the NMS request, the related MIB variable is automatically reset by
SNMP Agent to false(2).

3.8.9 NMS triggers alarm clearing

If one or several alarms are manually cleared by NMS operators, the MIB variable clearAlarms is
set to true (1) and the Set request contains also the list of alarm identifies (alarmIdList), the
operator identifier (clearUser), the requestingNmsName and (optionally) the clearSystemId.

Note: In the Alarm List of Monitor application, the value in the column Cancel User is
combined with the clearUser and clearSystemId, which is separated by |, and the
maximum length is 64.

After successful processing the NMS request, that is, automatic update of alarm list and of the related
NetAct user interface, the SNMP Agent generates for each cleared alarm a corresponding clear
alarm notification (see Notification about alarm clearing) and forwards them (under consideration of
current filter settings) to all registered NMS (including the requesting NMS). Also an endOfSequence
notification (which includes the number of previously forwarded traps) is sent to the registered NMS.

If a manually cleared alarm was previously already acknowledged, it is automatically removed from the
NetAct alarm list. If an NE alarm is cleared manually by mistake (that is, the alarm is still active in the
network), the alarm will be received again after the next alarm synchronization between NetAct and
the related NE.

It is the responsibility of the NMS operator to clear manually only alarms, which are not active anymore
in the network but which have not been cleared automatically, for example, because of the loss of the
related cleared alarms.

When the NMS request contains also identifiers of alarms not available anymore in the NetAct alarm
database, the NMS receives less notifications than the number of alarms indicated in the request. In
such cases the parameter processingStatus in the endOfSequence notification has the value
partialSuccess.

After successful processing of the NMS request, the related MIB variable is automatically reset by
SNMP Agent to false(2).

3.8.10 NMS triggers immediate sending of alarm summary notification

The NMS-triggered sending of alarm summary notification is useful in the following cases:

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 31

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

• An NMS operator needs urgent check of the alarm situation and does not want to wait until the
periodic summary notification is received.
• The periodic sending of alarm summary notification has been previously turned off.

In such cases the MIB variable getAlarmSummary is set to value true (1).

After successful processing the NMS request (that is, forwarding of alarmSummaryNotification
to the requesting NMS), the MIB variable is automatically reset by SNMP Agent to the default value
false (2).

Note:

• Since the NMS-triggered sending of alarm summary notification is a computation-intensive

operation, the request shall be handled with care.
• The NMS-triggered generation of alarm summary notification does not affect the periodic
forwarding of this notification (as far as this feature has not been previously turned off).

3.8.11 Handling of SNMP agent processing errors

The SNMP Agent is able to detect own processing errors, which are displayed in NetAct’s alarm
monitor and also notified to the registered NMS using the alarmNewNotification structure (see
Notification of a new alarm occurrence). These special alarms have the following properties:

• The current filter settings towards external NMS apply for these alarm notifications as well.
• The sequenceId values are temporarily stored in event buffer and can be retransmitted when
they have been lost (according to Reliable event reportingabove).
• The short description related to the problem of the current Agent is conveyed in the parameter
additionalText of the alarm notification and a more detailed description is present in the
Troubleshooting documentation

3.9 Topology data management

This NBI functionality generally provides a configuration management (CM) capability for NMS opera-
tors, that is:

• NMS is able to retrieve topology-related information about the managed network resources
• Configuration changes are sent under consideration of NMS-specific filter settings as real-time
event reports (object creation, object deletion) to all registered NMS.

3.9.1 Notification about new network resource creation

If a new network resource is taken into service (that is, a new corresponding object is managed by
NetAct CM platform), the registered NMS are informed by the specific createNotification, which
supports the following instance parameters:

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 32

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

sequenceId (M) The syntax and semantics of this parameter

is the same as used in alarms (see Supported
alarm parameters).

objectInstance (M) This parameter identifies the new created net-

work resource within NetAct or a managed NE.

eventTime (M) This parameter indicates the date and time of the
create notification generation as DateAndTime
format (including UTC offset).

optionalInformation (M) This parameter may contain additional topolo-

gy-related information according to the configura-
tion by the customers. The following optional data
separated by a dedicated, in NetAct configurable
character, may be added:

• NeName
• siteObjAddress
• siteObjName
• siteObjectDN
• maintenanceRegion
• vendor
• version
• alarmCount
• enrichment tag

As default (without configuration by the cus-

tomers) this parameter has an empty string val-
ue.

3.9.2 Notification about network resource deletion

If a resource (an object at SNMP-based NBI) is removed from the network, the registered NMS is
informed by the specific deleteNotification containing the following parameters:

sequenceId (M) The syntax and semantics of this parameter

is the same as used in alarms (see Supported
alarm parameters).

objectInstance (M) This parameter identifies the deleted network re-

source within NetAct or a managed NE.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 33

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 System management functionality
Northbound Interface

eventTime (M) This parameter indicates the date and time of the
delete notification generation as DateAndTime
format (including UTC offset).

On reception of this deletion notification, NMS deletes the related instance and also all related alarms
from its database.

3.9.3 Synchronization of topology data using MIB variable

One NMS obtains at any time information about the managed network resources. To retrieve this
information, the MIB variable getTopologyData is set as follows:

• To the value all: the network topology information about all alarming objects is returned
(mandatory)
• To the DN of a baseObject value: the topology information of the baseObject itself and all
contained managed resources is returned (optional).

Note: The maximum length of the DN is 256 characters.

Generally the feature can be triggered by NMS operators at any time, but it is strongly recommended
at least in the following cases:

• First NMS-NetAct communication.

• NMS receives a start-up notification.
• NMS receives a syncRequestedNotification and requestedSyncType is set to the value
topology.
• Re-establishment of the NMS-NetAct communication after long-time interruption, that is, the
buffered topology data in SNMP Agent do not provide sufficient information for synchronization.

The forwarding of new topology data during topology synchronization is supported.

The response is a sequence of topologySync notifications, which contain the same parameters as
the object creation notification.

Once all the notifications have been forwarded, the SNMP Agent sends to the requesting NMS an
endOfSequence notification, which includes the number of previously forwarded traps.

If a synchronization request is used in multiple NMS configurations, it is ensured that the topology-
related traps and the final endOfSequence notification are forwarded only to the requesting NMS.

After successful processing of the NMS request, the MIB variable is automatically reset by SNMP
Agent to the default value (empty string).

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 34

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Feature summary
Northbound Interface

4 Feature summary
The following tables contain a summary of SNMP NBI features from a functional point of view:

4.1 NMS requests

In the following table, two possible options have been listed for some features to support simple or
more advanced implementations on NMS side (SNMP Manager).

Meaning Request type Remarks

Retrieve supported Get requests Use nmsRegistrationTable

SNMP NBI version

Set filter for notifica- Set MIB variables: Filter settings are NMS-specific and for this
tions eventTypeFilter, purpose the nmsRegistrationTable is used,
while each row in the table contains the current
objectInstanceFilter,
severityFilter settings about the eventTypeFilter, the
and additionally objectInstanceFilter and (only for alarms)
the NMS identifier the severityFilter.
(requestingNmsName)
The filter settings apply for spontaneous notifica-
tions, because of notifications sent as response to
previous NMS requests and in synchronization re-
sponses.

Retransmit traps Set MIB variable re- Requested traps still available in event buffer are
from event buffer transmitTrapIds and forwarded as a sequence of single traps to the re-
additionally the NMS questing NMS. No additional filter check needed,
unambiguous identifier because all traps in event buffer already passed
(requestingNmsName) this check.

Alarm synchroniza- Set MIB variable getActiveAlarms: Only active alarms (that
tion using FM plat- getActiveAlarms or is, alarms whose perceived severity value is not
form data getAllAlarms and clear) generated by all resources or by specified
additionally the NMS managed elements (including NetAct) are returned
unambiguous identifier as a sequence of single traps.
(requestingNmsName)
getAllAlarms: alarms generated by all
resources or by specified managed elements are
returned as a sequence of single traps.

NMS triggers alarm Set MIB variable ac- The variable list in the Set request contains in ad-
acknowledgment/un- knowledgeAlarms dition the list of alarmId values for the alarms to
acknowledgment or unacknowl- be acknowledged or unacknowledged (using the

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 35

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Feature summary
Northbound Interface

edgeAlarms to val- alarmIdList object) and the NMS user identifica-

ue true(1), the user tion (ackUser).
identifications and also
the NMS unambiguous
identifier (request-
ingNmsName)

NMS triggers alarm Set MIB variable The variable list in the Set request contains in addi-
clearing clearAlarms to val- tion the list of alarmId values for the alarms to be
ue true(1), the user cleared (using the alarmIdList object) and the
identifications and also NMS user identification (clearUser).
the NMS unambiguous
identifier (request-
ingNmsName)

NMS triggers im- Set MIB variable getA- The variable value is set to value true (1). After
mediate sending of larmSummary and ad- the processing of the request is finished, the vari-
alarm summary noti- ditionally the NMS un- able is set by SNMP Agent to value false (2).
fication ambiguous identifier
(requestingNmsName)

NE topology data Set MIB variable get- Topology data of managed resources (either about
synchronization us- TopologyData and all alarming objects or only a subtree defined by
ing CM platform additionally the NMS means of a baseObject) are returned as a se-
unambiguous identifier quence of single traps.
(requestingNmsName)

Set period for send- Set MIB variable The heartbeat period is valid for all registered
ing heartbeat notifi- heartbeatPeriod and NMS.
cations additionally the NMS
unambiguous identifier
(requestingNmsName)

Set period for send- Set MIB variable alar- The summary period is valid for all registered NMS.
ing summary notifica- mSummaryPeriod and
tions additionally the NMS
unambiguous identifier
(requestingNmsName)

4.2 Spontaneous traps

Meaning Notification type Remarks

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 36

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Feature summary
Northbound Interface

New alarm alarmNewNotification Parameters ackState, ackSystemId,

ackUser, ackTime, clearSystemId,
clearUser, clearTime are not present.

Acknowledged alarmAckChangedNotification All mandatory parameters (filtering relevant)

alarm from the original alarm are present.

Same alarmId value as in the previous

new alarm.

Parameters ackState, ackSystemId,

ackUser, ackTime have well-defined
values (or empty) values.

Parameters clearSystemId,
clearUser, clearTime are not present.

Clear alarm alarmClearedNotification All mandatory parameters (filtering relevant)

from the original alarm are present.

Same alarmId value as in the previous

new alarm.

Parameters clearSystemId,
clearUser, clearTime have well-
defined (or empty) values.

Parameters ackSystemId, ackState,

ackUser, ackTime are not present.

Changed alarm alarmChangedNotification All mandatory parameters (filtering relevant)

from the original alarm are present.

Same alarmId value as in the previous

new alarm.

Parameters ackState, ackSystemId,

ackUser, ackTime, clearSystemId,
clearUser, clearTime are not present.

Object creation createNotification Some attribute values may be empty, if not

supported by the managed NEs.

Object deletion deleteNotification Mandatory parameters (also filtering rele-

vant) are present.

Heartbeat heartbeatNotification Common for all NMS.

Same heartbeat period for all NMS.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 37

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Feature summary
Northbound Interface

Alarm summary info alarmSummaryNotification Some information in the notification is NMS-

specific.

Same notification period for all NMS.

Start-Up startUpNotification Common for all NMS.

Contains the eventTime.

Shut-Down shutDownNotification Common for all NMS..

Contains the eventTime.

Sync Requested syncRequestedNotification Common for all NMS.

Contains the eventTime and a parameter

indicating the needed synchronization type
(alarms or topology data).

4.3 Traps sent after NMS requests

Trap type Notification type Remarks

Traps for retransmis- alarmNewNotification Used MIB variable

sion of lost alarms using retransmitTrapIds.
alarmAckChangedNotification
event buffer
Alarms are retransmitted with the
alarmClearedNotification
same sequenceId values as they
alarmChangedNotification have been stored in the event buffer at
their occurrence time. In such cases,
the NMS requests more alarms to be
retransmitted than only the lost ones,
NMS has to check each sequenceId
value to avoid alarm duplication in its
database.

Traps for retransmission changedPeriodNotification Used MIB variable retransmitTrapIds.

of other lost notifications
alarmSummaryNotification These notifications are retransmitted
using event buffer
with the same sequenceId values
endOfSequenceNotification
as they have been stored in the event
heartbeatNotification buffer at their occurrence time.
startUpNotification

shutDownNotification

syncRequestedNotification

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 38

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Feature summary
Northbound Interface

Traps after processing alarmAckChangedNotificationAlarms are forwarded to all connect-

NMS requests about ac- ed NMS with the same structure as in
alarmClearedNotification
knowledgment, unac- case of spontaneous traps.
knowledgment, clearing
of alarms

Traps after processing alarmAckChangedNotificationAlarms are forwarded to all connect-

NMS requests about ac- ed NMS with the same structure as in
alarmClearedNotification
knowledgment, unac- spontaneous traps.
knowledgment, clearing
of alarms

Trap for alarm synchro- alarmSyncNotification Used MIB variable

nization using FM plat- getActiveAlarms or
form data (for exam- getAllAlarms.
ple, after first re-start or
Similar as above, that is, full alarm
when lost traps are not
structure is used, also if some parame-
present in event buffer
ters may have empty values.
anymore)
There are two different cases:

1. Some of the returned alarm traps

may be new (new alarmId value,
not yet present in NMS alarm data-
base), thus NMS inserts them into
alarm database.
2. Some of the alarms related to an
alarm are already sent before com-
munication interruption or NMS re-
quest (alarmId value already avail-
able in NMS alarm list).

• If the returned alarm has an

identical contents as the alarm
present in NMS database, it
shall be ignored.
• If in the returned alarm some
parameters (for example, ack-
State) are changed in com-
parison with the alarm informa-
tion in NMS alarm database,
NMS has to update its data-
base contents.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 39

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Feature summary
Northbound Interface

Trap for alarm summary alarmSummaryNotification Used MIB variable: getAlarmSumma-

notifications ry.

Some information in the notification is

NMS-specific.

Traps for retransmis- createNotification Used MIB variable retransmitTrapIds.

sion of lost topology da- Notifications are retransmitted with the
deleteNotification
ta from event buffer same sequenceId values as they
have been stored in the event buffer at
their occurrence time. In such cases,
the NMS requests more topology data
to be retransmitted than (only) the lost
ones, NMS has to check each se-
quenceId value to avoid topology du-
plication in its database.

Traps for topology da- topologySyncDataNotifica- See above MIB variable

ta synchronization using tion getTopologyData related
CM platform comments.

(for example, after re- Some attribute values may be empty, if

start or when lost traps not supported by the managed NEs.
are not present in event
buffer anymore)

End of sequence endOfSequenceNotification Because of NMS request process-

ing, the number of sent traps is always
present in this end trap.

Changed trap period changedPeriodNotification Setting MIB variables: alarmSumma-

ryPeriod or heartbeatPeriod.
The new time period is notified to all
registered NMS.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 40

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Use case examples and related
Northbound Interface sequence diagrams

5 Use case examples and related sequence diagrams

In the following diagrams (emphasizing the logical view of the interactions between NMS and NetAct)
the exchanged messages directly involved in the described use cases are shown in light grey back-
ground.

Note:

• In each exchanged message only the relevant parameters for the described use case
are listed. Behind every shown trap the specific trap type is indicated.
• For readability, the prefix nbi used in the MIB definitions are intentionally omitted in the
diagrams.

5.1 NMS requests filtering of notifications

In this example, NMS1 changes own filter settings so that all related alarm types with
perceivedSeverity = warning or minor originated in the network element RNC-2 are not sent to
NMS1 anymore.

1. NMS sends set request to SNMP NBI to set objectInstanceFilter to NSNNetwork-1/RNC-2 and
severityFilter to 48.
2. SNMP NBI sends response to NMS, and from now on, SNMP NBI will filter out all alarms from
RNC-2 whose severity is warning or minor for this NMS.

The current filter applies for all related NBI mechanisms: real-time event forwarding, event retransmis-
sion (implicitly, since all notifications in event buffer already passed the filter check) and synchroniza-
tion requests.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 41

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Use case examples and related
Northbound Interface sequence diagrams

5.2 NMS sets time period for sending alarm summary notifications
In this example, NMS1 changes the time intervals for sending the alarm summary notifications from 10
hour to 15 hours.

1. NMS sends get request to SNMP NBI to retrieve the alarm summary period.
2. SNMP NBI sends response to NMS with the alarm summary period value 10.
3. NMS sends set request to SNMP NBI to set alarm summary period value to 15.
4. SNMP NBI sends changedPeriodNotifications to all registered NMS to inform that the new
alarm summary period is changed to 15.

The new period of multiple NMS is notified to all registered NMS.

A similar approach is used in case one: NMS operator changes the time period for sending heartbeat
notifications.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 42

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Use case examples and related
Northbound Interface sequence diagrams

5.3 NMS requests global alarm synchronization by setting MIB variable

getActiveAlarms
The alarm synchronization mechanism uses the information available in NetAct alarm database.

• It is possible that some of the previously forwarded (spontaneous) alarms have been
acknowledged and cleared in the meantime (that is, they are not managed in the NetAct’s alarm
database), thus gaps between the alarmId values of consecutive alarms may occur.
• During the alarm synchronization the forwarding of new occurred alarms towards the requesting
NMS is supported. The NMS application is able to distinguish between alarms sent as response to
the previous request and spontaneous alarm traps because of the different trap OIDs.
• At the end of synchronization, a dedicated endOfSequence trap indicates the number of sent
alarms related to the synchronization request. This is a means for the requesting NMS to check
the correct reception of all forwarded traps.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 43

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Use case examples and related
Northbound Interface sequence diagrams

1. NMS sends Set request with variable getActiveAlarms = all to SNMP NBI to trigger syn-
chronization for all active alarms.
2. SNMP NBI sends response to NMS.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 44

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Use case examples and related
Northbound Interface sequence diagrams

3. SNMP NBI sends alarmSyncNotifications to NMS as alarm synchronization response.

4. SNMP NBI sends alarmNewNotification to NMS when new alarm arrives.
5. SNMP NBI sends endOfSequenceNotification with the amount of response notifications to
NMS to indicate the alarm synchronization is finished.

5.4 NMS requests retransmission of alarm traps

This synchronization mechanism is especially useful in case one NMS autonomously recognizes the
loss of traps (alarms or topology-data notifications) or short-time communication interruptions. It uses
in the most situations the event information stored in the event buffer (as far as available) and returns
the missing data to the requesting NMS as sequence of single traps.

Recognition of missing traps and lost information are still available in event buffer.

In this example (for example, short time NMS-NetAct communication interruption or network
problems), an NMS interested only in alarm traps recognizes a gap between the sequenceId values
of two consecutive received alarms and the needed information is still available in event buffer.

The NMS uses a Set request to indicate the sequenceId values of the alarms to be retransmitted.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 45

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Use case examples and related
Northbound Interface sequence diagrams

1. SNMP NBI sends traps (alarmNewNotification) to NMS.

2. NMS receives some traps correctly and some get lost.
3. NMS sends set request with sequenceId as variable to request SNMP NBI to retransmit the lost
traps.
4. SNMP NBI sends the requested traps to NMS.
5. SNMP NBI sends endOfSequenceNotification to NMS to indicate the retransmission is fin-
ished.

5.5 NMS triggers alarm acknowledgment

In this example one NMS (identified as NMS1) triggers the acknowledgment of three alarms with the
unambiguous alarmId values 1234, 1238, 1244.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 46

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Use case examples and related
Northbound Interface sequence diagrams

The related alarms are set as acknowledged in NetAct alarm database. Subsequently corresponding
acknowledgment traps are generated and forwarded to both NMS1 and NMS2 (under consideration of
current NMS-specific filter settings).

The sequence diagram below emphasizes that for each alarm the acknowledgment traps are sent to
all registered NMS with the same alarmId value but NMS-specific sequenceId values.

1. NMS1 sends Set request to SNMP NBI to trigger alarm acknowledgment.

2. SNMP NBI sends response to NMS1.
3. SNMP NBI sends alarmAckChangedNotification to all the registered NMS.
4. SNMP NBI sends endOfSequenceNotification to all registered NMS, the field noOfRespon-
seTraps indicates the amount of acknowledgment alarms.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 47

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Use case examples and related
Northbound Interface sequence diagrams

Note: For example, the new alarm occurrence with alarmId = 1238 was filtered
out, also the related alarm acknowledgment trap is not forwarded on NBI, that is, the
endOfSequence notification for NMS2 would indicate that only two traps have been sent.

A similar processing is done in NMS-triggered alarm clearing.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 48

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 NetAct configuration capabilities for
Northbound Interface SNMP-based NBI

6 NetAct configuration capabilities for SNMP-based

NBI
This section summarizes NetAct operator capabilities about the configuration of the SNMP-based NBI.

Note:

• The list below may be extended during the implementation phase of the current version
and also for future NBI versions. In any cases, the extensions should be done in a
backwards compatible way.
• All configurable parameters are valid SNMP-Agent wide, as far as NMS-specific settings
are not explicitly mentioned.

Currently configuration capabilities are as follows:

• Community string and associated access rights. Further security-related parameters need to be
configurable in case of SNMPv3 support.
• SNMP version (SNMPv2c or SNMPv3) used at northbound interface.
• IP addresses and trap destination port numbers used by SNMP Agent for bi-directional
communication with all registered NMS.
• Symbolic names of used NMS (needed for registration).
• Default time period the SNMP Agent checks the NMS registration information (pre-configured in
NetAct).
• Default NMS-specific filter settings about notification forwarding (needed when NMS operators do
not set filter or when some third-party SNMP Managers do not support filter settings capability at
NBI).
• NMS-specific filter settings locally defined in NetAct.
• Default time period for sending heartbeat notifications.
• Default time period for generation of periodic alarm summary notifications.
• Enabling or disabling forwarding different traps by setting filters.
• Customer configurable content of the parameter optionalInformation in alarm and topology
notifications.
• Separator character between the sub-string conveyed in the parameters additionalText or
optionalInformation.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 49

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 Restrictions in the current NBI version
Northbound Interface

7 Restrictions in the current NBI version

This section describes the restrictions available in this SNMP-based NBI version and will be updated
during the implementation phase.

Current restrictions are as follows:

• Support of SNMPv1 is not foreseen.

• All NMS use the same SNMP NBI version with multiple NMS configuration.
• Retransmission of dedicated notification types (MIB variable retransmitTrapType) is not yet
supported.
• Alarm synchronization is supported only by setting MIB variable getActiveAlarms or
getAllAlarms.
• Alarm synchronization is supported either for the whole network or only for a single NE.
• No support of security-related alarms.
• No support of alarm parameter proposedRepairAction (not yet supported in NetAct FM
platform).
• Topology information such as object name change related notifications are not supported. NMS
must trigger topology synchronization to re-synchronize such information.
• Topology related functions only support alarming objects.
• When the NMS is configured with working set filter, the number of current alarms in the alarm
summary notification might be affected.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 50

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 MIB structure
Northbound Interface

8 MIB structure
The mediation application function provided by the SNMP Agent converts the system dependent view
of the lower level NetAct-NE interfaces into the system-independent view at NBI.

The object model exposed by SNMP-based northbound interface is formally described in the SNMP
NBI Management Information Base (MIB). The Nokia-specific MIB for the SNMP NBI is defined ac-
cording to the following naming tree:

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 51

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 MIB structure
Northbound Interface

Figure 2: Naming tree for the SNMP NBI MIB

The overall NBI MIB consists of the following modules:

• Registration MIB, which contains the unambiguous top-level OID (nbiNetActSnmp) for all SNMP
NBI definitions.
• Textual conventions MIB, which contains standard conformant textual conventions for the objects
used in the following modules.

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 52

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 MIB structure
Northbound Interface

• Common functions MIB, which contains object definitions for NBI functions not related to a dedi-
cated management area (fragment).
• Fault management MIB, which contains object definitions for NBI functions about the management
of alarms.
• Topology management MIB, which contains object definitions for NBI functions about the manage-
ment of topology data.

This modular approach allows for a seamless extension of the MIB in case further NBI management
areas will be provided in future versions.

The MIB definitions take into account (among others) the RFC 4181 Guidelines for Authors and Re-
viewers of MIB Documents about the OID layout:

• The value of the module-identity invocation is used as a sub-tree under which other object
identifier values assigned within the module are defined.
• Immediately below the module-identity value there are three separate branches dedicated
(respectively) to notification definitions, object definitions and conformance definitions.
Furthermore the conformance branch is subdivided into separate sub-branches for compliance
statements and object or notification groups. This structure is illustrated in the picture below,
where the numbers in parentheses are the sub-identifiers assigned to the branches.

Figure 3: OID layout of the SNMP NBI MIB

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 53

(VMware) Use subject to agreed restrictions on disclosure and use.
Final
Functional Specification for SNMP DN0973977 6-2 List of abbreviations
Northbound Interface

9 List of abbreviations

3GPP Third Generation Partnership Project

CM Configuration Management

EMS Element Management System

FM Fault Management

IP Internet Protocol

ITU-T International Telecommunications Union - Telecommunication standardiza-

tion sector

MIB Management Information Base

MOC Managed Object Class

MOI Managed Object Instance

NAT Network Address Translation

NBI North Bound Interface

NE Network Element

NM Network Management

NMS Network Management System

OES Open EMS Suite

OFaS Open Fault Standard

OID Object Identifier

PDU Protocol Data Unit

SNMP Simple Network Management Protocol

TCP Transmission Control Protocol

TMF Tele Management Forum

TMN Telecommunication Management Network

UDP User Datagram Protocol

USM User-based Security Model

VACM View-based Access Control Model

NetAct™ Cloud 22 FP2205 © 2023 Nokia. Nokia Confidential Information 54

(VMware) Use subject to agreed restrictions on disclosure and use.
Final