1.

IoT Network Protocols:

o Wi-Fi: Commonly used for local area networks (LANs) and provides high
data rates.
o LTE CAT 1: A cellular protocol suitable for applications with moderate
data requirements.
o LTE CAT M1: Optimized for low-power, wide-area (LPWA) IoT devices.
o NB-IoT: Another LPWA cellular protocol designed for low-power, long-
range communication.
o Bluetooth: Ideal for short-range connections between devices.
o ZigBee: Used in home automation and industrial applications.
o LoRaWAN: A long-range, low-power protocol for IoT devices.
2. IoT Data Protocols:
o AMQP: Advanced Message Queuing Protocol, suitable for reliable
message exchange.
o MQTT: Lightweight and widely used for efficient data transfer.
o HTTP: Commonly used for web-based communication.
o CoAP: Constrained Application Protocol, designed for resource-
constrained devices.
o DDS: Data Distribution Service, used in real-time systems.
o LwM2M: Lightweight Machine-to-Machine protocol for managing IoT
devices.

Remember, choosing the right protocol depends on factors like power

consumption, range, and data requirements

When network entities like servers, gateways, routers, applications,

and connected devices interact, protocols give them a shared
language. A protocol is a set of rules both network entities must
have in common in order to communicate. It governs what their
interactions look like, what values and attributes can be transmitted,
how they’re received and processed, what security methods will be
used, and more.

In the Internet of Things (IoT), the protocols you choose determine

your application’s complexity and help you prioritize the qualities
that impact service and performance, such as speed, clarity, power
saving, or security.

Some telecommunications protocols have been in use for decades,

like IP (Internet Protocol) or GSM (Global System for Mobile
Communications), and engineers have adapted them to new
devices and IoT contexts over time. Others are more recent
developments, born out of highly specific IoT use cases, like OCPP
(Open Charge Point Protocol), which enables electric vehicle
charging stations to interact with a central system.

As IoT continues to evolve and new devices and use cases arise,
we’ll likely see more specialized IoT protocols emerge as well. At
the same time, older, obsolete protocols will simply fall out of
usage.

In this guide, we’ll cover over 40 of the most popular IoT protocols
spanning various network layers, explaining what they are and how
they affect your devices.

 IoT application protocols

 Industry-specific IoT application protocols
 IoT protocols for consumer devices
 IoT transport protocols
 Network layer IoT protocols
 Physical and data link layer IoT protocols
 IoT security protocols

If you want help talking through how your IoT connectivity solution
will influence the protocols available to you, talk to one of our
experts.

IoT application protocols

The application layer of a network enables network entities to
identify and interact with each other.
MQTT (Message Queueing Telemetry Transport)

MQTT is a lightweight communication protocol specifically designed

for IoT and M2M applications. It’s ideal for remote environments or
applications with limited bandwidth. MQTT uses a connection
oriented publish/subscribe architecture, where MQTT applications
can either publish (transmit) or subscribe to (receive) topics, and an
MQTT broker passes information from the publishing client to the
subscribed client.
So for instance, an oil rig may have a predictive maintenance
sensor that detects changes in vibrations and uses the MQTT
protocol. The sensor “publishes” the vibration level to the broker,
which the MQTT broker then passes to a software application that
has subscribed to the topic “vibrations,” which can then trigger an
alert when the level is above a threshold. .
HTTP (HyperText Transfer Protocol)

Hypertext Transfer Protocol is the most widely used protocol for

navigating the Internet and to make data available over REST-APIs.
The main advantage of using HTTP for IoT is that web application
developers can use the same mechanism to send data to a
Webserver - via an HTTP POST request.

The drawbacks are that HTTP uses a connectionless request-

respond communication, meaning every message needs to include
authentication information—which requires data and energy
consumption. Nevertheless HTTP might be ideal for use cases
which have fewer data and battery constraints and where devices
already need to call existing REST-APIs.

Like MQTT and MQTT over WebSocket, HTTP is one of the

protocols that is supported by standard IoT cloud services such as
AWS IoT and Azure IoT.
WebSocket

WebSocket is a bi-directional communication protocol designed to

quickly send large quantities of data in web applications. A
WebSocket establishes a connection between client and server and
therefore after the initial connection establishment—every single
message only has small overhead. Devices and servers can
simultaneously transmit and receive data in real-time, making this
protocol best-suited for IoT applications where low latency is critical,
communication happens frequently, and data consumption is less
important.
AMQP (Advanced Message Queuing Protocol)

