一文让你轻松理解WLAN-Bluetooth-WWAN共存机制连载2：蓝牙-WLAN共存-CSDN博客

本文链接：https://blog.csdn.net/weixin_47877869/article/details/146063061

7. 蓝牙-WLAN共存

本节我们讲解 Bluetooth 和 WLAN 的共存组件。

7.1 基于消息的共存接口

基于消息的共存接口（MCI）用于在 WLAN 与 Bluetooth 之间进行通信。与仅支持 WLAN 和 Bluetooth 在 MAC 层进行仲裁的业界标准的三线接口相比，MCI 提供了更多信息。MCI 支持以下功能：

MAC 层仲裁
共享 LNA（低噪声放大器）控制协调
用于协调功率状态的消息
远程中断功能
从 WAN 隧道传输 WCI-2 消息
软件消息隧道

7.1.1 MAC 层仲裁

在直接 MAC 访问的场景下，当 Bluetooth 需要发起传输时，会在“执行时间（go time）”到来之前向 WLAN 发送仲裁请求。若此时无线电资源不可用，WLAN 会以 NACK 消息响应 Bluetooth。Bluetooth 仅在完成当前操作后才会再次发送仲裁请求。

基于消息的共存接口还可以选择性地追踪 Bluetooth 在正常数据传输之外的活动信息。例如，当 Bluetooth 进行低功耗（LE）扫描时，WLAN 驱动或系统可能提前得知该扫描窗口的存在。

如果无线电资源无法用于传输，则请求可能会被转发到系统中的聚合器模块。

7.1.2 功率状态协调

例如，在某种场景下，WLAN 处于工作状态时将无线电交由 Bluetooth 使用；当 WLAN 切换至休眠（doze）状态后，如果系统事件强制唤醒 WLAN，那么 WLAN 可能需要请求 Bluetooth 归还无线电资源，以便 WLAN 恢复正常工作。

如果系统设计中采用了全局电源管理器（GPM）来在无线电未被使用时设定其功率状态，那么 MCI 也可能承载帮助避免 Bluetooth 与 WLAN 相互干扰的消息。例如，当无线电因空闲而被关闭时，Bluetooth 与 WLAN 都会获知该状态并进行适当的协调，防止冲突发生。

7.1.3 远程中断

远程中断是 MCI 的一个功能，用于从 WAN 侧向 Bluetooth 和 WLAN 发送中断。例如，可以用来通知二者即将发生的状态变化或系统事件。

7.1.4 隧道传输来自 WAN 的 WCI-2 消息

如前所述，来自调制解调器的 WCI-2 消息可以封装在 MCI 中，以便 Bluetooth 或 WLAN 使用。

7.1.5 软件消息隧道

MCI 的另一个功能是传递软件消息，例如在 Bluetooth 与 WLAN 之间进行基于软件的同步或配置，用于协调硬件握手以外的信道使用或功率状态。软件消息也可以用于协调高级功能或在主机／系统中执行调试命令。

7.1.6 WAN 共存隧道

WCI-2 串行接口在物理上由 Bluetooth 子系统终止。有两个 MCI 消息用于封装 WCI-2 消息并在 WLAN 与 Bluetooth 软件模块之间进行传输。

7.1.7 系统消息

系统消息用于通知 MCI 对端，远端设备已进入或退出断电（power-collapsed）状态。即使 Bluetooth 子系统已处于断电状态，但 Bluetooth 端仍可以发送控制信息来封装并转发 WCI-2 消息，并在需要时中断远端 MCI 对端。

7.1.8 蓝牙到达角（Angle of Arrival, AoA）

AoA 会发送和接收 AoA 请求/响应消息。AoA 响应是一个标准的低功耗（LE）数据包，并在 CRC 之后附加扩展字段。某些采样/天线的组合可提供更好的定位精度。

7.2 共存软件架构框架

下图展示了共存框架构。共存管理器是一个集中式软件实体，用于汇总并解耦所有无线电共享决策。共存管理器会从 WLAN、Bluetooth 以及调制解调器获取输入，以做出资源共享方面的决策。

7.3 共存软件分解——共存管理器

下图展示了共存管理器的架构。共存系统更新时，会从系统监控模块获取输入，系统监控模块会持续监控 RSSI、所使用的接收物理层速率以及流量情况。当无线电状态发生变化时，共存系统还会从 WLAN、Bluetooth和调制解调器模块获取输入。基于所有这些输入，最终由共存管理器来决定在特定组合场景下使用哪种流量整形方案。

7.4 共存软件分解——共存系统更新

下图展示了共存系统更新的架构。在流量管理算法中会选择共存策略。因此，共存系统更新流程会针对 WLAN 虚拟设备（VDEV）以及 Bluetooth 链路优先级或阈值进行相应的调整。

7.5 共存软件分解——共存调度器

下图展示了共存调度器的体系结构。基于共存策略，Bluetooth 与 WLAN 的时间分配和间隔会随着 WLAN 权重的调整在共存调度软件例程中被确定。

7.6 Bluetooth-WLAN 共存策略

本节列出了 Bluetooth 和 WLAN 的共存策略。

7.6.1 自由运行（Free-run）策略

WLAN 和 Bluetooth 并行运行，而不实施 WLAN 流量整形。硬件仲裁适用于在 WLAN 与 Bluetooth 之间进行时间共享。

WLAN 和 Bluetooth 会根据动态调整的优先级相互“踩踏”。共存软件会监控 Bluetooth 带宽使用和 WLAN 吞吐量变化，并基于这些因素来调整优先级，以允许 WLAN“踩踏”Bluetooth 或 Bluetooth“踩踏”WLAN。此策略通常用于短时突发的 Bluetooth 流量场景，例如 xSCO/HID/BLE。

