Real-World Sensor Network for Long-Term Volcano …sensorweb.engr.uga.edu/wp-content/uploads/2016/08/...and evaluation of a real-world sensor network system for long-term volcano hazard

1

Real-World Sensor Network for Long-TermVolcano Monitoring: Design and Findings

Renjie Huang, Wen-Zhan Song, Mingsen Xu, Nina Peterson, Behrooz Shirazi, Richard LaHusen

Abstract—This paper presents the design, deployment and evaluation of a real-world sensor network system in an active volcano -Mount St. Helens. In volcano monitoring, the maintenance is extremely hard and system robustness is one of the biggest concerns.However, most system research to date have focused more on performance improvement and less on system robustness. In oursystem design, to address this challenge, automatic fault detection and recovery mechanisms were designed to autonomously roll thesystem back to the initial state if exceptions occur. To enable remote management, we designed a configurable sensing and flexibleremote command and control mechanism with the support of a reliable dissemination protocol. To maximize data quality, we designedevent detection algorithms to identify volcanic events and prioritize the data, and then deliver higher priority data with higher deliveryratio with an adaptive data transmission protocol. Also, a light-weight adaptive linear predictive compression algorithm and localizedTDMA MAC protocol were designed to improve network throughput. With these techniques and other improvements on intelligenceand robustness based on a previous trial deployment, we air-dropped 13 stations into the crater and around the flanks of Mount St.Helens in July 2009. During the deployment, the nodes autonomously discovered each other even in-the-sky and formed a smart meshnetwork for data delivery immediately. We conducted rigorous system evaluations and discovered many interesting findings on dataquality, radio connectivity, network performance, as well as the influence of environmental factors.

Index Terms—Real-world Sensor Network, Volcano Monitoring, System Design, Field Deployment, Evaluation and Findings

F

1 INTRODUCTIONWireless sensor networks have been attracting increasedinterest from the research community for a broad rangeof applications [17]. Wireless sensor networks have thepotential to greatly enhance the understanding of vol-cano hazards by permitting large distributed deploy-ments of sensor nodes in difficult-to-reach or hazardousareas [16]. Wireless networking allows sensor nodes tocommunicate with each other and to a central base sta-tion via a self-healing mesh network, allowing intelligentreal-time data reduction, data archival, as well as the re-tasking of the array after deployment. In remote volcanomonitoring, there is typically no infrastructure availableand maintenance is extremely hard. The sensor networkmust be able to run continuously with zero-maintenancefor a long period in a hostile volcanic environment.

In this paper, we present the design, deploymentand evaluation of a real-world sensor network systemfor long-term volcano hazard monitoring. Our sensornetwork has been deployed and tested on Mount St.Helens since July 2009, as part of the Optimized Au-tonomous Space In-situ Sensorweb (OASIS) [1] system.

• Wen-Zhan Song and Mingsen Xu are with Sensorweb Research Labora-tory, Georgia State University.E-mail: [email protected], [email protected]

• Renjie Huang, Nina Peterson and Behrooz Shirazi are with WashingtonState University.E-mail: {renjie huang, npicone, shirazi}@wsu.edu

• Richard LaHusen is with Cascades Volcano Observatory, U.S.GeologicalSurvey.Email: [email protected]

• Our research is partially supported by NASA-ESTO-NNX06AE42G,NSF-CNS-0914371, NSF-CNS- 0953067.

The OASIS is a prototype system that provides sci-entists and decision-makers with a tool composed ofa smart ground sensor network integrated with smartspace-borne remote sensing assets to enable promptassessments of rapidly evolving geophysical events in avolcanic environment. This paper describes the designand deployment of ground sensor networks. In 2008,we conducted a trial deployment [16] with 5 stations asa proof-of-concept with basic functions including UTC-time synchronized data acquisition, agile data collectionrouting, and reliable command dissemination. Learninglessons from that deployment, we have significantlyimproved the system functions and intelligence, andsuccessfully conducted a larger scale deployment intothe crater and around the flank of Mount St. Helens inJuly 2009. In this paper, we comprehensively review oursystem design and deployment experience and lessons,especially after trial deployment [16].

The rest of this paper is organized as follows. Section 2presents the system architecture of our field deploymenton Mount St. Helens. Section 3 describes the hardwaredesign of sensor nodes. Section 4 and Section 5 presentthe software design. Section 6 presents the rigorous sys-tem evaluation and various interesting findings. Finally,we discuss related works in Section 7 and conclude thepaper in Section 8 by pointing out our future work.

2 SYSTEM OVERVIEWFigure 1 illustrates the end-to-end configuration of thefull OASIS system. The ground sensor network deliveredreal-time volcanic signals to the sink nodes at JRO (John-ston Ridge Observatory) through multi-hop relays. The

2

802.15.4Microwave

ethernet bridge

Mount St Helens

V-alarmSerialforwarder

(At WSU vancouver)

50 miles

Valve Database

Command & Control

EO-1 Satellite

Web access

Fig. 1. The system configuration of OASIS

Fig. 2. The deployment map of 13 nodes on Mount St.Helens Volcano. The sink nodes 0 and 7 are placed atJRO.

sink nodes are connected to the gateway through serialconnection. The gateway (MOXA device server DE-304)relayed the data stream to a WSUV server through a mi-crowave link of 50 miles. In the lab, a customized TinyOStool SerialForwarder in WSUV server forwards the databetween the sensor network and the Internet. Multiplecontrol clients may connect to it, access the sensor datastream, and control the network in real time. V-alarm is avolcano activity alarm system, which can automaticallyidentify earthquake events from the raw data stream.Once an event is triggered, V-alarm can send eventalerts via email or text messages to the correspondingscientists in charge. The Command & Control center isfor situation awareness and integration of in-situ sensornetwork and space observations from EO-1 satellite. Itincorporates existing real-time volcano monitoring anddata-processing tools used by the USGS (U.S. GeologicalSurvey) and makes real-time autonomous operationaldecisions to control the sensor network according to localand remotely sensed environmental changes.

The real-time data stream from seismic, infrasonic,lightning, and GPS sensors, as well as RSAM, batteryvoltage and RSSI/LQI data, are imported into a MYSQLdatabase with UTC timestamps of millisecond resolu-tion. In connection with the database, a web appli-cation VALVE [2] was developed to display not only

current, but also historical data to a large number ofdistributed users. Our database is well integrated withUSGS’s science analysis software (e.g. VALVE) to man-age and visualize the volcano monitoring data. VALVE(Volcano Analysis and Visualization Environment) isa on-demand client/server system for visualization ofserving, graphing, and mapping nearly every type ofhistorical data collected by the sensor network. It greatlyfacilitates our analysis of the data quality and networkstatus. Our data is shared with the community throughthe VALVE web client. It allows users to visualize ordownload the volcanic data of a specific period fromany location on the Internet. The system collected about60 GB volcanic data in the first 6 months during thedeployment.

3 HARDWARE DESIGN

