VATUSA Forums
General => The Control Room Floor => Topic started by: Dhruv Kalra on October 16, 2015, 10:14:30 AM
-
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."
-
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.
-
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.
-
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.
-
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?
-
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. :P
-
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"(?).
-
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. :o
-
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. :o
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.
-
Yikes!!! I believe we have a difference of opinion here! :D 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?
-
Yikes!!! I believe we have a difference of opinion here! :D 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.
-
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.
-
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.
-
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 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.
-
From a CPC/OJTI friend at C90: "ZAU can accept a handoff 10 miles south of ORD, and I can vector the aircraft all over the sky and do whatever I want with him without coordination as long as I ship him IAW the C90/ZAU LOA. The fact that the next controller knows he's coming doesn't mean anything as far as how I work the a/c."
My interpretation of 5-4-5(b) is in line with Wes - the way I read that is subsequent instructions to bring the plane in line with the LOA'd procedure are fine; you just have to coordinate anything that is going to be contrary to the LOA prior to transfer of control/comms.
-
My interpretation of 5-4-5(b) is in line with Wes - the way I read that is subsequent instructions to bring the plane in line with the LOA'd procedure are fine; you just have to coordinate anything that is going to be contrary to the LOA prior to transfer of control/comms.
Eh.. Wes wasn't limiting to LOA. His interpretation, from what he's posted, allows him to do whatever with the aircraft inside his airspace after the handoff has been initiated so long as he doesn't touch NAS information. This differs from my interpretation, which is you cannot change anything EXCEPT what is understood through facility directives intrafacility or LOA interfacility. Wes posted he can give a 360 to a guy after handoff is initiated as long as it's still in his airspace and he doesn't touch NAS information.
-
Same here at RW ZFW. D10 may perform an automated handoff, but will many times continue to alter course and altitude as needed. They just will not comm change the aircraft until the appropriate instruction are given which put them IAW the letter, or otherwise coordinated.
Similar to 6s post the aircraft remain in D10s airspace and NAS information is not altered.
-
I should specify: as long as the aircraft is flying IAW LOAs/NAS route/altitude by the time comms are transferred, I believe there to be no issue.
-
I should specify: as long as the aircraft is flying IAW LOAs/NAS route/altitude by the time comms are transferred, I believe there to be no issue.
This is my interpretation as well.
-
I should specify: as long as the aircraft is flying IAW LOAs/NAS route/altitude by the time comms are transferred, I believe there to be no issue.
This is my interpretation as well.
Which, on VATSIM, there are rarely loas or procedures allowing turns and changes inside of a artcc/ccf airspace. So turns and the like, in theory, couldn't be applied on the VATSIM environment once a handoff has been initiated because there are no loas allowing it. The .65 doesn't define flight path as a nas route, etc. so to me that means it's heading, assigned or otherwise as that is how it's used elsewhere in the .65 in rules like passing and diverging, etc.
-
Which, on VATSIM, there are rarely loas or procedures allowing turns and changes inside of a artcc/ccf airspace. So turns and the like, in theory, couldn't be applied on the VATSIM environment once a handoff has been initiated because there are no loas allowing it. The .65 doesn't define flight path as a nas route, etc. so to me that means it's heading, assigned or otherwise as that is how it's used elsewhere in the .65 in rules like passing and diverging, etc.
Yeah, but doesn't the overriding principle of General Control apply? Namely, the plane is your control while under your area of jurisdiction and that the handoff is nothing more than the transfer of radar ID?
-
Which, on VATSIM, there are rarely loas or procedures allowing turns and changes inside of a artcc/ccf airspace. So turns and the like, in theory, couldn't be applied on the VATSIM environment once a handoff has been initiated because there are no loas allowing it. The .65 doesn't define flight path as a nas route, etc. so to me that means it's heading, assigned or otherwise as that is how it's used elsewhere in the .65 in rules like passing and diverging, etc.
Yeah, but doesn't the overriding principle of General Control apply? Namely, the plane is your control while under your area of jurisdiction and that the handoff is nothing more than the transfer of radar ID?
No because the responsibilities of the transferring controller (5-4-5) now applies.
-
Which, on VATSIM, there are rarely loas or procedures allowing turns and changes inside of a artcc/ccf airspace. So turns and the like, in theory, couldn't be applied on the VATSIM environment once a handoff has been initiated because there are no loas allowing it. The .65 doesn't define flight path as a nas route, etc. so to me that means it's heading, assigned or otherwise as that is how it's used elsewhere in the .65 in rules like passing and diverging, etc.
Yeah, but doesn't the overriding principle of General Control apply? Namely, the plane is your control while under your area of jurisdiction and that the handoff is nothing more than the transfer of radar ID?
No because the responsibilities of the transferring controller (5-4-5) now applies.
I want to throw in my two cents. My background is 8 years in the FAA, 7 of them being at two different terminal radar facilities. One has probably the most complex LOAs in the world between the TRACON and overlying center, and the other has probably one of the simplest (two different overlying ARTCCs).
5-4-5 b. simply means that once an aircraft is in automated handoff status, changes to the aircraft's flight plan information can't be made without verbal coordination. Consequently, they have made it impossible to do this by not allowing FDIO changes once an aircraft is in handoff status (speaking TRACON/TRACON and TRACON/ARTCC...I don't know what capabilities exist in the enroute world). Before ERAM, we had a requirement (in an LOA) to verbally coordinate all FDIO changes made within 15 minutes on initiating the handoff to ensure the receiving controller had the most up-to-date information.
The intent of that paragraph is not to forbid the initiating controller from working the aircraft in his airspace after an automated hand-off has been initiated. In fact, in many places, it would be impossibly to comply with that interpretation because aircraft go into automated handoff status without input from the controller.
LOA's don't have anything to do with how a controller may work an aircraft up to the transfer of control point. A lack of an LOA doesn't have anything to do with how a controller may work an aircraft up to the transfer of control point; they're totally unrelated.
Why then does 5-4-5 b. say "unless otherwise specified by a LOA or a facility directive."?
Because some LOA's/Facility Directives require aircraft to be delivered at specific speeds/headings/altitudes, etc... regardless of requested speed/altitude/routing and FDIO changes after the handoff has been initiated would not change how the receiving controller would receive the aircraft. Some facilities have the ability to change data block information on other controller's aircraft (requested altitudes, assigned speeds, route information, etc....).
Another way to look at it is from the point of view of the receiving controller. If I take a handoff on an aircraft, where I don't have any LOA with the initiating controller's facility on how this aircraft shall be delivered, I expect that the aircraft will be at its requested altitude and on the route in the FDIO. If, 10 miles from the boundary, the aircraft turns 40 degrees for some reason, what do I care? As long as he's pointed back toward his routing before he is shipped to me, it doesn't affect me in the least. When I'm working ORD arrivals, I don't care if ZAU has airliners zig-zagging all over their sector before coming to me. The fact that there's an LOA specifying how those planes will be delivered eventually doesn't make a difference to me; once the aircraft is switched to me and enters my airspace, then I can worry about it.
Now, if somebody has decided that their interpretation is that once the handoff has been initiated, they can no longer give any control instructions without verbal coordination, that doesn't really affect me either, so have at it. That's clearly not the intent, but it doesn't affect my operation, and I wouldn't even know that was the case because I'm not listening to how the initiating controller is working his airplanes.
One last thought. There are facility managers and district managers and OMs and supervisors who have ridiculous interpretations on different things in the 7110.65 that are not FAA-wide. It could very well be a directive in Fairbanks that once a handoff has been initiated, you aren't allowed to give any other control instructions without verbal coordination. For a while at ARR ATCT, if the ATIS advertised runway 27, aircraft couldn't operate on runway 15, even if there were no other aircraft within 100 miles of the airport, because of the managers unfounded interpretation of a new opposite direction procedure. Meanwhile, the other 4 FAA towers in the area actually followed the intent of the directive and ran similar operations without an issue. Even ORD ATCT can't roll a 22L departure if a heavy lands on 28C because of wake turbulence because someone somewhere has interpreted the wake turbulence rules to mean that an aircraft just beginning its takeoff roll is considered to be flying through the heavy's flight path.
Particularly since it is VATSIM, it is not wrong for a controller to not give control instructions after initiating a handoff, but it's absolutely not wrong for a controller TO give control instructions after a handoff has been initiated.
I would love to see the "reject handoff" feature to be eliminated from VATSIM. That's one of the most unrealistic features on the ATC side of the network. If someone is flashing and I, for some reason, don't want to take the handoff (or the handoff should be going somewhere else -- it happens sometimes), then I'll ignore it or verbally coordinate, "hey, I think you meant to flash him at the low sector, not me." I take handoffs 20 miles outside of my airspace all day long (only because usually that's the edge of my scope). It wouldn't bother me to take one 100 miles away because I know the initiating controller is going to ship me a clean airplane.
-
Which, on VATSIM, there are rarely loas or procedures allowing turns and changes inside of a artcc/ccf airspace. So turns and the like, in theory, couldn't be applied on the VATSIM environment once a handoff has been initiated because there are no loas allowing it. The .65 doesn't define flight path as a nas route, etc. so to me that means it's heading, assigned or otherwise as that is how it's used elsewhere in the .65 in rules like passing and diverging, etc.
Yeah, but doesn't the overriding principle of General Control apply? Namely, the plane is your control while under your area of jurisdiction and that the handoff is nothing more than the transfer of radar ID?
No because the responsibilities of the transferring controller (5-4-5) now applies.
Now, if somebody has decided that their interpretation is that once the handoff has been initiated, they can no longer give any control instructions without verbal coordination, that doesn't really affect me either, so have at it. That's clearly not the intent, but it doesn't affect my operation, and I wouldn't even know that was the case because I'm not listening to how the initiating controller is working his airplanes.
I wouldn't go so far as to say "that's clearly not the intent", as clearly the intent is not obvious. The wording describe matches similar in other procedures in the order to include heading assignments and not just NAS information. To me, if it was restricted to NAS information, they would've chosen wording to indicate such.
If, 10 miles from the boundary, the aircraft turns 40 degrees for some reason, what do I care? As long as he's pointed back toward his routing before he is shipped to me, it doesn't affect me in the least.
I would say you definitely should care. If the aircraft turns after the handoff has been initiated in a way that doesn't comply with SOP/LOA/filed routing and wasn't coordinated, it could limit your ability to comply with 5-4-6(b) "Issue restrictions that are needed for the aircraft to enter your sector safely before accepting the handoff" and that 5-4-5(b) ensures that you do not do something so as to change the aircraft's path that no longer allows the aircraft to enter the sector safely. Note that this isn't just lateral, but vertical as well. Having worked with what the military has to offer controller wise, I never assume that an aircraft will get turned back toward the gate before comm transfer as I've seen it happen countless times which to me implies the wording is meant to try and alleviate that and allow me to follow 5-4-6(b).
One last thought. There are facility managers and district managers and OMs and supervisors who have ridiculous interpretations on different things in the 7110.65 that are not FAA-wide. It could very well be a directive in Fairbanks that once a handoff has been initiated, you aren't allowed to give any other control instructions without verbal coordination. For a while at ARR ATCT, if the ATIS advertised runway 27, aircraft couldn't operate on runway 15, even if there were no other aircraft within 100 miles of the airport, because of the managers unfounded interpretation of a new opposite direction procedure. Meanwhile, the other 4 FAA towers in the area actually followed the intent of the directive and ran similar operations without an issue. Even ORD ATCT can't roll a 22L departure if a heavy lands on 28C because of wake turbulence because someone somewhere has interpreted the wake turbulence rules to mean that an aircraft just beginning its takeoff roll is considered to be flying through the heavy's flight path.
Agreed, there are some times when ridiculous interpretations put a damper on operations. It happens everywhere. However, this isn't a FAI directive but rather an interpretation by various controllers from each place I've been. There are an odd couple that believe it's NAS but they've mostly been in VATUSA and not the agency. Had 1 new E7 at one of my Navy facilities (some years ago) remove a procedure we had used for half a decade called "turn on reset". Basically our VISCOMs for GCA to tower would stay lit until someone hit the reset (after the approach terminated). It was generally the local controller after the aircraft was observed executing climb outs. Sometimes they would want the aircraft turned away from the airport sooner than 2 miles so as to launch an IFR departure so they would coordinate a "turn on reset" and when they hit the reset radar would give the climb outs, tower would observe it being executed and then launch their departure. The procedure was eliminated because "there was no way to ensure radar issued the climb outs" and he had it removed from our SOPs.
-
If, 10 miles from the boundary, the aircraft turns 40 degrees for some reason, what do I care? As long as he's pointed back toward his routing before he is shipped to me, it doesn't affect me in the least.
I would say you definitely should care. If the aircraft turns after the handoff has been initiated in a way that doesn't comply with SOP/LOA/filed routing and wasn't coordinated, it could limit your ability to comply with 5-4-6(b) "Issue restrictions that are needed for the aircraft to enter your sector safely before accepting the handoff" and that 5-4-5(b) ensures that you do not do something so as to change the aircraft's path that no longer allows the aircraft to enter the sector safely. Note that this isn't just lateral, but vertical as well. Having worked with what the military has to offer controller wise, I never assume that an aircraft will get turned back toward the gate before comm transfer as I've seen it happen countless times which to me implies the wording is meant to try and alleviate that and allow me to follow 5-4-6(b).
No, really, I don't care. It's the controller who is transferring radar and communication to me that is responsible for ensuring the aircraft is clear of conflicts until it reaches the airspace boundary (laterally or vertically). If the first controller turns an aircraft away after you took radar, then ships him to you on a heading away from your airspace, then he screwed up not because he gave a control instruction prior to initiating an automated handoff, but because the aircraft didn't come to you on its assigned routing.
Seriously, this is the way it works at every other FAA radar facility in the country. I work the airplanes in my airspace and you work the airplanes in your airspace. I don't care if you give the airplane three 360's five miles from the boundary after I take the handoff as long as he enters my airspace on his assigned routing. You shouldn't care in the least what I do with an airplane before I transfer communication to you as long as the aircraft is on his assigned routing. If I took a handoff, and then you were able to get an amendment into the FDIO and didn't coordinate with me verbally, THEN 5-4-5 b applies.
-
If, 10 miles from the boundary, the aircraft turns 40 degrees for some reason, what do I care? As long as he's pointed back toward his routing before he is shipped to me, it doesn't affect me in the least.
I would say you definitely should care. If the aircraft turns after the handoff has been initiated in a way that doesn't comply with SOP/LOA/filed routing and wasn't coordinated, it could limit your ability to comply with 5-4-6(b) "Issue restrictions that are needed for the aircraft to enter your sector safely before accepting the handoff" and that 5-4-5(b) ensures that you do not do something so as to change the aircraft's path that no longer allows the aircraft to enter the sector safely. Note that this isn't just lateral, but vertical as well. Having worked with what the military has to offer controller wise, I never assume that an aircraft will get turned back toward the gate before comm transfer as I've seen it happen countless times which to me implies the wording is meant to try and alleviate that and allow me to follow 5-4-6(b).
No, really, I don't care. It's the controller who is transferring radar and communication to me that is responsible for ensuring the aircraft is clear of conflicts until it reaches the airspace boundary (laterally or vertically). If the first controller turns an aircraft away after you took radar, then ships him to you on a heading away from your airspace, then he screwed up not because he gave a control instruction prior to initiating an automated handoff, but because the aircraft didn't come to you on its assigned routing.
Seriously, this is the way it works at every other FAA radar facility in the country. I work the airplanes in my airspace and you work the airplanes in your airspace. I don't care if you give the airplane three 360's five miles from the boundary after I take the handoff as long as he enters my airspace on his assigned routing. You shouldn't care in the least what I do with an airplane before I transfer communication to you as long as the aircraft is on his assigned routing. If I took a handoff, and then you were able to get an amendment into the FDIO and didn't coordinate with me verbally, THEN 5-4-5 b applies.
Maybe that's how they do it at your facility, but that's not how it's done at "every other facility". Sorry my interpretation differs from yours, but it's solid and valid when reading the words as written as used elsewhere in the .65. You initiate a hand off, and I start applying 5-4-6 to ensure his path can safely enter my airspace before I accept. If it doesn't, I'm calling. If his path differs and there isn't anything in the loa for it, I'm calling. It's my job as the receiving controller to ensure that aircraft can enter my airspace safely BEFORE it accepting the handoff. If you turn it after initiating or acceptance without it in the loa or coordinated, you are preventing me from doing my job.
And yes, you should care. 5-4-6 requires you to ensure the aircraft will enter your airspace safely. If the other controller is turning him without the loa allowing it, facility directives, etc how do you know the aircraft will enter safely? You don't. You have to assume the other controller will put him back on his routing, and you know what everyone says about assuming. Now with an loa, by all means. Most loas in the FAA are likely to direct it by specifying correct procedures for departures out of the airspace. On VATSIM, many of those are missing. For instance, all ifr departures from FAI not on a sid going south must be vectored so as to exit the nenana gate heading 220. This allows me to vector without coordination IFR aircraft going south not on a sid.
-
This is becoming kind of a pedantic argument over a very simple paragraph in the .65. I certainly have no issue with a controller at a neighboring facility waiting to initiate a handoff until it doesn't have to give any other control instructions. But, it would be impossible for me to comply with that interpretation at my facility (as it would at probably every other level 10 and above radar facility in the FAA). As C90 gets regular compliance audits (internally and externally) and this has never come up, despite this scenario happening over 1000 times per day, I am confident that my interpretation is correct and that the FAA does not expect me to withhold automated transfer of radar ID of airplanes simply because I have to make a turn or climb close to the airspace boundary.
-
This is becoming kind of a pedantic argument over a very simple paragraph in the .65. I certainly have no issue with a controller at a neighboring facility waiting to initiate a handoff until it doesn't have to give any other control instructions. But, it would be impossible for me to comply with that interpretation at my facility (as it would at probably every other level 10 and above radar facility in the FAA). As C90 gets regular compliance audits (internally and externally) and this has never come up, despite this scenario happening over 1000 times per day, I am confident that my interpretation is correct and that the FAA does not expect me to withhold automated transfer of radar ID of airplanes simply because I have to make a turn or climb close to the airspace boundary.
John, I agree. However, at C90, you very likely have LOAs to specify what you need to do with aircraft being handed off to neighboring facilities. I have been at facilities where we would ocassionaly hand off to facilities where we didn't have an LOA, and as such, we had to apply that paragraph as written (ie, once the handoff has been initiated, you cannot touch its path and route without coordination). In FAA world, very rarely do you have neighboring radar facilities without some kind of LOA that specifies what to do with routing and allowing vectors to said route. In DoD land (and many places in VATUSA), this isn't always so and that's when the main part of that paragraph comes in to play. Note the end states unless otherwise specified by LOA.