How join Accept depends on frequencies in region EU868?

ChirpStack Network Server
1

Thanks in advance for your support.
I want to share with the community some strange behaviours when chirpstack handle join Requests.

Context

End nodes work according to LoRaWAN 1.0.2 protocol.
This standard version states that end devices SHALL use the following frequencies when handling join requests:

  • 868100000 Hz
  • 868300000 Hz
  • 868500000 Hz

Behaviour

The join request was initiated in an end node to evaluate the actual behaviour. This node was sending join requests among 8 different frecuency channels, the three default ones and

  • 867100000 Hz
  • 867300000 Hz
  • 867500000 Hz
  • 867700000 Hz
  • 867900000 Hz

After some repetitions, the general behaviour was according to the referenced standard: only sending join accept to frames sent through default channel frequencies. However, I can report a couple non-supported cases:

First case

The first case shows a received join request with a valid channel frequency that should be accepted but that was never done. Every test was performed with the same app session keys so they would not be a problem.

Second case

The second case shows a received join request with an invalid channel frequency that should be rejected but that was accepted.

Questions

  • What checks are performed on the network server for accepting join requests?
  • Why I saw this behaviour?

Thanks in advance.

2

That could be anything. E.g. packet-loss, repeated DevNonce etc… Check the logs for more info.

The second case shows a received join request with an invalid channel frequency that should be rejected but that was accepted.

ChirpStack doesn’t check that the join-request was received on 868.1, .3 or .5. There is no need for this as these additional channels are valid in your configuration, otherwise the gateway wouldn’t have received them. What could be is that the device caches the additional channels it received during a previous activation.

3

Thanks brocaar for your answer.

Then, I understand ChirpStack caches join request messages and eventually accepts these invalid joins, invalid due to specification, sent through non valid frequencies for join requests. Is it correct?

The specification, for EU868, says:

image

Just to clarify the behaviour:

  • Does chirpstack eventually answers join requests that were sent through non-specified frequencies?
  • What was the reason to implement that functionality?
  • How could it be taken in advance to speed up the join request - join accept process?
  • Does it happens in every lora region?

Thanks in advance.

4

Just to explain this a bit more, all EU868 networks must implement 868.1, 868.3 and 868.5. This are the minimum required channels. However, most networks also support 5 (or sometimes more) additional channels: 867.1, 867.3, … 867.9.

In the specification you will find that the device shall use the 868.1, 868.3 and 868.5 channels for OTAA, to make sure that the device is able to activate on all networks (as the other channels are up to the network provider to decide).

If your network supports the above extra channels (which are usually the defaults in many configs) for OTAA, then there is absolutely no reason for ChirpStack to reject such join-request and it will happily process such request. It is not a feature that I added, I would actually need to add code to reject such join-requests.

The risk is however when you move your device to an other operator which does not support these channels that when your device sends a join-request, the message is lost as their gateways won’t receive it.

Again, it could be that your device once it received the additional channels (as part of the join-accept) caches these and (incorrectly) uses these for the next join-request. It could be that a power-cycle would flush this cache, but that really depends on the device firmware.

1 Like