多协议蓝牙和Zigbee怎样连接更多的设备

多协议连接提供了一种独特的方法来添加消费者和企业所要求的功能。为了在家庭或楼宇自动化场景中提供必要的可扩展性和稳定性，通过网状网络进行设备间通信是一种理想的实现方式。同时，能够直接从智能手机设置、控制或监视单个设备或一组设备的功能也是一种简化消费者体验并向技术人员提供更多即时诊断信息以辅助安装的特性需求。

增值服务可以通过连接的设备（例如灯）进行交付，例如在零售环境中提供基于接近感知的广告，为技术人员传输系统健康信息以及跟踪仓库中的资产。同时，人们希望参与多个生态系统，无论是Alexa、Apple HomeKit还是Google Home，每个生态系统都有各自的协议或集成要求。通过在单个设备上支持多协议，我们可以满足我们刚刚讨论过的许多需求。

目录

通过多种无线方式提供新体验

寻找一种经济有效的方式来支持多协议

在单个无线电上同时执行多协议

在单个无线电进行Zigbee和蓝牙 *** 作的调度要求

评估动态多协议性能

设计具有多协议连接的系统

通过多种无线协议提供新体验

让我们研究一下如何使用支持多协议的设备来改善家庭自动化场景中的体验。Zigbee通过其网状网络功能提供整个家庭的覆盖范围，并且可以通过网关从家庭外部进行控制。但是，有了多协议支持，我们可以进一步扩展使用场景，用具有低功耗蓝牙的电话进行本地控制和位置感知。

通过同时支持蓝牙和Zigbee连接，门锁在接收到蓝牙通信后便会解锁，同时能够发送Zigbee消息以打开客厅灯。当将智能手机带入卧室时，使用接近感应服务（例如蓝牙信标），灯可以发送蓝牙信标消息，允许消费者打开房间中的全部或部分灯。

在零售或商业环境中，希望利用诸如蓝牙信标之类的技术来提供基于位置的广告、跟踪资产，以及去开发人流的热图（heat map）。大规模采用的挑战之一是需要专用的信标设备。对于设备生命周期管理，连接范围也会影响更新设备的统筹安排。

通过将蓝牙信标集成到其他连接的基础设施（例如照明）中，我们可以建立大规模且密集的信标覆盖区域。不必同时部署连接灯和信标，连接的灯或灯具也可以用作蓝牙信标。与部署单独的专用信标设备相比，这可以提供一种更具成本效益的方式来提高信标密度，并且具有无需监视和维护必须由电池供电的信标设备的额外优势。

用多功能灯提高信标密度

多协议还使其他使用案例成为可能。例如，无线更新可能会在网状网络上花费很长时间，但是蓝牙的更高吞吐量可以在不消耗网状网络带宽的情况下提供更新固件映像的更快传输。

用多功能灯提高信标密度

寻找一种经济有效的方式来支持多协议

在支持多协议的情况下提供这些改进的体验所面临的挑战之一是要求拥有多个芯片或SoC，每种协议一个。然而，使用多协议芯片，设备现在可以灵活地运行不同的协议。下表描述了多协议设备的一些常见示例。

无线多协议方案

来自像Silicon Labs这样的公司的单芯片解决方案结合了软件和硬件方面的先进技术，使设备既支持Zigbee也支持蓝牙，从而满足目前为止讨论的使用案例需求。相对于两个无线电，通过使用一个SoC无线子系统，可以将BoM成本降低40%，并且通过消除设计中两个无线电之间可能存在的干扰，还可以简化PCB设计。

在单个无线电上同时执行多协议

让我们更详细地研究动态多协议调度如何通过单个无线电支持多协议。当不发送信号时，Zigbee路由器始终将其无线电设为接收模式。这样一来，网络中的其他设备就可以始终向其发送数据包或通过它路由。由于Zigbee流量的低占空比和Zigbee网络协议栈中的重传机制，Zigbee路由器可以在短时间内将其无线电更改为另一个协议，而不会在应用层级上丢弃任何消息。这使得我们可以在同一芯片上对Zigbee和蓝牙通信进行时间切片。除Zigbee路由外，Silicon Labs动态多协议技术还支持蓝牙连接和蓝牙信标。

协议连接间隔可以基于应用需求而配置。对于蓝牙信标，无线电只需要大约1ms即可发送信标，并且信标之间的连接间隔通常不小于100ms。对于高速OTA固件更新，可能需要将设备配置为支持更长的蓝牙连接时间。这些例子面对的应用场景相反。但是，通过可配置的连接间隔，Silicon Labs多协议解决方案提供了灵活的框架，可以满足不同应用的独特需求。

为了实现有效的多协议通信，Silicon Labs已经在软件和硬件上进行了大量投资。Silicon Labs无线协议栈经过专门设计，可以共享相同的低级别的无线电驱动程序和库（RAIL）。利用RAIL可确保使用一致的API和接口来共享无线电。

