SPEED: A Stateless Protocol for Real-Time Communication in Sensor Networks

T. He, J. A. Stankovic, C. Lu, T. Abdelzaher

Motivation: Why real-time communication?

Sense networks monitor the real world

Real-time constraints may exist Surveillance system Battlefield monitoring Earthquake response system Smart hospitals

Motivation

Freshness of data Promptness of Command and

Control

3

Need for a new real-time communication method Existing real-time communication

solutions are inappropriate IntServ: too expensive for sensor networks

Resource reservation Per-flow information Sensor nodes are referred to by attributes rather

than unique ID’s DiffServ Control Area Network

Small scale (mainly local area) Many restrictions for predictability

Need for a new real-time communication method (cont.)

MANET protocols Time insensitive Less strict energy constraints Route discovery may incur a lot of

delay and energy consumption AODV DSR LAR

Design Goals

Provide E2E delay guarantee E2E delay is proportional to the distance

between the source and destination Per hop speed guarantee Probabilistic soft real-time guarantees

Impossible to provide hard guarantees SPEED actually improves but does not guarantees

the E2E delay Support a desired delivery speed across the

sensor network

Design Goals

Localized behavior An action by a node does not affect

the whole network Contrasts to MANET protocols (e.g.,

AODV & DSR) Stateless architecture

Only maintains immediate neighbor info.

Design Goals Minimum MAC layer support

SPEED does not require real-time/QoS-aware MAC support

Congestion Control Traffic patterns may fluctuate significantly Short-term rate adjustment via feedback control Long-term backpressure re-routing

Void Avoidance Backpressure re-routing

Traffic Load Balancing Non-deterministic forwarding

Scalability Issues

Time Scalability GF (Geographic Forwarding) to avoid

route discovery E2E speed is proportional to the

distance between the source & destination

s d

Background – GF Choose the node closest to the destination in FS More appropriate for real-time communication than

AODV or DSR

Scalability Issues (Cont.) Memory Scalability

No per-flow state No per-destination route cache Just keep (immediate) neighbor table

Energy Scalability No network-wide flooding Nondeterministic forwarding to

balance energy consumptions

Assumptions

Each node is aware of its location Periodic beacons to exchange

location info. Beaconing rate can be very low when

sensor nodes are static Senor network is dense enough to

supporting greedy geographic routing, while avoiding a void

SPEED Architecture

Last Mile Process

SNGFBackpressure

ReroutingNFL

On DemandBeaconing

APIUniCast MultiCast AnyCast

Best effort MAC

MAC DelayEstimation

NeighborTable

SNGF (Stateless Non-deterministic Geographic Forwarding)

Neighbor Set of Node i NSi = {node| distance (node, node i ) R}

Forwarding Set of Node i FSi (Destination) = {node NSi | L – L_next > 0 }

L

j L-L_Next

NSFS

i D

m

k

Definitions

Speed Set Point Desired speed toward the destination

Speed Miss One hop relay speed violates the set

point Miss Ratio

#packet misses in a specified period

SNGF

E2E Di stance

j

FS

i D

Actual Speed

Speed todestination(Set Point )

E2E Delay is bound by E2E Distance/Speed SetPoint

ji

ji HopDelay

nextLLnDestinatioSpeed

