Radar Technique: Handoffs from TRACON to Center

[Dhruv Kalra]

I've seen this pop up at more than a few events during my visiting and ACE Team tenure, and realized that most facilities' opinions don't match up with mine and what I've taught my radar students over the years. I've long been a proponent of initiating the radar handoff process on departing aircraft sooner rather than later. More often than not, this is in order to reduce eventual workload down the line.

When I get busy, I'd rather flash early rather than flash late so that transfer of comms can be completed with enough time that the Center can keep guys climbing. In a lot of cases, I've witnessed the opposite, where a late handoff results in a plane unnecessarily leveling off at the top of the TRACON before the Center can start talking to them. That being said, I thought I'd raise the discussion here.

IRL, TRACON departures nominally begin automatically flashing to the appropriate center sector within a handful of miles of the departure end of the runway (or other, computer specified distances from the departure airport). It varies, but the aircraft is often still fairly low to the ground relative to the top of TRACON airspace, and often 20 or more miles from the lateral boundary. Just because the track is flashing to you doesn't mean you have to take it.

So here's my plea to all the center guys (and to borrow a quote from my friend Nate Johns): "There is zero reason to actively reject a handoff for "flashing too early." Zero. Heck, its not even possible from the center IRL.

Why would you make more work for your compadre? Heck, why would you make more work for you? If you're not ready to talk to someone yet, just wait until you are ready, then take the handoff at that point."

[Shane VanHoven]

He's right!! I was working a bit last night at the TRACON level and had to explain what was going on to the confused center controller when I sent an airplane at 4k'. Now in this case that created more workload for both of us because I had to sit there and explain myself afterwards -_- But USUALLY, it is smarter just to send it sooner. It helps to promote a smoother running machine when departures don't have to level off.

[Rick Rump]

Handing off as soon as feasible with respect to crossing traffic or other needs makes more sense than keeping someone until they are 100 feet from their assigned altitude and have to sit there level for a handoff to be accepted because one wanted to hold the aircraft forever.

[Chris Bright]

My goal when working is to talk to someone for the least amount of time possible. The sooner instructions are given, and the sooner coordination (handoff, pointouts, apreqs) are done, the more efficient I can run my sector. The whole point of the NAS is to safely organize and EXPEDITE the flow of traffic. If there is no conflict, there is no need to withhold radar, or refuse a handoff due to it being too early. Besides, handing off to approach 50 miles from the boundary can be fun some times.

My $.02.

[Wesley Miles]

Absolutely Dhruv!  That's generally a good rule when talking about any radar position.  Starting the flash to the next controller as soon as possible makes your job easier and may help the receiving controller by allowing them time to plan their action, or simply aiding their situational awareness.

When the handoff has been accomplished, transfer communications as soon as you no longer need them.  If you can avoid last-minute coordination, why wait?

[Daniel Hawton]

My goal when working is to talk to someone for the least amount of time possible.

Can't tell you how many people I've heard this from at my FAA facility... oh wait, yes I can.  Everyone.

[Daniel Hawton]

When the handoff has been accomplished, transfer communications as soon as you no longer need them.  If you can avoid last-minute coordination, why wait?

If you follow the .65 5-4, you should not initiate a handoff until you are free of conflicts.

To the extent possible, transfer communications when the transfer of radar identification has been accepted.

Thus if you follow 5-4, as soon as the handoff is accepted you should be shipping them as you shouldn't initiate a handoff until all conflicts have been resolved.  Departures, get them pointed toward the gate or on their flight path, issue the climb, verify flight path is clear of conflict and initiate the flash.  Once the flash is gone, ship 'em.  You flashing indicates to the next controller that there are no conflicts between the aircraft's position and the boundary.

Remember, even if you handoff and transfer comms, you're still responsible for separation until the boundary.  But otherwise, I agree.  I've always hated the rejection for being "too early"(?).

[Wesley Miles]

If you follow the .65 5-4, you should not initiate a handoff until you are free of conflicts.

I disagree.  You need to ensure potential airspace violations and traffic conflicts are resolved prior to communications transfer.  It's not necessary to withhold a handoff until all conflicts are resolved.  The flashing does not indicate there are no conflicts, but rather the communications transfer.

As far as transferring communications right after the handoff has been accepted, that's just to the "extent possible", and not a requirement.  Otherwise I and nearly every radar controller I coordinate with break the rule every day.   

[Daniel Hawton]

If you follow the .65 5-4, you should not initiate a handoff until you are free of conflicts.

I disagree.  You need to ensure potential airspace violations and traffic conflicts are resolved prior to communications transfer.  It's not necessary to withhold a handoff until all conflicts are resolved.  The flashing does not indicate there are no conflicts, but rather the communications transfer.

As far as transferring communications right after the handoff has been accepted, that's just to the "extent possible", and not a requirement.  Otherwise I and nearly every radar controller I coordinate with break the rule every day.   

