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? Sense 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 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 supporting greedy geographic routing, while avoiding a void

SPEED Architecture

SNGF (Stateless Non-deterministic Geographic Forwarding)  Neighbor Set of Node i  NS i = {node| distance (node, node i )  R}  Forwarding Set of Node i  FS i (Destination) = {node  NS i | L – L_next > 0 }

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

SNGF

Forward a packet to a node that is in FS i and can support the speed set point Probabilistically select one node The higher its speed, the higher its probability If no node in FS i can support the set point, reduce the relay ratio via NFL

NFL (MAC Layer Feedback) Delay Estimation: Delay= Round Trip Time – Receiver Side Processing Time On/Off Switch Back-Pressure Rerouting Relay Ratio Control

Backpressure Rerouting based on MAC Layer Feedback & SNGF Delay 11 Boo SPEED Node 5's NT Delay 0.5s 0.1s 0.4s 0.1s ID Packet Source Destination

Backpressure Rerouting based on MAC Layer Feedback & SNGF Delay Boo ID Delay 5 0.5S 2 0.1S 4 0.1S Node 3's NT ID Delay 5 0.1S 7 0.4S Node 6's NT 12 Packet 1 Beacon Packet 2 Packet (to 4)

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 AreaMulticastSend(Center position, radius, deadline, packet) AreaAnyCastSend(Center position, radius, deadline, packet) UnicastSend(Global_ID,deadline,packet) SpeedReceive()

Evaluations: Simulation Setup -1 ComponentsSetting Simulator & TestBedGloMoSim & Berkeley Motes RoutingSPEED, AODV, DSR, GF (Max Progress ) SPEED-S (Max Speed ), SPEED-T ( minimum delay) MAC Layer Bandwidth200Kb/s Payload size32 Byte TERRAIN(200m, 200m) Node number100 Node PlacementUniform Radio Range40m Runs16

Congestion Avoidance #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 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-T Light Congestion: SPEED=GF=SPEED-S Heavy Congestion : SPEED>GF,SPEED-S When Rate<60, SPEED has more Control Packets than DSR, but consumes less energy than DSR. Why???

Void Avoidance Delivery Ratio vs. Node Density Delivery Rate: DSR>SPEED>SPEED-S=GF=SPEED-T

Reminder: RAP (Real-Time MAC) dis = 60 m; D = 2 s V = 30 m/s LOW Priority dis = 90 m; D = 2 s V = 45 m/s HIGH Priority A B D C E Velocity Monotonic Scheduling

RAP: Prioritized MAC Collision Avoidance (CA) Contention Channel idle  wait for (IEEE (DCF) )Rand*DIFS (RAP) Rand*DIFS*Prio Collision (No CTS or No ACK)  (IEEE (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 Similarities 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 Traffic Control VMS?? (No)

Research Issues (Possible Projects) 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)

Research Issues (Possible Projects) 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? Sensor database QoS Prediction based on current & historic sensor data