正文

（5）LoraWAN：Join procedure、Receive Windows

IP云
IP云V管理员/5 阅读
08/29
提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

网络在建立之初，终端设备启动后需要向服务端发起Jion请求（接入请求），只有在接入请求得到成功答复，并根据答复配置相关参数后，终端才算成功加入网络。Jion成功后才能进行数据的上行、下行通信。

Jion过程、CLASS A等模式下，服务器、终端之间约定了两个下行接收窗口（时间窗口）来实现数据的交互。一般通信方式为：终端上行数据包后进入低功耗模式，等到约定的时间窗口后开始进入接收模式，接收服务器下行来的数据。

在Jion之前要了解一下Receive Windows概念。

接收窗口Receive Windows

在每次上行传输的终端设备打开两个短的接收窗口。接收窗口开始时间是一个配置周期的传输结束的最后一个上行比特。 终端在上行结束后考虑到功耗等问题不会立即进入接收模式，低功耗到合适时机再打开接收，接收下行数据。此协议约定了两个窗口，数据只会在其中一个窗口中接收到。

First receive window channel, data rate, and start

第一接收窗RX1使用相同的频率信道作为上行链路和一个数据速率是用于上行链路数据速率的函数。上行链路调制结束后RX1打开RECEIVE_DELAY1秒（+/- 20微秒）。上行链路和RX1时隙下行链路数据速率之间的关系，特定区域和详见的第7节；默认情况下，第一接收窗口数据速率是相同的，即最后的上行链路的数据速率。

Second receive window channel, data rate, and start

第二接收窗RX2采用固定配置的频率和数据率；上行链路调制结束后RX2打开RECEIVE_DELAY2秒（+/- 20微秒）。可通过MAC命令修改的频率和数据速率。

接收窗口持续时间Receive window duration

接收窗口的长度必须至少为有效地检测的下行链路前同步码所要求的终端设备的无线电收发机的时间。

Receiver activity during the receive windows

如果在接收窗口中的一个被检测到前置码，无线接收机将一直处于活动状态直到下行链路帧被解调。如果一个帧被检测到并且随后在第一接收窗口期间解调出来了，且在地址和MIC（消息完整性代码）校验通过后，该帧该是终端的目的帧，终端将不会打开第二接收窗口。

Network sending a message to an end-device

如果网络打算发送的下行链路到一个终端设备，它总是恰恰在接收窗口（两个之一）开始之前发起传输。

接收窗口重要提示Important notice on receive windows

一个终端不得发送另一个上行链路消息，除非它已经接收在上次发送的第一或第二接收窗的下行链路消息，或者前一次传输的第二接收窗口已过期。

接收或发送其他协议Receiving or transmitting other protocols

节点可以在LoRaWAN发送和接收窗口之间侦听、发送其他协议或做任何业务，只要终端仍符合当地法规，和LoRaWAN规范兼容。

Join procedure

从终端角度来看，Join过程包含两个MAC层数据信息与server服务器交换，即join request 和 join accept。

