Detailed working notes on Flight and Flow Information for a Collaborative Environment (FF-ICE), the ICAO concept that replaces legacy AFTN flight plan exchange with a digital, service-oriented information environment. This folder expands the summary in topics/ff_ice.md into per-aspect files so each can be read on its own.

Files in this folder#

• overview.md — what FF-ICE is, role in trajectory-based operations, and the Doc 9965 anchor.
• components.md — services (planning, filing, trial, flight data request, notification, publication), the flight object, and FIXM.
• blocks.md — FF-ICE Step 1 (Release 1) and Step 2 (Release 2), and how they map onto the GANP/ASBU FICE thread.
• threads.md — FF-ICE capability areas (filing, planning, trajectory, notification, flow services).
• modules.md — anatomy of an FF-ICE service: objective, procedure, technology, enablers, KPIs.
• enablers.md — FIXM, SWIM, AMHS/IPS, AOC integration, regulation, training.
• performance_objectives.md — Key Performance Areas (predictability, efficiency, interoperability) and the KPIs that measure them.
• timeline.md — Doc 9965 1st edition (2012), Implementation Guidance Manual, FF-ICE/1 to FF-ICE/R1 evolution, EU CP1 mandate, FF-ICE/R2 outlook.
• references.md — consolidated ICAO, FIXM, and external references for everything in this folder.

Reading order#

Start with overview.md, then components.md, then blocks.md and threads.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 9965, Manual on Flight and Flow Information for a Collaborative Environment (FF-ICE), Volumes I and II.
• ICAO Doc 4444 (PANS-ATM), Chapter 17 — procedures for FF-ICE services.
• ICAO Annex 2 (Rules of the Air) — FPL/eFPL definitions.
• ICAO Annex 6 (Operation of Aircraft), Part I — Preliminary Flight Plan and dispatcher duties.
• ICAO Annex 10, Volume II, Section 3.9 — Globally Unique Flight Identifier (GUFI).
• ICAO Doc 9750 (Global Air Navigation Plan), GANP/ASBU thread FICE.
• FIXM project (https://www.fixm.aero/) — XML-schema realization of the FF-ICE information requirements.
• EUROCONTROL FF-ICE concept and Network Manager R1 services.
• EU Commission Implementing Regulation 2021/116 (Common Project 1) — FF-ICE/R1 eFPL submission for IFR GAT in EU/Norway/Switzerland.

What FF-ICE is#

FF-ICE stands for Flight and Flow Information for a Collaborative Environment. It is the ICAO concept that replaces the legacy AFTN flight-plan exchange with a digital, service-oriented information environment in which operators, ANSPs, ATFM units, airports, and adjacent FIRs share a common, machine-readable view of each flight across its full lifecycle.

PANS-ATM Doc 4444, Chapter 17, defines FF-ICE as the information needed for planning, coordination, and notification of flights, exchanged in standardized format between members of the ATM community. The reciprocal definitions in Annex 2 (Rules of the Air) treat the filed flight plan as either an FPL (legacy AFTN exchange) or an eFPL (FF-ICE exchange), the latter allowing exchange of additional information not contained within the legacy FPL.

The Doc 9965 anchor#

The authoritative ICAO reference is Doc 9965 — Manual on Flight and Flow Information for a Collaborative Environment (FF-ICE), published in two volumes:

• Volume I — Concept. Defines the operational concept, services architecture, information requirements, and trajectory management philosophy.
• Volume II — Application Guidance. Details message content, data conventions, and translation algorithms for mixed-mode AFTN/FF-ICE operation.

Doc 9965 is the document that Annex 2, Annex 6, Annex 10 Volume II, and Doc 4444 Chapter 17 all defer to for substantive guidance. Doc 4444 §17.1.1 explicitly notes that further details on restrictions and constraints applicable to the planning service "can be found in the Manual on Flight and Flow — Information for a Collaborative Environment (FF-ICE) (Doc 9965)".

Role in Trajectory-Based Operations#

FF-ICE is the information-layer foundation for Trajectory-Based Operations (TBO). TBO requires every actor — flight crew, ATS unit, flow manager, airline operations centre, airport — to be working from a single, shared, machine-readable view of the same 4D trajectory. That shared trajectory cannot exist while the flight plan is a fixed-format ICAO 4444 Chapter 4 message limited to a route string and a handful of performance fields.

FF-ICE provides:

1. A persistent flight identity — the Globally Unique Flight Identifier (GUFI) defined in Annex 10 Volume II §3.9 — that ties every message and event for a flight together from preliminary planning to arrival.
2. A rich flight object in FIXM that can carry a 4D trajectory, performance data, climb and descent profiles, weather assumptions, aircraft mass, ETOs, and operator preferences.
3. A service catalogue (planning, filing, trial, flight data request, notification, publication) that lets the ATM community read, write, and subscribe to flight information rather than push-publishing fixed-format messages.

In ASBU/GANP terms, FF-ICE is the FICE thread, and TBO is the TBO thread; FICE delivers the information the TBO thread needs in order to operate.

Two implementation steps#

Doc 9965 frames FF-ICE in two implementation steps. The current operational rollout is:

• FF-ICE Step 1 (Release 1, FF-ICE/R1). Pre-departure phase. Planning, filing, trial, notification, flight data request, and publication services. The eFPL replaces the FPL for participating flights. Mixed-mode operation with legacy AFTN recipients is required by Doc 4444 §17.2.1 c) and §17.3.3.
• FF-ICE Step 2 (Release 2, FF-ICE/R2). Post-departure phase. Extends the same service model into the airborne phase, supporting trajectory negotiation and revision in flight in support of full TBO. R2 is in concept maturation; no firm global mandate date.

Why FF-ICE matters#

The legacy AFTN flight plan was designed as a teletype message. It cannot carry a 4D trajectory, cannot be selectively updated, cannot expose flight information to non-recipient subscribers, and gives no shared identifier across actors. FF-ICE removes those constraints in a single coherent step and makes the flight object the unit of collaboration across the ATM network.

Relationship to other initiatives in this repo#

• SWIM — the transport substrate FF-ICE rides on. FF-ICE is one of the core SWIM information services (alongside Digital AIM and AMET).
• TBO — FF-ICE is the information enabler; TBO is the operational consumer.
• ASBU / GANP — FF-ICE is delivered through the FICE thread, Block 1 (R1) and Block 2 (R2).
• A-CDM, NOPS — consumers of FF-ICE publication and notification services for demand-capacity balancing and turnaround coordination.
• AIDC — adjacent ATS-to-ATS coordination; FF-ICE complements but does not replace AIDC for tactical inter-centre coordination.

