1 wireless sensor networking (understanding the radio, mac, & routing protocols) romit roy...
TRANSCRIPT
1
Wireless Sensor Networking(Understanding the radio, MAC, & routing
protocols)
Romit Roy Choudhury
2
Sensor Networking – Why ??
Data Collection – A basic need Will the volcano erupt? Need temperature/gas
signatures How much Global Warming? Need ocean current data How many enemy tanks crossed?
Human monitoring possible/feasible ? Often risky, impenetrable, costly, …
But science has collected data for centuries … Manual (wired) placement, periodic human visits Wireless data transmitters Community accepted barriers/defiiencies
3
New Opportunities
Device miniaturization Moore’s law Processors envisioned as smart dust
Innovations in wireless communication Low power communication Antenna sizes smaller with high frequency
Device + RF + sensors - A new breakthrough:Scattered sensor motes self-organize themselves forming a
network.Sensed data aggregated, processed, and transported to base
station.Low risk, low cost, and heavy penetration
Device + RF + sensors - A new breakthrough:Scattered sensor motes self-organize themselves forming a
network.Sensed data aggregated, processed, and transported to base
station.Low risk, low cost, and heavy penetration
4
Plethora of Applications
5
Plethora of Challenges
Devices Reducing energy consumption Heavy programming constraints (16 KB RAM)
Wireless Radio Network Reliable low power communication Medium access control (MAC) Network wide energy conservation Routing Aggregation, compression, suppression …
6
Today’s Talk
Understanding the wireless channel The departure from wireline The key challenges
Medium access control Protocol design Energy-awareness (coordinated sleeping)
Routing Unicast (Diffusion) Broadcast (Gossip)
7
The Wireless Channel
8
Many Motivations for Wireless
Unrestricted mobility / deployability Unplugged from power outlet
Significantly lower cost No cable layout, service provision Low maintenance
Ease Direct communication with minimum
infratructure
9
From Links to Networks
Variety of architectures
Single hop networks
Multi-hop networks
10
The Wireless Future …
Internet
11
No Free Lunch
Numerous challenges Channel fluctuation Lower bandwidth Limited Battery power Disconnection due to mobility Security …
12
Question Is …
Can’t we use the rich “wireline” knowledge ?In solving the wireless challenges
13
The Answer
Wireless channel: A dispersive mediumThe PHY and MAC layer completely dissimilar
The whole game changes
14
On Our Agenda
Quick Glimpse Medium Access Control
•Wired
•Wireless
The emergence of 802.11
Evolution of sensor network MAC protocols•Energy awareness
15
Medium Access Control
16
The Channel Access Problem
Multiple nodes share a channel
Pairwise communication desired Simultaneous communication not possible
MAC Protocols Suggests a scheme to schedule communication
•Maximize number of communications•Ensure fairness among all transmitters
AA CCBB
17
The Trivial Solution
Transmit and pray Plenty of collisions --> poor throughput at high
load
AA CCBB
18
The Simple Fix
Transmit and pray Plenty of collisions --> poor throughput at high
load
Listen before you talk Carrier sense multiple access (CSMA) Defer transmission when signal on channel
AA CCBB
Don’ttransmit
Don’ttransmit
Can collisions still occur?Can collisions still occur?
19
CSMA collisions
Collisions can still occur:Propagation delay non-zero between transmitters
When collision:Entire packet transmission time wasted
spatial layout of nodes
note:Role of distance & propagation delay in determining collision probability
20
CSMA/CD (Collision Detection)
Keep listening to channel While transmitting
If (Transmitted_Signal != Sensed_Signal) Sender knows it’s a Collision ABORT
21
2 Observations on CSMA/CD
Transmitter can send/listen concurrently If (Sensed - received = null)? Then success
The signal is identical at Tx and Rx Non-dispersive
The transmitter can DETECT if and when collision occurs
The transmitter can DETECT if and when collision occurs
22
Unfortunately …
Both observations do not hold for wireless
Leading to …
23
Wireless Medium Access Control
A B
C D
Distance
Signalpower
SINR threhold
24
Wireless Media Disperse Energy
A B
C D
Distance
Signalpower
SINR threhold
A cannot send and listen in parallel
Signal not same at different locations
25
Collision Detection Difficult
Signal reception based on SINR Transmitter can only hear itself Cannot determine signal quality at
receiver
26
Calculating SINR
AB
C
α
α
CB
CtransmitC
B
AB
AAB
d
PI
d
PSoI
NNoiseIceInterferen
SoIterestSignalOfInSINR
transmit
=
=
+=
)()(
)(
α
α
CB
Ctransmit
AB
A
AB
dP
N
d
P
SINR
transmit
+
=
27
A B
C D
Distance
Signalpower
SINR threhold
Red signal >> Blue signal
X
Red < Blue = collision
28
A B
C D
Distance
Signalpower
SINR threhold
Important: C has not heard A, but can interfere at receiver B
X
C is the hidden terminal to A
29
A B
C D
Distance
Signalpower
SINR threhold
Important: X has heard A, but should not defer transmission to Y
X
X is the exposed terminal to AY
30
A B
C D
Distance
Signalpower
SINR threhold
X
A Project Idea!
Sensitivity threshold
31
A B
C D
Distance
Signalpower
SINR threhold
Sensitivity threshold
X
T
A Project Idea!Will this solve the wireless MAC problem? Do not transmit in this region
32
The Emergence of 802.11
Wireless MAC proved to be non-trivial
1992 - research by Karn (MACA) 1994 - research by Bhargavan (MACAW)
Led to IEEE 802.11 committee The standard was ratified in 1999
33
CTS = Clear To Send
RTS = Request To Send
IEEE 802.11 with Omni Antenna
D
Y
S
M
K
RTS
CTS
34
IEEE 802.11 with Omni Antenna
D
Y
S
X
M
Ksilenced
silenced
silenced
silencedData
ACK
35
But is that enough?
36
RTS/CTS
Does it solve hidden terminals ? Assuming carrier sensing zone =
communication zone
C
F
A B
E
D
CTS
RTS
E does not receive CTS successfully Can later initiate transmission to D.Hidden terminal problem remains.
E does not receive CTS successfully Can later initiate transmission to D.Hidden terminal problem remains.
37
Hidden Terminal Problem
How about increasing carrier sense range ?? E will defer on sensing carrier no
collision !!!
CB DData
A
E
CTS
RTSF
38
Hidden Terminal Problem
But what if barriers/obstructions ?? E doesn’t hear C Carrier sensing does not
help
CB DData
A
EF
CTS
RTS
39
Exposed Terminal
B should be able to transmit to A RTS prevents this
CA B
E
D
CTSRTS
40
Exposed Terminal
B should be able to transmit to A Carrier sensing makes the situation worse
CA B
E
D
CTSRTS
41
Thoughts !
802.11 does not solve HT/ET completely Only alleviates the problem through RTS/CTS and
recommends larger CS zone
Large CS zone aggravates exposed terminals Spatial reuse reduces A tradeoff RTS/CTS packets also consume bandwidth Moreover, backing off mechanism is also wasteful
The search for the best MAC protocol is still on. However, 802.11 is being optimized too.Thus, wireless MAC research still alive
42
Questions?
43
Energy-Awareness
802.11 optimizes for throughput/latency Energy savings is second priority
Unattended sensor networks Operate on AA batteries Yet, expected to last for months or years
Energy-awareness is the key Throughput and latency is secondary
44
An Energy-Efficient MAC Protocol for Wireless Sensor Networks (S-MAC)
Wei Ye, John Heidemann, Deborah Estrin
45
Major source of energy waste
Collision
Overhearing
Control Overhead
Idle Listening Listening to possible traffic that is not sent 50%-100% energy drain compared with receiving
46
Avenues to Reduce Energy Consumption
(1) Periodic listen and sleep(2) Collision avoidance(3) Overhearing avoidance(4) Message passing
47
(1) Periodic Listen and Sleep
The main idea Put nodes to sleep periodically
Called “Duty Cycles”
However, ensure that sleep/wake-up is synchronous
48
Listen for SYNC
td
Listen/Sleep Schedule Assignment
Choosing Schedule (1)
Sleep
Listen
Go to sleep after time t
Sleep
Listen
Broadcasts
A
B
Broadcasts
Go to sleep after time t- td
Synchronizer• Listen for a mount of time• If hear no SYNC, select its
own SYNC• Broadcasts its SYNC
immediately
Follower• Listen for a mount of time• Hear SYNC from A, follow
A’s SYNC• Rebroadcasts SYNC after
random delay td
49
Listen for SYNC Go to sleep after time t2
td
Listen for SYNC
Listen/Sleep Schedule Assignment
Choosing Schedule (2)
Sleep
Listen
Go to sleep after time t1
Sleep
Listen
A
Broadcasts
Sleep
Listen
C
Broadcasts
B
Only need to broadcast once
1. B receives A’s schedule and rebroadcast it.
2. Hear different SYNC from C3. Adapt both schedules
1. B receives A’s schedule and rebroadcast it.
2. Hear different SYNC from C3. Adapt both schedules
Nodes only rarely adopt multiple schedulesNodes only rarely adopt multiple schedules
50
Keeping Clocks in SYNC
SYNC packets must not collide Reserve separate time window for SYNC
transmission
51
(2) Collision Avoidance
Identical to 802.11 RTS/CTS Virtual carrier sense (NAV) Physical carrier sense
52
(3) Overhearing Avoidance
A is talking to BD receives CTS from B -> sleep• D’s transmission will collide B’s
C receives RTS from A -> sleep• C cannot receive CTS/DATA from E
All immediate neighbours of transmitting node sleep
How long should they sleep?C and D update their NAVKeeping sleeping until NAV count down to zero
Neighbors go to sleepon overhearing RTS/CTS
53
(4) Message Passing
How to transmit long message? Transmitting one long message is inefficient Many small packets with RTS/CTS/ACK for
each
S-MAC: Divide into fragments, transmit in burst
RTS/CTS reserve medium for the entire sequence
Fragment-errors recovery with ACK• no control packets for fragments
54
Acknowledgment to Pro. Jun Yang
Neighbors can sleep for whole message
55
Message Passing
Advantages: Energy saving:
Neighbors go to sleep when sense transmissions Reduces control overhead by sending multiple ACK
Disadvantage: Node-to-node fairness reduces
However, message-level latency reduces
56
ExperimentListen time: 300msSleeping time: 1sSYNC: every 13s (10 listen/sleep period)A, B, C use the same schedule
57Heavy Traffic Light Traffic
Energy save due to avoiding overhearing by using message passing
Energy save due to periodic sleep 802.11
OA
SMAC
58
OA: In light traffic status, nodes keep listening for quite a long time
59
Heavy Traffic Light Traffic
SYNC overhead
Overhearing avoidance still benefit
60
Questions?
61
Studied MAC protocols till now
Another important challenge:How does a packet get transported end to
end
i.e., How do you perform Routing
62
The Problem
A region requires event-monitoring (harmful gas, vehicle motion, seismic vibration, temperature, etc.)
Deploy sensors forming a distributed network
On event, sensed and/or processed information delivered to the inquiring destination
Event
Event
Sensor sources
Sensor sink
Directed Diffusion
A sensor field
63
Directed Diffusion
64
The Proposal
Proposes an application-aware paradigm to facilitate efficient aggregation, and delivery of sensed data to inquiring destination
Challenges: Scalability Energy efficiency Robustness / Fault tolerance in outdoor areas Efficient routing (multiple source destination
pairs)
65
IP or not to IP
IP is the pivot of wired/wireless networks All networking protocol over and below IP
Should we stick to this model?
Comments ?
66
Directed Diffusion
Typical IP based networks Requires unique host ID addressing Application is end-to-end, routers unaware
Directed diffusion – uses publish/subscribe Inquirer expresses an interest, I, using
attribute values Sensor sources that can service I, reply with
data
67
Data Naming
Expressing an Interest Using attribute-value pairs E.g.,
Other interest-expressing schemes possible E.g., hierarchical (different problem)
Type = Wheeled vehicle // detect vehicle locationInterval = 20 ms // send events every 20ms Duration = 10 s // Send for next 10 sField = [x1, y1, x2, y2] // from sensors in this area
68
Gradient Set Up
Inquirer (sink) broadcasts exploratory interest, i1 Intended to discover routes between source and sink
Neighbors update interest-cache and forwards i1
Gradient for i1 set up to upstream neighbor No source routes Gradient – a weighted reverse link Low gradient Few packets per unit time needed
69
Low
Exploratory Gradient
EventEvent
LowLow
Exploratory RequestGradient
Bidirectional gradients established on all links through flooding
70
Event-data propagation
Event e1 occurs, matches i1 in sensor cache e1 identified based on waveform pattern
matching
Interest reply diffused down gradient (unicast) Diffusion initially exploratory (low packet-rate)
Cache filters suppress previously seen data Problem of bidirectional gradient avoided
71
Reinforcement
From exploratory gradients, reinforce optimal path for high-rate data download Unicast
By requesting higher-rate-i1 on the optimal path
Exploratory gradients still exist – useful for faults
EventEvent
SinkA sensor field
Reinforced gradientReinforced gradient
72
Path Failure / Recovery
Link failure detected by reduced rate, data loss Choose next best link (i.e., compare links
based on infrequent exploratory downloads)
Negatively reinforce lossy link Either send i1 with base (exploratory) data rate Or, allow neighbor’s cache to expire over time
EventEvent
Sink
Src AC
B
MD
Link A-M lossyA reinforces BB reinforces C …D need notA (–) reinforces MM (–) reinforces D
73
M gets same data from both D and P, but P always delivers late due to looping M negatively-reinforces (nr) P, P nr Q, Q nr M Loop {M Q P} eliminated
Conservative nr useful for fault resilience
Loop Elimination
A
QP
D M
74
Simulation Setup & Metrics
ns2, 50 nodes in 160x160 sqm., range 40m Node density maintained, 802.11 MAC
Random 5 sources in 70x70, random 5 sinks Average Dissipated Energy
Per node energy dissipation / # events seen by sinks
Average Delay Latency of event transmission to reception at sink
Distinct event delivery ratio Ratio of # events sent to # events received by sink
75
Average Dissipated Energy
In-network aggregation reduces DD redundancy Flooding poor because of multiple paths from source to
sink
flooding
DiffusionMulticast
76
Delay
DD finds least delay paths, as OM – encouraging Flooding incurs latency due to high MAC contention,
collision
flooding
Diffusion
Multicast
77
Delivery ratio degrades with higher % node failures Graceful degradation indicates efficient negative
reinforcement
Event Delivery Ratio under node failures
0 %
10%20%
78
Conclusion
Directed diffusion, a paradigm proposed for event monitoring sensor networks
Energy efficiency achievable Diffusion mechanism resilient to fault tolerance
Conservative negative reinforcements proves useful
A careful MAC protocol, designed for such specifics, can yield further performance gains
79
Rumor Routing LEACH SPIN
Some other proposals for sensor routing
80
Rumor Routing
81
LEACH
Proposes clustering of sensors + cluster leaders Can aggregate data in single (local) cluster Rotating cluster head balances energy
consumption Cluster formation distributed and energy
efficientCluster-head always awake
Member nodes cansleep when not Txing
82
LEACH – The Protocol
Time is divided into rounds A node self-elects itself as the cluster head
Higher residual energy, higher probability to be head Close-by sensors join this cluster-head Cluster head does TDMA scheduling and gathers
data Gathered data compressed based on spatial
correlation Transmits data to Base Station (@ higher power)
In the next round, another cluster head elected Probabilistic load balancing Network lifetime can increase manifolds
83
SPIN: Information Via Negotiation
Flooding many sensors transmit same data Redundant
Make sensors disseminate spatially/temporally disjoint data sets Name data with meta-data to define space/time
property Sensors compare overheard data with self-
sensed data Combine data to minimize overlap
Make sensors resource-adaptive When low battery perform minimum activities
84
The SPIN 3-Step Protocol
B
AADVREQDATA
ADV
AD
VADV
ADV
AD
V ADV
REQ
RE
Q
REQ
RE
Q
REQ
DATADA
TA
DATA
DA
TA
DATA
85
The SPIN 3-Step Protocol
B
A
DATADA
TA
DATA
DA
TA
DATA
Notice the color of the data packets sent by node B
86
The SPIN 3-Step Protocol
B
A
DATADA
TA
DATA
DA
TA
DATA
SPIN effective when DATA sizes are large : REQ, ADV overhead gets amortized
87
SmartGossip: A Reliable Broadcast Service for Wireless Sensor
Networks
Romit Roy ChoudhuryDept. of ECE, Duke University
Joint work withPradeep Kyasanur (Google)
Indranil Gupta (UIUC)
88
Problem
Broadcast in Sensor Networks A widely used service
Network layer functions heavily depend on it
Examples:•Directed Diffusion
•Unicast or multicast routing
• Instruction / code dissemination
•Query propagation
89
Several approaches evolved over time
Approaches
Complexalgo
Floo
ding
Mul
ti-p
oint
rela
ys
BroadcastStorm
Dom
inat
ing
sets
Single pointof failures
Gos
sipi
ng
LoadBalance
90
Recent Past
Gossiping = Probabilistic flooding Nodes forward with probability, p
Source
91
Recent Past
Gossip based broadcast Nodes forward with probability, p
Source
Heads
Tails
92
Recent Past
Gossip based broadcast Nodes forward with probability, p
Source
Heads
Tails
93
Recent Past
Gossip based broadcast Nodes forward with probability, p
Source
HeadsHeads
Tails
94
Recent Past
Gossip based broadcast Nodes forward with probability, p
Source
HeadsHeads
Tails
95
Recent Past
Gossip based broadcast Nodes forward with probability, p
Source Heads
Tails
Tails
HeadsHeads
Tails
96
Recent Past
Gossip based broadcast Nodes forward with probability, p
Source Heads
Tails
Tails
HeadsHeads
Tails
97
Recent Past
Gossip based broadcast Nodes forward with probability, p
Source Heads
Tails
Tails
HeadsHeads
Tails
Heads
Tails
98
Recent Past
Gossip based broadcast Nodes forward with probability, p
Source Heads
Tails
Tails
HeadsHeads
Tails
Heads
Tails
99
Recent Past
Gossip based broadcast Nodes forward with probability, p
Source Heads
Tails
Tails
HeadsHeads
Tails
Heads
Tails
Heads
Tails
100
Recent Past
Gossip based broadcast Nodes forward with probability, p
Source Heads
Tails
Tails
HeadsHeads
Tails
Heads
Tails
Heads
TailsFor carefully chosen ‘p’
the message reaches all nodes in minimal transmissions
1. Simple, 2. Fault tolerant3. Load-balanced
101
We Ask …
Given some topology deployment How do we choose a suitable value of “p” ?
One option is to simulatethe gossip offline, and determine “p”
But, for this example, simulation result will be
p = 1
102
We Ask …
Given some topology deployment How do we choose a suitable value of “p” ?
Even if topology is homogeneous It may change over time due to failure and
mobility
103
We Ask …
Given some topology deployment How do we choose a suitable value of “p” ?
Even if topology is homogeneous It may change over time due to failure and
mobility
Say computed p = 0.85
104
We Ask …
Given some topology deployment How do we choose a suitable value of “p” ?
Even if topology is homogeneous It may change over time due to failure and
mobility Fails
Say computed p = 0.85
105
We Ask …
Given some topology deployment How do we choose a suitable value of “p” ?
Even if topology is homogeneous It may change over time due to failure and
mobility
Say computed p = 0.85
15% of packetswill not reach these nodes
106
We Ask …
Given some topology deployment How do we choose a suitable value of “p” ?
Even if topology is homogeneous It may change over time due to failure and
mobility
Finally, what if topology is not known a priori ? How can you choose “p” ?
107
A broadcast service necessary that customizes itself to the underlying topology
andrepairs itself with failures and mobility
We Argue …
108
Smart Gossip
Intuition Identify which of YOUR friends get to know
gossips earlier than you do•Request those friends to gossip more
Friends who get to know gossips later than you will request you to gossip more
You choose your gossip probability as:•MAX value of all requests from YOUR friends
109
For Example …
When H spreads a gossip F gets gossip only from G F asks G to always gossip Thus, pG = 1.0
B receives gossip from A,C,D,E,F B also observes that A,C,D,E received gossip
from F• Indicates that B must depend only on F (parent)
•A,C,D,E and B are independent (siblings)
B asks F to always gossip, thus pF = 1.0
110
For Example …
B asks F to always gossip,thus pF = 1.0
B does not require siblingsA,C,D,E to gossip at all
Thus pA = 0, pC = 0, pD = 0, pE = 0
Observe that only 2 transmissions (from G and F) are sufficient for broadcast
111
Protocol Details
For first gossip pkt, nodes transmit with p=1 Enables nodes to deduce neighbor dependences
Transmitters piggyback pkt with parent-id from which it received the pkt
Nodes record transmitter-id, and its parent-id, and deduce parent, child, sibling relationships …
… see next slide
112
Deducing Relationships
S A B C
E
SASASA Parent = {A}
Parent = {A}
Child = {A}
113
Parent = {A}
Parent = {A}
Child = {A}
Deducing Relationships
S A B C
E
ABABAB
Sibling = {B}
Child = {B} Parent = {B}
114
Parent = {A}
Parent = {A}
Child = {A}
Deducing Relationships
S A B C
EAEAE
Sibling = {B}
Child = {B} Parent = {B}
AE
115
Parent = {A}
Parent = {A}
Child = {A}
Deducing Relationships
S A B C
E
Sibling = {B}
Child = {B,E} Parent = {B,E}
Sibling = {E}
116
Choosing Probabilities
Each node calculates number of parents ( k ) Assume 99% assurance necessary for gossip
Node suggests each parent to gossip using ‘p’:
0.99 = ( 1 – (1 - p)k )
Each node receives multiple requests of ‘p’ Uses Max { pi } as its own gossip probability
S A B C
E
Parent={B,E}
117
Choosing Probabilities
Each node calculates number of parents ( k ) Assume 99% assurance necessary for gossip
Node suggests each parent to gossip using ‘p’:
0.99 = ( 1 – (1 - p)k )
Each node receives multiple requests of ‘p’ Uses Max { pi } as its own gossip probability
S A B C
E
p = 0.9
p = 0.9p = 1.0
p = 1.0p = 1.0
118
Choosing Probabilities
Each node calculates number of parents ( k ) Assume 99% assurance necessary for gossip
Node suggests each parent to gossip using ‘p’:
0.99 = ( 1 – (1 - p)k )
Each node receives multiple requests of ‘p’ Uses Max { pi } as its own gossip probability
S A B C
E
p = 0
p = 0.9
p = 0.9p = 1.0p = 1.0
119
The Bigger Picture
Src
120
Reliability (Details in paper)
Node Failures Node failures affect broadcast Source node flags packet periodically (p=1) Allows for updating dependences
Link Losses Node requests upstream nodes to retransmit
•We require each node to buffer few packets
Children overhear this request Children do not request retransmissions
themselves
121
Evaluation
Qualnet Simulator, ver 3.7(Currently implementing on Moteiv tmotes +
TinyOS)
Metrics used Average Reception Percentage Average Forwarding Percentage Resilience to link/node failures
122
Percolation
Smart Gossip
Adaptive Overhead
Adaptive Neighbor
123
Forwarding Overhead
124
Adaption to Node Failures
Nodes gossip more to compensate for other failing nodes
125
Conclusion
Broadcast is an important problem Gossip is good – but not practical for sensor nets Need to adapt gossip based on topology / failures
Smart Gossip Form dependence graphs using distributed
protocol Dependence relations suggest suitable probability
Results Overheads are low, and yet good percolation Robust to node and link failures
126
Questions?
127
Percolation
Smart Gossip
Adaptive Overhead
Adaptive Neighbor
128
Wireless Routing
Link instability causes many routing issues Shortest hop routing often worst choice Scarce bandwidth makes overhead
conspicuous Battery power a concern Security and misbehavior …
If that’s not bad enough Add node mobility
•Note: Routes may break, and reconnect later
129
Routing in wireless Mobile Networks
Imagine hundreds of hosts moving Routing algorithm needs to cope up with
varying wireless channel and node mobility
Where’s RED guy