以藍牙爲背景剖析無線通訊原理以及協議棧

時間 2019-11-17

標籤藍牙背景剖析無線通訊原理以及協議欄目無線简体版

原文原文鏈接

前言：html

　　基於傳統點對點的架構，想要把家庭電腦和鍵盤、鼠標、耳機、麥克風、以及移動電話等等鏈接起來，可能還要考慮增長USB插口。git

　　有沒有一種通用的不須要用戶干預的簡便方法把各類電子設備鏈接在一塊兒，而又不至於被線纜淹沒呢？在WiFi以外，你們已經比較熟悉的「藍牙」正是這樣一種鏈接技術，它被設計爲面向我的和家庭的無線式自動鏈接，其三大核心特色即是無線、低成本和自動化。github

　　　　　　　　　　　　　　　　　　　　　圖1 藍牙的無線鏈接模式網絡

　　但是「藍牙」是怎麼實現的上述所說的「鏈接」的呢？架構

　　下面咱們從無線通訊開始講解，而後講解藍牙通訊協議棧，最後講解藍牙低功耗中的廣播通訊。相信讀完下面的介紹，便能理解藍牙設備間是怎麼實現通訊的。app

1、無線通訊學習

1.1 無線通訊原理ui

　　在發射端，發射機將已調製的高頻震盪電流經過「饋電設備」輸入發射天線，發射天線將高頻電流轉變爲無線電波—自由電磁波向周圍空間輻射。google

在接收端經過接收天線將無線電波轉化成高頻電流，再通過饋電設備傳輸到接收機。spa

　　　　　　　　　　　　　　　　　　　　　　　　圖2 無線信號生成及傳輸過程

　　自由電磁波：是由同向且相互垂直的電場與磁場在空間中衍生髮射的震盪粒子波，是以波動的形式傳播的電磁場（電磁場是有內在聯繫、相互依存的電場和磁場的統一體的總稱。隨時間變化的電場產生磁場，隨時間變化的磁場產生電場，二者互爲因果，造成電磁場。電磁場可由變速運動的帶電粒子引發，也可由強弱變化的電流引發，不論緣由如何，電磁場老是以光速向四周傳播，造成電磁波）

　　饋電設備：被控制裝置向控制點送電。

　　饋電設備可根據高頻震盪電流的頻率和形式的不一樣，直接傳輸電流波或者電磁波。

　　電信號在接收端又是怎麼轉化成數字信號，供上層處理的呢？

　　這就是模數轉換（AD），模擬信號是有強弱變化的電流, 智能終端裏存儲不了這種信號。因此要把這種電流的強弱變化經過另外一種方式表達。因而就有了AD。它把電流強弱的變化翻譯成了二進制代碼存儲在智能終端，也就是數字信號。

　　一樣的，能夠經過數模轉換（DA）把數字信號轉化成模擬電信號，再由天線把電流轉化成無線電磁波進行發送。

1.2 電磁波譜

　　　　　　　　　　　　　　　　　　　　　　　　　圖3 電磁波譜

　　無線頻譜僅僅是全部電磁波譜的一個子集，例如，咱們將頻率爲428570Ghz的電磁波識別爲紅色，本文中重點介紹的藍牙頻段範圍是2.400-2.4835 GHz。

下表是無線電頻率頻段劃分：

　　　　　　　　　　　　　　　　　　　　　圖4 無線電頻率頻段劃分

　　人耳可以聽見的音頻信號的頻率範圍大約是20Hz-2OkHz。

1.3 無線通訊協議

　　無線通訊協議是爲了完成了通訊實體之間的通訊而作的一些規則和約定的集合。由於沒有實體，不是很好理解，能夠類比下交通運輸，路須要多寬，限速多少，道路標示怎麼畫，路兩側怎麼防禦，紅綠燈的規則等等，均可以認爲是"交通協議"，通訊協議與其相似。

2、藍牙通訊協議

　　通俗的講，藍牙協議棧上層封裝下層傳輸過來的數據並提供接口供上層調用，上層只需使用下層提供的接口，不須要關心下層的具體實現細節。兩個藍牙設備之間每層使用相同的協議進行封裝/解封裝，最終在藍牙app層只關心的是傳輸數據中的有效信息，並不關心如CRC校驗信息等。

