[Tinyos-2-commits] CVS: tinyos-2.x/doc/html tep123.html,1.6,1.7
Phil Levis
scipio at users.sourceforge.net
Mon Feb 5 19:45:30 PST 2007
Update of /cvsroot/tinyos/tinyos-2.x/doc/html
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv7188/html
Modified Files:
tep123.html
Log Message:
Updates to TEP 123.
Index: tep123.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tep123.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** tep123.html 12 Dec 2006 18:22:53 -0000 1.6
--- tep123.html 6 Feb 2007 03:45:27 -0000 1.7
***************
*** 304,310 ****
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">3-Aug-2006</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1.2.3</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2006-10-25</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
--- 304,310 ----
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">3-Aug-2006</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.6</td>
</tr>
! <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2007-01-16</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
***************
*** 359,374 ****
<div class="section">
<h1><a id="collection-and-ctp" name="collection-and-ctp">3. Collection and CTP</a></h1>
! <p>CTP uses expected transmissions (ETX) as its routing gradient. A root has an
! ETX of 0. The ETX of a node is the ETX of its parent plus the ETX of its
! link to its parent. This additive measure assumes that nodes use link-level
! retransmissions. Given a choice of valid routes, CTP SHOULD choose the one with the
! lowest ETX value. CTP represents ETX values as 16-bit fixed-point real numbers
! with a precision of hundredths. An ETX value of 451, for example, represents
! an ETX of 4.51, while an ETX value of 109 represents an ETX of 1.09.</p>
! <p>Routing loops are a problem that can emerge in a CTP network. Routing loops
! generally occur when a node choose a new route that has a significantly higher
! ETX than its old one, perhaps in response to losing connectivity with a candidate
! parent. If the new route includes a node which was a descendant, then a loop
! occurs.</p>
<p>CTP addresses loops through two mechanisms. First, every CTP packet
contains a node's current gradient value. If CTP receives a data frame with
--- 359,375 ----
<div class="section">
<h1><a id="collection-and-ctp" name="collection-and-ctp">3. Collection and CTP</a></h1>
! <p>CTP uses expected transmissions (ETX) as its routing gradient. A root
! has an ETX of 0. The ETX of a node is the ETX of its parent plus the
! ETX of its link to its parent. This additive measure assumes that
! nodes use link-level retransmissions. Given a choice of valid routes,
! CTP SHOULD choose the one with the lowest ETX value. CTP represents
! ETX values as 16-bit fixed-point real numbers with a precision of
! hundredths. An ETX value of 451, for example, represents an ETX of
! 4.51, while an ETX value of 109 represents an ETX of 1.09.</p>
! <p>Routing loops are a problem that can emerge in a CTP network. Routing
! loops generally occur when a node choose a new route that has a
! significantly higher ETX than its old one, perhaps in response to
! losing connectivity with a candidate parent. If the new route includes
! a node which was a descendant, then a loop occurs.</p>
<p>CTP addresses loops through two mechanisms. First, every CTP packet
contains a node's current gradient value. If CTP receives a data frame with
***************
*** 419,423 ****
<blockquote>
<ul class="simple">
! <li>C: Congestion notification. If a node is receiving packets faster than it can forward them, it MAY set the C field to notify other nodes. If a node hears a packet from node <em>N</em> with the C bit set, it MUST NOT transmit CTP data frames to <em>N</em> until it hears a packet from N with the C bit cleared.</li>
<li>P: Routing pull. The P bit allows nodes to request routing information from other nodes. If a node with a valid route hears a packet with the P bit set, it SHOULD transmit a routing frame in the near future.</li>
<li>THL: Time Has Lived. When a node generates a CTP data frame, it MUST set THL to 0. When a node receives a CTP data frame, it MUST increment the THL. If a node receives a THL of 255, it increments it to 0.</li>
--- 420,424 ----
<blockquote>
<ul class="simple">
! <li>C: Congestion notification. If a node drops a CTP data frame, it MUST set the C field on the next data frame it transmits.</li>
<li>P: Routing pull. The P bit allows nodes to request routing information from other nodes. If a node with a valid route hears a packet with the P bit set, it SHOULD transmit a routing frame in the near future.</li>
<li>THL: Time Has Lived. When a node generates a CTP data frame, it MUST set THL to 0. When a node receives a CTP data frame, it MUST increment the THL. If a node receives a THL of 255, it increments it to 0.</li>
***************
*** 458,462 ****
<blockquote>
<ul class="simple">
! <li>C: Same as data frame.</li>
<li>P: Same as data frame.</li>
<li>parent: The node's current parent.</li>
--- 459,463 ----
<blockquote>
<ul class="simple">
! <li>C: Congestion notification. If a node drops a CTP data frame, it MUST set the C field on the next routing frame it transmits.</li>
<li>P: Same as data frame.</li>
<li>parent: The node's current parent.</li>
***************
*** 491,517 ****
<div class="section">
<h2><a id="link-estimation" name="link-estimation">6.1 Link Estimation</a></h2>
! <p>The link estimator estimates the ETX to single-hop neighbors.
! The implementation uses two mechanisms to estimate the quality of a link:
! periodic broadcast packets and data packets. The estimator itself
! only generates broadcast packets. For data traffic, it depends on
! other components telling it about acknowledged and unacknowledged
! transmissions.</p>
! <p>The periodic broadcast packets have sequence numbers, which the
! estimator uses to estimate the sender-to-receiver packet reception
! rate (PRR). The data payload of periodic broadcast packets contain
! these estimates. Therefore, when node A receives a link estimation
! broadcast message from node B, it can use the packet header to
! estimate the B-to-A PRR and the packet payload to update B's
! estimate of the A-to-B PRR.</p>
! <p>Multiplying these two values gives a <em>bidirectional</em> PRR, or
! an estimate of the probability that if A transmits a packet to B,
! B will successfully hear and acknowledge the packet and A will
! hear the acknowledgment. The inverse of the bidirecitonal PRR
! is the ETX.</p>
! <p>CTP link estimation adapts its beaconing rate to be slow when
! its routing table is stable and faster when changes occur.
! It adjusts the beaconing interval using an algorithm similar
! to the trickle dissemination protocol[<a href="#id1" name="id2"><span class="problematic" id="id2">2_</span></a>]. CTP sends beacons
! more often when one of three conditions occurs:</p>
<blockquote>
<ol class="arabic simple">
--- 492,503 ----
<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="#id4" id="id1" name="id1">[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="#id5" id="id2" name="id2">[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">
***************
*** 521,530 ****
</ol>
</blockquote>
! <p>CTP also estimates link quality using data transmissions. This
! is a direct measure of ETX. Whenever the data path transmits a
! packet, it tells the link estimator the destimation 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
--- 507,516 ----
</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 destimation 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
***************
*** 535,549 ****
the transmission rate, then it can quickly detect a broken link and
switch to another candidate neighbor.</p>
</div>
<div class="section">
<h2><a id="routing-engine" name="routing-engine">6.2 Routing Engine</a></h2>
! <p>The</p>
</div>
</div>
! <div class="system-messages section">
! <h1>Docutils System Messages</h1>
! <div class="system-message" id="id1">
! <p class="system-message-title">System Message: <a name="id1">ERROR/3</a> (<tt class="docutils">txt/tep123.txt</tt>, line 232); <em><a href="#id2">backlink</a></em></p>
! Unknown target name: "2".</div>
</div>
</div>
--- 521,634 ----
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/le/LinkEstimatorP</span></tt> implements the
+ link estimator. It couples LEEP-based and data-based estimates.</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 repsonsibilities:</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>
! </div>
! <div class="section">
! <h1><a id="id3" name="id3">8. Citations</a></h1>
! <table class="docutils footnote" frame="void" id="id4" rules="none">
! <colgroup><col class="label" /><col /></colgroup>
! <tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id1" name="id4">[1]</a></td><td>TEP 124: Link Estimation Extension Protocol</td></tr>
! </tbody>
! </table>
! <table class="docutils footnote" frame="void" id="id5" rules="none">
! <colgroup><col class="label" /><col /></colgroup>
! <tbody valign="top">
! <tr><td class="label"><a class="fn-backref" href="#id2" name="id5">[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>
</div>
</div>
More information about the Tinyos-2-commits
mailing list