1. T. He, J. A. Stankovic, C. Lu, T. Abdelzaher
SPEED: A Stateless Protocol for Real-Time Communication in Sensor Networks
T. He, J. A. Stankovic, C. Lu, T. Abdelzaher

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

3. Motivation
Freshness of data
Promptness of Command and Control 3

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

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

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

7. Design Goals Localized behavior Stateless architecture
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.

8. Design Goals Minimum MAC layer support Congestion Control
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

9. Scalability Issues Time Scalability
GF (Geographic Forwarding) to avoid route discovery
E2E speed is proportional to the distance between the source & destination

10. Background – GF s d Choose the node closest to the destination in FS
More appropriate for real-time communication than AODV or DSR s d

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

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

13. SPEED Architecture

14. 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 }

15. Definitions Speed Set Point Speed Miss Miss Ratio
Desired speed toward the destination
Speed Miss
One hop relay speed violates the set point
Miss Ratio
#packet misses in a specified period

16. SNGF

17. SNGF
Forward a packet to a node that is in FSi and can support the speed set point
Probabilistically select one node
Higher speed  Higher probability
If no node in FSi can support the set point, reduce the relay ratio via NFL

18. NFL (MAC Layer Feedback)
Last Mile Process
SNGF
Backpressure
Rerouting
NFL
Beacon
Exchange
API
UniCast
MultiCast
AnyCast
MAC
Delay
Estimation
Neighbor
Table
NFL (MAC Layer Feedback)
Delay Estimation: Delay= Round Trip Time – Receiver Side Processing Time
Relay Ratio Control
On/Off Switch
Back-Pressure Rerouting

19. Backpressure Rerouting based on MAC Layer Feedback & SNGF
Node 5's NT
Delay
0.5s
0.1s
0.4s ID 9 7 10 3
SPEED 20
110 30
115 7 11
Packet
Destination 5
Packet 9 2
Delay 3 10
Source
Boo

20. Backpressure Rerouting based on MAC Layer Feedback & SNGF
ID Delay S S
Node 6's NT
Packet (to 4) 6
Beacon 7
ID Delay S S S
Node 3's NT
Boo
Delay 1 3 5
Packet 2
Packet 1 9 2
Packet 1
Packet 2 3 10
Packet 2 12
Packet 2 4
Packet 2 11

21. Void Avoidance In a similar way it deals with traffic congestion.
Last Mile Process
SNGF
Backpressure
Rerouting
NFL
Beacon
Exchange
API
UniCast
MultiCast
AnyCast
MAC
Delay
Estimation
Neighbor
Table
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 1 2 5 4 3

22. Last Mile Process
SNGF
Backpressure
Rerouting
NFL
Beacon
Exchange
API
UniCast
MultiCast
AnyCast
MAC
Delay
Estimation
Neighbor
Table
Last Mile Process
AreaMulticastSend(Center position, radius, deadline, packet)
AreaAnyCastSend(Center position, radius, deadline, packet)
UnicastSend(Global_ID,deadline,packet)
SpeedReceive()

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

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

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

26. Energy Consumed vs. Congestion-Level
Energy Consumption
Energy Consumed vs. Congestion-Level 5 10 15 20 25 30 35 40 50 60 70 80 90
100
Rate (P/S)
AODV
DSR
SPEED GF
SPEED-S
SPEED-T
Energy Consumption

27. Density (nodes per radio circle)
Void Avoidance
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-T
Delivery Rate
Delivery Ratio vs. Node Density

28. Reminder: RAP D E A C B Velocity Monotonic Scheduling
dis = 90 m; D = 2 s
V = 45 m/s
HIGH Priority E A C B
Velocity Monotonic Scheduling
dis = 60 m; D = 2 s
V = 30 m/s
LOW Priority

29. RAP: Prioritized MAC Collision Avoidance (CA) Contention
Channel idle  wait for
(IEEE (DCF) ) Rand*DIFS
(RAP) Rand*DIFS*Prio
Contention
Collision (No CTS or No ACK) 
(IEEE (DCF) ) CW=CW*2
(RAP) CW=CW*(2+(Prio-1)/MAX_Prio)

30. SPEED vs. RAP Similarities Differences Soft real-time No guarantees
Ad hoc deployment
Dynamic traffic
Homogeneous platform
Motes
Differences
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
VMS?? (No)

31. Possible Research Issues
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)

32. Possible Research Issues
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?
Prediction based on current & historic sensor data

33. Just-in-Time Scheduling for Real-Time Sensor Data Dissemination
K. Liu, N. Abu-Ghazaleh, KD Kang
PerCom 2006

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

35. 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
Compare to VMS of RAP

36. JiTS algorithms Basic: Static (JiTS-S) Dynamic (JiTS-D)
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

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

38. Performance evaluation in ns-2

39. Performance evaluation in ns-2
Delayed, Just-in-Time, packet delivery is better than immediate forwarding!

40. Questions?