34  OSI vs TCP/IP Comparison

In 60 Seconds

The OSI model (7 layers) is a theoretical reference for teaching and troubleshooting, while the TCP/IP model (4 layers) reflects the actual internet implementation. Both describe the same networking concepts at different abstraction levels, and understanding their mapping is essential for IoT development where protocols span both frameworks.

34.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Compare OSI and TCP/IP: Differentiate the theoretical 7-layer OSI model from the practical 4-layer TCP/IP model and explain when each framework applies
  • Map layer functions: Analyze what each layer answers (WHAT, HOW reliably, WHERE, HOW to transmit) and classify protocols by their layer assignment
  • Calculate encapsulation overhead: Apply header size data to compute goodput percentages and evaluate protocol stack efficiency for constrained IoT devices
  • Apply IoT context: Select appropriate protocol stacks by mapping traditional networking models to IoT-specific reference architectures and design requirements

34.2 Prerequisites

Required Chapters:

Estimated Time: 10 minutes

Why two models?

The OSI model (7 layers) was developed as a theoretical reference by ISO in the 1980s. The TCP/IP model (4 layers) evolved from actual internet implementation (ARPANET in the 1970s). Both describe the same networking concepts but at different abstraction levels.

Key insight: TCP/IP is what runs the internet; OSI is how we teach and troubleshoot networking concepts.

When to use each:

Situation Use
Learning networking OSI (more detailed)
Troubleshooting OSI (layer-by-layer isolation)
Protocol documentation Often TCP/IP
IoT development Both (understand mapping)

“Wait, there are TWO different models?” asked Sammy the Sensor, looking confused. “Which one is the real one?”

Max the Microcontroller held up two maps. “Think of it like having a detailed tourist map with every tiny street AND a simple highway map. The OSI model is the detailed map with 7 layers – great for learning and finding problems. The TCP/IP model is the highway map with just 4 layers – it is what the internet actually uses!”

“So when something goes wrong with my data,” said Lila the LED, “I use the OSI map to troubleshoot layer by layer. Is it a Physical problem? Data Link? Network? But when I am actually building an IoT app, I think in TCP/IP terms – Application, Transport, Internet, Link.”

Bella the Battery added, “The cool part is they describe the SAME road! OSI’s top three layers – Application, Presentation, and Session – all squish into TCP/IP’s single Application layer. Both maps get you to the same place; you just pick whichever one helps you most for the job at hand. For IoT, you really need to understand both!”

34.3 Model Comparison

The relationship between OSI and TCP/IP models is fundamental to understanding modern networking.

Side-by-side comparison diagram showing the 7-layer OSI model (Physical, Data Link, Network, Transport, Session, Presentation, Application) mapped to the 4-layer TCP/IP model (Link, Internet, Transport, Application) with arrows indicating how OSI layers combine into TCP/IP layers.

OSI vs TCP/IP vs IoT protocol stack comparison
Figure 34.1: OSI (7-layer) vs TCP/IP (4-layer) vs IoT protocol stack comparison.
Four-column diagram mapping networking questions to layers and IoT examples. WHAT to send maps to Application layer with MQTT temperature example. HOW reliably maps to Transport layer with TCP guaranteed vs UDP best-effort. WHERE to send maps to Network layer with IPv6 addressing and routing. HOW to transmit maps to Link and Physical layers with Wi-Fi frames and 2.4 GHz radio signals.
Figure 34.2: Alternative View: Layer Functions as Questions - Instead of memorizing layer names and protocols, this diagram frames each layer as answering a specific question. Application layer answers “WHAT to send?” (your sensor data and its meaning). Transport layer answers “HOW reliably?” (guaranteed or best-effort delivery). Network layer answers “WHERE to send?” (addressing and routing). Link/Physical layers answer “HOW to transmit?” (the physical medium and framing). This question-based approach helps students understand why layers exist and how to choose protocols for each question.

34.3.1 Layer Mapping Table

Layer OSI TCP/IP IoT Protocols
7 Application Application MQTT, CoAP
6 Presentation (Application) JSON, CBOR
5 Session (Application) TLS sessions
4 Transport Transport UDP, TCP
3 Network Internet IPv6, 6LoWPAN
2 Data Link Link 802.15.4, BLE
1 Physical Link Radio, Ethernet

34.4 Key Concepts

