Metering on the Network

Shane VanHoven

  • Mentors
  • 120
    • View Profile
Metering on the Network
« on: March 16, 2018, 10:14:04 PM »
Sorry to everyone that flew to the FNO at MSP tonight who had to fly a 30 mile downwind, followed by a 5 mile base and a 30 mile final, only to be sent around because the guy departing on the runway didn't roll in a timely manner.

But nevermind that, I want to talk about how to meter airplanes on the network and start a discussion about how some other facilities manage volume during events. We spent most of tonight with the final out to 30-35, sometimes 40 miles, just barely keeping it all within the TRACON. The final spacing was about as consistent as what they hit at the real building, so at a glance, it seems clear that we stumbled along with more traffic per hour than they see IRL.

Every airport has an Airport Arrival Rate they can handle per hour, and it's always changing depending on weather. How does a facility on the network meter arrivals so that we never surpass, say, 80-85% of the real AAR (Less than 100% to account for voice latency issues, disruptive pilots, and and controller inconsistencies)?

We all know that there isn't any particular program design specifically for metering arrivals, so we have to improvise. I'd love to hear everyone's methods and opinions.

Toby Rice

  • Members
  • 428
    • View Profile
    • ZJX ARTCC
Re: Metering on the Network
« Reply #1 on: March 16, 2018, 11:30:25 PM »
I just do holds. Lots of holds. Pilots complain about the wait? They shouldn’t, especially since realism is something pilots (and controllers) are always hoping to achieve. I’d say it’s pretty realistic to fly into a big airport on a Friday night and have massive delays for traffic flow.

Shane VanHoven

  • Mentors
  • 120
    • View Profile
Re: Metering on the Network
« Reply #2 on: March 16, 2018, 11:52:05 PM »
Also just thought of another topic, what do you do for OTHER  facilities' FNOs? When the ARTCC adjacent, a even the 2nd or 3rd tier, how do you help a controller 500, 700, or 1500 miles away?

Ryan Savara

  • ZAU Staff
  • 23
    • View Profile
    • Chicago ARTCC
Re: Metering on the Network
« Reply #3 on: March 17, 2018, 12:22:20 AM »
Also just thought of another topic, what do you do for OTHER  facilities' FNOs? When the ARTCC adjacent, a even the 2nd or 3rd tier, how do you help a controller 500, 700, or 1500 miles away?
Today I attempted to get our cab controllers to give an alternate routing, however they didn't follow it. Ideally, it would have alternating routes on departure, but we made it work. Usually it's speeds and turns/holds, or if you have friendly neighbors, who can help take some of the stuff if you can't get screwed.

Daniel Everman

  • ZMP Staff
  • 98
    • View Profile
Re: Metering on the Network
« Reply #4 on: March 17, 2018, 12:56:29 AM »
I just do holds. Lots of holds. Pilots complain about the wait? They shouldn’t, especially since realism is something pilots (and controllers) are always hoping to achieve. I’d say it’s pretty realistic to fly into a big airport on a Friday night and have massive delays for traffic flow.

Holds are a short-term solution though. You're just placing an extra burden on your enroute controllers if you don't also implement flow control at origin airports too. At ZLA we do call for release going to the main featured airports for intra-ZLA traffic. It works quite well, and you don't have enroute suddenly trying to merge traffic coming out of L30 in with the ANJLL flow, which is easily our busiest arrival into LAX during events.

Also just thought of another topic, what do you do for OTHER  facilities' FNOs? When the ARTCC adjacent, a even the 2nd or 3rd tier, how do you help a controller 500, 700, or 1500 miles away?

15 MIT, compatible speeds if it's a neighbor unless they want something else. At the ZOA FNO earlier last year when they were down to one runway for landing at SFO due to storms we had call for release for anything going to SFO outside of LAX. At LAX we were launching departures every 3-4 minutes. All of our tier 2/3s at ZLA are pretty far away so we generally don't have so much traffic going to event airports that we need to implement some sort of metering.

Today I attempted to get our cab controllers to give an alternate routing, however they didn't follow it. Ideally, it would have alternating routes on departure, but we made it work. Usually it's speeds and turns/holds, or if you have friendly neighbors, who can help take some of the stuff if you can't get screwed.

Letting your neighbors sort it out is highly dependent on how much space you have between your boundary and their arrival airport. In ZLA if ZLC/ZDV are handing me ties where the ANJLL merges (which isn't their fault - it's hard to see those things coming so far away, at least on VATSIM) I have 300 miles to sort it out and get a good stream going into SCT. If the KKILR is busy (which it always is during events, everyone loves the ORD-MSP flow) I have about 100 miles between the ZMP-ZAU boundary and the ZMP-M98 boundary to sort it out if things aren't spaced out well. If my neighbor isn't doing their job then I'm probably in for a rough time.

Josh Glottmann

  • Mentors
  • 190
    • View Profile
