User Tools
playground:wiki3:network_delays
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
playground:wiki3:network_delays [2020/03/19 17:33] dlr [Samples of configuration] |
playground:wiki3:network_delays [2023/05/16 14:23] (current) ehe created |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Network Delays configuration ====== | + | ====== Network delays configuration ====== |
| - | Network Delay configuration helps target the RX1 window when sending TX messages to an end device. | + | Network delays configuration helps target the RX1 window when sending TX messages to an end-device. |
| It also allows adaptation to networks with high latency. | It also allows adaptation to networks with high latency. | ||
| Line 33: | Line 33: | ||
| If a push is configured for the cluster, the LNS server will wait 150 ms after the push, in order to offer the client the opportunity to reply to the message in the following RX window. | If a push is configured for the cluster, the LNS server will wait 150 ms after the push, in order to offer the client the opportunity to reply to the message in the following RX window. | ||
| - | It will then try to see which window is best to send the TX message to the end-device. To do so, it will add the //network delay down// to the current time, and see if this fits, with an additional 50ms margin. If this allows to reach the RX1 window delay (usually one second), then it will send it soon. If this doesn't allow to reach the RX1 window, it will target the RX2 window (usually two seconds). | + | The LNS will then choose the best RX window to send the TX message to the end-device. To do so, it will add the //Network max delay down// to the current time, and see if this fits, with an additional 50ms margin. If this allows to reach the RX1 window delay (usually one second), then it will send it soon. If this doesn't allow to reach the RX1 window, it will target the RX2 window (usually two seconds). |
| - | ++++ RX window decision method | | + | |
| + | ++++ | ||
| + | RX window decision method | | ||
| <code> | <code> | ||
| T0lns = now - Ndu | T0lns = now - Ndu | ||
| Test = now + Tagg + Topp + Ndd | Test = now + Tagg + Topp + Ndd | ||
| - | Decision = Test-T0lns = Ndu + Tagg + Topp + Ndd < 1000 ? | + | Decision = Test - T0lns = Ndu + Tagg + Topp + Ndd < 1000 ? |
| Ttx = now + Twin - Ndd | Ttx = now + Twin - Ndd | ||
| </code> | </code> | ||
| Line 58: | Line 60: | ||
| * ''Twin'': the time for the target RX window (1000ms by default for RX1). | * ''Twin'': the time for the target RX window (1000ms by default for RX1). | ||
| ++++ | ++++ | ||
| - | ++++ Example | | + | |
| + | ++++ | ||
| + | Example | | ||
| Inputs: | Inputs: | ||
| Line 81: | Line 85: | ||
| * The LNS sends the packet at ''10:00:01.496'' (''Ttx''). | * The LNS sends the packet at ''10:00:01.496'' (''Ttx''). | ||
| - | * The packet forwarder receives it at ''10:00:01.708'' (''Ttx+212ms''). | + | * The packet forwarder receives it at ''10:00:01.708'' (''Ttx'' + 212ms). |
| * The LoRa frame is sent at ''10:00:02.000'' when the RX2 window opens. Actual timing is done with ''tmst'' (SX1301 clock counter). | * The LoRa frame is sent at ''10:00:02.000'' when the RX2 window opens. Actual timing is done with ''tmst'' (SX1301 clock counter). | ||
| ++++ | ++++ | ||
| - | ++++ Notes | | + | |
| + | ++++ | ||
| + | Notes | | ||
| * Due to the packet forwarder processing time, a delay of 30ms to 50ms occurs between the IP packet reception and the TX LoRa frame going out of the radio. | * Due to the packet forwarder processing time, a delay of 30ms to 50ms occurs between the IP packet reception and the TX LoRa frame going out of the radio. | ||
| Line 90: | Line 96: | ||
| * The LNS will keep the TX messages for as long as possible, and send them at the last moment. This is by design, to allow less load on the packet forwarders. Indeed, if the TX messages were sent as soon as possible, the gateways might get a lot of TX messages queued, which would be problematic on embedded devices. | * The LNS will keep the TX messages for as long as possible, and send them at the last moment. This is by design, to allow less load on the packet forwarders. Indeed, if the TX messages were sent as soon as possible, the gateways might get a lot of TX messages queued, which would be problematic on embedded devices. | ||
| ++++ | ++++ | ||
| + | |||
| + | |||
| ===== Actual behaviors ===== | ===== Actual behaviors ===== | ||
| Line 139: | Line 147: | ||
| <code>1200 + 350 + 50 + 1200 = 2800ms</code> | <code>1200 + 350 + 50 + 1200 = 2800ms</code> | ||
| - | On each end-device, and on the dashboard configuration of the end-device, the RX1 window delay has to be adjusted to a greater value. For example, setting RX1 to 2000ms (to reach the RX2 window) or 3000ms (to reach the RX1 window) is fine. | + | The RX1 window delay has to be adjusted to a greater value on each end-device, and on the WMC end-devices configuration interface. For example, setting RX1 to 2000ms (to reach the RX2 window) or 3000ms (to reach the RX1 window) is fine. |
| - | + | ||
| - | Indeed, the delay calculated above is 2800ms, so if RX1 delay is 3000ms, it is reachable. | + | This solution is possible at the cost of provisioning every end-devices of the network, so that it can work with high latencies. This network configuration is useful with satellite backhaul, for example. |
| - | + | ||
| - | This is possible at the cost of provisioning every end-device on the network so that it can work with high latencies. This can be useful with satellite backhaul, for example. | + | |
playground/wiki3/network_delays.1584635631.txt.gz · Last modified: 2020/03/19 17:33 by dlr
Page Tools
