MMSPEED

1. MMSPEED • “Multipath Multi-SPEED Protocol for QoS Guarantee of Reliability and Timeliness in Wireless Sensor Networks” • A paper by • Felemban, Lee, and Ekici • IEEE Transactions on Mobile Computing • Vol. 5, No. 6, June ’06 • Presented by Derek Pennington

2. 1 – Introduction Introduction • Wireless sensor networks can be used for many mission-critical applications • Military, emergency response, etc. • Can have diverse real-time requirements • eg: different notification deadlines when tracking slow targets vs. fast targets • Can have diverse reliability requirements • eg: forest fire notification delivery must be guaranteed, whereas normal, safe temps not as crucial • Mix of periodic & aperiodic data • Event-driven response vs. proactive environment polling

3. 1 – Introduction • Existing QoS path discovery / recovery techniques too costly for mission-critical apps • Protocols offer only partial solutions: • Timeliness, but not reliability • Reliability, but not timeliness • Handle periodic, but not aperiodic data • Solution: Authors propose MMSPEED routing protocol • Spans both network & MAC layers • Provides QoS guarantees for timeliness AND reliability • Differentiates QoS priorities based on urgency/value of data. • Localized decision-making. No need for end-to-end path discovery.

4. Order of Presentation Coverage • Introduction • Related Protocols / Services • MMSPEED Network Layer Details • MMSPEED MAC Layer Details • Framework for Optimal Protocol Configuration • Experimental Results / Power Consumption • Wrap-Up, Q & A

5. 2 – Related Work Related Protocols / Services AFS & ReInforM • Provide reliability guarantees via path redundancy • Require knowledge of the network topology • Limited speed prioritization capability • ReInforM is also discussed in P10’s “Introduction” section Implicit EDF (Earliest Deadline First) • End-to-end deadline guarantee, but only for periodic data • Periods must be known in advance

6. 2 – Related Work RAP • Speed prioritization • No end-to-end deadline guarantee Mobicast • Wakes-up “sleeping” sensors in time for data delivery • Assumes reliable & time-bounded transmissions between every sensor pair • Uses all nodes in large forwarding zones for packet forwarding SPEED • Localized geographic forwarding (w/o knowledge of network topology) • End-to-end deadline guarantee (one speed only) • No reliability guarantee

7. 2 – Related Work No existing protocol can achieve ALL of the following… • Service differentiation & guarantee for both timeliness & reliability • Localized packet delivery w/o knowledge of network topology • Overcoming less-reliable and unbounded transmissions over wireless links …except for MMSPEED !!

8. Order of Presentation Coverage • Introduction • Related Protocols / Services • MMSPEED Network Layer Details • MMSPEED MAC Layer Details • Framework for Optimal Protocol Configuration • Experimental Results / Power Consumption • Wrap-Up, Q & A

9. MMSPEED Network Layer Details Two main goals of the protocol: • Localized packet routing decisions w/o knowledge of global network topology or pre-arranged path setup • Provide differentiated QoS options in terms of both… • Timeliness …and… • Reliability

10. Goal #1: localized packet routing w/o knowledge of global network topology or pre-arranged path setup • Each node knows its physical, geographic location • Absolute via GPS or relative to other nodes via “distributed location services” • Packet destinations are specified by these physical locations rather than node IDs • Node location information exchanged via periodic location update packets Therefore, each node knows where it is and where its neighbors are (within radio range).

11. Goal #1: localized packet routing w/o knowledge of global network topology or pre-arranged path setup • Knowing the final geographic destination of a packet, a node can determine the best neighbor node to send to • Not taking into account congestion characteristics, etc, this would normally be the neighbor closest to the final node • In this manner, a packet will eventually reach its final destination

12. But what if there’s a lake (or some other void) in the middle of the network? • The authors propose “back-pressure packets” as a means of addressing this. • Will be explained in a few slides…

13. MMSPEED Network Layer Details Two main goals of the protocol: • Localized packet routing decisions w/o knowledge of global network topology or pre-arranged path setup • Provide differentiated QoS options in terms of both… • Timeliness …and… • Reliability NEXT (this will take longer to explain!)

