Bluetooth LE有幾種空中包格式？常見的PDU命令有哪些？PDU和MTU的區(qū)別是什么？DLE又是什么？Bluetooth LE怎么實(shí)現(xiàn)重傳的？Bluetooth LE ACK機(jī)制原理是什么？希望這篇文章能幫你回答以上問題。

雖然Bluetooth LE空口包（packet，又稱air interface packet）涉及Bluetooth LE協(xié)議棧link layer，L2CAP，SMP和ATT等各層次，但link layer跟空口包格式關(guān)系最緊密，掌握了Bluetooth LE packet的格式，就很容易理解Bluetooth LE link layer協(xié)議的工作原理，因此文章取名“詳解Bluetooth LE空口包格式—兼Bluetooth LE link layer協(xié)議解析”

Bluetooth LE Packet格式

Bluetooth LE鏈路層（link layer）只定義了一種packet（空中包）格式，如下所示：

而且PDU（protocol data unit，協(xié)議數(shù)據(jù)單元）前兩個(gè)字節(jié)固定為L(zhǎng)L header（1個(gè)字節(jié)長(zhǎng)）和payload length（1個(gè)字節(jié)長(zhǎng)，又稱data length），即上面的Packet可以展開為：

preamble（前導(dǎo)幀） 為1個(gè)字節(jié)，根據(jù)Access Address第一個(gè)Bit，有兩種取值情況：0x55或者0xAA（純PHY層行為），如下所示：

Access Address用來標(biāo)示接收者ID或者空中包身份，如前所示，Bluetooth LE只有一種packet格式，根據(jù)Access Address的不同，又區(qū)分兩種Packet類型：廣播包和數(shù)據(jù)包：

廣播包Access Address 固定為0x8E89BED6，廣播包只能在廣播信道（channel）上傳輸，即只能在37/38/39信道上傳輸（注：從藍(lán)牙5.0開始廣播包可以在其它信道上傳輸）。廣播包發(fā)送給附近所有的observer（掃描者）。

數(shù)據(jù)包Access Address為一個(gè)32bit的隨機(jī)值， 由Initiator生成。數(shù)據(jù)包，其實(shí)是數(shù)據(jù)信道上的空中包的簡(jiǎn)稱，數(shù)據(jù)包只在數(shù)據(jù)信道上傳輸，即除37/38/39之外的其余37信道（Bluetooth LE總共占用40個(gè)信道）。每建立一次連接，重新生成一次Access address。數(shù)據(jù)包是給連接通信使用的，即用于master和slave之間通信的。

CRC為24bit，初始向量為：

藍(lán)牙廣播包

藍(lán)牙廣播包，全名藍(lán)牙廣播通道（channel）空中包，即在藍(lán)牙廣播通道上傳輸?shù)目罩邪?，為兩種空中包的一種，其具體格式如下所示：

Advertising Header即前述的LL header，長(zhǎng)度為一個(gè)字節(jié)，其每bit定義如下所示：

PDU Type為3bit，具體定義如下?？梢钥闯?strong>掃描PDU和發(fā)起連接PDU都屬于廣播包。

注：CONNECT_REQ也可寫作CONNECT_IND

TxAdd/RxAdd，各占1bit，表示隨后的Device Address字段代表的藍(lán)牙MAC地址類型，值0代表Public地址，值1代表Random地址。

Payload length定義如下所示，所以廣播包PDU最長(zhǎng)37個(gè)字節(jié)。

Device Address，廣播包中的強(qiáng)制字段，俗稱藍(lán)牙MAC地址，如果是廣播包，則是advertiser的MAC地址；如果是scan包或者連接請(qǐng)求包，則是scanner的MAC地址。藍(lán)牙device address為6個(gè)字節(jié)，這樣Advertising data最長(zhǎng)為：37-6 = 31B，這就是廣播包數(shù)據(jù)最長(zhǎng)只能31個(gè)字節(jié)的由來。如前所述，device address分public和random兩種，定義如下所示：

Random device address又有三種類型，定義如下所示：

Advertising data我會(huì)另寫一篇文章來詳述，這里就不再介紹了。

如下為一個(gè)完整的真實(shí)的廣播包示例，注意：Bluetooth LE空中包采用小端模式。

AAD6BE898E600E3B75AB2A02E102010504FF5900538EC7B2

AA – 前導(dǎo)幀(preamble)

D6BE898E – 訪問地址(access address)

60 – LL幀頭字段(LL header)

0E – 有效數(shù)據(jù)包長(zhǎng)度(payload length)

3B75AB2A02E1 – 廣播者設(shè)備地址(advertiser address)

02010504FF590053 – 廣播數(shù)據(jù)

8EC7B2 – CRC24值

