1

pTunes: Runtime Parameter Adaptation for Low-power MAC Protocols

IPSN 2012Marco Zimmerling, Federico Ferrari (ETH - Zurich), Luca Mottola, Thiemo

Voigt (Swedish Institute of Computer Science), Lothar Thiele (ETH - Zurich)BEST PAPER RUNNER UP - IP TRACK

NSLab study group 2012/09/10Presented by: Yuting

2

Outline

• Introduction• System Model• Protocol Specific Modeling - X-MAC and LPP• Evaluation• Conclusion

3

Introduction• Separate protocol-dependent from protocol-independent aspects• A complement of existing MAC protocol

– X-MAC, LPP, etc• Runtime adaptation

– traffic load, link quality, topology• Multi-objective

– reliability R, latency L, lifetime T• Parameter optimization

– according to the running MAC protocol• Centralized

– a base station running ECLiPSe integrates with the application• Utilize Glossy (IPSN'11) on Contiki

4

Note

• No need to rely on expert knowledge to find optimized operating parameters– Experience, rules of thumb: performance may not

be what we want– Several field trials: time consuming, deployment-

specific• Separating adaptivity from MAC operation

release the limitation of its applicability

5

Outline

• Introduction• System Model• Protocol Specific Modeling - X-MAC and LPP• Evaluation• Conclusion

6

Framework

Challenges:- Minimum disruption- Timeliness- Consistency- Energy Efficiency

by ECLiPSe

Both collecting network state and disseminating MAC parameters exploit Glossy

c=[Ton, Toff, N]

7

Modeling Framework

(traffic load)

(link quality)

(routing tree)

X-MAC, LPP, etc

8

Optimization

• Multi-objective optimization problem (MOP): max R, min L, max T– Pareto-optimal solutions: trade-off between (R,L,T)

• Epsilon-constraint method:treat all but one objective as constraints, ex:

• If either constraint is unsatisfiable because of bad network situation?-> depends on user, ex: just maximize R

9

Term Definition

• N: set of all nodes excluding the sink• M N⊆ : set of source nodes• L: set of communication links• Pn L⊆ : path originating at node n M includes all ∈

intermediate links that connect node n to the sink

10

Application-level Metrics

L L L

11

Protocol-independent Modeling

Note: here N is "the maximum number of rtx(retransmisstion) per packet" , not the set of nodes excluding sink

Note: Nftx,l depend on ps,l and N

Note: Q is battery capacity (current*time)

Note: 1. similar to packet generation rate , but this is packet transmission rate 2. will be used to deduce Dtx,n and Drx,n in protocol-specific modeling

12

Outline

• Introduction• System Model• Protocol Specific Modeling - X-MAC and LPP• Evaluation• Conclusion

13

X-MAC: sender-initiated

• For broadcast: Tm = 2*Ton + Toff

at most Tm(= Ton + Toff ?)

14

Protocol-specific Modeling• MAC parameters c=[Ton, Toff, N]• Reliability

• Latency

• Lifetime

: duration of a strobe iteration at the senderTb: backoff before rtx

: expected number of strobe iterations

(attempts to rx)

15

LPP: receiver-initiated

• For broadcast: Tm = 2*Tl + Toff (It seems that they mistype Ton as Tm )

at most Ton

16

Protocol-specific Modeling• MAC parameters c=[Ton, Toff, N]• Reliability

• Latency

• Lifetime

Tb: backoff before rtx

: LPP duty cycle period ; {0,…,Trm}: random dist. for probe

: wait time before rx a probe, pi: prob of rx i-th probe Ti: expected time to await i-th probe

17

Outline

• Introduction• System Model• Protocol Specific Modeling - X-MAC and LPP• Evaluation• Conclusion

18

Framework Evaluation

Collection period Tc: can range from a few tens of seconds to several minutesGlossy: ~5.2ms for a single floodduty cycles of state-of-art MAC is 3-7%, much higher than the overhead of pTunes

Only 6 bytes: nodeID, parentID, Fn, ratio of successful and total number of handshake Hs,l/Ht,l

(both of H are counted by a way similar to EWMA)

A few tens of seconds -> slow!will be faster if they use dedicated solution technique

19

Testbed

• 44 Tmote Sky nodes and a interferer• Tc = 1min

20

Static MAC Configuration Optimized for Different Situation

21

Model Validation

• TimedTrigger: every 10 min• Inter-packet interval (IPI) of all nodes: from

300 s to 180, 60, 30, 20, 10, 5, and 2 s• δ(Mi ) = m(Mi ) − e(Mi )• Results is very accurate:

22

Bandwidth and Queuing

23

Lifetime Gain• TimedTrigger: every 10 min

maximizes T subject to R ≥ 95 %• Increase the IPI from 10 s to 20 s, 30 s, 60 s, 3 min, 5 min, and

20 min• 1st exp: use pTunes only in the very beginning

2nd exp: let pTunes run throughout the exp• Lifetime gain: ratio between the lifetime w/ and w/o pTunes

24

Adaptation to Traffic Fluctuations

25

Adaptation to Changes in Link Quality

26

Interaction with Routing

27

Outline

• Introduction• System Model• Protocol Specific Modeling - X-MAC and LPP• Evaluation• Conclusion

28

Conclusion• Runtime adaptability• Flexible modeling approach• Efficient system support to “close the loop”• Meet the requirements of real world applications as the

network state changes• Eliminates the need for time-consuming, and yet error-prone,

manual MAC configuration• Some comment

– Well written with systematical analysis– Good extended work of Glossy– Optimization solving time is not very fast, and it get slower when

there are more nodes– Developer still need to model the protocol specific part