NAM AIDC ICD Ver D 20 Jan 2012

North American (NAM) Common Coordination
Interface Control Document (ICD)
VOLUME 1: Area Control Center (ACC) to ACC
. . ALASKA
ALASKA
CANADA .
CANADA .
N
TIO
RA
EG
S INT
ES
ML
SEA
UNITED
UNITED STATES
MEXICO
MEXICO. .
CUBA .
NAS-IC-21009205
Revision D
January 20, 2012
i
This page intentionally left blank.
ii
CHANGE HISTORY
Date Rev. Action

1 August 2000 -- Initial Draft for C/M/U Review
26 January 2001 -- Draft Sent for ICAO Review
21 March 2002 -- Incorporate NCP 23326 - NAM ICD - Approved Changes (02-03, 02-04, 02-05, 02-
07, 02-08, 02-09, 02-10, 02-11, 02-12, 02-13, and 02-14)
12 September A Incorporate NCP 32074, ATO0E-NAS-1001 to address technical and editorial
2008 changes that have been pre-coordinated with NAV Canada and SENEAM.
5 April 2011 B Incorporate changes to NAM ICD which include ICAO 2012 Amendment 1 and to
address technical and editorial changes pre-coordinated with NAV Canada and
SENEAM.
5 December C Version update adds Cuba as the fourth NAM ICD interface member.
2011
20 January 2012 D Version update adds Cuba/Mexico Interface Attachment
i
ii
NAS-IC-21009205
Rev D- 20 January 2012
Table of Contents
FOREWORD .......................................................................................................................................... 1
1. Historical ........................................................................................................................................................ 1
About the Document ............................................................................................................................................. 1

1.1 Part I- Purpose, Policy, and Units of Measurement ................................................................................................ 1
1.2 Part II- NAM ATS Coordination Messages ............................................................................................................ 1
1.3 Part III- Communications and Support Mechanisms .............................................................................................. 1
1.4 Appendices ............................................................................................................................................................. 2
1.5 Attachments ............................................................................................................................................................ 2
2. Glossary.......................................................................................................................................................... 3
3. List of Acronyms ........................................................................................................................................... 5
4. References ...................................................................................................................................................... 8
PART I – PURPOSE, POLICY, AND UNITS OF MEASUREMENT ............................................. 9
1. Purpose ........................................................................................................................................................... 9
2. Policy .............................................................................................................................................................. 9
2.1 Configuration Management .................................................................................................................................... 9
2.2 System Philosophy .................................................................................................................................................. 9
3. Units of Measurement and Data Conventions .......................................................................................... 13

3.1 Time and Date ....................................................................................................................................................... 13
3.2 Geographic Position Information .......................................................................................................................... 13
3.3 Route Information ................................................................................................................................................. 13
3.4 Level (Altitude) Information................................................................................................................................. 14
3.5 Speed Information................................................................................................................................................. 14
3.6 Heading Information ............................................................................................................................................. 14
3.7 Functional Addresses ............................................................................................................................................ 14
3.8 Facility Designators .............................................................................................................................................. 14
PART II – NAM ATS COORDINATION MESSAGES ................................................................... 15
1. Introduction ................................................................................................................................................. 15
2. Message Fields……………………………………………………………………………………………..13
2.1 Field 03--Message Type, Number and Reference Data ........................................................................................ 16
2.2 Field 07--Aircraft Identification and Mode A Code ............................................................................................. 16
2.3 Field 08--Flight Rules and Type of Flight ............................................................................................................ 16
2.4 Field 09--Number and Type of Aircraft and Wake Turbulence Category ............................................................ 16
2.5 Field 10--Equipment and Capabilities .................................................................................................................. 16
2.6 Field 13--Departure Aerodrome and Time ........................................................................................................... 16
2.7 Field 14--Estimate Data ........................................................................................................................................ 16
2.8 Field 15--Route ..................................................................................................................................................... 17
2.9 Field 16--Destination Aerodrome and Total Estimated Elapsed Time, Destination Alternate Aerodrome(s) ...... 17
2.10 Field 18--Other Information ................................................................................................................................. 17
2.12 Field 31--Facility and Sector Designators............................................................................................................. 17
2.13 Field 32--Aircraft Position and Velocity Vector ................................................................................................... 18
iii
NAS-IC-21009205
Rev D - 20 January 2012
3. NAM Core Message Set .............................................................................................................................. 19
3.1 Coordination of Pre-Departure (near-border) Flights ........................................................................................... 20
3.2 Coordination of Active Flights ............................................................................................................................. 23
3.3 Reserved ............................................................................................................................................................... 24
3.4 General Information Messages ............................................................................................................................. 24
3.5 Interface Management Messages .......................................................................................................................... 25
3.6 Acknowledgements ............................................................................................................................................... 26
3.7 Radar Handoff Messages ...................................................................................................................................... 27
PART III – COMMUNICATIONS AND SUPPORT MECHANISMS .......................................... 31
1. Introduction ................................................................................................................................................. 31
2. Telecommunications Requirements and Constraints .............................................................................. 31

2.1 Use of Aeronautical Fixed Telecommunications Network (AFTN) ..................................................................... 31
2.2 Use of a Wide-Area Network ............................................................................................................................... 31
2.3 Use of Direct Lines ............................................................................................................................................... 31
2.4 Character Set ......................................................................................................................................................... 31
3. Engineering Considerations ....................................................................................................................... 31

3.1 Associated Automation Functionality ................................................................................................................... 31
3.2 Failure and Recovery Solutions ............................................................................................................................ 32
3.3 Data Requirements ................................................................................................................................................ 32
4. Security Considerations .............................................................................................................................. 32

4.1 Privacy .................................................................................................................................................................. 32
4.2 Authentication ....................................................................................................................................................... 33
4.3 Access Control ...................................................................................................................................................... 33
5. Test Considerations ..................................................................................................................................... 33
6. Performance Considerations ...................................................................................................................... 33

6.1 Response Time ...................................................................................................................................................... 33
6.2 Availability / Reliability ....................................................................................................................................... 33
6.3 Capacity and Growth ............................................................................................................................................ 33
APPENDIX A – ERROR CODES..................................................................................................... A-1
APPENDIX B – IMPLEMENTATION GUIDANCE MATERIAL .............................................. B-1
B.1 Use of the Core Message Set ...................................................................................................................... B-1
B.2 Development of Field Content ................................................................................................................... B-4
B.3 Summary of Expected Responses to Messages ........................................................................................ B-6
ATTACHMENT 1 – MEXICO/UNITED STATES BOUNDARY AGREEMENT ...................... 1-1
1. Introduction .................................................................................................................................................... 1-1
2. Message Implementation and Use ................................................................................................................ 1-1
3. Physical Interface ........................................................................................................................................... 1-3
iv
NAS-IC-21009205
Rev D- 20 January 2012
ATTACHMENT 2 – CANADA/UNITED STATES BOUNDARY AGREEMENT...................... 2-1
1. Introduction .................................................................................................................................................... 2-1
ATTACHMENT 3 - CUBA/UNITED STATES BOUNDARY AGREEMENT…………………3-1
1. Introduction .................................................................................................................................................... 3-1
ATTACHMENT 4 – MEXICO/CUBA BOUNDARY AGREEMENT........................................... 4-1
1. Introduction .................................................................................................................................................... 4-1
Tables and Figures

Table 1. Summary of Message Fields ................................................................................................................ 15
Table 2. NAM Core Message Set ...................................................................................................................... 19
Table 3. Summary of Data Definitions Needed to Support the Interface ...................................................... 32
Table 4. Expected Message Rates and Sizes ..................................................................................................... 33
Table A-1. LRM Error Codes and Explanations ........................................................................................... A-1
Table B-1. Summary of Expected Message Responses .................................................................................. B-6
Table Att. 2-1. Summary of Flight Plan Routing in FAA and NAV CANADA Systems ............................. 2-1
Attachment 1, Figure. 1-1. Physical Interface …..…………………..………………………………...…..1-3
Attachment 2, Figure 2-1. Physical Interface ………………………………………………………............2-4
Attachment 3, Figure 3-1. Physical Interface …………………………………………………...….............3-4
Attachment 4, Figure 4-1. Physical Interface…...………………...………………………………………....4-2
v
NAS-IC-21009205
vi
NAS-IC-21009205
FOREWORD
1. Historical
Within the North American Aviation Trilateral (NAAT/5), Canada, Mexico, and the United States agreed to
cooperate on development of a seamless interface between automation systems, focusing on automated
exchange of ICAO flight data. In June 1998, the Trilateral Commission formed a working group to address Air
Traffic flight data exchange via automation. Canada’s Air Traffic Service provider, NAV CANADA, Mexico’s
Air Traffic Service provider, SENEAM and the United States’ Air Traffic Service provider, the Federal
Aviation Administration, began discussions in which culminated in a plan to achieve cross-border automation.
These discussions evolved to include a message-set and support requirements being identified for initial
implementation of interface processing, which provides electronic exchange of air traffic flight data. This group
was responsible for defining common interface standards for the NAM region, based as closely as possible on
ICAO Doc. 4444, Procedures for Air Navigation Service – Air Traffic Management (PANS-ATM). The
endeavor resulted in operational flight data interfaces being implemented between Canada and the United States
in 2009 with the fielding of the Canadian Automated Air Traffic System (CAATS) and the Host En Route
Automation System (EAS). Mexico’s air traffic control automation system, called EUROCAT, was first
interconnected with the United States in 2005. HOST EAS and Mexico’s EUROCAT X upgrade was completed
in 2009, providing continued support for automated flight data exchange.
In June 2008, ICAO announced Amendment 1 Doc 4444 15th edition. This document revision reflects
Amendment 1 changes.
In October 2011 the FAA at Miami ARTCC (KZMA) and the Instituto de Aeronautica Civil de Cuba (IACC)
Havana ACC successfully implemented an automation interface between the two air traffic control facilities,
modeled after the U.S.-Mexico Class 1 cross border interface. The effort culminated eighteen months of
technical and operational coordination, testing and problem solving to achieve automated flight data exchange.
The automation initiative extends the NAM automation flight data exchange capability well into the Caribbean
achieving system goals and advancing ICAO milestones for both countries. In March0 2012, building on the
foundation of automated data exchange between Miami and Havana, SENEAM and the IACC implemented a
NAM interface between Merida and Havana. The interface extends the automation compatibility of the North
American region well into the Caribbean and the Gulf of Mexico and also lays the foundation for eventual
interconnection between adjacent member states automation systems.
About the Document

1.1 Part I- Purpose, Policy, and Units of Measurement
This section provides an overall philosophical view of the Interface Control Document (ICD) and general
information concerning the measurement units that are used. It also describes the process by which changes to
this document are to be managed.
1.2 Part II- NAM ATS Coordination Messages

This section describes in detail all the messages that may be used to exchange ATS data between NAM Air
Traffic Services (ATS) Units. In this version of the document, message formats have been defined.
1.3 Part III- Communications and Support Mechanisms

This section describes the technical and other requirements needed to support NAM ATS message exchange.
1
NAS-IC-21009205
1.4 Appendices
The appendices include a list of error messages and implementation guidance for the message set.
1.5 Attachments
Each attachment describes a specific common boundary agreement, noting the level of the interface that is
supported and any deviations from the core message definitions.
2
NAS-IC-21009205
2. Glossary
Active Flight A flight that has departed but has not yet landed. Note: This ICD assumes
any flight with an entered actual departure time in the flight plan is active.
Adapted Route A route whose significant points are defined in an automation system and
associated with a name for reference purposes. Adapted routes normally
include all ATS routes, plus non-published routes applied to flights by the
system or by controllers.
Adapted Route Two significant points and the name of the adapted route connecting them.
Segment
Aircraft ID A civilian or military call sign (e.g. UAL101 or SALLY72) or the registration
number, e.g., XBNBA, CGHFM, N19880, of an aircraft.
Air Traffic Services The FAA, SENEAM, NAV CANADA or IACC.

Provider
Airway A route that is defined and published for purposes of air navigation.
Altitude a) A level of constant atmospheric pressure related to a locally measured

atmospheric pressure, which is used to express an assigned or filed
altitude below flight level 180.
b) A level of constant atmospheric pressure related to reference datum of
29.92 inches of mercury (or 1,013.2 hPa), which is used to express an
assigned or filed altitude at or above flight level 180. (See Flight Level.)
Area Control Center An Air Traffic Services facility used for control of en route air traffic. Also
known as an Air Route Traffic Control Center (ARTCC) in the United States.
Assigned Beacon A beacon code that has been assigned by an ATC facility to a flight. The
Code flight may or may not be squawking this code. See Established Beacon Code.
ATS Route A route that is defined and published for purposes of air navigation.
Beacon Code A Mode 3/A transponder code consisting of four octal digits.
Boundary Crossing An intersection point between a route of flight and a control boundary.
Point
Boundary Crossing The time at which a flight is predicted to reach its Boundary Crossing Point.
Time
Boundary Point An agreed point on or near the control boundary at which time and altitude
information is provided for purposes of coordination.
3
NAS-IC-21009205
Character A letter from A-Z or number from 0-9.
Control Boundary The boundary of the Area Control Center (ACC) as defined in the local
automation system. This is typically close to, but not the same as, the FIR
boundary.
Direct Route Segment A route segment defined solely by two significant points. The path between
the points is implied and depends on the navigation system used.
Element Within a numbered field of an ICAO message there may be several sub-
fields, called elements. These are referred to by sequential letters a, b, c, etc.
For example Field 03 has elements a, b, and c.
Established Beacon The Mode 3/A beacon code that a flight is now squawking.
Code
Field A numbered logical portion of a message. All references to fields in this

