From @johan’s presentation:
Will the release for v3 contain the source code?
’ Almost one year back we decided to rebuild our backend server from scratch. The 3rd generation of the network stack takes into account all the lessons learned on security, scalability, speed and developer friendliness.
The future is Connected Private Networks. The V3 stack is designed to run well privately, either in a private cloud or on-premises. Private networks can use the long-awaited feature of exchanging traffic (peering) between public and private networks. This allows any private network to use community coverage while contributing back to the community network.
Want to know more? Read along.
I wish you guys would release the V3 stack so I can quit my job and start playing with it…
don’t quit your job this year
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?
No.
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
Integration testing
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.
Johan Stokking
CTO and Co-founder, The Things Industries
next update is in two weeks!
Is there any api documentation for the new stack available, or will the old api (application manager & data) be still usable after the migration?
I guess it doesn’t make much sense to start a new project using the old api now, or does it?
indeed, better wait a few weeks
Anyone heard any more about V3 ?
if you don’t read it here… there isn’t probably
expect more news after Thursday this week (conference)
Haha - I thought it couldn’t possibly be that quiet on progress !
official release on GITHUB after very very hard work… tnx !!
a lot of new things to study…from 'correlation ID’s to priotarization
Woop woop
now that its officially released, we continue in part 2 :