蓝牙专题(4)——链路层Link Layer(空中接口包 & 比特流处理)

AIR INTERFACE PACKETS (空中接口包)
在前面的学习中,我们知道了LL的状态和角色是如何定义的,那么,在某一状态下,和其它设备实体对应状态之间的数据交换机制是什么呢?如何根据上层实体的指令,以及当前的实际情况,完成状态之间的切换?在BLE协议中,这些工作由空中接口协议(Air Interface Protocol)负责。
链路层用于广播信道(advertising channel)包和数据信道(data channel)包的报文只有一种格式:
从LSB即Preamble开始传输,最后传输MSB即CRC,数据包最短80 bits,最长2120 bits。
Preamble(前导码)
所有链路层数据包都有一个8 bits的前导码。对接收者来说,前导用于执行频率同步、符号时序估计和自动增益控制(AGC)训练。
广播包的前导码固定为10101010b(0xAA);数据包根据Access Address的LSB为0还是1,有不同的前导码。当Access Address的LSB为1,前导码为:01010101b(0x55),否则前导码为10101010b(0xAA)。
Access Address (访问地址)
无线通信时,两个设备处于同一个频道进行通信,但是有时候可能有很多个设备在使用,那么多个设备处于同一个频道的可能性就比较大,为了避免这种多个设备某时刻工作在同一频率会造成的干扰,于是就有了Access Address。但是,即使是随机数,可也有可能其他多个设备具有相同的访问地址,所以,这里使用随机地址让AA(Access Address)不同是从概率基本等价于0来说的,即在随机地址下,AA相同的概率可以忽略不计,关于AA的作用:
广播包(Advertising packets)的Access Address是固定的:0x8E89BED6;数据包(Data packets)的Access Address是一个32 bits的随机值,由处于Initiating State的设备生成,并按照Section 2.3.3.1(core_4.2)中定义的那样发送连接请求,initiator应确保Access Address符合下列要求:
.不能有6个以上连续的0和1;
.不能是广播的访问地址;
.不能喝广播的访问地址只有1 bit 不同;
.不能4个字节都相同(1字节 = 8 bits的情况);
.访问地址应该超过24次转换;
.它应在最高有效的6 bits中至少有两次转换。
 Protocol Data Unit-PDU(协议数据单元)
广播PDU和数据PDU
在介绍PDU之前,先了解RESERVED FOR FUTURE USE (RFU)的概念,在协议字段中任何标记为RFU的都保留供将来使用,RFU字段发送时需要设置为零,接收时忽略。
ADVERTISING CHANNEL PDU
广播信道的PDU格式如下:
Herder的格式如下:
注:本文章系列是以core_4.2为蓝本,在core_5.x中,数据格式有变更,前面说过,学习时先以低版本为例,学好了4.2规范,5.x规范便水到渠成。
TxAdd、RxAdd字段由具体的PDU Type决定其意义。Length字段表示广播有效载荷字段的长度(以字节为单位)。长度字段的有效范围为6到37字节。
PDU Type如下:
其中有4种PDU Type属于advertising  PDUs:
Advertising PDUs
• ADV_IND: connectable undirected advertising event;可连接的不定向广播事件,最为常见的广播类型,可接受扫描和连接请求;
该类型的负载数据为:
通过前面的介绍我们知道,PDU的范围为2-257 octets,可以得到Payload的范围为0-255 octets,这里显然没有达到最大字节数,所以剩余字节为RFU,发送时需要清零,接收时忽略;
AdvA,6 bytes的广播者地址,由PDU Header的TxAdd bit决定广播地址(AdvA)的类型(0: public,1: random);AdvData,广播数据,AdvData字段可能包含来自广播者的广播数据,示例:要求连接到任何中央设备的智能手表。
• ADV_DIRECT_IND: connectable directed advertising event;可连接的定向广播事件,专门用于点对点连接,且已经知道双方的蓝牙地址,不可携带广播数据,接受连接请求,拒绝扫描请求
该类型的负载数据为:
AdvA,6 bytes的广播者地址,由PDU Header的TxAdd bit决定广播者地址(AdvA)的类型(0 :public,1: random);InitA,6 bytes的接收者(也是连接发起者)地址,由PDU Header的RxAdd bit决定设备地址(InitA)的类型(0: public,1 :random)。注意,该数据包不包含任何Host(层)数据,示例:智能手表请求连接到特定的中央设备。
• ADV_NONCONN_IND: non-connectable undirected advertising event;不可连接的不定向广播事件,拒绝连接和扫描请求
该类型的负载数据同ADV_IND一致,那么这种PDU Type有什么应用场景呢?示例:博物馆中的信标,用于确定与特定展览品的距离;
• ADV_SCAN_IND: scannable undirected advertising event;可扫描的不定向广播事件,接受扫描请求,拒绝连接请求;
该类型的负载数据同ADV_IND一致,示例:仓库货盘信标,允许中央设备请求有关货盘的其他信息。;
四种状态是否允许回应广播事件的PDU:
这些PDU由处于广播状态(Advertising State)的链路层发送,并由处于扫描状态或发起状态(Scanning State or Initiating State)的链路层接收。
 
