Hi, I appreciate your help. And I still have some difficulty understanding the inage field, please see my comment in line.
On Wed, Jun 3, 2009 at 5:19 AM, Rémi Villé <[email protected]> wrote: > I have a few questions regarding link estimation of tinyos 2.x: > > > I'm working on it too since a few month, so I can help you, but don't > hesitate to correct me. > >> >> 1 Are they identical, the link estimator under $TOSDIR/lib/net/4bitle and >> the one under $TOSDIR/lib/net/le? If yes, why bother keeping both? If no, >> what is the difference between these two? > > > net/le is the simplest estimator, 4bitle add the concept describe in this > paper : http://sing.stanford.edu/pubs/sing-07-00.pdf, it uses 4 bits too > have a metric which efficiently mix the qualities of the physical, link and > network layers, it uses the CompareBit component with the event > shouldInsert(...). > For now I have only used and modified net/le. > >> >> 2 What is the inage field in each entry of neighbor table? Why is it >> initialized to MAX_AGE, rather than 0? > > > I didn't look closely to this parameter but it allow to estimate the > number of round (a round correspond to have received BLQ_PKT_WINDOW beacon > packets) we haven't be able to update the in-bound quality link of a > neighbor (we haven't received beacon from this neighbor). > It's initialized to MAX_AGE and decremented to 0 every BLQ_PKT_WINDOW > beacon packets received. > When you look in the updateNeighborTableEst(...) function we can see that > if ((ne->inage == 0) && (ne->outage == 0)) then ne is set to be a invalid > entry (like if the neihbor was evicted). > I'm still not quite sure why we need this inage field. It is set to MAX_AGE every time a beacon is received (in function updateNeighborEntryIdx()) and decreased by 1 every round. > >> 3 Why is linkest_footer_t defined this way? Does it imply only one >> neighbor entry can be accommodated in the footer? >> typedef nx_struct linkest_footer { >> neighbor_stat_entry_t neighborList[1]; >> } linkest_footer_t; >> > > I'm not yet comfortable with nesC concepts but neighborList[1] doesn't > meens that theres only one neighbor entry in the footer, on the contrary if > you look in the sources or the LEEP frame describes in the Link Estimator > Exchange Protocol TEP, there's as many entry in this list that there are > neihgbors in the neihbor table. > This information is broadcast and the neighbors can update their out-bound > quality link. > > Note that in 4bitle the out-bound quality link is not used for a reason I > don't know, but the LEEP frame stay identical as the net/le estimator to > respect the protocol. > -Xiaohui
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
