Can a Single Protocol Cover Modern IoT Communication Patterns?

That diversity is healthy. But it also means that whenever an IoT system grows beyond "send data from A to B", teams end up stitching protocols together: one for telemetry, another for control, another for updates, another for whatever the device needs to do tomorrow. It works, but it leaves seams. And the bigger the deployment grows, the more those seams turn into operational cost. This post is about that landscape, and about a new entry in it.

IOTMP is a binary application-layer protocol that has just been published as an Internet-Draft at the IETF. It is not a fresh idea sketched on a whiteboard. The protocol captures nearly a decade of engineering decisions taken while building and operating a real IoT platform, but it is the first time it has been written down as a public, formal specification, with the explicit goal of being implementable by anyone.

Before getting into what IOTMP proposes, though, it is worth taking a careful look at the landscape it is entering. The case for any new protocol only makes sense once you understand what the existing ones do well, where they struggle, and what falls into the cracks between them.

Tiny devices with no memory, expensive radio links, unstable networks, dashboards that need real-time data, fleets that need to be updated, operators who need to open a remote shell at three in the morning. No single protocol was designed to handle all of that at once, so the ecosystem evolved as a toolbox rather than as a single tool.

Each of the major IoT protocols reflects a specific communication paradigm. MQTT is built around publish/subscribe. CoAP is a RESTful protocol for very small devices. HTTP is the universal language of web APIs. Each makes trade-offs that are perfectly reasonable in isolation, but those trade-offs do not always compose well when a single system needs to do several things at once.

Let's look at each of them in turn.

It is lightweight, mature, well-supported, and according to industry surveys it is used by more than half of all embedded developers.

Where MQTT shines is event-driven telemetry, especially when many devices need to send data that many consumers need to read. A weather station fleet publishing readings that feed dashboards, alert systems, and storage pipelines simultaneously is the textbook scenario. The broker handles the fan-out, the devices stay simple, and the consumers come and go without the producers having to know anything about them. MQTT v5 added useful refinements like Topic Aliases to avoid repeating topic strings, Response Topic and Correlation Data for request-response patterns, and shared subscriptions for load balancing, all of which have kept it relevant.

Where MQTT starts to feel tight is when the dominant pattern stops being pub/sub. The broker treats payloads as opaque bytes: it does not know what is inside, it cannot validate anything, and it has no idea what resources a device actually exposes. Server-to-device RPC, meaning telling a device to do something and waiting for a confirmation, is not native; it is built on top with paired command/response topics, application-defined conventions, and code on both ends to glue it all together. Streaming behavior is hardcoded in the firmware: if you want a device to sample every five seconds instead of every minute, you typically deploy new firmware rather than send a protocol-level instruction.

Think microcontrollers with a few kilobytes of RAM, battery-powered nodes that wake up briefly to send a packet and then go back to sleep, lossy low-power networks where every retransmission costs energy. CoAP runs over UDP, uses a fixed 4-byte header, and maps the familiar HTTP verbs (GET, POST, PUT, DELETE) onto a much tighter encoding. For that environment, it is excellent.

Its RESTful model also makes it a natural fit for device control: reading a sensor, setting an actuator, invoking an action all feel like a small, efficient HTTP request. The Observe extension adds a notification mechanism that lets a client subscribe to a resource and receive updates when it changes, which covers a useful chunk of the streaming use case.

Where CoAP runs into trouble is the public internet. UDP gives no persistent connection, which means devices behind NAT or firewalls (which is most devices in practice) cannot easily receive unsolicited requests from a server. Workarounds exist, like CoAP over TCP or CoAP over WebSockets, but the moment you reach for them you have given up part of what made CoAP attractive in the first place. CoAP also has no real concept of structured discovery beyond URI listings, no schema introspection, and no bidirectional data channels. It is a great protocol for what it was designed for, and a less natural fit outside of that.

For gateways, services, request-response APIs, firmware downloads, and webhook integrations, it is the obvious and correct choice.

The catch is overhead. HTTP headers are text. They repeat themselves on every request. Authentication tokens, content type declarations, host headers, user agents, all of it adds up, and for a constrained device sending a small reading every few seconds, the headers can easily be ten times the size of the actual payload. HTTP is also client-initiated by nature: the server cannot push anything to the device without the device asking first, which means either polling (wasteful) or upgrading to WebSockets (which is essentially adopting a different protocol). HTTP is fine as one piece of an IoT system. It struggles when asked to be the only piece.

