Geoffrey Werner-Allen,Konrad Lorincz,and Matt WelshHarvard University

Omar Marcillo and Jeff JohnsonUniversity of New Hampshire

Mario Ruiz and Jonathan LeesUniversity of North Carolina

Deploying a WirelessSensor Network on an Active Volcano

Augmenting heavy and power-hungry data collection equipment with lighter,

smaller wireless sensor network nodes leads to faster, larger deployments. Arrays

comprising dozens of wireless sensor nodes are now possible, allowing scientific

studies that aren’t feasible with traditional instrumentation. Designing sensor

networks to support volcanic studies requires addressing the high data rates and

high data fidelity these studies demand. The authors’ sensor-network application

for volcanic data collection relies on triggered event detection and reliable data

retrieval to meet bandwidth and data-quality demands.

Wireless sensor networks — inwhich numerous resource-limitednodes are linked via low-band-

width wireless radios — have been thefocus of intense research during the pastfew years. Since their conception, they’veexcited a range of scientific communitiesbecause of their potential to facilitate dataacquisition and scientific studies. Collab-orations between computer scientists andother domain scientists have producednetworks that can record data at a scaleand resolution not previously possible.Taking this progress one step further,wireless sensor networks can potentiallyadvance the pursuit of geophysical stud-ies of volcanic activity.

Two years ago, our team of computerscientists at Harvard University begancollaborating with volcanologists at the

University of North Carolina, the Univer-sity of New Hampshire, and the InstitutoGeofísico in Ecuador. Studying activevolcanoes typically involves sensor ar-rays built to collect seismic and infra-sonic (low-frequency acoustic) signals.Our group is among the first to study theuse of tiny, low-power wireless sensornodes for geophysical studies. In 2004,we deployed a small wireless sensor net-work on Volcán Tungurahua in centralEcuador as a proof of concept.1 For threedays, three nodes equipped with micro-phones collected continuous data fromthe erupting volcano.

In August 2005, we deployed a larger,more capable network on Volcán Reven-tador in northern Ecuador. The arrayconsisted of 16 nodes equipped with seis-moacoustic sensors deployed over 3 km.

18 MARCH • APRIL 2006 Published by the IEEE Computer Society 1089-7801/06/$20.00 © 2006 IEEE IEEE INTERNET COMPUTING

Sens

or-N

etw

ork

App

lica

tion

s

The system routed the collected data through amultihop network and over a long-distance radiolink to an observatory, where a laptop logged thecollected data. Over three weeks, our network cap-tured 230 volcanic events, producing useful dataand letting us evaluate the performance of large-scale sensor networks for collecting high-resolution volcanic data.

In contrast with existing volcanic data-acquisition equipment, our nodes are smaller,lighter, and consume less power. The resulting spa-tial distribution greatly facilitates scientific stud-ies of wave propagation phenomena and volcanicsource mechanisms. Additionally — and extremelyimportant for successful collaboration — this vol-canic data-collection application presents numer-ous challenging computer science problems.Studying active volcanoes necessitates high datarates, high data fidelity, and sparse arrays withhigh spatial separation between nodes. The inter-section of these scientific requirements with wire-less sensor network nodes’ current capabilitiescreates difficult computer science problems thatrequire research and novel engineering.

Sensor Networks for Volcanic MonitoringWireless sensor networks can greatly assist thegeophysics community. The increased scalepromised by lighter, faster-to-deploy equipmentwill help address scientific questions beyond cur-rent equipment's’ practical reach. Today’s typicalvolcanic data-collection station consists of agroup of bulky, heavy, power-hungry componentsthat are difficult to move and require car batter-ies for power. Remote deployments often requirevehicle or helicopter assistance for equipmentinstallation and maintenance. Local storage is alsoa limiting factor — stations typically log data to aCompact Flash card or hard drive, whichresearchers must periodically retrieve, requiringthem to regularly return to each station. Althoughthese limitations make it difficult to deploy largenetworks of existing equipment, such large-scaleexperiments could help us achieve importantinsights into volcanoes’ inner workings. Volcanictomography,2 for example, is one approach to thestudy of volcanoes’ interior structure; collectingand analyzing signals from multiple stations canproduce precise mappings of the volcanic edifice.In general, such mappings’ precision and accura-cy increases as stations are added to the data-col-lection network. Studies such as these could help

