thethingsnetwork / lorawan-frequency-plans Goto Github PK

Add frequency plan for devices that are roaming in Europe.

The current proposal is 868.1, 868.3, 868.5, 867.1, 867.3 and 867.9.

Blocked on agreement within LoRa Alliance.

The current actions make use of deprecated features and should be updated.
This relates to the use of:

• Node.js 12
• set-output
• save-state

Summary

https://ibb.co/gyBFvfZ

We need assistance to implement a new custom frequency plan in the EU, which is different from the standard frequency plan which uses the 5 optional channels in 867.1 Mhz - 867.9 Mhz. The plan is to move the 5 optional channels after 868.5 Mhz. We seek advice on where it is best to place the new channels, when we also have to think about the duty cycle being different in the other subbands. The reason for having this custom frequency plan is because we are experiencing a lot of interference from a passive RFID system at one of our locations, which results in poor data rate and high packet loss.

We have tried it ourselves to come up with a custom frequency plan, and test it on a local LNS in our office (see attached file). It did work on most channels, but for some reason we did not receive any data on 869.3 Mhz. We hope that you can help us with finding a way to best implement a frequency plan so we can have coexistence between LoRaWAN and RFID. We have also found an article which describes this issue in North America

https://lora-developers.semtech.com/uploads/documents/files/Coexistence_of_LoRaWAN_and_UHF_RFID_Final_v3.pdf

Why do we need this?

To have coexistence between LoRaWAN and RFID

What is already there? What do you see now?

EU_863_870

What is missing? What do you want to see?

A new custom frequency plan for EU

Environment

The Things Stack Cloud v3.16.2

How do you propose to implement this?

Find the best 5 new optional channels after 868.5 Mhz and use them together with 868.1 - 868.5 Mhz.

Can you do this yourself and submit a Pull Request?

No

Summary

Israel has finally approved and legalized the deployment and usage of LoRaWAN networks in Israel.
As a LoRaWAN and TTN/TTI enthusiast and promoter, I would like to contribute and help in defining and adding the regional
frequency IL917-920 to the ThingsStack

...

Why do we need this?

This will allow both community and business users to deploy LoRaWAN in Israel, correctly and legally, publicly and at scale. Until now only pilots were allowed.

...

What is already there? What do you see now?

during the pilot, the approved plan was 915-917mhz, and now it was shifted and approved for 917-920.
...

What is missing? What do you want to see?

While the Israeli approved plan is similar to AU915 FSB1-2, it is not exactly the same, and therefore a customized plan is required.
...

Environment

This will be used only in Israel as far as I know.

This is the official document, there is no English translation yet.

https://www.nevo.co.il/law_word/law06/tak-9301.pdf
Page 12 and Page 13
Section 47

...

How do you propose to implement this?

I propose to add IL917-920_FSB_1

...

Can you do this yourself and submit a Pull Request?

Yes I have already prepared the yaml file for review.

@htdvisser

...

Summary

By default, the Frequency Plan Australia 915 - 928MHz has a Dwell Time enabled, causing Uplink with large Payload cannot be sent.

Why do we need this?

Since Brazil does not have Dwell Time limitation, we need to have a Frequency Plan where Dwell Time is disabled by default.

How do you propose to implement this?

Yes

Can you do this yourself and submit a Pull Request?

Yes

We currently have the Frequency Plans Overview and Frequencies By Country pages (as well as a map) on our documentation site.

Now that our frequency plans are kept in a more structured format, those documentation pages may be generated and updated automatically when things change in here.

Summary

We may need a basic AS923 frequency plan (with only the mandatory channels).

Why do we need this?

For compatibility with v2, which uses such a frequency plan if it can't reliably determine the country of the gateway.

How do you propose to implement this?

Copy-paste from another AS923 plan, remove channels and change the min/max.

We should add a Japan-specific frequency plan that sets the maximum EIRP correctly (to 16dBm).

Summary

In Singapore, LoRaWAN network falls in the category of LPWAN with Authorized Frequency Band 920 - 925MHz.
There is no Dwell Time limitation and spectrum access is control by means of Duty Cycle. (=<1% ).
Please refer to attached document Page 17/34.
I would like to request for an additional regional frequency SG920-925 to TTS.

Singapore_IMDATSSRD.pdf

Why do we need this?

In TTS v3.17 or earlier, Frequency Plan Asia 920 - 923MHz was used. (Default Dwell Time is disabled)
Application with large Uplink/Downlink Payload can be deployed without problem.
In TTS v3.18, Dwell Time is enabled by default in Frequency Plan Asia 920 - 923MHz causing Uplink/Downlink with large Payload cannot be sent.
Since Singapore does not have Dwell Time limitation, we need to have a Frequency Plan where Dwell Time is disabled by default.

What is already there? What do you see now?

Currently there is Asia 915-928 MHz (AS923 Group 1) with only default channels and dwell time disabled.

What is missing? What do you want to see?

The current Frequency Plan only has default channels. There is no Sub-bands.

Environment

