I tend to agree with Tim that sleeping can potentially be a big issue for both 6lowpan and more general routing in sensor networks. I do not think it should be dismissed.
I also think that if 6lowpan does not choose one architectures (e.g. host-host, router-host, or router-router), it will be difficult to specify some of the optimizations. For example, ND optimization. Ian On Dec 8, 2007 3:37 AM, Geoff Mulligan <[EMAIL PROTECTED]> wrote: > Tim, > I think that you have some misunderstandings. > > On Thu, 2007-12-06 at 16:10 -0600, Timothy J. Salo wrote: > > Samita Chakrabarti wrote: > > > ... That way, periodic RA will not wake up > > > all the nodes in the 6lowpan. ... > > > > To the best of my knowledge, 802.15.4 implementations power-down > > the radio when the system sleeps. As such, a broadcast packet > > does not wake a sleeping 802.15.4 node. Rather, the packet > > is simply never received by the sleeping node. > > > This is not true. A node that sleeps can receive broadcast packets. > > - If the broadcast packet is transmitted on some schedule then the > sleeping node can wake up on that schedule and receive the packet. > - If the broadcast packet is transmitted with some sort of long > preamble then the sleeping node can wake up on it's own schedule, over > hear the preamble and stay awake to receive the packet. > - If the broadcast packet is transmitted multiple times the sleeping > node can wake up during one of these transmissions and receive the > packet. > > This is much like receiving any packet, not just broadcast packets. > > > If my understanding about this behavior is incorrect, someone > > please correct me. I have been meaning to check and see what > > the spec says about this, but haven't yet... > > There is nothing in the spec on this. As far as I know, there are no > 15.4 radios that wake on some sort of reception. > > > > > Given that the response to broadcast packets differs in 802.16 > > networks (where an idle node wakes to process the packet) and > > 802.15.4 networks (where a sleeping node is never even aware > > of the packet), different solutions are probably required. > > > > To reiterate what I have said before, I believe that we must > > explicitly specify the behavior we expect of multicast in > > 6lowpan networks that contain sleeping nodes. > > No we don't. > > > In particular, > > does multicast mean "received by the potentially very small > > percentage of the nodes that aren't currently sleeping" or might > > it mean "received by every node after they wake up [whenever > > day that might be]"? > > After we specify the behavior of multicast, > > then we can then try to figure out whether we can actually > > implement that behavior in a useful way. > > > > In the interim, I suggest a moratorium on simply assuming that > > multicast is a potential solution to any of the challenges > > we face (e.g., duplicate address detection, router announcements, > > neighbor discovery, ...) > > NO. > > > > > > -tjs > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/6lowpan > > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
