[core] Battery lifetime optimization idea for Mirror Server

["Dijk, Esko" <[e-mail]>]

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.