---
# System prepended metadata

title: Chapter 8 Fault Management
tags: [WG4]

---

# 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


![](https://i.imgur.com/yhmy2Yt.png)


## 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.

![](https://i.imgur.com/ApSLDH5.png)


## 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:

![](https://i.imgur.com/OrsTD53.png)


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

![](https://i.imgur.com/10NSnVm.png)


![](https://i.imgur.com/UigZr4S.png)

![](https://i.imgur.com/jxvCQhx.png)


## 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.