...

• Ability to internally initiate Health-checks on each of the common platform modules within the RIC (e.g., O1 Termination, A1 Mediator, E2 Termination, E2 Manager, xAPP Manager, Subscription Manager, etc.).
• Internal self-checks are to be done at default intervals.  Intervals are to be configurable during run-time.  
• Each platform module is required to support a health-check request.  Initially, the modules may simply need to send a response message to indicate that the connectivity is still up and messaging pathway still operational.  (In later releases, additional diagnostics may be needed to ensure RIC lifecycle management is robust and carrier-grade.)  
• Self-check results on platform modules are to be logged.

Alarms, Clearings and Notifications

...

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.

Alarms, Clearings and Notifications

• Anomaly conditions may be encountered as part of the self-check process or during normal operation (e.g., cannot send message to another module via RMR).  
• For each anomaly condition, the RIC and/or that RIC platform module needs to determine the severity and whether it is mappable to an alarm type.  
• New alarms are to be stored and captured as part of the alarm list of the RIC.
• Alarms found in either case (self-check or normal operation) require a notification to be sent immediately via the O1 VES interface, after verifying against the current RIC alarm list that the alarm is new.
• Similarly, the RIC needs to send alarm clearing notification over O1 VES when an alarm is not longer on the alarm list. 
• RMR

• 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]
  • normalize alarms conditions

...