Re: [core] sleepy to sleepy communication I-Ds

[Bruce Nordman <[e-mail]>]

In some contexts it has been helpful to identify "light sleep" vs. "deep
sleep" when
there are two sub-states with different characteristics.  Beyond two, the
terminology gets trickier.

It is probably already in the various drafts but it is important to
distinguish the link
state from the device power state.  Energy Efficient Ethernet (IEEE
802.3az) created
a sleep state for Ethernet with quick sleep/wake times (as opposed to a
link disconnected
state with very long renegotiation of the link).  On PCs, the link state
and the system
power state are completely independent.  Turning off the radio on a duty
cycle sounds
like a link sleep state that enables faster reestablishment of the link
than from a no-link state.

I have found that it is difficult to impose detailed requirements on the
specifics of
power states across a wide variety of devices, but CORE's clarity on this
for CoAP
low-power devices will be of great help in future.

Thanks,

--Bruce

On Thu, Mar 1, 2012 at 1:02 PM, Salvatore Loreto <
[e-mail]> wrote:

>  Hi Bruce,
>
> thanks a lot for your terminology comment...
> that is for sure something that we will adjust in a next version
> as well as we need text explaining the fact
> that there are differences in how the sensor go to sleep
> or in another way that different sensor go to sleep in a different way
> e.g. just turning off the radio to save the battery can be considered a
> sleep
>
>
> actually we were already discussing, during the writing of the drafts, the
> eventual
> implications of the different way to go to sleep on the design of the
> Options
> but we decided to do it later as well
> hopefully with the help of the community
>
> cheers
> Salvatore
>
> --
> Salvatore Loretowww.sloreto.com
>
>
>
> On 3/1/12 10:36 PM, Bruce Nordman wrote:
>
> Hi all--
>
>   I don't have a comment on the substance of this topic, but just on
> terminology.
> I have worked for many years on saving energy in mains-powered devices, and
> found terminology on power state important to pay attention to.  I have
> not worked
> on low-power sensors, but I think some of the lessons apply.
>
>   I would only suggest that the requirement be changed from "powered off"
> to "powered
> down".  "Down" is ambiguous as to whether it is to sleep or off, but the
> following
> sentence makes clear that the device is asleep since it wakes up.  A
> device that
> is off needs to be turned on - a sleeping device can be wake itself up (on
> timer or
> local activity), or possibly be woken from the network (not all devices
> will support this).
>
>   The distinction is that we would expect a wider range of events to
> trigger a wake
> than to trigger a turn-on, and a shorter latency on coming back from sleep
> than
> from turning on.
>
>   Not all devices have all three states (on, sleep, off) - many have just
> on and sleep
> and many others just on and off.  Some devices are always on.
> (Disconnection from
> all power sources, including internal batteries, will turn a device off so
> all devices have
> this sort of off mode)
>
>   Thanks,
>
> --Bruce
>
>
> ---------- Forwarded message ----------
> From: Thomas Fossati <[e-mail]>
> To: core WG <[e-mail]>
> Cc:
> Date: Wed, 29 Feb 2012 22:46:58 +0100
> Subject: [core] sleepy to sleepy communication I-Ds
> Hello all,
>
> today we have submitted a couple of I-Ds proposing three new CoAP Options
> that try dealing with the requirement REQ3 of draft-shelby-core-coap-req-04
>
>    The ability to deal with sleeping nodes.  Devices may be
>    powered off at any point in time but periodically "wake up"
>    for brief periods of time.
>
> leveraging on different techniques, i.e. store-and-forward, explicit
> origin delegation, REST interface to carbon-copy an observed resource.
>
>
> Their URIs and respective abstracts are given in the following for
> convenience:
>
> (1) "Sleepy Option for CoAP" (see
> http://tools.ietf.org/html/draft-giacomin-core-sleepy-option-00)
>
> This draft defines a new CoAP elective option, Sleepy, targeted
> specifically at proxies and used to signal a proxy the will to initiate an
> asynchronous request/response exchange.  The Sleepy option is partitioned
> in 2/3 subfields indicating: the remaining time before sleep, the expected
> sleep interval, and (optionally) the on-duty interval.
> .....
>
>
> --
> *Bruce Nordman*
> Lawrence Berkeley National Laboratory
> eetd.lbl.gov/ea/nordman
> [e-mail]
> 510-486-7089
> m: 510-501-7943
>
>
>
>


-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[e-mail]
510-486-7089
m: 510-501-7943