[Bluetooth Core V4.2] VOL2, PartB, 7 Bitstream Processing

7 比特流处理

蓝牙设备可使用下面段落定义的比特流处理机制。

在净荷从空中接口被发送之前,在发送器内会完成许多位操作以增强可靠性和安全性。一个HEC被加入到包头部,头部位以一个白化字扰码,且应用FEC码。在接收器内,相反的操作被实施。图7.1展示了在发送侧和接收侧的包头部处理过程。所有的头部位处理都是强制的,除了白化和去白化可以不用在同步行列包中被完成。在图7.1中,不是在所有类型的包中完成的过程由虚线指示出来。
[Bluetooth Core V4.2] VOL2, PartB, 7 Bitstream Processing_第1张图片

图7.2展示了在净荷上可能的处理过程。除了为包头部定义的过程,在净荷中加密可以被应用。白化和去白化,在图7.2中被描述的,被强制要求在每一个净荷,除了同步行列净荷,因为被禁止。图7.2中,可选的处理由虚线模块指出。当E0加密被用到,整个净荷可被加密。当AES-CCM加密被用到,只有净荷身体和MIC可被加密;净荷头部和CRC可不被加密。

7.1 错误检查

包的错误的投递或误差可以使用同步访问码,头部HEC,和净荷中的CRC来检查。在包的接收处,访问码首先被检查。由于在通道访问码内的64位同步字采自于24位主LAP,这个检查LAP是否正确,且避免接收器承认一个其他微微网的包(主设备的BD_ADDR提供的LAP域是不一样的)。

HEC和CRC计算的初始化如下:

  • 在询问应答子状态,DCI值可被用在FHS和扩展询问应答包。
  • 在主设备呼叫应答子状态,从设备的UAP可被用在FHS包。
  • 在连接状态,主设备的UAP可被使用。虽然访问码在两个微微网中可能一样,但不同的UAP值将导致HEC和CRC失败。
  • 从TDD切换开始的规则切换期间,新的从设备的UAP可被用在FHS包。

HEC和CRC的产生和检查在图7.5和7.8中概述。在计算HEC或CRC之前,HEC/CRC生成器中的位移寄存器可使用8位UAP(或DCI)值初始化。然后头部和净荷信息可被位移入各自的HEC和CRC生成器(LSB位在先)。

7.1.1 HEC生成

HEC生成器LFSR描绘在图7.3中。以8位UAP预载入来初始化这个电路,这样一来UAP的LSB位成为了移位寄存器的最左侧元素,UAP7成为了最右侧元素。HEC LFSR在图7.4中被描绘。开关S在位置1时,数据可以被移位。当最后一个数据位进入LFSR,开关S可被设置在位置2,然后,HEC能从寄存器内被读出。LFSR位可从右到左被读出(例如,位置7的位是第一个被传送的,接着是位置6)。

[Bluetooth Core V4.2] VOL2, PartB, 7 Bitstream Processing_第2张图片

7.1.2 CRC生成

CRC的16位LFSR的构造与HEC相似,使用CRC-CCITT生成器多项式。在这种情况下,8个最左侧位可用8位UAP载入(UAP0在左,UAP7在右),此时最右起8位可被复位为0。16位LFSR的初始化状态在图7.7中指定。在数据移入时,开关S可被设定在位置1。在最后一位进入LFSR后,开关可被设定在位置2,寄存器的内容可被从左到右发送(以位置15开始,接着是14)。

7.2 数据白化

同步队列包可以不用数据白化字扰码。在所有其他包发送之前,头和净荷可以数据白化字扰码,为的是从高度冗余模式来随机化数据,且最小化包的DC偏置。扰码可在FEC编码前完成。

在接收器,收到的扰码后的包的数据可被解扰码,使用的是接收端的相同的白化字生成器。解扰码可在FEC解码后完成。

白化字以多项式生成且随后可与头和净荷异或。白化字以线性反馈移位寄存器在图7.9上指出。在每个传送之前,移位寄存器可用一个主设备蓝牙时钟的一部分即CLK6-1初始化,MSB扩展为1。这个初始化的处理是由CLK1写入位置0,CLK2写入位置1。例外情况是在询问应答期间或呼叫应答期间的FHS包,还有在询问应答期间的扩展询问应答包,白化寄存器的初始化的处理可以不同。在询问或呼叫应答期间(取决于当前状态),X输入用来取代主时钟。5位值可被扩展为两个MSB为1。在寄存器初始化期间,X的LSB可被写入位置0,X1可被写入位置1。

