14 Zigbee Routing
Zigbee routing evidence, Zigbee AODV review, Zigbee route repair, Zigbee self-healing review, Zigbee path evidence
14.1 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.2 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.3 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.4 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.5 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.6 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.
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.7 Knowledge Check: AODV Path Cost
14.8 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.9 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.10 Knowledge Check: Route Repair Evidence
14.11 Knowledge Check: Route Repair Claim
14.12 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.13 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.14 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.15 Knowledge Check: Tree Fallback
14.16 Routing Review Record
Use a routing record when accepting path behavior.
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.17 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.18 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.19 Matching Quiz: Routing Evidence Family
14.20 Ordering Quiz: Routing Review Sequence
14.21 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.22 Knowledge Check: Routing Readiness
14.23 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.
14.24 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.25 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.26 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.27 What’s Next
Next, continue with Zigbee Application Profile Evidence Review, where routing evidence connects to endpoint, cluster, and interoperability behavior.