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 1 Outline Introduction System Model Protocol Specific Modeling - X-MAC and LPP Evaluation Conclusion 2 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 3 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 4 Outline Introduction System Model Protocol Specific Modeling - X-MAC and LPP Evaluation Conclusion 5 Framework 6 Challenges: - Minimum disruption - Timeliness - Consistency - Energy Efficiency by ECLiPSe Both collecting network state and disseminating MAC parameters exploit Glossy c=[T on, T off, N] Modeling Framework 7 (traffic load) (link quality) (routing tree) X-MAC, LPP, etc 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 8 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 9 Application-level Metrics 10 LL L Protocol-independent Modeling 11 Note: here N is "the maximum number of rtx(retransmisstion) per packet", not the set of nodes excluding sink Note: N ftx,l depend on p s,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 D tx,n and D rx,n in protocol-specific modeling Outline Introduction System Model Protocol Specific Modeling - X-MAC and LPP Evaluation Conclusion 12 X-MAC: sender-initiated For broadcast: T m = 2*T on + T off 13 at most T m (= T on + T off ?) Protocol-specic Modeling MAC parameters c=[T on, T off, N] Reliability Latency Lifetime 14 : duration of a strobe iteration at the sender Tb: backoff before rtx : expected number of strobe iterations (attempts to rx) LPP: receiver-initiated For broadcast: T m = 2*T l + T off (It seems that they mistype T on as T m ) 15 at most T on Protocol-specic Modeling MAC parameters c=[T on, T off, N] Reliability Latency Lifetime 16 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 Outline Introduction System Model Protocol Specific Modeling - X-MAC and LPP Evaluation Conclusion 17 Framework Evaluation 18 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 Only 6 bytes: nodeID, parentID, Fn, ratio of successful and total number of handshake H s,l /H t,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 Testbed 44 Tmote Sky nodes and a interferer Tc = 1min 19 Static MAC Configuration Optimized for Different Situation 20 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: 21 Bandwidth and Queuing 22 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 1 st exp: use pTunes only in the very beginning 2 nd exp: let pTunes run throughout the exp Lifetime gain: ratio between the lifetime w/ and w/o pTunes 23 Adaptation to Trafc Fluctuations 24 Adaptation to Changes in Link Quality 25 Interaction with Routing 26 Outline Introduction System Model Protocol Specific Modeling - X-MAC and LPP Evaluation Conclusion 27 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 28