Wireless Sensor Networks for High Fidelity Sampling Sukun Kim Qualifying Examination Dec 1, 2005

High Fidelity Sampling  Three classes of WSN applications Monitoring environments  Great duck island [11], Redwood forest [12]  Focus on low-duty cycle and low power consumption Monitoring objects – High Fidelity Sampling  machine health monitoring [13], condition-based monitoring, earthquake monitoring [14], structural health monitoring [15]  Focus on fidelity (quality) of sample Interactions with space and objects  Lighting control [16]  Focus on control

Structural Health Monitoring  High Fidelity Data  High Frequency Sampling with Low Jitter  Time Synchronized Sampling  Large-scale Multi-hop Network  Reliable Command Dissemination  Reliable Data Collection FTSP [8] Mint [9] Drip [10] Challenges

Reliable Data Collection - Problem Statement  Every data from every node needs be collected to PC over a multi-hop network without loss High throughput Small number of packet injections to network Overcome interference  Assumptions Powerful receiver, resource constrained sender Receiver (PC) can arbitrate flow  Low congestion Low loss rate

Hypothesis (Proposed Solution)  High Fidelity Data – Low-cost low-power MEMS accelerometer board with proper signal processing and calibration, produces data of meaningful fidelity  High Frequency Sampling with Low Jitter – WSN mote and TinyOS with guaranteed worst-case jitter, provide real time operation of meaningful level  Reliable Data Collection – Rate-based alternating-flow protocol with complex receiver and simple sender and pipelining, achieve reliable collection efficiently

Table of Contents  Related Work  High Fidelity Data  High Frequency Sampling with Low Jitter  Reliable Data Collection  Future Work

Structural Health Monitoring System Spencer, et al [5] Lynch, et al [6] Wisden [7] High Fidelity Data2.0μG/√ Hz * 0.5mG/ √Hz ? High Frequency Sampling with Low Jitter ?977Hz160Hz Time Synchronized Sampling?<1μsno Large-scale Multi-hop Network?noyes Reliable Command Dissemination?yesN/A Reliable Data Collection?B/s 250B/s Preliminary customized systems: Kruger, et al [1], Qiang, et al [2], Engel, et al [3], Caicedo, et al [4]

TCP on Wireless Networks  Blind link-level-retransmission (LLR) can decrease throughput – DeSimone, et al [17]  Support for mobile host I-TCP, Balakrishnan, et al [18]  Support for wireless ad-hoc network – WTCP, ATP Rate-based transmission Selective ACK contains congestion information No sender timeout for retransmission – WTCP

Reliable Transfer on WSN  Reliable diffusion PSFQ, RMST, Garuda, Drip, Deluge  Congestion Control ESRT, CODA, Fusion, Ee, et al [19]  Better best-effort convergence RBC  Reliable convergence Wisden  Sender sends data at static rate  In a routing tree, mote sends NACK to get missing packet from child for efficiency  PC sends NACK to source mote for e2e reliability  Incorrectly tuned rate and topology change make the network collapse  Compared to hardware, low bandwidth

Table of Contents  Related Work  High Fidelity Data In IWSHM ‘05  High Frequency Sampling with Low Jitter  Reliable Data Collection  Future Work

Accelerometer Board  Signal processing: averaging in software  Calibration for manufacturing variation and temperature  System noise floor: 30(μG/√Hz)  Gives desired quality in static, dynamic test Silicon Designs 1221L ADXL 202E  Two accelerometers for two axis  Thermometer, 16bit ADC, Low-pass filter

Table of Contents  Related Work  High Fidelity Data  High Frequency Sampling with Low Jitter In IWSHM ‘05  Reliable Data Collection  Future Work

Analysis of Jitter Sampling Other jobs like EEPROM write Non-preemptible portion Preemptible portion Probability Jitter 0CWT 1 +CT 2 +C P 1 /T 1 P 2 /T 2 1. Remove unnecessary blocking atomic section, interrupts  Turn off unnecessary components 2. Verify maximum blocking section is small enough Time

Verification of Jitter (6.67KHz) 0μs0μs 10μs 0μs0μs  Jitter is within 10µs (6.67%), 0.2% at 200Hz  Tradeoff: turning off radio  WSN mote and TinyOS are not inherently limited in real time operation It is a matter of the hardness of real time requirement and the tradeoff for the loss of functionality Time SeriesHistogram

Table of Contents  Related Work  High Fidelity Data  High Frequency Sampling with Low Jitter  Reliable Data Collection Straw  Future Work

Overview Application PCMote Application Straw Multi-hop Routing  PC application arbitrates flow Determines who sends when Triggers one flow at a time  Adjust RTT, adjust transmission rate to avoid interference Cross-layer information read(dest, *start, size) Routing layer is assumed to deliver packets end-to-end

