DSNA: the French air navigation service provider
ENAV; the Italian air navigation service provider
This Service is part of Coflight Cloud Services (CCS), which are primarily designed to support the Virtual Centre concept. As such, these CCS Services support the interactions between the CCS ATM Data Service Provider (ADSP) and Virtual Centre Air Traffic Service Units (ATSUs).
The CCS DatalinkManagement service is consistent with the other CCS services.
It addresses the operations for managing Datalink interface connection.
This version of the service is intended to be used in 'test mission', which aims at providing services and support to the Customer(s) to enable them to test any version of their ATM system during development.
Please note that the use of CCS DatalinkManagement service implies the use of CCS FlightDataDistribution Service to get the output Datalink interface information.
DSNA: the French air navigation service provider
ENAV; the Italian air navigation service provider
Coflight Cloud Services Program Director - To request access to the CCS service
For Incidents on services in operation, contact the Service desk [working hours/opening days] as described in the related support service (incident management) supplied by CCS provider to CCS customer during the procurement phase
CCS DatalinkManagement Service addresses the operations for managing Datalink interface connection.
It provides the capability for consumers to inform CCS that:
- an aircraft has made a Datalink logon,
- an aircraft has acknowledged an NDA message sent by the ATSU.
Datalink logon request
Datalink NDA acknowledgement
In accordance with their internal contractual rules on IPRs, DSNA, ENAV and Skyguide retain exclusive ownership of the information contained in this document and which is to be deemed as foreground of the Coflight Cloud Services project (aiming at delivering remote flight data processing).
This Service shall be consumed simultaneously with the other CCS SWIM Services
This service will be updated to be as much as possible in line with the Service Definition produced by SESAR Virtual Centre activities
As a consistent whole, the package of CCS swim services available is versioned. And each swim services is although versioned.
At least 2 versions of swim services could be maintained in the same time, taking benefit the capacities of technologies used in CCS such as protobuf.
Services management review are regularly organized with CCS customers to monitor the usability of the services and the KPI related to the quality of service described in the SLA.
The interface of CCS business services is accessible from outside DSNA premises through Internet using IPV4. An IPSEC link (IKE v1 or IKE v2) is used between CCS provider and CCS customer terminal network equipment.
The CCS provider acts as a certificate authority to provide and validate X.509 certificates. Before service operation, a package including X509 certificate and private key, will be delivered to the customer using the PKCS#12 archive file format.
Mutual authentication with X509 certificates is used between the AMQP broker and its client. Prior to any exchanges of AMQP Messages, the CCS customer shall establish with CCS Provider a TLS session using TLS 1.2 version.
-
CCS customer shall provide its certificates when establishing the connection. The certificates shall be valid (nor corrupted, nor revoked). The certificates of the CCS customer allow its identification for the use of the different CCS services (CCS business services at lower level).
-
The CCS provider transmit its complete certificate during the connection phase and allow OCSP stapling to allow the CCS customer to check if it is valid or not.
-
For the cryptographic algorithms, the authorized cipher suites must be agreed between the CCS provider and the customer based on the standards.
As an ATSU, the CCS business services customer, once identified, has access to all CCS services.
In the case of a Customer that would fail to authenticate 3 times in less than 3 minutes, the IP address would be ban and has to trigger the incident management procedure.
The service level objectives regarding the availability, response time, throughput and recoverability of CCS Services depend on the purpose (mission) for which the Customer intend to use them (e.g. integration, test, training, operational purpose).
These service level objectives are therefore negotiated with the Customers, based on their safety analysis, and are detailed in the specific Service Level Agreement established with each CCS Customer.
The minimum Bandwidth required to consume CCS services (hypothesis for the technical integration service of 300 simultaneous flight managed by the system) is 10MB/s.
Customer ATSU shall restrict the overall rate of requests to a maximum of 720 request/minutes. The detailed rate limitation per services is detailed in the associated swim service description of each service.
Prior to any Service publication in the European Swim Registry, CCS partners organise a joint validation that involve both CCS Providers and the 1st CCS Customer.
Test Cases dealing with several test topics are run using a happy flow of few flights to check that the services are consistent, compliant with the actual service description and meet the acceptance criteria formulated by the 1st CCS Customer.
Area Control Centre
Aerodrome of Departure
Aerodrome of Destination
Automatic Dependent Surveillance
ATM Data Service Provider
ATM Information Reference Model
Advanced Message Queuing Protocol
Air Navigation Service Provider
Abbreviated Flight Plan
Air Traffic Control Services
Automatic Tracking Initiation
Air Traffic Management
Aeronautical Telecommunication(s) Network
Air Traffic Service Unit
Coflight Cloud Services
Context Management
Controller Pilot Data Link Communication
Controller Working Position
Datalink
Datalink Management
Direction des Services de la Navigation A0xC3 0xA9rienne (French ANSP)
Ente Nazionale Assistenza al Volo (Italian ANSP)
Estimated Off-Block Date
Estimated Off-BlockTime
Functional Airspace Block Europe Central
Future Air Navigation Systems
Flight Data Distribution
Flight Data Management
Flight Data Operator
Flight Data Processing System
Flight Level
Flight Plan
International Civil Aviation Organization
Identifier
Interface Exchange Requirement
Internet Key Exchange
Interoperability
Internet Protocol
Internet Protocol Security protocol
Internet Protocol version 4
Joint Undertaking
Key Performance Indicator
Log-On Forwarding message
Mega byte
Next Authority Notified message
Next Data Authority
Network Time Protocol
Online Certificate Status Protocol
Operational Entity
On-line Data Interchange
Operational Supervision
Public-Key Cryptography Standards
Single European Sky Air Traffic Management Research
System Flight Plan
Service Level Agreement
SWIM Service Description
Synchronous Serial Interface
System Wide Information Management
Transfer Control Protocol
Technical Infrastructure
Transport Level Security
Coordinated Universal Time
Identifier of an aerodrome.
The identifier of an aircraft
Registration markings of the aircraft.
Address of the following applications:
- for CM application, it represents the transport layer address.
- for CPDLC, it represents the ATN address of the CPDLC application.
- for ADS, it represents the ATN address of the ADS applications.
The ATN Air-Ground application type.
Note: 0 for ADS, 2 or 22 for CPDLC and 3 for ATI.
Version of the Air-Ground application (ADS and CPDLC for FANS 1/A flights, ADS, CPDLC and ATI for ATN flights).
Note: Defined as 1{'00'|'01}1 for FANS 1/A flights (ADS and CPDLC) and as 1{'00'|'01'|'02'}1 for ATN flights (ADS, CPDLC and ATI).
Type to transmit the success code of an operation.
The value of the collection stamp.
Generic type to address comment/description/remark attributes within a long length frame.
Generic type to address comment/description/remark attributes within a medium length frame
Identification of a specific controller (originator of a request, served for SFPL distribution, target/originator of a PointSession...).
String to identify a controller.
Common Technical class
Data link ATN or FANS 1/A logon parameters.
Note: When an aircraft did not indicate that it wants to use one of the applications, the associated AppVersion is set to "00" and the associated application address field is omitted in the LOF.
Date, expressed in string ("YYMMDD")
Identifier of the error.
A string supporting the value of a parameter in an error description.
Flight Identifier
Type supporting a unique flight identifier that can be : an internal flight Id assigned by the FDPS, an IFPLIdentifier, an aircraftRegistration, a flightNumber...
24-bit address unequivocally identifying an aircraft and assigned by the State where an aircraft is registered in accordance with standards established by ICAO for Mode S transponders.
Other operational entity mapped on the originator working position.
Note: Even if the originator is a single controller, he may belong to a logical position composed of several operational entities (several Role/Responsibility couples).
Report returned by the service provider following a controller's request.
The version number of an item.
Time expressed in HHMM
Number of milliseconds since the Unix epoch time - 00.00 hours - Jan, 1st, 1970 (UTC).
Set of parameters defined for the Datalink logon request operation.
The DatalinkManagementResponse consists mainly of a result code and a description detailing a reason text.
Unique identifier of the SFPL made of basic flight plan fields: callsign, ADEP, ADES, EOBT.
Set of parameters defined for the NDA Acknowledgement request operation.
Mutual authentication with X509 certificates is used between the AMQP broker and its client established within a TLS session
TLS 1.2 is used to provide confidentiality and integrity at transport layer.
IPsec is used to provide confidentiality, authentication and integrity at network (internet) layer
CCS provider and CCS customer use the date and time for the operation of each service and they must be able to date the traces and the information passed to the SSI log collector.
NTP is the standard solution to synchronize time accurately. So, CCS Provider and CCS Customer should use, each of them, at least one NTP server (stratum N), integrated in a NTP network containing a stratum 0 reference time clock.
Each services interface of the CCS business services relies on the concept of AMQP queues and topics.
-
The CCS customer shall use an implementation of the AMQP 1.0 specification to connect to the CCS provider AMQP 1.0 endpoint.
-
The CCS provider endpoint is an AMQP 1.0 broker managing queue and topics.
The message payloads are encoded following a protobuf format.
The message exchange patterns used by the CCS services are request/reply and publish/subscribe. The CCS customer acts as requester and subscriber. The CCS provider acts as responder and publisher.
Concerning publish-subscribe, the CCS customer subscribes to a CCS distribution service by directly listening to an appropriate AMQP topic, which name follows the CCS derivation rules.
The subscription to CCS Distribution Services is not performed via subscription operations, but by connecting to the appropriate AMQP Topic described in the .protobuf files as topic://..
The subscribers can filter the messages they want to receive by using the filter parameters defined for each subscription operation.
Please note that, after subscribing to a CCS Distribution Service, the current repository of messages needs to be obtained from CCS via the get operation defined for each CCS Distribution Service (see "Subscription" section of the distribution operation of the service).
N.B:
- If the CCS platform restarts while the Customer is connected to the AMQP Broker, the current repository of messages is published again.
- The acknowledgement that a Customer receives to his request ("RequestReport") may be received after the data distribution that this request has triggered, as these two messages are managed asynchronously by AMQP Queues and Topics
Concerning request-reply the CCS customer sends a request by sending a message to an appropriate AMQP queue, which name follows the CCS derivation rules, to make a request. The request message contains the name of the queue into the CCS customer listens and in which the reply from the CCS provider is expected.
The Customer is the one that initiates the TCP connection and in case of a Network / Connection failure, it is the responsibility of the CCS customer to try to reconnect regularly.
The AMQP broker creates the physical resources associated with a destination (queue, topic) on demand when messages are actually sent to them.
Permissions on queues and topics (read/write access) are granted based on intended usage. The CCS customer will have:
-
Write access on the request queue
-
Read access on the reply queue
-
Read access on the topic for distribution service
This Service Interface exposes a set of basic operations needed for Datalink connection.
This operation allows a generic client (eq. Air Server system) to inform that an aircraft has made a Datalink logon and to associate the corresponding logon parameters with an SFPL..
This operation allows a generic client to inform that an aircraft has acknowledged an NDA message sent by the ATSU..
For security reasons, the addresses will be communicated only to Customers
Information is exchanged in Protobuf format. Protocol buffers or Protobuf are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data similar to XML, but smaller, faster, and simpler.
The detailed behavior of the service is provided in each operation dedicated section
This specification contains requirements for describing information services in the context ofInitial System Wide Information Management (iSWIM). The requirements prescribe the minimum set of elements a service descriptionhas to contain
EUROCONTROL-SPEC-168
This specification contains requirements forinformation definitions, meaning the formal descriptions of exchanged information, in the context of Initial System Wide Information Management (iSWIM). This contributes to semantic interoperability of information.
EUROCONTROL-SPEC-169
This specification contains requirements for system interfaces (e.g. protocols) and for IT infrastructure capabilities required to enable a reliable, secure and efficient exchange of information in the context of Initial System Wide Information Management (iSWIM).This contributes to technical interoperability
EUROCONTROL-SPEC-170