resolve debates over the physical processes atwork within a volcano’s interior.

The geophysics community has well-established tools and techniques it uses to processsignals extracted by volcanic data-collection net-works. These analytical methods require that ourwireless sensor networks provide data of extreme-ly high fidelity — a single missed or corrupted sam-ple can invalidate an entire record. Smalldifferences in sampling rates between two nodescan also frustrate analysis, so samples must beaccurately time stamped to allow comparisonsbetween nodes and between networks.

An important feature of volcanic signals is thatmuch of the data analysis focuses on discreteevents, such as eruptions, earthquakes, or tremoractivity. Although volcanoes differ significantly inthe nature of their activity, during our deployment,

many interesting signals at Reventador spannedless than 60 seconds and occurred several dozentimes per day. This let us design the network tocapture time-limited events, rather than continu-ous signals.

Of course, recording individual events doesn’tadequately answer all the scientific questions thatvolcanologists pose. Indeed, understanding long-term trends requires complete waveforms spanninglong time intervals. However, wireless sensor nodes’low radio bandwidth makes them inappropriate forsuch studies; thus, we focused on triggered eventcollection when designing our network.

Volcanic studies also require large internodeseparations to obtain widely separated views ofseismic and infrasonic signals as they propagate.Array configurations often comprise one or morepossibly intersecting lines of sensors, and theresulting topologies raise new challenges for sen-sor-network design, given that much previouswork has focused on dense networks in whicheach node has several neighbors. Linear configu-rations can also affect achievable network band-width, which degrades when data must be

IEEE INTERNET COMPUTING www.computer.org/internet/ MARCH • APRIL 2006 19

Deploying a Wireless Sensor Network

Studying active volcanoesnecessitates high data rates,high datafidelity, and sparse arrays with highspatial separation between nodes.

transmitted over multiple hops. Node failureposes a serious problem in sparse networksbecause a single failure can obscure a large por-tion of the network.

Sensor-Network Application DesignGiven wireless sensor network nodes’ currentcapabilities, we set out to design a data-collectionnetwork that would meet the scientific require-ments we outlined in the previous section. Beforedescribing our design in detail, let’s take a high-level view of our sensor node hardware andoverview the network’s operation. Figure 1 showsour sensor network architecture.

Network HardwareOur sensor network on Reventador comprised 16stations equipped with seismic and acoustic sen-sors. Each station consisted of a Moteiv TMoteSky wireless sensor network node (www.moteiv.com) , an 8-dBi 2.4-GHz external omnidirectionalantenna, a seismometer, a microphone, and a cus-tom hardware interface board. We fitted each of14 nodes with a Geospace Industrial GS-11 geo-phone — a single-axis seismometer with a cornerfrequency of 4.5 Hz — oriented vertically. Weequipped the two remaining nodes with triaxialGeospace Industries GS-1 seismometers with cor-ner frequencies of 1 Hz, yielding separate signalsin each of the three axes.

The TMote Sky is a descendant of the Uni-veristy of California, Berkeley’s Mica “mote” sen-

sor node. It features a Texas Instruments MSP430microcontroller, 48 Kbytes of program memory, 10Kbytes of static RAM, 1 Mbyte of external flashmemory, and a 2.4-GHz Chipcon CC2420 IEEE802.15.4 radio. The TMote Sky was designed to runTinyOS,3 and all of our software development usedthis environment. We chose the TMote Sky becausethe MSP430 microprocessor provides several con-figurable ports that easily support external devices,and the large amount of flash memory was usefulfor buffering collected data, as we describe later.

