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 依序從不同天線接收,  因此, 每根天...

在 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 網路中, 小資訊的資訊 (如: 溫度, 狀態等) 回報.

對於室內定位的應用而言, Bluetooth 由於其低功耗, 普及, 以及覆蓋範圍小等特性, 一直以來, 都是室內定位的熱門選擇, 在過去, Apple 就曾經以信號強度 (RSSI) 為依據, 推出室內定位用的 iBeacon 作為定位的解決方案, 其定位精度約為 1-5 公尺. 在新的 Bluetooth 協定中, 加入了 AoA/AoD 的支援, AoA (Angle of Arrive) 只需要接收端有多天線系統 (傳送端可為單天線), 可以分辨來自不同天線訊號的時間/相位差, 就可以計算出傳送端相對接收端的角度資訊, 類似的, AoD (Angle of Departure) 則要求傳送端有多天線系統, 就可以藉由 ACK 等資訊, 計算出接收端相對於傳送端的角度資訊, 來自:  http://dev.ti.com/tirex/content/simplelink_academy_cc2640r2sdk_2_30_02_00/ modules/blestack/ble_aoa/ble_aoa.html 在 Bluetooth 5.1 中, 距離資訊仍是來自於 RSSI 訊號強度, 而不是用 ToA (Time of Arrival) 來取得距離資訊, 這應該是因為希望和過往的 Bluetooth 裝置相容, (ToA 需要裝置間同步與硬體的支援, 無法相容於之前的裝置) 因此, 只希望修改 Bluetooth Gateway 的硬體與演算法, 來提供定位的結果. 在目前的架構下, AoA 資訊的取得, 的確能夠改善定位誤差, 特別是在直視路徑 (LoS, Light of Sight) 的環境中, 然而, 針對 Bluetooth 定位所遇到的其他問題, 例如: 過多的布建數量, 仍無法提出解答, 同時, 考慮 AoA/AoD 對於天線排列的要求, 如何提供一種均一, 容易開發, 且準確的 AoA/AoD 資訊, 將會是此標準能否廣泛應用的關鍵.

在所有 IoT 應用中, 除了穿戴裝置和感測器外, 另一個常被討論的應用就是車載網路, 不同於上述兩種應用, 面臨藍牙, LoRa, OneM2M的競爭, 車載網路由於其反映延遲和安全性的需求, 主要仍在 3GPP 的架構下討論, 稱為 V2X (Vehicle-to-everything). Note: 還有 802.11P 的 DSRC, 不過, 不在此文討論... 事實上, 在目前的架構中, V2X又 可以大概分成4個部分: V2V (車對車), V2I (車對號誌), V2N (車對網路), 以及V2P (車對行人) 如下圖所示: 來自:  https://www.hksilicon.com/articles/1453396 目前主要推動國家為中國大陸和美國, 圖片連結 有詳細的沿革紀錄, 可以了解雙方推動 V2X 網路重點的不同.

一般來說, 我們會從兩個角度描述一個通訊網路的關係, 首先, 我們會有一張系統架構圖, 用來描述各裝置的位置, 以及相互之間的關係, 如果更詳細一點, 應該要畫出裝置中各元件在SPEC中的定位, 以及裝置間個連線, 在SPEC中所使用的接口, 接下來, 我們需要有另一張資料流程圖 (data flow), 來表示控制訊息和資料訊息在裝置間(或是元件間)的時間關係. 然而, 不幸的是, oneM2M的TR0001雖然提供了大量的使用案例, 但是每一個案例的細節卻參差不一, 若以較為嚴格的標準來看, oneM2M提供的案例, 都無法直接的套入框架, 不過, 我們仍找一個較為完整的案例作為範例, 說明如何了解oneM2M的資料流程, 我們以9.1的Home Energy Management為例(pp. 73, TR0001 V2.4.1), 一開始, 違建會先用文字介紹環境以及目標 (9.1.1 Description), 接下來, 介紹會出現的裝置和標準 (9.1.3 Actors), 這一部分可以看做系統架構圖的文字版, 幸運的是, 該使用案例有畫出系統架構圖 (figure 9.2), 來自:  http://www.onem2m.org/images/files/deliverables/Release2/TR-0001-Use_Cases_Collection-V2.4.1.pdf

