Packet Broker currently routes traffic from gateways connected to The Things Network V2 to V3. That is, gateway coverage of V2 is available in V3. But not the other way around : gateways already connected directly to V3 will not be available for applications in V2.
As a friendly request, both as a user of TTN and as the maintainer of TTN Mapper, please keep your gateways on TTNv2, until as late as possible.
People in your city that have not yet migrated their application from v2 to v3 will lose connectivity if you migrate your gateway.
TTN Mapper does not currently map gateways connected via the Packet Broker. This is a work in progress. To keep your coverage on the map, please leave your gateways registered on V2 for now.
For those interested, the reason why we do not route traffic from Packet Broker to The Things Network V2, is all of the below:
The Things Network V2 has an RX1 delay of 1 second. This means that a downlink message needs to be ready for transmission by the gateway 1 or 2 seconds after the uplink was received. The whole roundtrip  cannot be made that fast. This is why we increased the default RX1 delay in The Things Network V3 to 5 seconds
V2 has its own mechanism to route traffic from one region to the other, known as cross-region peering. This is what Packet Broker does in V3. It is not reliable to keep both V2 cross region-peering and Packet Broker in place. We can also not reliably bypass V2 cross region-peering for incoming traffic, so we don’t support any incoming traffic that is outside of V2
Slightly related: we recommend against migrating the device session from V2 to V3, and we want to add a barrier for this by not routing data back to V2. There is a lot of traffic in the DevAddr blocks that are allocated to TTN V2. For TTN V3, we have fresh new DevAddr blocks (eu1 has 260B0000/16). If Packet Broker would be routing all traffic from TTN V2 DevAddr also to TTN V3 (or, from V3 to V2, what this topic is about), we get two new problems:
We cannot guarantee that the device session is only in TTN V3. So it could be that the same message ends up and gets handled by both V2 and V3 concurrently, leading to MAC state corruption and conflicting downlinks, and effectively disconnecting the device
We would be sending all the 600 messages per second to TTN V3. Now that is certainly possible in terms of performance, it comes with a serious cost (€€€ + ops time) of network capacity and it makes logging and tracing really hard, while we want to start with a clean slate and gradually grow TTN V3
 the roundtrip would be: gateway → TTN V3 Gateway Server → TTN V3 Packet Broker Agent → Packet Broker Data Plane → Packet Broker Router → Packet Broker Data Plane → TTN V2 Packet Broker Agent → TTN V2 Broker → TTN V2 Handler → TTN V2 Broker → TTN V2 Packet Broker Agent → Packet Broker Data Plane → Packet Broker Router → Packet Broker Data Plane → TTN V3 Packet Broker Agent → TTN V3 Gateway Server → gateway. You can imagine that it this only works in ideal circumstances, on one continent only, with very low latency gateway backhauls etc etc, i.e. there are so many things that break the downlink flow, that we decided not to support it in the first place, to avoid “why does it work for them but not for me” questions here that need significant troubleshooting effort.
If I understand correctly all your V3 applications will work just fine on your V3 gateway. I understand that if there is an existing community using V2 applications these packets will not be routed on the V3 (your gateway!) network at all. Maybe Jac or Johan could confirm.
The only instance this gateway migration will be a nuisance for me personally is the frame counter of an experimental application/node running over 31 months on a single LiFePO4 cell polling a BMP280 every fifteen minutes. Ideally I would like to see this device run for several more years but looking like there is an impending end to that experiment if I migrate my gateway?
yes, meanwhile I have a first temperature sensor running and also I receive the data in TTN V3. Next will to setup a proper application which stores the data, but that can wait some moe weeks. As far as I understood, V2 will be gone sooner or later, so probably your experiment will be g
I am trying to migrate my gateways from TTN v2 to V3.
Instructions at Adding Gateways | The Things Stack for LoRaWAN say I should add the gateway in TTS. However, this fails because the EUI is already being used (which it is, by me in my TTNv2!). Is this documentation correct or what is the correct procedure?
the device DEVEUI is hard coded in the device, can’t change
end device name, I have changed many times, same error
the end dev id, I have changed many times, same error
APPEUI is common to all my devices
APPKEYS is common to all my devices…
freq plan is USA TTN-2
so for some reason my DEVEUI must be in never-never land in the V3 database, locking this device out
the error message is very vague, “duplicate identifiers” not stating what identifier(s) is the issue…
V3 is not ready for prime time if there is no way to fix this type of issue…
so I’m at a loss here on how to move this device to V3…
The Id of the device is the part YOU enter that’s up to you. As I said above, it is NOT the EUI of anything.
An id like descartes-amazing-device-01.
It’s in the field marked End device ID
This does not allow certain obvious words or phrases like, for instance device.
The DevEUI should be unique - so may be if you look past that you are focused on the wrong field, if someone accidentally registers your DevEUI in the database before you, that’s not the fault of the database. How do you propose it handle it differently?