Re: Metering on the Network
« Reply #5 on: March 17, 2018, 09:14:39 AM »
This is a useful resource for getting an idea how many arrivals an airport can handle per hour based of a certain configuration.
Here's San Francisco's for instance:

As you can see, our arrival rate drops by over half if we went up using a single runway in IMC (as we did during an FNO last year).

Matthew Bartels

  • Members
  • 512
    • View Profile
Re: Metering on the Network
« Reply #6 on: March 17, 2018, 09:32:20 AM »
When I’m working a tier 2/3 center for an event, I put tons of space between aircraft bound for the event field 25+ MIT if I can do it.

That way tier one has plenty of holes to fit in their originators and hopefully allows for a bit of extra space to allow for voice lag, slow pilots, and the fact that many of our controllers are not real world professionals.

This happens so far out that most pilots don’t even realize they’re being metered or delayed.

The biggest problem with trying to meter VATSIM pilots is the disconnect button. If they don’t like the idea that they’re gonna have to sit on the ground for a half hour  to fly from ORD-MSP, they’ll just disconnect and reconnect airborne. And that causes worse problems than had tower just let them go on a penalty vector where we then know he’s coming.

Jeremy Peterson

  • Members
  • 250
    • View Profile
Re: Metering on the Network
« Reply #7 on: March 17, 2018, 09:37:54 AM »
Sometimes what we do in New York is Call-for-Release (CFR). If I’m the TMU for the event, I’ll usually be asking ZBW—or at the very least, BOS—for CFR for all flights coming to the designated airport. That way, I can look for appropriate gaps in enroute/arrival flow to fit in aircraft. Downstream centers can do this too; for instance, often times we get a heavy arrival stream from ATL at some point during the event. ZTL is a tier 2 center and admittedly, we have very little infrastructure to communicate with them so we ask ZDC to have them either provide MIT, reroutes, or ideally, CFR to either our TRACON, Center, or just between them (ZTL to ZDC).

Additionally, we have implemented CFR for ZOB and CZY, where Toronto traffic is heavy.

CFR is pretty much as close as we can get to using all available arrival capacity efficiently without creating excessive delay through ground stops and holding. All that has to happen is the tower calls either an enroute controller or the TMU requesting CFR and asks for a release time. They have 2 minutes before the time and 1 minute after the time to release that aircraft or else they will have to ask for another time.

Alternatively, if you know the demand before an event (like through signups where you have a flight list), you can construct a ground delay program to schedule aircraft. This is the most effective method of controlling your arrival rate because it restricts it to a certain number. You break each hour into segments and schedule aircraft to each block leaving a certain number of slots empty to account for unscheduled traffic (pop ups). Unfortunately, while often being the most effective method of controlling your arrival rate, it is the most time consuming and relies on a high level of controller-controller and controller-pilot cooperation and rarely ever suits events in VATSIM due to the lack of that cooperation.

Finally, for short term periods of excess demand, a ground stop is usually sufficient. The scope is important here and must be determined before implementing the GS. If there is excess demand for MSP and much of the future traffic isn’t airborne yet and originated from ORD, MDW, and MCI, then a tier 1 ground stop would suffice. If you have a heavy arrival stream from DEN and there are 28 more departures not yet airborne, bound to MSP, then a single-airport (for DEN) is all that’s needed and anything more than that would generate excess delay. If there is excess demand from many ARTCCs, all scheduled into MSP and not yet airborne, then an ALL+Canada GS might be most effective.

Oh, and for reference, there have been times where 40 MIT for ZTL to ZDC wasn’t even enough for spacing LGA arrivals and we had to seek other solutions. One thing we did was implement a mandatory reroute from the FAA Playbook that swapped the arrivals to come through ZOB and this alleviated congestion some. ZDC also did a great job in creating space for us while that was happening. If I remember correctly, BOS didn’t have a whole lot of traffic coming in so nothing was necessary with them, though if it were a problem, I would’ve had them on CFR.

Nickolas Christopher

  • ZLA Staff
  • 112
    • View Profile
Re: Metering on the Network
« Reply #8 on: March 17, 2018, 11:51:02 AM »
We like to use expectation management also. When we have a pilot or VA-organized event, we ask the coordinators to ensure pilots know that delays may be expected depending on traffic and weather conditions. We’re going to do our best, but you can only fit so many planes on a single route. Getting that relayed to the pilots helps clear up issues before they start.

To address pilots who disconnect and then pop up in the air: they’re going to get vectored out of the way. Sequencing a disconnect/pop-up aircraft into a existing stream in front of aircraft that waited their turn is providing a form of priority.

Don Desfosse

  • VATSIM Leadership
  • 7587
    • View Profile
    • http://
Re: Metering on the Network
« Reply #9 on: March 17, 2018, 12:48:27 PM »
To address pilots who disconnect and then pop up in the air: they’re going to get vectored out of the way. Sequencing a disconnect/pop-up aircraft into a existing stream in front of aircraft that waited their turn is providing a form of priority.
Excellent answer.  "Proceed direct Outtadaway VOR, advise when ready to copy holding instructions...."

