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.

@startuml
Autonumber
Skinparam sequenceArrowThickness 2
skinparam ParticipantPadding 5
skinparam BoxPadding 10

Box Personnel #lightblue
  Participant OTF as “Test Driver” <<INT>>
End box

Box SMO #gold
    Participant SMO_O1 as “O1” <<OAM>>
    Participant RPGE as “Non-RT RIC” <<NONRTRIC>>
End box

Box “O-RAN RIC” #lightpink
    Participant O1TERM as “O1 TERM” <<RIC>>
    Participant HC as "HealthCk Module" <<RIC>>
    Participant MOD as "Platform Modules" <<RIC>>
    Participant xAPP as “xAPPs” <<RICAPP>>
    Participant E2SIM as “E2 Node” <<SIM>>
End box


Note over SMO_O1 #lightsalmon
Provide E2E HealthCheck Test:
- Heartbeat Test
- Retrieve Alarms 
- Request On-Demand Full HealthCheck (Heartbeat, FM, PM)
End note

=== O1 RIC Heartbeat ==

Note Right #lightsalmon
 O1 Netconf Heartbeat between SMO and RIC
End Note
O1TERM -> SMO_O1 : <<O1>> O1VES Keep-alive
SMO_O1 -> O1TERM : <<O1>> O1Netconf get_config
O1TERM -> SMO_O1 : <<O1>> Healthy/OK


=== O1 RIC Health Status Retrieval (Alarms) ==


Note over SMO_O1 #lightsalmon
 Alarm Retrieval:
 -SMO or RIC dashboard able to retrieve any defined alarms
 -Support O1 Health/Alarms Report Retrieval
End note
OTF -> SMO_O1 : Retrieve Health Status
SMO_O1 -> O1TERM : <<O1>> NetConf get alarm-list
O1TERM -> SMO_O1 : <<O1>> alarm-list
Note Right 
 alarm-list defined & stored as leaf in O1 Yang model
End note
SMO_O1 -> OTF : Alarm List



=== O1 RIC On-Demand HealthCheck ==
Note over SMO_O1 #lightsalmon
  Support O1 Healthcheck Provisioning Command
  - Telemetry Report: Heartbeat, FM, PM
End Note

OTF -> SMO_O1 : On-Demand HealthCheck
SMO_O1 -> O1TERM : <<O1>> Perform HealthCheck
Note Right 
 Initial: On-Demand Update of Alarm List
 Longer term: May re-run RIC self-check 
End note

Note over SMO_O1 #lightsalmon
 Support HealthCheck Telemetry (FM, Heartbeat, PM)
End Note
O1TERM -> HC : request alarm update
HC -> O1TERM : alarm updates

O1TERM --> SMO_O1 : <<O1>> updated alarm-list

SMO_O1 -> OTF : Alarm List
OTF -> OTF  :
Note right : Evaluate O1 HealthCheck and Alarms

@enduml