该策略的优点如下：

在软件控制较少的情况下最大化天线使用。
在少数可预期的场景中可获得峰值吞吐量。

该策略的缺点：

对于某些不遵循标准的 AP，吞吐量可能不一致且不稳定。

7.6.2 静态 OCS 策略（Static OCS policy）

离线通道调度器（OCS）为 Bluetooth 和 WLAN 的交错运行提供时间切片。WLAN 流量整形由 WLAN 流量端执行，并在 Bluetooth 时段内进行。

在 WLAN 时段，普通 Bluetooth 流量会被“踩踏”，但关键的 Bluetooth 流量可“踩踏”WLAN 流量。该策略适用于长时突发的 Bluetooth 流量场景，例如 A2DP 和 OPP 配置文件。

该策略的优点在于可以对 WLAN 流量进行整形，同时在某些情况下可实现与自由运行（Free-run）策略相近的峰值吞吐量，但需要更复杂的软件控制来实现。

7.6.3 动态 OCS 策略

动态 OCS 提供了类似于静态 OCS 策略的 Bluetooth 和 WLAN 交错之间的时间切片。

在 WLAN 时段，除 Bluetooth 扫描之外，不允许任何 Bluetooth 流量。

在 Bluetooth 时段，Bluetooth 会刷新其传输队列中的数据，发送这些数据，然后转换到下一个数据包。

在另一个时段之后，它会将 Bluetooth 的所有数据一次性刷新到 WLAN。

当满足以下任一条件时，将触发从 Bluetooth 到 WLAN 的转换：

蓝牙数据传输队列中有 ≥ x 个数据包（其中 x=4）
自上次蓝牙数据包传输以来 ≥ y 毫秒（其中 y=60）
自队列中第一个蓝牙数据包排队以来 ≥ y 毫秒

该算法在使用 Bluetooth A2DP 配置文件时使用。该策略在硬件方面的特性如下：

硬件能够停止或恢复已排队或已授予的 Bluetooth QoS 的传输流。
硬件能够刷新或钳制整个流量。

该策略需要来自主机系统的驱动程序，该驱动程序是符合要求的软件控制。

它需要在指定的精确区域中配备 Bluetooth 和 WLAN 的集中调度器实例。

7.6.4 固定时间策略

固定时间与 CTS2S：将时间分割为 Bluetooth 时段和 WLAN 时段间隔。默认间隔是 20ms。

例如，前 20ms 仅用于 Bluetooth 流量，使用 CTS2S 来传输流量；然后接下来的 20ms 仅用于 WLAN 流量；再接下来的 20ms 又用于 Bluetooth 流量。

这用于 UART 调试、密钥交换和 DHCP 阶段。

它在 WLAN 连接过程中使用。在此过程中，Bluetooth 流量会被中断，来自 Bluetooth 的冲突流量被暂时禁用或被强制暂停其流，以允许最大的 WLAN 发送流量。

它用于 DHCP、密钥交换以及 DHCP 阶段。

以下为该政策的优点：

固定时间可为重要的 WLAN Rx 流量提供可靠的保护。
在 WLAN Tx 流量与 Bluetooth 之间实现最大化天线使用率。
在某些情况下可实现较高的 WLAN Tx 吞吐量峰值。

该政策的缺点如下：

在某些特定的接入点 (AP) 上会出现 WLAN Tx 吞吐量不一致且不稳定的现象，并且需要复杂的软件控制。

Fixed-time without CTS2S：

时间被切分为 Bluetooth 周期与 WLAN 周期交替进行。WLAN 会顺序切换硬件权重，以优先考虑 WLAN 或 Bluetooth。
在 Bluetooth 周期内，与其冲突的 WLAN Tx 流量会被 Bluetooth 流量“踩掉”。
在 WLAN 周期内，与其冲突的 Bluetooth 流量会被“踩掉”。由于没有 Rx 流量保护，WLAN 和 Bluetooth 的 Rx 始终处于开启状态。
当运行 Bluetooth A2DP 从设备配置文件时会使用该模式。
在某些场景下可以实现 WLAN 吞吐量的提升。但与 CTS2S 策略类似，在某些特定 AP 上，WLAN Tx 吞吐量仍会出现不一致且不稳定的现象。此外，在蓝牙 Tx 流量较重的情况下，某些 AP 也可能出现 WLAN Rx 速率下降的情况。

PS-POLL：PS-POLL 可用于 STA 和 P2P-GO，但不适用于 SAP/P2P-GO/IBSS。PS-POLL 会在设备（station）未唤醒时发送，用于获取数据帧。例如，在短空闲时隙（short idle slot）的同步蓝牙流量场景中会使用 xSCO。示例：xSCO。

一致且稳定的下行吞吐量是该策略的优点之一，并且在设置后不会影响同一信道上其他设备（类似 CTS2S 的效果）。

然而，PS-POLL 的开销相当可观。要使用 PS-POLL，必须禁用下行聚合，这会导致下行吞吐量下降。此外，复杂的软件配置也是该策略的一个缺点。

CTS2S：CTS2S 适用于 SAP/P2P-GO 和 IBSS。CTS2S 帧被发送以保护 Bluetooth 时段。该模式用于短空闲时隙的同步 Bluetooth 流量场景，例如 xSCO 配置文件。

当启用 CTS2S 时，同一信道上的所有设备都会受到流控。由于流控开销较小，因此可期望获得较高的下行吞吐量，并且实现起来也相对容易。

但其缺点在于，可能会为同一信道上附近并非预期的设备进行保留。CTS2S 的传输可能失败或延迟，从而导致流控失效。