Thingstream data and low-power IoT efficiency

4 mins read

LPWA (Low Power Wide Area) networks, such as Thingstream, allow low-power IoT devices to connect and communicate efficiently and effectively over large distances with minimal cost in terms of power. These networks are designed for sending small payloads such as information from sensors, alerts and status updates. For many remote devices, low-power is essential for preserving battery life and with the number of devices expected to rise exponentially, the environmental impact also needs to be considered.

To find out what low-power IoT really means, Thingstream CTO, Bruce Jackson puts Thingstream’s low-power IoT claims to the test.

Thingstream Low-power IoT Introduction

Thingstream is a service designed to provide connectivity for low-power IoT devices using the industry-standard MQTT-SN protocol across various cellular network technologies and bearers.

Like other end to end communications systems, Thingstream’s low-power IoT solution is built upon a series of layers from the cellular radio access network up to the data transmission protocol. This layering is shown in the diagram below:

thingstream communications layers

The protocols and embedded network integration used by Thingstream deliver a secure service that is highly optimised for both power and data efficiency.

A common question that arises is how Thingstream compares with other low-power IoT solutions that use alternative protocols or implement them in different ways across cellular networks. This paper provides some side by side test results comparing:

  • Thingstream over USSD (for 2G networks)
  • Thingstream over LTE Cat-1 (for LTE networks)
  • HTTP over LTE Cat-1
  • HTTPS over LTE Cat-1

The communication layers for HTTP/HTTPS are shown below:

HTTP HTTPS communication layers

For all of these test cases, we look at both the power efficiency (how much power it takes to perform a typical operation) and data efficiency (how much overhead is introduced in sending a given message payload).

Test setup and methodology

In designing the tests we have tried to model cases that both reflect the real-world use we have seen in customers and also scenarios that are comparable across different technologies.

Hardware

For all tests we have used the same hardware platform, shown below:

thingstream frankenbutton iot button

The “Frankenbutton” is a custom hardware platform based around the NXP LPC824 microcontroller, and used in the Thingstream Test button modified to remove the SIMCOM 868 cellular modem and to allow connection to alternative external modems.

This hardware was chosen because it allows us to write tests that run “close to the metal” – the Frankenbutton hardware has no operating system or task scheduler, and therefore the code has complete control over the hardware and it is simpler to normalise out the power used by the microcontroller compared to the modem.

The cellular modem used for testing is a u-blox LARA-R211 module. This module allows us to control the radio access technology used for the tests and to swap protocols with relative ease from the same software base.

Measurements

Power measurements were taken for the complete system via a Keithley 2280S connected to a PC to capture data, and using a combination of nginx and tshark to monitor and measure network traffic.

Tests

As mentioned previously, the tests were built around the most common scenario we see in customers in the real world, namely a device sending a small payload of data to a remote system. Therefore, the tests all use the same sample payload (in this case the 12-byte string “Hello World!”) encoded appropriately for each protocol as shown in the table below:

Bearer/protocolTransfer method
Thingstream 2G/USSDMQTT-SN PUBLISH at QoS -1*
Thingstream LTE Cat-1/UDPMQTT-SN PUBLISH at QoS -1*
HTTP/LTE Cat-1HTTP POST
HTTPS/LTE Cat-1HTTPS POST

* QoS -1 = MQTT QoS (quality of service) level -1

It is obviously possible to choose other protocols for comparison with Thingstream, including MQTT over LTE Cat-1. However, it is possible to extrapolate from the HTTP tests where these will fall relative to the tests we have conducted.

Furthermore, it should be noted that the HTTP/LTE Cat-1 test is not strictly a like-for-like test. Thingstream provides an end-to-end security model through integration at the network core level. The device is authenticated by the SIM card and data is not exposed at any point outside a secure encrypted private network. The HTTP test does NOT do this: it is a POST of data in the raw with no form of authentication of the device or encrypting of data.

Results

Power / current tests

For power tests, we measured the current drawn by the test hardware (the Frankenbutton and external modem module) over time. During this period, the test software performed:

A boot sequence to setup hardware and UART interface configuration
Power up the modem and attach to a network
Send a message using the selected protocol and bearer
Shutdown the modem

The results of the tests are shown in the chart below:

power efficiency thingstream LTE UDP

From this, it can immediately be seen that both of the Thingstream test cases (the yellow and red lines) draw less current than the HTTP-based cases, and for Thingstream over USSD, is also “on air” for a shorter period of time.

In the following chart, we sum the current consumption data over time and then normalise this against the lowest value (in this case Thingstream over USSD) to obtain relative results for a single message transfer:

thingstream low power test results

Numerically, this same data is shown in the table below:

Bearer/protocolRelative power consumption
Thingstream 2G/USSD1.0
Thingstream LTE Cat-1/UDP1.21
HTTP/LTE Cat-11.81
HTTPS/LTE Cat-12.05

Data tests

The second factor that was tested was the efficiency of a given protocol when sending a message from a device to a remote system. In other words: how much does the protocol ‘inflate’ the message payload to perform the task required.

The efficiency is important for two reasons:

  • the overhead introduced by a given protocol will impact on the power consumed to send a message
  • a typical data plan for cellular communication provides an allowance in bytes for a given price (for example €1 for 10Mb). If a protocol is highly inflationary, then the data allowance will be taken up by the overhead and not the payload (where the actual value lies)

The table below shows the total bytes transferred between the device and the remote system over the cellular network for the “Hello World!” test message payload:

Bearer/protocolPayload (bytes)Total transferred (bytes)Inflation factor
Thingstream 2G/USSD12262.17
Thingstream LTE Cat-1/UDP12342.83
HTTP/LTE Cat-112103486.17
HTTPS/LTE Cat-1125676473

This same data is shown in the chart below:

bytes transferred low power

Conclusions

In real-world scenarios, Thingstream outperforms other low-power IoT solutions by a significant margin both in terms of power and also efficiency/cost.

Thingstream uses less than half the power of HTTPS (which while secure, introduces other management overheads) and is many orders of magnitude more efficient over the air.

While Thingstream on USSD uses less power than UDP, it is not significantly different. Our client SDK will automatically select the best bearer based on power and coverage concerns, thus allowing customers to choose a single solution and know that it is optimised for power and performance while providing coverage across all 2G, 3G and LTE network, thus future proofing the investment in technology.

For more information on how Thingstream low-power IoT devices can bring value to your business, get in touch.

Globally connect your business

Get in touch with Thingstream to bring global IoT connectivity to your devices.

Get started