12 Zigbee Network Topologies

zigbee-thread

zigbee

topology

Keywords

Zigbee topology evidence, Zigbee star tree mesh review, Zigbee coordinator router end device roles, Zigbee route diversity review, Zigbee topology readiness

12.1 Start With One Packet Path

Start with one packet path through Zigbee Network Topologies. Name the sender, the next hop, the parent or router decision, and the evidence that proves the packet arrived for the reason the design expected.

Then widen the review. Mesh protocols fail at boundaries: sleepy children, route repair, parent changes, multicast, retries, and gateway custody. The chapter is easier to read when every detail is tied back to that first path.

Overview: What a Zigbee Topology Claim Means

Zigbee topology review asks whether the network shape matches observed coordinator, router, and end-device behavior. Star, tree, and mesh are useful words, but they are not proof by themselves. A reviewable topology claim names the deployment boundary, identifies the node roles, records parent relationships, and states what route or recovery behavior was actually observed.

The safest beginner rule is simple: approve only the topology behavior that the record can support. A small direct network can be acceptable when the direct coordinator dependency is intentional. A tree can be acceptable when parent and branch behavior are understood. A mesh can be acceptable when route diversity has been observed where resilience is required.

Radio Remi

“Range, power, and data-rate is a triangle — pick two honestly, then measure the third in the real room.”

Through this chapter, Remi checks each topology claim for its role evidence, its trade, and what the site must show.

A topology claim should connect the network shape to observed coordinator, router, and end-device roles before it is used as release evidence.

If you only need the intuition, this layer is enough: a topology diagram is a hypothesis. The evidence record turns that hypothesis into a bounded release decision.

Topology Evidence Families

Star evidence

Records direct coordinator dependencies, the small boundary where they are acceptable, and the site change that requires retesting.

Tree evidence

Records parent-child structure, branch dependencies, orphan behavior, and the owner for parent changes.

Mesh evidence

Records router participation, observed alternate paths, route-change behavior, and weak zones that still have one dependency.

Operations evidence

Records who owns powered routers, coordinator custody, topology refresh, recovery drills, and retest triggers after changes.

Beginner Examples

A device appearing online proves a narrow reachability observation, not parent quality, route diversity, or recovery behavior.
A powered device near an end device might be a router, but the topology record should show the actual role and parent relationship.
A mesh claim can be partly true: one monitored path may have observed alternatives while another area remains dependent on one parent.

Overview Knowledge Check

Practitioner: Build a Topology Evidence Record

A practical topology review starts with a decision claim. The claim should say what behavior is being approved, where it applies, and what evidence makes it ready. The record should then separate role evidence from path evidence so a tidy diagram does not hide fragile dependencies.

For each important device or zone, record the coordinator boundary, selected parent or next hop, expected router role, observed alternate path when resilience is required, and the change that makes the record stale. This keeps topology review useful after devices move, routers lose power, firmware changes, or a gateway is replaced.

Record Field

Review Question

Evidence To Record

Common Overclaim

Boundary

Where does the topology claim apply?

Room, floor, site, pilot group, excluded areas, coordinator or gateway boundary, and operating condition.

"The whole product is ready because one area was observed."

Role map

Which nodes acted as coordinator, routers, and end devices?

Coordinator custody, powered routers expected to stay available, sleepy end devices, role changes, and owner for each role.

"The inventory proves which devices routed traffic."

Parent and route evidence

Which dependencies did important devices actually use?

Parent relationships, next hops, route changes, observed alternate paths, unsupported paths, and weak zones.

"A mesh diagram means every device has a good alternate path."

Decision and retest

What is approved, what is outside scope, and when must the record be refreshed?

Accept/revise/retest decision, known gaps, operations owner, device move, router loss, coordinator change, traffic change, or site change.

"The topology remains approved after any maintenance change."

Worked Review: Small Direct Network

