藍(lán)牙協(xié)議分析(3)_藍(lán)牙低功耗(BLE)協(xié)議棧介紹

通過“藍(lán)牙協(xié)議分析(2)_協(xié)議架構(gòu)”的介紹，大家對(duì)藍(lán)牙協(xié)議棧應(yīng)該有了簡(jiǎn)單的了解，但是，肯定還有“似懂非懂、欲說還休”的感覺。有這種感覺太正常了，畢竟藍(lán)牙協(xié)議是一個(gè)歷史悠久又比較龐大的協(xié)議，沒那么容易理解。

因此，本文將換個(gè)視角，從協(xié)議棧設(shè)計(jì)者的角度，思考如下問題：

為什么會(huì)有藍(lán)牙協(xié)議棧（Why）？
怎樣實(shí)現(xiàn)藍(lán)牙協(xié)議棧（How）？
藍(lán)牙協(xié)議棧的最終樣子是什么（What）？

另外，我們知道，當(dāng)前的藍(lán)牙協(xié)議包含BR/EDR、AMP、LE三種技術(shù)，為了降低復(fù)雜度，本文將focus在現(xiàn)在比較熱門的BLE（Bluetooth Low Energy）技術(shù)上（物聯(lián)網(wǎng)嘛！），至于BR/EDR和AMP，觸類旁通即可。

“Why”要回答的其實(shí)是需求問題，對(duì)BLE（藍(lán)牙低功耗）來說，其需求包含兩個(gè)部分：和傳統(tǒng)藍(lán)牙重疊的部分；BLE特有的低功耗部分。大致總結(jié)如下：

基于2.4GHz ISM頻段的無線通信；
通信速率要求不高，但對(duì)功耗極為敏感；
盡量復(fù)用已有的BR/EDR技術(shù)；
組網(wǎng)方式自由靈活，既可以使用傳統(tǒng)藍(lán)牙所使用的“基于連接的星形網(wǎng)絡(luò)（由1個(gè)master和多個(gè)slave組成）”，也可以使用“無連接的網(wǎng)狀網(wǎng)絡(luò)（由多個(gè)advertiser和多個(gè)scanner組成）；
參與通信的設(shè)備的數(shù)量和種類眾多，要從應(yīng)用的角度考慮易于實(shí)現(xiàn)、互聯(lián)互通等特性；
有強(qiáng)烈的安全（security）需求；
等等。

“How”要回答的是設(shè)計(jì)思路，“What”是基于該思路設(shè)計(jì)出來的最終產(chǎn)品的樣子。

按理說，需要先介紹“How”，后介紹所產(chǎn)出的“What”。但以蝸蝸對(duì)藍(lán)牙的理解，顯然無法拋開“What”單獨(dú)回答“How”。所以，基于現(xiàn)有的協(xié)議框架（What），去理解背后的“How”，才是明智之舉。

開始之前，我們先總結(jié)一下BLE的協(xié)議框架，后面章節(jié)會(huì)根據(jù)該框架，采用自下向上的方法逐層分析介紹。

如下面圖片1所示，BLE的協(xié)議可分為Bluetooth Application和Bluetooth Core兩大部分，而Bluetooth Core又包含BLE Controller和BLE Host兩部分（有關(guān)概念可參考“藍(lán)牙協(xié)議分析(1)_基本概念”）。

任何一個(gè)通信系統(tǒng)，首先要確定的就是通信介質(zhì)（物理通道，Physical Channel），BLE也不例外。在BLE協(xié)議中，“通信介質(zhì)”的定義是由Physical Layer（其它通信協(xié)議也類似）負(fù)責(zé)。

Physical Layer是這樣描述BLE的通信介質(zhì)的：

由于BLE屬于無線通信，則其通信介質(zhì)是一定頻率范圍下的頻帶資源（Frequency Band）；
BLE的市場(chǎng)定位是個(gè)體和民用，因此使用免費(fèi)的ISM頻段（頻率范圍是2.400-2.4835 GHz）；
為了同時(shí)支持多個(gè)設(shè)備，將整個(gè)頻帶分為40份，每份的帶寬為2MHz，稱作RF Channel。

經(jīng)過上面的定義之后，BLE的物理通道已經(jīng)出來了，即“頻點(diǎn)分別是‘f=2402+k*2 MHz, k=0, … ,39’，帶寬為2MHz”的40個(gè)RF Channel。

