On Mon, Aug 11, 2008 at 5:10 PM, Tao Liu <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I am studying the 4bitle link estimator in the TinyOS 2. In the
> tos/lib/net/4bitle/LinkEstimatorP.nc (line 647), the 4bit estimator
> signals the CompareBit.shouldInsert() event when it received a beacon
> message from a new neighbor when there is no room left in the neighbor
> table, and the only implementation of CompareBit.shouldInsert I can
> find is in the tos/lib/net/ctp/CtpRoutingEngineP.nc, starting from
> line 634:
>
> /* This should see if the node should be inserted in the table.
> * If the white_bit is set, this means the LL believes this is a good
> * first hop link.
> * The link will be recommended for insertion if it is better* than some
> * link in the routing table that is not our parent.
> * We are comparing the path quality up to the node, and ignoring the link
> * quality from us to the node. This is because of a couple of things:
> * 1. because of the white bit, we assume that the 1-hop to the candidate
> * link is good (say, etx=1)
> * 2. we are being optimistic to the nodes in the table, by ignoring the
> * 1-hop quality to them (which means we are assuming it's 1 as well)
> * This actually sets the bar a little higher for replacement
> * 3. this is faster
> * 4. it doesn't require the link estimator to have stabilized on a link
> */
> event bool CompareBit.shouldInsert(message_t *msg, void* payload,
> uint8_t len, bool white_bit) {
> bool found = FALSE;
> uint16_t pathEtx;
> //uint16_t linkEtx = evaluateEtx(0);
> uint16_t neighEtx;
> int i;
> routing_table_entry* entry;
> ctp_routing_header_t* rcvBeacon;
>
> if ((call AMPacket.type(msg) != AM_CTP_ROUTING) ||
> (len != sizeof(ctp_routing_header_t)))
> return FALSE;
>
> /* 1.determine this packet's path quality */
> rcvBeacon = (ctp_routing_header_t*)payload;
>
> if (rcvBeacon->parent == INVALID_ADDR)
> return FALSE;
> /* the node is a root, recommend insertion! */
> if (rcvBeacon->etx == 0) {
> return TRUE;
> }
>
> pathEtx = rcvBeacon->etx; // + linkEtx;
>
> /* 2. see if we find some neighbor that is worse */
> for (i = 0; i < routingTableActive && !found; i++) {
> entry = &routingTable[i];
> //ignore parent, since we can't replace it
> if (entry->neighbor == routeInfo.parent)
> continue;
> neighEtx = entry->info.etx;
> //neighEtx = evaluateEtx(call
> LinkEstimator.getLinkQuality(entry->neighbor));
> found |= (pathEtx < neighEtx);
> }
> return found;
> }
>
> According to the comment, this event should do the comparison based on
> the white_bit argument. However, the actual code here does not take
> the white_bit into account. Instead, it just compare the path ETX
> value of the new beacon message with the neighbors that is already in
> the routing table (different from the neighbor table in the link
> estimator).
>
> When the 4bit link estimator signals the CompareBit.shouldInsert
> event, the white_bit is set to true if the LQI value in the message
> header indicates the wireless channel quality is high; false
> otherwise. Can somebody explain why the white_bit is ignored here? Or
> it's just I missed something?
>
You did not miss anything :)
We found this problem about two weeks ago but it was too close to the
2.1 release and did not update the code. The comparison statement
disappeared when we did code refactoring as we moved from experiments
to code in the repository.
I am redoing some of the experiments before I update the code so stay tuned.
- om_p
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
