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
14
Embed
A Blueprint for a Manageable and Affordable Wireless Testbed: Design, Pitfalls and Lessons Learned Ioannis Broustis, Jakob Eriksson, Srikanth V. Krishnamurthy,
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
A Blueprint for a Manageable and Affordable Wireless Testbed: Design, Pitfalls and Lessons Learned
Ioannis Broustis, Jakob Eriksson, Srikanth V. Krishnamurthy, Michalis FaloutsosDepartment of Computer Science and Engineering
Central server • A simple desktop [email protected] 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
Overall connectivity
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
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
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.
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
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.
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 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
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
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.)