# RN2483 confirmed uplink not working **URL:** \ **Category:** End Devices (Nodes)\ **Created:** [May 13, 2020, 1:46pm UTC](https://www.thethingsnetwork.org/forum/t/rn2483-confirmed-uplink-not-working/36980 "2020-05-13T13:46:56Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![cslorabox](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cslorabox/32/35697_2.png) [@cslorabox](https://www.thethingsnetwork.org/forum/u/cslorabox)\ **Post date:** [May 14, 2020, 5:27pm UTC](https://www.thethingsnetwork.org/forum/t/rn2483-confirmed-uplink-not-working/36980/4 "2020-05-14T17:27:44Z")
> [@BeckAndCall](#): > > (The node will eventually be deployed at a remote location and the ability to do the occasional confirmed uplink is a necessary part of ensuring continuous service. ) I would recommend against using network level confirmed uplink. The way it is designed, only the first attempt which reaches a gateway is confirmed by the network. So if it’s actually the _downlink_ packet that gets lost for whatever reason, then none of the retries will ever receive another confirmation. The network will ignore all traffic from the node until the uplink frame count increments, and retries do not increment the frame count, so they simply get ignored. Instead, I’d suggest you implement your own confirmations at _application_ level. This has several benefits, first each application packet gets a unique frame count, so none will be ignored by the network stack. Next, you can chose the retry strategy that is the best compromise between success and battery and airtime consumption. And whatever data you might include in the retry could be fresher measurements, rather than increasingly stale old ones. But most important, by generating an application-level downlink ack in your data backend infrastructure rather than having the TTN network servers generate a network-level one, your ack confirms what you probably actually care about - that your data back end got the message. TTN’s servers getting the message and it then getting lost on the way to your data backend is interesting from a debugging perspective, but probably irrelevant from a user one, where what you probably want is a truly end-to-end confirmation. --- _[View the full topic](https://www.thethingsnetwork.org/forum/t/rn2483-confirmed-uplink-not-working/36980)._