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