Ian,
I'm not sure what you mean by choosing one architecture?
geoff
On Mon, 2007-12-10 at 23:04 +0530, Ian Chakeres wrote:
> 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
