1.0
LoRaWAN_APB入網參數設置
2.0 OTAA入網
OTAA(Over-The-Air Activation)，是LoRaWAN的一種空中入網方式。當node在上電的時候處於非入網狀態時，需要先入網才能和服務器進行通信。其操作就是node發送join_request message，請求入網，然後服務器同意入網，並且返回Join-accept message，node再對信息進行解析，獲取通信參數，之後就可以和服務器通信了。
APPEUI node自定義的8字節長地址
APPKEY 服務器和node端都事先存好，用於對Join_acept message 做加解密處理
DevNonce 2字節的隨機數，用於生成隨機的AppSKey和NwkSKey
這些參數可以通過程序固話在裏面，或者通過串口或其他方式在入網操作前告訴node。
第一步
1.node發起入網請求，也就是發送join_request message，
根據LoRaWAN specification 可知，join_request message的格式如下:
| | |
| | |
| MHDR | APPEUI | DevEUI | DevNonce | MIC |
|---|---|---|---|---|
| 1字節 | 8字節 | 8字節 | 2字節 | 4字節 |
其中
字段 描述
MHDR 數據包頭，其中包含了數據包的類型，也就是說從這個包頭可以知道，這是一個join_request message
APPEUI 應用EUI
DevEUI node的長地址，由node自己定義
DevNonce 一個隨機數，用來生成密碼
MIC 4字節的校驗
需要注意的是Join_request message是未加密的
第二步
2.GW將此數據上傳至NS
GW對MAC層的數據不進行解析，而是直接將其進行base64編碼之後，封裝成JSON包上傳至NS,MAC層的數據位於rxpk.data
樣例數據：
{
“rxpk”: [
{
“tmst”: 532505620,
“chan”: 6,
“rfch”: 0,
“freq”: 471.9,
“stat”: 1,
“modu”: “LORA”,
“datr”: “SF12BW125”,
“codr”: “4/5”,
“lsnr”: -17,
“rssi”: -81,
“size”: 23,
“data”: “AAEAACAAxSYsFhAWIAB3SgBUe0At4Zo=”
}
]
}
此處，將data進行base64解碼，我們就可以看到MAC層數據了，因爲join_request message數據是未加密的
data部分的內容如下：
\x00 \x01 \x00 \x00 \x20 \x00 \xc5 \x26
\x2c \x16 \x10 \x16 \x20 \x00 \x77 \x4a
\x00 \x54 \x7b \x40 \x2d \xe1 \x9a
各部分的內容分別爲：
字段 內容
MHDR \x00
AppEUI \x01 \x00 \x00 \x20 \x00 \xc5 \x26 \x2c
DevEUI \x16 \x10 \x16 \x20 \x00 \x77 \x4a \x00
DevNonce \x54 \x7b
MIC \x40 \x2d \xe1 \x9a
第三步
3.NS向AS發送設備入網包
樣例數據:
{
“join”: {
“request”: {
“frame”: “AAEAACAAxSYsFhAWIAB3SgBUe0At4Zo”
}
}
}
將join.frame進行base64 解碼，得到的內容爲：
\x00 \x01 \x00 \x00 \x20 \x00 \xc5 \x26
\x2c \x16 \x10 \x16 \x20 \x00 \x77 \x4a
\x00 \x54 \x7b \x40 \x2d \xe1 \x9a
可以看到，原先的MAC 層的data數據沒有變化
第四步
4.AS同意入網並且向NS回覆同意入網
樣例數據:
{
“join”: {
“moteeui”: “4a770020161016”,
“accept”: true
}
}
第五步
5.NS生成MoteAddr,並將node端的信息發送給AS
樣例數據:
{
“join”: {
“appeui”: “2c26c50020000001”,
“moteeui”: “4a770020161016”,
“details”: {
“moteaddr”: “48000002”,
“devicenonce”: 31572
}
}
}
第六步
6.AS生成密鑰，並將相關信息告訴NS
樣例數據:
{
“join”: {
“moteeui”: “4a770020161016”,
“complete”: {
“frame”: “IPqAKXQ7LS/CmYVCDy8K3k4”,
“networkkey”: “de03331aeb4254e9727b6fafbf13db3d”
}
}
}
可以看到，networkkey直接發送給NS了，這也就是NwkSKey，之所以明文告訴NS，是因爲:
1.NS不做解密的工作,所以不能通過APPKEY解密負載得到
2.networkkey在NS對上下行數據進行校驗的時候會使用到
第七步
7.NS將數據告訴GW,GW再轉換成MAC包，發送給node
樣例數據：
{
“txpk”: {
“tmst”: 537505620,
“freq”: 471.9,
“rfch”: 0,
“powe”: 14,
“modu”: “LORA”,
“datr”: “SF12BW125”,
“codr”: “4/5”,
“ipol”: true,
“size”: 17,
“data”: “IPqAKXQ7LS/CmYVCDy8K3k4”
}
}
需要注意的是,此時的data部分是經過base64編碼以及AES加密的，直接解碼，看到的數據是無效的，需要再進行解密，解密需要使用APPKEY，也就是之前介紹的APPKEY.
txpk.data部分就是LoRaWAN MAC的join_accept message.
第八步
8.node解析join_accept message 部分
根據LoRaWAN specification 可知，join_accept message的格式如下:
| MHDR | AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList(pad16) | MIC |
|---|---|---|---|---|---|---|---|
| 1字節 | 3字節 | 3字節 | 4字節 | 4字節 | 1字節 | 0/16字節 | 4字節 |
其中
字段 描述
MHDR 數據包頭，其中包含了數據包的類型，也就是說從這個包頭可以知道，這是一個join_accept message
AppNonce 3字節的unique ID,服務器生成的，產生AppSKey/NwkSKey 會用到
NetID 網絡ID，產生AppSKey/NwkSKey 會用到
DevAddr 設備的短地址
DLSettings 設置RX1和RX2的下行接受串口的速率
RxDelay 從發送完成到打開RX1接受串口的事件
CFList(pad16) 我也不知道是什麼，目前看到的都是0個字節
MIC 4字節的校驗
需要注意的是Join_accept message是加密的，需要使用APPKEY解密
txpk.data:
“data”: “IPqAKXQ7LS/CmYVCDy8K3k4”
base64解碼:
\x20 \xfa \x80 \x29 \x74 \x3b \x2d \x2f
\xc2 \x99 \x85 \x42 \x0f \x2f \x0a \xde
\x4e
這個數據是未解密的，我們還需要解密
解密後爲
\x20 \x43 \x75 \xcb \x24 \x00 \x00 \x02
\x00 \x00 \x48 \x03 \x00 \x82 \xc9 \xd0
\xf9
具體的情況如下:
字段 解密前 解密後
MHDR \x20 \x20
AppNonce \xfa \x80 \x29 \x43 \x75 \xcb
NetID \x74 \x3b \x2d \x24 \x0 \x0
DevAddr \x2f \xc2 \x99 \x85 \x2 \x0 \x0 \x48
DLSettings \x42 \x3
RxDelay \x0f \x0
CFList
MIC \x2f \x0a \xde \x4e \x82 \xc9 \xd0 \xf9
可以看到,DevAddr爲0x48000002，而AppSKey和NwkSKey無法直接看出來，需要再計算
計算公式如下:
NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16)
AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)