Embedded IoT Protocols

IoT is a global network of physical devices communicating with each other, usually through cloud applications that add data processing, aggregation, and analysis to deliver business insight that wouldn’t otherwise be possible. For computers and IoT devices to interact intelligently, they rely on protocols — the same way people rely on shared languages to communicate. And just as many human languages express the same meaning but remain mutually unintelligible, computers and connected devices run into the same problem.

Because IoT systems are usually built from low-cost, low-power, low-performance embedded devices, the field of protocols that are ideal — or even possible — to use is narrower than it is for a typical web application, and the need to communicate securely complicates things further, especially since attackers of IoT systems have far more computing power at their disposal than the devices they’re targeting.

What makes a protocol good for IoT

A good IoT protocol enables inexpensive, low-power devices and high performance across a variety of end-use applications, while maintaining a high level of security and reliability. That’s a reasonable starting point, but how those goals are achieved varies a lot by use case. A few features are worth examining as a baseline for most general use:

• Standardization. IoT protocols are like human languages — you can only communicate with something that speaks the same one. Selecting a standardized protocol increases the number of devices and services your device can talk to. No single protocol has been universally adopted for every use case, and probably never will be, but choosing an off-the-shelf standard over a custom-built one saves significant development time and money.
• Low latency. Latency is how long it takes a device to react to an external event — how long it takes a lamp to turn on after a user taps a button in an app, for example. For IoT devices, network latency is by far the biggest component of total system latency, which makes it one of the most important factors in protocol selection for any user-facing reaction.
• Low data overhead. Overhead is the data transmitted beyond the actual information being conveyed. It will never be zero, but it matters for two reasons: many IoT devices communicate over metered cellular connections, so there’s a direct relationship between overhead and cost; and even on unmetered connections, high overhead per device compounds badly once a single house or business has hundreds of IoT devices sharing a connection.
• Low power use. Power use is closely tied to latency and overhead — the more time a device spends sending, receiving, or waiting for a response, the more battery it draws, and the more often a user has to recharge or replace it. Some protocols are specifically designed to work with aggressive device sleep cycles that make more traditional protocols unworkable.

The protocol stack

The internet is made up of many protocols, layered by the function they provide. It’s worth understanding the internet, transport, and application layers relevant to IoT, along with the trade-offs between the application-layer protocols that depend on them.

Internet layer. To be part of IoT, a device has to speak Internet Protocol (IP), which defines how a device is uniquely identified and how the network gets messages from one device to another. Two versions are in active use — IPv4 and IPv6 — and the internet as a whole is slowly migrating from the former to the latter. The main difference most IoT developers will notice is address size: IPv4 uses 32-bit addresses, IPv6 uses 128-bit addresses, allowing far more devices onto the network. Embedded developers usually don’t need to worry about this layer directly, since an IP stack is typically supplied by the hardware vendor — but if a device’s expected lifetime exceeds three to five years, IPv6 support should be a requirement.

Transport layer. This layer provides the common features that every higher-level protocol needs, so they don’t have to reimplement them.

• UDP is the more basic of the two, adding just two things on top of IP: data integrity (via checksums) and application multiplexing (via port numbers). That relative lack of features makes it simple to implement, at the cost of features that many IoT applications will still need from a higher-level protocol.
• TCP is UDP’s more capable sibling, providing reliable, ordered delivery and automatically re-requesting anything lost or corrupted in transit. It requires more hardware resources to implement, but with increasingly capable, affordable hardware — including network interfaces with a full TCP stack built in — that burden matters less than it used to.

Application layer. This is where the real trade-offs for IoT show up. It’s useful to split them into two groups: the older, general-purpose web standards, and the newer protocols purpose-built for IoT.

The old standards:

• HTTP is the best-understood, best-supported protocol on this list, and will remain the lowest common denominator for the foreseeable future. But its client-server request/response model assumes a user is directing the browser — with no user in the loop, an IoT device has to decide on its own when to poll for updates, and repeat that request almost immediately if it wants low-latency reactions, since there’s no way for a server to notify a client of a change without first receiving a request. That leaves HTTP with a data-overhead problem at scale, made worse by being a verbose, text-based protocol — a simple on/off state read can take over 400 bytes for a single request/response.
• XMPP, originally built for instant messaging, appealed to early IoT developers for its real-time, low-latency communication to a single central server. But as an XML-based protocol it’s even more verbose than HTTP — a single request/response to send one byte of data can run past half a kilobyte, and even a compressed variant (EXI) still adds hundreds of bytes of overhead for that same single byte. It’s generally not recommended for embedded IoT applications.

The newer protocols:

• MQTT is a publish/subscribe protocol designed to be simple, lightweight, and easy to implement — the spec is short enough that a reasonably technical person can read the whole thing in a day or two. That brevity cuts both ways: some areas are ambiguous or missing basic features that matter in real deployments, and one of its bigger pain points is limited error handling — most error conditions are just handled by disconnecting the TCP session with no explanation. MQTT works well for small, quickly implemented deployments where both the client and server are controlled by the same party; it’s a weaker fit where a heterogeneous set of clients each need different protocol implementations to talk to one service.
• CoAP was finalized by the IETF (RFC 7252) specifically for resource-constrained embedded devices, while staying extensible. Its semantics closely mirror HTTP’s, so developers already comfortable with HTTP can pick it up quickly — but unlike HTTP, CoAP is a binary protocol transported over UDP rather than TCP, which cuts overhead and improves latency and flexibility. That UDP foundation also lets a device sleep until it actually has something to report, extending battery life without adding latency. The trade-offs: UDP doesn’t offer TCP’s delivery guarantees, so CoAP takes on only the reliability features it actually needs; and without TCP, standard TLS can’t be used to secure the connection — DTLS is required instead, which (being newer) has more limited support across hardware and libraries.
• WebSocket wasn’t designed for IoT at all — it was built for the web, letting browsers and servers communicate continuously over a bi-directional channel. Its biggest strength is compatibility: a WebSocket connection starts as an HTTP request, so anywhere HTTP works, WebSocket almost certainly will too, and server-side library support is mature. Its biggest weakness for IoT is weight — it requires both a TCP and an HTTP implementation, and wasn’t designed with highly constrained embedded systems in mind, so there currently aren’t many open-source WebSocket implementations targeted at embedded hardware.

Choosing a protocol

Because the requirements of individual IoT deployments vary so much, there’s no single protocol that’s right for every situation. The right choice depends on the constraints of your device, your latency requirements, your data costs, and how much of the ecosystem (libraries, hardware support, team familiarity) already exists around a given option. A platform that supports multiple protocols — CoAP, HTTP, and WebSocket among them — gives you room to make that trade-off deliberately instead of being boxed in by whatever your first device happened to ship with.