O1 Managed Function (O-CU/O-DU/O-RU) Health-Check (Flow #4)

Owned by John Ng
Last updated: Jan 19, 2020
2 min read

The O1 Managed Function (MF) Health-check flow is defined to be applicable for all 3 MFs: O-CU, O-DU, and O-RU.  The MF flow is consistent with the flows defined for the RIC: 1) Self-check, 2) O1 Heartbeat test, 3) O1 health/alarm retrieval, and 4) O1 On-demand O1 health-check. 

 Figure 4 shows the corresponding sequence flow diagram. 


  • MF Self-Check at regular intervals – This fulfills the requirement that all systems need to monitor their own health – internal subsystems, hosted software, and external interfaces. The MF – whether it’s O-CU, O-DU, or O-RU – needs perform its own self-check at a configurable interval.  The self-check loops through all the software and hardware modules of the MF and store the results for later retrieval.  The MF determines whether anomalies found require alarms or alerts to be declared, and event notifications to be sent out over the O1VES interface.  The presence of alarm conditions would be used to derive the state of the MF.  The self-check needs to cover fault management, performance management (PM report files) and heartbeats (interface alive).  [see 1-5 in Figure 4]
  • O1 MF Heartbeats – This enables a northbound client like SMO to initiate an O1 Netconf Heartbeat test to the MF, ensuring that the O1 is alive. The MF’s O1 termination needs to respond to such regular heartbeat checks. [6-7]
  • Health Status Retrieval – This enables a northbound client (SMO or Dashboard) to retrieve the health of the RIC based on the last self-check performed. As self-check results are stored, the O1 Netconf operational tree should be updated so that the Health Status Retrieval request can be performed rapidly with minimal processing – generally the alarm-list is provided as the response to the request. [8-10]
  • On-demand Health-Check – This enables a northbound client (SMO or Dashboard) to trigger a self-check to be performed on-demand. This on-demand feature may be used by operations users to confirm fault conditions, get better/more real time diagnostics, verify MF operational state as the last step in remedying a fault.  As the MF performs the self-check on all its modules, new alarms may be generated, and existing alarms may be cleared.  Those notifications will be sent over O1VES.  In addition to storing self-check results, the MF will also send results to the northbound client in one or more responses.  If PM report files are generated, the location reference to the files are sent to the NB client for later retrieval. [12-18]   



Note 1: Need to identify the specific commands to invoke for O-CU, O-DU, and O-RU and whether they vary across vendors.

Note 2: Additional flows might be needed to distinguish health checks on O-CU-CP vs O-CU-UP and whether additional interfaces need to be checked (e.g., F1-u/F1-c)