Network delays configuration

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.

From the backhaul configuration menu of each gateway, the network delay uplink and downlink can be configured. The default configuration is 350ms.

Path to the menu: Managements → gateways→ <gateway_EUI> → configurations → backhaul

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.

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.

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

T0lns = now - Ndu
Test = now + Tagg + Topp + Ndd
Decision = Test - T0lns = Ndu + Tagg + Topp + Ndd < 1000 ?
Ttx = now + Twin - Ndd

Example

Notes

Several situations may arise:

• 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 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 very bad (>1000ms RTT), and the TX messages aren't transmitted properly.
• The backhaul is correct (~200ms RTT), everything works (nominal case without push).

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

The LNS will target the RX1 depending on the configured network delay. The configured network delays on the dashboard are set to 0ms and 400ms for Network max. delay up and Network max. delay down.

In this example (0ms/400ms), the RX1 is reachable. If the Network max. delay down had been configured to 100ms, the RX1 window targeted may have been reachable without margin. With default configuration (350ms/350ms), RX2 window is targeted.

In this case the RX1 window is not reachable. The RX2 window is also missed, unless the network delay is adjusted.

Network max. delay down is set with the default configuration:

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:

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. For instance, with a RTT of 1200ms, the delay is:

1200 + 350 + 50 + 1200 = 2800ms

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.

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 the nominal case. The LNS will always target the RX2. The configured delays on the dashboard are the default values (350ms).

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.