Detailed working notes on ATS Inter-facility Data Communications (AIDC): the automated, computer-to-computer exchange of operational ATC data between adjacent ATS units. This folder expands the summary in topics/aidc.md into per-aspect files so each can be read on its own.

Files in this folder#

• overview.md — what AIDC is, where it sits in the ICAO ICC application set, and why it matters operationally.
• components.md — the AIDC message set (Notify, Coordinate group, Transfer group, General, Free Text, Application management) and the exchange model.
• blocks.md — version / regional-edition lineage of AIDC (APAC ICD versions, OLDI editions, ED-133 transition).
• threads.md — functional areas of AIDC: notification, coordination, transfer of control, transfer of communications, dialog management.
• modules.md — anatomy of a single AIDC dialog: objective, procedure, technology, enablers, KPIs.
• enablers.md — supporting CNS/IT (AFTN, AMHS, ATN/OSI, ATN/IPS), LoA negotiation, training, regulation, certification.
• performance_objectives.md — KPAs (interoperability, predictability, safety) and KPIs for AIDC operations.
• timeline.md — AIDC ICD version history and PANS-ATM Appendix 6 evolution.
• references.md — consolidated ICAO and external references for everything in this folder.

Reading order#

Start with overview.md, then components.md, then threads.md and blocks.md, then drill into modules.md, enablers.md, and performance_objectives.md. Use timeline.md for date context and references.md for citations.

Source basis#

Content is grounded in:

• ICAO Doc 4444 (PANS-ATM), Chapter 10 (coordination), Chapter 11 (data link procedures, §11.2.2.2, §11.3.7, §11.4.2.5), and Appendix 6 (AIDC message types and content, Table A6-1).
• ICAO Annex 11 (Air Traffic Services), Chapter 3 (coordination between adjacent ATS authorities).
• ICAO Annex 10 Vol II (Communication Procedures, message priority) and Vol III Part I (Communication Systems, ICC application context).
• ICAO Doc 9694 (Manual of ATS Data Link Applications).
• ICAO Doc 9705 (Manual of Technical Provisions for the ATN; ASN.1 packed encoding rules).
• ICAO Doc 9804 (Manual on ATN Ground-Ground Applications).
• ICAO Doc 9896 (ATN using IPS Standards and Protocols).
• ICAO APAC AIDC ICD (ICAO Asia/Pacific Regional Office).
• EUROCONTROL Specification for On-Line Data Interchange (OLDI).
• EUROCAE ED-133 (Flight Object Interoperability Specification).

What AIDC is#

AIDC stands for ATS Inter-facility Data Communications. It is the automated, computer-to-computer exchange of operational air traffic control data between adjacent ATS units (area control centres, approach units, and towers). AIDC supports the four cross-boundary ATC functions that have historically been handled by direct controller- to-controller voice:

1. Notification that a flight is approaching the common boundary, including its boundary estimate.
2. Coordination of the conditions under which the flight will cross the boundary (level, point, time, speed restriction, route).
3. Transfer of control from the transferring unit to the accepting unit at the agreed point.
4. Transfer of communications of the pilot from the transferring unit's frequency to the accepting unit's frequency.

The intent is to remove repetitive voice coordination, reduce frequency loading on the controller-to-controller hot lines, and let the ATC systems on each side of an FIR boundary maintain a synchronised view of the flight without manual re-keying.

Where AIDC sits in the ICAO concept#

AIDC is the first ICAO ICC (inter-centre communications) application defined under Annex 10 Volume III, Part I. The ICC application set is the ground-ground counterpart of the air-ground data link applications (CPDLC, ADS-C). AIDC inherits its operational requirements from Annex 11 (mandatory coordination between adjacent ATS authorities, met by direct speech or AIDC) and its message set, encoding, and procedures from Doc 4444 (PANS-ATM) Chapters 10 and 11 and Appendix 6.

Key normative anchors:

• Annex 11, Chapter 3 — coordination between adjacent ATS authorities; AIDC is one accepted means.
• Annex 10, Vol II, Chapter 4 — message priority ("normal-priority flight safety messages").
• Annex 10, Vol III, Part I — definition of AIDC and its place in the ICC application set.
• Doc 4444, §10.1 — required content of letters of agreement (LoA), transfer points, levels, conditions.
• Doc 4444, §11.2.2.2 — use of AIDC App. 6 messages; ATN ASN.1 PER; AFTN fallback by regional agreement.
• Doc 4444, §11.4.2.5 — AIDC message list and procedures.
• Doc 4444, Appendix 6 — message types, fields, and content (Table A6-1).

What planners and operators use AIDC for#

For an ANSP, an AIDC bilateral with a neighbour answers four questions:

1. Which flights are coordinated automatically (typically all IFR crossing a defined boundary, with documented exceptions)?
2. Which boundary conditions are pre-agreed (standing levels, points, speed and route restrictions in the LoA) versus negotiated per flight?
3. Which transport bearer is used (ATN/OSI, ATN/IPS, AMHS, or AFTN) and with which timers and error semantics?
4. What fallback applies if AIDC is unavailable (degraded mode to voice; OPS Notice; LoA-defined contingency)?

AIDC does not replace the LoA — it operationalises it. Standing coordination (e.g. all flights cross at FL350 inbound) lives in the LoA; AIDC carries the per-flight data and exception-based negotiation.

Why "Inter-facility"#

The word "inter-facility" emphasises three things:

• Adjacent — AIDC is a bilateral exchange between two named ATS units, not a broadcast or a network publication.
• Operational — AIDC carries ATC data used to control specific flights, not strategic or planning information.
• Synchronised — both sides maintain a coherent view of the flight through the dialog state machine; an unacknowledged or rejected message degrades the controller's display.

Relationship to other initiatives in this repo#

AIDC is a foundational ground-ground data link capability that other topics in this workspace build on or replace:

