AS923: NewChannelReq rejection, ChMask discrepancy, LinkADRReq rejection / repetition

[jbiveroni]

Summary

After joining, the device is setup to use channels 0...6 (ChMask 0x7F). The LNS sends a NewChannelReq (channel 7). The device rejects DrRange, and therefore does not enable the new channel (ChMask 0x7F). However, in subsequent LinkADRReqs, the LNS uses ChMask 0xFF. The devices therefore rejects these LinkADRReqs. The LNS repeats LinkADRReq commands "forever", although they are always rejected. This creates unnecessary downlink traffic.

Steps to Reproduce

TTS, v3.18.2: Asia 920-923 MHz, LoRaWAN Specification 1.0.2, RP001 Regional Parameters 1.0.2 revision B. Device: Dwell time enabled (DR2...5), 2 default channels enabled.

1. Joining, channels 0...6 enabled.
2. LNS: NewChannelReq: MinDR: 0, MaxDR: 5, freq: 924xxx; LinkADRReq: DR 5, channel mask 0x00FF (8 channels).
3. Device: NewChannelAns: Accept frequency, REJECT Min/MaxDR. Probably, because MinDR = 0 is not permitted, minimum DR is 2 (SF10). New channel is not enabled on device. LinkADRAns: Accept DR, PWRIDX, but REJECT channel mask (8 channels, but only 7 are set up now!)
4. LNS: LinkADRReq: DR 5, channel mask 0x00FF (8 channels).
5. Device: LinkADRAns: Accept DR, PWRIDX, but REJECT channel mask (8 channels, but only 7 are set up now!)
6. LNS: LinkADRReq (above)
7. Device: LinkADRAns (above)
8. ... Repeats "forever"

What is already there? What do you see now?

Probably 2 separate issues:

• NewChannelReq rejected -> ChMask LNS/device do not match
• LinkADRReq rejected -> LNS repeats LinkADRReq "forever"

Workaround (not satisfactory): Use frequency plan "Asia 915–928 MHz (AS923 Group 1) with only default channels". NewChannelReq is not used. This way, the channel mask bits agree and the LinkADR is accepted.

More observations:

• Disable ADR on the device: behavior stays the same.
• Disable ADR in LNS (--mac-settings.use-adr=false): behavior stays the same (??).

What is missing? What do you want to see?

• After NewChannelReq was rejected, ChMask should be 0x7F in LinkADRReq.
• Maybe the first (single) MAC command should be to enable/disable dwell time limitations in AS923.
• LinkADRReq (MAC commands in general) should better not be repeated "forever".

Environment

The Things Network Command-line Interface: ttn-lw-cli Version: 3.18.2 Build date: 2022-03-29T11:41:38Z Git commit: 19dbc96d4 Go version: go1.17.7 OS/Arch: linux/amd64

How do you propose to implement this?

Can you do this yourself and submit a Pull Request?

I'm afraid not.

[viethoa14]

I think, it is this framework's bug, i had same issues about 3 years ago, maybe it will not resolve.

[adriansmares]

As part of https://github.com/TheThingsNetwork/lorawan-stack/pull/5811 I have implemented some of the fixes proposed here. The TxParamSetupReq will be sent as early as possible, and the LinkADRReq mask will now correctly take into account the fact that the channels are still pending accept/reject. This should cause the NS to no longer schedule perpetual LinkADRReq.

The only problem that is left in this issue is that I am not sure I agree with the fact that when the end device has uplink dwell time enabled, it should reject the min data rate index 0. The data rate index is supposed to be valid within the regional parameters version, but enabling uplink dwell time shouldn't retroactively move the channels between min data rate index 0 and 2. I cannot find a device stack that actually thinks that validation is dwell time sensitive:

LoRaMac-node: check and definitions arduino-lmic: check and definitions basicmac: check and definitions 1 / definitions 2