6 IoT Protocol Layers and Selection
6.1 Start With the Job of Each Protocol
A protocol choice is easier when you stop asking which name is fashionable and start asking what job must be done at each layer. One rule moves bits on a link, another identifies endpoints, another keeps a session reliable, and another gives the application a vocabulary.
Follow one IoT message down and back up the stack. The useful answer is not a protocol list; it is a reasoned selection that explains where each protocol adds evidence, overhead, security, or a gateway handoff.
Overview: Protocols Work as a Stack
IoT devices rarely use one protocol by itself. A useful design combines several agreements: how bits move on the medium, how frames share the link, how packets are addressed, how delivery is handled, and how application messages keep their meaning.
The point of a layered stack is separation of responsibility. Each layer should solve its own problem while preserving enough information for the next layer to do its job.
That separation prevents vague decisions such as "use MQTT" or "use LoRaWAN" from hiding missing work. MQTT describes an application messaging pattern, but it still depends on transport behavior, IP reachability, broker identity, credentials, payload schema, and operations. LoRaWAN describes a long-range low-power network service, but the application still has to decide payload format, freshness rules, acknowledgement needs, gateway visibility, and cloud handoff. CoAP, HTTP, BLE GATT, 6LoWPAN, IPv6, TCP, UDP, TLS, DTLS, Wi-Fi, Ethernet, and IEEE 802.15.4 each answer different questions.
A stack review therefore reads upward and downward. Upward means asking whether a lower layer preserves what the application needs: timestamp accuracy, command identity, duplicate handling, ordering, and stale-data behavior. Downward means asking whether an application choice fits the path below it: payload size, frame overhead, fragmentation, retry cost, sleep windows, radio duty cycle, gateway buffering, and backhaul reliability.
Gateways make the stack visible. A gateway may translate a local sensor frame into MQTT, convert CoAP resources into HTTP, compress or expand payloads, add timestamps, map identities, buffer during outages, or change security context. The gateway is not just a cable; it is a protocol boundary that needs its own evidence record.
Application
Defines message meaning: telemetry fields, commands, topics, resources, payload format, idempotency, and response expectations.
Transport
Defines delivery behavior: ports, streams, ordering, acknowledgements, congestion behavior, and when the application must handle loss itself.
Network and Adaptation
Defines addressing, routing, path scope, compression, fragmentation, and gateway boundaries for constrained links.
Link and Physical
Defines frame size, medium access, radio band or wire, reachability, duty cycle, interference, retries, and local diagnostics.
Do not compare MQTT, IPv6, Wi-Fi, and LoRaWAN as if they all solve the same problem. First identify the layer responsibility, then ask whether that layer's behavior fits the device and deployment.
Practitioner: Select the Stack from Constraints
Protocol selection should start with the system behavior, not a favorite protocol name. A practitioner asks what the device must send, how often, how far, under what power budget, through which gateway or service, and with what failure behavior.
The result is a short stack record: application protocol, payload format, transport behavior, network or adaptation layer, link technology, security wrapper, gateway handoff, and the evidence that proves the choices fit.
Selection Flow
Under the Hood: Boundaries Create Failure Modes
The hard part of a protocol stack is often not the protocol syntax. It is the boundary behavior: where payloads are wrapped, where reliability is added, where packets are compressed or fragmented, where identity changes, and where operators can see failure.
Under the hood, every layer adds context and cost. Headers, acknowledgements, retransmissions, security wrappers, and gateway buffers are useful when they serve the requirement; they are waste when they hide responsibility or exceed the link budget.
Boundary Evidence Record
A protocol family name is not a deployed contract. Check the exact profile, feature set, security mode, payload limits, gateway behavior, and operational owner before treating two devices or services as interoperable.
Protocol Stack Review Checklist
- Name the physical event, payload, receiver, and action the stack supports.
- Record payload size and how headers, security, retries, and fragmentation affect the constrained link.
- Decide where loss, duplicate messages, ordering, stale data, and command confirmation are handled.
- Identify every gateway or bridge that changes identity, timestamp, topic, path, credential, or quality marker.
- Keep packet traces, coverage evidence, power observations, and monitoring ownership with the decision record.
6.2 Summary
- IoT communication is a stack of agreements, not one protocol name.
- Application, transport, network/adaptation, link, and physical layers each carry a different responsibility.
- Protocol selection should start from payload meaning, freshness, delivery behavior, range, power, gateway handoff, and operational ownership.
- Header overhead, retransmissions, security wrappers, and fragmentation are design costs that should be visible in the decision record.
- Gateways are protocol boundaries: they need evidence for identity, timestamps, quality, buffering, credentials, and monitoring.
6.3 Key Takeaway
Choose IoT protocol stacks by matching each layer to a real constraint and recording the handoffs. A stack is credible when another engineer can see what each layer proves, what it hides, and who owns the failure cases.