IoT Protocols Overview

Abstract:
The advancement of IIoT 4.0 for smart factories, cities and buildings ushers in many exciting
possibilities for improved automation and capabilities. IoT devices are unlocking the great
potential for improved efficiency and improved user experiences. However, there are many
different IoT protocols, network topologies and frequency bands, making IoT an intranet of things
and not an internet of things. Therefore, in order to determine which IoT technology to use in
solving your use case and future proofing your investment, an understanding of the IoT ecosystem
is needed. This is the first in a series of papers describing the different protocols, topologies and
frequency bands used in IoT deployments.

Clint Smith, P.E..

csmith@nextgconnect.com
 Next G Connect

The internet of things (IoT) used in industrial, military, commercial, enterprise or consumer devices is anything but
a simple topic. The vastness of the types of IoT devices, their operating systems, capabilities, methods of
communication, as well as initial and recurring cost in selecting the proper device that meets the use case
requirements challenging.

The advancement of Industrial IoT (IIoT) 4.0 for smart factories, cities and buildings ushers in many exciting
possibilities for improved automation. IoT facilitates the exchange of data between the physical world and a user or
computer application. IoT devices collect and create massive amounts of data as well as exchange that data with
other devices to enable actions to take place based on the data and policy rule sets defined.

IoT devices are found in many places. Some are currently deployed in industrial, transportation, health, smart cities,
smart buildings, energy utilities, security and consumer products. However, the IoT industry is fragmented based on
the plethora of devices and protocols being utilized. The fragmentation of the IoT industry has created an Intranet
of things and not an Internet of things.

Ideally everything should utilize the internet protocol (IP), be open source and use REST commands with a common
API. Unfortunately, reality is quite different and there is no single answer and sometimes your decision was made
based on legacy platforms already in place.

There are numerous sources of information available regarding IoT devices from the internet and vendors all pushing
a particular solution. In fact, the information is so vast and dispersed that making a detailed informed decision is
beyond a challenging task.

However, if you are embarking or have embarked on an IoT path you need to be aware of the various options to pick
from. Although the IoT decision process involves many steps or decision points the first thing that you need to do is
determine your objective and use case. The objective determination is more of a business decision than a technical
one because the business decision should be driving the technical decision. Specifically, defining what your use case
or cases are that you need to solve is critical in the IoT selection process.

Choosing a particular protocol also impacts the efficiency and performance of the IoT solution and with numerous
diverse protocols out there for IoT, it is hard for one to decide which ones to use. To help in the decision process this
paper gives an overview of the protocols available in IoT world. This is the first in a series of papers describing the
various IoT protocols that are prevalent and will focus on identifying the various protocols, frequencies and
topologies that exist. The remaining papers will provide details about each of the various protocols with links to
perform a deeper dive.

Figure 1 is a high-level depiction of an IoT sensor that communicates with a middleware platform to reach the
application as part of the IoT ecosystem. The three different protocol classifications shown in Figure 1 the device,
communication and application protocols. The true demarcation of where one protocol function begins and ends is
dependent upon what your particular use case is.

Sensors Processing Communication Middleware Applications

Communication Application
Device Protocol
Protocol Protocol

Figure 1: IoT Protocol locations

www.nextgconnect.com 1 August 25, 2019

 Next G Connect

There are numerous data link or device protocols used for IoT. Each of the data link protocols is designed to solve a
particular problem and there is currently no single data link protocol that solves everything.

All data links can be classified as either tethered or wireless. Whether the selected data link protocol is tethered or
wireless, it should match the objective for the problem you are trying to solve. If you need mobility, then a data link
protocol providing mobility should be looked into. The mobility protocols available for use involve both licensed and
license exempt spectrum usages. Most, if not all, licensed spectrum data link protocols have monthly recurring costs
and these need to be understood. Also, other data link protocols are closed systems with one hardware vendor or
the protocol is not published.

It is necessary to look into the details of any device and protocol that you are considering. For instance, some data
link protocols are not well suited for software updates, patches or configuration changes. Others utilize a mesh or
star topology as part of the data link protocol where coverage and potential throughput need to be understood.

