Zigbee, Thread & Matter · Study deck
Zigbee Routing
Imagine a lamp command must cross several small routers after one path has failed.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
A routing claim needs observed discovery, forwarding, recovery, and service evidence.
- A joined endpoint does not prove its required traffic can arrive.The replacement gateway can preserve device joins while some downlink commands become inconsistent, so attachment leaves routing and application behaviour unproven.
- Route tables, source routes, and tree fallback are different forwarding mechanisms.A stale next-hop entry, an outdated gateway source route, and a long hierarchical fallback need different checks before a repair decision.
- A repaired path needs checks across affected endpoints and functions.Most endpoints can resume reports while one remains silent, making recovered traffic partial evidence rather than proof that every device recovered.
- Gateway visibility and ownership keep the route claim reviewable after change.The record needs interruption evidence, a repair owner, and retest triggers for router movement, gateway replacement, or other changes to the approved boundary.
Major section
A Clear First Route
A first routing test follows a real report from its endpoint to the destination.
- The evidence must identify the endpoint and function being served.The opening lamp command needs a named sender, receiver, and message before a line through several routers becomes a testable routing claim.
- Discovery records show how an unavailable path becomes usable.Requests, replies, and route state need observations from the deployment, because the application must tolerate discovery before its normal traffic can resume.
- Forwarding evidence connects stored route state with actual frames.A route-table entry needs representative traffic using its destination and next hop before the review can accept the path’s behaviour.
- The application result must establish service beyond network attachment.The lamp command still needs a useful result after delivery, with send and receive times and any failed cases kept in the record.
Major section
Endpoint gaps after a route or gateway change
A connected mesh drawing cannot establish how traffic behaves after a route change.
- A router or parent change can invalidate endpoint forwarding assumptions.The repair review needs the affected identities and observed paths after the change, rather than a clean mesh drawing that hides a silent endpoint.
- A gateway replacement can preserve joins while disrupting downlink commands.The chapter’s replacement case needs route-record custody checked before and after the change because continued attachment cannot establish preserved routing behaviour.
- The review must retain the identities of unresolved endpoints.A router-removal test can restore most reports while one endpoint stays silent, so approval must exclude that unresolved behaviour and record its owner.
- Uplink and downlink tests show which functions remain supported.Representative commands and reports need separate observations after replacement, keeping proven paths distinct from commands that still need repair and retesting.
Major section
The deployment boundary and repair owner
Routing ownership connects a successful bench test with later field operation.
- The approved claim must name its deployment boundary.The site, topology, gateway, and endpoint families define which routing behaviour has evidence, leaving other devices and arrangements outside that approval.
- Support systems need visible route symptoms and application impact.If one endpoint remains silent after router removal, missing gateway path evidence is a recorded gap rather than a reason to accept full recovery.
- The repair owner must know which changes require another review.Router movement, endpoint replacement, firmware updates, and repeated discovery can reopen the route claim when they change its tested assumptions.
- Recovered traffic cannot establish the failure cause or permanent repair.The incident record needs the failed assumption, observed path, and a retest trigger so a temporary return of reports does not close every question.
Major section
Routing Evidence Families
Different evidence families answer different questions about a route.
- Discovery evidence shows whether a source can find a missing path.AODV-style requests and replies need observations from the intended source and destination before the discovered route becomes part of the service claim.
- Repair evidence shows behaviour after a path assumption changes.A router-removal test must retain both recovered endpoints and unresolved gaps, with gateway visibility sufficient for support to identify the remaining problem.
- Many-to-one collection and downstream source routing need separate evidence.Traffic toward a concentrator can work while downstream commands depend on route records that no longer match the gateway or topology.
- Gateway and application records connect routing behaviour with service.Support needs visible interruption, retry, or application failure, while an operations owner must monitor symptoms and retest after placement or router changes.
Major section
AODV Path Cost Evidence
This path connects route discovery with the evidence needed to approve continuing service.
- The source endpoint first needs a route toward its destination.The diagram begins with a source whose route is unavailable, then follows discovery requests into the mesh toward the intended destination.
- Requests accumulate link cost before a reply establishes the selected path.A longer chain of reliable links can cost less than a shorter weak chain, so the selected route need not have the fewest hops.
- The route record preserves state for later frames and diagnosis.Routers on the selected path install route-table state, allowing later frames to reuse discovery rather than search again for every application frame.
- Gateway visibility connects the observed route with an owned service decision.The final diagram stages need support-visible failures, a bounded routing decision, an owner, and a retest trigger beyond the successful reply.
Activity 1 · Draw it
✎ Rebuild the discovery path
I want you to follow the packet before you call the mesh repaired.
On paper, sketch a source, intervening routers, and destination. Add route-request arrows, a return reply, and the route state used by later frames. Explain why the selected path need not have the fewest hops.
4 minutes · Pen and paper · Answer: Activity 1
Major section
Route Repair and Concentrator Evidence
Concentrator traffic needs separate checks for collection and downstream commands.
- Many-to-one routing supports traffic toward a collection point.A collection-heavy system can reduce repeated discovery toward its coordinator or gateway, but that result cannot establish every other traffic direction.
- The concentrator needs usable route records for downstream source routes.Downlink commands can depend on captured route records, so their custody and refresh after topology changes belong in the routing review.
- Gateway replacement can disturb those records while joins remain intact.The chapter’s replacement case needs before-and-after route-record evidence and gateway configuration checks before inconsistent commands can be treated as repaired.
- Recovered uplinks do not prove all downstream command paths work.Representative downlink and uplink tests must identify the commands that remain proven and the exclusions still assigned for repair and retest.
Major section
Routing Tables, Source Routes, and Tree Fallback
The active forwarding mechanism determines which stored state needs investigation.
- A route-table entry maps a destination to its next hop.AODV-discovered state lets later frames reuse a selected route, but stale entries need forwarding evidence before the application path can be approved.
- A concentrator can use source routes learned from route records.Those records support downstream frames and can stop matching the network after a gateway or router change alters the observed topology.
- Tree fallback can follow the parent-child hierarchy when another route fails.An unknown route, unsuccessful discovery, or constrained routing state can leave hierarchical forwarding available, without proving the preferred lowest-cost mesh route.
- Stale entries and topology changes create different failure mechanisms.The repair must address the route actually carrying the flow, because a refreshed table and a corrected gateway source route solve different problems.
Major section
Hidden latency in fallback and stale routes
Acceptable throughput can hide a slow or fragile forwarding path.
- Hierarchical fallback can keep traffic moving along a longer route.The parent-child path may preserve reachability while adding delay, so returned reports cannot establish that the preferred mesh discovery is working.
- An outdated source route can mismatch the current router arrangement.A gateway or topology change can invalidate stored downstream state even when endpoint joins still appear intact in the network record.
- Unexpected latency needs evidence of the active forwarding mechanism.Acceptable throughput can coexist with tree fallback or stale source-route state, leaving a discovery problem hidden behind apparently successful traffic.
- Refreshed topology or gateway state needs an owner and representative retests.The review should approve only observed paths after the refresh, preserving unresolved endpoints and service limits until the new evidence supports acceptance.
Major section
Routing Review Record
This repair record connects a route incident with a bounded operational decision.
- The event and affected-endpoint fields define the incident’s scope.The first row names a router, parent, gateway, or topology change and the endpoint functions whose behaviour the repair review must address.
- The observed-path field connects forwarding evidence with a failed assumption.Discovery, route state, and the specific stale dependency belong in the record rather than a broad label such as mesh instability.
- Gateway evidence connects the route incident with visible service impact.The record needs interruption or application-failure visibility so support can distinguish a radio change from a command path that remains unproven.
- The decision, owner, and retest trigger close the bounded record.Router movement, gateway replacement, or endpoint changes can reopen approval, preventing the current recovery result from becoming a permanent routing promise.
Activity 2 · Predict
✎ Replace the gateway
I want you to separate a successful join from a command that actually reaches its endpoint.
A replacement gateway preserves device joins, but some downlink commands fail. Write two routing checks and one limit on what you can approve before retesting.
3 minutes · Pen and paper · Answer: Activity 2
Major section
Routing Evidence Checklist
This packet map separates route choice from service identity and link-level checks.
- The PHY and MAC fields describe radio and link boundaries.The packet map begins below routing, so a frame’s valid link-level check cannot establish that it followed the intended application path.
- The NWK portion owns route selection.The next boundary chooses the network path, leaving the lighting service’s identity and endpoint meaning to the application-support portion of the frame.
- APS names profiles and endpoints while security protects its own boundary.The map separates service identity from hop protection through security fields and counters, keeping those claims distinct from the chosen network route.
- A valid frame check cannot prove route intent or application authorization.The boundary rule requires separate routing and service evidence before a received frame can support the intended lighting-operation claim.
Major section
Concept Relationships
Routing depends on surrounding network and service evidence, and never replaces that evidence.
- Formation evidence establishes joins and parents that routing depends on.The gateway-replacement case shows that preserved joins leave downstream commands unproven, so attachment evidence cannot replace a routing retest after change.
- Topology evidence defines available path diversity for the routers.Connected devices in a diagram need real forwarding and repair observations before an alternate route can support the deployment’s service claim.
- Stack boundaries separate network forwarding from application endpoint behaviour.NWK chooses the route while APS names the service, so the lighting command requires evidence across both boundaries rather than one packet check.
- Deployment records connect routing changes with ownership and service retests.Router movement, gateway changes, endpoint replacement, and firmware updates can reopen acceptance, making the operational owner part of the continuing routing review.
Deck summary
Key takeaways
A release decision requires observed, bounded route behavior.
- Discovery and route-table state need representative forwarding evidence.The lamp command must use an observed path to its intended destination; a stored next hop alone cannot establish application behaviour.
- Recovery checks must retain unresolved endpoints and both traffic directions.Most devices resuming reports does not prove that a silent endpoint recovered or that downstream commands work after a gateway replacement.
- Gateway records must expose route changes and service impact.Support needs interruption, retry, or application-failure evidence before it can connect a routing symptom with the endpoint function requiring repair.
- An operating owner and retest triggers keep the accepted claim current.The route record needs a named repair responsibility and fresh tests after topology, gateway, endpoint, or firmware changes affect its approved boundary.
Retrieval practice
Recall check 1 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q1In Zigbee AODV-style routing, what should a reviewer expect the selected route to minimize?
Show answer
Answer: A Route requests and replies discover paths on demand; accumulated link cost, not hop count alone, selects the route.
Retrieval practice
Recall check 2 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q2A router failure causes a brief burst of route requests, then endpoint traffic resumes on a new path. How should this be read?
Show answer
Answer: A A bounded route-request burst that resolves into resumed traffic is healthy repair evidence; continuous discovery is route churn.
Retrieval practice
Recall check 3 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q3A Zigbee route-repair test removes one powered router. Most endpoints resume reporting through another path, but one endpoint stays silent and the gateway does not show which path failed. What is the strongest review decision?
Show answer
Answer: C Routing review approves only the behavior that the evidence supports, records gaps for repair, and retests after repair.
Retrieval practice
Recall check 4 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q4Why should tree routing be treated as fallback evidence in a Zigbee routing review?
Show answer
Answer: A Tree routing follows hierarchical addressing as a fallback.
Retrieval practice
Recall check 5 of 5
Radio Remi says: answer from memory, then check your reasoning.
Q5A routing review shows route-table entries and a clean topology diagram, but it does not test route repair, gateway visibility, or ownership after router replacement. What should the reviewer do?
Show answer
Answer: B Routing readiness needs evidence that the path works, repairs acceptably, is visible enough, and has an owner.
Print reference
Answers 1 of 2
Answer key.
- A · Route requests and replies discover paths on demand; accumulated link cost, not hop count alone, selects the route.
- A · A bounded route-request burst that resolves into resumed traffic is healthy repair evidence; continuous discovery is route churn.
- C · Routing review approves only the behavior that the evidence supports, records gaps for repair, and retests after repair.
- A · Tree routing follows hierarchical addressing as a fallback.
Print reference
Answers 2 of 2
Answer key.
- B · Routing readiness needs evidence that the path works, repairs acceptably, is visible enough, and has an owner.
Print reference
Activity 1 answer
Model answer.
Draw it: The source broadcasts a route request; routers can rebroadcast it while adding link cost. The destination or a router with a usable route replies along the selected path. Routers store route-table state for later frames. Accumulated path cost can favor more reliable links over fewer hops.
Print reference
Activity 2 answer
Model answer.
Predict: Check route-record custody and source-route state before and after replacement. Test representative downstream commands as well as uplinks. Approve only the observed, retested paths; preserved joins do not establish preserved routing.