The O1 RIC Health-check flow is to enable a northbound client to:
- Initiate an O1 Heartbeat test to ensure that the O1 is alive
- Retrieve the health of the RIC based on the last self-check performed, and/or
- Request an on-demand health-check.
Figure 2 shows the corresponding sequence flow diagram.
The O1 Heartbeat test will enable the NB client to check whether the O1 NetConf interface to the RIC is still alive. The heartbeat 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). This heartbeat method could also be extended beyond the RIC to other RAN resources supporting the O1 interface. [Steps 1-2 in Figure 2]
[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 in the RIC Self-Check section above, the request can simply by a query of the NetConf 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]
The 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 “2nd hop” requests to validate the health of each common RIC platform function, each hosted xAPP instance, and the E2 interface. With multiple 2nd 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 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.
- A persistent O1 NetConf session has to be established between the NB client (SMO) and RIC, and the NB client has to subscribe to the corresponding topics to receive the Health-check related asynchronous notifications. [6-7 in Figure 2]
- When an On-Demand Health-check is invoked, the RIC responds with an acknowledgement once the RIC’s Health-Check function/module successfully initiated the RIC Self-Check flow described in the previous section. [8-9]
- As results of the RIC Self-Check from platform modules and xAPPs are gathered by the Health-Check function/module, they are stored in the O1 Termination and are sent asynchronously to the NB clients.Where there are failures and/or anomalies, alarms and alerts are also emitted via O1. [10]
- When the On-Demand Health-Check is completed with results sent to the NB client, the O1 NetConf session will be terminated. [11]
- The Operations user can now use the On-Demand health results to evaluate the health of the RIC.
<<insert sequence diagram and plantuml syntax>>
Note: It may be appropriate to group xAPP health checks for a subset of xAPPs that have dependencies on each other. But for the initial implementation, each xAPP is treated independently.