LoRaWAN與NBIoT不同之一是入網(wǎng)方式。首先它適用于私有網(wǎng)絡(luò)和公有網(wǎng)絡(luò)（如果法規(guī)允許）。其次，不同規(guī)模網(wǎng)絡(luò)的終端數(shù)量和入網(wǎng)方式可能是不一樣的。LoRaWAN支持ABP和OTAA方式。
ABP，Activation By Personalization
所謂Personalization就是生產(chǎn)環(huán)節(jié)預(yù)配置錄入的方式。在設(shè)備個性化時，把三個參數(shù)直接分別燒錄到設(shè)備NVMEM和云端數(shù)據(jù)庫中。流程簡單，容易理解。但是相對安全性較低，適合私有網(wǎng)絡(luò)。這三個參數(shù)是：
- DevAddr: 設(shè)備地址 (32bit)
- NwkSKey: 網(wǎng)絡(luò)會話秘鑰 (128bit)
- AppSKey: 應(yīng)用會話秘鑰 (128bit)
一般來說，由MCU的UID串號通過算法得到64bit DevEUI，繼而由云端生成DevAddr/NwkSKey/AppSKey，并且錄入到對應(yīng)設(shè)備中。這樣可以實現(xiàn)每臺設(shè)備與三個參數(shù)一一對應(yīng)。
ABP在生產(chǎn)環(huán)節(jié)多了一個工位，但是注冊流程簡單。
OTAA，Over the Air Activation
空口激活，即空白設(shè)備通過LoRaWAN的空中通道實現(xiàn)設(shè)備激活入網(wǎng)。
空白設(shè)備入網(wǎng)需要三個原始參數(shù)：
- AppEUI: 在某些代碼中被寫成ArtEUI
- DevEUI:
- DevKey:
推導(dǎo)算法
上圖來自Rime博客
首先，生產(chǎn)環(huán)節(jié)依然要燒錄AppEUI/DevEUI，其中AppEUI是要燒錄的，而DevEUI來自UID。
其次，上傳Join Request報文中，包括AppEUI/DevEUI和DevNonce，所謂DevNonce就是隨機數(shù)，可以來自網(wǎng)絡(luò)RSSI或者時間戳。
第三，在服務(wù)器中生成AppNonce/NetID/DevAddr，其中AppNonce是隨機產(chǎn)生的，而NetID則與網(wǎng)絡(luò)有關(guān)，DevAddr是從一個地址池中獲取。
第四，產(chǎn)生主密鑰AppKey，與DevAddr一起通過Join Accept報文下發(fā)給終端。
最后，設(shè)備將DevAddr，并且通過主密鑰推導(dǎo)出NwkSKey/AppSKey兩個秘鑰，保存在NVMEM中。
之后的通訊，設(shè)備都是通過DevAddr/NwkSKey/AppSKey進行通訊的。
這里面沒有基站網(wǎng)關(guān)出現(xiàn)，是因為在網(wǎng)絡(luò)中，網(wǎng)關(guān)不涉及到LoRaWAN的MAC層，所有報文交換發(fā)生在MAC層中。在實際網(wǎng)絡(luò)中，由于設(shè)備漫游等需求，此類密集的入網(wǎng)請求，需要在多個Join Server間進行處理。
其他
入網(wǎng)還需要避免集中入網(wǎng)導(dǎo)致的網(wǎng)絡(luò)堵塞，以及感知信道等。
但是上圖中，AppKey是加密后傳輸給終端的，但是AES128的Key/IV是如何產(chǎn)生的沒有說明，難道是從AppEUI/DevEUI中產(chǎn)生的？位數(shù)倒是正好128bit。
隱憂
由于LoRaWAN起源于私有網(wǎng)絡(luò)，未來發(fā)生公有和私有網(wǎng)絡(luò)彼此覆蓋的問題。加上LoRaWAN覆蓋范圍較大，同頻干擾、同類架構(gòu)彼此覆蓋的情況可能會出現(xiàn)。好在不同頻段還是可以通過頻段和調(diào)制度避免這些問題。但是基于微基站的漫游交換，復(fù)雜度不低。
所以，暫時還就是停留在私有網(wǎng)絡(luò)比較合乎現(xiàn)實。