除了物理通道之外，Physical Layer還需要定義RF收發(fā)雙方的一些其它特性，包括（不影響本文后續(xù)的討論，不用深究）：

RF****相關(guān)的特性（Transmitter Characteristics），包括****功率（Transmission power、調(diào)制方式（Modulation），高斯頻移鍵控（Gaussian Frequency Shift Keying ，GFSK）、Spurious Emissions、Radio Frequency Tolerance等等。（不影響本文后續(xù)的討論，不用深究）；
RF接收相關(guān)的特性（Receiver Characteristics），包括接收靈敏度等。

經(jīng)過Physical Layer的定義，通信所需的物理通道已經(jīng)okay了，即40個(gè)RF Channel（后面統(tǒng)一使用Physical Channel指代）。此時(shí)Link Layer可以粉墨登場(chǎng)了，它主要的功能，就是在這些Physical Channel上收發(fā)數(shù)據(jù)，與此同時(shí)，不可避免的需要控制RF收發(fā)相關(guān)的參數(shù)。但僅做這些，還遠(yuǎn)遠(yuǎn)不夠：

首先，Physical Layer僅僅提供了有限的40個(gè)Physical Channel，而BLE中參與通信的實(shí)體的數(shù)量，肯定不是這個(gè)數(shù)量級(jí)。Link Layer需要解決Physical Channel的共享問題；
其次，通信是兩個(gè)實(shí)體之間的事情，對(duì)這兩個(gè)實(shí)體來說，它們希望看到一條為自己獨(dú)享的傳輸通道（就是我們所熟悉的邏輯鏈路，Logical Link）。這也是Link Layer需要解決的；
再則，Physical Channel是不可靠的，任何數(shù)據(jù)傳輸都可能由于干擾等問題二損毀、丟失，這對(duì)有些應(yīng)用來說，是接受不了的。因此Link Layer需要提供校驗(yàn)、重傳等機(jī)制，確保數(shù)據(jù)傳輸?shù)目煽啃裕?
等等，等等，簡(jiǎn)直是既當(dāng)?shù)之?dāng)媽！

BLE系統(tǒng)只有有限的40個(gè)Physical Channel，怎么容納多個(gè)通信實(shí)體呢？說來也簡(jiǎn)單，Link Layer將BLE的通信場(chǎng)景分為兩類：

1） 數(shù)據(jù)量比較少、發(fā)送不頻繁、對(duì)時(shí)延不是很敏感的場(chǎng)景

例如一個(gè)傳感器節(jié)點(diǎn)（如溫度傳感器），需要定時(shí)（如1s）向處理中心發(fā)送傳感器數(shù)據(jù)（如溫度）。

針對(duì)這種場(chǎng)景，BLE的Link Layer采取了一種比較懶的處理方式----廣播通信：

從40個(gè)Physical Channel中選取3個(gè)，作為廣播通道（advertising channel）；
在廣播通道上，任何參與者，愛發(fā)就發(fā)，愛收就收，隨便；
所有參與者，共享同一個(gè)邏輯傳輸通道（廣播通道），之間的

當(dāng)然，這種方法存在很多問題，例如：

不可靠，是否會(huì)相互干擾？發(fā)送是否成功？不知道！
接收是否成功？不知道！
效率不高，如果同一區(qū)域有很多節(jié)點(diǎn)在廣播數(shù)據(jù)，某一個(gè)接收者是不是要接收所有的數(shù)據(jù)包，不管是不是它關(guān)心的？
安全問題，怎么解決？

確實(shí)，問題多多，不過Link Layer定義了一些策略，盡可能的提高了這種通信方式的便利性，后面我們會(huì)介紹。至于無法解決的，簡(jiǎn)單，兩種方案：

a）忍，廣播通信需要占用的資源實(shí)在太少了，正對(duì)物聯(lián)網(wǎng)中的那些小節(jié)點(diǎn)們的胃口啊。
b）使用基于連接的通信方式（就是給你倆建立一個(gè)專線），具體可參考下面5.2.2的介紹。

2）數(shù)據(jù)量較大、發(fā)送頻率較高、對(duì)時(shí)延較敏感的場(chǎng)景

