1. Architecture

The high-level architecture of the RAN simulator and its interface to ONAP is shown below.

2. Netconf server

Honeycomb simulator shall be used to simulate the Netconf server. Suitable extensions will be made for it to communicate with the RANSim Controller.
Each netconf server will run as standalone process or in a Docker container
The netconf servers will be spawned by RANSim Controller based on the topology specified.
Python scripts and client will seed the initial configuration for each Node.
Each netconf server can send a mount request to SDN-R when it is spawned.
ran-neighbor-list update notification will be sent by netconf server to SDN-R based on the trigger from RANSim Controller.
The netconf server will be able to accept phy-cell-id update trigger from SDN-R and forward same to RANSim Controller.
Maximum number of cells connected to a netconf server is configurable.

This is a Springboot based micro-service
RAN topology of ~2000 cells to be simulated is defined into a Config DB.
RAN Simulator spawns the netconf servers based on this topology
Exposes following rest APIs to:
1. Retrieve the current topology
2. Update phy-cell-id of a cell to simulate collision or confusion
3. Bring down a cell or create a new cell
4. Receive the new phy-cell-id set by SDN-R (after PCI optimization, or otherwise)
5. Start/Stop the network simulation
MariaDB will be used as the Config DB to store the topology
Robot scripts will drive the complete test sequences
Web GUI will show the current topology, phy-cell-id collision/confusions, ran-neighbor-list changes, updates from SDN-R, etc.
Pictorial representation will be a stretch goal