原文地址：http://www.cnblogs.com/zjutlitao/p/4742428.html
聲明：這篇文章是樓主beautifulzzzz學習網上關於藍牙的相關知識的筆記，其中比較多的受益於xubin341719的藍牙系列文章，同時還有其他網上作者的資料。由於有些文章只做參考或統計不足，如涉及版權請在下面留言~
主要參考資料的來源：xubin341719[下面是該前輩的BT系列文章]
下載連接：Bluetooth PROFILE SPECIFICATIONS （基本涵蓋所有藍牙協議）、buletooth
core 2.1-4.0 SPECIFICATION（三藍牙版本的核心協議v2.1\v3.0\v4.0）、藍牙核心技術與應用
馬建倉 版（藍牙協議相關初學者必讀，開發者參考）
藍牙核心技術概述（一）：藍牙概述
藍牙核心技術概述（二）：藍牙使用場景
藍牙核心技術概述（三）： 藍牙協議規範（射頻、基帶鏈路控制、鏈路管理）
藍牙核心技術概述（四）：藍牙協議規範（HCI、L2CAP、SDP、RFOCMM）
藍牙核心技術概述（五）：藍牙協議規範（irOBEX、BNEP、AVDTP、AVCTP）
有道筆記分享鏈接：http://note.youdao.com/share/?id=950d00cefa9b7fd3c559eec349805b24&type=note
藍牙，是一種支持設備短距離通信（一般10m內）的無線電技術。能在包括移動電話、PDA、無線耳機、筆記本電腦、相關外設等衆多設備之間進行無線信息交換。利用“藍牙”技術，能夠有效地簡化移動通信終端設備之間的通信，也能夠成功地簡化設備與因特網Internet之間的通信，從而數據傳輸變得更加迅速高效，爲無線通信拓寬道路。藍牙採用分散式網絡結構以及快跳頻和短包技術，支持點對點及點對多點通信，工作在全球通用的2.4GHz ISM（即工業、科學、醫學）頻段。其數據速率爲1Mbps。採用時分雙工傳輸方案實現全雙工傳輸。
Bluetooth的系統構成
2、基帶或鏈路控制單元(LinkController)：進行射頻信號與數字或語音信號的相互轉化，實現基帶協議和其它的底層連接規程。
3、鏈路管理單元(LinkManager)：負責管理藍牙設備之間的通信，實現鏈路的建立、驗證、鏈路配置等操作。
4、藍牙軟件協議實現：如上圖紫色部分，這個後面我們做詳細說明。
藍牙協議體系中的協議按SIG的關注程度分爲四層：
1.核心協議：BaseBand、LMP、L2CAP、SDP；2.電纜替代協議：RFCOMM；
3.電話傳送控制協議：TCS-Binary、AT命令集；
4.選用協議：PPP、UDP/TCP/IP、OBEX、WAP、vCard、vCal、IrMC、WAE。
除上述協議層外，規範還定義了主機控制器接口（HCI），它爲基帶控制器、連接管理器、硬件狀態和控制寄存器提供命令接口。在圖1中，HCI位於L2CAP的下層，但HCI也可位於L2CAP上層。
藍牙核心協議由SIG制定的藍牙專用協議組成。絕大部分藍牙設備都需要核心協議（加上無線部分），而其他協議則根據應用的需要而定。總之，電纜替代協議、電話控制協議和被採用的協議在覈心協議基礎上構成了面向應用的協議。
藍牙協議棧允許採用多種方法，包括 RFCOMM 和 Object Exchange （OBEX ）， 在設備之間發送和接收文件。如果想發送和接收流數據（而且想採用傳統的串口應用程序，並給它加上藍牙支持），那麼 RFCOMM 更好。反過來，如果想發送對象數據以及關於負載的上下文和元數據，則 OBEX 最好。
藍牙應用程序活動圖，如下：
2.1.1 串口仿真RFCOMM介紹
找到服務，RFCOMM是通過不同的頻道（channel）來提供不同的Profile的，所以需要找到要用的服務在設備上的哪個頻道上，這是通過同一個軟件包裏的sdptool來完成的，就是SDP，服務發現協議
2.2 藍牙profile
從3.0版本開始（據說2.1也是支持的？TBD），藍牙纔開始支持BluetoothProfile。BluetoothProfile是藍牙設備間數據通信的無線接口規範。想要使用藍牙無線技術,設備必須能夠翻譯特定藍牙配置文件,配置文件定義了可能的應用.
① 與其他配置文件的相關性
② 建議的用戶界面格式
③ 配置文件使用的藍牙協議堆棧的特定部分.
② 發現和鏈接設備的通用步驟
③ 基本用戶界面術語.
GOEP爲使用OBEX協議的其他配置文件提供了通用藍圖,併爲設備定義了客戶端和服務器角色.對於所有的OBEX事務.GOEP規定應由客戶端啓動所有事務.但是此配置文件並沒有描述應用程序就如何定義要交換的對象或如何實施交換.這些細節留給屬於GOEP的配置文件.即OPP,FTP和SYNC去完成.通常使用此配置文件的藍牙設備爲筆記本電腦,PDA,手機及智能電話.
SPP是基於RFCOMM的，spp 協議處於rfcomm的上層，spp的應用需走rfcomm層。如果你使用RFCOMM能夠實現，那麼也就不需要使用SPP，而卻速度還會比SPP來做快，因爲省略了採用profile的一些數據包頭等。不過，還是推薦採用SPP來做，兼容性有保證，這也是爲什麼藍牙本質上數據和語音的傳送卻出現HFP，HSP，SPP，OPP等諸多具體應用profile的原因。
每個attribute屬性被UUID（通用唯一標識符）唯一標識 ，UUID是標準128-bit格式的ID用來唯一標識信息。attributes 被 ATT 格式化characteristics和services形式進行傳送。
特徵（Characteristics）— 一個characteristics包含一個單獨的value值和0 –n個用來描述characteristic 值（value）的descriptors。一個characteristics可以被認爲是一種類型的，類似於一個類。
描述符(descriptor)—descriptor是被定義的attributes，用來描述一個characteristic的值。例如，一個descriptor可以指定一個人類可讀的描述中，在可接受的範圍裏characteristic值，或者是測量單位，用來明確characteristic的值。
服務（service）—service是characteristic的集合。例如，你可以有一個所謂的“Heart RateMonitor”service，其中包括characteristic，如“heart rate measurement ”。你可以在 bluetooth.org找到關於一系列基於GATT的profile和service。
如上圖所示：藍牙設備可以包括多個Profile，一個Profile中有多個Service，一個Service中有多個Characteristic，一個Characteristic中包括一個value和多個Descriptor。
② Android4.3（API級別18）引入內置平臺支持BLE的central角色，同時提供API和app應用程序用來發現設備，查詢服務，和讀/寫characteristics。與傳統藍牙（ClassicBluetooth）不同，藍牙低功耗（BLE）的目的是提供更顯著的低功耗。這使得Android應用程序可以和具有低功耗的要求BLE設備，如接近傳感器，心臟速率監視器，健身設備等進行通信。
③ BLE低功耗藍牙軟件有2個主要組成： OSAL操作系統抽象層和 HAL硬件抽象層，多個Task任務和事件在OSAL管理下工作，而每個任務和事件又包括3個組成：BLE 協議棧，profiles和應用程序。
通用屬性規範（GATT）—GATTprofile是一個通用規範用於在BLE鏈路發送和接收被稱爲“屬性（attributes）”的數據片。目前所有的低功耗應用 profile都是基於GATT。
藍牙SIG定義了許多profile用於低功耗設備。Profile（配置文件）是一個規範，規範了設備如何工作在一個特定的應用場景。注意：一個設備可以實現多個profile。例如，一個設備可以包含一個心臟監測儀和電池電平檢測器。
主從機連接建立過程:
低功耗藍牙模塊主透傳協議是針對低功耗藍牙模塊從透傳協議設計的，通過本協議模塊可替代手機設備與從透傳協議模塊連接，實現透傳功能或直驅控制功能。此協議模塊可用作從透傳協議模塊開發過程中的輔助工具。
BLE主透傳協議模塊（以下簡稱MTTM）可以工作在透傳模式（TTM）或指令模式（CM）。
MTTM上電啓動後，處於待機模式（SBM），此時處於空閒狀態，無睡眠，需要用戶通過AT指令控制模塊連接從設備。在成功與從設備建立鏈接後，MTTM會自動查找從設備的透傳通道，如果從設備屬於BLE從透傳協議模塊（以下簡稱STTM），MTTM默認進入透傳模式，否則默認進入指令模式。
透傳模式下，用戶CPU可以通過模塊的通用串口與STTM進行雙向通訊。從MTTM串口輸入的數據將轉發到STTM，並從STTM的串口輸出；從STTM輸入的數據將轉發到MTTM，並從MTTM的串口輸出，從而實現透明傳輸功能，用戶數據的具體含義由上層應用程序自行定義。
透傳中數據的格式也是profile，或藍牙標準profile或自定義simple profile。基本結構依然是：
服務和特徵都是用UUID來唯一標識的，UUID的概念如果不清楚請自行google,國際藍牙組織爲一些很典型的設備(比如測量心跳和血壓的設備)規定了標準的service UUID(特徵的UUID比較多，這裏就不列舉了)
（三）Android Bluetooth 架構
iOS 有兩個框架支持藍牙與外設連接。
一個是 ExternalAccessory。從ios3.0就開始支持，也是在iphone4s出來之前用的比較多的一種模式，但是它有個不好的地方，External Accessory需要拿到蘋果公司的MFI認證。
另一個框架則是本文要介紹的CoreBluetooth，在藍牙4.0出來之後（注意，硬件上要4s以上，系統要ios6以上才能支持4.0），蘋果開放了BLE通道，專門用於與BLE設備通訊（因爲它的API都是基於BLE的）。這個不需要MFI，並且現在很多藍牙設備都支持4.0,所以也是在IOS比較推薦的一種開發方法。現CoreBluetooth在的開發幾乎全部基於該框架，本節只介紹CoreBluetooth。
1，CoreBluetooth介紹
CoreBluetooth框架的核心其實是兩個東西，peripheral和central, 可以理解成外設和中心。對應他們分別有一組相關的API和類，如下圖所示:
如果你要編程的設備是手機的central，那麼你大部分用到peripheral API。反之亦然，設備是peripheral，iphone手機是central,所以將大部分使用central API。使用peripheral編程的例子也有很多，比如像用一個ipad和一個iphone通訊，ipad可以認爲是central，iphone端是peripheral,這種情況下在iphone端就要使用上圖右邊部分的類來開發了。
作爲一箇中心（central）要實現完整的通訊，一般要經過這樣幾個步驟：
（1）建立中心角色—（2）掃描外設（discover）（通過接收從設備廣播來掃描、發現設備，獲得peripheral ID）—
a, 如果數據中已經和某些藍牙設備綁定，可以使用BluetoothAdapter.getBondedDevices();方法獲得已經綁定的藍牙設備列表。通過指定特定的peripheral的UUID,central只會discover這個特定的設備。
b, 搜索周圍的藍牙設備受用BluetoothAdapter.startDiscovery()方法
c, 搜索到的藍牙設備都是通過廣播返回，so..。需要註冊廣播接收器來獲得已經搜索到的藍牙設備
（4）掃描外設中的服務和特徵(discover)（一個設備裏的服務和特徵往往比較多，一般會在發現服務和特徵的回調裏通過service、characteristic UUID去匹配我們關心那些）—
（5）與外設做數據交互(explore and interact)—
（6）斷開連接(disconnect)。
2, 設備ID描述DID
每個與蘋果設備兼容的藍牙接入都必須：支持藍牙設備ID描述，1.3版本或者更高；使用藍牙SIG分配的Assigned Numbers文檔中的公司標識作爲他的Vendor ID值，也就是VID，如果生產商沒有藍牙SIG公司標識，那麼藍牙HID描述接入可能會使用USB Implementers Forum分配的VID；使用他的VID值來標識最終的產品生產商；使用版本值來唯一標識軟件的版本；使用ProductID值唯一標識產品。Device ID描述使得蘋果產品能夠識別遠程的藍牙接入，該信息可以用來在與遠程接入交互的時候連接藍牙描述間的交替互操作。因此Device ID中的信息記錄非常重要。
理想情況下，這兩個設備應該有不同的產品ID。但是，當他們擁有完全相同的硬件、軟件和特性的時候擁有相同的ProductID也是可以允許的。如果他們有任何的不同，就都應該有不同的Product ID。
3，IOS的藍牙低功耗
藍牙4.0標準引入了藍牙低功耗，一種針對有限電池資源的藍牙接入的無線技術。如果支持藍牙低功耗的話，接入點需要支持下面的這些特性。（這裏更多的是藍牙芯片商要做的事情）
角色
藍牙接入需要實現藍牙4.0標準中定義的外圍角色
廣告通道
藍牙接入需要在所有三個廣告通道中針對每個廣告事件進行廣告
廣告PDU
藍牙接入需要使用如下廣告PDU中的一個：ADV_IND；ADV_NOCONN_IND；ADV_SCAN_IND。其中ADV_DIRECT_IND不推薦使用。
廣告數據
由藍牙接入發送的廣告信息應該至少包含藍牙4.0標準中包含的如下信息：Flags；TX Power Level；Local Name；Services。如果需要降低電量消耗或者並不是所有的廣告數據都適合放入到廣告PDU中的時候，接入點可能將Local Name和TX Power Level數據方知道SCAN_RSP PDU中。需要注意的是根據它的狀態，蘋果產品可能不會總是執行激活掃描。主要的服務應該總是放在廣告PDU中進行廣告。次要的服務不應該進行廣告。對於接入點不重要的服務信息可能會因爲廣告PDU中的空間不足而被忽略。廣告數據和SCAN_RSP PDU中的掃描響應數據應該遵循藍牙4.0標準中的格式。
廣告間隔
藍牙接入的廣告間隔應該慎重考慮，因爲他會影響到發現和連接的性能。對於低功耗的接入，電池資源也應該被考慮在內。爲了能夠被蘋果產品發現，藍牙接入應該首先使用推薦的廣告間隔20ms，並持續至少30秒。如果在這30秒內沒有被發現，那麼接入點可能會選擇節省電池電量然後增加廣告間隔，蘋果推薦使用如下依次延長的事件間隔來發現藍牙接入點：645 ms；768 ms；961 ms；1065 ms；1294 ms
連接參數
藍牙接入負責用來LE連接的連接參數。接入點需要請求合適的連接參數來在合適的時候發送一個L2CAP連接參數跟新請求。如果他沒有符合如下規則，那麼連接參數請求可能會被拒絕：Interval Max * (Slave Latency + 1) ≤ 2 seconds；Interval Min ≥ 20 ms；Interval Min + 20 ms ≤ Interval Max；Slave Latency ≤ 4；connSupervisionTimeout ≤ 6 seconds以及Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout。蘋果設備不會讀取或者使用Peripheral Preferred Connection Parameters特性中的參數。
隱私
藍牙接入應該在任何情況下都能夠滿足Resovable Private Address。因爲私隱方面的考慮，蘋果設備將會使用藍牙4.0標準中定義的隨機設備地址。
授權
藍牙接入不需要請求特殊的授權，如配對、認證或加密等來發現服務和特性。只有在獲取特性值或者描述值的時候可能會需要特殊的授權。9
配對
藍牙接入不應該請求配對。如果處於安全考慮，接入點需要與Central建立綁定關係，外圍可以使用Insufficient Authentication錯誤碼在必要的時候拒絕ATT請求。因此蘋果設備可能會需要按照既定的安流程程來執行過程。配對可能會需要基於蘋果產品的用戶認證。
服務
通用接入描述服務：藍牙接入應該實現按照藍牙標準4.0中的Device Name特性
通用屬性描述服務：只有當接入有能力在生命週期內更改他的服務的時候，該接入點才需要實現Service Changed特性。蘋果產品可以使用Service Changed服務特性來決定它是否可以使用之前讀取的或者緩存的來自設備的信息。
設備信息服務：藍牙接入應該實現設備信息服務。服務的UUID不應該包含在廣告數據當中。如下的特性需要被支持：Manufacturer Name String；Model Number String；Firmware Revision String；Software Revision String
4，IOS APP開發 的藍牙操縱API
手機APP要想獲得藍牙設備的一些額外的信息如電量或者操作藍牙設備，必須通過IOS API。那麼IOS底層必然有某種方式來與藍牙設備交互。 那麼電量通過什麼來讀寫呢？自定義 service characteristic？
任何免提的藍牙耳機都可以在iOS設備的狀態欄中顯示一個用來標識他電池電量的圖標。這個特性被所有的iOS設備所支持，包括iPhone、iPod和iPad。耳機的藍牙知識通過兩個iOS藍牙HFP AT命令：HFP Command AT+XAPL
HFP命令AT+XAPL
- 描述：允許通過耳機自定義AT命令
- 發起者：耳機
- 格式：AT+XAPL=[vendorID]-[productID]-[version],[features]
- 參數：
- vendorID: 標識生產商的vendor ID的十六進制表示，但是沒有0x前綴
- productID: 標識生產生的product ID的十六進制表示，但是沒有0x前綴
- version: 軟件的版本
- features: 用10進制標識的位標識:
- 1 = 耳機支持電池電量報告
- 2 = 耳機暫停或者正在充電
- 其他值保留
- 例子: AT+XAPL=ABCD-1234-0100,3
- 響應: +XAPL=iPhone,[features]
HFP命令AT+IPHONEACCEV
- 描述：報告耳機的狀態變更
- 發起者：耳機
- 格式：AT+IPHONEACCEV=[Number of key/value pairs ],[key1 ],[val1 ],[key2 ],[val2 ],...
- 參數：
- Number of key/value pairs : 接下來參數的數量
- key: 被報告狀態變化的類型
- 1 = 電量等級
- 2 = 暫停狀態
- val: 更改的值
- Battery events:0-9之間數字的字符串 A string value between '0' and '9'.
- Dock state: 0 = undocked, 1 = docked.
- Example: AT+IPHONEACCEV=1,1,3