BLE的Link Layer會(huì)從剩余的37個(gè)Physical Channel中，選取一個(gè)，為這種場(chǎng)景里面的通信雙方建立單獨(dú)的通道（data channel）。這就是連接（connection）的過程。

同時(shí)，為了增加容量，增大抗干擾能力，連接不會(huì)長(zhǎng)期使用一個(gè)固定的Physical Channel，而是在多個(gè)Channel（如37個(gè)）之間隨機(jī)但有規(guī)律的切換，這就是BLE的跳頻（Hopping）技術(shù)。

基于上面5.2小節(jié)的思路，BLE協(xié)議在Link Layer抽象出5種狀態(tài)：

注1：從橫向看，協(xié)議的每個(gè)層次（如這里的Link Layer）都可以當(dāng)做可相互通信的實(shí)體。這里的狀態(tài)，就是指這每一層實(shí)體的狀態(tài)。因此，在協(xié)議的多個(gè)層次上，都可能有狀態(tài)定義，甚至名字也一樣，我們閱讀協(xié)議棧的時(shí)候，一定要留意，不要被繞暈了。

? Standby State
? Advertising State
? Scanning State
? Initiating State
? Connection State

并以如下的狀態(tài)機(jī)進(jìn)行切換（設(shè)備在同一時(shí)刻只能處于這些狀態(tài)的一種）：

圖片2 Link Layer狀態(tài)機(jī)

Standby狀態(tài)是初始狀態(tài)，即不發(fā)送數(shù)據(jù)，也不接收數(shù)據(jù)。根據(jù)上層實(shí)體的命令（如位于host軟件中GAP），可由其它任何一種狀態(tài)進(jìn)入，也可以切換到除Connection狀態(tài)外的任意一種狀態(tài)。

Advertising狀態(tài)是可以通過廣播通道發(fā)送數(shù)據(jù)的狀態(tài)，由Standby狀態(tài)進(jìn)入。它廣播的數(shù)據(jù)可以由處于Scanning或者Initiating狀態(tài)的實(shí)體接收。上層實(shí)體可通過命令將Advertising狀態(tài)切換回Standby狀態(tài)。另外，連接成功后，也可切換為Connection狀態(tài)。

Scanning狀態(tài)是可以通過廣播通道接收數(shù)據(jù)的狀態(tài)，由Standby狀態(tài)進(jìn)入。根據(jù)Advertiser所廣播的數(shù)據(jù)的類型，有些Scanner還可以主動(dòng)向Advertiser請(qǐng)求一些額外數(shù)據(jù)。上層實(shí)體可通過命令將Scanning狀態(tài)切換回Standby狀態(tài)。

Initiating狀態(tài)和Scanning狀態(tài)類似，不過是一種特殊的接收狀態(tài)，由Standby狀態(tài)進(jìn)入，只能接收Advertiser廣播的connectable的數(shù)據(jù)，并在接收到數(shù)據(jù)后，發(fā)送連接請(qǐng)求，以便和Advertiser建立連接。當(dāng)連接成功后，Initiater和對(duì)應(yīng)的Advertiser都會(huì)切換到Connection狀態(tài)。

Connection狀態(tài)是和某個(gè)實(shí)體建立了單獨(dú)通道的狀態(tài)，在通道建立之后，由Initiating或者Advertising自動(dòng)切換而來。通道斷開后，會(huì)重新回到Standby狀態(tài)。

通道建立后（通常說“已連接”），處于Connection狀態(tài)的雙方，分別有兩種角色Master和Slave：

Initiater方稱作Mater；

Advertiser方稱作Slave。

狀態(tài)和角色定義完成后，剩下的事情就簡(jiǎn)單了，主要包括兩類：提供某一狀態(tài)下，和其它實(shí)體對(duì)應(yīng)狀態(tài)之間的數(shù)據(jù)交換機(jī)制；根據(jù)上層實(shí)體的指令，以及當(dāng)前的實(shí)際情況，負(fù)責(zé)狀態(tài)之間的切換。BLE協(xié)議中，這些事情是由一個(gè)叫做空中接口協(xié)議（Air Interface Protocol）的家伙負(fù)責(zé)，主要思路如下。

在BLE中，兩種類型的Physical Channel（advertising channel和data channel）統(tǒng)一使用一種packet format，如下：

