# FEDERAL AVIATION ADMINISTRATION

# AIR TRAFFIC CONTROL SYSTEM COMMAND CENTER

# Interface Control Document for 

# Substitutions during Ground Delay Programs, 

# Ground Stops, and Airspace Flow Programs

# Version 3.1

# 

# November 6, 2006

# NOTICE

This document includes new functionality to be issued in ETMS release
(8.3) scheduled to be deployed in October 2006. It should not be used as
a guide for how to interact with the operational ETMS prior to that
date.

**TABLE OF CONTENTS**

[1. INTRODUCTION 4](#__RefHeading___Toc150577452)

[1.1 Changes for Version 3.0 5](#__RefHeading___Toc150577453)

[1.2 Changes for Version 3.1 5](#__RefHeading___Toc150577454)

[2. OVERVIEW OF GDPs, GSes, AND AFPs 6](#__RefHeading___Toc150577455)

[3. ISSUING AND MAINTAINING GDPs, GSes, AND AFPs
6](#__RefHeading___Toc150577456)

[3.1 Slot Lists 6](#__RefHeading___Toc150577457)

[3.2 Unsolicited Messages 9](#__RefHeading___Toc150577458)

[3.3 Delay Computation for Pop-ups 9](#__RefHeading___Toc150577459)

[3.4 Precedence of GDPs and AFPs 10](#__RefHeading___Toc150577460)

[3.5 Adaptive Compression 11](#__RefHeading___Toc150577461)

[4. USER SUBSTITUTIONS 11](#__RefHeading___Toc150577462)

[4.1 Substitution Message Usage 13](#__RefHeading___Toc150577463)

[4.1.1 Re-assigning Flights to Slots 13](#__RefHeading___Toc150577464)

[4.1.2 Updating Other Data About a Controlled Flight.
13](#__RefHeading___Toc150577465)

[4.1.3 Canceling Flights 14](#__RefHeading___Toc150577466)

[4.1.4 Drop-out Flights 14](#__RefHeading___Toc150577467)

[4.1.5 Slot Credit Substitutions 15](#__RefHeading___Toc150577468)

[4.1.6 Managing Open Slots: The Hold Flag
16](#__RefHeading___Toc150577469)

[4.1.7 Creating Slots for Uncontrolled Flights
17](#__RefHeading___Toc150577470)

[4.1.8 Substituting Pop-up Flights 17](#__RefHeading___Toc150577471)

[4.1.9 Error Processing 18](#__RefHeading___Toc150577472)

[4.2 Substitution Message Formats 20](#__RefHeading___Toc150577473)

[4.2.1 Substitution Packets 20](#__RefHeading___Toc150577474)

[4.2.2 FM Message 20](#__RefHeading___Toc150577475)

[4.2.3 FX Message 21](#__RefHeading___Toc150577476)

[4.2.3 SCS Message 21](#__RefHeading___Toc150577477)

[4.2.5 SC Message 22](#__RefHeading___Toc150577478)

[4.2.6 Hold All Slots 23](#__RefHeading___Toc150577479)

[4.2.7 Release All Slots 23](#__RefHeading___Toc150577480)

[4.2.8 Bridging Off 23](#__RefHeading___Toc150577481)

[4.2.9 Bridging On 23](#__RefHeading___Toc150577482)

[4.2.10 Message Field Descriptions 23](#__RefHeading___Toc150577483)

[4.3 Substitution Message Replies 25](#__RefHeading___Toc150577484)

[4.3.1 Good Response 25](#__RefHeading___Toc150577485)

[4.3.2 Error Response 26](#__RefHeading___Toc150577486)

[5. TERMINATING A GDP OR AFP 26](#__RefHeading___Toc150577487)

[6. REPORTS 27](#__RefHeading___Toc150577488)

[6.1 Report Requests 27](#__RefHeading___Toc150577489)

[6.2 Report Formats 27](#__RefHeading___Toc150577490)

[6.2.1 EDCT LIST 27](#__RefHeading___Toc150577491)

[6.2.2 EDCT SUB SHOW 30](#__RefHeading___Toc150577492)

[6.2.3 EDCT SLIST 31](#__RefHeading___Toc150577493)

[7. UNSOLICITED MESSAGES 32](#__RefHeading___Toc150577494)

[7.1 Substitution Status 32](#__RefHeading___Toc150577495)

[7.2 GDP Termination 32](#__RefHeading___Toc150577496)

[7.3 EDCT Update 33](#__RefHeading___Toc150577497)

[7.4 DAS Delay 33](#__RefHeading___Toc150577498)

[7.5 GAAP Slot Assignment 33](#__RefHeading___Toc150577499)

[7.6 SCS Bridging Update 34](#__RefHeading___Toc150577500)

[7.7 ECR Update 34](#__RefHeading___Toc150577501)

[7.8 SCS Status 34](#__RefHeading___Toc150577502)

[7.9 Drop-out Flight 34](#__RefHeading___Toc150577503)

[7.10 Re-control 35](#__RefHeading___Toc150577504)

[7.11 Substitutions 35](#__RefHeading___Toc150577505)

[7.12 Hold/Release Slots 36](#__RefHeading___Toc150577506)

[7.13 Timeout Cancelled Flight 36](#__RefHeading___Toc150577507)

[7.14 Reinstated Flight 37](#__RefHeading___Toc150577508)

[7.15 Flight ID Change 37](#__RefHeading___Toc150577509)

[7.16 Diverted Flights and Diversion Recoveries
37](#__RefHeading___Toc150577510)

[7.17 Adaptive Compression Update 38](#__RefHeading___Toc150577511)

[7.18 Scope Reduction 38](#__RefHeading___Toc150577512)

[8. COMMUNICATIONS PROTOCOLS 39](#__RefHeading___Toc150577513)

[8.1 ARINC/ADNS 39](#__RefHeading___Toc150577514)

[8.2 CDMNET 39](#__RefHeading___Toc150577515)

[8.2.1 Session Protocol 39](#__RefHeading___Toc150577516)

[8.2.2 Message Protocol 40](#__RefHeading___Toc150577517)

[8.2.3 Error Handling 42](#__RefHeading___Toc150577518)

[9. BECOMING A PARTICIPANT 43](#__RefHeading___Toc150577519)

[Appendix A. SS ERROR RESPONSES 45](#__RefHeading___Toc150577520)

[A.1 Message Validation Errors 45](#__RefHeading___Toc150577521)

[A.2 Packet Header Errors 46](#__RefHeading___Toc150577522)

[A.3 SS Error Messages 47](#__RefHeading___Toc150577523)

[]{#__RefHeading___Toc150577452 .anchor}1. INTRODUCTION

Ground Delay Programs (GDPs) and Ground Stops (GSes) are traffic
management initiatives used to strategically manage arrivals at an
airport by controlling the departure times of flights going to that
airport. The programs delay departures in a manner so that the arrivals
can be handled by the destination airport and airspace. A GDP is run in
two cases: when the capacity of an airport is reduced, e.g., due to
weather, and cannot handle the normal demand; or when the demand at an
airport will be unusually high, e.g., due to a local convention, and
will exceed the normal capacity.

Airspace Flow Programs (AFPs) are similar to GDPs in that they attempt
to meet a desired arrival rate by controlling departure times. However,
AFPs control flights arriving at a Flow Constrained Area (FCA) rather
than an airport. An AFP might be used, for example, to reduce the flow
rate of flights through a center when that center has reduced en route
capacity due to severe weather.

A critical component of an AFP is the FCA. An FCA should be thought of
as a filter for selecting a group of flights operating in the NAS. Some
examples are: flights flying certain routes destined for certain
airports or centers; flights traversing a center in an easterly
direction; or flights traversing a particular sector. The FCA tool is
extremely flexible and allows almost any set of flights to be defined.
An FCA always has a physical basis, e.g., a line segment between two
points, an area of airspace, a center, or a sector. The arrival rate for
an AFP applies to the rate at which flights should intersect the
boundary of the FCA.

GDPs, GSes, and AFPs only work if they are communicated in detail to the
users, and if the users have flexibility is controlling how the program
affects their operations. The substitution process provides a way for
airspace users, henceforth referred to as users, to manage their flights
during a GDP, GS or AFP. Users can, for example, swap slots between a
high priority flight and a less important flight, reducing the delay on
one and the cost of increasing the delay for another.

There are two primary tools used by the FAA to issue and manage GDPs,
GSes, and AFPs:

-   Flight Schedule Monitor (FSM) -- FSM is the used to view airport or
    airspace demand, model GDPs, GSes, and AFPs, and initiate the
    sending of the program.

-   Enhanced Traffic Management System (ETMS) -- ETMS is the underlying
    database and communications system for traffic management. ETMS
    produces demand data, applies control times to the data, processes
    user substitutions, and generates user reports.

    The main purpose of this document is to describe the formatting and
    usage of the various messages that are exchanged between ETMS and
    users to substitute flights during a GDP, GS, or AFP. The document
    attempts to provide enough background to get the novice user
    started, but more thorough descriptions of various GDP, GS, and AFP
    topics can be found on the FAA website at
    [http://www.fly.faa.gov/Products/NASDOCS/nasdocs.jsp](http://www.fly.faa.gov/Products/NASDOCS/nasdocs.jsp )
    and on the CDM website at: http://cdm.metronaviation.com.

    This document is organized as follows.

    Section 1 -- Introduction

    Section 2 -- Overview of GDPs, GSes, and AFPs

    Section 3 -- How GDPs, GSes, and AFPs are issued

    Section 4 -- The usage and formatting of substitution messages

    Section 5 -- Requesting reports

    Section 6 -- Other GDP, GS, and AFP messages sent by ETMS

    Section 7 -- Protocol for using ARINC/ADNS or CDMNET

    Section 8 -- How to become a participant in the substitution process

    Appendix A --Substitution error messages

[]{#__RefHeading___Toc150577453 .anchor}1.1 Changes for Version 3.0

First, the title of the document has changed. The file name and document
name for the previous version were:

-   SSDOC_for_FAA_v_2_3.doc

-   GROUND DELAY PROGRAM, AIRSPACE FLOW PROGRAM, AND SUBSTITUTION
    MESSAGE PROCESSING

The file name and document name for the new version are:

-   ICD for Substitutions during GDPs and AFPS v3.0.doc

-   Interface Control Document for Substitutions during Ground Delay
    Programs, Ground Stops, and Airspace Flow Programs version 3.0

Version 3.0 includes changes being implemented in ETMS release 8.3.
These changes fall into three areas.

-   New unsolicited messages -- New message will be sent from ETMS to
    connected users to help ensure that all changes in control times or
    to the status of controlled flights are being sent to the users.
    These changes are documented in Sections 7.11 through 7.16.

-   Adaptive Compression -- Several changes are being made to the
    outgoing messages to support adaptive compression. See sections 3.5,
    7.6, and 7.17.

-   GDP, GS, and AFP Scope Reduction -- FSM and ETMS are being enhanced
    to allow the scope of an existing GDP, GS, or AFP to be reduced.
    When this happens, new message will be sent to the users indicated
    previously controlled flights that are no longer controlled. The new
    message is described in section 7.18.

Another change has to do with airport names. While this is not really a
change to ETMS, the document now emphasizes that airport names can
include both letters and numbers. This includes the airport name
embedded in an assigned arrival slot.

Various correction and additions were made to address existing
shortcomings in the report. Section 4.2.1 was added to describe the
packet header format. Various section references were fixed.

[]{#__RefHeading___Toc150577454 .anchor}1.2 Changes for Version 3.1

Version 3.1 of this document corrects an omission in version 3.0. The
EDCT LIST and EDCT SUB SHOW report formats for 8.3 include new
information showing the status of adaptive compression. Sections 6.2.1
and 6.2.2 have been changed to show the new report format.

[]{#__RefHeading___Toc150577455 .anchor}2. OVERVIEW OF GDPs, GSes, AND
AFPs

The essentials of the GDP/GS/AFP/substitution process are:

1.  The FAA determines that a GDP, GS, or AFP is needed and models the
    program using FSM driven by ETMS data.

2.  FSM divides the airport or airspace capacity into named arrival
    slots that are spaced out to achieve the acceptance rate desired by
    the FAA. An arrival slot can be allocated for an arrival airport
    (GDP or GS) or for an FCA (AFP). For an FCA, the arrival slot
    identifies the time that flight should first cross the boundary of
    the FCA.

3.  FSM then assigns the arriving flights to the slots. FSM orders
    flights by the Initial Gate Time of Arrival (IGTA) and assigns
    exempt flights first. For each flight, FSM computes the CTD required
    to "hit the slot" using the current Estimated Time Enroute (ETE).
    \[NOTE: The ETE in this context means the flying time from the
    departure airport to the element, i.e., airport or FCA, being
    controlled.\] This assignment includes assigning slots to cancelled
    flights, thus preserving slots to which the users are entitled.

4.  The FAA then issues the GDP, GS, or AFP, sending the user a list of
    its controlled flights, the arrival slots to which they have been
    assigned, and the CTDs required to hit those slots.

5.  The user can then re-assign its controlled flights to its assigned
    arrival slots in a flexible manner using the substitution process.

6.  The user may cancel flights involved in the GDP or AFP. Cancelled
    flights continue to "own" slots and appear in the data, making it
    easy to track and swap the open slots.

7.  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, GS, or AFP on the user.

8.  Pop-up flights, that is, flights arriving at the arrival airport or
    FCA during the program time interval that did not get control times
    in the original computation, are assigned control times as they
    appear. The manner as assigning delay depends on the delay
    assignment mode chosen for the GDP or AFP.

9.  FAA may choose to re-issue the GDP or AFP in several ways: e.g.,
    compression, which fills in slots that might go unused, or revision
    to change parameters such as the end time or the acceptance rate.

10. ETMS monitors the program for slots that are at risk of going
    unused. ETMS attempts to move those slots to later times when they
    are more likely to be used. This process is known as *adaptive
    compression*

11. The process continues iteratively until such time that the program
    is cancelled, because it is not longer needed, or the program
    expires.

[]{#__RefHeading___Toc150577456 .anchor}3. ISSUING AND MAINTAINING GDPs,
GSes, AND AFPs

[]{#__RefHeading___Toc150577457 .anchor}3.1 Slot Lists

When a GDP, GS, or AFP is issued or revised, the user 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, GS, or AFP for that user,
including flights that have been cancelled. If the user performs
substitutions for any affiliates using different three-letter codes
(e.g., if user ABC also subs for user DEF), their list will include all
flights for which they can substitute. A new, complete set of lists is
sent every time the FAA modifies a GDP, GS, or AFP. The user may submit
substitution messages only for flights that have been issued in a slot
list.

Due to line length constraints, a different slot list format is used
over ARINC/ADNS than for CDMNET. The full slot list is sent over CDMNET.
A shortened record is sent to ARINC/ADNS addresses.

A sample, full, CDMNET slot list for a GDP at an airport follows:

FOR LGA DESTINATION AIRPORT

ATCSCC EDCT FLOW CONTROL DEPARTURE TIME

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH ERTA IGTD

ABC1234 LGA.260400A DCA LGA 260300 260400 GDP - - - 260400 260245

ABC5678 LGA.260500A IAD LGA 260400 260500 GDP - - - 260300 260145

ABC3601 LGA.260323A BOS LGA 260206 260323 GDP Y - - 260319 260150

ABC3522 LGA.260311A DCA LGA 260215 260311 GDP - - - 260311 260145

ABC3994 LGA.260353A ROC LGA 260246 260353 AFP - Y - 260355 260235

A sample, full, CDMNET slot list for an AFP for an FCA follows:

FOR FCAA02

ATCSCC EDCT FLOW CONTROL DEPARTURE TIME

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH EENTRY IGTD

ABC1234 FCAA02.260400A DCA LGA 260300 260400 AFP - - - 260400 260245

ABC5678 FCAA02.260500A IAD BOS 260400 260500 AFP - - - 260300 260145

ABC3601 FCAA02.260323A BOS LGA 260206 260323 AFP Y - - 260319 260150

ABC3522 FCAA02.260311A DCA BOS 260215 260311 AFP - - - 260311 260145

ABC3994 FCAA02.260353A ROC LGA 260246 260353 AFP - Y - 260355 260235

Following is a description of the data in the full slot list.

Line 1: Identifies the GDP airport (LGA) or the AFP FCA (FCAA02).

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, N750CC). Flight identifier as it
> appears or will appear on the NAS flight plan.
>
> Field 2: Arrival Slot; the time slot that has been reserved at the
> airport or FCA for this flight to arrive (e.g., LGA.260400A,
> FCAA02.260400A). The format is a concatenation of airport or FCA name,
> slot date and time, and a one-letter suffix. An airport name can be
> three or four characters and can include letters and numbers. An FCA
> name must be the letters "FCA" followed by three digits. The name is
> separated from the date time by a dot for readability. 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: Arrival Airport (e.g., LGA). \[Note: For a GDP, the arrival
> airport will be the same for every flight; for an AFP, they may
> differ.\]
>
> Field 5: 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 6: Controlled Time of Arrival (CTA); the time the flight should
> arrive at the controlled airport or FCA (e.g., 260400). The format is
> a concatenation of day-hour-minute.
>
> Field 7: 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:
>
> ABRG -- Control times were assigned when creating a bridge in order to
> *adaptive compress* a slot.
>
> AFP -- Control times were computed as part of an initial AFP, a
> revision to an AFP, or an extension to an AFP.
>
> BLKT -- Control times were computed by a blanket program.
>
> COMP -- Control times were computed by compression.
>
> DAS -- Control times are from a DAS delay being assigned to a pop-up
> flight.
>
> ECR -- Control times were assigned by an FAA ECR request.
>
> GAAP -- Control times are from an unassigned slot being assigned to a
> pop-up flight.
>
> GDP -- Control times were computed as part of an initial GDP, a
> revision to a GDP, or an extension to a GDP.
>
> GS -- Control times were computed by a ground stop.
>
> RCTL -- Control times are from a DAS delay but the flight is a
> re-controlled flight from a purged AFP or GDP and therefore has full
> subbing rights.
>
> SBRG -- Control times were assigned when creating a bridge for an SCS
> or ECR request.
>
> SCS -- Control times were assigned by a user slot credit substitution
> message.
>
> SUB -- Control times were assigned by a conventional user substitution
> message.
>
> UPD -- Control times are from an FAA "EDCT UPDATE" command.
>
> Field 8: Exempt Flag; indicates the flight was exempt from delays when
> the GDP or AFP was computed. Format is "Y" if true, "-" if false.
>
> Field 9: Cancel Flag; indicates whether the flight is currently
> cancelled. Format is "Y" if true, "-" if false.
>
> Field 10: Slot Hold Flag; indicates whether a slot belonging to a
> cancelled flight is being held by the user for substitution. Format is
> "Y" if true, "-" if false.
>
> Field 11: Earliest Runway Time of Arrival (ERTA) or Earliest Entry
> Time (EENTRY): the earliest time flight can arrive at the controlled
> airport element in the case that the delays are reduced (e.g.,
> 260200). ERTA will be included for a GDP; EENTRY for an AFP.
>
> Field 12: 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.

A sample, truncated, ARINC/ADNS slot list for a GDP at an airport
follows:

FOR LGA DESTINATION AIRPORT

ATCSCC EDCT FLOW CONTROL DEPARTURE TIME

ACID ASLOT DEP ARR CTD CTA TYPE EX CX IGTD

ABC1234 LGA.260400A DCA LGA 260300 260400 GDP - - 260245

ABC5678 LGA.260500A IAD LGA 260400 260500 GDP - - 260145

ABC360 LGA.260323A CYYZ LGA 260206 260323 GDP Y - 260150

ABC3522 LGA.260311A DCA LGA 260215 260311 GDP - - 260145

ABC39 LGA.260353A ROC LGA 260246 260353 GDP - Y 260235

A sample, truncated, ARINC/ADNS slot list for an AFP for an FCA follows:

FOR FCAA02

ATCSCC EDCT FLOW CONTROL DEPARTURE TIME

ACID ASLOT DEP ARR CTD CTA TYPE EX CX IGTD

ABC1234 FCAA02.260400A DCA LGA 260300 260400 AFP - - 260245

ABC5678 FCAA02.260500A IAD BOS 260400 260500 AFP - - 260145

ABC360 FCAA02.260323A CYYZ LGA 260206 260323 AFP Y - 260150

ABC3522 FCAA02.260311A DCA BOS 260215 260311 AFP - - 260145

ABC39 FCAA02.260353A ROC LGA 260246 260353 AFP - Y 260235

The meaning of the fields is the same as for the full list.

A user can request a current slot list at any time over ARINC/ADNS or
the CDMNET. The requested list will show the state of the data at the
time of the request; that is, it will include the latest times as a
result of substitutions and other changes. The format of the requested
slot list is the same as the issued slot list except for differences in
the header. The report request/reply is described in Chapter 6.

[]{#__RefHeading___Toc150577458 .anchor}3.2 Unsolicited Messages

Once a GDP, GS, or AFP is in place, control times can change and new
flights can appear. Whenever there is a change to a flight that is not
in response to a substitution request by the responsible user, a message
is sent out to the user notifying them of the update. These messages,
known as unsolicited messages, also use the slot list data format. They
can be programmed to go either to ARINC addresses or over the CDMNET.
Chapter 7 describes the unsolicited messages.

[]{#__RefHeading___Toc150577459 .anchor}3.3 Delay Computation for
Pop-ups

A pop-up flight is defined as a flight that is planned to arrive during
the time period of a GDP or AFP, but which did not exist when the GDP or
AFP was issued. Pop-up flights are generally created from a flight plan
that is filed after the GDP or AFP was sent. Some examples of pop-up
flights are:

-   A flight plan filed for a flight that did not exist at all in the
    ETMS database when the GDP or AFP was computed.

-   A flight plan filed for an existing flight that takes it through an
    FCA that has an AFP, whereas the previous route did not take that
    flight through the FCA.

-   A flight that was exempt from an AFP because it was in a GDP, but
    now the GDP is purged.

Special mechanisms have been built for assigning control times to pop-up
flights. The mechanism used is determined by the delay assignment mode
chosen by the FAA when the GDP or AFP was issued. The choice of
mechanism can affect whether the user can substitute that flight. The
two choices are *DAS Mode* and *GAAP Mode*. The substitution processing
for pop-ups is described in section 4.1.8.

[DAS Mode]{.underline}

The default mode for a GDP or AFP is Delay Assignment (DAS) mode. When
DAS mode is selected, ETMS assigns equitable delays to the pop-up
flights regardless of whether there is available capacity at the
resulting arrival time. The equitable delay is, roughly speaking, the
average delay that was assigned to known flights wanting to arrive
during the same 15-minute interval as the pop-up. A pop-up flight that
is new to the database is identified in a slot list by having a control
type of "DAS".A pop-up flight that is due to another program being
purged or a flight routing from one AFP to another is identified in a
slot list by having a control type of "RCTL". (NOTE: A DAS flight has
subbing restrictions while a RCTL flight can be subbed fully. See
section 4.1.8 for details.)

[GAAP Mode]{.underline}

The other alternative is GAAP mode. GAAP mode is used when the demand
does not exceed the capacity at the time the GDP or AFP is computed, but
is expected to exceed the capacity later due to a large number of
expected pop-ups. (The pop-ups are sometimes GA traffic, leading to the
phrase GA Arrival Program, leading the name GAAP.) In GAAP mode, there
are open slots at the time the GDP or AFP is computed; these are
referred to as *unassigned slots*. When a pop-up appears, it will get
the first available unassigned slot at or after its desired arrival
time. If a slot is available, it is assigned to the flight, an
appropriate CTD and CTA are computed, and the control type is set to
"GAAP".

To ensure that the assigned delays do not get too large, the search for
an unassigned slot stops when the del\\ay reaches a *delay limit*. If
the search hits the delay limit, the flight is treated as if in DAS mode
with the assigned delay being equal to the delay limit. In this case,
the control type will be "DAS" and the flight is restricted for subbing,
as described in the above section titled *DAS Mode*.

[]{#__RefHeading___Toc150577460 .anchor}3.4 Precedence of GDPs and AFPs

If an AFP or GDP is issued at the same time that a GDP or another AFP is
in effect, it is possible that it could include a flight that has
already been controlled be the existing GDP or AFP. For example, a
flight destined for EWR could be controlled by an AFP over ZOB, then a
GDP could be issued for EWR. In this case, the FAA will determine
whether the new AFP or GDP should have precedence over the old. The
precedence rules are as follows:

-   A GDP will always have precedence over any AFP no matter what order
    they are issued. (Note: A flight can only be affected by one GDP at
    a time, as it can have only one destination.)

-   An AFP will normally exclude flights that were controlled by a
    previous AFP.

-   The FAA will have the option, if needed, to issue an AFP that
    overrides previous AFPs.

The user will know the precedence for a flight by examination of the
slot list. Assume there is a flight that has already been controlled and
is a candidate to be part of a new AFP or GDP. When the new slot list is
issued, it will either include this flight or not. If it includes the
flight, it means that the new AFP or GDP has been given precedence over
the previous AFP. If it does not include the flight, it means that the
previously issued controls still apply to that flight. If the new slot
list includes the flight, the user should conclude that the previous
control data is now void and has been replaced by the new control data.
The important points to note are:

-   A flight can only be controlled by one GDP or AFP at a time

-   The controlling element (i.e., the airport or FCA for which the
    program was issued) may change.

As a result of the above, it is important to monitor what the
controlling element is for a flight. This can be detected in two ways:

-   Any message sent with control times will include the name of the
    controlling element in the first line of the header; for example:
    "DAS DELAY FOR LGA" or "DAS DELAY FOR FCAA02".

-   The assigned slot for each flight includes the name of the
    controlling element; for example, LGA.061745A or FCAA02.281745B.

[]{#__RefHeading___Toc150577461 .anchor}3.5 Adaptive Compression

Adaptive compression is a process designed to ensure that slots in a GDP
or AFP do not go unused. A slot could potentially go unused in two
cases:

-   The flight assigned to the slot will arrive too late to use the
    slot.

-   The flight assigned to the slot is cancelled.

In either case, the user who "owns" the slot could rectify the situation
through substitutions. Or, the FAA could rectify it by compression or
revising the program. However, due to a variety of reasons, this does
not always happen. To avoid wasted capacity and unnecessary capacity,
ETMS continuously monitors each program to see whether a slot is at risk
of going unused. If so, ETMS attempts to move the slot back to a time
when it can still be used. ETMS does so by selecting other flights to
depart earlier, thus providing delay reduction benefits to other
flights. ETMS selects the flight to move earlier in a manner to give the
maximum delay reduction benefit to the user whose slot is being
compressed. ETMS sends notifications to all affected users notifying
them of any changes to their control times. The messages sent by ETMS to
the users are described in section 7.

[]{#__RefHeading___Toc150577462 .anchor}4. USER SUBSTITUTIONS

Substitution messages allow a user to trade arrival slots between their
flights, including cancelled flights. Substitutions allow a user to
reduce delay for a high priority flights at the expense of more delay
for another flight, or to cancel a flight and reduce delay for a number
of other flights.

Requests for 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
substitution (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 for a GDP has the following format:

SS ABC0626021029.01

FX ABC1234 DCA LGA 06260145

FM ABC1234 DCA LGA 06260145 T5 260400 T6 260500 A2 LGA.260500A

FM ABC5678 IAD LGA 06260245 T5 260300 T6 260400 A2 LGA.260400A

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 substitution (SS) packet sent by
> user ABC on June 26^th^ at 02:10:09Z. (The ".01" can be set to
> whatever the user wishes.)
>
> The "FX" line cancels flight ABC1234 from DCA to LGA originally
> departing on June 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) "LGA.260500A".
>
> 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) "LGA.260400A".

The net effect is the flight 1234 is cancelled and flight 5678 has a
one-hour delay reduction.

An SS message for an AFP has the same format, as seen in the following
sample:

SS ABC0626021029.01

FX ABC1234 DCA LGA 06260145

FM ABC1234 DCA LGA 06260145 T5 260400 T6 260500 A2 FCAA02.260500A

FM ABC5678 IAD BOS 06260245 T5 260300 T6 260400 A2 FCAA02.260400A

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 user 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 user can set the suffix to any desired two digits.

**NOTE**: If the packet is sent over the CDMNET, the user 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.
>
> SCS -- Slot Credit Substitution message; conditionally exchanges a
> slot that a flight cannot use for a slot the flight can use. Only has
> an effect if ETMS is able to swap the existing slot to a new, usable
> time range.
>
> 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 a user 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 user that are currently controlled and cancelled. Used to
> preserve the position of all a user's open slots during the next
> compression.
>
> RELEASE ALL SLOTS -- Releases the hold flag for all flights belonging
> to the sending user that are currently controlled and cancelled. Used
> to tell ETMS to make maximum use of all of a user's open slots during
> the next compression.

The format for each of these is described in section 4.2.

[]{#__RefHeading___Toc150577463 .anchor}4.1 Substitution Message Usage

The messages within the 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___Toc150577464 .anchor}4.1.1 Re-assigning Flights to
Slots

The main task of substitutions is to re-assign flights to slots; that
is, move one or more flights later in order to decrease the delay on one
or more other flights. 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. If any errors
are discovered in the packet, the entire packet is rejected and no
changes are committed to the ETMS database. The main point of the error
checking is to see that the one-flight-one-slot rule is preserved. That
is, a sub packet contains N flights that are currently assigned to N
slots. After the packet is processed, those N flights must still be
assigned to those same N slots, although in a different order. More
details on the error checking are provided in section 4.1.8.

An FM message must provide the following data:

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

2.  The arrival slot desired for that flight.

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

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

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

[]{#__RefHeading___Toc150577465 .anchor}4.1.2 Updating Other Data About
a Controlled Flight.

Changes to a controlled flight's data other than the control times and
assigned arrival slot are also sent in FM messages. These changes may be
coupled with the control time changes in an SS packet, or sent
independently in a flight data (FD) packet. Data field changes that are
specifically relevant to the GDP are:

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

-   For a non-cancelled flight, the user can use an FM to modify the
    Earliest Runway Time of Arrival (ERTA). The ERTA tells FSM 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 4.2.2

    []{#__RefHeading___Toc150577466 .anchor}4.1.3 Canceling Flights

    A user can cancel a controlled flight using an FX message. Once the
    flight is cancelled, the user can continue to substitute that flight
    like any other flight. Also, the cancelled flight continues to
    appear in the slot list with its current assigned slot. 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
    (the use of the hold flag is described in section 4.1.6).

    An FX message is subjected to the following checks:

```{=html}
<!-- -->
```
-   The user must be authorized to cancel the flight, as determined by
    the sending ARINC or CDMNET address.

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

-   The flight must not be active (airborne) or completed.

-   The flight must not be already cancelled.

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

    []{#__RefHeading___Toc150577467 .anchor}4.1.4 Drop-out Flights

For an AFP, an open slot can be created in another way: a flight might
change its route so that it no longer travels through the FCA or an FCA
might be edited so that a flight no longer meets the FCA definition.
Such a flight is referred to as a dropout. In this case, ETMS considers
the flight to be no longer controlled and cancels the EDCT for the
flight. The flight also loses its slot in the AFP, will no longer appear
in any slot list for that AFP, and can no longer be substituted as part
of that AFP. In the case of a reroute, if the user wishes to obtain any
benefit from the slot for the rerouted flight, they should submit
substitutions for that flight prior to rerouting it out of the FCA.

Several notes about dropout flights:

-   There is no way for the user to indicate that a flight has rerouted
    out of an FCA through a substitution message. The user can only do
    so by filing a new flight plan or submitting an early intent flight
    plan.

```{=html}
<!-- -->
```
-   Once a flight has dropped out of an FCA, the user will get an
    unsolicited message from ETMS telling them that the flight is no
    longer controlled. This message is described in section 7.9.

-   The flight will not appear in subsequent slot lists for that AFP.

There is one exception to the above discussion. If a flight drops out of
one AFP, it might become eligible for another AFP. In this case, the
control for that flight will be transferred to the new AFP and new
control data, including a CTD, CTA and ASLOT, will be assigned. The slot
from the original AFP will be lost. The user will first be notified that
the flight is not controlled by the original AFP, as described in
section 7.9, then will be notified of the new control data through a
RECONTROL message, which is described in section 7.10.

NOTE: To avoid unfairly penalizing or rewarding a re-controlled flight,
the subbing status will be preserved from the previous program. That is,
if the flight could be subbed in the previous program, it can still be
subbed. If the flight was a pop-up in the previous program, it cannot be
subbed. If the flight can be subbed, it will appear in the slot lists
with a new control type of RCTL (re-control).

[]{#__RefHeading___Toc150577468 .anchor}4.1.5 Slot Credit Substitutions

It is common that a slot is open due to the flight in that slot being
either cancelled or delayed. In many cases, the user has another flight
it can swap into that slot using a normal substitution message, as
described in section 4.1.1.

Sometimes, though, the user may not have a flight that can move early
enough to use the open slot. If the FAA runs compression, other flights
will be moved up into the open slot, if possible, to move the open slot
down to a time that the owner of the slot can use. However, this leaves
the user unsure whether that open slot will ever be used. This creates
unnecessary delays, and in the worst case might motivate a user not to
cancel a flight because they are not sure they will get any benefit.

Slot Credit Substitutions (SCS) provide a mechanism for a user to
substitute in these situations by using other users' flights to bridge
the open slot from an unusable time to a time that can be used to the
requester's advantage. The general concept of an SCS is as follows:

1.  A GDP or AFP is in place.

2.  A user identifies an opportunity where they already have an open
    slot at time t0 due to delay or cancellation, or could create an
    open slot at time t0 by canceling a flight (f0), but cannot move
    another flight directly into that slot using a normal substitution.

3.  The user identifies a flight (f1) that they would like to move up,
    and determines the time range (from t1 to t2) in which they would
    like flight f1 to arrive.

4.  The user submits a sub message that says: "I will yield my slot at
    time t0 to the system if I can move flight f1 up into a slot
    sometime from t1 to t2." The requested time range must be later than
    the slot being yielded.

5.  ETMS examines all the available flights in the time range t0 to t2
    to see whether it can create a bridge from the time that the user is
    yielding (t0) to a time that the user can use (somewhere from t1 to
    t2). That is, ETMS tries to move other users' flights earlier to get
    a later slot time for the requesting user.

6.  If a bridge is available, ETMS:

-   Selects one or more flights to be the bridging flights and moves
    them up into to new slots, thus reducing their delay.

-   Assigns the resulting opened slot to flight f1.

-   Updates the ETMS databases to reflect the bridging subs as well as
    the SCS.

-   Sends a reply to the requesting user with the updated slot list for
    its flights.

-   Sends a message to any other users whose flights were used in the
    bridge to notify them of the changes to their control times.

7.  If a bridge is not available, ETMS rejects the SCS and sends a
    suitable error message (NO SLOTS AVAILABLE) back to the requesting
    user.

    A ramification of an SCS message is that any user's flights can get
    moved as part of a bridge at any time. This has two implications:

```{=html}
<!-- -->
```
1.  Users must constantly monitor the unsolicited messages to find out
    about any delay reductions.

2.  If the change occurred while the user was preparing a substitution,
    it could be disruptive to that user. Therefore, two new messages
    were introduced to allow a user to temporarily disable the use of
    their flights as bridging flights. These messages are BRIDGING OFF
    and BRIDGING ON.

    The format of the SCS message is described in section 4.2.4.
    BRIDGING ON and BRIDGING OFF are described in sections 4.2.8 and
    4.2.9.

    []{#__RefHeading___Toc150577469 .anchor}4.1.6 Managing Open Slots:
    The Hold Flag

    When a controlled flight is cancelled, the slot to which it is
    assigned is known as an *open slot*. Also, if a flight diverts away
    from the controlled airport during a GDP, an open slot is created.
    In general, the user who operates that flight has ownership of the
    open slot and can use it to substitute, and reduce delays for, other
    flight. Every effort must be made to ensure that no open slot go
    unused during a GDP or AFP.

    Responsibility for using open slots goes to both the users and the
    FAA. The user can use an open slot be sending in substitutions that
    move other flights to earlier slots and move the open slot to late
    in the program where it has little or no value. The FAA can use open
    slots by running compression or revising the GDP or AFP. In either
    case, FSM identifies open slots and attempts to move them to the end
    of the program in order to reduce delays both for the owner of the
    slot and for other users.

    **NOTE**: The compression algorithm is carefully designed to ensure
    that the user that owns the open slot gets the maximum possible
    delay reduction from that slot. That is, if compression can move the
    open slot to the end of the GDP or AFP by only moving up flights
    belonging to that user, it will. Only in the event that the owning
    user has no flights that can use the open slot will the compression
    algorithm assign another user's flight to the open slot.

    Compression or revision will only move an open slot if the slot has
    been *released* by the user. When a user cancels a flight, it has
    the option of explicitly holding or releasing the slot (the slot is
    released by default). When a flight is diverted, the slot is
    automatically released, although the user can hold the slot be
    sending an additional message. If the user holds the slot, the user
    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 or AFP. If the user releases the slot, it is saying that the
    slot is free for the FAA to manage.

    In order to help ensure that open slots do not go unused, slots are
    automatically released each time a GDP or AFP is compressed or
    revised. That is, when a user holds a slot, that hold is good only
    for the next compression or revision. This makes it less likely that
    a user will hold an open slot then forget to ever use it.

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

```{=html}
<!-- -->
```
4.  A GDP is issued

5.  User cancels a flight and holds the slot.

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

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

8.  User continues to substitute flights using the open slot.

9.  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 a user is done doing substitutions and wishes to
    make all its open slots available for general use, the user can
    issue the "RELEASE ALL SLOTS" message. This has the effect of
    clearing the slot hold flag for all cancelled flights for the
    sending user. The format of the RELEASE ALL SLOTS message is
    described in detail in section 4.2.7.

    When compression is imminent and a user needs more time to complete
    its substitutions, the user 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 user. The format of the HOLD ALL SLOTS message is
    described in detail in section 4.2.6.

    The setting of the hold flag for an individual flight using an FM
    message is describe in section 4.2.2. The setting of the hold flag
    when canceling a flight with an FX message is described in section
    4.2.3.

    []{#__RefHeading___Toc150577470 .anchor}4.1.7 Creating Slots for
    Uncontrolled Flights

    Due to the nature of the GDP and AFP algorithms and procedures, a
    situation can arise where a user is forced to operate scheduled
    flights out of order. Consider an example of a user 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 for IAD 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 user
    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 a user to manage this scenario.
    Using slot create, the user can voluntarily control FLIGHT2,
    creating an arrival slot for it at its normally planned arrival
    time. Once the slot is created, the user can swap the two flights
    using the usual mechanisms described in 4.1.1.

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

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

11. The arrival slot desired for that flight.

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

    The Slot Create message is subjected to the following special error
    checks in addition to those described in section 4.1.8.

13. The flight cannot already be controlled.

14. The arrival slot name cannot already exist.

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

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

[]{#__RefHeading___Toc150577471 .anchor}4.1.8 Substituting Pop-up
Flights

A pop-up flight is defined as a flight that is planned to arrive during
the time period of a GDP or AFP, but which did not exist when the GDP or
AFP was issued. The delay computation for pop-up flights is described in
section 3.3 and varies depending on how the GDP or AFP was issued. The
choice of mechanism can affect whether the user can substitute that
flight. The two choices are *DAS Mode* and *GAAP Mode*.

[DAS Mode]{.underline}

When a flight gets a DAS delay, it does not have a legitimate slot. As a
result, no substitutions are generally allowed for pop-up flights.
Pop-up flights are identified in a slot list by having a control type of
"DAS".

The sole exception to this is when a flight is re-controlled; that is, a
flight is in one AFP or GDP, becomes no longer controlled, perhaps due
to that AFP or GDP being purged, and is now eligible for control in
another AFP. In this case, the flight maintains the subbing status that
it had in the previous AFP or GDP. If the flight was a pop-up in the
prior AFP or GDP, it will still be considered a pop-up and cannot be
used for substitutions. If the flight could be subbed in the prior GDP
or AFP, it can be subbed in the new AFP; in this case, the control type
will be "RCTL" (re-control) to indicate that it is not a normal pop-up.

A more complicated case occurs once the GDP or AFP 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 a user to take unfair advantage
of the system, an additional restriction has been placed on substituting
these *former pop-up* flights. A user can use substitution messages to
move a former pop-up flight earlier in time. However, a user 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 user operating these flights can swap the slots between ABC111 and
ABC222, moving the former pop-up flight earlier in time. However, the
user cannot swap flights ABC222 and ABC333, using the former pop-up slot
to reduce the delay for another flight.

An important distinction must be made between "pop-up" and
"re-controlled" flights. A pop-up flight did not exist at the time a GDP
or AFP was computed. A "recontrolled" flight did exist, but was not
considered to be part of the AFP because it was part of a GDP or a
different AFP. If the flight becomes eligible for an AFP due to another
program being purged, or due to its route moving it from one AFP to
another, the flight is not considered a pop-up. ETMS assigns an average
delay to the flight, as for a pop-up, but gives it a control type of
"RCTL" rather than "DAS". A "RCTL" flight can be subbed with no
restrictions. Only a "DAS" flight is restricted as described in this
section.

[GAAP Mode]{.underline}

In GAAP mode, if a slot is available, it is assigned to the flight, an
appropriate CTD and CTA are computed, and the control type is set to
"GAAP". In this case, the flight has a legitimate slot and so has full
substitution rights. If no open slot can be found, the flight gets a
DAS-like delay and has a control type of "DAS". In this case, the flight
is subject to the same limitations as any other DAS-mode pop-up.

[]{#__RefHeading___Toc150577472 .anchor}4.1.9 Error Processing

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 ETMS database. This avoids
the situation where the user is unsure of what changes did or did not
get applied, or creating an unwanted set of changes, or in the case of
an SCS, applying some changes although an SCS message is rejected.

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

ETMS 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 potential source of errors is lack of synchronization between the user
data and the ETMS data. A report -- EDCT SLIST -- has been provided to
allow a user to request the entire ETMS data for a GDP whenever a
"re-synch" is desired.

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

The flight-specific error checks are as follows:

16. The user must be authorized to modify all flights in the packet, as
    determined by the sending ARINC or CDMNET address. A user is
    authorized to modify its own flights and sometimes those of
    affiliated "sub-carriers". The authorization may be defined in
    several ways.

    1.  A user may be authorized to sub any flight for a certain
        three-letter code (e.g., all AAL flights).

    2.  A user may be authorized to sub flights for a certain
        three-letter code in a specified time range (e.g., ASH flights
        from 1000 to 1999).

    3.  A user may be authorized to sub flights in a list of specific
        flight IDs (e.g., N123CD, N750CC, ...)

17. All slots specifically identified in the packet must have previously
    been assigned to the user by ETMS in a slot list or unsolicited
    updates, or created by the user via a valid Slot Create message.

18. Each flight must have appeared in a slot list or unsolicited update
    issued by ETMS, or have been controlled by the user using a Slot
    Create message.

19. All flights in a sub packet must be controlled by the same GDP or
    AFP. You cannot swap slots between a flight in an AFP and a flight
    in a GDP, or between flights in two different AFPs.

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

21. The ETE for each flight, 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:

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

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

    **NOTE**: The ETE used for this check is the flying time from the
    departure airport to the controlled element. For a GDP, the
    controlled element is the arrival airport, so the ETE corresponds to
    the conventional notion. For an AFP, the ETE used for the error
    check does not correspond to the entire flying time.

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

[]{#__RefHeading___Toc150577473 .anchor}4.2 Substitution Message Formats

1.  []{#__RefHeading___Toc150577474 .anchor}Substitution Packets

Any substitution message must be sent as part of a packet. A
substitution packet consists of a packet header line followed by one or
more substitution messages. There is no explicit terminator for the
packet.

A sample substitution packet has the following format:

SS ABC0626021029.01 ABCDEFG

FX ABC1234 DCA LGA 06260145

FM ABC1234 DCA LGA 06260145 T5 260400 T6 260500 A2 LGA.260500A

FM ABC5678 IAD LGA 06260245 T5 260300 T6 260400 A2 LGA.260400A

The packet header line is the first line beginning with "SS". The packet
header line has the following meaning:

SS -- Packet type. (Required)

> ABC0626021029.01 -- Packet ID consisting of a concatenation of the
> user three-letter code, the date-time (MMDDHHMMSS), ".", and two-digit
> suffix. The date-time should be the date and time at which the message
> was sent. A suffix should be attached to make the packet ID unique.
> (NOTE: The packet ID is used only for logging and troubleshooting. As
> long as it is the correct length, ETMS will accept the message.)
> (Required)
>
> ABCDEFG -- ARINC address to which the reply should be sent. If this
> address is not included, ETMS will send the reply to the sending
> address, whether CDMNET or ARINC. (Optional)

[]{#__RefHeading___Toc150577475 .anchor}4.2.2 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 for a GDP has the following format:

FM ABC1234 DCA LGA 06260145 T5 260400 T6 260500 A2 LGA.260500A --

A6 R T8 260430

The sample message has the following meaning:

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

A sample FM message for an AFP has the following format:

FM ABC1234 DCA LGA 06260145 T5 260400 T6 260500 A2 FCAA02.260500A --

A6 R T8 260430

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

[]{#__RefHeading___Toc150577476 .anchor}4.2.3 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 user 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. (Required)
>
> ABC1234 -- Flight identifier (a.k.a. call sign) of the flight being
> modified. (Required)
>
> DCA -- Origin airport for the flight. (Required)
>
> LGA -- Destination airport for the flight. (Required)
>
> 06260145 -- Original gate departure date and time for the flight
> (0145Z on June 26^th^). (Required)
>
> A6 -- Field identifier for slot hold flag. (Optional)
>
> H -- New value (held) requested for this flight's slot. (Required)

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

[]{#__RefHeading___Toc150577477 .anchor}4.2.3 SCS Message

The SCS message is used to exchange a slot that cannot be used for a
slot that can be used. The SCS message differs from the other flight
specific messages in that it is about specific slots more than specific
flights. However, since the message formatting and error checking in
general is built around flights, the SCS message follows the
conventional format of first identifying the flight that owns the slot,
then the additional data needed to process the message. This message
also deviates in that it is a fixed format. Because of this, no field
identifiers are used.

An SCS message has the following format. The first field defines the
message type. The next four fields uniquely identify the flight that is
currently in the slot being yielded. The remaining fields provide, in
order, the name of the slot being yielded, the earliest acceptable time
for the new slot, and the latest acceptable time for the new slot.

A sample SC message for a GDP follows:

SCS UNA1277 DFW SFO 03241701 SFO.242040A 242050 242120

This sample would be interpreted as follows:

-   SCS -- This is an SCS request message type. (Required)

-   UNA1277 -- The ID of the flight to be subbed into the new slot.
    (Required)

-   DFW -- The origin of the flight. (Required)

-   SFO -- The destination of the flight. (Required)

-   03241701 -- The original departure date/time for the flight.
    (Required)

-   SFO.242040A -- The yielded slot. (Required)

-   242050 -- The earliest acceptable time for the new slot. (Required)

-   242120 -- The latest acceptable time for the new slot. (Required)

A sample SC message for an AFP follows:

SCS UNA1277 DFW SFO 03241701 FCAA02.242040A 242050 242120

[]{#__RefHeading___Toc150577478 .anchor}4.2.5 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 for a GDP has the following format:

SC ABC999 STL LGA 06260315 T5 260328 T6 260552 A2 LGA.260552Q

The sample message has the following meaning:

> SC -- Message type. (Required)
>
> ABC999 -- Flight identifier (a.k.a. call sign) of the flight being
> modified. (Required)
>
> STL -- Origin airport for the flight. (Required)
>
> LGA -- Destination airport for the flight. (Required)
>
> 06260315 -- Original gate departure date and time for the flight
> (0315Z on June 26^th^). (Required)
>
> T5 -- Field identifier for CTD. (Required)
>
> 260328 -- New value of CTD requested for this flight (0328Z on the
> 26^th^). (Required)
>
> T6 -- Field identifier for CTA. (Required)
>
> 260552 -- New value of CTA requested for this flight (0552Z on the
> 26^th^). (Required)
>
> A2 -- Field identifier for assigned arrival slot. (Required)
>
> LGA.260552Q -- Name of arrival slot requested for this flight. (NOTE:
> ETMS 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 user increases the changes that the slot name will be unique.)
> (Required)

A sample SC message for an AFP has the following format:

SC ABC999 STL LGA 06260315 T5 260328 T6 260552 A2 LGA.260552Q

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

[]{#__RefHeading___Toc150577479 .anchor}4.2.6 Hold All Slots

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

A sample message has the following format:

HOLD ALL SLOTS FOR LGA

[]{#__RefHeading___Toc150577480 .anchor}4.2.7 Release All Slots

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

A sample message has the following format:

RELEASE ALL SLOTS FOR FCAA02

[]{#__RefHeading___Toc150577481 .anchor}4.2.8 Bridging Off

The Bridging Off message temporarily disables flights for the sending
user from being used as part of an SCS bridge in a particular GDP.

A sample message has the following format:

EDCT BRIDGING OFF LGA

[]{#__RefHeading___Toc150577482 .anchor}4.2.9 Bridging On

The Bridging On message restores the use of flights for the sending user
from being used as part of an SCS bridge in a particular GDP.

A sample message has the following format:

EDCT BRIDGING ON FCAA02

[]{#__RefHeading___Toc150577483 .anchor}4.2.10 Message Field
Descriptions

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

-   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)

    -   c -- any character

    -   () -- 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.

The message fields follow.

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
user code and the flight number.

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

Examples: JFK, CYYZ, X47, 7FL6

FAA identifier for the airport of origin for this flight. NOTE: Airport
name can include digits and can start with a digit.

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

Examples: JFK, CYYZ, X47, 7FL6

FAA identifier for the destination airport for this flight. NOTE:
Airport name can include digits and can start with a digit.

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} --- 11,12, or 14
characters. aaa(a).ddddddL or FCAccc.ddddddL

Examples: ORD.261200A, CYYZ.261200C, X47.041749B, 7FL6.191923A,
FCAA02.191435A

Unique identifier of the arrival slot to which this flight is currently
assigned. The format is a concatenation of airport or FCA name, slot
date and time, and a one-letter suffix. An airport name can be three or
four characters and can be a mix of letters and digits. An FCA name must
be "FCA" followed by three digits. 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.

> NOTE ON FCA NAMES: An FCA name must be six characters starting with
> the literal letters "FCA". The remaining characters can be either
> digits, upper-case letters, dash ("-"), or underscore ("\_"). An FCA
> name cannot end with an underscore. Examples of legal FCA names:
> FCA001, FCAA01, FCA-01, FCA_AA.

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. For a GDP or GS, the CTA is the arrival time at the
airport; for an AFP, the CTA is the arrival time at the FCA 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 a user 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___Toc150577484 .anchor}4.3 Substitution Message Replies

ETMS will send a response to every SS message packet. The response is by
default sent to the return address on the incoming message. (The user
can optionally request that the response for a CDMNET message be sent to
an ARINC address.) The format of the response is the same regardless of
what types of messages were sent in the SS packet.

In addition, if a substitution request is successful, ETMS will send a
copy of the reply as an unsolicited message. This allows the user to
monitor a single stream of messages to get all control time updates,
even if initiated by the user. The unsolicited substitution update is
described in section 7.11.

[]{#__RefHeading___Toc150577485 .anchor}4.3.1 Good Response

If no errors are detected in the SS packet, the ETMS database is updated
to reflect the changes requested by the users. The response to the user
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 ARR CTD CTA TYPE EX CX SH ERTA IGTD

ABC1234 LGA.260500A DCA LGA 260400 260500 SUB - Y - - 260145

ABC5678 LGA.260400A IAD LGA 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___Toc150577486 .anchor}4.3.2 Error Response

If errors are detected in the SS packet, the entire packet is rejected
and the ETMS database is not updated. The response to the user 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 LGA.260500A

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___Toc150577487 .anchor}5. TERMINATING A GDP OR AFP

When a GDP or AFP is terminated (also referred to as purged), meaning
that the remaining controls for that ADP/GDP are being removed, a
message is sent to the user notifying them of the purge. In the case of
an airport GDP, it is straightforward for the user to know which flights
are no longer controlled. In the case of an AFP, the affected flights
might have different origins or destinations and otherwise be hard to
determine. To remove any ambiguity over which flights are being purged,
the purge message will include a list of the flights that no longer are
considered controlled by ETMS. Although the motivation is clarity in an
AFP, the same format is used for either an AFP or GDP for consistency.
The format of the purge message is described in section 7.2.

NOTE: Any flights that have departed prior to the GDP or AFP being
purged will NOT be included in this list. Since the CTD was in place
when these flights departed, ETMS considers them already controlled and
so therefore will not purge them.

[]{#__RefHeading___Toc150577488 .anchor}6. REPORTS

Three reports are available to the user 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___Toc150577489 .anchor}6.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. Required and allowed only 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 or FCA.
> Like the slot lists sent when the GDP is issued, the EDCT SLIST report
> returns a single list that includes all flights affiliated with the
> requesting user. That is, the reply can include different three-letter
> user codes in one report.

[]{#__RefHeading___Toc150577490 .anchor}6.2 Report Formats

[]{#__RefHeading___Toc150577491 .anchor}6.2.1 EDCT LIST

A sample EDCT LIST report has the following format: (NOTE: This sample
was generated with Adaptive Compression enabled.)

Number of airports currently controlled: 2

DEST TIMES CONTROL FLIGHTS SUBS SCS AC

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

EWR /19/01/ EDCT+DAS 255 ON ON ON

JFK /20/23/ GS 47 OFF OFF OFF

Bridging status at EWR:

\- Carriers which turned bridging OFF:

USA

Bridging status at JFK: ON.

Number of FCAs currently controlled: 1

FCA TIMES CONTROL FLIGHTS SUBS SCS AC

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

FCAA02 /18/23/ EDCT+DAS 24 ON ON OFF

Bridging status at FCAA02: ON.

Bridging turned OFF permanently for non-CDM general aviation and
military.

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 -- 8: 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 DAS delays)
>
> Number of flights affected (44)
>
> Status of substitutions (ON)
>
> Status of Slot Credit Substitutions (ON)
>
> Status of Adaptive Compression (ON)

Line 9: blank

Lines 10 -- 14: Status of bridging for individual GDPs. If bridging is
off, the report lists each carrier that currently has bridging off for
that GDP.

Line 15: blank

Line 16: Number of controlled FCAs.

Line 17: blank

Line 18: Column headers

Line 19: separator

Line 20: A list of each issuance of an AFP that is currently in effect.
The format is the same as for the GDP list.

Line 21: blank

Line 22: Status of bridging for individual AFPs. Same format as for
GDPs.

Line 23: blank

Line 24: Status of bridging for the system. This applies to both GDPs
and AFPs. (NOTE: This line continues out past the right margin.)

Line 25: blank

Line 26: Location of the printer at the command center. (NOTE: This is
of no use for the NAS user.)

If a GDP or AFP has been revised or compressed, there will be multiple
lines for that airport or FCA. 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).

The following sample EDCT LIST report was generated with Adaptive
Compression disabled. Notice the addition of two lines, one following
the list of airports, one following the list of FCAs. Otherwise the
report is the same as described above.

Number of airports currently controlled: 2

DEST TIMES CONTROL FLIGHTS SUBS SCS AC

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

EWR /19/01/ EDCT+DAS 255 ON ON OFF

JFK /20/23/ GS 47 OFF OFF OFF

ADAPTIVE COMPRESSION processing DISABLED!

Bridging status at EWR:

\- Carriers which turned bridging OFF:

USA

Bridging status at JFK: ON.

Number of FCAs currently controlled: 1

FCA TIMES CONTROL FLIGHTS SUBS SCS AC

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

FCAA02 /18/23/ EDCT+DAS 24 ON ON OFF

ADAPTIVE COMPRESSION processing DISABLED!

Bridging status at FCAA02: ON.

Bridging turned OFF permanently for non-CDM general aviation and
military.

Printer: \$fsa.//wkstn32

2.  []{#__RefHeading___Toc150577492 .anchor}EDCT SUB SHOW

A sample EDCT SUB SHOW report has the following format: (NOTE: This
sample was generated with Adaptive Compression enabled.)

Current Time: 18:06:17 on 7/29/2005

Airport SUB Processing Activated SCS Processing Activated AC Active

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

EWR Yes Yes Yes

JFK No No No

FCA SUB Processing Activated SCS Processing Activated AC Active

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

FCAA02 Yes Yes No

Bridging turned OFF permanently for non-CDM general aviation.

Printer: \$fsa.//wkstn32

The meaning of the sample is as follows:

Line 1: Time and date the report was generated.

Line 2: blank

Line 3: Airport header

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

Line 7: Blank

Line 8: FCA header

Line 9: A list of each AFP FCA and the status of substitutions at that
FCA.

Line 16: Blank

Lines 17: Status of bridging for individual AFPs. Same format as for
GDPs.

Line 18: blank

Line 19: Status of bridging for the system. This applies to both GDPs
and AFPs. (NOTE: This line continues out past the right margin.)

Line 20: blank

Line 21: Location of the printer at the command center. (NOTE: This is
of no use for the NAS user.)

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.

The following sample EDCT SUB SHOW report was generated with Adaptive
Compression disabled. Notice the additional line after the FCA list.
Otherwise the report is the same as described above.

Current Time: 18:06:17 on 7/29/2005

Airport SUB Processing Activated SCS Processing Activated AC Active

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

EWR Yes Yes Yes

JFK No No No

FCA SUB Processing Activated SCS Processing Activated AC Active

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

FCAA02 Yes Yes No

ADAPTIVE COMPRESSION processing DISABLED!

Bridging turned OFF permanently for non-CDM general aviation.

Printer: \$fsa.//wkstn32

[]{#__RefHeading___Toc150577493 .anchor}6.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 difference with the GDP
issuance is the first line. As with the slot list issued for a GDP or
AFP, the line length presents a problem for ARINC/ADNS. The same
solution is applied here; that is, a report requested over CDMNET will
contain the full data while a report request over ARINC/ADNS will
contain truncated data.

Sample reports are shown here. Refer to section 3 for a full description
of the slot list format.

A sample full EDCT SLIST report to be sent over CDMNET for a GDP has the
following format:

SLOT LIST FOR LGA

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH ERTA IGTD

ABC1234 LGA.260400A DCA LGA 260300 260400 GDP - - - 260400 260245

ABC5678 LGA.260500A IAD LGA 260400 260500 GDP - - - 260300 260145

ABC360 LGA.260323A CYYZ LGA 260206 260323 GDP Y - - 260319 260150

ABC3522 LGA.260311A DCA LGA 260215 260311 GDP - - - 260311 260145

ABC39 LGA.260353A ROC LGA 260246 260353 GDP - Y - 260355 260235

A sample truncated EDCT SLIST report to be sent over ARINC/ADNS for an
AFP has the following format:

SLOT LIST FOR FCAA02

ACID ASLOT DEP ARR CTD CTA TYPE EX CX IGTD

ABC1234 FCAA02.260400A DCA LGA 260300 260400 AFP - - 260245

ABC5678 FCAA02.260500A IAD BOS 260400 260500 AFP - - 260145

ABC360 FCAA02.260323A CYYZ LGA 260206 260323 AFP Y - 260150

ABC3522 FCAA02.260311A DCA BOS 260215 260311 AFP - - 260145

ABC39 FCAA02.260353A ROC LGA 260246 260353 AFP - Y 260235

[]{#__RefHeading___Toc150577494 .anchor}7. UNSOLICITED MESSAGES

During a GDP or AFP, ETMS will send messages to the users when changes
are made in the ETMS database that affect that user's flights. These
messages can be sent to ARINC addresses provided by the user or over
CDMNET via TCP/IP socket. Most of the messages are sent to both ARINC
and CDMNET addresses that are configured for the user. The reader should
assume this unless otherwise stated within the message description.

NOTE: All examples in this section are shown using the full format as
sent over AOCNET. When sent over ARINC, the slot list format is
truncated as for any other slot list issuance.

[]{#__RefHeading___Toc150577495 .anchor}7.1 Substitution Status

A message is sent whenever the FAA turns the substitution processing on
or off at an airport. User substitution messages are rejected when
substitutions are turned off. This is typically done just before a GDP
or AFP is revised so that the ETMS and user databases will stay
synchronized.

A sample of each type follows:

EDCT SUB OFF LGA

EDCT SUB ON FCAA02

[]{#__RefHeading___Toc150577496 .anchor}7.2 GDP Termination

The FAA terminates a GDP by using an EDCT PURGE command to clear the
controls out of the ETMS database. The user will get a copy of the EDCT
PURGE commands. The purge message will include a list of all flights
that are no longer considered controlled due to this purge. A sample
EDCT PURGE follows:

EDCT PURGE FCAA02

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH EENTRY IGTD

ABC1234 FCAA02.260400A DCA LGA 260300 260400 AFP - - - 260400 260245

ABC5678 FCAA02.260500A IAD BOS 260400 260500 AFP - - - 260300 260145

ABC360 FCAA02.260323A CYYZ LGA 260206 260323 AFP Y - - 260319 260150

ABC3522 FCAA02.260311A DCA MHT 260215 260311 AFP - - - 260311 260145

ABC39 FCAA02.260353A ROC LGA 260246 260353 AFP - Y - 260355 260235

[]{#__RefHeading___Toc150577497 .anchor}7.3 EDCT Update

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

NOTE: When ETMS creates a slot for a flight in response to an EDCT
UPDATE request from FAA, it uses a letter suffix of "P" or later to
ensure that the slot name will not conflict with a slot name created by
FSM. FSM assigns suffixes starting with the letter "A". Unique slot
names are required to allow these flights to be substituted.

A sample EDCT UPDATE message has the following format:

EDCT UPDATE FOR LGA

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH ERTA IGTD

ABC1593 LGA.252100P ORD LGA 251641 252100 UPD - - - 252034 251623

[]{#__RefHeading___Toc150577498 .anchor}7.4 DAS Delay

The user will get this message whenever a DAS 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.

NOTE: When ETMS creates a slot by assigning a DAS-delay to a pop-up, it
uses a letter suffix of "Z" in the slot name. "Z" slots are not assured
to be unique. Since a DAS-delayed flight cannot be used in
substitutions, the slot name is not required to be unique.

A sample EDCT UPDATE message for a user has the following format:

DAS DELAY FOR FCAA02

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH EENTRY IGTD

ABC1593 FCAA02.252100Z ORD LGA 251641 252100 DAS - - - 252034 251623

[]{#__RefHeading___Toc150577499 .anchor}7.5 GAAP Slot Assignment

The user will get this message whenever a GAAP unassigned slot is
applied to one of its flights. The update is simply a new slot list
including the one flight that was assigned to the slot.

A sample GAAP SLOT message for a user has the following format:

GAAP SLOT FOR LGA

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH ERTA IGTD

ABC1593 LGA.252100A ORD LGA 251641 252100 GAAP - - - 252034 251623

[]{#__RefHeading___Toc150577500 .anchor}7.6 SCS Bridging Update

The user will get this message whenever one or more of its flights is
used to create a bridge for an SCS request. A bridging update will only
move a flight to an earlier time.

An SCS request can be initiated in three ways. If the request is sent by
a user or by the FAA (using the ECR tool), ETMS will give the bridged
flights control types of SBRG. If the request is generated internally by
ETMS during adaptive compression, ETMS will give the flights control
types of ABRG.

A sample BRIDGING UPDATE message for a user has the following format:

SCS BRIDGING UPDATE FOR FCAA02

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH EENTRY IGTD

ABC1593 FCAA02.252100A ORD LGA 251641 252100 BRG - - - 252034 251623

[]{#__RefHeading___Toc150577501 .anchor}7.7 ECR Update

When a flight misses its EDCT window, the FAA will request a new EDCT
for that flight using the ECR Tool. The ECR Tool allows the traffic
manager to first make an SCS request. If that fails, the traffic manager
can then make an EDCT Update request. An ECR-generated EDCT Update
request looks like any other EDCT Update; the user is notified as
described in section 7.3. An ECR-generated SCS request, if successful,
will look slightly different to the user. The message sent will have the
same header as the SCS Bridging Update. However, the flight for which
the EDCT change was requested will have a control type of ECR. The slot
list may also include flights for that user that were bridged as part of
the request.

A sample SCS BRIDGING UPDATE message that includes an ECR flight has the
following format:

SCS BRIDGING UPDATE FOR LGA

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH ERTA IGTD

ABC1593 LGA.252100A ORD LGA 251641 252100 ECR - - - 252034 251623

ABC264 LGA.252043B DFW LGA 251737 252043 BRG - - - 252043 251705

[]{#__RefHeading___Toc150577502 .anchor}7.8 SCS Status

A message is sent whenever the FAA turns the SCS processing on or off at
an airport. User SCS messages are rejected when SCS is turned off. The
capability to turn off SCS was implemented as a fail-safe in case SCS
messages caused adverse effects during a GDP or AFP. It is never used
under normal circumstances.

A sample of each type follows:

EDCT SCS OFF LGA

EDCT SCS ON LGA

[]{#__RefHeading___Toc150577503 .anchor}7.9 Drop-out Flight

When a flight drops out of an FCA, perhaps due to a reroute, and
therefore is no longer controlled by an AFP for that FCA, a message will
be sent to the user indicating that the flight is no longer controlled.
The message shows the control times and slot at the time the flight was
rerouted.

NOTE: Once a flight drops-out of an AFP, the slot that belonged to that
flight is no longer available for substitution or compression. See
section 4.1.4 for more details.

A sample DROPOUT FLIGHT message for a user has the following format:

DROPOUT FLIGHT FOR FCAA02

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH EENTRY IGTD

ABC1593 FCAA02.252100A ORD LGA 251830 252100 AFP Y - - 252034 251623

[]{#__RefHeading___Toc150577504 .anchor}7.10 Re-control

There are two cases, other than the issuing of a GDP or AFP, in which
the control of a flight might transfer from one AFP to another:

-   A flight might drop out of one AFP and immediately be eligible for
    another.

-   The controlling program for a flight may be purged, making it
    eligible for another AFP.

In either case, a message will first be sent to the user indicating that
the flight is no longer controlled by the original AFP or GDP, followed
by another message indicating the flight is now controlled by a new
element. If the flight was a pop-up in the prior AFP or GDP, the user
will receive a new pop-up message as described in section 7.4. However,
if the flight was not a pop-up and could be subbed in the prior GDP or
AFP, a RECONTROL message will be sent, indicating that the flight can be
subbed in the new program. The flight will be assigned a control type of
"RCTL".

NOTE: When ETMS creates a slot for a re-controlled flight, it uses a
letter suffix of "P" or later to ensure that the slot name will not
conflict with a slot name created by FSM. FSM assigns suffixes starting
with the letter "A". Unique slot names are required to allow these
flights to be substituted.

A sample RECONTROL FLIGHT message for a user has the following format:

RECONTROL FOR FCAA02

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH EENTRY IGTD

ABC1593 FCAA02.252100P ORD LGA 251830 252100 RCTL Y - - 252034 251623

[]{#__RefHeading___Toc150577505 .anchor}7.11 Substitutions

When a user successfully substitutes flights, ETMS sends a response
confirming the new control times for those flights. The person who
generated request, and/or the application from which the request was
sent, therefore know that these flights have been updated. However,
other people from that user's organization and other applications the
user may run do not necessarily know that these flights have changed. In
order to allow a person or application to have a single source of all
control time changes, ETMS will send a copy of any successful
substitution request out as an unsolicited message.

Section 4.3.1 describes the reply format for a successful substitution
request. The unsolicited message format contains the same slot list but
has a slightly different header to better identify the message and to be
consistent with the other unsolicited messages. A sample substitution
message for a user has the following format:

SUBSTITUTION FOR LGA

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH ERTA IGTD

ABC1234 LGA.260500A DCA LGA 260400 260500 SUB - Y - - 260145

ABC5678 LGA.260400A IAD LGA 260300 260400 SUB - - - 260400 260245

[]{#__RefHeading___Toc150577506 .anchor}7.12 Hold/Release Slots

When a user submits a HOLD ALL SLOTS or RELEASE ALL SLOTS request, ETMS
sends a response listing the cancelled flights that were modified. As
with other substitution requests, ETMS sends the response to the
requestor. However, a user application listening for changes will not
know these flights have changed status. Therefore, ETMS will send a copy
of any successful HOLD ALL SLOTS or RELEASE ALL SLOTS request out as an
unsolicited message.

Section 4.3.1 describes the reply format for a successful substitution
request, which includes the HOLD ALL/RELEASE ALL response. The
unsolicited message format contains the same slot list but has a
slightly different header to better identify the message and to be
consistent with the other unsolicited messages. A sample HOLD ALL
message for a user has the following format:

HOLD ALL SLOTS FOR LGA

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH ERTA IGTD

ABC1234 LGA.260500A DCA LGA 260400 260500 SUB - Y Y - 260145

ABC5678 LGA.260400A IAD LGA 260300 260400 SUB - - Y 260400 260245

A sample RELEASE ALL message for a user has the following format:

RELEASE ALL SLOTS FOR FCAA01

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH ENTRY IGTD

ABC1234 FCAA01.260500A DCA LGA 260400 260500 SUB - Y - 260430 260145

ABC5678 FCAA01.260400A IAD LGA 260300 260400 SUB - - - 260400 260245

NOTE: The HOLD ALL SLOTS and RELEASE ALL SLOTS messages will be sent
only to CDMNET addresses. These messages will never be sent to an ARINC
address, even if configured to receive unsolicited data. The reasoning
is the messages to ARINC generally print out for human consumption.
Since these messages do not contain control time changes, they are not
important to the people monitoring these printouts.

[]{#__RefHeading___Toc150577507 .anchor}7.13 Timeout Cancelled Flight

When a flight's departure time falls too far into the past (90-minutes
for US and Canada departures), ETMS cancels the flight. This can cause a
flight to be compressed to the end of a program. To help avoid this
happening for flights that the user is still planning to operate, ETMS
will send a message to the user notifying them that a controlled flight
has been timeout cancelled. The message will show the control times for
the flight at the time it was cancelled.

If the status for a timeout-cancelled flight changes so that it is now
expected to operate, ETMS will send a REINSTATE message as described in
the next section.

A sample TIMEOUT CANCEL message for a user has the following format:

TIMEOUT CANCEL FOR FCAA02

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH EENTRY IGTD

ABC1593 FCAA02.252100A ORD LGA 251830 252100 AFP Y Y - 252034 251623

[]{#__RefHeading___Toc150577508 .anchor}7.14 Reinstated Flight

If ETMS has sent an unsolicited message indicating a controlled flight
has been cancelled, and the flight is reinstated to a status indicating
it is expected to operate, ETMS will send a reinstate message to the
user.

A sample REINSTATED FLIGHT message for a user has the following format:

REINSTATED FLIGHT FOR FCAA02

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH EENTRY IGTD

ABC1593 FCAA02.252100A ORD LGA 251830 252100 AFP Y - - 252034 251623

[]{#__RefHeading___Toc150577509 .anchor}7.15 Flight ID Change

If the flight ID for a controlled flight changes, ETMS maintains the
control times and status for the flight. A flight ID change may be
initiated by either a user message or an ATC message. To keep the user
informed of such changes, ETMS will send a message whenever the ID is
changed for a controlled flight. The message will show the current
control times for the flight. To help the user correlate the change with
the previous data, the message will indicate the former ID for the
flight.

A sample FLIGHT ID CHANGE message for a user has the following format:

FLIGHT ID CHANGE FOR LGA

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH ERTA IGTD

ABC593X LGA.252100A ORD LGA 251830 252100 SUB Y - - 252034 251623

PREVIOUS ACID: ABC1593

[]{#__RefHeading___Toc150577510 .anchor}7.16 Diverted Flights and
Diversion Recoveries

A controlled flight that is diverted can go through two stages:

-   First, the original controlled flight is diverted to an alternate
    destination. In order to maintain the arrival slot in the program
    for that user, the original flight is *diversion-cancelled* in ETMS.

-   If the user creates a new flight leg to operate the flight from the
    alternate airport to the original destination, the *recovery leg*
    assumes the control times, arrival slot, and status from the
    diversion-cancelled leg.

In both cases, the flight data change can be initiated by either a user
message or an ATC message. In both cases, ETMS will send a message to
the user indicating the change in status.

A sample DIVERSION CANCEL message for a user has the following format:

DIVERSION CANCEL FOR LGA

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH ERTA IGTD

ABC1593 LGA.252100A ORD LGA 251830 252100 GDP Y Y - 252034 251623

A sample DIVERSION RECOVERY message for a user has the following format:

DIVERSION RECOVERY FOR LGA

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH ERTA IGTD

ABC593A LGA.252100A ALB LGA 252025 252100 GDP Y Y - 252034 251945

NOTE: If a diversion-cancelled flight is reinstated prior to the
recovery leg being created, ETMS will send a REINSTATED FLIGHT message
as described in section 7.14.

[]{#__RefHeading___Toc150577511 .anchor}7.17 Adaptive Compression Update

The user will get this message whenever ETMS moves one or more of its
slots using the adaptive compression process. The message will include
the flights that are moved later, to keep their slots usable, as well as
flights for that user that are moved earlier to take advantage of the
compressed slots. Flights that are being moved later to keep their clots
usable will be tagged with a control type of ADPT. Flights that are
moved earlier to *bridge* the flights back will be given a control type
of ABRG. If ETMS needs to execute any internal SCS requests to
accomplish the adaptive compression, it will send those updates out
using the normal SCS BRIDGING UPDATE message described in section 7.6.

A sample BRIDGING UPDATE message for a user has the following format:

ADAPTIVE COMPRESSION FOR FCAA02

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH EENTRY IGTD

ABC1234 FCAA02.260255A DCA LGA 260210 260255 ADPT - Y - 251705 251545

ABC5678 FCAA02.251900A IAD BOS 251755 251900 ABRG - - - 251830 251645

ABC360 FCAA02.252123A CYYZ LGA 252050 252123 ABRG - - - 251945 251750

ABC3522 FCAA02.252311A DCA MHT 252135 252311 ABRG - - - 252211 251845

ABC39 FCAA02.260053A ROC LGA 252346 260053 ABRG - - - 252355 251835

[]{#__RefHeading___Toc150577512 .anchor}7.18 Scope Reduction

If the FAA revises a GDP, AFP, or GS so that the program ends earlier
and fewer flights are controlled, ETMS will send a message to each
affected user listing the flights that are no longer controlled. The
flight list will include the last control times assigned to the flights
prior to them being dropped from the program.

SCOPE REDUCTION FOR FCAA02

ACID ASLOT DEP ARR CTD CTA TYPE EX CX SH EENTRY IGTD

ABC1234 FCAA02.260400A DCA LGA 260300 260400 AFP - - - 260400 260245

ABC5678 FCAA02.260500A IAD BOS 260400 260500 AFP - - - 260300 260145

ABC360 FCAA02.260323A CYYZ LGA 260206 260323 AFP Y - - 260319 260150

ABC3522 FCAA02.260311A DCA MHT 260215 260311 AFP - - - 260311 260145

ABC39 FCAA02.260353A ROC LGA 260246 260353 AFP - Y - 260355 260235

[]{#__RefHeading___Toc150577513 .anchor}8. COMMUNICATIONS PROTOCOLS

[]{#__RefHeading___Toc150577514 .anchor}8.1 ARINC/ADNS

The ARINC/ADNS network provides users with a customized network for
transmitting and receiving certain aviation data. The GDP and AFP
messages are sent and received using the same protocol as other ADNS
data. The only specific requirement of the GDP and AFP 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 LGA.260500A

FM ABC5678 IAD LGA 06260245 T5 260300 T6 260400 A2 LGA.260400A

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 user. 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.

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

[]{#__RefHeading___Toc150577515 .anchor}8.2 CDMNET

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

[]{#__RefHeading___Toc150577516 .anchor}8.2.1 Session Protocol

Using CDMNET, inter-process communications between application processes
at the users and the ETMS are performed in "sessions" through dedicated
TCP/IP sockets. In each session, the application running at the user
site is considered the client and the application running at the ETMS 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.

2.  Data is exchanged between the client and server indefinitely.

3.  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 ETMS 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 or AFP message. Each message has a *client
tag* embedded in the header. The ETMS 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 user is sending the
data.

The user client can manage the session in several ways. If the user
wants to get unsolicited GDP and AFP messages, the client should
establish a connection, send a connect message (to identify itself), and
listen on the socket indefinitely. If the user 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 a user wants to run multiple simultaneous clients, the user needs a
unique client tag for each. FAA will provide as many client tags as the
user needs. FAA can authorize use of the client tags from a single IP
address or multiple addresses.

ETMS 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 ETMS server has data to transmit to a user and the
user client is not currently connected, the ETMS server discards the
data. When a user client reconnects, it can use the reports requests to
synchronize the user with the current ETMS data, if desired.

[]{#__RefHeading___Toc150577517 .anchor}8.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
> user. \[4-byte integer\]
>
> 5\) Short Data - Field for optional use by the user 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_ATMS_CONNECT       1           Sent by client when  There is no data
                                   first connecting to  buffer for this
                                   identify itself to   message.
                                   the ETMS server.     

  M_ATMS_ACCEPT        2           Set by ETMS server   There is no data
                                   to client to         buffer for this
                                   acknowledge that the message.
                                   connection as been   
                                   accepted.            

  M_ATMS_REJECT        5           Sent by ETMS server  There is no data
                                   to client to notify  buffer for this
                                   the client that the  message.
                                   connection has been  
                                   refused.             

  M_HB_REQ             10          Optionally sent by   There is no data
                                   client to check if   buffer for this
                                   the connection is    message.
                                   still alive.         

  M_HB_ACK             11          Sent by the ETMS     There is no data
                                   server to the client buffer for this
                                   in response to a     message.
                                   M_HB_REQ             

  M_SS_DATA_PACKET     112         Sent by client to    SS packet as
                                   submit a             described in Section
                                   substitution         4.2.
                                   request.             

  M_SS_REPLY           102         Sent by ETMS server  SS Reply as described
                                   in response to a     in Section 4.3.
                                   substitution         
                                   request.             

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

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

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

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

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+DAS 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___Toc150577518 .anchor}8.2.3 Error Handling

#### Loss of Client

When the ETMS 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

2.  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

2.  A failure when writing to the server socket.

[]{#__RefHeading___Toc150577519 .anchor}9. BECOMING A PARTICIPANT

Before a user can participate in substitutions, the user must have
connectivity to ETMS. This can be done either through the ARINC/ADNS
network, through a dedicated IP link, or through a VPN over the
Internet; either of the latter two provide the TCP/IP connectivity
referred to as the CDMNET. Information for accessing the CDMNET will be
provided upon request.

**NOTE**: In order to use Flight Schedule Monitor (FSM) tool, a user
must have a CDMNET connection.

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

1.  All flights codes that you would like to get GDP data for and send
    SS messages for. These can be specified as:

    1.  All flights for a three-letter code.

    2.  Flight number ranges for three-letter codes.

    3.  A list of specific flight IDs.

2.  Written authorization from any other users for which you will be
    doing substitutions.

    If the user is using ARINC/ADNS, it must provide to FAA:

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

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

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

If the user 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 substitutions.

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

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

3.  One or more unique client tags.

4.  IP addresses and port numbers of the ETMS server.

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

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

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

[]{#__RefHeading___Toc150577521 .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 ETMS 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.

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).

ERR320: NOT AUTHORIZED TO UPDATE THIS FLIGHT.

One of the flights in the message belongs to an airline that you cannot
submit data for.

ERR321: DEPARTURE DATE TOO FAR IN FUTURE.

> The departure date is more than 1 day in the future (this limit is
> temporary until future flights are processed.

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.

ERR396: CANNOT SPECIFY CONTROLLED TIME.

Cannot specify CTD or CTA in an FM message submitted in an FD packet.
Control times can only be specified in an FM submitted in an SS packet.

ERR397: CANNOT SPECIFY ASSIGNED ARRIVAL SLOT.

Cannot provide Arrival Slot in an FM message submitted in an FD packet.
Arrival slot can only be provided in an FM submitted in an SS packet.

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___Toc150577522 .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 substitution messages or RQ for 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. USE QU BOSCDYA.

The packet was sent to the wrong address.

[]{#__RefHeading___Toc150577523 .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 414: 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.

ERR415: 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 0this error is an incorrect flight ID, origin,
destination, or original gate departure date and time.

ERR417: 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.

ERR418: CANNOT SUB INTO SLOT NOT OWNED BY THIS CARRIER

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

ERR419: 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.

ERR420: 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.

ERR421: 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.

ERR422: 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.

ERR423: 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.

ERR424: CANNOT SUB A FORMER POPUP FLIGHT TO A LATER SLOT

To discourage misuse of pop-up flights, a slot created by a pop-up
flight cannot be used to improve the position of another flight.

ERR425: AIRPORT OR FCA NOT CONTROLLED

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

ERR426: CANNOT CHANGE HOLD FLAG FOR NON-CANCELLED 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.

ERR427: 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.

ERR428: 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.

ERR429: SLOT TIME CANNOT BE IN THE PAST

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

ERR430: CANNOT SUB COMPLETED FLIGHT

Cannot modify slot assignment for a completed flight.

ERR431: CANNOT SUB MULTIPLE AIRPORTS OR FCAS

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

ERR432: 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.

ERR433: 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.

ERR434: 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 DAS Delay.

ERR435: SLOT ALREADY EXISTS

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

ERR436: INVALID MESSAGE TYPE FOR SS PACKET. USE FM/FX/SCS/HOLD ALL
SLOTS/RELEASE ALL SLOTS.

Only FM, FX, SCS, HOLD ALL SLOTS or RELEASE ALL SLOTS are valid within
an SS packet.

ERR437: SLOT IN SC MSG CANNOT BE DURING CURRENT GDP

Slot time for newly created slot falls in the current GDP timeframe. For
a user 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.

ERR438: CANNOT SUB REMOVED FLIGHT

The flight has been removed by the FAA and is not available for subbing.

ERR439: 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.

ERR440: SUB PROCESSING IS OFF

Command Center is currently not accepting substitution messages
pertaining to this GDP or AFP. FAA will send a SUBS ON message in a few
minutes when it resumes accepting substitution messages.

ERR441: SCS CAN ONLY BE INCLUDED IN SS PACKETS

A Slot Credit Sub message can only be included in an SS packet, not in
an FD or EI packet.

ERR442: SCS PROCESSING IS OFF

The FAA has turned Slot Credit Sub processing off for the airport or
FCA. All SCS requests will be rejected.

ERR443: YIELDED SLOT MUST BE IN THE FUTURE

The slot that is being given up in the SCS message must be later than
the current time.

ERR444: EARLIEST ACCEPTABLE TIME MUST BE LATER THAN TIME OF YIELDED SLOT

The time of the yielded slot must be earlier than the earliest
acceptable time.

ERR445: EARLIEST ACCEPTABLE TIME MUST BE EARLIER THAN LATEST ACCEPTABLE
TIME.

The window of acceptable times must be specified as the earliest
acceptable time first then the latest acceptable time.

ERR446: 20-MINUTE WINDOW NOT ALLOWED WITH SCS

The substitution window size for an SCS packet must be set to 0. If any
flights within the packet violate the window size, then the packet will
be rejected.

ERR447: YIELDED SLOT OWNED BY FORMER POP-UP FLIGHT

The yielded slot must not be owned by a former pop-up.

ERR448: SCS TIME RANGES OVERLAP

The time ranges of different SCS messages within a packet must not
overlap. The time range of an SCS is defined as the time from the
yielded slot to the latest acceptable time.

ERR449: NO SLOTS AVAILABLE

No bridge could be created that would allow the SCS flight to be moved
into the requested window.

ERR450: SLOT TIME OF SCS FLIGHT IS ALREADY WITHIN WINDOW

The yielded slot of the SCS flight already falls within the requested
window. No processing is required.

ERR451: SCS PROCESSING HAS BEEN DISABLED UNTIL FURTHER NOTICE

The FAA has suspended SCS processing temporarily.

ERR485: AFP SUBS ARE DISABLED

The FAA has suspended substitutions for AFP indefinitely. This is
distinguished from ERR440 as follows. ERR440 is sent when FAA has
momentarily turned off subs in order to issue a revision or compression.
If a user sees ERR440, they should wait a few minutes and try again.
ERR485 indicates the FAA has disabled subs because they are causing a
large-scale technical or procedural problem. Subs may be disabled for
days or weeks in this latter case.