BLE：广播channel上的PDU分析

Posted 2021-03-14 someone-device

本文涉及如下BLE问题：

• BLE设备是如何被发现的

• 如何快速的找到BLE设备或者如何降低广播阶段的功耗

• BLE广播通道/频道(channle)上的PDU

   

1. 广播的目的

•  让别人能发现自己，对于一个不广播的设备，周围设备感觉不到其存在的，因此，要让别的设备能发现，则必须向外广播，在广播中可以带上丰富的数据，比如设备的能力，设备名字以及其他自定义的数据，这也就有了第二种可能。
• 给不需要建立连接的应用广播数据，比如一个BLE温度计，其本身可以不接收任何连接，而可以选择通过广播将温度发送出去。检测者只要监听广播就能获取当前的温度。

扫描者只有在收到广播数据后，才能去与广播者建立连接。广播是周期性的将广播数据从广播通道上发送出去，这里有如下几个问题：

1.     广播通道，广播数据是在37/38/39通道上将广播出去，当然也可以只配置在某一个广播通道上发送

2.     广播数据：即广播类型的PDU，广播所携带的信息。

3.     周期性：即广播间隔(advertising interval)

一个广播包在37,38,39分别广播出去为一个广播事件(Advertising event), 

 

以一定的时间间隔广播数据，这个间隔称为称为advertising interval，为了改善设备的兼容性,在两个广播时间间隔之间，还有加上一个随机的0-10ms的delay时间。

时间关系如下：

Advertising event的周期= advertising interval + delay

其中：delay是一个0-10ms的随机数。

advertising interval的范围：20ms – 10.24s，并且要求是0.625ms的整数倍。

2.  扫描

扫描是为了获取设备信息，发现周围设备，分两种情况：

被动扫描(Passive scan)：这种情况，扫描者不发送任何信息，只监听广播数据，扫描者能收到广播，广播者并不知道扫描设备的存在：

 

主动扫描：扫描者在接到广播数据(ADV_IND)后，主动发起扫描请求(SCAN_REQ)，广播者接到扫描请求回应扫描(SCAN_RSP)，扫描回应(SCAN_RSP)也可以携带广播者数据：

但需要注意的是，扫描者发送SCAN_REQ请求无法携带有效用户数据(参考扫描类型的PDU Payload)，因此广播和扫描者之间是单向通信，扫描者能知道广播者信息，但广播者无法知道扫描者信息。

 

广播者只是在广播通道发送广播数据，并不知道任何scanner的存在，advertiser和  scanner之间也不存在任何同步方式，只有广播和扫描所在的通道随机重合时，广播包才能被扫描设备收到，因此，和广播设备一样，扫描设备也有一些时间参数要求。

扫描有两个重要的参数：scan interval 和scan window

Scan interval：定义多久发送一次扫描请求，

Scan window：定义扫描持续的时间是多长

Scan interval 的取值范围是：2.5ms-10.24s

advertiser 和 scanner之间不存在任何同步方式，只有广播和扫描所在的通道随机重合时，双方才能发现。

对于广播和扫描而言，功耗主要消耗在发送或者接收数据期间，因此，广播间隔和扫描间隔对功耗有很大影响，不同的应用应根据实际设置合适的间隔。

 

3 初始化连接(Initiating)

当接到广播数据后，scanner可以发起建立连接请求，建立连接请求的数据包(CONNECT_REQ)是在广播通道上发起的。如下所示：

CONNECT_REQ请求中会带上重要的连接参数，包括连接时间间隔，supervision timeout，以及和跳频相关的参数，并且在建立连接后，切换到数据通道上交互数据。这些将在连接的建立中详细叙述。

4. 广播channle上的PDU的展开

将广播通道的PDU结构进一步展开如下：

1. PDU Type：指示PDU的类型，PDUType有七种，分别如下：

                          

7个类型的PDU，分为三类：

• 四个广播类型的广播PDU

• 两个扫描类型的PDU

• 一个发起连接PDU

2 RFU: reserved

3 TxAdd和RxAdd：由PDUType决定其意义，后面的章节与PDUType一并分析；

4 Length: PDU的长度，6 bits，有效范围 6-37 octets，

 5 Payload：取决于PDUType，后面的章节与PDU Type一并分析；

广播类型的PDU包括 16 bits的header 和（0-31）字节的payload，header中最重要的一个字段是PDU Type, Txaddr, RxAddr以及payload都是由PDU type决定其意义的，现在将PDUType的七种情况展开分析：

 

根据上图信息，目前，还有两个结构没有展开：AdvData和LLData，

下面以ADV_IND和CONNECT_REQ  为例来展开分析对应PDU

5. ADV_IND  PDU展开

ADV_IND PDU

最终，看到AdvData由一个个AD Structure组成，每个advStructure包括三个部分：

·       AD length，AD Type 和ADData的长度

·       AD Type：AD Data的数据含义，

·       AD Data：AD Type所指示的数据

AD type定义在Core Specification Supplement(CSS) v7 https://www.bluetooth.com/specifications/adopted-specifications

先来看从代码中找到AD type支持的类型：

最后一个AD Type = 0xFF时，可以扩展私有数据。

抓包示例（抓包软件会解析或者附带一些的帧头数据）：

这是工具已经解析了的数据，物理层原始数据如下：

按照PDU结构解析后如下：

SCAN_RSP的原始数据包如下：

解析后：

CONNECT_REQ PDU也是广播通道上的PDU，我们后续再继续展开分析。

6. 广播阶段设备的交互流程

一般情况下，广播阶段设备的交互流程如下所所示：