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 P10s
  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 theres 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, lets 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 papers 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 i wants to send a packet to node k, but
  cant 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 packets 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 packets 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

• 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

• 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, weve discussed how the SPEED protocol can
  guarantee a single level of QoS in terms of
  timeliness.
• Using that knowledge, well 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 packets 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 layers
  CSMA/CA behavior can disturb the transmission
  order originally determined by the priority
  queues.
• CSMA/CA Carrier Sense, Multiple Access with
  Collision Avoidance
• Thus, MMSPEEDs 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

• Goal 2A (continued) Provide differentiated QoS
  options in terms of timeliness.
• Sub-topic Dynamic compensation for local
  decisions.

• Once the packets ReqSpeed is known, the nodes
  urgency classifier can pick the proper speed
  layer (SetSpeedl) for the packet

The speed layer chosen by the nodes 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 packets 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
  its contribution to the packets overall delay
  as it progresses toward the final destination
  node.
• This is accomplished by storing a telapsed field
  in the packets 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
  packets 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 packets 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 packets
  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 xs 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 its 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 were 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
  wont 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
  dont necessarily need to take the shortest
  route.
• Sometimes, its 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,
its 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
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? Well 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.
What happens is that, as we add each new path, we
multiply the new paths reaching probability (RP)
by the already-computed product of the
reaching probabilities of the other paths (what
Im calling TRPold). The formula is as follows
TRPnew 1-(1-0.7)(1-0.6) 0.88 ltlt this
satisfies Preq!
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
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 were too reliable ?
• Since were 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.

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

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

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 js 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 nodes immediate neighbors, and
  theyll 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 packets
  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 gt 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
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

51

• 4 MAC Layer Features to Support MMSPEED Routing
  Protocol
• Sub-topic Support for measurement of average
  delay at each neighbor

Source Node
Destination Node

• 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

Time
t1
DATA
SIFS
ACK
t2

• ?t captures the MAC layers contribution to
  delayi,j used by MMSPEED to compute

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 for
• nearby 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
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

55
5 Framework for Optimal Protocol Configuration
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?)

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

57

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

• During design, consider event locations and
  workload characteristics.
• For example

Wildlife tracking in a forest
Intrusion detection at a border
58

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

• 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
• In a loop, do increase f, then call
  FindSetSpeed(f).
• When FindSetSpeed(f) fails, reduce f by one
  increment
• The next call to FindSetSpeed(f) will be the
  answer

59
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

60
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 QoS in a localized manner

EDCF MAC Parameters
Simulation Environment Settings
61
Experiment 1
Reachability constant 0.5 Delay 0.3 1.0

• 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

62
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 QoS
  differentiation for even 20 flows and 70 RP
• SPEED cannot differentiate service and misses
  requirement for 18 flows

63
Experiment 3
Reachability 0.7 0.2 Delay 0.3 1.0

• MMSPEEDs On-Time Reachability
• Accommodates as many as 18 flows across all 4
  flow groups
• Can accommodate all 20 flows for some groups

• SPEEDs On-Time Reachability
• Accommodates only 12 flows across the 4 flow
  groups
• Due to mixing up all flow groups without any
  differentiation

64
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

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

66
Experiment 6

• Nodes In Motion
• 150 nodes
• Randomly placed
• 4 flow groups, 3 flows per group
• First 200s All nodes static
• 400s 600s 20 nodes moving
• 600s 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

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

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?