The hardware design of the OASIS station has consid-ered various environmental challenges in volcano hazardmonitoring with the direct involvement of experiencedUSGS engineers. Figure 3 shows the OASIS station.A wireless mote iMote2 is the core of OASIS station.iMote2’s PXA271 processor is configured to operate in alow voltage (0.85 V) and low frequency (13 MHz) mode.Each station contains a GPS receiver (U-Blox LEA-4T L1)to pinpoint the exact location and measure subtle grounddeformation, a seismometer to detect earthquakes, aninfrasonic sensor to detect volcanic explosions, and alightning sensor to detect eruption clouds. The accuracyof the GPS receiver’s time pulse is up to 50 ns providingaccurate timing for TDMA and data timestamp. Theinfrasonic sensor (All Sensor Model 1 INCH-D-MV) isa low range differential pressure sensor to record lowfrequency acoustic waves generated during explosiveevents. Lightning typically accompanies heavy ash emis-sions, so lightning is a useful parameter for monitor-ing volcanic activity. In this deployment, we used twotypes of seismometers: low-cost MEMS accelerometer(Silicon Designs Model 1221J-002) and geophone sensor(Geospace HS-1). The geophone sensor has been usedas a seismometer by USGS and has ultra low noiselevel. However, they are difficult to be deployed sincethey must be hand-placed in a perfect vertical position.

3

The accelerometer sensor is suitable for fast air-dropdeployment, but it has higher noise level comparedto the geophone sensor. The measured average energyconsumption of the OASIS station is about 375 mW.Powered by AIR-ALKALINE batteries of 1200 Ah Capac-ity at a voltage of 3V, the estimated lifetime of the OASISstation is about 400 days. The station communicates witheach other via a 802.15.4 radio.

Fig. 3. The whole OASIS station.

Learning lessons from the trial deployment [16] in2008, we upgraded the radio amplifier and added alightning protector. We originally used the 2.4 GHz bi-directional Amplifier SmartAmp to increase the trans-mission range. However, it does not work well becausethe required minimum TX input power is 0 dBm, whilethe output power from the iMote2 mote is typicallyabout −3 dBm after attenuation of connector. Moreover,the current consumption power of SmartAmp is as highas 540 mA in TX mode and 60 mA in RX mode at 7.5V. To meet the energy requirement of one-year unat-tended operation, we built the amplifier customized forOASIS using a cost-effective and high performance RFfront end CC2591. The current consumption of CC2591in TX and RX mode are typically 100 mA and 1.7mA at 3 V respectively, while obtaining similar gainscompared to SmartAmp. We added a coaxial lightingarrestor (NextTek Surgeguard) to reflect the lightningenergy after we found that lightning strikes can destroythe amplifier. In addition, in previous deployment a900 MHz Freewave radio modem connected the sinkstation to the gateway over a 6-mile radio link. Laterthe field test showed that the 802.15.4 radio with ourcustomized amplifier can achieve similar transmissionrange, so the 900 MHz Freewave radio was removedfrom the hardware configuration to conserve energy.

4 ROBUSTNESS AND REMOTE NETWORKMANAGEMENT

To survive unforeseen software faults, our sensor nodeautomatically detects and self-recovers from softwarefailures. Also, considering the longevity and remotenessof environmental monitoring, online reconfiguration of

the network and motes is highly desirable for systemmanagement. Thus, we developed a comprehensive re-mote network management mechanism that providesinteractions between users and the network in the field.

4.1 Automatic Fault Detection and RecoveryAll of our nodes are in rugged terrain and only reach-able by helicopter. The field maintenance is difficult,if not impossible. Thus, software dependability andreliability is a major concern. Nasty bugs may occurafter deployments [7], [20]. It is, therefore, crucial tohave an exception-handling mechanism to recover nodesautomatically from software and hardware failures. Weexploited the benefits of watchdog. The iMote2’s hard-ware watchdog can restart the node under exceptionssuch as dead loop, memory errors, and stack overflow.In addition, software failures can also be caused byunexpected logic errors. For example, corrupted packetsmay result in time desynchronization, and corruption ofcommunication protocols. We further developed a soft-ware watchdog to enable self-recovery from erroneousstates. Each node monitors the most important internallogic states and calls a command to reboot by stoppingthe watchdog timer when it detects erroneous states.However, the reboot operation will cause a node to dis-card its system state information in memory. To reducethe reboot cost to the minimum, important parametersand states, such as sampling rate and RF channel/power,are written to Flash when configured by remote users,and are restored once a node reboots. With those faulttolerant mechanisms, our system is able to continuouslyoperate normally after the deployment.

4.2 Remote Command and ControlThe remote command and control is based on a flex-ible Remote Procedure Call (RPC) mechanism [22]. Itallows a PC to access the exported functions and anyglobal variables of a statically-compiled program onsensor nodes at run time. To ensure the reliable dis-semination of RPC messages over multi-hop paths, wehave designed a reliable data dissemination protocolCascades [12]. The RPC mechanism gives users greatflexibility to read/write system variables and run anyexported functions. Operations such as set/get samplingrate, beacon interval, power level, radio channel, andevent report level threshold are provided to remoteclients. The RPC mechanism also provides visibility intonetwork failures and helps to correct bugs.

4.3 Configurable SensingAs an instrument to enhance scientific explorations, theOASIS stations are designed to be smart and config-urable with the sensing parameters adjustable based onenvironmental conditions and mission needs. Our sensordriver performs synchronized sampling operation andmaintains sensing parameters, such as sampling rate,

4

ADC channel, and data priority. All these parameterscould be tuned according to environmental and resourcesituations to conserve energy or increase fidelity. Whenenergy conservation becomes a priority, users can re-motely close a non-critical data channel by simply settingthe sampling rate to 0. Currently, we collect all raw datafor scientific analysis, but users also can change the basedata priority to 0, then the OASIS station will send outevent data only. If a sensor is broken or the hardwareinterface is disconnected, its channel can be closed tosave energy and bandwidth.

Besides the configurable parameters, it is also use-ful to configure the data processing tasks for differentdata types. To support this, each processing algorithmis indexed in a task queue through function pointers.Each data block is associated with a taskCode, indicatingthe processing tasks to be performed on the raw datasamples. By configuring the taskCode, users can flexiblyalter the in-network processing for a specific data typeon specific nodes. With this mechanism, we can remotelychoose to run different event detection and compressionalgorithms on different types of data without reprogram-ming the nodes.

4.4 Over-the-air Network ReprogrammingAfter a field deployment, the network functionality mayneed improvement or fix new software failures. Thus,it is important to support remote software upgrades.Deluge is the de facto network reprogramming protocolthat provides an efficient method for disseminating codeupdate over the wireless network and having each nodeprogram itself with the new image. Deluge originallydoes not support the iMote2 platform, and it is nottrivial to port it to support the iMote2 platform [11](see supplement). We also improve Deluge to ensurethat it could handle some adverse situations. (1) Im-age integrity verification. If a node reboots during thedownload phase, we have to ensure it correctly resumesthe download. To address this issue, we implemented amechanism where we verify the image integrity duringstartup. If the image has been completely downloaded,then we continue with the normal operations; otherwisewe erase the entire downloaded image and reset themeta data to enable a fresh re-download. (2) Imageversion consistency. The original Deluge is based onsequence number. However, if the gateway lost track ofthe sequence number and did not use a higher sequencenumber, then Deluge will not respond to new requestof code update. We fixed this problem by using thecompilation timestamp to differentiate new image fromold image.

5 QUALITY-AWARE DATA COLLECTION

