search

TheThingsNetwork / lorawan-stack

The Things Stack, an Open Source LoRaWAN Network Server
https://www.thethingsindustries.com/stack/
Apache License 2.0
980 stars 309 forks source link

Option to set persistent LinkADR settings when using Custom ADR option #3820

Closed i3mSuperMan closed 2 years ago

i3mSuperMan commented 3 years ago

Summary

The custom ADR option allows to set the ADR parameter values, and NS communicates them to the device via LinkADRReq. But these values are not persistent and lost on reset of MAC State during re-join, thus requiring re-configuration every time device joins the network.

Why do we need this?

To make the parameters' values persistent and communicate to the device in case of MAC State reset after Join, to avoid manual intervention to set them with every re-join of the device.

What is already there? What do you see now?

The custom ADR option currently allows configuring the adr-data-rate-index, adr-tx-power-index & adr-nb-trans values using the below flags. These values reset when the MAC State of the device reset on re-join and not communicated to the device.

ttn-lw-cli end-devices set <app-id> <dev-id> --mac-state.desired-parameters.adr-data-rate-index
ttn-lw-cli end-devices set <app-id> <dev-id> --mac-state.desired-parameters.adr-tx-power-index
ttn-lw-cli end-devices set <app-id> <dev-id> --mac-state.desired-parameters.adr-nb-trans

What is missing? What do you want to see?

An option to make the changes to adr-data-rate-index, adr-tx-power-index & adr-nb-trans parameters persistent.

Environment

TTES V3.10.9 CH

How do you propose to implement this?

Add relevant mac-settings flags at the NS end.

How do you propose to test this?

...

Can you do this yourself and submit a Pull Request?

No. @rvolosatovs

rvolosatovs commented 3 years ago

Good to note that this is mostly relevant for pre-1.1 devices in US915-like bands

rvolosatovs commented 3 years ago

Also, these fields should be mutually exclusive with enable_adr

baranisrc commented 3 years ago

If NS sets the DataRate=0 respectful of Desired ADR settings for each device when sending the USA linkADRreq "channel_mask", it will cause devices with an 11 byte or larger payload to exceed allowed payload size and some modems may reset, thus sending them into an endless reset and rejoin cycle, since the maximum application payload length in the absence of the OPTIONAL FOpt MAC control field (N) is 11 bytes. A single data frame may contain any sequence of MAC commands piggybacked in the FOpts field. Piggybacked MAC commands are always sent without encryption and MUST NOT exceed 15 octets. Alternatively, MAC commands may be sent as FRMPayload and MUST NOT exceed the maximum FRMPayload length. ref: RP002-1.0.2 LoRaWAN® Regional Parameters: 2.5.6 US902-928 Maximum payload size

rvolosatovs commented 3 years ago

If NS sets the DataRate=0 respectful of Desired ADR settings for each device when sending the USA linkADRreq "channel_mask", it will cause devices with an 11 byte or larger payload to exceed allowed payload size and some modems may reset, thus sending them into an endless reset and rejoin cycle, since the maximum application payload length in the absence of the OPTIONAL FOpt MAC control field (N) is 11 bytes. A single data frame may contain any sequence of MAC commands piggybacked in the FOpts field. Piggybacked MAC commands are always sent without encryption and MUST NOT exceed 15 octets. Alternatively, MAC commands may be sent as FRMPayload and MUST NOT exceed the maximum FRMPayload length. ref: RP002-1.0.2 LoRaWAN® Regional Parameters: 2.5.6 US902-928 Maximum payload size

This should be fixed by https://github.com/TheThingsNetwork/lorawan-stack/issues/3901 - NS will probably send the uplink data rate index in the first LinkADRReq.