atc-discussion Reforming Oceanic

[Harry Sugden]

With reference to the below thread here:

In advance of CTP either this October or next April, I personally think it is time we accept that the data we have available on VATSIM enables a simulation of ADS-B with no delay. I have been doing some digging with the limited material that's out there, but from what I can glean, 14NM lateral/longitudinal seems a sensible separation standard that we could adopt in advance of the real world ICAO approval that will no doubt come in future.

What I'm wondering is whether there are any pilots or Shanwick heads amongst us that might be able to contribute to a discussion here about how this could work on VATSIM...

1. Is the need for PIREPs as we know them completely negated, or are they still given?
2. If they are still required, due to the lack of integrated CPDLC on VATSIM, would a report at the entry point, 30W and exit point suffice?
3. Does 'controlling' Oceanic become more like we are used to on our usual en-route positions, in that controllers monitor the live picture and intervene with speed restrictions/level changes as required?
4. Added: What should pilots squawk?

The key question: how do we use the live data feed, SELCAL, and only limited CPDLC uptake we have both sensibly and realistically during both normal operations and CTP?

I put up this post in no official capacity, but because I noticed in the Q2 BOG minutes that CTP was viewed as needing changes or scrapping. I avoid Oceanic like the plague since it got so big - but I'd come back if we could reduce the separation standards! Shall we all club our ideas together and work out a virtual Oceanic future?

Edited August 22, 2020 by Harry Sugden
Added Q4

[Harry Sugden]

Well it looks really sad that I didn't get a response in this thread, but it also looks as if this discussion is likely to take place outside of the forum now. I thought I'd best just post an update here else I might be at risk of looking like an idiot... 😄 

For those that are interested, behind the scenes myself and a few others are proposing that the virtual Oceanic environment moves toward using the FSD data - visualised through the controller client - as a direct imitation of ADS-B, allowing controllers to actively control the traffic, rather than relying on outdated procedural separation. As long as voice congestion can also be eliminated through a natTRAK-esque system that acts as a CPDLC-equivalent, we believe it may be possible to head towards reducing longitudinal separation to something in the region of 20NM/3 minutes, and reducing lateral separation to something in the region of 14-20NM.

[Henry Cleaver]

Having controlled Oceanic for CTP for what feels like most of the events, I think there has been a lot of movement away from pilots making position reports. For some it's a novelty, but trying to get in on some frequencies is too difficult so many just don't bother. I seem to recall last time round there were whole tracks that were not allocated a controller.

I wonder whether there is the controller capacity during the event to actively control each person though? It would be a lot of work for the first sector then once they're pointed on the right way it should work out. However there is still a lot of monitoring required for a lot of targets over a large area.

[Trevor Hannant]

if you're going to reduce controller workload by "automating" some of the position reports via a web front end, then it really needs to be done right - or at least have a focussed team behind it that can bring it to where it's needed quickly.   

If pilots are to enter their own posreps, then to actually help out a controller, it's going to need to:

- compare the planned time at a waypoint against actual time
- flag the flight up if it's out by +/- a tolerance
- flag up a flight that is too close to someone in front at same level

...plus potentially other scenarios.   For the amount of traffic that utilises the tracks on a CTP event, I'd suggest the above is the minimum you'll need for any reporting system.   Whether an aircraft is ADS-B capable or not, it still gives a position report (at this time).  And as Henry says, it's a huge amount of airspace with a lot of targets to keep an eye on using the Mk1 Eyeball for separation...

Does anyone have any screenshots/logs/stats on how many aircraft were on each track at the traffic peak?

Edited August 24, 2020 by Trevor Hannant

[Fraser Cooper]

Unfortunately, Cross the Pond is too big now.

The only way I see the ocean working now is if we have fixed A-B routes/destinations,

LEMD - KMIA

EGLL - KJFK

EKCH - CYYZ

etc.

Where the crossing of routes is not needed.

A couple of NAT tracks per city pair.

[Alex Mollen]

As a pilot, I enjoy the "special" Oceanic procedures (NATS, the clearance and position reports). Even though I generally do not fly a lot of long haul, I make an exception for Cross the Pond and other cross-Atlantic events.

I guess technology progress and introduction of ADS-B will make cross-Atlantic more like a regularly controlled long haul like e.g flying coast-to-coast in the USA. Easier, but less special. While generally I favor VATSIM mirroring real life, I would look back to the old procedures with a degree of melancholy once things change.

I do agree something needs to be changed. In last Saturday's JFK-AMS event, both Gander and Shanwick controllers had to cope with too much frequency congestion. Once Pilot A made his position report, Pilots B, C and D would all be stepping on each other to be next. Just too many flights per controller. In addition, some pilots are ill-prepared, don't know the procedures, clog the frequency. Others are rude and just blurt out a full position report on first contact. All that adds to the confusion. One Gander controller logged off halfway in desperation, he was doing an admirable job, but just got overwhelmed and likely a bit frustrated by all that.