在初始化后,包头部和净荷(包括CRC)被白化。净荷白化可从HEC的结尾的白化LFSR的状态延续。在包头部和净荷之间位移寄存器不用重新初始化。data in序列的第一位应是包头部的LSB。

对增强数据比率包来说,白化不应用在增强数据比率包的看守,同步和结尾部分。在白化没有应用的周期的期间,LFSR可以被暂停。

7.3 错误更正

蓝牙中定义了三种错误更正机制

  • 1/3 比率FEC
  • 2/3 比率FEC
  • ARQ数据机制

在数据净荷上的FEC机制的目的是为了减小重传的数量。然后,在一个合理的无错误环境中,FEC提供了非必要的开销从而减少了吞吐量。因此,章节6给出的包定义已经保持了在净荷中使用或不使用FEC的灵活性,这样一来DM和DH包为的是ACL逻辑传送,HV包为的是SCO逻辑传送,EV包为的是eSCO逻辑传送。包头部总是被一个1/3比率的FEC保护,因为它包含了贵重的链接说明,且被设计用来承受更多bit错误。

在语音解码中的掩码错误的修正测试不包含在此章节。有关内容在9.3章。

7.4 FEC码:比率1/3

一个简单的3次重复FEC码用在头部。重复码的实现是每个bit重复3次,看图7.10。3次重复码用在整个头部,同步数据域HV1包也一样。

7.5 FEC码:比率2/3

另一个FEC机制是一个(15,10)截短汉明码。这对应的是八进制符号65。LFSR生成码描绘在图7.11。所有寄存器元素初始化为0。10个信息bit随后用开关S1和S2设定在位置1,然后填充到LFSR。然后,在最后一个bit输入,开关S1和S2设定在2,5个奇偶bit位移出。奇偶bit紧随着信息bit。随后,每10个信息bit为1块,编码为15bit码字。这个码能改正所有单独的错误且检查出每个码字内的双数错误。这种2/3比率FEC用在DM包,DV包的数据域,FHS包,HV2包和EV4包。由于编码器操作的信息部分的长度是10,为0的尾bit应附加在CRCbit之后,使得bit的总数等于10的整数倍。附加的尾bit的数量应尽可能是最少的。这些尾bit并没有包含在ACL包的净荷长度指示器内,或是eSCO装载LMP命令的净荷长度域之内。
[Bluetooth Core V4.2] VOL2, PartB, 7 Bitstream Processing_第3张图片

7.6 ARQ机制

由于一种自动重复请求机制,DM包,DH包,DV包的数据域,EV包应被发射,直到接收到一个从目的端返回的成功的回单(或超时发生)。回单信息应被包含在返回包的头部。ARQ机制仅仅使用在包的净荷且只用在有CRC的包上。净荷头部和HV的同步数据净荷,还有DV包不受ARQ机制的保护。

7.6.1 未编号ARQ

蓝牙使用一个快速的,未编号的承认机制。一个ACK(ARQN=1)或一个NAK(ARQN=0)被返回以作为之前收到的包的收据。从设备在从主时隙里应答,这个应答要直接跟随主从时隙,除非从设备在那个时隙里有scatternet责任;主设备可在下一个寻址同样的从设备的事件时应答(主设备可寻址的其他从设备处在)。为了成功保证包的接收,至少HEC是必须通过的。另外,当MIC和CRC存在时,都必须通过。

在新的连接的开始的第一个POLL包(由于呼叫,呼叫搜索,规则切换或解停泊),主设备可初始化ARQNbit为NAK。从设备发送的应答包也可将ARQNbit设置为NAK。随后的包应使用下列规则。主设备的eSCO ARQN在链接装载的初始值应为NAK。

ARQNbit可以仅受数据包包含的CRC和空slot影响。如图7.12所示,当成功收到一个CRC包后,ARQNbit应设为ACK。如果,在从设备的任意接收slot,或在跟随着主设备发送的包的接收slot,下列其中之一会发生:
1. 未检测到访问码
2. HEC失败
3. CRC失败
4. MIC失败

然后ARQNbit应设为NAK。在eSCO内,ARQNbit可被设为ACK,甚至当在EV包上的CRC是失败的,这样错误的包也被同意接收。