We built a custom hardware board to integratethe TMote Sky with the seismoacoustic sensors.The board features up to four Texas InstrumentsAD7710 analog-to-digital converters (ADCs), pro-viding resolution of up to 24 bits per channel. TheMSP430 microcontroller provides on-board ADCs,but they’re unsuitable for our application. First,they provide only 16 bits of resolution, whereaswe required at least 20 bits. Second, seismoa-coustic signals require an aggressive filter centeredaround 50 Hz. Because implementing such a filterusing analog components isn’t feasible, it’s usual-ly approximated digitally, which requires severalfactors of oversampling. To perform this filtering,the AD7710 samples at more than 30 kHz, whilepresenting a programmable output word rate of100 Hz. The high sample rate and computation thatdigital filtering requires are best delegated to aspecialized device.

A pair of alkaline D cell batteries powered eachsensor node — our network’s remote locationmade it important to choose batteries maximizingnode lifetime while keeping cost and weight low.D cells provided the best combination of low costand high capacity, and they can power a node formore than a week. Roughly 75 percent of thepower each node draws is consumed by the sen-sor interface board, primarily due to the ADCs’high power consumption. During our three-weekdeployment, we changed batteries on the entiresensor array only twice.

The network is monitored and controlled by alaptop base station, located at a makeshift volcanoobservatory roughly 4 km from the sensor networkitself. FreeWave radio modems using 9-dBi direc-tional Yagi antennae were used to establish a long-distance radio link between the sensor networkand the observatory.

Typical Network OperationEach node samples two or four channels of seis-moacoustic data at 100 Hz, storing the data in

20 MARCH • APRIL 2006 www.computer.org/internet/ IEEE INTERNET COMPUTING

Sensor-Network Applications

Figure 1. The volcano monitoring sensor-network architecture. Thenetwork consists of 16 sensor nodes, each with a microphoneand siesmometer, collecting seismic and acoustic data on volcanicactivity. Nodes relay data via a multihop network to a gateway nodeconnected to a long-distance FreeWave modem, providing radioconnectivity with a laptop at the observatory. A GPS receiver is usedalong with a multihop time-synchronization protocol to establish anetwork-wide timebase.

FreeWave radiomodem for long-distancecommunication to base

GPS receiverfor time sync

200-400 m

Sensor nodes

local flash memory. Nodes also transmit periodicstatus messages and perform time synchronization,as described later. When a node detects an inter-esting event, it routes a message to the base sta-tion laptop. If enough nodes report an event withina short time interval, the laptop initiates data col-lection, which proceeds in a round-robin fashion.The laptop downloads between 30 and 60 secondsof data from each node using a reliable data-collection protocol, ensuring that the systemretrieves all buffered data from the event. Whendata collection completes, nodes return to sam-pling and storing sensor data.

Overcoming High Data Rates:Event Detection and BufferingWhen designing high-data-rate sensing applica-tions, we must remember an important limitationof current sensor-network nodes: low radio band-width. IEEE 802.15.4 radios, such as the ChipconCC2420, have raw data rates of roughly 30 Kbytesper second. However, overheads caused by pack-et framing, medium access control (MAC), andmultihop routing reduce the achievable data rateto less than 10 Kbytes per second, even in asingle-hop network.

Consequently, nodes can acquire data fasterthan they can transmit it. Simply logging data tolocal storage for later retrieval is also infeasible forthese applications. The TMote Sky’s flash memoryfills in roughly 20 minutes when recording twochannels of data at 100 Hz. Fortunately, manyinteresting volcanic events will fit in this buffer. Fora typical earthquake or explosion at Reventador, 60seconds of data from each node is adequate.

Each sensor node stores sampled data in itslocal flash memory, which we treat as a circularbuffer. Each block of data is time stamped usingthe local node time, which is later mapped to aglobal network time, as we explain in the next sec-tion. Each node runs an event detector on locallysampled data. Good event-detection algorithmsproduce high detection rates while maintainingsmall false-positive rates. The detection algorithm’ssensitivity links these two metrics — a more sensi-tive detector correctly identifies more events at theexpense of producing more false positives.

