CCS CoordinationAndTransferManagement

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 CoordinationAndTransferManagement service is consistent with the other CCS services. It addresses the CWP manual interactions for managing Coordination and Transfer operations, and is to be used for automatic coordination of standard conditions as well as for manual coordination of non-standard conditions. 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. Note: Only civil flights are handled by CCS services. Please note that the use of CCS CoordinationAndTransferManagement service implies the use of CCS FlightDataDistribution Service to get the output coordination and transfer information, i.e.:

- Current status of coordination and transfer of flights between the crossed controller positions (AoR)

- On-going Change proposals for those coordination and transfer

Service retired from 20/03/2023

Categorisation

Service Type

SERVICE_DESCRIPTION

Life Cycle Stage

RETIRED

Business Activity Type

INFORMATION_MANAGEMENT

Intended Consumer

CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER

Information Exchange Category

FLIGHT_INFORMATION_EXCHANGE

Provider

DSNA&ENAV

Description

DSNA: the French air navigation service provider

ENAV; the Italian air navigation service provider

Type

CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER

Point of Contact

Restricted

Contact Information

Restricted

Name

1 General operational need

Description

CCS CoordinationAndTransferManagement Service addresses the CWP manual interactions for managing Coordination and Transfer operations, and is to be used for automatic coordination of standard conditions as well as for manual coordination of non-standard conditions.It provides a set of operations to support the Coordination and Transfer process between controller positions. It addresses operations such as:-ActivateCoordination,-AssumeFlight,-CoordinationProposal,-ForceAssume,-HandOver,-...

Name

Manually activate a coordination

Description

Manually activate a coordination

Real World Effect

To manually trigger the coordination before the automatic event

Name

Assume a flight

Description

Assume a flight

Real World Effect

The control of the flight is transferred to the controller assuming it.

Name

Deassume a flight

Description

Deassume a flight

Real World Effect

To give back the control of the flight to the controller previously assuming the flight.

Name

Force assume a flight

Description

Force assume a flight

Real World Effect

To force the transfer of the control of the flight to the controller assuming it (delegation or in advance).

Name

Force Hand over a flight

Description

Force Hand over a flight

Real World Effect

Transfer at the request of an upstream responsibility with a shortcut or towards a responsibility not crossed by the flight.

Name

Hand over a flight

Description

Hand over a flight

Real World Effect

The downstream controller receiving the hand over input, is informed that the controller in charge of the flight intends to release it according to the agreed transfer conditions.

Name

Initiate a dialogue with a new coordination proposal

Description

Initiate a dialogue with a new coordination proposal

Real World Effect

The controller of the consulted responsibility receives a whatIF flight with the proposed coordination data and the coordination status of the transition is set to PROPOSED.

Name

Manually accept a coordination proposal (e.g. response to a proposal or a counter proposal)

Description

Manually accept a coordination proposal (e.g. response to a proposal or a counter proposal)

Real World Effect

The coordination status of the transition is set to ACCEPTED and the trajectory is updated taking into account the agreed coordination data (the corresponding whatIF flight is deleted from CCS).

Name

Manually reject a coordination proposal (e.g. response to a proposal or a counter proposal)

Description

Manually reject a coordination proposal (e.g. response to a proposal or a counter proposal)

Real World Effect

The coordination status of the transition is set to REJECTED (the corresponding whatIF flight is deleted from CCS).

Name

Input a verbal coordination with the downstream/upstream responsibility

Description

Input a verbal coordination with the downstream/upstream responsibility

Real World Effect

This service is used by either the upstream or the downstream controller, when the coordination agreement has to be done by phone.Once a verbal agreement has been performed, the controller must perform this operation to feed the system with a stable coordination state.

Name

Point out a flight to another responsibility

Description

Point out a flight to another responsibility

Real World Effect

The Point message is sent to highlight (ou point out) a flight to another controller(s) within the same ATSU or in adjacent ATSU.This is a PNT msg equivalent.

Name

End a PointOut notification

Description

End a PointOut notification

Real World Effect

closePointOut is used in response to a pointOut notification for formally notifying the system that the notification has been processed by the receiver.This remains a local action between the receiver and his/her system without any OLDI equivalent message. The expected output is the removal of the controller involvement in the FDD PointOut session, or the end of the PointOut session if no more controller involved.

Name

Recall a transferred flight

Description

Recall a transferred flight

Real World Effect

