IoT Energy Management For Low-Energy IoT Devices

In this day and age, all the devices around us are becoming increasingly connected, while also being increasingly wireless. It is more and more obvious in many industries, that battery technology is the most limiting factor for modern technology. However, while we got used to plugging our smartphones to the wall every night and charging electric cars whenever we have the chance, there are many applications in which access to the power grid is even more limited.

Examples of devices that are required to be ready for operation for several years without replacing or recharging the batteries, would include various smart meters (for usage of water, electricity etc.) which are often designed to be simple to install with minimal changes to existing systems, so connecting them to the grid might not always be feasible. Similar arguments can be made for agricultural devices such as soil sensors, often installed in remote locations, quite far from power lines; cables running through fields could also be prone to breaking during field works. There are even some novel usages, such as location-enabled pet collars – it is preferable to take the collar off as rarely as possible, so that the risk of pet getting lost without it on can be minimized.

Limiting power usage in IoT

Radio transmission is power-hungry by its very nature. Power consumption of modern CPUs and microcontrollers, while getting lower with every generation, is also still much too high to allow continuous operation for months or even years on a single battery charge. For this reason, the primary way of extending battery life in IoT devices is to limit the time during which these power-hungry electronics are active, that is by keeping them in sleep mode for as long as possible.

This basic technique can be applied with any type of connectivity, but modern radio technologies dedicated for IoT applications such as LTE Cat-M1, NB-IoT or LoRaWAN, all falling under the LPWAN (low-power wide-area network) umbrella term, include additional extensions to the signaling protocol that make this even more effective. For LTE-based technologies including Cat-M1 and NB-IoT, these are Power Saving Mode (PSM) and extended Discontinuous Reception (eDRX).

Power-Saving Mode (PSM)

PSM is a feature of the 3GPP standards such as Cat-M1 and NB-IoT that allows the cellular module to shut down most of its functions in a way that does not terminate its registration to the network. Whenever the device wakes up later, it can reattach to the network much faster while exchanging much less data than if a full registration were necessary.

If there is no need to handle incoming traffic, the device can then go back into sleep mode within milliseconds. The registration can then be maintained by the network for up to 413 days, depending on the timer value negotiated between the device and the network.

Extended Discontinuous Reception (eDRX)

eDRX is another feature of 3GPP standards that facilitates even more aggressive power-saving scenarios. While in PSM, each wakeup from a deep sleep state must start with some device-originated transmission, eDRX allows the device to turn off its radio interface for an extended period of time (up to 43 minutes for LTE-M and even up to 3 hours for NB-IoT), and wake up only to listen in for possible incoming packets. The eDRX cycle length can be autonomously set by the device, and it is the network’s responsibility to queue device-terminated packets for appropriate time slots when the device is scheduled to wake up. The cellular module will only fully wake up if some data is actually received.

Furthermore, eDRX can even be used together with PSM. For example, the device may, after performing an outgoing transmission, function in eDRX mode for half an hour, checking for incoming messages every minute, and then switch into a deep sleep state permitted by PSM, ceasing all communication for several more hours.

The OMA LwM2M protocol contains several features that make it practical to employ the low-level power-saving mechanisms described above. These include:

• Queue mode. In LwM2M’s default mode of operation, the client device remains continuously connected and can process a request from the LwM2M Server at any time. However, when queue mode is employed, this functionality is limited and the LwM2M Server is only allowed to send requests to the client only for a short time after each client-originated communication. This allows the device to turn off its network connectivity when there is no data to be sent.
• The Notification Storing When Disabled or Offline functionality allows the device to queue up monitoring data without actually coming online and send all the outstanding data in bulk after reconnecting. This can be used to increase robustness in case of losing network connectivity, but can also be utilized to more aggressively limit online time for power efficiency.
• While Non-IP Data Delivery (NIDD) binding is not a power-saving feature per se, it allows the client device to forgo handshakes on PPP and DTLS layers and instead exchange data directly via the cellular IoT network’s control plane. This lowers the amount of raw data transferred as well as cuts down on processing power used by handling additional encapsulation layers.
• PSM and eDRX configuration is exposed as part of the LwM2M Cellular Connectivity object (Object ID 10) that is standardized by OMA, which allows these functionalities to be reconfigured from the server side.
  
  

Saving power with Anjay

While handling power-saving modes is outside the scope of Anjay, as it is a library that focuses on implementing the LwM2M protocol itself and does not perform such low-level hardware operations, it contains various APIs that make it feasible to implement all the mechanisms described above:

• LwM2M queue mode has been supported in both open-source and commercial versions since the very first release. The open-source version supports queue mode as defined in LwM2M TS 1.0, where the queue mode is enabled by adding “Q” to the Binding Mode resource, which can also be controlled by the server. The commercial version also adds an anjay_set_queue_mode_preference() API, which gives more control to the client application, in line with how queue mode is defined in LwM2M TS 1.1 and up.
• Offline mode support has also been available since the very first version. By default, Anjay assumes that network connectivity is available continuously. However, functions like anjay_transport_enter_offline() can be called to inform the library about the connectivity state – either if the signal is lost or if the device deliberately went offline to conserve power.
• Notification Storing When Disabled or Offline has also been supported in both open-source and commercial versions since the beginning. This feature is handled automatically, based on the settings in the data model and the state of the aforementioned offline mode.
• Core state persistence is a feature available in the commercial version that allows to dump the state of all server connections, including LwM2M and DTLS session states, to non-volatile memory when shutting down the library (anjay_delete_with_core_persistence()) and restore it during subsequent initialization (anjay_new_from_core_persistence()). This allows LwM2M registrations to be retained while the client device is in a deep sleep state.
• The aforementioned NIDD binding is also fully supported in the commercial version. A driver for NIDD connectivity with the popular Quectel BG96 cellular module is included, but flexible architecture allows the user to replace it with any other custom driver.

The commercial version also includes APIs to query the time at which automatically handled outgoing messages (such as Register, Update or Notify) are scheduled for sending. This allows the client application to precisely control timer-controlled sleep states so that the device can wake itself or its radio module up just in time to satisfy all the requirements of the LwM2M protocol.

If you want to know more and try these features yourself, don’t hesitate to contact us and ask for an evaluation of the commercial version of Anjay.