通常, 我們寫通訊架構的文章資料來源有二: 上網搜尋閱讀別人摘要, 或是閱讀SPEC, 閱讀別人的資訊再整理, 的確能夠快速地了解架構, 然而, 畢竟是二手資訊, 如果仍有疑問, 還是要回到官方的文件, 也就是SPEC上 OneM2M的SPEC和3GPP的形式一致, 分成TS (Technical Specification) 和TR (Technical Report), 網址如下: http://www.onem2m.org/technical/published-documents TS是正式的SPEC, 會規範通訊中的細節, 以TS 0001為例, 標題為: Functional Architecture, 裡面就涵蓋了之前文章的多數內容, 比如說, 在第6章, "oneM2M Architecture Aspects", 就介紹了四種節點 (Node) 的定義與相互的角色, 包括: Application Service Node, Application Dedicated Node, Middle Node, Infrastructure Node, 然而, 由於這是SPEC文件, 所以不會有詳細的說明和舉例, 通常只有一到兩句的定義 TR則是在定義SPEC之前討論所產生的技術文件, 以TR 0001為例, 標題為: Use Cases Collection, 就集結了各家提出來OneM2M的使用環境設定, 通常, 我們會從這份文件讀起, 嘗試了解SPEC定義者心目中應用架構, 再一步步推廣到其他細節. 不過, OneM2M和3GPP的SPEC仍有很大的差距, 根據我之前讀TR的經驗, 3GPP文件不論是圖, 表, 文字, 內容, 都十分一致, 但在OneM2M的文件中, 卻有一種像是剪貼簿的感覺, 只是把各家報告複製貼上, 而缺乏整合...

讓我們在這裡總結一下前幾篇文章對oneM2M的介紹, 並嘗試系統化oneM2M的架構. 在oneM2M的架構中, 分成3種基本單元: AE: Application Entity CSE: Common Service Entity NSE: Network Service Entity 以上3個單元, 分別對應於Application Layer, Service Layer和Network Layer, 其中, 在之前文章中, NSE沒有詳細的介紹, 根據定義, NSE provides connectivity services to the CSEs besides the pure data transport. 換句話說, NSE提供CSE基本的資料傳輸功能, 用以建立網路, 若以在網路中的角色來分配, oneM2M有4種不同的節點: Application Dedicated Node Application Service Node  Middle Node  Infrastructure Node. 這四個節點以Middle Node為界, 分屬於兩個網路: M2M網路, 網際網路, 或是以oneM2M的術語來說, 就是field domain 和 infrastructure domain, Middle Node像是gateway一樣, 扮演兩個網路之間資料轉傳的角色, Application Dedicated Node和Application Service Node的差別在於CSE的有無, 換句話說, 若是傳統無oneM2M的裝置, 即是Application Dedicated Node, 若有CSE層, 則是Application Service Node, Application Dedicated Node和Application Service Node同屬於M2M網路中的節點, 關係如下圖: 來自:  https://www.slideshare.net/Hamdamboy/one-m2m-66797390

交大資工林甫俊老師有一篇文章介紹OneM2M, 很值得一看: http://scitechreports.blogspot.tw/2014/04/blog-post_14.html 在該篇文章中, 借用了我們較為熟悉的網路流程, 也就是: 感測器->資料庫->應用, 的架構, 並定義了兩種網路: M2M設備網路, 以及M2M核心網路, 其中介於兩種網路之間, 就是閘道 (gateway), 因此, 架構圖就會表示如下圖: 來自於:  http://scitechreports.blogspot.tw/2014/04/blog-post_14.html 對照 上一篇文章 中的圖示, 我們可以找到其對應關係: Application Service Node (應用服務Node): M2M設備區 Middle Node (中間Node): M2M閘道 Infrastructure Node (基礎設施Node): M2M網路區

