User Tools
wiki:network_delays
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
wiki:network_delays [2018/07/20 11:34] bdu [RX window decision] |
wiki:network_delays [2018/07/25 09:28] (current) bdu [RX window decision] |
||
|---|---|---|---|
| Line 36: | Line 36: | ||
| * ''Tagg'': Aggregation time: the LNS waits 350ms after the first packet. | * ''Tagg'': Aggregation time: the LNS waits 350ms after the first packet. | ||
| * ''Ndd'': //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). | ||
| - | * ''hr'': Headroom: the LNS adds a 50ms margin to add some margin. | + | * ''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). | * ''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. | * ''Ttx'': the time at which the LNS will send the packet to the gateway. | ||
| Line 45: | Line 45: | ||
| Inputs: | Inputs: | ||
| - | * Delay up: 350ms (configured). | + | * Delay up: ''350ms'' (configured). |
| - | * Delay up: 196ms (actual). | + | * Delay up: ''196ms'' (actual). |
| - | * Delay down: 350ms (configured). | + | * Delay down: ''350ms'' (configured). |
| - | * Packet sent at 10:00:00.000 by gateway (actual ''T0'', but not the value computed by LNS). | + | * Delay down: ''212ms'' (actual). |
| - | * Packet received at 10:00:00.196 by LNS (''now''). | + | * 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''). | ||
| Computation: | Computation: | ||
| - | * ''T0'' assumed is 09:59:59.846 by LNS (''now'' minus 350ms ''Ndu''). | + | * ''T0'' assumed is ''09:59:59.846'' by LNS (''now'' minus 350ms ''Ndu''). |
| - | * ''Test'' is ''T0'' + 350 + 350 + 50 = 10:00:00.596 | + | * ''Test'' is ''T0'' + 350 + 350 + 50 = ''10:00:00.596'' |
| * Decision: ''Test'' is less than 1000ms after ''T0'', so RX1 is reachable. | * 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: | Behavior: | ||
| - | * ''Ttx'' is ''T0'' + 1000 - 350 = 10:00:00.496 (time at which the LNS sends the TX message) | + | * The LNS sends the packet at ''10:00:00.496'' (''Ttx''). |
| - | * The packet forwarder is assumed to receive the packet 350ms later (//Network max. delay down//). | + | * The packet forwarder receives it at ''10:00:00.708'' (''Ttx+212ms''). |
| - | * The packet forwarder may receive it actually 212ms later (actual delay). | + | * The LoRa frame is sent at ''10:00:01.000'' when the RX1 window opens. Actual timing is done with ''tmst'' (SX1301 clock counter). |
| - | * Actual reception date is hence 10:00:00.706. | + | |
| - | * The LoRa frame is sent at 10:00:01.000 when the RX1 window opens. | + | |
| ==== Notes ==== | ==== 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 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 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 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 75: | 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 137: | 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.1532079278.txt.gz · Last modified: 2018/07/20 11:34 by bdu
Page Tools
