Collection Tree Protocol ACM SenSys’09 Slides revised from Omprakash Gnawali

Outline Introduce Control Plane (two principles of CTP) Data Plane Datapath validation Adaptive beacons Data Plane Evaluation

Data collection protocols Three phases in handling sensory data in IoT: Sensory data acquisition Sensory data collection Sensory data computation CTP is a kind of data collection protocol Base Requirement Reliability: > 90% of packet Robustness: Operate without tuning or configuration Efficiency: Use minimum of transmissions Hardware Independence: no specific chip feature

CTP sink Is a protocol that computes routes from sensor to one or more sinks(base stations) Build and maintains minimum cost tree(s) with the sink(s) as root A distance vector protocol

Parent Selection Minimize transmission costs(ETX) b Minimize transmission costs(ETX) Every node maintains an estimate of the costs of a route to sink 10 e 3 1 2 d a sink 4 3 2 2 2 3 f c e: EXT(e) = 1 f: EXT(f) = 2 d: 2 + EXT(e) < 2 + ETX(f) b: 10 + EXT(e) c: 3 + EXT(f) a: 4 + EXT(d) < 3+ EXT(b) and 2 + EXT(c)

Challenges for data collection Link dynamics Links can be highly dynamic, particularly in the 2.4 GHz frequency space Wireless links can change in the order of a few hundred milliseconds Routing inconsistencies Rapid topology change can cause routing inconsistencies and route loops, cause packet loss in the data plane

Common Architecture Control Plane Data Plane Routing Engine Application Fwd Table Link Estimator Forwarding Engine Link Estimator: estimate and compute ETX to neighbors Routing Engine: compute route and cost to sink, generate fwd table Forwarding Engine: forward data packets according to fwd table Link Layer

CTP Noe Enable control and data plane interaction Control Plane Two mechanisms for efficient and agile topology maintenance Datapath validation Adaptive beaconing Routing Engine Application Link Estimator Forwarding Engine Link Layer

Outline Introduce Control Plane(two principles of CTP) Data Plane Datapath validation Adaptive beacons Data Plane Evaluation

Routing Consistency Next hop should be closer to the destination Maintain this consistency criteria on a path Inconsistency due to stale state ni ni+1 nk

Routing Inconsistency X Cost does not decrease Route inconsistency can cause routing loops 8.1 3.2 C B 4.6 A D 6.3 5.8

Datapath validation Use data packets to validate the topology Inconsistencies Loops Receiver checks for consistency on each hop Transmitter’s cost is in the data packet header

Datapath validation X Datapath validation Inconsistency 8.1 3.2 Cost in the packet Receiver checks Inconsistency Larger cost than on the packet On Inconsistency Don’t drop the packets One beacon interval pause in forwarding Immediately Signal the control plane X 3.2 < 4.6? 8.1 < 4.6? 8.1 8.1 3.2 C 4.6<5.8? 4.6 < 6.3? 4.6 4.6 B 4.6 6.3 5.8 < 8.1? A 5.8 D 6.3 5.8

Outline Introduce Control Plane(two principles of CTP) Data Plane Datapath validation Adaptive beacons Data Plane Evaluation

How Fast to Send Control Beacons? Control beacons are broadcasts Other protocols typically use periodic beacons to update network topology and link estimates Using a fixed rate beacon interval Faster rate lead to higher cost Slower rates lead to less agility Agility-efficiency tradeoff Agile+Efficient possible? CTP use Trickle Algorithm[Levis, 2004] Fast rate: more bandwidth and more energy, inference data packets Slow rate: less agility. if topology changes, cannot update immediately, route inconsistence and route loop can exist for a long time

Control Traffic Timing In CTP: Start with lowest intervals of 64ms When interval expires double it up to 1 hour Reset to lowest interval when inconsistent Reset the interval on three events Receive packet ETX <= self ETX Its routing cost decreases Significantly It receives a packet with P bit set TX Increasing interval Reset interval

Adaptive vs Periodic Beacons Total beacons / node 1.87 beacon/s 0.65 beacon/s Time (mins) Tutornet Less overhead compared to 30s-periodic

Path established in < 1s Efficient and agile at the same time Node Discovery A new node introduced Total Beacons Path established in < 1s Tutornet Time (mins) Efficient and agile at the same time

Outline Introduce Control Plane(two principles of CTP) Data Plane Datapath validation Adaptive beacons Data Plane Evaluation

Data Plane Design Queueing discipline Per-client queueing [top-level] each client may have one outstanding packet achieves better fairness than a shared queue Hybrid send queue [lower-level] contains both route-through and locally-generated traffic duplicate packets are dropped [i.e., not inserted in the queue]

Data Plane Design Transmit Timer Self-interference between packets Rate Control: delay the transmission of packets: randomized between (1.5, 2.5) packet times

Data Plane Design Transmission cache For each transmitted packet insert(origin, seqNo, THL) Determine if a packet is duplicate

Outline Introduce Control Plane(two principles of CTP) Data Plane Datapath validation Adaptive beacons Data Plane Evaluation

Variations in hardware, software, RF environment, and topology Experiments 12 testbeds 20-310 nodes 7 hardware platforms 4 radio technologies 6 link layers Variations in hardware, software, RF environment, and topology

Reliable, Efficient, and Robust Testbed Delivery Ratio Wymanpark 0.9999 Vinelab Tutornet NetEye Kansei 0.9998 Mirage-MicaZ Quanto 0.9995 Blaze 0.9990 Twist-Tmote 0.9929 Mirage-Mica2dot 0.9895 Twist-eyesIFXv2 0.9836 Motelab 0.9607 Motelab has slightly low delivery ratio, packet loss is the dominant cause of failure. Because Motelab nodes are only intermittently and sparsely connected False ack Retransmit High end-to-end delivery ratio (but not on all the testbeds!)

Reliable, Efficient, and Robust Reliable: Packets delivered to the sink

Reliable, Efficient, and Robust Efficient? TX required per packet delivery Tutornet CTP Noe Low data and control cost

Reliable, Efficient, and Robust Time (mins) Delivery Ratio 10 out of 56 nodes removed at t=60 mins Robust? Performance with disruption Tutornet No disruption in packet delivery

Reliable, Efficient, and Robust Nodes reboot every 5 mins Routing Beacons ~ 5 min Tutornet Delivery Ratio > 0.99 High delivery ratio despite serious network-wide disruption (most loss due to reboot while buffering packet)

Summary of Results 90-99.9% delivery ratio Compared to MultihopLQI Testbeds, configurations, link layers Compared to MultihopLQI 29% lower data delivery cost 73% fewer routing beacons 99.8% lower loop detection latency Robust against disruption Cause for packet loss vary across testbeds

Thank you!