在 上一篇文章 中, 介紹了OneM2M的目標以及所處位置, 在這一篇文章中, 將繼續介紹在OneM2M中, 裝置所虛擬化的基本單元. 不同於一般行動網路的通訊協定, 定義了核心網路以及接取網路的架構, OneM2M不提供網路服務, 所以沒有核心網路的設計, 而把自己視為一個轉介層, IoT終端透過此轉介層, 回傳所收集的資料, IoT的應用服務, 也透過此轉介層, 訂閱所需要的資料, 因此, 在OneM2M的架構下, 可以區分出兩個主要的基礎單元: AE (Application Entity): 可以是裝置, 也可以是應用服務 CSE (Common Services Entity): 提供OneM2M溝通介面的裝置 其中關係如下圖所示: 來自:  https://www.slideshare.net/onem2m/onem2m-release-1-primer/54

OneM2M:  http://www.onem2m.org/ 在之前的一系列文章中, 介紹了許多IoT的協定, 其中, 考慮到IoT裝置的省電需求與運算能力限制, 通常不會賦予完整的應用, 而是以資料蒐集, 處理, 以及傳輸為主, 對於IoT應用的架構者而言, 通常是藉由資料庫的查詢, 取得收集的資料, 並透過控制指令, 間接的操作IoT終端裝置, 對於像是SigFox這種封閉式平台當然沒問題, 只要設定好回傳的資料, 週期, 等參數設定, 就能夠自動地把資料回傳到SigFox的資料庫, 而使用者可以直接對資料庫進行操作, 抓取資料做進一步分析. 然而, 對於Bluetooth, Zigbee之類的通訊協定要怎麼處理呢? 這些通訊協定, 通常只定義了MAC和PHY的通訊協定, 而不包含TCP/IP層的協定, 無法提供後端聯網功能, 因此, 在過去, 都是由開發者自行處理資料的轉傳, 儲存與處理, 好處是開發者可以掌控所有細節, 但也堆高了開發成本, 無法像SigFox一樣包裝成應用服務使開發者容易上手.

對於通訊應用來說, 我們通常可以從兩個角度來看: 也就是行動網路 (mobile comm.) 和無線區域網路 (wireless area network), 或者, 更久遠一點的: 電話網路 (telecom) 和資料網路 (datacom). 雖然最近幾年, 兩者的差距越來越小, 但是, 畢竟來自於不同的出發點, 對於系統架構也有不同想法, 來自:  https://www.leverege.com/blogpost/lpwan-benefits-vs-iot-connectivity-options 在這張圖中, 我們通常把左方 (802.11系列) 和下方 (802.15, Bluetooth) 歸類於WAN, 2G, 3G, 4G, 5G 則是行動網路, 我們可以看到, LPWAN正好鄰近於802.15和2G, 也因此, NB-IoT的通訊方式, 更近於2G (Sigfox, LoRa, 更經典的是EC-GSM-IoT), 對於Bluetooth, WiFi而言, 發展IoT網路的阻礙反而來自覆蓋範圍.

在之前的文章中, 我們介紹了兩個陣營的IoT通訊方式, 對於比較不同的通訊協定, 或是通訊系統而言, 事實上, 調變方式, 功率, 等底層通訊框架反而不是最重要的, 畢竟, 通訊技術的決定, 一向是投票決定的結果, 不同的通訊技術, 常常可以到達相同的成效, 然而, 比較上述幾個cellur-based IoT通訊協定, 包括: LTE-M, NB-IoT, Sigfox, LoRa這四種通訊協定. 在商業應用的選擇上, 仍然有幾個需要注意的地方, 來自:  http://3smarket-info.blogspot.tw/2016/06/lora-nb-iot.html 首先, 我們先說他們的共同特色: 低功率, 便宜的晶片, 少量的資料傳輸 盡量適用低頻的通道, 窄頻譜 (LTE-M除外) 大基地台, 廣大的覆蓋範圍 這些共同的特色也造成了cellur-based物聯網適用的應用例, 也就是在大範圍為的地區, 進行資料的收集, 用以對抗有線網路和電源缺少的使用情境.

