Recommended
Related

Extend your battery life with nRF Cloud's CoAP interface

Tuomas P
Extend your battery life with nRF Cloud's CoAP interface

Low power is one of the cornerstones of Nordic’s cellular IoT solution. The nRF91 Series is built from the ground up with ultra-low power consumption in mind, and the nRF Connect SDK provides applications and samples that optimize the device's performance and power consumption usage. On the other side of the connection, our nRF Cloud platform provides location services, firmware-over-the-air updates, and other features to increase your device's batter life further.

This is why we are excited to announce a new low-power addition to our nRF Cloud platform, the nRF Cloud CoAP (Constrained Application Protocol) interface. The CoAP interface is a future-proof addition to nRF Cloud, extending nRF Cloud services to other technologies. The CoAP interface enables efficient communication while lowering the device’s power consumption, memory usage, and operator fees. Introducing the CoAP interface, alongside our existing TCP-based interfaces, allows you to choose the option best suited for your application needs.

This blog post will discuss the new features of the CoAP interface and the benefits of using CoAP for device-to-cloud communication with nRF Cloud. We will also give you an overview of nRF Cloud's interfaces and how to choose which one to use for your application. Lastly, we will present power consumption measurements of an nRF9160 DK connection to nRF Cloud using both the CoAP and MQTT interface.

Table of Contents

Why CoAP?

So why have we added support for CoAP? And why should you use CoAP in your device-to-cloud communication? The CoAP interface brings less power consumption usage, lower overall data transmission and a reliable connection for both LTE-M and NB-IoT. Let’s look deeper into how the CoAP interface enables all these things.

The Constrained Application Protocol (CoAP) is a UDP-based transport protocol developed for constrained devices. Since CoAP works on UDP, it is lightweight for the device as there is no end-to-end connection signaling required, as there is in TCP. Although UDP is unreliable since it does not force acknowledgment, reliability can be achieved through the CoAP protocol. CoAP provides the flexibility to implement retry logic and reliability based on your use-case needs.

Reduced power consumption for secure connections

In a cellular network, unless you pay for a fixed IP, your device is assigned a dynamic IP address from the network. And since the secure DTLS sessions are tied to a device’s IP address, this means devices either need to maintain the connection, or they are unable to keep the same DTLS session for long periods of time, requiring a DTLS handshake every time it wakes up to send some data.

To solve this, the nRF Cloud CoAP interface implements the DTLS 1.2 Connection ID (CID) extension (RFC 9146). This significantly reduces the DTLS handshakes, saving kilobytes of data each time a device connects.

The basic idea is that the established DTLS connection is stored on both sides with a Connection ID, which is then used as the identifier in upcoming connections. This removes the DTLS bind to the IP address, and the device does not need to maintain the connection or IP address. With the Connection ID, the device can send requests only when needed, bringing power usage down while only requiring a short radio-on period.

The image below shows a simplified system flow between a device and nRF Cloud with and without using CID.

Smaller message size with CBOR

The nRF Cloud CoAP interface also implements Concise Binary Object Representation (CBOR) (RFC 8949). CBOR is a data format for constrained devices that enables smaller client code and message sizes. This reduces the overhead in packets, lowering the overall transmission of data, which allows you to save on operator fees. It also provides a structured, self-explaining format for binary data transfer. In short, it is efficient and easy to use.

Reliable for both LTE-M and NB-IoT

Using TCP-based protocols with NB-IoT can be problematic since NB-IoT is not required to support TCP, according to its 3GPP specification. Therefore, introducing the CoAP interface, which is a UDP-based protocol, enables the utilization of NB-IoT features and a reliable connection to nRF Cloud, regardless of which cellular technology you are using.

nRF Cloud interfaces

For device-to-cloud communication, nRF Cloud provides the TCP-based MQTT interface and the UDP-based CoAP interface.

So, how do you know which interface to choose? This all depends on the needs of your application.

As we have highlighted in this blog post, CoAP uses UDP, which is not as reliable as the TCP-based connection that the MQTT interface uses. However, this also results in higher power consumption as MQTT has to maintain the connection between the client and the broker.