Understanding these fundamental concepts is essential for mastering network architectures:

  • Networking Standards: Agreed-upon protocols enabling interoperability between different manufacturers and systems globally
  • OSI Model (7 layers): Theoretical framework (Physical, Data Link, Network, Transport, Session, Presentation, Application)
  • TCP/IP Model (4 layers): Practical internet model (Link, Internet, Transport, Application); simplified and widely deployed
  • Layering Principle: Dividing complex systems into functional layers enables modularity and independent development
  • Encapsulation: Each layer adds its own header information to data from upper layers; essential for routing and switching
  • Decapsulation: Removal of headers at each layer as data moves up the stack at destination
  • MAC Addresses (Layer 2): 48-bit hardware identifiers (AA:BB:CC:DD:EE:FF) for local network delivery
  • IP Addresses (Layer 3): 32-bit (IPv4) or 128-bit (IPv6) identifiers enabling logical routing across networks
  • Subnet Masks: Determine network and host portions of IPv4 addresses; essential for routing decisions
  • IPv6: 128-bit addressing (\(3.4 \times 10^{38}\) addresses) solving IPv4 exhaustion; critical for IoT’s billions of devices
  • ARP (Address Resolution Protocol): Maps IP addresses to MAC addresses for local frame forwarding
  • IoT Reference Models: Specialized frameworks addressing IoT challenges (edge processing, massive scale, resource constraints)
  • Standards Organizations: IEEE, IETF, ISO, ITU, W3C set global protocols ensuring interoperability
  • Protocol Stacking: Multiple protocols work together at different layers (e.g., MQTT over TCP over IP over Wi-Fi)
  • Layer Abstraction: Each layer provides services to higher layers without revealing implementation details

34.5 Encapsulation and Protocol Overhead

Encapsulation is central to layered models. As data moves down the stack, each layer adds its own header, creating a nested structure. Headers at Layer 4 (TCP header) contain transport-level information, Layer 3 (IP header) contains routing information, and Layer 2 (Ethernet/802.15.4 header) contains hardware addressing. This design enables each layer to function independently while supporting the full stack.

Vertical diagram showing data encapsulation as it passes down through network layers. Application data gets wrapped with a TCP header at the Transport layer, then an IP header at the Network layer, then an Ethernet header and trailer at the Data Link layer, forming a complete frame ready for Physical layer transmission.

Data encapsulation through network layers
Figure 34.3: Data encapsulation and decapsulation process through network layers.

How much do protocol headers add to payload size? Let’s quantify encapsulation overhead for a typical IoT sensor packet.

Scenario: ESP32 sensor sends 10-byte temperature reading via MQTT over Wi-Fi to cloud.

Layer-by-layer encapsulation:

Layer Protocol Header Size Running Total % Overhead
Application MQTT 2 bytes (fixed) + 5 bytes (topic) = 7 bytes 10 + 7 = 17 70%
Transport TCP 20 bytes (no options) 17 + 20 = 37 270%
Network IPv4 20 bytes (no options) 37 + 20 = 57 470%
Data Link Wi-Fi (802.11) 34 bytes (MAC header + 4 FCS) 57 + 34 = 91 810%
Physical Preamble + PLCP 20 bytes equivalent 111 bytes on-air 1010%

Goodput calculation: \(\text{Goodput} = \frac{\text{Payload}}{\text{Total}} = \frac{10}{111} = 9\%\)

Only 9% of transmitted bytes are actual sensor data!

Energy cost (Wi-Fi radio at 350 mA TX, 802.11n 20 MHz, 54 Mbps): \(\text{Airtime} = \frac{111 \times 8\text{ bits}}{54 \times 10^6\text{ bps}} = 16.4\text{ microseconds}\) \(\text{Energy} = 350\text{ mA} \times 3.3\text{ V} \times 16.4\text{ µs} = 18.9\text{ µJ}\)

But TCP handshake adds: - 3-way handshake: 3 packets = 3 x (20 TCP + 20 IP + 34 Wi-Fi) = 222 bytes - 4-way close: 4 packets = 296 bytes - Total: 518 bytes for connection lifecycle

For 10-byte payload: \(\text{Total transmission} = 518 + 111 = 629\text{ bytes}\) \(\text{True goodput} = \frac{10}{629} = 1.6\%\)

Comparison with CoAP over UDP (constrained protocol):

Layer Protocol Header Size Running Total
Application CoAP 4 bytes (fixed header) 10 + 4 = 14
Transport UDP 8 bytes 14 + 8 = 22
Network IPv4 20 bytes 22 + 20 = 42
Data Link Wi-Fi 34 bytes 42 + 34 = 76
Physical Preamble 20 bytes 96 bytes

\(\text{Goodput} = \frac{10}{96} = 10.4\%\) (vs 9% for MQTT/TCP)

With 6LoWPAN compression (Zigbee/Thread):

Layer Protocol Header Size Running Total
Application CoAP 4 bytes 14
Transport UDP (compressed) 4 bytes 18
Network 6LoWPAN IPv6 (compressed) 7 bytes 25
Data Link 802.15.4 13 bytes 38
Physical Preamble + sync 6 bytes 44 bytes

\(\text{Goodput} = \frac{10}{44} = 22.7\%\)