14. Goal #2A: Provide differentiated QoS options in terms of timeliness. • First, let’s discuss how we might guarantee a single level of QoS. • This is what the SPEED protocol does. • SPEED can “guarantee” a minimum network-wide packet speed… from any source to any sink. • The paper’s authors refer to this guaranteed speed as “SetSpeed”.

15. Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. • Sub-topic: How SPEED guarantees a single level of QoS in terms of timeliness. An example of how SPEED works… • Node iwants to send a packet to node k, but can’t because k is 100 meters away and outside of radio range. • i chooses to send to an intermediate node j, who is 20 meters closer to k. • By the time the packet from i reaches j, 0.1 seconds have elapsed. • due to time spent queuing, processing, and resolving MAC collisions Notice that the packet’s distance to final destination (node “k”) shrank by 20 meters in 0.1 seconds.

16. Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. • Sub-topic: How SPEED guarantees a single level of QoS in terms of timeliness. Therefore, the packet’s speed from i to k (by way of j) is 200 meters per second: • Remember: each node can calculate distances to neighbors thanks to location update packets. • The SPEED protocol also calls for each node to maintain estimates of delayi,j values to each neighbor. • Thus, each node has the capability to estimate to each neighbor node.

17. If , then node j is a good candidate to receive our packet. • In cases of congestion, delay estimates will increase and a node may find that it has fewer neighbors to whom it can send packets on schedule. • In extreme cases, a node will simply drop packets so that it can keep at least one neighbor within a delay estimate which satisfies the SetSpeed requirement. • ie: If sending a packet to our last good neighbor puts him over the threshold of SetSpeed, then don’t send... just drop the packet. • Thus, a downside of SPEED: It will sacrifice reliability to uphold the timeliness requirements of SetSpeed. • Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. • Sub-topic: How SPEED guarantees a single level of QoS in terms of timeliness.

18. Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. • Sub-topic: How SPEED guarantees a single level of QoS in terms of timeliness. Back-Pressure Packets • In addition, in these cases of congestion, nodes may issue “back-pressure packets” to neighbors to reduce incoming traffic. • This back-pressure mechanism also happens to solve the “network void” problem mentioned earlier. • By alerting other nodes to divert traffic, alternate routes around holes will eventually be discovered.

19. MMSPEED • SPEED_1 • SPEED_2 • SPEED_3 • Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. • Sub-topic: How SPEED guarantees a single level of QoS in terms of timeliness. • Thus, we’ve discussed how the SPEED protocol can guarantee a single level of QoS in terms of timeliness. • Using that knowledge, we’ll now learn how MMSPEED builds upon SPEED to offer multiple QoS timeliness guarantees.

20. Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. L = 2 (in this case) Conceptually, you could think of MMSPEED as being L number of SPEED layers over top of one physical network. Each individual speed layer l (lowercase “L”) guarantees a corresponding SetSpeedl.

21. Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. To accomplish this “virtual layering”, MMSPEED employs two notions: • Virtual “isolation” among the layers • Dynamic compensation of local decisions • Another way to put it: “downstream compensation for decisions made upstream”

22. Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. • Sub-topic: Virtual isolation among the speed layers. The goal of “virtual isolation” is to minimize the impact that one layer has on another. • When a packet arrives at a node, the node must first classify the message based on the urgency of its contents • Did this packet’s source node sense a forest fire, or just same typical data? • The packet is placed into one of L priority queues based on urgency. • More on urgency in a moment… • Packets in higher layers cannot be delayed by packets in lower layers.

23. Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. • Sub-topic: Virtual isolation among the speed layers. • However, the randomness of the MAC layer’s CSMA/CA behavior can disturb the transmission order originally determined by the priority queues. • CSMA/CA = Carrier Sense, Multiple Access with Collision Avoidance • Thus, MMSPEED’s authors also propose changes to the MAC protocol. • Will be discussed later in the slideshow…

24. Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. • Sub-topic: Dynamic compensation for local decisions. About “urgency classification”… • We can imagine that the system designers / customers will come to an agreement on the speeds at which certain kinds of events will need to be reported. • For example, a requirements agreement might say… • Report a forest fire within 10 seconds of detection. • Report a frost warning within 30 seconds of detection. • Report a change of + or – 5 degrees within 45 seconds of detection. • Thus, we have a notion of “deadlines” for certain kinds of sensed events.

25. Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. • Sub-topic: Dynamic compensation for local decisions. • MMSPEED ensures that these deadlines are met by recomputing the “remaining time to deadline” at each hop. • The required speed of a packet (ReqSpeed), then, can be computed as follows… Distance packet x is from final destination node d. Minimum speed packet x must travel toward final destination node d. Maximum time packet x is allowed to take to reach final destination node d.

26. Speed layer module l can then choose a neighbor node whose progress estimation is greater than or equal to SetSpeedl • Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. • Sub-topic: Dynamic compensation for local decisions. • Once the packet’s ReqSpeed is known, the node’s urgency classifier can pick the proper speed layer (SetSpeedl) for the packet The speed layer chosen by the node’s urgency classifier From speed layer 1 to L, find the slowest speed layer j such that… …speed layer j can guarantee that packet x will travel toward its final destination node at a speed greater than or equal to the ReqSpeed of x.

27. Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. • Sub-topic: Dynamic compensation for local decisions. • Computing a packet’s “remaining time to deadline” (ie: deadline(x)) is not as easy as one might think, primarily because MMSPEED assumes that all nodes in the network have accurate, but not globally synchronized clocks. • Therefore, MMSPEED has each node keep track of it’s contribution to the packet’s overall delay as it progresses toward the final destination node. • This is accomplished by storing a telapsed field in the packet’s header, which is the running total of the combined delay from upstream nodes.

28. Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. • Sub-topic: Dynamic compensation for local decisions. How telapsed is computed • When a node receives the last bit of a packet x, the MAC layer tags a tarrival field in the packet’s header. • MMSPEED spends some time figuring out which speed layer to use, which neighbor node to send to, etc. • Once processing is done and the packet is ready to be sent, the MAC layer notes the current clock time (tdeparture), as well as the packet’s length and the transmission output rate of the node (ttransDelay). • So our new telapsed time, then, is the original value for telapsed plus the departure time (tdeparture) minus the arrival time (tarrival) plus the little bit of extra time it takes to get the full packet out the door (ttransDelay)…

29. Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. • Sub-topic: Dynamic compensation for local decisions. • The MAC layer updates telapsed in the packet’s header and makes its first attempt to send the packet on the physical layer. • However, the first attempt is not always successful, and the MAC layer may need to resend multiple times before receiving an ACK from the neighbor node. • Each successive resend attempt delays the packet a little bit more, so the MAC layer will update telapsed each time to ensure an accurate value. • When the neighbor node finally receives this packet x, he is able to compute remaining time to deadline (deadline(x)) as follows… deadline(x) = deadline(x) – telapsed – tpropDelay …where tpropDelay represents the propagation delay between any two nodes (negligibly small).

30. Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. Recap: How MMSPEED processes packet x at a given node... • MAC layer tags tarrival to incoming packet x. • MMSPEED computes packet x’s remaining time to deadline: deadline(x) = deadline(x) – telapsed – tpropDelay • MMSPEED computes required send speed for packet x: • MMSPEED puts packet x into appropriate speed layer priority queue as follows… • Speed layer module uses SPEED logic to select best candidate node j as the send target for packet x. • When it’s time to send packet x, MAC layer updates telapsed with each send attempt…

31. Goal #2A (continued): Provide differentiated QoS options in terms of timeliness. Differentiated Timeliness QoS Summary Discussion • Because we’re recomputing remaining time to deadline and required speed at each hop, a particular packet will naturally be bumped up or down in priority as it gets ahead of or behind schedule on its way to the final destination node. • Via these means, we have some level of assurance that if a packet reaches its final destination node, it satisfies the end-to-end deadline requirement for the sensed event. • However, in a congested system, nodes may just drop packets. How do we ensure that our packet won’t be dropped by the system?

