Skip to Main Content
Cumulocity IoT Feedback Portal
Status Likely to support/improve
Created by Iain Mackenzie
Created on Nov 3, 2023

LwM2M – C8Y should not implement queuing when a device registers with queue mode = false

For a LwM2M device, C8Y always performs queuing even if queue mode is set to false (Binding Mode: U) on registration. This can be observed by:

  1. Device successfully registers.

  2. A read (or write) is issued from the shell, but due to say a temporary loss of connectivity the read timeouts. Because of this timeout the device is considered “offline” by C8Y.

  3. Any subsequent read is then queued and will only be completed after the next successful registration update which could be up to 24 hours later.

So could C8Y be modified so that:

If on registration a device’s queue mode is set to false (Binding Mode: U). It should be assumed that the device is always online, and C8Y should try the read/write/operation immediately. If the operation fails (after the configured retries), say due to a timeout, it should be marked as failed and no further action taken. In other words the read/write/operation should never be queued to try at a later time.

If on registration a device’s queue mode is set to true (Binding Mode: UQ). C8Y should operate as it does now i.e. it should be assumed that the device maybe online. C8Y should try the operation & if it times-out it should be queued, until the next time the device is online. It would be useful to also add the following:

  1. Some configurable job timeout like 48 hours i.e. what happens if a device never comes back online.

  2. Deduplication. No sense adding the same read/write/operation to the queue again if it’s already present.

  • Attach files
  • Iain Mackenzie
    Reply
    |
    Jan 8, 2024

    Hi Aaron,

    Increasing the registration frequency could be a temporary workaround. But it has real cost implications as each registration update incurs at least 1 MEA, plus it’s extra cellular data that must be paid for as well. In my view, C8Y needs to properly honor the queue mode setting.

    A typical scenario for us is realtime control of a LwM2M device from the server e.g. turning on a streetlight. The operator needs to know that the device has either successfully performed the action (streetlight is on) or it’s failed in a timely manner. Queueing it up to try at a later time (even if it’s just ten minutes later) makes no sense.

    Regards

    Iain Mackenzie

  • Admin
    Aaron Raab
    Reply
    |
    Jan 8, 2024

    Hi Iain,

    the underlying problem here is that for devices that are anyway online you don’t want to wait 24h for the device to pick up new operations. But if the device is anyway online all the time I assume that energy consumption is not an issue. In that case you could also change the frequency of registration updates to let’s say 10 minutes. Is there from your side anything that speaks against this approach?

    Best regards,

    Aaron

  • Admin
    Aaron Raab
    Reply
    |
    Nov 27, 2023

    Hi Iain,

    this is something we agreed on implementing once we find the time for it (as there are still many things in our backlog we need to work on first).

    Best regards,
    Aaron