Preamble(1 octet)    Access Address(4 octets)    PDU(2 to 257 octets)    CRC(3 octets)

關(guān)于packet format，我們可以關(guān)注如下內(nèi)容：

1）Access Address，用于識(shí)別。

2）PDU，BLE在Link Layer的PDU長(zhǎng)度最大為257 octets（不知道octets是神馬意思？當(dāng)做bytes就行了）。這決定了上層實(shí)體，如L2CAP、Application等，需要拆分、重組才能支持更大數(shù)據(jù)量的傳輸。

3）Link Layer總packet長(zhǎng)度是9~264bytes。

由5.3小節(jié)的描述，Link Layer有5種狀態(tài)，每種狀態(tài)下所傳輸數(shù)據(jù)的功能不盡相同，基于此，Air Interface Protocol定義出如下的PDU類型（這里只簡(jiǎn)單列舉一下，不深入討論）：

1）Advertising channel中Advertising有關(guān)的PDU

ADV_IND，Advertiser發(fā)送的、可被連接的、無方向的廣播數(shù)據(jù)（connectable undirected advertising event）。

ADV_DIRECT_IND，Advertiser發(fā)送的、可被連接的、單向廣播數(shù)據(jù)（connectable directed advertising event）。

ADV_NONCONN_IND，Advertiser發(fā)送的、不可被連接的、無方向的廣播數(shù)據(jù)（non-connectable undirected advertising event）。

ADV_SCAN_IND，Advertiser發(fā)送的、可接受SCAN_REQ請(qǐng)求的、無方向的廣播數(shù)據(jù)（scannable undirected advertising event）。

2）Advertising channel中Scanning有關(guān)的PDU

SCAN_REQ，Scanner發(fā)送的、向Advertiser請(qǐng)求額外信息的數(shù)據(jù)包（一般需要在收到ADV_SCAN_IND后才可發(fā)送）。

SCAN_RSP，Advertiser發(fā)送的、響應(yīng)SCAN_REQ請(qǐng)求的數(shù)據(jù)包。

3）Advertising channel中Initialing有關(guān)的PDU

CONNECT_REQ，Initiater發(fā)起的、請(qǐng)求建立連接的數(shù)據(jù)包。

4）Data channel中LL data有關(guān)的PDU

已連接的雙方進(jìn)行數(shù)據(jù)通信所用的PDU，有效的payload長(zhǎng)度為0~251bytes。

5）Data channel中LL control有關(guān)的PDU

用于管理、維護(hù)、更新已連接的數(shù)據(jù)通道的PDU，包括：

LL_CHANNEL_MAP_REQ，請(qǐng)求更改所使用的Physical Channel的數(shù)據(jù)包；

LL_TERMINATE_IND，告知對(duì)方此次連接即將結(jié)束，以及結(jié)束的原因；

等等。

主要針對(duì)廣播通道，因?yàn)殡S著通信設(shè)備的增多，空中的廣播數(shù)據(jù)將會(huì)呈幾何級(jí)的增長(zhǎng)，為了避免資源的浪費(fèi)（特別是BLE Host），有必要在Link Layer過濾掉一些數(shù)據(jù)包，例如根據(jù)藍(lán)牙地址，過濾掉不是給自己的packet。

上層軟件只需要定義一些參數(shù)，例如：

Advertising State下的Advertising Channel的選擇、Advertising的間隔、Advertising PDU的類型等；

Scanning State/Initialing State下的scanWindow、scanInterval等。

Link Layer將會(huì)自動(dòng)發(fā)送或者接收數(shù)據(jù)包。

具體不再詳細(xì)描述。

經(jīng)過Air Interface Protocol的抽象，BLE實(shí)體已經(jīng)具備廣播通信、點(diǎn)對(duì)點(diǎn)連接的建立和釋放、點(diǎn)對(duì)點(diǎn)通信等基本的能力。除此之外，Link Layer又抽象出來一個(gè)鏈路控制協(xié)議（Link Layer Control），用于管理、控制兩個(gè)Link Layer實(shí)體之間所建立的這個(gè)Connection，主要功能包括：

更新Connection相關(guān)的參數(shù)，如transmitWindowSize、transmitWindowOffset、connInterval等等（具體意義這里不再詳述）；

更新該連接所使用的跳頻圖譜（使用哪些Physical Channels）；