有正确的HEC但寻址的是其他从设备,或者不是DH,DM,DV,EV包,不应影响ARQNbit。例外情况在7.6.2.2章中标注。在这些情况下,ARQNbit可以被丢弃,因为更要紧的是接收这个包。对ACL包而言,如果一个CRC包有一个正确的头部,在这个头部内,与之前收到的CRC包有着相同的SEQN,ARQNbit可设为ACK,且不检查CRC就丢弃净荷。对eSCO包而言,当确定了AQRN时,SEQN不应使用。如果一个eSCO包在eSCO窗口内被成功接收,随后的eSCO窗口内的接收应被忽略。在eSCO窗口的最后,主设备的ARQN应在下一个eSCO窗口内为了第一个主从设备传送而保持。

ARQNbit在FHS包内是无意义的。ARQNbit的内容在FHS包内无需检查。

ARQNbit在扩展询问应答包内是没用的。这个bit应设为0且在接收时被忽略。

广播包可用CRC检查,但没有ARQ机制可被应用。广播包从不会确认收到。
[Bluetooth Core V4.2] VOL2, PartB, 7 Bitstream Processing_第4张图片

[Bluetooth Core V4.2] VOL2, PartB, 7 Bitstream Processing_第5张图片

[Bluetooth Core V4.2] VOL2, PartB, 7 Bitstream Processing_第6张图片

7.6.2 重传滤波器

数据净荷可被传送,直到一个确实的回单被接收或发生超时。一个重传可被执行,既可以是因为包发送本身的失败,或因为返回包内的回单传送失败(注意后者的可能性更低,因为头部在很大程度上被编码)。在后一个事件里,目的地一次次重复接收相同的净荷。为了在目的地内滤除重传,SEQNbit要存在于头部。通常,这个bit对每个新的CRC数据净荷传输是交替的。在一个重传的例子中,bit可以不被改变,这样目的地能将SEQNbit的值与之前的SEQN值作比较。如果不同的话,一个新的数据净荷会接收;否则被认为是相同的数据净荷且被忽略。只有新的数据净荷可被传输给基带资源管理器。注意CRC数据净荷只能被DM,DH,DV,EV包负载。

7.6.2.1 在新的连接的开始初始化SEQN

在连接开始时第一个CRC数据包的SEQNbit(由呼叫,呼叫搜索,规则切换,解停泊引起的)在主设备和从设备侧都应设为1。随后的包可使用如下章节的规则。

7.6.2.2 ACL和SCO重传滤波器

如图7.15,SEQNbit只可被CRC数据包影响。每次一个新的CRC数据包被发送,它需要反转。CRC数据包可被以相同的SEQN号重传,直到一个ACK被收到,或者包被刷新。当一个ACK被收到,一个新的净荷可被发送,且在这次传送时SEQNbit应被反转。如果一个设备决定刷新(见7.6.3),且当前包未能收到一个确认收到,可用相同序列号的ACL-U连续包替换当前包,作为当前的包且长度为0。如果用这种方法替代了当前包,不应移动到发送下一个包,直到收到一个ACK。

如果从设备收到的包不是DH,DM,DV,EV,且与在相同LT_ADDR上成功接收的上一个头部的SEQNbit相反,应设定ARQNbit为NAK,直到一个DH,DM,DV或EV包被成功接收。
[Bluetooth Core V4.2] VOL2, PartB, 7 Bitstream Processing_第7张图片

7.6.2.3 eSCO重传滤波器

在eSCO内,SEQNbit应在每个sSCO窗口切换。在eSCO窗口期间这个值应保持不变。SEQNbit的初始值应设为0。

对一个给定eSCO窗口而言,SEQNbit应该不变。

7.6.2.4 FHS重传滤波器

SEQNbit在FHS包内是无意义的。这个bit可设为任意值。SEQNbit的内容在FHS包内不需要检查。

7.6.2.5 扩展询问应答重传滤波器

SEQNbit在扩展询问应答包内是不用的。这个为应设为0且在接收端无视。

7.6.2.6 没有CRC重传滤波器的包

没有CRC的包在传输期间SEQNbit应与之前的包中的值保持一致。

7.6.3 刷新净荷

在ACL逻辑传送上,ARQ机制可以导致通信上的变化的延迟,因为重传被插入以确保传输数据的零错误。对确定的链接来说,只有一个受限数量的延迟是允许的:重传在一个确定的限制内被允许,即当前净荷应被忽略。这个数据传输被标示为同步通信。这意味着重传进程必须被跳过,为的是继续下一个数据净荷。中止重传的机制由刷新就数据和强制链接控制器拿取下一个替代数据来完成。

刷新导致一个L2CAP消息剩余部分的丢失。因此紧跟在刷新后的包应有一个起始包的指示LLID=10在包头部,提供给下一个L2CAP消息。这样就把刷新通知了目的地(章6.6)。刷新不是必然导致在SEQNbit上值得变化,见之前的章节。

