LoRaWAN1.0.x规范详解之空口帧结构

文章目录

  • 1 前言
  • 2 LoRaWAN空口帧结构
    • 2.1 入网(JOIN)
      • 2.1.1 入网请求(Join Request)
      • 2.1.2 入网接受(Join Accept)
      • 2.1.3 Join小结
    • 2.2 数据通信(Data Message)
      • 2.2.1 数据消息类型
      • 2.2.2 MAC命令
  • 3 Wireshark分析LoRaWAN空口包
    • 3.1 Join Request
    • 3.2 Join Accept
    • 3.3 Confirmed Data Up
    • 3.4 Unconfirmed Data Down(ACK)
    • 3.5 Unconfirmed Data Down(Application Data)

1 前言

帧结构是通信协议的核心设计内容。设计MAC层的主要工作之一就是帧(数据)结构的设计。
LoRaWAN规范(LoRaWAN Speicification)虽然只定义到了数据链路层(无上层LLC层,只有下层MAC层),但是LoRaWAN空口帧结构作为LoRaWAN规范的核心知识要点,设计精简,是学习无线通信协议的很好参考。

2 LoRaWAN空口帧结构

LoRaWAN规范自下而上设计,充分发挥了LoRa的硬件优势,LoRaWAN空口帧结构非常精简,如图2.1所示。这样最大化优化了物联网终端的功耗,降低整体系统的复杂度、系统成本等。
下图2.1基本涵盖了LoRaWAN1.0.x空口传输的所有信息。
LoRaWAN1.0.x规范详解之空口帧结构_第1张图片

图2.1 LoRaWAN 空口帧结构
LoRaWAN物理层主要是LoRa物理层(部分Region有采用FSK,作为高速应用的补充),LoRa物理层采用LoRa有头模式(Explicit Header Mode)(PS:除了Class B Beacon,其采用了Implicit Header),上行带硬件CRC,下行不带硬件CRC。同时采用的同步字是0x34(有别于现有市场的私有LoRa应用的同步字0x12)。
LoRaWAN空口帧的MAC层按照消息类型(MTypes)来看,有6个消息类型:

  • 入网 2个
  • 数据通信 4个
    • MAC命令

2.1 入网(JOIN)

入网是LoRaWAN通信的开始,只有正确加入LoRaWAN网络的设备,才能进行数据通信。入网包含了两个消息:

  • Join Request
  • Join Accept

2.1.1 入网请求(Join Request)

设备通过发送加入请求(Join Request)来申请加入目标LoRaWAN网络。
入网请求(Join Request)包含了两个EUI号,数据长度都是8 Byte,分别是DevEUIAppEUI。DevEUI遵循EUI-64命名规范,是设备的全球唯一标识。AppEUI命名规则根据实际运营网络而定。

DevNonce为2 Byte的随机数,用来防止JOIN的重播攻击,NS服务器会跟踪记录每次JOIN Request中的DevNonce,只有在接收到第一条上行后,在删除该DevNonce,因此NS服务器能够通过DevNonce值来识别出重播攻击,拒绝响应Join Accept。
MIC(4 Byte)是对Join Request的完整性检查,只有拥有根秘钥AppKey,才能计算得到有效mic值,否则将被NS服务器拒绝,因此可以防止伪造节点。
image.png
图2.2 Join Request的MIC生成方法

2.1.2 入网接受(Join Accept)

入网接受包(Join Accept)是NS服务器对设备的入网许可回复。
入网接受包通过Appkey来加密。
image.png
图2.3 Join Accept解密方式
AppNonce若为3 Byte的随机数,可(与DevNonce)每次派生出不同两个会话秘钥AppSKey、NwkSKey


image.png
图2.4 会话秘钥AppSKey、NwkSKey派生方式
NetID(3 Btye)标识网络ID,用于区别同一地理区域内可能存在的多个不同运营商的LoRaWAN网络,全球性的NetID,LoRa Alliance已执行了新的管理办法。
DevAddr(4 Byte)标识设备在网络内的短地址。
DLSettings(1 Byte)用于NS服务器侧调整RX1,RX2的速率。可以根据不同地区,网关可支持的最大功率来调整,以实现上行与下行无线链路预算的平衡。
RxDelay(1 Byte)用于NS服务器侧调整RX1窗口开启延时
CFList(16 Byte)是可选的频率表字段,NS服务器可根据Reginal Parameters与实际部署需要,决定是否携带频率表信息。
MIC是对Join Accept的完整性检查。
image.png
图2.5 Join Accept的MIC生成方式

