Скачать презентацию MMSPEED Multipath Multi-SPEED Protocol for Qo S Guarantee Скачать презентацию MMSPEED Multipath Multi-SPEED Protocol for Qo S Guarantee

9f8bb4f140ac253f343e266cb614e2d8.ppt

  • Количество слайдов: 70

MMSPEED “Multipath Multi-SPEED Protocol for Qo. S Guarantee of Reliability and Timeliness in Wireless MMSPEED “Multipath Multi-SPEED Protocol for Qo. S 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 1

1 – Introduction • Wireless sensor networks can be used for many mission-critical applications 1 – 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 2

1 – Introduction • Existing Qo. S path discovery / recovery techniques too costly 1 – Introduction • Existing Qo. S 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 Qo. S guarantees for timeliness AND reliability Differentiates Qo. S priorities based on urgency/value of data. Localized decision-making. No need for end-to-end path discovery. 3

Order of Presentation Coverage ü Introduction 2) Related Protocols / Services 3) MMSPEED Network Order of Presentation Coverage ü Introduction 2) Related Protocols / Services 3) MMSPEED Network Layer Details 4) MMSPEED MAC Layer Details 5) Framework for Optimal Protocol Configuration 6) Experimental Results / Power Consumption 7) Wrap-Up, Q & A 4

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

2 – Related Work RAP • Speed prioritization • No end-to-end deadline guarantee Mobicast 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 6

2 – Related Work No existing protocol can achieve ALL of the following… • 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 !! 7

Order of Presentation Coverage ü ü Introduction Related Protocols / Services 3) MMSPEED Network Order of Presentation Coverage ü ü Introduction Related Protocols / Services 3) MMSPEED Network Layer Details 4) MMSPEED MAC Layer Details 5) Framework for Optimal Protocol Configuration 6) Experimental Results / Power Consumption 7) Wrap-Up, Q & A 8

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

Goal #1: localized packet routing w/o knowledge of global network topology or pre-arranged path 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). 10

Goal #1: localized packet routing w/o knowledge of global network topology or pre-arranged path 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 11

But what if there’s a lake (or some other void) in the middle of 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… 12

MMSPEED Network Layer Details Two main goals of the protocol: ü Localized packet routingor MMSPEED Network Layer Details Two main goals of the protocol: ü Localized packet routingor pre-arrangedknowledge of decisions w/o global network topology path setup 2. Provide differentiated Qo. S options in terms of both… a. Timeliness NEXT (this will take longer to explain!) …and… b. Reliability 13

