Downlink messages after unconfirmed uplink

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?

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.

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

image

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!

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.

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

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.

Two days ago I have added this change:

This will be included in the next release :slight_smile:

@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:

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

Here’s the unusual part:

  1. 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