The data set that our previous deployment atVolcán Tungurahua1 produced aided us in de-signing the event detector. We implemented ashort-term average/long-term average thresholddetector, which computes two exponentiallyweighted moving averages (EWMAs) with differ-

ent gain constants. When the ratio between theshort-term average and the long-term averageexceeds a fixed threshold, the detector fires. Thedetector threshold lets nodes distinguish betweenlow-amplitude signals, perhaps from distant earth-quakes, and high-amplitude signals from nearbyvolcanic activity.

When the event detector on a node fires, itroutes a small message to the base-station laptop.If enough nodes report events within a certain timewindow, the laptop initiates data collection fromthe entire network (including nodes that didn’treport the event). This global filtering preventsspurious event detections from triggering a data-collection cycle. Fetching 60 seconds of data fromall 16 nodes in the network takes roughly onehour. Because nodes can only buffer 20 minutes oferuption data locally, each node pauses samplingand reporting events until it has uploaded its data.Given that the latency associated with data collec-tion prevents our network from capturing allevents, optimizing the data-collection process is afocus of future work.

Reliable Data Transmission and Time SynchronizationExtracting high-fidelity data from a wireless sen-sor network is challenging for two primaryreasons. First, the radio links are lossy and fre-quently asymmetrical. Second, the low-cost crys-tal oscillators on these nodes have low tolerances,causing clock rates to vary across the network.Much prior research has focused on addressingthese challenges.4,5

We developed a reliable data-collection proto-col, called Fetch, to retrieve buffered data fromeach node over a multihop network. Samples arebuffered locally in blocks of 256 bytes, then taggedwith sequence numbers and time stamps. Duringtransmission, a sensor node fragments eachrequested block into several chunks, each of whichis sent in a single radio message. The base-stationlaptop retrieves a block by flooding a request tothe network using Drip, a variant of the TinyOSTrickle6 data-dissemination protocol. The requestcontains the target node ID, the block sequencenumber, and a bitmap identifying missing chunksin the block.

The target node replies by sending the request-ed chunks over a multihop path to the base station.Our system constructs the routing tree using Multi-HopLQI, a variant of the TinyOS MintRoute4 rout-ing protocol modified to select routes based on the

IEEE INTERNET COMPUTING www.computer.org/internet/ MARCH • APRIL 2006 21

Deploying a Wireless Sensor Network

CC2420 link quality indicator (LQI) metric. Link-layer acknowledgments and retransmissions ateach hop improve reliability. Retrieving oneminute of stored data from a two-channel sensornode requires fetching 206 blocks and can takeseveral minutes to complete, depending on themultihop path’s quality and the node’s depth in therouting tree.

Scientific volcano studies require sampled datato be accurately time stamped; in our case, a glob-al clock accuracy of ten milliseconds was suffi-cient. We chose to use the Flooding TimeSynchronization Protocol (FTSP),5 developed atVanderbilt University, to establish a global clockacross our network. FTSP’s published accuracy isvery high, and the TinyOS code was straightfor-ward to integrate into our application. One of thenodes used a Garmin GPS receiver to map theFTSP global time to GMT. Unfortunately, FTSPoccasionally exhibited unexpected behavior, inwhich nodes would report inaccurate global times,preventing some data from being correctly timestamped. We’re currently developing techniques tocorrect our data set’s time stamps based on thelarge amount of status messages logged from eachnode, which provide a mapping from the localclock to the FTSP global time.

Command and ControlA feature missing from most traditional volcanicdata-acquisition equipment is real-time networkcontrol and monitoring. The long-distance radiolink between the observatory and the sensor net-work lets our laptop monitor and control the net-work’s activity. We developed a Java-based GUI formonitoring the network’s behavior and manuallysetting parameters, such as sampling rates andevent-detection thresholds. In addition, the GUI wasresponsible for controlling data collection follow-ing a triggered event, moving significant complex-ity out of the sensor network. The laptop logged allpackets received from the sensor network, facilitat-ing later analysis of the network’s operation.

