Channel List in the Join accept message

[coljander]

In the EU version as a test I've centered Radio_1 on 869.5MHz in the gateway. This produces frequencies of 869.1/3/5/7/9. All of these frequencies lie within an allowed ETSI band.

When I receive the Join Accept message It contains the Channel List containing the above frequencies. However when I check the channel list at the end of the routine 869.3MHz is missing. The frequency is set to 0 and the ChannelsMask is updated accordingly.

The reason for this is that in function LoraMacChannelAdd() there is no band that this frequency sits in. It would fit in the 863-870MHz band but this has been reduced to 865-868MHz so that the duty cycle can be increased to 1% from 0.1% if the full band is used.

Is this something we just have to accept for the increased duty cycle is a gateway uses this center frequency? Is that the reason for the frequency bands being as they are?

[mluis1]

The current LoRaWAN implementation is ETSI compliant. The European band is indeed 863-870 MHz but not every frequency in this range can be used. Some frequencies in that range are for example reserved for alarm systems.

The ETSI document EN 300 220 Table 5 describes the frequencies ranges that can be used or not.

I have also attached a document describing the Semtech recommended LoRaWAN channel line-up that complies with the ETSI regulations LoRaWAN_Ch_Lineup_V0.6.zip

[coljander]

Thanks. Those documents are very useful. My only reference has been the ETSI table in the LoRaWan spec.

However this has raised another question. According to the LoRaWanspec the DateRate for 868.3MHz should be DR0 to DR5. In LoRaMac-board.h the max Datarate for this frequency, LC2, is defined in the structure as DR_6. I notice that the IBM code also suggests that this channel should have a datarate of 6. I just can’t find where in the spec it is allowed for.

Also when we receive an ADR message from the gateway we are currently using, Multitech, it sets the Datarate to DR6, SF7@250kHz. In SetNextChannel() the min and max datarate for each channel is checked against this new value. So all our channels are discarded with the exception of LC2 and so we would only ever transmit on this channel. This doesn’t seem right.

I would have thought that provided the datarate was less than a maximum datarate then that channel should be allowed to transmit (provided it met the other criteria). In this case the value sent in the ADR message would be the maximum value. Again the spec isn’t very clear on this.

Is this line correct?

                if( ( ( Channels[i + j].DrRange.Fields.Min <= ChannelsDatarate ) &&
                      ( ChannelsDatarate <= Channels[i + j].DrRange.Fields.Max ) ) == false )

Should it be?

                if( ( ( Channels[i + j].DrRange.Fields.Min <= ChannelsDatarate ) &&
                      (Channels[i + j].DrRange.Fields.Max <= ChannelsDatarate) ) == false )

[mluis1]

The SX1301 chip (gateway) has 8 modems that are able to handle SF2BW125 (DR0) up to SF7BW125 (DR5) datarates it has also one modem to handle the SF7BW250 (DR6) and one modem to handle the FSK (DR7) datarates.

This is why only 1 channel is enabled when a device uses DR6 datarate in your case (also applies for DR7).

If for some reason the end-device datarate is lowered to a datarate between DR0 up to DR5 then the 8 normal channels will be used depending on the channel mask currently being used. (A modem corresponds to a channel frequency)

The high speed modems can be set to the same frequencies as the ones used by the 8 low speed modems. The LoRa datarates are orthogonal between them and the FSK modulation isn't disturbed by LoRa modulation.

The IBM code and LoRaMac-board.h setup the 868.3 MHz channel up to DR6 due to historical reasons. At the beginning it was even up to DR7. We will change the LoRaMac-board.h file in order to better reflect the LoRaWAN specification.

The channels definition on the specification must be seen as the minimum setup that all devices must support. Nothing prevents you to setup one of the default channels to handle higher datarates.

I guess that the current end-device implementation handles all these questions correctly.

[coljander]

Thanks for the explanation. Things are starting to be a bit clearer now, however I’d just like to clarify a couple of points.

Firstly, when the gateway sets the datarate to DR6 only a single channel should then transmit data to the gateway. How is that channel defined? At the moment in your code only LC2 is set for DR6. However unless the gateway is also set up for this frequency then any packets transmitted on that frequency will be lost? And that is the scenario we are seeing. We have a mismatch between the end device and the gateway.

I’ve looked at our gateway config and in the global_conf.json file I can see the following settings

            "chan_FSK" :
            {
                    "bandwidth" : 250000,
                    "datarate" : 50000,
                    "enable" : true,
                    "freq_deviation" : 25000,
                    "if" : 25000,
                    "radio" : 1
            },
            "chan_Lora_std" :
            {
                    "bandwidth" : 250000,
                    "enable" : true,
                    "if" : 25000,
                    "radio" : 1,
                    "spread_factor" : 7
            },

So the SF7@250kHz channel seems to be at Radio_1 + 25kHz.

This is not a standard frequency and is not configured in the end device code. So how does it get there? We can’t hardcode this value as we don’t know what gateway a user will be using or how it is configured. Therefore the gateway must send us that information. It isn’t available in the ADR command so should we be expecting to see a NewChannleReq command to set up that channel dynamically?

You wrote

“The channels definition on the specification must be seen as the minimum setup that all devices must support. Nothing prevents you to setup one of the default channels to handle higher datarates.” Again this implies that unless we set up the code differently for a specific gateway where we already know the high speed channel in advance, there has to be some facility for dynamically setting a new channel. Either through the NewChannleReq command form the gateway or via a run time config option?

[mluis1]

Could you please remove the previous messages when you reply to the mail? It is just for a question of clarity.

I don't know what is your gateway setup. But, if you take a look to the packet_forwarder global_conf.json file example you will notice the following:

...
        "radio_0": {
            "enable": true,
            "type": "SX1257",
            "freq": 867500000,
            "rssi_offset": -166.0,
            "tx_enable": true
        },
        "radio_1": {
            "enable": true,
            "type": "SX1257",
            "freq": 868500000,
            "rssi_offset": -166.0,
            "tx_enable": false
        },
...
"chan_multiSF_1": {
            /* Lora MAC channel, 125kHz, all SF, 868.3 MHz */
            "enable": true,
            "radio": 1,
            "if": -200000
        },
...
 "chan_Lora_std": {
            /* Lora MAC channel, 250kHz, SF7, 868.3 MHz */
            "enable": true,
            "radio": 1,
            "if": -200000,
            "bandwidth": 250000,
            "spread_factor": 7
        },
        "chan_FSK": {
            /* FSK 50kbps channel, 868.8 MHz */
            "enable": true,
            "radio": 1,
            "if": 300000,
            "bandwidth": 125000,
            "datarate": 50000
        },
...

Thus, the chan_Lora_std modem uses the same frequency as the chan_multiSF_1 modem. In this case 868.3 MHz

Normally It is up to the server to setup the missing channels using the NewChannelReq MAC command.

The specification only mandates that all end-devices need to have the 3 default channels defined. All other channels must be add either by

1. The server
2. Setup in the end-device at manufacturing according to a specific channel plan.

Please note that the server can always change dynamically (when supported) the channel plan over the air even if the end-device already had channels defined at manufacturing.

Currently not all server implementations create the additional channels over the air using the MAC command. In those cases you may need to setup the supported channels into the end-device.

[nkaramolegos]

Thanks mluis1 for your useful help. You said that the server can always change dynamically the channels. This means that can instruct the node for example to change the frequency of channel with id 3 to another frequency?