本文主要是介绍LoRaWan协议解析,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
目录
LoRaWAN协议数据包
入网请求数据包分析
入网回复数据包分析
不需要确认上行数据包分析
需要确认上行数据包分析
不需要确认下行数据包分析
需要确认下行数据包分析
LoRaWAN协议数据包
LoRaWan协议中规定了7种不同的数据包,每种数据包又有不同的字段,除了“入网请求”和“入网回复”,其它的数据包都是AES-128加密的。
7种不同的数据包分别为:
LoRaWAN协议数据包格式 |
Join Request |
Join Accept |
Unconfirmed Data Up |
Unconfirmed Data Down |
Confirmed Data Up |
Confirmed Data Down |
Proprietary |
针对OTAA,终端必须按照加网流程来和网络服务器进行数据交互。如果终端丢失会话消息,则每次必须重新进行一次加网流程。
加网流程需要终端准备好三个参数:DevEUI、AppEUI、AppKey。
DevEUI和AppEUI类似,AppKey是由应用程序拥有者分配给终端,很可能是由应用程序指定的根密钥来衍生的,并且受提供者控制。
当终端通过OTAA方式加入网络,AppKey用来产生会话密钥NwkSKey和AppSKey,会话密钥分别用来加密和校验网络层和应用层数据。
OTAA和ABP的区别在于:
OTAA就是入网时通过AppKey产生临时的会话密钥NwkSKey和AppSKey,入网后再用临时的会话密钥NwkSKey和AppSKey去进行通信。
ABP就是协商好会话密钥NwkSKey和AppSKey,再用会话密钥NwkSKey和AppSKey去进行通信。
入网请求数据包分析
字节数 | 1 | 8 | 8 | 2 | 4 |
内容 | MHDR | AppEUI | DevEUI | DevNonce | MIC |
DevNonce是一个设备随机值,网络服务器为每个终端记录过去的DevNonce数值。如果相同设备发出相同的DevNonce,网络服务器就会忽略join request。DevNonce的随机生成可看lorawan协议,有具体算式。
入网请求不需要加密。
例如:00B14781E3765F9B3CE50000FF0C010100727A8C4307D9
00:入网请求消息类型,LoRaWAN R1主版本号。
B14781E3765F9B3C:AppEUI = 3C9B5F76E38147B1
E50000FF0C010100:DevEUI = 0001010CFF0000E5
727A:DevNonce = 7A72,随机值
8C4307D9:MIC校验
入网回复数据包分析
字节数 | 1 | 3 | 3 | 4 | 1 | 1 | (16)Optional | 4 |
内容 | MHDR | AppNonce | NetID | DevAddr | DLSettings | RXDelay | CFList | MIC |
如果网络服务器准许终端加入网络,就会用Join Accept对Join Request进行应答,否则网络服务器无动作,即终端不会收到回应。
Join Accept是作为一个普通下行帧进行下发的,唯一的区别是它使用的是JOIN_ACCEPTA_DELAY1或JOIN_ACCEPTA_DELAY2(分别代替RECEIVR_DELAY1和RECEIVR_DELAY2),但是它所使用的两个接收窗口的信道频率和数据速率和LoRaWAN地区参数文件所描述的RX1和RX2接收窗口相同。
AppNonce是一个应用随机数,由网络服务器所提供的一个随机值或者某种形式的唯一ID,用于终端得到两个会话密钥NwkSKey和AppSKey(有具体的算式,看lorawan协议)。
NetID为网络标识符,7个最低有效位为实际的NetID并且和终端短地址的7个最高有效位相对应。保留的17个最高有效位可以由网络运营商进行自由选择。
DevAddr为终端地址,由可标识当前网络设备的32位ID所组成。高7位是NwkID,用来区别同一区域内的不同网络,另外也保证防止节点窜到别的网络去。低25位是NwkAddr,是终端的网络地址,可以由网络管理者来分配。
Bits 31:25 24:0 DevAddr NwkID NwkAddr DLSettings字段:
Bits 7 6:4 3:0 DLSettings RFU RX1DRoffset RX2DataRate RX1DRoffset位域设置上行数据速率和RX1下行数据速率的偏移量。默认情况下偏移量为0(意思是上行数据速率和下行数据速率相等)。偏移量用于考虑一些地区的基站最大功率密度限制和平衡上下行射频链路预算。
RxDelay字段:
Bits 7:4 3:0 RxDelay RFU Del(单位s,对应1~15s,0值也代表1s)
Join Request的消息是使用AppKey进行加密的,具体有算式,可看lorawan协议。
注意:网络服务器在ECB模式下使用一个AES解密操作去对Join Request的消息进行加密,因此终端就可以使用一个AES加密操作去对消息进行解密。这样终端只需要去实现AES加密而不是AES解密。
注意:建立NwkSKey和AppSKey这两个会话密钥使得网络服务器中的网络运营商无法窃听应用层数据。在这样的设置中,应用提供商必须支持网络运营商处理终端的加网以及为终端生成NwkSKey。同时应用提供商向网络运营商承诺,它将承担所产生的任何流量费用并且保持用于保护应用数据的AppSKey的完全控制权。
例如:204D6E5D25D464B81B78FB0C4ED1214F96
20:入网回复消息类型,LoRaWAN R1主版本号。
4D6E5D:AppNonce = 5D6E4D
25D464:NetID = 64D425
B81B78FB:DevAddr = FB781BB8
0C:DLSettings = 0C,即RX1DRoffset = 0,RX2DataRate = 12
4E:RXDelay = 4E,即RXDelay.Del = 14,即延迟14s。
D1214F96:MIC校验
不需要确认上行数据包分析
例如:40DE6D2707000000DE11B4E3748D7BFE017F621FEFE2E2
40:无需认证的上行数据,LoRaWAN R1主版本号。
DE6D2707:DevAddr = 07276DDE
00:帧控制字节。ADR = 0,ADRACKReq = 0, ACK = 0, FOptsLen = 0。
0000:FCnt = 0000。
DE:FPort = DE,供应用层使用。当数据包长度大于12时,FPort存在。
11B4E3748D7BFE017F62:FRMPayload。经过AES-128加密的实际数据包。
1FEFE2E2:MIC校验
需要确认上行数据包分析
例如:80DE6D270700010005DB351121DAEB0BD87FAAD212
80:需要认证的上行数据,LoRaWAN R1主版本号。
DE6D2707:DevAddr = 07276DDE
00:帧控制字节。ADR = 0,ADRACKReq = 0, ACK = 0, FOptsLen = 0。
0100:FCnt = 0x0001。
05:FPort = 05,供应用层使用。当数据包长度大于12时,FPort存在。
DB351121DAEB0BD8:FRMPayload。经过AES-128加密的实际数据包。
7FAAD212:MIC校验
不需要确认下行数据包分析
例如:60DE6D2707200100DD2A6EC398BED0
60:无需认证的下行数据,LoRaWAN R1主版本号。
DE6D2707:DevAddr = 07276DDE
20:帧控制字节。ADR = 0,ADRACKReq = 0,ACK = 1,FPending = 0,FOptsLen = 0。
0100:FCnt = 0x0001。
DD:FPort = DD,供应用层使用。当数据包长度大于12时,FPort存在。
2A6E:FRMPayload。经过AES-128加密的实际数据包。
C398BED0:MIC校验
需要确认下行数据包分析
类推。。。
这篇关于LoRaWan协议解析的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!