FF-ICE is not a single artefact. It is a structured set of interlocking components that together describe what information is exchanged, through which services, between whom, using which data model, and identified how. The components are:

1. The flight object#

The flight object is the central data structure. It is a logical record that exists for every flight from the moment a Preliminary Flight Plan (PFP) is submitted until the flight has arrived. It carries:

• Identification — GUFI, callsign, aircraft identification, operator.
• Aircraft data — type, equipment, performance class, wake category.
• Route and 4D trajectory — sequence of trajectory points with latitude, longitude, altitude, and time at each point.
• Performance assumptions — climb and descent profiles, cruise level, cruise speed, mass, fuel.
• Weather assumptions used for the trajectory.
• Operator preferences — preferred level, preferred routing, cost index.
• Constraints — any restrictions issued by an FF-ICE services unit.
• Status — current lifecycle state (planning, filed, departed, arrived, cancelled).

Every FF-ICE message is, in effect, a read or write against the flight object referenced by its GUFI.

2. FF-ICE services (the service catalogue)#

Doc 4444 §17.1.1 enumerates six services. The appropriate ATS authority must designate at least one FF-ICE services unit and, as a minimum, provide the filing and flight data request services (Doc 4444 §17.2.1).

• Planning service. Evaluates a Preliminary Flight Plan (PFP) for acceptability and returns applicable restrictions and constraints (Planning Status). Supports collaborative refinement before filing.
• Filing service. Evaluates a Filed Flight Plan (eFPL) as a request for ATS and returns a Filing Status. The eFPL is the FF-ICE equivalent of the legacy FPL but carries 4D trajectory points, performance data, climb and descent profiles, weather assumptions, aircraft mass, ETOs, and the GUFI.
• Trial service. Supports what-if queries (Trial Request / Trial Response) so an operator can test scenarios without committing a PFP, eFPL, or update.
• Flight data request service. Returns flight-plan or SAR data for a specific flight to an eligible recipient on demand.
• Notification service. Pushes flight events such as Flight Departure and Flight Arrival to required recipients.
• Publication service. Publishes flight and flow data to authorized subscribers, supporting ATFM demand-capacity balancing and CDM.

Update and cancellation are handled by the Flight Plan Update and Flight Cancellation messages, with mandatory version control (Doc 4444 §17.4.1.5 / §17.4.1.6) so recipients detect missed increments. Each submission is acknowledged by a Submission Response.

3. The standard message set#

Doc 4444 Table 17-1 prescribes the standard FF-ICE messages:

• Submission Response.
• Preliminary Flight Plan (PFP).
• Planning Status.
• Trial Request / Trial Response.
• Filed Flight Plan (eFPL).
• Filing Status.
• Flight Plan Update.
• Flight Cancellation.
• Flight Data Request / Response.
• Flight Departure.
• Flight Arrival.

These messages all carry the GUFI of the flight they refer to and are encoded in FIXM.

4. FIXM — the data model#

The Flight Information Exchange Model (FIXM) is the XML-schema realization of the FF-ICE information requirements. FIXM is maintained jointly by EUROCONTROL, the FAA, and JCAB under ICAO sponsorship at https://www.fixm.aero/. An eFPL is, in practice, a FIXM-encoded message exchanged over a SWIM-style transport.

FIXM is paired with:

• AIXM — the Aeronautical Information Exchange Model, for aeronautical reference data (airspace, routes, navaids, procedures).
• WXXM / IWXXM — the Weather Information Exchange Model, for meteorological data.

Together, FIXM, AIXM, and IWXXM give every actor a coherent reference frame: the same flight, against the same aeronautical data, with the same weather assumptions.

5. GUFI — the flight identity#

The Globally Unique Flight Identifier (GUFI) is defined in Annex 10 Volume II §3.9. It is the unchangeable data element that ties all FF-ICE messages for a flight together. The originator assigns the GUFI on the PFP or eFPL (Annex 10 V2 §3.9.1 to §3.9.6) and may not reuse it for at least ten years. The GUFI is the join key between FF-ICE, SWIM publishers, and any downstream ATM system that needs to refer to the same flight.

6. The FF-ICE services unit#

A logical entity, designated by the appropriate ATS authority, that provides FF-ICE services to eligible community members. The services unit may be an existing ATS unit, a regional flow management unit, or a purpose-built node such as EUROCONTROL Network Manager or FAA CSS-FD. The services unit is the addressable peer in every FF-ICE exchange.

7. Eligible community members (the actors)#

FF-ICE participants include:

• Aircraft operators and their flight planning services.
• Air Navigation Service Providers (ANSPs) and their ATS units.
• Air Traffic Flow Management (ATFM) units at national, regional, and global level.
• Airport operators (for surface and turnaround coordination).
• Adjacent FF-ICE services units in neighbouring FIRs.
• Search and Rescue (SAR) services, via the flight data request service.

8. The mixed-mode bridge#

Doc 4444 §17.2.1 c) and §17.3.3 require an FF-ICE services unit to maintain the ability to translate between FF-ICE messages and the legacy AFTN ATS message set defined in Chapter 11. Doc 9965 Volume II provides the translation algorithms. Mixed-mode operation is a permanent design feature, not a transitional one — many SAR and non-equipped recipients will never become full FF-ICE peers.

What a Step is#

ASBU uses the word Block; FF-ICE uses the word Step (also called Release). The ideas are similar but not identical. A Step in FF-ICE bundles a set of services and information requirements that become globally implementable together, but the Step is defined by its functional scope (which phases of flight it covers and which services it offers) rather than by a fixed availability year.

Doc 9965 defines two implementation Steps:

• Step 1 — FF-ICE/R1 — Pre-departure information services.
• Step 2 — FF-ICE/R2 — In-flight information services.

These map onto the GANP/ASBU FICE thread as Block 1 (FICE-B1, R1) and Block 2 (FICE-B2, R2).

FF-ICE Step 1 (Release 1, FF-ICE/R1)#

Scope. Pre-departure phase. From the moment a flight is first proposed until it pushes back / takes off, every information exchange about that flight uses FF-ICE services keyed by GUFI.

Services delivered.

