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 are 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; therefore, they need to work in queue mode. Device Management Client defines the mode in the registration phase, by setting the LwM2M binding mode to Q.

Regardless of the device operation mode, any messages sent to the device are held in server queue until delivered. For more details, see guaranteed delivery.

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

Resource cache

To minimize unnecessary traffic to Device Management 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 Device Management Client (at the Resource level).

Device Management 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.

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. More information about memory considerations for firmware updates is available in the Porting section.
  • For Device Management Client 3.2 and later, you can build a delta image that requires less space.

Power consumption

Use resource caching and queue mode as much as possible.

Auto-observation

The auto-observation feature reduces traffic between Device Management 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 device and Device Management. Normal subscriptions require subscription tokens to be sent from Device Management to device 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.

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 Device Management Client to register (Client.register_and_connect();).
4. Device Management 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.