1. Broadcast-Free Collection Protocol Daniele Puccinelli , Marco Zuniga , Silvia Giordano , Pedro Jos’e Marr’onj   University of Applied Sciences of Southern Switzerland  Delft University of Technology SenSys, 2012 MengLin, 2012/12/03 1

2. Outline Introduction Model Derivation Design and Implementation Experimental Evaluation Conclusion 2 Intro/Model/Design/Evaluation/Conclusion

3. Introduction Broadcast-Free collection protocol –Running data collection protocol without any broadcast and only with unicast traffic Broadcasts in asynchronous low-power listening (LPL) are actually more expensive than unicasts in energy footprint Broadcasts usually used in –Data dissemination (B or U) –Neighbor discovery (B) –Routing tree formation (B) 3 Intro/Model/Design/Evaluation/Conclusion

4. Introduction Implemented in TinyOS BFC discovers routes by eavesdropping on neighbors’ unicast transmissions Compare with broadcast-based CTP on duty cycle of the radio (the fraction of radio on-time) 4

5. Broadcast VS Unicast BoX-MAC (B-MAC + X-MAC) –Most popular LPL in TinyOS’ MAC layer –Send packet trains to stretch the transmission duration Unicast packet trains can be cut short by ack Broadcast must match the entire wakeup interval –Broadcast packet is twice as costly as unicast packet 5 Intro/Model/Design/Evaluation/Conclusion

6. Broadcast VS Unicast Data collection protocols –Unicasts for data traffic –Broadcasts for control traffic to form routing structure –Trickle algorithm for the management of broadcast control traffic First aggressively use beacons to discover a route Finally converge to a fixed steady-state inter- beacon interval (IBI) CTP’s t IBI exponentially increasing from 64 ms to about 8 minutes 6 Intro/Model/Design/Evaluation/Conclusion

7. Modeling the Duty Cycle Receive checks Broadcast transmissions Broadcast receptions Unicast transmissions Unicast receptions 7 Intro/Model/Design/Evaluation/Conclusion t w The LPL wake up interval t c The LPL periodic energy check time t rx The packet reception time t IBI The inter-beacon interval t IPI The inter-packet interval N i The number of neighbors of node i F i The ratio of the total number of forwarded packets (local+relay) per locally generated packet Γ i the number of transmissions required for every successful reception (the measured ETX) L i The total listening load of node i during the interval t IPI (either intended and unintended receptions)

8. Insights Derived from the Model Roles of nodes –Leaves (nodes with Fi < 2 that are not within one hop of the sink) –Relays (nodes with Fi ≥ 2 that are not within one hop of the sink) –Sink’s neighbors Optimal t w for Bcast –[0.5, 2] 8 Intro/Model/Design/Evaluation/Conclusion

9. Insights Derived from the Model Eliminating broadcasts mostly benefits the lifetime of the sink’s neighbors and leaf nodes 9 Intro/Model/Design/Evaluation/Conclusion

10. Insights Derived from the Model Eliminating broadcasts widens the optimal wakeup interval range –With broadcast, increasing t w means longer sleep, but also costlier transmissions –Without broadcast Duty cycles being insensitive to change of t w under very low traffic rate scenarios Insensitive to out-of-network interference, that is less false busy 10 Intro/Model/Design/Evaluation/Conclusion

11. Design and Implementation of BFC Leverage eavesdropping on neighbors’ unicast transmissions Connect to a neighbor that already has a reliable path to the sink Based on BoX-MAC or any LPL with ack Assumption –The sink is always on –Every node injects traffic every t IPI 11 Intro/Model/Design/Evaluation/Conclusion

12. Route Discovery Initialization –Discover the sink by sending 1~2 unicast pkt to sink; otherwise, goes into hibernation –Eavesdrop on unicast transmissions every t w Parent Selection –Data path validation Route assessing: sum up the measured ETXs Viability flag setting: set flag after sending and receiving ν consecutive acks –Viable parents advertisement –Simply select workable parents 12 Intro/Model/Design/Evaluation/Conclusion

13. Route Discovery Best Effort Data Delivery –Not guarantee end-to-end delivery –Set maximum retransmissions and Time to Live (TTL) After N retx =6 unicasts, drop current parent After TTL=N max =32 unicasts, drop packet –BFC jitter transmissions to alleviate hidden node effects as t w is increased and LPL increases the packet transmission duration? 13 Intro/Model/Design/Evaluation/Conclusion

14. Route Maintenance Route breakage occurs when no longer has a valid parent Route failure due to channel dynamics –Asymmetric for ack and unreliable links Route failure due to traffic dynamics –Congestion: reset viability flag or disable ack Route Repair –Governed by a Vetting period –New parent accepted if measured ETX is the same –Avoid loops 14 Intro/Model/Design/Evaluation/Conclusion

15. Design and Implementation of BFC 15 Intro/Model/Design/Evaluation/Conclusion The expected duration of a unicast transmission Wake up interval

16. Snapshots of BFC Operation 16 Intro/Model/Design/Evaluation/Conclusion

17. Evaluation Evaluate on three different testbeds, but focus on most challenging Motelab (low density and unstable link) Compare BFC with CTP Measure to ensure similar channel condition in each experiment Use duty cycle as a key metric Not much difference in delivery rate and throughput 17 Intro/Model/Design/Evaluation/Conclusion

18. Median and mean for all nodes Optimal interval for CTP is [1,2] Much wider and flatter t w for BFC Sink neighbors’ unicasts are cheaper Leaves’ unicasts are rare 18 Intro/Model/Design/Evaluation/Conclusion

19. Duty cycling savings Normalizing the results with respect to the performance of CTP and the optimal duty cycle in CTP 19 Intro/Model/Design/Evaluation/Conclusion

20. Impact of the network structure Place the sink at the edge of the network Focus on [0.5, 5] sec BFC still much wider than CTP 20 Intro/Model/Design/Evaluation/Conclusion

21. Node insertion When nodes added or reboot, CTP aggressively broadcasts to pull a route For BFC, only cost unicast snoops 21 Intro/Model/Design/Evaluation/Conclusion

22. Node removal Similar to route breakage CTP might broadcasts to pull a route again Not easy to evaluate 22 Intro/Model/Design/Evaluation/Conclusion BFC

23. Poor connectivity CTP commands intense broadcast activity to pull a route BFC simply gives up for intervals equal to t seek 23 Intro/Model/Design/Evaluation/Conclusion

24. Latency Use throughput as a proxy for connectivity 1 t IPI for CTP, 6 t IPI for BFC (middle), 13.5 t IPI for BFC (edge) Acceptable One-time delays (43 mins) 24 Intro/Model/Design/Evaluation/Conclusion

25. Conclusion Practical to perform data collection without broadcast control traffic Energy efficient for sink’s neighbors and poor connectivity Complete research Nice organization but tedious in writing Might not be useful in many cases (short bootstrap time) 25 Intro/Model/Design/Evaluation/Conclusion

26. Thanks for Your Listening 26