1. A Blueprint for a Manageable and Affordable Wireless Testbed: Design, Pitfalls and Lessons Learned 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 TRIDENTCOM 2007

2.  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 Motivating factors for our achitectural design

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 3 rd 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 PoE on 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 number of links, both short and long Example: links of node 20 to all of 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 http://networks.cs.ucr.edu/testbed