跟我一起學 LoRa (I) - 相愛容易相處難

之前在 facebook 上，對 LoRa 發了一點牢騷，恐怕有些人以為我討厭 LoRa，但其實並沒有。我只是對於「拱 LoRa」這件事情有點小意見而已啦！我對 LoRa 也是小有興趣的啦！之後隨著我自身的學習，也希望能盡量抽出時間整理一下我的學習成果，跟大家一起分享。 (靠~~ 我想寫的東西真他媽多....)

接下來，我們就開始來認識一下 LoRa 吧！文章的圖與內容有很多都是從官方文件讀(借)來的，所以若有興趣，不妨可以到 LoRa 官網給他逛一逛哦！

　

什麼是 LoRaWAN?

LoRaWAN 是眾多 低功率廣域網路 (LPWAN, Low Power Wide Area Network) 規範的其中一種，它的訴求是能夠讓 以電池供電的裝置 可以部署在較廣域的網路中 (原文是 regional, national or global)。因此，注重的點是「遠距離、低耗電」。

　

　　整個 LoRa 網路的形成就如同下面這張圖，遠距節點可以透過多台 LoRa 閘道器 (gateways) 與後端網路伺服器連接，將資料後送至雲端或應用伺服器上。

　　在 LoRa 網路中，終端節點的訊息，是可以同時傳遞給多個閘道器的，節點也不一定是掛在某一台閘道器底下；訊息也可透過閘道器之間的橋接，進一步延伸傳輸距離。
　　

　　既然同一個訊息可以由多個閘道器接收，那麼到底要以哪一台 gateway 為準呢？相關的計算 (冗餘封包濾除、安全性驗證、最佳 ACK 路徑或動態資料率調整等)，通通都移到了 Network Server 身上，所以可想而知 Network Server 一定是比較強大的機器，而終端裝置與閘道器的計算能力相對來說就不需要很強 (當然，對於多頻段、多通道以及身兼 Network Management 的高容量閘道器不再此列，這類型的閘道器確實要很強大，一台動輒要台幣 8, 9 萬以上)。
　

LoRaWAN 網路架構的特點

• 採用星狀拓樸
• 終端點的通訊是雙向的 (bi-directional)
• LoRaWAN 資料率可以從 0.3 kbps 到 50 kbps
• 使用了展頻技術 (相同的頻率通道中，可再以不同的 spreading factor 來切割通道做 multiple access，但會影響資料傳輸率)
• 中央閘道器 (gateway) 負責橋接 (bridging) 裝置間的訊息，同時也作為與後端服務連結的網路伺服器 (透過 IP 網路)
• 資料傳輸率的高低與通訊距離之間具有取捨關係
• 適應性資料率  (adaptive data rate, ADR)
• LoRaWAN 的網路伺服器可為個別裝置設定資料率，以最佳化電池效率及網路容量

　

三種終端裝置的 Class

　　LoRaWAN 將終端裝置 (end-point devices) 區分為A, B, C 三類 (classes)，各自能適用遠距通訊的不同需求 (有些要求很省電、有些需要很即時)。這裡先說明一下 uplink 與 downlink 的意思：

• uplink transmission (上行傳輸)：終端裝置傳給伺服器
• downlink transmission (下行傳輸)：伺服器傳給終端裝置

好，那麼我們來看 A, B, C 這三個 Class 分別擁有什麼特性：

• Class A
• 可雙向通訊的終端裝置 (bi-directional end-devices)
• 每個裝置的 uplink transmission 之後接有兩個短暫的 downlink receive windows
• 用於需要以最低功耗操作的終端裝置。這種裝置常常在它送出 uplink 之後，只需要與 server 端進行很短暫的 downlink 通訊 (例如只收個 ACK 而已)
• 在任何其他時間，從 server downlink 必須等到下一次的 scheduled uplink (所以通訊沒辦法很即時，例如下一次的 scheduled uplink 可能是在 128 秒之後)
• Class B
• 必須至少有 A 類的功能
• 可雙向通訊的終端裝置，但有 scheduled receive slots (有固定接收時槽接收 server 過來的訊息，相較於 A 類會更即時一點)
• 相較於 A 類的隨機 receive windows，Class B 的裝置會在排程的時間打開一個額外的接收窗。為了讓終端裝置在排程時間打開它的 receive window，它需要從 gateway 接收一個用於時間同步的 Beacon (如此一來，server 就能知道終端裝置何時在 listening)
• Class C
• 必須至少有 A 類的功能
• 可雙向通訊的終端裝置，盡可能安排最多的 receive slots
• C 類的終端裝置是幾乎連續地開著 receive windows，只有在發送時才會關閉接收視窗
• C 類對 server 與終端裝置通訊帶來最低的延遲 (latency)，所以即時性最好，但消耗功率最高

　