Goal #2 A: Provide differentiated Qo. S options in terms of timeliness. • First, Goal #2 A: Provide differentiated Qo. S options in terms of timeliness. • First, let’s discuss how we might guarantee a single level of Qo. S. • 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 “Set. Speed”. 14

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Sub-topic: How SPEED guarantees a single level of Qo. S in terms of timeliness. An example of how SPEED works… 1. Node i wants to send a packet to node k, but can’t because k is 100 meters away and outside of radio range. 2. i chooses to send to an intermediate node j, who is 20 meters closer to k. 3. 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. 15

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Sub-topic: How SPEED guarantees a single level of Qo. S 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 node. to each neighbor 16

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Sub-topic: How SPEED guarantees a single level of Qo. S in terms of timeliness. • If receive our packet. , then node j is a good candidate to • 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 Set. Speed requirement. – ie: If sending a packet to our last good neighbor puts him over the threshold of Set. Speed, then don’t send. . . just drop the packet. • Thus, a downside of SPEED: It will sacrifice reliability to uphold the timeliness requirements of Set. Speed. 17

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Sub-topic: How SPEED guarantees a single level of Qo. S 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. 18

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

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. L=2 Goal #2 A (continued): Provide differentiated Qo. S 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 Set. Speedl. 20

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. To Goal #2 A (continued): Provide differentiated Qo. S 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” 21

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Goal #2 A (continued): Provide differentiated Qo. S 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. 22

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. ü Goal #2 A (continued): Provide differentiated Qo. S 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… 23

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Goal #2 A (continued): Provide differentiated Qo. S 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. 24

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Goal #2 A (continued): Provide differentiated Qo. S 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 (Req. Speed), 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. 25

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Sub-topic: Dynamic compensation for local decisions. • Once the packet’s Req. Speed is known, the node’s urgency classifier can pick the proper speed layer (Set. Speedl) 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 Req. Speed of x. Speed layer module l can then choose a neighbor node whose progress estimation is greater than or equal to Set. Speedl 26

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Goal #2 A (continued): Provide differentiated Qo. S 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. 27

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. • Sub-topic: Dynamic compensation for local decisions. How telapsed is computed 1. When a node receives the last bit of a packet x, the MAC layer tags a tarrival field in the packet’s header. 2. MMSPEED spends some time figuring out which speed layer to use, which neighbor node to send to, etc. 3. 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 (ttrans. Delay). 4. 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 (ttrans. Delay)… 28

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. ü Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. ü Sub-topic: Dynamic compensation for local decisions. 5. The MAC layer updates telapsed in the packet’s header and makes its first attempt to send the packet on the physical layer. 6. 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. 7. 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. 8. 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 – tprop. Delay …where tprop. Delay represents the propagation delay between any two nodes (negligibly small). 29

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

Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. Differentiated Goal #2 A (continued): Provide differentiated Qo. S options in terms of timeliness. Differentiated Timeliness Qo. S 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? 31

MMSPEED Network Layer Details Two main goals of the protocol: ü Localized packet routingor MMSPEED Network Layer Details Two main goals of the protocol: ü Localized packet routingor pre-arrangedknowledge of decisions w/o global network topology path setup 2. Provide differentiated Qo. S options in terms of both… üTimeliness …and… b. Reliability NEXT 32

Goal #2 B: Provide differentiated Qo. S options in terms of reliability. Just like Goal #2 B: Provide differentiated Qo. S 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. 33

Goal #2 B (continued): Provide differentiated Qo. S options in terms of reliability. Some Goal #2 B (continued): Provide differentiated Qo. S 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. 34

Goal #2 B (continued): Provide differentiated Qo. S options in terms of reliability. • Goal #2 B (continued): Provide differentiated Qo. S 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-toend level of reliability. 35

Goal #2 B (continued): Provide differentiated Qo. S options in terms of reliability. How Goal #2 B (continued): Provide differentiated Qo. S 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). 36

Goal #2 B (continued): Provide differentiated Qo. S options in terms of reliability. Using Goal #2 B (continued): Provide differentiated Qo. S 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. 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. 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”. 37

Goal #2 B (continued): Provide differentiated Qo. S options in terms of reliability. • Goal #2 B (continued): Provide differentiated Qo. S 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. d j RP=0. 7 i Preq=0. 8 We need to add another path… 38

Goal #2 B (continued): Provide differentiated Qo. S options in terms of reliability. What Goal #2 B (continued): Provide differentiated Qo. S options in terms of reliability. 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… d j RP=0. 7 i TRPnew = 1 -(1 -0. 7)(1 -0. 6) = 0. 88 << this satisfies Preq! Formula breakdown: w RP=0. 6 Preq=0. 8 ═ 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 39

Goal #2 B (continued): Provide differentiated Qo. S options in terms of reliability. • Goal #2 B (continued): Provide differentiated Qo. S options in terms of reliability. • One additional complication… Preq needs to be modified as we proceed downstream. • Consider our little example… d j RP=0. 7 Preq=0. 8 i w RP=0. 6 • 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. 40

Goal #2 B (continued): Provide differentiated Qo. S options in terms of reliability. • Goal #2 B (continued): Provide differentiated Qo. S 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 Preq=0. 6 d j RP=0. 7 Preq=0. 8 i w RP=0. 6 Preq=0. 5 • Now, nodes j and w now have less strict reliability requirements. • In this way, MMSPEED dynamically compensates local reachability estimations based on upstream results. 41

