An Analysis of a Large Scale Habitat Monitoring Application

Robert Szewczyk, Alan Mainwaring, Joseph Polastre and David Culler

April 9, 2004

AbstractHabitat and environmental monitoring is a driving appli-cation for wireless sensor networks. We present secondgeneration sensor networks deployed during the summerand autumn of 2003. These networks produced uniquedatasets for both systems and biological analysis. Thispaper focuses on nodal and network performance, withan emphasis on lifetime, reliability, and network perfor-mance. Of particular interest are the the static and dy-namic aspects of single and multi-hop networks over thecourse of several months as these networks run com-pletely unattended. This analysis sheds light on a num-ber of network design issues from network deployment,through selection of power sources to optimizations ofrouting decisions.

1 IntroductionSensor networks offer enormous potential benefits forhabitat and environmental monitoring. They enable pre-cision sensing at the spatial and temporal scale of thephenomena of interest rather than of the human observeror sparsely deployed instrument. Automated observationand measurement not only exposes the long-term unat-tended operation potential of low-power microelectronics,but it minimize observer effects and study site intrusionsas well. The efficiency of data collection as well as thequality of the data should increase, while the costs as com-pared with traditional human-centric methods should de-crease. Moreover, sensor networks offer new capabilities,such as near real-time data access via the Internet to recentand archival data. This further minimizes observer effectsand site intrusions, and establishes a new paradigm of datapublication and dissemination.

A broad class of important habitat and environmentalmonitoring applications are within reach of contemporarytechnology. They are both scientific and commercial innature, representing, for example, applications in ecology,plant physiology, and precision agriculture. They appli-cation share a common structure where fields of mostlystationary sensors arequeriedperiodically for their sen-sor readings and report results to a central data center.The two principal characteristics that distinguish pointswithin the space are the sensor sampling rate and the net-work bandwidth requirements. The application discussedin this paper resides in the low sample rate, low band-width quadrant. The architecture and its implementation

as described herein is quite general and can support ap-plications in other quadrants with varying sampling andbandwidth demands.

To demonstrate the practical benefits of sensor net-works and to develop first hand experience with sensornetwork technologies in the field, we have several de-ployed sensor networks of increasing scale in a ruggedoutdoor environment. The networks have produced aunique datasets for the life sciences and biological anal-yses are underway. From a systems perspective, they con-tain a great deal of information. For example, some sen-sor nodes ran unattended for 3 to 4 months and there arepacket logs for them. There are packet traces showingemergent network behavior after weeks of operation. Andalthough the application on each sensor node was simple,it exhibited ample amounts of interesting behaviors afterdays, weeks and months of runtime. Bit by bit we’re gain-ing practical experience from real world deployments.

This paper presents an analysis of that data collectedduring the summer and autumn of 2003. It is organizedas follows: Section 2: system architecture and realization.Section 3: data Analysis Section 4: discussion Section 5:Related Works and Section 6: concludes.

2 SystemAs preparation for the performance analyses in Section 3,this section presents the system architecture and its imple-mentation. In particular, we describe the tiered networkarchitecture typical of habitat monitoring applications andthe design and implementation of its major components.

2.1 ArchitectureThe system has the tiered architecture depicted in Fig-ure 1. The lowest level consists ofsensor nodesthatperform communication, computation and sensing. Theyare typically deployed in dense patches. Depending onthe application, their spatial distribution within asensorpatchcan vary from transects to patches of nodes to three-dimensional monitoring. Each sensor patch has agatewaythat sends data from the patch through atransit networkto a remotebase stationvia thebase station gateway. Weexpect mobilefield toolswill allow on-site users to in-teract with the base station and sensor nodes to aid thedeployment, debugging and management of the installa-tion. The base station provides Internet connectivity anddatabase services. It needs to provide high availability andbe able to deal with disconnections. Remote management

1

facilities are a crucial feature of a base station. Typicallythe sensor data is replicated via Internet. These replicasare located wherever it is convenient for the users of thesystem. In this formulation, asensor networkconsists ofone or more sensor patches spanned by a common transitnetwork and base station.

Site WAN Link

Client Data Browsingand Processing Base station

Transit Network

Verification Network

Single Hop Network

Multi Hop Network

Internet

Gateway

Gateway

Gateway

Sensor Patches

Figure 1: Architecture of the habitat monitoring system

Sensor nodes are small, battery-powered devices capa-ble of general purpose computation, bi-directional wire-less communication, and application-specific sensing.The sizes of nodes are commensurate with the scale ofthe phenomenon to be measured. Their lifetime varieswith duty cycle and sensor power consumption; it can bemonths or years. They use analog and digital sensors tosample their environment, and perform basic signal pro-cessing, e.g., thresholding and filtering. Nodes communi-cate with other nodes either directly or indirectly by rout-ing through other nodes. Nodes communicate directly totheir gateway in asingle hopnetwork or through interme-diates in amultihopnetwork.

Independentverification networkscollect baseline datafrom reference instruments that are used for sensor cal-ibration, data validation, and establishing ground truth.Typically verification networks utilize conventional tech-nologies and are limited in extent due to cost, power con-sumption and deployment constraints.

2.2 Concrete DeploymentOur habitat monitoring deployment is a concrete realiza-tion of the general architecture from Figure 1. The sensornode platform was a Mica2Dot, a repackaged Mica2 moteproduced by Crossbow, Inc. with a 1 inch diameter formfactor. The mote used an Atmel ATmega128 microcon-troller running at 4 MHz, a 433 MHz radio from Chip-con operating at 40Kbps, and 512KB of flash memory.The mote interfaced to sensors digitally using I2C and SPIserial protocols and to analog sensors using the onboardADC. The small diameter circuit boards allowed a cylin-drical assembly where where sensor boards were endcaps

with mote and battery internal. Sensors could be exposedon the endcaps; internal components could be protectedby O-rings and conformal coatings. This established amechanical design where sensor board and battery diam-eters were in the 1 to 1.5 inch range but the height of theassembly could vary.

Figure 2: Mote configurations used in the deployment:climate mote (left) and presence mote (right)

