Beware that in practice this can work out a little bit differently than intended - because it’s entirely possible that the node fails to hear the network’s ACK, even though the network heard the uplink and advanced the uplink frame counter as a result.
A typical node implementation may then try to retransmit the uplink with the same frame counter. Because the network has already seen that frame count, and already acked it, the retransmission will be ignored - the node can re-transmit as many times as it likes and it will never get an ack because as far as the server is concerned, it already did!
So if you’re going to re-transmit on lack of an ACK, it’s probably preferable to send fresh readings with an incremented frame count number, and not merely re-send the same exact packet, or at least, sharply limit the number of resends before incrementing the frame counter.
(A possible alternate behavior would be to make the server willing to re-ack the most recently seen uplink frame, with the same exact downlink count - but that’s probably only worthwhile if you have an application where getting 100% of a perhaps increasingly stale data set through is more important than getting current data through often enough.