ANNEX

1.   EXTENDED ARRIVAL MANAGEMENT AND PERFORMANCE BASED NAVIGATION IN THE HIGH DENSITY TERMINAL MANOEUVRING AREAS

Extended Arrival Management (AMAN) and Performance Based Navigation (PBN) in high density Terminal Manoeuvring Areas (TMAs) improves the precision of the approach trajectory and facilitates air traffic sequencing at an earlier stage. Extended AMAN supports extension of the planning horizon out to a minimum of 180-200 nautical miles, up to and including the Top of Descent of arrival flights. PBN in high density TMAs covers the development and implementation of fuel efficient and/or environmental friendly procedures for arrival and departure (Required Navigation Performance 1 Standard Instrument Departures (RNP 1 SIDs), Standard Arrival Routes (STARs)) and approach (Required Navigation Performance Approach (RNP APCH)).

This functionality is composed of two sub-functionalities:

—	Arrival Management extended to en-route Airspace

—	Enhanced Terminal Airspace using RNP-Based Operations

1.1.   Operational and technical scope

1.1.1.   Arrival Management extended to en-route Airspace

Arrival Management extended to en-route Airspace extends the AMAN horizon from the 100-120 nautical miles to 180-200 nautical miles from the arrival airport. Traffic sequencing may be conducted in the en-route and early descent phases.

Air traffic control (ATC) services in the TMAs implementing AMAN operations shall coordinate with Air Traffic Services (ATS) units responsible for adjacent en-route sectors.

The existing techniques to manage the AMAN constraints, in particular Time to Lose or Gain and Speed Advice may be used to implement this functionality.

System requirements

—	AMAN systems shall provide arrival sequence time information into en-route ATC systems up to 180-200 nautical miles from the arrival airport

—

ATC systems of upstream air traffic service (ATS) units shall manage AMAN constraints. Data exchange, data processing and information display at the relevant controller working positions in the ATS units shall support the management of arrival constrains; Data exchange between ATS units may be achieved with existing technology pending the implementation of System-Wide Information Management (SWIM) services

1.1.2.   Enhanced Terminal Airspace using RNP-Based Operations

Enhanced Terminal Airspace using RNP-Based Operations consists of the implementation of environmental friendly procedures for arrival/departure and approach using PBN in high-density TMAs, as specified in the following navigation specifications:

—	SIDs and STARs using the RNP 1 specification with the use of the Radius to Fix (RF) path terminator

—	Required Navigation Performance Approach with Approach Procedure with Vertical guidance (RNP APCH with APV)

Enhanced Terminal Airspace using RNP-Based Operations includes:

—	RNP 1 SIDs, STARs and transitions (with the use of the Radius to Fix (RF) attachment)

—	RNP APCH (Lateral Navigation/Vertical Navigation (LNAV/VNAV) and Localiser Performance with Vertical guidance (LPV) minima)

System Requirements

ATC systems and ATC Safety Nets shall enable the Terminal Area and Approach PBN operations

—	RNP 1 operations require the Lateral and Longitudinal Total System Error (TSE) to, be within +/– 1 nautical mile for at least 95 % of flight time and on-board performance monitoring, alerting capability and high integrity navigation databases

—

For RNP APCH, the Lateral and Longitudinal Total System Error (TSE) shall be +/– 0,3 nautical mile for at least 95 % of flight time for the Final Approach Segment and on-board performance monitoring, alerting capability and high integrity navigation databases are required RNP 1 as well as RNP APCH capability requires inputs from Global Navigation Satellite System (GNSS)

—	Vertical Navigation in support of APV may be provided by GNSS Satellite Based Augmentation System (SBAS) or by barometric altitude sensors

1.2.   Geographical scope

1.2.1.   EU and EFTA Member States

Extended AMAN and PBN in high density TMAs and associated en-route sectors shall be operated at the following airports:

—	London-Heathrow

—

Paris-CDG

—	London-Gatwick

—	Paris-Orly

—	London-Stansted

—	Milan-Malpensa

—	Frankfurt International

—	Madrid-Barajas

—	Amsterdam Schiphol

—	Munich Franz Josef Strauss

—	Rome-Fiumicino

—	Barcelona El Prat

—	Zurich Kloten (1)

—	Düsseldorf International

—	Brussels National

—	Oslo Gardermoen (2)

—	Stockholm-Arlanda

—	Berlin Brandenburg Airport

—	Manchester Ringway

—	Palma De Mallorca Son San Juan

—	Copenhagen Kastrup

—	Vienna Schwechat

—

Dublin

—	Nice Cote d'Azur

1.2.2.   Other third countries

Extended AMAN and PBN in high density TMAs should be operated at the Istanbul Ataturk Airport.

1.3.   Stakeholders required to implement the functionality and deployment target date

ATS providers and the Network Manager shall ensure that ATS units providing ATC services within the terminal airspace of the airports referred to in point 1.2 and the associated en-route sectors operate Extended AMAN and PBN in high density TMAs as from 1 January 2024.

1.4.   Need for synchronisation

The deployment of Extended AMAN and PBN in high density TMAs functionality shall be coordinated due to the potential network performance impact of delayed implementation in the airports referred to in Point 1.2. From a technical perspective the deployment of targeted system and procedural changes shall be synchronised in order to ensure that the performance objectives are met. The synchronisation of investments shall involve multiple airport operators and air navigation service providers. Furthermore, synchronisation during the related industrialisation phase shall take place, in particular among supply industry.

