|
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.
|