Co-ordination

General:

The purpose of the Coordination SOP is to outline when coordination should take place and how it should be undertaken. Accurate coordination is important because it mens that the controllers involved all understand what will be happening with an aircraft. It also means that VATNZ is able to more accurately simulate non-radar approach procedures.

With the release of EuroScope and the availability of it's built in automatic coordination functions, the ability to accurately simulate non-radar approach procedures and increased traffic in the oceanic sectors, there is a greater need to formalise flight plan handling and coordination between sectors. This reduces overall controller workload and allows controllers to provide a better service to pilots, especially in non-radar approach units.

Generally speaking, anything can be accomplished through the use of coordination. Given enough time, an adjacent controller will almost always do what they can to help you out. If you have any doubts about what an aircraft is doing or what they should be doing, talk to the adjacent controller.

Co-ordination

Coordination may take place using controller to controller chatbox messages, voice (intercom/override) transmissions or through other voice applications such as Teamspeak.

Non-standard Levels:

Approval is to be sought from the next controller for an aircraft to continue cruising at a non-standard level, prior to the aircraft reaching the common boundary. Use the phraseology: REQUEST NON-STANDARD (LEVEL) (CALLSIGN).

Climbs and Descents:

A receiving controller may descend arriving aircraft or climb departing aircraft prior to the aircraft entering their airspace, without coordination.

Direct Routings:

Unless otherwise specified in SOPs, coordination is required prior to clearing an aircraft direct to a Navaid/Waypoint in another controller's airspace. Use the phraseology: REQUEST DIRECT (NAVAID/WAYPOINT) (CALLSIGN).

Direct Routings from the receiving controller:

To facilitate separation and/or sequencing, the receiving controller may accept an aircraft direct to a waypoint or NAVAID which is on a more direct routing than their flightplan route. Use the phraseology: (CALLSIGN) ACCEPTED DIRECT (NAVAID/WAYPOINT).

Radar Releases

Tower Units with Radar Approach Services:

Prior to allowing an IFR flight to depart from an airport with a radar approach service, the Aerodrome controller shall request a RELEASE for the aircraft. This ensures that the approach controller has the appropriate separations in place prior to the aircraft departing. Use the phraseology: REQUEST RELEASE (Callsign) (Conditions/Requests). If the radar controller is able to accept the aircraft, they use the phraseology: (Callsign) RELEASED (Conditions - if applicable). Conditions/Requests can range from requests for an aircraft to climb on track, a departure from the non-duty runway, to conditions imposed by the radar controller as to when the release applies from. If the controller is unable to accept the aircraft, they use the phraseology: (callsign) HOLD.

Pre-Departure Clearance

Because procedural approach units own significantly more airspace compared to towers with a radar approach service and a release is not required before allowing an aircraft at a procedural approach airport to take off, it is important that adjacent radar or non-radar sectors are aware of a departing aircraft, which will enter their airspace, before it becomes airborne.

A pre-departure clearance is the process of obtaining permission for an aircraft to enter a controller’s airspace via a given route and at a given level. Information about the level and route of the flight are detailed in the flight plan.

A pre-departure clearance request is normally made once the departing aircraft requests start-up.

There are several ways to request a pre-departure clearance:

Verbal/Text Coordination:

Use the phraseology: REQUEST (callsign) (level) via (navaid/waypoint at airspace boundary)

e.g. REQUEST ANZ221, FL330 via KELSO

If the receiving controller is able to accept the aircraft at the level and on the route requested, they use the phraseology: (callsign) ACCEPTED (or APPROVED).

e.g. ANZ221 ACCEPTED.

If the receiving controller is unable to accept the aircraft at the level and on the route requested, they use the phraseology: (callsign) UNABLE (level and/or route) APPROVED/ACCEPTED (revised level and/or route).

Electronic Coordination (EuroScope):

Right click the COPX column for the required aircraft. From the drop down menu, select the fix at the common boundary. If the fix is not displayed in the drop down menu, select Enter Name and enter the fix name into the textbox.

Controllers/Standard Operating Procedures/Co-ordination SOP/Euroscope Coordination Ex1

The value for COPX will change to the selected/entered fix name and be displayed in yellow. The RFL will also be displayed in yellow. This indicates that the request is pending approval from the next controller.

Controllers/Standard Operating Procedures/Co-ordination SOP/Euroscope Coordination Ex2

If the accepting controller can accept the flight on the requested route at the requested level, they can right click on the COPN fix and accept the request. They can also change the requested fix and/or level as required. Verbal/Text coordination should follow a change in the requested route or level.

