This section aggregates the information exchange requirements and the requirements on the consumption of the NM B2B Services in support of the FF-ICE/R1 information exchanges, to help concerned Stakeholders conform to the applicable CP1 requirements. The conformity checklists captured in the Handbook for ANSPs and the Handbook for AUs then identifies the requirements that need to be satisfied in order for a concerned Stakeholder to achieve a particular objective set by CP1 and the SESAR Deployment Programme.

Status

OUTDATED - superseded by Requirements and guidance

Full table of contents

Click here to expand...

Information Exchange Requirements

Definitions

Term	Definition
Air service	In its broadest sense, includes any service performed by Aircraft for public transportation, whether on a scheduled or non-scheduled basis. [ICAO] A flight or a series of flights carrying passengers, cargo or mail for remuneration or hire. [EU/EC REGULATION No 255/2010]
Airspace users	All aircraft operated as general air traffic. [EU/EC REGULATION No 549/2004]
General air traffic [GAT]	All movements of civil aircraft, as well as all movements of State aircraft (including military, customs and police aircraft) when these movements are carried out in conformity with the procedures of the ICAO. [EU/EC REGULATION No 549/2004]
Scheduled air transport	An Air service open to use by the general public and operated according to a published timetable or with such a regular frequency that it constitutes an easily recognizable systematic series of flights. [ICAO]
Non-scheduled air transport	Any Air service that is performed other than as a Scheduled air service, including but not limited to charter operations. [ICAO]

Clarification of the CP1 mandate

The CP1 regulation states that:

Operational stakeholders must implement services that support the exchange of flight information using the SWIM yellow profile, as specified in the deployment programme:
    (a) related to FF-ICE Release 1 Services:
      - flight plan and routes generation and validation;
      - flight plans, 4D trajectory, flight performance data, flight status;
      - flights lists and detailed flight data;

These statements in CP1 context means:

routes generation and validation: “routes generation” relates to the Expanded Route as described in the FF-ICE/R1 Manual, Appendix E-3. (An expanded route contains every significant point that is in the route. While a Route has only the entry and exit point from each ATS route traversed, the expanded route contains each significant point traversed along each ATS route.). “validation” relates to the outcome of the flight plan validation and is an aspect covered in bullet point 4) Flight Status below.
4D trajectory: this relates to the Trajectory information provided as part of the Route/Trajectory Group, as explained in the FF-ICE/R1 Manual, Appendix E-3.
flight performance data: this relates to the Route/Trajectory Specific Performance Data as described in the FF-ICE/R1 Manual, Chapter 10.3, table 2. It comprises the Aircraft Take-Off Mass, the Performance climb and descent profile and the Climb and descent speed schedule.
Flight status: this relates to the Operator Flight Plan Version and the Filing Status value that are specified in the FF-ICE/R1 Manual, Appendix B-2.14 and B-2.23.2. Note: The term "Flight Status” used in CP1 does NOT refer to Field 18 STS, sometimes called status field, which captures the Reason for special handling by ATS. In FF-ICE, this piece of information is explicitly represented by the Data Item “Special Handling” in Data Category “Flight Characteristics”.
flights lists: the notion of "Flights Lists" is not described in the FF-ICE/R1 Manual. It is therefore considered that this particular wording relates to the use of the GUFI to assist in associating a message to the correct flight and to help in distinguishing between similar flights, as explained in the FF-ICE/R1 Manual, chapter 3.7.1;
detailed flight data: This relates to the eFPL content that is not new compared to what is currently exchanged, i.e. this relates to the flight plan data items already exchanged in FPL 2012 format.

The Information Exchange Requirements below are specified based on this meaning. They supplement the applicable IERs for FF-ICE/R1 that are specified in Appendix B and Appendix C of the FF-ICE/R1 Manual, sometimes making them more stringent.

In the next tables, the following terms and convention are used:

[Clarifications of the terms]

The ‘submitted eFPL’ designates the flight plan information that is provided by an Airspace User to the Network Manager using the FF-ICE Filing Service.
The ‘desired route/trajectory‘ designates the route/trajectory group that is provided by an operator when submitting or updating an eFPL using the FF-ICE Filing Service.
The ‘distributed eFPL’ designates the flight information that is provided by the Network Manager to ANSPs using the FF-ICE Publication Service.
The ‘agreed route/trajectory‘ designates the route/trajectory group that is provided by the Network Manager as an indication of the route/trajectory on record within the IFPS Zone.
The ‘flight (plan) data response’ (resp. ‘flight (status) data response’) designates the flight information that is sent by the Network Manager as a response to a valid Flight Data Request of type “FLIGHT_PLAN” (resp. of type “FLIGHT_STATUS”) made by an ANSP using the FF-ICE Flight Data Request Service.

[Convention]

MUST - indicates an IER that has to be satisfied in order to comply with the CP1 regulatory requirements;
SHOULD - indicates an IER that is recommended in order to maximise the benefits of the implementation;

Applicability & Exemptions

The CP1 requirements related to FF-ICE/R1 concern General Air Traffic [GAT] operating IFR. VFR and OAT operations are exempted.

Unless specified otherwise, the IERs for Airspace Users below apply to all types of IFR operations, including, but not limited to, Air Services (i.e. Scheduled and Non-scheduled air transport operations), General Aviation operations, and Military Flights operating GAT.

The rules under which a flight is operated can change, and an IFR/GAT flight can have VFR or OAT portions. The IERs below about Route/Trajectory are therefore only applicable to the IFR/GAT portions.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

THE FOLLOWING SECTIONS DO NOT REFLECT YET THE LATEST VERSION OF THE ENVISAGED FF-ICE/R1 INFORMATION EXCHANGE REQUIREMENTS.

PLEASE REFER INSTEAD TO THE DRAFT SDP GUIDANCE MATERIALS SHARED FOR STAKEHOLDERS CONSULTATION ON 09-APR-2023.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Information Exchange Requirements for Airspace Users (Filing Service)

Route/Trajectory
FFICE-009	REQ	The desired route/trajectory of the filed eFPL MUST contain an expanded route.
FFICE-010	REQ	For Air Services operated as IFR, the desired route/trajectory () of the submitted eFPL MUST* contain trajectory information with at least: - One Initial Prediction Point; - One End Prediction Point; - Top of Climb (TOC) points for the initial cruising level and every subsequent requested cruising level change after a climb; - One Top of Descent (TOD) point where the trajectory begins a descent from the final (last) cruising level. - Trajectory Change Point – Vertical (TCP-V) points where a level segment (intermediate or cruise) is initiated or terminated.
	REQ	For aircraft operations operated as IFR other than Air Services, the desired route/trajectory () of the submitted eFPL SHOULD* contain trajectory information with at least: - One Initial Prediction Point; - One End Prediction Point; - Top of Climb (TOC) points for the initial cruising level and every subsequent requested cruising level change after a climb; - One Top of Descent (TOD) point where the trajectory begins a descent from the final (last) cruising level. - Trajectory Change Point – Vertical (TCP-V) points where a level segment (intermediate or cruise) is initiated or terminated.
	RATIONALE	A Route/Trajectory is distinguished by the type of route provided, and the type of trajectory information provided. The FF-ICE/R1 Manual, Appendix E-3. Route/Trajectory, outlines five options for the level of details of the route/trajectory information in an eFPL, described as packages: - Package 1A = Route and no trajectory points - Package 1B = Route with selected trajectory points - Package 2A = Expanded Route and no trajectory points - Package 2B = Expanded Route with selected trajectory points - Package 2C = Expanded Route with complete trajectory The exchange of 4D trajectory information is mandated by CP1, and the CP1 wording routes generation is interpreted as relating to the Expanded Route. Therefore, the minimum requirement from a CP1 perspective is that Package 2B (Expanded Route with selected trajectory points) is supported in the submitted eFPL for both Scheduled and Non-scheduled air transport operations when operated as IFR, i.e. for all IFR flights carrying passengers, cargo or mail for remuneration or hire. The selection of trajectory points to be supported compulsorily is based on the minimum trajectory requirements specified in the NM IFPS User Manual R27.0. The exchange of trajectory information is recommended (should) for other types of IFR aircraft operations in order to acknowledge that the information can be either sensitive in the case of Military flights, or not as critical (from a network perspective) for e.g. General Aviation Operations - see also below the rationale for the IERs on the Filing Service / Flight Performance Data.
*Flight Performance Data*
FFICE-011	REQ	The aircraft take-off mass, the performance climb and descent profile and the climb and descent speed schedule MUST be provided in the submitted eFPL for Air Services operated as IFR.
	REQ	The aircraft take-off mass, the performance climb and descent profile and the climb and descent speed schedule SHOULD be provided in the submitted eFPL for aircraft operations operated as IFR other than Air Services.
	RATIONALE	The FF-ICE/R1 Manual, chapter 10.3, recognises that the provision of the performance data items could be done as logical combinations (“aircraft take-off mass with speed schedule” OR “performance profile”). However, the use of all three data items will be highly beneficial in Europe. Therefore, the exchange of the aircraft take-off mass, the performance climb and descent profile and the climb and descent speed schedule is declared mandatory (must) for Scheduled and Non-scheduled air transport operations (operated as IFR). The exchange of these data items is recommended (should) for other types of aircraft operations in order to acknowledge that the information, although nice to have, may be either sensitive for e.g. Military flights, or harder to originate for e.g. General Aviation Operations.
Flight status
FFICE-012	REQ	The operator flight plan version MUST be provided in the submitted eFPL.
	RATIONALE	The term "Flight Status” used in CP1 refers to the Data Category of the same name specified in the FF-ICE/R1 Manual Appendix C, which for the submitted eFPL comprises the Operator flight plan version. Note: The operator flight plan version is already declared mandatory in the submitted eFPL in the FF-ICE/R1 Manual, Appendix C-4.
Flights lists
FFICE-013	REQ	The Globally Unique Flight Identifier (GUFI) MUST be provided in the submitted eFPL.
	RATIONALE	This is to enable the flight / flight plan correlation based on GUFI. Note: The GUFI is already declared mandatory in the submitted eFPL in the FF-ICE/R1 Manual, Appendix C-4.
