跟我一起學 LoRa (II) - A 類裝置、裝置屬性與入網程序

在上一篇「跟我一起學 LoRa (I) - 相愛容易相處難」已經介紹過 LoRaWAN 的大概念，這裡很快做一下回顧。下圖是一個典型的 LoRaWAN 的網路架構示意圖，一個網路中有
(1) 網路伺服器
(2) 閘道器 (或稱基地台)
(3) 終端裝置(通常是感測裝置)

其中網路伺服器多由系統營運商 (operators) 負責建設，可進一步提供服務給 End User Application，或是由 (4) 應用服務商利用建設進一步發展某種產品，再提供給 (5) End User Application 使用。不過在台灣，大家是怎麼玩的我就不清楚了（有人知道的話，歡迎跟大家 share 一下）。

　　LoRa 終端裝置的 A, B, C 三種類型，也很快地回顧一下：

• Class A
• 可雙向通訊的終端裝置 (bi-directional end-devices)
• 通訊最不頻繁，最省電 (適合電池供電)，但即時性也最差
• Class B
• 必須至少有 A 類的功能
• 通訊較頻繁，較耗電 (能以電池供電)，即時性較好
• Class C
• 必須至少有 A 類的功能
• 通訊最頻繁，最耗電 (不適合電池供電)，但即時性最好

A 類終端裝置如何與伺服器通訊

這篇文章要聊 A 類的裝置，所以我們先來看看一個 A 類的 LoRa End Device 是怎麼樣和伺服器通訊的吧！這裡我把整個程序整理成下圖，那就照編號一個一個看吧！

1. 裝置想要開始說話了 (發起通訊)，然後它就把訊號發射出去 (uplink)。
2. 等到話 (數據) 說完了，就相當於這一次的 uplink 結束啦！圖中時間軸上的藍色橫條，表示這一次 uplink 所花的時間。視數據長度，uplink 的時間長短也不一樣。
3. 訊號發射出去後，End Device 會稍等片刻，不會很猴急地一發完就想看結果，畢竟伺服器端也需要時間處理。這裡等待的時間標記為 RECEIVE_DELAY1，預設是 1 秒 (+- 20 us)。
4. 等待一下之後，End Device 會開啟 Radio，試著收看看有沒有訊號從空間飄了回來 (downlink)。這一段開啟 Receiver 的其間稱為一個接收窗 (receive window 或 RX slot)。
5. 如果在 RX1 有收到東西 (有收到並解開 preamble，8 個 symbols  [更正: 原誤記為 5 個 symbols，謝謝 Edward 的糾正])，然後發現這個訊號就是給自己的話，Radio 就會繼續接收下去，直到數據傳完。
6. 如果在 RX1 期間沒有收到要給自己的訊號，那麼 End Device 就會像下面這張圖一樣，再試著等待一下，然後再嘗試接收一次。如果這次又沒收到，那就是沒有了，本次通訊就會被視為過期。若第 5 步就已接收成功，當然就不用開 RX2 接收窗了。

註：

• 整個通訊過程還有一些細節，例如 RX1 與 RX2 的頻率跟資料傳輸率，等待期間 server 要計算最佳的 gateway 通訊路徑等等，這個要請大家自己讀 spec 了。這裡要補充的是，在 RX1 與 RX2 還未確認成功收到數據前，End Device 不可以在這期間又發送一次 uplink。

裝置的基本屬性

一個 LoRa 終端裝置上會有幾個基本屬性，我把它整理在下面這張圖。在圖裡面我們會看到「特化 (Personalized)」與「啟用 (Activated)」這兩個東西，比較粗魯地來講是這樣：

• 「特化」是說：「這個裝置你它媽誰？」，所以裝置有自己的身分證，這張身分證是 manufacturer 跟 producer 要給的，也可以說，就是裝置製造者或設計者要寫在「韌體」裡的東西。
• 「啟用」是說：「好！我現在它媽給你一個網路位址，把你加進網路！從現在起你就是我的人了！外人亂我兄弟者，視投名狀，必殺之～.... （喂！！！）」。

關於這些基本屬性，我把它分成兩組來說明 (分成兩組的原因等等就會提到)。

第一組 [ DevEUI, AppEUI, AppKey]：

• DevEUI (64-bit)
• 全球唯一的終端裝置 ID，可視為裝置的 MAC 位址 (IEEE EUI64)，由製造商製發。Radio 本身不管這個，裝置製造商要負責這件事。每個裝置配發一個。
• AppEUI (64-bit)
• 應用識別碼 (IEEE EUI64)，這個是預先就要寫在裝置中的，是裝置製造商的責任。這個「識別碼」被用於辨識 Application，所以「很多裝置」都有同樣的 AppEUI 的話，代表他們就是同一黨的。
• AppKey (128-bit)  [更正: 原誤記為 64-bit，謝謝王子心的糾正]
• 讓服務端用於派生 NwkSKey 與 AppSKey 兩把密鑰。

第二組 [ DevAddr, NwkSKey, AppSKey]：

• DevAddr (32-bit)
• 終端裝置入網後，服務端配發給它的位址，有一點像 IP 位址的概念。它是由 NwkID 和 NwkAddr 組成。
• NwkID (MSB 7-bit)：網路 ID，用來區分不同網路營運商重疊網路的位址。(等等會看到一個叫 NetID 的東西，NwkID 相當於是 NetID 的 LSB 那 7 bits。總之這可以用來區分營運商就對了)
• NwkAddr (LSB 25-bit)：網路位址，由網路服務端派發。
• NwkSKey (128-bit)
• 終端裝置的 network session key，用於 MAC 訊息驗證/加解密
• AppSKey (128-bit)
• 終端裝置的 application session key，用於應用層訊息驗證/加解密

