LoRaWAN 未确认下行链路和重新加入过程

Question

最近我开始研究支持 LoRa 的设备，并注意到其中一些设备在未从网络服务器配置时无法处理情况。这种情况在开发过程中经常发生（特别是如果 NS 也在开发中）。

事情是这样的：

• 在 Network/App 服务器上配置的 LoRa 设备。
• LoRa设备发送JOIN成功
• 我删除了网络服务器上的设备实体，然后重新添加。这会导致删除 OTAA 期间生成的会话密钥并清除 devEUI
• LoRa设备不断发送数据，被服务器拒绝
• LoRa 设备不做任何处理并继续发送数据。

一些设备在重启时再次发送 JOIN。但并非所有设备都可以重新启动！我见过的一些仪表在重新连接硬接线电池后拒绝工作！

是否有任何 "common" 设备如何 应该 detect/handle 来自 NS 的 "disconnection" 的方法？

Answer 1

终端设备可以通过请求关闭网络服务器来定期检查会话link。

发送确认数据包或 link 检查请求应该会引起服务器的响应。

ADR 将在 64 uplinks 后请求 downlink，并且应该会收到响应。如果在额外的 32links 后没有看到响应，则数据速率会降​​低。如果达到最低数据速率，则重新启用默认通道。 终端设备不认为会话丢失或断开连接，它会继续发送数据包，直到电池耗尽。

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

Answer 2

回答我自己的问题：

LoRaWAN 规范 1.1 的第 5.2 "Link Check commands (LinkCheckReq, LinkCheckAns)" 节中描述了一个 LinkCheckReq MAC 命令，这应该有助于确定设备是否具有 link。

来源：LoRaWAN spec 1.1

Answer 3

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

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