This Frequency Plan will be used in Singapore.
The only available regulatory document is the attached Technical Specification. (Page 17/34)

Singapore_IMDATSSRD.pdf

How do you propose to implement this?

I would like to propose for an additional regional frequency SG920-925 to be added.
This plan must have all AS923-1 channels (default channels and it's Sub-bands) with default Dwell Time disabled.

Can you do this yourself and submit a Pull Request?

No

The README contains the following confusing/incorrect line:

base-frequency: 868      # Base frequency in MHz (433, 470, 860 or 915)

We should specify more clearly what the intention of this field is (I suspect hardware support?) and use appropriate values in the documentation of this field.

Summary

For each plan we should indicate whether it's applicable to end devices and/or gateway.

What is already there? What do you see now?

In the Console you can now select both the EU_863_870 plan and the EU_863_870_TTN plan when registering a gateway. For gateways, these plans are equivalent, but users don't know that, which makes it confusing.

What is missing? What do you want to see?

We should only show relevant plans when registering gateways / end devices.

How do you propose to implement this?

We'd need to indicate in each frequency plan (or perhaps in the index) whether the plan applies to gateways, end devices or both.

Summary

Please replace below information in Band ID documentation

Current version has - IN_865_870 : India 868 - 867 MHz
Replace it with - IN_865_867 : India 868 - 867 MHz
...

Environment

• Frequency plan: all
• Region: India
• End device brand, model and firmware: all
• Gateway brand, model and firmware: all
• Network Server version: all

Steps to Reproduce

1. ... Replace
2. ... Replace
3. ... Replace

What is already there? What do you see now?

IN_865_870 : India 868 - 867 MHz
...

What is missing? What do you want to see?

IN_865_867 : India 868 - 867 MHz
...

How do you propose to implement this?

Yes
...

Can you do this yourself and submit a Pull Request?

Yes
...

We need naming guidelines for our frequency plans.

Right now we have a combination of [two-letter-region]_[start-frequency]_[end-frequency], but in the future this will likely cause overlap because of 8/16/32/64-channel frequency plans, or because of (combinations of) different FSBs that are used.

Each frequency plan in the index should get a list of (ISO) country codes to indicate where the frequency plan can be used.

This list could then be used to populate a dropdown in the console when registering gateways or end devices, but possibly also for guessing the frequency plan of gateways or end devices that don't have one registered.

Summary

We need an EU433 frequency plan

How do you propose to implement this?

See https://github.com/TheThingsNetwork/lorawan-frequency-plans/blob/feature/eu-433/EU_433.yml

Hi

I would like to suggest better naming convention to the AS923 bands.

LoRaWAN Alliance refers to them as AS923-1, AS923-2, AS923-3, AS923-JAPAN and soon AS923-4

Shouldn't the band selection in TTI/TTN be more similar to this notation ? The current one is a bit confusing.

Issue and Pull Request templates help contributors to submit all relevant information in their issue or pull request. For issues we can have multiple templates for:

• Proposals for new frequency plans
• Fixes for existing frequency plans
• Improvements to repository or workflow
• ...

For each of these, we'll need background information in order to determine if we can accept the proposal, and what is required for implementation. Specifically links to appropriate documentation of (local) regulations and specifications will be required.

The Pull Request template can be pretty similar to the ones we have in our other repositories. There should be a link with the issue that it fixes, it should check some boxes to make sure everything is tested with the stack, gateways, devices, etc. It should make sure that all relevant files are updated (frequency plan, index, documentation, etc.).

Summary

Invalid radio settings issued by AS_920_923_TTN_JP_3

A channel cannot be more than +/- 400 KHz from the radio frequency.
...

Environment

• Frequency plan: AS_920_923_TTN_JP_3
• Region: enter
• End device brand, model and firmware: enter
• Gateway brand, model and firmware: Multitech
• Network Server version:

Steps to Reproduce

1. Set Japan 920-923 MHz with LBT (channels 24-31) - AS_920_923_TTN_JP_3 as gateway Frequency plan
2. Run basic station

What do you see now?

2022-11-04 15:45:24.821 [RAL:VERB] SX1302 ifchain  9: enable=1 rf_chain=1 freq=1000000 bw=0 SF=50000 sync_word=0/0
2022-11-04 15:45:24.822 [RAL:INFO]  RX/TX RF0:    920.9MHz rssi_offset=-214.5 type=5 rssi_tcomp=0.000 0.000 0.000 0.000 0.000
2022-11-04 15:45:24.828 [RAL:INFO]  RX    RF1:    921.7MHz rssi_offset=-214.5 type=5 rssi_tcomp=0.000 0.000 0.000 0.000 0.000
...
2022-11-04 15:45:24.831 [RAL:INFO]  [FSK]   9:    922.7MHz rf=1 freq=+1000.0 datarate=50000 bw=0 sync_word=0/0
2022-11-04 15:45:24.832 [RAL:ERRO] lgw_rxif_setconf(9) failed
2022-11-04 15:45:24.832 [RAL:ERRO] Concentrator start failed: lgw_rxif_setconf
2022-11-04 15:45:24.832 [RAL:ERRO] ral_config failed with status 0x10
2022-11-04 15:45:24.832 [any:ERRO] Closing connection to muxs - error in s2e_onMsg

...

What do you want to see instead?

The basic station should be able to run, invalid configuration should not be provided.
...

How do you propose to implement this?

A different frequency needs to be defined.
...

Can you do this yourself and submit a Pull Request?

...

Summary

Add the FSB1 for CN470 frequency plan

Why do we need this?

the main motivation is to avoid to have a lot of dropped join request on this frequency plan.

Environment

This is an upgrade of the existing CN470 implementation (Section 2.6.2 on LoRaWAN Regional Parameters v1.0):

How do you propose to implement this?

Copy-paste the existing CN470_FSB11 and minus 16MHz to each frequency.

Can you do this yourself and submit a Pull Request?

Yes

Summary

Based on our earlier call regarding newer regional parameters, we have discussed that the following changes should be done to this repository:

• We should start versioning the repository (one branch per version)
• The gateway frequency plans should be separated from the end device frequency plans
  • The gateway frequency plans don't have to be versioned (on a per regional parameters basis) - they represent the latest version, and data rate ranges are not required
• The definition of the frequency plans should be moved to this repository. This allows CI to be added and the content of the frequency plans to be validated.

Why do we need this?

In order to support newer regional parameters versions.

What is already there? What do you see now?

Only master, containing frequency plans combining both gateways and end devices.

What is missing? What do you want to see?

• One branch per version
• Top level folders for end device frequency plan definitions, and for gateway frequency plan definitions
• A Go package that exposes the schema for these definitions

Can you do this yourself and submit a Pull Request?

Can review and assist when needed.

Summary

In order to assist users to pick the usually applicable FP per country, we should add such information to the FP structure.

Why do we need this?

Interfaces that present the list of FPs for selection could then use this info to prioritize endorsed options, thus helping users to make a choice that should work in most cases.

What is already there? What do you see now?

We currently have applicable countries for each FP which is already a good start. To help with the problem that even for a single country often many different FSBs exist, it would assist users a lot to signify the most common option to them as well.

What is missing? What do you want to see?

An endorsed flag per frequency plan.

How do you propose to implement this?

Updating the sheet is trivial. More complicated will be to determine the correct FP for endorsement.

Can you do this yourself and submit a Pull Request?

Updating the yaml is not the problem but I am not knowledgeable about FPs enough to decide which ones to endorse.

Summary

We should add the missing FSBs for US915 (3-8) and AU915 (3-5 and 7-8).

Why do we need this?

Even though we encourage the other FSBs, these missing ones are still valid.

How do you propose to implement this?

Copy-paste and add a couple kHz to each frequency.

Can you do this yourself and submit a Pull Request?

Yes

Summary

Basic station expects the LNS to provide beacon parameters in radio_conf. It makes sense that the LNS would control the beacon parameters as it sets all the radio channels.

Support for beacons settings and tests are available in the current release of the TTN stack.
https://github.com/TheThingsNetwork/lorawan-stack/blob/v3.26/pkg/pfconfig/lbslns/lbslbs_test.go#L151
...

Environment

• Frequency plan: all
• Region: all
• End device brand, model and firmware: all
• Gateway brand, model and firmware: all
• Network Server version: all

Steps to Reproduce

1. Connect basic station
2. bcning field is not provided in the radio_conf message as shown in station debug.

What is already there? What do you see now?

The bcning field can be sent to basic station since v3.21.2
https://www.thethingsnetwork.org/forum/t/upgrade-to-the-things-network-v3-21-2-completed/58810

https://github.com/TheThingsNetwork/lorawan-stack/blob/98e65a7069fd55593fa20fa5a7f44b15bfeba02d/pkg/pfconfig/lbslns/lbslns.go#L251
...

What is missing? What do you want to see?

Beaconing settings in frequency plans or additional plans for optional beaconing.
...

How do you propose to implement this?

...

Can you do this yourself and submit a Pull Request?

...

Summary

We have a request from a user to add the Frequency plan for Morocco. As per LoraWAN Regional Parameters 1.0.3, the Band/channels that can be used in Morocco are 867.6 - 869 MHz (EU863-870).

Some of the additional channels of EU_863_870 in TTS falls outside the permitted spectrum in Morocco. So, the user can't use the EU868 variant available in TTS for Morocco as per the regulation.

Here is the regional regulation document provided by the user: https://www.anrt.ma/sites/default/files/decision_a2fp_-vf-_mod_07.05.2021.pdf

Here is the English translation of the document (Tool used: Google Translate):
decision_a2fp_-vf-_mod_07.05.2021_Translated.pdf

CC: @rish-c

Why do we need this?

To let the user use a frequency plan with channels within the permitted spectrum in Morocco.

What is already there? What do you see now?

Standard EU_863_870 Frequency plan.

What is missing? What do you want to see?

Frequency plan for Morocco.

Environment

TTS v3.20.1

How do you propose to implement this?

...

Can you do this yourself and submit a Pull Request?

No