| Basic Concepts |
| The procedures for operating with the
Oceanic FSS are a little different than working with you radar-based
neighboring ARTCCs/FIRs. Understand that the Oceanic Controller is
simulating a "non-radar" position. The oceanic controller is
using the radar client program only to facilitate communications, not to
separate traffic. He may not be looking at actual targets and data tags
on his radar client program. The FSS position will never issue
"radar vectors". All separation is done by setting fixed
spacing onto the oceanic route system and managing speed and altitude.
To accomplish this, a key element is the oceanic clearance covered
below.
The Oceanic FSS may be operating as one position, ZAK_FSS, on 131.95 and a voice callsign of "San Francisco Radio". Additionally, the FSS may open two sub sectors on the east and west borders. The east sector bordering Vancouver, Seattle, Oakland, and Los Angeles Centers will be ZAK_E_FSS on 122.50, "Oakland Radio" on voice. The west sector bordering Honolulu ARTCC will be ZAK_W_FSS on 122.60, "Honolulu Radio" on voice. When these border FSS stations are open you will interact with them, and not the Central sector.
|
| Oceanic Clearances and TCPs |
| Each ARTCC/FIR that borders the Oakland
Oceanic FSS needs to coordinate traffic flow onto the oceanic routes.
The FSS will manage flow control onto the routes by issuing an Oceanic
Clearance (OC). There are two scenarios requiring OCs. The first is a
departure from your Center. The second is a transit from that originated
in another Center but will join the oceanic route in your airspace.
Generally OCs are requested by one Center sector, who handles the sky
with the oceanic route entry paths. However, some Centers may delegate
permission for DEL functions to call the FSS directly for OCs. Check
your local SOP. The OC is based on the estimated time the aircraft will
pass over the Transfer-of-Control-Point or TCP. The TCP is the fix that
lies on the border between the Center and Oceanic FIR. As a Center
controller, you would obtain OCs for each aircraft based on their
estimated TCP Time.
You can find the TCP fixes listed on the route details pages on this web site. Go to the Info for Adjacent Centers page, and click on your ARTCC/FIR to see its details. You will see the TCP for your outbound routes, as well a table of inbound routes. To illustrate the OC process, lets work thru two examples. Example 1: AAL1028 is on the ground at PHNL, looking for IFR clearance to KSEA via the MMK4.ZIGIE.A331 at FL370. He calls HNL_GND. The time is now 17:07Z. AAL1028: "HNL_GND, AAL1028,gate C-5, IFR to KSEA." HNL_GND: "Clearance on request." HNL_GND will now perform his normal Flight Plan checks and prepare a departure clearance. He knows that KZAK_FSS is open, and he will also need an Oceanic Clearance. To request the clearance, he will need an estimated TCP time. He will access the oceanic web site and view the route details for A331. He notes on the "Estimating time to CTR TCP table" that departure on MMK4.ZIGIE will take approximately 54 minutes to reach the TCP, ZURIC. He also has been tracking the average time from clearance to takeoff and notes they are taking about 10 minutes. So if AAL1028 is cleared at 17:08Z, he should take off about 17:18Z. Then 54 minutes later should be crossing ZURIC, at 18:12Z. This is the estimated TCP Time. Now he will call for an OC. HNL_GND to HNL_CTR: "Reqst OC AAL1028 FL370 ZURIC 18:12Z" HNL_CTR to ZAK_FSS: "Reqst OC AAL1028 FL370 ZURIC 18:12Z" ZAK_FSS to HNL_CTR: "AAL1028, JC" ("JC" are the FSS controllers 'operating initials' and means that FSS controller "JC" has granted the OC as requested). HNL_CTR to HNL_GND: "AAL1028, OC appvd." (No specific phraseology is called for here, and can be set by local SOP). HNL_GND: "AAL1028, Clearance available. Advise ready to copy." or... KZAK_FSS to HNL_CTR: "AAL1028, ZURIC 18:27Z" (means that a slot is not available on A331 at FL350 until 18:27). HNL_CTR to HNL_GND: "AAL1028, ZURIC 18:27Z"
HNL_GND: "AAL1028,
Expect Oceanic Clearance ZURIC 18:27Z, taxi at 17:22. Advise ready to
copy."
Example 2: ACA301 is airborne out of CYVR, transiting through
SEA_CTR to join A331, climbing to FL350 and approaching TOU. The time is
now 20:37Z. SEA_CTR will access the oceanic web site and view the route
details for A331. He notes that the
segment from TOU to the TCP, SEDAR, is 182nm, and at groundspeed of 455,
will take 24 minutes to SEDAR. However, he observes ACA301s groundspeed
to be 405. He can guestimate a longer travel time at say 28 minutes, or
use the formula 60 * (distance / groundspeed) to find the actual travel
time would be 26.9 minutes. Thus the estimated TCP is 20:37+27=
21:04Z. SEA_CTR to KZAK_FSS:
"Reqst OC ACA301 FL350 SEDAR 21:04Z" KZAK_FSS to SEA_CTR:
"ACA301, JC" SEA_CTR notes the OC on paper. At 20:45 it
is clear that the groundspeed has picked up. He's now showing 510 GSP
with 67nm to SEDAR. This will put him at SEDAR at 20:54. If the TCP
estimate is off from the OC Time by more than 5 minutes you need to
amend the OC, as follows: SEA_CTR to KZAK_FSS:
"ACA301 FL350 was SEDAR 21:04Z, now 20:54" KZAK_FSS to SEA_CTR:
"ACA301, unable" Uh-oh. KZAK_FSS can't slot him in early. This may be due to traffic
ahead on the route. The FSS must put 15 minutes between aircraft at the
same FL. You will need to issue a speed reduction or vector to delay
ACA301's arrival over SEDAR until 21:04. If you issues a speed
restriction, be sure to remember to release it before the handoff to the
FSS. A way around having to do all the math yourself is to get the pilot
to look it up on his FMS like this: SEA_CTR: "ACA301,
Sir, what is your estimated time for SEDAR ?" ACA301: "Showing
SEDAR 20:54Z". You can even have the aircraft match his OC as follows, but try to
issue a restriction like this after the aircraft is established into
cruise with a steady airspeed: SEA_CTR: "ACA301,
cross SEDAR at or after 21:04Z" ACA301: "Slowing to
cross SEDAR 21:04Z." |
| Handoffs to the FSS |
Since the FSS is not a radar position, do
not use the radar client handoff feature to handoff aircraft to the FSS.
The FSS needs no interphone call, so long as there are no special
conditions and the aircraft is within 5 minutes of the estimated TCP
time. Just issue the frequency change to the aircraft. Specifically, the
following actions should be taken to handoff aircraft:
Example: SEA_V_CTR: "American 1028, Entering the oceanic airspace. Squawk 2000. Radar service terminated. Report position to San Francisco Radio on 131.95." |
| Handoffs from the FSS |
| The FSS will not use the handoff feature for
your inbounds either. To assist in radar identification of inbounds, you
may call the FSS position and assign a beacon code to an aircraft
approaching the border. The FSS will pass this to the aircraft. In
addition, to assist in sequencing arrivals, you may request early
control of an aircraft like this:
SEA_V_CTR to ZAK_FSS: "Request Control, AAL1028."
|
| Time Compression Procedures |
The Oakland Oceanic FIR has established
fixed procedures for handling 2x and 4x flight. These requests cannot be
taken as lightly with no radar surveillance. Adjacent CTRs should insure
flights are 1x at time of handoff. The FSS can not approve pilot
requests to transit at "multiple-x". To allow pilots a
structured method for transiting the vast oceanic space under "time
compression", certain altitudes are allocated for multiple-x as
follows:
Note that these routes will be operated under Reduced Vertical Separation Minimums, thus aircraft should file with a "/W" or appropriate equipment indicator. Pilots should also indicate intentions to use the procedure in their flight plan comments (e.g.: "R464 - 2x"). The flights will not be at multiple-X the entire length of the route. 1X "buffer zones" will be used at either end to setup and return the flights to 1x and insure sequencing has been preserved. |
| Other Items |
A few other items you should know:
|