LoRaWAN default channel allocations

[bmarkus]

Unfortunately there is no way to get actual LoRaWAN channel settings and I do not find it in the documentation. There is only add_channel and remove_channel methods but no info_channel or whatever its name would be. It is pity specially using a development board like LoPy.

Testing the EU868 I found by default only the three mandatory channels configured with DR0...DR5 for uplink and these channels can't be removed with remove_channel. It is correct to keep compliance to LoRaWAN Specification. However it would be good to have it documented specially for regions like Asia/Pacific where no strict channel allocation and multiple settings are used even within a country.

Please provide a list of country channel settings for public and make settings available to read by an application.

[jmarcelino]

@bmarkus said in LoRaWAN default channel allocations:

Maybe I'm wrong, I do not have a live US environment here, but what is the default LoPy US channel allocation? I'm not saying it is wrong, just how to get it?

The LoPy US915 channel allocation comes from the same place as the EU 868 channel allocation, the official LoRaWAN Regional Parameters specification published by the LoRa Alliance

"2.2.2 US902-928 Channel Frequencies
The 915 MHz ISM Band shall be divided into the following channel plans.

Upstream – 64 channels numbered 0 to 63 utilizing LoRa 125 kHz BW varying from DR0 to DR3, using coding rate 4/5, starting at 902.3 MHz and incrementing linearly by 200 kHz to 914.9 MHz
Upstream – 8 channels numbered 64 to 71 utilizing LoRa 500 kHz BW at DR4 starting at 903.0 MHz and incrementing linearly by 1.6 MHz to 914.2 MHz"

so you get:

channel 0: 902300 kHz dr: 0-3
channel 1: 902500 kHz dr: 0-3
channel 2: 902700 kHz dr: 0-3
channel 3: 902900 kHz dr: 0-3
... and so on until channel 71:
channel 71: 914200 kHz dr: 4

[bmarkus]

@jmarcelino said in LoRaWAN default channel allocations:

@bmarkus
Thanks for the clarification, while your original post seemed more around documentation it's now it's clear your main objective is to be able to change almost any parameter - uplink and downlink settings - at will.

Both. These parameters must be configurable on a more flexible way as now and you must know what do you change without reverse engineering.

Regarding mandatory channels is also a good question. US915 e.g. is different, on GW side you have 8 channel blocks choosen by network operator, in your node you must set the matching set which can be even 16 channel instead of 8.

Yes US915 is a bit different, some networks even support 64 channels (gateways by Tektelic with 8 x SX1301). But you can already set the correct channels you need via remove_channel and add_channel. What's the issue there?

Maybe I'm wrong, I do not have a live US environment here, but what is the default LoPy US channel allocation? I'm not saying it is wrong, just how to get it?

same is other LoRaWAN modules can do.

Sure some modules may do (which ones? I'd like to look at their API) but for example my most deployed module the Laird RM186 and now the RAK811 don't. What they all seem to have in common is they use Semtech's LoRa-Node stack, which is what the LoPy uses as well.

I'm working with RN2483. I have RisingHF modules but not for production, only for testing.

[jmarcelino]

@bmarkus
Thanks for the clarification, while your original post seemed more around documentation it's now it's clear your main objective is to be able to change almost any parameter - uplink and downlink settings - at will.

Regarding mandatory channels is also a good question. US915 e.g. is different, on GW side you have 8 channel blocks choosen by network operator, in your node you must set the matching set which can be even 16 channel instead of 8.

Yes US915 is a bit different, some networks even support 64 channels (gateways by Tektelic with 8 x SX1301). But you can already set the correct channels you need via remove_channel and add_channel. What's the issue there?

same is other LoRaWAN modules can do.

Sure some modules may do (which ones? I'd like to look at their API) but for example my most deployed module the Laird RM186 and now the RAK811 don't. What they all seem to have in common is they use Semtech's LoRa-Node stack, which is what the LoPy uses as well.

[bmarkus]

@jmarcelino

Thanks for the link. It's OK you can find it in the source, but it is not part of the documentation. For sure I can make a proposal for a method if it is not already made by PyCom Team so let's wait for a response from Daniel first.

What is also important to know and change if necessary the TX2 window settings. E.g. just recently there were changes in Asia/Pacific in TX2 so if you have different settings in your node OTAA will not work. It may vary network by network.

Regarding mandatory channels is also a good question. US915 e.g. is different, on GW side you have 8 channel blocks choosen by network operator, in your node you must set the matching set which can be even 16 channel instead of 8.

All together just using a country name is not enough and need access to channel settings for the application, same is other LoRaWAN modules can do.

[jmarcelino]

@bmarkus
All the LoPy LoRaWAN definitions are set in code form at https://github.com/pycom/pycom-micropython-sigfox/blob/master/lib/lora/mac/LoRaMac-definitions.h, which comes from the "official" Semtech stack which in turns comes from the LoRaWAN Regional Parameters specification.

As you know - or can gather from the document linked above - there are a LOT of parameters in LoRa so it would be helpful if you could share what you'd hope to get from that info_channel function.

Is it just the base default channels? The current configured channels including those added by the server via LoRaMAC commands/OTAA?

What information would you expect? Frequency, data rates available, duty cycle, tx power, receive windows? What are aiming to do with this information?