¶ Software
The ORBIT Radio Grid Testbed is operated as a shared service to allow a number of projects to conduct wireless network experiments on-site or remotely. Although only one experiment can run on the testbed at a time, automating the use of the testbed allows each one to run quickly, saving the results to a database for later analysis.
In other words, Orbit may be viewed as a set of services into which one inputs an experimental definition and one receives the experimental results as output as illustrated in Figure 1 below. The experimental definition is a script that interfaces to the ORBIT Services. These services can reboot each of the nodes in the 20x20 grid, then load an operating system, any modified system software and application software on each node, then set the relevant parameters for the experiment in each grid node and in each non-grid node needed to add controlled interference or monitor traffic and interference. The script also specifies the filtering and collection of the experimental data and generates a database schema to support subsequent analysis of that data.
Figure 4. Execution of an Experiment from a User's point-of-view
¶ Measurement & Result Collection
The ORBIT Measurement Framework & Library (OML) is responsible for collecting the experimental results. It is based on a client/server architecture as illustrated in Figure 5 below.
One instance of an OML Collection Server is started by the Node Handler for a particular experiment execution. This server will listen and collect experimental results from the various nodes involved in the experiment. It uses an SQL database for persistent data archiving of these results.
On each experimental node, one OML Collection Client is associated with each experimental applications. The details and "How-To" of such association will be presented in a following part of this tutorial. In the context of this introduction to the testbed, the client-side measurement collection can be viewed as follows. The application will forward any required measurements or outputs to the OML collection client. This OML client will optionally apply some filter/processing to these measurements/outputs, and then sends them to the OML Collection Server (currently over one multicast channel per experiment for logical segregation of data and for scalability)
There are two alternative methods for the user to interface their experimental applications with the OML Collection Clients and to define the requested measurement points and parameters. These methods and measurement definitions will be presented in details later in this tutorial.
As an example of the flow of an experiment, we can consider the process for imaging the nodes. All experiments are some variation of this process. Consider:
As we can see from this graph, different phases of the experiments occur in different parts of the infrastructure. Some operations (e.g. compute, communicate, overwrite disk) are done on the nodes them selves. Others are initiated from the console (they entry point of user commands). Much of the expirment orchestration happens withing the service infrastructure.