Broadcast-Free Collection Protocol

1. Broadcast-Free Collection Protocol Daniele Puccinellij, Marco Zunigak, Silvia Giordanoj, Pedro Jos’eMarr’onjk jUniversityof Applied Sciences of Southern Switzerland kDelftUniversity of Technology SenSys, 2012 MengLin, 2012/12/03

2. Outline • Introduction • Model Derivation • Design and Implementation • Experimental Evaluation • Conclusion 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(Bor U) • Neighbor discovery (B) • Routing tree formation (B) Intro/Model/Design/Evaluation/Conclusion

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

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 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 tIBI exponentially increasing from 64 ms to about 8 minutes Intro/Model/Design/Evaluation/Conclusion

7. Modeling the Duty Cycle • Receive checks • Broadcast transmissions • Broadcast receptions • Unicast transmissions • Unicast receptions tw The LPL wake up interval tc The LPL periodic energy check time trx The packet reception time tIBI The inter-beacon interval tIPI The inter-packet interval NiThe number of neighbors of node i Fi The ratio of the total number of forwarded packets (local+relay) per locally generated packet Γithe number of transmissions required for every successful reception (the measured ETX) LiThe total listening load of node i during the interval tIPI (either intended and unintended receptions) Intro/Model/Design/Evaluation/Conclusion

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 twfor Bcast • [0.5, 2] 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 Intro/Model/Design/Evaluation/Conclusion

10. Insights Derived from the Model • Eliminating broadcasts widens the optimal wakeup interval range • With broadcast, increasing tw means longer sleep, but also costlier transmissions • Without broadcast • Duty cycles being insensitive to change of tw under very low traffic rate scenarios • Insensitive to out-of-network interference, that is less false busy 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 thesink • Based on BoX-MAC or any LPL with ack • Assumption • The sink is always on • Every node injects traffic every tIPI 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 tw • 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 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 Nretx=6 unicasts, drop current parent • After TTL=Nmax=32 unicasts, drop packet • BFC jitter transmissions to alleviate hidden node effects as tw is increasedand LPL increases the packet transmission duration? 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 Intro/Model/Design/Evaluation/Conclusion

15. Design and Implementation of BFC • Adaptive Low Power Listening • Lock to most active parents causing unbalanced routing tree • Halves heavily loaded nodes’ tw • Connectivity • P[overhearing a packet] psnoop = 1 − 0.5nh n potential parents h IPI intervals The expected duration of a unicast transmission Wake up interval Intro/Model/Design/Evaluation/Conclusion

16. Snapshots of BFC Operation 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 Intro/Model/Design/Evaluation/Conclusion

18. Median and mean for all nodes • Optimal interval for CTP is [1,2] • Much wider and flatter tw for BFC • Sink neighbors’ unicasts are cheaper • Leaves’ unicasts are rare 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 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 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 Intro/Model/Design/Evaluation/Conclusion

22. Node removal • Similar to route breakage • CTP might broadcasts to pull a route again • Not easy to evaluate 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 tseek Intro/Model/Design/Evaluation/Conclusion

24. Latency • Use throughput as a proxy for connectivity • 1 tIPI for CTP, 6 tIPI for BFC (middle), 13.5 tIPI for BFC (edge) • Acceptable One-time delays (43 mins) 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) Intro/Model/Design/Evaluation/Conclusion

26. Thanks for Your Listening