低能耗藍(lán)牙4.0協(xié)議原理與實(shí)現(xiàn)方法

徐金茍

0 引言

隨著藍(lán)牙技術(shù)由手機(jī)、游戲、耳機(jī)、便攜電腦和汽車等傳統(tǒng)應(yīng)用領(lǐng)域向物聯(lián)網(wǎng)、醫(yī)療等新領(lǐng)域擴(kuò)展，市場(chǎng)對(duì)低功耗的要求越來(lái)越高。藍(lán)牙4.0協(xié)議版本是在藍(lán)牙3.0高速版本基礎(chǔ)上增加了低能耗協(xié)議部分。嵌入式設(shè)備端在很多應(yīng)用場(chǎng)景要求能耗非常低，傳輸速率要求也不高，對(duì)于這類設(shè)備，可以僅實(shí)現(xiàn)4.0協(xié)議中低能耗藍(lán)牙部分，通過(guò)與支持雙模的主機(jī)設(shè)備進(jìn)行通信或者跟同類設(shè)備通信。

由于藍(lán)牙4.0協(xié)議擁有極低的運(yùn)行和待機(jī)功耗，使用一粒紐扣電池甚至可連續(xù)工作數(shù)年之久；同時(shí)還有低成本、跨廠商互操作性、3毫秒低延遲、AES-128加密等諸多特色，可以廣泛應(yīng)用于計(jì)步器、心律監(jiān)視器、智能儀表、傳感器物聯(lián)網(wǎng)等眾多領(lǐng)域，大大擴(kuò)展藍(lán)牙技術(shù)的應(yīng)用范圍。所以，目前很多藍(lán)牙廠商也都推出了符合藍(lán)牙 4.0 版本的低功耗協(xié)議的藍(lán)牙芯片。本文介紹藍(lán)牙4.0低能耗部分協(xié)議即LE的技術(shù)原理、協(xié)議架構(gòu)以及給出一個(gè)具體的實(shí)現(xiàn)方法。

1 協(xié)議原理

LE協(xié)議的底層與基礎(chǔ)藍(lán)牙協(xié)議底層基本相似，但在主機(jī)端，針對(duì)傳感器網(wǎng)絡(luò)應(yīng)用推出了屬性協(xié)議 ATT以及通用屬性剖面GATT，具體協(xié)議分層結(jié)構(gòu)，如圖1所示：

圖1 協(xié)議分層結(jié)構(gòu)圖

其中，基于邏輯鏈路與適配協(xié)議即L2CAP以上的部分可在主機(jī)端實(shí)現(xiàn)，這一部分可稱為主機(jī)端部分，HCI層以下部分可稱為芯片控制器層也可簡(jiǎn)稱底層協(xié)議。下面我們對(duì)每層協(xié)議做一下描述。

（1）物理層（Physical Layer）

物理層采用調(diào)頻技術(shù)減少干擾與信號(hào)衰減，從2．402～2．480 GHz均勻分為40個(gè)信道，每個(gè)信道寬2MHz；使用GFSK調(diào)制解調(diào)方式；輸出功率為：0．01～10mw；傳輸速率1 Mb／s。提供3個(gè)固定的廣播信道，廣播數(shù)據(jù)用于建立連接以及發(fā)現(xiàn)設(shè)備，這樣使得建立連接的時(shí)間可以壓縮到3ms左右，大大提高了設(shè)備建立連接的效率。另外提供 37個(gè)數(shù)據(jù)信道采用自適應(yīng)調(diào)頻技術(shù)發(fā)送數(shù)據(jù)。

（2）鏈路層（Link Layer）

鏈路層功能是執(zhí)行一些基帶協(xié)議底層數(shù)據(jù)包管理協(xié)議。

鏈路層設(shè)備主要有待機(jī)、發(fā)起、掃描、連接、廣播5種工作狀態(tài)，狀態(tài)轉(zhuǎn)換圖，如圖2所示：

圖2 狀態(tài)轉(zhuǎn)換圖

待機(jī)狀態(tài)不發(fā)送和不接受任何包，任何狀態(tài)都可以進(jìn)入待機(jī)狀態(tài)。

廣播狀態(tài)在廣播信道發(fā)送廣播包并且監(jiān)聽(tīng)可能的響應(yīng)包，廣播狀態(tài)可以由待機(jī)狀態(tài)進(jìn)入。

掃描狀態(tài)將會(huì)監(jiān)聽(tīng)廣播信道包，掃描狀態(tài)可以從待機(jī)狀態(tài)進(jìn)入。

