Broadcast-Free Collection
Protocol
Daniele Puccinellij, Marco Zunigak, Silvia Giordanoj, Pedro Jos’e Marr’onjk
jUniversity of Applied Sciences of Southern Switzerland
kDelft University of Technology
SenSys, 2012
MengLin, 2012/12/03
1
•
•
•
•
•
Outline
Introduction
Model Derivation
Design and Implementation
Experimental Evaluation
Conclusion
2
Intro/Model/Design/Evaluation/Conclusion
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 (B or U)
– Neighbor discovery (B)
– Routing tree formation (B)
3
Intro/Model/Design/Evaluation/Conclusion
Introduction
• Implemented in TinyOS
• BFC discovers routes by eavesdropping
on neighbors’ unicast transmissions
• Compare with broadcast-based CTP on
duty cycle of the radio (the fraction of radio
on-time)
4
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
5
Intro/Model/Design/Evaluation/Conclusion
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 interbeacon interval (IBI)
• CTP’s tIBI exponentially increasing from 64 ms to
about 8 minutes
6
Intro/Model/Design/Evaluation/Conclusion
Modeling the Duty Cycle
• Receive checks
tw
tc
• Broadcast transmissions trx
tIBI
tIPI
• Broadcast receptions
• Unicast transmissions
• Unicast receptions
Ni
Fi
Γi
Li
The LPL wake up interval
The LPL periodic energy check time
The packet reception time
The inter-beacon interval
The inter-packet interval
The number of neighbors of node i
The ratio of the total number of
forwarded packets (local+relay) per
locally generated packet
the number of transmissions
required for every successful
reception (the measured ETX)
The total listening load of node i
during the interval tIPI (either
intended and unintended receptions)
7
Intro/Model/Design/Evaluation/Conclusion
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 tw for Bcast
– [0.5, 2]
8
Intro/Model/Design/Evaluation/Conclusion
Insights Derived from the Model
• Eliminating broadcasts mostly benefits the
lifetime of the sink’s neighbors and leaf
nodes
9
Intro/Model/Design/Evaluation/Conclusion
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
10
Intro/Model/Design/Evaluation/Conclusion
Design and Implementation of BFC
• Leverage eavesdropping on neighbors’
unicast transmissions
• Connect to a neighbor that already has a
reliable path to the sink
• Based on BoX-MAC or any LPL with ack
• Assumption
– The sink is always on
– Every node injects traffic every tIPI
11
Intro/Model/Design/Evaluation/Conclusion
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
12
Intro/Model/Design/Evaluation/Conclusion
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 increased and LPL
increases the packet transmission duration?
13
Intro/Model/Design/Evaluation/Conclusion
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
14
Intro/Model/Design/Evaluation/Conclusion
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]
The expected duration 𝑡𝑤
1
of a unicast transmission 2
=
Wake up interval
𝑡𝑤 2
psnoop = 1 − 0.5nh
n potential parents
h IPI intervals
15
Intro/Model/Design/Evaluation/Conclusion
Snapshots of BFC Operation
16
Intro/Model/Design/Evaluation/Conclusion
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
17
Intro/Model/Design/Evaluation/Conclusion
•
•
•
•
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
18
Intro/Model/Design/Evaluation/Conclusion
Duty cycling savings
• Normalizing the results with respect to the
performance of CTP and the optimal duty
cycle in CTP
19
Intro/Model/Design/Evaluation/Conclusion
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
20
Intro/Model/Design/Evaluation/Conclusion
Node insertion
• When nodes added or reboot, CTP
aggressively broadcasts to pull a route
• For BFC, only cost unicast snoops
21
Intro/Model/Design/Evaluation/Conclusion
Node removal
• Similar to route breakage
• CTP might broadcasts to pull a route again
• Not easy to evaluate
22
BFC Intro/Model/Design/Evaluation/Conclusion
Poor connectivity
• CTP commands intense broadcast activity
to pull a route
• BFC simply gives up for intervals equal to
tseek
23
Intro/Model/Design/Evaluation/Conclusion
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)
24
Intro/Model/Design/Evaluation/Conclusion
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)
25
Intro/Model/Design/Evaluation/Conclusion
Thanks for Your Listening
26