Subject: [core] Sleepy devices in CoAP - Requirements

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 12 Jun 2013 05:59:26 +0000

Dear all,

as input to last year's discussion on 'sleepy devices' in CoAP I have uploaded an I-D that aims to capture the requirements for sleepy devices.
As discussed in the IETF 83 CoRE meeting, we can create a solution once the requirements are sufficiently clear. The I-D is:
http://tools.ietf.org/html/draft-dijk-core-sleepy-reqs-00

Also I've uploaded a second I-D to provide possible solutions to meet these requirements, based on an architecture that uses a specific type of intermediary to interface to the sleepy devices:
http://tools.ietf.org/html/draft-dijk-core-sleepy-solutions-01

regards,
Esko

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Rick Bullotta <[email-masked]>
Date: Wed, 12 Jun 2013 14:01:49 +0000

Hi, Esko.

Where would a device that is "somewhat sleepy" (e.g.  a cellular or satellite gateway with support for SMS, RF or other "shoulder tap") fall in this scenario?  In some aspects, it is a SEP (from the standpoint of the primary radio and communications) but it is also a NSEP from the perspective of listening on an SMS or other low power/low bandwidth channel for external "wake up".

Rick
ThingWorx

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dijk, Esko
Sent: Wednesday, June 12, 2013 1:59 AM
To: core ([email-masked])
Subject: [core] Sleepy devices in CoAP - Requirements

Dear all,

regards,
Esko

---

From: "Dijk, Esko" <[email-masked]>
Date: Wed, 12 Jun 2013 16:14:30 +0000

Hello Rick,

I think that if a device sleeps part of the time and can be woken by external triggers that are not sent over the communication interface over which CoAP runs (e.g. wake by sensor input, SMS received, FM radio data broadcast, button push, etc.) we should consider it a SEP.

However, in case a CoAP client could always send e.g. an SMS first to wake the SEP before initiating a CoAP request, the requirements would change a bit.
E.g. the R3.1 "Read via Proxy" and R4.1 "Write via Proxy" may not be needed anymore since the reading/writing can always be done by first waking the SEP and then doing the CoAP request.

Esko

From: Rick Bullotta [mailto:[email-masked]]
Sent: Wednesday, June 12, 2013 16:02
To: Dijk, Esko; core ([email-masked])
Subject: RE: Sleepy devices in CoAP - Requirements

Hi, Esko.

Rick
ThingWorx

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Dijk, Esko
Sent: Wednesday, June 12, 2013 1:59 AM
To: core ([email-masked]<mailto:[email-masked]>)
Subject: [core] Sleepy devices in CoAP - Requirements

Dear all,

regards,
Esko

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sun, 16 Jun 2013 23:13:19 -0400

Dear Esko,

Thanks for the excellent input to the Sleepy Devices space.  I have the
following initial feedback on your I-Ds:

*         draft-dijk-core-sleepy-reqs-00

o   The I-D seems to have a majority of requirements that can very
realistically be addressed at the COAP application level (which is very
good).  But also it has some other requirements that most likely would
need to be addressed at some lower level than CoAP (e.g. section 4.3,
item 6 - Client location).  Is my observation accurate, and if so should
this duality be clearly indicated in the I-D?

o   Do you think that it would be worthwhile to note that there are two
classes of sleep patterns for sleepy devices (SEPs)?  Namely, some SEPs
may have predictable (e.g. scheduled) sleep cycles and others may have
completely unpredictable (e.g. external event driven) sleep schedules.
Maybe you had captured the concept in the text but it did not stand out
for me at least.  At least section 4.7 (item 1- Configurable sleep
interval) seems to imply only support of fully scheduled sleep cycles to
me ...

o   I think we need to support more than just S0 class devices as SEP
(section 1.2).  For example, S1 is probably an important class of
devices to also support as SEPs. 

*         draft-dijk-core-sleepy-solutions-01

o   It would be nice if you included
http://tools.ietf.org/html/draft-rahman-core-sleepy-02 in your survey!

Best Regards,

Akbar

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dijk, Esko
Sent: Wednesday, June 12, 2013 1:59 AM
To: core ([email-masked])
Subject: [core] Sleepy devices in CoAP - Requirements

Dear all,

as input to last year's discussion on 'sleepy devices' in CoAP I have
uploaded an I-D that aims to capture the requirements for sleepy
devices.

