On May 28, 2008, at 9:02 PM, Benjamin A. Rolfe wrote: > Sorry, first post to the list, so forgive if I'm sounding like a > newbie... > How would one get link quality information to the upper layers > other than > via a MAC service? > I can see inserting a shim-layer service to isolate upper layers > form the > different MACs which may be under it, so as to provide a consistent > service > interface. Of course you can only get what the MAC provides, but > the shim > layer and upper layer's can be designed to handle gracefully > different MAC > capabilities (at least consistently). > > I'm asking with a bit of a bias here: I'm currently working on MAC > enhancements for 802.15.4 (in task group "e" in 802.15), including a > proposal for enhanced link assessment information from the MAC. So > of course > I'd suggest not ruling out some better link metrics in the 802.15.4 > MAC at > some point, although upper layers still need to deal with existing > 802.15.4 > devices. So the general thinking from upper layer uses is very > interesting. > Thanks >
This is a very good question. It turns out to be very difficult, for two major reasons: separation of concerns and time scale. For the sake of simplicity, let's just consider the simplest link quality metric, the packet reception ratio. By separation of concerns, I mean that the MAC layer has to maintain state to generate link estimates. However, the MAC layer does not know which links are useful to a network layer. That is, it could learn and estimate the best links, but those links could be not very good for routing. For example, they could lead to a disconnected network, or high stretch routes. By time scale, I mean that if the average PRR over ten seconds is 50%, that could be due to bursts of high and bursts of low reception. Let's say that an application sends a packet every one second, the link layer transmits 5 times, and the 50% PRR is due to 5 seconds of 0% and 5 seconds of 100%. During the 5 seconds of 0%, the node will transmit 25 packets, with no successful deliveries. Meanwhile, during the 5 seconds of 100%, it will transmit five packets with 5 deliveries. While the PRR over the 10 second window was 50%, the link layer observed a PRR of 16% (5/30). Most radio chips (e.g., CC2420 and RF230) provide LQI as chip correlation values over some number of packet octets. These physical layer measurements effectively add significant bits to the SNR in the sharp part of the BER curve, and are amazingly useful. However, because they are only taken on successful packets, they suffer from measurement bias; in the example above of 50% PRR, a network layer would see all packets having an excellent LQI value, even though packets are lost. This happens in practice, when you have channel variations. Within the TinyOS community, our conclusion is that the MAC layer needs to provide 2 bits of information to the network layer. The first, the "white bit," is a simplification of things like LQI or SNR and essentially indicates whether a received packet had a very low BER, indicating it is probably -- but not certainly -- a good link. The second, the "ack bit" is signaled on each link layer transmission and indicates whether the transmitter received a layer 2 ack. A paper in HotNets last year quantified the benefits each of the bits provides.[1] Phil [1] http://enl.usc.edu/papers/abstract/Fonseca07.html _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
