OID repository
OID Repository
http://oid-info.com
Display OID:
 
Action itemiso(1) Action itemidentified-organization(3) Action itemdod(6) Action iteminternet(1) Action itemprivate(4) Action itementerprise(1) Action item193 Action itemericssonModules(183)  

Navigating the OID tree

ericssonAlarmXpathMIB(6)
child OIDs: Child OID separator eriAlarmXObjects(1) Child OID separator eriAlarmXNotifications(2) Child OID separator eriAlarmXConformance(4) Child OID separator
 
Separation line
 
OID description

   
OID: (ASN.1 notation)
(dot notation)
(OID-IRI notation)

Description:

ericssonAlarmXpathMIB MODULE-IDENTITY
LAST-UPDATED "201708110000Z"
ORGANIZATION "Ericsson AB"
CONTACT-INFO
"EEIEMY"
DESCRIPTION
"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
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 YangNodeInstance and AlarmType.
In this way, there is no ambiguity about how alarm
and alarm clear correlation should be performed:
the same YANG resource instance and AlarmType
shall be used. The same is true for changing
existing alarm states. Severity, Additional Text
and Additional Info 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 YangNodeInstance
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 alerts, there are
generic notifications to send the alerts
with different severities.
NOTE - Updated Definition of Alerts in TEA (The
Ericsson Architecture):
Alerts are used by service management systems
to evaluate service impact, and are only applicable
to very specific state changes with potential service
impact like restart and redundancy shifts.
Alerts SHALL NOT be used for fault indication.
Alerts should always have Perceived Severity
Indeterminate, and should only be sent using
eriAlarmXIndAlert notification. The other severity
alert notifications should not be used, and are
only present in this specification for
backward compatibility reasons.
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 were 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: 11/196 03-CXC 172 7549."
REVISION "201708110000Z"
DESCRIPTION
"Fixed duplicate object names issue, by replacing
prefix eriAlarm with prefix eriAlarmX where needed.
Increased overall size of Additional Info.
Added new OBJECT-TYPE:
eriAlarmXNObjAppendedAdditionalInfo.
Added new IMPORT:
EriAppendedAdditionalInfo.
Fixed CONFORMANCE GROUPS issue by separating
recently added OBJECT-TYPES into new
CONFORMANCE GROUPS.
Added new GROUPS:
eriAlarmXActiveAlarmsAdditionalInfoGroup,
eriAlarmXAlertsAdditionalInfoGroup,
eriAlarmXRecordTypeGroup.
Added more detail to DESCRIPTION for each REVISION.
Document number: 11/196 03-CXC 172 7549, Rev C."
REVISION "201704130000Z"
DESCRIPTION
"Updated as part of ERICSSON ALARM MIB 2.1 package.
Added new OBJECT-TYPES:
eriAlarmNObjAdditionalInfo,
eriAlarmNObjMoreAdditionalInfo,
eriAlarmNObjRecordType,
eriAlarmActiveAdditionalInfo,
eriAlarmAlertAdditionalInfo.
Added new IMPORTS:
EriAdditionalInfo,
EriLargeAdditionalInfo,
EriAlarmRecordType.
Document number: 11/196 03-CXC 172 7549, Rev B."
REVISION "201606240000Z"
DESCRIPTION
"Initial version of this MIB module.
Document number: 11/196 03-CXC 172 7549, Rev A."


 
Short URLs for this page:

Disclaimer: The owner of this site does not warrant or assume any liability or responsibility for the accuracy, completeness, or usefulness of any information available on this page (for more information, please read the complete disclaimer).
All rights reserved, Orange © 2024
Tree display Parent OID: ericssonModules(183) First child OID: eriAlarmXObjects(1) First sibling OID: ericssonTCMIB(1) Previous sibling OID: ericssonDiscoveryMIB(5)
Separation line
OID helper Webmaster Bullet 4 Aug 2022 Bullet Page top