注：上述廣播包是藍(lán)牙4.x格式，藍(lán)牙5.0廣播包除了包含上述格式外（記?。核{(lán)牙5是跟藍(lán)牙4.x兼容的！），還有一些新的定義，以后我也會(huì)寫一篇關(guān)于藍(lán)牙5廣播的文章來專門闡述藍(lán)牙5擴(kuò)展廣播包。

藍(lán)牙數(shù)據(jù)通道空口包（數(shù)據(jù)包）

與藍(lán)牙廣播包相對(duì)應(yīng)，藍(lán)牙數(shù)據(jù)包是另一種Bluetooth LE packet。藍(lán)牙數(shù)據(jù)包是藍(lán)牙數(shù)據(jù)信道空中包的簡(jiǎn)稱，表示空中包只在藍(lán)牙數(shù)據(jù)信道上傳輸，即除37/38/39之外的其他37信道。從格式上來說，藍(lán)牙數(shù)據(jù)包又分空包（empty packet）和普通數(shù)據(jù)包（data packet）兩種，空包格式如下。

由圖可見，空包整個(gè)payload為空，故名空包。

普通數(shù)據(jù)包格式如下所示：

Data header，即前述的LL header，在數(shù)據(jù)包中的定義如下所示：

LLID（2bits）， link layer ID，對(duì)LL PDU進(jìn)行分類：LL data PDU和LL control PDU。也就是說，普通的數(shù)據(jù)信道空中包包含LL數(shù)據(jù)包和LL控制包兩種，具體定義如下所示。請(qǐng)大家注意分清data channel packet（數(shù)據(jù)信道空中包）和LL data packet（LL數(shù)據(jù)包）的區(qū)別，如前所示data channel packet包含LL data packet和LL control packet，LL data packet只是data channel packet的一種。在不引起上下文歧義的時(shí)候，我們把他們統(tǒng)一稱作“數(shù)據(jù)包”。

LL Control PDU是在Link layer層直接進(jìn)行交互的，也就是說他們不會(huì)經(jīng)過后面的L2CAP層，Link layer支持如下control PDU：

NESN/SN，NESN和SN各占1bit。SN全稱為sequence number，表示當(dāng)前發(fā)送的packet編號(hào)。NESN，next expected sequence number，用來告知對(duì)方下一個(gè)期待的packet的編號(hào)。Link layer使用SN來告知對(duì)方這個(gè)packet是新數(shù)據(jù)包還是重傳包，用NESN來告訴對(duì)方你之前發(fā)我的包已經(jīng)收到了（相當(dāng)于ACK的作用），我現(xiàn)在期待下一個(gè)新的數(shù)據(jù)包了，因此Bluetooth LE沒有專門的ACK包，它是通過NESN/SN來實(shí)現(xiàn)ACK和重傳雙重功能的。請(qǐng)參考如下表格，仔細(xì)揣摩NESN和SN是如何編碼的，以同時(shí)完成ACK和重傳功能。

我們來分析#3數(shù)據(jù)包，#3是master發(fā)給slave的，那么#3的NESN和SN是如何確定的呢？其實(shí)#3的NESN和SN是通過比較#1和#2的NESN/SN的值來確定的，Master把#1傳完之后，會(huì)把#1包的NESN和SN記錄下來，即表格右邊的NESN?和SN?。然后Master會(huì)拿SN?跟#2的NESN相比，兩者不等，說明slave已經(jīng)收到了#1包，并期待master發(fā)一個(gè)新的包給它，此時(shí)Master會(huì)把SN?增1，形成#3包的SN，表示這個(gè)數(shù)據(jù)包是一個(gè)新包，然后發(fā)出去；兩者相等，說明slave沒有收到#1包，此時(shí)master需要重傳。Master還會(huì)拿NESN?跟#2的SN相比，兩者相等，說明#2包為新包，然后Master會(huì)把NESN?增1，形成#3包的NESN發(fā)出去，告訴slave我已經(jīng)收到#2包了并期待你的下一個(gè)包；兩者不等，說明#2包為重傳包。注意：大家可以從上述表格發(fā)現(xiàn)一個(gè)規(guī)律，就是同一方向相鄰的兩個(gè)數(shù)據(jù)包，他們的NESN和SN與另一個(gè)包的NESN和SN是相反的，比如#3 NESN = #1 #NESN ，#3 SN = #1 #SN ，同樣#2和#4 各自的NESN和SN是相互相反的。

我們可以用下面的流程圖來描述上述過程。

MD（1bit），more data，用來指示對(duì)方我還有數(shù)據(jù)包要傳，請(qǐng)繼續(xù)打開射頻窗口準(zhǔn)備接收。比如Nordic nRF51822一個(gè)connection interval可以發(fā)6個(gè)包或者更多的包（也就是說，一個(gè)connection event包含多個(gè)數(shù)據(jù)包交互），用的就是MD來實(shí)現(xiàn)的。以notify命令為例，設(shè)備（Server）notify第一個(gè)數(shù)據(jù)包并將MD置1，Client（比如手機(jī)）收到這個(gè)notify命令后，就知道Server還有數(shù)據(jù)包要傳，此時(shí)手機(jī)可以繼續(xù)發(fā)一個(gè)空包給設(shè)備，以讓設(shè)備把第二個(gè)notify命令發(fā)過來，詳情如下所示。注：Master為手機(jī)（Client），Slave為設(shè)備（Server）。

Payload Length or Data Length，BT4.0/4.1定義如下所示，這就是藍(lán)牙4.0/4.1一個(gè)包只能傳20個(gè)字節(jié)的根源。

BT4.2之后，Payload length 8 bits全部用來表示長(zhǎng)度，這樣的話，payload size最大可達(dá)251字節(jié)（255 – MIC size）。Bluetooth LE連接建立之后，可以動(dòng)態(tài)更改data length長(zhǎng)度（默認(rèn)為27字節(jié)），這個(gè)特性叫做Data Length Extension（DLE），DLE是通過Link layer命令：LL_LENGTH_REQ和LL_LENGTH_RSP來實(shí)現(xiàn)的。Data length直接跟藍(lán)牙芯片的射頻能力有關(guān)，像Nordic的nRF51822只支持BT4.1的Data length，就是因?yàn)镻HY層已經(jīng)做死了，無法擴(kuò)展，但Nordic最新的nRF52832和nRF52840，就都支持DLE，即data length最大可到251字節(jié)。

