Sequencing arrivals when it's busy

[Craig Zarmer]

I'm going to pick up a topic started in the events forum (http://www.oakartcc.com/forum/showthread.php?4669-DVA-Delta-Virtual-Airlines-Chinatown-Dec-19-1700-1900pst-%28Dec-20-0100-0300z%29&p=31305#post31305) as a follow-up to the Chinatown event and ask more generally: How does the real world tactically manage sequencing, and how does that translate to our world?

My assumption of how the real world works is: Central traffic mgmt uses ground and enroute holds to ensure each arrival airport stays roughly within it's arrival capacity. But when they actually do show up at KSFO in 3 streams, with different controllers managing those streams, how do they work together to get them into 1 line with proper spacing?

We were using the guideline of 15 miles in trail per stream, which theoretically would ensure that the streams could be merged into 5 miles in trail worst case, and all the OSI sector controller would have to do is minor vectoring to achieve that. Is that what real world NorCal does?

When most of the traffic comes from one area for a period of time (as with our event), do the outer sectors take a peak at other sectors and assume they can jam a little more thru if needed if the other sectors aren't as busy?

I'm interested in both the mechanics (e.g. miles-in-trail vs other mechanisms) and how the communication and coordination happens in the real world, and whether any of those techniques would work here.

Craig

[David Carman]

Great question Craig! I'm by no means an expert here, but I do have a pretty good perspective from the ZOA traffic management unit side of things.

You're absolutely right that the ZOA TMU uses tools to help match capacity with the number of airplanes in the system. There are three main tools they use to accomplish this.

The first tool is ground delay programs. These are issued by the national traffic management command center. Basically, if it looks like an airport in ZOA (really only SFO) is going to be over capacity due to weather or some other reason, they let the command center know, and the command center builds a GDP. The way a GDP works is, for the area it is effective for, all aircraft departing in that area, with a destination of SFO, get an EDCT (estimated departure clearance time) on the strip when it's printed. The aircraft must be released (cleared for takeoff) within a small window around that time. This way, only the amount of traffic SFO can handle in an hour is theoretically departing, and so there shouldn't be any problems. It works well most of the time, unless you're a passenger, then the gate agent is telling you your flights been delayed 3 hours, for the 1 hour flight from ONT to SFO...

The second tool is mile-in-trail and speed restrictions. The ZOA TMU can place mile in trail requirements on specific arrival streams for traffic entering ZOA. For instance, during the morning rush, if the weather is bad, ZLA might be asked to give 20 MIT and 250 knots on the BSR arrival. The TMU has tools to look ahead and projected traffic, and they make a call which streams need MIT and how much, and then continually evaluate that and make changes as necessary. The TMU also sometimes issues MIT in between sectors within ZOA although that is less common. More common is the NCT TMU working with the ZOA TMU to establish MIT for a/c entering NCT.

The third tool is Time Based Metering. This is not always used, and is being phased in at a lot of airports in the US still, but basically, it is like creating a GDP at the TMU level, that is constantly being updated. It schedules planes to the runways, and then figures out if aircraft are too far ahead of where they need to be to make it, or too far behind, and tells controllers whether they need to delay an a/c, or speed it up, and how much. It works really well if everyone is well trained on it, and conditions are favorable.

It is common for MIT to be used in conjunction with GDPs. TBM is normally not used with other techniques, and it is NOT something we can simulate on VATSIM. The idea behind all of these techniques is to balance capacity with demand, with the goal being to minimize airborne delays such as holding, or extensive vectoring. When these systems are working well and everyone is on the ball, NCT should only need to do MINIMAL vectoring to zip the streams together on final. I've seen it happen, when it does it's a beautiful thing.

As for varying the spacing on different streams based on traffic, this does happen in the real world. For instance, in the morning arrival rush, the majority of the traffic is arriving from the east on the MOD3, so the TMU works very hard not to put any restrictions on that arrival, and instead places rather large MIT restrictions on arrivals from the north, south and west, which is generally ok because there aren't many flights anyway, and this minimizes the overall delays in the system. Same thing during periods where there are a lot of arrivals from the south, and not much elsewhere. This is on the TMU level though, with MIT requirements being placed on neighboring centers, not internally between controllers (although the controllers are the ones who inevitably have to make the planes meet the MIT).

