What topic or problem does the demo address | solve?

The demo – which is collaoboration with ONF - presents an O-RAN Mobility Load Balancing use case in a 5G actual scenario, where the load of Radio Units (i.e.,the number of UEs attached to it) can be balanced by an application. Load balancing can be critical to achieve the needed performance requirements of UEs. An UE, User Equipment. is a commercial handset. 

SD-RAN for Beginners:

Imagine a packed lunchbox from a restaurant. For four people without further optimization and selection options for the user.

  • This is more or less how you have to imagine a classic radio access network (RAN) for end customers. A black box with fixed components and little scope for the network operator to influence the hard- and software.

It would be to your taste if you could change the ingredients of the lunchbox and also influence parameters such as the cooking level of a steak (rare to well done).

  • For a RAN, this means that greater flexibility is desired, and the RAN can be better adapted to the requirements of the network operators.

For the lunchbox, the price also changes if you could choose chicken instead of wagyu beef.

  • This is where Software Defined RAN comes into play. The most expensive software is not necessary everywhere and a mix of different open-source software can do the trick just as well.

In the end, the lunchbox customer still needs to know which ingredients go together and which don’t.

  • The tests for all components of a RAN is done by the i14y Lab and the results are made available to its partners. 
Bon appétit, test SD-RAN software in the i14y Lab
Bon appétit, test SD-RAN software in the i14y Lab
How does it solve the problem?

An application can oversee the status of the amount of User Equipments (UEs) connected to a Radio Unit (RU) and balance such load among the RUs. This is enabled via a closed control loop between the RAN equipment (i.e., O-RAN CU) and the near real time RAN Intelligent Controller (RIC) where the application performs its operations. 

How does it solve the problem?
The Dashboard | UEs connected to the RUs

Each color represents the User Equipments (UEs), and it also tells you how many UEs are connected to the Radio Units (RUs). Then the application monitores the amount of UEs connected to a RU and balances the load evenly among the RUs.

The Dashboard | UEs connected to the RUs
The Dashboard | Component of Cells

Three different cells are connected to the system
e2cell: Each of the Radio Units (RUs)
e2node: Each node includes one RUs and is connected to each of the RUs.
e2t: It controls all of the e2nodes and does the load balancing

The Dashboard | Component of Cells
The Dashboard | Node Controlls

The curve highlighted contains information from the RAN Intelligent Controller (RIC), more specificly a component called onos-topo. Among other features, onos-topo is responsible for storing a topological representation of RAN components in the form of entities and relationships, both having a parameter named kind.

The Dashboard | Node Controlls
Software requirement-RAN

The current setup is maintained inside i14y lab, visible by two indoor Radio Units (O-RU) and a cellphone. The other local RAN components (DU) are hosted in the lab/server room and on a local edge cloud site. Further key components (5G Core) run in a centralized Google Cloud instance. The components are executed via software interfaces, remotely accessible. All the needed equipment is already in place. 


Software requirement-RAN
Software Setting-RAN
  • Open-Radio Unit (O-RU): Converts digital signals into radio signals and vise versa
  • Open-Distrubution Unit(O-DU): Prepares the signals for transport over the O-RU, Calculates beam forming for a better connection.
  • Open-Control Unit (O-CUs): It can operate for multiple O-DUs and O-RUs, it contains Control plane and user plane
Software Setting-RAN
  • DU: Distribution Unit
  • RU: Radio Unit
  • CU-C: Control Unit – Customer Plane
  • CU-U: Control Unit – User Plane
  • Mobile Core CP: Mobile Core Control Plane
  • Non-RT RIC: Non - Real Time
  • nRT RIC: near Real Time
  • RRM: Radio Ressource Management
  • SON: Self Organizing Networks