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

From: Bruce Nordman <[email-masked]>
Date: Thu, 1 Mar 2012 12:36:51 -0800

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 <[email-masked]>
To: core WG <[email-masked]>
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
[email-masked]
510-486-7089
m: 510-501-7943

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 1 Mar 2012 23:02:59 +0200

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 Loreto
www.sloreto.com

On 3/1/12 10:36 PM, Bruce Nordman wrote:
> found terminology on power state important to pay attention to.  I 
> have not worked
>   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).
>
> 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
> all power sources, including internal batteries, will turn a device 
> off so all devices have
> this sort of off mode)
>
>   Thanks,
>
> --Bruce
>
>
> From: Thomas Fossati <[email-masked] <mailto:[email-masked]>>
> To: core WG <[email-masked] <mailto:[email-masked]>>
> Cc:
> 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
>
> leveraging on different techniques, i.e. store-and-forward, explicit 
> origin delegation, REST interface to carbon-copy an observed resource.
>
>
> 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*
> eetd.lbl.gov/ea/nordman <http://eetd.lbl.gov/ea/nordman>
> [email-masked]
> 510-486-7089
> m: 510-501-7943
>

---

From: Bruce Nordman <[email-masked]>
Date: Thu, 1 Mar 2012 13:56:16 -0800

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 <
[email-masked]> wrote:

> actually we were already discussing, during the writing of the drafts, the
> eventual
> Salvatore Loretowww.sloreto.com
>
>
>
> found terminology on power state important to pay attention to.  I have
> not worked

---

From: Jari Arkko <[email-masked]>
Date: Mon, 05 Mar 2012 03:04:19 +0200

Good points, Bruce.

I will add that for many applications and platforms, the ability to communicate is the primary issue and waking up the CPU is secondary. In addition, on many link layers the ability to communicate depends on the network as well as the device, as it is the network that does the final synchronization, granting of time slots, etc. These may not matter on a coarse time scale (I'll wake up to listen for messages from 00h00min0s to 00h00min5s, but it may matter for smaller time scales (it definitely does for a millisecond).

Jari

On 01.03.2012 23:56, Bruce Nordman wrote:
> 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