While CoAP has a one-to-one communication model, MQTT supports multiple connected nodes simultaneously. MQTT is better for event-based systems, where you have multiple nodes interacting based on, for instance, their sensor values. CoAP is more suited for systems that monitor state changes, where you can transfer state information between client and server.

If your devices need to send data continuously, then MQTT is the best choice. However, if your device can sleep between sending data, CoAP is the better choice.

Power consumption measurements

We have measured the power consumption that an nRF9160 DK running modem firmware 1.3.5 uses when connected to nRF Cloud using both the CoAP and the MQTT interface. The device establishes a (D)TLS connection with nRF Cloud, then goes into Power Saving Mode (PSM) and wakes up intermittently to send data to the cloud. In the CoAP case, it uses CID to avoid a new DTLS handshake for the session, while in the MQTT case, the device sends MQTT keepalive messages every 20 minutes to keep the connection alive.

We tested sending data every 5 minutes, 30 minutes, and 60 minutes for 3 hours. The results are presented in the table below. 

As you can see, the less frequently the data is uploaded, the more power-saving the CoAP interface brings.

Please note that these are just one set of measurements in one network, and other networks will give different numbers.

Testing the CoAP interface

If you would like to test the CoAP interface, nRF Connect SDK tag v2.4.99-dev1 contains the nRF Cloud multi-service sample, which demonstrates a connection to nRF Cloud over the nRF Cloud CoAP library.

Your nRF9160 device must be running modem firmware version 1.3.5 or above to benefit from the power savings provided by DTLS Connection ID.

Closing

With the introduction of the nRF Cloud CoAP interface, you can now interface with nRF Cloud using either a TCP-based or UDP-based protocol. Allowing customers to select whichever option is best suited for their application needs.

The nRF Cloud CoAP interface enables you to:

  • Gain power savings from a short radio-off period as CID removes the need for a heavy DTLS handshake.

  • Save memory in the device with the CBOR format

  • Save operator fees with smaller message sizes and no heavy DTLS handshakes

Feel free to like this blog post and leave a comment telling us about your experience with the new CoAP interface

  • in reply to Harald

    Thanks for sharing Harald. Need to study your white papers. Yes the 3h measuring time is short and results here are averages from few test runs. As you mention, the position of device effects the consumption. The idea of these measurements were to give idea of the difference comparing MQTT and CoAP and to point out that depending on communication need, you need to make selection. We are planning to make more comprehensive measurements to bring up the advantages of MQTT and CoAP and enable user to select between protocols.

  • in reply to Tuomas P

    nRF Cloud is not using Californium as you expected. But let me check from other teams are there plans. We do not have graceful restart in our solution. We will consider it when we strat working on gateway connected devices such as NR+

  • in reply to Achim Kraus

    Hello Kraus, I have noticed your name on the standard but I was not aware your contribution to Zephyr and MbedTLS. I am looking this purely from nRF Cloud side.

  • in reply to Harald

    Device side stack is open source. Just have a look at the sample linked to in the article. It uses https://github.com/nrfconnect/sdk-nrf/tree/main/subsys/net/lib/nrf_cloud which builds on top of various Zephyr libraries.

  • I like the idea of comparing MQTT with CoAP. However, I missed several details. In 2018, we have already measured the energy consumption with NB-IoT (UDP) without a layer to secure it with LoRaWAN and Sigfox. We compared 12, 24, 64 and 512 bytes at 134, 144 and 154 dB link budget. See https://www.akoriot.com/white-papers/
    In the long test series, you can see +/-4dB in the RSRP.
    If you transmit every 60 minutes for 3 hours, that's only 3 transmissions. If I take the jumps from our test series as a basis, then there is a very high probability of very random results.
    I also miss the RSRP specification. At high field strengths, MQTT and TCP cause many repetitions due to packet loss. At low field strength, MQTT will consume more power than CoAP.
    If you are using a stack for CoAP, as Achim mentioned, then you should mention which one you are using. The same goes for TCP / MQTT. Within TCP/MQTT you should mention how many retransmissions have been set.

    Figure: Measurement series from the study