4、Zigbee网络组建与管理：网络形成流程、节点入网与拓扑维护
好，咱们进入第四章。这一章讲的是Zigbee网络怎么“从无到有”，以及怎么“活下去”。说白了，就是网络怎么建起来，设备怎么加进来，以及网络怎么自我修复。我在好几个项目里都栽过跟头，尤其是网络不稳定的时候，最后发现都是这些基础环节没处理好。
4.1 网络形成流程：PAN ID选择与信道扫描
一个Zigbee网络，总得有个“发起人”。这个角色就是协调器（Coordinator）。它上电后第一件事，不是急着喊“大家快来连我”，而是先做环境调查。
4.1.1 信道扫描：先听再说
协调器会执行一次能量扫描（Energy Scan），看看哪个信道的干扰最小。你想想看，如果2.4GHz频段上Wi-Fi、蓝牙都在抢，Zigbee的信道很容易被挤爆。
我个人习惯，在固件里把能量扫描的阈值设得严格一点。比如默认-75dBm以上就算“拥挤”，我会调到-80dBm。为什么？因为我在一个智能家居项目里遇到过，协调器选了个“看起来还行”的信道，结果一到晚上Wi-Fi流量高峰，Zigbee网络就频繁掉线。嗯，后来改成更严格的阈值，问题就解决了。
扫描流程大致如下：
- 能量扫描：遍历所有可用信道（通常是11到26），测量每个信道的能量值。
- 主动扫描：发送Beacon请求，看看周围有没有现成的Zigbee网络。如果有，就记下它们的PAN ID。
- 信道选择：选一个能量最低、且没有冲突PAN ID的信道。
核心原则：信道选择不是“选最安静的”，而是“选最干净且不冲突的”。安静但已有网络的信道，你硬挤进去，两个网络会互相干扰。
4.1.2 PAN ID选择：避免“撞车”
PAN ID是网络的身份证。协调器会从主动扫描结果里，知道哪些PAN ID已经被用了。然后它自己选一个没被占用的。如果实在找不到空闲的，可以选一个随机的，但一定要确保不冲突。
我曾经遇到过一个坑：某个设备厂商的协调器固件，PAN ID选择逻辑写得太简单，直接用了出厂默认值0xFFFF。结果两个邻居家的网关都用了这个值，网络串扰得一塌糊涂。从那以后，我坚持在固件里加入“PAN ID冲突检测”机制，每次上电都重新扫描确认。
4.2 节点入网机制：Association与Rejoin
网络建好了，设备怎么加进来？Zigbee提供了两种主要方式：关联（Association）和重新加入（Rejoin）。
4.2.1 Association：标准入网流程
这是最常用的方式。节点上电后，会主动扫描周围的路由器或协调器，然后发送关联请求。流程如下：
- 节点发送Beacon请求，寻找允许加入的网络。
- 路由器或协调器回复Beacon，包含网络信息（如PAN ID、是否允许加入）。
- 节点发送关联请求（Association Request）。
- 父节点分配一个16位短地址，回复关联响应（Association Response）。
这里有个细节：父节点分配短地址时，要保证唯一性。我见过一个案例，因为地址分配表没及时更新，导致两个节点拿到了相同的短地址，网络直接乱套。所以，地址管理一定要用原子操作，加锁或者用事务机制。
我的小技巧：在固件里，我会把短地址分配做成一个“预分配+确认”的流程。先分配一个临时地址，等节点确认收到后，再正式写入地址表。这样能避免因丢包导致的地址冲突。
4.2.2 Rejoin：快速重新入网
Rejoin是给已经入过网的设备用的。比如节点掉电重启，或者网络拓扑变化，它不需要重新走一遍完整的Association流程。它直接发送Rejoin请求，父节点如果还记得它，就直接恢复连接。
Rejoin有两种模式：
- 带安全上下文的Rejoin：节点还记得网络密钥，直接加密通信。速度快，安全性高。
- 不带安全上下文的Rejoin：节点忘了密钥，需要重新认证。速度慢一些，但适合设备被重置后的场景。
我个人建议，在固件里优先使用带安全上下文的Rejoin。为什么？因为我在一个工业项目里，设备频繁掉电，每次都用不带上下文的Rejoin，结果网络密钥交换占用了大量带宽，其他节点的数据都传不上来了。后来改成带上下文的Rejoin，网络负载立刻降下来了。
4.3 网络拓扑维护：路由表与邻居表
网络建好了，节点也加进来了，但这不是终点。Zigbee网络是动态的，节点可能移动、掉电、干扰变化。所以，拓扑维护是固件里最考验功底的部分。
4.3.1 路由表：数据怎么走
每个路由器（包括协调器）都维护一张路由表。这张表告诉它：“你要发数据给某个目标，下一跳该找谁。”路由表的结构大致如下：
| 字段 | 说明 |
|---|---|
| 目标地址 | 16位短地址 |
| 下一跳地址 | 下一跳路由器的短地址 |
| 状态 | ACTIVE、DISCOVERY、FAILED等 |
| 路由成本 | 到目标的链路质量评估 |
路由表不是一成不变的。Zigbee协议栈会定期执行路由发现（Route Discovery），更新最优路径。但这里有个权衡：路由发现太频繁，网络开销大；太不频繁，路径老化后数据传不过去。
我一般把路由发现周期设为30秒到60秒之间。但要注意，如果网络里节点数量超过50个，这个周期要适当拉长，否则路由请求会像广播风暴一样把网络打满。嗯，我在一个100个节点的项目里吃过这个亏，后来把周期调到120秒，才稳定下来。
4.3.2 邻居表：谁在我旁边
邻居表记录了当前节点能直接通信的邻居设备。每个节点（包括终端设备）都会维护一张邻居表。它包含：
- 邻居的短地址和IEEE地址
- 链路质量（LQI）
- 关系（父节点、子节点、兄弟节点）
- 设备类型（协调器、路由器、终端）
邻居表是路由决策的基础。如果一个邻居的LQI持续低于某个阈值（比如20），就应该把它标记为“不可用”，并触发路由修复。
注意：邻居表不是越大越好。Zigbee协议栈通常限制邻居表条目数（比如20条）。如果邻居太多，要优先保留链路质量好的。我见过一个项目，因为邻居表满了，新节点无法加入，老节点又频繁掉线，整个网络陷入死循环。
4.3.3 拓扑维护的常见策略
在实际项目中，我总结了几条经验：
- 定期发送链路状态帧：每个路由器每隔一段时间（比如15秒）向邻居发送一个轻量级的“我还活着”帧。这样能快速发现断链。
- 被动监听：节点在空闲时，监听周围的数据帧，更新邻居表的LQI。这样不用额外开销。
- 路由修复触发条件：当连续3次发送数据失败，或者收到路由错误帧（Route Error），立即启动路由发现。
我曾经在一个智能照明项目里，把链路状态帧的间隔从15秒改成了30秒，结果网络收敛速度慢了一倍。后来发现，15秒是最佳平衡点——既不会太耗电，又能及时感知拓扑变化。
小结
这一章的内容，说白了就是三个字：建、连、维。网络形成是“建”，节点入网是“连”，拓扑维护是“维”。每一个环节都有坑，但只要你理解了背后的原理，再加上一点项目经验，就能避开大部分问题。
下一章，我们会深入Zigbee的绑定机制和组播通信。到时候再聊。