Retransmission ACK response at RxWin 2

1

Hi there,

we recently observed the following situation.
We are sending a Confirmed Uplink starting at SF7. The gateway correctly tries to respond to the same channel/freq and the device fails to receive the ACK (that’s actually done on purpose). Then the device correctly moves to the next SF. Everything works as expected until we reach SF9 when the LoRa Server starts replying in Window 2 without even trying RxWin1 (notice the freq is 869.525). Even when we get to SF10+ zone, the server keeps responding with win2 settings

JSON up: {"rxpk":[{"tmst":1198057243,"chan":0,"freq":868.100000,"datr":"SF7BW125",
JSON down: {"txpk":{"imme":false,"tmst":1199057243,"freq":868.1,"datr":"SF7BW125",
JSON up: {"rxpk":[{"tmst":1206002979,"chan":1,"freq":868.300000,"datr":"SF7BW125",
JSON down: {"txpk":{"imme":false,"tmst":1207002979,"freq":868.3,"datr":"SF7BW125",
JSON up: {"rxpk":[{"tmst":1214025604,"chan":2,"freq":868.500000,"datr":"SF8BW125",
JSON down: {"txpk":{"imme":false,"tmst":1215025604,"freq":868.5,"datr":"SF8BW125",
JSON up: {"rxpk":[{"tmst":1228258332,"chan":3,"freq":867.100000,"datr":"SF8BW125",
JSON down: {"txpk":{"imme":false,"tmst":1229258332,"freq":867.1,"datr":"SF8BW125",
JSON up: {"rxpk":[{"tmst":1242222804,"chan":4,"freq":867.300000,"datr":"SF9BW125",
JSON down: {"txpk":{"imme":false,"tmst":1244222804,"freq":869.525,"datr":"SF9BW125",
JSON up: {"rxpk":[{"tmst":1270708436,"chan":5,"freq":867.500000,"datr":"SF9BW125",
JSON down: {"txpk":{"imme":false,"tmst":1272708436,"freq":869.525,"datr":"SF9BW125"
JSON up: {"rxpk":[{"tmst":1299296916,"chan":6,"freq":867.700000,"datr":"SF10BW125",
JSON down: {"txpk":{"imme":false,"tmst":1301296916,"freq":869.525,"datr":"SF9BW125"
JSON up: {"rxpk":[{"tmst":1349707820,"chan":7,"freq":867.900000,"datr":"SF10BW125",
JSON down: {"txpk":{"imme":false,"tmst":1351707820,"freq":869.525,"datr":"SF9BW125",

We also tried different scenarios such as starting from SF8 or SF10. The moment our SF is equal or larger than SF9, the server is responding with Window 2 settings.

Does anyone see an issue here or is this a TTN feature we have been missing?

2

Why do you think there might be an issue? The backend is allowed to choose which window to use and RX2 is more efficient (10% duty cycle frequency and more power allowed where RX1 has 1% duty cycle).
So yes, this is a feature.

1 Like
3

Cause we tried this many times and this ALWAYS kicks in when our uplink SF is equal or greater than SF9. If what you describe is true, how come it never happens at SF7/8?

Keep in mind that we are in a completely LoRa-wise clean environment and we do use different gateways to avoid over-utilizing gateway TX capabilities (duty cycle etc)

It really looks like a bug on the backend: as soon as it is called to respond to SF9, it takes Win2 configuration AND indeed sends the message much later.

4

At sf7 and sf8 it is feasible to respond in RX1, the data rate is sufficient so a transmission is short. At SF9 the transmission in both rx1 and rx2 use the same amount of time so it is more efficient to use the slot with the highest duty cycle. For SF10 and up using RX2 is far more efficient.

Why should I keep that in mind? Neither I not the backend know what gateway transmission capacity will be required in 1 or 2 minutes. You might know (or assume to know) there are no other users, the backend doesn’t.

The LoRaWAN standard allows the backend to decide the optimal transmission strategy. Sending the response 1 whole second later does not seem such a huge thing to me but maybe I’ve been working with LoRaWAN too long… (looking at sf11 and SF12 the total time spend receiving will be equal or less even with the 1 second additional delay due to the additional time the transmissions take at the lower data rate)

BTW the backend has this behavior explicitly coded so they certainly is no bug but a design decision.

1 Like
5

Just to be sure: note that a LoRaWAN server will only choose one of RX1 or RX2. For a specific downlink, It will not use RX2 after first trying RX1, if that’s what you’re thinking.

6

I think this explains it. I was completely not thinking about the efficiency part.