Operation to indicate that the upstream controller requests to recover the flight control after a handOver operation. The flight is then expected to get back into the previous state.Intra-centre operation: no OLDI msg equivalent.

Name

Request the transfer of a flight

Description

Request the transfer of a flight

Real World Effect

Operation to force in advance the request of the transfer of the flight.This is a ROF msg equivalent.

Name

Send a counter proposal after a coordination proposal

Description

Send a counter proposal after a coordination proposal

Real World Effect

Operation to forward a counter proposal from the accepting unit to the transferring one or vice versa during the coordination phase.This is basically replicating the CDN msg, but the application context is extended beyond the OLDI scope in order to possibly support counter proposal from transferring to accepting when sent to another sector of the same ATSU.

Name

Delegate the responsibility of a flight

Description

Delegate the responsibility of a flight

Real World Effect

Operation to transfer the responsibility of a flight to a controller whose responsibilities are not part of the planned control sectors list.

Name

Change the list of the planned control sectors

Description

Change the list of the planned control sectors

Real World Effect

Operation to discard the responsibilities of the originator LogicalCWP from the planned control sectors list.Once this is done, this operation allows undoing it.

Name

Request clearances

Description

Request clearances

Real World Effect

Operation from accepting unit to request some operational clearances from transferring unit

Name

Send a Hand Over proposal

Description

Send a Hand Over proposal

Real World Effect

Operation to propose the flight for hand-over to the accepting controller (unit) when required.

Name

Reject a transfer conditions proposal

Description

Reject a transfer conditions proposal

Real World Effect

Operation to indicate the manual rejection by a unit of the transfer conditions previously sent (response to a request clearances operation).

Name

Accept a transfer conditions proposal

Description

Accept a transfer conditions proposal

Real World Effect

Operation to indicate the manual acceptance by a unit of the transfer conditions previously sent (response to a hand over proposal or to a request clearances operation).

Information ownership

IPRIn accordance with their internal contractual rules on IPRs, DSNA, ENAV and skyguide retain exclusive ownership of the information contained in this document, which is to be deemed as foreground of the Coflight Cloud Services project (aiming at delivering remote flight data processing).Access to the ServiceThis service is provided to Service Consumers under a contractual basis signed between the CCS Service Provider and the Service Consumer.
Dependencies with other CCS Services

If the service consumer also consumes other CCS services, this Service shall be consumed simultaneously with the other CCS SWIM Services that are part of the contractual agreement between the service consumer and CCS service provider.
Alignment to SESAR Virtual Centre activity

This service will be updated to be as much as possible in line with the Service Definition produced by SESAR Virtual Centre activities
Service versioning

Both the SWIM Service Description documents / Protobuf files and the CCS Services are versioned.The version assigned to SSDs and to Protobuf files is composed by four digits in the form x.y.z.w.New releases are numbered according to the following rule (compared to the previous version): -w increased by one: means that some content that could be ignored by the developers changed and the changes do not affect the protobuf files generation. For example, changes in the comments or in the descriptions of services, fields and data structures.-z increased by one: means that some content is changed by adding (but not changing or removing) some messages and/or data types. The generated protobuf files are expected to be an extension of the previous one and as result they are backward compatible.-y increased by one: means that the file is changed by changing or removing some operations. The generated protobuf files are not expected to be compatible with the previous one.-x increased by one: means that the file contains a new baseline. Major changes are expected to be present.The service version is composed by 3 digits a.b.c assigned according to the following rule:- a could be 0,1,2 depending on the status of the service with respect to the SWIM registration phase:0: before the service application (as candidate)1: if candidate2: if compliant- b Increments if major changes have been done with respect to the previous version (modify/remove). No backward compatibility.- c Increments if minor changes have been done with respect to the previous version (addition/description modified). Full backward compatibility.
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.

ABI

Advanced Boundary Message
AC

Airspace Configuration
ACC

Area Control Centre
ACP

Accept Message
ACT

Activate Message
ADSP

ATM Data Service Provider
AFTN

Aeronautical Fixed Telecommunication Network
AIRM

ATM Information Reference Model
AMQP

Advanced Message Queuing Protocol
ANSP

Air Navigation Service Provider
APL

Abbreviated Flight Plan
APP

Approach
ATC

Air Traffic Control
ATCO

Air Traffic Control Officer
ATCS

Air Traffic Control Services
ATM

Air Traffic Management
ATS

Air Traffic Services
ATSU

Air Traffic Service Unit
AoR

Area of Responsibility
CCS

Coflight Cloud Services
CDN

