# Chapter 8 Fault Management
###### tags: `WG4`

- NETCONF server is response for manage **" active-alarm-list "**
- Fault management is response for sending alarm notifications.
- when the alarm reason disappears then the alarm is cleared
- removed from the “active-alarm-list”.
- when the element that was the “fault-source” of an alarm is deleted
- then all related alarms are removed from the “active-alarm-list”.
- NETCONF client (Event collector) need to subscribe at first
- The NETCONF Client can read “active-alarm-list” by `get rpc` operation


## 8.1 Alarm Notification

The O-RU is responsible to send `<alarm-notif>` to a configured subscriber when the NETCONF Client has established a subscription to alarm notification

- **a new alarm is detected**
- this can be the same alarm as an already existing one, but reported against a different “fault-source” than the existing alarm
- **an alarm is removed from the list**
Removal of alarms from the list due to deletion of “fault-source” element is considered as clearing and cause sending of to the configured subscriber. This applies to alarms which were explicitly related to the deleted “fault-source” element. The rationale for such is to avoid misalignment between NETCONF Clients when one NETCONF Client deletes an element.

- The O-RU reports in `<alarm-notif>` only for new active or cancelled alarms, not all active alarms.


## 8.2 Manage Alarms Request to NETCONF Clients

The NETCONF Client can “subscribe” to Fault Management Element by sending create-subscription, RFC5277 [21], to NETCONF Server

**Case 1)** NETCONF client subscribes alarm-notif filtering fault-severity:

**CRITICAL**, **MAJOR** and **MINOR** and **measurement-result-stats** filtering **transceiver-stats** and **rx-window-stats** which measurement-object is RX_ON_TIME only:


**Case 2)** NETCONF client subscribes default event stream NETCONF to receive all notifications defined in O-RAN YANG modules:




## 8.3 Fault Sources

Alarm notifications reported by NETCONF Server contain element “fault-source” which indicates the origin of an alarm. In general values of “fault-source” are based on names defined as YANG leafs

- **Source (Examples: fan, module, PA, port)**
indicates that origin of the alarm within the O-RU. Value of “fault-source” is based on element name.
- **Source (other than when an element is within the O-RU)**
Value of fault-source may be empty or may identify the most likely external candidate; for example, antenna line.

Alarms with different **“fault-id”**, **“fault-source”** or **"fault-severity"** are independent

- Multiple alarms with same **“fault-id”** may be reported with different **“fault-source”**.
- Multiple alarms with same **“fault-source”** may be reported with different “fault-id”.

The range of "fault-id" is separated to common and vendor specific. The common fault-ids are defined in Annex A and more number will be used in future.

- The vendor specific range for the fault-id shall be [1000 .. 65535]

## 8.4 Manage Alarms Request to Event-Collector

instead of sending a NETCONF to the NETCONF server in the O-RU to subscribe to the alarm-notif notifications,the NETCONF client **installs the subscription via configuration of the O-RU’s datastore.**

Based on configured subscriptions, the O-RU sends asynchronous YANG notifications over HTTPS to the configured Event-Collector.