DSNA&ENAV
DSNA: the French air navigation service provider
ENAV; the Italian air navigation service provider
Abstract
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 CorrelationDistribution service is consistent with the other CCS services.
It supports the distribution of correlation information for flights when it is updated and periodically, if required, for all flights to increase the resilience of the service.
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.
Provider
Provider Type
CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER
Point of Contact
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
General
Operational Needs
Operational Need
CCS CorrelationDistribution Service supports the distribution of correlation information for each flight in the area of interest of the system instance when it is updated and periodically, if required, for all flights to increase the resilience of the service.
This Service fulfils the following requirement: REQ-16.03-FRD-FC03.0002 (source SESAR 2020 FRD - PJ.16-03 solution, edition 01.00.00)
Functionality
Description
Publish correlation data
Real World Effect
All subscribers are informed of any change on the correlation status of a flight when it is updated
Description
Publish all correlation data
Real World Effect
All subscribers are periodically informed of the correlation status of all flights, and thus are aware of the latest correlation status of all flights.
Access and Use
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.
Quality of Service
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.
Validation
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.
Following Topics have been successfully assessed by the Customer (TBC):
- Distribution of non-correlated flight plan status
- Automatic correlation on ASSR
- Periodic correlation status distribution
- Correlation termination after flight termination
- Correlation termination after track deletion
Abbreviations
Area Control Centre
ATM Data Service Provider
ATM Information Reference Model
Advanced Message Queuing Protocol
Air Navigation Service Provider
Assigned Secondary Surveillance Radar
Air Traffic Control
Air Traffic Control Officer
Air Traffic Control Services
Air Traffic Management
Air Traffic Service Unit
Coflight Cloud Services
Correlation Distribution
Correlated Position Report
Controller Working Position
Direction des Services de la Navigation Aerienne (French ANSP)
Ente Nazionale Assistenza al Volo (Italian ANSP)
En route
Functional Airspace Block
Flight Data Processing System
Flight Plan
International Civil Aviation Organization
Identifier
Interface Exchange Requirement
Internet Key Exchange
Internet Protocol
Internet Protocol Security protocol
Internet Protocol version 4
Joint Undertaking
Key Performance Indicator
Mega byte
Network Time Protocol
Online Certificate Status Protocol
Public-Key Cryptography Standards
System Area Code
Service Definition Document
Single European Sky Air Traffic Management Research
System Flight Plan
System Identification Code
Service Level Agreement
SWIM Service Description
Synchronous Serial Interface
Secondary Surveillance Radar
System Wide Information Management
To Be Confirmed
Transfer Control Protocol
Technical Infrastructure
Transport Level Security
Coordinated Universal Time
Information
Information Definition
Boolean
AIRM Conformant
False
The value of the collection stamp.
AIRM Conformant
False
The data source identifier
AIRM Conformant
False
Flight Identifier
AIRM Conformant
False
Type supporting a unique flight identifier that can be : an internal flight Id assigned by the FDPS, an IFPLIdentifier, an aircraftRegistration, a flightNumber...
AIRM Conformant
False
Common class
Stamp of an item: the stamp identifies a version of an item (e.g. an SFPL, a mapping...).
AIRM Conformant
False
The System Area Code (SAC) centrally maintained and allocated to a specific region.
Hexa value on 2 chars.
AIRM Conformant
False
The System Identification Code (SIC) allocated nationally by the responsible Air Traffic Services Organisation.
0 to 256 range.
AIRM Conformant
False
Identification of a track as defined by Asterix062.
AIRM Conformant
False
The version number of an item.
AIRM Conformant
False
Number of milliseconds since the Unix epoch time - 00.00 hours - Jan, 1st, 1970 (UTC).
AIRM Conformant
False
Radar track identifier
AIRM Conformant
False
Type supporting the name of the surveillance system.
AIRM Conformant
False
The AllCorrelationDataMessage contains the correlation status of all flights in the system.
AIRM Conformant
False
Define the types of ambiguity that may be detected during the automatic correlation process.
AIRM Conformant
False
This defines the correlation status of a flight. If the flight is UNCORRELATED it indicates that the automatic correlation process has not started, has been initiated but not completed or has failed.
AIRM Conformant
False
This provides the reason that a flight has been automatically decorrelated:
- FLIGHT_TERMINATED: De-correlation performed when the SFPL flightPlanStatus becomes TERMINATED.
- TRACK_DROP: De-correlation performed upon loss of the system track.
UNEXPECTED_CODE: De-correlation performed when the system track SSR code changes to a code that is not the current SSR code, nor the following SSR code, nor an emergency SSR code.
AIRM Conformant
False
This class is present when the automatic correlation process failed because it was unable to identify a unique relationship between a single SFPL and a single system track via the SSR code assigned to the SFPL. This would occur under the following circumstances:
ONESFPL_MANYTRACKS - multiple tracks within the SFPL's correlation search volume are squawking the SSR code assigned to the SFPL.
MANYSFPL_ONETRACK - A track update is received whose received SSR code is assigned to multiple SFPLs that meet the correlation criteria.
MANYSFPL_MANYTRACKS - there are multiple SFPLS and tracks that meet the correlation criteria, i.e. the SFPLs are assigned the same code and multiple tracks are squawking that same code in the region where
If there are multiple tracks that meet the correlation criteria for an SFPL then the relevant track identifiers are provided in the correlation ambiguousTrackData.
If there are multiple flights that meet the correlation criteria for an SFPL then the relevant flight identifiers are provided in the correlation ambiguousFlightData.
Ambiguous correlation issues usually require manual intervention by a controller. For example, the ONESFPL_MANYTRACKS case means that at least one aircraft is squawking the wrong code. This may be a transient situation because the transponder of an aircraft was not put into Standby mode when changing codes or simply that an aircraft has entered the wrong code. In the former case it may resolve itself but in the latter case a controller will have to identify the aircraft involved and resolve the situation manually.
AIRM Conformant
False
The CorrelationData class consists of the correlation information related to a given flight: correlationStatus, FlightIdentifier, optionally the TrackIdentifier, and CorrelationAmbiguityData (present in case of ambiguity only)...
CCS starts distributing correlation data for an SFPL when this SFPL is eligible for correlation or if it is MANUALLY_CORRELATED.
An SFPL is eligible for correlation if the following conditions are satisfied:
- it is not CORRELATED,
- at least one internal segment of the system instance is PENDING or LIVE (e.q "pre-active" or "active" in Coflight) or one external segment of the system instance is LIVE (e.q "in-use" in Coflight),
- it has at least an SSR Code to be correlated (in the SSR Code sequence computed for this SFPL, an SSR Code has not yet been used for correlation or has been used, then decorrelated).
Notes:
- To be eligible for correlation with Mode S tracks, an SFPL has to be Mode S equipped.
- An SFPL without controlled segments cannot have an SSR code to be correlated, therefore it is not eligible for correlation.
AIRM Conformant
False
The correlationDatamessage is sent when a flight is correlated or decorrelated to/from a system track as a result of an AUTOMATIC or MANUAL correlation or decorrelation
AIRM Conformant
False
Technical
Security Mechanism
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
Technical Constraint
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
Monitoring Description
<p>CCS services are supervised in real time by trained and licensed ATSEPS.</p><p></p><p> A dedicated service to supervise the complete CCS swim services portfolio is available to the customer.</p><p>For more information, please refer to the swim service description of the CCS technical supervision distribution service</p><p></p>
Interfaces
This Service Interface exposes the technical operation that allows the consumer to get the current correlation status of all flights on request. It is typically used when starting the Service, for initialisation.
PROVIDER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
Allows a consumer to get the applicable data related to flight correlation status.
Endpoints
Address
For security reasons, the addresses will be communicated only to Customers
Interface Binding Description Overview
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.
Behaviour
This Service Interface exposes two operations for publishing updates of correlation status, either immediately on a specific flight when updated, or periodically for all flights.
PROVIDER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
FIRE_AND_FORGET
Operations
This operation periodically sends the correlation status for all flights to subscribers, and thus they are aware of the latest correlation status of all flights.
Correlation data are sent every 4 seconds (time period of radar updates).
CCS starts distributing correlation data for an SFPL when this SFPL is eligible for correlation or if it is MANUALLY_CORRELATED..
This operation sends the correlation status of a flight when it is updated.
CCS starts distributing correlation data for an SFPL when this SFPL is eligible for correlation or if it is MANUALLY_CORRELATED..
Endpoints
Address
For security reasons, the addresses will be communicated only to Customers
Interface Binding Description Overview
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.
Behaviour
References
Service Documents
Service Description Document (SDD) from PJ.16-03 on which the CCS Service is based
Protobuf files describing the exchanged information
Complete service specification
Implemented Standards
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
Reference
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.
Reference
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
Reference
EUROCONTROL-SPEC-170
Revision Save Date
Thu, 12/23/2021 - 13:48
Revision Number
114131
The service description has currently reached the "PUBLISHED" status.