---
title: 'VOTA: Virtualized Over-The-Air Testbed'
url: https://www.emergentmind.com/topics/vota
type: topic
---

# VOTA: Virtualized Over-The-Air Testbed

VOTA, short for **Virtualized Over-The-Air**, is an open-source, software-only testbed scaling method for wireless experimentation that uses real-time virtualization and frequency tuning to maximize parallel experiments while controlling interference in shared 6G-RAN infrastructure. It is positioned against the conventional trade-off in testbed sharing between serial access and degraded fidelity under concurrent use. In the reported demonstration, two interference-sensitive use cases—**MIMO iDFT/DFT Offloading** and **O-RAN DoS Attack**—ran side-by-side on a 32-core host and achieved **dedicated-like** results while enabling **2.67$\times$** more sharing opportunities [2509.00130].

## 1. Research setting and motivation

VOTA is situated in the broader problem of **testbed sharing**, where multiple researchers concurrently develop independent use cases on the same wireless testbed. The central drawback identified for this practice is **experimental inconvenience**: experiments must either be delayed or executed under compute and RF interference that harms fidelity. The method is motivated by the observation that, in shared wireless research infrastructure, the practical bottleneck is often the **radio hardware**—not host compute—because SDRs and embedded UEs are expensive, scarce, and frequently locked to a single user even when compute remains underutilized [2509.00130].

The approach is framed against two common sharing patterns. In one, radio equipment is shared ad hoc while compute nodes remain dedicated, which introduces recurrent setup overhead. In the other, radios are isolated through **Faraday cages** or cable partitions, often with synthetic channel emulation, which constrains flexibility and does not capture real-world OTA effects such as MIMO or positioning. The summary also contrasts VOTA with **Colosseum**, which partitions nodes with Linux containers but focuses on channel emulation and post-prototyping rather than true OTA multiplexing during active development [2509.00130].

A plausible implication is that VOTA addresses not merely scheduler-level fairness, but the more specific problem of preserving **OTA realism** under concurrent execution. This distinguishes it from testbed orchestration systems that isolate software stacks yet still serialize RF usage.

## 2. Architectural model

The core design of VOTA multiplexes both **compute slices** and **spectrum slices** over a shared pool of radios. Each experiment receives an isolated execution environment and a distinct RF sub-band. The implementation uses **LXC/LXD containers** with hardware passthrough rather than VMs, on the grounds that containers share the host kernel and use **cgroups** and **namespaces** for process and resource isolation with near-zero overhead for real-time workloads [2509.00130].

Each experiment is placed in its own container and can attach or detach radios and UEs dynamically via LXD device passthrough. Isolation is organized through **LXD projects**, with per-project control of CPU cores, VLANs, and storage pools. For compute-critical radio pipelines, **gNB SDR-write threads** are pinned to dedicated cores using `taskset` and `nice`, and CPU governors are set to `performance`. The system therefore treats radio experiments as hard real-time tenants rather than best-effort processes [2509.00130].

On the RF side, VOTA uses **frequency tuning** to assign each experiment a unique portion of the available spectrum. The configuration is applied through SDR and UE parameters including `dl_absoluteFrequencyPointA`, `absoluteFrequencySSB`, and UE-side `AT+QNWPREFCFG`. The summary states that non-overlapping, locally unused sub-bands are selected within regulatory limits, and transmission power is attenuated so that emissions do not leave the lab [2509.00130].

This architecture makes “virtualized over-the-air” literal: the virtualization boundary covers host compute and device assignment, while RF coexistence is enforced through spectral separation instead of physical shielding.

## 3. Isolation and interference control

VOTA’s isolation model has two coupled components: **real-time compute isolation** and **OTA spectrum isolation**. Compute contention is controlled by assigning specific CPU cores to each container through **cpusets** and by pinning latency-sensitive radio threads to fixed cores. The summary reports that this eliminates late packet errors and prevents background tasks or neighboring containers from inducing SDR overruns [2509.00130].

RF interference is controlled by operating each experiment on a non-overlapping sub-band. Because the sub-bands are distinct and the system runs at legal, locally attenuated power, the method avoids the need for hardware RF shielding or cable-based separation. The reported result is that even under aggressive scenarios, including an O-RAN denial-of-service workload, one experiment did not spill interference into the other in either compute or RF terms [2509.00130].

The paper summary expresses VOTA’s scaling rule as

$$
N_{\text{VOTA}} = \left\lfloor \frac{\text{Total Host Cores}}{\text{Max Cores needed by any experiment}} \right\rfloor
$$

and gives the example

$$
32 / 12 \approx 2.67
$$

for a 32-core host and a most demanding experiment requiring 12 cores [2509.00130].

This suggests that VOTA’s capacity model is intentionally conservative: safe concurrency is bounded by the heaviest real-time workload, not by average CPU utilization. In practice, the method prioritizes deterministic schedulability and RF non-interference over maximal statistical multiplexing.