• Planning service (with PFP and Planning Status).
• Filing service (with eFPL and Filing Status).
• Trial service (Trial Request / Trial Response).
• Flight data request service.
• Notification service (Flight Departure as the closing event of R1).
• Publication service (for ATFM and CDM consumers).

Information delivered.

• The flight object, including 4D trajectory at the level of detail achievable pre-departure (route points, level changes, ETOs).
• Constraints applied by the planning and filing services.
• Operator preferences and performance data.

What R1 does not do.

• It does not negotiate trajectory revisions in flight.
• It does not provide tactical clearance delivery (CPDLC remains the channel).
• It does not replace ATS-to-ATS coordination (AIDC / OLDI remain).

Anchor points.

• Mandate (EU): Commission Implementing Regulation 2021/116 (Common Project 1) requires FF-ICE/R1 eFPL submission for IFR GAT in EU Member States, Norway, and Switzerland from 1 January 2026. EUROCONTROL Network Manager is the principal R1 services unit.
• USA: FAA Common Support Services — Flight Data (CSS-FD) is being built in phases to deliver R1 services within the SWIM segment of NextGen, with TBO as the operational driver.
• APAC: ICAO APAC FF-ICE Ad hoc Group is running R1 trials and pre-R2 workshops.
• Industry tooling: flight-planning vendors (Navblue N-Flight, AIR SUPPORT, Lido, Jeppesen) are publishing FF-ICE-ready eFPL filers ahead of the 2026 cutover.

FF-ICE Step 2 (Release 2, FF-ICE/R2)#

Scope. Adds the in-flight phase. R2 extends the same service model into the airborne portion of the flight, supporting trajectory negotiation and revision after departure in support of full TBO.

Services added.

• In-flight trajectory negotiation (revision of the 4D trajectory after departure, with the flight object updated in place).
• In-flight constraints exchange between ATS units, the operator, and the flow manager.
• In-flight notification services (waypoint passage, level change, trajectory-conformance events).

Information added.

• Live trajectory state (current and predicted), updated by the FMS via data link and reconciled against the ground view.
• Tactical constraint and preference exchange that is currently handled by voice or by AIDC.

Status. R2 is in concept maturation. Doc 9965 describes the services architecture, but the operational procedures, data link substrate, and human-machine interface design are still being trialled through SESAR, NextGen, and the ICAO APAC FF-ICE/R2 workshops. There is no firm global mandate date.

Dependencies on Step 1. R2 cannot operate without R1. The R1 flight object is the artefact R2 updates; the GUFI assigned at PFP / eFPL time in R1 is the join key R2 uses to update the same flight record after departure.

Step dependency principle#

R1 is a precondition for R2. A State or region cannot operationalise R2 without:

• A working R1 services unit producing a flight object per flight.
• SWIM transport with sufficient quality of service to carry in-flight updates.
• Air-ground data link able to deliver trajectory revisions to and from the FMS (ATN B2 over VDL Mode 2 in continental airspace; satcom data link or future Iris in oceanic and remote regions).
• Controller and pilot training for trajectory negotiation procedures.

A region that has not completed R1 will not benefit from R2.

Mapping FF-ICE Steps onto ASBU#

Supporting threads that must move in lockstep:

• SWIM — SWIM-B1 underpins R1; SWIM-B2 underpins R2.
• TBO — TBO-B2 is the operational consumer of FICE-B2.
• NOPS — NOPS-B1 / B2 is the flow-management consumer.
• COMI — air-ground data link (ATN B2, satcom) underpins R2.
• AMET — wind and weather information feeds the trajectory.

Implementation guidance#

ICAO publishes an FF-ICE Implementation Guidance Manual alongside Doc 9965 to help States move from declared FF-ICE participation to operational R1 services. The guidance covers AIP promulgation under Doc 4444 §17.2.2, services-unit governance, mixed-mode operating procedures, and conformance testing against FIXM.

FF-ICE in this folder uses the word capability area for what ASBU calls a thread: a feature area in which related services and information requirements are grouped. The capability areas below are the columns of the FF-ICE service matrix; the rows are the two Steps (R1 and R2). Together they describe what FF-ICE delivers and what must be in place to deliver it.

The five FF-ICE capability areas are:

1. Filing.
2. Planning.
3. Trajectory.
4. Notification.
5. Flow services (publication and flight data request).

These map directly onto the six services enumerated in Doc 4444 §17.1.1.

1. Filing#

Service. Filing service (with eFPL and Filing Status).

What it does. Replaces the legacy filed flight plan (FPL on AFTN) with the eFPL — a FIXM-encoded flight plan that carries 4D trajectory points, performance data, climb and descent profiles, weather assumptions, aircraft mass, ETOs, and the GUFI. The receiving FF-ICE services unit evaluates the eFPL and returns a Filing Status.

Why it matters. The eFPL is the FF-ICE artefact that must be in place for any other FF-ICE service to operate downstream. Doc 4444 §17.2.1 makes the filing service one of the two minimum services an FF-ICE services unit must offer.

Anchors. Doc 4444 §17.1.1 (services list); Doc 4444 §17.4.3 (filing procedures); Annex 2 Chapter 1 (FPL/eFPL definition).

2. Planning#

Service. Planning service (with PFP and Planning Status).

What it does. Allows an operator to submit a Preliminary Flight Plan (PFP) ahead of the formal eFPL filing window. The FF-ICE services unit evaluates the PFP for acceptability and returns applicable restrictions and constraints in a Planning Status, supporting collaborative refinement before filing.

Why it matters. Pre-filing collaboration moves constraint discovery earlier in the planning cycle. Operators learn about flow restrictions, airspace closures, or routing limitations while there is still time to optimise, rather than at filing time.

Anchors. Annex 6 Part I §4.6.1 (Note 2) — flight operations officer / dispatcher duties reference Doc 9965 for guidance on the PFP; Doc 4444 §17.4.2 (planning procedures).

3. Trajectory#

Service. Underpins both filing (R1) and in-flight revision (R2); also exposed via the trial service.

What it does. Provides a shared 4D trajectory as the primary operational reference for every actor associated with the flight. The trajectory is encoded in FIXM with a sequence of trajectory points each carrying latitude, longitude, altitude, and time.

Why it matters. The 4D trajectory is the artefact that makes TBO possible. Conflict probing, ATFM demand prediction, A-CDM turnaround coordination, environmental footprint reporting, and SAR all benefit from a single, authoritative trajectory rather than a collection of locally-reconstructed estimates.