AMQP is an open source protocol for Message-Oriented

Middleware (MOM). It’s designed to facilitate communications
between systems, devices, and applications from multiple vendors
—and it was not directly designed for IoT. Opposed to MQTT it
supports more routing options than just publish / subscribe on
topics—but this flexibility comes with complexity on application
setup and additional protocol overhead. AMQP is also supported by
Azure IoT for device communication.
CoAP (Constrained Application Protocol)

Constrained Application Protocol (CoAP) is designed for low-power,

lossy networks, also known as “constrained” networks. CoAP is
usually paired with User Datagram Protocol (UDP) which makes it
highly efficient, making it appealing for IoT applications where
battery conservation is important. For example, it’s often used
in smart meter communications. CoAP can also use TCP or SMS
as transport mechanism.
LwM2M (Lightweight Machine-to-Machine)

The Lightweight Machine-to-Machine (LwM2M) protocol builds on

CoAP for a highly efficient low-power communication, but LwM2M
also specifies device management and provisioning functionality.
Therefore, LwM2M, for example, has a standardized procedure to
clarify which security mechanism is used and how device firmware
is updated. As LwM2M is build on top of CoAP it can be used
with UDP, TCP, and SMS for data transport.
XMPP (Extensive Messaging and Presence Protocol)

Extensible Messaging and Presence Protocol is a communications

protocol built on Extensible Markup Language (XML). XMPP was
initially designed for instant messaging (IM)—which also explains
that it comes with an overhead for the exchange of presence
information and is not optimized for memory constrained devices.
Nevertheless XMPP allows for the definition of the message format
and therefore handles very well structured data, as well as
establishes a device’s identity and facilitates communications
between different platforms. This open-source technology is highly
accessible and is still being enhanced with new IoT-related
developments.
DDS (Data Distribution Service )
Data Distribution Service protocol is a real-time, interoperable
communication protocol designed for solutions that require
significant coordination, reliable transmissions, and distributed
processing between the devices itself. Instead of sending data to a
central hub or broker, data can be directly been exchanged
between peers making it more robust and efficient. DDS uses a
publish/subscribe mechanism where devices subscribe to a topic
and devices sending to the topic are then using multicast to
distribute the information to the subscribers. DDS can use TCP and
UDP as transmission protocol.
SMS / SMPP (Short Message Peer-to-Peer Protocol)

Short Message Service allows devices and applications to send and

receive text messages over a cellular connection. Cellular
IoT devices use Short Message Services (SMS) to send and
receive data to the application or to another peer in the mobile
communication network.

An application can communicate with devices programmatically by

connecting to the Short Message Service Center (SMSC) of a
service provider using the Short Message Peer-to-Peer Protocol
(SMPP) or an SMS Rest-API. Telematics providers can use SMPP
to provision and configure their devices remotely.
USSD (Unstructured Supplementary Service Data)

Also known as “Feature Codes” or “Quick Codes,” USSD is a

messaging protocol used in cellular networks based on the Global
System for Mobile Communications (GSM). IoT businesses use
USSD to retrieve text-based data (such as location, temperature,
and other status updates) from IoT devices without relying on a
data connection. Unfortunately, since many carriers
are sunsetting their 2G and 3G networks, USSD will become
obsolete in the near future.
Simple Sensor Interface (SSI) protocol

SSI enables IoT sensors to transmit data to or receive data from a

terminal such as a computer or mobile device. As the name implies,
the protocol is not very complex, so communicating via SSI uses
very little power. However, there’s been no update to the protocol
since 2006, so it may already be obsolete.

Industry-specific IoT application protocols

In telecommunications, it’s fairly common for unique protocols to
emerge in order to optimize and improve networking capabilities for
particular use cases. Here are some examples of protocols that
were designed with a specific IoT application or industry in mind.
OCPP (Open Charge Point Protocol)

Open Charge Point Protocol (OCPP) is an open standard

communication protocol for Electric Vehicle (EV) charging stations.
It defines interactions between EV charging stations and a central
system - mainly the Charging Station Management System
(CSME), helping to facilitate security, transactions, diagnostics,
devic management and more. While in the beginning using SOAP -
newer OCPP protocols support communication via WebSocket and
JSON over WebSockets.
IEC 62056

