Latest News
May 31, 2017
By Matt Smith, Cortet
As the Internet of Things (IoT) industry continues to expand, new information on emerging best practices, technical specifications and design considerations continues to flood the market.
Here at CEL (California Eastern Laboratories), one of the priorities is helping you navigate through the deluge of information and identify which technology choices will have the biggest positive impact on your upcoming IoT plans.
This post is designed to help your decision-making process by explaining the existing technologies and attempting to demystify the ocean of IoT protocols. It will establish a framework for categorizing the various technologies and explain some criteria on how to compare and evaluate these.
Often, it’s hard to be sure of what items need to be, or even can be, compared to each other. New ideas and protocols are becoming available at a rapid pace and some companies are pushing technologies that aren’t yet ready for prime time. This makes it confusing.
One of the most important decisions you may be facing is which communication protocols to choose. This decision impacts the hardware and what devices and functionality are available. Communication protocols need to be grouped together. Like puzzle pieces, only certain protocols can “connect” to each other.
Communication Protocols You Need to Know
Here’s our list of the most important protocols to keep an eye on. We based this list on multiple factors from our own research, including performance, latency, interoperability as well as current industry adoption levels.
If this list looks daunting, that’s ok. It is just a list. The protocols need to be organized in a way that allows a high-level understanding of the benefits and drawbacks of each.
The next section gives a way to make sense of all of these. In other words, feel free to skip this list and start reading the next paragraph.
A Framework for Organization and Comparison
With a list of critical protocols defined, the next step is to create an effective and efficient way of evaluating and comparing them.
We have organized these protocols into “Protocol Stacks.” A Protocol Stack shows which protocols can build on top of other protocols. Like puzzle pieces, only certain protocols can “connect” to (sit on top of) other protocols.
A Protocol Stack must be used as a whole, so stacks must be compared to each other, rather than comparing separate parts of different stacks.
Much of the confusion around IoT comes from not understanding what can be compared and what protocols can (and must) be paired together. Each Protocol stack consists of a three-layer model, as defined below:
Physical Layer: This layer describes how messages are physically exchanged. It describes what physical medium (cable, wireless) is used, what frequency (for wireless), and message encoding scheme. This is how physical, measured events are translated into bits.
Routing Layer: Now that devices have a way to exchange messages, there needs to be a set of rules for how to get a message from one device to another when the devices aren’t close to each other. This layer explains how devices find each other and work together to get messages to devices that are not within range of the initiating device. The content of the message is unimportant for this layer. This layer focuses on delivery from point A to point B.
Application Layer: This layer explains the content of the messages. How do the bits translate into an action for a device? This layer describes what a “turn the light ON” or “DIM the light to 50%” message looks like. This allows devices to work together to take action and communicate.
The table shown below (courtesy of CEL) is populated with the protocols from our list above and organized into Protocol Stacks.
ZigBee Stack | IP Stack | Thread Stack | Bluetooth Stack | |
App Layer | ZCL | HTTP | Dotdot | GAP / GATT |
Routing Layer | ZigBee Pro ZigBee 3 | IP | Thread 1.1 Thread 2.0 | GAP / BT Mesh Stack |
Physical Layer | 802.15.4 | 802.11 WiFi 802.3 Ethernet | 802.15.4 | BT PHY |
Now that the protocols are organized this way, you can evaluate each Stack’s strengths and weakness and compare them based on project or product requirements.
Sources: This article was adapted from a blog written by Matt Smith, head of Cortet Engineering, Colorado offices.