"Negative request". And the ATC self-overload paradigm

General Discussion Pilot Talk
1

Recently, I had one of those flights that highlight what, in my opinion, is the recurring weakness of the current “top-down” implementation on VATSIM.

I was inbound to Frankfurt-Hahn (EDFH) on a long direct to FH515 (ILS21 fix, 15.6 DME, 5000’+). Passing abeam EDDF at FL250, I was told by Rhein Radar to contact Langen sector below. EDDF wasn’t particularly busy — yet the controller was continuously rattling out instructions for both Frankfurt and smaller fields in the area, including detailed taxi/gate clearances.

On check-in I waited patiently, as frequency was a wall of chatter. Eventually I got further descent (7000’, then immediately 5000’) and a direct ILS21 clearance. With energy management already stretched, I requested extra track miles. The response was: “Negative request!” — full stop, and the frequency moved on.

That’s not a standard phraseology, IMO, not a service-oriented response, and frankly not realistic. West of Hahn was empty, and a simple dogleg would have solved the problem. In real life I would insist and get the extra miles. On VATSIM, I was left wondering: argue on frequency? improvise and take the extra miles on my own? disconnect? None of those feel like good options.

Let me be clear: German ATC is almost always exemplary, and this post is not about an individual controller. It’s about the recurring pattern of CTR positions attempting to “micromanage” every clearance, taxi route, and VFR request across multiple fields at once. That leads to exactly the kind of overloaded, distracted service I experienced — and pilots stuck in situations where there’s no safe, realistic way to comply.

Other pilots on this forum have raised the same issue:

  • [When VATSIM stops being fun – Chase Stigberg]
  • [Unable to fly due to unrealistic ATC assignment rules – Gabor]

We all see the same symptoms:

  • CTRs drowning in radio clutter from minor airfields and excess attention requests
  • Pilots forgotten on arrival or descent because bandwidth is used on gate assignments.
  • Unrealistic refusal of reasonable pilot requests, not because of airspace constraints but because of workload.

My view: CTR should provide core enroute and approach service only, and let minor airports self-manage via advisory/UNICOM. IFR clearances on the ground? Sure — but no need for taxi micromanagement. Departures can call airborne passing an altitude, level or fix. That’s both more realistic and more sustainable.

So my question: Why is this problem, which surfaces in thread after thread, still not addressed at policy level? With traffic steadily growing, GCAP soon in force, and controller workload already at the breaking point, isn’t it time we draw a line between “providing service” and “trying to do everything everywhere at once”?

Curious to hear the thoughts of both pilots and ATCOs.

Cheerio!
Cristian

2 Likes
2

In principle I agree with you and that’s the way that I provided CTR-services, when I was still allowed to staff my usual CTR-positions (currently I cannot be bothered to regain my “endorsements” and all that unnecessary stuff). With some virtual controllers there seems to be a wrong mindset: they rather close their sectors than simply reduce their service level. As you wrote: IFR clearances: yes. Detailed taxi instructions: not when it gets overly busy! As a CTR-controller I rather have pilots call me at the holding point, ready for departure, because I do not want any surprises. But by (temporarily) removing the workload of managing ground movements one could get their head out of the noose of frequency saturation and get ahead of the game again.

People need to “grow some balls” and do so.

EDIT: typing error

2 Likes
3

Well referenced and written Cristian. I hope we get some comment and progress on this. I have had situations where I have continued on a radar vector and couldn’t get a word in to remind the controller I was now OCTA and below MSA. I think some of it is implied skills, by that I mean the need to be a good controller means you have to control everything rather than orchestrate. As an example there is a tendency to take IFR aircraft off published arrivals and provide vectoring. That may be ok if traffic is LIGHT, but it increases voice traffic and decreases situational awareness.
In reality (which I believe most ARTCC are chasing) there would not be one ATCO covering the area we do on VATSIM. I don’t think there is a real world where one person provides ATC services on the ground at small airports up to enroute traffic.
Hope you can achieve some movement Cristian.

2 Likes
4

The ability to shed workload had always been assumed as a “reasonable think to do”, but was codified in GCAP in 2023. You mention something about GCAP “soon in force”, but it’s been active for a while now. So, it has been addressed at policy level. If you’re finding individual controllers that are not utilizing that tool in their toolbox, I’d suggest providing constructive feedback (like your example, above) to the ATC facility.