　　藍牙無線通訊遵循IEEE的802.15標準，IEEE 802.15具備短距離、低功耗、低成本、小型網絡及適用於我的操做空間的特色。因爲藍牙屬於無線通訊，則其通訊介質是必定頻率範圍下的頻帶資源（Frequency Band），藍牙的市場定位是個體和民用，所以使用免費的ISM頻段（頻率範圍是2.400-2.4835 GHz）。（ISM:Industrial Scientific Medical，是由ITU，國際通訊聯盟無線電通訊局定義的）

　　下面重點講解藍牙通訊協議棧。協議棧以下圖：

　　　　　　　　　　　　　　　　　　　　　　　　　　圖5 藍牙協議棧

　　藍牙協議分爲四個層次：物理層（Physical Layer）、邏輯層（Logical Layer）、L2CAP Layer和應用層（APP Layer）。

物理層，負責提供數據傳輸的物理通道（一般稱爲信道）。一般狀況下，一個通訊系統中存在幾種不一樣類型的信道，如控制信道、數據信道、語音信道等等。

邏輯層，在物理層的基礎上，提供兩個或多個設備之間, 和物理無關的邏輯傳輸通道（也稱做邏輯鏈路）。

L2CAP層，L2CAP是邏輯鏈路控制和適配協議（Logical Link Control and Adaptation Protocol）的縮寫，負責管理邏輯層提供的邏輯鏈路。基於該協議，不一樣Application可共享同一個邏輯鏈路。相似TCP/IP中端口（port）的概念。

APP層，理解藍牙協議中的應用層，基於L2CAP提供的channel，實現各類各樣的應用功能。Profile是藍牙協議的特有概念，爲了實現不一樣平臺下的不一樣設備的互聯互通，藍牙協議不止規定了核心規範（稱做Bluetooth core），也爲各類不一樣的應用場景，定義了各類Application規範，這些應用層規範稱做藍牙profile。

　　在以上四個層次的基礎上，藍牙協議又將物理層和邏輯層劃分了子層，分別是Physical Channel/Physical Links和Logical Transports/Logical Links，這一劃分，至關令人崩潰，要多花費大量的腦細胞去理解它們，具體請參考下面的分析。

2.1 物理層

　　物理層負責提供數據傳輸的物理信道，又分爲Physical Channel和Physical Links。

Physical Layer還須要定義RF(指物理信道)收發雙方的一些特性，包括：

RF發射相關的特性（Transmitter Characteristics），包括髮射功率（Transmission power、調製方式（Modulation），高斯頻移鍵控（Gaussian Frequency Shift Keying ，GFSK）、Spurious Emissions、Radio Frequency Tolerance等等。

RF接收相關的特性（Receiver Characteristics），包括接收靈敏度等。

2.1.2 Physical Channel(物理信道)

　　分傳統的藍牙技術（BR）和低功耗藍牙技術（BLE）分別介紹Physical Channel

　　傳統藍牙技術BR這樣定義信道：

1）ISM頻帶被分紅79份，每一份帶寬1MHz，稱做RF Channel。在0 channel和78 channel以外設立guard band（保護帶寬，Lower Guard Band爲2MHz，Upper Guard Band爲3.5MHz）。

2）採用跳頻技術（hopping），也就是說，某一個物理信道，並非固定的佔用79個channel中的某一個，而是以必定的規律在跳動（該規律在技術上叫作"僞隨機碼"，就是"假"的隨機碼）。所以藍牙的物理信道，也能夠稱做跳頻信道（hopping channel）。

3）BR技術定義了5種物理信道（跳頻信道），BR Basic Piconet Physical Channel、BR Adapted Piconet Physical Channel、BR Page Scan Physical Channel、BR Inquiry Scan Physical Channel和BR Synchronization Scan Channel。

4）BR Page Scan Physical Channel用於藍牙設備的發現操做（discovery），即咱們經常使用的搜索其它藍牙設備（discover）以及被其它藍牙設備搜索（discoverable）。

5）BR Inquiry Scan Physical Channel用於藍牙設備的鏈接操做（connect），即咱們經常使用的鏈接其它藍牙設備（connect）以及被其它藍牙設備鏈接（connectable）。

