OTAA Join requests failing but only when multiple gateways are visible

End Devices (Nodes)
1

Hi All

I have been experiencing trouble with Murata CMWX1ZZABZ-078 based devices undertaking OTAA Join requests. The join request has been failing around 30% of the time even though the TTN backend reports a successful join.

The interesting part is that they only fail when more than one gateway is visible to the device, if only a single gateway is visible then the join works perfectly every time.

The gateways that are visible in one area in Central London are all Kerlink gateways, however there may be other gateways on other networks that I am not aware of. Other locations with multiple gateways also show the same issue but I don’t know the gateway types and am experiencing the same problem.

Once this failure happens the device is locked out as the radio reports back as busy and doesn’t timeout, I think this is a secondary issue that looks like it may need to be addressed in the stack.

Currently I have a pretty robust workaround and OTAA registration has to happen rarely in a devices lifetime so it’s not too much of an issue

Trouble is I don’t like workarounds or unanswered issues it’s just not tidy and it may come back to haunt me or just keep me up a night asking why over and over again.

I’m afraid I don’t have much knowledge of the detailed workings of the gateways but was wondering what impact multiple gateways could cause to result in the behaviour described above.

Do all or more than one gateway/s respond to Join requests?
Using OTAA do the gateways negotiate connectivity parameters with the device upon joining?
Could another gateway from another network in the vicinity interfere with the TTN gateways?
What could be different between a location with a single gateway as opposed to multiple?

Any ideas, thoughts, explanations, starting points to look would be much appreciated.

Doug

1 Like
3

No, just one,

No. The network (TTN) negotiates parameters, not the gateway. The gateway just sends that response packet to your node.

No. Only TTN has the secret key required to recognize the packet and generate a valid response.

With multiple gateways TTN uses an algorithm to select one of the gateways to send the OTAA response. It could be a gateway is selected which is sub optimal when transmitting. For instance when a gateway receives a packet with excellent signal strength it is likely to be chosen to send the response. If that gateways transmissions are weak due to issues with the antenna or too strong because it is too close to the node the node will not receive the response intact.

1 Like
4

Note that clicking a Join Request in TTN Console will show you the details of all gateways that received the request, including their RSSI and SNR. Given their id’s you might be able to find their owner.

(The MQTT API also allows for monitoring device events such as activations, but that shows the same information as the Join Request in TTN Console, and no details about the Join Accept. It also allows for subscribing to errors, but I’d assume that TTN doesn’t think anything is wrong. ttnctl subscribe shows even fewer details. So I’d say TTN Console suffices here.)

Too bad one cannot tell which gateway is used to transmit the Join Accept if multiple have received the Join Request, unless one owns the selected gateway and can see the Join Accept in its Traffic in TTN Console. (Or unless one owns all others and sees those are not used.)

In case you can investigate:

  • Am I right to assume you do see the Join Request in the application’s Data page in TTN Console, even when they fail? And that, if the join fails, the requests are repeated?

  • Am I right to assume that the presence of a specific gateway in the list of gateways that received the Join Request is the culprit? Or does a totally different area with all different gateways yield the same problem?

  • In case you know which gateway is used for the Join Accept:

    • In a specific area, is it always the same gateway that is selected by TTN for the Join Accept downlink? (It might make sense if TTN would pick another one for repeated join attempts, if only to minimize a gateway’s duty cycle, if such applies to the region, which indeed it does for EU868.)

    • Any chance you can limit the range of the node to make that gateway be the only one that received the Join Request, to see what happens then?

  • What SF is being used?

  • Any difference when increasing the initial SF?

5

Hi All

Thanks for the guidance here, it’s good to learn and get clarity on my understanding. Also thanks for some great ideas on where to look. I think I can get access to the gateways to investigate which one is transmitting the join Accept, It’s going to take time and another trip to London though.

Below are the gateways for interest sake. The RSSI is very high on one of them and as it was in the same room I turned it off to see if it may be having an impact. However no change.

SF factor is at 12 despite having ADR tuned on and a very close gateway but guess that’s off topic

{
  "time": "2019-01-26T09:51:55.393604664Z",
  "frequency": 868.3,
  "modulation": "LORA",
  "data_rate": "SF12BW125",
  "coding_rate": "4/5",
  "gateways": [
    {
      "gtw_id": "eui-0000024b0b030eeb",
      "timestamp": 2484621988,
      "time": "2019-01-26T09:51:55.356933Z",
      "channel": 1,
      "rssi": -115,
      "snr": -11.2,
      "rf_chain": 1,
      "latitude": 51.52402,
      "longitude": -0.10478,
      "altitude": 35
    },
    {
      "gtw_id": "eui-0000024b0b030e31",
      "timestamp": 2479942964,
      "time": "2019-01-26T09:51:55.356932Z",
      "channel": 1,
      "rssi": -78,
      "snr": 11.5,
      "rf_chain": 1,
      "latitude": 51.52856,
      "longitude": -0.12678,
      "altitude": 62
    },
    {
      "gtw_id": "eui-0000024b0b030ed4",
      "timestamp": 2246337652,
      "time": "",
      "channel": 1,
      "rssi": -30,
      "snr": 11.8,
      "rf_chain": 1
    },
    {
      "gtw_id": "eui-0000024b080503d6",
      "timestamp": 2281556140,
      "time": "2019-01-26T09:51:55.356928Z",
      "channel": 1,
      "rssi": -76,
      "snr": 12.5,
      "rf_chain": 1,
      "latitude": 51.52857,
      "longitude": -0.12683,
      "altitude": 50
    }
  ]
}
6

So, the Join Request you’re showing above is in another location, and is still giving you the same problem?

And the one that was in the same room was not selected to transmit the Join Accept? (It is a full gateway, not some single-channel test gateway, right?)

Also when things work just fine with just one gateway? (Some RN2483 modules are known to have issues with SF12.)

(Note that access to the gateway’s Traffic can also be shared by adding “collaborators” in TTN Console.)

1 Like
7

ADR does not work right away. The network need to receive a number of packets to be able to determine the optimal transmission parameters.

A gateway in the same room is always a cause for concern as the signal transmitted by the node and a response transmitted by the gateway may be too powerful for the receiver circuits of the other device resulting in overloading the receiver (which leads to reception errors).

8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.