Categorisation
SERVICE_DESCRIPTION
PROSPECTIVE
- TRAFFIC_SYNCHRONISATION
- CIVIL_AIRSPACE_USER
- AIR_TRAFFIC_SERVICE_PROVIDER
- AIRPORT_OPERATOR
- FLIGHT_INFORMATION_EXCHANGE
Provider
DSNA
DSNA (Direction des Services de la Navigation Aerienne) is the national air navigation services provider of France.
DSNA is entrusted with the provision of air traffic services, associated communication, navigation and surveillance services and aeronautical information services in all airspace under French responsibility and at designated airports. DSNA is member of A6, FABEC and SESAR JU.
Paris ACC : At the crossroads of the biggest European platforms, Paris ACC manage one of the densest airspace in Europe. Paris ACC act to develop Paris airports capacity. The traffic handled by Paris ACC consists of 72% of flights departing or arriving at Parisian airports. With its 1.3 million controlled flights in 2018, Paris ACC is one the most important ACC in Europe.
Core business is to manage the regulated Air Traffic Control Services (ATCS), for which it is entrusted, allowing aircraft to fly within the assigned airspace with constantly enhanced levels of safety, optimizing the effectiveness of the service provided and the efficiency of the company"
Restricted
Restricted
COMMISSION IMPLEMENTING REGULATION (EU) No 716/2014
the service is defined to satisfy the requirement Arrival Management extended to en-route Airspace. The Implementing Regulation requires the upgrade of existing AMAN to provide connection with cooperative En-Route Air Traffic Service Units (ATSU) to coordinate the actions to be taken by the cooperative ATSUs to make the correct time adjustment to flights under their control, in order to get the best and most efficient arriving flight sequence at the relevant airports based on AMAN arriving planning tool.
Publish arrival sequence
Publication of current arrival sequence information
All subscribers are informed of any change about the arrival sequence of one or more airports, according to their subscription parameters.
-
Business and operational policiesBusiness and operational policies are defined in the Service Agreement.
-
Versioning PolicyService update: This service will be updated when new operational needs are identified. Please get in touch with the Service Provider/Consumer Point of Contact for any evolution request regarding this Service. Backwards compatibility is guaranteed between minor versions but not for major. Given a version number MAJOR.MINOR.PATCH, DSNA will increment: the MAJOR version number when incompatible API changes occur, the MINOR version number when functionality evolve in a backwards compatible manner, the PATCH version number when backwards compatible bug fixes occur.
-
Lifecycle PolicyDSNA will manage 3 versions of the service: Versions N (i.e. nominal version of the service) and N-1 (if existing) provided by the operational system, Version N-1 will be removed when all consumers have migrated to the nominal version of the service or when the version N+1 is commissioned (Constraint of evolutivity). Version N or N+1 (if existing) provided by a pre-operational (preops) system. Please get in touch with the Service Provider / Consumer Point of Contact for any evolution request regarding this Service.
-
Access to the serviceThe access to the service is subject to the signature of a Service Agreement between DSNA and the Recipient. Please contact DSNA SWIM Services Responsible (§1.2) for more information.
-
Service consumption constraintsTwo access points are provided for access to the service from Internet: One operational access point associated with the operational system (standard WSDL and amqps endpoint). One pre-operational access point associated with the pre-operational system (PREOPS WSDL and amqps endpoint). The certificate provided by DSNA is specific to the service and the endpoint (operational or pre-operational). Consumer must not use an operational certificate to invoke the pre-operational system. One subscription per certificate (and as a consequence, one AMQP connection).
-
ConfidentialityCommunications are secured by TLS protocol. Communications (HTTPS and AMQPS) are secured by the TLS v1.2 protocol. SSL, TLS v1 to v1.1 versions are not supported. Suites using the AES -256 or ChaCha20 block cipher algorithm are preferred. The AES-128 algorithm is an acceptable alternative. Suites using the SHA2 and later hash functions are the only ones supported. Communications (HTTPS and AMQPS) require mutual authentication of the correspondents based on X-509 certificates (see § Authentication): The consumer must provide its full certificate during the connection phase. This certificate must not have been corrupted or revoked. The consumer's certificate also allows identification and secure access to the only distribution channel linked to its subscription. The server also transmits its full certificate during the connection phase.
-
IntegrityCommunication integrity is guaranteed by TLS encryption.
-
AuthentificationX.509 certificate All communications are secured by mutual authentication of correspondents using X.509 certificates. A consumer is entitled to one subscription per X.509 certificate and therefore one AMQP connection. The lifetime of a subscription and therefore of an AMQP connection is limited by the expiry date of the certificate. Upon service restart, active subscriptions are not lost. The certificates are issued to the consumer by the DSNA during the service contractualisation phase. Certificates have an expiry date and their renewal must therefore be managed in advance by both parties. Transport authentication: TLS with mutual authentication and SASL ANONYMOUS.
-
AuthorisationThe consumer is authorized to access any Arrival Sequence information using a valid X.509 certificate associated with the Arrival Sequence Distribution Service (see Authentication).
-
A-CDMAirport CDM (Collaborative Decision Making)
-
AMANArrival management
-
APTOAMAN Planned Time Over
-
APTTAMAN Planned Threshold Time
-
ATLDTAMAN Target Landing Time
-
EHExtended Horizon
-
EUROCAEEuropean Organisation for Civil Aviation Equipment
-
IAFInitial Approach Fix
-
MPMetering Point
-
OSEDOperational Services & Environment Description
-
RWYRunway
-
SOAPService Oriented Architecture Protocol
-
STAScheduled Time of Arrival
-
SWIM TISWIM Technical Infrastructure
-
TMATerminal Manoeuvring Area
-
TODTop Of Descent
-
TTGTime To Gain
-
TTLTime To Lose
-
URLUniform Resource Locator
-
WSDLWeb Services Description Language
-
XSDSML Schema Definition
-
List of available arrival sequencesFind below the list of available arrival sequences or ADES codes that can be used in subscription requests or that can be present in received messages. CDG : LFPG, LFPB; Orly : LFPO, LFPN, LFPV.
-
Sizing and performanceFor each selected ADES, a consumer must be able to receive one message every 15 sec. (standard sequence calculation period) without generating congestion in its queue. Unprocessed messages will be automatically suppressed after expiration of time to live (TTL) delay. This behavior is not critical due to the cyclical nature of the arrival sequence calculation (see ED-254-REQ 0870). The use of a message listener with deferred processing is recommended in this case. The consumer infrastructure must be able to handle the resulting flow rate from their subscription. The filter capability of the subscription request can be used to reduce the resulting flow rate (remove uninteresting ADES or flights). Find below some orders of magnitude for arrival sequence message size and associated flow rate (calculation period 15 sec.). Flights in the sequence Sequence size (bytes) Flow rate (with protocol overhead) (kb/s) Average ADES situation 40 44550 24 Loaded ADES situation 20 220550 118 The following values are given as a guide: Constant Indicative Value MAX_DELIVERY_TIME (cf. ED-254-REQ 0800, 0805) 10 sec MAX_CONSUMER_NUMBER (cf. ED-254-REQ 0885) 100 (no clear value identified at this stage)
-
ArrivalSequenceInformationPublisherSubscription management interface.The service consumer is able to subscribe and unsubscribe to the arrival sequence information and by using the same interface, the consumer is able to send problem reports.PROVIDER_SIDESYNCHRONOUS_REQUEST_RESPONSE
-
subscribeToArrivalSequenceInformationSOAP subscription OperationgitMessages
-
subscribeToArrivalSequenceInformationRequestIN
-
subscribeToArrivalSequenceInformationResponseOUT
-
-
unsubscribeToArrivalSequenceInformationSOAP unsubscription OperationgitMessages
-
unsubscribeToArrivalSequenceInformationRequestIN
-
unsubscribeToArrivalSequenceInformationtResponseOUT
-
unsubscribeToArrivalSequenceInformationtResponseOUT
-
-
communicateProblemOperation to log a problem in the DSNA monitoring systemgitMessages
-
communicateProblemRequestOUT
-
EndpointsRestricted
-
-
ArrivalSequenceInformationSubscriberDSNA Arrival Sequence Service - Data distribution interfaceCONSUMER_SIDE
-
publishArrivalSequenceOperation to transmit the ArrivalSequence message to the service consumergit
-
communicateExceptionOperation to inform the service consumer about problems occurring, at service run-time, on provider side.git
EndpointsRestricted
-
Arrival Sequence Service Performance Standard
SERVICE_STANDARD
Conformant
June 2018
Standardised SWIM service design for an AMAN Sequence Service. (available standard by EUROCAE: https://eshop.eurocae.net/eurocae-documents-and-reports/ed-254/)
This EUROCAE standardised service design follows the specification documents for service descriptions as provided by EUROCONTROL. Together with them, it can be used as a basis to implement SWIM Service instances.