We designed two different motes for the application,presence motesfor detecting occupancy using non-contactinfrared thermopile sensors andclimate motesfor moni-toring microclimates. The presence motes, being the moreelectromechanically constrained of the two forms, pushedminiaturization more than the climate mote. The pres-ence mote had to be extremely small to be deployed un-obtrusively in nests typically only a few centimeters wide.Batteries with lithium chemistries were chosen with dis-charge curves where voltages remained in tolerance formote, radio and sensors almost to the end of the batterylifetime. We elected not to use a DC boost regulator to re-duce noise, standby power consumption, and power con-sumption as the battery discharges. Its operation and thequality of its sensor readings depends upon the voltage re-maining within tolerance. As the voltage falls outside theoperating range of the mote, radio, or sensors, the resultsare unpredictable.

2.2.1 Presence and Climate MotesPresence motes monitor temperature, humidity and occu-pancy of nesting burrows using non-contact passive in-frared temperature sensors. They have two sensors: aMelexis MLX90601 non-contact temperature module anda Sensirion SHT11 temperature and humidity sensor. TheMelexis part measures both ambient temperature (± 1◦C)and object temperature (± 2◦C). The Sensirion part mea-sures relative humidity (± 3.5% but typically much less)and ambient temperature (± 0.5◦C), which is used inter-nally for temperature compensation. The motes used 3.6VElectrochem batteries rated at 1Ahr, with a 1mA rated dis-charge current and a maximum discharge of 10mA. The25.4mm diameter by 7.54mm tall dimensions of the cellwere well suited for the severely size constrained presenceenclosures.

Climate motes monitor temperature, humidity, andbarometric pressure. (They also measure ambient andincident light, both broad spectrum as well as photo-synthetically active radiation, but these were not used inthis application.) They have the following sensors: Sen-

2

sirion SHT11, Intersema MS5534A barometer, 2 TAOSTSL2550 light sensors, and 2 Hamamatsu S1087 photodi-odes. The Intersema measures barometric pressure (± 1.5mbar) and ambient temperature (± 0.8◦C) used for com-pensation. The motes used 2.8V SAFT LO34SX batteriesrated at 860mAhr, with a 28mA rated discharge currentand a maximum discharge exceeding 0.5A. A 25.6mmdiameter by 20.3mm height were similar to the Elec-trochem, permitting a similar packaging technique. Thebattery exhibits a flat voltage profile for nearly its entirelifetime.

2.2.2 Single and Multihop Networks

The first network deployed was an elliptical single hopnetwork The total length of the ellipse was 57 meters. Thenetwork gateway was at the western edge. Nodes in thisnetwork perform no routing, they sampled their sensorsevery 5 minutes and sent results to their gateway. Thegateway mote used a TESSCO 0.85 dBi omnidirectionalantenna for the sensor patch and a Hyperlink 14dBi yagifor a long distance point-to-point link to the base stationover a distance of about 120 meters.

The second deployed network was a multihop networkwith a kite-shape to the southwest and a tail to the north-east. Its total length is 221 meters with a maximum widthof 71m at the southwest but it narrows to 8m at the north-east. Nodes in this network sampled every 20 minutes androuted packets destined for its gateway. An identical an-tenna configuration to the single hop network was used,with a few important distinctions. The gateway mote inthe single hop network operated at 433 MHz, and its pack-ets were retransmitted on the transit network at 915 MHz.The gateway mote in the multihop network operated at435 MHz, and its packets were retransmitted on the tran-sit network at 916 MHz as well. The 128kHz frequencybandwidth of the radio allowed the two sensor networkdeployments to operate independently but share a com-mon transit network and upstream infrastructure.

2.2.3 Transit and Verification Networks

There were two redundant transit networks operating onidentical channels that connected the single and multihopnetworks to the base station gateways. The gateway nodeswere co-located in the sensor patches for convenience.

To understand the correlation between infrared sen-sor readings from presence motes and true occupancy,the verification network collected 15 second movies us-ing in-burrow cameras equipment with IR illuminators.Using a combination of off-the-shelf equipment–cables,802.11b, power over Ethernet midspans, and Axis 2401camera servers–eight sites were instrumented and five op-erated successfully. All verification network equipmentwas physically distinct from the transit and sensor net-works with the exception of the laptops at the base station.Scoring the movies by hand in preparation for analysiswith sensor data is underway.

2.2.4 WAN and Base StationA DirecWay 2-way satellite system with Optistreams ser-vice provided WAN connectivity with 5 globally routableIP addresses for the base stations and other equipment atthe study site. This provided access to the PostgreSQLrelational databases on the laptops, the verification im-age database, administrative access to network equip-ment, multiple pan-tilt-zoom webcams and network en-abled powerstrips. A remote server computes the set ofdatabase insertions and uploads the differences every 20minutes via the satellite link. Should the link be un-available, updates are queued for delivery. The remotedatabases may be queried by replicas for missing dataupon link reconnection. Although the upstream band-width is small (128Kbps), we have not witnessed an over-run situation. The base station, satellite link and sup-porting equipment were powered off a standalone photo-voltaic system with an average daily generating capacityof 6.5kWh/day in the summer.

2.3 Media Access and RoutingThe network software was designed to be simple and pre-dictable. The radio was duty cycled in our deploymentswith a technique called low power listening. Low powerlistening periodically wakes up the node, samples the ra-dio channel for activity, and then returns to sleep if thechannel is idle. Packets sent to a low power listening nodemust be long enough that the packet is detected when thenode samples the channel for activity. Once activity isfound, the node stays awake and receives the packet, oth-erwise it goes back to sleep.

The single hop network utilized low power listening butwith normal sized packets to its transit gateway. Pack-ets with short preambles can be used because the gate-way does not duty cycle the radio–instead it is capable ofalways receiving packets. The sensor nodes periodicallytransmitted their sensor readings. They used low powerlistening to allow the base station to issues commands tochange their sample rate, to read calibration data them,and toping the node for health and status information.

The multihop network integrated low power listeningwith adaptive multihop routing developed by Woo [11].Each node selected its parents by monitoring the channeland using the path it expected to be most reliable. Nodesperiodically broadcasted their link quality estimates totheir neighbors. This data was used to find bidirectionalreliable links. The nodes communicated with each otherusing low power listening and long packets. We estimateda network neighborhood size of 10 nodes and calculatedthat a 2.2% radio duty cycle would maximize the node’slifetime. We deployed the nodes with these settings andallowed them to self-organize and form the network rout-ing tree.