• AFTN / AMHS / ATN — transport substrate for AIDC.
• FF-ICE and SWIM — the longer-term replacement: shared flight-object publication instead of point-to-point coordination.
• OLDI — the European regional cousin of AIDC, functionally equivalent with a different encoding and message naming.
• PBN, CPDLC, ADS-C — air-ground complements of AIDC; ADS-C contracts on either side feed the same boundary-estimate problem AIDC coordinates on the ground.
• APAC Seamless ATM Plan — AIDC implementation is a named deliverable in the APAC regional plan.

AIDC is a structured set of messages, exchanged in defined sequences, over an agreed transport bearer, between two ATS units bound by a letter of agreement. The components are:

1. Messages (Doc 4444, Appendix 6 / §11.4.2.5)#

The AIDC message set is grouped by function. Names below follow the ICAO Doc 4444 Appendix 6 nomenclature. (The OLDI cousins are noted in parentheses where the function is equivalent — full mapping in blocks.md.)

Notification group#

• Notify (NTF) — advance flight information sent at an LoA-defined time or distance before the common boundary; carries the boundary estimate (point, time, level). Multiple Notify messages may precede coordination as the estimate evolves. (OLDI: ABI — Advance Boundary Information.)

Coordination group#

• Coordinate Initial (CDN-I) — proposal of boundary/transfer conditions; closes notification, opens coordination. (OLDI: ACT — Activate.)
• Coordinate Negotiate — counter-proposal in response to a Coordinate Initial that the receiver cannot accept as-is. (OLDI: CDN — Change.)
• Coordinate Accept — acceptance of a Coordinate Initial or Coordinate Negotiate, completing the coordination dialog. (OLDI: ACP — Accept.)
• Coordinate Reject — refusal of the proposed conditions. (OLDI: RJC — Reject.)
• Coordinate Cancel — abrogates a prior Notify or coordination when the flight will no longer enter the receiving unit. (OLDI: MAC — Message for Abrogation of Coordination.)
• Coordinate Update — amendment within the LoA, auto-processed without controller intervention. (OLDI: REV — Revision.)
• Coordinate Standby — receipt acknowledgement; response will follow when controller has processed.

Transfer group#

• Transfer Initiate — starts the transfer phase; carries executive and track data.
• Transfer Conditions Proposal — used for early/manual transfer or transfer outside LoA-standing conditions.
• Transfer Conditions Accept — accepts non-standard transfer conditions.
• Transfer Communication Request — receiver asks for the handoff to begin.
• Transfer Communication — instruction to pilot to contact the next unit. (OLDI: TIM — Transfer Initiation.)
• Transfer Communication Assume — receiver confirms communications established.
• Transfer Control — proposal to transfer control authority.
• Transfer Control Assume — receiver confirms control assumed.

General group#

• General Point — highlight a specific flight to the other unit's controller; supports voice coordination.
• General Executive Data — update level, speed, heading, frequency for an already-coordinated flight without re-opening coordination.

Free text group#

• Free Text Emergency — emergency information that does not fit another message type.
• Free Text General — plain-language operational information.

Application management group#

• Application Accept (LAM analogue) — auto-generated by the receiver to confirm the AIDC message was parsed and is displayable. Maintains dialog integrity (Doc 4444 §11.3.7.7). (OLDI: LAM — Logical Acknowledgement.)
• Application Reject — auto-generated when an error is detected; carries a reason code. The dialog reverts to the prior state.

2. Dialog model#

The coordination dialog is a state machine. Doc 4444 §11.3.7.5 defines completion: a Coordinate Initial (or counter-proposal via Coordinate Negotiate) is accepted by Coordinate Accept. Until Coordinate Accept arrives, both controllers see the flight as "in coordination". After Coordinate Cancel, the flight is removed from the receiving unit's queue.

3. Boundary-estimate timing#

LoAs set the AIDC timing parameters per boundary:

• Notify trigger — typically 20–30 minutes before boundary.
• Coordinate Initial — typically not later than 20 minutes before the transfer-of-control point.
• Application Accept timeout — a parameter time after which, absent an Application Accept, the controller is alerted and voice coordination is invoked (Doc 4444 §11.4.2.5.23.2).

4. Transport bearer#

AIDC application messages are encoded and carried over one of:

• ATN/OSI — ground-ground using ASN.1 packed encoding rules (Doc 4444 §11.2.2.2.1; Doc 9705).
• ATN/IPS — ground IP migration (Doc 9896), in support of SWIM.
• AMHS — X.400-based store-and-forward, replacing AFTN, used as an AIDC bearer in several regions.
• AFTN — permitted where ATN/AMHS unavailable; format per Doc 4444 Appendix 3 with gaps filled by regional agreement (§11.2.2.2.2). Many APAC States still run AIDC over AFTN.

In all cases, AIDC messages carry normal-priority flight safety message priority on the underlying network (Annex 10 Vol II, Ch. 4).

5. Letters of agreement (LoA)#

The LoA between the two ATS units is the human-readable contract underneath every AIDC bilateral:

• Identifies the two facilities and the boundary.
• Defines standing transfer conditions (point, level, route).
• Lists which message types are exchanged and which are not.
• Sets timers and error-handling expectations.
• Defines fallback procedures when AIDC is degraded.

6. Identifiers and addressing#

• Facility designators — eight-character ICAO addresses on AFTN, ATN PSAP addresses on OSI, or IP/URI on IPS.
• Flight identification — aircraft callsign plus departure aerodrome and EOBT (or a system-assigned flight identifier) used to correlate messages on both sides.
• Message reference — a sequence number per dialog so that retransmissions and acknowledgements correlate.

7. Error handling#

• Malformed message → Application Reject with reason code.
• Dialog desync (e.g. Coordinate Accept for an unknown flight) → Application Reject; controller alerted.
• Missed Application Accept within timer → controller alerted; voice coordination resumes.

