lorawan: Join Request retransmission timing - Interop Engine compliance test

[zul00]

Description of defect

When we tested our LoRaWAN device (DUT) using Interop Engine from Actility we found that our DUT failed on test 1.2.2.4.

Test description

In test 1.2.2.4, test engine expects the DUT to do a Join Request, while the network server is holding back sending Join Accept to the DUT. In this situation, the DUT is expected to keep on doing retransmission of the Join Request until it satisfied some conditions.

One parameter that is verified by the test engine is the timing between each retransmission (item 1.2.2.4). Based on the test that we have done, with the default configuration, our DUT always failed on the transmission of the second Join Request. Below is the literal failure message from the test engine:

It must have more than (6 seconds + worst case air time transmission) between two JointRequests to
wait JoinAccept through RX2

This failure is likely to happen if the timing between the first Join Request and the second one is less about 6.4 s (default condition), while it would be less likely to happen if the delay is increased between 320 ms to 500 ms. I will explain later how we achieve the delay.

What we have tried

To passed the test, we tested two approaches:

1. Adding a call_in with 500 ms delay in RX2 window of LoRaWANStack::process_reception_timeout(). This solution adds a delay of 500 ms between the timeout of the RX2 window to the next Join Request retransmission. This approach has a better chance of passing the test.
2. Increasing downlink-preamble-length value of lora library configuration from 5 symbols to 15 symbols which increase about 320 ms delay between RX2 symbol timeout to the next retransmission. This approach sometimes still failed but is more likely to succeed compared to the default configuration.

Both modifications increase the chance of succeeding test 1.2.2.4. I think the change in solution 1 is quite isolated where it only delayed the transmission of the next JointRequests by 500 ms.

While with solution 2, I am guessing that adding 10 symbols to the downlink-preamble-length is quite a significant number, and might risk our DUT missing downlink due to it is not able to lock to a signal because it increases the minimum number of symbols before locking into it.

I will prepare two different PRs using the approaches above.

Can someone give their opinion regarding this situation?

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 (1bf6b20)

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 1.2.2. In the test item, Interop aksed the tester to reset the device which force the device to send Join Request. Then Interop will disable the device on the Network Server by not responding to the Join Request. Interop expect DUT to do retransmission within the expected time. With default condition, DUT is likely to failed when sending the second Joint Request. Looking at the log, the second Join Request is transmited ~6.4 s after the first one.

Test 1.2.2 is configurated using default configuration from Interop:

- Expected number of uplinks received for each default channel: 2
- Delay between the end of the Tx uplink and the opening of the first reception slot: 2
- Offset between the uplink data rate and the downlink data rate: 3
- The RX2DataRate field defines the data rate of a downlink using the second receive window: 2

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.
What target(s) are you using?
What toolchain(s) are you using?

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.

[zul00]

Below is a screenshot of the failed test:

[zul00]

Below is a screenshot from Actility network server log, it shows that the delay between the first Join Request and the second Join Request is 6.446 ms. The timestamp of the second Join Request also matched the timestamp from when Interop concluded the test failed.