Unfortunately, you’ve been subject to some replies that were more condescending than technically helpful.
Downlink confirmations are sent if and only if the uplink traffic is sent in confirmed mode - a header bit typically set or not based on the data transmit function you call, or an option passed through it. So the way to not trigger confirmation downlinks, is to send your uplink traffic in unconfirmed mode.
However, modern full implementations of LoRaWAN like TTN v3 are likely going to send some configuration MAC commands in downlinks to any new node, and to keep sending them until they receive a satisfactory response. You mentioned using an Arduino nano, and if that also means you’re also using an old, incomplete, deprecated LoRaWAN limitation like an obsolete version of LMiC, it’s quite likely that your node is not going to correctly respond, and the downlinks will continue, rapidly chewing up your usage allowance.
To implement a node properly, you absolutely must use a current, spec compliant LoRaWAN stack, such as a recent checkout of MCCI LMiC. This can be challenging to compile to fit on a smaller Arduino, but there’s really no option but to do it right with such a full LoRaWAN implementation. If you can’t get it to fit in your existing processor board, you’ll need to get a more capable one.
In terms of reliablity studies, as already mentioned you should look for gaps in the uplink frame counts. If you need the node’s view of affairs, give it meaningful serial console output (be careful not to generate serial output within the tight timing of the TX-RX windows) and collect those logs on something for later analysis.