R1 vs R2. In R1 the trajectory is fixed at filing time and updated only via Flight Plan Update messages. In R2 the trajectory is negotiable in flight: revisions originate from the FMS, the ATS unit, or the flow manager, and the flight object is updated in place.

Anchors. Doc 9965 Volume I (concept and trajectory model); ASBU TBO thread.

4. Notification#

Service. Notification service (Flight Departure, Flight Arrival, plus event-driven messages).

What it does. Pushes flight events to required recipients without the recipient having to poll. R1 covers Flight Departure and Flight Arrival as the closing events of the pre-departure and post-arrival phases respectively. R2 adds in-flight events (waypoint passage, level change, trajectory-conformance deviation).

Why it matters. Notification is what removes the legacy DEP / ARR / CHG / DLA AFTN message pattern and replaces it with event-driven push. Recipients subscribe to the events they care about and stop receiving volumes of irrelevant messages.

Anchors. Doc 4444 Table 17-1 (standard messages including Flight Departure and Flight Arrival); Doc 4444 §17.4.6 (notification procedures).

5. Flow services#

Services. Publication service and flight data request service.

What they do.

• The publication service publishes flight and flow data to authorized subscribers, supporting ATFM demand-capacity balancing, Network Manager operations, and CDM at airports.
• The flight data request service returns flight-plan or SAR data for a specific flight to an eligible recipient on demand. Doc 4444 §17.2.1 makes flight data request the second of the two minimum services any FF-ICE services unit must provide.

Why they matter. Flow services are the bridge between FF-ICE and network operations. The publication service is what feeds the demand-prediction engine of the Network Manager; the flight data request service is what lets a SAR coordinator pull the last known trajectory of an overdue flight without sending an AFTN request.

Anchors. Doc 4444 §17.4.7 (flight data request); Doc 4444 §17.4.8 (publication, where present in the published edition); EUROCONTROL Network Manager R1 services description.

Cross-area dependencies#

• Filing depends on FIXM (data model), GUFI (identity), SWIM (transport).
• Planning depends on filing being available downstream and on flow data being available upstream from the network manager.
• Trajectory is shared by filing, planning, and (in R2) in-flight notification.
• Notification depends on a working flight object — there is nothing to notify about until a flight has been at least pre-planned.
• Flow services depend on the publication subscriber population being authorised under the SWIM governance regime, and on adequate service-level agreements between the FF-ICE services unit and its subscribers.

The capability areas cannot be implemented independently. A region that deploys filing without planning leaves operators with no collaborative refinement channel; a region that deploys publication without filing has nothing meaningful to publish.

What an FF-ICE service is#

An FF-ICE service is the smallest planning unit in this folder. It is the cell at the intersection of one Step (R1 or R2) and one capability area (filing, planning, trajectory, notification, flow). A service is deliverable — a State or ANSP can plan, fund, procure, deploy, certify, train for, and operate it as a coherent capability.

Each service has the structured anatomy below, modelled on Doc 9965 and the GANP module template.

Anatomy#

1. Title and identifier#

For example: "Filing service — FF-ICE/R1". Where it is useful to map onto ASBU, the corresponding module identifier is FICE-B1/<seq>.

2. Operational improvement (objective)#

A plain-language statement of what changes operationally. For the filing service, this is the move from a fixed-format AFTN FPL to a FIXM-encoded eFPL carrying a 4D trajectory and a GUFI, evaluated by the FF-ICE services unit and acknowledged with a Filing Status.

3. Performance objective and applicable KPAs#

The "why". The service is tagged with one or more Performance Objectives drawn from the GANP catalogue, which in turn map to Key Performance Areas (KPAs). For filing, the headline KPAs are predictability, interoperability, and cost-effectiveness; for planning, add capacity and flight efficiency; for the trajectory and flow services, add environment.

4. Procedure element#

The procedural changes required:

• PANS-ATM (Doc 4444), Chapter 17 — the procedural anchor for every FF-ICE service.
• Annex 2 — adjusts the definition of the filed flight plan to permit the eFPL form.
• Annex 6 Part I — adjusts dispatcher duties to include the PFP.
• Annex 10 Volume II §3.9 — GUFI assignment.
• Doc 7030 (Regional Supplementary Procedures) and the local AIP for region-specific and State-specific provisions, as required by Doc 4444 §17.2.2.

5. Technology element#

The systems that must be deployed:

• Ground systems. FF-ICE services unit (e.g. EUROCONTROL Network Manager R1, FAA CSS-FD); FIXM-aware flight data processing system (FDPS); AIM and MET integration so the trajectory can be evaluated against current AIP and weather.
• Operator systems. Flight planning system that emits FIXM eFPL and consumes Filing Status / Planning Status / constraints feedback; operator AOC integration with airline operations.
• SWIM transport. Service registry, identity and access management, message-level QoS, audit logging.
• Air-ground (R2 only). ATN B2 over VDL Mode 2 in continental airspace; satcom data link or future Iris in oceanic and remote regions; FMS capable of 4D trajectory exchange.

6. Human performance element#

• Controller training to consume eFPL-rich flight strips and to understand the trajectory model rather than the route string.
• Pilot and dispatcher training on the PFP cycle, the GUFI lifecycle, and (in R2) on trajectory negotiation procedures.
• AIM and MET officer training so the data feeding the trajectory is fit-for-purpose.

7. Standards basis#

• Annex 1 (Personnel Licensing) — Amendment 179 aligns the flight plan definition to support FF-ICE.
• Annex 2 (Rules of the Air) — FPL/eFPL definition.
• Annex 6 (Operation of Aircraft) — PFP and dispatcher duties.
• Annex 10 (Aeronautical Telecommunications), Volume II §3.9 — GUFI.
• Annex 11 (Air Traffic Services) — coordination and flight plan information.
• Doc 4444 (PANS-ATM), Chapter 17 — procedures.
• Doc 9965 — the manual itself.
• Doc 9750 (GANP), FICE thread.

8. Enablers#

The infrastructure, regulation, and institutional prerequisites that must be in place. See enablers.md.

9. Dependencies#

Other capabilities that must be implemented (or partially implemented) first. For an R1 service these typically include SWIM-B0/B1, COMS-B0 (ground network), and bilateral agreements with adjacent FF-ICE services units. For an R2 service add SWIM-B2, COMI-B1/B2 (ATN B2 data link), TBO-B2 procedures, and an operating R1 baseline.