The software running on the presence and climatemotes implements a data stream architecture. Each motesamples it sensors and sends its readings to the base sta-tion once per sampling period. Single hop motes sam-ple every five minutes and multihop motes every twenty

3

Table 1: Estimated power consumption of the applicationTask Energy Singlehop Multihop

current current(mAs) (µA) (µA)

Baseline sleep - 20 20Timer 0.0012 22 22Incoming packet detection 0.166 166 332(low power listening)Packet transmission 1.4 5 -(short preamble)Packet transmission 14.0 - 23(long preamble)Climate sensing 13.0 43 11Occupancy sensing 12.6 (est) 42 10.5Total climate mote - 256 408w/o routing & overhearing)Total presence mote - 255 407.5w/o routing & overhearing)

minutes. Each mote also listens for incoming packets andtakes appropriate action upon receipt. If the packet is des-tined for the mote, it parses the contents and takes appro-priate action, e.g., changing its sampling rate or respond-ing to a diagnostic ping message. Otherwise, the packetis forwarded by the routing subsystem towards its desti-nation.

3 AnalysisThis section analyzes the performance of the sensornetworks from a systems perspective, analyzing packetpower, and network properties. During their combined115 days of operation, the networks produced in excess of650000 sensor observations. The first deployment startedJune 8th with the incremental installation of a single hopnetwork. At its peak starting June 16th, the network had48 motes (28 presence and 21 climate). A second deploy-ment began July 8th with the incremental installation ofa multihop network. At its peak starting August 5th, thenetwork had a total of 98 motes (62 presence and 36 cli-mate).

3.1 LifetimeThe design goal for the networks was to provide obser-vations throughout the field season. We first examinethe lifetime of single- and multihop motes, and comparethe achieved performance with estimates. The simplicityand regularity of the single-hop network makes the poweranalysis straightforward. Table 1 summarizes the mainsources of power drain in the system. Excluding packetreception costs, our original estimates called for a 256µAand 255µA current drain in the single hop climate andpresence motes respectively – or 138 days of operationassuming a full battery discharge with the SAFT lithiumcells.

Figure 3 shows the distribution of mote lifetimes indays in the single hop networks for both climate and pres-ence motes. The key distinctions between the climate andpresence lifetimes are the significantly different mean andmedian days of operating. Whereas over 75% of the cli-mate mote population lives for 120 days or longer, only

0 20 40 60 80 100 120 1400

0.1

0.2

0.3

0.4

0.5Distribution of lifetimes in the single hop network

Frac

tion

of P

opul

atio

n

Climate motes: N=21mean=104, median=126

0 20 40 60 80 100 120 1400

0.1

0.2

0.3

0.4

0.5

Days of activity

Frac

tion

of P

opul

atio

n

Presence motes: N=28mean= 50, median= 52

Figure 3: Node lifetimes in the single hop network

0 20 40 60 80 100 120 1400

0.1

0.2

0.3

0.4

0.5Distribution of lifetimes in the multi hop network

Frac

tion

of P

opul

atio

n

Climate motes: N=38mean= 60, median= 63

0 20 40 60 80 100 120 1400

0.1

0.2

0.3

0.4

0.5

Days of activity

Frac

tion

of P

opul

atio

n

Presence motes: N=58mean= 29, median= 34

Figure 4: Node lifetimes in the multihop network

4

50% of the presence mote population lives for 52 daysor longer. We have met the lifetime goal for the climatemotes – motes were operational at the end of the deploy-ment. We believe the different characteristics of batteriespowering the two different kinds of devices explain this;a more detailed power usage discussion follows below.

Figure 4 shows the distribution of mote lifetimes indays in the multihop network for climate and presencemotes. Just as in the single-hop case, the presencemotes have considerably shorter lifetimes than the climatemotes: whereas over 62% of the climate mote populationlives for 63 days or longer, only 42% of the presence motepopulation lives for 34 days or longer. The multihop net-work operates for a much shorter period. This is to beexpected: the average current consumption, excluding lis-tening and packet forwarding, is estimated at 400µA, ora mere 90 days of lifetime (Table 1). However, these life-times still fall short of the predictions. To locate possiblecauses of the shortened operation, we turn to analyzingthe battery voltages during the final hours of operation.

Figure 5 shows the average voltages reported by motesduring their last three hours of operation. Mote that mayhave continued to operate but that were unable to commu-nicate successfully with the base station were consideredto have died. A threshold is highlighted on each graph thatindicates the lowest voltage at which a mote will reliablyoperate.

The passing remnant of hurricane Isabel required shut-ting down the base station between September 15th to Oc-tober 9, which produced a 23-day-long outage. The basestations were revived until October 20th when they wereshutdown for the season because of persistent early win-ter storms. Motes that ceased operation during each shut-down have their lifetimes truncated; this leads to forma-tion of indicated clusters in the scatter plot.

Figure 5 shows that of the original 21 single hop cli-mate motes, 15 are still operating at the end of the sea-son on October 20th. Improper sealing may play a partin shortening the lifespan of the 6 remaining motes. Only3 of the multihop climate motes were prematurely termi-nated because of clear battery problems. We note that theall multihop motes experience increased power consump-tion when they actively forward packets from the networkor when they overhear packets from a busy neighborhood;we attempt to quantify these issues below.

Both kinds of multihop motes show significant cluster-ing of points above the threshold voltage. If the base sta-tion was operating properly, these motes would have op-erated for another few days. This leads us to conclusionthat the shutdown had a significant impact on mean andmedian recorded lifetimes.

The presence motes also seem to run their battery toexhaustion. In the single hop case, motes drain their bat-tery thoroughly: 8 motes fall below the conservative 3Vthreshold. We observe a very sharp voltage drop at theend of battery capacity – it is possible that the remainingexperienced a drop so rapid that it was not recordable. Wediscuss a number of improvements in collection of diag-nostic information in Section 4. The multihop presence

motes exhaust their supply very rapidly. We conjecturethat it is caused by two factors: inability of battery tosource current for the long preambles and by excessiveoverhearing of other multihop traffic. We attempt to ver-ify the second hypothesis below.

