People who design IoT systems need a shared vocabulary for the parts, and the usual answer is a layered model. Like the networking stack it borrows from, the model divides a system into layers with distinct responsibilities, so that a conversation about a Zigbee radio does not get tangled with one about a dashboard. The simplest version has three layers: perception, network and application. Practical versions add an edge layer and a platform or middleware layer between them, which is the five-layer form this guide uses.
No two reference models agree on the names, and ISO/IEC 30141, the international reference architecture, uses a richer set of domains rather than a strict stack. That is fine. The point of the model is to make responsibilities explicit, not to dictate a diagram. Use the layers as a checklist: for each one, what hardware or software fills it, what protocol crosses its boundaries, and who is responsible for it.
The sections below describe each layer, the interface to the next, and the trade-offs that show up where one layer ends and another starts.
Perception layer
The perception layer is where the physical world is measured and acted upon. It contains sensors, actuators and the microcontroller or processor that reads and drives them. Firmware at this layer handles sampling, calibration, filtering, local buffering and power management.
The main design decisions here are what to measure, how often, and how much to process before transmission. Reporting a raw stream is simplest but expensive in energy and bandwidth. Reporting only changes or exceptions is efficient but hides information that might matter later. A sensor that sends vibration spectra summarized into a few numbers has made an analytical decision on behalf of the whole system, which is fine as long as everyone knows it.
Identity also starts here. Every device needs a unique, unforgeable device identity, ideally anchored in a secure element, because every upper layer will trust data labeled with it.
Network layer
The network layer moves data between devices and the systems that consume it. It includes the local radio or wired link (Wi-Fi, Zigbee, Thread, LoRaWAN, NB-IoT, Ethernet), any gateway that bridges a non-IP local network onto IP, and the internet or private WAN path to the back end.
In the classic three-layer model this layer also carries the application protocol (MQTT, CoAP, HTTP) and transport security (TLS, DTLS). The connectivity overview covers how to choose a link; the key architectural question is whether devices are IP endpoints in their own right or whether a gateway represents them. That choice determines where addressing, encryption and authentication terminate, and it is hard to change after deployment.
Edge layer
Many models fold the edge into the network layer, but it has grown enough to deserve its own place. The edge layer is computation that happens near the devices rather than in a data center: on an edge gateway, an industrial PC on the factory floor, a vehicle computer, or the device itself.
The jobs that belong here are those that need low latency, must keep working when the uplink fails, or would be too expensive to do centrally. Examples are protocol translation from Modbus or OPC UA to MQTT, local alarm logic, downsampling of high-rate data, buffering during outages, and increasingly edge AI inference such as detecting a person in a camera frame before any video leaves the site.
The guide on edge, cloud and fog goes into where to draw this line. The architectural consequence is that the edge layer runs real software that needs the same lifecycle discipline as the cloud: version control, deployment, monitoring, and updates.
Platform layer
The platform or middleware layer is the back end that every device connects to. An IoT platform, whether a managed cloud service, an open-source stack or something built in house, provides a standard set of functions:
- Connectivity: a broker or endpoint that terminates device connections and authenticates them.
- Device management: a device registry, provisioning, device shadows, fleet management and OTA updates.
- Data handling: data ingestion, routing, a rule engine, storage in a time-series database and integration points such as APIs and webhooks.
This layer is where scalability is won or lost. A back end that handles a hundred devices on a single server rarely survives a hundred thousand without rework in how connections, storage and rules are partitioned. The platforms guide compares the options.
Application layer
The application layer is where the data becomes useful to people and other systems. It contains dashboards, alerting, mobile apps, analytics, digital twins and integrations with enterprise software such as maintenance systems, billing or an MES in a factory.
Everything below this layer is roughly the same across industries. The application layer is where domain knowledge lives: what a temperature excursion means for a vaccine, what a vibration signature means for a pump, what occupancy means for a building’s HVAC schedule. It is also where commands originate that travel back down the stack to actuators, which means the application layer needs an authorization model that limits who can send what to which device.
Cross-cutting concerns
Some responsibilities do not fit in one layer. They are easy to forget precisely because no layer owns them.
Security runs through every layer: hardware root of trust at perception, encryption on the network, isolation at the edge, identity and access control on the platform, and audit at the application. Treating security as a layer of its own tends to produce a system where each layer assumes another is handling it.
Identity and lifecycle follow a device from manufacturing through commissioning, operation and decommissioning. The device lifecycle spans all layers and is the subject of the device management guide.
Data governance concerns what is collected, where it is stored, who can access it and when it is deleted. Data sovereignty rules can force the edge and platform layers to be located in a specific jurisdiction.
Observability means knowing which devices are online, which are stale and what the pipeline is doing, usually through heartbeats and metrics at each layer.
Using the model in practice
The layered model is most valuable when you use it to allocate responsibility. For each layer, write down the component, the owner, the protocol at its upper boundary and what happens when the layer above or below is unavailable. Gaps and overlaps show up immediately. A common finding is that two layers both think they are responsible for buffering during outages and neither does it well, or that no layer owns the mapping from a device serial number to a customer.
The model also helps with vendor conversations. Platform vendors tend to describe the whole system as their product; the model makes clear which layers they actually supply and which you still have to build, integrate or operate.
Where to go next
- How IoT works: from sensor to cloud and back follows one reading through all five layers.
- IoT platforms explained looks in detail at the platform layer.
- The IoT data pipeline covers what happens to data from ingestion to action.
- Edge vs cloud vs fog helps decide what belongs at the edge layer.
Topics: architecture, layers, reference model