The GUI also displayed a table summarizingnetwork state, based on the periodic status mes-sages that each node transmitted. Each table entryincluded the node ID; local and global timestamps; various status flags; the amount of local-ly stored data; depth, parent, and radio link qual-ity in the routing tree; and the node’s temperatureand battery voltage. This functionality greatlyaided sensor deployment by letting a team mem-ber rapidly determine whether a new node had

joined the network as well as the quality of itsradio connectivity.

Deploying on Volcán ReventadorVolcán Reventador is located in northern Ecuador,roughly three hours from the capital, Quito. Longdormant, Reventador reawakened suddenly in2002, erupting with massive force. Ash thrown intothe air blanketed Quito’s streets 100 kilometers tothe east, closing schools and the airport. Pyroclas-tic flows raced down the mountain, flatteningforests, displacing an oil pipeline, and severing amajor highway. After 18 months of quiescence,renewed activity began in November 2004. Duringour deployment, Reventador’s activity consisted ofdiscrete, relatively small explosive events thatejected incandescent blocks, gas, and ash severaltimes a day. Corresponding seismic activity includ-ed explosion earthquakes, extended-durationshaking (tremors), and shallow-rock-fracturingearthquakes that might have been associated withmagma migration within the volcano.

Several features of Volcán Reventador made itideal for our experiment. Reaching 3,500 meters atits peak, Reventador sits at a low elevation com-pared to other Ecuadorean volcanoes, makingdeployment less strenuous. Its climate is moderate,with temperatures ranging between 10 and 30degrees Celsius. The 2002 explosion producedpyroclastic flows that left large parts of the flanksdenuded of vegetation. Given that our radio anten-nas’ effectiveness can be severely degraded byobstacles to line-of-sight, the lack of vegetationgreatly simplified sensor-node positioning.

Our base while working at Reventador was theHosteria El Reventador, a small hotel locatednearby on the highway from Quito to Lago Agria.The hotel provided us with space to set up ourequipment and ran an electric generator thatpowered our laptops and other equipment at themakeshift observatory.

Sensor-Network Device Enclosures and Physical SetupA single sensor network node, interface board, andbattery holder were all housed inside a smallweatherproof and watertight Pelican case, as Fig-ure 2 shows. We installed environmental connec-tors through the case, letting us attach cables toexternal sensors and antennae without openingthe case and disturbing the equipment inside. Forworking in wet and gritty conditions, these exter-nal connectors became a tremendous asset.

22 MARCH • APRIL 2006 www.computer.org/internet/ IEEE INTERNET COMPUTING

Sensor-Network Applications

Installing a station involved covering the Pel-ican case with rocks to anchor it and shield thecontents from direct sunlight. We elevated theantennae on 1.5-meter lengths of PVC piping tominimize ground effects, which can reduce radiorange. We buried the seismometers nearby, but farenough away that they remained undisturbed byany wind-induced shaking of the antenna pole.Typically, we mounted the microphone on theantenna pole and shielded it from the wind andelements with plastic tape. Installation took sever-al minutes per node, and the equipment was suf-ficiently light and small that an individual couldcarry six stations in a large pack. The PVC poleswere light but bulky and proved the most awkwardpart of each station to cart around.

Network Location and TopologyWe installed our stations in a roughly linear con-figuration that radiated away from the volcano’svent and produced an aperture of more than threekilometers. We attempted to position the stationsas far apart as the radios on each node wouldallow. Although our antennae could maintainradio links of more than 400 meters, the geogra-phy at the deployment site occasionally requiredinstalling additional stations to maintain radioconnectivity. Other times, we deployed a nodeexpecting it to communicate with an immediateneighbor but later noticed that the node wasbypassing its closest companion in favor of anode closer to the base station. Most nodes com-municated with the base station over three orfewer hops, but a few were moving data over asmany as six.

