利用协议分析工具对蓝牙设备进行协同性测试

蓝牙作为一项短距离无线通信与电缆替代技术全球标准，目前已得到业界广泛接受，蓝牙产品的数量正在不断增多，此时其测试重点已从是否遵守标准规范转为与新设备或现有设备之间的协同关系。蓝牙从本质上说是一套需要多层多线程协议堆栈来实现的高度结构化规范，其实际技术和操作细节均由开发人员完成，蓝牙设计、开发和调试给开发人员提出了特有的协同性问题。本文介绍利用协议分析工具对蓝牙设备进行协同性测试。

虽然遵守蓝牙规范可以确保某一装置能作为蓝牙设备正常工作，但它并不能保证该产品可以和其它相关产品协调运行。举例来说，一个厂家生产的蓝牙耳机除了要测试看是否满足耳机规范要求外，它还必须针对市场上所有支持蓝牙技术的手机进行测试以确保兼容性，另一方面，以后出产的手机也应该针对已有的耳机做测试。

这种“真实条件”下的功能测试就是协同性测试，通常使用协议分析仪集中进行，称为“Un-plugfests”。协同性测试可在制造厂商的设计实验室、蓝牙认证测试机构(BQTF)和蓝牙认证组织(BQB)中进行。

观测与控制

了解关于堆栈每层活动的信息之后，就可以采用基于无线频率(RF)的蓝牙协议分析仪控制和观测蓝牙产品。如果没有RF探测器，开发人员只能利用虚拟的软件模拟器或通过主机控制接口(HCI)在被测设备上观测协议堆栈的运行情况，但有两个原因使得这样做并不实际：

1． HCI测试无法通过物理层显示出“空中”正在发生的事情，而所有蓝牙装置最终都必须通过物理层进行通信。

2． HCI测试不能直观地显示各层上下正在发生的情况，这样就不能为开发人员提供他们需要的信息。

为克服这些局限，开发人员可以使用空中探测器通过“蓝牙无线通信”进入和监控被测系统(如图1)，这也是产品完成后所有蓝牙通信都遵循的路径。蓝牙无线通信和基带反映了设备每一个细节活动，从寻呼、查询扫描到设备之间所有高层信息包交换。空中探测器通过在基带层面上收集数据，可提供丰富的有关蓝牙设备实际表现的所有信息。

我们可以将空中探测器和用直升机观察交通堵塞作个类比。如果你开车遇到一个五公里长的交通阻塞，你只能猜测塞车的原因；但如果使用直升机，就可以鸟瞰到整个塞车的情况和起因。空中探测器就是你观察蓝牙协议堆栈的眼睛，没有这种观测角度你根本看不到造成运行错误的原因。

蓝牙序列和时序

蓝牙协议序列是一套复杂的规范，它设计用来保证可靠稳定无差错的Piconet(微微网)通信。这些序列大多是些信号交换协议，若要避免不同厂家生产的设备不相容就要精确地执行这些协议。在最好情况下，信号交换错误会产生一个事先预知的缺陷，如业务搜索超时；而最坏情况下，边界时序操作导致设备断续运行，从而表现出协同性问题。根据以往的经验，在调试排错的成本上有一个十倍递增规律，就是说一个序列错误要在试样阶段就加以排除，否则到了BQTF排错的成本将是原来的十倍，如果错误到了生产阶段才被发现，这个数字将变大到一百倍。假如没有实时空中探测及其相关的协议序列和时序数据，开发人员就不能确定时序余量，必须通过设计或做最坏余量打算以确保正确性。蓝牙协议堆栈的层数加上多线程序列的复杂性，决定了如果没有实时测量要想测试时序冲突是不可能的。因此对于序列可观测性和时序余量都很重要的场合，使用空中探测器可以很好地提供技术上的便利。

将空中探测器用作Piconet的一项可以实现对蓝牙样机的控制，另外空中探测器还是一个独立的Piconet装置，针对被测样机提供一个标准。对样机的测试能够而且应该采用多种不同的形式，包括和参考设备一起运行以及和其它相关装置的协同性测试。此外既然我们希望蓝牙设备不被其它仪器设备、科技和医疗(ISM)无线电波段覆盖掉，那么在不利的无线传播条件和拥挤的空间中保证持续稳定运行对蓝牙产品完整性非常重要。同一般专用设备不同，蓝牙设备需要针对产品在第三方进行严格测试。

事件检测

现在的蓝牙协议分析仪(BPA)都已是非常直观易用的工具。例如泰克的BPA系列包含有连接向导，可以提供直观的连接过程，使开发人员在连接分析仪的同时仍然将注意力集中在产品开发上。希望设计人员既是一个优秀的蓝牙开发者又是仪器专家这种想法是错误的，难于使用的工具已不再得到业界的认可，目前的工业标准工具供应商们也认识到了这一趋势。

