BlueTooth: 蓝牙基础知识进阶——链路控制操作

转自：http://blog.csdn.net/augusdi/article/details/25887395

七链路控制操作

链路控制操作就是用来描述一个设备是如何加入piconet又是如何从一个piconet中退出的。当然我们肯定不会忘记介绍一个设备是如何在多个piconet中夹缝生存的，呵呵~~

Q1：在加入和退出一个piconet的过程中是否有类似状态转换的定义啊？

这个问题不错，的确为了更好地描述这样的一个过程，我们把设备在这个过程中的转换分成了三个主要状态和七个子状态，这些状态的定义在对整个蓝牙操作的描述中是非常重要的。

三个主要状态分别为：

STANDBY:这个状态是一个设备的默认状态，可以认为是初始的状态。

CONNECTION:也就是处于连接的状态，可以进行数据的交互。我们可以认为它是正常工作的状态。

PARK:就是设备不需要进行什么操作，但又暂时不想退出piconet，这种状态我们就称之为park的状态。也就是一个pionet中除了active的slave之外的那些设备所处的状态。目前在实际应用中，PARK状态是不会使用的。

七个子状态分别为：

Page：这个子状态就是我们通常称为的连接，进行连接/激活对应的slave的操作我们就称为page。

Page scan：这个子状态是和page对应的，它就是等待被page的slave所处的状态，换句话说，若想被page到，我们就要处于page scan的状态。

inquiry：这就是我们通常所说的扫描状态，这个状态的设备就是去扫描周围的设备。

inquiry scan：这就是我们通常看到的可被发现的设备。体现在上层就是我们在Android系统中点击设备可被周围什么发现，那设备就处于这样的状态。

slave response：这个就是在page的过程中，slave收到了master的page msg，它会回应对应的pageresponse msg，同时自己就进入到了slave response的状态。

master response：master收到slaveresponse的msg后，他就会进入到master response的状态，同时他会发送一个FHS的packet。

inquiry response：就是在inquiry scan的设备在收到inquiry的msg后，就会发送inquiryresponse的msg，在这之后它就会进入到了inquiry response的状态了。

Q2：这些状态之间是如何转换的啊？

一般而言，我们来解释状态的转换都是通过状态图来描述的，这次我们仍然不例外。只要能清晰地读懂这个状态的转换图，我想整个工作的机理应该也就了然于胸了。

图7-1 链路控制的状态转换图

我们从最右边往最左边来一个个分析这个状态的转换。

standby->inquiry：当一个设备需要去扫描周围是否有别的设备的时候，就会从standby转变到inquiry的状态。到了这个状态之后，他就会重复地发送inquiry的msg，inquiry msg并没有标明任何和source相关的信息，但是它可能包含哪一类的设备应当响应这个msg。处于inquiry scan的设备，就可以响应inquiry的msg了，但是spec中说并不是所有处于inquiryc scan的设备都必须响应inquiry的msg。所以，还是有一定的自主权的，哈哈~~。

在inquiry状态的设备会收到被搜索到的设备发回的response，需要注意的是inquiry状态的设备并不需要对这个response做出任何形式的回应。因为一段时间内进行inquiry的频点范围是有限的，若想搜索到所有频点的设备，需要保证inquiry的最短时间是10.24s。这一点是尤为重要的，这也是为什么我们通常看到一些设备如Android他的搜索时间都是设为10.24s，就是这个原因。

inquiry->connection:在搜索到一个设备之后，就可以根据搜索到的信息进行连接该设备，从而进入到connection的状态。

inquiry->standby:若是不进行连接或者没有搜索到任何设备，在一定时间之后，仍然会回复到standby的状体。

connection->inquiry:和standy->inquiry比较类似，唯一的差别在于standby到inquiry可以集中全部的能力去进行inquiry，而connection到inquiry则因为有别的事情需要做，需要做一些善后的工作，比如把ACL link置到sniff状态，若是有SCO或者ESCO，则会比inquiry的优先级更高，先保证SCO或者ESCO的传输，在空隙时间才能进行inquiry。

standby->inquiry scan:若是一个设备想被发现，则会进入到inquiryscan的状态。在此状态若是收到inquiry的msg就可以进行回应了。

inquiry scan->inquiry response：在收到inquiry的msg后，就可以回应对应的inquiry的msg，从而进入到inquiryresponse的状态。回应的inquiry response有两种情况，一种就是很单纯地只回应对应的FHS的packet，另外一种就是有EIR（Entended Inquiry Result） data。是否有EIR data是FHS中的一个标志位来决定的。

inquiry response->inquiry scan: 这有两种情况，一种是我们下面要去和master建立连接从而进入到connection状态，必须要经过inquiry scan状态后才行，而不是直接就进入到conneciton状态。另外一种就是回到原来的standby状态，同样的，我们仍然要经过这个inquiry scan的状态。

