Timing Diagram and Impact of deduplication_delay and get_downlink_data_delay to sending ACK to lora device receive window


Is there timing diagram to elaborate the impact of get_downlink_data_delay and deduplication_delay on network server to start sending acknowledgement to end device?

Based on your experience, what is the latency introduced by gateway bridge and MQTT broker from network server to gateway, and from gateway to network server?

is the default rx1_delay = 1 second?

There is no such diagram, but:

  • After receiving the first uplink, the NS waits deduplication_delay for other gateways to potentially report the same uplink in order to deduplicate an uplink received by multiple gateways
  • After sending the uplink to the AS, the NS waits get_downlink_data_delay before getting a potential downlink from the queue.

If rx1_delay=1, then the roundtrip must be completed in less than 1 second. Apart from the above parameters, you must take network latency into account. Thus:

GW > NS latency + deduplication delay + get downlink data delay + NS > GW latency must be less than rx1_delay (+ add some small margin for processing, database queries etc…)

1 Like