Castle on a Cloud

在 BLE 5.1 中加入了對角度估測的支援, 此功能可以廣泛利用於室內定位的範疇, 提供公尺以下之定位精確度, 此定位功能利用多天線之技術, 估計目標裝置相對之角度, 又可以分成以下兩種估計之架構: AoA (Angle of Arrival) 和 AoD (Angle of Departure). 來自:  https://www.rohde-schwarz.com/ae/solutions/test-and-measurement/wireless-communication/ wireless-connectivity/bluetooth/bluetooth-direction-finding/bluetooth-direction-finding_251246.html 在 AoA 的架構下, 移動裝置需要單一天線, 並發送一特殊訊號 (DF-enabled packet), 固定裝置 (BLE Gateway, BLE GW) 擁有多根天線, 進行角度之估測, 在 DoA 的架構下, 移動裝置依然透過單一天線傳輸, 但是此時, 特殊的 DF-enabled packet 由 BLE GW 發出, 角度之估測則在移動裝置進行, 在 BLE 5.1 的架構下, 裝置必須發送一特殊訊號,  也就是上述的 DF-enabled packet, 其中 DF 為 Direction Finding  的縮寫, 此訊號的特色為包含一串 Constant Tone Extension (CTE) 訊號, 用以提供固定的波型 (waveform) 和頻率 (frequency) 的訊號, 以供接收端進行 IQ 的分解 (顯示收到訊號的的強度和相位改變), 進行之後之角度估測. https://www.bluetooth.com/wp-content/uploads/2019/05/BTAsia/1145-NORDIC-Bluetooth-Asia-2019Bluetooth-5.1-Direction-Finding-Theory-and-Practice-v0.pdf 在角度估測部分, 以 AoA 為例, 移動裝置發出 DF-enabled packet, 而 BLE GW 依序從不同天線接收,  因此, 每根天...

來自: https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/ 我們一樣從 BLE 的封包封裝開始介紹 L2CAP 協定, 在之前的介紹中, 我們介紹了 LL (Link Layer) 層的通訊協定, 在 LL 層的 payload 中, 我們可以加入更上層的封包格式, 在 BLE 協定中, 其中一種上層協定稱為 L2CAP (Logical Link Control and Adaptation Protocol), L2CAP 中主要負責功能如下: 封包的分段 (Segmentation) 重組與拆解 重傳與資料流控制 (Flow Control) 封裝 (Encapsulation) 與排程 (Scheduling) QoS 機制的支援 相對於底層封包傳送以 PDU (Packet Data Unit) 為單位, L2CAP 上層應用可以以 SDU (Service Data Unit) 來傳送資料, 一個 SDU 的大小最大可以為 64 KB, L2CAP 協定會將一個 SDU 按照 PDU 的大小進行重新切分與重組, 並將一個 Service 虛擬成一個邏輯通道 (L2CAP Channel), 讓上層應用進行存取. 為了完成上述功能, L2CAP 由兩個部分組成: Channel Manager, Resource Manager, 如下圖所示:  Figure 1.1: L2CAP architectural blocks in "Logical Link Control and Adaptation Protocol Specification" 對於一個 L2CAP Channel 而言, 對應一個 Channel ID (CID), 一個 CID 對應於一個 P2P 的 BLE 連線, 基於一個 CID, L2CAP 提供 Flow Control 與重傳機制, 對於 L2CAP 底下的 PDU 而言, L2CAP 提供檢查 CRC 和重傳機制, 考慮到 LL 層本身的重傳機制, PDU 會在連線失敗之前不斷重傳, L2CAP 實際上的 Flow Control 機制為控制 PDU ...

