...
<<insert sequence diagram and plantuml syntax>>
| 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 E2SIM as “E2 Node” <<SIM>>
End box
=== 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
HC -> E2SIM : <<E2>> Generate Report
Note Left #lightsalmon : Support E2 Test Message Processing
E2SIM -> HC : <<E2>> REPORT
HC -> HC :
Note Right : Calculate report size response times as PM measures
HC -> O1TERM : E2 Alarm/Alert/Clear
O1TERM -> SMO_O1 : <<O1VES>> Alarm/Alert or Clear
HC -> O1TERM : Store all HC results 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.
...