Dear all,
When I use unconfirmed send, after gateway reboot then node must to join again to send data success. If not rejoin then node also show “send success” although gateway didn’t receive. My question is how to node can check lose in this case to rejoin?
thanks,
Tuyen
The uplink confirm packet does not require a reply from the gateway, which cannot determine whether the node is disconnected.If it is an confirm packet, you will receive an incorrect reply.
Thanks Nicholas,
So, no way node can detect in case gateway suddenly reboot and auto rejoin? Must rejoin by hand? It is very inconvenient when node far away. If use confirmed sending i think it cost “expensive” bandwidth.
regards,
Tuyen
Can you tell me which node and gateway you are using?
I am using rak2247 & rak811 and Chirpstack server
regards,
Typically nodes do not join gateways but rather joint network servers. You have an atypical case where both functions run on the same embedded computer, but it’s actually an apparent loss of session records by the network server and not the gateway that is at issue here.
The general answer is that network servers should be implemented in a way that does not lose state! That’s one reason that in most non-demo settings its better to run the network server component in the cloud and back it up. In theory a gateway-hosted server could also use a backup (persisted redis or whatever) but there might be issues with the actual implementation.
The design of LoRaWAN does not provide much mechanism to recover from a loss of server state. Generally when using OTAA you’d also use ADR, and if ADR fails after hours/days to ever get any feedback from the server, it might at that point attempt to rejoin. But this is not a strong mechanism because it is not something that is supposed to happen often; ideally joining only happens once or at most a few times in device lifetime.
Also note that LoRaWAN does not have any sort of “nack” or negative reply in either direction. If a node sends traffic (even confirmed) with invalid session keys, or with a rewound frame counter, it will receive no response at all from the server. The server might internally log the occurrence of unintelligible traffic, but there will be no negative or error reply transmitted back to the node.
Thanks cstratton for explanation,
How about confirmed sending mode? what is advantage and disadvantage?
regards,
Tuyen
You can refer this lorawanr-specification.
https://lora-alliance.org/resource-hub/lorawanr-specification-v102
LoRaWAN confirmed uplink has a serious design flaw and generally should not be used: because a given frame count can be confirmed only once, if it is the downlink rather than the uplink which is missed, none of the retries can achieve success either.
For most purposes you are better off implementing you own confirmations and retry at application level, such that each uplink attempt is a distinct message with its own unique frame count. That also means you can retry with fresh data, rather than old and increasingly stale data.
But keep in mind the LoRaWAN downlinks are far more costly than uplinks, generally you should not be trying to achieve confirmation at all.
Hi cstratton,
So it is the best is node using unconfirmed mode and we should have a “PING” from application server to keep alive? How about network server save join information?
No, ADR does that for you. The only reason to reply is if you would transmit again sooner if you do not get one, but again keep in mind that downlinks are fairly expensive in LoRaWAN.
It should be doing so, and it is a bug if it does not, but that’s an entirely distinct topic from the rest.