Page History

The A1 (A1-AP) interface is used to support the Non-RealTime RIC creating and managing policies for near-RealTime RICs in the RAN.  The nearRT RICs can then use/pass these A1 policies/requests to hosted xAPPs for enforcement.

A1 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.  

The A1 RIC Health-Check flow supports the following requirements/Epics:

• Provide E2E Health-Check - Policy Changes via A1 interface
• Non-RT RIC support of A1 messages - Policy list queries
• RIC Support of A1 Policy Test Message Generation and Mediation
  • "HelloWorld" Test Policy Instance Creation and Deletion
  • xAPP process of "HelloWorld" Policy Creation and Deletion

For A1 interface health in the nearRT RIC, the nearRT RIC Platform is already defining a self-check mechanism (see RIC Self-Check page) in which the nearRT RIC 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.

For A1 interface health in the NONRTRIC A1 Policy Management Service constantly monitors the consistency of the policies in all nearRT RICs and maintains a consistent view. If Inconsistencies occur a warning is logged and the inconsistency is resolved according to the last know intents specified by the actor creating/deleting/updating policies.

To verify whether policy configuration requests can be processed, it is recommended that a "HelloWorld" xAPP be defined that supports a unique unique "HelloWorld" policy to policy type. New instances of this policy type can then 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.by the test driver. The creation, deletion, status and consistency of these instances can then be checked to ensure healthy operation. These checks would then confirm that the following functions operate as expected: 1) NONRTRIC A1 Policy Management Service, 2) the NONRTRIC A1 Adapter, 3) the A1 connections, 4) the nearRT RIC A1 Mediator,  and 5) the nearRT RIC "HelloWorld" xAPP.

Here is 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, check status, and get the current policy list again (to verify "HelloWorld" policy instance is present as expected)
• Send via A1 a "HelloWorld" policy instance deletion request
• Upon successful response, check status, and get the current policy list (to verify "HelloWorld" policy instance removal)

Figure below shows the corresponding sequence flow diagram.

@startuml
Autonumber
Skinparam sequenceArrowThickness 2
skinparam ParticipantPadding 5
skinparam BoxPadding 10

Box Personnel #lightblue
  Participant OTF as “Test Driver” <<INT>>
End box

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 xAPP as “HelloWorld xAPP” <<RICAPP>>
    Participant E2SIM as “E2 Node” <<SIM>>
End box

Note over SMO_O1 #lightsalmon
Provide E2E Healthcheck Test (Policy Changes via A1)
End note

=== A1 Heartbeat ==
Note over RPGE, A1TERM 
  A1 Mediator Health is addressed by RIC Self-Check Flows
End Note


=== A1 On-demand Policy Creation and Deletion ==
Note over SMO_O1 #lightsalmon
  Non-RT RIC support for A1 messages: A1 Query of Policies 
  Querying Policies can be requested by OTF/Test Driver as well
End Note

RPGE -> A1TERM : <<A1>> GET Policy List
A1TERM --> RPGE : <<A1>> Policy List


Note over SMO_O1 #lightsalmon
  Support A1 Policy Test Message Generation:
  "HelloWorld" Test Policy Instance Creation
End Note
OTF -> A1TERM : <<A1>> HelloWorld Policy Creation Request
A1TERM -> xAPP : HelloWorld Policy Creation
Note Left #lightsalmon
  Support A1 Policy Test Message Mediation
End Note
xAPP -> A1TERM : Policy Status Change
Note Left #lightsalmon
    Support A1 Policy Test Message Processing:
    xAPPs process "HelloWorld" Policy Creation
End Note
A1TERM --> OTF : <<A1>> Policy Creation Completed
xAPP -> A1TERM : Policy Status Change
A1TERM ->> RPGE : <<A1>> Enforcement Change Notification

OTF -> A1TERM : <<A1>> GET Policy List
A1TERM --> OTF : <<A1>> Policy List
Note right 
  Send Policy List showing HelloWorld instance created
End Note


Note over SMO_O1 #lightsalmon
  Support A1 Policy Test Message Generation:
  "HelloWorld" Test Policy Deletion
End Note
OTF -> A1TERM : <<A1>> HelloWorld Policy Deletion Request


A1TERM -> xAPP : HelloWorld Policy Deletion
xAPP -> A1TERM : Policy Status Change
A1TERM --> OTF : <<A1>> Policy Deletion Completed

A1TERM ->> RPGE : <<A1>> Enforcement Change Notification
OTF -> A1TERM : <<A1>> GET Policy List 
A1TERM --> OTF : <<A1>> Policy List 
Note right 
  Send Policy List showing HelloWorld deleted
End Note






@enduml

Image Removed

Near-RT RIC angle: 

NONRTRIC angle:

Figure below shows the corresponding sequence flow diagram.

• Please click on the image for a larger version - or here
• The PlantUML source is available here

Image AddedPlantuml file for A1_HealthCheck Sequence Diagram