OMA_LwM2M_for_Developers
OMA_LwM2M_for_Developers copied to clipboard
OpenMobileAlliance
Is there a way for a server to say to a client using queue mode there is no (more) request for it.
Here a use case which was reporting to me :
A fleet of devices which are using QueueMode.
Most of the time there are sleeping to minimize battery consumption.
When they wake up, they send an Update request.
Then wait for several seconds (at least MAX_TRANSMIT_WAIT seconds is recommended by the LWM2M specification) in case there is requests from the server (not so often in this particular use-case).
Then to go back to sleep.
- It sounds that waiting before to go to sleep is not so good for battery consumption.
- Is there a way to tell to the device there is no need to wait. (e.g. a
go to sleepexecutable resource ?)
I found nothing in the specification which address this kind of optimization. I also tried to find a object which could help in LWM2M Registry without success. (maybe I missed something)
Is it something that somebody already faced ? is it something which is addressed or will be addressed in recent or future version of LWM2M ?
The time a device has to wait before going back to sleep is dependent on the transport. When the Queue mode was defined, the specification focused on the use of CoAP over UDP as a transport.
For other transports MAX_TRANSMIT_WAIT has not been optimized. The overall time a device has to wait is rather low in QUEUE mode and therefore there was no interest in optimizing MAX_TRANSMIT_WAIT for each individual transport.
We will nevertheless clarify this aspect in a future version of the specification.
@hannestschofenig do you think it makes sense to have a request to say "no more request for you" ?
Pretty much like we do with bootstrap finished request ?
Or a less specific request like a just an execute request on a go to sleep resource ?
Maybe this kind of resource could be added in an existing object without need to modify the current specification.
I rethought about it.
We can imagine several level of optimization.
1) Without changing anything, just using a shorter "awake" time could be a first step. (But in our case this sounds not enough.)
2) To minimize awake time (as proposed above) we can imagine a new executable resource on an existing object. It can be done with current version of the spec just by adding a new object or a new version of an existing object. (This could be OK for us)
3) To minimize awake time and data, for the particular use case where the server has nothing to send to the client. We can imagine to add the information in the payload of the Update Request response 2.04 Changed. This is the optimal way but need a new version of the specification and also I'm not sure if this is respect the CoAP spirit. (See rfc7252#section-5.9.1.4)
(Just an idea maybe for next version of the specification)
About 2), I would really appreciate feedback from OMA. I would like to avoid to fall in "proprietary"/"not interoperable" solution.
Is it something that you would like to add to an existing object ?
Do you have a better idea than a kind of go to sleep resource ? (maybe not so good for multi-server use cases :thinking:)
If not should I create a new Object and register it to OMA ?
But creating an object just for 1 resource sounds not to good... :confused
By the past, I proposed a DeviceExt object but was decided to be renamed in RebootStatus, so can not really be reused.
Personnal opinion:
About 1: the CoAP timers values defined in RFC 7252 are recommanded but not mandatory. A device can use different ones. They can also be configured by the Server thanks to the CoAP Config Object (ID: 500). But this does not fix anything for other transports.
About 2: receiving, handling, and replying to an execute operation on this new resource would probably be more taxing on the battery than being idle for MAX_TRANSMIT_WAIT seconds. However that may depends on your hardware.
About 3: this idea have been floating around in the IETF Core WG, again for CoAP transport, by defining a new CoAP option meaning "I have nothing more to say". Otherwise, when using a DTLS based transport, the LwM2M Server can close the session after sending the update response.
this idea have been floating around in the IETF Core WG, by defining a new CoAP option meaning "I have nothing more to say"
@dnav do you have any pointer ?
Otherwise, when using a DTLS based transport, the LwM2M Server can close the session after sending the update response.
Maybe I missed it, but AFAIK nothing in the specification says that closing the DTLS connection means "I don't want to talk you anymore" ? I'm not too comfortable with the idea to base this kind on feature on DTLS Layer. DTLS jobs should only be to provide a secure channel with authentication. I already don't like how specification ties LWM2M registration and DTLS connection. (see #506) By the way because of this tie if you close the DTLS connection, you force device to register again for next communication instead of just updating the registration. One more example showing this tie sounds not a good idea.
About "waiting" vs "sending an exec", there is a discussion about it here : https://github.com/eclipse/leshan/issues/998#issuecomment-829217174