Which IoT Communication Protocols Are Best Suited to Your Design Requirements

For IoT products, the interoperability question depends on the communications protocol you use, since most products can’t communicate with systems using a different protocol. The protocol you choose will also affect your hardware. For example, transmission distance will determine your available IoT modules, power requirements, and shape the network configuration for your system. There are a huge number of protocols to choose from. New versions are coming out every year, and groups are trying to consolidate the options that already exist. How do you decide which one is right for your product?

Designing an IoT product is a little bit like buying a new laptop. You’ll end up with a lot of things to consider, like speed, cost, functionality, and interoperability. One or two will probably end up most important, and then you do your best to optimize the rest. In my case, I used Linux machines exclusively for a couple years, but the limited interoperability when I needed to share Microsoft files was brutal. Eventually, I gave in and set up my computers as dual-boot with Windows.

Whether you want open-source or proprietary, interoperability is key for most systems.

For IoT products, the interoperability question depends on the communications protocol you use, since most products can’t communicate with systems using a different protocol. The protocol you choose will also affect your hardware. For example, transmission distance will determine your available IoT modules, power requirements, and shape the network configuration for your system.

How to Choose a protocol

There are a huge number of protocols to choose from. New versions are coming out every year, and groups are trying to consolidate the options that already exist. How do you decide which one is right for your product?

The quest for a universal standard creates chaos of its own - even for emojis!

As you start stressing out about all the options you need to consider, I’d like to share some advice. I wish I’d been able to read this before my first IoT design: “Bottom line, there’s not a standard that’s so prolific or significant that you’re making a mistake by not using it.” (The emphasized text is from me.)

1. Identify your priorities

In IoT Central’s 2017 survey on developer trends, they found the top IoT protocols, the main concerns are security and interoperability. You should be addressing security at every level of your product design, from the physical PCB to the storage of user data. Interoperability is a little more simple. By choosing the right protocol, you can maximize the IoT ecosystems that your product can play in.

2. Know your jargon

Because there are so many players in the IoT protocols space, the terminology is a mess. Even the meaning of a data protocol versus a communications protocol varies by industry, and sometimes even by company. There’s a nice overview here but double check on terminology before you commit yourself to anything.

The most commonly used protocols

The protocols that are the “Windows” or “Mac” of the IoT world generally existed before IoT was really proliferating. For example, Bluetooth, Wifi, cellular, and near field communication. Familiarity has given them a foothold for interoperability at the cost of not being optimized for IoT applications.

Bluetooth

Frequency: 2.4 GHz, frequency hopping.

Range: Medium (≤100 meters)

Cloud Access: Easy (Bluetooth 4.2 added IPv6 routing so some modules can have direct internet access.)

Bluetooth is generally used for “personal area networks.” It’s seen increased adoption over the last three years, including several new versions and message formats.

Bluetooth Low Energy (BLE) is specifically optimized for IoT devices with improved power requirements from adjusting the message format, size, and transmission time, at a cost of shorter range (down to 50 m). The networking is also improved with the addition of CSR Mesh.

Cellular

Frequency: GPRS, 2G, 3G, and 4G vary by region and carrier

Range: Long range (15-35 km)

Cloud Access: Easy

Cellular communication provides long range transmission with direct access to the cloud, but at the cost of high power requirements. I’ve also had issues with poor hardware and network support, so I strongly recommend thoroughly vetting your providers.

Near field communications (NFC)

Frequency: 13.56 MHz

Range: Very short (centimeters to meters)

Cloud Access: Medium - you’ll need a bridge from your tags or modules to the internet.

NFC is actually another set of communication standards. It comes in passive, and battery assisted passive forms. The farthest range is possible with devices and shortest with passive systems.

It’s considered a Bluetooth alternative that uses less power and doesn’t require pairing. Some NFC standards are compatible with RFID, so it’s a popular choice for inventory management products.

Wifi

Frequency: 2.4 GHz

Range: Medium (40-90m, depending on environment and standard)

Cloud Access: Easy, you can talk to the internet since it’s an internet protocol-based standard.

