2016年8月3日 星期三

由台北 IoT 平台聊 LoRA & LPWAN (1) - LoRA & LoRaWAN

台北 LoRA 去年開始講, 終於在今年上線了

新聞如下:
http://www.ithome.com.tw/news/99917
http://www.ithome.com.tw/news/103206

之前一陣子到五月底還在提供 user 申請試用 (本來想申請一組, 但因為太忙了...假如有板友有申請到, 歡迎技術交流一下, 也或許可以讓我來寫篇使用的文章分享)

http://taipeismartcity.kktix.cc/events/lora3

簡單來說就是台北要建構 IoT Cloud, 只要申請就可以把一些 sensors 資料上傳到雲上, 並也可以由雲上取資料, 做不同應用, 例如我在陽明山上裝了一個星星數量感測器, 然後他會判斷目前天空上看到的星星數量, 而這資料就會定期傳到 IoT Cloud, 而其他也可以由此 IoT Cloud 取得這資訊, 例如寫 App 或網頁, 提供想觀星的人目前的資訊

那要建構 IoT 網路, 除了點對點互聯外, 最終還是要上雲端, 所以各種網路佈建跟整合是重點, 台北佈建了 WiFi 網路 (文中提到藍牙, 這我倒是不清楚目前政府有用藍牙佈什麼網路), 為了增加 coverage, 還導入了 LoRA 技術, 做長距離低功耗無線傳輸用

 LoRA 可以做到長達好幾公里的的傳輸距離, 用的是 ISM 低頻的頻段, 低頻表示高波長, 特性就是穿透性強且穩定, 距離遠, 但缺點就是速度不快, 所以台北市只要在公家大樓樓頂佈建幾台 LoRA 發射台, 就可以涵蓋整個台北市, 不過真的要整合到 sensors 或是到使用者的電腦手機, 可還是得透過 Gateway 等功能, 整個 LoRA 結合 WiFi / BT 到 IoT Cloud 如何做佈建, 我還滿好奇的, 總之就看到時開通後怎麼運作跟提供那些 API 給 users 結合就知道了

=> 補充目前看起來就是, 由正文科技提供 LoRA 模組, 使用者透過如 Raspberry Pi 或其他硬體, 結合模組後, 可發送 LoRA 帶個使用者資料存到雲上, 這邊應該會綁帳號密碼, 不是所有有 LoRA Module 就可以使用此服務  (所以才要申請試用)

回到本篇重點 LoRA, LoRA 有一個聯盟 (跟 ZigBee 一樣), 然後會有認證 (假如你用了 trademark) 以及有 SPEC 可以下載, 想深入研究的人建議可以抓下來研讀一下

https://www.lora-alliance.org/
https://www.lora-alliance.org/What-Is-LoRa/LoRa-Videos
https://www.lora-alliance.org/What-Is-LoRa/LoRa-White-Papers

也可以參考下面的 slideshare:
http://www.slideshare.net/zahidtg/lora-introduction

這篇就先做一下 LoRAWAN Introduction:
https://www.lora-alliance.org/portals/0/documents/whitepapers/LoRaWAN101.pdf

何謂 LoRA, 他是一個長距離 (long range) 的通訊協定, 一般的 low power 協定會用 FSK 來達到 low power, 而 LoRA 用 chirp spread spectrum (CSS) 來達到既可以和 FSK 一樣省電又可以達到長程的傳輸, 關於 CSS 因為牽扯到 PHY 底層通訊的技術, 這邊就不細講, 可以參考 Wiki: https://en.wikipedia.org/wiki/Chirp_spread_spectrum

LoRA 的特點就是, 只要一個基地台, 就可以 cover 整個城市, 當然他還是有 coverage 的限制, 得看環境以及距離和干擾等等, 不過比起其他 communication protocol 來說已經遠距很多, 那 LoRA 所組成的 LPWAN (亦即 LoRAWAN) 和其他的 communication protocol 例如 local area 短距離無線傳輸如 WiFi, Bluetooth, 以及長距離且高速的 mobile network (GPRS, WCDMA, LTE ...) 的差異跟互相的優缺點, 如下表所表示, 各自有其合適的應用