document are to message fields defined in ICAO Doc. 4444 unless otherwise
specified.
Fix-radial-distance A method of specifying a geographic point. It includes the name of a fix,

followed by a direction from the fix in degrees and then a distance in nautical
miles.
Flight ID The combination of aircraft ID (from Field 07) and most recent message
number (from ICAO Field 03(b)) in which uniquely identifies a flight.
Flight Level A level of constant atmospheric pressure related to a reference datum of 29.92
inches of mercury (1,013.2 hPa). Each is stated in three digits that represent
hundreds of feet. For example, flight level 250 represents a barometric
altimeter indication of 25,000 feet with the altimeter set to 29.92.
EUROCAT The SENEAM En Route Automation System (EAS), a Thales ATM system.
Letter A letter from A-Z.
Numeric A number from 0-9.
Off-Block Time The time at which an aircraft expects to push back or has pushed back from
the gate.
Proposed Flight A flight that has a flight plan but has not departed.
Reject When this term is used, it means that an incoming message is not to be
processed further and should be output to a specified location (either the
message source, or a local adapted device or position). The message must be
re-entered in total (after correction) in order for it to be processed.
4
NAS-IC-21009205
Reported Altitude The latest valid Mode C altitude received from an aircraft or the latest
reported altitude received from a pilot.
Route A defined path consisting of one or more ordered route segments with
successive segments sharing a common end/start point. (See also Adapted
Route, Direct Route, Flight Plan (or Filed) Route, Route Segment, Direct
Route Segment, and Adapted Route Segment).
Route Segment Two significant points and the path between them, with the order of the points
indicating the direction of flight. (See Adapted and Direct Route Segments.)
Selective Calling Techniques or procedures applied to radio communications for calling only
System one of several receiving stations guarding the same frequency.
Service In the context of this interface, a service refers to type of interface service
provided: message transfer, file transfer, data base query, etc.
Standard Arrival A published route from a designated significant point to an aerodrome. This
Route is also known as a Standard Terminal Arrival (STAR) in the United States
and Canada.
Standard Departure A published route from an aerodrome to the first significant point on a route.
Route This is known as a Standard Instrument Departure (SID) in Canada and an
Instrument Departure Procedure (DP) in the United States.
Significant Point A specified geographical location used in defining an ATS route or the flight
path of an aircraft and for other navigation and ATS purposes.
Standard Metric Level The same as Flight Level, but expressed in tens of meters instead of hundreds
of feet.
Symbol Any of the symbols used within messages, including space “ ”, oblique
stroke “/”, single hyphen “-”, plus “+”, open bracket “(”,and closed bracket
“)”.
Transaction The exchange of a message and the associated response.
Note: Definitions applicable for the purpose of this ICD
3. List of Acronyms
ACC Area Control Center

ACID Aircraft ID
Note: The first character must be a letter.
ACP Acceptance Message
ADF Automatic Direction Finder
AFTN Aeronautical Fixed Telecommunications Network
5
NAS-IC-21009205
ANSI American National Standards Institute

ARTCC Air Route Traffic Control Center (see Area Control Center)
ASCII American Standard Code for Information Interchange
ATM Air Traffic Management
ATN Aeronautical Telecommunications Network
ATS Air Traffic Services
bps Bits Per Second
CAATS Canadian Automated Air Traffic System
CHG Proposed flight modification message
CMNPS Canadian Minimum Navigation Performance Specifications
C/M/U ASI/TF Canada/Mexico/United States Automation System Interfaces
Task Force
CNL Flight Plan Cancellation message
CNS Communications, Navigation, Surveillance
CPL Current Flight Plan
DOF Date of Flight
EAS En Route Automation System
EST Estimate message
FAA Federal Aviation Administration
FDP Flight Data Processing
FDPN Flight Data Processing Network
FIR Flight Information Region
FPL Filed Flight Plan message
FSAS Flight Services Automation System
FSS Flight Service Station
IACC Instituto de Aeronautica Civil de Cuba
ICD Interface Control Document
ICAO International Civil Aviation Organization
ID Identification
IFR Instrument Flight Rules
ILS Instrument Landing System
IRQ Initialization Request message
IRS Initialization Response message
ISO International Standards Organization
KB Kilobyte (= 1024 bytes)
LAM Logical Acknowledgement message
LRM Logical Rejection message
MIS Miscellaneous Information message
MNPS Minimum Navigation Performance Specification
6
NAS-IC-21009205
MOD Active flight modification message

MSN Message Switched Network
NADIN National Airspace Data Interchange Network
NAM ICAO North American Region
NAS National Airspace System
NAAT North American Aviation Trilateral
NAT ICAO North Atlantic Region
OTP On Top
PAC ICAO Pacific Region
PANS Procedures for Air Navigation Services
PSN Packet Switched Network (synonymous with PSDN)
PSDN Packet Switched Data Network (synonymous with PSN)
RDP Radar Data Processing
RLA Radar Logical Acknowledgement
RNP Required Navigation Performance
RTF Radio Telephone
RTA Radar Transfer Accept
RTI Radar Transfer Initiate
RTU Radar Track Update
RVSM Reduced Vertical Separation Minimum
SELCAL Selective Calling System
SENEAM Servicios A La Navegación En El Espacio Aéreo Mexicano
(Navigation Services for Mexican Airspace)
SID Standard Instrument Departure
SSR Secondary Surveillance Radar
STAR Standard Terminal Arrival
TBD To Be Determined
TRQ Termination Request message
TRS Termination Response message
UTC Coordinated Universal Time
VFR Visual Flight Rules
VHF Very High Frequency
VOR VHF Omni-directional Range
VSP Variable System Parameter
WJHTC William J Hughes Technical Center
7
NAS-IC-21009205
4. References
Document ID Document Name

ICAO Doc. 4444 Procedures for Air Navigation Services-Air Traffic
Management, Fifteenth Edition
NAT ICD North Atlantic Common Coordination Interface Control
Document
ICAO Annex 10, Volume II Aeronautical Telecommunications
ICAO Doc. 8643 Aircraft Type Designators
ICAO Doc. 7910 Location Indicators
Amendment 1 Amendment 1 to the PANS-ATM (ICAO Doc 4444 15th

Edition)
8
NAS-IC-21009205
PART I – PURPOSE, POLICY, AND UNITS OF MEASUREMENT

1. Purpose
The purpose of this document is to ensure that data interchange between ATS units providing Air Traffic
Services in the NAM region conforms to a common standard, and to provide a means to centrally coordinate
changes to the standard.
2. Policy
2.1 Configuration Management
The contents of this ICD are to be approved by the members of the Canada/Mexico/Cuba/United States
Automation Systems Interface Task Force (C/M/U ASI/TF). Proposed changes to this document will be
submitted to the C/M/U ASI/TF secretariat, currently the United States Federal Aviation Administration (FAA).
The secretariat of the task force will coordinate review through a designated representative for each country.
When all parties have agreed to a change, the document will be amended and distributed by the secretariat.
This document identifies the standards to be followed when the defined messages are implemented. A separate
agreement between each pair of countries will define which messages are currently implemented.
“ICAO Doc. 4444”, when used in this document, refers to the ICAO Doc 4444 Procedures for Air Navigation
Services-Air Traffic Management, Fifteenth Edition, Amendment 1.
2.2 System Philosophy
The automation of flight data exchange between neighboring Air Traffic Services units will follow the standards
set by ICAO Doc. 4444 as closely as possible. In constructing the interface, it was recognized that the ICAO
standards address neither all required messages nor all required details of message content, and that existing
ATS procedures and automation systems are not always fully compatible with parts of the ICAO standard.
Therefore, this document supplements ICAO Doc. 4444 as needed to meet the needs of the NAM ATS
providers.
This document addresses messages exchanged between Area Control Centers (ACCs) for IFR aircraft1.
Interfaces with Flight Service Stations (FSSs) and with airspace users for IFR and VFR flights are not
addressed. Note that a message (e.g. FPL) from a user or FSS to an ACC may have different requirements than
those sent from ACC to ACC.
In addition, several levels of implementation have been defined. Each level is a subset of the entire message set,
and represents a complete operational capability with attendant procedures. This allows for incremental
implementation of the capability.
2.2.1 Flight Data Coordination

The first phase of the automation exchanges active flight plans using a CPL message. Changes to a previously
transmitted CPL and all other coordination (including transfer of control) are accomplished manually. When
1
Including composite flights that are IFR when they cross the control boundary.
9
NAS-IC-21009205
mutually agreed upon between ATS units, the the automation may also include the exchange of proposed flight
plans using the FPL message. Manual acceptance via the ACP message (see ICAO Doc. 4444, Section 9) is not
implemented.
The second phase of the automation is Class 2 which adds the following capabilities:
a) Exchange of Filed Flight Plan (FPL) and Estimate (EST) messages.
b) Modification of a CPL or of a FPL that was activated by an EST message (MOD).
c) Modification of FPL messages (CHG).
2.2.2 Cancellation of a previously sent FPL or CPL (CNL).

The Logical Acknowledgement Message (LAM) signifies that a message was received correctly. During Class
1, each system must determine if a message was rejected or lost, or if the interface failed by timing-out receipt
of an LAM for each message sent. During the Class 2 phase, the Logical Rejection Message (LRM) provides
the reason a message was rejected.
2.2.3 Flight Data Coordination

A Class 2 interface adds the following capabilities to a Class 1 interface:
a) Modification of a CPL or FPL that was activated by an EST message (MOD).
b) Exchange of Filed Flight Plan (FPL) and Estimate (EST) messages.
c) Cancellation of a previously sent FPL or CPL (CNL).
d) Modification of FPLs (CHG).
e) General Information (MIS) capability.
2.2.4 Interface Management

Class 2 Interface Management adds the following capabilities:
a) Logical Rejection Messages (LRM).
b) Interface management (IRQ, IRS, TRQ, TRS).
2.2.5 Radar Handoff

Transfer of Control includes the capability to perform a radar handoff using the RTI, RTU, RTA, and RLA
messages defined in this ICD. The format of these messages is consistent with ICAO standards, and the content
was developed based on the TI, TU, and TA messages used in FAA inter-center radar handoffs. The RLA
message was introduced as a logical acknowledgement to an RTI, instead of LAM, because it needs to transmit
information back to the sender.
2.2.6 Candidate Messages for Future Implementation

The following capabilities are under consideration for future implementation:
a) Notification / Coordination (ABI / CDN, ACP, REJ)
b) Alerting messages (ALR, RCF.)
c) Transfer of jurisdiction (TOC, AOC).
d) Point outs (POT, POA, POJ). Note: These messages have no ICAO precedent.
e) Arrival and departure notification (ARR, DEP).
f) Flight plan request (RQP).
g) Clearance request/accept (CRQ, CAK, CLR). Note: These messages have no ICAO precedent.
h) Special Use Airspace status (SUA). Note: This message has no ICAO precedent.
i) Delay (DLA).
10
NAS-IC-21009205
j) Supplemental flight plan (SPL, RQS).

k) General Information (MIS) capability
l) Interface Management (IRQ, IRS, TRQ, TRS)
11
NAS-IC-21009205
12
NAS-IC-21009205
Units of Measurement and Data Conventions

2.3 Time and Date
All times shall normally be expressed in UTC as four digits, with midnight expressed as 0000. The first two
digits must not exceed 23 and the last two digits must not exceed 59.
If higher precision is needed, then a field specification may designate additional digits representing seconds and
then fractions of seconds (using decimal numbers) may be added. For example,
• 092236 is 9 hours, 22 minutes, and 36 seconds.
• 11133678 is 11 hours, 13 minutes, and 36.78 seconds.
When used, dates shall be expressed in the form YYMMDD where YY is the last two digits of the year (e.g. 01
is 2001), MM is the month (e.g. 05 for May), and DD is the day of the month (e.g. 29).
2.4 Geographic Position Information