3.2 Packet Delivery EffectivenessWe examine whether the packet delivery mechanisms waseffective. Recall that both single- and multihop networksused the streaming data architecture and relied on over-sampling (2x) to deliver the required sampling rates. Pre-vious studies using the same multihop routing algorithmhave indicated a 90% packet yield across a 6-hop net-work [11]. We study the packet delivery over both a shortterm and a long term and determine whether the stream-ing data approach, with no acknowledgments or retrans-missions, was sufficient. First, we note that the networkswere operating at such a low duty cycle that collisions ornetwork congestion should be insignificant.

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1Packet delivery CDF from different motes

Fraction of packets delivered per mote per day

Frac

tion

of m

otes

SH Weather, Mean: 204.00, Std Dev: 47.17, Median: 221SH Burrow, Mean: 210.97, Std Dev: 66.64, Median: 235MH Weather, Mean: 55.06, Std Dev: 10.77, Median: 57MH Burrow, Mean: 39.44, Std Dev: 15.26, Median: 42

Figure 6: Packet delivery CDF on the first day of com-plete deployment of the single-hop (June 18, 2003) andthe multihop network (August 6, 2003). multihop weathermotes had a median packet delivery of 42 packets (58%).All other motes achieved a median packet yield of over70%.

Figures 6 and 7 show the packet yields from the 4 dif-ferent kinds of motes. Figure 6 shows the packets deliv-ered to the base station during the first full day of deploy-ment of each network. The results match the expectationsbuilt up in the indoor lab environment: the climate motes,on average, deliver well over 70% of the packets. Thesingle-hop presence motes deliver similar yield. The mul-tihop presence motes perform worse (with a median yieldof 58% ), but within expectations: the application was de-signed to oversample the biological signal, and consulta-tions with biologists indicated that the delivered samplingrate would be sufficient over the long term. Figure 7 tellsa different story. It plots the CDF of the packet yields for

5

0 20 40 60 80 100 120 1402.3

2.4

2.5

2.6

2.7

2.8

2.9

3

Lifetime (days)

Vol

tage

dur

ing

last

3 h

rs (V

)

Climate motes

4 single hop, 13 multihop motes

17 single hop, 32 multihop motes

Clustering caused by base−station shutdown in Sep.

15 single hop motes stilloperate at the end of experimentat the end of Oct.

0 20 40 60 80 100 120 1402.5

3

3.5

4

Lifetime (days)

Vol

tage

dur

ing

last

3 h

rs (V

)

Presence motes

8 single hop, 11 multihop motes

11 single hop, 33 multihop motes

Single hopMulti hop

Single hopMulti hop

Figure 5: Mote voltage at the end of operation. The cutoff voltages are conservative and have been selected frombattery datasheets. The dotted and dashed trails illustrate average daily voltages from representative motes; these arein line with the discharge curves in the datasheets.

6

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1Daily packet delivery CDF from 4 kinds of motes

Fraction of packets delivered per mote per day

Frac

tion

of m

otes

SH Weather, Mean: 182.34, Std Dev: 82.69, Median: 219SH Burrow, Mean: 169.08, Std Dev: 90.24, Median: 206MH Weather, Mean: 41.20, Std Dev: 37.59, Median: 38MH Burrow, Mean: 25.49, Std Dev: 20.46, Median: 20

Figure 7: Daily packet delivery CDF over the entire lengthof the deployment. Motes in the single-hop network de-liver a median yield of 70% of packets. The multihopnetwork fares much worse, with multihop burrow nodesdelivering a median yield of just 28%.

each mote on every day that mote was active, i.e. deliv-ered a packet. The results are satisfactory for the singlehop: the median yield still remains over 70%. In contrastto Figure 6, the distribution contains many mote-days withsubstandard performance. On the first day, no mote deliv-ered fewer than 35% of its packets; over the course ofthe deployment nearly a quarter of the motes performedthat badly. The situation get even worse when we look atthe multihop network: the climate motes deliver a medianyield of a mere 28%, a performance that begins to jeop-ardize the required delivery rates. Some portion of this isdue to partial day outages at the base station, but other ef-fects are also at play. This unexpected behavior illustrateshow results from lab experiment may be optimistic in thelong term outdoor deployments.

We conclude that the simple streaming approach wassufficient in the single hop network, but fell short in themultihop case.

Next, we evaluate the effectiveness of routing. Figure 8depicts the packet yield for each multihop mote as a func-tion of mote’s average depth in the routing tree, weightedby number of packets. Recall that the multihop routingsoftware performs no retransmissions. Given that we haveobserved non-negligible packet loss in the single hop net-work, we expect to observe the same behavior per hop inthe multihop case. In turn, this behavior would producea packet yield that is a decaying exponential function ofdepth in the tree. Indeed, the data in Figure 8 shows suchbehavior. If we model the packet yieldP asld wherel islink quality andd is a packet depth, then the best fit linkquality l is 0.72 and the mean squared error is 0.03, forboth climate and presence motes. This matches closelythe mean packet delivery in the single hop network in Fig-

0 1 2 3 4 5 6 7 80

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Average depth

Packet delivery vs. network depth

Frac

tion

of p

acke

ts d

eliv

ered

Weather: 0.57*0.90depth

Burrow: 0.46*0.88depth

WeatherBurrow

Figure 8: Packets delivered v. average depth. We modelpacket delivery as a function of theAld, wherel is linkquality, d is the average depth in the routing tree, andArepresents packets lost for reasons unrelated to multihoprouting, like base station or transit network outage

ure 6 as well as the link quality data reported in [11] (0.7and 0.73 for climate and burrow, respectively), and is con-siderably better than the mean packet yield over the life-time of the single hop network.

We note that a fixed fraction of data was never recordedin the database – either because of losses in the transit net-work (with potentially different link characteristics) or be-cause of the base station outage. It is therefore appropriateto model the packet yield asAld, whereA corresponds tothat deterministic loss for all motes. The best fit param-eters curves from this model are shown in Figure 8. TheMSE using this model is 0.015 for presence motes and0.025 for climate motes. The average link quality esti-mate of nearly 0.9 shows that the routing layer is capableof picking high quality links. The deterministic lossA isvery high: 0.57 and 0.46 for climate and presence motesrespectively.