AIDC has no Block 0–3 timeline. Instead it has a version lineage: the ICAO global profile in Doc 4444 Appendix 6 and the regional Interface Control Documents (ICDs) that profile it. This file is the AIDC analogue of the asbu blocks.md: the "delivery slots" of AIDC are the successive ICD editions that bilateral pairs of ANSPs upgrade to.

What an AIDC ICD is#

An Interface Control Document (ICD) is a regional agreement that profiles the global Doc 4444 Appendix 6 message set into a deployable bilateral interface. The ICD pins down:

• which message types are exchanged;
• the on-the-wire encoding and field formats;
• timers, retry counts, and error-code semantics;
• bilateral options that the LoA between two specific units selects.

Without an ICD profile, two implementations of Appendix 6 will not interoperate, because Appendix 6 leaves implementation choices open.

ICAO global profile lineage#

Regional ICD editions#

Asia/Pacific — ICAO APAC AIDC ICD#

Maintained by the ICAO Asia/Pacific Regional Office; the de-facto standard for cross-FIR AIDC across the region (HK, SG, JP, AU, TH, MY, ID, PH, KR, IN, and others).

ICD v3 is the working baseline for new APAC bilateral implementations. States with legacy v1/v2 deployments migrate to v3 as part of regional APANPIRG-monitored work programmes.

Europe — OLDI / ED-133#

Europe runs a parallel profile called OLDI (On-Line Data Interchange), defined by EUROCONTROL Specification and EUROCAE ED-133. Functionally analogous to AIDC but with different message naming and encoding.

Mapping to AIDC names:

• ABI ↔ Notify
• ACT ↔ Coordinate Initial
• REV ↔ Coordinate Update
• CDN ↔ Coordinate Negotiate
• ACP ↔ Coordinate Accept
• RJC ↔ Coordinate Reject
• MAC ↔ Coordinate Cancel
• LAM ↔ Application Accept
• TIM ↔ Transfer Communication

Americas — NAM/CAR ICDs#

FAA, NAV CANADA, and Mexico's SENEAM run AIDC variants on NAM/CAR ICDs. Historical implementations include ICAO ICD-derived profiles between US ARTCCs and Canadian ACCs, and US-Mexico bilateral ICDs. Modern implementations align with ICAO Appendix 6 and the APAC ICD where relevant.

Africa, MID, SAM#

Adoption tracks the regional implementation plans (ICAO MID Air Navigation Strategy, AFI Plan, SAM Plan). ICDs typically profile APAC ICD v3 or OLDI as a base, with bilateral tailoring.

Bearer-edition lineage#

Independent of the ICD edition, the underlying transport bearer follows its own versioning:

ICD dependency principle#

A bilateral upgrade to a newer ICD edition typically depends on bearer upgrades being in place. For example:

• Moving from APAC ICD v2 to v3 with full Appendix 6 coverage usually requires AMHS or ATN bearer to handle the larger and more frequent messages reliably.
• ED-133 Flight Object adoption requires SWIM infrastructure on both sides — it is no longer an ICD-style point-to-point upgrade.

Pakistan / APAC application#

A typical national AIDC implementation roadmap for an APAC ANSP runs as follows:

1. Implement the APAC ICD v3 message subset over AFTN with adjacent FIRs as a baseline (Notify, Coordinate Initial, Coordinate Accept, Application Accept).
2. Migrate the bearer to AMHS, then ATN, as regional capability matures.
3. Extend message coverage to the full Appendix 6 set, including General Executive Data and Transfer-group messages.
4. Plan FF-ICE / ED-133-style flight-object publication as a longer-term replacement for point-to-point AIDC.

A functional area in AIDC is a coherent slice of the boundary- crossing problem that one or more messages address. AIDC is organised around five functional areas, mapping to the dialog phases described in Doc 4444 §10.1 and §11.4.2.5.

1. Notification#

Purpose. Tell the receiving unit that a flight is approaching the common boundary, before any negotiation of conditions begins. The notification carries the boundary estimate (point, time, level) so that the receiving controller's display and ground system can plan capacity.

Messages.

• Notify (NTF) / OLDI ABI.
• May be repeated as the boundary estimate refines (e.g. trajectory updates from ADS-C contracts on the transferring side).

Operational use.

• Triggered at an LoA-defined time-to-boundary or distance-to-boundary, typically 20–30 minutes before the common boundary.
• The receiving unit's flight data processing system creates or updates a flight record from the Notify content.
• Notify carries no commitment from the receiver; it is informational.

Failure mode. If Notify is not received, the receiving unit may have no advance flight record and must rely on voice or AFTN flight- plan messages. AIDC degrades to voice coordination.

2. Coordination#

Purpose. Agree the conditions under which the flight will cross the boundary: the transfer point, transfer level, transfer time, and any speed, route, or vertical restrictions.

Messages.

• Coordinate Initial (proposal).
• Coordinate Negotiate (counter-proposal).
• Coordinate Accept (agreement closes the dialog).
• Coordinate Reject (refusal of proposed conditions).
• Coordinate Update (in-LoA amendment, auto-processed).
• Coordinate Cancel (abrogation when the flight will not enter).
• Coordinate Standby (receipt acknowledgement, response pending).

Operational use.

• Standing conditions in the LoA do not require negotiation; they are baselined and only departures from them require coordination.
• Coordinate Initial typically issued not later than 20 minutes before the transfer-of-control point.
• Coordinate Update auto-processed within the LoA (e.g. minor level change) keeps the receiver's record current without controller intervention.

Failure mode. Application Reject from the receiver returns the dialog to its prior state; controller is alerted; voice coordination is invoked.

3. Transfer of control#

Purpose. Hand control authority for the flight from the transferring unit to the accepting unit at the agreed transfer-of- control point.

Messages.

• Transfer Initiate (start transfer phase, executive/track data).
• Transfer Conditions Proposal / Accept (early or non-standard transfer outside LoA-standing conditions).
• Transfer Control (proposal to transfer control authority).
• Transfer Control Assume (control assumed).

Operational use.

• Transfer-of-control point is normally a published or LoA-defined fix on or near the boundary.
• In an ATS surveillance environment, transfer of control is conducted via direct controller-to-controller communications by two-way speech or AIDC (Doc 4444 §13.4.3.2).

Failure mode. Transfer-of-control fallback is voice; responsibility remains with the transferring unit until the accepting unit accepts.

4. Transfer of communications#

Purpose. Move the pilot's communications from the transferring unit's frequency to the accepting unit's frequency.

Messages.

• Transfer Communication Request (receiver asks for handoff).
• Transfer Communication (instruction to pilot to contact next unit; OLDI TIM).
• Transfer Communication Assume (comms established).

Operational use.

• Normally aligned with transfer of control but can be earlier or later by LoA.
• The transferring controller issues the frequency change to the pilot; the accepting controller receives the pilot's first call and sends Transfer Communication Assume so the transferring unit can release the flight from its display.

Failure mode. Standard voice fallback; LoA-defined hot-line between the two units is used to confirm comms established.

5. Dialog management and supporting exchange#

Purpose. Maintain dialog integrity, allow free-text exchange, and keep both displays synchronised when AIDC alone does not capture the operational picture.

Messages.

• Application Accept / OLDI LAM (auto acknowledgement).
• Application Reject (error detected, with reason code).
• General Point (highlight a specific flight to support voice coordination).
• General Executive Data (level, speed, heading, frequency update for an already-coordinated flight).
• Free Text Emergency / General.

Operational use.

• Application Accept is auto-generated by the receiving system to maintain dialog integrity (Doc 4444 §11.3.7.7).
• General Point complements voice — the controller phones the neighbour and uses General Point to ensure they are looking at the same flight.
• Free Text Emergency carries information that does not fit any structured field (e.g. radio failure, hijack, medical diversion).

Failure mode. No Application Accept within the LoA-defined timer triggers a controller alert and voice fallback (Doc 4444 §11.4.2.5.23.2).

Cross-area dependencies#

• Coordination depends on Notification — the receiver must have a flight record before Coordinate Initial arrives.
• Transfer of control and Transfer of communications presuppose successful Coordination.
• Dialog management wraps every area; without Application Accept semantics, no other area can be trusted.

This is why AIDC is implemented as a coherent application rather than as independent message streams: a partial implementation that supports Coordination but not Application Accept is operationally useless.

What an AIDC dialog is#

An AIDC dialog is a single, identifiable, end-to-end exchange of messages between two ATS units about one flight crossing one boundary. It is the smallest unit of AIDC operations — funded, certified, trained for, and monitored as a coherent capability per bilateral.

Dialog identifier convention (informal):

<TRANSFERRING_UNIT>-<ACCEPTING_UNIT>/<flight_id>/<sequence>

Examples:
  OPLA-VABF/PIA309/0001
  YBBB-WSJC/SIA221/0014

A dialog is deliverable — the bilateral pair plans, funds, certifies, trains for, and operates AIDC for a given message subset, on a given bearer, under a given ICD edition.

Anatomy of a dialog#

Each AIDC dialog carries the following structured content.

1. Boundary identifier#

The named common boundary (e.g. "KARACHI FIR / MUMBAI FIR boundary at SOSUS"). The LoA names the boundary explicitly.

2. Operational improvement statement#

What changes operationally for the controllers on each side. For a typical bilateral: replacement of a voice estimate exchange with an automated Notify-Coordinate-Accept sequence; the receiving controller sees the inbound flight on the strip/display 20 minutes before boundary with full conditions.

3. Performance objective and applicable KPAs#

The "why". Each AIDC bilateral is justified against KPAs of: predictability (synchronised display), safety (reduced read- back error), cost-effectiveness (controller workload reduction), interoperability (common message set across multiple boundaries), capacity (faster coordination cycle enables tighter sectoring).

4. Procedure element#

The procedural changes required:

• LoA between the two units (transfer point, level, conditions).
• Local ATC procedures embedding AIDC into the controller workflow.
• Contingency procedures when AIDC is degraded.
• Consistency with PANS-ATM (Doc 4444) §10.1, §11.2.2.2, §11.3.7, §11.4.2.5, and Appendix 6.

5. Technology element#

The systems that must be deployed:

• AIDC application on each FDPS (flight data processing system).
• Bearer connection (AFTN, AMHS, ATN/OSI, ATN/IPS).
• ICD encoder/decoder per chosen edition (APAC ICD v3 / OLDI / NAM).
• Controller HMI integration (alerting, fallback indication).
• Recording for incident investigation (Annex 13 implications).

6. Human performance element#

• Controller training on AIDC HMI (acceptance, rejection, Application Reject reasoning).
• Familiarity with fallback to voice when AIDC is degraded.
• Crew Resource Management between transferring and accepting controllers.

7. Standards basis#

The SARPs, PANS, and manuals the AIDC bilateral relies on:

• Annex 10 Vol II (priority), Vol III (ICC application set).
• Annex 11 (coordination duty).
• Doc 4444 §10.1, §11.2.2.2, §11.3.7, §11.4.2.5, Appendix 6.
• Doc 9694 (Manual of ATS Data Link Applications) for field semantics.
• Doc 9705 (ATN/OSI ASN.1 PER) or Doc 9896 (ATN/IPS) for bearer.
• Doc 9804 (ATN ground-ground applications) for operational requirements correlation to Annex 11 §6.2.

8. Enablers#

The infrastructure, regulation, and institutional prerequisites that must be in place. See enablers.md. At minimum: bearer connectivity, LoA signed, ICD agreed, controllers trained, contingency procedures tested.

9. Dependencies#

Other capabilities that must be in place first:

• Bearer (AFTN/AMHS/ATN) operational on both sides.
• LoA covering the boundary.
• Common ICD edition.
• Synchronised flight identification rules (callsign, EOBT keys).

