Speeding over-the-air latency for IoT applications with compression - Embedded.com

Speeding over-the-air latency for IoT applications with compression

During the development cycle for a wireless Internet of Things (IoT) application, developers spend the most time debugging and getting over-the-air (OTA) downloading to work reliably. Some key challenges when implementing OTA are patch updates, security and new feature integration. Slow OTA updates in the field cause major service disruptions and increase the likelihood of firmware corruption. But in industrial settings, nodes are located in hard-to-access or no-access areas; therefore, updating the firmware reliably is critical.

It’s possible to reduce OTA update times by reducing the firmware image size. The trick is to identify an efficient compression algorithm with a small code footprint that adds only minimal system-level latency. This article offers a solution with LZ4 compression and provides design considerations specifically for Bluetooth ® low energy OTA updates. Our solution can ultimately reduce OTA update times by as much as 40 percent, and help you implement a more economical OTA process that can scale for industrial applications with massive deployment.

From building and home automation to wearables, from automotive and smart cities to health care, the Internet of Things (IoT) touches every facet of our lives. Within the past decade, the number of IoT devices introduced on the market has increased dramatically. The total is approaching a staggering 8.4 billion, meaning that there are currently roughly two connected devices per living human.

This trend is expected to continue at a rapid pace, with an estimated 20.4 billion connected devices by the year 2020. Most connected devices within the IoT are nodes containing microcontrollers (MCUs), sensors, wireless devices and actuators that collect data. Figure 1 shows some of these connected devices.


Figure 1. IoT-enabled home, with connected devices and appliances working invisibly for consumers (Source: Texas Instruments)

The most common challenges when developing IoT devices are security and privacy, low power, diverse connectivity options and fragmented ecosystems. But one challenge isn’t mentioned that often: over-the-air (OTA) latency, which is the time that it takes to update an IoT device. Whether you are an IoT user or a developer/manufacturer, OTA latency is an interesting challenge, especially given the prevalence of high-memory nodes with low-speed interfaces.

We heard of a designer who was developing a smart e-lock with Bluetooth® low energy similar to the one shown in Figure 2. A 256KB image was taking close to 4 minutes to program. For the next generation (with extra features) of his e-lock, he wanted to increase the memory footprint to 512KB, but that would increase the upload time of new images to almost 8 minutes.


Figure 2. Bluetooth low energy e-lock (Source: Texas Instruments)

Slow OTA updates in the field cause major service disruptions and increase the likelihood of firmware corruption. During the development cycle for a wireless IoT application, developers often spend the most time debugging and getting OTA updates to work reliably.

Consumers already have connected devices like thermostats, energy meters, lighting control systems, e-locks, music streaming and control systems, remote video streaming boxes, pool systems, irrigation systems and garage door openers – with more to come. In industrial settings, the location of these nodes in hard-to-access or no-access areas makes reliable firmware updates critical.

Updating the software because of a bug fix or just because there are new features available is something that we expect IoT devices to be capable of; unfortunately, depending on wireless technology, such updates could vary between a few seconds to several minutes.

The most direct approach to reducing OTA firmware update times is to reduce the firmware image size. The trick is to identify an efficient compression algorithm with a small code footprint that adds only minimal overhead in terms of system-level latency.

One of these compression algorithms is LZ4 (LZ4 is an open-source specification), which is a lightweight compression library optimized for ultra-low power MCUs (for example, Texas Instruments SimpleLink™ MSP432™ MCUs).

Traditional compression formats such as .gzip, .zip and .7z are optimized for high compression ratios, with slow compression and fast decompression performance. These compression formats are typically used for file transfers where there is a single source but multiple destinations (such as file downloads).

Compressing files is a one-time cost, and it’s beneficial to trade compression speed for a higher compression ratio. While compression may occur very slowly, decompression is typically very fast (as much as 100x faster) because decompression only entails unfolding the compressed file. But running these compression algorithms on an ultra-low-power MCU would be impractical and take a significant amount of energy to enable both compression and decompression.

The LZ4 compression algorithm is designed for both fast compression and decompression, with less of a focus on the compression ratio. This format is well-suited for applications with point-to-point data transfers such as in large data centers, where the goal is shorter transfer times, but not at the cost of significantly increasing processing power to run compression.

This makes LZ4 an excellent choice for an ultra-low-power embedded device, where compression and decompression are equally important. The LZ4 algorithm provides a perfect balance of compression performance and functionality for a wide range of embedded applications, such as data logging, expanded data storage, OTA data transfers and more.

Figure 3 shows four different images compressed using the LZ4.