刷新超时定义了一个从控制器缓冲器来的ACL-U包中所有packet_boundary_flag值为10的段被刷新后的最大周期。这个刷新超时应开始于ACL-U包的第一段存储进控制器缓冲器之时。如果一个ACL-U包的第一段的packet_boundary_flag的值是00,它则不是自动刷新且不应导致刷新超时的启动。当刷新超时期满后,链接控制器可参照章7.6.2.2中描述的进程继续传输,然而基带资源管理器应不能继续ACL-U包到链接控制器的传输。如果基带资源管理器有更多的在队列中的需要传输给链接控制器的包的段,它应从队列中删除ACL-U包的剩余段。假使完整的ACL-U包并没有存储在控制器缓冲器中,任何后续的为了ACL逻辑传送而接收的段都应被刷新,直到收到第一个段。当全部的ACL-U包被刷新,链接管理器应继续为ACL逻辑传送传输下一个ACL-U包。默认刷新超时应为无限大。重传会执行,直到物理链接发生丢失。这也被称之为‘可靠通道’。所有设备应默认支持刷新超时。可靠数据应在一个通道上以有限的刷新超时发送,靠的是给可靠的包标记为非自动刷新。

在eSCO逻辑传送,包应在eSCO窗口的最后自动刷新。

非连接从广播包在每个安排好的非连接从广播瞬间发送。如果没有新的数据,非连接从广播发射器应发送有着最后可用净荷数据的包。

7.6.4 多从设备考虑

在一个有着多个逻辑传送的微微网中,主设备应在各自逻辑传送上分别执行ARQ协议。

7.6.5 活跃从设备和停泊从设备广播包

ASB和PSB广播包是由主设备同时发送给所有从设备的广播包(见8.6.4章)。如果多个跳变序列已经被使用,每个传送只能被这些从设备中的一部分接收。这样一来主设备应在各个跳变序列上重复传输。一个ASB或PSB广播包应由全零的LT_ADDR指示(注意:只有FHS包和扩展询问应答包的LT_ADDR是全零,但不是广播包)。广播包应不能被确认收到(至少在LC级是这样)。

由于广播包不能被确认收到,每个广播包被传送不少于一个固定次数。一个ASB或PSB广播包应在下一个同样的广播消息的广播包被发送以前被发送NBC此,见图7.16。可选的,一个ASB或PSB广播包可以被传送NBC+1次。注意:NBC=1意味着每个广播包应只被发送一次,但可选地被发送两次。然而,时间-严格广播信息可能使正在进行的广播往来中止。例如,在beacon实例上发送的解停泊消息,见章8.9.5。

有CRC的ASB和PSB广播包应有他们自己的序列号。有CRC的第一个广播包的SEQN应由主设备设定为SEQN=1,且在此后又CRC得每个新广播包时被反转。没有CRC的ASB和PSB广播包与序列号无关。在一个连接中,从设备应接受它收到的第一个广播包的SEQN,且应在后续的广播包检查SEQN的变化。由于广播消息没有确认收到也没有结尾包指示,正确接收到起始包尤为重要。为了确保如此,L2CAP起始包是重复的广播包,且LMP包应不被过滤掉。这些包应在净荷头部由LLID=1X指示,如表6.6的讲解。只有L2CAP后续包的重复可以被滤除。
[Bluetooth Core V4.2] VOL2, PartB, 7 Bitstream Processing_第8张图片

7.7 错误同步数据记录

错误数据的记录可由同步链接使能。当使能后,同步数据应以如下顺序执行:

  • 如果,在一个(e)SCO间隔,一个收到的eSCO包有合法的HEC和合法的CRC或一个收到的SCO包有合法的HEC,收到的净荷数据应被指示为“good data”并发送到控制器的上边沿。
  • 如果,在一个eSCO间隔,收到的eSCO包有合法的HEC,但他们都没有合法的CRC,可获得的最佳已知数据(例如采自收到的数据或是实际的净荷数据有CRC错误)应被指示为“data with possible errors”并发送到控制器的上边沿。
  • 如果,在一个(e)SCO间隔,收到的SCO或eSCO包都没有合法的HEC,一个“lost data”指示会发送给控制器的上边沿。

7.8 消息完整性检查

当AES-CCM编码使能后,一个消息完整性检查(MIC)被添加到净荷中包的CRC的前面。MIC是最高位在前8进制(MSO)。

你可能感兴趣的:(蓝牙)