我肯定在阅读 LoRaWAN 规范时错过了一些东西，因为这看起来太糟糕了，难以置信。请告诉我我神志不清:)
当我有许多 OTAA 节点并且我不知道什么会阻止它时，我的测试台中似乎会发生以下情况：
我的网络中的多个节点同时发出加入请求（这可能是偶然发生的，或者如果它们同时启动）
网关成功接收（至少）其中一个，并以分配 DevAddr 的 JOIN ACCEPT 进行响应，认为一个节点执行了加入请求
所有发出 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是不是坏了？:)