Detailed flight data
FFICE-014	REQ	The flight data that is mandatory in FPL 2012 format, as prescribed in ICAO Doc 4444 and the IFPS Users Manual, MUST be included in the submitted eFPL.
	RATIONALE	This is to ensure that the submitted eFPL does not miss information compared to its legacy ATS message counterpart. Note: This is specified in FF-ICE/R1 Manual, Appendix C-4.

(*) IFR/GAT portions only

Information Exchange Requirements for Airspace Users (Trial Service)

Airspace users, when testing out alternative trajectories using the Trial Service, are expected to submit Trial Requests with appropriate information, similar in content as the submitted eFPLs.

Information Exchange Requirements for the Network Manager (Data Publication Service)

Route/Trajectory
FFICE-304	REQ	The agreed route/trajectory MUST be provided in the distributed eFPL.
FFICE-305	REQ	The agreed route/trajectory () that is provided in the distributed eFPL MUST* contain an expanded route.
FFICE-306	REQ	The agreed route/trajectory () that is provided in the distributed eFPL MUST* at least contain: - One Initial Prediction Point; - One End Prediction Point; - Top of Climb (TOC) points for the initial cruising level and every subsequent requested cruising level change after a climb; - One Top of Descent (TOD) point where the trajectory begins a descent from the final (last) cruising level. - Trajectory Change Point – Vertical (TCP-V) points where a level segment (intermediate or cruise) is initiated or terminated.
FFICE-307	REQ	The agreed route/trajectory () that is provided in the distributed eFPL MUST* identify, where appropriate, the constraints impacting the desired route/trajectory, if any.
	RATIONALE	The exchange of the agreed route/trajectory as part of the distributed eFPL is mandatory because it is the route/trajectory on record within the IFPS Zone against which the airspace user is recommended to synchronise its own desired route/trajectory. See FF-ICE/R1 Manual, chapter 6.3.5 for further details on the recommendation on the Airspace Users to react to agreed route/trajectories and synchronise their own route/trajectories. Synchronising trajectories is one of the main objectives of trajectory based operations allowing both the operator and the ATM functions to obtain the benefits that improved predictability can provide in terms of flight efficiency and ATM resource management. The requirements on the minimum level of details of the agreed route/trajectory ensures that Package 2B (Expanded Route with selected trajectory points) is always supported in the distributed eFPL for all types of IFR operations, as a minimum requirement. Additionally, the agreed route/trajectory must identify, where appropriate, the constraints (PTRs) impacting the desired trajectory by adding the necessary constraint points and references to the PTR identifiers, where appropriate.
	ASSOCIATED ANSP USE CASES	Use of eFPL Trajectory Instead of RFL Profiles Use of (Expanded) Route Start Points for Trajectory Computation Use of Route/Trajectory Data for ToD/ToC
Flight Performance Data
FFICE-308	REQ	The aircraft take-off mass, the performance climb and descent profile and the climb and descent speed schedule, when provided in the submitted eFPL, MUST be provided in the distributed eFPL.
	RATIONALE	This ensures that all flight performance data specified in the FF-ICE/R1 Manual that is provided to the Network Manager by the Airspace User is also available to the ANSPs.
	ASSOCIATED ANSP USE CASES	Processing of the Performance Profile for Trajectory Computation Aircraft Performance Data for Flight Monitoring Aircraft Performance Data for Traffic Complexity Tool Aircraft Performance Data for MTCD Aircraft Performance Data for Sector Sequence Aircraft Take-off Mass & Speed Schedule for Trajectory Computation Display of the Aircraft Take-off Mass to the ATCO
Flight status
FFICE-309	REQ	The operator flight plan version provided in the submitted eFPL MUST be provided in the distributed eFPL.
FFICE-310	REQ	The Filing Status value MUST be provided whenever the outcome of the flight plan re-evaluation needs to be exchanged, in line with the rules of the IFPS Users Manual.
	RATIONALE	The exchange of the operator flight plan version (which in FF-ICE belongs to the Data Category Flight Status) is mandatory (must) in the distributed eFPL, in so far as the knowledge by ANSPs of this piece of information is essential in order to guarantee that only the most recent and up-to-date flight plan data is used. The requirement on the exchange of the Filing Status aims to ensure that ANSPs are duly informed of a change of eFPL status, in line with the rules of the IFPS Users Manual, chapter 20.
	ASSOCIATED ANSP USE CASES	Management of Operator Flight Plan Version Display of the Operator Flight Plan Version to the ATCO
Flights lists
FFICE-311	REQ	The Globally Unique Flight Identifier (GUFI) MUST be provided in the distributed eFPL.
	RATIONALE	This is to allow the flight / flight plan identification based on GUFI.
	ASSOCIATED ANSP USE CASES	Use of GUFI for FF-ICE Message Association FF-ICE Message Received with Unknown GUFI
Detailed flight data
FFICE-312	REQ	The flight data that is mandatory in FPL 2012 format, as prescribed in ICAO Doc 4444 and the IFPS Users Manual, MUST be included in the distributed eFPL.
	RATIONALE	This is to ensure that the distributed eFPL does not miss information compared to what is currently distributed to ANSPs.

(*) IFR/GAT portions only

Information Exchange Requirements for the Network Manager (Flight Data Request Service)

Route/Trajectory
FFICE-105	REQ	The agreed route/trajectory MUST be provided in the flight (plan) data response.
FFICE-106	REQ	The agreed route/trajectory () that is provided in the flight (plan) data response MUST* have the same content as the agreed route/trajectory provided in the distributed eFPL.
	RATIONALE	The requirements aim to ensure that the route/trajectory information provided to ANSPs upon request via the Flight Data Request Service is similar content-wise to the route/trajectory information pushed to ANSPs via the Publication Service. The exchange of the agreed route/trajectory as part of the flight (plan) data response is mandatory because it is the route/trajectory on record within the IFPS Zone against which the airspace user is recommended to synchronise its own desired route/trajectory.
Flight Performance Data
FFICE-107	REQ	The aircraft take-off mass, the performance climb and descent profile and the climb and descent speed schedule, when provided in the submitted eFPL, MUST be provided in the flight (plan) data response.
	RATIONALE	The requirements aim to ensure that the flight performance data provided to ANSPs upon request via the Flight Data Request Service is similar content-wise to the flight performance data pushed to ANSPs via the Publication Service.
Flight status
FFICE-108	REQ	The operator flight plan version provided in the submitted eFPL MUST be provided in the flight (status) data response.
FFICE-109	REQ	The Filing Status value MUST be provided in the flight (status) data response.
	RATIONALE	Plausibility - The response to a valid Flight Data Request of type “FLIGHT_STATUS” has to contain flight status information.
Flights lists
FFICE-110	REQ	The Globally Unique Flight Identifier (GUFI) MUST be provided in the flight (plan) data response and flight (status) data response.
	RATIONALE	The requirement aims to ensure that the data provided to ANSPs upon request via the Flight Data Request Service is similar content-wise to the data pushed to ANSPs via the Publication Service.
Detailed flight data
FFICE-111	REQ	The flight data that is mandatory in FPL 2012 format, as prescribed in ICAO Doc 4444 and the IFPS Users Manual, MUST be included in the flight (plan) data response.
	RATIONALE	The requirement aims to ensure that the data provided to ANSPs upon request via the Flight Data Request Service is similar content-wise to the data pushed to ANSPs via the Publication Service.

(*) IFR/GAT portions only

Information Exchange Requirements for ANSPs (Notification Service)

No specific IER beyond the applicable ones specified in Appendix B and Appendix C of the FF-ICE/R1 Manual.

Summary Tables for the eFPL content

FF-ICE Data item presence in the submitted eFPL

The table below provides a recap of the rules on the presence of fields for the submitted eFPL. The table should be read as follows:

Columns 1 and 2 contains the name of the Data Category and Data Item as listed in ICAO Doc 9965 Ed2 Volume 2 (the FF-ICE/R1 Implementation Guidance Manual), chapter C-4 Filed Flight Plan. A data item displayed in italic is an FF-ICE data item that is specific to Europe.
- Use of symbol indicates that the FF-ICE Data Item is new in the eFPL compared to the legacy FPL content.
Columns 3 to 7 describe the rules on the presence of the FF-ICE Data Item in the submitted eFPL.
- Column 3 indicates whether the data item is declared Mandatory (M) or Optional (O) in the message template for the filed flight plan provided by FIXM's FF-ICE Message Application 1.1.0, which generally reflect the rules on the presence of fields from ICAO Doc 9965 Ed2 Volume 2, Appendix C.
- Column 4 indicates whether the data item is considered mandatory (M) as per CP1. Use of the character "-" indicates that CP1 does not specify any rule for that item.
- Column 5 indicates whether the data item is considered Mandatory (M), Optional (O), forbidden (F), or not needed by NM. Use of the character "-" indicates that no rules are specified on top of what FIXM specifies.
- Column 6 indicates whether the data item is considered Mandatory (M) from the perspective given OUTDATED - Use cases (ANSPs).
- Column 7 provides the aggregated rule on the presence of the data item, which corresponds to the most stringent of the FIXM, CP1, NM and Use Cases rules.
Column 8 provides an indication whether the data item is supported by the current NM systems, based on the NM B2B R27 documentation. Use of symbol means that the data item is supported by the NM B2B R27 Filing Service. Use of symbol indicates that data item is either partly supported (e.g. can be received but cannot be processed yet) or not supported.
Column 9 may capture additional notes in relation to the requirements on the data item presence, such as the justification for a particular CP1 requirement that is more stringent than what ICAO specifies.

