5 IoT Protocol Layers and Selection

OSI and TCP/IP explain how network messages are packaged, addressed, routed, and delivered. IoT reference models add a different lens: they name the functional jobs around the network path, including devices, gateways, edge processing, service support, applications, management, security, and operational decisions.

That extra lens matters because an IoT system is rarely just one device talking to one server. It may include constrained sensors, actuators, non-IP radios, gateways, brokers, local filtering, data stores, dashboards, fleet management, firmware updates, and human response workflows. A reference model gives reviewers a shared map for asking whether each responsibility has an owner and evidence trail.

For example, a cold-chain monitor may start with a calibrated temperature tag, pass through a BLE gateway in a truck, use cellular backhaul, land in a message broker, update a shipment record, and trigger a driver alert. OSI and TCP/IP help debug the radio link, IP route, TLS session, or MQTT exchange. The IoT reference model asks the surrounding questions: who proves the tag was calibrated, who owns gateway buffering during dead zones, which service normalizes units, what security evidence follows the reading, and which operations workflow acts on the alarm. That prevents a review from treating a successful packet trace as proof that the deployment is operationally ready, and exposes missing ownership before procurement locks in.

The next claim about overview: reference models name the jobs depends on Figure 5.5. Its diagram makes ITU IoT Reference Model and L4 explicit within the itu view keeps the model compact: devices generate or act on physical-world data, networks carry it, service support prepares it, and.

At ITU IoT Reference Model in Figure 5.5, compare the diagram with L4; then locate Application. That labelled check bounds the itu view keeps the model compact: devices generate or act on physical-world data, networks carry it, service support prepares it, and. For overview: reference models name the jobs, retain Application as evidence for the resulting choice.

The Four Questions

Overview Knowledge Check

If this is enough, you can stop here: use IoT reference models to check whether the system has clear owners for the device path, network path, service path, application path, and cross-cutting controls. Continue to Practitioner when you need to map a real deployment.

The practical use of an IoT reference model is not to decorate an architecture slide. It is to force a reviewable mapping before the team locks in radios, gateways, brokers, databases, or dashboards.

Start with one representative message: a reading, alarm, command, firmware status, or device-health event. Follow it from the physical endpoint to the decision it supports. At each layer, write down the responsibility, the evidence you expect to collect, and the owner who will maintain it.

Before choosing products, inspect Figure 5.6 to separate the responsibilities one representative message crosses. The expanded model is useful here because it prevents connectivity, processing, storage, applications, and operational work from being hidden inside one platform box.

Read Figure 5.6 upward from physical devices through connectivity and edge processing, then follow data accumulation and abstraction into applications, collaboration, and processes. At each level, name the owner and evidence for the representative message rather than assigning a product by habit. The ordered map connects technology selection to the deployment decision the message supports and exposes which failure boundaries still lack proof.

A Review Map for One Message

Practitioner Workflow

Choose a representative event that matters operationally, such as an alarm, command, health report, or compliance record. Map it first to OSI or TCP/IP for packet mechanics, then to the IoT reference model for functional responsibilities. Mark every point where its format, ownership, trust level, timing, or storage state changes. At each boundary, name the log, acknowledgement, timestamp, identity, or policy that proves correct behavior. Finish by testing the offline-device, full-gateway, unavailable-service, stale-data, and ignored-alert cases.

A Named Precedent: the M2M Service Platform

Machine-to-Machine (M2M) communication is a direct ancestor of today's IoT reference models, and it is worth naming because it already solved the same separation problem under different labels. M2M is device communication with no human step in the loop: sense, move the data across a network, extract and process the information, then act. Unlike SCADA, which was built for one isolated proprietary system, M2M assumed the device, network, and application would come from different vendors and still have to interoperate — the same cross-platform assumption an IoT reference model makes today.

The M2M Service Platform split that responsibility into four planes above a shared core network: a device plane for profile, registration, and authentication of each node; a user plane for accounts and access control; an application plane that merges device data into new services; and an access plane for the app or web delivery surface. That maps directly onto this chapter's Device, Data Services, and Application rows above — different names, the same boundaries, plus an explicit connectivity concept of its own: the M2M area network linking devices back to the platform.

M2M Node Classes: Capability Sets a Deployment Choice

M2M literature also grouped devices into node classes by capability rather than by protocol, a habit worth reusing whenever a review needs to say what a device can and cannot promise:

The M2M area network connecting those nodes back to the platform needed its own named requirements: fault tolerance, scalability, low cost and complexity, energy efficiency, dynamic configuration, minimized management traffic, and behavior that adapts to whether the traffic is data-centric, emergency, or real-time. Those are the same properties a Connectivity boundary review should still ask for today.

Practitioner Knowledge Check

The practitioner outcome is a short review record: one representative event, the layers it crosses, the boundary changes, the evidence collected, and the failure paths that still need design work.

The most common mistake is to read a reference model as if each layer must be a separate box, product, team, or protocol. In real IoT systems, one gateway may cover several responsibilities, one cloud platform may combine storage and application functions, and one security control may need evidence at many points.

That flexibility is useful only if the architecture names the boundaries. A reference model becomes valuable when it turns an ambiguous system into contracts: what each function accepts, what it emits, which trust assumptions it makes, and what proof it leaves behind.

Consider a gateway that receives LoRaWAN payloads, rejects frames that fail integrity checks, converts raw counts into engineering units, buffers readings during backhaul loss, and forwards alarms ahead of routine telemetry. Calling it "the gateway layer" is too vague. The review should split its contracts: the radio-facing side accepts device identity, frame counters, and link metadata; the processing side emits validated records with units and timestamps; the northbound side promises retry behavior, priority ordering, and error vocabulary that downstream services can rely on.

Those contracts also explain why security and management cannot be drawn as one box at the edge of the diagram. Device identity, firmware state, key rotation, clock quality, queue depth, schema version, and alert ownership all cross layer labels. A useful model therefore records where each claim is checked, which log or test proves it, and what design change forces the review to reopen. For a release gate, the model is useful only when those records can be tested against a real message path.

To turn the model into release evidence, inspect Figure 5.7 before treating a layer label as a complete contract. The diagram shows which questions must be answered where data or control crosses between responsibilities.

Read Figure 5.7 across the device-to-connectivity, connectivity-to-edge, and edge-to-data-and-application boundaries. For each crossing, pair accepted fields and trust assumptions with an owner, normal test, retained evidence, and recheck trigger. That sequence turns a flexible deployment—where one gateway may implement several roles—into explicit contracts. It connects the reference model to the release gate without requiring every layer to become a separate product.

Boundary Contracts

How the Models Fit Together

Use OSI and TCP/IP when tracing protocol mechanics: headers, addresses, ports, routes, sessions, transport behavior, and application exchanges. Move to a compact IoT model when the task is to communicate broad responsibilities across product, operations, security, and procurement. Use an expanded IoT model when edge decisions, stored data, abstraction, applications, and people or process outcomes must be separated. Across all three views, keep security and management visible along the whole path; identity, keys, updates, monitoring, logging, and access control do not belong to only one layer.

Under-the-Hood Knowledge Check

The under-the-hood rule is simple: do not ask which product belongs to which layer first. Ask which responsibility, boundary, and evidence contract the design must preserve.