Head of Development for u-blox Services, Bruce Jackson puts u-blox MQTT Anywhere’s low-power IoT claims to the test to find out what low-power IoT "really" means.
LPWA (low power wide area) networks 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.
Low-power IoT communication – introduction
MQTT Anywhere is an IoT connectivity service by u‑blox designed to provide connectivity for low-power IoT devices using the industry-standard MQTT-SN protocol (MQTT for sensor networks) across various cellular network technologies and bearers. This service is delivered and managed by the Thingstream platform.
Like other end-to-end communications systems, u‑blox’s low-power IoT communication 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:
The protocols and embedded network integration used by MQTT Anywhere deliver a secure service that is highly optimized for both power and data efficiency.
A common question that arises is how MQTT Anywhere compares with other low-power IoT communication providers that use alternative protocols or implement them in different ways across cellular networks. This paper provides some side by side test results comparing:
- MQTT Anywhere over USSD (for 2G networks)
- MQTT Anywhere 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:
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.
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.
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 normalize 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.
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:
|MQTT Anywhere 2G/USSD||MQTT-SN PUBLISH at QoS -1*|
|MQTT Anywhere LTE Cat-1/UDP||MQTT-SN PUBLISH at QoS -1*|
|HTTP/LTE Cat-1||HTTP POST|
|HTTPS/LTE Cat-1||HTTPS POST|
* QoS -1 = MQTT-SN QoS (quality of service) level -1, blind fire-and-forget.
It is obviously possible to choose other protocols for comparison with MQTT Anywhere, 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. u‑blox 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.
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 set up hardware and UART interface configuration
- Power up the modem and attach to a network
- Send a message using the selected protocol and bearer
- Shut down the modem
The results of the tests are shown in the chart below:
From this, it can immediately be seen that both of the MQTT Anywhere test cases (the yellow and red lines) draw less current than the HTTP-based cases, and for MQTT Anywhere 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 normalize this against the lowest value (in this case MQTT Anywhere over USSD) to obtain relative results for a single message transfer:
These same data are shown numerically in the table below:
|Bearer/protocol||Relative power consumption|
|MQTT Anywhere 2G/USSD||1.0|
|MQTT Anywhere LTE Cat-1/UDP||1.21|
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 chart below shows the total bytes transferred between the device and the remote system over the cellular network for the “Hello World!” test message payload:
These same data are shown numerically in the table below:
|Bearer/protocol||Payload (bytes)||Total transferred (bytes)||Inflation factor|
|MQTT Anywhere 2G/USSD||12||26||2.17|
|MQTT Anywhere LTE Cat-1/UDP||12||34||2.83|
MQTT Anywhere Low-power IoT conclusions
In real-world scenarios, MQTT Anywhere outperforms other low-power IoT solutions by a significant margin both in terms of power and also efficiency/cost.
MQTT Anywhere 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 MQTT Anywhere 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 optimized 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 u‑blox low-power IoT Communication-as-a-Service can bring value to your business, get in touch.