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

Question

我肯定在阅读 LoRaWAN 规范时漏掉了一些东西，因为这似乎太糟糕了，不可能是真的。请告诉我我神志不清:)

当我有很多 OTAA 节点时，我的测试台似乎会发生以下情况，但我不知道什么会阻止它:

我的网络中的多个节点同时发出 JOIN REQUEST(这可能是偶然发生的，或者它们同时开机)

网关成功接收(至少)其中一个并以分配 DevAddr 的 JOIN ACCEPT 响应，认为一个节点做了加入请求

所有执行 JOIN REQUEST 的节点都会收到 ACCEPT 并认为 JOIN ACCEPT 是针对它们的，并且很高兴设置相同的接收 DevAddr

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

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

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

它具有:AppNonce NetID DevAddr DLSettings RxDelay CFList，并使用网络唯一而非节点唯一的 AppKey 进行加密。 MIC 仅涉及这些值，因此也无济于事。

我本来希望 JOIN ACCEPT 至少包括请求加入的 DevEUI 作为 MIC 的一部分，并且它还将包括 DevNonce。似乎两者都不包括。

是什么赋予了？ OTAA 是否损坏？ :)

Answer 1

每个设备的 MIC 都不同，因为它基于设备和网络之间共享的 secret (并且应该是唯一的)主 key (AppKey)。
设备做的第一件事是检查 MIC，如果它不是预期的，它将丢弃消息。
所以你下面说的并不完全正确:

The JOIN ACCEPT has, as far as I can see, no data in it which is derived from the JOIN > REQUEST, and therefore it can't be directed to a specific node in the case that many > > nodes are currently listening to an ACCEPT.

It has: AppNonce NetID DevAddr DLSettings RxDelay CFList, and isencrypted with the AppKey which is network unique and not node unique.The MIC only involves these values and so doesn't help either

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