Gateway-profile enabled channels / LoRa Server extra channels


Yes, that is correct (or it will use the CFList on OTAA join).


i’m a little bit lost with this topic:

I have my enabled_uplink_channels = [] in the loraserver.toml
No extra channels.

No gateway profile (not a good idea i know) but it seem that everything works with the default Mac address in global_conf.json.

And when i’m connecting one of my end device, which is using 8 channels, i received every frames that i send :confused:

I’m using the EU_Band and i really don’t understand what is the point of the enabled_uplink_channels field in loraserver.toml :confused:

Thanks in avance :slight_smile:


To give you and example which would apply to the US915 band:

By default there are 64 + 8 uplink channels defined for the US band. Most devices only support 8 + 1 channels. Therefore a devices will hop over all 64 channels for OTAA activation, this means there will be packet-loss initially. By configuring the enabled_uplink_channels to for example channels 0 - 7, LoRa Server knows which channel-mask to send to your device. Either using the LinkADRReq channel-mask, or the CFList channel-mask (LoRaWAN 1.1).

On other words, when configured correctly it gives LoRa Server the information how to configure your device through mac-commands (or the CFList in LoRaWAN1.1).

The gateway-profile gives LoRa Server the information how to configure your gateway(s).

Of course the channel-configuration in loraserver.toml and the gateway-profiles (must be used together with the LoRa Gateway Bridge!) must overlap.

It does not restrict LoRa Server in which frames are accepted. All frames received are processed (when they contain valid data).


Ok i think i get it ! :slight_smile:

Just to be sure, in ABP mode, in the device profile, should i enter every channels wich the device use?
And the channel-configuration and the gateway-profiles does not affect the ABP mode, it’s only to expand the OTAA capabilities.

Am i right?


And the channel-configuration and the gateway-profiles does not affect the ABP mode, it’s only to expand the OTAA capabilities.

Only the channel-configuration. The gateway-profiles are only there to configure your gateways. It doesn’t change the way how LoRa Server is operating.

(e.g. when you configure 16 channels in LoRa Server and only configure 8 channels in your gateway-profile and LoRa Gateway Bridge is configured to reconfigure the packet-forwarder then you basically have a malfunctioning network as you will have packet-loss on 8 channels).


It’s a little bit hell in my brain now :confused:
If i configure my loraserver.toml to get 8 channels (3 default EU + 5 extra) and i configure 8 channels in my gateway profile, i will not have mismatch?

But, if i want to use 16 channels, i have to configure the 16 channels in the loraserver.toml and create 2 gateway profiles (i’m using the IC880A so i can listen only 8 channels) , i will be able to listen all of 16 channels?

I’m not sure that the lora-gateway bridge is reconfiguring the packet forwarder, how can i check that?


Have you seen this documentation? If this is not clear, please let me know how it can be improved :slight_smile:

Again: the gateway-profile only affects the gateway itself. With or without gateway-profiles, LoRa Server operates the same. It is just an easy way to push the same config (gateway-profile) to a group of gateways, instead of updating each gateway individually.


If I understand correctly, the channel mask sent to the end devices (as configured in the loraserver.toml file) is independent of the gateway channel configuration. In which case, a network that contains both 8 channel and 16 channel gateways wouldn’t work very well.

For example if you configure the loraserver.toml to use only 8 out of the 16 possible channels then there will never be lost uplinks, but half of the channels on the 16 channel gateways would be unused.

Alternatively, if the end devices are configured to use 16 channels, then when they are only around 8 channel gateways half of their uplinks will be lost.

Is there any way around this?


That is correct.

Please note that it also allows you to for example configure 50% of your gateways on channels 0-7 and the other 50% on 8-15 when you have a dense network of gateways or any other kind of mix that you can think of :slight_smile:


That would definitely work for a dense network. But the network I am working on will be quite sparse with only 1-2 gateways in range for most up links. I think the only solution is to limit all of the devices to 8 channels.