Geographic position information shall be expressed in one of the following forms. Items a) through d) are
consistent with ICAO Doc. 4444 Appendix 3, section 1.6.3; and item e) was added because the standard ICAO
definition of Latitude/Longitude did not provide enough precision for exchange of radar identification.
a) From 2 to 5 characters, being the coded designator assigned to an en route point;
b) 4 numerics describing latitude in degrees and minutes, followed by “N” (North) or “S” (South),
followed by five numeric’s describing longitude in degrees and minutes, followed by “E” (East) or
“W” (West). The correct number of numerics is to be made up, where necessary, by the insertion of
zeros, e.g. “4620N07805W”.
c) 2 numeric’s describing latitude in degrees, followed by “N” (North) or “S” (South), followed by three
numeric’s describing longitude in degrees, followed by “E” (East) or “W” (West). Again, the correct
number of numerics is to be made up, where necessary, by the insertion of zeros, e.g. “46N078W”.
d) 2 to 5 characters being the coded identification of a significant point, followed by three decimal
numerics giving the bearing from the point in degrees magnetic followed by three decimal numerics
giving the distance from the point in nautical miles. The correct number of numerics is to be made up,
where necessary, by the insertion of zeros, e.g. a point at 180° magnetic at a distance of 40 nautical
miles from VOR “FOJ” would be expressed as “FOJ180040”.
e) When surveillance information with higher precision is necessary, use six numerics describing latitude
in degrees, minutes, and seconds, followed by “N” (North) or “S” (South), followed by seven numerics
describing longitude in degrees, minutes, and seconds followed by “E” (East) or “W” (West). The
correct number of numerics is to be made up, where necessary, by the insertion of zeros, e.g.
“462033N0780556W”.
2.5 Route Information

All published routes shall be expressed as two to seven characters, being the coded designator assigned to the
route to be flown.
13
NAS-IC-21009205
2.6 Level (Altitude) Information

All altitude information shall be specified as flight level(s) or altitude(s) in one of the following formats (per
ICAO Doc. 4444Appendix 3, Section 1.6.2):
a) F followed by three decimal numerics, indicating a Flight Level number.
b) A followed by three decimal numerics, indicating altitude in hundreds of feet.
c) S followed by four decimal numerics, indicating a Standard Metric Level in tens of meters.
d) M followed by four decimal numerics, indicating altitude in tens of meters.
All levels at or above 18,000 feet shall be expressed as a flight level, prefixed with an “F” (e.g. F240). Any
level below 18,000 feet shall be expressed as an altitude, prefixed with an “A” (e.g. A170).
Each message description identifies which of these formats may be used.
2.7 Speed Information

Speed information shall be expressed as true airspeed or as a Mach number, in one of the following formats (per
ICAO Doc. 4444, Appendix 3):
a) N followed by four numerics indicating the true airspeed in knots.
b) M followed by three numerics giving the Mach Number to the nearest hundredth of unit Mach.
c) K followed by four numerics giving the true airspeed in kilometers per hour.
Each message description identifies which of these formats may be used.
2.8 Heading Information

Heading information shall be expressed as degrees and hundredths of degrees relative to true north using five
digits and inserting zeros as necessary to make up five digits, e.g. “00534” is 5.34 degrees relative to true north.
2.9 Functional Addresses

A functional address, which refers to a function within an ATS Unit, may be substituted in the MIS message for
the aircraft identification found in Field 07. The functional address shall contain between one and six characters
and shall be preceded by an oblique stroke (/), for a total length of two through seven characters.
2.10 Facility Designators

Facility designators shall consist of four letters except where noted in a boundary agreement. If an ICAO Doc.
7910 location identifier exists for the facility, it shall be used.
14
NAS-IC-21009205
PART II – NAM ATS COORDINATION MESSAGES

1. Introduction
The following sections describe those messages used by NAM ATS systems for exchange of information.
Messages and fields conform generally to ICAO Doc 4444, and differences are noted.
2. Message Fields
Table 1 provides a summary of all fields used in messages described by this document. The remainder of this
section describes the format of each field element. Section 3 describes which elements should be included in
each ATS message type, and Appendix B describes rules for the semantic content of each field.
Table 1. Summary of Message Fields
Field Element (a) Element (b) Element (c) Element (d) Element (e)
03 Message Type Message Number Reference Data
Designator
07 Aircraft SSR Mode SSR Code
Identification
08 Flight Rules Type of Flight
09 Number of Aircraft Type of Aircraft Wake Turbulence

Category
10 Radio, Comm., Surveillance
Nav., and Equipment and
Approach Aid Capabilities
Equipment and
Capabilities
13 Departure Time
Aerodrome
14 Boundary Point Time at Boundary Cleared Level Supplementary Crossing Condition
Point Crossing Data
15 Cruising Speed or Requested Cruising Route
Mach Number Level
16 Destination Total Estimated Alternate
Aerodrome Elapsed Time Aerodrome(s)
18 Other Information
22 Field Indicator Amended Data
31 Facility Designator Sector Designator
32 Time of Day Position Track Ground Speed Track Heading Reported Altitude
15
NAS-IC-21009205
2.1 Field 03, Message Type, Number and Reference Data

Field 03(a) format shall be per ICAO Doc. 4444 except that:
Only the message identifiers identified in Section 3 shall be permitted in element (a).
Field 03(b) and Field 03(c) format shall be per ICAO Doc. 4444 except that:
The ATS unit identifier in elements (b) and (c) shall be exactly 4 letters except where noted in a boundary
agreement. The ATS unit identifier should correspond to the first four letters of the ICAO Doc. 7910
location identifier for the ATS unit, e.g. CZYZ for the Toronto ACC.
2.2 Field 07, Aircraft Identification and Mode A Code

a) The aircraft ID shall begin with a letter and be at least two characters long.
b) Aircraft IDs that begin with “TTT” shall be used only for test flight plans.
c) In an MIS message, a functional address may be substituted for the flight ID.
Field 07(b) and Field 07(c) format shall be per ICAO Doc. 4444, with the clarification that each number in Field
07(c) must be an octal digit. Note that elements 07(b) and 07(c) are either both present or both absent.
2.3 Field 08, Flight Rules and Type of Flight

Field 08(a) format shall be per ICAO Doc. 4444.
Field 08(b) format shall be per ICAO Doc. 4444.
2.4 Field 09, Number and Type of Aircraft and Wake Turbulence Category
Field 09(b) format shall be per ICAO Doc. 4444 except that:
The list of allowable aircraft type designators will include those in ICAO Doc. 8643 and any others agreed
to between countries implementing the interface. Additional aircraft types must start with a letter.
Field 09(c) format shall be per ICAO Doc. 4444.
2.5 Field 10, Equipment and Capabilities

2.6 Field 13, Departure Aerodrome and Time

2.7 Field 14, Estimate Data

Field 14(c) format shall be per ICAO Doc. 4444 except that:
The designators “S” and “M” used for metric altitude will not be permitted.
Field 14(d) format shall be per ICAO Doc. 4444 except that:
Field 14(e) format shall be per ICAO Doc. 4444.
16
NAS-IC-21009205
2.8 Field 15, Route

The designator “K” used for kilometers per hour will not be permitted.
Field 15(b) format shall be per ICAO Doc. 4444 except that
Field 15(c) format shall be per ICAO Doc. 4444. (Note that even though metric altitude and speed information
will not be permitted in other fields, they are permissible in elements (c4) and (c6).
2.9 Field 16, Destination Aerodrome and Total Estimated Elapsed Time, Destination Alternate
Aerodrome(s)
Field 16(c) format shall be per ICAO Doc. 4444.
2.10 Field 18, Other Information

Field 18(a) format shall be per ICAO Doc. 4444, except that
a) Indicators other than those shown in ICAO Doc. 4444 may be used. This reflects the reality that flight
plans are filed with indicators other than those defined by ICAO (e.g. EUR/ to identify EURCONTROL
specific indicators). Handling of non-standard indicators should be annotated in the respective boundary
agreement.
b) ICAO issued a clarification on the use of Field 18 in CHG, CNL, DLA, DEP and RQS messages and
their use in advance filing. The messages included in this document refer only to flights operating
within the current 24 hour period; therefore DOF may be sent but is not required in messages. Cross-
border deviations from ICAO guidance for the required DOF/ Field 18 format (DOF/YYMMDD or -0)
should be annotated in the respective boundary agreements.
c) ICAO Doc. 4444 does not address the validity/invalidity of using multiple indicators; however,
instances of filed plans which use the same indicator multiple times have been identified. For example,
“RMK/AGCS EQUIPPED RMK/TCAS EQUIPPED RMK/RTE 506”. Because the other indicators, for
example DEP/, often must be used for successful processing of the flight plan in these cases multiple
instances should not be permitted. Boundary agreements should document the specific multiple
indicator conventions if allowed.
2.11 Field 22, Amendment

2.12 Field 31—Facility and Sector Designators

Field 31(a) shall contain a four-letter designator of the destination facility that is to receive the handoff. Note
that this facility ID can be for a terminal facility that the parent en-route system provides routing. The four-
letter designator should be the location identifier for the facility (from ICAO Doc. 7910) if one exists. If a
location identifier does not exist, one should be assigned by mutual agreement between the implementing
countries.
Field 31(b) shall contain a two-digit designator of the sector that is to receive the handoff. If “00” is designated
or the field element is not included then the receiving system is to determine the appropriate sector.
Example: CZEG00
17
NAS-IC-21009205
2.13 Field 32—Aircraft Position and Velocity Vector

Each element of field 32 is fixed length; there is no separator between elements.
Field 32(a) shall contain the time of day that the position is valid for expressed in eight digits: HHMMSSDD
where HH is hours from 00 to 23; MM is minutes from 00 to 59; SS is seconds from 00 to 59 and DD is
hundredths of seconds from 00 to 99.
Field 32(b) shall contain the position of the referent flight expressed in Latitude/Longitude to the nearest second,
in ICAO Doc. 4444 format extended to include seconds (e.g. 462034N0780521W).
Field 32(c) shall contain the ground speed of the flight expressed in knots, per ICAO Doc. 4444 format (e.g.
N0456).
Field 32(d) shall contain five digits, from 00000 to 35999, which is the heading of the flight expressed in
degrees and hundredths of a degree, relative to true north.
Field 32(e) shall contain the reported altitude expressed in ICAO Doc. 4444 format for a level (e.g. F330).
18
NAS-IC-21009205
3. NAM Core Message Set

The NAM core message set is summarized in Table 2 below.
Table 2. NAM Core Message Set
Category Msg. Message Name Description Priority Source
Coordination of pre- FPL Filed Flight Plan Flight plan as stored by the FF ICAO Doc. 4444
departure (near- sending ATS unit at the time of
border) flights transmission. Used only for
proposed flights.
CHG Change Changes previously sent flight FF
data (before estimate data has
been sent).
EST Estimate Identifies expected flight position, FF
time and altitude at boundary.
Coordination of CPL Current Flight Plan Flight plan as stored by the FF ICAO Doc. 4444
active flights sending ATS unit at the time of
transmission, including boundary
estimate data. Used only for
active flights.
CNL Cancellation Cancels an FPL or a CPL. FF
MOD Modify Changes previously sent flight FF New message,
data (after estimate data has been format per CHG.
sent).
General Information MIS Miscellaneous Free-format text message with FF NAT ICD
addressing options.
Interface IRQ Initialization Request Initiates activation of the FF Based on existing
Management interface. CAATS
protocols.
IRS Initialization Response Response to an IRQ. FF
TRQ Termination Request Initiates termination of the FF

interface.
TRS Termination Response Response to a TRQ. FF
Radar Handoff RTI Radar Transfer Initiate Initiates a radar handoff. FF New messages
RTU Radar Track Update Provides periodic position FF based on existing
FAA protocols
updates for a track in handoff
status. and ICAO Doc.
4444 format
RLA Radar Logical Computer acceptance of an RTI FF
Acknowledgement message.
RTA Radar Transfer Accept Accepts or retracts a handoff. FF
Acknowledgements LAM Logical Acknowledgement Computer acceptance of a FF ICAO Doc. 4444
(included in each of message.
the above services) LRM Logical Rejection Computer rejection of an invalid FF NAT ICD
message.
19
NAS-IC-21009205
3.1 Coordination of Pre-Departure (near-border) Flights
3.1.1 FPL (Filed Flight Plan)
3.1.1.1 FPL Purpose

An FPL for a proposed flight may be sent from ATS unit to ATS unit under agreed conditions (e.g. for near
border departures, when the flight time to the boundary is less than the normal advance time for sending a CPL).
The FPL sent contains the latest flight plan information as entered by Air Traffic Control and is not the original
FPL filed by the user.
3.1.1.2 FPL Format

FPL Field Required Optional Comments
Elements Elements
03 a, b
07 a b, c Beacon code is only sent if one is (already) assigned and
the aircraft is so equipped.
08 a b Element (b) is included per requirements of the
boundary agreement.
09 b, c a
10 a, b
13 a, b
15 a, b, c
16 a, b c
18 a, other info. Element (a) will contain -0 (zero) if no other information
is included. Either element (a) OR other information
(but not both) must be included.
3.1.1.3 FPL Examples

