Ioannis Broustis, Jakob Eriksson, Srikanth V. Krishnamurthy, Michalis Faloutsos

1. A Blueprint for a Manageable and Affordable Wireless Testbed: Design, Pitfalls and Lessons Learned TRIDENTCOM 2007 Ioannis Broustis, Jakob Eriksson, Srikanth V. Krishnamurthy, Michalis Faloutsos Department of Computer Science and Engineering University of California, Riverside {broustis, jeriksson, krish, michalis}@cs.ucr.edu

2. Motivating factors for our achitectural design • Functional requirements • Tune basic wireless network parameters, implement functionalities • Hardware requirements • Easily extend/update the testbed with new technologies, compatibility • Software requirements • Easily perform s/w configurations and updates uniformy for all devices • Efficiency and social implications • Non-intrusive deployment, limited interference from/to co-located wireless networks • Cost constraints • Low cost, without compromizing the capabilities • Manageability • Remote network configurations, update distributions, log gathering

3. In this paper… • We justify our architectural design choices • Diskless nodes • PoE • Linux NFS boot • We present how we manage our wireless testbed • Central server • Provides Linux image and drivers for nodes • Full access to all aspects of the network through this server • We discuss some pitfalls and mistakes to avoid • Transmission power and sensing threshold • Deployment issues

4. Deployment • 31 nodes, deployed in the 3rd floor of the CS building @ UCR • H/W components • Deployed in labs, offices, corridors • Both short and long links maintained

5. Hardware for the nodes • Remote access through Ethernet interface • Low cost • Silent, small size • Soekris net4826 • 266 MHz CPU • 64-256 MB SDRam • 10/100 Mbit Ethernet port • 2 miniPCI slots • On-board compact flash 128 MB • Serial port • Wireless cards: EMP 8602-6g, a/b/g • Atheros-based chipset • MadWifi driver • 5-dBi dual-band antennae

6. Testbed management from a central location • Central server • A simple desktop Pentium4@1.8GHz PC with 1 GB of memory • Two Ethernet interfaces (one for Internet, one for the testbed) • Server connected to nodes through a set of switches • Remote access from the server (only) to each individual node • Through secure shell connection (ssh) • PoE (Power over Ethernet) • Our set of switches (DLink-DES-1526) support PoE, as per the IEEE 802.3af standard • The nodes are empowered directly from the switches • We can power on/off each node remotely, from the server, by (de)activating the PoEon each port of the switch :-) • Very useful when nodes hang

7. Overall connectivity

8. OS boot for nodes • Main software requirements: • Secure • Easily configurable • Lightweight, due to low CPU/memory of the Soekris boards • Linux, mounted over NFS • Whenever a node is turned on (PoE is activated) it loads a Debian Linux from the central NFS/bootp/tftp server • Bootp for IP assignment (similarly as dhcp) • Update kernels/modules centrally, reboot the nodes, in order for them to get the updates • Only kernel and modules are loaded -- minimal memory demands • All required files loaded in memory; no need to read/write anything locally on nodes! • No disk = lower cost + lower probability of malfunction

9. Performing and managing experiments • All experiments are controlled by the central server • Server opens an ssh session to a node through wired interface • Initiates an iperf traffic experiment through this session on wireless interface • Closes the ssh sessions after the end of the experiment • Different linux distros can be used for different nodes • Each researcher maintains her/his own linux distro version at the server • The bootp config file is modified before rebooting the testbed • At reboot, nodes load the distro pointed by bootp • Some nodes may boot a different distro than others • E.g. some nodes may be configured to be the APs, while others the clients (as long as the Wifi card supports both AP and client drivers) • Or experiments may be run in paraller by different researchers on different nodes, in different channels… etc.

10. IP addressing and naming • Server: 10.0.0.1 • Switches: 10.0.0.253 - 254 • Nodes: static IP assignment • Wired segment: 10.0.0.11 and up • Wireless segment: 192.168.1.11 and up • Node name corresponds to last 8 bits of IP • Node-31 has Ethernet IP 10.0.0.31 and wireless IP 192.168.1.31 • Easier to identify/remember nodes, and set-up experiments

11. Pitfall: Placing nodes close with high power… • … is not efficient in terms of achievable throughput • Experiment: • 2 nodes, 3m apart, Tx power = 15 dBm • Fully-saturated TCP and UDP traffic from one node to the other • We observed that the achieved throughput was too low • We started increasing the distance between nodes, and observed that the throughput was increased, until distance = 10m. • For distance = 3m, the maximum throughput was achieved for Tx power = 1 dBm. • We observed similar behavior with 3 different wireless cards, all channels and both frequency bands • Happens probably due to the fact that the receiver’s A/D converter cannot compensate such a strong signal.

12. Pitfall: Transmitting with maximum allowable power… • … is not always the best way to go, for some wireless cards • Experiments with a large numberof links, both short and long • Example: links of node 20 to allof its neighbors • Only one activated each time • Max supported power: 18 dBm • Max throughput at 16 dBm, and drops for higher power! • Note that this is not the case for other cards • Exists with the EMP 8602-6g • Not with the Intel 2915

13. Conclusions • We have designed and deployed a manageable and affordable wireless testbed • PoE support for (de)activating nodes remotely • NFS, to avoid storing data locally, and managing updates easily • Silent, and small-size nodes, not to disturb people • Linux-based network, to have access to most aspects of the S/W • Manageable, through remote access to a central server • Some companies and universities have already adopted our architectural decision (Intel research, UCBerkeley, etc.)

14. Questions? • Thanks :-) • http://networks.cs.ucr.edu/testbed