Different LoRa Servers


(Wechuli) #1

Hey, this is probably a simple question. So if i understand correctly, the way LORAWAN works is that the end nodes have no association with any particular gateway. But the gateways are configured to forward packets to a specific LoRa network server. So assuming I have applications and devices configured in ttn, but the gateways that are in my range are configured to forward packets to lets say Loriot network server, will this traffic still be routed to my ttn application?


(Elvin Luff) #2

You’re correct that it doesn’t matter what gateway picks up the messages. LoRaWAN nodes simply broadcast a message, and any gateways in the vicinity will pick up the message. They will then forward this message to the network server that it is configured to forward to. A gateway configured for TTN will forward all packets to the TTN network server, a Loriot to a Loriot server, etc.

All packets received get forwarded to their network server. However, remember that all LoRaWAN packets are encrypted. If a Loriot network server receives a TTN packet, it cannot decrypt the message. It is subsequently dropped. And vice versa.

Unless there was a specific effort to peer networks servers together, they simply don’t talk to each other. If your TTN node broadcast is only received by a Loriot gateway, you will not receive the message. (You’ll get it if there’s also a TTN gateway in the vicinity)


(Badryan) #3

Follow-up question: Roaming between different LoRaWAN networks would require a directory of applications and a way to normalise messages received at different networks. Is that something people are doing? Are there any tools or services readily available?


(Elvin Luff) #4

There’s no effort between the products of different companies, from what I’ve been seeing. A Loriot network server can’t pass messages to a TTN server, or the open source Lorawan server, for example.

However, there’s plenty of effort to peer networks using the same product. The Things Network v3 stack has peering as standard, where you can peer multiple private networks together, or peer your private network with the community network.

It’s being worked on, but it’s not quite there yet!


(Arjan) #5

No, peering/roaming would use the prefix of the DevAddr to pick one or more possibly suitable providers to which to forward the message; see https://www.thethingsnetwork.org/docs/lorawan/address-space.html#device-address-assignment The DevAddr and some other meta data are not encrypted.


(Elvin Luff) #6

https://www.orange-business.com/en/press/international-lorawan-roaming-trial-success

It looks like roaming agreements are starting to come to national networks! Of course this is an entirely different use case compared to what most people here are doing, but it shows that some real thought is being put into this.

In fact, the things network v3 has roaming as standard - all the community networks around the world are peered together, so you would be able to send messages through the Meshed AU router and have them forward to the EU network, for example.


(Nestor Ayuso) #7

The lora alliance has a roaming specification for the directory of applications and normalized messages. this is documeted in file LoRaWAN-Backend-Interfaces-v1.0.pdf request it here: admin@mail.lora-alliance.org

Basically if Loriot receives a LoRa packet with a DevAddr=0x26345678, this address is owned by TTN acording to https://www.thethingsnetwork.org/docs/lorawan/address-space.html#device-address-assignment but a network server can automate the resolution using a DNS query to domain name 8.7.6.5.4.3.6.2.NETIDS.LORA-ALLIANCE.ORG

Then if Loriot and TTN have a roaming agreement, Loriot can forward the packet to TTN in a normalized message format. This is called pasive roaming.

The same for OTA joining using a Join Server:

In a ideal scenario, the LoRa device makers and LoRa server developers don’t need to deal with security: encryption, keys storage, authentication… using security companies like Gemalto, for example.

A device maker just buy a secure element chip from gemalto and put it inside the LoRa module.

Upon a join request received by a network server with an AppEUI=JoinEUI=0x1C41586789abcdef this EUI belongs to Gemalto acording to http://standards-oui.ieee.org/oui.txt but the network server can automate it using a DNS query to f.e.d.c.b.a.9.8.7.6.8.5.1.4.c.1.JOINEUIS.LORA-ALLIANCE.ORG then the network server asks Gemalto to authorize the join, and derive the network key and application key and forward them to the network server and application server respectively.


(Badryan) #8

If I understand correctly, this would resolve the roaming issue on the network level.

Alternatively, the issue could also be resolved on the application level, or not? I’m not sure if that’s possible, but could I register an application with the same app ID with two different network providers, and then normalise in my own software? Or is this technically not possible or otherwise “against the rules”?


(Wechuli) #9

Okay, thank you for the response.
This kind of makes LORAWAN inefficient because even if gateways are in range of my end nodes, i still have to make sure they are forwarding packets to the correct Network Server. Basically means if I am building an IoT solution using LoRa as the communication infrastructure, to be safe, i will need to also set up my own gateways to direct my traffic accordingly.
I think more effort should be made to connect all LoRa network servers in a manner that allows them to talk to each other, I guess we would need to find a unique way to identify which applications are associated with which network servers, sort of the way ip(version 6) works.


(Jac Kersing) #10

Just like with mobile providers (at least in your contract country) you need to make sure you are in range of their cells. No roaming of data/voice. The advantage of LoRaWAN (and specifically TTN) is you are able to add your own gateways cheaply, (a couple of hundred dollars for one) where for mobile networks you have to rely on the provider to provide you with coverage.
When compared to Wi-Fi things are even better, for LoRaWAN you do not need secret keys associated with the access point, just with the network.

So inefficient? Depends on how you look at it.


(Wechuli) #11

Good points Kersing. If your devices are static (or they are mobile but within your own gateways coverage limits) and within a constrained geographical area, then LoRaWAN would be ideal. I am trying to implement a solution where my nodes are constantly moving and I cannot predict where they would be at any given time or if there would be a gateway where they are that is configured to forward packets to ttn. Setting up my own gateways is kind of expensive, I’ll need to determine every possible place my nodes will move to, and then set up my gateways. If I was using a cellular infrastructure, I would not even need to think about how my devices would talk to the internet, in any case , mobile providers provide almost 100% coverage, so I would rarely be asking myself if my data is being routed to the backend.
I think we should move to a standard where:

  1. if anybody is setting up a gateway and intends to use any of the public LoRa Network Server, they must reveal all relevant information about it(location, specs, etc)
  2. As I said earlier, all public LoRa Network servers should be connected, so that as long as a gateway is forwarding to any public network server, anybody can use them without worrying about which one(the public network server).
  3. The network server providers would each collect statistics on the gateways(up-time,location, traffic, etc) and make this information available to anyone (sort of like what ttn has done, but this time in a unified manner so that the challenge will be to find any gateway and not a gateway that is forwarding packets to a specific network server)

All this is a bit too soon I guess, but we should get there, hopefully.


(Jac Kersing) #12

The nice thing for TTN is that we (the community) are the network. So feel free to start working on a proposal.