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

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

3. 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 ?
Rely on (unreliable) individual sensors
8/26/2019

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

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

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

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

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

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

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

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

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

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

14. 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 ’s EDCF
Acquire
Channel
Idle
Time
BASE_DIFSPRI CW
Avoidance
Contention
Exponential Backoff
Transmission
8/26/2019

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

16. 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: , extended with prioritization
8/26/2019

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

36. Questions?
8/26/2019