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

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

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

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

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

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

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 }

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

SNGF

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

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

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

Backpressure Rerouting based on MAC Layer Feedback & SNGF ID Delay 5 0.1S 7 0.4S Node 6's NT Packet (to 4) 6 Beacon 7 ID Delay 5 0.5S 2 0.1S 4 0.1S 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

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

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()

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

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

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

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

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

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

RAP: Prioritized MAC Collision Avoidance (CA) Contention 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)

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)

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)

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

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

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?