10 How Multi-Hop Networks Work
More
Depth: Practitioner
Progress saves as you read. Mark sections complete as you go; your progress appears in the sidebar.
10.1 Start With the Neighbor That Can Hear
This section: Start With the Neighbor That Can Hear — Picture a farm sensor that reaches the control room only while a battery relay remains awake.
Prove One Relay Path Before Calling It a Mesh
Picture a farm sensor that reaches the control room only while a battery relay remains awake. 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.
Send marked packets over one hop and several hops, then remove one relay and restart the gateway. Keep node identities, route version, each next hop, time, retries, delivery, energy state, loss, and recovery result.
This test covers selected paths and faults, not the whole estate. The deeper sections compare forwarding, route repair, reliability, energy cost, gateway intake, and operating ownership.
A multi-hop network begins when the destination is not directly reachable. One node can hear a neighbor, that neighbor can hear another, and the path becomes a chain of forwarding promises.
For IoT deployments in farms, buildings, mines, and campuses, this chain is both opportunity and risk. Start with two neighbors and one packet that must move farther than one radio hop; routing, reliability, and battery cost all follow from that first relay.
10.2 Learning Objectives
This section: Learning Objectives — The overview depth layer below carries the route map that connects purpose, topology, relay roles, gateway proof, and the decision record.
By the end of this chapter, you should be able to:
- Explain what makes a network ad hoc and what makes a path multi-hop.
- Decide when a direct gateway path, relay path, or mixed design deserves a closer decision.
- Identify relay responsibilities and gateway-boundary proof.
- Separate topology diagrams from observed route behavior.
- Build a short fundamentals decision record before moving into detailed routing or application design.
The overview depth layer below carries the route map that connects purpose, topology, relay roles, gateway proof, and the decision record.
10.3 Where This Chapter Fits
This section: Where This Chapter Fits — This chapter is the foundation for the multi-hop sequence.
This chapter is the foundation for the multi-hop sequence. It prepares the vocabulary and decision habits used by the concepts, applications, and assessment chapters.
Inputs
Application outcome, deployment shape, gateway boundary, node roles, operating constraints, and proof expectations.Outputs
Topology choice, relay-role expectations, gateway proof needs, route decision questions, and a short proof record.Boundary Habit
Ask, "What must be true at the application boundary before this path counts as working?"10.4 Foundation Model
This section: Foundation Model — Multi-hop fundamentals are easier to review when the path is described in responsibilities instead of slogans.
Multi-hop fundamentals are easier to review when the path is described in responsibilities instead of slogans.
The surrounding prose sets a requirement; Figure 10.1 shows its working parts. Study it to determine whether foundation model showing application purpose, node roles, link observations, relay responsibility, gateway intake, and decision result.
Begin the technical reading of Figure 10.1 with End. Next determine how Observed route alters the case, then verify the end condition at valid and fresh. This is the visible basis for foundation model showing application purpose, node roles, link observations, relay responsibility, gateway intake, and decision result, and it carries Foundation Model into the chapter’s evidence trail.
| Foundation Question | What It Protects | Proof to Look For |
|---|---|---|
| What result does the application need? | Prevents routing work from being judged without a business or safety outcome. | Accepted payload, freshness rule, failure handling, and owner response. |
| Which nodes only originate messages? | Prevents hidden relay work from being placed on nodes that were not planned for it. | Role map, forwarding expectation, health signal, and maintenance access. |
| Which paths are observed? | Prevents a diagram from being mistaken for route behavior. | Route trace, retry pattern, queue behavior, and recheck trigger. |
| Where does the gateway accept the message? | Prevents network delivery from being confused with application delivery. | Gateway intake, validation result, duplicate handling, and application acknowledgement. |
10.5 Core Vocabulary and Route-State Addendum
This section: Core Vocabulary and Route-State Addendum — Use narrow terms when reviewing a multi-hop design.
Use narrow terms when reviewing a multi-hop design. A route is operational state, not permanent wiring, and a relay is an owned responsibility, not just a dot in the diagram.
| Concept | Boundary question |
|---|---|
| End node | Does the node only send its own messages, or is it also expected to relay for others? |
| Relay node | Who owns its load, health signal, placement, queue behavior, and maintenance proof? |
| Hop | What happens when this forwarding step is delayed, retried, or replaced by another path? |
| Route | Is the active path observed, assumed, preferred, or only drawn? |
| Gateway | Does the gateway validate, buffer, de-duplicate, and report failures before exposing data to the application? |
| Route state | Which candidate neighbor, selected route, recovery behavior, and recheck trigger make the route proof current? |
| Link and relay proof | Is the neighbor link stable enough, is the relay burden acceptable, and is the application result still fresh when it arrives? |
This vocabulary supports the topology decision. Direct paths need stable gateway reachability; relay paths need route-segment proof, relay ownership, recovery behavior, and gateway-intake proof.
10.6 Topology Choice Is a Boundary Decision
This section: Topology Choice Is a Boundary Decision — Direct gateway paths and relay paths are both valid when their proof matches the application.
Direct gateway paths and relay paths are both valid when their proof matches the application. The weak design is the one that picks a topology before naming the proof needed to trust it.
Figure 10.2 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. 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. A mixed design combines those duties for different nodes. The hop counts are drawn-link counts, not measured range or reliability. Choose the path that can meet the application outcome, then record who carries relay burden and what trace would show a route still works after a neighbor changes.
Direct Gateway Path
Useful when nodes can reach the gateway boundary with simple ownership and acceptable application freshness.Relay Path
Useful when nearby forwarding creates a better path, but only when relay burden and route recovery are owned.Mixed Design
Useful when some nodes report directly while others need relay help; the review must prevent hidden unfairness.10.7 Relay Responsibility
This section: Relay Responsibility — A relay is not just a convenient dot between two nodes.
A relay is not just a convenient dot between two nodes. It becomes part of the operating system for the network.
Relay Boundary Prompts
Log both the relay path and gateway result. A drawn route cannot prove the app worked.
10.8 Proof Workflow
This section: Proof Workflow — The decision flow should move from purpose to proof.
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.
Figure 10.3 follows a route claim from application freshness to observed relay behavior.
The worked application expires a payload after 30 seconds, so delivery alone is not enough. Sketch the end node, each relay, and the gateway, then record the role of every hop. A route observation should show which neighbor forwarded the marked packet and whether gateway intake accepted it. Test a lost neighbor or delayed relay to see when the application receives stale data or no data. Keep the route trace, gateway record, and recheck trigger together. A topology sketch tells reviewers what to test; it does not prove the route remains current at the site.
| Decision Step | Question | Completion Signal |
|---|---|---|
| Purpose | What does the application need from this message? | Freshness, acceptance, and failure response are named. |
| Topology | Which nodes report directly, relay, or do both? | Node roles and gateway boundary are mapped. |
| Behavior | What route behavior was observed under normal and changed conditions? | Route trace, retry behavior, and queue proof are recorded. |
| Boundary | Did the gateway produce usable application data? | Intake, validation, duplicate handling, and application acknowledgement are checked. |
10.9 Fundamentals Decision Record
This section: Fundamentals Decision Record — A concise record makes later routing and application chapters easier to use.
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.
Figure 10.4 ties the greenhouse relay choice to packet and freshness evidence.
The soil-moisture sensor cannot reach the gateway directly, so the proposed path uses a relay and two drawn hops. 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. The record must also name relay burden, route recovery, and a recheck trigger. The drawn path is a candidate; the site trace and receiver result are the proof needed before accepting it.
Record Template
- Purpose: What application outcome is this path supporting?
- Topology choice: Direct, relay, or mixed path, with the reason for choosing it.
- 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.
- Owner and trigger: Who maintains the proof, and what change reopens the decision?
10.10 Chapter Route
This section: Chapter Route — Use this sequence when moving through the multi-hop set.
Use this sequence when moving through the multi-hop set.
Concepts
Multi-Hop Core Concepts defines hops, relays, route state, gateway boundaries, and decision vocabulary.Applications
Multi-Hop Applications applies the foundation to application fit, role ownership, path proof, and gateway contracts.Assessment
Multi-Hop Assessment turns the foundation into proof-based design decisions and weak-design diagnosis.10.11 Knowledge Check
This section: Knowledge Check
10.12 Match Foundations to Proof
This section: Match Foundations to Proof
10.13 Order a Fundamentals Decision
This section: Order a Fundamentals Decision
10.14 Common Pitfalls
This section: Common Pitfalls — Look at the two paths.
Look at the two paths. Why does the red cross reject the upper path as proof of application delivery?
-
Wrong: Reaching the last relay proves delivery. Check that the application accepted fresh, valid data.
The upper path reaches the gateway, but the red cross rejects that as proof that the application accepted the reading. The lower path continues to application storage. Check for a fresh, valid result there, not just a final relay or gateway arrival. That is the gateway-boundary pitfall below.
Mesh as Default
Treating a relay topology as a default upgrade without checking whether the application actually needs it.Diagram as Proof
Approving a path drawing without observed route behavior, relay burden, queue behavior, and gateway intake.Hidden Relay Ownership
Letting nodes forward for others without health proof, maintenance responsibility, or escalation rules.Gateway Boundary Gap
Stopping the decision when a message reaches a final relay instead of checking application-side acceptance.10.15 Overview: A Route Is A Current Claim
This section: Overview: A Route Is A Current Claim — A multi-hop route is not permanent wiring.
A multi-hop route is not permanent wiring. It is a current claim that this message can move through these neighbors, arrive fresh enough, and become accepted application data at the gateway boundary. Inspect Figure 10.5 because that claim can expire when links fade, relays move, queues fill, batteries fall, or gateway intake rules change.
Read Figure 10.5 from application purpose through topology fit and relay roles to gateway proof and the review trigger. 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?"
Mobile summary: Figure 10.5 treats every multi-hop route as a current claim: the topology, relay burden, gateway proof, and review trigger must all support the application purpose.
10.16 Route Freshness Record
This section: Route Freshness Record — Before approving a relay path, write a short route freshness record.
Before approving a relay path, write a short route freshness record. It keeps the review anchored to message usefulness instead of hop count alone.
Message Boundary
Name the payload, freshness limit, duplicate rule, missing-data behavior, and application acknowledgement that makes delivery count.
Relay Burden
Name each relay role, queue limit, power impact, retry budget, health signal, and owner who responds when forwarding is no longer healthy.
Route Recheck
Name the link, queue, battery, mobility, gateway, or policy change that invalidates the current route proof and forces retest.
A good record can reject a tempting mesh design. If the payload expires after 30 seconds and the second relay often buffers for two minutes during gateway loss, more hops did not improve the application outcome.
10.17 Under the Hood: Forwarding Moves Failure
This section: Under the Hood: Forwarding Moves Failure — Multi-hop forwarding does not remove failure; it moves and redistributes it.
Multi-hop forwarding does not remove failure; it moves and redistributes it. A direct weak link may become three shorter links, but the design now has relay queues, duplicate suppression, route repair, hidden power drain, and gateway de-duplication to prove.
This is why route behavior should be observed under change, not only drawn under normal conditions. The under-the-hood proof is a trace: selected neighbor, retry count, queue age, relay health, gateway acceptance, and whether route repair kept the application data fresh enough.
10.18 Summary
This section: Summary — Multi-hop ad hoc fundamentals are a way to decide whether relay networking is justified and reviewable.
Multi-hop ad hoc fundamentals are a way to decide whether relay networking is justified and reviewable.
Use the route trace and gateway record to distinguish a working application path from a topology sketch.
10.19 Key Takeaway
This section: Key Takeaway — Multi-hop fundamentals are about tradeoffs: extra reach and resilience come with routing overhead, latency, maintenance, and diagnostics costs.
Multi-hop fundamentals are about tradeoffs: extra reach and resilience come with routing overhead, latency, maintenance, and diagnostics costs.
10.20 See Also
This section: See Also
10.21 What’s Next
This section: What’s Next
Continue with Where Multi-Hop Networks Fit to apply multi-hop ad hoc networks where infrastructure is limited, using application-fit checks, relay roles, path health, and gateway boundaries.
Find help
3 reviewed answers.
Where should I start in a module?
Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.
Modules and pathsReviewed
What can I try when a project does not work?
Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.
When you are stuckReviewed
How do interactive examples work?
Use the interactive guide to check how examples and simulations work before changing your project.
Interactive examples guideReviewed