Hi Tim, see comments below:
Timothy J. Salo wrote:
Should I interpret your first sentence to mean: "It depends on
whether the node sleeps?" If it means more than that, please explain.
No, you should interpret it as: "with what schedule does the radio
enable or disable its receiver".
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.]
Duty-cycle is a generally accepted term to refer to the proportion of
time a device is on or off: http://en.wikipedia.org/wiki/Duty_cycle
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?
Low power listening and time-synchronization are two generally accepted
mechanisms for duty-cycling a radio. Both mechanisms have been shown to
significantly reduce average power consumption (fractions of a percent)
in a variety of applications.
If this capability actually exists, then we can talk
about whether it is actually useful.
The capability does exist and is being deployed today.
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.
Use low power listening, schedule broadcast slots in a synchronized
protocol, buffer packets at a router. There's a bunch of literature on
this already.
[...]
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).
And we do this by first outlining the small number of configurations.
This is what the architecture ID is trying to do. It outlines a number
of scenarios and states that different mechanisms may be required
depending on the operational scenario you're assuming. Sure, the
architecture ID still needs work, but its a starting point. I believe we
are in agreement here?
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
