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

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

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

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

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

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

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

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

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

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

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

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

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

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

經(jīng)過上面的定義之后，BLE的物理通道已經(jīng)出來了，即“頻點分別是‘f=2402+k*2 MHz, k=0, … ,39’，帶寬為2MHz”的40個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個RF Channel（后面統(tǒng)一使用Physical Channel指代）。此時Link Layer可以粉墨登場了，它主要的功能，就是在這些Physical Channel上收發(fā)數(shù)據(jù)，與此同時，不可避免的需要控制RF收發(fā)相關(guān)的參數(shù)。但僅做這些，還遠(yuǎn)遠(yuǎn)不夠：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Initiater方稱作Mater；

Advertiser方稱作Slave。

狀態(tài)和角色定義完成后，剩下的事情就簡單了，主要包括兩類：提供某一狀態(tài)下，和其它實體對應(yīng)狀態(tài)之間的數(shù)據(jù)交換機制；根據(jù)上層實體的指令，以及當(dāng)前的實際情況，負(fù)責(zé)狀態(tài)之間的切換。BLE協(xié)議中，這些事情是由一個叫做空中接口協(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，用于識別。

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

3）Link Layer總packet長度是9~264bytes。

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

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請求的、無方向的廣播數(shù)據(jù)（scannable undirected advertising event）。

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

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

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

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

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

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

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

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

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

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

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

等等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

等等…

以上問題，都是由L2CAP，一個介于應(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ù)傳輸對延時的要求，并便于后續(xù)的重傳、流控等機制的實現(xiàn)；

Flow control per L2CAP channel，基于L2CAP Channel的流控機制；

Error control and retransmissions，錯誤控制和重傳機制；

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

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

Quality of Service，QoS的支持。

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

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

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

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

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

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

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

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

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

那CID是怎么確定的呢？有一些固定用途的L2CAP Channel，其CID是固定值，另外一些則是動態(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)用場景，L2CAP在提供基于連接的通信機制之外，也提供了無連接的數(shù)據(jù)傳輸方法。基于這種方法，CID不存在了，取而代之的是一個稱作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可在兩個設(shè)備之間建立用于點對點通信的Logical Channel；而L2CAP則將這個Logical Channel換分為一個個的L2CAP Channel，以便提供應(yīng)用程序級別的通道復(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é)點設(shè)備定時的向中心設(shè)備匯報信息數(shù)據(jù)，或者，中心設(shè)備在需要的時候主動查詢。

基于信息采集的需求，BLE抽象出一個協(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é)點），訪問信息的一方稱作ATT client。

3）一個Attribute由Attribute Type、Attribute Handle和Attribute Value組成。

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

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

Attribute Value代表Attribute的值，可以是任何固定長度或者可變長度的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可以對server有多種訪問方式，包括：

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

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

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

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

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

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

作為一個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的最頂層，由一個或者多個和某一應(yīng)用場景有關(guān)的Service組成。

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

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

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

Characteristic Value是特征的實際值，例如一個溫度特征，其Characteristic Value就是溫度值就。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

藍牙地址（Bluetooth Device Address）；

藍牙名稱（Bluetooth Device Name）；

藍牙的pincode（Bluetooth Passkey）；

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

等等。

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

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

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

.

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