Coordination Message
CFL

Cleared Flight Level
COF

Change of Frequency Message
COP

Coordination Point
CTM

Coordination and Transfer Management
CWP

Controller Working Position
DSNA

Direction des Services de la Navigation A0xC3 0xA9rienne (French ANSP)
EFL

Entry Flight Level
ENAV

Ente Nazionale Assistenza al Volo (Italian ANSP)
ETN

Estimated Time of Entry
ETX

Estimated Time of Exit
FABEC

Functional Airspace Block Europe Central
FDD

Flight Data Distribution
FDM

Flight Data Management
FDO

Flight Data Operator
FDPS

Flight Data Processing System
FL

Flight Level
FP

Flight Plan
HMI

human machine Interface
IAS

Indicated Airspeed
ICAO

International Civil Aviation Organization
ID

Identifier
IER

Interface Exchange Requirement
IFR

Instrument Flight Rules
IKE

Internet Key Exchange
IP

Internet Protocol
IPSEC

Internet Protocol Security protocol
JU

Joint Undertaking
KPI

Key Performance Indicator
MAS

Manual Assumption of Communications Message
MB

MegaByte
MEP

Message Exchange Pattern
NTP

Network Time Protocol
OCSP

Online Certificate Status Protocol
OE

Operational Entity
OLDI

On-line Data Interchange
OPSUP

Operational Supervision
PAC

Preliminary Activate Message
PKCS

Public Key Cryptography Standards
RAP

Referred Activate Proposal Message
RJC

Reject Message
ROCD

Rate of Climb Descend
RRV

Referred Revision Proposal Message
SDD

Service Definition Document
SESAR

Single European Sky Air Traffic Management Research
SFPL

System Flight Plan
SLA

Service Level Agreement
SSD

SWIM Service Description
SSI

Synchronous Serial Interface
SSR

Secondary Surveillance Radar
SWIM

System Wide Information Management
TBC

To Be Confirmed
TCP

Transfer Control Protocol
TI

Technical Infrastructure
TLS

Transport Level Security
UTC

Coordinated Universal Time
VC

Virtual Centre
VFR

Visual Flight Rules
XFL

Exit Flight Level

Name

Service Information Definition

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 TopicsConcerning 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-Connection management

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.
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

AdvancedCoordinationAndTransferManagementProvider

This Service Interface exposes the set of operations related to Coordination and Transfer that are not necessarily required to achieve a usual/basic interoperability level.

PROVIDER_SIDE

SYNCHRONOUS_REQUEST_RESPONSE
- deassumeFlight
  
  Operation to cancel a previous assume of a flight.
  git
  Messages
  
  DeassumeFlight
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- forceHandOver
  
  Operation to transmit the intention of releasing the flight according to the provided data..
  git
  Messages
  
  ForceHandOver
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- closePointOut
  
  closePointOut is used in response to a pointOut notification for formally notifying the system that the notification has been processed by the receiver.This remains a local action between the receiver and his/her system without any OLDI equivalent message.The originator controller is capable of ending the point session, while the designated controller is capable only to remove his OEs from the recipient list (and if there is no more recipient, the point session is ended). The exception being that it is not possible to end a point session in another OLDI ATSU because OLDI considers the "point" as a one shot distribution..
  git
  Messages
  
  ClosePointOut
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- pointOut
  
  The Point message is sent to controller(s) of the same ATSU or another ATSU to point out a flight in order to facilitate verbal coordination, irrespective of whether co-ordination has taken place.This is a PNT msg equivalent.The input of the point function shall contain the identification of the SFPL and the identification of one or several point target sector(s).The use of a reason parameter written by the originator is only allowed for Point message sent to controller(s) of the same ATSU.The main uses of the point function are:-highlight: to support vocal exchanges during the co-ordination process. In such cases, the flight is designated by the giving position, and it is highlighted on the positions managing the pointed sector(s).-manual distribution: to support the delivery of flight data to a chosen recipient: -for information, if the recipient is not within the computed informed responsibility list (e.g. to check with an adjacent position the possibility to transfer the flight to it) -to replace automatic distribution by manual distribution, when the system is degraded..
  git
  Messages
  
  PointOut
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- delegate
  
  Operation to transfer the responsibility of a flight to a responsibility that is not in the list of the planned crossed responsibilities.The input shall contain the identification of the SFPL and the name of the receiving responsibility (toSector).
  git
  Messages
  
  Delegate
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- handOverProposal
  
  Operation to propose the flight for hand-over to the accepting controller (unit) when required.This is a HOP msg equivalent.This operation is possible only if the accepting unit is another ATSU.This operation is allowed only if no clearances request is on going (either no request has been received for the flight, or otherwise it has been answered). The input shall contain one or more of the following transfer data: CFL, assigned heading, direct route clearance, assigned speed, assigned rate of Climb/Descent..
  git
  Messages
  
  HandOverProposal
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- handOverRejection
  
  Operation to propose the flight for hand-over to the accepting controller (unit) when required.This is a HOP msg equivalent.This operation is possible only if the accepting unit is another ATSU.This operation is allowed only if no clearances request is on going (either no request has been received for the flight, or otherwise it has been answered)..
  git
  Messages
  
  HandOverRejection
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- transferAcceptation
  
  Operation to indicate the manual acceptance by a unit of the transfer conditions previously sent (e.g. response to a propose hand over operation).This is an ACP msg equivalent.This operation can be a response either to a clearances request, or to a hand over proposal..
  git
  Messages
  
  TransferAcceptation
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- clearancesRequest
  
  Operation from accepting unit to request some operational clearances from transferring unit.This is a RTI msg equivalent.This operation is allowed only if no hand over proposal is on going (either no proposal has been received for the flight, or otherwise it has been answered). The input shall contain CFL, and optionally one or more of the following transfer data: CFL, assigned heading, direct route clearance, assigned speed, assigned rate of Climb/Descent..
  git
  Messages
  
  ClearancesRequest
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
Endpoints