發(fā)起狀態(tài)將會(huì)監(jiān)聽(tīng)從特定設(shè)備發(fā)出的廣播包并且發(fā)起鏈接請(qǐng)求作為響應(yīng)，發(fā)起狀態(tài)可從待機(jī)狀態(tài)進(jìn)入。

連接狀態(tài)可以從發(fā)起狀態(tài)或者廣播狀態(tài)進(jìn)入，在連接狀態(tài)下有主從兩種角色。

當(dāng)從發(fā)起狀態(tài)進(jìn)入連接狀態(tài)時(shí)，發(fā)起連接請(qǐng)求，將會(huì)是主設(shè)備，當(dāng)從廣播狀態(tài)進(jìn)入連接狀態(tài)時(shí)，將會(huì)是從設(shè)備。

鏈路層主要有兩種重要的事件操作：掃描與建立鏈接。

設(shè)備掃描有被動(dòng)掃描和主動(dòng)掃描兩種：

被動(dòng)掃描是通過(guò)被動(dòng)接收廣播包得到設(shè)備信息。被動(dòng)掃描過(guò)程，如圖3所示：

圖3 被動(dòng)掃描

主動(dòng)掃描是通過(guò)發(fā)送掃描請(qǐng)求得到掃描回應(yīng)得到設(shè)備信息。主動(dòng)掃描過(guò)程，如圖4所示：

圖4 主動(dòng)掃描

而建立鏈接過(guò)程是通過(guò)發(fā)送鏈接請(qǐng)求包來(lái)建立設(shè)備鏈接。建立鏈接過(guò)程，如圖5所示：

圖5 建立連接流程圖

（3）主機(jī)控制接口層(HCILayer)

主機(jī)控制接口與標(biāo)準(zhǔn)藍(lán)牙技術(shù)相同，提供了主機(jī)與控制器層的通信方式與命令事件格式，重用標(biāo)準(zhǔn)藍(lán)牙傳輸層接口如UART,USB等。

（4）邏輯鏈路與適配協(xié)議層（L2CAPLayer）

與標(biāo)準(zhǔn)藍(lán)牙技術(shù)相同，為上層提供了數(shù)據(jù)封裝業(yè)務(wù)，提供端到端的邏輯數(shù)據(jù)通信。

（5）安全管理層(Security Manager Layer)

定義了配對(duì)和密鑰分發(fā)方法，提供其它層協(xié)議接口來(lái)安全的建立連接以及交換數(shù)據(jù)。安全管理層不涉及具體的BLE安全算法，只是提供一些接口，為節(jié)省功耗以及降低復(fù)雜性，具體安全算法可以通過(guò)在底層硬件實(shí)現(xiàn)。

（6）通用接入層(GAP Layer)

定義了通用的接口，供應(yīng)用層調(diào)用底層模塊，比如設(shè)備發(fā)現(xiàn)，建立連接相關(guān)的業(yè)務(wù)，同時(shí)封裝了安全設(shè)置相關(guān)的API。

（7）屬性協(xié)議層（ATT Layer）

屬性協(xié)議允許設(shè)備以“屬性”的形式向另外的設(shè)備暴露他的某些數(shù)據(jù)。在ATT協(xié)議里，暴露屬性的稱為Server 端，另外一端稱為Client。

（8）通用屬性剖面(GATT Profile)

GATT 層是一種具體使用屬性協(xié)議的應(yīng)用框架。GATT定義了屬性協(xié)議應(yīng)用的架構(gòu)。在BLE協(xié)議中，應(yīng)用中數(shù)據(jù)片段被稱為“特征“， 而BLE中兩個(gè)設(shè)備之間的數(shù)據(jù)通信就是通過(guò)GATT 子過(guò)程來(lái)處理的。

2 協(xié)議的實(shí)現(xiàn)方法

低能耗藍(lán)牙是一種對(duì)數(shù)據(jù)傳輸速率要求不高的通信協(xié)議，在實(shí)現(xiàn)BLE數(shù)據(jù)協(xié)議時(shí)采用一種簡(jiǎn)單的分層協(xié)議架構(gòu)。設(shè)計(jì)時(shí)可以將主機(jī)端與控制器端通過(guò)HCI 層分開(kāi)實(shí)現(xiàn)。

這里，可以考慮采用一種通用的通信協(xié)議實(shí)現(xiàn)框架，該實(shí)現(xiàn)框架運(yùn)行效率高，移植方便，并且可以運(yùn)用到其他通信協(xié)議上。

首先，考慮一下一般通信協(xié)議需要考慮的主要實(shí)現(xiàn)策略：

（1）協(xié)議層次結(jié)構(gòu)

