4. 无线协议栈基础与Silicon Labs协议栈选型
多协议无线网关的核心价值，在于用一颗或一组无线SoC同时接入不同生态的设备，并把它们统一到IP或应用层语义上。要做到这一点，开发者必须先理解各协议栈在物理层、MAC层、网络层、应用层上的分工，再结合网关的并发需求、设备规模、功耗约束和云端对接方式，选择Silicon Labs提供的对应SDK组件。本节先横向对比802.15.4、Zigbee、Thread、BLE、Z-Wave、Wi-SUN与Matter的协议特点，再给出面向网关需求的选型与SDK配置方法。
一、协议栈分层视角：先看“谁负责什么”
无线协议栈通常按IEEE 802.15.4或BLE等底层规范、网络层、应用层来划分。802.15.4只定义PHY与MAC，提供低速率、低功耗的无线承载，本身不具备路由和互操作语义；Zigbee、Thread、Wi-SUN都构建在802.15.4之上，但网络层设计差异很大。BLE则自成体系，包含广播、连接、GATT等机制，既可点对点，也可通过Mesh扩展。Z-Wave使用Sub-1GHz专有频段与自有协议栈，抗干扰和穿墙能力较好，但芯片与生态相对封闭。Matter并不是新的射频协议，而是应用层统一数据模型与配网规范，底层可跑在Thread、Wi-Fi或以太网之上，常与BLE配合完成入网。
二、各协议特点与网关适配性
802.15.4是底层承载，网关若直接使用它，需要自行实现网络层，通常只在定制私有协议时采用。Zigbee生态成熟、设备品类多，采用网状路由，适合照明、传感器、开关等场景；但Zigbee并非原生IP，网关需做协议转换。Thread基于IPv6和6LoWPAN，天然支持IP寻址，边界路由器可直接把设备接入局域网，适合与Matter、云端直连配合。BLE适合配网、近场调试和低功耗外设，也可通过BLE Mesh覆盖较大范围，但吞吐和节点规模有限。Z-Wave工作在Sub-1GHz，干扰少、穿墙好，适合安防与家庭自动化，但需专用芯片和认证。Wi-SUN面向大规模户外网络，如智能电表、路灯，覆盖广、节点多，但功耗和成本高于室内协议。Matter解决跨生态互操作，网关若作为Matter桥接器，可把Zigbee或Z-Wave设备映射为Matter设备。
三、按网关需求选择协议栈
选型时先明确三个问题：网关要接入哪些生态的设备？是否需要IP直达云端？并发协议数量与芯片资源是否匹配？例如，一个面向智能家居的网关，若需同时支持Zigbee传感器、Thread设备、BLE配网和Matter桥接，可选用Silicon Labs EFR32MG24系列，它支持Zigbee、Thread、BLE多协议并发，并具备Matter over Thread能力。若网关还需Wi-Fi回传，可选用SiWx917等Wi-Fi+BLE组合方案，把Wi-Fi作为上行，BLE用于本地配网。
在SDK层面，Silicon Labs的Gecko SDK（GSDK）以组件化方式组织协议栈。创建工程时，可在Simplicity Studio的Project Configurator中勾选所需组件：Zigbee选择Zigbee Stack与Zigbee Cluster Library；Thread选择OpenThread并配置Thread Border Router；BLE选择Bluetooth Stack与GATT Configurator；Matter选择Matter组件并指定底层为Thread或Wi-Fi。多协议并发时，需在Radio Configurator中配置时分复用或双射频，并注意RAM/Flash占用。
四、SDK组件配置示例
以EFR32MG24搭建“Zigbee + BLE + Matter桥接”网关为例，典型组件配置如下：
Project: Zigbee_BLE_Matter_Gateway
Target: EFR32MG24B310F1536IM48
Components:
- Zigbee Stack (Coordinator)
- Zigbee Cluster Library (HA profile)
- Bluetooth Stack (Peripheral + Central)
- Matter (Bridge, Thread transport)
- OpenThread (FTD, Border Router)
- NVM3 (非易失存储)
- RAIL (Radio Abstraction)
- FreeRTOS (多任务调度)
Radio: 2.4GHz, 802.15.4 + BLE 时分复用
配置完成后，先编译并烧录，再用Simplicity Studio的Network Analyzer抓包，确认Zigbee入网、BLE广播和Thread边界路由均正常。若出现射频冲突，可调整RAIL的时隙优先级，或把BLE广播间隔从100ms放宽到500ms，降低对802.15.4的抢占。
五、选型决策表
| 协议 | 频段/速率 | 网络结构 | 典型网关角色 | SDK组件 |
|---|---|---|---|---|
| 802.15.4 | 2.4GHz / 250kbps | 星型或自定义 | 私有协议承载 | RAIL + 802.15.4 MAC |
| Zigbee | 2.4GHz / 250kbps | 网状 | 协调器/网关 | Zigbee Stack + ZCL |
| Thread | 2.4GHz / 250kbps | 网状/IPv6 | 边界路由器 | OpenThread + Border Router |
| BLE | 2.4GHz / 1-2Mbps | 星型/Mesh | 配网/近场 | Bluetooth Stack + GATT |
| Z-Wave | Sub-1GHz / 100kbps | 网状 | 专用网关 | Z-Wave SDK（需专用芯片） |
| Wi-SUN | Sub-1GHz / 50-300kbps | 大规模网状 | 户外汇聚网关 | Wi-SUN Stack |
| Matter | 承载于Thread/Wi-Fi | Fabric | 桥接/控制器 | Matter + Thread/Wi-Fi |
实际项目中，网关往往不是单一协议，而是“主协议+配网协议+上行协议”的组合。例如Zigbee网关常用BLE做配网、Wi-Fi或以太网做上行；Thread网关则用BLE配网、Matter做应用层统一。理解各协议在分层模型中的位置，再结合GSDK组件化配置，就能在资源、生态和成本之间找到平衡点。