Our testbed, the UCSB MeshNet
, has been operationalsince 2004 and is similar to the previous two mesh testbedswith respect to the number of nodes and the fact that thetestbed is composed entirely of geographically distributed,physical nodes. The UCSB MeshNet is built from a mix of IEEE 802.11b/g Linksys WRT54G wireless routers and smallform-factor PCs, equipped with IEEE 802.11a/b/g PCMCIAwireless network interface cards. The 30 nodes are distributedin ofﬁces and research labs throughout the Engineering Ibuilding on the UCSB campus. The Linksys WRT54G routershave been upgraded with the OpenWRT
Linux distribution sothat they can run in ad hoc mode. All nodes have an ad hocrouting protocol installed that establishes and maintains pathsbetween nodes. Currently, the Ad hoc On-demand DistanceVector (AODV) protocol  is deployed on the testbed nodes,but any ad hoc routing protocol implementation developed forLinux can be used.Design, deployment, administration, and operation of amesh network are challenging tasks. Typically, the meshnetwork design is dependent on the hardware/software plat-form and network deployment, as well as administration andoperation restrictions/requirements. For mesh network design,there are hardware issues such as the selection of a hardwareplatform on which the designated testbed software must beable to execute and, at the same time, provide informationneeded for experiment analysis. Another issue related tomesh network design is the selection of the operational andadministrative functions that should be supported, which inturn have an impact on the network architecture. For example,network monitoring should be performed non-intrusively, andnetwork management operations, such as software deploy-ment and remote command execution, should be robust. Bothmonitoring and management solutions need to handle thedistributed nature of the mesh network. Another importantfactor that affects the mesh network design and deploymentis whether a wired backhaul network is available. Wirednetwork connectivity may signiﬁcantly affect node placementduring network deployment, or alternatively, the absence of wired connectivity will affect the monitoring and managementsoftware architectures.In this paper, we report on our effort and experience todesign, deploy, administer, and operate our mesh network testbed. As a case study, we describe the UCSB MeshNetarchitecture, including its support services for
. We found these services to bevital to achieve efﬁcient testbed operation and usage. Themost important lesson learned is that the trade-offs relatedto platform selection, node deployment, and testbed softwaredesign are all dependent on each other and thus need to be jointly evaluated.The remainder of this paper is organized as follows. InSection II we discuss the challenges of design, deploymentand usage of a mesh testbed. We describe our UCSB MeshNettestbed in Section III and summarize the lessons learned inSection IV. Finally, we conclude the paper in Section V.
SAGE OF THE
This section discusses the challenges and issues we experi-enced during construction and use of our mesh testbed. First,we discuss issues and trade-offs in platform selection and nodedeployment. Next, we describe the design challenges of thethree support services that we found to be vital for efﬁcienttestbed operation:
.In a mesh network, the design of these services poses chal-lenges different from those in a wired network, mainly due tothe mesh network’s distributed, wireless, and multi-hop nature.Furthermore, their design is affected by platform selection andnode deployment. Therefore, all trade-offs related to platformselection, node deployment, and testbed software design needto be jointly considered early in the planning of the testbed.
A. Platform Selection and Node Deployment
Two important issues to consider early in the planning of a mesh testbed are hardware/software platform selection andnode deployment. Node price typically increases with nodecapability. The number of nodes needed depends on the desirednetwork topology as well as the characteristics of the testbedarea. Since the testbed budget is typically limited, the nodeprice and the number of nodes needed becomes the main trade-off. This section discusses these and other trade-offs.
a) Selection of the Hardware and Software Platforms.
There are three primary factors that inﬂuence the selectionof nodes: (i) node capability, (ii) planned number of nodes,and (iii) node price. Typically, there is a trade-off betweendesired node capability, planned number of nodes, and thetestbed budget. Nodes with high performance and ﬂexibilityare usually desirable but are typically more expensive than lesscapable ones. Thus, the testbed designer must weigh the nodecapability against the planned number of nodes and the testbedbudget available. In this section, we focus our discussion onnode capability.Node capability is important and should be part of the initialtestbed design. The most important node capabilities to con-sider are: (i)
. The hardware characteristicsare dependent on the node type. Typically, mesh nodes canconsist of stationary PCs, laptops, and/or dedicated hardwaresuch as ordinary WiFi access points modiﬁed to operate asmesh nodes
. The advantages of dedicated hardware are thatit is cheap and that certain models are equipped with multipleradio technologies. On the other hand, dedicated hardware ishard to expand, e.g., increasing hard disk space or addingnew radio hardware may not be possible. Other trade-offswith dedicated hardware are that it typically has less harddisk space and processing power. At a minimum, there mustbe enough hard disk space for the testbed software, such asthe operating system, routing protocol, trafﬁc generators, andtestbed support system. By testbed support system, we meanthe software to operate, manage, and monitor the testbed. Hard
The Linksys WRT54G can be upgraded to run the OpenWRT operatingsystem, which enables installation of new software and the ability to operatethe access point as a mesh node.