A single network fault may generate a large number of alarms over space and time. In a large and complex network, simultaneous network faults may occur, causing the network operator to be flooded with high volume of alarms.
The high volume of alarms, typically the one received by an IRPManager via the getAlarmList or alarm notifications of Alarm IRP specification, greatly inhibits the operator ability to quickly identify and locate the responsible network faults.
Therefore it is considered advantageous to have methods categorizing network alarms as insignificant or significant. The word 'insignificant' does not imply "low priority". In the context of this specification the words 'significant' and 'insignificant' have the following implications:
-
IRPAgent shall not report alarms categorized as insignificant.
-
IRPAgent shall report all significant alarms.
Reporting only significant alarms and not reporting insignificant alarms would reduce network operator's time to locate network faults so that more time can be spent fixing them.
When reading the alarmList it can be advantageous to partition alarms in the alarmList into sets of alarms which might be caused by the same network fault.
By assigning network operators to locate network faults based on alarms in such alarm partitions, rather than based on alarm severity, alarm type or reporting location, duplication of network operator effort (e.g. two network operators work on two different alarms and their resolutions lead to the same network faults) can be reduced or avoided
4.2.1)
The IRPManager should be able to request the IRPAgent to
-
categorize alarms as insignificant or significant
and
-
to act based on these categories, e.g. to discard if insignificant.
The IRPManager should be able to cancel such requests.
4.2.2)
The standard should define some alarm categorization rules. The standard should also allow vendor to define their own alarm categorization rules.
4.2.3)
Possible alarm categorization rule(s) may depend for example on the type of alarm, the environment, the time of day, the type of network element, the alarm severity, the location, position in the containment tree and many more. No restriction is imposed in this regard.
4.2.4)
The IRPManager should be able to request the IRPAgent for the list of active categorization rules (i.e. standard defined and vendor defined).
4.2.5)
The IRP manager should be able to request the IRPAgent to apply the categorization rule(s) and to remove the insignificant alarms in the following situations:
-
alarm notifications to be sent to any IRPManager
-
advanced alarm management requests by this IRPManager to read the alarm list
Certain types of categorization rules are only to be applied to read the alarm list. The term used for these rules is alarm partitioning rules.