1.5.   Essential prerequisites

There are no prerequisites for this functionality. An existing AMAN facilitates the operational integration of this ATM functionality into existing systems.

1.6.   Interdependencies with other ATM functionalities

—	Data exchange between ATS units, in particular concerning Extended AMAN, shall be implemented using System Wide Information Management (SWIM) services where iSWIM functionality referred to in Point 5 is available

—	Downlink trajectory information as specified in Point 6, where available, shall be used by the AMAN

2.   AIRPORT INTEGRATION AND THROUGHPUT

Airport Integration and Throughput facilitates the provision of approach and aerodrome control services by improving runway safety and throughput, enhancing taxi integration and safety and reducing hazardous situations on the runway.

This functionality is composed of five sub-functionalities:

—	Departure Management Synchronised with Pre-departure sequencing

—	Departure Management integrating Surface Management Constraints

—	Time-Based Separation for Final Approach

—	Automated Assistance to Controller for Surface Movement Planning and Routing

—	Airport Safety Nets

2.1.   Operational and technical scope

2.1.1.   Departure Management Synchronised with Pre-departure sequencing

Departure management synchronised with pre-departure sequencing is a means to improve departure flows at one or more airports by calculating the Target Take Off Time (TTOT) and Target Start Approval Time (TSAT) for each flight, taking multiple constraints and preferences into account. Pre-departure management consists of metering the departure flow to a runway by managing Off-block-Times (via Start-up-Times) which take account of the available runway capacity. In combination with Airport — Collaborative Decision Making (A-CDM), Pre-departure management reduces taxi times, increases Air Traffic Flow Management-Slot (ATFM-Slot) adherence and predictability of departure times. Departure management aims at maximising traffic flow on the runway by setting up a sequence with minimum optimised separations.

Operational stakeholders involved in A-CDM shall jointly establish pre-departure sequences, taking into account agreed principles to be applied for specific reasons (such as runway holding time, slot adherence, departure routes, airspace user preferences, night curfew, evacuation of stand/gate for arriving aircraft, adverse conditions including de-icing, actual taxi/runway capacity, current constraints, etc.).

System Requirements

—	Departure Management (DMAN) and A-CDM systems shall be integrated and shall support optimised pre-departure sequencing with information management systems for airspace users (Target Off Block Time (TOBT) feeding) and airport (contextual data feeding)

—

DMAN systems shall elaborate a collaborative sequence and provide both TSAT and TTOT. TSAT and TTOT shall take into account variable taxi times and shall be updated according to the actual aircraft take-off; DMAN systems shall provide the air traffic controller with the list of TSAT and TTOT for the aircraft metering

2.1.2.   Departure Management integrating Surface Management Constraints

Departure management integrating surface management constraints is an ATM tool that determines optimal surface movement plans (such as taxi route plans) involving the calculation and sequencing of movement events and optimizing resource usage (e. g. de-icing facilities). The departure sequence at the runway shall be optimised according to the real traffic situation reflecting any change off-gate or during taxi to the runway.

Advanced Surface Movement Guidance and Control Systems (A-SMGCS) shall provide optimised taxi-time and improve predictability of take-off times by monitoring of real surface traffic and by considering updated taxi times in departure management.

System Requirements

—	DMAN systems shall take account of variable and updated taxi times to calculate the TTOT and TSAT. Interfaces between DMAN and A-SMGCS routing shall be developed

—	DMAN integrating A-SMGCS constraints using a digital system, such as Electronic Flight Strips (EFSs), with an advanced A-SMGCS routing function shall be integrated into flight data processing systems for departure sequencing and routing computation

—	An A-SMGCS routing function shall be deployed

2.1.3.   Time-Based Separation for Final Approach

Time-Based Separation (TBS) consists in the separation of aircraft in sequence on the approach to a runway using time intervals instead of distances. It may be applied during final approach by allowing equivalent distance information to be displayed to the controller taking account of prevailing wind conditions. Radar separation minima and Wake Turbulence Separation parameters shall be integrated in a TBS support tool providing guidance to the air traffic controller to enable time-based spacing of aircraft during final approach that considers the effect of the headwind.

System Requirements

—	The flight data processing and AMAN systems shall be compatible with the TBS support tool and able to switch between time and distance based wake turbulence radar separation rules

—	The controller working position shall integrate the TBS support tool with safety nets to support the air traffic controller, in order to calculate TBS distance respecting minimum radar separation using actual glide-slope wind conditions

—	Local meteorological (MET) information providing actual glide slope wind conditions shall be provided to the TBS support tool

—	The TBS support tool shall provide automatic monitoring and alerting on non-conformant final approach airspeed behaviour, automatic monitoring and alerting of separation infringement and automatic monitoring and alerting for the wrong aircraft being turned on to a separation indicator

—	The TBS support tool and associated controller working position shall calculate Indicator distance and display it on controller displays

—	Safety nets capturing automatic monitoring and alerting of separation infringement shall support TBS operations

2.1.4.   Automated Assistance to Controller for Surface Movement Planning and Routing

The routing and planning functions of A-SMGCS shall provide the automatic generation of taxi routes, with the corresponding estimated taxi time and management of potential conflicts.

Taxi routes may be manually modified by the air traffic controller before being assigned to aircraft and vehicles. These routes shall be available in the flight data processing system.

System Requirements

