...
Major version update: Please note that this is a major version update where downtime is expected. Zero downtime is difficult to achieve and it depends on how often the devices transmit/rejoin and the level of access to the gateways.
Migrate devices with new session on V3: In order to guarantee proper functioning of migrated devices, they will need to rejoin after migrating to V3. It is not advised to migrate the device session data, because when the session is retained, we can't guarantee the maintainability of the active session and if downlinks will reach the devices. Devices imported from V2 are configured with an Rx1Delay of 1 second, by default. In The Things Stack we recommend using an Rx1Delay of 5 seconds to accommodate for high latency backhauls and/or peering with Packet Broker.
Multi-cluster deployment: In V2, deployment is in the closest geographical region. The Things Stack Cloud is a multi-cluster deployment. This means that while your account information is stored in a central location, you can connect your gateways to a closer cluster, and route all your IoT traffic in that cluster. This can significantly reduce latency. Hence, we recommend you to consider migrating your devices and gateways to appropriate clusters. The Things Stack Cloud currently has clusters in Ireland, Sydney and North California. Ref: https://www.thethingsindustries.com/docs/getting-started/cloud-hosted/
Peering between V2 and V3:
Eventually, all the gateways are to be migrated to V3. But, if you need more time to migrate your gateways due to lack of remote access or manual access, we can enable peering between your V2 instance and your The Things Stack Cloud V3 tenant, so that the traffic from your devices reach V3 while the gateways are still pointing to V2. It gives you more time to migrate your gateways gradually. Please note that V2 deployment is based on geographical region and so the frequency plan is tied to that region. If your installed base use gateways operating in multiple frequency plans, then peering can be enabled for only one frequency plan. The gateways on other frequencies should be migrated to route traffic to V3.
Please list the behaviour of your devices and accessibility of the gateways based on the cluster and site and send us the these details over email/support ticket to support@thethingsindustries.com so that we can further comment on your migration path.
Devices:
...
Cluster
...
Site No./ Site ID
...
Total no. of devices
...
No. of devices that can rejoin
...
Join policy of the devices
...
No. of devices that can’t rejoin or with any specific remarks
...
(Sample entry)
EU
...
Site 1
...
50
...
50
...
Send Linkcheck after 5 uplinks and initiate join if needed
...
-
...
(Sample entry)
EU
...
Site 2
...
100
...
90
...
Automatic rejoin every week or after every 20 uplinks
...
10 devices rejoin only on low-power trigger
...
(Sample entry)
US
...
Site 1
...
20
...
15
...
Send Linkcheck every hour and initiate join if needed
...
Automatic joins are disabled for 5 devices
Gateways:
...
Location/Frequency Plan
...
Site No./ Site ID
...
Total no. of gateways
...
No. of Gateways with remote or physical access
...
No. of Gateways with neither remote access nor physical access
...
(Sample entry)
EU
...
Site 1
...
3
...
3
...
0
...
(Sample entry)
US
...
Site 2
...
4
...
3
...
For support in the process, please file a ticket in our Support Portal or mail us atsupport@thethingsindustries.com