We clearly do need to address the frequency congestion. Acknowledging that we cannot force the Oceanic centers to have 10 controllers online at each event, there are other possibilities while we discuss the long term future. One compromise could be to encourage position reports via text. Another would be reports via the Nattracks website. I am not sure what the technical issues are with the website. All I know is that neither text reports nor the website were mentioned, even as the chaos increased. To me, either would have provided relief (but needed to be mentioned/promoted in the event brief or by the controller).

Maybe it's not as easy as I believe. I am willing to be corrected.

[Harry Sugden]

I would not personally see the need for pilots to submit position reports manually - this is the job of ADS-C in real life, if I'm not mistaken. The kind of reform I would be looking for is one where we use the data we get fed as if it were the (effectively) live position reports from ADS-B. Voice congestion would ideally be completely eliminated through the mandatory (at least during CTP) use of a natTRAK-esque system that acts as a CPDLC-link - so it wouldn't be for submitting position reports, but for sending/receiving communications with controllers and linked to the controller's tags/display.

3 hours ago, Trevor Hannant said:

If pilots are to enter their own posreps, then to actually help out a controller, it's going to need to:

- compare the planned time at a waypoint against actual time
- flag the flight up if it's out by +/- a tolerance
- flag up a flight that is too close to someone in front at same level

I think we should just stop them, full stop. For clearance requests however, I do think that some sort of natTRAK-esque system could very easily require the pilot to input the current sim time alongside their estimated time, so as it can perform adjustments automatically.

2 hours ago, Trevor Hannant said:

And as Henry says, it's a huge amount of airspace with a lot of targets to keep an eye on using the Mk1 Eyeball for separation...

Very true, and why the most ideal solution would make good use of the separation tools that certain controller plugins have championed. The web client vNAS and other Oceanic tools in the past have helped to identify conflicts based on position reports, so they could probably help with recognising conflicts based on live data too!

2 hours ago, Alex Mollen said:

Acknowledging that we cannot force the Oceanic centers to have 10 controllers online at each event, there are other possibilities while we discuss the long term future.

Indeed, we can never guarantee interest in controlling Oceanic, but I for one am put off by the current issues. It is a possibility that many might return if: the frequency congestion were eliminated; they had time to actually control rather than type in a spreadsheet and handle nonsense; and they were allocated a manageable level block of a single track.

2 hours ago, Fraser Cooper said:

Unfortunately, Cross the Pond is too big now.

The only way I see the ocean working now is if we have fixed A-B routes/destinations,

...

Where the crossing of routes is not needed.

A couple of NAT tracks per city pair.

I'm going to assume the CTP team are looking at something elsewhere. I think there are reforms we can make to Oceanic that would increase capacity, regardless of what happens with CTP. But yes, the current pairing of every departure airfield to every arrival airfield is nonsense; the fact we don't recognise Heathrow is always busy (event or non-event) is becoming nonsense; the crossing is a pain and needs to be limited. But in the UK at least, we are slowly seeing our Area capacity increase in line with the scale of the event!

---

Of course I am not underestimating the technical demands more than anything of any reform. But I think it's either a case of them happening rapidly and drastically, or we'll see even fewer numbers putting their name down for Oceanic! I see no reason to cling on to conventional position reports if this is a large part of the problem?

[Henry Cleaver]

14 hours ago, Harry Sugden said:

But yes, the current pairing of every departure airfield to every arrival airfield is nonsense

Traffic crossing over i think is more of an issue for domestic controllers at each end. Once they're on the NAT, it doesn't make a difference where they're from/to. It would be kinder on the domestic controllers if there was less crossing to sort out, however that may lead to longer delays with more separation required if everyone from a departure airport is going on the exact same route. At least with different routes they can be possibly alternated for departure.

14 hours ago, Harry Sugden said:

the fact we don't recognise Heathrow is always busy (event or non-event) is becoming nonsense

I think the non-event traffic is one of the biggest issues. Currently, it's allowed for anyone to fly anywhere; I don't see a way that can be changed. But having to provide control for these pilots on non-event tracks to stop them bumping into event traffic is a nightmare. It needs a whole controller team just to keep them separated. Add in people who go the opposite way! I'm not sure what the answer is to that problem, short of denying them entry to MNPS airspace and making them go above/below/around we're limited on options.

[Trevor Hannant]

You can ease the domestic issue though by utilising the different routes that head to the same NAT - and different levels.  For example, using today's track entering at SUNOT, there are 17 different routing options on CPT/UMLAT SIDs according to the SRD (not taking into account any notes on usage).   Even taking 5 of these on rotation with each having a specified flight level, you instantly get vertical separation when they hit SUNOT.

