1 / 28

pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols

pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols. IPSN 2012 Marco Zimmerling , Federico Ferrari (ETH - Zurich), Luca Mottola , Thiemo Voigt (Swedish Institute of Computer Science), Lothar Thiele (ETH - Zurich) BEST PAPER RUNNER UP - IP TRACK

marla
Télécharger la présentation

pTunes : Runtime Parameter Adaptation for Low-power MAC Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. pTunes: Runtime Parameter Adaptation for Low-power MAC Protocols IPSN 2012 Marco 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/10 Presented 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 knowledgeto 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 Both collecting network state and disseminating MAC parameters exploit Glossy by ECLiPSe c=[Ton, Toff, N] Challenges: - Minimum disruption - Timeliness - Consistency - Energy Efficiency

  7. Modeling Framework (routing tree) (traffic load) (link quality) 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 Tb: backoff before rtx : expected number of strobe iterations : duration of a strobe iteration at the sender (attempts to rx)

  15. LPP: receiver-initiated • For broadcast: Tm = 2*Tl+ Toff(It seems that they mistype Tonas Tm ) at most Ton

  16. Protocol-specific Modeling • MAC parameters c=[Ton, Toff, N] • Reliability • Latency • Lifetime : LPP duty cycle period ; {0,…,Trm}: random dist. for probe Tb: backoff before rtx : wait time before rx a probe, pi: prob of rxi-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 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 fasterif they use dedicated solution technique Collection period Tc: can range from a few tens of seconds to several minutes Glossy: ~5.2ms for a single flood duty cycles of state-of-art MAC is 3-7%, much higher than the overhead of pTunes

  19. Testbed • 44 TmoteSkynodes 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 minmaximizes 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 • 1stexp: use pTunes only in the very beginning2ndexp: let pTunes run throughoutthe 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

More Related