Base station backhaul link over cellular : impact of increased round-trip delay and acceptable range

Base station backhaul link over cellular : impact of increased round-trip delay and acceptable range

After they have transmitted an uplink message, LoRaWAN class A devices open two short receive windows for downlink messages called Rx1 and Rx2.

The default timers are 1s (Rx1 begins exactly 1s after last bit of the last uplink message has been transmitted), and 2s for Rx2.

If the round trip delay is too long, then the downlink messages sent by the LoRaWAN network controller (LRC) to the LRR base station may arrive too late for downlink transmission to the device, causing loss of downlink messages.

So how good is your base station backhaul ?

You need to assess the average LRR to LRC round trip delay, and its standard deviation.

The LRR to LRC round trip delay is composed of:
- the network round-trip (an order of magnitude can be obtained with IP Ping tool)
- the uplink jitter compensation buffer of the LRC, which defaults to 250ms (may be customized per LRR base station in the LRC configuration). This delay is necessary to process uplink messages which are received by multiple base stations: the LRC accepts up to 250ms backhaul delay difference when receiving such uplink messages from multiple LRR base stations, and will process such duplicate packets only once. If you reduce this jitter compensation buffer, packets received from multiple base stations may be processed separately, resulting in duplicate packets with the same LoRaWAN upCnt frame counter being forwarded to application servers. This is not necessarily a big issue as long as the application server is able to detect duplicates from upCnt frame counter. When this happens, you will also see duplicate packets in the Wireless Logger application, with the same uplink frame counter. 

So we have:
- average backhaul round trip delay = LRR-to-LRC Ping round-trip + 250ms (jitter buffer)
- round trip delay standard deviation = ping standard deviation

The average round trip delay including uplink jitter buffer is automatically computed by the LRR, and its value may be accessed from the LRR WAN backhaul monitoring page in the Network Manager application, which is part of the standard ThingPark Wireless delivery.

Assuming a normal distribution of round trip delays, if MEAN refers to the average round-trip delay including jitter buffer, and STDDEV is the standard deviation of this delay :

- If     MEAN + 1,65 STDDEV < 2s, then there will be less than 5% downlink packet loss due to round trip delay. This is a worst case for QoS. Try to use a different backhaul technology (e.g. Ethernet to DSL modem) if you cannot get to this performance level.

- If    MEAN+ 2,33 STDDEV < 2s, then there will be less than 1% downlink loss due to round trip delay. 

- If    MEAN+ 3 STDDEV < 2s, then there will be less than 0,1% downlink loss to to round trip delay

For optimal performance and cell capacity, the LRC network controller should be able to select the Rx1 receive window. In order to ensure this we recommend that  MEAN + 2,33 STDDEV < 1s. This ensures that less than 1% of the downlink transmissions scheduled to Rx1 will need to fallback to Rx2 due to excessive round-trip delay.

For instance, when using a cellular connexion, MEAN=500ms and SDTDEV=200ms will provide a good performance, but anything beyond this will reduce cell capacity (as Rx2 will be used to compensable for round trip delay), and if MEAN + 1,65 SDTDEV >2s, the backhaul delay may also introduce unacceptable downlink packet loss.

    • Related Articles

    • When performing range testing, disable Automatic Datarate (ADR) adaptation.

      If you are performing a range testing session with a LoRa device, and you are walking are driving, you may get into connectivity problems while moving away from the nearest LoRa base station if you use a normal production connectivity plan. Normal ...
    • Product Version 5.2 - Software Release Notes

            Versions Version  Date  Author Details  Rev1  2018-11-15  Actility  First Version  Rev2  2018-11-21  Actility  Addition of the following features: RDTP-7722, RDTP-7723 and RDTP-7746  Rev3  2019-03-04  Actility  Updated versioning (release 5.2 ...
    • User Guide for ThingPark Wireless - Version 5.1

      This article is the official documentation provided by Actility for the 5.1 release. It will contain User's Guide, Product Description, and other reference documents.  The release notes can be found  in the release notes section (click here) User's ...
    • Product Version 6.0 - Software Release Notes

              Versions  Version Date Author Details Rev1 2019-07-25 Actility First Version. Rev2 2020-01-07 Actility - Addition of “Feature Interaction Matrix” for each feature. - Updated the Feature Activation details for LRC record/replay tools Rev3 ...
    • Product Version 5.0.1 - Software Release Notes

      Scope The scope of this document is to describe the release notes of the ThingPark Product Software v5.0.1. Version 5.0.1 subcomponents versioning Version 5.0.1 list of new introduced features (User Stories) and release notes for all ThingPark ...