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

时间:2021-11-12 08:16:56

转自: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:这些状态之间是如何转换的啊?

一般而言,我们来解释状态的转换都是通过状态图来描述的,这次我们仍然不例外。只要能清晰地读懂这个状态的转换图,我想整个工作的机理应该也就了然于胸了。BlueTooth: 蓝牙基础知识进阶——链路控制操作

图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.

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

图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只能应用于异步传输,不能应用于同步逻辑传输。

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

图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

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

图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的信息还是要保存的。