This section aggregates 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

WORK IN PROGRESS - content should not be used

Full table of contents

Information Exchange Requirements

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: this relates to the Expanded Route as described in the ICAO FF-ICE/R1 Implementation Guidance 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.)
4D trajectory: this relates to the Trajectory as specified in the ICAO FF-ICE/R1 Implementation Guidance Manual, Appendix B-3 and Appendix E-3.
flight performance data: this relates to the Route/Trajectory Specific Performance Data as described in the ICAO FF-ICE/R1 Implementation Guidance Manual, Chapter 10.3, table 2. It comprises Climb and descent speed schedule, Take-off mass and Performance climb and descent profile. This also relates to the weigh evolution along the flight (weight at route/trajectory elements), which is part of the European extension to the eFPL.
Flight status: this relates to the Operator Flight Plan Version and the Filing Status (ACCEPTABLE, NON-ACCEPTABLE) as described in the ICAO FF-ICE/R1 Implementation Guidance Manual, Appendix B. This also relates to the NM Revalidation status (COMPLIANT, ADVISORY or SUSPENDED). 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 ICAO FF-ICE/R1 Implementation Guidance Manual. It is therefore considered that this particular wording relates related to flight identification based on GUFI.
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 complement the IERs for FF-ICE/R1 that are specified in Appendix B and Appendix C of the ICAO FF-ICE/R1 Implementation Guidance Manual.

In the next tables, the following wording and convention are used:
[Wording]

The ‘filed eFPL’ designates the flight information that is sent 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 sent by the Network Manager to ANSPs using the FF-ICE Publication Service.
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 be satisfied in order to comply with CP1;
SHOULD - indicates an IER that is recommended in order to maximise the benefits of the implementation;
MAY - indicates an optional IER that is nice to have.

Information Exchange Requirements for Airspace Users (Filing Service)

Exchange of flight information - Route and 4D trajectory
	REQ	The desired route/trajectory of the filed eFPL MUST contain an expanded route.
	REQ	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	A Route/Trajectory is distinguished by the type of route provided, and the type of trajectory information provided. The ICAO FF-ICE/R1 Implementation Guidance Manual, 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 [CP1] - Package 2C = Expanded Route with complete trajectory The exchange of a 4D trajectory is explicitly mandated by CP1, and the CP1 wording routes generation and validation 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 filed eFPL. 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.
Exchange of flight information - *Flight Performance Data*
	REQ	The estimated take-off mass, the performance profile and the speed schedule: - MUST be provided in the filed eFPL for Commercial Air Transport Operations (1) and Military Flights operating GAT. - SHOULD be provided in the filed eFPL for other types of aircraft operations, such as General Aviation Operations (2).
	REQ	The weight of the aircraft at each route/trajectory element: - SHOULD be provided in the filed eFPL for Commercial Air Transport Operations and Military Flights operating GAT. - MAY be provided in the filed eFPL for other types of aircraft operations, such as General Aviation Operations.
	RATIONALE	The ICAO FF-ICE/R1 Implementation Guidance Manual Chapter, chapter 10.3, recognises that the provision of the performance data items could be done as logical combinations (“estimated take-off weight with speed schedule” OR “performance profile”). However, the use of all three data items is expected to be highly beneficial in Europe. Therefore, the exchange of the estimated take-off mass, the performance profile and the speed schedule is declared mandatory (must) for Commercial Air Transport Operations and Military Flights operating GAT. 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 harder to originate for e.g. General Aviation Operations. The exchange of the weight of the aircraft at each route/trajectory, which is part of the European extension to the eFPL, is recommended (should) for Commercial Air Transport Operations and Military Flights operating GAT and optional (may) for other operations, in order to acknowledge that while the information can be beneficial to enhance the trajectory predictions, its further exchange by the Network Manager to ANSPs may not always be possible or relevant – see below the rationale for the IERs on the Publication Service / Flight Performance Data.
Exchange of flight information - Flight status
	REQ	The operator flight plan version MUST be provided in the filed eFPL.
	RATIONALE	The term "Flight Status” used in CP1 refers to the Data Category of the same name specified in the ICAO FF-ICE/R1 Implementation Guidance Manual Appendix C, which for the filed eFPL comprises the Operator flight plan version. Note: The operator flight plan version is already declared mandatory in the filed eFPL in the ICAO FF-ICE/R1 Implementation Guidance Manual, Appendix C-4.