執(zhí)行鏈路加密（Encryption）有關(guān)的過程。

定義Host和Controller（通常是兩顆IC）之間的通信協(xié)議，可基于Uart、USB等物理介質(zhì)，對(duì)理解藍(lán)牙協(xié)議來說，是無關(guān)緊要的，這里暫不介紹。

經(jīng)過Link Layer的抽象之后，兩個(gè)BLE設(shè)備之間可存在兩條邏輯上的數(shù)據(jù)通道：一條是無連接的廣播通道，天高任鳥飛；另一條是基于連接的數(shù)據(jù)通道，是一個(gè)點(diǎn)對(duì)點(diǎn)（Master對(duì)Slave）的邏輯通道。

廣播通道暫且不表，這個(gè)數(shù)據(jù)通道（后面簡(jiǎn)稱邏輯通道，Logical Channel），要怎么使用，還需要一番思索，例如：

Logical Channel只有一條，而要利用它傳輸數(shù)據(jù)的上層應(yīng)用卻不止一個(gè)（例如圖片1中的ATT和SMP），怎么復(fù)用？

Logical Channel所能傳輸?shù)挠行ayload長(zhǎng)度最大只有251bytes，怎是否意味著上層應(yīng)用每次只能傳輸少于這個(gè)長(zhǎng)度的數(shù)據(jù)？（顯然不能?。?/p>

Logical Channel僅提供了簡(jiǎn)單的應(yīng)答和流控機(jī)制，如果傳輸?shù)臄?shù)據(jù)出錯(cuò)怎么辦？

等等…

以上問題，都是由L2CAP，一個(gè)介于應(yīng)用程序（Profile、Application等）和Link Layer之間的protocol，負(fù)責(zé)回答，這也是它的縮寫（Logical Link Control and Adaptation Protocol）的意義所在。它提供的功能主要包括：

Protocol/channel multiplexing，協(xié)議/通道的多路復(fù)用；

Segmentation and reassembly，上層應(yīng)用數(shù)據(jù)（L2CAP Service Data Units，SDUs）的分割（和重組），生成協(xié)議數(shù)據(jù)單元（L2CAP Packet Data Units，PDUs），以滿足用戶數(shù)據(jù)傳輸對(duì)延時(shí)的要求，并便于后續(xù)的重傳、流控等機(jī)制的實(shí)現(xiàn)；

Flow control per L2CAP channel，基于L2CAP Channel的流控機(jī)制；

Error control and retransmissions，錯(cuò)誤控制和重傳機(jī)制；

Support for Streaming，支持流式傳輸（如音頻、視頻等，不需要重傳或者只需要有限重傳）；

Fragmentation and Recombination，協(xié)議數(shù)據(jù)單元（PDUs）的分片（和重組），生成符合Link Layer傳輸要求的數(shù)據(jù)片（長(zhǎng)度不超過251，具體可參考5.4.1中有關(guān)的介紹）；

Quality of Service，QoS的支持。

鑒于篇幅問題，本文重點(diǎn)介紹有利用理解上層協(xié)議（ATT、GATT等）的“Protocol/channel multiplexing”功能，其它部分會(huì)在后續(xù)L2CAP的分析文章中重點(diǎn)說明。

所謂的multiplexing（多路復(fù)用），還是很好理解的：

可用于傳輸用戶數(shù)據(jù)的邏輯鏈路只有一條，而L2CAP需要服務(wù)的上層Profile和Application的數(shù)目，肯定遠(yuǎn)不止這個(gè)數(shù)量。因此，需要使用多路復(fù)用的手段，將這些用戶數(shù)據(jù)map到有限的鏈路資源上去。

至于multiplexing的手段，簡(jiǎn)單又直接（稱的上“協(xié)議”的標(biāo)配）：

數(shù)據(jù)發(fā)送時(shí)，將用戶數(shù)據(jù)分割為一定長(zhǎng)度的數(shù)據(jù)包（L2CAP Packet Data Units，PDUs），加上一個(gè)包含特定“ID”的header后，通過邏輯鏈路發(fā)送出去。

數(shù)據(jù)接收時(shí)，從邏輯鏈路接收數(shù)據(jù)，解析其中的“ID”，并以此判斷需要將數(shù)據(jù)轉(zhuǎn)發(fā)給哪個(gè)應(yīng)用。

