Jonathan Hui wrote:
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.
Should I interpret your first sentence to mean: "It depends on
whether the node sleeps?" If it means more than that, please explain.
I assume that "heavily duty-cycle [the] radio" is an obscure
way of saying "power down the radio". [I like simple,
direct language, evidence to the contrary notwithstanding.]
Do any of the 802.15.4 chips support a "wake on receive"
capability? Does this capability (assuming it exists)
require that the radio be powered on continuously? That is,
does this capability power-down _only_ the processor, but
not the radio? Does this capability really save enough
power to meet the needs of many battery-powered, hopefully
long-lived wireless sensor networks?
If this capability actually exists, then we can talk
about whether it is actually useful.
Please provide an outline of how you think broadcast might
work in networks where most of the nodes sleep (really sleep,
as in powering down the radio and most of the microprocessor)
most of the time. This is an important discussion to start
soon.
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.
Well, I also don't believe that we have yet specified a complete
solution, much less one that works and is useful in common
environments.
Personally, I doubt that we can develop a complete, working,
useful solution without giving more thought to what 802.15.4
capabilities we require or use if they are available. (Wasn't
that the general conclusion of the working group meeting?
Or, is that still an open question?)
[...]
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.
Well, perhaps for a couple of reasons.
First, we have split the functionality necessary to run IPv6 over
802.15.4 networks across a large number of documents. If each of
these documents use or require different sets of 802.15.4
capabilities, it will be difficult to figure out whether we
have actually specified a complete solution for a particular
environment (or perhaps even for any environment).
Second, it depends on what our interoperability objective is.
There are a range of opinions about what "interoperability"
actually means. For some, interoperability means "if you
implement a particular feature, here is how it should be
implemented". The other view of interoperability focuses
on system-level interoperability. Under this view, the
objective is "If a system implements the relevant [broad]
standards, this it is assured to interoperate with all
other systems that implement these standards". A major
problem with the first approach is that it doesn't assure
system-level interoperability. This is particularly true
when lots of fine-grained standards exist (which is the
direction that the 6lowpan working group seems to be headed
at the moment). That is, when a vendor can pick one standard
from column 1, one from column 2, etc. for more than a trivially
small number of columns, the chance of systems from different
vendors will interoperate become very small.
Personally, I prefer system-level (rather than a feature-level)
interoperability. It is possible that we will find that there
are several very different environments that we want to support
(e.g., networks in which nodes sleep versus networks in which
nodes can always receive packets). And, we may find that these
different environments require different solutions. If this
the case, I think that we should specify a small number of
solutions that target specific environments, rather than specify
a large number of component technologies that vendors can
combine in various ways to create solutions (which are likely
to be functionally proprietary, in the sense that they don't
interoperate with other vendors' products).
-tjs
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
