Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

1. Background

The O-RAN architecture includes a Real-Time (RT) Radio Intelligent Controller (RIC) that is connected via A1 interface to Non-Real Time RIC function that resides in the Service Management and Orchestration (SMO) layer. The purpose of A1 interface is to enable Non-RT RIC function to provide policy-based guidance, AI/ML model management, and enrichment information to the near-RT RIC for RAN optimization.















2. High-Level Architecture and Use Cases

The overall Use Case Flow (DMAAP <--> SDNR/A1 REST Adapter <--> A1 Mediator) is as follows:

  1. Any ONAP or micro-service that wants to perform any policy management related activity will publish a DMAAP message, with appropriate request
  2. DMAAP listener will consume the DMAAP message and invoke RPC against A1 Adapter
  3. A1 Adapter, based on the received DMAAP message/RPC, will invoke corresponding REST API's against A1 Mediator in Near-RT RIC

The picture below depicts overall use case flow:




3. High-Level Design and Implementation Approach



For Frankfurt, only A1 Policy Management is supported.

The solution leverages existing CCSDK/SDNR code base and SDNC Dmaap Listener, and below depicts implementation approach:


4. North-bound RPC YANG Model

YANG model for north-bound RPC's for A1 Adapter can be found at: https://gerrit.onap.org/r/gitweb?p=ccsdk/features.git;a=blob;f=sdnr/northbound/a1Adapter/model/src/main/yang/A1-ADAPTER-API.yang;h=fb740cc2731ba8ab76977450b9bc31578bff9f16;hb=refs/heads/master

The below picture depicts the overall YANG tree.


5. DMAAP Message Format


Following are DMAAP message formats for topics A1-P and A1-P-RSP.

DMAAP Message Request (sent from ONAP or MS components):

Topic: A1-P 

{ 

    "body": { 

        "input": { 

            "CommonHeader": { 

                "TimeStamp": "2018-11-30T09:13:37.368Z", 

                "APIver": "1.0", 

                "RequestID": "9d2d790e-a5f0-11e8-98d0-529269fb1459", 

   "SubRequestID": "1", 

                "RequestTrack": {}, 

                "Flags": {} 

            }, 

            "Action": "getNearRT-RICs", 

            "Payload": {"input": {"dummy": "dummy"}} 

        }, 

        "version": "1.0", 

        "rpc-name": "getNearRT-RICs", 

        "correlation-id": "9d2d790e-a5f0-11e8-98d0-529269fb1459-1", 

        "type": "request" 

    } 

} 


DMAAP Message Response (sent from A1 Mediator with status response)

Topic: A1-P-RSP 

 

{ 

    "body": { 

        "output": { 

            "CommonHeader": { 

                "TimeStamp": "2018-09-10T07:10:05.614Z", 

                "APIver": "1.0", 

                "RequestID": "9d2d790e-a5f0-11e8-98d0-529269fb1459", 

                "SubRequestID": "1", 

                "RequestTrack": [], 

                "Flags": [] 

            }, 

            "Status": { 

                "Code": 200, 

                "Value": "SUCCESS" 

            }, 

            "Payload": "" 

        } 

    }, 

    "version": "1.0", 

    "rpc-name": "getNearRT-RICs", 

    "correlation-id": "9d2d790e-a5f0-11e8-98d0-529269fb1459-1", 

    "type": "response" 

} 

DMAAP message payload is aligned with YANG RPC Input parameters and is exactly the same as, when YANG model RPC input is rendered as a JSON object. See the above example, where DMAAP message is related to RPC "getNearRT-RICs". 

IMPORTANT: Please note that “input” key needs to be included in the payload. Escape characters ARE NOT to be INCLUDED.




6. A1 Mediator References

The A1 Mediator Open API's can be referenced at: https://gerrit.o-ran-sc.org/r/gitweb?p=ric-plt/a1.git;a=history;f=a1/openapi.yaml;h=2aa7a943eea23dff79a40917273c1bf43b1ae7d9;hb=445221bb8e531d77aad987b936b30d385521134f

A1 Adapter in Frankfurt is implemented against A1 Mediator OpenAPI version 1.0.0, and will be updated to support the latest A1 Mediator OpenAPI version 2.1.0. It is observed that there are no substantial material differences between API's for versions 1.0.0 and 2.1.0. 

Detailed documentation on A1 Mediator is available at: https://docs.o-ran-sc.org/projects/o-ran-sc-ric-plt-a1/en/latest/





7. Deployment Considerations


  • A1 Mediator/Real-RT RIC
  • ONAP (Non-RT RIC)
    • Use Frankfurt ONAP deployment
    • Configuration changes to the DG properties file required, if testing/deployment is done against A1 mediator other than described below
      • Properties file: /opt/onap/ccsdk/data/properties/a1-adapter-api-dg.properties
        • SSH into rancher node (NFS/rancher)
        • sudo su
        • kubectl get pods -n onap -o wide | grep sdnc
        • Execute the following command to all sdnc POD's to update properties file
          • kubectl exec -it dev-sdnc-sdnc-x bash (x=0, 1, 2, depending upon number of sdnc replicas in the setup)
        • Once in the docker, edit the properties file (/opt/onap/ccsdk/data/properties/a1-adapter-api-dg.properties)
        • Make following configuration changes per setup
          • Update IP address/port# for A1 Mediator (a.b.c.d:port# below)
            • near-rt-ric-id=a.b.c.d:port#

9. A1 Mediator Testing


The following depicts DMAAP to RPC to A1 Mediator REST API flow, and test cases are also mapped against this flow.


Mapping of flow to Test Cases described here:



Following is the current testing environment in the WIndriver Lab:


A1 Mediator deployed currently conforms to OpenAPI Version 1.0.0; and the OpenAPI latest version is 2.1.0. It is observed that there are no substantial material differences between API's for versions 1.0.0 and 2.1.0. 



10. To Do's


  • Perform testing and further development against full-blown RIC deployment that includes A1 mediator
  • Integrate ONAP/A1 Mediator with Near-RT deployment


11. Supporting Documents

A1-Adapter-ONAP-Ver6.pptx




  • No labels