註：

• DevEUI 與 AppEUI 由製造商或應用商向 IEEE 購買識別碼區段。系統營運商可以向 LoRa 聯盟申請 NwkID。NwkAddr 的 25 個位元，有些公司會再抽取其中幾個位元來做布建地域劃分（例如歐洲、北美）。

終端裝置如何加入 LoRaWAN

整個加入網路的程序是 A 類裝置必須實作的功能，那因為 B 類、C 類同樣至少實作有 A 類的功能，所以就是這三類加入網路的作法都一樣。

　　要加入 LoRaWAN 有兩種方式，第一種是透過 OTA 請求來加入網路 (啟用)，稱為 OTAA (over-the-air activation)。第二種是網路都已經事先規劃好的，那麼加入網路就是很像「開機即加入」的感覺，這稱為 ABP (activation by personalization)。因為第二種 ABP 還蠻好理解的，所以就先講它。

ABP（activation by personalization）

　　因為這種情況是事先規劃好了，所以 End Device 的特化跟啟用算是一次完成，開機就有。這也是將 End Device 直接綁入一個特定的網路的方式（就不用跑 Join Request/Join Accept 的程序了）。剛剛前面我們把基本屬性分成兩組來討論對吧！在 ABP 的情況下：

• DevAddr、NwkSKey 與 AppSKey 是直接儲存在裝置上的。（等一下的 OTAA 是用 DevEUI, AppEUI, AppKey 這一組）
• 每個裝置都有自己的 NwkSKey 與 AppSKey，這樣洩漏一個裝置的密鑰，才不會牽連到其他裝置。

OTAA（over-the-air activation）

　　這屬於「裝置會向網路伺服器請求加入網路」的情況，我們下一節會看到入網程序 (Join Procedure) 的流程。這裡只要知道

• 裝置要先特化：也就是要準備好 DevEUI、AppEUI、AppKey 金鑰這三個東西，正是前面看到的第一組基本屬性。這是做韌體的時候，就要寫進去的。AppKey 的目的是為了產生 NwkSKey 與 AppSKey。
• 接著由 End Device 發起請求，進行入網程序。
• 過程中如果失去 session context，必須重新跑 Join Procedure。

總之，綜合上述，一個 End Device 除了自己原本的 DevEUI、AppEUI 之外，它在啟用 (入網) 之後，必須把 DevAddr、NwkSKey、AppSKey 記下來就對了。

接著來看看 Join Procedure 吧！

入網程序 (Join Procedure)

Join Request 的訊息由 End Device 發起，我把它畫成下面這張圖。請求訊息帶有三個參數：

• AppEUI：寫在裝置韌體中
• DevEUI：寫在裝置韌體中
• DevNonce：隨機的任意數（什麼是 Nonce）

這裡多做一點說明，就是 Join Request 的訊息不可以加密。

　　如果網路伺服器接受這個裝置加入網路，就會回復 Join Accept 訊息給它。Join Accept 訊息跟一般 downlink 訊息一樣，End Device 也是用接收窗 RX1 與 RX2 來接收它。如果 Join Request 被伺服器拒絕，那伺服器就不發回任何訊息，反正 End Device 最後沒收到訊息就知道被排擠就對了。

Join Accept 訊息帶有幾個參數：

• AppNonce：任意數或伺服器給的獨特 ID，這跟 NwkSKey 和 AppSKey 會有關
• NetID：24-bit 的網路 ID ，有點像 PAN ID 的概念，鄰近或重疊的網路一定要使用不同的 NwkIDs。24 個位元可以允許 1 千 6 百萬個不同的 LoRa 網路。NetID 的 LSB 那 7 個 bits 就是 NwkID。然後 NwkID 又跟下一項 DevAddr 的 MSB 那 7 個 bits 一樣。（真繞口阿！）
• DevAddr：終端裝置位址。由 NwkID (7 bits) 跟 NwkAddr (25 bits) 組合而成。25 個位元的寬度代表一個 LoRa 網路理論上可容納約 3 千 3 百萬個裝置。
• DLSettings：用來設置 RX1 data rate offset 和 RX2 data rate。
• RxDelay：TX 和 RX 之間的延遲。
• CFList：給終端裝置一條可加入網路的頻率通道清單。這個欄位是 optional 的。

Join Accept 差不多就是這樣子，補充一點就是 Join Accept 訊息是靠 AppKey 加密起來的。
　

小結

以上就是對 LoRa 終端裝置入網程序，還有 A 類裝置是如何完成通訊的介紹。之後我會再繼續把 B 類和 C 類裝置的特性和通訊方式介紹給大家哦！
　
　　感謝我們同仁 Eason 幫忙整理這篇文章所使用到的資料，如果沒有他的幫忙，我不知道要拖稿拖到民國幾年啦～　QQ
 　
　　最後，因為我們團隊也正在做 LoRa 的東西，有一些事情是一邊做一邊搞清楚。所以對於文章中有任何錯誤的地方，也請大家反應讓我們知道阿！謝謝大家～　以後有機會再整理一些實作經驗和大家分享囉！如果對我們團隊在 IoT 的其它開發項目有興趣(BLE, ZigBee, CoAP 與 MQTT) ，歡迎到這裡看看我們都在搞什麼鬼 XDDD