蓝牙BLE之广播

参考文章：作者大棋17 链接：https://www.jianshu.com/p/ac24239c1daf
作者 枫之星雨 原文链接：https://blog.csdn.net/zzfenglin/article/details/51165543

广播数据格式

广播包有两种：

• 广播包（Advertising Data）
• 响应包（Scan Response）
  其中广播包是每个外设都必须广播的，而响应包是可选的。每个广播包的长度必须是31个字节，如果不到31个字节 ，则剩下的全用0填充。 补全。这部分的数据是无效的。

广播数据单元

广播包中包含若干个广播数据单元，广播数据单元也称为 AD Structure。

广播数据单元 = 长度值Length + AD type + AD Data。

长度值Length只占一个字节，并且位于广播数据单元的第一个字节。

概念的东西有些抽象，先看看下面的广播报文：

0x代表这串字符串是十六进制的字符串。两位十六进制数代表一个字节。
读取第一个广播数据单元。读取第一个字节:0x07,转换为十进制就是7，即表示后面的7个字节是这个广播数据单元的数据内容。超过这7个字节的数据内容后，表示是一个新的广播数据单元。
而第二个广播数据单元，第一个字节的值是0x16,转换为十进制就是22，表示后面22个字节为第二个广播数据单元。
在广播数据单元的数据部分中，第一个字节代表数据类型（AD type），决定数据部分表示的是什么数据。（即广播数据单元第二个字节为AD type），如下：

AD Type的类型如下：

 1 #define BLE_GAP_AD_TYPE_FLAGS                               0x01 /**< Flags for discoverability. */ 
 2 #define BLE_GAP_AD_TYPE_16BIT_SERVICE_UUID_MORE_AVAILABLE   0x02 /**< Partial list of 16 bit service UUIDs. */ 
 3 #define BLE_GAP_AD_TYPE_16BIT_SERVICE_UUID_COMPLETE         0x03 /**< Complete list of 16 bit service UUIDs. */ 
 4 #define BLE_GAP_AD_TYPE_32BIT_SERVICE_UUID_MORE_AVAILABLE   0x04 /**< Partial list of 32 bit service UUIDs. */ 
 5 #define BLE_GAP_AD_TYPE_32BIT_SERVICE_UUID_COMPLETE         0x05 /**< Complete list of 32 bit service UUIDs. */ 
 6 #define BLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_MORE_AVAILABLE  0x06 /**< Partial list of 128 bit service UUIDs. */ 
 7 #define BLE_GAP_AD_TYPE_128BIT_SERVICE_UUID_COMPLETE        0x07 /**< Complete list of 128 bit service UUIDs. */ 
 8 #define BLE_GAP_AD_TYPE_SHORT_LOCAL_NAME                    0x08 /**< Short local device name. */ 
 9 #define BLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME                 0x09 /**< Complete local device name. */
 10 #define BLE_GAP_AD_TYPE_TX_POWER_LEVEL                      0x0A /**< Transmit power level. */
 11 #define BLE_GAP_AD_TYPE_CLASS_OF_DEVICE                     0x0D /**< Class of device. */
 12 #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_HASH_C               0x0E /**< Simple Pairing Hash C. */
 13 #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_RANDOMIZER_R         0x0F /**< Simple Pairing Randomizer R. */
 14 #define BLE_GAP_AD_TYPE_SECURITY_MANAGER_TK_VALUE           0x10 /**< Security Manager TK Value. */
 15 #define BLE_GAP_AD_TYPE_SECURITY_MANAGER_OOB_FLAGS          0x11 /**< Security Manager Out Of Band Flags. */
 16 #define BLE_GAP_AD_TYPE_SLAVE_CONNECTION_INTERVAL_RANGE     0x12 /**< Slave Connection Interval Range. */
 17 #define BLE_GAP_AD_TYPE_SOLICITED_SERVICE_UUIDS_16BIT       0x14 /**< List of 16-bit Service Solicitation UUIDs. */
 18 #define BLE_GAP_AD_TYPE_SOLICITED_SERVICE_UUIDS_128BIT      0x15 /**< List of 128-bit Service Solicitation UUIDs. */
 19 #define BLE_GAP_AD_TYPE_SERVICE_DATA                        0x16 /**< Service Data - 16-bit UUID. */
 20 #define BLE_GAP_AD_TYPE_PUBLIC_TARGET_ADDRESS               0x17 /**< Public Target Address. */
 21 #define BLE_GAP_AD_TYPE_RANDOM_TARGET_ADDRESS               0x18 /**< Random Target Address. */
 22 #define BLE_GAP_AD_TYPE_APPEARANCE                          0x19 /**< Appearance. */
 23 #define BLE_GAP_AD_TYPE_ADVERTISING_INTERVAL                0x1A /**< Advertising Interval. */ 
 24 #define BLE_GAP_AD_TYPE_LE_BLUETOOTH_DEVICE_ADDRESS         0x1B /**< LE Bluetooth Device Address. */
 25 #define BLE_GAP_AD_TYPE_LE_ROLE                             0x1C /**< LE Role. */
 26 #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_HASH_C256            0x1D /**< Simple Pairing Hash C-256. */
 27 #define BLE_GAP_AD_TYPE_SIMPLE_PAIRING_RANDOMIZER_R256      0x1E /**< Simple Pairing Randomizer R-256. */
 28 #define BLE_GAP_AD_TYPE_SERVICE_DATA_32BIT_UUID             0x20 /**< Service Data - 32-bit UUID. */
 29 #define BLE_GAP_AD_TYPE_SERVICE_DATA_128BIT_UUID            0x21 /**< Service Data - 128-bit UUID. */
 30 #define BLE_GAP_AD_TYPE_3D_INFORMATION_DATA                 0x3D /**< 3D Information Data. */
 31 #define BLE_GAP_AD_TYPE_MANUFACTURER_SPECIFIC_DATA          0xFF /**< Manufacturer Specific Data. */

