User Tools
wiki:network_delays
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
wiki:network_delays [2018/07/20 11:15] bdu created |
wiki:network_delays [2018/07/25 09:28] (current) bdu [RX window decision] |
||
|---|---|---|---|
| Line 16: | Line 16: | ||
| 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). | 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). | ||
| + | |||
| + | ==== RX window decision ==== | ||
| So the RX window decision is basically: | So the RX window decision is basically: | ||
| Line 21: | Line 23: | ||
| <code> | <code> | ||
| T0 = now - Ndu | T0 = now - Ndu | ||
| - | T0 + Tagg + Ndd + m < 1000 ? | + | Test = T0 + Tagg + Ndd + hr |
| + | Decision = Test-T0 < 1000 ? | ||
| + | Ttx = T0 + Twin - Ndd | ||
| </code> | </code> | ||
| with: | with: | ||
| - | * ''T0'': packet reception date by the LNS | + | * ''T0'': packet transmission date by gateway. |
| - | * ''Ndu'': uplink "actual": the //real// time it took for the packet to reach the LNS. | + | * ''now'': packet reception date by LNS. |
| + | * ''Ndu'': //Network max. delay up//: the setting on the dashboard (350ms by default). | ||
| + | * ''Test'': estimated earliest timestamp for transmission | ||
| * ''Tagg'': Aggregation time: the LNS waits 350ms after the first packet. | * ''Tagg'': Aggregation time: the LNS waits 350ms after the first packet. | ||
| - | * ''Ddc'': Delay downlink "configured": what is configured as //Network max. delay down// on the dashboard. | + | * ''Ndd'': //Network max. delay down//: the setting on the dashboard (350ms by default). |
| - | * ''Tm'': Margin time: the LNS adds a 50ms margin to add some headroom. | + | * ''hr'': Headroom: the LNS adds a 50ms margin. |
| + | * ''Decision'': whether the RX1 window is reachable, 1000ms being the default RX1 value (it can be changed). | ||
| + | * ''Ttx'': the time at which the LNS will send the packet to the gateway. | ||
| + | * ''Twin'': the time for the target RX window (1000ms by default for RX1). | ||
| - | So for example: | + | === Example === |
| - | * Delay up: 196ms (actual) | + | Inputs: |
| - | * Delay down: 350ms (configured) | + | |
| - | * total: ''196 + 350 + 350 + 50'' = ''946'' | + | |
| - | * Result is less than 1000, so RX1 is reachable. | + | |
| - | * LNS will send the packet at T0+650ms (which is ''1000 - Ddc'') | + | |
| - | * The packet forwarder may receive it at around T0+850ms (assumed 200ms actual downlink delay) | + | |
| - | * The LoRa frame is sent at T0+1000ms (RX1 window start) | + | |
| - | Please note also that 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. | + | * Delay up: ''350ms'' (configured). |
| + | * Delay up: ''196ms'' (actual). | ||
| + | * Delay down: ''350ms'' (configured). | ||
| + | * Delay down: ''212ms'' (actual). | ||
| + | * Packet sent at ''10:00:00.000'' by gateway (//actual// ''T0'', but not the value computed by LNS). | ||
| + | * Packet received at ''10:00:00.196'' by LNS (''now''). | ||
| - | Hence, 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. | + | Computation: |
| + | |||
| + | * ''T0'' assumed is ''09:59:59.846'' by LNS (''now'' minus 350ms ''Ndu''). | ||
| + | * ''Test'' is ''T0'' + 350 + 350 + 50 = ''10:00:00.596'' | ||
| + | * Decision: ''Test'' is less than 1000ms after ''T0'', so RX1 is reachable. | ||
| + | * ''Ttx'' is ''T0'' + 1000 - 350 = ''10:00:00.496'' (time at which the LNS sends the TX message) | ||
| + | |||
| + | Behavior: | ||
| + | |||
| + | * The LNS sends the packet at ''10:00:00.496'' (''Ttx''). | ||
| + | * The packet forwarder receives it at ''10:00:00.708'' (''Ttx+212ms''). | ||
| + | * The LoRa frame is sent at ''10:00:01.000'' when the RX1 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. | ||
| + | * 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. | ||
| ===== Actual behaviors ===== | ===== Actual behaviors ===== | ||
| Line 50: | Line 75: | ||
| Several situations may arise: | Several situations may arise: | ||
| - | * the backhaul is very good (<100ms RTT), everything works (nominal case) | + | * The backhaul is very good (<100ms RTT), everything works (nominal case). |
| - | * the backhaul is fair (300ms RTT), but the RX1 window is sometimes missed | + | * The backhaul is fair (300ms RTT), but the RX1 window is sometimes missed. |
| - | * the backhaul is not good (>500ms RTT), and the TX messages aren't transmitted properly | + | * The backhaul is not good (>500ms 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 very bad (>1000ms RTT), and the TX messages aren't transmitted properly. |
| ==== Very good backhaul (<100ms RTT) ==== | ==== Very good backhaul (<100ms RTT) ==== | ||
| Line 112: | Line 137: | ||
| So basically, if there is no traffic, the first connection may take up to 1000ms. Subsequent connections are faster, like 100 or 200ms. | So basically, if there is no traffic, the first connection may take up to 1000ms. Subsequent connections are faster, like 100 or 200ms. | ||
| + | |||
| + | ==== Solutions ==== | ||
| One way to circumvent this is to run a periodic ping on the gateway, this will keep the network connectivity in DCH state with a low latency. The downside is that this generates a lot of data traffic, that may be charged a premium by the mobile ISP. | One way to circumvent this is to run a periodic ping on the gateway, this will keep the network connectivity in DCH state with a low latency. The downside is that this generates a lot of data traffic, that may be charged a premium by the mobile ISP. | ||
| Another way to work around this is to configure a 1000ms //Network max. delay up// and a 200ms //Network max. delay down//. This will allow the LNS to finely compute the delays, and be able to reach the RX2 window. | Another way to work around this is to configure a 1000ms //Network max. delay up// and a 200ms //Network max. delay down//. This will allow the LNS to finely compute the delays, and be able to reach the RX2 window. | ||
wiki/network_delays.1532078123.txt.gz · Last modified: 2018/07/20 11:15 by bdu
Page Tools