Wifi is the most popular protocol using IEEE’s 802.11 standards. It’s easy to use, very compatible with other products, and high bandwidth. Wifi requires high power consumption, but the latest standard IEEE 802.11 AH is intended to decrease power requirements and increase range. This makes it perfect for IoT applications.

There are also options like WeMo, which isn’t its own protocol, but instead, piggybacks on existing WiFi networks.

Emerging Leaders in the protocol battles

Some newer protocols are starting to overtake the incumbents. Being designed specifically for IoT applications gives these protocols advantages in performance, and we’re likely to see increasing usage in the next few years.

Thread

Frequency: 2.4 GHz

Range: Short (10-30m)

Cloud Access: Medium - You’ll still need a bridge, but 6LoWPAN makes it easier to use IPv6 internet protocols.

Thread is Google’s baby, hatched by Nest. Usage hasn’t grown as fast as predicted a couple years ago, but Thread is almost always considered in the top contenders for smart homes. Thread can also be used on Zigbee radios to give them cloud access through IPv6 support.

Zigbee

Frequency: 915 MHz, 2.4 GHz

Range: Short (10-20 m)

Cloud Access: Medium - requires a bridge

A low power, IoT-centric protocol, Zigbee can use 128 bit AES encryption.

Zigbee is used by a number of manufacturers, largely because there are multiple sources of suppliers. Zigbee is also well-established in mesh networking, although I’ve heard some sad stories of poorly designed meshes and failed product integrations. Make sure your Zigbee profiles all match and your mesh is designed to be robust.

Z-Wave

Frequency: 908/916 MHz (U.S.) Because Z-Wave uses the ISM band, the frequency varies by country.

Range: Medium (100 m)

Cloud Access: Medium - requires a bridge

Z-Wave and Zigbee are neck and neck with each other. Z-Wave is frequently selected because the ISM band it uses is less crowded than the 2.4 GHz band, and thus is less prone to interference. The downside is that Z-Wave has a slower transmission rate, and devices can’t be used outside their “home” region. Z-Wave also has the option of 128 bit AES encryption.

Radios are single source and are usually higher priced as a result.

New and interesting protocols

There is a morass of new protocols trying to establish themselves. From an interoperability standpoint, most of them aren’t mature or widespread enough to consider. However, a few are starting to get make some progress.

AllJoyn

Frequency: Varies - AllJoyn transports on Wifi, ethernet, and serial.

Range: Varies - AllJoyn works on a range of platforms, so the range is hardware dependent.

Cloud Access: Medium - requires a bridge, or can function as a standalone network.

Started by Qualcomm, AllJoyn is now open source and runs on Windows, iOS, OSx, Ubuntu, and Android platforms. It’s not widely adopted, but it’s one of the most interesting approaches I’ve seen.

EnOcean

Frequency: 902 MHz (U.S. and Canada), 2.4 GHz

Range: Medium (30 m range inside, up to 300m outside)

Cloud Access: Medium - requires a bridge

EnOcean is an energy harvesting protocol that allows for wireless interfaces to be self-powered. It’s low frequency and low bandwidth, but provides a really unique use-case that’s also compatible with Zigbee and BLE.

ANT

Frequency: 2.4 GHz

Range: Short (100 m)

Cloud Access: Needs a bridge

Frequently compared to BLE, ANT is focused on sensor networks in which each node can transmit and receive messages.

Interoperability between all the components of an IoT system needs careful requirements management.

Because there are so many options available for an IoT communications protocol, it’s important to identify your product requirements first. I strongly urge you to consider the interoperability of your system with other systems in the IoT ecosystem. It is a particularly vexing parameter because the landscape is changing quickly, and it’s a critical enabler for many IoT applications. Like knowing what you’d need a new laptop to do, understanding the needs of your IoT system will make it easier to answer the design questions you’re facing.

The best way to keep your requirement management consistent and simple is with good tools, such as Design Data Management in Altium Vault^®. By tracking changes, and checking components against your requirements, can help you ensure interoperability within your system and in your product ecosystem. Contact an Altium sales representative to get started today!