10. KPI linkage#

Quantitative indicators on which the AIDC bilateral's effect is measured (see performance_objectives.md):

• Application Accept rate (parsed-and-displayed messages over total sent).
• Coordination cycle time (Coordinate Initial to Coordinate Accept).
• Voice fallback rate per 100 flights.
• Boundary-estimate accuracy (predicted vs. actual boundary crossing time/level).

11. Region applicability#

Most AIDC bilaterals are within one region's plan (APAC ICD, NAM, EUR OLDI). Cross-region bilaterals (e.g. APAC-MID) require additional profiling and bilateral testing.

12. Implementation guidance / supporting material#

• ICAO APAC AIDC ICD v3 reference document.
• EUROCONTROL OLDI Specification.
• EUROCAE ED-133 (Flight Object Interoperability) for SWIM-era evolution.
• Regional planning fora records (APANPIRG, MIDANPIRG, EANPG).

Worked examples#

Example 1 — APAC bilateral, AFTN bearer, ICD v2 subset#

• Operational improvement. Replace voice exchange of estimates with Notify + Coordinate Initial + Coordinate Accept on AFTN.
• KPAs. Predictability, controller workload.
• Procedure. LoA names boundary, transfer level, transfer point; AIDC supplements rather than replaces the hot-line.
• Technology. AFTN bearer; ICD v2 subset (Notify, Coordinate Initial, Coordinate Accept, Application Accept only).
• Enablers. AFTN circuits, LoA, controller training, voice fallback.
• Dependencies. Reliable AFTN with predictable latency.
• KPIs. Application Accept rate >98%; voice fallback <5% of flights.

Example 2 — APAC bilateral, AMHS bearer, ICD v3 full#

• Operational improvement. Full Appendix 6 coverage including Coordinate Update auto-processing and Transfer-group messages.
• KPAs. Capacity, predictability, interoperability.
• Procedure. Auto-coordination within LoA-defined parameters; controller intervention only for exceptions.
• Technology. AMHS bearer; APAC ICD v3 encoder/decoder; HMI with per-message alerting.
• Enablers. AMHS infrastructure, ICD v3 conformance testing, refreshed LoA, retrained controllers.
• Dependencies. ICD v2 baseline already in operation; AMHS rollout.
• KPIs. Auto-processed Coordinate Update share; cycle time; Application Reject rate.

Example 3 — Cross-FIR AIDC over ATN/IPS towards FF-ICE#

• Operational improvement. AIDC over IP backbone; trajectory- rich messages supporting later FF-ICE alignment.
• KPAs. Interoperability, flight efficiency, environment.
• Procedure. AIDC dialog still per Doc 4444 App. 6 but bearer is ATN/IPS per Doc 9896.
• Technology. ATN/IPS routers, IP-aware FDPS, IPv6 transit.
• Enablers. Cyber security framework for SWIM-adjacent traffic; service-level agreements; identity and access management.
• Dependencies. SWIM-TI infrastructure on both sides.
• KPIs. Latency budget; security event rate; transition rate of bilaterals from AFTN to IPS.

How dialogs become a national plan#

A national AIDC implementation plan is produced by:

1. Listing every adjacent FIR boundary and every ATS unit pair that coordinates across it.
2. Selecting the ICD edition and message subset for each bilateral.
3. Sequencing bilaterals per the dependency graph (bearer first, then ICD edition, then message coverage expansion).
4. Mapping each bilateral to the responsible organisation, funding, regulatory action, and milestone date.
5. Reporting status into the regional planning forum (APANPIRG, MIDANPIRG, EANPG) and into the State's air navigation plan.

What an Enabler is#

An Enabler is a supporting element without which an AIDC bilateral cannot deliver its intended benefit. Enablers are not themselves the operational capability; they are prerequisites. AIDC fails — silently or noisily — if any enabler is missing.

Enablers fall into seven categories.

1. CNS / IT bearer infrastructure#

The transport layer for AIDC application messages.

• AFTN. Character-oriented store-and-forward; legacy but still the bearer for many APAC AIDC bilaterals. Format per Doc 4444 Appendix 3 with regional gap-fill (§11.2.2.2.2).
• AMHS. X.400-derived ATS message handling system; the active replacement for AFTN. Carries AIDC payloads with richer addressing and quality-of-service.
• ATN/OSI. Doc 9705 SARPs; ASN.1 packed encoding rules; native ground-ground bearer for AIDC App. 6 messages with priority "normal-priority flight safety messages" (Annex 10 Vol II).
• ATN/IPS. Doc 9896 IP-based migration; SWIM-friendly; increasingly the target bearer.
• Voice hot-lines. Always required as fallback when AIDC is degraded; typically direct speech circuits per Annex 11 / Doc 4444.

Without bearer reliability and known latency, AIDC dialogs time out and drop into voice — defeating the purpose of the investment.

2. Procedures#

Procedural changes anchored in ICAO PANS and regional supplementary procedures.

• Doc 4444 — PANS-ATM, Chapter 10. Coordination duty, LoA content (transfer points, levels, conditions).
• Doc 4444 — PANS-ATM, Chapter 11. Use of AIDC App. 6 messages, ATN/AFTN transport rules, dialog integrity (Application Accept).
• Doc 4444 — Appendix 6. Message types, fields, coordination environments (surveillance vs procedural), Table A6-1.
• Doc 7030 — Regional Supplementary Procedures. Region-specific AIDC tailoring (APAC, MID, EUR, NAM, CAR, SAM, AFI).
• Local ATC procedures. Embedding AIDC into the controller's workflow; alerting, fallback, exception handling.
• Letters of Agreement (LoA). The bilateral contract — boundary, transfer point/level, message subset, timers, fallback.

3. Standards (SARPs and supporting manuals)#

Annex provisions and ICAO manuals that underpin AIDC:

