Network Delays configuration

Network Delay configuration helps target the RX1 window when sending TX messages to an end device.

On the LNS section of each gateway, the network delay uplink and downlink can be configured. By default it is 350ms. Here is how it looks like:

This value is an indication of the network delays that the gateway has towards and from the LNS server.

When an end-device sends a LoRa packet, each gateway that receives it will forward it to the LNS server. The LNS server will wait 350ms after having received the first packet, in order to aggregate all the copies of that packet sent by each individual gateway.

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).

So the RX window decision is basically:

T0 = now - Ndu
Test = T0 + Tagg + Ndd + hr
Decision = Test-T0 < 1000 ?
Ttx = T0 + Twin - Ndd

with:

• 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).
• Test: estimated earliest timestamp for transmission
• Tagg: Aggregation time: the LNS waits 350ms after the first packet.
• Ndd: Network max. delay down: the setting on the dashboard (350ms by default).
• 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).

Inputs:

• 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).

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).

• 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.

Several situations may arise:

• 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 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.

This is the nominal case. The LNS will always target the RX1. The configured delays on the dashboard are the default values (350ms).

This is an edge case of the nominal case. The LNS will miss the RX1 depending on the actual network delay. The configured delays on the dashboard are the default values (350ms).

In this example, the RX1 is missed. If the network delay had been configured to 300ms, the RX1 window may have been reachable.

In this case, it is very important to reconfigure the network delay on the dashboard. This will help reach the RX1 window as soon as the actual network delay is good.

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:

In this case the RX2 is missed and the TX packet is dropped. The solution is to change the Network max. delay down to a value of 850ms:

The RX1 is not reachable, but the RX2 is, thanks to the updated configuration.

In this case the RX1 and RX2 windows are never reachable. Indeed, with an example 1200ms RTT, the delay is:

1200 + 350 + 50 + 1200 = 2800ms

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.

Indeed, the delay calculated above is 2800ms, so if RX1 delay is 3000ms, it is reachable.

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.

Mobile network operators, to save bandwidth and power, usually instruct the mobile equipments to reduce the radio state (RRC layer).

For example, in UMTS, there are mainly three states:

• idle: radio is OFF, but the context is saved both in mobile and network.
• FACH: radio is in a low latency but low payload active state. Only very limited payloads can be sent.
• DCH: radio is active and transmitting data.

The behavior is that when there is network activity, the mobile is in DCH. When there is no activity, after a delay, the network will place the mobile in FACH. This allows the mobile to quickly recover an active connection (DCH) and to send very limited payloads. When there is still no activity while in FACH, the network will place the mobile in idle state.

When the mobile is idle and wants to send data, it will have to establish a new radio connection to the mobile network, which will take some time. Once in this state (DCH), the mobile will have a low latency.

So basically, if there is no traffic, the first connection may take up to 1000ms. Subsequent connections are faster, like 100 or 200ms.

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.