network and systems laboratory nslab.ee.ntu.edu.tw the hitchhiker’s guide to successful wireless...

Network and Systems Laboratorynslab.ee.ntu.edu.tw

The Hitchhiker’s Guide to Successful Wireless Sensor Network Deployments

Guillermo Barrenetxea, Francois Ingelrest, Gunnar Schaefer and Martin Vetterli

LCAV, EPFL, Switzerland

SenSys 2008

Jeffrey


OutlineIntroductionRelated WorkSensorScopeThe Hitchhiker’s GuideConclusionComments

Copyright © 2008 Jeffrey Hsiao2


IntroductionMost theoretical aspects of wireless sensor

networks (WSNs) have been well studied over the past few years SynchronizationLocalization Routing

Real-world deployments still remain a challenging task



Why Challenging?Good WSN systems fail to provide expected

results once deployed in the real worldSuch failures may be either due to

a completely non-working system oran inability to meaningfully exploit gathered

dataWhile certain issues may be anticipated,

experience is still the key asset to ensure a successful deployment



Main Areas to Successful DeploymentsThree main areas exist, in which expertise is

needed, to access to the “Holy Grail” of successful deployments

DevelopmentTestingDeployment



DevelopmentThe first stepLocal conditions must be carefully studied

and consideredsuch as the expected weather in case of

outdoor deploymentsHardware must be well-fitted to the targeted

siteEmbedded software must be designed in a

way that eases debugging later on



TestingEnsuring that the system is ready to be

deployed before going on site is mandatorySetting up a testbed is often the best solutionDesigning a good one, however, is not so

easy



DeploymentLast but not least, the deployment is most

often the time to face unexpected problems due to unanticipated or—even worse—underestimated issues



SensorScopeOver the past three years, the authors have

worked on SensorScopean environmental monitoring system based on a

WSNHave engineered a complete framework

includingelectronic circuit boardsa solar energy systeman embedded communication stack, based on

TinyOSserver-side software



Six Real-world DeploymentsHave already run six real-world deploymentsRanging in size from half a dozen to a

hundred stationsFrom our university campus to high-mountain

sitesThroughout these deployments, valuable

experience in preparing, conducting, and managing deployments have been gathered



On A Rock GlacierHave deployed our system on a rock glacier

located at 2500m, on top of the G´en´epi, a mountain in the Swiss Alps

This environment is rough and the deployment took place under very harsh conditions

Thanks to the authors’ experience, it was successful and led environmental scientists to the modeling of a microclimate causing dangerous mud streams



Not For Outdoor Deployments OnlySensorScope is aimed at outdoor

deploymentsMany of the issues we describe in this paper

are common to all kinds of deploymentsThe main part of this paper is written as a

guide for readers aiming to deploy a live WSN

Contains much advice, illustrated with many examples, all taken from our own experience



Related WorkMany known deployments of WSNsWireless sensor networks for habitat

monitoring, 2002By a group at Berkeley in 2002, on the Great

Duck Island, to help habitat monitoring Pioneering WorkLimited To Single-hop CommunicationsMany Lessons Were Learned Regarding The

Difficulties Of Deploying Such A Network



Berkeley’s MacroscopeA macroscope in the redwoods, 2005A new sensor network built by BerkeleyBuilt on top of TASK, a set of WSN software

and tools, also designed at BerkeleyExtensively used for microclimate monitoring

of a redwood tree



DrawbacksRather small-scalePlaced in a tree, at an altitude of 15 to 70m

from the groundMost sensor motes, in particular the ones

used in SensorScope, are able to communicate directly over such a small distance



HarvardDeploying a wireless sensor network on an

active volcano, 2006A group at Harvard described their experience

in deploying WSNs on top of active volcanoesTo study their activity by measuring seismic

and infrasonic signalsClose to SensorScope, in the sense that

targeted sites are harsh and difficult to access once deployed the network must be robust and

reliable



DifferencesEvent-based

no data is needed when there is no volcanic activity

Sensor Scope is time-basedTheir deployments were also short-term (a

few weeks)Some of deployments in this paper lasted for

more than six months



Delft UniversityMurphy loves potatoes: Experiences from a

pilot sensor network deployment in precision agriculture, 2006