IEC 62056-21 is a set of standards for electricity meters. Designed

by the IEC (International Electrotechnical Commission), the
protocols define data exchanges for meter reading, as well as tariff
and load control. The intent of this protocol is to standardize these
communications internationally.
OBD2/CAN bus

The On Board Diagnostics 2 (OBD2) protocol defines

communications between a vehicle’s electrical systems and its OBD
port. When one of these systems experiences a malfunction, it uses
OBD2 to communicate the relevant Diagnostic Trouble Codes
(DTCs) to the OBD port. Nowadays ODB2 is used to capture
vehicle telematics information such as temperature, velocity, fuel
consumption, brake or tire pressure. The CAN bus is another
protocol that works in conjunction with OBD2, defining how the
communication takes place between microcontrollers of the
vehicle.
OPC UA

OPC Unified Architecture (UA) is an interoperable, open-source

communication protocol used in industrial IoT, specifically to
exchange data between connected sensors and the cloud. This
highly versatile protocol isn’t tied to a specific operating system,
programming language, or communication protocol, making it useful
for non-industrial applications as well.
Wireless M-bus

Wireless M-bus is a specialized European standard designed

for smart meter communication. Devices are communicating in a
star like topology with a central gateway or data logger. The
Wireless M-bus protocol suite that goes across the physical and
link-layer (EN 13757-2) and application layer (EN 13757-3) has
good indoor penetration based on the use of low frequencies (169,
433 and mainly 868 MhZ) and has a wide adoption in Europe.
However, this open source protocol doesn’t have a certification
standard, so providers and manufacturers who use it aren’t always
compatible.

IoT protocols for consumer devices

Consumer IoT devices become more valuable when they can
communicate with devices from different brands, which may rely on
different connectivity solutions. Some manufacturers develop their
own proprietary protocols to provide specific functionality to
particular devices, but at times they’ll collaborate to enable
interoperability.
Matter

Matter is a recently developed application protocol born out of a

collaboration between Google, Apple, Amazon, Samsung
SmartThings, and the Zigbee Alliance (now the Connectivity
Standards Alliance). It was designed to enable communication and
improve compatibility between smart home devices from different
vendors.
Weave
Weave is an IoT protocol which Nest Labs developed and Google
later acquired. While it was initially developed for Nest products,
Google plans to integrate it with connected Android devices as well.
It’s compatible with ethernet, Wi-Fi, Bluetooth Low Energy (BLE),
cellular networks, and other IPv6 technologies.
Homekit Accessory Protocol (HAP)

Apple developed HAP so that manufacturers could produce third-

party devices that can communicate with Apple products around the
home. For example, consumers can control smart lights, connected
locks, and IoT thermostats from their Apple products if these other
devices were developed with HAP.
KNX

KNX is an open standard used for building automation, which

descends from three European protocols: European Home Systems
Protocol (EHS), BatiBus, and European Installation Bus (EIB). It
typically operates over twisted pair links, but can use other links as
well.
X10

X10 was developed in 1975 to enable remote control of household

devices including lamps, appliances, and outlets. It’s the oldest
networking technology specifically designed for connecting home
devices and it’s still widely used today. X10 includes specifications
for using Power Line Communication (PLC) and RF.
Z-Wave

Z-Wave is a smart home protocol that uses a mesh network

topology to connect devices to a central hub. It offers longer range
than early generations of Bluetooth and uses less power than WiFi.
When a consumer issues a command to a connected device
through a smartphone or PC, the data packet uses the mesh of
connected devices as nodes to reach the central hub, which then
routes the data through the nearby devices to reach its intended
destination.
IoT transport protocols
Transport layer protocols define how data gets packaged, sent, and
received. In IoT, the best protocol for your device depends on what
needs to be sent and which quality is more important for your use
case: speed or reliability.
UDP (User Datagram Protocol)

User Datagram Protocol (UDP) is a transport protocol that

prioritizes speed over reliability, using a connectionless process to
send data packets to a destination. Due to its low latency, UDP is
ideal for time-sensitive use cases like video streaming, Voice over
Internet Protocol (VoIP), video gaming, and Domain Name System
(DNS) lookups.
TCP (Transmission Control Protocol)

Transmission Control Protocol (TCP) sets the parameters for data

