Allocate OTA lab radios with associated compute nodes with gnuradio installed.

The OTA lab has the following resources

• Four NI X310 SDRs

These are paired with either d430 or d740 compute nodes (profile parameter) when allocated by this profile, connected by 10G Ethernet.

• Four i7 NUC comput nodes with USB3-attached radios
  • One NI B210 per node
  • One Quectel RM500Q-GL 5G modem per node

See the following diagram for the lab layout: OTA Lab Layout

Be sure to select at least one node/radio, or nothing will be allocated!

If you plan to transmit anything, you will need to declare the frequency range you plan to use for transmission via the parameters in this profile. If you transmit without declaring frequencies, this will be detected, and your experiment may be shut down. Please make sure the frequencies you declare are compatible with the radios you specify for allocation.

This profile creates a Kubernetes cluster and installs the O-RAN SC Near-RT RIC (and optionally, the ONF SD-RAN RIC) and xApps. When you click the Instantiate button, you'll be presented with a list of parameters that you can change to configure your O-RAN and Kubernetes deployments. Before creating any experiments, read the Instructions, and the parameter documentation.

OAI 5G using the POWDER Indoor OTA Lab

This profile instantiates an experiment for testing OAI 5G with COTS UEs in standalone mode using resources in the POWDER indoor over-the-air (OTA) lab. The indoor OTA lab includes:

• 4x NI X310 SDRs, each with a UBX-160 daughter card occupying channel 0. The TX/RX and RX2 ports on this channel are connected to broadband antennas. The SDRs are connected via fiber to near-edge compute resources.
• 4x Intel NUC compute nodes, each equipped with a Quectel RM500Q-GL 5G module that has been provisioned with a SIM card. The NUCs are also equipped with NI B210 SDRs, but they are not the focus of this profile.

You can find a diagram of the lab layout here: OTA Lab Diagram

The following will be deployed:

• Server-class compute node (d430) with a Docker-based OAI 5G Core Network
• Server-class compute node (d740) with OAI 5G gNodeB (fiber connection to 5GCN and an X310)
• One to four Intel NUC compute nodes, each with a 5G module and supporting tools

Note: This profile currently requires the use of the 3550-3600 MHz spectrum range and you need an approved reservation for this spectrum in order to use it. It's also strongly recommended that you include the following necessary resources in your reservation to gaurantee their availability at the time of your experiment:

• A d430 compute node to host the core network
• A d740 compute node for the gNodeB
• One of the four indoor OTA X310s
• All four indoor OTA NUCs

Bleeding-edge Software Caveats!

You may see warnings, errors, crashes, etc, when running the OAI gNodeB soft modem. The COTS modules may sometimes fail to attach. Please subscribe to the OAI user or developer mailing lists to monitor and ask questions about the current status of OAI 5G: https://gitlab.eurecom.fr/oai/openairinterface5g/-/wikis/MailingList.

This profile creates a node and attaches it to the shared vlan for the Powder Ceph cluster.

This profile instantiates a d840 machine connected to a Skylark FAROS massive MIMO system comprised of a FAROS hub, a Faros massive MIMO Base Station, and a set of Iris UEs (clients). The PC boots with Ubuntu 20.04 and includes a MATLAB installation that could be used to run experiments on FAROS with RENEWLab demos. For more information on RENEWLab, see RENEW documentation page

This profile allows the allocation of resources for over-the-air operation in POWDERs indoor over-the-air (OTA) lab.

A map of the lab's layout is here: OTA Lab Diagram

The OTA Lab has a number of X310 SDRs connected to two broadband antennas; one on the TX/RX port, and the other on RX2 port of channel 0. Each X310 is paired with a compute node (by default a Dell d430).

The OTA Lab also has a number of B210s SDRs paired with an Intel NUC small form factor compute node. These B210s are connected to broadband antennas, one on each of the "channel A" TX/RX and RX2 ports.

This profile uses a disk image with UHD pre-installed and clones/builds/installs srsRAN 22.04. The source code can be found at /var/tmp/srsran on each node after the startup scripts for the experiment have finished.

