PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Tech Log (https://www.pprune.org/tech-log-15/)
-   -   Why do some CPDLC uplinks take 1 second… and others 40 seconds? (https://www.pprune.org/tech-log/669400-why-do-some-cpdlc-uplinks-take-1-secondo-others-40-seconds.html)

fraguel 27th November 2025 09:15

Why do some CPDLC uplinks take 1 second… and others 40 seconds?
 
A lot of pilots assume CPDLC and ACARS are “instant” systems — especially in continental ATN environments — but the more you look into the network behind the service, the more you realise that message delivery time varies massively depending on where you are and through which path the message is actually travelling.

Something that has caught my attention recently:
  • A simple CPDLC UM in EUR ATN might arrive in 1–3 seconds
  • The same UM, in another FIR, suddenly takes 20–40 seconds
  • And occasionally you see delays that feel more like ACARS SATCOM than ATN
Technically, this shouldn’t happen if the routing layer is working optimally.
Yet it does.

The variables I’m trying to understand (and would like to hear from others):
  1. Queueing/polling cycles in some ground networks
  2. Fallbacks between VDL2/ATN and ACARS paths
  3. DSP congestion at peak times
  4. Hidden store-and-forward logic in particular regions
  5. Local ATN router bottlenecks that no one talks about
In theory, ATN B1 is supposed to offer consistent latency…
In practice, we’ve all seen it behave very differently.

Has anyone here analysed real-world latency data or done comparisons across FIRs?
Did you see systematic patterns, or was it completely random?

Would love to hear experiences from ATCOs, avionics engineers and anyone familiar with ground routing.

Uplinker 27th November 2025 12:06

I think you have answered your own question with the options you state; any or all of those reasons.

My cellphone often sits quietly doing nothing, but if I happen to click on an email message, it suddenly goes "oh yes, I forgot to tell you, these other emails came in..." and several new ones suddenly appear. It's almost as if it waits to see activity before downloading my new emails.

maxq. 24th May 2026 00:06

VDL2 generally gives much lower latency than SATCOM or HFDL, which is why ATN CPDLC in Europe often feels almost instantaneous.

But I suspect the big latency differences are less about raw transmission speed and more about the underlying network architecture: ATN/ACARS routing, DSP congestion, store-and-forward logic, and possible transitions between VDL2 and ACARS paths.

Crossing VHF coverage boundaries and switching between VDL2 ground stations could probably add short delays too, although that alone may not explain the occasional 20–40 second delivery times.

steamchicken 24th May 2026 21:40

If there are buffers anywhere in the network you can get unpredictably long latency - your packet happened to arrive at the back of the queue. Adding longer buffers is a common strategy to solve networking problems - if the buffer is long enough, the message will be sent one day - but it's also a mistaken one as the buffer can fill up and stay full, creating a permanent and large delay. IETF's Dave Taht spent a lot of time diagnosing this so-called bufferbloat in WiFi networks and the wider Internet.

The solution he found was to reduce the effective size of the buffer by dropping messages at random when the buffer length went over a target; if you're using a transport layer like TCP/IP that retransmits dropped messages and adjusts the transmission rate, this ensures that senders know that there is a delay and slow down sending so the buffer clears, and the dropped messages get resent. Unlike just having a shorter buffer, this doesn't create a systematic source of packet loss so it is fair to all flows.

maxq. 24th May 2026 23:25

I’m not fully convinced the comparison with WiFi/TCP bufferbloat directly applies to ATN B1.

ATN B1 is not a TCP/IP internet-style network with adaptive congestion control. It’s an OSI/CLNP-based ATS datalink architecture with very different traffic patterns, priorities and certification constraints.

That said, the general principle still makes sense: if intermediate ATN/VDL2/ground systems use store-and-forward queues or oversized buffers, congestion could absolutely create variable latency and long delivery times.

steamchicken 26th May 2026 22:01

Good grief that's an intensely *90s Phone Company* document....

ahwalk01 27th May 2026 07:44

Is it working over HF?

Aviation Communication | STORADIO

FlyComs 28th May 2026 12:51

Hello - my first post, although I have been reading this forum on and off for some years. I am some sort of a has-been weekend pilot (i.e. you don't want to fly with me :)), with some history in design and standards related to communications avionics.

To the topic: One aspect I am aware of is that Europe has been severely constrained in terms of VHF frequencies for datalink (VDL mode 2 and ATN). Only a very small number of frequencies are available for the whole continent, and are reused over and over. Some work was done to relieve this, but the last info I have is that it remains a bottleneck. This problem resulted in a program stretching over more than a decade which resulted in adopting satcom as a means to augment VHF datalink (ATN) over Europe. The first airliners started using this perhpas a year ago, with the number of installed aircraft now significantly ramping up.

I can't say that the VHF congestion explains everything the OP reported, but it is certainly a factor. I imagine it would vary from area to area.


All times are GMT. The time now is 14:39.


Copyright © 2026 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.