The problem will be on gateways with older forwarders. Those overwrite the last downlink message when they receive a new one
So on busy gateways (we have some of those in the public network) the gateway just keeps overwriting downlink messages, and as a result, nothing arrives
htdvisser [5:38 AM]
We used to send downlink messages to the gateway as soon as they were “available”. So let’s say we are now at t=10. We schedule a join accept at t=15. At t=11, we schedule a downlink at t=12. This should be perfectly valid, but many gateways would now replace the join accept at t=15 with the downlink at t=12, and the join accept at t=15 would be lost
In the worst case (on busy, well located gateways) this would mean that the gateway is constantly replacing the next scheduled downlink message, effectively not sending anything at all
So we reduce this risk by sending the downlink later so that it’s on the gateway only a few hundred milliseconds before transmission time
This issue was fixed in newer versions of the packet forwarder, so if you have access to all gateways in your network, you can just fix it on the gateway side. As the gateways in the public community network are managed by community members who might or might not have the time (or the knowledge) to update their gateways, this is a little different, so we had to solve this on the backend side
We try to avoid RX2 if possible. For RX1 we have 8 channels available, while RX2 is fixed on 1 channel and a very inefficient data rate. Therefore, expect most downlink messages to be sent after 1 second. Losing 400 ms on the slow connection is not ideal, but we can handle it. For now just install the latest packet forwarder from Semtech (https://github.com/Lora-net/packet_forwarder) and we’ll make sure the timing on the server side will be better.
In private networks with this issue, you might want to consider increasing the RX_DELAY to (for example) 5 seconds. That would place RX1 at 5 and RX2 at 6, leaving more than enough time for even a satellite backhaul.
Am I right to assume that when the receive windows are delayed by an additional n seconds, the backend also sends the downlink data to the gateway n seconds later? (It seems downlink data is currently always sent to the gateway 800 ms before the given RX1 or RX2 slot?)
In other words: I’d assume increasing RX_DELAY fixes half of the problem: it helps with slow uplinks (from gateway to TTN), for which the application server gets the uplink late and then does not have enough time to tell TTN if some downlink is needed. But I’d guess it would not fix slow response times (from TTN to gateway).