資料傳輸率與通訊距離

　　官方文件中給了一張圖，說明了 LoRa 的資料傳輸率 (data rate)、通訊距離與其他協定的對照圖。在這張圖比較下方，你可以看到 LoRa 所處的位置，它的資料傳輸率約莫在 100 bps ~ 20 kbps 之間，而通訊距離落在 5 公里的範圍內(實際上也有高達 10 餘公里者)。LoRa 的傳輸率可以自由調整，傳輸率越低，傳輸的距離可以越遠。

　　仔細看這張圖，你可以發現在通訊距離 100m 以內，LoRa 的對手太多了，例如成熟的 BLE、ZigBee 與 802.11，LoRa 恐怕都不是對手(有部分原因是成熟產品的普及度)。反過來說，LoRa 的優勢在傳輸距離超過 500m 以上，有它絕對的優勢 (但這也不好說，採用 MESH 網路架構的 ZigBee ，可以跳躍多點來延伸網路的佈建範圍)。其實這幾種協定要比較傳輸距離也不一定公平，畢竟各自使用的頻段並不一樣，這我就不談了，因為探究其實也沒用。

　　

　　這裡我要補充一點我的見解，LoRa 的省電優勢是建立在「遠距傳輸」這個前提之下，如果在傳輸距離 100m 以內，LoRa 比起圖中的 BLE 與 ZigBee，恐怕很難說它會比較省電。不過對於耗電，還是有幾件事情可以稍微看一下：

• 省電的機制大多都是看應用而有不同的睡眠實作方式，所以到底誰比較耗電確實不容易比較 (我想沒有人閒閒在同一種應用場景，用三種不同的協定來實作並比較耗電。如果有，我也超想知道結果為何阿~~)。
• 以遠距通訊來論，BLE 與 ZigBee 必須花更大的力氣來延伸傳播距離。
• 載波頻率的問題 (頻率低者通常比較容易傳的遠)
• 穿透力與繞射能力的問題 (訊號遮蔽性、反射、衰減以及實施環境下建築物幾何結構的影響)
• 規範限制的問題 (雖然是在 ISM band，但規範為了避免自己阻塞到自己人，發射功率都有限制。超過此限，所有規格就不保證啦!!)
• 以 RF 前端架構而言，LoRa、BLE 與 ZigBee 通通採用固定波包調制以及展頻技術
• LoRa
• 通道頻寬：最大 0.5 MHz (見下表)
• 調制與展頻：GFSK + CSS (Chirp Spread Spectrum, 雖然 semtech 說 CSS 是戰時的國防技術, 不過 semtech 似乎有再加上自己的獨門調制技術, 這是有專利保護的!)
• BLE
• 通道頻寬：2 MHz
• 調制與展頻：GFSK + FHSS (Frequency Hopping Spread Spectrum)
• ZigBee
• 通道頻寬 2 MHz
• 調制與展頻：OQPSK (half-sine pulse shaping) + DSSS (Direct Sequence Spread Spectrum)
• 在功率放大器的發射效率上，LoRa 也沒有比較佔優勢 (若要更嚴謹地說，在電路實作上其實還是有優勢，主要還是頻段的差別)；但在接收上，靈敏度確實是贏，當然展頻的 processing gain 是有貢獻，但主要還是因為頻寬較窄 (相對地，transceiver 的線性度也比較好做，這性能參數一來一往會差很多)

