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 > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan
