Open klementc opened 4 months ago
Hello Clément,
Yes, we are aware of this problem (among others!) in the current implementation of the MAC layer. In general, real LoRaWAN applications would not request two uplink transmission in such a short time span (2 seconds). As you noted, the responsibility not to schedule a second uplink transmission in such a short time frame is currently left to the user. I agree that in the future it should be prevented to avoid unexpected behavior; it is already on the list of planned changes to this module in the dedicated issue.
I'll take this chance to write down how - in my opinion - the intended behavior should be; then we can see whether to take the time to implement it, or just patch your issue for now.
If we look at an actual implementation of the LoRaWAN MAC layer, we see that you should not be able to transmit a new packet neither while the device is still busy with the reception procedure (i.e., the 2 reception windows), nor if there are further retransmission scheduled for a previous packet. The way they prevent you from doing that is by having an internal task scheduler, acting as a size-1 buffer for send events. The send task is only launched if the MAC layer is IDLE, i.e., not planning to open a reception window, not planning to retransmit a packet, etc.
Interestingly, this implementation seems to interrupt the retransmission procedure if no channel with available duty-cycle is found after closing the 2nd reception window. Note that here the duty-cycle is managed in 1 hour periods (i.e., with a 1% DC you'd have 36 cumulative seconds to use for TX in the band for the current hour), providing more time management flexibility than our implementation.
For now, you may want to avoid scheduling a second call to Send
while the device is still in the process of opening reception windows. I'll leave this issue open for further discussion and updates.
Hello, thank you for your answer. I know that it is uncommon to have applications sending messages within such short delays, but I am interested in simulating what would happen in such situations. I guess for now the best is to rely on callbacks to wait for the finish of the second window before sending new packets, thank you
Expected Behavior
Hello, if I send two uplink packets from the same node in a short time, I encounter 2 different behaviors for the second packet's transmission. The expected behavior is for the second packet to be scheduled after making sure the reception windows of the first packet are closed, and DC rules are respected.
Actual Behavior
I encounter 2 different behaviors depending on the timestamp of the Send() function:
Steps to Reproduce the Problem
I modify the simple-network-example to add a second transmission:
In this case, the (parsed) logs output:
We observe the delayed scheduling of the second packet transmission 3.09414 seconds after its supposed emission time. However, the transmission never starts. If using a Tx time later than the second receive window (i.e. 4.3136), the second packet is delayed in a similar way, and sent successfully after this delay.
I think this behavior shouldn't happen and the postponed transmission should take place after considering DC rules.
The reason for this to happen is the
resetRetransmissionParameters()
function called inCloseSecondReceiveWindow()
that cancels the future transmission. Simulator::Cancel(m_nextTx); deletes the future Tx, causing this issue.If this is the expected behavior, how should I schedule the tx of multiple packets from the application
Specifications