(主要為備份參考用，此文在BLE架構分析上相當清楚細膩)
Bluetooth Low Energy: The Developer's Handbook 讀書筆記 (3)
http://www.amazon.com/Bluetooth-Low-Energy-Developers-Handbook/dp/013288836X
==============
Part 1 : Overview
Chapter 3: BLE 架構
BLE 架構很簡單如下圖, 會分 Application, Host, Controller 三塊:
這個章節就會對下圖這幾個方塊做一個概念性的介紹
(Figure from: https://developer.bluetooth.org/TechnologyOverview/Pages/BLE.aspx)
[Controller]
一般被稱作是 Bluetooth radio 或是 Bluetooth chip, 它包含了 RF 處理 analog / digital 的部分, 包含硬體的部分, 負責 TX/RX (傳送/接收) Bluetooth 封包
(Figure from BLE SPEC, LL 的封包格式)
[Host]
Host 包做的事情有 Multiplexing (L2CAP), Authentication (SM), expose state data (Attribute
Protocol), 定義 Attribute Protocol 如何重複利用 services 來讓裝置的 characteristics 可以被存取到 (Generic Attribute Profile), 以及定義裝置如何找到其他裝置並做連線 (Generic Access Profile).
註: Host 上面並沒有定義 interface (不向 HCI), 所以 API 是由各廠商自己訂的.
[Application]
Application Layer 在最上層, 定義了三種規範: characteristic, service, and profile
每一個規範都是基於 Generic Attribute Profile (GAP) 所定義的, GAP 會定義多個 attributes groups 來表示 services 和 characteristics, 而 Applications 定義了如何去使用這些 attribute groups
[Stack 劃分]
上面提到的 BLE 架構, 不一定得全都在同一個 Chip, 是可以做劃分的, 如下圖每個方塊都可以當作一個 Chip, 所以可以看到有各種組合的可能, 而 Chip 之間都有 interface 可以做 interaction, 這些不同的 solutions 可以用在不同的需要上.
(Figure created by Jackal Chen)
這本書是市面上 BLE Protocol 介紹的書裡我覺得最好的, 內容很深入, 算是介於入門書跟SEPC之間的地位, 最近也出了大陸簡體中文版, 懶得看英文的可以買來看, 百度也有線上版可以看, 但我強烈建議看英文版就是了, 畢竟 SPEC 是寫英文...
本篇使用的圖片, 有些來自網路電子書, 有些來自網路, 若有疑慮請通知我, 我會把它移除!
(Some figures in this article are captured from internet or e-book. If there is a violation of copyright. consideration. Please tell me and I i will remove it immediately)
本篇使用的圖片, 有些來自網路電子書, 有些來自網路, 若有疑慮請通知我, 我會把它移除!
(Some figures in this article are captured from internet or e-book. If there is a violation of copyright. consideration. Please tell me and I i will remove it immediately)
==============
Part 1 : Overview
Chapter 3: BLE 架構
BLE 架構很簡單如下圖, 會分 Application, Host, Controller 三塊:
- Controller: 負責 PHY/LL 的部分, 也就是收送無線電訊號 (Radio Signals), 以及將訊號轉換成封包資料的部分
- Host: 就是軟體 Protocol 本身, 管理 devices 之間的連線, 以及如何將多個 services 資料由 radio 送出, 或是將收到的資料解成多個 services
- Application: 使用 Host 來達到使用的案例
這個章節就會對下圖這幾個方塊做一個概念性的介紹
(Figure from: https://developer.bluetooth.org/TechnologyOverview/Pages/BLE.aspx)
[Controller]
一般被稱作是 Bluetooth radio 或是 Bluetooth chip, 它包含了 RF 處理 analog / digital 的部分, 包含硬體的部分, 負責 TX/RX (傳送/接收) Bluetooth 封包
- Physical Layer
- 負責在 2.4 GHz 下做 radio TX/RX 的工作
- Modulation scheme (我不會翻, 調解方案?) 是使用 Gaussian Frequency Shift Keying (GFSK)
- Shift Keying 意思就是 0/1 是利用頻率的上下移位來表示
- 然後利用 Gaussian filter 來讓頻率不會位移的太嚴重, 形成 Gaussian curve 的波形
- 在利用展頻的技術, 當離中心點 > 185kHz 就當作 1, < 185kHz 就當 0
- BLE PHY 的能力是 1us 傳輸 1 bit
- 註: 這邊真的有講跟沒講差不多, 我對通訊也沒到很熟, 真的要講可能之後章節有比較多的圖來解釋會比較易懂, 這邊 PHY 的部分看看就好..
- Direct Test Mode
- 用來測試 PHY 的功能, 大多的無線通訊技術其實對策是 PHY 並沒有一個標準, 所以有的公司會自己做自己的測試 PHY 的方式, 增加 Cost 的考量
- 利用這個 Direct Test Mode 可以直接控制 PHY 做 TX/RX 資料並分析判斷 PHY 行為正確性
- Direct Test Mode 也可以用來量測 RF 參數, 並可以被用來做產線的測試以及 RF 的校準
- Link Layer
- 主要功能是處理廣播 (advertising), 掃描 (scanning), 以及建立和保持連線 (connections), 並確保資料有正確的封包格式, 並執行 CRC check 以及處理加密, 這些工作由以下三的部分組成
- Channels
- advertising channels
- 還沒連線時使用來廣播連線訊息, 會有 3 個 advertising channels, 然後 scanner 也會去掃描這些 channels, 發現裝置並執行連線的動作
- data channels
- 當連線建立後, 就使用 data channels 來收跟傳資料, 會有 37 個 data channels, 並透過 adaptive frequency-hopping (選擇性跳頻) 來達到傳輸的穩定性 (避開干擾)
- data channel 還有其他功能如 ACK (acknowledgement), RETX (重傳) 以及針對每個封包為單位作加密
- Packets
- 封包 (packet) 就是一些資料依據格式做的封裝單位, 目的是可以在很短時間內收送, 所以長度很短, advertising/data channel 的封包格式都市長一樣的, 可以參考下方的 LL 封包格式圖
- 8-bit Preamble: 讓接收端做 time sync 以及 power 量測用的
- 32-bit access address: 對於 advertising channel 是固定值但 data channel 則是 random/private 的
- PDU (2-39 bytes): LL 的要處理的資料
- 會包含 2 bytes PDU header, 主要是 PDU type 以及一些 flags 還有 PDU payload length
- 以及包含 0-37 bytes PDU payload
- 24-bit CRC: 用來檢查此 packet 是否有 error 發生, 確保 packet 內容的正確性
- Procedures
- Procedures 包含一些如建立連線, Pairing, Bonding, 加密等等的步驟, 之後細講 LL 才會帶到
- Host/Controller Interface
- 簡稱 HCI, 是 Host 用來跟 Controller 溝通的標準介面, 因為在傳統 BT 的架構下, 有 60% 的 Controller 是透過 HCI 來控制的 (也就是 Controller 是一顆獨立的 Chip 而 Host/App 再另一顆 Chip, 智慧手機就是一個例子)
- HCI 會分成 logical interface 以及 physical interface
- Logical Interface
- 定義了 commands (指令) 以及 events (事件), 以及當收到指令或是發生事件對應的行為是什麼
- 此 interface 可以透過實體方式傳送資料 (commands & events) 或是透過定義 API 的方式, 讓 Host 可以使用 (host/controller 同一個 chip 的情況下)
- Physical Interface
- 定義了 commands/events/data 如何傳輸 (with Host)
- 常見的有如 SDIO / USB / UART 等介面
- 一般 controller 會支援 1-2 種介面, 而 USB 因為是比較耗電且 cost 比較高的介面, 所以通常 single mode chip (BLE only) 不會支援 USB
- HCI 要同時存在於 controller 以及 host, 這樣才有辦法溝通, 所以我們會把 controller 的部分稱為 lower-host controller interface 而 host 的部分稱為 upper-host controller interface
[Host]
Host 包做的事情有 Multiplexing (L2CAP), Authentication (SM), expose state data (Attribute
Protocol), 定義 Attribute Protocol 如何重複利用 services 來讓裝置的 characteristics 可以被存取到 (Generic Attribute Profile), 以及定義裝置如何找到其他裝置並做連線 (Generic Access Profile).
註: Host 上面並沒有定義 interface (不向 HCI), 所以 API 是由各廠商自己訂的.
- Logical Link Control and Adaptation Protocol (L2CAP)
- BLE 的 multiplexing Layer (簡單來說就是將資料用正確的格式分出去 or 聚集起來, 中文是多工 & 解多工)
- L2CAP channel
- 一條雙向的資料通道 (裝置之間的 L2CAP)
- 每一條 L2CAP channel 都是獨立的, 有各自的 flow control 以及設定
- BLE 使用三條固定的 channel
- 一條是 signaling channel (做控制用的)
- 一條是和 SM 之間
- 一條是和 Attribute Protocol 之間
- 封包格式稱為 B-frame (最下圖可以看到), 簡化設計 (傳統 BT 格式會比較多種, 但 BLE 都只用 B-Frame Type)
- 2 bytes 資料長度
- 2 bytes Channel ID
- 最後就是 LL2CAP PDU Payload
- L2CAP signaling commands
- 即在 signaling channel 上傳輸的 command, 之後會在比較細節的討論到
- Security Manager Protocol
- 負責 pairing 以及 key distribution
- pairing 就是 device 之間互相取得信任的程序, pairing 後就會用加密的連線做 key distribution. (pairing 過程中 SM 會產生 hash, confirm value, short term key 等等)
- key distribution 就是 slave 把加密資訊送給 master, 所以重新連線後, 就可以用這個加密資訊來加密資料做安全性的傳輸
- Attribute Protocol
- 定義了存取 peer device (對方裝置) 資料的"規則"
- Server 的資料存放在 Attribute 中, Client 可以送需求 (Request) 給 Server 並藉由 Server 回復 (Response) 得知 Server 的 Attributes 並做 Attributes 讀寫, Server 其實也可以自己送 Message 給 Client, 端看 Message 的類型
- Attribute Protocol 定義六種 Message 類型:
- 1) Request (Client -> Server)
- 2) Response (Server -> Client, 回覆 Request 用)
- 3) Commands (Client -> Server, 不用 Response)
- 4) Notifications (Server -> Client, 不用 Confirm)
- 5) Indications (Server -> Client, 需要 Confirm)
- 6) Confirmations (Client -> Server, 為了回覆 Indication)
- 每一個 Attribute 就是一個有位址有標籤的資料
- 會有一個 unique handle 來辨識此 Attribute
- 此 Attribute 會有個 Type 來敘述此 Attribute 存放什麼資料, 例如溫度資料, 例如心跳資料
- Attribute Protocol 也定義了 Attributes 的權限 (Permissions)
- Read
- Write
- Authenticated Read
- Authenticated Write
- 註: 對於需要 Authentication 的部分, Client 若沒有正確的 Authenticated, 發出去的需求只會得到 Error, Client 並不會知道到底真正的權限是什麼
- Attribute Protocol 為 stateless (無狀態的), 每一個動作 (transaction), 例如 Read/Write, 狀態都不會被記住 (可以想成每一個 transaction 都是獨立的), 所以 Attribute Protocol可以節省記憶體, 唯一一個需要記的prepare and write request 這個動作, 要先把要 write 的資料都先存下, 再靠一個 execute all 的 transaction 逐一的把資料寫入
- Generic Attribute Profile
- 位於 Attribute Protocol 的上層 (所以是 based on Attribute Protocol), 定義了 Attributes 的 Type 以及他們該如何被使用
- 提出了幾個"概念": “characteristics,” “services, services 之間的 “include” 關聯性 , 以及characteristic “descriptors.”
- 並定義了一些 procedures 來發現 services, characteristics, descriptors 並對 characteristics 做讀寫
- Service
- "immutable" "encapsulation" of some "atomic" "behavior" of a device
- 以下一一講解這些文字的意義
- Immutable
- 不可變的, 一旦此 Service 公開, 就不可以被改變
- 有此特性後 Service 才可以被重複使用 (reuse), 因為行為不會被改變了
- 假如 Service 可以改變, 就得靠一直存在的連線來做交換訊息, 但就跟 BLE 的 connectionless 有衝突了, 所以這邊定義 Services 是不能變的
- Encapsulation
- 封裝, 把相關的 attributes 合起來就變成一個 Service, 也就是說 Service 是一個 attributes 集合
- Atomic
- 簡單來說就是小單元的
- 為何需要小單元是因為 Service 本身有 include 的功能, 我們希望 service 可以盡量被 reuse, 所以 service 的定義最好越單元性越容易被 reuse, 假如定義了一個複雜的 Service 那就很難被 reuse 或 include 了
- Behavior
- 在某種情況下, 所做的反應或動作稱作 Behavior (行為)
- 對於 Service 來說, Behavior 就是當 Attribute 被讀寫時的行為, 或是什麼事件讓 attribute 會 notify client (notification)
- Behavior 必須很明確被定義, 才不會造成和不同 Client 連線有不同行為, 喪失協同性 (interoperability)
- Service relationships
- 裝置假如有複雜的 Behavior 就可以用到這個特性, 一個複雜的 Behavior 可以有不只一個 Services
- 例如一個裝置有溫度 Service 可以量環境溫度, 有個 Battery Service 可以量電量 (他們都是 Primary Service)
- 又因為 Battery 中其實又有溫度 sensor, 所以 Battery Service 其實又可以參考到另一個溫度 service 的實體用來取得電池溫度 (電池溫度 Service 為 Secondary Service)
- Generic Access Profile
- 定義了裝置如何成為 discoverable, connectable, bondable
- 定義了裝置如何利用程序 (procedures) 來 discover, connect, read device name, bond 其他裝置
- 另外也涉及隱私 (Privacy) 的概念, 利用 Resolvable private addresses (可知來源的私人位址), Privacy 可用在一直 broadcast 資訊並被連線的裝置上, 他可以一直改變 random address 來達到 privacy 需求. 就可以避開別人透過一直聽 address 來 track 裝置, 但是對於信任的人, 這個裝置 (一直換 address 的傢伙) 又必須是可被連線的
- 所以 Generic Access Profile 定義了如何讓 private address 是 Resolvable (可知來源的), 也定義了如何去對 private address 裝置做連線
[Application]
Application Layer 在最上層, 定義了三種規範: characteristic, service, and profile
每一個規範都是基於 Generic Attribute Profile (GAP) 所定義的, GAP 會定義多個 attributes groups 來表示 services 和 characteristics, 而 Applications 定義了如何去使用這些 attribute groups
- Characteristics
- 已知格式的資料, 伴隨一個 Universally Unique Identifier (UUID)
- 可以重複使用 (reusable), 所以沒有行為的定義 (no behavior), 因為一但有了行為的定義, 就不容易重複使用了
- computer readable format, 需要透過 computer 協助顯示給 user
- Services
- 他是 human readable format 的資料
- 他包含了多個 characteristics 以及對應的行為 (behavior), 所以 characteristic 到了一個 service 內才被賦予了行為 (behavior)
- Service 只對定義 characteristics 在 Server 的行為 (GATT Server), Client 的行為則不會定義 (Client 行為定義在 Profile)
- 註: 所以我們講 Service 的時候, 就是只會提到 Server 的行為而已
- Service 可以包含 (include) 其他 services, 但是他只能定義 included services 之間如何互動, 但不能改變他們的 characteristics 或改變這些 services 的行為
- Service 不是敘述裝置如何連線並找到和使用 service, 以及如何找到 characteristics, 而是敘述當 Server 的 characteristics 被讀寫 (以及 notified / indicated) 的時候, 會發生什麼事
- Service 有兩種, Primary Service 以及 Secondary Service
- Primary: 用來體現裝置的目的, 簡單來說就是使用者利用 Primary Service 來知道這裝置是幹嘛用的
- Secondary: 用來輔助 Primary Service 或其他 Secondary Services
- 例如 Battery Service 是 Primary Service 用來取得電池相關資訊, 那會有一個 Temperature Service 為 Secondary Service 輔助 Battery Service 讓整個電池的資訊更加完整
- Profiles
- Profile 就是應用程式本身, 或是使用案例的一個體現
- Profile 會敘述 2 到多個裝置, 每個裝置會有多個 services
- Profile 會敘述裝置如何成為 discoverable 以及 connectable (間接定義了)
- Profile 會敘述 Client 如何找到 Service, 找到 Characteristics, 以及如何去使用這些 Services 以達到目標的功能
- Profiles 和 Services 是多對多對應關係的, 如下圖所示
- 不同的 Profiles 可以使用到同一種 Service 來達到裝置要的行為 (如 immediate Alert Service)
- 一個 Profile 也可以同時有用到多個 Services (如 Proximity Profile)
- 另外補充, 同種類的 Service 在不同 Profile 間是獨立的 (會各自有個實體 instance)
[Stack 劃分]
上面提到的 BLE 架構, 不一定得全都在同一個 Chip, 是可以做劃分的, 如下圖每個方塊都可以當作一個 Chip, 所以可以看到有各種組合的可能, 而 Chip 之間都有 interface 可以做 interaction, 這些不同的 solutions 可以用在不同的需要上.
- Single Chip Solution
- Application / Host / Controller 都跑在同一顆 Chip, 屬於最 Low Cost 的方案
- 常用於 low-power 裝置, 例如 BLE 燈泡, BLE 電源開關, BLE 飛機...等等通常都會使用這種 SoC 的 BLE Chip 來做, 常見的 Chip 如 TI CC2541
- 缺點就是, 他真的只適合用在小型裝置, 因為這種 Chip 都是資源非常限制的裝置 (大多會是 8-bit MCU 和很小的 Memory), 所以開發的 Application 就被這個給侷限了, 能做的事情有限
- Two Chips Solution
- 簡單來說就是分成兩顆 Chips, 有兩種分法
- Application/Host + Controller, 滿常見的用途是智慧手機, 因為手機本來就有一個 AP 負責 Applications, 所以他只需要透過 HCI (host controler interface)來控制支援 BLE 的 Controller Chip 就可以了, 強大的 AP Core 則會跑 Application + BLE Protocol Software (Host)
- Application + Host/Controller, 這個比較常見的用途是 Arduino + BLE module, 兩個 chip 之間會用客製化方式溝通 (例如 UART), 優點就是讓某平台可以藉由加入 Module 方式變成支援 BLE 功能, 且也不會因為 BLE 的加入讓 Application chip 變的受限制 (因為 host & controller 都跑在另一顆 chip 沒什麼太大的 overhead)
- Three Chips Solution
- 市面上場品幾乎都不會做這種劃分, 比較可能是在開發初期的實驗階段才會這樣做
- 一個是因為太複雜, 每顆 Chip 都需要 interface 做溝通,
- 再來就是太貴了, 三顆 Chip 的價錢以及所占的面積其實都會比較大
(Figure created by Jackal Chen)