The observed packet yields make a strong case for morereliable routing subsystems. To reduce the exponentialdrop as a function of depth, a simple hop-by-hop retrans-mission strategy could be used. In addition, custody trans-fer mechanisms could be used to improve or eliminate thedeterministic loss.

3.3 Multihop network structureLow-power listening, as used in the multihop network,lowers the cost of listening, while increasing the cost ofboth transmitting and receiving. Overhearing packets isalso costly, since there is no early packet rejection. Con-sequently, the connectivity of the motes in the multihopnetwork has a large impact on the power consumption ofindividual nodes. We did not log the information aboutneighborhood sizes or packet overhearing, at best we canmake conservative estimates from the dataset. We briefly

7

analyze the structure of the multihop routing graph andpoint out opportunities for improvement.

Given their reduced power supply, the presence motesshould never be used to route packets. In the deploy-ment, we did not specifically enforce this constraint, con-sequently 48 of the presence motes were used as parentsat some point during their operation; on average thesemotes routed 75 packets, with maximum of 570 packets.While the packets routed through the presence motes werea small fraction of the overall traffic (3600 out of 120000packets), this was an optimization that would have beeneasy to implement.

Larger savings may be obtained from reducing over-hearing. We calculate the number of packets routedthrough each mote. We observe that the communicationbetween parent and child is bidirectional – the algorithmfor parent selection ensures that. Therefore we can ap-proximate the number of packets overheard by any moteby summing all packets routed throughany of the par-ents this mote selected. On average, each of the presencemotes overheard nearly 17000 packets, a significant bur-den on the limited power supply. Overhearing reductionis more complex to implement than restricted route selec-tion.

Finally, we examine the distribution of children of ev-ery node. Figure 9 shows that a large portion of the net-work – 32% – consisted of leaf nodes that never routedany packets. In a stable network topology, the leaf nodes(most of which are climate motes) can dramatically re-duce the discovery rate.

0 5 10 15 20 250

5

10

15

20

25

30

Num

ber o

f mot

es

Number of children

Properties of the routing tree

N=101Median # children=2Mean # children= 4.64

Figure 9: Distribution of children in the routing graph.

3.4 Routing StabilityLab measurements have documented routing stabilityover periods of hours. We evaluate the stability overweeks and moths in a real world deployment. Previouslypublished results, show the random fluctuations in linkquality in the real world. In addition, the logistic of the

100 101 102 103 1040

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1CDF of links and packets delivered through those links

Link Longevity (packets received)

Frac

tion

LinksPackets

Figure 10: CDFs of parent-child relationship lengths andpackets delivered through those links. Long-lived, stablelinks (ones that delivered more than 100 packets) consti-tute 15% of all links, yet they are used for more than 80%of the packets.

application – incremental installation, and node attrition –contribute significantly to parent switching.

We begin the analysis by looking at the lengths ofparent-child relationships within the routing tree. Fig-ure 10 shows a CDF of both the links and the packetsdelivered over links. Link longevity is measured as a num-ber of consecutive packets successfully delivered througha particular parent. We only count packets sourced ratherthan routed through the link since packets are sourced at afixed rate. Because of great range in the link longevity, itis more appropriate to plot it on a logarithmic scale. Mostof the links are short lived: the median link is used to de-liver only 13 packets. However, mote of the packets aretransmitted over stable stable links. We observe an 80-20 rule: 80% of the packets are delivered over less than20% of all links. These stable links last for more than 100packets – or more than a day and a half. While the distri-bution may be skewed by nodes that communicate directlywith the root of the tree, it still can be used to choose thebeaconing rates for updating routes.

Another way to look at the stability of the tree is tolook at the number of parent changes per time window.Because of the fluctuating network size, we normalize thenumber of parent changes by the number of motes activeover that particular window. Window size has a signif-icant impact on the analysis; we chose a window of 6hours, which is longer than the median longevity of thelink. Figure 11 offers a time series view of the multihopnetwork. In order to understand the stability over time,we must look at two related variables: network size andquality of data logging. Recall that the multihop networkwas installed in 3 stages, concluding with a deploymentof presence motes on August 5. Prior to presence mote

8

installation, we see a stable mote population. The parentchange rate spikes rapidly after the installation of eachmote group installation, but settles quickly thereafter. Af-ter the initial parent turnover, the network is stable; thismatches the stability results in [11]. After the deploymentof burrow motes the parent change rate remains high at 0.5for a week. This behavior is likely caused by a set of nodesfaced with a choice between a few equally good links. Thebehavior is not directly caused by changes in populationsize – a period at the end of August corresponds to a simi-lar mix of motes, is accompanied my motes disappearing,and yet the parent change rate is nearly 0. We also note ahigh turnover in the last part of the network lifetime – thisis related to the network periodically disappearing, andreappearing.

Figure 12 attempts to look at this behavior as a distribu-tion. The takeaway is that the over 55% of time intervalscorresponded to times with no changes in the links; 75%had experienced less that 0.1 parent changes per 6 hourinterval.

−0.5 0 0.5 1 1.5 2 2.50

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Parent changes/network size

Frac

tion

of ti

me

inte

rval

s

Parent change rate distribution, weighted by network size, 6 hrs interval

Figure 12: Distribution of parent change rates

4 DiscussionThis section discusses insights we have gained from thedata analysis as well as deploying and working with sen-sor networks in the field. In some cases, as in the caseof integrated data logging, we recommend functionalityfor future systems. In others, as in the case of field tools,we talk about our struggles with very primitive tools forthe on-site installation and remote monitoring of sensornetworks.

4.1 Mote DesignThe shorter lifespan of presence motes in the multihopnetwork - nearly 50% - shown in Figure 3 was surprising.The presence motes were a challenge to design and to en-gineer for damp and dirty environment. We were unable

to determine the root cause of presence mote failures al-though were able to identify a few potential factors. Inthis section we identify solutions that may assist in futuredeployments with root cause analysis.

When using batteries with a constant operating voltage,such as the lithium batteries used in our deployment, bat-tery voltage does not indicate how much capacity is re-maining. A more adequate measure of how much workhas been performed by the node is needed to calculateeach node’s expected lifetime. Since our deployment, wehave implemented energy counters at the MAC layer andin our sensing application. Each counter keeps track of thenumber of times each operation has occurred (e.g.sensing,receiving or transmitting bytes, total amount of time thecpu is active). By keeping track of this data, nodes canreport on the number of packets forwarded or overhead.We can improve our lifetime estimate through additionalhealth information from each mote. Metrics, such as theseenergy counts, are crucial to predicting the performance ofthe deployed network.

