...
For NB interfaces, while the RIC is responsible to check its interface functions (i.e., O1 Termination module and A1 Mediator), heartbeats or keep-alive signals over O1 and A1 are verified by the NB clients invoking the O1 and A1. (see sections below on Flows #2 and #3)
<<insert sequence diagram and plantuml syntax>>
The specific Health-Check validations are as follows (see flow diagram on Figure 1):
...
- Health of RIC platform modules –
- Ability to initiate a Health-check on each of the common platform modules within the RIC (e.g., logging, tracing, conflict manager, xAPP manager, subscription management, O1 Termination, A1 Mediator, etc.), store results and declare alarm/alert conditions [5 in Figure 1]
- Ability for each common platform module in the RIC to perform a self-check [6]
- Implementation Option[1]: The self-check can potentially leverage Kubernetes Liveness and Readiness probes. Liveness probes can be configured to execute a command, issue a http-get, and open a TCP socket against the container/pod. Readiness probes can be configured to ensure the pod is ready before allowing it handle traffic. To further check a module’s (pod) ability to communicate with other modules over RMR (RIC Message Router), each module could subscribe to its own topic, send a hello-world message regularly to itself and ensure it can send and receive messages.
- Any alarm/alert conditions or clearing of alarms/alerts are sent immediately via the O1 VES interface. [7-8]
- Health of xAPPs
- Ability of RIC to invoke Health-check requests to each of the xAPP instances deployed on the RIC [9]
- Ability of each xAPP to perform Health-checks on itself and respond back to the RIC [10]
- Implementation Option: See Implementation Option above for platform modules.
- Any alarm/alert conditions or clearing of alarms/alerts are sent immediately via the O1 VES interface. [7-8]
- Health of E2 interface - Ability to send request downstream RAN resources (O-CU/O-DU) via E2 interface for PM collection and report generation, and receive PM report [13-15]
- Any alarm/alert conditions or clearing of alarms/alerts are sent immediately via the O1 VES interface. [16]
- Health of Overall RIC Instance based on Health-Check results (successes, failures and anomalies), mapped to alarms and alerts (which represent RIC’s operability) are stored . [17]
- Ability to update alarms for queries by NB clients.For example, RIC alarms/alerts can be incorporated into the O1 NetConf operational tree. The corresponding Yang model might need to be augmented (e.g., define health state leaf with alarm-list in the Yang model).
- Ability to make performance test results available to NB clients (for on-demand requests) [19-22]
...
Figure 1 below shows the flow of RIC Self-Checks – regular heartbeats over O1 and A1, the Health-Check Module initiating health-check requests within the RIC to assess its overall health, and issuing alarms/alerts, as appropriate based on health results.
<<insert sequence diagram and plantuml syntax>>
Note 1: Figure 1 above shows the flows assuming that SMO is the northbound client that triggers the near-RT RIC. The SMO consists of the O1 OAM adapter (supporting both O1VES and O1NetConf related messages/data) and the non-RT RIC (containing the A1 adapter). The O-RAN SC implementation of the flows associated with this Health-check use case should create a simulated SMO for invoking requests and processing responses. The simulated SMO should also provide a Test Driver (shown in Figures 2-4) for initiating requests to SMO and receive response from SMO. Alternatively, a Dashboard can also be the NB client to trigger these requests.
[1] Implementation options are suggested at the use case level, to be further fleshed out during user stories phase.
...