Ryan Geckler

  • Mentors
  • 453
    • View Profile
Re: Metering on the Network
« Reply #10 on: March 17, 2018, 01:16:22 PM »
Today I attempted to get our cab controllers to give an alternate routing, however they didn't follow it. Ideally, it would have alternating routes on departure, but we made it work.

This is where you need to start prodding your cab guys to do some work. By just accepting it as is, you aren't helping yourself. Alternatively, you issue the reroute in the air.

Quote
or if you have friendly neighbors, who can help take some of the stuff if you can't get screwed.

Any time!

Brad Littlejohn

  • Members
  • 154
    • View Profile
Re: Metering on the Network
« Reply #11 on: March 17, 2018, 03:01:52 PM »

Just going to add this in as this should pretty much be common knowledge for all of us.

This is where sequencing at the Ground/LCL lvel comes in. If given the MIT via TMU from adjacent sectors, the LCL controller, especially the Ground controller can create that MIT by sequencing flights not going to the sector hosting the FNO between those that do. if that can't be done at the GND level in time, intersection departures would create that as well. For example, if SFO hosts the FNO, and I have 6 flights that are heading up that way, instead of holding up the entire conga line, I'll pull a LAS or SLC-bound aircraft(s) out of the line, TIPH them at an intersection, launch them, then get the next SFO-bound aircraft out. That artificially creates that MIT, without having to manage it by airspeed further along the higher positions. That's one way to properly get that MIT spacing at least from 1 - 3 different airports.

Another suggestion: Could TMU be used for Call-for-Release procedures? I'm not talking in getting the release from the TRACON, but in particular for the featured airport for FNO, could the local controller not only get the release from the TRACON (for the TRACON's airspace), but for the release for the aircraft going to the FNO airport and get the window for their departure? Sorta like combining metering with calling up for oceanic clearance, and getting the expected window for when they should reach the sector in question.

I'm trying to brush up again on all of the call-for-release procedures, so my memory is a bit rusty there.

BL.

Jeremy Peterson

  • Members
  • 250
    • View Profile
Re: Metering on the Network
« Reply #12 on: March 17, 2018, 03:16:24 PM »
Another suggestion: Could TMU be used for Call-for-Release procedures? I'm not talking in getting the release from the TRACON, but in particular for the featured airport for FNO, could the local controller not only get the release from the TRACON (for the TRACON's airspace), but for the release for the aircraft going to the FNO airport and get the window for their departure? Sorta like combining metering with calling up for oceanic clearance, and getting the expected window for when they should reach the sector in question.

This is usually how we do it for ZNY. Either the EC or dedicated TMU will make sure the appropriate lines of communication are open for release time coordination. For example, during the Eastbound CTP, I was working with the ZBW TMU to coordinate releases that weren't initially scheduled through the official booking channels. ZBW had heavy enroute volume and departures from EWR or PHL bound to Europe were on CFR. EWR Tower would relay me flight info they were requesting to release and I would call ZBW TMU and ask them for a specific wheels-up time. EWR Tower would be responsible for getting that flight of the ground within 2 minutes prior to 1 minute after that time or a new release would have to be coordinated.

In the real world, CFR isn't always involving the ARTCC (or for N90, the TRACON) TMU; sometimes the tower only has to pick up the phone (unless they have a shout line or something) to the TRACON or ARTCC controller above them and request a specific release. However, other times TMU or specific TMU personnel are aware of the CFR procedures being in effect and participate in coordinating the releases so that controllers can focus on more immediate things.

Steven Perry

  • VATSIM Supervisors
  • 15
    • View Profile
Re: Metering on the Network
« Reply #13 on: March 17, 2018, 04:23:02 PM »
Different winds & temps aloft.  Simulator stutters and hiccups.  XPlane running at a reduced rate without the pilots realizing it.  There are a number of reasons why strategic metering doesn't work very effectively.

If we were to give metering a real try, I think VATUSA has to own it and do it week in & week out.  We have no fancy software and the number of variables we deal with exceed those in the real world.  Its going to take trial and error to build some proficiency.  It's also going to require some people sitting out of the fun of actual controlling.

Having each ARTCC attempt to do it 3-4 times a year isn't going to cut it, in my opinion.  I doubt anyone is going to volunteer to be the TMU for every event.


Shane VanHoven

  • Mentors
  • 120
    • View Profile
Re: Metering on the Network
« Reply #14 on: March 17, 2018, 05:36:17 PM »
Different winds & temps aloft.  Simulator stutters and hiccups.  XPlane running at a reduced rate without the pilots realizing it.  There are a number of reasons why strategic metering doesn't work very effectively.

Which is why you'd have to shoot for 20-30% less than what the airport could handle at max capacity.

I doubt anyone is going to volunteer to be the TMU for every event.

You'd be surprised.