LoRaWAN未经证实的下行链路和重新加入程序

Question

最近，我开始研究支持LoRa的设备，并注意到有些设备在从Network Server取消设置时无法处理。这在开发过程中经常发生（特别是如果NS也在开发中）。

以下是发生的事情：

• 在Network / App Server上配置的LoRa设备。
• LoRa设备发送JOIN并成功。
• 我删除了网络服务器上的设备实体并再次添加。这会导致删除在OTAA期间生成的会话密钥以及清除devEUI
• LoRa设备继续发送数据，并在服务器上被拒绝。
• LoRa设备无需处理它并继续发送数据。

某些设备在重启时会再次发送JOIN。但并非所有设备都可以进行电源循环！我看到有些电表在重新连接后的硬接线电池上被拒绝工作了！

有没有＆＃34;常见＆＃34;设备应如何检测/处理此类＆＃34;断开连接的方法＆＃34;来自NS？

Answer 1

终端设备可以通过请求网络服务器的下行链路来定期检查会话。

发送确认的数据包或链接检查请求应该从服务器获得响应。

ADR将在64个上行链路之后请求下行链路并且应该接收响应。如果在32个附加上行链路之后没有看到响应，则数据速率降低。如果达到最低数据速率，则重新启用默认通道。 终端设备不认为会话丢失或断开，它将继续发送数据包直到电池耗尽。

应用程序应根据其要求和期望确定会话何时丢失。

Answer 2

回答我自己的问题：

在5.2和＃34;链路检查命令（LinkCheckReq，LinkCheckAns）＆＃34;中描述了LinkCheckReq MAC命令。 LoRaWAN规范1.1，它应该有助于确定设备是否有链接。

来源：LoRaWAN spec 1.1

Answer 3

然后在终端节点侧 - 设备加入网络后，网络类型标志设置为 OTAA（空中激活），并且在重置之前不会再次发送加入请求。

如果设备继续使用未经确认的上行链路传输，它不会检查 GW 是否收到消息。因此，要重新启动加入过程，应重新启动设备。