分層結(jié)構(gòu)是如果每層由一個(gè)任務(wù)來(lái)管理資源，其他層與之通信采用消息隊(duì)列或者信號(hào)量等通信原語(yǔ)，這種結(jié)構(gòu)層次較為清晰，由操作系統(tǒng)來(lái)負(fù)責(zé)調(diào)度和各層執(zhí)行，但這種結(jié)構(gòu)需要考慮系統(tǒng)任務(wù)切換時(shí)占用的開(kāi)銷。特別是對(duì)小型資源有限的嵌入式系統(tǒng)。

另外一種方法就是由一個(gè)任務(wù)來(lái)處理所有各層事物，這種方法可以減少任務(wù)切換的開(kāi)銷，但系統(tǒng)看起來(lái)結(jié)構(gòu)不清晰，容易發(fā)生錯(cuò)誤。

（2）Buffer 管理機(jī)制

通信協(xié)議數(shù)據(jù)Buffer的管理是一個(gè)難點(diǎn)，處理的不好會(huì)影響系統(tǒng)的效率。一種典型的應(yīng)用是在不同層級(jí)之間采用數(shù)據(jù)分配、拷貝，然后釋放，這種機(jī)制，結(jié)構(gòu)清晰，但拷貝數(shù)據(jù)會(huì)影響系統(tǒng)的效率，如圖6所示：

圖6 內(nèi)存拷貝方式

如果采用零拷貝的機(jī)制，在分配Buffer時(shí)預(yù)留所有頭部和尾部區(qū)域，到各層通過(guò)填充相關(guān)信息，直到數(shù)據(jù)處理完畢，釋放所分配的內(nèi)存空間這種機(jī)制，將會(huì)有效提高系統(tǒng)的效率，如圖7所示：

圖7 內(nèi)存無(wú)拷貝方式

（3）發(fā)送數(shù)據(jù)包與接收數(shù)據(jù)包機(jī)制

當(dāng)有數(shù)據(jù)從應(yīng)用層或者硬件到達(dá)的時(shí)候，通常有兩種主要的策略：一種是通過(guò)周期性的查詢的方式，另一種是通過(guò)中斷或者事件觸發(fā)。采用查詢的方式可能會(huì)影響數(shù)據(jù)包的響應(yīng)速度，而采用中斷的方式將會(huì)打斷任務(wù)進(jìn)程。如果頻繁的中斷將會(huì)影響系統(tǒng)任務(wù)執(zhí)行的效率。

（4）LE實(shí)現(xiàn)框架

我們基于LE協(xié)議的實(shí)現(xiàn)，主要考慮協(xié)議移植方便，要求效率高，代碼層次清晰，設(shè)計(jì)了如下一種通信協(xié)議框架。這種協(xié)議框架是以狀態(tài)機(jī)推動(dòng)每層數(shù)據(jù)的處理與交互，各個(gè)模塊都有一個(gè)完備的狀態(tài)機(jī)實(shí)現(xiàn)，各模塊之間通過(guò)事件來(lái)相互通信。各個(gè)狀態(tài)機(jī)在一個(gè)任務(wù)里實(shí)現(xiàn)，從而減少了任務(wù)切換的開(kāi)銷。而 Buffer 的處理采用零拷貝的方式，通過(guò)分配預(yù)約資源對(duì) Buffer 加以管理和分配，從而減少了內(nèi)存拷貝占用CPU資源的開(kāi)銷。

對(duì)于主機(jī)端，協(xié)議的實(shí)現(xiàn)框架，如圖8所示：

圖8 主機(jī)端實(shí)現(xiàn)框架

通過(guò)各層的狀態(tài)機(jī)推動(dòng)系統(tǒng)的交互與運(yùn)行。

而對(duì)于LE控制器層的實(shí)現(xiàn)，可分為3層：HCI 層、鏈路層以及基帶層。協(xié)議框架，如圖9所示：

圖9 控制器端協(xié)議框架

HCI層提供了 HCI命令格式與各種命令分組，以及將事件通過(guò) HCI傳輸層發(fā)送給上層應(yīng)用程序。鏈路層相當(dāng)于標(biāo)準(zhǔn)藍(lán)牙中的鏈路管理層，對(duì)鏈路狀態(tài)機(jī)進(jìn)行維護(hù)，對(duì)鏈路信息進(jìn)行管理，是底層BLE的核心?；鶐又饕菍?duì)硬件資源進(jìn)行管理、調(diào)度。

