Wireless Sensor Networking (Understanding the radio, MAC,

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
• Moores 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 Scatte
red 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
Todays 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
11
No Free Lunch

• Numerous challenges
• Channel fluctuation
• Lower bandwidth
• Limited Battery power
• Disconnection due to mobility
• Security

12
Question Is

• Cant we use the rich wireline knowledge ?
• In solving the wireless challenges

13
The Answer

• Wireless channel A dispersive medium
• The 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

A
C
B
17
The Trivial Solution

• Transmit and pray
• Plenty of collisions --gt poor throughput at high
  load

A
C
B
18
The Simple Fix
Dont transmit

• Transmit and pray
• Plenty of collisions --gt poor throughput at high
  load
• Listen before you talk
• Carrier sense multiple access (CSMA)
• Defer transmission when signal on channel

A
C
B
Can collisions still occur?
19
CSMA collisions
spatial layout of nodes
Collisions can still occur Propagation delay
non-zero between transmitters
When collision Entire packet transmission time
wasted
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 its 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
22
Unfortunately

• Both observations do not hold for wireless
• Leading to

23
Wireless Medium Access Control
C
D
A
B
Signal power
SINR threhold
Distance
24
Wireless Media Disperse Energy
A cannot send and listen in parallel
C
D
A
B
Signal power
Signal not same at different locations
SINR threhold
Distance
25
Collision Detection Difficult

• Signal reception based on SINR
• Transmitter can only hear itself
• Cannot determine signal quality at receiver

26
Calculating SINR
B
A
C
27
Red lt Blue collision
Red signal gtgt Blue signal
C
D
X
A
B
Signal power
SINR threhold
Distance
28
Important C has not heard A, but can interfere
at receiver B
C is the hidden terminal to A
C
D
X
A
B
Signal power
SINR threhold
Distance
29
Important X has heard A, but should not defer
transmission to Y
Y
X is the exposed terminal to A
C
D
X
A
B
Signal power
SINR threhold
Distance
30
A Project Idea!
C
D
X
A
B
Signal power
SINR threhold
Sensitivity threshold
Distance
31
A Project Idea!
Do not transmit in this region
Will this solve the wireless MAC problem?
C
D
X
A
B
Signal power
SINR threhold
T
Sensitivity threshold
Distance
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
IEEE 802.11 with Omni Antenna
M
Y
S
RTS
D
CTS
K
34
IEEE 802.11 with Omni Antenna
silenced
M
Y
silenced
S
Data
D
ACK
silenced
X
K
silenced
35

• But is that enough?

36
RTS/CTS

• Does it solve hidden terminals ?
• Assuming carrier sensing zone communication
  zone

E
F
C
A
B
D
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
  !!!

RTS
E
F
CTS
C
B
D
A
Data
38
Hidden Terminal Problem

• But what if barriers/obstructions ??
• E doesnt hear C ? Carrier sensing does not help

RTS
E
F
CTS
C
B
D
A
Data
39
Exposed Terminal

• B should be able to transmit to A
• RTS prevents this

E
RTS
CTS
C
A
B
D
40
Exposed Terminal

• B should be able to transmit to A
• Carrier sensing makes the situation worse

E
RTS
CTS
C
A
B
D
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/Sleep Schedule Assignment

• Choosing Schedule (1)

• Synchronizer
• Listen for a mount of time
• If hear no SYNC, select its own SYNC
• Broadcasts its SYNC immediately

Listen
A
Sleep
Go to sleep after time t
Listen for SYNC
Broadcasts

• Follower
• Listen for a mount of time
• Hear SYNC from A, follow As SYNC
• Rebroadcasts SYNC after random delay td

Listen
Sleep
Go to sleep after time t- td
td
Broadcasts
49
Listen/Sleep Schedule Assignment

• Choosing Schedule (2)

• B receives As schedule and rebroadcast it.
• 2. Hear different SYNC from C
• 3. Adapt both schedules

Listen
Sleep
Go to sleep after time t1
Listen for SYNC
Broadcasts
Listen
B
Sleep
td
Broadcasts
Only need to broadcast once
Nodes only rarely adopt multiple schedules
Listen
C
Sleep
Go to sleep after time t2
Listen for SYNC
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
Neighbors go to sleepon overhearing RTS/CTS

• A is talking to B
• D receives CTS from B -gt sleep
• Ds transmission will collide Bs
• C receives RTS from A -gt 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 NAV
• Keeping sleeping until NAV count down to zero

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
Experiment
Listen time 300ms Sleeping time 1s SYNC every
13s (10 listen/sleep period) A, B, C use the same
schedule
57
Energy save due to periodic sleep
802.11
Energy save due to avoiding overhearing by using
message passing
OA
SMAC
Heavy Traffic
Light Traffic
58
OA In light traffic status, nodes keep listening
for quite a long time
59
SYNC overhead
Overhearing avoidance still benefit
Heavy Traffic
Light Traffic
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

A sensor field
Event
Sensor sources
Sensor sink
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)

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
Exploratory Gradient
Exploratory Request Gradient
Event
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