Resources needed to realize a basic srsRAN setup consisting of a UE, an eNodeB and an EPC core network:

• Spectrum for LTE FDD opperation (uplink and downlink).
• A "nuc+b210" OTA lab compute/SDR pair (This will run the UE side.)
• An "x310" OTA Lab SDR. (This will be the radio side of the eNodeB.)
• A "d740" or "d430" compute node. (This will run both the eNodeB software and the EPC software.)

srsRAN S1 Handover w/ Open5GS

This profile allocates resources in a controlled RF environment for experimenting with LTE handover. It deploys srsRAN on three nodes, each consisting of a NUC5300 compute node and a B210 SDR, in our RF attenuator matrix. One node serves as the UE, while the other two serve as "neighboring" eNBs. Since the srsRAN EPC does not support S1 handover, the profile deploys Open5GS on a node outside of the controlled RF environment and sets up LAN connections between this node and both eNB nodes. A command line tool is provided that allows you to change the amount of attenuation on the paths between the UE and both eNBs in order to simulate mobility and trigger S1 handover events.

This profile is intended for capturing WiMatch/Shout dependencies and for reproducing experiments as conducted for the CNERT 2021 workshop paper.

Allocate some number of X310 radios (+ compute) for doing measurements. Can allocate both CBAND and Cellular band X310 Radios as well as FE NUC+B210 resources.

This profile allocates two bare metal nodes and connects them together via two Dell or Mellanox switches with layer1 links.

Start X11 VNC on a node.

This profile creates a Kubernetes cluster with Kubespray. When you click the Instantiate button, you'll be presented with a list of parameters that you can change to control what your Kubernetes cluster will look like; read the parameter documentation on that page (or in the Instructions).

This profile provides a highly-configurable OpenStack instance with a controller and one or more compute nodes (potentially at multiple Cloudlab sites) (and optionally a network manager node, in a split configuration). This profile runs x86, arm64, and POWER8 (Queens and up) nodes. It sets up OpenStack Zed (Ubuntu 22.04), Xena, Wallaby, Victoria, Ussuri (Ubuntu 20.04, python3), Train, Stein (Ubuntu 18.04, python3), Rocky, Queens (Ubuntu 18.04, python2), Pike, Ocata, Newton, or Mitaka (Ubuntu 16.04, python2) (Liberty on 15.10, Kilo on 15.04, and Juno on 14.10, python2, deprecated) according to your choice, and configures all OpenStack services, pulls in some VM disk images, and creates basic networks accessible via floating IPs. You'll be able to create instances and access them over the Internet in just a few minutes. When you click the Instantiate button, you'll be presented with a list of parameters that you can change to control what your OpenStack instance will look like; carefully read the parameter documentation on that page (or in the Instructions) to understand the various features available to you.

An example of constructing a profile with a single Xen VM with a routable IP address.

An example of constructing a profile with a single Xen VM, running on a shared VM host, with a routable IP address.

An example of constructing a profile with two VMs connected by a LAN.

This profile demonstrates how to add some extra local disk space on your node. In general nodes have much more disk space then what you see with df when you log in. That extra space is in unallocated partitions or additional disk drives. An ephemeral blockstore is how you ask for some of that space to be allocated and mounted as a temporary filesystem (temporary means it will be lost when you terminate your experiment).

An example of constructing a profile with install and execute services.

An example of how to generate a random per experiment password that is displayed to the user in the instructions below, and can be accessed on nodes in your experiment. This avoids having to use a well known password.

An example demonstrating how to control the installation of an ssh private and public pair for the root user such that root can ssh without a password to other nodes in your experiment.

This profile demonstrates a parameterized profile that allows you to select one of several standard OS images for your nodes. When you instantiate this profile, you will be asked to select the OS via a drop down menu.

An example of constructing a profile with a single raw PC, that is set to run a specific operating system image (Ubuntu). It can be instantiated on any cluster, this particular Ubuntu image is available on all clusters.

An example of constructing a profile that requests a specific raw PC. It can be instantiated only on the cluster where that pc is located; the node will boot the default operating system, which is typically a recent version of Ubuntu.