Restricted
CoordinationAndTransferManagementProvider

This Service Interface exposes the set of basic operations needed for Coordination and Transfer.

PROVIDER_SIDE

SYNCHRONOUS_REQUEST_RESPONSE
- assumeFlight
  
  Operation to indicate the assume of the flight..
  git
  Messages
  
  AssumeFlight
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- handOver
  
  Operation to transmit the intention of releasing the flight according to the agreed transfer conditions. Depending on the LoAs: e.g. expecting a further AssumeFlight operation or just waiting for a radio contact to release the flight.This is an OLDI COF (Change Of Frequency) message equivalent.This operation also offers the possibility to hand over the flight to another crossed responsibility than the expected one (eq. shortcut forceHandOver input). In that case, it is expected to provide explicitly the new responsibility traversal to which the transfer is performed, as well as the identifier of this responsibility (available in the SFPL ControlSector list).This operation also offers the possibility to hand over the flight to a responsibility not in the list of crossed (eq. delegate input)..
  git
  Messages
  
  HandOver
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- coordinationAccept
  
  Operation to accept a coordination data proposal previously sent .
  git
  Messages
  
  CoordinationAccept
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- coordinationProposal
  
  Operation to input a dialogue with a new coordination proposal.This service is to be used by either the upstream or the downstream controller.When the proposal is initiated by the downstream, this is an OLDI CDN message equivalent. When the proposal is initiated by the upstream, this is mainly an OLDI RRV equivalent.When the proposal is initiated by the upstream, it may be a RAP message equivalent if the downstream is not yet NEAR_PLANNING and if RAP transmission is off-line authorised. Else it may be an RRV message equivalent if the downstream is at least NEAR_PLANNING.The input shall contain the identification of the SFPL, the receiving responsibility, the coordinationReference value (downstream or upstream proposal) and at least one of the following proposed coordination data: -in case of downstream proposal: Transfer Flight Level, Route (including direct to a new point), Next SSR code, COP, Time on transition point. -in case of upstream proposal: the Transfer Flight Level or the Route (including direct to a new point).In both cases, the proposal input can also contain a Supplementary Flight Level, the boundary point type and, only when sent to another sector of the same ATSU, the following tactical instructions: Heading, Speed, ROCD and CFL (the application point of tactical instructions in coordinationProposal is considered IMMEDIATE).The controller of the consulted responsibility receives a whatIF flight with the proposed coordination data and the coordination status of the transition is set to PROPOSED..
  git
  Messages
  
  CoordinationProposal
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- coordinationRejection
  
  Operation to reject a coordination data proposal previously sent.
  git
  Messages
  
  CoordinationRejection
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- activateCoordination
  
  Operation to force in advance (prior to the automatic coordination event) the triggering of the coordination event for a given transition between two responsibility traversals by sending specific flight details..
  git
  Messages
  
  ActivateCoordination
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- forceAssume
  
  Operation to indicate the assume of the flight when the protocol cannot be followed. .
  git
  Messages
  
  ForceAssume
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- coordinationManualAgreement
  
  Operation to input a verbal coordination dialogue in inter-centre..
  git
  Messages
  
  CoordinationManualAgreement
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- handOverRecall
  
  Operation to indicate that the upstream controller requests to recover the flight control after a handOver operation.The flight is then expected to get back into the previous state. However, for the receiving responsibility, there may be some exceptions (when the flight is a re-entering flight which was HANDED_OVER or RELEASED, or when it is a stolen flight which was DEASSUMED).This operation being only for intra-centre operation, there is no OLDI message equivalent..
  git
  Messages
  
  HandOverRecall
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- handOverRequest
  
  Operation performed by the accepting unit to the transferring unit, when required, to request the transfer of the flightThis is a ROF msg equivalent.It may be used:-in reply to a handOverProposal (HOP) to signify the acceptance of the flight under the proposed conditions,-or to request the early transfer of the flight..
  git
  Messages
  
  HandOverRequest
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- coordinationCounterProposal
  
  Operation to forward a counter proposal from the accepting unit to the transferring one or vice versa during the coordination phase.This is basically replicating the CDN message, but the application context is extended beyond the OLDI scope in order to possibly support counter proposal from transferring to accepting when sent to another sector of the same ATSU.Counter-proposal input is accepted only if no counter-proposal has been issued before.The input shall contain the identification of the SFPL, of downstream the responsibility of the transition on which the coordination dialogue was initiated and at least one of the following proposed coordination data: Transfer Flight Level, Route (including direct to a new point), Next SSR code, COP, Time on transition point..
  git
  Messages
  
  CoordinationCounterProposal
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
- replaceSectors
  
  Operation to discard (eq. skip) all the responsibilities* of the originator LogicalCWP from the control sectors list of an SFPL (ex. {A,B,C,D} is replaced by {A,D}, if B and C are the responsibilities of the originator LogicalCWP).*: the responsibilities of the relevant internal segment. The request shall contain the responsibility to skip in the ControlSector list (respTraversalId).The skipped LogicalCWP traversal is no more taken into account (from a frequency point of view); the upstream LogicalCWP transfers the flight directly to the downstream LogicalCWP.The skip processing does not impact the application of constraints and the trajectory prediction..
  git
  Messages
  
  ReplaceSectors
  
  IN
  
  CoordinationAndTransferResponse
  
  OUT