Since the presence motes were so closely integratedwith a damp volatile environment, their packaging mustprotect the internal components of the mote. With onlyexternal sensors on our mote, we were unable to detectwater breaches in the packaging. We have decided to in-clude a humidity and temperature sensor inside the motefor future platforms. The internal sensor can cause themote to notify end users of packaging failures.

4.2 Integrated DataloggingIn the current system, packets are sent without any ac-knowledgments or retransmissions. Sensor readings canbe lost at any level of the network from the node to thebase station gateway. However, nodes at each level of thenetwork could log data into local non-volatile memory asit heads towards the base station.

A protocol can attempt to incorporate data logging withreliable message delivery or custody transfer protocols toreduce data loss. For example, given 512KB of local stor-age, 64 byte sensor readings, and a sampling interval of 20minutes, each node could store 113 days of its own read-ings. This buffering could mitigate downtime at the addedexpense of buffering packets along the path. The buffer-ing is free unless the packet is writing to flash memory;writing flash memory is approximately four times morecostly than sending the message.

Integrated logging allows nodes to retain data when dis-connections occur. A node may be disconnected from an-other mote (such as a parent), the gateway, the base stationgateway, one of the base stations, or the data base service.Since large scale deployments are relatively costly, it maybe worth taking measures to retain the data if the reductionin longevity can be tolerated.

4.3 Field ToolsSensor networks are challenging to install and monitor.Currently a great deal of expertise is required to installthese networks; rather we would prefer to enable the spe-

9

07/06 07/13 07/20 07/27 08/03 08/10 08/17 08/24 08/31 09/07 09/14 09/21 09/28 10/05 10/12 10/19 10/260

50

100Time−series characteristics of the mutlihop network

07/06 07/13 07/20 07/27 08/03 08/10 08/17 08/24 08/31 09/07 09/14 09/21 09/28 10/05 10/12 10/19 10/260

0.5

1

1.5

2

07/06 07/13 07/20 07/27 08/03 08/10 08/17 08/24 08/31 09/07 09/14 09/21 09/28 10/05 10/12 10/19 10/260

0.5

1

1.5

Active nodesParent changes

Parent change−network size ratio

PC uptime fraction

Figure 11: multihop network stability over time. The top graph shows the size of the multihop network. Parent changerate is shown in the middle figure. The bottom graph shows the state of the base station logging the data. The basestation exhibits a number of outages that impact both the observed network size and the calculation of parent changerates.

10

cialist and the non-specialist alike to accomplish that eas-ily. We identify two levels of tools that provide assis-tance when deploying sensor networks: field tools that runon small, PDA-class devices and client tools that run onlarger laptops class machines situated either at the localfield station or more distantly at businesses or universitiesmany miles away. For each class, we note the functional-ity that would be useful from our own experiences in thefield.

4.3.1 Field Tools Functionality

1. Run self-check. Before placing a mote in the field,where is may not be touched again for months or years, itshould be possible to run a final self diagnostic to verifythe mote’s health. If the device is healthy, it can be leftalone, but otherwise repairs must be taken.

2. Show network neighborhood. While incrementallydeploying a network in the field, oftentimes one needs tosee whether a mote has been placed within range of therest of the network. Placement is often guided by non-networking factors, e.g., factors of biological interest.

3. Show network statistics. While within range of themote, it can be useful to query it for basic packet levelstatistics. Once a mote has joined a network, it can beuseful to monitor how well its networking subsystem isoperating before moving onto new locations.

4.3.2 Client Tools Functionality

1. Retask nodes (reprogram the sensor network). Fromtime to time, application software upgrades and patcheswill become available and it will become necessary to up-grade application software. It should be possible to do thisfrom a field station or remotely on the Internet.

2. Show who-can-hear-whom relationships. Show thegraph estimating the radio neighborhoods around eachnode as well as the routing tree currently in use for thenetwork. This is typical of the diagnostic information thattechnicians would need to monitor network operation.

3. Show when mote lasted reported in. Report wheneach mote was last heard from. This is a very common andvery useful statistic for the layperson looking for signs ofa malfunctioning mote or network.

The usefulness of these tools is proven by a large num-ber of scenarios that arose in the study area. Althoughthe spatial distribution of nodes was driven by the inter-ests of our biologist, these tools can show the density ofeach level of the multihop network. A simple GUI coulddisplay when each node was last heard from. An optionalalarming mechanism to notify on-site staff when a nodefailed to report is needed functionality for non-technicalon-site staff.

4.4 The One Touch MoteFor sensor networks to scale to hundreds and thousandsof nodes, motes can be touched just once. Assemblinga mote, programming it in a test fixture, enclosing it ina package (with no external on/off switch), positioning

it the field, and acquiring its survey GPS location is im-practical for large numbers of motes. Even the end userwho receives a complete, pre-assembled mote ready fordeployment faces usability problems of scale. Ideally,the mote should be a completely encapsulated, or pack-aged, with only the sensors exposed, a non-contact on/offswitch, and robust network booting and reprogramming.Issues of programming and network construction shouldbe handled with tools that operate on aggregates of nodesrather than individuals wherever possible.

4.5 Metadata ManagementWhen motes are deployed in the environment, they as-sume a geospatial context that is critical when interpret-ing their sensor data. Their locations potentially change;this is one form of metadata that must remain bound to themote for the duration of its lifetime. When motes are cal-ibrated, coefficients of calibration become another formof metadata that must remain bound to the device for itslifetime. Whatever the form of metadata, it is critical thatit remains bound to its mote in the presence of potentiallydisruptive events, such as being moved or being cleaned.Ambiguity will cast doubt on the data analysis.

4.6 Lessons LearnedThis remainder of this section discusses how we wouldapproach and what we would do differently in future de-ployment.

4.6.1 Deployment ToolsThe back-end infrastructure such as the transit network,base stations and relational databases were deployed be-fore the motes so that packet logs were ready to be cap-tured as soon as sensors nodes began to report in. Whendeploying new motes, it was possible to see their recordsbeing inserted into the database and thus know they werealive. This was a primitive but sufficient means of cre-ating a network when combined with the ability to issueSQL queries against the growing database. The queriesallowed one to retrieve statistics such as the network sizeand when motes were last heard from.

