BLE（6）—— 扫描态数据包组成（Scanning Packets PDUs）

基于 BLE 5.1 协议 Core Spec。

目录

1、SCAN_REQ

2、AUX_SCAN_REQ

3、SCAN_RSP

4、AUX_SCAN_RSP

5、总结

---

下列在 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。