Layered network models are the foundation of all IoT communication. This section covers the theoretical frameworks (OSI, TCP/IP) and IoT-specific reference models that enable billions of devices to communicate seamlessly.
Core concept: Network communication is organized into layers (OSI: 7 layers, TCP/IP: 4 layers) where each layer handles one specific function and adds its own header to data passing through - a process called encapsulation.
Why it matters: When IoT connectivity fails, understanding layers helps you diagnose whether the problem is physical (antenna/cable), network (IP/routing), or application (code/protocol) - each requires different troubleshooting.
Key takeaway: Think “bottom-up” when debugging: check Physical layer first (is the device powered and connected?), then Data Link (MAC address visible?), then Network (IP assigned?), and finally Application (service running?).
By the end of this section, you will be able to:
When devices communicate, the process is broken into layers, like floors of a building where each floor has a specific job. The bottom layer handles physical signals (like electrical pulses on a wire), and higher layers handle things like addressing and the actual data you want to send. This layered approach means you can change one part without rebuilding everything.
“I want to send my temperature reading to the cloud, but how does it actually get there?” wondered Sammy the Sensor. Max the Microcontroller pulled out a stack of colored cards. “Think of it like a layer cake! Each layer has one specific job, and they all work together.”
“The bottom layer is the Physical layer – that is the actual radio waves or electrical signals,” Max explained. “Above that is the Data Link layer, which makes sure your message does not get scrambled. Then the Network layer figures out the route, and the Transport layer makes sure everything arrives safely.”
Lila the LED lit up. “Oh! It is like sending a letter. The Physical layer is the mail truck, the Data Link is the envelope, the Network layer is the address, and the Transport layer is the tracking number that confirms delivery!”
“Exactly!” said Bella the Battery. “And the best part about layers is that I can swap out the Physical layer from Wi-Fi to Bluetooth without changing anything else above it. Each layer only talks to the layer above and below, so you can upgrade one piece without rebuilding the whole system. That is why standards matter – they let all of us IoT devices speak the same language!”
The foundational layered network models that enable global interoperability.
Topics covered:
Key figures:
How data is transformed as it moves through protocol layers.
Topics covered:
Key figures:
IoT-specific architectural frameworks beyond traditional networking.
Topics covered:
Key figures:
| Model | Layers | Use Case |
|---|---|---|
| OSI | 7 (Application to Physical) | Teaching, troubleshooting, detailed analysis |
| TCP/IP | 4 (Application to Network Access) | Practical implementation, development |
| ITU IoT | 4 + cross-cutting | Standards compliance, architecture planning |
| Cisco 7-Level | 7 (Devices to Collaboration) | IoT system design, edge computing decisions |
Scenario: A precision agriculture sensor (ESP32 with soil moisture probe) sends a 6-byte reading ({moisture: 42, temp: 18}) to a cloud dashboard via a LoRaWAN gateway and LTE backhaul. Walk through every protocol layer to understand exactly what happens to those 6 bytes and why the final on-air transmission is 51 bytes.
Step 1: Application layer – CoAP formats the reading
The sensor application calls coap_put("/soil/m42", payload):
| Field | Size | Content |
|---|---|---|
| CoAP header (Ver, Type, TKL, Code, MsgID) | 4 bytes | Version 1, Non-Confirmable, PUT, MsgID=0x1A3F |
| CoAP token | 2 bytes | 0xBE01 (matches request to response) |
| CoAP option (Uri-Path) | 0 bytes | Omitted (server knows device by DevEUI) |
| CoAP payload marker + data | 1 + 6 = 7 bytes | 0xFF + {42, 18, ...} |
| Subtotal | 13 bytes | Application PDU |
Step 2: Transport layer – UDP adds port addressing
UDP wraps the CoAP message with minimal header:
| Field | Size | Content |
|---|---|---|
| Source port | 2 bytes | 5683 (CoAP default) |
| Destination port | 2 bytes | 5683 |
| Length | 2 bytes | 21 (8 header + 13 payload) |
| Checksum | 2 bytes | Integrity check |
| Subtotal | 8 bytes | Added to 13 = 21 bytes |
Why UDP and not TCP? The sensor sleeps for 10 minutes between readings. TCP’s 3-way handshake would add 3 extra packets (78+ bytes) every wake cycle, doubling energy consumption for a 6-byte payload.
Step 3: Network layer – IPv6 with 6LoWPAN compression
Standard IPv6 adds a 40-byte header, which is larger than the entire payload plus transport header. 6LoWPAN header compression reduces this:
| Header version | Size | What it contains |
|---|---|---|
| Full IPv6 | 40 bytes | Source (16 B) + Dest (16 B) + Version/Class/Flow (4 B) + Payload length/Next/Hop (4 B) |
| 6LoWPAN compressed | 7 bytes | Context-based compression: addresses derived from link-layer IDs, next header = UDP (elided), hop limit = 64 (elided) |
Compression ratio: 40 / 7 = 5.7x reduction. Without 6LoWPAN, network overhead alone would be 6.7x the payload.
Running total: 7 + 8 + 13 = 28 bytes (6 bytes payload, 22 bytes protocol overhead).
Step 4: Data link layer – LoRaWAN MAC framing
LoRaWAN adds MAC header, device addressing, and integrity:
| Field | Size | Content |
|---|---|---|
| MHDR (MAC header) | 1 byte | Message type = Unconfirmed Data Up |
| DevAddr | 4 bytes | Device network address |
| FCtrl | 1 byte | ADR enabled, no pending, FOptsLen=0 |
| FCnt | 2 bytes | Frame counter (replay protection) |
| FPort | 1 byte | Application port 1 |
| FRMPayload | 28 bytes | Encrypted application data (from above) |
| MIC | 4 bytes | Message Integrity Code (AES-CMAC) |
| Subtotal | 13 bytes | Added to 28 = 41 bytes |
Step 5: Physical layer – LoRa modulation
LoRa adds a preamble and sync word for radio synchronization:
| Component | Size | Purpose |
|---|---|---|
| Preamble | 8 symbols | Receiver synchronization |
| Sync word | 2 symbols | Network identification |
| LoRa PHY header + CRC | ~2.25 + 2 bytes | Error detection |
| Payload | 41 bytes | MAC frame from above |
| Total on-air payload | ~51 bytes | Including PHY overhead |
At spreading factor SF7 and bandwidth 125 kHz: airtime = 41.2 ms.
Step 6: Overhead summary
| Layer | Bytes Added | Running Total | % of Total |
|---|---|---|---|
| Application data | 6 | 6 | 11.8% |
| CoAP header | 7 | 13 | 13.7% |
| UDP header | 8 | 21 | 15.7% |
| 6LoWPAN IPv6 | 7 | 28 | 13.7% |
| LoRaWAN MAC | 13 | 41 | 25.5% |
| LoRa PHY | 10 | 51 | 19.6% |
Goodput: 6 / 51 = 11.8%. Only 1 in every 8.5 bytes transmitted is actual sensor data.
Key insight: Understanding encapsulation layer by layer reveals why IoT protocol design obsesses over header size. Each layer has a legitimate job – addressing, integrity, encryption, synchronization – but for tiny payloads, the overhead dominates. This is why 6LoWPAN compression (saving 33 bytes), CoAP over HTTP (saving ~200 bytes), and UDP over TCP (saving 12+ bytes per packet) are not optimizations but necessities for constrained IoT networks. When your payload is 6 bytes, every header byte matters.
All 7 OSI layers typically run as software on the same device. Physical layer hardware is an exception. Fix: understand that layering is a software abstraction implemented in a protocol stack, not separate hardware boxes.
Cross-layer optimisation (sharing radio state from the physical layer directly with the application layer) is common in IoT for power savings but breaks the layered model guarantees. Fix: document any cross-layer optimisations explicitly, as they create tight coupling that complicates maintenance.
Each layer adds a header. In a constrained IoT frame of 127 bytes, headers from 5 layers can consume 40+ bytes, leaving little room for application data. Fix: calculate total header overhead for your chosen protocol stack before finalising the data model.
Start with the foundational models, then progress through practical implementation:
| Topic | Chapter | Description |
|---|---|---|
| OSI and TCP/IP Models | layered-fund-osi-tcpip.html | Compare the seven-layer OSI and four-layer TCP/IP models; map protocols to each layer |
| Encapsulation and PDUs | layered-fund-encapsulation-pdu.html | Trace how headers are added and stripped as data moves through protocol layers |
| IoT Reference Models | layered-fund-iot-reference-models.html | Apply ITU and Cisco 7-level frameworks to real IoT system architecture decisions |
| Labs and Implementation | layered-models-labs-and-impl.html | Configure MAC/IP addressing and implement protocol stack logic in Python |
| Layered Models Review | layered-models-review.html | Consolidate and test understanding across all layered model concepts |
| Networking Addressing and Subnetting | networking-addressing-and-subnetting.html | Calculate subnet masks, CIDR notation, and IPv6 addressing for IoT deployments |
IoT Reference Architectures:
Protocol Stack Components:
Addressing: