The Things Network Stack V3 Update 2
Migration options, technical update and timelines
Here’s an update of the development of The Things Network Stack V3, roll-out and migration options.
We’re getting more and more excited to make V3 available for public use. As said in the previous update message, it’s targeting all LoRaWAN deployment scenarios: public community network and private hosted, private cloud, private on-premises and open source development. The V3 minimum viable product (MVP) will target private on-premises and open source development, but can be used to evaluate the stack for private hosted and private cloud.
Migration from V2 to V3
We’ve been receiving a few questions about migrating V2 to V3. In this update, I want to answer frequently asked questions about migration.
How does migration from V2 to V3 SaaS work?
We move applications and devices from V2 to V3 at a scheduled time; devices cannot be present in both. In order to avoid downtime, you have to connect your application to both V2 and V3 to avoid missing messages. Device sessions will be preserved, however as V3 has more many more MAC settings, manual configuration may be required. We’re happy to help customers with this process.
What kind of MAC settings do I need to adjust, and how does it affect my data?
In most cases, you don’t need to adjust anything. V3 has per-device settings for LoRaWAN MAC and PHY version (i.e. setting the device to LoRaWAN 1.0.2 with Regional Parameters 1.0.2 rev B). On migration, we assume V2 defaults when migrating to V3. Devices that work in V2 will work in V3 as well. However, you may want to adjust RX1 timing and RX2 parameters for better performance.
Which device session settings are you migrating?
The Device ID, plus the LoRaWAN MAC state including AppEUI, DevEUI, DevAddr, NwkSKey, AppSKey, FCntUp, FCntDown and PHY version 1.0.2 rev B.
Do I migrate application per application?
Yes. You cannot migrate per device, only applications as a whole.
Can I migrate applications and devices back to V2?
How to migrate my gateway to V3?
Gateways need to be updated to a new address. We will update DNS records with a decent sunset period, but eventually we migrate to a new DNS scheme.
We provide a migration path by replacing the current V2 Bridge with the V3 Gateway Server which points traffic to V2 and V3 concurrently. This enables you to keep using your production V2 environment while you can use V3 with the same gateway infrastructure.
What about the V3 Gateway Agent?
We have put the V3 Gateway Agent project on hold, as we are working with Semtech to test and evaluate a network-independent packet forwarder. This packet forwarder replaces the existing UDP based packet forwarders and offers functionality similar to the V3 Gateway Agent; remote configuration, secured and authenticated communication, TLS sessions with optional client authentication, low band width mode by filtering upstream traffic, etc.
Private MVP Milestone
Since the previous update, we have merged many feature branches and improvements. V3 is quality first and built for the future, and I’m confident that thanks to the longer development time and taking lessons learned into account, V3 is the best LoRaWAN network stack available. It comes at a price; time, but I bet it’s worth it.
Here’s what needs to be done for the MVP release:
Finalizing the Console. Our API is now final though
Finalizing the CLI
Finalizing the Network Server downlink scheduling
Bridging to V2 and V3 for side-by-side deployments
Making everything GitHub ready; housekeeping and documentation
If you have any questions, please reply and I’m happy to answer them.
CTO and Co-founder, The Things Industries
next update is in two weeks!