蓝牙和WIFI共存设计

蓝牙和802.11b/g/n都可能工作在2.4G ISM频段，可能相互干扰。干扰的典型应用之一是VOIP，用手机的WLAN打VOIP电话，用蓝牙耳机来通话。互相干扰的后果就是用户能够感觉到通话质量的下降。

设计上有些方法能够减少相互干扰，尽量维持蓝牙和wifi的throughput，使得用户的使用体验不受应i选哪个。 方法主要是AFH和分时。

1. 是否存在相互干扰和相互干扰是否严重受以下因素影响:

1.1 共用天线还是单独用自己的天线

如果蓝牙和wifi使用单独的天线，蓝牙天线和wifi天线之间的隔离大小会影响干扰的程度。如果认为有一定的隔离度，蓝牙和wifi是可以同时发射或者接收的。

如果蓝牙和wifi共用天线，蓝牙和wifi不可以同时工作。（如果不考虑相互干扰，可以同时接受）

1.2. 干扰是噪声还是阻塞

干扰分为两种。一种是噪音，主要发生在频率冲突时；另一种是大信号阻塞，和频率是否冲突没有关系，和具体射频设计以及天线间的隔离有关系。

1.3. 蓝牙通信频率是否落在wifi带内

如果蓝牙通信频率落在wifi频带内，噪音干扰和阻塞干扰都会有。如果蓝牙通信频率落在wifi频带外，只有阻塞干扰。

AFH是针对噪音干扰最好的方法，蓝牙和wifi的性能都能维持100%。唯一问题是无法解决阻塞干扰。

1.4. 蓝牙和wifi是接收还是发射

假设蓝牙和wifi使用自己单独的天线，蓝牙和wifi是能够同时发射和同时接收的。如果一个发射、一个接收，在频率冲突时会有相互干扰。另外，同时发射可能会对另一侧设备带来干扰。

1.5 蓝牙和wifi的具体应用的通信特点

共存时相互干扰是否严重还和具体应用时的通信特点有关。比如数据量是否大，是否是数据流，是否是time critical的。所以有的设计是host可以根据不同应用配置不同的优先级，以达到最好的平衡。

2. 主要设计方法简单介绍

2.1 AFH

AFH是解决噪音的最好方法。通过在调频频率中避开wifi的频带，既可以避免频率冲突带来的干扰，也丝毫不损失蓝牙和wifi的性能。另外，AFH不只针对wifi干扰，道理上其他干扰源也可以避开。

AFH功能包括两个方面，一是channel的好坏区分；二是使用新的channellist调频。

Channel的好坏区分有三种来源：

• 自己通过scanRSSI或检测PER等方式区分channel;
• 通过令侧设备的区分信息，如master取slave的区分结果；或slave依照master的区分结果；
• 依靠host通过HCI命令set_AFH_host_channel_classification传下来。

蓝牙和wifi共存设计中，host通过HCI命令告诉蓝牙哪些channel不可用是很有效的。如果蓝牙自己区分，应该既自己检查channel，也需要读另侧设备的区分信息，因为两者如果距离稍远，可能看见的bad channel是不同的。

2.2 分时

分时是利用蓝牙和wifi间的握手信号，使蓝牙和wifi分时在2.4G工作，这样可以避免噪音干扰和阻塞干扰。问题是会降低蓝牙和wifi的throughput。所以这个机制应该只在AFH不能提供良好效果时使用。

802.15.2中有规定仲裁方式和信号(PTA, packet traffic arbitration)的框架，很多蓝牙芯片厂商也有自己专有的握手信号定义。道理上来讲我们的设计还需要了解主流wifi芯片的握手信号定义。

这些握手信号都差不多。简单说明如下：

2.2.1 2-wire

Wifi给蓝牙信号wl_active，表示wifi有通信，如果这个信号asserted，蓝牙应该只接收/发射highpriority的包，其它包delay。
　　蓝牙给wifi信号bt_priority，表示蓝牙要发highpriority的包，wifi必须停止当前通信。
　　可以看出，这两根信号分别是保护wifi和蓝牙通信的。所以assert的多与少会影响2.4G带宽在两者间的分配。
　　从蓝牙芯片设计的角度，蓝牙芯片必须支持对于包优先级的区分和delay包的处理。一般来说，定时同步，inquiry，page，SCO等是高优先级，传送数据的包则是普通优先级。如果处理得细致和灵活，很多参数是需要可以配置和可调的，因为可能需要host根据具体应用来配置。
　　如果蓝牙芯片知道wifi的频带，bt_priority也可以只在频率冲突时拉起。

2.2.2 3－wire

　　三线方案和两线方案相似。多加一根蓝牙输出的bt_active，这样和bt_priority一起可以表示两种优先级的蓝牙通信。

2.2.3 4－wire

　　四线方案和三线方案相似，再多加一根蓝牙输出的bt_freq，指示蓝牙通信是否和wifi频带冲突。

2.2.4 PTA

　　802.15.2中没有规定PTA具体的硬件接口和仲裁判定，是依赖实现的。也有类似上述的2/3/4线方案。但PTA的基本思想是蓝牙和wifi提交申请给PTAcontroller，（一般PTAcontroller集成在wifi中），由PTAcontroller来许可。所以PTA中的相关信号都是指将要的操作，不同于上面的是指已经发生的操作。