MMSPEED

1

“Multipath Multi-SPEED Protocol for QoS Guarantee of Reliability and Timeliness in Wireless Sensor Networks”

A paper byFelemban, Lee, and Ekici

IEEE Transactions on Mobile ComputingVol. 5, No. 6, June ’06

Presented by Derek Pennington

MMSPEED

2

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

Introduction

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

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

Order of Presentation Coverage

5

2 – Related Work

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

Related Protocols / Services

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

Introduction


3) MMSPEED Network Layer Details




7) Wrap-Up, Q & A


9

MMSPEEDNetwork 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 QoS options in terms of both…

a. Timeliness

…and…

b. Reliability

10

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

Goal #1: localized packet routing w/o knowledge of global network topology orpre-arranged path setup

11

• 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

Goal #1: localized packet routing w/o knowledge of global network topology orpre-arranged path setup

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


Localized packet routing decisions w/o knowledge of global network topology or pre-arranged path setup


a. Timeliness

…and…

b. Reliability

NEXT (this will take longer to explain!)

14

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

Goal #2A: Provide differentiated QoS options in terms of timeliness.

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…

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.

16

sec/200sec1.0/20/)( ,,,, mmdelaydistdistSpeed jikjkik

ji

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.

kjiSpeed ,

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.

SetSpeedSpeed kji ,

18


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

Back-Pressure Packets

19

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.

MMSPEED

SPEED_1SPEED_2SPEED_3

20

Goal #2A (continued): Provide differentiated QoS options in terms of timeliness.

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.

L = 2(in this case)

21


To accomplish this “virtual layering”, MMSPEEDemploys 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 onelayer 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…

http://en.wikipedia.org/wiki/CSMA/CA

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


• 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…

)(

)()( ,

xdeadline

xdistxReqSpeed ds

Minimum speed packet x must travel toward final destination node d.

Distance packet x is from final destination node d.

Maximum time packet x is allowed to take to reach final destination node d.

26


• Once the packet’s ReqSpeed is known, the node’s urgency classifier can pick the proper speed layer (SetSpeedl) for the packet

)}(|{min 1 xReqSpeedSetSpeedSetSpeedSetSpeed jjLjl

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.

• Speed layer module l can then choose a neighbor node whose progress estimation is greater than or equal to SetSpeedl

jikjkik

ji delaydistdistSpeed ,,,, /)(

27


• 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


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 (ttransDelay).

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 (ttransDelay)…

transDelayarrivaldepartureelapsedOldelapsedNew ttttt )(

29

Goal #2A (continued): Provide differentiated QoS 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 – tpropDelay

…where tpropDelay represents the propagation delay between anytwo nodes (negligibly small).

30


Recap: How MMSPEED processes packet x at a given node...

1. MAC layer tags tarrival to incoming packet x.2. MMSPEED computes packet x’s remaining time to deadline:

deadline(x) = deadline(x) – telapsed – tpropDelay

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…

)(

)()( ,

xdeadline

xdistxReqSpeed ds

)}(|{min 1 xReqSpeedSetSpeedSetSpeedSetSpeed jjLjl

transDelayarrivaldepartureelapsedOldelapsedNew ttttt )(

31


• 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?

Differentiated Timeliness QoS Summary Discussion

32





Timeliness

…and…

b. Reliability

NEXT

33

Goal #2B: Provide differentiated QoS options in terms of reliability.

Just like the timeliness requirements agreement, we can imagine asystem designer and customer negotiating reliability requirements forcertain 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 reliabilityrequirements 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 whenaddressing reliability requirements.

35


• 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


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


Using those two factors a node i can estimate reachability of apacket from node i to sink node d via a neighbor node j as follows:

),(/),(,,, )1)(1( jidistdjdistjiji

dji eeRP

“Reaching Probability” from node i to node d via node 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”.

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.

38


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

i

jd

RP=0.7Preq=0.8

We need to add another path…

reqdji PRP ,

39


What happens is that, as we add each new path, we multiply the new path’sreaching probability (RP) by the already-computed product of the reachingprobabilities of the other paths (what I’m calling TRPold).The formula is as follows…

)1)(1(1 ,djioldnew RPTRPTRP

Preq=0.8i

jd

RP=0.7

wRP=0.6TRPnew = 1-(1-0.7)(1-0.6)

= 0.88 << this satisfies Preq!

)1( oldTRP

)1( ,djiRP

)1)(1( ,djiold RPTRP

)1)(1(1 ,djiold RPTRP

═ 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

Formulabreakdown:

40


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

Preq=0.8i

jd

RP=0.7

wRP=0.6

41


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

Preq=0.8i

jd

RP=0.7

wRP=0.6

Preq=0.6

Preq=0.5

42


A very thorough example from the paper…

Notice that as we proceed downstream from source node s, Preq changesfor the subsequent nodes in an attempt to maintain a somewhatconstant level of reliability from end-to-end.

43


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:

1. Classify x into speed layer l based on ReqSpeed(x).

2. Speed layer module picks neighbor nodes who satisfy SetSpeedl & TRP > Preq.

3. Packet x is sent to chosen neighbors accordingly.

45


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


• 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)

)) AND(1(1 reachc

deadlinec xxP

xc

))(1(1 reachcxP

xc

47





Timeliness

…and…

Reliability

48

Introduction






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

51

t captures the MAC layer’s contribution to delayi,j used by MMSPEED to compute

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 = t2 – t1 – SIFS – ACK

– “SIFS” is a known MAC layer value

– “ACK” is the propagation delay of the ACK message

SIFSACK

DATA

Source Node

Destination Node

t1

t2

Time

kjiSpeed ,

52

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” fornearby neighbors.

53

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)

54

Introduction



MMSPEED MAC Layer Details



7) Wrap-Up, Q & A


