...

[1] Implementation options are suggested at the use case level, to be further refined/finalized during user stories phase.

Near-RT RIC angle: RIC-139 for platform parts.

Alarms, Clearings and Notifications

• As anomaly conditions are encountered as part of the self-check process or during normal operation (e.g., cannot send message to another module/xApp via RMR), the RIC and/or the specific platform module/xAPP needs to determine the severity and whether they are mappable to an alarm type.  If mappable to an alarm type, the RIC needs to declare the alarm condition.  
• The alarm type definitions for platform modules and xAPPs should be consistent with 3GPP TS 28.545 Fault Supervision technical specification.  
• New alarms declared in either case (self-check or normal operation) require notifications to be sent immediately via the O1 VES interface, after verifying against the current RIC alarm list that the alarm is indeed new.
• New alarms are to be stored and captured as part of the alarm list of the RIC.  To support queries from NB clients for outstanding alarms via O1 Netconf interface, the RIC needs to make the alarm list available in the yang operational tree.  The yang model may need to be updated to support the alarm queries.  
  • Since alarms are sent as VES events over O1 VES, a mapping or translation function between VES alarms and Netconf/Yang model might needed. 
• Similarly, the RIC needs to identify alarms that are not longer present by comparing self-check results against the current alarm list.  Any cleared alarms need to be removed from the RIC alarm list and clearing notifications sent over O1 VES. 

Near-RT RIC angle: RIC-56 for alarms

Health-Check Function

To support these flows, a new Health-Check functional block within the RIC is being proposed.  This Health-Check functional block can be implemented as a separate software module, as a distributed function across one or more existing modules, and/or as existing capabilities already available from the underlying container infrastructure such as Kubernetes' container/pod lifecycle management.  The Health-Check functional block has to perform the following:

• Trigger health-checks on the common RIC platform functions/modules and on xAPP instances hosted on the RIC (self-checks at configured intervals and on-demand requests)
• Map failures and anomalies to alarms 
• Send out notifications for new alarms 
• Determine the state of the RIC based on alarms 
• Log health-check results and update alarm list for queries
• Clear alarms and alerts when conditions clear

Near-RT RIC angle: RIC-56 for alarms, incl list and notifications

The sequence diagram below shows the flow of RIC Self-Checks:

...

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.  E2 latency includes telemetry that measures incoming messages/data to the RIC as well as outgoing messages from the RIC to Managed Functions.  RIC processing latency is telemetry that measures the RIC/xAPPs control loop processing time to receive messages, apply analytics, determine control loop actions and generate outgoing messages to RAN Managed Function over E2.  As the RIC matures release over release, latency telemetry must be defined and implemented.

Near-RT RIC angle: RIC-30, RIC-33, RIC-35, RIC-69 for latency measurements

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. 

...