—	The A-SMGCS routing and planning function shall calculate the most operationally relevant route as free as possible of conflicts which permits the aircraft to go from stand to runway, from runway to stand or any other surface movement

—	The controller working position shall allow the air traffic controller to manage surface route trajectories

—	The flight data processing system shall be able to receive planned and cleared routes assigned to aircraft and vehicles and manage the status of the route for all concerned aircraft and vehicles

2.1.5.   Airport Safety Nets

Airport safety nets consist of the detection and alerting of conflicting ATC clearances to aircraft and deviation of vehicles and aircraft from their instructions, procedures or routing which may potentially put the vehicles and aircraft at risk of a collision. The scope of this sub-functionality includes the Runway and Airfield Surface Movement area.

ATC support tools at the aerodrome shall provide the detection of Conflicting ATC Clearances and shall be performed by the ATC system based on the knowledge of data including the clearances given to aircraft and vehicles by the air traffic controller, the assigned runway and holding point. The air traffic controller shall input all clearances given to aircraft or vehicles into the ATC system using a digital system, such as the EFS.

Different types of conflicting clearances shall be identified (for example Line-Up vs. Take-Off). Some may only be based on the air traffic controller input; others may in addition use other data such as A-SMGCS surveillance data.

Airport Safety Nets tools shall alert air traffic controllers when aircraft and vehicles deviate from ATC instructions, procedures or route. The air traffic controller instructions available electronically (through a digital system, such as EFS) shall be integrated with other data such as flight plan, surveillance, routing, published rules and procedures. The integration of this data shall allow the system to monitor the information and when inconsistencies are detected, an alert shall be provided to the air traffic controller (for example no push-back approval).

System Requirements

—	Airport Safety Nets shall integrate A-SMGCS surveillance data and controller runway related clearances; Airport Conformance Monitoring shall integrate A-SMGCS Surface Movement Routing, surveillance data and controller routing clearances

—	A-SMGCS shall include the advanced routing and planning function referred to in Point 2.1.4 above to enable conformance monitoring alerts

—	A-SMGCS shall include a function to generate and distribute the appropriate alerts. These alerts shall be implemented as an additional layer on top of the existing A-SMGCS Level 2 alerts and not as a replacement for them

—	The controller working position shall host warnings and alerts with an appropriate human-machine interface including support for cancelling an alert

—	Digital systems, such as EFSs, shall integrate the instructions given by the air traffic controller with other data such as flight plan, surveillance, routing, published rules and procedures

2.2.   Geographical scope

2.2.1.   EU and EFTA Member States

Departure Management Synchronised with Pre-departure sequencing, Departure Management integrating Surface Management Constraints, Automated Assistance to Controller for Surface Movement Planning and Routing and Airport Safety Nets shall be operated at the following airports:

—	London-Heathrow

—

Paris-CDG

—	London-Gatwick

—	Paris-Orly

—	London-Stansted

—	Milan-Malpensa

—	Frankfurt International

—	Madrid-Barajas

—	Amsterdam Schiphol

—	Munich Franz Josef Strauss

—	Rome-Fiumicino

—	Barcelona El Prat

—	Zurich Kloten (3)

—	Düsseldorf International

—	Brussels National

—	Oslo Gardermoen (4)

—	Stockholm-Arlanda

—	Berlin Brandenburg Airport

—	Manchester Ringway

—	Palma De Mallorca Son San Juan

—	Copenhagen Kastrup

—	Vienna Schwechat

—

Dublin

—	Nice Cote d'Azur

Time-Based Separation for Final Approach shall be operated at the following airports:

—	London-Heathrow

—	London-Gatwick

—	Paris-Orly

—	Milan-Malpensa

—	Frankfurt International

—	Madrid-Barajas

—	Amsterdam-Schiphol

—	Munich Franz Josef Strauss

—	Rome-Fiumicino

—	Zurich Kloten (5)

—	Düsseldorf International

—	Oslo Gardermoen (6)

—	Manchester Ringway

—	Copenhagen Kastrup

—	Vienna Schwechat

—

Dublin

2.2.2.   Other third countries

All sub-functionalities referred to in this Point should be operated at the Istanbul Ataturk Airport.

2.3.   Stakeholders required to implement the functionality and deployment target dates

ATS providers and airport operators providing services at the airports as referred to in point 2.2 shall operate:

—	Departure Management Synchronised with Pre-departure sequencing as from 1 January 2021

—	Departure Management integrating Surface Management Constraints as from 1 January 2021

—	Time-Based Separation for Final Approach as from 1 January 2024

—	Automated Assistance to Controller for Surface Movement Planning and Routing as from 1 January 2024

—	Airport Safety Nets as from 1 January 2021

2.4.   Need for synchronisation

The deployment of Airport Integration and Throughput functionality shall be coordinated due to the potential network performance impact of delayed implementation in the targeted airports. From a technical perspective the deployment of targeted system and procedural changes shall be synchronised in order to ensure that the performance objectives are met. This synchronisation of investments shall involve multiple airport operators and air navigation service providers. Furthermore synchronisation during the related industrialisation phase shall take place, in particular among supply industry and standardisation bodies.

2.5.   Essential prerequisites

The following prerequisites are required:

—	Digital systems, such as EFS, A-CDM and initial DMAN for Departure Management Synchronised with Pre-departure sequencing

—	Digital systems, such as EFS, initial DMAN and A-SMGCS level 1 & 2 for Departure Management integrating Surface Management Constraints