在上一篇文章中, 介紹了 BLE 5.0 的新功能, 其中, 其中有一項是 2Mbps 的物理層傳輸速率, 然而, 我們真實量測的網速為在 MAC 層的網路速度, 我們在計算 BLE 5.0 真實的 throughput 時, 必須考慮其 MAC 層的機制, 才能找出真實傳送時的速度. (事實上, 還要計入個層封包的 header 冗餘, 才能反映真實速度) 在 BLE 5.0 中, 影響 throughput 的 MAC 層因素包括下列四點: 每一個 Connection Interval 中的封包數量上限 封包間隔時間 (Inter Frame Space, IFS) 的長度 (150 ns) 用以回應 ARQ 的空封包 MAC 層的 header 冗餘 首先, 我們先看 MAC 層的冗餘, BLE 封包格式如下: https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/ 在 BLE 4.2 之後, payload 長度為 244 bytes, 在使用 2M PHY 時, 對應的 PDU 長度為 266 (2+4+257+3) bytes, 換句話說, 傳送一個封包中, 資料佔 244/266 的比例. 接下來, 我們要回答在一個 Connection Interval 內可以傳幾個封包, 這個問題來自於兩個限制: 第一, Connection Interval 必須高於所有封包 + IFS 的總時長 第二, 來自硬體 (BLE 晶片) 以及作業系統的限制, 當需要設計一個高速應用時, 要特別注意此來自於裝置與作業系統的限制, 並根據需求選擇適合的 Connection Interval 長度. 在接下來的討論中, 我們先忽視第二點限制, 來考慮所有封包所產生的總時間長度, 在 BLE 中, 下一個回傳的封包為傳送的封包的 ACK, 考慮到一個單向的 BLE 應用 (只有 master -> slave 的資料回報), 此時回傳的封包為一個空封包 (沒有 payload), 因此, 一次資料交換的流程為: IFS + data packet + IFS + empty packet, 如下圖所示: h...

本篇文章來源為:  https://www.novelbits.io/bluetooth-5-advertisements/ BLE 5.0 號稱有三大改良: 網速從 1Mbps 提升至 2Mbps 傳輸範圍提升 4 倍 廣播封包的 throughput 提升 8 倍 不過, 這些改良並不是同時完成, 和 BLE 4.2 相比, BLE 5.0 提供了兩種新的 PHY 層格式, 分別是對應高傳輸率的 2Mpbs (LE 2M), 以及透過錯誤更正碼保護對應高傳輸範圍的 PHY 層協議 (LE coded), 其中, 三種 PHY 層的協定如下圖所示: 來自:  https://www.novelbits.io/bluetooth-5-advertisements/ 在上表中, 我們可以看到, 當使用 LE coded 來延伸傳輸距離時, 傳輸速率並沒有提升, 反而是下降, 另一方面, 在廣播封包 (advertising) 部分, 和 BLE 4.2 相比, 新增了一種新的 Adverting, 稱為: Extended Advertisements, 和舊有的 Adverting (Legacy Advertisements) 相比, 新的規格可以使用所有的頻帶 (不只是 36, 37, 38), 也因此, 可以提供較寬頻的廣播通訊, 此功能應該是應對於 BLE Mesh 的技術, 考慮到 BLE Mesh 是以 Advertising 封包傳送, 其有效 throughput 並不高, BLE 5.0 可以針對此部分進行提升, 其基本想法也是在 {36, 37, 38} 上發送起始的封包, 並在 {0-36} 將剩餘封包傳輸, 因此, 此類的 Advertising 封包傳送機制, 就非常類似於舊有 BLE 中的一般封包傳送, 只不過, 現在傳送的對象是一整群的定閱使用者.

參考資料: https://www.cnblogs.com/iini/p/8977806.html http://leconiot.com/download/cc2640r2f/ble_stack_app/app_examples/exchange_mtu/exchange_mtu.html http://www.wowotech.net/bluetooth/le_encryption.html https://www.cnblogs.com/hzl6255/p/4127138.html http://www.wowotech.net/bluetooth/ble_connection.html https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/ 在藍牙通訊中, 我們可以先看一下整體的封包格式,  在這一篇文章中, 我們將先看到 PDU 這一層, 之後若有時間, 會繼續說明 L2CAP 和 ATT 的機制. 在 BLE 中, 基本的通訊單元稱為 PDU (Protocol Data Unit), 如下圖所示: 其中, Preamble 是用以辨別封包的開始, 大小為 8 個 bits, 分成兩種型態: 01010101, 10101010 Access Address, 則根據廣播封包或是通訊封包而不同, 廣播封包的位址固定為: 0x8E89BED6, 通訊封包則根據建立連線的對象而改變. CRC 則是用以保護 PDU 的資料傳輸. 在這篇文章中, 我們先專注在通訊封包的格式, 進入 PDU 封包後, 我們可以列出更詳細的資料格式: 其中, header 一共有 16 bits, 前 8 個 bits 的資訊為 LL header (Link Layer), 後 8 個 bits 為資料長度, 詳細說明如下: LLID (2): 指示接下來的封包為 L2CAP, 或是 LL control PDU NMSN (1), SN (1), MD (1): BLE 的 ARQ 和 Flow Control 機制 (之後會說明) RFU (3): 保留字元 (Reserved for...

