Discussion: Better control of confirmed uplink messages from application

[cjhdev]

Discussion: Better control of confirmed uplink messages from application

[cjhdev]

Confirmed uplinks currently use the same retry/back-off strategy as OTAA which is very slow. The specification doesn't require it to use the same strategy. I did it that way because I don't use confirmed uplinks and didn't want to spend time on it.

I think increasing power and/or spreading factor on retry is the opposite of what should be done, especially If the loss is due to congestion.

It is possible to change the back-off strategy to send the retries closer together and thus avoid the payload becoming stale. This already happens with re-transmission of unconfirmed data (redundant frames). Back-to-back re-transmission is allowed until a certain amount of off-time has been accumulated. The limit is set in ldl_region.c so it changes depending on the region. In EU this limit is set to one hour of off-time.

Confirmed retries could be improved by shifting to a similar system, but with a back-off algorithm that is faster than OTAA.

Regarding your proposed changes:

I would prefer any counter manipulation remain the responsibility of the MAC. I think special behaviour should be implemented as a mode the application can select, for example:

• retry with exponential back-off
• retry with exponentiall back-off and randomisation
• variation on the back-off interval

That sort of thing, with the default mode being something conservative.

As mentioned I think increasing the reach of the signal on retry is moving in the wrong direction.

[frbehrens]

Thanks for your comments.
New for me is the opinion, that a retry should not increase power/spreading factor. You are right, that in the case of congestion it does not help, rather the opposite. In my setup I send confirmed messages with nbTrans=3, so there is always a fast retry with the same settings. But if the location or other conditions change, we have to change the spreading factor. If we do not want to wait until ADR kicks in, some missed ACKs (to confirmed messages) is the right place.
In my test setup (with one bug fixed) it worked very well. After a location change I observed a switch from SF7 to SF9 and shortly thereafter to SF8. That is still running stable with that value.

regarding

1. I agree, that the retry with same counter should be the responsibility of the MAC. A retry with exponential back-off or other algorithm in addition to the existing nbTrans behaviour is a good idea.

2. If several retries with same SF fail, the SF should be increased, either controlled by MAC or application. The fact, that ADR is too slow in order to be able to react to changed transmission conditions was exactly the reason for my changes. On the other hand ADR works quite well in reducing the SF.

[cjhdev]

I've had another look at your proposed changes, I think I missed the point the first time around.

In the past the retransmission of failed confirmed uplinks was only controlled
by parameter nbTrans. The application could not trigger a proper retry, because
a repeated call to LDL_MAC_confirmedData() increases the frame counter, which
in turn is a problem, when not the confirmed uplink was lost, but the acknowledge
downlink.

The frame counter is required to increment if you want adrAckCounter to increment (see 1.0.3 section 4.3.1.1). If you want ADR to respond as fast as possible, you need to use confirmed service without retries.

I think the problem is that you want the server to resend an unacknowledged confirmed downlink.
Shouldn't this happen if the ACK bit is not set on the next frame?

LDL_MAC_resendLastConfirmedMessage() to trigger a retransmit of confirmed messsage

Your function assumes that the previous frame is still in the buffer. This is problematic because LDL by design does not guarantee the contents of the buffer and other service specific state once the service is complete.

LDL_MAC_lowerRateIncreasePower() to control transmit power and data rate

You don't have to use ADR. The spec encourages applications to turn it on/off as required. LDL has getter/setter functions for manipulating power and rate. At a glance, these functions work (or should work) regardless of the ADR setting.

[frbehrens]

Hello,
I use this topic to give feedback right away.
Meanwhile I updated my test environment to the current version (450ae80) and everything seems to work well. Thanks for your continuous improvements.

After your posting I restructured my code. I send confirmed messages with nbTrans=3 and rely on LDL's retry at first. If it fails I reduce the rate by one step and the next measurement will use the new rate. So I do not need to patch LDL and have the desired behaviour. I need the fast rate change, because my devices will run on places where SF7 is sufficient and also where I need SF8 or SF9.