Facilities and controllers have the latitude to decide what approach, e.g. reduction in top-down or logging into a smaller airspace, works best for the situation. This was a very thoughtful approach, as history and culture varied across the globe in terms of how certain facilities, divisions and/or regions preferred to address the issue. Although there may have been cultural preferences, we very consciously left it open ended in policy as to how such situations could be address.

Here’s the relevant section from GCAP:
4.6(d) If a controller finds themselves overloaded by traffic, they are permitted to provide a
reduced service to pilots controlled top-down. In extreme cases, withdrawal of topdown control from an airport may be required; however in such cases controllers
should consider whether logging onto a smaller/split Position might be more
suitable.

I hope this helps.

2 Likes
5

One issue might have been communicating your need for descent room as a request? I don’t know what phraseology you used of course, I’m just guessing based on the quoted response. Something like that is an operational requirement though; in reality I’d have phrased it as “we’ll require…” and so that’s the tactic I’d take on Vatsim too. I’d have just told him what I was doing. I believe even on Vatsim the PIC is always gonna win that one.

I agree with the basic point though; controllers aren’t always load shedding when they should and it can lead to a comically unrealistic level of freq saturation. NY during a heavy bank has nothing on some Vatsim sectors lol.

1 Like
6

As you quite rightly wrote, there are cultural differences and in some regions it is frowned upon reducing service levels. GCAP states clearly that is an option to logoff and open a smaller sector, but it is not a requirement. Just reduce the level of service provided (e.g. ground movement control) and keep reviewing the situation to check if the situation improves.

2 Likes
7

Yes, correct. On VATSIM, if a frequency is that busy, I’d even come along with a solution for my problem. This will help the controller in taking a quick decision. In the situation of the OP I’d have requested a 360 turn over the intermediate fix, or similar. The airport that he was flying to is a secondary airport with very little traffic and he probably was the only guy inbound at that time.

IRL we’d ask for “request x more track miles to lose altitude”.

1 Like
8

First, thank you all for the thoughtful and very valuable feedback!

Phraseology point (Andrew & Andreas):
To clarify, my request was: “Unable, too high, request more track miles please.”
That’s already structured as → inability → reason → resolution, and I made it politely, not assertive - I already noted the burden on the controller. So I don’t think the problem was wording. I absolutely agree that sometimes bringing a proposed solution (orbit, 360, dogleg) can help the controller decide faster — but in this case I expected at least some form of workable solution back, rather than a flat “negative request.” (which I still don’t get what it was supposed to mean)

On GCAP (Don & Andreas):
You’re right — GCAP 4.6(d) does provide the option for controllers to reduce top-down service if overloaded. But as written, it says “are permitted”, not “are required”. So in practice, whether that tool is used comes down to individual will, habits, and cultural norms. I’m not convinced this is being consistently trained or emphasized.

The crux of the issue:
When a single controller runs multiple sectors, they are forced to constantly switch radar layouts, zoom levels, monitor multiple ATIS/weather contexts, and juggle traffic from major and minor airports simultaneously. That is beyond human powers if traffic is even moderate.

