Bluetooth Low Energy: The Developer's Handbook 讀書筆記 (3)

轉貼from http://thinkingiot.blogspot.tw/2015/03/bluetooth-low-energy-developers_19.html
(主要為備份參考用，此文在BLE架構分析上相當清楚細膩)

Bluetooth Low Energy: The Developer's Handbook 讀書筆記 (3)

http://www.amazon.com/Bluetooth-Low-Energy-Developers-Handbook/dp/013288836X

這本書是市面上 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)

==============

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

(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 是由各廠商自己訂的.

• 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 裝置做連線

(Figure from BLE SPEC, L2CAP 封包格式)

[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)

(Figure from https://developer.bluetooth.org/TechnologyOverview/Pages/Profiles.aspx)

[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)