When using a gateway on a GPRS (or other high latency network) how does TTN cope (or not)?
for example is it able to use the RX2 window when it wouldn’t be possible to make RX1 in time?
1 second for RX1 can be a bit optimistic unless on a DSL connection, 2 seconds for RX2 however is fairly doable.
It does not, I’ve even had problems running it on 3G (400ms round trip (ping) time)
I was just discussing this yesterday on Slack and @htdvisser provided some insight into why
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 (GitHub - Lora-net/packet_forwarder: A LoRa packet forwarder is a program running on the host of a LoRa gateway that forwards RF packets receive by the concentrator to a server through a IP/UDP link, and emits RF packets that are sent by the server.) 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.
@kersing has been working on the packet forwarder for me on a SPI conduit. I think it has JIT scheduling on it
In the current live environment with a recent packet forwarder is it expected to work over 3g? What is the slowest latency expected to work reliably?
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).
A good example of latency problems seems to be “OTAA ok, 12h later I get denied, reboot gateway –> OK again …!?” for which the OTAA Join Accept receive window is at 5 seconds after the Join Request, but still comes in too late for some 3G gateways.