Then there are different frequencies for the wireless data link protocols. Some are meant for short range low data
speeds using sub GHz frequencies. Others are meant for short range but higher data speeds using ISM frequencies.
Also there are protocols offering long range and low data rates and others with long range and high data rates.

As you can quickly gather there are numerous issues that should be thought about and weighed regarding their
technical and business merits. It’s important to always remember that once you begin using a data link protocol
changing to another will prove difficult and time consuming which both equate to money.

When determining which data link protocol to utilize keep in mind that there are numerous IoT devices and protocols
which have not been commercially successful with limited roll outs resulting in stranded systems.

Therefore Table 1 is a list of most of the IoT Device Protocols that are in use presently. Table 1 has four categories
in it. The first category is the tethered group which includes protocols associated primarily with wired connections.
The second category is listed as wireless and while the remaining two are also wireless, this category fundamentally
covers the device protocols using license exempt frequencies. The third category involves cellular which includes
wireless broadband. The fourth category lists the primary cellular IoT technologies that are used.

If you have not heard of some of the protocols listed in table 1 you are not alone. If you do not know a particular
protocol that is listed, it would be good to possibly investigate it a little more. As always, the devil is in the details
and the table provided is meant to help start culling the options you are trying to figure out for your use case.

www.nextgconnect.com 2 August 25, 2019

 Next G Connect

IoT Device Protocols

8902.3
Tethered
Ethernet IPv4/IPv6 QR Code RS-232 RS-422 RS-485
4-20mA SPI I2C HART Modbus LonTalk
Foundation
Fieldbus ARCNet ProfiNet Fieldbus Profibus CEBus
BPL
BACNet LonWorks X10 IEEE1901 G.hn

Wireless WiFi (WiFi6) BLE Bluetooth ZigBee RFID NFC

6LoWPAN
802.15.4 Zwave Sigfox LoRa LwM2M
(6Lo)
Wireless DASH7
RuBee ANT EnOcean Weightless P
HART (DA7)
WiFi HaLow Ingenu
ISA100 Telensa Nwave Neul
802.ah RPMA
Wi SUN/
NB-Fi
802.15.4g
Cellular GSM CDMA UMTS LTE WiMax Satellite
DECT/ULE-
Cellular IoT Cat 4 Cat 0 LTE Cat M1 LTE NB IoT EC-GSM-IoT ultra low
energy

Note: some protocols include higher OSI layers

Table 1: IoT Device Protocols

To complicate things some of the protocols listed in Table 1 include some higher OSI layers. Furthermore, some of
the IoT device protocols are part of a closed system limiting the use to a particular protocol and or vendor even
though they claim to be an open standard.

Table 2 is a list of some of the IoT communication (session) protocols. Again, as with the device protocol list some
of the protocols listed in Table 2 span multiple OSI layers.

IoT Communication Protocols

XMPP HTTP/REST SNMP SMS HTTP/2 SOAP
CoAP MQTT SMQTT IEEE 1451 AMQP LLAP
Hart-ip IBS DNP3 IEC61850 CANopen DDS
IEC 60870 IEC 61968 IEC 61968 Multispeak SSI ZeroMQ
Websocket IEC61334 UPnP IoTivity DeviceNet IEEE 1905.1
Continua
BACNet Modbus LonWorks Sinec H1 MTConnect
HDP
IEEE P2413 Weave

Note: some protocols include higher OSI layers

Table 2: IoT Communication Protocols

www.nextgconnect.com 3 August 25, 2019

 Next G Connect

In addition to device protocols and session protocols there are application protocols shown in Table 3. Table 3 lists
some of the more prevalent IoT application protocols that are present today.

Application Protocols
Juniper Mist Haystack AllJoyn Thread Tingsquare Mist
EEBus Spine Dotdot 1.0 IoTivity ONVIF KNX
HomeKit Symphony Link MyriaNed Insteon Senet
IoLink Home Pod AWS IoT Google IoT Azure IoT
Home
SmartThings Hub Amazon Echo Google Home Nest
Connect

Table 3: IoT Application Protocols

