UPLINK_F_CNT_RETRANSMISSION events in ChirpStack when not ignoring direct uplinks in Border Gateway

Question

We are currently observing different behaviors depending on our LoRaWAN infrastructure configuration and are looking for the appropriate settings to resolve the issue.

Case 1
Infrastructure:
1 Relay Gateway
1 Border Gateway configured to ignore direct uplinks

Sensor configuration:
Rx Delay set to 5 seconds in the device profile

Result:
Frame acknowledgements are working correctly

Case 2
Infrastructure:
1 Relay Gateway
1 Border Gateway configured to not ignore direct uplinks

Sensor configuration:
Rx Delay set to 5 seconds in the device profile

Result:
We observe UPLINK_F_CNT_RETRANSMISSION events

In production, we will necessarily operate in case 2. Case 1 is not an option for us.

Is there a specific configuration (network, gateway, timing, or device profile settings) that could prevent UPLINK_F_CNT_RETRANSMISSION while maintaining the case 2 architecture?

Regards,

Orne Brocaar · Answer

Case 2: We observe UPLINK_F_CNT_RETRANSMISSION events

This is expected. It takes more time for the uplink to be relayed as the Relay receives it, then retransmits it.

With not ignore direct uplinks it means the uplink is received by the border gateway and the relay at the same time. The border gateway immediately sends it to ChirpStack, and ChirpStack starts processing it.

At the moment the Relay has relayed it to the Border gateway, and the Border gateway forwards this to ChirpStack, the uplink has already been processed and it is seen as a re-transmission.

There is nothing to worry about, it means that in case of a downlink it will be sent by the Border gateway to the device, instead of by a Relay thus less airtime is being used, which is a good thing :)

UPLINK_F_CNT_RETRANSMISSION events in ChirpStack when not ignoring direct uplinks in Border Gateway

1 Answers