1. Architecture

The updated architecture of the RAN-Simulator for ONAP Dublin is illustrated below.

2. Netconf server

The Netconf server functionality implemented for the Casablanca PoC shall be enhanced for Dublin. For completeness, the entire functionality available in Dublin is summarized below (including the implementation done for Casablanca).

2.1. Introduction

• Honeycomb simulator shall be used to simulate the Netconf server. Necessary extensions have been made for it to communicate with the RAN-Sim Controller.
• Each Netconf server will run as standalone process or in a Docker container.
• The Netconf servers will be spawned by RAN-Sim 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.
• Maximum number of cells connected to a Netconf server is configurable (currently configured as 16).

2.2. Handle inputs from RAN-Sim controller

• Netconf server sends a nbrlist-change notification to SDN-R based on the trigger from RAN-Sim Controller, when a cell's neighbor list is updated.
• Netconf server sends a netconf-config-change notification to SDN-R when triggered by RAN-Sim Controller, when a cell's PCI value is updated.
• Netconf server sends an alarm message to VES Collector for collision/confusion (and clearing) when triggered by the RAN-Sim Controller.
• Netconf server sends PM data to VES Collector when triggered by the RAN-Sim Controller.
• PM and FM data formats are provided below.

2.3. Handle inputs from SDN-R

• Netconf server accepts phy-cell-id update trigger from SDN-R and forwards itto RAN-Sim Controller.
• Netconf server accepts neighbor list (HO allowed) update trigger from SDN-R and forwards it to RAN-Sim Controller.

3. RANSim Controller

• This is a Springboot based micro-service.
• RAN topology of ~2000 cells to be simulated is defined into a configuration DB.
• RAN Simulator spawns the netconf servers based on this topology.
• Exposes following rest APIs for GUI to:
  1. Retrieve the current topology
  2. Update phy-cell-id of a cell to simulate collision or confusion
  3. Update neighbor list to simulate collision or confusion (in the table view)
  4. Receive the new phy-cell-id set by SDN-R (after PCI optimization, or otherwise)
  5. Start/Stop the network simulation
  6. Start/stop generation of PM data for the network. Flexibility to specify which cell(s) should have poor/bad performance.
• MariaDB will be used as the configuration DB to store the topology
• Web GUI will show the current topology, phy-cell-id collision/confusions (using different color codes), ran-neighbor-list.
• Basic pictorial representation will be provided, improvements will be a stretch goal.

4. RAN-Sim GUI

4.1. Assumptions

• For initial setup, an input file containing foll. info shall be used
  •  Cell Id
  • PNF name (though this has really no relevance to the GUI)
  • Cell position = {0,1,2,3} 0=>no sectors, 1-3 denotes sectors
  • PCI value
  • (x,y) = mapping to a co-ordinate on the canvas from (lat,long)
  • Neighbor list (ordered list of (cell id, PCI))
• Canvas view and ‘on-click’ views possible
• Editable contents: neighbor list (in graphical view), PCI value (in graphical view)
• Maximum 3 cells in a single location
• All cells are assumed to be of same size, i.e., path loss, etc. are not considered.
• Option provided for user to pause before seeing the changed PCI values.
• Only 1 iteration of PCI/neighbor list change will be performed.

4.2. Illustration of GUI

4.2.1. Canvas view when a neighbor list of a cell is updated

4.2.2. Canvas view when a neighbor list of a second cell is updated (OOF is not yet triggered)

4.2.3. Details of a particular cell (on click view)