RX1 Delay not working

[ludionisio]

• [x] The issue is present in the latest release.
• [x] I have searched the issues of this repository and believe that this is not a duplicate.

What happened?

I am not being able to send any Downlink messages successfully.

What did you expect?

That the timestamp of the Downlink message would be equal to the rx1_delay parameter on the configuration file. Inspecting the "live lorawan frames" I can see that the "delayTimingInfo" - "delay" is always equal to "2s", don't matter which "rx1_delay" setting is chosen in "chirpstack-network-server.toml", even leaving it unset/commented out or equal to "0"

Steps to reproduce this issue

Steps:

1. Setup a network with Class A devices, Lorawan 1.0.2 and ABP authentication method
2. Set RX1_delay in chirpstack-network-server.toml equal to 2.
3. Create end device.
4. Try to send messages to end-device.
5. Change RX1_delay in chirpstack-network-server.toml to the correct/desired value.
6. Restart chirpstack-network-server.
7. Try again to send downlinks to end-device.
8. The delay remains equal to the first set value.

Could you share your log output?

Your Environment

Class A ABP Mode

network.toml:

[network_server.band] name="AU915"

[network_server.network_settings] disable_mac_commands=true disable_adr=true enabled_uplink_channels=[0, 1, 2, 3, 4, 5, 6, 7]

[network_server.gateway.backend.mqtt] server="tcp://localhost:1883" username="chirpstack_ns" password="chirpstack_ns"

[geolocation_server] server="localhost:8005"

Component	Version
Application Server	v3.10.0
Network Server	v3.9.0
Gateway Bridge	v3.8.0
Chirpstack API
Geolocation
Concentratord

[ludionisio]

Scanning through the source code I believe I found where the problem may be. The RX1_delay being used is equal to the delay stored in the Device Session:

# snippet chirpstack-network-server/internal/downlink/data/data.go

func setRXParameters(ctx *dataContext) error {
    if ctx.DeviceSession.RX2Frequency != rx2Frequency || ctx.DeviceSession.RX2DR != uint8(rx2DR) || ctx.DeviceSession.RX1DROffset != uint8(rx1DROffset) {
        block := maccommand.RequestRXParamSetup(rx1DROffset, rx2Frequency, rx2DR)
        ctx.MACCommands = append(ctx.MACCommands, block)
    }

    if ctx.DeviceSession.RXDelay != uint8(rx1Delay) {
        block := maccommand.RequestRXTimingSetup(rx1Delay)
        ctx.MACCommands = append(ctx.MACCommands, block)
    }

    return nil
}

It seems that even when this parameter changes in chirpstack-network-server.toml, the Device session's one does not get updated.

Thinking about a little more I think that this parameter should also be part of the Device Profile, because sometimes you do not have control of end device's factory configuration. Even though this parameter could be changed through MAC commands, the end device may not be fully compliant to the specification and will not adapt. And if it happens that you need 2 separate set of settings for 2 different end-devices in your network you would have to have 2 instances of the network server running.

[mmrein]

@ludionisio If you want to change RX1_delay value in device session immediately (without waiting for device to ACK the changes), change the "RX1 delay" value in Device profile and re-activate the device.

That way the network-server should use delay value set in device profile instead the one set in .toml for downlinks.

If value in .toml changes, server will try to send the MAC command (unless disable_mac_commands=true) to device indicating it should change its setting. If device ACKs the change, then the server starts to use the value from .toml for downlinks (i.e. then the Device session value should update).

[ludionisio]

I thought the RX1_delay value in the device profile was just for the OTAA JOIN session since it is under the JOIN(OTAA/ABP) tab, because when I tried to change this value I did not reactivate the device and it had no effect. I did not try to check the OTAA box I see that everything disappears. Plus, I did not consider ABP a JOIN process just an ACTIVATION process.

I would kindly suggest to open a pop-up window whenever Update profile is pressed informing the user to reactivate the devices for the changes to take effect immediately.

Thanks for the clarifications.