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?
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)
1 Like
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?
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!
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.
1 Like
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.
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.
3 Likes
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ā?
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.
1 Like
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.
4 Likes
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:
- 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)
- 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).
- 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.
1 Like
The nice thing for TTN is that we (the community) are the network. So feel free to start working on a proposal.
2 Likes
Is it possible to simply register a Class A device with multiple LoRaWAN providers, so that packets received by one provider will be sent to your server via their systems, packets received by the other would be sent via their systems, and the providers need not have any form of sharing arrangement at all or even know that each other exists?
For instance, can a person register devices with a commercial LoRaWAN provider that has suitable coverage in a target market, but also register the same devices with TTN to provide additional coverage options for mobile devices or devices in areas with poor coverage by the commercial provider? Obviously the networks would have to operate at the same frequency.
I think this is a slightly different question to the original post, I just canāt post a new topic yet sorry. It seems a simpler and more flexible option than waiting for network providers to form collaborations, at least for one-way communication.
Background: I have devices registered with a commercial provider, but have reception issues in certain areas, and would like to also take advantage of TTN gateways to maximise options for reception.
That will not work because networks have their own range of device addresses. For TTN devices need to have (and will be assigned) a device address starting with 26 or 27. Any lorawan transmission with an address starting with for instance 12 will be ignored in the backend.
Thankyou. Just trying to understand this better in light of this discussion on switching between networks.
Is the device address autogenerated once for the device, or regenerated each time the device ājoinsā the network?
Do I understand correctly that if I have a device with the same DevEui, AppEui and AppKey registered with another network, and with TTN, both using OTAA:
- On startup, it will randomly ājoinā one of the two networks (probably the one with the best reception).
- While connected to that network, transmissions will use an autogenerated device address that is only recognised by that network. So if ājoinedā to another network, TTN will reject transmissions from it. And if ājoinedā to TTN, the other network will reject transmissions, even though it knows the DevEui, AppEui and AppKey.
- The next time the power is cycled, it may join TTN, and the reverse would apply.
If that is the case, could I have a device that was registered with both networks, but occasionally attempted to rejoin, and in that process would connect to the network with the highest reception at the time?
Although this would not give the reliability of using all gateways simultaneously, it should mean that if one network were down temporarily, or the device moved out of reception, it would end up connecting to the other network and continue to transmit successfully.
Do I understand this correctly or would this not work for a reason I have missed?
The device address (along with session keys) are generated on join.
What you describe could work, however to join a device uses a random nonce. These nonces should be unique. The nonce is 16 bit, so in theory a device could join 64k times. In practice you will get duplicate nonces much sooner, resulting in delays while retrying to join a network.
With this mechanism two networks will instruct a gateway to respond (assuming two networks receive the request). The node will probably receive the reply with the strongest signal, however if the signals of both gateways have comparable strength it may end up not receiving a valid join response at all.
With regards to the device migrating/rejoining, make sure your mechanism to check for a valid āconnectionā to a network does not exceed the fair access policy of TTN. So no acks for all uplinks or uplinks need to be limited to 10 a dayā¦
Thankyou, that is very helpful. Thanks for outlining the downsides Iād need to work around. If I were just to try rejoining once a day it should run for several years without getting many or any duplicate nonce values. Alternatively, I could ask for an ack every 4 hours or so and just rejoin if no ack was received then. Lots to think about, and I donāt know whether Iāll actually do this yet, but Iāve got enough information to get started now.
If a OTAA device is joined in one network and you want to use the device from another network, you must add the device in the new network with the session keys and addresses (DevAddr, NwkSKey, AppSKey), not with the join keys and addresses (DevEui, AppEui and AppKey). In other words, add it as an ABP device.
Hi, I am currently looking at both TTN and Loraserver for a project, Would it not be possible to use multiple packet forwarders to achieve this network compatibility? Thanks in advance.
No that would not work, like Jac said, networks have their own device address range and gateways are stupid.
Chances are that in the near future, different networks work together with roaming, so that packets received by TTN will be directed to another connected network and viceversa.
@ this moment, packets with a non TTN device address, will be dropped by the TTN backend.
1 Like