1 wireless sensor networking (understanding the radio, mac, & routing protocols) romit roy...

Wireless Sensor Networking(Understanding the radio, MAC, & routing

protocols)

Romit Roy Choudhury

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

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

Plethora of Applications

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 …

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)

The Wireless Channel

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

From Links to Networks

Variety of architectures

Single hop networks

Multi-hop networks

The Wireless Future …

Internet

No Free Lunch

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

Question Is …

Can’t we use the rich “wireline” knowledge ?In solving the wireless challenges

The Answer

Wireless channel: A dispersive mediumThe PHY and MAC layer completely dissimilar

The whole game changes

On Our Agenda

Quick Glimpse Medium Access Control

•Wired

•Wireless

The emergence of 802.11

Evolution of sensor network MAC protocols•Energy awareness

Medium Access Control

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

The Trivial Solution

Transmit and pray Plenty of collisions --> poor throughput at high

AA CCBB

The Simple Fix

Transmit and pray Plenty of collisions --> poor throughput at high

Listen before you talk Carrier sense multiple access (CSMA) Defer transmission when signal on channel

AA CCBB

Don’ttransmit

Can collisions still occur?Can collisions still occur?

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

CSMA/CD (Collision Detection)

Keep listening to channel While transmitting

If (Transmitted_Signal != Sensed_Signal) Sender knows it’s a Collision ABORT

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

Unfortunately …

Both observations do not hold for wireless

Leading to …

Wireless Medium Access Control

Distance

Signalpower

SINR threhold

Wireless Media Disperse Energy

Distance

Signalpower

SINR threhold

A cannot send and listen in parallel

Signal not same at different locations

Collision Detection Difficult

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

receiver

Calculating SINR

CtransmitC

NNoiseIceInterferen

SoIterestSignalOfInSINR

transmit

Ctransmit

transmit

Distance

Signalpower

SINR threhold

Red signal >> Blue signal

Red < Blue = collision

Distance

Signalpower

SINR threhold

Important: C has not heard A, but can interfere at receiver B

C is the hidden terminal to A

Distance

Signalpower

SINR threhold

Important: X has heard A, but should not defer transmission to Y

X is the exposed terminal to AY

Distance

Signalpower

SINR threhold

A Project Idea!

Sensitivity threshold

Distance

Signalpower

SINR threhold

Sensitivity threshold

A Project Idea!Will this solve the wireless MAC problem? Do not transmit in this region

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

CTS = Clear To Send

RTS = Request To Send

IEEE 802.11 with Omni Antenna

Ksilenced

silenced

silencedData

But is that enough?

RTS/CTS

Does it solve hidden terminals ? Assuming carrier sensing zone =

communication zone

E does not receive CTS successfully Can later initiate transmission to D.Hidden terminal problem remains.

Hidden Terminal Problem

How about increasing carrier sense range ?? E will defer on sensing carrier no

collision !!!

CB DData

Hidden Terminal Problem

But what if barriers/obstructions ?? E doesn’t hear C Carrier sensing does not

CB DData

Exposed Terminal

B should be able to transmit to A RTS prevents this

CTSRTS

Exposed Terminal

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

CTSRTS

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

Questions?

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

An Energy-Efficient MAC Protocol for Wireless Sensor Networks (S-MAC)

Wei Ye, John Heidemann, Deborah Estrin

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

Avenues to Reduce Energy Consumption

(1) Periodic listen and sleep(2) Collision avoidance(3) Overhearing avoidance(4) Message passing

(1) Periodic Listen and Sleep

The main idea Put nodes to sleep periodically

Called “Duty Cycles”

However, ensure that sleep/wake-up is synchronous

Listen for SYNC

Listen/Sleep Schedule Assignment

Choosing Schedule (1)

Listen

Go to sleep after time t

Listen

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

Listen for SYNC Go to sleep after time t2

Listen for SYNC

Listen/Sleep Schedule Assignment

Choosing Schedule (2)

Listen

Go to sleep after time t1

Listen

Broadcasts

Listen

Broadcasts

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

Keeping Clocks in SYNC

SYNC packets must not collide Reserve separate time window for SYNC

transmission

(2) Collision Avoidance

Identical to 802.11 RTS/CTS Virtual carrier sense (NAV) Physical carrier sense

(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

(4) Message Passing

How to transmit long message? Transmitting one long message is inefficient Many small packets with RTS/CTS/ACK for

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

Acknowledgment to Pro. Jun Yang

Neighbors can sleep for whole message

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

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: In light traffic status, nodes keep listening for quite a long time

Heavy Traffic Light Traffic

SYNC overhead

Overhearing avoidance still benefit

Questions?

Studied MAC protocols till now

Another important challenge:How does a packet get transported end to

i.e., How do you perform Routing

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

Sensor sources

Sensor sink

Directed Diffusion

A sensor field

Directed Diffusion

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)

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 ?

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 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

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