6）BR Basic Piconet Physical Channel和BR Adapted Piconet Physical Channel主要用在處於鏈接狀態的藍牙設備之間的通訊。它們的區別是，BR Adapted Piconet Physical Channel使用較少的RF跳頻點。BR Basic Piconet Physical Channel使用所有79個跳頻點，而BR Adapted Piconet Physical Channel是根據當前的信道狀況使用79個跳頻點中的子集，可是跳頻數目也不能少於20個。這個主要是由於藍牙使用ISM頻段，當藍牙和WIFI共存的時候，部分跳頻點被WIFI設備佔用而使得藍牙設備在這些跳頻點上的通訊老是失敗，所以，須要避過那些WIFI設備佔用的頻點。

7）BR Synchronization Scan Channel可用於無鏈接的廣播通訊，後續文章會詳細介紹。

8）同一時刻，BT 設備只能在其中一個物理信道上通訊，爲了支持多個並行的操做，藍牙系統採用時分方式，即不一樣的時間點採用不一樣的信道。

　　BLE低功耗藍牙技術這樣定義信道：

1）ISM內整個頻帶分爲40份，每份的帶寬爲2MHz。在0 channel和39 channel以外設立guard band（保護帶寬，Lower Guard Band爲2MHz，Upper Guard Band爲3.5MHz）。

2）LE技術定義了2種物理信道，LE Piconet channel和LE Advertisement Broadcast Channel。

3）LE Piconet Channel用在處於鏈接狀態的藍牙設備之間的通訊，和BR同樣，採用調頻技術。和BR不同的地方是，只會在40個頻率channel中的37個上面跳頻。

4）LE Advertisement Broadcast Channel用於在設備間進行無鏈接的廣播通訊，這些廣播通訊可用於藍牙的設備的發現、鏈接（和BR/EDR相似）操做，也可用於無鏈接的數據傳輸。

5）和BR同樣，同一時刻，BT 設備只能在其中一個物理信道上通訊，爲了支持多個並行的操做，藍牙系統採用時分方式，即不一樣的時間點採用不一樣的信道。

AMP是爲高速數據傳輸設計的技術，也是傳統藍牙技術的一種，其物理層規範直接採用802.11（WIFI）的PHY規範，主要有以下特色：AMP物理信道只有一種，即AMP Physical Channel，主要用於已鏈接設備之間的數據通訊，和BR技術中的BR Adapted Piconet Physical Channel位於一個級別，能夠互相切換使用。

2.1.2 Physical Links

　　物理鏈路層，是對Physical Channel物理信道（主要是BR技術中的Basic Piconet Physical Channel和Adapted Piconet Physical Channel）的進一步封裝。

2.2 邏輯層

　　邏輯層的主要功能，是在已鏈接（LE Advertisement Broadcast能夠看作一類特殊的鏈接）的藍牙設備之間，基於物理鏈路，創建邏輯信道。所謂的邏輯信道，和城市道路上的車道相似：

一條城市道路能夠看作一個物理鏈路（咱們只考慮一個方向便可），該物理鏈路根據行車用途，能夠劃分爲多個邏輯信道，如直行車道、右轉車道、左轉車道、掉頭車道、快速車道、慢速車道等等。

和車道相似，藍牙邏輯信道的劃分依據是傳輸類型，主要包括下面3類（即Logical Link）：

1）用於管理底層物理鏈路的控制類傳輸。

2）傳輸用戶數據的用戶類傳輸，包括。

3）其它比較特殊的傳輸類型。

　　因爲Physical Channel是不可靠的，任何數據傳輸均可能因爲干擾等問題而損毀、丟失，這對有些應用來講，是接受不了的。所以Link Layer提供了校驗、重傳等機制，確保數據傳輸的可靠性；Link Layer還提供數據過濾機制，主要針對廣播通道，由於隨着通訊設備的增多，空中的廣播數據將會呈幾何級的增加，爲了不資源的浪費（特別是BLE Host），有必要在Link Layer過濾掉一些數據包，例如根據藍牙地址，過濾掉不是給本身的packet。

2.3 L2CAP Channels

　　L2CAP是Logical Link Control and Adaptation Protocol（邏輯鏈路控制和適配協議）的縮寫，它介於應用程序和Link Layer層之間的協議：

對下，它在用戶類Logical Link的基礎上，抽象出和具體技術無關的數據傳輸通道（包括單播和廣播兩類），至此用戶就再也不須要關心繁雜的藍牙技術細節。

對上，它以L2CAP channel endpoints的概念（相似TCP/IP中的端口），爲具體的應用程序（profile）提供獨立的數據傳輸通道（指的是邏輯通道）。

