Documentation

Mistake on this page? Email us

Device guidelines

Queue mode for devices

IoT devices can work with Device Management Connect server in one of two modes:

  • In normal mode, the device actively listens for incoming packets from the server. This allows the server to forward requests from a web application to the device as soon as the web application sends the original request to the server. This mode is not suitable for devices that can be inactive most of the time.
  • In queue mode, the server queues all requests from a web application. It only forwards these requests to the device when the device sends a registration update.

For energy efficiency reasons, many IoT devices are inactive most of the time; they therefore need to work in queue mode. The client defines the mode in the registration phase, by setting the LwM2M binding mode to Q.

Server queue limits:

  • 100 messages per device.
  • There is no time limit for storing messages. They remain in the queue until:
    • The device sends a registration update message. The server then delivers the messages, and removes them from the queue.
    • If the device lifetime expires on server-side, the server deletes any data it's storing about the device, including queued items.
    • If the device sends a full registration message, the server deletes any queued items and any active subscriptions.

Queue mode

Note: Queue mode is only supported with UDP (MBED_CLOUD_CLIENT_TRANSPORT_MODE_UDP_QUEUE).

Application congestion delivery control

By default, the CoAP protocol does not allow multiple simultaneous transactions between the server and the device. If a transaction is in progress, any consecutive request gets the response of 429 Too Many Requests, until the first transaction is complete.

When using the device-side queue mode, the server solves the problem by adding requests to the queue (as explained above). But for non-queue mode devices, we developed the application congestion delivery control. It provides a new queue for non-queue mode devices: if the device is busy with a request, the server stores the other requests until the device is free to receive them.

The queue stores up to 20 requests at a time. The server sends an error message to the web application when:

  • The queue is full: 429 Too many requests.
  • The device lifetime expires: 429 Queue was cleared.

Application congestion

Resource cache

To minimize unnecessary traffic to the client, you can cache Resource values in the LwM2M server for a specified time. You can then use the cache to answer requests from third-party customer applications.

To configure the cache lifetime, set the max-age parameter (in seconds) on the client (at the Resource level).

The client includes the max-age information in responses related to Resources. For example, if you have a value that you want to cache for ten minutes:

  1. The device notifies Device Management Connect of the Resource value change, adding max-age of 600 seconds.
  2. Device Management Connect caches the resource value for 600 seconds.
  3. Device Management Connect notifies the web application of the new value.
  4. Less than 600 seconds later, the web application requests the same resource value.
  5. Device Management Connect provides the response from the cache, without contacting the device.

The LwM2M server will cache the Resource value only after receiving a response or an observation. It will be cached for up to number of seconds defined in the max-age option header. However, the server may reduce the time defined. The caching is not automatically triggered, so if no one has read the Resource or subscribed to it, the cache of the LwM2M server is not populated.

Note: The max-age is limited to 72 hours by the server side. The caching is also bound to device registration and all cached resources will be removed if the registration is deleted or expires.

Resource cache

Tip: For more information on the max-age configuration, see Working with the server cache.

Guidelines for memory usage

  • Minimize tracing for production releases. It can have a significant effect on RAM/ROM and performance.
  • Avoid dynamic memory use in applications whenever possible. In particular, any Resource that you do not need to change should be set as static.
  • Minimize eMMC usage to avoid the flash memory wearing out.
  • The firmware update feature requires a lot of space to fully load a new binary to the device (currently, it only supports full updates). More information about memory considerations for firmware updates is available in the Porting section.

Power consumption

Use resource caching and queue mode as much as possible.

Auto-observation

The auto-observation feature reduces traffic between the client and Device Management Connect at the registration phase. You can use it on all levels: Resource, Object instance and Object. Your web application will still need to presubscribe to the Resources to start receiving the Resource change events.

An example on how to use the auto-observation method:

