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?