　　它提供的功能主要包括：通道的多路複用，對上層應用數據的分割和重組，生成協議數據單元（PDUs），以知足用戶數據傳輸對延時的要求，並便於後續的重傳、流控等機制的實現。

2.4 Profiles

　　profile是藍牙Application的代指，也能夠翻譯爲服務，爲了實現不一樣平臺下的不一樣設備的互聯互通，藍牙協議爲各類可能的、有通用意義的應用場景，都制定的了規範，如SPP、HSP、HFP、FTP、IPv6/6LoWPAN等等。

　　Profiles基於L2CAP提供的L2CAP channel endpoints實現，在它們對應的層次上進行數據通訊，以完成所需功能。

3、低功耗藍牙BLE廣播通訊原理

　　傳統藍牙BR雖然在協議底層有說起多播和廣播的概念，但在上層的應用場景中，更側重於點對點的通訊，幾乎不存在廣播相應的應用。而低功耗藍牙BLE相比傳統藍牙，最大的突破就是加大了對廣播通訊（Advertising）的支持和利用。

3.1 BLE廣播通訊使用場景

1）單一方向的、無鏈接的數據通訊，數據發送方在廣播信道上廣播，接收方掃描、接收數據。

2）鏈接的創建。

3.2 協議層次

　　BLE廣播通訊相關的協議層次：

GAP --> HCI --> Link Layer

　　LinkLayer(LL) 位於最底層，負責廣播通訊有關功能的定義和實現，包括物理通道的選擇、相關的鏈路狀態的定義、PDU的定義、設備過濾（Device Filtering）機制的實現等。

　　HCI負責將LL提供的全部功能，以Command/Event的形式抽象出來，供上層使用。

　　GAP負責從應用程序的角度，抽象並封裝LL提供的功能，以便讓應用以比較傻瓜的方式進行廣播通訊。

3.3 Link Layer

3.3.1 狀態定義

　　從LL層看，參與廣播通訊的BLE設備，可有三種狀態：　

Advertising，數據發送方，週期性的發送廣播數據；

Scanning，數據接收方，掃描、接收廣播數據；

Initiating，鏈接發起方，掃描帶有「可鏈接」標誌的廣播數據，一旦發現，則發起鏈接請求（都是由Link Layer自動完成，不須要上層軟件參與）。

3.3.2 PDU

　處於不一樣狀態的BLE設備能夠發送不一樣類型的PDU數據。

PDU格式：（具體每一個字段的意義如圖所標）

　　　　　　　　　　　　　　　　　　　　　　　　　　圖6 pdu格式

PDU類型：

　　　　　　　　　　　　　　　　　　　　　　　圖7 PDU類型

舉例：

1）若是隻須要定時傳輸一些簡單的數據（如某一個溫度節點的溫度信息），後續不須要創建鏈接，則可使用ADV_NONCONN_IND。廣播者只須要週期性的廣播該類型的PDU便可，接收者按照本身的策略掃描、接收，兩者不須要任何額外的數據交互。

2）若是除了廣播數據以外，還有一些額外的數據須要傳輸，因爲種種緣由，如廣播數據的長度限制、私密要求等，可使用ADV_SCAN_IND。廣播者在週期性廣播的同時，會監聽SCAN_REQ請求。接收者在接收到廣播數據以後，能夠經過SCAN_REQ PDU，請求更多的數據。

3）若是後續須要創建點對點的鏈接，則可以使用ADV_IND。廣播者在週期性廣播的同時，會監聽CONNECT_REQ請求。接收者在接收到廣播數據以後，能夠經過CONNECT_REQ PDU，請求創建鏈接。

4）經過ADV_IND/CONNECT_REQ的組合創建鏈接，花費的時間比較長。若是雙方不關心廣播數據，而只是想快速創建鏈接，剛好若是鏈接發起者又知道對方（廣播者）的藍牙地址（如經過掃碼的方式獲取），則能夠經過ADV_DIRECT_IND/CONNECT_REQ的方式。

3.3.3 Advertising狀態

　　BLE使用40個RF Channel（前文有述）中的3個做爲廣播信道，信道頻段信息等以下：

　　　　　　　　　　　　　　　　　　　　　　　圖8 廣播信道

　　BLE設備處於Advertising狀態的目的，就是要廣播數據。而且，根據應用場景的不一樣，可在3個channel上廣播4種類型的數據。

