PDU

• PDU 基本數據結構
• • LL Header
• 廣播包（廣播報文）
• • Advertising Header
  • • PDU Type
    • • Advertising PDU
      • Scanning PDU
      • Initialing PDU
  • Payload length
  • Payload （有效數據包）
  • • Advertising Address
    • Advertising Data
  • 完整數據包
• 數據包（數據報文）
• • Data Header
  • • LL DATA PDU
    • LL Control PDU
  • Payload Length
  • Payload
  • • LL DATA PDU
    • • L2CAP PDU Length
      • L2CAP Channel ID （L2CAP CID）
    • LL Control PDU
    • • Opcode
      • CtrData
• 參考地址

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

PDU 基本數據結構

PDU（protocol data unit，協議數據單元，BLE 數據傳送的基本單元）前兩個字節固定為LL header（1個字節長）和 payload length（1個字節長，又稱data length），即可以展開為：

協議數據單元，又分為廣播通道PDU和數據通道PDU

LL Header

長度為一個字節。
在廣播包里他是 Advertising Header；在數據包里他是 data header

廣播包（廣播報文）

Advertising 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 沒用）

PDU Type

Advertising PDU

Control PDU NameDescription

	ADC_IND(通用廣播)	Advertiser發送的、可被連接的、無方向的廣播數據（connectable undirected advertising event）
	ADV_DIRECT_IND(定向廣播)	Advertiser發送的、可被連接的、單向廣播數據（connectable directed advertising event）
	ADV_NONCONN_IND(不可連接廣播)	Advertiser發送的、不可被連接的、無方向的廣播數據（non-connectable undirected advertising event）
	ADV_SCAN_IND(可掃描廣播)	Advertiser發送的、可接受SCAN_REQ請求的、無方向的廣播數據（scannable undirected advertising event）

Scanning PDU

Control PDU NameDescription

	SCAN_REQ(掃描請求)	Scanner發送的、向Advertiser請求額外信息的數據包（一般需要在收到ADV_SCAN_IND后才可發送）
	SCAN_RSP(掃描響應)	Advertiser發送的、響應SCAN_REQ請求的數據包

Initialing PDU

Control PDU NameDescription

	CONNECT_REQ(連接請求)	Initiater 發起的、請求建立連接的數據包
	CONNECT_IND（5.1）

根據藍牙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

Payload length

數據包：長度域包含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 （有效數據包）

在廣播包中，Payload由兩部分組成，Advertising Address 和 Advertising Data組成，如下：

Advertising Address

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購買；管理申請繁瑣；不安全

Advertising Data