For such a high data rate application, a key challengeis how to collect the high-fidelity data subject to thelimited bandwidth available to sensor nodes. Adaptivedata transmission protocols were designed to ensure

higher priority data with higher reliability. Additionally,light-weighted compression and localized TDMA MACprotocol was designed to improve network throughput.

5.1 Priority-aware Data Delivery

In the volcano network, the sensor data is not equally im-portant; thus, we need to treat the data accordingly andcontrol the Quality of Service (QoS). Firstly, we used theSTA/LTA (short-term average over long-term average)algorithm [25], [26] to detect seismic events and assignthose event data with higher priority. More details aboutthis algorithm can be found in the supplement. Then,we designed a Tiny-Dynamic Weighted Fair Queueingalgorithm (Tiny-DWFQ) [13] to assign proper QoS foreach packet based on the data priorities and networksituations. Once the QoS is assigned, Tiny-DWFQ en-sures that the packets are sent throughout the networkin a way that the desired QoS requirements are upheld.The dynamic nature of Tiny-DWFQ is exemplified in theassignment of the priority of each packet, called the Dy-namic Weighted Priority (DWP). The DWP is a weightedcombination of the node and data priorities assignedbased on the current context of the environment. Once apacket has been assigned a DWP, it must be scheduledin accordance with its DWP and the current networkcongestion level. The Tiny-DWFQ algorithm ensures thatthe high priority packets are transmitted, even in themidst of congestion.

5.2 Reliable Event Data Collection

Seismic event and RSAM data are important for volcanostudies, and volcanologists expect them to be reliablycollected. Thus, we developed a Reliable Data Transfer(RDT) protocol, on top of the priority-aware data deliv-ery approach in section 5.1. Notice that, the resource andsystem constraints of sensor network demand a light-weighted design, where TCP [24] can not be directlymigrated. Firstly, the bandwidth is severely constrainedand may be insufficient to deliver all seismic and RSAMevent data during some active periods. Secondly, thefeedback traffic from the data server to sensor nodesshall be as few as possible. The feedback control trafficdirectly competes the bandwidth of sensor data trafficdue to the radio broadcast nature. When the bandwidthis severely limited, the data delivery with RDT couldbe worse than that without RDT. Realizing those newsystem challenges, we made several innovative designchoices as described in the supplement.

5.3 Network Throughput Improvement

Existing low power MAC protocols, such as B-MAC [14],are designed for low duty cycle applications. To providehigh channel capacity utilization and low congestionratio, we developed a new TDMA MAC protocol calledTreeMAC [15] to regulate the channel access. The design

5

of TreeMAC is based on a key observation of multi-hop data collection networks: the bandwidth allocationof any node shall be no less than that of its subtree,so that the nodes closer to the sink have enough band-width to forward data packets for the nodes in itssubtree. TreeMAC divides a time cycle into multipleframes and each frame into 3 slots. Parent nodes assignnon-overlapping frames to their children nodes basedon their proportional bandwidth demands. Each nodecalculates its own slot assignment based on its hop-count to the sink. This innovative 2-dimensional frame-slot assignment algorithm has the following nice theoryproperties. Firstly, given any node, at any time slot,there is at most one active sender in its neighborhood(including itself). Secondly, the packet scheduling withTreeMAC is bufferless, which therefore minimizes theprobability of network congestion. Thirdly, the datathroughput to the gateway is at least 1/3 of the optimumassuming reliable links.

To reduce the bandwidth demands and maximize thedata return over the unreliable and low rate radio links,we designed an Adaptive Linear Filtering Compression(ALFC) [9] algorithm to compress the seismic raw data.It is a lightweight compression algorithm tailored forsensor networks with code size only 768 bytes. Con-sidering the relatively modest computational power ofexisting sensor platforms, ALFC does not use floating-point operations and has very low computation andenergy cost. More details about ALFC are presented inthe supplement.

6 SYSTEM EVALUATION AND FINDINGS

After the deployment, we have conducted rigorous sys-tem evaluations and discovered many interesting find-ings on data quality, radio connectivity, network perfor-mance, as well as the influence of environmental factors.Due to space limit, additional system evaluation andfindings can be found in the supplement.

6.1 Data Quality EvaluationOne important aspect of evaluating a real-world sensornetwork system is the data quality. To assess the qualityof our data we compared it with that from broadbandstation VALT, which is the state-of-the-art instrumentin seismology. VALT sits inside the crater of Mount St.Helens volcano, and is the closest to OASIS node 1. Theanalog-to-digital converter for VALT station is 24 bitswhile that of our OASIS stations is 16 bits. To comparethe SNR between VALT station with OASIS node 1, wescaled the seismic reading from VALT by 1

256 (e.g., from24-bit to 16-bit). Figure 4 shows 50-minute seismic rawreading from OASIS node 6, node 1, and VALT stationduring the time period from UTC 07/20/2009 18:20 toUTC 07/20/2009 19:10. After scaling, the noise level ofVALT and OASIS station is almost the same. We can seethat the OASIS station with geophone seismic sensor canachieve similar data quality. It is worth mentioning that

32800

32900

33000

33100

33200

33300

33400

07/20/09 18:20 18:30 18:40 18:50 19:00 19:10

Counts

Time

31600

31700

31800

31900

32000

32100

32200

07/20/09 18:20 18:30 18:40 18:50 19:00 19:10

Readin

g

Time

Node 1

-80000-60000-40000-20000

0 20000 40000 60000 80000

07/20/09 18:20 18:30 18:40 18:50 19:00 19:10

Readin

g

Time

VALT

Fig. 4. Comparison of the seismic waveform data.

the seismic sensor of the broadband station costs about$10, 000 ($25, 000 for the whole station), while the OASISstation only costs about $3000 (including radios andother sensors). In addition, the deviation of the noisesof OASIS node 6 is much higher than OASIS node 1 asexpected. The reason is that OASIS node 1 is equippedwith a high-fidelity geophone seismic sensor that hasa low noise level, while OASIS node 6 uses a low-costMEMS accelerometer as the seismic sensor. The poorSNR (signal-noise-ratio) of seismic MEMS sensors doesnot meet the requirements from seismologists very well.

The infrasonic sensor is to record infrasound, low-frequency acoustic waves generated during explosiveevents. During the first 2 months after the deployment,no explosions happened in Mount St. Helens volcano,thus the infrasonic sensor did not detect any explo-sive events. However, heavy storms were correctly de-tected by the infrasonic sensors. The lightning sensorsalso recorded several lightning strikes on 08/26/2009,08/28/2009, 09/01/2009, and 09/04/2009, as shownin Figure 8. When analyzing the data, we found thatthe lightning strikes were accompanied by storms. Forexample, Figure 7 shows that OASIS node 3 triggeredlightning events during a heavy storm indicated by theinfrasonic RSAM on 08/25/2009. The lightning strikesalso destroyed node 3’s radio amplifier, and caused itsdata stream to stop around 07:30. We added a lightningarrestor to protect the amplifier after we realized thisproblem. Correlating different sensors can help to cor-rectly identify events. For example, with the infrasonicsensor and seismic sensor together, we can tell a vol-cano explosion (with infrasonic event) from an ordinaryearthquake (without infrasonic event).