在 BLE 通訊協定中, BLE 裝置透過 Advertising 告知周邊 BLE 裝置自己的存在, 其中, 考慮到 WiFi 的干擾, Advertising 封包在以下 3 個 bluetooth channel 上廣播: channel 37 (2402 MHz), channel 38 (2426 MHz), 和 channel 39 (2480 MHz), 我們可以利用下圖來了解其中干擾的關係: 來自:  https://www.infsoft.com/technology/sensors/bluetooth-low-energy-beacons 對於 connection 之後的資料傳輸, 則使用其他 bluetooth channel 進行通訊, 並藉由展頻通訊 (跳頻) 的方法, 對抗 WiFi 通訊產生的干擾, 透過不同的通訊目標, BLE 設計了 4 種不同的 advertising 的方式, 如下表所示: Advertising PDU Description Max Adv Data Len Max Scan Res Len Allow Connect ADV_IND Used to send connectable undirected advertisement 31 bytes 31 bytes Yes ADV_DIRECT_IND Used to send connectable directed advertisement N/A N/A Yes ADV_SCAN_IND Used to send scannable undirected advertisement 31 bytes 31 bytes No ADV_NONCONN_IND Used to send non-connectable undirected advertisement 31 bytes N/A No (來自:  Bluetooth Low Energy Scanning and Advertising ) Advertising Data (Adv Data) 代表在 advertising 封包中自帶的資訊, 在 BLE 中, 此資料的長度為 31 bytes. 更多的資訊...

在一般 BLE 裝置中, 不同的連線階段也扮演不同角色, 一般來說, 可以分成這四種 GAP Roles: GAP Role Description BROADCASTER A device that only sends advertising events. OBSERVER A device that only receives advertising events. PERIPHERAL A device that accepts the establishment of an LE physical link using the connection establishment procedure. CENTRAL A device that supports the Central role initiates the establishment of a physical connection. (來自: Bluetooth Low Energy Scanning and Advertising ) 其中, Broadcaster 和 Observer 為一對, 進行 adverting 通訊, Peripheral 和 Central 為一對, 進行資料傳輸, 為了表示此 4 種 GAP 腳色, BLE 可以表示為以下狀態機 (State Machine) 的轉換: 來自:  https://iot.electronicsforu.com/expert-opinion/improving-battery-life-in-bluetooth-low-energy-connected-things-part-2/ 其中, 我們可以看到 Connection 和 Advertising 分屬不同的狀態, 以 one-hot state machine 的概念來說, 在一個時間內應只屬於一個狀態, 至於上述 4 個 GAP Role 則使用了狀態機不同的部分, 如下圖所示: 來自:  https://iot.electronicsforu.com/expert-opinion/improving-battery-life-in-bluetooth-low-energy-conne...

在過往的 BLE 應用中, 其網路架構為點對點通訊, 換句話說,  藍牙連線的兩端, 為 master - client 的架構, 對於這樣的通訊連線, 兩個裝置在進行連線的開始, 會先藉由在特定頻帶上的廣播訊息 (advertising), 取得連線的需求, 先交換雙方跳頻序列 (hopping sequence), 為之後展頻通訊進行準備. 考慮到 BLE 的架構, 連線兩端分享共同的 hopping sequence, 在此通訊框架上, 難以擴展成廣播, 或是一對多通訊的模式, 在舊有的 BLE 星狀網路 (star network) 中, 雖然支援一對多的網路架構, 但對 master 節點來說負擔頗重, 對於多個 client 連線時, 也會導致資源分配下降, 在 2017 年, BLE 也提出了 Mesh 的架構, 其主要的想法在於: 透過廣播訊息和 relay 方法, 將傳輸資料從原始節點擴散出去, 如下圖所示: https://wiki.makerdiary.com/nrf52832-mdk/mesh/ 考慮到 BLE 的特性, 我們可以看到所有的節點必須分享相同的 hopping sequence, 同時, 節點 (Ndoe) 透過廣播 (ADV bearer) 將資訊傳出, 接著, 這些資訊再透過 Relay 節點 (Relay Node) 把資訊向外轉傳, 轉傳的數量, 則透過 TTL (time-to-life) 來限制轉傳的次數, 此流程稱為 message flooding. 此方法可以方便的建立一個 BLE 區域網路, 特別適用於智慧家庭等應用環境, 而無須特別針對裝置連線設定, 然而, 另一方面, 則會犧牲了傳送的 throughput, 對於大量的資訊流量而言, 也將因為相同的 hopping sequence, 而產生如 WiFi 般封包碰撞的問題, 而減損的展頻通訊抗干擾的能力, 比較適合 IoT 網路中, 小資訊的資訊 (如: 溫度, 狀態等) 回報.