Narrative:

The san diego area is unique to sct because of its close proximity with tijuana approach control. On feb/mon/02, sct experienced 2 incidents which need to be addressed. With over 40 mi of shared boundary, the san diego area experiences target swaps with aircraft arriving and departing tijuana on almost a daily basis. B737, an arrival to san diego from the northwest, approached north sector's boundary at over 400 KTS. Somewhere outside of the controller's range, the tag for the B757 had acquired on the same beacon code of an aircraft arriving tijuana. The controller at ZLA sector 21 needed to make a manual handoff. From their perspective everything seemed normal except the north sector was not taking the handoff. The controller accepted the handoff and built the data tag. This all takes time. He builds an abbreviated data tag using a different call sign, which each controller must then coordinate forward verbally. The system is providing a false sense of security to the controllers. If the controller at ZLA knew they would need to make a manual handoff, then they can prepare for it. If the controller at sct knew he would be accepting a manual handoff from ZLA and that he could not build a normal data tag with the correct call sign, he could also have gotten help. 11 mins later, the southbay sector experienced something similar. Sdm tower requested a release for aircraft Y, a bizjet, to vny. The controller at southbay observed the call sign in his list, had the flight plan in front of him, then released the aircraft. Just then, the data tag of aircraft Y then acquired on an aircraft in mexican airspace. The controller expected an automatic acquisition on the beacon code. He checked the beacon code to see if it was correct. It was. He attempted to start a track on both the beacon code and the call sign. It wouldn't work because the data tag was being tracked somewhere outside of his set range. Normally one would build an abbreviated dat block. However, the whole flight plan dropped out of the system and another flight plan needed to be put in. 4 yrs ago this issue was addressed as a safety concern. I feel it needs to be readdressed. Data tags acquire on mexican traffic on a daily basis. The air traffic system works smoothly as long as ATC's can rely on it, and not concern themselves with system failures. This type of problem leads controllers into a false sense of security. One does not have time to get help unless they can foresee what is to come. The ATC system performed well, and the flying public perception of the problem was transparent. Both incidents occurred during a time when traffic was light to moderate. Even then, the controller's workload immediately increased to the individual's limit, and stays there until data tags are built or flight plans put in the system. What is needed is a beacon code allocation agreement between mexico and the san diego area. Callback conversation with reporter revealed the following information: reporter advised that similar events continue to be documented weekly. Reporter is aware that these type events have been elevated from the facility level to the western pacific regional office for review and resolution. The reporter alleges that this problem has been tracked and discussed for a number of years without resolution.

Related reports:

Google
 

Original NASA ASRS Text

Title: SCT CTLR ALLEGES BEACON CODE ALLOCATION DEFICIENCY BTWN UNITED STATES AND MEXICO WHEN ACFT IN HDOF AUTO-ACQUIRE ON ACFT WITH SAME BEACON CODE IN MEXICAN AIRSPACE.

