[Tinyos-2-commits] CVS: tinyos-2.x/doc/txt tep116.txt, 1.5,
1.6 tep123.txt, 1.7, 1.8 tep124.txt, 1.3, 1.4
Phil Levis
scipio at users.sourceforge.net
Wed Feb 28 14:33:34 PST 2007
Update of /cvsroot/tinyos/tinyos-2.x/doc/txt
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv15472/txt
Modified Files:
tep116.txt tep123.txt tep124.txt
Log Message:
Assorted TEP updates.
Index: tep116.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/txt/tep116.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** tep116.txt 12 Dec 2006 18:22:54 -0000 1.5
--- tep116.txt 28 Feb 2007 22:33:28 -0000 1.6
***************
*** 28,32 ****
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.
1. Introduction
--- 28,32 ----
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 AMSenderC and AMReceiverC.
1. Introduction
***************
*** 228,235 ****
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``.
2.2 Sending interfaces
--- 228,233 ----
The command address() returns the local AM address of the
node. AMPacket provides accessors for its two fields, destination and
! 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
***************
*** 334,338 ****
//Case 3
! message_t* ptr;
message_t* Receive.receive(message_t* msg, void* payload, uint8_t len) {
message_t* tmp = ptr;
--- 332,337 ----
//Case 3
! message_t buf;
! message_t* ptr = &buf;
message_t* Receive.receive(message_t* msg, void* payload, uint8_t len) {
message_t* tmp = ptr;
***************
*** 552,557 ****
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::
typedef nx_struct cc2420_header_t {
--- 551,556 ----
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 an example
! structure for a CC2420 (802.15.4) header::
typedef nx_struct cc2420_header_t {
Index: tep123.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/txt/tep123.txt,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** tep123.txt 6 Feb 2007 03:45:27 -0000 1.7
--- tep123.txt 28 Feb 2007 22:33:28 -0000 1.8
***************
*** 119,123 ****
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! |C|P| reserved | THL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETX |
--- 119,123 ----
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! |P|C| reserved | THL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETX |
***************
*** 132,137 ****
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.
* 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.
--- 132,137 ----
Field definitions are as follows:
* 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.
***************
*** 162,166 ****
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! |C|P| reserved | parent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| parent | ETX |
--- 162,166 ----
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! |P|C| reserved | parent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| parent | ETX |
***************
*** 171,176 ****
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.
* parent: The node's current parent.
* metric: The node's current routing metric value.
--- 171,176 ----
The fields are as follows:
* 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.
Index: tep124.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/txt/tep124.txt,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** tep124.txt 9 Feb 2007 21:01:06 -0000 1.3
--- tep124.txt 28 Feb 2007 22:33:28 -0000 1.4
***************
*** 35,42 ****
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.
2. Definitions
--- 35,42 ----
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. 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
***************
*** 46,54 ****
--------------------------------------------------------------------
! 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.
2.2 In-bound Link Quality
--- 46,56 ----
--------------------------------------------------------------------
! 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
More information about the Tinyos-2-commits
mailing list