In addition to the sensor nodes, we used sever-al other pieces of equipment. Three Freewave(www.freewave.com) radio modems provided along-distance, reliable radio link between the sen-sor network and the observatory laptop. Each Free-wave required a car battery for power, rechargedby solar panels. A small number of Crossbow(www.xbow.com) MicaZ sensor network nodesserved supporting roles. One interfaced betweenthe network and the Freewave modem and anoth-er was attached to a GPS receiver to provide aglobal timebase.

Early ResultsWe deployed our sensor network at Volcán Reven-tador for more than three weeks, during whichtime we collected seismoacoustic signals from sev-eral hundred events. We’ve only just begun rigor-

ously analyzing our system’s performance, butwe’ve made some early observations.

In general, we were pleased with our systems’performance. During the 19-day deployment, weretrieved data from the network 61 percent of thetime. Many short outages occurred because — dueto the volcano’s remote location — powering thelogging laptop around the clock was often impos-sible. By far the longest continuous network out-age was due to a software component failure,which took the system offline for three days untilresearchers returned to the deployment site toreprogram nodes manually.

Our event-triggered model worked well. Dur-ing the deployment, our network detected 230eruptions and other volcanic events, and loggednearly 107 Mbytes of data. Figure 3 shows an

IEEE INTERNET COMPUTING www.computer.org/internet/ MARCH • APRIL 2006 23

Deploying a Wireless Sensor Network

Figure 2. A two-component station. The bluePelican case contains the wireless sensor node andhardware interface board. The external antenna ismounted on the PVC pole to reduce groundeffects. A microphone is taped to the PVC pole,and a single seismometer is buried nearby.

example of a typical earthquake our networkrecorded. By examining the data downloaded fromthe network, we verified that the local and globalevent detectors were functioning properly. As wedescribed, we disabled sampling during data col-lection, implying that the system was unable torecord two back-to-back events. In some instances,this meant that a small seismic event would trig-ger data collection, and we’d miss a large explo-sion shortly thereafter. We plan to revisit ourapproach to event detection and data collection totake this into account.

Our deployment raises many exciting directionsfor future work. We plan to continue improv-

ing our sensor-network design and pursuingadditional deployments at active volcanoes. Thiswork will focus on improving event detection andprioritization, as well as optimizing the data-collection path. We hope to deploy a much larg-er (100-node) array for several months, withcontinuous Internet connectivity via a satelliteuplink. We’re collaborating with the SensorWebsproject at NASA and the Jet Propulsion Lab toallow our ground-based sensor network to trig-ger satellite imaging of the volcano after a largeeruption. We assembled equipment required totest this idea at Reventador, but were unable toestablish a reliable Internet connection at thedeployment site via satellite.

A more ambitious research goal involvessophisticated distributed data-processing within thesensor network itself. Sensor nodes, for example,can collaborate to perform calculations of energyrelease, signal correlation, source localization, andperhaps tomographic imaging of the volcanic edi-fice. By pushing this computation into the network,we can greatly reduce the radio bandwidth require-ments and scale up to much larger arrays. We’reexcited by the opportunities that sensor networkshave opened up for geophysical studies.

References

1. G. Werner-Allen et al., “Monitoring Volcanic Eruptions

with a Wireless Sensor Network,” Proc. 2nd European

Workshop Wireless Sensor Networks (EWSN 05), IEEE

Press, 2005; www.eecs.harvard.edu/~mdw/papers/volcano

-ewsn05.pdf.

2. J.M. Lees, “The Magma System of Mount St. Helens: Non-

linear High Resolution P-Wave Tomography,” J. Volcanic

and Geothermal Research, vol. 53, nos. 1–4, 1992, pp.

103–116.

3. J. Hill et al., “System Architecture Directions for Networked

Sensors,” Proc. 9th Int’l Conf. Architectural Support for

Programming Languages and Operating Systems, ACM

Press, 2000, pp. 93–104.

4. A. Woo, T. Tong, and D. Culler, “Taming the Underlying

Challenges of Reliable Multihop Routing in Sensor Net-

works,” Proc. 1st ACM Conf. Embedded Networked Sensor

Systems (SenSys 03), ACM Press, 2003, pp. 14–27.

