BLE 4.0 - BLE 5.0 ，BLE 5.1 的部分内容没有加入到里面，待添加

PDU（protocol data unit，协议数据单元，BLE 数据传送的基本单元）前两个字节固定为LL header（1个字节长）和 payload length（1个字节长，又称data length），即可以展开为：

协议数据单元，又分为广播通道PDU和数据通道PDU

长度为一个字节。 在广播包里他是 Advertising Header；在数据包里他是 data header

PDU Type：标识ADV

RFU ： 预留

ChSel：如果本机支持跳频（Hopping）算法 #2，这设置成为 1

TxAdd：如果为 0 代表 ADV 是 public 类型的 Address，否则为 1，是 random 类型的 Address

RxAdd：如果为 0 代表期望的对端地址类型为 public，否则为1，代表期望对端的 Target Address 为 random（在指向性广播中使用，因为指向性广播，携带了对端地址，其他类型广播，这个 bit 没用）

根据蓝牙spec规定，advertiser发送完一个广播包之后150us（T_IFS），advertiser必须开启一段时间的射频Rx窗口，以接收来自observer的数据包。Observer就可以在这段时间里给advertiser发送连接请求。如下图所示，手机在第三个广播事件的时候扫到了设备B，并发出了连接请求CONN_REQ(CONN_REQ又称为CONNECT_IND)。

转：详解BLE连接建立过程：https://www.cnblogs.com/iini/p/8972635.html

数据包：长度域包含5个比特，有效值的范围是0~31。（原BLE4.0 4.1中 规定数据长度5个比特）

广播包：长度域包含6个比特，有效值的范围是6~37。

广播包和和数据包的长度域有所不同，主要原因是：广播包除了最多31个字节的数据之外，还必须要包含6个字节的广播设备地址。6+31=37，所以需要6比特的长度域。

转 ：https://www.cnblogs.com/debugdabiaoge/p/15772546.html

在广播包中，Payload由两部分组成，Advertising Address 和 Advertising Data组成，如下：

Device Address，广播包中的强制字段（数据包里没有），俗称蓝牙MAC地址。 如果是广播包，则是advertiser的MAC地址；如果是scan包或者连接请求包，则是scanner的MAC地址。 蓝牙device address为6个字节，这样Advertising data最长为：37-6 = 31B，这就是广播包数据最长只能31个字节的由来（1M PHY）。

分类：

蓝牙协议分析(6)_BLE地址类型：http://www.wowotech.net/bluetooth/ble_address_type.html

一个BLE设备两种地址都可以使用（Public Device Address和Random Device Address）

Public Device Address

需要向IEEE购买；管理申请繁琐；不安全

转：蓝牙协议分析(5)_BLE广播通信相关的技术分析 http://www.wowotech.net/bluetooth/ble_broadcast.html

广播数据（或者扫描应答数据）由一个一个的AD Structure组成，对于未满31bytes的其它数据，则填充为0（无效数据）；

每个AD Structure由两部分组成：1byte的长度信息（Data的长度），和剩余的Data信息； Data信息又由两部分组成：AD Type（长度不定）指示该AD Structure的类型，以及具体的AD Data。

无效数据部分 广播包的长度必须是 31 个 byte，如果有效数据部分不到 31 自己，剩下的就用 0 补全。这部分的数据是无效的。

最关键的还是AD Type，BLE协议根据实际的应用场景，定义了各种各样的AD type，以及相应的数据格式，例如

参考地址： https://www.pianshen.com/article/7755244605/ https://www.jianshu.com/p/7d814c22a085

Flags bit 0: LE有限发现模式 bit 1: LE普通发现模式 bit 2: 不支持BR/EDR bit 3: 对Same Device Capable(Controller)同时支持BLE和BR/EDR bit 4: 对Same Device Capable(Host)同时支持BLE和BR/EDR bit 5…7: 预留

Security Manager Out of Band bit 0: OOB Flag，0-表示没有OOB数据，1-表示有 bit 1: 支持LE bit 2: 对Same Device Capable(Host)同时支持BLE和BR/EDR bit 3: 地址类型，0-表示公开地址，1-表示随机地址

