RAP:A Real-Time Communication Architecture for Large-Scale Wireless Sensor Networks

1. RAP:A Real-Time Communication Architecture for Large-Scale Wireless Sensor Networks C. Lu, B.M. Blum, T.F. Abdelzaher, J.A. Stankovic, and T. He Adapted Chenyang Lu’s slides

2. Design Requirements • Minimize end-to-end deadline miss ratio • Support distributed micro-sensing • High-level service API • Large scale, high density • Scalability is key • Extreme resource constraints • Minimal overheads

3. ID-based From ID to ID What is the reading of sensor 125.111.1.5? Rely on (unreliable) individual sensors Location-based From location to location What is the virus density in south terminal of airport? Individual sensors NOT important Local coordination: Sensors in interested area aggregate data Sensor-base comm: Send aggregated result to base station Location-based Communication

4. RAP: Real-time locAtion-based Protocols Sensing/Control Application Query/Event Service APIs Query/Event Service Coordination Service Location-Addressed Protocol Geographic Forwarding Velocity Monotonic Scheduling Prioritized MAC

5. Query/Event Service Query/Event API Coordination Service Location-Addressed Protocol Geographic Forwarding Velocity Monotonic Scheduling Prioritized MAC • RAP provides the following query/event service APIs. • query { attribute_list, area, timing_constraints, querier_loc } • register_event { event, area, query } • Assume that the locations of the base stations are fixed.

6. Query/Event Service Example Coordination Service Location-Addressed Protocol Geographic Forwarding Velocity Monotonic Scheduling Prioritized MAC register_event { virusFound(0,0,100,100), // area to post event query { // query to be triggered virus.count, // attribute area=(x-1,y-1,x+1,y+1), // query area period=1.5, deadline=5, // timing info base=(100,100) // base station location } } • Registers a virus_count query for a virus_found event. • If any viruses are found in a rectangular area (0,0,100,100), return the average density of the viruses of the 2*2 square area centered at the event location (Xevent,Yevent) • Peirod: 1.5 sec. • End-to-end deadline: 5 sec

7. Query/Event Service Geographic Forwarding Coordination Service Location-Addressed Protocol Geographic Forwarding Velocity Monotonic Scheduling Prioritized MAC Closest to C • Local state  Scalability – Routing decisions are local • Dense network  Efficient greedy forwarding works well • Dense network  #hop proportional to distance • Location-based comm.  No location directory service A C E

8. GF always chooses the node that is closest to the destination in FS. Background – GF s d

9. Deadline & Distance Aware • FCFS scheduling does not work well for real-time communication • Deadline-aware • The shorter the deadline, the higher the packet priority • Distance-aware • The longer the distance, the higher the packet priority

10. Query/Event Service Velocity Coordination Service Location-Addressed Protocol Geographic Forwarding Velocity Monotonic Scheduling Prioritized MAC • Timing constraint: deadline • Location constraint: distance to destination • Requested Velocity • Embody both constraints • Reflect local urgency • Velocity Monotonic Scheduling (VMS): Priority = Requested Velocity

11. Example D dis = 90 m; D = 2 s V = 45 m/s HIGH Priority A C B dis = 60 m; D = 2 s V = 30 m/s LOW Priority

12. Velocity Monotonic Scheduling Static VMS • Fixedvelocity on each hop • V = dis(x0,y0,xd,yd)/D • Source location: (x0,y0) • Destination location: (xd,yd) • End-to-end deadline: D Dynamic VMS • Adaptvelocity at intermediate node based on progress • Vi = dis(xi,yi,xd,yd)/Si • Velocity at node: Vi • Location of node i: (xi,yi) • Slack: Si = D – elapsed time

13. Priority Queue • Single Queue • Ordered by priority • If queue is full, higher priority incoming packets overwrite lower priority • Implement a priority queue: Overhead is (log n) where n is the number of packets in the queue • Multiple Queue • Priority corresponds to a range of requested velocities. A packet is first mapped to a priority, and then inserted into the FIFO queue based on its priority • Packets that miss their deadlines are useless -> Actively drop packets that have missed their deadlines to avoid wasting bandwidth

14. Query/Event Service Prioritized MAC Coordination Service Location-Addressed Protocol Geographic Forwarding Velocity Monotonic Scheduling Prioritized MAC • Collision Avoidance (CA) • Channel idle  wait for DIFS =BASE_DIFSPRI • Packets with a higher priority (corresponding to a smaller PRIORITY value) on average choose a smaller waiting period. • Contention • Collision (No CTS or No ACK)CW = CW*(2+(PRI-1)/MAXPRI) • MAXPRI is the maximum value of priority (corresponding to the lowest priority). The backoff counter of a node with a pending lower priority packet increases faster than a node with a pending packet with a higher priority. • Similar to 802.11’s EDCF Acquire Channel Idle Time BASE_DIFSPRI CW Avoidance Contention Exponential Backoff Transmission

15. Simulation in GloMoSim:Biometric Sensing • 100 nodes on 136X136 m2 • Periodic query count on 31 nodes; detail on 15 nodes Base Station Hot Regions (sources) FAR

16. Workload • Network (roughly approximate MICA mote) • Communication range: 30.5 m • Packet size: 32B (count), 160 B (detail) • Bandwidth: 200 kbps (> MICA) • Protocols • Routing: DSR (Dynamic Source Routing), GF (Geographic Forwarding) • Scheduling: FIFO, DS (Deadline-based), SVM, DVM • MAC: 802.11, extended 802.11 with prioritization

17. Flow of Packets Base station Base station GF – Flow of Packets DSR – Flow of Packets

18. Deadline Miss RatioOverall GlomoSim simulation (deadline: detail: 5 s, count: 10 s)

19. Deadline Miss Ratio: FAR hot region GlomoSim simulation (deadline: detail: 5 s, count: 10 s)

20. Distance Fairness • SVM provides “fairer” service to remote sensors • Critical for scalability of sensor networks!

21. Conclusion • Velocity Monotonic Scheduling • Reduce end-to-end deadline miss ratio • Fair service to remote sensors • Event/query service API’s • High-level abstraction for distributed microsensing • Location-based protocol stack • Scalable • Small protocol overhead

22. Discussions • VMS • Best-effort  No guarantee • What if there’s a void? GF does not work • Is velocity the right trade-off between distance and time? • How about ETX or other link quality metrics? • DVM is worse than SVM? • What if network is congested? • Just-in-Time Scheduling • Location of the base station is fixed

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

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

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

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

27. Performance evaluation in ns-2

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

29. Questions?