pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols
description
Transcript of pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols
![Page 1: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/1.jpg)
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
![Page 2: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/2.jpg)
2
Outline
• Introduction• System Model• Protocol Specific Modeling - X-MAC and LPP• Evaluation• Conclusion
![Page 3: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/3.jpg)
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
![Page 4: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/4.jpg)
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
![Page 5: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/5.jpg)
5
Outline
• Introduction• System Model• Protocol Specific Modeling - X-MAC and LPP• Evaluation• Conclusion
![Page 6: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/6.jpg)
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]
![Page 7: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/7.jpg)
7
Modeling Framework
(traffic load)
(link quality)
(routing tree)
X-MAC, LPP, etc
![Page 8: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/8.jpg)
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
![Page 9: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/9.jpg)
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
![Page 10: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/10.jpg)
10
Application-level Metrics
L L L
![Page 11: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/11.jpg)
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
![Page 12: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/12.jpg)
12
Outline
• Introduction• System Model• Protocol Specific Modeling - X-MAC and LPP• Evaluation• Conclusion
![Page 13: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/13.jpg)
13
X-MAC: sender-initiated
• For broadcast: Tm = 2*Ton + Toff
at most Tm(= Ton + Toff ?)
![Page 14: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/14.jpg)
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)
![Page 15: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/15.jpg)
15
LPP: receiver-initiated
• For broadcast: Tm = 2*Tl + Toff (It seems that they mistype Ton as Tm )
at most Ton
![Page 16: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/16.jpg)
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
![Page 17: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/17.jpg)
17
Outline
• Introduction• System Model• Protocol Specific Modeling - X-MAC and LPP• Evaluation• Conclusion
![Page 18: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/18.jpg)
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
![Page 19: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/19.jpg)
19
Testbed
• 44 Tmote Sky nodes and a interferer• Tc = 1min
![Page 20: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/20.jpg)
20
Static MAC Configuration Optimized for Different Situation
![Page 21: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/21.jpg)
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:
![Page 22: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/22.jpg)
22
Bandwidth and Queuing
![Page 23: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/23.jpg)
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
![Page 24: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/24.jpg)
24
Adaptation to Traffic Fluctuations
![Page 25: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/25.jpg)
25
Adaptation to Changes in Link Quality
![Page 26: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/26.jpg)
26
Interaction with Routing
![Page 27: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/27.jpg)
27
Outline
• Introduction• System Model• Protocol Specific Modeling - X-MAC and LPP• Evaluation• Conclusion
![Page 28: pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols](https://reader036.fdocuments.in/reader036/viewer/2022081505/568165be550346895dd8bd04/html5/thumbnails/28.jpg)
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