M2MResource* resource = object_instance->create_dynamic_resource(“5700", “IntegerType“, M2MResourceInstance::INTEGER, true);
resource->set_value(10);
resource->set_auto_observable(true);

Note: Currently, Device Management Client can have a maximum of 1023 auto-observable Resources. You must set the method before starting the registration process.

Tip: For more information on this API, see the following API descriptions M2MBase::set_auto_observable.

Auto-observation and sleepy devices without RAM retention

Note: This information is valid for both Device Management Client and Client Lite for devices that sleep without RAM retention, but not for Edge.

One of the challenges of working with battery-powered, resource constrained devices is the power consumption. If a device sleeps with RAM retention on, it consumes more power. If it sleeps without RAM retention, you need to deal with other complications, such as storing the context and dealing with wear leveling.

Auto-observation was created primarily to decrease the amount of network traffic between the client and cloud. Normal subscriptions require subscription tokens to be sent from cloud to client in every full registration, while auto-observation removes this traffic completely. It also offers a solution, with some limitations, to observe devices without RAM retention.

Getting data from a device without RAM retention

This is how to get data from a device without RAM retention.

Auto-observe

  1. The web application presubscribes the Resources.
  2. In your device application, set the Resources auto-observable (resource->set_auto_observable(true);).
  3. The device application requests the client to register (Client.register_and_connect();).
  4. Client registers.
  5. The device application reads the sensor value.
  6. The device application updates the value to the Resource (resource->set_value)
  7. Device sends observation of the value change to Device Management.
  8. Device Management notifies the web application.

After wake-up or interrupt, start over from step 2.

Steps for deep sleep

Deep sleeping devices without RAM retention lose all of the RAM contents when they enter sleep, which means that every wake-up is very near a cold reboot. To drive the connectivity stack down in a controlled manner, use the pause and resume functionality.

Limitations caused by deep sleep

Losing the RAM contents limits the operation of the device as follows:

Normal observations cannot be used

  • Subscription tokens are only in RAM. You lose them and cannot use subscriptions.
  • Set everything that you want to observe auto-observable. The information gets sent to Device Management every time the device wakes up.

Observation rules are lost

  • Subscription rules, such as PMIN and PMAX, are lost because they are stored only in RAM.
  • When the device wakes up, the previous values are no longer available and there is nothing to compare with.
  • Update the auto-observable resource values only when you want a notification to be sent. In other words, you need to make sure that your application logic handles this.

Client pause and resume

Note: This information is valid for both Device Management Client version 2.2 onwards and Client Lite version 0.7 onwards. This information is not valid for Edge.

The application must ensure Device Management Client has a functional network connection. With the Client pause and resume feature, you can control Device Management Client when the application knows that the connectivity is not going to be available:

  • The application needs to turn off the network interface temporarily.
  • A device has multiple network interfaces and Device Management Client needs to switch between them. For example using Wi-Fi when available, but otherwise using cellular.
  • The device needs to enter deep sleep.

Note: Deep sleep assumes RAM retention. If you do not have RAM retention, in other words you hibernate, special limitations apply as described in Client deep sleep guidance. This is not natively supported in Mbed OS.

Using Client pause and resume

The following usage flow applies when starting up a device or resuming the connection after deep sleep.

  1. Initialize your network connection.
  2. Set up your (sensor) drivers.
  3. Set up your client Object, Object Instance and Resource structure.
  4. Update the Resource values to latest measured values.
  5. Start the client and connect it (MbedCloudClient.setup(*iface)).
  6. When you need to either enter deep sleep OR change network stack, call MbedCloudClient.pause().
  7. Do your required operations, such as:
    • Shut down the network stack (disconnect).
    • Store any values that need storing to non-volatile memory.
    • Set up interrupts and timers for wake-up.
  8. Get back operational (wake-up by interrupt, for example).
  9. Set up a network stack (connect). This can be a different network stack.
  10. Set up your (sensor) drivers.
  11. Set up your client Object, Object Instance and Resource structure.
  12. Call MbedCloudClient.resume(*iface) with a pointer to the network interface to use.
  13. Update the values to auto-observable resources. The updates will trigger the notifications from client to Device Management.

This sequence allows the client to change the network interface in a controlled manner.

Note: Mbed OS has network stack limitations. You cannot switch between all combinations of network stacks; for example, lwIP-based stacks require multi-homing support. Confirm that your configuration works before committing to product solutions.