主機(jī)控制器層對(duì)上層發(fā)下來(lái)的命令或者數(shù)據(jù)發(fā)送到鏈路層，鏈路層維護(hù)一個(gè)狀態(tài)機(jī)，根據(jù)當(dāng)前狀態(tài)以及事件信息確定與基帶層或者在本層進(jìn)行處理；而基帶層也維護(hù)了一個(gè)狀態(tài)機(jī)，根據(jù)收到的事件以及數(shù)據(jù)包做出正確的響應(yīng)。而對(duì)于基帶層數(shù)據(jù)包的發(fā)送和接收，通過(guò)中斷的方式，從而使數(shù)據(jù)包能夠得到及時(shí)的處理，而且由于基帶層和鏈路層狀態(tài)機(jī)都在一個(gè)任務(wù)中執(zhí)行，所以，中斷的加入也不會(huì)導(dǎo)致任務(wù)的處理受到很大的影響。

（5）有限狀態(tài)機(jī)

由于協(xié)議框架要求將各層抽象出一種狀態(tài)機(jī)，所以狀態(tài)機(jī)的實(shí)現(xiàn)決定了協(xié)議框架的好與壞。下面舉例討論一下?tīng)顟B(tài)機(jī)實(shí)現(xiàn)的基本方法：

先介紹兩個(gè)重要的狀態(tài)機(jī)實(shí)現(xiàn)的數(shù)據(jù)結(jié)構(gòu):

比如一個(gè)發(fā)送數(shù)據(jù)的狀態(tài)轉(zhuǎn)換圖，如圖10所示：

圖10 狀態(tài)轉(zhuǎn)換圖

初始狀態(tài)為STATE1，當(dāng)在此狀態(tài)接收到主機(jī)送來(lái)的數(shù)據(jù)包，系統(tǒng)將會(huì)執(zhí)行動(dòng)作Send_CurData, 發(fā)送當(dāng)前數(shù)據(jù)包，并且切換到STATE2狀態(tài)， 當(dāng)在STATE2狀態(tài)下， 系統(tǒng)接收到回應(yīng)的Ack, 發(fā)送下一個(gè)數(shù)據(jù)包，切換到STATE3狀態(tài)，如果在STATE3狀態(tài)下，接收到Ack確認(rèn), 并且沒(méi)有數(shù)據(jù)包發(fā)送，回到狀態(tài)STATE1狀態(tài)。

這張狀態(tài)圖對(duì)應(yīng)的表格為：

StateTypeTab StateTabForFSM[]= {/*CurState Event Action Return NextState */STATE1, Rx_data, SendCur, Reserved, STATE2 STATE2, RX_Ack, SendNext, Reserved, STATE3 STATE3, RX_Ack, Null, Reserved, STATE1 FsmType Fsm= {/* Start StateCount Pointer to FSM Table */STATE1, 3, StateTabForFSM

這樣狀態(tài)機(jī)就準(zhǔn)備好了，現(xiàn)在的工作就是實(shí)現(xiàn)操作函數(shù)，來(lái)使得行為連貫以及狀態(tài)機(jī)正確地遷移。具體到低能耗藍(lán)牙協(xié)議，就是給每層設(shè)計(jì)一個(gè)完整的狀態(tài)圖。代碼維護(hù)時(shí)對(duì)照狀態(tài)表格和狀態(tài)遷移圖，就會(huì)非常容易理解協(xié)議和查找問(wèn)題。

3 結(jié)論

通過(guò)對(duì)藍(lán)牙4.0低能耗部分無(wú)線通信技術(shù)原理的介紹和以及通信協(xié)議的實(shí)現(xiàn)方法，讀者可以了解LE協(xié)議的基本原理，以及分層架構(gòu)的通信協(xié)議實(shí)現(xiàn)的一般方法和應(yīng)對(duì)策略，從而為從事藍(lán)牙技術(shù)或者其他通信技術(shù)的協(xié)議的工作者提供一定的參考。由于篇幅所限，本文沒(méi)有對(duì)LE協(xié)議詳細(xì)實(shí)現(xiàn)做過(guò)多描述。

[1]Bluetooth SIG.Bluetooth Specification Version 4.0.2010,06

[2]Bluetooth SIG.Core Specification V2.1+EDR of Bluetooth Specification. 2007,7

[3]Henrik Lindbom, Jonas Wigstein. A portable protocol stack framework for embedded systems. 2000

[4]Robin Heydon. ULP 開(kāi)啟全新無(wú)線應(yīng)用.[j]電子設(shè)計(jì)應(yīng)用 2007

[5]羅瑋 一種新興的藍(lán)牙技術(shù)—超低功耗藍(lán)牙技術(shù)[j]現(xiàn)代電信科技 2010

[6]金純 編著. 超低功耗（ULP）藍(lán)牙技術(shù)規(guī)范解析. [M]國(guó)防工業(yè)出版社. 2010,5