Hello, I’m hoping someone can help clarify the operation between the TTN Router and the Gateway in the following situation:
An end device with ADR enabled joins the network and is in close proximity to a gateway so has it’s SF set to 7. If it’s operating with a BW of 125kHz it’ll transmit and also expect a preamble of approximately 8ms.
When the device next transmits a confirmed packet on the uplink, 1 second later it’ll open it’s RX1 window and look for a preamble for 8ms (indicating the start of the downlink ACK packet).
In this situation am I correct in assuming that if the latency between the TTN Router and the Gateway is greater than 8ms, then the Gateway will start transmitting the preamble on the downlink too late for the end device to receive it, so the device will go back to sleep and miss the ACK?
If so, does the LoRaWAN specification allow configuring a longer preamble in the gateway and devices to allow for large latencies between the Router and Gateway?
You are not correct. The gateway will forward the received LoRaWAN packet to the router immediately when it is received. The router needs to foward any downlink packet to the gateway within the 1 second RX1 window so the gateway has any response packet available before the RX1 window opens.
Ok thanks, so just to clarify, when a downlink ACK is to be sent to a device the Router sends it to the Gateway (within 1 second of receiving the uplink transmission), and the Gateway buffers it then transmits it at exactly the right time the device opens it’s RX1 window?
If so how does the Gateway know when to start the transmission?
The uplink includes a timestamp of the end of the packet with respect to the gateway’s own internal rolling microsecond counter.
The downlink command sent from the network back to the gateway includes the time in the same units when the downlink packet should start.
If you examine the raw data, these will be exactly 1 second (1000000 micro seconds) apart for a normal RX1.
The packet then gets loaded by software into the gateway baseband chip’s hardware where a comparator fires it off when the counter reaches the programmed time.
There’s an added complication, that the gateway hardware can only have a single packet staged. And older versions of the “packet forwarder” software that managed the hardware didn’t respond very well if given transmit requests out of order. So even in cases like join RX2 (which has a six second delay), the network holds onto the downlink request and only pushes it down to the gateway once the time is so late that no 1-second delay RX1 downlink could need to be sent (to some other node) first. It happens though that the current branch of the code has a software queue that sorts packets into the proper order before loading them into the hardware, so for modern packet forwarders this holdover behavior is unecessary. But it’s not a big cost, because if a gateway’s connectivity won’t work in the fraction of a second needed for normal RX1, being able to get a join ack out over a slow internet backhaul isn’t that useful anyway.
TL;DR TTN requires gateways to have relatively low latency Internet connection, but most do except when the provider’s network is “acting up”
