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

Low-Power Wireless Applications Have diverse communication requirements… Environmental monitoring: Long-term data collection at a single sink PermaSense [Beutel et al., IPSN 2009] If we look at low-power wireless applications that have emerged in the last years, we can notice that their requirements in terms of communication are getting more and more diverse. November 7, 2012 Low-Power Wireless Bus

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

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

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 DRAP + CTP + custom MAC Custom collection/ dissemination + LPL Dozer To meet these diverse requirements, these application need to form ensembles of different protocols, because current protocols are designed for specific patterns and scenarios. This approach is time-consuming, as it requires to investigate the interactions between different protocols. In our paper instead we show that a single solution for all communication is possible -> November 7, 2012 Low-Power Wireless Bus

Low-Power Wireless Bus (LWB) 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 To this end, we propose LWB ALL NODES RECEIVE ALL PACKETS We achieve these properties with a single protocol by using 3 design principles -> November 7, 2012 Low-Power Wireless Bus

LWB Design Principles Use only network floods 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 All nodes receive all data Only one node transmits at a certain time (collision-free) The controller determines which node transmits when November 7, 2012 Low-Power Wireless Bus

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 Atomic operation: all nodes have data in the end November 7, 2012 Low-Power Wireless Bus

Time-Triggered Operation LWB operation is confined to rounds A round consists of non-overlapping slots Each slot corresponds to a distinct flood Round period T t n1 n2 n3 n1 LWB active at ALL NODES (radio off between rounds) Each slot is allocated to one node Initiator of the flood, all others receive and relay: ALL PARTICIPATE IN ALL COMMUNICATION n2 n1 n3 November 7, 2012 Low-Power Wireless Bus

Time-Triggered Operation LWB operation is confined to rounds A round consists of non-overlapping slots Each slot corresponds to a distinct flood Round period T t n1 n2 n3 n2 Initiator of the flood, all others receive and relay n2 n1 n3 November 7, 2012 Low-Power Wireless Bus

Time-Triggered Operation LWB operation is confined to rounds A round consists of non-overlapping slots Each slot corresponds to a distinct flood Round period T t n1 n2 n3 n3 Initiator of the flood, all others receive and relay From network scale to single node -> n2 n1 n3 November 7, 2012 Low-Power Wireless Bus

Application Interface 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() remove_stream() Low-Power Wireless Bus LWB send_data() data_received() controller LWB logic transmits requests to the controller November 7, 2012 Low-Power Wireless Bus

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 Stand-alone component, active at the controller Desired policy just by modifying a single component How are schedule and stream requests transmitted? -> November 7, 2012 Low-Power Wireless Bus

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 controller computes new schedule controller Schedule n1 Data n2 n3 … (not allocated) Contention November 7, 2012 Low-Power Wireless Bus

Low-Power Wireless Bus Example LWB Execution n2 n1 c n1 generates packets at t = 0, 3, 6, …, 60, … n2 generates packets at t = 0, 5, 10, …, 60, … t c n1 n2 add stream Receive from n1 Compute new schedule T = 1 {Ø} add stream Receive from n1 Compute new schedule T = 1 {Ø} c is aware of n1’s data stream Schedule Contention t = 0 November 7, 2012 Low-Power Wireless Bus

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

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

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

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

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 November 7, 2012 Low-Power Wireless Bus

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 November 7, 2012 Low-Power Wireless Bus

Evaluation Methodology Four testbeds Seven combinations of routing+MAC protocols Testbed TWIST KANSEI CONETIT LOCAL Location TU Berlin Ohio State Univ. Univ. of Seville ETH Zurich Nodes 90 260 26 (5 mobile) 55 Diameter 3 hops 4 hops 5 hops Scenario Protocols Many-to-one CTP+{CSMA, LPL, A-MAC}, Dozer Many-to-many Muster+{CSMA, LPL} Mobile sink/sources BCP+CSMA, CTP+CSMA November 7, 2012 Low-Power Wireless Bus

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 Many-to-many data collection protocols November 7, 2012 Low-Power Wireless Bus

Many-to-One: Light Traffic LOCAL (5 hops): 1 sink, 54 sources generation period: 2 min High data yield (99.98 %) Low, even radio duty cycle (0.43 %) Average performance comparable to Dozer Outperforms contention- based protocols Hotspot nodes die first -> network partition sink November 7, 2012 Low-Power Wireless Bus

Many-to-One: Fluctuating Traffic LOCAL (5 hops): 1 sink, 54 sources 14 with varying generation period LWB promptly adapts to varying traffic load Round period T Slot allocation Additional complexity to make Dozer and LPL adaptable sink November 7, 2012 Low-Power Wireless Bus

Low-Power Wireless Bus Static vs. Mobile Sink CONETIT (3 hops): 1 sink, 25 sources generation period: {4, 2, 1} s LWB performs as in static scenarios (no topology-dependent state to update) Performance loss with BCP sink (1 m/s) November 7, 2012 Low-Power Wireless Bus

Low-Power Wireless Bus 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 ENERGY and BANDWIDTH November 7, 2012 Low-Power Wireless Bus

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 A UNIFIED, SIMPLE SOLUTION Self Managing Situated Computing ERC advanced grant November 7, 2012 Low-Power Wireless Bus

Low-Power Wireless Bus Questions? FLOCKLAB DEMO!!! November 7, 2012 Low-Power Wireless Bus