Maybe Loriot sends the response a lot earlier than TTN. I imagine there may be several reasons why TTN is sending instructions to gateways as late as possible:
- It allows TTN to choose another gateway as late as possible, or change the RX window to allow more urgent responses for other nodes to be sent.
- It allows TTN to drop responses and downlinks for nodes that have exceeded the (future) fair access policy, in favor of responding to nodes that have used less air time.
- Maybe TTN assumes that gateways do not implement a queue of packets to be transmitted? (And that is probably true for most gateways, as gateways are often referred to as “packet forwarders”.) By only sending the packets to the gateway when they are about to be transmitted, TTN can still add newer responses for other nodes, that are to be sent earlier. (Like: a Join Accept is to be sent after either 5 or 6 seconds, while a regular downlink is to be sent after 1 or 2 seconds. If no queue is implemented then the gateway could not be used for any other transmissions between receiving the Join Accept and actually transmitting it.) I’m just assuming things here.
If Loriot is sending responses much earlier than TTN, then that might solve your problem now, but might be troublesome when the network usage increases. Again: I’m just guessing here.
So: with Loriot, how soon exactly do you receive responses on the gateway?
Yes, of course limited by the specification: for the OTAA Join Accept itself these are fixed. One should surely not set any specific RX2 channel before performing the OTAA Join.
After OTAA, in the configuration as sent in the Join Accept, TTN tells the nodes which channel and spreading factor is used for RX2. (That only applies to regular downlinks.) For ABP one needs to configure that manually, for OTAA one should not.
Yes, but like Kersing explained earlier: relative to the tmst value in the request:
That said, if OTAA is working then problems with regular downlinks are not in scope of this topic, I feel.