Researchers at Delft University deployed a large-scale sensor network in a potato field

The goal of the project was to improve the protection of potatoes against a

fungal disease to precisely monitor the development of that

disease



DrawbacksUnfortunately, the deployment went mostly

awryso that the work could not be finished, because

of time and money constraintsNevertheless, the researchers reported the

lessons they learnedespecially how much more difficult it is to set

up a WSN in the real world rather than in a simulator or in a laboratory



University of Virginia’s LUSTERLUSTER: Wireless sensor network for

environmental research, 2007Designed mainly to gather light measurementsBuilt on top of a low-power MAC layer Makes use of distributed storage on embedded

flash cards, providing fault-toleranceDeployed outdoors, in two different

environmentsin a forested area, close to the laboratoryon Hog Island, a research site in the Virginia Coast

ReserveCopyright © 2008 Jeffrey Hsiao

21


Deployment Methodology Remains The SameAlthough these projects are different from each

otherHardwareProtocolsApplications

The deployment methodology remains the sameWhile the targeted site may be either a volcano or

a giant tree, most difficulties regarding the deployment itself are common to all scenariosPreparationManagement



SensorScopeSensorScope is an environmental monitoring

systemBased on a time-driven WSNThe network’s sensing stations regularly

transmit environmental data to a sinkwind speed and direction

The sink in turn, uses a gateway to relay the data to a server



Different GatewaysDepending on the deployment scenario and

the available communication resources, different gateways are usedGPRS, Wi-Fi, or Ethernet

All data is published on our real-time Google Maps-based web interface and on Microsoft’s SensorMap website



Architecture



Results of CollaborationSensorScope is developed in collaboration

between two research laboratories at EPFL:LCAV (signal processing and networking) EFLUM (hydrology and environmental fluid

mechanics)



GoalThe goal is to improve current environmental

data collection techniquesCommonly based on a single, very expensive

sensing station (€ 60,000)Such stations use data loggers with limited

capacity, requiring manual on-site downloadsUsing a WSN is highly relevant to this area of

researchRealtime feedback (e.g., storms, pollution) Long-term monitoring (e.g., snow level) in areas

of varying sizeCopyright © 2008 Jeffrey Hsiao

28


HardwareShockfish TinyNode sensor motes are used



Why Shockfish TinyNode?Long communication range Low power consumptionA transmission power of 15 dBm allows for a

communication range of up to 500m with the on-board antenna

Up to 1 km using an external quarter-wavelength omni-directional antenna



Powered by Solar Energy SystemTo allow for long-term deployments, we

designed a complete solar energy system in the spirit of Heliomote

Composed of a solar panel and two rechargeable batteriesone of them being used as a backup buffer



SensorsStations are equipped with seven sensors,

measuring nine environmental quantitiesair temperature and humiditysurface temperaturesolar radiation wind speed and directionsoil water content and suctionprecipitation



Sensing Station



Sensor Box



PriceThe average price of a station is around € 900The price is kept down by using lower-end

sensorsA key goal of the project is to obtain dense

spatial measurementsThis is achieved by deploying multiple low-

cost—possibly less accurate—sensing stations, rather than a single expensive, but very accurate one



NetworkMulti-hop

wireless networking



Packet Format



Neighborhood ManagementMotes maintain a neighborhood table in

which they store the neighbors they can hear from

Chose an overhearing method in the spirit of MintRoute

There are no dedicated neighborhood discovery packets

Neighbors are discovered by listening to data traffic



Discovery Processthe sink starts the discovery process by

emitting beaconsA cost—currently the hop distance to the sink

—and a timestamp are associated to each neighbor



SynchronizationTo allow for a meaningful exploitation of

gathered data, it must be time-stamped by the nodes, as part of the sensing process

Because our power management mechanism relies on duty-cycling, we opted for global synchronization of all motes

Use SYNC REQUEST/SYNC REPLY messages to propagate the local time of the sink (the network time), so that all nodes share its clock



Clock UpdateWhen a node wants to update its clock, it

sends a request to a neighbor closer to the sink than itself

This neighbor, if it knows the network time, broadcasts it back, and all receivers, which are further from the sink, update their clock

