Wireless Sensor Networks for High Fidelity Sampling
Sukun KimElectrical Engineering and Computer Sciences
University of California at Berkeley
Committee: David Culler, Ion Stoica, and Gregory Fenves
Dissertation TalkMay 14, 2007
High Fidelity Sampling Three categories 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]
Broadcast [10]
Challenges
Table of Contents Introduction Flush: A Reliable Bulk Transport Protocol
Algorithm Implementation Evaluation Discussion Related Work Conclusion
Deployment at the Golden Gate Bridge Data from the Golden Gate Bridge Conclusion
With Rodrigo Fonseca, Prabal Dutta, Arsalan Tavakoli, David Culler, Philip Levis, Scott Shenker and Ion Stoica
Overview Target applications
Where transfer completion time is more important than latency of each data point
Structural health monitoring, volcanic activity monitoring, bulk data collection
One flow at a time Reasonable restriction for target applications Remove inter-path interference Easier to optimize for intra-path interference
Table of Contents Introduction Flush: A Reliable Bulk Transport Protocol
Algorithm Implementation Evaluation Discussion Related Work Conclusion
Deployment at the Golden Gate Bridge Data from the Golden Gate Bridge Conclusion
Algorithm Receiver-initiated Selective-NACK Rate Control Separation of Concerns
Correctness (all packets are delivered) Performance (achieve high bandwidth)
Reliability
2 4 5
4 9
2, 4, 5
4, 9
4, 9
Rate Control: Conceptual Model
Rate:
Assuming disk modelN: Number of nodes, I: Interference range
Rate Control
d8 = δ8 + H7
= δ8 + δ7 + f7
= δ8 + δ7 + δ6 + δ5
1. At each node, Flush attempts to send as fast as possible without causing interference at the next hop along the flow
2. A node’s sending rate cannot exceed the sending rate of its successor
8 7 6 5
8 6 5
4
4
3
Interference Range > Reception Range
However,
Signal Strength
Noise Floor Noise Floor+ SNR Threshold
Noise Floor+ 2 X SNR Threshold
SNR Threshold – minimum SNR to decode a packet
Jammer – a node which can conflict with the transmission, but cannot be heard
Jammer Vulnerable to Jammer No problem to Jammer
Identifying the Interference Set
0
0.2
0.4
0.6
0.8
1
0 5 10 15 20 25 30
Fra
ctio
n of
Nod
es
Difference Between Received Signal Strength and Noise Floor (dBm)
Fract
ion o
f N
odes
CDF of the difference between the received signal strength from a predecessor and the local noise floor
A large fraction of interferers are detectable and avoidable
Table of Contents Introduction Flush: A Reliable Bulk Transport Protocol
Algorithm Implementation Evaluation Discussion Related Work Conclusion
Deployment at the Golden Gate Bridge Data from the Golden Gate Bridge Conclusion
Implementation RSSI is measured by snooping Information is also snooped
δ, f, D are put into packet header, and exchanged through snooping
δ, f, D take 1 byte each, 3 bytes total Cutoff
A node i considers a successor node (i− j) an interferer of node i+1 if, for any j > 1, rssi(i+1) − rssi(i−j) < 10 dBm
The threshold of 10 dBm was chosen after empirically evaluating a range of values
Implementation 16-deep Rate-limited Queue
Enforces departure delay D(i) When a node becomes congested (depth 5), it
doubles the delay advertised to its descendants
But continues to drain its own queue with the smaller delay until it is no longer congested
Table of Contents Introduction Flush: A Reliable Bulk Transport Protocol
Algorithm Implementation Evaluation Discussion Related Work Conclusion
Deployment at the Golden Gate Bridge Data from the Golden Gate Bridge Conclusion
Packet Throughput of Different Fixed Rates
0
5
10
15
20
25
30
35
40
45
0 1 2 3 4 5 6
Effe
ctiv
e T
hrou
ghpu
t (pk
t/s)
Hops from Sink
Fixed 10msFixed 20msFixed 40ms
Eff
ect
ive T
hro
ughput
(pkt
/s)
Packet throughput of fixed rate streams over different hop counts
The optimal fixed rate depends on the distance from the sink
Packet Throughput of Flush
0
10
20
30
40
50
60
0 1 2 3 4 5 6
Effe
ctiv
e T
hrou
ghpu
t (pk
t/s)
Hops from Sink
FlushBest Fixed Rate
Eff
ect
ive T
hro
ughput
(pkt
/s)
Effective packet throughput of Flush compared to the best fixed rate at each hop
Flush tracks the best fixed packet rate
Bandwidth of Flush
0
200
400
600
800
1000
1200
0 1 2 3 4 5 6
Effe
ctiv
e B
andw
idth
(B
/s)
Hops from Sink
FlushBest Fixed Rate
Eff
ect
ive B
and
wid
th
(B/s
)
Effective bandwidth of Flush compared to the best fixed rate at each hop
Flush’s protocol overhead reduces the effective data rate
Fraction of Data Transferred in Different Phases
• Fraction of data transferred from the 6th hop during the transfer phase and acknowledgment phase• Greedy best-effort routing is unreliable, and exhibits a loss rate of 43.5%. A higher than sustainable rate leads to a high loss rate
0
0.2
0.4
0.6
0.8
1
1.2
Flush Fixed 40 Fixed 20 Fixed 10 Routing
Fra
ctio
n
ACK PhaseTransfer Phase
Amount of Time Spent in Different Phases
• Fraction of time spent in different stages• A retransmission during the acknowledgment phase is expensive, and leads to a poor throughput
0
5
10
15
20
25
30
35
40
45
50
Flush Fixed 40 Fixed 20 Fixed 10 Routing
Tim
e (s
)
IntegrityCheckACK Phase
TransferPhaseTopologyQuery
Packet Throughput at Transfer Phase
0
10
20
30
40
50
60
70
80
90
100
0 1 2 3 4 5 6
Effe
ctiv
e G
oodp
ut (
pkt/s
)
Hops from Sink
FlushFixed 40Fixed 20Fixed 10Routing
Eff
ect
ive G
oodput
(pkt
/s)
Effective goodput during the transfer phase
Flush provides comparable goodput as a lower loss rate which reduces the time spent in the expensive acknowledgment phase, which increases the effective bandwidth
Packet Rate over Time for a Source
• Source is 7 hops away, Data is smoothed by averaging 16 values• Flush approximates the best fixed rate with the least variance
Maximum Queue Occupancy across All Nodes for Each Packet
• Flush exhibits more stable queue occupancies than Flush-e2e
Sending Rate at Lossy Link
Both Flush and Flush-e2e adapt while the fixed rate overflows its queue
6
5 43
2
10
Packets were dropped from hop 3 to hop 2 with 50% probability between 7 and 17 seconds
Queue Length at Lossy Link
Flush and Flush-e2e adapt while the fixed rate overflows its queue
Route Change Experiment
• We started a transfer over a 5 hop path• Approximately 21 seconds into the experiment forced the node 4 hops from the sink to switch its next hop• Node 4’s next hop is changed, changing all nodes in the subpath to the root• No packets were lost, and Flush adapted quickly to the change• Flush adapts when the next hop changes suddenly0
1a
2a
3a
1b2b
3b
45
Scalability Test
0
200
400
600
800
1000
1200
1400
0 5 10 15 20 25 30 35 40 45 50
Effe
ctiv
e B
andw
idth
(B
/s)
Hops from Sink
FlushFixed 20msFixed 40msFixed 60ms
Eff
ect
ive B
and
wid
th
(B/s
)
Effective bandwidth from the real-world scalability test where 79 nodes formed 48 hop network
Flush closely tracks or exceeds the best possible fixed rate across at all hop distances that we tested
Table of Contents Introduction Flush: A Reliable Bulk Transport Protocol
Algorithm Implementation Evaluation Discussion Related Work Conclusion
Deployment at the Golden Gate Bridge Data from the Golden Gate Bridge Conclusion
Discussion High-power node
reduces hop count and interference Not an option on the Golden Gate Bridge due
to power and maintenance problems Interactions with Routing
Link estimator of a routing layer breaks down under heavy traffic
Related Work Li et al – capacity of a chain of nodes
limited by interference using 802.11 ATP, W-TCP – rate-based transmission in
the Internet Wisden – concurrent transmission without
a mechanism for a congestion control Fetch – single flow, selective-NACK, no
mention about rate control
Conclusion A reasonable assumption (single flow)
simplifies a problem (eliminates inter-path congestion control)
Light-weight solution reduces complexity Overhearing is used to measure interference
and to exchange information Two rules to determine a rate
At each node, Flush attempts to send as fast as possible without causing interference at the next hop along the flow
A node’s sending rate cannot exceed the sending rate of its successor
Table of Contents Introduction Flush: A Reliable Bulk Transport Protocol
Algorithm Implementation Evaluation Discussion Related Work Conclusion
Deployment at the Golden Gate Bridge Data from the Golden Gate Bridge Conclusion
With Shamim Pakzad, David Culler, James Demmel, Gregory Fenves, Steve Glaser, and Martin Turon
Node Layout (1st phase)
Distance between nodes on the span is either 100ft or 50ft
Initially designed as 150ft Difference in MicaZ radio output power
was up to 7.5dBm
8 nodes
56 nodes
1125 ft 4200 ft
500 ft
246 ft
SF(south)
Sausalito(north)
Environment
FogStrong and salty windRapidly changing... high and scary
Node
Node (Mote + Accelerometer Board)
Battery (4 X 6V Lantern Battery)
Bi-directionalPatch Antenna
Node
Extreme Rusting of C-clamp
Zip tie aroundAntenna
Base Station
Laptop
Students At Work
Installation
Hard Hat
Harness
Sharp Edge
Ouch
However…
Crawling and Installing
Done!Strong Wind
Table of Contents Introduction Flush: A Reliable Bulk Transport Protocol
Algorithm Implementation Evaluation Discussion Related Work Conclusion
Deployment at the Golden Gate Bridge Data from the Golden Gate Bridge Conclusion
Reliable Data Collection at GGB
Bandwidth versus Hop Count
0
200
400
600
800
1000
1200
1400
0 10 20 30 40 50Hop Count
Ban
dwid
th (
B/s
)
Aug 1stAug 7thSep 20th
Data is collected reliably over a 46-hop network, with a bandwidth of 441B/s at the 46th hop
Vibration Data of GGB
The vertical modal properties match among (1) simulation model, (2) previous study, and (3) this study
(1)
(2)
(3)
Conclusion As a concrete example of HFS, SHM is
designed, implemented and deployed Requirements are identified and solutions
are proposed The system satisfied requirements, and
provided meaningful data for the research of structural analysis
Bonus – Spectacular Views
Acknowledgement David Culler GGB – Shamim Pakzad, James Demmel, Gregory
Fenves, Steve Glaser, and Martin Turon Reliable Data Collection – Rodrigo Fonseca, Prabal
Dutta, Arsalan Tavakoli, Philip Levis, Scott Shenker and Ion Stoica
Jaein Jeong, Xiaofan Jiang, Jay Taneja, Jorge Ortiz, Robert Szewczyk, Tom Oberheim, Anthony Joseph, Joe Polastre, Alec Woo, Kamin Whitehouse, Phil Buonadonna
Average Number of Transmissions per node for sending 1,000 packets
0
500
1000
1500
2000
2500
0 1 2 3 4 5 6
Ave
rage
Tra
nsm
issi
ons
Per
Nod
e
Hops from Sink
FlushFixed 10msFixed 20msFixed 40msOptimal
Bandwidth at Transfer Phase
0
200
400
600
800
1000
1200
1400
1600
1800
2000
0 1 2 3 4 5 6
Effe
ctiv
e G
oodp
ut (
B/s
)
Hops from Sink
FlushFixed 40Fixed 20Fixed 10Routing
Eff
ect
ive G
oodput
(B/s
)
Effective goodput during the transfer phase
Effective goodput is computed as the number of unique packets received over the duration of the transfer phase
Details of Queue Length for Flush-e2e
Memory and Code Footprint
The Golden Gate Bridge
More on Node
Signal Splitter
Antenna CableTo Base Station
(1)
(2)
(3)
The torsional modal properties match among (1) simulation model, (2) previous study, and (3) this study
8 7 6 5
8 6 5
4
4
3
6
5 43
2
10
0
1a
2a
3a
1b2b
3b
45