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 12 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




7. Deployment Considerations



8. Supporting Documents

A1-Adapter-ONAP-Ver6.pptx




  • No labels