A1 Termination
On top of existing OSC A1 simulator codebase, a module named A1 Terminator has added. It does interaction with the A1-PMS and the RAN-App. It acts a gateway between the RAN-Simulator and the SDNR.
A1 Policy are redirected as Kafka messages to a configured Kafka Topic to RAN-App, then responses from the RAN-App are collected from another configured Kafka Topic. This provides a Kafka-based request-response abstraction for adding supplemental simulator behavior for particular A1 Policy Types. After a request message is sent, a response message will be expected within some configurable timeout interval (default: 30 sec). The topics to be used for particular A1 Policy Types is configured using a JSON map.
The Kafka message dispatcher (Payload Dispatcher) exposes a ‘Kafka Message Dispatcher’ REST API. This internal API is invoked directly by the A1 Terminator (A1 Simulator), and is not intended to be used by any other client.
You can please find the design of A1 Termination flow:
To start the A1 terminator please use below commands.
Build and start the simulator containers: STD_1.1.3 and OSC_2.1.0, using: ./build_and_start.sh duplicate-check|ignore-duplicate Build and start the simulator container version STD_2.0.0, using two alternatives: ext-srv or kafka-srv. However, both can not be used at the same time to start A1 sim. In order to start with ext-srv: In order to start with kafka-srv: |
|---|
We will add the A1 ANR policy payload which A1 terminator receives it from the A1-PMS, and will add the sample output which A1 Terminator will be pushing.
Since Kafka Message Dispatcher is a specific implementation of an External Server (calloutserver), which further redirects A1 Policy operations to a Kafka message topic, A1 Terminator could be started only with kafka-srv arguments.
Ran-App
To support A1 interface in SON use case we have added RAN-App( ANR use case). RAN-App simulates the xApp behavior and to simulate the xApp E2 interface functionality we are using NETCONF protocol. Currently we have developed RAN-App for the ANR use case.
RAN App receives the ANR A1 policy data from the A1 Terminator and performs the business logic over it and triggers the Neighbor change request towards the requested gNodeB node.
RAN-App uses Netconf protocol to interact with the gNodeB for triggering the ANR configuration.
We will add the sample payload which RAN-App will receive from the A1 Terminator and the sample output which RAN App will send towards the CU/DU.
Sample Input Payload for Ran-App:
| {"action":"UpdatePolicy","payload":{"PNFName":"cucpserver2","PLMNID":"ran-1","CellID":"15549","neighbours":[{"PNFName":"cucpserver2","PLMNID":"ran-1","CellID":"14427","ho-kpi1":100},{"PNFName":"cucpserver2","PLMNID":"ran-1","CellID":"15548","ho-kpi1":90}]},"policy_type_id":"ANR","policy_id":"pi3"} |
|---|
Enhancements to Ran-Sim Controller
RAN-Simulator is enhanced to support the RAN-App functionality. RAN-App crates a WebSocket connection with the RAN Simulator for interacting with the database and to interact with the CU/DU. RAN-App asks RAN-Simulator for the CU/DU existing configuration which in-turn RAN Simulator fetch it from MariaDB and gives back to the RAN-App.
Same way RAN-App sends the newly generated config payload towards the RAN simulator and RAN simulator in turn sends it towards the requested CU/DU using the NETCONF.