5. M. Maroti et al., “The Flooding Time Synchronization Pro-

tocol,” Proc. 2nd ACM Conf. Embedded Networked Sensor

Systems, ACM Press, 2004, pp. 39–49.

6. P. Levis et al., “Trickle: A Self-Regulating Algorithm for

Code Propagation and Maintenance in Wireless Sensor

Networks,” Proc. 1st Usenix/ACM Symp. Networked Sys-

tems Design and Implementation (NSDI 04), Usenix Assoc.,

2004, pp. 15–28.

Geoffrey Werner-Allen is a second-year PhD candidate in com-

puter science in the Division of Engineering and Applied

Science at Harvard University. His research interests

include wireless sensor networks, biologically inspired and

distributed algorithms, tool development, and software

engineering. Werner-Allen has an AB in physics from Har-

vard University. He is a student member of the ACM. Con-

tact him at werner@eecs.harvard.edu; www.eecs.harvard.

edu/~werner.

Konrad Lorincz is a fourth-year PhD candidate in computer sci-

ence at Harvard University. His research interests include

distributed systems, networks, wireless sensor networks,

location tracking, and software engineering. Lorincz has

24 MARCH • APRIL 2006 www.computer.org/internet/ IEEE INTERNET COMPUTING

Sensor-Network Applications

Figure 3. An event captured by our network. The event shownwas a volcano tectonic (VT) event and had no interesting acousticcomponent. The data shown has undergone several rounds ofpostprocessing, including timing rectification. We show onlyseismic signals.

Nod

e ID

204213208206209207200201250203202205212210251214

04:07:10 04:07:20 04:07:30 04:07:40Time (UTC)

04:07:50

an MS in computer science from Harvard University. Con-

tact him at konrad@eecs.harvard.edu; www.eecs.harvard.

edu/~konrad.

Mario Ruiz is an associate professor at the Escuela Politecnica

Nacional and a third-year PhD student at the University of

North Carolina, Chapel Hill. His research field is volcano

seismology. Ruiz has an MS in geophysics from the New

Mexico Institute of Technology. Contact him at mruiz@

email.unc.edu.

Omar Marcillo is a graduate student in the Department of Earth

Sciences at the University of New Hampshire. His primary

research interest is the development of instrumentation for

volcano monitoring and geophysical studies. Contact him

at oed4@unh.edu.

Jeff Johnson is a research assistant professor of geophysics and

volcanology in the Department of Earth Sciences at the

University of New Hampshire. His research interests

include eruption dynamics and volcano monitoring. John-

son has an MS from Stanford and a PhD in geophysics

from the University of Washington. He is an active mem-

ber of the American Geophysical Union and Seismologi-

cal Society of America and the International Association

of Volcanology and Chemistry of the Earth’s Interior. Con-

tact him at jeff.johnson@unh.edu; http://earth.unh.edu/

johnson/johnson.htm.

Jonathan Lees is an associate professor in the Department of

Geological Sciences at the University of North Carolina,

Chapel Hill, where he specializes in geophysics, seismology

and volcanology. His research is directed toward under-

standing the dynamics of volcanic explosions as they relate

to the shallow conduit system as well as the deep plumb-

ing structure of the volcano edifice. Lees has a PhD in geo-

physics from the University of Washington. He is an active

member of the American Geophysical Union, the Society

of Exploration Geophysicists, and the Seismological Soci-

ety of America. Contact him at jonathan_lees@unc.edu;

www.unc.edu/~leesj.

Matt Welsh is an assistant professor of computer science at

Harvard University. His research interests include operat-

ing system, network, and programming-language support

for massive-scale distributed systems, including Internet

services and sensor networks. Welsh has a PhD in comput-

er science from the University of California, Berkeley. He

is a member of the ACM and the IEEE. Contact him at

mdw@eecs.harvard.edu; www.eecs.harvard.edu/~mdw.

IEEE INTERNET COMPUTING www.computer.org/internet/ MARCH • APRIL 2006 25

Deploying a Wireless Sensor Network