10. KPI linkage#

Quantitative indicators on which the service's effect can be measured. See performance_objectives.md.

11. Region applicability#

Universally applicable in principle, but the priority capability areas differ by region. EUR is mandate-driven (CP1 / Reg. 2021/116 to 1 January 2026 for R1). USA is segment-driven (FAA CSS-FD phased delivery aligned with NextGen TBO). APAC is trial-driven (APAC FF-ICE Ad hoc Group, R1 trials, pre-R2 workshops).

12. Implementation guidance#

ICAO publishes an FF-ICE Implementation Guidance Manual alongside Doc 9965; EUROCONTROL publishes Network Manager R1 service descriptions; the FAA publishes CSS-FD interface control documents; SESAR and SESAR Deployment Manager publish R1 deployment artefacts under Common Project 1.

Worked examples#

Example 1 — Filing service (FF-ICE/R1)#

• Operational improvement. Operators submit eFPLs to the FF-ICE services unit; the unit evaluates and returns a Filing Status. Mixed-mode translation to legacy AFTN recipients per Doc 4444 §17.3.3.
• KPAs. Predictability, interoperability, cost-effectiveness.
• Procedure. Doc 4444 §17.4.3; AIP promulgation per §17.2.2.
• Technology. FIXM-aware FDPS; SWIM transport; eFPL filer in the operator's flight planning system.
• Enablers. AIP publication of services and conditions; bilateral agreement with the network manager; controller training.
• Dependencies. SWIM transport; GUFI assignment process; mixed-mode translation engine.
• KPIs. eFPL acceptance rate; eFPL filing-to-status latency; proportion of flights filed via eFPL vs legacy FPL.

Example 2 — Planning service (FF-ICE/R1)#

• Operational improvement. Pre-filing collaborative refinement of the flight via the PFP / Planning Status loop, surfacing flow and airspace constraints earlier in the cycle.
• KPAs. Predictability, capacity, flight efficiency.
• Procedure. Doc 4444 §17.4.2; Annex 6 Part I §4.6.1 (Note 2).
• Technology. Planning evaluator within the FF-ICE services unit; feed of current ATFM regulations; weather and aeronautical reference data integration.
• Dependencies. Filing service available downstream; flow data available upstream from the network manager.
• KPIs. Proportion of flights with at least one PFP cycle; share of constraints surfaced before eFPL filing rather than after.

Example 3 — In-flight trajectory negotiation (FF-ICE/R2)#

• Operational improvement. After departure, the flight object is updated in place as the trajectory is revised by the FMS, the ATS unit, or the flow manager. The shared trajectory remains the single authoritative reference.
• KPAs. Flight efficiency, environment, capacity, predictability.
• Procedure. Doc 9965 Volume I (concept); future Doc 4444 Chapter 17 amendments for in-flight services.
• Technology. ATN B2 data link; TBO-capable FMS; trajectory conformance monitoring on the ground.
• Dependencies. R1 baseline; SWIM-B2; COMI-B1/B2 data link; controller and pilot training.
• KPIs. Trajectory conformance; track-mile efficiency; vertical profile efficiency.

What an enabler is#

An enabler is a supporting element without which an FF-ICE service cannot deliver its intended benefit. Enablers are not themselves operational improvements; they are prerequisites. FF-ICE makes its enablers explicit so that planners do not deploy a service whose foundation is missing.

Enablers fall into seven categories.

1. FIXM — the data model#

The Flight Information Exchange Model (FIXM) is the XML-schema realization of the FF-ICE information requirements. FIXM is maintained jointly by EUROCONTROL, the FAA, and JCAB under ICAO sponsorship at https://www.fixm.aero/.

• FIXM Core defines the flight object and its trajectory model.
• FIXM Extensions (e.g. FIXM US, FIXM EU) carry region-specific attributes that are not (yet) in Core.
• FIXM is paired with AIXM (aeronautical information) and IWXXM (weather) so that every actor evaluates the same flight against the same reference frame.

A region cannot field FF-ICE without a FIXM-aware ground system on the ANSP side and a FIXM-aware flight planning system on the operator side.

2. SWIM — the transport substrate#

System-Wide Information Management (SWIM) is the information backbone that FF-ICE rides on. SWIM provides:

• Service registry and discovery.
• Identity and access management for eligible community members.
• Policy-based authorisation (who may publish, who may subscribe, who may read).
• Message-level quality of service and delivery guarantees.
• Audit logging for safety and regulatory traceability.

In ASBU terms, FF-ICE/R1 depends on SWIM-B1; FF-ICE/R2 depends on SWIM-B2. EUROCONTROL operates the European SWIM yellow profile under which Network Manager R1 services are exposed; the FAA operates the NAS Enterprise Messaging Service under which CSS-FD is exposed.

3. AMHS / ATN / IPS — the network underlay#

FF-ICE rides on top of the existing ATN substrate during transition, and on IP-based transport (ATN/IPS, IPv6) in the longer term.

• AMHS (ATS Message Handling System) — the X.400-based replacement for AFTN that already carries non-FF-ICE ATS messages. FF-ICE services units must continue to interoperate with AMHS-only peers per Doc 4444 §17.3.3.
• ATN/OSI to ATN/IPS migration — the transition from OSI-stack ATN to an IPv6-based ATN/IPS, providing a single IP-converged ground-ground substrate for FF-ICE, SWIM, and AIDC.
• PENS / NewPENS (in Europe), comparable national / regional IP backbones elsewhere.

For FF-ICE/R2, the air-ground substrate matters: ATN B2 over VDL Mode 2 (continental), satcom data link (oceanic and remote), and future substrates such as Iris and LDACS.

4. AOC and operator integration#

FF-ICE only delivers benefit if the operator side is integrated:

• The flight planning system must produce FIXM eFPLs and consume Filing Status / Planning Status / constraints feedback.
• The Airline Operations Centre (AOC) must be linked to the flight-planning workflow so that constraints surfaced by the planning service feed back into commercial scheduling, fuelling, and crew planning.
• Vendors (Navblue N-Flight, AIR SUPPORT, Lido, Jeppesen) are publishing FF-ICE-ready eFPL filers ahead of the EU 2026 cutover.

Without AOC integration, FF-ICE remains a one-way submission channel and the collaborative refinement loop does not close.