Exchange of flight information - Flights lists
	REQ	The Globally Unique Flight Identifier (GUFI) MUST be provided in the filed eFPL.
	RATIONALE	This is to enable the flight / flight plan identification based on GUFI. Note: The GUFI is already declared mandatory in the filed eFPL in the ICAO FF-ICE/R1 Implementation Guidance Manual, Appendix C-4.
Exchange of flight information - Detailed flight data
	REQ	The eFPL data items that are not new compared to what is currently exchanged in FPL 2012 format MUST be provided in the filed eFPL.
	RATIONALE	This is to ensure that the filed eFPL does not miss information compared to its ATS message counterpart. Note: This is specified in ICAO FF-ICE/R1 Implementation Guidance Manual, Appendix C-4.

(1) Commercial Air Transport Operation = An Aircraft Operation involving the transport of passengers, Cargo or Mail for remuneration or hire. [ICAO]

(2) General Aviation Operation = An Aircraft Operation other than a Commercial air transport operation or an Aerial work Operation. [ICAO]

Information Exchange Requirements for Airspace Users (Trial Service)

Airspace users, when testing out alternative trajectories using the Trial Service, are expected to submit “what-if eFPLs” with the same required content as the filed eFPLs. Therefore, the Information Exchange Requirements for Airspace Users specified above for the Filing Service are equally applicable to the trial request of the Trial Service.

Information Exchange Requirements for the Network Manager (Publication Service)

Exchange of flight information - Route and 4D trajectory
	REQ	The agreed route/trajectory MUST be provided in the distributed eFPL.
	REQ	The agreed route/trajectory that is provided in the distributed eFPL MUST have the same level of detail as the desired route/trajectory provided in the filed eFPL.
	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.
	REQ	The desired route/trajectory provided by the airspace user in the filed eFPL MUST be provided in the distributed eFPL in addition to the agreed route/trajectory.
	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 Implementation Guidance 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 requirement on the preservation of the level of details between the agreed and desired route/trajectories ensures that that Package 2B (Expanded Route with selected trajectory points) is equally supported in the distributed eFPL, 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. The exchange of the desired route/trajectory in the distributed eFPL is mandatory (must). The outcome of the trajectory synchronisation between Airspace Users and the Network Manager during the planning phase is expected to minimise the differences between the desired and agreed route/trajectories. However, differences might still exist within acceptable limits, as acknowledged by the FF-ICE/R1 Implementation Guidance Manual, chapter 6.3.5, and the knowledge by ATC of the desired route/trajectory as provided in the field eFPL will prove helpful in some particular circumstances.
	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 ANSP Use of AU Filed Desired Route/Trajectory
Exchange of flight information - Flight Performance Data
	REQ	The estimated take-off mass, the performance profile and the speed schedule provided in the filed eFPL MUST be provided in the distributed eFPL.
	REQ	The performance profile, when provided in the filed eFPL, MUST be provided in the distributed eFPL.
	REQ	The speed schedule, when provided in the filed eFPL, MUST be provided in the distributed eFPL.
	REQ	The weight of the aircraft at each route/trajectory element MAY be provided in the distributed eFPL, where appropriate.
	RATIONALE	This ensures that all flight performance data as specified in the ICAO FF-ICE/R1 Implementation Guidance Manual that is provided to the Network Manager by the Airspace User is also available to the ANSPs. The exchange of the weight of the aircraft at each route/trajectory, which is part of the European extension to the eFPL, is optional (may) as part of the distributed eFPL. The agreed route/trajectory may introduce lateral and/or vertical changes compared to the desired route/trajectory, therefore affecting the estimation of the weight evolution provided by the airspace user. Consequently, it may not always be appropriate to reuse the “weight at route/trajectory element” information from the desired route/trajectory into the agreed route/trajectory.
	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 Mass per Point
