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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

首先，Physical Layer僅僅提供了有限的40個(gè)Physical Channel，而B(niǎo)LE中參與通信的實(shí)體的數量，肯定不是這個(gè)數量級。Link Layer需要解決Physical Channel的共享問(wèn)題；
其次，通信是兩個(gè)實(shí)體之間的事情，對這兩個(gè)實(shí)體來(lái)說(shuō)，它們希望看到一條為自己獨享的傳輸通道（就是我們所熟悉的邏輯鏈路，Logical Link）。這也是Link Layer需要解決的；
再則，Physical Channel是不可靠的，任何數據傳輸都可能由于干擾等問(wèn)題二損毀、丟失，這對有些應用來(lái)說(shuō)，是接受不了的。因此Link Layer需要提供校驗、重傳等機制，確保數據傳輸的可靠性；
等等，等等，簡(jiǎn)直是既當爹又當媽?zhuān)?/pre>5.2 怎么解決Physical Channel的共享問(wèn)題
BLE系統只有有限的40個(gè)Physical Channel，怎么容納多個(gè)通信實(shí)體呢？說(shuō)來(lái)也簡(jiǎn)單，Link Layer將BLE的通信場(chǎng)景分為兩類(lèi)：
1） 數據量比較少、發(fā)送不頻繁、對時(shí)延不是很敏感的場(chǎng)景
例如一個(gè)傳感器節點(diǎn)（如溫度傳感器），需要定時(shí)（如1s）向處理中心發(fā)送傳感器數據（如溫度）。
針對這種場(chǎng)景，BLE的Link Layer采取了一種比較懶的處理方式----廣播通信：
從40個(gè)Physical Channel中選取3個(gè)，作為廣播通道（advertising channel）；
在廣播通道上，任何參與者，愛(ài)發(fā)就發(fā)，愛(ài)收就收，隨便；
所有參與者，共享同一個(gè)邏輯傳輸通道（廣播通道），之間的
當然，這種方法存在很多問(wèn)題，例如：
不可靠，是否會(huì )相互干擾？發(fā)送是否成功？不知道！
接收是否成功？不知道！
效率不高，如果同一區域有很多節點(diǎn)在廣播數據，某一個(gè)接收者是不是要接收所有的數據包，不管是不是它關(guān)心的？
安全問(wèn)題，怎么解決？
確實(shí)，問(wèn)題多多，不過(guò)Link Layer定義了一些策略，盡可能的提高了這種通信方式的便利性，后面我們會(huì )介紹。至于無(wú)法解決的，簡(jiǎn)單，兩種方案：
a）忍，廣播通信需要占用的資源實(shí)在太少了，正對物聯(lián)網(wǎng)中的那些小節點(diǎn)們的胃口啊。
b）使用基于連接的通信方式（就是給你倆建立一個(gè)專(zhuān)線(xiàn)），具體可參考下面5.2.2的介紹。

2）數據量較大、發(fā)送頻率較高、對時(shí)延較敏感的場(chǎng)景
BLE的Link Layer會(huì )從剩余的37個(gè)Physical Channel中，選取一個(gè)，為這種場(chǎng)景里面的通信雙方建立單獨的通道（data channel）。這就是連接（connection）的過(guò)程。
同時(shí)，為了增加容量，增大抗干擾能力，連接不會(huì )長(cháng)期使用一個(gè)固定的Physical Channel，而是在多個(gè)Channel（如37個(gè)）之間隨機但有規律的切換，這就是BLE的跳頻（Hopping）技術(shù)。

