在之前的文章中向大家介紹了LoRaWAN協(xié)議中節(jié)點的兩種不同的入網(wǎng)方式OTAA和ABP的區(qū)別，本文主要介紹了OTAA節(jié)點是如何入網(wǎng)的。此文來自微信公眾號“小七說LoRa”，內(nèi)容已獲小七老師授權(quán)，小七老師是騰訊云在線課程講師，在騰訊云在線課堂搜索“LoRaWAN節(jié)點”即可找到相關(guān)課程。

OTAA的全稱是Over The Air Activation。它的入網(wǎng)步驟是這樣的：節(jié)點發(fā)出的Join Request請求通過網(wǎng)關(guān)轉(zhuǎn)發(fā)到服務(wù)器，也就是NS；NS會對該請求做一些判斷處理之后，將Join Accept響應(yīng)通過網(wǎng)關(guān)發(fā)送給節(jié)點。

網(wǎng)關(guān)的主要作用是將節(jié)點的數(shù)據(jù)與服務(wù)器的數(shù)據(jù)互相轉(zhuǎn)發(fā)。服務(wù)器我們可以選擇一些在線的服務(wù)器，比如TTN、騰訊云物聯(lián)網(wǎng)開發(fā)平臺等，我們也可以搭建開源的服務(wù)器，比如chirpstack，我們還可以購買一些已經(jīng)內(nèi)置了服務(wù)器的網(wǎng)關(guān)。

無論是TTN、騰訊云物聯(lián)網(wǎng)開發(fā)平臺、chirpstack還是內(nèi)置服務(wù)器，基本上都是免費使用的。騰訊云物聯(lián)網(wǎng)平臺于2021年1月升級為部分收費的模式，1000臺設(shè)備以內(nèi)是免費使用的。

OTAA節(jié)點入網(wǎng)需要與NS有兩次數(shù)據(jù)交互過程。一次是節(jié)點向NS發(fā)送join request請求，一次是NS向節(jié)點發(fā)送 join accept響應(yīng)。在節(jié)點發(fā)送join request請求之前，我們需要準備OTAA節(jié)點的三個參數(shù)DevEUI、AppEUI和AppKey。在節(jié)點接收到j(luò)oin accept之后，節(jié)點需要成功解析join accept之后，才是入網(wǎng)成功，接下來對每一個步驟進行詳細的說明。

對于OTAA節(jié)點，我們?nèi)绾潍@取到DevEUI、AppEUI和AppKey這三個參數(shù)呢？有的廠商會在節(jié)點上貼一個二維碼，通過掃描二維碼可以獲得這三個參數(shù)；有的廠商可以通過at指令來獲取這三個參數(shù)，具體的at指令需要查看廠商提供的手冊；還有的廠商只會將devEUI貼在節(jié)點上，然后將devEUI、appEUI和appKey通過其他方式發(fā)送給客戶，以保證三個參數(shù)的安全性。

DevEUI就是節(jié)點的身份標識，就像我們每個人在企業(yè)中的工號一樣。

AppEUI是應(yīng)用ID，我們可以把AppEUI理解為企業(yè)中的部門名稱。剛剛我們在前面提到過的幾個NS服務(wù)器中，如果使用TTN服務(wù)器，需要配置AppEUI；如果使用騰訊云物聯(lián)網(wǎng)平臺或者chirpstack的話，對于AppEUI這個參數(shù)節(jié)點可以設(shè)置為任意值。

AppKey是節(jié)點用來計算會話秘鑰的，節(jié)點使用AppKey從join accept中計算出會話秘鑰NwkSKey和AppSKey用于節(jié)點入網(wǎng)成功之后的通信，這就是一個完整的入網(wǎng)請求流程。

節(jié)點發(fā)送Join request請求，通過網(wǎng)關(guān)透傳轉(zhuǎn)發(fā)給NS服務(wù)器。NS判斷請求是否合法，合法的情況下，NS下發(fā)join accept消息到網(wǎng)關(guān)，網(wǎng)關(guān)再將消息發(fā)送給節(jié)點。節(jié)點收到j(luò)oin accept之后會從join accept中解析出devAddr、appSKey和nwkSKey，之后節(jié)點就可以使用解析后的這三個參數(shù)對數(shù)據(jù)進行加密發(fā)送給NS了。

我們通過舉例說明Join request請求的報文格式，一個join request請求中包含了節(jié)點的AppEUI參數(shù)、DevEUI參數(shù)還有一個隨機值參數(shù)，叫做DevNonce。

