Incorrect LoRaWAN behavior on unconfirmed uplink retransmission

[zul00]

Description of defect

Based on LoRaWAN v1.0.2 specification; page 24; line 25-27; end-device should stop retransmission of unconfirmed uplink anytime it receive any downlink. However, in the current setup, end device would keep on sending retransmission of unconfirmed messages even though it receive a downlink.

Target(s) affected by this defect ?

n/a

Toolchain(s) (name and version) displaying this defect ?

• GCC_ARM
• arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]

What version of Mbed-os are you using (tag or sha) ?

Customized mbed-os based on mbed-os-5.13.4 (1bf6b20df9)

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

• mbed-cli : 1.10.1
• InteropEngine : 1.3.2
• LRC(Actility) : 1.22.4
• LoRa region : EU868
• LoRa class : A

How is this defect reproduced ?

We were testing our device using Interop Engine from Actility when we found that our device (DUT) failed the test 3.2.4. In the test item, Interop configures DUT to do repeated transmission of unconfirmed-uplink. The test engine expects the DUT to stop retransmission after receiving a downlink.

Looking at the LoRaWAN specification that I cited above it looks to confirm the expected behavior from the test engine.

The test documentation can be found here.

[mbedmain]

@zul00 thank you for raising this issue.Please take a look at the following comments:

Could you add some more detail to the description? A good description should be at least 25 words.

NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'. This indicates to us that at least all the fields have been considered. Please update the issue header with the missing information.