For making the request the user has to build the WFS request-link from baseUrl and relPath in the notification message. Furthermore the user needs credential for access.
The SSR code management service allows a client to reserve an SSR code for manual assignment later on (i.e. manual assignment by using the Operation setSsr service call), and to clear such code from display in the whole OPS sector.An SSR code reserved for manual assignment is not available for automatic assignment. The SSR code will be reserved during a design parameter time and then released if not manually assigned to any flight plan or released according to the standard release rules if manually assigned to a flight plan during this design parameter time. When an input is made and successfully processed the response to the request is delivered in two parts: • Each input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input. • Secondly, provided the input was accepted, the updated information (as delivered by the SsrCode Distribution service) is sent. As such, subscription to the SsrCode distribution service is mandatory prior the user requesting modifications.
The sectorisation management service provides any connecting client with the means to perform a re-sectorisation change. Two kind of requests can be made, being: • A request to verify a new sectorisation change (i.e. would the request once executed be valid for the server?), • A request to perform a sectorisation change. When an input is made and successfully processed the response to the request is delivered in two parts: • Each input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input. • Secondly, provided the input was accepted, the updated information (as delivered by the Sectorisation Distribution service) is sent. As such, subscription to the Sectorisation distribution service is mandatory prior the user requesting sectorisation modifications.
The Flight Bright Management service allows any connecting CWP client to perform inputs related to highlight of a track or flight plan, more specifically: • SSR Bright: o Add an SSR Code to the SSR Bright function for his OPS sector o Cancel all SSR Codes from the SSR Bright function for his OPS sector o Delete one SSR Code from the SSR Bright function for his OPS sector • ModeS Bright: o Add an ModeS callsign to the ModeS Bright function for his OPS sector o Cancel all ModeS callsign from the ModeS Bright function for his OPS sector o Delete one ModeS callsign from the ModeS Bright function for his OPS sector • FPL Bright: o Add a flight to the FPL Bright function for his OPS sector o Delete a flight from the FPL Bright function for his OPS sector o Add a flight to the FPL Bright function of another internal OPS Sector (by specifying an internal flight sector) o Point a flight to an external flight sector / centre When an input is made and successfully processed the response to the request is delivered in two parts: • Each input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input. • Secondly, provided the input was accepted, the updated information (as delivered by the Flight Bright Distribution service) on the flight is sent. As such, subscription to the Flight Bright distribution service is mandatory prior the user requesting modifications. Please do note that the distribution of the FlightBright message is OPS sector oriented.
The Correlation Management service allows any connecting CWP client to perform inputs related to the linkage or unlinkage of flight plans with tracks, more specifically:
• Link a flight plan with a specific track,
• Unlink a flight plan from a specific track,
• Set the present, next or downstream SSR code a flight.
When an input is made and successfully processed the response to the request is delivered in two parts:
• Each input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input.
• Secondly, provided the input was accepted, the updated information (as delivered by the Flight Plan Distribution service) on the flight is sent. As such, subscription to the flight plan distribution service is mandatory prior the user requesting flight data modifications. Additionally, if the user is subscribed to the Correlation Distribution service, extended correlation information will be sent.
The Sector Specific Data Management service supports any connecting CWP client to send certain inputs in order to trigger the correct & latest up-to-date controller information regarding sector-specific information and coordination & transfer information, more specifically:
• Allow taking control of a flight (or proposing hand-over, request-on-frequency, etc.),
• Change the coordinated entry and exit levels,
• Deliver departure clearance for an flight departing from an internal aerodrome,
• Skip and cancel-skip of an internal sector,
• Bypass and cancel-bypass of the 1st downstream internal sector,
• Delegate the flight to another internal sector,
• Change the next downstream internal sector into the preferred one,
• Change the entry/exit frequency of sectors,
• Etc.
When an input is made and successfully processed the response to the request is delivered in two parts:
• Each input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input.
• Secondly, provided the input was accepted, the updated information (as delivered by the Flight Plan Data Distribution & Sector Specific Data Distribution service) on the flight is sent. As such, subscription to the both aforementioned services is mandatory prior the user requesting sector specific data modifications.
To process the input of a control input command, to allow either:
• Take control of the flight,
• Transfer control of the flight,
• Delegate control of the flight to the sector where the flight is geographically located,
• Hand-over propose/accept.
The operation allows to:
• Skip and cancel-skip of an internal sector,
• Bypass and cancel-bypass of the 1st downstream internal sector,
• Delegate the flight to another internal sector,
• Change the next downstream internal sector into the pre-ferred one.
The operation allows performing coordination changes related to the entry of the sector performing the request. The operation applies to both internal and external entry coordination.
Changes to the following items can be requested, or negotiated:
• NFL & NSFL (as also possible with requestNFL – see section 3.6.4)
• Departure level (indicates the initial cleared level for departure flights out of an internal aerodrome)
• ETO (Estimated Time Over)
• COP (Coordination Point)
• PSSR (Present SSR Code)
• DCT-to point (including intermediate point if required)
• Accepting Frequency
• Speed
• Heading
The operation allows performing coordination changes related to the exit of the sector performing the request. The operation applies to both internal and external exit coordination.
Changes to the following items can be requested, or negotiated:
• TFL & TSFL (as also possible with requestTFL – see section 3.6.5)
• ETO (Estimated Time Over)
• COP (Coordination Point)
• PSSR (Present SSR Code)
• DCT-to point (including intermediate point if required)
• Transferring Frequency
• Speed
• Heading
The operation allows performing a departure clearance (for a flight departing from an internal aerodrome). For example, a TWR sector can perform this action, or eventually a higher sector that has to deliver the departure clearance.
Items available in the departure clearance are kept limited for the first phase and include:
• Departure level (indicates the initial cleared level for departure flights out of an internal aerodrome)
• Take-off time
• PSSR (Present SSR Code)
• Accepting Frequency
• SID
• Departure runway
The operation allows an OPS sector:
• To select the frequency to be sent to the transferring previ-ous adjacent center or internal sector,
• To select the default for the frequency to be sent to the transferring previous adjacent center or internal sector,
• To change the exit frequency with the next partner or internal sector,
• To reset the exit frequency.
The Flight Plan Data Management service supports any connecting CWP client to send certain inputs in order to trigger the correct & latest up-to-date controller information, more specifically: • Create ASPL or SFPL, • Modify an ASPL/SFPL or upgrade an SFPL, • Downgrade an SFPL into an ASPL, • Delete an existing ASPL/SFPL, • Submit requests about instructions/clearances given to the flight crew (e.g. DCT, CFL, NFL, speed, heading, …) • Change status information regarding the flight’s airframe (e.g. no FSSA, RVSM status, …) • Etc. When an input is made and successfully processed the response to the request is delivered in two parts: • Each input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input. • Secondly, provided the input was accepted, the updated information (as delivered by the Flight Plan Distribution service) on the flight is sent. As such, subscription to the Flight Plan Distribution service is mandatory prior the user requesting flight data modifications.
The operation allows modifying:
• number of aircraft related to a flight plan
• aircraft type
• flight’s wake-turbulence category
• flight’s deviation status
• RVSM capability
• 8.33 kHz capability
• UHF equipment
• BRNAV/PRNAV equipment
• ModeS capability
• Number of people on board
• FSSA capability
• Avoiding weather indicator
• Fuel dumping indicator
From an operational perspective, a DCT action can represent multiple cases. The interface definition has been considered to fulfil the op-erational scenarios listed below. For completeness reasons the required options to be passed in the RequestDCT input are given below:
• DCT to a (intermediate) Point
o to
Allows the sending of a single route point name (or coordinate) with optional intermediate point. In this case, the MSB-CB will automatically determine the most likely type of DCT instruction given (i.e. make the distinction between “to-original-route” and “to-trajectory” as given below). From an interface and client implementation perspective this option allows to perform DCT actions without the requirement for the client to reference to index in the trajectory. Also, this option allows also performing a DCT instruction for an ASPL for which no trajectory is available.
• DCT to Point on the Trajectory (Uplink = UM74)
o to-trajectory
intermediate-point not sent
end-point represents the index point and posi-tion in the trajectory
• DCT to Point on the Original Route (Uplink = UM74 + UM72)
o to-original-route
intermediate-point not sent
end-point represents the point name (located on the original route)
• DCT to (Intermediate) Point not located on the trajectory; in this case the end-point is on the trajectory (Uplink = UM79: "CLEARED TO [end-point] VIA [intermediate-point])
o to-trajectory
intermediate-point represents the route point name or position of the intermediate point
end-point represents the index point and posi-tion in the trajectory
• DCT to (Intermediate) Point not located on the trajectory; in this case the end-point is on the original route (Uplink = UM79: "CLEARED TO [end-point] VIA [intermediate-point] + UM72)
o to-original-route
intermediate-point represents the route point name or position of the intermediate point
end-point represents the point name (located on the original route)
• DCT to (Intermediate) Point not located on the trajectory, and no end-point specified. In this case, the DCT is considered to be a point completely off-route, which is not to be rejoined. A typical example is a DCT to a point outside the AoI, which is not located on the trajectory (Uplink = UM74).
o to-trajectory
intermediate-point represents the route point name or position of the intermediate point
end-point represents the null index point
Note 1: A current heading restriction will be removed upon receiving a DCT input.
Note 2: For ASPLs, a DCT to an Intermediate OR End Point is allowed (with whatever DctData option) provided any reference to a trajectory point is populated with the null-TrajectoryPointNumber. Inputs combining both Intermediate AND End Point will not be processed.
From an operational perspective, a change route action represents a re-routing of the flight across multiple waypoints (unlike a DCT where the flight is instructed to go to only one waypoint).
Note 1: A current heading restriction will be removed upon receiving Operation changeRoute.
Note 2: Only available for SFPLs.
The interface definition has been compiled taking into account the operational cases listed below. For completeness reasons the possible parameters, for such situations, to be passed in the RequestHeading input are indicated as well:
• Present Heading (uplink possible)
• Assigned Heading – relative or absolute true/magnetic heading (uplink possible)
• Non-specified Heading; use track direction as heading and update trajectory with this value (no uplink possible)
• Heading to avoid weather, for example CBs; use track direction as heading an generate an observed tactical trajectory with it (no uplink possible)
In the first three cases above, the type of heading closure is mandatory in the request. The following cases have been distinguished in case the application limit and trajectory resuming point are included in the request:
• No application limit and rejoining point specified in the input: a default application limit will be applied and the trajectory will be closed based on pre-defined closure rules.
• Application limit specified as distance and rejoining point present in the request: the specified distance and rejoining-point will be applied.
• Application limit specified as “Indefinite”: the system will auto-close the trajectory at AoR exit.
In all cases, the input heading is considered as magnetic heading.
The command allows resetting a previous heading instruction for ASPLs only. In case the command is requested for an SFPL, the result will be returned with an error.
To process the input of an enroute cruising level. The ECL is applied until the exit of the AoI (i.e. propagated all the way), unless the ap-plication-limit is present in the request.
The interface definition has been compiled taking into account the operational cases listed below:
• Present speed (uplink possible)
• Assigned speed, including route point until where the speed restriction should apply (uplink possible)
• Speed range, including route point until where the speed re-striction should apply (between a lower and upper speed)
• Minimum or Maximum speed instruction, including route point until where the speed restriction should apply (uplink possible)
• Keyword, to represent a pure textual speed instruction to the ATCO (e.g. CLEAN speed) without affecting the flight’s calculat-ed profile
• Resume speed, to cancel any previous speed restriction (uplink possible)