The best thing of TTN is that while creating an application and registering an end device node in the application, the AppEUI and AppKey both are automatically generated for us. It takes away the work from the end device programmer.
But now I am using the gateway from an external vendor who also gives me access to his cloud server running the network server. Here while creating an application and registering an end device node, the AppEUI and AppKey are not generated automatically. I have to manually enter them. So, I just select some random AppEUI and random AppKey and enter them and successfully register the device in the network server and start working with it. My questions are:
Are there any rules for generating an IEEE EUI-64 AppEUI. Should I follow any guidelines to create it. For testing and hobby projects it is OK. If I want to deploy a commercial project then can I still generate an AppEUI randomly or should I buy it from certain standard regulatory body just like device manufacturers do it in the case of DevEUI.
For a particular application (having an unique application Id in the network server), once the AppEUI is generated, should all the devices which will get registered in that application in the future have the same AppEUI? Can the AppEUI for 2 different end node devices under the same application be different. I mean while provisioning the end node devices with AppEUI and AppKey, can I provision 2 different end node devices, registered under the same application, with 2 different AppEUI’s ? In case of TTN I do not need to do that as TTN gives me the same AppEUI for any number of devices registered under a particular application. But the network server provided by my gateway manufacturer allows me to provision the 2 different end node devices, registered under the same application, with 2 different AppEUI’s. Is this correct behavior?
Thank you Arjanvanb for the valuable answer. Sorry for my delayed response.
I was thinking that all devices created under an application should have same AppEUI. But what is the significance of AppEUI. DevEUI is similar to MAC address of the end device. AppKey is the shared secret. What is the significance of AppEUI. I was thinking that AppEUI is the global identity of any lorawan application and so all devices created under an application should have same AppEUI. But turned out that my understanding in not correct. Could you please tell me the significance of AppEUI.
Another doubt I have is that in LoRaWAN class A device mode, there are 2 RX windows which follows the TX window after 1 and 2 seconds respectively. If the end node after transmission waits for 1 sec and opens its RX window and successfully receives the downlink packet, it will no more open the 2nd RX window and go back to sleep. But will the network server again re-transmit the downlink packet for the RX2(receive window 2) timeslot? Because the network server has no idea whether the end node successfully received the downlink packet or not. So, will the network server re-transmit the downlink packet for RX2 window to ensure that end device gets it in case it failed to receive it in RX1 receive window. Please help me with your valuable advise.
AppKey is shared as in shared between node and application, not between nodes. The AppEUI identifies the application and is usually the same for all nodes that belong to that application.
No, the gateway transmits just once, if the node did not receive downlink transmitted in RX1 it will not get the data.
Thank you for the valuable answer.
Actually as per my understanding, the gateway never transmits anything from its own. It is the network server which transmits via the gateway. But as you said that if end node cannot receive in RX1 then it will not receive the downlink packet. Then what is the purpose of keeping RX2?
Even my understanding was also the same that all nodes coming under one application share the same AppEUI. But TTN and other network server providers allow for different AppEUI configuration even for nodes which are coming under the same application. Do you know why?
That remark was provided in the context of your message where you asked if a gateway would send the data again in RX2. RX2 is useful as it allows the back-end a choice of slots to answer in.
And you are right, the gateway does not transmit anything on its own. A gateway currently is just a RF to IP and IP to RF translator where when sending the back-end determines transmission time, speed and frequency for the transmission. If the gateway can not send at that time (due to for instance an LBT conflict) the transmission will be dumped and the node will not receive anything. Even when transmitted there is no guarantee the node will receive the transmission.
That is the only way to handle hardware which has been programmed by a manufacturer with OTAA ‘credentials’. Not all devices provide an interface to allow programming your own AppEUI and AppKey.
