采用CQDDR方案提高蓝牙设备抗干扰性能

在噪声环境中，蓝牙设备通信性能将大大降低。本文介绍的CQDDR方案可以实时监测通信信道质量，并根据信道质量在DM和DH数据包以及不同的包长度之间做出恰当的选择，在噪声环境下提高通信可靠性，在正常条件下提高数据通信效率。

随着无线技术在全球的广泛使用，通信信道变得更为拥挤而且容易受干扰。在ISM频段内，由于有许多特殊的通信设备在工作，这些干扰会更明显。就蓝牙设备而言，这种干扰可能来自其它蓝牙设备和WLAN网络设备等。

产生干扰的另一个更重要的原因是用户在使用无线产品时总希望挑战其性能极限。如果一个正常工作距离为10米的2类蓝牙设备的极限工作距离可达50米，那么用户肯定希望它能在50米的距离内正常工作。但是由于现实生活中存在各种干扰，要在实际环境中实现这种极限通信对设计工程师具有很大挑战性。

目前，除了蓝牙标准中使用的各种检错和纠错技术外，还有一个根据信道质量来确定数据速率(CQDDR)的方案可用于解决这种干扰问题。该技术对远距离和干扰条件下的通信非常有效，可作为一种标准专用优化技术来降低干扰对蓝牙设备的影响。

蓝牙标准采取了很多措施来保证数据的完整性，其中一种是跳频技术。即每个数据包都以不同的频率传送，同时配有快速检错(数据包头和有效载荷均有检错码)和应答，如果有必要还可以重传。如果数据包没有正确接收，则检错失败，不发送应答信号，该数据包会在下一个可用时隙内重新发送。在蓝牙方案中，数据包不但有检错功能，还包含了纠错功能，但需要牺牲一定带宽。

蓝牙通信中有两种数据包类型，分别是DH(高数据率)和DM(中等数据率)。两者均有三种等级，分别为单时隙、3倍时隙和5倍时隙，每个DM或DH数据包后标有相应的数字，用来指示该数据包的长度。DH中的“H”代表高带宽，指的是数据包中能够携带最多有效载荷。DH5容量为339字节，采用DH5的蓝牙方案的数据率可达723kbps。但DH5也有缺点，只要接收的DH数据包中有一位误码，整个数据包就必须重传。DM数据包支持中等数据带宽，它与同等级的DH数据包的数据长度相同，但DM数据包的有效载荷中有三分之一都被前向纠错码(FEC)占用了。每10位的数据后面都加有5位的前向纠错码，可以在15位的数据/FEC时钟内最多纠正两位的误码。最高有效载荷的DM数据包最多可包含224字节数据，允许的最大带宽为477.8kbps。

数据包类型与误码率

误码使各种蓝牙数据包所提供的载荷保护机制失效的概率有多大？数据包类型和在空中传输时的误码率是其中两个需要考虑的因素。图1给出了二者之间的关系，其中上面的虚线表示误码率为10^-13，下面的虚线表示误码率为10^-9。由该图可以看出，受FEC保护的DM数据包具有很好的鲁棒性。随着BER的增加，不同数据包长度所对应的曲线在1G字节附近出现分叉。

然而，如果数据链路的BER低于10^-9，那么人们就会认为这个链路很不可靠。因此，由于数据包的长度不同而造成的可靠性差异实际上与链路没有太大关系。人们更感兴趣的是DH数据包和DM数据包在可靠性上的差别。

如果要求数据完整性很高，那么就应采用DM数据包。另一方面，如果10^-9的误码率能够满足性能需要，那么在BER低于0.02%时可以采用DH数据包，并能提供最高的带宽。但如果BER高于这个等级，那么就要采用DM数据包才能保证可满足数据完整性要求。实际上，采用DM数据包可能反而比采用DH数据包提供的带宽更高。

在一个一般的BER环境中，很多数据包都可能受干扰影响。DH数据包只能通过重传来恢复数据，但带宽浪费太大，而采用DM数据包可以通过采用FEC来纠正受干扰的数据，不需要重传。因此，尽管DM数据包支持的带宽只有DH数据包的三分之二，但其抗干扰性却比DH数据包好很多。

BER、数据包类型和有效带宽之间的关系如图2所示。从图中可看出，DH数据包的有效带宽事实上并不如DM数据包高。当BER为0.04%时，DH5数据包只能提供200kbps的带宽，而DM5却能提供超过450kbps的带宽。如果BER低于0.02%，则DM数据包的有效带宽超过DH数据包，而DH数据包能提供的数据完整性则低于10^-9。

因此，在基带时正确选择数据包类型不但有利于保持最大带宽，而且可提供有效的链路。由于数据完整性和有效带宽这两个标准的临界BER相同，因此提高其中一者的时候不会牺牲另一者。

突发噪声干扰

前面的讨论均假设背景噪声是均匀的，没有考虑在某个短时段内的突发噪声干扰。突发噪声可能由开关电弧和其它蓝牙设备或采用802.11b协议的设备在以同一频率发送信号所引起。对突发噪声干扰进行建模比对均匀噪声建模更困难，因为突发噪声可能有很多种类型，而且也不能知道这类噪声会在哪个时间段发生。对于突发噪声，需要注意以下几点：

