thethingsnetwork / lorawan-frequency-plans Goto Github PK
View Code? Open in Web Editor NEWLoRaWAN Frequency Plans for The Things Stack
Home Page: https://www.thethingsnetwork.org
License: Apache License 2.0
LoRaWAN Frequency Plans for The Things Stack
Home Page: https://www.thethingsnetwork.org
License: Apache License 2.0
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:
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
To have coexistence between LoRaWAN and RFID
EU_863_870
A new custom frequency plan for EU
The Things Stack Cloud v3.16.2
Find the best 5 new optional channels after 868.5 Mhz and use them together with 868.1 - 868.5 Mhz.
No
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
...
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.
...
during the pilot, the approved plan was 915-917mhz, and now it was shifted and approved for 917-920.
...
While the Israeli approved plan is similar to AU915 FSB1-2, it is not exactly the same, and therefore a customized plan is required.
...
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
...
I propose to add IL917-920_FSB_1
...
Yes I have already prepared the yaml file for review.
...
By default, the Frequency Plan Australia 915 - 928MHz has a Dwell Time enabled, causing Uplink with large Payload cannot be sent.
Since Brazil does not have Dwell Time limitation, we need to have a Frequency Plan where Dwell Time is disabled by default.
Yes
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.
We may need a basic AS923 frequency plan (with only the mandatory channels).
For compatibility with v2, which uses such a frequency plan if it can't reliably determine the country of the gateway.
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).
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.
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.
Currently there is Asia 915-928 MHz (AS923 Group 1) with only default channels and dwell time disabled.
The current Frequency Plan only has default channels. There is no Sub-bands.
This Frequency Plan will be used in Singapore.
The only available regulatory document is the attached Technical Specification. (Page 17/34)
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.
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.
For each plan we should indicate whether it's applicable to end devices and/or gateway.
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.
We should only show relevant plans when registering gateways / end devices.
We'd need to indicate in each frequency plan (or perhaps in the index) whether the plan applies to gateways, end devices or both.
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
...
IN_865_870 : India 868 - 867 MHz
...
IN_865_867 : India 868 - 867 MHz
...
Yes
...
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.
We need an EU433 frequency plan
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:
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.).
Invalid radio settings issued by AS_920_923_TTN_JP_3
A channel cannot be more than +/- 400 KHz from the radio frequency.
...
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
...
The basic station should be able to run, invalid configuration should not be provided.
...
A different frequency needs to be defined.
...
...
Add the FSB1 for CN470 frequency plan
the main motivation is to avoid to have a lot of dropped join request on this frequency plan.
This is an upgrade of the existing CN470 implementation (Section 2.6.2 on LoRaWAN Regional Parameters v1.0):
Copy-paste the existing CN470_FSB11 and minus 16MHz to each frequency.
Yes
Based on our earlier call regarding newer regional parameters, we have discussed that the following changes should be done to this repository:
In order to support newer regional parameters versions.
Only master
, containing frequency plans combining both gateways and end devices.
Can review and assist when needed.
In order to assist users to pick the usually applicable FP per country, we should add such information to the FP structure.
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.
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.
An endorsed
flag per frequency plan.
Updating the sheet is trivial. More complicated will be to determine the correct FP for endorsement.
Updating the yaml is not the problem but I am not knowledgeable about FPs enough to decide which ones to endorse.
We should add the missing FSBs for US915 (3-8) and AU915 (3-5 and 7-8).
Even though we encourage the other FSBs, these missing ones are still valid.
Copy-paste and add a couple kHz to each frequency.
Yes
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
...
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
Beaconing settings in frequency plans or additional plans for optional beaconing.
...
...
...
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
To let the user use a frequency plan with channels within the permitted spectrum in Morocco.
Standard EU_863_870
Frequency plan.
Frequency plan for Morocco.
TTS v3.20.1
...
No
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.