Advertising interval （广播间隔）

设备每次广播时，会在3个广播信道上发送相同的报文。这些报文被称为一个广播事件。除了定向报文（已配对的蓝牙之间传输的数据）以外，其他广播事件均可以选择“20ms ~ 10.28s”不等的间隔。通常，一个广播中的设备会每一秒广播一次。两个相邻广播事件之间的时间称为广播间隔。
但是，设备周期性的发送广播会有一个问题：由于设备间的时钟会不同程度的漂移，两个设备可能在很长一段时间同时广播而造成干扰。为防止这一情况的发生，除定向广播之外的其他广播类型，发送时间均会被扰动。实现该扰动的方式为，在上一次广播事件后加入“0 ~ 10ms”的随机延时。这意味着，即使两个设备广播间隔相同，并在相同信道及时间点上发送造成了冲突，但它们发送下一个广播事件时也会有很大可能不再冲突。
所以，两个相邻的广播事件的之间的时间间隔（T_advEvent）为：
T_AdvEvent = advInterval + advDelay
其中，advInterval 必须是“0.625ms”的整数倍，范围是“20ms ~ 10.24s”之间。对于 可扫描非定向广播和不可连接非定向广播这两种广播类型，该值最好不小于100ms，即（160个0.625ms）。 advDelay是Link Layer（链接层）分配的一个伪随机数，它的范围为“0 ~ 10ms”。
对BLE广播通信来说，Advertising的周期是一个比较重要的参数，因为它关系到系统的功耗和通信的效率，因此需要根据使用场景，小心设定。
广播包的截图如下：

当然，实际设置过程中没有广播间隔参数，而是设置Advertising_Interval_Min（最小广播间隔）和Advertising_Interval_Max（最大广播间隔）这两个参数来调整广播间隔，它们都是以“0.625ms”为单位，如果要固定广播间隔为某一个值，只需要将这两个参数设置为同一个有效数值即可。

Advertising_Type （广播类型）

广播的类型一般分为四种，分别是：

