• Testbed
• Umic-Mesh Realization
  • Motivation
  • Architecture
  • Realization
  • References
• Umic-Mesh Real-Time Status
• Other Testbeds

Network Architecture

The following depicts the general system and network architecture of the UMIC-Mesh testbed. In accordance with the previous considerations that a hybrid testbed presents an appropriate environment to study WMNs, the UMIC-Mesh testbed is realized by using two different components: a virtualization environment and a real testbed.

A main disadvantage of both real testbeds and virtualization environments is the high maintenance cost. Especially, if there is a failure in the course of a performance evaluation, the distribution of a new, corrected implementation is still labor-intensive. To minimize this maintenance cost a central configuration approach is used. As shown in the Figure, a central server, the so-called meshserver, is integrated into the testbed. It serves two responsibilities, the source functionality and the drain functionality. First, the term source functionality describes the fact that the server provides several services to the attached nodes. The most important service is the provision of an OS image to all nodes via network. Therefore, the basic setup is the same in each node of the hybrid testbed. The nodes may even share the same kernel including modules and drivers. Another important service provided by the meshserver is the Internet access, which is required for the mesh gateways. Second, the meshserver offers a drain functionality. That means, all important information about the real and emulated mesh networks is gathered and stored at the central server. Typical pieces of information are system log and SNMP messages or measurements results, which are stored in a database. This approach of a central log and information server enables a quick detection of any problem in the mesh testbed.

Besides reducing the maintenance cost, a central configuration and log server offers eased scenario creation and improved controllability. Since the configuration files are stored on a single central server, any WMN architecture or WMN application scenario can easily be realized. For example, it is possible to define which mesh routers should act as a gateways. Furthermore, the routing functionality for the clients can be enabled or disabled. Thereby, a routing mesh client can simply be reconfigured to a non-routing mesh client. Thus, the performance of different mesh architectures can be evaluated and measured.

All mesh routers and virtual machines are connected by a common network, the virtual backbone network. The term “virtual” emphases the fact that this network is solely used for booting and configuring the attached nodes as well as for the audit trail processing. That means, the clients in the real testbed cannot access the virtual backbone network. Thus, their data is not transmitted via this virtual network but is forwarded in a multi-hop fashion by the wireless network interfaces.