[Tinyos-devel] [Tinyos-help] LinkEstimator, link qualities, ETX

[Omprakash Gnawali]

On Thu, Aug 28, 2008 at 1:06 AM, Michiel Konstapel
<m.konstapel at sownet.nl> wrote:
...
>
> Our thinking was that instead of initializing the qualities and ETX to zero,
> wouldn't it be better to set them "halfway"? That way, it is encoded that
> the quality of the link is unknown, and could go either way. An initial
> quality value of 180 (out of 255) means that 1/(inq*outq) results in an ETX
> of 2; a 50% link.

Perhaps values other than 0 are better as initial values. Lets
consider these CTP/LEEP mechanisms:

1. eetx for a link is not available until a link is mature
2. you transmit a lot of beacons in the beginning so there are enough
beacons to bootstrap the values (are you using the router that uses
Trickle timer to drive the beacons?)
3. you will eventually use the link that provides the best delivery performance

So we are talking about initial setup time beyond link maturity? How much time?

> Another observation of ours was that after a large number of beacons (>
> MAX_PACKET_GAP) is missed, the route qualities are reset, but the ETX isn't.
> In cases where a node that is a popular parent (say, the sink) is turned off
> for a while, its children will see its ETX skyrocket as they try to get
> packets through. When the node comes back online and starts sending beacons,
> its old children will reset the link qualities to zero, but leave the ETX at
> its inflated value. This means that it will take a very long time for the
> node to send enough beacons to make itself look like a viable parent again.
> Wouldn't it be better to reset the ETX at the same time as the in and out
> qualities? Something like this:

If you turn the node back on, you are right. But there are some other
scenarios where what you propose might make things worse - lets say
the link quality degrades and you slam the eetx value to the ceiling.
Now, suddenly after more than MAX_PACKET_GAP (lets say after an hour),
you receive a beacon, and BLQ_PKT_WINDOW consecutive beacons
immediately after that. Is this link good or bad? If the last known
etx for this link is a high value, why change it to some arbitrary
value?

One other detail - if you change inquality, you are changing the
contribution to etx through the beacons. It is entirely possible that
we are getting good etx estimate through the data packets while we are
getting bad etx estimate through the beacons due to potentially
different timescales at which the channel is sampled through these
mechanisms. updateNeighborEntryIdx is only concerned with updating the
beacon based estimate so it would not be appropriate to change eetx
here because eetx also takes into account data pkt transmission
statistics.

> We've done some desktop experiments with INITIAL_QUALITY_ESTIMATE = 180 and
> INITIAL_EETX_ESTIMATE = 10 and the recovery time improved greatly. However,
> we don't have results for larger networks and were wondering if there might
> be issues we haven't foreseen.

I am not entirely convinced that we should optimize this link
estimator to a scenario in which a link with a good track record
suddenly becomes unavailable for a while and suddenly it becomes
available with excellent delivery performance if that optimization is
done at the expense of poorer response to other types of failure
scenarios. Does your suggestion make recovery/adaptation worse for
other types of failure scenarios?

Overall, initialization value of these parameters become more
important if you are using the link estimator without CTP.

It would be good to see some numbers across the failure scenarios that
you considered in your experiments.

Thanks.

- om_p