On the smaller scale, where it sounds like maybe you're more interested, I don't have as much knowledge. However, I understand that at NCT the feeder controllers do look at the other streams and work together to figure out a sequence of who's following who. Then they vector a/c so that they hand them off to the final controller close to where they need to be, and the final controller ideally only has to vary speed and the turn to final to achieve proper spacing on final. Also, at the ZOA level, if ZLA has MIT requirements for a/c going to LAX, the controllers who work the traffic going south look at each others traffic and work together to establish a sequence and maintain the separation.

As for ways to apply this to VATSIM, some would be easier than others.

To create a GDP on VATSIM would be VERY challenging because one, a/c don't pre-file hours in advance with requested departure times like they do in the real world, so figuring out future demand and creating EDCTs to manage it doesn't work. Also, VERY VERY few tower controllers on VATSIM would be able to actually meet the EDCTs accurately enough for it to matter at all, if there's a tower controller online at that airport in the first place. Nevermind a/c departing offline so they don't have to wait 2 hours for their EDCT and then logging in half way to SFO.

TBM on VATSIM is not possible at all. The system which does it is HIGHLY complex and there is no feasible way to recreate it on VATSIM.

MIT is all we get then :) But realistically with VATSIM traffic that's all we need. I think having the blanket 15 MIT on each arrival stream works well personally. Without someone acting as the TMU (we barely have staffing to cover what we need, nevermind staff a TMU position, which would require more training too) IMO it would be too confusing to change the spacing frequently. It would get reduced, and then it wouldn't go back up, or it would but people would forget, or not pass it on in a relief briefing, etc. Unless someone is in charge and making sure everyone knows what spacing to use, it's best to just set it at the beginning and stick with it, even if it isn't always the most efficient.

What I DO think we can do on VATSIM is change how we understand the MIT requirement and where we think the MIT needs to be enforced. The idea behind the MIT requirement is to only give NCT as many planes and they can land. No more, ideally no less. That's centers job, to match the capacity, not to sequence them for final, but just to only give NCT as many planes as they can use. That's what the 15 MIT accomplishes. If center sticks to that, NCT will only get as many planes as they can land, and due to controllers and pilots not being perfect, there will one or two planes too many in NCT, which is actually ideal. With that in mind, we need to change where we apply the MIT.

Right now it seems like we are thinking that MIT needs to be applied being handed off to the final controller. Actually, the MIT is important when going from ZOA to NCT. Once planes are within NCT, the controllers can disregard the MIT, APP controllers job is to work together to SEQUENCE a/c for final. That means that the feeder controllers need to look at each others arrivals, and work together. Visualize yourself putting the a/c together on final, and then work to get the a/c handed off to the final controller in a way that he doesn't have to do much vectoring. For example, if you see MOD3 has 2 arrivals with a big hole in between them, visualize where that hole will end up on final, and try to vector an a/c on the BSR2 to be in a position to fill it. Or if there are two arrivals really close to each other on the MOD3, delay a guy on the BSR2 to go behind them, instead of smack in the middle of them.

You can do this working as a team, or by assigning ONE feeder controller the job of being the one who assigns the sequence, and then it's there job to tell the other feeders who's following who on final. It's more fun as a team, and in some ways less work, but at times it is also good to have just one person making decisions...

It's a tricky game, and a challenge real controllers and TMCs face every day, and even in the real world they don't always do it right. But hopefully understanding more about the tools available and how they work can help us on VATSIM to use them more effectively and at least reduce the chaos a little. Thanks for asking the question Craig!

[David Carman]

Also, after reading the other thread, I'll mention my thoughts on holding. APP should not hold for spacing, ever, because as I said in my post above, APPs job is to SEQUENCE, not manage capacity. Holds should be done by center, if necessary, to achieve proper MIT spacing. Put A/C in holds, and release them as you need to get the MIT.

Finally, the 15 MIT is a guideline, but as I said, controllers and pilots aren't perfect and sometimes even that isn't enough. Center, pay attention to APP. If you see red in APP, or LOTS of vectoring/holding, stop sending guys for a bit, put everyone in holds, let NCT get their act together and sort out what they have before slamming them with more. And APP, if you are getting slammed with a/c from center, it's totally ok to tell center to hold all a/c on a certain arrival. Center has a lot more room to work and options than you do on APP, so yea it sucks, but it sucks less if CTR deals with it.