2.1.3 Join小结

  1. 入网请求包(Join Request)是明文发送,但是受MIC(消息完整性检查)保护。(LoRaWAN的所有消息类型都受MIC保护)。
  2. 入网接受包(Join Accept)是密文发送。需要通过根秘钥AppKey解密得到。
  3. 入网可以实现会话秘钥(AppSKey、NwkSKey)的动态更新。
  4. 具备一定的防重播攻击、防伪节点的能力。

2.2 数据通信(Data Message)

数据通信用来传输MAC命令与应用数据。
MAC层网络开销是13字节,如图2.1蓝色区块(在没有FRMPayload的情况下,实际网络开销是12字节,缺省情况下,未发送Fport.)
DevAddr是入网后,获取的网内短地址标识。
Fctl(1 Byte)是网络控制字节,按位来标识ADR、ACK、Fpending、Class B、Foptslen等网络控制信息
Fcnt(2 Byte)是帧计数器,由发送端维护,即终端侧FCntUp与服务器侧FCntDown,LoRaWAN支持2 Byte与4 Byte的Fcnt。4 Byte的Fcnt具有更大线性计数空间,相应的也具备更好安全性,但是需要发送端进行相应的计数器向上溢出、掉电\上电保护等。2 Byte的Fcnt则可以直接拿来就用,无需特殊保护。
Fport(1 Byte)是应用端口号,用于指示FRMPayload的数据属性。Fport=0,FRMPayload用于传输MAC命令。Fport=224,FRMPayload用于传输LoRaWAN联盟定义认证测试应用。1~233 可根据实际情况,自定义使用。
FRMPayload为应用数据。最大数据包长度受限于通信速率。

2.2.1 数据消息类型

根据数据消息是否有显性应答,分为确认帧(Confirmed-data message)与非确认帧(Unconfirmed-data message

  • 确认帧 :接收端必须应答
  • 非确认帧 :接收端不要求应答

2.2.2 MAC命令

MAC命令属于LoRaWAN协议层数据,主要用于实现网络的运维与管理、网络动态优化等。
橙色由设备端发起,蓝色由NS服务器发起。

CID MAC命令 描述
0x02 LinkCheck 可用于设备端进行LoRaWAN链路的可达性测试
0x03 LinkADR 用于NS服务器进行ADR提速与调整功率
0x04 DutyCycle 用于NS服务器进行占空比配置
0x05 RxParamSetup 用于NS服务器进行Rx速率参数(RX1\RX2)调整
0x06 DevStatus 用于NS服务器获取设备电池信息与无线链路余量Margin
0x07 NewChannel 用于NS服务器新增\删除\修改信道
0x08 RxTimingSetup 用于NS服务器进行RX1窗口时间(RX1Delay)的调整
0x09 TxParamSetup 用于NS服务器进行TX功率、驻留时间的调整
0x0A DIChannel 用于NS服务器对RX1窗口频率的特殊设定
0x0D DeviceTime 可用于设备端获取全网时间,辅助Class B Beacon 同步等

3 Wireshark分析LoRaWAN空口包

接下来透过最流行的开源协议分析工具Wireshark(PS:Wireshark2.6.0版本开始增加了LoRaWAN协议的解析器),来实际看看LoRaWAN空口数据包。

3.1 Join Request

LoRaWAN1.0.x规范详解之空口帧结构_第2张图片
图3.1 Join Request

  • “Join Request”为明文传输,但受MIC保护

3.2 Join Accept


LoRaWAN1.0.x规范详解之空口帧结构_第3张图片
图3.2 Join Accept

  • “Join Accept”为密文传输,没有根秘钥Appkey,则无法获取原始信息内容

3.3 Confirmed Data Up

LoRaWAN1.0.x规范详解之空口帧结构_第4张图片
图3.3 确认帧上行

  • 上行用户数据“Frame Payload”采用AES128加密,没有会话秘钥AppSkey,则无法获取原始信息内容

3.4 Unconfirmed Data Down(ACK)


LoRaWAN1.0.x规范详解之空口帧结构_第5张图片
图3.4 上行确认帧的回复(下行非确认帧)

  • 在没有用户数据的情况,实际下行空口是12个字节(纯MAC层开销)

3.5 Unconfirmed Data Down(Application Data)


LoRaWAN1.0.x规范详解之空口帧结构_第6张图片
图3.5 上行确认帧的回复(下行非确认帧,并携带用户数据)

  • 下行用户数据“Frame Payload”采用AES128加密,没有会话秘钥AppSkey,则无法获取原始信息内容
    LoRaWAN1.0.x规范详解之空口帧结构_第7张图片

你可能感兴趣的:(IoT通信)