No downlinks scheduled in LoRaWAN 1.1

[janakj]

Summary

I have been trying to activate an OTAA device in LoRaWAN 1.1 mode. Join completes successfully. The device sends a confirmed uplink message right after. The uplink contains a rekey indication and I see the TTN network server scheduling a rekey confirmation. However, the network server never schedules any downlink message to the device. Thus, the rekey confirmation never arrives at the device. LinkCheckAns also does not work.

This appears to be a LoRaWAN 1.1 issue. When I configure the device as LoRaWAN 1.0.4, downlinks from the NS are scheduled correctly (without rekey, of course, since those are not used in LoRaWAN 1.0).

Update: Communication with the AS works, both uplink and downlink. That is, I can send an uplink to the AS and it is correctly decoded. I can also schedule a downlink from the AS and it arrives at the device. It's downlinks from the NS what does not work, i.e., rekey confirmation, link check answer, ADR, and uplink confirmations.

Steps to Reproduce

My device uses LoRaMac-node v4.6.0, however, I am able to reproduce the problem with ttn-lw-cli simulate as follows.

First, create a new OTAA LoRaWAN 1.1 device in TTN:

ttn-lw-cli end-devices create irt-lora-app rtk-client         \
    --lorawan-version MAC_V1_1                                \
    --join-eui 0101010101010101                               \
    --dev-eui 3632313961398608                                \
    --root-keys.app-key.key 2B7E151628AED2A6ABF7158809CF4F3C  \
    --root-keys.nwk-key.key 2B7E151628AED2A6ABF7158809CF4F3C  \
    --frequency-plan-id US_902_928_FSB_2                      \
    --lorawan-phy-version RP002_V1_0_1

Then simulate a Join:

ttn-lw-cli simulate gateway-join-request       \
    --dev-eui 3632313961398608                 \
    --join-eui 0101010101010101                \
    --dev-nonce 0001                           \
    --lorawan-version MAC_V1_1                 \
    --lorawan-phy-version RP002_V1_0_1         \
    --band-id US_902_928                       \
    --app-key 2B7E151628AED2A6ABF7158809CF4F3C \
    --nwk-key 2B7E151628AED2A6ABF7158809CF4F3C \
    --gateway-id irt-mudd-rooftop-gateway

The output of the above command from my run is in the following file: join.txt

Extract the various keys and DevAddr from the output of the above command and send a confirmed uplink to port 0, with no application payload, and with rekey indication in FRMPayload:

ttn-lw-cli simulate gateway-uplink                       \
    --f-nwk-s-int-key 4DDBA89D5278EDDC803CEA7EC1F76242   \
    --s-nwk-s-int-key 6A295E3DE99B1D4550A808318CAD7112   \
    --nwk-s-enc-key 7284246FAAF622F07AC8961B626FDBC8     \
    --app-s-key D003C78F08E2EF6A6E38E8D8E0820F95         \
    --lorawan-version MAC_V1_1                           \
    --dev-addr 260C1BCE                                  \
    --gateway-id irt-mudd-rooftop-gateway                \
    --f-port 0                                           \
    --lorawan-phy-version RP002_V1_0_1                   \
    --band-id US_902_928                                 \
    --f-cnt 0001                                         \
    --confirmed                                          \
    --f-port 0                                           \
    --frm-payload 0x0B01

No downlink is received and the last command eventually prints:

#### Sending confirmed uplink
INFO	Sent uplink
error:unknown:unknown (context deadline exceeded)
    correlation_id=a0fa1dc0ffd54149a605968c2682a08f

What do you see now?

Here is an excerpt from TTN console showing rekey indication, confirmation, and device activation, but no scheduled downlink. I get the same behavior with my device (LoRaMac-node v4.6.0) and with ttn-lw-cli simulate:

JSON-formatted log for the above screenshot: no-downlink.txt

What do you want to see instead?

I would assume the TTN network server would schedule a downlink to the device so that the rekey confirmation can actually be transmitted to the device.

Environment

TTN nam1 cluster, version 3.18.1
The device uses LoRaMac-node version 4.6.0
ttn-lw-cli 3.18.1

How do you propose to test this?

I was able to reproduce the bug with ttn-lw-cli simulate (see above), so that tool can be used to test the bugfix.

Can you do this yourself and submit a Pull Request?

No. This looks like a bug in the TTN network server and I am not familiar with that code base.

[adriansmares]

Thanks a lot for the detailed report. I've been able to reproduce the issue and can confirm that it is on our side.

I think that setting the following command which updates the desired ADR ACK delay exponent and limit exponent should allow your device to receive downlinks post join:

ttn-lw-cli dev set app1 eui-1231231231231231 --mac-settings.desired-adr-ack-delay-exponent ADR_ACK_DELAY_32 --mac-settings.desired-adr-ack-limit-exponent ADR_ACK_LIMIT_64

The downlinks are scheduled after explicitly providing these parameters, in my tests.

Currently these desired values are unmarshalled wrongfully from the stack configuration and make the MAC state desired parameters have invalid (0) values instead of allowing the settings to fall back to the band defaults. This in turns causes the downlink marshaling to fail as exponents cannot be zero.

[janakj]

Thanks for the workaround! I can confirm that it works.