To the extent possible means basically to do it outside of situational requirements that desire an alternate course of action.  You shouldn't be initiating a handoff until all conflicts (or violations) have been resolved.  At that point, you have no reason to keep them so why keep them?  Get rid of them.  You can't make any changes to the aircraft's heading, route, speed, altitude, etc after it's been initiated (IE, "C" slew enter) or completed, without coordination... so if you initiated the handoff but you're not ready to release comms then "you're doing it wrong" (meme quote).

So if you hand them off and then check conflicts... you can't do anything about it without coordinating.  Resolve conflicts, hand them off and ship them.

[Wesley Miles]

Yikes!!! I believe we have a difference of opinion here!    Maybe your LOAs specify differently, but even  if the next sector takes the flash, the aircraft is still your control while in your airspace. I can give a guy a 360° turn after the next sector took the flash, and still be legal if he's in my airspace.

 For example: I start the handoff on a departure passing 3000. The center takes the flash at 4000.  I  still have control to vector the guy out of the gate, or around traffic, or stop his climb below traffic, as long as he's still in my airspace.

And on that logic, it's not uncommon for me to take a handoff 20 miles outside my airspace and not talk to the plane until 5 out. Maybe they had traffic, maybe the controller needed him for some reason. It's not my concern. I only care that I'm talking to him by my boundary, and when I do talk to him he has no conflicts.

 Do you guys do something differently?

[Daniel Hawton]

Yikes!!! I believe we have a difference of opinion here!    Maybe your LOAs specify differently, but even  if the next sector takes the flash, the aircraft is still your control while in your airspace. I can give a guy a 360° turn after the next sector took the flash, and still be legal if he's in my airspace.

 For example: I start the handoff on a departure passing 3000. The center takes the flash at 4000.  I  still have control to vector the guy out of the gate, or around traffic, or stop his climb below traffic, as long as he's still in my airspace. Do you guys do something differently?

Nope, I was reading straight out of the .65 on that one.   The only time you CAN make a turn [etc implied] after a handoff has been initiated is by LOA or facility directive.  Reference 7110.65 5-4-5(b)

b. Verbally obtain the receiving controller’s approval prior to making any changes to an aircraft’s flight path,  altitude, speed, or data block information while the handoff is being initiated or after acceptance, unless otherwise  specified by a LOA or a facility directive.

My (rw) LOA with ZAN allows it.  *BUT*, strictly speaking from .65 and having seen a majority of the LOAs around VATUSA, you wouldn't be able to.

[Wesley Miles]

We interpret that to mean changes to NAS information... ie route, altitude, etc.  Which is why you get the "Handoff Status" error when trying to make an FDIO ammendment to an aircraft in h/o status.  Also why you have to coordinate any changes to NAS info after a handoff has been accepted.  Pretty sure this excludes maneuvers in your airspace, under your control.

This is interesting... I'll have to ask around and see what the consensus is at my facility.  If we're "doing it wrong", it may be a regional thing seeing as how variations of this happen many times each week (even with the Center).  Just had one today with ROC vectoring a guy after I accepted the handoff.

Edit: I can even remember a few times at the academy when I've had to vector after a handoff. Mind = blown.  Time for bed.

[Daniel Hawton]

We interpret that to mean changes to NAS information... ie route, altitude, etc.  Which is why you get the "Handoff Status" error when trying to make an FDIO ammendment to an aircraft in h/o status.  Also why you have to coordinate any changes to NAS info after a handoff has been accepted.  Pretty sure this excludes maneuvers in your airspace, under your control.

This is interesting... I'll have to ask around and see what the consensus is at my facility.  If we're "doing it wrong", it may be a regional thing seeing as how variations of this happen many times each week (even with the Center).  Just had one today with ROC vectoring a guy after I accepted the handoff.

Everywhere I've been, it's meant as ANY changes and not just NAS information, that aren't strictly authorized by the LOA.  IE, the LOA has us vectoring out one gate for a specific direction and placing the rest on their filed routings.  To us, this is an authorized change of flight path after the handoff has been initiated as it's by LOA.  As a flight's path is altered when you give a vector, that to me violates that paragraph.  Have never heard your argument before but can't say I am overly surprised that this paragraph is being interpreted differently around the FAA.

[Dhruv Kalra]

I know for a fact that at busier places where the automation starts the flash by itself, control instructions are given to planes while in handoff status and after center buys the track.

I can ask friends at those TRACONs to weigh in.

[Daniel Hawton]

I know for a fact that at busier places where the automation starts the flash by itself, control instructions are given to planes while in handoff status and after center buys the track.

I can ask friends at those TRACONs to weigh in.

I'm at one of those.  Our departures start flashing immediately.  However, generally departure instructions are covered by LOA which allows control instructions to be issued after the handoff has been initiated... at least in my LOA they are.