32. MMSPEED Network Layer Details Two main goals of the protocol: • Localized packet routing decisions w/o knowledge of global network topology or pre-arranged path setup • Provide differentiated QoS options in terms of both… • Timeliness …and… • Reliability NEXT

33. Goal #2B: Provide differentiated QoS options in terms of reliability. Just like the timeliness requirements agreement, we can imagine a system designer and customer negotiating reliability requirements for certain events. For example… • A forest fire notification must be reported to the main station with 95% reliability. • A frost warning must be reported to the main station with 85% reliability. • A change in temperature of + or – 5 degrees must be reported with 75% reliability. The specific system parameter for each of these end-to-end reliability requirements is denoted as Preq. For example, in the “forest fire” bullet, Preq = 0.95.

34. Goal #2B (continued): Provide differentiated QoS options in terms of reliability. Some things to consider… • In dense sensor networks, there are likely MANY potential paths from a source node to a sink node. • As long as timeliness requirements are met, we don’t necessarily need to take the shortest route. • Sometimes, it’s better to take a slightly longer route, because the shortest routes may be heavily congested. • A means of load-balancing the network. MMSPEED keeps all of these points in mind when addressing reliability requirements.

35. Goal #2B (continued): Provide differentiated QoS options in terms of reliability. • Knowing that packets can be dropped due to congestion, node failure, or path failure (excessive noise, etc), MMSPEED adds redundant paths as necessary to ensure that reliability requirements are met for each sensed event. • With each successive node hop, MMSPEED reconsiders how many neighbor nodes (ie: redundant output paths) to send to. • These locally-made path adjustments effectively maintain an end-to-end level of reliability.

36. Goal #2B (continued): Provide differentiated QoS options in terms of reliability. How are these local forwarding path decisions made? Each node calculates “reaching probability” based on two factors: • Average transmission error (packet loss) percentage ei,j This includes: • intentional packet drops due to congestion • packets lost due to errors (noise, etc) on the wireless channel • MAC layer loss estimation (will be described later) • Geographic hop distances to each neighbor node (as already discussed).

37. Goal #2B (continued): Provide differentiated QoS options in terms of reliability. Using those two factors a node i can estimate reachability of a packet from node i to sink node d via a neighbor node j as follows: “Reaching Probability” from node i to node d via node j The probability that a packet sent from node i will reach node j successfully. The estimated hop-count from intermediate node j to sink node d. This assumes that, for each hop from j toward d, the per-hop progress toward d will average-out to be roughly equal to our progress toward d when we hopped from source node i to j. Without knowledge of the global topology, it’s essentially a “best guess”. We assume, for the moment, that each hop from j toward d will have the same probability of success as that of our hop from source node i to j.

38. Preq=0.8 j RP=0.7 i d We need to add another path… Goal #2B (continued): Provide differentiated QoS options in terms of reliability. • So the previous equation allows us to compute reaching probability (RP) from our current node to the sink node via one path only. • But what if the RP value we get does not satisfy Preq? We’ll have to add another path and see what our total reaching probability (TRP) becomes.

39. Goal #2B (continued): Provide differentiated QoS options in terms of reliability. RP=0.7 RP=0.6 Preq=0.8 j w i d What happens is that, as we add each new path, we multiply the new path’s reaching probability (RP) by the already-computed product of the reaching probabilities of the other paths (what I’m calling TRPold). The formula is as follows… • TRPnew = 1-(1-0.7)(1-0.6) • = 0.88<< this satisfiesPreq! Formula breakdown: • the probability that none of the already-computed paths will successfully deliver the packet to sink node d. • the probability that this new path from i to d via j will fail to deliver the packet successfully • the probability that ALL of the paths, old and new combined will fail to deliver the packet to sink node d • the probability that at least one path will successfully deliver the packet to sink node d

