Control, Gateways & Networked Systems · Study deck

How Multi-Hop Networks Work

Picture a farm sensor that reaches the control room only while a battery relay remains awake.

Gateway Gus is your guide for this deck.

multi

After studying this chapter

Learning objectives

You will be able to:

Explain: A relay path adds forwarding segments and a device that owns that work; its proof needs segment observations, recovery behavior, and a gateway intake record.
Explain: A marked packet trace can show each send and forward, while gateway intake and the receiving time show whether the irrigation decision receives usable data.
Explain: A direct path has one drawn hop to the gateway, so its key evidence is stable reachability and acceptable freshness at the receiver.
Explain: The soil-moisture sensor cannot reach the gateway directly, so the proposed path uses a relay and two drawn hops.

Proof workflow from application outcome to topology sketch, role map, route observation, gateway proof, and recheck trigger.

Major section

Start With the Neighbor That Can Hear

The direct radio link and the relayed path are different promises.

A gateway means the boundary system that joins local devices to another network or service.
A multi-hop network begins when the destination is not directly reachable.
For IoT deployments in farms, buildings, mines, and campuses, this chain is both opportunity and risk.

Fundamentals decision record linking purpose, topology, relay role, route proof, gateway proof, owner, and recheck trigger.

Major section

Topology Choice Is a Boundary Decision

Direct gateway paths and relay paths are both valid when their proof matches the application.

Figure: Topology choice map comparing direct path compares direct and relay paths by the proof each route needs.
A direct path has one drawn hop to the gateway, so its key evidence is stable reachability and acceptable freshness at the receiver.
The hop counts are drawn-link counts, not measured range or reliability.

Topology choice map comparing direct path, relay path, and mixed design through proof, weakness, and ownership.

Major section

Topology Choice Is a Boundary Decision (continued)

Useful when some nodes report directly while others need relay help; the review must prevent hidden unfairness.

A relay path adds forwarding segments and a device that owns that work; its proof needs segment observations, recovery behavior, and a gateway intake record.
Useful when nodes can reach the gateway boundary with simple ownership and acceptable application freshness.
Useful when nearby forwarding creates a better path, but only when relay burden and route recovery are owned.

Major section

Proof Workflow

The decision flow should move from purpose to proof.

That order keeps the chapter from drifting into protocol trivia before the design problem is clear.
The worked application expires a payload after 30 seconds, so delivery alone is not enough.
A topology sketch tells reviewers what to test; it does not prove the route remains current at the site.

Major section

Fundamentals Decision Record

A concise record makes later routing and application chapters easier to use.

It also gives reviewers a way to reject a design without arguing about style.
The soil-moisture sensor cannot reach the gateway directly, so the proposed path uses a relay and two drawn hops.
The record must also name relay burden, route recovery, and a recheck trigger.

Major section

Fundamentals Decision Record (continued)

The end node owns the reading, the relay forwards it, and the gateway is the application boundary.

A marked packet trace can show each send and forward, while gateway intake and the receiving time show whether the irrigation decision receives usable data.
Relay role: Which nodes forward for others and what burden they accept.
Route proof: What route behavior was observed, not only drawn.
Gateway proof: What shows the message became accepted application data.

Foundation model showing application purpose, node roles, link observations, relay responsibility, gateway intake, and decision result.

Deck summary

Key takeaways

The direct radio link and the relayed path are different promises.

Direct gateway paths and relay paths are both valid when their proof matches the application.
Useful when some nodes report directly while others need relay help; the review must prevent hidden unfairness.
The decision flow should move from purpose to proof.
A concise record makes later routing and application chapters easier to use.

Retrieval practice

Recall check 1 of 3

Gateway Gus says: answer from memory, then check your reasoning.

Q1A greenhouse sensor node cannot reach the gateway directly, so the team wants a nearby node to relay soil-moisture readings for irrigation decisions. Which first check keeps the multi-hop choice inspectable?

AApprove the relay after one wet-day packet reaches the gateway, then watch battery and queue logs during normal operation.

BUse the relay if RSSI improves on both short hops, but postpone gateway-validation checks until the first irrigation cycle.

CRecord accepted payload, freshness limit, relay role, queue budget, route trace, gateway validation, owner, and recheck trigger before rollout.

DLet the routing protocol handle failed hops, and assign an owner only if stale readings appear during operation.

Show answer

Answer: C A traceable multi-hop fundamentals decision proves that the relay topology keeps messages fresh enough for the application, assigns relay responsibility, observes route behavior, and checks gateway acceptance.

Retrieval practice

Recall check 2 of 3

Gateway Gus says: answer from memory, then check your reasoning.

Q2A team proposes multi-hop because it sounds more resilient than a direct gateway path. What is the best fundamentals response?

AChoose relays from two neighbours alone and defer ownership until alarms rise.

BAsk for application outcome, topology, relay owner and gateway acceptance.

CChoose direct links because shorter paths improve reliability for far nodes on rain days.

DPick routing algorithm first and ask whether late data matters afterward.

Show answer

Answer: B Multi-hop fundamentals start with application proof, then decide topology fit, relay ownership, route behavior, and gateway proof.

Retrieval practice

Recall check 3 of 3

Gateway Gus says: answer from memory, then check your reasoning.

Q3A soil-moisture network adds a relay so distant nodes can reach the gateway, but messages sometimes arrive after the irrigation controller has already made its decision. What should the multi-hop fundamentals record check first?

AKeep the relay if it improves RSSI at each hop, and treat late arrivals as a dashboard filtering problem.

BMove the freshness decision to the routing layer and leave irrigation timing out of the route record.

CRaise the gateway timeout so late packets are accepted, then review duplicates only if alarms disagree.

DCheck payload age, relay queue time, retry budget, route repair, gateway acceptance, and whether the data is still useful.

Show answer

Answer: D A multi-hop route is acceptable only when the forwarded message remains fresh and accepted at the application boundary, with relay burden, route repair, and gateway behavior proven.

Print reference

Answers

Answer key.

C · A traceable multi-hop fundamentals decision proves that the relay topology keeps messages fresh enough for the application, assigns relay responsibility, observes route behavior, and checks gateway acceptance.
B · Multi-hop fundamentals start with application proof, then decide topology fit, relay ownership, route behavior, and gateway proof.
D · A multi-hop route is acceptable only when the forwarded message remains fresh and accepted at the application boundary, with relay burden, route repair, and gateway behavior proven.