[net2-wg] link estimator interface

[Philip Levis]

On Sun, 2006-03-05 at 15:22 -0800, Omprakash Gnawali wrote:
> I was looking at the Moteiv SP interfaces, and I wanted to discuss the
> notion of link quality provided by these interfaces:
> 
> getQuality 
> command uint16_t getQuality(sp_neighbor_t *n, TOS_Msg *msg) 
> 
> The documentation says that this call is supposed to return ETX. That
> is one way to standardize the return value so that any routing
> protocol can use this information without having to adapt to different
> link quality estimators.

The inline comment is a little different:


  /**
   * Update the link quality for a specific neighbor based on the
   * packet passed into this function
   */
  command uint16_t getQuality(sp_neighbor_t* n, TOS_Msg* msg);

The documentation makes a lot more sense.

> What if someone just wants to use LQI based estimator. In that case,
> not only is the metric asymmetric, but it would be impossible to
> provide the above command because many people seem to have come up
> with very different correlation between ETX/reliability and LQI
> depending on the environment. Even in a single environment, I am not
> sure if there is a strong correlation between these variables.

For the CC2420, there is some correlation, but it is not that strong.
Two neighbors with the same LQI might have very different ETX values.
For example, I've seen an LQI of 80 correspond both to an 80% PRR (ETX
of 1.25) and 20% PRR (ETX of 5). It looks like the implementation is
doing this:

uint16_t correlation(uint8_t v) {
  uint16_t c = (80 - (v - 40));
  c = (((c * c) >> 3) * c) >> 3;
  return c;
}

where v is the LQI. Given than an LQI of 100 (very good) will return
125, which is far from the ETX (~1.05-1.1).

> What do people think about abstracting the notion of link quality and
> saying here is the range of values and the values in between describe
> link quality in linear proportion of the range? For example,
> 1/2(max+min) would describe link quality roughly in between the
> maximum and minimum quality.

On one hand, this is a good idea, in that it means that the underlying
stack does not have to try to calculate ETX (which can be difficult). On
the other, it means that different stacks might calculate the value
based on different metrics. This could easily lead to a protocol
assuming a specific link quality (e.g., "I know that if it's >45 then I
see this on this radio, so I put an if statement in there") and so not
being portable.

> Without standardizing the return value, I do not see how different
> routing protocols can work with a variety of link estimators. The
> drawback is this will make it harder for protocols that rely on a
> specific implementation of an estimator - protocols that configure the
> number of retransmission based on ETX, for example.

The purpose is to break protocols from relying on a specific
implementation. That way they can actually work on different data link
layers without modification, just as my UNIX app can use 802.11 or 802.3
without knowing the difference.

Phil