# FEDERAL AVIATION ADMINISTRATION

# AIR TRAFFIC CONTROL SYSTEM COMMAND CENTER

# GROUND DELAY PROGRAM

# SIMPLIFIED SUBSTITUTION MESSAGE PROCESSING

# November 2001

**TABLE OF CONTENTS**

1\. INTRODUCTION [3](#__RefHeading___Toc531397189)

2\. ISSUING GDPS [3](#__RefHeading___Toc531397190)

3\. AIRLINE SUBSTITUTIONS [5](#__RefHeading___Toc531397191)

3.1 Substitution Message Usage [6](#__RefHeading___Toc531397192)

3.1.1 Re-assigning Flights to Slots [6](#__RefHeading___Toc531397193)

3.1.2 Updating Other Data About a Controlled Flight.
[7](#__RefHeading___Toc531397194)

3.1.3 Cancelling Flights [7](#__RefHeading___Toc531397195)

3.1.4 Managing Open Slots [7](#__RefHeading___Toc531397196)

3.1.5 Creating Slots for Uncontrolled Flights
[8](#__RefHeading___Toc531397197)

3.1.6 Substituting Pop-up Flights [9](#__RefHeading___Toc531397198)

3.1.7 Error Processing [10](#__RefHeading___Toc531397199)

3.2 Substitution Message Formats [10](#__RefHeading___Toc531397200)

3.2.1 FM Message [10](#__RefHeading___Toc531397201)

3.2.2 FX Message [11](#__RefHeading___Toc531397202)

3.2.3 SC Message [11](#__RefHeading___Toc531397203)

3.2.4 Hold All Slots [12](#__RefHeading___Toc531397204)

3.2.5 Release All Slots [12](#__RefHeading___Toc531397205)

3.2.6 Message Field Descriptions [12](#__RefHeading___Toc531397206)

3.3 Substitution Message Replies [14](#__RefHeading___Toc531397207)

3.3.1 Good Response [14](#__RefHeading___Toc531397208)

3.3.2 Error Response [14](#__RefHeading___Toc531397209)

4\. REPORTS [15](#__RefHeading___Toc531397210)

4.1 Report Requests [15](#__RefHeading___Toc531397211)

4.2 Report Formats [16](#__RefHeading___Toc531397212)

4.2.1 EDCT LIST [16](#__RefHeading___Toc531397213)

4.2.2 EDCT SUB SHOW [16](#__RefHeading___Toc531397214)

4.2.3 EDCT SLIST [17](#__RefHeading___Toc531397215)

5\. UNSOLICITED MESSAGES [17](#__RefHeading___Toc531397216)

5.1 Substitution Status [17](#__RefHeading___Toc531397217)

5.2 GDP Termination [18](#__RefHeading___Toc531397218)

5.3 EDCT Update [18](#__RefHeading___Toc531397219)

5.4 FA Delay [18](#__RefHeading___Toc531397220)

6\. COMMUNICATIONS PROTOCOLS [18](#__RefHeading___Toc531397221)

6.1 ARINC-ADNS [18](#__RefHeading___Toc531397222)

6.2 CDMNET [19](#__RefHeading___Toc531397223)

6.2.1 Session Protocol [19](#__RefHeading___Toc531397224)

6.2.2 Message Protocol [20](#__RefHeading___Toc531397225)

6.2.3 Error Handling [22](#__RefHeading___Toc531397226)

7\. BECOMING A PARTICIPANT [22](#__RefHeading___Toc531397227)

Appendix A. SS ERROR RESPONSES [24](#__RefHeading___Toc531397228)

A.1 Message Validation Errors [24](#__RefHeading___Toc531397229)

A.2 Packet Header Errors [25](#__RefHeading___Toc531397230)

A.3 SS Error Messages [25](#__RefHeading___Toc531397231)

[]{#__RefHeading___Toc531397189 .anchor}1. INTRODUCTION

The simplified substitution process provides a way for airlines to
manage their flights during an airport ground delay program (GDP). The
essentials of simplified subs are:

1.  When a GDP is computed, the FAA divides the airport capacity into
    named arrival slots.

    When the GDP is issued, the FAA sends the airline a list of its
    controlled flights and the arrival slots to which they have been
    assigned.

    The airline can then re-assign its controlled flights to its
    assigned arrival slots in a flexible manner.

    Cancelled flights continue to own slots and appear in the data,
    making it easy to track and swap the open slots.

    Additional data, such as the slot hold flag and Earliest Runway Time
    of Arrival (ERTA), can be sent to better control the effects of the
    GDP on the airline.

    Additional data has been added to make the data exchange more
    robust.

Simplified substitution (SS) messages can be sent over the ARINC-ADNS
network or over a dedicated TCP/IP network known as the CDMNET.

This document is organized as follows.

> Section 1 -- How GDPs are issued.
>
> Section 2 -- The usage and formatting of simplified substitution (SS)
> messages.
>
> Section 3 -- Requesting reports.
>
> Section 4 -- Other GDP messages sent by FAA.
>
> Section 5 -- Protocol for using ARINC-ADNS or CDMNET.
>
> Section 6 -- How to become a participant in the substitution process.
>
> Appendix A -- Simplified substitution error messages.

[]{#__RefHeading___Toc531397190 .anchor}2. ISSUING GDPS

When a GDP is issued, the airline can receive *slot lists* at one or
more ARINC addresses, or over the CDMNET via TCP/IP socket, or both. The
slot lists provide a complete list of the controlled flights involved in
the GDP for that airline. If the airline performs substitutions for any
affiliates using different three-letter codes (e.g., if airline ABC also
subs for airline DEF), a separate list is sent for each three-letter
code. A new, complete set of lists is sent every time the FAA modifies a
GDP. The airline may submit substitution messages only for flights that
have been issued in a slot list.

A sample slot list has the following format:

FOR LGA DESTINATION AIRPORT

ATCSCC EDCT FLOW CONTROL DEPARTURE TIME

ABC1234 LGA260400A DCA 260300 260400 GDP - - - 260200 260245

ABC5678 LGA260500A IAD 260400 260500 GDP - - - 260300 260145

ABC3601 LGA260323A BOS 260206 260323 GDP Y - - 260319 260150

ABC3522 LGA260311A DCA 260215 260311 GDP - - - 260311 260145

ABC3994 LGA260353A ROC 260246 260353 GDP - Y - 260355 260235

Line 1: Identifies the GDP airport (LGA).

Line 2: Identifies the data as flow control departure times.

Lines 3 -- n: A line for each controlled flight. For each flight, the
slot list provides:

> Field 1: Flight ID (e.g., ABC1234). Concatenation of airline name and
> flight number. No leading zeros are shown in the flight number.
>
> Field 2: Arrival Slot; the time slot that has been reserved at the
> airport for this flight to land (e.g., LGA260400A). The format is a
> concatenation of airport name, slot date and time, and a one-letter
> suffix. The airport name can be three or four characters. The slot
> date and time is six digits: two each for day, hour, and minute. Day,
> hour, or minute should be zero padded if necessary (e.g., 06). The
> suffix letter is used to ensure that slot name is unique.
>
> Field 3: Departure Airport (e.g., DCA)
>
> Field 4: Controlled Time of Departure (CTD); the time the flight
> should take off (e.g., 260300). The format is a concatenation of
> day-hour-minute.
>
> Field 5: Controlled Time of Arrival (CTA); the time the flight should
> land (e.g., 260400). The format is a concatenation of day-hour-minute.
>
> Field 6: Control Type; the source of the current control times for
> this flight (e.g. GDP). The control types that can appear in a slot
> list are:
>
> GDP -- Control is part of an initial GDP, a revision to a GDP, or an
> extension to a GDP.
>
> COMP -- Control is part of a compression.
>
> BLKT -- Control is part of a blanket program.
>
> GS -- Control is part of a ground stop.
>
> SUB -- Control is from an airline substitution message.
>
> FA -- Control is from an FA delay.
>
> UPD -- Control is from an FAA "EDCT UPDATE" command.
>
> Field 7: Exempt Flag; indicates the flight was exempt from delays when
> the GDP was computed. Format is "Y" if true, "-" if false.
>
> Field 8: Cancel Flag; indicates whether the flight is currently
> cancelled. Format is "Y" if true, "-" if false.
>
> Field 9: Slot Hold Flag; indicates whether a slot belonging to a
> cancelled flight is being held by the airline for substitution. Format
> is "Y" if true, "-" if false.
>
> Field 10: Earliest Runway Time of Arrival (ERTA); the earliest time
> flight could arrive in the case that the delays are reduced (e.g.,
> 260200).
>
> Field 11: Initial Gate Time of Departure (IGTD); the original
> scheduled gate push back time for the flight (e.g., 260245). Used to
> uniquely identify the flight.

[]{#__RefHeading___Toc531397191 .anchor}3. AIRLINE SUBSTITUTIONS

Requests for simplified substitution processing must be transmitted over
ARINC-ADNS to the Air Traffic Control System Command Center (ATCSCC)
ARINC address TFMBSYA or over the CDMNET via TCP/IP socket. The format
of the SS message is the same regardless of how the message is
transmitted.

As an introduction, this section first presents an example of a
simplified sub (SS) message. Each part of the message, including the
detailed message formats and field descriptions is then described in
more detail.

A sample SS message has the following format:

SS ABC0626021029.01

FX ABC1234 DCA LGA 06260145

FM ABC1234 DCA LGA 06260145 T5 260400 T6 260500 A2 LGA260500A

FM ABC5678 IAD LGA 06260245 T5 260300 T6 260400 A2 LGA260400A

The sample SS message could be issued as a response to the slot list
shown in section 1, and operates on the first two flights shown in that
list. The effect of this example is to cancel flight ABC1234 and swap
the arrival slots between ABC1234 and ABC5678. More specifically:

> The first line identifies this as a simplified substitution (SS)
> packet sent by airline ABC on June 26^th^ at 02:10:09Z. (The ".01" can
> be set to whatever the airline wishes.)
>
> The "FX" line cancels flight ABC1234 from DCA to LGA originally
> departing on Jun 26^th^ at 0145Z (06260145).
>
> The first "FM" line says that flight ABC1234 from DCA to LGA
> originally departing on Jun 26^th^ at 0145Z (06260145) wants a new a
> CTD (T5) of 0400Z on the 26^th^ (260400), CTA (T6) of 0500Z on the
> 26^th^ (260500), and the arrival slot (A2) "LGA260500A".
>
> The second "FM" line says that flight ABC5678 from IAD to LGA
> originally departing on Jun 26^th^ at 0245Z (06260245) wants a new a
> CTD (T5) of 0300Z on the 26^th^ (260300), CTA (T6) of 0400Z on the
> 26^th^ (260400), and the arrival slot (A2) "LGA260400A".

A more formal description of the SS packet format follows.

Line 1: Packet header. The letters "SS" followed by a space followed by
a unique packet identifier. The packet identifier shall consist of the
three-letter airline code, a ten-digit transmission date/time (two
digits each of month, day, hour, minute, second), a period ("."), and a
two-digit suffix. The two-digit suffix may be used to create unique
identifiers when multiple messages are generated in the same second.
Otherwise the airline can set the suffix to any desired two digits.

> NOTE: If the packet is sent over the CDMNET, the airline has the
> option of directing the reply to an ARINC-ADNS address instead of back
> to the sending client via TCP/IP socket. To do so, the desired ARINC
> address must be included following the packet identifier separated by
> a space. Example: SS ABC0626021029.01 SUBHQAB

Lines 2 -- n: Substitution messages. Possible message types are:

> FM -- Flight modify message; updates one or more data fields for the
> flight identified in the message. Used to reassign an already
> controlled flight to a new arrival slot.
>
> FX -- Flight cancel message; cancels the flight identified in the
> message. Used to cancel a controlled flight.
>
> SC -- Slot create message; creates an arrival slot for the flight
> identified in the message. Used to assign control times to a flight
> that is not already controlled when an airline wants to restore the
> schedule order between a controlled and non-controlled flight.
>
> HOLD ALL SLOTS -- Sets the hold flag for all flights belonging to the
> sending airline that are currently controlled and cancelled. Used to
> preserve the position of all an airlines open slots during the next
> compression.
>
> RELEASE ALL SLOTS -- Releases the hold flag for all flights belonging
> to the sending airline that are currently controlled and cancelled.
> Used to tell FAA to make maximum use of all of an airline's open slots
> during the next compression.

[]{#__RefHeading___Toc531397192 .anchor}3.1 Substitution Message Usage

The messages within the simplified substitution (SS) packet are used to
re-assign flights to slots, to update other data about controlled
flights, to cancel flights, manage open slots, and to create slots for
uncontrolled flights.

The following sections describe how the messages are used for each of
these functions. Additional sections describe unique restrictions in
substituting "pop-up" flights, and error checking.

[]{#__RefHeading___Toc531397193 .anchor}3.1.1 Re-assigning Flights to
Slots

Re-assigning flights to slots is accomplished by sending a set of FM
messages. Each FM identifies the flight and the new slot requested for
the flight. The slot assignments in a single SS packet are error checked
both individually and as a group. The error checks are as follows:

1.  The airline must be authorized to modify all flights in the packet,
    as determined by the sending ARINC address. An airline is authorized
    to modify its own flights and sometimes those of affiliated
    "sub-carriers".

    All slots in the packet must have previously been assigned to the
    airline by the FAA in a slot list, or created by the airline via a
    valid Slot Create message.

    An SS packet must preserve the one-flight-one-slot relationship.
    That is, after the SS packet is processed, every slot must have
    exactly one flight in it and every previously controlled flight must
    be assigned to exactly one slot.

    NOTE: Cancelled flights can be re-assigned just like any other
    flight.

    An FM message must provide the following data:

    A unique identification of the flight (flight ID, origin,
    destination, and original gate departure date and time).

    The arrival slot desired for that flight.

    The new CTD and CTA for the flight to make that arrival slot.

    This data is subjected to the following error checks:

    The flight must have appeared in a slot list issued by FAA or have
    been controlled by the airline using a Slot Create message.

    The requested arrival slot must have been assigned to the airline in
    a slot list issued by FAA or have been created by the airline using
    a Slot Create message.

    The ETE, as computed by subtracting the CTD from the CTA, may change
    from the previous ETE by no more than 45 minutes or 50% of the
    previous ETE, whichever is greater. That is:

    If the previous ETE was from 1 to 90 minutes, the new ETE may change
    by up to 45 minutes.

    If the previous ETE was greater than 90 minutes, the new ETE may
    change by up to 50% of the previous ETE.

    The new CTA must be no earlier than the arrival slot time, and no
    more than 20 minutes later than the arrival slot time.

    The format of the FM message is described in detail in section 2.2.1

    []{#__RefHeading___Toc531397194 .anchor}3.1.2 Updating Other Data
    About a Controlled Flight.

    For a cancelled flight, the airline can use an FM to change the
    value of the slot hold flag. The slot hold flag tells FAA whether an
    open slot should be automatically filled when the GDP is compressed
    or revised.

    For a non-cancelled flight, the airline can use an FM to modify the
    Earliest Runway Time of Arrival (ERTA). The ERTA tells FAA the
    earliest possible arrival time the flight can make in the event that
    delays are reduced.

    The format of the FM message is described in detail in section 2.2.1

    []{#__RefHeading___Toc531397195 .anchor}3.1.3 Cancelling Flights

    An airline can cancel a controlled flight using an FX message. Once
    the flight is cancelled, the airline can continue to substitute that
    flight like any other flight. This provides an easy and robust
    mechanism for tracking and managing open slots.

    An FX message must provide a unique identification of the flight
    (flight ID, origin, destination, and original gate departure date
    and time). An FX may also optionally set the value of the hold flag.

    An FX message is subjected to the following checks:

    The airline must be authorized to cancel the flight, as determined
    by the sending ARINC address.

    The flight must have appeared in a slot list issued by FAA or have
    been controlled by the airline using a Slot Create message.

    The flight must not be already cancelled.

    The format of the FX message is described in detail in section 2.2.2

    []{#__RefHeading___Toc531397196 .anchor}3.1.4 Managing Open Slots

    When a flight is cancelled, the slot it is assigned to is known as
    an *open slot*. Every effort is made to ensure that no open slot go
    unused during a GDP. Responsibility for using open slots goes to
    both the airlines and the FAA. When an airline cancels a flight, it
    has the option of holding or releasing the slot (the slot is
    released by default). If the airline holds the slot, the airline is
    saying that it will take responsibility for moving other flights up
    into that slot, and moving the open slot down to the end of the GDP.
    If the airline releases the slot, it is saying that the slot is free
    for the FAA to manage. When the FAA revises or compresses a GDP, the
    compression algorithm moves flights up into the open slot and moves
    the open slot down to the end of the GDP.

    NOTE: The compression algorithm is carefully designed to ensure that
    the airline that owns the open slot gets the maximum possible delay
    reduction from that slot. Only in the event that the owning airline
    has no flights that can use the open slot will the compression
    algorithm assign another airline's flight to the open slot.

    In order to help ensure that open slots do not go unused, slots are
    automatically released each time a GDP is compressed or revised.
    This makes it less likely that an airline will hold an open slot
    then forget to ever use it.

    A sample sequence of how the slot holding works is as follows:

    GDP is issued

    Airline cancels a flight and holds the slot.

    Airline performs some substitutions moving the open slot to later in
    the GDP.

    FAA compresses the GDP. The open slot stays where it is, but it is
    released; i.e., no longer held.

    Airline continues to substitute flights using the open slot.

    FAA compresses the GDP again. Now the open slot, which is released,
    is compressed down to the end of the GDP.

    At any time when an airline is done doing substitutions and wishes
    to make all its open slots available for general use, the airline
    can issue the "RELEASE ALL SLOTS" message. This has the effect of
    clearing the slot hold flag for all cancelled flights for the
    sending airline. The format of the RELEASE ALL SLOTS message is
    described in detail in section 2.2.5.

    When compression is imminent and an airline needs more time to
    complete its substitutions, the airline can preserve the position of
    all its open slots by issuing the "HOLD ALL SLOTS" message. This has
    the effect of setting the slot hold flag for all cancelled flights
    for the sending airline. The format of the HOLD ALL SLOTS message is
    described in detail in section 2.2.4.

    []{#__RefHeading___Toc531397197 .anchor}3.1.5 Creating Slots for
    Uncontrolled Flights

    Due to the nature of the GDP algorithms and procedures, a situation
    can arise where an airline is forced to operate scheduled flights
    out of order. Consider an example of an airline that runs hourly
    service from BOS to IAD on the half hour. Consider two of these
    flights:

    FLIGHT1 normally departs at 1430Z

    FLIGHT2 normally departs at 1530Z

    A GDP is issued with an end time of 1500Z. The delays are running
    approximately 2 hours. After the GDP is issued, FLIGHT1 has a CTD of
    1630Z. Assuming the GDP is not extended, FLIGHT2 can operate on
    time, while FLIGHT1 has to operate an hour after FLIGHT2. Since
    FLIGHT2 is not controlled and has no arrival slot, the airline
    cannot swap these two flights and put them back into the scheduled
    order with one-hour delay for each flight.

    The Slot Create (SC) message allows an airline to manage this
    scenario. Using slot create, the airline can voluntarily control
    FLIGHT2, creating an arrival slot for it at its normally planned
    arrival time. Once the slot is created, the airline can swap the two
    flights using the usual mechanisms described in 2.1.1.

    When an airline creates an arrival slot for an uncontrolled flight,
    the airline must provide:

    A unique identification of the flight (flight ID, origin,
    destination, and original gate departure date and time).

    The arrival slot desired for that flight.

    The new CTD and CTA for the flight to make that arrival slot.

    The Slot Create message is subjected to the following error checks:

    The airline must be authorized to modify the flight, as determined
    by the sending ARINC address.

    The flight cannot already be controlled.

    The arrival slot name cannot already exist.

    The ETE, as computed by subtracting the CTD from the CTA, may change
    from the previous ETE by no more than 45 minutes or 50% of the
    previous ETE, whichever is greater. That is:

    If the previous ETE was from 1 to 90 minutes, the new ETE may change
    by up to 45 minutes.

    If the previous ETE was greater than 90 minutes, the new ETE may
    change by up to 50% of the previous ETE.

    The new CTA must be the same as the arrival slot time.

The format of the SC message is described in detail in section 2.2.3

[]{#__RefHeading___Toc531397198 .anchor}3.1.6 Substituting Pop-up
Flights

A pop-up flight is defined as a flight that is planned to arrive during
the GDP time period, but which did not exist when the GDP was issued.
Pop-up flights are generally created from a flight plan that is filed
after the GDP was sent. Because the flight did not exist when the GDP
was computed, it does not have a slot allocated for it. A special
mechanism -- the FA delay -- is used to assign an equitable delay to the
flight. When a flight gets an FA delay, it does not have a legitimate
slot. As a result, no substitutions are allowed for pop-up flights.
Pop-up flights are identified in a slot list by having a control type of
"FA".

A more complicated case occurs once the GDP is compressed or revised.
When the FAA compresses or revises, arrival slots are assigned to the
pop-up flights. This enables substitutions for these flights. However,
to reduce the opportunities for an airline to take unfair advantage of
the system, an additional restriction has been placed on substituting
these *former pop-up* flights. An airline can use substitution messages
to move a former pop-up flight earlier in time. However, an airline
cannot use a slot belonging to a former pop-up flight to move another
flight earlier in time.

Consider the following example:

[Flight]{.underline} [Status]{.underline} [Slot Time]{.underline}

ABC111 Normal 1200Z

ABC222 Former pop-up 1230Z

ABC333 Normal 1300Z

The airline operating these flights can swap the slots between ABC111
and ABC222, moving the former pop-up flight earlier in time. However,
the airline cannot swap flights ABC222 and ABC333, using the former
pop-up slot to reduce the delay for another flight.

[]{#__RefHeading___Toc531397199 .anchor}3.1.7 Error Processing

The 3-letter airline codes in the flights IDs contained in the SS
messages are validated against the sender's ARINC address. If the
address of the sender is not authorized for each airline code in the
packet, the processing is terminated and an error message is returned to
the sender.

When an SS packet is processed, the messages are error checked both
individually and collectively. Collective checking is required to ensure
that that the one-flight-one-slot rule is preserved. If any error is
discovered during the processing of a packet, the entire packet is
rejected without making any updates to the FAA database. This avoids the
situation where the airline is unsure of what changes did or did not get
applied, or creating an unwanted set of changes.

Because packet-level error checking is performed, all messages in an SS
packet must pertain to the same arrival airport GDP. This simplifies
both the generation of the messages and the error checking.

FAA tries to find as many errors as possible when a packet is processed.
If a packet is rejected, all detected errors will be reported in the
reply.

A common source of errors is lack of synchronization between the airline
data and the FAA data. A new report -- EDCT SLIST -- has been provided
to allow an airline to request the entire FAA data for a GDP whenever a
"re-synch" is desired.

A complete list of the possible error messages is provided in Appendix
A.

[]{#__RefHeading___Toc531397200 .anchor}3.2 Substitution Message Formats

[]{#__RefHeading___Toc531397201 .anchor}3.2.1 FM Message

The FM message is used to modify data about an existing controlled
flight. The first field defines the message type. The next four fields
uniquely identify the flight that is being modified. The remaining
fields are used to modify the data for the flight. For each field being
modified there is a field identifier followed by the new data value for
that field.

A sample FM message has the following format:

FM ABC1234 DCA LGA 06260145 T5 260400 T6 260500 A2 LGA260500A --

A6 R T8 260430

The sample message has the following meaning:

> FM -- Message type.
>
> ABC1234 -- Flight identifier (a.k.a. call sign) of the flight being
> modified.
>
> DCA -- Origin airport for the flight.
>
> LGA -- Destination airport for the flight.
>
> 06260145 -- Original gate departure date and time for the flight
> (0145Z on June 26^th^).
>
> T5 -- Field identifier for CTD
>
> 260400 -- New value of CTD requested for this flight (0400Z on the
> 26^th^).
>
> T6 -- Field identifier for CTA
>
> 260500 -- New value of CTA requested for this flight (0500Z on the
> 26^th^).
>
> A2 -- Field identifier for assigned arrival slot.
>
> LGA260500A -- Name of arrival slot requested for this flight.
>
> "-" -- Continuation character; indicates that the message continues on
> the next line.
>
> A6 -- Field identifier for slot hold flag.
>
> R -- New value (released) requested for this flight's slot.
>
> T8 -- Field identifier for ERTA.
>
> 260430 -- Name of arrival slot requested for this flight (0430Z on the
> 26^th^).

A detailed description of each field format is provided in section
2.2.6.

[]{#__RefHeading___Toc531397202 .anchor}3.2.2 FX Message

The FX message is used to cancel an existing controlled flight. The
first field defines the message type. The next four fields uniquely
identify the flight that is being modified. The airline can optionally
send an additional two fields for setting the value of the hold flag.

A sample FX message has the following format:

FX ABC1234 DCA LGA 06260145 A6 H

The sample message has the following meaning:

> FX -- Message type.
>
> ABC1234 -- Flight identifier (a.k.a. call sign) of the flight being
> modified.
>
> DCA -- Origin airport for the flight.
>
> LGA -- Destination airport for the flight.
>
> 06260145 -- Original gate departure date and time for the flight
> (0145Z on June 26^th^).
>
> A6 -- Field identifier for slot hold flag.
>
> H -- New value (held) requested for this flight's slot.

A detailed description of each field format is provided in section
2.2.6.

[]{#__RefHeading___Toc531397203 .anchor}3.2.3 SC Message

The SC message is used to create a slot for an existing un-controlled
flight. The first field defines the message type. The next four fields
uniquely identify the flight that is being modified. The remaining
fields provide the CTD, CTA, and arrival slot for the flight.

A sample SC message has the following format:

SC ABC999 STL LGA 06260315 T5 260328 T6 260552 A2 LGA260552Q

The sample message has the following meaning:

> SC -- Message type.
>
> ABC999 -- Flight identifier (a.k.a. call sign) of the flight being
> modified.
>
> STL -- Origin airport for the flight.
>
> LGA -- Destination airport for the flight.
>
> 06260315 -- Original gate departure date and time for the flight
> (0315Z on June 26^th^).
>
> T5 -- Field identifier for CTD
>
> 260328 -- New value of CTD requested for this flight (0328Z on the
> 26^th^).
>
> T6 -- Field identifier for CTA
>
> 260552 -- New value of CTA requested for this flight (0552Z on the
> 26^th^).
>
> A2 -- Field identifier for assigned arrival slot.
>
> LGA260552Q -- Name of arrival slot requested for this flight. (NOTE:
> FAA creates suffixes using the early part of the alphabet and also
> uses Z. By choosing a suffix that is later in the alphabet but not Z,
> the airline increases the changes that the slot name will be unique.)

A detailed description of each field format is provided in section
2.2.6.

[]{#__RefHeading___Toc531397204 .anchor}3.2.4 Hold All Slots

The HOLD ALL SLOTS message holds all open slots belonging to an airline
for a particular GDP.

A sample message has the following format:

HOLD ALL SLOTS FOR LGA

[]{#__RefHeading___Toc531397205 .anchor}3.2.5 Release All Slots

The RELEASE ALL SLOTS message releases all open slots belonging to an
airline for a particular GDP.

A sample message has the following format:

RELEASE ALL SLOTS FOR LGA

[]{#__RefHeading___Toc531397206 .anchor}3.2.6 Message Field Descriptions

Following are detailed descriptions of each field used in the FM, FX,
and SC messages. Each description includes:

1.  Field number

    Field name

    Format defined as the field length and composition. The composition
    shows how many and what kinds of symbols are allowed. Symbols shown
    outside of parentheses are required. Symbols shown inside
    parentheses are optional. The following conventions are used in the
    composition:

    L -- uppercase letter (A-Z)

    a -- any uppercase letter or digit (A-Z, 0-9)

    d - any digit (0-9)

    () -- parentheses indicate optional characters.

    Example: Ld(a)(a) means that the field must start with an uppercase
    letter followed by a number, optionally followed by one or two
    characters that are either letters or numbers.

    Examples.

    A paragraph describing the field.

Field 02. [Flight Identification]{.underline} --- 2--7 characters.
La(a)(a)(a)(a)(a)

Examples: N1, GAA1234

Flight call sign as it appears in the OAG and/or is filed on the NAS
flight plan. No padding is required. Do not include a space between the
airline code and the flight number.

Field 26. [Departure Airport]{.underline} --- 3-4 characters. aaa(a)

Examples: JFK, CYYZ

FAA identifier for the airport of origin for this flight.

Field 27. [Arrival Airport]{.underline} --- 3-4 characters. aaa(a)

Examples: JFK, CYYZ

FAA identifier for the destination airport for this flight.

Field A1. [Original Gate Departure Date and Time]{.underline} --- 8
digits. dddddddd

Example: 06261225

Month, day, hour and minute on which the flight leg was originally
scheduled to depart the gate. Month, day, hours and minutes must each be
two digits, zero padded.

Field A2. [Assigned Arrival Slot]{.underline} --- 10-11 characters.
(L)LLLddddddL

Example: ORD261200A, CYYZ261200C

Unique identifier of the arrival slot to which this flight is currently
assigned. The format is a concatenation of airport name, slot date and
time, and a one-letter suffix. The airport name can be three or four
characters. The slot date and time is six digits: two each for day,
hour, and minute. Day, hour, or minute should be zero padded if
necessary (e.g., 06). The suffix letter is used to ensure that slot name
is unique.

Field A6. [Slot Hold Flag]{.underline} --- 1 character. L

Examples: H, R

Value of the hold flag; H means slot is held, R means slot is released.
Only valid if the slot is currently occupied by a cancelled flight.

Field T5. [Controlled Time of Departure (CTD)]{.underline} --- 6 digits.
dddddd

Example: 261245

Day, hour, and minute at which the flight will have to leave the
departure runway to make its controlled arrival time. Also referred to
as EDCT. Format is six digits: two each for day, hour, and minute. Day,
hour, or minute should be zero padded if necessary (e.g., 06).

Field T6. [Controlled Time of Arrival (CTA)]{.underline} --- 6 digits.
Dddddd

Example: 261553

Day, hour, and minute at which the flight must arrive to make its
arrival slot. Format is six digits: two each for day, hour, and minute.
Day, hour, or minute should be zero padded if necessary (e.g., 06).

Field T8. [Earliest Runway Time of Arrival (ERTA)]{.underline} --- 6
digits. Dddddd

Example: 261518

Day, hour, and minute of the earliest runway arrival time that an
airline is willing to accept for a flight. Format is six digits: two
each for day, hour, and minute. Day, hour, or minute should be zero
padded if necessary (e.g., 06).

[]{#__RefHeading___Toc531397207 .anchor}3.3 Substitution Message Replies

FAA will send a response to every SS message packet. The response is
sent to the return address on the incoming message. The format of the
response is the same regardless of what types of messages were sent in
the SS packet.

[]{#__RefHeading___Toc531397208 .anchor}3.3.1 Good Response

If no errors are detected in the SS packet, the FAA database is updated
to reflect the changes requested by the airlines. The response to the
airline includes the packet identifier, a message indicating it was
successfully processed, and an updated slot list for each flight
affected by the message.

A good response to the sample packet from section 2 has the following
format:

SS ABC0625121029.01 ACCEPTED.

SLOT LIST for LGA

ACID ASLOT DEP CTD CTA TYPE EX CX SH ERTA IGTD

ABC1234 LGA260500A DCA 260400 260500 SUB - Y - - 260145

ABC5678 LGA260400A IAD 260300 260400 SUB - - - 260400 260245

The meaning of the sample response is as follows:

Line 1: Shows the identifier of the packet that is being replied to. The
word "ACCEPTED" indicates that the processing of the packet was
successful.

Line 2: Identifies airport that the SS messages were for.

Line 3: blank

Line 4: Column headers for the slot list.

Lines 5 -- n: A slot list for all flights affected by the SS messages.
The format is the same as described in section 1.

[]{#__RefHeading___Toc531397209 .anchor}3.3.2 Error Response

If errors are detected in the SS packet, the entire packet is rejected
and the FAA database is not updated. The response to the airline
includes the packet identifier, a message indicating it was rejected,
and the number of errors. For each error, the response shows the SS
message that triggered the error and the reason for the error.

A sample error response has the following format:

SS ABC0625121029.01 REJECTED. 1 ERROR.

FM ABC1234 DCA LGA 06260145 T5 260400 T6 260430 A2 LGA260500A

ERR501: CTA NOT WITHIN 20-MINUTE WINDOW

The meaning of the sample response is as follows:

Line 1: Shows the identifier of the packet that is being replied to. The
word "REJECTED" indicates that the processing of the packet was
successful. The number of errors is shown.

Line 2: blank

Line 3: The SS message that triggered the error.

Line 4: The error code and message. In this case the CTA provided in the
T6 field was not within 20 minutes of the slot time shown in the A2
field.

A complete list of the error messages is shown in Appendix A.

[]{#__RefHeading___Toc531397210 .anchor}4. REPORTS

Three reports are available to the airline through the SS process.
Report requests must be transmitted to the Air Traffic Control System
Command Center (ATCSCC) ARINC address TFMBSYA or over the CDMNET via
TCP/IP socket.

[]{#__RefHeading___Toc531397211 .anchor}4.1 Report Requests

When sending a report request over ARINC-ADNS, the request must include
the "RQ" packet header. When sending report requests over CDMNET, no
header is required or allowed.

A sample report request has the following format:

RQ

EDCT LIST

EDCT SUB SHOW

EDCT SLIST LGA

Line 1: Packet header: the letters "RQ". No packet identifier is
required. Only required and allowed for ARINC-ADNS messages.

Line 2 - n: Report request(s). The packet can include one or more
requests. Each report comes back as a separate message. Possible request
types are:

> EDCT LIST -- Returns a list of all airports that currently have GDPs.
>
> EDCT SUB SHOW -- Returns the substitution status (on or off) at all
> airports that currently have GDPs (sub status is also part of the EDCT
> LIST report).
>
> EDCT SLIST LGA-- Returns a slot list for the requested airport. Unlike
> the slot lists when the GDP is issued, the EDCT SLIST report returns a
> single list that includes all flights affiliated with the requesting
> airline. That is, the reply can include different three-letter airline
> codes in one report.

[]{#__RefHeading___Toc531397212 .anchor}4.2 Report Formats

[]{#__RefHeading___Toc531397213 .anchor}4.2.1 EDCT LIST

A sample EDCT LIST report has the following format:

Number of airports currently controlled: 3

DEST TIMES CONTROL FLIGHTS SUBS

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

EWR /18/23/ EDCT+FA 44 ON

EWR /19/01/ EDCT+FA 255 ON

LGA /18/23/ EDCT+FA 123 ON

JFK /20/23/ GS 47 OFF

Number of sectors currently controlled: 0

Printer: \$fsa.//wkstn32

The meaning of the sample is as follows:

Line 1: The number of airports that currently have GDPs or ground stops.

Line 2: blank

Line 3: Column headers

Line 4: separator

Lines 5 -- n: A list of each issuance of a GDP or ground stop that are
currently in effect. Each line indicates (using line 5 as an example)

> Airport name (EWR)
>
> Start and end times of the GDP or ground stop (1800Z to 2300Z)
>
> Types of controls issued (EDCTs and FA delays)
>
> Number of flights affected (44)
>
> Status of substitutions (ON)

If a GDP has been revised or compressed, there will be multiple lines
for that airport. The number of flights in any line shows the number of
flights controlled by that issuance that were not later updated in the
next issuance. Thus, the total number of affected flights is the sum of
these numbers (for EWR, 255+44 = 299 flights currently affected).

[]{#__RefHeading___Toc531397214 .anchor}4.2.2 EDCT SUB SHOW

A sample EDCT SUB SHOW report has the following format:

Airport SI Processing Activated

EWR YES

LGA YES

JFK NO

The meaning of the sample is as follows:

Line 1: Report header

Line 2: blank

Line 3 -- n: A list of each GDP airport and the status of substitutions
at that airport.

The data shown in the EDCT SUB SHOW report is the same as the data shown
in the SUBS column of the EDCT LIST report.

[]{#__RefHeading___Toc531397215 .anchor}4.2.3 EDCT SLIST

The EDCT SLIST request returns the same format used to issue a GDP, or
used to reply to an SS message. The only differences with the GDP
issuance are the first line and the fact that the column headers are
included.

The EDCT SLIST report takes the place of the CTALIST report used to
"re-synch" the SI message processing.

A sample EDCT SLIST report has the following format:

SLOT LIST for LGA

ACID ASLOT DEP CTD CTA TYPE EX CX SH ERTA IGTD

ABC1593 LGA252100A ORD 251641 252100 GDP Y - - 252034 251623

ABC489 LGA252258A ORD 251901 252258 GDP Y - - - 251835

ABC81 LGA260218A ORD 252212 260218 GDP - Y - - 252000

ABC1435 LGA260419A ORD 260014 260419 GDP - - - 260223 252152

ABC195 LGA251939A BOS 251346 251939 GDP Y - - 251910 251300

ABC193 LGA260403A BOS 252230 260403 GDP - - - - 251925

ABC1033 LGA252030A DFW 251651 252030 GDP Y - - 252012 251608

The meaning of the sample response is as follows:

Line 1: Identifies airport that the slot list is for.

Line 2: blank

Line 3: Column headers for the slot list.

Lines 4 -- n: A slot list for all flights currently affected by the GDP.
The format is the same as described in section 1.

[]{#__RefHeading___Toc531397216 .anchor}5. UNSOLICITED MESSAGES

During a GDP, FAA will send messages to the airlines when changes are
made in the FAA database that affect that airline's flights. These
messages can be sent to ARINC addresses provided by the airline or over
CDMNET via TCP/IP socket.

[]{#__RefHeading___Toc531397217 .anchor}5.1 Substitution Status

A message is sent whenever the FAA turns the substitution processing on
or off at an airport. Airline substitution message are rejected when
substitutions are turned off. This is typically done just before a GDP
is revised so that the FAA and airline databases will stay synchronized.
A sample of each type follows:

EDCT SUB OFF LGA

EDCT SUB ON LGA

[]{#__RefHeading___Toc531397218 .anchor}5.2 GDP Termination

The FAA terminates a GDP by using an EDCT PURGE command to clear the
controls out of the FAA database. The airline will get a copy of the
EDCT PURGE commands. A sample EDCT PURGE follows:

EDCT PURGE LGA

[]{#__RefHeading___Toc531397219 .anchor}5.3 EDCT Update

The FAA can manually update the data for a controlled flight using an
internal command called EDCT UPDATE. The airline will get a message
whenever EDCT UPDATE is used to modify one of its flights (including
affiliated airlines). The update is simply a new slot list including the
one flight that was changed by FAA.

A sample EDCT UPDATE message has the following format:

EDCT UPDATE FOR LGA

ACID ASLOT DEP CTD CTA TYPE EX CX SH ERTA IGTD

ABC1593 LGA252100A ORD 251641 252100 UPD Y - - 252034 251623

[]{#__RefHeading___Toc531397220 .anchor}5.4 FA Delay

The airline will get message whenever an FA delay is applied to one of
its flights. The update is simply a new slot list including the one
flight that was changed by FAA.

A sample EDCT UPDATE message for an airline has the following format:

FA DELAY FOR LGA

ACID ASLOT DEP CTD CTA TYPE EX CX SH ERTA IGTD

ABC1593 LGA252100A ORD 251641 252100 FA Y - - 252034 251623

[]{#__RefHeading___Toc531397221 .anchor}6. COMMUNICATIONS PROTOCOLS

[]{#__RefHeading___Toc531397222 .anchor}6.1 ARINC-ADNS

The ARINC-ADNS network provides airlines with a customized network for
transmitting and receiving certain aviation data. The GDP messages are
sent and received using the same protocol as other ADNS data. The only
specific requirement of the GDP messages is that they be sent with a
priority of "QU".

To help illustrate the protocol format, here is the sample SS packet
from section 2 as it appears when sent over ARINC-ADNS:

QU TFMBSYA

.SUBHQAB

SS ABC0626021029.01

FX ABC1234 DCA LGA 06260145

FM ABC1234 DCA LGA 06260145 T5 260400 T6 260500 A2 LGA260500A

FM ABC5678 IAD LGA 06260245 T5 260300 T6 260400 A2 LGA260400A

The meaning of the sample is as follows:

Line 1: Shows the message priority (QU) and the FAA address to which the
messages must be sent (TFMBSYA).

Line 2: Shows the return address of the sending airline. In some cases,
a time stamp follows the return address. This is allowed but not
required.

Lines 3 -- n: The content of the SS packet.

NOTES:

1.  ARINC-ADNS limits line lengths to 68 characters. An SS message can
    be continued to another line by using a hyphen (-) as the last field
    in the first line.

    ARINC-ADNS message packet size is limited to approximately 1800
    bytes.

[]{#__RefHeading___Toc531397223 .anchor}6.2 CDMNET

CDMNET is a private, dedicated communications network based on TCP/IP
protocol used to provide secure, reliable, high-speed communications
between airlines and FAA. Several vendors provide connectivity to CDMNET
offering different levels of service to the airlines. If an airline
chooses to use CDMNET, it is incumbent on the airline to develop or
procure software that adheres to the protocol described here.

[]{#__RefHeading___Toc531397224 .anchor}6.2.1 Session Protocol

Using CDMNET, inter-process communications between application processes
at the airlines and the FAA are performed in "sessions" through
dedicated TCP/IP sockets. In each session, the application running at
the airline site is considered the client and the application running at
the FAA is considered the server. The approach is as follows:

1.  A client process opens a socket connection to a server process using
    an FAA-provided IP address and starts a session.

    Data is exchanged between the client and server indefinitely.

    The client terminates the session by closing the connection. (NOTE:
    Under error conditions the server can also close the connection and
    end the session.)

When the connection is opened, the FAA server uses the IP address to
validate that the connection is coming from an allowed client. The
client begins the session either by sending a "connect" message, or by
sending any other type of GDP message. Each message has a *client tag*
embedded in the header. The FAA server validates the client tag against
the sending IP address to help ensure that the data is coming from the
authorized client and to identify which airline is sending the data.

The airline client can manage the session in several ways. If the
airline wants to get unsolicited GDP messages, the client should
establish a connection, send a connect message (to identify itself), and
listen on the socket indefinitely. If the airline does not want to get
the unsolicited messages, the client can connect when it has a message
to send, wait for the reply, then disconnect.

If an airline wants to run multiple simultaneous clients, the airline
needs a unique client tag for each. FAA will provide as many client tags
as the airline needs. FAA can authorize use of the client tags from a
single IP address or multiple addresses.

FAA provides multiple servers for added reliability. Airport client
software should have the capability of connecting to more than one
server address.

In the case that the FAA server has data to transmit to an airline and
the airline client is not currently connected, the FAA server discards
the data. When an airline client reconnects, it can use the reports
requests to synchronize the airline with the current FAA data, if
desired.

[]{#__RefHeading___Toc531397225 .anchor}6.2.2 Message Protocol

All messages sent over CDMNET are comprised of a 24-byte binary header,
followed in most cases by a variable number of bytes containing
application-specific data; for example, a slot list, an SS packet, or a
report request. The 24-byte header is comprised of six 4-byte integers,
defined as follows:

> 1\) Message Type - Integer value of the message type. \[4-byte
> integer\]
>
> 2\) Message Source - Not used for this application. Should always be
> 0. \[4-byte integer\]
>
> 3\) Message Destination - Not used for this application. Should always
> be 0. \[4-byte integer\]
>
> 4\) Client Tag - The client tag assigned by the FAA for use by the
> airline. \[4-byte integer\]
>
> 5\) Short Data - Field for optional use by the airline as a sequence
> number or message identifier. If this field is filled on an SS message
> or a GDP request, the value will be inserted in this same field on the
> corresponding reply. \[4-byte integer\]
>
> 6\) Message Length - Length of the data buffer to follow (may be zero;
> maximum is 128 Kbytes). \[4-byte integer\]
>
> 7\) Data Buffer - An array of ASCII bytes, the size of which is
> defined by the Message Length field, containing the application
> message (e.g., "EDCT LIST") It may only sent if the Length field in
> the header is non-zero. Maximum size is 128 Kbytes.

The message types that are used for GDP data are defined in the
following table:

  ---------------- ----------- ----------------------- ---------------------
  **Message Type   **Integer   **Use**                 **Data Buffer
  Name**           Value**                             Content**

  M_CONNECT        1           Sent by client when     There is no data
                               first connecting to     buffer for this
                               identify itself to the  message.
                               FAA server.             

  M_SS_PACKET      101         Sent by client to       SS packet as
                               submit a simplified     described in Section
                               substitution request.   2.

  M_SS_REPLY       102         Sent by FAA server in   SS Reply as described
                               response to a           in Section 2.3.
                               simplified substitution 
                               request.                
  ---------------- ----------- ----------------------- ---------------------

  ---------------- ----------- ----------------------- ---------------------
  **Message Type   **Integer   **Use**                 **Data Buffer
  Name**           Value**                             Content**

  M_SLOT_DATA      103         Sent by FAA server when Slot list as
                               a GDP is issued;        described in section
                               includes initial GDP,   1.
                               compression, revision,  
                               extension, blanket, or  
                               ground stop.            

  M_GDP_REQ        104         Sent by airline client  Report request (EDCT
                               to request one or more  LIST, EDCT SUB SHOW,
                               reports.                or EDCT SLIT) as
                                                       described in Section
                                                       3.1.

  M_GDP_REPLY      105         Sent by FAA server in   Report (EDCT LIST,
                               response to a report    EDCT SUB SHOW, or
                               request.                EDCT SLIT) as
                                                       described in Section
                                                       3.2.

  M_GDP_MESSAGE    106         Sent by FAA server when Unsolicited messages
                               triggered by certain    (EDCT PURGE, EDCT SUB
                               events during a GDP.    ON/OFF, EDCT UPDATE,
                                                       FA DELAY) as
                                                       described in section
                                                       4.
  ---------------- ----------- ----------------------- ---------------------

An example of a client message follows. Back-slashes are used to
delineate the start and end of the message. Numbers in angle brackets
are four-byte binary integers. Plain characters are ASCII text. \<NL\>
is used to represent the newline character.

> \\\<104\>\<0\>\<0\>\<383\>\<1\>\<9\>EDCT LIST\\

This example should be interpreted as follows:

> \<104\> - Message type M_GDP_REQ
>
> \<0\> - Ignored
>
> \<0\> - Ignored
>
> \<383\> - Client tag assigned by FAA for this client
>
> \<101\> - Request identifier filled in by the client.
>
> \<9\> - Number of ASCII bytes to follow.
>
> 'EDCT LIST' -- The 9 ASCII bytes that contain the report request.

A sample reply to this message is:

> \\\<105\>\<0\>\<0\>\<383\>\<1\>\<174\>Number of airports currently
> controlled: 1\<NL\>\<NL\>DEST TIMES CONTROL FLIGHTS
> SUBS\<NL\>\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--\<NL\>EWR
> /18/23/ EDCT+FA 44 ON\\

This example should be interpreted as follows:

> \<105\> - Message type M_GDP_REPLY
>
> \<0\> - Ignored
>
> \<0\> - Ignored
>
> \<383\> - Client tag assigned by FAA for this client
>
> \<101\> - The short data field copied from the client request.
>
> \<174\> - Number of ASCII bytes to follow.
>
> 'Number of airports...' -- The 174 ASCII bytes that contain the
> report.

[]{#__RefHeading___Toc531397226 .anchor}6.2.3 Error Handling

#### Loss of Client

When the FAA server detects a loss of client, it ends the session by
closing the connection. It is the responsibility of the client to
reestablish the connection. The server considers any of the following
events to be a "loss of client".

1.  Notification that the socket connection to the client has been lost

    A failure when writing to the client socket.

#### Loss of Server

When a client detects a loss of server, it should end the session by
closing the connection, notifies the user as appropriate, and tries to
re-establish a new connection. A client considers any of the following
events to be a "loss of server".

1.  Notification that the socket connection to the server has been lost

    A failure when writing to the server socket.

[]{#__RefHeading___Toc531397227 .anchor}7. BECOMING A PARTICIPANT

Before an airline can participate in simplified substitutions, the
airline must have connectivity to the FAA traffic management system.
This can be done either through the ARINC-ADNS network, or through the
private CDMNET. A list of vendors who provide access to CDMNET will be
provided upon request.

To participate in simplified substitutions, the airline must provide the
FAA with the following information:

1.  All three-letter codes that you would like to get GDP data for and
    send SS messages for.

    Written authorization from any other airlines for which you will be
    doing substitutions. (NOTE: If such authorization already existed
    for SI messages, it does not need to be repeated for SS messages.)

    In addition, if the airline is using ARINC-ADNS, it must provide to
    FAA:

    ARINC address(es) that you would like the slot lists sent to when
    GDPs are issued.

    ARINC address(es) that you would like to be authorized for
    submitting SS messages.

    ARINC address(es) that you would like to have the unsolicited
    messages sent to.

If the airline is using the CDMNET, it must provide to FAA:

1.  Apparent IP address (i.e., the address that FAA will see) for any
    client machines authorized to do simplified substitutions.

    The number of simultaneous clients that the airline intends to use
    operationally.

    In addition, if the airline is using the CDMNET, FAA will provide to
    the airline:

    One or more unique client tags.

    IP addresses and port numbers of the FAA server.

The FAA can provide access to a test system for airlines that would like
to test the simplified substitution before using it operationally.

To request participation in the simplified substitution process, contact
the FAA Air Traffic Control System Command Center (ATCSCC) at the
Computer System Analyst (CSA) position. Phone number is (703) 904-4451.

[]{#__RefHeading___Toc531397228 .anchor}Appendix A. SS ERROR RESPONSES

[]{#__RefHeading___Toc531397229 .anchor}A.1 Message Validation Errors

The following are general errors in either syntax or semantics that may
be detected while parsing the individual SS messages prior to
correlating the messages with the FAA database.

ERR301: UNKNOWN MESSAGE TYPE. USE FC/FM/FX/SM/HOLD ALL SLOTS FOR/RELEASE
ALL SLOTS FOR.

A message with an invalid message type was received. Valid message types
are FM, FX, SC, HOLD ALL SLOTS, and RELEASE ALL SLOTS.

ERR302: UNKNOWN FORMAT FOR FLIGHT ID.

The flight ID field does not match the specified syntax.

ERR303: UNKNOWN FORMAT FOR AIRPORT.

An airport field does not match the specified syntax.

ERR304: UNKNOWN FORMAT FOR DEPARTURE AIRPORT.

The departure airport field does not match the specified syntax.

ERR305: UNKNOWN FORMAT FOR ARRIVAL AIRPORT.

The arrival airport field does not match the specified syntax.

ERR306: UNKNOWN AIRPORT.

The specified airport does not exist in the ETMS airport database.

ERR307: FLIGHT ID/DEPARTURE/ARRIVAL AIRPORT MISSING.

One of the first three required fields is missing (cannot tell which one
from syntax).

ERR308: UTC DEPARTURE DATE/TIME MISSING/INCORRECT.

The required field UTC Departure Date/Time is missing.

ERR309: INVALID UTC DEPARTURE DATE/TIME.

The UTC Departure Date/Time contains an illegal value (e.g., a month
greater than 12)

ERR310: UNKNOWN FORMAT FOR UTC DEPARTURE DATE.

The UTC Departure Date/Time field does not match the specified syntax.

ERR317: INVALID TIME. USE DDHHMM

A time field contains an illegal value (e.g., date greater than 31)

ERR318: DEPARTURE TIME LATER THAN ARRIVAL TIME.

A departure time cannot be later than an arrival time in a matched pair
of times (e.g., control times).

ERR319: DEPARTURE TIME EQUAL TO ARRIVAL TIME.

A departure time cannot be equal to an arrival time in a matched pair of
times (e.g., gate times).

ERR323: FIELD SPECIFIED MULTIPLE TIMES.

A field has been defined more than once.

ERR326: FLIGHT ID TOO LONG. USE MAX 7 CHARS.

The Flight ID has 8 characters. Although this is valid CDM message
syntax, Flight ID's of 8 characters will not be allowed until NAS goes
to 8.

ERR327: LINE CONTINUATION CHARACTER MUST BE LAST FIELD.

A line continuation character (-) was encountered in a position other
than the last field in the message.

ERR398: INVALID CHARACTER.

An unrecognizable character was received in an FC, FM, or FX message.

ERR399: UNKNOWN SYNTAX ERROR.

A totally unrecognizable message was received.

[]{#__RefHeading___Toc531397230 .anchor}A.2 Packet Header Errors

The following errors may be detected in the packet header line.

ERR402: PACKET ID IS MISSING. USE LLLDDDDDDDDDD.DD

The packet header line does not include a packet ID. A packet ID must be
included in any FD or SS packet.

ERR403: INVALID PACKET ID. USE LLLDDDDDDDDDD.DD

The packet ID does not match the specified syntax.

ERR404: NO MESSAGES IN PACKET.

The packet contains no SS messages.

ERR405: UNKNOWN PACKET CODE. USE FD/SS/RQ.

The packet contains an invalid packet code in the header line. Use SS
for Simplified Substitution messages or RQ for Simplified Substitution
report requests submitted over ARINC-ADNS.

ERR406: PACKET CODE LINE MISSING. USE FD LLLDDDDDDDDDD.DD

The packet has no header line. For FD packets, use FD followed by a
space and the packet ID. For SS packets, use SS followed by a space and
the packet ID. For RQ packets, use only the literal string RQ.

ERR407: UNKNOWN HUB SITE ARINC ADDRESS.

The packet was sent to the wrong address.

[]{#__RefHeading___Toc531397231 .anchor}A.3 SS Error Messages

The following are errors specific to the content of the SS messages.

ERR 412: ILLEGAL HOLD FLAG VALUE: USE R OR H

Valid values for Hold Flag are H to hold slot or R to release slot.

ERR 413: NOT AUTHORIZED TO SUB FOR THESE FLIGHTS

At least one flight in this packet belongs to a carrier for which the
sender is not authorized to make substitutions at this airport. Sender
must be authorized to submit substitutions for all flights referenced in
an SS packet.

ERR414: CANNOT CANCEL A NON-CONTROLLED FLIGHT

An FX message submitted in an SS packet must pertain to a controlled
flight. A non-controlled flight may only be cancelled in an FD packet.
The most common cause for this error is an incorrect flight ID, origin,
destination, or original gate departure date and time.

ERR416: CTA NOT WITHIN 20-MINUTE WINDOW

CTA must be no earlier than the slot time for the flight's assigned
slot, and no more than 20 minutes later than the slot time.

ERR417: CANNOT SUB INTO SLOT NOT OWNED BY THIS CARRIER

The FM message references a slot that does not currently belong to the
sending airline or one of its authorized affiliates.

ERR418: CANNOT SUB TWO FLIGHTS IN ONE SLOT

Packet contains FM messages that assign more than one flight to the same
slot. Only one flight may be assigned to a slot.

ERR419: CANNOT SUB ONE FLIGHT IN TWO SLOTS

Packet contains FM messages that assign a flight to more than one slot.
A flight may be assigned to only one slot.

ERR420: CANNOT SUB A NON-CONTROLLED FLIGHT

Cannot use an FM message to assign a flight to a slot if the flight does
not already have a slot assignment. This message is generated if the
flight referenced in an FM does not exist in the ETMS flight database,
or if it exists but is not currently controlled. The most common cause
for this error is an incorrect flight ID, origin, destination, or
original gate departure date and time.

ERR421: CANNOT CONTROL FLIGHT SCHEDULED TO ARRIVE DURING GDP

An SC message can be used to create a slot and assign it to a flight
only if the flight is scheduled to arrive after the GDP end time is
over.

ERR422: SLOT NOT OWNED BY FLIGHT IN THIS PACKET

In order to preserve the one-flight-one-slot rule, every slot that is
assigned in an SS packet must be assigned to another flight in that
packet prior to the packet being processed.

ERR423: CANNOT SUB INTO SLOT OCCUPIED BY FORMER POPUP FLIGHT

Flight cannot be assigned to an earlier slot if the flight currently
assigned to that slot was formerly a popup.

ERR424: AIRPORT NOT CONTROLLED

A HOLD ALL SLOTS or RELEASE ALL SLOTS message was received for an
airport that does not currently have a GDP.

ERR425: CANNOT CHANGE HOLD FLAG FOR NON-CONTROLLED FLIGHT

Cannot modify hold flag for flight that does not have an assigned slot
in a GDP. The most common cause for this error is an incorrect flight
ID, origin, destination, or original gate departure date and time.

ERR426: CANNOT SUB POP-UP FLIGHT

Cannot assign a popup flight to a slot. Only compression may assign a
popup to a slot, after which the flight is referred to as a former
popup.

ERR427: CONTROL INFO MISSING. SPECIFY: DEP.TIME, ARR.TIME, AND SLOT

CTD, CTA, and ASLOT fields are required in an FM message submitted in an
SS packet.

ERR428: SLOT TIME CANNOT BE IN THE PAST

A flight cannot be assigned to a slot whose slot time is earlier than
the current time.

ERR429: CANNOT SUB COMPLETED FLIGHT

Cannot modify slot assignment for a completed flight.

ERR430: CANNOT SUB MULTIPLE AIRPORTS

All messages in an SS packet must pertain to flights arriving at the
same airport.

ERR431: CANNOT SEND FC MESSAGE IN SS PACKET

Flights cannot be created in an SS packet. An FC message may only be
submitted in an FD packet.

ERR432: SC CAN BE SENT ONLY IN SS PACKET

Slots cannot be created in an FD packet. An SC message may only be
submitted in an SS packet.

ERR433: CANNOT CREATE SLOT FOR CONTROLLED FLIGHT

Flight referenced in SC message is already controlled. Cannot use SC
message to create a slot and assign a flight to the newly created slot
if the flight already has an assigned slot or an FA Delay.

ERR434: SLOT ALREADY EXISTS

The slot value provided in SC message already exists. A newly created
slot must have a unique slot identifier. An airline can generally create
a unique identifier by changing the suffix letter in the slot name.

ERR435: CANNOT USE SIMPL SUB MSG AFTER OLD STYLE SUB MSG

Until transition to Simplified Substitution messages is complete,
airlines may submit substitutions using either the new SS messages or
the old SI messages. However, once an airline has submitted an SI
message, it must continue to use SI messages for the remainder of that
GDP.

ERR436: SLOT IN SC MSG CANNOT BE DURING CURRENT GDP

Slot time for newly created slot falls in the current GDP timeframe. For
an airline to create a slot, the slot time portion of the "Assigned
Arrival Slot" field in the SC message must specify a time that is after
the GDP is over.

ERR437: ETE CANNOT BE CHANGED BY MORE THAN 50%

The new ETE, derived by subtracting CTD from CTA, cannot change from the
prior ETE by more than 45 minutes or 50% of the prior ETE, whichever is
greater.

ERR438: SUB PROCESSING IS OFF

Command Center is currently not accepting substitution messages
pertaining to this GDP. ETMS will send an ETMS SUBS ON message when it
resumes accepting substitution messages.