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-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 "HelloWorld" policy type. New instances of this policy type can then be created and deleted 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 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)

Near-RT RIC angle:  RIC-46 - Getting issue details... STATUS

NONRTRIC angle: NONRTRIC-95 - Getting issue details... STATUS


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













  • No labels

14 Comments

  1. David Kinsey

    We need to discuss this flow as I don't see why the Test Driver is performing the A1 Policy Create instead of the Non-RT RIC.

    1. John Keeney

      Agree: The test driver should request NONRTRIC perform A1 messages, not contact the near-RT-RIC directly.

      1. John Ng

        John Keeney David and I discussed.  And the flows have been updated to reflect test driver request NONRTRIC to perform HelloWorld policy creations and deletions.  But test driver can still invoke near-RTRIC to retrieve policy list or status.  

        1. John Keeney

          Hi John Ng and David Kinsey

          I don't believe this is the case.

          All A1 operations should go through the NONRTRIC. For each near-RT-RIC there can only be one A1 northern termination in the SMO/NONRTRIC, so SMO/NONRTRIC/R-APP/Test functions that need to perform any A1 operations must do so via the NONRTRIC.

          Of course in many cases, initially, the NONRTRIC would simply mediate these operations directly through to the appropriate near-RT-RIC and then provide responses. All of the needed A1 functions in the current (06/Feb) version of the flows above will be exposed by the NONRTRIC NBI, so the test driver should use those rather than try contact the near-RT-RIC directly.

  2. David Kinsey

    I agree there is only one physical termination for the A1. However this should be with the controller that exchanges certificates with the device. This is in the SMO and not the non-RT RIC. I believe the Non-RT RIC should be used for All A1 policy management but is not the proxy for All A1 communications. I know there is a difference of opinion in this area and we should have time next week or at the face-to-face to see if we need to engage the ONAP architecture team in regards to multiple controllers talking, albeit over different interfaces, to a single device. Considerations in the original architectural principals would have to be revisited.


    Flows through the SMO Controller have not been show as it is internal to the SMO implementation. The Non-RT RIC has access to these as do other SMO components. Therefore the A1 are more from their logical endpoint. In the case of the Healthcheck the Test Driver accesses GET only functions (Get Policies and Get Policy/Status). We should have to build in Non-RT RIC interfaces for these functions as that is just added bulk to an implementation with no value add.

    1. John Keeney

      Hi again David Kinsey

      I'm not concerned (here) about flows within the SMO.
      I am concerned about the A1 messages being sent directly to the near-RT-RIC from a function other than the NONRTRIC in SMO.

      O-RAN WG2 and WG1 are very clear that NONRTRIC terminates and mediates all north-end A1 communications.
      You seem to be inferring here that the NONRTRIC is not the north-end termination for the A1 interface?
      You also seem to infer that there is a difference between "A1 policy management" messages and "All A1 communications" (about A1 policies?).
      (We have not yet started discussing about non-policy A1 messages).
      As NONRTRIC PTL I will aim to ensure compliance with WG2's requirements.


      On the other somewhat related topic about controller instances, yes I agree we need to re-discuss this with the ONAP architecture team, esp as the scope of A1 changes.

      1. David Kinsey

        Can you give me a contact in WG2 who advocates Non-RT RIC is sole the Mediator for all A1 traffic. I have not heard of this and it was not brought up in any conversations I have personally attended. I would like to understand the rationale behind creating such a limitation as part of the standards on the SMO implementation. In terms of termination we have agreed that A1"logically" terminates on the Non-RT RIC, but I have been very consistent that this is not the "physical" termination.

        There is a difference between Policy Management, and Policy Query. In the healthcheck I have been adamant that the Non-RT RIC be used for Policy Creation and Deletion as there could be more internalized steps to policy management that should not be replicated outside the Non-RT RIC. However developing a logical proxy for the physical proxy in order to query data is just not necessary.

  3. John Ng

    I updated the sequence flow diagram where the Test Driver (OTF) interfaces with 1) SMO's A1 Termination for get_policy_list and for get_policy_status, and 2) SMO's NONRTRIC for policy creation and deletion requests.

    1. John Keeney

      Hi John

      Re version 11Feb - I don't really understand what is the OAM-A1 function? How is it different from the NONRTRIC? The NONRTRIC is SMO A1 termination for all A1 operations.

      Thanks,

      John 

  4. John Keeney

    12 March: Added a new version of the sequence flow diagram that shows how the NONRTRIC parts are implemented..

    1. David Kinsey

      This does more than initially intended as it verifies that the Near-RT RIC, the SDN A1 Adapter, and the Non-RT RIC maintain consistency through the add and delete operations. There is a little more work on the OTF team for comparative evaluations, otherwise, I am OK with the approach.

    2. John Keeney

      Note there is a problem with the picture above (12 March version) - the bottom is cut off. This is an issue with how large PlantML definitions are rendered in confluence. I'll raised a ticket with LF and hopefully this will be sorted very quickly. If not I will upload a picture soon.

      1. John Keeney

        The issue has been fixed, but now the page takes too long to render when the PlantUML is re-parsed each time.
        I have uploaded the sequence diagram as a PNG picture, and included the PlantUML source as an attachment.

        Diagram: BronzeHealthCheck-A1-12Mar-JohnKeeney.plantUML.png

        PlantUML Source: BronzeHealthCheck-A1-12Mar-JohnKeeney.plantUML.txt

        1. David Kinsey

          Thanks John, this is more performant. I think we should adopt this method for future flows.