Hi Tim, comments in line.
Timothy J. Salo wrote:
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.
Depends on the link-layer energy management protocol. It is possible to heavily duty-cycle radio while supporting a broadcast communication.
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...
This gets back to the question raised in the WG meeting, regarding how much of the MAC we should assume. The 802.15.4 specification only defines a limited set of power management mechanisms. As a result, many commercial implementations and industrial standards built on 802.15.4 forego the defined power management mechanisms. We've been careful so far to rely only on the frame format and nothing else.
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. 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, ...)
Why not simply let the particular protocol specification state its assumptions about the underlying link? The challenge is that 6lowpan links may be configured very differently and solutions may differ greatly depending on the operational framework. I'd rather not limit the WG to a specific one.
-- Jonathan Hui
-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