Data Category	Data Item	From FIXM	From EU CP1	From NM B2B	Aggregated Requirement	NM R27 Capabilities	Notes / Justifications
Content of the filed eFPL		Requirements on Data Item presence in the filed eFPL
Message Information	List of Recipients	O	-	Not needed	Not needed		The FIXM template leaves these fields optional, even though they are described as mandatory in ICAO Doc 9965 Ed2 Volume 2 Appendix C-4, to allow these fields to be absent from the XML body of the FF-ICE message if they can be exchanged/retrieved through other means, as is the case in the NM B2B implementation.
	Message Originator	O	-	Not needed	Not needed
	Request for Translation and Delivery	O	-	Not needed	Not needed		This item identifies the eASP that has been requested to translate and deliver the Flight Plan to identified Requested Recipients. In the context of the European implementation of FF-ICE, this eASP is always NM. The information is therefore implicit and the field is irrelevant.
	Requested Recipients	O	-	-	O		This implements the (IFPS Users Manual) Re-addressing Function.
	Request for Forwarding	O	-	Not needed	Not needed		This item identifies the eASP that is requested to forward the Flight Plan to all Relevant ASPs. In the context of the European implementation of FF-ICE, this eASP is always NM. The information is therefore implicit and the field does not need to be provided.
	Relevant ASPs	M	-		M
	Message Date-Time	O	-	Not needed	Not needed		See Notes above for "Message Originator"
	Message Identifier	O	-	M	M
	Type of Request/Response	O	-	M	M
	AFTN Address	O	-	-	-	?
	Contact Information	O O	-	Not needed	Not needed		The NM B2B services implements an authentication mechanism (using digital certificates – PKI) which makes the exchange of contact information about the sender not needed as part of the FF-ICE Message.
Flight Identification	GUFI	M	M	-	M		See REQ FF-ICE-013
Flight Identification	Aircraft Identification	M	M	M	M		See REQ FFICE-014
Flight Status	Operator Flight Plan Version	M	M	-	M		See REQ FFICE-012
Flight Characteristics	Flight Rules	M	M	-	M		See REQ FFICE-014
	Type of Flight	O	M	M	M		See REQ FFICE-014
	Special Handling	O	-	-	O
	Flight Plan Originator	O	-	-	O
	Remarks	O	-	-	O
	Operator	O	-	-	O
	Equipment and Capabilities	M	M	-	M		See REQ FFICE-014
	Supplementary Information Source	O	-	-	O
	Required Runway Visual Range	O	-	-	O
	EUR Special Handling	N/A	-	O	O
Aircraft Characteristics	Total number of aircraft	O	-	-	O
	Registration	O	-	-	O
	Aircraft Address	O	-	-	O
	SELCAL Code	O	-	-	O
	Mode A Code	O	-	-	O
	Number and type of aircraft	M	M	-	M		See REQ FFICE-014
	Wake Turbulence Category	M	M	-	M		See REQ FFICE-014
	Aircraft Approach Category	O	-	-	O
Departure/Destination Data	Departure Aerodrome	M	M		M		See REQ FFICE-014
	Destination Aerodrome	M	M		M		See REQ FFICE-014
	Estimated Off-Block Time	M	M		M		See REQ FFICE-014
	Departure Airport Slot Identification	O	-	-	O
	Destination Airport Slot Identification	O	-	-	O
	Departure Runway	O	-	-	O
	Destination Runway	O	-	-	O
Alternates	Alternate Destination Aerodrome(s)	O	-	-	O
	Alternate Take-Off Aerodrome(s)	O	-	-	O
	Alternate En-Route Aerodrome(s)	O	-	-	O
Desired Route/Trajectory		M	-	-	M
Route/Traj. Group	Aircraft Take-off Mass	O	M (Cond)	-	M (Cond)		See REQ FFICE-011
	Requested Cruising Speed	M	M	-	M		See REQ FFICE-014
	Requested Cruising Level	M	M	-	M		See REQ FFICE-014
	Total Estimated Elapsed Time	O	M	M	M		See REQ FFICE-014
	General Flight Constraint	O	-	F	F	N/A
Route/Traj. Element		M (2+)	M (2+)	M (2+)	M (2+)		See REQ FFICE-009
	Along Route Distance	O	-	M	M
	Route Element Start Point	M	-	-	M
	Route to Next Element	O	-	-	O		The ICAO FF-ICE/R1 Manual states that the field is required on each element, except when the element is the last point of the route.
	Route Truncation Indicator	O	-	-	O
	Requested Change	O	-	-	O
	Route/Trajectory Constraints	O	-	F	F	N/A
	Trajectory Point	O	M (Cond)	-	M (Cond)		See REQ FFICE-010
	Geo Position	M	-	-	M
	Time	M	-	-	M
	Level	M	-	-	M
	Predicted Airspeed	O	-	-	M
	Predicted Ground Speed	O	-	-	M
	Wind Vector	O O O	- - -	M M M	M M M
	Assumed Altimeter Setting	O	-	-	O
	Temperature	O O	-	M M	M M
	Trajectory Point Property	O M O O	M (Cond) - - -	- - - -	M (Cond) M O O		See REQ FFICE-010
	Planned Delay	O	-	-	O
	Weight at Point	N/A	O	O	O
Route/Traj. Aircraft Performance	Performance Profile	O O M (1+) O M M M M	M (Cond) M (Cond) - - - - - -	- - M (3+) - - - - -	M (Cond) M (Cond) M (3+) O M M M M		See REQ FFICE-011
Route/Traj. Aircraft Performance	Speed Schedule	O O M M	M (Cond) M (Cond) - -	- - - -	M (Cond) M (Cond) M M		See REQ FFICE-011
Route to Revised Destination	Revised Destination	O	-	-	O
Route to Revised Destination	Route String to Revised Destination	O	-	-	O
Dangerous Goods	Dangerous Goods Information	O	-	-	O
AIRAC	AIRAC Reference	O	-	-	O
Supplementary Information	Fuel Endurance	O	-	-	O
	Persons on Board	O	-	-	O
	Emergency Radio	O	-	-	O
	Survival Capability	O	-	-	O
	Life Jacket Characteristics	O	-	-	O
	Aircraft Colour and Markings	O	-	-	O
	Pilot in Command	O	-	-	O
	Dinghies	O	-	-	O
	Remarks	O	-	-	O
Other European Items	Stay Information	N/A	-	O	O
	EUR Special Handling	N/A	-	O	O

FF-ICE Data item presence in the distributed eFPL (Summary table)

The table below provides a recap of the rules on the presence of fields for the distributed eFPL (i.e. the eFPL sent by NM to ANSPs). The table follows the same conventions as the previous table and can be read in a similar manner.

The distributed eFPL is sent by NM to ANSPs using the FF-ICE Publication Service. ICAO Doc 9965 Ed2 Volume 2 does NOT specify the FF-ICE Messages exchanged by this Publication Service. As a result:

no tabular description of the distributed eFPL can be found in Appendix C of ICAO Doc 9965 Ed2 Volume 2. The table shown below is however inspired by ICAO Doc 9965 Ed2 Volume 2, chapters C-4 Filed Flight Plan and C-5 Filing Status, with altogether provides a good baseline for outlining the content of the distributed eFPL.
no XML message template exists in the FIXM "FF-ICE Message" Application 1.1.0 that can support the exchange of the distributed eFPL. The NM B2B Publication Services actually exchanges the distributed eFPL using a message named “FficePublicationMessage”, which is a bespoke NM B2B message. This message, however, still uses FIXM Core 4.3.0 for the representation of the flight data. It should be noted that all flight data items in FIXM Core 4.3.0 are declared optional. Therefore, for readability purpose, the column "From FIXM" outlining the requirements on the presence of fields is not shown in the table below.

Data Category	Data Item	Mandatory in filed eFPL?	From EU CP1	Aggregated Requirements	Notes / Justifications
Content of the distributed eFPL			Requirements on Data Item presence in the distributed eFPL
Flight Identification	GUFI	Yes	M	M	See REQ FFICE-311
Flight Identification	Aircraft Identification	Yes	-	M	See REQ FFICE-312
Flight Status	Operator Flight Plan Version	Yes	M	M	See REQ FFICE-309
light Characteristics	Flight Rules	Yes	M	M	See REQ FFICE-312
	Type of Flight	Yes	M	M	See REQ FFICE-312
	Special Handling	No	-	O
	Flight Plan Originator	No	-	O
	Remarks	No	-	O
	Operator	No	-	O
	Equipment and Capabilities	Yes	M	M	See REQ FFICE-312
	Supplementary Information Source	No	-	O
	Required Runway Visual Range	No	-	O
Aircraft Characteristics	Total number of aircraft	No	-	O
	Registration	No	-	O
	Aircraft Address	No	-	O
	SELCAL Code	No	-	O
	Mode A Code	No	-	O
	Number and type of aircraft	Yes	M	M	See REQ FFICE-312
	Wake Turbulence Category	Yes	M	M	See REQ FFICE-312
	Aircraft Approach Category	No	-	O
Departure/Destination Data	Departure Aerodrome	Yes	M	M	See REQ FFICE-312
	Destination Aerodrome	Yes	M	M	See REQ FFICE-312
	Estimated Off-Block Time	Yes	M	M	See REQ FFICE-312
	Departure Airport Slot Identification	No	-	O
	Destination Airport Slot Identification	No	-	O
	Departure Runway	No	-	O
	Destination Runway	No	-	O
Alternates	Alternate Destination Aerodrome(s)	No	-	O
	Alternate Take-Off Aerodrome(s)	No	-	O
	Alternate En-Route Aerodrome(s)	No	-	O
Agreed Route/Trajectory		N/A	M	M	See REQ FFICE-304
Route/Traj. Group	Aircraft Take-off Mass	Yes	M (Cond)	M (Cond)	See REQ FFICE-308
	Requested Cruising Speed	Yes	-	M	See REQ FFICE-312
	Requested Cruising Level	Yes	-	M	See REQ FFICE-312
	Total Estimated Elapsed Time	Yes	-	M	See REQ FFICE-312
	General Flight Constraint	No	-	TBD
