BLE4.0教程一 藍牙協議鏈接過程與廣播分析

1.藍牙簡介

什麼是藍牙4.0 算法

 

藍牙無線技術是使用範圍最普遍的全球短距離無線標準之一,藍牙4.0版本涵蓋了三種藍牙技術,即傳統藍牙、高速藍牙和低功耗藍牙技術,將三種規範合而爲一。它繼承了藍牙技術在無線鏈接上的固有優點,同時增長了高速藍牙和低功耗藍牙的特色。這三個規格能夠組合或者單獨使用。藍牙4.0規範的核心是低功耗藍牙(Low Energy),即藍牙4.0BLE。該技術最大特色是擁有超低的運行功耗和待機功耗,藍牙低功耗設備使用一粒鈕釦電池能夠連續工做數年之久。藍牙4.0技術同時還擁有低成本、向下兼容、跨廠商互操做性強等特色。安全

藍牙4.0 BLE的特色 服務器

藍牙4.0 BLE技術具備以下特色:網絡

1.高可靠性架構

對於無線通訊而言,因爲電磁波在傳輸過程當中容易受不少因素的干擾,例如,障礙物的阻擋、天氣情況等。所以,無線通訊系統在數據傳輸過程當中,具備內在的不可靠性。性能

藍牙技術聯盟(SIG)在制定藍牙4.0規範時已經考慮到了這種數據傳輸過程當中的內在的不肯定性,因此在射頻、基帶協議、鏈路管理協議(LMP)中採用可靠性措施,包括:差錯檢測和校訂、進行數據編解碼、差錯控制、數據加噪等,極大地提升了藍牙無線數據傳輸的可靠性。另外,使用自適應跳頻技術,最大程度地減小和其餘2.4GHz ISM頻段無線電波的串擾。加密

2.低成本、低功耗spa

低功耗藍牙支持兩種部署方式:雙模方式和單模方式。設計

(1)雙模方式,低功耗藍牙功能集成在現有的經典藍牙控制器中,或在現有經典藍牙技術(2.1+EDR/3.0+HS)芯片上增長低功耗堆棧,總體架構基本不變,所以成本增長有限。3d

(2)單模方式,面向高度集成、緊湊的設備,使用一個輕量級鏈接層(Link Layer)提供超低功耗的待機模式操做。藍牙4.0BLE技術能夠應用於8bit MCU,目前TI公司推出的兼容藍牙4.0BLE協議的SoC芯片CC2540/CC2541,外接PCB天線和幾個阻容器件構成的濾波電路便可實現藍牙網絡節點的構建。

低功耗設計:藍牙4.0版本強化了藍牙在數據傳輸上的低功耗性能,功耗較傳統藍牙下降了百分之九十。

傳統藍牙設備的待機耗電量大一直是其缺陷之一,這與傳統藍牙技術採用 16~32 個頻道進行廣播不無關係,而低功耗藍牙僅使用了3個廣播通道,且每次廣播時射頻的開啓時間也由傳統的 22.5ms 減小到 0.6~1.2ms,這兩個協議規範的改變,大幅下降了由於廣播數據致使的待機功耗。

低功耗藍牙設計了用深度睡眠狀態來替換傳統藍牙的空閒狀態,在深度睡眠狀態下,主機(Host)長時間處於超低的負載循環(Duty Cycle)狀態,只在須要運做時由控制器來啓動,因爲主機較控制器消耗的能源更多,所以這樣的設計也節省了最多的能源。

 

3.快速啓動,瞬間鏈接

此前藍牙版本爲人詬病的地方就在於啓動速度方面,藍牙2.1版本的啓動鏈接須要 6s 時間,而藍牙4.0版本僅僅須要3ms便可完成,幾乎是瞬間鏈接。

4.傳輸距離極大提升

