I think that when using LoRaWAN, your application should simply be prepared to have some missing data, and missing up to 10% of packets is quite realistic in my experience.
If you send a kind of absolute measurement, like a counter, it is not a super big deal if you miss a packet. Each new packet provides a full status.
For example, we have a project with motion sensor nodes (TBMS100). The motion sensor sends a packet immediately upon detecting motion. Sometimes this packet is lost. It has a packet structure that tells you the number of minutes since the last movement, and it contains a counter for the absolute number of times a movement was detected. So even if you miss a packet, you can still see that the counter was increased by some amount since the last packet. And you can reconstruct the time of the last motion event using the minutes-since-motion field.
Another example, where data loss is more-or-less tolerable: I’m using LoRaWAN to send airborne particulate matter measurements. The node sends data every 5 minutes (depending on spreading factor). If I miss a packet, the node will miss the “heartbeat” of the map on maps.sensor.community and will not appear on their map. A pity but not a super big deal.
The dutch national institute for public health and environment uses that data too, but calculates hourly averages, so missing 10% of packets means only a slightly inferior hourly average, we still get enough data.