Route/Traj. Element		Yes	M (2+)	M (2+)
	Along Route Distance	Yes	-	M
	Route Element Start Point	Yes	-	M
	Route to Next Element	No	-	O	Required on each element, except when the element is the last point of the route.
	Modified Route Indicator	No	-	O
	Route Truncation Indicator	No	-	O
	Requested Change	No	-	O
	Route/Trajectory Constraints	No	-	TBD
	Trajectory Point	Yes (Cond)	M	M	See REQ FFICE-306
	Geo Position	Yes	-	M
	Time	Yes	-	M
	Level	Yes	-	M
	Predicted Airspeed	Yes	-	O
	Predicted Ground Speed	Yes	-	O
	Wind Vector	Yes Yes Yes	- - -	TBD TBD TBD
	Assumed Altimeter Setting	No	-	O
	Temperature	Yes Yes	- -	TBD TBD
	Trajectory Point Property	Yes (Cond) Yes - -	M - - -	M M O O	See REQ FFICE-306
	Planned Delay	No	-	O
	Weight at Point	No	-	O
Route/Traj. Aircraft Performance	Performance Profile	Yes Yes Yes No Yes Yes Yes Yes	M (Cond) M (Cond) - - - - - -	M (Cond) M (Cond) M (3+) O M M M M	See REQ FFICE-308
Route/Traj. Aircraft Performance	Speed Schedule	Yes Yes Yes Yes	M (Cond) M (Cond) - -	M (Cond) M (Cond) M M	See REQ FFICE-308
Route to Revised Destination	Revised Destination	No	-	O
Route to Revised Destination	Route String to Revised Destination	No	-	O
Dangerous Goods	Dangerous Goods Information	No	-	O
AIRAC	AIRAC Reference	No	-	O
Supplementary Information	Fuel Endurance	No	-	O
	Persons on Board	No	-	O
	Emergency Radio	No	-	O
	Survival Capability	No	-	O
	Life Jacket Characteristics	No	-	O
	Aircraft Colour and Markings	No	-	O
	Pilot in Command	No	-	O
	Dinghies	No	-	O
	Remarks	No	-	O
Other European Items	Route Text	N/A	-	O
	Ifps Identifier	N/A	-	O
	Stay Information	No	-	O
	AO What-If ReRoute Indicator	N/A	-	O
	Replacement Flight Plan Indicator	N/A	-	O

Other requirements

Requirements on the connection to NM B2B Services

FFICE-REQ-001 - Signature of an agreement with NM

Title	Signature of an agreement with NM
Identifier	FFICE-REQ-001
Stakeholders	ANSP, AU
Requirement	The Stakeholder MUST sign an agreement with NM in order to be able to consume the NM B2B Services.
Rationale	Access to the NM B2B Services is subject to eligibility and usage conditions.
CP1 Mandate
Notes
Guidance	First check internally whether your organisation is already using the NM B2B Services. Depending on whether your organization is already using the NM B2B Services or not, you may apply for initial or additional access. The form for requesting access to NM B2B services can be found at: https://www.eurocontrol.int/network-operations/access-service-request-form

FFICE-REQ-002 - Access request to NM B2B Filing service

Title	Access request to NM B2B Filing service
Identifier	FFICE-REQ-002
Stakeholders	AU
Requirement	The Stakeholder MUST request access to the NM B2B Filing Service.
Rationale	Access to this NM B2B service is necessary for Stakeholders seeking to consume the FF-ICE Filing service provided by NM. See FF-ICE in the NM B2B for details.
CP1 Mandate
Notes
Guidance

FFICE-REQ-003 - Access request to NM B2B Trial service

Title	Access request to NM B2B Trial service
Identifier	FFICE-REQ-003
Stakeholders	AU
Requirement	The Stakeholder SHOULD request access to the NM B2B Trial Service.
Rationale	Access to this NM B2B service is necessary for Stakeholders seeking to consume the FF-ICE Trial service provided by NM. See FF-ICE in the NM B2B for details.
CP1 Mandate
Notes
Guidance

FFICE-REQ-004 - Access request to NM B2B Flight Data Request service

Title	Access request to NM B2B Flight Data Request service
Identifier	FFICE-REQ-004
Stakeholders	ANSP, AU
Requirement	The Stakeholder MUST request access to the NM B2B Flight Data Request service.
Rationale	Access to the NM B2B Flight Data Request service is necessary for Stakeholders seeking to consume the FF-ICE Flight Data Request service provided by NM. Access to the NM B2B Flight Data Request service may be necessary for Stakeholders seeking to consume the FF-ICE Filing service provided by NM. See FF-ICE in the NM B2B for details.
CP1 Mandate
Notes
Guidance

FFICE-REQ-005 - Access request to NM B2B Notification service

Title	Access request to NM B2B Notification service
Identifier	FFICE-REQ-005
Stakeholders	ANSP
Requirement	The Stakeholder MUST request access to the NM B2B Notification service.
Rationale	Access to this NM B2B service is necessary for Stakeholders seeking to consume the FF-ICE Notification service provided by NM. See FF-ICE in the NM B2B for details.
CP1 Mandate
Notes
Guidance

FFICE-REQ-006 - Access request to NM B2B Publication Service

Title	Access request to NM B2B Publication service
Identifier	FFICE-REQ-006
Stakeholders	ANSP
Requirement	The Stakeholder MUST request access to the NM B2B Flight Management service.
Rationale	Access to NM B2B Publication Service service is necessary for Stakeholders seeking to consume the FF-ICE Data Publication service provided by NM. See FF-ICE in the NM B2B for details.
CP1 Mandate
Notes
Guidance	Fill in the form as follows: ...

Requirements on the management of subscriptions to FF-ICE information

FFICE-REQ-007 - Subscription to relevant eFPLs

Title	Subscription to relevant eFPLs and associated changes
Identifier	FFICE-REQ-007
Stakeholders	ANSP
Requirement	The Stakeholder MUST manage its subscriptions appropriately using the NM B2B Publication Service so that it receives all relevant eFPLs filed by the eAUs and accepted by NM, as well as any subsequent changes to the ePFLs acceptance status.
Rationale
CP1 Mandate
Notes	This replaces the current reception of FP messages (IFPL, ICHG...) through AFTN. It materialises the paradigm shift from a provider-driven "push" of legacy IFPL/ICHG messages to consumer-driven subscriptions to eFPLs & subsequent changes.
Guidance	See NM B2B documentation

FFICE-REQ-008 - Subscription to relevant notifications of departure and arrival

Title	Subscription to relevant notifications of departure and arrival
Identifier	FFICE-REQ-008
Stakeholders	ANSP
Requirement	The Stakeholder SHALL manage its subscriptions appropriately using the NM B2B Subscription Management so that it receives all the notifications of departure and arrivals relevant to their operations.
Rationale
CP1 Mandate
Notes
Guidance	See NM B2B documentation

Requirements on the development, testing and validation of NM B2B client applications

FFICE-REQ-xxx - Development based on latest NM B2B release

Title	Development based on latest NM B2B release
Identifier	FFICE-REQ-xxx
Stakeholders	AU, ANSP, ARO
Requirement	The Stakeholder MUST consider the latest NM B2B release available at the start of their B2B client application development.
Rationale	NM has been deploying new releases of its software on a regular basis. Since 2018, each new release has gradually incorporated new or enhanced FF-ICE-related capabilities. Starting the development of a client application based on the latest release of the NM B2B guarantees that these development are based on the most up-to-date implementation of FF-ICE services by NM.
CP1 Mandate
Notes
Guidance

FFICE-REQ-xxx - Development and testing in PRE-OPS

Title	Development and testing in PRE-OPS
Identifier	FFICE-REQ-xxx
Stakeholders	AU, ANSP, ARO
Requirement	The Stakeholder MUST develop and test its B2B client application supporting FF-ICE/R1 exchanges using the PREOPS platform.
Rationale	NM deploys the NM B2B services on distinct platforms with distinct purposes, enabled services, data and access. The main purpose of the PREOPS platform is to support the development and testing of B2B client applications without impacting the operations. This platform is also used to validate the correct behaviour of client applications and to assess their readiness to be connected to the Operational platform.
CP1 Mandate
Notes
Guidance

FFICE-REQ-xxx - Validation for OPS usage

Title	Validation for OPS usage
Identifier	FFICE-REQ-xxx
Stakeholders	AU, ANSP, ARO
Requirement	The Stakeholder having performed the necessary developments and tests in PREOPS MUST get their client application validated by NM for OPS usage.
Rationale	The operational use of the B2B Services will be allowed only after the Stakeholder has successfully executed the NM acceptance validation processes. This process is established in order to make sure that only client applications with correct behaviour use the operational system.
CP1 Mandate
Notes
Guidance	Any official request to apply the present procedure shall be officially addressed to the NM email address: NM.servicerequests@eurocontrol.int The evaluation will be based on the test case "EFPL FILING (FIXM FORMAT) – TEST CASES" described in NM B2B's Business documentation for Flight Plan Filing More details: https://ost.eurocontrol.int/sites/B2BWS/Shared%20Documents/7%20-%20Business%20Documentation/Flight%20Plan%20Filing%20Use%20Cases.pdf Supporting materials Browse the presentation "NM B2B Operational Validation" presented to FPFDE TF#12 Text below adapted from FPFDE TF#12 minutes of meeting, chapter 5.1 This presentation covers the operational acceptance validation process for WRITE service. This process is approved by EASA. The FF-ICE services (eFPL Filing - including update and cancellation, and Notification) are part of this category. The first step is to request a NM B2B PREOPS certificate with the “FF-ICE” profile. Before running the validation process activities, the user has to provide Use Cases in order to update the PREOPS certificate profile accordingly. The Client application has to be fully ready for the validation (no last-minute bug fixing for example). A READ validation will be required prior to every Operational Acceptance Validation: A testing period of 10 days is required during which the user will run the client application on PREOPS in a nominal manner (i.e. as intended to be used in OPS). Once the 10 days period is completed, different aspects will be evaluated, such as the consistency with the Use Cases, the number of requests and data volumes per service, errors and overload events, etc. Once the READ validation is passed, the next step is the Operational Validation for WRITE services. This consists of technical and operational validations on PREOPS, both being scheduled and organised as sessions of approximatively 1 hour. The NM B2B WRITE Operational Validation is an interactive Teams session where both sides are sharing their screens and participate in the tests. It consists mostly in running the Use Cases provided by NM and the User that reflect the future usage on OPS. The entire duration of the Validation process (READ and WRITE validations) will last around 3 months (without considering the request of the PREOPS certificate). If the validation is successfully passed, the user will receive an OPS certificate. NM will monitor the user’s OPS activity during several months.