5. Regulatory framework#

• State approval frameworks. AIP promulgation of FF-ICE services per Doc 4444 §17.2.2, including instructions for constructing valid flight plans, time limits for PFP submission, and the period under which Planning and Filing Status updates are provided.
• Regional mandates. EU Commission Implementing Regulation 2021/116 (Common Project 1) mandates FF-ICE/R1 eFPL submission for IFR GAT in EU/Norway/Switzerland from 1 January 2026.
• Safety oversight. Annex 19 SMS at the State and service-provider levels, extended to cover information-service risks.
• Cybersecurity. Annex 17 and State cyber-security regulation applied to SWIM-connected systems; identity and credential lifecycle management.
• Data protection. Where flight information is treated as personal or commercially sensitive, applicable regulation (e.g. GDPR in EU) governs publication-service subscriptions.

6. Human resources and training#

• Controllers. Training to read and act on eFPL-rich flight information rather than the legacy ATC strip; understanding of the GUFI lifecycle; for R2, training on trajectory negotiation procedures.
• Pilots. Awareness of the eFPL flow, the GUFI, and (R2) procedures for in-flight trajectory revision.
• Dispatchers and flight operations officers. PFP cycle, planning service interaction, mixed-mode operating with non-FF-ICE destinations and overflown FIRs. Anchored in Annex 6 Part I §4.6.1 (Note 2).
• AIM and MET officers. Data quality regime so that the aeronautical and weather data feeding the trajectory is fit-for-purpose.
• Engineering and operations staff. SWIM service operations, identity and access management, FIXM schema versioning.

7. Institutional and inter-State#

• Bilateral letters of agreement between FF-ICE services units in adjacent FIRs, defining how flight objects are handed over (or re-published) at boundaries.
• Regional planning fora. APANPIRG (APAC), MIDANPIRG (MID), EANPG (EUR) endorsing harmonised implementation through regional plans (APAC Seamless ATM Plan, MID Air Navigation Strategy, European ATM Master Plan).
• Network manager / regional flow management arrangements. In Europe, EUROCONTROL Network Manager is the principal R1 services unit; subscription to its publication service is the pathway by which national ATFM units consume FF-ICE flow data.
• Memoranda of understanding for SWIM and FIXM interoperability — schema-version compatibility, security policy alignment, audit-log exchange where required.

How enablers are managed in practice#

For FF-ICE, the practical test of enabler readiness is whether a flight planned in one region can be evaluated, filed, departed, and arrived against the FF-ICE services unit of the destination region without any AFTN-format message being required by either party. That single end-to-end test exercises FIXM, SWIM, the regulatory framework, controller and dispatcher training, and the bilateral institutional agreements simultaneously.

A region that buys an FF-ICE services unit but does not put the matching SWIM, FIXM, regulatory, training, and institutional pieces in place will not see the predicted benefit.

The performance lens of FF-ICE#

FF-ICE is not deployed for its own sake. Each service is justified by the performance benefit it delivers across the ATM community, and progress is measured against defined 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). Doc 9750 (GANP) and the GANP Portal expose the catalogue.

The chain is:

KPA  --(measured by)-->  KPI  <--(targeted by)--  Performance Objective  --(achieved by)-->  FF-ICE service

Headline KPAs for FF-ICE#

Of the eleven Doc 9854 / Doc 9883 KPAs, FF-ICE most directly improves:

• Predictability — variance between planned and actual times (off-block, airborne, landing). FF-ICE reduces variance because every actor is working from the same flight object and the same trajectory, and because constraints are surfaced earlier in the planning cycle.
• Flight efficiency — actual vs. user-preferred trajectory; track- mile and vertical-profile efficiency. FF-ICE supports efficiency by letting operators express full preferences in the eFPL and (in R2) by letting the trajectory be negotiated in flight.
• Interoperability — common procedures, data formats, and systems enabling seamless cross-border operation. FF-ICE replaces a patchwork of local AFTN flight-plan handlers with a single FIXM-based service catalogue.

Secondary KPAs improved by FF-ICE:

• Capacity — better demand prediction in ATFM lets the network use available capacity more fully; pre-filing planning surfaces flow constraints earlier so operators can adapt rather than be delayed.
• Cost-effectiveness — fewer manual interventions on flight plans; fewer rejected FPLs; fewer downstream coordination calls.
• Environmental impact — better trajectory fidelity means more realistic 4D planning, supporting CDO / CCO conformance and optimum-level access (especially under R2).
• Safety — improvement is indirect: a single, authoritative flight object reduces the risk that two actors are working from inconsistent information; SAR coordination via the flight data request service is more reliable than AFTN polling.
• Access and equity — FF-ICE participation must be open to all eligible community members; the design avoids preferential information flow.

Performance Objectives#

A Performance Objective (PO) is a stated, measurable improvement in one or more KPAs. The GANP Portal carries the live catalogue. Examples relevant to the FICE thread (illustrative naming):

• PO — Reduce flight-plan-related variance in network demand prediction. Measured by demand-prediction error at H-2 and H-1. Delivered by the FF-ICE filing service, the publication service, and in R2 by in-flight trajectory updates.
• PO — Surface flow and airspace constraints earlier in the planning cycle. Measured by the proportion of constraints surfaced via PFP / Planning Status before the eFPL filing window. Delivered by the FF-ICE planning service.
• PO — Improve cross-border information consistency. Measured by semantic conformance and message-level QoS across FIR boundaries. Delivered by FIXM schema version alignment, SWIM service-level agreements, and bilateral letters of agreement.
• PO — Reduce manual handling of flight plans by ATS units. Measured by share of flights filed via eFPL versus legacy FPL, and by the rate of manual rejections / corrections.
• PO — Improve arrival predictability through better pre-departure trajectory fidelity. Measured by standard deviation of actual vs. planned landing time. Delivered jointly with A-CDM, RSEQ, and NOPS.

Key Performance Indicators (KPIs)#

Quantitative measures used to evidence progress toward an FF-ICE-related PO. Common families:

Filing and submission KPIs#

• eFPL acceptance rate (eFPLs accepted on first submission).
• eFPL submission-to-Filing-Status latency.
• Proportion of flights filed via eFPL vs legacy FPL.
• Rate of Flight Plan Update / Flight Cancellation messages per filed flight.

Planning KPIs#