6.2 Event Detection AccuracyBroadband station VALT co-locates with OASIS node 1,so it is chosen as the ground truth for comparison. From

6

Fig. 5. Seismic events detected during a 6-day period:(Top) Broadband station VALT; (Bottom) OASIS node 1.

Figure 4, we can see that OASIS node 1 and VALT detectseismic events at the same time. Figure 5 compares thenumber of events detected during an active period from07/21/2009 to 07/26/2009. OASIS node 1 triggers 140seismic events while VALT detects 160. The VALT stationis more sensitive, because it has a very low frequencyresponse up to 0.01 Hz, while the corner frequency ofthe OASIS station is 2 Hz. Therefore, VALT can detectmore subtle events than the OASIS station, but it is alsomore expensive as said earlier.

When our STA/LTA algorithm identifies seismicevents, it assigns the highest priority 7 to the seismic sig-nals, as shown in Figure 6 (Top). The default STA/LTAratio 2 works well in the lab test with real seismic data asinput. However, post-deployment analysis shows that 2is not always the optimal STA/LTA ratio. Due to the highsensitivity and low noise level of the geophone sensor,many small activities are also recognized as earthquakeevents. If we choose 3 as the STA/LTA threshold, thosesmall volcanic activities will not be considered as events,as illustrated in Figure 6 (Bottom). We reconfiguredthe parameter remotely via RPC commands avoid falseevent triggering and result in better bandwidth allo-cation. The right monitoring parameter value highlydepends on the status of the volcano. It may needto be tuned in long-term monitoring as the volcanoesstatus changes. This exemplifies the importance of beingremotely configurable for systems like ours.

6.3 System Failures and Diagnosis

In this section, we present our evaluation and diagnosison several problems during deployment. The uptimeevaluation is fully end-to-end, that is to say, a nodeis considered to be up only if its data is successfullylogged in the database, no matter where the failure is in-between. Figure 9 shows the status of each node duringthe period from 07/15/2009 to 09/01/2009. The uptimeof the nodes varies from 34% to 93.6% with differenttypes of failures. From 08/16, the UPS for the Internetrouter at the control center was down for two days, andcaused failure of data importing. On 08/23/2009, dueto an exception in the data importer tool, the networkbranch 2 was offline for 1 day. Node 1 has the shortest

0

10

20

30

40

50

60

70

80

0

1

2

3

4

5

6

7

8

Seis

mic

RS

AM

Data

Priority

0

10

20

30

40

50

60

70

80

09/1216:14 16:16 16:18 16:20 16:22 16:24

0

1

2

3

4

5

6

7

8

Seis

mic

RS

AM

Data

Priority

Time

Fig. 6. Event detection and prioritization. (Top) whenSTA/LTA threshold is 2; (Bottom) when STA/LTA thresholdis 3.

uptime due to the Deluge failure. We used Deluge toreprogram the network with a new version of nodesoftware after fixing a bug. Unfortunately, node 1 failedto reboot from the designated image slot.

0

5000

10000

15000

20000

08/25 06:30 06:45 07:00 07:15 07:30

0

10000

20000

30000

40000

50000

60000

70000In

fra

so

nic

RS

AM

Lig

htn

ing

str

ike

s

Time

Fig. 7. Node 3 failed in a storm at 07:33:43, right after alightning strike.

0

2

4

6

8

10

12

14

08/21 08/23 08/25 08/27 08/29 08/31 09/02 09/04

0

10000

20000

30000

40000

50000

60000

70000

Fa

ile

d n

od

e

Lig

htn

ing

str

ike

s

Time

Fig. 8. The correlation between the occurrence of light-ning strikes and node failures.

Radio related problems is another challenge to thesystem robustness. We describe how the problem wasexposed and solved as follows. From 08/25/2009 to09/04/2009, 9 nodes surprisingly disappeared one afteranother. However, the RSSI/LQI report in our VALVEdatabase shows that the sink nodes can normally receivethe beacon packets from those nodes. We suspected thatthe radio amplifier of those nodes may always stay inTX mode, and thus could not receive beacon packets toform a valid path to the sink. To verify our conjecture,we remotely reprogrammed the sink node 0 with the

7

TOSBaseLQI (based on TOSBase in TinyOS) program.The snooped beacon packets show that those nodesrestarted every 30 seconds (our software watchdog resetsthe node once it fails to send out any data packets for30 seconds), and further ensure us that the amplifier isthe reason for the node failures. On 09/11/2009, we gota chance to visit several failed nodes by sharing a heli-copter with another USGS mission. The field test showsthat the power supply to the amplifier is only 0.33 V(normally it should be 3 V), and the current consumptionof the amplifier is as high as 164 mA. That indicates thatthe amplifier is latched in TX mode. A few days later,when we scrutinized the data logged in the database,we observed a pattern that most nodes detected light-ning strikes before they disappeared, as shown in Fig-ure 8. Node 11 recorded at least 20 strikes in the lastminute before it died. We confirmed that our losses weredue to lightning strikes from the weather patterns on8/25/2009, 8/27/2009, 9/1/2009, and 9/3/2009. The RFreceiver on the TI chip CC2591 is sensitive to lightning,and got damaged by lightning strikes. Afterward weadded a coaxial lightning arrestor to CC2591 to reflectthe lightning energy without decreasing the RF SNR, andreplaced the broken RF amplifiers.

0

20

40

60

80

100

1 2 3 4 6 8 9 10 11 12 13 14

Node S

tatu

s (

%)

Node ID

Node uptime

Radio failure

Infrastructure failure

Deluge Failure

Fig. 9. The node status during the first 47 days.

6.4 Link Quality and Network ConnectivityWe conducted evaluation on link quality (RSSI/LQI) andpacket loss. The end-to-end packet loss is measured asthe ratio of the number of lost data bits over the totalnumber of bits expected in each time unit. Each node inthe network reports the RSSI (Received Signal StrengthIndicator) and LQI (Link Quality Indicator) of beaconpackets from its neighbors every 5 minutes.

Figure 10 plots the change of the RSSI and LQI of links2 → 0 (node 2 is the sender and node 0 is the receiver)and 5 → 0 over a time period of 36 hours. We can seethat the RSSI of node 5 is higher than that of node 2by about 13 dBm. The LQI of node 5 is also constantlyhigher than that of node 2 due to the directional antennaon node 5 that significantly increases the signal strengthand link quality. We also observed a diurnal drop in thesignal strength and link quality. In Figure 10, the RSSI

-90

-85

-80

-75

-70

-65

0h 6h 12h 18h 0h 6h

RS

SI

Time (hour)

Node 2

Node 5

50

60

70

80

90

100

110

0h 6h 12h 18h 0h 6h

LQ

I

Time (hour)

Node 2

Node 5

Fig. 10. RSSI and LQI over the time.

of both nodes are high during UTC time 06:00 to 15:00(23:00 to 8:00 in Pacific time), and decreases by morethan 10 dBm during UTC time 18:00 to 00:00. Figure 10shows the diurnal change in LQI. The LQI of node 2 alsoexperiences a diurnal drop, similar to the RSSI. The LQIof node 5 does not experience significant fluctuation overtime, because the link quality (e.g., LQI) stays high whenthe RSSI is way above the threshold. The above analysisreveals that there exists certain diurnal environmentalparameters that affect radio propagation. From the datalogged in our database, this diurnal phenomenon repeatsalmost everyday. Similar phenomenon is also reported in[23]. From the above observations we conclude that it isnecessary to provide a certain amount of redundancy inthe link quality to survive the diurnal drop when deploy-ing a network. The network connectivity can becomeintermittent in extreme conditions. For example, ournode 12 occasionally lost its communication connectionto the network when the link quality dropped (SeeFigure 14 in the supplement).

