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.