...
- 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.
External Interfaces
For external interfaces, the RIC is responsible to check its interface functions - O1 Termination, A1 Mediator, and E2 Termination modules - which is already described above as part of the RIC Self-Check. In addition, the RIC needs to support heartbeats or keep-alive signals to ensure RIC-SMO (including other NB clients) and RIC-RAN Resources.
RIC connectivity resources
The RIC also checks heartbeat message come from RAN resources over the E2 interface.
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.
To support this flow, a new Health-Check functional block within the RIC is being proposed, which 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:
...
PlantUML Macro | ||||||
---|---|---|---|---|---|---|
| ||||||
@startuml Autonumber Skinparam sequenceArrowThickness 2 skinparam ParticipantPadding 5 skinparam BoxPadding 10 Box SMO #gold Participant SMO_O1 as “O1” <<OAM>> Participant RPGE as “Non-RT RIC” <<NONRTRIC>> End box Box “O-RAN RIC” #lightpink Participant A1TERM as “A1 MED” <<RIC>> Participant O1TERM as “O1 TERM” <<RIC>> Participant HC as "HealthCk Function" <<RIC>> Participant MOD as "Platform Modules" <<RIC>> Participant xAPP as “xAPPs” <<RICAPP>> Participant E2SIME2TERM as “E2 Node” <<SIM>> TERM” <<RIC>> End box Box “O-RAN Managed Function (MF)” #lightpink Participant MF as “Managed Function” <<MF>> End box Note over MF : MF = O-CU, O-DU or O-RU === Alarms/Alerts from individual RIC Platform Modules and xAPPs == Note over RPGE,HC Note: Apart from Health-Checks, a platform module or xAPP may generate an alarm/alert (or its clearing) when it encounters a failure/error (e.g., failure to reach another module) End Note MOD -> O1TERM : Platform Module Alarm/Alert/Clear O1TERM -> SMO_O1 : <<O1VES>> Alarm/Alert or Clear xAPP -> O1TERM : xAPP Alarm/Alert/Clear O1TERM -> SMO_O1 : <<O1VES>> Alarm/Alert or Clear === RIC Self-Checks @ Regular Intervals == Note over A1TERM,HC #lightsalmon Support HealthCheck Telemetry (FM, Heartbeat, PM) End note Note over HC RIC Self-Checks Initiated End note Group loop for each Platform Module HC -> MOD : Perform HealthCheck Note Left Support Platform Module HealthCheck End Note MOD -> HC : HealthCheck Status End HC -> O1TERM : Platform Module Alarm/Alert/Clear O1TERM -> SMO_O1 : <<O1VES>> Alarm/Alert or Clear Group loop for each xAPP instance deployed HC -> xAPP : Perform HealthCheck xAPP -> HC : HealthCheck Status Note Left #lightsalmon Support xAPP HealthCheck End note End HC -> O1TERM : xAPP Alarm/Alert/Clear O1TERM -> SMO_O1 : <<O1VES>> Alarm/Alert or Clear HCMF -> E2SIME2TERM : <<E2>> Generate Reportkeep-alive Note Left #lightsalmon : Support E2 Test Message Processing E2SIME2TERM -> HC : <<E2>> REPORT HC -> HC : Note Right : Calculate report size response times as PM measuresmissed heartbeat HC -> O1TERM : E2 Alarm/Alert/Clear O1TERM -> SMO_O1 : <<O1VES>> Alarm/Alert or Clear HC -> O1TERM : StoreLog all HC results & update alarm-list in yang model Note Left #lightsalmon : Support Alarm Retrieval from SMO, Dashboard Alt If HC is performed on-demand, make file available to client Note over RPGE : Publish Results HC -> O1TERM : Performance File Available O1TERM -> SMO_O1 : <<O1VES>> HealthCheck Performance File Available SMO_O1 -> O1TERM : <<O1>>Get PM Report File SMO_O1 -> SMO_O1 : Make PM File Available for Sharing End @enduml |
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.
External Interfaces
For health of external interfaces, the RIC is responsible to check its interface module health and the reachability/connectivity by external systems. For RIC interface modules - O1 Termination, A1 Mediator, and E2 Termination modules - the requirement is already described above as part of the RIC Self-Check. For connectivity, the RIC needs to support heartbeats or keep-alive signals to ensure northbound (SMO-RIC including other NB clients) and southbound connectivity (RIC-RAN Resources).
- SMO-RIC connectivity over O1 Netconf and O1 VES
- SMO-RIC connectivity over A1
- RIC-RAN Resources over E2
RIC connectivity resources
The RIC also checks heartbeat message come from RAN resources over the E2 interface.
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.