Click here to expand...

WORKING MATERIALS / WORKING AREA - IGNORE

-

Title
Identifier	FFICE-REQ-xxx
Stakeholders
Requirement
Rationale
Verification
Notes
Guidance

-

FFICE-REQ-xxx - Provision of weight information in the filed eFPL

Title	Provision of weight information in the filed eFPL
Identifier	FFICE-REQ-xxx
Requirement	The Stakeholder should provide weight information in the filed eFPL.
Rationale
Verification
Notes
Guidance

FFICE-REQ-xxx - Provision of SID and STAR information in the filed eFPL

Title	Provision of SID and STAR information in the filed eFPL
Identifier	FFICE-REQ-xxx
Requirement	The Stakeholder should SID and STAR information in the filed eFPL.
Rationale
Verification
Notes
Guidance	Copied from FPFDE TF#9 Minutes of meeting, chapter 5.1 The following guidelines are proposed [ ... ]: SIDs and STARs should be included in eFPLs as published within the corresponding national AIPs, including the list of points that compose the SID/STAR and the SID/STAR designator. Departure/arrival Transitions and/or approach procedures (including any corresponding published points), should not be included in eFPLs. This is pending feedback from the ICAO IFPP panel on transition routes. The trajectory segment between the Initial Approach Fix (the last point of the STAR) and the destination aerodrome may be included in an eFPL trajectory as the last segment of the STAR. The Along Route Distance provided for the aerodrome of destination may include the length of an approach procedure that is used internally for the flight trajectory calculation by the eFPL originator system (virtual distance).

FFICE-REQ-xxx - Provision of xxx information in the filed eFPL

Placeholder - TODO

FFICE-REQ-xxx - Use of aircraft operator flight plan version

Title	Use of Aircraft Operator Flight Plan version
Identifier	FFICE-REQ-xxx
Stakeholders
Requirement	The Stakeholder MUST use the Aircraft Operator Flight Plan version when the need arises for ATC and the crew to verify that they are using the same version of a flight plan.
Rationale
CP1 Mandate
Notes	See also FF-ICE/R1 Implementation Guidance Manual, chapter 3.8 VERSIONING & REFERENCE INFORMATION See also IPFS Users Manual, chapter C.6
Guidance	Example of usages

x

FFICE-REQ-xxx - Use of the Performance profile

Title	Use of the performance profile of the eFPL
Identifier	FFICE-REQ-xxx
Stakeholders
Requirement	The Stakeholder SHOULD use the performance profile of the eFPL as a replacement of any theoretical cruise / descent performance model when doing trajectory computation.
Rationale
CP1 Mandate
Notes
Guidance	Example of usages

FFICE-REQ-xxx - Use of the take-off mass

Title	Use of the take-off mass
Identifier	FFICE-REQ-xxx
Stakeholders
Requirement	The Stakeholder SHOULD use the estimated take-off mass of the eFPL as a replacement of any estimated take-off mass model when doing trajectory computation based on the eFPL.
Rationale
CP1 Mandate
Notes
Guidance

FFICE-REQ-xxx - Use of selected trajectory point information

Title	Use of selected trajectory point information
Identifier	FFICE-REQ-xxx
Stakeholders
Requirement	TODO
Rationale
CP1 Mandate
Notes
Guidance

x

===========================

Requirements on the usage of the FF-ICE information

The requirements on the usage of the FF-ICE information will be gradually derived from the work on the USE CASES.

FFICE-REQ-xxx - Use of GUFI for FF-ICE messages correlation

Title	Use of GUFI for FF-ICE messages correlation
Identifier	FFICE-REQ-xxx
Stakeholders	AU, NM, ANSP
Requirement	The Stakeholder MUST use the GUFI as the primary means to correlate FF-ICE messages.
Rationale	The Global Unique Flight Identifier (GUFI) is intended to provide a unique reference to a specific flight, civil or military. Its purpose is to assist in associating a message to the correct flight and to help in distinguishing between similar flights. [ ... ] In addition [ ... ], the GUFI will also assist in distinguishing between different flight plans e.g., answering the question “do these two flight plans concern one flight or two different flights?” extracts from FF-ICE/R1 Implementation Guidance Manual, chapter 3.7.1
CP1 Mandate
Notes	See FF-ICE/R1 Implementation Guidance Manual, chapter 3.7 GUFI & FLIGHT PLAN ASSOCIATION
Guidance

FFICE-REQ-xxx - Check of GUFI uniqueness

Title	Check of GUFI uniqueness
Identifier	FFICE-REQ-xxx
Stakeholders	AU, NM
Requirement	The Stakeholder MUST check the uniqueness of the GUFI.
Rationale
CP1 Mandate
Notes	See FF-ICE/R1 Implementation Guidance Manual, chapter 3.7 GUFI & FLIGHT PLAN ASSOCIATION
Guidance

Click here to expand...

WORK AREA - PLEASE IGNORE

Data Category	Data Item	Data Item Representation
Content of the distributed eFPL
Flight Identification	GUFI	fx:GufiChoiceType:gufi
Flight Identification	Aircraft Identification
Flight Status	Operator Flight Plan Version	nm:FficePublicationMessage:operatorFlightPlanVersion_v4_3
	Revalidation Status	nm:RevalidationInformation:revalidationStatus
	Revalidation Status Explanation	nm:RevalidationInformation:revalidationErrors
Flight Characteristics	Flight Rules
	Type of Flight
	Special Handling
	Flight Plan Originator
	Remarks
	Operator
	Equipment and Capabilities
	Supplementary Information Source
	Required Runway Visual Range
Aircraft Characteristics	Total number of aircraft
	Registration
	Aircraft Address
	SELCAL Code
	Mode A Code
	Number and type of aircraft
	Wake Turbulence Category
	Aircraft Approach Category
Departure/Destination Data	Departure Aerodrome
	Destination Aerodrome
	Estimated Off-Block Time
	Departure Airport Slot Identification	fx:DepartureType:airportSlotIdentification
	Destination Airport Slot Identification	fx:ArrivalType:airportSlotIdentification
	Departure Runway	fx:DepartureType:runwayDirection
	Destination Runway	fx:ArrivalType:runwayDirection
Alternates	Alternate Destination Aerodrome(s)
	Alternate Take-Off Aerodrome(s)
	Alternate En-Route Aerodrome(s)
Desired Route/Trajectory		fx:RouteTrajectoryGroupContainerType:desired
Agreed Route/Trajectory		fx:RouteTrajectoryGroupContainerType:agreed
Route/Traj. Group	Aircraft Take-off Mass	fx:RouteTrajectoryGroupType:takeoffMass
	Requested Cruising Speed
	Requested Cruising Level
	Total Estimated Elapsed Time
	General Flight Constraint	fx:FlightType:flightConstraint
Route/Traj. Element		fx:RouteTrajectoryGroupType:element
	Along Route Distance	fx:RouteTrajectoryElementType:alongRouteDistance
	Route Element Start Point
	Route to Next Element
	Modified Route Indicator
	Route Truncation Indicator	fx:RouteTrajectoryElementType:routeTruncationIndicator
	Requested Change
	Route/Trajectory Constraints	fx:RouteTrajectoryElementType:constraint
	Trajectory Point	fx:RouteTrajectoryElementType:point4D
	Geo Position	fx:TrajectoryPoint4DType:position
	Time	fx:TrajectoryPoint4DType:time
	Level	fx:TrajectoryPoint4DType:level
	Predicted Airspeed	fx:TrajectoryPoint4DType:predictedAirspeed
	Predicted Ground Speed	fx:TrajectoryPoint4DType:predictedGroundspeed
	Wind Vector	fx:TrajectoryPoint4DType:metData fx:MeterorologicalDataType:windDirection fx:MeterorologicalDataType:windSpeed
	Assumed Altimeter Setting	fx:TrajectoryPoint4DType:altimeterSetting
	Temperature	fx:TrajectoryPoint4DType:metData fx:MeterorologicalDataType:temperature
	Trajectory Point Property	fx:TrajectoryPoint4DType:pointProperty fx:TrajectoryPointPropertyType:propertyType fx:TrajectoryPointPropertyType:description fx:TrajectoryPointPropertyType:reference ...
	Planned Delay
	Weight at Point	nm:NmRouteTrajectoryElementExtensionType:weight
Route/Traj. Aircraft Performance	Performance Profile	fx:RouteTrajectoryGroupType:climbProfile fx:RouteTrajectoryGroupType:descentProfile fx:PerformanceProfileType:profilePoint fx:ProfilePointType:airspeed fx:ProfilePointType:distance fx:ProfilePointType:level fx:ProfilePointType:seqNum fx:ProfilePointType:time
Route/Traj. Aircraft Performance	Speed Schedule	fx:RouteTrajectoryGroupType:climbSchedule fx:RouteTrajectoryGroupType:descentSchedule fx:SpeedScheduleType:initialSpeed fx:SpeedScheduleType:subsequentSpeed
Route to Revised Destination	Revised Destination
Route to Revised Destination	Route String to Revised Destination
Dangerous Goods	Dangerous Goods Information	fx:FlightType:dangerousGoods
AIRAC	AIRAC Reference	fx:FlightRouteInformation:airacReference
Supplementary Information	Fuel Endurance
	Persons on Board
	Emergency Radio
	Survival Capability
	Life Jacket Characteristics
	Aircraft Colour and Markings
	Pilot in Command
	Dinghies
	Remarks
Other European Items	Route Text
	Ifps Identifier
	Stay Information
	AO What-If ReRoute Indicator
	Replacement Flight Plan Indicator