Could you please explain how to setup the lora gateway bridge? You’ve mentioned setting up gateway channels using the gateway-profile in the web interface. And this is to be consistent with enabled_uplink_channels[] in loraserver.toml. What needs to be done in lora-gateway-bridge.toml?

I have tried uncommenting [[packet_forwarder.configuration]] and uncommenting mac=‘gatewaymac’. The logs says “apply configuration error” error=“load config file error: read file error: open : no such file or directory”.



You must also uncomment and configure base_file, output_file and restart_command. LoRa Gateway Bridge will then read the base_file merges the configuration from the Gateway Profile and writes this as output_file after which it executes restart_command.


The use of
base_file="/etc/lora-packet-forwarder/global_conf.json" and
output_file="/etc/lora-packet-forwarder/local_conf.json" has me confused.

Do i need to create these files first so they can be found? I see an error in the logs: “…/global_conf.json: no such file of directory”. Does global_conf.json already exist elsewhere and I need to enter a different path?
Once local_conf.json has been written to, does it need to be copied to the gateway manually?



First of all, this only works when you run the LoRa Gateway Bridge on the gateway. The idea here is to automate the configuration update & restart :slight_smile:

Usually the Semtech packet-forwarder comes with a couple example configurations for your gateway. These you can use as base_file. The output_file usually is named local_conf.json.

The Semtech packet-forwarder will first read the global_conf.json after which it also applies configuration found in local_conf.json. You will find more information here:


I’m Using Kerlink IBTS compact. The packet forwarder used by it is spf2:
Its current configuration is like this:

