- Tue Dec 05, 2017 2:24 pm
Drawing on RW experience I partly agree.
The types of flow I've come into contact with are
Slots or CTOT, Calculated Take Off Time
ADI, Average Departure Interval
MDI, Minimum Departure Interval
MIT, Miles in Trail
TNBF, Take off Not Before
TNAF, Take off not After
They are used for different things. MIT is a radar thing (mainly, I think there are places that use MIT for tower as well), all the others are tower based.
MIT is a requirement to have a certain amount of miles in trail for en-route aircraft. In other words as an en-route sector you will have to sequence. In some cases this is also done in such a way that you are targeting certain waypoints at certain times.
For real this is quite a big part of en-route control, and you can find flights on FR24 that have been sequenced en-route if you look in the right places. On vatsim however we sometimes forget this. Partly because our en-route sectors spend so much time doing top-down and coordination. Things that for real would be done by other controllers. Also because we suffer from a lack of C1+ controllers for these events we can't get the sectors staffed to the level we would want regardless.
This is always a major issue with these types of events, we simply do not have the en-route controllers required to optimise these sort of things. Also an MIT reduces complexity by reducing bunching, but if you keep firing traffic in at a higher rate than can be managed then the MIT is unsustainable.
CTOTs are issued by CFMU, the Central Flow Management Unit, in Brussels and they are generally used to control traffic flow over several hours.
CTOTs can be extremely complex, and include multiple restrictions both en-route and at the arrival airport. CTOTs however come with a -5/+10 takeoff window. This mean they are fairly blunt, therefore the longer flying time is used to look at the situation continuously and the flow can then be managed tactically. This can be things such as delaying some flights, short-cutting some, changing a few levels to reduce complexity and splitting the sectors. On Vatsim again we don't have the expertise (with a few exceptions), we don't have the tools (although that is changing) and we don't have the staff to do these things.
ADI and MDI are similar. An ADI require every 3 aircraft to be spaced by an average interval. So if an ADI is 3 minutes you can have something like a 2 minute gap, 4 minute gap, 3 minute gap etc.
An MDI has to be a minimum. So an MDI of 3 requires you to have a minimum 3 minutes between all aircraft on that route. Ie 3-3-4-3, but never 2.
These are generally used to stop bunching in sectors close to the airport. In other words Heathrow might get an MDI to protect a TC sector or something like the Dover sectors. Manchester might get MDIs to protect the Daventry sectors.
In general these are used to reduce complexity in sectors, not to reduce the flow through. If the flow needs to be reduced CTOTs are often used, sometimes in combination with an ADI or MDI.
TNBF and TNAF are generally used for short (often domestic) flights to reduce delay in the air or on the ground. For example if Dublin are fogged in a flight from Liverpool might be issued with a TNBF to keep it behind a stream of aircraft coming in ahead. Or conversly a TNAF to keep it ahead of other inbounds, thereby reducing air and ground delay and reducing complexity in the radar sectors.
So, with that background, my thoughts relating to CTP.
MDIs could be useful, but I think it would be to protect the en-route sectors, not the ocean. The ocean is so far away from most departure fields that by the point the flow reaches the boundary any MDI effect has been lost.
We could attempt a MIT solution, but that again is only really useful to stop bunching. Not to mention you need to find a quiet sector with the capacity to apply the MIT, I don't think we've got any quiet sectors during CTP.
The slot system used in theory should spread traffic out, but it also helps to keep track of who has booked and who hasn't. The system could be changed to track this in another way, but I don't know if it's worth it.
For me personally I think it would be worth spending time trying to optimise the system on the ocean and en-route more. We could apply more flow restrictions but this would mainly stop the near-airfield sectors from an overload, and I don't know if that's been a big issue?
I think what we're doing with routes is good and should continue. Ideally arranging the routes artificially to reduce conflict points and to try to avoid giving a single sector too many conflicts. It means longer distance for the pilots but on the whole I think it's a compromise worth doing.
I have said in the past as well that I think we should consider how we work the ocean. I have to provide a disclaimer though which is that I am not shanwick qualified, so feel free to shot me down if it's stupid. However my suggestions are based on what the RW guys do.
The RW system works either on CPDLC or HF. The HF is operated by radio operators who are not controllers. They can spend time to repeat messages several times and listen closely to the frequency because it is their only task.
You can also have several radio operators for a track, there is no need to keep them contained to a single track or flight level. You could simply pass an equal amount of aircraft to say 10 or even 20 frequencies, each manned by one person. This gives flexibility with closing and opening more frequencies based on traffic load.
We don't have nearly enough C1s to do this. But we do have plenty of S2 and S3s in the system. I am well aware of the restrictions in the current rules for frequency range. However I think it's worht exploring if S2 and S3 controllers could be trained as radio operators and be allowed to man a shanwick or gander frequency where they will take position reports and requests, and relay these to the controllers as well as relaying any controller clearance to the aircraft.
This means the controllers don't have to spend time managing a frequency, instead they can sit with a spreadsheet (or similar) in front of them and only input data and do the controlling. This is roughly how the real system works.
For real as well there are controllers providing clearances and en-route controllers. Put your more experienced controllers onto clearance where they receive and formulate clearances and nothing else. They are responsible for giving clearances that should work all the way through. If the clearances are safe then in theory the en-route controllers should only have to monitor the traffic and ensure any position reports and estimates conform with what is expected (and the clearances as needed).
Another thing to consider. For real they split en-route vertically, not by track. When I was there visting they had two en-route controllers for all of Shanwick (I think they had 3 or 4 clearance controllers most the time). This means that if your traffic is on different tracks you can ignore it as a conflict, you only work within each track (assuming nobody crossing at an angle, which for real there are but pretty rare for CTP I believe).
The only downside is that if you want to let someone climb you may have to coordinate with another controller, but for CTP we never really do any level changes on the track system anyway.
To me, again from the outside looking in, this seems like an easier way of working than to have one controller per track. Also if we can use some sort of off-load system with radio operators we could both reduce frequency congestion and give the controllers more time to do actual controlling rather than admin.
So on the whole, I do think we have things we could improve. However the main issue will always be staffing of en-route sectors. I don't think an MDI system is a bad idea, but use it for the right things. It can be useful to protect sectors close in, it will not make a big difference to the oceanic part of the event.