Event
A sensor field
Sink
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 neighbors cache to expire over time

Link A-M lossy A reinforces B B reinforces C D
need not A () reinforces M M () reinforces D
Event
D
M
Src
A
C
Sink
B
73
Loop Elimination

• 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

Q
P
A
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
Multicast
Diffusion
76
Delay

• DD finds least delay paths, as OM encouraging
• Flooding incurs latency due to high MAC
  contention, collision

flooding
Diffusion
Multicast
77
Event Delivery Ratio under node failures

• Delivery ratio degrades with higher node
  failures
• Graceful degradation indicates efficient negative
  reinforcement

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 efficient

Cluster-head always awake
Member nodes can sleep 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 (_at_ 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
A
B
85
The SPIN 3-Step Protocol
A
B
Notice the color of the data packets sent by node
B
86
The SPIN 3-Step Protocol
A
B
SPIN effective when DATA sizes are large REQ,
ADV overhead gets amortized
87
SmartGossip A Reliable Broadcast Service for
Wireless Sensor Networks
Romit Roy Choudhury Dept. of ECE, Duke
University Joint work with Pradeep 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
Approaches

• Several approaches evolved over time

90
Recent Past

• Gossiping Probabilistic flooding
• Nodes forward with probability, p

Source
91
Recent Past

• Gossip based broadcast
• Nodes forward with probability, p

Tails
Source
Heads
92
Recent Past

• Gossip based broadcast
• Nodes forward with probability, p

Tails
Source
Heads
93
Recent Past

• Gossip based broadcast
• Nodes forward with probability, p

Tails
Source
Heads
Heads
94
Recent Past

• Gossip based broadcast
• Nodes forward with probability, p

Tails
Source
Heads
Heads
95
Recent Past

• Gossip based broadcast
• Nodes forward with probability, p

Tails
Tails
Source
Heads
Heads
Heads
Tails
96
Recent Past

• Gossip based broadcast
• Nodes forward with probability, p

Tails
Tails
Source
Heads
Heads
Heads
Tails
97
Recent Past

• Gossip based broadcast
• Nodes forward with probability, p

Tails
Tails
Tails
Source
Heads
Heads
Heads
Heads
Tails
98
Recent Past

• Gossip based broadcast
• Nodes forward with probability, p

Tails
Tails
Tails
Source
Heads
Heads
Heads
Heads
Tails
99
Recent Past

• Gossip based broadcast
• Nodes forward with probability, p

Tails
Tails
Tails
Source
Heads
Heads
Heads
Heads
Heads
Tails
Tails
100
Recent Past

• Gossip based broadcast
• Nodes forward with probability, p

Tails
Tails
Tails
Source
Heads
Heads
Heads
Heads
Heads
Tails
For carefully chosen p the message reaches all
nodes in minimal transmissions
1. Simple, 2. Fault tolerant 3. Load-balanced
Tails
101
We Ask

• Given some topology deployment
• How do we choose a suitable value of p ?

One option is to simulate the 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
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
We Argue

• A broadcast service necessary
• that customizes itself to the underlying topology
• and
• repairs itself with failures and mobility

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 siblings
• A,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 p1
• 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
113
Deducing Relationships
S
A
B
C
E
114
Deducing Relationships
S
A
B
C
E
115
Deducing Relationships
Sibling E
S
A
B
C
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
ParentB,E
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

p 1.0
p 1.0
p 0.9
S
A
B
C
p 0.9
p 1.0
E
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

p 0
p 0.9
p 1.0
p 1.0
S
A
B
C
E
p 0.9
119
The Bigger Picture
Src
120
Reliability (Details in paper)

• Node Failures
• Node failures affect broadcast
• Source node flags packet periodically (p1)
• 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
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 thats 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

Wheres RED guy