Exploratory Gradient

EventEvent

LowLow

Exploratory RequestGradient

Bidirectional gradients established on all links through flooding

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

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

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

Src AC

Link A-M lossyA reinforces BB reinforces C …D need notA (–) reinforces MM (–) reinforces D

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

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

Average Dissipated Energy

In-network aggregation reduces DD redundancy Flooding poor because of multiple paths from source to

flooding

DiffusionMulticast

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

collision

flooding

Diffusion

Multicast

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

reinforcement

Event Delivery Ratio under node failures

10%20%

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

Rumor Routing LEACH SPIN

Some other proposals for sensor routing

Rumor Routing

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

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

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

The SPIN 3-Step Protocol

AADVREQDATA

DATADA

Notice the color of the data packets sent by node B

DATADA

SPIN effective when DATA sizes are large : REQ, ADV overhead gets amortized

SmartGossip: A Reliable Broadcast Service for Wireless Sensor

Networks

Romit Roy ChoudhuryDept. of ECE, Duke University

Joint work withPradeep Kyasanur (Google)

Indranil Gupta (UIUC)

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

Several approaches evolved over time

Approaches

Complexalgo

BroadcastStorm

Single pointof failures

LoadBalance

Recent Past

Gossiping = Probabilistic flooding Nodes forward with probability, p

Source

Recent Past

Gossip based broadcast Nodes forward with probability, p

Source

Recent Past

Source

Recent Past

Source

HeadsHeads

Recent Past

Source

HeadsHeads

Recent Past

Source Heads

HeadsHeads

Recent Past

Source Heads

HeadsHeads

Recent Past

Source Heads

HeadsHeads

Recent Past

Source Heads

HeadsHeads

Recent Past

Source Heads

HeadsHeads

Recent Past

Source Heads

HeadsHeads

TailsFor carefully chosen ‘p’

the message reaches all nodes in minimal transmissions

1. Simple, 2. Fault tolerant3. Load-balanced

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

We Ask …

Even if topology is homogeneous It may change over time due to failure and

mobility

We Ask …

mobility

Say computed p = 0.85

We Ask …

mobility Fails

We Ask …

mobility

15% of packetswill not reach these nodes

We Ask …

mobility

Finally, what if topology is not known a priori ? How can you choose “p” ?

A broadcast service necessary that customizes itself to the underlying topology

andrepairs itself with failures and mobility

We Argue …

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

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

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

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

Deducing Relationships

S A B C

SASASA Parent = {A}

Parent = {A}

Child = {A}

Parent = {A}

Child = {A}

S A B C

ABABAB

Sibling = {B}

Child = {B} Parent = {B}

Parent = {A}

Child = {A}

S A B C

Sibling = {B}

Child = {B} Parent = {B}

Parent = {A}

Child = {A}

S A B C

Sibling = {B}

Child = {B,E} Parent = {B,E}

Sibling = {E}

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

Parent={B,E}

0.99 = ( 1 – (1 - p)k )

S A B C

p = 0.9

p = 0.9p = 1.0

p = 1.0p = 1.0

0.99 = ( 1 – (1 - p)k )

S A B C

p = 0.9

p = 0.9p = 1.0p = 1.0

The Bigger Picture

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

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

Percolation

Smart Gossip

Adaptive Overhead

Adaptive Neighbor

Forwarding Overhead

Adaption to Node Failures

Nodes gossip more to compensate for other failing nodes

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

Questions?

Percolation

Smart Gossip

Adaptive Overhead

Adaptive Neighbor

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

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

1 wireless sensor networking (understanding the radio, mac, & routing protocols) romit roy...

Documents

1 computer network architecture ece 356 fall 2012 romit roy...

1 network layer overview ece 256 spring 2008 romit roy...

1 wireless medium access control romit roy choudhury...

1 utilizing beamforming antennas for wireless multi-hop...

1 realtime location privacy via mobility prediction creating...

ripple: communicating through physical vibration ·...

he wang, xuan bao, romit roy choudhury, srihari nelakuditi...

1 wireless networking & mobile computing ece 256, cs 215...

mobility assisted networking romit roy choudhury

satellites in our pockets: an object positioning system...

listening through a vibration motor · pdf filelistening...

1 networking primer - transport layer ece 256 spring 2009...

1 computer network architecture ece 156 fall 2011 romit roy...

1 upcoming topics and projects romit roy choudhury dept. of...

surroundsense: mobile phone localization via ambience...

1 wireless networking & mobile computing ece 256, cs 215...

listening through a vibration motor - university of...

poster: networked acoustics around human ears · poster:...

1 the importance of being wireless romit roy choudhury

1 surroundsense: mobile phone localization via ambience...