7 RELATED WORKS

Deployment lessons [18] have stacked up with the in-creasing quantity of reported deployments. One of thefirst deployments was conducted in 2002 at Great DuckIsland to monitor the habitat of the Leach’s Storm Pe-trel [17]. Other habitat monitoring deployments includetracking the micro-climate of a redwood tree [19] andCane Toad populations [3]. These applications typicallyhave low-duty-cycle and low-data-rate characteristics.Like our application requirements, some recent deploy-ments involved high-data-rate signals, such as monitor-

8

ing industrial processes [5], long-span bridge [10], andrailway [4]. Those deployments shed light on a numberof design issues of sensor networks.

However, long-term viability in harsh and remoteenvironments remains a challenging issue. A recent de-ployment in the Swiss Alps [6] reported that the temper-ature response differences for the processor and radiooscillators caused a loss of clock synchronization undertemperature variations, and resulted in communicationfailures. FireWxNet [8], a multi-tiered portable wirelesssystem for monitoring wildland fire, is distinguishedby the rugged mountainous terrain over which it wasspread, similar to the volcanic environment of OASIS.The deployment life of FireWxNet was expected to beroughly 3 weeks, while OASIS is designed to operateunattended for at least one year. All of our nodes wereonly reachable by helicopter, and the field maintenanceis extremely hard. Thus software dependability andreliability are our critical concerns. Harvard has donethe pioneering work [21] in volcano monitoring anddeployed a sensor network on an active Ecuador volcanoin 2005 to monitor seismic activities. They used an event-detection algorithm to trigger on interesting volcanicactivity and initiate reliable data transfer to the basestation. During the 19-day sensor network deployment,the network recorded 229 earthquakes, eruptions, andother seismoacoustic events. However, they found theirevent detection accuracy was only 1%, which justifiesthe requirement of real-time continuous raw data de-livery by USGS. Their network reliability and uptimewas relatively low: the mean node uptime was only69% after factoring out base station failures. This workreveals many hard lessons in volcano monitoring, andhas greatly benefited our design of OASIS system. Inour deployment, we have achieved better performancein those aspects and learned many new lessons.

8 CONCLUSION AND FUTURE WORKOur successful design and deployment in Mount St.Helens demonstrated that a low-cost sensor networksystem can provide real-time continuous monitoring inharsh environments and greatly promoted the confidentuse of sensor networks. It is an achievement of the wholesensor network community. USGS has been planningto utilize this design for other volcano monitoring andgeological survey missions.

Sustainability and reliability of sensor networks in ex-treme environments remain a major research challenge.In extreme situations, a predictable and stable path maynever exist, the network connectivity is intermittent (asobserved in this study), a node could suddenly appear ordisappear, and the rare upload opportunity and unpre-dictable node disruptions often result in data loss. Oneof our future works is to design a collaborative com-munication and storage middleware that cooperativelyconfigures resources to increase disruption resilience,data persistence and network lifetime, and capture theintermittent connectivity for data delivery.

REFERENCES[1] OASIS. http://sensorweb.cs.gsu.edu/research/oasis.html.[2] VALVE. http://131.96.49.147:8080/valve3/.[3] S. Shukla, S. Shukla, N. Bulusu, N. Bulusu, S. Jha, and S. Jha.

Cane-toad Monitoring in Kakadu National Park Using WirelessSensor Networks. In Networks Research Workshop, 2004.

[4] K. Chebrolu, B. Raman, N. Mishra, P. K. Valiveti, and R. Kumar.BriMon: A Sensor Network System for Railway Bridge Monitor-ing. In MobiSys, 2008.

[5] R. Adler, P. Buonadonna, J. Chhabra, M. Flanigan, L. Krishna-murthy, N. Kushalnagar, L. Nachman, and M. Yarvis. Design andDeployment of Industrial Sensor Networks: Experiences from theNorth Sea and a Semiconductor Plant. In SenSys, 2005.

[6] G. Barrenetxea, F. IngelrestGunnar, G. Schaefer, and M. Vetterli.The hitchhiker’s guide to successful wireless sensor networkdeployments. In SenSys, 2008.

[7] Y. Chen, O. Gnawali, M. Kazandjieva, P. Levis, and J. Regehr.Surviving Sensor Network Software Faults. In SOSP, 2009.

[8] C. Hartung, R. Han, C. Seielstad, and S. Holbrook. FireWxNet:A Multi-Tiered Portable Wireless System for Monitoring WeatherConditions in Wildland Fire Environments. In MobiSys, 2006.

[9] A. Kiely, M. Xu, W.-Z. Song, R. Huang, and B. Shirazi. AdaptiveLinear Filtering Compression on Realtime Sensor Networks. InPerCom, 2009.

[10] S. Kim, S. Pakzad, D. Culler, J. Demmel, G. Fenves, S. Glaser,and M. Turon. Wireless sensor networks for structural healthmonitoring. In SenSys, 2006.

[11] R. Parthasarathy, N. Peterson, W.-Z. Song, A. Hurson, and B. Shi-razi. Over the Air Programming on Imote2-based Sensor Net-works. In HICSS, 2010.

[12] Y. Peng, W. Song, R. Huang, M. Xu, and B. Shirazi. Cacades: areliable dissemination protocol for data collection sensor network.In IEEE Aerospace Conference, 2009.

[13] N. Peterson, L. Anusuya-Rangappa, B. Shirazi, R. Huang, W.-Z. Song, M. Miceli, D. McBride, A. Hurson, and R. LaHusen.TinyOS-based Quality of Service Management in Wireless SensorNetworks. In HICSS, 2009.

[14] J. Polastre, J. Hill, and D. Culler. Versatile Low Power MediaAccess for Wireless Sensor Networks. In SenSys, 2004.

[15] W.-Z. Song, R. Huang, B. Shirazi, and R. Lahusen. TreeMAC:Localized tdma mac protocol for high-throughput and fairness insensor networks. In PerCom, 2009.

[16] W.-Z. Song, R. Huang, M. Xu, A. Ma, B. Shirazi, and R. Lahusen.Air-dropped Sensor Network for Real-time High-fidelity VolcanoMonitoring. In MobiSys, 2009.

[17] R. Szewczyk, J. Polastre, A. Mainwaring, J. Anderson, andD. Culler. Analysis of a Large Scale Habitat Monitoring Applica-tion. In SenSys, 2004.

[18] R. Szewczyk, J. Polastre, A. Mainwaring, and D. Culler. LessonsFrom A Sensor Network Expedition. In EWSN, 2004.

[19] G. Tolle, J. Polastre, R. Szewczyk, D. Culler, N. Turner, K. Tu,S. Burgess, T. Dawson, P. Buonadonna, D. Gay, and W. Hong. AMacroscope in the Redwoods. In SenSys, 2005.