Goal #2 B (continued): Provide differentiated Qo. S options in terms of reliability. A Goal #2 B (continued): Provide differentiated Qo. S 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. 42

Goal #2 B (continued): Provide differentiated Qo. S options in terms of reliability. Reliability Goal #2 B (continued): Provide differentiated Qo. S 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. 43

3. 3 – Discussion of Concurrent Timeliness and Reliability • End product: Timeliness & 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: 1. Classify x into speed layer l based on Req. Speed(x). 2. Speed layer module picks neighbor nodes who satisfy Set. Speedl & TRP > Preq. 3. Packet x is sent to chosen neighbors accordingly. 44

3. 3 – Discussion of Concurrent Timeliness and Reliability Some things to keep in 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… 45

3. 3 – Discussion of Concurrent Timeliness and Reliability • We can say: The 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(e 2 e. Delay(xc) ≤ deadline(x) | xc reaches the destination) ≈ 1 • Put another way… P(at least one copy reaches destination before deadline) xc xc 46

MMSPEED Network Layer Details Two main goals of the protocol: ü Localized packet routingor MMSPEED Network Layer Details Two main goals of the protocol: ü Localized packet routingor pre-arrangedknowledge of decisions w/o global network topology path setup 2. Provide differentiated Qo. S options in terms of both… üTimeliness …and… üReliability 47

Order of Presentation Coverage ü ü ü Introduction Related Protocols / Services MMSPEED Network Order of Presentation Coverage ü ü ü Introduction Related Protocols / Services MMSPEED Network Layer Details 4) MMSPEED MAC Layer Details 5) Framework for Optimal Protocol Configuration 6) Experimental Results / Power Consumption 7) Wrap-Up, Q & A 48

4 – MAC Layer Features to Support MMSPEED Routing Protocol MMSPEED requires the following 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. 49

4 – MAC Layer Features to Support MMSPEED Routing Protocol • Sub-topic: Prioritized access 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 50

4 – MAC Layer Features to Support MMSPEED Routing Protocol • Sub-topic: Support for 4 – MAC Layer Features to Support MMSPEED Routing Protocol • Sub-topic: Support for measurement of average delay at each neighbor We compute t as such: • t = t 2 – t 1 – SIFS – ACK – – • Source Node t 1 Destination Node DATA “SIFS” is a known MAC layer value ACK “ACK” is the propagation delay of the ACK message Time SIFS t 2 t captures the MAC layer’s contribution to delayi, j used by MMSPEED to compute 51

4 – MAC Layer Features to Support MMSPEED Routing Protocol • Sub-topic: Reliable multicast 4 – MAC Layer Features to Support MMSPEED Routing Protocol • Sub-topic: Reliable multicast support Some options for MAC multicast support: • Use RTS/CTS/DATA/ACK w/ all forwarding neighbors – – • Problem: serializes transmissions, imposes big delays downstream ie: hurts timeliness Ignore RTS/CTS/ACK, just send DATA to neighbors – – • Problem: probability of successful packet delivery is low ie: hurts reliability Solution: designate one “primary” neighbor for RTS/CTS/DATA/ACK handshake – – Assume other forwarding neighbors are close by They can eavesdrop transmissions to primary node Transmissions to primary node are guaranteed, and “highly likely” for nearby neighbors. 52

4 – MAC Layer Features to Support MMSPEED Routing Protocol • Sub-topic: Support for 4 – MAC Layer Features to Support MMSPEED Routing Protocol • Sub-topic: Support for loss rate measurement • Non-primary nodes will still increment incoming frame counts. • A node will report frame count to sender in ACK whenever selected as primary. • Meanwhile, sender nodes increment frames sent to each neighbor. • Thus, sender can calculate loss rate to current primary. • After calculation, both sender and primary reset frame counts to zero. • These loss rate measurements are used by MMSPEED to determine ei, j (which helps find RP) 53

