Why layers help
When a temperature sensor in a greenhouse reports a reading, a surprising number of separate agreements are at work. Something decides which radio frequency to use. Something else decides how the data is addressed, how it is delivered reliably, and what the message actually means to the receiving application. Engineers split these jobs into layers, and each layer can be swapped without rewriting the rest.
Layers are also the easiest way for a newcomer to make sense of the many acronyms in this field. Wi-Fi, Bluetooth, LoRaWAN, IPv6, MQTT and HTTP are not rival answers to one question. They answer different questions at different layers, and a real product usually combines several of them.
The exact number of layers depends on which model you read. This guide uses four practical groupings, from the bottom up.
Layer 1: the physical link
The bottom layer is the radio or wire. It determines how bits become signals: the frequency band, the modulation, the transmit power and the resulting range and data rate. Short-range options such as Bluetooth Low Energy and Wi-Fi trade range for speed. Long-range options give up speed for distance. Wired links such as Ethernet sit here too, and some can carry power as well as data.
The physical choice sets hard limits. A radio that can reach several miles typically can only send small, infrequent messages. A radio that can stream video usually reaches only across a building and uses more energy. No higher layer can change that.
Layer 2: the local network
The link layer organizes how devices share a medium and form a local network. It handles who may transmit when, how a device joins, and how frames are checked for errors. This is where pairing, network keys and local link-level encryption usually live.
The shape of the local network also matters. Many devices connect in a star, with each one talking to a central access point or hub. Others form a mesh, where devices relay for each other to extend coverage. Some wide-area systems use a star of stars, with gateways collecting from many devices. These topologies are choices made at this layer, and they affect reliability, range and battery use.
Layer 3: addressing and transport
Above the local link, devices need addresses so that data can cross networks, and a way to deliver it. The Internet Protocol provides the addresses, in two versions: IPv4 and the much larger IPv6. On top of that sit transport protocols. TCP gives reliable, ordered delivery, at the cost of setup and acknowledgment traffic. UDP is lighter, sends individual datagrams and leaves reliability to the application, which suits constrained devices that send small readings.
Some very low-power links do not carry IP traffic natively. Those devices speak a compact local protocol and rely on a gateway to translate into IP on the other side. That is also why the same sensor may look very different depending on whether you see it from the radio side or the cloud side.
Layer 4: application messaging
The top layer defines what the data means and how applications exchange it. Here you find request-response styles familiar from the web, and lightweight messaging patterns designed for devices. The publish subscribe pattern, in which devices send messages to named topics through a broker and interested parties receive them, is widely used because devices do not need to know who is listening.
Above the transport, there is also the question of data format: a simple text structure, a compact binary encoding, or a vendor-specific layout. Agreeing on the format and the meaning of each field is often the hardest part, which is the core of why device interoperability remains difficult even when the lower layers match.
Putting a real example together
Consider a battery-powered soil sensor in a field. A plausible stack looks like this:
- Physical: a long-range, low-data-rate radio.
- Local network: a star topology, with a gateway at the edge of the field.
- Addressing and transport: the sensor uses a compact local format; the gateway converts the data into IP packets for the internet.
- Application: the gateway publishes each reading as a message that a cloud service stores and displays.
Now consider a smart plug in a home. The physical and link layers are likely home Wi-Fi. It gets an IP address from the router, keeps a connection open to a cloud service, and exchanges small control messages. Same four groupings, very different choices.
Where gateways and conversions fit
Because the layers are separate, a gateway can sit between two different worlds. It receives data from a local radio, may buffer or filter it, and forwards it over a wider network. The conversion happens at the layers it bridges. IoT gateways are common precisely because many constrained devices cannot speak the internet’s protocols directly.
What to ask when comparing technologies
When you meet a new term, ask which layer it belongs to and what it assumes about the layers around it. A few useful questions:
- Does it define the radio, the network, the messages, or several of these?
- What range and data rate does the physical layer allow?
- How does the device get power, and how often must it transmit? Battery life is shaped heavily by lower-layer choices.
- Who holds the keys, and how are devices authenticated when they join?
- Can devices from different makers work together at the application level, or only at the radio level?
Sorting a marketing claim by layer often reveals that two products “using the same technology” share only the radio. Likewise, a device that “supports” a standard might only implement part of it.
Security across layers
Each layer can protect or expose data. Link-layer encryption protects traffic on the local radio but not beyond the gateway. Transport-level encryption protects data across the internet. Application-level checks decide who may command a device. Weakness at one layer is not repaired by strength at another, which is one reason good practice is to secure every layer that is available and to keep firmware updates possible over the device’s life.
A note on change
Specific standards and their versions evolve, and details differ between products. Treat the layers as a stable way of thinking, and check current documentation for any particular technology before relying on its range, speed or security features.