5.3 狀態(tài)（state）和角色（role）的定義
基于上面5.2小節的思路，BLE協(xié)議在Link Layer抽象出5種狀態(tài)：
注1：從橫向看，協(xié)議的每個(gè)層次（如這里的Link Layer）都可以當做可相互通信的實(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ìn)行切換（設備在同一時(shí)刻只能處于這些狀態(tài)的一種）：
圖片2 Link Layer狀態(tài)機
Standby狀態(tài)是初始狀態(tài)，即不發(fā)送數據，也不接收數據。根據上層實(shí)體的命令（如位于host軟件中GAP），可由其它任何一種狀態(tài)進(jìn)入，也可以切換到除Connection狀態(tài)外的任意一種狀態(tài)。
Advertising狀態(tài)是可以通過(guò)廣播通道發(fā)送數據的狀態(tài)，由Standby狀態(tài)進(jìn)入。它廣播的數據可以由處于Scanning或者Initiating狀態(tài)的實(shí)體接收。上層實(shí)體可通過(guò)命令將Advertising狀態(tài)切換回Standby狀態(tài)。另外，連接成功后，也可切換為Connection狀態(tài)。
Scanning狀態(tài)是可以通過(guò)廣播通道接收數據的狀態(tài)，由Standby狀態(tài)進(jìn)入。根據Advertiser所廣播的數據的類(lèi)型，有些Scanner還可以主動(dòng)向Advertiser請求一些額外數據。上層實(shí)體可通過(guò)命令將Scanning狀態(tài)切換回Standby狀態(tài)。
Initiating狀態(tài)和Scanning狀態(tài)類(lèi)似，不過(guò)是一種特殊的接收狀態(tài)，由Standby狀態(tài)進(jìn)入，只能接收Advertiser廣播的connectable的數據，并在接收到數據后，發(fā)送連接請求，以便和Advertiser建立連接。當連接成功后，Initiater和對應的Advertiser都會(huì )切換到Connection狀態(tài)。
Connection狀態(tài)是和某個(gè)實(shí)體建立了單獨通道的狀態(tài)，在通道建立之后，由Initiating或者Advertising自動(dòng)切換而來(lái)。通道斷開(kāi)后，會(huì )重新回到Standby狀態(tài)。
通道建立后（通常說(shuō)“已連接”），處于Connection狀態(tài)的雙方，分別有兩種角色Master和Slave：
Initiater方稱(chēng)作Mater；
Advertiser方稱(chēng)作Slave。
5.4 Air Interface Protocol
狀態(tài)和角色定義完成后，剩下的事情就簡(jiǎn)單了，主要包括兩類(lèi)：提供某一狀態(tài)下，和其它實(shí)體對應狀態(tài)之間的數據交換機制；根據上層實(shí)體的指令，以及當前的實(shí)際情況，負責狀態(tài)之間的切換。BLE協(xié)議中，這些事情是由一個(gè)叫做空中接口協(xié)議（Air Interface Protocol）的家伙負責，主要思路如下。
5.4.1 定義在Physical Channel上收發(fā)的數據包的格式（packet format）
在BLE中，兩種類(lèi)型的Physical Channel（advertising channel和data channel）統一使用一種packet format，如下：
Preamble(1 octet)    Access Address(4 octets)    PDU(2 to 257 octets)    CRC(3 octets)
關(guān)于packet format，我們可以關(guān)注如下內容：
1）Access Address，用于識別。
2）PDU，BLE在Link Layer的PDU長(cháng)度最大為257 octets（不知道octets是神馬意思？當做bytes就行了）。這決定了上層實(shí)體，如L2CAP、Application等，需要拆分、重組才能支持更大數據量的傳輸。
3）Link Layer總packet長(cháng)度是9~264bytes。
5.4.2 定義不同類(lèi)型的PDU及其格式
由5.3小節的描述，Link Layer有5種狀態(tài)，每種狀態(tài)下所傳輸數據的功能不盡相同，基于此，Air Interface Protocol定義出如下的PDU類(lèi)型（這里只簡(jiǎn)單列舉一下，不深入討論）：
1）Advertising channel中Advertising有關(guān)的PDU
ADV_IND，Advertiser發(fā)送的、可被連接的、無(wú)方向的廣播數據（connectable undirected advertising event）。
ADV_DIRECT_IND，Advertiser發(fā)送的、可被連接的、單向廣播數據（connectable directed advertising event）。
ADV_NONCONN_IND，Advertiser發(fā)送的、不可被連接的、無(wú)方向的廣播數據（non-connectable undirected advertising event）。
ADV_SCAN_IND，Advertiser發(fā)送的、可接受SCAN_REQ請求的、無(wú)方向的廣播數據（scannable undirected advertising event）。
2）Advertising channel中Scanning有關(guān)的PDU
SCAN_REQ，Scanner發(fā)送的、向Advertiser請求額外信息的數據包（一般需要在收到ADV_SCAN_IND后才可發(fā)送）。
SCAN_RSP，Advertiser發(fā)送的、響應SCAN_REQ請求的數據包。
3）Advertising channel中Initialing有關(guān)的PDU
CONNECT_REQ，Initiater發(fā)起的、請求建立連接的數據包。
4）Data channel中LL data有關(guān)的PDU
已連接的雙方進(jìn)行數據通信所用的PDU，有效的payload長(cháng)度為0~251bytes。
5）Data channel中LL control有關(guān)的PDU
用于管理、維護、更新已連接的數據通道的PDU，包括：
LL_CHANNEL_MAP_REQ，請求更改所使用的Physical Channel的數據包；
LL_TERMINATE_IND，告知對方此次連接即將結束，以及結束的原因；
等等。
5.4.3 以白名單（White List）的形式定義Link Layer的數據過(guò)濾機制
主要針對廣播通道，因為隨著(zhù)通信設備的增多，空中的廣播數據將會(huì )呈幾何級的增長(cháng)，為了避免資源的浪費（特別是BLE Host），有必要在Link Layer過(guò)濾掉一些數據包，例如根據藍牙地址，過(guò)濾掉不是給自己的packet。
5.4.4 執行廣播通道上實(shí)際的packet收發(fā)操作
上層軟件只需要定義一些參數，例如：
Advertising State下的Advertising Channel的選擇、Advertising的間隔、Advertising PDU的類(lèi)型等；
Scanning State/Initialing State下的scanWindow、scanInterval等。
Link Layer將會(huì )自動(dòng)發(fā)送或者接收數據包。
5.4.5 定義連接建立的方式及過(guò)之后的應答、流控等機制
具體不再詳細描述。
5.5 Link Layer Control
經(jīng)過(guò)Air Interface Protocol的抽象，BLE實(shí)體已經(jīng)具備廣播通信、點(diǎn)對點(diǎn)連接的建立和釋放、點(diǎn)對點(diǎn)通信等基本的能力。除此之外，Link Layer又抽象出來(lái)一個(gè)鏈路控制協(xié)議（Link Layer Control），用于管理、控制兩個(gè)Link Layer實(shí)體之間所建立的這個(gè)Connection，主要功能包括：
更新Connection相關(guān)的參數，如transmitWindowSize、transmitWindowOffset、connInterval等等（具體意義這里不再詳述）；
更新該連接所使用的跳頻圖譜（使用哪些Physical Channels）；
執行鏈路加密（Encryption）有關(guān)的過(guò)程。
6. HCI
定義Host和Controller（通常是兩顆IC）之間的通信協(xié)議，可基于Uart、USB等物理介質(zhì)，對理解藍牙協(xié)議來(lái)說(shuō)，是無(wú)關(guān)緊要的，這里暫不介紹。
7. L2CAP Protocol7.1 功能介紹
經(jīng)過(guò)Link Layer的抽象之后，兩個(gè)BLE設備之間可存在兩條邏輯上的數據通道：一條是無(wú)連接的廣播通道，天高任鳥(niǎo)飛；另一條是基于連接的數據通道，是一個(gè)點(diǎn)對點(diǎn)（Master對Slave）的邏輯通道。
廣播通道暫且不表，這個(gè)數據通道（后面簡(jiǎn)稱(chēng)邏輯通道，Logical Channel），要怎么使用，還需要一番思索，例如：
Logical Channel只有一條，而要利用它傳輸數據的上層應用卻不止一個(gè)（例如圖片1中的ATT和SMP），怎么復用？
Logical Channel所能傳輸的有效payload長(cháng)度最大只有251bytes，怎是否意味著(zhù)上層應用每次只能傳輸少于這個(gè)長(cháng)度的數據？（顯然不能?。?/p>
Logical Channel僅提供了簡(jiǎn)單的應答和流控機制，如果傳輸的數據出錯怎么辦？
等等…
以上問(wèn)題，都是由L2CAP，一個(gè)介于應用程序（Profile、Application等）和Link Layer之間的protocol，負責回答，這也是它的縮寫(xiě)（Logical Link Control and Adaptation Protocol）的意義所在。它提供的功能主要包括：
Protocol/channel multiplexing，協(xié)議/通道的多路復用；
Segmentation and reassembly，上層應用數據（L2CAP Service Data Units，SDUs）的分割（和重組），生成協(xié)議數據單元（L2CAP Packet Data Units，PDUs），以滿(mǎn)足用戶(hù)數據傳輸對延時(shí)的要求，并便于后續的重傳、流控等機制的實(shí)現；
Flow control per L2CAP channel，基于L2CAP Channel的流控機制；
Error control and retransmissions，錯誤控制和重傳機制；
Support for Streaming，支持流式傳輸（如音頻、視頻等，不需要重傳或者只需要有限重傳）；
Fragmentation and Recombination，協(xié)議數據單元（PDUs）的分片（和重組），生成符合Link Layer傳輸要求的數據片（長(cháng)度不超過(guò)251，具體可參考5.4.1中有關(guān)的介紹）；
Quality of Service，QoS的支持。
鑒于篇幅問(wèn)題，本文重點(diǎn)介紹有利用理解上層協(xié)議（ATT、GATT等）的“Protocol/channel multiplexing”功能，其它部分會(huì )在后續L2CAP的分析文章中重點(diǎn)說(shuō)明。
7.2 Protocol/channel multiplexing
所謂的multiplexing（多路復用），還是很好理解的：
可用于傳輸用戶(hù)數據的邏輯鏈路只有一條，而L2CAP需要服務(wù)的上層Profile和Application的數目，肯定遠不止這個(gè)數量。因此，需要使用多路復用的手段，將這些用戶(hù)數據map到有限的鏈路資源上去。
至于multiplexing的手段，簡(jiǎn)單又直接（稱(chēng)的上“協(xié)議”的標配）：
數據發(fā)送時(shí)，將用戶(hù)數據分割為一定長(cháng)度的數據包（L2CAP Packet Data Units，PDUs），加上一個(gè)包含特定“ID”的header后，通過(guò)邏輯鏈路發(fā)送出去。
數據接收時(shí)，從邏輯鏈路接收數據，解析其中的“ID”，并以此判斷需要將數據轉發(fā)給哪個(gè)應用。
這里所說(shuō)的ID，就是多路復用的手段，L2CAP提供兩種復用手段：
7.2.1 基于連接的方法（這里的連接為L(cháng)2CAP connection，不要和Link Layer的connection混淆了）
這里的連接，是指基于L2CAP的應用程序，在通信之前，先建立一個(gè)基于Logical Channel的虛擬通道（稱(chēng)作L2CAP channel，和TCP/IP中的端口類(lèi)似）。L2CAP會(huì )為這個(gè)通道分配一個(gè)編號，稱(chēng)作channel ID（簡(jiǎn)稱(chēng)CID）。
L2CAP channel建立之后，就可以把CID放到數據包的header中，以達到multiplexing的目的。這些基于CID實(shí)現的多路復用，就稱(chēng)作channel multiplexing（基于通道的多路復用）。
那CID是怎么確定的呢？有一些固定用途的L2CAP Channel，其CID是固定值，另外一些則是動(dòng)態(tài)分配的，具體如下：
圖片3 BLE CID分配
有關(guān)CID的具體數值可參考：Core_v4.2.pdf, Volume 3, Part A - Logical Link Control and Adaptation Protocol Specification
7.2.2 無(wú)連接的方法
另外，為了提高數據傳輸的效率，方便廣播通信等應用場(chǎng)景，L2CAP在提供基于連接的通信機制之外，也提供了無(wú)連接的數據傳輸方法?；谶@種方法，CID不存在了，取而代之的是一個(gè)稱(chēng)作Protocol/Service Multiplexer(PSM)的字段。
這種多路復用的手段則成為Protocol multiplexing（基于協(xié)議的多路復用）。
由于Protocol multiplexing只允許在BR/EDR controller中使用，本文就不再詳細介紹了。
8. Attribute Protocol
由上面章節的描述可知，在BLE協(xié)議棧中：Physical Layer負責提供一系列的Physical Channel；基于這些Physical Channel，Link Layer可在兩個(gè)設備之間建立用于點(diǎn)對點(diǎn)通信的Logical Channel；而L2CAP則將這個(gè)Logical Channel換分為一個(gè)個(gè)的L2CAP Channel，以便提供應用程序級別的通道復用。到此之后，基本協(xié)議棧已經(jīng)構建完畢，應用程序已經(jīng)可以基于L2CAP歡快的run起來(lái)了。
談起應用程序，就不得不說(shuō)BLE的初衷----物聯(lián)網(wǎng)。物聯(lián)網(wǎng)中傳輸的數據和傳統的互聯(lián)網(wǎng)有什么區別呢？拋開(kāi)其它不談，物聯(lián)網(wǎng)中最重要、最廣泛的一類(lèi)應用是：信息的采集。
這些信息往往都很簡(jiǎn)單，如溫度、濕度、速度、位置信息、電量、水壓、等等。
采集的過(guò)程也很簡(jiǎn)單，節點(diǎn)設備定時(shí)的向中心設備匯報信息數據，或者，中心設備在需要的時(shí)候主動(dòng)查詢(xún)。
基于信息采集的需求，BLE抽象出一個(gè)協(xié)議：Attribute protocol，該協(xié)議將這些“信息”以“Attribute（屬性）”的形式抽象出來(lái)，并提供一些方法，供遠端設備（remote device）讀取、修改這些屬性的值（Attribute value）。
Attribute Protocol的主要思路包括：
1）基于L2CAP，使用固定的Channel ID（0x004，具體可參考“圖片3”）。
2）采用client-server的形式。提供信息（以后都稱(chēng)作Attribute）的一方稱(chēng)作ATT server（一般是那些傳感器節點(diǎn)），訪(fǎng)問(wèn)信息的一方稱(chēng)作ATT client。
3）一個(gè)Attribute由Attribute Type、Attribute Handle和Attribute Value組成。
Attribute Type用于標示Attribute的類(lèi)型，類(lèi)似于我們常說(shuō)的“溫度”、“濕度”等人類(lèi)可識別的術(shù)語(yǔ)，不過(guò)與人類(lèi)術(shù)語(yǔ)不同的是，Attribute Type使用UUID（Universally Unique IDentifier，16-bit、32-bit或者128-bit的數值）區分。
Attribute Handle是一個(gè)16-bit的數值，用作唯一識別Attribute server上的所有Attribute。Attribute Handle的存在有如下意義：
        a）一個(gè)server上可能存在多個(gè)相同type的Attribute，顯然，client有區分這些Attribute的需要。
        b）同一類(lèi)型的多個(gè)Attribute，可以組成一個(gè)Group，client可以通過(guò)這個(gè)Group中的起、始handle訪(fǎng)問(wèn)所有的Attributes。
