TTIG does not support downlinks when not frequently receiving uplinks?

[arjanvanb (Arjan)]

Indeed, it’s quite likely that downlinks might arrive too late (or might not even be delegated to the TTIG by the backend?) when a TTIG is not receiving a lot of traffic:

@KrishnaIyerEaswaran2

In response to the "flashing green LED " question:

Yes that’s normal behavior.

If there’s no traffic on your gateway for about 60s, the WebSocket(WS) connection to the network is dropped intentionally and the gateway will re-connect. During reconnection, the LED will flash green.

The reason for this to not have gateways actively connected to the network and taking up resources when there’s no traffic (since WS requires a persistent connection).

…to which @tchenier already responded:

@tchenier

wouldn’t the Downlink listen window on the device be missed because of the large time delay between Uplink transmit and when the TTN servers received it? Therefore, unless another active gateway is in the area, you’d never be able to get a Downlink packet to the device.

This includes confirmed uplinks and ADR (after 1 or 2 seconds), and less likely the very first OTAA Join Accept (after 5 or 6 seconds). Given its indoor use, it’s quite likely that it’s not receiving many packets from other users?

A summary of some problems discussed hidden in other topics:

• Some report it is not buffering the uplink:

  @Wimfish

  the packet is simply lost… shouldn’t that gateway buffer the packet it recieves, connect to websocket, and send it?

• …but others see it being sent, but much later, showing “retry” for uplinks that are actually only sent once:

  @pe_t_er

  I noticed that it takes ~2 seconds when the packet was received by the TTIG till it starts a new WS connection and another second till the connection is established and the packet get’s send. If the packet is received by multiple gateways deduplication doesn’t work anymore and the packet shows up as “retry” in the TTN console.

• Also, it seems it might cause uplinks to go missing if it’s already reconnecting:

  @wrldtvlr

  Is there any chance the TTIG aggressive disconnect/reconnect logic could be relaxed a little?

  I have a single TTIG that I use for testing various end nodes. One node in particular reports once an hour. It’s the only Lora device around and there are no other gateways in reach. The problem is that if the TTIG is in the middle of reconnecting, it seems to drop or not hear the node. This happens quite frequently.

• Like also mentioned by @Vaelid above, this seems to affect ADR:

  @tkerby

  I can only conclude that the TTIG doesn’t do well with ADR if it doesn’t get a packet from anything within 30 seconds. This is because it seems to do a store and forward of the received packet while it reconnects to TTN and thus will miss the downlink slot.

I don’t know if there’s any GitHub project where this might be/have been reported on? (I don’t see it on, e.g., The Things Network · GitHub, The Things Products · GitHub, The Things Industries · GitHub, or maybe it is part of GitHub - lorabasics/basicstation: LoRa Basics™ Station - The LoRaWAN Gateway Software ?)