Downlink messages after unconfirmed uplink

ChirpStack Network Server
8

@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