Low-Power Wireless Bus

1. Low-Power Wireless Bus Federico Ferrari1, Marco Zimmerling1, Luca Mottola2, Lothar Thiele1 1 Computer Engineering and Networks Laboratory, ETH Zurich, Switzerland 2 Politecnico di Milano, Italy and Swedish Institute of Computer Science (SICS) SenSys '12, November 7, 2012 Toronto, ON, Canada

2. Low-Power Wireless Applications Have diverse communication requirements… Environmental monitoring: Long-term data collectionat a single sink PermaSense[Beutel et al., IPSN 2009] Low-Power Wireless Bus

3. Low-Power Wireless Applications Have diverse communication requirements… Clinical monitoring: Mobile nodes immersed in static infrastructure [Chipara et al., SenSys 2010] Low-Power Wireless Bus

4. Low-Power Wireless Applications Have diverse communication requirements… Closed-loop control: Collection at multiple sinks and dissemination TRITon [Ceriotti et al., IPSN 2011] Low-Power Wireless Bus

5. Low-Power Wireless Applications Have diverse communication requirements… Employ increasingly complex protocol ensembles • Which protocol(s) for future applications? • Distributed control loops • Highly mobile scenarios Dozer DRAP + CTP+ custom MAC Custom collection/ dissemination + LPL Low-Power Wireless Bus

6. Low-Power Wireless Bus (LWB) Low-Power Wireless Bus • Shared bus for low-power wireless networks,where all nodes receive all packets • Multiple communication patterns • Node mobility without performance loss • Resilience to topology changes • High reliability and efficiency Low-Power Wireless Bus

7. LWB Design Principles Low-Power Wireless Bus • Use only network floods • Multi-hop wireless network  Shared bus • Synchronized, time-triggered operation • Collision-free and efficient bus accesses • Centralized scheduling • A controller node orchestrates all communication controller Low-Power Wireless Bus

8. Network Flooding: Glossy [Ferrari et al., IPSN 2011] • Fast and reliable • A few ms to flood > 100 nodes • Reliability > 99.99 % in most scenarios • Accurate global time synchronization (< 1 ms) • Enables time-triggered operation • No topology-dependent state • Enables support for mobility Low-Power Wireless Bus

9. Time-Triggered Operation • LWB operation is confined to rounds • A round consists of non-overlapping slots • Each slot correspondsto a distinct flood Round period T t n1 n2 n1 n2 n3 n1 n3 Low-Power Wireless Bus

10. Time-Triggered Operation • LWB operation is confined to rounds • A round consists of non-overlapping slots • Each slot correspondsto a distinct flood Round period T t n2 n2 n1 n2 n3 n1 n3 Low-Power Wireless Bus

11. Time-Triggered Operation • LWB operation is confined to rounds • A round consists of non-overlapping slots • Each slot correspondsto a distinct flood Round period T t n3 n2 n1 n2 n3 n1 n3 Low-Power Wireless Bus

12. Application Interface Low-Power Wireless Bus • Add and remove periodic streams of data stream_id add_stream(period, start_time) void remove_stream(stream_id) • Send and receive application data void send_data(&data) void data_received(&data) add_stream() Application LWB remove_stream() send_data() data_received() controller Low-Power Wireless Bus

13. Centralized Scheduling • Scheduler: active at the controller • Receives stream requests • Computes communication schedule • Round period T • Allocation of slots to streams • Example scheduling policy • Minimize energy while providing enough bandwidth • Ensure fair allocation of slots to streams T t n1 n2 n3 Low-Power Wireless Bus

14. LWB Activity during a Round • Schedule: sent by the controller, also for time-sync • Data: transmitted by allocated sources • Contention: competed by sources for stream requests T t controllercomputesnew schedule … • controller n1 n2 n3 (not allocated) Contention Schedule Data Data Data Low-Power Wireless Bus

15. Example LWB Execution n1 generates packets at t = 0, 3, 6, …, 60, … n2 generates packets at t = 0, 5, 10, …, 60, … c n2 n1 0 t c Computenew schedule Computenew schedule • T = 1 • {Ø} • T = 1 • {Ø} Receivefrom n1 Receivefrom n1 add stream add stream n1 c is aware of n1’s data stream add stream add stream n2 Schedule Contention t = 0 Low-Power Wireless Bus

