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 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

3. 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

4. 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

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
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

6. 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

7. 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

8. Network Flooding: Glossy
[Ferrari et al., IPSN 2011]
Fast and reliable
A few ms to flood > 100 nodes
Reliability > % 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

9. 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

10. 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

11. 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

12. 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

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
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

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

15. 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

16. 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

17. 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

18. 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

19. 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

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

22. 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

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

24. 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

25. 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

26. 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

27. 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

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

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