Flight Strip Annotation

There is a 3x3 matrix available on a flight strip to annotate information such as Estimate Time of Arrivals (ETA) for a given fix or fixes. The upper row is where the code for your waypoint or NAVAID is written. The second row is where the ETA for that waypoint/NAVAID is written and the last row is where the Actual Time of Arrival (ATA) is written

Annotation for aircraft arriving to procedural approach units:

The aircraft's ETA at the common boundary should be annotated in the first column (1) and th ETA for the destination airport should be annotated in the second column (2). The third column (3) is available for the approach sector to use as required. If there is no fix at the common boundary, the controller should make their best estimate based on the aircraft's current speed and distance to the common boundary

Note: Time (minutes) to fix = (Distance to fix in nautical miles) / Groundspeed of aircraft (knots) * 60

Annotation for aircraft departing from procedural approach units:

The aircraft's departure time should be annotated in the first column (1), in the ATA row and the ETA at the common boundary should be annotated in the second (2) column. If there is no fix at the common boundary, use the first waypoint in the aircraft's flight plan.

Annotation for aircraft entering or leaving the Auckland Oceanic FIR:

The first column (1) should be annotated with the ETA at the FIR boundary.

Sending Strips:

Using VRC - Right click on the strip, click Push To and select the unit from the list

Using EuroScope - Right click on the strip and select the unit to send the strip to from the drop down menu.

Flight Plan Handling

Flight plans are the main form of coordination between sectors. They have the ability to provide the controller informaton about the aircraft's route, level and times at which the aircraft will reach certain points during the flight. When a sector receives a flightplan, it is understood that the aircraft will enter that sector at the level and on the route described in the flightplan.

Between Radar sectors

There is no requirement to send flight strips between two radar sectors. There is sufficient information available to each controller using the radar that the use of strips is superfluous.

Arrivals (into procedural airspace):

In non-radar units, the ETA of an aircraft at the sector boundary as well as at the destination airport is important information to the controller. By default, these times are not made available on the Euroscope or VRC flight strips. For Euroscope users, this information can be found in other places, such as on the flight data list lines and in Flight Plan Dialog Window for the aircraft. No such time information is available to VRC users.

Receiving controller using EuroScope:

Flight strips are not required to be sent to simulated non-radar units who are using EuroScope because time information is available for flights under radar control. Non-radar units are able to access ETA information prior to the aircraft leaving radar coverage.

Receiving controller using VRC:

A flight strip with the ETAs at the airspace boundary as well as the destination airport are required to be sent to the unit approximately 15 minutes prior to the airspace boundary. Refer Flight Strip Annotation for more information. To obtain the time to a fix in VRC, use the Anchor function. For more information about the Anchor functions, consult the VRC manual.

Receiving controller using EuroScope or VRC:

Once the departing aircraft reports their ETA at the common airspace boundary, a flight strip with the departure time and ETA for the common boundary is to be sent to the radar sector. Refer Flight Strip Annotation for more information.

Between Simulated Non-Radar and Simulated Non-Radar sectors:

Arrivals - Receiving controller using EuroScope or VRC:

A flight strip with ETAs at the airspace boundary as well as the destination airport are required to be sent to the unit approximately 15 minutes prior to the airspace boundary. Refer Flight Strip Annotation for more information.

Departures - Receiving controller using EuroScope or VRC:

Between Radar Sectors and Auckland Oceanic

As soon as a stable ETA is known for the FIR boundary fix, for an aircraft entering the Auckland Oceanic FIR, the adjacent area sector should send a flight strip detailing the ETA to the OCA controller. Approximately two minutes from the FIR boundary, the Area controller should conduct a radar handoff of the aircraft to Auckland Oceanic.

Because VATSIM radar clients do not model flight trajectories of aircraft climbing or descending and there is no requirement for pilots to file an accurate ETD or ETA for crossing a FIR boundary, it can be difficult to estimate a flights ETA at the boundary. The easiest way to establish an ETA which will not vary significantly from the time it is passed until the time the aircraft has crossed the boundary, is to wait until the aircraft is in the later parts of the climb or in the cruise.

Between Auckland Oceanic and Radar Sectors

Approximately 15 minutes prior to the FIR boundary, Auckland Oceanic should send a flight strip detailing the ETA for the boundary fix, to the Area controller. Approximately two minutes from the FIR boundary, the Oceanic controller should conduct a radar handoff of the aircraft to the Area controller.