This flight plan was sent from Montreal Center (CZUL) to Boston Center (KZBW). The flight is from
Sherbrooke Airport to Montpelier, VT. Because the departure airport is at the border between Canada and the
United States, an FPL will be sent before departure.
(FPLCZUL/KZBW043 -N12345 -IG -C172/L -SD/C -CYSC2055 -N0120A060 DCT YSC V447 MPV DCT –KMPV0053-
EET/KZBW0012)
This flight plan is from Duluth (KDLH) to Amsterdam (EHAM). It crosses into Winnipeg Center from
Minneapolis Center.
(FPLKZMP/CZWG223 –DAL56-IS -B742/H-SXWDHGRZJ3M1/SB2 -KDLH0255 -N0492F330 DCT DLH J533 YQT

DCT YDP/M084F330 DCT PRAWN/M084F370 DCT 59N050W 58N040W 57N030W 56N020W 55N010W UN551
TADEX/N0485F370 UN551 BEL UB3 IOM UL603 BLUF BLUFA4 -EHAM0721 EBBR-PBN/D2 NAV/RNVD1E2A1
REG/N642NW EET/CZWG0032 CZYZ0113 CZUL0126 CZQX0226 59N050W0328 58N040W0404 EGGX0441
56N020W0521 EGPX0603 EGTT0623 SEL/CMAD TALT/KMSP)
20
NAS-IC-21009205
3.1.2 CHG (Change)
3.1.2.1 CHG Purpose

A CHG is used to transmit a change to one or more fields of previously sent flight data for a flight that has not
had boundary estimate data sent. When boundary estimate data has been sent (via CPL or FPL followed by
EST), a MOD message must be used for flight data changes.
3.1.2.2 CHG Format

CHG Field Required Optional Comments
Elements Elements
03 a, b, c Element (c) shall contain the reference number of the
first message (FPL or CPL) sent for this flight.
07 a b, c If a beacon code has been assigned and sent in a
13 a, b previous CHG, it should be included.
Fields 07, 13, and 16 must contain the values of these
16 a fields before the flight data was changed.
18 a
22 a, b
3.1.2.3 CHG Examples

This amendment changes the equipment and capabilities in Field 10 and the Other Information in Field 18.
(CHGKZHU/MMZT776KZHU/MMZT603-UAL1021-KIAD1905-MMEX-DOF/121115-10/SFGHRWXZ/SB2-
18/PBN/D2 NAV/RNVD1E2A1 EET/MMZT0023 MMEX0057 RMK/TCAS EQUIPPED)
OR
(CHGKZHU/MMZT776KZHU/MMZT603-UAL1021-KIAD1905-MMEX-0-10/SFGHRWXZ/SB2-
18/PBN/D2 NAV/RNVD1E2A1 EET/MMZT0023 MMEX0057 RMK/TCAS EQUIPPED) This amendment
changes the ACID of a flight from AAL72 to AAL73. Note that when Field 07(a) is changed, it is the only
change allowed in the message.
(CHGKZMP/CZWG776KZMP/CZWG603-AAL72-KSEA-CYOW-07/AAL73)
3.1.3 EST (Estimate)
3.1.3.1 EST Purpose

An EST is used to provide boundary estimate information for a flight when the basic flight plan information was
previously transmitted via an FPL (instead of a CPL). Note that the EST is sent only when a flight becomes
active.
21
NAS-IC-21009205
3.1.3.2 EST Format

EST Field Required Optional Comments
Elements Elements
the aircraft is so equipped. Aircraft ID and beacon code
sent in an EST message must match the values
previously sent in the FPL or the last CHG that modified
the FPL.
13 a Departure aerodrome must match the value previously
sent in the FPL or the last CHG that modified the FPL.
14 a, b, c d, e
16 a Destination aerodrome must match the value previously
sent in the FPL or the last CHG that modified the FPL.
3.1.3.3 EST Examples

This message was sent from Minneapolis Center to Winnipeg Center upon departure of DAL122. It indicates
that the flight is expected to cross the coordination fix Humboldt (HML) at 2042UTC, and that the flight has
been cleared to flight level 350.
(ESTKZMP/CZWG992KZMP/CZWG991 -DAL122/A4322 –KFAR-HML/2042F350 -CYOW)
3.1.4 CNL (Cancel)
3.1.4.1 CNL Purpose

A CNL is used to notify the receiving ATS unit that a flight, for which an FPL or CPL was sent earlier, is no
longer relevant to that ATS unit.
3.1.4.2 CNL Format

CNL Field Required Optional Comments
Elements Elements
07 a Elements (b) and (c) are not used in this context.
13 a, b Implemented as optional to preclude rejection in
those cases where an EOBT time is not available.
16 a
18 a
3.1.4.3 CNL Examples

This message was sent from Houston Center to Mazatlan Center to indicate that flight UAL1021 from Houston
to Mexico City will no longer be entering Mazatlan Center airspace.
(CNLKZHU/MMZT776KZHU/MMZT603-UAL1021-KIAD0818-MMEX-0)
22
NAS-IC-21009205
3.2 Coordination of Active Flights
3.2.1 CPL (Current Flight Plan)
3.2.1.1 CPL Purpose

A CPL is used to inform the receiving center of the cleared flight plan and boundary estimate information for
coordination purposes. This message may only be sent as the initial transmission of an active flight plan (i.e. a
flight that has departed and for which a boundary estimate based on the actual departure time is available).
3.2.1.2 CPL Format

CPL Field Required Optional Comments
Elements Elements
03 a, b
the aircraft is so equipped.
08 a b Element (b) is included per requirements of the
boundary agreement.
09 b, c a
10 a, b
13 a
14 a, b, c d, e
15 a, b, c
16 a
18 a, other info . Element (a) is included only if no other information is
included. Either element (a) OR other information (but
not both) must be included.
3.2.1.3 CPL Examples

This flight is from Houston to Mexico City. It passes from Houston Center (KZHU) to Monterrey Center
(MMTY).
(CPLKZHU/MMTY005-UAL1021/A2173-IX-A320/M-SE3HIRWXZ/SB2-KIAD-MAM/2042F350-
N0420F350 MAM UJ35 AVSAR DCT-MMMX-PBN/D2 NAV/RNVD1E2A1 DOF/121130)
3.2.2 CNL (Cancel)
3.2.2.1 CNL Purpose

A CNL is used to notify the receiving ATS unit that a flight, for which an FPL or CPL was sent earlier, is no
longer relevant to that ATS unit.
3.2.2.2 CNL Format

The CNL message is used for both active and proposed flights. The format is described in section 3.1.4.
23
NAS-IC-21009205
3.2.3 MOD (Modify)
3.2.3.1 MOD Purpose

A MOD is used to transmit a change to one or more fields of previously sent flight data after boundary estimate
data has been sent. The MOD is therefore used for any flight data changes after a CPL or an EST has been sent.
3.2.3.2 MOD Format

MOD Field Required Optional Comments
Elements Elements
07 a b, c Beacon code is only sent if one is (already) assigned
and the aircraft is so equipped.
13 a
Fields 07, 13, and 16 must contain the values of these
16 a fields before the flight data was changed.
22 a, b
3.2.3.3 MOD Examples

In this example fields 10 and 18 have been amended via a MOD message. Note that all of Field 18 is sent, even
though likely only one part of it changed.
(MODKZHU/MMTY776KZHU/MMTY720-UAL1021–KIAD –MMEX-10/SE3HIRWX/S-18/PBN/D2
NAV/RNVD1E2A1 REG/N431UP EET/MMTY0312 MMEX0338 SEL/EFPQ)
3.3 Reserved
3.4 General Information Messages
3.4.1 MIS (Miscellaneous)
3.4.1.1 MIS Purpose

A MIS is used to transmit a free text message to a specific functional position, or to the position responsible for
a specific flight, at another facility.
3.4.1.2 MIS Format

MIS Field Required Optional Comments
Elements Elements
03 a, b
07 a Note that element (a) in the MIS may contain a flight ID
or a functional address
18 RMK/ followed
by free text
24
NAS-IC-21009205
3.4.1.3 MIS Examples

In this example Salt Lake Center (KZLC) has forwarded information regarding flight DAL1311 to Winnipeg
Center.
(MISKZLC/CZWG876 –DAL1311 -RMK/DAL1311 ABLE 350 AT 1322Z)
In this example Moncton Center (CZQM) has notified a supervisory position (S1) in Boston Center (KZBW)
that sectors 21 and 22 are going to be combined.
(MISCZQM/KZBW999 -/S1 -RMK/COMBINING SECTOR 21 INTO 22 AT 1415Z)
3.5 Interface Management Messages
3.5.1 IRQ (Initialization Request)
3.5.1.1 IRQ Purpose

An IRQ is used to request transition of an interface from a non-operational to an operational state.
3.5.1.2 IRQ Format

IRQ Field Required Optional Comments
Elements Elements
03 a, b
3.5.1.3 IRQ Examples

In this example Moncton Center (CZQM) has sent a request to Boston Center (KZBW) to initialize the interface.
(IRQCZQM/KZBW491)
3.5.2 IRS (Initialization Response)
3.5.2.1 IRS Purpose

An IRS is used as a response to an IRQ message.
3.5.2.2 IRS Format

IRS Field Required Optional Comments
Elements Elements
03 a, b, c Element (c) should contain the reference number of the
previously sent IRQ.
3.5.2.3 IRS Examples

In this example Boston Center has responded to a request from Moncton Center to initialize the interface.
(IRSKZBW/CZQM232CZQM/KZBW491)
3.5.3 TRQ (Termination Request)
3.5.3.1 TRQ Purpose

A TRQ is used to request transition of an interface from an operational to a non-operational state.
25
NAS-IC-21009205
3.5.3.2 TRQ Format

TRQ Field Required Optional Comments
Elements Elements
03 a, b
18 a, other info. Element (a) is included only if no other information is
not both) must be included. Other information, if
included, must include RMK/ followed by free text.
3.5.3.3 TRQ Examples

In this example Vancouver Center (CZVR) has notified Seattle Center (KZSE) that Vancouver Center needs to
terminate the interface.
(TRQCZVR/KZSE491-RMK/SHUTDOWN FOR SOFTWARE CHANGE)
3.5.4 TRS (Termination Response)
3.5.4.1 TRS Purpose

TRS is used as a response to a TRQ message.
3.5.4.2 TRS Format

TRS Field Required Optional Comments
Elements Elements
03 a, b, c Element (c) should contain the reference number of the
previously sent TRQ.
18 a, other info. Element (a) is included only if no other information is
not both) must be included. Other information, if
included, must include RMK/ followed by free text.
3.5.4.3 TRS Examples

In this example Seattle Center (KZSE) has acknowledged the Termination Request (TRQ) sent by Vancouver
Center (CZVR).
(TRSKZSE/CZVR232CZVR/KZSE491-0)
3.6 Acknowledgements
3.6.1 LAM (Logical Acknowledgement)
3.6.1.1 LAM Purpose

A LAM is sent from ACC to ACC to indicate that a message has been received and found free of syntactic and
semantic errors. It does not indicate operational acceptance by a controller. Element (c) contains the reference
number (i.e. element 3(b)) of the message being responded to.
3.6.1.2 LAM Format

LAM Field Required Optional Comments
Elements Elements
03 a, b, c
26
NAS-IC-21009205
3.6.1.3 LAM Examples

This is an example where Houston Center (KZHU) has accepted message number 021 from Monterrey Center
(MMTY) to Houston Center.
(LAMKZHU/MMTY035MMTY/KZHU021)
3.6.2 LRM (Logical Rejection)
3.6.2.1 LRM Purpose

An LRM is used to indicate that a message sent from ATS system to ATS system contained an error and has
been rejected by the receiving system.
3.6.2.2 LRM Format

LRM Field Required Optional Comments
Elements Elements
03 a, b, c
18 text as shown in Describes the error code and the error per Appendix A
Comments guidelines: after RMK/, include
⇒ two digits comprising the error code; (note that
error code 57 will be used for any error that is not
field specific and that is not identified in Appendix
A - Error Codes.)
⇒ two digits comprising the field in error (or 00 if the
error is not field-specific);
⇒ and the erroneous text, i.e. the contents of the
message that caused the error when the error is
field specific. When the error is non-field specific,
a descriptive error message shall be included.
Separate the above items by an oblique stroke (/).
3.6.2.3 LRM Examples

This LRM was generated because the ACID in Field 07 was illegal (eight characters is too long)
(LRMKZLC/CZWG035CZWG/KZLC021-RMK/06/07/AAL98295)
This LRM is an example of a non-field specific error.

(LRMCZYZ/KZOB001KZOB/CZYZ210-RMK/53/00/MESSAGE LOGICALLY TOO LONG)
3.7 Radar Handoff Messages
3.7.1 RTI Message (Radar Transfer Initiate)
3.7.1.1 RTI Purpose

An RTI message is sent from one ATS unit to another to initiate the transfer of radar identification for a flight.
Logical acknowledgement of an RTI is an RLA or LRM.
27
NAS-IC-21009205
3.7.1.2 RTI Format