傳統藍牙傳輸距離爲 2~10m,而藍牙4.0的有效傳輸距離可達到 60~100m,傳輸距離提高了十倍,極大開拓了藍牙技術的應用前景。固然,上述距離數值是在理想狀態下,實際使用過程當中由於各類因素的影響,好比:空氣溼度、其餘電磁信號干擾等等,致使實際距離可能達不到上述理論值,經過抗干擾等處理能夠提升實際的傳輸距離。

5.高安全性

爲了保證數據傳輸的安全性,使用AES-128 CCM加密算法進行數據包加密和認證。

藍牙4.0BLE無線網絡拓撲結構

藍牙4.0BLE網絡拓撲結構分爲星型拓撲和廣播組拓撲。不一樣的網絡拓撲對應不一樣的應用領域,在藍牙4.0BLE的無線網絡中,不一樣的網絡拓撲結構對網絡節點的配置有不一樣的要求(藍牙網絡節點的類型能夠分爲主機、從機,也能夠分爲服務器、客戶端,具體配置須要根據配置文件決定)。

 

 

 

 

2.藍牙的狀態以及基本鏈接過程

2.1 藍牙的狀態:

藍牙具備5種狀態:

待機狀態(standby)        :沒有鏈接任何設備,沒有傳輸和發送數據。

廣播狀態(Advertiser/advertising):週期性廣播狀態。

掃描狀態(Scanner/scanning)    :主動尋找正在廣播的設備。

發起鏈接狀態(Initiator/initiating):主動發起鏈接。

鏈接狀態(connected)        :已經鏈接。

 

2.2藍牙的角色

主設備 從設備

2.3藍牙的鏈接流程    

 

BLE鏈接流程

找公司服務比喻

Master

Slave

消費者

服務方

待機模式

待機模式

空閒

空閒

掃描模式

廣播模式

尋找公司

發廣告

掃描請求

掃描迴應

諮詢能提供什麼服務

告知服務

鏈接請求

 

簽署業務合同

 

鏈接參數請求

 

具體合同內容

 
 

參數更新請求

 

合同修改

參數更新迴應

 

合同迴應

 

創建鏈接

 

簽署合同

 

鏈接事件

 

開始業務合做

 

 

 

 

 

 

 

 

2.4鏈接事件和參數

2.4.1鏈接事件

主設備和從設備創建鏈接以後,全部的數據通訊都是在鏈接事件(Connection Events)中進行的。


 

尖刺的波就是鏈接事件(Connection events),剩下的Sleeping是睡眠時間,設備在創建鏈接以後的大多數時間都是處於Sleeping,這種狀況下耗電量比較低,而在鏈接事件(Connection events)中,耗電量就相對高不少,這也是BLE爲何省電的緣由之一。

每一個鏈接事件(Connection events)中,都須要由Master發起包,再由Slave回覆。

 

 

2.4.2鏈接參數

鏈接參數用於規定主從機數據通訊時間,若是鏈接參數設置不合理,就會致使鏈接斷開。

主要鏈接參數有如下三個:

