Issue with LinkADRReq Persistence on TTN with LoRaWAN v1.0.4 and rp002-1.0.3

[autume]

Summary

We are facing an issue with persistent LinkADRReq messages on TTN when using a device with LoRaWAN v1.0.4 and rp002-1.0.3. The device does not support ADR.

Steps to Reproduce

1. Configure the device to operate in the 868.1 MHz region on the TTN console.
2. Ensure the device does not support ADR.
3. Successfully join the network.
4. Observe the LNS initiating a LinkADRReq.
5. Device responds with LinkADRAns (0x01: ChannelMaskACK ok).

Current Result

The LNS continuously sends LinkADRReq messages and does not stop until the device responds with LinkADRAns (0x07).

Expected Result

The LNS should not persist in sending LinkADRReq messages when the device does not support ADR, and it should not check the PowerACK and DataRateACK bits.

Relevant Logs

No response

URL

No response

Deployment

The Things Stack Cloud

The Things Stack Version

3.32.1

Client Name and Version

No response

Other Information

No response

Proposed Fix

No response

Contributing

• I can help by doing more research.
• I can help by implementing a fix after the proposal above is approved.
• I can help by testing the fix before it's released.

Validation

• The fix is tested in a staging environment.
• The fix is documented in The Things Stack Documentation

Code of Conduct

• I agree to follow TTN's Community Code of Conduct.

[halimi]

I'm checking the LoRaWAN v1.0.4 specification and after that I will check our implementation.

From the specification:

4.3.1.1 Adaptive data-rate control in frame header (ADR, ADRACKReq in FCtrl):

If the ADR bit is unset, the Network Server SHALL accept that the end-device MAY not comply with any
attempt to control the number of retransmissions, the data rate, or the TX power of the end-
device regardless of the received signal quality. The Network MAY still send commands to
inform the end-device of the recommended configuration using the LinkADRReq command.
An end-device SHOULD accept the channel mask controls present in LinkADRReq, even
when the ADR bit is not set. The end-device SHALL respond to all LinkADRReq commands
with a LinkADRAns indicating which command elements were accepted and which were
rejected. This behavior differs from when the uplink ADR bit is set, in which case the end-
device accepts or rejects the entire command.

So indeed if the ADR is not set then the Network Server should accept that the end device has rejected the data rate and the TX power and not send the request again.

[halimi]

@autume Could you please provide some logs and the LinkADRAns and LinkADRReq MAC commands especially that in the uplink package the ADR bit is set in the FCtrl header?

[johanstokking]

It could be that TTS considers the entire LinkADRReq to be discarded when some LinkADRAns ACK bits are 0, because of L998 and L999:

The end-device SHALL respond to all LinkADRReq commands
with a LinkADRAns indicating which command elements were accepted and which were
rejected. This behavior differs from when the uplink ADR bit is set, in which case the end-
device accepts or rejects the entire command.

This formulation is confusing because indeed there's an exception for when the end device set the ADR bit to 0 in the uplink message. In that case, like @halimi says it is okay that the end device does not accept all instructions.

[autume]

@halimi The attached file is the relevant log.
eui-70b3d57ed0050417_live_data_1732758662188.json

[halimi]

@autume Thank you for providing the information.

The uplink header doesn't have the ADR bit set.

 "data": {
      "@type": "type.googleapis.com/ttn.lorawan.v3.UplinkMessage",
      "raw_payload": "QP+8CyYAEQAAj9dg1hFt",
      "payload": {
        "m_hdr": {
          "m_type": "UNCONFIRMED_UP"
        },
        "mic": "YNYRbQ==",
        "mac_payload": {
          "f_hdr": {
            "dev_addr": "260BBCFF",
            "f_ctrl": {},
            "f_cnt": 17
          },
          "frm_payload": "j9c=",
          "full_f_cnt": 17
        }
      },

And only the ChannelMaskAck is set in the LinkADRAns and we are marking as a rejected answer.

"name": "ns.mac.link_adr.answer.reject",
 "data": {
      "@type": "type.googleapis.com/ttn.lorawan.v3.MACCommand.LinkADRAns",
      "channel_mask_ack": true
    },

Checking the code we are marking the answer as rejected if one of the Ack bit is not set and we are not checking the header ADR bit.

lorawan-stack/pkg/networkserver/mac/link_adr.go

Line 324 in eda0a45

if !pld.ChannelMaskAck || !pld.DataRateIndexAck || !pld.TxPowerIndexAck {

[autume]

@halimi Thank you, I understand the issue now. Will this logic be optimized in future versions?

[halimi]

@autume yes, we will fix this. Thank you for reporting the issue.