2 Devices, Packets, and Layers
Addresses, Packets, Protocol Jobs, and IoT Evidence
2.1 Start With One Sensor Message
Imagine a sensor reading that must leave a device, cross a room, pass a gateway, and land in a dashboard without losing its meaning. The beginner mistake is to name protocols first. The useful move is to trace the message and ask what proof each hop needs before the next hop can matter.
Use this page as the route map for that trace. Packets, links, addresses, routers, and layers are not separate trivia; they are the handoff points that turn a local signal into a trustworthy IoT event.
2.2 Message Paths Need Evidence
A network lets one device send a message to another device through agreed rules. In IoT, that message might be a temperature reading, a door-state event, a firmware request, an alarm, or a command sent back to an actuator.
The first useful idea is simple: a network is not just a radio or cable. It is a chain of jobs. The system must identify who is talking, package the message, move it across one or more links, deliver it to the right application, and prove what happened when something is late or missing.
Packet Pete
“A packet you can’t trace is a claim you can’t defend — name the address, the route, and the hop that dropped it.”
Through this chapter, Pete stamps every message with the same delivery slip: who is talking, which hops carry it, and what proves it arrived.
If you only need the intuition, this layer is enough: networking is the delivery evidence path for IoT messages. Addresses identify endpoints, packets carry payloads plus headers, protocols define the rules, and layers keep each job reviewable.
Think of sending a parcel. The object inside is the payload. The label, tracking number, address, and handling marks are headers. The local courier, sorting center, long-haul carrier, and final courier each do different jobs. If the parcel is lost, a useful system can say where the evidence stopped. Networking uses the same pattern for digital messages.
For IoT, that evidence must survive gateways and time gaps. A sleepy sensor may report only once every few minutes, a gateway may buffer during an outage, and a dashboard may cache the last good value. The network review therefore asks for sender time, gateway time, broker or service time, acknowledgement behavior, and stale-data handling instead of trusting one visible screen.
That record turns a vague complaint such as “the network is down” into a specific next test at the lowest unproven boundary.
The One-Minute View
Identify
MAC addresses help with local link delivery, IP addresses support routed delivery, and ports hand traffic to the right application process.
Package
A packet or frame carries the application payload plus headers that describe delivery, ordering, integrity, or local-link handling.
Prove
Useful network designs keep evidence: timestamps, retries, acknowledgements, sequence checks, logs, and failure paths.
Local MAC Addressing
A MAC address is the local data-link address used by technologies such as Ethernet, Wi-Fi, and Bluetooth to move a frame across one network segment. It is often called a hardware address because it identifies a network interface controller for local delivery, but it is not a route to the application. A switch uses the destination MAC address to choose the next local port; a host still needs an IP address for routed delivery and a port number for the receiving application process.
When an Ethernet frame is created, the frame header carries a destination MAC address and a source MAC address before fields such as EtherType, payload data, and the frame check sequence. The MAC addresses change at each local hop as routers forward traffic between networks, while the destination IP address continues to identify the end host.
Classic MAC-48 addresses are 48 bits long. For humans, those bits are written as twelve hexadecimal digits, usually grouped as six pairs such as 01:23:45:67:89:ab or 01-23-45-67-89-ab; some tools use three groups of four digits such as 0123.4567.89ab. The first 24 bits are the Organizationally Unique Identifier, or OUI, assigned to the manufacturer, and the remaining 24 bits identify the interface within that allocation. Device labels often print separate MAC addresses for wired LAN and wireless LAN interfaces because each network interface needs its own local-link identity.
A local broadcast frame uses the destination MAC address ff:ff:ff:ff:ff:ff so every interface on the same link can inspect it. That is useful for discovery and address-resolution work, but it is still a local-link action, not a route across the Internet. Also treat observed MAC addresses as operational evidence, not permanent human identity: modern phones and some IoT operating systems may use locally administered or randomized Wi-Fi MAC addresses on different networks, while Ethernet controllers and managed device radios may keep stable assigned addresses.
Beginner Examples
-
A room sensor sends
temperature=22.4to a gateway. The payload is small, but the link and network headers still decide how it reaches the service. - A gateway receives a command for an actuator. A good design records whether the command was authorized, delivered, acknowledged, retried, or rejected.
- A dashboard showing stale data may have a sensor problem, a link problem, a route problem, a broker problem, or an application-cache problem. Layers help narrow the search.
Overview Knowledge Check
If this gives you the big picture, you can stop here. Continue to Practitioner when you need to design or review a real IoT message path.
2.3 Build the IoT Network Review
The practical networking workflow starts with one message and follows it end to end. The goal is not to memorize every protocol name. The goal is to know what each layer is responsible for and what evidence would prove that responsibility in a deployment.
Walkthrough: From Device Event to Review Evidence
- Name the message. State the payload, expected rate, freshness need, and consequence if it is delayed or lost.
- Name the local link. Record whether the first hop is wired, Wi-Fi, cellular, LPWAN, mesh, or another medium, and what local identity is used.
- Name the route. Record gateway, router, broker, service, or peer handoffs that move the message beyond the local link.
- Name the transport behavior. Decide whether the message needs connection setup, ordering, retransmission, low overhead, or application-level acknowledgement.
- Name the application endpoint. Record the topic, URL, port, resource, or command channel that receives the payload.
- Name the proof. Keep timestamps, sequence checks, acknowledgements, logs, counters, and the reopen trigger for later review.
Pete’s Delivery Slip
- Address: the named message and its endpoint — topic, URL, port, or command channel.
- Route: the local link first, then gateway, router, broker, or service handoffs.
- Receipt: timestamps, acknowledgements, sequence checks, logs, and the reopen trigger.
Worked Example: Tiny Reading, Large Delivery Context
Suppose a device reports a 12-byte application payload: a sensor identifier, timestamp delta, and scaled temperature value. The payload is not the whole network cost. Before link framing and security, a minimal IPv4 plus UDP path adds 20 bytes of IPv4 header and 8 bytes of UDP header. A minimal IPv6 plus UDP path adds 40 bytes of IPv6 header and 8 bytes of UDP header.
This example does not prove that one path is always better. It shows why IoT network reviews start with the message requirement. A once-per-hour soil reading, a safety command, and a firmware chunk have different timing, reliability, power, and evidence needs.
Incremental Practice
Beginner
For one sensor reading, write the payload, local link, gateway or router, destination service, and the timestamp evidence you expect to see.
Intermediate
Compare UDP and TCP for the same message. Record what reliability is provided by the transport and what must be handled by the application.
Advanced
Design the failure record for a missing command acknowledgement: retry limit, stale command handling, operator alert, and rollback action.
Practitioner Knowledge Check
If your job is to make a defensible network choice, you can stop here. Continue to Under the Hood for the layer mechanics behind the review.
2.4 Layer Contracts and Failures
Layering is a contract discipline. Each layer adds or interprets enough information for its own job, then hands the result to the next layer. The same application payload may be wrapped by transport, network, data-link, and physical-layer mechanisms before it leaves the device.
Layer Contract Ledger
Pete’s Delivery Slip
- Address: MAC on the local link, source and destination IP across networks, port at the endpoint.
- Route: gateway, hop behavior, and reachability toward the intended endpoint.
- Receipt: transport retransmissions and timeouts, application acknowledgements, and local-link retries.
Encapsulation and Overhead
Encapsulation means each layer wraps the data it receives. A transport header might add ports. A network header might add IP addresses. A data-link frame might add local delivery information and an integrity check. The receiver unwraps the same structure in the opposite direction.
This is why a tiny IoT payload can still consume meaningful airtime, energy, and memory. The review should include payload size, header overhead, retransmission behavior, and how often the message repeats. A design that is efficient for a mains-powered gateway may be wasteful for a sleeping sensor.
Address Boundaries
- MAC or local-link identity: helps deliver a frame on one local medium. It is not a global route by itself.
- IP address: supports routed delivery across networks. IPv4 uses 32-bit addresses; IPv6 uses 128-bit addresses.
- Port or application resource: helps the endpoint hand the packet to the correct application behavior.
- Device identity: may be separate from all of the above. Security, fleet management, and operations need to know which real device the network endpoint represents.
Common Pitfalls
- Confusing reachability with correctness. A packet arriving at a host does not prove the application accepted the right command or data meaning.
- Choosing a protocol by popularity. The right path depends on payload size, timing, loss tolerance, power, security, and operational evidence.
- Ignoring stale-data behavior. Many IoT failures are not dramatic outages; they are old values that look current.
- Hiding the gateway. Gateways often translate, buffer, filter, authenticate, and retry. Those are design responsibilities, not invisible plumbing.
Under-the-Hood Knowledge Check
At this depth, networking is a sequence of contracts. Each layer needs a job, a boundary, and evidence that the job was satisfied under normal and failure conditions.
2.5 Summary
- IoT networking moves messages through identifiable jobs: local link, route, transport behavior, application endpoint, and operating workflow.
- Packets carry payloads plus headers, so small telemetry can still have meaningful overhead.
- MAC addresses, IP addresses, ports, and device identities answer different questions and should not be treated as one thing.
- TCP, UDP, and application acknowledgements provide different reliability evidence.
- A useful network review traces observation, command, exception, and maintenance paths instead of trusting a diagram alone.
Design the network from the message outward: state the payload, choose the delivery behavior, trace the boundaries, and keep evidence that the right endpoint received the right meaning at the right time.
2.6 See Also
Layered Models Fundamentals
Deepen the OSI and TCP/IP model vocabulary used by this chapter.
IPv4 Addressing Fundamentals
Practice address structure, local networks, subnets, and route planning.
Networking Protocol Fundamentals
Review how protocol rules shape interoperability and evidence.
Medium Access Control (MAC)
See how the local link shares the medium and frames data before routing and transport take over.