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

Gateway Gus, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: The useful fundamentals question is not "is this a mesh?" It is "which active path is trusted right now, what burden does each relay accept, and what proof shows the application outcome still holds after forwarding?".
Explain: Together,: Direct path and evidence frame the topology choice is a boundary decision claim: topology choice map comparing direct path, relay path, and mixed design through proof, weakness, and ownership.
Explain: Useful when nearby forwarding creates a better path, but only when relay burden and route recovery are owned.
Identify relay responsibilities and gateway-boundary proof.

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.

Major section

Topology Choice Is a Boundary Decision

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

Together,: Direct path and evidence frame the topology choice is a boundary decision claim: topology choice map comparing direct path, relay path, and mixed design through proof, weakness, and ownership.

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)

Those labels connect the application outcome in topology choice is a boundary decision to relay custody at: Direct path, gateway acceptance, and operational proof at evidence.

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.
Useful when some nodes report directly while others need relay help; the review must prevent hidden unfairness.

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.

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

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.
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.

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

Major section

Common Pitfalls

Letting nodes forward for others without health proof, maintenance responsibility, or escalation rules.

Stopping the decision when a message reaches a final relay instead of checking application-side acceptance.

Major section

Overview: A Route Is A Current Claim

A multi-hop route is not permanent wiring.

The useful fundamentals question is not "is this a mesh?" It is "which active path is trusted right now, what burden does each relay accept, and what proof shows the application outcome still holds after forwarding?".

The fundamentals route starts with the application purpose, chooses topology by proof, assigns relay roles, checks gateway intake, and records the trigger for review.

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.
Those labels connect the application outcome in topology choice is a boundary decision to relay custody at: Direct path, gateway acceptance, and operational proof at evidence.
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?

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

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

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

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

Show answer

Answer: A 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 relay paths if the map shows two neighbors per node, then verify ownership only after field alarms rise.

BChoose direct gateway links if they avoid relay maintenance, even when far nodes lack rain-day link margin.

CAsk what application outcome must be proven, what topology evidence supports it, who owns relay load, and how gateway acceptance is checked.

DPick the routing algorithm first, then let the application team decide later whether late data matters.

Show answer

Answer: C 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?

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

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

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

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

Show answer

Answer: A 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.

A · 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.
C · Multi-hop fundamentals start with application proof, then decide topology fit, relay ownership, route behavior, and gateway proof.
A · 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.