下面以RFCOMM OBEX文件传输的触发和捕获为例说明BPA应用。OBEX是一个“对象交换协议”，最初作为IrDA协议开发用于红外数据交换，通过面向RFCOMM串行连接协议映射到蓝牙，实现无线交换数据对象如文本、图像或名片文件的传输与同步。RFCOMM和OBEX协议以及蓝牙无线电、基带和链接管理器等都被认为是稳定可靠的。

要想避免互用性问题，蓝牙所特有的逻辑链接控制和适配协议(L2CAP)以及业务搜寻协议(SDP)需要仔细关注。L2CAP信号是一个基于规则的序列协议集，它处理来自接口层的请求并为多路复用的应用程序分配通讯信道标示符(CID)；另外“Flush Timeout”命令以毫秒精度控制设备传送一个L2CAP数据包的时间长短，这里序列和时序都是关键的协议测量项目。当L2CAP链接安排好后，业务搜寻协议就会通过一个“通用唯一标示符(UUID)”数据库向客户提供服务器所能提供服务的详细信息。业务搜寻协议是蓝牙协议堆栈的核心部分，它用独特的PAN将蓝牙从静态网络中分离出来，但如果业务搜寻协议无法找到一个有效的UUID，链接就会断开。没有BPA的空中探测是无法检测实时业务搜寻协议失效的，图2是一个解码业务搜寻协议序列。

标准的Windows BPA界面使开发人员能够观察协议堆栈的任何层，并使用专用菜单按钮选择触发向导(图3)。在这里，BPA被设置为由“异步设置非平衡模式(SABM)”数据包序列触发。SABM数据包是RFCOMM用来激活链接的低层命令数据包，图4显示了触发点和随后的数据包细节，注意所显示的触发前和触发后的信息。

图5的报时信号给出了允许协议序列错误检测的相对时序数据，开发人员通常都知道，更多的数据并不意味着更多的信息，事实上太多数据反而会妨碍调试过程。需要检测的是事件，BPA的数据筛选器、触发函数和时间标记可将它们转化为有用信息。

疲劳测试

蓝牙开发会有一些隐藏的成本，通常是由于软件栈的实现造成的，如果要在测试和开发后期不出现互用性问题，软件栈必须完全符合蓝牙规范。开发人员必须在每个堆栈接口上实现事先定义好的事件驱动接口，并提供根据协议规范支持自动错误检测和校正的通信链接。最后开发人员还需要对他们的设备进行应力测试，这种测试能使开发人员在产品送交做常规蓝牙测试之前，对产品保持一定的信心。数据包错误生成功能可让开发人员有意将错误引入数据包，并在Piconet模式下对设计进行疲劳测试。

图6显示了BPA错误生成对话框，利用它可对BPA进行配置，发送带有预存错误的数据包或数据包序列。其特性如下：

* 可创建四个序列，每个包含四个数据包模式。

* 在一个序列中可使用基带、LMP、L2CAP、RFCOMM和SDP层数据包模式。

* 预定义的错误包括数据包报头或有效载荷中的单比特、双比特和三比特错误，也可创建自定义错误。

数据包每个错误都会由“触发器错误”(Trigger Error)函数记录在一个文件中由BPA显示出来(图7)，可从触发视图进入蓝牙堆栈的每一层追踪错误数据包，该视图使开发人员很容易确认每个错误发送的次数和错误序列。因为错误是在基带中产生的，所以记录文件中有效载荷数据与其预定义错误值一同显示。

图8是带有错误生成功能的记录文件基带视图，有错误的数据包以蓝色突出显示出来。主设备发送出一个错误后，从设备发送一个错误消息作为响应，一旦满足错误确认条件，正确的数据包将被重新发送。注意BPA触发视图(图7)显示的数据包索引号与图8中BPA基带视图中显示的索引号，二者匹配时我们就可以跟踪到这个序列，这样可通过协议堆栈的每一层快速跟踪错误数据包。BPA错误生成函数可被用来对设计进行应力测试，以及接收到错误数据包时验证对错误的正确响应和恢复序列。

本文结论

将蓝牙设计迅速推向市场是一项极具挑战性的工作，这当中有一些特殊的开发难题，如果对设备之间的实际互用性没有清楚的了解，开发人员将无法有效开展工作。另外蓝牙序列是基于严格规范的通讯协议，要避免操作互用性问题就必须在真实条件下进行测试。蓝牙产品面向的消费者不是技术专家，互用性很快将成为蓝牙开发的一个最重要特性。

作者：

Geoff Lawday博士

白金汉郡奇尔特恩斯大学学院

Email: geoffrey.lawday@bcuc.ac.uk