• Annex 10, Vol II — Communication Procedures. Message priority ("normal-priority flight safety messages"); Chapter 4.
• Annex 10, Vol III, Part I — Communication Systems. Definition of AIDC; ICC application set; AIDC as the first ICC application.
• Annex 11 — Air Traffic Services. Mandatory coordination between adjacent ATS authorities; satisfied by direct speech or AIDC.
• Doc 9694 — Manual of ATS Data Link Applications. Field definitions, ranges, resolutions.
• Doc 9705 — Manual of Technical Provisions for the ATN. ASN.1 packed encoding rules, AIDC addressing.
• Doc 9804 — Manual on ATN Ground-Ground Applications. Operational requirements correlated to Annex 11 §6.2; APAC ICD references.
• Doc 9896 — ATN using IPS Standards and Protocols. IP migration.

4. Avionics and fleet equipage#

AIDC is a ground-ground application; aircraft are not directly involved. However, AIDC is most beneficial when paired with air-ground data link on the same flight:

• CPDLC FANS-1/A or ATN B1/B2. Allows the transferring controller to issue the frequency change by data link; the receiving controller to receive logon by data link; AIDC then synchronises the ground state.
• ADS-C contracts. Trajectory and position reports feed the boundary-estimate quality that AIDC carries in Notify.
• Mode S / ADS-B. Surveillance underpins the surveillance- environment branch of AIDC procedures (Doc 4444 §13.4.3.2).

Without good air-ground equipage, AIDC still works, but the boundary estimate quality is lower (procedural, voice-fed estimates) and the benefit is reduced.

5. Regulatory framework#

• State approval of AIDC operations between named ATS units.
• Safety oversight under Annex 19 (SMS at the State and ANSP levels; State Safety Programme); AIDC fallback procedures must be hazard-assessed.
• Certification of FDPS AIDC application versions; conformance to the chosen ICD edition.
• Spectrum / network policy for the chosen bearer (AFTN, AMHS, ATN/OSI, ATN/IPS).
• Cyber security regulation for IPS-bearing AIDC, especially as it overlaps with SWIM.

6. Human resources and training#

• Controller training on the AIDC HMI: how to interpret Application Reject, when to escalate to voice, how to use General Point and General Executive Data.
• Refresher training on fallback when AIDC is degraded.
• Engineering and maintenance training on FDPS AIDC modules and the chosen bearer.
• Cross-unit familiarisation between controllers on either side of a boundary, ideally including site visits and joint exercises.
• Human-factors design of the AIDC HMI: alerts must be salient but not nuisance; rejected messages must be diagnosable.

7. Institutional and inter-State#

• Letter of Agreement (LoA) between the two ATS units. The single most important enabler; without an up-to-date LoA, AIDC is a technical curiosity.
• ICD adoption at regional level (APAC ICD v3; OLDI in EUR; NAM/CAR ICDs in the Americas).
• Conformance testing between the two implementations before going live; periodic re-testing after software upgrades.
• Bilateral hot-line for technical contact (engineering on both sides) when AIDC degrades.
• Regional planning forum endorsement (APANPIRG, MIDANPIRG, EANPG, GREPECAS) of the bilateral as part of the regional plan.
• Memoranda of Understanding for SWIM service exchange and FF-ICE bilateral readiness when transitioning beyond AIDC.

How enablers are managed in practice#

Each AIDC bilateral has a documented enabler register, typically maintained by the engineering teams on both sides:

• Bearer status (AFTN circuit / AMHS / ATN node) per side.
• ICD edition in use per side.
• LoA version and date.
• Last conformance test date and outcome.
• Open Application Reject reason codes and trend.
• Fallback test date and outcome.

A bilateral is considered fully operational only when all declared enablers are in place — not only the headline message exchange. This is why AIDC adoption is much more than software procurement: a State that ships the AIDC application without negotiating an LoA, training controllers, and testing fallback will not see the predicted benefit and will, in practice, continue to coordinate by voice.

The performance lens of AIDC#

AIDC is a performance-justified capability. Every bilateral is funded to deliver measurable benefits in defined Key Performance Areas (KPAs), and operational health is monitored through Key Performance Indicators (KPIs). The terminology comes from the Global ATM Operational Concept (Doc 9854) and the Manual on Global Performance of the Air Navigation System (Doc 9883).

The chain is:

KPA  --(measured by)-->  KPI  <--(targeted by)--  Performance Objective  --(achieved by)-->  AIDC bilateral

Key Performance Areas most affected by AIDC#

Of the eleven KPAs from Doc 9854 / Doc 9883, AIDC most directly affects:

1. Safety — fewer voice-readback errors on cross-boundary coordination; consistent synchronised display on both sides.
2. Interoperability — common message set, encoding, and dialog rules across multiple boundaries.
3. Predictability — synchronised flight records reduce variance between predicted and actual boundary crossings.
4. Capacity — faster coordination cycles allow tighter sectoring and more flights per controller-hour.
5. Cost-effectiveness — controller workload reduction; voice circuit utilisation reduction.
6. Flight efficiency — accurate boundary conditions allow optimal level and route assignment without buffer levels.
7. Global Interoperability — alignment of regional ICDs to Doc 4444 Appendix 6 supports cross-region coordination.

KPAs less directly affected: environmental impact (indirect, via flight efficiency), security (indirect, via bearer security), flexibility, access and equity, participation.

Performance Objectives#

A Performance Objective (PO) for AIDC is a stated, measurable improvement in one or more KPAs that the AIDC bilateral commits to pursue. Examples (illustrative naming):

• PO — Reduce voice coordination workload. Measured by voice calls per 100 flights at the boundary, before and after AIDC. Delivered by full Notify-Coordinate dialog adoption.
• PO — Improve coordination cycle time. Measured by elapsed time from Coordinate Initial to Coordinate Accept. Delivered by ICD v3 adoption and AMHS bearer.
• PO — Increase boundary-estimate accuracy. Measured by RMS error between predicted and actual boundary crossing time/level. Delivered by ADS-C-fed Notify content.
• PO — Reduce coordination-related incidents. Measured by loss- of-coordination occurrences per 100,000 flights. Delivered by dialog integrity (Application Accept) and synchronised display.
• PO — Improve cross-FIR interoperability. Measured by share of bilaterals on the latest ICD edition. Delivered by regional-plan alignment.

