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:21] bdu [Behavior] |
wiki:network_delays [2018/07/25 09:28] (current) bdu [RX window decision] |
||
|---|---|---|---|
| Line 23: | Line 23: | ||
| <code> | <code> | ||
| T0 = now - Ndu | T0 = now - Ndu | ||
| - | T0 + Tagg + Ndd + hr < 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. |
| + | * ''now'': packet reception date by LNS. | ||
| * ''Ndu'': //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). | ||
| + | * ''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. | ||
| - | * ''Ndd'': //Network max. delay down//: whthe setting on the dashboard (350ms by default). | + | * ''Ndd'': //Network max. delay down//: the setting on the dashboard (350ms by default). |
| - | * ''hr'': 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). | ||
| === Example === | === Example === | ||
| - | * Delay up: 350ms (configured) | + | Inputs: |
| - | * Delay up: 196ms (actual) | + | |
| - | * Delay down: 350ms (configured) | + | * Delay up: ''350ms'' (configured). |
| - | * Packet sent at 10:00:00.000 by gateway | + | * Delay up: ''196ms'' (actual). |
| - | * Packet received at 10:00:00.196 by LNS | + | * Delay down: ''350ms'' (configured). |
| - | * T0 assumed is 09:59:59.650 by LNS | + | * Delay down: ''212ms'' (actual). |
| - | * total: ''196 + 350 + 350 + 50'' = ''946'' | + | * Packet sent at ''10:00:00.000'' by gateway (//actual// ''T0'', but not the value computed by LNS). |
| - | * Result is less than 1000, so RX1 is reachable. | + | * Packet received at ''10:00:00.196'' by LNS (''now''). |
| - | * 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) | + | Computation: |
| - | * The LoRa frame is sent at T0+1000ms (RX1 window start) | + | |
| + | * ''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 ==== | ==== 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 58: | 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 120: | 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.1532078504.txt.gz · Last modified: 2018/07/20 11:21 by bdu
Page Tools
