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

[Salvatore Loreto <[e-mail]>]

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:
> 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] <mailto:[e-mail]>>
> To: core WG <[e-mail] <mailto:[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 <http://eetd.lbl.gov/ea/nordman>
> [e-mail]
> 510-486-7089
> m: 510-501-7943
>