RAP and SPEED

1. RAP and SPEED Presented by Octav Chipara

2. Realtime Systems • Concerned with two aspects • Control • RAP • Predictability • SPEED

3. Modeling the sensor networks • A sensor: • Limited memory • MAC layer may provide QoS • Communication: • Scarce bandwidth • Voids exists • Energy intensive • Communication generates congestion hot-spots • end-to-end communication time depends on single-hop delay and the distance it has to travel

4. Modeling the sensor networks • Tight integration with the physical world • Location aware • Communication patterns: • Local coordination • Sensors coordinate with one another [usually by defining a group] in order to aggregate data • Usually involves a small number of hops • Sensor-base communication • Sends data from the local group to the base station • Requires multiple hops

5. RAP

6. Contributions • A high level architecture for large wireless networks • Ability to define queries • Use event services • Velocity Monotonic Scheduling (VMS) • A policy for scheduling packets in a sensor network

7. Design Goals • Provide APIs for micro-sensing and control • Maximize the number of packets meeting their e2e deadlines • Scale well to large number of nodes and hops • Introduce minimum communication overhead

8. RAP Stack

9. Query/Event Service API • Query {attribute list, area, time constraints, querier location} • Register {event, area, query} • Periodically the results will be send back to the querier

10. Location-Addressed Protocol • Connectionless transport layer • Address is based on geographic location • Services: • Unicast • Area multicast • Area anycast

11. Geographic forwarding • Greedy algorithm • Selects the node with the shortest geographic distance to the packet’s destination • At every step the packet gets closer to the destination • Works really good for high density network

12. Velocity Monotonic Scheduling • FCFS policy is generally used in sensor networks • Works poorly for realtime systems • VMS • It is both deadline and distance aware • Assigns priority based on the requested velocity • A higher velocity denotes higher priority

13. Velocity Monotonic Scheduling(2) • Two flavors • Static monotonic velocity (SMV) • V=dist(x0,y0,xd,yd)/D • Dynamic monotonic velocity (DMV) • V=dist(xi,yi,xd,yd)/(D-Tj)

14. MAC –layer prioritization • When communicating multiple host compete for the shared medium • In 802.11b all messages have the same priority • To enforce packet prioritization MAC protocols should provide distributed prioritization on packets from different nodes • We can changed two parameters • The time you can wait after idle • DIFS = BASE_DIFS * PRIORITY • Backoff increase function • CW=CW*(2 + (PRIORITY-1)/MAX_PRIORITY)

15. Experiments • Routing protocols • Dynamic Source Routing (DSR) • Originally designed for ID networks • GF • Location based routing • Scheduling • FCFS • DS – fixed priority based on their e2e deadline • Velocity Scheduling • DVS • SVS

16. Overall Miss Ratio of GF/DSR

17. Impact of scheduling on deadline misses

18. SPEED

19. State of the art • Only a few real-time algorithms exist for sensor networks • Routing based on sensor’s position • GPSR • GEDIR • LAR

20. Design Goals • State • Information regarding the immediate neighbors • Soft Real Time • Provides uniform speed delivery across the network • Q: is this uniform speed guaranteed globally or piece-wise • Q: why would the application want something like this • Minimum MAC Layer support

21. Design Goals • Traffic load-balancing • Localized behavior • Void avoidance

22. Speed Protocol • API • Neighbor beacon exchange scheme • Delay estimation algorithm • Stateless nondeterministic geographic forwarding algorithm • Neighbor feedback loop • Backbone rerouting • Void avoidance • Last mile processing

23. API • AreaMulticastSend(position,radius, packet) • Send a message to all nodes in the specified area • AreaAnyCastSend(position,radius,packet) • Sends a message to at least one node inside the specified area • UnicastSend(Global_ID, packet) • Send a message to the specified ID (id is given by its geographic position) • SpeedReceive()

24. API (2) • Where is the time constraint? • “SPEED aims at providing a uniform packet delivery speed across the sensor network, so that the end-to-end delay of a packet is proportional to the distance between the source and destination. With this service, real-time applications can estimate end-to-end delay before making admission decisions. Delay differentiation for different classes of packets is left as future work.” • Q: if the velocity is imposed piece wise how can we give end-to end guarantees? • Q: By distance we mean Euclidian distance or the Euclidian distance of the path?

25. Neighbor beacon exchange scheme • Periodically broadcasts a beacon to neighbors to exchange local information • In order to reduce traffic we can piggyback the information • Possible enhancement: • Advertising state changes may reduce number of beacons • On-demand beacons • Delay estimation • Back pressure pressure • Fields: • Neighbor ID • Position • Send To Delay

26. Delay estimation algorithm • Due to scarce bandwidth cannot use probe packets • Delay is measured at the sender as the difference between when the packet was queued and its ACK and the processing time on the receiver time • Keeps track of multiple data points to compute the current delay using (EWMA): • intervalavg = intervalavg + w * err • Where: • I is the refresh time sample from this packet • err = I - intervalavg • w is the smoothing constant

27. Delay estimation algorithm (2) • Delay estimation beacon is used to communicate to other neighbors the estimated delay • Hope to make a set of neighboring nodes react to changes in traffic patters [avoid congestion]

28. Neighbor set of node i Forwarding candidate set Where L = d(i, destination) Lnext = d(next, destination) Relay speed SNGF

29. SNFG(2) If (|FSi| > 0) { if (|Viable| > 0) { candidate=choose(Viable(FSi)) send to candidate } else { compute relay ratio if no nodes to support Ssetpoint downstream, drop packet if a random chosen between (0,1) is bigger than the relay ratio } } else { drop packets send pressure beacon upstream }

30. SNFG(3) • Delay Bound = Le2e / Ssetpoint • Where: • Le2e is the end-to-end Euclidian distance measured • Ssetpoint the speed maintained across the network • Drawbacks: • All messages have the same speed • Does this really mean we can enforce a deadline?

31. Neighbor feedback loop • Goal: • Maintain a single hop speed above a desired Ssetpoint • Ssetpoint is a network wide parameter that tunes how harsh the realtime requirements are

32. Neighbor feedback loop

33. Back pressure rerouting • Rerouting due to pressure • The congested area is detected and the probability of sending to that node is limited • Issue: • Maybe reinforcement should refer to a geographic area rather than a node!

34. Void avoidance • Voids occur if the density is not high enough • Deals with voids similarly to hotspots by applying backbone pressure • Several packets may be dropped when trying to avoid a void

35. Last mile processing • Processing close to the destination area • Area anycast • Area multicast

36. E2E Miss Ratio • Ssetpoint = 1km/s • e2e deadline = 200 ms

37. Protocol Evaluation

38. Improving Speed

39. Possible Improvements • Allow the application to specify different speeds • Combine speed and rap • Change the MAC layer to support priority sending messages with different priorities • What scheduling policy to use? • Why are messages dropped?

40. Questions?