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

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

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) • Bus technology • 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 (Ad hoc On Demand Distance Vector Routing) • DSR (Dynamic Source Routing) • LAR (Location Aided Routing): Flood a route request in an expected zone

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

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

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

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

10. Choose the node closest to the destination in FS More appropriate for real-time communication than AODV or DSR Background – GF 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 support 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 • 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

16. SNGF Speed (or progress) supported by neighbor j

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

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

19. ID Delay 5 0.1S 7 0.4S Node 6's NT Beacon ID Delay 5 0.5S 2 0.1S 4 0.1S Packet 1 Packet 2 Node 3's NT Packet 1 Packet 2 Packet 2 Packet 2 Backpressure Rerouting based on MAC Layer Feedback & SNGF Packet (to 4) 6 7 Boo 1 3 Delay 5 9 2 3 Packet 2 10 12 4 11 Traffic from nodes 4 to 6 not affected

20. API UniCast MultiCast AnyCast Last Mile Process Backpressure NFL SNGF Rerouting Delay Beacon Neighbor Table Estimation Exchange MAC 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

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

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

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

24. Evaluations: Simulation Setup -1

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

26. Congestion Avoidance (Heavy Congestion) Delay: SPEED performs best Delay: SPEED-T > GF,SPEED,SPEED-S Delay: AODV>DSR>SPEED #E2E Delay vs. Congestion-Level

27. Control Overhead (Heavy Congestion) #Packets: DSR>SPEED>GF=SPEED-T=SPEED-S (Light Congestion) #Packets: DSR<GF,SPEED,SPEED-S,SPEED-T SPEED uses periodic & on-demand beacons #Control Packets vs. Congestion-Level

28. 40 Energy Consumption 35 30 25 20 AODV 15 DSR SPEED 10 GF 5 SPEED-S Rate (P/S) SPEED-T 0 0 10 20 30 40 50 60 70 80 90 100 Energy Consumed vs. Congestion-Level Energy Consumption Energy Consumed: AODV>DSR>SPEED,GF,SPEED-S,SPEED-T Heavy Congestion : SPEED>GF,SPEED-S Light Congestion: SPEED=GF=SPEED-S When Rate<60, SPEED has more Control Packets than DSR, but consumes less energy than DSR. Why???

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

30. 100% 95% Delivery Rate 90% DSR SPEED 85% GF SPEED-S 80% SPEED-T 75% 70% 15.5 13.9 12.6 11.4 10.4 9.5 8.7 8.0 Density (nodes per radio circle) Void Avoidance Delivery Rate: DSR>SPEED>SPEED-S=GF=SPEED-T Delivery Ratio vs. Node Density

31. Reminder: RAP (Real-Time MAC) D 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

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

33. 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 • Prioritized MAC • Velocity=Distance/Deadline • Distance (Source,Destination) • Reflect local emergency • Traffic Control • VMS?? (No) • Ordinary, best-effort MAC • SPEED=Distance/Delay • Distance (node, neighbor) • Reflect communication capacity • Traffic Control • SNGF • MAC Layer adaptation • Backpressure Rerouting SPEED vs. RAP Similarities Differences

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

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

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

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

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

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

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

41. Performance evaluation in ns-2

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

43. Questions?