8/26/2019 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

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 8/26/2019

Location-based Communication 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 ID-based From ID to ID What is the reading of sensor 125.111.1.5? Rely on (unreliable) individual sensors 8/26/2019

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 8/26/2019

Query/Event API RAP provides the following query/event service APIs. 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. 8/26/2019

Example register_event { 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 8/26/2019

Geographic Forwarding 8/26/2019 Query/Event Service Geographic Forwarding Coordination Service Location-Addressed Protocol Geographic Forwarding Velocity Monotonic Scheduling Closest to C Prioritized MAC A C E What if there is holes/obstacles? 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 8/26/2019

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

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 8/26/2019

Velocity Monotonic Scheduling 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 8/26/2019

Example D A C B dis = 90 m; D = 2 s V = 45 m/s HIGH Priority LOW Priority 8/26/2019

Velocity Monotonic Scheduling Static VMS Fixed velocity 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 Adapt velocity 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 8/26/2019

Priority Queue Single Queue Multiple 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 8/26/2019

Velocity Monotonic Scheduling 8/26/2019 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 8/26/2019

Simulation in GloMoSim: Biometric Sensing 8/26/2019 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) 6-7 hop maximum FAR 8/26/2019

Workload Communication range: 30.5 m 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 8/26/2019

Flow of Packets Base station Base station GF – Flow of Packets DSR – Flow of Packets 8/26/2019

Deadline Miss Ratio Overall 8/26/2019 Deadline Miss Ratio Overall GlomoSim simulation (deadline: detail: 5 s, count: 10 s) 8/26/2019

Deadline Miss Ratio: FAR hot region 8/26/2019 Deadline Miss Ratio: FAR hot region GlomoSim simulation (deadline: detail: 5 s, count: 10 s) 8/26/2019

Distance Fairness SVM provides “fairer” service to remote sensors Critical for scalability of sensor networks! 8/26/2019

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 8/26/2019

Research Issues VMS What if network is congested? DVM is worse than SVM? No schedulability analysis or admission control  No guarantee Is velocity the right trade-off between distance and time? How about ETX? Should we consider potential retransmissions for real-time routing? VMS is not a routing but a scheduling scheme! What if there’s a void? GF does not work What if network is congested? Just-in-Time Scheduling Location of the base station is fixed 8/26/2019

Mobility-based communication in wireless sensor networks E. Ekici, Y. Gu, D. Bozdag

Common approaches Connectivity Network lifetime Deploy a sufficient number of sensors or use nodes with long-range communication capabilities to maintain a connected graph Network lifetime Energy efficient protocols & algorithms Energy replenishment 8/26/2019

Motivations Use mobile platforms, e.g., soldiers & UAVs in a battlefield, animals in habit monitoring, and buses in traffic monitoring, to maintain connectivity and improve network lifetime Connectivity: Use mobile devices to carry info between isolated parts in WSNs Energy efficiency: Use mobile devices to reduce multihop routing 8/26/2019

Representative approaches Mobile base station (MBS)-based solutions Use a mobile sink MBS during operation Still multihop routing but more uniform energy consumptions across the network No long-term buffering is required Mobile data collector (MDC)-based solutions A mobile sink MDC visits sensors Buffer data at sources until the MDC visits and downloads the info via one hop wireless communication 8/26/2019

Representative approaches Rendezvous-based solutions Hybrid approach Sensor data are sent to a rendezvous points close to the path of mobile devices Data are buffered at rendezvous points until downloaded by mobile devices 8/26/2019

MBS-based approaches Base station relocation [2] Change MBS locations along the periphery of the sensing filed to balance the energy consumption of individual sensors Two objective functions Total energy consumption of all sensors  More data are collected throughout the network lifetime (according to simulation results) Max energy consumption of any sensor  Longer network lifetime (defined to be the time until the first node dies) 8/26/2019

Joint mobility and routing [3] Analytic work Assume sensors are deployed in a circle Network lifetime can be improved even when an optimally placed fixed sink, i.e., sink located in the center of the circle, is replaced by a randomly moving MBS Optimal movement of MBS is to follow the periphery when the deployment area is circular Best way to disperse network flows 8/26/2019

Joint mobility and routing [3] (Cont’d) Heuristic for joint mobility and routing MBS moves on a circular trajectory inside the deployment region Nodes inside the trajectory send their packets to MBS on shortest paths Nodes outside the trajectory use paths composed of arcs followed by straight lines directed toward the trajectory center to reach MBS to utilize residual energy in outer nodes 8/26/2019

MDC-based solutions Sparse WSNs are used to collect data in large areas Observation of traffic density in a big city Sensors are placed on roads to observe vehicles A small number of sensors is sufficient as the number of cars along a road segment is highly correlaed Utilizing many relay nodes or using long-range comm interface can be expensive Instead, use MDCs that gathers data from sensors by visiting them No multihop routing Long-term buffering 8/26/2019

Data Mules [6] MDCs move randomly to collect data opportunistically from sensors in their direct comm range Carry collected data to a wireless access point Msg transfer delay is unbounded as MDCs move randomly 8/26/2019

Predictable data collection [7] Data are collected by vehicles which pass near sensors Sensors know the trajectory of MDCs, e.g., buses Predict when data transfer will take place Sensors can sleep until the predicted transfer time 8/26/2019

Mobile element scheduling [8] Sensors may generate data at different rates MDC called mobile element (ME) is scheduled to visit sensors such that no sensor buffer overflow occurs ME scheduling is NP-complete EDF: Earliest buffer overflow deadline first Minimum Weight Sum First: Consider distances between nodes in addition to buffer overflow deadlines  Back-and-forth movements btwn far away nodes are not avoided completely Analogous to real-time disk scheduling 8/26/2019

Rendezvous-based solutions When WSNs consist of isolated network partitions, data generated in a partition can be accumulated at designated sensors that buffer data until they are relayed to a MDC Can save energy in a connected WSN too Relayed data collection [5] MDC traverses a linear path and collect data from designated sensors when it enters their transmission range Remaining sensors relay their data to the nodes closest to the MDC path via multihop routing 8/26/2019

Questions? 8/26/2019