RTI Field Required Optional Comments
Elements Elements
03 a, b, c
07 a, b, c Must include ACID and established beacon code
13 a
16 a
31 a b If no sector designated or sector 00 is designated, then
receiving system determines
32 a, b, c, d, e
3.7.1.3 RTI Examples

This is an example of a handoff initiated by KZMP to CZWG. No sector is designated, so CZWG will
determine who should receive it.
(RTIKZMP/CZWG812KZMP/CZWG801-DLH499/A3407-KMSP–CYOW–CZWG
-13242934462034N0780521WN043327629F349)
This is an example of a handoff directed to sector 08 in Boston Center, from Toronto Center.
(RTICZYZ/KZBW123CZYZ/KZBW102-ACA202/A2201-CYYZ–KIAD–KZBW08
-13242934444055N0752756WN043327629F350)
3.7.2 RLA Message (Radar Logical Acknowledgement)
3.7.2.1 RLA Purpose

The Radar Logical Acknowledgment message is used to acknowledge computer receipt of an RTI message. The
facility sending this message is indicating that the referenced message has been received and has no format or
logic errors, and to indicate which sector the handoff was routed to. The RLA is an acknowledgement message
in response to RTI and therefore is not responded to.
3.7.2.2 RLA Format

RLA Field Required Optional Comments
Elements Elements
03 a, b, c
31 a, b
3.7.2.3 RLA Examples

In this example Boston Center has indicated to Montreal Center that it has received a handoff and routed it to
sector 53.
(RLAKZBW/CZUL202CZUL/KZBW445-KZBW53)
In this example Boston Center has indicated to Montreal Center that it has received a handoff and routed it to
sector 1A at the TRACON serving the Burlington, Vermont airport. In this case KBTV is an adapted identifier
for the TRACON, since there are no ICAO location identifiers for U.S. TRACONs.
(RLAKZBW/CZUL202CZUL/KZBW445-KBTV1A)
28
NAS-IC-21009205
3.7.3 RTU Message (Radar Track Update)
3.7.3.1 RTU Purpose
An RTU message may be sent from one ATS unit to another to update the radar position of a flight during
transfer of radar identification. RTU messages are sent periodically after an RTI, until an RTA is received or
the handoff is retracted. There is no logical acknowledgement of an RTU.
3.7.3.2 RTU Format

RTU Field Required Optional Comments
Elements Elements
03 a, b, c Element (c) shall refer to the message number of the
RTI message that initiated the handoff.
07 a , b, c Include established beacon code.
13 a
16 a
32 a, b, c, d, e
3.7.3.3 RTU Examples
This is an example of an RTU message initiated by KZMP to CZWG. The message KZMP/CZWG801 was the
RTI message that initiated the handoff.
(RTUKZMP/CZWG000KZMP/CZWG801-DLH499/A3407-KMSP-CYOW
-13242934462034N0720521WN043327629F349)
3.7.4 RTA Message (Radar Transfer Accept)
3.7.4.1 RTA Purpose

An RTA message may be sent from one ATS unit to another as an application response to an RTI. This
message signifies that a controller has accepted radar identification of a flight. An RTA is also sent by the
facility that initiated a handoff to retract the handoff. Logical (computer) acknowledgement of an RTA is an
LAM or LRM.
3.7.4.2 RTA Format

RTA Field Required Optional Comments
Elements Elements
03 a, b, c Element (c) refers to the message number of the RTI
that is being responded to.
07 a, b, c Include assigned beacon code (i.e. code assigned by the
accepting center).
13 a
16 a
31 a, b Note accepting facility may be a TRACON serviced by
the sending ACC.
29
NAS-IC-21009205
3.7.4.3 RTA Examples

This is an example of a handoff accepted by CZWG. Handoff was initiated by KZMP.
(RTACZWG/KZMP438KZMP/CZWG812-DLH499/A4222-KZMP-CYOW-CZWG33)
This is an example of a retraction by KZMP:
(RTAKZMP/CZWG222KZMP/CZWG812-DLH499/A4222-KZMP-CYOW-KZMP42)
30
NAS-IC-21009205
PART III – COMMUNICATIONS AND SUPPORT MECHANISMS

1. Introduction
The communications protocols and physical path are not dictated by this ICD. This ICD addresses only the
application message content.
2. Telecommunications Requirements and Constraints

2.1 Use of Aeronautical Fixed Telecommunications Network (AFTN)
AFTN may be used for the flight data interface in Class 1 or Class 2, subject to verification of performance.
Any interface exchanging radar position data, including radar handoffs, shall not use AFTN.
When AFTN is used as the communications mechanism:
a) The AFTN IA-5 Header as described in ICAO Annex 10, Aeronautical Telecommunications
(Amendment 71) will be used for exchange of messages.
b) ATS messages will be addressed to each ATS unit using an eight-character facility address where the
first four characters are the appropriate location indicator from ICAO Doc. 7910, and the last four
characters are routing indicators defined by the ATS unit in accordance with ICAO Annex 10.
Each message shall be sent with the priority indicated in Table 2 of Part II.
2.2 Use of a Wide-Area Network

Use of existing wide-area networks (e.g. using TCP/IP protocol) may be used if the speed, capacity, and security
characteristics are verified as adequate to support the interface.
2.3 Use of Direct Lines

In cases where speed, capacity, and/or security require it, a direct line interface may be used between facilities.
2.4 Character Set

The IA-5 character set shall be used for all application message content. Certain characters have special
meaning and must only be used as indicated below:
a) Open parenthesis “(”and close parenthesis “)” shall be used only to begin and terminate the application
message.
b) A single hyphen “-” shall be used only as a field separator and shall not be used within any field.
c) Elements within a field shall be separated by an oblique stroke “/’”only where so prescribed in ICAO
Doc 4444, Appendix 3.
3. Engineering Considerations
3.1 Associated Automation Functionality
Each ATS service provider participating in this interface must have a supporting automation system. The
supporting automation shall:
a) Error check all inbound messages for proper format and logical consistency.
b) Ensure only messages from authorized senders are accepted and processed.
c) As required, alert the responsible controller(s) of flight data that has been received.
d) Notify the responsible personnel when any message sent is rejected or not acknowledged within a
variable system parameter (VSP) period of time.
31
NAS-IC-21009205
3.2 Failure and Recovery Solutions

Automation systems may have different failure avoidance and failure recovery mechanisms. Each participating
system shall have the following characteristics:
a) If the recovery process preserves the current message number in the sequence with each facility, no
notification is necessary.
b) If the recovery process requires reset of the sequence number to 000, a means of notifying the receiving
facility that the message numbers have been reset is required. This may be procedural rather than
automated.
c) The recovery process shall not automatically re-send any CPL for which an LAM had been received.
This is relevant if the system was able to recover state information about which flight plans have been
coordinated, and did not need to reset the message sequence numbers.
3.3 Data Requirements

Certain data must be defined and maintained to support all features of the interface. Depending on the data, it
should be coordinated on a National, Regional, or Local (facility) basis. Data requirements are identified in
Table 3 below.
Table 3. Summary of Data Definitions Needed to Support the Interface
Field Data Purpose Source Coordination
03 Facility Identifiers Identify the sending/receiving ICAO Doc. 7910 (first Local
facility. four characters) and
local definition (second
four characters)
07 Functional Address Agree on functional addresses to be Local Data Local
used in MIS messages.
09 Aircraft Type Identify aircraft type designators FAA, NAV CANADA, National
exceptions and wake turbulence categories that SENEAM publications
are not listed in ICAO Doc. 8643.
10 Equipment and Identify ATS-specified equipment FAA, NAV CANADA, National
Capabilities Codes qualifiers that are not specified in SENEAM publications
ICAO Doc. 4444.
14 Boundary Point Identify the coordination fixes to be Local Data Local
sent for each airway.
15 Adapted Routes Identify airway and fix information Local Data Local
and Fixes that is adapted by both systems.
18 Requirements for Identify any requirements for data FAA, NAV CANADA, National
other data to be that must be included in Field 18. SENEAM publications
included
4. Security Considerations
4.1 Privacy
This ICD does not define mechanisms that guarantee privacy. It should be assumed that any data sent over this
interface may be seen by unintended third parties either through interception of the message or through
disclosure at the receiving facility.
Any communications requiring privacy must be identified and appropriate communications and procedures
defined.
32
NAS-IC-21009205
4.2 Authentication
Each system shall authenticate that messages received are from the source that is identified in Field 03.
4.3 Access Control

Each system participating in the interface shall implement eligibility checks to ensure that the source of the
message is eligible to send the message type and is the appropriate authority for the referenced flight.
5. Test Considerations
Before an automated flight data interface becomes operational between any two facilities, the following set of
tests shall be completed:
a) Off-line tests using development or test (i.e. non-operational) systems. These may include both test
systems at non-operational facilities, and operational systems that are in an offline mode.
b) Tests using the operational systems in operational mode in which manual coordination verifies each
flight data message sent.
For diagnostic purposes, each side of the interface should be able to isolate the source of interface problems.
6. Performance Considerations
6.1 Response Time
For flight planning messages, controllers require indication of an unsuccessful message transmission within 60
seconds of the message being sent. Therefore, the response time from the time a message is sent until an LAM
(or LRM) is received shall be under 60 seconds at least 99% of the time under normal operations. A faster
response time is desirable and will result in operations that are more efficient.
For messages involving transfer of control and surveillance data (e.g. RTI, RTA, and RTU) the data must be
transmitted in time for the receiving system to display the track position with acceptable accuracy.
Communication across the interface shall be less than six seconds maximum.
6.2 Availability / Reliability

The hardware and software resources required for providing service on the NAM interfaces should be developed
such that the inherent reliability will support interface availability which is at least equal to the end systems of
that interface.
6.3 Capacity and Growth

Before implementing this interface between two centers, an analysis of the traffic expected between the centers
shall be performed and the proposed communications links verified for appropriate capacity. Traffic estimates
should consider current and future expected traffic levels.
For initial planning purposes the following estimates of message size and messages per flight are provided.
Table 4. Expected Message Rates and Sizes
Message Avg. per Flight Avg. Size2 Comments
Messages per near-border departure flight:
FPL 1 240
CHG 0.5 160 Assumed 1 of 2 flights amended after coordination, before departure.
2
The average message size includes an estimated 50 bytes of communications header added to each application message.
Average message size estimates are based on a combination of specification analysis and review of sample data. In
particular the route, other information, and nav/comm equipment elements were estimated based on approximately 200
FPLs filed in Houston Center in 1998.
33
NAS-IC-21009205
Message Avg. per Flight Avg. Size2 Comments

EST 1 120
MOD 0.5 120 Assumed 1 of 2 flights amended after coordination.
Messages per non near-border departure flight:
CPL 1 250
MOD 0.5 120 Assumed 1 of 2 flights amended after coordination.
Messages per every flight:
CNL 0.01 100 Assumed 1 in 100 flight plans are cancelled.
RTI 1 150
RTU 5 140 Assumed 1 RTU every 6 seconds for 30 seconds.
RTA 1 110
MIS 0.1 130
Responses (not per flight):
LAM/RLA Sum of all above 80
except RTU
LRM 100
The hardware and software developed for the interfaces shall be capable of asynchronously exchanging the
messages defined in Part II, section 3, simultaneously with up to four NAM peer systems.
34
NAS-IC-21009205
Rev D, - 20 January 2011
APPENDIX A – ERROR CODES

The error codes for use with LRM messages are defined in Table 5 below.
Table A-1. LRM Error Codes and Explanations