1. 对DH数据包而言，即使突发噪声只影响到载荷中的一个数据位，整个数据包也必须重发；而对DM数据包而言，只有在突发噪声影响15位数据/FEC模块中的3个有效载荷位或者更多时才会重发。2. 非有效载荷部分(如数据包头)对突发噪声的容错能力比有效载荷部分要高，但对于数据包头而言，其最大容错能力也只是数据包头FEC的三分之一。因此，DM数据包对突发噪声的容错能力比DH数据包要强一些，但差别并不大。比如，一次开关放电可能延续3微秒以上，而在ISM频段中，某信息与其它信息产生的冲突可能持续整整一个数据包的传输过程。除了最轻微的突发噪声外，所有其它突发噪声对DM或DH数据包的干扰都一样，因此选择DM和DH数据包并无太大区别。

自然突发噪声一般不会持续太久，因而它对整个带宽的平均影响并不大。如果16位或超过16位接收数据都受到了噪声干扰，那么DH数据包成功发送16位CRC检测信号的概率就是2^-16。而DM数据包中存在FEC部分，因而很难预测。根据经验，如果在每个15位的FEC中有三分之二都受到了噪声干扰，那么在数据包中出现不可纠正错误并导致数据包拒收的概率为50%。因此，在只有均匀噪声的情况下，如果我们最关注的是数据完整性，那么就应该选择DM数据包。

大多数蓝牙芯片组都支持所有的数据包类型，但蓝牙设备在建立链接的时候，可以限定链接所采用的数据包类型。有些应用选择DM型数据包，但大部分情况下都应该允许DH和DM数据包同时可用。具体的选择由底层的基带部分和决策算法部分决定，其中决策算法部分由特定的芯片组实现。好的算法可将平均误码率降低几个数量级，而采用差的算法时，当切换到有FEC保护的数据包时出现链接超时的问题。

简单的蓝牙芯片组方案仅仅根据待发送的字节数来决定采用哪种数据包类型，即如果待发送字节能够填满一个DH5数据包，那么就选择DH5数据包。这种方法在实验室中使用还不错，但正如前面所分析，在实际应用时其效果可能很糟糕。

CQDDR方案根据需要选择合适的数据包

为了保证用户在使用时的良好效果，蓝牙方案在选择数据包类型时不仅要看等待发送的数据有多少，还应该考虑各种可能导致出错的因素。CQDDR在蓝牙方案中就是起到这样的作用。

采用CQDDR方案允许接收设备与发送设备协商，根据所处的环境改变数据包类型，从而解决长距离通信和干扰问题。例如，如果通信的一方发现接收到的数据包错误过多，它就会通知另一方采用DM数据包。在本次链接完成后，又允许另一方重新采用DH数据包。

例如，在大功率1类设备与小功率2类设备链接时，由于它们之间的数据传输已达到2类设备的极限距离，因此1类设备在接收由2类设备发出的数据时较为困难，此时它会通知2类设备采用DM数据包。另一方面，2类设备从1类设备所接收到的信号足够强，因此对它而言DH数据包是最佳选择。

在蓝牙标准的应用中主要的困难是如何测量BER并产生恰当的数据包类型请求。如图1和图2所示，DH数据包和DM数据包曲线的交叉点大约出现在0.02%BER处。要以0.02%的误码率来判断选择用哪种数据包，就要求将误码数平摊到多个数据包上来计算误码率，这本身就会造成问题。对DH数据包来说，还有另一个问题：如果CRC校验失败，如何判断有多少位数据出错？不过，我们还可以根据数据包头中的误码率来大致估计BER。

CQDDR允许独立选择DM或DH数据包类型以及数据包长度。根据以上分析，数据包的长度似乎对数据完整性影响不大。所以考虑到带宽效率，最好将数据包长度留给基带部分来决定，CQDDR只用于选择DM或DH数据包类型。

根据蓝牙网站上的资格认证信息显示，目前只有两家公司采用过CQDDR。因此，带有CQDDR功能的芯片不一定能获得远程设备的支持，根据这种情况，CSR公司开发出一种算法，该算法着眼于唯一可用的信息：ACK(应答数据包)与NACK(非应答数据包)的比例，并根据这一信息估计链接的性能，然后对发送数据包的类型进行修改。但这种方法对已经入站的信息流无法进行任何操作。

该算法很简单，但效率很高，特别是对于一个已经采用了DH数据包而且干扰越来越大的链接时，如果该链接继续采用DH数据包而不使用这种算法，最终BER会增大到使DH5数据包无法传输。

本文小结

由于目前芯片组对CQDDR的支持并不是很多，建议产品开发商首先要了解问题所在，并清楚CQDDR的作用。然后仔细研究基带机制，弄清其数据包类型选择算法及所有用于优化带宽的专有技术。

对于正在研究中的项目来说，在应用级提供一定程度的带宽保护是可能的，但这样会延长开发时间。我们可以通过一些主控制器接口(HCI)级指令来获得相关链接质量信息，但开发商必须认识到该信息并非确实的数据，而是从0到255的一系列等级数(等级数越小则链接质量越差)，而且这一等级数也取决于该研发芯片所用的基带机制。

随着越来越多的芯片组日趋成熟，这些芯片组将包含CQDDR和可靠的BER测量方案。应用开发商可以不必选择数据包类型，而将这一的任务的具体细节交给基带部分来完成，并且对任何芯片组厂商的产品都适用。

作者：David McCall

高级应用工程师

CSR公司

Email: david.mccall@csr.com