The network time always propagates away from the sink, which acts as the global reference



Power ManagementEven with solar energy, power management at

the MAC layer is essential for long-term deployments

As the radio chip is a greedy energy consumerTurning on the radio of a TinyNode increases its

energy consumption approximately eightfoldOpted for a synchronous duty-cycling scheme

made this decision based on interactions with EFLUM

allowed us to determine that overall data traffic would be low



RoutingTo route data to the sink, a randomizing

solution is chosenEach time a packet has to be routed, the

forwarding node randomly selects a next hop between the neighbors closer to the sink

To give priority to the better neighbors, two thresholds, based on link quality, are used



DeploymentsHave conducted six deployments



The Hitchhiker’s GuideHardware and Software DevelopmentTesting and Deployment PreparationDeployments



Hardware and Software DevelopmentDevelopment is the first step towards the

construction of a new systemDuring this phase, it is of prime importance

to ensure that both hardware and software fit the intended application, considering the expected resultsthe conditions in which deployments will take

place



Consider Local ConditionsYou must investigate how local conditions

will affect your deploymentsBecause we knew that our deployments were

going to be outdoors, we carefully considered, with the help of the EFLUM, how weather conditions would impact our system



Not Always ObviousHowever, it is not always obvious how

possibly drastic variations in temperature and humidity will affect hardware devices in general

A lack of testing under real conditions may lead to serious issues

Already knew that Li-Ion battery should not be charged when the temperature is below freezingas it could explode



Many Hardware Failureshydrologists brought a disdrometer, an

expensive instrument that can distinguish between different kinds of rain by analyzing the water drops

It was supposed to be used as a high-quality benchmarking tool.

Unfortunately, it turned out that it worked only during a few days, simply because it was too cold on top of the mountain

Crucial to simulate the anticipated deployment conditions as accurately as possible



Use A Climate ChamberTo study the impact of weather conditions on

hardware devices, the best solution is to use a climate chamberarbitrary temperature/humidity conditions can

be createdIn most cases, basic tests inside a household

freezer will expose potential points of failure



Time’s a DrifterThe crystals, used in embedded devices to

measure time, are not perfecttemperature greatly impacts their precision



Hard Shell – Soft CorePackaging sensors for outdoor deployments is a

difficult taskAs it must protect electronic parts from humidity

and dust while being unobtrusive at the same timeIP codes are used to specify the degree of

environmental protection for electrical enclosuresThe required protection for outdoor deployments

is IP67, which provides full protection against dust as well as water, up to an immersion depth of one meter



Sensirion SHT75 sensorUsed to measure both air temperature and

humidity comes unpackagedTook quite some time to figure out a suitable

packaging, protecting from direct sunlight, while still letting the wind reach the sensor



Corrosion Problem-1



Corrosion Problem-2



There Is no Light at the End of the TunnelThere shall be no light because it strains thy

batteryOn our motes, a single LED consumes about 3

mAThat makes a total of 9mA for the typical three

LEDs, while the radio chip, when on, consumes “only” 15 mA

There is thus no reason to efficiently manage the radio while carelessly using the LEDs

LEDs are the most useful debugging tools for WSN developers (and often the only ones)



Keep It Small and SimpleBoth code and algorithms must be well-fitted

to the intended applicationSometimes, you will not be able to avoid

complexity, but whenever the benefits are questionable, you should prefer simple solutions



Remote ControlIf sensor motes are to be deployed in difficult-

to-access places (and sometimes even in easy-to-access places), the ability to remotely control the deployment is highly desirable

When going back to the deployment site is difficult or costly, being able to adjust certain parameters remotely, such as the sampling frequency, may be necessary

More drastically, you will also want to be able to reprogram the motes of an ongoing deployment, without leaving your office



SensorScopeWhen we developed SensorScope, we added

routines to the software running on the GPRS moduleenable us to control it remotely, using simple

GSM text messages, sent from a standard mobile phone

Allows to query its status or to reboot either the GPRS or the sink’s mote



SensorScopeCan also ask the GPRS to download a new

version of its binary image from an FTP server, and to reboot using this new version

Still cannot, however, change parameters of the entire network, as this requires a mechanism to disseminate information from the sink, which is currently not implemented



