Can I register an ABP device that has fixed DevAddr, NwkSKey and AppSKey?

[arjanvanb (Arjan)]

@arjanvanb

network providers (such as TTN) are required to actively block devices that always send on SF11 or SF12, to keep their LoRa Alliance NetID: Devices with fixed hardcoded data rates of SF12 or SF11 must not be allowed to join the network.

As for currently enforcing this, @htdvisser wrote on Slack July 3rd:

But no, we’re indeed not enforcing it at the moment
It’s pretty difficult to detect (with certainty) that a device is hardcoded to SF11/SF12
Sure, we can “assume” it if a device with a good signal is transmitting on SF12
But in my opinion, we should first notify the owner before we start blocking a device
And we’re still working on this notification system

[sronan]

@arjanvanb

It’s not possible to register just any DevAdr, as it includes a network identifier

The TouchTag has a fixed DevAddr that starts with 16. When I register it and personalize it via ttnctl according to the console it is given a DevAddr that starts with 26. Whether or not I change that via ttnctl, the gateway traffic only shows transmissions from the DevAddr 16xxxxxx and in neither case does traffic show at the application level.

Does it seem possible that TTN would in the future accept traffic for a device with a fixed DevAddr that starts with 16? Would that require some kind of peering agreement? My guess would be that sensors with a fixed DevAddr would be cheaper to manufacture than ones where the user can alter the DevAddr. And for devices with a fixed DevAddr to need to be specifically manufactured for use only in a particular network would seem regrettably inefficient. But I may have a fundamental misunderstanding of the issue.

[arjanvanb (Arjan)]

@sronan

Does it seem possible that TTN would in the future accept traffic for a device with a fixed DevAddr that starts with 16?

Even it would do peering/roaming, you’d then need to register it with EveryNet in Russia.

[kersing (Jac Kersing)]

@sronan

Does it seem possible that TTN would in the future accept traffic for a device with a fixed DevAddr that starts with 16?

If the devaddr is fixed the node uses ABP (not the preferred activation mode), with OTAA the customer would be able to create an application with the (unique) id, register the nodes EUI and key and be in business.

[mhruska]

@Verkehrsrot

@Verkehrsrot

Is there somewhere a list of assignments NetID <-> LoRaWAN Network Provider?

https://www.thethingsnetwork.org/docs/lorawan/address-space.html

[jpmeijers]

@htdvisser

ttnctl devices set my-device-id --override --dev-addr 00000000 --nwk-s-key 00000000000000000000000000000000 --app-s-key 00000000000000000000000000000000

Thanks! This is useful when migrating a device from TTN to a TTI instance or back.

[shahrulazwan]

Hi… I have similar problem with my sensor. The sensor that I have already with a prefix DeviceAddress (Address: B00XXXXXX), Application Session Key and Network Session Key. According to the manufacturer, the sensor is configured with ABP.

When I added the sensor to TTN using TTNCLI and force change the Device Address to the sensor Device Address, I couldn’t get the publish in TTN. The instruction that I used to change the Device Address

ttnctl devices set [device_id] --dev-addr [sensor_device_address] --handler-id ttn-handler-asia-se

As i’m using Asia server, I need to put the --handler-id, else there will be error in the process.

Is there any solution for this?

[arjanvanb (Arjan)]

@shahrulazwan

Is there any solution for this?

A DevAdrr that starts with B00 will never work with TTN, see the explanation above. You’ll need to reprogram the device to use the TTN-assigned DevAddr for ABP. Or make it use OTAA and configure TTN and the device to use the same values for DevEUI, AppEUI and AppKey.

[shahrulazwan]

Hi… Thank you for the feedback. Although the data is available in the gateway traffic, application level, the data can’t be shown in the application due to the network identifier?

[arjanvanb (Arjan)]

Sorry, I don’t know how to explain better than already quoted from the documentation above:

@arjanvanb

Within TTN, we assign device address prefixes to “regions” (for example, device addresses in the eu region start with 0x2601).

…and as already quoted from Slack:

@arjanvanb

We route data based on the NetID that was assigned to us by the LoRa Alliance

Devices with a DevAddr that does not match our NetID, are (according to the LoRaWAN spec) part of another network

If you don’t believe it, then click on an item in the gateway traffic, to see that (in your case) TTN will not recognize this as traffic it needs to handle. For example, for a DevAddr starting with 14:

…and the “drop” along with the reason “no brokers” in:

[kersing (Jac Kersing)]

@shahrulazwan

the data can’t be shown in the application due to the network identifier

The data can not be forwarded to any application because the address is not valid for TTN.

[shahrulazwan]

Thank you for the feedback @arjanvanb an @kersing