3 OSI and TCP/IP Models
3.1 Start With the Layer That Owns the Failure
Networks do several jobs in sequence. They send a signal, deliver it across one local link, choose a route, deliver data, and give that data meaning. A fault in any one job may look like the same complaint: “it cannot connect.”
A protocol is a set of rules that two systems agree to follow. Internet Protocol is the set of rules used to address and route packets across networks. The Open Systems Interconnection (OSI) model sorts network protocols into seven layers. TCP means Transmission Control Protocol. The TCP/IP model groups the same kind of work into fewer layers. Use both models as troubleshooting maps. Prove one layer before testing the next.
3.2 Overview: OSI and TCP/IP Models Are Troubleshooting Maps
The two models are not competing memory tests. They are maps that separate network jobs. An actuator is a device that makes a physical change, such as opening a valve. A temperature reading, alarm, or actuator command is easier to debug when the team can name the job that failed. The job may be the physical signal, local delivery, routing, data delivery, or application meaning.
OSI is the more detailed reference model. Its seven layers are Physical, Data Link, Network, Transport, Session, Presentation, and Application. TCP/IP is the practical model used for Internet systems. Its usual four groups are Network Access, Internet, Transport, and Application. Engineers use OSI when they need precise fault language. They use TCP/IP when discussing working Internet systems.
If you only need the intuition, this layer is enough: start at the bottom when a device cannot communicate, and move upward only when each lower layer has evidence. Power, radio, addressing, routing, ports, payload format, and application behavior are different questions.
For example, suppose a greenhouse sensor stops updating a dashboard. Do not begin by rewriting the cloud software. First check power and the antenna. Next check whether the sensor joined its local network. A gateway is a device that links that local network to another network. Check whether the sensor or gateway received an address. Then test the route, firewall, and delivery method. Only after those tests should you inspect the message topic, data format, login details, and dashboard age. This order stops a weak radio link from being mistaken for an MQTT or database fault.
Keep a short record. Write one line for the last layer that worked, one for the first layer that failed, and one for the next test. For example, DHCP and SLAAC are two ways to obtain an address. If power and network joining work but both address methods fail, test addressing next. If the route and port work but the receiver rejects the message format, test the application next.
Inspect Figure 3.1 as a troubleshooting route. Power and signal evidence must be sound before association or link checks; those must pass before DHCP or SLAAC can establish an address, and address evidence must exist before route, port, and application checks can mean anything.
The upward arrows in Figure 3.1 are conditional, not a licence to skip layers: move from radio power to association, from association to an IP address, from address to route and port, and only then to the application. Record the first failed boundary and its evidence instead of reporting only that “the network is down.”
3.2.1 The One-Minute Model Comparison
OSI
A seven-layer reference model that is useful for explaining boundaries and isolating failures with precise language.
TCP/IP
A practical Internet architecture that groups real protocols around link access, IP routing, transport behavior, and application services.
IoT Use
A review method: prove the first hop, prove routed reachability, prove delivery behavior, then prove the application understood the message.
3.2.2 Beginner Examples
Read the examples from the lowest proved boundary upward. A sensor with a dead battery is a lower-layer failure, so changing MQTT topics cannot repair it. A device with link signal but no IP address has proved only the local medium, not routed reachability. A cloud host receiving a packet on the wrong port proves still more of the path, but not application correctness. The sequence shows how each observation narrows the investigation without claiming that later boundaries have passed.
3.2.3 Overview Knowledge Check
If this gives you the map, you can stop here. Continue to Practitioner when you need to write a review record for a real device path.
3.3 Practitioner: Build a Layer Trace Record
A layer trace record follows one IoT message from the device outward. It does not need packet-capture detail for every project. It does need enough evidence to prevent teams from blaming the wrong layer.
3.3.1 Trace Workflow
3.3.2 Worked Example: Missing Temperature Reading
A greenhouse sensor sends a periodic temperature reading through a gateway to a cloud dashboard. The dashboard shows stale data. A weak review says, "MQTT is down." A stronger review follows the layers:
The record prevents a common mistake: treating the dashboard symptom as the only failure. It shows which layers are working, which one is uncertain, and which application behavior must still protect the operator.
3.3.3 Practitioner Knowledge Check
If your job is to diagnose or defend a design choice, this layer trace is the practical artifact to keep. Continue to Under the Hood for the mechanics behind the boundary labels.
3.4 Under the Hood: Encapsulation, Handoffs, and Failure Boundaries
Encapsulation is the main mechanical idea behind both models. As an application message moves down the sender's stack, each layer adds information for its own job. The receiver reverses the process and removes those wrappers as the message moves upward.
3.4.1 Boundary Ledger
3.4.2 Encapsulation Rules That Matter in IoT
Apply the encapsulation rules as one review. First account for headers as both evidence and cost: addresses, ports, lengths, integrity, and control consume airtime and energy. Then choose the stack from payload, latency, loss, power, security, and visibility requirements rather than from layer names. Treat every gateway as an explicit boundary because it may translate, buffer, terminate security, rewrite addresses, or change acknowledgement behavior. Finally test application meaning, because routed reachability cannot prove that a payload was current, authorized, or applied to the right logical device.
3.4.3 Common Review Pitfalls
Avoid four review shortcuts in order. Do not memorize layer numbers without naming the proof expected at each boundary. Do not equate OSI and TCP/IP labels mechanically: even when Session, Presentation, and Application collapse into one TCP/IP layer, format, identity, and meaning still need records. Do not assume a gateway is transparent when it changes a contract. Finally, do not skip freshness semantics, because an old value that looks current is an application failure even when every packet was delivered.
3.4.4 Under-the-Hood Knowledge Check
At this depth, the models are evidence contracts. OSI gives precise names for the contracts. TCP/IP shows how Internet systems commonly group them. IoT design needs both: clear boundaries and a record that each boundary behaved as intended.
3.5 Implementation Ownership Across the Stack
Layering is also an implementation contract. An application author usually owns message meaning and the use of an application protocol; the operating system supplies transport and IP; a driver binds that stack to a controller; and the controller plus PHY put frames onto one local medium.
| Boundary | Typical owner | What it implements | What it can legitimately assume |
|---|---|---|---|
| Application | Product or service code | HTTP resource, MQTT topic and payload, request state, authentication use, retry policy at business level | A socket or library contract, not a particular cable |
| Transport | OS kernel or network library | TCP sequencing and congestion control, or UDP ports and checksum behavior | IP packet delivery with stated limits |
| Internet | OS network stack and routers | IPv4/IPv6 addressing, routing, hop limit, fragmentation behavior | A next-hop interface capable of carrying a packet |
| Driver/controller | OS driver, firmware, NIC or radio controller | Descriptor rings, frame transfer, link address, acknowledgements and retries where the link defines them | A specific controller and local link contract |
| PHY and medium | Transceiver and installed plant | Symbol timing, modulation or line coding, transmit/receive energy | Electrical, optical, or radio conditions within its budget |
Walk a browser request to see the handoffs. The browser constructs an HTTPS request and calls a socket API. The TLS and TCP implementations segment protected bytes and maintain ordered delivery. IP chooses a next hop. The Ethernet or Wi-Fi driver queues a frame for its controller, and the PHY emits electrical or radio symbols. At a router, the incoming link frame ends: the router validates it, routes the IP packet, decrements the hop limit, and builds a different link frame for the next medium. The server reverses the process until its application receives the request.
This is why the same application can run between dissimilar endpoints. A wired Linux gateway and a cellular phone do not share a layer-2 frame or PHY. They share interoperable application, transport, and IP behavior across routers that terminate and recreate the lower layers. Peer protocols are logically horizontal—TCP at one endpoint communicates with TCP at the other—while the actual data path is vertical through each local stack and across each physical hop.
The boundary is not absolute in every product. A microcontroller may use a userspace TCP/IP stack, a modem may offload TCP or TLS, and a smart NIC may implement parts of transport. Record actual ownership rather than assuming it from the layer name. The review question is always the same: which component creates this header or state, which component validates it, and which evidence proves the handoff?
3.6 Summary
- OSI is a detailed seven-layer reference model; TCP/IP is the practical Internet architecture with fewer grouped layers.
- Layered thinking is most valuable when it turns a vague connectivity problem into specific evidence questions.
- A useful IoT trace starts at the physical and link layers, then moves through routed reachability, transport behavior, and application meaning.
- Encapsulation adds useful control information but also adds overhead, airtime, and failure boundaries.
- Gateways, stale-data behavior, and application acknowledgements must be reviewed explicitly because reachability alone is not correctness.
3.7 Key Takeaway
Use OSI and TCP/IP as evidence maps: prove the lower-layer path, prove the routed and transport behavior, then prove that the application received the right meaning at the right time.
3.8 See Also
Encapsulation and PDUs
Follow how payloads become segments, packets, frames, and bits across the stack.
IoT Reference Models
Connect network layers to IoT architecture layers, gateways, edge processing, and services.
IoT Protocol Layers and Selection
Use layer evidence to select protocol stacks for range, power, reliability, and operations.
Datagrams and Packet Structure
Inspect the packet-level mechanics that make layer boundaries visible in practice.