[20] M. Wachs, J. I. Choi, J. W. Lee, K. Srinivasan, Z. Chen, M. Jain,and P. Levis. Visibility: A New Metric For Protocol Design. InSenSys, 2007.

[21] G. Werner-Allen, K. Lorincz, J. Johnson, J. Lees, and M. Welsh.Fidelity and Yield in a Volcano Monitoring Sensor Network. InOSDI, 2006.

[22] K. Whitehouse, G. Tolle, J. Taneja, C. Sharp, S. Kim, J. Jeong, J. Hui,P. Dutta, and D. Culler. Marionette: Using RPC for InteractiveDevelopment and Debugging of Wireless Embedded Networks.In IPSN, 2006.

[23] V. Turau, M. Witt, and C. Weyer. Analysis of a Real Multi-hopSensor Network Deployment: The Heathland Experiment. InINSS, 2006.

[24] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP SelectiveAcknowledgement Options. In RFC 1996.

[25] T. L. Murray and E. T. Endo. A real-time seismic-amplitudemeasurement system (rsam). volume 1966 of USGS Bulletin, pages5–10. 1992.

[26] Y. Peng, R. Lahusen, B. Shirazi, and W. Song. Design Of SmartSensing Component For Volcano Monitoring. In The 4th IETInternational Conference on Intelligent Environments (IE), July 2008.

9

Renjie Huang is a PhD student in computerscience from Washington State University. Hisresearch interest mainly focuses communicationscheduling and optimization in wireless sensornetwork. He received his B.S. degree from SouthChina University of Science & Technology andreceived his Master degree from Huazhong Uni-versity of Science & Technology.

Wen-Zhan Song is an associate professor incomputer science and director of SensorwebResearch Laboratory at Georgia State Univer-sity. Dr. Song is an active researcher on sensornetworks, smart grid and pervasive computingand has received more than 2 million fundingsupport from NSF, NASA, USGS and Boeingduring 2005 - 2010. He is a recipient of NSF CA-REER award in 2010 and Chancellor ResearchExcellence Award in WSU Vancouver in 2010.He received PhD from Illinois Institute of Tech-

nology and MS/BS from Nanjing University of Science and Technology.

Mingsen Xu is a PhD student in computer sci-ence from Georgia State University. He currentlyis a research assistant of sensorweb researchlaboratory. His research interest focuses on datacorrelation and reduction on sensor networks.He received his MS and BS degree from BeijingUniversity of Posts and Telecommunications.

Nina Peterson is currently an Assistant Pro-fessor of Computer Science in the Natural Sci-ences and Mathematics Division at Lewis-ClarkState College. She received her Doctorate fromWashington State University and worked as aResearch Assistant in the Pervasive ComputingLaboratory.

Behrooz A. Shirazi is currently the Huie-Rogerschair professor and director of the School ofElectrical Engineering and Computer Science.His research interests include the areas ofpervasive computing, software tools, distributedreal-time systems, scheduling and load balanc-ing, and parallel and distributed systems. Hehas received grant support totaling more than$8 million from federal agencies, including theUS National Science Foundation (NSF), the USDefense Advanced Research Projects Agency

(DARPA), and the AFOSR, and private sources, including Texas In-struments and Mercury Computer Systems. He has received numerousteaching and research awards. He is currently the Editor-in-Chief for theSpecial Issues for Pervasive and Mobile Computing Journal and hasserved on the editorial boards of the IEEE Transactions on Computersand the Journal of Parallel and Distributed Computing.

Richard LaHusen Richard LaHusen receivedthe BS degree from the University of California,Davis, and completed 4 years of graduate workat Humboldt State University. Thereafter, he hasworked for the last 20 years as part of theUSGS Volcano Hazards Team and is currentlya senior instrumentation engineer at the USGSCascades Volcano Observatory. Throughout the20-year period, he has developed instrumenta-tion, telemetry systems, and software for theresearch and monitoring of volcanic processes

and hazards (Murray et al., 1996). He developed the Acoustic FlowMonitor (AFM), an innovative system that incorporates in situ analysis ofseismic signals at remote nodes for the real-time detection and warningof volcanic debris flows that is in use around the world (LaHusen, 1996).He also developed a low-powered, high-resolution earth deformationmonitoring system that optimizes allocation of limited resources for GPSdata acquisition and communication needs (LaHusen and Reid, 2000).Most recently, he introduced and applied aerial deployment of self-contained volcano monitoring instrumentation stations during the 2004-2005 eruption of Mount St. Helens (LaHusen et al., 2006).

1

SUPPLEMENT OF THE ARTICLE:Real-World Sensor Network for Long-Term VolcanoMonitoring: Design and Findings

9 SUPPLEMENTAL SYSTEM DESIGN DETAILS

In this section, we present more system design detailsas a supplement of section 4 and section 5 in the mainpaper.

9.1 Over-the-air Network Reprogramming (contin-ued)This is a supplement of section 4.4 in the main paper.Deluge works on Tmote Sky and MicaZ, but it does notsupport the iMote2 platform, so we ported Deluge tothe iMote2 platform. The challenges of porting Delugeto iMote2 result from the need of a sophisticated mech-anism to access the Flash due to the increased size ofboth the RAM (32 MB) and the flash (32 MB), whichuse a Linux file system. In addition, the bootloader ofiMote2 is much more sophisticated than that of TmoteSky. Here we summarize the major modifications madein the implementation of Deluge for iMote2.

iMote2 does not have sectors that can be used forallocating space for the three different Deluge images.So we created three files in the user area for storing thecode updates. The bootloader is modified so that it canread the new code from the location specified in the userarea and load the code to the bootable location. This wasachieved by adding additional attributes to the sharedattribute table including the location and size of theimage. Whenever a node receives a reboot command, itupdates these attributes in the shared attribute table andreboots the device. Prior to each reboot, the bootloaderfirst checks the shared attributes to see if these attributesare enabled. If enabled, it then loads the image from thedesignated location; if no location is recorded, it loadsthe image from the pre-defined primary and secondarylocations.

9.2 Event Detection and Data PrioritizationThe seismic event data is critical for volcano studies, anddomain scientists require reliable delivery of the datawith the highest priority. We used the STA/LTA (short-term average over long-term average) algorithm [4], [5]to detect seismic events. The prototype of this algorithmis presented in [1] and we describe it here briefly.The STA/LTA algorithm is based on RSAM (RealtimeSeismic Amplitude Measurement), which is calculatedon raw seismic data samples every second. Let m bethe number of samples per second, {st−m, · · · , st−1}and {st, · · · , st+m−1} be the raw seismic sample val-ues in the (i − 1)th and ith second respectively, then

ei−1 =∑t−1

l=t−m slm is the average seismic sample value in

(i − 1)th second. The ith-second RSAM xi is calculatedwith the equation: xi =

∑t+m−1k=t (sk−ei−1)

m . The STA or

LTA is continuously updated based on the equation:

Xi =

∑n−1j=0 xi−j

n, where xi is ith-second RSAM; n is the

