Putting Thingstream data and power efficiency to the test
LPWA (Low Power Wide Area) networks, such as Thingstream, allow IoT devices to connect and communicate efficiently and effectively over large distances with minimal cost…
LPWA (Low Power Wide Area) networks, such as Thingstream, allow 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. In this article, Thingstream CTO, Bruce Jackson puts Thingstream’s low-power claims to the test.
Like other end to end communications systems, Thingstream 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:
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 solutions that use alternative protocols or implement them in different ways across cellular networks. This paper provides some side by side test results comparing:
The communication layers for HTTP/HTTPS are shown below:
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).
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.
For all tests we have used the same hardware platform, shown below:
The “Frankenbutton” is a custom hardware platform based around the NXP LPC824 microcontroller, and used in the Thingstream Test button (more details at https://thingstream.io/product/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 (see https://www.u-blox.com/en/product/lara-r2-series). 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.
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.
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:
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.
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:
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:
Numerically, this same data is shown in the table below:
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 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:
This same data is shown in the chart below:
In real-world scenarios, Thingstream outperforms other 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.
Ready to get started with Thingstream's IoT Connectivity Platform?