Key insight: Protocol choice matters enormously for IoT. Moving from MQTT/TCP/Wi-Fi (111 bytes) to CoAP/UDP/6LoWPAN (44 bytes) reduces on-air payload by 60%, which translates directly to longer battery life for transmission-dominated power budgets.

Try It: Encapsulation Overhead Calculator

Adjust the payload size and protocol stack to see how encapsulation overhead changes for different IoT configurations.

34.6 Addressing Across Layers

MAC addressing at Layer 2 handles local network delivery. The 48-bit address (e.g., DC:A6:32:AB:CD:EF) consists of a 24-bit OUI (Organizationally Unique Identifier, identifying manufacturer) and a 24-bit device-specific portion. MAC addresses are only meaningful on the local network segment.

IP addressing at Layer 3 enables routing across networks. IPv4 uses 32-bit addresses (e.g., 192.168.1.100) but only provides approximately 4.3 billion addresses – exhausted by 2011. IPv6 uses 128-bit addresses providing \(3.4 \times 10^{38}\) addresses, essential for IoT’s billions of devices. Subnet masks partition IP addresses into network and host portions, determining routing decisions.

IPv6 advantages for IoT:

  • Virtually unlimited address space (no NAT needed)
  • IPsec support (recommended per RFC 6434, no longer mandatory as in the original IPv6 spec)
  • Auto-configuration (SLAAC)
  • Header compression with 6LoWPAN for constrained devices

ARP (Address Resolution Protocol) maps between IP and MAC addresses. When a host needs to send locally, it uses ARP to ask “who has IP 192.168.1.20?” and learns the corresponding MAC address. This enables Layer 2 switching based on Layer 3 routing decisions. Note: IPv6 replaces ARP with Neighbor Discovery Protocol (NDP), which uses ICMPv6 rather than broadcast.

34.7 IoT Reference Models

Traditional networking models (OSI and TCP/IP) focus on data transport. IoT reference models extend these to address the full data lifecycle from device to business insight:

  • Cisco IoT Reference Model (7 levels): Physical Devices and Controllers, Connectivity, Edge/Fog Computing, Data Accumulation, Data Abstraction, Application, Collaboration and Processes
  • ITU-T Y.2060: Standardized IoT architecture with device, network, service/application support, and application layers
  • IEEE 2413: Standard architectural framework for IoT interoperability

These models recognize that IoT systems require edge processing, massive scale support, resource-constrained devices, and security from device to cloud.

Layered diagram showing how common IoT protocols map to OSI layers. Physical layer shows 802.15.4 radio and LoRa. Data Link shows BLE and Zigbee. Network shows IPv6 and 6LoWPAN. Transport shows UDP and TCP. Application shows MQTT, CoAP, and HTTP.

IoT protocol stack diagram
Figure 34.4: IoT protocol stack mapping showing how common IoT protocols fit into OSI layers.
Common Misconception: “More Layers = Better Security”

The Myth: Many beginners believe that having more layers in a network model (7 layers in OSI vs 4 in TCP/IP) automatically provides better security or performance.

The Reality: Layer count has zero correlation with security or performance. Security depends on implementation at each layer, not layer quantity.

Real-World Data:

  • TLS/SSL encryption (operates at OSI Layer 6 Presentation) provides the same security whether you conceptualize it in the 7-layer OSI model or the 4-layer TCP/IP model
  • The majority of IoT vulnerabilities occur at the Application Layer due to weak passwords, unpatched firmware, and insecure APIs – regardless of whether you use OSI or TCP/IP modeling
  • IPsec encryption at Layer 3 (Network) provides identical protection in both models

Why This Matters: The OSI model’s 7 layers vs TCP/IP’s 4 layers is about abstraction level, not capability. TCP/IP combines OSI Layers 5-7 (Session, Presentation, Application) into a single Application Layer because real protocols like HTTP, MQTT, and CoAP handle all three functions without strict separation. Both models can implement security at multiple layers:

  • Layer 1: Physical security (locked server rooms)
  • Layer 2: MAC filtering, 802.1X authentication
  • Layer 3: IPsec, VPNs, network segmentation
  • Layer 4: TCP SYN flood protection, port filtering
  • Layer 7: TLS/SSL, authentication, input validation

Key Takeaway: Focus on implementing security controls at the right layers for your threat model, not on counting layers. A 4-layer model with proper encryption, authentication, and firewall rules is infinitely more secure than a 7-layer model with no security controls.

34.8 Worked Example: Layer-by-Layer Troubleshooting an IoT Failure

Scenario: A Zigbee temperature sensor in a smart office stopped sending data to the cloud dashboard 2 hours ago. The sensor’s LED still blinks (device is powered on). Use the OSI model to systematically isolate the fault.

Step 1 – Physical Layer (Layer 1): Is the radio transmitting?

