2

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

这是发生的事情：

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

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

设备应如何检测/处理与 NS 的这种“断开连接”是否有任何“通用”方法？

4

3 回答 3

0

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

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

于 2021-05-27T21:54:57.410 回答
0

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

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

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

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

于 2018-02-10T23:31:26.783 回答
0

回答我自己的问题：

LoRaWAN 规范 1.1 的第 5.2 节“链路检查命令（LinkCheckReq，LinkCheckAns）”中描述了一个 LinkCheckReq MAC 命令，它应该有助于确定设备是否具有链路。

来源：LoRaWAN 规范 1.1

于 2018-06-11T14:28:06.443 回答