Selecting preferred LoRaWAN network?

Application Development
1

Hi!

I’m trying to find a way of prioritising selection of LoRaWAN network depending on coverage and cost for a specific end-device.

Lets say that I have an OTAA end-device and I’m registering it in an app. The app provisions it automatically to TTN or some other public network providers. The device happen to be in coverage on both TTN and another paid network and I want it to be on the cheapest(TTN) network for example.

How can this prioritising be done in a nice way?

It’s not good to have an end-device provisioned on several networks due to collision etc. And the problem is that you do not know if you have coverage on a network before provisioning.

Thanks in advance!

2

Easy, put the join details in to an array in decreasing order of preference and work your way through the list until you get a result.

But the last I heard you didn’t have much space in your MCU so it may get a bit tight.

3

How would you do that for an OTAA device?

4

Create a C array with settings, for loop through it, break if join succeeds …

5

Do you mean that the end-device should check for the NetID on the received joinAccept message and reject it if it is not the preferred one? I don’t see that working if all networks would send at the same time. Also that requires the device to be provisioned on all networks which is not good.

There are no settings (except deveui/appeui) used on an OTAA device so I’m not sure what you mean by “settings”?

Maybe I didn’t explain my question clear enough.

6

Well you can do that too, but I did say:

Well you can’t do that but I did say:

How else would such a scheme work? You can’t have a device hunt for a network to join - there isn’t a broadcast like GSM or WiFi and it’s not like WiFi where if you have the credentials you can join (which is a bit like ABP) so for either connection method, the likely servers are going to have to know about the device under pretty much all circumstances unless you use the Chirpstack AutoRegister feature in the RAK gateways - but that would require you to setup a public network of RAK gateways, so you could then just use normal gateways and register them in your own Network Server.

I only used settings, ie “information to which a machine or device can be adjusted to operate” as a generic term, but I did say:

Given the protracted system design that you’ve received over the past months, you either need to slow down to read the responses & think about them OR commission someone to get your project done.

7

So one solution would be to have a different DevEUI or AppEUI for each network to avoid join accept collision. However that introduces a bit more complexity in the registration process. I guess that is what you mean by “join details”?

I kindly ask you to be a bit more detailed in your answers to reduce unnecessary threads like this, regardless of the question.

Thanks again

8

So what stops you using different AppEUIs for different networks? Apart from that provisioning a device on a commercial providers network usually involves fees… You probably need to do a site survey at the deployment location and choose manually depending on the survey results. Of just deploy your own gateways (attached to TTN preferably) if you deploy in bulk. That way you provide something back to the community as well…

9

The device stack can only do one set of settings at a time, so there is little chance of a join accept collision unless you send out a pile of join requests and then try to hear them all simultaneously which would rather imply you need a gateway for a device, which is getting silly.

Just do one at a time.

The time I spend here is funded by the people that get me to come up with, design, test & deploy these sorts of schemes and this is how I can spend as much time on here as I do.

I alluded to my view above on how much design help you’ve been given - this one is an easy array & loop implementation, probably about an hour to code and then, because you’ll need three or four NS’s to go at, a day to test - we can’t actually extend to writing the code for you - we are volunteers after all - and I doubt you’d get a TTI paid support contract to get code written for you unless you have an enterprise package. And even then there is a whole conflict of interest going on here.

And on that note, TTI are taking a view on people who do have many commercial devices, so you may want to engage with them on having a private instance before you launch your product.

10

And just to remind scope here - this is the Forum for THE prefered network - TTN; not neccessarily to look at how to join others even if as alternates. If you want options perhaps persuade the other target networks to peer with TTN to allow roaming away from home and/or perhaps engage via PacketBroker…then no exotic or over complicated alternate join mechanisms are needed on the devices - KISS! :thinking:

2 Likes
11

Having to modify the LMIC library to try different AppEUIs for each channel/datarate does not sound good to me and it will take much more time to join due to duty cycle limits. So I will stick to some backend solution and not modify the firmware!

The plan is to also have TTN gateways where there is no coverage from any network.

Thanks for your input!

1 Like
12

There is no requirement to modify the LMIC library at all. Just a simple for loop over an array in the setup.

And duty cycle limits would allow you to try one set of credentials every 3 minutes. So not a huge imposition. Once joined, that’s all done.

You still sound like you are going to fall foul of the FUP with the deployment.

13

That is if you are assuming sending on SF7 only. But you may have to go up to SF12 if the connection is bad which will take hours to increment to.

14

Why would you assume SF7?

And if you do polish you halo and absolutely stick to the FUP AND choose to increment from SF7 up, it will take 4.4 hours.

But as you are interleaving non-FUP networks AND you choose to increment from SF7 up, it would take 9 minutes per non-FUP network.

Or you could run through SF7 to SF12 with the FUP interval between each go, and take 2.25 hours.

However you are entirely at liberty to use any SF you like to start a join with. So you could try SF9 and then move to SF11.

But if you need to join at SF12, you may want to use another network at a lower SF as you’ll just kill the battery on the device.

Or you could join the first available network at a lower rate and then probe for other networks once you are transmitting data.

Reality is that one implementation that may exist is that it joins the first reasonable network and once online, can be told what to probe for if there is coverage that might be at a slightly higher SF - but balanced against the battery use.

15

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.