Data Category	Data Item	Data Item Representation
Content of the distributed eFPL
Flight Identification	GUFI	fx:GufiChoiceType:gufi
Flight Identification	Aircraft Identification
Flight Status	Operator Flight Plan Version	nm:FficePublicationMessage:operatorFlightPlanVersion_v4_3
	Revalidation Status	nm:RevalidationInformation:revalidationStatus
	Revalidation Status Explanation	nm:RevalidationInformation:revalidationErrors
Flight Characteristics	Flight Rules
	Type of Flight
	Special Handling
	Flight Plan Originator
	Remarks
	Operator
	Equipment and Capabilities
	Supplementary Information Source
	Required Runway Visual Range
Aircraft Characteristics	Total number of aircraft
	Registration
	Aircraft Address
	SELCAL Code
	Mode A Code
	Number and type of aircraft
	Wake Turbulence Category
	Aircraft Approach Category
Departure/Destination Data	Departure Aerodrome
	Destination Aerodrome
	Estimated Off-Block Time
	Departure Airport Slot Identification	fx:DepartureType:airportSlotIdentification
	Destination Airport Slot Identification	fx:ArrivalType:airportSlotIdentification
	Departure Runway	fx:DepartureType:runwayDirection
	Destination Runway	fx:ArrivalType:runwayDirection
Alternates	Alternate Destination Aerodrome(s)
	Alternate Take-Off Aerodrome(s)
	Alternate En-Route Aerodrome(s)
Desired Route/Trajectory		fx:RouteTrajectoryGroupContainerType:desired
Agreed Route/Trajectory		fx:RouteTrajectoryGroupContainerType:agreed
Route/Traj. Group	Aircraft Take-off Mass	fx:RouteTrajectoryGroupType:takeoffMass
	Requested Cruising Speed
	Requested Cruising Level
	Total Estimated Elapsed Time
	General Flight Constraint	fx:FlightType:flightConstraint
Route/Traj. Element		fx:RouteTrajectoryGroupType:element
	Along Route Distance	fx:RouteTrajectoryElementType:alongRouteDistance
	Route Element Start Point
	Route to Next Element
	Modified Route Indicator
	Route Truncation Indicator	fx:RouteTrajectoryElementType:routeTruncationIndicator
	Requested Change
	Route/Trajectory Constraints	fx:RouteTrajectoryElementType:constraint
	Trajectory Point	fx:RouteTrajectoryElementType:point4D
	Geo Position	fx:TrajectoryPoint4DType:position
	Time	fx:TrajectoryPoint4DType:time
	Level	fx:TrajectoryPoint4DType:level
	Predicted Airspeed	fx:TrajectoryPoint4DType:predictedAirspeed
	Predicted Ground Speed	fx:TrajectoryPoint4DType:predictedGroundspeed
	Wind Vector	fx:TrajectoryPoint4DType:metData fx:MeterorologicalDataType:windDirection fx:MeterorologicalDataType:windSpeed
	Assumed Altimeter Setting	fx:TrajectoryPoint4DType:altimeterSetting
	Temperature	fx:TrajectoryPoint4DType:metData fx:MeterorologicalDataType:temperature
	Trajectory Point Property	fx:TrajectoryPoint4DType:pointProperty fx:TrajectoryPointPropertyType:propertyType fx:TrajectoryPointPropertyType:description fx:TrajectoryPointPropertyType:reference ...
	Planned Delay
	Weight at Point	nm:NmRouteTrajectoryElementExtensionType:weight
Route/Traj. Aircraft Performance	Performance Profile	fx:RouteTrajectoryGroupType:climbProfile fx:RouteTrajectoryGroupType:descentProfile fx:PerformanceProfileType:profilePoint fx:ProfilePointType:airspeed fx:ProfilePointType:distance fx:ProfilePointType:level fx:ProfilePointType:seqNum fx:ProfilePointType:time
Route/Traj. Aircraft Performance	Speed Schedule	fx:RouteTrajectoryGroupType:climbSchedule fx:RouteTrajectoryGroupType:descentSchedule fx:SpeedScheduleType:initialSpeed fx:SpeedScheduleType:subsequentSpeed
Route to Revised Destination	Revised Destination
Route to Revised Destination	Route String to Revised Destination
Dangerous Goods	Dangerous Goods Information	fx:FlightType:dangerousGoods
AIRAC	AIRAC Reference	fx:FlightRouteInformation:airacReference
Supplementary Information	Fuel Endurance
	Persons on Board
	Emergency Radio
	Survival Capability
	Life Jacket Characteristics
	Aircraft Colour and Markings
	Pilot in Command
	Dinghies
	Remarks
Other European Items	Route Text
	Ifps Identifier
	Stay Information
	AO What-If ReRoute Indicator
	Replacement Flight Plan Indicator

=======================

Convention

The following conventions is used in this page:

‘MUST’ - indicates a requirement that must be implemented;

‘SHOULD’ - indicates a requirement that is recommended to achieve the best possible implementation; and

‘MAY’ - indicates an option.

Each requirement is detailed in a table with the following structure.

Title	Title of the requirement, used as a short name for the requirement for mnemonic and readability purposes.
Identifier	Unique identifier of the requirement.
Stakeholders	One or more stakeholders impacted by the requirement (ANSP, NM, AU, ARO, …)
Requirement	Statement expressing the requirement.
Rationale	Justification of the existence of the requirement.
CP1 Mandate	List of the specific mandate elements that are covered by the requirement. Null if the requirement does not come from the CP1 mandate.
Notes	Additional notes to clarify the requirement.
Guidance	Guidance to help stakeholders satisfy the requirement.

Requirements on the content of the FF-ICE information

The FF-ICE/R1 Implementation Guidance Manual, Appendix C, specifies the content of the FF-ICE Messages including the rules on the presence of fields per message. These rules are enforced in the schemas for the FF-ICE Messages provided by FIXM.

The requirements below complement these ICAO rules and focuses on FF-ICE Message content declared optional in the FF-ICE/R1 Manual, but whose provision may be either required, or recommended from a European perspective.

Requirements on the provision of flight performance data in the filed eFPL

CP1 states that Operational stakeholders must implement services that support the exchange of flight information [...]
(a) related to FF-ICE Release 1 Services:
[...]
- flight plans, 4D trajectory, flight performance data, flight status;

ICAO Doc 9965 Ed2 Vol II, Chapter 10.3, table 2 explains that this comprises Climb and descent speed schedule, Take-off mass and Performance climb and descent profile.

The following requirements address the provision of performance data in the file eFPL, in line with CP1.

FFICE-REQ-INFO-001 - Provision of take-off mass in the filed eFPL

Title	Provision of take-off mass in the filed eFPL
Identifier	FFICE-REQ-INFO-001
Stakeholders	AU
Requirement	The estimated take-off mass MUST be provided in the filed eFPL.
Rationale	CP1 states that Operational stakeholders must implement services that support the exchange of flight information [...] (a) related to FF-ICE Release 1 Services: [...] - flight plans, 4D trajectory, flight performance data, flight status; According to ICAO Doc 9965 Ed2 Vol II chapter 10.3, the flight performance data that can be provided by an operator includes the take-off mass.
CP1 Mandate	See CP1 Clarifications, item flight performance data
Notes	The estimated take-off mass helps improve trajectory prediction in climb and descent.
Guidance

FFICE-REQ-INFO-002 - Provision of a performance profile in the filed eFPL

Title	Provision of a performance profile in the filed eFPL
Identifier	FFICE-REQ-INFO-002
Stakeholders	AU
Requirement	A performance profile MUST be provided in the filed eFPL.
Rationale	CP1 states that Operational stakeholders must implement services that support the exchange of flight information [...] (a) related to FF-ICE Release 1 Services: [...] - flight plans, 4D trajectory, flight performance data, flight status; According to ICAO Doc 9965 Ed2 Vol II chapter 10.3, the flight performance data that can be provided by an operator includes the Performance Profile.
CP1 Mandate	See CP1 Clarifications, item flight performance data
Notes	The performance profile helps improve trajectory prediction in climb and descent.
Guidance	See also: FF-ICE/R1 Implementation Guidance Manual, Chapter 10.3 AIRCRAFT PERFORMANCE DATA NM 27.0 - NM B2B Reference Manual - FFICE, Chapter D.7.33. RouteTrajectoryGroupType Rules IPFS Users Manual

FFICE-REQ-INFO-003 - Provision of a speed schedule in the filed eFPL

Title	Provision of a speed schedule in the filed eFPL
Identifier	FFICE-REQ-INFO-003
Stakeholders	AU
Requirement	A speed schedule MUST be provided in the filed eFPL.
Rationale	CP1 states that Operational stakeholders must implement services that support the exchange of flight information [...] (a) related to FF-ICE Release 1 Services: [...] - flight plans, 4D trajectory, flight performance data, flight status; According to ICAO Doc 9965 Ed2 Vol II chapter 10.3, the flight performance data that can be provided by an operator includes the Speed Schedule.
CP1 Mandate	See CP1 Clarifications, item flight performance data
Notes
Guidance

Requirements on the desired Route/Trajectory in the filed eFPL

A Route/Trajectory is distinguished by the type of route provided, and the type of trajectory information provided. ICAO Doc 9965 Ed2 Vol II, Appendix E-3. Route/Trajectory, specifies the five options for the level of details of the route/trajectory information in an eFPL, described as packages:

Package 1A = Route and no trajectory points
Package 1B = Route with selected trajectory points
Package 2A = Expanded Route and no trajectory points
Package 2B = Expanded Route with selected trajectory points
Package 2C = Expanded Route with complete trajectory

CP1 states that Operational stakeholders must implement services that support the exchange of flight information [...]
(a) related to FF-ICE Release 1 Services:
[...]

- flight plan and routes generation and validation.
- flight plans, 4D trajectory, flight performance data, flight status;

The exchange of a 4D trajectory is mandated by CP1. The CP1 wording routes generation and validation is understood as relating to the Expanded Route. Therefore, it is considered that the exchange of an expanded route is also mandated by CP1.

