| | 1 | [wiki:WikiStart Orbit] > [wiki:NodeHandler NodeHandler] > [wiki:NodeHandler/Tutorial Tutorial] > Testbed introduction |
| | 2 | |
| | 3 | = The ORBIT Radio Grid Testbed = |
| | 4 | |
| | 5 | 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 server. To provide this service, each of the ORBIT hardware components is designed to be controlled by one of the ORBIT services. Figure 1 illustrates the ORBIT services. These services enable the experimenter to use a script to define and run an '''ORBIT Radio Grid Testbed''' experiment. |
| | 6 | |
| | 7 | Figure 1. ORBIT Services (see page 6 of [http://www.orbit-lab.org/download/presentations/Orbit_Architecture.pdf]). |
| | 8 | |
| | 9 | == Testbed Experiment Architecture == |
| | 10 | |
| | 11 | The '''ORBIT Radio Grid Testbed''' 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 2 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. |
| | 12 | |
| | 13 | Figure 2. Experiment Support Architecture (see page 8 of [http://www.orbit-lab.org/download/presentations/Orbit_Architecture.pdf]). |
| | 14 | |
| | 15 | == Hardware Components == |
| | 16 | The '''ORBIT Radio Grid Testbed''' as illustrated in Figure 3 consists of a multiply interconnected, 20-by-20 grid of '''ORBIT Radio Nodes''', some non-grid nodes to control R/F spectrum measurements and interference sources, and front-end, application and back-end servers. These servers support various ORBIT services. |
| | 17 | |
| | 18 | Figure 3. ORBIT Hardware (page 2 of [http://www.orbit-lab.org/download/presentations/Orbit_Hardware.pdf]). |
| | 19 | |
| | 20 | Each '''ORBIT Radio Node''' is a PC with a 1 GHz VIA C3 processor, 512 MB of RAM, 20 GB of local disk, two 100BaseT Ethernet ports, two 802.11 a/b/g cards and a Chassis Manager to control the node, see Figure 4. The Chassis Manager has a 10BaseT Ethernet port. The two 100BaseT Ethernet ports are for Data and Control. The Data ports are available to the experimenter. The Control port is used to load and control the ORBIT node and collect measurements. |
| | 21 | |
| | 22 | Figure 4. '''ORBIT Radio Node''' (see page 3 of [http://www.orbit-lab.org/download/presentations/Orbit_Hardware.pdf]). |
| | 23 | |
| | 24 | ==== Software components ==== |
| | 25 | Besides commercial software like Matlab and Excel and open-source software like Linux, Ruby and MySQL, there are two other types of software used with the '''ORBIT Radio Grid Testbed''': ORBIT-developed and user-developed. Most ORBIT-developed software provides the ORBIT Services as illustrated in Figure 1 above. ORBIT Services are integrated with the control hardware of the '''ORBIT Radio Grid Testbed''' and its servers. |
| | 26 | |
| | 27 | The main component of the Experiment Management Service is the '''Node Handler''' that functions as an Experiment Controller. It multicasts experiment scripts to the nodes. It keeps track of each step and sends the information to each node at the appropriate time. The '''Node Agent''' software component resides on each node and listens to commands from the '''Node Handler''' and reports information back to the '''Node Handler'''. The combination of these two components controls the testbed and enables the automated collection of experimental results. Because the '''Node Handler''' uses a rule-based approach to monitoring and controlling experiments, occasional feedback from experimenters may be required to fine tune its operation. |
| | 28 | |
| | 29 | The disk-loading '''Frisbee''' server is designed to quickly load hard disk images onto the nodes using a scalable multicast protocol. It allows different groups of nodes to run different OS images. |
| | 30 | |
| | 31 | The '''Collection Server''' collects experimental results. There is one instance of the '''Collection Server''' per experiment. The Berkeley database is used for scalability, and an SQL database is used for persistent data archiving. One multicast channel per experiment is used for logical segregation of data and for scalability. |
| | 32 | |
| | 33 | Besides ORBIT Services, other ORBIT-developed software includes '''Libmac''' and the '''ORBIT Measurement Framework'''. Each provides procedures that may be called in user-developed applications. '''Libmac''' is a user-space C library that allows applications to inject and capture MAC layer frames, manipulate wireless interface parameters at both aggregate and per-frame levels, and communicate wireless interface parameters over the air on a per-frame level. |
| | 34 | |
| | 35 | The '''ORBIT Measurement Framework (OML)''' has a client/server architecture illustrated in Figure 5 below. '''OML''' uses IP multicast to send data to the measurement server as it is collected. '''OML''' includes a client application programming interface (API). A developer can use this client API through a web interface to define the measurement points and parameters for his or her application. Such definitions are saved as an XML-based configuration file and source code for the measurement client is automatically generated that contains application-specific methods that handle type-safe data collection. This source code can be compiled and linked with the application. |
| | 36 | |
| | 37 | Figure 5. '''OML''' component architecture (see page 3 of [http://www.orbit-lab.org/download/publications/Orbit_OML.pdf]). |
| | 38 | |
| | 39 | User-developed software includes the script for the experiment, the application(s) and any modifications to system software. The user-developed script for the experiment contains three static components: the configuration of nodes, the configuration of the application software, and the configuration of the '''ORBIT Measurements Framework and Library (OML)'''. The application is one or more programs that implement the intended behavior of the active nodes in the experiment. Modified system software may include modified Linux components or custom device drivers. Each of these types of user-developed software is covered in more detail in the Testbed Experiments section of this tutorial. |
| | 40 | |
| | 41 | The interaction of the various commercial, open-source, user-developed and ORBIT-developed software components during the conduct of an experiment is illustrated in Figure 6 below. Note that experimental results are available via the web. |
| | 42 | |
| | 43 | Figure 6. Running an Experiment (see page 3 of [http://www.orbit-lab.org/download/presentations/Orbit_Software.pdf]). |
| | 44 | |
| | 45 | |