27R deps are 1 min separation between UMLAT and CPT SIDs.    If you're mixing these departures with slots that are varying the NAT levels also, then you've got 5 minutes between two aircraft at the same level - unless you spread over more than 5 levels giving you even more flexibility on that track.

 

[Cathal Boyce]

Thanks Harry for posting this.

I think this is something that needs to be changed and looked at before the next CTP ideally. 

As it stands, Shannon has to present traffic to Shanwick with time-based separation in place, which can go as low as 3 minutes on the PBCS tracks between FL350-390. They also no longer cross check the 20W waypoints (which is something we would have to do for every aircraft). The 19NM lateral separation is something they use on the tracks with ADS-C surveillance.

Position reports are still given, but almost exclusively via CPDLC. This would be equivalent to our NATTRACK system or something similar.

On 25/08/2020 at 09:22, Henry Cleaver said:

Traffic crossing over i think is more of an issue for domestic controllers at each end. Once they're on the NAT, it doesn't make a difference where they're from/to. It would be kinder on the domestic controllers if there was less crossing to sort out, however that may lead to longer delays with more separation required if everyone from a departure airport is going on the exact same route. At least with different routes they can be possibly alternated for departure.

I think the non-event traffic is one of the biggest issues. Currently, it's allowed for anyone to fly anywhere; I don't see a way that can be changed. But having to provide control for these pilots on non-event tracks to stop them bumping into event traffic is a nightmare. It needs a whole controller team just to keep them separated. Add in people who go the opposite way! I'm not sure what the answer is to that problem, short of denying them entry to MNPS airspace and making them go above/below/around we're limited on options.

