SYNCHRONOUS_REQUEST_RESPONSE

Allows to modify the current configuration of the runways for an aerodrome of a given Aerodrome Group.
This operation enables an eligible user (normally a supervisor) to modify the following data of a given runway or of the runway(s) of an aerodrome: landing and/or take-off rates, IAP in operation and operating mode (open or closed).
It is also possible to revert to default rate values of runway(s) if no rate value is provided in the operation..

Allows replacing the current Aerodrome Group Configuration with another given aerodrome group configuration.
The user may activate an offline predefined aerodrome group configuration, activate the one previously defined as the Next one or revert back to the default one.

When the aim of this operation is to :
- activate an offline predefined aerodrome group configuration, aerodromeGroupConfigName should be filled with the name of the configuration,
- activate the next aerodrome group configuration, aerodromeGroupConfigName should not be filled,
- revert back to the default aerodrome group configuration, aerodromeGroupConfigName should not be filled and aerodromeConfigurationOrigin should be DEFAULT.
.

Allows removing the fact that an aerodrome group configuration is identified as the next one..

Allows modifying the configuration parameters of an aerodrome.

The 3 possibilities given by this operation are :
- revert to default the aerodrome Altitude Correction
- revert to default the aerodrome Transition Level. In this case, defaultAltitudeCorrection should be set to FALSE
- modify one or several of the following parameters : transitionLevel, altitudeCorrection, modeSCapabilityState. In this case, revertToDefault should not be filled

aerodromeGroup is ignored by CCS..

Allows a consumer to get the erroneous AFTN messages referred to FDO for manual correction, either for a specific erroneous message by filling the messageId, or all the erroneous messages if the messageId attribute is empty.

Refer to publishErroneousAFTNMessageData description for more details about the list of errors that can be enc.

This operation allows a generic client (eq. Air Server system) to inform that an aircraft has made a Datalink logon and to associate the corresponding logon parameters with an SFPL..

Operation to indicate the assume of the flight..

Operation to transmit the intention of releasing the flight according to the agreed transfer conditions.
Depending on the LoAs: e.g. expecting a further AssumeFlight operation or just waiting for a radio contact to release the flight.
This is an OLDI COF (Change Of Frequency) message equivalent.

This operation also offers the possibility to hand over the flight to another crossed responsibility than the expected one (eq. shortcut forceHandOver input). In that case, it is expected to provide explicitly the new responsibility traversal to which the transfer is performed, as well as the identifier of this responsibility (available in the SFPL ControlSector list).
This operation also offers the possibility to hand over the flight to a responsibility not in the list of crossed (eq. delegate input)..

Operation to accept a coordination data proposal previously sent .

Operation to input a dialogue with a new coordination proposal.
This service is to be used by either the upstream or the downstream controller.
When the proposal is initiated by the downstream, this is an OLDI CDN message equivalent. When the proposal is initiated by the upstream, this is mainly an OLDI RRV equivalent.
When the proposal is initiated by the upstream, it may be a RAP message equivalent if the downstream is not yet NEAR_PLANNING and if RAP transmission is off-line authorised. Else it may be an RRV message equivalent if the downstream is at least NEAR_PLANNING.
The input shall contain the identification of the SFPL, the receiving responsibility, the coordinationReference value (downstream or upstream proposal) and at least one of the following proposed coordination data:
- in case of downstream proposal: Transfer Flight Level, Route (including direct to a new point), Next SSR code, COP, Time on transition point.
- in case of upstream proposal: the Transfer Flight Level or the Route (including direct to a new point).

In both cases, the proposal input can also contain a Supplementary Flight Level, the boundary point type and, only when sent to another sector of the same ATSU, the following tactical instructions: Heading, Speed, ROCD and CFL (the application point of tactical instructions in coordinationProposal is considered IMMEDIATE).

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

Operation to reject a coordination data proposal previously sent.