{ “SX1301_array_conf”: [
“board_type”: “MASTER”,
“board_rx_freq”: 903800000,
“board_rx_bw”: 4000000,
“full_duplex”: false,
“rf_chain_conf”: [
“rx_enable”: true,
“tx_enable”: true,
“tx_freq_min”: 923300000,
“tx_freq_max”: 927500000
“SX1301_conf”: [
“chip_enable”: true,
“chip_center_freq”: 903000000,
“chip_rf_chain”: 0,
“chan_multiSF_0”: { “chan_rx_freq”: 902300000, “spread_factor”: “7-10” },
“chan_multiSF_1”: { “chan_rx_freq”: 902500000, “spread_factor”: “7-10” },
“chan_multiSF_2”: { “chan_rx_freq”: 902700000, “spread_factor”: “7-10” },
“chan_multiSF_3”: { “chan_rx_freq”: 902900000, “spread_factor”: “7-10” },
“chan_multiSF_4”: { “chan_rx_freq”: 903100000, “spread_factor”: “7-10” },
“chan_multiSF_5”: { “chan_rx_freq”: 903300000, “spread_factor”: “7-10” },
“chan_multiSF_6”: { “chan_rx_freq”: 903500000, “spread_factor”: “7-10” },
“chan_multiSF_7”: { “chan_rx_freq”: 903700000, “spread_factor”: “7-10” },
“chan_LoRa_std”: { “chan_rx_freq”: 903000000, “bandwidth”: 500000, “spread_factor”: 8 }
“chip_enable”: true,
“chip_center_freq”: 904600000,
“chip_rf_chain”: 0,
“chan_multiSF_0”: { “chan_rx_freq”: 903900000, “spread_factor”: “7-10” },
“chan_multiSF_1”: { “chan_rx_freq”: 904100000, “spread_factor”: “7-10” },
“chan_multiSF_2”: { “chan_rx_freq”: 904300000, “spread_factor”: “7-10” },
“chan_multiSF_3”: { “chan_rx_freq”: 904500000, “spread_factor”: “7-10” },
“chan_multiSF_4”: { “chan_rx_freq”: 904700000, “spread_factor”: “7-10” },
“chan_multiSF_5”: { “chan_rx_freq”: 904900000, “spread_factor”: “7-10” },
“chan_multiSF_6”: { “chan_rx_freq”: 905100000, “spread_factor”: “7-10” },
“chan_multiSF_7”: { “chan_rx_freq”: 905300000, “spread_factor”: “7-10” },
“chan_LoRa_std”: { “chan_rx_freq”: 904600000, “bandwidth”: 500000, “spread_factor”: 8 }
“FSK_sync”: “C194C1”,
“loramac_public”: true,
“nb_dsp”: 1,
“dsp_stat_interval”: 10,
“dsp_stat_interval”: 10,
“aes_key”: “ABCDEF0123456789ABCDEF0123456789”,
“fts_match_crc_error”: false,
“fts_version”: 1
“gateway_conf”: {
“server_address”: “XXXXXXX”,
“serv_port_up”: XX,
“serv_port_down”: XX,
“keepalive_interval”: 10,
“stat_interval”: 30,
“push_timeout_ms”: 100,
“forward_crc_valid”: true,
“forward_crc_error”: false,
“forward_crc_disabled”: false,
“autoquit_threshold”: 3

The Gateway Bridge, installed in the server, is default.

The LoRaServer is configured to US915:

/Device session expiration.

/ Get downlink data delay.

/ LoRaWAN regional band configuration.
/ LoRaWAN band to use.

/ Enforce 400ms dwell time

/ Enforce repeater compatibility

/ LoRaWAN network related settings.
/ Installation margin (dB) used by the ADR engine.

/ RX window (Class-A).

/ Class A RX1 delay

/ RX1 data-rate offset

/ RX2 data-rate

/ RX2 frequency

/ Downlink TX Power (dBm)

/ Disable mac-commands

/ Disable ADR

/ Enable only a given sub-set of channels

/ Extra channel configuration.
/ Example:
/ [[network_server.network_settings.extra_channels]]
/ frequency=867100000
/ min_dr=0
/ max_dr=5

/ [[network_server.network_settings.extra_channels]]
/ frequency=867300000
/ min_dr=0
/ max_dr=5

/ [[network_server.network_settings.extra_channels]]
/ frequency=867500000
/ min_dr=0
/ max_dr=5

/ [[network_server.network_settings.extra_channels]]
/ frequency=867700000
/ min_dr=0
/ max_dr=5

/ [[network_server.network_settings.extra_channels]]
/ frequency=867900000
/ min_dr=0
/ max_dr=5

/ Class B settings
/ Ping-slot data-rate.

/ Ping-slot frequency (Hz)
/ Set this to 0 to use the default frequency plan for the configured region
/ (which could be frequency hopping).

/ Rejoin-request settings
/ When enabled, LoRa Server will request the device to send a rejoin-request
/ every time when one of the 2 conditions below is met (frame count or time).
/ Request device to periodically send rejoin-requests

/ The device must send a rejoin-request type 0 at least every 2^(max_count_n + 4)
/ uplink messages. Valid values are 0 to 15.

/ The device must send a rejoin-request type 0 at least every 2^(max_time_n + 10)
/ seconds. Valid values are 0 to 15.
/ 0 = roughly 17 minutes
/ 15 = about 1 year

/ Scheduler settings
/ These settings affect the multicast, Class-B and Class-C downlink queue
/ scheduler.
/ Scheduler interval
/ The interval in which the downlink scheduler for multicast, Class-B and
/ Class-C runs.

/ Class-C settings.
/ Downlink lock duration
/ Contains the duration to lock the downlink Class-C transmissions
/ after a preceeding downlink tx (per device).

I had setup gateway-profiles considering only 8 channels, but I saw that my Gateway; while receiving messages in the 8 channels, it didn’t send the Downlink (Unconfirmed/Confirmed) messages. So I deleted my Gateway profile from the Gateway, and Left it as is. Also; reading some of your posts, you mentioned that ONLY use a Gateway profile in case the LoRa-Gateway_bridge is found inside the Gateway, which isn’t the case here.


So I ask, must I perform another configuration? Do you any recommendation/discouragment?

Another thing, our gateway supports 16 channels, but I understand I can only use 8. Is that right?
Can’t I use the other channels?