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:
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.
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?
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.
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.