Contents

1   Understanding the Ericsson Alarm Interface

1.1   The Ericsson Alarm Interface in a Management Solution

The Ericsson Alarm Interface provides a unified way to expose the alarm status of an Ericsson Managed Element (ME) to a management system or a Command-Line Interface (CLI) client.

The Ericsson Alarm Interface consists of alarm handling capabilities exposed over the following interfaces:

• Ericsson Command-Line Interface – A Man–Machine Interface realized as a CLI reachable through the SSH
• Ericsson NETCONF Interface – A Machine-Machine Interface based on the IETF NETCONF standard (RFC 4741) with SSH as transport (RFC 4742)
• Ericsson Alarm MIB over SNMPv1, SNMPv2, and SNMPv3 – SNMP is used to report failures to the management system

Alarm information is available in the ECLI, NETCONF, and SNMP interfaces and in log files.

For a complete description about the ECLI, refer to Ericsson Command-Line Interface.

For a complete description of the Ericsson Network Configuration (NETCONF) interface, refer to Ericsson NETCONF Interface.

1.2   Key Features for Ericsson Alarm Interface

1.3   Ericsson Alarm Interface Concepts

An alarm is an indication of a fault that has occurred or is likely to occur and that requires human intervention and action. An alarm is stateful which means that the state can either be raised or cleared. The severity level can be changed by the system by either increase or decrease the severity of the alarm. An alarm is cleared when the underlying fault no longer exists.

An alert is a stateless alarm, that is, an alarm that can only have the raised state.

An alarm notification is an alarm state change sent over SNMP. Alarm notifications are sent when an alarm is initially raised, updates its severity, updates its additional text, and is eventually cleared.

Alarm types define what alarms a ME can actually report. An alarm is uniquely identified by the combination of its source with an alarm type. An alarm type is uniquely identified based on the {major type, minor type} combination or the {specific problem, probable cause, event type} combination.

1.3.1   Alarm List Rebuilt Event

This event is reported as a SNMP notification when the ME active alarm list reaches a stable situation after a restart or after an ME internal audit process. It is an indication to the SNMP targets to perform the following:

• Retrieve the ME active alarm list.
• Compare the retrieved list with their own list of active alarms.
• Appropriately handle any change between the two lists.

1.3.2   Heartbeat Event

Alarms and alerts may not always reach a management system because of network issues. Such situation can lead to longer service deterioration or unavailability. The heartbeat mechanism enables a management system to detect quickly alarm/alert loss so the ME is not left unattended during a too long period.

Two heartbeat mechanisms are supported: pull heartbeat and push heartbeat.

The heartbeat mechanism enables a management system to detect quickly if some alarms or alerts have been lost.

With the pull mechanism, a management system regularly polls the following information on the ME:

• The last event time stamp, that is, when any alarm was last changed.
• The last used sequence number for an alarm state change notification.

A management system can pull this information using NETCONF or SNMP. The ECLI is not recommended in this case.

With the push mechanism, the ME instead reports Heartbeat events to a management system at a regular time interval. Heartbeat events contain the same information as in the pull mechanism. The push mechanism is supported only over SNMP using an SNMP notification. It can therefore only be used by management systems acting as SNMP targets.

1.3.3   Other Events

Reporting of all other events is done over NETCONF notifications and is not handled by FM.

2   Alarm Interface Capabilities NBI Exposure

3   Ericsson Alarm MIB Modules Overview

The Ericsson Alarm MIB consists of five different MIB modules.

General imported modules:

• Ericsson-TOP-MIB

  The Ericsson enterprise OID.

• Ericsson-TC-MIB

  Textual convention for Managed Objects and other Ericsson-specific generic textual conventions.

• Ericsson-ALARM-MIB

  The main MIB with alarm tables, alarm notifications, heartbeat, and so on.

  Note:  

  The Ericsson Alarm Management Information Base (MIB) is supported with the following exemptions:

  
  
  • The alert table, eriAlarmAlertTable, is always empty.
  • eriAlarmActiveTableURL always returns an empty string.
  • eriAlarmAlertTableURL always returns an empty string.
• Ericsson-ALARM-PC-MIB

  Separate module for probable cause.

