Core Networking · Study deck

IoT Protocol Layers and Selection

A protocol is an agreed set of rules for an exchange.

Packet Pete is your guide for this deck.

fundprotocolslayered

Packet Pete, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: At each boundary, write the job: move bits, share the local link, name the sender and receiver, carry the message, protect it, route it to a service, and show the final result.
Explain: The result is a short stack record: application protocol, payload format, transport behavior, network or adaptation layer, link technology, security wrapper, gateway handoff, and the evidence that proves the choices fit.
Explain: If a packet arrives 300 ms late after a radio retry, the correct action may be to discard it rather than move the maze toward an obsolete orientation.

Major section

Start With the Job of Each Protocol · Overview: Protocols Work as a Stack

Saying that the device is connected hides which rule or hand-off failed.

At each boundary, write the job: move bits, share the local link, name the sender and receiver, carry the message, protect it, route it to a service, and show the final result.

A protocol stack is a set of layer agreements, not a single product choice.

Major section

Practitioner: Select the Stack from Constraints

Protocol selection should start with the system behavior, not a favorite protocol name.

A practitioner asks what the device must send, how often, how far, under what power budget, through which gateway or service, and with what failure behavior.
Assuming a dashboard click means the device changed state.

Choose each layer for a reason and record the handoff between layers.

Major section

Practitioner: Select the Stack from Constraints (continued)

Choosing a verbose web stack because it is familiar.

The result is a short stack record: application protocol, payload format, transport behavior, network or adaptation layer, link technology, security wrapper, gateway handoff, and the evidence that proves the choices fit.
Its diagram makes Application and resources, topics, commands explicit within choose each layer for a reason and record the handoff between layers.
Using a low-power telemetry link for traffic it cannot carry.

Major section

Under the Hood: Boundaries Create Failure Modes

The hard part of a protocol stack is often not the protocol syntax.

Under the hood, every layer adds context and cost.
Headers, acknowledgements, retransmissions, security wrappers, and gateway buffers are useful when they serve the requirement; they are waste when they hide responsibility or exceed the link budget.

Layer-aware review asks what each boundary adds, removes, preserves, or translates.

Major section

Under the Hood: Boundaries Create Failure Modes (continued)

That visual pairing grounds layer-aware review asks what each boundary adds, removes, preserves, or translates in named evidence.

Together those labels make layer-aware review asks what each boundary adds, removes, preserves, or translates testable.
The message looks delivered, but command meaning, duplicate handling, or freshness is unclear.
Reliability assumptions break when paths are lossy, sleepy, buffered, or translated.
Address mapping, compression, fragmentation, or retries hide where packets are actually dropped.

Major section

Under the Hood: Boundaries Create Failure Modes (continued)

Address plan, adaptation context, frame fit, link acknowledgement, retry count, and channel evidence.

Translation changes identity, time, quality, credentials, or failure visibility.
Common pitfall: A protocol family name is not a deployed contract.
Protocol Stack Review Checklist Begin with the physical event, payload, receiver, and action the stack supports.

Major section

Worked End-to-End Stack Trace: Connected Tilt Maze

It decapsulates the Internet message all the way to its control application, validates freshness and limits, then creates a new local-link message for the Arduino.

A fast command round trip does not prove low video latency, and smooth video does not prove that a stale motor command will be rejected.
If a packet arrives 300 ms late after a radio retry, the correct action may be to discard it rather than move the maze toward an obsolete orientation.
Layering makes delivery possible; application semantics decide whether delivered data is still safe to use.

Major section

IoT Reference Models

A layer picture helps only when each hand-off has an owner and evidence.

OSI means Open Systems Interconnection, a model that separates network communication jobs.
A protocol is a shared set of rules for exchanging data.
TCP means a connected byte stream that tracks order and loss.
Telemetry means measurements and status sent from remote devices for review.

The ITU view keeps the model compact: devices generate or act on physical-world data, networks carry it, service support prepares it, and applications use it. Management and security cut across the stack.

Major section

IoT Reference Models (continued)

An IoT reference model is not a poster to memorize.

Break a hand-off, delay it, repeat it, restart one part, and keep the local safe response available.
This runway does not choose products or prove the full system.
That sequence turns a flexible deployment—where one gateway may implement several roles—into explicit contracts.

Major section

IoT Reference Models (continued)

The deeper sections compare network models with IoT responsibility models and show how device, service, security, management, and human action fit together.

Each layer should explain a responsibility, an owner, and the evidence needed to know the system is still doing its job.
The ordered map connects technology selection to the deployment decision the message supports and exposes which failure boundaries still lack proof.
An IoT reference model is not a product stack.

Major section

