Does V2 and V3 share the same Net ID?

TTN V2 to V3 Upgrade
1

Hi,

I know that V2 has been shut down, but I’m wondering purely out of curiosity

  1. Does V2 and V3 share the same Net ID?
  2. If so, how come we could do active session migration between different tenants on the same network without changing the DevAddr?
  3. I’m also deciding between Helium and TTN for my next project, and I’m wondering why TTN associates gateways with a particular network (i.e. some gateways are in V2, some in V3), whereas Helium gateways don’t care about which console (in fact, you can’t even add gateways to console)

I’m learning a lot about the TTN architecture and was down this rabbit hole. Any help is appreciated, thanx!

2
  1. They did, the one ID that has been assigned to TTN.
  2. Because data was forwarded between the two networks. Which you could know if you took the effort to research the migration as it has been mentioned multiple times on this forum.
  3. Because Helium and TTN are implemented totally differently. And V2 is down so there are no more gateways in V2.

When it comes to decided between networks you might want to take into account the driving forces behind the network. Based on the number of Helium accesspoints and the amount of LoRaWAN traffic that network is seems to mainly attract miners looking to generate money and get rich. TTN is about implementing LoRaWAN use cases.

1 Like
3
  1. Thanx for clarifying!
  2. I actually did my research before posting here, I should rephrase my question → so the packet broker would essentially keep a record (i.e. DevAddr A belonged to V2, and packet broker would recognize that DevAddr because of the migration request, then even though technically DevAddr A belonged to V2’s LNS, the packet broker would forward it to V3’s LNS?) → but how could V3’s LNS accept this DevAddr if it can’t find it in its own device address space?

Unless what it means is that the device is still joined with the V2 LNS, but the data gets forwarded to V3 LNS, which somehow doesn’t drop the packet even though it doesn’t recognize the DevAddr?

  1. What are the tradeoffs of associating gateway with a particular network then?

Fair point…i don’t think they have a forum either so I’m looking for help here…

4

Because the TTI development team are wizards. And much of it was predicated around which gateway it came in via - tenants are TTI construct, it all boiled down to a DevAddr + matching credentials / decryption - tenants are a way of partitioning data sets whilst still using the same server instance - nothing to do with the LoRaWAN spec. I could migrate sessions but generally I think people let devices rejoin, along with a lot of legacy devices on ABP.

As for TTN vs Helium, why not try both and see what the reality is. For such an open ended question it would be easier to know what your use case / requirements are.

1 Like
5

2.No. To be able to migrate devices you had to move gateways first. While the device was still in V2 the packetbroker sent the data to V2, however the because the gateway was in V3 the packet was available there as well without a matchig device. Once you moved the session to V3 it could match the device in V3 (and still packetbroker would sent it to V2). So after migrating the session the LNS had that device address.

I am curious as to why this would be important months after the migration ended. The mechanism won’t work to migrate devices from one network to another without both parties investing time and money. Something TTN did to ease our migration to the new stack. Something that won’t happen for migration to/from Helium or one of the other LoRaWAN providers.

Helium has discord in stead of a forum.

And as @descartes states, we won’t be able to help if you don’t ask well defined, specific questions.

1 Like