Beyond the big three, there are protocols built specifically for richer device management and industrial use cases. LwM2M offers comprehensive device management with a deep object model and a standardized resource registry. DDS and OPC UA target industrial systems with very sophisticated capabilities. They are powerful, and where they fit they fit very well. But they come with implementation complexity that does not always make sense on a small microcontroller. LwM2M clients tend to bring in significantly larger libraries than MQTT or CoAP, and full DDS or OPC UA stacks routinely exceed what a microcontroller-class device can comfortably host.

MQTT for telemetry. HTTP for cloud API integration. Maybe CoAP or LwM2M for device management. Something proprietary for remote access or OTA. Each protocol is there because it covers something the others do not.

The gap is not that these protocols are bad. It is that none of them was designed to cover all the patterns that modern IoT systems actually need at the same time. There is no single protocol that natively handles periodic telemetry, on-demand streaming controlled by the server, bidirectional RPC, runtime API discovery, device-initiated operations against backend services, and persistent bidirectional channels for things like remote terminals or file transfers.

The table is not trying to crown a winner. It is trying to make a simpler point: each of these protocols optimizes for a different shape of problem, and there is a shape of problem that none of them was built to handle on its own. That shape is the persistent, bidirectional, full-featured link between a device and its platform, where the same channel needs to carry many different kinds of conversation.

That is the shape IOTMP is built for.

It is resource-oriented, symmetric (both ends can expose and invoke resources over the same connection), and built for the interaction patterns that have historically required combining several protocols: telemetry, remote control, real-time streaming, API description, and longer-lived operations like file transfers, remote shells, or firmware updates.

The "why now" question matters as much as the technical answer. IOTMP is not a fresh proposal. The protocol, together with PSON, the compact binary format it uses for payloads, has been in production since 2015 as the communication core of the Thinger.io platform, running across industrial, energy, and smart city deployments. What changed recently is that all of that engineering was written down as a public specification and submitted to the IETF as Internet-Drafts.

That is a different kind of commitment.

The IOTMP Linux client is a good example of how far the base primitives can go, because it ships with several extensions that would normally each require their own protocol stack, and all of them run over the same single persistent connection that also carries telemetry.

What is interesting is not any one of these in isolation, since there are mature tools for each, but the fact that all of them share the same connection that the device is already using for telemetry and RPC. A single device can be streaming sensor readings, responding to RPC calls, hosting a terminal session, and tunneling TCP traffic simultaneously, all multiplexed over one TCP connection identified by Stream IDs. None of these features required adding a new message type to the protocol: they are all built on the same RUN and STREAM_DATA primitives that handle a temperature reading.

This is what "expanding what is practically achievable on constrained devices" looks like in practice. Not a single feature, but the ability to consolidate operations that today require stitching together multiple tools, and to do it with the same code path the device is already running.

A concrete example of this in production is ThinRemote, our remote monitoring and access service for edge devices. ThinRemote is built directly on top of the IOTMP Linux client, and exposes exactly these capabilities (remote terminal, filesystem access, TCP tunneling, command execution) as a managed service for operators who need to reach distributed Linux devices in the field.

But the move from internal protocol to public draft is the move that matters, because it changes what kind of conversation is possible around it. Now anyone can read the spec, criticize it, propose changes, or build an interoperable implementation.

It is also worth being honest about scope. IOTMP is not trying to replace every IoT protocol.

That is the framing that fits both the technology and the moment: not a winner-takes-all replacement, but an open proposal for a piece of the puzzle that has been missing a good shared answer.

If the protocol details matter to you, like the framing, the encoding, the streaming compaction, the security model, the benchmarks against MQTT, CoAP, LwM2M, and HTTP on ESP32, they are all in the public drafts, on iotmp.io, and in the accompanying technical paper.

IOTMP is not presented as a new idea. It is presented as the open evolution of a communication core that has been quietly running in production for a decade. Writing it down, submitting it to the IETF, and inviting the rest of the ecosystem to read it, critique it, and implement it is probably the most honest thing engineering can do with a piece of technology that has reached this kind of maturity.

The conversation about the next generation of IoT protocols is going to happen one way or another. The point of opening IOTMP is to make sure that conversation is held in the open.

For any questions, join our Discord community: our team and other users will be happy to help.