lora_gateway
lora_gateway copied to clipboard
Lora-net
Anybody completely solve retransmission of Lorawan-End-Node ?
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) :
Yeah. The server ignores retransmitted frames, so if the FCnt is the same it does not sent anything to backend. Try setting the "FCnt check" in your device profile to "Disabled". I tried it in Lora Server ,but not OK.
2 Confirmed retransmission not acknowledged ：
This is by design. The network-server will only confirm an uplink once. Re-transmissions with the same frame-counter are ignored as else this would allow for re-play attacks. The network-server can't know if this is a replay attack or re-transmission. I think in LoRaWAN 1.1 this is fixed by hashing the uplink channel index, so that the network-server can detect that the frame-counter did not increment, but that the MIC is unique (given that the re-transmission was done using a different channel). LoRaWAN 1.1 has better mechanisms to deal with this, as I already have pointed out in previous comments (adding the channel + DR into account when generating the MIC so that the network-server can distinguish a retransmission from a replay-attack).
3 LoraWAN1.1 protocol 19.1 Uplink Timing Diagram for Confirmed Data Messages：
If an end-device does not receive a frame with the ACK bit set in one of the two receive windows immediately following the uplink transmission it may resend the same frame with the same payload and frame counter again at least ACK_TIMEOUT seconds after the second reception window. This resend must be done on another channel and must obey the duty cycle limitation as any other normal transmission. If this time the end-device receives the ACK downlink during its first receive window, as soon as the ACK frame is demodulated, the end-device is free to transmit a new frame on a new channel.
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 :
End-node open-source LoraMAC-node 4.3.2 and LoraMAC-node 4.4.2 Gateway : newest Lora-gateway & packet_forwarder LoraWAN-Server : newest Lora Server
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!
