1. 介紹
Bluetooth low energy，也稱BLE(低功耗藍牙)，在4.0規范中提出
BLE分為兩種設備
- 單模(single-mode): Logo為「Bluetooth®Smart」
- 雙模(dual-mode): Logo為「Bluetooth®Smart Ready」
TIP: 傳統藍牙的Logo為「Bluetooth®」
BLE與傳統藍牙的兼容性如下圖所示
可以看出他們之間的通信規則如下(Bluetooth指代傳統藍牙，下同)
- Smart Ready: Smart Ready、Bluetooth、Smart
- Bluetooth: Smart Ready、Bluetooth
- Smart: Smart Ready、Smart
2. 協議棧
BLE協議棧如下圖所示
BLE協議棧由Controller和Host兩部分組成；Profile和Service基於GAP和GATT
協議棧各層次介紹如下
- PHY: 1Mbps自適應跳頻GFSK, 運行在2.4GHz頻段 - LL: RF控制器, 控制設備的鏈路狀態 - HCI: 接口層, 向上為主機提供軟件應用程序接口, 對外通過通過串口、SPI、USB實現設備控制 - L2CAP: 為上層提供數據封裝服務, 允許邏輯上的端到端數據通信 - SM: 提供配對和密鑰分發服務, 實現安全連接和數據交換 - GAP: 直接與應用程序或配置文件通信的接口, 處理設備發現和連接相關服務; 另外還處理安全特性的初始化 - ATT: 導出特定的數據(稱為屬性)到其他設備 - GATT: 定義了使用ATT的服務框架和配置文件(Profiles)的結構; BLE中所有的數據通信都需要經過GATT
3. 鏈路層
3.1 鏈路狀態機
鏈路層操作可以描述為鏈路狀態機(The Link Layer State Machine)
鏈路狀態機有如下五種狀態
- Standby State: 准備, 不傳輸或接受數據包 - Advertising State: 廣播, advertiser, 發送advertising channel packets, 接受來自scanner的響應 - Scanning State: 監聽/掃描, scanner, 監聽來自advertiser的advertising channel packets - Initiating State: 初始化, initiator, 監聽來自特殊設備的advertising channel packets,並進行初始化連接 - Connection State: 連接, 有兩種角色: Master Role(從initiator進入)/Slave Role(從advertiser進入)
鏈路狀態機只允許處於五種狀態之一；鏈路層可以有多個鏈路狀態機，但至少有一個支持Advertising/Scanning State
處於Master Role的設備可以和多個Slave Role分時通信；處於Slave Role的設備只能和處於Master Role的設備通信
下圖展示了允許和禁止的鏈路狀態機和角色的組合
3.2 比特序
在鏈路層規范中規定Packet/PDU比特序(Bit Ordering)為Little Endian format；LSB最先發送
3.3 設備地址
設備地址(Device Address)可以是公共地址或者隨機地址，長度為48 bits
公共地址采用IEEE 802-2001 standard的48-bit universal LAN MAC addresses，格式如下
隨機地址格式如下
3.4 物理信道
BLE RF信道(Physical Channel)被定義為兩種: advertising and data
- advertising信道: 使用3個RF信道用來發現設備, 初始化連接和廣播數據
- data信道: 則使用多達37個RF信道用於兩個連接設備間通信
RF Channel和Advertising/Data channel Index對應關系如下圖 
4. BLE報文
4.1 報文格式
對於BLE鏈路層，advertising/data channel packet格式如下
數據包長度為80~376bits(10~47Byte)
- Preamble: 前導碼, 用於接收方同步頻率等 advertising channel packet - 10101010b data channel packet - 10101010b或01010101b - Access Address: 接入地址 advertising channel packet - 0x8E89BED6 data channel packet - 每個鏈路層連接都有其唯一值, 由initiator隨機生成, 相關限制可參看規范 - PDU: 協議數據單元, 對於advertising和data channel packet, 有各自的格式要求 - CRC: 由PDU計算得到
4.2 RFU
Reserved For Future Use，留待后用，設置為0，接收后被忽略
4.3 Advertising Channel PDU
PDU格式如下
Header部分格式如下 
Header各字段含義如下
- PDU Type: 定義PDU類型 - TxAdd/RxAdd: 由PDU類型決定，若未定義，則認為是RFU - Length: 定義Payload的字節數(octets)，有效范圍是6~37Bytes - Payload: 由PDU類型決定
其中PDU類型如下
在Adv PDUs中，AdvData/ScanRspData指來自Host的數據
4.3.1 Advertising PDUS
Advertising PDUS包含下面幾種類型
- ADV_IND: 表明自己是可以被連接的 Payload - AdvA(6 octets) + AdvData(0~31 octets) AdvA字段為advertiser的地址(TxAdd=0表示公共地址, Txadd=1表示隨機地址) - ADV_DIRECT_IND: 向特定設備建立連接 Payload - AdvA(6 octets) + InitA(6 octets) AdvA字段為advertiser的地址(TxAdd=0表示公共地址, Txadd=1表示隨機地址) InitA字段為initiator(接收方)的地址(RxAdd=0表示公共地址, Rxadd=1表示隨機地址) - ADV_NONCONN_IND: 用於廣播信息 Payload - AdvA(6 octets) + AdvData(0~31 octets) AdvA字段為advertiser的地址(TxAdd=0表示公共地址, Txadd=1表示隨機地址) - ADV_SCAN_IND: scannable undirected advertising event Payload - AdvA(6 octets) + AdvData(0~31 octets) AdvA字段為advertiser的地址(TxAdd=0表示公共地址, Txadd=1表示隨機地址)
這些PUDs的數據流向為 advertiser->scanner/initiator
4.3.2 Scanning PDUS
Scanning PDUS包含下面幾種類型
- SCAN_REQ: 數據流向為 scanner->advertiser Payload - ScanA(6 octets) + AdvA(6 octets) ScanA字段為scanner的地址(TxAdd=0表示公共地址, Txadd=1表示隨機地址) AdvA字段為advertiser的地址(RxAdd=0表示公共地址, Rxadd=1表示隨機地址) - SCAN_RSP: 數據流向為 advertiser->scanner Payload - AdvA(6 octets) + ScanRspData(0~31 octets) AdvA字段為advertiser的地址(TxAdd=0表示公共地址, Txadd=1表示隨機地址)
4.3.3 Initiating PDUS
Initiating PDUS包含下面的類型
- CONNECT_REQ: 數據流向為 initiator -> advertiser Payload - InitA(6 octets) + AdvA(6 octets) + LLData(22 octets) InitA字段為scanner的地址(TxAdd=0表示公共地址, Txadd=1表示隨機地址) AdvA字段為advertiser的地址(RxAdd=0表示公共地址, Rxadd=1表示隨機地址) LLData字段如下，詳細信息請參看規范
4.4 Data Channel PDU
Data Channel PDU格式如下 
4.4.1 Header
Header部分格式及字段含義如下 
4.4.2 Payload
Payload格式(Opcode[1 octet] + CtrData[0~22 octets])由LLID字段決定，有下面兩種類型
- LL Data PDU: 用來發送L2CAP數據, LLID為01b/10b
- LL Control PDU: 用來控制鏈路層連接, 詳細信息請參考規范
4.4.3 MIC
MIC(Message Integrity Check)
- 不存在的情況 ~ 在非加密連接中 ~ 加密連接, Payload為空 - 存在的情況 ~ 加密連接, Payload不為空