Key Performance Indicators#

Quantitative measures used to evidence progress. AIDC operations typically expose:

Safety KPIs#

• Loss-of-coordination events per 100,000 flights at the boundary.
• Coordination-related incidents per 100,000 flights.
• Application Reject rate by reason code.

Capacity KPIs#

• Coordination cycle time (Coordinate Initial to Coordinate Accept).
• Flights coordinated per controller-hour at the boundary.
• Sustained boundary throughput at peak.

Predictability KPIs#

• RMS error between predicted boundary time (in Notify) and actual boundary crossing.
• RMS error between predicted boundary level and actual.
• Standing deviation of dialog state-machine completion time.

Cost-effectiveness KPIs#

• Voice calls per 100 flights at the boundary.
• Controller intervention rate per AIDC dialog.
• Bearer cost per dialog.

Interoperability KPIs#

• Share of adjacent bilaterals on the latest ICD edition.
• Application Accept rate (parsed-and-displayable messages over total).
• Dialog completion rate (Coordinate Accept reached over Coordinate Initial issued).
• Free-text fall-through rate (Free Text General/Emergency over total messages).

Reliability KPIs#

• Bearer availability (AFTN/AMHS/ATN per side).
• Mean time to recover from AIDC outage.
• Voice fallback rate (% of flights where AIDC degraded to voice).

How performance is reported#

• Globally — through the ICAO regional implementation reports feeding the GANP review cycle.
• Regionally
  • APAC: APANPIRG performance reporting; the APAC Seamless ATM Plan AIDC implementation table.
  • MID: MIDANPIRG and the MID Air Navigation Strategy.
  • EUR: EUROCONTROL Performance Review Body; LSSIP cycle (treats OLDI as the AIDC analogue).
  • NAM/CAR/SAM/AFI: respective regional offices.
• Bilaterally — every AIDC pair typically maintains a quarterly operational review with the neighbouring ANSP, covering KPI trends and Application Reject reason codes.
• Nationally — State Action Plans and ANSP performance plans report AIDC coverage and quality as part of cross-boundary performance.

Why this matters for planning#

Tying every AIDC bilateral to a Performance Objective and a KPI keeps investment honest. The questions a business case must answer:

1. What measurable problem does this AIDC bilateral fix (workload, predictability, safety event rate)?
2. What is the target value of the KPI 12 months after go-live?
3. How will degraded AIDC be detected, and what is the fallback cost?

This discipline is what distinguishes a working AIDC programme from a bilateral that ships software, declares success, and continues to coordinate by voice in practice.

Three timelines to keep distinct#

When discussing AIDC "dates", separate three things:

1. ICAO standards timeline — when ICAO published or amended the AIDC content of Doc 4444 Appendix 6 and the supporting Annexes and manuals.
2. Regional ICD timeline — when the APAC ICD, OLDI, and NAM/CAR ICDs were issued and amended.
3. Bilateral go-live timeline — when two specific ATS units activated AIDC over a defined boundary on a defined bearer.

A State's own AIDC roadmap is a fourth, national timeline; it must be expressed in terms of the regional ICD edition and the bilateral go-live milestones.

ICAO standards timeline#

Key inflection points: 2001 (App. 6 introduced), 2007 (App. 6 stabilised), 2016 (latest major edition baseline).

Regional ICD timeline#

APAC ICD#

European OLDI#

Americas — NAM/CAR#

Bilateral AIDC ICDs (FAA / NAV CANADA / SENEAM) evolved from late- 1990s trials through 2000s production into ICAO-aligned profiles. No single regional document; bilateral ICDs reference Doc 4444 App. 6.

Bearer-evolution timeline#

1990s ----- 2000s ----- 2010s ----- 2020s ----- 2030s
  |          |            |           |           |
  AFTN       AFTN/AMHS    AMHS/ATN    ATN/IPS     SWIM / Flight Object
                          coexistence              (FF-ICE)

These dates are not deadlines for States. They are the dates by which the bearer was mature enough that any State could migrate. Many APAC AIDC bilaterals still operate over AFTN.

Where Pakistan / APAC sit on this timeline#

Indicative regional context (verify against the latest APANPIRG and ICAO APAC implementation reports — these change annually):

• Bilateral AIDC coverage — substantial across major APAC FIR boundaries. Common gaps: smaller boundaries with low traffic density still on voice; some bilaterals on ICD v1/v2 subset only.
• ICD v3 adoption — active migration; targeted by APANPIRG work programmes.
• AMHS migration — well advanced, replacing AFTN as the AIDC bearer.
• ATN/IPS — planning and trials; production use rare in APAC AIDC.
• FF-ICE / Flight Object — horizon planning; not yet replacing AIDC operationally.

Implementation monitoring cadence#

• Global — ICAO publishes ground-ground data link / AIDC implementation status as input to the GANP review cycle.
• APAC — APANPIRG monitors AIDC bilateral status annually as part of the Seamless ATM Plan.
• Europe — LSSIP cycle reports OLDI and ED-133 annually against the European ATM Master Plan.
• National — typically a 3–5 year air navigation plan with AIDC bilateral go-live milestones, reviewed annually.

How to read a date in an AIDC document#

When an AIDC document uses a date, check which kind of date it is:

• "Doc 4444 14th edition (2001)" — ICAO publication date.
• "APAC ICD v3 endorsed by APANPIRG (2018)" — regional ICD date.
• "AIDC go-live with OPLA-VABF on 2024-06-01" — bilateral activation.
• "All APAC bilaterals on ICD v3 by 2030" — regional commitment.

