Narrative:

Air carrier nebound flight plan (dfw to rdu via pbf 247061 direct vxv) appeared to ZTL controllers to proceed along the boundary between rqz sector and mqy sector, entering ZME airspace prior to entering csv sector. From previous occurrences of this problem, it appears that the flight plan is sent by the ZTL computer to the ZME computer, but the ZME computer does not accept the flight plan. It appears that no controller at ZME or ZTL is ever made aware of the problem. The aircraft subsequently enters the csv, which has no flight plan strips on the flight (neither will any subsequent sector). Since the flight plan processing terminates at the csv/mqy boundary, it seems possible that the flight plan information stored in the computer will eventually 'drop out,' leaving no information on the flight at all. The potential for an airspace deviation or aircraft incident is dramatically increased by this situation. This has been occurring for some time, and any action taken to correct it has (obviously) been ineffective. It would seem that discussions/negotiations between ZTL and ZME automation personnel would be useful for finding an automation solution. Failing that, moving one end of the boundary 1 or 2 mi north or south might solve the problem. (Clearing aircraft direct to vxv VORTAC appears to initiate the problem since this boundary lies directly 'in line' with the VORTAC -- moving the boundary might create a more distinct crossing point, eliminating the problem.)

Google
 

Original NASA ASRS Text

Title: REJECTION OF FLT PLAN BY ZME FROM ZTL PREVENT FURTHER PASSAGE OF THE FLT PLAN INFO TO THE APPROPRIATE CTR SECTORS LEADING TO THE DROPPING OF THE FLT PLAN IN THE SYS.

Narrative: ACR NEBOUND FLT PLAN (DFW TO RDU VIA PBF 247061 DIRECT VXV) APPEARED TO ZTL CTLRS TO PROCEED ALONG THE BOUNDARY BTWN RQZ SECTOR AND MQY SECTOR, ENTERING ZME AIRSPACE PRIOR TO ENTERING CSV SECTOR. FROM PREVIOUS OCCURRENCES OF THIS PROB, IT APPEARS THAT THE FLT PLAN IS SENT BY THE ZTL COMPUTER TO THE ZME COMPUTER, BUT THE ZME COMPUTER DOES NOT ACCEPT THE FLT PLAN. IT APPEARS THAT NO CTLR AT ZME OR ZTL IS EVER MADE AWARE OF THE PROB. THE ACFT SUBSEQUENTLY ENTERS THE CSV, WHICH HAS NO FLT PLAN STRIPS ON THE FLT (NEITHER WILL ANY SUBSEQUENT SECTOR). SINCE THE FLT PLAN PROCESSING TERMINATES AT THE CSV/MQY BOUNDARY, IT SEEMS POSSIBLE THAT THE FLT PLAN INFO STORED IN THE COMPUTER WILL EVENTUALLY 'DROP OUT,' LEAVING NO INFO ON THE FLT AT ALL. THE POTENTIAL FOR AN AIRSPACE DEV OR ACFT INCIDENT IS DRAMATICALLY INCREASED BY THIS SIT. THIS HAS BEEN OCCURRING FOR SOME TIME, AND ANY ACTION TAKEN TO CORRECT IT HAS (OBVIOUSLY) BEEN INEFFECTIVE. IT WOULD SEEM THAT DISCUSSIONS/NEGOTIATIONS BTWN ZTL AND ZME AUTOMATION PERSONNEL WOULD BE USEFUL FOR FINDING AN AUTOMATION SOLUTION. FAILING THAT, MOVING ONE END OF THE BOUNDARY 1 OR 2 MI N OR S MIGHT SOLVE THE PROB. (CLRING ACFT DIRECT TO VXV VORTAC APPEARS TO INITIATE THE PROB SINCE THIS BOUNDARY LIES DIRECTLY 'IN LINE' WITH THE VORTAC -- MOVING THE BOUNDARY MIGHT CREATE A MORE DISTINCT XING POINT, ELIMINATING THE PROB.)

Data retrieved from NASA's ASRS site as of July 2007 and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.