Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements

From: "Ian Chakeres" <[email-masked]>
Date: Fri, 2 Mar 2007 08:15:27 -0800

Two quick comments inline.

On 3/2/07, 김용운 <[email-masked]> wrote:
> >I don't think LQI by itself should be used. LQI must be matched with
> >other indicators to make good decisions.
>
> I agree. But, in my opinion,
> LQI is likely to be the primary key.
> The reason is saving TCO.

LQI is good for making single hop decisions, but much more complicated
when we talk about  multiple hops (routing).

<snip>

> >Regarding the requirements section:
> >
> >I think that R2 is a bad requirement. I would instead say that routing
> >should be efficient. Efficiency can be defined in many ways. There
> >might be 6lowpan networks where all devices are power so power usage
> >is not important. Alternatively there might be nodes that choose not
> >to participate even though they have energy. I think that requiring
> >minimal energy routing is too harsh and unrealistic.
>
> In my opinion,
> most 6lowpan devices are powered by battery and
> The battery power must be the weakest point in business.
>
> As time goes after wireless devices have been installed,
> management cost, for examples, battery cost, labor cost for
> battery change, maintenance cost, remote monitoring and management
> cost, etc. will overwhelm installation cost.
>
> Minimal energy usage is worth adopting for requirement to
> save battery cost and relevant labor cost, I think.
>
> "harsh and unrealistic" is a good expression
> but solving it must be a technical target.

I guess my comment has more to do with how we solve the problem.  I
think that a routing protocol that can handle sleeping nodes (and
adapt quickly) and also one that can be influenced by nodes
willingness (maybe remaining battery) is sufficient. Therefore, I'm
not sure we need an energy aware routing protocol.
_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: Philip Levis <[email-masked]>
Date: Fri, 9 Mar 2007 09:15:18 -0800

> when we talk about  multiple hops (routing).

I'd caution against just assuming that LQI will solve all single-hop  
problems.

First, LQI is not clearly defined. Radios such as the CC2420 give  
multiple hardware indicators of link quality. The "LQI" field that  
the CC2420 provides, for example, is not an 802.15.4 LQI value; the  
data sheet recommends that you use other values and factors to  
determine link quality. I have yet to hear of a good (produces stable  
and accurate values) algorithm to compute an 802.15.4 LQI purely from  
hardware indicators.

For example, if you look at what current sensor net stacks do, they  
essentially scale the LQI such that only very high SNR links are used  
(think >10dBm above threshold), leading to routes that are stable but  
are far from the shortest path.

Additionally, if you have analog interference sources, then you must  
compute LQI bidirectionally. Otherwise, you may be able to receive  
packets from a node but it cannot receive packets from you. This is  
also a reason why protocols such as AODV run into big problems in  
practice, unless you constrain communication to be over a  
bidirectional mesh that you've established underneath IP. But that's  
the hard part and the actual protocol problem to solve: once you have  
it, AODV and its ilk are fairly trivial.

Finally, applying LQI to routing decisions is difficult, given its  
fairly vague specification in 802.15.4. One can imagine computing  
minimum cost paths using LQI, but it would be good to see what those  
calculations are like in practice, and how different 802.15.4 stacks,  
with their different LQI calculations, lead to different routing  
performance based on the upper layers assumptions on its meaning.

All together, what this means is that mesh routing is almost  
certainly needs to have network-level information in terms of link  
quality, which it can use to make network-level routing decisions. It  
can use LQI as part of these decisions, but it is important to leave  
the flexibility to incorporate other information as well.

Phil