• ERICSSON-ALARM-TC-MIB

  Textual convention used in the alarm MIBs.

4   Alarm Type Information Mapping to NBI

Alarm information is available in the SNMP, CLI, and NETCONF interfaces and in log files, as described in this section.

A summary of the number of active alarms is available as follows:

• eriAlarmActiveAlarms, eriAlarmSumCritical, eriAlarmSumMajor, eriAlarmSumMinor, and eriAlarmSumWarning SNMP objects of the ERICSSON-ALARM-MIB

  Note:  

  The number of alarms of indeterminate severity is available in the SNMP as eriAlarmSumIndeterminate only.

  
  
• Attributes totalActive, sumCritical, sumMajor, sumMinor, and sumWarning of MO Fm in the COM CLI and NETCONF

  Note:  

  While reading the Fm subtree in a particular transaction, the statistics attributes in Fm (that is totalActive, sumMajor, sumMinor, and so on) cannot always be in sync with the actual FmAlarm instances.

  
  

Information about the last issued alarm is available as follows:

• SNMP objects eriAlarmActiveLastSequenceNo and eriAlarmActiveLastChanged of the ERICSSON-ALARM-MIB
• Attributes lastChanged and lastSequenceNo of MO Fm in the COM CLI and NETCONF

Column FmAlarmType shows what static alarm model information is visible over NETCONF and the ECLI. Column FmAlarm shows what active alarm information is visible over NETCONF and the ECLI. Column ERICSSON ALARM MIB is mainly for reference and indicates how the information is mapped on the SNMP interface.

5   Alarm Instances Information Mapping to Notification

6   Heartbeat Information Mapping to NBI

In Table 6, the columns NETCONF/ECLI and ERICSSON ALARM MIB show what information a management system must access to implement a heartbeat pull over NETCONF and SNMP, respectively.

Events AlarmListRebuilt and HeartBeat are reported using NOTIFICATION-TYPE eriAlarmHeartBeatNotif and eriAlarmAlarmListRebuilt, respectively, according to ERICSSON-ALARM-MIB.

The heartbeat interval of the COM SNMP alarm interface is configurable as follows:

• SNMP object eriAlarmHbInterval of the ERICSSON-ALARM-MIB
• Attribute heartbeatInterval of the Fm Managed Object (MO) in the COM CLI or NETCONF

7   Mapping Between IETF MIB Framework and ECLI/NETCONF Model

8   Alarm Log and Alert Format

The Alarm Log and Alert Log files are exposed by File Management as two file groups named AlarmLogs and AlertLogs, respectively.

Alarm Log files are rotated. Internal limits set the maximum file size and the maximum number of files. When the maximum number of files is exceeded, the oldest file is deleted automatically. The same behavior applies to Alert Log files.

The Alarm Log and Alert Log records are encoded in a common XML format. The log record consists of two elements. The first element indicates the time the record is logged. The second element contains specific information about the alarm or alert and is formatted as a semicolon-separated string.

<FmLogRecord>
 <LogTimestamp>2014-03-06T11:20:15Z</LogTimestamp>
 <Alarm>
2014-03-06T11:20:14Z; ManagedElement=CSCF06ST,SystemFunctions=1,Brm=1,BrmBackupManager=⇒
SYSTEM_DATA,BrmBackupScheduler=SYSTEM_DATA;193;327681;BRM, Scheduled Backup Failed;418;MAJOR;⇒
Scheduled Backup for SYSTEM_DATA failed with disk space error;33;OTHER
 </Alarm>
</FmLogRecord>

<FmLogRecord>
 <LogTimestamp>2014-03-06T11:20:25Z</LogTimestamp>
 <Alarm>
2014-03-06T11:20:25Z; ManagedElement=CSCF06ST,SystemFunctions=1,Brm=1,BrmBackupManager=⇒
SYSTEM_DATA,BrmBackupScheduler=SYSTEM_DATA;193;327681;BRM, Scheduled Backup Failed;418;CLEARED;⇒
Scheduled Backup for SYSTEM_DATA failed with disk space error;34;OTHER
 </Alarm>
</FmLogRecord>