{ "informationService": { "descriptionInformation": { "abbreviations": [ { "name": "ABI", "description": "Advanced Boundary Message" }, { "name": "AC", "description": "Airspace Configuration" }, { "name": "ACC", "description": "Area Control Centre" }, { "name": "ACP", "description": "Accept Message" }, { "name": "ACT", "description": "Activate Message" }, { "name": "ADSP", "description": "ATM Data Service Provider" }, { "name": "AFTN", "description": "Aeronautical Fixed Telecommunication Network" }, { "name": "AIRM", "description": "ATM Information Reference Model" }, { "name": "AMQP", "description": "Advanced Message Queuing Protocol" }, { "name": "ANSP", "description": "Air Navigation Service Provider" }, { "name": "APL", "description": "Abbreviated Flight Plan" }, { "name": "APP", "description": "Approach" }, { "name": "ATC", "description": "Air Traffic Control" }, { "name": "ATCO", "description": "Air Traffic Control Officer" }, { "name": "ATCS", "description": "Air Traffic Control Services" }, { "name": "ATM", "description": "Air Traffic Management" }, { "name": "ATS", "description": "Air Traffic Services" }, { "name": "ATSU", "description": "Air Traffic Service Unit" }, { "name": "AoR", "description": "Area of Responsibility" }, { "name": "CCS", "description": "Coflight Cloud Services" }, { "name": "CDN", "description": "Coordination Message" }, { "name": "CFL", "description": "Cleared Flight Level" }, { "name": "COF", "description": "Change of Frequency Message" }, { "name": "COP", "description": "Coordination Point" }, { "name": "CTM", "description": "Coordination and Transfer Management" }, { "name": "CWP", "description": "Controller Working Position" }, { "name": "DSNA", "description": "Direction des Services de la Navigation A0xC3 0xA9rienne (French ANSP)" }, { "name": "EFL", "description": "Entry Flight Level" }, { "name": "ENAV", "description": "Ente Nazionale Assistenza al Volo (Italian ANSP)" }, { "name": "ETN", "description": "Estimated Time of Entry" }, { "name": "ETX", "description": "Estimated Time of Exit" }, { "name": "FABEC", "description": "Functional Airspace Block Europe Central" }, { "name": "FDD", "description": "Flight Data Distribution" }, { "name": "FDM", "description": "Flight Data Management" }, { "name": "FDO", "description": "Flight Data Operator" }, { "name": "FDPS", "description": "Flight Data Processing System" }, { "name": "FL", "description": "Flight Level" }, { "name": "FP", "description": "Flight Plan" }, { "name": "HMI", "description": "human machine Interface" }, { "name": "IAS", "description": "Indicated Airspeed" }, { "name": "ICAO", "description": "International Civil Aviation Organization" }, { "name": "ID", "description": "Identifier" }, { "name": "IER", "description": "Interface Exchange Requirement" }, { "name": "IFR", "description": "Instrument Flight Rules" }, { "name": "IKE", "description": "Internet Key Exchange" }, { "name": "IP", "description": "Internet Protocol" }, { "name": "IPSEC", "description": "Internet Protocol Security protocol" }, { "name": "JU", "description": "Joint Undertaking" }, { "name": "KPI", "description": "Key Performance Indicator" }, { "name": "MAS", "description": "Manual Assumption of Communications Message" }, { "name": "MB", "description": "MegaByte" }, { "name": "MEP", "description": "Message Exchange Pattern" }, { "name": "NTP", "description": "Network Time Protocol" }, { "name": "OCSP", "description": "Online Certificate Status Protocol" }, { "name": "OE", "description": "Operational Entity" }, { "name": "OLDI", "description": "On-line Data Interchange" }, { "name": "OPSUP", "description": "Operational Supervision" }, { "name": "PAC", "description": "Preliminary Activate Message" }, { "name": "PKCS", "description": "Public Key Cryptography Standards" }, { "name": "RAP", "description": "Referred Activate Proposal Message" }, { "name": "RJC", "description": "Reject Message" }, { "name": "ROCD", "description": "Rate of Climb Descend" }, { "name": "RRV", "description": "Referred Revision Proposal Message" }, { "name": "SDD", "description": "Service Definition Document" }, { "name": "SESAR", "description": "Single European Sky Air Traffic Management Research" }, { "name": "SFPL", "description": "System Flight Plan" }, { "name": "SLA", "description": "Service Level Agreement" }, { "name": "SSD", "description": "SWIM Service Description" }, { "name": "SSI", "description": "Synchronous Serial Interface" }, { "name": "SSR", "description": "Secondary Surveillance Radar" }, { "name": "SWIM", "description": "System Wide Information Management" }, { "name": "TBC", "description": "To Be Confirmed" }, { "name": "TCP", "description": "Transfer Control Protocol" }, { "name": "TI", "description": "Technical Infrastructure" }, { "name": "TLS", "description": "Transport Level Security" }, { "name": "UTC", "description": "Coordinated Universal Time" }, { "name": "VC", "description": "Virtual Centre" }, { "name": "VFR", "description": "Visual Flight Rules" }, { "name": "XFL", "description": "Exit Flight Level" } ], "serviceDescriptionIdentification": { "serviceDescriptionTitle": "CCS CoordinationAndTransferManagement Service Description", "serviceDescriptionEdition": "5.2.0.9", "serviceDescriptionReferenceDate": "14/06/2022" } }, "name": "CCS CoordinationAndTransferManagement", "serviceAbstract": "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). \r\nThe CCS CoordinationAndTransferManagement service is consistent with the other CCS services.\r\nIt 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.\r\n \r\nThis version of the service is intended to be used in \u0027test mission\u0027, which aims at providing services and support to the Customer(s) to enable them to test any version of their ATM system during development.\r\n\r\nNote: Only civil flights are handled by CCS services.\r\n\r\nPlease 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.: \r\n-\tCurrent status of coordination and transfer of flights between the crossed controller positions (AoR)\r\n-\tOn-going Change proposals for those coordination and transfer\r\n", "serviceCategorisation": { "serviceType": "SWIM_COMPLIANT", "lifeCycleStage": "OPERATIONAL", "businessActivityType": [ "INFORMATION_MANAGEMENT" ], "informationCategory": [ "FLIGHT_INFORMATION_EXCHANGE" ], "intendedConsumer": [ "CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER" ], "applicationMessageExchangePattern": [ "SYNCHRONOUS_REQUEST_REPLY" ] }, "serviceDescriptionReferences": { "implementedStandard": [ { "conformanceStatement": "Description of Service according to EUROCONTROL specifications", "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", "isConformant": true, "reference": "https://confluenceccs.se-dmf.eu/display/CDFSR/Applicable+documents\r\n\r\nNote: to request access to Confluence, please refer to the point of contact section.", "standardType": "EUROCONTROL_SPECIFICATION_FOR_SWIM_SERVICE_DESCRIPTION", "title": "EUROCONTROL Specification for SWIM - Service Description ", "version": "2.0" }, { "conformanceStatement": "Information definition according to EUROCONTROL specifications", "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. ", "isConformant": true, "reference": "https://confluenceccs.se-dmf.eu/display/CDFSR/Applicable+documents\r\n\r\nNote: to request access to Confluence, please refer to the point of contact section.", "standardType": "EUROCONTROL_SPECIFICATION_FOR_SWIM_INFORMATION_DEFINITION", "title": "EUROCONTROL Specification for SWIM - Information Definition", "version": "1.0" }, { "conformanceStatement": "Implementation of service and network bindings", "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", "isConformant": true, "reference": "https://confluenceccs.se-dmf.eu/display/CDFSR/Applicable+documents\r\n\r\nNote: to request access to Confluence, please refer to the point of contact section.", "standardType": "EUROCONTROL_SPECIFICATION_FOR_SWIM_TECHNICAL_INFRASTRUCTURE", "title": "EUROCONTROL Specification for SWIM - Technical Infrastructure (TI) Yellow Profile", "version": "1.0" } ], "serviceDocument": [ { "description": "AIRM traceability for CCS Coordination And Transfer Management service payload", "documentType": "AIRM_TRACE", "reference": "https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Coordination+And+Transfer+Management+Service \nNote: to request access to Confluence, please refer to the point of contact section", "title": "CCS AIRM mapping CTM service", "version": "1.0" }, { "description": "Validation evidence for CCS Coordination And Transfer Management service", "documentType": "SERVICE_VALIDATION_REPORT", "reference": "https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Coordination+And+Transfer+Management+Service \nNote: to request access to Confluence, please refer to the point of contact section", "title": "CCS Validation evidence document - CoordinationAndTransferManagement", "version": "1.0" }, { "description": "Protobuf files describing the exchanged information", "documentType": "MACHINE_READABLE_SERVICE_DESCRIPTION", "reference": "https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Coordination+And+Transfer+Management+Service", "title": "CCS_coordinationAndTransferManagement.proto", "version": "5.0.0.5" }, { "description": "Protobuf file describing the exchanged information common to two or more CCS Services", "documentType": "MACHINE_READABLE_SERVICE_DESCRIPTION", "reference": "https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Coordination+And+Transfer+Management+Service", "title": "CCS_common.proto", "version": "5.5.1.2" }, { "description": "Protobuf file describing the metadata used by the CCS Services", "documentType": "MACHINE_READABLE_SERVICE_DESCRIPTION", "reference": "https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Coordination+And+Transfer+Management+Service", "title": "metadata.proto", "version": "v1.2.0.0" }, { "description": "Complete service specification", "documentType": "SERVICE_SPECIFICATION", "reference": "https://confluenceccs.se-dmf.eu/display/CDFSR/CCS+Coordination+And+Transfer+Management+Service", "title": "CCS CoordinationAndTransferManagement Service Description", "version": "5.2.0.9" }, { "description": "Document that includes the list of all applicable error messages for CCS services", "documentType": "SERVICE_SPECIFICATION", "reference": "https://confluenceccs.se-dmf.eu/display/CDFSR/Applicable+Documents", "title": "CCS Errors Management Document", "version": "2.0" } ] }, "serviceProvision": { "dateInOperation": "2020-07-01", "provider": "DSNA\u0026ENAV", "providerDescription": "DSNA (Direction des Services de la Navigation Aerienne) is the national air navigation services provider of France. DSNA is entrusted with the provision of air traffic services, associated communication, navigation and surveillance services and aeronautical information services in all airspace under French responsibility and at designated airports. DSNA is member of A6, FABEC and SESAR JU.\r\nParis ACC : At the crossroads of the biggest European platforms, Paris ACC manage one of the most dense airspace in Europe. Paris ACC act to develop Paris airports capacity. The traffic handled by Paris ACC consists of 72% of flights departing or arriving at Parisian airports. With its 1.3 million controlled flights in 2018, Paris ACC is one the most important ACC in Europe.\r\n\r\nENAV S.p.A. (ENAV) is the Italian AIR Navigation Service Provider \r\nENAV\u0027s core business is to manage the regulated Air Traffic Control Services (ATCS), for which it is entrusted, allowing aircraft to fly within the assigned airspace with constantly enhanced levels of safety, optimizing the effectiveness of the service provided and the efficiency of the company", "providerType": [ "CIVIL_AIR_NAVIGATION_SERVICE_PROVIDER" ], "pointOfContact": [ { "name": "Andrea Quaresima", "description": "CCS Collaborative tools administrator - To request access to the CCS documentation", "email": "andrea.quaresima@enav.it", "phoneNumber": "" }, { "name": "Guillaume Ramonet", "description": "Coflight Cloud Services Program Director - To request access to the CCS service", "email": "Guillaume.Ramonet@aviation-civile.gouv.fr", "phoneNumber": "" }, { "name": "Service Desk", "description": "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\r\n", "email": "", "phoneNumber": "" } ] }, "serviceGeneralDescription": { "operationalNeed": [ { "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.\r\nIt provides a set of operations to support the Coordination and Transfer process between controller positions. It addresses operations such as:\r\n-\tActivateCoordination,\r\n-\tAssumeFlight,\r\n-\tCoordinationProposal,\r\n-\tForceAssume,\r\n-\tHandOver,\r\n-\t...\r\n" } ], "functionality": [ { "name": "Manually activate a coordination", "description": "Manually activate a coordination", "realWorldEffect": "To manually trigger the coordination before the automatic event" }, { "name": "Assume a flight", "description": "Assume a flight", "realWorldEffect": "The control of the flight is transferred to the controller assuming it." }, { "name": "Deassume a flight", "description": "Deassume a flight", "realWorldEffect": "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", "realWorldEffect": "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", "realWorldEffect": "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", "realWorldEffect": "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", "realWorldEffect": "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)", "realWorldEffect": "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)", "realWorldEffect": "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", "realWorldEffect": "This service is used by either the upstream or the downstream controller, when the coordination agreement has to be done by phone.\r\nOnce a verbal agreement has been performed, the controller must perform this operation to feed the system with a stable coordination state.\r\n" }, { "name": "Point out a flight to another responsibility", "description": "Point out a flight to another responsibility", "realWorldEffect": "The Point message is sent to highlight (ou point out) a flight to another controller(s) within the same ATSU or in adjacent ATSU.\r\nThis is a PNT msg equivalent." }, { "name": "End a PointOut notification", "description": "End a PointOut notification", "realWorldEffect": "closePointOut is used in response to a pointOut notification for formally notifying the system that the notification has been processed by the receiver.\r\nThis 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", "realWorldEffect": "Operation to indicate that the upstream controller requests to recover the flight control after a handOver operation. \r\nThe flight is then expected to get back into the previous state.\r\nIntra-centre operation: no OLDI msg equivalent." }, { "name": "Request the transfer of a flight", "description": "Request the transfer of a flight", "realWorldEffect": "Operation to force in advance the request of the transfer of the flight.\r\nThis is a ROF msg equivalent." }, { "name": "Send a counter proposal after a coordination proposal", "description": "Send a counter proposal after a coordination proposal", "realWorldEffect": "Operation to forward a counter proposal from the accepting unit to the transferring one or vice versa during the coordination phase.\r\nThis 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.\r\n" }, { "name": "Delegate the responsibility of a flight", "description": "Delegate the responsibility of a flight", "realWorldEffect": "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", "realWorldEffect": "Operation to discard the responsibilities of the originator LogicalCWP from the planned control sectors list.\r\nOnce this is done, this operation allows undoing it.\r\n" }, { "name": "Request clearances", "description": "Request clearances", "realWorldEffect": "Operation from accepting unit to request some operational clearances from transferring unit" }, { "name": "Send a Hand Over proposal", "description": "Send a Hand Over proposal", "realWorldEffect": "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", "realWorldEffect": "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", "realWorldEffect": "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)." } ], "accessAndUseCondition": [ { "description": "\u003cbold\u003eIPR\u003c/bold\u003e\r\nIn 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).\r\n\r\n\u003cbold\u003eAccess to the Service\u003c/bold\u003e\r\nThis service is provided to Service Consumers under a contractual basis signed between the CCS Service Provider and the Service Consumer.", "name": "Information ownership", "type": "LEGAL_CONSTRAINT" }, { "description": "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.", "name": "Dependencies with other CCS Services", "type": "SERVICE_CONSUMPTION_CONSTRAINT" }, { "description": "This service will be updated to be as much as possible in line with the Service Definition produced by SESAR Virtual Centre activities", "name": "Alignment to SESAR Virtual Centre activity", "type": "SERVICE_POLICY" }, { "description": "Both the SWIM Service Description documents / Protobuf files and the CCS Services are versioned.\r\nThe version assigned to SSDs and to Protobuf files is composed by four digits in the form x.y.z.w.\r\nNew releases are numbered according to the following rule (compared to the previous version): \r\n-\tw 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.\r\n-\tz 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.\r\n-\ty 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.\r\n-\tx increased by one: means that the file contains a new baseline. Major changes are expected to be present.\r\n\r\nThe service version is composed by 3 digits a.b.c assigned according to the following rule:\r\n- a could be 0,1,2 depending on the status of the service with respect to the SWIM registration phase:\r\n0: before the service application (as candidate)\r\n1: if candidate\r\n2: if compliant\r\n- b Increments if major changes have been done with respect to the previous version (modify/remove). No backward compatibility.\r\n- c Increments if minor changes have been done with respect to the previous version (addition/description modified). Full backward compatibility.\r\n", "name": "Service versioning", "type": "SERVICE_POLICY" }, { "description": "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.", "name": "KPIs monitoring", "type": "SERVICE_POLICY" }, { "description": "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.", "name": "Confidentiality and integrity", "type": "SECURITY_CONSTRAINT" }, { "description": "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. \r\nMutual 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. \r\n-\tCCS 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).\r\n-\tThe 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.\r\n-\tFor the cryptographic algorithms, the authorized cipher suites must be agreed between the CCS provider and the customer based on the standards.\r\nAs an ATSU, the CCS business services customer, once identified, has access to all CCS services.\r\nIn 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.\r\n", "name": "Authentication and authorisation", "type": "SECURITY_CONSTRAINT" } ], "qualityOfService": [ { "name": "Services level objectives", "description": "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).\r\nThese 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." }, { "name": "Network performance", "description": "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." }, { "name": "Rate limitation", "description": "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": [ { "description": "Prior to any Service publication in the European SWIM Registry, CCS partners organise a joint validation that involve both CCS Providers and the first CCS Customer. \r\nTest 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 first CCS Customer.\r\nAny anomaly raised by the test case execution is conveyed into the CCS bug management process. For each anomaly, a criticality level is assigned:\r\n-\tCritical: blocking issue that prevents the usage of a service functionality\r\n-\tMajor: issue that prevents the usage of a service functionality for which a workaround has been identified\r\n-\tMinor: other anomalies neither Critical nor Major \r\nDepending on the impacts, the issue is addressed to the specific team(s) in charge of the resolution (specification team, software team, dataset team...).\r\nOnce fixed, the issue is verified during one of the next validation sessions and closed if the resolution is confirmed by the validation team.\r\n\r\nIn addition to the functional validation, CCS partners also organise performance validations. The objectives of such sessions are:\r\n-\tto measure the CCS system response times according to several Key Performance Indicators (KPI) and Non-Functional Requirements (NFR) agreed among parties\r\n-\tto indicate if the KPI target values are reached or not\r\nThe following KPI are evaluated:\r\n-\tMaximum Provider response time for receiving the related to a short process request triggered from the CCS Client\r\n-\tMaximum Provider response time for receiving the result related to a long process request triggered from the CCS Client\r\n-\tMaximum Provider response time for receiving the result Provider related to a SFPL external event processing\r\nWhile the following KPI is just monitored for information:\r\n-\tMaximum Provider response time for receiving an Acknowledge (or Reject) related to a request triggered from the CCS Client.\r\nIt is worth noting that the performance test cases involve only the operations from a subset of CCS services.\r\nThe response times from end to end are computed by costumer equipments. CCS reference platform internal traversal times are measured on provider side.\r\nThe details about executed test cases and related results are provided in the CCS Validation evidence document of this service.\r\n", "type": "COLLABORATIVE_VALIDATION" } ] }, "serviceInformationDescription": { "exchangeSchema": [ { "name": "deassumeFlight Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "forceHandOver Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "closePointOut Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "pointOut Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "delegate Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "handOverProposal Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "handOverRejection Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "transferAcceptation Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "clearancesRequest Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "assumeFlight Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "handOver Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "coordinationAccept Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "coordinationProposal Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "coordinationRejection Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "activateCoordination Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "forceAssume Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "coordinationManualAgreement Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "handOverRecall Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "handOverRequest Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "coordinationCounterProposal Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" }, { "name": "replaceSectors Exchange schema", "reference": "CCS_coordinationAndTransferManagement.proto 5.0.0.5", "schemaLanguage": "Protocol buffer" } ], "informationDefinition": [ { "airmConformant": true, "airmVersion": "1.0.0", "description": "For the exchanged data model, please refer to the SWIM Service Description document (sections 2.1 and 2.2)", "name": "Service Information Definition" } ] }, "serviceTechnicalDescription": { "securityMechanism": [ { "description": "Mutual authentication with X509 certificates is used between the AMQP broker and its client established within a TLS session", "name": "Mutual authentication with X509 certificates", "type": [ "AUTHENTICATION" ] }, { "description": "TLS 1.2 is used to provide confidentiality and integrity at transport layer.", "name": "TLS 1.2", "type": [ "CONFIDENTIALITY", "INTEGRITY" ] }, { "description": "IPsec is used to provide confidentiality, authentication and integrity at network (internet) layer", "name": "IPsec v4", "type": [ "CONFIDENTIALITY", "INTEGRITY", "AUTHENTICATION" ] } ], "serviceMonitoring": { "monitoringDescription": "CCS services are supervised in real time by trained and licensed ATSEPS\r\n\r\n. A dedicated service to supervise the complete CCS swim services portfolio is available to the customer.\r\nFor more information, please refer to the swim service description of the CCS technical supervision distribution service\r\n" }, "technicalConstraint": [ { "name": "Time synchronisation", "description": "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. \r\nNTP 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.\r\n" }, { "name": "Provider-Customer interface-Exchange patterns", "description": "Each services interface of the CCS business services relies on the concept of AMQP queues and topics. \r\n-\tThe CCS customer shall use an implementation of the AMQP 1.0 specification to connect to the CCS provider AMQP 1.0 endpoint. \r\n-\tThe CCS provider endpoint is an AMQP 1.0 broker managing queue and topics. \r\nThe message payloads are encoded following a protobuf format. \r\nThe 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.\r\nConcerning 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.\r\nThe 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://\u003cNameSpaceName\u003e.\u003cServiceInterfaceName\u003e.\u003cLogicalOperation\u003e\r\nThe subscribers can filter the messages they want to receive by using the filter parameters defined for each subscription operation.\r\nPlease note that, after subscribing to a CCS Distribution Service, the current repository of messages needs to be obtained from CCS via the get\u003cMessageRepository\u003e operation defined for each CCS Distribution Service (see \"Subscription\" section of the distribution operation of the service).\r\nN.B:\r\n- If the CCS platform restarts while the Customer is connected to the AMQP Broker, the current repository of messages is published again.\r\n- 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\r\n\r\nConcerning 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.\r\n" }, { "name": "Provider-Customer interface-Connection management", "description": "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." }, { "name": "Provider-Customer interface-Queue management", "description": "The AMQP broker creates the physical resources associated with a destination (queue, topic) on demand when messages are actually sent to them.\r\nPermissions on queues and topics (read/write access) are granted based on intended usage. The CCS customer will have: \r\n-\tWrite access on the request queue\r\n-\tRead access on the reply queue \r\n-\tRead access on the topic for distribution service\r\n" } ] }, "serviceInterface": [ { "behaviour": [ { "name": "Service behaviour", "description": "The detailed behavior of the service is provided in each operation dedicated section" } ], "description": "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.", "endPoint": [ { "address": "For security reasons, the addresses will be communicated only to Customers", "addressableResource": [ { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.AdvancedCoordinationAndTransferManagementProvider.deassumeFlight", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.AdvancedCoordinationAndTransferManagementProvider.forceHandOver", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.AdvancedCoordinationAndTransferManagementProvider.closePointOut", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.AdvancedCoordinationAndTransferManagementProvider.pointOut", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.AdvancedCoordinationAndTransferManagementProvider.delegate", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.AdvancedCoordinationAndTransferManagementProvider.handOverProposal", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.AdvancedCoordinationAndTransferManagementProvider.handOverRejection", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.AdvancedCoordinationAndTransferManagementProvider.transferAcceptation", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.AdvancedCoordinationAndTransferManagementProvider.clearancesRequest", "type": "QUEUE" } ], "name": "AdvancedCoordinationAndTransferManagementProvider" } ], "interfaceBindingDescription": "Information is exchanged in Protobuf format. Protocol buffers or Protobuf are Google\u0027s language-neutral, platform-neutral, extensible mechanism for serializing structured data similar to XML, but smaller, faster, and simpler. ", "interfaceProvisionSide": "PROVIDER_SIDE_INTERFACE", "name": "AdvancedCoordinationAndTransferManagementProvider", "networkInterfaceBinding": "IPV4_SECURE_UNICAST", "operation": [ { "description": "Operation to cancel a previous assume of a flight. ", "idempotency": "NON_IDEMPOTENT", "name": "deassumeFlight", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "DeassumeFlight" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse" } ], "precondition": "the coordinationStatus of the giving (originator) responsibility is ASSUMED and the coordinationStatus of the receiving responsibility is DEASSUMED.", "processingConsideration": [ { "name": "coordinationReference parameter", "description": "coordinationReference is a parameter common to all C\u0026T operations, but CCS does not use it for the deassumeFlight operation." }, { "name": "Successful request", "description": "If the request is successful, CCS performs the following updates:\r\n- the coordinationStatus of the receiving responsibility is set to ASSUMED,\r\n- the coordinationStatus of the originator comes back to the previous status (its status before the forceAssume input),\r\n- if the previous assume input was a delegation, the giving responsibility is removed from the list of control responsibilities.\r\n\r\nThen CCS publishes the updated SFPL using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation to transmit the intention of releasing the flight according to the provided data.. ", "idempotency": "NON_IDEMPOTENT", "name": "forceHandOver", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name.", "direction": "IN", "isFault": false, "name": "ForceHandOver" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "coordinationReference parameter", "description": "coordinationReference is a parameter common to all C\u0026T operations, but which is not used by CCS for the forceHandOver operation." }, { "name": "transferData and releasedForActions parameters", "description": "neither transferData nor releasedForActions can be sent via this operation, this is a CCS limitation." }, { "name": "toSector and toSectorTraversalId parameters", "description": "toSector and toSectorTraversalId are mutually exclusive, but the controller must provide at least one of them." }, { "name": "forceHandOver towards another ATSU", "description": "in case of forceHandOver towards another ATSU, if the corresponding parameter related to this ATSU is set in the dataset, automatic assumption by the receiving unit is applied after an offline defined delay (coordinationStatus of the receiving responsibility is set to ASSUMED)." }, { "name": "Instructed communication responsibility update", "description": "The Instructed Communication Responsibility will be updated as follows: it will be the Responsibility designated in the input." }, { "name": "Successful request", "description": "If the request is successful, the following transition data are updated:\r\n-\tthe coordinationStatus of the giving responsibility is set to RELEASED,\r\n-\tthe coordinationStatus of the receiving responsibility is set to FREQUENCY_CHANGED (eq. assumable),\r\n-\tthe coordinationStatus of any responsibility that is DEASSUMED is set to HANDED_OVER." }, { "name": "delegation case", "description": "In case of delegation, some other data are updated (see the results of the delegate operation)." }, { "name": "protocol not applicable", "description": "When the protocol cannot be followed:\r\n-\tin case of delegation towards a responsibility which is not in the list of crossed responsibilities, the controller must use the delegate input.\r\n" }, { "name": "Unsuccessful request", "description": "CCS will reject a forceHandOver input when:\r\n-\tboth toSector and toSectorTraversalId are provided.\r\n-\tneither toSector nor toSectorTraversalId are provided." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "closePointOut is used in response to a pointOut notification for formally notifying the system that the notification has been processed by the receiver.\r\nThis remains a local action between the receiver and his/her system without any OLDI equivalent message.\r\nThe 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.. ", "idempotency": "NON_IDEMPOTENT", "name": "closePointOut", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "ClosePointOut" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "coordinationReference parameter", "description": "coordinationReference is defined as common to all CTM operations (it is mentioned here for interoperability purpose only), but CCS does not use it for this operation" }, { "name": "Successful request", "description": "If the request is successful while it has been done by the designated controller, the associated target controller is removed from the servedController list.\r\nIf the request is successful while it has been done by the originator, or by the designated controller and there is no more recipient, the point session is ended for all the target responsibilities:\r\n-\tthe \"PointSession\" data related to this session are removed from the SFPL.\r\n-\tthe associated target controllers are removed from the servedController list.\r\nThen the updated SFPL is published using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "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.\r\nThis is a PNT msg equivalent.\r\nThe input of the point function shall contain the identification of the SFPL and the identification of one or several point target sector(s).\r\nThe use of a reason parameter written by the originator is only allowed for Point message sent to controller(s) of the same ATSU.\r\nThe main uses of the point function are:\r\n-\thighlight: 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).\r\n-\tmanual distribution: to support the delivery of flight data to a chosen recipient:\r\n -\tfor 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)\r\n -\tto replace automatic distribution by manual distribution, when the system is degraded.\r\n. ", "idempotency": "NON_IDEMPOTENT", "name": "pointOut", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "PointOut" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "coordinationReference parameter", "description": "coordinationReference is defined as common to all CTM operations (it is mentioned here for interoperability purpose only), but CCS does not use it for this operation" }, { "name": "Request rejected", "description": "The operation is rejected if the operation is performed while 4 point sessions are already opened" }, { "name": "Successful request", "description": "If the request is successful, CCS performs the following updates:\r\n-\tA \"PointSession\" class is added, including with its Identification, Originator and Target.\r\n-\tWhen the target ATSU is not an external OLDI ATSU, the target controllers are added in the servedController list with the reason filled by the ATCO.\r\nThen the updated SFPL is published using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs.\r\n" }, { "name": "OLDI ATSU", "description": "In case of point to a responsibility managed by an OLDI ATSU, an OLDI message is sent only once at the start of the point session." }, { "name": "mapping change", "description": "A point is independent of the mapping of responsibilitie(s) onto logicalCWPs, and so after any change of mapping configuration a point will remain between the point originating responsibilitie(s) and the pointed responsibilitie(s)." }, { "name": "no reason provided", "description": "The text \u003c\u003c \u003e\u003e is distributed by FDD if there is a pointSession for which no reason has been input" } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation to transfer the responsibility of a flight to a responsibility that is not in the list of the planned crossed responsibilities.\r\nThe input shall contain the identification of the SFPL and the name of the receiving responsibility (toSector)\r\n. ", "idempotency": "NON_IDEMPOTENT", "name": "delegate", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "Delegate" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "coordinationReference parameter", "description": "coordinationReference is a parameter common to all C\u0026T operations, but which is not used by CCS for the delegate operation." }, { "name": "Instructed communication responsibility update", "description": "The Instructed Communication Responsibility will be updated as follows: it will be the Responsibility designated in the input." }, { "name": "Successful request", "description": "If the request is successful, the following transition data are updated:\r\n-\tthe delegated responsibility is added in the ControlSector list of the SFPL,\r\n-\tthe coordinationStatus of the giving responsibility is set to RELEASED,\r\n-\tthe coordinationStatus of the receiving responsibility is set to FREQUENCY_CHANGED (eq. assumable),\r\n-\tthe coordinationStatus of any responsibility that is DEASSUMED is set to HANDED_OVER,\r\n-\tthe sectorState of the delegated responsibility is set to DELEGATED.\r\n-\tThe transition between the delegated responsibility and the downstream is tagged as non standard.\r\n-\tThe transition status between the delegating and the delegated is set to DELEG.\r\n" }, { "name": "Unsuccessful request", "description": "CCS will reject a delegate input if the delegated responsibility is mapped on the same LogicalPosition as the delegating responsibility or its downstream responsibility." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation to propose the flight for hand-over to the accepting controller (unit) when required.\r\nThis is a HOP msg equivalent.\r\nThis operation is possible only if the accepting unit is another ATSU.\r\nThis 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). \r\nThe input shall contain one or more of the following transfer data: CFL, assigned heading, direct route clearance, assigned speed, assigned rate of Climb/Descent.. ", "idempotency": "NON_IDEMPOTENT", "name": "handOverProposal", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "HandOverProposal" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "Successful request", "description": "If the request is successful, the coordinationStatus of the receiving responsibility is set to HANDOVER_PROPOSED.\r\nThen the updated SFPL is published using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation to propose the flight for hand-over to the accepting controller (unit) when required.\r\nThis is a HOP msg equivalent.\r\nThis operation is possible only if the accepting unit is another ATSU.\r\nThis 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).. ", "idempotency": "NON_IDEMPOTENT", "name": "handOverRejection", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "HandOverRejection" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "Successful request", "description": "If the request is successful, if the message exchange is within the ATSU, or with another ATSU if the controlled ATSU is the one answering the proposal, the coordinationStatus of the receiving responsibility is set to HANDOVER_REJECTED. Otherwise, the coordinationStatus of the receiving responsibility is back to the status it had before the clearances request.\r\nThen the updated SFPL is published using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation to indicate the manual acceptance by a unit of the transfer conditions previously sent (e.g. response to a propose hand over operation).\r\nThis is an ACP msg equivalent.\r\nThis operation can be a response either to a clearances request, or to a hand over proposal.. ", "idempotency": "NON_IDEMPOTENT", "name": "transferAcceptation", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "TransferAcceptation" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "Unsuccessful request", "description": "CCS rejects the input if the coordinationReference indicating the Downstream/Upstream direction is not provided. " }, { "name": "Successful request", "description": "If the request is successful:\r\n-\tIf the message exchange is within the ATSU, or with another ATSU if the controlled ATSU is the one answering the proposal, the coordinationStatus of the receiving responsibility is set to HANDOVER_ACCEPTED. Otherwise, the coordinationStatus of the receiving responsibility is back to the status it had before the clearances request or hand over proposal.\r\n-\tthe transfer data are applied to the SFPL\r\nThen the updated SFPL is published using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs.\r\nThe agreed transfer data can be retrieved in the constraint data." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation from accepting unit to request some operational clearances from transferring unit.\r\nThis is a RTI msg equivalent.\r\nThis 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). \r\nThe 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.. ", "idempotency": "NON_IDEMPOTENT", "name": "clearancesRequest", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "ClearancesRequest" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "Successful request", "description": "If the request is successful, the coordinationStatus of the receiving responsibility is set to HANDOVER_PROPOSED.\r\nThen the updated SFPL is published using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] } ], "serviceInterfaceBinding": "SWIM_TI_YP_1_0_AMQP_MESSAGING", "tiPrimitiveMessageExchangePattern": "SYNCHRONOUS_REQUEST_RESPONSE" }, { "behaviour": [ { "name": "Service behaviour ", "description": "The detailed behavior of the service is provided in each operation dedicated section" } ], "description": "This Service Interface exposes the set of basic operations needed for Coordination and Transfer.", "endPoint": [ { "address": "For security reasons, the addresses will be communicated only to Customers", "addressableResource": [ { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.CoordinationAndTransferManagementProvider.assumeFlight", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.CoordinationAndTransferManagementProvider.handOver", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.CoordinationAndTransferManagementProvider.coordinationAccept", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.CoordinationAndTransferManagementProvider.coordinationProposal", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.CoordinationAndTransferManagementProvider.coordinationRejection", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.CoordinationAndTransferManagementProvider.activateCoordination", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.CoordinationAndTransferManagementProvider.forceAssume", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.CoordinationAndTransferManagementProvider.coordinationManualAgreement", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.CoordinationAndTransferManagementProvider.handOverRecall", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.CoordinationAndTransferManagementProvider.handOverRequest", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.CoordinationAndTransferManagementProvider.coordinationCounterProposal", "type": "QUEUE" }, { "description": "Name of the queue", "name": "queue://ccs.protobuf.coordinationAndTransferManagement.CoordinationAndTransferManagementProvider.replaceSectors", "type": "QUEUE" } ], "name": "CoordinationAndTransferManagementProvider" } ], "interfaceBindingDescription": "Information is exchanged in Protobuf format. Protocol buffers or Protobuf are Google\u0027s language-neutral, platform-neutral, extensible mechanism for serializing structured data similar to XML, but smaller, faster, and simpler. ", "interfaceProvisionSide": "PROVIDER_SIDE_INTERFACE", "name": "CoordinationAndTransferManagementProvider", "networkInterfaceBinding": "IPV4_SECURE_UNICAST", "operation": [ { "description": "Operation to indicate the assume of the flight.. ", "idempotency": "NON_IDEMPOTENT", "name": "assumeFlight", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name\r\n\r\nNote: coordinationReference is a parameter common to all C\u0026T operations, but which is not needed in the case of the assumeFlight operation, therefore its multiplicity is set to 0.", "direction": "IN", "isFault": false, "name": "AssumeFlight" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "CoordinationReference parameter", "description": "CoordinationReference is a parameter common to all C\u0026T operations, but which is not used by CCS for the assumeFlight operation." }, { "name": "respTraversalId parameter not provided", "description": "If no respTraversalId is provided in the input, CCS deduces the assuming responsibility considering the originator of the input." }, { "name": "Protocol not applicable", "description": "when the protocol cannot be followed (eq. in advance assume or delegation), the controller should use the forceAssume input. " }, { "name": "respTraversalId paramter", "description": "Whether the parameter respTraversalId is provided or not, CCS shall:\r\n-\ttrigger a normal assumption if the assuming responsibility is in the list of crossed responsibilities and if it is assumable (eq. coordinationStatus FREQUENCY_CHANGED),\r\n-\ttrigger an assume by shortcut if the coordinationStatus of the assuming responsibility is in the list of crossed responsibilities but it is not assumable (this includes the case where the assuming responsibility is DEASSUMED following a forceAssume from another responsibility),\r\n-\ttrigger an assume by delegation if the assuming responsibility is not in the list of crossed responsibilities." }, { "name": "transferring unit is another ATSU", "description": "in case the transferring unit is another ATSU, if the corresponding parameter related to this ATSU is set in the dataset, automatic transfer is applied: when progressOfFlight is NEAR_EXE, the flight becomes assumable" }, { "name": "Communication Responsibilities update", "description": "The Communication Responsibilities will be updated as follows:\r\n-\tthe Current Communication Responsibility will be the Responsibility designated in the input, or the Instructed Communication Responsibility if no designated Responsibility.\r\n-\tthe Instructed Communication Responsibility will be cleared." }, { "name": "Successful request", "description": "If the request is successful, the following transition data are updated:\r\n-\tthe coordinationStatus of the receiving (assuming) responsibility is set to ASSUMED,\r\n-\tthe coordinationStatus of the giving responsibility is set to HANDED_OVER (transferred) in case of normal assumption (otherwise see the results of the forceAssume operation),\r\n-\tthe rofIndicator is unset if it was set.\r\nThen the updated SFPL is published using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs." }, { "name": "Shortcut assume option", "description": "The shortcut assume option can be offline disabled with an eligibility rule based on the assumable value of the coordinationStatus:\r\nBy default, the CCS assumeFlight operation will not be rejected when the assuming responsibility is not FREQUENCY_CHANGED. The consumer can limit the assumeFlight access to FREQUENCY_CHANGED responsibilities by defining offline a specific eligibility rule in the dataset." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation to transmit the intention of releasing the flight according to the agreed transfer conditions. \r\nDepending on the LoAs: e.g. expecting a further AssumeFlight operation or just waiting for a radio contact to release the flight.\r\nThis is an OLDI COF (Change Of Frequency) message equivalent.\r\n\r\nThis 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).\r\nThis operation also offers the possibility to hand over the flight to a responsibility not in the list of crossed (eq. delegate input).. ", "idempotency": "NON_IDEMPOTENT", "name": "handOver", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name.\r\n\r\nNote: - coordinationReference is a parameter common to all C\u0026T operations, but which is not used by CCS for the handOver operation.\r\n- no transferData can be sent via this operation, this is a Coflight limitation.\r\n- 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).\r\n", "direction": "IN", "isFault": false, "name": "HandOver" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "coordinationReference parameter", "description": "coordinationReference is a parameter common to all C\u0026T operations, but which is not used by CCS for the handOver operation." }, { "name": "transferData parameter", "description": "no transferData can be sent via this operation, this is a CCS limitation." }, { "name": "toSector parameter", "description": "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 CCS)." }, { "name": "coordinationStatus parameter", "description": "The coordinationStatus of the originator responsibility has to be ASSUMED." }, { "name": "handOver towards another ATSU", "description": "in case of handOver towards another ATSU, if the corresponding parameter related to this ATSU is set in the dataset, automatic assumption by the receiving unit is applied after an offline defined delay (coordinationStatus of the receiving responsibility is set to ASSUMED)." }, { "name": "Instructed Communication Responsibility update", "description": "The Instructed Communication Responsibility will be updated as follows: it will be the Responsibility designated in the input, or the Default Communication Responsibility of the LogicalCWP if no designated Responsibility. The Default is either a fixed Responsibility offline defined for this sector mapping, or the 1st Resp crossed after the LogicalCWP." }, { "name": "Protocol not applicable", "description": "When the protocol cannot be followed:\r\n-\tin case of shortcut, the controller should use the forceHandOver input, \r\n-\tin case of delegation towards a responsibility which is not in the list of crossed responsibilities, the controller must use the forceHandOver delegate input." }, { "name": "Successful request", "description": "If the request is successful, the following transition data are updated:\r\n-\tthe coordinationStatus of the giving responsibility is set to RELEASED,\r\n-\tthe coordinationStatus of the receiving responsibility is set to FREQUENCY_CHANGED (eq. assumable),\r\n-\tthe coordinationStatus of any responsibility that is DEASSUMED is set to HANDED_OVER." }, { "name": "Delegation case", "description": "In case of delegation, some other data are updated (see the results of the delegate operation)." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation to accept a coordination data proposal previously sent . ", "idempotency": "NON_IDEMPOTENT", "name": "coordinationAccept", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "CoordinationAccept" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "CoordinationAccept input", "description": "Even if the downstream changes, the responsibility originator of the coordinationAccept input must be the consulted responsibility (the responsibility delivered for CONSULTATION). The name of this consulted responsibility can be deduced from the servedController list (distributionKind \u003d CONSULTATION) of the alternative SFPL corresponding to the proposal according to the direction of this proposal (direction \u003d DOWNSTREAM / UPSTREAM), and its identifier is in the ControlSector list. \r\nOn a coordinationAccept input:\r\n- The whole set of coordination data is considered agreed by CCS.\r\n- The coordination status of the transition is set to ACCEPTED.\r\n- The update of the coordination data within the real SFPL triggers the recomputation of the trajectory.\r\n- The WhatIF flight supporting this coordination dialog is deleted from CCS (the HMI manages itself the removal of the whatIF flights associated with an ACCEPTED/REJECTED dialog in its system). " } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation to input a dialogue with a new coordination proposal.\r\nThis service is to be used by either the upstream or the downstream controller.\r\nWhen 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.\r\nWhen 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.\r\nThe 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: \r\n-\tin case of downstream proposal: Transfer Flight Level, Route (including direct to a new point), Next SSR code, COP, Time on transition point. \r\n-\tin case of upstream proposal: the Transfer Flight Level or the Route (including direct to a new point).\r\n\r\nIn 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).\r\n\r\nThe 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.. ", "idempotency": "NON_IDEMPOTENT", "name": "coordinationProposal", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "CoordinationProposal" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "REV equivalent message", "description": "In case the Standard/Non Standard conditions would be assessed by FDP-C\u0026T (and/or unknown in the CWP), this operation can also be an REV equivalent" }, { "name": "COP and time on transition point", "description": "The COP and Time on transition point are not applicable to an upstream coordination proposal." }, { "name": "whatIfId parameter", "description": "The whatIfId is mentioned for interoperability purpose only; it is not used by CCS for this operation." }, { "name": "consulted responsibility computation", "description": "To compute the consulted responsibility, the system determines the new control responsibility list for the whatIf flight (resulting from Trajectory prediction using the proposed coordination data), and identify the consulted responsibility as the first downstream responsibility concerned by the new coordination data." }, { "name": "OLDI transition", "description": "An upstream coordination proposal for an OLDI transition is accepted whatever the coordination dialog status is." }, { "name": "transition typology computation", "description": "The system re-computes the typology of the transition from the proposal conditions and the consumer can receive a warning if the computed typology differs from the initial typology considered by Coflight. " } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation to reject a coordination data proposal previously sent. ", "idempotency": "NON_IDEMPOTENT", "name": "coordinationRejection", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name.", "direction": "IN", "isFault": false, "name": "CoordinationRejection" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "Coordination rejection input", "description": "Even if the downstream changes, the responsibility originator of the coordinationRejectioninput must be the consulted responsibility (the responsibility delivered for CONSULTATION). The name of this consulted responsibility can be deduced from the servedController list (distributionKind \u003d CONSULTATION) of the alternative SFPL corresponding to the proposal according to the direction of this proposal (direction \u003d DOWNSTREAM / UPSTREAM). And its identifier is in the ControlSector list.\r\n\r\nOn a coordinationRejection input:\r\n- The whole set of coordination data is considered rejected by CCS.\r\n- The coordination status of the transition is set to REJECTED.\r\n- The WhatIF flight supporting this coordination dialog is deleted from CCS (the HMI manages itself the removal of the whatIF flights associated with an ACCEPTED/REJECTED dialog in its system). " }, { "name": "coordinationReference parameter", "description": "coordinationReference is defined as common to all CTM operations (it is mentioned for interoperability purpose only), but it is not used by CCS for this operation." }, { "name": "flightId parameter", "description": "the flightId is defined as mandatory for all CTM operations for interoperability purpose, but it is not used by Coflight for this operation coordinationRejection (the whatIfId is used to retrieve the concerned SFPL). It is ignored by CCS for this operation." }, { "name": "Coordination rejection limitation", "description": "In CCS, it is not possible to reject a proposal already agreed, because the agreed proposal is directly applied in the real SFPL and the whatIf flight containing the proposal is deleted (as soon as the coordinationAccept is performed)." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "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.. ", "idempotency": "NON_IDEMPOTENT", "name": "activateCoordination", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "ActivateCoordination" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "coordinationReference parameter", "description": "coordinationReference is defined as common to all CTM operations (it is mentioned here for interoperability purpose only), but CCS does not use it for this operation." }, { "name": "whatIfId parameter", "description": " whatIfId is defined as common to many CTM operations (it is mentioned here for interoperability purpose only), but CCS does not use it for this operation." }, { "name": "Successful request", "description": "If the request is successful, the coordinationStatus of this receiving responsibility is set to ACCEPTED.\r\nThen the updated SFPL is published using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs." }, { "name": "Coordination with OLDI ATSU", "description": "In case of coordination with an OLDI ATSU, the system triggers the sending of the relevant ACT message, following the settings of the coordination states." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation to indicate the assume of the flight when the protocol cannot be followed. . ", "idempotency": "NON_IDEMPOTENT", "name": "forceAssume", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "ForceAssume" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "coordinationReference parameter", "description": "coordinationReference is a parameter common to all C\u0026T operations, but which is not used by CCS for the assumeFlight operation." }, { "name": "respTraversalId and respName parameters", "description": "respTraversalId and respName are mutually exclusive and the controller must provide at least one of them" }, { "name": "reassume a flight", "description": "This operation does not allow to re-assume a flight previously handed-over; this will be managed in CCS by the handOverRecall operation." }, { "name": "forceAssume input", "description": "Whatever the parameter given in the input (respTraversalId or respName), CCS shall:\r\n-\ttrigger a normal assumption if the assuming responsibility is in the list of crossed responsibilities and if it is assumable (eq. coordinationStatus FREQUENCY_CHANGED),\r\n-\ttrigger an assume by shortcut if the coordinationStatus of the assuming responsibility is in the list of crossed responsibilities but it is not assumable,\r\n-\ttrigger an assume by delegation if the assuming responsibility is not in the list of crossed responsibilities" }, { "name": "Communication Responsibilities update", "description": "The Communication Responsibilities will be updated as follows:\r\n-\tthe Current Communication Responsibility will be the Responsibility designated in the input.\r\n-\tthe Instructed Communication Responsibility will be cleared." }, { "name": "Successful request", "description": "If the request is successful, the following transition data are updated:\r\n-\tthe coordinationStatus of the assuming responsibility is set to ASSUMED,\r\n-\tthe coordinationStatus of the giving responsibility is set to DEASSUMED, but it may be set to HANDED_OVER according to the eligibility rules definition or if this giving responsibility is RELEASED,\r\n-\tthe rofIndicator is unset if it was set.\r\nThen the updated SFPL is published using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation to input a verbal coordination dialogue in inter-centre.. ", "idempotency": "NON_IDEMPOTENT", "name": "coordinationManualAgreement", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name.", "direction": "IN", "isFault": false, "name": "CoordinationManualAgreement" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "Intra centre coordination", "description": "For an intra-centre coordination, the ATCO must directly input the corresponding clearance via the relevant operation (requestProcessXFL...).\r\n" }, { "name": "Successful request", "description": "If the request is successful, CCS performs the following updates:\r\n-\tThe coordination data of the transition are updated in the SFPL.\r\n-\tThe entered coordination data are considered as agreed coordination data.\r\n-\tThe update of the coordination data triggers the recomputation of the trajectory.\r\n-\tThe computation of the servedController list according to the new sector List if any. \r\nThen the SFPL is published using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs. " }, { "name": "Unsuccessful request", "description": "CCS rejects the input if :\r\n-\tagreedCoordinationData is empty,\r\n-\tthe coordinationReference indicating the Downstream/Upstream direction is not provided." }, { "name": "coordinationReference parameter", "description": "The coordinationReference parameter is optional because it is inherited from a class used also by other CTM operations, but it is mandatory for this operation." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation to indicate that the upstream controller requests to recover the flight control after a handOver operation.\r\nThe 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).\r\nThis operation being only for intra-centre operation, there is no OLDI message equivalent.\r\n. ", "idempotency": "NON_IDEMPOTENT", "name": "handOverRecall", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "HandOverRecall" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "coordinationStatus parameter", "description": "the coordinationStatus of the giving responsibility is set to RELEASED, and the coordinationStatus of the receiving responsibility is set to FREQUENCY_CHANGED (eq. assumable)." }, { "name": "Successful request", "description": "If the request is successful, the following transition data are updated in the SFPL:\r\n-\tthe coordinationStatus of the giving responsibility is set to ASSUMED,\r\n-\tthe coordinationStatus of the receiving responsibility is set to ACCEPTED.\r\nThen the updated SFPL is published using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs.\r\n" } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation performed by the accepting unit to the transferring unit, when required, to request the transfer of the flight\r\nThis is a ROF msg equivalent.\r\nIt may be used:\r\n-\tin reply to a handOverProposal (HOP) to signify the acceptance of the flight under the proposed conditions,\r\n-\tor to request the early transfer of the flight.\r\n. ", "idempotency": "NON_IDEMPOTENT", "name": "handOverRequest", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "HandOverRequest" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "coordinationReference parameter", "description": "coordinationReference is defined as common to all CTM operations (it is mentioned here for interoperability purpose only), but CCS does not use it for this operation" }, { "name": "whatIfId parameter", "description": "whatIfId is defined as common to many CTM operations (it is mentioned here for interoperability purpose only), but CCS does not use it for this operation." }, { "name": "Successful request", "description": "If the request is successful, CCS performs the following updates in the SFPL:\r\n-\tthe coordinationStatus of the receiving responsibility is set to REQUEST_ON_FREQUENCY in the SFPL,\r\n-\tthe rofIndicator is set in the transferData of the relevant transition.\r\nThen the updated SFPL is published using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs.\r\n" } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "Operation to forward a counter proposal from the accepting unit to the transferring one or vice versa during the coordination phase.\r\nThis 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.\r\nCounter-proposal input is accepted only if no counter-proposal has been issued before.\r\nThe 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.. ", "idempotency": "NON_IDEMPOTENT", "name": "coordinationCounterProposal", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "CoordinationCounterProposal" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "responsibility originator", "description": "Even if the downstream changes, the responsibility originator of the coordinationCounterProposalinput must be the consulted responsibility (the responsibility delivered for CONSULTATION). The name of this consulted responsibility can be deduced from the servedController list (distributionKind \u003d CONSULTATION) of the alternative SFPL corresponding to the proposal according to the direction of this proposal (direction \u003d DOWNSTREAM / UPSTREAM). And its identifier is in the ControlSector list." }, { "name": "coordination counterproposal input", "description": "The counter-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 coordinationCounterProposal is considered IMMEDIATE)." }, { "name": "consulted responsibility whatIf flight", "description": "The controller of the consulted responsibility receives a whatIF flight with the proposed coordination data and the coordination status of the transition is kept as PROPOSED." }, { "name": "coordination counterproposal input processing", "description": "On a coordination counter-proposal input, the new proposal replaces the previous proposed coordination data within the alternative SFPL by applying only data input in the counter-proposal." }, { "name": "transition typology recomputation", "description": "The system re-computes the typology of the transition from the counter-proposal conditions." }, { "name": "SFPL update", "description": "Then the SFPL is published using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] }, { "description": "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).\r\n*: the responsibilities of the relevant internal segment. \r\nThe request shall contain the responsibility to skip in the ControlSector list (respTraversalId).\r\nThe 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.\r\nThe skip processing does not impact the application of constraints and the trajectory prediction.\r\n. ", "idempotency": "NON_IDEMPOTENT", "name": "replaceSectors", "operationMessage": [ { "description": "Message definition of the operation corresponding to the same class name", "direction": "IN", "isFault": false, "name": "ReplaceSectors" }, { "description": "Specialisation of the common RequestReport.", "direction": "OUT", "isFault": false, "name": "CoordinationAndTransferResponse " } ], "processingConsideration": [ { "name": "Successful request", "description": "If the request is successful, the following transition and control sector data are updated:\r\n-\tthe coordinationStatus of the skipped responsibility is set to COMMUNICATION_SKIPPED, except if the upstream or downstream responsibility belongs to another ADSP (in this case, the coordinationStatus is not impacted by the operation),\r\n-\tthe transitionStatus of the skipped responsibility is set to SKIPPED, except if the upstream or downstream responsibility belongs to another ADSP (in this case, the transitionStatus is not impacted by the operation),\r\n-\tthe sectorState of the skipped responsibility is set to SKIPPED.\r\n" }, { "name": "skipped LogicalCWP with upstream OLDI transition", "description": "When the skipped LogicalCWP has an upstream OLDI transition, CCS sends automatically an OLDI SCO message (Skip Communication Message) to this upstream ATSU. \r\nNote: unlike CCS, in PJ16 definition, the operation is allowed only when the upstream responsibility is in the same ATSU." }, { "name": "SFPL update", "description": "Then the SFPL is published using the FlightDataDistributionSubscriber Service Interface in order to be displayed in the Controller HMIs." }, { "name": "responsibility traversal skipped", "description": "When the responsibility traversal is skipped, this operation allows to unskip it (i.e. cancel the skip). To perform this input, the respTraversalId parameter should not be filled." }, { "name": "sectorInCurrentSequence and sectorInNewSequence parameters", "description": "sectorInCurrentSequence and sectorInNewSequence are defined for this operation (it is mentioned here for interoperability purpose only), but CCS does not use them for this operation." }, { "name": "mapping change", "description": "On a mapping change impacting the skipped traversal or a coordination data input for the skipped traversal, the skip is cancelled." } ], "synchronicity": "SYNCHRONOUS", "tiProtocolMethod": [ "transfer" ] } ], "serviceInterfaceBinding": "SWIM_TI_YP_1_0_AMQP_MESSAGING", "tiPrimitiveMessageExchangePattern": "SYNCHRONOUS_REQUEST_RESPONSE" } ], "version": "2.0.0" } }