[Bluetooth Core V4.2] VOL2, PartB, 6 Packets

6 包

蓝牙设备可使用如下部分设定的包。

6.1 通用格式

6.1.1 基本速率

基本速率的通用包格式如下:
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第1张图片

一个包可包含:

  • 只包含截短的访问码(ID包)
  • 访问码和包头部
  • 访问码,包头部和净荷

6.1.2 增强数据速率

[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第2张图片

访问码和包头部的格式和调制方式与基本速率包相同。增强数据速率包有一个看守时间和同步序列跟随着包头部。随后是净荷和两个结尾负号。看守时间,同步序列和结尾在6.6节定义。

6.2 位顺序

当在基带特征说明里定义包和消息时,位顺序是小端格式。下列规则应用在:

  • LSB对应b0;
  • LSB是在空中发送的第一个位;
  • 在图示中,LSB展示在左侧;

此外,数据域产生于基带等级内部,例如包头域和净荷长度,应以LSB为第一位发射。例如,一个3-bit参数X=3被发送成:

b0b1b2=110

穿过空气时先发射1,后发射0。

6.3 访问码

每个包以一个访问码作为开始。如果一个包头跟在后面,访问码是72bit长,否则访问码是68bit且被称作截短访问码。截短访问码不能包含一个尾部。这个访问码用在同步,DC偏置补偿和身份认证。访问码在物理通道识别所有包:所有在相同物理通道内传送的包的前部分是相同的访问码。在设备接收器内,当一个门限值被超过后,一个滑动相关器把访问码和触发器相关联。这个触发器信号用来决定接收时序。

截短访问码用在呼叫,询问和停泊。既然如此,访问码自身被用做一个信号消息,且既不作为头部也不作为当前的净荷。

访问码包括一个序,一个同步字,和一个可能的尾部。
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第3张图片

6.3.1 访问码类型

不同访问码类型使用不同的低地址部分(LAPs)以构成同步字。BD_ADDR的LAP域在1.2部分被解释。不同的访问码类型概述在表6.1中。
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第4张图片

CAC包括一个premable,sync word和trailer,且它的整个长度是72bits。当作为一个没有头部的自包含消息时,DAC和IAC不包括结尾bits和68bits长。

6.3.2 序

序是一个固定的4符号0-1模式,用来帮助DC补偿。序列是‘0101’或‘1010’(在发射次序),取决于随后的各个同步字的LSB是1或是0。
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第5张图片

6.3.3 同步字

同步字是一个64位码字源于一个24bit地址(LAP);对CAC而言主设备的LAP被用到;对GIAC和DIAC而言,被保留的,专门的LAPs被用到;对DAC而言,从设备LAP被用到。这种基于不同LAPs的构造保证了同步字之间的汉明距离最大化。此外,同步字很好的自动相关性特征提高了timing的获得。

6.3.3.1 同步字定义

同步字是基于一个覆盖(位宽异或)64位全长度伪随机噪声序列(PN)的一个(64,30)删信块码。删信码保证了不同地址之间同步字的汉明距离(dmin = 14)最大。PN序列提升了访问码的自动相关特性。后续步骤描述了如何生成同步字:

  1. 生成信息序列;
  2. 用PN覆盖序列的”信息覆盖“部分与此序列异或运算;
  3. 生成代码字;
  4. 用所有PN覆盖序列的所有64bits与代码字做异或运算;

通过附加6bit到24bit LAP上生成信息序列(step 1)。如果LAP的MSB等于0,附加bits是001101。如果LAP的MSB等于1,附加bits110010。LAP MSB和附加bits一起构成一个长度为7的巴克序列。包含一个巴克序列的目的是进一步提高自相关特性。
群同步 其中有马克序列的说明
在步骤2中这些信息通过与PN序列的p34-p63异或实现预扰码。在生成代码字后(step 3),完整的PN序列异或到代码字(step 4)。这个步骤将代码字中的信息部分解扰码。与此同时代码字的奇偶校验位被扰码。终于,原始的LPA和巴克序列作为访问码同步字的一部分来确保规则,且周期性的潜在代码特性被移除。图6.5描绘了原理。(具体运算见spce)
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第6张图片
(a0是蓝牙设备地址的LSB)。

6.3.3.2 伪随机噪声序列生成器

为了生成PN序列,本原多项式应被使用。(具体运算见spce)

6.3.4 尾部

只要包头跟在访问码后面,尾部被附加在同步字的后面。这是在CAC的典型应用,但当这些码用在呼叫应答和询问应答期间的FHS包交换时,尾部也用在DAC和IAC。

尾部是一个固定的4位0-1符号模式。尾部与同步字的3位MSB构成一个7bit交替0-1模式,可被用于延伸DC补偿。尾部序列是‘1010’或‘0101’(在传输顺序)分别取决于同步字的MSB是0还是1。尾部的选择如下图:
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第7张图片

6.4 包头部

头部包含链接控制(LC)信息且包括6个域:

  • LT_ADDR: 3-bit 逻辑传送地址
  • TYPE: 4-bit 类型代码
  • FLOW: 1-bit 流控制
  • ARQN: 1-bit 回单指示
  • SEQN: 1-bit 序列号
  • HEC: 8-bit 头部错误检查

整个头部包括HEC,包含18bits,且以1/3 EFC 比率编码后形成一个54bit头部。LT_ADDR和TYPE域被LSB首先发送。
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第8张图片

6.4.1 LT_ADDR

3bit LT_ADDR域包含包的逻辑传送地址。这个域指出了在主-从传输slot内的目标从设备(或在一个广播中的多个从设备),也指出了在一个从-主传输slot内的源从设备。

6.4.2 TYPE

16种不同类型的包可以被区分。4bit TYPE码指定了哪个包类型是可用的。TYPE码的说明取决于包内的逻辑传送地址。首先,它应取决于包是否在一个SCO逻辑传送,一个eSCO逻辑传送,一个ACL逻辑传送,或一个CSB逻辑传送上发送。其次,它应取决于由LT_ADDR指示的为了逻辑传送(ACL或eSCO)的增强数据率是否已经被使能。它也能取决于哪个类型的SCO包,eSCO包或ACL包被收到。TYPE码决定了当前包将使用多少个slots。这就允许非编址接收器在剩余的slots期间内拒绝监听此通道。6.5对每个包类型有更详细的描述。

6.4.3 FLOW

FLOW bit 用在在ACL逻辑传送上的流控制。当ACL逻辑传送的RX缓冲器在接收端是满的,一个STOP指示(FLOW = 0)应被返回以暂时停止其他设备发送数据。STOP信号只影响ACL包。包只包含链接控制信息(ID,POLL和NULL包),SCO包或eSCO包仍能继续接收。当RX缓冲器能接收数据后,一个GO指示(FLOW = 1)应被返回。当收不到包时,或收到的包头有错误,一个GO应被假定隐含。这样一来,虽然从设备的RX缓冲器并不是一直为空,但它能接收一个有着CRC的新的包。即使这个包通过了CRC校验,从设备仍应返回一个NAK以应答这个包。

FLOW bit 并不用于eSCO逻辑传送且应在传送时被设为1,且在接收端应被忽视。在CSB逻辑传送时FLOW bit 未被使用且应在传送时被设为0,在接收端应被忽视。

6.4.4 ARQN

1bit接收指示ARQN用一个具有CRC的净荷数据的成功发射来通知源,且能积极回应ACK或不回应NAK。

ARQN bit不用在CSB逻辑传送,且在发射时应设置为0,且在接收时忽略。

6.4.5 SEQN

SEQN bit 提供一个按次序编码制以排列数据包流。7.6.2章是初始化和SEQNbit的用途。对活跃或停泊的从广播包来说,一个改进的排序方法被用到。

6.4.6 HEC

每个头部都有一个头部错误检测以检测头部完整性。HEC是一个8bit宽(章7.1.1专门讲HEC生成)。在生成HEC之前,HEC生成器以一个8bit值初始化。对在主设备应答子状态中发送的FHS包来说,从设备上层地址部分(UAP)应被用到。对FHS包和在询问应答时的扩展询问应答包来说,默认检查初始化(DCI)应被使用。在所有其他情况下,主设备的UAP应被使用。

在初始化后,应为头部的10bit计算HEC。在检查HEC之前,接收器应以合适的8bit UAP(或DCI)初始化HEC检查电路。如果HEC不能检查,整个包需要丢弃。更多信息在7.1章节。

6.5 包类型

在微微网上使用的包的类型取决于他们用的是哪个逻辑传送。四个逻辑传送以有区别的包类型定义如下:

  • SCO逻辑传送
  • eSCO逻辑传送
  • ACL逻辑传送
  • CSB逻辑传送

为了在一个逻辑传送中指示不同的包,4bit TYPE码被用到。包类型被分成四个部分。第一个部分是为控制包保留的。所有控制包占用一个单独的时间slot。第二个为包保留的部分占用一个单时间slot。第三个部分占用三个时间slot。第四部分占用五个时间slot。slot的占用反映在分段上且能直接采自类型码。表6.2概述了SCO,eSCO,ACL和CSB逻辑传送类型的包的定义。
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第9张图片

所有关于净荷的包类型应使用GFSK调制,除了在下面部分中特别指出来。

ACL逻辑传送增强数据率包类型明确地通过LMP使用packet_type_table参数来选择。eSCO增强数据率包类型在当eSCO 逻辑传送建立后被选择。CSB逻辑传送的增强数据包类型在CSB逻辑传送被建立后被选择。

6.5.1 共用包类型

有五个共用包类型。除了在上表中分段1中列出的类型外,ID包也是一个共用包类型,但并未列在分段1中,因为它没有一个包头部。

6.5.1.1 ID包

身份或ID包由设备访问地址(DAC)或询问访问地址(IAC)组成。它固定长度为68bits。它是非常有鲁棒性的包,由于接收器使用一个位相关器将收到的包与ID包中已知的位序列做适配。

6.5.1.2 NULL包

空包没有净荷且只由通道访问码和包头部组成。它的固定总长度是126bits。NULL包可用来反馈链接信息给源设备有关前一个传输的成功(ARQN),或接收缓冲器的状态(FLOW)。空包不是必须回应的。

6.5.1.3 PULL包

PULL包与NULL包非常近似。它并没有净荷。与NULL包相比,它需要从接收端获取一个确认。它不是ARQ设计的一部分。POLL包不影响ARQN和SEQN的域。从设备一旦接收到POLL包,它应应答这个包,甚至在从设备没有任何信息需要发送的时候,除非从设备在那个时间slot内有分布网委托。这个返回包是一个POLL包的隐含回应。这个包总在一个微微网内被主设备使用以调查从设备。从设备应不能发送POLL包。POLL不应在一个非连接从广播逻辑传送上被传送。

6.5.1.4 FHS包

FHS包是一个特别的控制包,它包含蓝牙设备地址和发送者的时钟。它的净荷包含144个信息bit加上16bit CRC码。净荷以一个总有效载荷长度为240bit的2/3比率FEC编码。

图6.9图示了FHS载荷的格式和内容。FHS包用在呼叫主设备应答,询问应答和规则切换。

FHS包不是加密的。没有净荷头部或MIC存在。

FHS包包括实时时钟信息。这个时钟信息应在每次重传之前被升级。FHS净荷的重传与普通的数据净荷重传不同之处在于,同样的净荷被用在每次重传中。FHS包用于在微微网通道建立后的频率跳变同步,或当一个已存在的微微网切换到新的微微网。然而,FHS包不会被非连接从广播从设备用来与非连接从连接主设备实现频率跳变同步。
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第10张图片
每个域的更多信息如下:

  • 奇偶位:这34bit域包含的奇偶位构成了发送FHS包的设备的访问码的同步字的第一部分。这些位采自LAP。
  • LAP:这24位域应包含发送FHS包的设备的低地址部分。
  • EIR:这个位应标明一个扩展询问应答包可以跟随
  • 未定义:留作以后用且不能设为0
  • SR:这2位是搜寻重复域且指出两个连续呼叫搜寻窗口的间隔
  • 保留:这2为应设为10
  • UAP:这8位域应包含发送FHS包的设备的高地址部分
  • NAP:这16位域应包含发送FHS包的设备的非有效地址部分
  • 设备类别:这24位域应包含发送FHS包的设备的设备类别。这个域包含在Bluetooth Assigned Numbers。
  • LT_ADDR:这3位域应包含在FHS包用于连接建立或规则切换时的接收端的本地传送地址。一个从设备应答一个主设备或一个设备应答一个询问请求消息时它应在发送FHS包时包含一个全0 LT_ADDR域。
  • CLK27-2:这26位域应包含发送FHS包的设备的自身时钟的值,采样于这个FHS包的访问码的传送的开始。这个时钟的值有一个1.25ms(2个slot间隔)的分辨率。对每个新的传输来说,这个域被更新以精确地反映实时时钟的值。
  • 呼叫搜索模式:这3位域应指示哪个搜索模式是FHS包发送器的默认值。呼叫搜索模式的解释在表6.5。

设备发送FHS时可根据表6.4设置SR位:
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第11张图片

设备发送FHS时可根据表6.5设置呼叫查询模式位:
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第12张图片

LAP,UAP和NAP共同构成了发送FHS包的设备的48位蓝牙设备地址。在使用奇偶位和LAP时,接收端能直接构建FHS包的发射端的通道访问代码。

当为询问应答FHS包初始化HEC和CRC时,UAP可以是DCI。

6.5.1.5 DM1包

DM1包是段落1的一部分,为的是支持在任何允许DM1包的逻辑传送内的控制消息。然而,它也可以搭载增整齐的用户信息。由于DM1包能被视为一个ACL包,它将在6.5.4中讨论。

6.5.2 SCO包

HV和DV包用在同步SCO逻辑传送。HV包不包括一个MIC或CRC且不可被重传。DV包在数据部分包括一个CRC,但不在同步数据部分。DV包不包括一个MIC。DV包的数据部分可被重传。SCO包可被通路到同步I/O端口。SCO逻辑传送允许四中包:HV1,HV2,HV3和DV。这些包典型地被用在64kb/s语音传输,但也可用在透明同步数据传输。

当E0被使能后SCO包只能被E0编码。当AES-CCM编码使能后,SCO包不可被发送。

6.5.2.1 HV1包

HV1包有10个信息字节。这些字节以1/3 FEC 比率保护。不存在MIC。不存在CRC。净荷长度固定为240bit。不存在净荷头部。

6.5.2.2 HV2包

HV2包有20个信息字节。这些字节以2/3 FEC率保护。不存在MIC。不存在CRC。净荷长度固定为240bit。不存在净荷头部。

6.5.2.3 HV3包

HV3包有30个信息字节。这些字节不以FEC保护。没有MIC。不存在CRC。净荷长度固定为240bit。没有净荷头部。

6.5.2.4 DV包

DV包是数据和音频的联合包。DV包只可以用在一个HV1包。净荷包被分成一个80位的语音域和一个最多150位的数字域,见图6.10。语音域不以FEC保护。数字域在1和10个信息字节之间(包括1字节的净荷头部)加一个16位的CRC码。不存在MIC。数字域(包括CRC)以2/3 比率的FEC压缩。由于DV包的同步内容,其不得不在有规律的间隔内发送,它被列在SCO包类型下方。语音和数据域可被分别处理。语音域可与普通SCO数据采用相同的方式来处理,且不可悲重传;那就是说,语音域总是新的。数据域会检查错误且如需要的话可被重传。当在SCO逻辑传送结束之前,在DV包里的异步数据域没有被应答,异步数据域可以一个DM1包重传。
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第13张图片

6.5.3 eSCO包

EV包用在同步eSCO逻辑传送。如果在重传窗口内如果没有收到合适的应答,一个包含CRC和重传的包会被应用。不存在MIC。eSCO包可以被通路到同步I/O端口。三个eSCO包类型(EV3,EV4,EV5)被定义用于基础速率操作,4个额外的eSCO包类型(2-EV3,3-EV3,2-EV5,3-EV5)用于增强数据速率操作。eSCO包可被用于64kb/s的语音传输,又可以是64kb/s的透明数据和其他的速率。

6.5.3.1 EV3包

EV3包有1到30之间的信息字节加上一个16位CRC码。不存在MIC。FEC不保护字节。EV3包可以覆盖一个单时间slot。不存在净荷头部。净荷长度在LMP eSCO建立期间设定且维持固定,直到连接被移除或重新协定。

6.5.3.2 EV4包

EV4包有1到120之间的字节信息加上一个16位CRC码。信息加上CRC位以2/3 FEC 编码。不存在净荷头部。净荷长度在LMP eSCO建立期间设定,且一直持续到链接移除或重新协定。

6.5.3.3 EV5包

EV5包有1到180之间的信息字节加上1个16位CRC码。没有MIC。字节不由FEC保护。EV5包可以覆盖最多三个时间slot。没有净荷头部存在。净荷长度在LMP eSCO建立期间设定,且一直持续到链接移除或重新协定。

6.5.3.4 2-EV3包

2-EV3包与EV3包相似,除了净荷使用π/4-DQPSK调制。它有1到60信息字节加上1个16位CRC码。没有MIC存在。字节不靠FEC保护。2-EV3包覆盖一个单时间slot。没有净荷头部存在。净荷长度在LMP eSCO建立期间设定,且一直持续到链接移除或重新协定。

6.5.3.5 2-EV5包

2-EV5包与EV5包相似,除了净荷使用π/4-DQPSK调制。它有1到360信息字节加16位CRC码。没有MIC存在。字节不靠FEC保护。2-EV5包覆盖最多三个时间slot。没有净荷头部存在。净荷长度在LMP eSCO建立期间设定,且一直持续到链接移除或重新协定。

6.5.3.6 3-EV3包

3-EV3包与EV3包相似,除了净荷使用8DPSK调制。它有1到90信息字节加16位CRC码。没有MIC存在。字节不靠FEC保护。3-EV3包覆盖一个单时间slot。没有净荷头部存在。净荷长度在LMP eSCO建立期间设定,且一直持续到链接移除或重新协定。

6.5.3.7 3-EV5包

3-EV5包与EV5包相似,除了净荷使用8DPSK调制。它有1到540信息字节加16位CRC码。没有MIC存在。字节不靠FEC保护。3-EV5包覆盖最多三个时间slot。没有净荷头部存在。净荷长度在LMP eSCO建立期间设定,且一直持续到链接移除或重新协定。

6.5.4 ACL包

ACL包用在异步逻辑传送和CSB逻辑传送。搭载的信息可以是给逻辑运输的用户数据或给异步逻辑运输的控制数据。

基本速率运算定义了7种包类型:DM1,DH1,DM3,DH3,DM5,DH5和AUX1。增强速率运算定义了六种额外的包:2-DH1,3-DH1,2-DH3,3-DH3,2-DH5,3-DH5。

净荷头部的长度指示器指定了用户数据的长度(不包含净荷头部,MIC和CRC码)。

6.5.4.1 DM1包

DM1包仅搭载数据信息。净荷有1到18个信息字节(包括1字节净荷头部)加1个16位CRC码。一个32位MIC只存在于当AES-CCM加密被使能时。DM1包占用一个单时间slot。信息位MIC(当存在时),加上CRC位以2/3比率的FEC码编码。净荷头部在DM1包内长一字节。

6.5.4.2 DH1包

这个包与DM1包类似,除了在净荷内的信息不用FEC编码,DH1包有1到28个信息字节(包括1字节净荷头部)加一个16位CRC码。一个32位MIC仅存在于当AES-CCM加密被使能时。DH1包占用一个单时间slot。

6.5.4.3 DM3包

DM3包可占用最高三个时间slot。净荷在2到123个信息字节之间(包括2字节净荷头部)加上一个16位CRC码。一个32位MIC仅存在于当AES-CCM加密被使能时。信息位,MIC位(当存在时),加上CRC位以2/3比率FEC编码。DM3包内的净荷头部是两个字节长。

6.5.4.4. DH3包

这个包与DM3包相似,除了在净荷内的信息不是FE编码。因此,DH3包有2到185个信息字节(包括2字节净荷头部)加上一个16位CRC码。一个32位MIC仅存在于当AES-CCM加密被使能时。DH3包最多可占用3个时间slot。

6.5.4.5 DM5包

DM5包可占用最多5个时间slot。净荷有2个到226个信息字节(包括2字节净荷头部)加一个16位CRC码。一个32位MIC仅存在于当AES-CCM加密被使能时。CM5包内的净荷头部长2字节。信息位,MIC位(如果存在的话),加CRC位以2/3比率FEC编码。

6.5.4.6 DH5包

这个包与DM5包相似,除了在净荷中的信息不用FEC编码。结果是,DH5包有2到341个信息字节(包括2字节净荷头部)加一个16位CRC码。一个32位MIC仅存在于当AES-CCM加密被使能时。DH5包可最多占用5个时间slot。

6.5.4.7 AUX1包

这个包与DH1包相像但没有MIC或CRC码。AUX1包有1到30个信息字节(包括1字节净荷头部)。AUX1包占用一个单时间slot。AUX1包不可用在ACL-U,ACL-C或PBD逻辑链接。一个AUX1包可被丢弃。当E0加密被使能后,AUX1包只可以此方式编码。当AES-CCM加密被使能后AUX1包不可被使用。

6.5.4.8 2-DH1包

这个包与DH1包相似,除了净荷使用π/4-DQPSK加密。2-DH1包有2到56个信息字节(包括2个净荷头部)加一个16位CRC码。一个32位MIC仅存在于当AES-CCM加密方式被使能时。这个2-DH1包占用一个单slot包。

6.5.4.9 2-DH3包

这个包与DH3包相似,除了净荷使用π/4-DQPSK加密。2-DH3包有2到369个信息字节(包括2个净荷头部)加一个16位CRC码。一个32位MIC只存在于当AES-CCM加密被使能时。2-DH3包可占用最多3个时间slot。

6.5.4.10 2-DH5包

这个包与DH5包相似,除了净荷使用π/4-DQPSK加密。2-DH5包有2到681个信息字节(包括2个净荷头部)加一个16位CRC码。一个32位MIC只存在于当AES-CCM加密被使能时。2-DH5包可占用最多5个时间slot。

6.5.4.11 3-DH1包

这个包与DH1包相似,除了净荷使用8DPSK加密。3-DH1包有2到85个信息字节(包括2个净荷头部)加一个16位CRC码。一个32位MIC只存在于当AES-CCM加密被使能时。3-DH1包可占用最多一个单时间slot。

6.5.4.12 3-DH3包

这个包与DH3包相似,除了净荷使用8DPSK加密。3-DH3包有2到554个信息字节(包括2个净荷头部)加一个16位CRC码。一个32位MIC只存在于当AES-CCM加密被使能时。3-DH3包可占用最多3个时间slot。

6.5.4.13 3-DH5包

这个包与DH5包相似,除了净荷使用8DPSK加密。3-DH5包有2到1023个信息字节(包括2个净荷头部)加一个16位CRC码。一个32位MIC只存在于当AES-CCM加密被使能时。3-DH5包可占用最多5个时间slot。

6.6 净荷格式

在净荷内,分为两个域:同步数据域和异步数据域。ACC包只有异步数据域,SCO和eSCO包只有同步数据域,例外的是DV包两者都有。

6.6.1 同步数据域

在SCO内,只支持基础速率模式,同步数据域有固定的长度且只由同步数据身体部分组成。不存在净荷头部。

在基础速率eSCO内,同步数据域包括两个部分:同步数据身体和CRC码。不存在净荷头部。

在增强数据速率eSCO内,同步数据域包括5个部分:保护时间,同步序列,同步数据身体,CRC码和尾部。不存在净荷头部。

  1. 增强数据速率保护时间
    对增强数据速率包来说,保护时间被定义为一个周期,这个周期起始于最近的头部的GFSK符号的结束,结束于同步序列参考符号的起始部分。保护时间长度可在4.75us到5.25us之间。

  2. 增强数据率同步序列
    对增强数据速率包来说,在同步序列开端的的符号时序可在最近的包头部的GFSK符号时序的正负1/4us之间。同步序列的长度是11us(11 DPSK符号)且由一个参考符号(随即相位)跟着10个DPSK符号组成。
    DPSK符号之间的相位变化(在同步序列中展示)如下:

{ϕ1, ϕ2, ϕ3, ϕ4, ϕ5, ϕ6, ϕ7, ϕ8, ϕ9, ϕ10} =
{3π/4, -3π/4, 3π/4, -3π/4, 3π/4, -3π/4, -3π/4, 3π/4, 3π/4, 3π/4}

[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第14张图片

Sref是参考符号。ϕ1是参考符号和第一个DPSK符号S1之间的相位变化。ϕk是符号k-1和k之间的相位差。
注意:生成同步序列的调制方式可使用预挂起数据来生成同步序列。
对π/4-DQPSK,位序列通常用来生成同步序列为0,1,1,1,0,1,1,1,0,1,1,1,1,1,0,1,0,1,0,1。
对8DPSK,位序列通常生成同步序列0,1,0,1,1,1,0,1,0,1,1,1,0,1,0,1,1,1,1,1,1,0,1,0,0,1,0,0,1,0。

  1. 同步数据身体
    对HV和DV包而言,同步数据身体的长度是固定的。对EV包而言,同步数据身体的长度在LMP eSCO建立期间协商确定。一旦协商完成,同步数据身体长度维持不变直到重新协商。各方向上的eSCO逻辑传送的同步数据身体的长度可以不同。

  2. CRC码
    章7.1指定了净荷的16位CRC的生成。8位主设备UAP通常用来初始化CRC生成器。只有同步数据身体段需要生成CRC码。

  3. 增强数据速率尾部
    对增强数据速率尾部而言,两个尾部符号可被增加到每个净荷的结束部分。尾部位可为全0。例如{00, 00} for the π/4-DQPSK and {000, 000} for the 8DPSK。

6.6.2 异步数据域

基础速率ACL包有一个异步数据域,由两个、三个或四个段组成:一个净荷头部,一个净荷身体,可能有一个MIC,且可能有一个CRC码。

增强数据速率ACL包有一个异步数据域,由六或七个段组成:一个保护时间,一个同步序列,一个净荷头部,一个净荷身体,可能有一个MIC,CRC和尾部。

  1. 增强数据速率保护时间
    与6.6.1定义的同步数据域一致

  2. 增强数据速率同步序列
    与6.6.1定义的同步数据域一致

  3. 净荷头部
    净荷头部有1到2字节长。基础数据速率包在段1和2中有一个1字节的净荷头部;基础速率包在段3和4中和所有增强数据速率包中有一个2字节的净荷头部。净荷头部指定了逻辑链接(2位LLID指示位),控制逻辑通道的流(1位FLOW指示位)且有一个净荷长度指示器(5位和10位,分别给1字节和2字节净荷头部)。在2字节的净荷头部的情况下,长度指示器扩展进入下一个字节内。第二个字节的剩余3位被保留以被将来使用,且可被设成0。
    [Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第15张图片

[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第16张图片

LLID域可首先被发射,长度域排最后。LLID域的更多信息在表6.6中。
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第17张图片

一个L2CAP消息可被分片成许多包。码10b可悲用在一个ACL-U包内以搭载一个消息的第一个分片;码01b可被用在连续的分片。第一个通过HCI的L2CAP消息的分片被定义为一个00b或01b的packet_boundary_flag值,这两个值都映射到LLID码10b。如果没有分片,码10b可被用在每个包。用在PBD逻辑链接的ACL包不能使用分片。对PBD逻辑链接上使用的ACL包而言,LLID码10b可被用在发射端。任何在PBD逻辑链接上使用的不等于10b的ACL包可被接收器忽略。码11b可悲用在LMP消息。码00b保留供未来使用。

在净荷中流指示器用来在L2CAP层级控制流。这通常用来控制每个逻辑链接的流。FLOW=1意味着流-打开(GO)且FLOW=0意味着流-关闭(STOP)。在一个新的连接建立后,流指示器可被设置为GO。当一个设备收到一个flow位为STOP的净荷头部时,它需要在一个额外数量的净荷数据被发送之前停止ACL-U包的发送。这个数量由流控制滞后定义,把数量表示为字节。流控制之后不可超过1792字节(7*256字节)。为了允许设备优化包长度的选择和缓冲器空间,一个给定的流控制滞后可在LMP_feature_res消息内提供。

如果一个包含了STOP净荷流位的包被收到,以一个有效的包长度而不是坏的净荷,净荷流控制位可被忽视。包含在包头部内的基带ACK将被收到且未来一个ACL包将被发送。每次发生这种情况时允许一个更多的的ACL包被发送,尽管流控制请求已经通过净荷头部流控制位被发送出去。建议设备使用净荷头部流位时应允许不要发送更多的ACL包,直到净荷流位被正确地接收。想要实现这点,就需要同时打开包头部的流位且保持打开直到一个返回的ACK被收到(ARQN=1)。这将典型地形成一次往返。由于缺乏一个净荷CRC,AUX1包不能使用净荷流位的STOP。

基带资源管理器负责设置和处理净荷头部内的流位。实时流控制可通过包头部的流位被连接管理在包层面完成。关于净荷流位,从遥控器端的通信可被控制。允许产生和发送一个净荷长度为0的ACL包而不需考虑流状态。当净荷长度等于0时,L2CAP-开始分片和连续分片指示位(LLID=10和01)也保留他们的意义(例如一个空的开始分片不可在一个正在进行的ACL-U包传输的中间被发送)。在发送长度=0和LLID=01的ACL包时总是安全的。净荷流位在各个逻辑链接中有各自的意义(ACL-U和ACL-C),见表6.7。在ACL-C逻辑链接上,不使用流控制且净荷流位总是设置为0。在PBD逻辑链接上,没有用到流控制且净荷FLOW位可总是设为0。
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第18张图片

指示器的长度可被设为排除了净荷头部,MIC和CRC码的净荷字节数(例如8位字);例如只有净荷身体。参考6.12和6.13,在一个字节头部内,长度域的MSB是净荷头部的最后一位(右侧最高);在两个字节头部内,长度域的MSB是净荷头部的第二个字节从右向左数的第四位。

  1. 净荷身体
    净荷身体包含用户信息且决定了有效的用户吞吐率。净荷身体的长度被指定于净荷头部的长度域。

  2. 消息健全检查
    32位消息健全检查(MIC)在净荷中的生成方式在[Vol. 2, Part H] Section 9.2中专门说明。

  3. CRC码生成
    在净荷内的16位循环冗余校验码在7.1章中被指定。在决定CRC码之前,一个8位的值用来初始化CRC生成器。对于由主设备应答子状态发送的FHS包内的CRC码来说,从设备的UAP被用到。对于由询问应答子状态发送的FHS包和扩展询问应答包来说,DCI被用到。对所有其他包来说,主设备的UAP被用到。

只有净荷头部,净荷身体和MIC段(如果存在的话)被用来生成CRC码。

  1. 增强数据率尾部
    这与在6.6.1章中定义的同步数据域一致。

6.7 包概要

包的概要和他们的特性在表6.8,6.9,6.10中展示。净荷代表了除了FEC,CRC,和净荷头部的包净荷。
[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第19张图片

[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第20张图片

[Bluetooth Core V4.2] VOL2, PartB, 6 Packets_第21张图片

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