标签: lorawan

我试图了解LoRaWAN 1.2规范中的三个神奇的LoRaWAN ID 。我的理解是：

• DevEUI 就像一个MAC地址
• AppKey 就像一个公钥（大概...）
• AppEUI 就像一个端口号

现在，我在理解由谁负责创建这些ID时遇到了问题：

• DevEUI 可以从LoRa芯片内部ID寄存器生成（我正在使用村田制作所的ABZ类型芯片）
• AppKey：每个端节点是否应该唯一？我应该选择一个随机的还是从LoRaWAN提供商那里问一个（例如Objenious）？
• AppEUI：每个终端节点应该公用（我想应该是）？我应该随机选择一个，还是向LoRaWAN提供商询问？

我已经成功地将TTN theThingsNetwork与我的LoRaWAN网关集成在一起。我也能够在节点之间到ThingsNetwork之间转发数据。现在，我正在寻找信息以将数据从TTN Thethingsnetwork获取到我自己的服务器。任何信息将不胜感激。提前致谢。

此致Zaheen

我肯定在阅读 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是不是坏了？:)

乍一看，我和很多人有同样的问题。但我的情况有点复杂。

先决条件：
项目语言： Java 11
网络服务器： Orbiwise NS ( https://eu.saas.orbiwise.com/ )
设备：（STM32 + Wifi 模块）通过 Lorawan 网关连接到 Orbiwise 并通过 wifi 使用 TCP 套接字。

40 24 fa fa 01 c2 c5 25  03 06 01 43 a4 99 5a c1
85 71 0c 87 38 84 53 9a  80 6c 5a 14 da f8 ff 7c
21 83 8f 78 8e ec f2 7d  4e 4e 07