exchanges between software applications, confirms what is being
sent, where it’s coming from, where it’s going, and whether or not it
arrived correctly. TCP prioritizes accuracy over speed, ensuring that
data arrives in order, with minimal errors, and without duplication. If
data gets lost in transmission, TCP requests the data packets be
resent.

Network layer IoT protocols

The network layer packages transmissions and routes data packets
from one network entity (such as a router, server, node, application,
or device) to another, determining the path they will take to get
there.
IP (Internet Protocol)

Internet Protocol is basically the key to the Internet. It gives network

entities an IP address, which allows other network entities to send
them data packets even if they are not on the same network.

Physical and data link layer IoT protocols

Physical and data link layer protocols arguably have the biggest
impact on your IoT solution’s capabilities and service. These are the
standards that define the type of network your device relies on,
which determines what kind of coverage, signal strength, power
consumption, and data throughput you’ll be working with.
Wi-Fi

Wi-Fi is a suite of wireless network protocols built primarily on IEEE

802. It creates a Local Area Network that nearby devices can
connect to. While these networks are ubiquitous in homes and
businesses and can offer good data throughput, Wi-Fi isn’t ideal for
many IoT applications, as basic structures like walls can greatly
disrupt its signal strength, and since nearly all Wi-Fi networks use
2.4GHz or 5GHz frequency bands, they’re prone to interference. It
also consumes more power than protocols that were designed with
IoT devices in mind.
LTE (Long Term Evolution)

LTE is a 4G standard that is built on 2G and 3G cellular

infrastructure to provide significantly faster data speeds and new
applications including multimedia streaming, Voice over IP, and
video conferencing. LTE is widely used today and offers excellent
coverage, but is not suitable for battery-powered IoT devices and is
quite expensive. Therefore, for IoT use cases, there is also a
variant LTE CAT-1 which is more simple and less costly, but still not
feasible for battery powered devices.
GSM

The Global System for Mobile Communications (GSM) specifies

how 2G (second generation) cellular networks operate. Despite
being three decades old, it’s currently the most widely used network
technology in IoT applications due to its simplicity, affordability, and
accessibility. As MNOs shut down their 2G networks, IoT
manufacturers need to weigh the risks of continuing to rely on GSM
or using it as a backup.
GPRS

General Packet Radio Service (GPRS) is an upgrade to 2G

networks, sometimes referred to as 2.5G. It provides higher data
rates and additional services, including “always on” Internet access
and Internet applications for IoT devices.
UMTS

Universal Mobile Telecommunications Service (UMTS) has become

practically synonymous with 3G, the third generation of cellular
networks. It offers greater bandwidth, more efficient use of the radio
spectrum, and more advanced cellular capabilities than GSM,
including video transmission. UMTS has been popular in IoT
because it consumes less power than 4G LTE, but offers greater
throughput than GSM. However, UMTS is almost two decades old,
and carriers are sunsetting their 3G networks to free bandwidth for
newer networks. So depending on where you deploy, relying on
UMTS could be a gamble—the standard may not last as long as
your device.
5G

5G networks are designed to achieve a peak download speed of 20

Gbps and peak upload speed of 10 Gbps. The average rates are
more like 100 Mbps for downloads and 50 Mbps for uploads. This is
several times faster than 5G’s predecessor, 4G, and the theoretical
peak speeds are 100 times faster. Even though in developed
countries early 5G technology has been rolled out, it is still early for
the use of 5G in IoT because of device costs and energy
consumption.
NB-IoT

Narrowband IoT (NB-IoT) is a specialized cellular network made for

the Internet of Things. This standard enables devices to utilize
frequencies within a carrier’s licensed bands and use minimal
power, particularly when a device isn’t transmitting. It allows
devices to use power-saving features, but it has drawbacks as well
—the main being that there is no redundant coverage available with
NB-IoT, and global deployments require multiple providers as
roaming is difficult with NB-IoT.
LTE-M

Long Term Evolution Machine Type Communication (LTE-M) is a

type of 4G cellular network specifically designed for the Internet of
Things. LTE-M provides many of the same advantages as NB-IoT,
but it has 10 times faster data speeds and offers better coverage
due to the possibility to roam between networks. (Notably, NB-IoT
has slightly better indoor penetration.)
NFC (Near Field Communication)

NFC builds on Radio Frequency Identification (RFID) to facilitate

connectivity between two devices that are within 1.5 inches (or
4cm) of each other. If one of these devices is connected to the
Internet, NFC also enables the other device to access online
services through the connection. This niche protocol continues to
play an integral role in daily life through applications like tap-to-pay.
PLC (Power Line Communication)