—	Digital systems, such as EFS for TBS

—	Digital systems, such as EFS and A-SMGCS level 1 & 2 for Automated Assistance to Controller for Surface Movement Planning and Routing

—	Digital systems, such as EFS and A-SMGCS surveillance for Airport Safety Nets.

2.6.   Interdependencies with other ATM functionalities

—	There are no interdependencies with other ATM functionalities

—

The sub-functionalities Departure Management Synchronised with Pre-departure sequencing and Time Based Separation for Final Approach may be implemented independently from the other sub-functionalities; The implementation of the sub-functionalities Departure management integrating surface management constraints and Airport Safety Nets require the availability of the sub-functionality Automated assistance to controllers for surface movement planning and routing (A-SMGCS level 2+)

3.   FLEXIBLE AIRSPACE MANAGEMENT AND FREE ROUTE

Combined operation of Flexible Airspace Management and Free Route enable airspace users to fly as closely as possible to their preferred trajectory without being constrained by fixed airspace structures or fixed route networks. It further allows operations that require segregation, for example military training, to take place safely and flexibly, and with minimum impact on other airspace users.

This functionality is composed of two sub-functionalities:

—	Airspace Management and Advanced Flexible Use of Airspace

—	Free Route

3.1.   Operational and technical scope

3.1.1.   Airspace Management and Advanced Flexible Use of Airspace

Airspace Management (ASM) and Advanced Flexible Use of Airspace (A-FUA) aims to provide the possibility to manage airspace reservations more flexibly in response to airspace user requirements. Changes in airspace status shall be shared with all concerned users, in particular Network Manager, air navigation service providers and airspace users (Flight Operations Centre/Wing Operations Centre (FOC/WOC)). ASM procedures and processes shall cope with an environment where airspace is managed dynamically with no fixed-route network.

Data-sharing shall be enhanced by the availability of airspace structures in support of a more dynamic ASM and Free Routing Airspace (FRA) implementation. FRA is the airspace defined laterally and vertically, allowing free routing with a set of entry/exit features. Within this airspace, flights remain subject to air traffic control.

ASM solutions shall support all airspace users, including enabling the alignment of FRA, Conditional Route (CDR) and published Direct Routing (DCT). These ASM solutions shall be based on forecast demand received from the local Air Traffic Flow and Capacity Management (ATFCM) function and/or the Network Manager.

System requirements

—

The ASM support system shall support the fixed and conditional route networks currently in place, as well as DCTs, FRA and flexible sector configurations; The system shall be able to respond to changing demands for airspace; Enhancements to the Network Operations Plan (NOP) shall be achieved through a cooperative decision-making process between all involved operational stakeholders; The system shall support cross-border activities, resulting in shared use of segregated airspace regardless of national boundaries

—	Airspace configurations shall be accessible via Network Manager systems, which shall contain the up-to-date and foreseen airspace configurations, to allow airspace users to file and modify their flight plans based on timely and accurate information

—	The ATC system shall support flexible configuration of sectors so that their dimensions and operating hours can be optimised according to the demands of the NOP

—	The system shall allow a continuous assessment of the impact of changing airspace configurations on the network

—	ATC systems shall correctly depict the activation and de-activation of configurable airspace reservations and the change of a volume of airspace from a fixed route network to FRA

—	The Flight Plan Processing System (IFPS) shall be modified to reflect the changes in the definition of airspace and routes so that the routes, flight-progress and associated information are available to ATC systems

—

The ASM, ATFCM and ATC systems shall securely interface in a way that allows the provision of air navigation services based on a common understanding of the airspace and traffic environment. The ATC systems shall be modified to enable this functionality to the extent necessary to comply with Regulation (EC) No 552/2004, point 4 of Part A of Annex II.

—

Centralised Aeronautical Information Services (AIS) systems, such as the European AIS Database (EAD), shall make available environment data for flexible airspace structures to all involved operational stakeholders in a timely manner. This enables planning to be undertaken based on accurate information relevant to the time of the planned operations; Local AIS systems shall enable this capability and the upload of changing local data

—

Operational stakeholders shall be able to interface with the NOP as specified in Point 4; Interfaces shall be defined to allow dynamic data to be sent to operational stakeholder systems, and for those stakeholders to be able to communicate information in an accurate and timely manner; The systems of these stakeholders shall be modified to enable these interfaces

3.1.2.   Free Route

Free Route may be deployed both through the use of Direct Routing Airspace and through FRA. Direct Routing Airspace is the airspace defined laterally and vertically with a set of entry/exit conditions where published direct routings are available. Within this airspace, flights remain subject to air traffic control. To facilitate early implementation before the target deployment date specified in Point 3.3, free route could be implemented in a limited way during defined periods. Procedures for transitioning between free route and fixed route operations shall be set. Initial implementation of Free Route may be done on a structurally limited basis, for example by restricting the available entry/exit points for certain traffic flows, through the publication of DCTs, which will allow airspace users to flight plan on the basis of those published DCTs. DCT availability may be subject to traffic demand and/or time constraints. The implementation of FRA based on DCTs may allow the removal of the ATS route network. FRA and DCT shall be published in aeronautical publications as described in the European Route Network Improvement Plan of the Network Manager.

System requirements

—	Network management systems shall implement: — Flight plan processing and checking for DCTs and FRA — IFPS routing proposals based on FRA — dynamic re-routing — ATFCM planning and execution within FRA — calculation and management of traffic loads