在LoRaWAN協(xié)議中，第一個字節(jié)稱為Mac Header標志，簡稱為MHDR，用來表示消息類型。00固定表示這是一個join request消息。第二到第九這8個字節(jié)固定填充AppEUI，第十到第十七字節(jié)固定填充DevEUI，第十八十九字節(jié)就是一個隨機值DevNonce。最后四個字節(jié)是對AppEUI、DevEUI和DevNonce這部分數(shù)據(jù)計算出的校驗值。注意DevNonce這個參數(shù)，很多做開發(fā)的朋友踩過一個坑，都與這個DevNonce有關(guān)，等會兒和大家分享。

一個完整的Join accept消息格式如下，第一個字節(jié)是我們剛剛提到的MHDR協(xié)議頭，Join accept消息的協(xié)議頭固定是十六進制的0x20。然后依次是AppNonce，它是NS生成的一個隨機數(shù)；NetID是NS的一個參數(shù)，可以簡單理解成NS的ID；DevAddr就是NS為節(jié)點生成的一個短地址，節(jié)點Join成功之后DevAddr就成了節(jié)點在NS上的唯一身份標識，同一個NS中不會出現(xiàn)兩個相同的DevAddr；DLSettings中配置了節(jié)點兩個接收窗口的接收速率參數(shù)；RxDelay中配置了節(jié)點在發(fā)送數(shù)據(jù)完成之后間隔多長時間打開第一個接收窗口，這個值默認都是1秒；CFList是一個可選參數(shù)，它可以更改節(jié)點在入網(wǎng)成功之后的通信信道信息。

NS下發(fā)給節(jié)點的join accept消息是加密消息，需要節(jié)點先使用appKey解密之后才能拿到明文的JoinAccept報文。然后節(jié)點再使用DevNonce、AppKey和從Join accept中解析出來的appNonce計算出兩個會話秘鑰nwkSKey和appSKey。

一個完整的OTAA流程的交互報文我們已經(jīng)介紹完了，在實際的使用中，大家在剛剛接觸LoRaWAN的時候很容易遇到入網(wǎng)不成功的問題。入網(wǎng)不成功有多種可能的原因，將原因主要總結(jié)為以下三點：

第一，在NS上注冊的節(jié)點三參數(shù)與節(jié)點配置的三個參數(shù)不匹配導(dǎo)致。如果devEUI或者AppEUI配置不一致的話，服務(wù)器就不會下發(fā)Join Accept消息；如果AppKey配置不一致的話，就會導(dǎo)致節(jié)點無法成功解析Join Accept消息。這個不匹配主要是人為因素，一般是因為用戶將參數(shù)填寫錯誤導(dǎo)致的，相對容易排查到。

第二，節(jié)點發(fā)送的Join Request請求網(wǎng)關(guān)沒有接收到，一般是硬件故障或者是環(huán)境導(dǎo)致無線信號特別差引起的。硬件出現(xiàn)故障的概率比較低，一般需要重點檢查是不是無線信號較差，可以考慮將節(jié)點與網(wǎng)關(guān)的距離設(shè)置的近一點、或者盡量清除節(jié)點與網(wǎng)關(guān)之間的障礙物，然后再進行嘗試。

第三，還有一個很少見的原因也極不容易排查到。很多開發(fā)者可能在剛剛學(xué)習(xí)階段會將Join Request中的各個參數(shù)在代碼中寫死，Devnonce在代碼中設(shè)置成了固定值，這種做法，將導(dǎo)致第一次Join成功之后再重新Join始終無法成功。這就是我們前面提到的Devnonce引出的一個坑。

NS會有一個緩存機制，會保存同一個節(jié)點每次Join request消息中的Devnonce，在一定時間內(nèi)，如果同一個節(jié)點入網(wǎng)請求消息中的Devnonce與NS緩存中的Devnonce雷同，那么NS會拒絕該終端的本次入網(wǎng)請求。NS這么處理是為了保證節(jié)點的數(shù)據(jù)安全性。只要更改Devnonce的值，節(jié)點就能重新成功入網(wǎng)了。

在接下來的文章中，將會繼續(xù)分享更多的物聯(lián)網(wǎng)LoRaWAN相關(guān)知識，希望大家持續(xù)關(guān)注我們。
? ? ? ? 責(zé)任編輯:tzh