(proposal): New shifted frequency plans for EU zone

[smartnexus]

The aim of this change is to broaden the alternatives when it comes to planning a LoRaWAN network. There are such zones that have tons of devices, causing problems related with the duty cycle regulations...

BREAKING CHANGE: 3 new frequency plans proposed for EU zone

Summary

There are not issues to reference. This pull request has been developed after months fixing problems and maintaining a LoRaWAN that is using TheThingsNetwork solution.

The main issue was that in the zone where the devices where located the statistics of TTN stated high duty cycles among the band where the default EU channels are located.

Considering that the EU863-870 band is wider enough, this PR introduces 3 alternative frequency plans, so then TTN users do not have to deploy TheThingsStack on premises to use custom frequency plans.

Changes

Three new frequency plans that have 5ch situated in a different position throughout the frequency spectrum:

• EU_863_870_1 (5ch around 863.5 MHz, 3ch around 868.3 MHz)
• EU_863_870_2 (5ch around 865.0 MHz, 3ch around 868.3 MHz)
• EU_863_870_3 (5ch around 866.5 MHz, 3ch around 868.3 MHz)

Each frequency plan tries to be conservative in the way that not all 8 channels are changed from the default EU plan. Instead, only 5 out of 8 channels are shifted.

Notes for Reviewers

The necessity of this breaking change in the EU frequency plans has been requested by the companies that are running LoRaWAN for their IoT products. Indeed, although you can use your custom frequency plans in TheThingsStack, is not worth for a small IoT company (start-up) to have to loose time self hosting a service to have the ability to customize it.

Checklist

• Scope: The referenced issue is addressed, there are no unrelated changes.
• Compatibility: The changes are backwards compatible, they don't break existing deployments.
• Testing: The changes are tested.
• Documentation: Relevant documentation is added or updated.

[johanstokking]

We should definitely make it easier to customize frequency plans.

In The Things Stack V3, both the end-device and the gateway have a frequency plan. Ideally, the end-device's frequency plan is a subset of the gateway.

With these proposed plans, the end-device may be able to join but receive a set of channels that is not supported by the gateway(s). So this only works well in private networks.

Note that the duty-cycle of 863.0 to 865.0 MHz is only 0,1%.

Also, did you test this? And is there a reason to not name them EU_863_870_{1,2,3}.yml?

[smartnexus]

We definitely should change frequency plans in gateways and devices, in order to use these proposed plans.

The fact is that, having split the whole coverage zone in 3 regions, gateways and nodes would get a different frequency plan according to their location.

What is more, as there 3 common channels in every plan, those will be available in whatever coverage zone.

[smartnexus]

It was tested in a small LoRaWAN deployment using one gateway and two nodes.

Moreover, the given name is provisional. These three plans ought to have a name that allows users to understand that you can not use just one of them. Indeed, they will be more effective in the scenario I mentioned before.

[johanstokking]

@smartnexus circling back on this; what problem are you trying to solve actually? Do you see channel utilization issues with the standard plan?

I'm definitely for allowing users to customize channel plans, but The Things Stack V3 doesn't handle this properly. There is no check whether the gateway(s) that forward the join-request are configured with a superset of the frequency plan that is used for the end-device. In a public community network, this is a nightmare.

[smartnexus]

@johanstokking I would like to state that this problem is common (among other users of The Things Stack), but I might not.

I discovered this issue meanwhile being researcher at the university. In our team, we were working on a project with a private company that uses LoRaWAN to handle their's service comms.

Having compiled the network metrics (powered by The Things Stack API), I observed that there were some periods when the duty cycle was at 100% and there weren't any noticeable changes on the number of devices, amount of sent data and so on and so forth.

The main hypothesis is that there are other people relaying on this network, without owning gateways. Therefore, to address such issue, the proposal was splitting the channels in different ls sub-bands, in order to distribute duty cycle saturation.

[smartnexus]

@johanstokking Talking about an approach to handle custom frequency plan selection I could come up with a solution for this problem. I would think it over.