• Proportion of flights with at least one PFP cycle.
• Time between PFP submission and Planning Status response.
• Share of constraints surfaced before eFPL filing rather than after.

Trajectory KPIs#

• Trajectory fidelity (planned vs flown deviation in latitude, longitude, altitude, time).
• Track-mile efficiency (KEP / KEA in EUROCONTROL terms).
• Vertical-profile efficiency.
• (R2) Trajectory conformance after revision.

Notification and flow KPIs#

• Time from Flight Departure event to publication availability.
• Subscriber population on the publication service.
• Flight data request response time and success rate.

Interoperability KPIs#

• SWIM service availability and message latency.
• FIXM schema-version conformance across peers.
• Number of active bilateral FF-ICE services-unit agreements.

Safety and SAR KPIs#

• Mean time to retrieve last known trajectory of an overdue flight via the flight data request service.
• Number of incidents attributable to inconsistent flight information between actors (target: zero).

How performance is reported#

• Globally — through the ICAO ASBU implementation monitoring reports, with FICE-thread modules reported alongside SWIM, AIM, AMET, and TBO.
• Regionally
  • APAC: APANPIRG performance reporting; APAC Seamless ATM Plan; APAC FF-ICE Ad hoc Group trial reports.
  • MID: MIDANPIRG monitoring under the MID Air Navigation Strategy.
  • EUR: EUROCONTROL Performance Review Body and the LSSIP cycle; SESAR Deployment Manager Common Project 1 deployment reports.
  • NAT/CAR/SAM/AFI: respective regional offices.
• Nationally — State Action Plans for environment and safety, plus the State's national ATM modernisation plan.

Why this matters for planning#

Tying every FF-ICE service to a Performance Objective and a KPI keeps the programme honest. It forces the question "what measurable problem does this fix?" during business-case development. It also lets oversight bodies ask whether deployed FF-ICE capability is actually delivering the predictability, efficiency, and interoperability gains promised by Doc 9965 and the GANP.

Three timelines to keep distinct#

When discussing FF-ICE "dates", separate three things:

1. Doc 9965 / standards timeline — when ICAO published or amended the manual and the supporting Annex / PANS provisions.
2. Step (Release) timeline — when FF-ICE/R1 and FF-ICE/R2 became, or are planned to become, operationally implementable.
3. Regional / national mandate timeline — when participation in FF-ICE becomes a regulatory obligation in a given State or region.

A State's own implementation plan is a fourth timeline; it must be expressed in terms of the Step availability and the regional plan's milestones.

Doc 9965 / standards timeline#

The two inflection points to remember are 2012 (Doc 9965 1st edition published, the FF-ICE concept becomes a published ICAO manual) and the 2020 maturation pass that re-cast FF-ICE/1 as the operationally deployable FF-ICE/R1.

FF-ICE/1 to FF-ICE/R1 evolution#

The change from "FF-ICE/1" to "FF-ICE/R1" is more than a renaming:

• FF-ICE/1 (Doc 9965 1st edition, 2012) described the full pre-departure concept including services that turned out to need longer to mature (e.g. fully automated trajectory negotiation pre-departure).
• FF-ICE/R1 is the operationally deployable subset: planning, filing, trial, flight data request, notification, and publication services, with mixed-mode operation against legacy AFTN. R1 is what the EU CP1 mandate refers to and what EUROCONTROL Network Manager exposes today.

Doc 9965 Volume II (Application Guidance) is the document that narrows the concept down to the R1 service set and provides the data-conventions and translation algorithms needed to operate it alongside legacy systems.

Step availability timeline#

2012 ----- 2019 ----- 2025 ----- 2031 ----- ...
  |          |          |
 Doc 9965   FICE-B1    FICE-B2
 1st ed.    (R1, pre-  (R2, in-
            departure) flight)

• FF-ICE/R1. Operationally deployable from 2019 in ASBU terms; EU mandates submission for IFR GAT from 1 January 2026; USA delivering in phases via FAA CSS-FD; APAC running R1 trials.
• FF-ICE/R2. ASBU notional availability from 2025 (FICE-B2); in concept maturation; no firm global mandate date.

Regional and national mandate timeline#

European Union#

• Commission Implementing Regulation 2021/116 (Common Project 1) is the binding instrument for EU/Norway/Switzerland.
• 1 January 2026 — FF-ICE/R1 eFPL submission becomes mandatory for IFR GAT in the EU/Norway/Switzerland area.
• EUROCONTROL Network Manager is the principal R1 services unit; participation is governed by Network Manager service agreements.

United States#

• FAA Common Support Services — Flight Data (CSS-FD) is being built in phases. CSS-FD is the SWIM segment that exposes FF-ICE services within NextGen, with TBO as the operational driver.
• No single mandate date; deployment is phased per CSS-FD increments.

Asia / Pacific#

• ICAO APAC FF-ICE Ad hoc Group runs R1 trials and pre-R2 workshops; the group's outputs feed into the APAC Seamless ATM Plan and APANPIRG decisions.
• Adoption is State-by-State; no region-wide mandate date comparable to EU CP1.

Middle East#

• MIDANPIRG tracks FF-ICE under the MID Air Navigation Strategy; bilateral arrangements between MID States and EUROCONTROL Network Manager support transit traffic.

How to read a date in an FF-ICE document#

When an FF-ICE document uses a date, check which kind of date it is:

• "Doc 9965 1st edition (2012)" — ICAO publication date.
• "FICE-B1 from 2019" — ASBU notional availability (global earliest).
• "FF-ICE/R1 mandatory from 1 January 2026" — EU CP1 regulatory date.
• "Operator XYZ files first eFPL in 2024" — voluntary national or bilateral milestone.
• "FF-ICE/R2 target date" — typically a planning estimate, not a binding commitment.

Mixing these up leads to false claims that a State is "behind" or "ahead" of FF-ICE, when in fact the only meaningful measure is the State's own implementation plan against its declared milestones.

Implementation monitoring cadence#

• Global — ICAO publishes ASBU implementation status (FICE thread included) as input to the GANP review cycle.
• EUR — SESAR Deployment Manager reports on Common Project 1; EUROCONTROL Performance Review Body reports through the LSSIP cycle.
• USA — FAA reports CSS-FD progress through NextGen reporting.
• APAC — APANPIRG annual reporting under the APAC Seamless ATM Plan; FF-ICE Ad hoc Group meeting outputs.
• National — typically a 3-5 year national air navigation plan, reviewed annually, expressing FF-ICE participation in terms of Doc 9965 services, FIXM versions, and SWIM peering arrangements.