Figure 3. LZ4 benchmark (Source: Texas Instruments)

As you can see, preliminary results look very promising, with good improvement in most of the images. Applying LZ4 could reduce code size and download times by as much as 40 percent. Reducing OTA times by up to 40 percent will help you implement a more economical OTA process that can scale for industrial applications with massive deployment.

Now, let’s walk through the OTA process. Assume that your end equipment requires Wi-Fi® and Bluetooth functionality – see Figure 4 for an example.


Figure 4. Wi-Fi and Bluetooth end-equipment block diagram (Source: Texas Instruments)

The end equipment uses a host and a couple of radios acting as network processors. This modular approach gives you flexibility and scalability in case you would like to extend beyond these wireless technologies. Figure 5 lists the memory architecture.


Figure 5. Memory architecture (Source: Texas Instruments)

One challenge is finding a way to manage the images, but you can easily resolve this by adding a small section header on each image. Another challenge is finding enough space to store the images.

In this case, there are three different images:

  • A Wi-Fi radio image.

  • A Bluetooth low energy radio image.

  • A host MCU image.

Considering the software complexity (including Bluetooth and Wi-Fi stacks), the application functionality and the OTA download function, it becomes incredibly important to manage the tasks efficiently and effectively in real time. A good real-time operating system (RTOS) can play a vital role in enabling a robust wireless application, especially when coupled with processing-intensive compression algorithms. For example, the SimpleLink software development kit (SDK) provides industry-standard application programming interfaces (APIs), TI drivers and the TI RTOS, offering a robust foundation for application development.

In our experience, you are already looking for a host with at least 512KB of memory and probably 512KB more for image allocation. Reserving space to allocate multiple images is optimal but not mandatory; still, with this approach you can perform an update of all of the images simultaneously. If there is not enough free space in the host, you will need to reuse this space and program the images separately. Another way is to have an external serial flash, but that brings up some security concerns.

In regards to the OTA process, the application will receive the compressed images (Bluetooth low energy or Wi-Fi) and put them in memory. After confirming that the images are valid, the application will pass control to the boot loader, which will have the LZ4 routines. Then, the boot loader will program the application or network processor images accordingly. The updates for the network processors will happen through their serial interfaces, SPI for the Wi-Fi Radio and UART for the Bluetooth low energy radio – see Figure 4.

This is only one suggested way to perform this kind of update. Another method would be to have the LZ4 libraries as part of the application and upload the uncompressed images into memory.

For more information on how to leverage LZ4 compression to reduce OTA download times, check out this in-depth training video showcasing an implementation of the SimpleLink MSP432 SDK in conjunction with the CC2640R2F SimpleLink Bluetooth plug-in. A smart wireless application such as this Bluetooth low energy-enabled access control panel can be further enhanced by an optimal and robust OTA download implementation.

We hope you will find this information useful, and happy coding.

Additional resources

See the LZ4 full specification and download the open-source software.


David Lara is an Applications Engineer on the SimpleLink™ MSP432™ Customer Applications Team at Texas Instruments since 2012. Prior to TI, he has 13 years of experience supporting automotive customers as application engineer and embedded software engineer. One of his expertise during this time was to develop flash custom boot loaders for different automotive protocols, such as CAN and LIN. David holds a BS in Computer Engineering from Instituto Tecnologico de Monterrey [Mexico], a MS in Computer Engineering from New Mexico State University [Las Cruces, NM].

Dung Dang is a product marketing engineer managing the 32-bit ultra-low-power microcontroller (MCU) product line at Texas Instruments (TI). He is responsible for driving strategy, roadmap, business development, and new platform and production definition for TI’s 32-bit ARM Cortex-M MCU portfolio. Dung joined TI in 2007 and has served in various technical roles in new product development, key customer engagements, software and system solutions in MSP430 product line prior transitioning to product portfolio management. Elected on TI’s technical ladder (MGTS), Dung played a critical role in the MSP432 platform and ecosystem release, shaping the foundation of TI’s future 32-bit Cortex-M roadmap. Dung Dang holds an MSEE degree from St. Mary’s University at San Antonio, concentrating on embedded systems and image processing.

Stefan Schauer is a systems engineer for SimpleLink™ MSP432™ microcontroller (MCU) team at Texas Instruments. He joined Texas Instruments in 1995 and has since served in various roles in new product development and customer support. His experience covers a wide range of serial communication interface standards, microcontroller design and programming, and verification on application level. He also chaired the EEMBC(C) ULPBench(TM) Working Group for many years. Stefan Schauer holds a diploma degree from the UAS Landshut.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.