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

• Initiate an O1 Heartbeat test to ensure 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/or
• 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

...

[Question: where is this defined in O-RAN OSC?  Or use Netconf’s keep-alives and reconnection strategy for persistent or periodic SSH/TLS sessions (per IETF draft-ietf-netconf-netconf-client-server-02).]

...

The RIC Health Status Retrieval request will return a list of outstanding alarms and alerts identified in the last self-check.  This request is sent over O1 (NetConf).  As mentioned described in the RIC Self-Check section above(Flow #1), outstanding alarms are stored and are available as alarm-list in the O1 Netconf/Yang model.  So, the request can is simply by a query of the NetConf/Yang operational tree.  The operational tree would have a leaf with state information related to the RIC, including an alarm-list and other pertinent data. [Steps 1-4 in Figure 2]

 

...

 (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

request will trigger a complete self-check (as defined in the previous section) to be run, which will invoke internal “2^nd hop” requests to validate the health of each common RIC platform function, each hosted xAPP instance, and the E2 interface.  With multiple 2^nd hop checks being invoked, 1 or more asynchronous notifications may be returning to the NB client.  The notifications will comprise the overall health telemetry report that covers the RIC’s FM, heartbeat (interface) and PM information.  This on-demand feature may 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.

Figure 2 shows the corresponding sequence flow diagram. 

@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>> NetconfO1Netconf get_config
O1TERM -> SMO_O1 : <<O1>> Healthy/OK


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


Note over SMO_O1 #lightsalmon
 Alarm/Alert 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 Alarms/AlertsList



=== 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>> Establish NetConf Session
SMO_O1 -> O1TERM : <<O1>> Subscribe to HC Notifications
SMO_O1 -> O1TERM : <<O1>> Perform HealthCheck
Note Right 
 InitiateInitial: On-Demand HealthCheckUpdate -
of PlatformAlarm Modules, xAPPs, E2
End note

O1TERM --> SMO_O1 : HealthCheck started ackList
 Longer term: May re-run RIC self-check 
End note

Note over SMO_O1 #lightsalmon
 Support HealthCheck Telemetry (FM, Heartbeat, PM)
End Note
RefO1TERM over SMO_O1,-> HC : request Performalarm RICupdate
HC Self-Check> (SeeO1TERM RIC: Self-Check flows)alarm updates

O1TERM --> SMO_O1 : <<O1>> On-Demand HC Notification
SMO_O1 <-> O1TERM : <<O1>> Terminate NetConf Session
SMO_O1 -> OTF : HC Results/Alarms/Alerts

updated alarm-list

SMO_O1 -> OTF : HealthCheck Completed
OTF -> SMO_O1 : Get HC Performance ResultsAlarm List
OTF -> OTF  :
Note right : Evaluate O1 HealthCheck results and Alarms/Alerts

@enduml

...