S1P1 CPDLC DEPARTURE CLEARANCE END2END DESCRIPTION

Transcription

1 S1P1 CPDLC DEPARTURE CLEARANCE END2END DESCRIPTION Data Comm Implementation Team 23 April 2015 Version 2.0 DCIT Plenary Approved An overview of the FAA Segment 1 Phase 1 (S1P1) Implementation of CPDLC Departure Clearance (DCL) processing from an end-to-end perspective S1P1 CPDLC DCL End2End Description Page iii

2 Table of Contents 1. Overview User Preferences and Flight Plan Filing Initial CPDLC Clearance Generation Logon and Connection Establishment DCL Pilot Downlink Request and Uplink Response Pilot Response to Clearance AOC/FOC Dispatch Message Generation and Response Revised CPDLC Uplinks CPDLC Service Termination Appendix A: DCL Production System Message Samples Appendix B: Production System Dispatch Message Samples Appendix C: S1P1 Gate Request Message Samples Appendix D: ICAO FPL DCL Delivery Codes Appendix E: Selected S1P1 Production System Future Capabilities Appendix F: Subscriber Data Base Users Guide Summary S1P1 CPDLC DCL End2End Description Page iv

3 DCIT End-to-End Procedures for CPDLC Departure Clearance Operational/Production System (Segment 1 Phase 1) Draft, V1.2, 22 April Overview This document describes the Future Air Navigation System (FANS) 1/A(+) Controller Pilot Data Link Communication (CPDLC) Departure Clearance (DCL) for the Production system that is being deployed by the Federal Aviation Administration (FAA) in 2016, from an end-to-end view. This is a high-level summary designed to capture the Data Comm Implementation Team (DCIT) inputs into the operational procedures and concepts for this new CPDLC capability for departure clearances, and was developed from the comparable End-to-End Procedures for the Trials demo system and the Segment 1 Phase 1 (S1P1) Production system specifications. This is designed to be a work in progress, leveraging DCIT, industry and user community inputs, and is planned to be updated as new information becomes available. Note that the appendices and most of the S1P1 Production system documents use the term DCL for the FANS CPDLC departure clearance. Within this E2E DCIT document, the term CPDLC will be used, however the term DCL may be considered synonymous. 2. User Preferences and Flight Plan Filing 2.1. Subscriber Data Base Prior to specific flight plan filing, the user has an option to designate flights that will participate in the CPDLC Departure Clearance service, using a new FAA Web- Access Subscriber Data Base (SDB). Details for using the SDB are provided in the User s Guide For Tower Data Link Service (TDLS) Subscriber Database (SDB) Webbased Application. An extract of this is provided in Appendix F. Using standard browser capabilities, users may designate DCL and PDC clearance delivery settings independently from flight plan filing. The SDB values for CPDLC or PDC service will be superseded by the service preferences provided in the flight plan. The SDB allows the user to provide a fleet default value an airport/fleet value, e.g., all airline flights at airport X get PDC, or a flight-specific value, e.g., XYZ123 gets CPDLC. For those users currently receiving PDC service, the default settings for the SDB will be the current PDC options SDB Fallback Hierarchy If desired, users may designate a CPDLC primary/ PDC secondary hierarchy for CPDLC flights. If the CPDLC service is not available, flights that are explicitly designated as PDC secondary will revert to PDC if they have not yet been S1P1 CPDLC DCL End2End Description Page 1

4 processed as a CPDLC flight. This user preference can be implemented in the Subscriber Data Base, the filed flight plan, both or none. Note: The fallback to PDC capability applies when the entire CPDLC service is unavailable at an airport, not when an individual flight ends up not being eligible for a CPDLC clearance SDB Updates Users may update the SDB up to 60 minutes prior to the filed departure time (Ptime). If a user wants to change delivery preferences after that time, they should either cancel and refile or amend the flight plan accordingly (up to approximately 45 min) Flight Plan Filing Service Eligibility a. In order to receive CPDLC or PDC service, users should file an ICAO flight plan, nominally not later than 45 minutes prior to P-Time (P-Time defined within this document as the proposed departure time in the flight plan), via normal flight plan filing mechanisms. b. The flight plan must have the Flight Identification (FID) in Field 7 (e.g. FDX123), the departure airport, and registration number in field 18, per standard requirements for FANS operations (ref: GOLD a). c. Users participating in the Trials activity should no longer include FRC DCL in the Remarks field. The presence of FRC will make a DCL flight ineligible for a Cleared as Filed initial clearance. Other RMK entries can and should still be included in the flight plan as necessary User Preference in Flight Plan For flights that will participate in the CPDLC service or the legacy PDC service, users may designate the flight as CPDLC or PDC in either the ICAO Flight Plan (FPL) and/or the FAA Web-Access SDB (see above). i. If using the ICAO FPL, the user includes the relevant equipage codes and Z in the Equipage Field 10a, and the appropriate CPDLC/PDC delivery preference code in the DAT/ sub-field of Field 18. (See Appendix D, Table D - 1 ICAO FPL Field 10a and Field 18 DAT/ Codes, for the specific proposed preference codes. ii. In the ground system, the ICAO FPL always takes precedence; if the clearance delivery preference codes are in the flight plan, they will override anything in the SDB. S1P1 CPDLC DCL End2End Description Page 2

5 Flight Plan Fallback Hierarchy In addition to designating the preferred clearance delivery mechanism, users may optionally designate a CPDLC DCL primary/pdc secondary hierarchy in the ICAO FPL. a. If the user designates it as such, a flight may revert to PDC if the CPDLC service becomes unavailable. If no PDC secondary code is provided, then the ground system will revert to voice for CPDLC flights. b. Hierarchy codes in the flight plan supersede any hierarchy preferences in the SDB. c. If the user did not file a CPDLC or PDC preference code in the original flight plan, a subsequent flight plan amendment may be entered to provide it within a site adaptable time prior to P-Time, e.g., min. Users may also update the flight plan codes in the flight plan up to the existing site adaptable parameter that allows users to amend flight plans. After that time, any issues/requests would require voice discussion with ATC. Note: The adaptable time is currently configured per site based on flight strip printing times, e.g. 30 minutes expected at most sites, and other values up to a maximum of 60 minutes at other sites Route Guidelines This section contains route loadability rules. If the user files a flight plan that does not adhere to these rules, the ground system will not create a PDC or CPDLC clearance for the flight - Clearances will then be handled via voice. The following definitions apply: Fix. As used below, the term fix means published intersections, waypoints, or navaids. A fix may also be a fix-radial-distance (FRD), or a latitude/longitude (L/L). For the purposes of this document an airport is not considered a fix. Route Element. Airways and fixes defining a route of flight. Departure/Arrival airports are NOT considered route elements. a. General Rules. i. Use of an airway as a route element requires a published entry and exit point for the airway, (e.g...sjn.j108.gingr..), ii. iii. iv. An implied airway/airway junction (i.e. no fix between airways) is NOT loadable,(e.g..j4..j65.). If a named fix is published at the implied junction, it may be added to make the route loadable, (e.g..j4.abi.j65.). Note- This is the preferred option. A navaid radial is NOT a loadable route element in a DataComm clearance, e.g..air111. or.abq092r.). S1P1 CPDLC DCL End2End Description Page 3

