Building an LwM2M client with a focus on energy conservation
Designing a radio-connected device operating on battery power means balancing several aspects that often conflict. For instance, frequent data reporting, real-time event notifications, and a rich feature set are desirable features, but they can be difficult to reconcile with the need for years of operation on a small battery.
This is why client design decisions require careful deliberation. One crucial decision involves selecting the protocol to use for reporting data and remotely controlling the device, and one good option is Lightweight Machine-to-Machine (LwM2M)built on the Constrained Application Protocol (CoAP).
For an embedded system designer, building a low-cost LwM2M client involves designing a complete system (including the battery, processor, modem, communication stacks, and application) that is independently efficient and thoughtfully integrated for optimal battery life. This requires making the following strategic architecture design choices.
Threading
Deciding between a real-time operating system (RTOS) and multiple execution threads is one of the first architecture choices to be made.
Threads can help lower the complexity of large applications and distribute CPU resources among concurrent tasks, but they may not be worth including in a closed-off system controlling a small set of sensors. Using threads increases memory consumption (a 1 KB processor stack per thread is typical) and adds concurrency issues. Nevertheless, the alternative finite-state automaton model also has drawbacks, as it can be fragile and difficult to maintain.
In all cases, the overall code execution schedule should be clear starting from the design stage. LwM2M itself does not mandate the use of a rich Transmission Control Protocol/Internet Protocol (TCP/IP) stack and can usually rely on a single thread and a single modem-provided socket for all its needs (data upload, device management, firmware update, etc.), so it does not require an RTOS.
Spotty communication
The key to reducing energy consumption lies in decreasing the number of instances and shortening the intervals at which the device is actively communicating. It is best to set the device to sleep when it doesn’t need to be awake and ensure it talks to a management server only a few times a day.
While it is possible to build such a system using TCP, this streaming protocol bears several aspects that impact a device’s power budget:
- Establishing a TCP connection, especially if secured using Transport Layer Security (TLS), is relatively costly.
- Maintaining the connection requires sending keep-alive messages periodically, as well as the ability to reply to server-initiated keep-alive probes.
- It can incur significant memory usage due to its dynamic aspect.
User Datagram Protocol (UDP) is usually more desirable because:
- It requires no connection.
- It does not require periodic transmissions (keep-alive probes).
That said, UDP has a few downsides:
- UDP datagrams may arrive at their destination in a different order than they were sent.
- UDP datagrams may be dropped.
- Network UDP routes are dropped quicker than TCP routes. If this happens, the server will be unable to reach the device until the device itself sends data again.
These downsides are also known to CoAP, which associate tokens to requests and supports confirmation and retransmission, as well as LwM2M, which handles unreachable devices through the queue mode mechanism. The UDP routing problem is aligned with Narrowband IoT (NB-IoT) power-saving mechanisms, which turn off the radio quickly after transmission, rendering the device offline.
Power Saving Mode (PSM)
NB-IoT supports a Power Saving Mode, which is essentially a sleep mode. While ‘asleep’, the device remains attached to a cell tower but is offline. Data sent through the radio network to a sleeping device won’t reach it. However, as soon as the device wakes up, either periodically according to the timers negotiated with the tower upon registration or because it needs to communicate, a new ‘connected’ period starts. In this connected state, the device is available for incoming traffic reception. The duration of this window is negotiated with the cell tower and is best kept at a few seconds.
A device’s power consumption while in idle mode is thousands less than its power usage when transmitting and is a small fraction of the current needed to keep a device connected (even when the device is not sending or receiving data). To save power during connections, the connected window can be partitioned so the device is only reachable during small intervals. This is the Discontinuous Reception (DRX) mechanism. With DRX, data sent to the device is delivered with a predictable delay but not discarded by the network.
Such a cycle starts immediately after the device stops transmitting. A well-designed application can align its transmissions with the programmed radio timers or restrict its radio activity to the connected period boundaries, which the modem reports to the application. (Figure 1.)
Latency
NB-IoT latencies can easily reach ~10 seconds, and its throughput is in the order of kilobytes per second, even under ideal conditions. This must be considered when selecting the CoAP timeouts and PSM parameter values and accounted for when building applications on top of LwM2M / NB-IoT.
This also means that the power budget imposes a cap on the total amount of data that can be exchanged between the device and the server.
LwM2M offers several mechanisms to reduce the number of frames exchanged.
Bulk transfer
Coalescing several updates and sending them as a large packet rather than one by one reduces total latency and improves throughput. This can be done using the LwM2M 1.1 data push operation (a composite operation in nature) or by temporarily locking the transmission of notifications if the application permits.
Note that the battery must be able to support the heavy usage of the modem, as bulk transfer requires the transmission of several large frames over a short time span.
Peak power consumption
Batteries with low self-discharge are limited in the amount of power they can provide at once. They won’t be able to sustain the prolonged radio usage required by a firmware update session. Thus, they either need to be coupled to a capacitor or their characteristics taken into account by all elements of the firmware stack to limit peak power usage.
Testing should cover good as well as bad network conditions. NB-IoT power usage can increase markedly under degraded conditions (long distance, interference), and that’s not even taking packet loss and retransmissions into account.
The “turn on modem, transmit, then turn off” method
Instead of dealing with all these considerations, it may seem easier to simply turn off the modem when it’s not needed. While conceptually simple, however, this technique usually yields a higher average power consumption than PSM due to the complexity of reattaching to the network. The typical power draw in PSM idle is a few microamperes (μA), which enables years of operation on a small battery.
RX path
Particular attention should be devoted to the handling of the radio reception window. CAT-NB1 and its newer NB2 (3GPP rel 14, higher bandwidth) iteration are half-duplex systems. The modem can be seen as generally alternating between transmission, reception, paging (checking if the communication tower holds incoming data), and idle mode.
Several parameters are negotiated when the modem attaches to the tower. The Tracking Area Update timer controls the interval between the connected and idle cycles. The active cycle contains several paging windows, whose duration can be configured. The active time timer controls the number of seconds during which the reception (RX) path remains open after a transmission. The tower has the ultimate say on the values that get used. The modem communicates them to the application using the CEREG notification.
Having the shortest possible RX windows is a good way to save power. It works well with LwM2M provided,
- the device requests queue mode when registering to the LwM2M server;
- the application itself is tolerant of this scheme; and
- NB-IoT latencies, which easily go to 10 seconds under poor radio coverage, are supported.
Queue mode
LwM2M servers will buffer any outgoing traffic for clients registering with the Q mode indication. They will then send everything that has been stored or queued once the client performs a registration update.
The delay between registration updates is therefore an important consideration for the application designer. For further optimisation, it is also possible for the client to buffer outgoing notifications until the next outgoing traffic time slot.
Release Assistance Indication (RAI)
NB-IoT also supports the unilateral shutdown of the RX path through the Release Assistance Indication mechanism, which may help save additional milliwatts. This means there is no need for paging after a non-confirmable data push, so the application can tell the modem that it does not expect any incoming traffic for the foreseeable future.
This should be used with care, however, as it may interfere with the reception of an Acknowledgement (ACK) for confirmable CoAP messages, queued LwM2M commands following a registration update, a Datagram Transport Layer Security (DTLS) handshake, or a firmware update session, among other things.
Encryption options
Using DTLS, it is possible to cryptographically secure the link between the device and the server. However, this may not be the best choice energy-wise. Support for the connection ID extension ought to be used to guarantee that the link can be used for a long time after the initial (relatively costly) handshake completes, even if the IP address changes. Likewise, using the Pre-Shared Key mechanism is going to be less energy-intensive than using certificates. Using CoAP level authentication and encryption, i.e., Object Security for Constrained RESTful Environments (OSCORE), is a better choice, as it leads to smaller frames on average.
Error management
Transitory problems, such as a power outage affecting the radio network, can happen. It’s important to react to them thoughtfully, in a way that won’t deplete the battery. This needs to be considered in the design phase of the product, even if it is difficult to test. It’s worth having a fallback mechanism, such as reverting to the LwM2M bootstrap phase or factory settings after a while.
Simplifying LwM2M client design with IoTerop Iowa and Alaska
Trasna has developed two solutions that can drastically reduce LwM2M client design complexity and time to market. They are IoTerop Iowa and IoTerop Alaska, which enable LwM2M support out of the box, accelerating LwM2M client prototyping and massive IoT rollouts. More importantly, they can help streamline the process of designing energy-efficient LwM2M IoT clients and IoT networks.
Iowa SDK
Iowa SDK provides a ready-to-integrate LwM2M stack that eliminates the need to build firmware from scratch to implement LwM2M client-side. The pre-built features make LwM2M client design easier and faster, so designers can create a prototype in less than two hours.
One of its key advantages, however, is its inherent focus on energy conservation. Here are the features that make it capable of supporting IoT devices that must operate for 20 years on a single battery or charge:
- Minimal footprint: The stack can be as small as 40 kilobytes and requires less than 5 KB of random access memory (RAM).
- Code selection: The native support for various codes and specifications means the client designer can easily implement the transport, security, communication, client-server interaction protocols and mechanisms required by their energy-efficient design. For instance, Iowa provides support for the pre-shared key mechanism and OSCORE, which are excellent security and encryption options for lower power consumption.
- Built-in optimised power management: Iowa SDK includes ready configuration options for optimal bootstrap operation, device runtime scenarios, context storage, and CoAP retry timers.
Alaska device management
IoTerop Alaska is a cloud-based IoT device management platform that enables the centralised and comprehensive management of up to millions of IoT devices. Its native LwM2M capability makes it a preferred choice for managing LwM2M clients and, through the LwM2M Gateway extension protocol (which Iowa SDK can enable), it can interact even with non-LwM2M clients.
The native support for LwM2M makes it an excellent device management platform for IoT deployments with a focus on energy conservation. It also has the following features that enhance power savings:
- Lean protocols: Alaska uses lean protocols that significantly reduce data traffic and transmission frequency, thus extending client battery life.
- Optimised connectivity: The platform is connectivity agnostic and can manage devices even with intermittent connection on the slowest networks. This minimises the amount of energy clients must spend attempting to connect and sustain a connection.
- Built-in support for energy-conserving protocols: Alaska provides support for the protocols and mechanisms used by LwM2M clients designed for minimal power consumption, including the power management configuration options that the Iowa SDK enables.
Considerations in the design of an LwM2M client
Getting an embedded device to run for years on battery requires a careful selection of technologies to onboard, a holistic understanding of the entire hardware and software ecosystem, and painstaking attention to detail. Understanding precisely what the system does and when is key. Prototyping using the Iowa SDK and device management with Alaska will also definitely help.
Talk to a Trasna technical consultant now to learn how Iowa SDK and the Alaska device management platform can help you design energy-efficient LwM2M clients and IoT networks.
Get in touch for orders or any queries: sales@rfdesign.co.za / +27 21 555 8400
Courtesy of Trasna