• 若移到協定上的問題來講，LoRa 的非同步通訊方式，也確實能為功率消耗帶來一些幫助。因為它不用三不五時就跟閘道器報備 (同步) 一下，它可以在它有需要時發起通訊，在通訊結束後就沉沉睡去。但是我對這一點是持保留態度就是了。
• 這個非同步指的是行為上，有一點像中斷的感覺，隨時都可以發起通訊
• 但是通訊只要一發起，反而有一點像被"阻塞"住了，通訊不是隨時隨地就可以收發的，這之後我寫 MAC 層的時候會看到　

　　好～這部分就到此暫停！因為比較它們實在沒意思！但我真的是忍不住就想比看看 XDDD，我猜應該也是有人會忍不住想知道.... 　但是寫再多，真的都沒意義啦！各個協定都有它們強的地方啦！況且 LoRa 其實跟 BLE 與 ZigBee 完全不是同一層次的協定啊！(要比也是跟 IEEE 802.15.4 比)　

小結

　　我們的 LoRa 初探，先寫到這裡，相信您看完之後，應該對 LoRa 網路也會稍稍有點概念了。之後等我把 MAC 層的東西整理完後，再來看一下 LoRa 的 MAC 大概有些什麼。接著，我們會再看一下 Semtech SX127x 的晶片架構。

　　

　　如果你問我，現在到底適不適合選擇 LoRa 來做產品？其實我沒辦法給你很明確的答案，因為那要看你到底想做什麼。還有一點比較奇怪的是，LoRa 雖然是使用 ISM Bands，但是這些頻帶(433/868/915 MHz)，台灣目前並沒有開放啊!! (嚇~~~ 還是我資訊有誤? 知道的人麻煩請跟我說一下)  不過，相信會有開放的一天啦！但到底開放哪個頻段，我就不知道啦！想做產品的話，就跟他賭吧！ (這不是只牽涉到產品設計與部署的問題，還有被 NCC 打槍的問題... XDDD，不過產品若是要賣國外的話，大概是沒問題啦!!) 

　

　　LoRa 協定大概就是負責到 transportation layer 的事情 (有一點像 IEEE 802.15.4，是 ZigBee 與 6LoWPAN 的底層協定)。它沒有高層 profile 或 data model 的概念，也就是沒有像 BLE 的 Characteristics、沒有像 ZigBee 的 Clusters。這意味著，假如你今天採用了 LoRa，即便只是傳輸很簡單的資料 (例如溫度值)，你百分之一千萬一定會遇到相容性的問題，A 公司的作法跟 B 公司的作法可能不同。除非，你開發的產品真的是很明確就是用在某個應用之上，弄來弄去都是自己關起門來搞，也沒有要跟其他人相容的意思，那麼選擇 LoRa 當然沒有問題。那如果你想要自己家的產品，能夠跟未來的物聯網體系有較好的黏合度，我是覺得最好再觀望一下，等之後上層的定義有機會明朗化再下手吧！如果想做的東西，沒有真的需要"遠距"傳輸，我還是建議用 BLE, ZigBee 或走 IP-based (看你是要用 MQTT 還是 CoAP) 的方式就好啦，一旦出事也比較好隨時換方案！

(你也許會想說自己先做，反正等之後有一些上層規範出來，再跟上去就好啦！其實這樣也可以啦！只不過你要有 firmware 全部挖掉重來的心理準備就是了。那個不是只有資料模型那麼簡單，還有 Client/Server Interfaces 的問題。) 

　

　　那如果你想問我，LoRa 適不適合 Maker 呀？我是覺得對 Maker 就沒差啦！想玩就玩呀～哈哈哈.... 但是我必須要先說，Maker 用了 LoRa，應該是傳輸距離比較遠會有一點爽度。不過要有心理準備，需要消耗一點腦細胞在一些「跟應用無關」的事情上。我是覺得還是不要自找麻煩的好，用 IP-based 好啦，立馬從美國讀取一個溫度值回來，超遠！ (喂～不是那種遠距的意思啦...)。

　

給個結論，目前的 LoRa，我覺得用一句話形容就是：「相愛容易，相處難」。

　
　
　

2016/10/13：謝謝 BeJo Li 提醒，台灣已可用 900 MHz 頻段囉~