另外，无线电调度器管理来自协议的请求以访问无线电，而Micrium OS内核管理协议栈之间的资源共享。

Silicon Labs多协议调度考虑了要调度的协议，并使用基于优先级的调度方法。蓝牙需要固定的连接间隔才能有效运行，而采用MAC重传方法的Zigbee更加宽容。因此，对于Zigbee和蓝牙多协议 *** 作，蓝牙以更高的优先级运行。由于使用RAIL、无线电调度器和Micrium OS的无线协议栈具有统一的体系结构，该系统能够使用基于优先级的调度方法来平衡Zigbee和蓝牙 *** 作。

在单个无线电上进行Zigbee和蓝牙 *** 作的调度要求

许多调度方案可能都要求使用单个无线电实现Zigbee和蓝牙的正确 *** 作。调度器可以配置成使得任一协议在无线访问方面具有更高的优先级。但是，最可能的配置是使蓝牙连接和信标具有更高的优先级，并且在不执行其他任何 *** 作时将无线电保持在Zigbee接收模式。

具有优先权的Bluetooth LE和Zigbee后台接收

在上图中，我们可以看到低优先级的Zigbee接收是默认的，但是当需要Zigbee传输时，它将中断该过程。这是Zigbee设备的正常行为。当Bluetooth LE连接被调度时，采用先例，调度器要及时退出Zigbee接收模式，以用于蓝牙连接。如果调度器要求进行Zigbee传输的请求超过下一个蓝牙连接或信标发出之前无线电上可用的时间，则调度器将重新安排Zigbee传输以在蓝牙活动完成之后进行。

如果Zigbee数据包的传输时间超出了预期，可能是由于退避或清除信道评估所致，调度器可以中断该传输并切换到蓝牙。如图2所示，对于Zigbee协议栈来说，这看起来像是一次失败的尝试，因此它进行了重传，这次成功了。

蓝牙连接中断Zigbee传输

同样，如果远程Zigbee节点在处于蓝牙连接或信标中间时尝试将数据包发送到设备，则该设备将无法接收该数据包，但是发送设备将重传（IEEE 802.15.4 MAC重传），数据包将在第二次尝试时被接收。另外，如果在建立蓝牙连接或信标时设备正处于接收Zigbee数据包的中间，调度器可能会中断数据包的接收，并且发送设备将不会收到确认。因此，它将重传并在第二次尝试时被成功接收。图3显示了这两种情况。

无线电调度器必须处理各种情况，以管理无线协议之间的冲突，但是各个协议栈彼此并不会有任何察觉，只是他们必须请求访问无线电并且判断它们的发送或接收是否成功。

评估动态多协议性能

为了了解运行多协议时的设备行为，重要的是测量和比较多种配置下的性能。对于在同一SoC和单个无线电上运行Zigbee和蓝牙的情况，方案可能包括：

Zigbee吞吐量对比蓝牙连接和/或广播间隔

Zigbee延迟对比蓝牙连接和/或广播间隔

Zigbee吞吐量或延迟对比变化的蓝牙数据包类型和大小

Zigbee重试和网络行为对比变化的蓝牙连接和/或广播

动态多协议测试设置

使用图4中概述的测试设置，在Silicon Labs Wireless Gecko STK板上使用辐射测试设置执行的示例测试给出以下结果：

对于显示结果，我们使能了802.15.4 MAC和Zigbee NWK层重传，但未使能Zigbee APS层重传。该设备配置为在单个跳跃点上传输70个字节的有效负载，同时在指定的连接间隔内保持蓝牙连接并保持活动状态。随着蓝牙连接间隔的减小，由于Zigbee网络上无线电时间的减少，蓝牙连接事件的数量增加，Zigbee吞吐量降低。需要注意的是，这里获得了100%的端到端消息可靠性，并且虽然由于较长的数据传输时间导致吞吐量降低，但没有丢失Zigbee应用消息。

为了验证广播间隔的影响，设备配置为以变化的间隔传输蓝牙广播，而不是保持蓝牙连接。由于蓝牙广播数据包比蓝牙连接保持活动的数据包更长，因此在相同时间间隔内，它们对Zigbee吞吐量的影响略高。短至0.5s的广播间隔对Zigbee吞吐量几乎没有影响，应该可以满足大多数用例的需求。

设计具有多协议连接的系统

借助动态多协议硬件和软件，现在可以在一个SoC上以经济高效的方式去整合多协议的优势。通过在设备上结合Zigbee和蓝牙连接，家庭自动化、资产跟踪和零售广告可从中受益。

每个设备和应用都有独特的需求，这些需求要求对软件进行可配置性设置，例如蓝牙连接间隔。在着手开发之前，重要的是要确保基础软件和硬件体系结构被设计用于无线电的有效资源共享，并支持高级调度方案。此外，应根据特定的应用和系统用例来定义测试和性能基准，以确保在现场正确运行。

责任编辑：ct