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 042315
Page iii
Table of Contents
1. Overview .................................................................................................................................. 1
2. User Preferences and Flight Plan Filing ............................................................................... 1
3. Initial CPDLC Clearance Generation ................................................................................... 6
4. Logon and Connection Establishment ................................................................................ 10
5. DCL Pilot Downlink Request and Uplink Response ......................................................... 14
6. Pilot Response to Clearance ................................................................................................. 17
7. AOC/FOC Dispatch Message Generation and Response .................................................. 18
8. Revised CPDLC Uplinks ...................................................................................................... 19
9. CPDLC Service Termination ............................................................................................... 22
Appendix A: DCL Production System Message Samples ....................................................... 24
Appendix B: Production System Dispatch Message Samples ................................................ 34
Appendix C: S1P1 Gate Request Message Samples ............................................................... 38
Appendix D: ICAO FPL DCL Delivery Codes ....................................................................... 39
Appendix E: Selected S1P1 Production System Future Capabilities .................................... 41
Appendix F: Subscriber Data Base Users Guide Summary .............................................. 42
S1P1 CPDLC DCL End2End Description 042315
Page iv
DCIT End-to-End Procedures for CPDLC Departure
Clearance Operational/Production System
(Segment 1 Phase 1)
Draft, V1.2, 22 April 2015
1. 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 WebAccess 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.
2.1.1. 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 042315
Page 1
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.
2.1.2. 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).
2.2.
Flight Plan Filing
2.2.1. 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 2.2.6.2.a).
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.
c.
2.2.2. 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 042315
Page 2
2.2.3. 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., 45-60 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.
2.2.4. 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.
i.
General Rules.
Use of an airway as a route element requires a published entry and
exit point for the airway, (e.g. ..SJN.J108.GINGR..),
ii.
An implied airway/airway junction (i.e. no fix between airways) is NOT
loadable,(e.g. .J4..J65.).
iii.
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.
iv.
A navaid radial is NOT a loadable route element in a DataComm
clearance, e.g. .AIR111. or .ABQ092R.).
S1P1 CPDLC DCL End2End Description 042315
Page 3
v.
An FRD may be used in place of a navaid radial, or unnamed airway
junction, (e.g. ..TCH..TCH094074..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.
b.
i.
ii.
c.
i.
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.
Departure Phase (ADR/PDR, ADAR/PDAR, CDR, IFR Preferential
Route, Playbook Routes, etc.)
The first route element after departure must NOT be an airway, (e.g.
KPHX.J65..).
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.).
Arrival Phase (AAR/PAR, ADAR/PDAR, APR, CDR, IFR Preferential
Route, Playbook Routes, etc.)
The last route element prior to destination must NOT be an airway,
(e.g. ..J78.KAMA).
ii.
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).
iii.
Arrival procedures, i.e., STARs, should be filed with a published
arrival transition.
d.
i.
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.
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.
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.
iii.
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 042315
Page 4
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.
iv.
e.
For both initial and revised clearances, if a UM79 or UM80 is not
possible, then the controller will revert to a voice clearance.
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.
“XXX” indicating an incomplete route. This will prevent a CPDLC or
PDC departure clearance from being generated.
iii.
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 042315
Page 5
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.
3.1.
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.
3.1.1.
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
3.1.2. 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 042315
Page 6
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.
3.1.3. 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 042315
Page 7

