Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/dsyx/docs.silabs.com_zh/llms.txt

Use this file to discover all available pages before exploring further.

在单一设备上实现多个无线协议，使 IoT 产品能够同时服务于不同的网络生态系统，是 Silicon Labs EFR32 平台的重要差异化能力。通过单芯片多协议，可以节省成本、减小产品体积并降低系统整体功耗。本文档介绍了四种多协议实现模式、各模式的适用场景与基础设施要求，并详细阐述 Silicon Labs Radio Scheduler 的工作原理——这是动态多协议解决方案的必要组件。

​
为什么需要多协议

在单一设备上运行多个协议，可以带来以下显著优势：

节省成本

单个设备执行多个功能，减少物料清单（BOM）中的芯片数量，降低整体产品成本。

节省空间

当多个协议共享同一无线电时，最终产品封装可以更小更简洁。

节约能源

减少网络上的设备数量，降低系统整体功耗，延长电池使用寿命。

用户体验提升

允许用户通过智能手机（Bluetooth）控制和诊断设备，同时设备保持在 Zigbee 等主协议网络中正常运行。

​
四种多协议实现模式

1

编程式（Programmable）多协议

芯片具备支持多种协议的基础设施，但在制造时仅编程一种协议运行。客户通过选择不同的应用固件，在不同协议的产品版本中复用同一颗芯片，节省零部件成本。适用场景：需要为不同市场或协议环境提供硬件兼容的产品线。
2

切换式（Switched）多协议

设备初始运行一种协议，在未来某个时间点通过 Bootloader 切换到另一种协议。两种主要用例：
  • 面向未来（Future-proofing）：制造商预留协议切换能力，以应对未来协议环境的变化。
  • 智能手机辅助 Commissioning：设备先以 Bluetooth 协议出厂，用户通过智能手机 App 完成入网配置后，再切换到 Zigbee 等目标协议，简化安装体验。
基础设施要求：足够的内存支持多协议平台、统一的无线电 API（如 RAIL）、跨协议兼容的 Bootloader。
3

动态式（Dynamic）多协议

两个协议并发运行，通过 Radio Scheduler 对无线电进行时间分片，快速切换无线电配置（如信道），使不同协议能同时可靠运行。典型场景：用户通过手机 Bluetooth 连接设备执行控制或诊断，同时设备保持 Zigbee 网络连接，路由数据包并执行 ZCL 命令。基础设施要求（额外）：
  • 支持任务切换和资源共享的 RTOS（如 Micrium OS）
  • 管理时间分片的 Radio Scheduler（详见下文）
4

并发式（Concurrent）多协议

两个协议不仅并发运行，而且共享相同的无线电信道。例如，Zigbee/Thread 双协议网关可同时管理 Zigbee 和 Thread 两个网络，通过过滤不同的 PAN ID 将传入数据包分发到相应的协议栈。约束条件：
  • 多协议设备必须控制 Zigbee 和 Thread 使用的相同 IEEE 802.15.4 信道
  • 两种网络的组合占空比不得超过单一协议设备通常能承受的上限
  • 不能同时接收两个协议的数据包（MAC 重试机制通常可弥补此限制）

​
协议选型考量

单个无线电不能同时接收或发送两种不同协议的数据包。为共享无线电，两个协议必须接受它们无法 100% 占用无线电的现实，并具备在不显著降低性能或丢失消息的情况下让出无线电的能力。

​
动态式多协议协议适配条件

协议成为动态式多协议良好候选的必要条件：

低占空比

正常操作条件下，协议不能长时间（单次超过几毫秒）独占无线电。

重试机制

具备管理传入数据包丢失的强大机制，如 MAC 重试，以容忍偶尔的无线电切换中断。

短数据包

数据包和无线电占用时间极短，切换开销可忽略不计。

严格时隙或共享 PHY

实现严格的时隙/连接间隔，或与另一协议共享相同的无线电 PHY（如 IEEE 802.15.4）。

​
典型示例

