Handoffs: Think Frequency, Not Callsign

[Evan Reiter]

When flashing a datablock to the next sector, we should be looking for the specific sector, not a particular callsign, to hand off to. Check out the two Boston Center controllers in this example:



In this scenario, BOS_CTR is working 134.70, and a student BOS_S_CTR is listening (unprimed). In a few moments, they'll swap positions. If you're an adjacent controller getting ready to switch an airplane to Boston Center, the pending controller swap should be irrelevant to you. All you need to know is that your handoff is to 134.70.

Use the keyboard commands (not the mouse) to initiate the handoff and it won't matter whether BOS_S_CTR, BOS_CTR, BOS_NW_CTR, or any other callsign is working 134.70; it will end up in the right place.

We recently ran an event that involved rotating positions (so controllers worked about 1.5 hours of each sector over the course of the 7-hour event). That meant we signed in using BOS_1_CTR, BOS_2_CTR, etc., and the callsign to hand off to was constantly changing. For the first hour, your handoff might have been to BOS_1_CTR on 127.97. Then, the first rotation hit and BOS_2_CTR started working 127.97. However, the frequency to hand off to was always the same and if you were handing to 127.97 instead of "BOS_1_CTR", you wouldn't even have noticed.

If you use vERAM or vSTARS, switching aircraft by reference to a sector is already second-nature to you. In VRC, resist the temptation to use the mouse. Instead use the key command "F4 -> sectorID -> asel" (where the sectorID is, in the picture above, "37") and you won't have to ever worry about adjacent controller callsigns again!

[Nolan Danziger]

While we're on the topic of handoffs, let me drop these here...

https://web.archive.org/web/20120813031415/http://laartcc.org:80/old/training/understandinghandoffs.htm

https://web.archive.org/web/20120813175019/http://laartcc.org/old/training/understandinghandoffs2.htm

[Aidan Deschene]

Evan, thank you for the time in sharing your thoughts on how handoffs should be handled. I completely agree with your statements, and I want to input my personal experience with working a neighboring ARTCC during the event.

I worked ~5 out of the 7 hours on Cleveland Center, and witnessed approximately 4 controller changes. I had signed on a minute after the event had started and I was misinformed of the center splits occuring during the event since there were several, and I mean several.

Communication is key ... if controllers in-facility, and out-of-facility do not coordinate with eachother in the proper means of communication there will be misinformation, and possible confusion that occurs. The event had a great amount of traffic, and I handled several handoffs. The first thing I did: communication, and I asked what "sector" I would be handing off to. But this is my first mistake ... controllers should be inquiring what frequency they should be handing off to in certain scenarios if... for in this case the sectors are unknown through the callsigns. I was then politely informed that the high sector for our boundary was on frequency: 127.970, and also informed that the sector split was not yet active.

One the frequency has become active there was a great amount of coordination occuring, and the event went as planned until... the controller change. I was unaware of the changes occuring frequently over the span of the event, and I was unaware until my first handoff was rejected. This is my second mistake: not looking frequently for the frequency I was handing off to, and no knowledge on the new high sector ID handling my boundary handoffs.

New Lesson: in scenarios where you may fortunately border a facility with an event, and controller changes, or no event: you should always keep an eye out on changing sectors and frequencies. I always keep my communications "tab" open on my, lucky to have, second monitor, and I utilize this to my advantage. I would also like to give the advise for other controllers to make my mistake, and use this lesson to remember that "scanning" non-scope material and systems is important to the efficiency of our traffic management flowing between our TRACON and ARTCC/FIR boundaries.

I am not ashamed to say (as no one should be); I learned from my mistakes, and take this from me..... be informed/in the know of the sectorization of your neighbors (especially for events), and scan not just your scope, but your other materials and systems (such as SIGMETs/IDS/Comms.)...

A great learning point for myself, and I hope you inherent the other materials regarding the responsibility of handing off... and please be nice to your neighbors.

[Dhruv Kalra]

Couple key takeaways from Aidan’s post above:

Sector configuration for the neighbors is an integral part of the position relief briefing. The controller being relieved needs to pass on who owns what.

Rejecting handoffs is poor form and shouldn’t ever happen (I really wish you couldn’t reject a handoff in our radar clients - we have no such capability on the real systems). If something’s flashing at you that shouldn’t be (or if you’re so far down the tubes that you need to shut off the neighbors), coordinate.

“ZOB 04, ZBW 39, AAL344 should be flashing at 37”

Or better still, take the handoff and transfer radar to the correct sector.

“ZOB 04, ZBW 39, I flashed AAL344 on to 37. That’s his airspace. Put him on 134.7”

And if the plane is flashing at the right sector and you as the receiving controller need the nuclear option:

“ZOB 04, ZBW 37, I can’t take AAL344, POINTOUT APPROVED. SPIN HIM AND I CAN’T ACCEPT ANY MORE AIRPLANES FOR NOW. I’LL CALL YOU BACK.”

I understand when things get hectic you don’t always have time, but this is where blasting out a quick message on the ATC channel is useful and can very easily duplicate the effect of an interfacility shout line call (someday maybe AFV will have solid G/G comms and we can teach the “real” way to do it).

There’s a right way and a wrong way to shut off the neighbors. We almost always do the latter. Yes, it sucks, but it’s way less of a headache when it’s not a giant panic at the boundary. If you tell me I’m shut off, I don’t keep guys driving at your airspace. The first one or couple of planes might get panic spun, that’s the reality of it. I can then start to come up with a plan to delay, hold, or reroute the next 8-10 or however many more I have headed for that sector behind the first couple in a much more orderly (as orderly as getting shut off can get, anyway) fashion.

[Evan Reiter]

Evan, thank you for the time in sharing your thoughts on how handoffs should be handled. I completely agree with your statements, and I want to input my personal experience with working a neighboring ARTCC during the event.

Thanks Aidan! I didn't intend to call you out specifically, of course...I've been trying to drive this concept home within ZBW for the past several years. Just ask any ZBW controller who has tried to tell me that "handoffs are to NY_1_CTR" in a briefing...

Totally agree on rejected handoffs; that shouldn't be happening.

One thing we've done recently is created airspace.bvartcc.com as a quick reference for our active split. If you go there now, it will just show all available spilts. However, during an event, we post the specific split that's open (if you go to this link, you'll see what was published during Tea Party, albeit with a post-factum edit to include a reference to this post I just made). We've found this easier than telling people "yeah the split is on Page 6 of our LOA, oh wait, that's the old LOA, uh...". I recognize that, in the heat of battle, it's easier to just hear "high to 127.97" and we try to do that to...but I've always found a map helps.

I'd encourage other facilities to consider whether something like this is an option for them. We've tried to make it obvious and also put numbers on some of the key areas so we can say "change of plans, Area 6 is now going to 127.97" if we have to make an adjustment last-minute.