Emulator Architecture Overview

Physical Structure

The architecture of the emulator is shown in the figure below. A number of "RF nodes'' (e.g. laptops, access points, or any wireless device in the supported frequency range) are connected to the emulator through a cable attached to the antenna port of their wireless line cards. Each RF signal is mixed with the local oscillator (LO) signal down to baseband and is then digitized. The digitized signals are fed into a DSP engine that is built around one or more FPGAs. The DSP engine models the effects of signal propagation (e.g. large-scale attenuation and small-scale fading) on each signal path between each RF node. Finally, for each RF node, the DSP combines the appropriately processed input signals from all the other RF nodes and sends it to the line card through the antenna port. More details on the emulator design and implementation can be found on the emulator web page and in various research papers.

architecture diagram

The emulator is managed using the Emulab software from the University of Utah in the context of the CMUlab testbed. The Emulab instance at CMU is called CMUlab and the two control nodes are boss.cmcl.cs.cmu.edu and ops.cmcl.cs.cmu.edu. "Boss" is used to allocate resources and set up experiments through the web interface (http://boss.cmcl.cs.cmu.edu). You can log into "Ops" to access your data and to log into the emulation controller and the laptops involved in your experiment over a private ethernet.

Fine grain control over emulator experiments is done by software running on the Emulation Control Node (emucontrol-1.ece.cmu.edu). It controls both the RF devices (laptops in the current testbed), allowing it to control applications on those devices, and the emulator hardware, providing control over the wireless channels. You can currently directly log into the emulation control node to control your experiments, but at some point, the control node only be accessible through "Ops".

The deployed wireless network emulator at CMU has the following features:

What nodes are available on the emulator changes over time. The CMUlab hardware page list the nodes that are currently available on the wireless network emulator.

Logical Architecture

From a user's perspective, there are three main subsystems which you use to control and run your experiment:
  1. Emulab is repsonsible for allocating PC nodes on the Emulator. You interact with Emulab through the web interface at http://boss.cmcl.cs.cmu.edu/.
  2. The Emulator Control Software is a collection of Java programs for controlling the signal conversion and propagation hardware. The RF parameters of your experiment are managed by the emulator daemon, based on a user-supplied experiment configuration file and optional custom Java classes. You run this software from the command line on emucontrol-1.ece.cmu.edu.
  3. The experimental PCs are controlled directly: When Emulab allocates a PC to your experiment, it loads a Linux operating system image onto the PC. Emulab can provide some default initial configuration, but in general you will log in to the PCs over SSH and configure them manually. You will have sudo authority on your PCs, and can do whatever you want with the wireless drivers and other software.

It is important to understand that we are using only a subset of Emulab's features. In a wired testbed like the original at Utah, Emulab is used to configure switches on the experimental network to create the desired topology. In our use, the experimental network is the simulated wireless medium, and Emulab has no knowledge of or ability to configure it.

The core of the emulator control system is the edu.cmu.emulator.Emulator daemon, which is invoked using the emuRun script on emucontrol-1.ece.cmu.edu. On startup, this daemon reads in configuration information generated by Emulab and a user-supplied XML experiment configuration file. This daemon then manages the FPGAs to create the desired emulated channels.