How to Reduce IoT Communication Protocol Overhead
Written by: Steve Hardy
Published: July 5, 2023
In the realm of IoT, three key elements—devices, networks, and cloud— require careful technology selection. This leads many to look to experts, like Soracom, before launching their own IoT solution.
One of the most commonly asked questions around IoT networking is about which communication protocol should be used. T Selecting the right protocol for communication between IoT devices and the cloud or on-premise systems can be a confusing process for many, but thankfully, it doesn’t have to be.
In this blog post, we aim to address this question by measuring the communication volume of the various protocols that may be under consideration, examining their features, and introducing effective strategies for reducing communication volume using Soracom.
Types and Features of Communication Protocols That Can Be Used in IoT
As its name suggests, IoT is a mechanism that runs on the Internet, which means it can handle IP-based protocols. The table below lists the protocols that are commonly used by IoT developers and their characteristics:
| Communication Protocol | Protocol Overview |
| HTTP/HTTPS | Very common in application layer protocols in the TCP/IP model.A protocol in which a request from a client (typically a device in IoT) is the starting point, and a response is exchanged from the server.Easy to implement because it is “stateless” with a question-and-answer format, though does involve some overhead to establish a connection with each attempt. There are methods to reduce overhead, such as KeepAlive, but this also requires corresponding client-side implementation.When communication is encrypted by TLS (SSL), it is called HTTPS. |
| TCP/TCPS (TLS) | A transport layer protocol that is a layer lower than HTTP. Highly reliable communication is possible by establishing a 3-way handshake and retransmission processing.In order to actually perform transmission and reception, a unique protocol design is required in the upper application layer.Like HTTPS, when encrypted by TLS, it is called TCPS. |
| UDP/DTLS | A transport layer protocol similar to TCP.Although it does not have a reliability improvement mechanism (i.e. the 3-way handshake), it specializes in transmitting data with low delay and high efficiency even if there are some defects, such as stream audio. As with TCP, protocol implementation in the application layer is required.When encrypted by TLS, it is called DTLS. |
| MQTT/MQTTS | A protocol that operates at the application layer.Whereas HTTP is always client-originated and stateless, MQTT establishes a connection between the client and server in advance (stateful). Using this connection, data transmissions originating from both the client and server (called two-way communication) is possible. Because the already established connection is reused for sending and receiving data, the amount of communication tends to be smaller than that of HTTP.When encrypted by TLS, it is called MQTTS. |
Understanding Communication Overhead Due to Protocol Differences and TLS
Different protocols use different methods to send and receive data. For instance, when transmitting the two-digit number “25,” the total data volume varies depending on the protocol. While using TLS ensures data protection through encryption straight from the device, it introduces additional overhead, such as exchanging key information. To illustrate this, we have performed several tests below.
Introduction to the Testing Environment
The architecture used for these tests is as follows:
Firstly, we set up a server (Amazon API Gateway, referred to as “API Gateway”) in the cloud, configured to listen over HTTPS. This API Gateway is then configured to invoke AWS Lambda.
For our benchmark, we employed four different communication protocols. The common aspect among them is the use of Soracom Air SIM cards for LTE communication.
One method involved direct HTTPS communication from the device, while the other three utilized Soracom Beam, a data transfer service, to convert HTTP, TCP, and UDP data into TLS-enabled protocols.
For measurement purposes, we employed Soracom Peek, Soracom’s on-demand packet capture service.
Communication Benchmark Results and Strategies for Reducing Communication Volume
For these tests, curl and nc (netcat) were used to generate the communication for each protocol. The 18-byte message used in each test was {"test": "message"}.
1. Direct Communication via HTTPS (HTTP+TLS)
Below is a packet capture of HTTPS communication with encryption. In this test, communication is performed using HTTP 2.0/TLSv1.2. The data was sent with the following command:
curl -X POST https://***.execute-api.***.amazonaws.com/dev/benchmark -H 'Content-Type: application/json' -d '{"test":"message"}'Code language: JavaScript (javascript)
If you are unfamiliar with the Wireshark GUI used to analyze these packets, each line represents one packet, and the leftmost line is the capture number. The packets are arranged chronologically from top to bottom, and while some of the packets in this capture are not related to this case, the gray and light purple lines are the ones to pay attention to.
First, a 3-way handshake (capture lines 8, 9, and 11) is performed to initiate communication. A key exchange for TLS (capture line 20) is also performed to start encryption. Then, in capture line 30, the data {"test": "message"} is sent, but since it is encrypted, it only appears to Wireshark as “Application Data.”
Communicating this way means that each time data is sent, a 3-way handshake and TLS key exchange occur again, resulting in another 2 to 3 KB of data being used. Of course, there are ways to avoid this, such as reusing the connection with KeepAlive or resuming the previous TLS session. Unfortunately, it is necessary to implement these solutions not only on the server side but also on the client side, which may present some challenges. KeepAlive can be easily configured with Linux but may require advanced custom implementation when using microcontrollers such as Arduino, and is not available on all devices.
2. HTTP with Soracom Beam
Below is a packet capture of non-encrypted HTTP communication. In this test, we are communicating over HTTP 1.1.
The test was performed using the following command – note that the destination is not the API Gateway, but instead Soracom Beam.
curl -X POST http://beam.soracom.io:8888/dev/benchmark -H 'Content-Type: application/json' -d '{"test":"message"}'Code language: JavaScript (javascript)
As with HTTPS, the communication starts with a 3-way handshake (capture lines 5, 6, and 7), and since there is no TLS key exchange, data is sent immediately after the communication starts in line 8. The server then returns a 402-byte response at line 10.
3. TCP with Soracom Beam
Below is a packet capture of TCP communication. The following command was used for the test, which once again targets Beam:
nc beam.soracom.io 23080
{"test":"message"}Code language: JavaScript (javascript)
At first glance, there is not much difference from the HTTP packet capture. Communication is initiated with a 3-way handshake (capture lines 5, 6, and 7), and data is sent at line 8.
What is noteworthy, however, is what happens after that: the server sends a TCP response of about 180 bytes, roughly half the size of the HTTP response in the previous test. This may only be a difference of a few bytes, but the impact can be considerable when scaled to tens of thousands or millions of IoT devices.
4. UDP with Soracom Beam
Below is a packet capture of UDP communication. The following command was used for the test, targeting Beam again:
nc -u beam.soracom.io 23080<br>{"test":"message"}Code language: JavaScript (javascript)
UDP does not require the 3-way handshake used in previous TCP-based communications. Data transmission (capture line 5) is performed immediately and uses only 61 bytes. The response from the server in capture line 6 is also small (96 bytes), making UDP the most data-efficient protocol used in our testing.
Communication Volume Comparison
Let’s look at the total communication volume from the packet capture results:
We can see that HTTPS communication, which takes advantage of TLS security, uses the most data by a wide margin, though by utilizing HTTP/TCP/UDP communication, the amount of data used decreases the simpler the protocol gets.
Although we did not test MQTT or MQTTS above, it is worth noting that MQTTS (MQTT+TLS) has the same key exchange overhead as HTTPS. On the other hand, unlike HTTPS, MQTT continues to use the connection once established, so the overhead of subsequent communication is almost negligible.
Is Device-Level Encryption Necessary?
IoT is a mechanism in which devices and the cloud cooperate with each other. Therefore, there is a possibility that communications via the Internet will inevitably occur, so it is not wrong to ask: “Is it essential to implement encryption for IoT devices?”
On one hand, device-side encryption may be required by certain businesses, for example, when complying with the PCI Data Security Standard (PCI DSS), which is a standard for handling and protecting information such as credit card information.
On the other hand, our testing shows that TLS encryption creates significant communication overhead. This affects communication volume and rates, increases the man-hours required for implementation on the IoT device, and adds the operational burden of replacing certificates. Data size is also proportional to the power consumption of the communication module (modem), i.e. the larger the data size, the more power is consumed, something that is especially applicable to battery-powered devices.
If you determine that device-side encryption is not necessary for your IoT business requirements, you can use Soracom application services such as Soracom Beam to add encryption between Soracom’s servers and the cloud, allowing you to take advantage of less data-consuming unencrypted protocols.
Conclusion
Selecting the appropriate IoT communication protocol is crucial for efficient and effective data transmission between devices and the cloud. Understanding the characteristics and overhead of different protocols, as well as considering strategies to reduce communication volume, can greatly enhance the performance and scalability of IoT systems.
By leveraging the expertise of Soracom and utilizing technologies like Soracom Beam, you can make informed decisions and implement best practices to optimize IoT communication protocols, ultimately improving the overall efficiency and reliability of your IoT deployments.
………………
Got any questions about an IoT deployment? Soracom offers a number of powerful solutions that have made us a visionary in the IoT space. Chat with us today to learn how a partnership with Soracom can get your project up and running easily and securely. Contact us today!
