OneLab - Future Internet Testbeds


Thirty-seven nodes are available in R2lab to provide a modern testbed infra structure. The nodes are distributed in a grid layout and are customizable, allowing great variety of experimentation scenarios.

Full control and access to bare metal
The nodes are totally open and users can install any software stack they need

The testbed is yours

The testbed is reservable as a whole. Once they have booked the testbed, registered users can ssh into, and from there control all the resources in the testbed. You are thus in full control of all the radio traffic in the chamber.

The nodes are yours

Also you can load your operating system of choice on any node. From that point you can ssh-access all nodes with administration privileges, and configure the available resources - nodes, SDRs and phones - to create a rich experimental environment.


Experimental scenarios can be created using standard tools. We also provide tutorials, and python libraries that can optionnally help you efficiently orchestrate the complete experimental workflow, from deployment to data collection.

All nodes

All 37 nodes are based on Nitos X50 and feature

  • State of the art motherboard
    • CPU Intel Core i7-2600 processor
    • 8GB RAM
    • 240 GB SSD
  • 2 Wireless Interfaces, dedicated to experimentation, 3 antennas each :
    • one Atheros 802.11 93xx a/b/g/n - exposed as atheros
    • and one Intel 5300 - exposed as intel
  • 3 wired interfaces used for :
    • remote power and reset management (not visible from linux)
    • control, used by the testbed management framework for providing access - reachable from the gateway as e.g. fit02 or fit34
    • data, dedicated to experimentation - known as e.g. data04 or data12

Icarus Nodes in the testbed

Icarus node standalone

USRP nodes

Some nodes are equipped with USRP devices from ETTUS to run SDR-based experiments such as spectrum analyzer or 4G/5G OpenAirInterface scenarios. All these devices can be remotely-controlled through the ust/uon/uoff utilities.

Currently, our deployment features the following types of USRP devices : USRP B210, USRP N210, USRP 2, and USRP 1 (see detailed mapping in the table below).

Make sure to read the additional notes below that cover some specifics of these devices.

Lime SDR devices

Here are the detailed specifications for the LimeSDR devices deployed in the chamber (see table below for the details on which nodes host such devices)

  • RF Transceiver: Lime Microsystems LMS7002M MIMO FPRF (Datasheet)
  • FPGA: Altera Cyclone IV EP4CE40F23 - also compatible with EP4CE30F23
  • Memory: 256 MBytes DDR2 SDRAM
  • Oscillator: Rakon RPT7050A @30.72MHz (Datasheet)
  • Continuous frequency range: 100 kHz – 3.8 GHz
  • Bandwidth: 61.44 MHz
  • RF connection: 10 U.FL connectors (6 RX, 4 TX)
  • Power Output (CW): up to 10 dBm
  • Multiplexing: 2x2 MIMO
  • Dimensions: 100 mm x 60 mm
  • Plus: "What makes LimeSDR interesting is that it is using Snappy Ubuntu Core as a sort of app store. Developers can make code available, and end-users can easily download and install that code."

Node with a Lime SDR device

Important notes on SDR devices

Please note the following specifics about the additional SDR devices:

  • the following table shows in the sdr columns the type of the attached SDR or none if none is installed.

  • Depending on the SDR device, one or two Rx/Tx channels may be available. The antennas attached to each channel are specified as follows: 900M for omni-directional 5dBi antennas, operating on 800-900MHz; 2-5G for dual-band 5dBi omni-directional antennas, operating on both 2.4GHz and 5GHz; and Dup-eNB or Dup-UE if a duplexer is used.

  • Warning: the N210 and usrp2 models use an Ethernet connection to link to the node. This means that on those nodes, the data wired interface is not available, as the hardware interface is wired into the USRP device.


Some USRP devices, like the B210, have their Tx and Rx SMA connectors very close to one another. For that reason some have a device named a duplexer band 7[specs] [pict].

The settings used in our deployed duplexers match the frequencies used in our default configuration for OpenAirInterface. That is to say, it is assumed that

  • Downlink (eNB to UE) uses frequency 2.66 GHz (duplexers are set to the 2.62-2.69 GHz range)
  • Uplink (UE to eNB) uses frequency 2.54 GHz (duplexers are set to the 2.50-2.57 GHz range)

In the sdr antennas column below, devices are tagged as either none, Dup-UE or Dup-eNB.

With the above assumptions, these tags can be interpreted as follows:

  • none: no duplexer is attached

  • Dup-UE: to transmits on the uplink and receive on the downlink; hence typically this setup can be used to scramble the uplink

  • Dup-eNB: conversely, this node is fit to scramble the downlink

Commercial Huawei LTE Sticks

The testbed currently includes 4 Huawei LTE sticks:

Commercial Bluetooth 4.2/5.0 Low Energy (BLE) devices

Commercial 4G/5G Quectel RM 500Q-GL USB3 modules

The testbed currently includes 4 Quectel RM 500Q-GL modules using specific kits (composed of M.2/USB3 interface and 4 antennas):

  • One attached to fit09 with SIM #14
  • One attached to fit18 with SIM #13
  • One attached to fit32 with SIM #11
  • One attached to fit35 with SIM #12

Commercial 4G Phones

The testbed offers a couple of commercial phones right inside the chamber:

  • Each phone is reachable through a Mac (that also sits in the room) that has its wireless card physically disabled, and that has a USB cable to the phone.
  • The Mac can be reached from the gateway as e.g. ssh tester@macphone1 (or the macphone1 convenience shell shortcut)
  • Once logged in the Mac you can use convenience helpers to manage the phone (type help for details), or use adb manually.
  • The mac can also be managed using apple screen sharing tools (VNC-compliant), pointing directly at
  • You will find more details about controlling the phone in the tutorials section.

How to control a commercial phone

Nodes detailed information

Clicking in the header will focus on nodes that have a USRP device

Nodes health

The testbed routinely runs a thorough raincheck procedure, to make sure that all is in order.
Stay away from nodes that show up behind a big red circle, as this means that the node is not in good shape.