The O1 RIC Health-check flows are to enable a northbound client (SMO) to:

Initiate O1 Heartbeat check or receive a heartbeat signal to verify that the O1 interface is alive
Retrieve the health (alarm list) of the RIC based on the last self-check performed, and
Request an on-demand health-check.

O1 Heartbeat

The O1 Heartbeat consists of O1 VES and O1 Netconf.

O1 VES heartbeat originating from the RIC - There is a heartbeat signal defined for O1 VES. So the NB client will receive regular from the RIC O1 Termination indicating that it is alive.
O1 Netconf heartbeat check triggered by the NB client - The NB client checks whether the O1 NetConf interface is still alive. The heartbeat check from the SMO could be implemented using the already defined NetConf session health-checks (regular <get-config> requests to the RIC to query the operational tree, filtering response to send just OK).

Near-RT RIC angle: RIC-56 for VES heartbeat to show that this connection works, nothing else.

RIC Health Status Retrieval

The RIC Health Status Retrieval request will return a list of outstanding alarms identified in the last self-check. This request is sent over O1 (NetConf). As described in RIC Self-Check (Flow #1), outstanding alarms are stored and are available as alarm-list in the O1 Netconf/Yang model. So, the request is simply a query of the NetConf/Yang operational tree. (Note: some modeling work might be needed.)

Near-RT RIC angle: RIC-56 for implementing an alarm management system and getting active alarm list via O1

RIC On-Demand Health-Check

This on-demand feature is designed to be used by operations users to confirm fault conditions, get better/more real time diagnostics, verify RIC’s operational state as the last step in remedying a fault. The On-Demand Health-Check is meant to trigger a complete RIC Self-Check to be run. However, since the Self-Check is currently leveraging Kubernetes liveness and readiness probes and their extensions to check the health of the Pods, and the check is done every 5-12 seconds, re-running a Self-Check is not meaningful. For the initial implementation, the On-Demand check will trigger the RIC to update its alarm list.

The vision is that a RIC On-Demand Health-Check would trigger a more comprehensive self-check including meaningful diagnostics and telemetry. This use case will be modified release over release to include enhancements that collect and analyze diagnostic and telemetry data, enabling operations users to troubleshoot faults and react to control loop latency.

The figure below depicts the corresponding sequence flow diagram showing the O1 heartbeats, RIC health retrieval and RIC on-demand health-check.

Near-RT RIC angle: RIC-95 (operator-initiated "ping") & RIC-124 for continuous overview of state of E2 connections and RIC-14 for xApp health check or state.