Hi,
When buying a commercial node, how can you register it on a network ?
I understand the keys (DEVEUI, Apsskey and Appeui) must match the server side.
Does a device manufacturer needs to label his device with these 3 keys ? Or is just the DEVEUI sufficient ?
How do the remaining keys match ?
Thanks!
The device should use OTAA (a hardcoded ABP DevAddr is not supported).
For OTAA, each LoRaWAN 1.0.x device needs an Application Identifier (AppEUI), Device Identifier (DevEUI) and secret Application Key (AppKey; not the secret application session key, AppSKey). With TTN, all these can be set to any value using TTN Console:
In the application settings:
Each application can have multiple values for AppEUI.
In the device settings:
To use a LoRaWAN 1.1.x device on a 1.0.x network:
(LoRaWAN 1.1 uses the new NwkKey for the OTAA join. If the OTAA Join Accept indicates it’s connected to a LoRaWAN 1.0.x server, then the device will fall back to 1.0.x.)
To enter a value rather than having one generated, click the pencil icon to allow for manual input:
The makers of the device need to provide a user friendly way to configure the device without having to access the code or special tools to set it up. I’ve been developing a number of devices that use a bluetooth module to enable them to be configured quickly with integration to the LoRaWAN network. Other alternatives would be NFC but as with any of these solutions, they need to be secure.
Thanks
Andrew
Note that maybe support for ABP is a requirement for certification:
More information from the lora-alliance.org website that supports my vague statement that ABP is a requirement for getting a certified product.
First this image from (https://www.lora-alliance.org/certification-overview):
And then looking further into any Test House Report from any product from https://www.lora-alliance.org/certified-products you will see one test:
Test Mode Activation (Activation by Personalization): PASS
Which seems that all test must be passed before any certification is issued. There could be some hidden way under “LoRa Alliance can be consulted for dispute resolution” which takes you directly somewhere to the chain which eventually leads you to the “END”. Skipping the “All tests pass”, we are not sure if it works this way or not, would be great if some expert could clear this up.
It is also somehow strange since the networks certification seems to say that a public network which got an own NetID doesn’t need to support NetID 0x00 which is for experimentation (or any other than their assigned one for that matter) . Which would lead to the strange scenario where device manufacturer MUST support ABP while network operators are not obligated to support these devices. And the device manufacturer must, therefore, build devices which are looked into some network, or rather, locked out of some networks for the above method.
Today I was surprised to have a node without APP_EUI, So to test, I registered the node with my local back end and it works (by back end does not has the APP_EUI field mandatory). How can that be possible? How backend manage this? That’s strange but it works, may be device has a DevEui I do not see or set to 0?
the device joined, and has nwskey and appskey.
As for uniqueness:
Hylke wrote on Slack:
@htdvisser [Jan 11th 2019 4:24 PM]
We use the AppEUI+DevEUI combination as identifier for a device, so as long as you use different AppEUIs for devices with the same DevEUI, you should be fine for now (but you may encounter problems in v3 if you would use LoRaWAN 1.1 ReJoinRequests)
Things might be different for other networks, so I’d just make sure the AppEUI and DevEUI are unique (and comply to the rules of an EUI-64, so are either purchased or crafted using specific rules). The secret AppKey can be any secure random value.