Why do some CPDLC uplinks take 1 second… and others 40 seconds?
Thread Starter
Joined: Mar 2011
Posts: 5
Likes: 0
From: madrid
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:
Yet it does.
The variables I’m trying to understand (and would like to hear from others):
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.
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
Yet it does.
The variables I’m trying to understand (and would like to hear from others):
- Queueing/polling cycles in some ground networks
- Fallbacks between VDL2/ATN and ACARS paths
- DSP congestion at peak times
- Hidden store-and-forward logic in particular regions
- Local ATN router bottlenecks that no one talks about
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.
Joined: Nov 1999
Aviation Qualifications: ATPL
Posts: 3,139
Likes: 740
From: UK
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.
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.
Joined: May 2026
Aviation Qualifications: ATPL
Posts: 5
Likes: 2
From: Pacific
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.
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.
Joined: Mar 2002
Posts: 958
Likes: 55
From: Surrey, UK
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.
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.
Joined: May 2026
Aviation Qualifications: ATPL
Posts: 5
Likes: 2
From: Pacific
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.
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.
Joined: Feb 2010
Aviation Qualifications: CPL
Posts: 361
Likes: 28
From: Vienna (FAA CPL/CFI)
Joined: May 2026
Aviation Qualifications: PPL
Posts: 1
Likes: 0
From: South Africa
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.
), 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.
