10 How Multi-Hop Networks Work
10.1 Start With the Neighbor That Can Hear
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
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 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
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
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
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.
Before accepting Direct path as the starting point for topology choice is a boundary decision, inspect Figure 10.2 against evidence. 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.
In Figure 10.2, compare Direct path with evidence; their contrast makes topology choice map comparing direct path, relay path, and mixed design through proof, weakness, and ownership explicit. 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. At Figure 10.2, record Direct path beside evidence; without Direct path, topology choice is a boundary decision loses the checkpoint paired with evidence.
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
A relay is not just a convenient dot between two nodes. It becomes part of the operating system for the network.
Relay Boundary Prompts
Taken together, these checks make the section reviewable. That order prevents radio delivery or a drawn route from being mistaken for an accepted application result, preserving the chapter’s path-to-proof narrative.
10.8 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.
Before accepting Recheck as the starting point for proof workflow, inspect Figure 10.3 against Role Map. Together, Recheck and Role Map frame the proof workflow claim: proof workflow from application outcome to topology sketch, role map, route observation, gateway proof, and recheck trigger.
Trace Figure 10.3 from Recheck toward Role Map; that hand-off expresses proof workflow from application outcome to topology sketch, role map, route observation, gateway proof, and recheck trigger. Those labels connect the application outcome in proof workflow to relay custody at Recheck, gateway acceptance, and operational proof at Role Map. At Figure 10.3, record Recheck beside Role Map; without Recheck, proof workflow loses the checkpoint paired with Role Map.
| 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
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.
Before accepting Site as the starting point for fundamentals decision record, inspect Figure 10.4 against role. Together, Site and role frame the fundamentals decision record claim: fundamentals decision record linking purpose, topology, relay role, route proof, gateway proof, owner, and recheck trigger.
Trace Figure 10.4 from Site toward role; that hand-off expresses fundamentals decision record linking purpose, topology, relay role, route proof, gateway proof, owner, and recheck trigger. Those labels connect the application outcome in fundamentals decision record to relay custody at Site, gateway acceptance, and operational proof at role. At Figure 10.4, record Site beside role; without Site, fundamentals decision record loses the checkpoint paired with role.
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
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
10.12 Match Foundations to Proof
10.13 Order a Fundamentals Decision
10.14 Common Pitfalls
-
Wrong: Reaching the last relay proves delivery. Check that the application accepted fresh, valid data.
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
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
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
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
Multi-hop ad hoc fundamentals are a way to decide whether relay networking is justified and reviewable.
Taken together, these checks make the section reviewable. That order prevents radio delivery or a drawn route from being mistaken for an accepted application result, preserving the chapter’s path-to-proof narrative.
10.19 Key Takeaway
Multi-hop fundamentals are about tradeoffs: extra reach and resilience come with routing overhead, latency, maintenance, and diagnostics costs.
10.20 See Also
10.21 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.