Hi Omprakash,
About the inage field,
In the code below, first there is the check for the neighbor table entry to
update. Inage field is only decremented for the neighbor that sent beacon
msg !
// update the inbound link quality by
// munging receive, fail count since last update
void updateNeighborTableEst(am_addr_t n) {
uint8_t i, totalPkt;
neighbor_table_entry_t *ne;
uint8_t newEst;
uint8_t minPkt;
minPkt = BLQ_PKT_WINDOW;
dbg("LI", "%s\n", __FUNCTION__);
for (i = 0; i < NEIGHBOR_TABLE_SIZE; i++) {
ne = &NeighborTable[i];
if (ne->ll_addr == n) {
if (ne->flags & VALID_ENTRY) {
if (ne->inage > 0)
ne->inage--;
But i think inage field should be decremented when the following condition
holds, isn't it?
if (ne->ll_addr != n)
Otherwise setting the inage field of the neighbor who sent the beacon to
MAX_AGE
(in function updateNeighborEntryIdx())
and then decrementing it
(in function updateNeighborTableEst())
doesn't make sense, right?
Am i missing something?
On Tue, Jun 16, 2009 at 11:54 PM, Omprakash Gnawali <[email protected]> wrote:
> On Thu, Jun 4, 2009 at 2:03 AM, Rémi Villé<[email protected]> wrote:
> >>>> 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.
> >
> > The calculation of a bidirectional quality link is like 1/Qi * 1/Qo,
> where
> > Qi is the ratio msg_received/total_msg_send from a neighbor to the
> current
> > mote and Qo this ratio from the current mote to the neighbor.
> > I think inage and outage are used to know when the connection whith a
> > neighbor is lost, i.e. when we have received BLQ_PKT_WINDOW * MAX_AGE
> beacon
> > packets without having any information about in-bound quality and
> out-bound
> > quality from a neighbor.
> > In-bound quality is compute with the sequence number in the LEEP frame
> sent
> > by a neighbor (when there's a gap between two seq number we can deduce
> how
> > many packets have been lost). Out-bound quality is compute thanks to the
> > in-bound quality from the current mote to a neighbor, this information is
> > sent in the LEEP footer frame from this neighbor to the mote, if the
> > neighbor have keep the mote in its neighbor table.
> > So we can have in-bound quality information from a neighbour without
> having
> > out-bound one (if the neighbor haven't keep the mote in its neighbor
> table),
> > but I do not think we can have out-bound quality information from a
> > neighbour without having in-bound (because we must receive a packet to
> have
> > the out-bound quality, and this packet allows to compute in-bound quality
> > thanks to the seq number), so maybe inage is useless.
>
> inage is used to keep track of freshness of the link entry. If it gets
> too stale, we invalidate the entry.
>
> - om_p
>
> _______________________________________________
> Tinyos-help mailing list
> [email protected]
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
--
Mehmet Akif Antepli
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
