broadcast-free collection protocol
DESCRIPTION
Broadcast-Free Collection Protocol. Daniele Puccinelli j , Marco Zuniga k , Silvia Giordano j , Pedro Jos’e Marr’onj k j University of Applied Sciences of Southern Switzerland k Delft University of Technology SenSys , 2012 MengLin , 2012/12/03. Outline. Introduction Model Derivation - PowerPoint PPT PresentationTRANSCRIPT
1
Broadcast-Free Collection Protocol
Daniele Puccinellij, Marco Zunigak, Silvia Giordanoj, Pedro Jos’e Marr’onjkjUniversity of Applied Sciences of Southern Switzerland
kDelft University of Technology
SenSys, 2012MengLin, 2012/12/03
2
Outline• Introduction• Model Derivation• Design and Implementation• Experimental Evaluation• Conclusion
Intro/Model/Design/Evaluation/Conclusion
3
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)
Intro/Model/Design/Evaluation/Conclusion
4
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)
5
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
Intro/Model/Design/Evaluation/Conclusion
6
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 inter-
beacon interval (IBI)• CTP’s tIBI exponentially increasing from 64 ms to
about 8 minutes
Intro/Model/Design/Evaluation/Conclusion
7
Modeling the Duty Cycle• Receive checks
• Broadcast transmissions
• Broadcast receptions
• Unicast transmissions
• Unicast receptions
Intro/Model/Design/Evaluation/Conclusion
tw The LPL wake up intervaltc The LPL periodic energy check timetrx The packet reception timetIBI The inter-beacon intervaltIPI The inter-packet interval
Ni The number of neighbors of node iFi The ratio of the total number of forwarded packets (local+relay) per locally generated packetΓi the number of transmissions required for every successful reception (the measured ETX)Li The total listening load of node i during the interval tIPI (either intended and unintended receptions)
8
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]
Intro/Model/Design/Evaluation/Conclusion
9
Insights Derived from the Model• Eliminating broadcasts mostly benefits the
lifetime of the sink’s neighbors and leaf nodes
Intro/Model/Design/Evaluation/Conclusion
10
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
Intro/Model/Design/Evaluation/Conclusion
11
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
Intro/Model/Design/Evaluation/Conclusion
12
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
Intro/Model/Design/Evaluation/Conclusion
13
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?
Intro/Model/Design/Evaluation/Conclusion
14
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 Intro/Model/Design/Evaluation/Conclusion
15
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]
psnoop = 1 − 0.5nh
n potential parents
h IPI intervalsIntro/Model/Design/Evaluation/Conclusion
The expected duration of a unicast transmission
Wake up interval
16
Snapshots of BFC Operation
Intro/Model/Design/Evaluation/Conclusion
17
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
Intro/Model/Design/Evaluation/Conclusion
18
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
Intro/Model/Design/Evaluation/Conclusion
19
Duty cycling savings• Normalizing the results with respect to the
performance of CTP and the optimal duty cycle in CTP
Intro/Model/Design/Evaluation/Conclusion
20
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
Intro/Model/Design/Evaluation/Conclusion
21
Node insertion• When nodes added or reboot, CTP
aggressively broadcasts to pull a route• For BFC, only cost unicast snoops
Intro/Model/Design/Evaluation/Conclusion
22
Node removal• Similar to route breakage• CTP might broadcasts to pull a route again• Not easy to evaluate
Intro/Model/Design/Evaluation/ConclusionBFC
23
Poor connectivity• CTP commands intense broadcast activity
to pull a route• BFC simply gives up for intervals equal to tseek
Intro/Model/Design/Evaluation/Conclusion
24
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)
Intro/Model/Design/Evaluation/Conclusion
25
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)
Intro/Model/Design/Evaluation/Conclusion
26
Thanks for Your Listening