舉一個例子, 我要做一個小孩防丟器, 用這三個哪一種比較好?  那一個防丟器的需求如下:

重點需求: 可以偵測小孩遠離 or 知道小孩子在哪裡

  • 前者可以透過 Bluetooth / WiFi 等方式做室內定位
    • 優點: 便宜好做
    • 缺點: 一但快速遠離 (被綁上車子), 接收到警訊時, 已經來不及了
  • 後者可能得透過 GPS 等方式, 時時的上傳 GPS 資料
    • 優點: 時時上傳 GPS 可以增加搶救的時間 (直到被拆掉這個防丟器)
    • 缺點: 時時上傳就得透過如 LPWAN 和行動網路
      • 針對行動網路, 就是現在大陸防丟手錶最主要的做法, 是用 2G 來做, 缺點就是這種作法會有月租費的出現, 且耗電量跟成本高
      • 假如用 LPWAN, 也會有月租費出現, 但是因為 GPS 資料小, 所以其實比較合適用 LPWAN, 耗電量低, 且硬體成本也較低 

所以其實這樣評估起來, 以技術跟成本來說, 我會選用 LPWAN 來做防丟手環, 可以達到幾個特點:

  • 可以隨時隨地將位置資訊上傳到網路的功能 (相較於 Bluetooth 需要附近有 Gateway, WiFi 需要附近有可以連接的 AP)
  • 裝置低成本 (相較於 2G/3G/4G)
  • 裝置低耗電量 (相較於 2G/3G/4G)
  • 低月租費 (相較於 2G/3G/4G)

但殘念 (最大的缺點) 是, LPWAN 這需要有業者佈建這個服務才行 (跟 mobile network 一樣, 又有夠多的基地台覆蓋整個城市, 有訊號的 coverage), 也就是說在沒有 LPWAN coverage 的情況下, 這東西會無法使用, 則是 LPWAN 的最大的缺點, 他的普及度比 mobile network 低太多了

不過假設台北真的佈了, 那我認為還是值得做的, 至少歹徒不會這麼快就逃離台北市, 還是可以有一定的時間追蹤走失的小孩, 不過這又回到一個問題就是, 假如歹徒知道有這東西, 直接綁架構就把防丟裝置丟棄, 那就沒用了, 所以藏的好也是一個重點 (扯遠了...)














回到正題, 所以我們討論幾個 LPWAN 的重要 factors 如下, 也就是當我們在考慮一個應用程式是否使用 LPWAN 的幾個重點, 而後面會慢慢再提到 LoRAWAN 實做 LPWAN 這邊這幾個特點會是什麼


















在開始帶 LoRaWAN 的架構之前, 先提一下 LoRA, LPWAN, LoRaWAN 的差異, 以免專有名詞混淆了:

  • 亦即 LoRA 聯盟提出的透過 LoRA PHY/MAC 達到遠距傳輸的無線 protocol
  • LPWAN 就是 Low Power WAN, 泛指所有低功耗的 WAN 的實做, 不只 LoRA 方式, 還會有其他在醞釀的方式跟聯盟在做, LPWAN 簡單來說就是既可以達到 low power 又可以長距離範圍傳輸的網路架構
  • LoRaWAN 就是使用 LoRA 技術所做出來的 LPWAN

下圖為 LoRaWAN 的系統架構, 在 ISM band 上使用 LoRA Modulation 技術和其 MAC Protocol, 上面載送應用端的資料做傳輸, 細節後面會再細講

















下圖則是 LoRaWAN 的網路架構圖, 幾個重要的元件由這張圖可以看到:

  • 最左邊是 Nodes 也就是有 LoRA 功能的裝置
  • 中間則是 Gateway, 負責使用 LoRA 通訊協定和 Node 溝通, 並將資料透過 Internet 到網路伺服器中
  • 網路伺服器則是所謂的雲, 可以被 Remote Access
  • 最右邊則是應用伺服器, 也可以是應用程式, 透過和網路伺服器交換資訊達到應用需求

