蓝牙技术研究

蓝牙技术一直以来都是研究的热门，以下是我这段时间对蓝牙技术研究心得

1蓝牙专业术语

A2DP全名是Advanced Audio Distribution Profile 蓝牙音频传输模型协定! A2DP是能够采用耳机内的芯片来堆栈数据，达到声音的高清晰度。有A2DP的耳机就是蓝牙立体声耳机。声音能达到44.1kHz，一般的耳机只能达到8kHz。如果手机支持蓝牙，只要装载A2DP协议，就能使用A2DP耳机了。

 

EDR 即Enhanced data rate，是蓝牙技术中增强速率的缩写，其特色是大大提高了蓝牙技术的数据传输速率，达到了2.1Mbps ，是目前蓝牙技术的三倍。因此除了可获得更稳定的音频流传送的更低的耗电量之外，还可充分利用带宽优势同时连接多个蓝牙设备。目前诸如多普达 710 等手机已经开始支持蓝牙EDR 技术。

 

2蓝牙通信、配对与连接

 

蓝牙通信有三种安全模式，级别最高的便是“链路级安全模式”，它要求

设备在链路建立前采用“认证”的方式进行安全保护，在链路建立后的应用层级上可以进行数据加密。配对便是进行认证之前的一个关键步骤。由配对产生初始密钥Kint，然后产生链路密钥Kab，双方设备将Kab存储在各自的非易失性存储器中，这样以后的通迅不需要创建Kab，直接便能进入认证阶段。密钥和认证码的产生都有一套固定的算法，所以从数学角度来看，只要终端设备输入一致，在相同的算法下得出的结果也应该是一致的。

首先初始密钥Kint是由PIN码、从设备蓝牙地址和一个主设备发给从设备的随机数共同产生的，很显然，只要PIN码一致，产生的Kint便一致，这便是为什么双方PIN码不匹配便配对失败的原因。

