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]   

O1 Managed Functions (O-CU/O-DU/O-RU) Health-Check Personnel SMO O-RAN Managed Function (MF) «INT»Test Driver «INT»Test Driver «OAM»O1 «OAM»O1 «NONRTRIC»Non-RT RIC «NONRTRIC»Non-RT RIC «MF»Managed Function «MF»Managed Function MF = O-CU, O-DU or O-RU MF Self-Checks @ Regular Internals Support Healthcheck Telemetry (FM, Heartbeat, PM) 1Loop thru allmodules in MF MF Self-Checks Initiated- Determine alarms/alerts, Store HC results, Generate PM file alt[Alarm State Change Detected] Support Alarm Notifications 2«O1VES» Alarms/Alerts/Clears alt[If HC is performed on-demand, make file available to client] Publish Results 3«O1VES» HealthCheck Performance File Available 4«O1»Get PM Report File 5Make PM File Available for Sharing O1 MF (O-CU, O-DU, O-RU) Heartbeat Provide E2E Healthcheck Test: Heartbeat Test, Retrieve Alarms, On-Demand HealthCheck 6«O1» Netconf get_config 7«O1» Healthy/OK O1 MF (O-CU, O-DU, O-RU) Health Status Retrieval (Alarms/Alerts) Alarm/Retrieval:- SMO or Dashboard able to retrieve any defined alarms- Support O1 Health/Alarms Report Retrieval 8Retrieve Health Status 9«O1» NetConf get alarm-list 10«O1» alarm-list 11Alarms/Alerts O1 MF (O-CU, O-DU, O-RU) On-Demand HealthCheck Support O1 Healthcheck Provisioning Command 12On-Demand Healthcheck 13«O1» Perform Healthcheck Support HealthCheck Telemetry (FM, Heartbeat, PM) refPerform MF Self-Check (See MF Self-Check flows above) 14«O1» On-Demand HC Notifications: HC results, alarms, alerts 15HC Results, Alarms, Alerts 16HealthCheck Completed 17Get HC Performance Results 18  Evaluate O1 HealthCheck Results and Alarms/Alerts


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)





  • No labels