+to notify other nodes, which might change their routes. The parent
+field acts as a surrogate for the single-hop destination field of
+a data packet: a parent can detect when a child's ETX is significantly
+below its own. When a parent hears a child advertise an ETX below its
+own, it MUST schedule a routing frame for transmission in the near
+future.</p>
+<p>A node MUST send CTP routing frames as broadcast messages.</p>
+</div>
+<div class="section">
+<h1><a id="implementation" name="implementation">6. Implementation</a></h1>
+<p>An implementation of CTP can be found in the tos/lib/net/ctp directory
+of TinyOS 2.0. This section describes the structure of that implementation
+and is not in any way part of the specification of CTP.</p>
+<p>This implementation has three major subcomponents:</p>
+<p>1) A <strong>link estimator</strong>, which is responsible for estimating the
+single-hop ETX of communication with single-hop neighbors.</p>
+<p>2) A <strong>routing engine</strong>, which uses link estimates as well as
+network-level information to decide which neighbor is the next
+routing hop.</p>
+<p>3) A <strong>forwarding engine</strong>, which maintains a queue of packets
+to send. It decides when and if to send them. The name is a little
+misleading: the forwarding engine is responsible for forwarded traffic
+as well as traffic generated on the node.</p>
+<div class="section">
+<h2><a id="link-estimation" name="link-estimation">6.1 Link Estimation</a></h2>
+<p>The implementation uses two mechanisms to estimate the quality of a link:
+periodic LEEP <a class="footnote-reference" href="#id6" id="id2" name="id2">[1]</a> packets and data packets. The implementation sends
+routing beacons as LEEP packets. These packets seed the neighbor table
+with bidirectional ETX values. The implementation adapts its beaconing
+rate based on network dynamics using an algorithm similar to the
+trickle dissemination protocol <a class="footnote-reference" href="#id7" id="id3" name="id3">[2]</a>. Beacons are sent on an exponentially
+increasing randomized timer. The implementation resets the timer to a
+small value when one or more of the following conditions are met:</p>
+<blockquote>
+<ol class="arabic simple">
+<li>The routing table is empty (this also sets the P bit)</li>
+<li>The node's routing ETX increases by >= 1 transmission</li>
+<li>The node hears a packet with the P bit set</li>
+</ol>
+</blockquote>
+<p>The implementation augments the LEEP link estimates with data
+transmissions. This is a direct measure of ETX. Whenever the data path
+transmits a packet, it tells the link estimator the destination and
+whether it was successfully acknowledged. The estimator produces an
+ETX estimate every 5 such transmissions, where 0 successes has an ETX
+of 6.</p>
+<p>The estimator combines the beacon and data estimates by incorporating
+them into an exponentially weighted moving average. Beacon-based
+estimates seed the neighbor table. The expectation is that the low
+beacon rate in a stable network means that for a selected route,
+data estimates will outweigh beacon estimates. Additionally, as
+the rate at which CTP collects data estimates is proportional to
+the transmission rate, then it can quickly detect a broken link and
+switch to another candidate neighbor.</p>
+<p>The component <tt class="docutils literal"><span class="pre">tos/lib/net/4bitle/LinkEstimatorP</span></tt> implements the
+link estimator. It couples LEEP-based and data-based estimates as
+described in <a class="footnote-reference" href="#id9" id="id4" name="id4">[4]</a>.</p>
+</div>
+<div class="section">
+<h2><a id="routing-engine" name="routing-engine">6.2 Routing Engine</a></h2>
+<p>The implementation's routing engine is responsible for picking the next
+hop for a data transmission. It keeps track of the path ETX values of
+a subset of the nodes maintained by the link estimation table. The minimum
+cost route has the smallest sum the path ETX from that node and the link
+ETX of that node. The path ETX is therefore the sum of link ETX values
+along the entire route. The component <tt class="docutils literal"><span class="pre">tos/lib/net/ctp/CtpRoutingEngineP</span></tt>
+implements the routing engine.</p>
+</div>
+<div class="section">
+<h2><a id="forwarding-engine" name="forwarding-engine">6.3 Forwarding Engine</a></h2>
+<p>The component <tt class="docutils literal"><span class="pre">tos/lib/net/ctp/CtpForwardingEngineP</span></tt> implements the
+forwarding engine. It has five responsibilities:</p>
+<blockquote>
+<ol class="arabic simple">
+<li>Transmitting packets to the next hop, retransmitting when necessary, and
+passing acknowledgment based information to the link estimator</li>
+<li>Deciding <em>when</em> to transmit packets to the next hop</li>
+<li>Detecting routing inconsistencies and informing the routing engine</li>
+<li>Maintaining a queue of packets to transmit, which are a mix of locally
+generated and forwarded packets</li>
+<li>Detecting single-hop transmission duplicates caused by lost acknowledgments</li>
+</ol>
+</blockquote>
+<p>The four key functions of the forwading engine are packet reception
+(<tt class="docutils literal"><span class="pre">SubReceive.receive()</span></tt>), packet forwarding (<tt class="docutils literal"><span class="pre">forward()</span></tt>), packet
+transmission (<tt class="docutils literal"><span class="pre">sendTask()</span></tt>) and deciding what to do after a packet
+transmission (<tt class="docutils literal"><span class="pre">SubSend.sendDone()</span></tt>).</p>
+<p>The receive function decides whether or not the node should forward a
+packet. It checks for duplicates using a small cache of recently received
+packets. If it decides a packet is not a duplicate, it calls the
+forwading function.</p>
+<p>The forwarding function formats the packet for forwarding. It checks the
+received packet to see if there is possibly a loop in the network.
+It checks if there is space in the transmission queue.
+If there is no space, it drops the packet and sets the C bit. If the
+transmission queue was empty, then it posts the send task.</p>
+<p>The send task examines the packet at the head of the transmission
+queue, formats it for the next hop (requests the route from the
+routing layer, etc.), and submits it to the AM layer.</p>
+<p>When the send completes, sendDone examines the packet to see the result.
+If the packet was acknowledged, it pulls the packet off the transmission
+queue. If the packet was locally generated, it signals sendDone() to the
+client above. If it was forwarded, it returns the packet to the forwarding
+message pool. If there are packets remaining in the queue (e.g., the
+packet was not acknowledged), it starts a randomized timer that reposts
+this task. This timer essentially rate limits CTP so that it does not
+stream packets as quickly as possible, in order to prevent self-collisions
+along the path.</p>
+</div>
+</div>
+<div class="section">
+<h1><a id="citations" name="citations">7. Citations</a></h1>
+<div class="line-block">
+<div class="line">Rodrigo Fonseca</div>
+<div class="line">473 Soda Hall</div>
+<div class="line">Berkeley, CA 94720-1776</div>
+<div class="line"><br /></div>
+<div class="line">phone - +1 510 642-8919</div>
+<div class="line">email - <a class="reference" href="mailto:rfonseca@cs.berkeley.edu">rfonseca@cs.berkeley.edu</a></div>
+<div class="line"><br /></div>
+<div class="line"><br /></div>
+<div class="line">Omprakash Gnawali</div>
+<div class="line">Ronald Tutor Hall (RTH) 418</div>
+<div class="line">3710 S. McClintock Avenue</div>
+<div class="line">Los Angeles, CA 90089</div>
+<div class="line"><br /></div>
+<div class="line">phone - +1 213 821-5627</div>
+<div class="line">email - <a class="reference" href="mailto:gnawali@usc.edu">gnawali@usc.edu</a></div>
+<div class="line"><br /></div>
+<div class="line"><br /></div>
+<div class="line">Kyle Jamieson</div>
+<div class="line">The Stata Center</div>
+<div class="line">32 Vassar St.</div>
+<div class="line">Cambridge, MA 02139</div>
+<div class="line"><br /></div>
+<div class="line">email - <a class="reference" href="mailto:jamieson@csail.mit.edu">jamieson@csail.mit.edu</a></div>
+<div class="line"><br /></div>
+<div class="line"><br /></div>
+<div class="line">Philip Levis</div>
+<div class="line">358 Gates Hall</div>
+<div class="line">Computer Science Laboratory</div>
+<div class="line">Stanford University</div>
+<div class="line">Stanford, CA 94305</div>
+<div class="line"><br /></div>
+<div class="line">phone - +1 650 725 9046</div>
+<div class="line">email - <a class="reference" href="mailto:pal@cs.stanford.edu">pal@cs.stanford.edu</a></div>
+<div class="line"><br /></div>
+<div class="line"><br /></div>
+<div class="line">Alec Woo</div>
+<div class="line">Arch Rock Corporation</div>
+<div class="line">501 2nd St. Ste 410</div>
+<div class="line">San Francisco, CA 94107-4132</div>
+<div class="line"><br /></div>
+<div class="line">email - <a class="reference" href="mailto:awoo@archrock.com">awoo@archrock.com</a></div>
+<div class="line"><br /></div>
+<div class="line"><br /></div>
+<div class="line">Sukun Kim</div>
+<div class="line">Samsung Electronics</div>
+<div class="line">416 Maetan-3-dong, Yeongtong-Gu</div>
+<div class="line">Suwon, Gyeonggi 443-742</div>
+<div class="line">Korea, Republic of</div>
+<div class="line"><br /></div>
+<div class="line">phone - +82 10 3065 6836</div>
+<div class="line">email - <a class="reference" href="mailto:sukun.kim@samsung.com">sukun.kim@samsung.com</a></div>
+</div>
+</div>
+<div class="section">
+<h1><a id="id5" name="id5">8. Citations</a></h1>
+<table class="docutils footnote" frame="void" id="id6" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id2" name="id6">[1]</a></td><td>TEP 124: Link Estimation Extension Protocol</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id7" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id3" name="id7">[2]</a></td><td>Philip Levis, Neil Patel, David Culler and Scott Shenker. "A
+Self-Regulating Algorithm for Code Maintenance and Propagation
+in Wireless Sensor Networks." In Proceedings of the First USENIX
+Conference on Networked Systems Design and Implementation (NSDI), 2004.</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id8" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id1" name="id8">[3]</a></td><td>TEP 119: Collection.</td></tr>
+</tbody>
+</table>
+<table class="docutils footnote" frame="void" id="id9" rules="none">
+<colgroup><col class="label" /><col /></colgroup>
+<tbody valign="top">
+<tr><td class="label"><a class="fn-backref" href="#id4" name="id9">[4]</a></td><td>Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, and Philip Levis.
+"Four Bit Wireless Link Estimation." In Proceedings of the Sixth Workshop
+on Hot Topics in Networks (HotNets VI), November 2007.</td></tr>
+</tbody>
+</table>