　　BLE協議對廣播通訊的指望，是很是明確的，不在意速率、只在意功耗。對於鏈接來講，若是事先不知道鏈接發起者的設備地址，則最快的鏈接速度多是20ms。若是事先知道地址，則可能在3.75ms內創建鏈接。由此能夠看出，BLE的鏈接創建時間，比傳統藍牙少了不少，這也是BLE設備之間不須要保持鏈接的緣由。

3.3.4 Scanning狀態

　　scanWindow指示一次掃描的時間，scanInterval指示兩次掃描之間的間隔。若是這兩個參數的值相同，表示連續不停地掃描。Scanning的掃描就是由　　　scanWindow和scanInterval兩個參數決定的。

　　BLE協議規定，scanWindow和scanInterval最大不能超過10.24s，而且scanWindow不能大於scanInterval。

　　Passive Scanning和Active Scanning

　　Passive Scanning稱做消極的掃描，是由於這種掃描模式下，BLE設備只聽不問，也就是說，只接收ADV_DIRECT_IND、ADV_IND、ADV_SCAN_IND、ADV_NONCONN_IND等類型的PDU，並不發送SCAN_REQ。而Active Scanning，不僅認真聽講，還勤於發問（SCAN_REQ），並接收後續的 SCAN_RSP。

　　這兩種Scanning的最終結果，就是把接收到的數據（包括Advertiser地址、Advertiser數據等），反饋給上層。

3.3.5 Initiating狀態

　　Initiating狀態和Scanning狀態相似，只不過它的關注點不同：它不關心廣播數據，只關心ADV_DIRECT_IND和ADV_IND兩類消息，並在符合條件的時候，發出CONNECT_REQ，請求創建鏈接。

3.3.6 設備過濾機制

　　若是多個BLE設備同時發廣播，Scanner怎麼過濾本身不想要的廣播，這時候設備過濾機制的白名單就上場了。LL層的白名單針對PDU三種類型（Advertising, Scanning, Initiating）分別有一個白名單，這個白名單能夠設置。　　　　　　　　

3.4 HCI

　　HCI層將Link Layer層提供的功能封裝成Command和Event。

3.4.1 HCI Command/Event模式

　　HCI Command格式：（參考「BLUETOOTH SPECIFICATION Version 4.2 [Vol 2, Part E]」）

　　其中OCF和OGF組成16bit的操做碼，Parameter Total Length，指示該Command全部參數長度，Parameter一、Parameter二、等等，16 bits的參數，由具體的Command決定。

　　HCI Event格式：

3.4.2 廣播通訊相關的HCI Command

　　BLE相關的HCI Comman使用的HCI Command的OGF都是0x08。

Advertising狀態有關的命令

1）HCI_LE_Set_Advertising_Parameters

設置廣播參數，包括Advertising Interval、Advertising Type、本機的地址類型、對端設備的地址類型和地址、所使用的物理Channel的map、Advertising白名單等。

2）HCI_LE_Set_Advertising_Data

設置廣播數據，OCF爲0x0008，Command參數的格式以下：

例如，下劃線依次表明OGF、OCF、Advertising Data Length、Advertising Data。

3）HCI_LE_Set_Scan_Response_Data

設置Scan請求時的應答數據，OCF爲0x0009，格式和HCI_LE_Set_Advertising_Data同樣。

4）HCI_LE_Set_Advertise_Enable

控制Advertising的使能與否，ICF爲0x000a，命令參數包括一個8 bits的「Advertising Enable」，以下：

hcitool -i hci0 cmd 0x08 0x000A 01

Scanning狀態有關的命令

1）HCI_LE_Set_Scan_Parameters

設置scan參數，包括Scan Type、Scan Interval、Scan Window、本機的地址類型、Scanning白名單等。

2）HCI_LE_Set_Scan_Enable

Scan動做的開關，其數據格式和HCI_LE_Set_Advertise_Enable一致。

Initiating狀態有關的命令

1）HCI_LE_Create_Connection

創建鏈接，可指定Sca Interval、Scan Window、Initiator Filter Policy、Peer Address Type、Peer Address、Own Address Type等Initiating有關的參數，也能夠指定鏈接相關的參數。

2）HCI_LE_Create_Connection_Cancel

取消鏈接。

白名單有關的命令

包括：

HCI_LE_Read_White_List_Size，獲取BLE Controller的白名單大小；