有2种PDU Type属于scanning PDUs 。
Scanning PDUs
• SCAN_REQ: sent by the Link Layer in the Scanning State, received by a Link Layer in the Advertising State;通过名字我们就可以知道,扫描请求,即扫描状态的时候发送的消息,广播状态接收的消息;如果此时设备处于扫描状态,当其接收到ADV_IND或者ADV_SCAN_IND类型的广播数据的时候,可以通过该PDU,请求广播者广播更多的信息;
该类型的负载数据为:
ScanA,6 bytes的主机(扫描者)地址,由PDU Header的TxAdd bit决定扫描者地址(ScanA)的类型(0: public,1 :random);
AdvA,6 bytes的广播者地址,由PDU Header的RxAdd bit决定广播者地址(AdvA)的类型(0 :public,1 :random)。
注意,该数据包不包含任何Host(协议层的Host层,这里译为主机会产生歧义)数据。
SCAN_RSP
• SCAN_RSP: sent by the Link Layer in the Advertising State, received by a Link Layer in the Scanning State,扫描应答,广播态发送消息,扫描态接收。广播者收到SCAN_REQ请求后,通过该PDU响应,把更多的数据传送给接收者;
该类型的负载数据为:
AdvA,6 bytes的广播者地址,由PDU Header的TxAdd bit决定广播者地址(AdvA)的类型(0 :public,1 :random);ScanRspData,扫描的应答数据,ScanRspData可能包含广播者的主机数据。
 
有1种PDU Type属于initiating PDUs:
Initiating PDUs
• CONNECT_REQ:This PDU is sent by the Link Layer in the Initiating State and received by the Link Layer in the Advertising State。连接请求,广播态接收,发起态发送消息;当接收到ADV_IND或者ADV_DIRECT_IND类型的广播数据的时候,可以通过该PDU,请求和对方建立连接;
该类型的负载数据为:
InitA,6 bytes的本机地址,由PDU Header的TxAdd bit决定发起者地址(InitA)的类型(0 public,1 random);
AdvA,6 bytes的广播者地址,由PDU Header的RxAdd bit决定广播者地址(AdvA)的类型(0 public,1 random);
AA  : Access Address ,可参考Vol 6,Part B (本文若无特殊说明,都是在这个大目录下的章节)Section 2.1.2
CRCInit:它是一个由链路层产生的随机值,defined in Section 3.1.1.
WinSize:defined in Section 4.5.3,transmitWindowSize =WinSize * 1.25 ms.
WinOffset:defined in Section 4.5.3 , transmitWindowOffset =WinOffset * 1.25 ms
Interval  :defined in Section 4.5.1 ,connInterval = Interval * 1.25 ms.
Latency : defined in Section 4.5.1 ,connSlaveLatency =Latency.
Timeout :defined in Section 4.5.2, connSupervisionTimeout = Timeout * 10 ms.
ChM :ChM字段包含指示已使用和未使用数据信道的信道映射。 每个通道均按照第1.4.1节(由于已经学习过,特标注出来方便查看,见下表1.2)中定义的数据通道索引位置定位。 LSB代表数据通道索引0,位置36的位代表数据通道索引36。值为0表示该通道未使用,值为1表示该通道已使用。 位置37、38和39中的位保留供将来使用。 注意:从RF信道映射到数据信道索引时,应注意在第二个广播信道的位置处留有间隙(即广播信道38的时候,数据信道为空,此处数据信道不连续,有间隔)。
Hop :Hop字段指示4.5.8.2节定义的数据通道选择算法中使用的hopIncrement。它是一个在5到16之间的随机值。
SCA : SCA字段指示用于确定最坏情况下主机的睡眠时钟精度(如第4.2.2节所定义)的masterSCA。SCA字段的值应设置为表2.2中定义的值:
百万分率(英语:parts per million缩写ppm),定义为百万分之一,1ppm即是一百万分之一。
由于有一些章节还没介绍到,所以这里暂时不发散各个字段的含义。
 