Protocol PCMote Straw  Selective NACK  No need for flow control, rate-based transmission  No congestion control  Pipelining, no link level retransmission   Alternating flow, no concurrent bidirectional flow ComplexSimple 1. Data Request 2. Data Transfer 3. Request missing holes 4. Transfer missing holes Selective NACK Rate = if (Depth < Interference Radius) then (UART Delay) + Depth * (Radio Delay) else (Interference Radius) * (Radio Delay)

Optimization Read Send  Transfer the checksum of the whole data to guarantee the integrity  Parallelize reading from the memory and sending to the network Memory Network

95.6% 560B/s 96.6% 576B/s 91.4% 296B/s 91.8% 304B/s 93.2% 299B/s * End-to-end Raw Reliability Effective Bandwidth (Byte/s)  10KB of data 500 packets  Mica2dot, 36 bytes/pkt  Comparison to routing layer 630B/s for 1 hop  Up to 91.4% efficiency 352B/s for 2 hops  Up to 86.4% efficiency Test Result

Channel Capacity Utilization  Hardware capacity limit UART: 57.6Kbps Radio: 19.2Kbps 1 hop: 14.4Kbps  Measured actual capacity usage UART: 27.8Kbps Radio: 9.74Kbps Routing: 5.46Kbps (1 hop) Reliable: 4.7Kbps (1 hop) Mica2, 36bytes/pkt 33%

Mica2, 36bytes/pkt 43% header transfer & overhead 212.7μs 33% data transfer 24% overhead for transferring data

Effect of Packet Size on Bandwidth  Doubled packet size: 36B  72B  Payload: 20B  56B (2.8 times)  Packets/sec: 29.4  20.9 (71%)  Bandwidth doubled: 588B/s  1172B/s* (1.99 times)  RAM usage jump from 3437B to 4733B for SHM application (Sentri) 36 packet buffers Basic services (Comm + TimeSync + Routing + Bcast + Reliable) can go beyond 4KB of RAM *Loss rate was 0.2% RAM

GenericComm QueuedSend RoutingCmpnt1DripBcast Cmpnt2 Cmpnt5 Cmpnt3Cmpnt4Straw Cmpnt6 Forward 1. At least one at each end Component (12 out of 36) 2. Forwarding Queue (20 out of 36) Sharing packet buffer? Reliability of system versus Efficient use of resource Why so much RAM (packet buffer)? Sensornet Network Layer

Reliable Data Collection - Problem Statement  Every data from every node needs be collected to PC over a multi-hop network without loss High throughput Small number of packet injections to network Overcome interference  Assumptions Powerful receiver, resource constrained sender Receiver (PC) can arbitrate flow  Low congestion Low loss rate IF Revisited

Destination Source 5 hops, 26.28% link loss rate (78.23% E2E), 300 packets, separated by 1 sec, on BVR TestbedIn SECON ‘04

8 original messages

Overhead End-to-end retransmission (Straw): 8.6% at 96.6%(1hop) success rate 13.6% at 91.8%(2hops) success rate Erasure code: 12.5%, 25%, …

Table of Contents  Related Work  High Fidelity Data  High Frequency Sampling with Low Jitter  Reliable Data Collection  Future Work

Link Level Retransmission + Pipelining  Link level retransmission is effective when loss rate is high  Pipelining is effective for long path  Combining two can intensify interference - higher correlated losses Throughput = (e2e success rate) * (pkts/s at sender)

Congestion Control  In case Straw is used together with constant upstream traffic, congestion control will be needed  Congestion control from the receiver Include congestion information in NACK packet Sender adjusts rate using congestion information

Using Sentri (structural health monitoring toolkit) BerkeleySF Bay mid-spanquarter-span 59 Base Station 260ft 16ft L3L5L1L4L2 Deployment at Footbridge

V9V7 V13V4 V2 BerkeleySF Bay Plots of calibrated data

Model Properties First Vertical Mode of Vibration Match with SAP bridge model

Timeline  Mar 2006 for SenSys – Deployment on the Golden Gate Bridge  April 2006 – Study correlation between (link level retransmission + pipelining) and interference  Jul 2006 – Implement link level retransmission + pipelining  Dec 2006 – Congestion control with rate adjustment

Questions and Discussions

Backup Slides