[Charan Kumar]

Thanks for the gr8 explanation David, it is really interesting always to know more about this field. All 3 of us working APP that day knew what we were getting into, but one thing that we did not think we needed was a plan of action. We assumed that our training with the SOPs should come in and everything will be hunky-dory. Which it did for a while, but soon things got out of hand, and we started making amendments. For eg, One thing I did was descended acft to 8k near SFO before handing off only after Jim requested it sometime into the arrival stream. We could've additionally added slam dunk to all arrivals, so that they would already be on the d/w and all SFO would have to do is to give one descent and turn to final PTAC. Also I did not pay attn to Jim's area for a very long time, which I should've done early enuf. One thing we should always remember as controllers is maintain a scan of our airspace and a little bit around, and in this case, neighboring air space.

The speed control also gets tossed a bit on VATSIm due to the varying weather component in each sim. For speed control, we ask an acft's speed, then ask for another acft's speed, then asking the second acft to reduce speed only to find out he is already slower than that :) Instead try "reduce/increase speed by 20 kts", but beware of how much space there is before and after and increase/decrease accordingly.

And use shortcuts and vectors as much as you need. You don't have to keep an acft on its arrival path if vectoring to another waypoint or area even, like David mentioned, will achieve it's goal. A BSR arrival can be merged with a MOD3 arrival over SJC, doesn't have to be done over MEHTA/MENLO. Technically the flows never meet.

Don't hesitate to assign the opposite side rwy for BSR2/MOD3 either. It is only a general guideline, they are not rules, so a MOD3 can expect ILS 28L. For example all DVA tfc the other day from SEA was coming into 28R, Jim and I agreed on that. So all MOD3/BSR2 can go to 28L. They will just go to HEMAN or MENLO based on which side they come from. If this is what you guys did, then that's brilliant!! The reason I mention it is because Jim asked me to alternate the tfc to 28L/28R. I would not have a problem if that was the only stream he had. But it would be too confusing to alternate acft from one source, while two other streams are also feeding both the runways. It would be better if you keep acft from one stream go to one rwy, that way sequencing is easy.

My 2 cents, and lessons learnt, we shall do much better next time!!

[Craig Zarmer]

Vectoring / sequencing was kind of the core of my question. As we were split for that event, I controlled the BSR2 and MOD3, and the airspace over SJC, so yes I could do that merging. (But w/o pointouts, Jim couldn't merge over SJC.)

But I felt I didn't have enough insight into what Charan/Jim are doing with the heavy north traffic. I saw traffic coming down both the left and right side, and it was difficult to see where the hole (as David suggested) would be. For a while there I don't think there was a hole.

Unless you are expecting people to go visual and thus parallel approaches once below say 4K, I'm not clear what the advantage is of running people down both the left and right side (the slam dunk). Why take 1 stream and split into 2 when center has already ensured stream 1 has enough separation? Slam dunk makes sense when one of the other streams is busy but has a gap you can fill (and it's visual conditions). If it's IFR with a ceiling of less than say 3K, it's going to be single file down the approaches, so why not get them in one line as far back as possible? Then it'd be easy for another feeder sector to see where the holes are.

Craig

[Charan Kumar]

Sorry I should've clarified. The arrival stream from SEA/GOLDN5 was going to LOZIT/SFO/ILS 28R according to Jim, unless I was totally mistaken.. Since he has to issue an additional vector to bring them to the d/w, I was saying the slam dunk approach of putting them on hdg 100 could've been used to save him a couple of vectors.

[Craig Zarmer]

I just saw a lot of planes appear to be on the right downwind - maybe they screwed up and Jim was resequencing them over there.

Anyway, I love DavidC's point about MIT vs sequencing. Let's make an effort to run split NorCal a lot more often, even when not that busy, for practice and experimentation!

[Charan Kumar]

On a side note, we should eventually plan for tfc like this:
http://www.ge.com/thegeshow/flight/index.html#ch1

Courtesy VATSIM forums

[David Carman]

