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

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

ICDCS 2003

Source: T. He ICDCS 2003

Motivation: Why real-time communication?

Sensor 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) Bus technology 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 (Ad hoc On Demand Distance Vector

Routing) DSR (Dynamic Source Routing) LAR (Location Aided Routing): Flood a route

request in an expected zone

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 RAP implicitly assumes perfect wireless links

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

support 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 Uniform desired speed across the network

Speed Miss One hop relay speed violates the set point Packet loss due to collision or congestion

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

_)(

Speed (or progress) supported by neighbor j

SNGF

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

Higher speed Higher probability If no node in FSi can support the set

point, (1) do backpressure rerouting by transmitting on-demand backpressure beacons and (2) reduce the packet relay ratio via NFL

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)

Traffic from nodes 4 to 6 not affected

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

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 Only triggered when all neighbors suffer misses

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

Performance evaluation: Tested approaches AODV, DSR and GF SPEED-S

Forward a packet to the node with max single hop speed

No backpressure rerouting SPEED-T

Forward a packet to the node with min single hop delay

No backpressure rerouting

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

Simulation Setup 1 1 base station at the middle of the right

side of the terrain 6 nodes, randomly chosen from the left

side of terrain Each node generates 1 packet/s

At 80s, generate traffic between two randomly chosen nodes in the middle of the terrain and stop doing this at 150s Increase the flow rate from 0 to 100

packets/s

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

Simulation Setup 2 for void avoidance experiments

To avoid packet losses due to congestion, use only four flows with a rate of 0.5 packets/s

To change the network density, increase the side length of the terrain in steps of 50m

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)

Possible Research Issues

SPEED assumes that each node knows its location. What if it’s not the case?

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 Optimal number of sensors to minimize energy

consumption, while detecting events

Possible Research Issues

Derive feasible deadlines Admission control & adaptive deadlines

Differentiated service MMSPEED: INFOCOM ’05

Speed differentiation & network resource conservation via data aggregation

How to implement reliable area-multicast and anycast?

Prediction based on current & historic sensor data

Just-in-Time Scheduling for Real-Time Sensor Data Dissemination

K. Liu, N. Abu-Ghazaleh, KD Kang

PerCom 2006

Motivation RAP (a real-time MAC protocol) prioritizes

packets but not delayed High contention due to bursty traffic can result

in increasing transmission & queuing delay What if all packets have the highest priority?

MAC level solutions cannot consider queuing delay at routing layer that can significantly impact E2E delay under overload

Role of routing in the success of real-time data dissemination is not sufficiently examined

Geographic forwarding is used in RAP and SPEED JiTS considers shortest path routing in addition to GF

Key Contributions

Just-in-Time Scheduling Delay packets at every hop for a duration

of time which is a function of the number of hops to the sink and deadline

Use a full estimate of the delay including the queuing delay at the network layer

Not specialized MAC Just use 802.11 Compare to VMS of RAP

JiTS algorithms Basic:

Static (JiTS-S) E2E deadline is fixed at source Let X = source EETD = distance * ETD (Estimated Transmission

delay) where ETD = time difference between receiving an ACK and packet transmission

Dynamic (JiTS-D) Use ”remaining slack time = deadline – elapsed

time” instead of E2E deadline EETD = remaining distance * ETD

JiTS algorithms (cont’d)

Nonlinear JiTS (JiTS-NL) Allocate more slack to the nodes

closer to the sink R: Remaining distance to the sink O: Average one-hop distance

Performance evaluation in ns-2

Performance evaluation in ns-2

Delayed, Just-in-Time, packet delivery is better than immediate forwarding!

Questions?