Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1

Ratings: (0)|Views: 17|Likes:
Published by wwdt4h

More info:

Published by: wwdt4h on May 07, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Experiences from the Design, Deployment,and Usage of the UCSB MeshNet Testbed
Henrik Lundgren, Krishna Ramachandran, Elizabeth Belding-Royer, Kevin Almeroth,Michael Benny, Andrew Hewatt, Alexander Touma, Amit JardoshDepartment of Computer ScienceUniversity of California, Santa Barbara
In this paper we report on our effort and experienceto design, deploy and use our 30 node wireless mesh testbed,the
UCSB MeshNet
. Compared to simulation, the constructionand utilization of a wireless mesh testbed poses many newchallenges. We discuss the challenges with distributed testbedmanagement, non-intrusive and distributed monitoring, and nodestatus visualization. These are vital components in a sustainablewireless mesh testbed, but at the same time, non-trivial todesign and realize. As a case study, we present the UCSBMeshNet architecture, including its management, monitoring,and visualization systems. We share our lessons learned from thiseffort and believe that they will be valuable to other researcherswho develop experimental wireless mesh networks.
I. I
In wireless local area networks (WLANs), the wired Ether-net is replaced by wireless connections through access points(APs) that are deployed in designated areas. Each AP, in turn,must be connected to a wired backbone network. This restrictsthe deployment of the wireless network and the placement of APs. A
mesh network 
is a more flexible solution to providewireless network access. An infrastructure mesh consists of de-ployed wireless mesh nodes that have minimal or no mobility,and serve the purpose of a multi-hop infrastructure backbone.Each mesh node has wireless router functionality and forwardsdata packets on behalf of other mesh nodes. Typically, one ormore nodes have external network access and act as gatewayson behalf of the rest of the mesh network. End nodes, such aslaptops and PDAs, may use the mesh infrastructure, but arenot required to implement mesh functionality themselves. Thisis in contrast to
ad hoc networking
, where even end nodes areexpected to implement functionality such as routing and self-configuration. Figure 1 shows an example of a multi-hop meshnetwork backbone that consists of dedicated mesh nodes.Mesh network research has so far primarily relied onsimulation for evaluation and performance prediction. Simu-lation is attractive since it enables test repeatability, parameterexploration, and scalability. Real world stochastic factors, suchas wireless randomness and node mobility, can be controlledand predicted through the use of models. However, modelsare often simplified to reduce simulation time, or because of the difficulties in accurately representing certain real worldphenomena. Another shortcoming is that most simulators lagwith respect to recent protocol improvements and new protocolversions. Research studies have shown that simulation resultsdepend heavily on the simulator and models used [1], [2] and
Fig. 1. A wireless multi-hop mesh network backbone inside a building,covering several floors. The black arrows indicate available radio links.
that some (performance degrading) effects may not be visibleuntil the protocols are exposed to real world settings [3].Simulation studies therefore need to be complemented bymore realistic testing. This testing is vital to improve theunderstanding of wireless network systems as it allows re-searchers to study phenomena that may not be visible insimulator settings. Emulation offers one possibility that rep-resents a middle ground between simulation and real worldtesting. Typically, wireless randomness and/or node mobilityare controllable through emulation [4], [5]. Another advantageof emulation testbeds is that the software under test typically isexecuted in its final operation system environment. To capturethe full effect of the wireless medium and node mobility,however, real testbeds are needed. A few major efforts withad hoc network testbeds have been used to study variousperformance effects in wireless and mobile settings [6]–[8].The primary difference between ad hoc network testbeds andmesh network testbeds is that the former typically consist of mobile devices with limited battery power. This, in turn, meansthat the lifetime of the ad hoc network is impeded by thebattery duration. In contrast, mesh testbeds typically constitutemore permanent infrastructures. For example, MIT’s Roofnetconsists of 30 stationary IEEE 802.11b nodes deployed inapartments on the MIT campus and has been running since2002 [9]. As another example, a PC-based 23 node IEEE802.11a indoor mesh testbed was recently built by MicrosoftResearch [10].
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 offices 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 [11] 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 significantly 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
, and
. We found these services to bevital to achieve efficient 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.
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 efficienttestbed 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 influence 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 flexibilityare 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)
hardware characteristics
, (ii)
operating system
,and (iii)
configurable parameters
. 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 modified 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, traffic 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.
disk space is also needed to log monitoring and experimentmeasurement data. Hard disk space constraints force solutionswhere measurement data must be transfered to stable stor-age frequently, even during experiment execution. Processingpower limitations affect the design of the testbed supportsystem, which should be designed to not significantly impactthe node performance during experiments.The hardware dictates the operating systems that can besupported. In turn, the operating system dictates the softwareprograms that can be used. For example, a dedicated wire-less access point may support installation of a Linux-basedoperating system. Although such an operating system may besimilar to a Linux distribution intended for a PC, the softwareavailable for execution may still vary.The ability to configure as many parameters as possible isdesirable. For example, transmission power adjustment allowsthe modification of network connectivity and thereby easynetwork topology variation. However, the ability to adjusttransmission power and the availability of WiFi information isdependent on the WiFi network interface card (NIC). A relatedissue is that different WiFi NICs may report information thatis not directly comparable between NICs. For example, WiFiNIC vendors interpret and present signal strength differently.Therefore, special care must be taken if the testbed consistsof nodes with heterogeneous WiFi hardware. However, testbedsettings with apparently homogeneous WiFi hardware can alsoexperience firmware diversity. This is due to the fact that WiFiNIC vendors may upgrade to newer firmware versions as wellas completely change the chipset while still maintaining thesame WiFi NIC model name. This firmware version diversitybecomes an issue if the testbed network is to be expanded ata later point in time or if some nodes need to be replaced.This can be an issue at the initial purchase as well. Since thefirmware revision number is only available on the NIC itself,retailers have no way to distinguish between different versions.Even a “bulk purchase” can contain WiFi cards with differentfirmware versions.
b) Hardware Deployment.
The hardware deployment canbe an additional factor in the node platform selection process.For example, the number of nodes needed can be influenced byrequirements to cover a specific geographic area, or to supportspecific network topologies. Therefore,
a priori
knowledgeabout the testbed area is important. The planning of thephysical placement of testbed hardware is commonly a trade-off between the following three factors: (i)
physical access totestbed nodes
, (ii)
availability of power outlets and network infrastructure
, and (iii)
planned network topology
.Unless there is a dedicated testbed area available, thephysical area is likely to have many constraints. In an in-door testbed, the building construction significantly affectsthe nodes’ transmission range. Another potential problem isthat nodes may breakdown, need to be replaced, rebooted, orupgraded. Therefore, while many other operations on testbednodes can be realized via remote access, easy physical accessto the nodes is desirable. Remote access can be realized viathe testbed network itself, but is dependent upon the network’soperational status. The availability of a pre-existing network infrastructure enables out-of-band remote access. Another im-portant factor to consider is that nodes require access to poweroutlets.The requirements described above are likely to put severelimitations on node placement. In addition to these require-ments, node placement is further impacted by the desirednetwork topologies. There are important benefits to havingredundant network connectivity and topology flexibility in thetestbed. For example, in a well-connected testbed, multipletopologies can be created by adjusting the output transmissionpower or turning on or off nodes’ network interfaces.
 B. Testbed Support System Design