這里所說的ID，就是多路復(fù)用的手段，L2CAP提供兩種復(fù)用手段：

這里的連接，是指基于L2CAP的應(yīng)用程序，在通信之前，先建立一個(gè)基于Logical Channel的虛擬通道（稱作L2CAP channel，和TCP/IP中的端口類似）。L2CAP會(huì)為這個(gè)通道分配一個(gè)編號(hào)，稱作channel ID（簡(jiǎn)稱CID）。

L2CAP channel建立之后，就可以把CID放到數(shù)據(jù)包的header中，以達(dá)到multiplexing的目的。這些基于CID實(shí)現(xiàn)的多路復(fù)用，就稱作channel multiplexing（基于通道的多路復(fù)用）。

那CID是怎么確定的呢？有一些固定用途的L2CAP Channel，其CID是固定值，另外一些則是動(dòng)態(tài)分配的，具體如下：

圖片3 BLE CID分配

有關(guān)CID的具體數(shù)值可參考：Core_v4.2.pdf, Volume 3, Part A - Logical Link Control and Adaptation Protocol Specification

另外，為了提高數(shù)據(jù)傳輸?shù)男?，方便廣播通信等應(yīng)用場(chǎng)景，L2CAP在提供基于連接的通信機(jī)制之外，也提供了無連接的數(shù)據(jù)傳輸方法?；谶@種方法，CID不存在了，取而代之的是一個(gè)稱作Protocol/Service Multiplexer(PSM)的字段。

這種多路復(fù)用的手段則成為Protocol multiplexing（基于協(xié)議的多路復(fù)用）。

由于Protocol multiplexing只允許在BR/EDR controller中使用，本文就不再詳細(xì)介紹了。

由上面章節(jié)的描述可知，在BLE協(xié)議棧中：Physical Layer負(fù)責(zé)提供一系列的Physical Channel；基于這些Physical Channel，Link Layer可在兩個(gè)設(shè)備之間建立用于點(diǎn)對(duì)點(diǎn)通信的Logical Channel；而L2CAP則將這個(gè)Logical Channel換分為一個(gè)個(gè)的L2CAP Channel，以便提供應(yīng)用程序級(jí)別的通道復(fù)用。到此之后，基本協(xié)議棧已經(jīng)構(gòu)建完畢，應(yīng)用程序已經(jīng)可以基于L2CAP歡快的run起來了。

談起應(yīng)用程序，就不得不說BLE的初衷----物聯(lián)網(wǎng)。物聯(lián)網(wǎng)中傳輸?shù)臄?shù)據(jù)和傳統(tǒng)的互聯(lián)網(wǎng)有什么區(qū)別呢？拋開其它不談，物聯(lián)網(wǎng)中最重要、最廣泛的一類應(yīng)用是：信息的采集。

這些信息往往都很簡(jiǎn)單，如溫度、濕度、速度、位置信息、電量、水壓、等等。

采集的過程也很簡(jiǎn)單，節(jié)點(diǎn)設(shè)備定時(shí)的向中心設(shè)備匯報(bào)信息數(shù)據(jù)，或者，中心設(shè)備在需要的時(shí)候主動(dòng)查詢。

基于信息采集的需求，BLE抽象出一個(gè)協(xié)議：Attribute protocol，該協(xié)議將這些“信息”以“Attribute（屬性）”的形式抽象出來，并提供一些方法，供遠(yuǎn)端設(shè)備（remote device）讀取、修改這些屬性的值（Attribute value）。

Attribute Protocol的主要思路包括：

1）基于L2CAP，使用固定的Channel ID（0x004，具體可參考“圖片3”）。

2）采用client-server的形式。提供信息（以后都稱作Attribute）的一方稱作ATT server（一般是那些傳感器節(jié)點(diǎn)），訪問信息的一方稱作ATT client。

3）一個(gè)Attribute由Attribute Type、Attribute Handle和Attribute Value組成。

Attribute Type用于標(biāo)示Attribute的類型，類似于我們常說的“溫度”、“濕度”等人類可識(shí)別的術(shù)語，不過與人類術(shù)語不同的是，Attribute Type使用UUID（Universally Unique IDentifier，16-bit、32-bit或者128-bit的數(shù)值）區(qū)分。

