This
should be required reading/training for all radar controllers in VATUSA, and probably other parts of VATSIM would find this extremely useful as well.
More often than not these days, I find myself working with controllers that have no knowledge or concept of what, exactly, a handoff really is or how to understand and accomplish coordination appropriately along with the specific phraseology. Learning this material will not only make coordination easier between each facility in VATUSA, but also help to train pilots how to properly "check-in" with a controller from radar handoffs and during non-radar situations. Again, referencing one of my largest concerns within the division (and possibly entire network) is the overall lack of standardization and consistency of controller training between each facility. Ensuring everyone is on the same page with things such as handoffs and controller coordination (and this really isn't rocket science, by any means - Jeff does an excellent job of breaking this down fairly simply in this article) will help to improve controller consistency/efficiency with handoffs and coordination not only within a facility, but also across facilities. this, in turn, should rub off on pilots making the check-in process a lot more efficient and consistent (during handoffs and non-radar situations for sure).
Anyways, thanks to Jeff Clark for writing this (wherever you may be). It's a great article. Maybe VATUSA can add this into their controller training documentation...
(Original Article found here:
http://www.laartcc.org/old/training/unders...inghandoffs.htm)
[!--quoteo--][div class=\\\'quotetop\\\']QUOTE [/div][div class=\\\'quotemain\\\'][!--quotec--]Training - Understanding Handoffs and Coordination (Part 1)
by Jeff Clark
Perhaps one of the most misunderstood concepts on the VATSIM system is the purpose and proper use of the handoff. During low traffic situations these misunderstandings usually result in little problem, but as traffic increases, a better knowledge of how these works is becoming more important. Also, with the upcoming release of new controller software, a clearer understanding of the rules surrounding handoffs will soon become essential. This document explains not only the purpose of the handoff, but also 'best-practice' on how to use them, as well as procedures and practices to use both before and after a handoff has been accomplished.
It should be noted that the information contained here is written primarily from a U.S. FAA point of view - however the fundamental principles at play here are fairly universal, and other countries will have similar rules to those described here to address these issues.
The fundamental essence of the handoff:
The first thing you need to understand when considering the handoff is to understand exactly what you are doing. You have probably already determined that one part of a handoff involves telling an aircraft to contact the next controller along his route of flight. You may, however, be surprised to find out that this is in fact only a tiny part of a long string of events that should occur every time you perform a handoff.
There are two key goals you are accomplishing via a handoff that you need to always remember: You are transferring "identity" of an aircraft to another controller, and you are transferring "communications and control" of an aircraft. Both areas will be discussed in further detail later in this document - but first we shall look at the history of the handoff.
Early air traffic controllers had it easy. Aircraft always flew along fixed routes, and altitude separation by direction of flight made it very easy to keep aircraft separate using non-radar procedures. At the first control center in New Jersey, controllers simply pushed little model airplanes along giant maps of the East Coast to keep track of where they were. When they got near the edge of their area, they'd tell the plane to call the next controller, who they'd given a 'heads-up' to via the telephone.
Things are a bit more complicated now. In the early days of radar, controllers worked in teams, gathered around a single radar display which was usually laid flat like a coffee table. The earliest transponders didn't have the ability to show many different codes, and the computers modern controllers use to show an aircraft's callsign and altitude didn't exist. Instead, this information was usually scribbled on a piece of glass that was placed over the blip, which came to be known as a 'shrimp boat'. As the blip moved around the scope, the piece of glass was moved along with it.
These early controllers divided their one big scope into smaller sectors, and because they were right next to each other, it was easy to co-ordinate with each other, asking for permission to clip each other's airspace. They could also pass the 'shrimp boat' along with the blip from one controller to the next, as long as the next controller shared the same large screen - which brings us to the first thing you need to understand - "transfer of identification". But before we discuss this, we need to discuss the passing of flight plans…
Step One: Passing the Flight Plan
You're probably already familiar with the fact that a pilot files a flight plan with a Flight Service Station prior to picking up his IFR clearance. What you may not know is that these flight plans are then entered into a computer system and passed to a Center controller whose sky is -over- the departure airport. This controller is responsible for reviewing the flight plan route, and if the route is unacceptable, he will amend it in the computer before sending the computer sends the route on to the Tower Controller to be read to the pilot.
The Center's computer will then send a copy of the flight plan to the controller who will be handling the departure so he can also study it and be ready for it. Except for one or two controllers, everyone else along the route won't yet be aware of the flight. It is not until the flight actually departs that a 'departure message' is sent to the Center Computer, which then starts calculating 'estimated' times at which the flight will enter various sectors along it's route. The Center's computer then ensures that controllers receive a flight strip with route information for each controller along the way, approximately 15 minutes before the flight arrives.
Sometimes however, this information isn't passed automatically. This can happen when a flight is a 'pop-up', or if the computers aren't working, which is common at night when they are being maintained. In these circumstances the controllers or their assistants are responsible for passing the pilot's flight plan information from one sector to the next well before the plane arrives. This ensures that each controller can study the route and make sure that it will be OK for him, allowing time to ask the controller sending him the aircraft to amend the route or altitude if necessary before the pilot enters his sky.
It is important to note here that when we say we are passing the aircraft's "flight plan", what we are actually referring to is his current cleared route. Controllers do not need to know that the pilot had originally requested a DP which he was not assigned. Similarly, the portion of the pilot's route that he has already flown is also not passed. Only the route to be flown is sent, to ensure that if the pilot loses radio communications, the controllers along the route will know what the pilot was last assigned and consequently must fly until communications are re-established.
It is standard practice amongst controllers that the receiving controller is advised of any route/altitude changes before a handoff is initiated so that the receiving controller is aware of this information before deciding whether or not he can accept the aircraft.
In addition to telling the receiving controller what route has been assigned, another reason for passing flight plan information is to give the receiving controller time to review the route that the aircraft will be flying inside his own sky. Many times particular routings will be unavailable, or not particularly good because of traffic or weather. This is why it is very important to pass an aircraft's flight plan, and to initiate a handoff early enough so that any required re-route can be done by the initiating controller in time. For example, an aircraft may be currently routed to enter the next Center's airspace along J146 - however this airway may be unavailable. The initiating controller needs to find this out -before- the aircraft is 5 miles from the airspace boundary on J146 - in many cases the re-routes need to be issued hundreds of miles before the edge of your airspace boundary.
Once the aircraft's flight plan information, including currently assigned routing has been passed, the next stage of the handoff involves making sure that the receiving controller correctly understands which target belongs to the aircraft to be handed off - this is called Transfer of Identification.
Step Two: Transfer of Identification
When an aircraft first enters a radar environment (normally immediately after departure when contacting the departure controller), that controller uses one of several possible methods available to him to positively identify the blip that he -thinks- is in fact a particular aircraft. The reasons for doing this are very important indeed. It is not unheard of for a pilot to dial in a transponder code that was intended for someone else. For example, if there were radio problems with the Clearance Delivery frequency, it's possible for a pilot to think that -he- is being assigned a transponder code which was actually being read to someone else. He'll depart on his normal flight plan, but the departure controller won't realise where he is because the blip will bear the name of another flight. If two aircraft make the same mistake, the wrong blip will make a turn intended for another aircraft potentially causing a mid-air.
For this reason, controllers MUST use what is called POSITIVE identification to ensure that the blip he -thinks- belongs to the aircraft is really him. Once this positive identification has been established other controllers at the same TRACON are permitted to assume that the computer has kept the right tag with the right plane, and they do not need to radar identify the aircraft simply because he has passed from one sector to the next.
Step Three: Transferring Control:
The second goal of the handoff, after the transfer of radar identification, is the transfer of control. Because ATC is a very precise endeavor, there are very specific rules and guidelines for determining at what point an aircraft becomes the responsibility of one controller, and then becomes the responsibility of the next.
By using automated, or manual handoff procedures, the next step of the handoff process involves communicating your intention to handoff the aircraft to another controller. This is done either via using a computer command to initiate a handoff, or by calling the receiving controller on the landline and performing a handoff manually as described later in this section.
Once this action is started, the receiving controller will review his current traffic situation, and make a decision as to whether or not he will be able to allow the aircraft to enter his airspace. If he is able to do so, he will either enter a computer command to indicate his acceptance, or say 'radar contact' during a manual handoff. On certain occasions, he may implement conditions on the handoff, described later in this section. At this point, permission has been granted for the aircraft to cross the airspace boundary along the assigned flight plan route, at the assigned altitude. It is important to note that this process is best seen as 'asking for permission' to handoff the aircraft, and the aircraft is not yet actually handed off yet at this point.
When to initiate a handoff?
When a controller is handling an aircraft that is going to leave his airspace, he should almost immediately begin thinking about handing him off to the next sector. For reasons discussed elsewhere in this document, this process is not something that can be put off until the last minute or serious problems may develop. There are two important conditions that need to be met before a handoff can be initiated - the first is that the aircraft has been positively radar identified, and the second is that the aircraft no longer has any obvious traffic conflicts. The period when an aircraft is 'between controllers' is one where you don't want any surprises, and a good controller will not accept a handoff if he does not understand exactly how any potential conflicts will be resolved.
For example if you were planning on handing off an aircraft that had visual separation with another aircraft immediately above him, you should advise the receiving controller that there was visual separation between the aircraft at the time you handoff the aircraft. This is because a receiving controller will rarely accept a handoff of an aircraft that appears to be in conflict alert. If there were to be an accident, the controller who currently had control of the aircraft will more usually be the one considered to be at fault, and you cannot expect to 'handoff' problems to another controller in hopes that they will fix something you weren't able to.
Similarly if you have just instructed an aircraft to speed up, slow down, expedite climbs, etc., to resolve a potential conflict, you may need to tell the next controller this information before they will be comfortable accepting a handoff.
Once all of these conflicts with your own aircraft have been resolved, or explained, you should at that point initiate handoff - even if the aircraft is many miles from the airspace boundary. (On VATSIM, there is sometimes a complication that occurs when the receiving controller's range is not set far enough out to see the aircraft. In these cases he will not know that you attempted to handoff the plane - in real life systems however, the aircraft remains in handoff status regardless of how far out they are, and when they appear on the receiving controllers scope edge, they will be in a flashing 'handoff' status.) Many controllers use the saying "take a handoff, make a handoff" to illustrate the common practice of initiating a handoff to the next sector almost immediately after you -accept- a handoff from the first sector. This practice has the advantage of helping to make sure you do not -forget- to handoff an aircraft, which is viewed as a serious infraction in a radar environment.
When an aircraft goes from one radar facility to the next, the computers -usually- are able to pass information to each other about where a blip is, who he is, and where he is going, but not always. In these cases, or indeed when the computers aren't working properly, a "manual handoff" is initiated. In a manual handoff, a controller essentially calls a neighboring controller on the phone and says "Do you see this guy near Terre Haute on the 4203 code? He's AAL330…" The proper phraseology for this process follows the following format. First, the controller initiating the handoff calls the adjacent controller on the landline and identifies himself and why he is calling: "Albuquerque Center, Los Angeles Center handoff". The receiving controller then indicates he is ready by saying "Albuquerque Center, go ahead".
The initiating controller then starts the handoff by telling the receiving controller where on the scope to start looking. He does this by referring to an intersection/navaid that he knows is depicted on both of their scopes, and a position reference that fix - for example: "Thermal, 10 miles southeast", or "over Needles". While the receiving controller starts searching that area for targets, the initiating controller continues the process by reading the squawk code of the target (remember that the receiving controller won't always see a data tag containing the aircraft's id on it, especially if the computers have failed to correlate the aircraft's position between themselves). This allows the receiving controller to examine the codes of all aircraft in the vicinity of the location identified by the initiating controller until he finds the correct target. The initiating controller continues by passing the aircraft id, and any other flight plan information if it hasn't yet been passed. Otherwise, after passing the aircraft ID, the receiving controller will then do one of several things.
If the receiving controller locates the aircraft, and can accept the aircraft, he will say "(aircraft ID) Radar Contact".
If for traffic reasons, he needs to place a condition on the handoff, he will do so at this time via one of several methods discussed later in this document.
If the receiving controller cannot accept the aircraft for the time being, he will say "unable handoff", and if able, advise how long a delay the initiating controller can expect. At this point, the initiating controller must turn or hold the aircraft ensuring that he does not enter the airspace of the receiving controller.
Negotiating conditions for handoffs
There are many times when a receiving controller cannot accept an aircraft into his airspace without modifying some aspect of it's flight. There may be many aircraft in his sector, including many aircraft that the initiating controller may not necessarily be able to see on his radar scope, either due to different radar antenna locations, aircraft operating without transponders or faulty transponders
The receiving controller will place a 'condition' on a handoff by informing the initiating controller of the condition on the landline as follows:
He can ask for the aircraft to be given a speed restriction by saying, for example, "AAL370, speed 250 knots, radar contact".
He can ask for a route change: "AAL370 direct DAG, radar contact"
He can ask for the aircraft to be assigned a heading, for example, for traffic, by saying "AAL370, heading 350, radar contact"
He can ask for an altitude change: "AAL370, descending to FL180 radar contact"
He can also ask for any combination of these. When he includes these instructions in his acceptance of the handoff, he is making this a -condition- of the handoff, and the initiating controller MUST instruct the aircraft to perform the required modification to it's route BEFORE sending the aircraft to the next controller.
If the initiating controller is unable to comply with the request because of traffic in his own airspace, the two controllers must negotiate an alternate plan of action before the aircraft can enter the next controller's airspace. It is important to note that should a situation develop where there is quite simply no where for the plane to safely go, it will be the initiating controller who will be legally responsible for having got into this situation, and therefore he should always have a 'way out' should the handoff not be accepted.
After the handoff, before the ship…
After you have obtained permission for the aircraft to enter the next controller's airspace, the next step is to transfer communications of the aircraft to the next controller. It is important to realize that in real-life, this process does not occur immediately after the handoff is accepted, and many VATSIM controllers believe it is best to de-couple the option which automatically tells the plane to contact the next controller.
There are many reasons why you may wish to hold on to an aircraft before 'shipping' him to the next controller. For example, you may still be monitoring a potential separation conflict with another aircraft to make sure it works out. You may also be monitoring spacing between aircraft or some other factor that needs to be taken care of before you finally are done with the aircraft. As discussed in the previous section, just because you still have work to do with the plane is no reason to not -initiate- the handoff. In those cases, you simply get permission to enter the next sector, and continue to work with the aircraft on your own frequency until you no longer need to talk with him.
After you have resolved any potential issues with your aircraft, and after the handoff has been accepted however, you can - and in many cases should - switch the aircraft to the next controller's frequency as soon as possible. There are many reasons for doing this earlier rather than later. Firstly, you should not worry about the aircraft not being on your frequency but in your sky - there are many rules which are set up to prevent problems with this, which will be discussed in the next section. Secondly, if the aircraft has not changed to the next controller's frequency before entering his airspace, technically you have committed an error which could lead to disciplinary action in a real-world facility. (Remember that it takes time to change radios, so always leave time for this). Finally, the sooner the next controller talks to the aircraft, the sooner he can start working with him, which is always advantageous.
After transfer of communications, but before he leaves your sky…
Until the aircraft has left your airspace there are certain rules that the receiving controller must observer to ensure that your separation is maintained.
Specifically - the receiving controller may not alter the aircraft's altitude, route, speed or transponder code while he is still in your airspace, (or even within 2.5 miles of the edge of it inside his own sky if at the Center).
Having this rule allows you to "count on" your aircraft leaving your sky on a certain route, altitude, etc., which will be useful if you have other aircraft near the boundary that he needs to miss. Because you can count on the next controller not to change any of these things, it frees you up to hand him off and leave him off your frequency as he approaches the boundary.
Negotiating changes after the handoff
There are certain times when the receiving controller may wish to move the aircraft after the aircraft has been handed off, but before he has left your airspace. In these cases he must ask your permission to make one of these changes through the use of an APREQ (Approval Request).
As an example, he may call you to ask:
"APREQ heading 350 AAL320" - which means that he is asking your permission to turn a plane stillin your airspace to a 320 heading.
"APREQ FL180 AAL320" - which is asking to change the aircraft's altitude
The controller may also APREQ more general permissions, such as a blanket permission to make many different turns, or a variety of descents.
To do this, a controller may ask for "control for turns", or "control for descent". If control for turns is granted, the receiving controller may make a series of turns provided none of those turns takes the aircraft -back into- the first controllers sector. "Control for descent" (or "climb") allows a variety of altitudes to be assigned provided that the direction is not changed (in other words, if you are descending him, you can't then climb him).
A controller may ask for both turns and descent/climb by asking for "control on contact", which then grants permission to do both.
Finally, any of these can be granted by the initiating controller without actually being asked. Some controllers even coordinate a special arrangement where all aircraft that are handed off are assumed to be 'control on contact' which means that the initiating controller will allow the receiving controller to alter all aircrafts course and altitude after transfer of communications. This however is more an exception than the rule.
Point Outs
There are occasions when you will hand an aircraft off to a controller who will only work the aircraft for a short period of time because the route of flight will only take him across a very tiny portion of his airspace. In these situations the receiving controller may tell you "Point Out Approved" when you thought you would hear "radar contact". In this situation the controller is telling you that he sees the aircraft, understands his route but doesn't want or need to speak with him. You should then normally hand the aircraft off to the next controller along the plane's route.
Other occasions when you may need to point out an aircraft involve times when an aircraft has strayed off his route, or you may not be certain if a plane is going to clip someone's airspace or not.
A controller always has the right to decline a pointout. He may do this by saying "radar contact" when you were initiating a point out - meaning that he still wants to talk to the aircraft. If he doesn't take the pointout or a handoff, you must ensure the aircraft remains clear of his airspace or an error will have occurred.
A controller who accepts a pointout may also place a condition on the pointout, in the same way he puts conditions on handoffs. He may say:
"heading 330 pointout approved" meaning that as long as the aircraft is on a 330 heading, you can "borrow" his airspace
"Fl180 pointout approved" meaning that as long as you change the altitude to FL180, then it's OK.
Also, he may show you an aircraft in his airspace that you must miss as a condition of the pointout. The way this is done is as follows - he will first tell you where to look on your scope, the transponder code of the aircraft to miss (or his ID if you are on the same radar system), and what he is doing. If you see the aircraft you would then say "AAL331 traffic observed". He would then say "reference that traffic, pointout approved", which means that you may enter his airspace provided that YOU take the necessary action to ensure separation with AAL331. If a separation conflict subsequently develops between these two aircraft in the other controller's airspace, it is now -your- legal responsibility and not his so it is important to understand what the other aircraft is doing before making this type of arrangement.
Summary:
The steps that must be taken as part of a handoff are summarized as follows where the initiating controller is "controller A", and the receiving controller is "controller B".:
1.) You must make sure that the flight plan route in the computer system matches the pilots' assigned route. If it doesn't, you must either change the route in the computer, or tell Controller B.
2.) After you have established radar contact, and resolved any separation problems, you then initiate handoff, either via an automated system or via landline.
3.) If the aircraft doesn't have a tag, you must describe the location, code and route of the aircraft to controller B at the time of initiating handoff.
4.) Controller B may either decline the handoff, accept it, or accept it with conditions which must be issued by Controller A prior to transferring communications.
5.) After the handoff has been completed, Controller A keeps the aircraft on his frequency until all potential conflicts in his airspace have been resolved, but transfers communications to Controller B in plenty of time to ensure that the transfer is complete prior to the aircraft entering Controller B's airspace.
6.) After communications have been transferred, Controller B may not alter the route, altitude or code of the aircraft without first APREQ'ing it with Controller A.
7.) Control for turns, climb, descent or control on contact can be used to get around point 6.
8.) A controller may choose to accept a 'point out' if he doesn’t' want to talk to the aircraft, with or without conditions.
9.) An aircraft that has not been handed off or pointed out may NOT enter Controller B's airspace under any circumstances.
SEE PART 2 of Understanding Handoffs and Coordination[/quote]
