When reading about the Internet of Things you have probably come across a wide range of increasingly unfamiliar names for different ways in which a device can communicate to you the data it is collecting. The goal of this article is to give you an overview of the protocols that are available and the trade-offs they make, to help you understand which one is the best for your use case.
Usually the end goal with an IoT device is to collect some data and upload it to the cloud so that it can be visualized and analyzed remotely. This goal can be achieved in two ways:
- single hop: the device is directly connected to the internet and sends the data straight to the cloud (e.g. Wi-Fi and cellular connections)
- multi hop: the device is connected to another gateway which will relay the data to the internet (e.g. LoRaWAN and Sigfox)
A key distinction between different systems is how far the gateway is from the device, for example a smartwatch can connect via bluetooth to a phone only if they are at most 10 meters apart, on the other hand a LoRaWAN gateway can be 10 kilometers apart from the device.
A second differentiating factor between protocols is the speed of transmission, meaning how much data the device can upload (throughput) and how much delay there is between measurement and upload (latency). In general Wi-Fi and cellular connections give the highest throughput and lowest latency, while low-power protocols (e.g. Bluetooth and Zigbee) provide low throughput and some have high latency.
Guaranteeing that all the data uploaded by the device actually reaches the cloud constrains the speed of the protocol, for this reason if you are fine with losing a measurement once in a while you may want to use an unreliable but fast protocol such as CoAP.
As a rule of thumb if you want more speed, more range or more reliability you will need more power. The following table summarizes the trade-offs that the most popular protocols make:
When designing a new IoT product you should consider what are your constraints in terms of power, range and speed to determine a shortlist of the protocols you could use. The final choice will then come down to compatibility with existing solutions, the experience of your team with different protocols and the technical details of each solution.