Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x
Top   in Index   Prev   Next

TS 32.121
Telecommunication Management –
Advanced Alarm Management (AAM) Integration Reference Point (IRP):
Requirements

3GPP‑Page   ETSI‑search   CONTENT↓
V17.0.0 (PDF)  2022/03  9 p.
V16.0.0  2020/06  9 p.
V15.0.0  2018/06  9 p.
V14.0.0  2017/03  9 p.
V13.0.0  2016/01  9 p.
V12.0.0  2014/10  9 p.
V11.0.0  2012/09  9 p.
V10.0.0  2011/04  9 p.
V9.0.0  2009/12  9 p.
V8.0.1  2010/06  9 p.
Rapporteur:
Dr. Pollakowski, Olaf
Nokia Networks

Content for  TS 32.121  Word version:  17.0.0

Here   Top

0  Introduction  p. 4

The present document is part of a TS-family covering the 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication management; as identified below:
32.121:
"Advanced Alarm Management Integration Reference Point (IRP): Requirements";
32.122:
"Advanced Alarm Management Integration Reference Point (IRP): Information Service (IS)";
32.126:
"Advanced Alarm Management (AAM) Integration Reference Point (IRP); Solution Set (SS) definitions".
The Itf-N interface is built up by a number of IRPs and a related Name Convention, which realize the functional capabilities over this interface. The basic structure of the IRPs is defined in TS 32.150.
IRPManagers (typically Network Management Systems) and IRPAgents (typically EMs or NEs) synchronize their data concerning alarms or configuration data. In certain scenarios this synchronization is lost or not done.
This IRP provides functionality to significantly reduce the amount of data which needs to be transferred in order to re-establish synchronization.
Up

1  Scope  p. 5

The purpose of this set of specifications is to provide a mechanism enabling the IRP Manager to improve the information content of alarms, thereby contributing to reduce the time-to-repair. For this configurable rules for advanced alarm filtering are defined to reduce the number of alarms by applying such advanced alarm filtering.
The present document contains the Requirements of Advanced Alarm Management (AAM) on Itf-N IRP.
It defines, for the purpose of AAM on Itf-N, the basic requirements to be fulfilled on Itf-N.
Up

2  References  p. 5

The following documents contain provisions that, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TS 32.150: "Telecommunication management; Integration Reference Point (IRP) Concept and definitions".
Up

3  Definitions and abbreviations  p. 5

3.1  Definitions  p. 5

For the purposes of the present document, the following terms and definitions apply:
IRP:
See TS 32.150.
IRPAgent:
See TS 32.150.
IRPManager:
See TS 32.150.

3.2  Abbreviations  p. 5

For the purposes of the present document, the following abbreviations apply:
IRP
Integration Reference Point
IS
Information Service
Itf-N
Interface N
NE
Network Element

4  Requirements for AAM on Itf-N  p. 6

4.1  Concept  p. 6

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
Up

4.2  General Requirements for AAM on Itf-N  p. 6

4.2.1)
The IRPManager should be able to request the IRPAgent to
  1. categorize alarms as insignificant or significant
    and
  2. 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.
Up

$  Change History  p. 7

Up   Top