Attribute Handle是一個(gè)16-bit的數(shù)值，用作唯一識(shí)別Attribute server上的所有Attribute。Attribute Handle的存在有如下意義：
        a）一個(gè)server上可能存在多個(gè)相同type的Attribute，顯然，client有區(qū)分這些Attribute的需要。
        b）同一類型的多個(gè)Attribute，可以組成一個(gè)Group，client可以通過這個(gè)Group中的起、始handle訪問所有的Attributes。

Attribute Value代表Attribute的值，可以是任何固定長(zhǎng)度或者可變長(zhǎng)度的octet array（理解為字節(jié)類型的數(shù)組即可）。

4）Attribute可以定義一些權(quán)限（Permissions），以便server控制client的訪問行為，包括：

訪問有關(guān)的權(quán)限（access permissions），Readable、Writeable以及Readable and writable；

加密有關(guān)的權(quán)限（encryption permissions），Encryption required和No encryption required；

認(rèn)證有關(guān)的權(quán)限（authentication permissions），Authentication Required和No Authentication Required；

授權(quán)有關(guān)的權(quán)限（authorization permissions），Authorization Required和No Authorization Required。

5）根據(jù)所定義的Attribute PDU的不同，client可以對(duì)server有多種訪問方式，包括：

Find Information，獲取Attribute type和Attribute Handle的對(duì)應(yīng)關(guān)系；

Reading Attributes，有Read by type、Read by handle、Read by blob（只讀取部分信息）、Read Multiple（讀取多個(gè)handle的value）等方式；

Writing Attributes，包括需要應(yīng)答的writing、不需要應(yīng)答的writing等。

ATT之所以稱作“protocol”，是因?yàn)樗€比較抽象，僅僅定義了一套機(jī)制，允許client和server通過Attribute的形式共享信息。而具體共享哪些信息，ATT并不關(guān)心，這是GATT（Generic Attribute Profile）的主場(chǎng)。

GATT相對(duì)ATT只多了一個(gè)‘G‘，但含義卻大不同，因?yàn)镚ATT是一個(gè)profile（更準(zhǔn)確的說是profile framework）。

在藍(lán)牙協(xié)議中，profile一直是一個(gè)比較抽象的概念，我們可以將其理解為“應(yīng)用場(chǎng)景、功能、使用方式”都被規(guī)定好的Application。傳統(tǒng)的BR/EDR如此，BLE更甚。上面我們講過，BLE很大一部分的應(yīng)用場(chǎng)景是信息（Attribute）的共享，因此，BLE協(xié)議棧基于Attribute Protocol，定義了一個(gè)稱作GATT（Generic Attribute）的profile framework（它本身也是一個(gè)profile），用于提供通用的、信息的存儲(chǔ)和共享等功能。

作為一個(gè)Profile framework，GATT profile提出了如下的層次結(jié)構(gòu)：

圖片4 GATT Profile hierarchy

由上面圖片可知，GATT profile的層次結(jié)構(gòu)依次是：Profile—>Service—>characteristic。

“Profile”是基于GATT所派生出的真正的Profile，位于GATT Profile hierarchy的最頂層，由一個(gè)或者多個(gè)和某一應(yīng)用場(chǎng)景有關(guān)的Service組成。

一個(gè)Service包含一個(gè)或者多個(gè)Characteristic（特征），也可以通過Include的方式，包含其它Service。

Characteristic則是GATT profile中最基本的數(shù)據(jù)單位，由一個(gè)Properties、一個(gè)Value、一個(gè)或者多個(gè)Descriptor組成。

Characteristic Properties定義了characteristic的Value如何被使用，以及characteristic的Descriptor如何被訪問。

Characteristic Value是特征的實(shí)際值，例如一個(gè)溫度特征，其Characteristic Value就是溫度值就。

Characteristic Descriptor則保存了一些和Characteristic Value相關(guān)的信息（比較抽象，后續(xù)文章會(huì)根據(jù)實(shí)例做進(jìn)一步的理解）。

以上除“Profile”外的每一個(gè)定義，Service、Characteristic、Characteristic Properties、Characteristic Value、Characteristic Descriptor等等，都是作為一個(gè)Attribute存在的，具備第8章所描述的Attribute的所有特征：Attribute
Handle、Attribute Types、Attribute Value和AttributePermissions。

