A1 is used for enabling the near-real time RIC (the term RIC will be used on this page) to manage policies configured for various hosted xAPPs. A1-related RIC Health-Check must ensure that: 1) the A1 interface is operational, and 2) policy changes (create, change, delete) can be processed.
For A1 interface health, the RIC Platform is already defining a self-check mechanism (see RIC Self-Check page) in which the A1 Mediator will support internal health-check requests (get_healthcheck request defined). And if there are any anomalies, an alarm will be generated via O1VES and the RIC alarm-list will be updated. So there is no need for the NB client issue a specific A1 health-check; NB client can just query for the alarm-list for A1 mediator health and other component/xAPP health that might hinder the policy configuration from being processed.
To verify whether policy configuration requests can be processed, it is recommended that a "HelloWorld" xAPP be defined that supports a unique "HelloWorld" policy to be created and deleted. So a NB client (Non-RTRIC in SMO or OTF) can verify RIC's policy processing health across the pathway from A1 Med, to RMR, to HelloWorld xAPP, back to A1 Mediator, and A1 Mediator in updating its policy list.
Here are the sequence of operations:
- Get current policy list (to ensure HelloWorld policy instance is not present)
- Send via A1 a HelloWorld policy instance creation request
- Upon receiving creation request successful, get current policy list again (to verify HelloWorld policy instance is present)
- Send via A1 a HelloWorld policy instance deletion request
- Upon successful response, get current policy list (to verify HelloWorld policy instance removal)
Figure 3 shows the corresponding sequence flow diagram.
<<insert sequence diagram and corresponding plantuml text>>