References [1] M. Kruger and C. U. Grosse. Structural health monitoring with wireless sensor networks. Otto-Graf-Journal, 15:77–90, [2] P. Qiang, G. Xun, and Z. Chang-you. A wireless structural health monitoring system in civil engineering. The Third International Conference on Earthquake Engineering (3ICEE), Nanjing, China, October 18-20, [3] J. M. Engel, L. Zhao, Z. Fan, J. Chen, and C. Liu. Smart brick - a low cost, modular wireless sensor for civil structure monitoring. International Conference on Computing, Communications and Control Technologies (CCCT 2004), Austin, TX USA, August 14-17, [4] J. M. Caicedo, J. Marulanda, P. Thomson, and S. J. Dyke. Monitoring of bridges to detect changes in structural health. the Proceedings of the 2001 American Control Conference, Arlington, Virginia, June 2527, [5] B. S. Jr., M. Ruiz-Sandoval, and N. Kurata. Smart sensing technology: Opportunities and challenges. Journal of Structural Control and Health Monitoring, in press, [6] J. P. Lynch. Overview of wireless sensors for real-time health monitoring of civil structures. Proceedings of the 4th International Workshop on Structural Control (4th IWSC), New York City, NY, USA, June 10-11, [7] N. Xu, S. Rangwala, K. Chintalapudi, D. Ganesan, A. Broad, R. Govindan, and D. Estrin. A wireless sensor network for structural monitoring. the Proceedings of the ACM Conference on Embedded Networked Sensor Systems, November 2004.