A variety of tools have since been developed for dataanalysis as well as network monitoring. Ideally, theseGUIs, visualizations, and statistical tools should be avail-able at deployment time as well to enrich the suite to clienttools that are available. The statistics one performs on acorpus of data, such as lifetime analysis or voltage pro-filing, may have great practical utility during phases ofnetwork construction and early days or weeks of opera-tion as well. Many of the graphs in Section 3 would beof interest to practioners deploying their own large scalesensor networks out in the field.

4.6.2 Node PackagingThere were several interdependent constraints on nodepackaging and power design. We sought a single, wa-terproof enclosure design with integrated internal batterythat was small enough for our occupancy cavity yet with

11

enough interior space to accommodate a larger batterywith more capacity for the climate motes. From these con-straints, the remaining packaging and power issues andsolutions followed. In retrospect, we can more fully ap-preciate their implications.

Rather than building semi-custom enclosure from off-the-shelf stock plastic, custom machined enclosures mayhave been advantageous and more cost effective becausethe current enclosures (1) require adhesive sealant fortruly watertight seal in harsh environments but this makesdisassembling them difficult, (2) have end caps that screwonto the enclosure but this limits how tightly they attachcompared to an assembly that uses screws, (3) have holesto accommodate the external antenna but a new designcould properly integrate an antenna into the package, (4)limit the form factors of available batteries to esoteric cellsbut a new design could make broader range of less expen-sive, high capacity cells available.

The choice of batteries reflected the requirement tofind a cell small enough for presence nodes whereas ex-tra room was available inside the climate nodes. Elec-trochems were rated at 1mA constant discharge. Whenmotes were operating, they used nearly 25mA. Two largecapacitors were added to prevent the in-rush of currentwhen coming out of sleep and the resulting voltage dropfrom resetting the mote. The climate mote could be larger,however the desire for a common enclosure strategy lim-ited the battery selection to a slightly taller and widercells.

4.6.3 Node ReclamationReclamation is an important issue facing contemporarydeployments. Because presence and climate motes aresmall, inconspicuous devices, they were easy to misplaceand to lose in the field. Even with their GPS locations,motes deployed in early spring can be difficult to find inlate fall after an entire summer’s of vegetation growth.(For this reason, it is worthwhile augmenting locations ex-perimental deployments with other markers, such as sur-vey flags.) Whether localization is an intrinsic service ofthe sensor network or part of the installation process, geo-graphic location is critical for the reclamation of nodes atthe conclusion of a deployment.

Reclamation represents another application for fieldtools where for example, it could integrate GPS, direc-tional mote antenna, and access to mote metadata like lo-cations. With such a tool, a person one could zero in ona mote, pinging and listening for responses from differ-ent angles. The prospect of littering pristine and oftenprotected habitats with nodes and lithium batteries maybe unattractive, and in some cases, may be unacceptable,too. Strong economic incentives for reclaiming nodes willremain for the foreseeable future as long as climate motescontinue to cost on the order of $400.00.

5 Related WorkThere are two fundamental differences between tradi-tional data loggers and presence and climate motes: log-

gers lack both networking and open source program-ming environments for application-specific customiza-tions. One such data logger is the Hobo Data Logger [6].Traditional data loggers can be larger and more expen-sive. They require that intrusive probes and correspondingequipment immediately adjacent. They are typically usedsince they are commercially available, supported, and pro-vide a variety of sensors. Due to size, price, and organismdisturbance, using these systems for fine-grained habitatmonitoring is inappropriate.

Other habitat monitoring studies install one or a fewsophisticated weather stations an “insignificant distance”from the area of interest. With this method, biologistscannot gauge whether the weather station actually mon-itors a different micro-climate due to its distance fromthe organism being studied. Using the readings from theweather station, biologists make generalizations throughcoarse measurements and sparsely deployed weather sta-tions. Instead, we strive to provide biologists the abilityto monitor the environment on the scale of the organism,not on the scale of the biologist [2, 8].

Habitat monitoring for WSNs has been studied by a va-riety of other research groups. Cerpa et. al. [1] proposea multi-tiered architecture for habitat monitoring. The ar-chitecture focuses primarily on wildlife tracking insteadof habitat monitoring. A PC104 hardware platform wasused for the implementation with future work involvingporting the software to motes. Experimentation using ahybrid PC104 and mote network has been done to analyzeacoustic signals [10], but no long term results or reliabil-ity data has been published. Wang et. al. [9] implementa method to acoustically identify animals using a hybridiPaq and mote network.

ZebraNet [5] is a WSNfor monitoring and trackingwildlife. ZebraNet nodes are significantly larger andheavier than motes. The architecture is designed for analways mobile, multi-hop wireless network. In many re-spects, this design does not fit with monitoring the Leach’sStorm Petrel at static positions (burrows). ZebraNet, atthe time of this writing, has not yet had a full long-termdeployment.

At UC James Reserve in the San Jacinto Mountains, theExtensible Sensing System (ESS) continuously monitorsambient micro-climate below and above ground, aviannest box interior micro-climate, and animal presence in100+ locations within a 25 hectare study area. Individualnodes with up to 8 sensors are deployed along a transect,and in dense patches, crossing all the major ecosystemsand environments found on the Reserve. The sensor dataincludes temperature, humidity, photosynthetically activeradiation (PAR), and infrared (IR) thermopile for detect-ing animal proximity.

ESS is built on TinyDiffusionn [3, 7] routing substrate,running across the hierarchy of nodes. Micro nodes col-lect low bandwidth data, and perform simple process-ing. Macro sensors organize the patches, initiate task-ing and process the sensor patch data further. They of-ten perform functions of both cluster heads and patchgateways. In case of a macro sensor failure, the rout-

12

ing layer automatically associates macro sensors with thenearest available cluster-head. The entire system is time-synchronized, and uses SMAC for low power operation.Data and timestamps are normalized and forwarded toan Internet publish-and-subscribe middleware subsystemcalled Subject Server Bus (SSB), whereby data are mul-ticast to a heterogeneous set of clients (e.g., Oracle, Mat-Lab, and LabVIEW) for processing and analysis of bothhistorical and live data streams. ESS makes an aggressiveuse of hierarchy within a patch; the diversity of sensorscan also be used for verification of data. The SSB is anoteworthy departure from the architecture in Figure 1 –it allows for natural integration of triggered features intothe system in addition to data analysis.

