See also Documentation and Use of the Ericsson
SNMP Alarm MIB, Document number EAB/OP-07:0139.

This MIB Module is an Ericsson-wide SNMP
interface for managing alarms. Main inputs to
the MIB design are the 3GPP Alarm IRP and X.733.
However, an important restriction is that the MIB
only represents the resource view and not
management activities like acknowledgment, etc.
It describes generic notifications used to send
alarm state changes and a table which represents
the current active alarms in the system. The MIB
supports both stateful alarms and stateless
alarms (that have no clear notification).
Stateless alarms are called alerts.

It is important to identify clearly what is to be
considered the same alarm object instance. All
unique alarm *types* are identified by
'AlarmType'. An AlarmType is a one-to-one
mapping with X.733 EventType, ProbabableCause and
SpecificProblem. A pair of integers are used to
specify the alarm type.

A unique alarm object *instance* is the
combination of managed object and AlarmType. In
this way there, is no ambiguity about how alarm
and alarm clear correlation should be performed:
the same managed object instance and AlarmType
shall be used. The same is true for changing
existing alarm states. Severity and
additionalText can be changed on an existing
alarm.

For stateful alarms there are notifications to
report a new alarm and a cleared alarm. Changing
an alarm is done via the new alarm notification.
The management system shall match the alarm by
using alarm type and managed object instance in
the same way as for clear notifications.

The MIB has different notifications for different
severities in order to support SNMP managers
which maps severities based on notification
identifiers. For stateless alarms, there are
generic notifications to send the alarm raise
with different severities.

A table lists all active alarms so that a manager
can read an initial state and also perform an
alarm resynchronization procedure. There is also
a table of latest stateless alarms. Since the
stateless alarms do not have a corresponding
clear message, the table size is limited by the
agent instrumentation.

The MIB supports two approaches for detecting
lost notifications:
- sequence numbers are used in the alarm
 notifications, and are shown in the active
 alarm table. The last used sequence number can
 be read in a scalar variable
- a time stamp indicates the last time alarm
 tables where updated.

Heartbeat mechanisms are supported both in pull
and push mode:
- Pull: the classical SNMP polling where a
 manager polls a scalar variable, for example
 the last sequence number used
- Push: the agent can be configured to send
 heartbeat notifications. These contains the
 last used sequence numbers.

Document number: 5/196 03-CXC 172 7549, Rev A