基于 BLE 5.1 协议 Core Spec。
目录
下列在 advertising physical channel 发送的(交互)的 PDU 叫做 scanning PDUs:
• SCAN_REQ
• SCAN_RSP
• AUX_SCAN_REQ
• AUX_SCAN_RSP
这里需要解释一下,为啥 Scanning PDUs 是在 advertising physical channel。因为 Scanning 是需要和 Advertising 交互的,所以呢,就这样叫了。
当然,上面的包不仅仅是 Scanner 发送,也有 Advertising 发送的,只不过这些包都是与 Scanning 相关的。
注意:这里只讲包的组成,不探讨交互以及时序,相关的交互和时序在以后的章节介绍,因为如果先介绍了交互和时序,那包体没有介绍,也比较难以理解,这就涉及到了鸡生蛋蛋生鸡的问题了,所以,还是先介绍包的组成吧。
这里分为两组:
SCAN_REQ 、AUX_SCAN_REQ : Scan 请求
SCAN_RSP 、AUX_SCAN_RSP : Advertising 回复 Scanner 的请求
注:这里我们只讨论 Payload 域,扫描态的总体数据包组成也是和广播态一致,也是分为 Preamble + AA + PDU + CRC 的组成,而 PDU 的 Header 域的含义与 Advertising 含义一致,参考 《广播态数据包组成》
1、SCAN_REQ
这种包,在 Legacy 时代就有了,用于在 Scanner 端扫描到一个可扫描的 Advertising 后,对其进行回复的包,它的组成为:
ScanA:记录了 Scanner 的地址信息
AdvA :记录了被 Scanner 收到的这个 Advertising 的地址信息
这个 SCAN_REQ 在 Primary Advertising Physical Channel 上回复,针对的对象是 Legacy 类型的可扫描的 Advertising PDU
2、AUX_SCAN_REQ
这种是专门针对 Extended Advertising 的交互,包体的内容和 SCAN_REQ 一样,只不过针对对象不一样,只针对 Extended 类型的可扫描的 Advertising PDU。Scanner 收到 Extended Advertising 的 Primary Advertising Physical Channel 上的 EXT_ADV_IND 然后再去 Secondary Advertising Physical Channel 上收到了 AUX 包,然后回复了 AUX_SCAN_REQ。
3、SCAN_RSP
这种包,也是只针对 Legacy 的 Advertising 和 Scanner 交互使用的。当 Advertising 发送的可扫描的 ADV 被 Scanner 收到,Scanner 可选择是否应答你并回复 SCAN_REQ(active 类型的 Scanning 予以回复,passtive 不回复,只是偷偷的听),此刻 Advertising 端收到来自 Scanner 的 SCAN_REQ,主动发送应答包,这个包就是 SCAN_RSP:
注意,这里能够携带最多 31 字节的数据。称之为 ScanRspData。
4、AUX_SCAN_RSP
AUX_SCAN_RSP 也是仅仅针对的是 Extended 的,发起这个包的过程也和 SCAN_RSP 类似,Advertising 收到了 AUX_SCAN_REQ 在 Secondary Advertising Physical Channel 回复这个 AUX_SCAN_RSP。
与 SCAN_RSP 不一样的是,包体是 Common Extended Advertising Payload Format :
为何是这样的呢?因为 RSP 包要带数据呀,带数据的话,那么用 Common Extended Advertising Payload Format 能够带更多的数据(251 Bytes),甚至于能够带 Chain 包,带一堆堆东西。
5、总结
看得出来,针对 Scanning 的几个包,分为了针对 Legacy 和 Extended 的,不过 REQ 的含义都几乎一致,RSP 的包含义也几乎一致。空口上发生这些包的交互,还有一些实际的 Timing 需要,后面会专门讲 Timing。