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 12:09] dlr more variables modification |
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 17: | Line 17: | ||
| On a fast network, to target the RX1 window with maximum anticipation, the following configuration must be set: | On a fast network, to target the RX1 window with maximum anticipation, the following configuration must be set: | ||
| - | |Network max. delay up* | |Network max. delay down* | | + | |Network max. delay up | |Network max. delay down | |
| |0| |400| | |0| |400| | ||
| On a slow network, to target the RX2 window with maximum anticipation, the following configuration must be set: | On a slow network, to target the RX2 window with maximum anticipation, the following configuration must be set: | ||
| - | |network max. delay up* | |network max. delay down* | | + | |network max. delay up | |network max. delay down | |
| |0| |1400| | |0| |1400| | ||
| 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> | ||
| - | T0_lns = now - Ndu | + | T0lns = now - Ndu |
| - | T_est = now + T_agg + T_opp + N_dd | + | Test = now + Tagg + Topp + Ndd |
| - | Decision = T_est - T0_lns = N_du + T_agg + T_opp + N_dd < 1000 ? | + | Decision = Test - T0lns = Ndu + Tagg + Topp + Ndd < 1000 ? |
| - | T_tx = now + T_win - N_dd | + | Ttx = now + Twin - Ndd |
| </code> | </code> | ||
| Line 47: | Line 49: | ||
| * ''T0'': packet transmission date by gateway. | * ''T0'': packet transmission date by gateway. | ||
| - | * ''T0_lns'': packet transmission date by gateway estimated by lns. | + | * ''T0lns'': packet transmission date by gateway estimated by lns. |
| * ''now'': packet reception date by LNS. | * ''now'': packet reception date by LNS. | ||
| - | * ''N_du'': //Network max. delay up//: the setting on the dashboard (350ms by default). | + | * ''Ndu'': //Network max. delay up//: the setting on the dashboard (350ms by default). |
| - | * ''T_est'': estimated earliest timestamp for transmission | + | * ''Test'': estimated earliest timestamp for transmission |
| - | * ''T_agg'': Aggregation time: the LNS waits 350ms after the first packet. | + | * ''Tagg'': Aggregation time: the LNS waits 350ms after the first packet. |
| - | * ''T_opp'': Opportunity time: the LNS waits 150ms after the first packet. | + | * ''Topp'': Opportunity time: the LNS waits 150ms after the first packet. |
| - | * ''N_dd'': //Network max. delay down//: the setting on the dashboard (350ms by default). | + | * ''Ndd'': //Network max. delay down//: the setting on the dashboard (350ms by default). |
| * ''Decision'': whether the RX1 window is reachable, 1000ms being the default RX1 value (it can be changed). | * ''Decision'': whether the RX1 window is reachable, 1000ms being the default RX1 value (it can be changed). | ||
| - | * ''T_tx'': the time at which the LNS will send the packet to the gateway. | + | * ''Ttx'': the time at which the LNS will send the packet to the gateway. |
| - | * ''T_win'': 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 71: | Line 75: | ||
| Computation: | Computation: | ||
| - | * ''T0_lns'' assumed is ''09:59:59.846'' by LNS (''now'' minus 350ms ''Ndu''). | + | * ''T0lns'' assumed is ''09:59:59.846'' by LNS (''now'' minus 350ms ''Ndu''). |
| - | * ''T_est'' without push is ''now'' + 350 + 350 = ''10:00:00.896'' | + | * ''Test'' without push is ''now'' + 350 + 350 = ''10:00:00.896'' |
| - | * ''T_est'' with push is ''now'' + 350 + 150 + 350 = ''10:00:01.046'' | + | * ''Test'' with push is ''now'' + 350 + 150 + 350 = ''10:00:01.046'' |
| - | * Decision: ''T_est'' is greater than 1000ms after ''T0'', so RX1 isn't reachable. | + | * Decision: ''Test'' is greater than 1000ms after ''T0'', so RX1 isn't reachable. |
| - | * Decision: ''T_est'' is less than 2000ms after ''T0'', so RX2 is reachable. | + | * Decision: ''Test'' is less than 2000ms after ''T0'', so RX2 is reachable. |
| - | * ''T_tx'' is ''T0_lns'' + 2000 - 350 = ''10:00:01.496'' (time at which the LNS sends the TX message) | + | * ''Ttx'' is ''T0lns'' + 2000 - 350 = ''10:00:01.496'' (time at which the LNS sends the TX message) |
| Behavior: | Behavior: | ||
| - | * The LNS sends the packet at ''10:00:01.496'' (''T_tx''). | + | * The LNS sends the packet at ''10:00:01.496'' (''Ttx''). |
| - | * The packet forwarder receives it at ''10:00:01.708'' (''T_tx+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 | | ||
| - | * The packet forwarder has a delay between the IP packet reception and the TX LoRa frame going out of the radio. This processing delay is around 30-50ms. | + | ++++ |
| + | 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. | ||
| * The computation algorithm above is only for the RX window **decision**. The actual **scheduling** of the packet is done using the ''tmst'' field of the packet forwarder, and adding the corresponding SX1301 ticks to reach the RX1 or RX2 windows. | * The computation algorithm above is only for the RX window **decision**. The actual **scheduling** of the packet is done using the ''tmst'' field of the packet forwarder, and adding the corresponding SX1301 ticks to reach the RX1 or RX2 windows. | ||
| - | * The LNS will try to 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 95: | Line 103: | ||
| Several situations may arise: | Several situations may arise: | ||
| - | * The backhaul is correct (200ms RTT), with default configuration everything works (nominal case with push). | + | * The backhaul is correct (~200ms RTT), with default configuration everything works (nominal case with push). |
| * The backhaul is very good (<100ms RTT), with specific configuration everything works (RX1 target with push). | * The backhaul is very good (<100ms RTT), with specific configuration everything works (RX1 target with push). | ||
| * The backhaul is not good (~800ms RTT), with default configuration the TX messages aren't transmitted. | * The backhaul is not good (~800ms RTT), with default configuration the TX messages aren't transmitted. | ||
| * The backhaul is not good (~800ms RTT), with specific configuration everything works (RX2 target with push). | * The backhaul is not good (~800ms RTT), with specific configuration everything works (RX2 target with push). | ||
| * The backhaul is very bad (>1000ms RTT), and the TX messages aren't transmitted properly. | * The backhaul is very bad (>1000ms RTT), and the TX messages aren't transmitted properly. | ||
| - | * The backhaul is correct (200ms RTT), everything works (nominal case without push). | + | * The backhaul is correct (~200ms RTT), everything works (nominal case without push). |
| ==== Correct backhaul (~200ms RTT) ==== | ==== Correct backhaul (~200ms RTT) ==== | ||
| Line 110: | Line 118: | ||
| ==== Very good backhaul (<100ms RTT) ==== | ==== Very good backhaul (<100ms RTT) ==== | ||
| - | The LNS will target the RX1 depending on the configure network delay. | + | The LNS will target the RX1 depending on the configured network delay. |
| - | The configured delays on the dashboard are set to 0ms and 400ms for network delay up and down. | + | The configured network delays on the dashboard are set to 0ms and 400ms for //Network max. delay up// and //Network max. delay down//. |
| {{:images:326lns_delay_100ms.png|}} | {{:images:326lns_delay_100ms.png|}} | ||
| In this example (0ms/400ms), the RX1 is reachable. | In this example (0ms/400ms), the RX1 is reachable. | ||
| - | If the network delay down had been configured to 100ms, the RX1 window targeted may have been reachable without margin. | + | If the //Network max. delay down// had been configured to 100ms, the RX1 window targeted may have been reachable without margin. |
| - | With default config (350ms/350ms) RX2 window targeted. | + | With default configuration (350ms/350ms), RX2 window is targeted. |
| - | ==== Not good backhaul (800ms RTT) ==== | + | ==== Not good backhaul (~800ms RTT) ==== |
| In this case the RX1 window is not reachable. The RX2 window is also missed, unless the network delay is adjusted. | In this case the RX1 window is not reachable. The RX2 window is also missed, unless the network delay is adjusted. | ||
| - | This is by default with 350ms //Network max. delay down//: | + | //Network max. delay down// is set with the default configuration: |
| {{:images:326lns_delay_800ms_ko.png|}} | {{:images:326lns_delay_800ms_ko.png|}} | ||
| - | In this case the RX2 is missed and the TX packet is dropped. The solution is to change the //Network max. delay up & down// to a value of 0ms & 850ms: | + | In this case the RX2 is missed and the TX packet is dropped. The solution is to change the //Network max. delay up// and //Network max. delay down //to a value of 0ms and 850ms: |
| {{:images:326lns_delay_800ms.png|}} | {{:images:326lns_delay_800ms.png|}} | ||
| Line 135: | Line 143: | ||
| ==== Very bad backhaul (>1000ms) ==== | ==== Very bad backhaul (>1000ms) ==== | ||
| - | In this case the RX1 and RX2 windows are never reachable. Indeed, with an example 1200ms RTT, the delay is: | + | In this case the RX1 and RX2 windows are never reachable. For instance, with a RTT of 1200ms, the delay is: |
| <code>1200 + 350 + 50 + 1200 = 2800ms</code> | <code>1200 + 350 + 50 + 1200 = 2800ms</code> | ||
| - | The RX2 window has to be changed in order for this to work. 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, 2000 (for RX2 target) or 3000ms (for RX1 target) 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. | ||
| ==== Correct backhaul (~200ms RTT) without push ==== | ==== Correct backhaul (~200ms RTT) without push ==== | ||
playground/wiki3/network_delays.1584616167.txt.gz · Last modified: 2020/03/19 12:09 by dlr
Page Tools
