TTN network stack V3 central 1


#1

soon to be released… the long awaited TTN V3 stack

1-1

1-2

webinair stack V3 - https://www.youtube.com/watch?v=dvYREtWc1lA
slides - https://drive.google.com/file/d/1wJ-3tF1jRiO88S3grb7E3kbLKb7_LBgs/view
forum search - https://www.thethingsnetwork.org/forum/search?q=V3%20stack

more txt …


Class C Status
The Things Network Stack V3
Setting up a Private Routing Environment
Create my own network server
OTAA Join Takes A Long Time - Murata CMWX1ZZABZ-091 and LAIRD RG191 Gateway
Inconsistent/Unreliable Join Issues
(Joerg Wende) #2

Just wondering about the timing of V3 development - I know it will be ready if its ready - but are there any new plans or estimates ?

Thanks
Joerg


#3

htdvisser on Slack :
There has been long discussions about what to do with gateway locations. For now we won’t make any changes, but with our upcoming v3 stack, we will rely on the registered location only, and not on the location that the gateway may or may not send (we will just ignore it completely).

The reasons for this are that (1) many gateways don’t have a GPS, or are located in places with bad GPS coverage and thus have an inaccurate location (2) people started hard-coding GPS locations into config files that are difficult to update and may therefore be outdated.

For the relatively rare case of mobile (moving) gateways we still have to define a “spec”.


(Verkehrsrot) #4

Will this work with lmic?
Lmic does not support 1.1 until now (?)


#5

On Slack today :

We’re all really looking forward to the entire v3 stack. It will make so many things easier and better.
It’s indeed completely written in Go (including the Gateway Agent), so it can be cross-compiled for many CPU architectures (including several arm versions).

It’s still too early for nightly builds, I can imagine it will still take several weeks, maybe months before everything is working properly.

We want to open up the source code around this time (Q2), but the actual launch is planned for Q4 this year, so we still have enough time to actually make it work on all gateways.


(Hylke Visser) #6

From @johan’s presentation:
Timeline


(Acourt) #8

Will the release for v3 contain the source code?


#9

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.


(Simon) #11

I wish you guys would release the V3 stack so I can quit my job and start playing with it…


#12

don’t quit your job this year :wink:


#13

V3-2

The Things Network Stack V3 Update !

V3%20maillist


Conduit with 2 packet forwards
#14

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!


(Lawrence Griffiths) #15

This sounds very much like tracknet.io Station (GW) software.
Which Semtech acquired with their purchase of Tracknet.
If it is then this would be great news as it’s telco operator grade.


#16

Hi Lawrence, sorry I really don’t know :sunglasses:


(Lawrence Griffiths) #17

No worries here’s hoping

The tracknet team were Stella
Thorsten Kramp one of the authors of the LoRaWAN 1.0 spec
Marcus Oestreicher one of the authors of LMIC


(Jeff Uk) #18

…and not forgetting Hardy of course as CEO…he was the former Snr Product Manager for the Radio products at Semtech, I guess if he’s stayed post acquisition he’s going home!

As too is Byron (VP Sales) - another one of the former SMTC Snr Mrktg staffers from a range of products and applications

Must confessed I missed this one as hadn’t seen any PR from Semtech about buying them and the tracknet nor tabs websites dont mention it either! When did it happen?


(Lawrence Griffiths) #19

Happend back in summer I think , no PR about it.
I believe all have moved to and for some back to Semtech.