So far, I very much felt that off-the-shelf 1.0.x devices should have a unique AppEUI (and DevEUI) for each device. Quoting myself:
In real life, at least on TTN things seem to work if a non-unique AppEUI is shared among multiple devices, registered by different users. (Also a single TTN user can use the same AppEUI in multiple applications in TTN Console, at least in V2.) Again quoting myself, while I was quoting myself:
So it seems at least TTN V2 can handle sharing an AppEUI (though someone reported that programming a new, unique AppEUI fixed their problems). And we’ve seen quite a few devices use a single or non-registered AppEUI. (Like Dragino LHT65 and LGT92, RadioBridge, Nke Watteco, Axioma Qalcosonic, …?)
But if things work, then why did the LoRaWAN specifications even bother about defining the AppEUI? Surely the network servers could have used just the DevEUI and MIC to find the right configuration. This makes me feel that things work because of implementation choices, despite the devices not being compliant.
thats a thought I stumbled upon when recently purchasing 10 Elsys CO2 sensors. They all have the same AppEUI 0000000000000000.
In LoRaWAN 1.1, I totally understand the use of AppEUI (renamed to JoinEUI): It identifies the Join Server keeping the root keys for this device.
In LoRaWAN 1.0.x however, I do not really get the initial usage for AppEUI as there is no Join Server yet. It also is not used in key generation:
So, from my current knowlegde (which might change), I see no reason why non-unique AppEUIs should be a problem. However, it feels somehow wrong to me to register 10 devices with the same AppEUI
The specification says “AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the entity able to process the JoinReq frame”.
You write “In this case: unique per application” which is an understandable but incorrect assumption.
The specification explicitly says the entity able to process the JoinReq frame and not application.
The specification also says “the entity” and this is where I think the specification is not precise enough because (based on current implementation) this probably should read “an entity”.In which case multiple applications can serve as an ‘the entity able to process the JoinReq frame’.
Off-the-shelf devices must be able to be used right out of the box without having a user to configure any keys on the device first. To make this possible they must be pre-configured with DeviceEUI, AppKey and AppEUI (all three of them).
DeviceEUI and AppKey are end device specific (properties of the end device).
AppEUI is a property of an entity/application that can handle the join request for this device, but only if the end device is registered for that application and an end device can only be registered to a single application.
From the perspective that a(n off-the-shelf) device must be able to be registered to any application (but only one at a time) it makes sense that any application can be enabled to handle a join request of that device by adding the AppEUI (configured in the device) to that application.
The device must be registered for an application to be able to join, but technically this does not require the AppEUI to be unique for that application and hence an AppEUI can be shared by different applications (possibly even by applications from different accounts).
Giving each device their own unique AppEUI as some suggest would not be useful and not be logical. The device is already uniquely identified by its DevEUI. The devices of an application can all share the same AppEUI (unless they come hard/pre-configured with different AppEUI’s). This is exactly the same as when an application only has a single (its default) AppEUI which is then automatically used during device registration (when the user does not explicitly enter an AppEUI) and the user then configures that AppEUI on the end device(s).
Why do you mention MIC here? Did you mean DevEUI and AppKey instead?
In which case only DevEUI and AppKey would have to be specified when registering a device, without needing to bind it to an AppEUI (that must have been added to the application in advance)?
“why did the LoRaWAN specifications even bother about defining the AppEUI?”
Possibly with future extensions in mind (e.g. Join Server like)?
Or maybe speedup the handling of join requests?
Can it be related to that NetworkSKey and AppSkey are not yet known during the join request?
The application name appears to be the primary key of applications.
This explains why two different user accounts cannot use identical application names.
It also explains why applications can share AppEUI’s, because it is not their primary key.
The name AppEUI which is usually referred to as ‘Application ID’ gives a wrong impression and puts us on the wrong foot because AppEUI is not the unique primary key of an application.
This is probably (one of) the reason(s) why it was renamed to JoinEUI in later versions of the spec.
(In database design it’s bad practice to use name as primary key. This is probably a V2 design flaw).
Sure, we already established it seems a unique AppEUI is not needed with TTN, at least not with V2. But: that may be considered an implementation detail? Do things still work when registering a 1.0.x device on V3? Or when using another network? Or when networks start peering?
(Aside: just peeking in the code, it seems things also work when running one’s own handler in V2. In that case TTN does not know the device’s AppKey, but TTN simply delegates an OTAA Join Request to all handlers. It also seems devices should then still be registered with TTN itself, as TTN seems to expect to find it using the AppEUI and DevEUI. At that point it seems it even already knows the TTN App ID, and as handlers announce the App IDs they know, TTN may only need to delegate to a few handlers. I’ve not truly investigated, but that looks solid and I’d assume it works. For TTN V2.)
The AppKey is not in an OTAA Join Request. But indeed, the AppKey is used to validate the MIC of an OTAA Join Request, so they’re interchangeable in this context.
Aside: this AppEUI has not even been registered by Elsys. It almost looks like they forgot to provision the devices…
When you introduce a new JoinEUI, use the manufacturer’s OUI for the first bytes of the JoinEUI. Consider separate JoinEUIs per frequency band or per brand. There is no problem having multiple JoinEUIs point to the same join server. Do not create a unique JoinEUI per device and do not use a random sequence. If an OUI is not available, use all zeros to indicate that a join server is not available. The intention is to consolidate devices.
Too bad I cannot find any mention of off-the-shelf devices anywhere in the developer portals. I wonder if the above applies to such devices, considering the LoRaWAN Backend Interfaces 1.0 Specification, emphasis mine:
Join Server:
The Join Server (JS) manages the Over-the-Air (OTA) End-Device activation process. There may be several JSs connected to a NS, and a JS may connect to several NSs.
The End-Device signals which JS should be interrogated through the JoinEUI field of the Join-request message. Each JS is identified by a unique JoinEUI value. Note that AppEUI field of the Join-request in LoRaWAN 1.0/1.0.2 [LW10, LW102] is renamed to JoinEUI field in LoRaWAN 1.1 [LW11]. The term JoinEUI is used to refer to the AppEUI in the context of LoRaWAN 1.0/1.0.2 End-Devices in this specification.