链路密钥是由主从设备的蓝牙地址和主从设备各一随机数共同产生的，所以只要主从设备能互换该随机数便能得到一致的Kab，这点蓝牙是怎么做到的呢？主设备将随机数RandA与Kint异或的结果发给从设备，从设备将随机数RandB与Kint异或的结果发给主设备，由于双方已经有了一致的Kint，显然从设备只需( (RandA异或Kint）异或Kint)便能得到RandA，主设备亦然，这时双方输入一致了，便能产生一致的Kab。

认证算法的输入是Kab、从设备地址和主设备发给从设备的随机数，结果一致则认证成功，显然只要Kab一致便能认证成功。认证成功便能建立链路级的连接了。

显然：1、不配对是无法建立连接的，因为没有PIN码产生的Kint，便没有之后的Kab和认证；
2、设备的配对设备列表中存储的便是其物理地址及Kab（还有时钟信息），删除了该配对设备便删除了Kab，外部设备来连接时显然认证无法成功，这时是会触发再次配对的。

 

对于蓝牙连接

物理信道（physical channel）是蓝牙系统的最底层结构，它以一伪随机跳频序列、特定的发送时槽定时、接入码及帧头编码来表征。蓝牙定义了一系列物理信道用于不同的应用，包括用于匹克网内设备通信的匹克网物理信道，用于寻呼设备的寻呼扫描物理信道和用于查找设备的查找扫描物理信道。两台设备必须采用相同的物理信道才能进行通信

主从设备建立连接的过程就是建立相同的匹克网信道的过程，这样主从设备才能以同样的定时和次序进行载波频率的跳变，进行数据传输，同时可以根据匹克网接入码和帧头编码进行数据过滤和解析，避免和其他设备在同一个频段上的偶尔的相撞。

寻呼扫描物理信道（page scan physical channel）用于主设备寻呼从设备，是设备建立连接的必经阶段，主从设备是匹克网内设备的概念，这里用来指发起寻呼的设备和寻呼扫描设备。寻呼扫描跳频序列和寻呼请求帧的设备接入码-DAC是由从设备物理地址运算出来的，主设备以该跳频序列进行载波频率的跳变并在发送时间槽内发送寻呼请求，处于可被连接模式的从设备以固定的周期（由page scan interval决定）在一个固定的时间窗（由page scan window决定）内以某个跳频频率监听主设备的寻呼请求，监听到请求便在下个时间槽立即发送从设备寻呼响应(slave page response)，主设备在收到从设备寻呼响应的下个时间槽发送主设备寻呼响应(master page response)，该响应中包含了由主设备地址运算出来的跳频序列信息和时钟相位，从设备接收到这些信息便进入连接状态并自动成为匹克网的从设备，并再次返回从设备寻呼响应，主设备收到该响应后进入连接状态并自动成为匹克网的主设备。

应用层的连接是建立在匹克网物理信道之上的逻辑连接，主设备通过SDP查询从设备相应服务的逻辑通道号，依据该通道建立应用层级的连接。

 

为什么不配对就无法连接

任何无线通信技术都存在被监听和破解的可能，蓝牙SIG为了保证蓝牙通信的安全性，采用认证的方式进行数据交互。同时为了保证使用的方便性，以配对的形式完成两个蓝牙设备之间的首次通讯认证，经配对之后，随后的通讯连接就不必每次都要做确认。所以认证码的产生是从配对开始的，经过配对，设备之间以PIN码建立约定的link key用于产生初始认证码，以用于以后建立的连接。

所以不配对，两个设备之间便无法建立认证关系，无法进行连接及其之后的操作，所以配对在一定程度上保证了蓝牙通信的安全，当然这个安全保证机制是比较容易被破解的，因为现在很多个人设备没有人机接口，所以PIN码都是固定的而且大都设置为通用的0000或者1234之类的，所以很容易被猜到并进而建立配对和连接。

 

3 蓝牙兼容性

 

所谓兼容性问题，指的是支持该功能的方式有所不同，比如该手机可以传递漫游状态，但该状态和其他手机相反，那么这个属于兼容性问题。如果这个手机不能传短信状态而别的手机可以，那么这个不属于兼容性问题，即支持不支持该功能不属于兼容性问题。
这个问题怎么来的呢？虽然蓝牙SIG组织在应用的互操作性方面以profile的形式对一些功能做了规定，但有的功能并没有在profile中定义，还有就是做了规定的没有做那么多的严格界定条件，那么这个功能的实现便取决于各个手机厂商的具体实现，实现不同这就带来了兼容性问题。
最多的兼容性问题便出现在没有严格界定条件的这些应用上，比如电话簿应用，同样是syncML,有的手机必须发给它的syncML文档的最后一包必须是空包，否则无法继续同步。再比如配对后的处理，三星手机和多普达手机都是在配对后马上读取本地设备的SDP而其他手机则不然。
手机的兼容性问题可以说是制约蓝牙应用的一个关键因素，同时也是决定一款优秀的车载蓝牙设备的功能完善性的一个因素。怎么解决这个问题呢，首先要在底层解决，这个取决于采用的蓝牙芯片供应商及其方案，比如CSR(Cambridge Silicon Radio)公司，它是蓝牙业界的领导者，在兼容性方面做了非常充分的测试，其固件和蓝牙协议栈凝结了CSR在蓝牙领域的多年开发经验，而且其固件可升级，每次固件的升级都经过了大量的严格的测试，首先在底层上就保证了最大程度的蓝牙兼容性。然后便是多测手机，在应用程序上进行完善，这部分工作有时工作量很少但有时出了问题找起来便非常麻烦，笔者在这里举个例子，dopod s1手机在配对后该手机的蓝牙部分便死机了，最后发现是因为该手机是个PDA，PDA经常进行的操作便是连接SPP，尽管我的设备SPP是dev A,但dopod s1依然来连接本地设备的SPP，而我在应用程序中并没有考虑到SPP被手机连接的情况，所以造成了死机，响应了该连接请求便解决了该死机问题。

我们可以经常在网上看到这样的论调，车载蓝牙设备不好做，因为蓝牙手机厂商做得太不规范了，这些手机存在大量的兼容性问题。事实上去年我也存在这样的看法，当时因为我们做的车载蓝牙免提设备应用程序很不完善，结果拿来新手机一测问题就来了，由于问题来得突然，而且网上有很多关于手机兼容性的论调，本能的反应当然是首先把问题从自身身上推走，推到蓝牙手机厂商那里去，振振有词得抨击兼容性问题。

现在这些问题大部分都已经解决，实在不能解决的可以归之为手机自身的bug,但这bug跟蓝牙协议是没有关系的，所以，现在要为蓝牙手机厂商正名。

实事求是地说，兼容性问题绝大部分来源于自身应用程序的缺陷而不是蓝牙协议的不完善。因为蓝牙协议规定了单个功能的实现方式，但是它没有定义包含多个功能的某项应用的严格的流程或者上下文，比如配对后是不是自动连接，是马上连接还是先做一下服务查询再连接，这些都是由具体应用定义的，还有判断设备功能是靠服务发现协议（SDP）还是靠读取设备类型，这个也是没有定义的，这样就保证了实现的灵活性和应用的差异性，当然应用的差异性的前提是蓝牙协议的一致性，协议一致性保证了，兼容性问题其实就是应用的差异性带来的，当然手机应用程序的bug除外。解决应用的差异性问题需要完善车载设备的应用程序，比如针对存在配对后有的手机会先进行服务查询再连接，我们可以在配对后等待几秒的时间再去读取手机的服务，比如有的手机做SYNCML同步时会发送查询syncml服务器属性的命令，必须在应用程序中加入对该命令的处理，否则无法与该手机进行syncml同步。

当然手机很多，问题就会不少，当然做研发的遇到问题也很正常，我们要做的是不要一有问题就归为手机自身兼容性的问题，要先找自己应用程序的问题。而且不要过分相信所选择的芯片厂商提供的方案，他们的例程是有不完善之处的，比如他们的spp devA 例程中就完全没有考虑被连接的情况，而有些PDA手机是会连接免提设备的spp devA的。比如他们设置链路监控超时为5秒，这会造成很多手机的链路丢失的，这两个都是可以修改解决的，比如它们没有在寻呼完成后同时读取support feature和lmp version，这样会造成在与手机交互时选择的包类型不合适，这个只能牺牲EDR包的性能了，即不误选择这些不合适的包类型。