6 v. An FRD may be used in place of a navaid radial, or unnamed airway junction, (e.g...tch..tch mtu..) Note- Use a named fix, if available. Some PlaceBearingDistance (PBDs) are also an issue for some aircraft and may not be loadable. vi. vii. Unpublished, named (Ghost) fixes are not loadable, e.g. KMSY..TIKDP..). ClearanceSupportAlphas (formerly Host G-Keys) are non-standard route elements applied by ground automation, (e.g. MAXIE-STAR or RV LAIRD or RV HDG030. They may be forwarded to the AOC for PDCs, but not for CPDLC Dispatch messages. They will not be included in CPDLC uplinks to the flight crew. Use of ClearanceSupportAlphas should be avoided, if possible. b. Departure Phase (ADR/PDR, ADAR/PDAR, CDR, IFR Preferential Route, Playbook Routes, etc.) i. The first route element after departure must NOT be an airway, (e.g. KPHX.J65..). ii. The first route element may be a fix, or a SID/DP followed by the last fix on the common route, or a published transition fix. Other exit fixes are NOT loadable, (e.g. KPHX..PXR.J65.). c. Arrival Phase (AAR/PAR, ADAR/PDAR, APR, CDR, IFR Preferential Route, Playbook Routes, etc.) i. The last route element prior to destination must NOT be an airway, (e.g...j78.kama). ii. iii. The last route element must be a fix, or a STAR proceeded by a published transition fix, or the first fix on the common route. Other entry fixes are NOT loadable, (e.g....j78.ama..kama). Arrival procedures, i.e., STARs, should be filed with a published arrival transition. d. Dynamic Routes. When included in the filed flight plan, NAT tracks or other dynamic routes will be handled as any other initial or revised departure clearance. The following is a summary see Section 3 for details. i. If the filed route has not changed and the flight is eligible, a CLEARED AS FILED uplink will be sent as the initial CPDLC departure clearance. The portion of the route containing NAT tracks, as either lat/longs or name (e.g., NATW) will be considered part of the AS FILED clearance. ii. iii. If the filed route does not match the enroute automation processed route then the initial CPDLC departure clearance will be a UM79, clearing the flight to where it rejoins the route, as long as this join point is within the ground system navigational database. If a UM79 is not possible, the ground system will attempt to generate a UM80. Some dynamic routes may be eligible for a UM80 if the en S1P1 CPDLC DCL End2End Description Page 4

7 iv. route NAV database contains all relevant route elements. However, it is expected that the majority of flights flying international routes with NAT Tracks will not be eligible for a UM80. For both initial and revised clearances, if a UM79 or UM80 is not possible, then the controller will revert to a voice clearance. e. Other. Additional filing guidelines are designed to minimize discons and auto-loading issues. These include the following undesirable filings: i. Three (3) Letter Identifiers being utilized as origin and destination airports. ii. iii. XXX indicating an incomplete route. This will prevent a CPDLC or PDC departure clearance from being generated. Any custom non-published points inserted into the route. Note: Some undesirable route elements are also being applied by ground automation today based on local facility adaptation, e.g., coded routes or Traffic Flow Playbook routes. The FAA is working to remove or significantly reduce any automation-applied adapted route elements that cause loadability issues. S1P1 CPDLC DCL End2End Description Page 5

8 3. Initial CPDLC Clearance Generation Approximately 30 minutes prior to the proposed departure time (specifically at a parameter time configured to the site s current strip printing time), the en route ground system (ERAM) triggers strip printing in the tower with the planned route. The ground system will evaluate the route for CPDLC after ground system route processing Clearance Type Determination The following summarizes the ground system determination of the type of CPDLC departure clearance that a flight will receive as an initial clearance. Within this section the ground system processed route, after route conversion of either an original filed route or a subsequent amended route, will be referred to as the Data Comm route. The en route automation ground system may add, delete or modify SIDs and transitions based on adaptation rules for the application of PDR/ADRs User Preferences The ground system first determines which type of clearance the flight will receive CPDLC, PDC or voice, based on previous user designation. Note: The tower controller does not have the capability to modify the flight plan hierarchy codes. The controller can revert to voice Cleared as Filed a. If the route of flight contained in the original filed flight plan is not altered by the ground system route processing automation from what it received, the ground system will create a Cleared as Filed (CAF) CPDLC clearance for the initial departure clearance. b. If the Data Comm route, starting from the first element after the transition fix, is unchanged from the original filed route, and the controller adds a SID or SID and transition, then the flight is eligible for a CAF initial clearance. Example: Original Filed Route: KSLC..TCH..CYS..LBF..KBWI Controller Route: KSLC.LEETZ3.HOLTR..TCH..CYS..LBF UM79 Clearance: CLEARED TO KBWI LEETZ3.HOLTR THEN AS FILED, CLIMB VIA SID, c. If the filed flight plan included a SID/transition, the UM169 will include the SID/transition name and the phrase THEN AS FILED ; if there is no SID, and no climbout instructions then the phase will be AS FILED. d. The ground system will build a Cleared as Filed clearance using UM169 and UM19 (when applicable). S1P1 CPDLC DCL End2End Description Page 6

9 e. The CAF clearance will not include a route clearance variable but will include any applicable SID and transition in a UM169. It will also include Climb Via instructions in a UM169 in lieu of a UM19 initial altitude, when applicable. If automation or controller adds, modifies or removes a SID and/or departure transition, then the flight is not eligible for an CAF Initial clearance, and the an Initial UM79 will be sent instead Initial UM79 a. If the Data Comm route, starting from the first element after the transition fix (if applicable) is changed in any way from the original filed, the flight is not eligible for a CAF initial clearance. The ground system will attempt to create an initial UM79 specifying the route from departure transition to the route element where the original route is rejoined. Example: Original Filed Route: KSLC.LEETZ3.HOLTR..TCH..CYS..EMI Data Comm Route: KSLC.PECOP3.BAM..OTT..EMI UM79 Clearance: CLEARED TO EMI VIA BAM OTT, PECOP3.BAM, AFTER EMI CLEARED TO KBWI ARPT AS FILED, CLIMB VIA SID {3 lines condensed for space} b. When the filed route can be rejoined within the FAA NAV database, the ground system will uplink an INITIAL UM79 DCL message with AFTER [position] CLEARED TO [airport] ARPT AS FILED, plus other elements as required (e.g. expected altitude, departure frequency, etc.). c. If the SID has been removed from the original filed route by en route automation, the Data Comm route does not match and the flight is not eligible for a CAF initial clearance. The ground system will create an initial UM79, which includes text in the UM169 NO DPP or NO SID to explicitly indicate that SID (and transition if applicable) has been removed. The NO SID tag is used if other elements of a local departure procedure still apply, e.g., climbout such as FLY HDG xxx. Note: The NO DPP or NO SID text is also included if a subsequent revision removes the SID. d. If the Data Comm route, starting from the first element after the transition fix, is unchanged, and en route automation adds a SID and transition, then the flight is not eligible for a CAF initial clearance and the system will generate an initial UM79. Example: Original Filed Route: KSLC..TCH Data Comm Route: KSLC.LEETZ3.HOLTR..TCH S1P1 CPDLC DCL End2End Description Page 7

10 UM79 Clearance: CLEARED TO TCH VIA HOLTR, LEETZ3.HOLTR, AFTER TCH CLEARED TO KBWI ARPT AS FILED, CLIMB VIA SID e. If the Data Comm route, starting from the first element after the transition fix is unchanged, and the SID and transition, or just the transition is changed by en route automation, then the flight is not eligible for a CAF initial clearance and the system will generate an initial UM Initial UM80 a. If a CAF or a UM79 is not possible for this initial CPDLC departure clearance, and the en route ground system has NAV database information for the entire route, and the ground system can process the entire route, then the ground system will uplink a UM80 with the entire route of flight Exceptions a. If the flight is eligible for a CAF clearance but the flight plan remarks includes FRC, the ground system will build an initial UM80 when possible. If the ground system cannot convert the route to its destination, then an initial UM79 will be built instead. b. If the flight is eligible for a CAF clearance but CAF eligibility has been disabled deselected by the controller for the flight, e.g., the controller wants to send the entire route, the ground system will build an initial UM80 when possible. If the ground system cannot build a UM80, such as for an international flight, then the session will be terminated and controller and pilot will coordinate via voice. Note: This is one of the conditions when the system will not try to build a UM79. If either the pilot or the controller wants a full route clearance and it cannot be generated, then the controller will handle via voice procedures. c. Voice Clearance. If the filed route is not identical to the ground system processed route and the ground system could not create a CPDLC clearance with an initial UM79 or a UM80, then the controller will be notified and the clearance will be provided via voice, using current voice procedures. d. Incomplete Route (XXX). If the user files XXX or the ground automation cannot process the route to its destination, the ground system will not create a PDC or CPDLC clearance for the flight. This will be handled via voice. S1P1 CPDLC DCL End2End Description Page 8

11 3.2. Initial CPDLC Clearance Contents Departure Procedure Information a. The CPDLC clearance will include departure procedure/sid text (when applicable) and altitude instructions in the form of an initial MAINTAIN altitude or a Climb Via instruction. Whether a Climb Via instruction or a Maintain altitude instruction is included will be based on facility operations. The ground system will provide automation support for the appropriate options, e.g., adapted defaults for controller/system selection in generating the DCL and rules to ensure appropriate combinations. b. If applicable, the ground system will provide additional departure procedure/sid transition information by inserting required data elements, e.g., the first filed route fix for a SID/Transition combination. c. If there is no published departure procedure (SID or SID plus transition) in the original filed route and it is identical to the ground system processed route, and the controller adds a SID or SID plus transition, the ground system will generate a CAF clearance Controller/System Approval a. The controller reviews the clearance. At facilities running in automode, no controller approval is required for a CPDLC or PDC clearance unless FRC is in the flight plan or there are revisions to the flight plan or clearance data. b. The ground system automation formats the clearance into a FANS-1/A clearance using UM79, UM80, UM169, and UM19 message elements as appropriate, and places the clearance in a queue awaiting the pilot downlink request via DM25. (See Appendix for sample messages). c. The ground system initiates flight plan correlation and connection establishment as described in the following section Gate Request Message a. If required operationally at the departure tower, the user opts in for receiving a GREQ message from TDLS by providing user preferences in the Subscriber Database b. Independent from session establishment, the ground system will send a Gate Request (GREQ) message to the user/airline host system, as described in the TDLS-CSP IRD, and Appendix C, upon clearance approval by the controller(or by the ground system in automode) and when operationally applicable. S1P1 CPDLC DCL End2End Description Page 9

12 c. The user/airline host system responds to the GREQ message with two messages: a system acknowledgement (ACK) on receipt of the GREQ and a GREQ response message within an operationally appropriate time period (currently, 2 minutes for a PDC). The GREQ response message from the user/airline host system contents are specified by the TDLS-CSP IRD and include the departure parking gate, if known or G if gate is unknown. 4. Logon and Connection Establishment 4.1. Logon Pilot Logon At the appropriate time, and while still at the departure parking gate, the aircrew logs-on using the local tower ICAO facility name, e.g., KJFK. This can be done any time after the airline has filed the flight plan with the FAA Ground System Logon Processing The Ground system will accept valid log-ons, provided that log-on contains the registration number, correct departure airport, position and Flight Identification. The position in the log-on request must be within an adapted distance of the departure airport. Specifically: a. When a log-on request message (FN_CON) has valid and required data, the ground system will accept the log-on and send a positive logon response (FN_AK). In all other cases the ground system will send a negative response (FN_AK). b. If the log-on is attempted and no response is received, or a negative response is received, the aircrew may attempt another log-on or may choose to revert to voice for their departure clearance. Note: Actual flight plan correlation and CPDLC connection occurs only after the tower controller approves the CPDLC clearance at some point after P Time-30 minutes. If the aircrew logs on prior to controller approval, the ground system will wait until the controller approval to initiate a CPDLC connection. If the controller approves the clearance prior to the log-on request from the aircrew, the ground system will initiate the connection establishment upon detection of a successful logon. The ATC comm established indicator in the cockpit will be an indication to the aircrew that an approved DCL is ready. Note: During periods of heavy activity in the tower, aircrews should be aware that CPDLC connection establishment may be longer than in optimal conditions. S1P1 CPDLC DCL End2End Description Page 10

13 4.2. Connection Establishment Correlation a. Upon approval of the CPDLC clearance by the controller (or by the ground system if the facility is operating in automode) and when there is an accepted logon, the ground system will attempt to correlate the flight plan data with the logon data. If correlation fails, an error message is provided to the controller, and the controller and pilot coordinate via voice. b. Note: Flight data items used for correlation from the aircraft are the aircraft registration/tail number, the Flight ID and the lat/long position reported in the log-on. Flight ID (ABC123), Tail Number/Registration, and lat/lon in position variable are used. The ICAO facility ID is used, e.g., logging on to KMEM, but correlation uses lat/lon to determine if matches departure airport in flight plan. c. When an update (change) to flight data items used for correlation are received for a FP that is correlated with a log-on, the CPDLC connection associated with that flight plan will first be terminated, and the crew will then need to re-accomplish the log-on. d. Block List. If the aircraft has been identified as ineligible for CPDLC service due to logon problems, e.g., excessive logons that caused the flight to be on the block list, the ground automation will provide failure information to the controller when flight plan correlation is attempted. The controller and pilot will coordinate to resolve any block list issues. This may include coordination with the dispatcher and FAA personnel at a central national position Connection a. When correlation is successful, the ATC ground system will attempt to establish a CPDLC connection with the aircraft by sending a CR1 (to which the aircraft responds with a CC1). Upon receipt of a DR1 or other error indication in response to the CR1, the ground will retry sending the CR1 to the aircraft one time, after an adaptable parameter of time. b. Upon a successful CPDLC connection, the ATC ground automation and avionics may notify the controller or aircrew of the availability of CPDLC service for the flight. The ground system provides a controller display indication. Some avionics will provide an aural notification to the aircrew. c. If the controller/system approves the departure clearance and there is no accepted log-on available, the ground system will wait until there is an accepted log-on, and then attempt to establish the CPDLC connection and perform flight plan correlation. S1P1 CPDLC DCL End2End Description Page 11

14 4.3. ReLogon and Callsign Changes The following section describes expected behavior when a departing flight on the ground is the continuation of a delayed inbound arrival and when two flights on the ground have a hull swap Continuation Flight. Nominal Desired Scenarios. The departing flight will modify its callsign (AID), e.g., DL416 becomes DL416P. Timing and sequence determine the ground system processing. a. Prior to P-30. Pilot had already logged on with old AID (DL416), before P-30 or after P-30 and before controller processes DL416, which means there is no active session. Pilot does a new logon with DL416P. The ground system accepts the Logon and replaces with new AID DL416P. The AOC amends the callsign (AID) from DL416 to DL416P. The amendment by the AOC has to be prior to any strip printing or the ground system rejects (baseline). Alternately, the AOC cancels the DL416 and refiles as DL416P. No session was ever established. Once the tower controller approves the desired flight plan, DL416P after P-30, the ground system will initiate connection establishment with the aircraft. b. After P-30, after session already started for DL416 (old). Pilot coordinates with tower controller via voice. Controller removes (RS) DL416 and may manually terminate the session. The ground system closes the logon for DL416. If the controller did not manually terminate the session, the ground system will terminate it after the session timer expires (nominally 15 min). Meanwhile, pilot relogs on with new AID DL416P. Note: Some avionics would terminate the connection if it is still established on the relogon. Dispatch enters a new flight plan for DL416P. When received, the controller/system processes the new flight plan. Flight plan correlation is successful, a new session is established, and the pilot requests a clearance for DL416P via DM Continuation Flight Non-Nominal Undesired Scenarios a. Prior to P-30. Pilot does not send a new logon with DL416P (The ground system still has logon for DL416). When controller/system processes the flight at P-30, flight plan correlation would fail (AID mismatch), the controller is notified of S1P1 CPDLC DCL End2End Description Page 12

15 the error, and the clearance is delivered via voice. No further CPDLC will be available. b. After P-30, after session already started for DL416 (old). Pilot does not logon again or controller does not remove the old flight plan, or pilot relogs on prior to flight plan fixing. These cases will result in flight plan correlation failure and session termination errors. No further CPDLC will be available. If dispatch does not refile, the flight will be handled via voice Hull Swap Nominal Desired Scenarios a. Prior to P-30. Pilot is logged from Aircraft with tail number N123GQ before the tower controller processes the associated flight plan, which means there is no active session Hull swap and pilot moves to new aircraft. Pilot sends a new logon with tail number N456GQ. The ground system accept the logon and creates a new logon entry for tail number N456GQ The AOC amends the Tail Number (REG) from N123GQ to N456GQ. The amendment by the AOC has to be prior to any strip printing or the ground system rejects (baseline). Alternately, the AOC cancels the N123GQ and refiles as N456GQ. At P-30, the tower controller receives and approves the desired flight plan, with N456GQ tail number, the ground system will initiate connection establishment with the aircraft. b. After P-30, after session already started for N123GQ (old) Pilot coordinates with tower controller via voice Controller removes (RS) the old flight plan and may manually terminate the session The ground system closes the logon for N123GQ. If the controller did not manually terminate the session, the ground system will terminate it after the session timer expires (nominally 15min) Meanwhile, pilot logs on from new aircraft with tail number N456GQ Dispatch enters a new flight plan for N456GQ. When received, the tower controller/system processes the new flight plan S1P1 CPDLC DCL End2End Description Page 13

16 New flight plan is successfully correlated with the new logon from N456GQ, a session is established, and the pilot can request his clearance from the N456GQ aircraft via DM Hull Swap Non-Nominal Undesired Scenarios a. Prior to P-30. Pilot does not send a new logon with N456GQ (The ground system still has logon for N123GQ). When controller/system processes the flight at P-30, flight plan correlation would fail (REG mismatch), the controller is notified of the error, and the clearance is delivered via voice. No further CPDLC will be available. b. After P-30, after session already started for N123GQ (old) An amendment to the tail number on the flight plan will result in flight plan correlation failure and session termination error. No further CPDLC will be available. If dispatch does not refile, the flight will be handled via voice 5. DCL Pilot Downlink Request and Uplink Response 5.1. Pilot DM25 Request At the appropriate time, and after establishment of a CPDLC connection, the aircrew requests the Departure Clearance using only DM25 [REQUEST CLEARANCE]. a. The aircrew should not append free text to this DM25. If free text is concatenated with the DM25, the ground system will respond with an error, UM159, for unexpected data. b. If the aircrew uses any other message type to request the Departure Clearance, the Ground System will respond with an error message: If the downlink is a DM67, the error will be a UM159 with UM169 FREETEXT NOT SUPPORTED. c. If the downlink is any other element, the error will be a UM162 SERVICE UNAVAILABLE Initial CPDLC Clearance Uplink Response Clearance Contents The Ground system will react to crew requests for a DCL as follows: a. Upon receipt of the aircrew request the Ground System delivers the pre-approved, stored departure clearance to the aircraft using FANS- S1P1 CPDLC DCL End2End Description Page 14

17 1/A message elements UM80, UM169, UM19, and UM79, as appropriate. A sub-set of the elements may be sent in a message (see Appendix A for message samples). a. The clearance will contain either Cleared as Filed or a full or partial route, and all other relevant data elements from the flight plan or locally applied procedures. It will contain an expected cruise altitude, a departure frequency, and either a Climb Via text or a Maintain altitude. It may also contain climbout instructions, a beacon code, a SID/transition from the departure airport and/or STAR/transition at the arrival airport. b. The clearance type will be based on the following (see CPDLC Generation section above for details): When a filed route matches the en route automation processed route the ground system will uplink a CLEARED AS FILED DCL message. Note: If there is a departure procedure/sid, the terminology will be THEN AS FILED. An initial UM79 when a CAF clearance cannot be generated and the flight is eligible for a UM79. An initial UM80 when the ground system cannot create a CAF or initial UM79 clearance When the ground system cannot create a CAF, an initial UM79 or a UM80 clearance, the controller will revert to voice, using current voice procedures. c. The ground system uplinks the appropriate clearance to the aircraft as a positive response to the DM25 clearance request CPDLC Clearance Format and Constraints a. The uplink does not contain a departure runway or SID in the loadable portion (UM80 or UM79), though it will normally contain a SID and transition as appropriate in a non-loadable UM169 free text element within the clearance. Note: The SID is included in the non-loadable portion because FAA systems cannot include the departure runway in the uplink and this is required for correct loading of the SID. Although departure runway cannot be provided within the initial production system, inclusion of departure runway is an important feature for aircrew and the FAA is investigating how to provide it in future versions of the production system. b. If the [routeclearance] variable in an uplink contains an arrival procedure/transition, then the last waypoint in the [routeinformation] variable must be the same as the first fix in the arrival transition (if S1P1 CPDLC DCL End2End Description Page 15

18 specified) or the arrival procedure (if a transition is not used). If the uplink contains an arrival transition, the arrival transition name must be included in the proceduretransition field of the procedurename variable. c. The ground system will include the optional lat/long field for Published identifiers (waypoint names) in the route information variable of Departure Clearance uplinks. d. UM169 [freetext] elements will include no more than 80 characters. e. When an airway is included in the filed flight plan with published named waypoints for the entry and exit points, the entry and exit point will be designated by the published named waypoints in the routeclearance variable. f. When an airway intersects with another consecutive airway with no intersecting waypoint in the flight plan and the proposed uplink would contain a route, i.e., not CAF, the ground system will prevent an uplink from being constructed and terminate the CPDLC session with the aircraft. The controller and pilot will then need to resolve the issue via voice. g. UM79 will be used when the clearance includes a route change ending at the specified position (the TO point) which may be a point after the SID or the SID Transition (if these are present) up to and including the last en-route point prior to the first point in the first Arrival, Approach, or associated Transition in the aircraft s cleared route. h. When a UM79 is used for the initial departure clearance, the uplink will include a UM169 free text stating that the rest of the route is unchanged following the TO point in the uplink (e.g. an initial UM79 with a "TO" point of MCB will be followed by a UM169 with AFTER MCB CLEARED TO KBWI ARPT AS FILED" and then the initial altitude information (Climb Via SID or MAINT altitude) Note: The position variable in a UM169 does not allow for the same level of resolution as a lat/lon in the position variable of a UM79. Because each avionics display this UM79 position differently, the UM169 position will not always match the level of a UM79 position. A UM169 lat/lon position will be truncated (not rounded) to the minute and be sent as Direction, Hours, Minutes. Example: UM79 position displayed as N W , UM169 sent as N2120W i. For a UM79, when the TO point is an airway exit waypoint, the Ground System will include the TO point as the last element in the routeinformation field. When the TO point is not an airway exit waypoint, the ground system will omit the TO point as the last element in the routeinformation field. S1P1 CPDLC DCL End2End Description Page 16

19 j. If the arrival procedure and/or arrival transition is changed from what was filed, the initial DCL clearance will be a UM80 (this ensures loadability of the arrival), unless the flight is not eligible for a UM80, in which case it will revert to a voice clearance. k. The Ground System will not include the departure or arrival airport in UM79 routeclearance variable. l. When a UM80 contains an arrival procedure without a published arrival transition fix, the ground system will prevent an uplink from being generated and sent. Any existing session will be terminated, the controller will be notified, and the controller and pilot will coordinate via voice. Note: See Appendix D for details and additional information on future approach. 6. Pilot Response to Clearance 6.1. FMS Load and Review The aircrew loads the revised CPDLC clearance into the FMS and reviews it. If acceptable, the flight crew activates the route in the FMS, addressing any potential discons or loading issues Downlink Response Upon acceptance and loading into the FMS, the aircrew selects the appropriate downlink message. a. If acceptable, a positive response is generated, i.e., DM0 [WILCO] or DM3 [ROGER]. b. If unacceptable, or if a Partial Load or Load Failure indication occurs, the crew downlinks DM1 [UNABLE]. c. If a DISCON is present when the clearance is loaded, the aircrew may downlink a DM2 [STANDBY] response while trying to resolve. If the aircrew cannot resolve the DISCON, the aircrew downlinks DM1 [UNABLE] and reverts to voice. Note: Aircrew should not add a DUE TO clarification (DM65, DM66 or DM67) to the REJECT/UNABLE of a CPDLC clearance revert to ATC voice procedures with Clearance Delivery when a REJECT/UNABLE response is required. If the crew appends a DUE TO to a DM1 [UNABLE], the controller will receive the UNABLE portion without the DUE TO rationale Additional DM25 Requests a. If the aircrew requests a clearance again after sending the WILCO to the initial CPDLC clearance, the Ground System will provide an S1P1 CPDLC DCL End2End Description Page 17

20 indication to the controller and a proposed CPDLC departure clearance using a UM80 reflecting the full route as held in current the Ground System data. b. The controller will manually approved the CPDLC departure clearance and the Ground System will transmit to the aircraft. For some flights, such as international flights, a UM80 may not be able to be sent, in which case the system will attempt to generate a UM79 or advise the controller to revert to voice. Note: If the original DM25 request is still open, then the ground system will send an open transaction error back to the aircraft. 7. AOC/FOC Dispatch Message Generation and Response 7.1. Dispatch Message Delivery User Preference Users may opt out of receiving the Dispatch message by using the Subscriber Data Base capability Dispatch Message Delivery a. When a CPDLC clearance is uplinked to the aircraft, the ground system will provide a Dispatch message including required parts of the clearance except the beacon code to the user host system via the user-supplied 7-character IATA address, as defined in the Appendix B and in the TDLS-CSP IRD. b. In addition to clearance contents, for CLEARED AS FILED clearances or initial UM79 clearances, the dispatch message will include the full route from the ground automation processed flight plan. c. The dispatch message will include a header CPDLC DCL DISPATCH MSG NOT TO BE USED AS A CLEARANCE, and any contents sourced from the uplinked CPDLC clearance will be included as text. d. When the ground system receives a pilot response of WILCO, ROGER or UNABLE to the CPDLC uplink message, it will provide the pilot response to the AOC/FOC in a Dispatch message update, as a Pilot Response Dispatch Message, as defined in the TDLS-CSP IRD. S1P1 CPDLC DCL End2End Description Page 18

21 Dispatch Message Response Note: In this context, some CSPs may provide user host functions to their clients. a. Users shall be capable of distinguishing an initial or updated Dispatch Message from a PDC clearance. b. Upon receipt of an initial or updated Dispatch Message, the user host system shall send a system acknowledgement back to the Ground System. c. The user shall ensure that the Dispatch Message is not forwarded to the aircrew/aircraft. 8. Revised CPDLC Uplinks For aircraft participating in CPDLC departure clearances, one or more Revised Departure clearances may be sent by ATC prior to aircraft departure (see Appendix A for sample messages). For aircraft receiving PDC clearances, revisions will be handled via voice Revised Clearance Approval All CPDLC clearance revisions will be reviewed and approved by tower ATC before being transmitted to the aircrew. These include revisions generated by changes to the flight plan and revisions initiated by the controller for locally applied clearance information, e.g., frequency Revised Clearance Content/Constraints Revised clearances will contain some or all of the same information as the initial Departure Clearance. In general, formatting rules and notes listed for the initial DCL clearance also apply to DCL revisions Content a. The uplink will never contain a departure runway or SID in the loadable portion (UM79, UM80, or UM83), though it may contain a SID and transition, climbout instructions, initial altitude or Climb Via instruction, etc., as appropriate in a non-loadable UM169 free text element(s). b. No altitude or speed constraints will be included in the loadable part of the message (UM79, UM80, UM83), other than those automatically loaded from the aircraft s NAV Database with an uplinked STAR contained in the route clearance variable. Revisions may be sent as a UM80, UM83, or UM79, according to the information being revised. c. Revisions include a free text header information indicating which portions of the departure clearance have been revised, e.g., DPP or S1P1 CPDLC DCL End2End Description Page 19

22 ALT. Revised clearances may include truncated text strings when required to meet overall message length constraints, e.g., 80 characters. d. A revised CPDLC clearance may contain information that is unchanged but is repeated to reduce ambiguity, such as the initial altitude, Climb Via text, climbout, SID and transition fields. Whenever part of the departure procedure or related route portion is changed, the ground system will resend the entire departure procedure. For a revised CPDLC departure clearance with a UM79 or UM80, the ground system will include non-blank fields for the SID, transition, climbout, climb via or MAINT ALT in the revised uplink whether or not there was a change UM79 a. The UM79 route message will be used when the clearance includes a route change ending at the specified position (the TO point), which is a point after the SID or the SID Transition (if these are present) up to and including the last en-route point for which the en route automation has NAV data and has performed route processing for, prior to the first point in the first Arrival, Approach, or associated Transition in the aircraft s active route. b. When constructing a UM79, the Ground System will not include the departure airport or the destination airport in the route clearance element UM83 a. When the UM83 capability is enabled in the ground system automation, a UM83 will be used when the revision includes a route change starting at a specified position (the AT point) which is the last point in the SID or the SID Transition (if these are present) or any point after that, excluding any point within the Arrival, Approach, or associated Transitions. b. If any portion of the route is outside the FAA automation NAV database, then the flight will revert to voice. c. The Ground System will not include a departure airport in the UM83 route clearance. d. When the AT point is an airway entry point, the Ground System will include the AT point as the first element in the routeinformation field. When the AT point is not an airway entry point, the ground system shall omit the AT point as the first element in the routeinformation field. Note: Initial implementation will have UM83 disabled. S1P1 CPDLC DCL End2End Description Page 20

23 UM80 a. A UM80 will be used when the revision includes a route change and UM79 or UM83 is not appropriate according to rules above. This includes when the use of UM83 is disabled in the ground system automation. b. If a UM80 cannot be generated, the controller will revert to voice clearances. c. When a UM80 or UM83 (if applicable) contains an arrival procedure without a published arrival transition fix, the ground system will prevent an uplink from being generated and sent. Any existing session will be terminated, the controller will be notified, and the controller and pilot will coordinate via voice. Note: See Appendix D for details. d. After receiving an UNABLE, if a revised flight plan is received by the ground system, the ground system will construct a UM80 reflecting the full revised route. For international flights a UM80 may not be able to be sent, so the system will attempt to generate a UM79 or advise the controller to revert to voice Revised Dispatch Message a. When a revised CPDLC clearance is sent to the aircraft, the Ground System will provide a Revised Dispatch message including required parts of the clearance as defined in the TDLS-CSP IRD and summarized in Appendix B: Production System Dispatch Message Samples, with the exception of a beacon code, to the user host system via the user-supplied 7-character /IATA address. b. The Revised Dispatch Message will include a header CPDLC DCL DISPATCH MSG NOT TO BE USED AS A CLEARANCE and any contents sourced from the uplinked CPDLC clearance, in text format. It will also include the type of revision in the header information, e.g., RTE. c. When a revised clearance contains a route revision, the ground system will include the full route from the ground automation processed flight plan in the revised Dispatch message regardless of whether or not a full route was sent to the aircrew in the revised uplink. d. User systems should be capable of distinguishing the Revised Dispatch Message from a PDC clearance. Upon receipt of the Revised Dispatch Message the user/airline host system will send an acknowledgement back to the Ground System. The Airline Host shall ensure that the Revised Dispatch Message is not forwarded to the aircrew/aircraft. S1P1 CPDLC DCL End2End Description Page 21

24 8.4. Revised Clearance Response a. The aircrew loads the revised CPDLC clearance into the FMS and reviews it. If acceptable, the flight crew activates the route in the FMS. b. As with an initial departure clearance, the aircrew responds with the appropriate downlink message. See previous section for details. 9. CPDLC Service Termination CPDLC Service termination for an individual flight can occur based on controller, the ground system or pilot initiated termination. In addition, the entire CPDLC service may be terminated by a facility Controller Termination a. If the controller needs to cancel or modify a CPDLC message, the controller shall contact the aircraft using voice with the accepted phraseology, e.g., (flight ID) DISREGARD CPDLC MESSAGE followed by the correct clearance via voice as appropriate. b. If the controller terminates a CPDLC connection, the ground automation will uplink a UM161 end service message. Note: There is an open issue about allowing concatenation of error rationale as free text with the UM161. This is being investigated for later releases and coordination with en route CPDLC Pilot Termination If the pilot needs to terminate the CPDLC connection, the aircraft sends a disconnect request to the ground system, which terminates the connection Ground System Termination a. If the ground system terminates a CPDLC connection, either due to the nominal case when a flight departs, or due to system error conditions, the ground automation will uplink a UM161 end service message. Note: This is being investigated for later releases and coordination with en route CPDLC. b. After notification that the flight has taken off and the flight plan has become an active flight plan, the Ground System will disconnect CPDLC with the aircraft at a parameter amount of time after departure. The disconnect time will be an adjustable parameter for each facility (e.g. initially 5-10 minutes). Note: Aircrew transiting to another FANS-supporting airspace (e.g. Oakland Oceanic, New York Oceanic) will need to log-on to the next S1P1 CPDLC DCL End2End Description Page 22

25 FANS facility. No automatic transfer of the CPDLC connection will occur. c. If ATC or the user deletes the flight plan, or the flight plan times out of the FAA en route automation system, the ground system will prevent any further CPDLC message exchange and will disconnect CPDLC with the aircraft after a time parameter (same time parameter as for when a flight becomes active.) If the deletion involves multiple flight plans in the system, the CPDLC disconnect will occur on controller action Enable/Disable CPDLC Service If FAA personnel need to discontinue the entire CPDLC Service, tower personnel: a. May notify the users/ AOC(s) to commence filing flight plans in accordance with PDC procedures. The means of notification will depend upon the operational circumstances at the time; there is no additional automated notification at this point in time directly from the ground system. Current procedures and notification mechanisms are expected to be used, e.g., NOTAM or D-ATIS. b. Issue PDC clearances for DCL flights that are eligible to fallback to PDCs. If the user has filed the appropriate codes in the ICAO flight plan and/or designated the appropriate preferences in the Subscriber Database, and the clearance has not yet been processed, the ground system will generate a PDC for any initial clearance that is otherwise eligible for a PDC. If not eligible for a PDC, the ground system will provide the controller with an indication and the flight will revert to a voice clearance. c. Issue clearances by voice for those flights which specified FANS CPDLC and did not specify PDC as the fallback choice in the subscriber database or ICAO flight plan, or for which PDCs cannot be generated. S1P1 CPDLC DCL End2End Description Page 23

26 Appendix A: DCL Production System Message Samples General for Initial and Revised Clearances: Variables enclosed by () are variables received from En Route automation. Variables enclosed in [] are Controller entered or local adaptation. Text enclosed in {} is explanatory text in the requirement. Proceduredeparture and procedure transition (i.e., SIDs) are optional and may either be generated by en route automation (ERAM) as a result of the filed flight plan, or added by the controller or local adaptation. ERAM-provided values take precedence. UM169 free text is limited to 80 characters by the ground system to facilitate avionics loading. Note: In any UM169, keyword should be separated by "." or " " separators and the message should not end with a separator. These routes are examples. Adaptation changes may impact the actual SID identifiers. Revised Clearances: Header Tags. After the initial DCL has been accepted/wilco ed by the aircrew and one or more fields other than the route are amended, the Ground System will construct a Revised DCL containing a header that identifies all of the fields that have changed, using UM169 as follows: UM169 containing REVISED concatenated with: - RTE "," {if applicable when the routeclearance variable is revised} - DPP {if applicable when any of the SID, transition or climbout parameters are changed} "," - CLIMB-OUT {if applicable}, - ALT {if applicable when either Maintain altitude of Climb Via text is changed "," - EXP ALT {if applicable} "," - DPFREQ {if applicable} "," - EDCT {if applicable} "," - SQUAWK {if applicable} "," - CONTACT {if applicable}, - LCLINFO {if applicable}. The remainder of the revised DCL contains the actual revised data, using UM80, UM79, UM83, and UM169 as applicable, as follows: UM80, UM79 or UM83 {if applicable} UM169 containing - (proceduredeparture) {if applicable} " " (proceduretransition) {if applicable}, [climb-out-procedure] {if applicable} UM169 containing - MAINTAIN [altitude] or Climb Via Text, as applicable for UM79 or UM80 - EXP (requestedaltitude) [minutes-miles] { MIN or NM as determined by the adapted value of [minutes-miles]} {if applicable} " " AFT DP {if applicable}, - DPFRQ [frequency] {if applicable}, or SEE SID {if applicable} - EDCT (edcttime) {if applicable}, UM169 containing {if applicable} - SQUAWK (beaconcode) {if applicable}, - [contactinfo],{if applicable}, - [localinfo] {if applicable}. Note: UM169 messages are fixed format. Keywords should be separated by "," or when applicable, and the message S1P1 CPDLC DCL End2End Description Page 24

27 should not end with a "," or. Initial Clearance Then As Filed, with Maintain Altitude Original Route - CAF KMEM.JTEEE1.ALDAY..BSIDE.J187.FTZ.BENKY1.KORD/0119 UM Number UM169 [freetext] UM19 MAINTAIN [altitude] UM169 [freetext] UM169 [freetext] ASN1 Definition FreeText ::= IA5String (SIZE (1..256)) Altitude ::= CHOICE altitudeqnh [0] altitudeflightlevel[6] FreeText ::= IA5String (SIZE (1..256)) FreeText ::= IA5String (SIZE (1..256)) Sample Clearance CLEARED TO KORD ARPT JTEEE1.ALDAY THEN AS FILED Notes UM169 limited to 80 characters MAINTAIN 5000FT EXPECT MIN AFT DP, DPFRQ EDCT 1525 UM169 limited to 80 characters. SQUAWK 0562 UM169 limited to 80 characters. MESSAGE DESCRIPTION The Ground System will encode the CAF Initial DCL with the message elements and parameters in the following order: UM169 containing CLEARED TO concatenated with: - (airportdestination) ARPT, - (proceduredeparture), {if applicable} -. (proceduretransition) {if applicable}, - [Climb-out procedure] {if applicable}, - THEN AS FILED 1. UM19 - [altitude] UM169 - EXP (requestedaltitude) [minutes-miles] { MIN or NM as determined by the adapted value of [minutes-miles]} AFTER DEP. DEP FREQ [frequency] EDCT (edcttime) {if applicable} UM169 SQUAWK (beaconcode) {if applicable} or, [contactinfo] {if applicable}, [localinfo] {if applicable} 1 If there is no SID (proceduredeparture), the text will be AS FILED S1P1 CPDLC DCL End2End Description Page 25

28 Initial Clearance Then As Filed, with Climb Via SID Original Route - CAF KMEM.CHLDR2.ANSWA..TUL..KA39Y.. KD42U..ILC..OAL.MADN5.KOAK UM Number UM169 [freetext] UM169 [freetext] UM169 [freetext] UM169 [freetext] ASN1 Definition FreeText ::= IA5String (SIZE (1..256)) FreeText ::= IA5String (SIZE (1..256)) FreeText ::= IA5String (SIZE (1..256)) FreeText ::= IA5String (SIZE (1..256)) Sample Clearance CLEARED TO KOAK ARPT CHLDR2.ANSWA THEN AS FILED Notes UM169 limited to 80 characters. CLIMB VIA SID UM169 limited to 80 characters. EXPECT MIN AFT DP, DPFRQ SEE SID, EDCT 1525 UM169 limited to 80 characters. SQUAWK 0562 UM169 limited to 80 characters. MESSAGE DESCRIPTION The Ground System will encode the CAF Initial DCL with the message elements and parameters in the following order: UM169 containing CLEARED TO concatenated with: - (airportdestination) AIRPORT, - (proceduredeparture), {if applicable} -. (proceduretransition) {if applicable}, - [Climb-out procedure] {if applicable}, - THEN AS FILED. UM169 - [climbvia text] UM169 - EXP (requestedaltitude) [minutes-miles] { MIN or NM as determined by the adapted value of [minutes-miles]} AFTER DEP. DEP FREQ [frequency] EDCT (edcttime) {if applicable} UM169 SQUAWK (beaconcode) {if applicable} or, [contactinfo] {if applicable}, [localinfo] {if applicable} S1P1 CPDLC DCL End2End Description Page 26

29 Initial Full Route Clearance Amended Route w/loadable route KMEM.CHLDR1.ANSWA..DHART.J180.SWB.TXMEX1.KIAH/0121 UM Number UM80 [RouteClearance] UM169 [freetext] UM19 MAINTAIN [altitude] UM169 [freetext] UM169 [freetext] ASN1 Definition Sample Clearance Notes AirportDeparture[0] KMEM CLEARED ROUTE AirportDestination KIAH CLEARANCE [1] SWB.TXMEX1 ProcedureArrival [6] ANSWA DHART J180 SWB Routeinformation [8] FreeText ::= CHLDR1.ANSWA UM169 limited to 80 IA5String (SIZE characters. (1..256)) Altitude ::= 5000 MAINTAIN 5000FT CHOICE altitudeqnh [0] altitudeflightlevel[6] FreeText ::= IA5String EXPECT MIN UM169 limited to 80 (SIZE (1..256)) AFT DP, DPFRQ characters. EDCT 1525 FreeText ::= IA5String SQUAWK 0562 UM169 limited to 80 (SIZE (1..256)) characters. MESSAGE DESCRIPTION The Ground System will encode the entire Initial DCL (UM80_based) with the message elements and parameters in the following order: UM80 - (airportdeparture) (airportdestination) (procedurearrival) (routeinformation) UM169 containing the concatenation of: - [proceduredeparture], {if applicable} -. [proceduretransition] {if applicable}, - [Climb-out procedure] {if applicable}. UM19 - [altitude] or UM169 [climb via text], as applicable UM169 - EXPECT (requestedaltitude) [minutes-miles] { MIN or NM as determined by the adapted value of [minutes-miles]} AFT DP. DPFREQ {[frequency] or SEE SID }, EDCT (edcttime) {if applicable} UM169 SQUAWK (beaconcode) {if applicable}, [contactinfo] {if applicable}, [localinfo] {if applicable} S1P1 CPDLC DCL End2End Description Page 27

30 Initial Clearance Cleared TO via RTE CLR, UM79 Original Route Unknown Route Elements KJFK BETTE3.ACK J585 YQI DOTTY/M084F370 NATU RESNO/M084F390 NATU NETKI/N0487F390 DCT LIFFY UL975 WAL NUGRA EGLL Note: The flight plan to EGLL contains route elements outside the en route automation database, in this case starting with a NAT Track ID of NATU. The ground automation will determine the last known waypoint, DOTTY, and construct an initial DCL using UM79. UM Number UM79 CLEARED TO [position] VIA [routeclearance] ASN1 Definition Position ::= CHOICE ::= fixname RouteClearance ::= SEQUENCE Routeinformation [8] Sample Clearance DOTTY KJFK J585 YQI DOTTY/M084F370 Notes CLEARED TO DOTTY VIA ROUTE CLEARANCE UM169 [freetext] UM169 [freetext] UM169 [freetext] UM169 [freetext] FreeText ::= IA5String (SIZE (1..256)) FreeText ::= IA5String (SIZE (1..256)) FreeText ::= IA5String (SIZE (1..256)) FreeText ::= IA5String (SIZE (1..256)) BETTE3.ACK UM169 limited to 80 characters. AFTER DOTTY CLEARED TO UM169 limited to 80 EGLL ARPT AS FILED, characters. MAINTAIN 5000 EXPECT MIN AFT DP, DPFRQ EDCT 1525 SQUAWK 0562 UM169 limited to 80 characters. MESSAGE DESCRIPTION The Ground System will encode the Initial DCL (UM79-based) with the message elements and parameters in the following order: UM79 - (position) (routeclearance) UM169 containing - (proceduredeparture), -. (proceduretransition) {if applicable}, - [Climb-out procedure] {if applicable}, - AFTER (position) concatenated with: - CLEARED TO - (airportdestination) ARPT AS FILED UM19 - [altitude] or UM169 containing (climb via text) UM169 - EXPECT (requestedaltitude) [minutes-miles] { MIN or NM as determined by the adapted value of [minutes-miles]} AFT DP. DPFRQ {[frequency] or SEE SID }, EDCT (edcttime) {if applicable} UM169 SQUAWK (beaconcode), [contactinfo] {if applicable}, [localinfo] {if applicable} S1P1 CPDLC DCL End2End Description Page 28

31 Revised RTE UM80 KMEM.CRSON1.HUMMS..PXV..BIGXX..MZZ.ROYKO3.KORD UM Number UM169 [freetext] UM80 [RouteClearance] UM169 [freetext] UM169 [freetext] UM169 [freetext] ASN1 Definition FreeText ::= IA5String (SIZE (1..256)) AirportDeparture[0] AirportDestination [1] ProcedureArrival [6] Routeinformation [8] FreeText ::= IA5String (SIZE (1..256)) FreeText ::= IA5String (SIZE (1..256)) FreeText ::= IA5String (SIZE (1..256)) Sample Clearance REVISED RTE, DPP, ALT, DPFRQ KMEM KORD MZZ.ROYKO3 HUMMS..PXV..BIGXX..MZZ Notes Revised field identifiers are provided in the header. CLEARED ROUTE CLEARANCE CRSON1.HUMMS UM169 limited to 80 characters. CLB VIA SID EXC MAINT 5000FT UM169 limited to 80 characters. DPFRQ UM169 limited to 80 characters. MESSAGE DESCRIPTION The Ground System will prepare a UM80_based Revised DCL using a UM80 by concatenating a UM169, UM80, UM169, UM19, and UM169 (if applicable) in the following order: UM169 - REVISED RTE { DPP ALT EXP ALT DPFRQ EDCT SQUAWK CONTACT LCLINFO any other relevant tags for revised fields} UM80 - (airportdeparture) (airportdestination) (procedurearrival) (routeinformation) UM169 containing the concatenation of: - (proceduredeparture), {if applicable} -. (proceduretransition) {if applicable}, - [Climb-out procedure] {if applicable}. UM19 - [altitude] {if applicable} UM169 containing the concatenation of: - { MAINTAIN [altitude]} or (climb via text), as applicable - EXP (requestedaltitude) [minutes-miles] { MIN or NM as determined by the adapted value of [minutesmiles]} AFT DP {if applicable} ". " {if applicable}, - "DPFRQ { [frequency] or SEE SID } {if applicable} ". " {if applicable} - EDCT (edcttime) {if applicable} " " {if applicable} UM169 containing the concatenation of: - SQUAWK (beaconcode) {if applicable} [contactinfo] {if applicable}, [localinfo] {if applicable}. Note: In third UM169, keyword should be separated by "," or " " separators and the message should not end with a separator. S1P1 CPDLC DCL End2End Description Page 29

32 Revised Route UM79 Amended Route: From original CAF route above KMEM..DUCKZ1.PBUDY..ARG..BSIDE.J187.FTZ.BENKY1.KORD/0119 UM Number UM169 [freetext] UM79 CLEARED TO [position] VIA [routeclearance] ASN1 Definition FreeText ::= IA5String (SIZE (1..256)) Position ::= CHOICE ::= fixname RouteClearance ::= SEQUENCE Routeinformation [8] Sample Clearance REVISED RTE, DPP BSIDE PBUDY..ARG..BSIDE Notes CLEARED TO BSIDE VIA ROUTE CLEARANCE UM169 [freetext] FreeText ::= IA5String (SIZE (1..256)) DUCKZ1.PBUDY, AFT BSIDE REST OF RTE UNCHNGD New DP/TRAN. UM169 limited to 80 characters. UM169 [freetext] FreeText ::= IA5String (SIZE (1..256)) MAINTAIN 5000 Included but not revised. UM169 limited to 80 characters. MESSAGE DESCRIPTION The Ground System will construct a UM79_based Revised DCL using a UM79 by concatenating a UM169, UM79, UM169, UM169, and UM169 (if applicable) in the following order: UM169 - REVISED RTE { DP CLIMB-OUT ALT EXP ALT DEP FREQ EDCT SQUAWK CONTACT LOCALINFO any other relevant tags for revised fields} UM79 - (position) (routeclearance) UM169 containing the concatenation of: - DP (proceduredeparture), {if applicable}, -. (proceduretransition) {if applicable}, - [Climb-out procedure] {if applicable}, - AFTER (position) REST OF ROUTE UNCHANGED. UM169 containing the concatenation of: - MAINTAIN [altitude] {if applicable} - EXP (requestedaltitude) [minutes-miles] { MIN or NM as determined by the adapted value of [minutesmiles]} AFT DP {if applicable} ". " {if applicable}, - "DPFRQ { [frequency] or SEE SID } {if applicable} ". " {if applicable} - EDCT (edcttime) {if applicable} " " {if applicable} UM169 containing the concatenation of: - SQUAWK (beaconcode) {if applicable} [contactinfo] {if applicable}, [localinfo] {if applicable}.. Note: In third UM169, keyword should be separated by "." or " " separators and the message should not end with a separator. S1P1 CPDLC DCL End2End Description Page 30

33 Revised Route UM83 Amended Route: From original CAF route above KMEM.JTEEE1.ALDAY..BSIDE.PXV..BIGXX..MZZ.ROYKO3.KORD* UM Number UM169 [freetext] ASN1 Definition FreeText ::= IA5String (SIZE (1..256)) Sample Clearance REVISED RTE Notes UM83 AT [position] CLEARED [routeclearance] Position ::= CHOICE ::= fixname RouteClearance ::= SEQUENCE AirportDestination [1] ProcedureArrival [6] Routeinformation [8] BSIDE KORD MZZ.ROYKO3 BSIDE PXV BIGXX MZZ AT BSIDE CLEARED ROUTE CLEARANCE MESSAGE DESCRIPTION The Ground System will construct a UM83_based Revised DCL by concatenating a UM169, UM83, and UM169 (if applicable) in the following order: UM169 - REVISED RTE EXP ALT DPFRQ EDCT SQUAWK CONTACT LCLINFO any other relevant tags for revised fields} UM83 - (position) (routeclearance) UM169 containing the concatenation of: - EXPECT (requestedaltitude) [minutes-miles] { MIN or NM as determined by the adapted value of [minutes-miles]} AFT DP {if applicable} ". " {if applicable}, - "DEP FREQ [frequency] {if applicable} ". " {if applicable} - EDCT (edcttime) {if applicable} " " {if applicable} - UM169 containing the concatenation of:- SQUAWK (beaconcode) {if applicable}. [contactinfo] {if applicable}, [localinfo] {if applicable} Note: In second UM169, keyword should be separated by "." or " " separators and the message should not end with a separator. Revised Clearance Conditional Message Examples The following table is extracted from the S1P1 Production system specification, WSSD 4.0, 5/16/14, Appendix D, WSSD76. This is provided for information only, and is subject to future updates. Note : The basic rule is that whenever part of the departure procedure is changed, you resend the whole departure procedure. If a MAINTAIN altitude was included, it is also sent with the revised DP. If a climbvia was sent with the original DP, it is resent with the revised DP, even if not changed. Rule 2 is the exception to Rule 1: if only the MAINTAIN altitude is changed (SID, TRANS, CLIMBOUT unchanged), then MAINTAIN altitude can be sent alone. Note : MAINTAIN altitude is the altitude selected by the controller in the MAINT ALT selection. Note : When the controller selects a climb via text other than NONE, the MAINT ALT must be none. And vice versa. S1P1 CPDLC DCL End2End Description Page 31

34 Table A- 1 Conditional Departure Information Message Examples Condition any part of DPP changed any part of DPP changed SID changed to NONE SID changed to NONE CLIMBOUT changed to NONE CLIMBOUT changed to NONE CLIMBOUT changed CLIMBVIA changed CLIMBVIA changed to NONE MAINT alt changed to NONE and CLIMBVIA selected Climbout changed (and climbout <> NONE) MAINT alt changed MAINT alt not changed but part of DPP changed SID, climbout, climbvia SID<>NONE Climbviatxt <> NONE Climbviatext = NONE Climbout <> NONE Climbvia = NONE CLIMBOUT=N ONECLIMBVIA = NONE SID<>NONECli mbviatext <> NONE Climbviatext = NONE MAINT [alt]* UPLINK none UM169 (procdep) "." (trans) " " (climbout), (climbviatext)note: (trans) and (climbout) only if not NONE, but are included even if not changednote: 1 st UM169 should include REVISED DPP (and ALT if [climbviatextt] is changed) yes UM169 (procdep) "." (trans) " " (climbout), MAINTAIN (alt)note: (trans) and (climbout) only if not NONE, but are included even if not changednote: 1 st UM169 should include REVISED DPP (and ALT if [climbviatextt] is changed) yes yes none yes UM169 "SID NONE, " (climbout)um19 [alt]note: include (climbout) if <> NONE, even if same Note: 1 st UM169 should include REVISED DPP (and ALT if [alt] is changed) UM169 "DPP NONE"UM19 [alt]note: 1 st UM169 should include REVISED DPP (and ALT if [alt] is changed) UM169 (procdep) "." (trans) ", (climbviatext)note: (trans) included only if not NONE, but included even if not changednote: 1 st UM169 should include REVISED DPP UM169 (procdep) "." (trans)um19 [alt]note: (trans) included only if not NONE, but included even if not changed. ProcDep included if applicablenote: 1 st UM169 should include REVISED DPP SID stays NONE yes UM169 (climbout)um19 [alt]note: 1 st UM169 should include REVISED DPP SID<>NONE none UM169 (procdep) "." (trans) " " (climbout), (climbviatext)note: (trans) and (climbout) only if not NONE, but are included even if not changed Note: 1 st UM169 should include REVISED DPP SID<> NONE and SID unchanged SID, CLIMBOUT, CLIMBVIA unchanged SID or CLIMBOUT<>N ONE yes UM169 (procdep) "." (trans) " " (climbout)um19 [alt] Note: (trans) and (climbout) only if not NONE, but are included even if not changed. ProcDep as applicablenote: 1 st UM169 should include REVISED ALT none UM169 (procdep) "." (trans) " " (climbout) as appl, ", (climbviatext)note: 1 st UM169 should include REVISED ALT yes yes yes UM169 (procdep) "." (trans) " " (climbout)um19 [altitude]note: 1 st UM169 should include REVISED DPP (and ALT if [alt] changed) UM19 [alt]note: 1 st UM169 should include REVISED ALT UM169 (procdep) "." (trans) " " (climbout)um19 [altitude]note: 1 st UM169 should include REVISED DPP S1P1 CPDLC DCL End2End Description Page 32

35 S1P1 CPDLC DCL End2End Description Page 33

36 Appendix B: Production System Dispatch Message Samples These examples are included as limited samples. See the TDLS-CSP IRD (U. S. Department of Transportation, Federal Aviation Administration, Interface Requirements Document, Tower Data Link Services (TDLS) to Communications Service Provider (CSP), Draft, December 15, 2014, for more examples and details.. This ICD is available from the Data Comm Program as a coordination document with DCIT> Initial Dispatch Message When an initial DCL clearance is sent to the aircrew, the Ground System sends an FAA to User/Airline ground-to-ground text message to the user/airline host computer system containing the information in the uplinked clearance. This Dispatch Message/Courtesy Copy is sent over the existing interface used for PDCs. In cases when the full route of flight is not sent to the aircraft, i.e., for CAF and initial UM79 clearances, the full route of flight is included in Dispatch message. Table B- 1 Initial Dispatch/DCC Message Format for a Cleared as Filed, THEN as Filed Message Format for this Field Explanation Example example <SOH>QU {IATA address Address of airline host QU ANPOCWN TO }.{IATA address FROM} Automation System address and day/time.okctwxa {DDHHMM} of message <STX>CCI SMI CCI { Sequence Number} CPDLC DCL DISPATCH MSG NOT Sequence number and notification 003 CPDLC DCL DISPATCH MSG NOT TO BE USED AS A CLEARANCE TO BE USED AS A CLEARANCE {Flight ID} Flight ID and departure airport FDX9901 KMEM {AirportDeparture} {Equipment} P{Departure Equipment and departure time D/A320/Q P1558 time} {Computer Identifier} Computer code and expected altitude 555 FL300 FL{Expect Level [level]} CLEARED TO {Airport Destination} AIRPORT Route Information (including Airport Destination, departure procedure, and CLEARED TO KOAK AIRPORT CHLDR2.ANSWA {SID}.{TRANSITION FIX} departure transition fix) {Route Information} Route Information THEN AS FILED {climbviatext} Initial Altitude CLIMB VIA SID CLIMB VIA SID, or CLIMB VIA SID EXCEPT Maintain (Altitude) (this text matches exactly what is in the uplink) MAINT (Altitude) would be included if there is no {climbviatext} DEP FREQ {freq} Departure Frequency DEP FREQ {contactinfo}, {local info} Local information CTC GROUND CONTROL 121.9, ADV ON INIT CTC YOU HAVE ATIS {Free Text} Full Route String (indicates the full cleared route of flight) KMEM.CHLDR2.ANSWA..TUL..KA39Y.. KD42U..ILC..OAL.MADN5.KOAK <ETX> <ETX> End of Transmission The following is a representative sample of the text message of the above: 003 CPDLC DCL DISPATCH MSG - NOT TO BE USED AS ACLEARANCE FDX9901 KMEM D/A320/Q P FL300 CLEARED TO KOAK AIRPORT S1P1 CPDLC DCL End2End Description Page 34

37 CHLDR2.ANSWA THEN AS FILED CLIMB VIA SID DEP FREQ CTC GROUND CONTROL 121.9, ADV ON INIT CTC YOU HAVE ATIS KMEM.CHLDR2.ANSWA..TUL..KA39Y.. KD42U..ILC..OAL.MADN5.KOAK Revised Dispatch Message When a revised DCL clearance is sent to the aircrew, the Ground System sends a revised Dispatch message to the user/airline host computer system containing the information in the uplinked clearance as well as several mandatory header fields. Note: The first 7 fields through Computer ID and Expect level/altitude are mandatory in the Revised Dispatch message, regardless of whether or not the contents of the field actually changed. This was designed to minimize software impact to users by reusing as much of the PDC formatting as possible. After the first 7 fields, only those fields that are revised, or are required to be included in the uplink, will be included. However, as with an initial Dispatch message, in cases when the full route of flight is not sent to the aircraft, i.e., when only a partial route is sent in a UM79 or UM83 clearance, the full route of flight is included in revised Dispatch message. The full route is not included in non-route revisions, e.g., when only the EDCT or frequency is changed. Table B-2. Revised DCC Message Format for a UM79 Revised Clearance Message Format for this example Field Explanation Example <SOH>QU {IATA address TO } Address of airline host QU ANPOCWN.{IATA address FROM} Automation System address.okctwxa {DDHHMM} and day/time of message <STX>CCR SMI CCR { Sequence Number CPDLC DCL DISPATCH MSG NOT TO BE Sequence number and notification 005 CPDLC DCL DISPATCH MSG NOT TO BE USED AS A CLEARANCE USED AS A CLEARANCE {Flight ID} {AirportDeparture} Flight ID, departure airport FDX9901 KMEM REVISED RTE DPP REVISED <RTE DPP> and revision marking {Equipment} P{Departure time} Equipment and departure time D/A320/Q P1610 {Computer Identifier} Computer code and expected 555 FL300 FL{Expected Level} REVISED RTE CLEARED TO {position} VIA {route information} REVISED DPP {SID}.{TRANSITION FIX}, AFTER {position} REST OF ROUTE UNCHANGED CLIMB VIA SID EXCEPT MAINT {initial altitude}ft{route Information} {Free Text} altitude Revised Route Information Revised Departure Procedure Information Initial Altitude Free Text Additional Maintain Altitude Full Route String (indicates the full cleared route of flight) REVISED RTE CLEARED TO GCK VIA EOS ICT REVISED DPP ZUMIT.FOXOM, AFTER GCK REST OF ROUTE UNCHANGED CLIMB VIA SID EXCEPT MAINT 5000FT KMEM.ZUMIT.FOXOM..EOS..ICT..GCK.. KD48W..HVE..ILC..OAL.MADN5.KOAK <ETX> <ETX> End of Transmission The following are representative samples of the text message of the above: a) Route Revision 005 CPDLC DCL DISPATCH MSG NOT TO BE USED AS A CLEARANCE FDX9901 KMEM REVISED RTE DP D/A320/Q P FL300 REVISED RTE CLEARED TO GCK VIA EOS ICT REVISED DPP ZUMIT.FOXOM, AFTER GCK REST OF ROUTE UNCHANGED CLIMB VIA SID EXCEPT MAINT 5000FT KMEM.ZUMIT.FOXOM..EOS..ICT..GCK.. KD48W..HVE..ILC..OAL.MADN5.KOAK S1P1 CPDLC DCL End2End Description Page 35

38 b) Non-Route Revision. Note that expected altitude is included as one of the mandatory first 7 fields, but does not have any revision tag. 005 CPDLC DCL DISPATCH MSG NOT TO BE USED AS A CLEARANCE SWA999 KMEM REVISED EDCT DEPFREQ CONTACT H/B744/Q P D FL320 REVISED EDCT 1630 REVISED DEPFREQ REVISED CONTACT Ctc Clearance Delivery now Dispatch Message Acknowledgement (ACK) When the AOC automation receives a Dispatch Message from the Ground System, it returns a response indicating successful receipt. There are no required fields other than those that identify the message and the flight. However, the decision was made to minimize software impact to the AOC automation systems by retaining two fields, the Departure Time and Gate Assignment, in this response message format. The goal is to allow users to respond to the Dispatch Message by leveraging the existing PDC format as much as possible. The Ground System will ignore any data in these two fields. Table B- 3 DCC ACK Message Body Example Message Format for this example Field Explanation Example <SOH>QU {IATA address TO } Receiving Automation <SOH>QU BNATWXA System address (e.g., TDLS automation).{iata address FROM} {DDHHMM} Sending Automation. ANPOCWN System address (e.g. AOC) and day/time of message <STX>CCA SMI (message type <STX>CCA identifier) CCA {Flight ID } {Sequence Number} {Aircraft Reg Flight ID (characters and SWA N34522 P2145 #/Tail Number}{ Departure Time 2 } {Gate Assignment 3 } numerals), Sequence Number that matches sequence number of DCC message for which this is a response, optional Aircraft Registration Number/Tail Number, Departure Time in hours and minutes, <ETX> End of Transmission <ETX> When the ground system receives a response from the aircrew to the initial or revised CPDLC departure clearance, it generates a Dispatch Message and transmits to the AOC/FOC. This Dispatch message, designated as a Pilot Response message, contains the pilot response but also contains the original Dispatch message contents to which this message is a response. The AOC/FOC automation responds with a system acknowledgement, as defined in the TDLS-CSP IRD. 2 Ignored by Production system but not rejected if in message. (This is to minimize software impact on users by retaining some fields from current PDC.) 3 Ignored by Production system but not rejected if in message. (This is to minimize software impact on users by retaining some fields from current PDC.) S1P1 CPDLC DCL End2End Description Page 36

39 Table B-3 provides an example of a DCC Pilot Response message, which would be a response to an initial CPDLC clearance. Table B-4. CCP Message Body Example Message Format for this Example Field Explanation Example <SOH>QU {IATA address TO } Receiving Automation System QU ANPOCWN address (e.g., TDLS automation).{iata address FROM} Sending Automation System.BNATWXA {DDHHMM} address (e.g. AOC) and day/time of message <STX>CCP SMI (message type identifier) CCP {Sequence Number} Clearance Sequence Number 001 {Flight ID} {Airport Departure} Flight ID and departure airport FDX9901 KMEM PILOT RESPONSE {Response} The response sent by the pilot to the clearance identified by PILOT RESPONSE - WILCO {Sequence Number} CPDLC DCL DISPATCH MSG NOT TO BE USED AS A CLEARANCE the following fields Sequence number and notification {Flight ID} {Airport Departure} Flight ID and departure airport FDX9901 KMEM {Equipment} P{Departure time} Equipment and departure time D/A320/Q P CPDLC DCL DISPATCH MSG NOT TO BE USED AS A CLEARANCE {Computer Identifier} FL{Expected Level} Computer code and requested altitude 555 FL300 CLEARED TO {Airport Destination} AIRPORT {SID}.{TRANSITION FIX} Route Information (including Airport Destination, departure procedure, and departure transition fix) CLEARED TO KOAK AIRPORT CHLDR2.ANSWA {Route Information} Route Information THEN AS FILED {climbviatext} Initial Altitude CLIMB VIA SID DEP FREQ {freq} Departure Frequency DEP FREQ {contactinfo}, {local info} Local information CTC GROUND CONTROL 121.9, ADV ON INIT CTC YOU HAVE ATIS {Free Text} <ETX> Full Route String (indicates the full cleared route of flight) End of Transmission KMEM.CHLDR2.ANSWA..TUL..KA39Y.. KD42U..ILC..OAL.MADN5.KOAK S1P1 CPDLC DCL End2End Description Page 37

40 Appendix C: S1P1 Gate Request Message Samples When a CPDLC departure clearance is approved by the controller or the Ground System, the Ground System sends an FAA to User/AOC ground-to-ground text message to the user/airline host computer system requesting the departure gate for the specified flight. This Gate Request message is sent over the existing interface used for PDCs, but only for CPDLC-designated flights. The user/airline responds with the gate identifier or an unknown tag. This data exchange represents the same functionality as currently provided by the user/aoc response to a PDC. It is a one-time exchange for the initial Production implementation; no revisions are expected. The following are examples of the Gate Request (GREQ) Message and User/Airline reply. Table C- 1 GREQ Message Body Example Message Format for this example Field Explanation Example <SOH>QU {IATA address TO } Receiving Automation System <SOH>QU ANPOCWN address (e.g., AOC automation). {IATA address FROM} {DDHHMM} Sending Automation System.BNATWXA address (e.g. TDLS at BNA) and day/time of message <STX>GRM SMI (message type identifier) <STX>GRM GRM for Gate Request { Sequence Number} Sequence number 89 {Flight ID } {Aircraft Reg #/Tail Flight ID (characters and SWA2331 N34522 KBNA Number}{Departure Airport } numerals), optional tail number and departure airport <ETX> End of Transmission <ETX> Table C- 2 GREQ Reply Message Body Example Message Format for this example Field Explanation Example <SOH>QU {IATA address TO } Receiving Automation System <SOH>QU BNATWXA address (e.g., TDLS automation).{iata address FROM} {DDHHMM} Sending Automation System. ANPOCWN address (e.g. AOC) and day/time of message <STX>GIR SMI(message type identifier) Gate <STX>GIR ID Response { Sequence Number} Sequence number that matches 89 sequence number of GREQ message for which this is a response {Flight ID } {Aircraft Reg #/Tail Number}{Departure Airport } {Gate Flight ID (characters and numerals), optional tail number and departure SWA2331 N34522 KBNA B3 Assignment} airport, gate assignment of Gxxx or G if unknown <ETX> End of Transmission <ETX> S1P1 CPDLC DCL End2End Description Page 38

41 Appendix D: ICAO FPL DCL Delivery Codes The ICAO 2012 Flight Plan is now operational in the NAS and is required for CPDLC service. The proposed Data Comm codes in Field 18/DAT are an optional mechanism for the user to notify FAA automation to generate a CPDLC or PDC clearance. The codes were created to differentiate FANS 1/A and FANS 1/A+ support. At this time, there are no differences in the ground system support for either mode. ICAO FP codes take precedence over any other user preference mechanism, e.g., SDB Field 10a allows any order and is world-wide; Z is required in order to get to DAT/ field No spaces should be included in the actual DAT/ field; they are shown in the table for clarity only. Proposed codes include an optional Fallback Hierarchy if CPDLC service is not available Data Comm Trials system uses FRC DCL in Field 18/RMK field of current and ICAO Flight Plan. Users will need to remove this from filing in order to be eligible for Cleared as Filed initial CPDLC clearances. Data Comm S1P1 Production system (IOC 2016) will use ICAO 2012 FPL. Field 10a (Equipage) used to identify aircraft capabilities Field 18 (Other Information) DAT/Codes used to identify flights getting CPDLC or PDC Need to fill in Field 10a in order to get to Field 18 DAT/ Field 18 DAT/ Codes will include a primary/secondary hierarchy xxx designates preferred departure clearance delivery mechanism xxx designates back up delivery mechanism ICAO FPL preferences take priority over any other sources Table D - 1 ICAO FPL Field 10a and Field 18 DAT/ Codes # User Preference Data Comm Capability Description for S1P1 (2016) ICAO 2012 Fld 10a Data Comm Fld 18 DAT/ 4 Comments These apply to FANS in US domestic airspace only. 1a Voice only* Not equipped for ACARS or FANS; gets voice only Default if user is not getting PDC or FANS. Field 10a may be optional. 1b Voice only* Equipped for ACARS and FANS but wants voice only E3J4J7 Z 1VOICE Optional. Only needed if users want to negate default PDC/CPDLC-DCL value and use voice only. 2a PDC only* Not ACARS equipped but gets PDC via manual means Z 1PDC Some aircraft are non-acars equipped, and 10a is physical equipage. Still get PDC via other means, e.g., gate printer. 4 No spaces in actual DAT/ codes S1P1 CPDLC DCL End2End Description Page 39

42 # User Preference Data Comm Capability Description for S1P1 (2016) ICAO 2012 Fld 10a Data Comm Fld 18 DAT/ 4 Comments These apply to FANS in US domestic airspace only. 2b PDC only* Equipped only for ACARS PDC E3 Z 1PDC 2c PDC only* Equipped for ACARS PDC and FANS but wants PDC only E3J4Jx Z 1PDC Equipped for ACARS PDC and FANS 1/A or 1/A+, and possibly other capabilities (Jx). Identifies US domestic preference for PDC. 3a FANS 1/A only Equipped for ACARS/PDC and FANS but wants FANS 1/A only for CPDLC-DCL E3J4Jx Z 1FANS Identifies FANS 1/A CPDLC for US domestic airspace. 3b FANS 1/A+ only Equipped for ACARS/PDC and FANS but wants FANS 1/A+ only for CPDLC-DCL E3J4Jx Z 1FANSP Identifies FANS 1/A+ CPDLC for US domestic airspace 4a FANS 1/A/PDC Equipped for ACARS PDC and FANS 1/A, with primary/secondary CPDLC- DCL fallback preferences E3J4Jx Z 1FANS2PDC Code shows PDC/CPDLC-DCL fallback priority preference, e.g., FANS 1/A is primary preference; PDC is secondary for the tower that will be used if FANS CPDLC-DCL primary is unavailable and PDC is feasible. 4b FANS 1/A+ /PDC Equipped for ACARS PDC and FANS 1/A+, with primary/secondary CPDLC- DCL fallback preferences E3J4Jx Z 1FANSP 2PDC Code shows PDC/CPDLC-DCL fallback priority preference, e.g., FANS 1/A+ DCL is primary preference; PDC is secondary for the tower that will be used if FANS CPDLC-DCL primary is unavailable and PDC is feasible. * No ICAO FP change required if user currently gets PDC and does not want DCL. Current PDC designation will be the default. S1P1 CPDLC DCL End2End Description Page 40

43 Appendix E: Selected S1P1 Production System Future Capabilities The following table represents future capabilities associated with the S1P1 Production system that have been discussed by the DCIT and/or the S1P1 program. Many are also noted in the text of this E2E document. Some of these areas are currently being worked and may have an initial capability designed for the IOC release and a future capability that is planned for later releases, e.g., during the waterfall roll-out of the S1P1 system starting in January Others have been identified but are not yet being actively investigated. This table is a work in progress, and is not intended to be inclusive of all future capabilities its focus is those that appear to be of specific concern to the DCIT. Proposed resolutions, planned releases, and the S1P1 System Specification (SSD) and/or Data Comm Engineering Request (ER) tracking numbers are provided when available. The S1P1 systems planned release column is based on assumed annual or semi-annual releases after IOC. However, those releases requiring changes across more than one system may be adjusted accordingly. This is DRAFT only. Table E- 1 **Example** Selected S1P1 System Future Capabilities or Revisions are TBD # Function/Topic Description Comments Proposed Resolution Planned Release 1 Arrival Transition Fix Processing Arrival procedure intersections not at published transitions. Includes first fix on common base leg. Involves adaptation, software, and possible redefinition of charts. May also need to handle any local AARs that involve arrival/transitions. 1. Initial: Ground will prevent any uplink that has no arrival transition 2. Waterfall: will accept no transitions that are first fix on common base leg. Mid-stream joins still prohibited. 3. Future: Possible solution for mid-stream joins 1. IOC 2. Waterfall 3. TBD Spec/DCP ER # 1. ER1341, 2. ER1337, 1315 Prt y H S1P1 CPDLC DCL End2End Description Page 41

44 Appendix F: Subscriber Data Base Users Guide Summary The following is an extract from the User s Guide For Tower Data Link Service (TDLS) Subscriber Database (SDB) Web-based Application, draft, Nov This is a work in progress. SECTION 1 INTRODUCTION This User s Guide describes how to use the Tower Data Link Service (TDLS) Subscriber Database (SDB) Web-based application. The TDLS SDB Web-based Application, accessed via the Internet using a standard Web Browser, is a user portal intended solely for the purpose of maintaining a centralized database of TDLS subscriber data. The Subscriber Database contains data records identifying airline flights (subscribers) and the clearance services subscription information for those flights. Currently TDLS offers three services: Pre-departure Clearance (PDC), Future Air Navigation Service (FANS) Clearance, and Voice. Users are given access to the TDLS SDB Web-based Application according to their association with a Communications Service Provider (CSP) or an Airline Operations Center (AOC) organization that exchanges departure clearance (DCL) Dispatch Message (DCC), Pre-Departure Clearance (PDC), and/or Ground Location Request (GREQ) messages with the TDLS systems. Individual users will only have access to their own Organization s records via the SDB Web Application. In some cases, an AOC user will be given restricted access to subscriber data. Figure 1 shows a high-level conceptual view of the connection between the External User s Web Browser and the TDLS SDB Web Server. Internet External User s Web Browser Legend HTTPS Interface NAS Public DMZ SDB Web Server Figure 1 - Conceptual View, External User to SDB Web Server Users gain access to the TDLS SDB Web-based Application by using either of the two URLs provided below. URL 1: URL 2: S1P1 CPDLC DCL End2End Description Page 42

45 1.1 ESTABLISHING THE CONNECTION TO THE SDB WEB SERVER The TDLS SDB Web Application is managed and maintained by the FAA s Inter-Facility Communications Engineering Team (IFCET). User access is coordinated between the User and IFCET as directed below: STEP 1: hours User calls IFCET Help Desk at (405) during normal business (M-F, 6:00 am to 6:00 pm CST). STEP 2: IFCET determines if the user is to have full or restricted access. Once user access is approved, IFCET provides the user with a unique username and a temporary password. STEP 3: IFCET sends the user (via ) the X509v3 certificate required for establishing the connection. STEP 4: Once the user receives the X509v3 client certificate and enters one of the SDB Web Server URLs, the user will be connected to the TDLS SDB Logon Page. STEP 5: The user is required to change their temporary password immediately after initial login. (Passwords must be at least eight characters long and must contain one lowercase letter, one uppercase letter, one number and one special character.) STEP 6: After five unsuccessful attempts to login, the user s account will be locked out for one hour, at which time the user can attempt to log in again. If the user attempts to log in before the lockout period has ended, an appropriate error message will be displayed. 1.2 HELP-DESK SUPPORT IFCET provides Help-Desk support for handling technical questions related to user accounts, passwords, and access rules, and for handling technical issues related to URL access to the SDB Web Servers. In addition to the above extract, the SDB Guide contains detailed information and examples for: a. Maintenance (logon, passwords, initiating, terminating, etc) b. Subscriber Menus c. Subscriber Search capabilities d. Subscriber Update capabilities. Subscriber Update menus and priorities are extracted below. Note that there are slightly different menus for restricted and non-restricted users. In addition, for the initial implementation, a Pilot Response Dispatch Message will automatically be sent to all users who receive Dispatch (DCC) messages, i.e., there is no separate selection for receiving pilot response messages. S1P1 CPDLC DCL End2End Description Page 43

46 1 4 2 Item Feature 1 2 Subscriber Information Service Information Figure 12 - Subscriber Update Page Function Lists Airline, Flight/Tail Number and Airport Code for the selected subscriber. Service: Choices are PDC", "FANS", VOICE and NONE. (In the future, other service types may be available.) Indentifies service s clearance type for the flight (dependent upon availability). For example: If the first priority service s clearance type is set to "FANS" and the airport has FANS capability, then a FANS clearance will be transmitted to the aircraft. However, if the airport does not have FANS capability or if Controller-Pilot Data Link Communications (CPDLC) service is down or has been turned off, then the second priority service s clearance type will be used. The first priority service must be selected as FANS or PDC; the second and third are optional. If a secondary or tertiary service is unavailable, VOICE service will be assumed. IATA: If populated, contains an IATA address specifying where PDC, DCL Dispatch Message, and GREQ will be sent. Field can be left blank if PDC is not an option for the clearance type AND no Dispatch Message or GREQ is to be sent for a FANS clearance. DCC: Identifies DCL Dispatch Message type. Acceptable values from a drop-down box are listed below: 1) INIT Copy of initial DCL only 2) INIT_REV Copy of initial DCL and revisions 3) REV Copy of revisions only (no initial clearances) 4) NONE No DCL Dispatch Messages will be sent for this flight. Surf. Loc.: Indicates that a surface location request S1P1 CPDLC DCL End2End Description Page 44 3

47 3 4 Save Cancel Navigation Path message (GREQ) is to be sent to the specified Dest. Org. Start: Specifies the date when the service addition takes effect. If field is left blank, service addition occurs when the Save button is selected. The input format for this field is MM/DD/YYYY, where MM = the 2-digit month, DD = a 2-digit day, and YYYY = the four-digit year. End: Specifies the date when the service is no longer valid. Format rules for the Start Date apply to this field. Delete: If box is checked, the corresponding service will be deleted. Select Save to add/update the subscriber information in the database. Select Cancel to return to the Subscribers Menu page. Click on Subscribers to return to Subscribers Menu page. Click on SDB Home to return to SDB Home page. (Browser <Back> button may also be used.) Table 12 - Subscriber Update Page Features A restricted-access user is presented with the Change Priorities page, shown in Figure 13, in lieu of the Subscriber Update page, after selecting an existing subscriber from the results table on the Subscriber Search Results page. The Change Priorities page allows the restricted-access user to change service priorities for an existing subscriber Item Feature 1 Subscriber Information Figure 13 - Change Priorities Page Function Lists Airline, Flight/Tail Number and Airport Code for the selected subscriber. S1P1 CPDLC DCL End2End Description Page 45

48 2 3 4 Services Information Save Cancel Navigation Path Lists Services information for the selected subscriber. Priority is only editable field. Select Save to update the subscriber information in the database. Select Cancel to return to the Subscribers Menu page. Click on Subscribers to return to Subscribers Menu page. Click on SDB Home to return to SDB Home page. (Browser <Back> button may also be used.) Table 13 - Change Priorities Page Features S1P1 CPDLC DCL End2End Description Page 46

49 1 4 2 e. Item Feature Subscriber Information Services Information Save Cancel Navigation Path f. Figure 13 - Change Priorities Page Function Lists Airline, Flight/Tail Number and Airport Code for the selected subscriber. Lists Services information for the selected subscriber. Priority is only editable field. Select Save to update the subscriber information in the database. Select Cancel to return to the Subscribers Menu page. Click on Subscribers to return to Subscribers Menu page. Click on SDB Home to return to SDB Home page. (Browser <Back> button may also be used.) g. Table 13 - Change Priorities Page Features 3 S1P1 CPDLC DCL End2End Description Page 47