PLC leverages existing energy infrastructure to facilitate IoT

communication. With PLC, power lines provide the infrastructure for
data transmissions in addition to electricity. Since it builds on
existing infrastructure, PLC is a relatively simple connectivity
solution, but unfortunately, it’s also not very reliable. Electrical
currents can and do interfere with data transmissions.
MIoTy

MIoTy is a Low Power Wide Area Network (LPWAN) standard that

uses telegram splitting and unlicensed frequency bands to provide
efficient, large-scale connectivity for industrial IoT applications. It
splits data into subpackets and applies error-correcting codes
before sending them, making transmissions more resistant to
interference. MIoTy is open source and standardized by the mioty
alliance.
LoRa (Long Range)

LoRa is the physical layer standard that makes LoRaWAN possible.

It uses spread spectrum modulation to increase signal strength,
improve security, and enable multiple-access communications.
LoRa builds on the chirp spread spectrum to distribute signals
across a greater bandwidth. LoRa uses unlicensed low frequency
bands 169 MHz, 433 MHz (Asia), 868 MHz (Europe), and 915 MHz
(North America).
LoRaWAN (Long Range Wide Area Network)

LoRaWAN is the communication protocol that builds on LoRa to

connect devices to a network. It’s a type of LPWAN standard
designed for IoT applications. It uses very little power, has good
coverage, and works well indoors. However, unless you can find a
LoRaWAN vendor with coverage in the area you’re deploying, you
have to deploy and manage your own infrastructure. This can be
especially challenging when you have multiple deployments.
Sigfox

Sigfox networks use very small frequency bands and each country
only has a single Sigfox network operator. This standard is used in
everything from retail stores to industrial IoT to smart alarm
systems, but while it has coverage up to 1,000 kilometers, devices
that use Sigfox can only send and receive extremely small
messages, which makes firmware updates and data-intensive
processes impossible.
Neocortec

Neocortec is a proprietary mesh networking protocol that boasts

“cable-like reliability” and emphasizes simplicity. Data transmission
goes from node to node until it reaches its destination. Similar to IP
networks Neocortec also providers acknowledge (TCP like) and un-
acknowledge UDP like data transport. It’s meant to be fast to set
up, low maintenance, and simple to develop with. This is an IoT
connectivity solution that requires manufacturers to build and
manage their own infrastructure on site. Neocortec uses unlicensed
bands such as 868 and 915 MhZ and 2.4GHz.
Weightless

Weightless is an open Low Power networking standard protocol

driven by the Weightless alliance operating in unlincensed sub-GHZ
bands. There were three distinct Weightless standards, each of
which relies on different technology:

1. Weightless-W - operating in TV whitespace

2. Weightless-N - offering uplink only LPWAN communication
3. Weightless-P - providing bi-directional LPWAN communication

Based on the success of only Weightless-P now the other

standards are not further developed and Weightless-P has been
renamed to purely Weightless.

Weightless is an ultra ultra narrow-band (12.5khz) LPWAN

technology that allows Weightless capable devices to communicate
with a Weightless base station over km wide distances. With radio
resource scheduling it provides efficient and collision free data
transmission which is a benefit compared to LoRaWan.

IoT security protocols

Most IoT application protocols already include their own end-to-end
security mechanism. The security protocols listed here are just for
devices where end-to-end encryption is impossible.
IPSec (Internet Protocol Security)

Internet Protocol Security (IPsec) is a protocol suite that secures

network communications at the IP layer. It facilitates two-way
authentication between network entities exchanging data, then uses
keys to authorize data packets. While IPsec is an option for
powerful gateway, low resource IoT devices will not be able to
handle the processing and data overhead. An alternative in Cellular
IoT is to offload the security to the cellular service provider which
then establishes an IPsec connection between the mobile network
and the IoT application.
OpenVPN (Open Virtual Private Network)

OpenVPN is a versatile, open source protocol for creating Virtual

Private Networks (VPNs) using a point-to-point or site-to-site model.
It uses 256-bit encryption to protect your data packets and enables
a client and server to authenticate each other with a pre-shared key
and a certificate. In IoT, OpenVPN is essential for remotely
maintaining, analyzing, and troubleshooting your devices.
TLS (Transport Layer Security)

Transport Layer Security (TLS) is the most widely used security