Besides device, communication and application protocols there are numerous dashboards and OSI layer 7
applications that are available for IoT systems. These dashboard systems are how the user or device manager views
their IoT world from. Therefore, when making a choice of which IoT device or devices to utilize, you need to include
in the decision selection process how you will interface with the devices and system through a management layer.
A key consideration about which dashboard or application you select needs to be based on what your use case is.

Each IoT device protocol and higher layers has a particular network topology it was initially designed for. When
investigating an IoT solution there are numerous types of network topologies that can be used and each with its own
set of unique benefits.

Figure 2 is a high-level depiction of the various network topologies. Some IoT technologies and implementations
scenarios utilize a hybrid approach where there are multiple topologies used in different branches of the system.

www.nextgconnect.com 4 August 25, 2019

 Next G Connect

Monitor/
Monitor/ Sensor Controller
Controller
Sensor Sensor Sensor

(a) Peer to Peer (P2P) Home Run

Topology (b) Linear Bus /Multidrop Topology

Sensor

Monitor/
Controller

Monitor/
Sensor
Controller

Sensor Sensor Sensor

Sensor

(d) Star Topology

(c) Ring Topology/Multidrop

Monitor/
Controller

Sensor Sensor Sensor

Monitor/
Controller
(e) Daisy Chain / Line

Gateway Gateway Sensor Sensor

Sensor Sensor Sensor Sensor Sensor Sensor Sensor Sensor

(f) Hierarchial (Tree) Topology (g) Mesh Topology

Figure 2: Network Topologies

In addition to the network topologies shown in figure 2 there is another topology which involves clouds. The use of
cloud network as part of your solution may or may not be appropriate depending on your use case. However, it is
likely some part of your IoT solution will incorporate the use of a cloud solution.

As you would expect there are numerous sources for clouds available. However, keep in mind that not all cloud
solutions are the same and that interoperability and real portability needs to be considered otherwise you will be
locked into one service provider or solution.

Regardless a cloud environment for IoT can be looked at in three layers: cloud, fog and mist and they are shown in
figure 3. In figure 3 the main layer is the cloud and it is a more traditional network model using remote servers
running in a virtual environment instead of being run locally. The cloud service provides the ability to perform heavy
computing, storage, and analytics. Devices can connect to the cloud directly or via an intermediary like a fog or mist
environment.

www.nextgconnect.com 5 August 25, 2019

 Next G Connect

A fog environment shown in figure 3 is meant to extend cloud computing closer to the edge of the network. This
has many advantages for an IoT environment reducing latency, performing less intensive computing functions and
minimizing the amount of data that is sent to the cloud which is not needed. Fog environments are more
geographically dispersed than cloud networks. The fog environment can be thought of as an intermediate level
cloud.

The next lower level cloud environment shown in figure 3 is called a mist or rather edge computing. Mist computing
is meant to provide edge computing for the network. Devices making up a mist environment perform smaller
functions that do not need to be elevated to the fog or cloud environments. Many mist clouds can reside within a
fog environment. The mist environment is a true distributed computing environment.

Cloud
D2D within Cloud
Cloud

Device-to-Cloud Cloud-to-Cloud
D2C C2C
Fog-to-Cloud
F2C
Edge-to-Cloud
E2C
Fog Computing

Fog and Edge Standalone

Edge Computing
Computing Device
Device-to-Device
D2D

Mist Computing

Figure 3: Cloud Topologies

IoT devices not only utilize a multitude of protocols and topologies they also operate in a multitude of different
frequency bands. The frequency band used by the IoT device can be licensed or unlicensed and it can be either
stationary, semi-mobile or mobile. The frequency band used by the IoT device has a large impact on how the use
case solution is solved. For instance, devices using lower frequencies in the spectrum have more range while devices
using higher frequencies can support more data rich solutions.

Figure 4 is a brief overview of the US spectrum which applies to wireless IoT devices. In reviewing figure 4 the
different frequency bands which are available for IoT use are vast. In addition, all the frequency bands with the
exception of the cellular spectrum are license free. IoT devices however are not solely limited to the frequencies
listed in figure 4.

www.nextgconnect.com 6 August 25, 2019

 Next G Connect