在 上一篇文章 中, 我們雖然介紹了NB-IoT為蜂巢網路下的IoT架構, 但是, 事實上, 蜂巢網路架構下的IoT仍有其它的競爭者, 包括LoRa, 以及Sigfox. 包括LoRa和Sigfox的共通特性就是兩者都使用1GHz以下的頻帶, 在通訊領域中, 越低的頻譜, 其指向性差, 可傳輸性遠, 可以用較低的功率覆蓋極大的範圍, 但是, 其能夠傳送的傳送速率較低, 因此, 適合用作IoT的應用, 以調變技術而言, LoRaWAN使用chirp spread spectrum, 為一種展頻通訊的方法, 而Sigfox則使用窄頻BPSK的方式調變, 相較LTE-based以OFDMA作為調變的方法, 可以省下運算所需要的功率, 但也更難和手機裝置整合, 傳輸的速率也因此受到限制, 我們先看一張比較圖, 比較LoRa, Sigfox和LTE-based的IoT差異 雖然原文中未寫明, 但是Narrow-Band應該就是 Sigfox 來自:  http://thinkingiot.blogspot.tw/2016/08/iot-lora-lpwan-1-lora-lorawan.html 這張表, 很明顯應該是LoRa方製作的, 因此, LoRa在除了傳送率之外的所有項目都勝出, 但是, 以一個非同步的通訊標準 (LoRa和Sigfox都是) 而言, 沒有限制的上傳的限制, 意味著, 封包無限制的碰撞, 可以想像在室內有10個WiFi AP時, 並不會有10倍的傳輸量, 反而導致所有AP都因為封包碰撞, 而無法正確送達, Sigfox把上傳限制設為一日140個訊息, 一個訊息12 bits似乎是較合理的作法, 另一方面, Coexistance, 也就是和其他基地台, 或是通訊系統的共存, LoRa因為有random backoff和展頻的機制, 因此可以做到較好的共存, 但是, Sigfox部分, 我並沒有看到如random backoff的機制, 可能會被其他基地台甚至是LoRa的用戶干擾. 最後, 雖然上表並未提及, 但是Sigfox目前並沒有提供下行的資料傳輸, 而LoRa則把裝置分成三個等級, 分別設計其下行傳輸方式, 沒有下行, 對於通訊系統而言, 是一件好玩的事情, 一方面, ...

就和所有的科技進展一樣, 首先, 有一個漂亮的標題或是願景, 像是: 萬物聯網, 然後, 是各式各樣的通訊技術的競爭與合作, 直到最後, 我們才找到一組可行的通訊協定, 推廣, 普及, 從發想到實踐, 大概是10年, IoT不是新概念, 從電腦開始, 到智慧家電, 以及最後的萬物聯網, 都是IoT的應用 http://monipag.com/antoine-michel/iot-conclusion/ 物聯網 (Internet-of-Things, IoT) 也是相同的概念, 事實上, 此概念並不新, 在WiFi網路中, ad-hoc網路就曾經是熱門話題, 低功率應用, 從當年Zigbee, Bluetooth兩家爭搶, 到現在LoRa (Long Range), Bluetooth, WiFi互相爭奪市場與應用, 但是, 市場依然沒有像當年預想的普及, 實際的應用範例反而偏向工業上的物流管理等專業的場域, 而現在3gpp加入戰場, 讓IoT的議題更受矚目, 也希望憑著3gpp聯盟廠商間更緊密的關係, 能夠藉由一致的標準, 快速提供低價且普及的IoT接取, 然而, 問題在於: 行動網路 (cellular network) 的架構並不適合物聯網 (IoT).