Subject: [core] Battery lifetime optimization idea for Mirror Server

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 29 Mar 2013 10:00:49 +0000

Hello  Matthieu,

I considered an optimization for the Mirror Server (http://tools.ietf.org/html/draft-vial-core-mirror-server-00) that could extend the battery lifetime of Sleepy Endpoints (SEPs) significantly. The idea  applies to SEPs that have writeable resources registered into a Mirror Server (MS). Based on Section 4.8 (Modification Check) a SEP needs to periodically check if one of its resources has been changed on the Mirror Server. This requires an extra CoAP request in addition to the sensor value updates the SEP is periodically sending to the Mirror Server, e.g. like PUT /ms/0/sen/temp "22". In a typical use case as I see it, the SEP performs this PUT every time it wakes up and also GETs to do the modification check in the same awake-interval. Two requests, two responses.

The idea is to make this into only one request + one response in the following way: the SEP sends a PUT request to update e.g. its temperature value; and then the Mirror Server responds with 2.04 Changed and only in case one of the SEP resources has been modified on the Mirror Server, it attaches a special short payload to the response that indicates "one or more of your resources have been changed". It could be a single character "M" for example. This is a trigger for the SEP to do the modification check of section 4.8.
Because in >99% of the times no changes have been made to the SEP resources on the MS, the average message load drops to one request + one response per awake-interval.

The alternative here is to define a new Option that is attached to the 2.04 response message; that seems a neater way to do it. This Option doesn't need to be recognized by anyone except the SEPs and Mirror Servers that adhere to this specification so I don't see any bad side-effects to CoAP by defining such Option in a spec separate from core-coap.

So perhaps we can include a feature like this in MS, to meet the home/industry demands for long battery life for sensor-type 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: Carsten Bormann <[email-masked]>
Date: Fri, 29 Mar 2013 11:15:22 +0100

Maybe this should be discussed in the context of bundling and batching.

There would be no problem defining a new media-type that is essentially a list of resources that might require attention.  Since servers are free to send back a PUT response of their liking, returning this media type could be made into a convention for MS.
(You might even misuse the link-format syntax for this.)

While I have the attention of everybody interested in sleepy nodes:

LWIG has a new version out of the terminology draft, with some power-related terminology.
We are likely to reference this in our specifications, so please do have a look.

Htmlized:        
http://tools.ietf.org/html/draft-ietf-lwig-terminology-02
Diff from previous version:            
http://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-terminology-02

Grüße, Carsten

PS.: Oh, and calling them SEPs is part of a contest for how many different unrelated meanings we can ascribe to this TLA? Like we do for MAC? :-)

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 29 Mar 2013 10:50:21 +0000

Thanks for reminding ;)

Exercising the LWIG terminology: Mirror Server clearly targets class S0 (Always-off) devices and clearly not S2 (Always-on).
What about class S1? I assume that class S1 "some form of network  attachment" means that the device is still reachable for CoAP requests. (e.g. because nearby routers buffer IP packets for the sleepy device. An example for this is the "fast poll state" of ZigBee-IP; every 500 ms or sooner a node then wakes up to poll for packets at its parent router. Spec is now public at http://www.zigbee.org/Specifications/ZigBeeIP/Download.aspx ).

 So only class S0 is targeted by Mirror Server if I'm correct.

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Friday, March 29, 2013 11:15
To: Dijk, Esko
Cc: [email-masked]; core ([email-masked])
Subject: Re: [core] Battery lifetime optimization idea for Mirror Server

Htmlized:

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Mar 2013 11:54:43 +0100

> So only class S0 is targeted by Mirror Server if I'm correct.

Being able to say sentences like these in a concise way is exactly why the terminology draft is so useful...

Yes, that is my understanding of the Mirror Server concept as well.

Grüße, Carsten

---

From: [email-masked]
Date: Fri, 29 Mar 2013 13:28:46 +0100

Hi Carsten and Esko,

>Since servers are free to send back a PUT response of their liking,
returning this media type could be made into a convention for MS.

It seems a bit strange to send back a payload that is unrelated with the
target resource but I admit that it is efficient.

Matthieu

---

From: [email-masked]
Date: Fri, 29 Mar 2013 13:28:48 +0100

> So only class S0 is targeted by Mirror Server if I'm correct.

Yes, but the idea is that a S0 is a kind of S1 when it is not off.
Mirror Server is used in addition to optimized link-layer techniques. It
doesn't aim at being a replacement.

Matthieu

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 29 Mar 2013 12:38:46 +0000

In my understanding being a S0 device means that once you wake up, you can still remain awake for arbitrary periods, even in an always-on mode (i.e. without doing any RF duty cycling, using a regular 802.15.4 link layer without optimized techniques, etc.).  So indeed it then behaves as a S1 device or a S2 device would normally do all the time.

Esko

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 29, 2013 13:29
To: Carsten Bormann
Cc: core ([email-masked]); Dijk, Esko
Subject: Re: [core] Battery lifetime optimization idea for Mirror Server

Yes, but the idea is that a S0 is a kind of S1 when it is not off.
Mirror Server is used in addition to optimized link-layer techniques. It doesn't aim at being a replacement.

Matthieu