HCI_LE_Clear_White_List，清空白名單；

HCI_LE_Add_Device_To_White_List，將設備添加到白名單；

HCI_LE_Remove_Device_From_White_List，將設備從白名單移除；

3.5 GAP

3.5.1 GAP定義

　　對於廣播通訊，GAP主要的工做是Link Layer的「協議語言」，如Advertising、Scanning、Initiating等，轉換爲更爲直觀的「人類語言」以及定義掃描數據和廣播數據的統一規範。

　　GAP層把Link Layer層的狀態進行了又一次抽象，分別以下：

　　1）廣播模式以及解析過程。GAP爲該模式下的設備定義了兩個角色（GAP role）：Broadcaster（具備「Broadcast mode」能力）和Observer（具備「observation procedure」能力。

　　2）發現模式以及對應的發現過程。GAP爲該模式下的設備定義了兩個角色：Peripheral（被發現的設備）和Central（主動發現別人的設備）。不一樣的設備能夠選擇具備如下能力：

Non-Discoverable mode，不可被發現，設備不會廣播任何數據；Limited Discoverable mode，可被發現（有限的），指設備只會在有限的一段時間內，廣播數據；General Discoverable mode，可被發現（通用的）；Limited Discovery procedure ，可執行有限的發現操做，可發現處於「Limited Discoverable mode」的設備；General Discovery procedure ，可執行通用的發現操做，可發現處於「Limited Discoverable mode」和「General Discoverable mode」的設備；Name Discovery procedure，可進行Name的發現操做。若是經過Scanning操做沒有獲得廣播設備的名稱，使用該過程，能夠在創建鏈接以後，再獲取對方的名字。

　　3）鏈接模式以及對應的鏈接過程。全部四種角色的設備，Peripheral、Central、Broadcaster和Observer均可能涉及鏈接模式。

設備能夠選擇鏈接有關的模式：

Non-connectable mode，不可被鏈接的模式；Directed connectable mode，可被指定的設備鏈接；Undirected connectable mode，可被鏈接（不指定設備）；Auto connection establishment procedure，可自動鏈接模式；General connection establishment procedure，通用的鏈接過程等。

3.5.2 廣播數據格式

　　BLE協議31個bytes的廣播數據和掃描應答數據的格式以下：

　　　　　　　　　　　　　　　　　　　　　　圖9 廣播數據和掃描應答數據的格式

　　廣播數據/掃描應答數據一個個的AD Structure組成，未滿31bytes的數據由0填充；每一個ADStructure有1byte的長度信息（Data的長度），和剩餘的Data組成。

　　Data由AD Type和AD Data組成。其中AD Type能夠指定Service UUID，設備支持哪些profile；Local Name，設備的名稱； Flags，設備的GAP發現鏈接能力等。結合上面的例子，再分析下：

　　02 01 06，是一個AD Structure：Data的長度是02；Data是01 06；AD Type是01（Flags）；AD Data是06，代表支持General Discoverable Mode可被發現、不支持BR。

　　03 03 aa fe，是一個AD Structure：Data的長度是03；Data是03 aa fe；AD Type是03（16 bits的Service UUID）；AD Data是aa fe，是Eddystone profile的Service UUID。

　　17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00，是一個AD Structure：Data的長度是17（23bytes）；Data是16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00；AD Type是16（Service Data）；AD Data是aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00，是Eddystone profile具體的Service Data。

總結

　　讀罷全文，若是還有「似懂非懂、欲說還休」的感受，太正常了，畢竟藍牙協議是一個歷史悠久又比較龐大的協議，本文當一個學習筆記吧，之後遇到相關的問題，來這篇文章查查應該就能夠了。

參考文檔：

https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile

CSS(Core Specification Supplement)

https://github.com/google/eddystone/blob/master/protocol-specification.md

IPSP SPEC, 1.0, https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=296307

IETF RFC7668, IPv6 over BLUETOOTH(R) Low Energy, https://datatracker.ietf.org/doc/rfc7668/?include_text=1

LE_PSM_IPSP, https://www.bluetooth.com/specifications/assigned-numbers/logical-link-control

http://embedded-computing.com/articles/bluetooth-smart-and-zigbee-if-you-cant-beat-them-join-them/

https://developer.bluetooth.org/gatt/services/Pages/ServicesHome.aspx

https://tools.ietf.org/html/rfc4944