Error Field Number Supporting Text
Code
1 Header INVALID SENDING UNIT (e.g., AFTN address)
2 Header INVALID RECEIVING UNIT (e.g., AFTN address)
3 Header INVALID TIME STAMP
4 Header INVALID MESSAGE ID
5 Header INVALID REFERENCE ID
6 07 INVALID ACID
7 07 DUPLICATE ACID
8 07 UNKNOWN FUNCTIONAL ADDRESS
9 07 INVALID SSR MODE
10 07 INVALID SSR CODE
11 08 INVALID FLIGHT RULES
12 08 INVALID FLIGHT TYPE
13 09 INVALID AIRCRAFT MODEL
14 09 INVALID WAKE TURBULENCE CATEGORY
15 10 INVALID CNA EQUIPMENT DESIGNATOR
16 10 INVALID SSR EQUIPMENT DESIGNATOR
17 13, 16 INVALID AERODROME DESIGNATOR
18 13 INVALID DEPARTURE AERODROME
19 16 INVALID DESTINATION AERODROME
20 17 INVALID ARRIVAL AERODROME
21 13, 16 EXPECTED TIME DESIGNATOR NOT FOUND
22 13, 16 TIME DESIGNATOR PRESENT WHEN NOT EXPECTED
23 13, 14, 16 INVALID TIME DESIGNATOR
24 13, 14, 16 MISSING TIME DESIGNATOR
25 14 INVALID BOUNDARY POINT DESIGNATOR
26 14, 15 INVALID ENROUTE POINT
27 14, 15 INVALID LAT/LON DESIGNATOR
28 14, 15 INVALID NAVAID FIX
29 14, 15 INVALID LEVEL DESIGNATOR
30 14, 15 MISSING LEVEL DESIGNATOR
31 14 INVALID SUPPLEMENTARY CROSSING DATA
32 14 INVALID SUPPLEMENTARY CROSSING LEVEL
33 14 MISSING SUPPLEMENTARY CROSSING LEVEL
34 14 INVALID CROSSING CONDITION
35 14 MISSING CROSSING CONDITION
36 15 INVALID SPEED/LEVEL DESIGNATOR
37 15 MISSING SPEED/LEVEL DESIGNATOR
38 15 INVALID SPEED DESIGNATOR
A-1
NAS-IC-21009205
Rev D, - 20 January 2012
Error Field Number Supporting Text
Code
39 15 MISSING SPEED DESIGNATOR
40 15 INVALID ROUTE ELEMENT DESIGNATOR
41 15 INVALID ATS ROUTE/SIGNIFICANT POINT DESIGNATOR
42 15 INVALID ATS ROUTE DESIGNATOR
43 15 INVALID SIGNFICANT POINT DESIGNATOR
44 15 FLIGHT RULES INDICATOR DOES NOT FOLLOW SIGNIFICANT POINT
45 15 ADDITIONAL DATA FOLLOWS TRUNCATION INDICATOR
46 15 INCORRECT CRUISE CLIMB FORMAT
47 15 CONFLICTING DIRECTION
48 18 INVALID OTHER INFORMATION ELEMENT
49 19 INVALID SUPPLEMENTARY INFORMATION ELEMENT
50 22 INVALID AMENDMENT FIELD DATA
51 nn (field indicator MISSING FIELD Two numerics
where nn is two
numerics if
present)
52 MORE THAN ONE FIELD MISSING
53 MESSAGE LOGICALLY TOO LONG
54 SYNTAX ERROR IN FIELD nn
55 INVALID MESSAGE LENGTH
56 NAT ERRORS
57 INVALID MESSAGE
58 MISSING PARENTHESIS
59 MESSAGE NOT APPLICABLE TO zzzz ACC
60 03 INVALID MESSAGE MNEMONIC (i.e., 3 LETTER IDENTIFIER)
61 Header INVALID CRC
62 MESSAGE REJECTED, MANUAL COORDINATION REQUIRED
63 INVALID DATE OF FLIGHT
64 INCONSISTENT ITEM 10 AND 18
65 INVALIDS ADS-B EQUIPMENT DESIGNATOR
66 INVALIDS ADS-C EQUIPMENT DESIGNATOR
67-255 Reserved for future use.
Error Code 57 shall be used for any error that is not field-specific and is not identified in the table.
Each country may propose additional error codes as needed.
A-2
NAS-IC-21009205
Rev D – 20 January 2012
APPENDIX B – IMPLEMENTATION GUIDANCE MATERIAL

B.1 Use of the Core Message Set
B.1.1 Filed Flight Plan Messages

The format and content of the FPL is subject to the rules of the receiving country and is not defined by this ICD.
It is expected that an FPL will be filed by an airspace user, and a subsequent CPL will be received from an
adjacent ATS unit. It is the responsibility of each country to design their automation to ensure that an FPL or
CPL from an adjacent ATS unit always takes precedence over a user-filed FPL for the flight so that second-
order flight data messages are applied to the ATS unit-supplied flight plan and not the user-filed flight plan.
B.1.2 Coordination of Active Flights

Normally, a specified VSP number of minutes before a flight reaches a control boundary the sending ATS unit
will send a CPL message to the receiving ATS unit.
The normal computer response to a CPL is an LAM sent by the receiving automation system to signify that the
plan was found to be free of syntactic and semantic errors. Controller acceptance is implied (i.e. the ACP
message defined in ICAO Doc. 4444 is not implemented). This is permitted per ICAO Doc. 4444, Part IX,
section 4.2.3.5.1 and Part VIII, section 3.2.5. If the receiving computer cannot process a CPL then an LRM will
be returned for interfaces implementing Class 2.
ICAO Doc. 4444 states, in Part IX, section 4.2.3.2.5 “A CPL message shall include only information concerning
the flight from the point of entry into the next control area or advisory airspace to the destination aerodrome”.
However, ICAO Doc. 4444 provides no guidelines for choosing the exact point at which the CPL should start.
The nature of ATC automation systems is that they have differing requirements for the starting point of a route
relative to the facility boundary, necessitating some agreement on allowable route tailoring. The relationship
between the start of the route in Field 15 and the coordination fix in Field 14 must also be established so that the
receiving center can accurately process the route. Agreements on these points are provided in the attached
boundary agreements for each country.
B.1.3 Changes after Coordination

Any change to a flight plan after initial coordination requires a message that can be mapped to the correct flight
plan. Every message sent after an initial CPL should have the same Aircraft ID, departure point, and destination
point. The message reference data should point to the first message flight plan message (FPL or CPL) which
began the sequence of messages of which this message is a part. For example, if the CPL message number is
KZMP/CZWG035 then the reference data for the first MOD sent after the CPL should be KZMP/CZWG035.
The second MOD sent for that flight should also refer to the initial message number of the CPL in the sequence.
The messages that represent valid changes to the original flight plan include CHG, EST, MOD, RTI, and RTA
(when used for retraction; see Section B.1.8).
If a flight for which a CPL has been sent will no longer enter the recipient’s airspace, a CNL message should be
sent.
Any change to flight data for a flight that has been coordinated (i.e. a CPL or EST has been sent) must be
forwarded via a MOD message. The MOD message is identical to the ICAO CDN message in format and
content, but does not require an ACP response (only LAM or LRM).
The expected computer response to a CNL, CHG, EST, or MOD is an LAM or LRM for interfaces
implementing Class 2.
Each system should implement rules as to whether an amendment on a particular flight should be accepted from
a neighboring ACC. For example, an amendment from the sending ACC typically is not accepted once transfer
of control has been initiated.
B-1
NAS-IC-21009205
It is expected that the content of a field sent in a flight data change message (e.g. CHG or MOD) will completely
replace the content of the field currently stored in the receiving center. So, for example, if Field 18 is amended
the entire contents of the field should be sent and not only the changed elements.
An aircraft placed into a hold without an Expect Further Clearance (EFC) time should result in a MOD being
sent to the downstream facility with the estimated boundary crossing time in Field 14 changed by an adapted
amount. An aircraft placed into a hold with an EFC time should result in a MOD being sent for the estimated
boundary crossing time in Field 14. After release from hold if the new projected boundary crossing time is
different by more than a parameter time (per facility LOA; nominally 3 minutes), the hold cancellation should
result in a Field 14 MOD message reflecting the new expected boundary crossing time.
After acceptance of a CNL message the receiving system should not accept any changes regarding the subject
flight.
Upon acceptance of an RTI message the receiving system should accept only an RTA, RTU, or MIS message
for the flight. If an RTA signifying retraction is accepted, then the system may once again accept a MOD
message.
Upon receipt of a logical acknowledgement to an RTA message signifying handoff acceptance, the sender of the
RTA should not accept any messages regarding the subject flight.
B.1.4 Near-border Departures

ATS units implementing either Class 1one or Class 2 Flight Data Coordination may also exchange FPLs to
coordinate flights pre-departure when the flight time from the departure point to the boundary point is less than
the normal CPL notification time.
If the estimated flying time from the departure point to the boundary is less than the normal CPL notification
time, or the relevant ATS units have agreed to coordinate all flights from a specified airport pre-departure:
a) ATS units implementing CPLs will manually coordinate the flight upon departure. Additional
coordination procedures may be defined in a facility Letter of Agreement.
b) ATS units implementing FPLs will send an EST message (Basic flight data will have already been
communicated via an FPL sent pre-departure).
If an FPL has been sent and changes are subsequently made, then a CHG message should be used to modify the
changed fields. Only the ATS unit that sent an FPL message may send a CHG message (i.e. the receiving unit
cannot send a CHG back to the sending unit). Once an EST message is sent, a MOD must be used instead of a
CHG for transmission of flight data changes.
The expected computer response to an FPL is an LAM or LRM.
If a previously sent FPL is to be cancelled, a CNL message should be sent.
B.1.5 Interface Management

ATS units implementing phase one of Interface Management will nominally be expected to accept messages at
any time the system is available. Each system is responsible for providing the capability of inhibiting received
messages, if needed. Each system is expected to be able to inhibit outgoing messages. Manual coordination
between facilities will be needed for one facility to request the other to inhibit messages.
B.1.6 Interface Management Future Implementation

ATS units implementing Interface Management candidate messages will request initialization or termination of
the interface via automated messages. Only when an initialization request has been sent and responded to
affirmatively will each system be expected to accept messages.
Any message received when the interface is not initialized shall be ignored (i.e. not processed and not responded
to), except for IRQ.
B-2
NAS-IC-21009205
To request initialization one system shall send an IRQ message to the other. The IRQ may be repeated a
predetermined number of times if no response is received, with each repeated IRQ receiving the same message
number.
If the receiving system is ready to communicate (i.e. it has already sent an IRQ) when it receives an IRQ, it shall
send an IRS in response. There is no LAM or LRM response to an IRQ. The reference number in Field 03
should refer to the message number of the IRQ being responded to. Each system becomes active when it
receives an IRS from the other system. There is no response to an IRS.
If no response to an IRQ is received and the maximum number of retries exceeded, the interface is considered
failed by the initiating system.
A system requests orderly termination of the interface by sending a TRQ message. After sending a TRQ, a
system shall accept only a TRS or TRQ message. There is no LAM or LRM response to a TRQ. Upon receipt
of a TRS the interface shall be deactivated. There is no response to a TRS. Upon receipt of a TRQ the system
shall respond with a TRS and deactivate the interface immediately (even if a TRQ is outstanding). When
messages are exchanged between two ATS units that cause successful termination of the interface, the two
systems shall not send or accept any messages on the interface until a successful initialization transaction has
been completed.
B.1.7 Error Checking, Responses, and Resends

Upon receiving a message, the receiving system shall check that the format and content of each field are in
accordance with this ICD. Other logic checks may be performed per the rules defined by the ATS provider.
Whenever a message is received and passes all syntactic and semantic checks an LAM (or RLA for handoff
initiation) shall be returned to the sender for those messages designated for LAM/LRM responses.
Interface Management (Class 1)
ATS units implementing the first phase of Class 1 Interface Management will not send any response to the
sender when a message fails a syntactic or semantic check. Because the implementation does not use LRM
messages, message rejection is inferred by the failure to receive an LAM. ATS units will mutually agree on a
maximum operationally acceptable time-out value (from the time a message is sent to receipt of an LAM).
ATS units implementing the Class 1 of interface management cannot productively use message resend as a
technique, since the lack of an LAM may infer a lost message or message rejection.
Interface Management (Class 2)
ATS units implementing the second phase of Interface Management , Class 2,will send an LRM when a
received message fails a syntactic or semantic check, using the error codes in Appendix A. In the case of a radar
handoff initiation (see B.1.8) an RLA is used instead of an LAM.
When no response to a message is received within a VSP period of time a unit may optionally choose to resend
the original message—using the same message number—a VSP number of times before declaring failure. The
same message number should be used so that the receiving station can easily distinguish exact duplicates should
the same message be received more than once.
B.1.8 Radar Handoffs
RTI Message
An RTI shall be used to initiate a transfer of radar identification from a controller in one ACC to a controller in
another ACC. An RLA or LRM shall be returned in response to an RTI, based on acceptance checks by the
receiving computer.
If no logical response (RLA or LRM) to an RTI is received after a specified number of retries, the handoff
should be marked as failed to the initiating controller.
Upon acceptance of an RTI message the receiving system should not accept any flight data messages regarding
the subject flight except for an RTA, RTU, or MIS.
B-3
NAS-IC-21009205
RTU Message
The transferring center shall begin sending RTU messages once an RLA is received for an RTI.
RTU messages shall be sent once every tracking cycle. The expected track update rate must be coordinated
between the implementing countries.
An RTU message should not be sent when current track data is not available for a flight, e.g. if the flight enters a
coast mode.
Upon retraction of the transfer or receipt of an RTA from the receiving center the sending of RTUs shall stop.
There will be no response to an RTU (i.e. no LAM, RLA, or LRM).
RTA Message
An RTA message shall be sent by the receiving center in response to an RTI when the receiving controller has
accepted the transfer. An RTA message shall be sent by the sending center when the initiating controller
retracts a previously issued RTI. An LAM or LRM shall be returned in response to an RTA, based on
acceptance checks by the receiving computer. If no response is received within a VSP period of time, the
transfer shall be considered failed and the accepting controller notified.
If the sending center receives an RTA after retracting a handoff, it shall reject the RTA by returning an LRM.
If the receiving center receives an RTA after accepting a handoff, it shall reject the RTA by returning an LRM.
After an RTA is rejected, the controller that attempted to accept or retract control shall be notified that the
handoff failed. Note that it is possible for accept and retract to be entered simultaneously; resulting in both RTA
messages being rejected.
B.1.9 MIS Message

