藍芽解析(3):BLE協議棧解析
轉自http://www.wowotech.net/bluetooth/ble_stack_overview.html
1. 前言
本文從協議棧設計者的角度，思考如下問題：
為什麼會有藍芽協議棧（Why）？
怎樣實現藍芽協議棧（How）？
藍芽協議棧的最終樣子是什麼（What）？
我們知道，當前的藍芽協議包含BR/EDR、AMP、LE三種技術，為了降低複雜度，本文將focus在現在比較熱門的BLE（Bluetooth Low Energy）技術上（意在用於物聯網），至於BR/EDR和AMP，觸類旁通即可。
“Why”要回答的其實是需求問題，對BLE（藍芽低功耗）來說，其需求包含兩個部分：和傳統藍芽重疊的部分；BLE特有的低功耗部分。大致總結如下：
基於2.4GHz ISM頻段的無線通訊；
通訊速率要求不高，但對功耗極為敏感；
儘量複用已有的BR/EDR技術；
組網方式自由靈活，既可以使用傳統藍芽所使用的“基於連線的星形網路（由1個master和多個slave組成）”，也可以使用“無連線的網狀網路（由多個advertiser和多個scanner組成）；
參與通訊的裝置的數量和種類眾多，要從應用的角度考慮易於實現、互聯互通等特性；
有強烈的安全（security）需求；
等等。
“How”要回答的是設計思路，“What”是基於該思路設計出來的最終產品的樣子。
按理說，需要先介紹“How”，後介紹所產出的“What”。但以蝸蝸對藍芽的理解，顯然無法拋開“What”單獨回答“How”。所以，基於現有的協議框架（What），去理解背後的“How”，才是明智之舉。
開始之前，我們先總結一下BLE的協議框架，後面章節會根據該框架，採用自下向上的方法逐層分析介紹。
如下面圖片1所示，BLE的協議可分為Bluetooth Application和Bluetooth Core兩大部分，而Bluetooth Core又包含BLE Controller和BLE Host兩部分（有關概念可參考“藍芽協議分析(1)_基本概念”）。
圖片1 BLE協議框架
任何一個通訊系統，首先要確定的就是通訊介質（物理通道，Physical Channel），BLE也不例外。在BLE協議中，“通訊介質”的定義是由Physical Layer（其它通訊協議也類似）負責。
Physical Layer是這樣描述BLE的通訊介質的：
由於BLE屬於無線通訊，則其通訊介質是一定頻率範圍下的頻帶資源（Frequency Band）；
BLE的市場定位是個體和民用，因此使用免費的ISM頻段（頻率範圍是2.400-2.4835 GHz）；
為了同時支援多個裝置，將整個頻帶分為40份，每份的頻寬為2MHz，稱作RF Channel。
經過上面的定義之後，BLE的物理通道已經出來了，即“頻點分別是‘f=2402+k*2 MHz, k=0, … ,39’，頻寬為2MHz”的40個RF Channel。
除了物理通道之外，Physical Layer還需要定義RF收發雙方的一些其它特性，包括（不影響本文後續的討論，不用深究）：
RF發射相關的特性（Transmitter Characteristics），包括髮射功率（Transmission power、調製方式（Modulation），高斯頻移鍵控（Gaussian Frequency Shift Keying ，GFSK）、Spurious Emissions、Radio Frequency Tolerance等等。（不影響本文後續的討論，不用深究）；
RF接收相關的特性（Receiver Characteristics），包括接收靈敏度等。
經過Physical Layer的定義，通訊所需的物理通道已經okay了，即40個RF Channel（後面統一使用Physical Channel指代）。此時Link Layer可以粉墨登場了，它主要的功能，就是在這些Physical Channel上收發資料，與此同時，不可避免的需要控制RF收發相關的引數。但僅做這些，還遠遠不夠：
首先，Physical Layer僅僅提供了有限的40個Physical Channel，而BLE中參與通訊的實體的數量，肯定不是這個數量級。Link Layer需要解決Physical Channel的共享問題；
其次，通訊是兩個實體之間的事情，對這兩個實體來說，它們希望看到一條為自己獨享的傳輸通道（就是我們所熟悉的邏輯鏈路，Logical Link）。這也是Link Layer需要解決的；
再則，Physical Channel是不可靠的，任何資料傳輸都可能由於干擾等問題二損毀、丟失，這對有些應用來說，是接受不了的。因此Link Layer需要提供校驗、重傳等機制，確保資料傳輸的可靠性；
等等，等等，簡直是既當爹又當媽！
BLE系統只有有限的40個Physical Channel，怎麼容納多個通訊實體呢？說來也簡單，Link Layer將BLE的通訊場景分為兩類：
1） 資料量比較少、傳送不頻繁、對時延不是很敏感的場景
例如一個感測器節點（如溫度感測器），需要定時（如1s）向處理中心傳送感測器資料（如溫度）。
針對這種場景，BLE的Link Layer採取了一種比較懶的處理方式----廣播通訊：
從40個Physical Channel中選取3個，作為廣播通道（advertising channel）；
在廣播通道上，任何參與者，愛發就發，愛收就收，隨便；
所有參與者，共享同一個邏輯傳輸通道（廣播通道），之間的
當然，這種方法存在很多問題，例如：
不可靠，是否會相互干擾？傳送是否成功？不知道！接收是否成功？不知道！
效率不高，如果同一區域有很多節點在廣播資料，某一個接收者是不是要接收所有的資料包，不管是不是它關心的？
安全問題，怎麼解決？
確實，問題多多，不過Link Layer定義了一些策略，儘可能的提高了這種通訊方式的便利性，後面我們會介紹。至於無法解決的，簡單，兩種方案：
a）忍，廣播通訊需要佔用的資源實在太少了，正對物聯網中的那些小節點們的胃口啊。
b）使用基於連線的通訊方式（就是給你倆建立一個專線），具體可參考下面5.2.2的介紹。
2）資料量較大、傳送頻率較高、對時延較敏感的場景
BLE的Link Layer會從剩餘的37個Physical Channel中，選取一個，為這種場景裡面的通訊雙方建立單獨的通道（data channel）。這就是連線（connection）的過程。
同時，為了增加容量，增大抗干擾能力，連線不會長期使用一個固定的Physical Channel，而是在多個Channel（如37個）之間隨機但有規律的切換，這就是BLE的跳頻（Hopping）技術。
基於上面5.2小節的思路，BLE協議在Link Layer抽象出5種狀態：
注1：從橫向看，協議的每個層次（如這裡的Link Layer）都可以當做可相互通訊的實體。這裡的狀態，就是指這每一層實體的狀態。因此，在協議的多個層次上，都可能有狀態定義，甚至名字也一樣，我們閱讀協議棧的時候，一定要留意，不要被繞暈了。
• Standby State
• Advertising State
• Scanning State
• Initiating State
• Connection State
並以如下的狀態機進行切換（裝置在同一時刻只能處於這些狀態的一種）：
圖片2 Link Layer狀態機
Standby狀態是初始狀態，即不傳送資料，也不接收資料。根據上層實體的命令（如位於host軟體中GAP），可由其它任何一種狀態進入，也可以切換到除Connection狀態外的任意一種狀態。
Advertising狀態是可以通過廣播通道傳送資料的狀態，由Standby狀態進入。它廣播的資料可以由處於Scanning或者Initiating狀態的實體接收。上層實體可通過命令將Advertising狀態切換回Standby狀態。另外，連線成功後，也可切換為Connection狀態。
Scanning狀態是可以通過廣播通道接收資料的狀態，由Standby狀態進入。根據Advertiser所廣播的資料的型別，有些Scanner還可以主動向Advertiser請求一些額外資料。上層實體可通過命令將Scanning狀態切換回Standby狀態。
Initiating狀態和Scanning狀態類似，不過是一種特殊的接收狀態，由Standby狀態進入，只能接收Advertiser廣播的connectable的資料，並在接收到資料後，傳送連線請求，以便和Advertiser建立連線。當連線成功後，Initiater和對應的Advertiser都會切換到Connection狀態。
Connection狀態是和某個實體建立了單獨通道的狀態，在通道建立之後，由Initiating或者Advertising自動切換而來。通道斷開後，會重新回到Standby狀態。
通道建立後（通常說“已連線”），處於Connection狀態的雙方，分別有兩種角色Master和Slave：
Initiater方稱作Mater；
Advertiser方稱作Slave。
狀態和角色定義完成後，剩下的事情就簡單了，主要包括兩類：提供某一狀態下，和其它實體對應狀態之間的資料交換機制；根據上層實體的指令，以及當前的實際情況，負責狀態之間的切換。BLE協議中，這些事情是由一個叫做空中介面協議（Air Interface Protocol）的傢伙負責，主要思路如下。
5.4.1 定義在Physical Channel上收發的資料包的格式（packet format）
在BLE中，兩種型別的Physical Channel（advertising channel和data channel）統一使用一種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等，需要拆分、重組才能支援更大資料量的傳輸。
3）Link Layer總packet長度是9~264bytes。
由5.3小節的描述，Link Layer有5種狀態，每種狀態下所傳輸資料的功能不盡相同，基於此，Air Interface Protocol定義出如下的PDU型別（這裡只簡單列舉一下，不深入討論）：
1）Advertising channel中Advertising有關的PDU
ADV_IND，Advertiser傳送的、可被連線的、無方向的廣播資料（connectable undirected advertising event）。
ADV_DIRECT_IND，Advertiser傳送的、可被連線的、單向廣播資料（connectable directed advertising event）。
ADV_NONCONN_IND，Advertiser傳送的、不可被連線的、無方向的廣播資料（non-connectable undirected advertising event）。
ADV_SCAN_IND，Advertiser傳送的、可接受SCAN_REQ請求的、無方向的廣播資料（scannable undirected advertising event）。
2）Advertising channel中Scanning有關的PDU
SCAN_REQ，Scanner傳送的、向Advertiser請求額外資訊的資料包（一般需要在收到ADV_SCAN_IND後才可傳送）。
SCAN_RSP，Advertiser傳送的、響應SCAN_REQ請求的資料包。
3）Advertising channel中Initialing有關的PDU
CONNECT_REQ，Initiater發起的、請求建立連線的資料包。
4）Data channel中LL data有關的PDU
已連線的雙方進行資料通訊所用的PDU，有效的payload長度為0~251bytes。
5）Data channel中LL control有關的PDU
用於管理、維護、更新已連線的資料通道的PDU，包括：
LL_CHANNEL_MAP_REQ，請求更改所使用的Physical Channel的資料包；
LL_TERMINATE_IND，告知對方此次連線即將結束，以及結束的原因；
等等。
5.4.3 以白名單（White List）的形式定義Link Layer的資料過濾機制
主要針對廣播通道，因為隨著通訊裝置的增多，空中的廣播資料將會呈幾何級的增長，為了避免資源的浪費（特別是BLE Host），有必要在Link Layer過濾掉一些資料包，例如根據藍芽地址，過濾掉不是給自己的packet。
上層軟體只需要定義一些引數，例如：
Advertising State下的Advertising Channel的選擇、Advertising的間隔、Advertising PDU的型別等；
Scanning State/Initialing State下的scanWindow、scanInterval等。
Link Layer將會自動傳送或者接收資料包。
具體不再詳細描述。
經過Air Interface Protocol的抽象，BLE實體已經具備廣播通訊、點對點連線的建立和釋放、點對點通訊等基本的能力。除此之外，Link Layer又抽象出來一個鏈路控制協議（Link Layer Control），用於管理、控制兩個Link Layer實體之間所建立的這個Connection，主要功能包括：
更新Connection相關的引數，如transmitWindowSize、transmitWindowOffset、connInterval等等（具體意義這裡不再詳述）；
更新該連線所使用的跳頻圖譜（使用哪些Physical Channels）；
執行鏈路加密（Encryption）有關的過程。
定義Host和Controller（通常是兩顆IC）之間的通訊協議，可基於Uart、USB等物理介質，對理解藍芽協議來說，是無關緊要的，這裡暫不介紹。
經過Link Layer的抽象之後，兩個BLE裝置之間可存在兩條邏輯上的資料通道：一條是無連線的廣播通道，天高任鳥飛；另一條是基於連線的資料通道，是一個點對點（Master對Slave）的邏輯通道。
廣播通道暫且不表，這個資料通道（後面簡稱邏輯通道，Logical Channel），要怎麼使用，還需要一番思索，例如：
Logical Channel只有一條，而要利用它傳輸資料的上層應用卻不止一個（例如圖片1中的ATT和SMP），怎麼複用？
Logical Channel所能傳輸的有效payload長度最大隻有251bytes，怎是否意味著上層應用每次只能傳輸少於這個長度的資料？（顯然不能！）
Logical Channel僅提供了簡單的應答和流控機制，如果傳輸的資料出錯怎麼辦？
等等…
以上問題，都是由L2CAP，一個介於應用程式（Profile、Application等）和Link Layer之間的protocol，負責回答，這也是它的縮寫（Logical Link Control and Adaptation Protocol）的意義所在。它提供的功能主要包括：
Protocol/channel multiplexing，協議/通道的多路複用；
Segmentation and reassembly，上層應用資料（L2CAP Service Data Units，SDUs）的分割（和重組），生成協議資料單元（L2CAP Packet Data Units，PDUs），以滿足使用者資料傳輸對延時的要求，並便於後續的重傳、流控等機制的實現；
Flow control per L2CAP channel，基於L2CAP Channel的流控機制；
Error control and retransmissions，錯誤控制和重傳機制；
Support for Streaming，支援流式傳輸（如音訊、視訊等，不需要重傳或者只需要有限重傳）；
Fragmentation and Recombination，協議資料單元（PDUs）的分片（和重組），生成符合Link Layer傳輸要求的資料片（長度不超過251，具體可參考5.4.1中有關的介紹）；
Quality of Service，QoS的支援。
鑑於篇幅問題，本文重點介紹有利用理解上層協議（ATT、GATT等）的“Protocol/channel multiplexing”功能，其它部分會在後續L2CAP的分析文章中重點說明。
7.2 Protocol/channel multiplexing
所謂的multiplexing（多路複用），還是很好理解的：
可用於傳輸使用者資料的邏輯鏈路只有一條，而L2CAP需要服務的上層Profile和Application的數目，肯定遠不止這個數量。因此，需要使用多路複用的手段，將這些使用者資料map到有限的鏈路資源上去。
至於multiplexing的手段，簡單又直接（稱的上“協議”的標配）：
資料傳送時，將使用者資料分割為一定長度的資料包（L2CAP Packet Data Units，PDUs），加上一個包含特定“ID”的header後，通過邏輯鏈路傳送出去。
資料接收時，從邏輯鏈路接收資料，解析其中的“ID”，並以此判斷需要將資料轉發給哪個應用。
這裡所說的ID，就是多路複用的手段，L2CAP提供兩種複用手段：
7.2.1 基於連線的方法（這裡的連線為L2CAP connection，不要和Link Layer的connection混淆了）
這裡的連線，是指基於L2CAP的應用程式，在通訊之前，先建立一個基於Logical Channel的虛擬通道（稱作L2CAP channel，和TCP/IP中的埠類似）。L2CAP會為這個通道分配一個編號，稱作channel ID（簡稱CID）。
L2CAP channel建立之後，就可以把CID放到資料包的header中，以達到multiplexing的目的。這些基於CID實現的多路複用，就稱作channel multiplexing（基於通道的多路複用）。
那CID是怎麼確定的呢？有一些固定用途的L2CAP Channel，其CID是固定值，另外一些則是動態分配的，具體如下：
圖片3 BLE CID分配
有關CID的具體數值可參考：Core_v4.2.pdf, Volume 3, Part A - Logical Link Control and Adaptation Protocol Specification
另外，為了提高資料傳輸的效率，方便廣播通訊等應用場景，L2CAP在提供基於連線的通訊機制之外，也提供了無連線的資料傳輸方法。基於這種方法，CID不存在了，取而代之的是一個稱作Protocol/Service Multiplexer(PSM)的欄位。
這種多路複用的手段則成為Protocol multiplexing（基於協議的多路複用）。
由於Protocol multiplexing只允許在BR/EDR controller中使用，本文就不再詳細介紹了。
由上面章節的描述可知，在BLE協議棧中：Physical Layer負責提供一系列的Physical Channel；基於這些Physical Channel，Link Layer可在兩個裝置之間建立用於點對點通訊的Logical Channel；而L2CAP則將這個Logical Channel換分為一個個的L2CAP Channel，以便提供應用程式級別的通道複用。到此之後，基本協議棧已經構建完畢，應用程式已經可以基於L2CAP歡快的run起來了。
談起應用程式，就不得不說BLE的初衷----物聯網。物聯網中傳輸的資料和傳統的網際網路有什麼區別呢？拋開其它不談，物聯網中最重要、最廣泛的一類應用是：資訊的採集。
這些資訊往往都很簡單，如溫度、溼度、速度、位置資訊、電量、水壓、等等。
採集的過程也很簡單，節點裝置定時的向中心裝置彙報資訊資料，或者，中心裝置在需要的時候主動查詢。
基於資訊採集的需求，BLE抽象出一個協議：Attribute protocol，該協議將這些“資訊”以“Attribute（屬性）”的形式抽象出來，並提供一些方法，供遠端裝置（remote device）讀取、修改這些屬性的值（Attribute value）。
Attribute Protocol的主要思路包括：
1）基於L2CAP，使用固定的Channel ID（0x004，具體可參考“圖片3”）。
2）採用client-server的形式。提供資訊（以後都稱作Attribute）的一方稱作ATT server（一般是那些感測器節點），訪問資訊的一方稱作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的數值）區分。
Attribute Handle是一個16-bit的數值，用作唯一識別Attribute server上的所有Attribute。Attribute Handle的存在有如下意義：
a）一個server上可能存在多個相同type的Attribute，顯然，client有區分這些Attribute的需要。
b）同一型別的多個Attribute，可以組成一個Group，client可以通過這個Group中的起、始handle訪問所有的Attributes。Attribute Value代表Attribute的值，可以是任何固定長度或者可變長度的octet array（理解為位元組型別的陣列即可）。
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）根據所定義的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等。
ATT之所以稱作“protocol”，是因為它還比較抽象，僅僅定義了一套機制，允許client和server通過Attribute的形式共享資訊。而具體共享哪些資訊，ATT並不關心，這是GATT（Generic Attribute Profile）的主場。
GATT相對ATT只多了一個‘G‘，但含義卻大不同，因為GATT是一個profile（更準確的說是profile framework）。
在藍芽協議中，profile一直是一個比較抽象的概念，我們可以將其理解為“應用場景、功能、使用方式”都被規定好的Application。傳統的BR/EDR如此，BLE更甚。上面我們講過，BLE很大一部分的應用場景是資訊（Attribute）的共享，因此，BLE協議棧基於Attribute Protocol，定義了一個稱作GATT（Generic Attribute）的profile framework（它本身也是一個profile），用於提供通用的、資訊的儲存和共享等功能。
作為一個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中最基本的資料單位，由一個Properties、一個Value、一個或者多個Descriptor組成。
Characteristic Properties定義了characteristic的Value如何被使用，以及characteristic的Descriptor如何被訪問。
Characteristic Value是特徵的實際值，例如一個溫度特徵，其Characteristic Value就是溫度值就。
Characteristic Descriptor則儲存了一些和Characteristic Value相關的資訊（比較抽象，後續文章會根據例項做進一步的理解）。
以上除“Profile”外的每一個定義，Service、Characteristic、Characteristic Properties、Characteristic Value、Characteristic Descriptor等等，都是作為一個Attribute存在的，具備第8章所描述的Attribute的所有特徵：Attribute
Handle、Attribute Types、Attribute Value和AttributePermissions。
藍芽4.0之後所引入的GATT profile，是一個非常有“心計”的profile，其中有三點，需要我們重點關注：
1）基於GATT架構，Application的存在形式，不再是單一的Profile，很多簡單的應用場景，可以直接以Service的形式存在（profile的概念隱藏在了GATT中），這大大簡化了一些感測器節點的設計複雜度。
2）仔細瞅一下圖片4中的Service，然後回憶一下藍芽BR/EDR中的服務發現協議（Service Discover Protocol，SDP）中的“Service”，是否有什麼關聯？你猜對了，非常有關聯，在存在GATT的實現中，SDP就沒有存在的必要了。Service也是一個普通的Generic Attribute。也正是因為這樣的抽象，才使得以往藍芽協議中的“Service”例項化了。
3）所謂的“Service”例項化，指的是，任何一個profile，都是由service和對應的profile功能組成。
Security Manager負責BLE通訊中有關安全的內容（毫無疑問，在物聯網時代，安全變得更重要，誰也不想臥室的燈在深夜的時候會無緣無故的亮吧），包括配對（pairing,）、認證（authentication）和加密（encryption）等過程。
該部分的內容比較獨立，這裡先不過多介紹，後面會有單獨的分析文章。
11. Generic Access Profile（GAP）
上面7到10章的內容，都是和基於連線的data channel有關，至於無連線的advertising channel，以及連線建立的過程，好像被我們忽略了。雖然Link Layer已經做出了定義（具體可參考第5章的介紹），但它們並沒有體現到Application（或者Profile）層面，畢竟Link layer太底層了。
因此，BLE協議棧定義了一個稱作Generic Access（通用訪問）的profile，以實現如下功能：
1）定義GAP層的藍芽裝置角色（role）
和5.3中的Link Layer的role類似，只不過GAP層的role更接近使用者（可以等同於從使用者的角度看到的藍芽裝置的role），包括：
Broadcaster Role，裝置正在傳送advertising events；
Observer Role，裝置正在接收advertising events；
Peripheral Role，裝置接受Link Layer連線（對應Link Layer的slave角色）；
Central Role，裝置發起Link Layer連線（對應Link Layer的master角色）。
2）定義GAP層的、用於實現各種通訊的操作模式（Operational Mode）和過程（Procedures），包括：
Broadcast mode and observation procedure，實現單向的、無連線的通訊方式；
Discovery modes and procedures，實現藍芽裝置的發現操作；
Connection modes and procedures，實現藍芽裝置的連線操作；
Bonding modes and procedures，實現藍芽裝置的配對操作。
3）定義User Interface有關的藍芽引數，包括：
藍芽地址（Bluetooth Device Address）；
藍芽名稱（Bluetooth Device Name）；
藍芽的pincode（Bluetooth Passkey）；
藍芽的class（Class of Device，和發射功率有關）；
等等。
4）Security有關的定義，見http://blog.csdn.net/z497544849/article/details/53906871。
暫不介紹了，後續其它文章會結合某些Profile及應用場景的室例，作進一步分析。
--------------------- 本文來自 no輸給現實 的CSDN 部落格 ，全文地址請點選：https://blog.csdn.net/z497544849/article/details/53926785?utm_source=copy