protocol for communications over the Internet. Through a series of
back-and-forth protocol messges, TLS establishes a “handshake”
between a client and server to authenticate client and server and
then to start an encrypted data transmission. TLS relies on
certificate authorities that proves the authenticity of a device or
server certificate to proof the identity of communication parties.

Get the IoT connectivity you need with emnify

emnify is a cellular IoT connectivity provider that keeps your
devices connected anywhere in the world. Our global IoT
SIMs enable your devices to connect to more than 540 networks in
over 200 countries—all with a single contract. Our flexible pricing
ensures you only pay for the data you use, and you get everything
you need to manage your connectivity at scale. In addition to
simple, scalable connectivity, emnify secures your connectivity
with multi-layered IoT security.

As you examine the protocols and standards your application

needs, consider the possibilities of cellular IoT. Our IoT experts will
be happy to talk through the best options for your solution.

When building an Internet of Things project, most stakeholders only care about getting data
from their devices to their dashboards. Seldom do they think about how the data gets there,
because they see that as the engineers’ responsibility.

In response, the engineers just shake their heads.

Understanding how your data is transmitted is essential to identify potential areas of

optimization and improve your deployment’s performance. This is how you'll ensure that the
technical solution to the business problem you’re trying to solve with IoT is the best it can be.

Protocols are the language that enables communication between devices and the cloud. Most
protocols come with pros and cons—and while some work well for IoT, others do not.
This article will describe and compare the major protocols, discuss how they can be used in
the IoT space, and detail how Particle finds the right protocols for your IoT deployment.

What are IoT protocols?

Before we dive into common IoT protocols, let's define the term "protocol" at a high level.

Protocols are a set of rules for transmitting data between electronic devices according to
a preset agreement regarding information structure and how each side will send and
receive data. Correspondingly, IoT protocols are standards that enable the exchange
and transmission of data between the Internet and devices at the edge.

IoT protocols can be divided into two categories: IoT network protocols and IoT data
protocols. Data protocols mainly focus on information exchange, while network protocols
provide methods of connecting IoT edge devices with other edge devices or the Internet.
Each category contains a number of protocols that each have their own unique features. We'll
take a look at those next.

List of Common IoT Protocols

IoT Network Protocols

 Wi-Fi
 LTE CAT 1
 LTE CAT M1
 NB-IoT
 Bluetooth
 ZigBee
 LoRaWAN

IoT Data Protocols

 AMQP
 MQTT
 HTTP
 CoAP
 DDS
 LwM2M

Layers of the IoT protocol stack

"IoT protocol stack" refers to a hierarchy of software and hardware layers.

As Particle's Sr. Solutions Architect Dan Kouba phrased it, "It is all the things that sit in
between the data being produced at the edge to the data being received by your systems."

The IoT network stack can be represented using the seven-layer OSI Network Model, starting
from the physical layer at the bottom and ending with the application layer at the top.
Specific protocols may represent only one layer or span many—regardless, they must be
interoperable to ensure that the network functions as intended.

Next, let's take a closer look at each layer and its related functions.

Physical and Data Link Layers

The first two layers from the bottom—the physical and data link layers—define the physical
connection of end devices to the network. More specifically:

 The physical layer receives unstructured raw data between devices and physical
transmission media, then transmits the digital information into electrical, radio, or
optical signals.
 The data link layer catches the data and detects/corrects any errors that may have
occurred. This layer also defines the protocol for flow control, as well as establishing
and terminating connections between two physically connected devices.

"The physical layer is the actual hardware that the electronics are on," explained Dan. "The
data link layer represents how the modem negotiates with the cell tower—for example, to
establish a communication channel between a device and the cell tower or other networking
equipment."

Network, Transport, and Session Layers

The network, transport, and session layers facilitate data transfer over the connection,
with a focus on logical addressing, traffic directing, error correction, flow control,
congestion avoidance, session management, and reliability.
"From the user’s perspective, these layers are the protocols that run on top of the tunnel to
facilitate communication," Dan noted. "What does that message look like? How is it
formulated? How do I put data in it? How do we get data out of it?"

Presentation and Application Layers

The two layers at the top—presentation and application—deal with data formatting and the
boundary between the data coming from devices in the field and a business application or
database.

 The presentation layer transforms data into the form that is accepted by the
application.
 The application layer—the layer closest to the user—typically identifies