Order of Presentation Coverage ü ü Introduction Related Protocols / Services MMSPEED Network Layer Order of Presentation Coverage ü ü Introduction Related Protocols / Services MMSPEED Network Layer Details MMSPEED MAC Layer Details 5) Framework for Optimal Protocol Configuration 6) Experimental Results / Power Consumption 7) Wrap-Up, Q & A 54

5 – Framework for Optimal Protocol Configuration • Remember that the number of speed 5 – Framework for Optimal Protocol Configuration • Remember that the number of speed layers (L) and the speeds of each layer (Set. Speedl) are set at design time. • Authors propose ways to figure out optimal settings for these • Regarding L: – The more speed layers, the finer service differentiation offered – However, means more protocol overhead in: • • Processing power Memory requirements – Thus, to determine L, “consider the practical limits of your hardware”. – (…is it that easy…? ) 55

5 – Framework for Optimal Protocol Configuration • Sub-topic: Determining Set. Speedl Next step: 5 – Framework for Optimal Protocol Configuration • Sub-topic: Determining Set. Speedl Next step: Determine Set. Speed for each speed layer • Not as simple • In fact, fairly complicated • First, an intuitive concept: – – – • As Set. Speed increases, packet drop probability also increases This means reliability decreases Hence: So we must be careful in choosing Set. Speedl for each layer 56

5 – Framework for Optimal Protocol Configuration • Sub-topic: Determining Set. Speedl • During 5 – Framework for Optimal Protocol Configuration • Sub-topic: Determining Set. Speedl • During design, consider event locations and workload characteristics. • For example: Wildlife tracking in a forest Intrusion detection at a border 57

5 – Framework for Optimal Protocol Configuration • Sub-topic: Determining Set. Speedl Authors propose 5 – Framework for Optimal Protocol Configuration • Sub-topic: Determining Set. Speedl Authors propose two pseudo-code functions for finding Set. Speedl: Find. Set. Speed(f) • for a given workload scale factor f, find Set. Speedl (1 ≤ l ≤ L) • Think of “workload” as processing load or “productivity” – • ie: the more the system can handle successfully, the better this function returns Set. Speedl solutions for all L speed layers Maximize. F • find the maximum f and the corresponding Set. Speedl values for all L speed layers 1. 2. 3. In a loop, do: increase f, then call Find. Set. Speed(f). When Find. Set. Speed(f) fails, reduce f by one increment The next call to Find. Set. Speed(f) will be the answer 58

Order of Presentation Coverage ü ü ü Introduction Related Protocols / Services MMSPEED Network Order of Presentation Coverage ü ü ü Introduction Related Protocols / Services MMSPEED Network Layer Details MMSPEED MAC Layer Details Framework for Optimal Protocol Configuration 6) Experimental Results / Power Consumption 7) Wrap-Up, Q & A 59

5 – Experimental Results / Power Consumption Experimental Results • Performed network simulations using 5 – Experimental Results / Power Consumption Experimental Results • Performed network simulations using “J-SIM” software • MMSPEED compared only vs. SPEED – SPEED is the only other available WSN protocol providing real-time Qo. S in a localized manner EDCF MAC Parameters Simulation Environment Settings 60

Experiment #1 Reachability = constant 0. 5 Delay = 0. 3 & 1. 0 Experiment #1 Reachability = constant 0. 5 Delay = 0. 3 & 1. 0 Avg. Delay vs. # Flows • MMSPEED provides adequate timeliness Qo. S differentiation for even 20 flows & little delay • SPEED has only 1 level of service and can only accommodate 14 flows max Reachability vs. # Flows • No significant difference between the two • Mainly because reliability requirement is constant for all 61

Experiment #2 Reachability = 0. 7 & 0. 2 Delay = constant 1. 0 Experiment #2 Reachability = 0. 7 & 0. 2 Delay = constant 1. 0 Avg. Delay vs. # Flows • No significant difference between the two • Mainly because deadline requirement is constant for all Reachability vs. # Flows • MMSPEED provides adequate reachability Qo. S differentiation for even 20 flows and 70% RP • SPEED cannot differentiate service and misses requirement for 18+ flows 62