0d 03 4e 00 00 80 03 26 aa d6 be 89 8e 00 24 40 9c d0 38 c1 a4 02 01 06 03 03 1a 18 09 ff 5a a5 a4 c1 38 d0 9c 40 0c 09 44 46 53 4b 30 34 2d 39 43 34 30 93 52 e4

我们传输的数据结构：

aa d6 be 89 8e 00 24 40 9c d0 38 c1 a4 02 01 06 03 03 1a 18 09 ff 5a a5 a4 c1 38 d0 9c 40 0c 09 44 46 53 4b 30 34 2d 39 43 34 30 93 52 e4

aa – 前导帧(preamble) d6 be 89 8e （0x8E89BED6） – 访问地址(access address) 00 – LL帧头字段(LL header) 24 – 有效数据包长度(payload length) 40 9c d0 38 c1 a4 （0xA4C138D09C40）– 广播者设备地址(advertiser address) 02 01 06 03 03 1a 18 09 ff 5a a5 a4 c1 38 d0 9c 40 0c 09 44 46 53 4b 30 34 2d 39 43 34 30 – 广播数据 93 52 e4 – CRC24值

转：BLE（8）—— 连接态数据包组成（ Connection Packets PDUs）https://stephenzhou.blog.csdn.net/article/details/95938674

LLID ： 用于区分这个 Connection 的包是普通的数据包（L2CAP 的起始/连续/空包），还是 Control PDU

NESN：下一个期望的对端包的 Sequence Number NESN 和 SN 来决定了数据包是否传输 OK，也就是是否需要重传

SN：当前包的 Sequence Number NESN 和 SN 来决定了数据包是否传输 OK，也就是是否需要重传

MD：是否有 More Data MD 决定了后面是否跟有更多的数据。有了这个 MD，对端才会开窗继续来收数据。

RFU：预留

当 Connection 的包体中 LLID 是 01’b 或者 10’b 的时候，说明这个是个数据包（L2CAP的）

如下，是01的时候，是数据包

如下，是10的时候，是数据包

如上，01的时候数据包是空包，10的时候数据包是普通数据包

当 Connection 的包体中 LLID 是 11’b 的时候，说明这个是个控制包（LL Control PDU）

如下，11的时候是控制包

数据包：长度域包含5个比特，有效值的范围是0~31。 原BLE4.0 4.1中 规定数据长度5个比特。BLE4.2以后可以修改。

LL DATA PDU数据包就是 L2CAP的数据包。

如果包含MIC部分

mic是消息完整性检查分场景的（如果payload 为空或者该linklayer 没有加密可以不添加mic部分，反之添加mic部分）

表示后面information payload的长度，information payload最大长度除了受这个L2CAP length字段约束，同时还受MTU的限制。

MTU，Maximum Transmission Unit，是ATT层与L2CAP层可以交互的最大数据长度，或者说是Client与Server可以交互的最大长度。

总结一下，蓝牙spec里面定义了2个长度字段： LL data length和L2CAP length，同时ATT层还定义了一个MTU，以限制ATT PDU最大长度。 LL data length可以通过LL_LENGTH_REQ和LL_LENGTH_RSP来动态改变，MTU size则可以通过后面要讲到的Exchange MTU Request和Exchange MTU Response来改变，而L2CAP length无法动态改变，也就是说不能超过65535。

逻辑通道的ID，BLE使用固定的通道编号，也就是说虽然蓝牙spec里面也允许BLE使用connection oriented channel，但大部分BLE协议栈实现的时候都是使用固定的通道编号，通道编号定义如下所示：

待续，先这样吧

连接建立之后，Master或者Slave可以借助Link Layer Control Protocol (LLCP)，通过LL Control PDU，对连接进行管理控制

数据格式如下：

LL Control PDU是在Link layer层直接进行交互的，他们不会经过后面的L2CAP层。

待续，先这样吧

抄的大佬，做的学习笔记。

转 ：BLE（3）—— 空口数据包组成 ：https://stephenzhou.blog.csdn.net/article/details/94676596

转：详解BLE空口包格式—兼BLE Link layer协议解析 https://www.cnblogs.com/iini/p/8977806.html

蜗窝科技：http://www.wowotech.net/sort/bluetooth

BLE:https://blog.csdn.net/zhoutaopower/category_9083143.html

https://blog.csdn.net/freemote/article/details/120165736