Restore

Testbed Realization

The UMIC-Mesh testbed is deployed in the complex of the Department of Computer Science at the RWTH Aachen University. The complex consists of one four- and two three-story buildings, which are all interconnected. The mesh routers are located in different offices at different floors. Currently, three mesh routers are installed per floor there. None of the mesh routers has a line-of-sight to its respective neighbor.

As mentioned above, the UMIC-Mesh testbed consists of two parts, the virtualization environment and the real testbed. The remainder of this section describes the hard- and software used for each of these parts.

Hardware

Currently, the real testbed part of UMIC-Mesh consists of 51 identical mesh routers. Each mesh router consists of a single board computer (SBC), two IEEE 802.11a/b/g wireless network interface cards, two omni-directional antennas and one 515MB compact flash (CF) card. The SBC is a ALIX.2C2/3C2 board from PC Engines [PCEngines], which is a x86 computer on the basis of the 500 MHz AMD Geode LX800 CPU. Besides the slots for the two Mini PCI cards and the CF card, the board offers 128 MB RAM, one 100 Mb/s ethernet port, and one RS 232 serial port. The board does not have any graphic adapter, keyboard or mouse connector. All communication with the mesh router goes over a serial line, or via network connections. The WRAP.2E is particularly suitable as a wireless mesh router since the board presents a small, quiet, and cost-effective SBC platform.

The two wireless network interface cards every mesh router is equipped with base on the Atheros AR5213 XR chipset [Atheros] and each of them is connected to a tri-band 5 dBi omni-directional antenna [Joymax]. While the first card is reserved for router-to-router communication, the second one handles the router-to-client communication. Other variations, such as interface channel assignment, are conceivable but not yet been implemented. In order to cleanly separate router-to-router from router-to-client communication, the first card uses 802.11g channel 1 and the second one channel 11. Both cards transmit at 100 mW and operate in a non-standard independent basic service set (IBSS) mode ahdemo [Madwifi]. The ahdemo omits the beacons and the basic service set identifier (BSSID) mechanism of 802.11. This solves the tendency of the IBSS mode to form partitions which have different BSSIDs despite having the same network identifier (NID). Such partitions made it impossible to reliably operate the WMN with the IBSS mode. All mesh routers share the same extended service set identifier (ESSID) pair, that is one ESSID for channel 1 (router-to-router communication) and one ESSID for channel 11 (router-to-client communication).

The virtualization part of our testbed consists of 7 standard Core 2 Duo PC with 1 GB RAM. With this amount of RAM it is possible to run about 10 virtual machines per host.

Software

As described in the previous Section, one goal of the UMIC-Mesh implementation is to achieve is a central configuration. In order to do so, a single OS image is provided to all nodes via network by using the Network File System (NFS) protocol. Consequently, there is no restriction to the use of a stripped-down Linux distribution fitting onto the CF cards of the routers. Therefore, a standard Ubuntu Linux distribution has been chosen. Besides some alterations in the boot process, which are described below, nodes are running standard Linux software.

The central audit trail processing is realized with a combination of logging and monitoring. The logging task is performed by syslog [Lon01], the de facto standard for forwarding log messages in an Internet Protocol (IP) network. It provides a centralized, securely stored log of all network devices. This incorporates a lot of powerful features, including filtering based on message content, as well as customizable data mining and analysis capabilities. The other task, monitoring, is performed by the SNMP [CasMunPar+02]. Its extensible design is achieved by management information bases (MIB). Thus, it is not only possible to retrieve information from the mesh routers but also to apply changes to the managed testbed, e.g., to change the wireless channel or the transmitting power.

On the one hand, the madwifi-ng driver [Madwifi] is used to implement the WMN architecture in the real testbed. One of the most interesting features of madwifi is the virtual access point (VAP) mode that allows the operation of multiple concurrent virtual wireless devices running in different modes. In particular, it is possible to run one VAP in the access point (AP) mode and a second one in the ad-hoc mode. Thereby, both non-routing and routing mesh clients are connected by means of the same wireless network interface card. Otherwise, two separate cards would be needed, since non-routing mesh clients operate in the AP mode and routing mesh clients in the ad-hoc mode.

On the other hand, the nodes in the virtual environment are driven by Xen [Cambridge]. The open-source pro ject Xen was chosen due to the fact that it employs the most efficient approach to a system virtualization, the paravirtualization. Furthermore, CPU manufacturers actively support its development. Thus, the upcoming integration of hardware virtualization support and the general Xen development are likely to make quick progress. Host and guest systems, the so-called domains, are equipped with a modified version of the Linux kernel. Domain administration is carried out in the host system, dom0 in Xen terminology. On a given dom0 the maximum number of guests, or domUs, is bounded by the amount of physical memory and by the available processing power.

To emulate the multi-hop behavior a combination of the advanced networking features of the Linux kernel is used. At the core, there is a virtual network that exists on top of the virtual backbone as illustrated in the Figure before. For this, the tunneling protocol Generic Routing Encapsulation (GRE) [FarLiHan+00] is utilized. It emulates a broadcast medium on top of an existing IP network by using a multicast address for its broadcast traffic. To control the communication between all participants of the network, standard packet filtering as provided by iptables [netfilter] is employed. There is no effort put in the emulation of a wireless medium (e.g., by using tc [LARTC] to set packet loss and packet delay) because the virtualization environment is used only for software development and functionality validation. Network performance valuation is solely done in the real testbed.

Currently, the Dynamic Manet On-Demand (DYMO) routing protocol [ChaPer06] implementation from the University of Murcia [Murcia] and the Optimized Link-state Routing Protocol (OLSR) protocol [ClaJac03] implementation from the OLSR.org Project [OLSR] are employed. This is because the two routing protocols are typical representatives of the two routing philosophies in mobile ad-hoc networks (MANET): reactive and proactive routing.

As previously mentioned, all UMIC-Mesh testbed nodes are booted via network. The vital parts of this process get an IP configuration and a kernel for booting. For this purpose, a combination of EtherBoot [EtherBoot] and PXELinux [PXELinux] is utilized. EtherBoot obtains the IP configuration from a Dynamic Host Configuration Protocol (DHCP) server and provides a standardized environment, the so-called preboot execution environment (PXE), to PXELinux. In turn, PXELinux uses this environment to access the network and to fetch a kernel image from the supplied server address.