Exchange of flight information - Flight status
	REQ	The operator flight plan version provided in the filed eFPL MUST be provided in the distributed eFPL.
	REQ	The revalidation status MUST be provided in the distributed eFPL, whenever the outcome of the flight plan revalidation needs to be exchanged.
	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 exchange of the NM Revalidation status in the distributed eFPL is also mandatory when appropriate in order to ensure that ANSPs are always informed of a change of eFPL status, e.g. when an eFPL is suspended.
	ASSOCIATED ANSP USE CASES	Management of Operator Flight Plan Version Display of the Operator Flight Plan Version to the ATCO
Exchange of flight information - Flights lists
	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
Exchange of flight information - Detailed flight data
	REQ	The eFPL data items that are not new compared to what is currently exchanged in FPL 2012 format MUST be equally provided 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.

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

Exchange of flight information - Route and 4D trajectory
	REQ	The agreed route/trajectory MUST be provided in the flight (plan) data response.
	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.
	REQ	The desired route/trajectory provided in the filed eFPL MUST be provided in the flight (plan) data response, in addition to the agreed route/trajectory.
	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 IPFS Zone against which the airspace user is recommended to synchronise its own desired route/trajectory. The exchange of the desired route/trajectory is mandatory as part of the flight (plan) data response, to be consistent with the similar IER above related to the Publication Service. This is also consistent with the FF-ICE/R1 Implementation Guidance Manual, chapter 10.1.1, that states that An eASP may provide the Desired or Agreed route/trajectory group in a Flight Data Response to a legitimate Flight Data Request message.
Exchange of flight information - Flight Performance Data
	REQ	The estimated take-off mass provided in the filed eFPL MUST be provided in the flight (plan) data response.
	REQ	The performance profile provided in the filed eFPL MUST be provided in the flight (plan) data response.
	REQ	The speed schedule provided in the filed eFPL MUST be provided in the flight (plan) data response.
	REQ	The weight of the aircraft at each route/trajectory element MAY be provided in the flight (plan) data response, where appropriate.
	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.
Exchange of flight information - Flight status
	REQ	The operator flight plan version provided in the filed eFPL MUST be provided in the flight (plan) data response.
	RATIONALE	The Filing Status value MUST be provided in the flight (status) data response.
Exchange of flight information - Flights lists
	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.
Exchange of flight information - Detailed flight data
	REQ	The eFPL data items that are not new compared to what is currently exchanged in FPL 2012 format MUST be equally provided in the distributed eFPL.
	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.

Information Exchange Requirements for ANSPs (Notification Service)

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

Summary Tables for the eFPL content

FF-ICE Data item presence in the filed eFPL

The table below provides a recap of the rules on the presence of fields for the filed eFPL (i.e. the eFPL sent by an eAU to NM). 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 filed 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 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	From Use Cases	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
Flight Identification	Aircraft Identification	M	-	M	-	M
Flight Status	Operator Flight Plan Version	M	M	-	-	M		See Information Exchange Requirements for Airspace Users: (Filing Service), part Flight status.
Flight Characteristics	Flight Rules	M	-	-	-	M
	Type of Flight	O	-	M	-	M
	Special Handling	O	-	-	-	O
	Flight Plan Originator	O	-	-	-	O
	Remarks	O	-	-	-	O
	Operator	O	-	-	-	O
	Equipment and Capabilities	M	-	-	-	M
	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
	Wake Turbulence Category	M	-	-	-	M
	Aircraft Approach Category	O	-	-	-	O
Departure/Destination Data	Departure Aerodrome	M	-		-	M
	Destination Aerodrome	M	-		-	M
	Estimated Off-Block Time	M	-		-	M
	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	-	-	M
	Requested Cruising Speed	M	-	-	-	M
	Requested Cruising Level	M	-	-	-	M
	Total Estimated Elapsed Time	O	-	M	-	M
	General Flight Constraint	O	-	F	-	F	N/A