California redwoods are such large organisms that theirlife cycle can be measured through microclimate obser-vations. Having developed models for their metabolism,biologists are now using sensor networks to verify and re-fine these models. The sensor network measures directand incident photosynthetically active radiation (PAR),temperature, and relative humidity. In the fall of 2003,70 nodes were deployed on a representative tree in themiddle of the forest, reporting data every minute. Biolo-gists intend to grow the network to both interior and edgetrees in a grove.

The network collecting this information is an instan-tiation of the Tiny Application Sensor Kit (TASK) [4].The macro sensors in the patch run a version of TinyDBquery processing engine that propagates queries and col-lects results from a multi-hop network. There is no sepa-rate transit network – the patch bridges directly to the basestation. The base station runs a TASK server that logsdata, queries, network health statistics and keeps a jour-nal of the experiment. TASK server is capable of runningon a macro sensor. Deployment and in the field debug-ging are aided by a PDA-class device running a field tool,that allows for connectivity assessment and direct query-ing of individual sensors. To achieve low power opera-tion, the entire network is time-synchronized and duty-cycled. TASK has a health query as one of the options,which could obtain voltage, routing, neighborhood andother networking state that could facilitate the analysesin Section 3

6 ConclusionsWe have presented the system design and deployment oftwo wireless sensor networks. We deployed 150 nodesin both single- and multi-hop configurations. Duringfour months of operation, these networks produced a richdataset, valuable both to life and computer scientists.

Among the life scientists, Graphical Information Sys-tems (GIS) have become the lingua franca for the visualpresentation, analysis and exchange of geospatial data.Figure 13 shows a visualization of our study site of un-derground cavities on the left and corresponding surfaceson the right. Data for this visualization was collected frompresence and climate motes, respectively, at midnight ona typical summer evening. Darker colors correspond to

warmer temperatures, lighter colors correspond to coolertemperatures, and and shaded regions of similar colorscorrespond to isoplethic temperature regions. From thisvisualization, the effect of radiational cooling on the sur-face is apparent due to cooler temperatures, whereas thebuffering and insulating properties of the cavities causethem to maintain their a constant temperature. Hot-spotsin underground cavities are of special interest to life sci-entists, because the most likely source of heat would be anesting sea bird.

The data allows computer scientists to compare thelab benchmarks with the phenomena observed in the realworld over a period of months. In a number of cases(e.g.lifetime prediction for the single-hop network), thelab micro-benchmarks transfer well into a deployed ap-plication. In other cases, we see an interesting departurefrom the expected behavior,e.g.the lower packet yieldsfrom the multihop network. Often, these new behaviorsemerge as the network is reconfigured, expanded, or re-deployed; others are an artifact of aging. Most of thosebehaviors cannot be observed without actually construct-ing the complete system and deploying it in the field. Ouranalysis begins to extract some important characteristics,and compares them against the previously published re-sults. Ultimately, this dataset should be used to informmodels of real-world behavior; algorithms may be de-signed and tested in a lab with the characteristics of a realworld outdoor deployment.

References[1] CERPA, A., ELSON, J., ESTRIN, D., GIROD, L.,

HAMILTON , M., AND ZHAO, J. Habitat monitor-ing: Application driver for wireless communicationstechnology. In2001 ACM SIGCOMM Workshopon Data Communications in Latin America and theCaribbean(San Jose, Costa Rica, Apr. 2001).

[2] HAPPOLD, D. C. The subalpine climate at smigginholes, Kosciusko National Park, Australia, and itsinfluence on the biology of small mammals.Arctic& Alpine Research 30(1998), 241–251.

[3] HEIDEMANN , J., SILVA , F., AND ESTRIN, D.Matching data dissemination algorithms to applica-tion requirements. InACM SenSys 2003(Los Ange-les, CA, USA, Nov. 2003), ACM Press.

[4] HONG, W., MADDEN, S., FRANKLIN , M., ANDHELLERSTEIN, J. TASK: Tiny Application SensorKit. http://berkeley.intel-research.net/task/ , 2004.

[5] JUANG, P., OKI , H., WANG, Y., MARTONOSI,M., PEH, L.-S., AND RUBENSTEIN, D. Energy-efficient computing for wildlife tracking: Designtradeoffs and early experiences with ZebraNet. InProceedings of the 10th International Conference onArchitectural Support for Programming Languagesand Operating Systems (ASPLOS-X)(San Jose, CA,USA, Oct. 2002), ACM Press, pp. 96–107.

13

Figure 13: GIS map of midnight cavity (left) and surface(right) temperatures.

[6] ONSET COMPUTER CORPORATION. HOBOweather station. http://www.onsetcomp.com.

[7] OSTERWEIL, E., AND ESTRIN, D. TinyDif-fusion in the Extensible Sensing System at theJames Reserve. http://www.cens.ucla.edu/˜eoster/tinydiff/ , May 2003.

[8] TOAPANTA, M., FUNDERBURK, J., ANDCHELLEMI , D. Development of Frankliniellaspecies (Thysanoptera: Thripidae) in relation tomicroclimatic temperatures in vetch.Journal ofEntomological Science 36(2001), 426–437.

[9] WANG, H., ELSON, J., GIROD, L., ESTRIN, D.,AND YAO, K. Target classification and localizationin habitat monitoring. InProceedings of IEEE Inter-national Conference on Acoustics, Speech, and Sig-nal Processing (ICASSP 2003)(Hong Kong, China,Apr. 2003).

[10] WANG, H., ESTRIN, D., AND GIROD, L. Prepro-cessing in a tiered sensor network for habitat moni-toring. EURASIP JASP Special Issue on Sensor Net-works 2003, 4 (Mar. 2003), 392–401.

[11] WOO, A., TONG, T., AND CULLER, D. Taming theunderlying challenges of reliable multihop routing insensor networks. InACM SenSys 2003(Los Ange-les, CA, USA, Nov. 2003), ACM Press, pp. 14–27.

14