TTN V2 to The Things Stack V3 Transition

V2 to V3 Upgrade
#1

This topic created to focuss discussions around practicalities and issues arising from pending TTN V2 to TTN V3 migration, and associated V2 Sunset 2H’21

*Note TTN V2 Gateways currently forward to TTN V3 with no issues (*though you may see some GW metadata is stripped/annonymized, potentially affecting some Applications or use cases - YMMV - e.g. TTN Mapper has a know problem with V3) through PacketBroker, however, new GW’s directly connected to V3 WILL NOT forward data ‘backwards’ to V2 Applications. In addition if you migrate a V2 installed GW to V3 this too will stop forwarding to V2 applications.

Bottom line Users & Community Members need to plan and schedule their migrations carefully to avoid local disruptions and apparent ‘loss of service’ for older applications, etc.

Per @johan on the TTConf’21 chat this morning (20210126)

V2 gateways are fully connected to V3, for uplink, downlink and activations.However, gateways that are connected directly to V3 (new or migrated gateways) will not route data back to the legacy V2 environment

(*) updated to add comment

Let the discussion begin :slight_smile: :-

2 Likes
Things you should know before Moving your gateway from V2->V3
TTN V2 to V3 migration - Migrate your gateways last!
TTN V3 questions
TTN to TTI routing
About the V2 to V3 Upgrade category
Integration myDevices(Cayenne) missing in v3?
#2

Most important message:

Don’t Panic

We all need to be pro-active but no one is trying to “break” TTN - if there are some real show stoppers that will totally break your system, then says so and we can find a way.

To underline @Jeff-UK’s message, your V2 will carry on working for a while, new deployments of devices of an existing application will need to plan to be on V3 when V2 goes read-only This means you will need to join the two integration sources together. We can all help each other with this.

Please do not post your specific use case or issue here, create a new topic, let’s keep this thread a generic discussion.

1 Like
#3

If I recall correctly @johan wrote in chat that

“V2 GWs are fully connected to V3, for UL, DL and activations. However, GWs that are directly connected to V3 (new or migrated) will not route back to the legacy V2 environment”

So, I believe that a make-before-break approach would dictate to first move your applications to V3 and then migrate your GW to V3. Is this assumption correct?

#4

Note: This message was moved here from another thread.

As understood in the TTN conference there are some things you need to know and arrange before you consider moving the gateway from V2 to V3. You may break things :slight_smile:

So, summarizing :

  • V3 gateways do NOT forward traffic to V2 applications.
  • V2 gateways forward traffic to V3 applications.
  • Moving gateways to V3 means there won’t be traffic to V2 applications from those gateways
  • Move your applications to V3 and only when all applications (including those of the community members in your region) are on V3 move the gateway(s) as well.

HT @kersing @johan @pe1mew for clarifying.

What more should you consider or definitely not do?

1 Like
#5

Note: This message was moved here from another thread.

Since we started this entire journey, it has been our goal to create a worldwide LoRaWAN ecosystem. We’ve done this with our public community network, but we also wanted to do this for other public and private networks. That’s why last year we announced Packet Broker.

With Packet Broker, different networks (but also clusters within the same network) can exchange traffic with one another. We call this peering. In this peering relationship, there are two sides:

  • The Forwarder: Sends uplinks to Packet Broker, receives downlinks from Packet Broker
    • this is basically the gateway side
  • The Home Network: Receives uplinks from Packet Broker, sends downlinks to Packet Broker
    • this is basically the application side

The Things Stack (v3) can be both a Forwarder and Home Network (at the same time), while our V2 implementation is only a Forwarder. This means that two v3 clusters can have bidirectional peering, while a v2 cluster can only be the “gateway side”.

For the next couple of months it gets a bit confusing, since The Things Network now has both v2 clusters and v3 clusters. Between the different v2 clusters, there is full bidirectional traffic exchange (although that has always been a bit flaky). Between the different v3 clusters, there is full bidirectional peering through Packet Broker. You can have your gateways on v2 and your applications on v3. But you can not have your applications on v2 if your gateways are on v3.

6 Likes
The Things Network upgrade to V3
TTN to TTI routing
#6
#7

One possible problem is V2 Application support will stagnate/wither on the vine as new V3 GW’s deploy they wont help coverage for V2 applications, and existing V2 GWs that get migrate to V3 will stop servicing V2 devices/applications - even if they historically did so. Coverage for V2 devices/apps will therefore decline and already deployed devices will in many cases stop working!.

Message appears therefore to be deploy no new V2 devices or apps… the network has just been Osborned! :frowning:

Or am I reading this wrong? :sunglasses:

#8

My recommendations would be:

  • Always use OTAA, that’s going to make any migration a lot easier
  • Register new applications and end devices on v3
  • Migrate old applications and end devices to v3
  • Discuss with your local community when it’s no longer needed to keep your gateways on v2, and then flip the switch
  • Upgrade your gateways to the Basic Station forwarder while you’re at it
3 Likes
#9