Operation to force in advance (prior to the automatic coordination event) the triggering of the coordination event for a given transition between two responsibility traversals by sending specific flight details..

Operation to indicate the assume of the flight when the protocol cannot be followed. .

Operation to input a verbal coordination dialogue in inter-centre..

Operation to indicate that the upstream controller requests to recover the flight control after a handOver operation.
The flight is then expected to get back into the previous state. However, for the receiving responsibility, there may be some exceptions (when the flight is a re-entering flight which was HANDED_OVER or RELEASED, or when it is a stolen flight which was DEASSUMED).
This operation being only for intra-centre operation, there is no OLDI message equivalent.
.

Operation performed by the accepting unit to the transferring unit, when required, to request the transfer of the flight
This is a ROF msg equivalent.
It may be used:
- in reply to a handOverProposal (HOP) to signify the acceptance of the flight under the proposed conditions,
- or to request the early transfer of the flight.
.

Operation to forward a counter proposal from the accepting unit to the transferring one or vice versa during the coordination phase.
This is basically replicating the CDN message, but the application context is extended beyond the OLDI scope in order to possibly support counter proposal from transferring to accepting when sent to another sector of the same ATSU.
Counter-proposal input is accepted only if no counter-proposal has been issued before.
The input shall contain the identification of the SFPL, of downstream the responsibility of the transition on which the coordination dialogue was initiated and at least one of the following proposed coordination data: Transfer Flight Level, Route (including direct to a new point), Next SSR code, COP, Time on transition point..

Operation to cancel a previous assume of a flight.

Operation to transmit the intention of releasing the flight according to the provided data..

closePointOut is used in response to a pointOut notification for formally notifying the system that the notification has been processed by the receiver.
This remains a local action between the receiver and his/her system without any OLDI equivalent message.
The originator controller is capable of ending the point session, while the designated controller is capable only to remove his OEs from the recipient list (and if there is no more recipient, the point session is ended). The exception being that it is not possible to end a point session in another OLDI ATSU because OLDI considers the "point" as a one shot distribution..

The Point message is sent to controller(s) of the same ATSU or another ATSU to point out a flight in order to facilitate verbal coordination, irrespective of whether co-ordination has taken place.
This is a PNT msg equivalent.
The input of the point function shall contain the identification of the SFPL and the identification of one or several point target sector(s).
The use of a reason parameter written by the originator is only allowed for Point message sent to controller(s) of the same ATSU.
The main uses of the point function are:
- highlight: to support vocal exchanges during the co-ordination process. In such cases, the flight is designated by the giving position, and it is highlighted on the positions managing the pointed sector(s).
- manual distribution: to support the delivery of flight data to a chosen recipient:
- for information, if the recipient is not within the computed informed responsibility list (e.g. to check with an adjacent position the possibility to transfer the flight to it)
- to replace automatic distribution by manual distribution, when the system is degraded.
.

Operation to transfer the responsibility of a flight to a responsibility that is not in the list of the planned crossed responsibilities.
The input shall contain the identification of the SFPL and the name of the receiving responsibility (toSector)
.

Operation to propose the flight for hand-over to the accepting controller (unit) when required.
This is a HOP msg equivalent.
This operation is possible only if the accepting unit is another ATSU.
This operation is allowed only if no clearances request is on going (either no request has been received for the flight, or otherwise it has been answered).
The input shall contain one or more of the following transfer data: CFL, assigned heading, direct route clearance, assigned speed, assigned rate of Climb/Descent..

Operation to propose the flight for hand-over to the accepting controller (unit) when required.
This is a HOP msg equivalent.
This operation is possible only if the accepting unit is another ATSU.
This operation is allowed only if no clearances request is on going (either no request has been received for the flight, or otherwise it has been answered)..

Operation to indicate the manual acceptance by a unit of the transfer conditions previously sent (e.g. response to a propose hand over operation).
This is an ACP msg equivalent.
This operation can be a response either to a clearances request, or to a hand over proposal..