Experiment #3 Reachability = 0. 7 & 0. 2 Delay = 0. 3 & Experiment #3 Reachability = 0. 7 & 0. 2 Delay = 0. 3 & 1. 0 MMSPEED’s On-Time Reachability • Accommodates as many as 18 flows across all 4 flow groups • Can accommodate all 20 flows for some groups SPEED’s On-Time Reachability • Accommodates only 12 flows across the 4 flow groups • Due to mixing up all flow groups without any differentiation 63

Experiment #4 Reachability = 0. 7 & 0. 2 Delay = 0. 3 & Experiment #4 Reachability = 0. 7 & 0. 2 Delay = 0. 3 & 1. 0 Control Packet Overhead • • MMSPEED surprisingly has less Likely due to: – – – # loc. update pkts. same for both # timeliness back-pressure pkts. higher in SPEED since all pkt. classes mixed together MMSPEED has higher # back-pressure pkts, but this number is still low vs. timeliness back-pressure pkts. Data Packet Overhead • • MMSPEED close to SPEED Likely due to: – – MMSPEED typically duplicates just enough pkts. early on upstream (not exponential growth) Many pkts. dropped early on in MMSPEED due to lower reliability reqs. vs. original Preq 64

Experiment #5 Reachability = 0. 7 & 0. 2 Delay = 0. 3 & Experiment #5 Reachability = 0. 7 & 0. 2 Delay = 0. 3 & 1. 0 # Control Packets vs. # Nodes • • • Slight linear slope for both MMSPEED & SPEED Each new node adds a little overhead due to added location update packets However, this is great vs. the exponential scaling behavior seen in pro/re –active routing protocols # Data Packets vs. # Nodes • • Constant throughout for both protocols Location-based forwarding node selection (in both) scales well. 65

Experiment #6 Nodes In Motion • • • 150 nodes Randomly placed 4 flow Experiment #6 Nodes In Motion • • • 150 nodes Randomly placed 4 flow groups, 3 flows per group First 200 s: All nodes static 400 s – 600 s: 20% nodes moving 600 s+: All nodes static • Very slight decrease in performance due to nodes moving out of radio range of one another • Nevertheless, on-time reachability requirement met successfully throughout the experiment 66

6. 4 – Discussions on Power Overhead Two main sources of power consumption in 6. 4 – Discussions on Power Overhead Two main sources of power consumption in WSNs: • Node processor – – • MMSPEED requires more use of the CPU than other protocols. However, CPU power consumption still relatively low vs. radio Node radio module – – Much bigger source of power consumption MMSPEED has a slightly higher transmission rate than SPEED • Generally, a little more power consumption is a “small price to pay” for the timeliness & reliability Qo. S gains offered by MMSPEED • However, the authors DO mention a desire to revise MMSPEED for power-constrained applications. 67

Order of Presentation Coverage ü ü ü 7) Introduction Related Protocols / Services MMSPEED Order of Presentation Coverage ü ü ü 7) 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 68

Comments Areas for Improvement • Number of speed layers (L) and the speeds for Comments Areas for Improvement • Number of speed layers (L) and the speeds for each layer (Set. Speedl) must be determined and set before deployment. – – – • For this to be effective, it means the person / SW doing this “setting” must also have some knowledge of the system domain. Could this be determined after deployment? Maybe even create some automated way of resetting speeds and number of layers during runtime? (perhaps a periodic optional “reset” session across the network? ) Each node must have an idea of its physical location (via GPS or some other means) – Is this costly in terms of performance, money, energy consumed, etc? • Little discussion for how L is determined. Only says that you need to consider “the practical limits of processing power and memory size of sensor nodes” • Otherwise, MMSPEED sounds like a good idea! 69

Thanks! Any questions? 70 Thanks! Any questions? 70