2  Communication Models for IoT

2.1 Start With Flow, Not Protocol

Communication models describe how a message behaves before the team chooses HTTP, CoAP, MQTT, AMQP, WebSocket, a queue, or a stream. The model names who starts the exchange, who consumes it, whether the sender waits, what happens during outage, and what evidence proves the flow worked.

In a refrigerated warehouse, the same gateway may need four different communication models. Temperature telemetry can be pushed every minute and published to a broker so a dashboard, history store, alert service, and maintenance model can consume it independently. A compressor setpoint change should behave like a request-response command: the operator needs to know whether the gateway accepted, rejected, timed out, or deferred the change. A door-left-open event should run locally even if the cloud path is down. A maintenance report can be queued asynchronously because a technician can wait for a final work-order reference.

Beginner Rule

Pick the communication model per flow. A device can publish telemetry, raise local events, accept request-response commands, and replay buffered history without forcing all flows into one pattern.

Communication models turn message movement into an architecture boundary.

Request-response fits a command, query, enrollment step, or configuration change that needs an accepted-or-rejected result. Publish-subscribe fits telemetry, alarms, status, and fan-out where new consumers may appear later. Event-driven design fits meaningful state changes such as threshold crossings, failures, workflow transitions, and local safety actions.

Request-Response

One caller asks one target for a result, then uses the response to continue or stop.

Publish-Subscribe

Producers publish to a topic so dashboards, storage, analytics, and operations tools can consume independently.

Event-Driven

A meaningful change triggers local logic, queued work, downstream processing, or an operator workflow.

Hybrid Flow

A real system combines models, but each major flow still needs its own owner, failure behavior, and evidence.

The core patterns differ in waiting behavior, consumer coupling, and recovery evidence.

2.2 Separate Timing and Outage Needs

The practical review is a flow table. For each flow, classify whether the source pushes or the consumer pulls, whether the sender waits synchronously or hands off asynchronously, whether the data needs fan-out, and what recovery evidence is required after outage.

Push, pull, synchronous, and asynchronous are timing behaviors that can combine with the core patterns.

Selection Rule

Do not choose one model for the whole system. Choose one model per important flow, then document why the selected protocol currently implements that model well enough.

For a cold-storage facility, temperature telemetry usually fits push plus publish-subscribe because dashboards, history, alerting, and analytics can consume the same reading. A high-temperature alarm should trigger local event-driven behavior so safety action does not depend on cloud availability. A compressor setpoint change needs request-response because the operator must know whether the command was accepted, rejected, stale, unauthorized, or blocked by local limits.

Make the table concrete enough to test. For telemetry, write the topic name, timestamp rule, duplicate rule, and buffered replay rule. For an alarm, record the local threshold, latch behavior, operator acknowledgement, and the cloud event that proves it was later synchronized. For a command, record the requester role, freshness window, device state precondition, rejection reason, and audit event. Those fields matter more than whether the first implementation uses MQTT, CoAP observe, HTTP polling, WebSocket, or an AMQP queue.

Selection moves from flow intent through timing, fan-out, energy, reliability, replay, and evidence to a per-flow model.

Telemetry Flow

Usually push and publish-subscribe, with schema, timestamp, retention, duplicate, and replay rules.

Alarm Flow

Usually event-driven locally, with latch behavior, acknowledgement, replay marker, and operator visibility.

Command Flow

Usually request-response, with requester role, freshness check, accepted state, rejection reason, and audit event.

Workflow Flow

Often asynchronous, with correlation key, retry status, dead-letter handling, and final work reference.

2.3 Model as Evidence Contract

Under the hood, a communication model is a contract about state, timing, replay, and ownership. A publish-subscribe flow is weak if nobody owns topic contracts or duplicate handling. A request-response flow is weak if the response only proves that a packet arrived, not that the command was fresh, authorized, and applied. An event-driven flow is weak if handlers are not idempotent or if local and cloud records disagree after recovery.

Evidence Fields

• Initiator: device, gateway, cloud service, application, operator, or scheduled job.
• Consumers: direct target, topic subscribers, workers, dashboard, storage, analytics, or support workflow.
• Waiting behavior: blocking result, queued handoff, retained state, event history, or delayed completion.
• Failure behavior: timeout, retry, buffer, replay, drop, local fallback, manual review, or dead-letter path.
• Ownership: schema owner, command owner, handler owner, operations owner, and review trigger.

The review record keeps protocol changes from erasing the original model reasoning, describing behavior first and implementation second.

Protocols can change while the model remains stable. A telemetry path can move from one broker to another if the topic contract, timestamp rule, retained-state rule, replay behavior, and consumer expectations still hold. A command path can change transport if it still preserves freshness, authorization, applied-state proof, rejection reasons, and audit evidence. That is why the review record should describe behavior first and implementation second.

The hardest failures usually come from hidden model changes. A “simple” dashboard feature may turn one telemetry consumer into five consumers and require publish-subscribe fan-out. A firmware update may turn a configuration write into a safety-relevant command that needs a response contract. A battery-saving change may make pull polling impractical because devices sleep longer. Treat those changes as model changes, not only protocol changes.

Reopen the Decision

Recheck the model when a new consumer appears, latency targets tighten, a flow becomes safety-relevant, devices sleep longer, outage windows grow, replay becomes required, or ownership moves between device, gateway, cloud, and operations teams.

2.4 Summary

IoT communication models explain how each flow behaves: who starts it, who consumes it, whether the sender waits, what happens during outage, and which evidence proves the behavior. Start with the flow, split mixed requirements, choose request-response, publish-subscribe, event-driven, push, pull, synchronous, asynchronous, or hybrid behavior where it fits, and then choose the protocol that implements the selected model with clear ownership.

2.5 Key Takeaway

Choose communication models from flow evidence, not protocol preference: telemetry, alarms, commands, and workflows often need different timing, fan-out, outage, replay, and ownership contracts.

2.6 See Also

• Communication and Protocol Bridging - translating communication models across gateway and protocol boundaries.
• Publish/Subscribe Routing - routing topic-based flows through brokers, queues, gateways, and consumers.
• State Machines in IoT - making event-driven behavior explicit with states, guards, actions, and failure paths.
• Multi-Hop Fundamentals - reviewing communication behavior when messages depend on relays and route evidence.