—

ATC systems shall implement the following: — Flight data processing system, including HMI, to manage trajectory/flight planning without reference to the fixed ATS network — Flight planning systems to support FRA and cross-border operations — ASM/ATFCM to manage FRA — for FRA, Medium Term Conflict Detection (MTCD) including Conflict Detection Tools (CDT), Conflict Resolution Assistant (CORA), Conformance Monitoring, and APW for dynamic airspace volumes/sectors; Trajectory prediction and de-confliction shall support an automated MTCD tool adapted to operate in FRA airspace and, when required, on DCT

—	ATC systems may receive and utilise updated flight data coming from an aircraft (ADS-C EPP) where data link functionality is available

—	Airspace users' systems shall implement flight planning systems to manage dynamic sector configuration and FRA

—	Flight Data Processing System (FDPS) shall support FRA, DCT and A-FUA

—	The controller working position shall support the operating environments, as appropriate

3.2.   Geographical scope

Flexible Airspace Management and Free Route shall be provided and operated in the airspace for which the Member States are responsible at and above flight level 310 in the ICAO EUR region.

3.3.   Stakeholders required to implement the functionality and deployment target dates

Network Manager, air navigation service providers and airspace users shall operate:

—	DCT as from 1 January 2018

—	FRA as from 1 January 2022

3.4.   Need for synchronisation

The deployment of Flexible Airspace Management and Free Route functionality shall be coordinated due to the potential network performance impact of delayed implementation in a wide geographical scope involving a number of stakeholders. From a technical perspective the deployment of targeted system and procedural changes shall be synchronised to ensure that the performance objectives are met. This synchronisation of investments shall involve multiple civil/military air navigation service providers, airspace users and the Network Manager. Furthermore, synchronisation during the related industrialisation phase shall take place, in particular among supply industry.

3.5.   Essential prerequisites

There are no prerequisites for this functionality.

3.6.   Interdependencies with other ATM functionalities

—	When available FRA and DCT shall be supported by Network Manager and SWIM systems specified in Point 4 and Point 5

4.   NETWORK COLLABORATIVE MANAGEMENT

Network Collaborative Management improves the European ATM network performance, notably capacity and flight efficiency through exchange, modification and management of trajectory information. Flow Management shall move to a Cooperative Traffic Management (CTM) environment, optimising the delivery of traffic into sectors and airports and the need for Air Traffic Flow and Capacity Management (ATFCM) measures.

This functionality is composed of four sub-functionalities:

—	Enhanced Short Term ATFCM Measures

—	Collaborative NOP

—	Calculated Take-off Time to Target Times for ATFCM purposes

—	Automated Support for Traffic Complexity Assessment

4.1.   Operational and technical scope

4.1.1.   Enhanced Short Term ATFCM Measures

Tactical capacity management using Short Term ATFCM Measures (STAM) shall ensure a close and efficient coordination between ATC and the network management function. Tactical capacity management shall implement STAM using cooperative decision-making to manage flow before flights enter a sector.

System requirements

—

ATFCM planning shall be managed at network level by the Network Manager and at local level by the flow management position to support hot-spot detection, execution of STAM, network assessment and continuous monitoring of network activity; ATFCM planning at network and local level shall be coordinated with each other

4.1.2.   Collaborative NOP

The Network Manager shall implement a Collaborative NOP consisting of increased integration of NOP and Airport Operations Plan (AOP) information. The Collaborative NOP shall be updated through data exchanges between Network Manager and operational stakeholder systems in order to cover the entire trajectory lifecycle and to reflect priorities when needed. Airport configurations constraints and weather and airspace information shall be integrated into the NOP. Where available, the airport constraints shall be derived from the AOP. The ATFCM target times may be used as input to arrival sequencing. Where available and required for traffic sequencing, the Target Time for Arrival shall be derived from the AOP. Where Target Times are used by ATFCM to address airport congestion, these Target Times may be subject to AOP alignment as part of ATFCM coordination processes. Target Times shall also be used to support airport arrival sequencing processes in the en-route phase. The integrated airport configurations and weather and airspace information shall be able to be read and modified by authorised operational stakeholders participating in managing and operating the network.

The development of a Collaborative NOP shall focus on the availability of shared operational planning and real-time data.

System requirements

—	Operational stakeholders shall be granted access to the data they need through queries within the NOP

—	Operational stakeholder ground systems shall be adapted to interface with network management systems. AOP systems shall interface with the NOP systems to implement a Collaborative NOP

—	Interface between operational stakeholder systems and network management systems shall be implemented using System-Wide Information Management services once available

4.1.3.   Calculated Take-off Time to Target Times for ATFCM purposes

Target Times (TT) shall be applied to selected flights for ATFCM purposes to manage ATFCM at the point of congestion rather than only at departure. Where available, the Target Times of Arrival (TTA) shall be derived from the Airport Operations Plan (AOP). TTAs shall be used to support airport arrival sequencing processes in the en-route phase.

System requirements

—	Network Manager's systems shall support target time sharing. Systems shall be able to adjust Calculated Take-off Times (CTOTs) based on refined and agreed TTAs at the destination airport; TTAs shall be integrated into the AOP for subsequent refinement of the NOP

—	Flight data processing systems may need to be adapted in order to process downlinked trajectory data (ADS-C EPP)

4.1.4.   Automated Support for Traffic Complexity Assessment