轉：藍牙協議分析(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

AD TypeValue描述備注

Flags	0x01	標注藍牙特性
Service UUIDs	0x02	標注服務UUID	非完整的16 bit UUID列表
Service UUIDs	0x03	標注服務UUID	完整的16 bit UUID列表
Service UUIDs	0x04	標注服務UUID	非完整的32 bit UUID列表
Service UUIDs	0x05	標注服務UUID	完整的32 bit UUID列表
Service UUIDs	0x06	標注服務UUID	非完整的128 bit UUID列表
Service UUIDs	0x07	標注服務UUID	完整的128 bit UUID列表
Local Name	0x08	標注名稱	設備簡稱
Local Name	0x09	標注名稱	設備全名
TX Power Level	0x0A	標注射頻發射功率	表示設備發送廣播包的信號強度
Simple Pairing Option OOB Tags	0x0D	標注安全管理帶我外標簽	設備類別
Simple Pairing Option OOB Tags	0x0E	標注安全管理帶我外標簽	設備配對的Hash值
Simple Pairing Option OOB Tags	0x0F	標注安全管理帶我外標簽	設備配對的隨機值
Security Manager TK Value	0x10	標注 帶外方式配對綁定時的TK	TK安全管理
Security Manager Out of Band	0x011	標注帶外特性標志	帶外安全管理
Slave Connection Interval Range	0x012	標注連接參數范圍	外設（Slave）連接間隔范圍
List of 16-bit Service Solicitation UUIDs	0x014	標注主機特定服務	服務搜尋16 bit UUID列表
List of 128-bit Service Solicitation UUIDs	0x015	標注主機特定服務	服務搜尋128 bit UUID列表
Service Data	0x016	服務數據	16 bit UUID Service，前兩個字節是UUID，后面是Service的數據
Public Target Address	0x17		公開目標地址，表示希望這個廣播包被指定的目標設備處理，此設備綁定了公開地址
Random Target Address	0x18		：隨機目標地址，表示希望這個廣播包被指定的目標設備處理，此設備綁定了隨機地址
Appearance	0x19		表示設備的外觀
Advertising Interval	0x1A		廣播區間
LE Bluetooth Device Address	0x1B		LE設備地址
LE Role	0x1C		LE設備角色
Simple Pairing Hash C-256	0x1D		256位設備配對的Hash值
Simple Pairing Randomizer R-256	0x1E		256位設備配對的隨機值
Service Data - 32-bit UUID	0x20		32 bit UUID Service，前4個字節是UUID，后面是Service的數據
Service Data - 128-bit UUID	0x21		128 bit UUID Service，前16個字節是UUID，后面是Service的數據
3D Information Data	0x3D		3D信息數據
Manufacturer Specific Data	0xFF	廠商信息	廠商自定義數據，廠商自定義的數據中，前兩個字節表示廠商ID，剩下的是廠商自己按照需求添加，里面的數據內容自己定義。

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值

數據包（數據報文）

Data Header

轉：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：預留

LL DATA PDU

當 Connection 的包體中 LLID 是 01’b 或者 10’b 的時候，說明這個是個數據包（L2CAP的）

如下，是01的時候，是數據包

如下，是10的時候，是數據包

如上，01的時候數據包是空包，10的時候數據包是普通數據包

LL Control PDU

當 Connection 的包體中 LLID 是 11’b 的時候，說明這個是個控制包（LL Control PDU）

如下，11的時候是控制包

Payload Length

數據包：長度域包含5個比特，有效值的范圍是0~31。
原BLE4.0 4.1中 規定數據長度5個比特。BLE4.2以后可以修改。

Payload

LL DATA PDU

LL DATA PDU數據包就是 L2CAP的數據包。

如果包含MIC部分

mic是消息完整性檢查分場景的（如果payload 為空或者該linklayer 沒有加密可以不添加mic部分，反之添加mic部分）

L2CAP PDU Length

表示后面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。

L2CAP Channel ID （L2CAP CID）

邏輯通道的ID，BLE使用固定的通道編號，也就是說雖然藍牙spec里面也允許BLE使用connection oriented channel，但大部分BLE協議棧實現的時候都是使用固定的通道編號，通道編號定義如下所示：

Value描述

	0x0004	用于ATT協議
	0x0005	用于L2CAP信令
	0x0006	用于安全管理

待續，先這樣吧

LL Control PDU

連接建立之后，Master或者Slave可以借助Link Layer Control Protocol (LLCP)，通過LL Control PDU，對連接進行管理控制

數據格式如下：

LL Control PDU是在Link layer層直接進行交互的，他們不會經過后面的L2CAP層。

Opcode

OpcodeControl PDU NameDescription

0x00	LL_CONNECTION_UPDATE_IND	更新鏈接參數
0x01	LL_CHANNEL_MAP_REQ（4.2）	更新鏈接的 Channel Map
0x01	LL_CHANNEL_MAP_IND（5.1）	更新鏈接的 Channel Map
0x02	LL_TERMINATE_IND	斷開連接請求
0x03	LL_ENC_REQ	加密流程相關交互
0x04	LL_ENC_RSP	加密流程相關交互
0x05	LL_START_ENC_REQ	加密流程相關交互
0x06	LL_START_ENC_RSP	加密流程相關交互
0x07	LL_UNKNOWN_RSP	收到未知的 LLCP 后的回復
0x08	LL_FEATURE_REQ	請求交換 Feature 的交互，藍牙設備連接后用于數據
0x09	LL_FEATURE_RSP	請求交換 Feature 的交互
0x0A	LL_PAUSE_ENC_REQ	重啟加密流程相關交互
0x0B	LL_PAUSE_ENC_RSP	重啟加密流程相關交互
0x0C	LL_VERSION_IND	交換藍牙協議版本
0x0D	LL_REJECT_IND	拒絕請求
0x0E	LL_SLAVE_FEATURE_REQ	Slave 請求 Feature
0x0F	LL_CONNECTION_PARAM_REQ	更新鏈接參數
0x10	LL_CONNECTION_PARAM_RSP	更新鏈接參數
0x11	LL_REJECT_EXT_IND	擴展類型的拒絕請求
0x12	LL_PING_REQ	加密后的 PING 流程交互
0x13	LL_PING_RSP	加密后的 PING 流程交互
0x14	LL_LENGTH_REQ	更新空口數據長度
0x15	LL_LENGTH_RSP	更新空口數據長度
0x16	LL_PHY_REQ	PHY 更新相關交互
0x17	LL_PHY_RSP	PHY 更新相關交互
0x18	LL_PHY_UPDATE_IND	PHY 更新相關交互
0x19	LL_MIN_USED_CHANNELS_IND	Channels 相關的配置
All other values	Reserved for Future	Use 預留

CtrData

待續，先這樣吧

參考地址

抄的大佬，做的學習筆記。

轉 ：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

總結

以上是生活随笔為你收集整理的蓝牙相关学习：4.2.BLE空口包结构 - PDU的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。