It sounds like maybe you misunderstood a little what I meant Charan. I didn't necessarily mean merge streams out in the middle of no where to fill the holes, what I meant is, set the a/c up so the holes come together where they meet (around DUMBA) anyway. It's harder cause they aren't right next to each other sure, but if it was easy we wouldn't be getting paid.... oh wait. :) That's why I mentioned the visualizing them getting onto final. If you visualize all the a/c's flights onto final, then you can kinda visualize how it will mesh together, where the holes will be, and whether you need to speed up or slow down a/c on other streams to fill them.

I was trying to keep my comments general because I wasn't at the event, but I'll make a couple specific comments based on what you're saying. First, Craig is on the money questioning using two different approaches in IMC. That's pointless, stick with one app in IMC. You can't run them any tighter using two at SFO cause the runways are too close, so why make it more confusing for everyone?

Also, SFO/OAK sectors are tiny. TINY. They can not do anything except tweak the turn to final, extend GOLDN downwinds a tiny bit, and speed controls to get guys lined up. The reason GOLDN5s are sent to the south of SFO is because there is more room there to tweak their downwind slightly if necessary. The slam dunk should only really be used in VMC with planes you can sneak into little gaps. Also, like you said Craig, SFO can't extend final to SJC cause of airspace, which is even more reason for the feeders to keep things smooth. Because SFO/OAK are so tiny is why feeders are so important in setting up a good sequence. If you're working final, and you can't fit a guy in, don't try, climb him above the other stuff, and shoot him back to a feeder to be re sequenced, that's their job.

As for speed restrictions and vectoring, that's a whole other topic, and those are basic radar skills. If controllers are having trouble with those, the rest of this topic is pointless because even if we can figure out a great plan to sequence, if we don't yet know how to execute it, what's the point?

If you want to talk about speed restrictions more Charan, let me know I'd be happy to explain them again, and then how they suck on VATSIM and are basically useless.

[David Carman]

As another note to help see problems coming a little sooner, as soon as final breaks an a/c off and send it back to the feeders, or any time you have a go around, that is one slot you missed on final. That's 5+ miles gone, and 1 a/c too many in NCT. So, as soon as you see that happen as a feeder, that's the time to tell center to back off for a bit because you're still at capacity, you don't need more planes from CTR yet. If CTR keeps going you'll be constantly above capacity (ie, going down the crapper). Also, as center, if you see final spitting guys back to feeders, give them some slack to get everything flowing again.

[Charan Kumar]

Ok, point well taken. I missed the part about not using parallel runways during IMC. I don't want to say this is the reason, but our choice of using 28R for GOLDN5 is probably what caused our initial problem. I understand better now as to why we should avoid that. I agree that SFO/OAK sectors should only be doing a final descent and PTAC and nothing more. It's in a silver platter or given back to feeders.

As for Speed restrictions being pointless, I did see that a whole lot this time. That's why I switched to reduce 20 kts instead of reduce speed to 250. Even that didn't work, but it helped a bit. I don't want to depend on it, but I use it as a reminder to tell pilots they can't be approaching TMA at 400 kts GS :D

[Jim Greever]

This has been one of the best discussion we have had on approach in a long time.
After reading all the dialog over the last few days, seems like we could use a more defined "controller instruction" given at each event that would include a "worse case scenario" setting up a 15 mi MIT at less than 250K, predetermine all arrival streams, with runway use, further we can have an active communication that would flow with the changing weather, traffic demand and unforeseen circumstances.
I also believe part of the problem, was frankly my lack of experience in a very highly concentrated traffic environment.
My basic planned was flawed. It did not take into consideration the volume of traffic we experienced.
We all got a great lesson that day.

[Craig Zarmer]

I don't know if we need more pre-written instructions, but maybe a little more app control huddle before the show begins. I think each controller has their own style and skill level, and also their own pref for communication (TS? Chat window? Override?) I'd start with whoever has OSI, that controller says where they want 'em, and the feeder controllers need to support whatever that controller needs.

I'd love to hear more about the real world on the communicate and coordinate side. I visited Bay Approach a LONG time ago (yes I mean Bay approach when it was at OAK). I found it interesting that they had horizontal radar screens that could have 2 or 3 controllers around, and I noticed how they could just point to a plane and gesture to another controller. From the pictures I've seen of new massive combined appcons, I gather this doesn't happen any more (rows of vertical screens). I find it VERY hard to listen to TS while on the radio. I wish TS could automatically mute when there's a transmission on VRC.