• 可连接的非定向广播（Connectable Undirected Event Type）。这是一种用途最广的广播类型，包括广播数据和扫描响应数据，它表示当前设备可以接受其他任何设备的连接请求。
• 可连接的定向广播（Connectable Directed Event Type）。定向广播类型是为了尽可能快的建立连接。这种报文包含两个地址：广播者的地址和发起者的地址。发起者收到发给自己的定向广播报文之后，可以立即发送连接请求作为回应。
• 不可连接的非定向广播（Non-connectable Undirected Event Type）。仅仅发送广播数据。
• 可扫描的非定向广播（Scannable Undirected Event Type）。这种广播不能用于发起连接，但允许其他设备扫描该广播设备。这意味着该设备可以被发现，既可以发送广播数据，也可以响应扫描发送扫描回应数据，但不能建立连接。这是一种适用于广播数据的广播形式，动态数据可以包含于广播数据之中，而静态数据可以包含于扫描响应数据之中。
  总结：
  1）如果只需要定时传输一些简单的数据（如某一个温度节点的温度信息），后续不需要建立连接，则可以使用ADV_NONCONN_IND。广播者只需要周期性的广播该类型的PDU即可，接收者按照自己的策略扫描、接收，二者不需要任何额外的数据交互。

2）如果除了广播数据之外，还有一些额外的数据需要传输，由于种种原因，如广播数据的长度限制、私密要求等，可以使用ADV_SCAN_IND。广播者在周期性广播的同时，会监听SCAN_REQ请求。接收者在接收到广播数据之后，可以通过SCAN_REQ PDU，请求更多的数据。

3）如果后续需要建立点对点的连接，则可使用ADV_IND。广播者在周期性广播的同时，会监听CONNECT_REQ请求。接收者在接收到广播数据之后，可以通过CONNECT_REQ PDU，请求建立连接。

4）通过ADV_IND/CONNECT_REQ的组合建立连接，花费的时间比较长。如果双方不关心广播数据，而只是想快速建立连接，恰好如果连接发起者又知道对方（广播者）的蓝牙地址（如通过扫码的方式获取），则可以通过ADV_DIRECT_IND/CONNECT_REQ的方式。

注意： 所谓的定向和非定向针对的是广播的对象，如果是针对特定的对象进行广播（在广播包PDU（Packet Data Unit）中会包含目标对象的MAC）就是定向广播，反之就是非定向。可连接和不可连接是指是否接受连接请求，如果是不可连接的广播类型，它将不回应连接请求。可扫描广播类型是指回应扫描请求。
不同的广播类型对扫描请求和连接请求的不同结果如下图：

Advertising_Channel_Map （广播信道）

BLE可以使用40个Physical Channel中的3个作为广播通信的物理信道，综合各种因素（抗干扰等），最终选取了如下三个：

与此同时，Link Layer允许Host在这这三个物理信道中，任意选取一个或者多个，用于广播。Link Layer将相同的广播数据，在每一个被中的Channel中，发送一次。

Advertising Event的定义

Advertising Event是在所有被使用的物理Channel上，发送的Advertising PDU的组合。
详细说明：
BLE设备处于Advertising状态的目的，就是要广播数据。并且，根据应用场景的不同，可广播4种类型的数据。
另外，BLE设备最多可以在3个物理Channel上广播数据。也就是说，同一个数据（4中类型中的一种），需要在多个Channel上依次广播。因此，这样依次在多个Channel上广播的过程，就叫做一个Advertising Event。
与此同时，有些广播（如可连接、可扫描）发送出去之后，允许接收端在对应的Channel上，回应一些请求（如连接请求、扫描请求）。并且，广播者接收到扫描请求后，需要在同样的Channel上回应。这些过程，也会计算在一个Advertising Event中。

在一个广播事件（Advertising Event）中，一个广播包会在每个信道上进行传输。显示如下：

Advertising And ScanReponse Data （广播和扫描回应数据）

广播数据和扫描回应数据，它们的长度都不能超过31个字节（0 ~ 31），数据的格式必须满足下图的要求，可以包含多个AD数据段，但是每个AD数据段必须由“Length：Data”组成，其中Length占用1个octet，Data部分占用Length个字节，所以一个AD段的长度为：Length+1。格式图如下所示：