Narrative: THE SAN DIEGO AREA IS UNIQUE TO SCT BECAUSE OF ITS CLOSE PROX WITH TIJUANA APCH CTL. ON FEB/MON/02, SCT EXPERIENCED 2 INCIDENTS WHICH NEED TO BE ADDRESSED. WITH OVER 40 MI OF SHARED BOUNDARY, THE SAN DIEGO AREA EXPERIENCES TARGET SWAPS WITH ACFT ARRIVING AND DEPARTING TIJUANA ON ALMOST A DAILY BASIS. B737, AN ARR TO SAN DIEGO FROM THE NW, APCHED N SECTOR'S BOUNDARY AT OVER 400 KTS. SOMEWHERE OUTSIDE OF THE CTLR'S RANGE, THE TAG FOR THE B757 HAD ACQUIRED ON THE SAME BEACON CODE OF AN ACFT ARRIVING TIJUANA. THE CTLR AT ZLA SECTOR 21 NEEDED TO MAKE A MANUAL HDOF. FROM THEIR PERSPECTIVE EVERYTHING SEEMED NORMAL EXCEPT THE N SECTOR WAS NOT TAKING THE HDOF. THE CTLR ACCEPTED THE HDOF AND BUILT THE DATA TAG. THIS ALL TAKES TIME. HE BUILDS AN ABBREVIATED DATA TAG USING A DIFFERENT CALL SIGN, WHICH EACH CTLR MUST THEN COORDINATE FORWARD VERBALLY. THE SYS IS PROVIDING A FALSE SENSE OF SECURITY TO THE CTLRS. IF THE CTLR AT ZLA KNEW THEY WOULD NEED TO MAKE A MANUAL HDOF, THEN THEY CAN PREPARE FOR IT. IF THE CTLR AT SCT KNEW HE WOULD BE ACCEPTING A MANUAL HDOF FROM ZLA AND THAT HE COULD NOT BUILD A NORMAL DATA TAG WITH THE CORRECT CALL SIGN, HE COULD ALSO HAVE GOTTEN HELP. 11 MINS LATER, THE SOUTHBAY SECTOR EXPERIENCED SOMETHING SIMILAR. SDM TWR REQUESTED A RELEASE FOR ACFT Y, A BIZJET, TO VNY. THE CTLR AT SOUTHBAY OBSERVED THE CALL SIGN IN HIS LIST, HAD THE FLT PLAN IN FRONT OF HIM, THEN RELEASED THE ACFT. JUST THEN, THE DATA TAG OF ACFT Y THEN ACQUIRED ON AN ACFT IN MEXICAN AIRSPACE. THE CTLR EXPECTED AN AUTO ACQUISITION ON THE BEACON CODE. HE CHKED THE BEACON CODE TO SEE IF IT WAS CORRECT. IT WAS. HE ATTEMPTED TO START A TRACK ON BOTH THE BEACON CODE AND THE CALL SIGN. IT WOULDN'T WORK BECAUSE THE DATA TAG WAS BEING TRACKED SOMEWHERE OUTSIDE OF HIS SET RANGE. NORMALLY ONE WOULD BUILD AN ABBREVIATED DAT BLOCK. HOWEVER, THE WHOLE FLT PLAN DROPPED OUT OF THE SYS AND ANOTHER FLT PLAN NEEDED TO BE PUT IN. 4 YRS AGO THIS ISSUE WAS ADDRESSED AS A SAFETY CONCERN. I FEEL IT NEEDS TO BE READDRESSED. DATA TAGS ACQUIRE ON MEXICAN TFC ON A DAILY BASIS. THE AIR TFC SYS WORKS SMOOTHLY AS LONG AS ATC'S CAN RELY ON IT, AND NOT CONCERN THEMSELVES WITH SYS FAILURES. THIS TYPE OF PROB LEADS CTLRS INTO A FALSE SENSE OF SECURITY. ONE DOES NOT HAVE TIME TO GET HELP UNLESS THEY CAN FORESEE WHAT IS TO COME. THE ATC SYS PERFORMED WELL, AND THE FLYING PUBLIC PERCEPTION OF THE PROB WAS TRANSPARENT. BOTH INCIDENTS OCCURRED DURING A TIME WHEN TFC WAS LIGHT TO MODERATE. EVEN THEN, THE CTLR'S WORKLOAD IMMEDIATELY INCREASED TO THE INDIVIDUAL'S LIMIT, AND STAYS THERE UNTIL DATA TAGS ARE BUILT OR FLT PLANS PUT IN THE SYS. WHAT IS NEEDED IS A BEACON CODE ALLOCATION AGREEMENT BTWN MEXICO AND THE SAN DIEGO AREA. CALLBACK CONVERSATION WITH RPTR REVEALED THE FOLLOWING INFO: RPTR ADVISED THAT SIMILAR EVENTS CONTINUE TO BE DOCUMENTED WEEKLY. RPTR IS AWARE THAT THESE TYPE EVENTS HAVE BEEN ELEVATED FROM THE FACILITY LEVEL TO THE WESTERN PACIFIC REGIONAL OFFICE FOR REVIEW AND RESOLUTION. THE RPTR ALLEGES THAT THIS PROB HAS BEEN TRACKED AND DISCUSSED FOR A NUMBER OF YEARS WITHOUT RESOLUTION.

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.