A good system to support the operation and managementof the testbed is important. We found that efficient and easymanagement, automatic monitoring, and node status visual-ization are the most important components of such a system.The main challenge is to design these components such thatthey are distributed, efficient, and have minimal impact ontestbed experiments. In this section, we discuss these threecomponents and their design challenges.
a) Management.
A good management system is crucialfor efficient usage of the testbed. The management system’sdesign is dependent on the properties it needs in order tosupport the desired management operations. In this section, wediscuss the desired operations and the properties they require.The primary operations that the management system shouldsupport are: (i)
node configuration
, (ii)
software deployment 
software execution
, and (iv)
fault recovery
. First, allnodes must have the correct configuration prior to eachnew experiment. This requirement includes configuration of traffic generators and monitoring/logging software, as wellas varying transmission power, and activation/deactivation of network interfaces in order to control the network topology.Without an automated tool for configuration, test repeatabilityis jeopardized by the “human factor”. Topology control is anessential part of the configuration. Since wireless links varyover time and nodes may malfunction, a system must be ableto retrieve historic data on network connectivity as well ascurrent connectivity status. An automated tool for softwaredeployment reduces the deployment time and ensures that allnodes run the correct software version. Software executionis needed to perform configuration tasks as well as for ex-ecuting programs, such as traffic generators and monitoringtools. If the testbed consists of heterogeneous nodes, or if nodes should be treated differently, the management toolshould support node differentiation. Significant time can besaved if the management system is able to easily recoverfrom node faults and bring nodes back to a “good state”.However, some faults cannot be handled remotely, e.g., if a hardware failure occurs or if software causes a systemcrash. Additionally, a management system can be designed tohandle starting/stopping experiment execution. A related issueis node time synchronization, which might be needed for thesimultaneous commencement of an experiment on multiplenodes and for analysis of time-sensitive data.In order to support a management operation, the systemshould have the following properties: (i)
remote operation

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->