4. 协议栈并发模型
在 Silicon Labs 平台上讨论“多协议并发”，首先要区分两个层面：一是无线射频（Radio）层面的并发，二是协议栈与软件调度层面的并发。EFR32 系列 SoC 通常只有一套 2.4 GHz 射频前端（部分型号另有 Sub-GHz 射频），因此所谓“同时运行 Zigbee、Thread、BLE、Z-Wave”，在物理层上并不是真正的同时收发，而是通过分时复用（Time Division Multiplexing）加协议栈仲裁来实现的。理解这一点，是判断哪些组合可行、哪些组合受限的前提。
一、四种协议在 Silicon Labs 平台上的定位差异
Zigbee 与 Thread 都基于 IEEE 802.15.4 PHY/MAC，工作在 2.4 GHz，使用相同的信道划分（11～26 信道），因此二者在射频层高度同源，可以共享同一套 802.15.4 射频驱动。BLE 同样工作在 2.4 GHz，但采用 40 个 2 MHz 带宽信道与跳频机制，PHY 与 802.15.4 不同。Z-Wave 则工作在 Sub-GHz 频段（如 868.42 MHz、908.42 MHz、921.4 MHz 等区域频点），其 PHY 与 2.4 GHz 协议完全不同，通常需要独立的 Sub-GHz 射频通道或外置 Z-Wave 模块。
由此可以得出一个关键结论：Zigbee 与 Thread 的并发属于“同 PHY 协议切换”，BLE 与 802.15.4 的并发属于“跨 PHY 分时”，而 Z-Wave 与前三者的并发属于“跨频段、跨射频通道”的并发。这三类并发在 Silicon Labs 的软件架构中由不同的机制支撑，限制也各不相同。
二、同 PHY 并发：Zigbee 与 Thread 的动态多协议
Silicon Labs 的 Dynamic Multiprotocol（DMP） 机制允许 Zigbee 与 Thread 在同一颗 2.4 GHz 射频上分时运行。其核心是 RAIL（Radio Abstraction Interface Layer）层的时间片仲裁：每个协议栈在需要收发时向 RAIL 申请射频使用权，RAIL 根据优先级和时隙分配决定当前由哪个协议栈占用射频。典型配置下，Zigbee 与 Thread 各自获得约 50% 的射频时间片，切换粒度可达到毫秒级。
这种并发的限制在于：同一时刻只有一个协议栈能真正收发。如果 Zigbee 正在发送一个较长的数据帧，Thread 的入网请求就必须等待。对于时延敏感的 Thread 边界路由器或 Zigbee 协调器场景，需要合理设置各协议栈的时隙权重。在 Simplicity Studio 中，可以通过 sl_rail_util_mp 相关配置项调整调度策略，例如设置 SL_RAIL_UTIL_MULTIPROTOCOL_SCHEDULER 的优先级参数。
三、跨 PHY 并发：BLE 与 802.15.4 的共存
BLE 与 Zigbee/Thread 的并发是 Silicon Labs 平台上最常见的组合，例如“BLE 配网 + Zigbee 控制”或“BLE 信标 + Thread mesh”。由于二者共享 2.4 GHz 频段但 PHY 不同，射频前端需要在 BLE 和 802.15.4 之间快速切换。EFR32 的射频前端支持这种切换，但切换本身需要时间（典型值在百微秒量级），因此会带来一定的吞吐量下降。
更关键的限制是信道冲突。BLE 的广播信道（37、38、39）位于 2.4 GHz 频段的高端，而 802.15.4 的信道 11～26 覆盖整个 2.4 GHz 频段。当 BLE 广播与 802.15.4 数据帧在时间上重叠且频率接近时，会产生相互干扰。Silicon Labs 的 Coexistence（共存） 机制通过 PTA（Packet Traffic Arbitration）信号或软件调度来降低冲突概率。在软件共存模式下，BLE 协议栈会主动避让 802.15.4 的活跃时隙。
四、Z-Wave 并发的特殊性
Z-Wave 在 Silicon Labs 平台上通常以两种形式存在：一是使用支持 Sub-GHz 的 EFR32 型号（如 EFR32FG 系列）直接运行 Z-Wave 协议栈；二是通过外部 Z-Wave 模块（如 ZGM130S）与主控 SoC 配合。前者可以在同一颗芯片上实现 Z-Wave 与 2.4 GHz 协议的并发，因为 Sub-GHz 和 2.4 GHz 是两套独立的射频通道，互不抢占；后者则通过 UART 或 SPI 与主控通信，主控上的 Zigbee/Thread/BLE 与 Z-Wave 模块之间是松耦合的。
需要注意的是，Z-Wave 的协议栈实现与 Zigbee/Thread/BLE 不同，它并不运行在 RAIL 之上，而是有独立的 MAC 层和射频驱动。因此，Z-Wave 与 2.4 GHz 协议的并发更多是“硬件通道级”的并发，而非“射频时间片级”的并发。这也意味着 Z-Wave 的并发能力受限于芯片是否具备 Sub-GHz 射频前端，以及是否有多余的射频通道资源。
五、并发组合的可行性与限制总结
| 并发组合 | 射频通道 | 并发机制 | 主要限制 |
|---|---|---|---|
| Zigbee + Thread | 同一 2.4 GHz | DMP 时间片仲裁 | 同一时刻仅一个协议栈收发，时延增加 |
| Zigbee/Thread + BLE | 同一 2.4 GHz | 跨 PHY 分时 + 共存调度 | 信道冲突、切换开销、吞吐量下降 |
| Z-Wave + Zigbee/Thread/BLE | Sub-GHz + 2.4 GHz | 独立射频通道并行 | 需 Sub-GHz 射频前端或外部模块，成本增加 |
| Zigbee + Thread + BLE | 同一 2.4 GHz | 三协议 DMP 调度 | 时间片进一步碎片化，实时性显著下降 |
六、工程实践中的配置要点
在 Simplicity Studio 中创建多协议工程时，首先需要在 Project Configurator 的 Radio Configurator 中确认射频通道配置。对于 Zigbee + Thread 并发，选择 Dynamic Multiprotocol 模板，并在 sl_rail_util_mp 组件中设置各协议栈的优先级和时隙比例。对于 BLE + 802.15.4 并发，需要启用 Coexistence 组件，并配置 PTA 引脚或软件共存参数。
一个常见的配置示例是：BLE 用于设备配网，Zigbee 用于日常控制。在 sl_bt 配置中将 BLE 广播间隔设置为 100 ms 以上，减少对 802.15.4 的干扰；在 sl_zigbee 配置中将 SL_ZIGBEE_RAIL_UTIL_MULTIPROTOCOL 的优先级设为高于 BLE。这样在配网完成后，Zigbee 可以获得更多的射频时间片，保证 mesh 网络的稳定性。
总结来说，Silicon Labs 平台上的多协议并发并非“所有协议都能同时全速运行”，而是根据射频通道、PHY 类型和协议栈调度机制，在不同层级上实现的有限并发。理解 Zigbee/Thread 的同 PHY 切换、BLE 与 802.15.4 的跨 PHY 分时、以及 Z-Wave 的跨频段并行，是设计多协议产品时选择芯片型号、配置协议栈和评估性能边界的基础。