Miami Mega Ball 2019 Event Statistics

[Jeremy Peterson]

I was observing the event and monitoring ZMA sectors on my own, noting EFC times and airborne holding times using the VRC request list functionality. Here is what I found:

These manually collected data show a

• Total of 623.517 delay minutes (10:23:31)
• Maximum delay of 46.233 minutes (00:46:14)
• Average delay of 20.117 minutes (00:20:07)

The average expect-further-clearance (EFC) time was 14.000 minutes and ranged between 10 and 15 minutes.

5 aircraft were given airborne reroutes (though this number is most likely underestimated); 2 aircraft diverted. 37 aircraft in total experienced airborne delay.

Let me know if you can verify any discrepancies; otherwise I was impressed by the controlling in ZMA. It was handled well, considering an average airborne delay of about 20 minutes.

Note: if you would like a copy of the Excel file, email me at [email protected].

[Matt Bromback]

Do you have any data on ZTL delays? We had insane, almost un-workable amount of traffic leaving ATL for this event. I ran some quick numbers and came up with 122 departures vs 41 out of IAH.

I wish we had someone who could in real time determine putting aircraft on other routes into ZMA since the traffic load was so heavily on ATL vs IAH (which you don't know until the event is in action). We fall into these traps of "preferred routes, or event routes" It appears almost everytime this comes back around to actually NOT work. 

[Jeremy Peterson]

Do you have any data on ZTL delays? We had insane, almost un-workable amount of traffic leaving ATL for this event. I ran some quick numbers and came up with 122 departures vs 41 out of IAH.

I wish we had someone who could in real time determine putting aircraft on other routes into ZMA since the traffic load was so heavily on ATL vs IAH (which you don't know until the event is in action). We fall into these traps of "preferred routes, or event routes" It appears almost everytime this comes back around to actually NOT work.

My focus was on MIA so I don't have any data.

A suggestion would be to brief facilities on FYI routes that could be implemented dependent on a specific trigger like >15MIT passbacks from ZJX or >15min delays on ___ STAR. We utilized this during BOS FNO parking a JERES route for Potomac TRACON in the event that ROBUC became unavailable (which it did, and we implemented the route).

Another thing you could do is briefing and authorizing coded departure routes (CDRs) for quick flexible route options out of ATL. The thing to note, though, is the effect of the reroutes on the airspace (i.e., if ZMA is saturated, reroutes will not be effective if the enroute time delivers traffic too quickly to the Center).

Of course, all of these require (simple) coordination beforehand with all facilities involved.

I believe ZTL utilizes their STMC and ESP (Enroute Spacing) positions to handle CDRs, etc. ZNY uses a Departure Coordinator and the PIT to manage tactical reroutes; N90 has a Departure Coordinator TMC to manage N90 departures.

[Matt Bromback]

Do you have any data on ZTL delays? We had insane, almost un-workable amount of traffic leaving ATL for this event. I ran some quick numbers and came up with 122 departures vs 41 out of IAH.

I wish we had someone who could in real time determine putting aircraft on other routes into ZMA since the traffic load was so heavily on ATL vs IAH (which you don't know until the event is in action). We fall into these traps of "preferred routes, or event routes" It appears almost everytime this comes back around to actually NOT work.

My focus was on MIA so I don't have any data.

A suggestion would be to brief facilities on FYI routes that could be implemented dependent on a specific trigger like >15MIT passbacks from ZJX or >15min delays on ___ STAR. We utilized this during BOS FNO parking a JERES route for Potomac TRACON in the event that ROBUC became unavailable (which it did, and we implemented the route).

Another thing you could do is briefing and authorizing coded departure routes (CDRs) for quick flexible route options out of ATL. The thing to note, though, is the effect of the reroutes on the airspace (i.e., if ZMA is saturated, reroutes will not be effective if the enroute time delivers traffic too quickly to the Center).

Of course, all of these require (simple) coordination beforehand with all facilities involved.

I believe ZTL utilizes their STMC and ESP (Enroute Spacing) positions to handle CDRs, etc. ZNY uses a Departure Coordinator and the PIT to manage tactical reroutes; N90 has a Departure Coordinator TMC to manage N90 departures.

Thanks for the input!

So heres the thing with CDR's, they are great and expedite traffic flow out of a airport. We could of used some for this event, but who is to determine how many we issue? What is going to be the merge point for existing route (if any). How much MIT for either route(s). As far as I know we don't have any technology available for the network to deal with this. Talking about arrival aircraft rates, filling holes, etc...

As a example I was running TMU for a short time during the event, the times we issued some "STOPs to ZMA" for enroute saturation, it resulted in 40-70nm GAPS in the MIT. Plus we had some other internal issues that need to be addressed, but my point is I think its extremely hard to predict without software.

Unless are we OK with 30-40 A/C lines for takeoff at a airport like KATL for this type of event? resulting in 30-90 minute departure delays?

The summer is almost fully here and I can only expect this trend to continue in high traffic loads for events.

[Jeremy Peterson]

Do you have any data on ZTL delays? We had insane, almost un-workable amount of traffic leaving ATL for this event. I ran some quick numbers and came up with 122 departures vs 41 out of IAH.

I wish we had someone who could in real time determine putting aircraft on other routes into ZMA since the traffic load was so heavily on ATL vs IAH (which you don't know until the event is in action). We fall into these traps of "preferred routes, or event routes" It appears almost everytime this comes back around to actually NOT work.

My focus was on MIA so I don't have any data.

A suggestion would be to brief facilities on FYI routes that could be implemented dependent on a specific trigger like >15MIT passbacks from ZJX or >15min delays on ___ STAR. We utilized this during BOS FNO parking a JERES route for Potomac TRACON in the event that ROBUC became unavailable (which it did, and we implemented the route).

Another thing you could do is briefing and authorizing coded departure routes (CDRs) for quick flexible route options out of ATL. The thing to note, though, is the effect of the reroutes on the airspace (i.e., if ZMA is saturated, reroutes will not be effective if the enroute time delivers traffic too quickly to the Center).

Of course, all of these require (simple) coordination beforehand with all facilities involved.

I believe ZTL utilizes their STMC and ESP (Enroute Spacing) positions to handle CDRs, etc. ZNY uses a Departure Coordinator and the PIT to manage tactical reroutes; N90 has a Departure Coordinator TMC to manage N90 departures.

Thanks for the input!

So heres the thing with CDR's, they are great and expedite traffic flow out of a airport. We could of used some for this event, but who is to determine how many we issue? What is going to be the merge point for existing route (if any). How much MIT for either route(s). As far as I know we don't have any technology available for the network to deal with this. Talking about arrival aircraft rates, filling holes, etc...

As a example I was running TMU for a short time during the event, the times we issued some "STOPs to ZMA" for enroute saturation, it resulted in 40-70nm GAPS in the MIT. Plus we had some other internal issues that need to be addressed, but my point is I think its extremely hard to predict without software.

Unless are we OK with 30-40 A/C lines for takeoff at a airport like KATL for this type of event? resulting in 30-90 minute departure delays?

The summer is almost fully here and I can only expect this trend to continue in high traffic loads for events.

The specifics on CDR usage need to be coordinated both before and during their use. If ATL wants swaps onto the SSCOT but ZMA can’t handle, then clearly, don’t use that CDR. In the real world, a south Florida hotline would likely be activated to assist in this sort of thing.

Further, as far as enroute spacing goes, ZMA has a TBFM timeline so being able to look at that and manage spacing there would be valuable.

The sheer volume is a rather tough problem to manage without a particularly tedious solution since the real world would use a GDP or AFP in place of typical MIT and Metering to manage demand spikes. First tier ground stop or even just a ZJX internal ground stop would’ve taken away a few, maybe 5-10 planes from contributing to the arrival stream which could’ve helped but is certainly not sufficient to manage the ATL volume. ATL is a departure beast so it’s very common to see departure delays build because arrival fields can’t handle.

[Shane Friedman]

Hey guys, just wanted to chime in and give the ZMA point of view as well.

So I think part of the issue with this event was ZMA and ZJX didn't have a dedicated TMU for each, we had Brin running around trying to do both while also trying to manage ZJX staffing issues so he was pretty busy. Us not having a dedicated TMU is totally on us, we just didn't have the controller to spare to be staring at the TMU tapes the whole night who really knew how to manage it. And just so I'm clear, I am only proposing potential solutions to this exact situation were it to arise again, my overall solution to fixing the immense flow of traffic would be closer to a booking system, such as CalScream, but that comes with its own issues. As far as the solution for Saturday would go, we weren't anticipating that more than 60% of the traffic would come from ATL, we almost assumed a 50/50 split, but clearly it didn't turn out as such. In retrospect I would have began rerouting ATL deps down SSCOT as soon as I noticed IAH ran out of traffic, but it just didn't happen unfortunately. Since ZJX is an integral part of the flow of traffic into ZMA, especially for events, I think the most beneficial way to have solved this would have been to have ZTL and ZJX work a little closer and instead of stopping ZMAs, starting rerouting down SSCOT, since one side of ZJX was almost empty for part of the event. We just had too much traffic coming from one place, and it happens, this isn't a new issue when it comes to events in VATUSA, especially flyin style events like this one. And I do agree that there needs to be a more practical solution then just having lines and lines of departures, but we just haven't figured it out yet. I know I'm repeating almost exactly what has been said earlier, but I just want it known that ZMA agrees that we could've done that much much better and we will look to do it better in the future.

Again I know I'm mostly repeating everyone, but this is a long standing issue for these type of events, and it is/will be here until we find a more permanent solution. Either way we do this for fun, and I hope that the surrounding ARTCCs at least enjoyed themselves and the challenges brought on by this event. I understand that ZTL had an insane amount of traffic, even with the stats Matt gave all three ARTCCs handled the event very well and I appreciate everyone around us hanging out beyond the event end and giving the pilots a fun night of flying into KMIA.

[Nolan Danziger]

I think that one of the biggest problems during events is the difficulty in responding to huge pushes in real time. IRL, flights are planned out days in advance and there's plenty of notice before you're about to get a huge push from ATL, in this case. However, one problem with VATSIM is that someone may connect, call for clearance, and pushback with 10 minutes. That's not very much time to adapt.

I think a potential solution to this is a booking system, but I don't have any experience with how hard or easy it is to work with one of those. Maybe ZLA or ZOA or someone familiar with CTP could add their opinion on that front. But a more helpful and easy-to-enact solution would be what Jeremy said. Have a playbook that you can fall back on when you need it. Obviously this requires a little bit more extra work from ECs or TMU/CICs, but in my eyes meeting either the day before or a few hours before to establish a couple plays sounds like a very fruitful use of time. And, after the event, don't throw away your notes, because you can probably use it for the next one!

Just the thoughts of someone who sat on the ground in ATL for 45 minutes enjoys the event problem solving 

[Brin Brody]

I think a potential solution to this is a booking system

Jeremy is a good source for this... ZNY has used it on multiple occasions.

My thoughts on the booking system idea:

Due to the open nature of the network, we cannot require pilots to book their flights, adhere to slots, etc.  Denying or delaying service as a result of an unbooked flight seems unreasonable.  If, for unbooked flights, we default to the "fit them in where we can" mentality, then the point of the booking system becomes moot, as pilots slowly drift away from the extra step and towards the freeform method they adhere to currently.  Or maybe they think the booking process adds to the realism and will be more inclined to do it?  There's no way for me to know at this stage.

Having never coordinated an event with a booking system, I could be entirely wrong about this, and it could work spectacularly.  It's certainly worth a try, but we shouldn't expect it to work perfectly.

[Shane Friedman]

I think a potential solution to this is a booking system

Jeremy is a good source for this... ZNY has used it on multiple occasions.

My thoughts on the booking system idea:

Due to the open nature of the network, we cannot require pilots to book their flights, adhere to slots, etc.  Denying or delaying service as a result of an unbooked flight seems unreasonable.  If, for unbooked flights, we default to the "fit them in where we can" mentality, then the point of the booking system becomes moot, as pilots slowly drift away from the extra step and towards the freeform method they adhere to currently.  Or maybe they think the booking process adds to the realism and will be more inclined to do it?  There's no way for me to know at this stage.

Having never coordinated an event with a booking system, I could be entirely wrong about this, and it could work spectacularly.  It's certainly worth a try, but we shouldn't expect it to work perfectly.

I agree Brin, we can't control the openess of the network, I fully understand the issues associated with booking systems, I just didn't want to address that topic in my post since it wasn't about that, as I said "but that comes with its own issues." Ideally every pilot would book a flight and fly that flight as booked, but it will never work out that way, even large scale booked events like CTP don't work out that way.

I do think this topic serves an important purpose in furthering the discussion about these sorts of events, but as far as Saturday goes, its over and we worked through the problems. Further solutions should really be looked into for future events rather then dwelling on past ones.

[Matt Bromback]

So while you all discuss bookings, slots, etc...This event basically created a denial of service to certain traffic, which is exactly what Brin pointed out what should not or can't happen.

Be careful going down this path, once you start there is no turning back. Next event that does not offer "prizes, or money" you will see less and less traffic. Why would anyone want to fly in your event if your not giving away stuff for free? This is a very slippery slope, tread carefully.

[Don Desfosse]

While I agree that offering prizes certainly helps attract traffic, I think (gut, no statistical evidence) that no prizes during this event would have reduced the traffic load only by 15-30%.  It was a great, multi-ARTCC event on a Saturday night, and it was the "premiere" event in VATUSA and all of VATSIM at the time.  The traffic load would have been relatively high regardless.  The lack of prizes would have probably negated the need for gate holds.  Want to test the theory?  Hold an exact replica of the event, without prizes, on a "routine" (non-holiday weekend, nothing special going on in the world) Saturday night in a "routine" month (after summer vacation time, e.g. late September through early November) and see what happens.  The only thing, though, if no prizes, may want to make it two-way (i.e. don't just focus on KMIA arrivals), as not having the prizes kinda negates the need to focus on "just" KMIA arrivals.