Consequently, among the 5 packages defined above, only two are compatible with what CP1 requires. These two packages are:

Package 2B = Expanded Route with selected trajectory points
Package 2C = Expanded Route with complete trajectory

The minimum requirement from a CP1 perspective is that Package 2B is supported.

The following requirements address the provision of an expanded route and 4D trajectory in the filed eFPL accordingly.

FFICE-REQ-INFO-004 - Provision of an expanded route in the filed eFPL

Title	Provision of an expanded route in the filed eFPL
Identifier	FFICE-REQ-INFO-004
Stakeholders	AU
Requirement	The desired route/trajectory of the filed eFPL MUST contain an expanded route.
Rationale	Having an expanded route will allow all relevant stakeholders to process a route end to end (or simply beyond their current scope), even if they do not have full aeronautical data.
CP1 Mandate	See CP1 Clarifications, item *routes generation and validation*
Notes
Guidance	FIXM Resources https://docs.fixm.aero/#/fixm-in-support-of-ffice/example_data?id=content-of-ltfxroutetrajectorygroupgt-ff-ice-expanded-route

FFICE-REQ-INFO-005 - Provision of selected trajectory points in the filed eFPL

Title	Provision of selected trajectory points in the filed eFPL
Identifier	FFICE-REQ-INFO-005
Stakeholders	AU
Requirement	The desired route/trajectory of the filed eFPL MUST at least contain: One Initial Prediction Point. One End Prediction Point. Top of Climb (TOC) points for the initial cruising level and every subsequent requested cruising level change after a climb. One Top of Descent (TOD) point where the trajectory begins a descent from the final cruising level. Trajectory Change Point – Vertical (TCP-V) points where a level segment (intermediate or cruise) is initiated or terminated.
Rationale	CP1 states that Operational stakeholders must implement services that support the exchange of flight information [...] (a) related to FF-ICE Release 1 Services: [...] - flight plans, 4D trajectory, flight performance data, flight status; The minimum requirement from a CP1 perspective is that the desired route/trajectory of the filed eFPL contains a route with selected trajectory points. This corresponds to Package 1B specified by ICAO Doc 9965 Ed2 Vol II chapter E-3. Route/Trajectory.
CP1 Mandate	See CP1 Clarifications, item *4D trajectory*
Notes	Paired with requirement on the "Provision of an expanded route in the filed eFPL" above, this corresponds to Package 2B specified by ICAO Doc 9965 Ed2 Vol II chapter E-3. Route/Trajectory. The selection of trajectory points outlined in this requirement is based on the minimum trajectory requirements specified in the IFPS User Manual R27.0.
Guidance	FIXM Resources https://docs.fixm.aero/#/general-guidance/trajectory-point-properties https://docs.fixm.aero/#/fixm-in-support-of-ffice/example_data?id=content-of-ltfxroutetrajectorygroupgt-ff-ice-trajectory NM Resources IFPS Users Manual, C.3.1: Trajectory requirements

FFICE-REQ-INFO-006 - Provision of a complete trajectory in the filed eFPL

Title	Provision of a complete trajectory in the filed eFPL
Identifier	FFICE-REQ-INFO-006
Stakeholders	AU
Requirement	The desired route/trajectory of the filed eFPL MAY contain a complete trajectory with the selected trajectory points specified in requirement "Provision of selected trajectory points in the filed eFPL" every turn; every start and completion of cruising level; and every change in airspeed; each required EET point; optionally, additional points to achieve the needed accuracy.
Rationale	CP1 states that Operational stakeholders must implement services that support the exchange of flight information [...] (a) related to FF-ICE Release 1 Services: [...] - flight plans, 4D trajectory, flight performance data, flight status; The minimum requirement from a CP1 perspective is that the desired route/trajectory of the filed eFPL contains a route with selected trajectory points. Providing a complete trajectory is therefore optional.
CP1 Mandate	See CP1 Clarifications, item *4D trajectory*
Notes	Paired with requirement on the "Provision of an expanded route in the filed eFPL" above, this corresponds to Package 2C specified by ICAO Doc 9965 Ed2 Vol II chapter E-3. Route/Trajectory.
Guidance	FIXM Resources https://docs.fixm.aero/#/general-guidance/trajectory-point-properties https://docs.fixm.aero/#/fixm-in-support-of-ffice/example_data?id=content-of-ltfxroutetrajectorygroupgt-ff-ice-trajectory

Requirements on the Trajectory Points (TP) in the filed eFPL

FFICE-REQ-INFO-007 - Provision of TP predicted airspeed in the filed eFPL

Title	Provision of TP predicted airspeed in the filed eFPL
Identifier	FFICE-REQ-INFO-007
Stakeholders	AU
Requirement	A 4D Trajectory Point exchanged in the filed eFPL MUST contain a predicted airspeed.
Rationale
CP1 Mandate	See CP1 Clarifications, item *4D trajectory*
Notes
Guidance

FFICE-REQ-INFO-008 - Provision of TP predicted groundspeed in the filed eFPL

Title	Provision of TP predicted groundspeed in the filed eFPL
Identifier	FFICE-REQ-INFO-008
Stakeholders	AU
Requirement	A 4D Trajectory Point exchanged in the filed eFPL MUST contain a predicted groundspeed.
Rationale
CP1 Mandate	See CP1 Clarifications, item *4D trajectory*
Notes
Guidance

FFICE-REQ-INFO-009 - Provision of TP position information in the filed eFPL

Title	Provision of TP position information in the filed eFPL
Identifier	FFICE-REQ-INFO-009
Stakeholders	AU
Requirement	A 4D Trajectory Point exchanged in the filed eFPL SHALL contain its 2D position.
Rationale	Plausibility. A 4D Trajectory Point defined by a 2D position, a level and a time. Exchanging a 4D Trajectory Point without its position is meaningless.
CP1 Mandate	See CP1 Clarifications, item *4D trajectory*
Notes	The position of the 4D Trajectory Point is already declared mandatory in the filed eFPL in ICAO Doc 9965 Ed2 Vol II, Appendix C-4.
Guidance	FIXM https://docs.fixm.aero/#/general-guidance/geographical-positions https://docs.fixm.aero/#/fixm-in-support-of-ffice/example_data?id=content-of-ltfxroutetrajectorygroupgt-ff-ice-trajectory

FFICE-REQ-INFO-010 - Provision of TP level information in the filed eFPL

Title	Provision of TP level information in the filed eFPL
Identifier	FFICE-REQ-INFO-010
Stakeholders	AU
Requirement	A 4D Trajectory Point exchanged in the filed eFPL SHALL contain its level.
Rationale	Plausibility. A 4D Trajectory Point defined by a 2D position, a level and a time. Exchanging 4D Trajectory Point without the level is meaningless.
CP1 Mandate	See CP1 Clarifications, item *4D trajectory*
Notes	The level of the 4D Trajectory Point is already declared mandatory in the filed eFPL in ICAO Doc 9965 Ed2 Vol II, Appendix C-4.
Guidance	FIXM https://docs.fixm.aero/#/general-guidance/vertical-distances https://docs.fixm.aero/#/fixm-in-support-of-ffice/example_data?id=content-of-ltfxroutetrajectorygroupgt-ff-ice-trajectory

FFICE-REQ-INFO-011 - Provision of TP time information in the filed eFPL

Title	Provision of TP time information in the filed eFPL
Identifier	FFICE-REQ-INFO-011
Stakeholders	AU
Requirement	A 4D Trajectory Point exchanged in the filed eFPL SHALL contain its time.
Rationale	Plausibility. A 4D Trajectory Point defined by a 2D position, a level and a time. Exchanging 4D Trajectory Point without the time is meaningless.
CP1 Mandate	See CP1 Clarifications, item *4D trajectory*
Notes	The time of the 4D Trajectory Point is already declared mandatory in the filed eFPL in ICAO Doc 9965 Ed2 Vol II, Appendix C-4.
Guidance	FIXM https://docs.fixm.aero/#/general-guidance/date-time-specification https://docs.fixm.aero/#/fixm-in-support-of-ffice/example_data?id=content-of-ltfxroutetrajectorygroupgt-ff-ice-trajectory

Requirements on flight status information in the filed eFPL

FFICE-REQ-INFO-012 - Provision of the operator flight plan version in filed the eFPL

Title	Provision of the operator flight plan version in filed the eFPL
Identifier	FFICE-REQ-INFO-012
Stakeholders	AU
Requirement	The operator flight plan version MUST be provided in the filed eFPL.
Rationale	CP1 states that Operational stakeholders must implement services that support the exchange of flight information [...] (a) related to FF-ICE Release 1 Services: [...] - flight plans, 4D trajectory, flight performance data, flight status In the filed eFPL, this relates to the Operator Flight Plan Version.
CP1 Mandate	See CP1 Clarifications, item flight status
Notes	The operator flight plan version is already declared mandatory in the filed eFPL in ICAO Doc 9965 Ed2 Vol II, Appendix C-4.
Guidance

Requirements on the provision of flight performance data in the distributed eFPL

FFICE-REQ-INFO-013 - Provision of take-off mass in the distributed eFPL

Title	Provision of take-off mass in the distributed eFPL
Identifier	FFICE-REQ-INFO-013
Stakeholders	NM
Requirement	The estimated take-off mass exchanged in the filed eFPL MUST be provided in the distributed eFPL.
Rationale	CP1 states that Operational stakeholders must implement services that support the exchange of flight information [...] (a) related to FF-ICE Release 1 Services: [...] - flight plans, 4D trajectory, flight performance data, flight status; According to ICAO Doc 9965 Ed2 Vol II chapter 10.3, the flight performance data that can be provided by an operator includes the take-off mass.
CP1 Mandate	See CP1 Clarifications, item flight performance data
Notes	The estimated take-off mass helps improve trajectory prediction in climb and descent.
Guidance

FFICE-REQ-INFO-014 - Provision of a performance profile in the distributed eFPL