enum {
// Join Request frame format
OFF_JR_HDR = 0,
OFF_JR_ARTEUI = 1,
OFF_JR_DEVEUI = 9,
OFF_JR_DEVNONCE = 17,
OFF_JR_MIC = 19,
LEN_JR = 23
};
enum {
// Join Accept frame format
OFF_JA_HDR = 0,
OFF_JA_ARTNONCE = 1,
OFF_JA_NETID = 4,
OFF_JA_DEVADDR = 7,
OFF_JA_DLSET = 11,
OFF_JA_RXDELAY = 12,
OFF_CFLIST = 13,
LEN_JA = 17,
LEN_JAEXT = 17+16
};

  • [x] Join-request message

    Join-request信息包含终端的AppEUI、DevEUI及随机的DevNonce（2字节）。

    DevNonce是一个随机值。网络服务器server将保持对每个终端的过去一定数量的DevNonce值进行跟踪，如果join request请求过程中的DevNonce值与跟踪的DevNonce值相同则将忽略该终端的join请求。DevNonce主要用于网络的重放攻击。

  • [x] Join-accept message

  1. 假如终端被允许接入网络，网络服务器将用join-accept响应终端的join-request请求。Join-accept信息将像普通的下行一样的发送，只不过会使用JOIN_ACCEPT_DELAY1 或JOIN_ACCEPT_DELAY2（而不是分别用RECEIVE_DELAY1和RECEIVE_DELAY2） 这样的延时。

    假如join-request请求没有被接受，将不会给终端响应。

  2. Join-accept信息中包含3字节的App应用随机数（AppNonce），一个网络标示（NetID），一个设备地址（DevAddr），一个TX和RX之间延时（RxDelay）以及一个终端正在加入的网络的频率信道列表选项（CFList）。

    AppNonce是一个随机值或者基于某些形式的由网络服务器提供的唯一ID值，AppNonce用于终端导出NwkSKey和AppSKey两个会话密钥。

    NetID格式如下：低7位（LSB）命名为NwkID与前面章节所述的的7位MSB短地址相匹配。相邻或者重叠的网络必须具有不同的NwkIDs。剩下的17个高位可以由网络运营商任意选择。

    DLsettings字段的下行链路配置：

    Bits | 7 |6:4 | 3:0 |

    -------------|---|--------| -------|

    DLsettings |RFU|RX1DRoffset|RX2 Data rate

RX1DRoffset 字段设置在第一接收窗口（RX1）上行数据速率与下行数据速率通信之间的偏移，默认情况下该偏移量为0；改偏移量主要考虑到在某些区域基站的最大功率约束密度以平衡上行及下行的链路余量。

终端激活后的数据存储

终端激活后，以下信息将保存：设备地址(DevAddr)，APP应用标示(AppEUI)，网络会话密钥，APP应用密钥 (AppSKey)。

终端地址End-device address (DevAddr)

所述DevAddr由当前网络内终端32位标示组成，其格式如下：

Bit# | [31..25] | [24..0] |

-------------|----------|---------|

DevAddr bits | NwkID | NwkAddr |

高7位用作网络标识符（NwkID）以分离不同的网络运营商的地域重叠网络的地址，并以补救漫游的问题。所述低25位为终端的网络地址（NwkAddr），可以任意地由网络管理器分配。

u4_t addr = os_rlsbf4(LMIC.frame+OFF_JA_DEVADDR);
...
LMIC.devaddr = addr;

APP应用标示 Application identifier (AppEUI)

AppEUI是IEEE标准的全球APP应用ID，EUI地址空间是终端APP应用供应商的唯一标示。

所述AppEUI在执行激活过程之前就被存储在终端中。

网络会话密钥Network session key (NwkSKey)

所述NwkSKey终端特定的网络会话密钥。网络服务器和终端通过NwkSKey来计算和确认的所有数据信息的MIC验证（消息完整码），以确保数据的完整性。NwkSKey进一步用于加密和解密Payload字段仅MAC相关层的数据信息。

终端Join请求过程中在其开始执行Join之前如下的信息需要个性化设置：全球唯一终端标示(DevEUI)、APP应用标示(AppEUI)、AES-128加密/解密密钥(AppKey)。

APP应用会话密钥Application session key (AppSKey)

AppSKey是终端特定的APP应用会话密钥。网络服务器和终端通过AppSKey加密和解密Payload字段中APP应用程序特定数据信息。它也可以用来计算和验证包含在Payload字段中应用程序特定数据消息的应用程序级的MIC。

End-device identifier (DevEUI)

DevEUI是IEEE标准中的全球终端ID；EUI64地址空间是终端的全球唯一标示。

Application key (AppKey)

AppKey是针对该终端特有的AES-128应用密钥，该密钥由应用程序所有者分配给该终端设备。APPKey仅能从已知的特定App应用根密钥中获取和App应用提供者控制下得到。每当一个终端经过空中激活过程，所述的AppKey将用于导出NwkSKey会话密钥及AppSKey会话密钥，特定于该终端的会话密钥以便该终端加密和验证网络通信和App应用数据。

static void MsgProcess(void)