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

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

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

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

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

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

“How”要回答的是設計思路，“What”是基于該思路設計出來的最終產品的樣子。

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

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

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

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

Physical Layer是這樣描述BLE的通信介質的：

由于BLE屬于無線通信，則其通信介質是一定頻率范圍下的頻帶資源（Frequency Band）；
BLE的市場定位是個體和民用，因此使用免費的ISM頻段（頻率范圍是2.400-2.4835 GHz）；
為了同時支持多個設備，將整個頻帶分為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****相關的特性（Transmitter Characteristics），包括****功率（Transmission power、調制方式（Modulation），高斯頻移鍵控（Gaussian Frequency Shift Keying ，GFSK）、Spurious Emissions、Radio Frequency Tolerance等等。（不影響本文后續(xù)的討論，不用深究）；
RF接收相關的特性（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ā)相關的參數(shù)。但僅做這些，還遠遠不夠：

首先，Physical Layer僅僅提供了有限的40個Physical Channel，而BLE中參與通信的實體的數(shù)量，肯定不是這個數(shù)量級。Link Layer需要解決Physical Channel的共享問題；
其次，通信是兩個實體之間的事情，對這兩個實體來說，它們希望看到一條為自己獨享的傳輸通道（就是我們所熟悉的邏輯鏈路，Logical Link）。這也是Link Layer需要解決的；
再則，Physical Channel是不可靠的，任何數(shù)據(jù)傳輸都可能由于干擾等問題二損毀、丟失，這對有些應用來說，是接受不了的。因此Link Layer需要提供校驗、重傳等機制，確保數(shù)據(jù)傳輸?shù)目煽啃裕?
等等，等等，簡直是既當?shù)之攱專?/pre>5.2 怎么解決Physical Channel的共享問題
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ā)，愛收就收，隨便；
所有參與者，共享同一個邏輯傳輸通道（廣播通道），之間的
當然，這種方法存在很多問題，例如：
不可靠，是否會相互干擾？發(fā)送是否成功？不知道！
接收是否成功？不知道！
效率不高，如果同一區(qū)域有很多節(jié)點在廣播數(shù)據(jù)，某一個接收者是不是要接收所有的數(shù)據(jù)包，不管是不是它關心的？
安全問題，怎么解決？
確實，問題多多，不過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）技術。

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




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




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

					
						
						
					
				
                
				
								
c語言相關文章:c語言教程


								
單片機相關文章:單片機教程


								
單片機相關文章:單片機視頻教程


								
單片機相關文章:單片機工作原理