[Tinyos-2-commits] CVS: tinyos-2.x/doc/txt tep119.txt,1.11,1.12

[Omprakash Gnawali]

Update of /cvsroot/tinyos/tinyos-2.x/doc/txt
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv15403

Modified Files:
	tep119.txt 
Log Message:
fix the description of the implementation

Index: tep119.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/txt/tep119.txt,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** tep119.txt	6 May 2008 22:21:03 -0000	1.11
--- tep119.txt	6 May 2008 22:58:30 -0000	1.12
***************
*** 252,268 ****
  neighbor. In this TEP, we briefly describe the reference
  implementation in ''tinyos-2.x/tos/lib/4bitle'' and refer the readers
! to [3]_ for detailed description of the estimator.
  
  Link estimation is decoupled from the establishment of routes. There
  is a narrow interface -- LinkEstimator and CompareBit -- between the
! link estimator and the routing engine. The one requirement is that the
! quality returned is standardized. A smaller return value from
! LinkEstimator.getLinkQuality() MUST imply that the link to the
! neighbor is estimated to be of a higher quality than the one that
! results in a larger return value. The range of value SHOULD be
! [0,65535] and the variation in link quality in that range SHOULD be
! linear. Radio provided values such as LQI or RSI, beacon based link
! estimation to compute ETX, or their combination are some possible
! approaches to estimating link qualities. The routing engine instructs
  LinkEstimatorP to insert the neighbor, through which a high quality
  path to the root can be constructed, into the neighbor table by
--- 252,266 ----
  neighbor. In this TEP, we briefly describe the reference
  implementation in ''tinyos-2.x/tos/lib/4bitle'' and refer the readers
! to [3]_ for a detailed description of the estimator.
  
  Link estimation is decoupled from the establishment of routes. There
  is a narrow interface -- LinkEstimator and CompareBit -- between the
! link estimator and the routing engine. A smaller return value from
! LinkEstimator.getLinkQuality() implies that the link to the neighbor
! is estimated to be of a higher quality than the one that results in a
! larger return value. Radio provided values such as LQI or RSI, beacon
! based link estimation to compute ETX, or their combination are some
! possible approaches to estimating link qualities. LinkEstimatorP
! returns (ETX-1)*10 as the link quality. The routing engine instructs
  LinkEstimatorP to insert the neighbor, through which a high quality
  path to the root can be constructed, into the neighbor table by
***************
*** 270,277 ****
  for the newly discovered neighbor.
  
! LinkEstimatorP MAY have its own control messages to compute
! bi-directional link qualities. LinkEstimatorP provides calls (txAck(),
! txNoAck(), and clearDLQ()) to update the link estimates based on
! successful or unsuccessful data transmission to the
  neighbors. LinkEstimatorP uses the LinkPacketMetadata interface to
  determine if the channel was of high quality when a packet is received
--- 268,278 ----
  for the newly discovered neighbor.
  
! LinkEstimatorP does not generate its own control messages to compute
! link qualities. When a user of LinkEstimatorP (CtpRoutingEngineP, for
! example) sends a packet using the Send interface provided by
! LinkEstimatorP, link estimation information is also sent with the
! packet as described in an upcoming TEP [4_]. LinkEstimatorP provides
! calls (txAck(), txNoAck(), and clearDLQ()) to update the link
! estimates based on successful or unsuccessful data transmission to the
  neighbors. LinkEstimatorP uses the LinkPacketMetadata interface to
  determine if the channel was of high quality when a packet is received
***************
*** 329,342 ****
  tree. In traditional networking terminology, this is part of the
  control plane of the network, and is does not directly forward any
! data packets, which is the responsibility of CtpForwardingEngine. 
  The main interface between the two is UnicastNameFreeRouting.
  
! CtpRoutingEngineP uses the LinkEstimator interface to learn
! about the nodes in the neighbor table maintained by LinkEstimatorP and
! the quality of links to and from the neighbors. The routing protocol
! on which collection is implemented MUST be a tree-based routing
! protocol with a single or multiple roots. CtpRoutingEngineP 
! allows a node to be configured as a root or a non-root node
! dynamically. CtpRoutingEngineP maintains multiple candidate next hops::
  
    generic module CtpRoutingEngineP(uint8_t routingTableSize, 
--- 330,343 ----
  tree. In traditional networking terminology, this is part of the
  control plane of the network, and is does not directly forward any
! data packets, which is the responsibility of CtpForwardingEngineP. 
  The main interface between the two is UnicastNameFreeRouting.
  
! CtpRoutingEngineP uses the LinkEstimator interface to learn about the
! nodes in the neighbor table maintained by LinkEstimatorP and the
! quality of links to and from the neighbors. The routing protocol on
! which collection is implemented computes a routing tree with a single
! or multiple roots. CtpRoutingEngineP allows a node to be configured as
! a root or a non-root node dynamically. CtpRoutingEngineP maintains
! multiple candidate next hops::
  
    generic module CtpRoutingEngineP(uint8_t routingTableSize, 
***************
*** 496,497 ****
--- 497,500 ----
  
  .. [3] 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
+ 
+ .. [4] TEP 124: The Link Estimation Exchange Protocol (LEEP)