BLE 資料包格式
轉自： https://blog.csdn.net/Life_Maze/article/details/79634097
廣播態：
| LSB |
MSB |
||||||||||
| 鏈路層幀（10-47 Octet） |
|||||||||||
| Preamble |
Access Address |
PDU （2-39 Octet） |
CRC |
||||||||
| PDU type |
RFU |
TxAdd |
RxAdd |
length |
RFU |
廣播的資料（0-37 Octet） |
|||||
| AdvA |
0-31 byte |
||||||||||
| 1 Octet |
4 Octet |
4 bit |
2 bit |
1 bit |
1 bit |
6 bit |
2bit |
6 bytet |
3 Octet |
||
preamble = 10101010 or 01010101
Access Address = 0x8e89bedd6
| PDU type： 1）0000 - connected undirected advertising event 可連線非定向廣播事件 2）0001 - connected directed advertising event 可連線定向廣播事件 3）0010 - non-connected undirected advertising event 不可連線非定向廣播事件 4）0011 - response to scan request form scanner掃描請求響應 5）0101 - connect request by initiator連線請求 6）0110 -connected directed advertising event 可發現非定向廣播事件 |
|||
| 非定向廣播包（Undirected advertising packets） |
定向廣播包（Directed advertising packets |
||
| AdvA (6 Bytes) |
AdvData (31 Bytes max.) |
AdvA (6 Bytes) |
InitA(6 Bytes) |
| AdvA contains advertiser‘s public address if TxAdd = 1, or a random address if TxAdd = 0 |
AdvData advertising data |
AdvA contains advertiser‘s public address if TxAdd = 1, or a random address if TxAdd = 0; |
InitA contains initiator's address if RxAdd = 1, or a random address if RxAdd = 0; |
| PDU type： 1）0011 - scan request for further information from advertiser 掃描請求 2）0100 - response to scan request from scanner 掃描響應 |
|||
| 掃描請求 |
掃描響應 |
||
| ScanA (6 Bytes) |
AdvA(6 Bytes) |
AdvA(6 Bytes) |
ScanRspData（0~31Bytes） |
| ScanA contains Scanner's public address if TxAdd = 1, or a random address if TxAdd = 0; |
AdvA contains advertiser‘s public address if TxAdd = 1, or a random address if TxAdd = 0; |
ScanRspData data from advertiser’s host; |
AdvA contains advertiser‘s public address if TxAdd = 1, or a random address if TxAdd = 0; |
| PDU type： 0101 - connect request by initiator |
||
| 連線請求 |
||
| InitA（6 Bytes） |
AdvA（6bytes） |
LLData（22 Bytes） |
連線態：（非鏈路層控制報文）
| LSB |
MSB |
|||||||||||||||
| 鏈路層幀（10-41 Octet） |
||||||||||||||||
| Preamble |
Access Address |
PDU （2-33 Octet） |
CRC |
|||||||||||||
| LLID |
NESN |
SN |
MD |
RFU |
length |
RFU |
L2CAP層（0-27 Octet） |
MIC |
||||||||
| length |
Channel ID |
ATT_MTU=23協議幀（0-23 Octet） |
||||||||||||||
| attribute opcode |
attribute handle |
attribute Value |
||||||||||||||
| 1 Octet |
4 Octet |
2bit |
1bit |
1bit |
1bit |
3bit |
5bit |
3bit |
2 byte |
2 byte |
1 byte |
2 byte |
0-(MTU-3) |
4 byte |
3 Octet |
|
MIC為4位元組，只有在鏈路加密的情況下才會存在，為 訊息完整性校驗，防止訊息被篡改。PS:加密鏈路中的空包不會存在MIC
1位元組opcode用來指示 write，notify，indication
2位元組handle為控制代碼用來標識是操作哪個特性值的。
規範中預設這個MTU最大為23位元組，這個值其實是可以通過命令來協商的
Host層的GAP（通用訪問協議）
l 負責：連線前資料廣播
l 本層有定義了4種不同型別的廣播(gap.h)：
1. 通用的：GAP_ADTYPE_ADV_IND （可被掃描，可被連線）
2. 定向的：GAP_ADTYPE_ADV_DIRECT_IND （不可被掃描，可被連線）
3. 不可連線的：GAP_ADTYPE_ADV_DISCOVER_IND （可被掃描，不可被連線）
4. 可發現的：GAP_ADTYPE_ADV_NONCONN_IND （不可被掃描，不可被連線）
通用廣播：通用廣播是用途最廣的廣播方式。進行通用廣播的裝置能夠被掃描裝置掃描到，或者在接收到連線請求時作為從裝置進入一個連線。通用廣播可以在沒有連線的情況下發出，換句話說，沒有主從裝置之分。
定向廣播：有時候，裝置間需要快速建立連線。如果從裝置想這麼做，就需要進行廣播。定向廣播事件就是為了儘可能快的建立連線。這種報文包含兩個地址：廣播者的地址和發起者的地址。發起裝置收到發紿自己的定向廣播報文後，可以立即傳送連線請求作為迴應。
不可連線廣播：不想被連線的裝置使用不可連線廣播事件。這種廣播的典型應用包括裝置只想廣播資料，而不想被掃描或者連線。也是唯一可用於只有發射機而沒有接收機裝置的廣播型別。不可連線廣播裝置不會進入連線態，因此，它只能根據主機的要求在廣播態和就緒態之間切換。
可發現廣播：最後一種廣播事件是可發現廣播。這種廣播不能用於發起連線，但允許其他裝置掃描該廣播裝置。這意味著該裝置可以被發現，既可以廣播資料，又可以響應掃描，但不能建立連線。這是一種適用於廣播資料的廣播形式，動態資料可以包含於廣播資料之中，而靜態資料可以包含於掃描響應資料之中。可發現廣播不會進入連線態，而只能在停止後回到就緒態。
協議規定，payload 最大 27。剩下的就 23 個位元組 MTU。就是你看到的。就剩下 20了。這剩下的 20 位元組就是我們常說的傳送的 20 位元組的資料。
| payload 最大 27 |
|||
| L2CAP |
23 個位元組 MTU |
||
| ATT 層op code |
ATT 層attribute handle |
可用 |
|
| 4 個位元組 |
1 個字 |
2 個位元組 |
20byte |
上面是藍芽協議 4.0 中的內容。所以這個 MTU 是不少於 23，也是可以修改的，但是前提是 client 支援修改 MTU，如果 client 只支援 Default Value，那就不能修改。如果一個裝置既有 client 又有 server，那麼 client Rx MTU 和 server Rx MTU 必須是一樣的。
但是這個修改我不確定是不是 BLE 的特性，問了 TI 的人，給的回答是 BLE 允許修改 MTU 是藍芽 4.1 的新特性，姑且相信他吧。
廣播PDU格式：
無方向廣播包：
PDU Type = ADV_IND型別的：PDU解析
| 協議資料單元PDU |
||||||
| Header(16bits) |
Payload=advA(6byte)+advdata(0-31byte) |
|||||
| PDU Type (4 bits)
|
RFU (2 bits)
|
TxAdd (1 bit) |
RxAdd (1 bit) |
Length (6 bits) |
RFU (2 bits) |
Payload (長度由Header中的“Length”欄位決定) |
| 指示PDU(協議資料單元)的型別 |
reserved |
由具體的PDU Type決定 |
由具體的PDU Type決定 |
PDU的長度 |
reserved |
XXX |
| 0 |
/ |
0 |
0 |
13 |
/ |
|
| 32 octets(octet專指8 bits構成的位元組) |
說明 |
|||
| 有效資料部分 significant |
長度 Len (1 octes) |
Data (len octes) |
/ |
|
| AD Type（n ）AD Type.c |
AD data（len-n) |
/ |
||
| 表示這個 AD Structure 的長度（除去 len本身 1） |
標記這段廣播資料代表什麼， 比如裝置名， uuid |
資料 |
/ |
|
| 02 |
01 |
06 |
廣播資料單元1 AD Structure |
|
| 03 |
02 |
F0 FF |
廣播資料單元2 AD Structure |
|
| 。。。 |
。。。 |
。。。 |
廣播資料單元n AD Structure |
|
| 無效資料 non-significant |
補充 0；到32octets |
/ |
||
掃描請求包和掃描迴應包分析：
掃描請求包:
掃描迴應廣播包：
連線請求和迴應包：
Host層的GATT（通用屬性協議）
l 負責：連線後的資料傳輸。在屬性協議(ATT)的基礎上構建，為屬性協議傳輸和儲存資料建立了一些通用操作和框架。
l 本層有定義兩個角色：伺服器和客戶端
l GATT的角色並不一定與特定的GAP角色有關聯，但可能由更高層級的配置檔案指定。
l GATT和ATT不是傳輸專用，也可以用於BR/EDR和低耗能。但是，由於GATT和ATT用作發現服務，故必須在低耗能技術中實施。
l GATT伺服器儲存通過屬性協議傳輸的資料，並接受GATT客戶端發出的屬性協議請求、指令及確認。