Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LoRaWAN: Terminate RX when receiving uplink messages #11241

Merged
merged 1 commit into from
Aug 20, 2019

Conversation

teijokinnunen
Copy link

This prevents RX2 window to be enabled at the same time when repeating transmission, when QoS repeated TX is in effect. Failure to do so seems to place the LoRaWAN stack in a state where send() always fails with WOULD_BLOCK error.

Description

During testing of a LoRa device, the LoRaWAN stack rarely ended up in state where all transmissions would fail (LoRaWANInterface::send() would always return LORAWAN_STATUS_WOULD_BLOCK). After further investigation, this can happen with the following circumstances:

  • NbTrans > 1, i.e. TX retransmission occurs
  • During the RX1 window of the first transmission, an uplink message from another device coincidentally transmitting on the same channel is captured

The log looks similar to this (note that I've added some extra logging for window timing):

[INFO][LMAC]: RTS = 26 bytes, PEND = 0, Port: 2
[DBG ][LMAC]: Frame prepared to send at port 2
[DBG ][LMAC]: TX: Channel=1, TX DR=5, RX1 DR=5
[DBG ][LSTK]: Transmission completed
[DBG ][LMAC]: TX done @ 2291490 time_diff 27 timeout 891 rx2 to 1986
[DBG ][LMAC]: RX1 slot open @ 2292412, Freq = 868300000
*** Uplink received here
[DBG ][LMAC]: RX done @ 2292499
[INFO][LSTK]: QOS: repeated transmission #2 queued
[DBG ][LMAC]: Frame prepared to send at port 2
[DBG ][LMAC]: TX: Channel=7, TX DR=5, RX1 DR=5
[DBG ][LSTK]: Transmission completed
[DBG ][LMAC]: TX done @ 2292723 time_diff 28 timeout 890 rx2 to 1985
*** Both RX2 window of the 1st transmission and RX1 window of the 2nd tranmission overlap
[DBG ][LMAC]: RX2 slot open @ 2293507, Freq = 869525000
[DBG ][LMAC]: RX1 slot open @ 2293644, Freq = 867900000
[DBG ][LMAC]: RX timeout @ 2293812
*** As things are now messed up, TX_DONE indication never occurs, further attempts to transmit will fail.

A more appropriate fix would be to delay QOS retransmission until RX2 window closes, but it seems to me that more extensive code changes would be needed for that. At least this should prevent the stack from ending up in an unusable state.

Pull request type

[ X ] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

Release Notes

This prevents RX2 window to be enabled at the same time when repeating
transmission, when QoS repeated TX is in effect. Failure to do so
seems to place the LoRaWAN stack in a state where send() always fails
with WOULD_BLOCK error.
@ciarmcom ciarmcom requested review from a team August 16, 2019 11:00
@ciarmcom
Copy link
Member

@teijokinnunen, thank you for your changes.
@ARMmbed/mbed-os-wan @ARMmbed/mbed-os-maintainers please review.

@0xc0170
Copy link
Contributor

0xc0170 commented Aug 19, 2019

CI started

@mbed-ci
Copy link

mbed-ci commented Aug 19, 2019

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts

@0xc0170 0xc0170 merged commit 63084ad into ARMmbed:master Aug 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants