One thing is for certain when it comes to designing an IoT (Internet of Things) device; it won't be standalone. Unlike the way most traditional embedded devices have been developed in the past, such as the old-style digital thermostat I have in my hallway, IoT devices will always feature some form of communication. In the majority of cases, this will be wireless-based, and the key determining factors in the selection of the way it will communicate will be the required range, the amount of data to be transferred, and the available power budget.
Thus, embedded developers will now find themselves needing to delve into the world of communication protocols, standards, and wireless specifications. Understanding wireless design is a specialist subject in itself; thankfully, the availability of a range of pre-certified, type-approved wireless modules greatly simplifies the task.
The first step in determining which protocol to use for your IoT device is to take a step back and review the OSI 7-layer model. Getting the terminology right and using this model as a way of understanding which protocol method fits where can help. Appreciating the role of the different layers (e.g., physical, transport, network) and their correlation to the task at hand (e.g., communications, data exchange, device management) helps to put everything into context.
At the physical and data layers, protocols such as Wi-Fi (802.11) and cellular 3G & LTE are good examples. Ethernet dominates the wired world, and Wi-Fi is the prime candidate for transferring large amounts of data. For the latter, the catch is that this is somewhat power-hungry for always-on operation from a battery-powered device. Bluetooth low energy (BLE) is a viable candidate for lower data rates and power budgets; however, BLE's range is a restriction, typically limited to reliable free-space operation of around 30 meters. Longer range alternatives include cellular 3G and 4G networks where the data rates are fast approaching Wi-Fi speeds. Also of interest is the recently-announced, much lower speed, Narrow Band IoT protocol (NB-IoT), which is the result of cellular industry collaboration and the 3GPP working group. Competing against NB-IoT in the unlicensed industrial, scientific, and medical frequency spectrum of 858 / 915 MHz are low power, are low data rate offerings SigFox and LoRa. Z-Wave is another candidate operating in this spectrum, although its quoted range is significantly less than others.
It is the transport layer where we find TCP and UDP as two protocols. TCP is the default, but some embedded applications are starting to use the UDP protocol because it doesn't have as much package overhead as TCP.
The main focus as to which protocol to use is typically about the data protocol, this being at the application layer. There are many choices, several of which are establishing themselves as being increasingly popular. These include CoAP and MQTT, together with the web methods of XMPP and RESTful HTTP. The constrained application protocol (CoAP), which was brought to life by the Internet Engineering Task Force (IETF), was designed from the ground up for use in low-power devices that have limited compute resources. CoAP is based on a request/response model, offers reasonable security, and uses the UDP protocol, thereby making it very lightweight in use.
Also designed as a lightweight protocol for resource constrained devices, MQTT uses a publish and subscribe model, and is well suited for use in low-bandwidth, high-latency networks. Aimed at large volume deployments of sensors and devices that can be monitored from cloud-based applications, MQTT is extremely bandwidth efficient and requires very little code space.
Recent multi-framework protocols gaining adoption from the likes of Google include Thread. The Thread specification features its own physical layer, but retains compatibility with 802.15.4 by using existing wireless modules and transceiver. Developed as a low power open IPv6 protocol, Thread's core aim is to ensure connectivity across myriad devices by using mesh techniques to prevent a single point of failure.
Choosing the desired protocols for your IoT application requires careful thought, starting with a review of the operating requirements. With many different choices being available, having a clear indication of the operating criteria of the IoT device will help narrow down the selection process.
Rudy Ramos is the project manager for the Technical Content Marketing team at Mouser Electronics. Rudy holds an MBA from Keller Graduate School of Management. He has over 30 years of professional, technical, and managerial experience managing complex, time-critical projects and programs in various industries, including semiconductor, marketing, manufacturing, and the military. Previously, Rudy worked for National Semiconductor, Texas Instruments, and his entrepreneur silk-screening business.