Which IoT protocol should you use for your design?

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.

8 thoughts on “Which IoT protocol should you use for your design?

  1. “My belief is that for security reasons a proprietary protocol, while maybe more work, is best. Remember, a hacker can't hack what they don't understand. Standard protocols could be dangerous, and are obviously more susceptible to being hacked. “

    Log in to Reply
  2. “My experience has been that the standards introduce too much overhead to be used “all the way down to the things”. I think protocols such as CoAP and MQTT are best kept up on the Gateways and Edge Routers, and use smaller, more efficient protocols betwe

    Log in to Reply
  3. “The recent DDoS attacks show that standards can open things up for large scale attacks. Picking the right proprietary protocol/platform also gives you the flexibility to tailor the network a bit more to your application. The low-power and complex connect

    Log in to Reply
  4. “Yep! Stick with what best works at each layer and type of interaction rather than forcing one end-to-end mechanism that is generic.nThat is after all how the internet works :)”

    Log in to Reply
  5. “I applaud your sarcasm, and observe with concern that people actually got taken in. Security by obscurity never works in the long term; just about the only thing you can call for the proprietary protocols is that they fragment the space, and may make your

    Log in to Reply
  6. “I find this quite loose, more a marketing white paper than a technical article.nWhat is an “IoT protocol” anyway ? Or even a protocol stack ?nFurthermore, you can't compare apples to oranges, and CoAP and MQTT are apples and oranges.nFirst of all you

    Log in to Reply
  7. “I think the recent DDoS attacks had more to do with default user name and passwords still in place (because the owners didn't know or didn't realise what they had to do to secure their newly bought stuff) than with one or another protocol used.nnI perso

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.