Summary · Key Takeaway

IoT communication is a stack of agreements, not one protocol name.

Application, transport, network/adaptation, link, and physical layers each carry a different responsibility.
Protocol selection should start from payload meaning, freshness, delivery behavior, range, power, gateway handoff, and operational ownership.
Header overhead, retransmissions, security wrappers, and fragmentation are design costs that should be visible in the decision record.

Deck summary

Key takeaways

Saying that the device is connected hides which rule or hand-off failed.

Protocol selection should start with the system behavior, not a favorite protocol name.
Choosing a verbose web stack because it is familiar.
The hard part of a protocol stack is often not the protocol syntax.
That visual pairing grounds layer-aware review asks what each boundary adds, removes, preserves, or translates in named evidence.

Retrieval practice

Recall check 1 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q1A team says, "We chose MQTT, so the network architecture is solved." What is the best response?

AMQTT replaces the need to choose transport, addressing, link behavior, gateways, or operations.

BMQTT helps app messaging; transport, addressing, link, security, gateways, and operations still need evidence.

CAll IoT systems should use the same protocol stack after a broker is available.

DLayering matters only in textbook diagrams, not deployed IoT systems with gateways.

Show answer

Answer: B A stack choice is credible when the team names application meaning, transport behavior, addressing, link limits, security, gateway handoff, and layer evidence.

Retrieval practice

Recall check 2 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q2A battery sensor sends a small reading only occasionally through a local gateway. Which protocol-selection habit is strongest?

AChoose the protocol with the most familiar web developer tooling and then adjust the device later.

BIgnore gateway behavior because translation does not affect data meaning.

CStart with constraints and gateway handoff evidence.

DSelect the highest-bandwidth stack even when the payload is small and infrequent.

Show answer

Answer: C Constrained IoT stack selection should be driven by evidence about payload, freshness, link behavior, gateway handoff, and operations.

Retrieval practice

Recall check 3 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q3A gateway receives constrained-device messages on one side and publishes them to a cloud broker on the other. Which review record is most important?

AOnly the cloud broker URL, because the gateway is transparent after messages arrive.

BOnly the radio data sheet, because link coverage proves cloud application correctness.

COnly a dashboard screenshot, because visible data proves the gateway is trustworthy.

DA boundary record for identity, time, payload, buffering, stale data, credentials, and monitoring.

Show answer

Answer: D Protocol-stack correctness depends on evidence at the boundaries where layers or gateways add, remove, or translate context.

Retrieval practice

Recall check 4 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q4Why do IoT teams use IoT reference models in addition to OSI or TCP/IP?

ABecause IoT reference models replace packet, port, address, and routing analysis in architecture reviews.

BBecause they add a deployment-responsibility map around networking mechanics.

CBecause they provide a common firmware module layout for device implementations.

DBecause dashboards are the only architecture layer needing ownership, security, and evidence.

Show answer

Answer: B OSI and TCP/IP are still useful, but IoT reference models add the functional responsibilities that sit around the communication path.

Retrieval practice

Recall check 5 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q5A building gateway receives meter readings, rejects malformed payloads, summarizes normal readings locally, and sends alarms immediately to an operations service. What is the most useful reference-model review action?

AMap the gateway across connectivity, edge processing, data services, and operations evidence

BPlace the gateway only in the physical device layer because it sits near sensors.

CSkip the edge-processing review because summaries are smaller than raw readings.

DTreat the application dashboard as proof that all lower layers are correct.

Show answer

Answer: A A single product can span several model areas.

Retrieval practice

Recall check 6 of 6

Packet Pete says: answer from memory, then check your reasoning.

Q6A review document labels an IoT service-support layer as equivalent to the OSI session layer because both use the word service. What is the best correction?

ADo not equate model names directly

BAssume every IoT reference-model layer has a one-to-one OSI layer with the same function.

CRemove OSI and TCP/IP from the design review because IoT models are more modern.

DMove all service-support behavior into the application dashboard so the lower layers stay simple.

Show answer

Answer: A Similar words across models can hide different meanings.

Print reference

Answers 1 of 2

Answer key.

B · A stack choice is credible when the team names application meaning, transport behavior, addressing, link limits, security, gateway handoff, and layer evidence.
C · Constrained IoT stack selection should be driven by evidence about payload, freshness, link behavior, gateway handoff, and operations.
D · Protocol-stack correctness depends on evidence at the boundaries where layers or gateways add, remove, or translate context.
B · OSI and TCP/IP are still useful, but IoT reference models add the functional responsibilities that sit around the communication path.

Print reference

Answers 2 of 2

Answer key.

A · A single product can span several model areas.
A · Similar words across models can hide different meanings.