16. Example LWB Execution n1 generates packets at t = 0, 3, 6, …, 60, … n2 generates packets at t = 0, 5, 10, …, 60, … c n2 n1 0 t 1 c Computenew schedule Computenew schedule • T = 1 • {n1} • T = 1 • {n1} data 0 data 0 n1 c is aware of n1’s and n2’s data streams add stream add stream n2 Schedule Data Contention t = 1 Low-Power Wireless Bus

17. Example LWB Execution n1 generates packets at t = 0, 3, 6, …, 60, … n2 generates packets at t = 0, 5, 10, …, 60, … c n2 n1 0 2 t 1 c Computenew schedule Computenew schedule • T = 1 • {n2} • T = 1 • {n2} n1 Allocate slots for packets ready to be transmitted n2 data 0 data 0 Schedule Data Contention t = 2 Low-Power Wireless Bus

18. Example LWB Execution n1 generates packets at t = 0, 3, 6, …, 60, … n2 generates packets at t = 0, 5, 10, …, 60, … c n2 n1 … 0 2 t 1 60 c Computenew schedule • T = 30 • {n1,n2} n1 Traffic is stable: Increase T data 60 n2 data 60 Schedule Data Data Contention t = 60 Low-Power Wireless Bus

19. Example LWB Execution n1 generates packets at t = 0, 3, 6, …, 60, … n2 generates packets at t = 0, 5, 10, …, 60, … c n2 n1 … … 0 2 120 t 1 60 90 c Computenew schedule Computenew schedule 87 69 90 63 72 75 81 • … • T = 30 • {n1,n2} 66 78 84 65 70 75 80 85 90 n1 n2 S C Data t = 90 Low-Power Wireless Bus

20. LWB Run-Time Challenges • Node failures • Remain operational after controller failures • Stop allocating slots to failed sources • Communication failures • Nodes communicate only if synchronized • Promptly adapt to traffic changes • Decrease T after a received stream request Low-Power Wireless Bus

21. Evaluation Methodology • LWB prototype • On top of Contiki, targeting Tmote Sky nodes • Metrics • Data yield: fraction of packets received at sink(s) • Radio duty cycle: fraction of time with radio on Low-Power Wireless Bus

22. Evaluation Methodology • Four testbeds • Seven combinations of routing+MAC protocols Low-Power Wireless Bus

23. Key Evaluation Findings(256 runs, 838 hours) The same LWB prototype: • Is efficient under a wide range of traffic loads • Supports mobile nodes with no performance loss • Outperforms many-to-many state of the art • Is minimally affected by interference or failures The same LWB prototype: • Is efficient under a wide range of traffic loads • Supports mobile nodes with no performance loss • Outperforms many-to-many state of the art • Is minimally affected by interference or failures Low-Power Wireless Bus

24. Many-to-One: Light Traffic LOCAL (5 hops):1 sink, 54 sourcesgeneration period: 2 min • High data yield(99.98 %) • Low, even radioduty cycle (0.43 %) • Average performancecomparable to Dozer • Outperforms contention-based protocols sink Low-Power Wireless Bus

25. Many-to-One: Fluctuating Traffic LOCAL(5 hops):1 sink, 54 sources14 with varying generation period • LWB promptly adaptsto varying traffic load • Round period T • Slot allocation • Additional complexityto make Dozer andLPL adaptable sink Low-Power Wireless Bus

26. Static vs. Mobile Sink CONETIT (3 hops):1 sink, 25 sourcesgeneration period: {4, 2, 1} s • LWB performs as instatic scenarios(no topology-dependentstate to update) • Performance losswith BCP sink (1 m/s) Low-Power Wireless Bus

27. Limitations • Scalability • Linear with total amount of traffic • Outperforms state of the art at 52 pkt/s • Impact of network diameter • Efficiency decreases in long networks • 14 hops: up to 300 streams with a period of 5 s Low-Power Wireless Bus

28. Conclusion: Simplicity = Efficiency • LWB: Unified solution for diverse applications • Flooding for all communication • Time-triggered and centralized operation • Highly reliable and energy-efficient • Same performance with mobility Self Managing Situated Computing ERC advanced grant Low-Power Wireless Bus

29. Questions? Low-Power Wireless Bus