Attribute Value代表Attribute的值，可以是任何固定長(cháng)度或者可變長(cháng)度的octet array（理解為字節類(lèi)型的數組即可）。
4）Attribute可以定義一些權限（Permissions），以便server控制client的訪(fǎng)問(wèn)行為，包括：
訪(fǎng)問(wèn)有關(guān)的權限（access permissions），Readable、Writeable以及Readable and writable；
加密有關(guān)的權限（encryption permissions），Encryption required和No encryption required；
認證有關(guān)的權限（authentication permissions），Authentication Required和No Authentication Required；
授權有關(guān)的權限（authorization permissions），Authorization Required和No Authorization Required。
5）根據所定義的Attribute PDU的不同，client可以對server有多種訪(fǎng)問(wèn)方式，包括：
Find Information，獲取Attribute type和Attribute Handle的對應關(guān)系；
Reading Attributes，有Read by type、Read by handle、Read by blob（只讀取部分信息）、Read Multiple（讀取多個(gè)handle的value）等方式；
Writing Attributes，包括需要應答的writing、不需要應答的writing等。
9. Generic Attribute Profile9.1 功能介紹
ATT之所以稱(chēng)作“protocol”，是因為它還比較抽象，僅僅定義了一套機制，允許client和server通過(guò)Attribute的形式共享信息。而具體共享哪些信息，ATT并不關(guān)心，這是GATT（Generic Attribute Profile）的主場(chǎng)。
GATT相對ATT只多了一個(gè)‘G‘，但含義卻大不同，因為GATT是一個(gè)profile（更準確的說(shuō)是profile framework）。
在藍牙協(xié)議中，profile一直是一個(gè)比較抽象的概念，我們可以將其理解為“應用場(chǎng)景、功能、使用方式”都被規定好的Application。傳統的BR/EDR如此，BLE更甚。上面我們講過(guò)，BLE很大一部分的應用場(chǎng)景是信息（Attribute）的共享，因此，BLE協(xié)議?；贏(yíng)ttribute Protocol，定義了一個(gè)稱(chēng)作GATT（Generic Attribute）的profile framework（它本身也是一個(gè)profile），用于提供通用的、信息的存儲和共享等功能。
9.2 層次結構
作為一個(gè)Profile framework，GATT profile提出了如下的層次結構：
圖片4 GATT Profile hierarchy
由上面圖片可知，GATT profile的層次結構依次是：Profile—>Service—>characteristic。
“Profile”是基于GATT所派生出的真正的Profile，位于GATT Profile hierarchy的最頂層，由一個(gè)或者多個(gè)和某一應用場(chǎng)景有關(guān)的Service組成。
一個(gè)Service包含一個(gè)或者多個(gè)Characteristic（特征），也可以通過(guò)Include的方式，包含其它Service。
Characteristic則是GATT profile中最基本的數據單位，由一個(gè)Properties、一個(gè)Value、一個(gè)或者多個(gè)Descriptor組成。
Characteristic Properties定義了characteristic的Value如何被使用，以及characteristic的Descriptor如何被訪(fǎng)問(wèn)。
Characteristic Value是特征的實(shí)際值，例如一個(gè)溫度特征，其Characteristic Value就是溫度值就。
Characteristic Descriptor則保存了一些和Characteristic Value相關(guān)的信息（比較抽象，后續文章會(huì )根據實(shí)例做進(jìn)一步的理解）。
以上除“Profile”外的每一個(gè)定義，Service、Characteristic、Characteristic Properties、Characteristic Value、Characteristic Descriptor等等，都是作為一個(gè)Attribute存在的，具備第8章所描述的Attribute的所有特征：Attribute
Handle、Attribute Types、Attribute Value和AttributePermissions。
9.3 重要的思考
藍牙4.0之后所引入的GATT profile，是一個(gè)非常有“心計”的profile，其中有三點(diǎn)，需要我們重點(diǎn)關(guān)注：
1）基于GATT架構，Application的存在形式，不再是單一的Profile，很多簡(jiǎn)單的應用場(chǎng)景，可以直接以Service的形式存在（profile的概念隱藏在了GATT中），這大大簡(jiǎn)化了一些傳感器節點(diǎn)的設計復雜度。
2）仔細瞅一下圖片4中的Service，然后回憶一下藍牙BR/EDR中的服務(wù)發(fā)現協(xié)議（Service Discover Protocol，SDP）中的“Service”，是否有什么關(guān)聯(lián)？你猜對了，非常有關(guān)聯(lián)，在存在GATT的實(shí)現中，SDP就沒(méi)有存在的必要了。Service也是一個(gè)普通的Generic Attribute。也正是因為這樣的抽象，才使得以往藍牙協(xié)議中的“Service”實(shí)例化了。
3）所謂的“Service”實(shí)例化，指的是，任何一個(gè)profile，都是由service和對應的profile功能組成。
10. Security Manager（SM）
Security Manager負責BLE通信中有關(guān)安全的內容（毫無(wú)疑問(wèn)，在物聯(lián)網(wǎng)時(shí)代，安全變得更重要，誰(shuí)也不想臥室的燈在深夜的時(shí)候會(huì )無(wú)緣無(wú)故的亮吧），包括配對（pairing,）、認證（authentication）和加密（encryption）等過(guò)程。
該部分的內容比較獨立，這里先不過(guò)多介紹，后面會(huì )有單獨的分析文章。
11. Generic Access Profile（GAP）
上面7到10章的內容，都是和基于連接的data channel有關(guān)，至于無(wú)連接的advertising channel，以及連接建立的過(guò)程，好像被我們忽略了。雖然Link Layer已經(jīng)做出了定義（具體可參考第5章的介紹），但它們并沒(méi)有體現到Application（或者Profile）層面，畢竟Link layer太底層了。
因此，BLE協(xié)議棧定義了一個(gè)稱(chēng)作Generic Access（通用訪(fǎng)問(wèn)）的profile，以實(shí)現如下功能：
1）定義GAP層的藍牙設備角色（role）
和5.3中的Link Layer的role類(lèi)似，只不過(guò)GAP層的role更接近用戶(hù)（可以等同于從用戶(hù)的角度看到的藍牙設備的role），包括：
Broadcaster Role，設備正在發(fā)送advertising events；
Observer Role，設備正在接收advertising events；
Peripheral Role，設備接受Link Layer連接（對應Link Layer的slave角色）；
Central Role，設備發(fā)起Link Layer連接（對應Link Layer的master角色）。
2）定義GAP層的、用于實(shí)現各種通信的操作模式（Operational Mode）和過(guò)程（Procedures），包括：
Broadcast mode and observation procedure，實(shí)現單向的、無(wú)連接的通信方式；
Discovery modes and procedures，實(shí)現藍牙設備的發(fā)現操作；
Connection modes and procedures，實(shí)現藍牙設備的連接操作；
Bonding modes and procedures，實(shí)現藍牙設備的配對操作。
3）定義User Interface有關(guān)的藍牙參數，包括：
藍牙地址（Bluetooth Device Address）；
藍牙名稱(chēng)（Bluetooth Device Name）；
藍牙的pincode（Bluetooth Passkey）；
藍牙的class（Class of Device，和****功率有關(guān)）；
等等。
4）Security有關(guān)的定義，暫不介紹
12. Applications
暫不介紹了，后續其它文章會(huì )結合某些Profile及應用場(chǎng)景的室例，作進(jìn)一步分析。
 
原創(chuàng  )文章，轉發(fā)請注明出處。蝸窩科技，www.wowotech.net。




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




				
*博客內容為網(wǎng)友個(gè)人發(fā)布，僅代表博主個(gè)人觀(guān)點(diǎn)，如有侵權請聯(lián)系工作人員刪除。
				
            	

					
						
						
					
				
                
				
								
c語(yǔ)言相關(guān)文章:c語(yǔ)言教程


								
單片機相關(guān)文章:單片機教程


								
單片機相關(guān)文章:單片機視頻教程


								
單片機相關(guān)文章:單片機工作原理