STA or LTA time window size. LTA gives the long termbackground signal level while the STA responds to shortterm signal variation. In our implementation, the STAwindow is 8 seconds; the LTA window is 30 seconds.The ratio of STA over LTA is constantly monitored. Oncethe ratio exceeds the trigger threshold (by default 2), thestart of an seismic event is declared, and the LTA valueis frozen so that the reference level is not affected by theincoming signals. The end of the event is declared whenthe STA/LTA ratio is below the de-trigger threshold. Theevent data is then assigned the highest priority 7 forreliable delivery. Seismologists expect the onset of theevent to be reliably collected for analysis purpose; thedata at the margin of the event-triggered window shouldbe included in the event period. We used a pre-eventbuffer to retain the data for a period of Tpre (4 secondsby default). Once a seismic event is detected, the pre-event buffer data is also assigned the highest priority.The event data will be reliably delivered to the gatewayby the reliable data transfer protocols in section 9.3. Thedefault parameter values of the STA/LAT algorithm aresuggested by USGS scientists and are configurable viaRPC mechanism.

9.3 Reliable Event Data Collection (continued)

A key challenge of reliable data collection in sensornetwork is that the feedback control traffic directly com-petes the bandwidth of sensor data traffic due to theradio broadcast nature. When the bandwidth is severelylimited, the data delivery with RDT could be worsethan that without RDT. This has been overlooked in theliterature and we made the following innovative designchoices.

Firstly, we used bitmap to represent multipleACK/NAKs, namely ANK, to reduce feedback traffic.An ANK packet has 3 fields (startSeqNo, validBits,ankBitmap), where startSeqNo is the starting sequencenumber to ANK, and validBits indicates number ofvalid bits in ankBitmap (e.g., number of packets toANK). In ankBitmap, bit-1 denotes a received packetwhile bit-0 denotes a lost packet. For example, an ANKpacket (startSeqNo = 10, validBits = 4, ankBitmap =1001 · · · ) means that packet 10 and 13 are received, whilepacket 11 and 12 are lost. In this way, a single ANKpacket can ACK/NAK many packets. We also applieda mechanism to regulate ANK traffic with a controlledinterval. This mechanism was not considered in ouroriginal design. After the deployment, we observed thatthe data stream in the database was intermittent withgaps of several minutes. Later we found that the reasonwas because sometimes the receiver sent ANK packetstoo frequently and caused buffer overflow in the MOXAdevice server. After we prolonged the ANK interval,the system worked normally. Secondly, we removed

2

sender’s retransmission timer. In the previous examplethat ANK can not reach the sender, a sender with re-transmission timer would retransmit useless old packetswasting bandwidth. In addition, the timeout intervalwould be very hard to estimate in lossy wireless net-works, comparing to wired Internet. If a sender receivesan ANK, the buffer space of those ACKed packets will befreed for reuse. If a sender’s buffer is full, a new packetwill simply replace the oldest one, even if it has notbeen acknowledged. Because if this situation happens,it means either no packet loss as no ANK comes back,or bandwidth is severely limited - we would ratherdrop old packets than new packets. Those designs areimportant to ensure that using RDT will be at least asgood as the case without RDT. When the receiver stopssending ANK, the system will be same as without RDT.

9.4 Adaptive Linear Filtering CompressionTo reduce the bandwidth demands and maximize thedata return over the unreliable and low rate radio links,we designed an Adaptive Linear Filtering Compression(ALFC) [3] algorithm to compress the seismic raw data.It is a lightweight compression algorithm tailored forsensor networks with code size only 768 bytes. Con-sidering the relatively modest computational power ofexisting sensor platforms, ALFC does not use floating-point operations and has very low computation andenergy cost.

Our method relies on adaptive prediction, which elim-inates the need to determine a priori of prediction co-efficients and, more importantly, allows the compres-sor to dynamically adjust to a changing source. Thisis particularly important for seismic data because thesource behavior can vary so dramatically depending onseismic activities. Predicted sample values are used tolosslessly encode source samples using a variable lengthcoding scheme. We map each sample value to a non-negative integer and then encode the resulting sequenceusing Golomb codes. This general strategy is used inthe Rice entropy coding algorithm and the LOCO-I im-age compressor, among a myriad of other applications.Given the low power characteristics of wireless sensornetworks, wireless links are typically lossy, demandinga compression scheme that allows packets to be decom-pressed even when preceding packets have been lost. Wealter the prediction approach for the first few samples inthe packet so that it does not rely on sample values inpreceding packets. Predicted sample values are used tolosslessly encode source samples using a variable-lengthcoding scheme.

10 FIELD DEPLOYMENT EXPERIENCE

The deployment of the sensor network of 13 OASISstations was conducted in Mount St. Helens volcano inJuly 2009. The OASIS stations were lowered by cablefrom a helicopter hovering about 100 feet up and gentlyput in hot spots inside the crater and around the flank.

0

50

100

150

200

250

300

0 1 2 3 4 6 7 8 9 10 11 12 13 14

Cum

ula

tive s

eis

mic

events

Node ID

Fig. 11. The spatial distribution of the triggered eventsfrom 07/15/2009 to 07/31/2009.

We monitored the network connectivity in real time atJRO by connecting a laptop to the sink node and gavefeedback via satellite phones to the crew in the helicopterto ensure network connectivity. The real-time feedbackwas very useful in a field deployment. The 13-nodedeployment took us about 6 hours. Installing stationson the flank turned out to be more difficult than insidethe crater due to the long distance between stations (upto 4 miles) and the rugged terrain. The diameter of thecovered area is about 6 miles. The customized amplifierworked remarkable well. Node 6 has a reliable link tothe sink node 0 at JRO with a distance of approximately4.6 miles.

The deployed in-situ sensor network has twobranches. Each branch operates with a separate data col-lection sink and radio channel. The first branch network(nodes 1 − 6) is mostly placed inside the crater. Thesecond branch network (nodes 8−14) is deployed aroundthe flank forming a semicircle. Some OASIS stations co-locate with existing USGS stations including VALT, SEP,and NED, which serve as ground truth to evaluate thedata quality of OASIS stations. The two sink nodes 0and 7 are installed at JRO so they are easy to access.This makes the network failures caused by sink easierto fix. Also, the sink now has a reliable source of power.During the trial deployment in 2008, the sink node wasplaced in the crater with battery and equipped with a900 MHz radio for telemetry to the gateway, which waspower hungry and depleted the sink node in 4 months.

11 SUPPLEMENTAL SYSTEM EVALUATIONAND FINDINGS

In this section, we present more system evaluations andfindings as a supplement of section 6 in the main paper.

11.1 Data Quality Evaluation (continued)

This is a supplement of Section 6.1 in the main paper.During our trial deployment in 2008, we found that someseismic data samples lost their 6 LSBs (Least SignificantBit) and have distortions, as shown in Figure 12 (Top).Eventually, we figured out that the 6.5 MHz clock rateof iMote2 driving the ADC driver was the cause ofthe data distortion. The ADC chip ADS8344 [2] canonly work normally at 2.4 MHz clock mode. In otherwords, the external clock cycle should be no less than

3

Fig. 12. (Top) The 6 least significant bits of some seismic data samples are cut due to the ADC overclocking problem;(Bottom) The seismic data samples without distortion.

