是什么阻止 LoRaWAN 节点在 OTAA 中接受相同的 JOIN ACCEPT 消息

Question

我肯定在阅读 LoRaWAN 规范时错过了一些东西，因为这看起来太糟糕了，难以置信。请告诉我我神志不清:)

当我有许多 OTAA 节点并且我不知道什么会阻止它时，我的测试台中似乎会发生以下情况：

1. 我的网络中的多个节点同时发出加入请求（这可能是偶然发生的，或者如果它们同时启动）

2. 网关成功接收（至少）其中一个，并以分配 DevAddr 的 JOIN ACCEPT 进行响应，认为一个节点执行了加入请求

3. 所有发出 JOIN REQUEST 的节点都会收到 ACCEPT 并认为 JOIN ACCEPT 是针对它们的，并很乐意设置相同的接收到的 DevAddr

从这里开始，我们有几个节点，它们都认为它们已成功加入，并且都认为它们是唯一的，但具有相同的 DevAddr。不用说，系统会变得严重混乱。

阅读LoRaWAN规范，JOIN REQUEST有节点唯一的DevEUI、网络唯一的AppEUI和随机的DevNonce（防止重放攻击）。MIC 是根据这些和节点中存储的秘密网络唯一的 AppKey 计算得出的。

据我所知，JOIN ACCEPT 中没有从 JOIN REQUEST 派生的数据，因此在许多节点当前正在侦听 ACCEPT 的情况下，它无法定向到特定节点。

它有：AppNonce NetID DevAddr DLSettings RxDelay CFList，并用AppKey加密，AppKey是网络唯一的，而不是节点唯一的。MIC 仅涉及这些值，因此也没有帮助。

我预计 JOIN ACCEPT 至少包括请求加入作为 MIC 一部分的 DevEUI，并且还包括 DevNonce。似乎两者都不包括。

是什么赋予了？OTAA是不是坏了？:)

Answer 1

每个设备的 MIC 都不同，因为它基于设备和网络之间共享的秘密（并且据称是唯一的）主密钥 (AppKey)。

设备做的第一件事是检查 MIC，如果不符合预期，则会丢弃消息。

所以你下面说的并不完全正确：

据我所知，JOIN ACCEPT 中没有从 JOIN > REQUEST 派生的数据，因此在许多 >> 节点当前正在侦听某个节点的情况下，它无法定向到特定节点。接受。

它有：AppNonce NetID DevAddr DLSettings RxDelay CFList，并用AppKey加密，AppKey是网络唯一的，而不是节点唯一的。MIC 仅涉及这些值，因此也没有帮助

当然，如果您在每台设备上设置相同的 AppKey，您将得到您所描述的内容:)

Answer 2

一项限定条件是加入请求 (JR) 和加入接受 (JA) 的时间要求。规范规定设备只能使用在发送 JR 后“恰好”5 或 6（第二个窗口）秒收到的 JA。

我希望有比这个时间更好的故障保护，但目的可能是防止错误的标签获取 JA。