While investigating some issues with the tos/lib/net/le link estimator (turned out the last release didn't have this bug fix: http://tinyos.cvs.sourceforge.net/tinyos/tinyos-2.x/tos/lib/net/le/LinkE stimatorP.nc?view=diff&r1=1.7&r2=1.8), we've observed something interesting about the initial values of route quality and ETX. If my understanding is correct, a new/unknown link gets a zero EETX (perfect link) but also zero in and out qualities (terrible link). This means the ETX will move wildly with the first couple of packets received, and it can take a long time for especially the out quality to reach a value that is representative of the actual quality of the link.
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.
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 (packetGap > MAX_PKT_GAP) {
NeighborTable[idx].failcnt = 0;
NeighborTable[idx].rcvcnt = 1;
NeighborTable[idx].outage = 0;
NeighborTable[idx].outquality =
INITIAL_QUALITY_ESTIMATE;
NeighborTable[idx].inquality =
INITIAL_QUALITY_ESTIMATE;
NeighborTable[idx].eetx = INITIAL_EETX_ESTIMATE;
}
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.
Kind regards,
Michiel
Michiel Konstapel
Software Engineer
T: +31 (0)15 26 00 44 6
F: +31 (0)15 26 00 40 5
W: www.sownet.nl
<<image001.jpg>>
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
