Every flight in European airspace starts with a flight plan, and much of what the airline knows about that flight never makes it into the plan. The airline’s planning system calculates a detailed four-dimensional trajectory from aircraft performance, take-off mass and cost index, then compresses it into a short coded message.
FF-ICE (Flight and Flow Information for a Collaborative Environment) is ICAO’s plan to close that gap. It replaces the one-way message with shared, structured flight information that airspace users can check, negotiate and update before departure. Adopting FF-ICE affects flight planning systems, data interfaces and the way capacity decisions get made.
At Dreamix, we provide custom aviation software development for airlines, airports and business aviation companies. Standards documents make for heavy reading, so we tell this one as a story. Homer’s Odyssey describes a voyage home that took ten years, largely because the information Odysseus needed never reached him in time. Each section below pairs an episode from the epic with a practical question for air traffic management (ATM): why the legacy flight plan loses information, what FF-ICE puts in its place, how trial requests change planning decisions, and what a safe transition requires.
Sing, Muse of the flight plan
Nearly three thousand years ago, Homer told of a man who needed ten years to sail from Troy to Ithaca, a voyage that, with a fair wind, should have taken weeks. Odysseus was not a poor navigator. He was the victim of fragmented information: gods who never shared their intentions, winds sealed in a bag no one had briefed the crew about, harbours whose hazards were discovered only on arrival. Read with a modern eye, every detour in the Odyssey is a failure of shared situational awareness.
Aviation knows this story well and fragmented information continues to be an operational challenge in aviation. Every day, tens of thousands of flights cross the skies of Europe, and each one relies on a document that is, in spirit, still the hydraulic telegraph of Aeneas Tacticus: the ICAO flight plan. In the fourth century BC, two identical vessels of water stood on distant hills, each holding a rod inscribed with a short list of pre-agreed messages, such as "ships have arrived" or "grain is needed".
When the torch was raised, both vessels were drained together, and the line at the waterline became the message. It was ingenious, but it could only say what had already been carved into the rod. The flight plan works the same way: fixed fields, abbreviated codes, no room for nuance. Its format was refreshed in 2012, but carving a few new lines on the rod does not change the vessel. It remains a compressed, character-limited message, transmitted over AFTN and AMHS and re - read by each stakeholder along the route. The aircraft reaches its destination, of course.
But like Odysseus, it often gets there by way of re-filings, rejected messages and tactical reroutes, because what the operator truly intended was never on the rod to begin with.
FF - ICE, ICAO's concept of Flight and Flow Information for a Collaborative Environment, is the answer. It is not a bigger vessel with a longer rod. It is a new epic.
Penelope's Loom: Why the legacy flight plan unravels
While Odysseus wandered, Penelope wove a burial shroud by day and quietly unpicked it by night. The legacy flight plan behaves in much the same way. An airline operations centre builds a carefully optimised trajectory in its flight planning system, rich with aircraft performance data, take - off mass, cost index and a detailed four - dimensional profile. Then it flattens all of that into Item 15 and Item 18: abbreviated route strings and free text.
Downstream, the Network Manager's IFPS and every air navigation service provider along the route re - weave the trajectory with their own models, producing their own predictions. What the operator wove by day is unpicked at every FIR boundary.
The consequences are familiar to anyone who has worked a busy ops room. Trajectory predictions differ between the operator, the network and individual ATS units. The airspace user has almost no way to express intent, such as preferred alternatives or acceptable constraints. Capacity problems surface late, when the only remaining tools are slot delays and tactical rerouting. Coordination relies on point - to - point messages rather than shared information.
There is also the Cyclops problem. Trapped in Polyphemus's cave, Odysseus called himself "Nobody", and the trick worked because identity was ambiguous. A legacy flight is identified by a loose combination of callsign, aerodromes and date of flight, which is enough for humans to muddle through but a constant source of mismatched and duplicated records for machines.
Read next: The Future of Air Traffic Controllers (ATCOs): AI, Automation & ATM
The pillars of FF-ICE
FF - ICE, described in ICAO Doc 9965 and brought into the procedures of PANS - ATM for Release 1, replaces the message - centred flight plan with a shared, living set of flight information. Its architecture rests on a few elements:
- GUFI, the Globally Unique Flight Identifier. Assigned once and kept for the whole life of the flight, it ends the "Nobody" problem. Every stakeholder refers to the same flight in the same way.
- The extended flight plan (eFPL). Beyond the route string, it carries the operator's 4D trajectory, performance data, and preferences and constraints. The operator's intent is no longer flattened, it travels intact.
- FIXM, the Flight Information Exchange Model. A structured, machine - readable data model that sits alongside AIXM and IWXXM in the global information family.
- SWIM, System Wide Information Management. The service - oriented backbone that replaces point-to-point messaging with request/reply and publish/subscribe exchanges between authorised participants.
- eASPs, eligible Airspace Service Providers. The ANSPs and network functions that receive, evaluate and respond to flight information for the airspace they manage.
On top of these foundations, Release 1 defines a set of pre - departure services: filing, planning (submitting a preliminary flight plan long before departure), trial requests, flight data requests, notification of departure and arrival, and publication, which lets subscribers receive every update to a flight they care about.
Read next: Digital Fuel for Aviation: AIXM, FIXM, FF-ICE, Digital NOTAM
Between Scylla and Charybdis: Negotiating the trajectory
In the strait between Scylla and Charybdis, Odysseus faced a brutal trade - off: lose six men to the monster or risk the whole ship in the whirlpool. He made the call alone, with Circe's warning as his only pre - flight briefing.
Airspace users face their own straits every day. Route charges pull one way, fuel burn another, ATFM delay a third, and the least-cost route is often the one most exposed to a regulated sector. Under the legacy regime, an operator discovers which monster awaits only after filing, when a slot arrives or a flight plan is rejected.
FF - ICE changes the sequence. Through the trial request and planning services, the operator can ask the eASPs a simple, powerful question before committing: if I fly this trajectory, will you accept it, and under what constraints? The network can reply with the constraints that apply, a suggested reroute, or an expected impact on demand and capacity balancing (DCB). The decision stays with the airspace user, but it is now informed by the same picture the network sees.
This is Collaborative Decision Making (CDM) moved upstream, from the day of operations into the planning phase. It also lays the keel for Trajectory - Based Operations (TBO), in which the agreed 4D trajectory becomes a shared reference, almost a contract, between the flight deck, the airline, the network and every ANSP along the way. When airports connect through A - CDM, milestones such as the target off-block time can be tied to the same flight object, and the whole gate - to - gate chain begins to steer by a single chart.
Read next: How to Improve Airline Operations: A Practical Guide 2026
Sirens and Wax: The discipline of implementation
Odysseus wanted to hear the Sirens, so he had himself bound to the mast while his crew sailed on with wax in their ears. It remains one of literature's best lessons in change management: enjoy the new music, but lash yourself to a governance framework first.
FF - ICE has its own Sirens. The first is the temptation to treat it as a message - format upgrade, swapping FPL 2012 for XML and declaring victory. The real change is architectural. Flight data processing systems, network interfaces and airline flight planning tools must all learn to manage a flight object whose state evolves over time, rather than a stack of messages.
The second is the transition itself. For years, the ecosystem will run in mixed mode, with FF - ICE - capable and legacy stakeholders sharing the same flights. That demands robust translation between eFPL and FPL 2012, careful handling of information that has no legacy equivalent, and a clear view of which stakeholder is authoritative at every moment.
The third is trust. SWIM exposes services across organisational and national boundaries, so identity management, PKI, service - level agreements, and validation against the right FIXM version and application libraries are not optional extras. In Europe, the SWIM Yellow Profile and the Common Project 1 requirements supply much of the rope for that mast.
Beyond the horizon lies Release 2, extending FF - ICE into the execution phase, where trajectories are updated and synchronised in flight. Organisations that build clean, service-oriented foundations for Release 1 will find that next leg of the voyage far calmer.
Ithaca: The homecoming of the trajectory
When Odysseus finally reached Ithaca, disguised as a beggar, he was recognised in stages: by the old dog Argos, by the scar his nurse Eurycleia found, and finally by the great bow only he could string. Identity, verified beyond doubt, restored order to the house.
That is what FF - ICE promises the flight. From the first preliminary plan to on-block, the flight carries one identity and one shared trajectory, recognised by every system it meets. The benefits follow naturally: better predictability for the network, earlier and fairer resolution of capacity imbalances, more flight efficiency with lower fuel burn and emissions, fewer rejected and re - filed plans, and a system that is more resilient when weather or disruption forces a change of course.
The poet Constantine Cavafy reminded us that the value of Ithaca lies in the journey it inspires. FF - ICE is the same. Its real gift is not a new format but a new way of working together: airspace users, the Network Manager, ANSPs and airports sharing one picture of every flight.
A mentor for the voyage
In the Odyssey, the goddess Athena takes the form of Mentor, an old friend of the family, to guide Telemachus when the path ahead is unclear.
The voyage to FF - ICE is long, and like any great journey, it rewards those who know the waters. At Dreamix, our engineers have navigated them firsthand: service - oriented SWIM architectures, FIXM - based data exchange, integration with existing flight data processing systems, mixed - mode transition strategies, and the rigorous testing and security that safety - critical aviation demands.
Whether the next leg of the journey is shaping a roadmap, modernizing legacy systems or building new services, one thing remains constant: with the right knowledge on board, every flight can find its way safely home to Ithaca.
FAQ regarding FF-ICE:
We’d love to hear about your software project and help you meet your business goals as soon as possible.