Primary ICAO documents#

• Doc 9965 — Manual on Flight and Flow Information for a Collaborative Environment (FF-ICE), Volume I — Concept. Defines the FF-ICE concept, services architecture, information requirements, and trajectory management philosophy (authoritative source — not in local library).
• Doc 9965 — Manual on FF-ICE, Volume II — Application Guidance. Details message content, data conventions, translation algorithms for mixed-mode AFTN/FF-ICE operation, and implementation guidance referenced by Doc 4444 §17.3.3 Note 3 (authoritative source — not in local library).
• Doc 4444 — PANS-ATM, Chapter 17 (Flight and Flow — Information for a Collaborative Environment (FF-ICE) services). The procedural anchor for every FF-ICE service:
  • §17.1.1 — enumerates the six FF-ICE services.
  • §17.2.1 — appropriate ATS authority obligations: designate at least one FF-ICE services unit; provide filing and flight data request services as a minimum; maintain mixed-mode capability with non-FF-ICE units; promulgate via AIP.
  • §17.2.2 — content to be promulgated in the AIP.
  • §17.3.1, Table 17-1 — standard FF-ICE messages.
  • §17.3.3 — translation between FF-ICE and legacy ATS messages.
  • §17.4.1 to §17.4.7 — general procedures for FF-ICE services.
• Doc 9854 — Global Air Traffic Management Operational Concept. Source of the eleven KPAs against which FF-ICE performance is measured.
• Doc 9883 — Manual on Global Performance of the Air Navigation System. Defines the performance management methodology used to justify and measure FF-ICE deployment.
• Doc 9750 — Global Air Navigation Plan (GANP). ASBU thread FICE with Block 1 (FF-ICE/R1) and Block 2 (FF-ICE/R2); supporting threads SWIM, TBO, NOPS, AMET, COMI.
• Doc 8126 — Aeronautical Information Services Manual. Frames the AIM-side data quality regime that feeds FF-ICE trajectory evaluation.
• Doc 10066 — PANS-AIM. Aeronautical data catalogue and quality requirements that the FF-ICE trajectory evaluator depends on.
• Doc 10157 — PANS-MET. Meteorological information procedures underpinning the wind and weather assumptions in the eFPL.

ICAO Annexes most touched by FF-ICE#

• Annex 1 (Personnel Licensing) — Amendment 179 aligns the definition of a flight plan to support initial implementation of FF-ICE services (applicability 26 November 2026).
• Annex 2 (Rules of the Air), Chapter 1 (Definitions) — defines Filed flight plan as either FPL or eFPL; the Note distinguishes AFTN-exchanged FPL from FF-ICE-exchanged eFPL carrying additional information.
• Annex 6 (Operation of Aircraft), Part I, §4.6.1 (and Note 2) — flight operations officer / dispatcher duties; references Doc 9965 for guidance on FF-ICE services and the Preliminary Flight Plan.
• Annex 10 (Aeronautical Telecommunications), Volume II, §3.9 — Globally Unique Flight Identifier (GUFI). §3.9.1 to §3.9.6 mandate GUFI assignment by the originator of a PFP/eFPL, uniqueness, and the ten-year non-reuse rule.
• Annex 11 (Air Traffic Services) — provisions on ATS coordination and flight plan information that underpin FF-ICE services exchange.
• Annex 17 (Security) — applied to SWIM-connected FF-ICE systems.
• Annex 19 (Safety Management) — SMS at the State and service-provider levels, extended to information-service risk.

Live / authoritative sources#

• ICAO Store, Doc 9965 — https://store.icao.int/en/manual-on-flight-and-flow-information-for-a-collaborative-environment-ff-ice-doc-9965
• ICAO GANP Portal — https://ganpportal.icao.int/ — live home of the ASBU FICE thread.
• ICAO APAC FF-ICE workshop material — https://www.icao.int/sites/default/files/APAC/Meetings/2025/2025%20FF-ICE%202%20and%20WS/Guidance%20Material/06-Flight-and-Flow-Information-for-a-Collaborative-Environment-FF-ICE-Services.pdf

FIXM and information-model references#

• FIXM project — https://www.fixm.aero/ — XML-schema realization of the FF-ICE information requirements, maintained jointly by EUROCONTROL, the FAA, and JCAB under ICAO sponsorship.
• EUROCONTROL FIXM page — https://www.eurocontrol.int/model/flight-information-exchange-model

Regional implementation references#

• EUROCONTROL FF-ICE concept — https://www.eurocontrol.int/concept/flight-and-flow-information-collaborative-environment
• EUROCONTROL Network Manager — principal FF-ICE/R1 services unit for the EUR region; service descriptions in Network Manager publications.
• SESAR Deployment Manager, FF-ICE R1 eFPL deployment family — https://www.sesardeploymentmanager.eu/projects/2022_035_af5
• EU Commission Implementing Regulation 2021/116 (Common Project
  1. — binding instrument mandating FF-ICE/R1 eFPL for IFR GAT from 1 January 2026 in EU/Norway/Switzerland (authoritative source — not in local library).
• FAA Common Support Services - Flight Data (CSS-FD) — https://www.faa.gov/air_traffic/technology/swim/common-support-services-flight-data-css-fd
• APAC Seamless ATM Plan (ICAO Asia/Pacific Regional Office) — APAC realisation; FF-ICE Ad hoc Group outputs.
• MID Air Navigation Strategy (ICAO MID Regional Office) — MID realisation under MIDANPIRG.

Industry, training, and supporting material#

• SKYbrary, Doc 9965 summary — https://skybrary.aero/bookshelf/manual-flight-and-flow-information-collaborative-environment-ff-ice-doc-9965
• Flight-planning vendors publishing FF-ICE-ready eFPL filers ahead of the 2026 EU cutover include Navblue (N-Flight), AIR SUPPORT, Lido (Lufthansa Systems), and Jeppesen (Boeing).

Coverage note#

Doc 9965 itself is not present in the local ICAO Markdown library that this workspace indexes. The strongest internal material is Doc 4444 Chapter 17, Annex 2 definitions, Annex 6 Part I PFP provisions, and Annex 10 Volume II §3.9 GUFI procedures. For substantive FF-ICE concept and application guidance, the ICAO Store and the GANP Portal are the authoritative external entry points.