动态式：Bluetooth LE + Zigbee Bluetooth LE 是 Zigbee 动态多协议的理想配对协议：
  • Bluetooth 信标（beacon）数据包极短（通常最多 30 字节），无线电仅需约 1 ms 发送
  • 信标间隔通常不小于 100 ms，占空比仅约 1%，无线电超过 99% 的时间可用于 Zigbee
  • Zigbee 低占空比流量和协议栈内置的重试机制，使路由器可以短暂让出无线电而不丢失应用层消息
并发式：Zigbee + Thread 两者均基于 IEEE 802.15.4 协议，共享相同的 MAC/PHY 和信道，无需切换无线电 PHY，仅通过过滤不同 PAN ID 区分网络流量。
当无线电需要在两种不同 PHY 之间切换时，设备在切换期间会从一个网络”消失”。若设备是某协议中嗜睡终端设备（Sleepy End Device）的父节点，当父设备”消失”时，嗜睡终端设备醒来发送消息将无法得到响应，频繁重试会显著影响其电池寿命。

​
Radio Scheduler（无线电调度器）

Radio Scheduler 是动态多协议实现的核心基础设施，负责根据各无线协议栈和应用的要求调度无线电任务。 Silicon Labs Radio Scheduler 是 RAIL 库的一部分，运行在无线电硬件之上、RAIL API 之下： 
┌─────────────────────────────────────┐
│         协议栈（Zigbee/BLE等）        │
├─────────────────────────────────────┤
│         Radio Scheduler             │
├─────────────────────────────────────┤
│         RAIL API                    │
├─────────────────────────────────────┤
│         无线电硬件（EFR32）           │
└─────────────────────────────────────┘
Micrium OS 作为 RTOS，允许协议栈和应用逻辑共享 CPU 执行时间，是动态多协议实现的软件基础。

​
核心调度概念

无线电操作是预定的特定动作，具有无线电配置和优先级属性。每个协议栈可请求三种无线电操作：
  • 后台接收（Background Receive）：持续接收，旨在被其他任务中断，作为默认监听状态
  • 预定接收（Scheduled Receive）：在未来特定时间内以最短持续时间接收
  • 预定发送（Scheduled Transmit）：在未来特定时间内以最短持续时间发送
Priority：每个协议栈的每个操作都有默认优先级，应用可以修改。调度器在裁决冲突时以优先级为依据。Slip Time（滑动时间）：若操作无法在请求的开始时间发起，Slip Time 定义了可以延迟发起的最大时长。超出 Slip Time 后，操作将被放弃。
除执行后台接收外，协议栈在完成一个操作或一个操作序列后，必须主动让出（Yield）无线电。在协议栈 Yield 之前，调度器不会安排优先级较低的任务。这一机制确保了时间分片的正确性，防止协议独占无线电。

​
抢占机制

优先级较高的任务可以中断已调度的无线电操作，以下两种情况会触发抢占：
  1. 已调度的操作花费时间超出预期，而更高优先级操作必须按时启动，且当前协议栈未主动 Yield。
  2. 一个更高优先级的操作被调度在未来发生，与已安排的低优先级操作存在时间冲突。
某些长期存在的无线电操作（如 Zigbee Commissioning、OTA 固件升级）会对产品的正确运行产生重大影响。应用可能需要在协议之间显式协调这些特殊任务。若应用未进行协调，Radio Scheduler 将按优先级强制执行，可能导致任务被提前中断。

​
多协议实现对比总结

模式协议切换方式需要 RTOS需要 Radio Scheduler典型场景
编程式（Programmable）制造时固定❌❌多市场兼容单一硬件
切换式（Switched）Bootloader 切换❌❌智能手机 Commissioning、协议迁移
动态式（Dynamic）运行时时间分片✅✅Zigbee + Bluetooth LE 并发
并发式（Concurrent）共享同一 PHY 和信道❌❌Zigbee + Thread 双网络网关
如果只是在单一协议中使用多种无线电配置（如多个频段或调制方式），无需实现多协议——Silicon Labs RAIL 和无线电配置器已原生支持同一协议中的多个无线电配置。只有在需要真正运行多种不同协议时，才应采用多协议方案。

Build docs developers (and LLMs) love

Get started for freeTalk to us