藍(lán)牙4.0之后所引入的GATT profile，是一個(gè)非常有“心計(jì)”的profile，其中有三點(diǎn)，需要我們重點(diǎn)關(guān)注：

1）基于GATT架構(gòu)，Application的存在形式，不再是單一的Profile，很多簡(jiǎn)單的應(yīng)用場(chǎng)景，可以直接以Service的形式存在（profile的概念隱藏在了GATT中），這大大簡(jiǎn)化了一些傳感器節(jié)點(diǎn)的設(shè)計(jì)復(fù)雜度。

2）仔細(xì)瞅一下圖片4中的Service，然后回憶一下藍(lán)牙BR/EDR中的服務(wù)發(fā)現(xiàn)協(xié)議（Service Discover Protocol，SDP）中的“Service”，是否有什么關(guān)聯(lián)？你猜對(duì)了，非常有關(guān)聯(lián)，在存在GATT的實(shí)現(xiàn)中，SDP就沒有存在的必要了。Service也是一個(gè)普通的Generic Attribute。也正是因?yàn)檫@樣的抽象，才使得以往藍(lán)牙協(xié)議中的“Service”實(shí)例化了。

3）所謂的“Service”實(shí)例化，指的是，任何一個(gè)profile，都是由service和對(duì)應(yīng)的profile功能組成。

Security Manager負(fù)責(zé)BLE通信中有關(guān)安全的內(nèi)容（毫無疑問，在物聯(lián)網(wǎng)時(shí)代，安全變得更重要，誰也不想臥室的燈在深夜的時(shí)候會(huì)無緣無故的亮吧），包括配對(duì)（pairing,）、認(rèn)證（authentication）和加密（encryption）等過程。

該部分的內(nèi)容比較獨(dú)立，這里先不過多介紹，后面會(huì)有單獨(dú)的分析文章。

上面7到10章的內(nèi)容，都是和基于連接的data channel有關(guān)，至于無連接的advertising channel，以及連接建立的過程，好像被我們忽略了。雖然Link Layer已經(jīng)做出了定義（具體可參考第5章的介紹），但它們并沒有體現(xiàn)到Application（或者Profile）層面，畢竟Link layer太底層了。

因此，BLE協(xié)議棧定義了一個(gè)稱作Generic Access（通用訪問）的profile，以實(shí)現(xiàn)如下功能：

1）定義GAP層的藍(lán)牙設(shè)備角色（role）

和5.3中的Link Layer的role類似，只不過GAP層的role更接近用戶（可以等同于從用戶的角度看到的藍(lán)牙設(shè)備的role），包括：

Broadcaster Role，設(shè)備正在發(fā)送advertising events；

Observer Role，設(shè)備正在接收advertising events；

Peripheral Role，設(shè)備接受Link Layer連接（對(duì)應(yīng)Link Layer的slave角色）；

Central Role，設(shè)備發(fā)起Link Layer連接（對(duì)應(yīng)Link Layer的master角色）。

2）定義GAP層的、用于實(shí)現(xiàn)各種通信的操作模式（Operational Mode）和過程（Procedures），包括：

Broadcast mode and observation procedure，實(shí)現(xiàn)單向的、無連接的通信方式；

Discovery modes and procedures，實(shí)現(xiàn)藍(lán)牙設(shè)備的發(fā)現(xiàn)操作；

Connection modes and procedures，實(shí)現(xiàn)藍(lán)牙設(shè)備的連接操作；

Bonding modes and procedures，實(shí)現(xiàn)藍(lán)牙設(shè)備的配對(duì)操作。

3）定義User Interface有關(guān)的藍(lán)牙參數(shù)，包括：

藍(lán)牙地址（Bluetooth Device Address）；

藍(lán)牙名稱（Bluetooth Device Name）；

藍(lán)牙的pincode（Bluetooth Passkey）；

藍(lán)牙的class（Class of Device，和****功率有關(guān)）；

等等。

4）Security有關(guān)的定義，暫不介紹

暫不介紹了，后續(xù)其它文章會(huì)結(jié)合某些Profile及應(yīng)用場(chǎng)景的室例，作進(jìn)一步分析。

原創(chuàng)文章，轉(zhuǎn)發(fā)請(qǐng)注明出處。蝸窩科技，www.wowotech.net。

.

http://www.wowotech.net/bluetooth/ble_stack_overview.html