Closed Diligence365 closed 1 year ago
Aren't these behaviours by design? If the node ends a CONFIRMED DATA UP and the acknowledgement is lost, then the node will attempt to resend. With LoRaWAN 1.0.x, it will resend with the same FCntUp, which will cause it to get silently rejected by the network server. With LoRaWAN 1.1, the standard now has a better design to eliminate this problem. Either way, the network server did get the frame - so the only loss is that a device compliant with LoRaWAN 1.0.x might spend some time (re-)trying to get the acknowledgement successfully if the first acknowledgement is lost. If the uplink itself was lost, the retransmission workflow would work fully without issues.
These LoRaWan level issues have nothing to do with this repo.
This repo only implements support of the concentrator hardware, it has no knowledge of the LoRaWan protocol.
You need to consider these things in the context of the design of LoRaWan, and the implementation in whatever server stack you use - they have all but nothing to do with the packet forwarder, and literally nothing to do with the HAL.
Thank you for your inquiry.
Customers are encouraged to submit technical questions via our dedicated support portal at https://semtech.force.com/ldp/ldp_support.
We invite all users to visit the LoRa Developer Portal Forum at https://forum.lora-developers.semtech.com and to join the thriving LoRa development community!
Hi,all: Description details: recently,a problem about Lorawan node retransmission confused me , I've found many issues about it in github and repeated to find some information in Lorawan protocol, some useful issue about retransmission and their responding records as following: 1 uplink fail(re-up) :
2 Confirmed retransmission not acknowledged :
3 LoraWAN1.1 protocol 19.1 Uplink Timing Diagram for Confirmed Data Messages:
does the newest Open-Source LoraWAN Server completely solved the question above.
anybody have some useful suggestion or good idea to solve node retransmission ? Environment :