DATA CHANNEL PDU
前面介绍的都是广播通道的PDU,下面将开始学习数据通道的PDU相关知识。
数据通道PDU有一个16位报头(Header),一个可变大小的有效载荷(Payload),并可能包括一个消息完整性检查(MIC)字段。
MIC字段不应包含在未加密的链路层连接中,也不应该包含在使用零长度有效载荷的数据通道PDU的加密链路层连接中,MIC字段按照[Vol. 6] Part E, Section 1定义的方式计算。
Payload格式取决于Header的LLID字段。如果LLID区域是01b或10b,数据通道PDU有效载荷字段包含第2.4.1节定义的LL Data PDU。如果LLID字段是11b,那么数据通道PDU有效载荷字段包含一个LL Control PDU,见2.4.2节的定义。LLID字段为00b表示保留。
The NESN bit of the Header is defined in Section 4.5.9.
The SN bit of the Header is defined in Section 4.5.9.
The MD bit of the Header is defined in Section 4.5.6.
Header的length字段指示净荷(Payload)和MIC(如果包含)的长度。 长度字段的范围是0到255字节。 有效载荷字段的长度应小于或等于251字节。 MIC的长度为4个字节。
 
LL Data PDU
LLID=01b时,这种类型的PDU,要么是一个未传输完成L2CAP message(长度超过255,被拆包,此时不是第一个),要么是一个空包(Header中的Length为0)。主机的链路层可以向从机发送一个空PDU,以使从机能够响应任何数据通道PDU(包括一个空的PDU)。
LLID=10b时,这种类型的PDU,要么是L2CAP message的第一个包,要么是不需要拆包的完整的L2CAP message,值得注意的是,这种场景下的Header中的Length不能为0。
LL Control PDU
LLID=10b时,表示这个数据包为LL Control PDU,用于控制链路层的连接。
Opcode字段标识LL Control PDU的不同类型,如表2.4中所定义的那样。CtrData字段由Opcode字段决定,除非另有明确说明,否则CtrData字段中包含整数的所有字段都应解释为无符号的。
如果收到未使用或不支持的LL Control PDU,则链路层应以LL_UNKNOWN_RSP PDU进行响应。 LL_UNKNOWN_RSP PDU的UnknownType字段应设置为未使用或不支持的操作码的值。
如果收到的LL Control PDU的操作码无效,即操作码字段设置为保留供将来使用(Reserved for Future Use)的值或无效的CtrData字段,则链路层应以LL_UNKNOWN_RSP PDU进行响应。 LL_UNKNOWN_RSP PDU的UnknownType字段应设置为无效操作码的值。
至于每个 Control PDU的详细介绍,可以看Vol 6 ,Part B,2.4.2.这里暂时不介绍和前面的原因一样,有一些依托于后续章节的知识。
 
BIT STREAM PROCESSING (比特流处理)
蓝牙设备应使用以下小节中定义的比特流处理方案。
在接收包时,首先要检查访问地址(AA),如果访问地址不正确,将被拒收,反之则被视为已收到。如果CRC不正确,数据包将被拒绝,这样的数据包是无效的,反之则数据包将被认为是有效的。一个数据包只有在被认为是有效的情况下才能被处理。CRC错误的数据包可能导致继续连接事件,如第4.5.1节中所述。
CRC必须在所有链路层数据包的PDU字段上计算(即CRC是计算PDU的,不包括前导(Preamble)和访问地址(AA)字段)。 如果PDU被加密,则在对PDU进行加密之后应计算CRC。
24 bits的CRC校验值在发送的时候和其他字段不同,不知道你是否还记得,我们在前面的文章中说了CRC和MIC的传输不是LSB先行,这里,我们终于到CRC了,CRC在发送时,先发送MSB即最高有效位,再发送LSB即最低有效位。
DATA WHITENING(数据白化)
数据白化用于避免长序列的零或一,例如数据比特流中的0000000b或1111111b。 白化(whitening)应该应用于所有链路层的PDU和CRC字段,并在发送器中的CRC字段之后执行。 除白(De-whitening)是在接收器中的CRC字段之前执行的(请参见图3.1)。至于具体的白化算法,就不在此讨论了,感兴趣的可以自行查阅。
NOTE:以后的内容将在微信公众号更新。

 

posted @ 2020-04-29 14:22  Crystal_Guang  阅读(2156)  评论(3编辑  收藏  举报