[net2-wg] packet interfaces

[Omprakash Gnawali]

How do we expect this bit to be used? It will be good to generate a
few examples.

If we expect a neighbor table module or some other user of this bit to
interpret this bit to do something differently with the packet or
infer something about the link, will the interpretation be valid when
you move from one platform to the next? The key to getting this to
work might be finding the equivalent thresholds or filters across the
platforms.

It also seems that we are mostly talking about scenario with signal
attenuation and randomish environmental noise. Does the meaning of the
bit change in an environment with interference from radios working in
the same frequency band - 802.11 + CC2420, etc?

- om_p

> This week, in the core telecon, there was a long discussion on the  
> packet metadata interfaces. In particular, whether or not it would be  
> a good idea to have the packet HIL (chip-independent) interface  
> provide information such as the packet SNR, BER, or RSSI. After a bit  
> of discussion, core agreed that this might be something better for  
> net2 to tackle, in that we have a better sense of what the  
> requirements would be. On one hand, we want to avoid the trap that  
> 15.4 fell into, of specifying LQI so vaguely that it's difficult to  
> use effectively yet also specifying it so abstractly that it's hard  
> to implement. On the other, the effectiveness of protocols such as  
> MultihopLqi show how some physical layer information can really be a  
> big help in populating neighbor tables and estimating link quality.
> 
> Here's a strawman proposal. Either as part of an existing interface,  
> or as part of a new interface, we introduce a new command which  
> returns a boolean. This boolean indicates whether physical layer  
> characteristics suggest that the link may be in the grey region. In  
> the case of the CC2420, for example, you can do this by applying a  
> threshold to the LQI value; as one might expect from a random  
> process, high LQI values have low variance but middling ones have  
> high variance. So a good link will consistently report itself as  
> good, while a grey link might occasionally report as good but will  
> usually report as grey. In the case of the mica, or other physical  
> layers that use software encoding decoding, a threshold to recovered  
> bit errors can be used. In the case of the mica2, it can look at the  
> RSSI of the packet and compare it to the noise floor (if the SNR is  
> above a threshold, report good). In the case of a link layer that  
> cannot provide physical layer information, I'm not sure whether it  
> should always report good or report grey.
> 
> In some ways, this is in the vein of some of the proposals in SP,  
> where a single bit of information was provided for certain  
> properties. But it's on a per-packet, not per-node basis, and it's  
> one of the values that SP chose to dedicate multiple bits to. The HAL  
> (chip-specific) can always provide more information (e.g., the CC2420  
> can provide the LQI), but this is a hardware-independent indicator.
> 
> Thoughts?
> 
> Phil
> _______________________________________________
> net2-wg mailing list
> net2-wg at millennium.berkeley.edu
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/net2-wg