Is it a choice between losing some data packs or extending the battery life by about 30% or there are some more points to consider?
Several technologies and hardware systems have to function with millisecond latency from the time we hit go on an address bar to the time we see any website on the internet. Everything seems effortlessly smooth due to the number of innovations and breakthroughs in networking from the day the World Wide Web went public in April 1993. But in the internet's early days, everything was painfully slow. The fastest modem available was capable of 14.4kbps.
But why the history lesson, one might ask? The max speed of an NB-IoT device is roughly 100kbps and averages at about 20-50kbps. This may seem slow by today's internet standards, but that bandwidth is usually suitable for IoT devices transmitting a few bytes of data.
TCP and UDP are the major transport layer protocols predominantly used across the internet for various scenarios. TCP is a more complicated protocol that comes with many advantages one of which is ensuring that data is transmitted to the recipient. UDP is a simpler data-transmission protocol with a high throughput but doesn't guarantee all the packets reach the destination. When there is no bandwidth constraint, TCP is the preferred choice as it ensures reliable data transmission at the protocol level but for bandwidth-constrained applications like a sensor transmitting on NB-IoT, we cannot simply waste the few seconds it takes for the TCP handshake as the battery consumption by a modem during transmissions is very high.
The inherent issues with UDP, like lost or corrupted packets, aren't nearly as big of a concern in recent days as the underlying network NB-IoT uses is LTE which is the same as your smartphone but on limited bandwidth.
If there are no issues with UDP and it is better than TCP, why are we even discussing a comparison instead of using it everywhere?
Because nothing is as simple as it looks from the outside, UDP doesn't have standardised encryption during a transit like TLS, so we must implement symmetric or asymmetric encryption with keys loaded on the device. Even if the underlying network is LTE, the rate of errors is not zero so error detection mechanisms like CRC are needed. Even with all these complexities added, the bandwidth savings advantages are far superior to TCP.
Let's talk about numbers,
When transmitting a standard CBOR packet via UDP with encryption and CRC, the bandwidth consumption reported by our network provider is 396 bytes.
The same packet transmitted as JSON via MQTT a popular IoT transmission mechanism on top of TCP is 6-8KB
You can say it's unfair to compare MQTT, a heavy application layer implementation on TCP, with UDP and a simple custom application. MQTT is the choice of a communication mechanism for Azure IoT Hub, AWS IoT Core, Cumulocity and many more popular IoT platforms. So, instead of a simple HTTP request, we chose to use that for comparison, and from past customer and sales experience, we felt it ideal to compare these two.
During the Covid, we were sharing another advantage of UDP with our partners and clients, which is not the case for post-covid: UDP doesn't handshake !!!
The advantage of MQTT is that it is a stateful implementation with its own mechanism to ensure data is transmitted properly with QOS 0,1 and 2. This is on top of the assurances provided by TCP. Once a connection is established, it stays alive and subsequent transmissions do not consume as much data but for devices transmitting every once in a while, the overhead may be high.
Which one to choose?
MQTT on TCP | UDP |
If your platform of choice only supports MQTT | If your platform of choice has the option of UDP with proper encryption, always choose UDP |
Depending upon the device and platform used, it doesn't need a payload decoder | Needs custom payload decoders to decrypt and convert data |
Preferred choice when using Cat-M1 | Preferred choice when using Cat-NB / NB IoT |
If you application needs to keep a connection always open to transfer important information instantly (Switches and other actuators) | If your applications needs to receive data occasionally and missing a data point is not mission critical |
Battery life is not critical or you have access to power source | You have battery operated device in the middle of nowhere and every single transmission is matter |
Ellenex devices support MQTT and UDP, and we configure our devices based on the customer's requirements. Still, we internally always prefer UDP transmissions when connected to our platform as it is the most efficient data transmission method in terms of battery life and bandwidth consumption.
If you want to learn more about the OSI stack and how devices on the internet communicate, here is a good explainer by Cloudflare about the OSI model.
If this all feels complicated, our client growth experts are always available to discuss more about your application and suggest the best possible choice. Please feel free to email us at sales@ellenex.com or use the contact us page.