As discussed in the IETF 83 CoRE meeting, we can create a solution once
the requirements are sufficiently clear. The I-D is:

Also I've uploaded a second I-D to provide possible solutions to meet
these requirements, based on an architecture that uses a specific type
of intermediary to interface to the sleepy devices:

regards,

Esko

The information contained in this message may be confidential and
legally protected under applicable law. The message is intended solely
for the addressee(s). If you are not the intended recipient, you are
hereby notified that any use, forwarding, dissemination, or reproduction
of this message is strictly prohibited and may be unlawful. If you are
not the intended recipient, please contact the sender by return e-mail
and destroy all copies of the original message.

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 17 Jun 2013 06:41:22 +0000

Hello Akbar,

thanks for the feedback; here my comments:

o   The I-D seems to have a majority of requirements that can very realistically be addressed at the COAP application level (which is very good).  But also it has some other requirements that most likely would need to be addressed at some lower level than CoAP (e.g. section 4.3, item 6 - Client location).  Is my observation accurate, and if so should this duality be clearly indicated in the I-D?
-> Yes, there are requirements that influence on several levels, e.g. CoAP level or below that. I think it's good to clearly indicate this. Some requirements can even be irrelevant for a solution in the CoAP space.

o   Do you think that it would be worthwhile to note that there are two classes of sleep patterns for sleepy devices (SEPs)?  Namely, some SEPs may have predictable (e.g. scheduled) sleep cycles and others may have completely unpredictable (e.g. external event driven) sleep schedules.   Maybe you had captured the concept in the text but it did not stand out for me at least.  At least section 4.7 (item 1- Configurable sleep interval) seems to imply only support of fully scheduled sleep cycles to me ...
-> Yes, that could be explicitly mentioned, agree. Also a mix between event-driven and timer-driven can be expected, for example in the described 'heartbeat' mechanism.

o   I think we need to support more than just S0 class devices as SEP (section 1.2).  For example, S1 is probably an important class of devices to also support as SEPs.
-> I was assuming S1 is not relevant because regular CoAP can be used with those devices. However, if the "high latency" mentioned for S1 class devices because sufficiently large there may be so much timeouts in CoAP that the protocol effectively stops functioning. In this case we have at least two solution directions to follow:
1) change timing parameters of CoAP protocol (requires the non-sleepy CoAP device to also know about, and use, the new timing parameters)
2) use the same solution as is used for S0 devices.

We should check whether to update the 'sleepy-reqs' I-D with such considerations, or to have these in the 'sleepy-problem-statement' I-D.

o   It would be nice if you included http://tools.ietf.org/html/draft-rahman-core-sleepy-02 in your survey!
-> well, this document is not really a survey but it tries to construct a specific solution with some variations on how to implement the interfaces that are part of that solution.
There could be a similar document made with the solution of rahman-core-sleepy-02 integrated, I think.

Esko
From: Rahman, Akbar [mailto:[email-masked]]
Sent: Monday, June 17, 2013 05:13
To: Dijk, Esko
Cc: [email-masked]
Subject: RE: [core] Sleepy devices in CoAP - Requirements

Dear Esko,

Thanks for the excellent input to the Sleepy Devices space.  I have the following initial feedback on your I-Ds:

o   The I-D seems to have a majority of requirements that can very realistically be addressed at the COAP application level (which is very good).  But also it has some other requirements that most likely would need to be addressed at some lower level than CoAP (e.g. section 4.3, item 6 - Client location).  Is my observation accurate, and if so should this duality be clearly indicated in the I-D?

o   Do you think that it would be worthwhile to note that there are two classes of sleep patterns for sleepy devices (SEPs)?  Namely, some SEPs may have predictable (e.g. scheduled) sleep cycles and others may have completely unpredictable (e.g. external event driven) sleep schedules.   Maybe you had captured the concept in the text but it did not stand out for me at least.  At least section 4.7 (item 1- Configurable sleep interval) seems to imply only support of fully scheduled sleep cycles to me ...

o   I think we need to support more than just S0 class devices as SEP (section 1.2).  For example, S1 is probably an important class of devices to also support as SEPs.

o   It would be nice if you included http://tools.ietf.org/html/draft-rahman-core-sleepy-02 in your survey!

Best Regards,

Akbar

Dear all,

regards,
Esko