Hi,
consider the case 3 confirmed downlinks are queued for a class A node. Let’s assume the payload as: 0x11, 0x22, 0x33.
The first uplink for the node is with ACK=false.
In the downlink window the 1. dowlink 0x11 is received.
The second uplink is with ACK=true.
In the downlink window the 2. downlink 0x22 is sent.
The third uplink is ACK=false (either something went wrong, rejoin happend or 2. downlink not received)
Then in the downlink window ttn v3.30.x sends the third donwlink 0x33 NOT the 2. as repetition.
The fourth uplink is with ACK=true
In the downlink window then the 2. downlink is resent.
…
I guess it can not changed that the resent of confirmed downlinks which are NACK is done during the queue and not after the last element on the queue. Am I write?
Confirmed ‘anything’ is a 'mare in the context of TTN’s community deployment and if you read across the forum we advise/request that e.g. confirmed uplinks be avoided where possible, Your confirmation renders the target GW deaf to all other community traffic…bad enough for an odd message but if used regularly a DoS to other users…confirmed downlink’s specifically are a whole new kettle of fish and can have major consequences esp if node poorly behaved or struggles with reception as we have seen users find themselves stuck in repeated DL mode where Node never ACK’s or where sequence and synch of ACK’s is messed up (similar to your example) and system struggles to recover, so unless you have a major genuine need to use we would ask that you don’t. If needed go on to a private LNS instance and, unusual to say this as we generally like to share and get mutual benefit, dont peer to TTN as part of private deployment (you may inadvertently start DoS’ing the community GW(s)). Others may have different perspective and view…
Remember also under TTN FUP you are only allowed 10 DL (for ALL purposes) max per day and again we recommend you think of that per week, per fortnight or per month+
If you have node struggling to stay connected to the network you should investigate that first. (Add gateway or change the location (be it the node or antenna))
Do you want to replace a downlink message (change to a new message) or change the timing when it gets send?
thank you for the response. The advise is clear → try to avoid confirmed ‘anything’. It is a self hosted instance at our university. I guess that the functinoallity of the queueing in confirmed downlinks is the same across the deployments.
Hi, the need is to have a sequence of downlinks in a specific order.
radio signal/transmission is not poor but it shall work as robust as possible. So the described case is more or less which ‘can’ happen with small confidence.
Fundamental problem is RF based data delivery is not guaranteed - especially in the shared ISM bands - even with the additional resiliance of LoRa based RF modulation c/e conventional and legacy modulations delivery isnt/cant be guaranteed esp in presence of interferers and whilst you could kludge a solution where queues get delayed to facilitate only sending next message once previous acknowledged this can get VERY messy and long in the presence of continuous or bursty interferers that eliminate messages over a significant period and remember the interefrerers can be localised to either end of the transmission chain.
Fundamental point for all to consider is
“how will my application and use case behave if (a) message(s) dont get through?”…you need a graceful resolution.
Even conventional ethernet/Internet based delivery (IP) of packets/messages isnt guaranteed, you need a fragmentation and re-assembly scheme to capture the designed packets in order at the destination and then re-assemble and re-order based on the specific routes and associated latency of travel over the network, anything that takes too long either being requested for re-tx or tagged as dropped/missed with then error concealment mechanisms (think say video streaming), same goes with broadcast DV streams (Sat or Terrestrial etc), though here its an error correction and error concealment exercise as no scope for requesting re-tx and multiplath routing delay not a factor. Unless LNS local to the GW’s on your self hosted implementation you will also likely see Internet fragmentation and re-ordering requirements in your backhaul implementation.
For anyone who hasn’t yet had a migraine, read the docs and the spec on the tangle you can get in to.
In this instance the LNS has the third downlink in memory, so when the third uplink arrives without the ACK set, the message is passed on to the Application Server for notification to you and then the LNS re-queues the second downlink which would be behind downlink #3. This is the expected behaviour.
You’ve two* possibilities, either manage the queuing of downlinks from your application - this sort of thing is why we now have a 5s Rx1 delay. Or as @Jeff-UK suggests, re-asssembling the packets on the device in the right order. Or queue downlinks 1 & 2 and then once you know the second has arrived, queue the last one.
Ideally your device has code that can switch mode so when the first downlink arrives, it quickly cycles through uplinks to collect the rest of the downlink information and manages which downlinks have been received & lets the application know via the payload.
We can almost certainly advise further on solutions if you can indicate the size of the downlinks and why they are split in to three.
Insert usual joke about there being two hard things in CS …
quickly being a relative term given window lengths and fact that device (and GW) need to be mindful of duty cycle constraints, channel and sub-band utilisations, and legal issues, FUP not withstanding (appreciate private instance per above so not a factor?) - just calling out incase thread/post ‘googled’ and kept forever and temps other users to attempt something like a high wire act (and on TTN instance to boot!) (Dont!!!)
