13 Zigbee Network Formation
Zigbee network formation evidence, Zigbee commissioning review, Zigbee Trust Center custody, Zigbee joining evidence, Zigbee parent selection review
13.1 Start With One Packet Path
Start with one packet path through Zigbee Network Formation. 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: Formation Is the Network's First Evidence Record
Zigbee network formation is the review record that explains how a coordinator created a network and how devices were allowed to join it. A useful record does not stop at "the device joined." It names the deployment boundary, channel and PAN decision, Trust Center custody, joining rule, association result, selected parent, application observation, owner, and retest trigger.
The beginner mistake is to treat formation as a setup screen. Formation is a release gate. It decides whether the network identity, joining authority, and first parent relationships are controlled enough to support the actual product behavior.
If you only need the intuition, this layer is enough: a successful join is evidence for one bounded event. It is not proof that future devices, replacement devices, changed channels, or open joining are safe.
Formation Evidence Families
Channel and PAN
Records the chosen wireless channel, network identity, coordinator persistence, nearby-network observations, and retest rule.
Trust Center custody
Records who controls joining, which commissioning method is allowed, how join material is protected, and where logs live.
Join and association
Records which device joined, which join permission was active, which parent accepted it, and whether key transport completed.
Operations decision
Records accept, revise, reject, or retest; the owner of future joins; and the change that makes the record stale.
Beginner Example
An installer opens joining for three expected devices. Three expected identities and one unknown identity appear. The network formed and devices joined, but the release decision should be revised until the unexpected identity is explained, removed, quarantined, or explicitly accepted under the custody rule.
Overview Knowledge Check
Practitioner: Build the Formation and Join Record
A practical formation review starts with a claim that has boundaries. The claim should say which coordinator, site boundary, channel and PAN decision, device set, join method, and application behavior are being approved. Everything outside that observed boundary stays out of scope until it is reviewed.
How It Works: Controlled Formation
- Define the boundary. Name the site, pilot area, coordinator or gateway, expected device classes, and excluded conditions.
- Record channel and PAN evidence. Capture why the channel and network identity were accepted and what change requires a fresh review.
- Name Trust Center custody. State who can approve joining, how join material is protected, and how logs are preserved.
- Open joining deliberately. Record who opened joining, why, where, for which devices, and how it was closed.
- Verify the joined state. Record identity, role, selected parent, key transport result, application observation, owner, and retest trigger.
Intermediate Example
A failed sensor is replaced with a new unit that should inherit the same role. A reviewable decision does not approve the replacement from gateway visibility alone. It records the old identity, new identity, approved join window, Trust Center approval path, selected parent, key transport result, expected application behavior, and updated owner record.
Formation Review Ledger
Worked Review: Controlled Join Window
An installer opens joining to add a small group of devices. The record compares expected identities with joined identities, confirms who opened joining, checks the Trust Center decision, records which parent accepted each device, closes joining, and states whether the result is accepted or revised. An unexpected identity changes the decision even if every expected device also joined.
Practitioner Knowledge Check
Under the Hood: Formation Evidence Can Drift
Under the hood, formation evidence becomes stale when the channel environment changes, the coordinator or gateway is replaced, joining authority changes, devices are moved, parents change, or replacement devices enter the network. The review should treat these events as retest triggers instead of assuming the original setup remains valid forever.
The most important separation is between network-side evidence and application-side evidence. A device may associate and receive network material, but the product still needs to prove the expected report, command, state, or gateway-visible behavior after joining. Conversely, application visibility should not erase missing custody or parent-selection evidence.
Formation Drift Patterns
Setup drift
A successful setup screen is treated as release evidence even though the boundary, owner, and retest trigger were never recorded.
Open-join drift
Joining remains easy for installers but becomes unclear for support, security review, and unexpected-device investigation.
Parent drift
A device joins through an unexpected parent, then the topology and routing consequences are missed because the device appears online.
Replacement drift
A new device inherits an old role without fresh identity, custody, key transport, parent, and application evidence.
Diagnosis Pattern
- Start with the stale claim. Decide whether the old evidence still covers the channel, coordinator, device, parent, and application boundary.
- Preserve custody evidence. Record who opened joining, how the Trust Center decision was made, and which logs can support later troubleshooting.
- Inspect the parent relationship. A replacement or rejoin can change parent dependencies even when the gateway shows the device online.
- Narrow the decision. Accept only the observed formation behavior and write any unsupported future join, replacement, or topology claim explicitly.
Under-the-Hood Knowledge Check
13.2 Summary
Zigbee network formation review is about custody and evidence. A strong record explains the channel and PAN decision, Trust Center owner, controlled join window, joined identities, selected parents, key transport result, application observation, operations owner, and retest trigger.
Do not let a successful join become an unbounded deployment claim. Keep formation evidence tied to the reviewed site boundary and refresh it when the coordinator, channel environment, device identity, parent relationship, or operations rule changes.
Approve Zigbee network formation only when channel, PAN, Trust Center, join, parent, application, owner, and retest evidence all support the exact deployment boundary.
13.3 See Also
Zigbee Network Topologies
Review coordinator, router, end-device, parent, and route evidence after formation creates the network boundary.
Zigbee Routing
Use this when selected parents and router participation need route discovery, repair, and recovery evidence.
Zigbee Security
Use this for Trust Center custody, key handling, joining approval, and security evidence boundaries.
Zigbee Application Profile Evidence Review
Connect successful joining to clusters, endpoints, and product behavior after commissioning.