ZOB D-Side Controller described a confused re-routing/coordination event when the RADAR Controller attempted to reroute an aircraft close to another sectors boundary requiring multiple coordination and automation actions.
Synopsis
ZOB D-Side Controller described a confused re-routing/coordination event when the RADAR Controller attempted to reroute an aircraft close to another sectors boundary requiring multiple coordination and automation actions.
Narrative
I was working the D-Side at Sandusky (07). My R-Side asked me to route Air Carrier X in direct DRK. I did; he issued it to the pilot; and the pilot accepted it. About 30 seconds after it was issued; the pilot came back and asked for the spelling of the DRK. The R-Side gave it to the pilot and then the pilot said that they wanted to stay on their original route. My R-Side put the aircraft back on its route and I went to the User Request Evaluation Tool (URET) to put the previous route back in on the aircraft; [but] the computer would not accept it. I tried one or two more times and was still unsuccessful. After that; I tried unsuccessfully to enter the information manually. By this time the aircraft was level at FL260. While I was doing that my R-Side pointed Air Carrier X out to the Dayton (I88) Sector and told them we were putting the routing in on the aircraft and would flash the aircraft to them when we were done. Dayton agreed and told us to leave the aircraft at FL260. The R-Side then pointed the aircraft out to the FWA (G36) Sector. My R-Side tried 3 times to give the routing information to ZID after we discovered we could not get it in the machine and they said they would call us back. Finally; I called Dayton and forwarded the route information and they called R-Side contact and the R-Side person put the aircraft on the Dayton sector. Don't get into a bad situation of shortcutting an aircraft so close to the boundary; because the information might not pass successfully.
Second reporter narrative
I had between 8 and 12 aircraft on frequency working the morning push out of CLE and DTW handing quite a few aircraft off to DAY Sector (I88) in ZID. Air Carrier X was southwest bound out of CLE and traffic with several other aircraft coming out of DTW. I decided to keep Air Carrier X moving westbound to clear up the corridor a bit and alleviate some of the pressure on DAY and SGF sectors. I asked my D[-Side] guy to put direct DRK in the machine for Air Carrier X; which he did. After he did so; I pick and entered the route into ZAU airspace and PVD'd the aircraft to Indy intending to point him out to them later. Then I issued direct DRK to Air Carrier X; which he accepted. About 30 seconds later the pilot of Air Carrier X asked if I could give him the identifier for DRK and I did. Shortly after he came back and said he wanted to stay on his original flight plan. I asked my D[-Side] guy to put in the previous route and he told me it wouldn't take. I realized that I had picked and entered to ZAU which is why previous route was not working. I asked the pilot to repeat his previous route. As he did I PVD'd the aircraft to and called DAY to coordinate it entering their airspace while we got the old route and put it in the machine. I let him know we would flash the hand off when we accomplished that. He instructed me to leave the aircraft at FL260; which I did. I discovered that the D[-Side] guy had not heard the read back of the route so we re-asked the pilot for it. In the mean time I ensured the other aircraft were getting moved and handed off and pointed out. After several failed attempts to enter the route I re-initiated communication with DAY to attempt to pass the flight plan via land line. The DAY Controller was somewhat slow to cooperate. By this time the aircraft was approaching a boundary with ZAU in ZID airspace so I pointed the aircraft out to the ZAU Sector (G36). Shortly after I attempted to get DAY to take flight plan info over the land line asking him to have his D[-Side] guy pick up the line. My D[-Side] guy was working on it too and the DAY Controller talking to him took the info and RADAR contact. The DAY Controller I was talking to said [to] put him on me so I transferred communication of Air Carrier X to DAY. While there are several opportunities to improve the system exposed here; there is one my supervisor suggested which I think I will heed. The supervisor offered that it is setting yourself up for a pilot or other controllers to affect your ability to accomplish your tasks when you make changes close to the boundary. I also think that a practice of asking a pilot if he wants direct to a fix prior to entering it will protect against this type of occurrence. Systemically there are a couple of thoughts that come to mind; 1) There may be a need to reinforce the ability to quickly receive flight plan information verbally on the land lines in the workforce; 2) An improvement in URET that would enable swift retrieval of multiple layers of previous flight plans could avoid this dilemma; [and] 3) The ability to make a hand off to a facility that the host route of flight does not penetrate seems like it would be a 'fix all' here. The need for that to include flight plan transmission would be essential of course. It is my understanding that the ERAM platform will be able to do just that. In the interim (which obviously is of unknown duration) between current capability and En Route Automation Modernization (ERAM) deployment maybe the URET fix could be implemented.
Source: NASA Aviation Safety Reporting System (public domain). Reports are voluntary submissions and are not verified by NASA.