The figure below shows the structure of the emulator control application that used on the emulation control node to control the experiment. As is shown on the right, the control software is organized as four layers. On the left, we show the three interfaces available to users to specify and control experiments. This page elaborates on both aspects of the software.
The channel model layer, together with the FPGA code executing on the emulator hardware, is responsible for the emulation of the signal propagation channels between the nodes (antennas) attached to the emulator. Real-time emulation is done on the FGPA-based DSP, but it is controlled by the channel model code on the control node. The DSP Communicator acts as the intermediary between the Java-based control code in the channel model layer and the real-time HDL code executing on the FPGA. For example, when the attenuation of a channel changes, e.g. to reflect the (emulated) movement of one of the wireless devices, the channel control code will pass a "change attenuation" request to the DSP Communicator, which will translate it into a format that can be handled by the FPGA. In an N node experiment, the user can specify N x (N -1) channels.
The emulator software has a set of built-in channel models that can be configured to represent a broad range of useful signal propagation environments. Most channels have a single path, although we do support multi-path on a limited number of channels. In our built-in model, each path has an attenuation that can be combined with fast Ricean fading based on a statistical model. Alternatively, the attenuation of a path can be controlled through trace playback. The properties of the paths can be either directly controlled by the user or they can be derived automatically from the physical world model, as we describe below. More details on the available channel models can be found on the page Signal Environment and Channel Models:
While users can control the signal propgation environment by directly setting the parameters of the channel models, this can become somewhat involved for complex experiments. As an alternative, we also provide an emulated world model that offers indirect control over the signal propagation environment. When using the world model, users still need to select a channel model (e.g. log distance or fading) and they also have to specifiy some of the channel model parameters (e.g. the exponent in the log distance model), but most of the channel model parameters are derived automatically from the state of the world model (e.g. distance between nodes, speed). As the user changes the position and speed of nodes in the world model, the channel model parameters are automatically updated. For more details on the world model, see the Physical World Model page:
The current world model is very simple. When simple log distance channel models without fading are used, it corresponds to a free space model. When fading is added, more interesting environments can be created, although the user is responsible for selecting both the world model and channel model parameters appropriately. We plan to develop more detailed world models that reflect specific types of environments, e.g. reflecting office buildings, homes, vehicular networks, etc.
The experiment services layer helps managing experiments. It has a number of components:The experiment control system is responsible for controlling all aspects of a wireless experiments according to the users' intentions. The left side of the software architecture figure shows that there are three interfaces: a graphical user interface that enables interactive experimentation as well as visualization, scripts that provide an easy-to-use method for conducting simple experiments, and programs that provide more advanced users full access to the emulator capabilities.
The script interface is an easy-to-use interface for conducting basic experiments. This interface allows users to define node movement and application execution without the need to write real code. The scripting interface that we provide is deliberately simple. No looping, branching, or variables are supported. Rather scripts are defined as lists of events using an XML-based syntax. This restricted interface provides a very shallow learning curve, and makes writing basic emulator experiments an easy task. More information can be found on the Scripts page.
This is the most powerful method for defining experiments. Users write their own Java threads that can call the various classes that implement the other modules directly. The user's Java classes are loaded at the start of the emulator experiment. Users can use any of the classes available in the system, or they can bypass them. The only class that the user must use is the DSP communicator class, since it needs to follow a specific protocol when talking to the emulator hardware. Using the programmatic interface, experiments with arbitrarily complex behavior can be created. It is the only interfaces that offers full access to all emulator features. Both the GUI and scripting interface only expose a subset of the emulator features, to keep the interfaces simple and easy to learn. More information can be found on the User Code page.
When conducting experiments with real hardware in a physical environment, there is frequently an exploration phase during which wireless nodes are moved and applications are run in an interactive fashion. This initial testing and performance exploration is then typically followed by a more systematic performance evaluation. One unique aspect of the emulator is the ability to perform this exploratory phase without the need to actually move around the real world. To support this type of functionality, we provide an interactive GUI that can be used to move RF nodes around in an emulated physical environment and in the corresponding emulated signal propagation environment. More information can be found on the GUI page.