RAN-Sim

Architecture

Existing architecture is leveraged to support the network slicing in Guilin release. It has the below predominant elements.

1. Netconf Servers
2. Ransim Controller
3. Ransim DB

Netconf Servers

1. Each network function in the RAN network is realized by a Netconf server. The network functions are NearRTRIC, gNBCUCPFunction, gNBCUUPFunction, gNBDUFunction. RAN Network’s YANG model is attached.

 yang_ran-network@2020-08-06.yang

2.  RAN Network’s topology is maintained in ransim DB (mariaDB implementation). Based on the topology defined, netconf servers are spawned. Current topology supports, 2 NearRTRIC, 2 gNBCUCPFunction, 2 gNBCUUPFunction,  6 gNBDUFunction ans 30 cells. It is modifiable.

3. When a netconf server is spawned, it opens a websocket connection to Ransim controller and communicate via websocket messages.

4. Initial configuration for the netconf servers is simulated from ransim controller. Once the netconfserver is configured, it will be mounted to SDN-R.

5. Simultaneously, 12 netconf servers should be at running condition to simulate the ran network that contains 2 NearRT RICs, 2 gNBCUCPs, 2 gNBCUUPs and 6 gNBDUs.

Ransim Controller

1.Ransim controller acts as the simulator for the Honeycomb netconf servers.

2. Netconf servers ping Ransim Controller with the IP and port.

3. Once the websocket connection is received from the netconf agent, Ransim controller identifies the netconf agent as the specific network function (NEarRTRIC, CUCP, CUUP, DU) based on the topology and maintains the active sessions.

4. It sends the initial configuration to netconf servers via websocket messages.

5. It also takes care of distribution of NearRTRIC configuration to the cells associated with DU  function

6. PM data for closed loop and intelligent slicing usecases are generated by Ransim controller.

Ransim DB

1. MariaDB is used to implement ransim DB.

2. Ransim DB houses the below details:

• Network functions’ topology and Initial configuration details
• Slice configuration of network functions
• RRMPolicy Details
• Tracking Area to Cell mapping

Network Slicing impacts

When a request is received from SDN-R to Netconf servers, slice configuration and RRM policy updates are done in the yang structures and websocket message is sent to ransim controller to store the details in DB.

REST APIs are exposed in Ransim Controller to Start/Stop the RAN network slice simulation.

Start RAN network slice simulation API: 

1. It will populate the network function server Id based on the topology that need to be assigned to netconf server when it is spawned. 
2. Read the dump json file which will preload CUCP config data (PLMNInfo of each cell) in to ransimDB. 
3. Prepare unassignedServerIds map with RTRIC network function Id, when a netconf server is spawned the server Id from unassignedServerIds map will be assigned and it will load respective cellList from respective entity into unassignedCellIds map. When the subsequent netconf servers are spawned the server Id will be assigned from unassignedCellIds map. 
4. The client will seed the initial configuration of read/write data for each Node and initial configuration of read/only data for each node will be send as a websocket message to netconf server.  

SDN-R - Ransim interface - Restconf APIs

SDN-R interacts with mounted netconf agents by restconf APIs to configure the slices. Complete list of APIs are found at https://gerrit.onap.org/r/gitweb?p=ccsdk/distribution.git;a=blob;f=odlsli/src/main/properties/ran-slice-api-dg.properties;h=74aaf57b94abd45957145122b689d7d1abf43e3b;hb=HEAD

Few references:

1. To update PLMNInfo for NRCEllDUs

/restconf/config/network-topology:network-topology/topology/topology-netconf/node/{mountName}/yang-ext:mount/ran-network:ran-network/NearRTRIC/{idNearRTRIC}/GNBDUFunction/{idGNBDUFunction}/NRCellDU/{idNRCellDU}/attributes/pLMNInfoList/{mcc}/{mnc}

2. To read the PLMNInfo of NRCellDUs

/restconf/config/network-topology:network-topology/topology/topology-netconf/node/{mountName}/yang-ext:mount/ran-network:ran-network/NearRTRIC/{idNearRTRIC}/GNBDUFunction/{idGNBDUFunction}/NRCellDU/{idNRCellDU}/attributes/pLMNInfoList/{mcc}/{mnc}

3. To update RRMPolicy for NRCellDUs

/restconf/config/network-topology:network-topology/topology/topology-netconf/node/{mountName}/yang-ext:mount/ran-network:ran-network/NearRTRIC/{idNearRTRIC}/GNBDUFunction/{idGNBDUFunction}/NRCellDU/{idNRCellDU}/attributes/RRMPolicyRatio/{id}

Closed Loop & Intelligent Slicing impacts

PM data is generated for both the closed loop and intelligent slicing usecases.

PM data simulated in ran sim controller is sent to Netconf server via websocket message. It is parsed, converted to binary data and compressed in Honeycomb. This file is stored at SFTP in compressed form, later it will be read by DFC. 

Below REST APIs are exposed for PM data generation.

1. Start/Stop generate PM data of the simulated CUCP netconf server - Intelligent slicing
2. Start/Stop generate PM data of the simulated DU netconf server – Closed Loop

Closed Loop - PM data generation

1. Closed loop PM data is collected for gNBDUs per cell per s-NSSAI for two RICs.
2. Measurement types considered are SM.PrbUsedDl and SM.PrbUsedUL and are measured in terms of PRBs. Each cell is assumed to have 500 PRBs and the PRB usage is computed at a ratio randomly such that PRB usage is maximum for one of the RICs and minimum for the other.
3. The more the PRB usage, the corresponding RIC will need to support more throughput.
4. When the closed loop is triggered, Slice analysis MS will analyze the computed data and will determine the throughput to be split across different RICs.
5. RIC level configurations (dlThptPerSlice, ulThptPerSlice) are sent from Slice analysis MS to SDN-R and the configuration is distributed equally among the DU cells by the Ransim.

Intelligent Slicing - PM data generation

1. PM data is collected for gNBCUCPFunctions per cell per NSSAI.
2. PMs to be collected are Number of PDU Sessions requested to setup, Number of PDU Sessions successfully setup and Number of PDU Sessions failed to setup
3. Based on time interval, PM data will be generated. 
4. No of total no of PDU sessions varies based on peak hour and tracking area cell mapping. 
5. PM data applies a logic on config data, for every NSSAI 
   noOfPDUSessionsRequested = maxNoOfConnections * random metricValue 
   noOFPDUSessionsSuccess = noOfPDUSessionsRequested * (0.75-0.90) (assuming 75% - 90% success rates) 
   noOFPDUSessionsFailed = noOfPDUSessionsRequested-noOFPDUSessionsSuccess

   TAs at Peak hour(say TA1&TA3) – Itwill have very high traffic (say, > 1.2 times of maxConns for each of those cells in those TAs, so a random value between 100% - 140%) other TAs cells will have low traffic say random value between 30% -60%. 
   Peak hour– It will have high traffic (a random value between 80% - 110%) 
   Normal hours– It will have low traffic ( random value between 30% - 70%) 

6. Generated PM data is analyzed by ML based microservice and it results the cell level configuration (maxNumberOfConns) for CU Cells.

VES Notification - Fileready event

File ready event is triggered from Honeycomb agent to VES collector, once the PM data is generated and the data is stored as a file in SFTP. This event contains SFTP location of the PM data file and other details. PM data file name is aligned with 3GPP specification 32.432-5.1.2