### The Twentieth Meeting of the Informal South Pacific ATS Coordinating Group![](media/image1.jpeg){width="1.3291666666666666in" height="0.7368055555555556in"}

**(ISPACG/20)**

Honolulu, USA, 30 January -- 1 February 2006

Agenda Item 5: Identify future work programmes

###### 

###### ATS Interfacility Data Communications Version 2.0

(Presented by the Airservices Australia)

+-----------------------------------------------------------------------+
| # SUMMARY                                                             |
|                                                                       |
| This Working Paper presents information concerning AIDC ICD V2.0      |
+-----------------------------------------------------------------------+

1\. **INTRODUCTION**

1.1 ATS Interfacility Data Communications provides an automated means
for ATSUs to conduct electronic coordination with adjoining ATSUs. This
improves the overall safety of the ATM system, as well as increasing
airspace capacity, as it permits the controller to simultaneously carry
out other tasks.

1.2 Automated ATS systems in use in the South Pacific were originally
built according to the specifications of the Asia Pacific AIDC Interface
Control Document (ICD) Version 1.0. This version did not facilitate the
coordination of certain clearance types, such as block levels or off
track clearances.

1.3 AIDC ICD Version 2.0 was issued as the current version of AIDC,
dated 28 March 2003. This version included a message format for the
coordination of block levels, weather deviations as well as Mach Number
Technique. To ensure backwards capability, the use of these message
formats was defined to be permitted only following bilateral agreement.

1.4 In addition to these new message formats, two new AIDC messages were
also proposed:- the "FAN" & "FCN" messages. The purpose of these new
messages was to facilitate data link transfers between ATSUs. The
original concept was that the FAN message would be used in lieu of the
current Address forwarding process to improve both the speed and
reliability of data link transfers. The FCN message was proposed to
provide advice to the transferring unit that the receiving unit had
established a CPDLC connection.

1.5 The final format of the FAN message was not determined at the time
of issue of AIDC ICD Version 2, and it is desirable to amend the format
of the FCN message to provide increased versatility.

1.6 The purpose of this working paper is twofold:

-   To provide continuing awareness to the Pacific & South Pacific ANSPs
    of the existence of the AIDC ICD V2.0 protocols, and to encourage
    planning for their implementation; and

-   To promote discussion concerning the FAN and FCN messages in order
    to finalise the format of these messages. The current AIDC ICD V2.0
    description of the FAN and FCN message is included in Attachment A
    to this Working paper.

**2. Proposed purpose of the FAN and FCN messages**

2.1 To utilise ground-based messaging to facilitate data link transfers
between ATSUs, it is envisaged that the following functionality would be
required:

+----------------------+-----------------------+-----------------------+
| **Transferring unit  | **Receiving unit to   | **Unit x to unit y**  |
| to receiving unit**  | Transferring unit**   |                       |
+----------------------+-----------------------+-----------------------+
| -   Transfer an acft | -   Provide advice    | -   Transfer an acft  |
|     logon details;   |     that a CPDLC      |     logon details for |
|                      |     connection has    |     information (i.e. |
| -   Provide advice   |     been established  |     ADS-C only)       |
|     that the CPDLC   |                       |                       |
|     Connection with  |                       |                       |
|     an aircraft has  |                       |                       |
|     been terminated  |                       |                       |
+----------------------+-----------------------+-----------------------+

2.2 This functionality would result in:

-   A higher success rate with data link transfers between units;

-   The ability for a unit to receive a logon that was transmitted to
    them "for information only" without sending an automatic CPDLC
    Connection Request (which would subsequently fail);

-   Increased confidence for the transferring unit that the receiving
    unit has established a CPDLC connection with an aircraft;

-   Increased confidence for the receiving unit that the transferring
    unit has terminated their CPDLC connection with an aircraft. This
    could remove the requirement for a CPDLC position report for
    aircraft crossing FIR boundaries.

> *Many of these benefits facilitate the application of 30/30NM
> separation standards across FIR boundaries.*

2.3 To facilitate this functionality, the following amendments would be
required:

-   Finalise the definition and format of the FAN message;

-   Update the FAN message examples in accordance with the agreed
    format;

-   Finalise the definition and format of the FCN message;

-   Update the FCN message examples in accordance with the agreed
    format.

**3. Additional updates to the AIDC ICD**

3.1 Whilst reviewing the FAN and FCN messages, there are also a number
of other updates to the AIDC ICD which could be considered; including:

-   Addition of new error codes in Table B-1

-   Addition of the ability to coordinate changes to Field 10 (e.g. via
    CDN)

-   Formalise procedures for the coordination of a change to destination
    (which may result in changes to the CDN definition).

**4. Recommendation**

4.1 This working paper recommends that:

> \(i\) ISPACG members consider the need for the AIDC FAN and FCN
> messages, and determine what amendments would be required to the
> definition and format of these messages;
>
> \(ii\) Representation be made to ICAO Bangkok to reconvene the AIDC
> Task Force for the purpose of:

-   Finalising the format of the FAN and FCN messages in the AIDC ICD,
    and

-   Updating the AIDC ICD in accordance with these and any other changes
    required.

**Current definition of FAN and FCN from AIDC ICD V2.0**

**2.5.4 FAN (FANS APPLICATION MESSAGE)**

2.5.4.1 *Purpose*

Transmitted by the controlling ATSU to provide the receiving ATSU with
the required Context Management information necessary to establish CPDLC
and/or ADS connections.

A free text field is used in this message to transfer the CPDLC and ADS
application version numbers which are separated by a "/". If a
transferring ATSU wishes to transmit a FAN message to permit a
downstream ATSU to establish ADS contracts, the CPDLC application
version number shall be transmitted as a zero.

2.  *Message Format*

ATS fields Description

3 Message type

7 Aircraft identification

13 Departure aerodrome

16 Destination aerodrome

Text Application and address data (to be determined but will include
ICAO 24 bit code)

[]{.mark}

2.5.4.3 *Example*

(FAN-QFA43-YSSY-NZAA-Application and address data)

ATSUs should ensure that at least two of the ACID, REG, or CODE fields
are used to ensure that the Context Management information is associated
with the correct flight data record.

**2.5.5 FCN (FANS COMPLETION NOTIFICATION)**

2.5.5.1 *Purpose*

Transmitted by the receiving ATSU to the transferring ATSU as an
operational response to a FAN message. The free text "Connection Flag
field" is set to zero if the receiving ATSU was unable to establish a
CPDLC connection with the aircraft, otherwise it is set to one. It is
used to provide assurance to the transferring unit that a successful
CPDLC transfer should occur.

2.5.5.2 *Message Format*

ATS fields Description

3 Message type

7 Aircraft identification

Text Free text

2.5.5.3 *Example*

(FCN-QFA43-RMK/0)

(FCN-ANZ15-RMK/1)