The near-RT RIC (RIC for short) Self-Health-Check flow fulfills the requirement that all systems need to monitor their own health – internal subsystems, hosted software, and external interfaces.  At configurable intervals, RIC is to trigger Health-Check requests to its internal common platform modules and hosted xAPPs.  Each platform module and each xAPP are required to support Health-Check requests and to perform a self-check.  The RIC also exercises the E2 interface to ensure it is operational and receiving data from downstream RAN resources. 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). 

Platform Modules and xAPPs

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]

External Interfaces

For northbound (NB) interfaces, the RIC is responsible to check its interface functions - O1 Termination module and A1 Mediator.  In addition, heartbeats or keep-alive signals over O1 are verified by the NB clients invoking the O1.  

The RIC also checks the E2 interface - initially its heartbeat to individual RAN resources, and progressive the latency of messages/data flow over E2.  

Note: Since the role of RIC is to enable near realtime control loop actions, latency is an important set of telemetry to be collected and reported - E2 latency and RIC processing latency.  As RIC matures release over release, latency telemetry should be defined and implemented.

• 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]

...