CCS CorrelationDistribution 1.4.0

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.

Service Type
SWIM_CANDIDATE
Lifecycle Stage
PROSPECTIVE
Business Activity Type
INFORMATION_MANAGEMENT
Intended Consumer
CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER
Information Exchange Category
FLIGHT_INFORMATION_EXCHANGE
Application Message Exchange Pattern
PUBLISH_SUBSCRIBE
SYNCHRONOUS_REQUEST_REPLY
Aerodrome ICAO Location Indicator
No Information Provided
FIR ICAO Location Indicator
No Information Provided
State ICAO Nationality Letters
No Information Provided
In-Operation Date
No Information Provided
Provider
DSNA&ENAV

DSNA: the French air navigation service provider

ENAV; the Italian air navigation service provider

Provider Type
CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER
Support
No Information Provided
Point of Contact
Guillaume Ramonet
Coflight Cloud Services Program Director - To request access to the CCS service
Email
Guillaume.Ramonet@aviation-civile.gouv.fr
Telephone
No Information Provided
Service Desk
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
Email
No Information Provided
Telephone
No Information Provided
General operational need
Operational Need

CCS FlightDataDistribution Service supports:

- the distribution of Flight Plan information every time an update of a relevant Flight Plan is processed by the ADSP,

- the distribution of Erroneous AFTN messages information every time an AFTN message reception fails Coflight checks.

Publish all correlation data
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.
Publish correlation data
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
Information ownership
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).
Service versioning
As a consistent whole, the package of CCS swim services available is versioned. And each swim service 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.
KPIs monitoring
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.
Confidentiality and integrity
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.
Authentication and authorisation
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.

Services level objectives
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.
Network performance
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.
Rate limitation
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.
COLLABORATIVE_VALIDATION
It has been complemented by COLLABORATIVE_VALIDATION with operational service consumers. The whole process is bieng supervised under EASA Authority.
Concepts
No Information Provided
ADSP
ATM Data Service Provider
ASSR
Assigned Secondary Surveillance Radar
CPR
Correlated Position Report
FDPS
Flight Data Processing System
IPV4
Internet Protocol version 4
Information
BooleanType
AIRM Conformant
Off
AIRM Version
No Information Provided
Boolean
CollectionStampType
AIRM Conformant
Off
AIRM Version
No Information Provided
The value of the collection stamp.
FlightIdentifier
AIRM Conformant
Off
AIRM Version
No Information Provided
Flight Identifier
FlightIdentifierType
AIRM Conformant
Off
AIRM Version
No Information Provided
Type supporting a unique flight identifier that can be : an internal flight Id assigned by the FDPS, an IFPLIdentifier, an aircraftRegistration, a flightNumber...
Stamp
AIRM Conformant
Off
AIRM Version
No Information Provided
Common class Stamp of an item: the stamp identifies a version of an item (e.g. an SFPL, a mapping...).
SystemAreaCodeType
AIRM Conformant
Off
AIRM Version
No Information Provided
The System Area Code (SAC) centrally maintained and allocated to a specific region. Hexa value on 2 chars.
SystemIdentificationCodeType
AIRM Conformant
Off
AIRM Version
No Information Provided
The System Identification Code (SIC) allocated nationally by the responsible Air Traffic Services Organisation. 0 to 256 range.
SystemTrackIdentifierType
AIRM Conformant
Off
AIRM Version
No Information Provided
Identification of a track as defined by Asterix062.
TechStampType
AIRM Conformant
Off
AIRM Version
No Information Provided
The version number of an item.
TimeStampDateType
AIRM Conformant
Off
AIRM Version
No Information Provided
Number of milliseconds since the Unix epoch time - 00.00 hours - Jan, 1st, 1970 (UTC).
TrackIdentifier
AIRM Conformant
Off
AIRM Version
No Information Provided
Radar track identifier
TrackSourceNameType
AIRM Conformant
Off
AIRM Version
No Information Provided
Type supporting the name of the surveillance system.
AllCorrelationDataMessage
AIRM Conformant
Off
AIRM Version
No Information Provided
The AllCorrelationDataMessage contains the correlation status of all flights in the system.
CodeCorrelationAmbiguityType
AIRM Conformant
Off
AIRM Version
No Information Provided
Define the types of ambiguity that may be detected during the automatic correlation process.
CodeCorrelationStatusType
AIRM Conformant
Off
AIRM Version
No Information Provided
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.
CodeReasonAutomaticallyDecorrelatedType
AIRM Conformant
Off
AIRM Version
No Information Provided
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.
CorrelationAmbiguityData
AIRM Conformant
Off
AIRM Version
No Information Provided
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.
CorrelationData
AIRM Conformant
Off
AIRM Version
No Information Provided
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.
CorrelationDataMessage
AIRM Conformant
Off
AIRM Version
No Information Provided
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
Exchange Schema
TLS 1.2
TLS 1.2 is used to provide confidentiality and integrity at transport layer.
IPsec v4
IPsec is used to provide confidentiality, authentication and integrity at network (internet) layer
Time synchronisation
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.
Provider-Customer interface-Exchange patterns
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.
Provider-Customer interface-Queue management
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
CCS services are supervised in real time by trained and licensed ATSEPS. A dedicated service to supervise the complete CCS swim services portfolio is available to the customer.
For more information, please refer to the swim service description of the CCS technical supervision distribution service
CorrelationDistributionProvider
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
getRepository
Allows a consumer to get the applicable data related to flight correlation status.
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.
No Information Provided
Service behaviour
The detailed behavior of the service is provided in each operation dedicated section
CorrelationDistributionSubscriber
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
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.
No Information Provided
Service behaviour
The detailed behavior of the service is provided in each operation dedicated section
References
No Information Provided
Revision Save Date
Mon, 05/03/2021 - 14:06
Revision Number
55946