e.
UM79 Clearance: CLEARED TO TCH VIA HOLTR,
LEETZ3.HOLTR, AFTER TCH CLEARED TO KBWI ARPT AS
FILED, CLIMB VIA SID
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 UM79.
3.1.4. 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.
3.1.5. 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 042315
Page 8
3.2.
Initial CPDLC Clearance Contents
3.2.1. 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.
3.2.2. 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.
3.3.
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 042315
Page 9
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
4.1.1. 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.
4.1.2. 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 042315
Page 10
4.2.
Connection Establishment
4.2.1. 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.
4.2.2. 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 042315
Page 11
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.
4.3.1. 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 DM25.
4.3.2. 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 042315
Page 12
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.
4.3.3. 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 042315
Page 13

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 DM25
4.3.4. 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.
5.2.
Initial CPDLC Clearance Uplink Response
5.2.1. 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 042315
Page 14
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):
c.

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.
The ground system uplinks the appropriate clearance to the aircraft as
a positive response to the DM25 clearance request
5.2.2. 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 042315
Page 15
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 N21 20 22.1 W157 55 44.8 , UM169 sent as
N2120W15755 .
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 042315
Page 16
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.
6.2.
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.
6.3.
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 042315
Page 17
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
7.1.1. User Preference
Users may opt out of receiving the Dispatch message by using the Subscriber
Data Base capability.
7.1.2. 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.
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.
d.
S1P1 CPDLC DCL End2End Description 042315
Page 18
7.1.3. 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.
8.1.
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.
8.2.
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.
8.2.1. 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 042315
Page 19
“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.
8.2.2. 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.
8.2.3. UM83
a.
b.
c.
d.
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.
If any portion of the route is outside the FAA automation NAV
database, then the flight will revert to voice.
The Ground System will not include a departure airport in the UM83
route clearance.
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 042315
Page 20
8.2.4. 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.
8.3.
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 042315
Page 21
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.
9.1.
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.
9.2.
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.
9.3.
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 042315
Page 22
FANS facility. No automatic transfer of the CPDLC connection will
occur.
c.
9.4.
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 042315
Page 23
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 042315
Page 24
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]
ASN1
Definition
FreeText ::= IA5String
(SIZE (1..256))
UM19
MAINTAIN
[altitude]
UM169
[freetext]
Altitude ::= CHOICE
altitudeqnh [0]
altitudeflightlevel[6]
FreeText ::= IA5String
(SIZE (1..256))
UM169
[freetext]
FreeText ::= IA5String
(SIZE (1..256))
Sample Clearance
Notes
CLEARED TO KORD ARPT
JTEEE1.ALDAY THEN AS
FILED
5000
UM169 limited to 80
characters.
EXPECT390 10 MIN
AFT DP, DPFRQ 124.65
EDCT 1525
SQUAWK 0562
UM169 limited to 80
characters.
MAINTAIN 5000FT
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 FILED1”.
• 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 042315
Page 25
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]
ASN1
Definition
FreeText ::= IA5String
(SIZE (1..256))
UM169
[freetext]
FreeText ::= IA5String
(SIZE (1..256))
UM169
[freetext]
FreeText ::= IA5String
(SIZE (1..256))
UM169
[freetext]
FreeText ::= IA5String
(SIZE (1..256))
Sample Clearance
Notes
CLEARED TO KOAK ARPT
CHLDR2.ANSWA THEN AS
FILED
CLIMB VIA SID
UM169 limited to 80
characters.
EXPECT 390 10 MIN
AFT DP, DPFRQ SEE SID,
EDCT 1525
SQUAWK 0562
UM169 limited to 80
characters.
UM169 limited to 80
characters.
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 042315
Page 26
Initial Full Route Clearance
Amended Route w/loadable route
KMEM.CHLDR1.ANSWA..DHART.J180.SWB.TXMEX1.KIAH/0121
UM
Number
UM80
[RouteClearance]
UM169
[freetext]
ASN1
Definition
AirportDeparture[0]
AirportDestination
[1]
ProcedureArrival [6]
Routeinformation [8]
FreeText ::=
IA5String (SIZE
(1..256))
Altitude ::=
CHOICE
altitudeqnh [0]
altitudeflightlevel[6]
FreeText ::= IA5String
(SIZE (1..256))
UM169
[freetext]
FreeText ::= IA5String
(SIZE (1..256))
UM169
[freetext]
UM19
MAINTAIN
[altitude]
Sample Clearance
Notes
KMEM
KIAH
SWB.TXMEX1
ANSWA DHART J180 SWB
CLEARED ROUTE
CLEARANCE
CHLDR1.ANSWA
UM169 limited to 80
characters.
5000
MAINTAIN 5000FT
EXPECT 390 10 MIN
AFT DP, DPFRQ 124.65
EDCT 1525
SQUAWK 0562
UM169 limited to 80
characters.
UM169 limited to 80
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 042315
Page 27
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]
UM169
[freetext]
UM169
[freetext]
FreeText ::= IA5String
(SIZE (1..256))
FreeText ::= IA5String
(SIZE (1..256))
UM169
[freetext]
FreeText ::= IA5String
(SIZE (1..256))
UM169
[freetext]
FreeText ::= IA5String
(SIZE (1..256))
Sample Clearance
DOTTY
KJFK J585 YQI
DOTTY/M084F370
BETTE3.ACK
AFTER DOTTY CLEARED TO
EGLL ARPT AS FILED,
MAINTAIN 5000
EXPECT 390 10 MIN
AFT DP, DPFRQ 124.65
EDCT 1525
SQUAWK 0562
Notes
CLEARED TO
DOTTY VIA ROUTE
CLEARANCE
UM169 limited to 80
characters.
UM169 limited to 80
characters.
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 042315
Page 28
Revised RTE – UM80
KMEM.CRSON1.HUMMS..PXV..BIGXX..MZZ.ROYKO3.KORD
UM
Number
UM169
[freetext]
ASN1
Definition
FreeText ::=
IA5String (SIZE
(1..256))
UM80
AirportDeparture[0]
[RouteClearance] AirportDestination
[1]
ProcedureArrival [6]
Routeinformation [8]
UM169
FreeText ::=
[freetext]
IA5String (SIZE
(1..256))
UM169
FreeText ::=
[freetext]
IA5String (SIZE
(1..256))
UM169
FreeText ::=
[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 124.15
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 042315
Page 29
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]
UM169
[freetext]
UM169
[freetext]
Sample Clearance
Notes
REVISED RTE, DPP
BSIDE
PBUDY..ARG..BSIDE
CLEARED TO BSIDE
VIA ROUTE
CLEARANCE
FreeText ::= IA5String
(SIZE (1..256))
DUCKZ1.PBUDY, AFT BSIDE
REST OF RTE UNCHNGD
New DP/TRAN. UM169
limited to 80 characters.
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 042315
Page 30
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))
UM83
AT [position]
CLEARED
[routeClearance]
Position ::= CHOICE ::=
fixname
RouteClearance ::=
SEQUENCE
AirportDestination [1]
ProcedureArrival [6]
Routeinformation [8]
Sample Clearance
Notes
REVISED RTE
BSIDE
AT BSIDE CLEARED
ROUTE CLEARANCE
KORD
MZZ.ROYKO3
BSIDE PXV BIGXX MZZ
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 042315
Page 31
Table A- 1 Conditional Departure Information Message Examples
Condition
any part of DPP
changed
SID, climbout,
climbvia
SID<>NONE
Climbviatxt <>
NONE
MAINT [alt]*
none
any part of DPP
changed
Climbviatext =
NONE
yes
SID changed to
NONE
Climbout <>
NONE Climbvia
= NONE
yes
SID changed to
NONE
CLIMBOUT=N
ONECLIMBVIA
= NONE
SID<>NONECli
mbviatext <>
NONE
yes
CLIMBOUT
changed to
NONE
Climbviatext =
NONE
yes
CLIMBOUT
changed
CLIMBVIA
changed
SID stays NONE
yes
SID<>NONE
none
CLIMBOUT
changed to
NONE
none
CLIMBVIA
changed to
NONE
yes
MAINT alt
changed to
NONE and
CLIMBVIA
selected
Climbout
changed (and
climbout <>
NONE)
MAINT alt
changed
none
MAINT alt not
changed but part
of DPP changed
UPLINK
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)
UM169 (procdep) "." (trans) " " (climbout)
“, “
MAINTAIN (alt)Note: (trans) and (climbout) only if
not NONE, but are included even if not changedNote:
1st UM169 should include REVISED DPP (and ALT if
[climbviatextt] is changed)
UM169 "SID NONE, " (climbout)UM19 [alt]Note:
include (climbout) if <> NONE, even if same Note: 1st
UM169 should include REVISED DPP (and ALT if
[alt] is changed)
UM169 "DPP NONE"UM19 [alt]Note: 1st 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: 1st 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
UM169 (climbout)UM19 [alt]Note: 1st UM169 should
include REVISED DPP
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
UM169 (procdep) "." (trans) " " (climbout)UM19 [alt]
Note: (trans) and (climbout) only if not NONE, but are
included even if not changed. ProcDep as
applicableNote: 1st UM169 should include REVISED
ALT
UM169 (procdep) "." (trans) " " (climbout) as appl, ",
“ (climbviatext)Note: 1st UM169 should include
REVISED ALT
SID<> NONE
and SID
unchanged
yes
UM169 (procdep) "." (trans) " " (climbout)UM19
[altitude]Note: 1st UM169 should include REVISED
DPP (and ALT if [alt] changed)
SID,
CLIMBOUT,
CLIMBVIA
unchanged
SID or
CLIMBOUT<>N
ONE
yes
UM19 [alt]Note: 1st UM169 should include REVISED
ALT
yes
UM169 (procdep) "." (trans) " " (climbout)UM19
[altitude]Note: 1st UM169 should include REVISED
DPP
S1P1 CPDLC DCL End2End Description 042315
Page 32
S1P1 CPDLC DCL End2End Description 042315
Page 33
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
example
<SOH>QU {IATA address
TO }
.{IATA address FROM}
{DDHHMM}
<STX>CCI
{ Sequence Number} CPDLC
DCL DISPATCH MSG – NOT
TO BE USED AS A
CLEARANCE
{Flight ID}
{AirportDeparture}
{Equipment} P{Departure
time}
{Computer Identifier}
FL{Expect Level [level]}
CLEARED TO {Airport
Destination} AIRPORT
{SID}.{TRANSITION FIX}
{Route Information}
{climbviatext}
DEP FREQ {freq}
{contactinfo}, {local info}
{Free Text}
<ETX>
Field Explanation
Example
Address of airline host
QU ANPOCWN
Automation System address and day/time
of message
SMI
Sequence number and notification
.OKCTWXA 081251
Flight ID and departure airport
FDX9901 KMEM
Equipment and departure time
D/A320/Q P1558
Computer code and expected altitude
555 FL300
Route Information (including Airport
Destination, departure procedure, and
departure transition fix)
Route Information
Initial Altitude
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}
Departure Frequency
Local information
CLEARED TO KOAK AIRPORT
CHLDR2.ANSWA
Full Route String (indicates the full cleared
route of flight)
<ETX>
CCI
003 CPDLC DCL DISPATCH MSG –
NOT TO BE USED AS A CLEARANCE
THEN AS FILED
CLIMB VIA SID
DEP FREQ 124.650
CTC GROUND CONTROL 121.9,
ADV ON INIT CTC YOU HAVE ATIS
KMEM.CHLDR2.ANSWA..TUL..KA39Y..
KD42U..ILC..OAL.MADN5.KOAK
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 P1558 555 FL300 CLEARED TO KOAK AIRPORT
S1P1 CPDLC DCL End2End Description 042315
Page 34
CHLDR2.ANSWA THEN AS FILED CLIMB VIA SID DEP FREQ 124.650 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
<SOH>QU {IATA address TO }
.{IATA address FROM}
{DDHHMM}
<STX>CCR
{ Sequence Number CPDLC DCL
DISPATCH MSG – NOT TO BE
USED AS A CLEARANCE
{Flight ID} {AirportDeparture}
REVISED <RTE DPP>
{Equipment} P{Departure time}
{Computer Identifier}
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}
Field Explanation
Address of airline host
Automation System address
and day/time of message
SMI
Sequence number and
notification
Example
QU ANPOCWN
.OKCTWXA 081251
Flight ID, departure airport
and revision marking
Equipment and departure time
Computer code and expected
altitude
Revised Route Information
FDX9901 KMEM REVISED RTE DPP
Revised Departure Procedure
Information
REVISED DPP ZUMIT.FOXOM, AFTER
GCK REST OF ROUTE UNCHANGED
Initial Altitude Free Text
Additional – Maintain
Altitude
Full Route String (indicates
the full cleared route of flight)
CLIMB VIA SID EXCEPT MAINT
5000FT
<ETX>
<ETX>
End of Transmission
CCR
005 CPDLC DCL DISPATCH MSG – NOT
TO BE USED AS A CLEARANCE
D/A320/Q P1610
555 FL300
REVISED RTE CLEARED TO GCK VIA
EOS ICT
KMEM.ZUMIT.FOXOM..EOS..ICT..GCK..
KD48W..HVE..ILC..OAL.MADN5.KOAK
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
P1610 555 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 042315
Page 35
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 P1330 01D FL320 REVISED EDCT 1630 REVISED DEPFREQ 117.250 REVISED CONTACT Ctc
Clearance Delivery now 118.5
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
<SOH>QU {IATA address TO }
.{IATA address FROM} {DDHHMM}
<STX>CCA
{Flight ID } {Sequence Number} {Aircraft Reg
#/Tail Number}{ Departure Time2} {Gate
Assignment3}
<ETX>
Field Explanation
Receiving Automation
System address (e.g.,
TDLS automation)
Sending Automation
System address (e.g.
AOC) and day/time of
message
SMI (message type
identifier) CCA
Flight ID (characters and
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,
End of Transmission
Example
<SOH>QU BNATWXA
. ANPOCWN 062117
<STX>CCA
SWA2331 89 N34522 P2145
<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 042315
Page 36
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
<SOH>QU {IATA address TO }
Field Explanation
Receiving Automation System
address (e.g., TDLS
automation)
Sending Automation System
address (e.g. AOC) and
day/time of message
SMI (message type identifier)
Clearance Sequence Number
Flight ID and departure airport
The response sent by the pilot
to the clearance identified by
the following fields
Sequence number and
notification
Example
QU ANPOCWN
{Flight ID} {Airport Departure}
Flight ID and departure airport
FDX9901 KMEM
{Equipment} P{Departure time}
Equipment and departure time
D/A320/Q P1558
{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 124.650
{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>
End of Transmission
.{IATA address FROM}
{DDHHMM}
<STX>CCP
{Sequence Number}
{Flight ID} {Airport Departure}
PILOT RESPONSE {Response}
{Sequence Number} CPDLC DCL
DISPATCH MSG – NOT TO BE
USED AS A CLEARANCE
S1P1 CPDLC DCL End2End Description 042315
.BNATWXA 062117
CCP
001
FDX9901 KMEM
PILOT RESPONSE - WILCO
001 CPDLC DCL DISPATCH MSG – NOT
TO BE USED AS A CLEARANCE
Page 37
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
<SOH>QU {IATA address TO }
. {IATA address FROM} {DDHHMM}
<STX>GRM
{ Sequence Number}
{Flight ID } {Aircraft Reg #/Tail
Number}{Departure Airport }
<ETX>
Field Explanation
Receiving Automation System
address (e.g., AOC automation)
Sending Automation System
address (e.g. TDLS at BNA) and
day/time of message
SMI (message type identifier)
GRM for Gate Request
Sequence number
Flight ID (characters and
numerals), optional tail number and
departure airport
End of Transmission
Example
<SOH>QU ANPOCWN
.BNATWXA 062117
<STX>GRM
89
SWA2331 N34522 KBNA
<ETX>
Table C- 2 GREQ Reply Message Body Example
Message Format for this example
<SOH>QU {IATA address TO }
.{IATA address FROM} {DDHHMM}
<STX>GIR
{ Sequence Number}
{Flight ID } {Aircraft Reg #/Tail
Number}{Departure Airport } {Gate
Assignment}
<ETX>
Field Explanation
Receiving Automation System
address (e.g., TDLS automation)
Sending Automation System
address (e.g. AOC) and day/time of
message
SMI(message type identifier) Gate
ID Response
Sequence number that matches
sequence number of GREQ
message for which this is a response
Flight ID (characters and numerals),
optional tail number and departure
airport, gate assignment of Gxxx or
G if unknown
End of Transmission
S1P1 CPDLC DCL End2End Description 042315
Example
<SOH>QU BNATWXA
. ANPOCWN 062118
<STX>GIR
89
SWA2331 N34522 KBNA
B3
<ETX>
Page 38
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
1.1.1. “1”xxx designates preferred departure clearance delivery mechanism
1.1.2. “2”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)
1a
Voice only*
Not equipped for ACARS or
FANS; gets voice only
1b
Voice only*
Equipped for ACARS and
FANS but wants voice only
E3J4J7
Z
2a
PDC only*
Not ACARS equipped but gets
PDC via manual means
Z
4
ICAO 2012
Fld 10a
Data Comm
4
Fld 18 DAT/
Comments
These apply to FANS in US domestic
airspace only.
Default if user is not getting PDC or
FANS. Field 10a may be optional.
1VOICE
Optional. Only needed if users want
to negate default PDC/CPDLC-DCL
value and use voice only.
1PDC
Some aircraft are non-ACARS
equipped, and 10a is physical
equipage. Still get PDC via other
means, e.g., gate printer.
No spaces in actual DAT/ codes
S1P1 CPDLC DCL End2End Description 042315
Page 39
#
User
Preference
Data Comm Capability
Description for S1P1 (2016)
ICAO 2012
Fld 10a
Data Comm
4
Fld 18 DAT/
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 CPDLCDCL 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 CPDLCDCL 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 042315
Page 40
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 2016. 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
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
S1P1 CPDLC DCL End2End Description 042315
Planned
Release
1. IOC
2.
Waterfall
3. TBD
Spec/DCP
ER #
1.
ER1341,
2.
ER1337,
1315
Prt
y
H
Page 41
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. 2014. 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
NAS Public
DMZ
External User’s
Web Browser
SDB Web
Server
Legend
HTTPS Interface
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:
https://faa.gov.xxxxxxxxx
URL 2:
https://faa.gov.xxxxxxxxx
S1P1 CPDLC DCL End2End Description 042315
Page 42
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) 954-9131 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 email) 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 042315
Page 43
1
4
2
3
Figure 12 - Subscriber Update Page
Item Feature
1
2
Subscriber
Information
Service Information
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 042315
Page 44
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.
3
4
Save | Cancel
Select Save to add/update the subscriber information in
the database.
Select Cancel to return to the Subscribers Menu page.
Navigation Path
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.
1
4
2
3
Figure 13 - Change Priorities Page
Item Feature
1
Subscriber
Information
Function
Lists Airline, Flight/Tail Number and Airport Code
for the selected subscriber.
S1P1 CPDLC DCL End2End Description 042315
Page 45
2
Services Information
3
Save | Cancel
4
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 042315
Page 46
1
4
2
3
e.
f. Figure 13 - Change Priorities Page
Item Feature
Function
2
Subscriber
Information
Services Information
3
Save | Cancel
1
4
Navigation Path
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
S1P1 CPDLC DCL End2End Description 042315
Page 47
This page intentionally blank