Low-Power Wireless Bus Federico Ferrari 1, Marco Zimmerling 1, Luca Mottola 2, Lothar Thiele 1 1 Computer Engineering and Networks Laboratory, ETH Zurich,

Low-Power Wireless Bus

Federico Ferrari1, Marco Zimmerling1, Luca Mottola2, Lothar Thiele1

1 Computer Engineering and Networks Laboratory, ETH Zurich, Switzerland2 Politecnico di Milano, Italy and Swedish Institute of Computer Science (SICS)

SenSys '12, November 7, 2012Toronto, ON, Canada

Low-Power Wireless Bus 2

Low-Power Wireless Applications

November 7, 2012

Have diverse communication requirements…

Environmental monitoring:

Long-term data collectionat a single sink

PermaSense [Beutel et al., IPSN 2009]


Clinical monitoring:

Mobile nodes immersed in static infrastructure

[Chipara et al., SenSys 2010]



November 7, 2012




November 7, 2012

Closed-loop control:

Collection at multiple sinks and dissemination

TRITon [Ceriotti et al., IPSN 2011]




November 7, 2012

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


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

November 7, 2012



LWB Design Principles

• 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

November 7, 2012

controller



Network Flooding: Glossy

• 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

November 7, 2012

[Ferrari et al., IPSN 2011]


Time-Triggered Operation

• LWB operation is confined to rounds

• A round consists of non-overlapping slots

• Each slot correspondsto a distinct flood

November 7, 2012

Round period T t

n1 n2 n3n1

n1

n2

n3






November 7, 2012

Round period T t

n1 n2 n3n2

n1

n2

n3






November 7, 2012

Round period T t

n1 n2 n3n3

n1

n2

n3


• Add and remove periodic streams of datastream_id add_stream(period, start_time)void remove_stream(stream_id)

• Send and receive application datavoid send_data(&data)void data_received(&data)


Application Interface

November 7, 2012

controllerApplication

add_stream()

remove_stream()

send_data()

data_received()LWB


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

November 7, 2012

T tn1 n2 n3


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

November 7, 2012

T t

controller

Schedule

(not allocated)

Contention

n1

Data

n2

Data

n3

Data

…controllercomputes

new schedule


0

Example LWB Execution

November 7, 2012

n2n1

c

t = 0Schedule Contention

n1 generates packets at t = 0, 3, 6, …, 60, …

add stream

Receivefrom n1

Computenew schedule

T = 1{Ø}

add stream

n2 generates packets at t = 0, 5, 10, …, 60, …

add stream

Receivefrom n1

Computenew schedule

T = 1{Ø}

add stream

t

c

n1

n2

c is aware of n1’s data stream


1


November 7, 2012

n2n1

c

t = 1

Computenew schedule

T = 1{n1}

data 0

add stream

Schedule ContentionData

Computenew schedule

T = 1{n1}

data 0

add stream

0 t

c

n1

n2

c is aware of n1’s and n2’s data streams

n1 generates packets at t = 0, 3, 6, …, 60, …n2 generates packets at t = 0, 5, 10, …, 60, …


20


November 7, 2012

n2n1

c

t = 2Schedule ContentionData

Computenew schedule

T = 1{n2}

data 0

Computenew schedule

T = 1{n2}

data 0

1 t

c

n1

n2

Allocate slots for packets ready to be transmitted



…

60210


November 7, 2012

n2n1

c

t = 60

t

c

n1

n2

Computenew schedule

T = 30{n1,n2}

data 60

data 60

Schedule ContentionData Data

Traffic is stable: Increase T



120……

60210


November 7, 2012

n2n1

c

t = 90

t

c

n1

n2

Computenew schedule

T = 30{n1,n2}

S C

Computenew schedule

Data

…

63 66 69 72 75 78 81 84 87 90

65 70 75 80 85 90

90



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


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


Evaluation Methodology

• Four testbeds

• Seven combinations of routing+MAC protocols

November 7, 2012

Testbed TWIST KANSEI CONETIT LOCAL

Location TU Berlin Ohio State Univ. Univ. of Seville ETH ZurichNodes 90 260 26 (5 mobile) 55Diameter 3 hops 4 hops 3 hops 5 hops

Scenario ProtocolsMany-to-one CTP+{CSMA, LPL, A-MAC}, DozerMany-to-many Muster+{CSMA, LPL}Mobile sink/sources BCP+CSMA, CTP+CSMA


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

November 7, 2012

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


sink

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

November 7, 2012

Many-to-One: Light Traffic


sink

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

November 7, 2012

Many-to-One: Fluctuating Traffic


(1 m/s)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

Static vs. Mobile Sink

November 7, 2012


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

November 7, 2012


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

November 7, 2012

Self Managing Situated ComputingERC advanced grant


Questions?

November 7, 2012

Documents

Low-Power Wireless Bus Federico Ferrari 1, Marco Zimmerling 1, Luca Mottola 2, Lothar Thiele 1 1 Computer Engineering and Networks Laboratory, ETH Zurich,