125/
6.78MHz 13.567 27.12 40.68 433.92
131kHz 167 MHz 315 MHz
MHz MHz MHz MHz
RFID ISM ISM ISM ISM

9kHz 30kHz 14kHz 326kHz 40kHz 75kHz 1.74MHz 1.74MHz

27.283

169.4

433.05
13.567

40.7

434.79
315.87
13.553

26.957
6.795
6.675

40.56
0.134

169,475
0.125

314.13
Upper 700 MHz

757

763

775

787

793

805
Lower 700 MHz

A B C D E A B C C A D Public Safety B C A D Public Safety B

Ch52 Ch53 Ch54 Ch55 Ch56 Ch57 Ch58 Ch59 Ch60 Ch61 Ch62 Ch63 Ch64 Ch65 Ch66 Ch67 Ch68 Ch69

MediaFlo
Public Safety Public Safety
722

740

758
704

710

716

728

734

752

782

788
776
746

764

794

806
698

Cellular Recieve *45MHz Cellular Transmit 915

A A
ISM
ESMR A B A' B' ATG Transmitt ESMR "
A B A' B'
"
26MHz
817

846.5

891.5
849

869

880
824

835

845

890

894
825

870

928
902
851

862

AWS Recieve *400MHz PCS Recieve

*80MHz
A D B E F C
A B C D E F G
(MTA) (BTA) (MTA) (BTA) (BTA) (MTA)
1720

1740

1745
1710

1730

1735

1755

1850

1865

1870

1885

1890

1895

1910

1915
1920 PCS Transmit AWS Transmit
*80MHz *400MHz
A D B E F C
DECT G A B C D E F
(MTA) (BTA) (MTA) (BTA) (BTA) (MTA)

20MHz 2140

2155
2110

2120

2130

2135

2145
1995
1930

1945

1950

1965

1970

1975

1990
1910

WiFi WiFi WiFi

802.11b/g 802.11a 802.11a 24.125 GHz 61.25 GHz
5.8GHz

ISM UNII UNII ISM ISM ISM

100MHz 200MHz 255MHz 250MHz 500MHz

150MHz
5350
2500

5725
5470

5875

24.255GHz
24GHz

61GHz
2400

5150

61.5GHz

Figure 4: US IoT Spectrum

This article hopefully enables you to begin asking some questions you may not have thought about when putting
together your IoT solution. However, when deciding on what IoT device protocol you will be utilizing it is important
to understand the use case or cases you are solving.

While technology is an important component of IoT there are other issues that need to be addressed when selecting
an IoT solution. The 7 Critical Musts for IoT devices you should answer as part of your IoT solution are:

1. Objective/Purpose
2. Security (cyber/physical)
3. Data Acquisition/Functions

www.nextgconnect.com 7 August 25, 2019

 Next G Connect

4. Standards and Compliance Regulations

5. Business (CapEx/OpEx/Revenue)
6. Interface /User Experience
7. Technology

I trust that you found this first part of the IoT protocol articles useful.

Feel free to utilize this table in any presentation or article. I simply ask you to reference where it came from.

If you want to have a modified version of any of the tables, update, remove, and add some protocols or
features/functions please contact us at info@nextgconnect.com with the ask.

Clint Smith, P.E.

Next G Connect
CTO
csmith@nextgconnect.com

Who we are:

NGC is a consulting team of highly skilled and experienced professionals. Our background is in wireless
communications for both the commercial and public safety sectors. The team has led deployment and operations
spanning decades in the wireless technology. We have designed software and hardware for both network
infrastructure and edge devices from concept to POC/FOA. Our current areas of focus include 4G/5G, IoT and
security.

The team has collectively been granted over 160 patents in the wireless communication space during their careers.
We have also written multiple books used extensively in the industry on wireless technology and published by
McGraw-Hill.

Feel free to utilize this information in any presentation or article with the simple request you reference its origin.

If you see something that should be added, changed or simply want to talk about your potential needs please contact
us at info@nextgconnect.com or call us at 1.845.987.1787.

www.nextgconnect.com 8 August 25, 2019