Let’s not forget — the 2002 Überlingen tragedy ((mid-air-collision between DHX 611 and Bashkirian-Airlines 2937) happened for exactly this reason: the SkyGuide ATCO was handling Zurich ACC and Friedrichshafen approach simultaneously. Traffic was low, but the workload complexity was enough to cause a catastrophic oversight (combined with many other factors, but that one was decisive, IMO). Of course, VATSIM is not real life — but why should a virtual controller voluntarily take on a similar impossible burden, only to become stressed, ruin his precious hours online and risk snapping, while pilots get a degraded experience?

My position remains simple:
I’m very happy to have CTR online for:

  • Flight plan clearance/validation (maybe automated, as already is at some airports)
  • Smooth enroute handling
  • Properly-timed descent and arrival sequencing

But I don’t need CTR to be my GND, DEL, and TWR at a minor airport, nor to micromanage every VFR and taxi clearance across the region. With due respect for all the hard and sometimes super-human effort, that just adds noise, not realism…

C.

2 Likes
9

No, the accident of Überlingen happened, because the crew of the Tupolev was not properly training in the use of TCAS. They were trained in the days of the USSR and back then the rule “ATC instructions are not to be disregarded under any circumstances”. This in combination with the lack of understanding of how TCAS really works caused the collision.

1 Like
11

In my opinion, TCAS was the final line of defense, a failsafe that unfortunately failed - for the reason(s) you already mentioned. The ATCO’s primary role was (is) to prevent such a dangerous situation from developing in the first place. With all due respect for his memory (RIP!), he did not fulfill that responsibility that night. However, that is a separate issue.

3.2 CAUSES
Immediate causes:
• The imminent separation infringement was not noticed by ATC in time. The instruction for the TU154M to descend was given at a time when the prescribed separation to the B757-200 could not be ensured anymore.
• The TU154M crew followed the ATC instruction to descend and continued to do so even after TCAS advised them to climb. This manoeuvre was performed contrary to the generated TCAS RA.

From the systemic causes:
• Management and quality assurance of the air navigation service company did not ensure that during the night all open workstations were continuously staffed by controllers.
• Management and quality assurance of the air navigation service company tolerated for years that during times of low traffic flow at night only one controller worked and the other one retired to rest.
(BFU AX001-1-2/02, May 2004, p. 110)

12

Peter was a very competent ATCO who was murdered after this accident. He was setup by his employer to fail, that night. The crippled systems that he had to work with, without a second controller, at two different screens. Outrageous.
Yes, he made a mistake and the incompetent application of TCAS-commands (it does not provide “advisory messages”, but “command” messages that override ATC instructions at all times) caused the accident, ultimately.

13

For me, VATSIM is all about Top Down Service, as I choose my DEP and ARR airports exclusively on the (scheduled!) availability of CTR or APP controllers to get maximum and 99% certain ATC coverage.

In @851732 Cristian: In your specific case, ATC should have just terminated service on his EDGG frequency and staff a smaller sector, like only EDDF_APP.

14

I don’t think this is unique to a particular region and it’s down to the workload management skills of the individual controller. I won’t name names or locations as it’s not relevant, but more than one I’ve had to go around when I wasn’t cleared to land, because a CTR controller was busy giving clearances to aircraft on the ground. Ultimately this required more work by the controller to vector me around for another approach in between other traffic, when a simple “ABC123 stand by, break break, XYZ456 cleared to land” would have saved a lot of work in the long run and ABC123 getting their clearance 10 seconds later wouldn’t have been the end of the world.

1 Like
15

That happened to me recently as well. On short final I was told “expect late landing”, but the controller then got tied up with pattern traffic and ground clearances. I called twice that we were on short final, and eventually had to go around on my own. Total traffic? Three aircraft, including me.
That’s not a cultural issue, though, it’s tunnel vision. Too much focus on micro-managing every call in sequence and focusing on a previous mental picture, while losing sight of what’s most critical, i.e., landing traffic. This pattern repeats elsewhere, too — frequencies so saturated with instructions that it’s nearly impossible for anyone new to check in unless they’re already part of the controller’s mental “bubble.”

And it goes hand in hand with what I’d call over-controlling: a higher level traffic authority (CTR, APP) giving step-by-step taxi instructions (right on X, left on Y…), or repeatedly chopping descents and climbs into small segments. That only increases frequency congestion and complexity. This is exactly why we have SIDs, STARs, and transitions/vias — if traffic density gets serious, the better option is to let the published procedures do their job, and just supervise it to ensure a nice & continuous flow.

But, again, that’s not about the “top-down” issue in debate here, but about the personal way and capacity of doing things, and good/bad practices.

2 Likes
16

That’s my point. It’s not a request and so I wouldn’t use the term. “We require”, or “we’ll need”, or “we are flying” more track miles would be better options. Requests can be denied, so this isn’t a request, that’s all.

17

Or just go-around…

18

Well, I mean you can always go around, but how is that relevant here? You know what you need to fly to make the approach work, so why wouldn’t you just communicate that that’s what you need? Why would you allow a controller to drive you unstable and force a go around?

1 Like
19

Yes, I do agree, but if ATC denies such a much needed and vital request, show him the consequences of his actions and your next call is “going around” or “request new vectors to final”.

2 Likes