Check Method Result
LED indicator Visual inspection Green blink = radio active
Signal strength Spectrum analyzer near device -65 dBm signal detected
Interference Check 2.4 GHz spectrum New microwave oven installed nearby – intermittent interference at 2.45 GHz

Verdict: Physical layer operational, but interference noted. Continue up the stack.

Step 2 – Data Link Layer (Layer 2): Is the MAC delivering frames?

Check Method Result
Frame delivery Zigbee sniffer (Wireshark + CC2531) Frames sent, 40% CRC errors (normal: <5%)
Retransmissions Count MAC retries 4 retries per frame (max = 5)
Association Check PAN ID and short address Device still associated with coordinator

Verdict: High CRC error rate from microwave interference. Frames eventually delivered after retries, but throughput degraded.

Step 3 – Network Layer (Layer 3): Is routing working?

Check Method Result
Neighbor table Query device via management Parent node present, RSSI = -78 dBm
Route to gateway Traceroute equivalent 3 hops, all responsive
IPv6 address Check 6LoWPAN assignment Valid link-local address

Verdict: Network routing operational. Problem is not at Layer 3.

Step 4 – Transport Layer (Layer 4): Is the data reaching the application?

Check Method Result
CoAP responses Capture at gateway CON requests sent, no ACK received from cloud
UDP port 5683 Gateway firewall logs Port blocked – firewall rule changed during maintenance 2 hours ago

Root Cause Found: A firewall rule change during routine IT maintenance blocked UDP port 5683 (CoAP) at the gateway. The sensor was transmitting correctly through all lower layers, but CoAP confirmable messages to the cloud were being dropped at the gateway firewall.

Resolution: Restore firewall rule allowing UDP 5683 outbound from the IoT VLAN. Data flow resumes within 30 seconds (CoAP retransmission backoff clears).

Why the OSI Model Helped: Without systematic layer-by-layer analysis, the team might have spent hours checking sensor batteries, replacing Zigbee coordinators, or reconfiguring mesh routes – none of which were the actual problem. The OSI model directed the investigation from physical up to transport, finding the fault at Layer 4 in under 15 minutes.

Common Pitfalls

“OSI is better than TCP/IP” is meaningless without specifying what dimension (conceptual clarity, practical implementation, IoT suitability). Fix: always specify the comparison dimension before making a relative claim about models.

Students sometimes compare OSI and TCP/IP exhaustively without connecting the comparison to practical protocol selection or design decisions. Fix: conclude every model comparison with a statement about when each model is most useful in practice.

Comparing only OSI and TCP/IP misses the IoT-specific three-layer or five-layer models that are most relevant for IoT deployment design. Fix: include at least one IoT-specific reference model in any review of networking model comparisons.

34.9 Summary

This chapter solidified understanding of layered network models and their practical application to IoT systems:

  • OSI (7-layer) and TCP/IP (4-layer) models provide theoretical and practical frameworks for organizing network protocols, with TCP/IP combining OSI layers 5-7 into Application and layers 1-2 into Link
  • Encapsulation proceeds top-down during transmission (Application to Transport to Network to Data Link to Physical) with each layer adding headers; decapsulation reverses this at the receiver
  • Protocol overhead is significant for IoT: A 10-byte sensor payload can balloon to 111 bytes on-air with MQTT/TCP/Wi-Fi (9% goodput), but only 44 bytes with CoAP/UDP/6LoWPAN (22.7% goodput)
  • MAC vs IP addressing: Layer 2 MAC addresses (48-bit hardware identifiers) enable local delivery, while Layer 3 IP addresses (32/128-bit logical) enable global routing across networks
  • IPv6 is essential for IoT: 128-bit addressing provides \(3.4 \times 10^{38}\) addresses, with SLAAC auto-configuration and 6LoWPAN header compression for constrained devices
  • IoT reference models extend traditional networking beyond OSI/TCP-IP with layers for edge computing, data accumulation, analytics, and business processes addressing IoT-specific needs
  • Systematic troubleshooting using the OSI model’s layer-by-layer approach isolates faults efficiently, as demonstrated in the worked example

34.10 What’s Next

Topic Chapter Description
Layered Models Resources Layered Models Resources Reference tools, video tutorials, and visual galleries for OSI and TCP/IP models
Routing Fundamentals Routing Fundamentals How routers use Layer 3 (Network layer) addressing and routing tables to forward packets across networks
Transport Protocols Transport Protocols Fundamentals Deep comparison of TCP versus UDP at Layer 4, including reliability trade-offs for IoT workloads
Application Protocols Application Protocols MQTT and CoAP at Layer 7: design choices, QoS levels, and IoT deployment patterns
6LoWPAN Compression 6LoWPAN How IPv6 header compression works over 802.15.4 networks to reduce encapsulation overhead
IoT Security Layers Security Threats Fundamentals Applying security controls at each OSI layer to protect constrained IoT devices