Experiment with Hardware USRP Radio Units and a bare metal server

Prerequisites

  • You have a Slices account

  • You have successfully followed the previous tutorials

  • You have a basic understanding of kubernetes and containers

  • You have a good understanding of the 5G architecture

  • You have a good understanding of radio units (e.g., USRP).

  • You have a good understanding of OpenAirInterface and how to configure radio

The previous experiment used a simulated radio network. In this tutorial, we will work with a real radio network, utilizing a hardware radio unit and User Equipment (UE). To accomplish this, we will deploy the core network in the central SLICES-RI Kubernetes cluster, while the Radio Access Network (RAN) will operate on bare-metal resources.

For the hardware, we will utilize the R2LAB anechoic chamber, which provides both Radio Units (RUs) and User Equipment (UEs). In this setup, the N320 USRP from R2LAB will function as the radio unit of the gNB, while the N300 USRP will serve as the UE connecting to the 5G network. These devices will be referred to as n320 (for the radio unit) and n300 (for the UE). Additionally, a bare-metal server is required to act as the gNB and another one for the UE, which will be connected to the radio units.

Since gNBs linked to real radio units demand high-performance networking and computing resources, we will use sopnode-f1 and sopnode-f2.

This experiment connects:

  • the N320 USRP from the R2LAB anechoic chamber to the bare-metal fronthaul sopnode-f1 node, located in the SLICES-RI SophiaNode datacenter, which serves as a gNB. The gNB is linked to the 5G core deployed in the central hub’s Kubernetes cluster.

  • the N300 USRP from the R2LAB anechoic chamber to the bare-metal sopnode-f2, located in the SLICES-RI SophiaNode datacenter, which serves as UE.

We use standard-2-1 as a deployement node.

        graph TD
  centralhub <--> gnb
  gnb <--> n320
  ue <--> n300
  n300 <-.-> n320
  deploy -.-|controls| sopnode-f1
  deploy -.-|controls| sopnode-f2

  subgraph Slices resources

    subgraph Deployement node
    deploy[standard-2-1]
    end
    
    subgraph "centralhub k8s cluster"
            centralhub(5G core)
    end

    subgraph "Sophia Node"
        subgraph "Datacenter"
            subgraph "sopnode-f1"
                gnb(gnb)
            end
            subgraph "sopnode-f2"
                ue(UE)
            end
        end

        subgraph "Anechoic chamber"
            n320(n320)
            n300(n300)
        end
    end
  end

The UE is configured as follows, which is one of the default UE installed in OAI database; if you don’t use the core we provide by default, make sure to configure yours accordingly:

  • imsi: 001010000000100

  • key: fec86ba6eb707ed08905757b1bb44b8f

  • opc: C42449363BBAD02B66D16BC975D77CC1

  • dnn: oai

  • nssai_sst: 1

  • nssai_sd: 16777215

As in the previous tutorial, go to the Configure Experiment section of the Post-5G Blueprint Service, as in step 1 configure the NRF Load Balancer IP and the Multus network prefix based on the prefix you receive with the command:

post5g experiment prefix my_experiment

We do not use the kubernetes cluster to deploy the RAN and the UE, so deactivate RAN and UE by ensuring that GCN RAN Present and GCN UE Present are set to false in the assistant.

Specify standard-2-1 as deployement node, and add sopnode-f1 an sopnode-f2 as Resources (not r2lab).

Instead, the RAN will be configured and run as part of your custom experiment. We provide a simple scenario in usrp_baremetal. To use this implementation, set the experiment URL to be https://gitlab.inria.fr/dsaucez/5g_test/-/archive/usrp_exp/5g_test-usrp_exp.tar.gz.

Once you have configured correctly the experiment with the assistant, make sure you generate the code by clicking on the Generate Experiment Code button (see step 2).

The next step is to reserve the necessary resources. Similar to step 3, book a time slot through the POS Calendar section of the Post-5G Blueprint Service and choose the resources r2lab, standard-2-1, sopnode-f1, and sopnode-f2. Be sure to select the r2lab, as this ensures access to the radio hardware available in the anechoic chamber.

When your time slot begins, you can execute the experiment. Connect to the pos Webshell section of the Post-5G Blueprint Service and from the webshell retrieve the experiment information, just as you did in step 4.

post5g experiment get my_experiment

Before starting the experiment, ensure that the radio resources in R2LAB are powered on. You can control them from the pos Webshell using the command post5g nodes [start|stop] {<node_name>}, where <node_name> is the name of the resource you want to turn on or off. In this case, we’ll start the Radio Units with the following commands:

post5g nodes start n300
post5g nodes start n320

After that, you can launch the experiment using the usual method from the pos Webshell.

post5g experiment launch my_experiment

This will deploy the 5G core network on the SLICES-RI Kubernetes cluster, set up a bare-metal gNB on the sopnode-f1 server, and connect the N320 USRP to this gNB. It will then setup the UE on sopnode-f2 and connect the N300 USRP to the UE.

When the UE is connected to the RAN, then the experiment will do and ping as in our previous example.

To access the data, visit the MRS section of the Post-5G Blueprint Service, enter the Dataset ID, and click the Download Data button. In the downloaded dataset, go to the standard-2-1 folder and open the <date>_xp.sh.stdout file. It contains the compilation details and the output from the gNB console, similar to the following example.

Feel free to check xp.sh for the implementation details.