inquiry scan->connection:这个和inquiry到connection状态是类似，就不多说了。

connection->inquiry scan:这个状态的变化和standy->inquiryscan是类似的，也不多说了。

standy->page scan:若是一个设备想被page到则需要进入到pagescan状态。

page scan->slave response:在收到page的msg后，page scan的设备就会发送对应的responsemsg，然后进入到slave response的状态。

slave response->connection:在第一次回应response之后，maste和slave的交互并没有完全结束。他们仍然还有别的msg的交互，在master收到slave的response之后，他会发送对应的FHS packet过来，这个时候slave response状态的设备需要再次回复一个response。在master收到这第二个response的时候，他会发送一个poll的packet下来，从这个时间点开始，slave正式进入到conneciton的状态（step5）。具体可以参见下面图7-2.

图7-2 第一次page就恢复response的示意图

这里强调一点，就是response有可能在第二个page才回复，这个在之前有讲过就不再另外介绍了。

slave response->page scan:这个就是上面这个过程出问题了，就会回到pagescan的状态。

page scan->connection:需要注意这不是一个正常的流程，它发生在connection->pagescan后page失败，他就会返回到connection状态，而不是从standy->page scan->connection。和page scan到standy类似。

page scan->standby:page失败，返回之前的standby状态。

connection->page scan:和standy到page scan类似。

standy/connection->page:若想page到一个设备，就需要进入到page的状态。

page->standy/connection:同样的page失败回复对应的初始状态。

page->master response:在收到slave的response之后，就回应对应的FHSpacket，从而进入到master response的状态。

master response->connection:和slaveresponse到connection是同步类似的，不详细解释。

master response->page: 同样的是在上面出问题了，就回到page的状态了。

connection->standby:这个就是断开连接了，建立连接要走很多中间步骤，断开连接就没有这么麻烦了，直接搞定。当然理论上还是需要通过reset或者detach命令进行的。

Q3：我们假定的master和slave的角色在整个过程中是否有机会改变啊

是的，有机会改变的。我们不能总是让一家独大，至少表面上还是要民主的，让slave也是有机会去翻身做主人的。这个过程是通过role switch来实现的。一般来说可以通过如下方式来进行role switch。一个就是主动去page，我们会把主动page的设备定义为master。另外一个就是重建一个piconet，这样他就可以把自己当成master，而把原来的master定义成slave了，当然原来的master在原来的piconet中仍然扮演着master的角色。当然在有connection建立的时候，我们也可以通过上层发送的这样的命令来进行switch的请求。

Q4：什么是sniffmode，他是如何做到low power的

正常工作情况下，slave需要在每一个master的tx点进行监听。而sniffmode则是通过增加这个监听的周期来实现low power的。如下图7-3所示，slave会在特定的间隔监听master的tx，所以master也只要在相应的间隔再发送对应的数据即可。这个间隔就是图中所示的Tsniff。slave就是只在图中所示的sniff anchor point时监听。sniff mode只能应用于异步传输，不能应用于同步逻辑传输。

图7-3 sniff的状况示意图

Q5: 什么是sniff subrating mode，它和sniff mode有什么关系

所谓的sniffsubrating mode就是使用更少的sniff anchor point，可以理解为监听的间隔更长了。他需要首先在sniff mode，然后有一个timeout，若是在这个timeout内没有ACL-C和ACL-U的data传输，就会进入到sniff subrating mode，若是中间有了，则会重启这个timer。反之，若是想从sniff subrating mode到sniff mode，只要有收到ACL的data，就需要退出到sniff mode，而且若是此时你发送的packet需要回应，那么在回应未到达的情况下，你仍然需要处于sniff mode。如下图7-4

所示。

图7-4 sniff和sniffsubrating的变换图

八 Audio

语音在蓝牙应用中是极为关键的一个部分，蓝牙耳机也在我们现实生活中起着极为重要的作用。

Q1：目前蓝牙传输的语音信息都有哪些格式？

在空气中，目前有两种语音信息格式是比较常见的，一种是64kb/s的对数 PCM一种是64kb/s的CVSD。我们在线路接口上的语音编码的质量应当不能比64kb/s的对数PCM差。

Q2：语音若是有错误是如何处理的？

在环境不是很好的情况下，语音传输的质量取决于编码格式的稳定性。当然，若是eSCO，则会有重传来保证语音的质量。相对而言，CVSD对白噪声不太敏感，不过不管怎么说，因为access code或者HEC的测试出错，或者crc校验有问题而导致pacekt被拒绝的话，需要有相应的策略来填补这个丢失的语音部分。

比如说对HV1的格式是1/3的FEC纠错，我们就假设顶多有一个bit是错的，这样就可以“恢复”错误了。对于HV2和EV4这种2/3的FEC纠错来说，若是有错误，10bit的信息还是要保存的。