Endpoints

Restricted

CCS AIRM mapping CTM service

AIRM traceability for CCS Coordination And Transfer Management service payload

AIRM_TRACE

1.0
CCS Validation evidence document - CoordinationAndTransferManagement

Validation evidence for CCS Coordination And Transfer Management service

SERVICE_VALIDATION_REPORT

1.0
CCS_coordinationAndTransferManagement.proto

Protobuf files describing the exchanged information

MACHINE_READABLE_SERVICE_DESCRIPTION

5.0.0.5
CCS_common.proto

Protobuf file describing the exchanged information common to two or more CCS Services

MACHINE_READABLE_SERVICE_DESCRIPTION

5.5.1.2
metadata.proto

Protobuf file describing the metadata used by the CCS Services

MACHINE_READABLE_SERVICE_DESCRIPTION

v1.2.0.0
CCS CoordinationAndTransferManagement Service Description

Complete service specification

SERVICE_SPECIFICATION

5.2.0.9
CCS Errors Management Document

Document that includes the list of all applicable error messages for CCS services

SERVICE_SPECIFICATION

2.0

Title

EUROCONTROL Specification for SWIM - Service Description

Standard Type

EUROCONTROL_SPECIFICATION_FOR_SWIM_SERVICE_DESCRIPTION

Conformance Statement

Description of Service according to EUROCONTROL specifications

Version

2.0

Description

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

Title

EUROCONTROL Specification for SWIM - Information Definition

Standard Type

EUROCONTROL_SPECIFICATION_FOR_SWIM_INFORMATION_DEFINITION

Conformance Statement

Information definition according to EUROCONTROL specifications

Version

1.0

Description

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.

Title

EUROCONTROL Specification for SWIM - Technical Infrastructure (TI) Yellow Profile

Standard Type

EUROCONTROL_SPECIFICATION_FOR_SWIM_TECHNICAL_INFRASTRUCTURE

Conformance Statement

Implementation of service and network bindings

Version

1.0

Description

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

CCS CoordinationAndTransferManagement v 2.0.0

Categorisation

Provider