Mixing these up leads to false claims that a State is "behind" or "ahead" of AIDC, when in fact the only meaningful measure is the State's own bilateral go-live plan against the regional ICD baseline.

Primary ICAO documents#

• Doc 4444 — Procedures for Air Navigation Services — Air Traffic Management (PANS-ATM). The operative PANS document for AIDC.
  • Chapter 10, §10.1 — coordination between ATS units; required content of letters of agreement (transfer points, levels, conditions).
  • Chapter 10, §10.1.2 — coordination within contiguous control areas; transfer of flight plan and control information; transfer of control point.
  • Chapter 11, §11.2.2.2 — use of AIDC App. 6 messages supplementing/replacing App. 3 messages; ASN.1 PER over ATN; AFTN fallback by regional agreement.
  • Chapter 11, §11.3.7 — dialog management and Application Accept semantics.
  • Chapter 11, §11.4.2.5 — AIDC message list (Notify; Coordinate Initial / Negotiate / Accept / Reject / Cancel / Update / Standby; Transfer Initiate / Conditions / Communication / Control with Assume variants; General Point / Executive Data; Free Text; Application Accept / Reject).
  • Chapter 13, §13.4.3.2 — transfer of control in an ATS surveillance environment; direct controller-to-controller communications via two-way speech or AIDC.
  • Appendix 6 — ATS Inter-facility Data Communications (AIDC) Messages: message types, data fields, coordination environments (surveillance vs procedural), Table A6-1.
• Annex 10 — Aeronautical Telecommunications.
  • Vol II (Communication Procedures), Chapter 4 — priority of AIDC/AFTN messages; "normal-priority flight safety messages".
  • Vol III, Part I, Chapter 3, §3.1 — definition of ATS Inter- facility Data Communication (AIDC).
  • Vol III, Part I, Chapter 4 — ICC application set; AIDC as the first ICC application supporting FIR-boundary notification, coordination, and transfer of control / communication.
• Annex 11 — Air Traffic Services. Chapter 3, §3.4 — selection of separation minima and coordination between adjacent ATS authorities (met by direct speech or AIDC).
• Doc 9694 — Manual of Air Traffic Services Data Link Applications. Operational use of AIDC; field definitions, ranges, and resolutions.
• Doc 9705 — Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN). ASN.1 packed encoding rules and AIDC addressing.
• Doc 9804 — Manual on the ATN Ground-Ground Applications. Chapter 1 — operational requirements correlated to Annex 11 §6.2; APAC ICD references.
• Doc 9896 — Manual on the ATN using IPS Standards and Protocols. IP-based bearer migration.

ICAO supporting policy documents#

• Doc 9750 — Global Air Navigation Plan (GANP). AIDC implementation is monitored as part of the regional realisations of the GANP.
• Doc 9854 — Global ATM Operational Concept. Source of the eleven KPAs against which AIDC is justified.
• Doc 9883 — Manual on Global Performance of the ANS. Performance management methodology used to set AIDC POs and KPIs.
• Doc 7030 — Regional Supplementary Procedures. Region-specific AIDC tailoring (APAC, MID, EUR, NAM, CAR, SAM, AFI).

Regional implementation references#

• ICAO APAC AIDC ICD — Interface Control Document for ATS Inter- facility Data Communications, ICAO Asia/Pacific Regional Office. Profiles Doc 4444 Appendix 6 with field encodings, timers, error codes, and bilateral options. Version 3 aligns with full Appendix 6 coverage. Authoritative source — not in local library.
• APAC Seamless ATM Plan (ICAO Asia/Pacific Regional Office) — monitors AIDC bilateral implementation across the region; coordinated through APANPIRG.
• EUROCONTROL Specification for On-Line Data Interchange (OLDI) — European regional profile of ground-ground coordination messaging (ABI, ACT, REV, CDN, ACP, RJC, MAC, LAM, TIM). Authoritative source — not in local library.
• EUROCAE ED-133 — Flight Object Interoperability Specification; SWIM-era flight-object publication replacing point-to-point exchange. Authoritative source — not in local library.
• EU Regulation 1032/2006 — coordination and transfer of flight data; superseded by SES Implementing Regulations.
• MID Air Navigation Strategy (ICAO MID Regional Office) — MID realisation including AIDC implementation status.

ICAO Annexes most touched by AIDC#

• Annex 10 Vol II (Communication Procedures), Vol III Part I (Communication Systems).
• Annex 11 (Air Traffic Services).
• Annex 19 (Safety Management) — SMS treatment of AIDC failures and fallback procedures.

Live / authoritative sources#

• ICAO ATM Section — https://www.icao.int/airnavigation/pages/atm.aspx
• ICAO APAC Regional Office — https://www.icao.int/APAC/Pages/default.aspx
• ICAO MID Regional Office — https://www.icao.int/MID/Pages/default.aspx
• EUROCONTROL OLDI Specification page — https://www.eurocontrol.int/publication/eurocontrol-specification-line-data-interchange-oldi
• EUROCAE — https://www.eurocae.net/ (ED-133 Flight Object Interoperability).
• ICAO GANP Portal — https://ganpportal.icao.int/ (regional AIDC implementation monitoring as part of broader CNS/ATM tracking).

Industry training / supporting material#

• IATA / ICAO regional workshops on AIDC, AMHS, and ATN ground-ground applications run periodically out of the APAC and MID Regional Offices; attendance status feeds APANPIRG / MIDANPIRG reports.

Local library coverage (this workspace)#

The ICAO Markdown library carries AIDC content principally in:

• PANS — Doc 4444 (PANS-ATM) consolidated text — Chapters 10, 11, 13, and Appendix 6.
• Annexes — Annex 10 Vol II and Vol III, Annex 11.
• Documents — Doc 9804 (ATN Ground-Ground Applications) with APAC ICD references; Doc 9896 (ATN using IPS).

Authoritative sources not held in the local library are flagged above ("Authoritative source — not in local library").