Title	Provision of a performance profile in the distributed eFPL
Identifier	FFICE-REQ-INFO-014
Stakeholders	NM
Requirement	The performance profile exchanged in the filed eFPL MUST be provided in the distributed eFPL.
Rationale	CP1 states that Operational stakeholders must implement services that support the exchange of flight information [...] (a) related to FF-ICE Release 1 Services: [...] - flight plans, 4D trajectory, flight performance data, flight status; According to ICAO Doc 9965 Ed2 Vol II chapter 10.3, the flight performance data that can be provided by an operator includes the Performance Profile.
CP1 Mandate	See CP1 Clarifications, item flight performance data
Notes	The performance profile helps improve trajectory prediction in climb and descent.
Guidance	See also: FF-ICE/R1 Implementation Guidance Manual, Chapter 10.3 AIRCRAFT PERFORMANCE DATA NM 27.0 - NM B2B Reference Manual - FFICE, Chapter D.7.33. RouteTrajectoryGroupType Rules IPFS Users Manual

FFICE-REQ-INFO-015 - Provision of a speed schedule in the distributed eFPL

Title	Provision of a speed schedule in the distributed eFPL
Identifier	FFICE-REQ-0xx
Stakeholders	NM
Requirement	The speed schedule exchanged in the filed eFPL MUST be provided in the distributed eFPL.
Rationale	CP1 states that Operational stakeholders must implement services that support the exchange of flight information [...] (a) related to FF-ICE Release 1 Services: [...] - flight plans, 4D trajectory, flight performance data, flight status; According to ICAO Doc 9965 Ed2 Vol II chapter 10.3, the flight performance data that can be provided by an operator includes the Speed Schedule.
CP1 Mandate	See CP1 Clarifications, item flight performance data
Notes
Guidance

Requirements on the agreed Route/Trajectory in the distributed eFPL

FFICE-REQ-INFO-016 - Preservation of the level of detail of the route/trajectory in the distributed eFPL

Title	Preservation of the level of detail of the route/trajectory in the distributed eFPL
Identifier	FFICE-REQ-INFO-016
Stakeholders	NM
Requirement	The agreed route/trajectory that is exchanged in the distributed eFPL SHALL haver the same level of detail as the desired route/trajectory exchanged as part of the filed eFPL.
Rationale	The minimum requirement from a CP1 perspective is that route/trajectory Package 2B is supported. Requirements FFICE-REQ-012, FFICE-REQ-013 and FFICE-REQ-014 materialises this minimum requirement for the filed eFPL. This requirement on the preservation of the level of detail of the route/trajectory guarantees that the minimum CP1 requirement is equally satisfied in the distributed eFPL.
CP1 Mandate	See CP1 Clarifications, items 4D Trajectory and routes generation and validation
Notes	As an example, if package 2B is provided in the filed eFPL, then the agreed route/trajectory exchanged as part of the distributed eFPL shall a level of details matching at least package 2B.
Guidance

FFICE-REQ-INFO-023 - Provision of selected trajectory points in the distributed eFPL

Title	Provision of selected trajectory points in the distributed eFPL
Identifier	FFICE-REQ-INFO-023
Stakeholders	NM
Requirement	The agreed route/trajectory of the distributed eFPL MUST at least contain: One Initial Prediction Point. One End Prediction Point. Top of Climb (TOC) points for the initial cruising level and every subsequent requested cruising level change after a climb. One Top of Descent (TOD) point where the trajectory begins a descent from the final cruising level. Trajectory Change Point – Vertical (TCP-V) points where a level segment (intermediate or cruise) is initiated or terminated.
Rationale	CP1 states that Operational stakeholders must implement services that support the exchange of flight information [...] (a) related to FF-ICE Release 1 Services: [...] - flight plans, 4D trajectory, flight performance data, flight status;
CP1 Mandate	See CP1 Clarifications, item *4D trajectory*
Notes	Requirement FFICE-REQ-INFO-016 on the preservation of the level of detail of the agreed route/trajectory in the distributed eFPL already guarantess that at least Package 2B is support in the distributed eFPL. The purpose of this requirement is to outline the types of trajectory points that MUST always be present in the agreed route/trajectory. The current selection of trajectory points outlined in this requirement is based on the minimum trajectory requirements specified in the IFPS User Manual R27.0.
Guidance	FIXM Resources https://docs.fixm.aero/#/general-guidance/trajectory-point-properties https://docs.fixm.aero/#/fixm-in-support-of-ffice/example_data?id=content-of-ltfxroutetrajectorygroupgt-ff-ice-trajectory NM Resources IFPS Users Manual, C.3.1: Trajectory requirements

Requirements on the Trajectory Points (TP) in the distributed eFPL

FFICE-REQ-INFO-017 - Provision of TP predicted airspeed in the distributed eFPL

Title	Provision of TP predicted airspeed in the distributed eFPL
Identifier	FFICE-REQ-INFO-017
Stakeholders	NM
Requirement	A 4D Trajectory Point exchanged in the distributed eFPL MUST contain a predicted airspeed.
Rationale
CP1 Mandate	See CP1 Clarifications, item *4D trajectory*
Notes
Guidance

FFICE-REQ-INFO-018 - Provision of TP predicted groundspeed in the distributed eFPL

Title	Provision of TP predicted groundspeed in the distributed eFPL
Identifier	FFICE-REQ-INFO-018
Stakeholders	NM
Requirement	A 4D Trajectory Point exchanged in the distributed eFPL MUST contain a predicted groundspeed.
Rationale
CP1 Mandate	See CP1 Clarifications, item *4D trajectory*
Notes
Guidance

FFICE-REQ-INFO-019 - Provision of TP position information in the distributed eFPL

Title	Provision of TP position information in the distributed eFPL
Identifier	FFICE-REQ-INFO-019
Stakeholders	NM
Requirement	A 4D Trajectory Point exchanged in the distributed eFPL SHALL contain its 2D position.
Rationale	Plausibility. A 4D Trajectory Point defined by a 2D position, a level and a time. Exchanging a 4D Trajectory Point without its position is meaningless.
CP1 Mandate	See CP1 Clarifications, item *4D trajectory*
Notes
Guidance	FIXM https://docs.fixm.aero/#/general-guidance/geographical-positions https://docs.fixm.aero/#/fixm-in-support-of-ffice/example_data?id=content-of-ltfxroutetrajectorygroupgt-ff-ice-trajectory

FFICE-REQ-INFO-020 - Provision of TP level information in the distributed eFPL

Title	Provision of TP level information in the distributed eFPL
Identifier	FFICE-REQ-INFO-020
Stakeholders	NM
Requirement	A 4D Trajectory Point exchanged in the distributed eFPL SHALL contain its level.
Rationale	Plausibility. A 4D Trajectory Point defined by a 2D position, a level and a time. Exchanging 4D Trajectory Point without the level is meaningless.
CP1 Mandate	See CP1 Clarifications, item *4D trajectory*
Notes
Guidance	FIXM https://docs.fixm.aero/#/general-guidance/vertical-distances https://docs.fixm.aero/#/fixm-in-support-of-ffice/example_data?id=content-of-ltfxroutetrajectorygroupgt-ff-ice-trajectory

FFICE-REQ-INFO-021 - Provision of TP time information in the distributed eFPL

Title	Provision of TP time information in the distributed eFPL
Identifier	FFICE-REQ-INFO-021
Stakeholders	NM
Requirement	A 4D Trajectory Point exchanged in the distributed eFPL SHALL contain its time.
Rationale	Plausibility. A 4D Trajectory Point defined by a 2D position, a level and a time. Exchanging 4D Trajectory Point without the time is meaningless.
CP1 Mandate	See CP1 Clarifications, item *4D trajectory*
Notes
Guidance	FIXM https://docs.fixm.aero/#/general-guidance/date-time-specification https://docs.fixm.aero/#/fixm-in-support-of-ffice/example_data?id=content-of-ltfxroutetrajectorygroupgt-ff-ice-trajectory

Requirements on flight status information in the distributed eFPL

FFICE-REQ-INFO-022 - Provision of the operator flight plan version in the distributed eFPL

Title	Provision of the operator flight plan version in the distributed eFPL
Identifier	FFICE-REQ-INFO-022
Stakeholders	NM
Requirement	The operator flight plan version MUST be provided in the distributed eFPL.
Rationale	CP1 states that Operational stakeholders must implement services that support the exchange of flight information [...] (a) related to FF-ICE Release 1 Services: [...] - flight plans, 4D trajectory, flight performance data, flight status In the filed eFPL, this relates to the Operator Flight Plan Version.
CP1 Mandate	See CP1 Clarifications, item flight status
Notes
Guidance

FFICE-REQ-INFO-0xx - Provision of the Revalidation Status in the distributed eFPL

Title	Provision of the Revalidation Status in the distributed eFPL
Identifier	FFICE-REQ-xxx
Stakeholders	NM
Requirement	TODO
Rationale
CP1 Mandate
Notes
Guidance

??? Requirements on the desired Route/Trajectory in the distributed eFPL ???

TODO - if the need is confirmed

Flight SWIM Services

OUTDATED - Requirements

Information Exchange Requirements

Definitions

Clarification of the CP1 mandate

Applicability & Exemptions

Information Exchange Requirements for Airspace Users (Filing Service)

Route/Trajectory

Flight Performance Data

Flight status

Flights lists

Detailed flight data

Information Exchange Requirements for Airspace Users (Trial Service)

Information Exchange Requirements for the Network Manager (Data Publication Service)

Route/Trajectory

Flight Performance Data

Flight status

Flights lists

Detailed flight data

Information Exchange Requirements for the Network Manager (Flight Data Request Service)

Route/Trajectory

Flight Performance Data

Flight status

Flights lists

Detailed flight data

Information Exchange Requirements for ANSPs (Notification Service)

Summary Tables for the eFPL content

FF-ICE Data item presence in the submitted eFPL

FF-ICE Data item presence in the distributed eFPL (Summary table)

Other requirements

Requirements on the connection to NM B2B Services

Requirements on the development, testing and validation of NM B2B client applications