From: scipio Date: Wed, 28 Feb 2007 22:34:19 +0000 (+0000) Subject: Updated HTML. X-Git-Tag: tinyos/2.0.1~151 X-Git-Url: https://oss.titaniummirror.com/gitweb/?a=commitdiff_plain;h=9ba4683a70cef0774863af6ff5da4b92f6353420;p=tinyos-2.x.git Updated HTML. --- diff --git a/doc/html/tep116.html b/doc/html/tep116.html index e7f71113..68a5c269 100644 --- a/doc/html/tep116.html +++ b/doc/html/tep116.html @@ -303,9 +303,9 @@ ul.auto-toc { Philip Levis Draft-Created:10-Dec-2004 -Draft-Version:1.1.2.11 +Draft-Version:1.6 -Draft-Modified:2006-06-27 +Draft-Modified:2007-02-28 Draft-Discuss:TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu> @@ -323,7 +323,7 @@ TEP 1.

The memo documents the interfaces used by packet protocol components in TinyOS 2.x as well as the structure and implementation of ActiveMessageC, the basic data-link HIL component. It also documents the virtualized -active message interfaces AMSender and AMReceiver.

+active message interfaces AMSenderC and AMReceiverC.

1. Introduction

@@ -506,10 +506,8 @@ interface AMPacket {

The command address() returns the local AM address of the node. AMPacket provides accessors for its two fields, destination and -type. It does not provide commands to set these fields, as they are -set in the sending call path (see Section 2.3). The setDestination -and setType commands fulfill a similar purpose to -Packet.setLength.

+type. It also provides commands to set these fields, for the same +reason that Packet allows a caller to set the payload length.

2.2 Sending interfaces

@@ -608,7 +606,8 @@ message_t* Receive.receive(message_t* msg, void* payload, uint8_t len) { } //Case 3 -message_t* ptr; +message_t buf; +message_t* ptr = &buf; message_t* Receive.receive(message_t* msg, void* payload, uint8_t len) { message_t* tmp = ptr; ptr = msg; @@ -812,8 +811,8 @@ that an active message received from one data link layer (e.g., the radio) can be passed to another data link layer (e.g., the UART) without shifting the data payload. This means that the message_header_t must include all data needed for AM fields, which might introduce headers -in addition to those of the data link. For example, this is the -structure of the CC2420 header:

+in addition to those of the data link. For example, this is an example +structure for a CC2420 (802.15.4) header:

 typedef nx_struct cc2420_header_t {
   nx_uint8_t length;
diff --git a/doc/html/tep123.html b/doc/html/tep123.html
index 7b49fd48..74ef2151 100644
--- a/doc/html/tep123.html
+++ b/doc/html/tep123.html
@@ -303,9 +303,9 @@ ul.auto-toc {
 Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, Sukun Kim, Philip Levis, and Alec Woo
 Draft-Created:3-Aug-2006
 
-Draft-Version:1.6
+Draft-Version:1.8
 
-Draft-Modified:2007-01-16
+Draft-Modified:2007-02-28
 
 Draft-Discuss:TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu>
 
@@ -405,7 +405,7 @@ to do so.

                      1
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|C|P| reserved  |      THL        |
+|P|C| reserved  |      THL        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |              ETX                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -419,8 +419,8 @@ to do so.

 
Field definitions are as follows:

 

 
    
-
  • C: Congestion notification. If a node drops a CTP data frame, it MUST set the C field on the next data frame it transmits.
    • 
 
  • 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.
    • 
+
  • C: Congestion notification. If a node drops a CTP data frame, it MUST set the C field on the next data frame it transmits.
    • 
 
  • 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.
    • 
 
  • ETX: The ETX routing metric of the single-hop sender. When a node transmits a CTP data frame, it MUST put the ETX value of its route through the single-hop destination in the ETX field.  If a node receives a packet with a lower gradient than its own, then it MUST schedule a routing frame in the near future.
    • 
 
  • origin: The originating address of the packet. A node forwarding a data frame MUST NOT modify the origin field.
    • 
@@ -448,7 +448,7 @@ acknowledgments enabled.
    
                      1
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|C|P| reserved  |      parent     |
+|P|C| reserved  |      parent     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     parent    |       ETX       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -458,8 +458,8 @@ acknowledgments enabled.
    
 
    The fields are as follows:
    
 
    
 
      
-
    • C: Congestion notification. If a node drops a CTP data frame, it MUST set the C field on the next routing frame it transmits.
      • 
 
    • P: Same as data frame.
      • 
+
    • C: Congestion notification. If a node drops a CTP data frame, it MUST set the C field on the next routing frame it transmits.
      • 
 
    • parent: The node's current parent.
      • 
 
    • metric: The node's current routing metric value.
      • 
 
    
diff --git a/doc/html/tep124.html b/doc/html/tep124.html
index b676de42..39875ed0 100644
--- a/doc/html/tep124.html
+++ b/doc/html/tep124.html
@@ -303,9 +303,9 @@ ul.auto-toc {
 Omprakash Gnawali
 Draft-Created:05-Feb-2006
 
-Draft-Version:1.2
+Draft-Version:1.4
 
-Draft-Modified:2007-02-09
+Draft-Modified:2007-02-28
 
 Draft-Discuss:TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu>
 
@@ -329,20 +329,22 @@ links to the neighbors.
    
 
    Routing protocols often require bi-directional link qualities to
 compute the routes. Nodes can estimate the quality of the in-bound
 link from a neighbor by estimating the ratio of successfully received
-messages and the total transmitted messages. These in-bound link
-qualities are exchanged among the neighbors using LEEP to determine
-the out-bound link qualities. Bi-directional link quality is computed
-using thus learned in-bound and out-bound link qualities.
    
+messages and the total transmitted messages. LEEP appends in-bound
+packet reception rate (PRR) estimates to packets. Other nodes hearing
+these packets can combine the in-bound PRR values with their own
+in-bound values to compute bi-directional link quality.

2. Definitions

2.1 Link Quality

-

Quality of the link between any two nodes describes the probability -with which data link layer packets can be received without any -error. This definition assumes uncorrelated link losses. The link -between the nodes A and B may have different quality in A to B and B -to A directions.

+

The link quality between a directed node pair (A,B) is the probability +that a packet transmitted by A will be successfully received by B. The +bidirectional link quality of an undirected node pair (A,B) is the +product of the link quality of (A,B) and (B,A). This definition +assumes independent link losses. It also includes the case when +the link quality of (A,B) and (B,A) are different; this can occur +due to local interference or noise.

2.2 In-bound Link Quality