# Selecting preferred LoRaWAN network?

**URL:** <https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901>\
**Category:** Application Development\
**Created:** [February 1, 2022, 6:42pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901 "2022-02-01T18:42:33Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![tibhel](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/tibhel/32/40457_2.png) [@tibhel](https://www.thethingsnetwork.org/forum/u/tibhel)\
**Post date:** [February 1, 2022, 6:42pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/1 "2022-02-01T18:42:33Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\
**Post date:** [February 1, 2022, 7:25pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/2 "2022-02-01T19:25:39Z")

</div>

> [@tibhel](#):
>
> How can this prioritising be done in a nice way?

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.

---

<div class="post-metadata">

**Author:** ![tibhel](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/tibhel/32/40457_2.png) [@tibhel](https://www.thethingsnetwork.org/forum/u/tibhel)\
**Post date:** [February 1, 2022, 7:51pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/3 "2022-02-01T19:51:22Z")

</div>

> [@descartes](#):
>
> Easy, put the join details in to an array in decreasing order

How would you do that for an OTAA device?

---

<div class="post-metadata">

**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\
**Post date:** [February 1, 2022, 7:55pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/4 "2022-02-01T19:55:34Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![tibhel](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/tibhel/32/40457_2.png) [@tibhel](https://www.thethingsnetwork.org/forum/u/tibhel)\
**Post date:** [February 1, 2022, 8:01pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/5 "2022-02-01T20:01:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\
**Post date:** [February 1, 2022, 8:12pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/6 "2022-02-01T20:12:42Z")

</div>

> [@tibhel](#):
>
> 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?

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

> [@descartes](#):
>
> put the join details in to an array in decreasing order of preference

> [@tibhel](#):
>
> I don’t see that working if all networks would send at the same time.

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

> [@descartes](#):
>
> and work your way through the list until you get a result.

> [@tibhel](#):
>
> Also that requires the device to be provisioned on all networks which is not good.

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.

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

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:

> [@descartes](#):
>
> put the join details in to an array

> [@tibhel](#):
>
> Maybe I didn’t explain my question clear enough.

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.

---

<div class="post-metadata">

**Author:** ![tibhel](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/tibhel/32/40457_2.png) [@tibhel](https://www.thethingsnetwork.org/forum/u/tibhel)\
**Post date:** [February 1, 2022, 8:43pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/7 "2022-02-01T20:43:11Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![kersing](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/kersing/32/44777_2.png) [@kersing](https://www.thethingsnetwork.org/forum/u/kersing)\
**Post date:** [February 1, 2022, 9:02pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/8 "2022-02-01T21:02:18Z")

</div>

> [@tibhel](#):
>
> There are no settings (except deveui/appeui)

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…

---

<div class="post-metadata">

**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\
**Post date:** [February 1, 2022, 9:30pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/9 "2022-02-01T21:30:46Z")

</div>

> [@tibhel](#):
>
> join accept collision

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.

> [@tibhel](#):
>
> I kindly ask you to be a bit more detailed in your answers to reduce unnecessary threads like this, regardless of the question.

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.

---

<div class="post-metadata">

**Author:** ![Jeff-UK](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/jeff-uk/32/35697_2.png) [@Jeff-UK](https://www.thethingsnetwork.org/forum/u/Jeff-UK)\
**Post date:** [February 1, 2022, 11:12pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/10 "2022-02-01T23:12:19Z")

</div>

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! 🤔

---

<div class="post-metadata">

**Author:** ![tibhel](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/tibhel/32/40457_2.png) [@tibhel](https://www.thethingsnetwork.org/forum/u/tibhel)\
**Post date:** [February 2, 2022, 12:27pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/11 "2022-02-02T12:27:09Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\
**Post date:** [February 2, 2022, 12:34pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/12 "2022-02-02T12:34:27Z")

</div>

> [@tibhel](#):
>
> Having to modify the LMIC library to try different AppEUIs for each channel/datarate does not sound good to me

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.

---

<div class="post-metadata">

**Author:** ![tibhel](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/tibhel/32/40457_2.png) [@tibhel](https://www.thethingsnetwork.org/forum/u/tibhel)\
**Post date:** [February 2, 2022, 2:08pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/13 "2022-02-02T14:08:30Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![descartes](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/descartes/32/47220_2.png) [@descartes](https://www.thethingsnetwork.org/forum/u/descartes)\
**Post date:** [February 2, 2022, 3:35pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/14 "2022-02-02T15:35:34Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![system](https://www.thethingsnetwork.org/forum/uploads/default/original/3X/6/2/6250ea44fd2b0d6259489e1a92748df681e1f970.png) [@system](https://www.thethingsnetwork.org/forum/u/system)\
**Post date:** [February 3, 2022, 3:35pm UTC](https://www.thethingsnetwork.org/forum/t/selecting-preferred-lorawan-network/54901/15 "2022-02-03T15:35:37Z")

</div>

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