A small monitored area shows every reviewed end device reporting directly through the coordinator. The practitioner decision can accept a bounded star claim if the direct dependency is intentional, the coordinator placement is stable, no hidden router dependency was found, and operations knows what move or added device requires retesting.

Remi’s Signal Check

Band: a small monitored area where every reviewed end device reports directly through the coordinator — a bounded star claim.
Trade: direct dependency is fine when it is intentional and the coordinator placement is stable — not fine as an accident.
Room test: confirm no hidden router dependency, and record what added device requires a retest.

Worked Review: Router Removed From a Mesh

A powered router is removed during maintenance and nearby end devices reconnect through a different parent. The review should compare parent evidence before and after removal, check whether application behavior still matches the release claim, and narrow the decision to the paths that actually recovered. Devices that moved to fragile parents remain outside the approved mesh claim until revised or retested.

Practitioner Knowledge Check

Under the Hood: Role Dynamics, Route Drift, and Retest Triggers

Under the hood, Zigbee topology is dynamic. End devices select parents, routers may participate in forwarding, routes can be repaired, and application behavior can continue or fail after the network path changes. The review should preserve those dynamics instead of freezing the network as a static drawing.

The most important boundary is between what was observed and what was assumed. A route table snapshot, gateway inventory, or diagram can support a record, but it should not replace failure drills, parent-change evidence, route-change evidence, and owner decisions for maintenance events.

Dynamic Event

What To Inspect

Failure Pattern

Retest Trigger

Parent change

End-device parent before and after the event, path quality, latency, report freshness, and application impact.

The device appears online but is now dependent on a weaker parent or an overloaded branch.

Device move, battery behavior change, router move, wall power change, enclosure change, or local interference change.

Router loss

Which devices used the router, which devices recovered, which devices moved to a fragile path, and which owner approves the new state.

The network repairs for some devices while a critical zone silently loses redundancy.

Maintenance removal, outlet use change, firmware update, replacement device, or planned power policy change.

Coordinator or Trust Center change

Custody owner, join policy, address and security effects, rejoin behavior, backup plan, and support runbook.

Topology is treated as unchanged even though the root of network custody changed.

Coordinator replacement, backup restore, security policy change, gateway bridge change, or ownership transfer.

Scaling change

New zones, added reporting traffic, group commands, retries, router capacity, weak links, and split-network boundary.

A design that worked in a small pilot is approved for a larger site without renewed path evidence.

Device count growth, new floor or room, traffic pattern change, alert latency change, or added automation rule.

Remi’s Signal Check

Band: a coordinator or Trust Center change resets custody, join policy, address and security effects, and rejoin behavior.
Trade: a design that worked in a small pilot needs renewed path evidence at a larger site — new zones, traffic, router capacity, weak links.
Room test: retest after coordinator replacement, backup restore, security-policy change, or device-count growth.

Diagnosis Pattern

Name the exact topology claim. Separate a direct reachability claim from a route-diversity or recovery claim.
Preserve role and parent evidence. Record coordinator custody, router role, parent choice, route observations, and application symptoms before changing anything.
Retest the changed boundary. A moved router, changed gateway, new firmware, or larger traffic load invalidates different parts of the topology record.
Narrow the decision. Approve the paths that recovered, flag paths that became fragile, and write the unsupported claim explicitly.

Under-the-Hood Knowledge Check

12.2 Summary

Zigbee topology review starts with a bounded claim, not with a diagram or protocol label.
Star evidence proves direct coordinator dependencies only inside the reviewed boundary.
Tree evidence records parent-child structure, branch dependencies, orphan behavior, and owner decisions.
Mesh evidence needs observed router participation, route alternatives, and route-change behavior where resilience is claimed.
Operations evidence keeps the topology record alive after device movement, router loss, coordinator change, traffic growth, or ownership change.

Key Takeaway

Approve a Zigbee topology claim only when coordinator, router, end-device, parent, route, owner, and retest evidence support the exact behavior being released.