鏈接間隔(Connection interval

 


(GAPROLE_MIN_CONN_INTERVAL && GAPROLE_MAX_CONN_INTERVAL)鏈接間隔,在BLE的兩個設備的鏈接中使用跳頻機制。兩個設備使用特定的信道發送和接收數據,而後過一段時間後再使用新的信道(BLE協議棧的鏈路層處理信道的切換)。

兩個設備在切換信道後發送和接收數據稱爲一個鏈接事件。儘管沒有應用數據被髮送和接收,兩個設備仍舊會交換鏈路層數據(空包 Empty PDU)來維持鏈接。

鏈接間隔就是指在一個鏈接事件(Connection events)的開始到下一個鏈接事件(Connection events)的開始的時間間隔。鏈接間隔以1.25ms爲單元,鏈接間隔的範圍是6 3200既7.5ms 4s之間。

 

 

 

從機忽略(Slave Latency


容許Slave(從設備)在沒有數據要發的狀況下,跳過必定數目的鏈接事件(Connection events),在這些鏈接事件(Connection events)中沒必要回復Master(主設備)的包,這樣就能更加省電。

範圍能夠是0 ~ 499

   

更詳細的使用解析以下:

 

Slave Latency = OFF也就是Slave Latency爲0時,Master發包,Slave必須回覆,若是不回覆,Master就會認爲Slave那邊接收不正常。

Slave Latency = ON也就是Slave Latency不爲0的時候,圖中Slave Latency爲 3。Master發包,Slave沒有數據要回復的時候,就會忽略 3 個鏈接事件,在第 4 個鏈接事件接收到Master發送的數據以後,回覆Master。若是Slave有數據要發送就會喚醒,也就是說即便Slave Latency爲 3,可是在Master發第二包的時候Slave有數據要回復,這個時候就會當即回覆Master而不是等到 3 個鏈接事件以後的第 4 個鏈接事件去回覆。

 

 

 

超時時間(Supervision Timeout


這個參數設定了一個超時時間,若是BLE在這個時間內沒有發生通訊的話,就會自動斷開。

單位是 10ms,該變量的範圍是10 ~ 3200,折算成時間範圍是100ms ~ 32s 。

鏈接間隔、從機時延以及超時時間這三者必須知足以下公式:

Supervision Timeout  > (1 +slaveLatency)* (connectionInterval)

上述公式必須知足,不然鏈接就會不正常斷開。

 

 

 

 

這三個鏈接參數不一樣狀況下對通訊速率和功耗的影響:

 

1.Connection Interval縮短,Master和Slave通訊更加頻繁,提升數據吞吐速度,縮短了數據發送的時間,固然也增長了功耗。

2.Connection Interval增加,通訊頻率下降,數據吞吐速度下降,增長了數據發送的時間,固然,這種設置下降了功耗。

3.Slave Latency減小或者設置爲 0,每次Connection Events中都須要回覆Master的包,功耗會上升,數據發送速度會提升。

4.Slave Latency加長,功耗降低,數據發送速度下降。

 

 

 

 

 

 

注意修改鏈接參數的時候要知足必定的要求:

1.安卓設備做主設備時,鏈接參數知足的要求見本篇博文第二節"鏈接參數介紹"中提到的內容。另外實際開發過程當中發現安卓設備做主設備時存在一個問題,就是部分安卓設備鏈接BLE設備以後,只能進行一次鏈接參數的修改。

 

2. 蘋果系統設備做主設備時,鏈接參數更新的要求比較苛刻,以下:

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

 

即:

最大鏈接間隔時間 *(從機延遲 + 1) ≤ 2s

最小鏈接間隔時間 ≥ 20 ms

最小鏈接間隔時間 + 20 ms ≤ 最大鏈接間隔時間

從機延遲 ≤ 4

超時時間 ≤ 6s

最大鏈接間隔時間 *(從機延遲 + 1)* 3  < 超時時間

 

因此若是你的BLE從設備須要被IOS主設備鏈接,那你的BLE從設備的默認申請的鏈接參數必定要知足上述要求,而且鏈接過程當中修改鏈接參數的時候也要知足上述要求。

 

 

 

 

3.藍牙廣播的協議

藍牙廣播相關的參數有如下幾種:

Advertising interval     廣播間隔

Advertising_Type        廣播類型

Own_Address_Type    自身地址類型

Direct_Address_Type    定向地址類型

Direct_Address        定向地址

Advertising_Channel_Map廣播信道(一個廣播有三個信道)

Advertising_Filter_Policy     廣播過濾策略

Advertising Data        廣播數據

ScanReponse Data        響應數據

 

 

 

 

Advertising_Type廣播類型

   

1. 可鏈接的非定向廣播(Connectable Undirected Event Type):

這是一種用途最廣的廣播類型,包括廣播數據和掃描響應數據,它表示當前設備能夠接受其餘任何設備的鏈接請求。進行通用廣播的設備可以被掃描設備掃描到,或者在接收到鏈接請求時做爲從設備進入一個鏈接。通用廣播能夠在沒有鏈接的狀況下發出,換句話說,沒有主從設備之分。

鑑於此種廣播類型用的最多,下面咱們來討論一下此類型下廣播事件中廣播包的發送狀況,另外要注意在一個廣播事件中,前一個"ADV_IND PDUs"的開始到相鄰的下一個"ADV_IND PDUs"的開始處的時間要小於等於10ms 

第一種狀況:僅僅有廣播 PDUs 。截圖顯示以下:

第二種狀況:在廣播事件的中間有"SCAN_REQ""SCAN_RSP PDUs"。截圖顯示以下:

   

第三種狀況:在廣播事件的結尾有"SCAN_REQ""SCAN_RSP PDUs"。截圖顯示以下:

第四種狀況:在廣播事件的中間接收到"CONNECT_REQ PDU"的狀況。截圖顯示以下

2. 可鏈接的定向廣播(Connectable Directed Event Type):

定向廣播類型是爲了儘量快的創建鏈接。這種報文包含兩個地址:廣播者的地址和發起者的地址。發起者收到發給本身的定向廣播報文以後,能夠當即發送鏈接請求做爲迴應。 

定向廣播類型有特殊的時序要求。完整的廣播事件必須每3.75ms重複一次。這一要求使得掃描設備只需掃描3.75ms即可以收到定向廣播設備的消息。 

固然,如此快的發送會讓報文充斥着廣播信道,進而致使該區域內的其餘設備沒法進行廣播。所以,定向廣播不能夠持續1.28s以上的時間。若是主機沒有主動要求中止,或者鏈接沒有創建,控制器都會自動中止廣播。一旦到了1.28s,主機便只能使用間隔長得多的可鏈接非定向廣播讓其餘設備來鏈接。

當使用定向廣播時,設備不能被主動掃描。此外,定向廣播報文的淨荷中也不能帶有其餘附加數據。該淨荷只能包含兩個必須的地址。

3. 不可鏈接的非定向廣播(Non-connectable Undirected Event Type):

僅僅發送廣播數據,而不想被掃描或者鏈接。這也是惟一可用於只有發射機而沒有接收機設備的廣播類型。不可鏈接廣播設備不會進入鏈接態,所以,它只能根據主機的要求在廣播態和就緒態之間切換。

4. 可掃描的非定向廣播(Scannable Undirected Event Type):

又稱可發現廣播,這種廣播不能用於發起鏈接,但容許其餘設備掃描該廣播設備。這意味着該設備能夠被發現,既能夠發送廣播數據,也能夠響應掃描發送掃描迴應數據,但不能創建鏈接。這是一種適用於廣播數據的廣播形式,動態數據能夠包含於廣播數據之中,而靜態數據能夠包含於掃描響應數據之中。

注意:所謂的定向和非定向針對的是廣播的對象,若是是針對特定的對象進行廣播(在廣播包PDU中會包含目標對象的MAC)就是定向廣播,反之就是非定向。可鏈接和不可鏈接是指是否接受鏈接請求,若是是不可鏈接的廣播類型,它將不迴應鏈接請求。可掃描廣播類型是指回應掃描請求。

不一樣的廣播類型對掃描請求和鏈接請求的不一樣結果以下圖:

   

 

   

 

Advertising And ScanReponse Data  (廣播和掃描迴應數據)

 

廣播數據和掃描迴應數據,它們的長度都不能超過31個字節(0 ~ 31),

數據的格式必須知足下圖的要求,能夠包含多個AD數據段,可是每一個AD數據段必須由"Length:Data"組成,其中Length佔用1個octet,Data部分佔用Length個字節,因此一個AD段的長度爲:Length+1。

格式圖以下所示:

 

 

 

注:1 octet = 1 byte = 8 bit

相關文章
相關標籤/搜索