L2CAP length，2字節(jié)長(zhǎng)度，表示后面information payload的長(zhǎng)度，information payload最大長(zhǎng)度除了受這個(gè)L2CAP length字段約束，同時(shí)還受MTU的限制。MTU，Maximum Transmission Unit，是ATT層與L2CAP層可以交互的最大數(shù)據(jù)長(zhǎng)度，或者說是Client與Server可以交互的最大長(zhǎng)度。

總結(jié)一下，藍(lán)牙spec里面定義了2個(gè)長(zhǎng)度字段：LL data length和L2CAP length，同時(shí)ATT層還定義了一個(gè)MTU，以限制ATT PDU最大長(zhǎng)度。LL data length可以通過LL_LENGTH_REQ和LL_LENGTH_RSP來動(dòng)態(tài)改變，MTU size則可以通過后面要講到的Exchange MTU Request和Exchange MTU Response來改變，而L2CAP length無法動(dòng)態(tài)改變，也就是說不能超過65535。

L2CAP CID，2字節(jié)長(zhǎng)度，邏輯通道的ID，Bluetooth LE使用固定的通道編號(hào)，也就是說雖然藍(lán)牙spec里面也允許Bluetooth LE使用connection oriented channel，但大部分Bluetooth LE協(xié)議棧實(shí)現(xiàn)的時(shí)候都是使用固定的通道編號(hào)，通道編號(hào)定義如下所示：

Bluetooth LEL2CAP Signaling Channel支持的PDU命令只有三個(gè)：

Command reject

Connection parameter update request，更新連接參數(shù)，比如最小連接間隔，最大連接間隔，slave latency等

Connection parameter update response，接受或者拒絕上面的請(qǐng)求

Security Manager Protocol（SMP） 用來實(shí)現(xiàn)配對(duì)和密鑰分發(fā)的，SMP支持如下PDU命令：

Attribute Protocol（ATT），就是我們經(jīng)常用到的應(yīng)用層，應(yīng)用數(shù)據(jù)就跟在ATT命令后面，ATT支持如下命令列表：

至此Bluetooth LE空中包解析就告一段落了，再往上就是應(yīng)用層數(shù)據(jù)解析了，這個(gè)就不是空中包的范疇，而是GATT和profile要定義的事情，對(duì)GATT/ATT/Profile感興趣的同學(xué)可以參考：低功耗藍(lán)牙ATT/GATT/Profile/Service/Characteristic規(guī)格解讀

如下為一個(gè)完整的真實(shí)的數(shù)據(jù)包示例，注意：Bluetooth LE空中包采用小端模式。

AAAB5D65501E08040004001B130053D550F6

AA – 前導(dǎo)幀(preamble)

0x50655DAB – 訪問地址(access address)

1E – LL幀頭字段(LL header)

08 – 有效數(shù)據(jù)包長(zhǎng)度(payload length)

04000400 – ATT數(shù)據(jù)長(zhǎng)度，以及L2CAP通道編號(hào)

1B – notify command

0x0013 – 應(yīng)用數(shù)據(jù)handle

0x53 – 真正要發(fā)送的應(yīng)用數(shù)據(jù)

0xF650D5 – CRC24值

審核編輯 黃宇