communication partners, determines resource availability, and synchronizes
communication.

At this point in the process, all procedures are accomplished over an encrypted channel.
Security applies to every layer in different ways and is often a function of the protocol being
used. Once the data reaches the cloud, the systems will unpack it, analyze it, and make
decisions accordingly before pushing each decision to the user's cloud platform.

IoT network protocols: What are they and what do you need
to know?
Wi-Fi

Wi-Fi is a ubiquitous protocol that can be found almost anywhere—industrial plants, homes,
commercial buildings, and even your neighborhood restaurants. This widely favored
technology is able to transmit large volumes of data over reasonable distances. However,
many low-power or battery-powered IoT devices are unlikely to use Wi-Fi due to its high
power consumption rate.

Read our in-depth comparison of cellular vs. WiFi for IoT applications to learn more about
when WiFi makes sense and when it doesn’t.

LTE CAT 1

LTE CAT 1 is a communication standard specifically designed for servicing IoT applications.
Compared with other standards, it scales down bandwidth and communication demand to
save power and cost for large-scale and long-range IoT systems. Though LTE CAT 1
performs inferiorly to 3G networks, experts predict that it will replace 3G as major U.S.
carriers sunset 3G in 2022.

LTE CAT M1

LTE CAT M1—which can also be referred to as Cat-M—is a low-cost, low-power, wide-area
network that specializes in transferring low to medium amounts of data. It was developed by
the 3rd Generation Partnership Project as part of the 13th edition of LTE standard and is a
core cellular IoT technology.

Cat-M stands out as a protocol option because it is compatible with the prevailing LTE
network, meaning major carriers pivoting to it will not have to invest in new antennas.

Comparison: CAT M1 is considered a complementary technology to NB IoT. However,

CAT M1 has a faster upload/download speed of 1 Mbps and a lower latency of 10 to 15
ms.

As of 2024, LTE CAT M1 and NB-IoT are now widely deployed and supported by
major carriers worldwide, as the rollout has significantly progressed since 2022. This
widespread availability has enabled the growth of large-scale, low-power IoT
deployments across various industries.

NB-IoT

While the protocols detailed previously have been in application for a long time, Narrow
Band-IoT is a new, fast-growing, low-power, wide-area technology intended to specifically
target the needs of battery-powered IoT devices.

When compared to other cellular protocols, NB-IoT's advantages include improvements in

power consumption, system capacity, and spectrum efficiency. For example, NB-IoT can
connect huge fleets with up to 50,000 devices per network cell.

However, NB-IoT doesn’t come without challenges. The protocol has very limited
bandwidth, which can slow or limit data transmission capabilities and make essential features
like over-the-air updates difficult or impossible to achieve. Also, the protocol has seen
limited rollout and support in worldwide geographies. While support is growing, fragmented
availability is a risk to any IoT deployment.

Bluetooth

Bluetooth focuses on point-to-point, short-range communication of a relatively small amount

of data. In the IoT space, Bluetooth is commonly used to connect small, battery-powered
sensors to IoT gateways or to facilitate communication with a smartphone, eBike, or other
smart device.

ZigBee

Ratified in the early 2000s, ZigBee stands out as a low-cost, low-power, and reliable wireless
network technology. The standard is adaptable and supports multiple network topologies,
including mesh networks, point-to-multipoint, and point-to-point. ZigBee is most commonly
used in home or building automation settings.

LoRaWAN
Long-range wide area network—also referred to as LoRa—is a long-range, radio-wide
networking protocol with low power consumption. Normally, LoRaWAN wirelessly connects
multiple battery-operated devices to the Internet within regional, national, or global networks.

In the IoT field, LoRaWAN plays an important role in bidirectional communication, end-to-
end security, localization, and mobility services.

IoT data protocols: What are they and what do you need to
know?
AMQP

Known for its reliability and interoperability, Advanced Message Queuing Protocol is an
open messaging standard. This protocol utilizes queues of data, enabling connected systems
to communicate asynchronously and better handle issues like traffic spikes and poor network
conditions.

Additional AMQP features include durable and persistent queues, federation and high-
availability queues, clustering, and flexible routing. However, AMQP is known to be a
verbose protocol in some circumstances.

Comparison: Compared with MQTT (discussed next), AMQP is more reliable and
secure.

MQTT

Message Queue Telemetry Transport is a lightweight pub/sub messaging protocol suitable for
connecting small, low-power devices.

