IoT Blog
IoT Blog

How To Design Low-Power IoT Applications Part 2: Optimizing the Non-Optimal

by Altair
In Altair's latest webinar, How to Design Low-Power IoT Applications, Dima Feldman, Altair’s Head of Product Management, talked about the steps for designing and deploying low-powered IoT applications.

The first blog of a two-part series based on the webinar focused on the initial steps of developing a low-powered IoT device Now, in part 2, we focus on one specific IoT scenario and how it can be optimized for battery life and power consumption.

IoT button: a non-optimal scenario

An IoT button provides a good example of a simple application that will periodically send data, usually less than once a day.
When the button is pressed, the device has to power-up and boot, loading any relevant software and sync with the network. Once it has established the connection, it will send the payload and then have to wait quite some time to be released from the network before idling and finally powering down.

If not designed carefully, device will draw excessive power due to:
  • The DNS lookup requires a significant amount of data exchange.
  • After the TCP setup, it will have to establish the security session itself (TLS/SSL) – the most costly aspect, in terms of data exchange, requiring a certificate exchange on both sides.
  • It will then use either MQTT or HTTP protocols to send the data, which tend to be less efficient because they use DTLS over UDP.
The result is a device which uses some 5,000-9,000 bytes and takes over four seconds to send a very small amount of data.

How can we optimize it?

There are, however, some key techniques which can be employed to optimize the data exchange:
  • For the DNS lookup, time can be saved through use of a static IP, or by extending the time to live (TTL).
  • The protocol selection can be switched from TCP, which requires the device to remain on waiting for a reply for each package it sends, to a UDP– based protocol; or longer keep-alive timers can be used.
  • TLS being the de-facto security protocol today, one could look at using an abbreviated TLS method for re-establishing the connection, the benefit being that after the first connection, the server will remember the device and so won’t have to exchange the certificate again.
  • Instead of MQTT and HTTP, there are alternative protocols more optimized for IoT use cases, such as MQTT-SN, a variant of MQTT focused on smaller messages.
As the IoT continues to expand, power consumption will remain the primary concern for device manufacturers. Developers should consider the appropriate LTE technology to suit their needs and adjust protocols as necessary to maximize battery life.

If you’d like to watch a recording of the webinar, it can be accessed here.

This post also appears on the Altair LTE Blog.