TTN V2 to V3 migration

[jpmeijers]

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.

[pe1mew (Remko)]

Here is a visualization of the consequences of migrating gateways from V2 to V3:

(to enlarge the images: right-click | open image in new tab)

[johan (Johan Stokking)]

Thanks @pe1mew, that’s a correct illustration.

For those interested, the reason why we do not route traffic from Packet Broker to The Things Network V2, is all of the below:

1. 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 [1] cannot be made that fast. This is why we increased the default RX1 delay in The Things Network V3 to 5 seconds

2. 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

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

   1. 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
   2. 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

[1] 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.

[Jeff-UK]

Thanks for the clear and transparent explaination Johan. I think even I can (start) to understand (some) of this!

[steinamo]

@jpmeijers Do you know when will it be possible to register v3 devices in the Apple TTN mapper app?

[kersing (Jac Kersing)]

@jezd

was told to use browser only in another thread.

Browser won’t work for TTNmapper if you have a simple (no gps) node.

[jezd (JD)]

you right, ignore my post completely - I misread

[GVZLora]

@jpmeijers

until as late as possible.

What is the final date? for migration to V3.

[kersing (Jac Kersing)]

@GVZLora

What is the final date? for migration to V3.

No hard dates have been set yet. From the timelines mentioned during the conference think Q3.

[whisky_jb (Jörg Bieri)]

I’m new to TTN, so I got my first gateway running and obviously I started directly with V3 to skip an upcoming migration. Is that OK or is it better to still register in V2?

[GryKyo]

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?

G

[whisky_jb (Jörg Bieri)]

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

[pativar]

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?

{
  "code": 6,
  "message": "error:pkg/identityserver/store:id_taken (ID already taken)",
  "details": [
    {
      "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
      "namespace": "pkg/identityserver/store",
      "name": "id_taken",
      "message_format": "ID already taken",
      "correlation_id": "xxx",
      "code": 6
    }
  ],
  "request_details": {
    "url": "/users/xxx/gateways",
    "method": "post",
    "stack_component": "is"
  }
}

[descartes (Nick McCloud)]

That’s not what the error message says, it says the ID is already taken.

It doesn’t say the DevEUI is taken.

Also:

How do I format my forum post? [HowTo]

The TTN forum is using Discourse, which supports several ways to format your post: Markdown BBCode HTML Any combination of the above Quite often you’ll need an empty line above specific formatting to make it work. You’ll also have to type blank lines to create proper paragraphs; just pressing Return once and then typing a new block of text right below a previous block only creates a so-called line break, which might be harder to read. Leaving one blank line between two blocks of texts nicely…

[trlafleur]

I deleted my device from ver2, then added it to ver3, get this message… any idea on how to fix it??

duplicate_identifiers

{
  "code": 6,
  "message": "error:pkg/networkserver/redis:duplicate_identifiers (duplicate identifiers)",
  "details": [
    {
      "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
      "namespace": "pkg/networkserver/redis",
      "name": "duplicate_identifiers",
      "message_format": "duplicate identifiers",
      "correlation_id": "827238d53a7f436c8ce873d697d30837",
      "code": 6
    }
  ],
  "request_details": {
    "url": "/ns/applications/rsf1-otaa/devices/ws4a-6c-b0",
    "method": "put",
    "stack_component": "ns"
  }
}

[descartes (Nick McCloud)]

As I said above, duplicate identifiers - or possibly using a reserved word.

Have you used the Id before (note, NOT the EUI)

What is the Id you have used?

[trlafleur]

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
class A

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…

[descartes (Nick McCloud)]

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.

@trlafleur

V3 is not ready for prime time if there is no way to fix this type of issue

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?