The MIS message can be addressed to either a functional address, or to an aircraft ID. The functional addresses
to use will be exchanged between adjacent centers. Each functional address will map to a workstation or set of
workstations, and the types of information that should be sent to each address should accompany the exchange
of addresses.
When an MIS message is addressed to a flight ID, the receiving system shall route the message to the sector that
currently controls the flight. If no sector controls the flight the message shall be rejected. The intent is that an
MIS message does not modify the flight record for the subject flight (i.e. it is not treated as an amendment to
Field 18 for that flight).
B.2 Development of Field Content

The following sections provide implementation notes on the expected semantic content of each field, how to
generate the fields and how to interpret the fields.
B.2.1 Field 03
Each message sent to each interface should receive an incrementally higher number. Thus, a system must
maintain a separate sequence for each facility with which it interfaces.
The message following number 999 will be 000, and then the number sequence repeats.
The message number in Field 03 and the Aircraft ID in Field 07 combined must be unique for any CPL or FPL.
A flight plan received that has the same message number and ACID as a previously received plan shall be
rejected. Note that it is possible to have duplicate message numbers if the sending computer system fails and is
restarted in a cold start mode (i.e. no previous state data is retained). In this case the message numbers would
restart and may repeat.
Implementers of the interface should consider a check for out-of-sequence messages (i.e. a message received has
a message number that is not one greater than the previous message number). Since messages may be resent if a
response is not received within a VSP period of time, it may also be possible to receive a message more than
B-4
NAS-IC-21009205
once. Therefore implementers should consider a check for duplicate messages based on the message number.
Any such checks should also consider the behavior after a system failure/restart.
B.2.2 Field 07
If the aircraft does not have Mode A capability, omit elements (b) and (c) and the preceding oblique stroke.
Also omit these elements if the aircraft has Mode A capability but the code is unknown (or not assigned).
B.2.3 Field 09
When the aircraft type is “ZZZZ”, there may be no certificated maximum take-off weight. In this case the pilot
and/or controller are expected to determine what the value should be per the ICAO guidelines and the estimated
weight of the aircraft.
Allowable values for the aircraft type should include any type designator in ICAO Doc. 8643, and any type
designator agreed to by the implementing countries.
Note that implementers may choose to validate the wake turbulence category based on the aircraft type, since
these are published in ICAO Doc. 8643.
B.2.4 Field 10
Agreement on ATS-prescribed indicators is to be specified in separate implementation agreements.
B.2.5 Field 13
The aerodrome in Field 13 must match a location indicator in ICAO Doc. 7910, or must match one that is agreed
to per the relevant boundary agreement, or agreed to by the implementing facilities.
If ZZZZ or AFIL is used, then additional information should be present in Field 18 per ICAO Doc. 4444. This
ICD imposes no specific requirements on the content of DEP/.
B.2.6 Field 14
Field 14(a) contains a Boundary Point, which is an agreed point on or near the control boundary.
The boundary agreement between implementing countries identifies any specific requirements governing the
choice of boundary point.
B.2.7 Field 15
A CPL, per ICAO Doc. 4444, Chapter 11, Section 4.2.3.2.5 “shall include only information concerning the
flight from the point of entry into the next control area or advisory airspace to the destination aerodrome”. The
route information for a MOD message will include the same information as the CPL message. In practical
terms, each automation system generally has restrictions on the starting point of the route.
Each boundary agreement will define where the route of flight shall begin so as to meet the above requirement.
After the initial point, Field 15(c) should contain the remainder of the route of flight.
B.2.8 Field 18
In an FPL or CPL, all Field 18 content must be delimited by elements constructed as shown in ICAO Document
4444, each of which a three to four- letter identifier is followed by an oblique stroke “/”.
Field 18 shall not contain the character “-”, which is used to delineate fields in the message.
When used in an LRM, only the RMK/ element should be identified; only the text of the rejection message shall
be included.
B-5
NAS-IC-21009205
B.3 Summary of Expected Responses to Messages

Table 6 identifies the expected responses to each message. The computer logical responses represent acceptance
or rejection based on computer checks for message validity. An application response is a response that is
initiated by a person or the application software to provide semantic response to a message. Note that an LRM
can be sent in response to a message with no computer response identified if the message ID (e.g. RTU) cannot
be determined by the receiving computer.
Table B-1. Summary of Expected Message Responses

Computer Computer Logical
Logical Response Application Response Application
Msg Msg
Response Response
Accep Reject Accept Reject
t
FPL LAM LRM None RTI RLA LRM RTA
CHG LAM LRM None RTU None None None
EST LAM LRM None RLA None None None
CPL LAM LRM None RTA LAM LRM None
CNL LAM LRM None LAM None None None
MOD LAM LRM None
LRM None None None
MIS LAM LRM None
IRQ None None IRS
IRS None None None
TRQ None None TRS
TRS None None None
B-6
NAS-IC-21009205
ATTACHMENT 1 – MEXICO/UNITED STATES BOUNDARY AGREEMENT

1. Introduction
This section documents the Class 1 interface planned between the SENEAM and FAA en route automation
systems. The initial interface will have limited message capability. Future evolutions are expected to include
additional messages.
2. Message Implementation and Use
2.1 Messages Implemented

The initial interface between the SENEAM and FAA EASs will be based on a Class 1 implementation of the
Flight Data Coordination and Interface Management.
Thus, the interface will include CPL and LAM messages. A CPL will be sent when a flight departs, or when it
is within a VSP flying time from the boundary, whichever occurs later. Each CPL that is received and
successfully checked for syntactic and semantic correctness is responded to with an LAM.
2.2 Error Handling

A LAM will be sent in response to each CPL unless the receiving EAS detects an error. The EAS that sent the
CPL will wait a VSP period of time for an LAM, and if none is received within the time parameter, it will notify
the appropriate position that a failure occurred. Automatic retransmission of the message will not be attempted.
A LAM is sent in response to each CPL unless the receiving EAS detects an error. The EAS that sent the CPL
waits a VSP period of time for an LAM, and if none is received within the time parameter, it notifies the
appropriate position that a failure occurred. Automatic retransmission of the message will not be attempted.
2.3 Changes to a CPL

All changes to a previously sent CPL will be coordinated manually between the sending and receiving sectors.

Regardless of the value in Field 08(a), all CPLs sent on this interface will be assumed to be IFR at the boundary
between FAA and SENEAM airspace. Each center is only to send flight plans for flights that are IFR at the
boundary. The FAA EAS processes only the IFR portion of the route in any flight plan, and does not forward
flight plans to Flight Service Stations. Therefore any composite flight plan is expected to be filed by the user
with both Flight Service and En Route Air Traffic Control.
When a specific aircraft type is used, the wake turbulence indicator sent to EUROCAT must match the value
stored for the aircraft type in the EUROCAT database. When “ZZZZ” is used as the aircraft type, the wake
turbulence category may be H, M, or L as appropriate.

Flights on direct routes are not to be sent across the interface. In the future, expansion of the interface to allow
direct routes is expected. Enforcement of this requirement is expected to be procedural (i.e. the automation will
forward a direct route if one is entered). The following statements regarding direct routes indicate the expected
content of a message should a direct route be mistakenly sent.
1-1
NAS-IC-21009205
For flights from Mexico to the United States:
a) If a flight is on an adapted route segment when it crosses the control boundary, Field 14(a) will
reference the last significant point in the sending center’s airspace.
b) If a flight is on a direct route segment when it crosses the control boundary Field 14(a) will reference
the last significant point in the sending center’s airspace.
c) If there is no significant point between the departure aerodrome and the boundary, the departure
aerodrome will appear in Field 14(a).
All flights are expected to cross the boundary in level flight, at the altitude in Field 14(c). Elements (d) and (e)
will not be used, and manual coordination will be required for any flight not in level flight at the boundary.
Note that the FAA EAS will accept information in elements (d) and (e), but will discard that information when it
is included without performing any error checks of the information.
For flights from the United States to Mexico:

a) If a flight is on a non-adapted direct route segment and the coordination fix is adapted per ERAM direct
route crossing the control boundary Field 14(a) will reference the first significant point in the sending
center's airspace.
b) If a flight is on a non-adapted direct route segment and the coordination fix is not adapted per ERAM
direct route crossing the control boundary Field 14(a) will reference the last significant point in the
sending center's airspace
2.7 Field 15, Route

Element type (c6) will not be used on this interface.
Element 15(c) will be constructed the same way whether the flight is from Mexico or from the United States:
a) If a flight is on an adapted route segment when it crosses the control boundary then Field 15(c) will
begin with the same significant point as is in Field 14(a).
b) If a flight is on a direct route segment when it crosses the control boundary:
1) Field 15(c) will begin with the last significant point in the sending center’s airspace, if one exists.
2) If there is no significant point between the departure aerodrome and the boundary then Field 15(c)
will begin with “DCT”.
c) After the initial point, Field 15(c) will contain the remainder of the route of flight.
The FAA EAS will pass the assigned altitude (same as in Field 14(c)) in element 15(b). Note that in the future
the FAA plans to store and pass the requested altitude received in element 15(b). This boundary agreement will
be updated when that change is implemented.
The FAA EAS can accept up to 46 elements in the route of flight (Note: DCT does not count as an element).
1-2
NAS-IC-21009205
3. Physical Interface
Figure 3-1
Messages will be exchanged across this interface between the following facilities:
Los Angeles Albuquerque Houston

KZAB KZHU
KZLA
Mazatlan Monterrey Merida

MMTY MMID
MMZT
1-3
NAS-IC-21009205
1-4
NAS-IC-21009205
ATTACHMENT 2 – CANADA/UNITED STATES BOUNDARY AGREEMENT

1. Introduction
This section documents the interface established between NAV CANADA and FAA en route automation
systems.

This boundary agreement addresses conditions for exchange of all flight data messages, LAM and LRM, and
handoff messages.
2.2 Conditions for Exchange

Flight plan messages (CPL or FPL) are exchanged between en route centers for flights that are IFR at the
boundary. This includes the cases shown in Table Att. 2-1 below:
Table Att. 2-1. Summary of Flight Plan Routing in FAA and NAV CANADA Systems
Direction of Flight Flight Rules * Flight Data Routing FAA Routing
Canada to U.S. I CAATS to FAA EAS none.
V CAATS to FAA FSS none.
Y (VFR after bdry) CAATS to FAA EAS EAS to FSS
Y (VFR before bdry) CAATS/ to FAA FSS none.
Z (IFR after bdry) CAATS to FAA FSS FSS to EAS
Z (IFR before bdry) CAATS to FAA EAS none.
U.S. to Canada I FAA EAS to CAATS none.
V FAA FSS to CAATS none.
Y (VFR after bdry) FAA EAS to CAATS none.
Y (VFR before bdry) FAA FSS to CAATS none.
Z (IFR after bdry) FAA FSS to CAATS none.
Z (IFR before bdry) FAA EAS to CAATS FSS to EAS.
* NOTE: FAA EAS and Canada will prohibit the transmission of composite flight plans procedurally.
FAA EAS will determine the flight rules letter based upon the assigned or requested altitude. Therefore,
flight plan messages from the FAA EAS to Canada will be based on the assigned or requested altitude.
2.3 Aerodrome Designators (Fields 13 and 16)

Between NAV CANADA and the FAA, aerodrome designators in Fields 13 and 16 may be any four characters,
provided the first is a letter. For FPLs filed by users, if ZZZZ is entered, NAV CANADA requires that the
Lat/Long of the departure and/or destination aerodrome be entered in field 18 after the DEP/ or DEST/
designator. This information will be entered by the entity filing the flight plan. For FPLs transmitted by FAA
EAS, if “ZZZZ” is entered, FAA EAS will include a fix name, Fix Radial Distance (FRD), or Lat/Long after the
DEP/ or DEST/ indicator in field 18.
2-1
NAS-IC-21009205
2.4 Fix Radial Distance

A significant point expressed as a Fix Radial Distance (FRD) may include any two to five character fix name
provided the first character is a letter.
2.5 CPL Field 14(a) Implementation

For flights from Canada to the United States:
Field 14(a) will contain the Lat/Long of the boundary crossing point. Note that since the FAA will adapt the
Lat/Long of each boundary crossing point, any changes to boundaries or routes will require changes to the
adaptation.
For flights from the United States to Canada:
a) If a flight is on an adapted route segment when it crosses the control boundary, Field 14(a) will
reference the last point in the sending center’s airspace.
b) If a flight is on a direct route segment when it crosses the control boundary, Field 14(a) will reference
the last point in the sending center’s airspace.
2.6 CPL Field 14(c) Implementation

