We are diverging from the original issue of the route-over/mesh-under debate raised by Mark for the new 6lowpan charter. However, I do feel that increasing cross-layer cooperation while maintaining the layering is an interesting and important question and the discussion should continue in a separate thread.
The route-over/mesh-under issue covers more than just routing - it defines how we abstract the IP link and covers issues of fragment delivery, multicast emulation, neighbor discovery, autoconf, etc. While mesh-under is an acceptable approach for extending IP connectivity to 6lowpan devices, the real issue is that "IEEE 802.15.4" is a very loaded term today. There are many link-layers that could be well-suited for 6lowpan (both existing and in development) that utilize 802.15.4 radios, but not the 802.15.4 multihop meshing itself. The real problem with IEEE 802.15.4 is that it fails to define a true low-power solution for a multihop mesh, which is explicitly stated in IEEE 802.15.4-2006. Work is under way in IEEE 802.15.4e to address this issue, but it is still in the formative stages. Given where we are today, it is most desirable for us to develop solutions that do not assume specific functionality specified in IEEE 802.15.4-2006 for creating a multihop mesh (e.g. beacons, coordinators, etc.). It would be a shame if, for each specific 802.15.4 multihop mesh technology, we or others have to come up with a variety of different solutions (routing being only one piece of that) to successfully create an IP link. W.r.t. the routing requirements draft, I think we would be much better off by developing a "requirements document for 6lowpan mesh-under subnetwork designs", something that others could use when developing their own L2 mesh-layer on 802.15.4 radios. This is something the 6LoWPAN Architecture draft could include or could be broken out into a separate document. -- Jonathan Hui On May 28, 2008, at 10:49 PM, Philip Levis wrote: > > 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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
