發布日期：2022-05-25 點擊率：95
ass="bjh-p">在之前的文章中向大家介紹了LoRa終端OTAA與ABP入網方式工作原理區別介紹、在弱網區域下，LoRa終端的入網方式該如何選取。本文主要介紹了OTAA節點是如何入網的。此文來自小七老師，小七老師是騰訊云在線課堂物聯網講師。
OTAA,終端入網,LoRaWAN
OTAA的全稱是Over The Air Activation。它的入網步驟是這樣的：節點發出的Join Request請求通過網關轉發到服務器，也就是NS；NS會對該請求做一些判斷處理之后，將Join Accept響應通過網關發送給節點。
網關的主要作用是將節點的數據與服務器的數據互相轉發。服務器我們可以選擇一些在線的服務器，比如TTN、騰訊云物聯網開發平臺等，我們也可以搭建開源的服務器，比如chirpstack，我們還可以購買一些已經內置了服務器的網關。
無論是TTN、騰訊云物聯網開發平臺、chirpstack還是內置服務器，基本上都是免費使用的。騰訊云物聯網平臺于2021年1月升級為部分收費的模式，1000臺設備以內是免費使用的。
OTAA節點入網需要與NS有兩次數據交互過程。一次是節點向NS發送join request請求，一次是NS向節點發送 join accept響應。在節點發送join request請求之前，我們需要準備OTAA節點的三個參數DevEUI、AppEUI和AppKey。在節點接收到join accept之后，節點需要成功解析join accept之后，才是入網成功，接下來對每一個步驟進行詳細的說明。
對于OTAA節點，我們如何獲取到DevEUI、AppEUI和AppKey這三個參數呢？有的廠商會在節點上貼一個二維碼，通過掃描二維碼可以獲得這三個參數；有的廠商可以通過at指令來獲取這三個參數，具體的at指令需要查看廠商提供的手冊；還有的廠商只會將devEUI貼在節點上，然后將devEUI、appEUI和appKey通過其他方式發送給客戶，以保證三個參數的安全性。
DevEUI就是節點的身份標識，就像我們每個人在企業中的工號一樣。
AppEUI是應用ID，我們可以把AppEUI理解為企業中的部門名稱。剛剛我們在前面提到過的幾個NS服務器中，如果使用TTN服務器，需要配置AppEUI；如果使用騰訊云物聯網平臺或者chirpstack的話，對于AppEUI這個參數節點可以設置為任意值。
AppKey是節點用來計算會話秘鑰的，節點使用AppKey從join accept中計算出會話秘鑰NwkSKey和AppSKey用于節點入網成功之后的通信，這就是一個完整的入網請求流程。
節點發送Join request請求，通過網關透傳轉發給NS服務器。NS判斷請求是否合法，合法的情況下，NS下發join accept消息到網關，網關再將消息發送給節點。節點收到join accept之后會從join accept中解析出devAddr、appSKey和nwkSKey，之后節點就可以使用解析后的這三個參數對數據進行加密發送給NS了。
我們通過舉例說明Join request請求的報文格式，一個join request請求中包含了節點的AppEUI參數、DevEUI參數還有一個隨機值參數，叫做DevNonce。
在LoRaWAN協議中，第一個字節稱為Mac Header標志，簡稱為MHDR，用來表示消息類型。00固定表示這是一個join request消息。第二到第九這8個字節固定填充AppEUI，第十到第十七字節固定填充DevEUI，第十八十九字節就是一個隨機值DevNonce。最后四個字節是對AppEUI、DevEUI和DevNonce這部分數據計算出的校驗值。注意DevNonce這個參數，很多做開發的朋友踩過一個坑，都與這個DevNonce有關，等會兒和大家分享。
一個完整的Join accept消息格式如下。第一個字節是我們剛剛提到的MHDR協議頭，Join accept消息的協議頭固定是十六進制的0x20。然后依次是AppNonce，它是NS生成的一個隨機數；NetID是NS的一個參數，可以簡單理解成NS的ID；DevAddr就是NS為節點生成的一個短地址，節點Join成功之后DevAddr就成了節點在NS上的唯一身份標識，同一個NS中不會出現兩個相同的DevAddr；DLSettings中配置了節點兩個接收窗口的接收速率參數；RxDelay中配置了節點在發送數據完成之后間隔多長時間打開第一個接收窗口，這個值默認都是1秒；CFList是一個可選參數，它可以更改節點在入網成功之后的通信信道信息。
NS下發給節點的join accept消息是加密消息，需要節點先使用appKey解密之后才能拿到明文的JoinAccept報文。然后節點再使用DevNonce、AppKey和從Join accept中解析出來的appNonce計算出兩個會話秘鑰nwkSKey和appSKey。
一個完整的OTAA流程的交互報文我們已經介紹完了，在實際的使用中，大家在剛剛接觸LoRaWAN的時候很容易遇到入網不成功的問題。入網不成功有多種可能的原因，將原因主要總結為以下三點：
第一，在NS上注冊的節點三參數與節點配置的三個參數不匹配導致。如果devEUI或者AppEUI配置不一致的話，服務器就不會下發Join Accept消息；如果AppKey配置不一致的話，就會導致節點無法成功解析Join Accept消息。這個不匹配主要是人為因素，一般是因為用戶將參數填寫錯誤導致的，相對容易排查到。
第二，節點發送的Join Request請求網關沒有接收到，一般是硬件故障或者是環境導致無線信號特別差引起的。硬件出現故障的概率比較低，一般需要重點檢查是不是無線信號較差，可以考慮將節點與網關的距離設置的近一點、或者盡量清除節點與網關之間的障礙物，然后再進行嘗試。
第三，還有一個很少見的原因也極不容易排查到。很多開發者可能在剛剛學習階段會將Join Request中的各個參數在代碼中寫死，Devnonce在代碼中設置成了固定值，這種做法，將導致第一次Join成功之后再重新Join始終無法成功，這就是我們前面提到的Devnonce引出的一個坑。
NS會有一個緩存機制，會保存同一個節點每次Join request消息中的Devnonce，在一定時間內，如果同一個節點入網請求消息中的Devnonce與NS緩存中的Devnonce雷同，那么NS會拒絕該終端的本次入網請求。NS這么處理是為了保證節點的數據安全性。只要更改Devnonce的值，節點就能重新成功入網了。
在接下來的文章中，將會繼續分享更多的LoRa相關知識，希望大家持續關注我們。
下一篇： PLC、DCS、FCS三大控
上一篇： AIoT在工業場景中的應