_)(

SNGF

Forward a packet to a node that is in FSi and can support the speed set point Probabilistically select one node The higher its speed, the higher its

probability If no node in FSi can support the set

point, reduce the relay ratio via NFL

NFL (MAC Layer Feedback)

- SNGFNeighbor

Nodes

Beacon

MR Setpoi nt

Neighborhood Table

Del ay Esti mati on Beacon

SELF Neighbors

MAC Feedback

Back Pressure Beacon

Relay RatioController

Rel ayRati o

mi ssrati o

on/ off

Delay Estimation: Delay= Round Trip Time – Receiver Side Processing Time

On/Off Switch Back-Pressure Rerouting

Last Mile Process

SNGFBackpressure

ReroutingNFL

BeaconExchange

APIUniCast MultiCast AnyCast

MAC

DelayEstimation

NeighborTable

Relay Ratio Control 01 i

i eifN

eKu

01 ieifu

Backpressure Rerouting based on MAC Layer Feedback & SNGF

23

5

9

10

7

Delay

11

Boo

SPEED20

11030

115

Node 5's NT

Delay0.5s0.1s0.4s0.1s

ID97

103

Packet

Packet

Source

Destination

Backpressure Rerouting based on MAC Layer Feedback & SNGF

23

5

9

10

7

DelayBooID Delay

5 0.5S 2 0.1S 4 0.1S

Node 3's NT

411

6

13

ID Delay 5 0.1S 7 0.4S

Node 6's NT

12Packet 1

Packet 1

Beacon

Packet 2

Packet 2

Packet 2

Packet 2

Packet 2

Packet (to 4)

Void Avoidance In a similar way it deals with traffic congestion.

Backpressure beacon (ID, Destination, Positive Infinity) Greedy: It may not find a path even if it exists in the

worst case

Last Mile Process

SNGFBackpressure

ReroutingNFL

BeaconExchange

APIUniCast MultiCast AnyCast

MAC

DelayEstimation

NeighborTable

1

2

3

4 5

Last Mile Process AreaMulticastSend(Center position, radius,

deadline, packet) AreaAnyCastSend(Center position, radius,

deadline, packet) UnicastSend(Global_ID,deadline,packet) SpeedReceive()

Last Mile Process

SNGFBackpressure

ReroutingNFL

BeaconExchange

APIUniCast MultiCast AnyCast

MAC

DelayEstimation

NeighborTable

Evaluations: Simulation Setup -1

Components Setting

Simulator & TestBed GloMoSim & Berkeley Motes

Routing SPEED, AODV, DSR, GF (Max Progress )SPEED-S (Max Speed ), SPEED-T ( minimum delay)

MAC Layer 802.11

Bandwidth 200Kb/s

Payload size 32 Byte

TERRAIN (200m, 200m)

Node number 100

Node Placement Uniform

Radio Range 40m

Runs 16

Congestion Avoidance

40

90

140

190

240

290

0 10 20 30 40 50 60 70 80 90 100

Rate (P/S)

Del

ay (

MS

)

AODV

DSR

SPEED

40

90

140

190

240

0 10 20 30 40 50 60 70 80 90 100

Rate(P/S)D

elay

(M

S)

SPEED

GF

SPEED-S

SPEED-T

#E2E Delay vs. Congestion-Level#E2E Delay vs. Congestion-Level

Delay: AODV>DSR>SPEED

Delay: SPEED-T > GF,SPEED,SPEED-S

(Heavy Congestion) Delay: SPEED performs best

Control Overhead

#Control Packets vs. Congestion-Level#Control Packets vs. Congestion-Level

0

2000

4000

6000

8000

10000

12000

14000

0 10 20 30 40 50 60 70 80 90 100

Rate (P/S)

#Pac

kets

AODV

SPEED

400

500

600

700

800

900

1000

1100

1200

0 10 20 30 40 50 60 70 80 90 100

Rate (P/S)

#P

ackets

DSR

SP EED

GF

SP EED-S

SP EED-T

SPEED uses periodic & on-demand beacons(Light Congestion) #Packets: DSR<GF,SPEED,SPEED-S,SPEED-T

(Heavy Congestion) #Packets: DSR>SPEED>GF=SPEED-T=SPEED-S

Energy Consumption

Energy Consumed: AODV>DSR>SPEED,GF,SPEED-S,SPEED-TLight Congestion: SPEED=GF=SPEED-SHeavy Congestion : SPEED>GF,SPEED-S

When Rate<60, SPEED has more Control Packets than DSR, but consumes less energy than DSR. Why???

Energy Consumed vs. Congestion-LevelEnergy Consumed vs. Congestion-Level

0

5

10

15

20

25

30

35

40

0 10 20 30 40 50 60 70 80 90 100

Rate (P/S)

AODV

DSR

SPEED

GF

SPEED-S

SPEED-T

Energ

y

Consu

mpti

on

Void Avoidance

Delivery Ratio vs. Node Density Delivery Ratio vs. Node Density

70%

75%

80%

85%

90%

95%

100%

15.5 13.9 12.6 11.4 10.4 9.5 8.7 8.0

Density (nodes per radio circle)

DSR

SPEED

GF

SPEED-S

SPEED-TDeliv

ery

Rate

Delivery Rate: DSR>SPEED>SPEED-S=GF=SPEED-T

Reminder: RAP (Real-Time MAC)

dis = 60 m; D = 2 sV = 30 m/sLOW Priority

dis = 90 m; D = 2 sV = 45 m/sHIGH Priority

A

B

D

CE

Velocity Monotonic Scheduling

RAP: Prioritized MAC

Collision Avoidance (CA)

Contention

Channel idle wait for (IEEE 802.11 (DCF) ) Rand*DIFS (RAP) Rand*DIFS*Prio

Collision (No CTS or No ACK) (IEEE 802.11 (DCF) ) CW=CW*2 (RAP) CW=CW*(2+(Prio-1)/MAX_Prio)

SPEED vs. RAP Soft real-time

No guarantees Ad hoc deployment Dynamic traffic Homogeneous platform

Motes

Soft real-time No guarantees

Ad hoc deployment Dynamic traffic Homogeneous platform

Motes

Sim

ilaritie

sD

iffere

nces

Ordinary, best-effort MAC SPEED=Distance/Delay

Distance (node, neighbor) Reflect communication

capacity

Traffic Control SNGF MAC Layer adaptation Backpressure Rerouting

Prioritized MAC Velocity=Distance/

Deadline Distance (Source,

Destination) Reflect local emergency

Traffic Control VMS?? (No)

Research Issues (Possible Projects)

QoS Metrics other than delay? Energy

How long can a node support the desired speed or reliability?

Bandwidth Reliability Data criticality

Differentiated aggregation, scheduling, resource allocation …

Confidence of event detection Coverage Optimal number of sensors to minimize energy

consumption, while detecting events (if any)

Research Issues (Possible Projects)

Derive feasible deadlines Admission control & adaptive deadlines

Differentiated service MMSPEED: INFOCOM ’05 (Next Class)

Speed differentiation & network resource conservation via data aggregation

How to implement reliable area-multicast and anycast?

Sensor database QoS Prediction based on current & historic sensor

data