I actually think that crossing traffic is less of a problem then it's made out to be. For us on High Level, it's never really the problem (that's the one bit we actually enjoy 😋) As you pointed out Henry, the non-event traffic is the biggest issue by a long shot.

During the abomination of Westbound in March, we had 890 aircraft use DINIM. 890!! That's all non-event traffic. EISN was literally uncontrollable and we were more staffed than ever. Non-event, for us, is always the biggest issue, and less so is the combination of event airports and crossing in our UAC airspace. 

Another problem for us is Oceanic clearances. As it stands, aircraft need to actually leave our frequency (in a radar control environment) for anything from 5 to 30 minutes! Sometimes we end up transferring someone over the East of Ireland to not even get them back before 15W... It ruins the fun of it.

The problem with that is we often get an aircraft returning to our frequency from EGGX with their Oceanic clearance, and suddenly they have 30NM to climb through 6 aircraft above them to get to their cleared level of FL390! That is also a massive problem which I'm not sure how to fix. The Oceanic spreadsheet (if it was kept updated) would be a good compromise, but it always seems to go out the window. That way, Shannon controllers can check what level EGGX assigns the aircraft and what level the aircraft is requesting. I think people underestimate how much of a problem this is for us.

Edited August 29, 2020 by Cathal Boyce

[Alexander Beavil]

Speaking from my views having controlled like the last 3 years worth of CTPs, and a few other oca events also, NATTRAK hasn't helped my enjoyment of the event (far the opposite actually). The whole reason for wanting to control oceanic is that it isn't standard area. Whilst I agree that something needs to be done about capacity in the oceanic area, i'd tend towards a strategy that allowed S3s (or perhaps lower) to get oceanic endorsements - there aren't really any skills that you learn controlling area that are actually useful for oceanic, because pretty much everything is different. The issue I have most with NATTRAK is that you can theoretically be far over capacity, but have an entirely silent frequency (as happened last CTP especially) - it just makes copying things across onto a spreadsheet rather monotonous.

Another thing that a number of people have pointed out is non-event traffic. From my view, i don't see it useful in the slightest that we restrict bookings to a level such that a majority of oceanic flights end up not having them - thus, it means that a majority of the traffic seen's activities aren't known in advance of them showing up, and we have very little way (or capacity to do so in the cases that we can) across the board to do anything about it. If we know in advance about say 80-85% of the traffic, we can design the routings used to spread the capacity more evenly.

My final point that stands with most oceanic (and some domestic stuff with gander/moncton/shannon/scottish) is that it'd be really handy to have a real-time spreadsheet/map/website showing exactly who is controlling what, and what frequency you should be on from a pilots point of view - there's nothing more annoying than having shanwick track and the shannon station you were talking to closes/splits/merges, and you've got no clue who you should be sending your planes to, or from a pilots perspective, who you should be with if you get confused.

[Magnus Meese]

I've been a bit out of the VATSIM OCA loop for a year and some, but this is an important thread!

Between aircraft which ticks all the boxes for the new ADS-B based system, separation is 14nm in-trail, and 17nm on crossing tracks. This works pretty much like normal domestic area control, except you still need CPDLC or radio operators to reach aircraft.

The next level down is basically what we're doing at least partially on the network these days already without maybe even thinking about it, when we're using parallel tracks spaced less than 1°/60nm apart, through PBCS. 5min in trail and half a degree laterally separated tracks, in certain conditions with certain equipment and certifications.

The lowest level is what we've been using forever, 10min in trail and/or diverging from the same track, 15 minutes if crossing or converging (i.e. joining from not the same previous point). Reducable by the mach difference thing.

 

Our biggest issue taking in use the new procedures is of course software. The OCA, especially EGGX/CZQX, should have a unified ES setup and (if required) a unified external controller tool i.e. website/spreadsheet/software. While we could just pretend VHF coverage is a thing across the Atlantic, I'd prefer we had a CPDLC system internally. Hoppie is great, but afaik there's nothing in it which integrates with ES and populates datafields automatically, which is what we would need for any CTP event using CPDLC. ES's text chat is unusable with it's magnificent maximum 4 lines of chat history, so at the moment an alias system is not good enough either, voice is our only option for the time being.

As for external tools, I must say my preference is the one made available on vnas.net. It feels a bit odd going to a VA for a controller tool, but the tool itself is cleanly designed and the last time I used it (early 2019) it had both a map plotting function based on the position reports inserted and some conflict detection, plus of course allowing multiple controllers to work with it at the same time which is great. I don't much like spreadsheets, though I know they are a simple and powerfull tool which also allows easy coordination. A web page solution could be a fantastic platform allowing both a unified controller tool, combined with a CPDLC interface for both pilots and ATC, automatic input of the reported data into the flight data, etc. I've seen what looks to be something along these lines from the Gander side, but I've not been able to look into them, and it seems a lot of new Gander controllers does not mention it in their controller info so I'm assuming it's not official stuff. We need something official.

When it comes to controlling, the main benefit of the real life ATM systems is of course that controllers don't have to manually review routes and find conflicts, that is all handled by the computers based on the data they're given. As you know, the whole point of oceanic clearances is to ensure separation is achieved against every other cleared OCA flight from entry til landfall, in case of RCF. When online as EGGX on any regular day I enjoy finding route conflicts manually, but that's not possible once the traffic passes a certain level, and CTP or real life traffic levels is many times greater than that threshold. This is also why I find the fact that CZQM is offering oceanic clearance without EGGX/CZQX online completely ridiculous, sure they're offering an added experience but it's not actually achieving anything at all, which triggers my old-man-yelling-at-clouds tendencies. 

Finally, for a CTP, planning is key. Like mentioned above, non-event traffic is a massive issue. I'm sure there are plans to improve how this is handled, I would suggest to move away from a single non-even track, and instead just limit non-event routes interfering with the tracks to the levels below the event flights. Any flight not interfering with the tracks themselves should be allowed any level, and maybe even be on odds/evens appropriate to their direction, just to simplify things. Clearance delivery should be given a lot of manpower, and clear rules should define which aircraft calls which frequency. There's also need for a few supervisory positions who ATCs can reach out to for coordination, relief, etc, though this is probably already a thing the last few events (I hope). Someone not speaking to airplanes is vital in an overload situation like this, because the cumbersome coordination tools we have aren't great for those situations.

 

EDIT: When writing this, I did not realise how far Gander has progressed on this front. I've noticed they've been doing a lot of training and staffing, but didn't know the pilot tools and web pages had come along so far. I've not played with natTRAK from either side yet, but from what I can see the entire OCA thing has been really progressing the last 1-2 years. Unless the UK has something in the pipes they've not told anyone about and it is really good, (edit 2: When Andrew Ogden releases his plugin, we're all set) the best thing IMO would just to support Gander in their development of both software and procedures and agree on a common set of procedures, controller tools, and ES-setup. A common Discord channel wouldn't hurt either.

 

Edited November 3, 2020 by Magnus Meese

[Alexander Beavil]

On 24/10/2020 at 17:30, Magnus Meese said:

There's also need for a few supervisory positions who ATCs can reach out to for coordination, relief, etc, though this is probably already a thing the last few events (I hope). Someone not speaking to airplanes is vital in an overload situation like this, because the cumbersome coordination tools we have aren't great for those situations.

I definitely agree with that - there is no excuse for anyone being in a situation where they don't know who to contact, be it a pilot, OCA ATCO/rad op or surrounding ATSU - even something as simple as a website that gives a map of exactly who is covering what right now, updated by a "network manager" on a regular basis, with a (team of) network managers working on routing, rerouting, and applying MDIs to aircraft dynamically to avoid overloading sectors, as well as actually monitoring the traffic levels in each sector - I feel like that last point shouldn't be too big of a technical issue to assemble. Little things can go a long way to improving the experience of ATCOs and pilots