LoRaWAN 规范 1.0 （6）

最新推荐文章于 2024-07-26 20:37:42 发布

eydwyz

最新推荐文章于 2024-07-26 20:37:42 发布

阅读量432

点赞数

分类专栏： LORA

LORA 专栏收录该内容

8 篇文章 2 订阅

订阅专栏

目录(?)[-]

LoRaWAN 规范10 第六章部分
1. 终端激活End-Device Activation
  1. 1 激活成功后存储在终端设备的数据
  2. 2 无线激活Over-the-Air Activation
2. PS

LoRaWAN 规范1.0 （第六章部分）

最近在做LoRa， LoRaWAN协议略微复杂，边读边翻译，现在把部分关键的翻译分享给各位做物联网的同行。
当然里面掺杂了一些我的个人笔记，希望对大家有所帮助。
如果哪里有问题，欢迎应各位留言或者邮件指正。

翻译很辛苦，转载请注明出处和源链接

6 终端激活（End-Device Activation）

所有终端设备在正式加入LoRaWAN网络之前必须先进行初始化并激活。有两种激活方式：
无线激活（Over-The-Air Activation (OTAA)），设备部署和重置时使用;
手动激活（Activation By Personalization (ABP)），此时初始化和激活一步完成。

6.1 激活成功后存储在终端设备的数据

以下信息在激活成功后回存储在终端设备：设备地址（DevAddr）、应用ID（AppEUI）、网络会话密钥（NwkSKey）和应用会话密钥（AppKey）。

6.1.1 终端设备地址（DevAddr）

DevAddr是终端在当前网络中的识别码，大小32bits。结构如下：

Bit [31..25] [24..0]
DevAddr bits NwkID NwkAddr

最高7位是网络ID（NwkID），用以区分有地域重叠的不同网络运营商和弥补有路由问题的网络。接下来的25bits，终端设备网络地址（NwkAddr），该地址可以有由网络管理员分配。
6.1.2 应用唯一识别ID（AppEUI）

AppEUI是 IEEE EUI64 的全球唯一应用ID，用以识别终端设备的应用服务提供商（等等）。AppEUI在进行激活操作之前就存储在终端设备中了。就是说AppEUI是出厂时烧录进去的。
6.1.3 网络会话密钥（NwkSKey）

NwkSKey是分配给终端设备的网络会话密钥。网络服务器和设备用它来计算和校验所有消息的MIC（消息一致码），来保证收发的数据一致。也可以用来对MAC负载（MAC命令放在Payload里面）的消息进行加/解密。
6.1.4 应用会话密钥（AppSKey）

AppSKey是分配给终端设备的应用会话密钥。网络服务器和设备用来对应用指定的 Payload字段进行加解密。也可以用来计算和校验应用层MIC（可能存放在应用指定消息的Payload中）。

Bit	[31..25]	[24..0]
DevAddr bits	NwkID	NwkAddr

6.2 无线激活（Over-the-Air Activation）

终端设备在与网络服务器交流（数据交换）之前，必须先通过加入过程加入网络服务器。每次终端设备会话的上下文丢失（与服务器通信断开）后都要重新加入。加入服务器之前，要使用以下信息初始化终端设备：全局唯一设备ID（DevEUI）、应用ID（AppEUI）、AES-128密钥（AppKey）。 AppEUI在上面6.1.2中有介绍。

* 注意：无线激活时，网络密钥初不会向初始化那样写死到终端，而是在终端加入网络时由网络层衍生并分发，该密钥用来对传输数据进行加密和校验。这样，终端设备能很方便的在不同的网络服务器和应用提供商之间切换。使用网络会话密钥和应用会话密钥*可以避免应用数据被网络供应商（网络服务器拥有者）解析或篡改，从而接入大量的网络服务器。

6.2.1 终端设备ID（DevEUI）

DevEUI是全球终端ID，符合 IEEE EUI64，用来唯一辨识终端设备。
6.2.2 应用密钥（AppKey）

AppKey是AES-128的应用密钥，由应用拥有者通过应用指定的根密钥衍生并分配给终端设备，根密钥只有应用供应商知晓和掌握。终端设备通过无线激活入网时，通过AppKey衍生会话密钥 NwkSKey和AppSKey，并分发相应的终端设备，用来加密和校验网络通讯和应用数据。
6.2.3 入网流程