Planned trajectory information, network information and recorded analytical data from past operations shall be used for predicting traffic complexity and potential overload situations, allowing mitigation strategies to be applied at local and network levels.

Extended Flight Plan (EFPL) shall be used to enhance the quality of the planned trajectory information thus enhancing flight planning and complexity assessments.

System requirements

—	Network Manager systems shall deal with flexible airspace structures, route configuration allowing the management of traffic loads and complexity in a collaborative manner at flow management position and network level

—	The flight data processing systems shall interface with the NOP

—	Flight planning systems shall support EFPL and Network Manager systems shall be able to process EFPL

—

Information provided through Route Availability Document (RAD) and Profile Tuning Restriction (PTR) shall be harmonised through the Collaborative Decision Making (CDM) process of the European Route Network Design and ATFM functions of the Network Manager such that Flight Planning System Providers shall be able to generate a flight plan routing that will be accepted with the most efficient trajectory

—	ASM/ATFCM tools shall be able to manage different airspace availability and sector capacity, including A-FUA (as specified in point (3), Route Availability Document (RAD) adaptation and STAM

4.2.   Geographical scope

Network Collaborative Management shall be deployed in the EATMN. In ATC centres in Member States where civil-military operations are not integrated (7), Network Collaborative Management shall be deployed to the extent required by Regulation (EC) No 552/2004, point 4 of Part A of Annex II.

4.3.   Stakeholders required to implement the functionality and deployment target date

Operational stakeholders and the Network Manager shall operate Network Collaborative Management as from 1 January 2022.

4.4.   Need for synchronisation

The deployment of Network Collaborative Management functionality shall be coordinated due to the potential network performance impact of delayed implementation in a wide geographical scope involving a number of stakeholders. From a technical perspective the deployment of targeted system and procedural changes shall be synchronised to ensure that the performance objectives are met. This synchronisation of investments shall involve multiple air navigation service providers and the Network Manager. Furthermore synchronisation during the related industrialisation phase shall take place (supply industry and standardisation bodies in particular).

4.5.   Essential prerequisites

There are no prerequisites for this functionality. An existing STAM phase 1 implementation facilitates the operational integration of this ATM functionality into existing systems.

4.6.   Interdependencies with other ATM functionalities

—	Network management systems shall make use of AMAN as specified in Point 1

—	Where available, AOP system shall make use of DMAN as specified in Point 2

—	Network management systems shall support Flexible use of airspace and free routing as specified in Point 3

—	Information exchange requirements shall use SWIM as specified in Point 5 once available

—	Downlink trajectory information as specified in Point 6, where available, shall be integrated into the NOP to support TTO/TTA

5.   INITIAL SYSTEM WIDE INFORMATION MANAGEMENT

System Wide Information Management (SWIM) concerns the development of services for information exchange. SWIM comprises standards, infrastructure and governance enabling the management of information and its exchange between operational stakeholders via interoperable services.

Initial System Wide Information Management (iSWIM) supports information exchanges that are built on standards and delivered through an internet protocol (IP)-based network by SWIM enabled systems. It consists of:

—	Common infrastructure components

—	SWIM Technical Infrastructure and Profiles

—	Aeronautical information exchange

—	Meteorological information exchange

—	Cooperative network information exchange

—	Flight information exchange

5.1.   Operational and technical scope

5.1.1.   Common infrastructure components

Common infrastructure components are:

—	The registry, which shall be used for publication and discovery of information regarding service consumers and providers, the logical information model, SWIM enabled services, business, technical, and policy information

—	Public Key Infrastructure (PKI), which shall be used for signing, emitting and maintaining certificates and revocation lists; The PKI ensures that information can be securely transferred

5.1.2.   SWIM Technical Infrastructure and Profiles

A SWIM Technical Infrastructure (TI) Profile implementation shall be based on standards and interoperable products and services. Information exchange services shall be implemented on one of the following profiles:

—	Blue SWIM TI Profile, which shall be used for exchanging flight information between ATC centres and between ATC and Network Manager

—	Yellow SWIM TI Profile, which shall be used for any other ATM data (aeronautical, meteorological, airport, etc.)

5.1.3.   Aeronautical information exchange

Operational stakeholders shall implement services which support the exchange of the following aeronautical information using the yellow SWIM TI Profile:

—	Notification of the activation of an Airspace Reservation/Restriction (ARES)

—	Notification of the de-activation of an Airspace Reservation/Restriction (ARES)

—	Pre-notification of the activation of an Airspace Reservation/Restriction (ARES)

—	Notification of the release of an Airspace Reservation/Restriction (ARES)

—	Aeronautical information feature on request. Filtering possible by feature type, name and an advanced filter with spatial, temporal and logical operators.

—	Query Airspace Reservation/Restriction (ARES) information

—	Provide Aerodrome mapping data and Airport Maps

—	Airspace Usage Plans (AUP, UUP) — ASM level 1, 2 and 3

—

D-Notams

Service implementations shall be compliant with the applicable version of Aeronautical Information Reference Model (AIRM), the AIRM Foundation Material and the Information Service Reference Model (ISRM) Foundation Material.

System requirements

—	ATM systems shall be able to use the Aeronautical information exchange services

5.1.4.   Meteorological information exchange

Operational stakeholders shall implement services which support the exchange of the following meteorological information using the yellow SWIM TI Profile:

—	Meteorological prediction of the weather at the airport concerned, at a small interval in the future: — wind speed and direction — the air temperature — the altimeter pressure setting — the runway visual range (RVR)

—	Provide Volcanic Ash Mass Concentration

—	Specific MET info feature service

—	Winds aloft information service

—

Meteorological information supporting Aerodrome ATC & Airport Landside process or aids involving the relevant MET information, translation processes to derive constraints for weather and converting this information in an ATM impact; the system capability mainly targets a ‘time to decision’ horizon between 20 minutes and 7 days.

—

Meteorological information supporting En Route/Approach ATC process or aids involving the relevant MET information, translation processes to derive constraints for weather and converting this information in an ATM impact; the system capability mainly targets a ‘time to decision’ horizon between 20 minutes and 7 days

—

Meteorological information supporting Network Information Management process or aids involving the relevant MET information, translation processes to derive constraints for weather and converting this information in an ATM impact; the system capability mainly targets a ‘time to decision’ horizon between 20 minutes and 7 days

Service implementations shall be compliant with the applicable version of AIRM, the AIRM Foundation Material and the ISRM Foundation Material.

System requirements

—	ATM systems shall be able to use the MET information exchange services

5.1.5.   Cooperative network information exchange

Operational stakeholders shall implement services which support the exchange of the following cooperative network information using the yellow SWIM TI Profile:

—	Maximum airport capacity based on current and near term weather conditions

—	Synchronisation of Network Operations Plan and all Airport Operations Plans

—	Regulations

—

Slots

—	Short term ATFCM measures

—	ATFCM congestion points

—	Restrictions

—	Airspace structure, availability and utilisation

—	Network and En-Route Approach Operation Plans

Service implementations shall be compliant with the applicable version of AIRM, the AIRM Foundation Material and the ISRM Foundation Material.

System requirements

—

The Network Manager Portal shall support all operational stakeholders in exchanging data electronically with the Network Manager; The Network Manager Portal shall support the choice of the operational stakeholders between a pre-defined online access, or connect their own applications using the system-to-system (B2B) web-technology based services

5.1.6.   Flight information exchange

Flight information shall be exchanged during the pre-tactical and tactical phases by ATC systems and Network Manager.

Operational stakeholders shall implement services which support the exchange of the following flight information as indicated in the table below using the blue SWIM TI Profile:

—

Various operations on a flight object: Acknowledge reception, Acknowledge agreement to FO, End subscription of a FO distribution, Subscribe to FO distribution, Modify FO constraints, Modify route, Set arrival runway, Update coordination related information, Modify SSR code, Set STAR, Skip ATSU in coordination dialogue

—	Share Flight Object information. Flight Object includes the flight script composed of the ATC constraints and the 4D trajectory

Operational stakeholders shall implement the following services for exchange of flight information using the yellow SWIM TI Profile:

—	Validate flight plan and routes

—	Flight plans, 4D trajectory, flight performance data, flight status

—	Flights lists and detailed flight data

—	Flight update message related (departure information)

Service implementations shall be compliant with the applicable version of AIRM, the AIRM Foundation Material and the ISRM Foundation Material.

System requirements

—	ATC systems shall make use of the flight information exchange services

5.2.   Geographical scope

iSWIM functionality shall be deployed in the EATMN as indicated in the table. In centres in the Member States that have non-integrated civil/military service provision (8), iSWIM functionality shall be deployed to the extent required by Regulation (EC) No 552/2004, point 4 of Part A of Annex II.

	Civil ANSPs (excluding MET providers)	Airports	Civil-military coordination	Airspace Users	MET providers	Network Manager
Aeronautical information exchange	Area Control Centres, TMAs and Towers identified in the Appendix	Geo-graphical scope as referred to in Point 1.2	All centres in the Member States that have non-integrated civil/military service provision (9)	AOC system providers	—	Network Manager
Meteorological information exchange	Area Control Centres, TMAs and Towers identified in the Appendix	Geo-graphical scope as referred to in Point 1.2	All centres in the Member States that have non-integrated civil/military service provision (9)	AOC system providers	All MET providers	Network Manager
Cooperative network information exchange	Area Control Centres, TMAs and Towers identified in the Appendix	Geo-graphical scope as referred to in Point 1.2	—	AOC system providers	—	Network Manager
Flight information exchange	Area Control Centres & TMAs identified in the Appendix	—	—	—	—	Network Manager

5.3.   Stakeholders required to implement the functionality and deployment target date

Operational stakeholders and the Network Manager referred to in Point 5.2 shall provide and operate the iSWIM as of 1 January 2025.

5.4.   Need for synchronisation

The deployment of Initial System Wide Information Management functionality shall be coordinated due to the potential network performance impact of delayed implementation in a wide geographical scope involving a number of stakeholders. From a technical perspective the deployment of targeted system and service delivery changes shall be synchronised to ensure that the performance objectives are met. This synchronisation shall enable changes targeted within ATM functionalities referred to in sections 1 to 4 above as well as future common projects. Synchronisation shall involve all ATM ground stakeholders (civil/military air navigation service providers, airspace users — for AOC systems, airport operators, MET Service Providers and the Network Manager. Furthermore, synchronisation during the related industrialisation phase shall take place, in particular among supply industry and standardisation bodies.

5.5.   Essential prerequisites

To support the blue SWIM TI Profile, very high and high capacity centres shall be connected to Pan-European Network Services (PENS).

5.6.   Interdependencies with other ATM functionalities

—

SWIM services enable the AMAN functionality as described in Point 1, A-FUA as described in Point 3, Network Collaborative Management functionality as described in Point 4 and flight data processing systems to flight data processing systems exchange of down-linked trajectory information between ATS units required by Initial Trajectory Information Sharing functionality referred to in Point 6

—	The implementation of SWIM infrastructure and services referred to in Point 5 facilitates the information exchange for all mentioned ATM functionalities

6.   INITIAL TRAJECTORY INFORMATION SHARING

Initial Trajectory Information Sharing (i4D) consists of the improved use of target times and trajectory information, including where available the use of on-board 4D trajectory data by the ground ATC system and Network Manager Systems, implying fewer tactical interventions and improved de-confliction situation.

6.1.   Operational and technical scope

Target times and 4D trajectory data shall be used to enhance ATM system performance.

Trajectory information and target times shall be enhanced by the use of air-ground trajectory exchange.

System Requirements

—	Equipped aircraft shall down-link trajectory information using ADS-C Extended Projected Profile (EPP)as part of the ATN B2 services; The trajectory data shall be automatically down-linked from the airborne system shall update the ATM system according to the contract terms

—	Data link communications ground systems shall support ADS-C (downlink of aircraft trajectory using EPP) as part of the ATN B2 services

—	Flight data processing systems controller working positions and Network Manager systems shall make use of downlinked trajectories

—	FDP to FDP trajectory exchange between ATS units as well as between ATS units and the Network Manager systems shall be supported using flight object exchange as defined in Point 5

6.2.   Geographical scope

Initial Trajectory Information Sharing shall be deployed in all ATS units providing air traffic services within the airspace for which the Member States are responsible in the ICAO EUR region.

6.3.   Stakeholders required to implement the functionality and deployment target dates

ATS providers and the Network Manager shall ensure that they enable Initial Trajectory Information Sharing as from 1 January 2025.

The Deployment Manager shall develop a strategy, which shall include incentives, to ensure that at least 20 % of the aircraft operating within the airspace of European Civil Aviation Conference (ECAC) countries (10) in the ICAO EUR region corresponding to at least 45 % of flights operating in those countries, are equipped with the capability to downlink aircraft trajectory using ADS-C EPP as from 1 January 2026.

6.4.   Need for synchronisation

The deployment of Initial Trajectory Information Sharing functionality shall be coordinated due to the potential network performance impact of delayed implementation in a wide geographical scope involving a number of stakeholders. From a technical perspective the deployment of targeted system and service delivery changes shall be synchronised to ensure that the performance objectives are met. This synchronisation shall enable changes targeted within ATM functionality referred to in section 1, 3 and 4 above as well as future common projects. Synchronisation shall involve all air navigation service providers, the Network Manager and airspace users (air-ground synchronisation need). Synchronisation and consistency of avionics roadmaps, in order to ensure best economic efficiency and interoperability for airspace users, is achieved through the cooperative arrangements in the Memorandum of Cooperation in civil aviation research and development concluded between the United States of America and the Union (11). Furthermore, synchronisation during the related industrialisation phase shall take place, in particular among supply industry and standardisation and certification bodies.

6.5.   Essential prerequisites

The data link capability as described in Commission Regulation (EC) No 29/2009 on data link services is an essential prerequisite for this ATM functionality.

6.6.   Interdependencies with other ATM functionalities

—	The down-linked aircraft trajectory may be used to enhance the AMAN functionality described in Point 1

—	Downlink trajectory information may be integrated into the Enhanced Short Term ATFCM Measures calculation and the Automated Support for Traffic Complexity Assessment as specified in Point 3

—	Where available downlink trajectory information shall be integrated into the NOP as specified in Point 4 to support TTO/TTA

—	iSWIM referred to in Point 5 shall enable FDP to FDP exchange of down-linked trajectory information between ATS units

---

(1)  Subject to incorporation of this Regulation into Agreement between the European Community and the Swiss Confederation on Air Transport

(2)  Subject to incorporation of this Regulation into EEA Agreement

(3)  Subject to incorporation of this Regulation into Agreement between the European Community and the Swiss Confederation on Air Transport

(4)  Subject to incorporation of this Regulation into EEA Agreement

(5)  subject to incorporation of this Regulation into Agreement between the European Community and the Swiss Confederation on Air Transport

(6)  subject to incorporation of this Regulation into EEA Agreement

(7)  Austria, Belgium, Bulgaria, Czech Republic, France, Ireland, Italy, Portugal, Romania, Slovakia and Spain

(8)  Austria, Belgium, Bulgaria, Czech Republic, France, Ireland, Italy, Portugal, Romania, Slovakia and Spain.

(9)  Austria, Belgium, Bulgaria, Czech Republic, France, Ireland, Italy, Portugal, Romania, Slovakia and Spain.

(10)  Albania, Armenia, Austria, Azerbaijan, Belgium, Bosnia and Herzegovina, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Georgia, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Moldova, Monaco, Montenegro, Netherlands, Norway, Poland, Portugal, Romania, San Marino, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, The former Yugoslav Republic of Macedonia, Turkey, Ukraine, United Kingdom

(11)  Annex 1 to Memorandum of Cooperation NAT-I-9406 between the United States of America and the European Union, SESAR-NEXTGEN cooperation for global interoperability, OJ L 89, 5.4.2011, p. 8.