For flights from Canada to the United States the cleared level may include, in addition to the ICAO formats:
a) OTP
b) Block altitude, in one of the following formats:
1) AnnnBmmm, where nnn and mmm are altitudes in hundreds of feet
2) FnnnBmmm, where nnn and mmm are flight levels in hundreds of feet
For flights from the United States to CAATS the cleared level may include, in addition to the ICAO formats:
a) OTP
b) Block altitude, in one of the following formats:
1) AnnnBmmm, where nnn and mmm are altitudes in hundreds of feet
2) FnnnBmmm, where nnn and mmm are flight levels in hundreds of feet
2.7 CPL Field 14(d) and 14(e) Implementation

The crossing altitude and crossing condition may be included in a message to meet the ICAO format. This
information shall not be used for control purposes in the initial implementation. Future use of these elements
will be subject to mutual agreement by both parties.
2.8 CPL Field 15 (Route) Implementation

For flights from the United States, Field 15(c) will be constructed as follows:
a) If a flight is on an adapted route segment when it crosses the control boundary, Field 15(c) will begin
with the same significant point as is in Field 14a.
b) If a flight is on a direct route segment when it crosses the control boundary, Field 15(c) will begin with
the same significant point as is in Field 14a.
c) If there is no significant point between the departure aerodrome and the boundary, Field 15(c) will begin
with “DCT”.
2-2
NAS-IC-21009205
d) After the initial point, Field 15(c) will contain the remainder of the route of flight.
For flights from Canada, Field 15(c) will be constructed as follows:
a) If a flight is on an adapted route segment when it crosses the control boundary, Field 15(c) will begin
with the last significant point in the sending center’s airspace.
b) If a flight is on a direct route segment when it crosses the control boundary, Field 15(c) will begin with
c) If there is no significant point between the departure aerodrome and the boundary, Field 15(c) will begin
with “DCT”.
d) After the initial point, Field 15(c) will contain the remainder of the route of flight.
The FAA EAS will pass the requested altitude that was received in the flight plan. If an active flight plan with
no requested altitude was entered, the assigned altitude at the time the CPL was constructed will be used as the
requested altitude.
The FAA EAS can accept elements 15(c4) and 15(c6); however, when present, these elements are not processed
and are removed from the route of flight. Therefore no CPL from the FAA will contain these elements.
2.9 Flight Rules (Field 08)

Regardless of the value in Field 08(a), all CPLs sent on this interface will be assumed to be IFR at the border.
The FAA EAS processes only the IFR portion of the route in any flight plan, and does not forward flight plans
to Flight Service Stations. Therefore any composite flight plan is expected to be filed by the user with both
Flight Service and En Route Air Traffic Control.
2 -3
NAS-IC-21009205
Figure 2-1
FAA Anchorage Seattle Salt Lake City Minneapolis Cleveland Boston

WJHTC PAZA KZSE KZLC KZMP KZOB KZBW
Nav Canada
Technical Vancouver Edmonton Winnipeg Toronto Montreal Moncton
Systems CZVR CZEG CZWG CZYZ CZUL CZQM
Centre
Anchorage Seattle Minneapolis Cleveland Boston

PAZA KZSE KZMP KZOB KW
Technical Vancouver Edmonton Winnipeg Toronto Moncton

Systems CZVR CZEG CZWG CZYZ CZQM
Centre
2-4
NAS-IC-21009205
ATTACHMENT 3 – CUBA/UNITED STATES BOUNDARY AGREEMENT

1. Introduction
This section documents the Class 1 interface planned between the IACC and FAA en route automation systems.
The initial interface will have limited message capability. Future evolutions are expected to include additional
messages.

The initial interface between the IACC and FAA EASs will be based on a Class 1 implementation of the Flight
Data Coordination and Interface Management.
successfully checked for syntactic and semantic correctness is responded to with a LAM.
2.2 Error Handling

waits a VSP period of time for a LAM, and if none is received within the time parameter, it notifies the


between Miami Center’s airspace and Havana Center’s airspace. Each center is only to send flight plans for
flights that are IFR at the boundary. The FAA EAS processes only the IFR portion of the route in any flight
plan, and does not forward flight plans to Flight Service Stations. Therefore any composite flight plan is
expected to be filed by the user with both Flight Service and En Route Air Traffic Control.
When a specific aircraft type is used, the wake turbulence indicator sent to the IACC system must match the
value stored for the aircraft type in the IACC system database. When “ZZZZ” is used as the aircraft type, the
wake turbulence category may be H, M, or L as appropriate.

Flights on direct routes are not to be sent across the interface. In the future, expansion of the interface to allow
direct routes is expected. Enforcement of this requirement is expected to be procedural (i.e. the automation will
forward a direct route if one is entered). The following statements regarding direct routes indicate the expected
content of a message should a direct route be mistakenly sent.
a) For flights from Cuba to the United States: If a flight is on an adapted route segment when it crosses the
control boundary, Field 14(a) will reference the last significant point in the sending center’s airspace.
b) If a flight is on a direct route segment when it crosses the control boundary Field 14(a) will reference
3-1
3 -1
NAS-IC-21009205
All flights are expected to cross the boundary in level flight, at the altitude in Field 14(c). Elements (d) and (e)
will not be used, and manual coordination will be required for any flight not in level flight at the boundary.
Note that the FAA EAS will accept information in elements (d) and (e), but will discard that information when it
is included without performing any error checks of the information.
For flights from the United States to Cuba

a) If a flight is on a non-adapted direct route segment and the coordination fix is adapted per ERAM direct
route crossing the control boundary, Field 14(a) will reference the first significant point in the sending
center's airspace.
b) If a flight is on a non-adapted direct route segment and the coordination fix is not adapted per ERAM
direct route crossing the control boundary Field 14(a) will reference the last significant point in the
sending center's airspace
2.7 Field 15, Route

Element type (c6) will not be used on this interface.
Element 15(c) will be constructed as follows for flight plans from United States to Cuba
a) If a flight is on an adapted route segment when it crosses the control boundary then Field 15(c) will
begin with the same significant point as is in Field 14(a).
b) If a flight is on a direct route segment when it crosses the control boundary:
1) Field 15(c) will begin with the last significant point in the sending center’s airspace, if one exists.
2) If there is no significant point between the departure aerodrome and the boundary then Field 15(c)
will begin with “DCT”.
c) After the initial point, Field 15(c) will contain the remainder of the route of flight.
Element 15(c) will be constructed as follows for flight plans from Cuba to United States
a) If a flight is on an adapted route segment when it crosses the control boundary then Field 15(c)
will begin with the last significant point in the sending center’s airspace which is the published fix
into the adapted route segment and not the same as Field 14(a).
b) IACC does not pass direct route segments (at the time of its addition to the NAM/ICD).
Cuba IACC will pass the assigned altitude (Field 14(c)) and the requested altitude in element 15(b),
which may or may not be the same. Host/ERAM does not act on the requested altitude sub-field.
3-2
NAS-IC-21009205
Figure 3-1
Miami
KZMA
Havana
MUFH
3 -3
NAS-IC-21009205
3-4
NAS-IC-21009205
ATTACHMENT 4 – CUBA/MEXICO BOUNDARY AGREEMENT

1. Introduction
This section documents the Class 1 interface planned between the IACC (Havana) and SENEAM (Merida) en
route automation systems. The initial interface will have limited message capability. Future evolutions are
expected to include additional messages.

The initial interface between the SENEAM (Merida) and IACC (Havana) will be based on a Class 1
implementation of the Flight Data Coordination and Interface Management.
successfully checked for syntactic and semantic correctness is responded to with an LAM.
2.2 Error Handling

will wait a VSP period of time for an LAM, and if none is received within the time parameter, it will notify the


between FAA and SENEAM airspace. Each center is only to send flight plans for flights that are IFR at the
boundary.
When a specific aircraft type (ICAO) is used, the wake turbulence indicator sent must match the ICAO
8643 Document. When “ZZZZ” is used as the aircraft type, the wake turbulence category may be H, M,
or L as appropriate. and, the type of aircraft preceded by TYP/ specified in Item 18.2.6 Field 14, Estimate
Data
All Flights will be coordinated at established Boundary points (in accordance with the LOA); Flights on direct
routes are not to be sent across the interface. In the future, expansion of the interface to allow direct routes is
expected. Enforcement of this requirement is expected to be procedural (i.e. the automation will forward a
direct route if one is entered).
2.6 Field 15, Route
The Route of flight sent in the CPL message will begin from the initial point; Field 15(c) will contain the
remainder of the route of flight until the airport destination.
4 -1
NAS-IC-21009205
The Route of flight sent in the CPL message will begin with the last significant point in the sending center’s
airspace; Field 15(c) will contain the remainder of the route of flight until the airport destination
2.7 Field 18.

Field 18(a) will be constructed as follows for flight plans from Cuba to México
a) The total size will be limited to 250 characters
b) Format shall be per ICAO Doc. 4444.
c) All elements will be checked for syntax and correctness.
d) Multiple indicators will not be allowed. Only the first one will be admitted.
There are no special requirements in this field for flight plans from Mexico to Cuba (at the time of its addition to
the NAM/ICD).
Figure 4-1
Merida
MMID
Havana
MUFH
4-2

NAM AIDC ICD Ver D 20 Jan 2012

Uploaded by

Copyright:

Available Formats

NAM AIDC ICD Ver D 20 Jan 2012

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NAM AIDC ICD Ver D 20 Jan 2012

Uploaded by

Copyright:

Available Formats

North American (NAM) Common Coordination

Interface Control Document (ICD)

VOLUME 1: Area Control Center (ACC) to ACC

Date Rev. Action

About the Document ............................................................................................................................................. 1

3. List of Acronyms ........................................................................................................................................... 5

PART I – PURPOSE, POLICY, AND UNITS OF MEASUREMENT ............................................. 9

3. Units of Measurement and Data Conventions .......................................................................................... 13

PART II – NAM ATS COORDINATION MESSAGES ................................................................... 15

PART III – COMMUNICATIONS AND SUPPORT MECHANISMS .......................................... 31

2. Telecommunications Requirements and Constraints .............................................................................. 31

3. Engineering Considerations ....................................................................................................................... 31

4. Security Considerations .............................................................................................................................. 32

5. Test Considerations ..................................................................................................................................... 33

6. Performance Considerations ...................................................................................................................... 33

APPENDIX A – ERROR CODES..................................................................................................... A-1

APPENDIX B – IMPLEMENTATION GUIDANCE MATERIAL .............................................. B-1

B.1 Use of the Core Message Set ...................................................................................................................... B-1

B.2 Development of Field Content ................................................................................................................... B-4

B.3 Summary of Expected Responses to Messages ........................................................................................ B-6

ATTACHMENT 1 – MEXICO/UNITED STATES BOUNDARY AGREEMENT ...................... 1-1

1. Introduction .................................................................................................................................................... 1-1

2. Message Implementation and Use ................................................................................................................ 1-1

3. Physical Interface ........................................................................................................................................... 1-3

1. Introduction .................................................................................................................................................... 2-1

2. Message Implementation and Use ................................................................................................................ 2-1

3. Physical Interface ........................................................................................................................................... 2-4

ATTACHMENT 3 - CUBA/UNITED STATES BOUNDARY AGREEMENT…………………3-1

1. Introduction .................................................................................................................................................... 3-1

2. Message Implementation and Use ................................................................................................................ 3-1

3. Physical Interface ........................................................................................................................................... 3-4

ATTACHMENT 4 – MEXICO/CUBA BOUNDARY AGREEMENT........................................... 4-1

1. Introduction .................................................................................................................................................... 4-1

2. Message Implementation and Use ................................................................................................................ 4-1

3. Physical Interface ........................................................................................................................................... 4-4

Tables and Figures

Table 2. NAM Core Message Set ...................................................................................................................... 19

Table 3. Summary of Data Definitions Needed to Support the Interface ...................................................... 32

Table 4. Expected Message Rates and Sizes ..................................................................................................... 33

Table A-1. LRM Error Codes and Explanations ........................................................................................... A-1

Table B-1. Summary of Expected Message Responses .................................................................................. B-6

Attachment 1, Figure. 1-1. Physical Interface …..…………………..………………………………...…..1-3

Attachment 2, Figure 2-1. Physical Interface ………………………………………………………............2-4

Attachment 3, Figure 3-1. Physical Interface …………………………………………………...….............3-4

Attachment 4, Figure 4-1. Physical Interface…...………………...………………………………………....4-2

This page intentionally left blank.

About the Document

1.2 Part II- NAM ATS Coordination Messages

1.3 Part III- Communications and Support Mechanisms

Air Traffic Services The FAA, SENEAM, NAV CANADA or IACC.

Altitude a) A level of constant atmospheric pressure related to a locally measured

Character A letter from A-Z or number from 0-9.

Field A numbered logical portion of a message. All references to fields in this

Fix-radial-distance A method of specifying a geographic point. It includes the name of a fix,

Letter A letter from A-Z.

Numeric A number from 0-9.

Transaction The exchange of a message and the associated response.

Note: Definitions applicable for the purpose of this ICD

ACC Area Control Center