Route/Traj. Element		M (2+)	M (2+)	M (2+)	-	M (2+)
	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 Information Exchange Requirements for Airspace Users: (Filing Service), part Route and 4D trajectory. The minimum requirement from a CP1 perspective is that Package 1B (= Route with selected trajectory points) is supported. This implies that a selection of 4D Trajectory Points have to be exchanged in the filed eFPL, but not necessarily for all the constituting Route/Trajectory Elements. Therefore, the CP1 Rule is set to M (Conditional).
	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 Information Exchange Requirements for Airspace Users: (Filing Service), part Route and 4D trajectory. A trajectory can either involve a selection of trajectory points, or be a complete trajectory. In the former case, the data item Trajectory Point Property MUST always be provided, because all the 4D trajectory points that constitute the selection must be qualified. In the latter case, only a subset of the trajectory points will be qualified; the other 4D trajectory points added to the complete trajectory will have no Trajectory Point Property. The CP1 Rule is set to M (Conditional) in order to reflect this.
	Planned Delay	O	-	-	-	O
	Weight at Point	N/A	O	O	-	O		See Information Exchange Requirements for Airspace Users: (Filing Service), part Flight Performance Data.
Route/Traj. Aircraft Performance	Performance Profile	O O M (1+) O M M M M	M (Cond) M (Cond) - - - - - -	- - M (3+) - - - - -	- - - - - - - -	M M M (3+) O M M M M		See Information Exchange Requirements for Airspace Users: (Filing Service), part Flight Performance Data.
Route/Traj. Aircraft Performance	Speed Schedule	O O M M	M (Cond) M (Cond) - -	- - - -	- - - -	M M M M		See Information Exchange Requirements for Airspace Users: (Filing Service), part Flight Performance Data.
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
Flight Identification	Aircraft Identification	Yes	-	M
Flight Status	Operator Flight Plan Version	Yes	M	M	See Information Exchange Requirements for the Network Manager (Publication Service), part Flight status.
	Revalidation Status	N/A	M (Cond)	M (Cond)	See Information Exchange Requirements for the Network Manager (Publication Service), part Flight status. The CP1 rule is set to M (Cond) to acknowledge that the distributed eFPL will only include a revalidation status if a re-evaluation has effectively taken place whose outcome needs to be communicated to relevant eASPs.
	Revalidation Status Explanation	N/A	-	O
Flight Characteristics	Flight Rules	Yes	-	M
	Type of Flight	Yes	-	M
	Special Handling	No	-	O
	Flight Plan Originator	No	-	O
	Remarks	No	-	O
	Operator	No	-	O
	Equipment and Capabilities	Yes	-	M
	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
	Wake Turbulence Category	Yes	-	M
	Aircraft Approach Category	No	-	O
Departure/Destination Data	Departure Aerodrome	Yes	-	M
	Destination Aerodrome	Yes	-	M
	Estimated Off-Block Time	Yes	-	M
	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
Desired Route/Trajectory		Yes	M (Cond)	O	See Information Exchange Requirements for the Network Manager (Publication Service), part Route and 4D trajectory.
Agreed Route/Trajectory		N/A	M (Cond)	M (Cond)	See Information Exchange Requirements for the Network Manager (Publication Service), part Route and 4D trajectory. CP1 requires a trajectory to be exchanged as part of the eFPL. However, an eFPL that becomes invalid after a flight plan re-evaluation will not contain an agreed route/trajectory. Therefore, the rule on the presence of the field is set to M (Conditional).
Route/Traj. Group	Aircraft Take-off Mass	Yes	M	M	See Information Exchange Requirements for the Network Manager (Publication Service), part Flight Performance Data.
	Requested Cruising Speed	Yes	-	M
	Requested Cruising Level	Yes	-	M
	Total Estimated Elapsed Time	Yes	-	M
	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 (Cond)	M (Cond)	See Information Exchange Requirements for the Network Manager (Publication Service), part Route and 4D trajectory.
	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 (Cond) - - -	O M O O	See Information Exchange Requirements for the Network Manager (Publication Service), part Route and 4D trajectory.
	Planned Delay	No	-	O
	Weight at Point	No	-	O
Route/Traj. Aircraft Performance	Performance Profile	Yes Yes Yes No Yes Yes Yes Yes	M M - - - - - -	M M M (3+) O M M M M	See Information Exchange Requirements for the Network Manager (Publication Service), part Flight Performance Data.
Route/Traj. Aircraft Performance	Speed Schedule	Yes Yes Yes Yes	M M - -	M M M M	See Information Exchange Requirements for the Network Manager (Publication Service), part Flight Performance Data.
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 Error rendering macro 'viewpdf' : Failed to find attachment with Name NM B2B Operational Validation.pdf 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