55

5 – Framework for Optimal Protocol Configuration

• Remember that the number of speed layers (L) and the speeds of each layer (SetSpeedl) 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…?)

Framework for Optimal Protocol Configuration

56

5 – Framework for Optimal Protocol Configuration• Sub-topic: Determining SetSpeedl

Next step: Determine SetSpeed for each speed layer

• Not as simple

• In fact, fairly complicated

• First, an intuitive concept:

– As SetSpeed increases, packet drop probability also increases– This means reliability decreases– Hence:

• So we must be careful in choosing SetSpeedl for each layer

lll yreliabilit

1ProbPacketDropSetSpeed

57


• During design, consider event locations and workload characteristics.

• For example:

Wildlife tracking in a forest Intrusion detection at a border

58


Authors propose two pseudo-code functions for finding SetSpeedl:

FindSetSpeed(f)

• for a given workload scale factor f, find SetSpeedl (1 ≤ l ≤ L)

• Think of “workload” as processing load or “productivity”– ie: the more the system can handle successfully, the better

• this function returns SetSpeedl solutions for all L speed layers

MaximizeF

• find the maximum f and the corresponding SetSpeedl values for all L speed layers

1. In a loop, do: increase f, then call FindSetSpeed(f).2. When FindSetSpeed(f) fails, reduce f by one increment3. The next call to FindSetSpeed(f) will be the answer

59

Introduction






7) Wrap-Up, Q & A


60

5 – Experimental Results / Power Consumption

• Performed network simulations using “J-SIM” software

• MMSPEED compared only vs. SPEED

– SPEED is the only other available WSN protocol providing real-time QoS in a localized manner

Experimental Results

Simulation Environment SettingsEDCF MAC Parameters

61

Avg. Delay vs. # Flows• MMSPEED provides adequate

timeliness QoS 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

Experiment #1 Reachability = constant 0.5Delay = 0.3 & 1.0

62

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 QoS differentiation for even 20 flows and 70% RP

• SPEED cannot differentiate service and misses requirement for 18+ flows

Experiment #2 Reachability = 0.7 & 0.2Delay = constant 1.0

63

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

Experiment #3 Reachability = 0.7 & 0.2Delay = 0.3 & 1.0

64

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


65

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


66

• 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

Experiment #6

Nodes In Motion

• 150 nodes• Randomly placed• 4 flow groups, 3 flows per

group

First 200s: All nodes static400s – 600s: 20% nodes moving600s+: All nodes static

67

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 QoS gains offered by MMSPEED

• However, the authors DO mention a desire to revise MMSPEED for power-constrained applications.

68

Introduction





Experimental Results / Power Consumption

7) Wrap-Up, Q & A


69

Comments

Areas for Improvement

• Number of speed layers (L) and the speeds for each layer (SetSpeedl) 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!

70

Thanks!

Any questions?

MMSPEED

Documents

Transcript of MMSPEED