14 Zigbee Routing
14.1 A Clear First Route
Imagine a lamp command must cross several small routers after one path has failed. The team must decide whether the mesh can find, use, and repair a path in time. Zigbee is a low-power wireless system for nearby devices. A gateway is a device or service that links one network or system to another. Latency means the wait from an event to a useful result.
This page starts with one job. Name the sender, receiver, and message that matter. Then note path search, next hops, link loss, repair, and route records. Look for send and receive times, path state, repair logs, failed cases, and owner notes. Last, choose approve the bounded path claim, improve the mesh, or retest the site. Keep the limit in view. A line on a map is not proof of delivery. One good delivery is not proof of repair.
14.1.1 Follow One Decision
- What real event starts the case?
- Who needs the result?
- What action may follow?
- Which sign comes from the device?
- How old can that sign be?
- What can make it wrong?
- What must still work after a fault?
- Who owns the next check?
- What change will force a new test?
- What proof should the team keep?
A good record answers each point in plain words. It names the site and the people. It names the device and its state. It says when the event took place. It says when the result arrived. It marks doubt instead of hiding it. It also names the safe fallback. That makes the result useful without making it sound more sure than it is.
14.1.2 Know What This Route Leaves Out
This first route is a guide to the main choice. It does not model every field effect or rare fault. The Practitioner sections add path search, repair, route tables, source routes, and field review records. Under the Hood adds path cost, fallback rules, table limits, packet flow, and hard timing bounds. Those deeper parts add detail to this route. They do not reverse its main claim.
14.1.3 Read the Result Before You Act
Start with the source, not the final label. Check that the source belongs to this case. Check its time and state. Ask if a second source agrees. If two sources differ, keep that fact in the record. Do not force a clean answer just to fill a screen. A late result may be true about the past and still be unsafe now. A missing result is also useful news when the system shows it at once.
Next, link the result to one owned step. A person may inspect the site. A local rule may hold a safe state. A remote team may ask for more proof. The right step depends on the claim that was tested. It must not depend on a broad product label. Write down the reason for the step. Write down the time. Write down who may close the case.
14.2 In 60 Seconds
Zigbee routing review asks whether messages have owned, observable, and recoverable paths through the mesh. A route is not approved because a diagram shows connected routers. It is approved when route discovery, forwarding behavior, failure response, route-record visibility, gateway reporting, and operations ownership support the claim.
This chapter reviews AODV-style route discovery, route repair, many-to-one traffic, source-route use, path stability, and retest triggers without turning routing into a fixed-latency promise or a packet-field tutorial.
14.3 Learning Objectives
By the end of this chapter, you will be able to:
- state a reviewable Zigbee routing claim,
- identify the evidence needed for route discovery and repair,
- separate route-table presence from proven application behavior,
- review many-to-one and source-route boundaries,
- recognize routing drift in deployment records, and
- record decisions, owners, exclusions, and retest triggers.
14.4 Start With a Routing Claim
Begin with the behavior the system needs.
Weak claim: the Zigbee mesh can self-heal.
Stronger claim: within this deployment boundary, representative endpoints can discover or reuse a working path, route loss is visible enough for operations to respond, affected behavior recovers within the approved service expectation, gateway records show the interruption, and retest triggers are defined.
The stronger claim avoids promising universal self-healing. It names the boundary, observed behavior, gateway visibility, owner, and conditions that reopen the review.
14.5 Routing Evidence Families
Use these evidence families before accepting a routing claim.
Route discovery evidence records whether a source can find a path when no suitable path is available.
Forwarding evidence records which routers carry representative traffic and whether the observed path matches the approved topology claim.
Route table evidence records whether routing entries support the intended destination, next hop, route state, and owner of stale entries.
Repair evidence records what happens when a router, parent, or link assumption changes.
Gateway evidence records whether the gateway exposes route interruption, retry, or application-level failure clearly enough for support.
Operations evidence records who monitors routing symptoms, approves placement changes, replaces routers, and retests paths.
14.6 AODV Review Without Packet Drift
Zigbee routing commonly uses reactive route discovery. The important review question is not whether learners can memorize packet fields. The important question is whether route discovery behavior is observable and appropriate for the service claim.
Review:
- what source needs a route,
- what destination or concentrator is being reached,
- whether a route request reaches enough of the mesh,
- whether a reply returns through an owned path,
- whether intermediate routers have plausible forwarding roles,
- whether repeated discoveries point to an unstable path, and
- whether the application can tolerate discovery before normal traffic resumes.
Avoid approving a design from protocol names alone. AODV behavior still needs evidence from the deployment boundary.
14.7 AODV Path Cost Evidence
Zigbee PRO mesh routing is commonly described as AODV-style discovery. When a router needs a path it does not already have, it broadcasts a route request. Routers that hear it can rebroadcast it while adding link-cost information. The destination, or a router with a usable route, sends a route reply back along the selected path. Routers on that path install route-table state so later frames can reuse the route.
Two review facts matter more than packet-field memorization. First, the route is discovered and then reused; it is not rediscovered for every application frame. Second, the selected route is based on accumulated path cost, not simply the fewest hops. A longer chain of reliable links can be a better route than a shorter chain with weak links.
Route discovery is useful only when its result remains observable after the reply. Figure 14.1 connects the AODV-style exchange to the route record and service evidence needed for approval.
Figure 14.1 begins with the Source endpoint that needs a path. Discovery sends a request into the mesh, Forwarding lets routers accumulate and carry the evidence, and Reply returns the selected path to the source. The next box, Route Record, is where state and custody survive beyond the exchange; without it, later traffic and diagnosis cannot be tied to the discovery. Gateway View then asks whether support can see failures before the Routing Decision accepts only the observed path behaviour. This sequence turns the accumulated-cost explanation above into an operations claim rather than a one-off packet trace.
Use the path-cost story as evidence only when the route claim connects discovery, forwarding, route reply, route-table or route-record state, gateway visibility, decision, owner, and retest trigger.
14.8 Knowledge Check: AODV Path Cost
14.9 Route Repair and Self-Healing Evidence
Self-healing should be reviewed as evidence, not as a slogan.
When a path fails, review:
- which endpoints were affected,
- which router or path assumption changed,
- whether the affected endpoints found another usable path,
- whether the application behavior recovered or stayed degraded,
- whether the gateway reported the interruption clearly,
- whether a hidden single dependency remains, and
- who owns the repair and retest.
If some endpoints recover and others do not, the evidence supports a narrowed decision. Do not approve the whole mesh from partial recovery.
14.10 Route Repair and Concentrator Evidence
Route repair is the self-healing behavior a reviewer can actually observe. When a link on an established route fails, an upstream router can initiate a fresh discovery for that destination. A healthy repair usually appears as a short burst of route requests followed by traffic resuming on a new path. Continuous discovery that never settles is different evidence: it points to route churn, too few routers, a flapping link, or missing ownership.
For gateway-bound collection, many-to-one routing changes the evidence pattern. A concentrator such as the coordinator or gateway can issue a many-to-one request so routers learn a next hop toward the sink. Devices can then send route records that let the concentrator build reverse source routes for replies. This is useful evidence for collection-heavy systems, but it still must be retested after gateway replacement or topology changes.
| Mechanism | When used | Healthy evidence |
|---|---|---|
| Route repair | An in-use link fails. | One bounded discovery burst, then traffic resumes on an alternate path. |
| Many-to-one request | Many devices send toward one sink. | Sink-initiated discovery gives routers a next hop toward the concentrator. |
| Route record | The sink needs a reverse path. | Devices report route state that the concentrator can use for downstream replies. |
14.11 Knowledge Check: Route Repair Evidence
14.12 Knowledge Check: Route Repair Claim
14.13 Many-to-One and Source-Route Boundaries
Some Zigbee networks concentrate traffic toward a coordinator or gateway. Many-to-one routing and source-route behavior can reduce repeated discovery for that pattern, but they do not prove every traffic direction.
Review:
- whether most traffic actually flows toward the concentrator,
- whether route records are captured and usable,
- whether downlink commands depend on source-route state,
- whether route records are refreshed after topology changes,
- whether gateway replacement changes route-record custody, and
- whether non-concentrator traffic still has a tested path.
Many-to-one routing can be a strong fit for collection-heavy systems. It is weak evidence for peer-to-peer or direct-control claims unless those paths are separately tested.
14.14 Tree Routing and Fallback Claims
Tree-based forwarding and hierarchical assumptions may appear in routing explanations, but they need careful review. A tree path can be simple to reason about, yet it may hide weak alternate-path evidence.
Use tree-related claims only when the review record states:
- what hierarchy is being used,
- which devices depend on that hierarchy,
- whether alternate mesh forwarding is available,
- how path changes are observed,
- what gateway or coordinator behavior depends on the hierarchy, and
- when a topology change requires retest.
Do not treat a clean hierarchy diagram as proof of resilient routing.
14.15 Routing Tables, Source Routes, and Tree Fallback
A routing review should name which mechanism is carrying the flow. A router can use an AODV-discovered route-table entry that maps a destination to a next hop. A concentrator can use source-route state learned from route records to send downstream frames. If a route is unknown, cannot be discovered, or routing state is constrained, tree routing can follow the parent-child address hierarchy as a fallback.
These mechanisms fail differently. A route-table entry can become stale. A concentrator source route can stop matching the topology after a gateway or router change. A tree fallback can keep traffic moving but take a long, non-optimal hierarchical path. The fix depends on which mechanism is actually visible in the evidence.
If throughput is acceptable but some paths have unexpectedly high latency, do not treat that as automatic approval. Check whether tree routing or stale source-route state is hiding a route-discovery problem, then assign an owner and retest after the topology or gateway state is refreshed.
14.16 Knowledge Check: Tree Fallback
14.17 Routing Review Record
Use a routing record when accepting path behavior.
A repair can restore traffic without proving why the route failed. Figure 14.2 provides the minimum record for carrying a routing incident into an owned decision.
The first row of Figure 14.2 binds the Event—router, parent, gateway, or topology change—to the Affected endpoints and functions in scope. Observed path records discovery, forwarding, and route state, while Failed assumption names a single dependency or stale state instead of hiding it behind “mesh instability.” Next, Gateway evidence distinguishes visible service impact from radio-only change. The record closes with Owner, a bounded Decision, and the Retest trigger for topology, gateway, or endpoint changes. Those fields structure the repair examples below and prevent recovery from being mistaken for permanent proof.
The record should include:
- Claim: route behavior being approved.
- Boundary: site, topology, gateway, and endpoint families covered.
- Observed path: route discovery, forwarding, or route-record evidence.
- Affected endpoints: devices or functions included in the review.
- Gateway evidence: what support or application systems can see.
- Failure event: router, parent, gateway, or topology change tested.
- Decision: accept, narrow, revise, reject, or retest.
- Owner: person or team responsible for repair and monitoring.
- Retest trigger: router movement, endpoint replacement, gateway change, firmware update, topology change, or repeated route discovery.
14.18 Worked Review: Repeated Route Discovery
Scenario: A group of endpoints is reachable, but support logs show repeated route discovery before normal reports.
Review path:
- Confirm the affected endpoints and the destination being reached.
- Compare observed paths across several representative reports.
- Check whether the repeated discovery follows one router, one area, or one endpoint family.
- Review gateway visibility and application symptoms.
- Decide whether to accept the behavior, revise placement, or retest after a route-stability fix.
Decision: Revise when repeated discovery points to a fragile path or missing owner. Accept only when the behavior remains inside the approved service expectation and the owner can monitor it.
14.19 Worked Review: Gateway Replacement
Scenario: A gateway replacement preserves device joins, but downlink commands to some endpoints become inconsistent.
Review path:
- Separate join evidence from routing evidence.
- Confirm route-record custody before and after the replacement.
- Test representative downlink and uplink behavior.
- Record which commands remain proven and which are exclusions.
- Assign ownership for route-record refresh, gateway configuration, and retest.
Decision: Approve only the paths that were retested after replacement. Joined devices alone do not prove preserved routing behavior.
14.20 Matching Quiz: Routing Evidence Family
14.21 Ordering Quiz: Routing Review Sequence
14.22 Common Routing Drift
Diagram drift: approving a mesh path because a diagram shows connected routers.
Partial-recovery drift: treating recovered endpoints as proof that every affected endpoint recovered.
Protocol-name drift: assuming AODV, many-to-one, or source routing proves service behavior.
Gateway drift: ignoring whether route failure is visible to the application or support system.
Route-table drift: treating a route-table entry as proof of successful application behavior.
Owner drift: testing repair once without naming who monitors future route symptoms.
Retest drift: moving routers or replacing a gateway without reopening the routing claim.
14.23 Knowledge Check: Routing Readiness
14.24 Routing Evidence Checklist
Before accepting a Zigbee routing claim, confirm that the record:
- states the route behavior and boundary being approved,
- identifies representative endpoints and destinations,
- separates discovery evidence from cached-path behavior,
- records forwarding or route-record evidence,
- tests at least one meaningful route-change condition,
- records affected endpoints and unresolved gaps,
- includes gateway and application-facing visibility when relevant,
- names the operations owner,
- avoids fixed timing or capacity promises not proven by this site, and
- defines retest triggers for topology, gateway, endpoint, firmware, or operations changes.
Follow ownership from the radio frame to the lighting service in Figure 14.3.
In Figure 14.3, NWK chooses the route while APS names the service; Security protects each hop through its own fields and counters. The Boundary rule prevents a valid FCS from being mistaken for proof of route intent or application authorization.
Compare the installed failure surfaces of two Zigbee layouts with the diagram Figure 14.4.
In the diagram Figure 14.4, the STAR card concentrates every path at One centre, whereas MESH spends Many routers to create alternatives. Application profiles remain a service-interoperability mechanism in both cases; they do not manufacture radio coverage.
Test the phrase self-healing against an observable route change in the diagram Figure 14.5.
In the diagram Figure 14.5, the broken A → B → C → D route is replaced by A → D → G as RREQ discovery and RREP selection complete. The final G ACK is the critical label: restored endpoint delivery, not a redrawn graph, closes the claim.
14.25 Summary
Zigbee routing evidence review is about observed path behavior, repair behavior, route-record custody, gateway visibility, and ownership. Route discovery, route repair, many-to-one routing, and source-route behavior are useful only when tied to the claim and deployment boundary being approved.
Do not approve routing from a diagram, protocol name, route-table entry, or partial recovery alone. Approve only the route behavior that was observed, bounded, owned, and tied to retest triggers.
14.26 Key Takeaway
Approve Zigbee routing only when observed discovery, repair, route-record or gateway visibility, owner, and retest evidence support the exact route behavior being released.
14.27 Concept Relationships
- Zigbee Network Formation Evidence Review provides the join and parent evidence that routing depends on.
- Zigbee Network Topologies Evidence Review explains the topology claims behind path diversity.
- Zigbee Protocol Stack Evidence Review separates network-layer routing from application behavior.
- Zigbee Deployment Readiness Evidence Review records site ownership and retest gates for routing changes.
- Zigbee Worked Example Evidence Review shows scenario records that include route repair and gateway replacement.
14.28 What’s Next
Next, continue with Zigbee Application Profile Evidence Review, where routing evidence connects to endpoint, cluster, and interoperability behavior.