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 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.
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 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
SYNCHRONOUS_REQUEST_REPLY
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 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,
-...
Functionality
Description
Manually activate a coordination
Real World Effect
To manually trigger the coordination before the automatic event
Description
Assume a flight
Real World Effect
The control of the flight is transferred to the controller assuming it.
Description
Deassume a flight
Real World Effect
To give back the control of the flight to the controller previously assuming the 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).
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.
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.
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.
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).
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).
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.
Once a verbal agreement has been performed, the controller must perform this operation to feed the system with a stable coordination state.
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.
This is a PNT msg equivalent.
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.
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.
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.
The flight is then expected to get back into the previous state.
Intra-centre operation: no OLDI msg equivalent.
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.
This is a ROF msg equivalent.
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.
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.
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.
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.
Once this is done, this operation allows undoing it.
Description
Request clearances
Real World Effect
Operation from accepting unit to request some operational clearances from transferring unit
Description
Send a Hand Over proposal
Real World Effect
Operation to propose the flight for hand-over to the accepting controller (unit) when required.
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).
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).
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.
Abbreviations
Advanced Boundary Message
Airspace Configuration
Area Control Centre
Accept Message
Activate Message
ATM Data Service Provider
Aeronautical Fixed Telecommunication Network
ATM Information Reference Model
Advanced Message Queuing Protocol
Air Navigation Service Provider
Abbreviated Flight Plan
Approach
Air Traffic Control
Air Traffic Control Officer
Air Traffic Control Services
Air Traffic Management
Air Traffic Services
Air Traffic Service Unit
Area of Responsibility
Coflight Cloud Services
Coordination Message
Cleared Flight Level
Change of Frequency Message
Coordination Point
Coordination and Transfer Management
Controller Working Position
Direction des Services de la Navigation A0xC3 0xA9rienne (French ANSP)
Entry Flight Level
Ente Nazionale Assistenza al Volo (Italian ANSP)
Estimated Time of Entry
Estimated Time of Exit
Functional Airspace Block Europe Central
Flight Data Distribution
Flight Data Management
Flight Data Operator
Flight Data Processing System
Flight Level
Flight Plan
human machine Interface
Indicated Airspeed
International Civil Aviation Organization
Identifier
Interface Exchange Requirement
Instrument Flight Rules
Internet Key Exchange
Internet Protocol
Internet Protocol Security protocol
Joint Undertaking
Key Performance Indicator
Manual Assumption of Communications Message
MegaByte
Message Exchange Pattern
Network Time Protocol
Online Certificate Status Protocol
Operational Entity
On-line Data Interchange
Operational Supervision
Preliminary Activate Message
Public Key Cryptography Standards
Referred Activate Proposal Message
Reject Message
Rate of Climb Descend
Referred Revision Proposal Message
Service Definition Document
Single European Sky Air Traffic Management Research
System Flight Plan
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
Virtual Centre
Visual Flight Rules
Exit Flight Level
Information
Information Definition
Airspeed value expressed in knot or in mach.
AIRM Conformant
False
The name by which the route is known.
AIRM Conformant
False
Code describing how the boundary between two ATC volumes will be crossed.
AIRM Conformant
False
The direction types:
- DOWNSTREAM: coordination data for a downstream transition.
- UPSTREAM: coordination data for an upstream transition.
AIRM Conformant
False
Type to transmit the success code of an operation.
AIRM Conformant
False
A code describing the release indications.
AIRM Conformant
False
Code describing the different modes of surveillance.
- MODE_3A : The identification of an aircraft as reported by its SSR transponder. This 12-bits code is manually set by the pilot on request of ATC. This code is often called the 'squawk identification' and is usually represented as 4 octal digits (e.g. 0627). Special codes are reserved for emergency situations (7500 = hijack, 7600 = radio failure, 7700 = general emergency). (often abbreviated as: SSR code).
- MODE_A-C : The altitude of an aircraft as reported by its SSR transponder expressed in flight levels. Possible values are between FL 12 and FL 1267.
- MODE_S : An enhanced mode of SSR which permits the interrogation of SSR equipped aircraft and addressed interrogations with two way data exchange for suitably equipped aircraft
- INTERMODE : aircraft mode S equipped that can answer to mode A or mode C interrogations.
AIRM Conformant
False
The value of the collection stamp.
AIRM Conformant
False
Generic type to address comment/description/remark attributes within a long length frame.
AIRM Conformant
False
Generic type to address comment/description/remark attributes within a medium length frame
AIRM Conformant
False
Identification of a specific controller (originator of a request, served for SFPL distribution, target/originator of a PointSession...).
AIRM Conformant
False
String to identify a controller.
AIRM Conformant
False
Indicates the direction of the coordination proposal.
The CoordinationData of real SFPL are always from the entry to the exit sector.
AIRM Conformant
False
Identifier of the error.
AIRM Conformant
False
A string supporting the value of a parameter in an error description.
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
The flight level to climb/descend to.
AIRM Conformant
False
Geographical Point definition of a Significant Point.
AIRM Conformant
False
Heading type angle in degrees, with True North as reference
AIRM Conformant
False
A string of points (and connecting airways or DCTs where applicable) describing an ATS route or path of xes no more than 30 minutes ying time or 200nm apart, including those points where a change of speed, level, track, or flight rules is planned. Points can be listed by their coded designator (i.e. LN, MAY, HADDY), a 7 or 11-character representation of their coordinates (i.e. 46N078W, 4620N07805W), or a point relative to a reference point based on bearing and distance (i.e. DUB190040 being 40nm out on the 190 degree magnetic bearing from DUB). Change of speed and/or level is indicated by appending data formatted as in 15 CRUISING SPEED and LEVEL to a point, after a slash (i.e. MAY/N0305F180, 46N078W/M082F330). Change of flight rules are shown by a standalone VFR or IFR to indicate the beginning of that phase of flight.
AIRM Conformant
False
Simple class providing an IAS value.
AIRM Conformant
False
Simple class providing a mach value.
AIRM Conformant
False
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).
AIRM Conformant
False
Integer to identify a PointSession.
AIRM Conformant
False
Published Point definition of a Significant Point.
AIRM Conformant
False
Rate of Climb or Decent, respectively + or -.
Expressed in Feet/Minute
AIRM Conformant
False
Radial Point definition of a Significant Point.
AIRM Conformant
False
Express the reason of distribution
AIRM Conformant
False
Report returned by the service provider following a controller's request.
AIRM Conformant
False
String to identify a Responsibility.
AIRM Conformant
False
Common class
A route element may be either an airway or (exclusive) a significant point .
Upstream or downstream truncation of an airway to be used is to be made in conjunction with a previous or next RouteElement providing the corresponding point.
(Limitation CCS)
AIRM Conformant
False
String identifying a route point.
This is the identifier of an expanded route point.
AIRM Conformant
False
The number assigned to a particular multiple pulse reply signal transmitted by a transponder in Mode A or Mode C.
AIRM Conformant
False
Mode A/S value of the transponder.
4-digit octal representation
AIRM Conformant
False
In general Sector items manipulated by CTM may be any sector known by the centre, depending on the operation request, and including those already published by FDD as InformedSector or ControlSector.
AIRM Conformant
False
System reference number to identify the Sector by pointing to its position in the list of controlSector
AIRM Conformant
False
A specified geographical location used in defining an ATS route or the flight path of an aircraft and for other navigation and ATS purposes.
A SignificantPoint can be defined as a PublishedPoint, a GeographicalPoint or a RadialPoint.
AIRM Conformant
False
Name of a significant point.
Note: ICAO norm maximum length is 5 characters.
AIRM Conformant
False
The version number of an item.
AIRM Conformant
False
Number of seconds since the Unix epoch time - 00.00 hours - Jan, 1st, 1970 (UTC).
AIRM Conformant
False
Number of milliseconds since the Unix epoch time - 00.00 hours - Jan, 1st, 1970 (UTC).
AIRM Conformant
False
WhatIf class is used in the context of:
FlightDataManagement and CoordinationAndTransferManagement service: to indicate if the input operation is requested to be probed or not.
It is used in the following operations of CoordinationAndTransferManagement:
coordinationAccept, coordinationRejection, coordinationCounterProposal.
It is used in the following probing operations of FDM:
- requestProcessCFL
- requestProcessDirect
- requestProcessECL
- requestProcessEFL
- requestProcessHeading
- requestProcessHolding
- requestProcessRFL
- requestProcessROCD
- requestProcessRoute
- requestProcessXFL
AIRM Conformant
False
Unique identifier of a what-if context in the CCS system.
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
Note: coordinationReference is a parameter common to all C&T operations, but which is not needed in the case of the assumeFlight operation, therefore its multiplicity is set to 0.
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Generic definition of the CTM operations
Note: coordinationReference is a parameter common to all C&T operations, but which is not needed in the case of the assumeFlight and handover operations, therefore its multiplicity is set to 0.
AIRM Conformant
False
Specialisation of the common RequestReport.
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Data on the COP (coordination point) between two sectors of the same ATC unit or from adjacent units.
AIRM Conformant
False
Message definition of the operation corresponding to the same class name.
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Message definition of the operation corresponding to the same class name.
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Message definition of the operation corresponding to the same class name.
AIRM Conformant
False
Message definition of the operation corresponding to the same class name.
Note: - coordinationReference is a parameter common to all C&T operations, but which is not used by CCS for the handOver operation.
- no transferData can be sent via this operation, this is a Coflight limitation.
- toSector has to be filled only if the ATCO wants to perform a hand-over to a specific Sector instead of the next Sector. However, if the toSector attribute is filled, then it is mandatory to also fill the corresponding attribute toSectorTraversalId (only this identifier is really used by Coflight).
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Directives issued by air traffic control for the purpose of requiring a pilot to take a specific action.
Only the clearedRoute parameter is applicable to the operation coordinationManualAgreement.
AIRM Conformant
False
Message definition of the operation corresponding to the same class name
AIRM Conformant
False
Data Structures
Exchange Schema
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
Schema Language
Protocol buffer
Reference
CCS_coordinationAndTransferManagement.proto 5.0.0.2
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 set of operations related to Coordination and Transfer that are not necessarily required to achieve a usual/basic interoperability level.
PROVIDER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
Operation to cancel a previous assume of a flight.
Operation to transmit the intention of releasing the flight according to the provided data..
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..
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.
.
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)
.
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..
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)..
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..
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 one or more of the following transfer data: CFL, assigned heading, direct route clearance, assigned speed, assigned rate of Climb/Descent..
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
The detailed behavior of the service is provided in each operation dedicated section
This Service Interface exposes the set of basic operations needed for Coordination and Transfer.
PROVIDER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
Operation to indicate the assume of the flight..
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)..
Operation to accept a coordination data proposal previously sent .
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..
Operation to reject a coordination data proposal previously sent.
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..
Operation to indicate the assume of the flight when the protocol cannot be followed. .
Operation to input a verbal coordination dialogue in inter-centre..
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.
.
Operation performed by the accepting unit to the transferring unit, when required, to request the transfer of the flight
This 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.
.
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..
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.
.
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
The detailed behavior of the service is provided in each operation dedicated section
References
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
Tue, 02/01/2022 - 12:49
Revision Number
124656
The service description has currently reached the "PUBLISHED" status.