## 4. Demonstrated workloads

The published evaluation uses two interference-sensitive 6G-RAN workloads running concurrently.

| Workload | Technical focus | Assigned resources |
|---|---|---|
| MIMO iDFT/DFT Offloading | GPU offloading of 5G OFDM iDFT/DFT in OpenAirInterface | CPU cores 0–11, 40 MHz @ 3.32 GHz |
| O-RAN DoS Attack | Control-plane flooding via FlexRIC xApp against the E2 node | CPU cores 12–19, 40 MHz @ 2.59 GHz |

The **MIMO iDFT/DFT Offloading** use case evaluates whether GPU acceleration is advantageous for the iDFT/DFT stage in 5G OFDM. The implementation modifies **OpenAirInterface (OAI)** to include a GPU-accelerated kernel and compares it against an **AVX2-optimized CPU** implementation. The summary reports that for DFT sizes below **12288**, the CPU is faster, and that real 5G uses sizes below **4096**. The main bottleneck identified on the GPU path is **memory transfer**, as illustrated by Nsight Systems traces in the paper [2509.00130].

The **O-RAN DoS Attack** use case employs **FlexRIC** to deploy an xApp that floods the E2 node with subscription requests. In the reported experiment, one gNB’s throughput drops under attack, while the other parallel experiment remains unaffected. The purpose of this workload is not only security evaluation but also a stress test of VOTA’s isolation guarantees under malicious or pathological control-plane behavior [2509.00130].

Taken together, the two workloads span PHY/MAC real-time processing and O-RAN control-plane disruption. That combination is important because it tests VOTA under both sustained compute pressure and adversarial traffic.

## 5. Empirical behavior and measured outcomes

The headline empirical result is that VOTA produced **dedicated-like** results while permitting **2.67$\times$** more sharing opportunities on a **32-core host** [2509.00130]. In the scaling interpretation given by the summary, the most demanding workload required **12 cores**, so the host could safely accommodate approximately **2.67** such workloads in the sense of core provisioning, whereas the pre-VOTA baseline was effectively serial sharing or unreliable concurrent execution [2509.00130].

For the iDFT/DFT workload, the summary reports **~227 Mbps DL** under CPU-based continuous transmission and no penalty from co-running the O-RAN DoS experiment. For the GPU-offloading comparison, the CPU outperformed the GPU for the DFT sizes relevant to practical 5G because PCIe or analogous memory-transfer overhead dominated the GPU path [2509.00130]. This makes the workload valuable as a benchmark of real-time determinism rather than as evidence for GPU superiority.

For the O-RAN attack workload, the result of interest is containment. The attack degraded the targeted gNB while leaving the other experiment’s compute and RF performance unchanged. This is a concrete demonstration that VOTA’s isolation extends beyond benign multi-tenancy into cases involving deliberate service degradation [2509.00130].

A plausible implication is that VOTA is best understood as a **testbed-scaling discipline** rather than a mere packaging mechanism. Its empirical claims rely on preserving the operational envelope of independent experiments under concurrency, not simply on launching multiple containers.

## 6. Implementation stack, openness, and research significance

The implementation described in the summary uses **LXC/LXD v5.21.3**, **OpenAirInterface**, **FlexRIC**, and commodity host and radio components. The example platform includes **Ubuntu 24.04 LTS**, an **Intel Core i9-14900K**, **128GB DDR5**, an **NVIDIA RTX 4090**, **USRP X310** and **USRP B210** SDRs, and **Quectel RM530N-GL/RM520N-GL** UEs [2509.00130]. The project is explicitly characterized as **open-source** and **software-only**, with a stated intention to release the detailed testbed configuration and setup [2509.00130].

The significance claimed for VOTA is operational rather than theoretical: it increases utilization of expensive radio equipment, avoids dependency conflicts through per-experiment containerization, and preserves **true over-the-air** experimentation without requiring cages or additional RF-isolation hardware. The summary presents these properties as especially relevant to 6G-RAN workflows, where researchers need flexible device assignment, rapid iteration, and coexistence of heterogeneous stacks on the same infrastructure [2509.00130].

The roadmap listed in the summary includes **LXD on real-time kernels**, **federation across multiple clusters or sites**, and **O-RU support** for finer-grained O-RAN experimentation [2509.00130]. This suggests an intended evolution from single-host, single-lab scaling toward distributed and more disaggregated RAN experimentation.

In the current form, VOTA is a concrete method for converting shared wireless infrastructure from a serial-access resource into a spectrally partitioned, real-time virtualized platform. Its contribution lies in showing that concurrent OTA experimentation can be organized through software control of containers, CPU affinity, and frequency allocation while still preserving dedicated-like execution characteristics [2509.00130].

Source: https://www.emergentmind.com/topics/vota