This data protocol was designed specifically for IoT communication and requires minimal
memory and processing power. On the wire, MQTT's bidirectional pub/sub architecture
makes the protocol flexible and scalable for a wide variety of use cases and IoT system
architectures.

Additionally, the MQTT protocol is designed with reliability and scalability in mind—
security is provided via Transport Layer Security, and persistent sessions allow the protocol
to adapt to poor network conditions and reduce connection time overhead.

HTTP

You might recognize this acronym as appearing at the beginning of every website address
you type, as Hypertext Transfer Protocol is the foundation of data communication for the
World Wide Web.

However, within the context of IoT applications, HTTP has many drawbacks. For instance,
this protocol establishes a synchronous connection between two devices in order to transfer
data—which presents a number of challenges for IoT deployments because devices and
endpoints may not be online at the same time and connections may be unreliable due to
network conditions.
Additionally, HTTP relies on transferring data in ASCII, which is an inefficient way to
transmit the small bits of data often exchanged by IoT systems and requires more processing
power to encode and decode messages at both ends.

Ultimately, while HTTP is a great choice for transferring website data, it is generally not a
good choice for an IoT application.

CoAP

Constrained Application Protocol is used with constrained nodes and networks. This protocol
is suited for IoT applications as it reduces the size of network packages, thereby decreasing
network bandwidth overload. Other benefits of CoAP include improving the IoT life cycle,
saving battery power and storage space, and reducing the amount of data required to operate.

DDS

Released in 2004, Data Distribution Service is a middleware architecture for real-time

systems that focus on data communication between the nodes of a publication- or
subscription-based messaging architecture.

DDS is mainly used under circumstances that require real-time data exchange—for example,
autonomous vehicles, power generation, and robotics.

LwM2M

Lightweight Machine-to-Machine protocol is designed for remote management of M2M

devices and related services. LwM2M reduces costs associated with low-power module
deployment and equipping devices with faster IoT solutions. Learn more about M2M vs IoT.

Comparison: Note that the CoAP, LwM2M client initiates the connection to an LwM2M
server that will use the REST API to manage the interfaces.

Why are protocols and standards important in IoT?

While this synopsis might seem like information overload, protocols are essential in IoT
implementations.

"You want to make sure that whatever language your computers are speaking is really meant
to be used for your use case," explained Dan. "There are lots of ways to establish
communication between two machines, and picking the right one will give you advantages
such as a low data rate."

Simply put, different protocols provide data in vastly different ways. For example, video call
protocols might deliver data in a specific order all the time—something that's not necessarily
guaranteed with other protocols—but may not be able to ensure that low data is passed
between devices.

IoT security is another important element to take into consideration, as standardized IoT
protocols can prevent further fragmentation and reduce the risk of security threats.
"Security requires some exchange of information to establish a secure tunnel, and doing that
over certain protocols can be very data-intensive," said Dan. "Using the IoT-based protocols
leveraged by Particle minimizes this intensity."

What protocols does Particle use and why?

At Particle, we mainly use CoAP and MQTT for our customers, as both minimize the amount
of data transmitted and MQTT has a lot of institutional weight behind it.

As of 2024, we have expanded our protocol support to enable multi-radio networking. In

addition to the previously supported CoAP and MQTT protocols, Particle now leverages
LoRaWAN and satellite-based NTN (Non-Terrestrial Networks) protocols through
partnerships with leading network operators like Helium, The Things Industries, Comcast's
MachineQ, and Skylo.

"When Particle was created, we prioritized optimizing the amount of data used for each
transaction via our cloud because that directly ties into the value we provide for our
customers," Dan explained. "We give customers an allotted amount of data, and the more that
they can do with that data, the more value they're able to extract from our solution."

Nowadays, many companies don't optimize the layers of the protocol stack, which tends not
to be a direct driver of business value. This makes Particle's off-the-shelf solution an
excellent choice for most use cases.

The beauty of our approach is that you don't have to think about choosing a protocol, as
Particle's expert team will provide the stack and reference system for you. With this aspect
taken care of, you'll have more time to focus on the two end layers of the stack—namely,
what's happening at the edge and what's happening in the cloud.

According to Dan, "As long as you're transmitting your data, your data is relatively small, it's
sent relatively infrequently, and there's not necessarily a need to have it explicitly ordered,
Particle is going to be a great fit."