400 ns (2.4 MHz) to correctly accomplish the conversion.Originally the SPI clock rate was configured to be 6.5MHz (typical iMote2 clock rate), which is too high forADS8344. Thus we changed the SPI Serial clock rate to2.6 MHz by configuring a higher clock divisor. This SPIclock rate was still slightly higher than the specification,but ADS8344 worked normally and the data distortionwas eliminated (See Figure 12 (Bottom)).

11.2 Event Detection Accuracy (continued)

This is a supplement of Section 6.2 in the main paper. Wealso investigated the spatial distribution of the triggeredevents. Figure 11 shows the number of seismic eventstriggered by each OASIS station from 07/15/2009 to07/31/2009. We can see that the network branch (nodes1 − 4, and 6) inside the crater detects more events thanthe branch (nodes 8− 14) along the volcano flank, witha lead of 138%. That sheds light on the volcanic hotspot distribution and benefits the refinement of ourfuture deployment strategy. Additionally, OASIS node1 detected the most events due to its advantages in theseismic sensor. Some small events can only be detectedby highly sensitive sensors.

Not all seismic events indicate earthquakes. For ex-ample, a small rock fall can generate small seismicevents but not earthquake. Thus, we used USGS analysissoftware to pick out real earthquake events. Figure 13(Top) shows the location and magnitude of the 187earthquakes that happened in the first 6-month deploy-ment period from 07/18/2009 - 01/13/2010. The sizeof the circles denotes the earthquake magnitude. FromFigure 13 (Top) we can see that while the crater is mostactive area, some strong earthquakes also took placeon the flanks. Figure 13 (Bottom) shows the earthquaketime. We observed that earthquakes are more frequentduring the first 3 month.

11.3 Data Prioritization and Compression EffectsNext we evaluated the performance of our data pri-oritization scheme Tiny-DWFQ and data compressionalgorithm ALFC.

Figure 15 shows the end-to-end packet reception ratioswith different data priorities based on node 4’s 24-hourdata stream on 08/02. We can see that data with a higherpriority accordingly has a higher chance to reach thegateway.

80

85

90

95

100

RSAM1 RSAM2 Lightning GPS Seismic Infrasonic

0

1

2

3

4

5

6

7

8

Packet re

ception r

atio (

%)

Data

priority

Data type

Packet reception ratio

Data priority

Fig. 15. Packet reception ratio v.s. Data priority

A unique innovation of OASIS is feeding back infor-mation from EO-1 into the in-situ element. High spatialresolution data generated by EO-1’s Hyperion spectrom-eter is fed through a thermal analysis element to detecta region of thermal activity on the target area, analyzesthe data, and pushes results to the ground segmentto re-prioritize bandwidth allocation through Command& Control. Figure 16 shows the space-to-ground trig-gering and the prioritized data delivery mechanism inthe ground network. For example, as snow accumulatesin the Mount St. Helens, OASIS node 4 was buriedunder snow gradually. During that process, the datastream of node 4 experienced more and more packet loss.However, once the data priority was raised to highest

4

Fig. 13. (Top) The spatial distribution of earthquake events. (Bottom) The temperal distribution of earthquake events.

Fig. 14. The intermittent data delivery of OASIS node 12 between 11/09/2009 and 11/10/2009.

level due to space triggering, the data during that periodwere reliably delivered.

The ALFC algorithm in each OASIS station losslesslycompresses the real-time seismic data. The decompres-sion is performed at the gateway before the data is storedinto the database.

Figure 17 illustrates the average compression ratio ofthe seismic data on each OASIS station based on a 4-hour continuous data stream. Node 0 and node 7 serveas two sink nodes without connection to seismic sensors,and node 5 is not connected to the network due tothe problem of asymmetric links. So these 3 nodes are

not included in Figure 17. An observable margin in thecompression ratio can be found in node 1. It has anaverage compression ratio of about 2.2, which is about30% better than other nodes. Node 1’s Geophone-basedseismometer has lower noise level than the MEMS-based seismometer, thus its data is more compressible.Additionally, the standard error on node 1 indicates thatits compression ratio experiences a larger fluctuationthan other nodes. That is because node 1’s data containsmore seismic event signals. According to the data loggedin our database, node 1 experienced about 20 seismic

5

Fig. 16. Space-to-ground triggering raised the data priority to the highest level, resulting in reliable delivery of the datastream from node 4.

events in this 4-hour period, while other nodes detectedfewer, even none.

0

0.5

1

1.5

2

2.5

3

3.5

1 2 3 4 6 8 9 10 11 12 13 14

Com

pres

sion

Ratio

Node ID

compression ratio

Fig. 17. Averaged compression ratio of each node basedon a 4-hour seismic data stream

6

8

10

12

14

07/20/09 18:20 18:30 18:40 18:50 19:00 19:10

Bits

per

sam

ple

Time

Node 1 Node 6

Fig. 18. The number of bits per data sample aftercompression. Each data sample has 16 bits before com-pression. The result is correlated with the data samples inFigure 4.

Figure 18 illustrates the variation of the compressionratio over the time series. Here we measure the com-pression ratio using the number of bits per sample after

compression. Each data sample has 16 bits before beingcompressed. The lower number of bits per sample aftercompression denotes better compression performance.Figure 18 plots node 1 and node 6, the two nodes withthe most seismic events. The bit number per sample iscalculated every 280 samples to reflect the variation overtime series. There are two facts observed from Figure 18.Firstly, the average number of bits per sample of node 1is noticeably lower than node 6. With ALFC, it costs node1 about 7 bits to encode each sample on average, whilefor node 6 more than 9 bits are required to encode eachsample. That is because the data from node 1 have lowernoise level than that from node 6 due to the equippedgeophone seismic sensor as explained above. Secondly,the spikes in the curves for each node have a strongcorrelation with the seismic events. Figure 4 plots theseismic waveform data for node 6 and node 1. We cansee that each seismic event has a corresponding spikein the curves in Figure 18. The seismic event data havehigh dynamics and thus result in low compression ratio.Moreover, Figure 18 illustrates that the compression ratioof node 1 has larger fluctuation than that of node 6,which is indicated by the number and the amplitudeof spikes on each curve. That exactly explains why thecompression ratio of node 1 has a larger variation asshown in Figure 17. The results above show that ALFCperforms effectively in a field network deployed on anactive volcano where the seismic data generally havehigh dynamics. They also reveal that the noise floorof sensors has a significant impact on the compressionperformance of ALFC.

REFERENCES

[1] W.-Z. Song, R. Huang, M. Xu, A. Ma, B. Shirazi, and R. Lahusen.Air-dropped Sensor Network for Real-time High-fidelity VolcanoMonitoring. In The 7th Annual International Conference on MobileSystems, Applications and Services (MobiSys), June 2009.

[2] ADS8344: http://focus.ti.com/lit/ds/symlink/ads8344.pdf.

6

[3] A. Kiely, M. Xu, W.-Z. Song, R. Huang, and B. Shirazi. AdaptiveLinear Filtering Compression on Realtime Sensor Networks. InPerCom, 2009.

[4] T. L. Murray and E. T. Endo. A real-time seismic-amplitudemeasurement system (rsam). volume 1966 of USGS Bulletin, pages5–10. 1992.

[5] Y. Peng, R. Lahusen, B. Shirazi, and W. Song. Design Of SmartSensing Component For Volcano Monitoring. In The 4th IETInternational Conference on Intelligent Environments (IE), July 2008.