40. Preq=0.8 j w i d Goal #2B (continued): Provide differentiated QoS options in terms of reliability. • One additional complication… Preq needs to be modified as we proceed downstream. • Consider our little example… • When we were at node i, Preq was 80%. However, by transmitting to both nodes j and w, we calculated a TRP of 88%. We essentially have an 8% surplus. Looks like we’re too reliable  • Since we’re ahead of the game, we can afford to back-off slightly, so that our reachability will aim for 80% again, rather than 88%. • We do this by changing Preq at nodes j and w. RP=0.7 RP=0.6

41. Preq=0.8 Preq=0.6 Preq=0.5 j w i d Goal #2B (continued): Provide differentiated QoS options in terms of reliability. • In this case, we find that we can achieve a TRP of 80% again if we set Preq at node j to 60% and Preq at node w to 50%... TRP = 1 - (1-0.6)(1-0.5) = 0.8 • Now, nodes j and w now have less strict reliability requirements. • In this way, MMSPEED dynamically compensates local reachability estimations based on upstream results. RP=0.7 RP=0.6

42. Goal #2B (continued): Provide differentiated QoS options in terms of reliability. A very thorough example from the paper… Notice that as we proceed downstream from source node s, Preq changes for the subsequent nodes in an attempt to maintain a somewhat constant level of reliability from end-to-end.

43. Goal #2B (continued): Provide differentiated QoS options in terms of reliability. Reliability Back-Pressure Packets • If a node j cannot satisfy Preq even using all possible forwarding nodes, it issues a reliability back-pressure packet. • The packet contains the best possible TRP that node j can expect. • Upstream nodes will then reduce their reliability expectations of node j. • In future packets, these upstream nodes will limit Preq for node j to, at most, the TRP value they got in node j’s back-pressure packet. • In some situations, back-pressure messaging may cascade multiple hops upstream. • In the extreme case, this back-pressure cascade can propagate all the way to the source node. • In that situation, Preq values will be reassigned to the source node’s immediate neighbors, and they’ll attempt messaging again.

44. 3.3 – Discussion of Concurrent Timeliness and Reliability • End product: Timeliness & Reliability components work together • deadline(x) & Preq(x) represent a packet’s end-to-end requirements • Processing of packet x at node i: • Classify x into speed layer l based on ReqSpeed(x). • Speed layer module picks neighbor nodes who satisfy SetSpeedl & TRP > Preq. • Packet x is sent to chosen neighbors accordingly.

45. 3.3 – Discussion of Concurrent Timeliness and Reliability Some things to keep in mind… • We need to ensure “parallel progress” of packets. • Sending one-at-a-time throws off timeline accuracy • Thus, MAC layer multicast capability needed • Will be discussed shortly…

46. xc xc 3.3 – Discussion of Concurrent Timeliness and Reliability • We can say: The probability that a copy xc reaches the sink by deadline(x) time is approximately 1.0. In other words… P(e2eDelay(xc) ≤ deadline(x) | xc reaches the destination) ≈ 1 • Put another way… P(at least one copy reaches destination before deadline)

47. MMSPEED Network Layer Details Two main goals of the protocol: • Localized packet routing decisions w/o knowledge of global network topology or pre-arranged path setup • Provide differentiated QoS options in terms of both… • Timeliness …and… • Reliability

48. Order of Presentation Coverage • Introduction • Related Protocols / Services • MMSPEED Network Layer Details • MMSPEED MAC Layer Details • Framework for Optimal Protocol Configuration • Experimental Results / Power Consumption • Wrap-Up, Q & A

49. 4 – MAC Layer Features to Support MMSPEED Routing Protocol MMSPEED requires the following MAC layer enhancements: • Prioritized access to shared medium depending on the speed layer • Support of individual neighbor average delay measurement capability. • “Partially” reliable multicast delivery of packets to multiple neighbor nodes • Support of individual neighbor loss rate measurement capability.

50. 4 – MAC Layer Features to Support MMSPEED Routing Protocol • Sub-topic: Prioritized access to the shared medium • Set interframe spacing and backoff intervals based on speed layer priority • High priority layer gets shortest IFS & backoff interval • Low priority layer gets longest IFS & backoff interval • etc • Map each speed layer to a “MAC priority class” • Higher layers/classes cannot be interrupted by lower layers/classes