舉個例子, 我有一個 LoRA sensor node 裡面有放溫度 sensor, 他會佈在各地, 然後定期的將溫度資料跟時間傳送給 LoRA Gateway, 而 Gateway 再傳送給 Server 儲存, 監測人員則可以透過 App 去跟 Server 要資料, 時時監控這些感測器定期傳送的溫度資料, 這就是一個 LoRaWAN 的應用
















LoRaWAN 另外有幾個特性:
  • Node 到 Gateway 是星狀網路架構而不是 Mesh, 這可以讓 Node 本身專注於自身的資料而不用做 data forwarding, 可以讓 Node 更省電, 網路架構也相對簡易
  • Node 不用挑選 Gateway 傳輸, Node 資料會傳到 "所有可以接收到的 Gateway", 然後傳遞給 Server, 所以 Server 得做duplicate removal 的工作, 以及決定由哪個 gateway 送 ACK, 做一些安全檢查等等, 把複雜的事情放 Server, 這種 thin client, rich server 架構是常見的 IoT 架構, 為了讓這些吃電池的 Devices 可以更省電 
  • Node 可以自由移動且不需要做 handover 的動作, 原因同上, 只要 Node 在 LoRaWAN coverage 範圍內, 就有辦法讓 Server 收到資料
  • Node 在 LoRaWAN 網路內使用的是非同步傳輸 (asynchronous communication), 他是使用 random access 常見的 ALOHA method, 簡單來說就是想送的 node 就送 (但每個 node 可能會做一些 random delay 避免彼此的 collision), 但假如真的出現衝突, 就可能會出現 lost
    • 關於 ALOHA 或是 multiple access 的技術, 非常推薦這份投影片可以看看: http://www.slideshare.net/mangal007/aloha-6646824
  • 承上, 優點就是 node 很省電, 不用做任何的 time sync, data sync, 只要 trigger 點到了 node 就把資料送出去就好了, 那缺點當然就是 data collisions, 不過因為 LoRaWAN 設計是針對 IoT 是屬於 periodic & little data 的交換, 因此使用最簡單的 ALOHA 其實滿合適的
  • LoRaWAN 有很大的 network capacity, 也就是這網路可以有超多的 nodes 同時運作, 主要是透過幾個特點
    • 每個 gateway 可以有多個 channel 的 tranceiver, 因此可以同時接收不同 channel 的資料
    • 每個 channel 又因為 spreading factor 可以有多種 data rates, 彼此正交不會干擾, 所以 gateway 又有能力可以在同個 channel 中同時收不同 data rate 的資料
    • 因此透過增加 gateway, 可以直接 scale up 整個網路的 capacity, 有很強的擴充性
  • 安全性部分, 如上圖, 資料會透過 AES 加密, 達到安全性傳輸需求
最後有一點要提到的是 LoRA Node 本身有分等級, 不是每一個 Node 都是相同的, 等級如下圖, 主要是關於 downlink (DL) lantecy 的差異, 也就是裝置的 RX latency, 裝置的 TX 則是隨時想發就可以發, 沒什麼問題, 但是裝置去接收網路資料則是不同 Type 行為不同, 會有 ABC 三種 Type, 一個裝置可以支援多種 Type, 依照應用需求選用不同 type, 優點是可以更 utilize network resource, 且也可以有不同的收費方案
  • 下圖的象限, 越往上面, 愈省電 (電池的 life time 越長), 越往右邊則是 downlink (網路往裝置方向) 的時間越長
  • A Type: 
    • 每一種裝置至少都要支援 A Type, 最省電
    • RX 只有當 TX 後才可以做, 而 TX 則是由 ALOHA protocol 所 trigger 去送 (想送 + 透過 ALOHA protocol timer control 後才送出)
    • DL Latency 最高因為一定得等到網路收到裝置 TX 後才可以送 DL 給裝置
  • B Type: Bi-directional end-devices with scheduled receive slots
    • 除了向 A 之外的 random RX window 外
    • 會有一個 scheduled RX window, 所以 gateway 知道何時裝置在聽, 並可以送資料給裝置 (synchronized)
  • C Type: Bi-directional end-devices with maximal receive slots
    • 裝置可以一值聽資料 (from network), 只有在做 TX 時才會關掉 RX
    • 不會有 downlink latency















