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

Posted 2023-02-19

【中文标题】LoRaWAN 未确认的下行链路和重新加入程序

【英文标题】：LoRaWAN unconfirmed downlink and re-JOIN procedure

【发布时间】：2018-06-03 04:37:19

【问题描述】：

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

这是发生了什么：

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

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

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

【问题讨论】：

一旦服务器返回一个JOIN ACCEPT消息，它就与设备建立了合约。您删除服务器上的设备实体只会破坏该合同。

“合同违约”可能由于多种原因而发生，无论是有意还是无意。无论如何，设备应该保持运行，对吗？我（到目前为止）看不到 LoRaWAN 定义了任何可以帮助检测“违规”的东西

设备保持运行。你只是告诉服务器它不应该再听它了。设备本身对此无能为力。如果服务器不简单地忽略它，DOS 攻击可能就太简单了。

【参考方案1】：

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

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

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

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

【参考方案2】：

回答我自己的问题：

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

来源：LoRaWAN spec 1.1

【参考方案3】：

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

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