Don’t Be a Black BoxProgramming embedded devices requires a

different philosophy than traditional programming

In the latter case, it is easy to debug the code by using any kind of debugging statements or tools

It is far more difficult with embedded devices, such as sensor motes, as the simplest way for them to communicate with the outside world is by blinking their LEDs or using their serial port



Recommendationresearchers from Delft University

recommend that each software component should be able to produce a set of statistics about its recent activity

In SensorScope, besides traditional sensing packets, sensor motes generate three kinds of status packetsEnergyNetworkNeighborhood



Energy Status Packets



Network Status Packets



Publish or PerishAt some point, your system will—hopefully—

be functional and deployed, and your next step will certainly be to get publications out of it

Similar to the system itself, you should carefully plan these publications during the development phaseto make sure that all required data will be

gathered during deployments



Choose Your PartnerThere are two major components of a

successful deploymentsgathering the dataexploiting the data

Generally, networking laboratories only care about the first component, while the second one actually plays an equal role



Testing and Deployment PreparationTo prepare for our deployments, we use two

different testbedsOne is indoors, conveniently located in our

building, used mostly to test our communication software

The second testbed is a pseudo real-world deployment, located on our campus, composed of actual sensing stationsused to ensure that all code which is not in use on

our indoor testbed (e.g., sampling sensors, managing solar power) does not interfere with the rest



Efficiency MattersWhen setting up a testbed, you must keep in

mind that it will be used to develop and to test many software components

Because that is a long process, composed of many test-it-and-fix-it cycles, it is important for the testbed to be easily and quickly accessible

While programming motes one by one with a serial cable may be acceptable for deployments, because it is done only once, this is not the case for a testbed



Indoor TestbedRegularly replacing batteries is not a good

idea either, and this will be necessary, even if some slick power saving algorithm is used

As our indoor testbed is solely used to evaluate network code, its motes are not wired to any external sensors.

All of them are, however, plugged into AC power, allowing us to disregard any problems linked to energy management



Indoor TestbedFurthermore, all 50 motes are equipped with

a Digi Connect ME module which makes it possible to access and program them over a simple Ethernet connection

Each Digi module is indeed assigned an IP address which, in combination with the appropriate PC-side driversAllows for transparent PC–mote serial

communicationSuch equipment is very important to allow for

quick testingCopyright © 2008 Jeffrey Hsiao

71


Time to Flash MotesOn our indoor testbed, it takes only between

10 and 45 seconds to flash all 50 motes, depending on the size of the image,

while it takes us about 45 minutes to flash the 10 motes of our outdoor testbed and to put them back



Labels that StickOur indoor testbed is distributed among a

number of offices in our building, some of them belonging to other laboratories

We frequently discover that some of the motes are disconnected, or have even disappearedBecause people do not know exactly what these

strange devices are and what they are used forWhen we first installed our indoor testbed, we

put stickers on the motes stating that “this device belongs to LCAV, please

contact . . . for further information”



Know Your EnemiesWhen setting up a deployment or a testbed

(especially indoors, or close to urban areas), the first order of business should be to inspect the radio spectrum used by your platform to detect possible external interferences

The optimal way to do this is to use a spectrum analyzer



A Simpler WayA simpler way to check for interferences is to

run a test program to determine losses over time for the various frequencies that your selected platform can use

A run of 100 transmissions was started for each payload length with an interval of two seconds between transmissions



The Value of SimulationIn place of a testbed, or in addition to it,

simulations can be used to test protocolsMany simulation tools are available, the most

(in)famous one certainly being ns-2A new kind of simulation tool, called

Worldsens [4], has been developedMost of it is actually not a simulator, but a

sensor mote emulatorWSim



Image is Needed



Conclusion



CommentsProvide rather practical advices for WSN

deploymentsUseful for outdoor WSN deploymentsMight not be directly applicable to indoor

WSN deployments



Thank you very much for your attention!

Any Questions?


network and systems laboratory nslab.ee.ntu.edu.tw the hitchhiker’s guide to successful wireless...

Documents

systems laboratory

jeffrey slide

jeffrey hsiao

software copyright

good wsn systems

easy copyright

challenging task copyright

solar energy system