ADR behaviour on V3 - does not increase rate

After migration of my 1st test device to V3 stack I had the impression, that ADR does not work reliably as in V2. So I debugged this further. Am I wrong or do we have a problem here?
In the example the transmission conditions are very good, TX and RX SNR are above 8.

After OTAA join I send a 1st confirmed message and receive an ADR request. That is new in V3, but fine:
link_adr_req: dataRate=5 txPower=15 chMask=00ff chMaskCntl=0 nbTrans=1

That is confirmed from my device in next uplink (after further ADR requests as well):
link_adr_ans: powerOK=true dataRateOK=true channelMaskOK=true

Then the device sends some unconfirmed frames with DR5/SF7, all is fine. Before frame 6 I set manually the rate to SF10. With the downlink I receive immediately an ADR req, but only to change the power:
link_adr_req: dataRate=15 txPower=4 chMask=00ff chMaskCntl=0 nbTrans=1

The device continues to send uplinks and receives with frame 7 an ADR request again:
link_adr_req: dataRate=15 txPower=7 chMask=00ff chMaskCntl=0 nbTrans=1

Of course that request is confirmed in frame 8:
link_adr_ans: powerOK=true dataRateOK=true channelMaskOK=true

The rate stays at SF10, when I increase to SF11 or SF12 the behaviour is the same. After more than 100 unconfirmed uplinks there was no rate adjustment.

When I read the ADR parameter via TTN-CLI I see:

“network_server_address”: “eu1.cloud.thethings.network”,
“mac_settings”: {
},
“mac_state”: {
“current_parameters”: {
“adr_data_rate_index”: 5
},
“desired_parameters”: {
“adr_data_rate_index”: 5
},
“last_adr_change_f_cnt_up”: 8
}

So it seems that the network assumes the wrong currently used parameters.

When I overwrite the current_settings with:
ttn-lw-cli dev set ... --mac-state.current-parameters.adr-data-rate-index 2
the networks sends an expected ADR request:
link_adr_req: dataRate=5 txPower=0 chMask=00ff chMaskCntl=0 nbTrans=1

In my opinion the network should always update the current data rate parameter for ADR calculations from last received frame. Or how ADR is expected to work?

Kind regards,
Frank

Could you be clearer about exactly what you receive?

15 does not appear to be a legal value for the upper nibble of the DataRate_TXPower byte in any region I can see.

Also what is your region?

I use region EU863-870 and I receive the value 15, which is according to the LoRaWAN standard 1.0.4 (at least, I did not look into 1.1) a valid value:

The value 0xF (decimal 15) of either DataRate or TXPower means that the end-device SHALL ignore that field and keep the current parameter values.

Interesting, that seems to be a change since 1.03

…and not a very logical one, as giving the value again would not cost anything more.

I will probably have to investigate further what the special conditions are for me. I can’t imagine, that ADR won’t work in general.