I posted some generic information here: The Things Network upgrade to V3

Let’s discuss the migration from V2 to V3 here.

I understand the potential coverage issue that may occur when migrating gateways now from V2 to V3.

What is highly advised is to migrate devices as soon as possible to V3. Gateway coverage is already there. We support all application level integrations as we do in V2, including storage API, MQTT and webhooks.

See Migrating from The Things Network Stack V2 | The Things Stack for LoRaWAN. When you migrate, you can convert your V2 devices to ABP devices, i.e. remove the AppKey, so the end device will not join on V2 anymore.

Then, if your device has a mechanism to detect link loss (missed acks, missed ADR acks, link check misses etc), it will revert to join mode and join automatically on V3.

So the order would be:

  1. Create applications now on V3 and adapt your application to the new payload formats etc. Few changes, but all minor
  2. Migrate devices now from V2 to V3 and convert them to ABP in V2: Migrating from The Things Network Stack V2 | The Things Stack for LoRaWAN
  3. Follow @htdvisser’s steps mentioned above
2 Likes
#10

What about V2 devices without OTAA? Nearly all of my devices and many more here in the Community are only based on ABP and not OTAA.

#11

See https://www.thethingsnetwork.org/forum/t/the-things-network-upgrade-to-v3/43256:

  • Activation by personalization (ABP) devices, i.e. devices that have a fixed DevAddr and session keys, are personalized for a specific network, in this case, The Things Network V2. You should consider V3 as a new network. So if you want to keep using ABP and you cannot use over-the-air activation (OTAA), it is highly recommended to create a new ABP device in V3 and reconfigure the device with the new session. Note that the (default) RX1 delay has changed from 1 to 5 seconds.
2 Likes
#12

Ok so during the conf a user opens his/her TTN Console page (the current ‘public’ face & most used start point for users?), goes to Applications - add new application - will that automatically be in V3 now or will it still be V2?

We need this to be V3 ASAP if we are not to then orphan devices & apps starting now (that also create a big workload revisiting apps and devices to migrate). Going OTAA ok - but if devices dont restart (for a long time - given one feature called out for devices on LoRa is long battery life :wink: ) then they will likely be abandoned if not economic to make field visits to ‘fix’…

#13

V3 is available now, but the default Console is still V2 indeed. We need to put a banner there. Also we need to show the cluster overview on thethingsnetwork.org so that it is clear what the host names are and where to go. There’s still quite some work to do on our side.

As said in the keynote, V2 will become readonly from April. So from then, it will not be possible anymore to add new applications and gateways. By then, we should have the right navigation and user experience in place to make sure that people go to the right place. That also means that by then, we need to have nam1 and au1 deployed, and potentially one is Asia Pacific too.

1 Like
#14

Thanks for clarifying/confirming Johan. Looks like its the apps/devices that is the killer for now given existing V2->V3 routing for GW’s already seem sorted (with packetbroker :slight_smile: ) I will hold new device/app deployment for a few days/weeks where I can whilst matters settle and use as excuse to force myself to look deeper into V3 :wink: (was hoping that migration would be a ~Q2 task but given April timing that accelerates matters from last Mods heads up!).

Please do amend Console Apps page to forewarn users with a Use V3 Banner ASAP as I can see much nashing of teeth ahead! :wink:

1 Like
#15

Regarding Packer Broker peering:
I understand that TTN gateways (V2 and V3) are already sending traffic to TTI devices.
Are also TTI gateways routing traffic to TTN V3 devices?

#16

Hello, what is the workaround on eu1.cloud.thethings.network for a blank screen after login? I have tried changing my password and used Chrome on Windows and FF on Ubuntu, with standard security settings.

btw: I don’t get a blank screen (on oauth url) with our private instance of V3, login works as expected.

Thanks Mike.

1 Like
#17

We’re working on this!

That depends on the customer. Some do, some don’t. The basic rule is that there needs to be some balance; we don’t want leeching. For now, we show them the benefit of TTN coverage, and tell them that it doesn’t cost anything to allow offload (uplink) traffic back to TTN. Now, whether downlink will be supported is another issue. We support downlink prioritization in V3, so private TTI networks may support downlink but only if they have capacity left. We’ll see!

We are working on a fix that will be deployed shortly. cc @bafonins

4 Likes
#18

I’m currently writing a number of scripts utilizing the Application Management API. Should I wait and see, or can I rely on V2/V3 compatibility?

#19

How should we move “The Things Indoor Gateways” from V2 to V3?
The FAQ from the Gateway say:

Q. I want to delete and re-create (re-register) TTIG. Can I do that?

This is definitely not recommended since you cannot recreate a gateway with the same EUI on the same network. We do this to prevent violation of uniqueness on the EUI.

#20

Do not delete at this time. Looks like no rush to migrate such GW’s yet as the data is being forwarded through to V3 infrastructure back end already :slight_smile: Another good thing to do at time of migration is upgrade GW’s to using BasicStation - but the TTIG is already running that so no immediate imperative…

1 Like