从终端的角度看，和服务器交互的入网流程包含两个MAC消息：join request 和 join accept.
6.2.4 入网请求（Join-request message）

入网流程由终端发起，终端入网时发送入网请求，消息格式（MACPayoad）如下：

字节数 8 8 2
Join Request AppEUI DevEUI DevNonce

入网请求消息包含：AppEUI、DevEUI和终端设备产生的2字节的随机数（DevNonce）
DevNonce是个随机值，终端设备最近使用的一些(数量自定义)DevNonce会保存在网络服务器（NS）。如果终端发送的入网请求中的DevNonce在NS中可以查到，该请求就会被忽略。

注意：该机制的目的是防止重放攻击(replay attacks)，避免其它人通过发送之前的入网请求来断开终端设备和网络的连接。

入网请求的消息一致性校验码（MIC）（见第4章MAC消息部分）通过下述算法计算：
```
cmac = aes128_cmac(AppKey, MHDR | AppEUI | DevEUI | DevNonce)
MIC = cmac[0..3]
     
     1
2
     
     1
2
```
入网请求以明文发送。
6.2.5 接受入网消息（Join-accept）

服务器同意终端入网后网络服务器（NS）会回复接受入网消息。接受入网使用 JOIN_ACCEPT_DELAY1 或 JOIN_ACCEPT_DELAY2（而不是RECEIVE_DELAY1 和RECEIVE_DELAY2），和普通消息一样发送。这两种接收窗口使用的信道频率和数据率与 RX1和RX2的接收窗口（见章节“物理层”之”接收窗口”）相同。

入网请求被拒绝则服务器不发送任何数据。

接受入网消息包含以下字段：应用层随机数（AppNonce），3字节；网络ID（NetID）；终端地址（DevAddr）；介于 TX 和 RX（RxDelay）之间的延迟；信道频率的一系列配置（CFList）。CFList相关内容见第7章。

大小（字节） 3 3 4 1 1 变长(16)
接受入网 AppNonce NetID DevAddr DLSeting RxDelay CFList

AppNonce是由网络服务器产生的一个随机数或唯一ID，终端设备用它来衍生两个会话密钥：NwkSKey和AppSKey。衍生算法如下：
```
NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce |NetID | DevNonce | pad16)
AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)
     
     1
2
     
     1
2
```
接受入网的MIC计算方式如下：
```
cmac = aes128_cmac(AppKey,MHDR | AppNonce | NetID | DevAddr | RFU | RxDelay | CFList)
MIC = cmac[0..3]
     
     1
2
     
     1
2
```
消息本身采用 AppKey 加密，加密方式如下：
```
aes128_decrypt(AppKey, AppNonce | NetID | DevAddr | RFU | RxDelay | CFList | MIC)
     
     1
     
     1
```
注意：网络服务器加密接收入网消息使用的是 AEC ECB模式的解密算法。这样终端就不必再实现AES解密算法，只用AES加密即可。

PS ：之前关于NetID的翻译有误，特此更正。

NetID包含：7个最低有效位的NetID，称作NwkID；17个最高有效位，存放前面提到的终端短址。区域相邻或重叠的网络的NwkID不能相同。网络服务器可以任意处理余下的17个最高有效位。
NetID包含：NetID的7个最低有效位称作NwkID，即DevAddr（终端短址）的7个最高有效位。区域相邻或重叠的网络的NwkID不能相同。余下的17个最高有效位由网络运营商自由分配。

DLsetting字段含有下行配置：

位（Bits） 7 6:4 3:0
DLsettings RFU RX1DRoffset RX2 Data rate

RX1DRoffset设置上下行数据速率之间的偏移（偏差），和终端设备交互的首个接收时隙（RX1）。（感冒好几天了，头懵，不知道该怎么翻译）offset默认为0。下行数据速率不能比上行的大。考虑到一些地区基站的最大功率密度限制，offset用来平衡上行和下行的无线链路余量。
上行和下行链路数据速率之间的确切关系见章节 “物理层（Physical Layer）”

延时RxDelay规则和RXTimingSetupReq命令中的Delay字段相同。
6.3 手动激活

手动激活需要生产商提供的工具和配套网关等，考虑到目前国内还没有，暂时不翻译。