Downlink messages after unconfirmed uplink

sslupsky · May 3, 2018, 2:41pm

I have made an observation I would like to share and ask if anyone can explain what is going on. I’m not sure this is an “issue” but I cannot explain what is going on. When the logging began about 15 hours ago, I noticed that the server transmitted a corresponding unconfirmed downlink message for every unconfirmed uplink. I thought it odd that the server was responding to an unconfirmed message but I did not spend anytime to investigate whether or not this is normal behaviour because this has always been the case.

I have attached a screen shot of the frame log below taken recently. In the screen shot, you can see that there is a downlink message once for every 8 uplink messages. What appears to have changed is the frequency of the downlink messages. I have another sensor set up in a different application and it appears to exhibit similar “downlink frequency degrading” behaviour.

So, I was curious if anyone else has noticed this and if this is “normal” behaviour and to be expected?

brocaar · May 4, 2018, 7:17am

This could be perfectly valid. E.g. when you setup the device-status interval in the service-profile, the network-server will ask the device now and then about it link margin and battery status through a mac-command. It could also be the ADR algorithm kicking in…

Note: when the uplink is unconfirmed, it does not mean that the network-server will not send a response (mac-commands and / or application payload). It is actually the opposite, when the uplink is confirmed then the network-server must respond with an ACK.

wero1414 · December 19, 2018, 12:00am

Im sending uplinks without confirmation over ABP activation and every time that i receive one uplink the server answer with this:

So every time i send an uplink even when its unconfirmed i get a downlink without a clear reason i have search on the forum and on the docs but i got no information about this “Token”

When i do uplinks with OTAA i dont get it

Thanks!

brocaar · December 19, 2018, 8:29am

Please check the live LoRaWAN frame-log in the web-interface. These are probably downlink messages containing mac-commands to sync your device with the network-settings. When your device ignores mac-commands, it means the network-server will keep retrying.

Tony1 · November 20, 2019, 7:09pm

I’m receiving a mac-command after every uplink message.
I use the lmic library and mac-commands are not tested and probably not handled correctly. Does somebody know how to disable these mac-commands?
I found a hint to set disable_mac_commands=true in loraserver.toml, but this does not work.

loraserver log:
INFO[0249] adr request added to mac-command queue dev_eui=00f2796b7fec3add dr=5 nb_trans=1 req_dr=0 req_nb_trans=1 req_tx_power_idx=0 tx_power=0
INFO[0249] pending mac-command block set cid=NewChannelReq commands=3 dev_eui=00f2796b7fec3add

Thanks,
Tony

AlexSneedMiller · November 27, 2019, 7:28pm

I’ve seen similar issues with other devices that appear to not handle mac-commands properly as well.

Is there a way to disable sending down a downlink message for an unconfirmed uplink that is not requesting anything back?

If we have a lot of devices that are sending unconfirmed uplinks, we might start running into downlink capacity issues.

brocaar · November 28, 2019, 9:32am

Two days ago I have added this change:

This will be included in the next release

terrillmoore · December 12, 2019, 7:47pm

@brocaar @tony1 I maintain the LMIC version at https://github.com/mcci-catena/arduino-lmic. It is true that the original LMIC was not very compliant. However, that’s fixed in our version; I’ve tested the MAC commands, and the device passes the RedwoodComm LoRaWAN compliance scripts, which are based very closely on the official scripts.

However, devices built with our code show the repeating sequence of LinkAdrRequest/LinkAdrAck. We acknowledge the messages, and our response is legal, but… unusual.

Here’s what happens:

Device sends class-A uplink
NS sends LinkAdrReq as piggyback on a null downlink in the RX* slot.
LMIC parses the LinkAdrReq and accepts it and prepares a LinkAdrAck.

Here’s the unusual part:

LMIC notices that this is a piggyback on a null downlink, and immediately schedules a null uplink with the LinkAdrAck also piggybacked.

This seems to confuse quite a number of software packages. It works fine with TTN, but the original RedwoodComm tester, and the SwissComm tester both get confused (in different ways). Both seemed to expect the device to delay the LinkAdrAck for the next uplink. The LMIC doesn’t do this for a variety of reasons – primarily because this can break software in the US at SF10, because we only have 11 bytes of payload. Because we broke two packages, I suspect that the problem is that this is new (though compliant) behavior and therefore we’ve found a hole in test coverage.

In the case of ChirpServer, it causes the network to return to step 2, and we loop forever.

MCCI will be happy to get a test device to “somebody” for testing, and to work with @brocaar to find a suitable solution.

–Terry

brocaar · December 16, 2019, 3:06pm

Hi Terry, I’m happy to do some testing!

Before sending out any test devices, please note that it is normal that in case of ADR, the ChirpStack Network Server will send a few LinkADRReq mac-commands to tune the dr and tx-power. In case these stay the same, then there is an issue that needs to be solved, but when LMIC sends a positive (true) ack on the channel-mask, dr and tx-power, then this should not be the case and the NS should continue to increase the data-rate / decrease the tx-power.

Thiago_Campos · October 9, 2022, 11:19pm

Hi terrillmoore,

I’m using a mcci-lmic and I’m having this problem. Have any solution?

terrillmoore · October 10, 2022, 12:09am

@Thiago_Campos – sorry you’re having problems. Are you using the most up-to-date version? We have customers using this without difficulty, but you certainly need to be at v4. Please file a bug report at arduino-lmic if you’re seeing a problem with the most recent version. Be sure to include region, etc.

Thiago_Campos · October 10, 2022, 1:00am

Hi @terrillmoore thanks for te reply!!
I am using the last version MCCI LoRaWAN LMIC library

I’m running the otaa example from the library setting the frequency Au915.

I set the rx1 to 5s

My device profile is:

The data in device data is ok. But when I check on lorawan frames, I check that for every uplink sending, I have a downlink.

Johansson · October 10, 2022, 5:50am

Could this thread be related to your problem?

Thiago_Campos · October 10, 2022, 11:02pm

thanks Johansson for the answer!

So, I understand the topic is related in ABP, I am using otaa.
I set the device’s time window to 5s and this problem still occurs.

martin · October 11, 2022, 8:33am

The data in device data is ok. But when I check on lorawan frames, I check that for every uplink sending, I have a downlink.

Your device is sending Confirmed uplinks in which case the network server has to send downlink with ack (as we can also see inthe screenshot as ack: true), that is correct behaviour.