Internet of Things (IoT) Architecture

Internet of Things (IoT) Architecture defines the models, protocols, and data patterns required to connect, manage, and secure constrained physical devices operating over lossy, low-bandwidth, or remote networks.

Unlike standard cloud applications, IoT systems must balance extreme resource limitations at the edge with scalability and reliability in the cloud. Choosing the right communication protocols is critical to managing this balance.

1. The Constrained Device Paradigm

When designing IoT architectures, systems engineers must design around the limitations of constrained nodes (devices with limited CPU, RAM, storage, and battery life) and constrained networks (characterised by high packet loss, low bandwidth, and unstable connections).

The table below contrasts standard web systems with constrained IoT environments:

2. MQTT (Message Queuing Telemetry Transport)

MQTT is a lightweight, binary, publish-subscribe messaging protocol designed for constrained networks and low-bandwidth connections. Running over TCP, MQTT relies on a central broker to coordinate message delivery between publishers and subscribers.

Key Architectural Concepts in MQTT:

• Client-Broker Decoupling: Devices (publishers) send messages to specific hierarchical topics (e.g., factory/machine_1/temperature). Backend systems or other devices (subscribers) listen to those topics. The broker handles the routing, meaning clients never communicate directly with each other.
• Persistent TCP Connections: MQTT maintains an active TCP connection between the client and broker. A keep-alive timer ensures the link remains open with minimal traffic via small PINGREQ and PINGRESP exchanges.
• Quality of Service (QoS) Levels:
  • QoS 0 (At most once): The message is delivered according to the capabilities of the underlying network. No acknowledgement is sent; packets may be lost. (Lowest overhead).
  • QoS 1 (At least once): The broker sends a PUBACK message to acknowledge delivery. If the client does not receive the ack, it retries, potentially resulting in duplicates.
  • QoS 2 (Exactly once): A four-step handshake ensures the message is delivered exactly once. This resolves duplicate delivery but introduces significant network round-trip overhead.
• Last Will and Testament (LWT): When a client connects, it specifies an LWT message and topic. If the broker detects an unexpected disconnection (e.g., due to power loss or signal failure), it automatically publishes the LWT message to notify other systems of the device's offline status.
• Retained Messages: A publisher can mark a message to be retained by the broker. Any new subscriber to that topic immediately receives the last retained message, ensuring they do not have to wait for the next telemetry update.

3. CoAP (Constrained Application Protocol)

CoAP is a specialised web transfer protocol designed for use with constrained nodes and networks. Unlike MQTT, CoAP runs over UDP and is built on a request-response model that directly mirrors HTTP, making it highly compatible with existing RESTful architectures.

Key Architectural Concepts in CoAP:

• REST over UDP: CoAP maps directly to standard HTTP methods (GET, POST, PUT, DELETE) and uses URI paths (e.g., coap://[device_ip]/sensors/light). It avoids the heavy overhead of TCP handshake and stream management.
• Extremely Low Packet Overhead: CoAP has a compact 4-byte base binary header, drastically reducing packet size compared to HTTP text headers.
• Reliability Layer: Since UDP does not guarantee delivery, CoAP builds its own reliability mechanism using two message categories:
  • Confirmable (CON): Requires the receiver to return an Acknowledgement (ACK) packet. If the sender does not receive an ACK within a timeout period, it retries using exponential backoff.
  • Non-confirmable (NON): Fire-and-forget packets used for non-critical telemetry where occasional losses are acceptable.
• The Observe Option (RFC 7641): This extension allows a CoAP client to send a GET request containing an "Observe" flag. The CoAP server adds the client to a subscriber list and pushes asynchronous updates whenever the resource state changes, providing publish-subscribe-like behaviour without a broker.
• CoAP-to-HTTP Proxies: Because CoAP shares REST semantics with HTTP, translating between them is straightforward. An edge gateway can easily proxy CoAP requests from a constrained sensor network into standard HTTP requests for cloud APIs.

4. MQTT vs. CoAP: Protocol Calibration

Choosing between MQTT and CoAP depends on the physical architecture, power requirements, and network topologies of your deployment:

5. Strategic Utility (Why CTOs Should Care)

As a technology leader, protocol selection at the edge directly impacts battery replacement cycles, cellular data billing, and system scalability.

Energy Budget & Battery Optimisation

For battery-powered field sensors that sleep for hours and wake up for seconds, CoAP is typically superior. Establishing a new TCP/TLS connection for MQTT requires a multi-packet handshake that consumes substantial battery power. With CoAP over UDP/DTLS, the device wakes up, transmits a single packet, and immediately returns to low-power sleep. Conversely, for mains-powered devices that require instant, real-time command reception, MQTT is ideal, as the persistent TCP connection ensures low-latency message delivery.

Bandwidth Costs at Scale

If you manage a fleet of 500,000 devices communicating over cellular networks (NB-IoT/LTE-M), network ingress fees are a significant cost driver.

• MQTT requires keep-alive pings to maintain NAT bindings on cellular routers.
• CoAP avoids these pings but requires custom gateway-side logic to handle device reachability. Analyse the telemetry frequency: low-frequency reports favour CoAP's connectionless model, while high-frequency streaming favours MQTT.

Edge Gateways and Topology Patterns

In many industrial or home automation architectures, a hybrid approach is best. Constrained micro-controllers in a local mesh (using BLE, Zigbee, or Thread) communicate with a local Edge Gateway using CoAP. The Edge Gateway then consolidates, buffers, and publishes the data to the cloud using MQTT over a secure internet link. This minimises the processing load on the edge nodes while retaining a robust, stateful cloud integration.

Security & Device Identity Management

Standard TLS (used by MQTT) and DTLS (used by CoAP) require public-key cryptography to perform handshakes, which can overwhelm very low-end micro-controllers. Technology leaders must evaluate hardware capabilities:

• Ensure edge hardware includes a Cryptographic Co-processor or Secure Element to offload cryptographic calculations.
• Deploy mutual authentication (mTLS / mDTLS) rather than relying on weak password-based authentication.
• Establish a robust Firmware Over-The-Air (FOTA) update orchestration system to rotate device credentials and patch vulnerabilities at scale.

Explore Next

• OSI Model — Understand the layers of network communication and where IoT protocols like MQTT and CoAP operate.
• Event-Driven Architecture — Explore the publish-subscribe pattern, which forms the architectural foundation of MQTT.
• Exponential Backoff — Learn how to implement retry logic to prevent network storms when IoT devices reconnect.

References

• MQTT Standard (OASIS) — The official OASIS standard specification for MQTT, the lightweight publish-subscribe network protocol.
• CoAP RFC 7252 — The IETF specification defining the Constrained Application Protocol (CoAP) for constrained nodes and networks.