It’s not possible to register just any DevAdr, as it includes a network identifier:
The most significant 7 bits are used as network identifier (NwkID) to separate addresses of territorially overlapping networks of different network operators and to remedy roaming issues. The least significant 25 bits, the network address (NwkAddr) of the end-device, can be arbitrarily assigned by the network manager.
[…]
The seven LSB of the NetID are called NwkID and match the seven MSB of the short address of an end-device as described before.
The documentation on Addressing and Activation explains some more:
The Things Network Foundation has received a 7-bit device address prefix from the LoRa Alliance. This means that all TTN device addresses will start with 0x26 or 0x27 (although addresses that start with these might also belong to other networks with the same prefix).
(TTN currently uses a NetID of 0x000013, hence its NwkID is the 7 bits binary %0010011. As hexadecimal 0x26 is binary %00100110, and 0x27 is %00100111, both indeed start with the 7 bits NwkID.)
Also, the TTN-assigned DevAddr uses some more encoding for internal routing. From the same documentation:
Within TTN, we assign device address prefixes to “regions” (for example, device addresses in the eu region start with 0x2601). Within a region, the NetworkServer is responsible for assigning device addresses. We are using prefixes here too for different device classes (for example, ABP devices in the eu region start with 0x26011) or to shard devices over different servers.
(This indeed yields less than 12 bits within a region and class to generate a DevAddr, yielding only 4,096 unique values within such region and class. This is not a problem as a DevAddr is not unique.)
@htdvisser wrote in Slack, about just copying some existing DevAdr into TTN Console:
No, that won’t be possible in the public network
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 a manufacturer puts fixed DevAddr/NwkSKey/AppSKey in a device without giving the customer the ability to change those, they either don’t know what they’re doing or they don’t really care about the customer or they try to create some kind of lock-in to their own network.
And if if the NwkSKey/AppSKey is 2B7E151628AED2A6ABF7158809CF4F3C I would think twice before buying the device.
And about the test NetID 01/02:
We don’t issue DevAddresses for 00 / 01 but it is possible to “force-register” a device with such address (not in the console, only with ttnctl)
For such devices, we can still route data
But uplink for anything else than 00 / 01 / 26 / 27 will just be dropped before it’s even considered by the backend
Or routed to a roaming partner when roaming is added to LoRaWAN and supported by us
