White Paper — Data Compression for Low Energy IoT Connectivity

Dr. Nikos Zervas, CAST, Inc. •  November 2015

The trendy phrase “IoT” for Internet of Things has gotten applied to a wide range of different applications and diverse devices, but two characteristics are common: connectivity and low energy requirements.

Regardless of the specific network topology, bit rates, and communication standards, a significant amount of the energy budget of IoT nodes is consumed for communicating data. This is especially true for devices that use wireless communication links. In these,  the radio frequency (RF) subsystem is the dominant energy consumer, and putting this power-hungry communication link to sleep for longer periods is essential for lowering overall power consumption.

The RF subsystem’s active time—and therefore the energy consumed for data exchange—is more or less proportional to the amount of data that must be transmitted or received. So, using compression to reduce the size of that data can be an effective way to reduce the overall energy consumption of wirelessly connected IoT nodes.

Here we will describe an IoT device architecture that exploits lossless data compression, then try to quantify the energy savings this approach makes possible. 

The Architectural Template

Most IoT nodes are controlled by a microcontroller consisting of a typically low-power embedded processor (e.g. 8051, ARM Cortex, or BA2x); peripherals for communicating with some sensor (e.g., for thermal, image, chemical, or mechanical readings or analog-digital conversion) or actuator (e.g., a step motor or electric valve); and possibly some accelerators for the computational intensive tasks (e.g., DSP functions such as filtering, or baseband modulation demodulation).

The typical IoT node stores firmware in an NVM memory, and communicate via an RF subsystem (e.g., an RF transceiver for Zigbee or 802.11ah).

How can introducing a compression accelerator to this generic architecture reduce its energy consumption? 

Here we are considering a hardware accelerator for compression. Compression algorithms are typically computationally complex, so implementing them in software requires a significant amount of code and may actually exhaust the processing bandwidth of a typical low-power IoT embedded processor. Moreover, a hardware compression engine can perform compression faster and at a much lower energy cost.

An example hardware compression engine is the GZIP IP Core for deflate based compression offered by CAST [1].

Analyzing the Potential Energy Savings

Achieving worthwhile levels of compression—and therefore, significant energy savings—depends on the type of data a system must transmit.

IoT devices that exchange large volumes of image, video, or audio data, are poor candidates for further savings since these typically already use compressed data.

This leaves a large group of IoT devices with lower data rates that:

1. Exchange a set of measurements (e.g. vehicle location coordinates, air pollution or meteoroidal measurements, liquids or chemical levels or level variations in a tank, a building’s alarm system status, or a person’s health monitoring data),
2. Are able to receive commands (e.g. “turn on heating in apartment number 5 – start in 10 minutes and keep max temperature below 70^oF), and
3. May allow remote access via an HTML page.

From a compression point of view, this type of data resembles the characteristics of the simple text files, spreadsheets, and web files that office workers and engineers compress every day. It is typically highly compressible, with compression ratios in the range of 3:1 from lossless compression algorithms such as GZIP being common (see several examples in [2]).

With less data to transmit after compression, the active time of the RF subsystem in our IoT device will be shorter. How much energy can this save? Consider:

• Typical low-power RF subsystems consume 10-30mA while active, and a few uA while asleep [3].
• A typical low-power IoT device microcontroller managing the RF subsystem will consume a few hundreds of uA when active and less than 1 uA while asleep.
• A GZIP accelerator configured to operate at 1Mbps consumes a few tens of uW while active and practically nothing in sleep mode (assuming the supply voltage is off).

We can apply this sample power data to our architectural template to estimate the potential energy savings compression makes possible. For this, we will assume an RF transceiver with 30mW active and 2 mW idle power, an MCU with 2mW active and 0.3uW Idle power, and a GZIP accelerator with the characteristics of Table 1. 

The consumed energy (power over time) will depend on the device duty cycle (i.e., the percentage of time the device is active) and obviously on the compression ratio. Table 2 shows the power usage for our example IoT device with and without compression, under the quite conservative assumption of a 2:1 compression ratio.

From this we can see that significant energy savings can be gained by compressing the data to be transmitted even in cases where the IoT device duty cycle is as low as 1 sec/hour (which means the device is active 0.028% of the time).

Conclusions

In this paper we have considered the case of adding a compression accelerator to the typical IoT node architecture, in order to minimize the energy consumed for data exchange over a wireless network. Compression clearly helps reduce the active time of the RF transceiver, which typically consumes relatively large amounts of energy while active.

The energy savings will depend on the compression levels achieved (which in turn depend on compression algorithm), the exact power consumption characteristics of the device, and its duty cycle.

However, using typical characterization data and rather pessimistic compression levels, we have seen that adding a compression accelerator can result to significant energy savings, even for devices with duty cycles bellow 0.1% (or 1 sec per hour).

[1] ZipAccel-C GZIP/ZLIB/Deflate Data Compression Core

[2] The Canterbury Corpus Web page (http://corpus.canterbury.ac.nz/)

[3] Designer’s Guide to LPRG, Texas Instruments http://www.ti.com/lit/sg/slya020a/slya020a.pdf)