References (continued) [8] A. DeSimone, M. C. Chuah, O. Yue, Throughput performance of transport-layer protocols over wireless LANs. In Proceedings of IEEE Globecom 93, Houston, USA, [9] A. Bakre, B. R. Badrinath, I-TCP: indirect TCP for mobile hosts, Proceedings of the 15th International Conference on Distributed Computing Systems (ICDCS'95). [10] H. Balakrishnan, S. Seshan, and R. H. Katz, Improving reliable transport and handoff performance in cellular wireless networks. ACM Wireless Networks, December 1995.

Reliable Data Collection - Problem Statement  Every data from every node needs be collected to PC over a multi-hop network without loss in a way that gives high throughput with small number of packet injections  The collection must overcome interference with the flow in the same and the opposite direction

Reliable Data Collection - Problem Statement  Every data from every node needs be collected to PC over a multi-hop network without loss in a way that gives high throughput with small number of packet injections  The collection must overcome interference with the flow in the same and the opposite direction Data ACK or NACK

Accelerometer Board Design ADXL 202ESilicon Designs 1221L Range-2G ~ 2G-0.1G ~ 0.1G System noise floor200(μG/√Hz)30(μG/√Hz) Price$10$150  Two accelerometers for two axis  Thermometer  16bit ADC Silicon Designs ADXL

Signal Processing  As an analog signal processing low-pass filter is used, which filters high frequency noise Low-pass filter with threshold frequency 25Hz is used  As a digital signal processing, averaging is used If noise follows Gaussian distribution, by averaging N numbers, noise decreases by a factor of sqrt(N)

Sensor Calibration

Temperature Calibration Temperature Acceleration FC mG Thanks to Crossbow

Power Consumption Operation ModeConsumption (mW) Board Only240.3 Idle358.2 One LED On383.4 Erasing Flash672.3 Sampling358.2 Transferring Data388.8  3 of Tadiran 5930 (lithium- ion, 3.6V, 19Ah, $17, D size) are used

Power Consumption (cont)  With optimal sleeping, 30 days Board itself consumes significant amount of energy Power source Sensor ADC Mote Switch Power source SensorADC Mote Switch

Verification of Jitter – Time Series (1KHz, 5KHz, 6.67KHz)  Peak to Peak is time to fill up buffer  Spiky portion is time to write buffer to flash  Can sample as long as the former is larger than the latter 0μs0μs 10μs

Verification of Jitter – Histogram (1KHz, 5KHz, 6.67KHz)  Jitter is within 10 µ s  Peak at 625ns – Wakeup time from sleep mode 0μs0μs10μs

Real-time System  Use separate MCU for sensor board, or two motes SensorMCU Buffer MCU Radio

Constraints and Options Sources of Failure Link Failure Mote Failure … How to obtain reliability? (possible options) 1.Add redundancy of information 1.Retransmission – link-level, end-to-end 2.Data redundancy – duplication, erasure code 3.Path redundancy – Use thick path 2.Increase success rate 1.Alternative Route 2.Congestion Control (# of pkts received) = P success × (# of pkts sent)

Problem Statement  Goal Reliable communication in multi-hop Wireless Sensor Networks  Assumption Wireless communication Resource-constrained mote

Erasure Code EncodingChannelDecoding M 8 msgs N 21 code words N’ ≥8 code words M 8 original msgs

Systematic Code Benefit: if receiver has codes containing original messages Encoding, Decoding are faster Even if receiver get less than 8 packets, we don’t lose every message

Systematic Code Encoding one code word takes 1.7ms Decoding time varies from 0 to 27ms Real time processing is possible In MICA2

Alternative Route Discovery Find Alternative Route What if Get 6 best candidates for the next hop from routing table. And try from the best And if

8 original messages

Design Space – Routing Layers Point-to-point Convergence Divergence Implementation on Beacon Vector Routing However, solutions are applicable to all routing layers

8 original messages

Given a threshold reliability requirement, what is the retransmission and redundancy combination that has the smallest overhead? Decomposing causes of failures (5 ret, no RF)

Findings  Link-level retransmission – efficiently handle transient link failure  Route fix – cure stale routing table problem, increase usefulness of erasure code  Erasure code – relieve the burden of last a few packets, which is very expensive  Some options addresses some problems efficiently, but not all failures Combining options would provide a sweet spot

Run Length Encoding (RLE)  94720, 94704, 94715, becomes , 04, 15, 08  Exception 94720, 94704, 92345, becomes , 04, \92345, 08  Run simulation on footbridge vibration data Fragment Size: 4 Threshold: 2

High Resolution Footbridge data

Low Resolution Footbridge data

Analysis High ResolutionLow Resolution RLE66%45% gzip *68%49% Theory56.25% (9 dynamic bits) 37.5% (6 dynamic bits)  Algorithm of RLE fits better to sensor data Basic algorithm of gzip utilizes repetition of same pattern  Compression ratio is sensitive to parameters (even go above 100%) Selecting RLE parameter (either statically or dynamically) is critical * Windows zip showed 0.64% increase

Analysis (continued)  There exists room for lossless or lossy compression  Compression ratio is sensitive to parameters (even go above 100%)  Selecting RLE parameter (either statically or dynamically) is critical Similar  Compress Random garbage  Drop

State Diagram of Sender More Start Request / Set Timer Yes / Read Timer Fired / Send No / Stop Timer  Simple (intelligence in receiver)  Interface is simple read(start, size, *buffer)  Send everything once, and fill holes  Read depth in routing tree, and adjust transmission rate, packet interval, RTT estimate

State Diagram of Receiver Start More Send Network-Info Request Receive / Send Transfer Request, Set Timer Receive & Last || Timeout / count = 0 Timeout / FAIL Receive & not Last / Set Timer Yes / Send Read Request, Set Timer Receive / count = 0 More in Round count < threshold Yes No Yes / ++count No / FAIL No / SUCCESS Timeout

Mica2, 36bytes/pkt

Channel Capacity Utilization  Hardware capacity limit UART: 57.6Kbps = 200pkts/s Radio: 19.2Kbps = 66.7pkts/s 1 hop: 14.4Kbps = 50pkts/s  Measured actual capacity usage UART: 27.8Kbps = 120pkts/s Radio: 9.74Kbps = 42pkts/s Routing: 5.46Kbps = 31pkts/s (1 hop) Reliable: 4.7Kbps = 29.4pkts/s (1 hop) Mica2, 36bytes/pkt

Effect of header is considered here

For Mica2, packet size = 36 bytes Top, Left: Packet Size Bottom, Right: pkts/sec

RAM space  From 3437 to 4733 (SHM application – Sentri) 36Bytes RAM increase per 1Byte increase in packet size  Reason – Packet buffer space 4 below GenericComm 3 in TimeSync 16 in Routing 4 in Bcast in Reliable 2 in application  Basic services (Comm + TimeSync + Routing + Bcast + Reliable) can go beyond 4KB RAM with packet size = 72Bytes

Findings  Reliable Data Collection (Straw) 5.2% decrease in packet throughput 13.8% decrease in bandwidth  Packet is small compared to the size of header, so doubling packet size doubles bandwidth RAM limit due to many packet buffers – Reliability of system versus Efficient use of resource

Loss Rate at Footbridge Mica2, 36bytes/pkt

Loss Rate at Golden Gate Bridge Mica2, 36bytes/pkt

V9V7 V13V4 V2 BerkeleySF Bay Time-plots of calibrated data

Frequency-plots of calibrated data

Frequency: 1.78 Hz Damping Ratio: 1% Second Vertical Mode of Vibration

Custody Transfer  Efficient for unreliable media  Benefit from small packet header  Pipelining gets complicated  How to do custody transfer without interfering pipelining?

Low-power Reliable Transfer  Lessons from NEST FE Duty cycle affects retransmission timeout – timeout should consider duty cycle Aggressive transfer depletes battery – mote stop responding, causes transfer failure  Power information from lower layer are very useful for proper and efficient operation Power stack – duty cycle info, warning for low energy budget