The Challenge of Building a Low-Power Network Reachable IoT Device

Building a battery-powered IOT device is a very interesting challenge. Advancements in technology have enabled IOT module chips to perform more functions than ever before. There are chipsets available today that are smaller than a penny in size, yet they are equipped with GPS, Wi-Fi, cellular connectivity, and application processing capabilities. With these developments, it is an opportune time for the creation of small form factor IoT devices that can connect to the cloud and solve interesting problems in all domains.

There are plenty of applications where the IOT device needs to be accessed externally by an application to request a specific task to be executed. Think of a smart home lock device that needs to open and close the door lock from a mobile application. Or an asset tracking device that must start logging its location upon request. The basic idea is to be able to issue a command to these devices and make them perform an action.

Problem Statement

At first glance, it may seem pretty straightforward to achieve this. Connect the IoT device to the network, pair it with a server, and have it wait for commands. What is the big deal, one may ask? There are a few hurdles to making it work within a low-power battery-driven setup.

Cellular radio is expensive on battery. Keeping the device constantly connected to the network will drain the battery really fast. Maintaining a constant network connection can consume a significant amount of power and reduce the battery life span to an unacceptable level for most battery-powered applications where the expected battery life span is in the months to years range. Such a device must be designed to conserve power as much as possible to extend its operational life. 

Applying first principles thinking to the problem of high power consumption caused by cellular connections, we can ask a critical question: Is it necessary for the device to remain connected to the network at all times? In most cases, the device may not need to transfer or receive any data, and it may not make sense to keep it connected to the network. What if we could make it stay in 'sleep' mode and periodically wake it up to check for any incoming commands? This would mean the device only connects to the network when necessary, hence saving power. This is the fundamental idea behind the LTE-M power-saving modes. There are two modes that LTE-M offers: PSM and eDRX. Let's look at them in detail.

PSM Mode

When in PSM mode, an IoT device can request to enter a dormant state (RRC Idle) for a duration of up to 413 days. This mode is particularly useful for devices that need to periodically transmit data over the network and then go back to sleep. It is important to note that the device is entirely inaccessible while it is in the dormant state.

This is the power profile of a device in PSM mode. 

[Fig 1: PSM Power profile]

The device remains in a dormant state for an extended period until it wakes up to transfer data. Additionally, there is a brief paging window during which the device is reachable, after which it returns to sleep mode. Requesting longer sleep times can result in greater power savings, but it may also require sacrificing data transfer frequency. Ultimately, it is up to the developer to determine the ideal tradeoff between sleep time and required data resolution, depending on the application requirements. A smart energy meter might be perfectly fine sending updates once per day, but a GPS tracker that needs to send more frequent updates would need shorter sleep times.

eDRX Mode

The term eDRX stands for "extended Discontinuous Reception". The concept is similar to PSM mode, where the device goes into RRC Idle, but unlike PSM mode, in the eDRX, the device wakes up periodically to "check-in" with the network every eDRX cycle period. 

The maximum sleep time for eDRX devices ranges from up to 43 minutes for devices using LTE-M.

[Fig 2: eDRX power profile]

Compared to eDRX, a PSM device requires significantly more time to wake up from sleep mode and remain active, as it must establish a connection with the network before it can receive application data. When using eDRX, the device only needs to wake up and listen for 1 ms, whereas with PSM, the device must wake up, receive, and transmit control messages for approximately 100-200 ms before it can receive a message from the cloud application, resulting in a 100-fold difference. [1]

While these power modes seem promising for a low-power network IOT device, building a reachable device, i.e., a device that can send a message packet externally over the network, is still challenging. We will go into the details of the challenges that are encountered with TCP, SMS, and UDP-based communication protocols.

Communication Protocol Considerations

There are a variety of IOT communication protocols available for different kinds of IOT applications, but for the purpose of this article, we will categorize them into two kinds. 

• Connection-based: TCP-based MQTT, Websockets, HTTP
• Connection-less: UDP-based MQTT-SN, CoAP, LWM2M and SMS.

Connection Based Protocols

These communication protocols require an active connection over the network for the data to transfer. The connection is established over a three-way handshake, and it looks something like this:

[Fig 3: Three-way handshake illustration]

Notice that before any actual payload data can be transferred (shown in green), there are three network payloads that need to be sent back and forth. This overhead may seem little for a system where data consumption or battery life isn’t an issue, but in our case, this would cost a lot of precious battery resources, sometimes consuming more data than the actual payload just to initiate a connection.

Secondly, notice in the figure that the client is the one initiating the connection; this is intentional and a big limitation of connection-based (TCP, MQTT, etc.) protocols in the application of a network reachable device, which requires that the device responds to the server’s request.

One could have the client initiate a first connection and keep the connection open, but to keep the connection alive, keep-alive packets need to be sent every pre-defined interval, which again costs a tremendous amount of battery, making these kinds of protocols unusable and impractical for a low power network reachable device.

[Fig 4: TCP Based communication protocol power profile]

Connection-Less Protocols

Connection-less protocols require no active connection with the server for the data transfer to occur. These offer a much more promising outlook for the network-reachable IOT device application. Some examples of such protocols are MQTT-SN, CoAP, and LWM2M, which are implemented on top of UDP. 

These protocols are lightweight and optimized for power and resource consumption, working in favor of the resource-restricted platform they’re intended to be used on. There is, however, a logistical challenge with these networks with regard to the device being network reachable.

Despite the protocols themselves being connection-less, the underlying network still requires occasional data transfer to maintain active NAT translations. NAT (Network Address Translation) devices, commonly used in home and enterprise networks, have timeouts for translation entries in their tables. If a device using connection-less protocols remains dormant for an extended period, exceeding the NAT timeout, the corresponding translation entry is purged, hence making the original client unreachable by the network. To address this, periodic keep-alive messages or other mechanisms have to be implemented to maintain NAT translations and ensure continuous network reachability for IoT devices using connection-less protocols but that is very expensive on the battery and not ideal for an IOT device where battery is a scarce resource.

Conclusion

As we have explored in this article, building a network-reachable device is a challenge on all layers, from device constraints to infrastructure limitations. UDP-based communication protocols offer a promising future for low-power network reachable devices because, fundamentally, the logistical challenge of the NAT timeouts, as mentioned above, can be eliminated using a private network and bypassing the NAT altogether. As enough interest grows in the need for network-reachable devices, we should see specific commercial network infrastructures that offer out-of-the-box solutions for these challenges.