因為各國法規的因素, LoRaWAN 在各國的一些設定跟頻段是不同的 (其實 mobile network 也一樣有 band 的問題), 下面是一個整理的表格, 但就不細說, 這衍伸的缺點是是跨國相容問題, 這邊順便提一下, 因為是長距離低速傳輸, 所以使用的是低頻高波長的頻段, 跟高速傳輸用的如 2.4G, 5G 頻段不同

















最後是一個 LoRaWAN 跟其他想主打 M2M, IoT 並可以做遠距傳輸的 protocol 的整理比較表格, 這個表格其實有盲點, 例如一些 Yes/No 的欄位, 雖然都是 Yes, 但是強度可能差很多, 這就是這個表格沒表現出來的地方了
















Note: 關於 LPWAN 的介紹, 下一篇會來介紹
https://www.lora-alliance.org/portals/0/documents/whitepapers/LoRa-Alliance-Whitepaper-LPWA-Technologies.pdf


------------------------------------------------------
Copyright by Jackal Chen @ 2016
jackalchen737@gmail.com

相關系列文章:



9 則留言:

  1. 您好
    我想請問一下有關LoRaWAN的連接方式
    他是像Wifi一樣需要憑證才能連接
    還是像藍芽只要適當距離就可以自動作connection?

    回覆刪除
    回覆
    1. 看營運商如何做, 但不太可能是開放的, 一定是被 "認可" 的裝置才可以送給基地台並放到後端, 就像是你用中華電信的 SIM 無法跟遠傳基地台溝通一樣 (除非他們有簽協議), 在一開始嘗試去 camp network 就會被 reject 了

      刪除
  2. 回到主流的WiFi與RFID吧,台灣沒有本錢再浪費資源,一次錯誤的WiMax教訓已經夠了。

    回覆刪除
    回覆
    1. 這兩種情況可能不太一樣,行動電話網路都是基地台跟手機聯,只能有一種通信協定,但IoT各個節點的應用不同,各種應用的需求不同,有的要大頻寬、有的要長距離、有的要低功耗,不會有哪一種通信協定能滿足所有需求。

      刪除
  3. ...blogger 有 bug 留言有時送出會沒出現...如遇到請幫忙重送

    回覆刪除
  4. (座)長距離低功(號)無線傳輸用
    這句可以訂正一下誤植的字嗎? Thank You

    回覆刪除
  5. 每個 channel 又因為 spreading factor 可以有多種 data rates, 彼此正交不會干擾, 所以 gateway 又有能力可以在同個 channel 中同時收不同 data rate 的資料

    這句話有點怪怪的,Gateway同時收到不同的data rate的資料. 應該是說收到不同編排方式(encode)的資料才能進行decode吧? SF好像是chip內encode 的bit數.

    若有誤的話,再麻煩糾正我一下..謝謝

    回覆刪除
  6. 嗨 你好

    我想問個問題
    文章提到"Node 不用挑選 Gateway 傳輸"
    這點有點奇怪
    意思是我的end device不管跟哪一家營運商gateway都可以跟溝通嗎
    還是我的end device要配合某一家系列的gateway才有用?

    回覆刪除
    回覆
    1. 假設是以亞太做 LoRA 為案例的話, 她們架 LoRA 基地台收年費或月費的話, 要他們基地台才可以連, 技術細節就要再看更裡面 protocol 這邊怎麼去擋跟收

      刪除