By the end of this chapter, you will be able to:
Core concept: Network communication is organized into layers (OSI: 7 layers, TCP/IP: 4 layers) where each layer handles one specific function and communicates only with layers directly above and below it.
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 approaches.
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?).
Before diving into this chapter, you should be familiar with:
The network layer model becomes intuitive when compared to sending a letter:
| Network Layer | Postal Analogy | What It Does |
|---|---|---|
| Application | Letter content | Your actual message |
| Presentation | Language/encoding | Translate to readable format |
| Session | Conversation tracking | Remember ongoing correspondence |
| Transport | Tracking number | Ensure delivery, handle errors |
| Network | ZIP codes, routing | Find the right city/region |
| Data Link | Local mail carrier | Deliver within your neighborhood |
| Physical | Roads, trucks, planes | The actual transport medium |
| Term | Simple Definition |
|---|---|
| OSI Model | A 7-layer reference model that describes how networks should work |
| TCP/IP Model | A simplified 4-layer model that the actual internet uses |
| Encapsulation | The process of wrapping data with headers at each layer |
| MAC Address | A permanent hardware address burned into your network card |
| IP Address | A logical network address that can change |
Network layers are like a team of helpers who each do one special job to get your message delivered!
Sammy the Sensor wanted to send a temperature reading to the cloud. “It’s 25 degrees Celsius!” said Sammy. But how does a tiny number travel all the way to a computer far away?
Lila the LED explained: “Think of it like sending a present to grandma! First, you write your message - that’s the Application Layer writing ‘25 degrees.’ Then you wrap it in paper - that’s the Transport Layer making sure nothing gets lost. Next, you put grandma’s address on it - that’s the Network Layer figuring out where to send it!”
Max the Microcontroller continued: “Then the mailman picks it up from your mailbox - that’s the Data Link Layer moving it between houses on your street. And finally, the actual truck drives it on the road - that’s the Physical Layer, the wires and radio waves!”
Bella the Battery was excited: “So every message I send goes through ALL these helpers?” “Exactly!” said Sammy. “And when the cloud sends a reply back, it goes through all the layers in reverse order!”
| Word | What It Means |
|---|---|
| Layer | A helper that does one special job in getting messages delivered |
| OSI Model | A plan with 7 helpers (layers) that shows how messages travel |
| TCP/IP | A simpler plan with 4 helpers that the internet actually uses |
| Protocol | Rules that everyone agrees to follow, like taking turns |
| Physical Layer | The actual roads and wires that carry messages |
The Layer Relay Game!
Notice how each step adds something or does one job. That’s exactly how network layers work!
Since the 1950s, countless manufacturers have developed their own proprietary hardware and software systems: - IBM mainframes - DEC minicomputers - Apple personal computers - Cisco routers - Ericsson mobile networks - … and thousands more
The miracle: Today, all these different systems successfully communicate with each other!
The reason: Agreed-upon standards and protocols.
Benefits:
| Organization | Role | Key IoT Standards |
|---|---|---|
| IEEE | Institute of Electrical and Electronics Engineers | 802.15.4 (Zigbee), 802.11 (Wi-Fi), P2413 (IoT reference architecture framework) |
| IETF | Internet Engineering Task Force | TCP/IP, CoAP, 6LoWPAN, RPL |
| OASIS | Organization for the Advancement of Structured Information Standards | MQTT, AMQP |
| ITU | International Telecommunication Union (UN agency) | IoT reference architecture, cellular standards |
| ISO | International Organization for Standardization | OSI model, security standards |
| W3C | World Wide Web Consortium | Web of Things (WoT), HTTP, REST APIs |
A protocol is an agreed (or accepted) set of rules for a procedure.
Just like human communication has protocols: - Handshakes when meeting - Taking turns speaking in conversation - Email format conventions - Telephone etiquette
Network protocols define rules for machine communication.
Think of network communication like going shopping - each layer has specific procedures:
Each layer has rules:
Failure at any layer means an unsuccessful trip! - Forgot wallet? Can’t buy anything - No parking? Can’t access store - Item out of stock? Trip fails
Same with network protocols - each layer must succeed for communication to work.
Layered networking models divide network communication processes into separate, but connected, domains (layers).
1. Understanding
2. Development
3. Troubleshooting
IoT Example:
Problem: Temperature sensor not sending data to cloud
Troubleshooting by layer:
Layer 1 (Physical): Sensor powered? Wi-Fi antenna?
Layer 2 (Data Link): Wi-Fi connected? MAC address correct?
Layer 3 (Network): IP address assigned? Gateway reachable?
Layer 4 (Transport): MQTT connection established?
Layer 5+ (Application): Correct API credentials? Data format valid?
The Open Systems Interconnection (OSI) model was developed by the International Organization for Standardization (ISO) as a conceptual framework.
Purpose:
Important: OSI is a theoretical model for research and teaching - not used directly in practice, but essential for understanding networking.
| Layer | Name | Function | Examples |
|---|---|---|---|
| 7 | Application | Network processes for applications | HTTP, MQTT, CoAP, DNS, SMTP |
| 6 | Presentation | Data representation, encryption, compression | TLS/SSL, JPEG, ASCII, JSON |
| 5 | Session | Manages sessions between applications | NetBIOS, RPC, PPTP |
| 4 | Transport | Reliable data transfer, error recovery | TCP, UDP |
| 3 | Network | Logical addressing, routing, path determination | IP (IPv4/IPv6), ICMP, routing protocols |
| 2 | Data Link | Physical addressing, frame delivery | Ethernet, Wi-Fi (MAC), PPP |
| 1 | Physical | Physical transmission of bits | Cables, wireless signals, voltage levels |
Top to bottom: “All People Seem To Need Data Processing” Bottom to top: “Please Do Not Throw Sausage Pizza Away”
This variant shows the same 7 layers but organized around what to check when debugging network issues. Most IoT problems (80%+) occur at Layers 1-3.
Pro Tip: When your IoT device won’t connect, resist the urge to start debugging application code! Check the basics first: Is it powered on? Is the antenna connected? Does it have an IP address?
When data travels down the layers, each layer adds its own header (and sometimes trailer) information. This process is called encapsulation.
Protocol Data Unit (PDU) Names:
| Layer | PDU Name | Contains |
|---|---|---|
| Application | Data/Message | User information |
| Transport | Segment (TCP) / Datagram (UDP) | Port numbers, sequence numbers |
| Network | Packet | Source/destination IP addresses |
| Data Link | Frame | MAC addresses, error checking |
| Physical | Bits | Raw 1s and 0s |
The TCP/IP (Transmission Control Protocol/Internet Protocol) model implements the layering principles of OSI for the specific protocol suite used on the Internet.
Key differences from OSI:
Purpose: Provides network services directly to user applications
IoT Protocols:
Implementation: Software (applications, firmware)
Purpose: End-to-end communication, reliability, flow control
Protocols:
Implementation: Operating system
Purpose: Logical addressing, routing between networks
Protocols:
Implementation: Operating system
Purpose: Physical transmission and local network delivery
Technologies:
Implementation: Hardware (network interface cards, drivers)
How much do TCP and UDP headers differ in size, and what does that mean for battery-powered IoT devices? Let’s quantify the cost.
Header sizes:
For a 10-byte sensor payload: \(\text{TCP packet} = 20\text{ (IP)} + 20\text{ (TCP)} + 10\text{ (data)} = 50\text{ bytes}\) \(\text{UDP packet} = 20\text{ (IP)} + 8\text{ (UDP)} + 10\text{ (data)} = 38\text{ bytes}\)
Overhead comparison: \(\text{TCP overhead} = \frac{40}{50} \times 100\% = 80\%\text{ is headers}\) \(\text{UDP overhead} = \frac{28}{38} \times 100\% = 73.7\%\text{ is headers}\)
But the real difference is connection setup:
TCP 3-way handshake for EVERY new connection:
\(\text{Total handshake} = 120\text{ bytes}\)
UDP has NO handshake: \(\text{Total setup} = 0\text{ bytes}\)
Full transmission cost (single message with new connection):
| Protocol | Setup | Data Packet | Total Bytes |
|---|---|---|---|
| TCP | 120 | 50 | 170 |
| UDP | 0 | 38 | 38 |
Energy calculation (LoRa radio at 120 mA TX current, SF7 at 125 kHz BW with ~5.5 kbps data rate):
\(\text{TCP energy} = 120\text{ mA} \times 0.249\text{ s} = 29.9\text{ mAs} = 0.0083\text{ mAh}\) \(\text{UDP energy} = 120\text{ mA} \times 0.056\text{ s} = 6.7\text{ mAs} = 0.0019\text{ mAh}\) \(\text{Savings} = \frac{0.0083 - 0.0019}{0.0083} \times 100\% = 77.1\%\)
At scale (1,000 sensors, 1 message/hour, 1 year = 8,760 hours):
Battery life per sensor (2,000 mAh battery, 1 message/hour):
Note: These theoretical values only account for TX energy. Real-world battery life is much shorter due to receive windows, sleep current, microcontroller processing, and battery self-discharge (typically 1-5 years for LoRa sensors).
With persistent TCP connection (1 handshake + keep-alives, 8,760 messages/year): \(\text{Per message} \approx 50\text{ bytes} + \text{periodic keep-alive overhead}\)
Key insight: UDP saves ~77% energy per message when TCP reconnects each time. With persistent TCP connections (as MQTT uses), the gap narrows significantly. For battery-powered IoT with sporadic transmissions, CoAP over UDP is more energy-efficient; for devices with stable connections, MQTT over TCP with persistent connections is viable.
| OSI Layers | TCP/IP Layer | Function |
|---|---|---|
| 7, 6, 5 | Application | User applications and services |
| 4 | Transport | End-to-end reliability |
| 3 | Internet | Routing and logical addressing |
| 2, 1 | Network Access | Physical media and local delivery |
Option A: Use OSI 7-layer model for detailed protocol analysis and troubleshooting - provides fine-grained separation of concerns (Session, Presentation layers explicit) Option B: Use TCP/IP 4-layer model for practical implementation and development - maps directly to real protocol stacks and operating system APIs Decision Factors: Choose OSI when teaching networking concepts, analyzing protocol interactions at each layer, or troubleshooting complex interoperability issues. Choose TCP/IP when developing applications, configuring systems, or working with actual network implementations. Most IoT development uses TCP/IP thinking, but understanding OSI helps diagnose issues where “the application works but messages are garbled” (Presentation layer) or “connections drop randomly” (Session layer).
Scenario: You’re creating a new web browser or messaging app.
What you choose:
What you MUST implement:
What you DON’T worry about:
The beauty of layering: Operating system handles Transport, Internet, and Network Access layers automatically!
Layered models enable innovation by allowing developers to focus on their specific layer without understanding every detail of others.
A web developer doesn’t need to understand radio frequency modulation to build a mobile web app!
When your IoT device isn’t communicating, use this systematic layer-by-layer approach:
80% of IoT connectivity problems are at Layers 1-3 (Physical, Data Link, Network). Resist the urge to immediately debug your application code!
Pro tip: Use these commands to check each layer:
# Layer 1: Is the device powered and transmitting?
# Check LEDs, use multimeter, check antenna connection
# Layer 2: Is the device associated with the network?
ip link show # Linux: Check interface status
iwconfig # Linux: Check Wi-Fi association
# Layer 3: Does the device have an IP and can reach the gateway?
ip addr show # Check IP address
ping 192.168.1.1 # Ping your gateway
# Layer 4+: Can the application connect?
curl -v http://api.example.com/health # Test HTTP
mosquitto_sub -t test/topic # Test MQTTReciting “Physical, Data Link, Network, Transport, Session, Presentation, Application” without understanding what each layer does is useless for design decisions. Fix: for each layer, name one protocol and one function it performs.
OSI has 7 layers; TCP/IP has 4. The OSI Application/Presentation/Session map to TCP/IP’s single Application layer. Fix: draw both models side by side with the mapping arrows shown explicitly.
TCP/IP is the protocol suite used in real networks. OSI is a reference model for understanding concepts. Fix: when describing a real protocol, map it to TCP/IP layers, and use OSI only for conceptual discussion.
This chapter covered the foundational layered network models that enable billions of devices to communicate:
Continue your journey through layered network models and IoT networking:
| Topic | Chapter | Description |
|---|---|---|
| Encapsulation and PDUs | Encapsulation and Protocol Data Units | Learn how data is wrapped with headers at each layer, the naming conventions for PDUs (segment, packet, frame, bits), and how de-encapsulation works on the receiving side |
| IoT Reference Models | IoT Reference Models | Explore IoT-specific architectures including the ITU-T Y.2060 model, the Cisco 7-Level reference model, and how they map to OSI and TCP/IP |
| Hands-on Implementation | Layered Models: Labs and Implementation | Apply layer concepts hands-on: MAC/IP addressing exercises, ARP inspection, and Python socket programming across TCP/IP layers |
| Network Addressing | IP Addressing and Subnetting | Calculate subnet masks, CIDR notation, and configure static and dynamic (DHCP) IP addressing for IoT deployments |
| Routing Fundamentals | Routing Protocols and RPL | Understand how routers forward packets between networks and how RPL optimizes routing for constrained IoT mesh networks |
| Transport Protocol Selection | TCP vs UDP in IoT | Select the right transport protocol for your IoT use case, comparing connection overhead, reliability guarantees, and energy consumption |
Scenario: Set up a smart thermostat to connect to home Wi-Fi and send temperature readings to a cloud service.
Layer-by-Layer Setup:
| OSI Layer | What You Configure | Example |
|---|---|---|
| Layer 7 (Application) | Cloud service account | Create account at cloud.thermostat.com |
| Layer 6 (Presentation) | (Automatic) Data format | Thermostat sends JSON: {"temp": 72} |
| Layer 5 (Session) | (Automatic) Connection keep-alive | HTTPS connection stays open |
| Layer 4 (Transport) | (Automatic) TCP ensures delivery | Thermostat uses TCP port 443 |
| Layer 3 (Network) | IP addressing via DHCP | Thermostat receives 192.168.1.x from router |
| Layer 2 (Data Link) | Wi-Fi network and password | Select “MyHomeWiFi”, enter WPA2 password |
| Layer 1 (Physical) | (Automatic) Radio transmission | 2.4 GHz Wi-Fi signals |
What you actually configure: Network name, password, cloud account. Everything else handled automatically by firmware.
If it doesn’t work: Check Layer 1-3 first (Wi-Fi signal, password, IP assignment). 95% of home IoT issues are here.
Scenario: Deploy 50 vibration sensors in a factory using Zigbee mesh network connected to a gateway that forwards data via Ethernet to a SCADA system.
Layer-by-Layer Architecture:
| OSI Layer | Sensor Node | Gateway | SCADA Server |
|---|---|---|---|
| Layer 7 (Application) | Vibration monitoring app | Protocol translation (Zigbee to Modbus) | SCADA HMI software |
| Layer 6 (Presentation) | Binary sensor data | Data format conversion | Historian database format |
| Layer 5 (Session) | Keep-alive packets | Connection management | Poll sensors every 1 min |
| Layer 4 (Transport) | N/A (Zigbee handles reliability) | TCP to SCADA | TCP port 502 (Modbus) |
| Layer 3 (Network) | Zigbee routing (mesh) | IPv4: 192.168.10.50 | IPv4: 192.168.10.100 |
| Layer 2 (Data Link) | IEEE 802.15.4 MAC | Zigbee + Ethernet | Ethernet |
| Layer 1 (Physical) | 2.4 GHz radio | 2.4 GHz radio + Cat6 cable | Cat6 cable |
Key Complexity: Gateway operates at multiple layers simultaneously: - Layers 1-3: Participates in Zigbee mesh (coordinator node) - Layers 3-7: Acts as Ethernet client to SCADA - Layer 7: Translates between Zigbee Application Protocol and Modbus
Troubleshooting Approach:
Scenario: Smart city deployment with 10,000 sensors using multiple protocols (LoRaWAN, NB-IoT, Wi-Fi) feeding into edge gateways that perform local analytics before sending aggregated data to cloud via 4G/5G.
Layer-by-Layer Data Flow:
Stage 1: Sensor to Edge Gateway
| OSI Layer | LoRaWAN Sensor | NB-IoT Sensor | Wi-Fi Sensor |
|---|---|---|---|
| Layer 7 | Application data (12 bytes) | Application data (12 bytes) | CoAP (4-byte header) |
| Layer 6 | (None) | (None) | CBOR binary encoding |
| Layer 5 | (None) | (None) | (None - stateless) |
| Layer 4 | (None - LoRaWAN integrated) | UDP (8 bytes) | UDP (8 bytes) |
| Layer 3 | (None - no IP) | IPv6 + 6LoWPAN (7 bytes) | IPv4 (20 bytes) |
| Layer 2 | LoRaWAN MAC (13 bytes) | NB-IoT MAC | Wi-Fi 802.11 (36 bytes) |
| Layer 1 | LoRa modulation (SF7-12) | LTE Cat-M1 | 2.4/5 GHz OFDM |
Stage 2: Edge Gateway Processing (OSI doesn’t apply - this is data-at-rest) - Aggregate 100 sensor readings into 1 summary packet - Local ML model detects anomalies - Store raw data locally (24-hour buffer) - Forward: Summaries (every 15 min) + Alerts (immediate)
Stage 3: Edge Gateway to Cloud
| OSI Layer | Edge Gateway to Cloud |
|---|---|
| Layer 7 | HTTPS POST with JSON (aggregated data) or MQTT (alerts) |
| Layer 6 | TLS 1.3 encryption |
| Layer 5 | Persistent HTTPS or MQTT connection |
| Layer 4 | TCP port 443 (HTTPS) or 8883 (MQTT/TLS) |
| Layer 3 | IPv4 (cellular carrier NAT) or IPv6 |
| Layer 2 | 4G LTE or 5G NR MAC |
| Layer 1 | Cellular radio (700-2600 MHz bands) |
Why This Is Complex:
Troubleshooting This System Requires Understanding ALL Layers:
Scenario: A building management system reports that 12 of 200 Zigbee temperature sensors on Floor 3 stopped reporting data at 2:15 PM. All 12 sensors are in the east wing. The remaining 188 sensors (including west wing of Floor 3) continue operating normally. The network uses Zigbee (802.15.4) sensors connecting through 4 routers to a floor coordinator, which sends data via Ethernet to the building management server. Apply the bottom-up OSI troubleshooting method to isolate the fault.
Layer 1 – Physical: Is there a signal?
| Check | Method | Result |
|---|---|---|
| Are the 12 sensors powered? | Check battery voltage via maintenance LED | All 12 show green LED (battery OK) |
| Is the radio transmitting? | Spectrum analyzer near east wing | Zigbee channel 15 shows normal 802.15.4 bursts from sensors |
| Is the east-wing router powered? | Visual inspection | Router R3-East power LED is ON |
| Is the router’s Ethernet cable connected? | Check patch panel | Cable is seated in port 47 |
Finding: Physical layer appears healthy. Sensors are transmitting, router is powered, cable is connected. Move to Layer 2.
Layer 2 – Data Link: Can devices see each other?
| Check | Method | Result |
|---|---|---|
| Do sensors associate with router R3-East? | Query router’s association table | 12 sensors show as “associated” (MAC addresses present) |
| Is the router forwarding frames? | Monitor router’s frame counter | TX counter is incrementing (router IS sending frames) |
| Does the floor coordinator see R3-East? | Query coordinator’s neighbor table | R3-East MAC address is NOT present |
| Does the coordinator see the other 3 routers? | Query coordinator’s neighbor table | R3-West, R3-North, R3-South all present |
Finding: Data Link issue between R3-East and the floor coordinator. The router’s Ethernet interface is not visible to the coordinator. The cable is plugged in (Layer 1 OK), but the link is not established.
Deeper Layer 2 investigation:
| Check | Method | Result |
|---|---|---|
| Ethernet link LED on router R3-East? | Visual inspection | Link LED is OFF (no link detected) |
| Ethernet link LED on switch port 47? | Check switch front panel | Port 47 LED is OFF |
| Cable continuity test | Cable tester on patch cable | Pairs 1-2 and 3-6 pass. Pair 4-5 is OPEN |
Root cause found: The Ethernet cable connecting router R3-East to the switch has a broken pair. While standard 100BASE-TX only uses pairs 1-2 and 3-6 for data, this switch requires all 4 pairs for PoE (Power over Ethernet) negotiation. When pair 4-5 broke (likely from cable being pinched by a ceiling tile at 2:15 PM during maintenance), the switch disabled the port entirely as a PoE safety measure, taking down the Ethernet link even though the data pairs were functional.
Layer-by-layer diagnosis time:
| Layer | Time Spent | Outcome |
|---|---|---|
| Layer 1 (Physical) | 5 minutes | Eliminated power and radio as causes |
| Layer 2 (Data Link) | 8 minutes | Identified missing neighbor, found cable fault |
| Layer 3 (Network) | 0 minutes | Not reached – fault isolated at Layer 2 |
| Layer 4 (Transport) | 0 minutes | Not reached |
| Layer 7 (Application) | 0 minutes | Not reached |
| Total | 13 minutes | Cable replacement restores all 12 sensors |
Why bottom-up worked here: A top-down approach would have started at the application layer, checking server logs, MQTT broker connections, and sensor firmware – none of which were faulty. This could waste 30+ minutes investigating software before discovering a physical cable problem. Bottom-up eliminated physical causes in 5 minutes and found the fault at Layer 2 in 8 more minutes.
Why this fault was tricky: The cable passed a basic continuity test on the data pairs (1-2, 3-6). Only testing all 4 pairs revealed the PoE-related failure. In IoT deployments with PoE-powered devices, a “good” data cable can still cause link failure if auxiliary pairs are damaged.
Key insight: The OSI layered model is not just theoretical – it is a practical diagnostic framework. By systematically checking each layer from bottom to top, you avoid the common mistake of jumping to application-layer debugging when the real problem is a 50-cent cable. In IoT deployments, the majority of connectivity failures (estimated 60-70%) originate at Layers 1-2 (physical and data link), making the bottom-up approach the most efficient diagnostic strategy.