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 IDs 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 Higher speed Higher 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)

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? Sensor database QoS 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 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 (contd) 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

Delayed, Just-in-Time, packet delivery is better than immediate forwarding!

Questions?