1090 WP30 18 Draft - Do 260B V42

Working Paper 1090-WP30-18 as DRAFT Version 4.
2 of DO-282B
RTCA, Inc.
1828 L Street, NW, Suite 805
Washington, DC 20036-5133, USA
Minimum Operational Performance Standards for

1090 MHz Extended Squitter
Automatic Dependent Surveillance Broadcast (ADS-B)
and
Traffic Information Services Broadcast (TIS-B)
This is a DRAFT Version 4.2 Working Copy of this document.

It includes the published RTCA/DO-260A, plus Change 1 and Change 2 integrated into it.
It also has implemented into it those changes identified during Meeting #23 in Working
Papers 1090-WP23-02 and1090-WP23-03R1, and those changes currently agreed to as
acceptable changes in the Change Matrix of 1090-WP2X-03.
All changes to the original DO-260A are still highlighted in yellow.
RTCA DO-260B Prepared by: SC-186

Supercedes RTCA DO-260A, 20xx, RTCA, Inc.
including Change 1 and Change 2
Working Paper 1090-WP30-18 as DRAFT Version 4.2 of DO-282B

Copies of this document may be obtained from
RTCA, Inc,
1828 L Street, NW, Suite 805
Washington, DC 20036-5133, USA
Telephone: 202-833-9339
Facsimile: 202-833-9434
Internet: www.rtca.org
Please call RTCA for price and ordering information.

Foreword
This document was prepared by Special Committee 186 (SC-186) and approved by the RTCA
Program Management Committee (PMC) on MM DD, YYYY.
RTCA, Incorporated is a not-for-profit corporation formed to advance the art and science of
aviation and aviation electronic systems for the benefit of the public. The organization functions as
a Federal Advisory Committee and develops consensus based recommendations on contemporary
aviation issues. RTCAs objectives include but are not limited to:
coalescing aviation system user and provider technical requirements in a manner that helps
government and industry meet their mutual objectives and responsibilities;
analyzing and recommending solutions to the system technical issues that aviation faces as it
continues to pursue increased safety, system capacity and efficiency;
developing consensus on the application of pertinent technology to fulfill user and provider
requirements, including development of minimum operational performance standards for
electronic systems and equipment that support aviation; and
assisting in developing the appropriate technical material upon which positions for the
International Civil Aviation Organization and the International Telecommunications Union and
other appropriate international organizations can be based.
The organizations recommendations are often used as the basis for government and private sector
decisions as well as the foundation for many Federal Aviation Administration technical Standard
Orders.
Since RTCA is not an official agency of the United States Government, its recommendations may
not be regarded as statements of official government policy unless so enunciated by the U.S.
government organization or agency having statutory jurisdiction over any matters to which the
recommendations relate.

This page intentionally left blank.

Table of Contents
i
Table of Figures
ii
Table of Tables
iii
iv
1.0 PURPOSE AND SCOPE
1.1 Introduction
This document contains Minimum Operational Performance Standards (MOPS) for airborne
equipment for Automatic Dependent Surveillance-Broadcast (ADS-B) and Traffic
Information Service Broadcast (TIS-B) utilizing 1090 MHz Mode-S Extended Squitter
(1090ES). The supporting hardware can be incorporated within other on-board equipment,
or alternatively, the ADS-B equipment may be a separate avionics unit.
Note: Definitions of acronyms (e.g., MOPS, ADS-B, 1090ES) and of many other terms
(e.g., Extended Squitter) can be found in Appendix B of these MOPS.
Throughout this document, the term TIS-B refers to the Fundamental TIS-B
Service as defined in the TIS-B MASPS, RTCA/DO-286B, 1.4.1. The acronym
ADS-R refers to the ADS-B Rebroadcast Service as defined in the TIS-B MASPS,
RTCA/DO-286B, 1.4.1. The Fundamental TIS-B Service provides traffic
information that is derived from ground surveillance (e.g., radar) systems. The
ADS-B Rebroadcast Service provides the Rebroadcast on 1090 MHz of an ADS-B
Message from an alternate data link using the same TYPE Codes and Message
Formats as are defined for Downlink Format (DF) = 17 ADS-B Messages, with the
exception of bits modified as identified in 2.2.18.
Compliance with these standards by manufacturers, installers and users is recommended as

one means of assuring that the equipment will satisfactorily perform its intended functions
under conditions encountered in routine aeronautical operations. The regulatory application
of these standards is the responsibility of appropriate government agencies. In the United
States, the Federal Aviation Administration (FAA) publishes and maintains a Technical
Standard Order (TSO C166) for ADS-B equipment to reference the requirements and bench
test procedures in Section 2 of this document.
Since the equipment implementation includes a computer software package, RTCA DO-
178B, Software Considerations in Airborne Systems and Equipment Certification,
(EUROCAE ED-12B) is applicable. When determining the level of software requirements,
as defined in RTCA DO-178B (EUROCAE ED-12B), the equipment manufacturer should
consider the criticality appropriate for the installation certification, equipment failure
analysis, and the fault monitoring being accomplished.
In addition, since the measured values of equipment performance characteristics may be a

function of the measurement method, standard test conditions and methods of test are
recommended in this document.
Section 1 of this document provides information and assumptions needed to understand the
rationale for equipment characteristics and requirements stated in the remaining sections. It
describes typical equipment applications and operational goals and, along with RTCA DO-
242A, Minimum Aviation System Performance Standards for ADS-B, forms the basis for the
standards stated in Sections 2 and 3.
20xx, RTCA, Inc.

Section 2 contains the minimum operational performance standards for the equipment.
These standards define required performance under standard operating conditions and
stressed physical environmental conditions. Also included are recommended bench test
procedures necessary to demonstrate equipment compliance with the stated minimum
requirements.
Section 3 describes the performance required of the installed equipment. Tests for the
installed equipment are included when performance cannot be adequately determined
through bench testing.
Section 4 describes the operational characteristics of the installed equipment, self test
features, and controls.
Appendix A is normative whereas Appendices B through Q are informative. The following

is a short description of each of the Appendices contained in this document:
Appendix A defines the formats and coding for Extended Squitter ADS-B and TIS-B
Messages, expanding upon the requirements of Section 2.2.
Appendix B contains a list of acronyms and definition of terms used in this document.
Appendix C discusses aircraft antenna performance characteristics and identifies

references to obtain additional information on the subject.
Appendix D defines a ground architecture that can support (1) surveillance for ATC
using Extended Squitter ADS-B reports, and (2) TIS-B service.
Appendix E contains air-to-air link budgets for each class of ADS-B equipment and
summarizes the relationships between transmitter power, receiver sensitivity, and range
under worst case and practical implementation conditions.
Appendix F presents a traceability matrix to the ADS-B MASPS (RTCA DO-242A).
Appendix G discusses transition issues for ADS-B avionics.
Appendix H discusses ADS-B report assembly and provides additional guidance on the
subject.
Appendix I identifies and discusses examples of the enhanced reception techniques for
Extended Squitter that have been shown to meet the enhanced reception performance
requirements.
Appendix J discusses determining the Navigation Accuracy Category for velocity

(NACV) and describes the rationale for the values used in Table 2-25, NACV Data.
Appendix K discusses and provides the results of an analysis that determined the affect
of report assembly on velocity accuracy.
Appendix L discusses and provides a table showing, by equipage class, the impact of
radio frequency interference on Extended Squitter report integrity.
20xx, RTCA, Inc.

Appendix M provides a description of techniques for extending the effective air-to-air

range of 1090 MHz ADS-B Subsystems, and discusses the transmission power for Class
A3 airborne installations.
Appendix N defines the formats and coding for Extended Squitter ADS-B Messages
that are broadcast by ADS-B Version Zero (0), RTCA DO-260 compliant 1090 MHz
ADS-B Subsystems, and ADS-B Version One (1), RTCA DO-260A compliant 1090
MHz ADS-B Subsystems, and defines how the ADS-B Report Generation Function of
Version Two (2) 1090 MHz ADS-B Receiving Subsystems is to utilize messages
received from targets that are broadcasting with Version Zero (0) and Version One (1)
Message formats.
Appendix O provides specifics for possible future use of additional intent

communications provided for in RTCA DO-242A as Trajectory Change (TC)
Reports.
Appendix P presents the expected 1090 MHz Extended Squitter Performance in the
LA2020 Scenario defined in the ADS-B MASPS, RTCA DO-242A, 3.3.4.
Appendix Q presents a proposed format for a Runway Threshold On-Condition

Message.
Appendix R provides a calculation of 1090 MHz Extended Squitter broadcast rates for
different operational scenarios to show that transmission rates achieved over a 60
second period meet the required average rate over 60 seconds, and that there is no need
to implement a function to limit the total number of 1090 MHz Extended Squitters
transmitted over a certain period of time.
Appendix S specifies a method such that the Time Mark and UTC time can be
synchronized at any Time within any Epoch on any sub-epoch.
Appendix T provides a tutorial and gives explanations and derivations of the Compact
Position Reporting (CPR) equations given in Appendix A. CPR encoding and decoding
can be implemented without using any of the information in this appendix but, if a CPR
implementation has problems, the information in this appendix may be helpful in
resolving the issue.
1.2 System Overview
1.2.1 Definitions
ADS-B (Automatic Dependent Surveillance Broadcast) is a function for airborne or
surface aircraft, or other surface vehicles operating within the airport surface movement
area, that periodically transmits its state vector (horizontal and vertical position, horizontal
and vertical velocity) and other information. ADS-B is automatic because no external
stimulus is required; it is dependent because it relies on on-board navigation sources and on-
board broadcast transmission systems to provide surveillance information to other users.
The aircraft or vehicle originating the broadcast may or may not have knowledge of which
users are receiving its broadcast; any user, either aircraft or ground-based, within range of
20xx, RTCA, Inc.

this broadcast, may choose to receive and process the ADS-B surveillance information.
ADS-B supports improved use of airspace, reduced ceiling/visibility restrictions, improved
surface surveillance, and enhanced safety such as conflict management.
TIS-B (Traffic Information Service Broadcast) is a function in which transmitters on the

ground provide aircraft with information about nearby aircraft. The TIS-B information is
likely to come from ground-based surveillance sensors such as air traffic control radars or
multilateration systems. However, TIS-B information broadcast on a particular radio data
link might also be derived from the reception on the ground of ADS-B Messages that were
transmitted on a different data link. For example, 1090 MHz TIS-B transmitters might
broadcast information about nearby aircraft based on ground reception of ADS-B Messages
on other data links.
For the purposes of this document, the term Aircraft/Vehicle (A/V) will refer to either 1) a
machine or device capable of atmospheric flight, or 2) a vehicle on the airport surface
movement area (i.e., runways and taxiways). For simplicity, the word aircraft is used to
refer to aircraft and vehicles, where appropriate.
Figure 1-1 shows the extent of the 1090 MHz ADS-B system and its major components.
This figure is adapted from the ADS-B MASPS, RTCA DO-242A.
As indicated in the figure, the ADS-B system includes the following components: message
generation/transmission by the source A/V, propagation medium, and message
reception/report assembling by the user. The ADS-B system does not include the sources of
the data to be sent by the source subsystem on board the transmitting aircraft. Neither does it
include the client applications, which use the information received by the ADS-B user
subsystem on board the receiving aircraft. Some ADS-B participants may be able to
transmit but not receive. In addition, some ground-based users may be able to receive but
not to transmit.
Aid to Visual
GNSS, Nav, Acquisition
and Other Data
Conflict
ADS-B Messages Message
Pilot Input Message
Message
Exchange
Report Avoidance
Exchange Assembly
(e.g., call sign) Generation
Function Function
Function Function
- Transmit - Receive
Etc.
Pressure
Altitude Message Receiving
Transmitting Transm ission at
Subsystem 1090 MHz Subsystem
Source User
1090 MHz ADS-B System Applications
Data
Figure 1-1: The Scope of the 1090 MHz ADS-B System
20xx, RTCA, Inc.

Figure 1-2 shows the extent of the 1090 MHz TIS-B system and its major components. As
indicated in Figure 1-2, only the 1090 MHz TIS-B Messages and airborne TIS-B Receiving
Subsystem are described in these MOPS.
ATC
Surveillance Ground Part of the 1090 MHz TIS-B System
Radar Surveillance
Processing
that is described in these MOPS
Multilateration
Surveillance TIS-B Messages Aid to Visual
Systems Acquisition
Message TIS-B
Distribution
1090 MHz Exchange Report
TIS-B Function Assembly
Transmitter Message - Receive Function
ADS-B Reception at Possible Future
messages from 1090 MHz Applications
other data links 1090 MHz
Link Specific
Processing Airborne TIS-B User
Source Receiving
Part of the 1090 MHz TIS-B Subsystem
Applications
Data System that is not
described in these MOPS
Figure 1-2: Scope of the 1090 MHz TIS-B System
1.2.2 1090 MHz ADS-B System

The ADS-B Messages transmitted on 1090 MHz are the Mode S Extended Squitters
(Airborne Position squitter, Airborne Velocity squitter, Surface Position squitter, etc.)
described in ICAO Doc 9871, and Appendix A of this document.
The source 1090 MHz Transmitting Subsystem may or may not be implemented in
conjunction with a Mode S transponder.
The user 1090 MHz Receiving Subsystem may or may not be implemented in conjunction
with a TCAS (Traffic Alert and Collision Avoidance System).
1.2.3 ADS-B Avionics Integrity

The integrity requirements for the total system to support ADS-B related applications are
determined for a particular airborne architecture by conducting a functional hazard
assessment and system safety assessment. For each application, the classification (typically
expressed in terms of a category such as hazardous/minor, hazardous major, etc.) of
unannunciated and unmitigated failure conditions of ADS-B avionics that cause out-of-
tolerance error conditions will be derived from these assessments.
20xx, RTCA, Inc.

Guidance on the above assessments can be found in:
SAE ARP4761 -- Guidelines and Methods for Conducting the Safety Assessment
Process on Civil Airborne Systems and Equipment;
SAE ARP4754/ED79 -- Certification Considerations for Highly-Integrated or

Complex Aircraft Systems;
JAA AMJ 25.1309 -- Advisory Material Joint, System Design and Analysis;
FAA AC 23.1309-1C Equipment, Systems, and Installations in Part 23

Airplanes;
FAA AC 25.1309-1A -- Advisory Circular, System Design and Analysis.
Presuming that all 24 parity check bits (2.2.3.2.1.7) are employed for error detection, the
1090 MHz ADS-B Message formats have been designed to support an undetected error rate
of less than 1 undetected error per 107 ADS-B Messages.
20xx, RTCA, Inc.

1.2.4 1090 MHz ADS-B Subsystem Implementations

Figure 1-3 shows the 1090 MHz ADS-B Subsystems in more detail.
PVT
Input I/F Control, Nav
Interface Modulator &
Update, Message
Status & Buffer Assembler & 1090 MHz
Encoder Transmitter
1090 MHz
Transmit
Intent Antenna
1090 MHz ADS-B Transmitting Subsystem
Report
Output
Buffer &
Interface Client
1090 MHz Message Report Applications
Receiver & Data Assembler
Demodulator Buffer Function
1090 MHz
Report
Receive
Control
Antenna Interface
(Optional)
1090 MHz ADS-B & TIS-B Receiving Subsystem
Figure 1-3: 1090 MHz ADS-B Subsystems.
1.2.4.1 Source 1090 MHz ADS-B Transmitting Subsystem

The source subsystem consists of a message generation function and a transmitting message
exchange function. The 1090 MHz ADS-B Transmitting Subsystem takes PVT (Position,
Velocity, Time), status, and intent inputs from other systems onboard the aircraft and
transmits this information on the 1090 MHz frequency as Mode S Extended Squitter
messages. The message generation function includes the input interface, message assembly,
and encoding subfunctions. The message exchange function includes the radio equipment
(modulator/transmitter) and 1090 MHz transmitting antenna subfunctions.
The ADS-B Transmitting Subsystem may be implemented either (a) using a Mode S
secondary surveillance radar transponder, or (b) using Non-Transponder-Based 1090 MHz
transmitting equipment.
1.2.4.1.1 Transponder-Based Subsystems

In a Mode S Transponder-Based Subsystem, the ADS-B Message generation function and
the modulator and 1090 MHz transmitter are present in the Mode S transponder itself. The
transmit antenna subfunction consists of the Mode S antenna(s) connected to that
transponder.
20xx, RTCA, Inc.

1.2.4.1.2 Non-Transponder-Based Subsystems

Non-Transponder-Based ADS-B Subsystems might be installed in general aviation aircraft
that have Mode A/C ATCRBS transponders rather than Mode S transponders. In such Non-
Transponder-Based ADS-B Subsystems, the message generation function and the modulator
and 1090 MHz transmitter will be housed together in the transmitting unit. The transmitting
antenna subfunction may be separate from the transmitter unit or may also be incorporated
in the unit.
Notes:
1. The term Non-Transponder-Based within the context of DO-260B is not intended to

preclude an avionics configuration with a 1090 MHz ADS-B capability integrated with
a Mode A/C ATCRBS Transponder.
2. Installation of Non-Transponder-Based 1090 MHz ADS-B equipment in airplanes

equipped with Mode-S transponders is prohibited. The transmission of squitters in
addition to TCAS interrogation responses contributes unnecessary RF energy to the
spectral environment. TCAS systems (in other airplanes) cannot take advantage of
hybrid surveillance on the ADS-B data, since the non-transponder-based data cannot be
validated by TCAS interrogation. ADS-B data is not directly available to ground
interrogators as when it is read from transponder registers.
1.2.4.2 1090 MHz ADS-B & TIS-B Receiving Subsystem

The 1090 MHz ADS-B and TIS-B Receiving Subsystem consists of a receiver message
exchange function and a Report Assembly function. The 1090 MHz Receiving Subsystem
takes ADS-B and TIS-B Mode S Extended Squitter messages and outputs information to
other systems onboard the aircraft. The message exchange function includes the 1090 MHz
receiving antenna and radio equipment (receiver/demodulator) subfunctions. The Report
Assembly function includes the message decoding, report assembly, and output interface
subfunctions. Several configurations of ADS-B Receiving Subsystems, which include the
reception portion of the ADS-B Message Exchange Function and the ADS-B Report
Assembly Function, are defined:
Type 1 ADS-B and TIS-B Receiving Subsystems receive ADS-B and TIS-B Messages
and produce application-specific subsets of ADS-B reports. Type 1 Receiving
Subsystems are customized to the particular applications using ADS-B reports. Type 1
ADS-B Receiving Subsystems may additionally be controlled by an external entity to
produce installation-defined subsets of the reports that those subsystems are capable of
producing.
Type 2 ADS-B and TIS-B Receiving Subsystems receive ADS-B and TIS-B Messages
and are capable of producing complete ADS-B and TIS-B reports in accordance with
the ADS-B equipment class. Type 2 Receiving Subsystems may be controlled by an
external entity to produce installation-defined subsets of the reports that those
subsystems are capable of producing.
The ADS-B/TIS-B Message reception function may be physically partitioned into
separate avionics from those that implement the ADS-B/TIS-B report assembly
function.
20xx, RTCA, Inc.

1.2.4.2.1 Type 1 Report Assembly Function

In Type 1 the Report Assembly Function may be closely coupled to the client application
using the information provided by the ADS-B system. In this case, the ADS-B Report
Assembly Function might reside together with the associated client application in one piece
of equipment.
An advantage of a closely coupled assembler and application is that the Report Assembly
function can be customized for the needs of the particular client application with which it is
associated. If the client application does not require all of the State Vector elements listed
in the ADS-B MASPS (RTCA DO-242A), then its associated Report Assembly function can
customize the report by not providing the unneeded State Vector elements. Again, if the
client application is only concerned with certain targets, then its Report Assembly function
can optimize performance by filtering out targets that have no relevance to that application.
In a Type 1 configuration, any further control of output reports (beyond the customization)
would require a control interface by which the client application(s) can specify which and
how reports are to be assembled or output.
The Type 1 configuration has the advantage that it places only minimal processing
requirements on the ADS-B Receiving Subsystem.
1.2.4.2.2 Type 2 Report Assembly

In Type 2 the Report Assembly Function is of a general nature and is capable of supporting
the needs of a variety of applications.
An advantage of Type 2 is that it can support the needs of a variety of client applications, as
it includes a generalized Report Assembly Function that can output reports that contain all
the elements of the SV, MS, and OC reports as described in RTCA DO-242A.
In a Type 2 configuration, any control of output reports would require a control interface by
which the client application(s) can specify which and how reports are to be assembled or
output.
1.2.4.3 Major Operating Characteristics

The 1090 MHz ADS-B/TIS-B System uses the Mode S Extended Squitter defined in the
ICAO Annex 10, Volumes III and IV, to broadcast the Aircraft/Vehicle position, intent and
other relevant information over the RF medium.
For ADS-B Messages, ICAO Doc 9871 provides the Mode S Transponder Register
definitions as well as the 56-bit data formats required for the ADS-B Messages. Appendix
A to this document specifies the formats contained in ICAO Doc 9871, plus those event-
driven messages that are now defined. The transmission rate for each of the defined
broadcast messages is defined in Appendix A and in the MOPS for Air Traffic Control
Radar Beacon System/Mode Select (ATCRBS/Mode-S) Airborne Equipment (RTCA DO-
181D) (EUROCAE ED-73C).
20xx, RTCA, Inc.

10
TIS-B Messages have not yet been incorporated into the ICAO Annex 10 SARPs, nor into
the Mode S Transponder MOPS (RTCA/DO-181D, EUROCAE ED-73C). TIS-B Messages
are defined in 2.2.17 and A.2 of this document.
The ADS-B Extended Squitters sent from a Mode S transponder use Downlink Format 17
(DF=17). Each squitter contains 112 bits, of which 56 bits contain the various navigation,
intent, and other data comprising the ADS-B information. The other 56 bits include the 5-
bit DF (Downlink Format) field, the 3-bit CA (Capability) field, the 24-bit AA (Announced
Address) field, and the 24-bit PI (Parity/Interrogator ID) field.
Non-Transponder-Based ADS-B Transmitting Subsystems and TIS-B Transmitting

equipment use DF=18. By using this format instead of DF=17, an ADS-B/TIS-B Receiving
Subsystem will know that the message comes from equipment that cannot be interrogated.
The transmitter power is based on the classification of the ADS-B equipment. For example,
ADS-B class A0 equipment may transmit at a lower power than class A3 equipment.
The operating range of the 1090 MHz Extended Squitter receiver is tailored to the
classification of the equipment as well. Class A0 equipment may have a less sensitive
receiver and thus support a comparatively short operating range. Class A3 equipment
requires a more sensitive receiver, in order to receive ADS-B Messages from aircraft that
are farther away.
The operation of the 1090 MHz ADS-B System must not have an adverse effect on other
on-board systems. The ADS-B System may be used in conjunction with these other systems
for increased accuracy and integrity of an aircrafts current navigational position and/or
intent information.
1.2.5 Typical System Operation

A departing aircraft on the ground begins broadcasting its position and velocity via the 1090
MHz ADS-B System. This broadcast is received by other aircraft and the ground based
receivers. The broadcasting aircraft also receives other aircraft broadcasts. The aircraft
processes this information for use by applications that may involve Cockpit Display of
Traffic Information (CDTI). As the aircraft taxis to its holding area, it monitors the
movement of other aircraft on the surface as well as those in final approach. The aircraft on
approach can also monitor the ground traffic and watch for a potential runway incursion
and/or a blunder on a parallel approach area.
Once in the en route airspace, the aircraft broadcasts not only its position and velocity, but
depending on the equipment classes, additional intent information. The aircraft performs
various applications with the received broadcasts from other aircraft within range. These
applications may include the use of CDTI, situational awareness, and de-confliction
planning.
As the aircraft approaches its destination (terminal area), it monitors other proximate aircraft
in order to maintain the desired separation for approach and landing.
20xx, RTCA, Inc.

11
1.2.6 ADS-B Message Content

The ADS-B Message refers to the transfer of data via 1090 MHz. An ADS-B Message is
formatted data that conveys information used in the development of ADS-B reports. State
Vector source data is provided by the platform dynamic navigation systems and sensors.
For the transponder case, the information for the state vector is contained in various
registers. When broadcast, the contents of a register are inserted in the 56-bit message field
of a 112-bit squitter transmission. The remaining 56 bits contain the aircraft address as well
as required forward error correcting parity information. Appendix A to this document
defines the contents of the various transponder registers.
1.2.7 ADS-B Report Content

The ADS-B Report refers to the restructuring of ADS-B Message data received from a 1090
MHz broadcast into various reports that can be used directly by other on-board applications.
Four report types are defined for ADS-B outputs to applications. These report types are
State Vector (SV), Mode Status (MS), Target State Report (TSR), and Air Referenced
Velocity (ARV) Report.
1.2.7.1 State Vector Report

The State Vector report contains information about an aircraft or vehicles current kinematic
state as well as a measure of the accuracy of the State Vector. Specific requirements for the
customization of this type of report may vary according to the needs of the client
applications of each participant. The State Vector data is the most dynamic of the three
ADS-B reports; hence, the applications require frequent updates of the State Vector to meet
the required accuracy for the operational dynamics of the typical flying aircraft or ground
operations of aircraft and surface vehicles.
1.2.7.2 Mode Status Report

The Mode Status report contains current operational information about the transmitting
participant. This information may include current call sign, address, and other information
that may be needed at a lower update rate than the information in the State Vector. Specific
requirements for a participant to transmit data for, and/or customize, this report type will
vary according to the ADS-B equipage class of each participant.
1.2.7.3 Target State Report

The Target State Report contains information that will be broadcast (in Aircraft Target State
and Status Messages, 2.2.3.2.7.1) when current Target State information is available. The
Target State Report contains information that is required from only certain classes of ADS-
B equipped aircraft. (See 2.2.8.3.1 for the format of the Target State Report.)
Note: The ADS-B MASPS (RTCA DO-242A) describes a more general On Condition
class of reports of which the Target State Report and the Air Referenced Velocity
Report are the only instances that have so far been defined.
20xx, RTCA, Inc.

12
1.2.7.4 Air Referenced Velocity Report

The Air Referenced Velocity Report (2.2.8.3.2) contains velocity information that is
required from only certain classes of ADS-B equipped aircraft. This report is only
generated when Air Referenced Velocity information is being broadcast in the Airborne
Velocity Message (2.2.3.2.6).
Note: Air Referenced Velocity Messages may be received from airborne aircraft that are
also broadcasting messages containing ground referenced velocity information.
ADS-B Receiving Subsystems conformant to these MOPS are required to receive
and process ground referenced and Air Referenced Velocity Messages from the
same aircraft and output the corresponding reports. Although not required in these
MOPS, future versions of these MOPS will specify under what conditions both
ground referenced and air referenced velocity would be transmitted. This is
intended to provide compatibility with anticipated future requirements for the
transmission of both types of velocity information.
1.3 Operational Applications

The various equipment classes defined within this document are intended to provide a level
of capability appropriate to a set of expected operational applications. Operational approval
for specific applications should consider the total capability of all associated equipment
installed in the aircraft. All airborne equipment will require a source of state vector data,
such as a GNSS (GPS) receiver, an inertial/multisensor navigation system, or Flight
Management System (FMS). Additional concepts, algorithms, procedures, and standards
not defined within this document will also be required. This section describes several
examples of applications that make use of ADS-B supplied information. Further examples
may be found in RTCA DO-242A.
1.3.1 General Support for Surveillance

ADS-B is a cooperative system. All participating Aircraft and Vehicles (A/V) are required,
at a minimum, to broadcast ADS-B Messages as specified in Section 2.2 of this document
for each applicable equipment class. The broadcast of these messages provides the basic
surveillance data necessary to support all other ADS-B applications.
1.3.2 Cockpit Display of Traffic Information (CDTI)

The CDTI provides the pilot with awareness of proximate traffic. A minimum system
provides only the relative position and velocity vector of nearby traffic. Displays to support
advanced applications may be required to supply additional information, pilot cues, or
advanced alerting functions.
1.3.2.1 Aid to Visual Acquisition

An aid to visual acquisition application provides the pilot with information that supports
visual acquisition as part of the normal see-and-avoid operations. Visual acquisition is
applicable under visual meteorological conditions (VMC) regardless of whether the
operations are being conducted under IFR or VFR.
20xx, RTCA, Inc.

13
1.3.2.2 Enhanced Traffic Situational Awareness

With the ability to display the full population of proximate aircraft, the CDTI may be used
as an overall situational awareness tool. The CDTI is also seen as a key element to Free
Flight operations. With mature Free Flight, and mutual controller/pilot agreement,
separation responsibility may be delegated to the pilot. In this case, the ability to
electronically see and avoid proximate aircraft becomes a necessary technology to enable
the Free Flight concept. For example, the CDTI may be used for Electronic VFR, with
pilots applying Rules of the Air (as stated in ICAO Annex 2 to the Convention of
International Aviation) to maintain safe separation.
1.3.3 Improvements to Aircraft-based Collision Avoidance

ADS-B is seen as a valuable technology to enhance operation of the Airborne Collision
Avoidance System (ACAS). ADS-B data may be used to improve surveillance
performance. It might also be used within the collision avoidance logic to reduce the
number of unnecessary alerts.
1.3.4 Conflict Management and Airspace De-confliction

Conflict management and airspace de-confliction functions may be provided both by ground
and aircraft automation systems. Aircraft conflict management functions will be used to
support cooperative separation during the periods that separation responsibility has been
delegated to the aircraft, such as in Free Flight. Ground conflict management functions will
also be in place, both as a backup and as the primary tool to monitor aircraft for conflict
detection. Airspace de-confliction based on the exchange of intent information will be used
for strategic separation.
1.3.5 ATS Conformance Monitoring

ADS-B may be used to support and enhance ATS conformance monitoring, which is the
process of ensuring that an aircraft maintains conformance to its agreed-to trajectory. The
degree of deviation from the trajectory, or the conformance bounds, is based on factors such
as the aircrafts navigation capability and the separation standards in place. Conformance
monitoring occurs for all controlled aircraft or airspace, and applies to all operational
airspace domains. In the case of protected airspace or Special Use Airspace (SUA),
conformance monitoring is performed to ensure that an aircraft does not enter or leave a
specific airspace. Conformance monitoring includes monitoring of simultaneous
approaches to multiple runways, and surface operations.
1.3.5.1 Simultaneous Approaches

A specific example of conformance monitoring is the monitoring of simultaneous
instrument approaches, a task that enables closer separation between aircraft on adjacent
approach courses due to monitoring of each approach path by an ATS controller.
Parallel approaches that are not individually monitored require a stagger between aircraft on
adjacent approaches, thus reducing arrival rates. Conformance monitoring of simultaneous
approaches using a dedicated ATS controller for each approach stream allows simultaneous
20xx, RTCA, Inc.

14
approaches to be flown. No stagger is required and the potential arrival rate can be 40
percent higher than for staggered approaches. Simultaneous approaches can be flown as
close as 5000 ft (three runways) and 4300 ft (dual runways) with controllers using
conventional sensors and displays, and as close as 3400 ft when controllers use PRM, which
is a specialized sensor for simultaneous approaches. Simultaneous approaches may also be
flown to converging runways, and in the future may be flown along curved or segmented
courses that are tailored for local airport noise and arrival procedures. ADS-B may offer a
viable alternative to expensive PRM technology to support simultaneous approaches, and
may allow simultaneous approaches at airports that cannot currently justify the cost of a
PRM or conventional equipment for simultaneous approach monitoring.
1.3.5.2 Incursion Monitoring

ADS-B information may be used to support incursion monitoring for both airborne and
surface operations. Specific zones may be defined including:
special use airspace,
restricted airspace,
hazardous weather locations,
runways and taxiways,
lighting control areas (areas where lighting is under ATS control)
weight limited or wingspan limited areas, and
other operational control zones such as noise sensitive areas.
Projected position information based on ADS-B State Vectors, when used in combination
with zone incursion monitoring, can provide early warnings to ATS and the pilot.
1.3.6 Other Applications

Other applications for ADS-B may not be directly related to ground-based surveillance,
CDTI, or a Traffic Situation Display (TSD), but still offer many users a direct economic or
operational benefit. These should be developed and exploited as a means to encourage users
to promptly and voluntarily equip with ADS-B systems. Some examples of these other
applications are as follows:
Improved Search and Rescue
Enhanced Flight Following
Lighting Control and Operation
Aircraft Rescue and Fire Fighting (ARFF) Vehicle Operations
General Aviation Operations Control
20xx, RTCA, Inc.

15
Further details on these and other potential ADS-B applications can be found in the ADS-B
MASPS, RTCA DO-242A.
1.4 ADS-B Functions

The 1090 MHz ADS-B System can be viewed as being comprised of three major functions.
These functions are the ADS-B Message Generation Function, the ADS-B Message
Exchange Function, and the ADS-B Report Assembly Function.
The ADS-B Message Generation Function is responsible for assembling and structuring the
data to be delivered via the 1090 MHz Extended Squitter. The ADS-B Message Exchange
Function is then responsible for transferring this data at the required rate across the 1090
MHz frequency link. This function encompasses both the transmission and reception of the
data. The ADS-B Report Assembly Function is responsible for structuring the received data
into the appropriate ADS-B Reports for use by onboard applications.
1.4.1 ADS-B Message Generation Function
1.4.1.1 Avionics Input Bus

The information required for the various ADS-B reports are provided to the message
generation function via avionics digital communication buses or a General Aviation
interface. The majority of the information for air carrier installations may be obtained from
avionics buses that contain ARINC 429 data labels for the required information.
1.4.1.2 Input Interface

For the transponder case, the Mode S transponder will provide the input interface for the
required ADS-B Message data. This input may come directly from the source that supplies
the data, i.e., an FMS unit, or from a data concentrator. The data concentrator would serve
as the input for all source data and transfer this data to the transponder in the case of the
1090 MHz ADS-B System.
1.4.1.3 Message Assembly/Encoder

These subfunctions accept input data from other avionics sources and process this data into
the appropriate format. For a Mode S Transponder-Based ADS-B system, this formatted
data will then be inserted into DF=17 for transmission over the 1090 MHz frequency link.
For a Non-Transponder-Based ADS-B system, the formatted data will be inserted into
DF=18 for transmission.
1.4.2 ADS-B Message Exchange Function

The ADS-B Message Exchange Function provides for transmission and reception of the
ADS-B Message over the 1090 MHz medium. The message exchange function also
provides suitable integrity for ADS-B Messages.
20xx, RTCA, Inc.

16
1.4.2.1 Modulation/Transmission Subfunction

The modulation of the ADS-B Message transmission is Pulse Position Modulation (PPM) as
specified in RTCA DO-181D (EUROCAE ED-73C). This modulation scheme is inherently
resistant to ATCRBS interference. The information content of the transmission is further
protected by parity check bits generated by a cyclic coding algorithm.
The transmitter subfunction generates the 1090 MHz carrier frequency and impresses the
ADS-B information onto the carrier frequency. For Mode S Transponder-Based
implementations, the transmitter requirements for transmission of the ADS-B data are
defined in ICAO Annex 10, Volume IV, and also RTCA DO-181D (EUROCAE ED-73C).
For Non-Transponder-Based implementations, transmitter requirements are contained in this
document.
1.4.2.2 Transmit/Receive/Antenna Subfunction

The ADS-B transmit and receive subfunctions should be supported by one or two antennas
depending upon aircraft installation for the operational unit. Two antennas are required if
the transponder is coupled with an on-board TCAS, or if the aircrafts weight or maximum
airspeed is such that diversity is specified in ICAO Annex 10. The diversity installation
should be such that one antenna is mounted on the top of the fuselage and the other on the
underside. The antennas should be capable of receiving and transmitting the 1090 MHz
frequency (D-Band).
For best coverage in the yaw plane, the ADS-B antennas should be designed to radiate and
receive vertically polarized RF signals. The antennas should be designed such that the
ADS-B System is capable of performing its intended functions. This includes all azimuth
headings with respect to any radial direction from another ADS-B System receiver when in
the transmit mode or to another ADS-B transmitter when in the receive mode.
Note: For the transponder case, the antenna should also be capable of receiving the 1030
MHz frequency for use in the ATCRBS/Mode S environment.
These subfunctions should be designed to receive the RF signals of airborne aircraft and
Aircraft/Vehicles operating on the ground. Detailed requirements are given in Section 2.2
to establish a receive antenna suitable for the ADS-B function.
1.4.2.3 Receiver/Demodulator Subfunction

The ADS-B Message is received over the 1090 MHz frequency link, demodulated, and
output to the Report Assembly function. The minimum trigger level (MTL) defines the
minimum input power that results in reliable reception and is suitable for receiving the
information necessary for an ADS-B report. The MTL may vary to effectively increase or
reduce the range depending on the phase of flight. Dynamic MTL may be used to reject low
level multipath and interference.
20xx, RTCA, Inc.

17
1.4.3 ADS-B Report Assembly Function
1.4.3.1 Decoder/Report Assembly

Once the ADS-B Message is received, the decoder and message assembly subfunctions
provide all control, decoding, and formatting functions needed to convert the received
messages into the appropriate formatted reports for use by client applications. These
subfunctions may be performed in the 1090 MHz receiver unit itself or an external
processing unit that interfaces to the receiver.
Since the ADS-B information will be transmitted in multiple messages, the message
assembler may require the use of a tracker. The message assembly and tracking processor
will structure the received messages into the appropriate output data reports. It also verifies
that the output data reports are valid prior to delivery to the Output Interface subfunction.
1.4.3.2 Output Interface

The Report Assembly function will output information through the interface for use by
client applications that may involve CDTI. The Report Assembly/output processor serves
as the output control for ADS-B Message data and transfers this data to client applications.
1.4.3.3 Avionics Output Bus

The information required for the various client applications is provided by the Report
Assembly function, via avionics digital communication buses or a General Aviation
interface. The majority of the information for air carrier installations may be delivered with
avionics buses that contain ARINC 429 data labels for the required information.
1.5 Operational Goals

The aviation industry has articulated the goal of leveraging ADS-B equipage, in conjunction
with technologies/services such as GPS, Traffic Information ServiceBroadcast (TIS-B),
Flight Information ServiceBroadcast (FIS-B), and two-way digital aeronautical data link,
to support operational enhancements leading toward free flight [Joint Government/Industry
Plan for Free Flight Operational Enhancements, August 1998, RTCA Flight Select
Committee]. A number of the operational applications cited in Section 1.3 are involved in
this effort, most notably to support Improved Terminal Operations in Low Visibility
Conditions, Enhanced Visual Operations and Situational Awareness, Enhanced Operations
for En Route and Oceanic Air-to-Air, Improved Surface/Approach Operations, a Surface
and Airport Vicinity Display for the Controller, Use of ADS-B in Non-Radar Airspace, and
Use of ADS-B to Enhance Radar and Automation Performance. ADS-B is a technical
linchpin for supporting seven of the ten identified operational enhancements.
Operational scenarios have been developed for each of the above Free Flight Enhancements,
and more detailed operational concepts are being completed. The detailed operational
concepts are being used to develop a comprehensive roadmap for surveillance airborne and
ground system development and interoperability.
20xx, RTCA, Inc.

18
1.6 Assumptions and Rationale

Throughput requirements for ADS-B Message reception have been developed so that the
equipment can process the maximum number of messages that can be supplied on the 1090
MHz medium. The ADS-B Report Assembly function, whether or not physically collocated
with the ADS-B Message reception function, will similarly be required to be capable of
accepting this number of messages as output by the ADS-B receiver function.
1.7 Test Procedures

The test procedures specified in Sections 2.4 and 3 are intended to be used as recommended
means of demonstrating compliance with the minimum acceptable performance parameters
specified herein. Although specific test procedures are cited, it is recognized that other
methods may be suitable. These alternate procedures may be used if they provide at least
equivalent information. In such cases, the procedures cited herein should be used as one
criterion in evaluating the acceptability of the alternate procedures.
1.7.1 Environmental Tests

Environmental tests are specified in Section 2.3. These tests, like bench tests, are performed
at the equipment level. The procedures and their associated requirements provide a
laboratory means of determining the electrical and mechanical performance of the
equipment under conditions expected to be encountered in actual aeronautical operations.
Test results may be used by equipment manufacturers as design guidance, in preparation of
installation instructions and, in certain cases, for obtaining formal approval of equipment
design and manufacture.
1.7.2 Qualification Tests

The test procedures specified in Section 2.4 provide a means to demonstrate equipment
performance in a simulated environment. Test results may be used as design guidance for
monitoring manufacturing compliance and, in certain cases, for obtaining formal approval
of equipment design and manufacture.
Test procedures contained in Section 2.4 apply to the minimum system requirements in
accordance with the minimum performance parameters specified in these MOPS.
1.7.3 Installed Tests

The installed test procedures and their associated limit requirements are in Section 3.
Although bench and environmental test procedures are not a part of installed tests, their
successful completion is normally a precondition to the completion of the installed tests.
Installed tests are normally performed on the ground and in flight.
The test results may be used to demonstrate equipment functional performance in the
environment in which it is intended to operate and with the minimum service to be
provided.
20xx, RTCA, Inc.

19
1.8 MASPS Compliance

A detailed listing of compliance with the ADS-B MASPS is contained in Appendix F.
1.9 Definition of Key Terms

Appendix B provides a glossary of the terms used in this document. This section expands
upon the definitions of key terms in order to increase document clarity and establish a
common foundation of terminology.
ADS-B Broadcast and Receive Equipment - Equipment that can transmit and receive ADS-
B Messages. Defined as Class A equipment.
ADS-B Broadcast Only Equipment - Equipment that can transmit but not receive ADS-B
Messages. Defined as Class B equipment. Includes Transponder-Based equipment that is
capable of receiving 1030 MHz SSR interrogations.
ADS-B Message - A modulated packet of formatted data that conveys information used in
the development of ADS-B reports.
ADS-B Receiver or 1090 MHz Receiver - An ADS-B Receiving Subsystem that is not part
of a TCAS 1090 MHz receiver.
ADS-B Report - Specific Information provided by the ADS-B user participant subsystem to
external applications. Reports contain identification, state vector, and status/intent
information. Elements of the ADS-B Report that are used and the frequency with which
they must be updated will vary by application. The portions of an ADS-B Report that are
provided will vary by the capabilities of the transmitting participant.
Non-Transponder-Based Implementation - An ADS-B Transmitting Subsystem that is not

part of a Mode S transponder.
TCAS Implementation An ADS-B Receiving Subsystem implemented as part of a TCAS

receiver.
Transponder-Based Implementation - An ADS-B Transmitting Subsystem implemented as

part of, or added capability to, a Mode S transponder.
20xx, RTCA, Inc.

20
2.0 Equipment Performance Requirements and Test Procedures
2.1 General Requirements
2.1.1 Airworthiness
In the design and manufacture of the equipment, the manufacturer shall provide for
installation so as not to impair the airworthiness of the aircraft.
2.1.2 Intended Function

The equipment shall perform its intended function(s), as defined by the manufacturer, and
its proper use shall not create a hazard to other users of the National Airspace System.
Note: A manufacturer defines the functions to be included in a particular piece of

equipment, and these functions will then comply with the applicable MOPS.
2.1.3 Federal Communications Commission Rules

All equipment shall comply with the applicable rules of the Federal Communications
Commission.
2.1.4 Fire Protection

All materials shall be self-extinguishing except for small parts (such as knobs, fasteners,
seals, grommets and small electrical parts) that would not contribute significantly to the
propagation of a fire.
Note: One means of showing compliance is contained in Federal Aviation Regulations

(FAR), Part 25, Appendix F.
2.1.5 Operation of Controls

The equipment shall be designed so that controls intended for use in flight cannot be
operated in any position, combination or sequence that would result in a condition
detrimental to the reliability of the equipment or operation of the aircraft. If the optional
Extended Squitter inhibit capability per 2.1.5.1 is included, a means shall be provided to
annunciate this status to the pilot.
2.1.5.1 Optional Extended Squiter Inhibit

There is no requirement to include a control to allow pilot entry to inhibit the transmission
of Extended Squitters. However, if Extended Squitter capability is supported as per RTCA
DO-181D, 2.2.23 (EUROCAE ED-73C, 3.28), Minimum Operational Performance
Standards for Air Traffic Control Radar Beacon System/Mode Select (ATCRBS/Mode S)
Airborne Equipment, dated October 2, 2008, the requirements of RTCA DO-181D, 2.2
(EUROCAE ED-73C, 3.0) apply, including the loading and servicing of the Extended
Squitter related ground initiated Comm-B Registers identified in RTCA DO-181D, 2.2.23
(EUROCAE ED-73C, 3.28), but with the following exceptions:
20xx, RTCA, Inc.

21
1. The RF transmission of Extended Squitter messages is disabled when Extended

Squitters are inhibited by pilot entry, consistent with the power limit requirements of
RTCA DO-181D, 2.2.3.3 (EUROCAE ED-73C, 3.3.4).
2. The transponder is not considered failed, as per RTCA DO-181D, 2.2.10.2

(EUROCAE ED-73C, 3.14.2), when Extended Squitters are not transmitted as a result
of Extended Squitter being inhibited by pilot entry.
3. For the purposes of determining whether to transmit the acquisition squitter as per
RTCA DO-181D, 2.2.18.2.6 (EUROCAE ED-73C, 3.22.2.6), acquisition squitters are
always transmitted when Extended Squitters are inhibited by pilot entry.
2.1.6 Accessibility of Controls

Controls that do not require adjustment during flight shall not be readily accessible to flight
personnel.
2.1.7 Equipment Interfaces

The interfaces with other aircraft equipment shall be designed such that, properly installed
with adequately designed other equipment, normal or abnormal ADS-B equipment
operation shall not adversely affect the operation of other equipment nor shall normal or
abnormal operation of other equipment adversely affect the ADS-B equipment except as
specifically allowed.
2.1.8 Effects of Test

The equipment shall be designed so that the application of specified test procedures shall
not be detrimental to equipment performance following the application of these tests, except
as specifically allowed.
2.1.9 Design Assurance

The equipment shall be designed to the appropriate design assurance level(s) based on the
intended application of the equipment and aircraft class in which it is to be installed. The
appropriate design assurance level(s) are determined by an analysis of the failure modes of
the equipment and a categorization of the effects of the failure on the operation of the
aircraft. For the purpose of this analysis, a failure is defined as either a loss of function or
the output of misleading information. Additional guidance is contained in Advisory
Circulars AC 23.1309-1C and AC 25.1309-1A.
Software included as part of the equipment shall be developed in compliance with the
appropriate software level as specified in RTCA DO-178B, Software Considerations in
Airborne Systems and Equipment Certification (EUROCAE ED-12B).
2.1.10 Integration and Interoperability with a Mode S Transponder

If the ADS-B equipment is integrated into a Mode S transponder, the transponder functions
shall meet the appropriate requirements specified in the MOPS for Air Traffic Control
20xx, RTCA, Inc.

22
Radar Beacon System/Mode Select (ATCRBS/Mode S) Airborne Equipment (RTCA DO-

181D) (EUROCAE ED-73C).
If the ADS-B equipment is designed as a stand-alone system, it shall be interoperable within

the Mode S environment.
2.1.11 Equipage Class Definitions

ADS-B equipment is categorized into aircraft system equipage classes as defined in Table 3-
1 of RTCA DO-242A (ADS-B MASPS). For 1090 MHz ADS-B equipment, those
definitions are repeated in these MOPS in Table 2-1.
The Class A Aircraft/Vehicle Classes (A0, A1, A2, and A3) are as defined in RTCA DO-
242A. Class A equipment is interactive, transmit and receive equipment, used for both
aircraft and vehicles. The ADS-B MASPS A1 equipment has been further divided into
two classes, based on antenna diversity. For A1 installations using a single antenna, the
A1 Single class is created, and abbreviated throughout this document as A1S. A1
installations with diversity antennas are abbreviated throughout this document as A1. The
only equipment difference between classes A1 and A1S is antenna diversity.
The ADS-B MASPS B0 class (broadcast-only aircraft) is defined as having transmitter

characteristics and payload capability identical to the 1090 MHz A0 interactive aircraft
class. The ADS-B MASPS B1 class (broadcast-only aircraft) is defined as having
transmitter characteristics and payload capability identical to the 1090 MHz A1 interactive
aircraft class. The ADS-B MASPS B1 equipment has been further divided into two
classes, based on antenna diversity. For B1 installations using a single antenna, the B1
Single class is created, and abbreviated throughout this document as B1S. B1
installations with diversity antennas are abbreviated throughout this document as B1. The
only equipment difference between classes B1 and B1S is antenna diversity.
The characteristics of the 1090 MHz B2 class (broadcast-only ground vehicle) are defined
in Table 2-1.
The characteristics of the 1090 MHz B3 class (broadcast-only fixed or moveable obstacle)
are defined in Table 2-1. The payload capability supports the surface position, height of
highest point, and identification (including Emitter Category) of the obstacle, so that both
State Vector and Mode Status reports must be supported. Moveable obstacles require a
position source. A moveable obstacle is one that can change its position, but only slowly,
such that its horizontal velocity may be ignored.
Requirements for Class C ground-based receive-only equipment are not addressed in this
document.
2.1.12 Equipage Class Categories

ADS-B equipment is categorized into aircraft system equipage classes as specified in the
ADS-B MASPS (RTCA DO-242A) and as summarized in Table 2-1. These class categories
are based on both the aircrafts on-board transmitter and receiver capabilities. The system
classes are then broken down into subsystem equipment classes that are based on the
20xx, RTCA, Inc.

23
individual unit specifications (refer to 2.1.12.1 and 2.1.12.2). Table 2-2 lists the different
types of ADS-B Messages in the 1090 MHz ADS-B system.
Table 2-1: ADS-B Aircraft System Classes

Class Subsystem Features
Interactive Aircraft/Vehicle Participant Systems (Class A)
Minimum Interactive
A0 Lower transmit power and less sensitive receive than Class A1.
Aircraft/Vehicle
Standard transmit power and more sensitive receiver. Class A1

A1S/A1 Basic Interactive Aircraft
implements Antenna Diversity (Note)
Standard transmit power and more sensitive receiver. Interface with

Enhanced Interactive
A2 avionics source required for aircraft trajectory intent data. Antenna
Aircraft
Diversity (Note)
More sensitive receiver. Interface with avionics source required for

Extended Interactive aircraft trajectory intent data.
A3
Aircraft
Antenna Diversity (Note)
Broadcast-Only Participant Systems (Class B)

Transmit power may be matched to coverage needs. Nav data input
B0 Aircraft Broadcast Only
required.
Transmit power may be matched to coverage needs. Nav data input

B1S/B1 Aircraft Broadcast Only
required. Class B1 implements Antenna Diversity (Note)
Ground Vehicle Transmit power matched to surface coverage needs. High accuracy
B2
Broadcast Only Nav data input required.
Fixed coordinates. No Nav data input required. Collocation with

B3 Fixed Obstacle
obstacle not required with appropriate broadcast coverage.
Ground Receive Systems (Class C)

ATS En Route and Requires ATS certification and interface to ATS sensor fusion
C1
Terminal Area Operations system.
ATS Parallel Runway and Requires ATS certification and interface to ATS sensor fusion
C2
Surface Operation system.
Flight Following Does not require ATS interface. Certification requirements

C3
Surveillance determined by user application.
Note:. See 3.3.1 for Antenna Diversity.
20xx, RTCA, Inc.

24
Table 2-2: ADS-B Message To Requirement Cross-Reference Table

Message Reference Section
AIRBORNE POSITION 2.2.3.2.3
SURFACE POSITION 2.2.3.2.4
AIRCRAFT IDENTIFICATION and CATEGORY 2.2.3.2.5
AIRBORNE VELOCITY 2.2.3.2.6.1-
(Subtypes 1, 2, 3, & 4) 2.2.3.2.6.4
TARGET STATE AND STATUS 2.2.3.2.7.1
(Subtype=1)
AIRCRAFT OPERATIONAL STATUS 2.2.3.2.7.2
TEST MESSAGE 2.2.3.2.7.3
(Subtype 0)
SURFACE SYSTEM STATUS 2.2.3.2.7.4
RESERVED MESSAGE TYPES 2.2.3.2.7.5 - 2.2.3.2.7.6
RESERVED FOR TRAJECTORY CHANGE 2.2.3.2.7.7
MESSAGE
EXTENDED SQUITTER AIRCRAFT STATUS 2.2.3.2.7.8
(Subtypes 1 and 2)
RESERVED MESSAGE TYPE 2.2.3.2.7.9
2.1.12.1 Transmitting Subsystem

An ADS-B Transmitting Subsystem is classified according to the units range capability and
the set of parameters that it is capable of transmitting. Manufacturers should take into
consideration the equipments intended operation when determining the minimum set of
messages that the unit will be required to transmit (refer to Table 2-3 and Table 2-4).
20xx, RTCA, Inc.

25
Table 2-3: ADS-B Class A Transmitter Equipment To Message Coverage

Minimum
MASPS Requirement Minimum Message Capability Required
Transmitter Class Transmit Power
(RTCA DO-242A) (From Table 2-2)
(at Antenna Port)
Airborne Position
A/C Identification & Category
SV
Airborne Velocity
MS
A0 A/C Operational Status
70 W Extended Squitter A/C Status
(Minimum) Surface Position
SV A/C Identification & Category
MS A/C Operational Status
Extended Squitter A/C Status
Airborne Position
SV
Airborne Velocity
MS
A1S/A1 A/C Operational Status
125 W Extended Squitter A/C Status
(Basic) Surface Position
Airborne Position
SV
Airborne Velocity
MS
A/C Operational Status
TS
A2 TC+0 Extended Squitter A/C Status
125 W Target State and Status
(Enhanced) Reserved for TC Message
Surface Position
Airborne Position
SV
Airborne Velocity
MS
TS
A3 TC+n Extended Squitter A/C Status
200 W Target State and Status
(Extended) Reserved for TC Message
Surface Position
20xx, RTCA, Inc.

26
Table 2-4: ADS-B Class B Transmitter Equipment To Message Coverage

Minimum MASPS Requirement
Transmitter Minimum Message Capability Required
Transmit Power (RTCA
Class (From Table 2-2)
(at Antenna Port) DO-242A)
Airborne Position
A/C Identification and Category
Airborne Velocity
B0 SV
(Aircraft) 70 W 1 MS Extended Squitter A/C Status
Surface Position
Airborne Position
Airborne Velocity
B1S/B1 A/C Operational Status
SV
125 W 1 MS Extended Squitter A/C Status
(Aircraft)
Surface Position
B2 Surface Position
SV
(Ground 70 W 1 MS A/C Identification and Category
Vehicle) A/C Operational Status
B3 Airborne Position
SV
(Fixed 70 W 1 MS A/C Identification and Category
Obstacle) A/C Operational Status
1
May be increased based upon application specific needs.
Notes: (Table 2-3 and Table 2-4):
1. SV = State Vector, MS = Mode Status, TS = Target State, TC = Trajectory Change
2. SV elements are specified in Table 2-81.
3. MS elements are specified in Table 2-88.
20xx, RTCA, Inc.

27
4. On-Condition reports is a category that includes multiple report types. Each

specific On-Condition report type includes the following elements:
Target State Report (see Table 2-94)
o Time of Applicability
o Horiztonal Short Term Intent
o Vertical Short Term Intent
Air Referenced Velocity Report (see Table 2-96)
o Address (the ICAO 24-bit Address)
o Time of Applicability
o Airspeed
o Heading
Reserved for Trajectory Change Reports
2.1.12.2 Receiving Subsystem

An ADS-B Receiving Subsystem is classified by the sensitivity and the set of parameters
that it is capable of formatting into reports. Manufacturers should take into consideration
the equipments intended operation when determining the minimum set of reports that the
unit will be required to develop (refer to Table 2-5, Table 2-6 and Table 2-6A).
20xx, RTCA, Inc.

28
Table 2-5: ADS-B Class A Receiver Equipment To Report Coverage

Minimum MASPS
Trigger Requirement
Receiver Class Reception Minimum Report Required
Threshold [RTCA DO-242A
Technique
Level (MTL) Table 3-3(a)]
ADS-B State Vector Report
A0 SV (2.2.8.1)
-72 dBm Standard AND
(Minimum) MS ADS-B Mode Status Report
(2.2.8.2)
(2.2.8.1)
AND
SV ADS-B Mode Status Report
A1S/A1 Enhanced
-79 dBm MS (2.2.8.2)
(Basic) (2.2.4.4) AND
ARV
ADS-B Air Referenced Velocity
Report (ARV)
(2.2.8.3.2)
(2.2.8.1)
AND
ADS-B Mode Status Report
SV (2.2.8.2)
MS AND
A2 Enhanced ADS-B Target State Report
-79 dBm TS
(Enhanced) (2.2.4.4) (2.2.8.3.1)
ARV AND
ADS-B ARV Report
TC+0
(2.2.8.3.2)
AND
Reserved for ADS-B Trajectory
Change Reports
(2.2.8.1)
AND
SV (2.2.8.2)
MS AND
A3 Enhanced ADS-B Target State Report
-84 dBm TS
(Extended) (2.2.4.4) (2.2.8.3.1)
ARV AND
ADS-B ARV Report
TC+n
(2.2.8.3.2)
AND
Change Reports
20xx, RTCA, Inc.

29
Table 2-6: ADS-B Class C Receiver Equipment To Report Coverage

MASPS
Minimum Trigger Requirement
Receiver Threshold Level
Operation Minimum Report Required
Class (MTL) [RTCA DO-242A
Table 3-3(b)]
ADS-B State Vector Report (2.2.8.1)
AND
SV ADS-B Mode Status Report (2.2.8.2)
C1 MS AND
Supports Cooperative
(ATS En Not Specified in ATC Surveillance TS ADS-B Target State Report (2.2.8.3)
Route and these MOPS Services
AND
Terminal) ARV ADS-B ARV Report (2.2.8.3.2)
AND
TC+n Reserved for ADS-B Trajectory
Change Report(s)
ADS-B State Vector Report (2.2.8.1)
AND
SV ADS-B Mode Status Report (2.2.8.2)
C2 MS AND
Supports Cooperative
(Approach Not Specified in ATC Surveillance TS ADS-B Target State Report (2.2.8.3.1)
and these MOPS Services
AND
Surface) ARV ADS-B ARV Report (2.2.8.3.2)
AND
TC+n Reserved for ADS-B Trajectory Change
Report(s)
C3 Supports Private User SV ADS-B State Vector Report (2.2.8.1)
Not Specified in
(Flight these MOPS Operations Planning and AND
Flight Following MS ADS-B Mode Status Report (2.2.8.2)
Following)
Note: (Table 2-5 and Table 2-6):
SV = State Vector, MS = Mode Status, OC = On-Condition TS = Target State,

ARV = Air Referenced Velocity, TC = Trajectory Change
20xx, RTCA, Inc.

30
Table 2-6A: ADS-B Class R Receive-Only Equipment To Report Coverage

Minimum MASPS
Trigger Requirement
Receiver Class Reception Minimum Report Required
Threshold [RTCA DO-242A
Technique
Level (MTL) Table 3-3(a)]
R0 SV (2.2.8.1)
-72 dBm Standard AND
(Minimum) MS ADS-B Mode Status Report
(2.2.8.2)
(2.2.8.1)
AND
SV ADS-B Mode Status Report
R1S/R1 Enhanced
-79 dBm MS (2.2.8.2)
(Basic) (2.2.4.4) AND
ARV
ADS-B Air Referenced Velocity
Report (ARV)
(2.2.8.3.2)
(2.2.8.1)
AND
SV (2.2.8.2)
MS AND
R2 Enhanced ADS-B Target State Report
-79 dBm TS
(Enhanced) (2.2.4.4) (2.2.8.3.1)
ARV AND
ADS-B ARV Report
TC+0
(2.2.8.3.2)
AND
Change Reports
(2.2.8.1)
AND
SV (2.2.8.2)
MS AND
R3 Enhanced ADS-B Target State Report
-84 dBm TS
(Extended) (2.2.4.4) (2.2.8.3.1)
ARV AND
ADS-B ARV Report
TC+n
(2.2.8.3.2)
AND
Change Reports
20xx, RTCA, Inc.

31
2.2 Minimum Performance Standards - Standard Conditions and Signals
2.2.1 Definition of Standard Conditions

Unless otherwise noted, the signal levels specified for transmitting devices in this subsection
exist at the antenna end of a transmitter to antenna transmission line of loss equal to the
maximum for which the transmitting function is designed.
Likewise, unless otherwise noted, the signal levels specified for receiving devices in this
subsection exist at the antenna end of an antenna to receiver transmission line of loss equal
to the maximum for which the receiving function is designed.
Note: Transmitting or receiving equipment may be installed with less than the designed
maximum transmission line loss. Nevertheless, the standard conditions of this
document are based on the maximum design value. Insertion losses internal to the
antenna should be included as part of the net antenna gain.
2.2.2 ADS-B Transmitter Characteristics
2.2.2.1 Mode S Transponder-Based Transmitters

a. Transmitters for Class A1, A1S, B1 and B1S systems shall be based on Mode S
transponders with RF Peak Output Power levels as specified in 2.2.2.1.1.2.
Transmitters for Class A2, A3 systems shall be based on Mode S transponders with RF
Peak Output Power levels as specified in 2.2.2.1.1.3, or 2.2.2.1.1.4, respectively, for
the class of equipment.
b. Transmitters for Class A0 and Class B0 systems may also be based on Mode S
transponders with RF Peak Output Power levels as specified in 2.2.2.2.10.
c. If the ADS-B transmitter is based on Mode S transponders, then for transponder

functions it shall comply with RTCA DO-181D (EUROCAE ED-73C) for each class of
transponder specified in the latest version of FAA TSO-C112. For ADS-B functions, it
shall comply with the latest version of FAA TSO-C166.
2.2.2.1.1 RF Peak Output Power (minimum)

The minimum RF peak output power of each pulse of each transmitted message at the
terminals of the antenna shall be as provided in the following subparagraphs for each class
of equipment addressed.
2.2.2.1.1.1 Class A0 ADS-B Transponder-Based Transmitter Power

The minimum RF peak output power for Class A0 ADS-B Transponder-Based equipment
shall be 18.5 dBW (70 W).
20xx, RTCA, Inc.

32
2.2.2.1.1.2 Class A1S and A1 ADS-B Transponder-Based Transmitter Power

The minimum RF peak output power for Class A1S and A1 ADS-B Transponder-Based
equipment shall be 21.0 dBW (125 W).


2.2.2.1.1.5 Class B ADS-B Transponder-Based Transmitter Power

The minimum RF peak output power for Class B0, B2 and B3 ADS-B Transponder-Based
equipment shall be 18.5 dBW (70 W). The minimum RF peak output power for Class B1S
and B1 ADS-B Transponder-Based equipment shall be 21.0 dBW (125 W).
2.2.2.1.2 RF Peak Output Power (maximum)

The maximum RF peak output power of each pulse of each transmitted message at the
terminals of the antenna shall be fixed at 27.0 dBW (500 W) for all classes of Transponder-
Based equipment.
2.2.2.2 Stand Alone Transmitters

Stand Alone Transmitters for Class A0 and Class B0 equipment are those implemented
independent of a Mode S transponder. Such transmitters shall comply with the ADS-B
requirements of the latest version of FAA TSO-C166 and shall meet the requirements
specified in the following subparagraphs.
Note: A 1090 MHz Non-Transponder-Device (NTD) is intended to provide the lowest cost
implementation of Extended Squitter for low-end General Aviation (GA) users. A
NTD implementation does not use the 1090 MHz spectrum as efficiently nor provide
all of the system benefits as a Mode S Transponder implementation. For this
reason, its use is restricted to class A0 operation in order to limit the number of
such devices. Examples of the spectrum efficiency and system benefit issues related
to NTDs are as follows:
1. TCAS will not be able to benefit from the ADS-B information from the NTD.
TCAS will only monitor ADS-B data reported in DF=17 squitters (as emitted by
a Mode S transponder). DF=18 squitters from NTDs are not monitored since
TCAS must assume that it cannot interrogate the aircraft (via Mode S) to
validate the range and approximate bearing via active interrogations through a
process called hybrid surveillance.
20xx, RTCA, Inc.

33
2. Mode S interrogators will not be able to benefit from the ADS-B information
from the NTD. Mode S interrogators will not be able to read Extended Squitter
messages via direct air-ground readout. Such readout requires that the ADS-B
data is available in the transponder registers. This will not be the case for a
NTD.
3. More interference is generated. An aircraft equipped with a NTD and a Mode

A/C transponder will generate more interference than a Mode S transponder
implementation of Extended Squitter. Examples are as follows: (a) For a
transponder implementation, TCAS will (after validation) maintain an aircraft
on passive surveillance unless it becomes a near threat or a threat. For the
NTD case, the aircraft will emit Extended Squitters and be regularly
interrogated by TCAS. (b) A Mode S transponder implementation of Extended
Squitter offers a surface surveillance system the possibility of controlling the
squitter rate to reduce un-necessary transmissions.
2.2.2.2.1 Transmission Frequency

The carrier frequency of ADS-B Message transmissions shall be 1090 1 MHz.
Note: This requirement is consistent with ICAO Annex 10, Volume IV, fourth edition, July
2007, 3.1.2.2.1, and RTCA DO-181D, 2.2.3.1 (EUROCAE ED-73C, 3.3.1).
2.2.2.2.2 Transmission Spectrum

Spectrum requirements for the ADS-B transmitted message are provided in 2.2.3.1.3 and
Table 2-7 of these MOPS.
Note: The requirements provided are consistent with requirements of ICAO Annex 10,
Volume IV, fourth edition, July 2007, 3.1.2.2.2 and Figure 3-5, as well as with the
requirements of RTCA DO-181D (EUROCAE ED-73C).
2.2.2.2.3 Modulation
The ADS-B transmitted message shall consist of a preamble and a data block. The
preamble shall be a 4-pulse sequence and the data block shall be binary pulse-position
modulated at a 1 megabit per second data rate.
Note: This requirement is consistent with ICAO Annex 10, Volume IV, fourth edition, July
2007, 3.1.2.2.4. Requirements consistent with RTCA DO-181D, 2.2.4.2.1
(EUROCAE ED-73C, 3.6.1 and 3.6.2) are provided in 2.2.3.1.1 of this
document.
2.2.2.2.4 Pulse Shapes

Pulse shape requirements of the ADS-B transmitted message are provided in 2.2.3.1.3 of
these MOPS.
20xx, RTCA, Inc.

34
Note: The requirements provided are consistent with the requirements of ICAO Annex 10,
Volume IV, fourth edition, July 2007, 3.1.2.2.4.1 and Table 3-2, as well as with the
requirements of RTCA DO-181D, 2.2.4.2.3 (EUROCAE ED-73C, 3.3.2 and
3.6.4).
2.2.2.2.5 Message Structure

Message structure requirements of the ADS-B transmitted message are provided in 2.2.3.1
and Figure 2-1 of these MOPS.
Note: The requirements are consistent with the requirements of ICAO Annex 10, Volume
IV, fourth edition, July 2007, 3.1.2.2.5 and Figure 3-6, as well as with the
requirements of RTCA DO-181D, 2.2.4.2 and Figure 2-3 (EUROCAE ED-73C,
3.6.1 and Figure 3-2).
2.2.2.2.6 Pulse Intervals

Pulse interval requirements of the ADS-B transmitted message are provided in 2.2.3.1.4 of
these MOPS.
IV, fourth edition, July 2007, 3.1.2.2.5.1, as well as with the requirements of RTCA
DO-181D, 2.2.4.2.4 (EUROCAE ED-73C, 3.6.5).
2.2.2.2.7 Preamble
Preamble requirements of the ADS-B transmitted message are provided in 2.2.3.1.1 of
these MOPS.
IV, fourth edition, July 2007, 3.1.2.2.5.1.1, as well as with the requirements of
RTCA DO-181D, 2.2.4.2.1 (EUROCAE ED-73C, 3.6.1).
2.2.2.2.8 Data Pulses

Requirements for data pulses of the ADS-B transmitted message are provided in 2.2.3.1.2
of these MOPS.
2.2.2.2.9 Pulse Amplitude

Pulse amplitude requirements of the ADS-B transmitted message are provided in 2.2.3.1.3
of these MOPS.
DO-181D, 2.2.4.2.3 (EUROCAE ED-73C, 3.3.2 and 3.6.4.b).
20xx, RTCA, Inc.

35
2.2.2.2.10 RF Peak Output Power

The RF peak output power requirements of each pulse of each transmitted message at the
terminals of the antenna are provided in the following subparagraphs for each class of
equipment addressed.
2.2.2.2.10.1 Class A0 and B0 Equipment RF Peak Output Power

The minimum RF peak output power for Class A0 and B0 equipment shall:
a. not be less than 18.5 dBW (70 W) for aircraft (or other installations) not capable of
operating at altitudes exceeding 15000 feet (4570 meters);
b. not be less than 21.0 dBW (125 W) for aircraft (or other installations) capable of
operating above 15000 feet (4570 meters);
c. not be less than 21.0 dBW (125 W) for aircraft (or other installations) with a maximum
cruising speed exceeding 175 knots (324 km/h).
Note: These requirements are consistent with the requirements of ICAO Annex 10, Volume
IV, fourth edition, July 2007, 3.1.2.10.2, as well as with the requirements of RTCA
DO-181D, 2.2.3.2 (EUROCAE ED-73C, 3.3.3).
2.2.2.2.10.2 Class B2 and B3 Equipment RF Peak Output Power

The minimum RF peak output power for Class B2 and B3 equipment shall not be less than
18.5 dBW (70 W).
Notes:
1. ADS-B equipment that meets all requirements of Class B2 with the exception of this RF
peak output power requirement is identified by the use of the B2 Low Capability
Class Code as specified in 2.2.3.2.7.2.3.8.
2. It is noted that the 70 W minimum RF peak output power requirement for Class B2
equipment is overly stringent to meet the 5NM operational range required for airport
surface operations in RTCA DO-242A. Future revisions of these MOPS may reduce the
minimum power output requirement on B2 equipment to better reflect the 5NM
operational range.
2.2.2.2.10.3 RF Peak Output Power (maximum)

The maximum RF peak output power of each pulse of each transmitted message at the
terminals of the antenna shall be fixed at 27.0 dBW (500 W) for all classes of stand-alone
transmitter based equipment.
IV, fourth edition, July 2007, 3.1.2.10.2, as well as with the requirements of RTCA
DO-181D, 2.2.3.2 (EUROCAE ED-73C, 3.3.3).
20xx, RTCA, Inc.

36
2.2.2.2.11 Unwanted Output Power

When the ADS-B transmitter is in the inactive state, the RF output power at 1090 3.0 MHz
at the terminals of the antenna shall not exceed -70 dBm.
Notes:
1. The inactive state is defined to include the entire period between ADS-B Message
transmissions less 10-microsecond transition periods, if necessary, preceding and
following the extremes of the transmissions.
2. This unwanted power requirement is necessary to insure that the ADS-B transmitter
does not prevent closely located 1090 MHz receiver equipment from meeting its
requirements. It assumes that the isolation between the ADS-B transmitter antenna
and the 1090 MHz receiver equipment antenna exceeds 20 dB. The resultant
interference level at the 1090 MHz receiver equipment antenna should then be
below -90 dBm.
3. This unwanted power requirement is consistent with the requirements provided in:
a. ICAO, Annex 10, Volume 4, Fourth Edition, July 2007, 3.1.2.10.2.1.
b. RTCA DO-181D, 2.2.3.3 and 2.2.22.f (EUROCAE ED-73C, 3.3.4 and

3.27.f), and
c. RTCA DO-185B, 2.2.3.2 (EUROCAE ED-143, 2.2.3.2).
2.2.2.2.12 Broadcast Rate Capability

The ADS-B Transmitting Subsystem must be capable of the broadcast rates specified for
each message type in 2.2.3.3. These rates must be maintained along with whatever other
transmit functions that the transmitting device may be required to perform.
2.2.3 Broadcast Message Characteristics
2.2.3.1 ADS-B Message Characteristics

The ADS-B Message data block is formed by Pulse Position Modulation (PPM) encoding of
the message data. A pulse transmitted in the first half of the interval represents a ONE
while a pulse transmitted in the second half represents a ZERO (see Figure 2-1).
DO-181D, 2.2.4.2 (EUROCAE ED-73C, 3.6).
20xx, RTCA, Inc.

37
PREAMBLE DATA BLOCK

8.0 sec 112 sec
BIT BIT
BIT 1 BIT 2 BIT 3 BIT 4 N-1 N
1 0 1 0 1 0 1 0 1 0 1 0
0.0 0.5 1.0 3.5 4.5 8.0 9.0

TIME ( sec)
0 0 1 0 0 0 1
Example: Message Data Block Waveform Corresponding to Bit Sequence 0010...001
Figure 2-1: ADS-B Message Transmission Waveform
2.2.3.1.1 ADS-B Message Preamble

The preamble shall consist of 4 pulses, each having duration of 0.5 0.05 microseconds.
The second, third and fourth pulses shall be spaced 1.0, 3.5 and 4.5 microseconds,
respectively, from the first transmitted pulse. The spacing tolerance shall be in accordance
with 2.2.3.1.4.
IV, fourth edition, July 2007, 3.1.2.2.4 and 3.1.2.2.5, as well as with the
requirements of RTCA DO-181D, 2.2.4.2 (EUROCAE ED-73C, 3.6.1).
2.2.3.1.2 ADS-B Message Data Pulses

The block of message data pulses shall begin 8.0 microseconds after the first transmitted
pulse. 112 one-microsecond intervals shall be assigned to each ADS-B Message
transmission. A pulse with a width of 0.5 0.05 microseconds shall be transmitted either in
the first or the second half of each interval. If a pulse transmitted in the second half of one
interval is followed by another pulse transmitted in the first half of the next interval, the two
pulses shall merge and a 1.0 0.05 microsecond pulse shall be transmitted.
20xx, RTCA, Inc.

38
2.2.3.1.3 ADS-B Message Pulse Shape

a. The pulse amplitude variation between one pulse and any other pulse in a message
transmission shall not exceed 2 dB.
b. The pulse rise time shall not be less than 0.05 microseconds or greater than 0.1
microsecond.
c. The pulse decay time shall not be less than 0.05 microseconds or greater than 0.2
microseconds.
d. The spectrum of the message transmission shall not exceed the bounds in Table 2-7:
Table 2-7: ADS-B Transmission Message Spectrum

Frequency Difference Maximum Relative Response
(MHz from 1090 MHz) (dB Down From Peak)
> 1.3 and < 7 3
> 7 and < 23 20
> 23 and < 78 40
> 78 60
IV, fourth edition, July 2007, 3.1.2.2, Table 3-2, and Figure 3-5, as well as with
the requirements of RTCA DO-181D, 2.2.4.2.2 (EUROCAE ED-73C, 3.6.4).
2.2.3.1.4 ADS-B Message Pulse Spacing

ADS-B Message transmission pulses shall start at a defined multiple of 0.5 microsecond
from the first transmitted pulse. The pulse position tolerance shall be 0.05 microseconds,
measured from the first pulse of the transmission.
DO-181D, 2.2.4.2.4 (EUROCAE ED-73C, 3.6.5).
2.2.3.2 ADS-B and TIS-B Message Baseline Format and Structures

Figure 2-2 shows the overall format structure that shall be used for ADS-B and TIS-B
Messages. The first 5 data bits in each transmission are called the DF (Downlink Format)
field, while the next three bits are called:
1. the CA field if DF=17,
2. the CF field if DF=18, or
3. the AF field if DF=19.
20xx, RTCA, Inc.

39
ADS-B and TIS-B Overall Message Format Structures

Bit # 1 ------ 5 6 ------ 8 9 ------ 32 33 ------ 88 89 ------ 112
DF=17 AA
DF=17 CA ADS-B Message ME Field PI
Field ICAO Address
[5] [3] [56] [24]
Names [24]
AA
CF=0
ICAO Address
[3]
[24]
ADS-B Message ME Field PI
AA [56] [24]
CF=1 non-ICAO
[3] Address
[24]
CF=2 to 3 AA TIS-B Message ME Field PI
[3] [24] [56] [24]
DF=18 CF=4 PI
DF=18 TIS-B and ADS-R Management Messages
Field [3] [24]
[5]
Names AA
CF=5 non-ICAO TIS-B Message ME Field
[3] Address [56]
[24]
Rebroadcast of an ADS-B Message from an PI
alternate data link using the same TYPE Codes and [24]
CF=6
Message Formats as are defined for DF=17 ADS-B
[3]
Messages, with the exception of bits modified as
identified in 2.2.18.
CF=7 Reserved
AA
AF=0 ADS-B Message ME Field PI
DF=19 ICAO Address
DF=19 [3] [56] [24]
Field [24]
[5]
Names AF=1 to 7
Reserved for Military Applications
[3]
MSB MSB MSB MSB MSB
LSB LSB LSB LSB LSB
Figure 2-2: ADS-B and TIS-B Message Baseline Format Structure
Notes for Figure 2-2:
1. [#] provided in a field indicates the number of bits in the field.
2. DF=19 messages are intended for Military Applications systems only.
3. For DF=19, if the AF field is equal to 0, then bits 9-32 are used for the AA field, bits
33-88 are used for the ME field, and bits 89-112 are used for the PI field. If the AF
field is not 0 (that is, is in the range 1 to 7) then bits 9-112 are used for the Reserved
for Military Applications field. (This format is reserved for military use only.)
20xx, RTCA, Inc.

40
The DF=17 format is used for ADS-B Messages from Mode S transponders. If DF=17, the
CA field describes the capabilities of the Mode S transponder, the AA field holds the
transponders 24-bit ICAO address, the ME field holds the body of the ADS-B Message,
and the PI field holds parity check bits.
The DF=18 format is used for ADS-B or TIS-B Messages from transmitting devices that are
not Mode S transponders. If DF=18, then the 3-bit CF (Code Format) field designates
whether the ME field holds an ADS-B Message or a TIS-B Message. For DF=18
transmissions in which CF=0 or 1 (that is, DF=18 Extended Squitters that carry ADS-B
Messages), the CF field also specifies what type of address is contained in the AA field.
ADS-B Messages shall use Extended Squitter formats in which DF=17, or in which DF=18
and CF=0 or 1, or in which DF=19 and AF=0. The DF=19 format is reserved for military
applications; non-military ADS-B participants shall not transmit Extended Squitter formats
in which DF=19.
ADS-B Airborne Receiving Subsystems shall accept, and process as ADS-B Messages, any
Extended Squitter transmissions in which DF=17, or in which DF=18 and CF=0, 1 or 6.
ADS-B Airborne Receiving Subsystems may accept and process ADS-B Messages in which
DF=19 and AF=0, but need not do so. ADS-B Airborne Receiving Subsystems shall not
process as ADS-B Messages any Extended Squitter receptions in which DF=18 and CF is
not equal to 0, 1 or 6, or any Extended Squitter receptions in which DF=19 and AF is not
equal to 0.
TIS-B Messages use 1090 MHz Extended Squitter formats in which DF=18 and CF=2, 3 or
5. An ADS-B Message from an alternate data link that is being rebroadcast by ground
equipment as a Message using the 1090 MHz Extended Squitter uses formats in which
DF=18 and CF=6, and the same TYPE Codes and Message formats as are defined for
DF=17 ADS-B Messages, with the exception of bits modified as identified in Section
2.2.18. 1090 MHz Extended Squitter Messages with DF=18 and CF=4 convey
management information for TIS-B and ADS-R. Receiving equipment shall not process as
TIS-B Messages any Extended Squitter receptions in which DF is not equal to 18, or in
which CF is not in the range from 2 to 5.
Note: A primary purpose of the TIS-B/ADS-R Management Messages (i.e., DF=18 and
CF=4) is to convey the TIS-B and the ADS-R service volumes and to provide a
heartbeat indicator. This information is provided in order that airborne
applications using TIS-B and/or ADS-R received information can determine if their
own ship is within the designated TIS-B and/or ADS-R service volume (i.e., by
comparing own ship position with the service volume information conveyed by the
management message) and current service availability (i.e., with the heartbeat
function conveyed by the management message). Although the explicit data
contents of the TIS-B/ADS-R Management Messages are not defined within this
document, the overall message structure and purpose is defined.
2.2.3.2.1 ADS-B Message Baseline Field Descriptions

The following subparagraphs describe the fields that were listed in Figure 2-2 above.
20xx, RTCA, Inc.

41
2.2.3.2.1.1 DF Downlink Format Field

a. The DF field is the first field in all downlink formats and provides the transmission
descriptor coded in accordance with RTCA DO-181D, Figure 2-5 (EUROCAE ED-73C,
Figure 3-4).
b. The DF field shall be set to DF=17 (binary 1 0001) for all ADS-B Message
transmissions from Mode-S Transponder-Based transmission devices.
c. The DF field shall be set to DF=18 (binary 1 0010) for all ADS-B Message
transmissions from transmission devices that are not Mode-S Transponder-Based
systems. The DF=18 is also used for all TIS-B Message transmissions.
d. The DF field shall be set to DF=19 (binary 1 0011) for all ADS-B Message
transmissions from transmission devices that are Military Application based systems.
Note: Encoding of the DF field is consistent with 3.1.2.3.2 and Figure 3-8 in ICAO
ANNEX 10, Volume IV, Fourth Edition, July 2007.
2.2.3.2.1.2 CA Capability Field (used in DF=17)

a. Definition: -- The CA field is a 3-bit (Message bits 6 through 8) field used to report
the capability of an ADS-B transmitting installation that is based on a Mode-S
transponder. The CA field is used to report the capability and notice of a transponder
condition that requires interrogation by the ground of a transponder. It is used in Mode-
S downlink format DF=11, i.e., the Mode-S All Call reply and acquisition squitter, and
DF=17. Therefore, the codes used in the CA field are as specified in Table 2-8:
Table 2-8: CA Field Code Definitions
Coding
Meaning
(Binary) (Decimal)
Signifies Level 1 transponder (surveillance only), and no ability to
000 0
set CA code 7, and either on the ground or airborne
001 1 Reserved
010 2 Reserved
011 3 Reserved
Signifies Level 2 or above transponder, and the ability to set CA
100 4
code 7, and on the ground
101 5
code 7, and airborne
110 6
code 7, and either on the ground or airborne
Signifies the DR field is NOT equal to ZERO (0), or the FS
111 7
field equals 2, 3, 4, or 5, and either on the ground or airborne.
When the conditions for CA Code 7 are not satisfied, Level 2 or above transponders
in installations that do not have automatic means to set on-the-ground condition shall
use CA Code 6. Aircraft with automatic on-the-ground determination shall use CA
Code 4 when on the ground, and CA Code 5 when airborne. Data Link capability
20xx, RTCA, Inc.

42
reports (RTCA DO-181D, 2.2.19.1.12.6) (EUROCAE ED-73C, 3.23.1.12.e) shall be

available from aircraft installations that set CA codes 4, 5, 6 and 7.
Notes:
1. CA codes 1 to 3 are reserved to maintain backward compatibility.
2. These requirements are consistent with the requirements of ICAO Annex 10, Volume
IV, 3.1.2.5.2.2.1, as well as with the requirements of RTCA DO-181D, 2.2.14.4.6
(EUROCAE ED-73C, 3.18.4.5).
b. Transponder Use -- The CA code definitions provided herein are intended for use
when implemented with the Mode-S Transponder functions.
c. Air/Ground Determination
(1). If a transmitting ADS-B participant is not equipped with a means, such as a weight-
on-wheels switch, to determine whether it is airborne or on the surface, and that
participants Emitter Category (2.2.3.2.5.2) is one of the following, then it shall set
its Air/Ground State to Airborne, and broadcast the Airborne Position Message
(2.2.3.2.3):
Unknown Emitter Category
Light Aircraft
Rotorcraft
Glider or Sailplane
Lighter Than Air
Unmanned Aerial Vehicle
Ultralight, Hang Glider or Paraglider
Parachutist or Skydiver
Point Obstacle
Cluster Obstacle
Line Obstacle
Notes:
1. Because of the unique operating capabilities of Lighter-Than-Air vehicles,
i.e., balloons, an operational Lighter-Than-Air vehicle will always report the
Airborne State, unless the ON-GROUND State is specifically declared in
compliance with subparagraph (4) below.
2. Because of the fact that it is important for Fixed Ground or Tethered Obstacles
to report altitude, such objects will always report the Airborne state.
3. Because of the unique capabilities of Rotorcraft, i.e., hover, etc., an operational
Rotorcraft will always report the Airborne state unless the ON-GROUND
state is specifically declared in compliance with subparagraph (4) below.
4. An automatic means of determining air/ground status may include Weight-on-
Wheels discrete, Airspeed, Ground Speed, Radio Altitude, or other appropriate
data sources.
20xx, RTCA, Inc.

43
(2). If a transmitting ADS-B participants Emitter Category (2.2.3.2.5.2) is one of the

following, then that participant shall set its Air/Ground State to the ON-
GROUND condition and broadcast the Surface Position Message (2.2.3.2.4):
Surface Vehicle Emergency

Surface Vehicle Service
(3). If a transmitting ADS-B participant is not equipped with a means, such as a weight-
on-wheels switch, to determine whether it is airborne or on the surface, and its
ADS-B Emitter Category (2.2.3.2.5.2) is not one of those listed under tests (1) or
(2) above (i.e., the participants Emitter Category is either: Small, Large, High
Vortex Large, Heavy, Highly Maneuverable, or Space/Trans-Atmospheric), then the
following tests will be performed to determine whether to broadcast the Airborne or
Surface Position Messages.
a. If the participants Radio Height (RH) parameter is available, and RH<50 feet,
and at least Ground Speed (GS) or Airspeed (AS) is available, and the available
GS<100 knots, or the available AS<100 knots, then that participant shall
broadcast the Surface Position Message (2.2.3.2.4).
If all three parameters are available, the decision to broadcast the Airborne or
Surface Position Messages shall be determined by the logical AND of all
three parameters.
b. Otherwise, if Radio Height (RH) is not available, and if the participants

Ground Speed (GS) and Airspeed (AS) are available, and GS<50 knots and
AS<50 knots, then that participant shall broadcast the Surface Position Message
(2.2.3.2.4).
c. Otherwise, the participant shall broadcast the Airborne Position Message

(2.2.3.2.3).
(4). If a transmitting ADS-B participant is equipped with a means, such as a weight-on-

wheels switch, to determine automatically whether it is airborne or on the surface,
then such information shall be used to determine whether to broadcast the Airborne
Position Message (2.2.3.2.3), or the Surface Position Message (2.2.3.2.4).
d. Validation of Ground Status:
Note: For aircraft with an automatic means of determining vertical status (i.e., weight-
on-wheels, strut switch, etc.) the CA field reports whether the aircraft is
airborne or on the ground. TCAS acquires aircraft using the acquisition
squitters or extended squitters, both of which contain the CA field. If an
aircraft reports that it is on the ground, that aircraft will not be interrogated by
TCAS in order to reduce unnecessary interrogation activity. The 1090 MHz
ADS-B Message formatter may have information available to validate that an
aircraft reporting on-the-ground is actually on the surface.
20xx, RTCA, Inc.

44
If the automatically determined Air/Ground status is not available or indicates that the
Airborne Position Message (see 2.2.3.2.3) shall be broadcast, then the Airborne
Position Message shall be broadcast in accordance with subparagraph c.
If one of the conditions in Table 2-10 is satisfied, then the Air/Ground status shall be
changed to Airborne and the Airborne Position Message (see 2.2.3.2.3) shall be
broadcast irrespective of the automatically determined Air/Ground status.
Table 2-10: Validation of ON-GROUND Status

Airborne Position Message Broadcast
ADS-B Emitter Category Set A Ground Radio
Speed Airspeed Altitude
Coding Meaning
No ADS-B Emitter Category
0 No Change to On-the-Ground status
Information
1 Light (<15,500 lbs.) No Change to On-the-Ground status
2 Small (15,500 to 75,000 lbs.) > 100 knots or > 100 knots or > 50 feet
3 Large (75,000 to 300,000 lbs.) > 100 knots or > 100 knots or > 50 feet
High-Vortex Large
4 > 100 knots or > 100 knots or > 50 feet
(aircraft such as B-757)
5 Heavy (> 300,000 lbs.) > 100 knots or > 100 knots or > 50 feet
High Performance
6 > 100 knots or > 100 knots or > 50 feet
(> 5g acceleration and >400 knots)
7 Rotorcraft No Change to On-the-Ground status
Notes:
1. Aircraft reporting ADS-B Emitter Category Set A codes 0, 1 or 7 with an automatic

means to determine the on-the-ground status, and means to validate that status, may
change the status to Airborne if the on-the-ground status cannot be validated.
2. Modern aircraft with integrated avionics suites commonly contain sophisticated

algorithms for determining the air/ground status based on multiple aircraft sensors.
These algorithms are customized to the airframe and designed to overcome individual
sensor failures. These algorithms are an acceptable means to determine the air/ground
status and do not require additional validation.
2.2.3.2.1.3 CF Field (used in DF=18)

The CF field of DF=18 messages is a 3-bit field (Message bits 6 through 8) used by
installations in which the ADS-B or TIS-B transmitting device is not based on a Mode S
transponder. The CF field serves to classify DF=18 messages between ADS-B Messages
and TIS-B Messages. For ADS-B Messages, the CF field also specifies whether or not the
AA field (2.2.3.2.1.5) holds a 24-bit ICAO address. For TIS-B Messages, the CF field
serves to categorize the TIS-B Message as being a fine format TIS-B Message, a coarse
format TIS-B Airborne Position and Velocity Message, a Fine TIS-B Message that uses
non-ICAO 24-bit addresses, or a TIS-B/ADS-R Management Message. The coding of the
CF field shall be as specified in Table 2-11.
20xx, RTCA, Inc.

45
Table 2-11: CF Field Code Definitions

Coding
Meaning
(Binary) (Decimal)
AA field holds the transmitting ADS-B Participants 24-bit
000 0
ICAO address.
ADS-B
Message AA field holds another kind of address for the transmitting
001 1 ADS-B Participant: a self-assigned anonymous address, a
ground vehicle address, or a surface obstruction address.
010 2 Fine TIS-B Message using ICAO 24-bit address
011 3 Coarse TIS-B Airborne Position and Velocity Message.
100 4 TIS-B TIS-B and ADS-R Management Messages.
101 5 and Fine TIS-B Message using non-ICAO 24-bit address
ADS-R
Rebroadcast of an ADS-B Message from an alternate data link
Messages
using the same TYPE Codes and Message Formats as are
110 6
defined for DF=17 ADS-B Messages, with the exception of bits
modified as identified in Section 2.2.18.
111 7 Reserved
ADS-B Messages from ADS-B Transmitting Subsystems that are not based on Mode S
transponders shall use CF=0 or 1, according to the type of address conveyed in the AA
field. TIS-B Messages use CF=2, 3 or 5. An ADS-B Message from an alternate data link
that is being Rebroadcast by ground equipment as a Message using 1090 MHz Extended
Squitter uses formats in which DF=18 and CF=6, and the same 1090ES TYPE Codes and
Message formats as are defined for DF=17 ADS-B Messages, with the exception of bits
modified as identified in section 2.2.18. CF code 7 is reserved for future standardization
and shall not be transmitted by equipment that conforms to these MOPS (RTCA
DO-260B).
2.2.3.2.1.4 AF Field (used in DF=19)

The AF (Application Field) field of DF=19 messages is a 3-bit field (Message bits 6
through 8) used by all ADS-B Message transmissions from transmission devices that are
Military Application based systems. The coding of the AF field shall be as specified in
Table 2-12. Refer to 2.2.3.2.1.2 for determining On-Ground Status.
Table 2-12: AF Field Code Definitions

Coding
Meaning
(Binary) (Decimal)
000 0 ADS-B Message Structure
001 -
1-7 Reserved for future Military Applications
111
20xx, RTCA, Inc.

46
2.2.3.2.1.5 AA Address Field, Announced

The AA field is a 24-bit (Message bits 9 through 32) field that shall contain the address of
the transmitting installation. This is intended to provide unambiguous identification of the
A/V being described in the ADS-B or TIS-B Message.
The type of address (whether a 24-bit ICAO address or some other kind of address)
contained in the AA field depends on the value of the DF field, and the CF or AF fields
when DF=18 or 19, and the IMF (ICAO/Mode A flag) subfield of the ME field for TIS-B
Messages. The type of address in the AA field shall be as specified in Table 2-13.
Table 2-13: Determining The Type of Address in the AA Field

DF CF or AF IMF
AA Field Contents
Field Field Subfield
17 N/A N/A 24-bit ICAO address of transmitting ADS-B Participant
CF=0 24-bit ICAO address of transmitting ADS-B Participant
N/A Anonymous address or ground vehicle address or fixed
CF=1
obstacle address of transmitting ADS-B Participant
0 TIS-B targets 24-bit ICAO address
CF=2
1 TIS-B targets 12-bit Mode A code and track file number
0 TIS-B targets 24-bit ICAO address
CF=3
1 TIS-B targets 12-bit Mode A code and track file number
TIS-B and ADS-R Management Messages; AA field
18 CF=4 N/A
contains TIS-B/ADS-R management information
0 TIS-B targets 24-bit non-ICAO address
CF=5
1 Reserved
0 24-bit ICAO Address of the transmitting ADS-B Participant
CF=6 Anonymous address or ground vehicle address or fixed
1
obstacle address of the transmitting ADS-B Participant
Reserved for future standardization; AA field does not
CF=7 N/A necessarily exist in messages for which DF=18 and CF is
equal to 7.
AF=0 N/A 24-bit ICAO address of transmitting ADS-B participant
19 Reserved for military use; AA field does not necessarily
AF=1 to 7 exist in messages for which DF= 19 and AF is in the range
from 1 to 7.
For Extended Squitter transmissions in which DF=17, or in which DF=18 and CF=0, or in
which DF=19 and AF=0, the AA field contains the 24-bit ICAO address of the transmitting
participant.
The TIS-B/ADS-R Management Messages (i.e., DF=18 and CF=4) do not relate to an
aircraft but rather relate to the coverage and availability of the TIS-B or ADS-R service that
is being provided by the local ground infrastructure. Therefore, the coding of the AA field
for TIS-B/ADS-R Management Messages is used to convey additional information in the
TIS-B/ADS-R Management Message and must be included in the data delivered to ADS-B
applications.
20xx, RTCA, Inc.

47
Notes:
1. For Extended Squitter transmissions in which DF=18 and CF=1, the CF field indicates
that the ME field holds an ADS-B Message and that the AA field holds an address other
than the standard ICAO 24-bit address of the transmitting ADS-B participant.
2. For Extended Squitter transmission in which DF=18 and CF=2, 3 or 5, the CF field
indicates that the ME field holds a TIS-B Message. In these cases, the meaning of the
AA field whether or not it contains the ICAO 24-bit address of the aircraft being
described in the TIS-B Message depends on the value of the CF field, as described in
0.
3. These requirements are consistent with the requirements of ICAO Annex 10, Volume IV,
as well as the requirements of RTCA DO-181D, 2.2.14.4.1 (EUROCAE ED-73C,
3.18.4.1).
The ADS-B transmitter shall declare a transmitter failure in the event that its own ICAO 24-
bit Address is all ZEROs or all ONEs.
Note: This requirement is consistent with the requirements of RTCA DO-181D, 2.2.10.3.
2.2.3.2.1.6 ME Message, Extended Squitter

The ME field is a 56-bit field (Message bits 33 through 88) that occurs in every 1090
MHz Extended Squitter Message (that is, in the relevent messages specified in Figure 2-2).
The ME field carries the bulk of the data in ADS-B and TIS-B Messages.
The first five bits of the ME field comprise the TYPE Code subfield. For certain values of
the TYPE Code subfield, the next three bits (ME bits 6 to 8) comprise a Subtype Code
subfield. The values in the TYPE subfield and, if present, the Subtype subfield, determine
which of several ADS-B or TIS-B Messages is being conveyed in the remainder of the
ME field. The TYPE and Subtype subfields are described in 2.2.3.2.2.
The ME field formats for the various ADS-B Messages are described in 2.2.3.2.3
through 2.2.3.2.7 below. The formats for the various TIS-B Messages are described in
2.2.17 and its subparagraphs.
2.2.3.2.1.7 PI Parity / Identity

The PI field is a 24-bit (Message bits 89 through 112) downlink field that contains the
parity overlaid on the Code Label (CL) and Interrogator Code (IC) fields, that shall be
in accordance with 2.2.14.4.30 and 2.2.18.2.1 of RTCA Document DO-181D
(EUROCAE ED-73C, 3.18.4.27 and 3.22.2.1).
Note: In ADS-B and TIS-B Messages (those transmitted with downlink format DF=17, or
with DF=18 and CF in the range from 0 to 6, or with DF=19 and AF=0) both
CL=0 and IC=0. In other words, in ADS-B and TIS-B Messages the parity is
overlaid with a 24-bit pattern of ALL ZEROs.
20xx, RTCA, Inc.

48
2.2.3.2.2 Determining ADS-B and TIS-B Message Types

All ADS-B and TIS-B transmissions have the baseline structure specified in 2.2.3.2.1. The
subfields of the ME field are defined for each of the ADS-B Message types in the
following subparagraphs.
In ADS-B and TIS-B Extended Squitter Messages, the TYPE Code subfield of the ME
field occupies ME bits 1 to 5 (Message bits 33 to 37). The Subtype field, if present for a
particular message type, occupies ME bits 6 to 8 (Message bits 38 to 40). The TYPE
Code subfield, together with the Subtype subfield for some message types, is used to
identify the ADS-B or TIS-B Message and to differentiate the messages into several
message types.
The format TYPE Code differentiates the 1090ES Messages into several classes: Airborne
Position, Airborne Velocity, Surface Position, Identification and Category, Aircraft Intent,
Aircraft Status, etc. In addition, the format TYPE Code also encodes the Navigation
Integrity Category (NIC) value of the source used for the position report. The NIC value is
used to allow surveillance applications to determine whether the reported geometric position
has an acceptable level of integrity containment region for the intended use. The NIC
integrity containment region is described horizontally using the Radius of Containment
(RC). The format TYPE Code also differentiates the Airborne Messages as to the type of
their altitude measurements: barometric pressure altitude or GNSS height (HAE). The 5-bit
encoding for the format TYPE Code and NIC values conforms to the definition contained in
Table 2-16. If an update has not been received from an on-board data source to allow for
the determination of the NIC value within the past 5 seconds, then the NIC value is encoded
to indicate that RC is Unknown.
For ADS-B Messages (those for which DF=17, or DF=18 and CF=0, 1 or 6, or DF=19 and
AF=0), the possible Message Types are those listed in Table 2-14. An ADS-B Message
from an alternate data link that is being Rebroadcast by ground equipment using 1090 MHz
Extended Squitter uses formats in which DF=18 and CF=6, and uses the same 1090ES
TYPE Codes and Message formats as are defined for DF=17 ADS-B Messages, with the
exception of bits modified as identified in section 2.2.18. In Table 2-14, the word
Reserved indicates ADS-B Message Types for which ADS-B Message formats have not
yet been defined, but which may be defined in future versions of these MOPS. The TYPE
Code, together with the Subtype Code (if present for a given TYPE Code value), identifies
the TYPE of ADS-B Message being broadcast, in accordance with Table 2-14.
Note: ADS-B Receiving Subsystems should not generate ADS-B Reports based on the
receipt of ADS-B Message Types that are indicated as Reserved in Table 2-14.
20xx, RTCA, Inc.

49
Table 2-14: Determining ADS-B Message Type

(DF=17 or DF=18 and CF=0, 1 or 6, or DF=19 and AF=0)
TYPE Code Subtype Code
ADS-B Message Type
(ME bits 1-5) (ME bits 6-8)
Airborne Position Message (2.2.3.2.3),
0 Not Present
Surface Position Message (2.2.3.2.4)
14 Not Present Aircraft Identification and Category Message (2.2.3.2.5)
58 Not Present Surface Position Message (2.2.3.2.4)
9 - 18 Not Present Airborne Position Message (2.2.3.2.3)
0 Reserved
19 14 Airborne Velocity Message (2.2.3.2.6)
57 Reserved
20 - 22 Not Present Airborne Position Message (2.2.3.2.3)
0 Test Message (2.2.3.2.7.3)
23
17 Reserved
0 Reserved
24 1 Surface System Status (2.2.3.2.7.4) (Allocated for National use)
27 Reserved
25 26 Reserved
27 Reserved for Trajectory Change Message (2.2.3.2.7.7)
0 Reserved
Extended Squitter Aircraft Status Message
1
(Emergency/Priority Status & Mode A Code) (2.2.3.2.7.8.1)
28
Extended Squitter Aircraft Status Message
2
(1090ES TCAS RA Message) (2.2.3.2.7.8.2)
37 Reserved
0 Target State and Status defined in DO-260A, ADS-B Version=1
29 1 Target State and Status (2.2.3.2.7.1)
23 Reserved
30 07 Reserved
01 Aircraft Operational Status (2.2.3.2.7.2)
31
27 Reserved
For TIS-B Messages (those for which DF=18 and CF is in the range from 2 to 5), the
possible message Types are specified in Table 2-15. In that table, the word Reserved
indicates TIS-B Message Types for which the message formats have not yet been defined,
but which may be defined in future versions of these MOPS. The TYPE Code, together
with the Subtype Code (if present for a given TYPE Code value), identifies the Type of
TIS-B Message being received, in accordance with Table 2-15.
Note: TIS-B Receiving Subsystems should not generate TIS-B Reports based on the receipt
of messages for which the TIS-B Message Type is indicated as Reserved in Table
2-15.
20xx, RTCA, Inc.

50
Table 2-15: Determining TIS-B or ADS-R Message Type (DF=18, CF=2 to 6)

CF
Field TIS-B Message Type
(ME bits 1-5) (ME bits 6-8)
Value
TIS-B Fine Airborne Position Message (2.2.17.3.1), or
0 Not Present
TIS-B Fine Surface Position Message (2.2.17.3.2)
14 Not Present TIS-B Identification and Category Message (2.2.17.3.3)
58 Not Present TIS-B Fine Surface Position Message (2.2.17.3.2)
9 18 Not Present TIS-B Fine Airborne Position Message (2.2.17.3.1)
2 or 5
0 Reserved
19 14 TIS-B Velocity Message (2.2.17.3.4)
57 Reserved
20 22 Not Present TIS-B Fine Airborne Position Message (2.2.17.3.1)
23 31 Not Present Reserved
TIS-B Coarse Airborne Position and Velocity Message
3 Not Present Not Present
(2.2.17.3.5)
4 Not Present Not Present TIS-B and ADS-R Management Messages
6 0 31 See Table 2-14 ADS-B Rebroadcast (ADS-R) Message (2.2.18)
2.2.3.2.3 ADS-B Airborne Position Messages

Format for the Airborne Position Message ME field contents shall be as specified in
Figure 2-3. Each of the subfields is specified in the following subparagraphs.
Airborne Position Message ME Field

Msg
Bit 33 -37 38 ---------- 39 40 41 ----- 52 53 54 55 ---- 71 72 ---- 88
#
ME
Bit 15 6 ------------ 7 8 9 ----- 20 21 22 23 --- 39 40 --- 56
#
CPR CPR CPR
TYPE Surveillance NIC Time
Field Altitude Format Encoded Encoded
Code Status Supplement-B (T)
Name [12] (F) Latitude Longitude
[5] [2] [1] [1]
[1] [17] [17]
MSB MSB MSB MSB MSB
LSB LSB LSB LSB LSB
Note: [#] provided in the Field indicates the number of bits in the field.
Figure 2-3: ADS-B Airborne Position Message Format
20xx, RTCA, Inc.

51
2.2.3.2.3.1 TYPE Code Subfield in ADS-B Airborne Position Messages

The TYPE Code subfield is a 5-bit (ME bits 1 through 5, Message bits 33 through 37)
field that shall be used to identify the ADS-B Message and to differentiate between several
message types.
1. Airborne Position Message (2.2.3.2.3)
2. Surface Position Message (2.2.3.2.4)
3. Aircraft Identification (ID) and Category Message (2.2.3.2.5)
4. Airborne Velocity Message (TYPE=19) (2.2.3.2.6)
5. Target State and Status Message (TYPE=29) (2.2.3.2.7.1)
6. Aircraft Operational Status Message (TYPE=31) (2.2.3.2.7.2)
7. Test Message (TYPE=23) (2.2.3.2.7.3)
8. Aircraft Status Message (TYPE=28) (2.2.3.2.7.8)
In the case of ADS-B Airborne Position Messages (2.2.3.2.3), the Message TYPE Code
subfield (2.2.3.2.2) is also used in the following ways:
a. The TYPE Code subfield indicates the altitude type (barometric pressure altitude,
2.2.3.2.3.4.1, or geometric altitude, 2.2.3.2.3.4.2) being communicated in the
Airborne Position Message.
b. Together with the NIC Supplement subfield (described in conjunction with the
Aircraft Operational Status Message, 2.2.3.2.7.2.6), the TYPE Code subfield
allows the encoding of the Navigation Integrity Category (NIC) (see Table 2-70).
For Surface Position Messages (2.2.3.2.4), the TYPE Code subfield, together with the NIC
Supplement, allows the encoding of the NIC but not altitude type, since altitude is not
reported in Surface Position Messages.
Detailed definition of the TYPE Code subfield encodings that shall be used for all ADS-B
Airborne Position and Surface Position Messages are provided in Table 2-16. For Airborne
Position Messages and Surface Position Messages, Table 2-16 also shows how the NIC
value can be determined from the value of the TYPE Code subfield and the NIC
Supplement subfield in the Airborne Position and Operational Status Messages.
The ADS-B Airborne Position Messages shall use only TYPE Code values 0, 9 through
18, and TYPE Codes 20 through 22 as indicated in Table 2-16.
20xx, RTCA, Inc.

Working Paper 1090-WP30-18 as DRAFT Version 4.2 of DO-282B 52
Table 2-16: TYPE Subfield Code Definitions (DF=17 or 18)

NIC
TYPE Subtype Format Horizontal Containment Radius Limit Navigation Integrity
Supplement Altitude Type Notes
Code Code (Message Type) (RC) Category (NIC)
A B C
Not Not No Position Information Baro Altitude or
0 RC unknown NIC = 0 1, 2, 3
Present Applicable (Airborne or Surface Position Messages) No Altitude Information
1 Category Set D
2 Aircraft Identification and Category Category Set C
Not Not
Message Not Applicable Not Applicable Not Applicable
3 Present Applicable Category Set B
(2.2.3.2.5)
4 Category Set A
5 0 -- 0 RC < 7.5 m NIC = 11
6 0 -- 0 RC < 25 m NIC = 10
1 -- 0 RC < 75 m NIC = 9
7 6
Not 0 -- 0 Surface Position Message RC < 0.1 NM (185.2 m) NIC = 8
No Altitude Information
Present 1 -- 1 (2.2.3.2.4) RC < 0.2 NM (370.4 m) NIC = 7
1 -- 0 RC < 0.3 NM (555.6 m) NIC = 6
8
0 -- 1 RC < 0.6 NM (1111.2 m) NIC = 6
0 -- 0 RC > 0.6 NM (1111.2 m) or unknown NIC = 0
9 0 0 -- RC < 7.5 m NIC = 11 5
10 0 0 -- RC < 25 m NIC = 10 5
1 1 -- RC < 75 m NIC = 9
11 5, 6
0 0 -- RC < 0.1 NM (185.2 m) NIC = 8
12 0 0 -- RC < 0.2 NM (370.4 m) NIC = 7
0 1 -- RC < 0.3 NM (555.6 m) NIC = 6
13 Not 0 0 -- Airborne Position Message RC < 0.5 NM (925 m)
NIC = 6 Baro Altitude
Present 1 1 -- (2.2.3.2.3) RC < 0.6 NM (1111.2 m)
14 0 0 -- RC < 1.0 NM (1852 m) NIC = 5
15 0 0 -- RC < 2 NM (3.704 km) NIC = 4
1 1 -- RC < 4 NM (7.408 km) NIC = 3
16 7
0 0 -- RC < 8 NM (14.816 km) NIC = 2
17 0 0 -- RC < 20 NM (37.04 km) NIC = 1
18 0 0 -- RC > 20 NM (37.04 km) or unknown NIC = 0
0 Reserved Difference between
Not
19 14 Airborne Velocity Message (2.2.3.2.6) Not Applicable Not Applicable Baro Altitude and
Applicable
57 Reserved GNSS Height (HAE)
20 0 0 -- RC < 7.5 m NIC = 11 2, 5
Not Airborne Position Message
21 0 0 -- RC < 25 m NIC = 10 GNSS Height (HAE) 2, 5
Present (2.2.3.2.3)
22 0 0 -- RC > 25 m or unknown NIC = 0 2
20xx, RTCA, Inc. Working Paper 1090-WP30-18 as DRAFT Version 4.2 of DO-282B
Working Paper 1090-WP30-18 as DRAFT Version 4.2 of DO-282B 53
Table 2-16: TYPE Subfield Code Definitions (DF=17 or 18) (Continued)
TYPE Subtype NIC Format

Code Code Supplement (Message Type)
0 Test Message (2.2.3.2.7.3)
23
17 Reserved
0 Reserved
24 1 Surface System Status (2.2.3.2.7.4) (Allocated for National Use)
27 Reserved
25 26 Reserved (2.2.3.2.7.5 and 2.2.3.2.7.6)
0 Reserved
Not
1 Applicable Extended Squitter Aircraft Status Message (Emergency/Priority Status) (2.2.3.2.7.8.1)
28
2 Extended Squitter Aircraft Status Message (1090ES TCAS RA Message) (2.2.3.2.7.8.2)
37 Reserved
0 Target State and Status Message (ADS-B Version Number=1, defined in RTCA DO-260A)
29 1 Target State and Status Message (2.2.3.2.7.1) (ADS-B Version Number=2, defined in these MOPS, RTCA DO-260B)
23 Reserved
30 07 Reserved
01 Aircraft Operational Status Message (2.2.3.2.7.2)
31
27 Reserved
20xx, RTCA, Inc.

54
Notes for Table 2-16:
1. Baro Altitude means barometric pressure altitude, relative to a standard pressure

of 1013.25 millibars (29.92 in.Hg.). It does not mean baro corrected altitude.
2. TYPE codes 20 to 22 or TYPE Code 0 are to be used when valid Baro Altitude is
not available.
3. After initialization, when horizontal position information is not available but altitude
information is available, the Airborne Position Message is transmitted with a TYPE
Code of ZERO in bits 1-5, the barometric pressure altitude in bits 9 to 20, and bits 22
to 56 set to ZERO (0). If neither horizontal position nor barometric altitude
information is available, then all 56 bits of Register 0516 are set to zero. The ZERO
(0) TYPE Code field indicates that latitude and longitude information is not
available, while the Zero altitude field indicates that altitude information is not
available. (See Appendix A).
4. If the position source is an ARINC 743A GNSS receiver, then the ARINC 429 data
label 130 data word from that receiver is a suitable source of information for R C,
the horizontal integrity containment radius. (The label 130 data word is variously
called HPL (Horizontal Protection Limit) or HIL (Autonomous Horizontal Integrity
Limit) in different documents.
5. This TYPE Code value implies limits for the RC (horizontal containment limit). If this
limit is not satisfied, then a different value for the TYPE Code should be selected.
6. The NIC Supplement field in the Airborne Position Message (2.2.3.2.3.3) and in
the Aircraft Operational Status Message (2.2.3.2.7.2.6) enables the Report
Assembly Function in ADS-B Receiving Subsystem to determine whether the ADS-B
Transmitting Subsystem is announcing NIC=8 (RC < 0.1 NM) or NIC=9 (RC < 75 m).
7. The NIC Supplement field in the Airborne Position Message (2.2.3.2.3.3) and in
the Aircraft Operational Status Message (2.2.3.2.7.2.6) enables the Report
Assembly Function in ADS-B Receiving Subsystem to determine whether the ADS-B
Transmitting Subsystem is announcing NIC=2 (RC < 8 NM) or NIC=3 (RC < 4 NM).
8. Future versions of these MOPS may limit transmission of Surface Position Messages
at lower NIC and/or NACP values for Transponder-Based systems.
2.2.3.2.3.1.1 Airborne Position Message TYPE Code if Radius of Containment is Available

Note: If the position information comes from a GNSS receiver that conforms to the
ARINC 743A characteristic, a suitable source of information for the radius of
containment (RC), is ARINC 429 label 130 from that GNSS receiver.
If Radius of Containment (RC) information is available from the navigation data source,
then the ADS-B Transmitting Subsystem shall determine the TYPE Code (the value of
the TYPE Code subfield) of Airborne Position Messages as follows.
a. If current valid horizontal position information is not available to the ADS-B

Transmitting Subsystem, then the TYPE Code subfield of Airborne Position
Messages shall be set to ZERO (0) as described in 2.2.3.2.3.1.3.2 below.
20xx, RTCA, Inc.
55
b. If valid horizontal position and barometric pressure altitude information are both
available to the ADS-B Transmitting Subsystem, then the ADS-B Transmitting
Subsystem shall set the TYPE Code subfield of Airborne Position Messages to a
value in the range from 9 to 18 in accordance with Table 2-16.
c. If valid horizontal position information is available to the ADS-B Transmitting

Subsystem, but valid barometric pressure altitude information is not available, and
valid geometric altitude information is available, the ADS-B Transmitting Subsystem
shall set the TYPE Code subfield of Airborne Position Messages to a value in the
range from 20 to 22 depending on the radius of containment RC in accordance with
Table 2-16.
d. If valid horizontal position information is available to the ADS-B Transmitting

Subsystem, but neither valid barometric altitude information nor valid geometric
altitude information is available, the ADS-B Transmitting Subsystem shall set the
TYPE Code subfield in Airborne Position Messages to a value in the range from 9 to
18 depending on the radius of containment RC in accordance with Table 2-16. (In
that case, the ALTITUDE subfield of the Airborne Position Messages would be set to
ALL ZEROs in accordance with 2.2.3.2.3.4.3 below, in order to indicate that valid
altitude information is not available.)
2.2.3.2.3.1.2 Airborne Position Message TYPE Code if Radius of Containment is Not Available
If RC (radius of containment) information is NOT available from the navigation data
source, then the ADS-B Transmitting Subsystem shall indicate NIC=0 by selecting a
TYPE Code of 0, 18, or 22 in the Airborne Position Messages, as follows:
a. The ADS-B Transmitting Subsystem shall set the TYPE Code subfield to ZERO (0)
if valid horizontal position information is not available, as described in
2.2.3.2.3.1.3.2 below.
b. The ADS-B Transmitting Subsystem shall set the TYPE Code subfield to 18 if valid
pressure altitude information is available, or if neither valid pressure altitude nor
valid geometric altitude information is available.
If valid pressure altitude is not available, but valid geometric altitude information is
available, the ADS-B Transmitting Subsystem shall set the TYPE Code subfield to 22.
2.2.3.2.3.1.3 Special Processing for TYPE Code Equal to ZERO
2.2.3.2.3.1.3.1 Significance of TYPE Code Equal to ZERO

As shown in Table 2-16, TYPE Code equal to ZERO (0) is labeled No Position
Information. This type of message is intended to be used when horizontal position
information is not available or is invalid, and still permit the reporting of barometric
altitude, when it is available and valid. As such, the principal use of this message case is
to provide TCAS the ability to passively receive altitude information.
20xx, RTCA, Inc.

56
Airborne Position Messages may be transmitted with a TYPE Code of ZERO (0) under
the following condition:
An Airborne Position Message with a TYPE Code of ZERO (0) shall set all 56 bits of the
ME field bits to ZERO (0) if NO barometric pressure Altitude data is available. If
valid pressure Altitude data is available, then the Altitude subfield, ME bits 9 - 20,
Message bits 41 - 52, shall report the altitude in accordance with 2.2.3.2.3.4.3.
Note: Special processing is required for Airborne Position Messages because a CPR
encoded value of ALL ZEROs in the latitude and longitude field is considered to
be a valid encoding.
2.2.3.2.3.1.3.2 Broadcast of TYPE Code Equal to ZERO

The TYPE Code Equal to ZERO message may be required as a consequence of the
following events:
a. An ADS-B Airborne Position or Surface Position Message register has not been
loaded with data in the last 2 seconds. In this case, the ADS-B Message register
shall be cleared (i.e., all 56 bits set to ZERO) once it has timed out. Transmission of
the ADS-B Message that broadcasts the contents of the register shall be terminated if
the ADS-B Message register has not been loaded in 60 seconds, except that
transmission termination of Surface Position Messages does not apply to Non-
Transponder-Based Devices on aircraft that are on the surface, on surface vehicles, or
if barometric altitude information is available. Broadcast of the ADS-B Airborne
Position or Surface Position Message shall resume once data has been loaded into the
ADS-B Message register.
b. The data management function responsible for loading the ADS-B Message registers
determines that all navigation sources that can be used for the Airborne or Surface
Position Message are either missing or invalid. In this case the data management
function shall clear (set all data fields to all ZEROs) the TYPE Code and all other
fields of the Airborne or Surface Position Message and insert the ZEROed message
into the appropriate ADS-B Message register. This should only be done once in
support of the detection of the loss of data insertion and shall result in the
suppression of the broadcast of the related ADS-B Message.
c. Note that in all of the cases discussed above, a TYPE Code of ZERO infers a
message of ALL ZEROs. The only exception is that the Airborne Position Message
format shall contain barometric altitude code as set by the transponder when so
implemented. There is no analogous case for the other Extended Squitter Message
Types, since a ZERO value in any of the fields indicates that no valid information is
available.
2.2.3.2.3.1.4 TYPE Code based on Horizontal Position and Altitude Data

a. If valid horizontal position information is available, and valid pressure altitude
information is available, then the TYPE Code in the Airborne Position Message
shall be set in the range from 9 to 18.
b. If valid horizontal position information is available, valid pressure altitude is NOT

available, and GNSS Height Above the Ellipsoid (HAE) data is available, then the
20xx, RTCA, Inc.

57
TYPE Code in the Airborne Position Message shall be set in the range from 20
to 22.
c. If valid horizontal position information is available, but neither valid pressure altitude
information nor valid GNSS Height Above Ellipsoid (HAE) information is available,
then the TYPE Code in the Airborne Position Message shall be set in the range from
9 to 18.
d. In all three cases, a, b, and c above, the TYPE Coding shall be selected in
accordance with the Radius of Containment (RC) given in Table 2-16.
Alternatively, the TYPE Code may be selected in accordance with the Horizontal
Protection Limits (HPL) given in Table 2-16.
2.2.3.2.3.2 Surveillance Status Subfield in ADS-B Airborne Position Messages

The Surveillance Status subfield is a 2-bit (ME bits 6 and 7, Message bits 38 and 39)
field that shall be used to encode information from the aircrafts Mode-A transponder
code as provided in Table 2-17.
Table 2-17: Surveillance Status Subfield Code Definitions

Coding
Meaning
(Binary) (Decinal)
00 0 No Condition Information
01 1 Permanent Alert Condition (Emergency)
Temporary Alert Condition
10 2
(change in Mode A Identity Code other than emergency condition)
11 3 Special Position Identification (SPI) Condition
Note: Codes 1 and 2 take precedence over code 3.
The setting of the Surveillance Status is a transponder function and is appropriately

specified in RTCA DO-181D, 2.2.18.2.7 & 2.2.23.1.8 (EUROCAE ED-73C, 3.23.1.6
& 3.28.8).
When not implemented in a Mode-S Transponder-Based system, the ADS-B function

shall set the Surveillance Status subfield to ZERO.
2.2.3.2.3.3 NIC Supplement-B Subfield in ADS-B Airborne Position Messages

The NIC Supplement-B subfield in the Airborne Position Message is a one-bit subfield
(ME bit 8, Message bit 40) that, together with the TYPE Code subfield, shall be used
to encode the Radius of Containment (RC) and the Navigation Integrity Category (NIC)
of the transmitting ADS-B participant. The NIC Supplement-A subfield is also broadcast
in the Aircraft Operational Status Message (2.2.3.2.7.2.6).
Note: The Navigation Integrity Category (NIC) is reported so that surveillance

applications may determine whether the reported geometric position has an
acceptable level of integrity for the intended use. See 2.1.2.12 of RTCA DO-
242A, the ADS-B MASPS, for a fuller description of the Navigation Integrity
Category.
20xx, RTCA, Inc.
58
If an update has not been received from an on-board data source for the determination of
the NIC value within the past 5 seconds, then the NIC Supplement-B subfield shall be
encoded to indicate the larger Radius of Containment (RC).
Table 2-70 lists the possible NIC codes and the values of the TYPE Code subfield of the
Airborne and Surface Position Messages, and of the NIC Supplement-A and NIC
Supplement-B subfield that shall be used to encode those NIC codes in messages on the
1090 MHz ADS-B data link.
2.2.3.2.3.4 Altitude Subfield in ADS-B Airborne Position Messages

The Altitude subfield is a 12-bit (ME bit 9 through 20, Message bit 41 through 52)
field that shall contain the altitude of the ADS-B Transmitting Subsystem as provided in
the following subparagraphs.
2.2.3.2.3.4.1 Barometric Altitude in ADS-B Airborne Position Messages

Barometric Pressure Altitude relative to a standard pressure of 1013.25 millibars (29.92
in.Hg.) shall be reported in the Altitude Subfield of Airborne Position Messages
having TYPE Codes 9 through 18 (see 2.2.3.2.3.1 and Table 2-16) under the
following condition:
Barometric Pressure Altitude is selected for reporting via a control selection process and
such Barometric Pressure Altitude data is valid.
Note: Barometric Pressure Altitude specifically DOES NOT refer to Barometric

Corrected Altitude.
Encoding of the Barometric Pressure Altitude data into the Altitude subfield shall be in
accordance with 2.2.3.2.3.4.3.
2.2.3.2.3.4.2 GNSS Height Above the Ellipsoid (HAE) in ADS-B Airborne Position Messages
GNSS Height Above the Ellipsoid (HAE) shall be reported in the Altitude Subfield of
the Airborne Position Message having TYPE Codes 20 through 22 (see 2.2.3.2.3.1
and Table 2-16) under the following condition:
GNSS Height Above the Ellipsoid (HAE) is selected for reporting via a control
selection process and such GNSS Height Above the Ellipsoid (HAE) data is valid.
Encoding of the GNSS Height Above the Ellipsoid (HAE) data into the Altitude
subfield shall be in accordance with 2.2.3.2.3.4.3.
Note: GNSS height may be useful for integrity checking of altitude and in future ATC
concepts.
2.2.3.2.3.4.3 Altitude Encoding in ADS-B Airborne Position Messages

Altitude data shall be encoded into the Altitude subfield as follows:
a. Bit 16 (i.e., Message bit 48) shall be designated as the Q bit. Q equals ZERO
(0) shall be used to indicate that the Altitude is reported in 100 foot increments as
20xx, RTCA, Inc.

59
specified in paragraph b below. Q equals ONE (1) shall be used to indicate that
the altitude is reported in 25 foot increments as specified in paragraph c below.
b. If Q is equal to ZERO (0), then the Altitude shall be coded in 100 foot increments
by selection of pulses in accordance with ICAO ANNEX 10, Volume IV, fourth
edition, July 2007, Appendix 1 to Chapter 3, (see RTCA DO-181D,
2.2.13.1.2.a.(2).(c)) (EUROCAE ED-73C, 3.17.1.b.1.ii and 3.18.4.2). The
appropriate mapping for the sequence of pulses shall be as shown in Figure 2-4.
Altitude Subfield Encoding for Q = 0
MSG
BIT 41 42 43 44 45 46 47 48 49 50 51 52
#
ME
BIT 9 10 11 12 13 14 15 16 17 18 19 20
#
CODE
C1 A1 C2 A2 C4 A4 B1 Q B2 D2 B4 D4
BIT
Figure 2-4: Altitude Subfield Encoding For Q=0
c. If Q is equal to ONE (1), then the Altitude shall be coded such that bits 9 through
15, and 17 to 20 (Message bits 41 through 47, and 49 through 52) represent a binary-
coded field whose least significant bit has a value of 25 feet. The binary value of the
decimal number N shall be used to report Pressure Altitudes in the range (25 * N -
1000 + 12.5 feet).
The most significant bit of this field is bit 9. This code is able to provide code values
only between -1000 feet and +50175 feet. The coding used for Altitudes that are
greater than 50175 feet shall conform to the coding principles described in paragraph
b above.
d. If altitude data is not available, then all bits of the Altitude subfield shall be set to
ZERO.
Note: These requirements are consistent with the requirements of ICAO Annex 10,
Volume IV, fourth edition, July 2007, 3.1.2.6.5.4, as well as with the
requirements of RTCA DO-181D, 2.2.13.1.2 (EUROCAE ED-73C,
3.17.1.b).
2.2.3.2.3.5 TIME (T) Subfield in ADS-B Airborne Position Messages

The TIME (T) subfield is a 1-bit (ME bit 21, Message bit 53) field that shall indicate
whether or not the epoch of validity for the horizontal position data in an Airborne
Position Message is an exact 0.2 second UTC epoch. If the time of applicability of the
position data is synchronized to an exact 0.2 second UTC epoch, the TIME (T) subfield
shall be set to 1; otherwise, the TIME (T) subfield shall be set to ZERO (0).
20xx, RTCA, Inc.

60
Notes:
1. An ADS-B Transmitting Subsystem that sets the TIME (T) subfield to ONE (1)
must accept a GNSS TIME MARK input from the navigation data source in order to
be able to update the position data from the navigation data source to an exact 0.2
second UTC epoch (See 2.2.5.1.6).
2. An arithmetic description of the intended synchronization implementation is provided

in the Commentary paragraphs provided in 2.2.3.2.3.7.2 for precision Latitude
Position Extrapolation and in 2.2.3.2.3.8.2 for precision Longitude Position
Extrapolation.
2.2.3.2.3.6 CPR Format (F) Subfield in ADS-B Airborne Position Messages

The CPR Format (F) subfield is a 1-bit (ME bit 22, Message bit 54) field that shall
be used to indicate which Compact Position Reporting (CPR) Format type (even or
odd) is used to encode the latitude and longitude data (see 2.2.3.2.3.7 and
2.2.3.2.3.8). The bit shall be set to ZERO to indicate the even encoding of such
data, or to ONE to indicate the odd encoding of such data.
a. When TIME (T) = 0:
The CPR Format (F) subfield functions ONLY to indicate the even or odd
CPR encoding. In this case, the CPR encoding type shall alternate between even
and odd, and the CPR Format (F) subfield shall alternate between ZERO (0) and
ONE (1) respectively, each time the Airborne Position Message register is updated
with new position data.
Note: When the TIME (T) subfield is ZERO, the Airborne Position Message
register must be updated at least as frequently as every 200 milliseconds:
however, it may be updated more frequently, for example, every 100
milliseconds, etc. In such cases, the CPR encoding should alternate between
even and odd each time that the register is updated with new position
data.
b. When TIME (T) = 1:
The CPR Format (F) subfield functions to indicate the even or odd CPR
encoding and also indicates whether the epoch of applicability of the position data is
an even or odd 0.2 second UTC epoch.
Notes:
1. Although the Airborne Position Message register may be updated more

frequently than five times per second, the CPR Format (F) subfield alternates
between ZERO (0) and ONE (1) only as the epoch of applicability of the data
being loaded into the register alternates between even and odd 0.2 second
UTC epochs.
20xx, RTCA, Inc.

61
2. An even 0.2 second UTC epoch is defined as that moment on the UTC time
scale that occurs at an even number of 200-millisecond intervals after an exact
even-numbered UTC second. Likewise, an odd 0.2 second UTC epoch is
defined as that moment on the UTC time scale that occurs at an odd number of
200 millisecond intervals after an even numbered UTC second. Examples of
even 0.2 second epochs are 12.0 seconds, 12.4 seconds, 12.8 seconds, 13.2
seconds, 13.6 seconds, etc. Examples of odd 0.2 second epochs are 12.2
seconds, 12.6 seconds, 13.0 seconds, 13.4 seconds, 13.8 seconds, etc.
2.2.3.2.3.7 CPR Encoded Latitude Subfield in ADS-B Airborne Position Messages

The CPR Encoded Latitude subfield is a 17-bit (ME bit 23 through 39, Message bit
55 through 71) field containing the CPR encoded latitude of the airborne position.
2.2.3.2.3.7.1 Airborne Latitude Data Encoding

The airborne latitude position data shall be encoded in accordance with A.1.4.2.2 and
A.1.7 of Appendix A.
2.2.3.2.3.7.2 Airborne Latitude Position Extrapolation/Estimation (Precision Case, TYPE Codes

9, 10, 20 and 21)
The following subsections apply to Airborne Position Messages in which the TYPE Code
is 9, 10, 20 and 21 (see 2.2.3.2.3.1).
2.2.3.2.3.7.2.1 GPS/GNSS Time Mark Coupled Case (Extrapolation, TIME (T) = 1)

If TIME (T) = 1 (see 2.2.3.2.3.5) in an Airborne Position Message, then the time of
applicability of the latitude and longitude fields in that message shall be an exact 0.2
second UTC epoch.
a. Specifically, the position data in the latitude and longitude fields shall be
extrapolated forward from the time of validity of the position fix to the time of
applicability of the Airborne Position Message.
b. The Airborne latitude data registers and the encoded latitude subfield shall be
updated every 200 milliseconds to the next 0.2 UTC Epoch using the velocity data
provided for the position fix.
Notes:
1. The time of validity of the fix is provided with the fix data from the navigation data
source and is indicated by the leading edge of the GNSS Time Mark (see 2.2.5.1.6).
The time of applicability of the position message is the exact 0.2 second UTC Epoch
to which the position data is extrapolated.
2. The latitude position registers and encoded latitude subfield should be updated at a
time about 100 milliseconds before the time of applicability of the data being loaded
into that register (see 2.2.5.2.1 and Appendix A, A.1.4.2.3.1).
20xx, RTCA, Inc.

62
3. One method of estimating the position to an exact 0.2 second UTC Epoch is
described in the following Commentary.
COMMENTARY:
The following example provides one method (not the only method) that latitude
given in the Airborne Position Message may be extrapolated from the time of
validity of the fix (included with the fix from the navigation data source) to the
time of applicability of the Airborne Position Message. In the example, it is
assumed that the TIME (T) subfield (see 2.2.3.2.3.5) is ONE, indicating
that the time of applicability of the extrapolated position is an exact 0.2 second
UTC Epoch.
Let:
tfix = time of the leading edge of the last received GNSS Time
Mark (see 2.2.5.1.6), which is also the time of validity
included with the fix from the navigation data source.
tmessage = time of applicability of the Airborne Position Message,
which is an exact 0.2 second UTC Epoch.
t = tmessage - tfix, in milliseconds
fix = last known latitude position, at time tfix, in degrees
message = latitude, extrapolated forward to the time of applicability of
the Airborne Position Message, tmessage
= message - fix, in degrees
NS = North/South Velocity
The earth may be modeled as a sphere with radius such that one nautical mile
equals one minute of arc along a great circle. Using that approximation, yields:
message = fix +
= fix +( NS/60)( t/3600000)
= fix +( NS t) / (2.16 x 108)
(We divide NS by 60 to convert from knots in the N-S direction to degrees of
latitude per hour, and divide t by 3600 x 1000 to convert from milliseconds
to hours.)
The result, message, is to be encoded in the latitude field of the Airborne
Position Message using the CPR algorithm described in Appendix A, A.1.7.
2.2.3.2.3.7.2.2 Non-Coupled Case (Estimation, TIME (T) = 0)

ADS-B Airborne Position Messages with TYPE Codes of 9, 10, 20 and 21 (see
2.2.3.2.3.1) may implement estimation techniques such as alpha-beta trackers or Kalman
filters to satisfy the intent of the position update requirements given in 2.2.3.2.3.7.2.1.
Such techniques provide the capability to decouple the position computation from the
message transmission timing provided that the sampled data rate is sufficient to satisfy
minimum Nyquist criterion. Likewise such techniques may be necessary in order to
provide velocity compensation and/or acceleration estimation in the future.
20xx, RTCA, Inc.

63
a. If sampled data estimation techniques, e.g., alpha-beta trackers, alpha-beta-gamma

trackers, or Kalman filters, are used to periodically update position data, then the
maximum sampled data time shall not exceed 100 milliseconds.
b. Sampled data implementations shall update the airborne latitude data registers and
encoded latitude data subfield at intervals not to exceed 100 milliseconds
Note: The 100 millisecond requirement is necessary in order to insure that the 200
millisecond performance required in 2.2.3.2.3.7.2.1 is not degraded.
2.2.3.2.3.7.3 Airborne Latitude Position Extrapolation/Estimation (non - precision)
2.2.3.2.3.7.3.1 Airborne Latitude Position Extrapolation Case (non - precision)

ADS-B Airborne Position Messages with TYPE Codes other than 9, 10, 20 or 21 (see
2.2.3.2.3.1) shall contain an estimate of the latitude position at a time of applicability
that is within 200 milliseconds of the time that the Airborne Position Message is
transmitted. Essentially, the original data and the encoded latitude shall be updated at
least as frequently as every 200 milliseconds.
COMMENTARY:
The only difference between latitude position extrapolation in the non-precision
case and that of the precision case (2.2.3.2.3.7.2.1) is the interpretation of what
t means. In the non-precision case, t is the elapsed time from the last
received position update to the expected time of transmission of an Airborne
Position Message that is based on the last position update.
(In the precision case, t is the time interval from the last received leading edge
of the GNSS Time Mark to the 0.2 second UTC Epoch which is to be the time of
applicability of the Airborne Position Message).
Let:
tfix = time validity included with the PVT (position, velocity,
time) data from the navigation data source.
tupdate = time when the transmitting ADS-B Subsystem receives the
most recent PVT (position, velocity, time) data from a
navigation data source.
tmessage = time of applicability of the Airborne Position Message
t = tmessage - tupdate, in milliseconds
message = latitude, extrapolated forward to the time of applicability of
the Airborne Position Message, tmessage
20xx, RTCA, Inc.

64
message = fix +
= fix +( NS/60)( t/3600000)
= fix +( NS t) / (2.16 x 108)

latitude per hour, and divide t by 3600 x 1000 to convert from milliseconds to
hours.)
The result, message, is to be encoded in the latitude field of the Airborne Position
Message using the CPR algorithm described in Appendix A, A.1.7.
Note: In order not to introduce excessive error in the estimated latitude,

message, the latency, tupdate - tfix, in the delivery of PVT data from the
navigation data source should not be excessive.
2.2.3.2.3.7.3.2 Airborne Latitude Position Estimation Case (non - precision)

ADS-B Airborne Position Messages with TYPE Codes other than 9, 10, 20 and 21 (see

b. Sampled data implementations shall update the airborne latitude data registers and
encoded latitude data subfield at intervals not to exceed 100 milliseconds.
2.2.3.2.3.7.4 Airborne Latitude Position Data Retention

In the event that the latitude position data is no longer available, the extrapolation or
estimation of, and update of latitude data and fields specified in 2.2.3.2.3.7.2 through
2.2.3.2.3.7.3.2 shall be limited to no more than two seconds.
At the end of two seconds, the latitude data registers and the encoded latitude field shall
be set to ALL ZEROs.
2.2.3.2.3.8 CPR Encoded Longitude Subfield in ADS-B Airborne Position Messages

The CPR Encoded Longitude subfield is a 17-bit (ME bit 40 through 56, Message bit
72 through 88) field that shall contain the encoded longitude of the airborne position.
20xx, RTCA, Inc.

65
2.2.3.2.3.8.1 Airborne Longitude Data Encoding

The airborne longitude position data shall be encoded in accordance with A.1.4.2.2 and
2.2.3.2.3.8.2 Airborne Longitude Position Extrapolation/Estimation (Precision Case, TYPE

Codes 9, 10, 20 and 21)

If TIME (T) = 1 (see 2.2.3.2.3.5) in an Airborne Position Message, then the time of
second UTC epoch.
applicability of the Airborne Position Message.
b. The Airborne longitude data registers and the encoded longitude subfield shall be
Notes:
2. The longitude position registers and encoded longitude subfield should be updated at
a time about 100 milliseconds before the time of applicability of the data being
loaded into that register (see 2.2.5.2.1 and Appendix A, A.1.4.2.3.1).
COMMENTARY:
The following example provides one method (not the only method) that longitude
given in the Airborne Position Message may be extrapolated from the time of
time of applicability of the Airborne Position Message. In the example, it is
assumed that the TIME subfield (see 2.2.3.2.3.5) is ONE, indicating that
the time of applicability of the extrapolated position is an exact 0.2 second UTC
Epoch.
20xx, RTCA, Inc.

66
Let:
tmessage = time of applicability of the Airborne Position Message,
fix = last known longitude position, at time tfix, in degrees
message = longitude, extrapolated forward to the time of
applicability of the Airborne Position Message, tmessage
= approximate latitude (the latitude, fix, at the time of the
fix may be used)
EW = last known E-W velocity at time tfix, in knots (positive for
easterly velocity)
message = fix +
= fix + [( EW)/(60 cos ( ))] ( t/3600000)

= fix +( EW t) / [(2.16 x 108) cos( )]
(We divide EW by 60 cos ( ) to convert from knots in the E-W direction to
degrees of longitude per hour, and divide t by 3600 x 1000 to convert from
milliseconds to hours.)
The result, message, is to be encoded in the longitude field of the Airborne

ADS-B Airborne Position Messages with TYPE Codes of 9, 10, 20 and 21 (see

b. Sampled data implementations shall update the airborne longitude data registers and
encoded longitude data subfield at intervals not to exceed 100 milliseconds.
20xx, RTCA, Inc.
67
2.2.3.2.3.8.3 Airborne Longitude Position Extrapolation/Estimation (non - precision)
2.2.3.2.3.8.3.1 Airborne Longitude Position Extrapolation Case (non - precision)

ADS-B Airborne Position Messages with TYPE Codes other than 9, 10, 20 or 21 (see
2.2.3.2.3.1) shall contain an estimate of the longitude position at a time of applicability
that is within 200 milliseconds of the time that the Airborne Position Message is
transmitted. Essentially, the original data and the encoded longitude shall be updated at
least as frequently as every 200 milliseconds.
COMMENTARY:
The only difference between longitude position extrapolation in the non-precision
received position update to the expected time of transmission of an Airborne
Position Message that is based on the last position update. (In the precision
case, t is the time interval from the last received leading edge of the GNSS Time
Mark to the 0.2 second UTC Epoch which is to be the time of applicability of the
Airborne Position Message).
Let:
time when the transmitting ADS-B Subsystem receives the
tupdate =
most recent PVT (position, velocity, time) data from a
navigation data source.
tmessage = time of applicability of the Airborne Position Message
applicability of the Airborne Position Message, tmessage
fix may be used)
easterly velocity)
message = fix +
= fix + [( EW)/(60 cos ( ))] ( t/3600000)
= fix +( EW t) / [(2.16 x 108) cos( )]
20xx, RTCA, Inc.

68

The result, message, is to be encoded in the longitude field of the Airborne
Note: In order not to introduce excessive error in the estimated longitude, message, the
latency, tupdate - tfix, in the delivery of PVT data from the navigation data source
should not be excessive.
2.2.3.2.3.8.3.2 Airborne Longitude Position Estimation Case (non - precision)

ADS-B Airborne Position Messages with TYPE Codes other than 9, 10, 20 and 21 (see

b. Sampled data implementations shall update the airborne longitude data registers and
2.2.3.2.3.8.4 Airborne Longitude Position Data Retention

The extrapolation or estimation, and update of longitude data and fields specified in
2.2.3.2.3.8.2 through 2.2.3.2.3.8.3.2 shall be limited to no more than two seconds, in
the event that the longitude position data is no longer available.
At the end of two seconds, the longitude data registers and the encoded longitude field
shall be set to ALL ZEROs.
20xx, RTCA, Inc.

69
2.2.3.2.4 ADS-B Surface Position Messages

The format for the Surface Position Message ME field contents is specified in Figure 2-
5. Each of the subfields is specified in the following subparagraphs.
Surface Position Message ME Field

Msg
Bit 33 - 37 38 - 44 45 46 - 52 53 54 55 - 71 72 - 88
#
ME
Bit 1-5 6 - 12 13 14 - 20 21 22 23 - 39 40 56
#
Heading/
Heading/ CPR CPR CPR
TYPE Ground Time
Field Movement Ground Format Encoded Encoded
Code Track (T)
Name [7] Track (F) Latitude Longitude
[5] Status [1]
[7] [1] [17] [17]
[1]
MSB MSB MSB MSB MSB
LSB LSB LSB LSB LSB
Figure 2-5: ADS-B Surface Position Message Format
2.2.3.2.4.1 TYPE Code Subfield in ADS-B Surface Position Messages

The TYPE Code subfield was previously specified for the Airborne Position Message
in 2.2.3.2.3.1 and remains the same for the ADS-B Surface Position Message, which
shall use TYPE Codes 5, 6, 7 and 8 only.
Detailed definition of the TYPE Code subfield encodings that shall be used for all
ADS-B Messages are provided in Table 2-16.
2.2.3.2.4.1.1 Surface Position Message TYPE Code if Radius of Containment is Available

If RC (horizontal radius of containment) information is available from the navigation data
source, then the ADS-B Transmitting Subsystem shall use RC to determine the TYPE
Code used in the Surface Position Message in accordance with Table 2-16.
ARINC 743A characteristic, a suitable source of information for the radius of
containment (RC), is ARINC 429 label 130 from that GNSS receiver.
2.2.3.2.4.1.2 Surface Position Message TYPE Code if Radius of Containment is Not Available
If RC (horizontal radius of containment) information is NOT available from the
navigation data source, then the ADS-B Transmitting Subsystem shall indicate NIC=0 by
selecting a TYPE Code of 0 or 8 in the Surface Position Messages, as follows:
a. The ADS-B Transmitting Subsystem shall set the TYPE Code subfield to ZERO if
valid horizontal position information is NOT available, as described in
2.2.3.2.3.1.3.2 above.
20xx, RTCA, Inc.

70
b. The ADS-B Transmitting Subsystem shall set the TYPE Code subfield to 8 if valid
horizontal position information IS available. (This TYPE Code indicates that radius
of containment, RC, is either unknown or greater than or equal to 0.1 NM.) THIS
NEED TO BE CHANGED WITH THE ADDITION OF THE NIC SUPPLEMENT-
C AND THE NEW VALUES FOR RC ON THE SURFACE
2.2.3.2.4.1.3 Special Processing for TYPE Code Equal to ZERO
2.2.3.2.4.1.3.1 Significance of TYPE Code Equal to ZERO

As shown in Table 2-16, TYPE Code equal to ZERO (0) is labeled No Position
Information. This type of message is intended to be used when the latitude and/or
longitude information is not available, or is invalid.
A Surface Position Message with a TYPE Code eaual to ZERO (0) shall have all 56 bits
of the ME field set to ZERO.
Special processing is required for Surface Position Messages because a CPR encoded
value of ALL ZEROs in the latitude and longitude field is considered to be a valid
encoding.
2.2.3.2.4.1.3.2 Broadcast of TYPE Code Equal to ZERO

The requirements provided in 2.2.3.2.3.1.3.2 apply equally to the ADS-B Surface
Position Message except that subparagraph c is modified to read as follows:
c. Note that in all of the cases, a TYPE Code equal to ZERO infers a message of ALL
ZEROs.
2.2.3.2.4.1.4 TYPE Code based on Horizontal Protection Level or Estimated Horizontal Position
Accuracy
a. If valid horizontal position information is available, then the TYPE Code in the
Surface Position Message shall be set in the range from 5 to 8.
b. If RC (Horizontal Radius of Containment) information is available from the

navigation data source, the TYPE Coding shall be selected according to the RC
value, in accordance with Table 2-16.
c. If RC is not available from the navigation data source, then the TYPE Code shall be
set to 8.
2.2.3.2.4.2 Movement Subfield in ADS-B Surface Position Messages

The Movement subfield is a 7-bit (ME bits 6 through 12, Message bits 38 through
44) field that shall be used to encode information regarding the status of Movement of
the ADS-B Transmitting Subsystem in accordance with the coding provided in Table 2-
18.
20xx, RTCA, Inc.

71
Table 2-18: Movement Subfield Code Definitions

Coding Meaning Quantization
(Decimal)
0 No Movement Information Available
1 Aircraft Stopped (Ground Speed = 0 knots)
2 0 knots < Ground Speed 0.2315 km/h (0.125 kt)
3-8 0.2315 km/h (0.125 kt) < Ground Speed 1.852 km/h (1 kt) 0.2700833 km/h steps
9 - 12 1.852 km/h (1 kt) < Ground Speed 3.704 km/h (2 kt) 0.463 km /h (0.25 kt) steps
13 - 38 3.704 km/h (2 kt) < Ground Speed 27.78 km/h (15 kt) 0.926 km/h (0.50 kt) steps
124 324.1 km/h (175 kt) < Ground Speed
125 Reserved for Aircraft Decelerating
126 Reserved for Aircraft Accelerating
127 Reserved for Aircraft Backing-Up
Notes:
1. The data encoding represented in Table 2-18 represents a non-linear encoding:

therefore, encoding is performed exactly as specified in the table.
2. The last three movement encodings (125, 126, 127) are reserved to indicate high
levels of ground speed change, etc. The precedence of the codes is not defined yet as
inputs that would be required are not currently available.
2.2.3.2.4.3 Status Bit for Heading/Ground Track Subfield in ADS-B Surface Position
Messages
The Status Bit for Heading/Ground Track subfield is a 1-bit (ME bit 13, Message bit
45) field that shall be used to indicate the validity of the Heading or Ground Track as
specified in Table 2-19.
Table 2-19: Status Bit for Heading/Ground Track Encoding

Coding Meaning
0 Heading/Ground Track data is NOT VALID
1 Heading/Ground Track data is VALID
Note: If a source of A/V Heading is not available to the ADS-B Transmitting

Subsystem, but a source of Ground Track angle is available, then Ground Track
angle may be used instead of Heading, provided that the Status Bit for
Heading/Ground Track subfield is set to ZERO whenever the Ground Track
angle is not a reliable indication of the A/Vs heading. (The Ground Track angle
is not a reliable indication of the A/Vs heading when the A/Vs ground speed is
close to ZERO.)
20xx, RTCA, Inc.

72
2.2.3.2.4.4 Heading/Ground Track Subfield in ADS-B Surface Position Messages

The Heading/Ground Track Subfield is a 7-bit (ME bit 14 through 20, Message Bit
46 through 52) field that shall be used to report the Heading, or motion of the ADS-B
Transmitting Subsystem, Clockwise from North (i.e., Heading Sign Bit = 0). Encoding
of the Heading/Ground Track Subfield is specified in Table 2-20.
Table 2-20: Heading/Ground Track Encoding

Coding Meaning
(Binary) (Decimal) (Heading/Ground Track in degrees)
000 0000 0 Heading/Ground Track is ZERO
000 0001 1 Heading/Ground Track = 2.8125 degrees
*** *** ***
*** *** ***
Notes:
1. The encoding shown in the table represents an Angular Weighted Binary encoding in
degrees clockwise from True or Magnetic North. The MSB represents a bit
weighting of 180 degrees, while the LSB represents a bit weighting of 360/128
degrees.
2. Raw data used to establish the Heading or Ground Track subfield will normally have
more resolution (i.e., more bits) than that required by the Heading/Ground Track
Subfield. When converting such data to the Heading/Ground Track Subfield, the
accuracy of the data must be maintained such that it is not worse than LSB where
the LSB is the weight of the least significant bit of the Heading subfield.
3. The reference direction for Heading (whether True North or Magnetic North) is
indicated in the Horizontal Reference Direction (HRD) field of the Aircraft
Operational Status Message (2.2.3.2.7.2.13).
2.2.3.2.4.5 TIME (T) Subfield in ADS-B Surface Position Messages

The TIME (T) subfield is a 1-bit (ME bit 21, Message bit 53) field that shall be used
to indicate whether or not the epoch of validity for the horizontal position data in a
Surface Position Message is an exact 0.2 second UTC epoch. If the time of applicability
of the position data is synchronized to an exact 0.2 second UTC epoch, the TIME (T)
subfield shall be set to ONE (1); otherwise, the TIME (T) subfield shall be set to
ZERO (0).
The TIME (T) subfield may be set to ONE (1) only for TYPE Codes 5 and 6 (see
2.2.3.2.3.1 and Table 2-16) when used to indicated synchronization as discussed in the
previous paragraph.
20xx, RTCA, Inc.

73
Notes:
1. An ADS-B Transmitting Subsystem that sets the TIME (T) subfield to ONE (1)
must accept a GNSS TIME MARK input from the navigation data source in order to
be able to update the position data from the navigation data source to an exact 0.2
second UTC epoch (see 2.2.5.1.6).
2. An arithmetic description of the intended synchronization implementation is provided

in the Commentary paragraphs provided in 2.2.3.2.4.7.2 for precision Latitude
Position Extrapolation and in 2.2.3.2.4.8.2 for precision Longitude Position
Extrapolation.
2.2.3.2.4.6 CPR Format (F) Subfield in ADS-B Surface Position Messages

The CPR Format (F) subfield is a 1-bit (ME bit 22, Message bit 54) field that shall
be used to indicate which Compact Position Reporting (CPR) format type (even or
odd) is used to encode the latitude and longitude data (see 2.2.3.2.4.7 and
2.2.3.2.4.8). The bit shall be set to ZERO to indicate the even encoding of such
data, or to ONE to indicate the odd encoding of such data.
a. When TIME (T) = 0:
The CPR Format (F) subfield functions ONLY to indicate the even or odd
CPR encoding. In this case, the CPR encoding type shall alternate between even
and odd, and the CPR Format (F) subfield shall alternate between ZERO (0)
and ONE (1) respectively, each time the Surface Position Message register is updated
with new position data.
Note: When the TIME (T) subfield is ZERO, the Surface Position Message
register must be updated at least as frequently as every 200 milliseconds:
however, it may be updated more frequently, for example, every 100
milliseconds, etc. In such cases, the CPR encoding should alternate between
even and odd each time that the register is updated with new position
data.
b. When TIME (T) = 1:
The CPR Format (F) subfield functions to indicate the even or odd CPR
encoding and also indicates whether the epoch of applicability of the position data is
an even or odd 0.2 second UTC epoch.
Notes:
1. Although the Surface Position Message register may be updated more frequently
than five times per second, when T=1, the CPR Format (F) subfield alternates
between ZERO (0) and ONE (1) only as the epoch of applicability of the data being
loaded into the register alternates between even and odd 0.2 second UTC
epochs.
20xx, RTCA, Inc.

74
2. An even 0.2 second UTC epoch is defined as that moment on the UTC time scale
that occurs at an even number of 200-millisecond intervals after an exact even-
numbered UTC second. Likewise, an odd 0.2 second UTC epoch is defined as that
moment on the UTC time scale that occurs at an odd number of 200 millisecond
intervals after an even numbered UTC second. Examples of even 0.2 second epochs
are 12.0 seconds, 12.4 seconds, 12.8 seconds, 13.2 seconds, 13.6 seconds, etc.
Examples of odd 0.2 second epochs are 12.2 seconds, 12.6 seconds, 13.0 seconds,
13.4 seconds, 13.8 seconds, etc.
2.2.3.2.4.7 CPR Encoded Latitude Subfield in ADS-B Surface Position Messages

The CPR Encoded Latitude subfield is a 17-bit (ME bit 23 through 39, Message bit
55 through 71) field that shall contain the encoded latitude of the Surface position.
2.2.3.2.4.7.1 Surface Latitude Data Encoding

The surface latitude position data shall be encoded in accordance with A.1.4.2.2 and
2.2.3.2.4.7.2 Surface Latitude Position Extrapolation/Estimation (Precision Case, TYPE Codes 5

and 6)
The following subsections apply to Surface Position Messages with TYPE Codes of 5
and 6 (see 2.2.3.2.3.1).

If TIME (T) = 1 (see 2.2.3.2.3.5) in a Surface Position Message, then the time of
second UTC epoch.
applicability of the Surface Position Message.
b. The Surface latitude data registers and the encoded latitude subfield shall be updated
every 200 milliseconds to the next 0.2 UTC Epoch using the velocity data provided
for the position fix.
Notes:
1. The time of validity of the fix is provided with the fix data from the navigation
data source and is indicated by the leading edge of the GNSS Time Mark (see
2.2.5.1.6). The time of applicability of the position message is the exact 0.2
second UTC Epoch to which the position data is extrapolated.
2. The latitude position registers and encoded latitude subfield should be updated
at a time about 100 milliseconds before the time of applicability of the data being
20xx, RTCA, Inc.

75
COMMENTARY:
The following example provides one method (not the only method) that latitude
given in the Surface Position Message may be extrapolated from the time of
time of applicability of the Surface Position Message. In the example, it is
assumed that the TIME (T) subfield (see 2.2.3.2.3.5) is ONE, indicating
that the time of applicability of the extrapolated position is an exact 0.2 second
UTC Epoch.
Let:
tmessage = time of applicability of the Surface Position Message,
message = latitude, extrapolated forward to the time of
applicability the Surface Position Message, tmessage
message = fix +
= fix +( NS/60)( t /3600000)
= fix +( NS t) / (2.16 x 108)
latitude per hour, and divide t by 3600 x 1000 to convert from milliseconds
to hours.)
The result, message, is to be encoded in the latitude field of the Surface

ADS-B Surface Position Messages corresponding to precision categories 5 and 6 (see
20xx, RTCA, Inc.

76

b. Sampled data implementations shall update the surface latitude data registers and
2.2.3.2.4.7.3 Surface Latitude Position Extrapolation/Estimation (non - precision)
2.2.3.2.4.7.3.1 Surface Latitude Position Extrapolation Case (non - precision)

ADS-B Surface Position Messages with TYPE Codes other than 5 or 6 (see 2.2.3.2.3.1)
shall contain an estimate of the latitude position at a time of applicability that is within
200 milliseconds of the time that the Surface Position Message is transmitted.
Essentially, the original data and the encoded latitude shall be updated at least as
frequently as every 200 milliseconds.
COMMENTARY:
The only difference between latitude position extrapolation in the non-precision
received position update to the expected time of transmission of a Surface
Position Message that is based on the last position update.
(In the precision case, t is the time interval from the last received leading edge
of the GNSS Time Mark to the 0.2 second UTC Epoch which is to be the time of
applicability of the Surface Position Message).
Let:
tupdate = time when the transmitting ADS-B Subsystem receives
the most recent PVT (position, velocity, time) data from
a navigation data source.
tmessage = time of applicability of the Surface Position Message
message = latitude, extrapolated forward to the time of
applicability of the Surface Position Message, tmessage
20xx, RTCA, Inc.

77
message = fix +
= fix +( NS/60)( t /3600000)
= fix +( NS t) / (2.16 x 108)

latitude per hour, and divide t by 3600 x 1000 to convert from milliseconds to
hours.)
The result, message, is to be encoded in the latitude field of the Surface Position
Note: In order not to introduce excessive error in the estimated latitude, message, the
latency, tupdate - tfix, in the delivery of PVT data from the navigation data
source should not be excessive.
2.2.3.2.4.7.3.2 Surface Latitude Position Estimation Case (non - precision)

ADS-B Airborne Position Messages that do not correspond to precision categories 5 and
6 (see 2.2.3.2.3.1) may implement estimation techniques such as alpha-beta trackers or
Kalman filters to satisfy the intent of the position update requirements given in
2.2.3.2.4.7.3.1. Such techniques provide the capability to decouple the position
computation from the message transmission timing provided that the sampled data rate is
sufficient to satisfy minimum Nyquist criterion. Likewise such techniques may be
necessary in order to provide velocity compensation and/or acceleration estimation in the
future.

b. Sampled data implementations shall update the surface latitude data registers and
2.2.3.2.4.7.4 Surface Latitude Position Data Retention

The extrapolation and update of latitude data and fields specified in 2.2.3.2.4.7.2
through 2.2.3.2.4.7.3.2 shall be limited to no more than two seconds, in the event that
the latitude position data is no longer available. At the end of two seconds, the latitude
data registers and the encoded latitude field shall be set to ALL ZEROs.
2.2.3.2.4.8 CPR Encoded Longitude Subfield in ADS-B Surface Position Messages

The CPR Encoded Longitude subfield is a 17-bit (ME bit 40 through 56, Message bit
72 through 88) field that shall contain the encoded longitude of the Surface position.
20xx, RTCA, Inc.

78
2.2.3.2.4.8.1 Surface Longitude Data Encoding

The surface longitude position data shall be encoded in accordance with A.1.4.2.2 and
2.2.3.2.4.8.2 Surface Longitude Position Extrapolation/Estimation (Precision Case, TYPE Codes

5 and 6)

If TIME (T) = 1 (see 2.2.3.2.3.5) in a Surface Position Message, then the time of
second UTC epoch.
applicability of the Surface Position Message.
b. The Surface longitude data registers and the encoded longitude subfield shall be
Notes:
2. The longitude position registers and encoded longitude subfield should be updated at
a time about 100 milliseconds before the time of applicability of the data being
COMMENTARY:
The following example provides one method (not the only method) that longitude
given in the Surface Position Message may be extrapolated from the time of
time of applicability of the Surface Position Message. In the example, it is
assumed that the TIME subfield (see 2.2.3.2.3.5) is ONE, indicating that
the time of applicability of the extrapolated position is an exact 0.2 second UTC
Epoch.
Let:
tmessage = time of applicability of the Surface Position Message, is
an exact 0.2 second UTC Epoch.
20xx, RTCA, Inc.
79

fix may be used)
easterly velocity)
message = fix +
= fix + [( EW)/(60 cos ( ))] x ( t /3600000)

= fix +( EW t) / [(2.16 x 108) cos( )]
The result, message, is to be encoded in the longitude field of the Surface Position

ADS-B Surface Position Messages with TYPE Codes of 5 and 6 (see 2.2.3.2.3.1) may
implement estimation techniques such as alpha-beta trackers or Kalman filters to satisfy
the intent of the position update requirements given in 2.2.3.2.4.8.2.1. Such techniques
provide the capability to decouple the position computation from the message
transmission timing provided that the sampled data rate is sufficient to satisfy minimum
Nyquist criterion. Likewise such techniques may be necessary in order to provide
velocity compensation and/or acceleration estimation in the future.

b. Sampled data implementations shall update the surface longitude data registers and
20xx, RTCA, Inc.

80
2.2.3.2.4.8.3 Surface Longitude Position Extrapolation/Estimation (non - precision)
2.2.3.2.4.8.3.1 Surface Longitude Position Extrapolation Case (non - precision)

ADS-B Surface Position Messages with TYPE Codes other than 5 or 6 (see 2.2.3.2.3.1)
shall contain an estimate of the longitude position at a time of applicability that is within
200 milliseconds of the time that the Surface Position Message is transmitted.
Essentially, the original data and the encoded longitude shall be updated at least as
frequently as every 200 milliseconds.
COMMENTARY:
The only difference between longitude position extrapolation in the non-precision
received position update to the expected time of transmission of an Surface
Position Message that is based on the last position update. (In the precision
case, t is the time interval from the last received leading edge of the GNSS Time
Mark to the 0.2 second UTC Epoch which is to be the time of applicability of the
Surface Position Message).
Let:
tupdate = time when the transmitting ADS-B Subsystem receives
the most recent PVT (position, velocity, time) data from
a navigation data source.
tmessage = time of applicability of the Surface Position Message
message - fix, in degrees
=
fix may be used)
last known E-W velocity at time tfix, in knots (positive for
EW =
easterly velocity)
message = fix +
= fix + [( EW)/(60 cos ( ))] x ( t /3600000)
= fix +( EW t) / [(2.16 x 108) cos( )]
20xx, RTCA, Inc.

81
The result, message, is to be encoded in the longitude field of the Surface

Note: In order not to introduce excessive error in the estimated longitude, message,
the latency, tupdate - tfix, in the delivery of PVT data from the navigation data
source should not be excessive.
2.2.3.2.4.8.3.2 Surface Longitude Position Estimation Case (non - precision)

ADS-B Surface Position Messages with TYPE Codes other than 5 and 6 (see

b. Sampled data implementations shall update the surface longitude data registers and
2.2.3.2.4.8.4 Surface Longitude Position Data Retention

The extrapolation and update of longitude data and fields specified in 2.2.3.2.4.8.2
through 2.2.3.2.4.8.3.2 shall be limited to no more than two seconds, in the event that
the longitude position data is no longer available. At the end of two seconds, the
longitude data registers and the encoded longitude field shall be set to ALL ZEROs.
20xx, RTCA, Inc.

82
2.2.3.2.5 ADS-B Aircraft Identification and Category Messages

Format for the Aircraft Identification and Category Message ME field contents is
specified in Figure 2-6. Each of the subfields is specified in the following subparagraphs.
Aircraft Identification and Category Message ME Field

Msg
Bit 33 - 37 38 -- 40 41 - 46 47 - 52 53 - 58 59 - 64 65 - 70 71 - 76 77 - 82 83 88
#
ME
Bit 1-5 6-8 9 - 14 15 - 20 21 - 26 27 - 32 33 - 38 39 - 44 45 - 50 51 - 56
#
ADS-B Ident Ident Ident Ident Ident Ident Ident Ident
TYPE
Field Emitter Char. Char. Char. Char. Char. Char. Char. Char.
Code
Name Category #1 #2 #3 #4 #5 #6 #7 #8
[5]
[3] [6] [6] [6] [6] [6] [6] [6] [6]
MSB MSB MSB MSB MSB MSB MSB MSB MSB MSB
LSB LSB LSB LSB LSB LSB LSB LSB LSB LSB
Figure 2-6: ADS-B Aircraft Identification and Category Message Format
2.2.3.2.5.1 TYPE Code Subfield in ADS-B Aircraft Identification and Category Message
in 2.2.3.2.3.1 and remains the same for the ADS-B Aircraft Identification and Category
Message, which uses TYPE Codes 1, 2, 3 and 4 only.
2.2.3.2.5.2 ADS-B Emitter Category Subfield in ADS-B Aircraft Identification and Category
Message
The ADS-B Emitter Category subfield is a 3-bit (ME bits 6 through 8, Message bits
38 through 40) field that shall be used to identify particular aircraft or vehicle types
within the ADS-B Emitter Category Sets A, B, C or D identified by Message Format
TYPE Codes 4, 3, 2 and 1, respectively. Each of the ADS-B Emitter Category Sets are
If the ADS-B Emitter Category is not available to the ADS-B Transmitting Subsystem,
then the device shall enter ALL ZEROs into the "ADS-B Emitter Category" Subfield in
the Aircraft Identification and Category Message.
20xx, RTCA, Inc.

83
Table 2-21: ADS-B Emitter Category SET Code Definitions

ADS-B Emitter Category SET A ADS-B Emitter Category SET B
Coding Meaning Coding Meaning
0 0 No ADS-B Emitter Category
No ADS-B Emitter Category Information
Information
1 Light (<15,500 lbs.) 1 Glider / Sailplane
2 Small (15,500 to 75,000 lbs.) 2 Lighter-than-Air
3 Large (75,000 to 300,000 lbs.) 3 Parachutist / Skydiver
4 High-Vortex Large (aircraft such as B-757) 4 Ultralight / hang-glider / paraglider
5 Heavy (> 300,000 lbs.) 5 Reserved
6 High Performance 6 Unmanned Aerial Vehicle
(>5g acceleration and > 400 knots) 7 Space / Trans-atmospheric vehicle
7 Rotorcraft
ADS-B Emitter Category SET C ADS-B Emitter Category SET D

Coding Meaning Coding Meaning
0 0 No ADS-B Emitter Category
Information
1 Surface Vehicle - Emergency Vehicle 1-7 Reserved
2 Surface Vehicle - Service Vehicle
3 Point Obstacle (includes tethered balloons)
4 Cluster Obstacle
5 Line Obstacle
6-7 Reserved
Note: The Emitter Category codes 1 to 5 in category set A are intended to advise
other aircraft of the transmitting aircrafts wake vortex characteristics, and not
necessarily the transmitting aircrafts actual maximum takeoff weight. In case of
doubt, the next higher aircraft category code should be used.
2.2.3.2.5.3 ID Character Subfield in ADS-B Aircraft Identification and Category Message

Each of the 8 Ident Character subfields is a 6-bit field as specified in Figure 2-6.
The 8 Ident Character subfields shall encode the following information:
a. If the flight identification used in the aircraft flight plan is available (e.g., an airline
flight number), then the flight identification used in the flight plan shall be encoded.
b. If the flight identification used in the aircraft flight plan is not available, then the
Aircraft Registration Marking shall be encoded.
c. Surface vehicles should encode their radio call signs.
The character in each of the Ident Character subfields is encoded as a 6-bit subset of
the International Alphabet Number 5 (IA-5) in accordance with the following documents:
a. ICAO, Annex 10, Volume IV, fourth edition, July 2007, 3.1.2.9.1.2 and Table 3-9.
20xx, RTCA, Inc.

84
Note: The international reference version of International Alphabet No. 5 (IA-5) is

defined in full in ICAO, Annex 10, Volume III, Part 1, Amendment No. 82,
dated 11/22/2007, Table 8-2.
b. RTCA DO-181D, 2.2.19.1.13, (EUROCAE ED-73C, 3.23.1.13) and
c. A.1.4.4 of Appendix A.
2.2.3.2.6 ADS-B Airborne Velocity Messages

Formats for the various Airborne Velocity Messages are further classified by a Subtype
Code as identified in the following subparagraphs and Figure 2-7 and Figure 2-8.
20xx, RTCA, Inc.

85
Airborne Velocity Message Subtype=1 and 2 ME Field

MSG
BIT 33 - 37 38 - 40 41 42 43 - 45 46 47 - 56 57 58 - 67 68 69 70 - 78 79 - 80 81 82 88
#
ME
BIT 1-5 6-8 9 10 11 - 13 14 15 - 24 25 26 - 35 36 37 38 - 46 47 - 48 49 50 56
#
Diff
Diff
Reserved-A
Reserved-B
Intent E/W N/S Vert Vert from
E/W N/S Vert from
FIELD TYPE Subtype Change NACV Direction Direction Rate Rate Baro
[1]
[2]
Velocity Velocity Rate Baro
NAME [5] [3] Flag [3] Bit Bit Source Sign Alt
[10] [10] [9] Alt
[1] [1] [1] [1] [1] Sign
[7]
[1]
MSB MSB MSB MSB MSB MSB MSB MSB
LSB LSB LSB LSB LSB LSB LSB LSB
Figure 2-7: ADS-B Airborne Velocity Message Subtype 1&2
Airborne Velocity Message Subtype=3 and 4 ME Field

MSG
BIT 33 - 37 38 - 40 41 42 43 - 45 46 47 - 56 57 58 - 67 68 69 70 - 78 79 - 80 81 82 88
#
ME
BIT 1-5 6-8 9 10 11 - 13 14 15 - 24 25 26 - 35 36 37 38 - 46 47 - 48 49 50 56
#
Diff
Diff
Reserved-A
Reserved-B
Intent Heading Vert Vert from
Airspeed Vert from
FIELD TYPE Subtype Change NACV Status Heading Airspeed Rate Rate Baro
[1]
[2]
Type Rate Baro
NAME [5] [3] Flag [3] Bit [10] [10] Source Sign Alt
[1] [9] Alt
[1] [1] [1] [1] Sign
[7]
[1]
Figure 2-8: ADS-B Airborne Velocity Message Subtype 3&4
Note: The [#] provided in the Field description columns of Figure 2-7 and Figure 2-8 indicates the number of bits in the respective FIELD.
20xx, RTCA, Inc.

86
2.2.3.2.6.1 ADS-B Airborne Velocity Message - Subtype=1

a. The Airborne Velocity Message - Subtype=1 is illustrated in Figure 2-7 and shall be
transmitted by the Airborne ADS-B Transmitting Subsystem when Velocity Over
Ground information is available, and the transmitting device is installed in an
environment having NON-supersonic airspeed capability.
b. The Supersonic Version of the Airborne Velocity Message (i.e., Subtype=2) shall be
used if either the East/West velocity OR the North/South velocity exceeds 1022
knots. A switch to the normal velocity message (i.e., Subtype=1) shall be made if
both the East/West and the North/South velocities drop below 1000 knots.
c. The Airborne Velocity Message shall not be broadcast if the only valid data is the
Intent Change Flag.
(1). Transponder-Based ADS-B Transmitting Subsystems shall suppress the

broadcast by loading Register 0916 with ALL ZEROs and then discontinuing
updating of the Register until data input is available again. The Transponder
will ZERO the Airborne Velocity Message after 2.6 seconds and terminate the
broadcast.
(2). Non-Transponder-Based ADS-B Transmitting Subsystems shall ZERO the

Airborne Velocity Message after 2.6 seconds and terminate the broadcast as
specified in 2.2.3.3.2.11 and 2.2.3.3.2.12.
Each of the subfields of the Airborne Velocity Message - Subtype=1 is specified in the
2.2.3.2.6.1.1 TYPE Code Subfield in Airborne Velocity Message - Subtype=1

The TYPE Code subfield was previously specified in 2.2.3.2.3.1 and remains the
same for ADS-B Airborne Velocity Messages - Subtype=1 that use TYPE Code 19 only.
2.2.3.2.6.1.2 Subtype Code Subfield in Airborne Velocity Message - Subtype=1

The Subtype Code subfield is a 3-bit (ME bit 6 through 8, Message bit 38 through
40) field that shall be used to identify the subtypes of Airborne Velocity Messages as
20xx, RTCA, Inc.

87
Table 2-22: Airborne Velocity Message Subtype Code Field Encoding

Coding
(Binary) (Decimal)
Primary Message Contents
000 0 Reserved
Velocity Over Ground (i.e., Ground Speed) under normal
001 1 airspeed, i.e., non-supersonic, conditions
010 2 Velocity Over Ground (i.e., Ground Speed) under supersonic
conditions
Airspeed and Heading Information when Velocity Over Ground
011 3 information is not available and airspeed conditions are normal,
i.e., non-supersonic
Airspeed and Heading Information when Velocity Over Ground
100 4 information is not available and airspeed conditions are supersonic
101 5 Reserved
110 6 Reserved
111 7 Reserved
The ADS-B Airborne Velocity Messages - Subtype=1 shall use a Subtype encoding of
1.
2.2.3.2.6.1.3 Intent Change Flag Subfield in Airborne Velocity Messages - Subtype=1

The Intent Change Flag subfield is a 1-bit (ME bit 9, Message bit 41) field that shall
be used to indicate a change in intent as specified in Table 2-23, and transmitted in the
Airborne Velocity Message.
Table 2-23: Intent Change Flag Encoding

Coding Meaning
0 No Change in Intent
1 Intent Change
a. Mode-S Transponder Implementations
An Intent Change event shall be triggered 4 seconds after the detection of new
information being inserted in GICB Registers 4016 to 4216. This results in the Intent
Change Flag being set to ONE (1) and the code remains set for 18 1 seconds
following the intent change.
Notes:
1. GICB Register 4316 is not included since it contains dynamic data that will be
continuously changing.
2. A four second delay is required to provide for settling time for intent data
derived from manually set devices.
20xx, RTCA, Inc.

88
b. Non-Transponder-Based Implementations
Non-Transponder-Based transmission devices do not implement the Target State and

Status Messages and therefore do not set the Intent Change Flag. Therefore, such
devices shall set the Intent Change Flag to ZERO at all times.
2.2.3.2.6.1.4 Reserved Bit-A Subfield in Airborne Velocity Messages Subtype=1

The Reserved Bit-A subfield is a 1-bit (ME bit 10, Message bit 42) field that shall be
set to ZERO (0) in all ADS-B Transmitting Subsystems that comply with these MOPS.
This Reserved Bit-A subfield was identified in RTCA DO-260A as the IFR Capability
Flag subfield, and was required to be set to ONE only for transmitting aircraft that had
the capability for applications requiring ADS-B equipage Class A1 or above. The IFR
Capability Flag has been eliminated from the ADS-B MASPS (RTCA DO-242B), and
so has been removed from these requirements for the 1090ES MOPS.
2.2.3.2.6.1.5 NACV Subfield in Airborne Velocity Messages - Subtype=1

The NACV subfield is a 3-bit (ME bits 11 through 13, Message bits 43 through 45)
field that shall be used to indicate the Navigation Accuracy Category for Velocity as
The ADS-B Transmitting Subsystem shall accept, via an appropriate data interface, data
from which the own-vehicle Navigation Accuracy Category for Velocity (NACV) may be
inferred, and it shall use such data to establish the NACV subfields in transmitted ADS-B
Airborne Velocity Messages.
If the external data source provides 95% accuracy figures of merit for horizontal and
vertical velocity, then the ADS-B Transmitting Subsystem shall determine the value of
the NACV field in the Airborne Velocity Messages, Subtypes 1, 2, 3 and 4 (2.2.3.2.6.1,
2.2.3.2.6.2, 2.2.3.2.6.3 and 2.2.3.2.6.4, respectively) according to Table 2-25.
Note: Appendix J describes the manner in which GNSS position sources, which do not
output velocity accuracy, can be characterized so that a velocity accuracy value
associated with the position source can be input into ADS-B equipment as part of
the installation process.
Table 2-25: Determining NACV Based on Position Source Declared Horizontal

Velocity Error
Navigation Accuracy Category for Velocity
Coding
(Binary) (Decimal)
Horizontal Velocity Error
000 0 > 10 m/s
001 1 < 10 m/s
010 2 < 3 m/s
011 3 < 1 m/s
100 4 < 0.3 m/s
20xx, RTCA, Inc.

89
2.2.3.2.6.1.6 East/West Direction Bit Subfield in Airborne Velocity Messages - Subtype=1

The East/West Direction Bit subfield is a 1-bit (ME bit 14, Message bit 46) field that
shall be used to indicate the direction of the East/West Velocity Vector as specified in
Table 2-28.
Table 2-28: East/West Direction Bit Encoding

Coding Meaning
0 EAST
1 WEST
2.2.3.2.6.1.7 East/West Velocity Subfield in Airborne Velocity Messages - Subtype=1

The East/West Velocity subfield is a 10-bit (ME bit 15 through 24, Message bit 47
through 56) field that shall be used to report the East/West subsonic Velocity (in knots)
of the ADS-B Transmitting Subsystem.
Range, Resolution, and No Data encoding of the East/West Velocity subfield shall be
as shown in Table 2-29.
Table 2-29: East/West Velocity (subsonic) Encoding

Coding Meaning
(Binary) (Decimal) (E/W Velocity in knots) (subsonic)
00 0000 0000 0 No E/W Velocity information available
00 0000 0001 1 E/W Velocity is ZERO
00 0000 0010 2 E/W Velocity = 1 knot
00 0000 0011 3 E/W Velocity = 2 knots
*** *** ***
11 1111 1111 1023 E/W Velocity > 1021.5 knots
Notes:
1. The encoding shown in the table represents Positive Magnitude data only. Direction
is given completely by the East/West Direction Bit.
2. Raw data used to establish the East/West Velocity Subfield will normally have more
resolution (i.e., more bits) than that required by the East/West Velocity Subfield.
When converting such data to the East/West Velocity Subfield, the accuracy of the
data must be maintained such that it is not worse than LSB where the LSB is that
of the East/West Velocity subfield.
3. All velocity vector components are to be referenced to WGS-84 or to a coordinate

system consistent with WGS-84.
20xx, RTCA, Inc.

90
2.2.3.2.6.1.8 North/South Direction Bit Subfield in Airborne Velocity Messages - Subtype=1

The North/South Direction Bit subfield is a 1-bit (ME bit 25, Message bit 57) field
that shall be used to indicate the direction of the North/South Velocity Vector as shown
in Table 2-30.
Table 2-30: North/South Direction Bit Encoding

Coding Meaning
0 NORTH
1 SOUTH
2.2.3.2.6.1.9 North/South Velocity Subfield in Airborne Velocity Messages - Subtype=1

The North/South Velocity subfield is a 10-bit (ME bit 26 through 35, Message bit 58
through 67) field that shall be used to report the North/South subsonic Velocity (in knots)
Range, Resolution, and No Data encoding of the North/South Velocity subfield shall
be as shown in Table 2-31.
Table 2-31: North/South Velocity (subsonic) Encoding

Coding Meaning
(Binary) (Decimal) (N/S Velocity in knots) (subsonic)
00 0000 0000 0 No N/S Velocity information available
00 0000 0001 1 N/S Velocity is ZERO
00 0000 0010 2 N/S Velocity = 1 knot
00 0000 0011 3 N/S Velocity = 2 knots
*** *** ***
11 1111 1111 1023 N/S Velocity > 1021.5 knots
Notes:
is given completely by the North/South Direction Bit.
2. Raw data used to establish the North/South Velocity Subfield will normally have
more resolution (i.e., more bits) than that required by the North/South Velocity
Subfield. When converting such data to the North/South Velocity Subfield, the
accuracy of the data shall be maintained such that it is not worse than LSB
where the LSB is that of the North/South Velocity subfield.

2.2.3.2.6.1.10 Source Bit for Vertical Rate Subfield in Airborne Velocity Messages - Subtype=1
The Source Bit for Vertical Rate subfield is a 1-bit (ME bit 36, Message bit 68) field
that shall be used to indicate the source of Vertical Rate information by being encoded as
20xx, RTCA, Inc.

91
Table 2-32: Source Bit for Vertical Rate Encoding

Coding Meaning
0 Vertical Rate information from Geometric Source (GNSS or INS)
1 Vertical Rate information from Barometric Source
2.2.3.2.6.1.11 Sign Bit for Vertical Rate Subfield in Airborne Velocity Messages - Subtype=1
The Sign Bit for Vertical Rate subfield is a 1-bit (ME bit 37, Message bit 69) field
that shall be used to indicate the direction of the Vertical Rate Vector as shown in
Table 2-33.
Table 2-33: Sign Bit for Vertical Rate Encoding

Coding Meaning
0 UP
1 DOWN
2.2.3.2.6.1.12 Vertical Rate Subfield in Airborne Velocity Messages - Subtype=1

The Vertical Rate subfield is a 9-bit (ME bit through 38 through 46, Message bit 70
through 78) field that is used to report the Vertical Rate (in feet/minute) of the ADS-B
Transmitting Subsystem.
Range, Resolution, and No Data encoding of the Vertical Rate subfield shall be as
shown in Table 2-34.
Table 2-34: Vertical Rate Encoding

Coding Meaning
(Binary) (Decimal) (Vertical Rate in feet / minute)
0 0000 0000 0 No Vertical Rate information available
0 0000 0001 1 Vertical Rate is ZERO
0 0000 0010 2 Vertical Rate = 64 feet / minute
*** *** ***
1 1111 1111 511 Vertical Rate > 32608 feet / minute
Note: The encoding shown in the table represents Positive Magnitude data only.
Direction is given completely by the Sign Bit for Vertical Rate subfield.
2.2.3.2.6.1.13 Reserved Bits-B Subfield in Airborne Velocity Messages Subtype=1

The Reserved Bits-B subfield is a 2-bit (ME bits 47 48, Message bits 79 80) field
that shall be set to ZERO (binary 00) in all ADS-B Transmitting Subsystems that comply
with these MOPS.
This Reserved Bits-B subfield was identified in RTCA DO-260 as the Turn Indicator
subfield, and was required to be set to ZERO (binary 00) for all ADS-B Transmitting and
20xx, RTCA, Inc.
92
Receiving Subsystems that comply with that document also. The Turn Indicator was
eliminated from the ADS-B MASPS (RTCA DO-242A), and so has been removed from
the requirements for the 1090 MHz Extended Squitter data link.
2.2.3.2.6.1.14 Difference From Barometric Altitude Sign Bit Subfield in Airborne Velocity
Messages - Subtype=1
The Difference From Barometric Altitude Sign Bit subfield is a 1-bit (ME bit 49,
Message bit 81) field that shall be used to indicate the direction of the GNSS Altitude
Source data as shown in Table 2-35.
Table 2-35: Difference From Barometric Altitude Sign Bit Encoding

Coding Meaning
Geometric (GNSS or INS)
0
Altitude Source data is greater than (above) Barometric
Geometric (GNSS or INS)
1
Altitude Source data is less than (below) Barometric
2.2.3.2.6.1.15 Difference From Barometric Altitude Subfield in Airborne Velocity Messages -

Subtype=1
The Difference From Barometric Altitude subfield is a 7-bit (ME bits 50 through 56,
Message bits 82 through 88) field that is used to report the difference between Geometric
(GNSS or INS) Altitude Source data and Barometric Altitude when both types of
Altitude Data are available and valid. The difference between barometric altitude and
GNSS Height Above Ellipsoid (HAE) is preferred. However, GNSS Altitude (MSL)
may be used when airborne position is being reported using TYPE Codes 11 through 18.
If airborne position is being reported using TYPE Codes 9 or 10, only GNSS Height
Above the Ellipsoid (HAE) may be used. For TYPE Codes 9 and 10, if GNSS Height
Above the Ellipsoid (HAE) is not available, then the Difference from Barometric Altitude
subfield shall be set to ALL ZEROs.
Note: The basis for the barometric altitude difference (either GNSS HAE or Altitude
MSL) must be used consistently for the reported difference.
Range, Resolution, and No Data encoding of the Difference From Barometric Altitude
subfield shall be as shown in Table 2-36.
20xx, RTCA, Inc.

93
Table 2-36: Difference From Barometric Altitude Encoding

Coding Meaning
(Binary) (Decimal) (Geometric (GNSS or INS) Altitude Source data Difference in feet)
000 0000 0 No GNSS Altitude Source data Difference information available
000 0001 1 GNSS Altitude Source data Difference is ZERO
000 0010 2 GNSS Altitude Source data Difference = 25 feet
*** *** ***
111 1111 127 GNSS Altitude Source data Difference > 3137.5 feet
Note: The encoding shown in the table represents Positive Magnitude data only.
Direction is given completely by the Difference From Barometric Altitude Sign
Bit.

Ground information is available, and the transmitting device is installed in an
environment having a Supersonic airspeed capability.
used if either the East/West Velocity OR the North/South Velocity exceeds 1022
knots. A switch to the normal Airborne Velocity Message (i.e., Subtype=1) shall be
made if both the East/West and the North/South Velocities drop below 1000 knots.
Intent Change Flag.

will ZERO the Velocity Message after 2.6 seconds and terminate the broadcast.

Velocity Message after 2.6 seconds and terminate the broadcast, as specified in
2.2.3.3.2.11 and 2.2.3.3.2.12.
2.2.3.2.6.2.1 TYPE Code Subfield in Airborne Velocity Messages - Subtype=2

same for ADS-B Airborne Velocity Messages - Subtype=2 which use TYPE Code 19
only.
20xx, RTCA, Inc.

94
2.2.3.2.6.2.2 Subtype Code Subfield in Airborne Velocity Messages - Subtype=2

The Subtype Code subfield was previously specified in 2.2.3.2.6.1.2 and remains the
same for ADS-B Airborne Velocity Messages - Subtype=2 which shall use a subtype
encoding of 2.

The Intent Change Flag subfield was previously specified in 2.2.3.2.6.1.3 and remains
the same for ADS-B Airborne Velocity Messages - Subtype=2.

The Reserved Bit-A subfield was previously specified in 2.2.3.2.6.1.4 and remains the
same for ADS-B Airborne Velocity Messages Subtype=2.

The Navigation Accuracy Category - Velocity (NACV) subfield was previously
specified in 2.2.3.2.6.1.5 and remains the same for ADS-B Airborne Velocity Messages
- Subtype=2.
2.2.3.2.6.2.6 East/West Direction Bit Subfield in Airborne Velocity Messages - Subtype=2

The East/West Direction Bit subfield was previously specified in 2.2.3.2.6.1.6 and
remains the same for ADS-B Airborne Velocity Messages - Subtype=2.
2.2.3.2.6.2.7 East/West Velocity Subfield in Airborne Velocity Messages - Subtype=2

The East/West Velocity subfield is a 10-bit (ME bit 15 through 24, Message bit 47
through 56) field that shall be used to report the East/West supersonic Velocity (in knots)
Range, Resolution, and No Data encoding of the East/West Velocity subfield shall be
as shown in Table 2-37.
Table 2-37: East/West Velocity (supersonic) Encoding

Coding Meaning
(Binary) (Decimal) (E/W Velocity in knots) (supersonic)
00 0000 0000 0 No E/W Velocity information available
00 0000 0001 1 E/W Velocity is ZERO
*** *** ***
11 1111 1111 1023 E/W Velocity > 4086 knots
20xx, RTCA, Inc.

95
Notes:
is given completely by the East/West Direction Bit.
2. Raw data used to establish the East/West Velocity Subfield will normally have more
resolution (i.e., more bits) than that required by the East/West Velocity Subfield.
When converting such data to the East/West Velocity Subfield, the accuracy of the
data must be maintained such that it is not worse than LSB where the LSB is that
of the East/West Velocity subfield.

2.2.3.2.6.2.8 North/South Direction Bit Subfield in Airborne Velocity Messages - Subtype=2

The North/South Direction Bit subfield was previously specified in 2.2.3.2.6.1.8 and
2.2.3.2.6.2.9 North/South Velocity Subfield in Airborne Velocity Messages - Subtype=2

The North/South Velocity subfield is a 10-bit (ME bits 26 through 35, Message bits
58 through 67) field that shall be used to report the North/South Supersonic Velocity (in
knots) of the ADS-B Transmitting Subsystem.
Range, Resolution, and No Data encoding of the North/South Velocity subfield shall
be as shown in Table 2-38.
Table 2-38: North/South Velocity (supersonic) Encoding

Coding Meaning
(Binary) (Decimal) (N/S Velocity in knots)(supersonic)
00 0000 0000 0 No N/S Velocity information available
00 0000 0001 1 N/S Velocity is ZERO
*** *** ***
11 1111 1111 1023 N/S Velocity > 4086 knots
Notes:
is given completely by the North/South Direction Bit.
2. Raw data used to establish the North/South Velocity Subfield will normally have
more resolution (i.e., more bits) than that required by the North/South Velocity
Subfield. When converting such data to the North/South Velocity Subfield, the
accuracy of the data must be maintained such that it is not worse than LSB where
the LSB is that of the North/South Velocity subfield.
20xx, RTCA, Inc.
96

The Source Bit for Vertical Rate subfield was previously specified in 2.2.3.2.6.1.10
and remains the same for ADS-B Airborne Velocity Messages - Subtype=2.
The Sign Bit for Vertical Rate subfield was previously specified in 2.2.3.2.6.1.11 and

The Vertical Rate subfield was previously dspecified in 2.2.3.2.6.1.12 and remains the
same for ADS-B Airborne Velocity Messages - Subtype=2.
2.2.3.2.6.2.13 Reserved Bits-B Subfield in Airborne Velocity Subtype=2 Messages

The Reserved Bits-B subfield was previously specified in 2.2.3.2.6.1.13 and remains
the same for ADS-B Airborne Velocity Subtype=2 Messages.
The Difference From Barometric Altitude Sign Bit subfield was previously specified in
2.2.3.2.6.1.14 and remains the same for ADS-B Airborne Velocity Messages -
Subtype=2.

Subtype=2
The Difference From Barometric Altitude subfield was previously specified in
Subtype=2.

Ground information is not available, and the transmitting device is installed in an
environment having NON-supersonic airspeed capability.
20xx, RTCA, Inc.

97
used if the airspeed exceeds 1022 knots. A switch to the normal Velocity Message
(i.e., Subtype=3) shall be made if the airspeed drops below 1000 knots.
Intent Change Flag.

broadcast by loading Register 0916 with all ZEROs and then discontinuing
updating of the Register until data input is available again. The Transponder will
ZERO the Velocity Message after 2 seconds and terminate broadcast after 60
seconds, as specified in RTCA DO-181D (EUROCAE ED-73C).

Velocity Message after 2 seconds and terminate broadcast after 60 seconds, as
specified in 2.2.3.3.2.11 and 2.2.3.3.2.12.

only.

encoding of 3.


20xx, RTCA, Inc.

98

- Subtype=3.
2.2.3.2.6.3.6 Heading Status Bit Subfield in Airborne Velocity Messages - Subtype=3

The Heading Status Bit subfield is a 1-bit (ME bit 14, Message bit 46) field that
shall be used to indicate the availability of Heading information as shown in Table 2-
39.
Table 2-39: Heading Status Bit Encoding

Coding Meaning
0 Heading Data is NOT Available
1 Heading Data is Available
2.2.3.2.6.3.7 Heading Subfield in Airborne Velocity Messages - Subtype=3

The Heading subfield is a 10-bit (ME bits 15 through 24, Message bits 47 through
56) field that shall be used to report the Heading (in degrees) of the ADS-B
Range, Resolution, and No Data encoding of the Heading subfield shall be as shown in
Table 2-40.
Table 2-40: Heading Encoding

Coding Meaning
(Binary) (Decimal) (Heading in degrees)
00 0000 0000 0 Heading is ZERO
00 0000 0001 1 Heading = 0.3515625 degrees
00 0000 0010 2 Heading = 0.703125 degrees
00 0000 0011 3 Heading = 1.0546875 degrees
*** *** ***
01 1111 1111 511 Heading = 179.6484375 degrees
10 0000 0000 512 Heading = 180.0 degrees
10 0000 0001 513 Heading = 180.3515625 degrees
10 0000 0010 514 Heading = 180.703125 degrees
*** *** ***
11 1111 1110 1022 Heading = 359.296875 degrees
11 1111 1111 1023 Heading = 359.6484375 degrees
Notes:
1. The encoding shown in the table represents an angular weighted binary encoding in
degrees clockwise from True or Magnetic North. The MSB represents a bit
weighting of 180 degrees, while the LSB represents a bit weighting of 360/1024
degrees.
20xx, RTCA, Inc.

99
2. Raw data used to establish the Heading Subfield will normally have more resolution
(i.e., more bits) than that required by the Heading Subfield. When converting such
data to the Heading Subfield, the accuracy of the data must be maintained such that
it is not worse than LSB where the LSB is that of the Heading subfield.
3. The reference direction for Heading (whether True North or Magnetic North) is
Operational Status Message (2.2.3.2.7.2.13).
2.2.3.2.6.3.8 Airspeed Type Subfield in Airborne Velocity Messages - Subtype=3

The Airspeed Type subfield is a 1-bit (ME bit 25, Message bit 57) field that shall be
used to indicate the type of subsonic airspeed data provided in the Airspeed Subfield
(see 2.2.3.2.6.3.9) and is coded as specified in Table 2-41.
Table 2-41: Airspeed Type (subsonic) Encoding

Coding Meaning
0 Airspeed Type is Indicated Airspeed (IAS)
1 Airspeed Type is True Airspeed (TAS)
2.2.3.2.6.3.9 Airspeed Subfield in Airborne Velocity Messages - Subtype=3

The Airspeed subfield is a 10-bit (ME bit 26 through 35, Message bit 58 through 67)
field that shall be used to report the subsonic Airspeed, either Indicated or True, of the
ADS-B Transmitting Subsystem.
Range, Resolution, and No Data encoding of the Airspeed subfield shall be as shown
in Table 2-42.
Table 2-42: Airspeed (IAS or TAS) (subsonic) Encoding

Coding Meaning
(Binary) (Decimal) (Airspeed in knots) (subsonic)
00 0000 0000 0 No Airspeed information available
00 0000 0001 1 Airspeed is ZERO
00 0000 0010 2 Airspeed = 1 knot
00 0000 0011 3 Airspeed = 2 knots
*** *** ***
11 1111 1110 1022 Airspeed = 1021 knots
11 1111 1111 1023 Airspeed > 1021.5 knots
Note: The encoding shown in the table represents Positive Magnitude data only, since
Airspeed Data (IAS or TAS) is always considered to be positive. All velocity
vector components are to be referenced to WGS-84 or to a coordinate system
consistent with WGS-84.
20xx, RTCA, Inc.

100

The Vertical Rate subfield was previously specified in 2.2.3.2.6.1.12 and remains the

Subtype=3.

Subtype=3
The DIFFERENCE FROM BAROMETRIC ALTITUDE subfield was previously
specified in 2.2.3.2.6.1.15 and remains the same for ADS-B Airborne Velocity
Messages - Subtype=3.

Ground information is NOT available, and the transmitting device is installed in an
environment having Supersonic airspeed capability.
used if the airspeed exceeds 1022 knots. A switch to the normal Velocity Message
(i.e., Subtype=3) shall be made if the airspeed drops below 1000 knots.
20xx, RTCA, Inc.

101
Intent Change Flag.

will ZERO the Velocity Message after 2.6 seconds and terminate the broadcast.

Velocity Message after 2.6 seconds and terminate the broadcast, as specified in
2.2.3.3.2.11 and 2.2.3.3.2.12.

only.

encoding of 4.



- Subtype=4.
20xx, RTCA, Inc.

102
2.2.3.2.6.4.6 Heading Status Bit Subfield in Airborne Velocity Messages - Subtype=4

The Heading Status Bit subfield was previously specified in 2.2.3.2.6.3.6 and remains
2.2.3.2.6.4.7 Heading Subfield in Airborne Velocity Messages - Subtype=4

The Heading subfield was previously specified in 2.2.3.2.6.3.7 and remains the same
for ADS-B Airborne Velocity Messages - Subtype=4.
2.2.3.2.6.4.8 Airspeed Type Subfield in Airborne Velocity Messages - Subtype=4

The Airspeed Type subfield is a 1-bit (ME bit 25, Message bit 57) field that shall be
used to indicate the type of supersonic airspeed data provided in the Airspeed Subfield
(see 2.2.3.2.6.4.9) and is coded as specified in Table 2-43.
Table 2-43: Airspeed Type (supersonic) Encoding

Coding Meaning
0 Airspeed Type is Indicated Airspeed (IAS)
1 Airspeed Type is True Airspeed (TAS)
2.2.3.2.6.4.9 Airspeed Subfield in Airborne Velocity Messages - Subtype=4

The Airspeed subfield is a 10-bit (ME bit 26 through 35, Message bit 58 through 67)
field that shall be used to report the subsonic Airspeed, either Indicated or True, of the
ADS-B Transmitting Subsystem.
Range, Resolution, and No Data encoding of the Airspeed subfield shall be as shown
in Table 2-44.
Table 2-44: Airspeed (IAS or TAS) (supersonic) Encoding

Coding Meaning
(Binary) (Decimal) (Airspeed in knots) (supersonic)
00 0000 0000 0 No Airspeed information available
00 0000 0001 1 Airspeed is ZERO
00 0000 0010 2 Airspeed = 4 knot
00 0000 0011 3 Airspeed = 8 knots
*** *** ***
11 1111 1110 1022 Airspeed = 4084 knots
11 1111 1111 1023 Airspeed > 4086 knots
Note: The encoding shown in the table represents Positive Magnitude data only, since
Airspeed Data (IAS or TAS) is always considered to be positive. All velocity
vector components are to be referenced to WGS-84 or to a coordinate system
consistent with WGS-84.
20xx, RTCA, Inc.

103

The Vertical Rate subfield was previously specified in 2.2.3.2.6.1.12 and remains the

Subtype=3.

Subtype=4
The Difference From Barometric Altitude subfield was previously specified in
Subtype=4.
2.2.3.2.6.5 ADS-B Airborne Velocity Messages - Subtypes 5, 6, & 7

ADS-B Airborne Velocity Messages are not specified for Subtypes 5, 6 or 7 and
shall be considered to be Reserved for future expansion of Velocity Information Type
Messages.
20xx, RTCA, Inc.

104
2.2.3.2.7 ADS-B Periodic Status and Event-Driven Messages
2.2.3.2.7.1 Target State and Status Messages

The Target State and Status Message is used to provide the current state of an airborne
aircraft in navigating to its intended trajectory and the status of the aircrafts navigation
data source and TCAS/ACAS systems. For this version of these MOPS the Target State
and Status Message with Subtype=1 is defined to convey information on the aircrafts
target heading and altitude (i.e. Target State information) as well as information on the
status of the navigation data being used by ADS-B and the status of the aircraft TCAS
systems. The format of the Target State and Status Message shall be as specified in
Figure 2-9, while further definition of each of the subfields shall be as specified in the
subsequent paragraphs.
Note: The provisions of RTCA DO-260 related to TCP/TCP+1 were removed from the
initial publication of RTCA DO-260A, and provisions for a Target State and
Status Message were defined using the same message TYPE Code value (i.e,
TYPE Code = 29) as previously defined by RTCA DO-260 for the Aircraft
Trajectory Intent Messages that conveyed TCP/TCP+1 information. It is not
expected that any implementation based on RTCA DO-260 would have
implemented the messages for TCP and TCP+1. However, for purposes of
backward compatibility RTCA DO-260A required for a TYPE Code=29 message
that ME bit 11 always be set to ZERO (0), which would result in a RTCA DO-
260 conformant ADS-B receiver not attempting to make use of the remaining
contents of the message. Likewise, any TYPE Code=29 message transmitted by
an implementation based on DO-260 that has incorrectly set ME bit 11 set to
ONE (1) (i.e., indicating a valid TCP/TCP+1 Message is being transmitted)
should be discarded.
Target State and Status Message

Msg
Bit 33 ----------- 37 38 --------- 39 40 --------------------------- 88
#
ME
Bit 1 -------------- 5 6 ------------ 7 8 ----------------------------- 56
#
Field TYPE Code = 29 Subtype Intent/Status Information
Name (11101) Code (see 2.2.3.2.7.1.3)
[5] [2] [49]
MSB MSB MSB
LSB LSB LSB
Figure 2-9: Target State and Status Message Format
2.2.3.2.7.1.1 TYPE Code Subfield in Target State and Status Messages

in 2.2.3.2.3.1 and shall use the same subfield format for the Target State and Status
Message, which uses a TYPE Code of 29.
20xx, RTCA, Inc.

105
2.2.3.2.7.1.2 Subtype Code Subfield in Target State and Status Messages

The Subtype Code subfield is a 2-bit (ME bits 6 and 7, Message bits 38 and 39) field
that shall be used to identify if the format of the remainder of the Target State and Status
Message. The Subtype subfield shall be encoded in accordance with Table 2-45.
ADS-B Transmitting Subsystems that comply with these MOPS shall transmit a Subtype
Code equal to ONE (1).
Table 2-45: Subtype Code Subfield Encoding

Coding
Meaning
(Binary) (Decimal)
Reserved
00 0
(Target State and Status information was defined in RTCA DO-260A)
Target State and Status information is provided in the subsequent subfields
01 1
of the message (see 2.2.3.2.7.1.3)
10 2 Reserved
11 3 Reserved
2.2.3.2.7.1.3 Target State and Status Message (Subtype=1)

Target State and Status information is conveyed by the Target State and Status
Message (TYPE=29) when the Subtype=ONE (1). The format of the Target State and
Status Message for ADS-B Transmitting Subsystems that comply with these MOPS shall
be in accordance with Figure 2-10.
20xx, RTCA, Inc.

106
Msg
Bit 33 ----- 37 38 ----- 39 40 41 42 ------------------------52 53 --------------------------- 61
#
ME
Bit 1 ------ 5 6 ----- 7 8 9 10 ------------------------ 20 21 -------------------------- 29
#
TYPE Selected MCP/FCU Selected Altitude
Subtype=1 Barometric Pressure Setting
Field Code =29 SIL Altitude or
(0 1) Supplement (Minus 800 millibars)
Name (1 1 1 0 1) [1] Type FMS Selected Altitude
[2] [9]
[5] [1] [11]
MSB LSB MSB LSB MSB LSB MSB LSB
Msg
Bit 62 63 64 ---------------- 71 72 -----------------75 76 77 ---------- 78
#
ME
Bit 30 31 32 ---------------- 39 40 ---------------- 43 44 45 ----------- 46
#
Navigation Source
Selected Selected Navigation Accuracy
Selected Integrity Integrity
Field Heading Heading Category_Position
Heading Category_Baro Level
Name Status Sign (NACP)
[8] (NICBARO) (SIL)
[1] [1] [4]
[1] [2]
MSB LSB MSB LSB MSB LSB
Msg
Bit 79 80 81 82 83 84 85 86 -------- 88
#
ME
Bit 47 48 49 50 51 52 53 54 -------- 56
#
Status of VNAV Altitude Reserved
Autopilot Approach TCAS
Field MCP / FCU Mode Hold For ADS-R Reserved
Engaged Mode Operational
Name Mode Bits Mode Flag [3]
Engaged
[1] [1] [1]
[1] [1] [1] [1]
MSB LSB
Figure 2-10: Target State and Status Message (Subtype=1 Format)
2.2.3.2.7.1.3.1 SIL Supplement Subfield in Target State and Status Messages

The SIL Supplement (Source Integrity Level Supplement) subfield is a 1-bit (ME bit
8, Message bit 40) field that shall define whether the reported SIL probability is based on
a per hour probability or a per sample probability as defined in Table 2-46.
20xx, RTCA, Inc.

107
Table 2-46: SIL Supplement Subfield Encoding

Coding Meaning
0 Probability of exceeding NIC radius of containment is based on per hour
1 Probability of exceeding NIC radius of containment is based on per sample
Per Hour: The probability of the reported geometric position laying outside the
NIC containment radius in any given hour without an alert or an alert
longer than the allowable time-to-alert. The per hour representation
will typically be used when the probability of exceeding the NIC is
greater for the faulted versus fault-free Signal-in-Space case (When
the Signal-in-Space fault rate is defined as hourly).
Note: The probability of exceeding the integrity radius of

containment for GNSS position sources are based on a per
hour basis, as the NIC will be derived from the GNSS
Horizontal Protection Level (HPL) which is based on a
probability of 1X10-7 per hour.
Per Sample: The probability of a reported geometric position laying outside the
NIC containment radius. The per sample representation will typically
be used when the probability of exceeding the NIC is greater for the
fault-free Signal-in-Space case, or when the position source does not
depend on a Signal-in-Space.

containment for IRU, DME/DME and DME/DME/LOC
position sources may be based on a per sample basis.
2.2.3.2.7.1.3.2 Selected Altitude Type Subfield in Target State and Status Messages
a. The Selected Altitude Type subfield is a 1-bit (ME bit 9, Message bit 41) field
that shall be used to indicate the source of Selected Altitude data that is being used to
encode ME bits 10 through 20 (Message bits 42 through 52). Encoding of the
Selected Altitude Type shall be in accordance with Table 2-47.
Table 2-47: Selected Altitude Type Subfield Encoding

Coding Meaning
Data being used to encode ME bits 10 through 20 is derived from the
0 Mode Control Panel / Flight Control Unit (MCP / FCU) or equivalent
equipment.
1
Flight Management System (FMS).
b. Whenever there is no valid MCP / FCU or FMS Selected Altitude data available, then
the Selected Altitude Type subfield (ME bit 9, Message bit 41) shall be set to
ZERO (0).
20xx, RTCA, Inc.

108
2.2.3.2.7.1.3.3 MCP/FCU Selected Altitude or FMS Selected Altitude Subfield in Target State
and Status Messages
a. The MCP / FCU Selected Altitude or FMS Selected Altitude subfield is an 11-bit
(ME bits 10 through 20, Message bits 42 through 52) field that shall contain either
MCP / FCU Selected Altitude or FMS Selected Altitude data in accordance with the
b. Whenever valid Selected Altitude data is available from the Mode Control Panel /
Flight Control Unit (MCP / FCU) or equivalent equipment, such data shall be used to
encode ME bits 10 through 20 (Message bits 42 through 52) in accordance with
Table 2-48. Use of MCP / FCU Selected Altitude shall then be declared in the
Selected Altitude Type subfield as specified in Table 2-47.
c. Whenever valid Selected Altitude data is NOT available from the Mode Control
Panel / Flight Control Unit (MCP / FCU) or equivalent equipment, but valid Selected
Altitude data is available from the Flight Management System (FMS), then the FMS
Selected Altitude data shall be used to encode ME bits 10 through 20 (Message
bits 42 through 52) in accordance with Table 2-48 provided in paragraph d. Use of
FMS Selected Altitude shall then be declared in the Selected Altitude Type
subfield as specified in 2.2.3.2.7.1.3.2, Table 2-47.
d. Encoding of Selected Altitude data in ME bits 10 through 20 (Message bits 42

through 52) shall be in accordance with Table 2-48. Encoding of the data shall be
rounded so as to preserve accuracy of the source data within LSB.
Table 2-48: MCP/FCU Selected Altitude or FMS Selected Altitude Subfield Encoding
Coding
(ME bits 10 ---- 20) Meaning
(Binary) (Decimal)
000 0000 0000 0 NO Data or INVALID Data
000 0000 0001 1 0 feet
000 0000 0010 2 32 feet
000 0000 0011 3 64 feet
*** **** **** *** *** **** ****
*** **** **** *** *** **** ****
*** **** **** *** *** **** ****
111 1111 1110 2046 65440 feet
111 1111 1111 2047 65472 feet
e. Whenever there is NO valid MCP / FCU or FMS Selected Altitude data available,
then the MCP / FCU Selected Altitude or FMS Selected Altitude subfield (ME
bits 10 through 20, Message bits 42 through 52) shall be set to ZERO (0) as indicated
in Table 2-48.
20xx, RTCA, Inc.

109
2.2.3.2.7.1.3.4 Barometric Pressure Setting (Minus 800 millibars) Subfield in Target State and
Status Messages
a. The Barometric Pressure Setting (Minus 800 millibars) subfield is a 9-bit (ME
bits 21 through 29, Message bits 53 through 61) field that shall contain Barometric
Pressure Setting data that has been adjusted by subtracting 800 millibars from the
data received from the Barometric Pressure Setting source.
b. After adjustment by subtracting 800 millibars, the Barometric Pressure Setting shall
be encoded in ME bits 21 through 29 (Message bits 53 through 61) in accordance
with Table 2-49.
Table 2-49: Barometric Pressure Setting (Minus 800 millibars) Subfield Encoding
Coding
(Binary) (Decimal)
0 0000 0001 1 0 millibars
0 0000 0010 2 0.8 millibars
0 0000 0011 3 1.6 millibars
* **** **** *** *** **** ****
* **** **** *** *** **** ****
* **** **** *** *** **** ****
1 1111 1110 510 407.2 millibars
1 1111 1111 511 408.0 millibars
c. Encoding of Barometric Pressure Setting data in ME bits 21 through 29 (Message

bits 53 through 61) shall be rounded so as to preserve a reporting accuracy within
LSB.
d. Whenever there is NO valid Barometric Pressure Setting data available, then the
Barometric Pressure Setting (Minus 800 millibars) subfield (ME bits 21 through
29, Message bits 53 through- 1) shall be set to ZERO (0) as indicated in Table 2-49.
e. Whenever the Barometric Pressure Setting data is greater than 1209.5 or less than
800 millibars, then the Barometric Pressure Setting (Minus 800 millibars) subfield
(ME bits 21 through 29, Message bits 53 through 61) shall be set to ZERO (0).
2.2.3.2.7.1.3.5 Selected Heading Status Subfield in Target State and Status Messages
The Selected Heading Status subfield is a 1-bit (ME bit 30, Message bit 62) field that
shall be used to indicate the status of Selected Heading data that is being used to encode
ME bits 32 through 39 (Message bits 64 through 71) in accordance with Table 2-50.
20xx, RTCA, Inc.

110
Table 2-50: Selected Heading Status Subfield Encoding

Coding
Meaning
(ME bit 30)
Data being used to encode ME bits 32 through 39 (Message bits
0 64 through 71) is either NOT Available or is INVALID. See Table
2-52.
1
64 through 71) is Available and is VALID. See Table 2-52.
2.2.3.2.7.1.3.6 Selected Heading Sign Subfield in Target State and Status Messages
The Selected Heading Sign subfield is a 1-bit (ME bit 31, Message bit 63) field that
shall be used to indicate the arithmetic sign of Selected Heading data that is being used to
encode ME bits 32 through 39 (Message bits 64 through 71) in accordance with Table
2-51.
Table 2-51: Selected Heading Sign Subfield Encoding

Coding
Meaning
(ME bit 31)
64 through 71) is Positive in an angular system having a range
between +180 and 180 degrees. (For an Angular Weighted Binary
0
system which ranges from 0.0 to 360 degrees, the sign bit is positive
or Zero for all values that are less than 180 degrees). See Table 2-
52.
64 through 71) is Negative in an angular system having a range
1 between +180 and 180 degrees. (For an Angular Weighted Binary
system which ranges from 0.0 to 360 degrees, the sign bit is ONE
for all values that are greater than 180 degrees). See Table 2-52.
20xx, RTCA, Inc.

111
2.2.3.2.7.1.3.7 Selected Heading Subfield in Target State and Status Messages

a. The Selected Heading subfield is an 8-bit (ME bits 32 through 39, Message bits
64 through 71) field that shall contain Selected Heading data encoded in accordance
with Table 2-52.
Table 2-52: Selected Heading Status, Sign and Data Subfields Encoding
ME Bit Coding
30 31 32 -------- 39 Meaning
Status Sign Data
1 0 0000 0000 0.0 degrees
1 0 0000 0001 0.703125 degrees
1 0 0000 0010 1.406250 degrees
* * **** **** **** **** ****
* * **** **** **** **** ****
* * **** **** **** **** ****
1 0 1111 1111 179.296875 degrees
1 1 0000 0000 180.0 or -180.0 degrees
1 1 0000 0001 180.703125 or -179.296875 degrees
1 1 0000 0010 181.406250 or -178.593750 degrees
* * **** **** **** **** ****
* * **** **** **** **** ****
* * **** **** **** **** ****
1 1 1000 0000 270.000 or -90.0000 degrees
1 1 1000 0001 270.703125 or -89.296875 degrees
1 1 1000 0010 271.406250 or -88.593750 degrees
1 1 1111 1110 358.593750 or -1.4062500 degrees
1 1 1111 1111 359.296875 or -0.7031250 degrees
b. Encoding of Selected Heading data in ME bits 31 through 39 (Message bits 63

through 71) shall be rounded so as to preserve accuracy of the source data within
LSB.
c. Whenever there is NO valid Selected Heading data available, then the Selected
Heading Status, Sign, and Data subfields (ME bits 30 through 39, Message bits 62
through 71) shall be set to ZERO (0) as indicated in Table 2-52.
2.2.3.2.7.1.3.8 NACP Subfield in Target State and Status Messages

The Navigation Accuracy Category for Position (NACP) subfield is a 4-bit (ME bits 40
through 43, Message bits 72 through 75) subfield of the Target State and Status Message
that shall announce 95% accuracy limits for the horizontal position (and for some NACP
values, the vertical position) that is being currently broadcast in Airborne Position and
Surface Position Messages. Table 2-71 specifies the accuracy limits for each NACP
value. If an update has not been received from an on-board data source for NACP within
the past 5 seconds, then the NACP subfield shall be encoded as a value of ZERO (0)
indicating Unknown Accuracy.
20xx, RTCA, Inc.

112
Note: The Navigation Accuracy Category for Position (NACP) is reported so that
surveillance applications may determine whether the reported geometric position
has an acceptable level of accuracy for the intended use. See 2.1.2.13 of the
ADS-B MASPS, RTCA DO-242A, for a fuller description of NACP.
2.2.3.2.7.1.3.9 NICBARO Subfield in Target State and Status Messages

The NICBARO (Barometric Altitude Integrity Code) subfield is a 1-bit (ME bit 44,
Message bit 76) field that shall be used to indicate whether or not the barometric pressure
altitude being reported in the Airborne Position Message (2.2.3.2.3) has been
crosschecked against another source of pressure altitude. The NICBARO subfield shall
be encoded in accordance with Table 2-73, as specified in the Aircraft Operational Status
Message. If an update has not been received from an on-board data source for NICBARO
within the past 5 seconds, then the NICBARO subfield shall be encoded as a value of ZERO
(0).
2.2.3.2.7.1.3.10 Source Integrity Level (SIL) Subfield in Target State and Status Messages
The SIL (Source Integrity Level) subfield is a 2-bit (ME bits 45 and 46, Message bits
77 and 78) field that shall be used to define the probability of the reported horizontal
position exceeding the radius of containment defined by the NIC, without alerting,
assuming no avionics faults. The SIL will address the Signal-in-Space, if applicable, and
will be the higher of the faulted or fault free probability of the Signal-In-Space causing
the NIC radius of containment to be exceeded.
Note: The faulted Signal-in-Space case will represent the highest probability for GNSS
position sources while the fault free Signal-in-Space case will represent the
highest probability for DME/DME or DME/DME/LOC position sources because
the Signal-in-Space is monitored and for IRU position sources because there is
no Signal-in-Space.
The SIL probability can be defined as either per sample or per hour as defined in the
SIL Supplement (SILSUPP) in 2.2.3.2.7.1.3.1.
The SIL subfield shall be encoded in accordance with Table 2-72, as specified in the
Aircraft Operational Status Message. For installations where the SIL value is being
dynamically updated, if an update has not been received from an on-board data source for
SIL within the past 5 seconds, then the SIL subfield shall be encoded as a value of ZERO
(0), indicating Unknown.
Note: The SIL and NIC should be set to unknown if the ADS-B position source does not
supply an output certified to provide an indication of the integrity of the reported
position (e.g., such as HPL from GNSS systems).
2.2.3.2.7.1.3.11 Status of MCP/FCU Mode Bits Subfield in Target State and Status Messages
The Status of MCP / FCU Mode Bits subfield is a 1-bit (ME bit 47, Message bit 79)
field that shall be used to indicate whether the mode bits (ME bits 48, 49, 50 and 52,
Message bits 80, 81, 82 and 84) are actively being populated (e.g., set) in the Target State
and Status Message in accordance with Table 2-53.
20xx, RTCA, Inc.
113
Table 2-53: Status of MCP/FCU Mode Bits Subfield Encoding

Coding
Meaning
(ME Bit 47)
No Mode Information is being provided in ME bits 48, 49, 50 or
0
52 (Message bits 80, 81, 82, or 84)
Mode Information is deliberately being provided in ME bits 48,
1
49, 50 or 52 (Message bits 80, 81, 82, or 84)
If information is provided to the ADS-B Transmitting Subsystem to set either ME bit

48, 49, 50, or 52 (Message bit 80, 81, 82 or 84) to either 0 or 1, then bit 47 shall be
set to ONE (1). Otherwise, bit 47 shall be set to ZERO (0).
2.2.3.2.7.1.3.12 Autopilot Engaged Subfield in Target State and Status Messages

The Autopilot Engaged subfield is a 1-bit (ME bit 48, Message bit 80) field that
shall be used to indicate whether the autopilot system is engaged or not.
a. The ADS-B Transmitting Subsystem shall accept information from an appropriate

interface that indicates whether or not the Autopilot is engaged.
b. The ADS-B Transmitting Subsystem shall set ME bit 48 (Message bit 80) in
accordance with Table 2-54.
Table 2-54: Autopilot Engaged Subfield Encoding
Coding
Meaning
(ME Bit 48)
0 Autopilot is NOT Engaged (e.g., not actively coupled and flying the aircraft)
1 Autopilot is Engaged (e.g., actively coupled and flying the aircraft)
2.2.3.2.7.1.3.13 VNAV Mode Engaged Subfield in Target State and Status Messages
The VNAV Mode Engaged subfield is a 1-bit (ME bit 49, Message bit 81) field that
shall be used to indicate whether the Vertical Navigation Mode is active or not.

interface that indicates whether or not the Vertical Navigation Mode is active.
Table 2-55: VNAV Engaged Subfield Encoding
Coding
Meaning
(ME Bit 49)
0 VNAV Mode is NOT Active
1 VNAV Mode is Active
20xx, RTCA, Inc.

114
2.2.3.2.7.1.3.14 Altitude Hold Mode Subfield in Target State and Status Messages
The Altitude Hold Mode subfield is a 1-bit (ME bit 50, Message bit 82) field that
shall be used to indicate whether the Altitude Hold Mode is active or not.

interface that indicates whether or not the Altitude Hold Mode is active.
Table 2-56: Altitude Hold Mode Subfield Encoding
Coding
Meaning
(ME Bit 50)
0 Altitude Hold Mode is NOT Active
1 Altitude Hold Mode is Active
2.2.3.2.7.1.3.15 Reserved for ADS-R Flag Subfield in Target State and Status Messages
The Reserved for ADS-R Flag subfield is a 1-bit (ME bit 51, Message bit 83) field
that shall be used as specified in 2.2.18.4.6.
2.2.3.2.7.1.3.16 Approach Mode Subfield in Target State and Status Messages

The Approach Mode subfield is a 1-bit (ME bit 52, Message bit 84) field that shall
be used to indicate whether the Approach Mode is active or not.

interface that indicates whether or not the Approach Mode is active.
Table 2-57: Approach Mode Subfield Encoding
Coding
Meaning
(ME Bit 52)
0 Approach Mode is NOT Active
1 Approach Mode is Active
2.2.3.2.7.1.3.17 TCAS Operational Subfield in Target State and Status Messages

The TCAS Operational subfield is a 1-bit (ME bit 53, Message bit 85) field that shall
be used to indicate whether the TCAS System is Operational or not.
20xx, RTCA, Inc.

115

interface that indicates whether or not the TCAS System is Operational.
accordance with Table 2.2.3.2.7.1.3.17.
Table 2.2.3.2.7.1.3.17: TCAS Operational Subfield Encoding
Coding
Meaning
(ME Bit 53)
0 TCAS System is NOT Operational
1 TCAS System is Operational
Note: As a reference point, RTCA DO-181D Mode-S Transponders consider that the
TCAS System is operational when MB bit 16 of Register 1016 is set to ONE
(1). This occurs when the transponder / TCAS interface is operational and the
transponder is receiving TCAS RI=2, 3 or 4. (Refer to RTCA DO-181D
[EUROCAE ED-73C], Appendix B, Table B-3-16.
2.2.3.2.7.1.3.18 Reserved Subfield in Target State and Status Messages

ME bits 54 through 56 (Message bits 86 through 88) of the Target State and Status
Message are Reserved for future assignment and shall be set to ZERO (0) in this
version of these MOPS.
2.2.3.2.7.1.4 Reserved for TYPE=29 and Subtype > 1 Message Formats

This section is reserved for future editions of these MOPS to specify additional Target
State and Status Messages with the TYPE Code equal to 29 and the Subtype greater than
ONE (1).
2.2.3.2.7.2 Aircraft Operational Status Messages

The Aircraft Operational Status Message is used to provide the current status of the
aircraft. The format of the Aircraft Operational Status Message shall be as specified in
Figure 2-11, while further definition of each of the subfields is provided in the
20xx, RTCA, Inc.

116
Aircraft Operational Status ADS-B Message ME Field Format

MSG
BIT 33 - 37 38 - 40 41 - 52 53 - 56 57 - 72 73 - 75 76 77 - 80 81 - 82 83 - 84 85 86 87 88
#
ME
BIT 1-5 6-8 9 - 20 21 - 24 25 - 40 41 - 43 44 45 - 48 49 - 50 51 - 52 53 54 55 56
#
Operational
Capability Class (CC)
Subtype=0 Mode (OM) GVA NICBARO
Codes Source
[3] Codes MOPS [2] [1]
[16] NIC Integrity SIL
FIELD TYPE=31 [16] Version NACP HRD Reserved
Supp-A Level Supp
NAME [5] Operational Number [4] [1] [1]
CC L/W [1] (SIL) [1]
Subtype=1 Mode (OM) [3] Reserved TRK/HDG
Codes Codes [2]
[3] Codes [2] [1]
[12] [4]
[16]
MSB MSB MSB MSB MSB MSB MSB MSB MSB
LSB LSB LSB LSB LSB LSB LSB LSB LSB
Note: Subfields that are relevant only for Airborne Participants are allocated to Subtype ZERO (binary 000), while those that
pertain only to Surface Participants are allocated to Subtype ONE (binary 001).
Figure 2-11: Aircraft Operational Status ADS-B Message ME Field Format
20xx, RTCA, Inc.

117
2.2.3.2.7.2.1 TYPE Code Subfield in Aircraft Operational Status Messages

in 2.2.3.2.3.1 and remains the same for the Aircraft Operational Status Message that
uses TYPE Code 31.
2.2.3.2.7.2.2 Subtype Code Subfield in Aircraft Operational Status Messages

The Subtype Code subfield is a 3-bit (ME bits 6 through 8, Message bits 38 through
40) subfield that shall be used to indicate various types of Aircraft Operational Status
Messages as specified in Table 2-58.
Table 2-58: Subtype Code Subfield in Aircraft Operational Status Messages Encoding
Coding Meaning
Message contains Aircraft Operational Status data as shown in
0
Figure 2-11 for Airborne Participants
Message contains Aircraft Operational Status data as shown in
1
Figure 2-11 for Surface Participants
2-7 Reserved
2.2.3.2.7.2.3 CAPABILITY CLASS (CC) Subfield in Aircraft Operational Status Messages

The Capability Codes (CC) subfield of the ADS-B Aircraft Operational Status Message
shall occupy 16 bits in the airborne format of that message and 12 bits in the surface
format of the message. In the airborne format (messages with TYPE=31, Subtype=0), the
CC codes shall occupy ME bits 9 through 24 (Message bits 41 through 56). In the
surface format (TYPE=31, Subtype=1), the CC codes shall occupy ME bits 9 through
20 (Message bits 41 through 52). The format of this subfield depends on the value of the
Version Number subfield (2.2.3.2.7.2.5). Moreover, for ADS-B Messages transmitted
from a Version 1 ADS-B Transmitting Subsystem, the CC format depends on whether
the ADS-B Aircraft Operational Status Message Subtype field is has a value of 0 or 1.
If the Version Number subfield (2.2.3.2.7.2.5) is ZERO (0), then the format of the CC
subfield is as specified in the initial version of these MOPS (RTCA DO-260). This is
summarized in Table 2-59.
20xx, RTCA, Inc.

118
Table 2-59: Capability Class (CC) Code Format in Version 0 Transmitting Subsystems
Msg
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
Bit #
ME
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Bit #
Not-
Content 0 0 CDTI Reserved
TCAS
1. Not-TCAS = TCAS/ACAS Not Installed Or Not Operational

2. CDTI = CDTI Traffic Display Capability
3. Reserved = Reserved for standardization in future versions of these MOPS
If the Version Number subfield (2.2.3.2.7.2.5) is TWO (2) (for ADS-B Transmitting
Subsystems conformant to RTCA DO-260A), and the Subtype subfield is ZERO (0) (for
Airborne Participants), then the format of the CC subfield shall be as specified in Table
2-60.
Table 2-60: Airborne Capability Class (CC) Code Format in Version 2 Transmitting Subsystems.
Msg Bit
41 42 43 44 45 46 47 48 49 50 51 52 -- 56
#
ME
9 10 11 12 13 14 15 16 17 18 19 20 -- 24
Bit #
Reserved TCAS 1090ES Reserved UAT Reserved
Content ARV TS TC
= 0,0 Operational IN = 0,0 IN [6]
0,1 Reserved
1,0 Reserved
1,1 Reserved
1. TCAS Operational = TCAS is Operational or Not Operational

2. 1090ES IN = Aircraft has ADS-B 1090ES Receive Capability
3. ARV = ARV Report Capability
4. TS = TS Report Capability
5. TC = TC Report Capability Level
6. UAT IN = Aircraft has ADS-B UAT Receive Capability
Subsystems conformant to RTCA DO-260B), and the Aircraft Operational Status
Message Subtype subfield is ONE (1) (indicating Surface Participants), then the format
of the CC subfield shall be as specified in Table 2-61.
20xx, RTCA, Inc.

119
Table 2-61: Surface Capability Class (CC) Code Format in Version 2 Transmitting Subsystems.
Msg Bit
41 42 43 44 45 46 47 48 49 51 52
#
ME
9 10 11 12 13 14 15 16 17 19 20
Bit #
Reserved 1090ES Reserved B2 UAT NACV NIC
Content POA
0,0 IN = 0,0 Low IN [3] Supplement-C
0,1 Reserved
1,0 Reserved
1,1 Reserved
1. POA = Position Offset Applied

2. 1090ES IN = Aircraft has ADS-B 1090ES Receive Capability
3. B2 Low = 1 if Class B2 Ground Vehicle is transmitting with less than 70 watts
4. UAT IN = Aircraft has ADS-B UAT Receive Capability
5. NACV = Navigation Accuracy Category for Velocity
6. NIC Supplement-C = NIC Supplement used on the Surface
Subsystems conformant to RTCA DO-260B), and an update has not been received from
an on-board data source within the past 5 seconds for any data element of the Capability
Class subfield, then the data associated with that data element shall be considered invalid
and so reflected in the encoding of that message element to reflect No Capability or
Unknown Capability.
2.2.3.2.7.2.3.1 Reserved CC Code Subfields in Aircraft Operational Status Message

Within the Capability Class subfield, ME bits 9-10, 13-14, and 20-24 (Message bits 41-
42, 45-46 and 52-56) shall be reserved for setting by a future version of these MOPS.
ADS-B equipment conforming to this version of these MOPS (RTCA DO-260B) shall
set these reserved bits to ALL ZEROs.
Note: Future versions of these MOPS may define values other than zero for these
reserved bits.
2.2.3.2.7.2.3.2 TCAS Operational CC Code Subfield in Aircraft Operational Status Messages

The TCAS Operational subfield (ME bit 11, Message bit 43) of the CC Codes
subfield in ADS-B Aircraft Operational Status Messages (TYPE=31, SUBTYPE=0, for
airborne participants) shall be used to indicate whether the TCAS System is Operational
or not, and remains as defined for use in the Target State and Status Message
(2.2.3.2.7.1.3.17), with the encoding as specified in Table 2.2.3.2.7.1.3.17.
20xx, RTCA, Inc.

120
2.2.3.2.7.2.3.3 1090ES IN CC Code Subfield in Aircraft Operational Status Messages

The CC Code subfield for 1090ES IN in Aircraft Operational Status Messages
(TYPE=31, Subtype=0 or 1) is a 1-bit field (ME bit 12, Message bit 44) that shall be
set to ONE (1) as specified in Table 2-63 if the transmitting aircraft has the capability to
receive ADS-B 1090ES Messages. Otherwise, this CC code subfield shall be set to
ZERO (0).
Table 2-63: Encoding of 1090ES IN CC Subfield in Aircraft Operational Status

Messages
1090ES IN CC
Meaning
Code Encoding
0 No Capability to Receive ADS-B 1090ES Messages
1 Aircraft has the Capability to Receive ADS-B 1090ES Messages
2.2.3.2.7.2.3.4 ARV Report Capability CC Code Subfield in Aircraft Operational Status

Messages
The ARV Report Capability subfield of the CC Codes subfield is a one-bit Boolean
flag that shall be encoded as specified in Table 2-64.
Table 2-64: ARV Report Capability Encoding.

Coding Meaning
No capability for sending messages to support Air Referenced Velocity
0
Reports
Capability of sending messages to support Air-Referenced Velocity
1
Reports.
2.2.3.2.7.2.3.5 TS Report Capability CC Code Subfield in Aircraft Operational Status Messages

The Target State (TS) Report Capability subfield of the CC Codes subfield is a one-bit
Boolean flag in the airborne format of the Aircraft Operational Status Message
(TYPE=31, Subtype=0) that shall be encoded as specified in Table 2-65.
Table 2-65: TS Report Capability Encoding.

Coding Meaning
0 No capability for sending messages to support Target State Reports
1 Capability of sending messages to support Target State Reports.
20xx, RTCA, Inc.

121
2.2.3.2.7.2.3.6 TC Report Capability CC Code Subfield in Aircraft Operational Status Messages

The Trajectory Change (TC) Report Capability subfield of the CC Code subfield is a
two-bit (ME bits 17 and 18) subfield in the airborne format of the Aircraft
Operational Status Message (TYPE=31, Subtype=0) and is defined in the ADS-B
MASPS (RTCA DO-242A) as specified in Table 2-66. For these MOPS the subfield
shall be set to ZERO (binary 00).
Table 2-66: TC Report Capability Encoding

Coding
Meaning
(Binary) (Decimal)
No capability for sending messages to support Trajectory Change
00 0
Reports
01 1 Capability of sending messages to support TC+0 Report only.
10 2 Capability of sending information for multiple TC reports.
11 3 (Reserved for future use.)
2.2.3.2.7.2.3.7 Position Offset Applied CC Code Subfield in Surface Aircraft Operational Status
Messages
The Position Offset Applied (POA) subfield of the CC Code subfield of the surface
format Aircraft Operational Status Message (TYPE=31, Subtype=1) is a one-bit Boolean
flag that the ADS-B Transmitting Subsystem shall set to ONE as specified in Table 2-67
if the position that it is transmitted in the ADS-B Surface Position Message (2.2.3.2.4) is
known to be the position of the ADS-B participants ADS-B Position Reference Point
(RTCA DO-242A, 3.4.4.9.7) rather than, for example, the position of the antenna of the
navigation receiver. Otherwise, the ADS-B Transmitting Subsystem shall set this flag to
ZERO.
Table 2-67: Position Offset Applied (POA) Encoding

Coding Meaning
The position transmitted in the Surface Position Message is not known
0
to be referenced to the ADS-B Position Reference Point of the A/V
The position transmitted in the Surface Position Message is known to
1
be referenced to the ADS-B Position Reference Point of the A/V
2.2.3.2.7.2.3.8 B2 Low CC Code Subfield in Surface Aircraft Operational Status Messages

The B2 Low subfield (ME bit 15) of the CC Code subfield in the surface version
of the Aircraft Operational Status Message (TYPE=31, Subtype=1) is a one-bit Boolean
flag that the ADS-B Transmitting Subsystem shall set to ONE (1) if the Transmitting
Subsystem is a Non-Transponder-Based Transmitting Subsystem on a Ground Vehicle
that meets the requirements of Class B2, except that it transmits with less than 70 watts of
power. Otherwise, this bit shall be set to ZERO (0).
Note: Setting the B2 Low CC Code bit indicates to airborne participants that any
transmissions from that surface participant are at lower than the minimum 70
watts power required of Class B2 participants by these MOPS.
20xx, RTCA, Inc.

122
2.2.3.2.7.2.3.9 NACV CC Code Subfield in Surface Aircraft Operational Status Messages

The requirements for establishing the values for the Navigation Accuracy Category for
Velocity (NACV) are stated in 2.2.3.2.6.1.5 in conjunction with the Airborne Velocity
Messages. The NACV subfield shall be provided in ME bits 17 through 19 (Message
bits 49 through 51) of the Surface Aircraft Operational Status Message.
2.2.3.2.7.2.3.10 UAT IN CC Code Subfield in Aircraft Operational Status Messages
The UAT IN CC Code subfield (ME bit 19, Message bit 51, TYPE=31, Subtype=0,
for airborne participants AND ME Bit 16, Message bit 48, TYPE=31, Subtype=1 for
surface participants) in ADS-B Aircraft Operational Status Messages denotes whether the
aircraft is equipped with the capability to receive ADS-B UAT Messages. The coding of
UAT IN CC Code subfield shall be as specified in Table 2.2.3.2.7.2.3.10.
Table 2.2.3.2.7.2.3.10: Encoding of UAT IN CC Subfield in Aircraft

Operational Status Messages.
UAT IN CC Code Encoding Meaning
0 No Capability to Receive ADS-B UAT Messages
1 Aircraft has the Capability to Receive ADS-B UAT Messages
The UAT IN CC Code in Aircraft Operational Status Messages shall be set to ZERO
(0) in Aircraft Operational Status Messages if the aircraft is NOT fitted with the
capability to receive ADS-B UAT Messages. The UAT IN CC Code Subfield in
Aircraft Operational Status Messages shall be set to ONE (1) if the aircraft has the
capability to receive ADS-B UAT Messages.
Note: If the aircraft is fitted with ADS-B UAT receive equipment but such equipment is
not functional, then the encoding should be set to ZERO (0), e.g., the same as
if the aircraft were NOT fitted with the receive capability.
2.2.3.2.7.2.3.11 NIC Supplement-C CC Code Subfield in Aircraft Operational Status Messages

The NIC Supplement-C subfield in the Aircraft Operational Status Message is a one-bit
subfield (ME bit 20, Message bit 52) that, together with the TYPE subfield in Surface
Position Messages and the NIC Supplement-A in the Operational Status Message (ME
Bit 44, Message Bit 76), shall be used to encode the Navigation Integrity Category (NIC)
of the transmitting ADS-B participant.
the NIC value within the past 5 seconds, then the NIC Supplement subfield shall be
Table 2-70 lists the possible NIC codes and the values of the TYPE subfield of the
Airborne and Surface Position Messages, and of the NIC Supplement subfields that shall
be used to encode those NIC codes in messages on the 1090 MHz ADS-B data link.
20xx, RTCA, Inc.

123
2.2.3.2.7.2.4 OPERATIONAL MODE (OM) Subfield in Aircraft Operational Status Messages

The Operational Mode (OM) subfield is a 16-bit subfield (ME bits 25 through 40,
Message bits 57 through 72) that shall indicate Operational Modes that are active on
board the A/V in which the ADS-B Transmitting Subsystem resides. The format of the
OM subfield in Aircraft Operational Status Messages, with Subtype=0 for airborne
participants shall be as specified in Table 2-68A. The format of the OM subfield in
Aircraft Operational Status Messages, with Subtype=1 for surface participants shall be as
specified in Table 2-68B.
Table 2-68A: Airborne Operational Mode (OM) Subfield Format

Msg Bit
57 58 59 60 61 62 63 -- 64 65 -- 72
#
"ME
25 26 27 28 29 30 31 32 33 40
Bit #
Reserved
TCAS IDENT for Single System
RA Switch Receiving Antenna Design Reserved
00
Active Active ATC Flag Assurance [8]
OM [1] [1] Services [1] [2]
Format [1]
01 Reserved
10 Reserved
11 Reserved
Table 2-68B: Surface Operational Mode (OM) Subfield Format

Msg Bit
57 58 59 60 61 62 63 -- 64 65 -- 72
#
"ME
25 26 27 28 29 30 31 32 33 40
Bit #
Reserved
GPS
RA Switch Receiving Antenna Design
00 Antenna Offset
Active Active ATC Flag Assurance
OM [8]
[1] [1] Services [1] [2]
Format [1]
01 Reserved
10 Reserved
11 Reserved
2.2.3.2.7.2.4.1 OM Subfield Format Code in Aircraft Operational Status Messages

The first two bits of the OM subfield (ME bits 25 and 26) shall be reserved for
selecting one of up to four OM subfield formats. For this version of these MOPS (DO-
260B), the OM subfield format code shall be set to ZERO (binary 00).
20xx, RTCA, Inc.

124
2.2.3.2.7.2.4.2 TCAS/ACAS Resolution Advisory Active OM Code Subfield in Aircraft

Operational Status Message
The TCAS/ACAS Resolution Advisory Active (RA Active) Operational Mode Code is
a one-bit subfield (ME bit 27, Message bit 59) of the OM subfield in Aircraft
Operational Status Messages (TYPE=31, Subtype=0 or 1). The ADS-B Transmitting
Subsystem shall set this code to ZERO (0) so long as a TCAS II or ACAS Resolution
Advisory is known not to be in effect (i.e., an update has been received within the last 2
seconds that indicates a TCAS/ACAS Resolution Advisory is not Active); otherwise, it
shall set this OM code to ONE (1).
2.2.3.2.7.2.4.3 IDENT Switch Active OM Code Subfield in Aircraft Operational Status Message
The IDENT Switch Active Operational Mode code is a one-bit subfield (ME bit 28,
message bit 60) of the OM Code subfield in Aircraft Operational Status Messages.
Initially, the IDENT Switch Active OM Code shall be set to ZERO. Upon activation
of the IDENT switch, the ADS-B Transmitting Subsystem shall set this code to ONE for
a period of 18 1 seconds; thereafter, the ADS-B Transmitting Subsystem shall set this
OM Code to ZERO.
Note: The requirement for an interface by which the ADS-B Transmitting Subsystem
may be informed when the IDENT switch is active is given in 2.2.5.1.30.
2.2.3.2.7.2.4.4 Reserved for Receiving ATC Services OM Code Subfield in Aircraft Operational
Status Message
ME bit 29, Message bit 61 of the OM Code subfield in Aircraft Operational Status
Messages shall be reserved for the Receiving ATC Services Operational Mode Code.
If implemented into future versions of these MOPS, an ADS-B Transmitting Subsystem
would set this OM Code to ONE when the ADS-B Transmitting Subsystem is Receiving
ATC Services, as indicated by an update having been received via an appropriate
interface on board the transmitting aircraft within the past 5 seconds. Otherwise, in this
version of these MOPS, this OM Code bit shall be set to ZERO.
Note: The requirement for an interface by which the ADS-B Transmitting Subsystem
may be informed when the aircraft is receiving ATC services is given in
2.2.5.1.31.
2.2.3.2.7.2.4.5 Single Antenna Flag OM Code Subfield in Aircraft Operational Status Messages
The Single Antenna subfield is a 1-bit (ME bit 30, Message bit 62) field that shall be
used to indicate that the ADS-B Transmitting Subsystem is operating with a single
antenna. The following conventions shall apply both to Transponder-Based and Stand
Alone ADS-B Transmitting Subsystems:
a. Non-Diversity, i.e., those transmitting functions that use only one antenna, shall set
the Single Antenna subfield to ONE at all times.
20xx, RTCA, Inc.

125
b. Diversity, i.e., those transmitting functions designed to use two antennas, shall set
the Single Antenna subfield to ZERO at all times that both antenna channels are
functional.
At any time that the diversity configuration cannot guarantee that both antenna channels
are functional, then the Single Antenna subfield shall be set to ONE.
Note: Certain applications may require confirmation that each participant has
functioning antenna diversity for providing adequate surveillance coverage.
2.2.3.2.7.2.4.6 System Design Assurance OM Code Subfield in Aircraft Operational Status

Messages
The System Design Assurance (SDA) subfield is a 2-bit (ME bits 31 32, Message
bits 63 64) field that shall define the failure condition that the ADS-B system is
designed to support as defined in Table 2.2.3.2.7.2.4.6.
The supported failure condition will indicate the probability of an ADS-B system fault
causing false or misleading information to be transmitted. The definitions and
probabilities associated with the supported failure effect are defined in AC 25.1309-1A,
AC 23-1309-1C, and AC 29-2C. All relevant systems attributes should be considered
including software and complex hardware in accordance with RTCA DO-178B
(EUROCAE ED-12B) or RTCA DO-254 (EUROCAE ED-80).
The ADS-B system includes the ADS-B transmission equipment, ADS-B processing
equipment, position source, and any other equipment that processes the position data
transmitted by the ADS-B system.
Table 2.2.3.2.7.2.4.6: System Design Assuance OM Subfield in Aircraft Operational Status

Messages
SDA Value Probability of Undetected Fault causing Software & Hardware

Supported Failure
transmission of False or Misleading Design Assurance Level
(binary Condition Note 2
Information Note 3,4 Note 1,3
(decimal)
)
Unknown/ No > 1X10-3 per flight hour

0 00 N/A
safety effect or Unknown
1 01 Minor 1X10-3 per flight hour D
2 10 Major 1X10 per flight hour
-5
C
3 11 Hazardous 1X10 per flight hour
-7
B
Notes:
1. Software Design Assurance per RTCA DO-178B (EUROCAE ED-12B). Airborne Electronic Hardware Design
Assurance per RTCA DO-254 (EUROCAE ED-80).
2. Supported Failure Classification defined in AC-23.1309-1C, AC-25.1309-1A, and AC 29-2C.
3. Because the broadcast position can be used by any other ADS-B equipped aircraft or by ATC, the provisions in
AC 23-1309-1C that allow reduction in failure probabilities and design assurance level for aircraft under
6,000 pounds do not apply.
4. Includes probability of transmitting false or misleading latitude, longitude, velocity, or associated accuracy
and integrity metrics.
20xx, RTCA, Inc.

126
2.2.3.2.7.2.4.7 GPS Antenna Offset OM Code Subfield in Aircraft Operational Status Messages
The GPS Antenna Offset subfield is an 8-bit (ME bits 33 40, Message bits 65 72)
field in the OM Code Subfield of surface format Aircraft Operational Status Messages
that shall define the position of the GPS antenna in accordance with the following when
Position Offset Applied (2.2.3.2.7.2.3.7) is set to ZERO (0).
a. Lateral Axis GPS Antenna Offset:
ME bits 33 through 35 (Message bits 65 through 67) shall be used to encode the
lateral distance of the GPS Antenna from the longitudinal axis (Roll) axis of the
aircraft. Encoding shall be established in accordance with Table 2.2.3.2.7.2.4.7A.
Table 2.2.3.2.7.2.4.7A: Lateral Axis GPS Antenna Offset Encoding

ME Bit
(Message Bit) GPS Antenna Offset
33 34 35 Along Lateral (Pitch) Axis
(65) (66) (67) Left or Right of Longitudinal (Roll) Axis
0 = left Encoding
1 = right Bit 1 Bit 0 Direction (meters)
0 0 0 or NO DATA
0 1 2
0 LEFT
1 0 4
1 1 6
0 0 0 or NO DATA
0 1 2
1 RIGHT
1 0 4
1 1 6
Notes:
1. Left means toward the left wing tip moving from the longitudinal
center line of the aircraft.
2. Right means toward the right wing tip moving from the
longitudinal center line of the aircraft.
3. Maximum distance left or right of aircraft longitudinal (roll) axis is
6 meters or 19.685 feet.
b. Longitudinal Axis GPS Antenna Offset:
ME bits 36 through 40 (Message bits 68 through 72) shall be used to encode the
longitudinal distance of the GPS Antenna from the NOSE of the aircraft. Encoding
shall be established in accordance with Table 2.2.3.2.7.2.4.7B.
20xx, RTCA, Inc.

127
Table 2.2.3.2.7.2.4.7B: Longitudinal Axis GPS Antenna Offset Encoding

Longitudinal Axis GPS Antenna Offset Encoding
ME Bit
36 37 38 39 40 Along Longitudinal (Roll) Axis
(68) (69) (70) (71) (72) Aft From Aircraft Nose
Encoding
Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 (meters)
0 0 0 0 0 0 or NO DATA
0 0 0 0 1 2
0 0 0 1 0 4
0 0 0 1 1 6
0 0 1 0 0 8
* * * * * ***
* * * * * ***
* * * * * ***
1 1 1 1 1 62
Note: Maximum distance aft from aircraft nose is 62 meters or 203.412 feet.
When Position Offset Applied (2.2.3.2.7.2.3.7) is set to ONE (1), the GPS Antenna
Offset subfield shall be set to ALL ZEROs (0).
Note: When Position Offset Applied (2.2.3.2.7.2.3.7) is set to ONE (1), it means that
the GPS antenna position has already been compensated for in the reported
latitude and longitude position subfields of the Surface Position Message.
Ensuring that the GPS Antenna subfield is set to ZERO in this case ensures that
the offset compensation is not performed again by a receiving application.
2.2.3.2.7.2.4.8 Reserved OM Code Subfield in Aircraft Operational Status Messages

Reserved bits, (ME bits 33 through 40, Message bits 65 through 72) in the OM Code
Subfield of Surface format Aircraft Operational Status Messages are reserved for future
assignment. Until such future assignment, these bits shall be set to ZERO (0).
2.2.3.2.7.2.5 ADS-B Version Number Subfield in Aircraft Operational Status Message

The ADS-B Version Number (VN) subfield is a 3-bit (ME bits 41 through 43,
Message bits 73 through 75) field that shall be used to indicate the Version Number of
the formats and protocols in use on the aircraft installation. Encoding of the ADS-B
Version Number subfield shall be as shown in Table 2-69. Airborne ADS-B systems
conformant to the initial version of the 1090 MHz ADS-B MOPS (RTCA DO-260) do
not broadcast an explicit ADS-B Version Number. Therefore, ADS-B Receiving
Subsystems conformant with this version of the 1090 MHz MOPS (RTCA DO-260B)
shall initially assume a Version Number of ZERO (binary 000), until a received ADS-B
Version Number data indicates otherwise.
20xx, RTCA, Inc.

128
Table 2-69: Version Number Subfield Encoding

Coding
Meaning
(Binary) (Decimal)
000 0 Conformant to DO-260 and DO-242
001 1 Conformant to DO-260A and DO-242A
010 2 Conformant to DO-260B and DO-242B
011 111 37 Reserved
2.2.3.2.7.2.6 NIC Supplement-A Subfield in Aircraft Operational Status Messages

The NIC Supplement-A subfield in the Aircraft Operational Status Message is a one-bit
subfield (ME bit 44, Message bit 76) that, together with the TYPE subfield in Airborne
Position and Surface Position Messages, shall be used to encode the Navigation Integrity
Category (NIC) of the transmitting ADS-B participant. In ADS-B Transmitting
Subsystems with Version Number=2, or later, the NIC Supplement-B is also broadcast in
the Airborne Position Message (2.2.3.2.3.3).
Note: The Navigation Integrity Category (NIC) is reported so that surveillance

applications may determine whether the reported geometric position has an
acceptable level of integrity for the intended use. See 2.1.2.12 of RTCA
DO-242A, the ADS-B MASPS, for a fuller description of the Navigation Integrity
Category.
the NIC value within the past 5 seconds, then the NIC Supplement subfield shall be
Table 2-70 lists the possible NIC codes and the values of the TYPE subfield of the
Airborne and Surface Position Messages, and of the NIC Supplement subfield that shall
be used to encode those NIC codes in messages on the 1090 MHz ADS-B data link.
20xx, RTCA, Inc.

129
Table 2-70: Navigation Integrity Category (NIC) Encoding.

Airborne Surface
NIC NIC
NIC Radius of Containment Airborne Supplement Surface Supplement
Value (RC) Position Codes Position Codes
TYPE Code TYPE Code
A B A C
0 RC unknown 0, 18 or 22 0 0 0, 8 0 0
1 RC < 20 NM (37.04 km) 17 0 0 N/A N/A N/A
2 RC < 8 NM (14.816 km) 16 0 0 N/A N/A N/A
3 RC < 4 NM (7.408 km) 16 1 1 N/A N/A N/A
4 RC < 2 NM (3.704 km) 15 0 0 N/A N/A N/A
5 RC < 1 NM (1852 m) 14 0 0 N/A N/A N/A
RC < 0.6 NM (1111.2 m) 13 1 1 8 0 1
6 RC < 0.5 NM (926 m) 13 0 0 N/A N/A N/A
RC < 0.3 NM (555.6 m) 13 0 1 8 1 0
7 RC < 0.2 NM (370.4 m) 12 0 0 8 1 1
8 RC < 0.1 NM (185.2 m) 11 0 0 7 0 0
9 RC < 75m 11 1 1 7 1 0
10 RC < 25m 10 or 21 0 0 6 0 0
11 RC < 7.5m 9 or 20 0 0 5 0 0
12 Reserved
13 Reserved
14 Reserved
15 Reserved
Notes:
1. N/A means This NIC value is not available in the ADS-B Surface Position
Message formats.
2. NIC Supplement-A is broadcast in the Aircraft Operational Status Message, ME

bit 44 (Message bit 76, see Figure 2-11). NIC Supplement-B is broadcast in the
Airborne Position Message, ME bit 8 (Message bit 40, see Figure 2-3). NIC
Supplement-C is broadcast in the Surface Capability Class (CC) Code Subfield of the
Aircraft Operational Status Message, ME bit 20 (Message bit 52, see Table 2-61).
2.2.3.2.7.2.7 Navigation Accuracy Category for Position (NACP) Subfield in Aircraft

Operational Status Messages
The Navigation Accuracy Category for Position (NACP) is a 4-bit subfield of the ADS-B
Aircraft Operational Status Message (ME bits 45 to 48, Message bits 77 to 80) that
shall announce 95% accuracy limits for the horizontal position (and for some NACP
values, the vertical position) that is being currently broadcast in airborne position and
surface position messages. Table 2-71 specifies the accuracy limits for each NACP value.
If an update has not been received from an on-board data source for NACP within the past
5 seconds, then the NACP subfield shall be encoded as a value of ZERO (0) indicating
Unknown Accuracy.
20xx, RTCA, Inc.

130
Note: The Navigation Accuracy Category for Position (NACP) is reported so that
surveillance applications may determine whether the reported geometric position
has an acceptable level of accuracy for the intended use. See 2.1.2.13 of the
ADS-B MASPS, RTCA DO-242A, for a fuller description of NACP.
Table 2-71: Navigation Accuracy Category for Position (NACP) Encoding

Coding 95% Horizontal and Vertical
Comment Notes
(Binary) (Decimal) Accuracy Bounds (EPU)
0000 0 EPU 18.52 km (10 NM) Unknown accuracy 1
0001 1 EPU < 18.52 km (10 NM) RNP-10 accuracy 1, 3
0100 4 EPU < 1852 m (1 NM) RNP-1 accuracy 1, 3
0101 5 EPU < 926 m (0.5 NM) RNP-0.5 accuracy 1, 3
0110 6 EPU < 555.6 m (0.3 NM) RNP-0.3 accuracy 1, 3
0111 7 EPU < 185.2 m (0.1 NM) RNP-0.1 accuracy 1, 3
1000 8 EPU < 92.6 m (0.05 NM) e.g., GPS (with SA on) 1
1001 9 EPU < 30 m e.g., GPS (SA off) 1, 2, 4
1010 10 EPU < 10 m e.g., WAAS 1, 2, 4
1011 11 EPU < 3 m e.g., LAAS 1, 2, 4
1100 12 Reserved
1101 13 Reserved
1110 14 Reserved
1111 15 Reserved
1. The Estimated Position Uncertainty (EPU) used in the table is a 95% accuracy
bound on horizontal position. EPU is defined as the radius of a circle, centered on
the reported position, such that the probability of the actual position lying outside the
circle is 0.05. When reported by a GPS or GNSS system, EPU is commonly called
HFOM (Horizontal Figure of Merit).
2. RNP accuracy includes error sources other than sensor error, whereas horizontal
error for NACP only refers to horizontal position error uncertainty.
2.2.3.2.7.2.8 Geometric Vertical Accuracy (GVA) Subfield in Aircraft Operational Status

Messages
The Geometric Vertical Accuracy (GVA) subfield of Subtype=0 Aircraft Operational
Status Message is a 2-bit field (ME bits 49-50, Message bits 81-82) defined in Table
2.2.3.2.7.2.8. The GVA field shall be set by using the Vertical Figure of Merit (VFOM)
(95%) from the GNSS position source used to encode the geometric altitude field in the
20xx, RTCA, Inc.

131
Table 2.2.3.2.7.2.8: Encoding of the Geometric Vertical Accuracy (GVA) Subfield in Aircraft
GVA Encoding Meaning
(decimal) (meters)
0 Unknown or > 45 meters
1 45 meters
2 Reserved
3 Reserved
Note: For the purposes of these MOPS (RTCA DO-260B) values for 0 and 1 are
encoded. Decoding values for 2 and 3 should be treated as < 45 meters until
future versions of these MOPS redefine the values.
2.2.3.2.7.2.9 Source Integrity Level (SIL) Subfield in Aircraft Operational Status Messages
position exceeding the radius of containment defined by the NIC, without alerting,
assuming no avionics faults. The SIL will address the Signal-in-Space, if applicable, and
will be the higher of the faulted or fault free probability of the Signal-In-Space causing
the NIC radius of containment to be exceeded.
no Signal-in-Space.
SIL Supplement (SILSUPP) in 2.2.3.2.7.1.3.1.
The SIL subfield shall be encoded in accordance with Table 2-72. For installations
where the SIL value is being dynamically updated, if an update has not been received
from an on-board data source for SIL within the past 5 seconds, then the SIL subfield
shall be encoded as a value of ZERO (0), indicating Unknown.
Note: The SIL and NIC should be set to unknown if the ADS-B position source does not
supply an output certified to provide an indication of the integrity of the reported
position (e.g., such as HPL from GNSS systems).
20xx, RTCA, Inc.

132
Table 2-72: SIL Subfield Encoding

SIL Coding Probability of Exceeding the NIC
(Binary) (Decimal) Containment Radius (RC)
Unknown or > 1 10-3
00 0
per flight hour or per sample
1 10-3
01 1
1 10-5
10 2
1 10-7
11 3
Notes:
1. The RTCA DO-242 definition of SIL has been updated in this version of these MOPS.
These updates will be incorporated in 2.1.2.15 of the ADS-B MASPS, RTCA DO-
242B.
2. Implementers should not arbitrarily set the SIL to ZERO (0) just because SIL is not
provided by the position source. Implementers should perform an off-line analysis of
the installed position source to determine the appropriate SIL.
2.2.3.2.7.2.10 Barometric Altitude Integrity Code (NICBARO) Subfield in Aircraft Operational

Status Messages
The NICBARO (Barometric Altitude Integrity Code) is a 1-bit subfield of Subtype 0
ADS-B Aircraft Operational Status Messages (ME bit 53, Message bit 85) that shall be
used to indicate whether or not the barometric pressure altitude being reported in the
Airborne Position Message (2.2.3.2.3) has been cross-checked against another source of
pressure altitude. The NICBARO subfield shall be encoded in accordance with Table 2-
73. If an update has not been received from an on-board data source for NICBARO within
the past 5 seconds, then the NICBARO subfield shall be encoded as a value of ZERO (0).
Table 2-73: NICBARO Subfield Encoding

Coding Meaning
The barometric altitude that is being reported in the
Airborne Position Message is based on a Gilham coded
0
input that has not been cross-checked against another source
of pressure altitude
Airborne Position Message is either based on a Gilham code
1 input that has been cross-checked against another source of
pressure altitude and verified as being consistent, or is based
on a non-Gilham coded source
Notes:
1. The NIC value itself is conveyed within the ADS-B Position Message.
20xx, RTCA, Inc.

133
2. The NICBARO subfield provides a method of indicating a level of data integrity for
aircraft installed with Gilham encoding barometric altitude sources. Because of the
potential of an undetected error when using a Gilham encoded altitude source, a
comparison will be performed with a second source and only if the two sources
agree will the NICBARO subfield be set to a value of ONE (1). For other barometric
altitude sources (Synchro or DADS) the integrity of the data is indicated with a
validity flag or SSM. No additional checks or comparisons are necessary. For these
sources the NICBARO subfield will be set to a value of ONE (1) whenever the
barometric altitude is valid.
3. The use of Gilham type altimeters is strongly discouraged because of the potential
for undetected altitude errors.
2.2.3.2.7.2.11 Aircraft/Vehicle Length and Width Code Subfield in Aircraft Operational Status
Messages
The Aircraft/Vehicle (A/V) Length and Width Code Subfield is a four-bit field (ME
bits 21 to 24, Message bits 53 to 56) of the Aircraft Operational Status Messages
(Subtype=1, for Surface Participants). This field shall describe the amount of space that
an aircraft or ground vehicle occupies. The A/V Length and Width Code is based on the
actual dimensions of the transmitting aircraft or surface vehicle as specified in Table 2-
74. Once the actual Length and Width of the A/V has been determined, each A/V shall
be assigned the smallest A/V Length and Width Code from Table 2-74 for which the
actual length is less than or equal to the upper bound length for that Length/Width Code,
and for which the actual width is less than or equal to the upper bound width for that
Length/Width Code.
Note: For example, consider a powered glider with overall length of 24 m and
wingspan of 50 m. Normally, an aircraft of that length would be in length
category 1 (that is, have a length code of 1). But since the wingspan exceeds 34
m, it does not qualify for even the wide subcategory (width code = 1) of length
category 1. Such an aircraft would be assigned length code = 4 and width code
= 1, meaning length less than 55 m and width less than 52 m.
20xx, RTCA, Inc.

134
Table 2-74: Aircraft/Vehicle Length and Width Code Encoding

Width Upper-Bound Length and Width
A/V - L/W Length Code
Code for Each Length/Width Code
Code
ME ME ME ME
Length Width
Bit Bit Bit Bit
(Decimal) (meters) (meters)
21 22 23 24
0 0 0 0 0 No Data or Unknown
1 0 0 0 1 15 23
2 0 28.5
0 0 1 25
3 1 34
4 0 33
0 1 0 35
5 1 38
6 0 39.5
0 1 1 45
7 1 45
8 0 45
1 0 0 55
9 1 52
10 0 59.5
1 0 1 65
11 1 67
12 0 72.5
1 1 0 75
13 1 80
14 0 80
1 1 1 85
15 1 90
If the Aircraft or Vehicle is longer than 85 meters, or wider than 90 meters, then decimal
Aircraft/Vehicle Length/Width Code 15 shall be used.
2.2.3.2.7.2.12 Track Angle/Heading Subfield in Aircraft Operational Status Messages

The Track Angle/Heading subfield is a 1-bit field (ME bit 53, Message bit 85) of the
ADS-B Aircraft Operational Status Message (Subtype=1, for Surface Participants) that
allows correct interpretation of the data contained in the Heading/Ground Track subfield
of the ADS-B Surface Position Message (2.2.3.2.4) when the Air/Ground status is
determined to be in the On-Ground state as defined in 2.2.3.2.1.2. The encoding of
the Track Angle/Heading subfield shall be as specified in Table 2-75.
Table 2-75: Track Angle/Heading Encoding

Coding Meaning
0 Track Angle
1 Heading
20xx, RTCA, Inc.

135
2.2.3.2.7.2.13 Horizontal Reference Direction (HRD) Subfield in Aircraft Operational Status

Messages
The Horizontal Reference Direction (HRD) subfield of the ADS-B Aircraft Operational
Status Messages is a 1-bit field (ME bit 54, message bit 86) that shall indicate the
reference direction (true north or magnetic north) for horizontal directions such as
heading, track angle. The Horizontal Reference Direction subfield shall be encoded as
Table 2-76: Horizontal Reference Direction (HRD) Encoding.

Coding Meaning
0 True North
1 Magnetic North
2.2.3.2.7.2.14 SIL Supplement Subfield in Aircraft Operational Status Messages

55, Message bit 87) field that shall define whether the reported SIL probability is based
on a per hour probability or a per sample probability as defined in 2.2.3.2.7.1.3.1,
with the encoding specified in Table 2-46.
2.2.3.2.7.2.15 Reserved Subfield in Aircraft Operational Status Message

There are two Reserved subfields in the Aircraft Operational Status Message. The first
is a 2-bit field (ME bits 49 and 50, Message bits 81 and 82) of the Aircraft Operational
Status Message (Subtype=1, for Surface Participants). The second Reserved subfield is
a 1-bit field (ME bit 56, Message bit 88) that shall be reserved for future applications.
2.2.3.2.7.3 TYPE Code 23 ADS-B Messages for TEST

TYPE 23 ADS-B Messages shall be used for Test Purposes. TEST Messages shall
be used exclusively for the broadcast of information in support of bench and/or
certification testing of 1090 MHz ADS-B systems, or for the broadcast of information of
interest only to local ADS-B ground applications. TEST Message broadcasts will not
result in an ADS-B report being generated onboard any other ADS-B equipped aircraft,
nor is the specific information being included in the TEST Message expected to be
generally codified within internationally accepted standards. TEST Messages
containing information of interest only to local ADS-B ground applications are intended
to be used in support of technical or operational evaluations, or in support of local
operational requirements.
These MOPS define only one category of use for the TEST Messages, Subtype=0.
TEST Messages of Subtypes 1 through 7 are reserved.
TEST Messages with Subtype=0 shall be used only for messages in support of bench
and/or certification testing of 1090 MHz ADS-B systems. The format for TEST
Messages with Subtype=0 shall be shown in Figure 2-12.
20xx, RTCA, Inc.

136
TEST Message (TYPE=23 and Subtype=0)

MSG
33 --------------- 37 38 ------------ 40 41 ----------------- 88
Bit #
ME
1 ----------------- 5 6 ------------- 8 9 ----------------- 56
Bit #
Field TYPE=23 Subtype=0 Unformatted Test Data
Name [5] [3] [48]
MSB MSB MSB
LSB LSB LSB
Figure 2-12: TEST Message with Subtype=0 Format
2.2.3.2.7.4 Surface System Status Messages with TYPE Code=24

The Surface System Status Message is used to provide the status of certain elements of
surface surveillance systems. The Surface System Status Message is intended to be used
only by the surface surveillance system that generated it and should be ignored by other
systems. The format of the Surface System Status Message shall be as specified in
Figure 2.2.3.2.7.4, while further definition of each of the subfields is provided in the
Surface System Status Message ME Field Format

Msg
33 --------------- 37 38 --------------- 40 41 ---------------- 88
Bit #
ME
1 --------------- 5 6 ---------------- 8 9 ---------------- 56
Bit #
Surface
Field TYPE = 24 SUBTYPE
System Status
Name [5] [3]
[48]
MSB MSB MSB
LSB LSB LSB
Figure 2.2.3.2.7.4: Surface System Status ADS-B Message ME Field Format
2.2.3.2.7.4.1 TYPE Code Subfield in Surface System Status Messages

in 2.2.3.2.3.1 and remains the same for the Surface System Status Message that uses
TYPE Code=24.
2.2.3.2.7.4.2 SUBTYPE Code Subfield in Surface System Status Messages

The SUBTYPE Code subfield is a 3-bit (ME bits 6 through 8, Message bits 38
through 40) subfield that shall be used to indicate the source of the Surface System Status
Message as specified in Table 2.2.3.2.7.4.2.
Table 2.2.3.2.7.4.2: "SUBTYPE" Subfield in Surface System Status Messages

SUBTYPE Code
Subfield Encoding Meaning
(decimal)
0 Reserved
1 Multilateration System Status (Allocated for national use)
20xx, RTCA, Inc.

137
27 Reserved
2.2.3.2.7.4.3 Surface System Status Subfield in Surface System Status Messages

The Surface System Status subfield is a 48 bit (ME bits 9 through 56, Message bits 41
through 88) subfield that may be defined by the system equipment manufacturer.
2.2.3.2.7.5 RESERVED TYPE Code 25 ADS-B Messages

ADS-B Messages with TYPE Code=25 shall be Reserved for future expansion.

ADS-B Messages with TYPE Code=26 shall be Reserved for future expansion.

ADS-B Messages with TYPE Code=27 are Reserved for future expansion of these MOPS
to specify Trajectory Change Message formats.
Note: While no messages supporting Trajectory Change (TC) Reports are defined in
this version of these MOPS, a possible approach to the broadcast of this
information is described in Appendix O, Accommodation of Trajectory Change
Reporting.
2.2.3.2.7.8 Extended Squitter Aircraft Status Messages with TYPE Code=28
2.2.3.2.7.8.1 Emergency / Priority Status and Mode A Code (Subtype=1)

The Extended Squitter Aircraft Status Message (TYPE Code=28) is used to provide
additional information regarding aircraft status. Subtype=1 is used specifically to
provide Emergency / Priority Status and the broadcast of the Mode A (4096) Code.
Specific formatting of the TYPE Code=28, Subtype=1 is specified in Figure 2-13 and in
Appendix A, Figure A-8.
20xx, RTCA, Inc.

138
1090ES Aircraft Status Message (Emergency/Priority Status) (TYPE=28, Subtype=1)

Msg
33 ----- 37 38 ------ 40 41 -------- 43 44 --------- 56 57 ----------- 88
Bit #
ME
1 ------- 5 6 -------- 8 9 --------- 11 12 --------- 24 25 ----------- 56
Bit #
Emergency/
Field TYPE=28 Subtype=1 Mode A Code Reserved
Priority Status
Name [5] [3] [13] [45]
[3]
MSB LSB MSB LSB MSB LSB MSB LSB MSB LSB
Figure 2-13: 1090ES Aircraft Status Message (Emergency/Priority Status)

(TYPE=28, Subtype=1)
2.2.3.2.7.8.1.1 Emergency/Priority Status Subfield in Aircraft Status Messages

The Emergency/Priority Status subfield in the Extended Squitter Aircraft Status
Message shall be encoded in accordance with Table 2.2.3.2.7.8.1.1.
Table 2.2.3.2.7.8.1.1: Emergency/Priority Status Subfield Encoding

Coding
Meaning
(Binary) (Decimal)
000 0 No Emergency
001 1 General Emergency
010 2 Lifeguard/medical Emergency
011 3 Minimum Fuel
100 4 No Communications
101 5 Unlawful Interference
110 6 Downed Aircraft
111 7 Reserved
a. If the pilot enters a Mode A Code of 7500, the Emergency/Priority Status subfield
shall be encoded with a value of decimal 5 indicating Unlawful Interference.
b. If the pilot enters a Mode A Code of 7600, the Emergency/Priority Status subfield
shall be encoded with a value of decimal 4 indicating No Communications.
c. If the pilot enters a Mode A Code of 7700, the Emergency/Priority Status subfield
shall be encoded with a value of decimal 1 indicating General Emergency.
d. The emergency condition initiated by the pilot entry of Mode A Code 7500, 7600 or
7700 shall be terminated when the pilot changes to any other Mode A Code.
Note: The Surveillance Status subfield value of ONE corresponds to the

emergency condition activated by Mode A Code 7500, 7600 or 7700 and the
change from the value of ONE signals the termination of the emergency
condition (see 2.2.3.2.3.2).
e. If an update has not been received from an on-board data source for the
Emergency/Priority Status within the past 5 seconds, then the Emergency/Priority
Status subfield in the Aircraft Status Message shall be encoded with a value of
ZERO (binary 000) indicating No Emergency.
20xx, RTCA, Inc.

139
Note: The encoding of the Emergency/Priority Status subfield values 2, 3 and 6 do

not have a corresponding Mode A Code value that denotes the emergency
condition. The establishment of these emergency conditions by providing a pilot
interface to activate them is optional in this version of these MOPS.
2.2.3.2.7.8.1.2 Mode A (4096) Code Subfield in Aircraft Status Messages

a. The Mode A (4096) Code subfield in the Aircraft Status Message shall be encoded as
defined in RTCA DO-181D, 2.2.4.1.2 and 2.2.13.1.2.b (EUROCAE ED-73C,
3.5.2 and 3.5.6.b).
b. Starting with ME bit 12, the code sequence shall be C1, A1, C2, A2, C4, A4,
ZERO, B1, D1, B2, D2, B4, D4.
Note: The broadcast of the Mode A (4096) Code in the Aircraft Status Message with
Subtype=1 is provided as a transitional feature to aid operation of ATC
automation systems that use Mode A Code for Flight Plan correlation.
Provisions are included in these MOPS to disable the broadcast of the Mode A
Code. The requirement for the broadcast of the Mode A Code may be removed
from future versions of these MOPS.
The Mode A (4096) Code of 3000, disables the broadcast of the Mode A (4096) Code
as specified in 2.2.3.3.1.4.3.1.
2.2.3.2.7.8.2 1090ES TCAS Resolution Advisory (RA) Broadcast Message (Subtype=2)

The Extended Squitter Aircraft Status Message (TYPE 28) is also used to provide
additional information regarding the TCAS Resolution Advisory (RA). Subtype=2 is
used specifically to provide the encoding of this information as specified in Figure 2-14.
The content of the fields of the 1090ES TCAS RA Message conform to the
corresponding bits of transponder Register 3016, and are specified in ICAO Annex 10,
Vol IV, 4.3.8.4.2.2.1.
1090ES Aircraft Status Message (TCAS RA Broadcast Message) (TYPE=28, Subtype=2)

Msg
33 ------37 38 ----- 40 41 ----- 54 55 ----- 58 59 60 61 ----- 62 63 ---- 88
Bit #
ME
1 ------- 5 6 ------ 8 9 ------- 22 23 ----- 26 27 28 29 ----- 30 31 ---- 56
Bit #
Active Multiple Threat Threat
RA
Resolution RACs Threat Type Identity
Field TYPE=28 Subtype=2 Terminated
Advisories Record Encounter Indicator Data
Name [5] [3] (RAT)
(ARA) [4] (MTE) (TTI) (TID)
[1]
[14] [1] [2] [26]
MSB LSB MSB LSB MSB LSB MSB LSB MSB LSB MSB LSB
Note: [#] provided in a field indicates the number of bits in that field.
Figure 2-14: 1090ES Aircraft Status Message (TCAS RA Broadcast Message)

(TYPE=28, Subtype 2)
20xx, RTCA, Inc.

140
a. The transmission of the Aircraft Status Message with Subtype=2 shall begin within
0.5 seconds after the transponder notification of the initiation of a TCAS Resolution
Advisory.
b. The transmission of the Aircraft Status Message with Subtype=2 shall be terminated
24 1 seconds after the Resolution Advisory Termination (RAT) flag transitions from
ZERO (0) to ONE (1).
c. Aircraft Status Messages with Subtype=2 shall have priority over Aircraft Status
Messages with Subtype=1, and over all other Event-Driven Messages.

ADS-B Messages with TYPE Code=30 are Reserved for future expansion.
Note: The first version of these MOPS (RTCA DO-260) specified TYPE 30 for use in
support of Operational Coordination Messages. The Operational Coordination
Messages are no longer required and future editions of these MOPS may specify
a different use for TYPE 30 Messages.
2.2.3.3 ADS-B Message Transmission Rates
2.2.3.3.1 Transmission Rates for Transponder - Based Transmitters
2.2.3.3.1.1 Transmission Rates Compliant with RTCA DO-181D (EUROCAE ED-73C)

ADS-B transmitters based on Mode S transponders shall comply with the Message
Transmit Rates specified in RTCA DO-181D (EUROCAE ED-73C), for each class of
transponder defined in the latest version of FAA TSO-C112.
Note: The requirements of RTCA DO-181D (EUROCAE ED-73C) are consistent with
the requirements of ICAO Annex 10, Volume IV, fourth edition, July 2007,
3.1.2.8.6.4.
2.2.3.3.1.2 Transmission Rates Not Specified in RTCA DO-181D (EUROCAE ED-73C)

When the transmission rate of a particular message type is not specified in RTCA DO-
181D (EUROCAE ED-73C), then the Mode S Transponder-Based ADS-B transmitters
shall deliver those messages at the rates specified in the following subparagraphs for
Stand Alone Transmitters. If there is conflict between the requirements of RTCA DO-
181D (EUROCAE ED-73C) and this document, then the requirements of RTCA DO-
181D (EUROCAE ED-73C) shall be adhered to.
Note: The possible transmission time epochs should not be correlated with UTC to
preclude inadvertent synchronization of transmissions from different aircraft.
Table 2-77 summarizes the broadcast rates of the 1090ES ADS-B Messages specified in
these MOPS (RTCA DO-260B).
20xx, RTCA, Inc.

141
20xx, RTCA, Inc.

142
Table 2-77: 1090 MHz Extended Squitter ADS-B Message Broadcast Rates
Broadcast Rate
Transponder Event-Driven On-the-Ground, On-the-Ground
1090ES ADS-B Message Airborne
Register Message Priority not moving and moving
2 / 1 second
BDS 0,5 N/A Airborne Position N/A N/A
(0.4 0.6 sec)
LOW RATE HIGH RATE
BDS 0,6 N/A Surface Position 1 / 5 seconds 2 / 1 second N/A
(4.8 5.2 sec) (0.4 0.6 sec)
LOW RATE HIGH RATE HIGH RATE
BDS 0,8 N/A Aircraft Identification and Category 1 / 10 seconds 1 / 5 seconds 1 / 5 seconds
(9.8 10.2 sec) (4.8 5.2 sec) (4.8 5.2 sec)
2 / 1 second
BDS 0,9 N/A Airborne Velocity N/A N/A
(0.4 0.6 sec)
TCAS RA or Mode A Code Change
Aircraft Status
TCAS RA = 1 0.7 0.9 seconds
BDS 6,1 (Emergency/Priority Status, Subtype=1)
Emergency = 2 No TCAS RA, No Mode A Change
(TCAS RA Broadcast, Subtype=2)
4.8 5.2 seconds
BDS 6,2 N/A Target State and Status (TSS) N/A N/A 1.2 1.3 seconds
No change TSS being broadcast or not
NICSUPP/NAC/SIL No change TCAS/NAC/SIL
2.4 2.6 seconds 2.4 2.6 seconds
TSS being broadcast
BDS 6,5 N/A Aircraft Operational Status 4.8 5.2 seconds Change in TCAS/NAC/SIL
Change in 2.4 2.6 seconds
NICSUPP/NAC/SIL
TSS not broadcast 2
0.7 0.9 seconds
Change in TCAS/NAC/SIL
0.7 0.9 seconds
N/A = Not Applicable
Notes:
1. Transmitters are limited to no more than 2 Event Driven messages per second. Therefore, the average of 2 Airborne Position, 2 Airborne Velocity, 0.2
Identification, and 2 Periodic Status and Event Driven messages per second, averaged over any 60 second interval, yields the required 6.2 messages per second.
2. Not all aircraft broadcast the Target State and Status Message (see Table 2-3).
20xx, RTCA, Inc.

143
2.2.3.3.1.3 Maximum Transmission Rates for Transponder - Based Transmitters

The maximum ADS-B Message transmission rate shall not exceed 6.2 transmitted
messages per second averaged over any 60 second interval, distributed as required by
RTCA DO-181D, 2.2.23.1.3 (ED-73C, 3.28.3).
Note: Transponders are limited to no more than 2 Event Driven messages per second.
Therefore, the average of 2 Airborne Position, 2 Airborne Velocity, 0.2
Identification, and 2 Periodic Status and Event Driven messages per second,
averaged over any 60 second interval, yields the required 6.2 messages per
second.
2.2.3.3.1.4 ADS-B Periodic Status and Event-Driven Message Broadcast Rates
2.2.3.3.1.4.1 ADS-B Target State and Status Message Broadcast Rates

a. The Target State and Status Message(s) (TYPE=29, 2.2.3.2.7.1) shall be initiated
only when the aircraft is airborne and when vertical or horizontal target state
information is available and valid as a minimum.
b. The Target State and Status Message with a Subtype value of ZERO (0) shall, for the
nominal case, be broadcast at random intervals that are uniformly distributed over the
range of 1.2 to 1.3 seconds relative to the previous Target State and Status for as long
as data is available to satisfy the requirements of subparagraph a. above.
c. The broadcast rates for Target State and Status Messages with a Subtype subfield
value of other than ZERO (0) are not defined by this version of these MOPS.
Notes:
1. Future versions of these MOPS may require unique broadcast update intervals
for each Target State and Status Message Subtype (i.e., unique for each value of
the Subtype subfield).
2. Future versions of these MOPS may require that the broadcast rate for Target
State and Status Messages be temporarily increased (e.g., for 24 seconds)
following any change in target state or system status information.
2.2.3.3.1.4.2 ADS-B Aircraft Operational Status Message Broadcast Rates

The rate at which the ADS-B Aircraft Operational Status Messages (TYPE=31 and
Subtype=0, 2.2.3.2.7.2) are broadcast shall vary depending on the following conditions:
Condition 1: Target State and Status Message (2.2.3.2.7.1) for Target State and
Status Information (i.e., TYPE=29 and Subtype=1) is not being
broadcast versus being broadcast.
20xx, RTCA, Inc.

144
Condition 2: There has been a change within the past 24 seconds in the value of one or
more of the following parameters included in the Operational Status
Message:
a. TCAS/ACAS Operational
b. ACAS/TCAS resolution advisory active
c. NACp
d. SIL
a. For the two cases where:
i. The Target State and Status Message (2.2.3.2.7.1) with Subtype=1 is not being
broadcast and Condition 2 above is not applicable (nominal condition); or
ii. The Target State and Status Message with Subtype=1 is being broadcast
regardless of the applicability of Condition 2 above;
The Aircraft Operational Status Message shall be broadcast at random intervals

uniformly distributed over the range of 2.4 to 2.6 seconds.
b. For the case where the Target State and Status Message (2.2.3.2.7.1) with
Subtype=1 is not being broadcast and Condition 2 above is applicable, the Aircraft
Operational Status Message broadcast rate shall be increased for a period of 24
seconds (1 second) such that the broadcasts occur at random intervals that are
c. While the A/V is determined to be in the On-Ground condition, and Condition 2

above IS NOT applicable, then the ADS-B Aircraft Operational Status Message
(TYPE=31 and Subtype=1, for surface participants, 2.2.3.2.7.2) shall be broadcast
at random intervals that are uniformly distributed over the range of 2.4 to 2.6
seconds.
d. While the A/V is determined to be in the On-Ground condition, and Condition 2

above IS applicable, then the broadcast rate of the ADS-B Aircraft Operational Status
Message (TYPE=31 and Subtype=1, for surface participants, 2.2.3.2.7.2) shall be
increased for a period of 24 seconds (1 second) such that the broadcasts occur at
random intervals that are uniformly distributed over the range of 0.7 to 0.9 seconds.
2.2.3.3.1.4.3 Extended Squitter Aircraft Status ADS-B Event-Driven Message Broadcast Rates
2.2.3.3.1.4.3.1 Emergency/Priority Status Message Broadcast Rates

The Emergency/Priority Status Message (TYPE=28, Subtype=1), (see 2.2.3.2.7.8)
shall be broadcast using the EventDriven protocol. The rate of transmission varies
depending on other conditions. If the transmission of the Mode A Code is disabled, the
transmission of the Emergency/Priority Status Message occurs only when an
emergency condition is active. When the transmission of the Mode A Code is enabled,
the transmission rate of the Emergency/Priority Status Message depends on whether
the Mode A Code is changed, or if an emergency condition is active.
20xx, RTCA, Inc.

145
When the Mode A Code is set to 3000, the 1090ES Transmitting Subsystem shall
disable the transmission of the Mode A Code and broadcast the Emergency/Priority
Message in accordance with 2.2.3.3.1.4.3.1.1 only when an emergency is declared.
Otherwise, the Mode A Code transmission is enabled and the broadcast rates of
2.2.3.3.1.4.3.1.2 apply.
Note: The use of Mode A Code 3000 for this purpose is in accordance with the ICAO
Doc 9871 provision to disable the transmission of the Mode A Code on 1090ES.
This will occur at such time that the ATC systems no longer depend on the Mode
A Code to identify aircraft.
2.2.3.3.1.4.3.1.1 Emergency/Priority Status Message Broadcast Rates When Transmission of

Mode A Code is Disabled
When the Mode A Code transmission is disabled as per 2.2.3.3.1.4.3.1, the following
transmit rates apply:
a. The Emergency/Priority Status Message (TYPE=28, Subtype=1) shall be

broadcast at random intervals that are uniformly distributed over the range of 0.7 to
0.9 seconds relative to the previous Emergency/Priority Status for the duration of
the emergency condition which is established by any value other than ZERO in the
Emergency/Priority Status subfield in accordance with (2.2.3.2.7.8.1.1).
b. In the case where there is no emergency condition established by a ZERO value in

the Emergency/Priority Status subfield, then the Emergency/Priority Status
Message shall not be broadcast.
2.2.3.3.1.4.3.1.2 Emergency/Priority Status Message Broadcast Rates When Transmission of

Mode A Code is Enabled
When the Mode A Code transmission is enabled as per 2.2.3.3.1.4.3.1, the following
a. The Emergency/Priority Status (TYPE=28, Subtype=1) shall be broadcast at

random intervals that are uniformly distributed over the range of 0.7 to 0.9 seconds
relative to the previous Emergency / Priority Status under the following conditions:
i. For a duration of 24 1 seconds following a Mode A Code change by the pilot

except if the Mode A Code is changed to 7500, 7600 or 7700.
Note: The case where the Mode A Code is set to 7500, 7600 or 7700, the
transmission of the emergency condition is covered by ii. below. Setting
the Mode A Code to 7500, 7600 or 7700 is indicated by a Permanent
Alert in the Surveillance Status field (value of 1) (see 2.2.3.2.3.2). A
change in the Mode A Code, except to 7500, 7600 or 7700, is indicated
by a Temporary Alert in the Surveillance Status subfield (value of 2)
(see 2.2.3.2.3.2).
20xx, RTCA, Inc.

146
ii. For the duration of an emergency condition by any non-ZERO value in the
Emergency/Priority Status subfield in accordance with (2.2.3.2.7.8.1.1), if the
emergency code is cleared by the pilot changing the Mode A Code to other than
7500, 7600 or 7700, the broadcast of the Emergency/Priority Status Message
shall be continued for 24 1 seconds as i above.
b. In the absence of conditions specified in a above, the Emergency/Priority Status

Message shall be broadcast at random intervals that are uniformly distributed over
the range of 4.8 to 5.2 seconds relative to the previous Emergency / Priority Status
Message.
2.2.3.3.1.4.3.2 TCAS RA Broadcast Message Broadcast Rate

A TCAS RA Broadcast (TYPE=28, Subtype=2), shall be broadcast at random intervals
that are uniformly distributed over the range of 0.7 to 0.9 seconds relative to the previous
TCAS RA Broadcast Message for the duration of the TCAS RA in accordance with
2.2.3.2.7.8.2.
2.2.3.3.1.4.4 TYPE Code=23 (TEST) ADS-B Event-Driven Message Broadcast Rate

The following broadcast rate requirements shall apply only under the condition that
TEST Messages of the Subtype indicated are authorized to be transmitted.
The TEST ADS-B Event-Driven Messages with Subtype=0 shall be broadcast NOT
MORE THAN ONCE each time the Event-Driven Test Information is updated to the
transponder.
2.2.3.3.1.4.5 TYPE Codes 24 27 and TYPE Code=30 ADS-B Event-Driven Message

Broadcast Rate
In general, TYPE Codes 24 - 27 ADS-B Event-Driven Messages shall be broadcast
ONCE each time the Event-Driven TYPE Code 24 - 27 information is updated to the
transponder.
2.2.3.3.1.4.6 ADS-B Message Transmission Scheduling

An ADS-B Message scheduling function shall be used to determine the sequence of
ADS-B Messages to be broadcast and to control the overall transmission rate of Event-
Driven messages.
20xx, RTCA, Inc.

147
2.2.3.3.1.4.6.1 Event-Driven Message Scheduling Function

Note: This version of these MOPS does not define the message format for the broadcast
of Trajectory Change information (2.2.3.2.7.7). However it is anticipated that
future versions of these MOPS will require the broadcast of Trajectory Change
information for all Class A2 and Class A3 airborne systems and will be optional
for Class A1S and A1 airborne systems. The following requirements for the
Event-Driven Message Scheduling Function include provisions to accommodate
the future addition of messages conveying Trajectory Change information (i.e.,
message TYPE=27).
The Event-Driven Message Scheduling Function shall ensure that the total Event-Driven
message rate does not exceed 2 transmitted messages per second. This is consistent with
the required overall maximum allowed transmission rate specified in 2.2.3.3.1.3.
The Event-Driven Message Scheduling Function shall apply the following rules as a
means of prioritizing the Event-Driven Message transmissions and limiting the
transmission rates:
a. The Event-Driven Message scheduling function shall reorder, as necessary, pending

Event-Driven Messages according to the following message priorities, listed below
(and in Table 2-145) in descending order from highest to lowest priority:
i. The broadcast of the Extended Squitter Aircraft Status Message (2.2.3.2.7.8.1)

TCAS RA Broadcast (TYPE=28, Subtype=2).
ii. The broadcast of the Extended Squitter Aircraft Status Message (2.2.3.2.7.8.2)
Emergency/Priority Condition (TYPE=28, Subtype=1).
iii. This priority level applies as a default to any Event-Driven Message TYPE and
Subtype combination not specifically identified at a higher priority level above.
Event-Driven Messages of this default priority level shall be delivered to the
transponder on a first-in-first-out basis at equal priority.
b. The Event-Driven Message scheduling function shall limit the number of Event-
Driven Messages provided to the transponder to two (2) messages per second.
Note: It is possible that future versions of these MOPS, requiring a complementary

change to the Mode S transponder MOPS, will allow for Event-Driven Messages
to be transmitted at a rate of greater than the current limit of two (2) messages
per second. Therefore, a means should be provided to allow for a future
adjustment to the value used for the message rate limit in the Event-Driven
Message scheduling function.
c. If (b) results in a queue of messages awaiting delivery to the transponder, the higher
priority pending messages, according to (a) above shall be delivered to the
transponder for transmission before lower priority messages.
d. If (b) results in a queue of messages awaiting delivery to the transponder, new Event-
Driven messages shall directly replace older messages of the same exact TYPE and
Subtype (where a Subtype is defined) that are already in the pending message queue.
20xx, RTCA, Inc.

148
The updated message shall maintain the same position in the message queue as the
pending message that is being replaced.
e. If (b) above results in a queue of messages awaiting delivery to the transponder, then
pending message(s), shall be deleted from the message transmission queue if not
delivered to the transponder for transmission, or not replaced with a newer message
of the same message TYPE and Subtype, within the Message Lifetime value
specified in the Table 2-78 below:
Table 2-78: Event-Driven Message Lifetime

Message Message Message Lifetime
TYPE Subtype (seconds)
=0 5.0 seconds (0.2 sec.)
23
=1-7 Reserved (see Note)
24 Reserved (see Note)
=1 5.0 seconds (0.2 sec.)
10 seconds after RAT
28 =2
transitions from 0 to 1
0, > 2 Reserved (see Note)
Note: A default message lifetime of 20 seconds will be used for queue management
unless otherwise specified.
2.2.3.3.2 Transmission Rates for Stand Alone Transmitters

a. Stand Alone Transmitters for Class A0 and Class B0 equipment are those
implemented independent of a Mode S transponder. Such transmitters shall meet the
transmission rate requirements of 2.2.3.3.1.3 and the message update rate
requirements specified in the following subparagraphs.
b. Extended Squitter messages shall be transmitted at random intervals that are

uniformly distributed over the specified time interval using a time quantization no
greater than 15 milliseconds.
Note: The possible transmission time epochs should not be correlated with UTC to
preclude inadvertent synchronization of transmissions from different aircraft.
2.2.3.3.2.1 Power-On Initialization and Start Up
2.2.3.3.2.1.1 Power-On Initialization

a. At power-up initialization, the ADS-B Transmitting Subsystem shall start operations
in a mode in which it transmits NO messages.
b. Given that appropriate message data is provided to the ADS-B Transmitting

Subsystem, the transmission device shall be capable of transmitting ADS-B
Messages no later than 2.0 seconds after Power-On.
20xx, RTCA, Inc.

149
c. After a power-up initialization exceeding the momentary power interruption

capability of the equipment, the total set of BITE tests that check all necessary
functions of the ADS-B device shall be completed within 20 seconds. As a
minimum, the BITE tests shall include RAM, ROM, I/O, Timing, CPU instruction
integrity, and any associated RF hardware tests necessary to ensure proper
functioning of the ADS-B device.
2.2.3.3.2.1.2 Start Up
a. The ADS-B Transmitting Subsystem shall initiate broadcast transmissions of the
Airborne Position, Surface Position, Aircraft Identification and Category, Velocity,
Target State and Status, and/or Aircraft Operational Status Messages only when it has
received appropriate data to structure at least one variable data field of the respective
message. As such, each message shall be initiated individually and independently of
the other messages.
The single exception is presented by Altitude data in the Airborne Position Message
which shall be processed as follows:
The ADS-B Transmitting Subsystem shall not initiate broadcast of the Airborne
Position Message until horizontal position data has been received. That is, that
altitude data alone shall not be sufficient to initiate broadcast of the Airborne
Position Message.
b. Once ADS-B Message transmission has been initiated the transmission rate of each
type of ADS-B Message shall be as provided in the following paragraphs.
2.2.3.3.2.2 ADS-B Airborne Position Message Broadcast Rate

Once started, ADS-B Airborne Position Messages shall be broadcast by the transmission
device when in the Airborne state at random intervals that are uniformly distributed over
the range of 0.4 to 0.6 seconds relative to the previous Airborne Position Message, with
the exceptions as specified in 2.2.3.3.2.9.
2.2.3.3.2.3 ADS-B Surface Position Message Broadcast Rate

a. Once started, ADS-B Surface Position Messages shall be broadcast by the
transmission device when in the On-Ground state using either the High or Low
rate, which has been selected as follows:
(1). Switching from High rate to Low Rate:
(a). The broadcast rate shall be changed from High to Low when the
navigation source position data has not changed more than 10 meters in any
30 second interval.
Note: It is acceptable to compute the 10 meter distance using either

rectangular or polar coordinates.
(b). Upon selecting the Low rate, the transmission device shall save the
Position data at the time that the Low rate was selected.
20xx, RTCA, Inc.
150
(2). Switching from Low rate to High Rate:
The broadcast rate shall be changed from Low to High when the position of
the transmission device has changed by 10 meters or more since the Low rate
was selected.
Note: It is acceptable to compute the 10 meter distance using either

rectangular or polar coordinates.
b. If the High rate is selected, then the Surface Position Message shall be transmitted
at random intervals that are uniformly distributed over the range of 0.4 to 0.6 seconds
relative to the previous Surface Position Message.
c. If the Low rate is selected, then the Surface Position Messages shall be transmitted
relative to the previous Surface Position Message.
d. If the transmission device loses its navigation source, the High rate shall be used as
the default transmission rate.
e. Exceptions to these transmission rate requirements are specified in 2.2.3.3.2.9.
2.2.3.3.2.4 ADS-B Aircraft Identification and Category Message Broadcast Rate

a. Once started, ADS-B Aircraft Identification and Category Messages shall be
broadcast by the transmission device at random intervals that are uniformly
distributed over the range of 4.8 to 5.2 seconds relative to the previous Identification
and Category Message, when the ADS-B Transmitting Subsystem is reporting the
Airborne Position Message, or when reporting the Surface Position Message at the
high rate.
b. When the Surface Position Message is being reported at the low surface rate, then the
Aircraft Identification and Category Message shall be broadcast at random intervals
that are uniformly distributed over the range of 9.8 to 10.2 seconds relative to the
previous Aircraft Identification and Category Message.
c. When neither the Airborne Position Message nor the Surface Position Message is
being transmitted, then the Aircraft Identification and Category Message shall be
broadcast at the rate specified in subparagraph a.
d. Exceptions to these transmission rate requirements are specified in 2.2.3.3.2.9.
2.2.3.3.2.5 ADS-B Velocity Information Message Broadcast Rate

a. Once started, ADS-B Velocity Information Messages shall be broadcast by the
transmission device at random intervals that are uniformly distributed over the range
of 0.4 to 0.6 seconds relative to the previous Velocity Information Message.
b. Exceptions to these transmission rate requirements are specified in 2.2.3.3.2.9.
20xx, RTCA, Inc.

151
2.2.3.3.2.6 ADS-B Periodic Status Message Broadcast Rates
2.2.3.3.2.6.1 ADS-B Target State and Status Message Broadcast Rates

a. The requirements of 2.2.3.3.1.4.1 are applicable.
b. The Target State and Status Message (TYPE=29, Subtype=0, 2.2.3.2.7.1) shall be
broadcast at random intervals that are uniformly distributed over the range of 1.2 to
1.3 seconds relative to the previous Target State and Status Message for as long as
data is available to satisfy the requirements of subparagraph a. above.
c. Exceptions to these transmission rate requirements shall be as specified in

2.2.3.3.2.9.
2.2.3.3.2.6.2 ADS-B Aircraft Operational Status Message Broadcast Rates

a. The Aircraft Operational Status Message (TYPE=31 and Subtype=0 and 1)
(2.2.3.2.7.2) shall be broadcast at the rates as specified in 2.2.3.3.1.4.2.
b. Exceptions to these transmission rate requirements shall be as defined in 2.2.3.3.2.9.
2.2.3.3.2.6.3 Extended Squitter Aircraft Status ADS-B Event-Driven Message Broadcast Rate
a. The rate at which the Extended Squitter Aircraft Status (TYPE=28), ADS-B Event-
Driven Message (see 2.2.3.2.7.8) shall be broadcast varies as defined in
2.2.3.3.1.4.3.
b. The exceptional conditions specified in 2.2.3.3.2.9 shall be observed.
2.2.3.3.2.7 TYPE Code=23 (TEST) ADS-B Event-Driven Message Broadcast Rate

The TEST Message with Subtype=0 ADS-B Event-Driven Messages shall be
broadcast NOT MORE Than ONCE each time the Event-Driven Test Information is
updated to the ADS-B Transmitting Subsystem. The delay conditions specified in
2.2.3.3.2.9 shall be observed.
2.2.3.3.2.8 TYPE Codes 24 - 27 ADS-B Event-Driven Message Broadcast Rate

In general, TYPE Code 24 - 27 ADS-B Event-Driven Messages shall be broadcast
ONCE each time the Event-Driven TYPE Code 24 - 27 information is updated to the
ADS-B Transmitting Subsystem. The delay conditions specified in 2.2.3.3.2.9 shall be
observed.
2.2.3.3.2.9 ADS-B Message Transmission Scheduling

a. An ADS-B Message scheduling function shall be used to determine the sequence of
ADS-B Messages to be broadcast and to control the overall transmission rate of
Event-Driven messages.
20xx, RTCA, Inc.

152
b. As an exception to the general requirement for the transmission of ADS-B Messages,

the scheduled message transmission shall be delayed if a Mutual Suppression
interface is active.
2.2.3.3.2.9.1 Position, Velocity and Identification Message Scheduling

The priority for transmission (from highest to lowest) for the message types that are not
event-driven shall be:
a. Position Message (either Airborne Position Message, as specified in 2.2.3.2.3,

or Surface Position Message, as defined in 2.2.3.2.4)
b. Airborne Velocity Message (2.2.3.2.6)
c. Aircraft Identification and Category Message (2.2.3.2.5)
2.2.3.3.2.9.2 Event-Driven Message Scheduling

An Event-Driven Message Scheduling function shall:
a. Ensure that the total Event-Driven Message rate does not exceed 2 transmitted
messages per second. This is consistent with the required overall maximum
allowed transmission rate specified in 2.2.3.3.2.10.
Note: It is possible that future versions of these MOPS may allow for Event-
Driven messages to be transmitted at a rate of greater than the current
limit of two (2) messages per second. Therefore a means should be
provided to allow for a future adjustment to the value used for the
message rate limit in the Event-Driven Message scheduling function.
b. The Event-Driven Message scheduling requirements of 2.2.3.3.1.4.6.1 shall be

used as the means of ensuring the Event-Driven message broadcast limit of 2
messages per second is not exceeded.
2.2.3.3.2.10 Maximum ADS-B Message Transmission Rates

The maximum ADS-B Message transmission rate of non-transponder ADS-B Transmitter
implementations shall not exceed 6.2 transmitted messages per second, averaged over
any 60 second interval.
Note: It is possible that future versions of these MOPS may allow for ADS-B Messages
to be transmitted at a rate of greater than the current limit of 6.2 messages per
second. Therefore a means should be provided to allow for a future adjustment
to the value used for the message rate limit in the message scheduling function.
2.2.3.3.2.11 ADS-B Message Timeout

Notes:
1. These messages are cleared to prevent the reporting of outdated position and velocity
information.
20xx, RTCA, Inc.

153
2. During a register timeout event, the ME field of the ADS-B Broadcast Message
may contain ALL ZEROs, except for those fields that may be updated due to the
receipt of new data.
a. The ADS-B Transmitting Subsystem shall clear all but the altitude and surveillance
status subfields of the Airborne Position Message, if no new position data is received
within two (2) seconds of the previous input data update.
Note: During a timeout event the Format TYPE Code is set to ZERO (see
2.2.3.2.3.1.3.1).
b. The ADS-B Transmitting Subsystem shall clear all 56-bits of the Surface Position
Message if no new position data is received within two (2) seconds of the previous
input data update.
Notes:
1. During a timeout event the Format TYPE Code is set to ZERO (see
2.2.3.2.4.1.3.1).
2. When position is available, the ADS-B Transmitting Subsystem manages the

movement and the ground track subfields such that the subfields and applicable
status bits are set to ZERO (0) if no new data is received for the subfield within
2.6 seconds of the last data update of the subfield.
3. When position data is not received, all bits of the Surface Position Message are
set to ZERO to avoid confusion with altitude data in the Airborne Position
Message sent with TYPE Code ZERO (0).
c. The ADS-B Transmitting Subsystem shall clear all 56-bits of the Airborne Velocity
Message if no data is received within 2.6 seconds of the previous input data update.
Note: The Intent Change information is not sufficient to consider that new data has
been received (2.2.3.2.6.1.3).
d. The ADS-B Transmitting Subsystem shall not clear the Aircraft Identification
Message (see 2.2.3.2.5).
Note: The Aircraft Identification Message, is not cleared since it contains data that
rarely changes in flight and is not frequently updated.
e. The ADS-B Transmitting Subsystem shall clear each of the Selected Altitude,
Selected Heading, or Barometric Pressure Setting subfields of the Target State and
Status Message (see 2.2.3.2.7.1) if no new data is received within 2.0 seconds of the
previous input data update for the respective subfield. Each of the subfields shall be
cleared independently of the other subfields. That is, each of the three specified
subfields shall be processed mutually exclusively of the other two specified
subfields. The remaining subfields of the Target State and Status Message shall not
be cleared, as they contain other integrity, mode, or status information.
20xx, RTCA, Inc.

154
f. The ADS-B Transmitting Subsystem shall not clear the Operational Status Messages
(see 2.2.3.2.7.2) since the subfields of the Message contain various integrity, mode,
or status information..
g. The ADS-B Transmitting Subsystem shall not clear the Event-Driven Messages (see
2.2.3.2.7.8).
Note: The Event-Driven Messages do not need to be cleared since contents of such
messages are only broadcast once each time that new data is received.
2.2.3.3.2.12 ADS-B Message Termination

a. The ADS-B Transmitting Subsystem shall terminate broadcast transmissions of the
Airborne Position Message when position (latitude/longitude) and altitude data are
not available for a period of 60 seconds.
Note: For the Airborne Position Message, altitude data alone is sufficient to
maintain broadcast of the Message once the Message has been initiated.
When only altitude data is available, the Airborne Position Message
continues to be transmitted even after 60 seconds. However, if the altitude
data is not available for 60 seconds, then the Airborne Position Message
transmission is terminated and the conditions for start-up defined in
2.2.3.3.2.1.2 are necessary to resume the transmission of Airborne Position
Message.
b. The ADS-B Transmitting Subsystem shall terminate the transmission of Surface

Position Messages if position data that is necessary to update the Message is not
available for a period of 60 seconds. Transmission termination of Surface Position
Messages does not apply to Non-Transponder Devices on aircraft that are on the
surface, or on surface vehicles.
20xx, RTCA, Inc.

155
Note: For the Surface Position Message, the receipt of new Movement, or Ground
Track data is not sufficient to maintain broadcast of the message once the
message has been initiated.
c. The ADS-B Transmitting Subsystem shall not terminate broadcast transmissions of

Aircraft Identification and Category Message even if input data necessary to update
the Message is not available.
d. The ADS-B Transmitting Subsystem shall terminate broadcast transmissions of the

Airborne Velocity Message if input data necessary to update the subfields of the
Airborne Velocity Message, other than the Intent Change Flag, is not available for a
period of 2.6 seconds.
Notes:
1. The receipt of new data necessary to update any single subfield, other than the
Intent Change Flag, is sufficient to maintain broadcast of the Airborne Velocity
Message.
2. Previous versions of these MOPS required the Airborne Velocity Message to be

transmitted for an additional 60 seconds with ALL ZEROs including the TYPE
Code field. In the event of a loss of GPS data the Airborne Position Message
would have barometric altitude in it, the Airborne Velocity Message would not.
However, a receiver could not determine the difference between these cases,
therefore the transmitted altitude was not usable.
e. The ADS-B Transmitting Subsystem shall continue to broadcast the Target State and
Status Message for as long as Airborne Position Messages are being broadcast.
Note: Target State and Status Messages do not need to be terminated until the
Airborne and Surface Position Messages are terminated since the Target
State and Status Messages contain various integrity, mode, or status
information that is applicable to the Airborne Position Messages.
f. The ADS-B Transmitting Subsystem shall continue to broadcast the Operational

Status Messages for as long as Airborne Position Messages or Surface Position
Messages are being broadcast.
Note: Operational Status Messages do not need to be terminated until the Airborne
Position Messages and the Surface Position Messages are terminated since
the Operational Status Messages contain various integrity, mode, or status
information that is applicable to the Airborne Position Messages or the
g. Class B2 Non-Transponder-Based Transmitting Subsystems on Ground Vehicles

shall provide an interface capable of putting the unit into a standby condition in
which the unit suspends all message transmissions.
20xx, RTCA, Inc.

156
Notes:
1. This interface is intended to be used by a mapping function that will

automatically trigger the interface if the Transmitting Subsystem is outside a user
adaptable two-dimensional geographic area.
2. If required because of spectrum considerations, the two-dimensional geographic

area will be defined as the movement area (i.e., runways and taxiways) plus a
reasonable buffer area (i.e., 50 foot buffer). Implementations of this feature
should be designed such that a particular ground authority can specify a region
that conserves spectrum without introducing risk of accidental termination within
the movement area. Consideration should be given to precision and accuracy of
the geographic region definition.
3. As a vendor option, this mapping function may be implemented integral to the

Class B2 equipment. In this case, the interface is internal to the unit.
2.2.3.4 ADS-B Transmitted Message Error Protection

Error protection shall be provided by the ADS-B Transmitting Subsystem encoding all
messages in accordance with the requirements provided in RTCA DO-181D, 2.2.18.2.1
(EUROCAE ED-73C, 3.22.2.1) and illustrated in Figure 2-11 of RTCA DO-181D
(EUROCAE ED-73C, Figure 3-9).
Note: The requirements of RTCA DO-181D, 2.2.18.2.1 and Figure 2-11 (EUROCAE
ED-73C, 3.22.2.1 and Figure 3-9) are consistent with the requirements of ICAO
Annex 10, Volume IV, fourth edition, July 2007, 3.1.2.3.3.
2.2.4 ADS-B Receiver Characteristics
2.2.4.1 Minimum Triggering Level (MTL) Definition

a. The sensitivity of the ADS-B Receiver is sufficient to reliably detect and decode
ADS-B Messages provided the received power is at or above a certain level. The
receiver sensitivity requirements are stated in terms of the Minimum Triggering
Level (MTL) specified in the following paragraphs.
b. Given a valid ADS-B Message signal that complies with the frequency, pulse spacing
and pulse width requirements, and in the absence of interference or overloads, the
MTL of an ADS-B receiver is defined as the received power level that results in a
successful message reception ratio of 90%.
2.2.4.2 Receivers Shared with a TCAS Unit

a. ADS-B Receiving Subsystems implemented as part of a TCAS unit shall comply
with all receiver requirements specified in the TCAS MOPS, RTCA DO-185B,
2.2.4.4 (EUROCAE ED-143, 2.2.4.4).
b. ADS-B Receiving Subsystems operating with TCAS units that are more sensitive
than the MTL requirements specified in RTCA DO-185B (EUROCAE ED-143),
shall implement the capabilities specified in 2.2.4.2.1 through 2.2.4.4.
20xx, RTCA, Inc.

157
Note: The TCAS MOPS, RTCA DO-185B (EUROCAE ED-143), uses the term
Extended Squitter to refer to messages having the same formats and
transmission requirements as those messages referred to as ADS-B Messages
in this document. These terms should be accepted as being equivalent when
referring to the TCAS system.
2.2.4.2.1 Dual Minimum Triggering Levels

Note: A TCAS receiver that is also used as an ADS-B receiver will have a minimum
triggering level (MTL) that is more sensitive than a standard TCAS receiver.
Such a receiver must implement dual MTLs so that it is capable of setting an
indication for each squitter reception as to whether the reply would have been
detected by a TCAS operating with a standard MTL. Squitter receptions received
at the standard MTL will be passed to the TCAS surveillance function for further
processing. Squitter receptions that do not meet this condition will be not passed
to the TCAS surveillance function.
2.2.4.2.1.1 TCAS Compatibility

No more than 10% of all ADS-B Messages received at an input signal level of -78 dBm
or less shall be delivered to the TCAS functions specified in RTCA DO-185B
(EUROCAE ED-143).
Note: Use of the standard TCAS MTL (-74 +2dB as specified in RTCA DO-185B
2.2.4.4.1.1.a (EUROCAE ED-143, 2.2.4.4.1.1.a)) for the TCAS surveillance
functions preserves the current operation of TCAS surveillance when operating
with a receiver with an improved MTL, such as those inferred in 2.2.4.3.1.
2.2.4.2.1.2 ADS-B Compatibility

All ADS-B Messages shall be processed in accordance with 2.2.4.3.1.1.
2.2.4.2.2 Re-Triggerable Reply Processor

The TCAS Mode S reply processing function shall use a Mode S reply processor that
will re-trigger if it detects a Mode S preamble that is at least 3 dB stronger than the reply
that is currently being processed in order to ensure that the stronger signal is processed.
Note: Care must be taken to ensure that low-level squitters (i.e., those below the
nominal TCAS MTL) do not interfere with the processing of acquisition squitters
for TCAS. This may happen if the low-level squitter is allowed to capture the
reply processor. This may be prevented by using a separate reply processor for
each function, or by requiring the reply processor to be re-triggered by a higher
level squitter message.
20xx, RTCA, Inc.

158
2.2.4.3 Receivers Not Shared With TCAS
2.2.4.3.1 In-Band Acceptance and Re-Triggerable Capability
2.2.4.3.1.1 In-Band Acceptance

The requirements provided in the following subparagraphs are specified at the Antenna
end of an Antenna to Receiver transmission line having loss equal to the maximum for
which the receiving installation is designed.
a. The MTL of an ADS-B receiver processing signals over the frequency range of 1089
to 1091 MHz shall comply with the MTL limits provided in Table 2-79 for the
applicable receiver Equipment Class.
Table 2-79: ADS-B Class A Equipment Receiver Sensitivity

EQUIPMENT
A0 A1S/A1 A2 A3
CLASS
MTL -72 dBm -79 dBm -79 dBm -84 dBm
Note: The MTL limits of Table 2-79 must be complied with over the entire
environmental operating range specified by the manufacturer of the receiver
(e.g., receiver performance variations over temperature and other conditions
must be taken into account).
b. In the absence of interference or overloads, each ADS-B receiver shall properly

detect and decode at least 99% of all ADS-B Messages received at an input signal
level between the levels of MTL + 3 dB and -21 dBm.
c. In the absence of interference or overloads, each ADS-B receiver of equipment Class

A3 shall properly detect and decode at least 15% of all ADS-B Messages received at
an input signal level of -87 dBm.
Notes:
1. This requirement need only be tested under ambient conditions.
2. The intent of this requirement is to emphasize the desirability of taking

advantage of signals received below the required MTL.
2.2.4.3.1.2 Re-Triggerable Capability

ADS-B receivers having Equipment Class A1S, A1, A2 or A3 capability shall re-trigger
if such receivers detect an ADS-B Message having a preamble that is at least 3 dB
stronger than that of the message that is currently being processed.
Note: This requirement is required in order to ensure that the ADS-B processor will
properly detect and process the stronger signal.
20xx, RTCA, Inc.

159
2.2.4.3.2 Out-of-Band Rejection

For out-of-band signals the ADS-B Message signal level required to provide 90 percent
ratio of decoded and accepted messages to the number of actual messages transmitted
shall increase relative to the equipment MTL at 1090 MHz as provided in Table 2-80.
Table 2-80: ADS-B Receiver Out -of- Band Rejection

Message
Frequency Difference Triggering Level
(MHz from 1090 MHz) (dB above MTL)
+ 5.5 Greater Than or Equal to 3
+ 10 Greater Than or Equal to 20
2.2.4.3.3 Dynamic Minimum Trigger Level (DMTL)

ADS-B single receiver systems shall implement Dynamic Minimum Trigger Level
(DMTL) control as a mean of rejecting low level multipath signals and interference.
If the enhanced reception techniques (2.2.4.4) are used, then the DMTL characteristics
shall be compatible with the requirements in 2.2.4.4. Otherwise, the DMTL
characteristics shall be compatible with the requirements in 2.2.4.3.4.1 through
2.2.4.3.4.3.
2.2.4.3.4 1090 MHz ADS-B Message Reception Techniques
2.2.4.3.4.1 ADS-B Message Reception

a. When listening for ADS-B Messages and upon receipt of a single pulse of greater
than 300 nanoseconds duration and having amplitude A, where A exceeds MTL +8
dB, the receiver threshold shall increase to A -6 dB +1 dB for a period of not less
than five microseconds following the leading edge of the first pulse and shall be
recovered in not more than eight microseconds, unless a valid or qualifying preamble
is received (2.2.3.1.1), in which case the threshold shall be held at A -6 dB +1 dB
for a period of not less than 115 microseconds and shall be recovered in not more
than 120 microseconds.
The receiver threshold shall at no time exceed A -5 dB except for possible overshoot
during the first microsecond following the leading edge of the first pulse.
b. If A is less than MTL +8 dB, there is no requirement to raise the threshold.
Notes:
1. The length of an ADS-B Message cannot be determined with certainty by the DMTL
system. Therefore, the ADS-B Message DMTL desensitizes for the duration of the
ADS-B Message.
20xx, RTCA, Inc.

160
2. These requirements are consistent with the requirements of RTCA DO-185,

2.2.2.3.2. Note that there is no direct correlation to these requirements provided in
RTCA DO-185A. In fact, RTCA DO-185A has deleted the DMTL requirements
previously provided and now relies completely on Whisper Shout level control
techniques to provide multipath rejection (see 2.2.4.5.1 or RTCA DO-185A).
XXXXXXXX TBD XXXXXXXX What do we do about this note ??
2.2.4.3.4.2 Narrow Pulse Discrimination

The DMTL control shall not be responsive to pulses that have a width of less than 0.3
microseconds.
Note: These requirements are consistent with the requirements of RTCA DO-185B,
2.2.4.5.1.2.1 (EUROCAE ED-143, 2.2.4.5.1.2.1).
2.2.4.3.4.3 TACAN and DME Discrimination

The DMTL control shall not be responsive to TACAN or DME pulses.
Note: These requirements are consistent with the requirements of RTCA DO-185B,
2.2.4.5.1.2.2 (EUROCAE ED-143, 2.2.4.5.1.2.2).
2.2.4.3.4.4 Pulse Characteristics of Received ADS-B Messages

All pulse characteristics of the ADS-B Messages were previously specified in 2.2.2.2.1
and 2.2.3.1 and associated subparagraphs of this document.
2.2.4.3.4.5 Message Formats

The 1090 MHz receiver shall correctly decode all valid ADS-B Messages received in
accordance with the requirements specified in 2.2.4.3.1.1 through 2.2.4.3.4.4. A valid
Extended Squitter message follows the format specified in RTCA DO-181D (EUROCAE
ED-73C) with the PI field specified with II=0 and SI=0.
General formats of the Extended Squitter (i.e., ADS-B) Messages was provided is
2.2.3.1 through 2.2.3.2.1.7 of this document.
2.2.4.3.4.6 Description of 1090 MHz ADS-B Message Received Signals

Formats of ADS-B transmitted messages were previously specified in 2.2.3.2.3 through
2.2.3.2.7 of this document.
20xx, RTCA, Inc.

161
2.2.4.3.4.7 ADS-B Signal Reception
2.2.4.3.4.7.1 Criteria for ADS-B Message Transmission Pulse Detection

a. ADS-B Message transmission pulse decoding shall be based on pulse leading edges.
Note: The occurrence of a leading edge may be determined directly from a positive
slope or inferred from pulse widths and trailing edge positions. An actual
leading edge is defined as an event for which: the signal rises at a rate
exceeding 48 dB per microsecond to a level above the receiver threshold
AND 0.125 microseconds later the rate of rise is less than 48 dB per
microsecond. An inferred leading edge is defined as an event in which a
leading edge is assumed to exist in order to account for a pulse whose width
implies the existence of overlapping pulses.
a. All performance requirements shall be met for pulses having the following
characteristics:
(1). Pulse Amplitude Variation: up to +2 dB, relative to the amplitude of
the first preamble pulse
(2). Pulse rise time: 0.1 microsecond or less
(3). Pulse decay time: 0.2 microseconds or less
2.2.4.3.4.7.2 Criteria for Preamble Acceptance

The first qualifying criterion for reception of an ADS-B 1090 MHz message signal shall
be the reception of the Preamble (2.2.3.1.1). A preamble shall be accepted if each of
the four pulse positions of the preamble waveform contains a pulse that is above the
receiver threshold for at least 75 percent of its nominal duration, AND the last three
pulses are within +0.125 microseconds of their nominal position relative to the first pulse,
AND at least two of the four preamble pulses have actual leading edges (as specified in
2.2.4.3.4.7.1.a) that occur within +0.125 microseconds of their nominal edge positions.
All inferred leading edges shall occur within +0.125 microseconds of the expected
nominal position.
Note: Appendix I provides description of an improved implementation.
2.2.4.3.4.7.3 Criteria for Data Block Acceptance in ADS-B Message Signals

ADS-B Messages always contain 112 data bits. Each bit of the 1090 MHz ADS-B
Message Data Block shall be decoded by comparing the received signal with a 0.5
microsecond delayed replica of itself to determine the difference between the signal
amplitudes at the centers of the two possible pulse positions for that bit.
The ADS-B transmission shall be accepted as a valid ADS-B Message if:
a. The first five bits of the data block contain either the code 1 0001 or 1 0010 (i.e.,
either DF=17 or DF=18);
b. AND no error is detected, OR error correction performed in accordance with

2.2.4.4.2.2.d and Appendix A, Section 3 of RTCA DO-185B (EUROCAE ED-143,
20xx, RTCA, Inc.

162
2.2.4.4.2.2.d) can be successfully applied, AND no more than seven consecutive

data bits fail the following confidence test:
Sample the received signal at least eight times during the one microsecond bit
interval to determine if the amplitude of the received signal is above or below the
dynamic minimum triggering level of the receiver. The data bit shall be declared
a high-confidence bit if, between the first and second of the two possible pulse
positions for that bit, the difference in the number of samples for which the signal
is above DMTL is at least three AND the sign of this difference agrees with the
decoded value of the bit.
Notes:
1. Alternative equivalent methods are acceptable, provided that the manufacturer

provides evidence that performance is not degraded.
2. Acceptance of ADS-B transmissions with the first five bits identified as

1 0011 (i.e., DF=19) is optional.
2.2.4.3.5 ADS-B Receiver Duty Factor

Available ADS-B receiver duty factor (i.e., the percentage of time that the ADS-B
Message Reception function is able to receive and process ADS-B Messages at the
required ADS-B MTL), when the receiver is shared with another receiving function using
the 960-1215 MHz band, is an important consideration in meeting the intended ranges of
operation for ADS-B equipment. The available ADS-B receiver duty factor shall be 90%
or greater, averaged over a 10 second period. As an exception, if the available ADS-B
receiver duty factor is less than 90 percent, techniques for achieving equivalent
performance may be proposed and substantiated by analysis.
2.2.4.4 Enhanced Squitter Reception Techniques
2.2.4.4.1 Need for Enhanced Techniques

The 1090 MHz ADS-B Message Reception Techniques specified in 2.2.4.3.4 provide a
high probability of correct reception when the desired squitter is overlapped with one
ATCRBS interfering reply of equal or greater power. In some high interference
environments (e.g., Los Angeles or Frankfurt, Germany), there is a relatively high
probability that the desired squitter signal will be overlapped with two or more ATCRBS
replies. In these environments, the air-to-air range may be reduced because of the effects
of this interference.
2.2.4.4.2 Enhanced Squitter Reception Technique Overview

Enhanced squitter reception techniques have been developed (see Appendix I) that
provide the ability to receive squitters with multiple overlapping Mode A/C FRUIT.
Such enhanced reception techniques are composed of the following elements:
a. Improved preamble detection to reduce the probability of a false alarm caused by

detection of an apparent Mode S preamble synthesized by overlapped Mode A/C
FRUIT replies.
20xx, RTCA, Inc.

163
b. Improved code and confidence bit declaration typically based on the use of amplitude
to aid in the interpretation of the squitter data block.
c. More capable error correction techniques that are optimized to the characteristics of
the code and confidence process.
Class A1S, A1, A2 and A3 equipment shall demonstrate compliance with test procedures
specified in 2.4.4.4 and its subparagraphs.
Note: The full set of enhanced techniques are applicable to Class A2 and A3 receiving
equipment. Class A1S and A1 receiving equipment requires only a subset of the
enhanced reception capabilities, and this is reflected in the test procedures of
2.4.4.4 and its subparagraphs.
2.2.4.4.3 Error Correction
2.2.4.4.3.1 Error Correction Requirements

The ADS-B Receiving Subsystem shall either
a. use conservative and brute force error correction techniques as defined in I.4.3,
or
b. use alternative error correction techniques that are demonstrated to provide no more
than 1 x (10-6) report error rate.
2.2.4.4.3.2 Error Correction Restrictions

The enhanced reception techniques are intended to operate in very high Mode A/C
FRUIT environments. For this reason, the sliding window error correction technique
shall not be used in conjunction with the enhanced techniques since it produces an
unacceptably high undetected error rate in these high FRUIT environments.
Note: See Appendix I, I.3.3 and I.4.3 for more details on error correcting techniques.
2.2.4.5 ADS-B Received Message Error Protection

a. Error protection shall be provided by the ADS-B Receiving Subsystems decoding all
messages that have been encoded in accordance with the requirements provided in
RTCA DO-181D, 2.2.18.2.1.c and illustrated in Figure 2-11 of RTCA DO-181D
(EUROCAE ED-73C, 3.22.2.1.c and Figure 3-10).
b. Error correction techniques for equipment class A0 shall be applied by the ADS-B
Receiving Subsystems in accordance with RTCA DO-185B, Appendix A, A.3
(EUROCAE ED-143, A.3).
c. Error correction techniques for equipment Classes A1S, A1, A2 and A3 are specified
in 2.2.4.4.2.
20xx, RTCA, Inc.

164
2.2.5 ADS-B Transmission Device Message Processor Characteristics

The primary functions of the ADS-B Transmission Device Message Processor are
described in the following subparagraphs.
2.2.5.1 ADS-B Transmission Device Data Processing and Message Formatting
2.2.5.1.1 Participant Address
2.2.5.1.1.1 ICAO 24-Bit Discrete Address

The ADS-B Transmitting Subsystem shall accept the ICAO 24-bit Discrete Address via
an appropriate data input interface. For Transponder-Based systems, the ADS-B
Transmitting Subsystem shall format such data into the AA field (2.2.3.2.1.5),
Message bits 9 through 32, of ALL ADS-B Message Transmissions as identified in
Figure 2-2. Non-Transponder-Based systems shall format such data when selecting the
24-Bit ICAO Address from the Address Qualifier input specified in 2.2.5.1.1.3.
The ADS-B Transmitting Subsystem shall read in and store the ICAO 24-bit Discrete
Address during power-up initialization. For Transponder-Based Systems, the address
shall not change from the value stored at power-up, as required by RTCA DO-181D.
For Non-Transponder-Based Systems, if a means to change the ICAO 24-bit Address is
provided and permitted by the appropriate regulatory authority, the change shall only be
accepted while in standby mode as per section 4.4.6.
2.2.5.1.1.2 Anonymous Address

For Non-Transponder-Based systems, the use of an Anonymous Address may be allowed
under certain conditions. When an Anonymous Address is used the ADS-B Transmitting
Subsystems shall accept the Anonymous Address via an appropriate data input interface.
The Anonymous Address shall only be accepted while in standby mode as per section
4.4.6. The ADS-B Transmitting Subsystem shall format such data into the AA field
(2.2.3.2.1.5), Message bits 9 through 32, of ALL ADS-B Message Transmissions when
selecting Anonymous Address from the Address Qualifier input specified in
2.2.5.1.1.3.
2.2.5.1.1.3 Address Qualifier for Non-Transponder Devices

For Non-Transponder-Based systems, the ADS-B Transmitting Subsystems shall accept
the Address Qualifier selection via an appropriate data input interface. The input shall
select between the 24-Bit ICAO Address and the Anonymous Address to be
transmitted in the AA field (2.2.3.2.1.5), Message bits 9 through 32, of ALL ADS-B
Message Transmissions.
20xx, RTCA, Inc.

165
2.2.5.1.2 ADS-B Emitter Category Data

The ADS-B Transmitting Subsystem shall accept the ADS-B Emitter Category (see
2.2.3.2.5.2) via an appropriate data input interface and use such data to establish the
ADS-B Emitter Category Subfield in Aircraft Identification and Category Messages
(see 2.2.3.2.5) as specified in 2.2.3.2.5.2.
If the ADS-B Emitter Category is not available to the ADS-B Transmitting Subsystem,
then the device shall enter ALL ZEROS into the "ADS-B Emitter Category" Subfield in
2.2.5.1.3 Air/Ground Status Data

The ADS-B Transmitting Subsystem shall accept Air/Ground status information via an
appropriate data input interface and use such data to establish the CA Capability Field
as specified in 2.2.3.2.1.2.
If the ADS-B Transmitting Subsystem does not accept Air/Ground status information via
automatic means, the CA Capability field shall be set to 6 or 7 as specified in Table 2-8
in 2.2.3.2.1.2.
2.2.5.1.4 Surveillance Status Data

The ADS-B Transmitting Subsystem shall accept Surveillance status information via an
appropriate data input interface and use such data to establish the Surveillance Status
subfield in the ADS-B Airborne Position Message (see 2.2.3.2.3) as specified in
2.2.3.2.3.2.
Note: The Surveillance Status information interface is an internal interface in

transponder implementations.
2.2.5.1.5 Altitude Data

a. Pressure Altitude -- The ADS-B Transmitting Subsystem shall accept
Barometric Altitude (see 2.2.3.2.3.4.1) information via an appropriate variable data
input interface and use such data to establish the Altitude subfield in the ADS-B
Airborne Position Message (see 2.2.3.2.3) as provided in 2.2.3.2.3.4 through
2.2.3.2.3.4.3 with the following additional constraints:
(1). When operated in conjunction with a pressure-altitude encoder (digitizer) or an

air data system, the ADS-B Transmitting Subsystem shall have the capability
for pressure-altitude transmission up to its designed maximum altitude.
(2). If pressure-altitude Data is not available to the ADS-B Transmitting

Subsystem, then the device shall enter ALL ZEROs into the Altitude subfield
specified in 2.2.3.2.3.4.
20xx, RTCA, Inc.

166
b. GNSS Height Above the Ellipsoid (HAE) -- The ADS-B Transmitting

Subsystem shall accept GNSS Height Above the Ellipsoid (HAE) (see 2.2.3.2.3.4.2)
information via an appropriate variable data input interface and use such data to
establish subfields in ADS-B transmitted messages as follows:
(1). The Altitude subfield in the ADS-B Airborne Position Message (see
2.2.3.2.3) as provided in 2.2.3.2.3.4.2 through 2.2.3.2.3.4.3,
(2). The Difference From Barometric Altitude Sign Bit subfield (see
2.2.3.2.6.1.14) in the Airborne Velocity Subtype 1 & 2 (see 2.2.3.2.6.1
and 2.2.3.2.6.2) as specified in 2.2.3.2.6.1.14 and 2.2.3.2.6.2.14,
respectively,
(3). The Difference From Barometric Altitude Sign Bit subfield (see
2.2.3.2.6.1.14) in the Airborne Velocity Subtype 3 & 4 (see 2.2.3.2.6.3
and 2.2.3.2.6.4) as specified in 2.2.3.2.6.3.15 and 2.2.3.2.6.4.15,
respectively,
(4). The Difference From Barometric Altitude subfield (see 2.2.3.2.6.1.15) in

the Airborne Velocity Subtype 1 & 2 (see 2.2.3.2.6.1 and 2.2.3.2.6.2) as
specified in 2.2.3.2.6.1.15 and 2.2.3.2.6.2.15, respectively, and
(5). The Difference From Barometric Altitude subfield (see 2.2.3.2.6.1.15) in

the Airborne Velocity Subtype 3 & 4 (see 2.2.3.2.6.3 and 2.2.3.2.6.4) as
specified in 2.2.3.2.6.3.15 and 2.2.3.2.6.4.15, respectively,
If appropriate GNSS Height Above the Ellipsoid (HAE) data is not available to the
ADS-B Transmitting Subsystem, then the device shall set all subfields identified
above in subparagraphs (1). through (5). to ZERO.
c. GNSS Altitude (MSL) -- If GNSS Height Above the Ellipsoid (HAE)

data is not available to the ADS-B Transmitting Subsystem, then the device may
accept GNSS Altitude (MSL) data and use such data to establish the subfields
identified above in subparagraphs b.(1). through b.(5).
d. NO GNSS Height/Altitude Data -- If neither GNSS Height Above the Ellipsoid

(HAE) nor GNSS Altitude (MSL) data are available to the ADS-B Transmitting
Subsystem, then the device shall set all subfields identified above in subparagraphs
b.(1). through b.(5). to ZERO.
20xx, RTCA, Inc.

167
2.2.5.1.6 Time Data and Time Mark Pulse

The ADS-B Transmitting Subsystem shall accept GPS/GNSS Time Mark information as
provided in the following subparagraphs.
2.2.5.1.6.1 Case, where TIME (T) = 0

a. If the ADS-B Transmitting Subsystem is not capable of setting the TIME (T)
subfield (see 2.2.3.2.3.5) in the Airborne Position Message (see 2.2.3.2.3) or in the
Surface Position Message (see 2.2.3.2.4), then the ADS-B Transmitting Subsystem
shall set the TIME subfield to ZERO.
b. Whenever the ADS-B Transmitting Subsystem is setting the TIME (T) subfield
to ZERO as provided in subparagraph a., then the ADS-B Transmitting Subsystem
shall not be required to accept and process GPS/GNSS Time Mark information.
2.2.5.1.6.2 Case, where TIME (T) = 1

a. If the ADS-B Transmitting Subsystem is capable of setting the TIME (T) subfield
(see 2.2.3.2.3.5) to ONE in the Airborne Position Message (see 2.2.3.2.3) or in the
Surface Position Message (see 2.2.3.2.4), then the ADS-B Transmitting Subsystem
shall accept and process a GPS/GNSS Time Mark pulse or an equivalent time
synchronization indication from the source of navigation data.
b. The leading edge of the GPS/GNSS Time Mark pulse, or equivalent, shall indicate
the exact moment (epoch of the UTC time scale) 5 milliseconds that represents the
time of applicability of Position, Velocity, and Time (PVT) information that is
received from the navigation source.
Note: A possible implementation of the GPS/GNSS Time Mark pulse is illustrated

in Figure 2-15. The PVT data is expected to be provided by the navigation
data source no later than 200 milliseconds after the leading edge of the
GPS/GNSS Time Mark pulse, or equivalent.
c. When the ADS-B Transmitting Subsystem sets the TIME (T) subfield to ONE in
the Airborne Position Message (see 2.2.3.2.3), then the ADS-B Transmitting
Subsystem shall use the GPS/GNSS Time Mark pulse to accomplish the following:
(1). Synchronize the loading of the Airborne Position Message such that the
register is properly loaded 100 milliseconds 50 milliseconds prior to the time
of applicability of the data being loaded into the register.
(2). Establish the Time subfield in ADS-B Airborne Position Messages (see
2.2.3.2.3) as specified in 2.2.3.2.3.5,
(3). Establish the CPR Format subfield in ADS-B Airborne Position Messages
(see 2.2.3.2.3) as specified in 2.2.3.2.3.6,
20xx, RTCA, Inc.

168
(4). Extrapolate Airborne Latitude Position in ADS-B Airborne Position Messages

(see 2.2.3.2.3) as specified in 2.2.3.2.3.7.2.
(5). Extrapolate Airborne Longitude Position in ADS-B Airborne Position

Messages (see 2.2.3.2.3) as specified in 2.2.3.2.3.8.2,
d. When the ADS-B Transmitting Subsystem sets the TIME (T) subfield to ONE in
the Surface Position Message (see 2.2.3.2.4), then the ADS-B Transmitting
Subsystem shall use the GPS/GNSS Time Mark pulse to accomplish the following:
(1). Synchronize the loading of the Surface Position Message such that the register
is properly loaded 100 milliseconds 50 milliseconds prior to the time of
applicability of the data being loaded into the register.
(2). Establish the Time subfield in ADS-B Surface Position Messages (see
2.2.3.2.4) as specified in 2.2.3.2.4.5,
(3). Establish the CPR Format subfield in ADS-B Surface Position Messages (see
2.2.3.2.4) as specified in 2.2.3.2.4.6,
(4). Extrapolate Surface Latitude Position in ADS-B Surface Position Messages

(see 2.2.3.2.4) as specified in 2.2.3.2.4.7.2, and
(5). Extrapolate Surface Longitude Position in ADS-B Surface Position Messages

(see 2.2.3.2.4) as specified in 2.2.3.2.4.8.2.
20xx, RTCA, Inc.

169
t0 t1
1.0 second
TIME MARK Pulse from GPS/GNSS Receiver

200 ms.
max
POSITION, VELOCITY, and TIME (PVT)

Data Output from GPS/GNSS Receiver
DATA
POSITION
GNSS Longitude
GNSS Latitude
GNSS Longitude (Fine)
GNSS Latitude (Fine)
GNSS Height Above the Ellipsoid (HAE)
VELOCITY
GNSS Ground Speed
GNSS Track Angle
North/South Velocity
East/West Velocity
TIME
UTC (hh:min:ss)
UTC Fine
UTC Fine Fractions
Figure 2-15: GPS/GNSS Time Mark Pulse
Note: Navigation and UTC time information should be available within 200
milliseconds following the leading edge of the Time Mark at time t0. The
information is considered to be valid at time t0. Specifically, the information is
NOT projected to be valid at time t1, which represents the beginning of the next
GPS/GNSS Epoch.
20xx, RTCA, Inc.

170
2.2.5.1.7 Own Position Latitude Data

The ADS-B Transmitting Subsystem shall accept own position Latitude information via
an appropriate variable data input interface and use such data to establish subfields in
ADS-B transmitted messages as follows:
a. The encoded Latitude subfield in the Airborne Position Message (see 2.2.3.2.3) as
specified in 2.2.3.2.3.7 through 2.2.3.2.3.7.4,
b. The encoded Latitude subfield in the Surface Position Message (see 2.2.3.2.4) as
Note: Encoded Latitude for the Airborne and the Surface Position Messages will
normally not be the same. However, the procedures used to obtain the
Encoded Latitude for either case are essentially the same in the CPR
algorithm. (See Appendix A).
c. If Latitude data is not available to the ADS-B Transmitting Subsystem, then the
device shall enter ALL ZEROs into the Encoded Latitude subfield of the Airborne
Position Message (2.2.3.2.3) when airborne or into the Encoded Latitude subfield of
the Surface Position Message (2.2.3.2.4) when on the surface.
Note: Any airport surface application(s) that will use ADS-B surface position
information will need to account for the potential navigation error
associated with the reported position relative to the navigation center of the
aircraft.
2.2.5.1.8 Own Position Longitude Data

The ADS-B Transmitting Subsystem shall accept own position Longitude information
via an appropriate variable data input interface and use such data to establish subfields in
ADS-B transmitted messages as follows:
a. The encoded Longitude subfield in the Airborne Position Message (see 2.2.3.2.3) as
b. The encoded Longitude subfield in the Surface Position Message (see 2.2.3.2.4) as
Note: Encoded Longitude for the Airborne and the Surface Position Messages will
normally not be the same. However, the procedures used to obtain the
Encoded Longitude for either case are essentially the same in the CPR
algorithm. (See Appendix A).
c. If Longitude data is not available to the ADS-B Transmitting Subsystem, then the
device shall enter ALL ZEROs into the Encoded Longitude subfield of the Airborne
Position Message (2.2.3.2.3) when airborne or into the Encoded Longitude subfield
of the Surface Position Message (2.2.3.2.4) when on the surface.
20xx, RTCA, Inc.

171
Note: Any airport surface application(s) that will use ADS-B surface position
information will need to account for the potential navigation error
associated with the reported position relative to the navigation center of the
aircraft.
2.2.5.1.9 Ground Speed Data

a. The ADS-B Transmitting Subsystem shall accept own vehicle Ground Speed
information via an appropriate variable data input interface and use such data to
establish the Movement subfield (see 2.2.3.2.4.2) in the Surface Position Message
b. If Ground Speed data is not available to the ADS-B Transmitting Subsystem, then the
device shall enter ALL ZEROs into the Movement subfield specified in 2.2.3.2.4.2.
c. Ground Speed may be used in conjunction with Ground Track data to arithmetically
establish East/West Velocity Data (see 2.2.5.1.2) and North/South Velocity Data
(see 2.2.5.1.3) if East/West and/or North/South Velocity Data is not available.
(1). When Ground Speed data is used as provided in subparagraph c, the NACV
(see 2.2.5.1.19) data reported by the ADS-B Transmitting Subsystem shall be
consistent with the accuracy, range, and resolution that can be obtained by
using Ground Speed data as the input data to the arithmetic computations
necessary.
(2). When Ground Speed data is used as provided in subparagraph c, but Ground
Speed Data is not available to the ADS-B Transmitting Subsystem, then the
device shall enter ALL ZEROs into all transmitted subfields that are computed
based on Ground Speed data.
2.2.5.1.10 Heading/Ground Track Data

The ADS-B Transmitting Subsystem shall accept own vehicle Heading/Ground Track
information via an appropriate variable data input interface and use such data to establish
subfields in transmitted ADS-B Messages as follows:
a. The Status Bit for Heading/Ground Track subfield in the Surface Position Message
(See 2.2.3.2.4) as specified in 2.2.3.2.4.3,
b. The Heading/Ground Track subfield in the Surface Position Message (see

2.2.3.2.4.2) as specified in 2.2.3.2.4.4,
c. If Heading/Ground Track data is not available to the ADS-B Transmitting

Subsystem, then the device shall enter ALL ZEROs into the Status Bit for
Heading/Ground Track and Heading subfields specified in 2.2.3.2.4.3 and
2.2.3.2.4.4 respectively,
d. Heading/Ground Track may be used in conjunction with Ground Speed data to

arithmetically establish East/West Velocity Data (see 2.2.5.1.2) and North/South
20xx, RTCA, Inc.

172
Velocity Data (see 2.2.5.1.3) if East/West and/or North/South Velocity Data is not
available.
(1). When Heading/Ground Track data is used, the NACV (see 2.2.5.1.19) data
reported by the ADS-B Transmitting Subsystem shall be consistent with the
accuracy, range, and resolution that can be obtained by using Heading data as
the input data to the arithmetic computations necessary.
(2). When Heading/Ground Track data is used, but Heading/Ground Track Data is
not available to the ADS-B Transmitting Subsystem, then the device shall
enter ALL ZEROs into all transmitted subfields that are computed based on
Heading/Ground Track data.
Notes:
1. Ground Track data may be unreliable at low ground speeds. At very low ground
speeds, the best estimate of an aircrafts or ground vehicles ground track angle may
be from a heading source rather than from the track angle output of a GNSS
receiver.
2. If a source of A/V Heading is not available to the ADS-B Transmitting Subsystem,

but a source of Ground Track angle is available, then Ground Track angle may be
used instead of Heading, provided that the Status Bit for Heading/Ground Track
subfield is set to ZERO whenever the Ground Track angle is not a reliable indication
of the A/Vs heading. (The Ground Track angle is not a reliable indication of the
A/Vs heading when the A/Vs ground speed is close to ZERO.)
2.2.5.1.11 Aircraft Identification (or Registration) Data

a. The ADS-B Transmitting Subsystem shall accept own vehicle Aircraft Identification
Data via an appropriate data input interface and use such data to establish the Aircraft
Identification or Flight Number Data in Aircraft Identification and Category
Messages (see 2.2.3.2.5) as specified in 2.2.3.2.5.3.
b. When Aircraft Identification or Flight Number data specified in subparagraph a is not

available or is not valid, the ADS-B Transmitting Subsystem shall accept own
vehicle Aircraft Registration Character Data (N250DL, etc.) via an appropriate data
input interface and use such data to establish the Aircraft Identification or Flight
Number Data in Aircraft Identification and Category Messages (see 2.2.3.2.5) as
c. Only if Aircraft Identification or Flight Number Data, and Aircraft Registration Data
is not available to the ADS-B Transmitting Subsystem, shall the device enter ALL
ZEROs into the character fields specified in 2.2.3.2.5.3.
20xx, RTCA, Inc.

173
2.2.5.1.12 East/West Velocity Data

The ADS-B Transmitting Subsystem shall accept own vehicle East/West Velocity
a. The Encoded Longitude subfield in Airborne Position Messages (see 2.2.3.2.3) as

b. The Encoded Longitude subfield in Surface Position Messages (see 2.2.3.2.4) as

c. The East/West Direction Bit subfield in Airborne Velocity Messages - Subtypes 1

& 2 (see 2.2.3.2.6.1 and 2.2.3.2.6.2) as specified in 2.2.3.2.6.1.6 and
2.2.3.2.6.2.6 respectively,
d. The East/West Velocity subfield in Airborne Velocity Messages - Subtypes 1 &

2 (see 2.2.3.2.6.1 and 2.2.3.2.6.2 respectively) as specified in 2.2.3.2.6.1.7 and
2.2.3.2.6.2.7 respectively.
If East/West Velocity data is not available to the ADS-B Transmitting Subsystem, then
the device shall enter ALL ZEROs in the E/W Direction Bit and E/W Velocity subfields
specified in:
(1). 2.2.3.2.6.1.6 and 2.2.3.2.6.1.7, and
(2). 2.2.3.2.6.2.6 and 2.2.3.2.6.2.7, respectively.
2.2.5.1.13 North/South Velocity Data

The ADS-B Transmitting Subsystem shall accept own vehicle North/South Velocity
a. The Encoded Latitude subfield in Airborne Position Messages (see 2.2.3.2.3) as

b. The Encoded Latitude subfield in Surface Position Messages (see 2.2.3.2.4) as

c. The North/South Direction Bit subfield in Airborne Velocity Messages - Subtypes

1 & 2 (see 2.2.3.2.6.1 and 2.2.3.2.6.2) as specified in 2.2.3.2.6.1.8 and
2.2.3.2.6.2.8, respectively,
d. The North/South Velocity subfield in Airborne Velocity Messages - Subtypes 1 &

2 (see 2.2.3.2.6.1 and 2.2.3.2.6.2 respectively) as specified in 2.2.3.2.6.1.9 and
2.2.3.2.6.2.9, respectively.
20xx, RTCA, Inc.

174
If North/South Velocity data is not available to the ADS-B Transmitting Subsystem, then
the device shall enter ALL ZEROs in the N/S Direction Bit and N/S Velocity subfields
specified in:
(1). 2.2.3.2.6.1.8 and 2.2.3.2.6.1.9, and
(2). 2.2.3.2.6.2.8 and 2.2.3.2.6.2.9, respectively.
2.2.5.1.14 Vertical Rate Data

The ADS-B Transmitting Subsystem shall accept own vehicle Vertical Rate (Geometric
AND/OR Barometric referenced) information via an appropriate variable data input
interface and use such data to establish subfields in transmitted ADS-B Messages as
follows:
a. The Source Bit for Vertical Rate subfield in the Airborne Velocity - Subtype 1, 2,
3, & 4 Messages (2.2.3.2.6.1, 2.2.3.2.6.2, 2.2.3.2.6.3 and 2.2.3.2.6.4
respectively) as specified in 2.2.3.2.6.1.10, 2.2.3.2.6.2.10, 2.2.3.2.6.3.10 and
2.2.3.2.6.4.10, respectively,
b. The Sign Bit for Vertical Rate subfield in the Airborne Velocity - Subtype 1,2,3,
& 4 Messages (2.2.3.2.6.1, 2.2.3.2.6.2, 2.2.3.2.6.3 and 2.2.3.2.6.4 respectively)
as specified in 2.2.3.2.6.1.11, 2.2.3.2.6.2.11, 2.2.3.2.6.3.11 and 2.2.3.2.6.4.11,
respectively,
c. The Vertical Rate subfield in the Airborne Velocity - Subtype 1,2,3, & 4
Messages (2.2.3.2.6.1, 2.2.3.2.6.2, 2.2.3.2.6.3 and 2.2.3.2.6.4 respectively) as
specified in 2.2.3.2.6.1.12, 2.2.3.2.6.2.12, 2.2.3.2.6.3.12 and 2.2.3.2.6.4.12,
respectively.
If Vertical Rate data is not available to the ADS-B Transmitting Subsystem, then the
device shall enter ALL ZEROs in the Source Bit for Vertical Rate, Sign Bit for
Vertical Rate, and Vertical Rate Subfields specified in subparagraphs a, b and c given
directly above.
2.2.5.1.15 Heading (True or Magnetic) Data

The ADS-B Transmitting Subsystem shall accept own vehicle Heading information via
an appropriate variable data input interface and use such data to establish subfields in
transmitted ADS-B Messages as follows:
a. The Heading Status subfield in Airborne Velocity - Subtype 3 & 4 (2.2.3.2.6.3

and 2.2.3.2.6.4) as specified in 2.2.3.2.6.3.6 and 2.2.3.2.6.4.6, respectively,
b. The Heading subfield in Airborne Velocity - Subtype 3 & 4 (2.2.3.2.6.3 and

2.2.3.2.6.4) as specified in 2.2.3.2.6.3.7 and 2.2.3.2.6.4.7, respectively.
If Heading data is not available to the ADS-B Transmitting Subsystem, then the device
shall enter ALL ZEROs into the Heading Status Bit and Heading subfields specified
in subparagraphs a. and b. directly above respectively.
20xx, RTCA, Inc.

175
2.2.5.1.16 True Airspeed Data

The ADS-B Transmitting Subsystem shall accept own vehicle True Airspeed information
via an appropriate variable data input interface and use such data to establish subfields in
transmitted ADS-B Messages as follows:
a. The Airspeed Type subfield in Airborne Velocity - Subtype 3 & 4 (2.2.3.2.6.3

b. The Airspeed subfield in Airborne Velocity - Subtype 3 & 4 (2.2.3.2.6.3 and

2.2.3.2.6.4) as specified in 2.2.3.2.6.3.9 and 2.2.3.2.6.4.9, respectively.
If appropriate True Airspeed or Indicated Airspeed (2.2.5.1.17) data is not available

to the ADS-B Transmitting Subsystem, then the device shall set the Airspeed Type,
and Airspeed subfields to ALL ZEROs in the subfields specified in:
(1). 2.2.3.2.6.3.8, and 2.2.3.2.6.3.9, and
(2). 2.2.3.2.6.4.8, and 2.2.3.2.6.4.9.
2.2.5.1.17 Indicated Airspeed Data

The ADS-B Transmitting Subsystem shall accept own vehicle Indicated Airspeed
a. The Airspeed Type subfield in Airborne Velocity - Subtype 3 & 4 (2.2.3.2.6.3

b. The Airspeed subfield in Airborne Velocity - Subtype 3 & 4 (2.2.3.2.6.3 and

2.2.3.2.6.4) as specified in 2.2.3.2.6.3.9 and 2.2.3.2.6.4.9 respectively,
If appropriate True Airspeed (2.2.5.1.16) or Indicated Airspeed data is not available

to the ADS-B Transmitting Subsystem, then the device shall set the Airspeed Type,
and Airspeed subfields to ALL ZEROs in the subfields specified in:
(1). 2.2.3.2.6.3.8 and 2.2.3.2.6.3.9, and
(2). 2.2.3.2.6.4.8 and 2.2.3.2.6.4.9.
20xx, RTCA, Inc.

176
2.2.5.1.18 Intent Change Data

a. Intent Change data necessary to establish the setting of the Intent Change Flag in
Airborne Velocity - Subtype 1, 2, 3, & 4 Messages (2.2.3.2.6.1, 2.2.3.2.6.2,
2.2.3.2.6.3 and 2.2.3.2.6.4, respectively) is a Mode-S Transponder function only.
Therefore, appropriate requirements shall be established for such devices in RTCA
DO-181D (EUROCAE ED-73C).
b. Non-Transponder-Based ADS-B Transmitting Subsystems need no additional data to

establish the Intent Change Flag in Airborne Velocity - Subtype 1, 2, 3, & 4
Messages (2.2.3.2.6.1, 2.2.3.2.6.2, 2.2.3.2.6.3 and 2.2.3.2.6.4, respectively) in
accordance with 2.2.3.2.6.1.3, 2.2.3.2.6.2.3, 2.2.3.2.6.3.3 and 2.2.3.2.6.4.3,
respectively.
2.2.5.1.19 NACV Data

The ADS-B Transmitting Subsystem shall accept own vehicle Navigation Accuracy
Category - Velocity (NACV) information via an appropriate variable data input interface
and use such data to establish subfields in transmitted ADS-B Messages as follows:
a. The NACV subfield in the Airborne Velocity - Subtype 1, 2, 3, & 4 Messages

(2.2.3.2.6.1, 2.2.3.2.6.2, 2.2.3.2.6.3 and 2.2.3.2.6.4 respectively) as specified in
2.2.3.2.6.1.5, 2.2.3.2.6.2.5, 2.2.3.2.6.3.5 and 2.2.3.2.6.4.5, respectively,
b. If NACV data is not available to the ADS-B Transmitting Subsystem, then the
device shall enter ALL ZEROs in the NACV subfields specified in 2.2.3.2.6.1.5,
2.2.3.2.6.2.5, 2.2.3.2.6.3.5 and 2.2.3.2.6.4.5.
2.2.5.1.20 Subtype (Aircraft Status) Data

The ADS-B Transmitting Subsystem shall accept own vehicle Subtype information via
an appropriate variable data input interface and use such data to establish the Subtype
subfield in the Aircraft Operational Status Messages (see 2.2.3.2.7.2) as specified in
2.2.3.2.7.2.2.
If appropriate Subtype data is not available to the ADS-B Transmitting Subsystem, then
the device shall set the Subtype subfield specified in 2.2.3.2.7.2.2 to ZERO.
2.2.5.1.21 Capability Class (Reserved) Data

The ADS-B Transmitting Subsystem shall be capable of accepting Reserved
subfields in transmitted ADS-B Aircraft Operational Status Messages.
20xx, RTCA, Inc.

177
2.2.5.1.22 Capability Class (UAT IN) Data

The ADS-B Transmitting Subsystem shall be capable of accepting UAT IN
subfields in transmitted ADS-B Aircraft Operational Status Messages as specified in
2.2.3.2.7.2.3.2.
2.2.5.1.23 Capability Class (1090ES IN) Data

The ADS-B Transmitting Subsystem shall be capable of accepting 1090ES IN
subfields in transmitted ADS-B Aircraft Operational Status Messages as specified in
2.2.3.2.7.2.3.3.
2.2.5.1.24 Capability Class (ARV Report Capability) Data

The ADS-B Transmitting Subsystem shall be capable of accepting ARV Report
Capability information via an appropriate variable data input interface and use such data
to establish subfields in transmitted ADS-B Aircraft Operational Status Messages.
2.2.5.1.25 Capability Class (TS Report Capability) Data

The ADS-B Transmitting Subsystem shall be capable of accepting TS Report
2.2.5.1.26 Capability Class (TC Report Capability) Data

The ADS-B Transmitting Subsystem shall be capable of accepting TC Report
2.2.5.1.27 Capability Class (Position Offset Applied) Data

The ADS-B Transmitting Subsystem shall be capable of accepting Position Offset
Applied information via an appropriate variable data input interface and use such data to
establish subfields in transmitted ADS-B Aircraft Operational Status Messages.
2.2.5.1.28 Operational Mode (OM Format) Data

The ADS-B Transmitting Subsystem shall be capable of accepting OM Format
subfields in transmitted ADS-B Aircraft Operational Status Messages.
20xx, RTCA, Inc.

178
2.2.5.1.29 Operational Mode (TCAS/ACAS Resolution Advisory Active) Data

The ADS-B Transmitting Subsystem shall be capable of accepting TCAS/ACAS
Resolution Advisory Active information via an appropriate variable data input interface
and use such data to establish subfields in transmitted ADS-B Aircraft Operational Status
Messages (TYPE=31, Subtype=0) as specified in 2.2.3.2.7.2.4.2.
2.2.5.1.30 Operational Mode (IDENT Switch Active) Data

The ADS-B Transmitting Subsystem shall be capable of accepting IDENT Switch
Active information via an appropriate variable data input interface and use such data to
establish subfields in transmitted ADS-B Aircraft Operational Status Messages.
2.2.5.1.31 Operational Mode (Reserved for Receiving ATC Services) Data

The ADS-B Transmitting Subsystem shall be capable of accepting Receiving ATC
Services information via an appropriate variable data input interface and, if required in a
future version of these MOPS, use such data to establish subfields in transmitted ADS-B
Aircraft Operational Status Messages.
2.2.5.1.32 Radio Altitude Data

The ADS-B Transmitting Subsystem shall accept Radio Altitude via an appropriate
variable data input interface and use such data to establish the Air/Ground state and
thereby the CA field as provided in 2.2.3.2.1.2.
2.2.5.1.33 Version Number Data

ADS-B Transmitting Subsystems shall set the Version Number as indicated in Table 2-
69.
2.2.5.1.34 Navigation Accuracy Category for Position (NACP) Data

The ADS-B Transmitting Subsystem shall accept own vehicle NACP information via an
appropriate variable data input interface and use such data to establish the NACP
subfield transmitted in the ADS-B Target State and Status Message as specified in
2.2.3.2.7.1.3.8, and the NACP subfield transmitted in the ADS-B Operational Status
Message as specified in 2.2.3.2.7.2.7.
2.2.5.1.35 Navigation Integrity Category for Barometric Altitude (NICBARO) Data

The ADS-B Transmitting Subsystem shall accept own vehicle NICBARO information via
an appropriate variable data input interface and use such data to establish the NICBARO
2.2.3.2.7.1.3.9, and the NICBARO subfield transmitted in the ADS-B Operational Status
20xx, RTCA, Inc.

179
2.2.5.1.36 Navigation Integrity Category Supplement (NICSUPP) Data

The ADS-B Transmitting Subsystem shall accept own vehicle Navigation Integrity
Catgeory Supplement (NICSUPP) information via an appropriate variable data input
interface and use such data to establish the NICSUPP subfield transmitted in the ADS-B
Airborne Position Message as specified in 2.2.3.2.3.3, and in the ADS-B Operational
Status Message as specified in 2.2.3.2.7.2.6.
2.2.5.1.37 A/V Length/Width Code Data

The ADS-B Transmitting Subsystem shall accept own vehicle A/V Length/Width Code
the A/V Length/Width Code subfield transmitted in the ADS-B Operational Status
2.2.5.1.38 Track Angle/Heading Data

The ADS-B Transmitting Subsystem shall accept own vehicle Track Angle/Heading
the Track Angle/Heading subfield transmitted in the ADS-B Operational Status
2.2.5.1.39 Horizontal Reference Direction (HRD) Data

The ADS-B Transmitting Subsystem shall accept own vehicle HRD information via an
appropriate variable data input interface and use such data to establish the HRD
subfield transmitted in the ADS-B Operational Status Message as specified in
2.2.3.2.7.2.13.
2.2.5.1.40 Source Integrity Level (SIL) Data

The ADS-B Transmitting Subsystem shall accept own vehicle Source Integrity Level
the SIL subfield transmitted in the ADS-B Target State and Status Message as specified
in 2.2.3.2.7.1.3.10, and the SIL subfield transmitted in the ADS-B Operational Status
2.2.5.1.41 SIL Supplement Data

The ADS-B Transmitting Subsystem shall accept own vehicle Source Integrity Level
Supplement (SILSUPP) information via an appropriate data input interface and use such
data to establish the SILSUPP subfield transmitted in the ADS-B Target State and Status
Message as specified in 2.2.3.2.7.1.3.1, and the SILSUPP subfield transmitted in the
ADS-B Aircraft Operational Status Message as specified in 2.2.3.2.7.2.14.
20xx, RTCA, Inc.
180
Note: Section 2.2.3.2.7.1.3.1 indicates that an input interface may not be necessary to
provide SIL Supplement information. Rather, it should be sufficient to establish
that the SIL Supplement is set to ZERO (0) if a GNSS source is being used to
provide the geometric position information used to establish position in the
Airborne and Surface Position Messages. Likewise, it should be sufficient to
establish that the SIL Supplement is set to ONE (1) if a NON-GNSS source is
being used to provide the geometric position information used to establish
position in the Airborne and Surface Position Messages. Typical Non-GNSS
sources are recognized as IRS, IRU, DME/DME, DME/DME/LOC, etc.
2.2.5.1.42 MCP/FCU Selected Altitude or FMS Selected Altitude Data

The ADS-B Transmitting Subsystem shall accept own vehicle MCP/FCU Selected
Altitude or FMS Selcetd Altitude information via an appropriate variable data input
interface and use such data to establish the MCP/FCU Selected Altitude or FMS Selcetd
Altitude subfield transmitted in the ADS-B Target State and Status Message as specified
in 2.2.3.2.7.1.3.3.
2.2.5.1.43 Barometric Pressure Setting (Minus 800 millibars) Data

The ADS-B Transmitting Subsystem shall accept own vehicle Barometric Pressure
Setting (Minus 800 millibars) information via an appropriate variable data input interface
and use such data to establish the Barometric Pressure Setting (Minus 800 millibars)
2.2.3.2.7.1.3.4.
2.2.5.1.44 Selected Heading Data

The ADS-B Transmitting Subsystem shall accept own vehicle Selected Heading
subfields transmitted in the ADS-B Target State and Status Message as follows:
a. The Selected Heading Status subfield in the Target State and Status Message as
specified in 2.2.3.2.7.1.3.5,
b. The Selected Heading Sign subfield in the Target State and Status Message as
specified in 2.2.3.2.7.1.3.6, and
c. The Selected Heading subfield in Target State and Status Messages as specified in
2.2.3.2.7.1.3.7.
2.2.5.1.45 MCP / FCU Mode Bits Data

The ADS-B Transmitting Subsystem shall accept own vehicle MCP/FCU Mode
the subfields transmitted in the ADS-B Target State and Status Message as follows:
a. The Status of MCP/FCU Mode Bits subfield in the Target State and Status
Message as specified in 2.2.3.2.7.1.3.11,
20xx, RTCA, Inc.
181
b. The Autopilot Engaged subfield in the Target State and Status Message as
specified in 2.2.3.2.7.1.3.12,
c. The VNAV Mode Engaged subfield in the Target State and Status Message as
specified in 2.2.3.2.7.1.3.13,
d. The Altitude Hold Mode subfield in the Target State and Status Message as
specified in 2.2.3.2.7.1.3.14,
e. The Approach Mode subfield in the Target State and Status Message as specified
in 2.2.3.2.7.1.3.16.
2.2.5.1.46 Emergency/Priority Status Data

The ADS-B Transmitting Subsystem shall accept own vehicle Emergency/Priority Status
the Emergency/Priority Status subfield transmitted in the Emergency/Priority Status
subfield transmitted in the ADS-B Extended Squitter Aircraft Status Message as specified
in 2.2.3.2.7.8.
2.2.5.1.47 Mode A (4096) Code

The ADS-B Transmitting Subsystem shall accept the own vehicle Mode A (4096) Code
from the transponder function and use such data to establish the Mode A Code subfield
transmitted in the ADS-B Extended Squitter Aircraft Status Message (TYPE=28,
Subtype=1) Message as specified in 2.2.3.2.7.8.1.
2.2.5.1.48 TCAS Operational Data

The ADS-B Transmitting Subsystem shall accept TCAS Operational data via an
appropriate variable data input interface and use such data to establish the subfield
transmitted in the ADS-B Extended Squitter Target State and Status Message (TYPE=29,
Subtype=1) as specified in 2.2.3.2.7.1.3.17 and the Aircraft Operational Status Message,
as specified in 2.2.3.2.7.2.3.2.
2.2.5.1.49 Single Antenna Flag Data

The ADS-B Transmitting Subsystem shall accept Single Antenna Operation information
via an appropriate data input interface and use such data to establish the subfield
transmitted in the ADS-B Extended Squitter Aircraft Operational Status Message
(TYPE=31, Subtype=0) as specified in 2.2.3.2.7.2.4.5.
2.2.5.1.50 System Design Assurance (SDA) Data

The ADS-B Transmitting Subsystem shall accept System Design Assurance (SDA)
information via an appropriate data input interface and use such data to establish the
20xx, RTCA, Inc.
182
subfield transmitted in the ADS-B Extended Squitter Aircraft Operational Status Message
(TYPE=31, Subtype=0) as specified in 2.2.3.2.7.2.4.6.
2.2.5.1.51 GNSS Vertical Figure of Merit (VFOM) Data

The ADS-B Transmitting Subsystem shall accept GNSS Vertical Figure of Merit
(VFOM) information via an appropriate data input interface and use such data to
establish the Geometric Vertical Accuracy (GVA) subfield transmitted in the ADS-B
Extended Squitter Aircraft Operational Status Message (TYPE=31, Subtype=0) as
specified in 2.2.3.2.7.2.8.
2.2.5.2 ADS-B Transmission Device Message Latency
2.2.5.2.1 Airborne Position Message Latency

The ADS-B Transmission Device Message Processor function shall update the Airborne
Position Message data fields specified in 2.2.3.2.3 as follows:
a. Type information may change due to changes in the precision, quality, or integrity of
received navigation information. As such, any change in the TYPE information
identified in 2.2.3.2.3.1, or in the NIC Supplement information identified in
2.2.3.2.3.3, shall be reflected in the TYPE subfield of the next scheduled Airborne
Position Message transmission provided that the change occurs and is detected at
least 100 milliseconds prior to the next scheduled Airborne Position Message
transmission.
b. Any change in the Surveillance Status identified in 2.2.3.2.3.2 shall be reflected in

the Surveillance Status subfield of the next scheduled Airborne Position Message
transmission provided that the change occurs and is detected at least 100 milliseconds
prior to the next scheduled Airborne Position Message transmission.
c. Any change in the Altitude identified in 2.2.3.2.3.4 shall be reflected in the Altitude
subfield of the next scheduled Airborne Position Message transmission provided that
the change occurs and is detected at least 100 milliseconds prior to the next
scheduled Airborne Position Message transmission.
d. CPR Format changes at 0.2 second intervals or more often as specified in

2.2.3.2.3.6. A change in the CPR Format shall be reflected in the CPR Format
subfield of the next scheduled Airborne Position Message transmission provided that
the change occurs at least X milliseconds prior to the next scheduled Airborne
Position Message transmission. The time X, shall be dependent upon the NACP
(see Table 2-71, 2.2.3.2.7.2.7 and 2.2.8.2.12) provided to the transmission device
as follows:
(1). X is equal to 200 milliseconds if NACP < 8
(2). X is equal to 50 milliseconds if NACP > 8
20xx, RTCA, Inc.

183
Note: All efforts must be made to allocate the time necessary to update the actual
transmission buffer within the 200 millisecond time frame allocated to the
CPR Format changes. That is that no additional time can be added to the
200 milliseconds already allocated.
e. Encoded Latitude (specified in 2.2.3.2.3.7) must be extrapolated in accordance with

2.2.3.2.3.7.2 for precision systems. Likewise, Encoded Latitude must be updated in
accordance with 2.2.3.2.3.7.3 for non-precision systems. Any change in the
Encoded Latitude shall be reflected in the Encoded Latitude subfield of the next
scheduled Airborne Position Message transmission provided that the change occurs
at least X milliseconds prior to the next scheduled Airborne Position Message
transmission. The time X, shall be dependent upon the NACP (see Table 2-71,
2.2.3.2.7.2.7 and 2.2.8.2.12) provided to the transmission device as follows:
transmission buffer within the 200 millisecond time frame allocated updating
the Encoded Latitude. That is, that no additional time can be added to the
200 milliseconds already allocated
f. Encoded Longitude (specified in 2.2.3.2.3.8) must be extrapolated in accordance

with 2.2.3.2.3.8.2 for precision systems. Likewise, Encoded Longitude must be
updated in accordance with 2.2.3.2.3.8.3 for non-precision systems. Any change in
the Encoded Longitude shall be reflected in the Encoded Longitude subfield of the
next scheduled Airborne Position Message transmission provided that the change
occurs at least X milliseconds prior to the next scheduled Airborne Position
Message transmission. The time X, shall be dependent upon the NACP (see Table
2-71, 2.2.3.2.7.2.7 and 2.2.8.2.12) provided to the transmission device as follows:
200 milliseconds already allocated
2.2.5.2.2 Surface Position Message Latency

The ADS-B Transmission Device Message Processor function shall update the Surface
Position Message data fields specified in 2.2.3.2.4 as follows:
a. Type information may change due to changes in the precision, quality, or integrity of
received navigation information. As such, any change in the TYPE information
identified in 2.2.3.2.4.1 shall be reflected in the Type subfield of the next scheduled
Surface Position Message transmission provided that the change occurs and is
20xx, RTCA, Inc.

184
detected at least 100 milliseconds prior to the next scheduled Surface Position
Message transmission.
b. Any change in Movement (i.e., Ground Speed) identified in 2.2.3.2.4.2 shall be

reflected in the Movement subfield of the next scheduled Surface Position Message
transmission provided that the change occurs and is detected at least 100 milliseconds
prior to the next scheduled Surface Position Message transmission.
c. Any change in Ground Track identified in 2.2.3.2.4.3 and 2.2.3.2.4.4 shall be

reflected in the appropriate Ground Track subfields of the next scheduled Surface
least 100 milliseconds prior to the next scheduled Surface Position Message
transmission.
d. CPR Format changes at 0.2 second intervals as specified in 2.2.3.2.4.6. A change in

the CPR Format shall be reflected in the CPR Format subfield of the next scheduled
Surface Position Message transmission provided that the change occurs at least X
milliseconds prior to the next scheduled Surface Position Message transmission. The
time X, shall be dependent upon the NACP (see Table 2-71, 2.2.3.2.7.2.7 and
2.2.8.2.12) provided to the transmission device as follows:
transmission buffer within the 200 millisecond time frame allocated to the
CPR Format changes. That is that no additional time can be added to the
e. Encoded Latitude (specified in 2.2.3.2.4.7) must be extrapolated in accordance with

2.2.3.2.4.7.2 for precision systems. Likewise, Encoded Latitude must be updated in
accordance with 2.2.3.2.4.7.3 for non-precision systems. Any change in the
Encoded Latitude shall be reflected in the Encoded Latitude subfield of the next
scheduled Surface Position Message transmission provided that the change occurs at
least X milliseconds prior to the next scheduled Surface Position Message
transmission. The time X, shall be dependent upon the NACP (see Table 2-71,
2.2.3.2.7.2.7 and 2.2.8.2.12) provided to the transmission device as follows:
f. Encoded Longitude (specified in 2.2.3.2.4.8) must be extrapolated in accordance

with 2.2.3.2.4.8.2 for precision systems. Likewise, Encoded Latitude must be
updated in accordance with 2.2.3.2.4.8.3 for non-precision systems. Any change in
the Encoded Longitude shall be reflected in the Encoded Longitude subfield of the
next scheduled Surface Position Message transmission provided that the change
20xx, RTCA, Inc.

185
occurs at least X milliseconds prior to the next scheduled Surface Position

Message transmission. The time X, shall be dependent upon the NACP (see Table
2-71, 2.2.3.2.7.2.7 and 2.2.8.2.12) provided to the transmission device as follows:
the Encoded Longitude. That is, that no additional time can be added to the
2.2.5.2.3 Aircraft Identification Message Latency

The ADS-B Transmission Device Message Processor function shall update the Aircraft
Identification Message data fields specified in 2.2.3.2.5 as follows:
a. Type information for the Aircraft Identification Message should be fixed and
therefore not change. However, if changes are imposed, any such change in the
TYPE information identified in 2.2.3.2.5.1 shall be reflected in the Type subfield of
the Aircraft Identification message once the data has been stable (i.e., no changes) for
a period of 4 seconds.
b. ADS-B Emitter Category information for the Aircraft Identification Message should
be fixed and therefore not change. However, if changes are imposed, any such
change in the ADS-B Emitter Category information identified in 2.2.3.2.5.2 shall be
reflected in the ADS-B Emitter Category subfield of the Aircraft Identification
message once the data has been stable (i.e., no changes) for a period of 4 seconds.
c. Any change in Character information identified in 2.2.3.2.5.3 shall be reflected in

the appropriate Character subfields of the Aircraft Identification message once the
data has been stable (i.e., no changes) for a period of 4 seconds.
2.2.5.2.4 Airborne Velocity Message - Subtype=1 Latency

Velocity Message - Subtype=1 data fields specified in 2.2.3.2.6.1 as follows:
Any change in the data used to structure the following subfields of the Airborne Velocity
Message - Subtype=1 shall be reflected in the affected subfield of the next scheduled
Airborne Velocity Message - Subtype=1 provided that the change occurs and is detected
at least 100 milliseconds prior to the next scheduled Airborne Velocity Message -
Subtype=1 transmission:
(1). TYPE (2.2.3.2.6.1.1)
(2). Subtype (2.2.3.2.6.1.2)
(3). Intent Change Flag (2.2.3.2.6.1.3)
(4). NACV -- (2.2.3.2.6.1.5)
20xx, RTCA, Inc.

186
(5). East/West Direction Bit and East/West Velocity -- (2.2.3.2.6.1.6 and

2.2.3.2.6.1.7)
(6). North/South Direction Bit and North/South Velocity -- (2.2.3.2.6.1.8 and
2.2.3.2.6.1.9)
(7). Vertical Rate (2.2.3.2.6.1.10 through 2.2.3.2.6.1.12)
(8). Difference From Barometric Altitude (2.2.3.2.6.1.14 and 2.2.3.2.6.1.15)

- Subtype=2 message shall be reflected in the affected subfield of the next scheduled
Airborne Velocity - Subtype=2 message provided that the change occurs and is detected
at least 100 milliseconds prior to the next scheduled Airborne Velocity - Subtype=2
message transmission:
(1). TYPE (2.2.3.2.6.2.1)
(2). Subtype (2.2.3.2.6.2.2)
(4). NACV -- (2.2.3.2.6.2.5)
(5). East/West Direction Bit and East/West Velocity -- (2.2.3.2.6.2.6 and
2.2.3.2.6.2.7)
(6). North/South Direction Bit and North/South Velocity -- (2.2.3.2.6.2.8 and
2.2.3.2.6.2.9)

(1). TYPE (2.2.3.2.6.3.1)
(2). Subtype (2.2.3.2.6.3.2)
(4). NACV -- (2.2.3.2.6.3.5)
(5). Heading -- (2.2.3.2.6.3.6 through 2.2.3.2.6.3.7)
(6). Airspeed -- (2.2.3.2.6.3.8 and 2.2.3.2.6.3.9)
20xx, RTCA, Inc.

187


(1). TYPE (2.2.3.2.6.4.1)
(2). Subtype (2.2.3.2.6.4.2)
(3). Intent Change Flag (s2.2.3.2.6.4.3)
(4). NACV -- (2.2.3.2.6.4.5)
(5). Heading -- (2.2.3.2.6.4.6 through 2.2.3.2.6.4.7)
(6). Airspeed -- (2.2.3.2.6.4.8 and 2.2.3.2.6.4.9)
(8). Difference From Barometric Altitude - (2.2.3.2.6.4.14 and 2.2.3.2.6.4.15)
2.2.5.2.8 Airborne Velocity Message - Subtype 5 Latency

RESERVED FOR FUTURE APPLICATION.

RESERVED FOR FUTURE APPLICATION

2.2.5.2.11 Target State and Status Message Latency

The ADS-B Transmission Device Message Processor function shall update the Target
State and Status Message data fields specified in 2.2.3.2.7.1 as follows:
Any change in the data used to structure the following subfields of the Target State and
Status Message shall be reflected in the affected subfield of the next scheduled Target
State and Status Message provided that the change occurs and is detected at least 100
milliseconds prior to the next scheduled Target State Message transmission.
(1). TYPE (2.2.3.2.7.1.1)
(2). Subtype (2.2.3.2.7.1.2)
20xx, RTCA, Inc.

188
(3). SIL Supplement (2.2.3.2.7.1.3.1)

(4). Selected Altitude Type (2.2.3.2.7.1.3.2)
(5). MCP/FCU Selected Altitude or FMS Selected Altitude (2.2.3.2.7.1.3.3)
(6). Barometric Pressure Setting (Minus 800 millibars) (2.2.3.2.7.1.3.4)
(7). Selected Heading Status (2.2.3.2.7.1.3.5)
(8). Selected Heading Sign (2.2.3.2.7.1.3.6)
(9). Selected Heading (2.2.3.2.7.1.3.7)
(10). NACP (2.2.3.2.7.1.3.8)
(11). NICBARO (2.2.3.2.7.1.3.9)
(12). SIL (2.2.3.2.7.1.3.10)
(13). Status of MCP/FCU Mode Bits (2.2.3.2.7.1.3.11)
(14). Autopilot Engaged (2.2.3.2.7.1.3.12)
(15). VNAV Mode Engaged (2.2.3.2.7.1.3.13)
(16). Altitude Hold Mode (2.2.3.2.7.1.3.14)
(17). Approach Mode (2.2.3.2.7.1.3.16)
(18). TCAS Operational (2.2.3.2.7.1.3.17)
Note: In the future, the ADS-B system may need to be capable of processing Target
State and Status Messages that are independent of each other, as identified with
different Subtype codes. Likewise, the latency requirements for each message
Subtype will need to be satisfied in an independent manner.
2.2.5.2.12 Aircraft Operational Status Message Latency

Operational Status Message data fields specified in 2.2.3.2.7.2 as follows:
Any change in the data used to structure the following subfields of the Aircraft
Operational Status Message shall be reflected in the affected subfield of the next
scheduled Aircraft Operational Status Message provided that the change occurs and is
detected at least 100 milliseconds prior to the next scheduled Aircraft Operational Status
Message transmission:
(1). TYPE Code (2.2.3.2.7.2.1)
(2). Subtype Code (2.2.3.2.7.2.2)
(3). Capability Class (2.2.3.2.7.2.3 through 2.2.3.2.7.2.3.11)
(4). Operational Mode (2.2.3.2.7.2.4 through 2.2.3.2.7.2.4.7)
(5). Version Number (2.2.3.2.7.2.5)
(6). NIC Supplement-A (2.2.3.2.7.2.6)
(7). NACP (2.2.3.2.7.2.7)
(8). Geometric Vertical Accuracy (2.2.3.2.7.2.8)
20xx, RTCA, Inc.

189
(9). SIL (2.2.3.2.7.2.9)

(10). NICBARO (2.2.3.2.7.2.10)
(11). Aircraft Length and Width Codes (2.2.3.2.7.2.11)
(12). Track Angle/Heading (2.2.3.2.7.2.12)
(13). Horizontal Reference Direction (HRD) (2.2.3.2.7.2.13)
(14). SIL Supplement (2.2.3.2.7.2.14)
2.2.5.2.13 TYPE 23 TEST Message Latency

The ADS-B Transmission Device Message Processor shall process Vendor Specified
data for ADS-B Test messages specified in 2.2.3.2.7.3 with any change in data being
reflected in the next scheduled TYPE 23 Test Event-Driven Message provided that the
change occurs and is detected at least 100 milliseconds prior to the next scheduled TYPE
23 Test Event-Driven Message transmission.
2.2.5.2.14 TYPE 24 Message Latency

Reserved for Future Application.



Reserved for future use of Trajectory Change.
2.2.5.2.18 Aircraft Status Message Subtype=1 Latency

Status Message Subtype=1 data fields specified in 2.2.3.2.7.8.1 as follows:
Any change in the data used to structure the following subfields of the Aircraft Status
Message Subtype=1 (Emergency/Priority Status) shall be reflected in the affected
subfield of the next scheduled Aircraft Status Message Subtype=1 provided that the
change occurs and is detected at least 100 milliseconds prior to the next scheduled
Aircraft Status Message Subtype=1 transmission.
(1). TYPE (2.2.3.2.6.1.1)
(2). Subtype (2.2.3.2.6.1.2)
(3). EMERGENCY/PRIORITY STATUS FLAG (2.2.3.2.7.1.3.12)
20xx, RTCA, Inc.

190
2.2.5.2.19 Aircraft Status Message Subtype=2 Latency

Status Message Subtype=2 data fields specified in 2.2.3.2.7.8.2 as follows:
Any change in the data used to structure the following subfields of the Aircraft Status
Message Subtype=2 (TCAS Resolution Advisory Broadcast) shall be reflected in the
affected subfield of the next scheduled Aircraft Status Message Subtype=2 provided
that the change occurs and is detected at least 100 milliseconds prior to the next
scheduled Aircraft Status Message Subtype=2 transmission.
(1). TYPE (2.2.3.2.6.1.1)
(2). Subtype (2.2.3.2.6.1.2)
(The following data items are defined in ICAO Annex 10, Vol IV, 4.3.8.4.2.2)
(3). ACTIVE RESOLUTION ADVISORIES
(4). RACs RECORD
(5). RA TERMINATED
(6). MULTIPLE THREAT ENCOUNTER
(7). THREAT TYPE INDICATOR
(8). THREAT IDENTITY DATA
2.2.5.3 ADS-B Transmission Device Source Selection

When more than one position source is provided to the ADS-B transmitter, the
transmitter shall select a single source to provide position, velocity, and quality metrics.
Heading on the surface is an exception to this.
Notes:
1. The source selection logic should be designed to prevent the selection from
alternating between valid sources. One acceptable way to ensure this is to allow the
source selection to switch sources only after an alternate source has consistently
exceeded the performance of the currently selected source for several seconds.
2. Source selection logic may include criteria specific to the sources available on the
aircraft. In general, sources that support higher integrity should be selected over
sources that support lower integrity. When selecting among equivalent integrity
sources, the source with the smallest Radius of Containment should be selected.
2.2.6 ADS-B Receiving Device Message Processor Characteristics

To provide maximum flexibility in user application implementation of ADS-B
information, ADS-B Receiving Devices are categorized into two major functional types,
which are illustrated in Figure 2-16 and specified in the following subparagraphs.
20xx, RTCA, Inc.

191
Note: Figure 2-19 provides additional detail in regards to ADS-B Message and Report
general data flow.
RF ADS-B
MESSAGE RECEPTION
120 FUNCTION
88
MESSAGE DATA
REPORT TYPE 1: SUBSET REPORTS
REPORT ASSEMBLY
CONTROL TYPE 2: CAPABLE OF FULL
FUNCTION
INTERFACE REPORTS
REPORTS
APPLICATIONS
Figure 2-16: ADS-B Receiver / Report Assembly Functional Types
a. The ADS-B Message processing function begins with the ADS-B Message Reception
Function receiving the transmitted message and then performing the necessary
processing to deliver Message Data to the Report Assembly Function.
b. TYPE 1 TYPE 1 ADS-B Report Assembly subsystems are those that receive ADS-
B Messages and produce application-specific subsets of ADS-B reports. As such, the
Type 1 ADS-B Report Assembly subsystems may be customized to the particular
applications using ADS-B reports. In addition, Type 1 ADS-B Report Assembly
subsystems may be controlled by an external entity to produce installation-defined
subsets of the reports that those subsystems are capable of producing.
c. TYPE 2 TYPE 2 ADS-B Report Assembly subsystems are those that receive ADS-
B Messages and are capable of producing complete ADS-B reports in accordance
with the applicable ADS-B equipment class requirements. Type 2 Report Assembly
subsystems may be controlled by an external entity to produce installation-defined
subsets of the reports that those subsystems are capable of producing.
2.2.6.1 ADS-B Message Reception Function Requirements

a. The ADS-B Message Reception Function shall properly decode valid ADS-B
transmitted messages while ignoring other similar Mode-S transmissions.
b. The ADS-B Message Reception Function shall decode ADS-B transmitted messages
in accordance with the requirements provided in 2.2.4.3.4.7 of this document.
The ADS-B Message Reception Function shall receive and decode ADS-B messages that
are transmitted in Version Two (2) message formats as defined by 2.2.3.2 and its
subparagraphs and also Airborne Position, Surface Position, Airborne Velocity, Aircraft
Status, and Aircraft Operational Status, Identification and Category Messages that are
20xx, RTCA, Inc.

192
transmitted in Version Zero (0) and Version One (1) message formats as defined by
Appendix N, Section N.2, and its subparagraphs.
The version determined from the decoding of the Version Number subfield of the
Aircraft Operational Status Message (2.2.3.2.7.2.5) shall be retained and associated with
the specific target. This Version Number shall then be used for determining the
applicable message formats to be applied for the decoding of all subsequent 1090 MHz
ADS-B Messages received from that target.
Notes:
1. A summary of the RTCA DO-260 compliant, ADS-B Version Zero (0) and RTCA DO-
260A compliant ADS-B Version One (1) Message formats that must be received and
processed by Version Two (2) 1090 MHz ADS-B Receiving Subsystems is provided in
Appendix N.
2. The Version Two (2) and Version One (1) Aircraft Operational Status Message
format includes an explicit Version Number subfield (ME bits 41 43). For an
ADS-B Version Zero (0) Aircraft Operational Status Message, these same bits were
unassigned and were required to be set to a value of ZERO (binary 000). Thus, a
Version Two (2) and Version One (1) ADS-B Receiving Subsystem will decode ME
bits 41 43 received from a 1090 MHz ADS-B Transmitting Subsystem compliant
with RTCA DO-260 to indicate a Version Number of Zero (0).
2.2.6.1.1 ADS-B Message Reception Function Output Message Structure Requirements

All ADS-B Messages are received in the general format provided in Figure 2-2 and
specified in 2.2.3.2.
Each ADS-B Message received shall be structured into the baseline OUTPUT
MESSAGE shown in Figure 2-17 for delivery to the user interface or the Report
Assembly function:
ADS-B Output Message Format Structure
Transmitted
Message 1 --- 5 9 ---------- 32 33 ----------------------------- 88
BIT #
Output
Message 1 --- 5 6 ---------- 29 30 ----------------------------- 85
BIT #
FIELD DF AA ME
NAME [5] [24] [56]
MSB LSB MSB LSB MSB LSB
Note: [#] Provided in the FIELD indicates the number of bits in the field.
Figure 2-17: ADS-B Output Message Format Structure
20xx, RTCA, Inc.

193
2.2.6.1.2 ADS-B and TIS-B Message Reception Function Output Message Delivery
Requirements
Figure 2-18 illustrates the transmitted message receipt capabilities and the OUTPUT
MESSAGE delivery requirements, which are specified in the following subparagraphs:
treceive trecover treceive
t2 t3
120 120
microseconds microseconds
max = 8
Transmitted Recovery Transmitted

Message Reception Time Message Reception
Output Message
t0 Delivery
2.0 milliseconds
(maximum)
t1 t4
tdelivery
Figure 2-18: ADS-B and TIS-B Message Reception Function Output Message Delivery
The ADS-B and TIS-B Message Reception Function shall deliver All OUTPUT
MESSAGES to the user interface or the Report Assembly function within 2.0
milliseconds of the receipt of the last message bit of the transmitted message.
2.2.7 ADS-B Message Processor Characteristics
2.2.7.1 ADS-B Receiving Device Message Reception

The ADS-B Receiver shall decode all valid ADS-B transmitted messages and structure
the information from such messages into the appropriate ADS-B Reports identified in
subsequent sections of this document. The structured reports shall then be made
available to the appropriate user application as needed.
Future versions of these MOPS are expected to maintain backward compatibility with
RTCA DO-260B. Messages originating from 1090 MHz ADS-B Transmitting
Subsystems reporting a MOPS Version Number value that is indicated in Table 2-69 as
Reserved are to be considered valid. However, all message types and all subfields
within messages that are currently Unassigned, or are indicated as being Reserved by
these MOPS, shall be ignored and not used for ADS-B Report Generation.
2.2.7.1.1 Receipt of TYPE Code Equal to ZERO

An ADS-B Message containing a TYPE Code of ZERO (binary 0 0000) can only be used
to update the altitude data of an aircraft that is already being tracked by the entity
receiving the altitude data in a TYPE ZERO ADS-B Message.
If an ADS-B Message with TYPE Code equal to ZERO is received, it should be checked
to see if altitude data is present and then process the altitude data as follows:
20xx, RTCA, Inc.

194
a. If altitude data is not present, the message shall be discarded.
b. If altitude data is present, it may be used to update altitude as needed.
Note: For TCAS systems, this could be an aircraft that was being maintained via
hybrid surveillance when the position data input failed. In this case, altitude
only could be used for a short period of time. Interrogation would have to begin
at the update rate for that track to ensure update of range and bearing
information on the TCAS display.
2.2.8 ADS-B Report Characteristics

The intent of the following subparagraphs is to provide an example coding of each type
of ADS-B report. Implementations may use alternative report structures and coding of
the ADS-B reports. However, the contents of each Report Type, as specified in Table 2-
82 shall include, as a minimum, the data parameters as specified in the following
subparagaphs.
Note: This requirement describes the Report Type structure, not the contents of each
report that can contain a subset of the complete allowed parameters.
2.2.8.1 ADS-B State Vector Report Characteristics

Table 2-81 and the subsequent subparagraphs identify the data structure for all ADS-B
State Vector Reports generated for each ADS-B vehicle being reported.
The Report Assembly Function shall be compatible with the current and prior versions of
the relevant 1090 MHz ADS-B Messages (e.g., Airborne Position, Surface Position,
Airborne Velocity) that are used as the basis for generating State Vector Reports. The
relevant Version Two (2) messages are identified below and the relevant Version Zero (0)
messages, conformant to RTCA DO-260, including Change 1, and Version One (1)
messages, conformant to DO-260A including Change 1 and Change 2, and their required
use for ADS-B State Vector Report generation are defined in Appendix N, Section N.3.
The intent of Table 2-81 is to illustrate the structure of all Items (i.e., parameters)
required to be reported in an ADS-B State Vector Report. The exact structure of the data
indicated in columns 10 and 11 is provided as a guideline or one possible method of
satisfying the report structure. Implementers may choose to organize the data in another
format; however, delivery to a user interface or application of all Items in Table 2-81
shall be consistent with the range, resolution, and units indicated in column 7, 8 and 9 of
Table 2-81 respectively. If data is not available to support a field that is delivered to an
application, then the data provided to the application shall be set to ALL ZEROs. Those
requirements in 2.2.8.1.1 to 2.2.8.1.22 below that relate to specific data structure
details (byte numbers, and bit numbers within the bytes) shall only apply to equipment
that uses the sample report data structure shown in columns 10-11 of Table 2-81.
Note: Table 2-81 is structured such that column 1, 2, and 6 through 11, pertain to the
State Vector Report elements and how such elements should be structured into
the report. Columns 3 through 5 provide information on where the appropriate
data can be located in the ADS-B Messages for each of the Report elements.
20xx, RTCA, Inc.

20xx, RTCA, Inc.
Table 2-81: ADS-B State Vector Data Elements - Source Data Mapping To Report Structure
Table 2-81: ADS-B State Vector Data Elements Source Data Mapping To Report Structure
Column REPORT STRUCTURE MESSAGE STRUCTURE RELEVANT REPORT STRUCTURE RELEVANT
# 1 2 3 4 5 6 7 8 9 10 11
Item Received ME Message # of Data
Parameter / Contents Notes Range Resolution Units Data Structure
# Message Structure Field Bits Field Bits Bits Byte #
Report Type and MddL Mddd dddddddd
0a, 0b 2 N/A N/A 15 24 N/A N/A discrete 0 -2
Structure Identification ddddddL
0c Validity Flags N/A N/A N/A 16 N/A N/A discrete dddddddd dddddddd 3-4
Airborne Position - AA N/A 9 - 32
Mddddddd dddddddd
1 Participant Address Surface Position - AA N/A 9 32 24 N/A N/A discrete 5-7
dddddddL
Airborne Velocity AA N/A 9 - 32
Aircraft ID & Category
68 38 40
Emitter Category
2 Address Qualifier 8 N/A N/A discrete xxxxxMdL 8
All Messages with DF=18
N/A 6-8
CF
Report Time of Airborne Position Time 21 53 Mddddddd dddddddL
0.0078125
3 Applicability (Position 3 Surface Position Time 21 53 48 511.9921875 seconds Mddddddd dddddddL 9 - 14
(1/128)
and Velocity) Airborne Velocity N/A N/A Mddddddd dddddddL
Airborne Position 23 - 39 55 - 71
Encoded Latitude SMdddddd dddddddd
4
(WGS-84)
24 180 0.0000215 degrees
dddddddL
15 - 17
Surface Position 23 - 39 55 71
Airborne Position 40 - 56 72 - 88
Encoded Longitude SMdddddd dddddddd
5
(WGS-84)
24 180 0.0000215 degrees
dddddddL
18 - 20
Surface Position 40 - 56 72 88
Airborne Position TYPE, & 1 - 5, & 33 - 37
Altitude 9 - 20 41 52
Altitude, Geometric SMdddddd dddddddd
6 4 Airborne Velocity - Diff. from 24 131072 0.015625 feet 21 23
(WGS-84) dddddddL
Baro Alt sign & 49 81
Diff. from Baro. Alt. 50 - 56 82 - 88
Airborne Velocity N/S 25 57
7 North/South Velocity 4 Direction & 16 4096 0.125 knots SMdddddd dddddddL 24 25
N/S Velocity 26 - 35 58 67
Airborne Velocity - E/W 14 46
8 East/West Velocity 4 Direction & 16 4096 0.125 knots SMdddddd dddddddL 26 27
E/W Velocity 15 - 24 47 56
Ground Speed while on
9 5 Surface Position Movement 6 - 12 38 44 8 N/A N/A discrete MddddddL 28
the Surface
Heading while on the
10 5 Surface Position Heading 14 - 20 46 52 8 180 1.40625 degrees SMdddddL 29
Surface
Altitude, Barometric Airborne Position TYPE, & 1-5 33 37 SMdddddd dddddddd
11 4 24 131072 0.015625 feet 30 32
(Pressure Altitude) Altitude 9 - 20 41 52 dddddddL
Vertical Rate, Airborne Velocity
12 Geometric/Barometric 4 Vert. Rate Source, 36 68 16 32768 1.0 ft./min. SMdddddd dddddddL 33 34
(WGS-84) Vert. Rate Sign & 37 69
195
196
Table 2-81: ADS-B State Vector Data Elements Source Data Mapping To Report Structure
# 1 2 3 4 5 6 7 8 9 10 11
Item Received ME Message # of Data
Parameter / Contents Notes Range Resolution Units Data Structure
# Message Structure Field Bits Field Bits Bits Byte #
Vert. Rate 38 - 46 70 78
Airborne Position Type Code 15 33 37
& NIC Supplement-B 8 40
Operationsl Status -
Navigation Integrity NIC Supplement-A 44 76
13 8 N/A N/A discrete xxxMdddL 35
Category (NIC) Surface Position Type Code 15 33 37
& Operational Status -
NIC Supplement-A and 44, 76,
NIC Supplement-C 20 52
Airborne Position
23 39 55 71
Estimated Latitude Encoded Latitude SMdddddd dddddddd
14 6 24 180 0.0000215 degrees 36 38
(WGS-84) Surface Position dddddddL
23 - 39 55 71
Encoded Latitude
Airborne Position
40 - 56 72 - 88
Estimated Longitude Encoded Longitude SMdddddd dddddddd
15 6 24 180 0.0000215 degrees 39 41
(WGS-84) Surface Position dddddddL
40 - 56 72 88
Encoded Longitude
Airborne Velocity N/S 25 57
Estimated North/South
16 6 Direction & 16 4,096 0.125 knots SMdddddd dddddddL 42 43
Velocity
N/S Velocity 26 - 35 58 67
Airborne Velocity - E/W 14 46
Estimated East/West
17 6 Direction & 16 4,096 0.125 knots SMdddddd dddddddL 44 45
Velocity
E/W Velocity 15 - 24 47 56
Airborne Position
Surveillance Status 67 38 39 4
Surveillance
18 N/A N/A discrete dddd dddd 46
Status/Discretes
Airborne Velocity 9 9 4
Intent Change Flag
19 Report Mode N/A N/A N/A 8 N/A N/A discrete xxxxxxML 47
TOTAL BYTES 48
Notes:
1. In the Data Structure column (i.e., column 10), S indicates the sign-bit, M indicates the Most Significant Bit of the data field, d indicates data bits in
the field, L indicates the Least Significant Bit of the data field, 0 indicates the bit is to always be set to a value of zero (0) and x indicates Dont Care
bits in the data field.
2. The Report Type Identifier is used to identify the type of ADS-B Report being generated as specified in 2.2.8.1.1.1.
3. The Time of Applicability is actually a grouping of 3 individual parameters as specified in 2.2.8.1.4.
4. Parameters annotated with Note 4 are only present in the State Vector Report when the aircraft is airborne
20xx, RTCA, Inc.

20xx, RTCA, Inc.
5. Parameters annotated with Note 5 are only present in the State Vector Report with the aircraft is on the airport surface
6. Estimated values may be either an actual value from a received message, if available, or a calculated value such as produced by a surveillance tracker algorithm.
For example it is possible for a surveillance tracker to produce an updated estimate of the targets horizontal position based on just the receipt of a new velocity
message.
197
198
2.2.8.1.1 State Vector Report Type and Structure Identification and Validity Flags
2.2.8.1.1.1 State Vector Report Type and Structure Identification

The Report Type is used to identify the type of ADS-B Report being generated by the
report generation function and being provided to the User Application. The Report Type
is a 4-bit field and shall be provided in the most significant nibble (i.e., bits 7 - 4) of the
first byte (i.e., byte 0) of the Report. The Report Type formats and maximum number
of bytes to be contained in each report are identified in Table 2-82.
Table 2-82: ADS-B Report Type Coding

Maximum
Coding
Number
Report Type
of Bytes
(binary) (decimal)
in Report
0000 0 Undefined Report Type or no Report Available 1
0001 1 State Vector Report for ALL Class A Equipment 48
Mode-Status Report for Class A1S, A1, A2, and A3 35
0010 2
Equipment
0011 3 Reserved for Version ONE (1) ADS-B Target State Report 22
0100 4 Air Reference Velocity Report for Class A1S, A1, A2
14
and A3 equipment
ADS-B Target State and Status Report for Class A2 and
0101 5 A3 Equipment (Optional for Equipment Classes A1S and 22
A1).
Reserved for Trajectory Change Report for Class A2
0110 6
and A3 equipment
0111
through Not Assigned (Reserved for Future Assignment)
1111
The Report Structure field is used to indicate the exact data parameters identified in Table
2-81 that are being provided in the State Vector report and is intended to provide a
methodology for the report processor to structure shorter reports when data for some
parameters or groups of related parameters are not available. In order to provide the
capability to provide shorter State Vector reports the following basic conventions shall
be adhered to:
a. Any given data parameter to be used in the report shall use the designated number of
bytes and format as designated in Table 2-81.
b. Whenever a data parameter identified in Table 2-81, or a required grouping of data

parameters as identified in Table 2-83, is not provided in the report, then it is
permissible to concatenate the next parameter to be included into the report
immediately following the inclusion of the previous reported parameter. This feature
shall be used accommodate the reporting of the different sets of required parameters,
such as for when the aircraft is in the airborne condition versus on the airport surface
as indicated in Table 2-81.
20xx, RTCA, Inc.

199
c. Each parameter of the State Vector report identified in Table 2-81 shall be properly
declared in the Report Structure field as detailed in the following paragraphs and
Table 2-83.
Note: Implementation of the methodology just provided is realizable and controllable

due to the fact that the exact length of each report parameter is specified in Table
2-81 and the Report Structure field identifies exactly which parameters are
included in the report. Therefore, the report user can easily re-construct the
length and general format of the report.
The Report Structure is a 20-bit field and shall be provided in the least significant nibble
(i.e., bits 3 - 0) of the first byte (i.e., byte 0) and continuing into bytes 1 and 2 of the
Report. The Report Structure format is specified in Table 2-83 where each bit is
associated with a particular data parameter, or group of data parameters, of the State
Vector Report. If the bit is set to ONE (1), then the data parameter, or group of identified
data parameters, is considered to be available and shall be transmitted in the report.
Otherwise, the data parameter, or group of identified data parameters, is considered to not
be available and shall not be transmitted in the report. Note that Table 2-83 does not
address the Report Type and Structure Identification parameter, the Validity Flags
parameter, nor the Participant Address parameter and the Address Qualifier, since these
four parameters shall be included in the State Vector Report. Also, certain of the
other State Vector data parameters are required to be reported, as specified in
2.2.9, even though bits have been allocated in the report structure field as shown in
Table 2-83.
Table 2-83: ADS-B State Vector Report Structure Coding

Byte # Bit # State Vector Data Parameter(s) Number of
to be Reported Bytes
3 Time of Applicability for Estimated 2
Position/Velocity
0 2 Position Time of Applicability 2
1 Velocity Time of Applicability 2
0 Latitude (WGS-84) & Longitude (WGS-84) 7
7 Altitude, Geometric (WGS-84) 4
6 North/South Velocity & East/West Velocity 5
5 Ground Speed while on the Surface 2
4 Heading while on the Surface 2
1
3 Altimeter, Barometric 4
2 Vertical Rate Geometric/Baro. 3
1 Navigation Integrity Category 1
0 Estimated Latitude 3
7 Estimated Longitude 3
6 Estimated North/South Velocity 2
5 Estimated East/West Velocity 2
4 Surveillance Status/Discretes 1
2
3 Report Mode 1
2 Reserved for Future Expansion
20xx, RTCA, Inc.

200
2.2.8.1.1.2 State Vector Report Validity Flags

Validity Flags for data provided in the State Vector Report shall be indicated in bytes #3
and #4 of the State Vector Report as shown for item 0c in Table 2-81. The State
Vector Report elements that require validity flags are identified in Table 2-84. Table 2-
84 identifies the byte and bit that shall be used as a flag for each element that requires a
validity flag. Each validity flag bit shall be set to ONE (1) to indicate that the
corresponding State Vector Report Element data is valid. If such data is not valid, then
the corresponding validity flag bit shall be set to ZERO (0).
20xx, RTCA, Inc.

201
Table 2-84: ADS-B State Vector Report Validity Flag Requirements

SV
State Vector Report Validity Flag Bit
Report Validity Flag Bit Required?
Element Assignment
Item #
0a Report Type No Byte # Bit #
0b Structure Identification No
0c Validity Flags No
1 Participant Address No
2 Address Qualifier No
3 Report Time of Applicability No
Latitude Yes 7
4 (WGS-84) (This validity flag bit is for Horizontal Position Valid) 3
(MSB)
Longitude Yes
5 (WGS-84) (This validity flag bit is for Horizontal Position Valid)
3 7
Altitude, Geometric Yes
6 (WGS-84) (This bit is validity flag bit for Geometric Altitude Valid)
3 6
Yes (This bit is validity flag bit for Airborne Horizontal
7 North/South Velocity
Velocity Valid)
3 5
Yes (This bit is validity flag bit for Airborne Horizontal
8 East/West Velocity
Velocity Valid)
3 5
Ground Speed while on the Yes (This bit is validity flag bit for Surface Ground Speed
9 Surface Valid)
3 4
10 Heading while on the Surface Yes (This bit is validity flag bit for Surface HeadingValid) 3 3
Altitude, Barometric Yes (This bit is validity flag bit for Barometric Altitude
11 (Pressure Altitude) Valid)
3 2
Vertical Rate, Geometric Yes (This bit is validity flag bit for Geometric Vertical Rate
12a (WGS-84) Valid)
3 1
Vertical Rate, Barometric Yes (This bit is validity flag bit for Barometric Vertical Rate
12b (WGS-84) Valid)
3 0
Navigation Integrity Category No
13 (NIC)
Yes (This validity flag bit is for Estimated Horizontal
Position Valid -- If for some reason an estimation cannot be
7
14 Estimated Latitude (WGS-84) made of the horizontal position at the TOA of the report, then 4
this could be indicated by zeroing the validity flag for the (MSB)
estimated horizontal position.)
Position Valid -- If for some reason an estimation cannot be
15 Estimated Longitude (WGS-84) made of the horizontal position at the TOA of the report, then 4 7
this could be indicated by zeroing the validity flag for the
estimated horizontal position.)
16 Estimated North/South Velocity Velocity Valid -- It may be possible to estimate velocity at 4 6
some time after the TOA of the velocity message.)
17 Estimated East/West Velocity Velocity Valid -- It may be possible to estimate velocity at 4 6
some time after the TOA of the velocity message.)
18 Surveillance Status/Discretes No
19 Report Mode No
2.2.8.1.2 Participant Address

The Participant Address shall be encoded as specified in 2.2.3.2.1.5.
20xx, RTCA, Inc.

202
2.2.8.1.3 Address Qualifier

The Address Qualifier is used to indicate the type of Participant Address (2.2.3.2.1.5)
being reported. The 3 least significant bits of the one byte field (byte 8 of the Report
Field) are used to convey the Address Qualifier information. The Address Qualifier
subfield shall be coded as shown in Table 2-85.
Table 2-85: Address Qualifier Coding

Coding ADS-B Emitter Cateogry Set
Meaning
(MdL) (see Notes 1 & 2)
ICAO address being reported as Participant
000 See Note 3
Address for an unknown emitter category
Non-ICAO address being reported as
001 Participant Address for an unknown emitter See Note 3
category
010 A or B
Address for an Aircraft
011 A or B
Participant Address for an Aircraft
100 Address is for a Surface Vehicle, a Fixed C
Ground or Tethered Obstruction
101 Participant Address is for a Surface Vehicle, C
a Fixed Ground or Tethered Obstruction
110 Reserved N/A
111 Reserved N/A

1. All transponder-based based 1090 MHz ADS-B systems are required to use an ICAO
24-bit address. Certain types of non-transponder-based 1090 MHz ADS-B systems
may under certain conditions be permitted to broadcast an address other than an
ICAO 24-bit address. ADS-B Messages received from Non-Transponder Devices
transmitting with DF=18 and CF=1 indicate that a non-ICAO Address is being used
(see Figure 2-2).
2. The Emitter Category associated with the Participant Address is to be obtained from
the ADS-B Emitter Category subfield (2.2.3.2.5.2) of the ADS-B Aircraft
Identification and Category Message.
3. An Address Qualifier Code of 000 or 001 is to be reported if the value from the
ADS-B Emitter Category subfield indicates No ADS-B Emitter Category
Information, or if an ADS-B Aircraft Identification and Category Message has not
been received.
2.2.8.1.4 Report Time of Applicability

Since separate messages are used for position and velocity, the Time of Applicability is
reported individually for the position related report parameters and the velocity related
report parameters. Also the State Vector Report may include estimated position and/or
velocity values (i.e., not based on the receipt of a message with updated position or
velocity information). In this latter case the State Vector report shall include a Time of
20xx, RTCA, Inc.

203
Applicability for the estimated position/velocity parameters. The six-byte Report Time
of Applicability Parameter field, as specified in Table 2-81, is sub-divided into three
subfields as shown in Table 2-86. The coding of the subfields is specified in the
Table 2-86: Report Time of Applicability Parameter Coding

Subfield Coding
3Time of Applicability for Estimated Mddddddd dddddddL
Position/Velocity
3Position Time of Applicablity Mddddddd dddddddL
3Velocity Time of Applicabilty Mddddddd dddddddL
Note: In the Coding column, M indicates the Most Significant Bit of the data field
and L indicates the Least Significant Bit of the data field.
2.2.8.1.4.1 Time of Applicability for Estimated Position/Velocity
The Time of Applicability for the estimated position and velocity shall be generated
under the conditions specified below:
a. Each time that an individual State Vector Report is updated as specified in

2.2.8.1.17, 2.2.8.1.18, 2.2.8.1.19, OR 2.2.8.1.20, the Report Assembly Function
shall update the Time of Applicability for the Estimate Position/Velocity data in the
State Vector Report with either the GPS/GNSS UTC Measure Time data (2.2.8.5.1)
or the Established Receiver Unit Time (2.2.8.5.2), whichever is applicable to the
Receiving device Report Assembly Function installation requirements.
b. Time of Applicability data shall be provided in the State Vector report in binary
format as specified in Table 2-86.
2.2.8.1.4.2 Position Time of Applicability

Processing of Position Time of Applicability depends on the UTC Time of Message
Receipt of the Position Message and the value of the TIME (T) bit in the Position
Message.
2.2.8.1.4.2.1 Position Time of Applicability when TIME (T)=0

Each time that an Airborne or Surface Position Message is received with valid Latitude
AND Longitude data and TIME (T)=0, the Report Assembly Function shall update the
Position Time of Applicability data in the State Vector Report with the Time of Message
Receipt of the Position Message expressed as either GPS/GNSS UTC Measure Time data
(see 2.2.8.5.1), or the Established Receiver Unit Time (see 2.2.8.5.2). Time of
Applicability shall be rounded to the nearest LSB of the Position Time of Applicability
field.
2.2.8.1.4.2.2 Position Time of Applicability when TIME (T)=1 and UTC Time of Message
Receipt is Available
Each time that an Airborne or Surface Position Message is received with TIME
(T)=1 and valid Latitude AND Longitude data, and when a valid UTC Time of
20xx, RTCA, Inc.

204
Message Receipt is available per 2.2.8.5.1, the Report Assembly Function shall update
the Position Time of Applicability data in the State Vector Report with the appropriate
0.2 second UTC epoch. The appropriate 0.2 second UTC epoch is determined as follows:
If CPR Format (F)=0, Position Time of Applicability shall be the nearest even
0.2 second UTC epoch to the time that the Airborne Position Message is
received, expressed as GPS/GNSS UTC Measure Time data (see 2.2.8.5.1) and
rounded to the nearest LSB of the Position Time of Applicability field.
If CPR Format (F)=1, Position Time of Applicability shall be the nearest odd
0.2 second UTC epoch to the time that the Airborne Position Message is
received, expressed as GPS/GNSS UTC Measure Time data (see 2.2.8.5.1) and
rounded to the nearest LSB of the Position Time of Applicability field.
Note: An even 0.2 second UTC epoch is defined as that moment on the UTC time
that occurs at an even number of 200-millisecond intervals after an exact even-
numbered UTC second. Likewise, an odd 0.2 second UTC epoch is defined as
that moment on the UTC time scale that occurs at an odd number of 200
millisecond intervals after an even numbered UTC second. Examples of even 0.2
second epochs are 12.0 seconds, 12.4 seconds, 12.8 seconds, 13.2 seconds, 13.6
seconds, etc. Examples of odd 0.2 second epochs are 12.2 seconds, 12.6
seconds, 13.0 seconds, 13.4 seconds, 13.8 seconds, etc.
2.2.8.1.4.2.3 Position Time of Applicability when TIME (T)=1 and UTC Time of Message
Receipt is NOT Available
Each time that an Airborne or Surface Position Message is received with TIME (T)=1
and valid Latitude AND Longitude data, and when no valid UTC Time of Message
Receipt per 2.2.8.5.1 is available, the Position Time of Applicability shall be processed
as specified in 2.2.8.1.4.2.1.
2.2.8.1.4.3 Velocity Time of Applicability

Each time that an Airborne Velocity Message - Subtype=1 or 2 is received with valid
East/West AND North/South Velocity data, the Report Assembly Function shall update
the Velocity Time of Applicability data in the State Vector Report with either the
GPS/GNSS UTC Measure Time data (see 2.2.8.5.1) or the Established Receiver Unit
Time (see 2.2.8.5.2), whichever is applicable to the Receiving device Report Assembly
Function installation requirements.
Each time that a Surface Position Message is received with valid Movement AND
Ground Track data, the Report Assembly Function shall update the Velocity Time of
Applicability data in the State Vector Report with either the GPS/GNSS UTC Measure
Time data (see 2.2.8.5.1) or the Established Receiver Unit Time (see 2.2.8.5.2),
whichever is applicable to the Receiving device Report Assembly Function installation
requirements.
2.2.8.1.5 Latitude (WGS-84)

The ADS-B Report Assembly Function shall decode the Encoded Latitude data
(2.2.3.2.3.7 and /or 2.2.3.2.4.7) provided in the ADS-B broadcast. Decoding of the
20xx, RTCA, Inc.

205
encoded latitude data shall be performed in accordance with A.1.7.4 through A.1.7.8.2
of Appendix A. Latitude data shall be provided to the user application in the State
Vector report in angular weighted binary format (M bit = 90 degrees, S bit = negative, or
180 degrees) as specified in Table 2-81.
When valid encoded latitude data is not available, the latitude data provided to the user
application shall be set to ALL ZEROs, and the Horizontal Position Validity Flag bit,
i.e., bit #7 (MSB) of byte #3 of the State Vector Report (2.2.8.1.1.2), shall be set to
ZERO (0) to indicate that the reported Horizontal Position data is not valid. Otherwise,
the Horizontal Position Validity Flag bit, i.e., bit #7 (MSB) of byte #3 of the State Vector
Report, shall be set to ONE (1), unless modified by other conditions.
2.2.8.1.6 Longitude (WGS-84)

The ADS-B Report Assembly Function shall decode the Encoded Longitude data
(2.2.3.2.3.8 and / or 2.2.3.2.4.8) provided in the ADS-B broadcast. Decoding of the
encoded longitude data shall be performed in accordance with A.1.7.4 through
A.1.7.8.2 of Appendix A. Latitude data shall be provided to the user application in the
State Vector report in angular weighted binary format (M bit = 90 degrees, S bit =
negative, or 180 degrees) as specified in Table 2-81.
When valid encoded longitude data is not available, the longitude data provided to the
user application shall be set to ALL ZEROs, and the Horizontal Position Validity Flag
bit, i.e., bit #7 (MSB) of byte #3 of the State Vector Report, shall be set to ZERO (0) to
indicate that the reported Horizontal Position data is not valid. Otherwise, the Horizontal
Position Validity Flag bit, i.e., bit #7 (MSB) of byte #3 of the State Vector Report, shall
be set to ONE (1), unless modified by other conditions.
2.2.8.1.7 Altitude, Geometric (WGS-84)

a. When Geometric Altitude Data is indicated by the TYPE subfield (2.2.3.2.3.1) the
ADS-B Report Assembly Function shall decode Altitude Data (2.2.3.2.3.4) that has
been encoded by the ADS-B Transmitting Subsystem as specified in 2.2.3.2.3.4.2.
b. Alternatively, Barometric Altitude Data (2.2.3.2.3.4.1), Difference from Barometric

Altitude Sign Bit (2.2.3.2.6.1.14, 2.2.3.2.6.2.14, 2.2.3.2.6.3.14 or
2.2.3.2.6.4.14), and Difference from Barometric Altitude (2.2.3.2.6.1.15,
2.2.3.2.6.2.15, 2.2.3.2.6.3.15 or 2.2.3.2.6.4.15), shall be decoded and the
Geometric Altitude computed by the receiver Report Assembly Function.
c. Geometric Binary Altitude data shall be provided to the user application in the State
Vector report in binary format as specified in Table 2-81. This format represents a
true twos complement format where the MSB has a weight of 65,536 and the LSB
has a weight of 0.015625. The maximum range of the data is then given by
[2*MSB - LSB] or 131071.984375.
d. When valid Geometric Altitude data is not available, the ADS-B receiver shall set the
Geometric Altitude data provided to the user interface to ALL ZEROs, and the
Geometric Altitude Validity Flag bit, i.e., bit #6 of byte #3 of the State Vector Report
(2.2.8.1.1.2), shall be set to ZERO (0) to indicate that the reported Geometric
Altitude is not valid. Otherwise, the Geometric Altitude Validity Flag bit, i.e., bit #6
20xx, RTCA, Inc.

206
of byte #3 of the State Vector Report, shall be set to ONE (1), unless modified by
other conditions.
Note: Geometric Altitude is not required to be estimated when a State Vector Report is
prepared as a result of receiving an airborne position and velocity messages.
(i.e. The State Vector Report can include the most recently received value for this
field.)
2.2.8.1.8 North/South Velocity

a. The ADS-B Report Assembly Function shall extract the North/South Direction Bit
(2.2.3.2.6.1.8 or 2.2.3.2.6.2.8) and the North/South Velocity subfield
(2.2.3.2.6.1.9 or 2.2.3.2.6.2.9) from the ADS-B Message and provide North/South
Velocity information to the user Application in the State Vector report in binary
format as specified in Table 2-81. This format represents a true twos complement
format where the MSB has a weight of 2,048 and the LSB has a weight of 0.125.
The maximum range of the data is then given by [2*MSB - LSB] or 4,095.875.
b. When valid North/South Velocity data is not available, the North/South Velocity data
provided to the user application shall be set to ALL ZEROs, and the Airborne
Horizontal Velocity Validity Flag bit, i.e., bit #5 of byte #3 of the State Vector
Report (2.2.8.1.1.2), shall be set to ZERO (0) to indicate that the reported Airborne
Horizontal Velocity is not valid. Otherwise, the Airborne Horizontal Velocity
Validity Flag bit, i.e., bit #5 of byte #3 of the State Vector Report, shall be set to
ONE (1), unless modified by other conditions.
2.2.8.1.9 East/West Velocity

a. The ADS-B Report Assembly Function shall extract the East/West Direction Bit
(2.2.3.2.6.1.6 or 2.2.3.2.6.2.6) and the East/West Velocity subfield (2.2.3.2.6.1.7
or 2.2.3.2.6.2.7) from the ADS-B Message and provide East/West Velocity
information to the user application in the State Vector report in binary format as
specified in Table 2-81. This format represents a true twos complement format
where the MSB has a weight of 2,048 and the LSB has a weight of 0.125. The
maximum range of the data is then given by [2*MSB - LSB] or 4,095.875.
b. When valid East/West Velocity data is not available, the East/West Velocity data
provided to the user application shall be set to ALL ZEROs, and the Airborne
Horizontal Velocity Validity Flag bit, i.e., bit # 5 of byte #3 of the State Vector
Report (2.2.8.1.1.2), shall be set to ZERO (0) to indocate that the reported Airborne
Horizontal Velocity is not valid. Otherwise, the Airborne Horizontal Velocity
Validity Flag bit, i.e., bit #5 of byte #3 of the State Vector Report, shall be set to
ONE (1), unless modified by other conditions.
2.2.8.1.10 Ground Speed While on the Surface

a. The ADS-B Report Assembly Function shall extract the Movement Data
(2.2.3.2.4.2) from the ADS-B Surface Position Message and provide Ground Speed
information to the user application in the State Vector report as specified in Table 2-
81. Coding of the Movement information shall be the same as that identified for the
Movement Data in 2.2.3.2.4.2.
20xx, RTCA, Inc.

207
b. When valid Movement data is not available, the ADS-B Report Assembly Function
shall set the Ground Speed data provided to the user application to ALL ZEROs, and
the Surface Ground Speed Validity Flag bit, i.e., bit #4 (LSB) of byte #3 of the State
Vector Report, shall be set to ZERO (0) to indicate that the reported Surface Ground
Speed is not valid. Otherwise, the Surface Ground Speed Validity Flag bit, i.e., bit
#4 (LSB) of byte #3 of the State Vector Report, shall be set to ONE (1), unless
modified by other conditions.
2.2.8.1.11 Heading While on the Surface

a. The ADS-B Report Assembly Function shall extract the Status Bit for Heading
(2.2.3.2.4.3) and Heading Data (2.2.3.2.4.4) from the ADS-B Surface Position
Message and provide Heading while on the surface information to the user
application in the State Vector Report in binary format as specified in Table 2-81.
This format represents a true twos complement format where the MSB has a weight
of 90 degrees and the LSB has a weight of 1.40625 degrees. The maximum range of
the data is then given by [2*MSB - LSB] or 178.59375 degrees. Alternately, the
format may be referred to as angular weighted binary.
b. When valid Heading while on the surface data is not available, the ADS-B Report
Assembly Function shall set the Heading while on the surface data provided to the
user application to ALL ZEROs, and the Surface Heading Validity Flag bit, i.e., bit
#3 (MSB) of byte #3 of the State Vector Report, shall be set to ZERO (0) to indicate
that the reported Surface Heading is not valid. Otherwise, the Surface Heading
Validity Flag bit, i.e., bit #3 (MSB) of byte #3 of the State Vector Report, shall be set
to ONE (1), unless modified by other conditions.
2.2.8.1.12 Altitude, Barometric (Pressure Altitude)

a. When Barometric Altitude Data is indicated by the TYPE subfield (2.2.3.2.3.1) of
the ADS-B Airborne Position Message, the ADS-B Report Assembly Function shall
decode Altitude Data (2.2.3.2.3.4) that has been encoded by the ADS-B
Transmitting Subsystem as specified in 2.2.3.2.3.4.1. Binary Altitude data shall be
provided to the user application in the State Vector report as specified in Table 2-81.
This format represents a true twos complement format where the MSB has a weight
of 65,536 and the LSB has a weight of 0.015625. The maximum range of the data is
then given by [2*MSB - LSB] or 131071.984375.
b. When valid Barometric Altitude data is not available, the ADS-B Report Assembly
Function shall set the Barometric Altitude data provided to the user application to
ALL ZEROs, and the Barometric Altitude Validity Flag bit, i.e., bit #2 of byte #3 of
the State Vector Report, shall be set to ZERO (0) to indicate that the reported
Barometric Altitude is not valid. Otherwise, the Barometric Altitude Validity Flag
bit, i.e., bit #2 of byte #3 of the State Vector Report, shall be set to ONE (1), unless
modified by other conditions.
Note: Barometric Altitude is not required to be estimated when a State Vector Report is
prepared as a result of receiving an airborne position and velocity messages.
(i.e. The State Vector Report can include the most recently received value for this
field.)
20xx, RTCA, Inc.

208
2.2.8.1.13 Vertical Rate, Geometric/Barometric

The Vertical Rate field in the State Vector Report contains the altitude rate of an
airborne ADS-B Participant. This shall be either the rate of change of pressure altitude,
or of geometric altitude, as specified by the Vertical Rate Type element in the Mode
Status Report (2.2.8.2.18).
2.2.8.1.14 Vertical Rate, Geometric (WGS-84)

a. When Geometric Altitude Rate Data is indicated by the Source Bit for Vertical
Rate subfield (2.2.3.2.6.1.10, 2.2.3.2.6.2.10, 2.2.3.2.6.3.10 or 2.2.3.2.6.4.10)
the ADS-B Report Assembly Function shall extract the Sign Bit for Vertical Rate
subfield (2.2.3.2.6.1.11, 2.2.3.2.6.2.11, 2.2.3.2.6.3.11 or 2.2.3.2.6.4.11) and the
Vertical Rate subfield (2.2.3.2.6.1.12, 2.2.3.2.6.2.12, 2.2.3.2.6.3.12 or
2.2.3.2.6.4.12) from the ADS-B Message and provide Vertical Rate, Geometric
where the MSB has a weight of 16,384 and the LSB has a weight of 1. The
maximum range of the data is then given by [2*MSB - LSB] or 32,767.
b. When valid Geometric Altitude Rate data is not available, the ADS-B Report
Assembly Function shall set the Vertical Rate, Geometric data provided to the user
application to ALL ZEROs, and the Geometric Vertical Rate Validity Flag bit, i.e.,
bit #1 of byte #3 of the State Vector Report (2.2.8.1.1.2), shall be set to ZERO (0)
to indicate that the reported Geometric Vertical Rate is not valid. Otherwise, the
Geometric Vertical Rate Validity Flag bit, i.e., bit #1 of byte #3 of the State Vector
Note: Geometric Altitude Rate is not required to be estimated when a State Vector
Report is prepared as a result of receiving an airborne position and velocity
messages. (i.e. The State Vector Report can include the most recently received
value for this field.)
2.2.8.1.15 Barometric Altitude Rate

a. When Barometric Altitude Rate Data is indicated by the Source Bit for Vertical
Rate subfield (2.2.3.2.6.1.10, 2.2.3.2.6.2.10, 2.2.3.2.6.3.10 or 2.2.3.2.6.4.10)
the ADS-B Report Assembly Function shall extract the Sign Bit for Vertical Rate
subfield (2.2.3.2.6.1.11, 2.2.3.2.6.2.11, 2.2.3.2.6.3.11 or 2.2.3.2.6.4.11) and the
Vertical Rate subfield (2.2.3.2.6.1.12, 2.2.3.2.6.2.12, 2.2.3.2.6.3.12 or
2.2.3.2.6.4.12) from the ADS-B Message and provide Vertical Rate, Barometric
where the MSB has a weight of 16,384 and the LSB has a weight of 1. The
maximum range of the data is then given by [2*MSB - LSB] or 32,767.
b. When valid Barometric Altitude Rate data is not available, the ADS-B Report
Assembly Function shall set the Vertical Rate, Barometric data provided to the user
application to ALL ZEROs, and the Barometric Vertical Rate Validity Flag bit, i.e.,
bit #0 of byte #3 of the State Vector Report, shall be set to ZERO (0). Otherwise, the
Barometric Vertical Rate Validity Flag bit, i.e., bit #0 of byte #3 of the State Vector
20xx, RTCA, Inc.

209
Note: Barometric Altitude Rate is not required to be estimated when a State Vector
Report is prepared as a result of receiving an airborne position and velocity
messages. (i.e. The State Vector Report can include the most recently received
value for this field.)
2.2.8.1.16 Navigation Integrity Category (NIC)

The ADS-B Report Assembly Function shall provide Navigation Integrity Category
(NIC) information in the State Vector Report. The NIC is derived from the TYPE
Code data (2.2.3.2.3.1) and the NIC Supplement-B value (2.2.3.2.3.3) from the ADS-B
Airborne Position Message, and the NIC Supplement-A value (2.2.3.2.7.2.6) from the
ADS-B Aircraft Operational Status Message, OR the TYPE Code data (2.2.3.2.4.1)
from the ADS-B Surface Position Message, and the NIC Supplement-A value
(2.2.3.2.7.2.6) and the NIC Supplement-C value (2.2.3.2.7.2.3.11) from the ADS-B
Aircraft Operational Status Message. The NIC values are encoded according to the NIC
values given in Table 2-70, except for RC < 0.3 NM which is encoded in the State Vector
Report with a value of 6 in bits 0 to 3 in byte 35, with bit 4 in byte 35 set to ONE (1) (i.e.,
xxx10110). The NIC parameter is provided to the user application in the State Vector
Report as specified in Table 2-81.
Note: For backward compatability, applications designed to interface to the State

Vector Report structure of RTCA DO-260A will decode RC < 0.3 NM as NIC=6
and interpret it as RC < 0.6 NM. Applications designed to comply with these
MOPS will properly decode the NIC as RC < 0.3 NM.
2.2.8.1.17 Estimated Latitude (WGS-84)

a. New Latitude Data Received
(1). Airborne or Surface Message Received: - Each time that the Report Assembly
Function establishes a new decoded Latitude in accordance with 2.2.8.1.2, the
Report Assembly Function shall update the Estimated Latitude (WGS-84) data in
the State Vector Report with the new Latitude data received.
(2). Airborne or Surface Message Received: - The Estimated Latitude update shall be
completed by the Report Assembly Function also updating the Report Time of
Applicability in the State Vector Report with either the GPS/GNSS UTC
Measure Time data (see 2.2.8.5.1) or the Established Receiver Unit Time (see
2.2.8.5.2) whichever is applicable to the Receiving device Report Assembly
b. New North/South Velocity Data Received: (Airborne Velocity Message Received)
(1). Each time that an Airborne Velocity Message - Subtype=1 or 2 is received

with valid North/South Velocity data, the Report Assembly Function shall
compute a new Estimated Latitude (WGS-84) position based on the last known
Estimated Latitude (WGS-84), the last known North/South Velocity (Note: Not
the North/South Velocity data just received), and the time that has elapsed since
the last update of the Estimated Latitude (WGS-84).
20xx, RTCA, Inc.

210
Accuracy of the Estimated Latitude (WGS-84) computation shall be within 20

meters of the theoretical noise free position that could be established based on the
previous position, the last known velocity, and the time of travel.
Note: The accuracy requirement is stated in the manner given in order to

specifically allow the implementation to use estimation techniques
such as Kalman filters, alpha-beta trackers, or linear estimation as
deemed necessary by the implementer to satisfy the accuracy
requirement.
(2). The new Estimated Latitude (WGS-84) computed in b.(1) shall be used by the
Report Assembly Function to update the Estimated Latitude (WGS-84) data in
the State Vector Report.
(3). The Estimated Latitude update shall be completed by the Report Assembly
Function also updating the Report Time of Applicability in the State Vector
Report with either the GPS/GNSS UTC Measure Time data (see 2.2.8.5.1) or
the Established Receiver Unit Time (see 2.2.8.5.2) whichever is applicable to
the Receiving device Report Assembly Function installation requirements.
c. Estimated Horizontal Position Validity Flag Requirements
When valid estimated Latitude or Longitude position data is not available, the
estimated latitude and longitude data provided to the user application shall be set to
ALL ZEROs and the Estimated Horizontal Position Validity Flag bit, i.e., bit #7 of
byte #4 of the State Vector Report (2.2.8.1.1.2), shall be set to ZERO (0) to indicate
that the reported Estimated Horizontal Position is not valid.
Otherwise, the Estimated Horizontal Position Validity Flag bit, i.e., bit #7 of byte #4
of the State Vector Report, shall be set to ONE (1), unless modified by other
conditions.
2.2.8.1.18 Estimated Longitude (WGS-84)

a. New Longitude Data Received
(1). Airborne or Surface Message Received: - Each time that the Report Assembly
Function establishes a new decoded Longitude in accordance with 2.2.8.1.6, the
Report Assembly Function shall update the Estimated Longitude (WGS-84) data
in the State Vector Report with the new Longitude data received.
(2). Airborne or Surface Message Received: - The Estimated Longitude update shall
be completed by the Report Assembly Function also updating the Report Time of
Applicability in the State Vector Report with either the GPS/GNSS UTC
Measure Time data (see 2.2.8.5.1) or the Established Receiver Unit Time (see
2.2.8.5.2) whichever is applicable to the Receiving device Report Assembly
b. New East/West Velocity Data Received: (Airborne Velocity Message Received)
(1). Each time that an Airborne Velocity Message - Subtype=1 or 2 is received

with valid East/West Velocity data, the Report Assembly Function shall compute
a new Estimated Longitude (WGS-84) position based on the last known
20xx, RTCA, Inc.

211
Estimated Longitude (WGS-84), the last known East/West Velocity (Note: Not
the East/West Velocity data just received), and the time that has elapsed since the
last update of the Estimated Longitude (WGS-84).
Accuracy of the Estimated Longitude (WGS-84) computation shall be within

20 meters of the theoretical noise free position that could be established based
on the previous position, the last known velocity, and the time of travel.

requirement.
(2). The new Estimated Longitude (WGS-84) computed in b.(1) shall be used by the
Report Assembly Function to update the Estimated Longitude (WGS-84) data in
(3). The Estimated Longitude update shall be completed by the Report Assembly
Function also updating the Report Time of Applicability in the State Vector
the Established Receiver Unit Time (see 2.2.8.5.2) whichever is applicable to
c. Estimated Horizontal Position Validity Flag Requirements
When valid estimated Latitude or Longitude position data is not available, the
estimated latitude and longitude data provided to the user application shall be set to
ALL ZEROs and the Estimated Horizontal Position Validity Flag bit, i.e., bit #0 of
byte #3 of the State Vector Report (2.2.8.1.1.2), shall be set to ZERO (0) to indicate
that the reported Estimated Horizontal Position is not valid.
Otherwise, the Estimated Horizontal Position Validity Flag bit, i.e., bit #0 of byte #3
conditions.
2.2.8.1.19 Estimated North/South Velocity

Note: The estimation of North/South Velocity is considered to be an optional function
to be implemented in the ADS-B Report Assembly Function at the discretion of
the implementer. If estimation of North/South Velocity is implemented then the
requirements provided in the following subparagraphs a. through b.(3) are to be
used as the minimum acceptable performance for such estimation.
a. New North/South Velocity Received: (Airborne Velocity or Surface Position

Message Received)
(1). Each time that the Report Assembly Function establishes a new North/South
Velocity in accordance with 2.2.8.1.8, the Report Assembly Function shall
update the Estimated North/South Velocity data in the State Vector Report with
the new North/South Velocity data received.
20xx, RTCA, Inc.

212
(2). The Estimated North/South Velocity update shall be completed by the Report
Assembly Function also updating the Report Time of Applicability in the State
Vector Report with either the GPS/GNSS UTC Measure Time data (see
2.2.8.5.1) or the Established Receiver Unit Time (see 2.2.8.5.2) whichever is
applicable to the Receiving device Report Assembly Function installation
requirements.
b. New Latitude Position Data Received: (Airborne Position or Surface Position

Message Received)
(1). Each time that the Report Assembly Function establishes a new decoded Latitude
in accordance with 2.2.8.1.2, the Report Assembly Function shall compute a
new Estimated North/South Velocity based on the last known Estimated Latitude
(WGS-84), the new Latitude position data just received, and the time that has
elapsed since the last update of the Estimated North/South Velocity.
Accuracy of the Estimated North/South Velocity computation shall be within

0.3 meters/second of the theoretical noise free Estimated North/South Velocity
that could be established based on the previous position, the new position, and
the elapsed time of travel between the two positions.

requirement.
(2). The new Estimated North/South Velocity computed in b.(1) shall be used by the
Report Assembly Function to update the Estimated North/South Velocity data in
(3). The Estimated North/South Velocity update shall be completed by the Report
requirements.
c. Estimated Velocity Validity Flag Requirements
When valid estimated North/South or East/West Velocity data is not available, the
estimated North/South or East/West Velocity data provided to the user application
shall be set to ALL ZEROs and the Estimated Horizontal Velocity Validity Flag bit,
i.e., bit #6 of byte #4 of the State Vector Report (2.2.8.1.1.2), shall be set to ZERO
(0) to indicate that the reported Estimated Horzontal Velocity is not valid.
Otherwise, the Estimated Horizontal Velocity Validity Flag bit, i.e., bit #6 of byte #4
conditions.
20xx, RTCA, Inc.

213
2.2.8.1.20 Estimated East/West Velocity

Note: The estimation of East/West Velocity is considered to be an optional function to
be implemented in the ADS-B Report Assembly Function at the discretion of the
implementer. If estimation of East/West Velocity is implemented then the
requirements provided in the following subparagraphs a. through b.(3) are to be
used as the minimum acceptable performance for such estimation.
a. New East/West Velocity Data Received: (Airborne Velocity or Surface Position

Message Received)
(1). Each time that the Report Assembly Function establishes a new East/West
Velocity in accordance with 2.2.8.1.9, the Report Assembly Function shall
update the Estimated East/West Velocity data in the State Vector Report with the
new East/West Velocity data received.
(2). The Estimated East/West Velocity update shall be completed by the Report
requirements.
b. New Longitude Position Data Received: (Airborne or Surface Position Message

Received)
(1). Each time that the Report Assembly Function establishes a new decoded
Longitude in accordance with 2.2.8.1.6, the Report Assembly Function shall
compute a new Estimated East/West Velocity based on the last known Estimated
Longitude (WGS-84), the new Longitude position data just received, and the
time that has elapsed since the last update of the Estimated East/West Velocity.
Accuracy of the Estimated East/West Velocity computation shall be within 0.3

meters/second of the theoretical noise free Estimated East/West Velocity that
could be established based on the previous position, the new position, and the
elapsed time of travel between the two positions.

requirement.
(2). The new Estimated East/West Velocity computed in b.(1) Shall be used by the
Report Assembly Function to update the Estimated East/West Velocity data in
(3). The Estimated East/West Velocity update shall be completed by the Report
requirements.
20xx, RTCA, Inc.

214
c. Estimated Horizontal Velocity Validity Flag Requirements
When valid estimated North/South or East/West Velocity data is not available, the
estimated North/South or East/West Velocity data provided to the user application
shall be set to ALL ZEROs and the Estimated Horizontal Velocity Validity Flag bit,
i.e., bit #7 of byte #4 of the State Vector Report (2.2.8.1.1.2), shall be set to ZERO
(0) to indicate that the reported Estimated Horzontal Velocity is not valid.
Otherwise, the Estimated Horizontal Velocity Validity Flag bit, i.e., bit #7 of byte #4
conditions.
2.2.8.1.21 Surveillance Status / Discretes

a. The ADS-B Report Assembly Function shall extract the Surveillance Status
(2.2.3.2.3.2) from the ADS-B Airborne Position Message (2.2.3.2.3) and map the
surveillance status data into the most significant nibble of the State Vector Report
byte on a bit for bit basis as shown in Table 2-81.
b. When valid Surveillance Status data is not available, the ADS-B Report Assembly
Function shall set the Surveillance Status data provided to the user application to
ALL ZEROs.
c. The ADS-B Report Assembly Function shall extract the Intent Change Flag
(2.2.3.2.6.1.3 and Figure 2-7, Figure 2-8) from the ADS-B Airborne Velocity
Message (2.2.3.2.6) and map the Intent Change Flag into the bit b1 of the least
significant nibble of the State Vector Report byte on a bit for bit basis as shown in
Table 2-81.
d. The ADS-B Report Assembly Function shall insert a ZERO (0) into bit b0 of the
least significant nibble of the State Vector Report byte shown in Table 2-81.
2.2.8.1.22 Report Mode

The Report Mode is used to indicate the current state of the Report for each ADS-B
vehicle being reported. Each time that the State Vector Report is updated, the Report
Mode shall be updated with the encoding being as shown in Table 2-87.
Table 2-87: Report Mode Encoding

Coding Report Mode
xxxx 0000 No Report Generation Capability
xxxx 0001 Acquisition Mode (see 2.2.10.2)
xxxx 0010 Track Mode (see 2.2.10.3)
xxxx 0011
through Reserved for Future Expansion
xxxx 1111
Note: x in the table above, denotes DONT CARE.
20xx, RTCA, Inc.

215
2.2.8.2 ADS-B Mode Status Report Characteristics

Mode Status Reports.
The Report Assembly Function shall be compatible with the current and prior versions of
the relevant 1090 MHz ADS-B Messages (e.g., Operational Status, Airborne Position,
Surface Position, Airborne Velocity, Aircraft Status and Aircraft Identification) that are
used as the basis for generating Mode Status Reports. The relevant Version Two (2)
messages are identified below and the relevant Version Zero (0) messages, conformant to
RTCA DO-260, including Change 1, and the relevant Version One (1) messages,
conformant to RTCA DO-260A, including Change 1 and Change 2, and their required
use for ADS-B Mode Status Report generation are defined in Appendix N, Section N.4.
The intent of Table 2-88 is to illustrate the structure of all Items required to be reported in
an ADS-B Mode Status Report. The exact structure of the data indicated in columns 10
and 11 is provided as a guideline or one possible method of satisfying the report
structure. Implementers may choose to organize the data in another format; however,
delivery to a user interface or application of all Items in Table 2-88 shall be consistent
with the range, resolution, and units indicated in column 7, 8 and 9 of Table 2-88
respectively. If data is not available to support a field that is delivered to an application,
then the data provided to the application shall be set to ALL ZEROs. Those
requirements in 2.2.8.2.1 to 2.2.8.2.4 below that relate to specific data structure details
(byte numbers, and bit numbers within the bytes) shall only apply to equipment that uses
the sample data structure shown in columns 10-11 of Table 2-88.
Mode Status Report elements and how such elements should be structured into
20xx, RTCA, Inc.

216
Table 2-88: ADS-B Mode Status Data Elements - Source Data Mapping To Report Structure
Table 2-88: ADS-B Mode Status Data Elements Source Data Mapping To Report Structure
# 1 2 3 4 5 6 7 8 9 10 11
ME Message
Received # of Data
Item # Parameter / Contents Notes Field Field Range Resolution Units Data Structure
Message Sources Bits Byte #
Bits Bits
N/A 15 MddL Mddd dddddddd
0a, 0b Report Type and Structure N/A 24 N/A N/A discrete 0-2
N/A 1-5 dddddddL
0c Validity Flags N/A N/A N/A 8 N/A N/A discrete dddddddd 3
Airborne Velocity - AA N/A 9 32 24
- OR -
Operational Status AA N/A 9 32 24
- OR - Mddddddd dddddddd
1 Participant Address N/A N/A discrete 46
Target State & Status - AA N/A 9 32 24 dddddddL
- OR -
Aircraft ID & Category Msg
AA N/A 9 - 32 24
68 38 40
Emitter Category
2 Address Qualifier 8 N/A N/A discrete xxxxxMdL 7
All Messages with DF=18
N/A 68
CF
Operational Status
0.0078125
3 Time of Applicability Airborne Position N/A N/A 16 511.9921875 seconds Mddddddd dddddddL 8-9
(1/128)
Target State & Status
Operational Status
4 ADS-B Version 41 - 43 73 - 75 8 0-7 1 discrete xxxxxMdL 10
Version Number
xMdddddL xMdddddL
Aircraft ID & Category Alphanumeric xMdddddL xMdddddL
5a Call Sign 14 56 41 88 64 N/A N/A 11 18
Msg Ident Char. characters xMdddddL xMdddddL
xMdddddL xMdddddL
5b Emitter Category 68 38 - 40 8 N/A N/A discrete xxxMdddL 19
Msg Emitter Category
A/V Length and Width Operational Status
5c 3&4 21 24 53 56 8 N/A N/A discrete xxxxMddL 20
Code Subtype=1 L/W Code
Aircraft Status Message
6 Emergency/Priority Status Subtype 1 Emergency / 9 - 11 36 - 38 8 N/A N/A discrete xxxxxMdL 21
Priority Status
Operational Status CC 9 - 24 41 - 56 24
dddddddd dddddddd
7 Capability Class Codes Target State & Status See 2.2.8.2.10 22 - 24
dddddddd
TCAS Operational 53 85 1
8 Operational Mode Operational Status OM 25 40 57 - 72 16 See 2.2.8.2.11 dddddddd dddddddd 25 - 26
Operational Status NACP 45 48 77 80
8
9a SV Quality - NACP N/A N/A discrete xxxxMddL 27
Target State & Status -
NACP 40 - 43 72 - 75
20xx, RTCA, Inc.

20xx, RTCA, Inc.
Table 2-88: ADS-B Mode Status Data Elements Source Data Mapping To Report Structure
# 1 2 3 4 5 6 7 8 9 10 11
ME Message
Received # of Data
Bits Bits
Airborne Velocity NACV
11 13 43 45
9b SV Quality - NACV 8 N/A N/A discrete xxxxxMdL 28
Operational Status
17 19 49 51
Subtype=1 NACV
Operational Status SIL
51 52 83 84
9c SV Quality SIL 8 N/A N/A discrete xxxxxxML 29
45 46 77 78
SIL
Operational Status SIL 55 87
Supplement
SV Quality SIL
9d 8 N/A N/A discrete xxxxxLxx 29
Supplement
Target State and Status
SIL Supplement 8 40
SV Quality System
9e Operational Status SDA 31 32 63 64 8 N/A N/A discrete xxxMLxxx 29
Design Assurance (SDA)
9f SV Quality GVA Operational Status GVA 49 50 81 82 8 N/A N/A discrete xxxxxxML 30
Operational Status 53 85
Subtype=0 NICBARO
9g SV Quality NICBARO 8 N/A N/A discrete xxxxxxxL 31
NICBARO 44 76
Track/Heading and Operational Status
10a Horizontal Reference Subtype=1 Trk/Hdg 53 -54 85 -86 8 N/A N/A discrete xxxxxxML 32
Direction (HRD) & Subtype=0,1 HRD
Airborne Velocity Vert.
10b Vertical Rate Type 36 68 8 N/A N/A discrete xxxxxxxL 33
Rate Source
(Reserved for) Flight Mode
11 8 N/A N/A discrete xxxxxMdL 34
Specific Data
12 Other (Reserved) Reserved 8 Reserved dddddddd 35
TOTAL BYTES: 36
Notes:
1. In the Data Structure column (i.e., column 10), S indicates the sign-bit, M indicates the Most Significant Bit of the data field, d
indicates data bits in the field, L indicates the Least Significant Bit of the data field, and x indicates Dont Care bits in the data field.
2. The Report Type and Structure Identifier is used to identify the type of ADS-B Report being generated and the data parameters provided in the
report as specified in 2.2.8.1.1.
3. The A/V Length and Width Code parameter is only applicable to Mode Status Reports for aircraft or vehicles that are reporting the surface
formats.
4. The Operational Mode subfield includes the GPS Antenna Offset parameter in Mode Status Reports for aircraft or vehicles when reporting the
surface formats.
217
218
2.2.8.2.1 Mode Status Report Type and Structure Identification and Validity Flags
2.2.8.2.1.1 Mode Status Report Type and Structure Identification

The Report Type requirements were previously provided in 2.2.8.1.1. Report Type
formats and the maximum number of bytes to be contained in each report are identified in
Table 2-88.
2-88 that are being provided in the Mode Status report and is intended to provide a
methodology for the Report Assembly Function to structure shorter reports when data for
some parameters is not available. In order to provide the capability to provide shorter
Mode Status reports the following basic conventions shall be adhered to:
b. Parameters that are designated in Table 2-88 are restricted to byte boundaries.
c. Whenever a data parameter identified in Table 2-88 is not provided in the report, then
it is permissible to concatenate the next parameter to be included into the report
immediately following the inclusion of the previous reported parameter.
d. Each parameter of the Mode Status report identified in Table 2-88 must be properly
declared in the Report Structure field as detailed in the following paragraphs and
Table 2-89.

The Report Structure is a 20-bit field and shall be provided in the least significant nibble
(i.e., bits 3 - 0) of the first byte (i.e., byte 0) and continuing into bytes 1 and 2 of the
Report. The Report Structure format is specified in Table 2-89 where each bit is
associated with a particular data parameter of the Mode Status Report. If the bit is set to
ONE (1), then the data parameter is considered to be available and shall be transmitted in
the report. Otherwise, the data parameter is considered to not be available and shall not
be transmitted in the report. Note that Table 2-89 does not address the Report Type and
Structure Identification parameter, the Validity Flags parameter, nor the Participant
Address parameter since these four parameters shall be included in the Mode Status
Report. Also, certain of the other Mode Status data parameters are required to be
reported, as specified in 2.2.9, even though bits have been allocated in the report
structure field as shown in Table 2-89.
20xx, RTCA, Inc.

219
Table 2-89: ADS-B Mode Status Report Structure Coding

Number of
Byte # Bit # Mode Status Data Parameter to be Reported
Bytes
3 Time of Applicability 2
0 2 ADS-B Version 1
1 Call Sign 8
0 Emitter Category 1
7 A/V Length and Width Code 1
6 Emergency / Priority Status 1
5 Capability Codes 2
1 4 Operational Mode 2
3 SV Quality - NACP 1
2 SV Quality - NACV 1
1 SV Quality SIL, SIL Supplement, SDA 1
0 SV Quality GVA 1
7 SV Quality - NICBARO 1
6 True/Magnetic Heading (HRD) 1
5 Vertical Rate Type 1
2 4 (Reserved for) Flight Mode Specific Data 1
3 Other (Reserved) 1
2 Reserved
1 Reserved
0 Reserved
2.2.8.2.1.2 Mode Status Report Validity Flags

Validity Flags for data provided in the Mode Status Report shall be indicated in byte #3
of the Mode Status Report as shown for item 0c in Table 2-88. The Mode Status
Report elements that require validity flags are identified in Table 2-90. Table 2-90
identifies the byte and bit that shall be used as a flag for each element that requires a
validity flag. Each validity flag bit shall be set to ONE (1) to indicate that the
corresponding Mode Status Report Element data is valid. If such data is not valid, then
the corresponding validity flag bit shall be set to ZERO (0). Only the six most
significant bits of the subfield are currently assigned. The remaining 2 bits are reserved
for future use.
20xx, RTCA, Inc.

220
Table 2-90: ADS-B Mode Status Report Validity Flag Requirements
MS Validity Flag Bit

Report Mode Status Validity Flag Bit Required? Assignment
Item # Report Element
Bit #
0a Report Type No
Report Data
0b Structure Definition No
Time of
3 No
Applicability
4 ADS-B Version No
5a Call Sign No
5b Emitter Category No
A/V Length and
5c No
Width Code
Yes
Emergency/Priority If an update has not been received within 100 seconds, via an
6 2
Status Extended Squitter Aircraft Status Message, or a Target State and
Status Message, then this report element is not considered valid.
Yes
If an update has not been received within 24 seconds, via a 7
7 Capability Codes
Operational Status and/or a Target State and Status Message, then (MSB)
this report element is not considered valid
Yes
If an update has not been received within 24 seconds, via a
8 Operational Mode 6
Operational Status Message, then this report element is not
considered valid
Yes
If an update has not been received within 24 seconds, via a 5
9a SV Quality - NACP
Operational Status and/or a Target State and Status Message, then
Yes
9b SV Quality - NACV If an update has not been received within 24 seconds via Airborne 4
Velocity Message, then this report element is not considered valid
Yes
If an update has not been received within 24 seconds, via a
9c SV Quality SIL 3
Operational Status and/or a Target State and Status Message then
SV Quality SIL
9d No
Supplement
9e SV Quality SDA No
9f SV Quality GVA No
SV Quality
9g No
NICBARO
True/Magnetic
10a No
Heading
10b Vertical Rate Type No
(Reserved for)
11 Flight Mode No
Specific Data
12 Other (Reserved) No
20xx, RTCA, Inc.

221
2.2.8.2.2 Paritcipant Address

2.2.8.2.3 Address Qualifier

The Address Qualifier is used to indicate the type of participant address (2.2.8.1.3)
being reported. The 3 least significant bits of the one byte field are used to convey the
Address Qualifier information. The Address Qualifier subfield shall be coded as shown
in Table 2-85.
2.2.8.2.4 Report Time of Applicability

Each time that an individual Mode Status Report is updated, the Report Assembly
Function shall update the Report Time of Applicability data in the Mode Status Report
with either the GPS/GNSS UTC Measure Time data (see 2.2.8.5.1) or the Established
Receiver Unit Time (see 2.2.8.5.2), whichever is applicable to the Receiving device
Report Assembly Function installation requirements.
Report Time of Applicability data shall be provided in the Mode Status report in binary
format as specified in Table 2-88.
2.2.8.2.5 Version Number

The ADS-B Report Assembly Function shall extract the Version Number data from the
ADS-B Aircraft Operational Status Message (2.2.3.2.7.2.5) and provide the Version
Number to the user application in the Mode Status Report in the binary format specified
in Table 2-88.
When a valid Version Number is not available, the Version Number sent to the user
application shall be set to ALL ZEROs.
2.2.8.2.6 Call Sign

The ADS-B Report Assembly Function shall first extract the Aircraft Identification
Character subfields (2.2.3.2.5.3) from the ADS-B Flight Identification and Category
Message (2.2.3.2.5.3) for further processing.
Each of the eight characters extracted is encoded in a subset of International Alphabet

No. 5 (IA-5) in accordance with 2.2.3.2.5.3. The encoding of each character is 6 bits
long with bit_6 being the most significant and bit_1 being the least significant. IA-5 is a
seven bit encoding with bit_7 being the most significant and bit_1 being the least
significant. In order to provide an IA-5 encoding in an eight bit format as indicated in
Table 2-88, the Report Assembly Function shall:
(1). Retain bit_6 through bit_1 of the character encoding.
(2). If bit_6 is ZERO, set bit_7 to ONE
(3). If bit_6 is ONE, set bit_7 to ZERO
(4). Set bit_8 to ZERO
20xx, RTCA, Inc.

222
(5). Format bit_8 through bit_6 into 0MdddddL for entry into the report as
shown in Table 2-88.
When valid Flight Identity data is not available, the Call Sign data sent to the user
application shall be set to ALL ZEROs.
2.2.8.2.7 Emitter Category

The ADS-B Report Assembly Function shall extract TYPE (2.2.3.2.5.1) and ADS-B
Emitter Category (2.2.3.2.5.2) from the Aircraft Identification and Category Message
(2.2.3.2.5) and encode the Emitter Category field of the Mode Status Report as shown
in Table 2-91.
Table 2-91: Emitter Category Encoding

Coding Meaning
(Decimal)
0 No Emitter Category Information Available
1 Light (<15,500 lbs.)
2 Reserved for Future Growth
3 Small (15,500 to 75,000 lbs.)
5 Large (75,000 to 300,000 lbs.)
6 High-Vortex Large (aircraft such as B-757)
7 Heavy (>300,000 lbs.)
8 High Performance (>5 g acceleration and >400 knots)
10 Rotorcraft
11 Glider / Sailplane
12 Lighter - than - Air
13 Unmanned Aerial Vehicle
14 Space / Trans-atmospheric Vehicle
15 Ultralight / hang-glider / paraglider
16 Parachutist / Skydiver
20 Surface Vehicle - Emergency Vehicle
21 Surface Vehicle - Service Vehicle
22 Point Obstacle (includes Tethered Ballons)
23 Cluster Obstacle
24 Line Obstacle
25 through 31 Reserved for Future Growth
When valid ADS-B Emitter Category data is not available, the Emitter Category data sent
to the user application shall be set to ALL ZEROs.
20xx, RTCA, Inc.

223
2.2.8.2.8 Aircraft/Vehicle (A/V) Length and Width Code

The ADS-B Report Assembly Function shall extract the Aircraft/Vehicle (A/V) Length
and Width Code from the Aircraft Operational Status Message (2.2.3.2.7.2) when the
A/V is on the airport surface. The A/V Length and Width Code shall be encoded bit for
bit as specified in Table 2-74, into the Mode Status Report as specified in Table 2-88.
2.2.8.2.9 Emergency / Priority Status

The ADS-B Report Assembly Function shall extract the Emergency / Priority Status
data from the Extended Squitter Aircraft Status Message (2.2.3.2.7.8.1) (TYPE=28,
Subtype=1), and provide that Emergency / Priority Status information to the user
application in the Mode Status Report in the binary format specified in Table 2-88.
Emergency/Priority Status, bits 9 - 11 (see Appendix A, Figure A-8), of the Extended

Squitter Aircraft Status Message shall be mapped bit for bit into the three least significant
bits of the report byte as indicated in Table 2-88.
When valid Emergency/Priority Status data is not available (i.e., has not been received
within the past 100 seconds as per Table 2-102, Note #5), then the Emergency/Priority
Status data sent to the user application shall be set to ALL ZEROs and flagged as being
invalid as per Table 2-90.
2.2.8.2.10 Capability Class Codes

The ADS-B Report Assembly Function shall extract the Capability Class Codes data
(2.2.3.2.7.2.3) and the Target State and Status Message from the Aircraft Operational
Status Message (2.2.3.2.7.2) and provide the Capability Class Codes to the user
application in the Mode Status Report in the binary format specified in Table 2-88.
Capability Class Codes from the ADS-B Operational Status and the Target State and
Status Messages, shall be mapped bit for bit into the 3-byte long Capability Class Codes
field of the ADS-B Mode Status Report as specified in Table 2-92.
When valid Capability Class data is not available for a given parameter, then the
Capability Class data sent to the user application for that parameter shall be set to ALL
ZEROs.
When a Mode Status Report is generated and when the only received update to the
Capability Class data has come from a Target State and Status Message, the reported
value of all Capability Class parameters shall be based on the most recently received
Operational Status Message, except updated with the data (i.e., TCAS parameter)
received in the subsequent Target State and Status Message.
20xx, RTCA, Inc.

224
Table 2-92: Capability Code Mapping

Operational Status
Operational Status Message Target State and Status
MS Report Message Subtype 1
Subtype 0 (Airborne) Message
(Surface)
MS Report
Msg. Bit # Mapping to Msg. Bit # Mapping to Msg. Bit # Mapping to
CC Field Parameter
(ME field) MS Report (ME field) MS Report (ME field) MS Report
Byte # Bit #
Direct Direct
7 9 9
Mapping Mapping
Direct Direct
6 10 10
Mapping Mapping
Reserved
Direct Direct
5 13 13
Mapping Mapping
0 Direct Direct
4 14 14
Mapping Mapping
Direct
3 B2 Low 15
Mapping
2 Reserved
1 Reserved
0 Reserved
TCAS Direct Direct
7 11 53
Operational Mapping Mapping
1090ES Direct Direct
6 12 12
IN Mapping Mapping
Direct
5 ARV 15
Mapping
Direct
4 TS Report 16
Mapping
1
Direct
3 17
Mapping
TC Report
Direct
2 18
Mapping
Direct
1 POA 19
Mapping
UAT Direct Direct
0 19 16
IN Mapping Mapping
7 Reserved
6 Reserved
5 Reserved
4 Reserved
2
3 Reserved
2 Reserved
1 Reserved
0 Reserved
Note: Direct Mapping means the message bit state (i.e., 0 or 1) remains the same when
mapped into the Mode Status Report. Inverse Mapping means the message bit
state is reversed when mapped into the Mode Status Report.
2.2.8.2.11 Operational Mode

The ADS-B Report Assembly Function shall extract the Operational Mode data, ME
bits 25 through 40, (see Table 2-68 and 2.2.3.2.7.2.4) from the Aircraft Operational
Status Message (2.2.3.2.7.2) and shall be mapped bit for bit into the 2-byte long
Operational Mode field of the ADS-B Mode Status Report in the binary format specified
in Table 2-88.
20xx, RTCA, Inc.

225
Operational Mode Codes from the ADS-B Aircraft Operational Status Message shall be
mapped bit for bit into the 2-byte long Operational Mode Codes subfield of the ADS-B
Mode Status Report as specified in Table 2-92A.
Table 2-92A: Operational Mode Code Mapping

Operational Status Message Operational Status Message
MS Report
Subtype 0 (Airborne) Subtype 1 (Surface)
MS Report
Msg. Bit # Msg. Bit #
OM Field Parameter
(ME field) (ME field)
Byte # Bit #
7 OM Format 25 25
6 OM Format 26 26
TCAS RA
5 27 27
Active
IDENT
4 28 28
Switch
Reserved for
0 Receiving
3 29 29
ATC
Services
Single
2 Antenna 30 30
Flag
1 Reserved
0 Reserved
7 33
6 34
5 35
GPS
4 36
1 Antenna
3 37
Offset
2 38
1 39
0 40
2.2.8.2.12 SV Quality NACP

The ADS-B Report Assembly Function shall extract the NACP data from the Aircraft
Operational Status Message (2.2.3.2.7.2) and from the Target State and Status Message
(2.2.3.2.7.1.3.8) and map the NACP value bit for bit from the most recently received
ADS-B Message to the Mode Status Report in the binary format specified in Table 2-88.
2.2.8.2.13 SV Quality NACV

The ADS-B Report Assembly Function shall extract the NACV data from the ADS-B
Airborne Velocity Message (2.2.3.2.6), and the Aircraft Operational Status Message
(2.2.3.2.7.2), and map the NACV value bit for bit from the received ADS-B Message to
the Mode Status Report in the binary format specified in Table 2-88.
20xx, RTCA, Inc.

226
2.2.8.2.14 SV Quality SIL, SIL Supplement, SDA
2.2.8.2.14.1 SV Quality Source Integrity Level (SIL)

The ADS-B Report Assembly Function shall extract the SIL data from the Aircraft
Operational Status Message (2.2.3.2.7.2.9) and from the Target State and Status
Message (2.2.3.2.7.1.3.10), and map the SIL Value bit for bit from the most recently
received ADS-B Message to the Mode Status Report in the binary format specified in
Table 2-88.
2.2.8.2.14.2 SV Quality SIL Supplement

The ADS-B Report Assembly Function shall extract the SIL Supplement data from the
Aircraft Operational Status Message (2.2.3.2.7.2.14) and from the Target State and
Status Message (2.2.3.2.7.1.3.1), and map the SIL Supplement value bit for bit from the
most recently received ADS-B Message to the Mode Status Report in the binary format
2.2.8.2.14.3 SV Quality System Design Assurance (SDA)

The ADS-B Report Assembly Function shall extract the SDA data from the Aircraft
Operational Status Message (2.2.3.2.7.2.4.6) and map the SDA value bit for bit from the
most recently received ADS-B Message to the Mode Status Report in the binary format
2.2.8.2.15 SV Quality GVA

The ADS-B Report Assembly Function shall extract the GVA data from the Aircraft
Operational Status Message (2.2.3.2.7.2.8) and map the value of the GVA field to the
Mode Status Report in the format specified in Table 2-88.
2.2.8.2.16 SV Quality NICBARO

The ADS-B Report Assembly Function shall extract the NICBARO data from the Aircraft
Operational Status Message (2.2.3.2.7.2.10) and from the Target State and Status
Message (2.2.3.2.7.1.3.9), and map the value of the NICBARO bit from the most recently
received ADS-B Message to the Mode Status Report in the binary format specified in
Table 2-88. The NICBARO field in the Mode Status Report uses the least significant bit of
a one-byte field as a one-bit flag that indicates whether or not the barometric pressure
altitude that is provided in the State Vector Report has been cross-checked against
another source of altitude.
20xx, RTCA, Inc.

227
2.2.8.2.17 Track/Heading and Horizontal Reference Direction (HRD)

The ADS-B Report Assembly Function shall extract the Track Angle/Heading
(2.2.3.2.7.2.12) and the Horizontal Reference Direction (HRD) (2.2.3.2.7.2.13) flag
bits from the Aircraft Operational Status Message (2.2.3.2.7.2) and set the
True/Magnetic Heading field in the Mode Status Report in the binary format specified in
Table 2-88. This item within the Mode Status Report is used to indicate the nature of the
Horizontal Direction information being reported in the State Vector Reports. This
applies to the aircraft reported Horizontal Direction (in the State Vector Report). The
encoding of bits 0 and 1 of the report True/Magnetic Heading field shall be as specified
in Table 2-93. Bit 1 of the True/Magnetic Heading field indicates when Ground Track is
being reported (i.e., set to zero) or when Heading is being reported (i.e., set to one). Bit 0
of the True/Magnetic Heading field indicates when Heading based on True North (i.e., set
to zero) or when heading based on Magnetic North (i.e., set to one) is being reported.
Table 2-93: True/Magnetic Heading Encoding

Coding
Meaning
bit 1 bit 0
0 0 No Track/Heading or HRD Information Available
0 1 Ground track being reported
1 0 Heading relative to true north being reported
1 1 Heading relative to magnetic north being reported
Note: Bits 2 through 7 of byte 32 of the True/Magnetic Heading subfield are always set
to ZERO (0).
2.2.8.2.18 Vertical Rate Type

The ADS-B Report Assembly Function shall extract the Vertical Rate Source
(2.2.3.2.6.1.10, 2.2.3.2.6.2.10, 2.2.3.2.6.3.10, 2.2.3.2.6.4.10) data from the ADS-B
Airborne Velocity Message (2.2.3.2.6) and set the Vertical Rate Type in the Mode
Status Report in the binary format specified in Table 2-88. The Vertical Rate Type field
uses the least significant bit of a one-byte field in the Mode Status Report. This one-bit
flag shall be set to ZERO (0) to indicate that the Vertical Rate field in the State Vector
Report holds the rate of change of barometric pressure altitude. Or, this one-bit flag shall
be set to ONE (1) to indicate that the Vertical Rate field holds the rate of change of
geometric altitude.
2.2.8.2.19 (Reserved for) Flight Mode Specific Data

A 3-bit field in the Mode Status Report is reserved for future use as a Flight Mode
Specific Data field. In the current version of these MOPS, this field shall be set to ALL
ZEROs.
20xx, RTCA, Inc.

228
2.2.8.3 ADS-B On-Condition Report Characteristics

ADS-B On-Condition Reports include, but will not necessarily be limited to:
a. The Target State Report
b. The Air Referenced Velocity Report
Note: It is anticipated that the Trajectory Change Reports will be specified by a future
revision of these MOPS as an additional type of On-Condition Report.
2.2.8.3.1 ADS-B Target State Report

Target State Reports.
The Report Assembly Function shall be compatible with the current ADS-B Version
Two (2) of the relevant 1090 MHz ADS-B Messages (e.g., Target State and Status,
Subtype=1) that are used as the basis to generate Target State Reports. The relevant
Version Two (2) messages are identified below.
Note: Version 0 messages cannot be used as the basis for Target State Reports, because
there are no Version 0 messages that contain the necessary data elements.
Version 1 message formats for the Target State and Status Message with
Subtype=0 are defined in Appendix N, but are not used to generate the Version 2
Target State Report .
The intent of Table 2-94 is to illustrate the structure of all Items that are required to be
reported in an ADS-B Target State Report. The exact structure of the data indicated in
columns 10 and 11 is provided as a guideline or one possible method of satisfying the
report structure. Implementers may choose to organize the data in another format;
however, delivery to a user interface or application of all Items in Table 2-94 shall be
consistent with the range, resolution, and units indicated in column 7, 8 and 9 of Table 2-
94 respectively. If data is not available to support a field that is delivered to an
application, then the data provided to the application shall be set to ALL ZEROs. Those
requirements in the subparagraphs below that relate to specific data structure details (byte
numbers, and bit numbers within the bytes) shall only apply to equipment that uses the
sample data structure shown in columns 10 and 11 of Table 2-94.
Target State Report elements and how such elements should be structured into
20xx, RTCA, Inc.

20xx, RTCA, Inc.
Table 2-94: ADS-B Target State Data Elements - Source Data Mapping To Report Structure
Table 2-94: ADS-B Target State Data Elements Source Data Mapping To Report Structure
# 1 2 3 4 5 6 7 8 9 10 11
ME Message
Received # of Data
Bits Bits
Report Type and MddL Mddd
0a, 0b 3 N/A N/A 1-5 16 N/A N/A discrete 0-1
Structure Identification dddddddL
0c Validity Flags N/A N/A N/A 16 N/A N/A discrete dddddddd dddddddd 23
Target State & Status - N/A 9 - 32 Mddddddd dddddddd
1 Participant Address AA 24 N/A N/A discrete dddddddL 46
Aircraft ID & Category 68 38 40
2 Address Qualifier Emitter Category All 8 N/A N/A discrete xxxxxMdL 7
Messages with DF=18 CF N/A 68
Report Time of
Target State & Status N/A N/A 511.992187 0.0078125
3 Applicability 16 (1/128) seconds Mddddddd dddddddL 89
5
Selected Altitude: Target State & Status
4a Selected Altitude Type Selected Altitude Type
9 41 8 N/A N/A discrete xxxxxxxL 10
Selected Altitude: Target State &Status
MCP/FCU Selected MCP/FCU Selected
4b Altitude or FMS Selected Altitude or FMS Selected
10 - 20 42 - 52 16 0 - 65472 32 feet xxxxxMdd dddddddL 11 12
Altitude Altitude
Selected Altitude: Target State & Status
Barometric Pressure Selected Altitude: Milli
4c Setting (Minus 800 Barometric Pressure Setting
21 - 29 53 - 61 16 0- 408.0 0.8 xxxxxxxM dddddddL 13 - 14
bars
millibars) (Minus 800 millibars)
Target State & Status
5 Selected Heading
Selected Heading
31 - 39 63 - 71 16 180 0.703125 degrees xxxxxxxS MddddddL 15 - 16
Mode Indicators: Target State & Status
6a Autopilot Engaged Autopilot Engaged
6b VNAV Mode Engaged VNAV Mode Engaged
6c Altitude Hold Mode Altitude Hold Mode
6d Approach Mode Approach Mode
7 Reserved N/A 8 N/A N/A discrete xxxxxxxx 21
TOTAL BYTES: 21
229
230
Notes:
1. In the Data Structure column (i.e., column 10), S indicates the Sign-Bit, M indicates the Most Significant Bit of the data
field, d indicates data bits in the field, L indicates the Least Significant Bit of the data field, and x indicates Dont Care
bits in the data field.
20xx, RTCA, Inc.

231
2.2.8.3.1.1 Report Type and Structure Identification

The Report Type requirements were previously provided in 2.2.8.1.1. Report
Type formats and the maximum number of bytes to be contained in each report
are identified in Table 2-94.
The Report Structure field is used to indicate the exact data parameters identified
in Table 2-94 that are being provided in the Target State Report and is intended
to provide a methodology for the Report Assembly Function to structure shorter
reports when data for some parameters is not available. In order to provide the
capability to provide shorter Target State Reports the following basic
conventions shall be adhered to:
a. Any given data parameter to be used in the report shall use the designated
number of bytes and format as designated in Table 2-94.
b. Parameters that are designated in Table 2-94 are restricted to byte

boundaries.
c. Whenever a data parameter identified in Table 2-94 is not provided in the

report, then it is permissible to concatenate the next parameter to be included
into the report immediately following the inclusion of the previous reported
parameter.
d. Each parameter of the Target State Report identified in Table 2-94 must be
properly declared in the Report Structure field as detailed in the following
paragraphs and Table 2-95.
Note: Implementation of the methodology just provided is realizable and

controllable due to the fact that the exact length of each report
parameter is specified in Table 2-94 and the Report Structure field
identifies exactly which parameters are included in the report.
Therefore, the report user can easily re-construct the length and general
format of the report.
The Report Structure is a 12-bit field and shall be provided in the least
significant nibble (i.e., bits 3 - 0) of the first byte (i.e., byte 0) and continuing
into byte 1 of the Report. The Report Structure format is specified in Table 2-95
where each bit is associated with a particular data parameter of the Target State
Report. If the bit is set to ONE (1), then the data parameter is considered to be
available and shall be transmitted in the report. Otherwise, the data parameter is
considered to not be available and shall not be transmitted in the report. Note
that Table 2-95 does not address the Report Type and Structure Identification
parameter, the Participant Address parameter, the Address Qualifier parameter,
nor the Report Time of Applicability parameter, since these four parameters shall
be included in the Target State Report. Also, certain of the other Target State
data parameters are required to be reported, as specified in 2.2.9, even though
bits have been allocated in the report structure field as shown in Table 2-95.
20xx, RTCA, Inc.

232
Table 2-95: ADS-B Target State Report Structure Parameter Coding

Target State Data Parameter Number of
Byte # Bit #
to be Reported Bytes
3 Selected Altitude: Selected Altitude Type 1
Selected Altitude: MCP/FCU Selected
0 2 2
Altitude or FMS Selected Altitude
Selected Altitude: Barometric Pressure
1 2
Setting (Minus 800 millibars)
0 Selected Heading 2
7 Mode Indicators: Autopilot Engaged 1
6 Mode Indicators: VNAV Mode Engaged 1
5 Mode Indicators: Altitude Hold Mode 1
1 4 Mode Indicators: Approach Mode 1
3 Reserved x
2 Reserved x
1 Reserved x
0 Reserved x
2.2.8.3.1.2 Target State and Status Validty Flags

Validity Flags for data provided in the Target State Report shall be indicated in
bytes #3 and #4 of the Target State Report as shown for item 0c in Table 2-
95A. The Target State Report elements that require Validity Flags are identified
in Table 2-95A. Table 2-95A identifies the byte and bit that shall be used as a
flag for each element that requires a validity flag. Each Validity Flag bit shall be
set to ONE (1) to indicate that the corresponding State Vector Report Element
data is valid. If such data is not valid, then the corresponding Validity Flag bit
shall be set to ZERO (0).
20xx, RTCA, Inc.

233
Table 2-95A: ADS-B Target State Report Validity Flag Requirements

TS
Report Target State Report Validity Flag Bit Required? Validity Flag Bit Assignment
Item # Element
0a Report Type No Byte # Bit #
0b Structure Identification No
3 Report Time of Applicability No
4a Selected Altitude Type No
Yes
MCP/FCU Selected Altitude or
4b FMS Selected Altitude
(This validity flag bit is for Selected 3 7
Altitude Valid)
Yes
Barometric Pressure Setting
4c (Minus 800 millibars)
(This bit is validity flag bit for 3 6
Barometric Pressure Setting Valid)
Yes (This bit is validity flag bit for
5 Selected Heading
Selected Heading Valid)
3 5
Yes (This bit is validity flag bit for
6 MCP / FCU Mode Bits Status
MCP / FCU Mode Bits Valid)
3 4
2.2.8.3.1.3 Participant Address

2.2.8.3.1.4 Address Qualifier

The Address Qualifier is used to indicate the type of Participant Address
(2.2.8.1.3) being reported. The three (3) least significant bits of the one-byte
field are used to convey the Address Qualifier information. The Address
Qualifier subfield shall be coded as shown in Table 2-85.
2.2.8.3.1.5 Report Time of Applicability

Each time that an individual Target State Report is updated, the Report Assembly
Function shall update the Time of Applicability data in the On - Condition
the Established Receiver Unit Time (see 2.2.8.5.2), whichever is applicable to
Report Time of Applicability data shall be provided in the Target State Report in
binary format as specified in Table 2-94.
2.2.8.3.1.6 Selected Altitude: Selected Altitude Type

The Selected Altitude Type parameter shall use the least significant bit within
byte 10 to encode the parameter values specified in 2.2.3.2.7.1.3.2.
20xx, RTCA, Inc.

234
2.2.8.3.1.7 Selected Altitude: MCP/FCU Selected Altitude or FMS Selected Altitude

The MCP / FCU Selected Altitude or FMS Selected Altitude parameter shall use
the three (3) least significant bits within byte 11 and the 8 bits of byte 12 to
encode the parameter values specified 2.2.3.2.7.1.3.3.
2.2.8.3.1.8 Selected Altitude: Barometric Pressure Setting (Minus 800 millibars)

The Barometric Pressure Setting (Minus 800 millibars) parameter shall use the
three (3) least significant bits within byte 13 and the 8 bits of byte 14 to encode
the patameter values specified in 2.2.3.2.7.1.3.4.
2.2.8.3.1.9 Selected Heading

The Selected Heading parameter shall use the least significant bit of byte 15 and
the 8 bits of byte 16 to encode the heading values specified in 2.2.3.2.7.1.3.7.
2.2.8.3.1.10 Mode Indicators: Autopilot Engaged

The Autopilot Engaged parameter shall use the least significant bit within byte
17 to encode the parameter values specified in 2.2.3.2.7.1.3.12.
2.2.8.3.1.11 Mode Indicators: VNAV Mode Engaged

The VNAV Mode Engaged parameter shall use the least significant bit within
byte 18 to encode the parameter values specified in 2.2.3.2.7.1.3.13.
2.2.8.3.1.12 Mode Indicators: Altitude Hold Mode

The Altitude Hold Mode parameter shall use the least significant bit within byte
19 to encode the parameter values specified in 2.2.3.2.7.1.3.14.
2.2.8.3.1.13 Mode Indicators: Approach Mode

The Approach Mode parameter shall use the least significant bit within byte 20
to encode the parameter values specified in 2.2.3.2.7.1.3.16.
2.2.8.3.1.14 Reserved
A one-byte parameter is reserved for possible future use.
2.2.8.3.2 Air Referenced Velocity (ARV) Report

The Air Referenced Velocity (ARV) Report is an On-Condition Report type that
shall be provided when air-referenced velocity information is received from a
target aircraft.
The Report Assembly Function shall be compatible with the current and prior
versions of the relevant 1090 MHz ADS-B Messages (e.g., Airborne Velocity)
20xx, RTCA, Inc.

235
that are used to as the basis to generate Air Referenced Velocity Reports. The
relevant Version Two (2) messages are identified below and the relevant Version
Zero (0) messages, conformant to RTCA DO-260, including Change 1, and the
relevant Version One (1) messages, conformant to RTCA DO-260A, including
Change 1 and Change 2, and their required use for Air Referenced Velocity
Report generation are defined in Appendix N, Section N.5.
If data is not available to support a field that is delivered to an application, then

the data provided to the application shall be set to ALL ZEROs. Table 2-96 and
the subsequent subparagraphs describe the data structure for all ARV Reports.
20xx, RTCA, Inc.

236
Table 2-96: ADS-B Air Referenced Velocity Data Elements - Source Data Mapping To Report Structure

# 1 2 3 4 5 6 7 8 9 10 11
ME Message
Received # of Data
Bits Bits
Report Type and
0a, 0b Structure Identification N/A N/A 1-5 16 N/A N/A discrete MddL xxxx xxxxMddL 0-1
0c Validity Flags N/A N/A N/A 8 N/A N/A discrete xxxxxxML 2

Airborne Velocity Subtype Mddddddd dddddddd
1 Participant Address N/A 9 - 32 24 N/A N/A discrete dddddddL 3-5
3 or 4 AA
Aircraft ID & Category 68 38 40
Emitter Category
2 Address Qualifier All Messages with DF=18
8 N/A N/A discrete xxxxxMdL 6
CF N/A 68
Report Time of Airborne Velocity 0.0078125
3 N/A N/A 16 511.9921875 seconds Mddddddd dddddddL 7-8
Applicability Subtypes 3 or 4 (1/128)
Airborne Velocity -
26 35 58 67 16 0 1000 1 knots xxxxMddd dddddddL
Subtype 3 Airspeed
4a Airspeed 3 9 - 10
- OR -
26 - 35 58 - 67 16 1001 - 4000 4 knots xxxxMddd dddddL00
Subtype 4 - Airspeed
Airborne Velocity - Subtype
4b Airspeed Type 25 57 8 N/A N/A discrete xxxxxxML 11
3 Airspeed Type
Airborne Velocity - Subtype 0 0.3515625
5 Heading While Airborne 15 - 24 47 - 56 16 degrees xxxxxxMd dddddddL 12 - 13
3 Heading 359.6484375 (360/1024)
TOTAL BYTES 14
Notes:
1. In the Data Structure column (i.e., column 10), S indicates the Sign-Bit, M indicates the Most Significant Bit of the data field, d indicates
data bits in the field, L indicates the Least Significant Bit of the data field, 0 indicates the bit is to always be set to a value of ZERO (0), and x
indicates Dont Care bits in the data field.
3. Airspeed is coded with a fixed data structure using the 12 least significant bits of the 2-byte field. For the case where the source message for the air-
referenced velocity information is of the type Airborne Velocity Subtype 3 (2.2.3.2.6.3), a reported resolution of 1 knot is used for airspeed. This
generally applies for aircraft airspeeds of 0 to 1000 knots, although under certain conditions, as described in 2.2.3.2.6.3, an airspeed of up to 1022
knots may be reported with 1 knot resolution. For airspeeds greater than 1000 knots and where the source message for the air-referenced velocity
information is of the type Airborne Velocity Subtype 4 (2.2.3.2.6.4), the two least significant bits are set to a value of ZERO (0) thus providing an
actual reported resolution of 4 knots.
20xx, RTCA, Inc.

237
2.2.8.3.2.1 Report Type and Structure Identification and Validity Flags
2.2.8.3.2.1.1 Report Type and Structure Identification

The Report Type requirements were previously provided in 2.2.8.1.1.1. The Report
Type is provided in the most significant nibble of the first byte of the report. The Report
Type format, coding and the maximum number of bytes (i.e., 13 bytes) to be contained in
each Air Referenced Velocity report are identified in Table 2-96.
2-96 that are being provided in the Air Referenced Velocity report and is intended to
provide a methodology for the Report Assembly Function to structure shorter reports
when data for some parameters is not available. In order to provide the capability to
provide shorter Air Referenced Velocity reports the following basic conventions shall be
adhered to:
b. Parameters that are designated in Table 2-96 are restricted to byte boundaries.
c. Whenever a data parameter identified in Table 2-96 is not provided in the report, then
it is permissible to concatenate the next parameter to be included into the report
immediately following the inclusion of the previous reported parameter.
d. Each parameter of the Air Referenced Velocity report identified in Table 2-96 must
be properly declared in the Report Structure field as detailed in the following
paragraphs and Table 2-97.

The Report Structure Identification parameter is a 12-bit field and shall be encoded in the
least significant nibble (i.e., bits 3 through 0) of the first byte (i.e., byte 0) and
continuing into byte 1 of the Report. The Report Structure Identification parameter
format is specified in Table 2-95 where each bit is associated with a particular subsequent
data parameter of the Air Referenced Velocity Report. If the bit is set to ONE (1), then
the data parameter is considered to be available and shall be transmitted in the report.
Otherwise, the data parameter is considered to not be unavailable and shall not be
transmitted in the report. Note that Table 2-97 does not address the Report Type and
Structure Identification parameter, the Participant Address parameter, the Address
Qualifier parameter, and the Report Time of Applicability parameter since these four
parameters shall be included in each Air Referenced Velocity Report. Also certain
of the other Air Referenced Velocity data parameters are required to be reported,
as specified in 2.2.9.1, even though bits have been allocated in the report structure
field as shown in Table 2-97.
20x, RTCA, Inc.

238
Table 2-97: ADS-B Air Referenced Velocity Report Structure Parameter Coding
Air Referenced Velocity Data Number of
Byte # Bit #
Parameter to be Reported Bytes
3-7 Reserved N/A
2 Airspeed 2
0
1 Airspeed Type and Validity 1
0 Heading While Airborne 2
2.2.8.3.2.1.2 ARV Report Validity Flags

The only Validity Flag specified by these MOPS for the Air Referenced Velocity Report
uses the two (2) least significant bits of the one-byte field as shown in Table 2-98.
Table 2-98: ADS-B Air Referenced Velocity Report Validity Flag Coding
Byte # Bit # Validity Flag Reported
27 Reserved
2 1 Airspeed Valid
0 Heading Valid
The Heading Valid flag bit in the ARV report shall be set to ONE if the Heading
While Airborne field contains valid heading information, or set to ZERO if that field is
known to not contain valid heading information. The reported heading shall be indicated
as not valid if the received ADS-B Airborne Velocity Message (2.2.3.2.6.3 or
2.2.3.2.6.4) includes a Heading Status Bit (2.2.3.2.6.3.6) indicating that Heading
Data is NOT Available.
The Airspeed Valid flag bit shall be set to ONE if the Airspeed field (2.2.8.3.2.6)
contains valid heading information, or ZERO if that field is known to not contain valid
airspeed information. The reported Airspeed shall be indicated as Not Valid if the
received ADS-B Airborne Velocity Message (2.2.3.2.6.3 or 2.2.3.2.6.4) includes either
a value for the Airspeed subfield indicating No Airspeed Information Available, or
includes a value for the NACV subfield that is invalid.
2.2.8.3.2.2 Participant Address

The participant address shall be encoded as specified in 2.2.3.2.1.5.
2.2.8.3.2.3 Address Qualifier

The Address Qualifier is used to indicate the type of Participant Address (2.2.8.1.3)
being reported. The 3 least significant bits of the one-byte field are used to convey the
Address Qualifier information. The Address Qualifier subfield shall be coded as
20xx, RTCA, Inc.

239
2.2.8.3.2.4 Report Time of Applicability

Each time that an individual Air Referenced Velocity Report is updated, the Report
Assembly Function shall update the Time of Applicability data in the Air Referenced
Velocity Report with either the GPS/GNSS UTC Measure Time data (see 2.2.8.5.1) or
the Established Receiver Unit Time (see 2.2.8.5.2), whichever is applicable to the
Report Time of Applicability data shall be provided in the Air Referenced Velocity
report in binary format as specified in Table 2-96.
2.2.8.3.2.5 Airspeed
Airspeed shall be reported over the range of 0 to 4000 knots. The Airspeed parameter is
coded with a fixed data structure using the 4 least significant bits of the first byte and the
8 bits of the second byte of the Airspeed field as identified in Table 2-96. For the case
where the source message for the Air-Referenced Velocity information is of the type
Airborne Velocity Message Subtype=3 (2.2.3.2.6.3), a reported resolution of 1 knot is
used for Airspeed. This generally applies for Aircraft Airspeeds of 0 to 1000 knots,
although under certain conditions, as described in 2.2.3.2.6.3, an Airspeed of up to 1022
knots may be reported with 1 knot resolution. For Airspeeds greater than 1000 knots and
where the source message for the Air-Referenced Velocity information is of the type
Airborne Velocity Message Subtype=4 (2.2.3.2.6.4), the two (2) least significant bits
are set to a value of ZERO (0) thus providing an actual reported resolution of 4 knots.
2.2.8.3.2.6 Airspeed Type

The Airspeed Type and Validity field in the Air Referenced Velocity Report is a 2-bit
field that shall be encoded as specified in Table 2-99. The type of Airspeed being
reported shall be obtained from the Airspeed Type subfield of the ADS-B Airborne
Velocity Message, Subtype=3 (2.2.3.2.6.3) or Subtype=4 (2.2.3.2.6.4). The reported
Airspeed shall be indicated as Not Valid if the received ADS-B Airborne Velocity
Message (2.2.3.2.6.3 or 2.2.3.2.6.4) includes either a value for the Airspeed subfield
indicating No Airspeed Information Available, or includes a value for the NACV
subfield that is invalid. When set to indicate the Airspeed Field is Not Valid, the
corresponding Validity Flag parameter (2.2.8.3.2.1.2) shall also be set to indicate that
the reported Airspeed is not valid.
Table 2-99: Airspeed Type Encoding

Coding Meaning
00 Airspeed Field Not Valid
01 True Airspeed (TAS)
10 Indicated Airspeed (IAS)
11 Reserved for Mach
20x, RTCA, Inc.

240
2.2.8.3.2.7 Heading While Airborne

An Aircrafts Heading is reported as the angle measured clockwise from the reference
direction (magnetic north) to the direction in which the Aircrafts nose is pointing. The
heading field in Air Reference Velocity Reports shall be encoded using the 2 least
significant bits of the first byte and the 8 bits of the second byte of the Heading While
Airborne field as specified in Table 2-96. The encoding shall be the same as that used
in the Heading subfield of the ADS-B Airborne Velocity Message Subtype=3 as
specified in 2.2.3.2.6.3.7.
2.2.8.4 Processing of Reserved Message TYPE Codes

Receivers shall meet the requirements of 2.2.8.1 through 2.2.8.3 when receiving any
valid combination of messages with TYPE Codes 0 through 31 including TYPE Codes
24, 25, 26, 27 and 30.
Note: This requirement ensures that the receipt of ADS-B Messages with reserved
TYPE Codes will not adversely affect the processing of other ADS-B
Messages.
2.2.8.5 Receiving Installation Time Processing
2.2.8.5.1 Precision Installations

Receiving devices intended to generate ADS-B reports based on Surface Position
Messages received from TYPE 5 or 6 (see 2.2.3.2.3.1) equipment or Airborne Position
Messages received from TYPE 9, 10, 20 or 21 (see 2.2.3.2.3.1) equipment shall accept
GPS/GNSS UTC Measure Time data via an appropriate interface. Such data shall be
used to establish Time of Applicability data required in 2.2.8.1.4, 2.2.8.1.17 through
2.2.8.1.20, 2.2.8.2.4, 2.2.8.3.1.5 and 2.2.8.3.2.4.
UTC Measure Time data shall have a minimum range of 300 seconds and a resolution of
0.0078125 (1/128) seconds.
Note: Time of Applicability information is required in Item #s 18 through 23, and 25

of Table 2-81, Item #16 of Table 2-88, and Item #7 of Table 2-94. Each of these
table entries specify the data to be entered in 9 bits of whole number and 7 bits of
fractional data. Therefore, the full range can be up to 511.9921875 seconds
having the required resolution of 0.0078125 seconds.
20xx, RTCA, Inc.

241
2.2.8.5.2 Non-Precision Installations

Receiving devices that are not intended to generate ADS-B reports based on Surface
Position Messages received from TYPE 5 or 6 (see 2.2.3.2.3.1) equipment or Airborne
Position Messages received from TYPE 9, 10, 20 or 21 (see 2.2.3.2.3.1) equipment may
choose not to use GPS/GNSS UTC Measure Time data if there is no requirement to do so
by the end user of the ADS-B reports. In such cases, where there is no appropriate time
reference, the Receiving device shall establish an appropriate internal clock or counter
having a maximum clock cycle or count time of 20 milliseconds. The established cycle
or clock count shall have a range of 300 seconds and a resolution of 0.0078125 (1/128)
seconds in order to maintain commonality with the requirements of 2.2.8.5.1.
Note: Time of Applicability information is required in Item #s 18 through 23, and 25

of Table 2-81, Item #16 of Table 2-88, and Item #7 of Table 2-94. Each of these
table entries specify the data to be entered in 9 bits of whole number and 7 bits of
fractional data. Therefore, the full range can be up to 511.9921875 seconds
having the required resolution of 0.0078125 seconds.
2.2.9 ADS-B Report Type Requirements

Equipage classes are defined to accommodate tiered capabilities according to
increasingly complex operational objectives while preserving basic inter-operability
between classes of equipage. Each equipage class is required to receive messages and
process the recovered information into specific ADS-B reports according to the
applicable capability. The required ADS-B report capabilities for each class of equipage
are specified in the following paragraphs.
2.2.9.1 ADS-B Receiver Reporting Requirements for Class A Equipage

ADS-B Report Requirements for Class A Equipage are specified in Table 2-100. For
each required report type all data elements, as defined in 2.2.8.1 through 2.2.8.3
(inclusive of subparagraphs), shall be included for which valid information is available
(i.e., current information that has been received via one or multiple ADS-B Messages or
is available from an onboard data source). Although the Report Assembly Function is
required to support all data elements specified for the report types applicable to that
Equipage Class, as per Table 2-100, reports may be generated that convey only a subset
of the report elements. This is a consequence of certain data elements only being
applicable while airborne and others that are only applicable while on the surface. Also
the ADS-B Messages may not have been received that included the information
necessary to report a valid value for a given report data element. For each of the four
types of reports there is a set of required data elements that shall be included. The
required set of data elements is specified in Table 2-101 through Table 2-104 (inclusive)
for the four report types.
The Report Assembly Function shall maintain backward compatibility with prior
versions of the relevant 1090 MHz ADS-B Messages (i.e., Airborne Position, Surface
Position, Airborne Velocity, Aircraft Status, Aircraft Operational Status, and Aircraft
Identification and Category) that are used as the basis for generating State Vector, Air
Referenced Velocity and Mode Status Reports. The relevant Version Zero (0) message
formats, conformant to RTCA DO-260, including Change 1, and the relevant Version
20x, RTCA, Inc.

242
One (1) messages, conformant to RTCA DO-260A, including Change 1 and Change 2,
and their required use for ADS-B report generation are defined in Appendix N.
Table 2-100: ADS-B Class A Equipment Reporting Requirements

INTERACTIVE
AIRCRAFT/VEHICLES
OPERATIONAL CAPABILITIES
Equipage Class Airport
Airborne
Surface
ADS-B OUTPUT REPORTS REQUIRED
(Note 1)
AO
Minimum SV SV
Aircraft/ MS MS
Ground Vehicles
A1S/A1
Basic SV SV
Aircraft and MS MS
Ground Vehicles
A2 SV
Enhanced MS SV
Aircraft Only TS MS
(Note 2) TC+0
A3 SV
SV
Extended MS
Aircraft Only TS
MS
(Note 2) TC+n
Notes:
1. The report structure and contents are specified in 2.2.8.1 through 2.2.8.3, inclusive
of the subparagraphs.
2. It is anticipated that future revisions of these MOPS will require that Equipage Class
A2 and A3 systems will also be capable of generating Trajectory Change Reports.
20xx, RTCA, Inc.

243
Table 2-101: ADS-B State Vector Required Report Elements
Report Report Element Description Required

Element #
Report Type and
0a, 0b Yes
Structure Identification
0c Validity Flags Yes
1 Participant Address Yes
2 Address Qualifier Yes
Time of Applicability (Position and
3 Yes
Velocity)
4 Latitude (WGS-84) Note 3
5 Longitude (WGS-84) Note 3
6 Altitude, Geometric (WGS-84) No
7 North/South Velocity Note 3
8 East/West Velocity Note 3
9 Ground Speed while on the Surface Note 1
10 Heading while on the Surface Note 1
Altitude, Barometric
11 Note 2
(Pressure Altitude)
Vertical Rate, Geometric/Barometric
12 No
(WGS-84)
13 Navigation Integrity Category (NIC) Yes
14 Estimated Latitude (WGS-84) Yes
15 Estimated Longitude (WGS-84) Yes
16 Estimated North/South Velocity Note 2
17 Estimated East/West Velocity Note 2
18 Surveillance Status/Discretes No
19 Report Mode No
Notes:
1. Required when the report is for a target Aircraft/Vehicle that is on the airport
surface.
2. Required when the report is for a target aircraft that is airborne.
3. It is required that each new state vector report for an airborne target include report
elements 4 and 5 and/or report elements 7 and 8 since a new state vector report
should only be generated based on the reception of an Airborne Position and/or an
20x, RTCA, Inc.

244
Table 2-102: ADS-B Mode Status Required Report Elements

Required
Report Required
when
Element Report Element Description when A/V is
Aircraft is
Number on Surface
Airborne
0a, 0b Report Type and Structure Yes Yes
0c Validity Flags Yes Yes
1 Participant Address Yes Yes
2 Address Qualifier Yes Yes
3 Time of Applicability Yes Yes
4 ADS-B Version Yes Yes
5a Call Sign Note 1 Note 1
5b Emitter Category Note 1 Note 1
5c A/V Length and Width Code Note 2 No
6 Emergency/Priority Status Note 5 Note 5
7 Capability Codes Note 3 Note 3
8 Operational Mode Note 3 Note 3
9a SV Quality - NACp Note 3 Note 3
9b SV Quality - NACV Note 4 Note 4
9c SV Quality SIL Note 3 Note 3
9d SV Quality BAQ (reserved) No No
9e SV Quality NICBARO No Note 3
10a True/Magnetic Heading Note 2 Note 2
10b Vertical Rate Type Note 4 Note 4
11 Other (Reserved) No No
Notes:
1. Required if an Aircraft Identification Message has been received within the past 200
seconds.
2. Required if an Aircraft Operational Status Message has been received within the past
100 seconds.
3. Required if an Aircraft Operational Status and/or a Target State and Status Message
has been received within the past 100 seconds.
4. Required if an Airborne Velocity Message has been received within the past 100
seconds.
5. Required if an Extended Squitter Aircraft Status Message (TYPE=28, Subtype=1)

and/or Target State and Status Message (TYPE=29, Subtype=0) has been received
within the past 100 seconds.
20xx, RTCA, Inc.

245
Table 2-103: ADS-B Target State Required Report Elements

Report
Element Report Element Description Required
Number
Report Type and Structure
0a, 0b Yes
Identification
3 Report Time of Applicability Yes
Horizontal Intent: Horizontal Data
4a Available & Horizontal Target Yes
Source Indicator
Horizontal Intent: Target Heading or
4b Note 1
Track Angle
Horizontal Intent: Target
4c Note 1
Heading/Track Indicator
Horizontal Intent: Reserved for
4d Note 1
Heading/Track Capability
Horizontal Intent: Horizontal Mode
4e Note 1
Indicator
4f No
Horizontal Conformance
Vertical Intent: Vertical Data
5a Available & Vertical Target Source Yes
Indicator
5b Vertical Intent: Target Altitude Note 2
5c Vertical Intent: Target Altitude Type Note 2
Vertical Intent: Target Altitude
5d Note 2
Capability
Vertical Intent: Vertical Mode
5e Note 2
Indicator
Vertical Intent: Reserved for Vertical
5f No
Conformance
Notes:
1. Required if Report Element 4a indicates that data is available.
2. Required if Report Element 5a indicates that data is available.
20x, RTCA, Inc.

246
Table 2-104: ADS-B Air Referenced Velocity Required Report Elements

Report
Element Report Element Description Required
Number
0a, 0b Report Type and Structure
Yes
Identification
0c Validity Flags Yes
3 Report Time of Applicability Yes
4a Airspeed Yes
4b Airspeed Type and Validity Yes
5 Heading While Airborne Yes
2.2.9.1.1 ADS-B State Vector Reports for Class A Equipage

Equipage Class A0, A1S, A1, A2 and A3 equipment shall provide State Vector Reports
as indicated in 2.2.9.1. An example report format is showin in Table 2-81.
2.2.9.1.2 ADS-B Mode Status Reports for Class A Equipage

Equipage Class A0, A1S, A1, A2 and A3 equipment shall provide Mode Status Reports
as indicated in 2.2.9.1. An example report format is shown in Table 2-88.
2.2.9.1.3 ADS-B Target State Reports for Class A Equipage

a. Equipage Class A0, A1S and A1 equipment are not required to provide Target State
Reports.
b. Equipage Class A2 and A3 equipment shall provide Target State Reports as indicated
in 2.2.9.1. An example report format is shown in Table 2-94.
c. Target State Reports for newly acquired target aircraft shall not be provided until or
unless an Aircraft Operational Status Message (2.2.3.2.7.2) has been received from
the target aircraft indicating an ADS-B Version Number of other than Zero (0).
Note: Version Zero (0) messages that convey trajectory intent information using
message TYPE Code 29 (see Appendix N) are not to be used by 1090 MHz ADS-
B receiving systems conformant to these MOPS for the purpose of report
generation. Therefore a positive determination that the applicable Version
Number is other than Zero (0) for a received message with a TYPE Code of 29 is
necessary in order to avoid errors in the reporting of the aircraft target state.
2.2.9.1.4 ADS-B Air Referenced Velocity Reports for Class A Equipage

a. Equipage Class A0 equipment is not required to provide Air Referenced Reports.
b. Equipage Class A1S, A1, A2 and A3 equipment shall generate an Air Referenced
Velocity Report as indicated in 2.2.9.1. An example report format is shown in
Table 2-96.
20xx, RTCA, Inc.

247
2.2.9.2 ADS-B Receiver Report Content Requirements for Class B Equipage

There are no report requirements for Class B, i.e., Broadcast Only, Equipage.
2.2.10 ADS-B Receiver Report Assembly and Delivery

Note: This paragraph and its subparagraphs describe report assembly and delivery
only for ADS-B Receiving Subsystems. See 2.2.17.4 and its subparagraphs for
requirements on TIS-B report aseembly and delivery.
2.2.10.1 Fundamental Principals of Report Assembly and Delivery
2.2.10.1.1 General Data Flow

Figure 2-19 illustrates the general data flow of ADS-B Messages and Reports for the
purposes of establishing the baseline requirements for Report Assembly and Delivery.
ADS-B MOPs
Boundary
Application
Report
Control
Report Report Report Output

Message Report Data
ADS-B ADS-B Output to Application
Input Assembly
Messages Reports Storage Application Interface Interface
Processing Function
Buffer Interface Control
Specified by the
Specified by the
ADS-B / Application
ADS-B MOPs
Interface Specification
Figure 2-19: ADS-B Message And Report General Data Flow
a. Message Input Processing -- The Message Input Processing is performed by the

ADS-B Message Reception Function previously depicted in Figure 2-16 and
described in 2.2.6.1. The primary function of the Message Input Processing
function is to deliver all received ADS-B Messages to the Report Assembly Function.
b. Report Assembly Function -- The Report Assembly Function receives all ADS-B
Messages from the Message Input Processing Function and structures ADS-B
Reports for delivery to the Report Output Storage Buffer.
It is important to note that the specification of requirements within this document is

considered complete once the ADS-B Reports have been structured and delivered to
the Report Output Storage Buffer. Specifically, the specification of data delivery via
the Application Interface is not addressed in this document. Figure 2-19 illustrates
the boundary of the ADS-B MOPS specification.
20x, RTCA, Inc.

248
c. Report Output Storage Buffer -- The primary purpose of the Report Output
Storage Buffer is to store and maintain all ADS-B reports such that the Reports are
available for extraction by the Application Interface upon demand or as needed.
d. Application Report Control -- The Application Report Control depicted in Figure

2-19 represents an optional function that may be implemented for the application to
provide commands or control to the Report Assembly Function in order to control the
size of various ADS-B reports and/or the conditions under which such reports are
issued.
e. Application Interface -- The Application Interface is responsible for the extraction

of ADS-B reports from the Report Output Storage Buffer via the Report to
Application Interface. Requirements for the Application Interface and Report to
Application Interface are to be specified in various Application Interface
specifications and therefore are not addressed in this document.
Note: Figure 2-20, Figure 2-21 and Figure 2-22 are provided below as a guideline to
assist in understanding the Report Assembly and Delivery Process. As such,
these figures should not be construed as presenting the actual requirements.
Rather, the requirements for Report Assembly and Delivery are provided in the
remaining subparagraphs of 2.2.10.
ion
ept
rec
ty ding
city
o
vel t inclu
ept ge
vel
ode n
rec essa
ion
dec sitio
o ci
or
or
on
rep
m
po
siti
1 st
1 st
1st
t po
las
Initialization State Initialization State
Acquisition State Acquisition State
Track State
Issue 1st report

25 sec. 120 sec.* 200 to 250 sec.
* Retain position in
memory during this time.
Figure 2-20: Illustration of Report State Changes In A Typical Case
20xx, RTCA, Inc.

249
One message received
No messages
received for
200-250
seconds
No position message
received for
Initialization 120 seconds, or
position validation
State Global CPR failed
decode
(even and odd
position
messages both
received within
10 seconds for
Airborne)
Acquisition
State
Position validation
failed
Velocity message
received
No position or velocity
message received for
25 seconds
Track State
Figure 2-21: Report Assembly Airborne State Transition Diagram
20x, RTCA, Inc.

250
The unambiguous CPR

decoding was based on
Receive any message Receive any message Update
surface position
information
from this participant. messages. from this participant.
for this
(2.2.10.1.3.a) Update (2.2.10.3.2) (2.2.10.3.3) participant
information Output SV report.
for this (2.2.10.3.2.c-d,
participant. Receive both "even" and "odd" 2.2.10.3.1.1.b-c)
(2.2.10.1.3) airborne position or surface
Receive any message Set the Report
position messages within a 10 sec The unambiguous CPR Mode to "Track."
from an unknown (Airborne) & 50 sec (Surface)
decoding was based on
period.
(2.2.10.3.2.b,
participant. airborne position messages. 2.2.10.4.1.1.a)
(2.2.10.3.1, 2.2.10.3.2)
(2.2.10.3.1)
Output first MS
Initialize Valid airborne velocity report if MS info
information for Peform available.
Set report Acquisition message received.
this participant. unambiguous Output first SV (2.2.10.4.1.1.e)
(2.2.10.2) mode to State (2.2.10.4.1.1)
Initialization CPR decode, report.
"Acquisition." (2.2.10.3)
State (2.2.10.2.a,
(2.2.10.3.1.b)
(2.2.10.3.1.c-d)
(2.2.10.2) 2.2.10.3.1.a)
Delete SV
report from Output first TSR
Receive airborne
Delete all Report Output report if Target
velocity message. State info is
information about Storage Buffer.
(2.2.10.3.1.f) (2.2.10.4.1.2.b) available.
this participant.
(2.2.10.1.3, Update SV (2.2.10.4.1.1.f)
2.2.10.3.1.g, report with new
2.2.10.3.2.g, 120 seconds elapse without Update SV P, V
200-250 seconds elapse with no a new position message. report with new (2.2.10.4.1.2.b)
messages from this participant. (2.2.10.3.1.f, 2.2.10.3.2.f) position.
Receive airborne (2.2.10.4.1.2.a) Receive surface
(2.2.10.1.3.a-b, 2.2.10.3.1.g,
position message. position message.
2.2.10.3.2.g)
(2.2.10.4.1.2.a) (2.2.10.4.2.2.a)
Return to Acquisition State.

(2.2.10.4.1.3.c, No airborne position, airborne
Update SV
2.2.10.4.2.3.c) velocity, or surface position
Track State report with new
message received for 25 sec P, V.
(Airborne) and 200 sec (Surface). (2.2.10.4)
(2.2.10.4.2.2.a)
Stop output of SV, (2.2.10.4.1.3.a, 2.2.10.4.2.3.a)
MS, TS, & ARV
Reports. Receive new Aircraft
(2.2.10.4.1.3.b,
ID and Type Message
2.2.10.4.2.3.b)
Update MS or new Target State &
report with
Status Message, etc.
new data.
Update TSR (2.2.10.4.1.2.d,
NOTE: This diagram does not itself contain requirements report.
(2.2.10.4.1.2.d,
2.2.10.4.2.2.b) 2.2.10.4.2.2.b)
for the Report Assembly Function. It is only a note (2.2.10.4.1.2.e)
guiding the reader to those requirements provided in the
text of section 2.2.10. Receive new Target
. State & Status Message.
(2.2.10.4.1.2.e)
Detailed Report Assembly State Transition Diagram
Figure 2-22: Detailed Report Assembly State Transition Diagram

2000, RTCA, Inc.
251
2.2.10.1.2 ADS-B Report Organization

a. All ADS-B Message receptions and Reports shall be organized (i.e., indexed) in
accordance with the Participant Address (see 2.2.3.2.1.1) and the Address Qualifier
(see 2.2.8.1.3).
Note: The Participant Address, report element 1 in all ADS-B report structures. Is
conveyed in the AA Address Field of all ADS-B transmitted messages. The
Address Qualifier, report element 2 in all the ADS-B report structures,
denotes whether the address is a 24-bit ICAO aircraft address or some other
kind of address, and is conveyed in the combination of DF fields and, if
DF=18, in the CF field in ADS-B transmitted messages.
b. For the purposes of correlating received ADS-B Messages to existing Reports,

separate Reports shall be maintained for the same Participant Address (see
2.2.3.2.1.1) and Address Qualifier (see 2.2.8.1.3) if DF=17 ADS-B Messages are
received from one aircraft/vehicle and DF=18 Messages from another
aircraft/vehicle.
Note: Duplicate address processing as per 2.2.10.7 helps protect against not
detecting an aircraft/vehicle that is transmitting with the same 24-bit
address. However, duplicate address processing is not required when
addresses can be resolved when one aircraft/vehicle is from a Mode S
transponder based transmitting system and the other is from a Non-
transponder based transmitting system.
c. The Participant Address and the Address Qualifier shall be required elements in all
ADS-B Reports (see Table 2-81 Items 1 and 2, Table 2-88 Items 1 and 2, Table 2-94
Items 1 and 2, and Table 2-96 Items 1 and 2).
2.2.10.1.3 ADS-B Message Temporary Retention

a. Unless otherwise specified, all ADS-B Messages and decoded latitude and longitude
values received for a given Participant shall be appropriately time tagged and
temporarily stored for at least 200 seconds unless replaced by a received message of
equivalent type from that Participant.
Note: This requirement is intended to aid in the start-up of Report Assembly for a
given Participant such that as much data as possible can be provided as
soon as a Track is initialized on the given participant.
b. If no new messages have been received from a given Participant for 250 seconds,
then all records (including temporary storage) relevant to the Participant Address
shall be deleted from temporary storage and from the Report Output Storage Buffer.
2.2.10.1.4 Participant ADS-B Track Files

A Track File is defined as the accumulation of reports maintained on a given participant.
In the ADS-B case, the Track File refers to the State Vector, Mode Status, Target State
and Air Referenced Velocity Reports, which comprise a set of reports maintained on a
given participant.
20xx, RTCA, Inc.

252
The ADS-B Report Assembly function shall maintain one, and only one, Track File, i.e.,
set of reports on any given participant.
2.2.10.2 Report Assembly Initialization State

The Initialization State is entered for any given Participant for which there is no
information upon receipt of any of the following ADS-B Messages received from the
given Participant:
a. Airborne Position Message (i.e., a State Vector Position Message --- Airborne) (see
2.2.3.2.3)
b. Surface Position Message (i.e., a State Vector Position Message --- Surface) (see
2.2.3.2.4)
c. ADS-B Aircraft Identification and Category Message (see 2.2.3.2.5)
d. ADS-B Airborne Velocity Message (see 2.2.3.2.6)
e. Target State and Status Message (see 2.2.3.2.7.1)
f. Aircraft Operational Status Message (see 2.2.3.2.7.2)
Note: Upon the first receptions of airborne-format messages from a target that is
already in the Track State as a Surface Participant, it is not necessary to enter
the Initialization State or the Acquisition State. The target remains in the Track
State, now as an Airborne Participant. Similarly, for the transition from
airborne-format to surface-format messages, if the target is currently in the
Track State, it remains in the Track State, now as a Surface Participant.
2.2.10.3 Report Assembly Acquisition State
2.2.10.3.1 Report Assembly Acquisition State --- Airborne Participant

Upon receipt of an even and an odd encoded Airborne Position Message from a
given Participant within a ten second period, the Report Assembly Function shall:
a. Perform a successful Globally Unambiguous CPR decode of the Participant Position

in accordance with A.1.7.7 of Appendix A. Perform a validation of the resulting
position decode as follows: Compute the distance between own receiver position, if
known, and the Participant Position resulting from the Globally Unambiguous CPR
decode. The position validation is failed if the computed distance is greater than the
maximum operating range of the receiver. If position validation is not failed, then
proceed with subparagraph b below. Otherwise, discard the even and odd
Position Messages used in the attempted Globally Unambiguous CPR decode. The
Report Mode for the given Airborne Participant remains in Initialization State.
Note: If the Airborne Participant has already been in the Track State as a Surface
Participant, then it is not necessary to perform the Globally Unambiguous
CPR Decode.
b. Set the Report Mode to Acquisition for the given Airborne Participant in the State
Vector Report (see 2.2.8.1) in accordance with 2.2.8.1.22,
20xx, RTCA, Inc.
253
c. Structure all possible fields of the State Vector Report for the given Airborne
Participant in accordance with 2.2.8.1 (all subsections inclusive),
d. Deliver the first structured State Vector Report for the given Airborne Participant to
the Report Output Storage Buffer for subsequent access by the Application Interface
on demand,
e. Continue to maintain the integrity of the State Vector Report for the given Airborne
Participant in the Report Output Storage Buffer for at least 200 seconds unless
replaced by an updated State Vector Report or otherwise specified in the following
sections, the conditions of the following subparagraphs shall apply:
f. If a new Position Message is not received within a 120 second period, then the
Globally Unambiguous CPR decode performed in step a. shall be considered to be
invalid, and the Report Assembly Function shall return to the Initialization State. (In
order to proceed to the Track State for the airborne participant, the Globally
Unambiguous CPR decode will need to be repeated.)
Note: This action effectively represents a return to the Initialization State with the
exception that the return is to step a. above, and the report is retained as per
step e. The purpose of this action is to minimize the need to perform the
Globally Unambiguous CPR decode since it is not necessary when position
messages have been received within the reasonable time limit of 120
seconds. This action is illustrated in Figure 2-21.
g. If no new messages have been received from a given Airborne Participant for at least
200 seconds, then all reports relevant to the Participant Address shall be deleted from
the Report Output Storage Buffer.
2.2.10.3.1.1 Latency, Report Assembly Acquisition State --- Airborne Participant

Step 2.2.10.3.1.d shall be completed within 500 milliseconds of receipt of the second
Airborne Position Message of the even and odd pair.
2.2.10.3.2 Report Assembly Acquisition State --- Surface Participant

Upon receipt of an even and an odd encoded Surface Position Message from a given
Participant within a time period of interval X (where X=50 seconds, unless the Ground
Speed in either Surface Position Message is greater than 25 knots, or is unknown, in
which cases X=25 seconds), the Report Assembly Function shall:
a. Perform a successful Globally Unambiguous CPR decode of the Participant Position

in accordance with A.1.7.8 of Appendix A. Perform a validation of the resulting
position decode as follows: Compute the distance between own aircraft position, if
known, and the Participant Position resulting from the Globally Unambiguous CPR
decode. The position validation is failed if the computed distance is greater than the
maximum operating range of the receiver. If position validation is not failed, then
proceed with subparagraph b below. Otherwise, discard the even and odd
Position Messages used in the attempted Globally Unambiguous CPR decode. The
Report Mode for the given Surface Participant remains in Initialization State.
20xx, RTCA, Inc.

254
Note: If the Surface Participant has already been in the Track State as an Airborne
Participant, then it is not necessary to perform the Globally Unambiguous
CPR Decode.
b. Set the Report Mode to Track for the given Surface Participant in the State Vector
Report (see 2.2.8.1) in accordance with 2.2.8.1.22,
c. Structure all possible fields of the State Vector Report for the given Surface
d. Deliver the first structured State Vector Report for the given Surface Participant to
the Report Output Storage Buffer for subsequent access by the Application Interface
on demand,
e. Continue to maintain the integrity of the State Vector Report for the given Surface
Participant in the Report Output Storage Buffer for at least 200 seconds unless
replaced by an updated State Vector Report or otherwise specified in the following
sections, and the conditions of the following subparagraphs shall apply:
f. If a new Position Message is not received within a 120 second period, then the
Globally Unambiguous CPR decode performed in Step a shall be considered to be
invalid, and the Report Assembly Function shall return to the Initialization State. In
order to proceed from the Acquisition State to the Track State, the Globally
Unambiguous CPR decode must be repeated.
Note: This action effectively represents a return to the Initialization State with the
exception that the return is to Step a above, and the report is retained as
per Step e. The purpose of this action is to minimize the need to perform
the Globally Unambiguous CPR decode since it is not necessary when
position messages have been received within the reasonable time limit of 120
seconds. This action is illustrated in Figure 2-21.
g. If no new messages have been received from a given Surface Participant for at least
200 seconds, then all reports relevant to the Participant Address shall be deleted from
2.2.10.3.2.1 Latency, Report Assembly Acquisition State --- Surface Participant

Step 2.2.10.3.2.d shall be completed within 500 milliseconds of receipt of the second
Surface Position Message of the even and odd pair.
2.2.10.3.3 Acquisition State Data Retention

Upon receipt of any of the messages identified in 2.2.10.2 for any given participant, the
received message shall either:
a. Use the message as required in 2.2.10.3.1 for Airborne Participants or 2.2.10.3.2

for Surface Participants, or
b. Retain the message for future use as specified in 2.2.10.1.3.
20xx, RTCA, Inc.

255
2.2.10.4 Report Assembly Track State
2.2.10.4.1 Report Assembly Track State --- Airborne Participant
2.2.10.4.1.1 Report Assembly Track State Initialization --- Airborne Participant

Initialization of the Track State for a given Airborne Participant assumes that the
Acquisition State has been established for the given Participant in accordance with
2.2.10.3.1.
Upon receipt of a valid Airborne Velocity Message (see 2.2.3.2.6) for a given Airborne
Participant, the Report Assembly Function shall:
a. Set the Report Mode to Track for the given Airborne Participant in the State Vector
Report (see 2.2.8.1) in accordance with 2.2.8.1.22,
b. Structure all possible fields of the State Vector Report for the given Airborne
c. Deliver the new State Vector Report for the given Airborne Participant to the Report
Output Storage Buffer within 500 milliseconds of receipt of the Airborne Velocity
Message,
d. Maintain the integrity of the State Vector Report for the given Airborne Participant in
the Report Output Storage Buffer for 100 5 seconds unless replaced by an updated
State Vector Report or otherwise specified in the following sections,
e. Initiate Assembly of Mode Status Reports:
(1). The Report Assembly Function shall review all messages received from the
given Airborne Participant that may have been placed in temporary storage in
accordance with 2.2.10.1.3.
(2). Upon completion of the message review, the Report Assembly Function shall
structure all possible fields of the Mode Status Report for the given Airborne
Participant in accordance with 2.2.8.2 (all subsections inclusive).
(3). The Report Assembly Function shall deliver the new Mode Status Report for
the given Airborne Participant to the Report Output Storage Buffer within 500
milliseconds of receipt of the Airborne Velocity Message which initialized the
Track State.
(4). The Report Assembly Function shall maintain the integrity of the Mode Status
Report for the given Airborne Participant in the Report Output Storage Buffer
100 5 seconds unless replaced by an updated Mode Status Report or
otherwise specified in the following sections.
f. Initiate Assembly of ADS-B Target State Reports:
(1). The Report Assembly Function shall review all messages received from the
given Airborne Participant that may have been placed in temporary storage in
20xx, RTCA, Inc.

256
(2). Upon completion of the message review, the Report Assembly Function shall
structure all possible fields of the ADS-B Target State Report for the given
Airborne Participant in accordance with 2.2.8.3 (all subsections inclusive).
(3). The Report Assembly Function shall deliver the new ADS-B Target State
Report for the given Airborne Participant to the Report Output Storage Buffer
within 500 milliseconds of receipt of the Airborne Velocity Message which
initialized the Track State.
(4). The Report Assembly Function shall maintain the integrity of the ADS-B
Target State Report for the given Airborne Participant in the Report Output
Storage Buffer for 100 5 seconds unless replaced by an updated ADS-B
Target State Report or otherwise specified in the following sections.
2.2.10.4.1.2 Report Assembly Track State Maintenance --- Airborne Participant

The Track State shall be maintained for a given Airborne Participant for as long as
Airborne Position Messages (see 2.2.3.2.3) and Airborne Velocity Messages (see
2.2.3.2.6) are being received from the Participant.
a. Each time that a new Airborne Position Message is received from the given Airborne
(1). Perform a Local CPR decode of the Airborne Participant Position in

accordance with A.1.7.4 and A.1.7.5 of Appendix A. Perform the
reasonableness test identified in 2.2.10.6.3 to verify that the most recently
received position does not represent an unreasonable offset from the previous
aircraft position.
A. If the difference between the TOMRs of the previously received Position

Message and the most recently received Position Message is 30 seconds or
less, and the position decodes resulting from the reasonableness test of
2.2.10.6.3 are less than or equal to 6 NM if the last Position Message
received was an Airborne Position Message, or less than or equal to 2.5
NM if the last Position Message received as a Surface Position Message,
then the validation is successful and complete, and the position can be used
to update the track.
B. If the difference between the TOMRs of the previously received Position

less, and the reported position in the most recently received Position
Message differs from the previously reported position by more than 6 NM
if the last Position Message received was an Airborne Position Message, or
more than 2.5 NM if the last Position Message received as a Surface
Position Message, then the most recently received position shall not be
used to update the track.
(2). Update all possible fields of the State Vector Report for the given Airborne
(3). Deliver the updated State Vector Report to the Report Output Storage Buffer
within 500 milliseconds of receipt of the new Airborne Position Message, and
20xx, RTCA, Inc.

257
(4). Maintain the integrity of the State Vector Report for the given Airborne
Participant in the Report Output Storage Buffer for 100 5 seconds unless
replaced by an updated State Vector Report or otherwise specified in the
following sections.
b. Each time that a new Airborne Velocity Message is received from the Airborne
Participant that contains Ground Referenced Velocity information, the Report
Assembly Function shall:
(1). Update all possible fields of the State Vector Report for the given Airborne
within 500 milliseconds of receipt of the new Airborne Position Message, and
(3). Maintain the integrity of the State Vector Report for the given Airborne
following sections.
c. Each time an ADS-B Airborne Velocity Message (2.2.3.2.6) with Subtype=3 or

4 (i.e., providing Air Referenced Velocity information) is received from the ADS-
B Airborne Participant, then the Report Assembly Function shall:
(1). Update all possible fields of the Air Referenced Velocity Report for the given
ADS-B Airborne Participant in accordance with 2.2.8.3.2 (all subsections
inclusive),
(2). Deliver the updated ARV Report to the Report Output Storage Buffer within
500 milliseconds of receipt of the new ADS-B Airborne Velocity Message, and
(3). Maintain the integrity of the ARV Report for the given ADS-B Airborne
replaced by an updated ARV Report or otherwise specified in the following
sections.
d. Each time that a new Aircraft Identification and Category Message (see 2.2.3.2.5),
Target State and Status Message (see 2.2.3.2.7.1) having system status information,
Aircraft Operational Status Message (see 2.2.3.2.7.2), Airborne Velocity Message
(2.2.3.2.6), or Extended Squitter Aircraft Status Message (see 2.2.3.2.7.8) is
received from the Airborne Participant, the Report Assembly Function shall:
(1). Update all possible fields of the Mode Status Report for the given Airborne
(2). Deliver the updated Mode Status Report to the Report Output Storage Buffer
within 500 milliseconds of receipt of the new Message, and
(3). Maintain the integrity of the Mode Status Report for the given Airborne
replaced by an updated Mode Status Report or otherwise specified in the
following sections.
20xx, RTCA, Inc.

258
e. Each time that a new Target State and Status Message (see 2.2.3.2.7.1) having
Target State information is received from the given Airborne Participant, the Report
Assembly Function shall:
(1). Update all possible fields of the ADS-B Target State Report for the given
Airborne Participant in accordance with 2.2.8.3 (all subsections inclusive),
(2). Deliver the updated ADS-B Target State Report to the Report Output Storage
Buffer within 500 milliseconds of receipt of the new Message, and
(3). Maintain the integrity of the ADS-B Target State Report for the given Airborne
replaced by an updated ADS-B Target State Report or otherwise specified in
the following sections.
2.2.10.4.1.3 Report Assembly Track State Termination --- Airborne Participant

a. The Track State shall be terminated for a given Airborne Participant if no Airborne
Position (see 2.2.3.2.3) or Airborne Velocity Messages (see 2.2.3.2.6) have been
received from the Participant in 25 5 seconds.
b. Upon termination of the Track State for a given Airborne Participant, the Report
Assembly Function shall immediately delete all State Vector, Mode Status, ADS-B
Target State, and Air Referenced Velocity Reports that were placed in the Report
Output Storage Buffer for the given Participant.
Note: The track state termination requires deletion of all reports structured for a
given participant into the Report Output Storage Buffer. Track state
termination does not intend that temporary storage (see 2.2.10.1.3)
established for the given Participant be deleted. The temporary storage is
only deleted if NO ADS-B Messages have been received from the given
Participant for 225 25 seconds.
c. Upon completion of the preceding step b., the Report Assembly Function shall return
to the Report Assembly Acquisition State for the given Airborne Participant as
specified in 2.2.10.3.1.
2.2.10.4.2 Report Assembly Track State --- Surface Participant
2.2.10.4.2.1 Report Assembly Track State Initialization --- Surface Participant

Initialization of the Track State for a given Surface Participant is established in
In addition to the requirements specified in 2.2.10.3.2, the Report Assembly Function

shall initiate assembly of Mode Status Reports as follows:
a. The Report Assembly Function shall review all messages received from the given
Surface Participant that may have been placed in temporary storage in accordance
with 2.2.10.1.3.
20xx, RTCA, Inc.

259
b. Upon completion of the message review, the Report Assembly Function shall
structure all possible fields of the Mode Status Report for the given Surface
c. The Report Assembly Function shall deliver the new Mode Status Report for the
given Surface Participant to the Report Output Storage Buffer within 500
milliseconds of receipt of the last received Surface Position Message that initialized
the Track State.
d. The Report Assembly Function shall maintain the integrity of the Mode Status
Report for the given Surface Participant in the Report Output Storage Buffer 100 5
seconds unless replaced by an updated Mode Status Report or otherwise specified in
the following sections.
2.2.10.4.2.2 Report Assembly Track State Maintenance --- Surface Participant

The Track State shall be maintained for a given Surface Participant for as long as Surface
Position Messages (see 2.2.3.2.4) are being received from the Surface Participant.
a. Each time that a new Surface Position Message is received from the given Surface
(1). Perform a Local CPR decode of the Surface Participant Position in accordance
with A.1.7.4 and A.1.7.6 of Appendix A. Perform the reasonableness test
identified in 2.2.10.6.3 to verify that the most recently received position does
not represent an unreasonable offset from the previous aircraft position.
A. If the difference between the TOMRs of the previously received Position

less, and the position decodes resulting from the reasonableness test of
2.2.10.6.3 are less than or equal to 0.75 NM if the last Position Message
received was a Surface Position Message, or less than or equal to 2.5 NM if
the last Position Message received was an Airborne Position Message, then
the validation is successful and complete, and the position can be used to
update the track.
B. If the difference between the TOMRs of the previously received Position

less, and the reported position in the most recently received Position
Message differs from the previously reported position by more than 0.75
NM if the last Position Message received was a Surface Position Message,
or more than 2.5 NM if the last Position Message received was an Airborne
Position Message, then the most recently received position shall not be
(2). Update all possible fields of the State Vector Report for the given Surface
within 500 milliseconds of receipt of the new Surface Position Message, and
(4). Maintain the integrity of the State Vector Report for the given Surface
20xx, RTCA, Inc.

260

following sections.
b. Each time that a new Aircraft Identification and Category Message (see 2.2.3.2.5),
Aircraft Operational Status Message (see 2.2.3.2.7.2), or Aircraft Status Message
(see 2.2.3.2.7.8) is received from the Surface Participant, the Report Assembly
Function shall:
(1). Update all possible fields of the Mode Status Report for the given Surface
(2). Deliver the updated Mode Status Report to the Report Output Storage Buffer
within 500 milliseconds of receipt of the new Message, and
(3). Maintain the integrity of the Mode Status Report for the given Surface
replaced by an updated Mode Status Report or otherwise specified in the
following sections.
2.2.10.4.2.3 Report Assembly Track State Termination --- Surface Participant

a. The Track State shall be terminated for a given Surface Participant if no Surface
Position Message (see 2.2.3.2.4) has been received from the Participant in 200 5
seconds.
b. Upon termination of the Track State for a given Surface Participant, the Report
Assembly Function shall immediately delete all State Vector and Mode Status
Reports that were placed in the Report Output Storage Buffer for the given
Participant.
Notes:
1. The track state termination requires deletion of all reports structured into the
Report Output Storage Buffer. Track state termination does not intend that
temporary storage (see 2.2.10.1.3) established for the given Participant be
deleted. The temporary storage is only deleted if NO ADS-B Messages have been
received from the given Participant for 225 25 seconds.
2. ADS-B Surface Participants do not generate Trajectory Intent information;

therefore, ADS-B Target State Report assembly is not required for Surface
Participants.
c. Upon completion of the preceding step b., the Report Assembly Function shall return
to the Report Assembly Acquisition State for the given Surface Participant as
2.2.10.5 Minimum Number of Participant Track Files

In the absence of an applied interference environment and other interference, the ADS-B
Report Assembly Function shall be capable of:
20xx, RTCA, Inc.

261
a. Maintaining the minimum number of track files (see 2.2.10.1.4) of any mix of ADS-
B Participants and TIS-B targets as specified in Table 2-105 for a given equipage
class, and
Table 2-105: Minimum Participant Track File Capacity

Equipage Class of ADS-B Minimum Number of
Receiving Subsystem Participant Track Files
A0 100
A1S/A1 200
A2 400
A3 400
b. If the track file capacity of the ADS-B Receiving Subsystem is being exceeded by the
number of participants whose messages are being received by the subsystem, then the
subsystem may choose to discard track files of those participants that are not of
operational interest to the Receiving Subsystem (e.g., range and/or altitude filtering).
2.2.10.6 Reasonableness Tests for CPR Decoding of Received Position Messages
2.2.10.6.1 Reasonableness Test Overview

Although receptions of Position Messages will normally lead to a successful target
position determination, it is necessary to safeguard against Position Messages that would
be used to initiate or update a track with an erroneous position. A reasonableness test
applied to the computed position resulting from receipt of a Position Message can be used
to discard erroneous position updates. Since an erroneous Globally Unambiguous CPR
Decode could potentially exist for the life of a track, a reasonableness test and validation
of the position protects against such occurrences. Likewise, an erroneous Locally
Unambiguous CPR Decode could result in an incorrect position that potentially remains
incorrect for the life of the track.
2.2.10.6.2 Reasonableness Test Applied to Positions Determined from Globally Unambiguous

CPR Decoding
A validation shall be performed to verify the Globally Unambiguous CPR decode
established per 2.2.10.3.1, subparagraph a or 2.2.10.3.2, subparagraph a, using the
following steps:
a. Compute a second Globally Unambiguous CPR decode based on reception of a new

odd and an even Position Message as per 2.2.10.3.1, subparagraph a for an
Airborne Participant, or per 2.2.10.3.2, subparagraph a for a Surface Participant,
both received subsequent to the respective odd and even Position Message used
in the Globally Unambiguous CPR decode under validation.
b. Compare the position decode resulting from the Globally Unambiguous CPR decode
as per subparagraph a above to the Locally Unambiguous CPR decode computed
from the receipt of the current Position Message satisfying subparagraph a above,
Note: The Locally Unambiguous CPR decode is based on the update of the position
derived from the current Globally Unambiguous CPR decode established in
2.2.10.3.1, subparagraph a, or 2.2.10.3.2, subparagraph a.
20xx, RTCA, Inc.
262
c. If the position decodes resulting from subparagraph b above are identical to within
5 meters for an airborne decode and 1.25 meters for a surface decode, then the
validation is complete. Otherwise, the following subparagraph applies:
d. No State Vector Report is generated from the receipt of the current Position Message.
The Report Mode for the given Participant Report Mode is reset to the Initialization
State. All even and odd Position Messages received prior to the respective
even or odd Position Message used in the Globally Unambiguous CPR decode in
subparagraph a above are discarded.
Note: Completion of validation requires reception of both an additional even

and odd Position Message subsequent to the Position Messages used to
satisfy the Globally Unambiguous CPR decode in Acquisition State. In the
case of Airborne Participants, since reception of an Airborne Velocity
Message causes a transition from Acquisition State to Track State, as per
2.2.10.4.1.1, then validation may not be completed until the Airborne
Participant is in the Track State.
2.2.10.6.3 Reasonableness Test Applied to Positions Determined from Locally Unambiguous

CPR Decoding
A validation shall be performed to verify the Locally Unambiguous CPR decode
established per 2.2.10.4.1.2, subparagraph a.(1) for Airborne Participants, or
2.2.10.4.2.2, subparagraph a.(1) for Surface Participants, using the following steps:
a. Compare the Locally Unambiguous CPR decode computed from the reception of a
new odd or even Position Message as per 2.2.10.4.1.2, subparagraph a.(1) for
an Airborne Participant, or per 2.2.10.4.2.2, subparagraph a.(1) for a Surface
Participant, to the current position that was computed from the previously received
Position Message.
b. If the difference between the TOMRs of the previously received Position Message
and the most recently received Position Message is 30 seconds or less, and the
difference in the position decodes resulting from subparagraph a above are less
than or equal to X NM
where:
X=6 for Airborne Participants receiving Airborne Position Messages, or
X=2.5 for Airborne Participants that have received a Surface Position Message, or
X=2.5 for Surface Participants that have received an Airborne Position Message, or
X=0.75 for Surface Participants receiving Surface Position Messages,
then the validation is successful and complete, and the position shall be used to
update the track. Otherwise, the validation is considered failed, and:
1) the most recently received position shall not be used to update the track, and
2) the received position shall be used to initiate or update a candidate duplicate

address track or update a duplicate address track in accordance with
2.2.10.7.
20xx, RTCA, Inc.

263
Notes:
1. If no duplicate address or candidate duplicate address Report exists for this

ICAO 24-bit address, the position message is used to initiate a candidate
duplicate address Report. If a candidate duplicate address Report exists, the
position message is used to update the candidate duplicate address Report.
Otherwise, the position message is used to update the duplicate address Report
unless the position message fails this validation test (see 2.2.10.7).
2. The position threshold value is based on the assumption of a maximum aircraft

velocity of V knots (where V=600 for Airborne and V=50 for Surface) over a
maximum time period of 30 seconds. This yields a maximum positional
difference of approximately 5 NM for Airborne, and 0.5 NM for Surface. An
additional measure of 1 nautical mile for Airborne, and 0.25 for Surface are
added to account for additional ADS-B positional measurement uncertainty. The
position threshold of 2.5 nautical miles between surface and airborne
participants was derived from the assumption of 250 knots maximum speed for a
target transitioning from the surface state to an airborne state over 30 seconds,
yielding approximately 2 nautical miles, with an additional 0.5 NM being added
to allow for positional errors.
2.2.10.7 Duplicate Address Processing

The ICAO 24-bit address transmitted in each ADS-B Message and the derived Address
Qualifier is used to identify and associate the messages for a particular aircraft/vehicle.
Though each aircraft/vehicle should have a unique ICAO 24-bit address, there may be
occasions on which more than one aircraft/vehicle is transmitting the same ICAO 24 bit
address. It is important for ADS-B applications that receive 1090ES ADS-B Reports to
have knowledge of aircraft within receiving range. The requirements in the following
subparagraphs enable detection of a duplicate address aircraft/vehicle when horizontal
position separation is outside of the local CPR reasonableness test criteria of 2.2.10.6.3.
Notes:
1. Without duplicate address detection, an aircraft/vehicle that enters the range of the
receiver with the same ICAO 24-bit address as that of an existing ADS-B Report
would go undetected and message data from the undetected aircraft/vehicle could be
erroneously associated with the existing ADS-B Report.
2. Duplicate Address processing is not required for TIS-B targets. The assumption is
that the ADS-B Ground Stations will protect against any Duplicate Address situation.
2.2.10.7.1 Candidate Duplicate Address Report

A candidate duplicate address Report shall be initiated when a position message is
received for a ICAO 24-bit address that fails the local CPR reasonableness test validation
of 2.2.10.6.3.b and no candidate duplicate address Report or duplicate address Report is
currently active for the received ICAO 24-bit address. If initiated, the candidate
duplicate address Report is set to Initialization State as per 2.2.10.2 and the position
message is stored for this candidate duplicate address Report. The ADS-B Report for
which the position message did not pass the validation test of 2.2.10.6.3.b, the local
20xx, RTCA, Inc.

264
CPR reasonableness test, is the primary ADS-B Report for this ICAO 24-bit address.
Once a candidate duplicate address Report is initiated, association of subsequent position
messages with this ICAO 24-bit address shall be first attempted on the primary ADS-B
Report for this ICAO 24-bit address. If the position message does not pass the validation
test of 2.2.10.6.3.b on the primary ADS-B Report, the position message shall be used to
attempt Track Initialization on the candidate duplicate address Report as per 2.2.10.2.
Notes:
1. TIS-B Reports and ADS-R Reports are separate and distinct from ADS-B Reports as
per 2.2.17 and 2.2.18 so there is no duplicate address issues between these Report
types and ADS-B Reports.
2. Inter-source correlation is addressed in RTCA DO-317.
2.2.10.7.2 Duplicate Address Condition

A duplicate address condition shall be declared for a ICAO 24-bit address when a global
CPR decode is completed by the receipt of both an even and odd position message within
10 seconds for the candidate duplicate address and passes the global CPR reasonableness
test. Once declared, a duplicate address condition shall result in the Duplicate Address
Flag in the State Vector Report set to ON in the ADS-B Report upon output of either
ADS-B Report in the duplicate address condition. ADS-B Position Messages shall be
associated with the ADS-B Report in the duplicate address condition that passes the local
CPR reasonableness test in 2.2.10.6.3.b. Each ADS-B Report in the duplicate address
condition shall be updated upon receipt of other Extended Squitter Messages containing
the duplicate ICAO 24-bit address since there is no means to associate these messages
with the correct aircraft.
ADS-B Position, Velocity, Aircraft Identification and Category and Emergency / Priority
Status (Subtype=1) Messages from aircraft/vehicles with ICAO 24-bit addresses
identified as Duplicate Addresses shall be processed as Version ZERO (0) format
Messages. Since Target State and Status Messages can be associated with the appropriate
MOPS Version Number based on the Subtype and Operational Status Messages contain
the MOPS Version Number, these messages can be decoded directly.
Notes:
1. The Duplicate Address Flag is used to indicate to ADS-B applications that

information associated with that address can not be correctly associated with either
ADS-B Report in the duplicate address condition. Additionally, the correct MOPS
Version Number for each of the aircraft/vehicles can not be readily determined so
interpretation of message data defaults to Version ZERO (0).
2. The update and output of both ADS-B Reports when Extended Squitter Messages are
received with the duplicate ICAO 24-bit address results in additional overhead since
output of both ADS-B Reports possibly occurs upon message reception. However,
this approach gives ADS-B applications the ability to associate information with the
correct ADS-B Report if they choose to attempt to correlate using the additional
provided information.
20xx, RTCA, Inc.

265
The duplicate address condition shall be cleared after 60 seconds has elapsed with no
Position Message update for a Participant with an ADS-B Report identified in the
duplicate address condition. The relevant ADS-B Report for the Participant shall be
deleted from the Report Output Storage Buffer. Output of the remaining ADS-B Report
shall contain a State Vector Report with the Duplicate Address Flag set to OFF.
Note: After clearing the duplicate address condition, the ADS-B Report for the
aircraft/vehicle that continues to receive Position Messages that pass the local
CPR reasonableness test, as well as other 1090ES ADS-B Messages, is retained
and updated as per 2.2.10.4.
2.2.11 Self Test and Monitors
2.2.11.1 Self Test

If a self-test feature or monitor is provided as part of the equipment:
a. The device which radiates test ADS-B Messages or prevents messages from being
broadcast during the test period shall be limited to no longer than that required to
determine the status of the system.
b. The self-test message signal level at the antenna end of the transmission line shall not
exceed -40 dBm.
c. If provision is made for automatic periodic self-test procedure, such self-testing shall
not radiate ADS-B Messages at an average rate exceeding one broadcast every ten
seconds.
2.2.11.2 Broadcast Monitoring
2.2.11.2.1 Transponder-Based Equipment

If the ADS-B Transmitting Subsystem is implemented as part of a Mode S Transponder,
then the squitter monitor required by RTCA DO-181D, 2.2.10.2 (EUROCAE ED-73C,
3.14.2) is sufficient to ensure proper operation of the transmit chain. If the squitter
monitor indicates a failure, the device failure indication shall be asserted.
2.2.11.2.2 Non-Transponder-Based Equipment

If the ADS-B Transmitting Subsystem is a broadcast only device, then a monitor shall be
provided to verify that DF=18 transmissions are generated at the applicable rates
specified in 2.2.3.3 through 2.2.3.3.1.3. Event-Driven Squitter rates are not required to
be monitored to meet this requirement. If the DF=18 transmissions cannot be transmitted
properly, the device failure indication shall be asserted (see 2.2.11.5.1).
20xx, RTCA, Inc.

266
2.2.11.3 Address Verification
2.2.11.3.1 Transponder-Based Equipment

Transponder implemented ADS-B Transmitting Subsystems shall declare a device failure
in the event that its own ICAO 24-bit Address (i.e., the Mode-S Address) is set to all
ZEROs or all ONEs.
2.2.11.3.2 Non-Transponder-Based Equipment

Non-transponder implemented ADS-B Transmitting Subsystems shall declare a device
failure in the event that its own ICAO 24-bit Address is set to all ZEROs or all
ONEs.
2.2.11.4 Receiver Self Test Capability

ADS-B Receiving Devices shall be designed to provide sufficient self-test capability to
detect a loss of capability to receive ADS-B Messages, structure appropriate ADS-B
reports, and make such reports available to the intended user interface. Should the
receiving device detect that these basic functions cannot be performed properly, the unit
shall declare a device failure. Loss of data on external interfaces should not cause the
Receiver Device Failure to be asserted.
2.2.11.5 Device Failure Annunciation
2.2.11.5.1 ADS-B Transmission Device Failure Annunciation

An output shall be provided to indicate the validity/non-validity of the ADS-B
Transmitting Subsystem hardware. Failure to correctly transmit ADS-B Messages
detected by self-test, or the broadcast monitoring function, or the address verification
shall cause the output to assert the FAIL state. Momentary power interrupts shall not
cause the output to assert the FAIL state. Loss of data on external interfaces should not
cause the Transmit Device Failure to be asserted. The status of the ADS-B Transmitting
Subsystem shall be enunciated to the flight crew where applicable. When the ADS-B
Transmit Subsystem is integrated with a Mode S Transponder, the Transponder Fail
signal may be used to indicate ADS-B Transmission Device Failure (refer to DO-181D
2.2.10.4, EURCAE ED-73C, 3.14.3).
2.2.11.5.2 ADS-B Receiving Device Failure Annunciation

An output shall be provided to indicate the validity/non-validity of the ADS-B receiving
device. Failure to accept ADS-B Messages, structure appropriate ADS-B reports, make
such reports available to the intended user interface, or failure detected by self-test or
monitoring functions shall cause the output to assume the invalid state. Loss of data on
external interfaces should not cause the Receiver Device Failure to be asserted.
Momentary power interrupts shall not cause the output to assume the invalid state. The
status of the ADS-B receiving device shall be enunciated to the flight crew where
applicable.
20xx, RTCA, Inc.

267
2.2.11.6 ADS-B Function Fail Annunciation

The ADS-B Transmitting and Receiving Subsystems depend on a position source to
provide the data to populate the ADS-B Messages and Reports. These sources or
interconnects between them and the ADS-B device may fail and prevent the system from
transmitting ADS-B Messages or Reports. In this case, the ADS-B transmit/receive
subsystem cannot function, but there is not a failure of the ADS-B device itself. It is
desirable to indicate that the ADS-B function is failed independently of the ADS-B
Device Failure Annunciation.
If the conditions of setting TYPE Code equal ZERO, as per 2.2.3.2.3.1.3.2 are met, then
the ADS-B Function Fail Annunciation shall be asserted. The status of the ADS-B
Function shall be indicated to the flight crew.
Note: Although it is desirable to have an independent ADS-B Function Fail
annunciation, some legacy airplanes may have to share the ADS-B Device
Failure annunciation to also indicate when an ADS-B Function Fail has
occurred. In the case where the ADS-B Transmitting Subsystem is also
integrated with a Mode S Transponder (2.2.11.5.1), caution should be taken to
ensure that the ADS-B Function Fail is not interpreted as a Mode S Transponder
Device Failure that could generate a subsequent TCAS Fail annunciation.
2.2.12 Response to Mutual Suppression Pulses

Mutual suppression systems may be needed if the aircraft has other pulse L-band (also
known as D-band) equipment on board or if the ADS-B equipment is used in conjunction
with certain Collision Avoidance System equipment.
2.2.12.1 ADS-B Transmitting Subsystem Response to Mutual Suppression Pulses

If the ADS-B transmitting equipment is designed to accept and respond to mutual
suppression pulses from other electronic equipment in the aircraft (to disable the
equipment while the other equipment is transmitting), the equipment shall regain normal
transmission capability not later than 15 microseconds after the end of the applied mutual
suppression pulse.
2.2.12.2 ADS-B Receiving Device Response to Mutual Suppression Pulses

If the ADS-B receiving equipment is designed to accept and respond to mutual
suppression pulses from other electronic equipment in the aircraft (to disable the
equipment while the other equipment is transmitting), the equipment shall regain normal
sensitivity, within 3 dB, not later than 15 microseconds after the end of the applied
mutual suppression pulse.
Note: This document does not establish the design parameters of the mutual
suppression system. However, it is recommended that all sources of mutual
suppression pulses be DC coupled while sinks are AC coupled. This
standardization will prevent source or sink failures from disabling all users of
the mutual suppression pulses.
20xx, RTCA, Inc.

268
2.2.13 Antenna System

ADS B systems require omni-directional antenna(s) for transmitting and receiving.
Separate antenna for receiving and transmitting are not required.
2.2.13.1 Transmit Pattern Gain

The gain of an omni-directional transmit antenna shall not be less than the gain of a
matched quarter-wave stub minus 3 dB over 90 percent of a coverage volume from 0 to
360 degrees in azimuth and from 5 to 30 degrees above the ground plane when installed
at center of 1.2 meter (4 feet) diameter (or larger) flat circular ground plane.
2.2.13.2 Receiver Pattern Gain

The gain of an omni-directional antenna should not be less than the gain of a matched
quarter-wave stub minus one dB over 90% of a coverage volume from 0 to 360 degrees
in azimuth and -15 to +20 degrees in elevation when installed at the center of a 1.2 m (4
ft.) diameter (or larger) circular ground plane that can be either flat or cylindrical.
Note: These requirements are consistent with those provided in RTCA DO-185B,
2.2.4.7.2.1 (EUROCAE ED-143, 2.2.4.7.2.1).
2.2.13.3 Frequency Requirements for Transmit and Receive Antenna(s)

Antenna shall be designed to transmit and receive signals at 1090 1 MHz.
2.2.13.4 Impedance and VSWR

The VSWR produced by each antenna when terminated in a 50 ohm transmission line
shall not exceed 1.5:1 at 1090 MHz.
2.2.13.5 Polarization
Antenna(s) shall be vertically polarized.
2.2.13.6 Diversity Operation

Diversity transmission and/or reception is described in 3.3.1. Such implementations
shall employ two antennas, one mounted on the top and the other on the bottom of the
aircraft. Separate requirements apply to transmitting diversity and receiving diversity as
provide in the following subsections.
2.2.13.6.1 Transmitting Diversity

Transmitting diversity refers to the alternation between the top and bottom-mounted
antennas for the transmission of ADS-B Messages. If an ADS-B Transmitting Subsystem
implements transmitting diversity, it shall transmit each required type of ADS-B
Message alternately from the top and bottom antennas.
20xx, RTCA, Inc.

269
Note: For example, successive Airborne Position Messages would be transmitted on

different antennas. Again, successive messages loaded into a transponders
event-driven register would be transmitted alternately from the top and bottom
antennas.
If transmission diversity is used, the bit described in 2.2.3.2.3.3 shall be set valid.
2.2.13.6.1.1 Transmitting Diversity Channel Isolation

The peak RF power transmitted from the selected antenna shall exceed the power
transmitted from the non-selected antenna by at least 20 dB.
2.2.13.6.2 Receiving Diversity

Receiving diversity refers to an ADS-B Receiving Subsystems use of signals received
from either the top antenna, or the bottom antenna, or both antennas. For the purpose of
these requirements, several alternate ADS-B Receiving Subsystem architectures that
employ receiving antenna diversity are illustrated in Figure 217.
a. Full receiver and message processing function diversity:
(see Figure 2-23, part b1.)
There are two receiver input channels, each with its own receiver front end, preamble
detection, bit demodulation, error detection, and error correction functions. Channel
selection is based on declaration of a correct message by the parity error detection
function. In the event that both channels produce an identical correct message with
no parity errors, the message from either channel can be selected as the received
message, which is then delivered to the report assembly function. In the event each
channel produces valid, but different messages, both shall be delivered to the report
assembly function.
b. Receiver Switching Front-end Diversity:
There are two receiver input channels, each with its own receiver front end and
preamble detection; followed by single channel bit, demodulation, error detection,
and error correction functions. Channel selection is based on the detection of valid
preamble pulse patterns and connection of the single string elements to the receiver
input having the strongest preamble pulse pattern. In the event that the preamble
pulse patterns for both channels are within 1 dB of each other, either receiver input
may be selected.
c. Receiving antenna switching:
A single receiver input channel, consisting of receiver RF front end, preamble

detection, bit demodulation, and error detection and correction functions, is internally
connected alternately and periodically to the top and bottom antennas. If this method
is implemented, switching shall cause the channel to dwell for 2.0 seconds on each
antenna and continue an alternating transition every 2 0.1 seconds. The switching
20xx, RTCA, Inc.
270
function shall result in loss of no more than 1 input message for each transition when
the RF message signals are present at the required maximum incoming message rate
of 8000 ADS-B Messages per second.
Notes:
1. The maximum rate is derived from 2.2.4.3.4.1.which infers that the receiver
sensitivity threshold will be recovered in not more than 120 microseconds after
the detection of the preamble. Therefore, the minimum separation between the
leading edge of the first preamble pulse of two successive ADS-B Messages is
established at 125 microseconds, thereby establishing the maximum possible
short term rate of 8,000 ADS-B Messages per second.
2. The maximum rate identified above is not typical of the future ADS-B
environment and should not be applied to the ADS-B Receiving Subsystem as a
steady state rate. This high rate should be applied to the ADS-B Receiving
Subsystem for short durations that are adequate to demonstrate compliance of
the ADS-B Receiving Subsystem.
ADS-B Receiving Subsystems which implement antenna switching to a single receiver as

discussed in c, shall provide a method of delivering all ADS-B Messages to an
appropriate output interface for the purpose of monitoring the message throughput
capability of the Receiving Subsystem (see Figure 2-23, part a., MOPS test point).
d. Other switching diversity techniques. Other diversity implementations may be used.

Any implementation must meet the requirements of (a) or (b) above.
20xx, RTCA, Inc.

271
Part a.
ADS-B
Application
ADS-B Receiving Subsystem Application

Report
Report Control
Message Data Interface Control
Report Report
Message Assembly Application
Output Data
Reception Function Interface
Storage
Function (Type 1 or Control Output
Type 2)
Buffer Control
MOPS test point
Part b.
Receiver Bit Error

Preamble Bit Bit Error
RF front Detection
detection demodulation Correction
end (parity check) Message
data
Receiver Bit Error

Preamble Bit Bit Error
RF front Detection
detection demodulation Correction
end (parity check)
b1. Full Message Reception Function Diversity
Receiver
Preamble
RF front Message
detection
end data
Bit Error
Bit Bit Error
Detection
demodulation Correction
(parity check)
Receiver
Preamble
RF front
detection
end
b2. Receiver Front End Switching Diversity
Receiver Bit Error

Preamble Bit Bit Error Message
RF front Detection
detection demodulation Correction data
end (parity check)
b3. Antenna Switching
Figure 2-23: Various ADS-B Receiving Architectures.
20xx, RTCA, Inc.

272
2.2.14 Interfaces
2.2.14.1 ADS-B Transmitting Subsystem Interfaces
2.2.14.1.1 ADS-B Transmitting Subsystem Input Interfaces

Data delivery mechanisms shall ensure that each data parameter is provided to the input
function of the ADS-B Transmitting Subsystem at sufficient update rates to support the
ADS-B Message Update Rates provided in 2.2.3.3 through 2.2.3.3.2.11.
2.2.14.1.1.1 Discrete Input Interfaces

Appropriate discrete inputs may be used to provide the ADS-B Transmitting Subsystem
with configuration and control information. When implemented, all discrete inputs shall
provide appropriate diode isolation to prevent sneak current paths.
2.2.14.1.1.2 Digital Communication Input Interfaces

Approved Avionics Digital Communication interfaces shall be used to provide all digital
data parameters (including control information) to the ADS-B Transmitting Subsystem.
Such input interfaces shall implement appropriate error control techniques (i.e., parity as
a minimum) to ensure that data is properly delivered to the ADS-B Transmitting
Subsystem control and message generation functions.
2.2.14.1.1.3 Processing Efficiency

The ADS-B Transmitting Subsystem input processing function shall be capable of
efficiently processing all data input interfaces in a manner that ensures that the most
recent update received for all required data parameters is made available to the message
generation function to support the rates identified in 2.2.3.3 through 2.2.3.3.2.11.
2.2.14.1.2 ADS-B Transmitting Subsystem Output Interfaces
2.2.14.1.2.1 Discrete Output Interfaces

Appropriate discrete outputs may be used by the ADS-B Transmitting Subsystem to
provide Mode Status and Failure Monitoring information to other users or monitoring
equipment. When implemented, all discrete outputs shall provide appropriate diode
isolation to prevent sneak current paths.
2.2.14.1.2.2 Digital Communication Output Interfaces

Appropriate Avionics Digital Communication output interfaces shall be implemented by
the ADS-B Transmitting Subsystem to provide status and data communication to other
user or monitoring equipment. Such output interfaces shall implement appropriate error
control techniques (i.e., parity as a minimum) to ensure that data is properly delivered to
other user or monitoring equipment.
20xx, RTCA, Inc.

273
2.2.14.2 ADS-B Receiving Device Interfaces
2.2.14.2.1 ADS-B Receiving Device Input Interfaces
2.2.14.2.1.1 Discrete Input Interfaces

Appropriate discrete inputs may be used to provide the ADS-B Receiving device with
configuration and control information. When implemented, all discrete inputs shall
provide appropriate diode isolation to prevent sneak current paths.
2.2.14.2.1.2 Digital Communication Input Interfaces

Approved Avionics Digital Communication interfaces shall be used to provide all digital
data parameters (including control information) to the ADS-B Receiving Device. Such
input interfaces shall implement appropriate error control techniques (i.e., parity as a
minimum) to ensure that data is properly delivered to the ADS-B Receiving device
control and Report Assembly functions.
2.2.14.2.1.3 Processing Efficiency

The ADS-B Receiving Device input processing function shall be capable of efficiently
processing all data input interfaces in a manner that ensures that the most recent update
received for all required data parameters is made available to the Report Assembly
function.
2.2.14.2.2 ADS-B Receiving Device Output Interfaces
2.2.14.2.2.1 Discrete Output Interfaces

Appropriate discrete outputs may be used by the ADS-B Receiving device to provide
Mode Status and Failure Monitoring information to other users or monitoring equipment.
When implemented, all discrete outputs shall provide appropriate diode isolation to
prevent sneak current paths.
2.2.14.2.2.2 Digital Communication Output Interfaces

Appropriate Avionics Digital Communication output interfaces shall be implemented by
the ADS-B Receiving device to provide status and data communication to other user or
monitoring equipment. Such output interfaces shall implement appropriate error control
techniques (i.e., parity as a minimum) to ensure that data is properly delivered to other
user or monitoring equipment.
2.2.15 Power Interruption

The ADS-B transmitting and/or receiving equipment shall regain operational capability
to within its operational limits within two seconds after the restoration of power
following a momentary power interruption.
Note: The ADS-B transmitting and/or receiving equipment is not required to continue
operation during momentary power interruptions.
20xx, RTCA, Inc.

274
2.2.16 Compatibility with Other Systems
2.2.16.1 EMI Compatibility

The ADS-B transmitting and/or receiving equipment shall not compromise the operation
of any co-located communication or navigation equipment, or ATCRBS and/or Mode-S
transponders. Likewise, the ADS-B antenna shall be mounted such that it does not
compromise the operation of any other proximate antenna.
2.2.16.2 Compatibility with GPS Receivers

of a co-located proximate GPS receiver.
2.2.16.3 Compatibility with Other Navigation Receivers and ATC Transponders

of VOR, DME, ADF, LORAN, ATCRBS or Mode-S equipment installed in a proximate
location.
In addition, the ADS-B receiver must be fully operational when located in close
proximity of an ATCRBS or Mode-S transponder.
2.2.17 Traffic Information Services Broadcast (TIS-B)
2.2.17.1 Introduction
This section defines the formats and coding for a Traffic Information Service Broadcast
(TIS-B) based on the same 112-bit 1090 MHz signal transmission that is used for ADS-B
on 1090 MHz.
TIS-B complements the operation of ADS-B by providing ground-to-air broadcast of

surveillance data on aircraft that are not equipped for 1090 MHz ADS-B. The basis for
this ground surveillance data may be an ATC Mode S radar, a surface or approach multi-
lateration system or a multi-sensor data processing system. The TIS-B ground-to-air
transmissions use the same signal formats as 1090 MHz ADS-B and can therefore be
accepted by a 1090 MHz ADS-B receiver.
TIS-B service is the means for providing a complete surveillance picture to 1090 MHz
ADS-B users during a transition period. After transition, it also provides a means to cope
with a user that has lost its 1090 MHz ADS-B capability.
20xx, RTCA, Inc.

275
2.2.17.2 TIS-B Format Structure

TIS-B information is broadcast using the 112-bit Mode S DF=18 format as shown in
Figure 2-24.
TIS-B Baseline Format Definition

Bit # 1 ----- 5 6 --- 8 9 -------- 32 33 ----------------------------- 88 89 ------ 112
DF CF AA ME PI
DF=18 [5] [3] [24] [56] [24]
10010
MSB MSB MSB MSB MSB
LSB LSB LSB LSB LSB
Figure 2-24: TIS-B Baseline Format Definition
The content of the DF=18 transmission is defined by the value of the Control Field (CF),
as specified in Table 2-106.
Table 2-106: CF Field Code Definitions in DF=18 ADS-B and TIS-B Messages
ICAO/Mode A
CF Value Meaning
Flag (IMF)
ADS-B Message from a non-transponder device,
0 N/A
AA field holds 24-bit ICAO aircraft address
Reserved for ADS-B Message in which the AA field holds
1 N/A anonymous address or ground vehicle address or fixed
obstruction address
Fine TIS-B Message,
0
AA field contains the 24-bit ICAO aircraft address
2 Fine TIS-B Message,
1 AA field contains the 12-bit Mode A code followed by a 12-bit track
file number
Coarse TIS-B Airborne Position and Velocity Message,
0
3 Coarse TIS-B Airborne Position and Velocity Message,
1 AA field contains the 12-bit Mode A code followed by a 12-bit track
file number.
TIS-B and ADS-R Management Message
4 N/A
AA contains TIS-B/ADS-R management information.
Fine TIS-B Message
0
5 AA field contains a non-ICAO 24-bit address
1 Reserved
Rebroadcast of ADS-B Message from an alternate data link.
0
6 Rebroadcast of ADS-B Message from an alternate data link.
1 AA field holds anonymous address or ground vehicle address or
fixed obstruction address
7 N/A Reserved
20xx, RTCA, Inc.

276
2.2.17.2.1 DF Downlink Format

This field will be set to DF=18 for TIS-B to indicate that this transmission is not from a
Mode S transponder. See 2.2.3.2.1.1.
2.2.17.2.2 CF Control Field

The CF field of DF=18 messages is a 3-bit field (bits 6 through 8) used by Non-
Transponder-Based installations. This field will be set to 2, 3, 4 or 5 depending upon the
TIS-B Message as specified in Table 2-106. The ADS-B Receiving Subsystem shall
accept and process DF=18, with CF=2, CF=3, CF=4 and CF=5 as TIS-B Messages.
2.2.17.2.3 AA Address Announced Field

As specified in Table 2-106, the ADS-B Receiving Subsystem shall interpret the AA
field as either:
(1) the 24-bit aircraft address as specified in 2.2.3.2.1.1, or
(2) the 12-bit Mode A code followed by a 12-bit track number.
2.2.17.2.4 ME Message Extended Squitter Field

This field is specified in 2.2.3.2.1.6.
2.2.17.2.5 PI Parity/Identity Field

This field is specified in 2.2.3.2.1.7.
20xx, RTCA, Inc.

277
2.2.17.3 TIS-B Messages
2.2.17.3.1 TIS-B Fine Airborne Position Message
TIS-B Fine Airborne Position Message Format
MSG 33 --- 37 38 --------- 39 40 41 ----- 52 53 54 55 -------- 71 72 -------- 88

BIT #
ME 1 ----- 5 6 ------------ 7 8 9 ----- 20 21 22 23 -------- 39 40 -------- 56

BIT #
CPR CPR CPR
Reserved
Surveillance Pressure
Field TYPE IMF Format Encoded Encoded
[1]
Status Altitude
Name [5] [1] (F) Latitude Longitude
[2] [12]
[1] [17] [17]
MSB MSB MSB MSB MSB
LSB LSB LSB LSB LSB
Note: [#] provided in the Field Name column indicates the number of bits in the
respective field.
Figure 2-25: TIS-B Fine Airborne Position Message Format
2.2.17.3.1.1 Relationship to ADS-B Format

The following fields shall be decoded as specified for the ADS-B Airborne Position
Message defined in 2.2.3.2.3:
TYPE Code Surveillance Status
Altitude CPR Format
Encoded Latitude Encoded Longitude
The TYPE Code shall be decoded according to the TYPE Code Format in Table N-
XXXXXX.
Note: TIS-B Service Airborne Position Message TYPE Codes are consistent with ADS-
B Version ONE (1) definitions.
2.2.17.3.1.2 ICAO/Mode A Flag (IMF)

This 1-bit (ME bit 8) field shall be used to indicate the type of identity associated with
the aircraft data reported in the TIS-B Message. IMF equal to ZERO (0) shall indicate
that the TIS-B data is identified by an 24-bit Aircraft address. IMF equal to ONE (1)
indicates that the TIS-B data is identified by a Mode A Code. A Mode A Code of all
ZEROs indicates a primary radar target.
Note: The AA field is coded differently for 24-bit addresses and Mode A codes as
20xx, RTCA, Inc.

278
2.2.17.3.2 TIS-B Fine Surface Position Message
TIS-B Fine Surface Position Message Format
MSG
33 -- 37 38 ------- 44 45 46 ----- 52 53 54 55 ------- 71 72 -------- 88
BIT #
ME
1 ----- 5 6 --------- 12 13 14 ----- 20 21 22 23 ------- 39 40 -------- 56
BIT #
CPR CPR CPR

Heading
Field TYPE Movement Heading IMF Format Encoded Encoded
Status
Name [5] [7] [7] [1] (F) Latitude Longitude
[1]
[1] [17] [17]
MSB MSB MSB MSB MSB
LSB LSB LSB LSB LSB
respective field.
Figure 2-26: TIS-B Fine Surface Position Message Format

The following fields shall be coded as specified for the ADS-B Surface Position Message
defined in 2.2.3.2.4:
TYPE Code Movement
Heading Status Heading
CPR Format Encoded Latitude
Encoded Longitude
The TYPE Code shall be decoded according to the TYPE Code Format in Table N-
XXXXXX.
Note: TIS-B Service Surface Position Message TYPE Codes are consistent with ADS-B
Version ONE (1) definitions.

This 1-bit (ME bit 21) field shall be set as specified in 2.2.17.3.1.2.
20xx, RTCA, Inc.

279
2.2.17.3.3 TIS-B Identification and Category Message
TIS-B Identification and Category Message Format

MSG
BIT 33 - 37 38 - 40 41 - 46 47 - 52 53 - 58 59 - 64 65 - 70 71 - 76 77 - 82 83 88
#
ME
BIT 1-5 6-8 9 - 14 15 - 20 21 - 26 27 - 32 33 - 38 39 - 44 45 - 50 51 56
#
Ident Ident Ident Ident Ident Ident Ident Ident
Emitter
FIELD TYPE Char Char Char Char Char Char Char Char
Category
NAME [5] #1 #2 #3 #4 #5 #6 #7 #8
[3]
[6] [6] [6] [6] [6] [6] [6] [6]
MSB MSB MSB MSB MSB MSB MSB MSB MSB MSB
LSB LSB LSB LSB LSB LSB LSB LSB LSB LSB
respective field.
Figure 2-27: TIS-B Identification and Category Message Format

All of the fields of the TIS-B Identification and Category Message shall be coded as
specified for the ADS-B Identification and Category Message specified in 2.2.3.2.5.
Note: This message will only be used for aircraft identified with a 24-bit Aircraft
address.
20xx, RTCA, Inc.

280
2.2.17.3.4 TIS-B Velocity Message
TIS-B Velocity Message Subtypes 1 and 2

MSG
BIT 33 - 37 38 - 40 41 42 - 45 46 47 - 56 57 58 - 67 68 69 70 - 78 79 80 - 82 83 - 84 85 88
#
ME
BIT 1-5 6-8 9 10 - 13 14 15 - 24 25 26 - 35 36 37 38 - 46 47 48 - 50 51 - 52 53 56
#
Vertical Rate Sign Bit [1]

GEO
E/W Direction Bit [1]
N/S Direction Bit [1]
NIC Supplement [1]

Flag NACV SIL Reserved
=0 [3] [2] [4]
E/W N/S [1] Vert
FIELD TYPE Subtype IMF NACP
Velocity Velocity Rate
NAME [5] [3] [1] [4]
Sign Bit [1]

[10] [10] [9]
Difference
GEO Geometric Height
Reserved
Flag Difference From
[1]
=1 Barometric
[1] [7]
Note: [#] provided in the Field Name column indicates the number of bits in the respective field.
Figure 2-28: TIS-B Velocity Message, Subtypes 1 and 2
20xx, RTCA, Inc.

281
TIS-B Velocity Message Subtypes 3 and 4

MSG
BIT 33 - 37 38 - 40 41 42 - 45 46 47 - 56 57 58 - 67 68 69 70 - 78 79 80 - 82 83 - 84 85 88
#
ME
BIT 1-5 6-8 9 10 - 13 14 15 - 24 25 26 - 35 36 37 38 - 46 47 48 - 50 51 - 52 53 56
#
Vertical Rate Sign Bit [1]
True/Mag
GEO
Reserved
Reserved
Heading Status Bit [1]
NIC Supplement [1]

Airspeed Typet [1]
Flag NACV SIL
[2]
[1]
[1]
=0 [3] [2]
Heading Airspeed [1] Vert
FIELD TYPE Subtype IMF NACP
Rate
NAME [5] [3] [1] [4]
Sign Bit [1]

[10] [10] [9]
Difference
GEO Geometric Height
Reserved
Flag Difference From
[1]
=1 Barometric
[1] [7]
Note: [#] provided in the Field Name column indicates the number of bits in the respective field.
Figure 2-29: TIS-B Velocity Message, Subtypes 3 & 4
20xx, RTCA, Inc.

282

The following fields shall be coded as specified for the ADS-B Velocity Message with
Subtype=1, as specified in 2.2.3.2.6.1, or Subtype=2, as specified in 2.2.3.2.6.2:
E/W Direction Bit E/W Velocity
N/S Direction Bit N/S Velocity
Vertical Rate Sign Vertical Rate
Height Difference Sign Bit Geometric Height Difference from Baro
Vertical Rate Type

This one-bit (ME bit 9) field shall be set as specified in 2.2.17.3.1.2.
2.2.17.3.4.3 Navigation Integrity Code (NIC) Supplement

This one-bit (ME bit 47) field shall be used together with the Message TYPE Code to
define the NIC value for the Airborne and Surface Position Messages.
Coding of the NIC Supplement field shall be as specified in Table N-XXXXX.
2.2.17.3.4.4 Navigation Accuracy Category for Position (NACP)

This four-bit (ME bits 10 through 13) field shall define the NACP value for the
Airborne and Surface Position Messages.
Coding of the NACP field shall be as specified for the Aircraft Operational Status
Message in Table 2-71.
2.2.17.3.4.5 Navigation Accuracy Category for Velocity (NACV)

This 3-bit (ME bits 48 through 50) field shall define the NACV value for the Airborne
Velocity Message when the GEO Flag is equal to ZERO (0). Coding of the NACV field
shall be as specified in 2.2.3.2.6.1.5.
2.2.17.3.4.6 Surveillance Integrity Level (SIL)

This two-bit (ME bits 52 and 53) field shall define the SIL value for the Airborne and
Surface Position Messages when the GEO Flag is equal to ZERO (0). Coding of the SIL
field shall be as specified in Table N-XXXXX.
2.2.17.3.4.7 True/Magnetic Heading Type

This one-bit (ME bit 55) field shall define the True or Magnetic Heading value for the
Airborne Velocity Message when the GEO Flag is equal to ZERO (0) for a Subtype of 3
or 4. Coding of the True/Magnetic Heading Type field shall be as specified in
2.2.3.2.7.2.13.
20xx, RTCA, Inc.

283
2.2.17.3.5 TIS-B Coarse Position Message
TIS-B Coarse Position Message Format
MSG
BIT 33 34 ------- 35 36 -----39 40 -- 51 52 53 --- 57 58 -- 63 64 65 ------ 76 77 ------ 88
#
ME
BIT 1 2 --------- 3 4 ------- 7 8 ---19 20 21 --- 25 26 -- 31 32 33 ------ 44 45 ------ 56
#
Service
Ground Ground CPR CPR CPR
Surveillance Volume Pressure Ground
Field IMF Track Track Format Encoded Encoded
Status ID Altitude Speed
Name [1] Status Angle (F) Latitude Longitude
[2] (SVID) [12] [6]
[1] [5] [1] [12] [12]
[4]
MSB MSB MSB MSB MSB MSB MSB
LSB LSB LSB LSB LSB LSB LSB
respective field.
Figure 2-30: TIS-B Coarse Position Message Format

The format of the TIS-B Coarse Position Message is not related to any ADS-B format.
The format is specified in the following subparagraphs.

This one-bit (ME bit 1) field shall be set as specified in 2.2.17.3.1.2.
2.2.17.3.5.3 Service Volume ID (SVID)

The 4-bit (ME bits 4 through 7) SVID field shall be decoded to identify the TIS-B site
that delivered the surveillance data.
Note: In the case where TIS-B Messages associated with a specific target are being
received from more than one TIS-B ground station, the receiving application can
use the SVID to select coarse messages from a single source. This will prevent
the receiving applications TIS-B track from wandering due to the different error
biases associated with different sources.
2.2.17.3.5.4 Pressure Altitude

This 12-bit (ME bits 8 19) field shall be decoded as specified in 2.2.3.2.3.4.1.
20xx, RTCA, Inc.

284
2.2.17.3.5.5 Ground Track Status

This one bit (ME bit 20) field shall define the validity of the Ground Track value.
Coding for this field shall be as follows: 0=not valid and 1= valid.
2.2.17.3.5.6 Ground Track Angle

This 5-bit (ME bits 21 through 25) field shall define the direction (in degrees
clockwise from true north) of aircraft motion. The Ground Track shall be encoded as an
unsigned angular weighted binary numeral, with an MSB of 180 degrees and an LSB of
360/32 degrees, with ZERO (0) indicating true north. The data in the field shall be
rounded to the nearest multiple of 360/32 degrees.
2.2.17.3.5.7 Ground Speed

This 6-bit (ME bits 26 through 31) field shall define the aircraft speed over the ground.
Coding of this field shall be as shown in Table 2-107.
Table 2-107: Ground Speed Encoding

Coding Meaning
(Binary) (Decimal) (Ground Speed in knots)
00 0000 0 No Ground Speed information available
00 0001 1 Ground Speed < 16 knots
00 0010 2 16 knots GS < 48 knots
00 0011 3 48 knots GS < 80 knots
*** *** ***
11 1110 62 1936 knots GS < 1968 knots
11 1111 63 GS 1968 knots
Notes:
1. The encoding shown in the table represents Positive Magnitude data only.
2. Raw data used to establish the Ground Speed Subfield will normally have more
resolution (i.e., more bits) than that required by the Ground Speed Subfield. When
converting such data to the Ground Speed Subfield, the accuracy of the data must be
maintained such that it is not worse than LSB where the LSB is that of the
Ground Speed Subfield.
2.2.17.3.5.8 Encoded Latitude and Longitude

The Encoded Latitude field shall be decoded consistent with the format specified in
2.2.3.2.3.7, except that the 12-bit CPR coding specified in Appendix A, A.1.7 shall be
used.
The Encoded Longitude field shall be decoded consistent with the format specified in
2.2.3.2.3.8, except that the 12-bit CPR coding specified in Appendix A, A.1.7 shall be
used.
20xx, RTCA, Inc.

285
2.2.17.4 TIS-B Message Processing and Report Generation

The information received in TIS-B Messages is reported directly to applications, with one
exception. The exception is latitude-longitude position information, which is CPR-
encoded when it is received, and must be decoded before reporting. In order to
accomplish CPR decoding, it is necessary to track received messages, so that even-format
and odd-format messages can be combined to determine the latitude and longitude of the
target.
In the most common case, a particular target will result in TIS-B Message receptions or
ADS-B Message receptions, but not both. It is possible, however, for both types of
messages to be received for a single target. If this happens, the TIS-B information is
processed and reported independently of the ADS-B receptions and reporting.
2.2.17.4.1 TIS-B Message-to-Track Correlation

Tracking makes it possible to associate a received message with information previously
received about that same target, in the presence of many other intervening messages
about other targets. Such associations are necessary for global decodes (2.2.17.4.2), for
estimating velocity when position was received (2.2.17.4.6) and for estimating position
when velocity was received (2.2.17.4.6).
2.2.17.4.1.1 TIS-B Messages Having a 24-Bit ICAO Address

For a target that has a 24-bit ICAO Address, that address is used for correlating new
receptions with information in the TIS-B track file. Correlation is successful if the
address matches exactly. When a TIS-B Position Message having a 24-bit ICAO
Address is received, and an existing TIS-B track has the same address, the message shall
be correlated with the track.
2.2.17.4.1.2 TIS-B Messages Having Mode A Code and Track Number

For a target not identified by a 24-bit ICAO Address, but instead having a Mode A Code
and a TIS-B track number, then these are used to correlate with information in the track
file. Correlation is successful if the Mode A Code and the track number both match
exactly. When a TIS-B Message having a Mode A Code and TIS-B track number is
received, and an existing TIS-B track has the same Mode A Code and ADS-B track
number, the message shall be correlated with the track.
2.2.17.4.2 TIS-B Position Message Decoding

When a received TIS-B Position Message correlates to an existing TIS-B track, the
message and the track are used together to decode the latitude and longitude of the target.
If the track is Complete, meaning that a global decode has been accomplished, then the
new latitude-longitude information shall be decoded using local decoding, as specified in
A.1.7.4 in Appendix A, taking the previous position of the target as the reference.
If the TIS-B track is Incomplete, meaning that a global decode has not yet been
accomplished prior to this reception, then a global decode may be computed depending
on the contents of the track. If the information in the track together with the new position
message consist of at least one even format message and at least one odd format message
received within 10 seconds, then a global decode shall be computed as specified in
20xx, RTCA, Inc.

286
A.1.7.7 of Appendix A. Otherwise the received encoded position, the even/odd format,
and the time of applicability, shall be saved in the track file for later use.
Note: When decoding positions, a reasonableness test may be applied.
2.2.17.4.3 TIS-B Track Update

When a position message is correlated to a TIS-B track that is Complete, then a new
position is computed as specified in 2.2.17.4.2 and the tracked position shall be updated
with the new position and time of applicability. The previous position and time need not
be saved. Figure 2-31 illustrates the transition from Incomplete track to Complete track
and later track drop.
When a position message is correlated with a TIS-B track that is Incomplete, the new
information may make it possible for a global decode, as specified in 2.2.17.4.2. If a
global decode is accomplished, the track shall be promoted to Complete, and the latitude,
longitude, and time of applicability shall be saved in the track. The previous position and
time information need not be saved. If a global decode is not accomplished, the even and
odd encoded positions shall be saved for future decodes.
Note: It is not necessary to save any encoded positions longer than 10 seconds.
Global decode
(even and odd posi ti on messages
Position received withi n 10 seconds)
message Incomplete Complete
re ce ived Track Track
Track drop is optional if no No position message

position messages for 10 seconds. received for 120-125 seconds
Drop
track
Figure 2-31: TIS-B Tracks
2.2.17.4.4 TIS-B Track Initiation

A TIS-B track begins with the reception of one position message. A new Incomplete
track shall be created, and the encoded position, even/odd format bit, and time of
applicability shall be saved.
20xx, RTCA, Inc.

287
2.2.17.4.5 TIS-B Track Drop

A TIS-B track that is Complete shall not be dropped within 120 seconds after any TIS-B
Position Message reception. If 125 seconds elapses without any TIS-B Message
reception, the track shall be dropped.
Note: As specified in 2.2.17.4.3, for an Incomplete TIS-B track, it is not necessary to

save any information more than 10 seconds after reception. Therefore the track
can be dropped after 10 seconds.
2.2.17.4.6 TIS-B Report Generation

As TIS-B Messages are received, the information is reported to applications. All
received information elements, other than position, shall be reported directly, including
all reserved fields for the TIS-B fine format messages (2.2.17.3.1 to 2.2.17.3.4) and the
entire message content (i.e., including the complete 88-bit content of the DF, CF, AA and
ME fields of the Extended Squitter Message) of any received TIS-B Management
Message (Table 2-106, for CF=4). The reporting format is not specified in detail, except
that the information content reported shall be the same as the information content
received. The report shall be issued within 0.5 seconds of the message reception.
When a TIS-B Position Message is received, it is compared with tracks to determine

whether it can be decoded into target position, as specified in 2.2.17.4.2. If the message
is decoded into target position, a report shall be generated, within 0.5 seconds of the
message reception. The report shall contain the received position information with its
time of applicability, the most recently received velocity measurement with its time of
applicability, estimated position and velocity, applicable to a common time of
applicability, address, and all other information in the received message. The estimated
values shall be based on the received position information and the track history of this
target.
When a TIS-B Velocity Message is received, if it is correlated to a complete track, then a

report shall be generated, within 0.5 seconds of the message reception. The report shall
contain the received velocity information with its time of applicability, the most recently
received position measurement with its time of applicability, estimated position and
velocity, applicable to a common time of applicability, address, and all other information
in the received message. The estimated values shall be based on the received ground
referenced velocity information and the track history of this target.
Notes:
1. Whereas ADS-B reports are classified as to State Vector Reports and certain other
defined types, TIS-B reports are not. Instead, TIS-B reporting follows the general
principle that all received information is reported directly upon reception.
2. In the absence of TIS-B Message receptions, it is possible for reports to be generated,

but this is not required. Such additional reports might be useful as a means of
counteracting possible flaws in an on-board data bus between ADS-B and an
application.
20xx, RTCA, Inc.

288
3. Track drop (2.2.17.4.5) is the only TIS-B function for which time-out performance is
required. It is expected that TIS-B applications will take account of the times when
information is reported and will apply the time-out functions that are appropriate for
each application.
2.2.18 ADS-B Rebroadcast Service Formats and Coding
2.2.18.1 Introduction
The TIS-B MASPS, RTCA DO-286B defines, in addition to the Fundamental TIS-B
Service, an ADS-B Rebroadcast Service as an additional service that may be
provided. The Messages of the ADS-B Rebroadcast Service are not transmitted by
aircraft, but by ADS-B ground stations.
Notes:
1. This section defines the formats and coding for an ADS-B Rebroadcast (ADS-R)
Service (see the TIS-B MASPS, RTCA DO-286B, 1.4.1) based on the same 112-bit
1090 MHz Extended Squitter signal transmission that is used for DF=17 ADS-B
Messages on 1090 MHz.
2. The ADS-B Rebroadcast Service complements the operation of ADS-B and the
Fundamental TIS-B Service (see the TIS-B MASPS, RTCA DO-286B, 1.4.1) by
providing ground-to-air rebroadcast of ADS-B data about aircraft that are not
equipped for 1090 MHz Extended Squitter ADS-B, but are equipped with an alternate
form of ADS-B (e.g., Universal Access Transceiver (UAT)). The basis for the ADS-R
transmission is the ADS-B Report received at the Ground Station using a receiver
compatible with the alternate ADS-B data link.
3. The ADS-R ground-to-air transmissions use the same signal formats as the DF=17
1090 MHz Extended Squitter ADS-B and can therefore be accepted by a 1090 MHz
ADS-B Receiving Subsystem, with the exceptions identified in the following sections.
2.2.18.2 ADS-B Rebroadcast Format Definition

ADS-B Rebroadcast information is transmitted using the 112-bit Mode S DF=18 format
specified in Figure 2-2.
2.2.18.3 Control Field Allocation

The content of the DF=18 transmission is defined by the value of the Control Field (CF).
As specified in Table 2-11, ADS-B Rebroadcast (i.e., ADS-R) transmissions use CF=6,
and ADS-R Management information transmissions (i.e., defining ADS-R Service
Volume and service availability) use CF=4. The ADS-B Receiving Subsystem shall
accept and process ADS-R Messages, DF=18, with CF=4 and CF=6.
20xx, RTCA, Inc.

289
2.2.18.4 ADS-R Message Processing

The Rebroadcast of ADS-B information on the 1090 MHz Extended Squitter data link is
accomplished by utilizing the same ADS-B Message formats used by aircraft/vehicles
with the exception of the need to transmit an indication to the 1090 MHz Receiving
Subsystem as to the type of identity associated with the aircraft data being reported in the
ADS-B Rebroadcast Message. This identification is performed using the ICAO/Mode A
Flag (IMF), which was previously discussed in 2.2.17.3.1.2 for the TIS-B transmissions.
The insertion of this one bit into the ADS-B Messages identified in the subparagraphs
below allows the ADS-B Receiving Subsystem to interpret the Address Field (AF) in the
following manner:
IMF = 0 indicates that the ADS-B Rebroadcast data is identified by an ICAO 24-bit
Address.
IMF = 1 indicates that the ADS-B Rebroadcast data is identified by an anonymous 24-
bit address or ground vehicle address or fixed obstruction address.
The ADS-B Receiving Subystem outputs data to ADS-B applications for aircraft/vehicles
received via ADS-R Messages similar to direct reception of ADS-B Messages from
aircraft/vehicles. ADS-R Messages may be received from a Ground Station transmitting
ADS-B Version ONE (1) or Version TWO (2) Messages that have been received by the
Ground Station from an aircraft or vehicle transmitting on an alternate ADS-B data link.
Therefore, to correctly decode the data, knowledge of the MOPS ADS-B Version
Number is required. The ADS-B Receiving Subsystem shall decode all valid ADS-R
transmitted messages and structure the information from such received messages into the
appropriate ADS-B Reports as per 2.2.8 and designate them as ADS-R Reports.
Note: ADS-B applications may need to distinguish ADS-B Reports generated from
direct receipt and those received via ADS-R.
2.2.18.4.1 Rebroadcast of ADS-B Airborne Position Messages

The ADS-B Receiving Subsystem shall decode and process the ME Field of the ADS-R
Airborne Position Messages, and update and maintain ADS-R Reports with the decoded
data in accordance with 2.2.18.5. The format is as specified in Figure 2.2.18.4.1.
Note:
1. The format is identical to the Airborne Position Message depicted in Figure 2-3,
except that ME bit 8 is redefined to be the ICAO/Mode A Flag (IMF).
2. The interpretation of the TYPE Code is different between ADS-B Version ONE (1)
and Version TWO (2). See Appendix N-XXXXX for decoding Version ONE (1) and
2.2.3.2.3 for decoding Version TWO (2).
20xx, RTCA, Inc.

290
ADS-R Airborne Position Message ME Field

Msg
Bit 33 -37 38 ---------- 39 40 41 ----- 52 53 54 55 ---- 71 72 ---- 88
#
ME
Bit 15 6 ------------ 7 8 9 ----- 20 21 22 23 --- 39 40 --- 56
#
CPR CPR CPR
TYPE Surveillance Time
Field IMF Altitude Format Encoded Encoded
Code Status (T)
Name [1] [12] (F) Latitude Longitude
[5] [2] [1]
[1] [17] [17]
MSB MSB MSB MSB MSB
LSB LSB LSB LSB LSB
Figure 2.2.18.4.1: ADS-R Airborne Position Message Format
2.2.18.4.2 ADS-R Surface Position Messages

Surface Position Messages, and update and maintain ADS-R Reports with the decoded
data in accordance with 2.2.18.5. The format is as specified in Figure 2.2.18.4.2.
Note: The format is identical to the ADS-B Surface Position Message depicted in
Figure 2-5, except that ME bit 21 is redefined to be the ICAO/Mode A Flag
(IMF).
ADS-R Surface Position Message ME Field

Msg
Bit 33 - 37 38 - 44 45 46 - 52 53 54 55 - 71 72 - 88
#
ME
Bit 1-5 6 - 12 13 14 - 20 21 22 23 - 39 40 56
#
Heading/
Heading/ CPR CPR CPR
TYPE Ground
Field Movement Ground IMF Format Encoded Encoded
Code Track
Name [7] Track [1] (F) Latitude Longitude
[5] Status
[7] [1] [17] [17]
[1]
MSB MSB MSB MSB MSB
LSB LSB LSB LSB LSB
Figure 2.2.18.4.2: ADS-R Surface Position Message Format
2.2.18.4.3 ADS-R Aircraft Identification and Category Messages

Aircraft Identification and Category Messages, and update and maintain ADS-R Reports
with the decoded data in accordance with 2.2.18.5. The format is as specified in Figure
2-6.
Note: Any Rebroadcast ADS-B Aircraft Identification and Category Message does not
contain the IMF bit since aircraft using an anonymous 24-bit address will not
provide identity and category information.
20xx, RTCA, Inc.

291
2.2.18.4.4 ADS-R Airborne Velocity Messages

Airborne Velocity Messages, and update and maintain ADS-R Reports with the decoded
data in accordance with 2.2.18.5. The format is as specified in Figure 2.2.18.4.4-1 for
Subtype 1 & 2 Messages, and in Figure 2.2.18.4.4-2 for Subtype 3 & 4 Messages.
Notes:
1. The formats are identical to the ADS-B Airborne Velocity Messages depicted in
Figure 2-7 for Subtype 1 & 2 Messages, and in Figure 2-8 for Subtype 3 & 4
Messages, except that ME bit 9 is redefined to be the ICAO/Mode A Flag (IMF).
2. Bit 10 of the ME field in ADS-B Version ONE (1) is the IFR Capability Flag which is
not conveyed in ADS-B Version TWO (2) ADS-B Transmitting Subsystems.
20xx, RTCA, Inc.

292
ADS-R Airborne Velocity Message Subtype=1 and 2 ME Field

MSG
BIT 33 - 37 38 - 40 41 42 43 - 45 46 47 - 56 57 58 - 67 68 69 70 - 78 79 - 80 81 82 88
#
ME
BIT 1-5 6-8 9 10 11 - 13 14 15 - 24 25 26 - 35 36 37 38 - 46 47 - 48 49 50 56
#
Diff
Diff
Reserved-A
Reserved-B
E/W N/S Vert Vert from
E/W N/S Vert from
FIELD TYPE Subtype IMF NACV Direction Direction Rate Rate Baro
[1]
[2]
Velocity Velocity Rate Baro
NAME [5] [3] [1] [3] Bit Bit Source Sign Alt
[10] [10] [9] Alt
[1] [1] [1] [1] Sign
[7]
[1]
Figure 2.2.18.4.4-1: ADS-R Airborne Velocity Message Subtype 1 & 2 Format
ADS-R Airborne Velocity Message Subtype=3 and 4 ME Field

MSG
BIT 33 - 37 38 - 40 41 42 43 - 45 46 47 - 56 57 58 - 67 68 69 70 - 78 79 - 80 81 82 88
#
ME
BIT 1-5 6-8 9 10 11 - 13 14 15 - 24 25 26 - 35 36 37 38 - 46 47 - 48 49 50 56
#
Diff
Diff
Reserved-A
Reserved-B
Heading Vert Vert from
Airspeed Vert from
FIELD TYPE Subtype IMF NACV Status Heading Airspeed Rate Rate Baro
[1]
[2]
Type Rate Baro
NAME [5] [3] [1] [3] Bit [10] [10] Source Sign Alt
[1] [9] Alt
[1] [1] [1] Sign
[7]
[1]
Figure 2.2.18.4.4-2: ADS-R Airborne Velocity Message Subtype 3 & 4 Format
20xx, RTCA, Inc.

293
2.2.18.4.5 ADS-R Aircraft Emergency/Priority Status Messages

Aircraft Emergency/Priority Status Messages, and update and maintain ADS-R Reports
with the decoded data in accordance with 2.2.18.5. The format is as specified in Figure
2.2.18.4.5.
Notes:
1. The format is identical to the Aircraft Emergency/Priority Status Message depicted in

Figure 2-13, except that ME bit 56 is redefined to be the ICAO/Mode A Flag (IMF).
2. The Mode A Code, bits 12 through 24 of the ME field are not conveyed in ADS-B
Version ONE (1) Aircraft Emergency/Priority Status Messages (See Appendix N,
XXXXX).
ADS-R Aircraft Status Message (Emergency/Priority Status) (TYPE=28, Subtype=1)

Msg
33 ----- 37 38 ------ 40 41 -------- 43 44 --------- 56 57 --- 87 88
Bit #
ME
1 ------- 5 6 -------- 8 9 --------- 11 12 --------- 24 25 55 56
Bit #
Emergency/
Field TYPE=28 Subtype=1 Mode A Code Reserved IMF
Priority Status
Name [5] [3] [13] [44] [1]
[3]
MSB LSB MSB LSB MSB LSB MSB LSB MSB LSB
Figure 2.2.18.4.5: ADS-R Aircraft Emergency/Priority Status Message Format
2.2.18.4.6 ADS-R Target State and Status Messages

Target State and Status Messages, and update and maintain ADS-R Reports with the
decoded data in accordance with 2.2.18.5. The format is as specified in Figure
2.2.18.4.6.
Note: The format is identical to the ADS-B Target State and Status Message depicted in
Figure 2-10, except that ME bit 51 is redefined to be the ICAO/Mode A Flag
(IMF).
20xx, RTCA, Inc.

294
ADS-R Target State and Status Message

Msg
Bit 33 ----------- 37 38 ----- 39 40 ----------- 82 83 84 ------ 88
#
ME
Bit 1 -------------- 5 6 -------- 7 8 ------------- 50 51 52 ------ 56
#
Subtype
TYPE Code = 29 Intent/Status Intent/Status
Field Code=1 IMF
(11101) Information Information
Name (01) [1]
[5] [43] [5]
[2]
MSB MSB MSB MSB
LSB LSB LSB LSB
Figure 2.2.18.4.6: ADS-R Target State and Status Message Format
2.2.18.4.7 ADS-R Aircraft Operational Status Messages

Aircraft Operational Status Messages, and update and maintain ADS-R Reports with the
decoded data in accordance with 2.2.18.5. The format is as specified in Figure
2.2.18.4.7.
Note: The format is identical to the ADS-B Aircraft Operational Status Message
depicted in Figure 2-11, except that ME bit 56 is redefined to be the ICAO/Mode
A Flag (IMF).
20xx, RTCA, Inc.

295
ADS-R Aircraft Operational Status Message ME Field Format

Msg
BIT 33 - 37 38 - 40 41 - 52 53 - 56 57 - 72 73 - 75 76 77 - 80 81 - 82 83 - 84 85 86 87 88
#
ME
BIT 1-5 6-8 9 - 20 21 - 24 25 - 40 41 - 43 44 45 - 48 49 - 50 51 - 52 53 54 55 56
#
Capability Class (CC)
Subtype=0 GVA Source NICBARO
Codes Operational MOPS
[3] NIC [2] Integrity [1] SIL
Field TYPE=31 [16] Mode (OM) Version NACP HRD IMF
Supp. Level Supp
Name [5] CC L/W Codes Number [4] [1] [1]
Subtype=1 [1] Reserved (SIL) TRK/HDG [1]
Codes Codes [16] [3]
[3] [2] [2] [1]
[12] [4]
Note: Subfields that are relevant only for Airborne Participants are allocated to Subtype ZERO (binary 000), while those that
pertain only to Surface Participants are allocated to Subtype ONE (binary 001).
Figure 2.2.18.4.7: ADS-R Aircraft Operational Status Message ME Field Format
20xx, RTCA, Inc.

296
2.2.18.5 ADS-R Report Processing

ADS-R Reports shall be maintained and output for DF=18, with CF=4 ADS-R Messages
consistent with the ADS-B Report Characteristics requirements of 2.2.8 and the Report
Assembly and Delivery requirements of 2.2.10. ADS-R Reports shall be provided for
both ADS-B Version ONE (1) and Version TWO (2) formatted ADS-R Messages in
accordance with the message formats provided in 2.2.18.4.
Note: ADS-R Reports are for Participants that do not have ADS-B Reports since they
are ADS-B Messages transmitted by the Ground for aircraft/vehicles that
transmit on a different ADS-B link (e.g., UAT). ADS-R Messages are processed
by the 1090ES ADS-B Receiving Subsystems in the same manner as ADS-B
Messages received directly from aircraft/vehicle Participants.
2.3 Equipment Performance - Environmental Conditions

The environmental tests and performance requirements described in this subsection
provide a laboratory means of determining the overall performance characteristics of the
equipment under conditions representative of those that may be encountered in actual
aeronautical operations.
Some of the environmental tests contained in this subsection need not be performed
unless the manufacturer wishes to qualify the equipment for that particular environmental
condition. These tests are identified by the phrase When Required. If the manufacturer
wishes to qualify the equipment to these additional environmental conditions, then these
when required tests shall be performed.
The test procedures applicable to a determination of equipment performance under

environmental test conditions are contained in RTCA DO-160F (EUROCAE ED-14F),
Environmental Conditions and Test Procedures for Airborne Equipment, July 1997.
Some of the performance requirements in Subsections 2.1 and 2.2 are not tested by test
procedures herein. Moreover, not all tests are required to be done at each of the
environmental conditions in RTCA DO-160F (EUROCAE ED-14F). Judgment and
experience have indicated that these particular performance parameters are not
susceptible to certain environmental conditions and that the level of performance
specified in Subsections 2.1 and 2.2 will not be measurably degraded by exposure to
these environmental conditions.
The specified performance tests cover all classes of ADS-B Transmitting and Receiving
Subsystems. Only those tests that are applicable to the class of equipment being qualified
need be performed. Additional tests may have to be performed in order to determine
performance of particular design requirements that are not specified in this document. It
is the responsibility of the manufacturer to determine appropriate tests for these
functions.
Specific ADS-B Transmitting and Receiving Subsystem performance tests have been
included in this section for use in conjunction with the environmental procedures of
RTCA DO-160F (EUROCAE ED-14F). These tests have been chosen as a subset of the
ADS-B Transmitting and Receiving Subsystem performance tests provided in subsection
20xx, RTCA, Inc.

297
2.4. Normally, a MOPS document does not provide specific equipment performance
tests to be used in conjunction with the environmental procedures of RTCA DO-160F
(EUROCAE ED-14F). However, there is a sufficiently large number of ADS-B
Transmitting and Receiving Subsystem performance tests in subsection 2.4 that it would
be impractical to repeat all of those tests in conjunction with all of the appropriate
environmental procedures.
2.3.1 Environmental Test Conditions

Table 2-108 lists all of the environmental conditions and test procedures (hereafter
referred to as environmental procedures) that are documented in RTCA DO-160F
(EUROCAE ED-14F). Table 2-109 lists the sets of ADS-B Transmitting and Receiving
Subsystem performance tests that are specified in detail in this section and which are
intended to be run subject to the various environmental procedures of RTCA DO-160F
(EUROCAE ED-14F). In order to simplify the process of relating the environmental
procedures to the ADS-B equipment performance tests, Table 2-108 divides the
environmental procedures into groups. All of the procedures in a given group are carried
out in conjunction with the same set of ADS-B Transmitting and Receiving Subsystem
performance tests. Using this approach, the environmental procedures fall into five
groups. The environmental procedures that apply to all of the sets of ADS-B
Transmitting and Receiving Subsystem tests fall into group 1. Group 2 procedures apply
to 9 of the sets of ADS-B Transmitting and Receiving Subsystem performance tests.
Group 3 procedures apply to 6 of the sets of ADS-B Transmitting and Receiving
Subsystem performance tests. Group 4 procedures apply to one set of the performance
tests. Group 5, which applies to none of the ADS-B Transmitting and Receiving
Subsystem performance tests, includes only environmental procedures that are intended
to determine the effect of the ADS-B Transmitting and/or Receiving Subsystem on rack
mounting hardware, compass needles, explosive gases, and other RF hardware.
Table 2-109 indicates which of the groups of environmental procedures is related to each
set of ADS-B Transmitting and/or Receiving Subsystem performance tests. Each ADS-B
Transmitting and/or Receiving Subsystem performance test shall be validated under all
of the environmental procedures in the groups required for that test as indicated in Table
2-109.
20xx, RTCA, Inc.

298
Table 2-108: Environmental Test Groups

RTCA EUROCAE
TEST ENVIRONMENTAL
DO-160F ED-14F GROUPS REMARKS
# CONDITION
Paragraph Paragraph
4a Temperature 4.5 4.4 4.5 1
4b Altitude 4.6.1 4.6.1 3
Decompression &
4c 4.6.2 - 4.6.3 4.6.2 - 4.6.3 3
Overpressure
5 Temperature Variation 5.0 5.0 3
6 Humidity 6.0 6.0 2
7a Operational Shock 7.2 7.1 2
7b Crash Safety 7.3 7.2 5 NO TESTS
3 during:
8 Vibration 8.0 8.0 3&1
1 after
9 Explosion 9.0 9.0 5 NO TESTS
10 Waterproofness 10.0 10.0 2
11 Fluids Susceptibility 11.0 11.0 2
12 Sand and Dust 12.0 12.0 2
13 Fungus Resistance 13.0 13.0 2
14 Salt Spray 14.0 14.0 2
15 Magnetic Effect 15.0 15.0 5 NO TESTS
Power Input
4 3 during:
16 Momentary Interruptions 16.0 16.0
3&2 2 after
All Others
17 Voltage Spike 17.0 17.0 2
Audio Frequency Conducted
18 18.0 18.0 1
Susceptibility
19 Induced Signal Susceptibility 19.0 19.0 1
20 RF Susceptibility 20.0 20.0 1
21 Emission of RF Energy 21.1 21.1 5 NO TESTS
Lightning Induced Transient
22 22.0 22.0 3
Susceptibility
23 Lightning Direct Effects 23.0 23.0 3
24 Icing 24.0 24.0 2
25 Electrostatic Discharge 25.0 25.0 NO TESTS
Notes to Table 2-108:
1. Tests in Group 5 determine the effects of the ADS-B equipment on other equipment
(mounts, compass needles, explosive gases, and other RF equipment) and therefore do
not involve the ADS-B equipment performance requirements of this document.
2. Environmental test conditions specified in these MOPS are not directly applicable to
non-aircraft installations. Manufacturers of such equipment may be permitted to
substitute appropriate test standards, such as SAE J1455 (Joint SAE/TMC Recommended
Environmental Practices for Electronic Equipment Design (Heavy Duty Trucks)).
20xx, RTCA, Inc.

299
Table 2-109: Performance Test Requirements During Environmental Tests

Required Environmental Test
Test Groups
Procedure DESCRIPTION (See Table 2-108)
Paragraph
1 2 3 4 5
2.3.2.1 Transponder-Based Transmitters X X X
2.3.2.2 Stand Alone (Non-Transponder-Based) Transmitters NT NT NT NT NT
2.3.2.2.1 Frequency X X X
2.3.2.2.2 Pulse Shapes X
2.3.2.2.3 Pulse Interval X
2.3.2.2.4 Preamble X
2.3.2.2.5 Data Pulses X X
2.3.2.2.6 RF Peak Output Power NT NT NT NT NT
2.3.2.2.6.1 Class A0 Equipment RF Peak Output Power X X
2.3.2.2.6.2 Class B Equipment RF Peak Output Power X X
2.3.2.2.7 Transmission Rates for Transponder - Based Transmitters NT NT NT NT NT
2.3.2.2.7.1 Transmission Rates Compliant with RTCA DO-181D X X
2.3.2.2.7.2 Transmission Rates not specified in RTCA DO-181D X X
2.3.2.2.7.3 Maximum Transmission Rates for Transponder - Based Transmitters X X
2.3.2.2.8 Transmission Rates for Stand Alone Transmitters X X
2.3.2.2.8.1 Power-On Initialization X X
2.3.2.2.8.2 ADS-B Airborne Position Message Broadcast Rate X
2.3.2.2.8.3 ADS-B Surface Position Message Broadcast Rate X
2.3.2.2.8.4 ADS-B Aircraft Identification and Category Message Broadcast Rate X
2.3.2.2.8.5 ADS-B Velocity Information Message Broadcast Rate X
2.3.2.2.8.6 ADS-B Aircraft Target State and AStatus Message Broadcast Rates X
2.3.2.2.8.7 ADS-B Aircraft Operational Status Message Broadcast Rates X
2.3.2.2.8.8 Extended Squitter Aircraft Status ADS-B Message Broadcast Rate X
2.3.2.2.8.9 TYPE 23 (TEST) ADS-B Message Broadcast Rate X
2.3.2.2.8.10 Maximum ADS-B Message Transmission Rates X
2.3.2.3 Receivers Shared with a TCAS Unit X X X
2.3.2.3.1 TCAS Compatibility X
2.3.2.3.2 Re-Triggerable Reply Processor X X
2.3.2.3.3 Verfication of Enhanced Squitter Reception Techniques (2.2.4.4) NT NT NT NT NT
2.3.2.3.3.1 Combined Preamble and Data Block Tests with A/C Fruit X
2.3.2.3.3.2 Data Block Tests with Mode S Fruit X
2.3.2.3.3.3 Re-Triggering Performance X
2.3.2.4 Receivers Not Shared with TCAS (2.2.4.3) NT NT NT NT NT
2.3.2.4.1 In-Band Acceptance X X X
2.3.2.4.2 Dynamic Range X X X
2.3.2.4.3 Re-Triggerable Capability X X
2.3.2.4.4 Out-of-Band Rejection X X
2.3.2.4.5 Dynamic Minimum Trigger Level X X
2.3.2.4.6 Criteria for ADS-B Message Transmission Pulse Detection X
2.3.2.4.7 Criteria for Data Block Acceptance in ADS-B Message Signals X
2.3.2.4.8 Verification of Enhanced Squitter Reception Techniques (2.2.4.4) NT NT NT NT NT
2.3.2.4.8.1 Combined Preamble and Data Block Tests with A/C Fruit X
2.3.2.4.8.2 Data Block Tests with Mode S Fruit X
2.3.2.4.8.3 Re-Triggering Performance X X X
20xx, RTCA, Inc.

300
Table 2-109: Performance Test Requirements During Environmental Tests (Continued)
Required Environmental Test

Test Groups
Procedure DESCRIPTION (See Table 2-108)
Paragraph
1 2 3 4 5
2.3.2.4.9 Track File Maintenance X X X
2.3.2.5 Self Test and Monitors NT NT NT NT NT
2.3.2.5.1 Transponder-Based Equipment Address X X X X
2.3.2.5.2 Non-Transponder-Based Equipment X X X X
2.3.2.6 Response to Mutual Suppression NT NT NT NT NT
2.3.2.6.1 Transmitting Device Response to Mutual Suppression Pulses X
2.3.2.6.2 Receiving Device Response to Mutual Suppression Pulses X
2.3.2.7.1 Transmitting Diversity X X
2.3.2.7.2 Receiving Diversity NT NT NT NT NT
Full Receiver and Message Processing or Receiver Switching Front-
2.3.2.7.2.1 X X
End Diversity
2.3.2.7.2.2 Receiving Antenna Switching Diversity X X
2.3.2.8 Power Interruption NT NT NT NT NT
2.3.2.8.1 Power Interruption to ADS-B Transmitting Subsystems X X
2.3.2.8.2 Power Interruption to ADS-B Receiving Subsystems X X
2.3.2.9 Verification of Traffic Information Services Broadcast (TIS-B) NT NT NT NT NT
2.3.2.9.1 Verification of TIS-B Report Generation X
Note: NT in the above table means NO TEST.
2.3.2 Detailed Environmental Test Procedures

The test procedures set forth below are considered satisfactory for use in determining
equipment performance under environmental conditions. Although specific test
procedures are cited, it is recognized that other methods may be preferred. These
alternative procedures may be used if the manufacturer can show that they provide at
least equivalent information. In such cases, the procedures cited herein should be used as
one criterion in evaluating the acceptability of the alternative procedures. The ADS-B
Transmitting and Receiving Subsystem performance tests do not include specific pass/fail
criteria. It is intended that those criteria be obtained from the ADS-B Transmitting and
Receiving performance requirements provided in subsection 2.2.
2.3.2.1 Transponder-Based Transmitters (2.2.2.1)

Transponder-Based transmitters shall be tested to comply with the requirements of
RTCA DO-181D, 2.3.2.2 inclusive (EUROCAE ED-73C, chapter 4).
2.3.2.2 Stand Alone (Non-Transponder-Based) Transmitters (2.2.2.2)

No specific test procedure is required to validate 2.2.2.2.
20xx, RTCA, Inc.

301
2.3.2.2.1 Frequency (2.2.2.2.1)

Equipment Required:
Provide equipment capable of loading valid data for ADS-B broadcast messages into the
ADS-B equipment under test through the operational interface. Provide a Stub Tuner
(Microlab/FXR Sl-05N, or equivalent). Provide a Variable Air Line (Line Stretcher)
(Microlab/FKR SR-05N, or equivalent). Provide a Slotted Line (HP 805C, or
equivalent).
Measurement Procedure:
Determine the transmission frequency
Load valid data into the ADS-B Airborne Position format and ensure that the expected
ADS-B transmissions occur. Adjust the stub to establish a l.5:l VSWR at the antenna end
of the coax line specified by the manufacturer. If the ADS-B transmitter requires a
minimum length of a specified cable type, an attenuator equal to the loss of the minimum
amount of cable may be placed between the 1.5:1 VSWR point and the equipment
antenna jack. Alternately, a length of cable equal to the specified minimum length and
cable type may be used in lieu of the attenuator. Adjust the line stretcher for maximum
transmitter frequency shift above and below 1090 MHz. Determine that the frequency
shift does not exceed the requirements of 2.2.2.2.1.
2.3.2.2.2 Pulse Shapes (2.2.2.2.4)

Equipment Required:
Provide a method of loading valid data for ADS-B broadcast messages into the ADS-B
equipment under test. Provide a method of detecting the RF pulses of the ADS-B
broadcast message for display on an oscilloscope. Provide a Wide Band Dual Channel
Oscilloscope (HP 1710B, or equivalent).
Step 1: ADS-B Message Pulse Amplitude Variation (2.2.3.1.3.a)
Load valid data into the ADS-B Airborne Position Message and verify that the
messages are being transmitted by the equipment under test. Measure the
maximum power differential between pulses in ADS-B broadcast messages.
Verify that it is within the tolerance specified in 2.2.3.1.3.a.
Step 2: ADS-B Message Pulse Shape (2.2.3.1.3.b and c)
Load valid data into the ADS-B Airborne Position Message and verify that the
messages are being transmitted by the equipment under test. Measure the rise
and decay time of the ADS-B broadcast message pulses. Verify that they are
within the tolerances specified in 2.2.3.1.3.b and c.
20xx, RTCA, Inc.

302
Note: Pulse Rise Time is measured as the time interval between 10 percent
and 90 percent of peak amplitude on the leading edge of the pulse.
Pulse Decay Time is measured as the time interval between 90 percent
and 10 percent of peak amplitude on the tailing edge of the pulse. See
Caution statement below.
CAUTION: If the detector is not known to be linear, checks should be made to
determine what amplitude points on the detected pulse correspond to the
10 percent and 90 percent amplitude points of the RF pulses. In addition,
checks should be made to determine the rise and decay time of the detector.
2.3.2.2.3 Pulse Interval (2.2.2.2.6)

Equipment Required:
Broadcast Message for display on an oscilloscope. Wide Band Dual Channel
ADS-B Message Pulse Spacing Tolerance (2.2.3.1.4)
Load valid data into the ADS-B Airborne Position Message and verify that the messages
are being output. Determine that the leading edge of any reply pulse is within 50
nanoseconds of its assigned position.
Note: Interval measurements are measured between half voltage points of the
respective pulses as detected by a linear detector. If the detector is not known to
be linear, a check should be made to determine the half voltage points.
2.3.2.2.4 Preamble (2.2.2.2.7)

Equipment Required:
Broadcast Message for display on an oscilloscope. Provide a Wide Band Dual Channel
Determine Preamble Pulse Spacing
are being transmitted by the equipment under test. Display the ADS-B Messages on the
oscilloscope. Measure the pulse duration of the first four message pulses. Measure the
pulse spacing between the leading edge of the first and each of the second, third, and
fourth pulses. Determine that the spacing of the pulses is within the tolerances specified
in 2.2.3.1.1.
20xx, RTCA, Inc.
303
2.3.2.2.5 Data Pulses (2.2.2.2.8)

Equipment Required:
Determine Message Data Pulse Width and Duration
Note 1: For tests in this section, unless otherwise specified, examine pulses at the
beginning, middle and end of the ADS-B broadcast messages.
are being transmitted by the equipment under test. Measure the pulse duration of the
pulses transmitted in the ADS-B Message throughout the message transmission.
Determine that the duration of the pulses is within the tolerance specified in 2.2.3.1.2.
Measure the pulse spacing of the fifth reply pulse with reference to the first reply pulse.
Determine that the pulse spacing is within the tolerance specified in 2.2.3.1.2.
Note 2: Interval measurements are measured between half voltage points of the
2.3.2.2.6 RF Peak Output Power (2.2.2.2.10)

No specific test procedure is required to validate 2.2.2.2.10.
2.3.2.2.6.1 Class A0 Equipment RF Peak Output Power (2.2.2.2.10.1)

Equipment Required:
equipment under test. Wide Band Dual Channel Oscilloscope (HP 1710B, or equivalent).
ADS-B transmissions occur. Measure the single pulse having the maximum RF power
output. Determine that the maximum power output meets the requirements of
2.2.2.2.10.1.
2.3.2.2.6.2 Class B Equipment RF Peak Output Power (2.2.2.2.10.2)

Equipment Required:
equipment under test. Wide Band Dual Channel Oscilloscope (HP 1710B, or equivalent).
20xx, RTCA, Inc.

304
ADS-B transmissions occur. Measure the single pulse having the maximum RF power
output. Determine that the maximum power output meets the requirements of
2.2.2.2.10.2.
2.3.2.2.7 Transmission Rates for Transponder - Based Transmitters (2.2.3.3.1)

2.3.2.2.7.1 Transmission Rates Compliant with RTCA DO-181D (2.2.3.3.1.1)

Performance of ADS-B transmitters based on Mode S transponders shall validate
Message Transmit Rates in accordance with RTCA DO-181D 2.5.4.6.2 (EUROCAE
ED-73C, 5.5.8.6.2), for each class of transponder defined in the latest version of FAA
TSO-C112.
2.3.2.2.7.2 Transmission Rates Not Specified in RTCA DO-181D (2.2.3.3.1.2) (EUROCAE

ED-73C)
When the transmission rate of a particular message type is not specified or is not tested in
RTCA DO-181D (EUROCAE ED-73C), then the Mode S Transponder-Based ADS-B
transmitters shall verify the message delivery performance for those messages in
accordance with 2.3.2.2.8 through 2.3.2.2.8.10 of this document for Stand Alone
Transmitters. If there is conflict between the requirements of RTCA DO-181D
(EUROCAE ED-73C) and this document, then the requirements of RTCA DO-181D
(EUROCAE ED-73C) shall be adhered to.
2.3.2.2.7.3 Maximum Transmission Rates for Transponder-Based Transmitters (2.2.3.3.1.3)

Performance of ADS-B transmitters based on Mode S transponders shall validate
maximum transmission rates in accordance with RTCA DO-181D (EUROCAE ED-73C),
for each class of transponder defined in the latest version of FAA TSO-C112.
When the maximum transmission rate of a particular message type is not specified or is
not tested in RTCA DO-181D (EUROCAE ED-73C), then the Mode S Transponder-
Based ADS-B transmitters shall verify the maximum message delivery rate in accordance
with 2.3.2.2.8.10 of this document for Stand Alone transmitters. If there is conflict
between the requirements of RTCA DO-181D (EUROCAE ED-73C) and this document,
then the requirements of RTCA DO-181D (EUROCAE ED-73C) shall be adhered to.
2.3.2.2.8 Transmission Rates for Stand Alone Transmitters (2.2.3.3.1.4)

Purpose/Introduction:
a. Stand Alone Transmitters for Class A0 and Class B0 equipment are those
implemented independent of a Mode S transponder. Such transmitters shall meet the
transmission rate requirements of 2.2.3.3.1.3 and the message update rate
requirements specified in the following subparagraphs.
20xx, RTCA, Inc.

305
b. Add a quantization interval for the transmitted message jitter of 15 milliseconds or

less.
Equipment Required:
Provide a method of loading valid data for the generation of ADS-B Airborne Position,
Surface Position, Aircraft Identification and Category, Airborne Velocity, Target State
and Status, and Operational Status broadcast messages into the ADS-B Transmitting
Subsystem under test.
Provide a method of recording and time stamping all ADS-B Broadcast messages
transmitted by the ADS-B Transmitting Subsystem under test with the time stamping
quantization being 15 milliseconds or less.
Step 1: ADS-B Message Broadcast Setup
Provide the ADS-B Transmitting Subsystem under test with all valid necessary
data for the generation of ADS-B Airborne Position, Aircraft Identification and
Category, Airborne Velocity, Target State and Status, and Operational Status
broadcast messages.
Verify that the ADS-B Transmitting Subsystem is broadcasting ADS-B

Messages.
Step 2: ADS-B Message Recording and Time Stamping
Record and time stamp all ADS-B Messages that are broadcast by the ADS-B
Transmitting Subsystem for a period of not less than 5 minutes.
Step 3: Distribution Checks
For each of the ADS-B Airborne Position, Aircraft Identification and Category,
Airborne Velocity, Target State and Status, and Operational Status Message
types transmitted, verify that the messages are distributed over the specified
range of transmission intervals for each particular message type.
Step 4: Interval Quantization Checks
Airborne Velocity, Target State and Status, and Operational Status Message
types transmitted, verify that the messages were distributed with the jitter
spacing being 15 milliseconds or less between messages of equivalent type.
2.3.2.2.8.1 Power-On Initialization (2.2.3.3.2.1.1)

Equipment Required
20xx, RTCA, Inc.

306
Measurement Procedure
Step 1: No Data Available (2.2.3.3.2.1.1.a)
Ensure that no appropriate valid message data are available for any of the
possible ADS-B broadcast messages. Power up the equipment. Verify that no
transmissions occur.
Step 2: Valid Data available (2.2.3.3.2.1.1.b)
For each ADS-B Position and Velocity Message type in turn, ensure that
appropriate valid ADS-B Message data are available for that message type
only. Power up the equipment. Verify that the correct ADS-B broadcast
message is transmitted starting no later than 2.0 seconds after Power-On.
2.3.2.2.8.2 ADS-B Airborne Position Message Broadcast Rate (2.2.3.3.2.2)

Equipment Required:
Broadcast Message for display on an oscilloscope, or equivalent method of observing the
message content.
Ensure that the equipment is set to the Airborne condition and that the appropriate
valid ADS-B Airborne Position data is available. Verify that the ADS-B Airborne
Position Message is broadcast at intervals that are distributed over the range of 0.4 to 0.6
seconds as specified in 2.2.3.3.2.2.
2.3.2.2.8.3 ADS-B Surface Position Message Broadcast Rate (2.2.3.3.2.3)

Equipment Required:
Provide a method of loading valid data for broadcasting ADS-B Messages into the ADS-
B equipment under test. Provide a method of monitoring the transmitted ADS-B
Messages and measuring the rate at which they are output.
Step 1: Switching from High Rate to Low Rate (2.2.3.3.2.3.a(1) and c)
Ensure that the equipment is set to the On the Ground condition and that the
appropriate valid ADS-B Surface Position data is provided such that the
position is changing at a rate of 10.1 meters in any 30 second interval. At least
61 seconds after the start of the data input, verify that the ADS-B Surface
Position Message is broadcast at intervals that are distributed over the range of
0.4 to 0.6 seconds as specified in 2.2.3.3.2.3.b.
Input new ADS-B Surface Position data with the position data changing at a
rate of 9.9 meters in any 30 second interval. At least 61 seconds after the
inputting of the new data, verify that the ADS-B Surface Position Message is
20xx, RTCA, Inc.

307
broadcast at intervals that are distributed over the range of 4.8 to 5.2 seconds as
specified in 2.2.3.3.2.3.c.
Step 2: Switching from Low Rate to High Rate (2.2.3.3.2.3.a(2) and c)
appropriate valid ADS-B Surface Position data is provided such that the
position is stationary. At least 61 seconds after establishing the data, verify that
the ADS-B Surface Position Messages are broadcast at intervals that are
distributed over the range of 4.8 to 5.2 seconds as specified in 2.2.3.3.2.3.c.
Input new ADS-B Surface Position data such that the position is stationary and
10.1 meters away from the position above. One (1) second after inputting the
new data, verify that the ADS-B Surface Position Messages are broadcast at
intervals that are distributed over the range of 0.4 to 0.6 seconds as specified in
2.2.3.3.2.3.b. Also verify that at least 61 seconds after establishing the new
data that the ADS-B Surface Position Message is broadcast at intervals that are
distributed over the range 4.8 to 5.2 seconds as specified in 2.2.3.3.2.3.c.
2.3.2.2.8.4 ADS-B Aircraft Identification and Category Message Broadcast Rate (2.2.3.3.2.4)
Equipment Required:
Broadcast Message for display on an oscilloscope.
Step 1: Airborne (2.2.3.3.2.4.a )
Ensure that the equipment is set to the Airborne condition and that the
appropriate valid ADS-B Aircraft Identification and Category data is available.
Verify that the ADS-B Aircraft Identification and Category message is
broadcast at intervals that are distributed over the range of 4.8 to 5.2 seconds as
specified in 2.2.3.3.2.4.a.
Step 2: On the Ground (2.2.3.3.2.4.b)
Verify that the ADS-B Aircraft Identification and Category Message is
broadcast at intervals that are distributed over the range of 9.8 to 10.2 seconds
as specified in 2.2.3.3.2.4.b.
2.3.2.2.8.5 ADS-B Velocity Information Message Broadcast Rate (2.2.3.3.2.5)

Equipment Required:
20xx, RTCA, Inc.

308
Ensure that the appropriate valid ADS-B Velocity Information data is available. Verify
that the ADS-B Velocity Information message is broadcast at intervals that are distributed
over the range of 0.4 to 0.6 seconds as specified in 2.2.3.3.2.5.a.
2.3.2.2.8.6 Target State and Status Message Broadcast Rates (2.2.3.3.2.6.1)

Equipment Required:
Provide a Method of loading valid data for ADS-B broadcast messages into the ADS-B
Ensure that no Target State data is available. Verify that no Target State and Status
Message is output for a period of 20 seconds. Inject the appropriate valid ADS-B Target
State data and verify that the ADS-B Target State and Status Message is broadcast at
intervals that are distributed over the range of 1.2 to 1.3 seconds as specified in
2.2.3.3.2.6.1.b for as long and data is available.
Repeat the procedure for each Target State and Status Message independently as
necessary.
2.3.2.2.8.7 ADS-B Aircraft Operational Status Message Broadcast Rates (2.2.3.3.2.6.2)

Equipment Required:
Ensure that no Aircraft Operational Status data is available. Verify that no Aircraft
Operational Status Message is output for a period of 20 seconds. Inject the appropriate
valid ADS-B Aircraft Operational Status data. Verify that the ADS-B Aircraft
Operational Status Message is broadcast at intervals that are distributed over the range of
2.4 to 2.6 seconds as specified in 2.2.3.3.2.6.2.b for a period of 24 1 seconds if Target
State and Status Messages are being broadcast. Verify that the ADS-B Aircraft
Operational Status Message is broadcast at intervals that are distributed over the range of
0.7 to 0.8 seconds as specified in 2.2.3.3.2.6.2.b for a period of 24 1 seconds if Target
State and Status Messages are not being broadcast.
2.3.2.2.8.8 Extended Squitter Aircraft Status ADS-B Message Broadcast Rate (2.2.3.3.2.6.3)
Equipment Required:
20xx, RTCA, Inc.

309
Establish the emergency condition in accordance with Appendix A., Figure A.8-9, Note
2. Verify that the Emergency/Status Message (TYPE-28, Subtype=1) is broadcast at
intervals that are distributed over the range of 0.7 to 0.8 seconds if the Target State and
Status Message is not being broadcast. Verify that the Emergency/Status Message
(TYPE-28, Subtype=1) is broadcast at intervals that are distributed over the range of 2.4
to 2.6 seconds if the Target State and Status Message is being broadcast. Clear the
established emergency condition and verify that NO Emergency/Status Messages are
broadcast.
2.3.2.2.8.9 TYPE 23 (TEST) ADS-B Message Broadcast Rate (2.2.3.3.2.7)

Equipment Required:
Update the TEST ADS-B Message and verify that it is broadcast only once. Repeat 10
times.
2.3.2.2.8.10 Maximum ADS-B Message Transmission Rates (2.2.3.3.2.10)

Equipment Required:
ADS-B equipment under test through the operational interface. Provide a method of
monitoring ADS-B broadcast messages output by the equipment under test. Provide a
Wide Band Dual Channel Oscilloscope (HP 1710B, or equivalent).
Step 1: Maximum Combined ADS-B Message Output rate (2.2.3.3.2.10--Airborne
Set the Airborne condition and load valid data into all the ADS-B Broadcast
messages that can be supported by the equipment under test at a rate ensuring
maximum transmission rate. Also ensure that the data for all event driven
messages changes at a rate requiring more than the permitted maximum output
rate of two messages per second. Verify that each of the ADS-B Broadcast
messages types are output at rates within the specified tolerance, that the
Airborne Position Messages are being transmitted, and that only two event
driven messages per second are transmitted. Also verify that the total combined
rate is less than or equal to 6.2 messages per second.
During this test, also verify that the transmitted output power remains within
the specified limits.
20xx, RTCA, Inc.

310
2.3.2.3 Receivers Shared with a TCAS Unit (2.2.4.2)

ADS-B receivers implemented as part of a TCAS unit shall demonstrate compliance with
Test Procedures specified in the TCAS MOPS, RTCA DO-185B, 2.4.2.1.2 (EUROCAE
ED-143, 2.4.2.1.2).
In addition to tests specified in the TCAS MOPS, RTCA DO-185B, 2.4.2.1.2

(EUROCAE ED-143, 2.4.2.1.2), TCAS units operating with receivers that are more
sensitive than the MTL requirements specified in RTCA DO-185B (EUROCAE ED-
143), shall be submitted to the following test procedures provided through 2.3.2.4.7.
2.3.2.3.1 TCAS Compatibility (2.2.4.2.1.1)

This test verifies that no more than 10% of ADS-B Messages received at a level of
78 dBm or below shall be passed to the TCAS surveillance function.
Input:
Equipment:
Provide a method of supplying the UUT with:

Any Valid ADS-B Message having:
DF = 17
CA = 0
AA = Any discrete address
Message Rate = 50 Hz
Frequency = 1090 MHz
Power = -78 dBm
The ADS-B receiver power levels specified in this procedure are relative to the loss at the
RF message source end of the transmission line used to interface the RF message source
to the UUT receiver input port. For each ADS-B equipage class, the specified power
level shall be adjusted to compensate for the maximum line loss for which the UUT
receiver has been designed. For example, if the line loss is 3 dB, then each of the RF
message power levels specified in the test procedures shall be lowered by 3 dB.
Step 1: Apply ADS-B Input Message
Apply Input at the receiver input port.
Step 2: Verify ADS-B Input Message Reception
Verify that no more than 10% of all ADS-B Messages are passed on to the
TCAS surveillance function.
Step 3: Repeat on all Applicable Receiver Input Ports
Repeat Steps 1 and 2 on all other applicable receiver RF input ports of the
UUT.
20xx, RTCA, Inc.

311
2.3.2.3.2 Re-Triggerable Reply Processor (2.2.4.2.2)

The following procedures verify the capability of the TCAS shared ADS-B receiver to
detect overlapping Mode-S replies or ADS-B Messages in the TCAS level range.
Inputs:
All Intruder Aircraft:

Frequency = 1090 MHz.
Altitude Rate = 0 FPM
Intruder Aircraft 1:
Equipage = Mode-S ADS-B
Squitter Power = -50 dBm
Altitude = 8000 ft.
Range = 2 NM at T=0 sec.
Altitude = 8000 ft.
Range = Maintained such that the leading edge of the first
preamble pulse from Intruder 2 occurs 12 1.0 s
later than the leading edge of the first preamble pulse
from Intruder 1 throughout the scenario.
TCAS Aircraft:
Altitude = 8000 ft.
Range = 0 NM
Sensitivity Level Selection = Automatic
ADS-B Message Format (Intruder 1):
All ADS-B Message transmissions shall have the following standard data field
values:
DF = 17
CA = 0
Mode-S Squitter Format (Intruder 2):
All Mode-S squitter transmissions shall have the following standard data field
values:
DF = 11
CA = 0
Conditions:
TCAS initialized and operating at T = 0 seconds. Intruders 1 and 2 shall each transmit
squitters during the squitter listening period following each whisper-shout sequence and
shall reply with a short special surveillance format (DF=0) to each TCAS discrete
interrogation.
20xx, RTCA, Inc.
312
Scenario Description:
Both Intruders are co-altitude with TCAS and each transmits squitters when TCAS is in
squitter listening mode and replies to discrete interrogations from TCAS. Intruder 2 is
overlapping the Intruder 1 reply window.
The receiver power levels specified in this procedure are relative to the loss at the RF
message source end of the transmission line used to interface the RF message source to
the UUT receiver input port. For each ADS-B equipage class, the specified power level
shall be adjusted to compensate for the maximum line loss for which the UUT receiver
has been designed. For example, if the line loss is 3 dB, then each of the RF message
power levels specified in the test procedures shall be lowered by 3 dB.
Step 1: Apply ADS-B and Mode-S Input Messages
Apply the message inputs specified above to the receiver input port.
Verify that the TCAS receiver detects intruder #2.
Repeat Steps 1 on all other applicable receiver RF input ports of the UUT.
Step 3: Vary Signal Power Levels
Repeat Steps 1 and 2 with the following additional squitter power levels:
a. Intruder Aircraft 1 Squitter Power = -30 dBm
Intruder Aircraft 2 Squitter Power = -24 dBm
b. Intruder Aircraft 1 Squitter Power = MTL + 3 dB
Intruder Aircraft 2 Squitter Power = MTL + 9 dB
Verify that the TCAS receiver detects Intruder Aircraft #2 for each case.
2.3.2.3.3 Verification of Enhanced Squitter Reception Techniques (2.2.4.4)

No specific test procedures are required to validate 2.3.2.3.3.
The following test procedures apply to Class A1S, A1, A2 and A3 receivers that
implement Enhanced Squitter Reception Techniques and are part of the TCAS Receiver.
2.3.2.3.3.1 Combined Preamble and Data Block Tests with A/C Fruit
Perform the test procedures provided in 2.3.2.4.8.1.
2.3.2.3.3.2 Data Block Tests with Mode S Fruit

20xx, RTCA, Inc.

313
2.3.2.3.3.3 Re-Triggering Performance

2.3.2.4 Receivers Not Shared With TCAS (2.2.4.3)

2.3.2.4.1 In-Band Acceptance (2.2.4.3.1.1.a)

This test verifies the compliance of the ADS-B receiver with the sensitivity requirements
specified for the particular ADS-B equipage class.
Input:
Equipment:

DF = 17
CA = 0
Message Rate = 50 Hz.
Power = -68 dBm
Step 1: Apply ADS-B Input Messages
Step 2: Establish UUT Receiver MTL
Decrease the input power level and determine the minimum RF signal level
required to produce a 90 percent ADS-B Message reception rate by the UUT
receiver.
This value plus the loss line value represents the measured MTL of the UUT
ADS-B receiver.
Verify that the measured MTL is in compliance with the limits specified in
2.2.4.3.1.1.a for the UUT equipment class.
20xx, RTCA, Inc.

314
Step 3: Verify UUT Receiver MTL over the Operational Frequency Range
Vary the RF signal frequency over the range of 1089 to 1091 MHz and
determine the variation in RF signal level required to produce 90 percent ADS-
B Message reception rate by the UUT receiver.
Verify that the measured MTL continues to comply with the limits specified in
Repeat Steps 1 through 3 on all other applicable receiver RF input ports of the
UUT.
2.3.2.4.2 Dynamic Range (2.2.4.3.1.1.b)

This test verifies that the ADS-B receiver can detect and decode valid ADS-B Messages
over the equipments specified dynamic range.
Input:
Equipment:
Provide a method of providing the UUT with:

DF = 17
CA = 0
Power = -68 dBm
required to produce 90 percent ADS-B Message reception rate by the UUT
20xx, RTCA, Inc.

315
receiver. This value plus the loss line value represents the measured MTL of
the UUT ADS-B receiver.
Step 3: Verify UUT Receiver Dynamic Range
Increase the input signal power level to MTL + 3 dB. Verify that the receiver
properly detects and decodes at least 99% of all ADS-B Messages received.
Increase the input signal power level in 10 dB steps up to a signal level of -21
dBm. At each step, verify that the receiver properly detects and decodes at
least 99% of all ADS-B Messages received.
Step 4: Verify Class A3 UUT Receiver Performance
Decrease the input signal power level to 87 dBm. Verify that the receiver
properly detects and decodes at least 15% of all ADS-B Messages input.
UUT.
2.3.2.4.3 Re-Triggerable Capability (2.2.4.3.1.2)

The following procedures verify the capability of the Stand alone ADS-B receiver to
detect overlapping ADS-B broadcast messages.
Input:
Equipment:

DF = 17
CA = 0
Power = -50 dBm
Followed by a second Valid Mode S Extended Squitter:

DF = 17
CA = 0
AA = Any discrete address different from the first one
Power = -42 dBm
Starting 6.0 1.0 sec later than the leading edge of the first ADS-B Message.
20xx, RTCA, Inc.

316
Step 1: Re-Trigger Capability - Part 1
Apply Input at the receiver input and verify that at least the reply ratio in the
following table of the second valid ADS-B Messages are correctly decoded.
Receiver Class Class A1S/A1 Class A2 Class A3
Minimum Probability, Step 1 0.49 0.93 0.93
Repeat Step 1 with the Input signal power level at MTL + 6 dB for the first
ADS-B Message and MTL + 14 dB for the second ADS-B Message.
Repeat Step 1 with Input level at -32 dBm for the first ADS-B Message and
-24 dBm for the second ADS-B Message.
UUT.
2.3.2.4.4 Out-of-Band Rejection (2.2.4.3.2)

This test verifies that the ADS-B out-of-band rejection is in accordance with the specified
values.
Input A:
Equipment:

DF = 17
CA = 0
Power = MTL + 3 dB
20xx, RTCA, Inc.

317
Where MTL is the measured value of

MTL made at 1090 MHz.
Input B:
Same as Input A with:
Frequency = 1084.5 MHz
Power = MTL + 6 dB
Input C:
Power = MTL + 23 dB
Input D:
Power = MTL + 43 dB
Input E:
Power = MTL + 63 dB
Input F:
Power = MTL + 6 dB
Input G:
Power = MTL + 23 dB
Input H:
Power = MTL + 43 dB
Input I:
Power = MTL + 63 dB
20xx, RTCA, Inc.

318
Step 1: Apply Initial ADS-B Input Messages
Apply Input B at the receiver input port and decrease the power level until the
percentage of decoded ADS-B Messages is less than or equal to 90 percent.
Verify that the measured signal power level required to produce a message
decoding percentage of greater than or equal to 90 percent is greater than the
limit specified in Table 2-80 in 2.2.4.3.2.
Step 2: Vary the Input Signal Power and Frequency
Repeat Step 1 using inputs C, D, E, F, G, H, and I.
Repeat Steps 1 and 2 on all other applicable receiver RF input ports of the
UUT.
2.3.2.4.5 Dynamic Minimum Trigger Level (DMTL) (2.2.4.3.3)

This test verifies that, when DMTL control is implemented (see 2.2.4.3.3), then the
ADS-B receiver DMTL is capable of rejecting low level signals during a valid squitter
reception and that DMTL is capable of recovering in not more than 128 microseconds
after the leading edge of the first preamble pulse of a valid ADS-B Message.
Input A:
Equipment:

DF = 17
CA = 0
Power = -61 dBm
Overlapped by a pulse having the following characteristics:
Pulse Width = 120 1 sec
Pulse Rise Time = 0.05 to 0.1 sec
Pulse Fall Time = 0.05 to 0.2 sec
Power = -69 dBm
Starting 0.7 0.2 sec after the leading edge of the first preamble pulse of the
ADS-B Message.
20xx, RTCA, Inc.

319
Input B:

DF = 17
CA = 0
Power = -40 dBm
Power = -49 dBm
ADS-B Message.
Input C:

DF = 17
CA = 0
Power = -21 dBm
Power = -30 dBm
ADS-B Message.
Input D:

DF = 17
CA = 0
Power = -21 dBm
20xx, RTCA, Inc.

320
Followed by a second Valid ADS-B Message having:

DF = 17
CA = 0
Power = -60 dBm
Starting 129 1 sec after the leading edge of the first preamble pulse of the
first ADS-B Message.
Input E:

DF = 17
CA = 0
Power = -70 dBm
Preceded by a pulse having the following characteristics:
Pulse Width = 0.50 sec
Power = -60 dBm
Starting 4.0 sec before the leading edge of the first preamble pulse of the ADS-
B Message.
Input F:

DF = 17
CA = 0
Power = -70 dBm
Power = -60 dBm
Starting 9.0 sec before the leading edge of the first preamble pulse of the ADS-
B Message.
20xx, RTCA, Inc.

321
Step 1: DMTL Desensitization - Part 1
Apply Input A at the receiver input and verify that at least 90 percent of the
valid ADS-B Messages are correctly decoded.
Repeat Step 1 using Input B.
Repeat Step 1 using Input C.
Step 4: DMTL Recovery - Part 4
Apply Input D at the receiver input and verify that at least 90 percent of the
second valid ADS-B Messages are correctly decoded.
Step 5: DMTL Desensitization after a Single Pulse
Apply Input E at the receiver input and verify that no more than 10 percent of
the valid ADS-B Messages are correctly decoded.
Step 6: DMTL Recovery after a Single Pulse
Apply Input F at the receiver input and verify that at least 90 percent of the
2.3.2.4.6 Criteria for ADS-B Message Transmission Pulse Detection (2.2.4.3.4.7.1 and
2.2.4.3.4.7.2)
2.3.2.4.6.1 Criteria for ADS-B Message Transmission Pulse Detection for Receivers not using
Enhanced Reception Techniques
These test procedures verify that the ADS-B reply processor correctly detects the
presence of a valid ADS-B preamble whose pulse characteristics are within the allowable
limits and rejects preambles having pulse spacing and position characteristics that are
outside the allowable limits.
20xx, RTCA, Inc.

322
Note: This test is not applicable to equipment which uses the enhanced reception
techniques. That is, it is not applicable to equipage Classes A1S, A1, A2 and A3.
The enhanced preamble detection requirements for this equipment are tested in
2.3.2.4.6.2.
Reference Input:
Equipment:

DF = 17
CA = 0
Power = -23 dBm (for the first preamble pulse
level
Input A:
Same as the Reference Input, but having the following preamble pulse
characteristics:
Table 2-110: Input A: Preamble Pulse Characteristics
Pulse Rise time Fall time Width Position Amplitude
(sec) (sec) (sec) (sec) (dB)
1 0.05 - 0.1 0.05 - 0.2 +0.05
2 0.05 - 0.1 0.05 - 0.2 -0.05 -0.125 +2
3 0.05 - 0.1 0.05 - 0.2 +0.05 +0.125 +2
4 0.05 - 0.1 0.05 - 0.2 -0.05 -0.125 0
Input B:
characteristics:
Table 2-111: Input B: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 -0.3
2 0.05 - 0.1 0.05 - 0.2 -0.3 0 0
3 0.05 - 0.1 0.05 - 0.2 -0.3 0 0
4 0.05 - 0.1 0.05 - 0.2 -0.3 0 0
Input C:
characteristics:
20xx, RTCA, Inc.

323
Table 2-112: Input C: Preamble Pulse Characteristics

1 0.05 - 0.1 0.05 - 0.2 0
2 0.05 - 0.1 0.05 - 0.2 0 +0.2 0
3 0.05 - 0.1 0.05 - 0.2 0 +0.2 0
4 0.05 - 0.1 0.05 - 0.2 0 +0.2 0
Input D:
characteristics:
Table 2-113: Input D: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 +4.5
2
3 Pulse Not Present
4
Step 1: Preamble Pulse Characteristics set to the Extreme Limits of their Tolerance
Range - Part 1
ADS-B Messages are correctly decoded.
Range - Part 2
Repeat Step 1 with the signal power level at -65 dBm.
Step 3: Preamble Pulse Widths set to Out-of-Tolerance Values - Part 1
Apply Input B at the receiver input and verify that no more than 10 percent of
the ADS-B Messages are correctly decoded.
20xx, RTCA, Inc.

324
Step 5: Preamble Pulse Positions set to Out-of-Tolerance Values - Part 1
Apply Input C at the receiver input and verify that no more than 10 percent of
Step 7: Preamble Single Pulse - Part 1
Apply Input D at the receiver input and verify that no more than 10 percent of
2.3.2.4.6.2 Criteria for ADS-B Message Transmission Pulse Detection for Receivers using
Enhanced Reception Techniques
These tests verify that the ADS-B reply processor correctly detects the presence of a valid
ADS-B preamble whose pulse characteristics are within the allowable limits and rejects
preambles having pulse spacing and position characteristics that are outside the allowable
limits.
Reference Input:
Equipment:

DF = 17
CA = 0
Power = -23 dBm (for the first preamble pulse
level
20xx, RTCA, Inc.

325
Input A:
characteristics:
Table 2-2.3.2.4.6.2A: Input A: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 +0.05
2 0.05 - 0.1 0.05 - 0.2 -0.05 +0.100 +2
3 0.05 - 0.1 0.05 - 0.2 +0.05 +0.100 +2
4 0.05 - 0.1 0.05 - 0.2 -0.05 +0.100 0
Input B:
characteristics:
Table 2-2.3.2.4.6.2B: Input B: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 +0.05
2 0.05 - 0.1 0.05 - 0.2 -0.05 -0.100 +2
3 0.05 - 0.1 0.05 - 0.2 +0.05 -0.100 +2
4 0.05 - 0.1 0.05 - 0.2 -0.05 -0.100 0
Input C:
characteristics:
Table 2-2.3.2.4.6.2C: Input C: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 -0.3
2 0.05 - 0.1 0.05 - 0.2 -0.3 0 0
3 0.05 - 0.1 0.05 - 0.2 -0.3 0 0
4 0.05 - 0.1 0.05 - 0.2 -0.3 0 0
Input D:
characteristics:
Table 2-2.3.2.4.6.2D: Input D: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 +0.3 -0.3
2 0.05 - 0.1 0.05 - 0.2 0 -0.125 0
3 0.05 - 0.1 0.05 - 0.2 +0.3 -0.3 0
4 0.05 - 0.1 0.05 - 0.2 0 +0.125 0
20xx, RTCA, Inc.

326
Input E:
characteristics:
Table 2-2.3.2.4.6.2E: Input E: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 +0.3 -0.3
2 0.05 - 0.1 0.05 - 0.2 0 +0.125 0
3 0.05 - 0.1 0.05 - 0.2 +0.3 -0.3 0
4 0.05 - 0.1 0.05 - 0.2 0 -0.125 0
Input F:
characteristics:
Table 2-2.3.2.4.6.2F: Input F: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 +4.5
2 Pulse Not Present
3 Pulse Not Present
4 Pulse Not Present
to the UUT receiver input port. For each ADS-B equipage class, the specified power level
is adjusted to compensate for the maximum line loss for which the UUT receiver has
been designed. For example, if the line loss is 3 dB, then each of the RF message power
levels specified in the test procedures is lowered by 3 dB.
Range - Part 1
Range - Part 2
Range - Part 3
Apply Input B at the receiver input and verify that at least 90 percent of the
20xx, RTCA, Inc.

327
Range - Part 4
Apply Input C at the receiver input and verify that no more than 10 percent of
Apply Input D at the receiver input and verify that no more than 10 percent of
Apply Input E at the receiver input and verify that no more than 10 percent of
Apply Input F at the receiver input and verify that no more than 10 percent of
2.3.2.4.7 Criteria for Data Block Acceptance in ADS-B Message Signals (2.2.4.3.4.7.3)
This test procedure verifies that ADS-B Messages are accepted when DF field is 17 or 18
and when no more than seven consecutive bits fail the confidence test, as specified by
2.2.4.3.4.7.3.
20xx, RTCA, Inc.

328
Input A:
Equipment:

DF = 17
CA = 0
Power = -50 dBm
The normal data block content shall be modified to contain energy throughout both
halves (i.e., chips) of bit positions 33 to 39. The amplitude of the pulse in the half that
would ordinarily contain no energy shall be 2 dB below the amplitude of the normal
pulse in the other half of the bit position. The data values in bit positions 33 to 39 shall
be chosen so that at least one of these bits will be detected by the UUT with the incorrect
bit value.
Input B:
Equipment:

DF = 18
CA = 0
Power = -50 dBm
bit value.
Input C:
Equipment:

DF = 17
CA = 0
Power = -50 dBm
20xx, RTCA, Inc.

329
bit value.
Step 1: Valid DF=17 ADS-B Message
Apply Input A at the receiver input and verify that all ADS-B Messages are
correctly decoded.
Apply Input B at the receiver input and verify that all ADS-B Messages are
correctly decoded.
Step 3: Corrupted DF=17 ADS-B Messages - Part 1
Apply Input C at the receiver input and verify that ADS-B Messages are not
decoded.
UUT.
2.3.2.4.8 Verification of Enhanced Squitter Reception Techniques (2.2.4.4)

No specific test procedures are required to validate 2.2.4.4.
2.3.2.4.8.1 Combined Preamble and Data Block Tests with A/C Fruit (2.4.4.4.2.4)
The following tests verify the performance of the equipment under test in decoding the
Extended Squitter preamble and data block overlapped with Mode A/C FRUIT while
being subjected to environmental conditions.
Equipment:
Refer to 2.4.4.4.2.1.1 for Mode A/C Fruit Signal Source test requirements.
Refer to 2.4.4.4.2.1.3 for Extended Squitter Signal Source test requirements.
20xx, RTCA, Inc.

330
Step 1: Verification of Operation of Equipment Under Test
Connect the Extended Squitter signal source and set the power level at the
receiver input equal to the MTL limit required for the UUT equipment class:
79 dBm for A1S and A1 equipment class or,
79 dBm for A2 equipment class or,
84 dBm for A3 equipment class.
Inject the Extended Squitter signal 100 times and record the Extended Squitters
that are declared to be output as error free. Compare the decoded content of
each Extended Squitter with the known content of the injected Extended
Squitter. Any differences that are detected are recorded as an undetected error
and that squitter reception is deleted from the count of error free receptions.
Calculate the measured probability of correct receptions and the number of

undetected errors. The test is passed if the probability of correct receptions is at
least 90% and there is no more than one undetected error event.
If this test is successful, proceed to Step 2. Otherwise, the test setup and
equipment under test should be checked and Step 1 is repeated.
Step 2: Test with Three Mode A/C Fruit Overlaps
Set the Extended Squitter signal source as specified in Step 1.
Set the power level of three Mode A/C FRUIT sources at the receiver input to
the value corresponding to the UUT equipment class:
-71, -67 and 63 dBm for A1S, A1 or A2 equipment class or,
-76, -72 and 68 dBm for A3 equipment class.
Activate the Mode A/C FRUIT source so that the FRUIT is pseudo randomly
distributed across the Extended Squitter preamble and data block as specified in
2.4.4.4.2.1.
Inject the Extended Squitter waveform 100 times and record the receptions that
are declared to be error free. Check for undetected errors and adjust as
necessary the number of correctly received replies as specified in Step 1.
Calculate the measured probability of correct reception and the number of
undetected errors.
Step 3: Determination of Success or Failure
Compare the results recorded above with the appropriate requirements in Table
2-114, Table 2-115 or Table 2-116.
20xx, RTCA, Inc.

331
Table 2-114: Success Criteria for Preamble and Data Block Tests
with Mode A/C Fruit Class A1S and A1 Equipment
Number of Fruit 3
Minimum Probability 0.53

Max Undetected Errors 1
with Mode A/C Fruit Class A2 Equipment
Number of Fruit 3

Number of Fruit 3

2.3.2.4.8.2 Data Block Tests with Mode S Fruit (2.4.4.4.2.5)

The following tests verify the performance of the equipment under test in decoding the
Extended Squitter data content overlapped with Mode S FRUIT while being subjected to
environmental conditions.
Equipment:
Refer to 2.4.4.4.2.1.2 for Mode S Fruit Signal Source test requirements.
Connect the Extended Squitter signal source. Set and verify that the power
level at the receiver input is equal to the MTL limit required for the UUT
equipment class plus 12 dB:
67 dBm for A1S, A1 or A2 equipment class or,
Inject the signal 100 times and record the Extended Squitters that are declared
to be output as error free. Compare the decoded content of each Extended
Squitter with the known content of the injected Extended Squitter.
20xx, RTCA, Inc.

332
Any differences that are detected are recorded as an undetected error and that
squitter reception is deleted from the count of error free receptions.

Step 2: Test with One Mode S Fruit Overlap
Activate the Mode S FRUIT source so that the Mode S FRUIT is pseudo
randomly distributed across the data Extended Squitter data block as specified
in 2.4.4.4.2.1.2.
Set the Extended Squitter power to 0 dB relative to the Mode S FRUIT signal
level.
Inject the Extended Squitter waveform 100 times and record the receptions that
undetected errors.
Repeat the above step for relative powers of signal to interference (S/I) of +8
dB.
Calculate the probability of correct reception and the number of undetected

errors for each of the four power levels.
2-117, Table 2-118 or Table 2-119.
Table 2-117: Success Criteria for Data Block Tests

with Mode S Fruit Class A1S and A1 Equipment
Relative Power (S/I) dB 0 +8
Minimum Probability 0 0.99

Max Undetected Errors 1 1
20xx, RTCA, Inc.

333

with Mode S Fruit Class A2 Equipment



2.3.2.4.8.3 Re-Triggering Performance (2.4.4.4.2.6)

The following tests verify the performance of the equipment under test to detect
Extended Squitters that are preceded by lower level Mode S FRUIT while being
subjected to environmental conditions.
Equipment:
Refer to 2.4.4.4.2.1.2 for Mode S Fruit Signal Source test requirements.
Connect the Extended Squitter signal source. Set and verify that the power
level at the receiver input is equal to the MTL limit required for the UUT
equipment class plus 12 dB:
Note: The power levels given above are specified at the antenna connector
and not at the receiver unit-under-test connector.
Inject the signal 100 times and record the Extended Squitters that are declared
to be output as error free. Compare the decoded content of each Extended
Squitter with the known content of the injected Extended Squitter. Any
differences that are detected are recorded as an undetected error and that
squitter reception is deleted from the count of error free receptions.
20xx, RTCA, Inc.

334

Step 2: Re-triggering Test with Varying Position Mode S Fruit
Connect the Mode S Fruit signal source. Set and verify that the power level at
the receiver input is equal to the MTL limit required for the UUT equipment
class plus 12 dB:
Note: The power levels given above are specified at the antenna connector
and not at the receiver unit-under-test connector.
Set the Extended Squitter power to +4 dB relative to the Mode S FRUIT signal
level.
Activate the Mode S FRUIT source so that the 112-bit Mode S FRUIT signal is
uniformly randomly distributed across the time interval beginning at 112
microseconds and ending at 6 microseconds relative to the signal. The time
indicated is the spacing between the P1 pulse of the signal and the P1 pulse of
the FRUIT, where negative values indicate that the FRUIT is received earlier.
Inject the Extended Squitter waveform T times and record the receptions that
undetected errors.
Repeat the above step for relative powers of Signal to Interference (S/I) of
+12 dB.
Calculate the probability of correct reception and the number of undetected

errors for each of the three power levels.
2-120, Table 2-121 or Table 2-122.
Table 2-120: Success Criteria for Re-Triggering Test

with Varying Position Mode S Fruit Class A1S and A1 Equipment
Relative Power, (S/I) dB +4 +12
Minimum Probability 0.12 0.91

20xx, RTCA, Inc.

335

with Varying Position Mode S Fruit Class A2 Equipment



2.3.2.4.9 Track File Maintenance (2.2.8 through 2.2.10)

This procedure is used to verify the general performance characteristics of the ADS-B
Receiving Subsystem under environmental conditions. The scenarios described herein
should be repeated as needed to test the various aspects of the environmental
requirements of the ADS-B Receiving Subsystem.
Equipment:
Provide a method of loading valid ADS-B Broadcast messages of all types into the ADS-
B Receiving Subsystem under test. Provide a method of loading valid position
information into the ADS-B Receiving Subsystem under test.
Step 1: Establish ADS-B Receiving Subsystem Position
Provide the ADS-B Receiving Subsystem with valid position data as listed in
Table 2-123.
Step 2: Surface Participant Stimulus and Track File Maintenance
At a reference time of time zero, begin generation of a series of even and

odd Surface Position from Participants 1 through 4 shown in Table 2-123.
Each Message should be structured using subfield data shown in Table 2-123.
Each message should be provided at the appropriate rate in accordance with
2.2.3.3.2.2.
a. For Receiving Functions that provide only Output Messages in accordance

with 2.2.6, verify that the Receiving function delivers appropriate Output
Messages to the user interface or to the Report Assembly function for all
Surface Participants.
20xx, RTCA, Inc.

336
b. For Receiving Functions that provide a Report Assembly function, verify

that the Receiving function delivers appropriate State Vector Reports for all
Surface Participants in accordance with 2.2.8.1.
Step 3: Airborne Participant Stimulus and Track File Maintenance
While continuing to transmit the Surface Position Messages described in Step

1, begin generation of a series of even and odd Airborne Position Messages
from Participants 5 through 28 shown in Table 2-123. Each message should be
structured using subfield data shown in Table 2-123. Each message should be
provided at the appropriate rate in accordance with 2.2.3.3.2.2.
While continuing to transmit the messages required by Step 1 and the previous
paragraph, begin generation of Airborne Velocity Messages for participants 5
through 28. Each message should be structured using subfield data shown in
Table 2-123. Each message should be provided at the appropriate rate in
accordance with 2.2.3.3.2.5.

with 2.2.6, verify that the Receiving function delivers appropriate Output
Airborne Participants.

that the Receiving function delivers appropriate State Vector Reports for all
Airborne Participants in accordance with 2.2.8.1.
Step 4: Broadcast Message Termination
Terminate the delivery of broadcast messages for all participants. Wait for at
least 200 seconds.

with 2.2.6, verify that the Receiving function ceases to deliver Output
Messages to the user interface or to the Report Assembly function for All
Participants.

that the Receiving function ceases to deliver State Vector Reports for all
Airborne Participants.
20xx, RTCA, Inc.

337
60 nmi North 60 nmi

42.4264 nmi
5 6 7 8 9
14 13 12 11 10
West 15 16 3 RCVR 1 17 18 East

42.4264 nmi 42.4264 nmi
2
23 22 21 20 19
24 25 26 27 28
60 nmi South 60 nmi

42.4264 nmi
Figure 2-32: ADS-B Receiving Subsystem Environmental Test Scenario Pattern
Note: Figure 2-32 provides a visual indication of the placement of the participants listed in
Table 2-123.
20xx, RTCA, Inc.

338
Table 2-123: ADS-B Receiving Subsystem Environmental Test Scenario

E/W E/W N/S N/S Ground Ground
Target DF CA AA Latitude Longitude Altitude Direction Velocity Direction Velocity Speed Track
Numbe (Binary) (Binary) (HEX) (feet) Bit (knots) Bit (knots) (knots) (degrees)
r (Binary) (Binary)
UUT Receiver Location 33.9425361 -118.4080744 126
1 1 0001 100 AA AA AA 33.9425361 -118.3833333 126 10 270

2 1 0001 100 AA BB BB 33.9166666 -118.4080744 126 25 357
3 1 0001 100 AA CC CC 33.9425361 -118.4250000 126 35 90
4 1 0001 100 AA DD DD 33.9583333 -118.4080744 126 60 180
5 1 0001 101 BB AA AA 34.6496427 -119.1151811 35000 0 600 0 0
6 1 0001 101 BB BB BB 34.6496427 -118.7616277 20000 0 0 0 700
7 1 0001 101 BB CC CC 34.6496427 -118.4080744 10000 1 500 0 0
8 1 0001 101 BB DD DD 34.6496427 -118.0545211 15000 0 0 1 550
9 1 0001 101 BB EE EE 34.6496427 -117.7009677 9000 0 500 1 500
10 1 0001 101 CC AA AA 34.2960894 -117.7009667 25000 1 400 1 400
11 1 0001 101 CC BB BB 34.2960894 -118.0545211 15000 0 300 0 300
12 1 0001 101 CC CC CC 34.2960894 -118.4080744 12000 0 250 0 250
13 1 0001 101 CC DD DD 34.2960894 -118.7616277 30000 1 400 1 400
14 1 0001 101 CC EE EE 34.2960894 -119.1151811 37000 1 600 0 600
15 1 0001 101 DD AA AA 33.9425361 -119.1151811 8000 0 300 0 300
16 1 0001 101 DD BB BB 33.9425361 -118.7616277 29000 1 600 0 0
17 1 0001 101 DD CC CC 33.9425361 -118.0545211 26000 0 0 1 650
18 1 0001 101 DD DD DD 33.9425361 -117.7009667 28000 0 600 0 0
19 1 0001 101 DD EE EE 33.5889827 -117.7009667 31000 1 600 0 600
20 1 0001 101 EE AA AA 33.5889827 -118.0545211 25000 1 400 1 400
21 1 0001 101 EE BB BB 33.5889827 -118.4080744 14000 0 0 0 300
22 1 0001 101 EE CC CC 33.5889827 -118.7616277 15000 0 0 0 300
23 1 0001 101 EE DD DD 33.5889827 -119.1151811 16000 1 900 0 0
24 1 0001 101 EE EE EE 33.2354294 -119.1151811 15000 0 400 0 500
25 1 0001 101 FF AA AA 33.2354294 -118.7616277 36000 0 700 0 0
26 1 0001 101 FF BB BB 33.2354294 -118.4080744 19000 1 600 0 0
27 1 0001 101 FF CC CC 33.2354294 -118.0545211 25000 0 955 0 0
28 1 0001 101 FF DD DD 33.2354294 -117.7009667 35000 0 0 1 850
20xx, RTCA, Inc.

339
2.3.2.5 Self Test and Monitors (2.2.11)

No specific test procedure is required to validate 2.2.11.
2.3.2.5.1 Transponder-Based Equipment Address (2.2.11.3.1)

Transponder-Based Equipment shall be tested in accordance with the procedures
provided in 2.3.2.5.2.
Note: The requirement to test Transponder-Based equipment is provided herein due to

the fact that the test requirements provided in RTCA DO-181D do not test the
function adequately.
2.3.2.5.2 Non-Transponder-Based Equipment (2.2.11.3.2)

The following Test Procedures shall be used to verify that the ADS-B Transmitting
monitor function properly enunciates the Fail Warn condition in the event that the
ICAO 24-Bit Address (2.2.5.1.1) provided to the ADS-B Transmitting Subsystem is set
to ALL ZEROs or ALL ONEs.
Equipment Required:
equipment under test. Provide a method of detecting and monitoring ADS-B broadcast
messages. Provide a method of modifying the ICAO 24-Bit Address provided to the Unit
Under Test.
Step 1: Initial Conditions
Establish any state where the ADS-B Transmission Function is operational and
indicating no Fail Warn conditions.
Step 2: Address set to ALL ZEROs
Remove power from the Unit Under Test (UUT). Set the ICAO 24-Bit Address
provided to the UUT to ALL ZEROs. Apply power to the UUT. Verify that
the ADS-B transmission function properly enunciates the Fail Warn state
within no more than 2.0 seconds.
Step 3: New Initial Conditions
Repeat Step 1.
Step 4: Address set to ALL ONEs
Remove power from the Unit Under Test (UUT). Set the ICAO 24-Bit Address
provided to the UUT to ALL ONEs. Apply power to the UUT. Verify that the
20xx, RTCA, Inc.

340
ADS-B transmission function properly enunciates the Fail Warn state within
no more than 2.0 seconds.
Step 5: Restore Normal Operations
indicating no Fail Warn conditions prior to continuing with further testing.
2.3.2.6 Response to Mutual Suppression Pulses (2.2.12)

2.3.2.6.1 Transmitting Device Response to Mutual Suppression Pulses (2.2.12.1)

The following Test Procedures shall be used to verify that the ADS-B Transmitting
Subsystem functions properly in the Mutual Suppression environment.
Equipment Required:
equipment under test. Provide a method of supplying the ADS-B Transmitting
Subsystem with Mutual Suppression Pulses. Provide a method of monitoring and
recording ADS-B transmissions and the time at which such transmissions are generated
with respect to the end of a mutual suppression pulse.
Step 1: Initialize ADS-B Airborne Participant Transmissions
Provide the ADS-B Transmitting Subsystem with all necessary information to

enable the transmitting function to generate the following DF=17 transmitted
messages:
(1). Airborne Position Messages (2.2.3.2.3),
(2). Aircraft Identification and Category Messages (2.2.3.2.5), and
(3). Airborne Velocity Messages (2.2.3.2.6)
Verify that the ADS-B Transmitting Subsystem properly transmits Airborne

Position, Aircraft Identification and Category, and Airborne Velocity Messages
at the rates required in 2.2.3.3.2.2, 2.2.3.3.2.4 and 2.2.3.3.2.5.
Step 2: Apply Mutual Suppression
Apply Mutual Suppression pulses of the maximum length that the suppression
interface is designed to accept. Verify that no ADS-B transmissions occur
during the suppression period.
20xx, RTCA, Inc.

341
Record the transmissions that are generated and verify that transmissions can be
output no later than 15 microseconds after the end of the mutual suppression
pulse.
2.3.2.6.2 Receiving Device Response to Mutual Suppression Pulses (2.2.12.2)

The following Test Procedures shall be used to verify that the ADS-B Receiving device
functions properly in the Mutual Suppression environment.
Equipment Required:
Provide a method of supplying ADS-B Transmitted messages to the ADS-B Receiving

Subsystem. Provide a method of supplying the ADS-B Receiving Subsystem with
Mutual Suppression Pulses that can be synchronized to the ADS-B Transmitted messages
provided to the ADS-B Receiving Subsystem. Provide a method of monitoring and
recording the Receiving function decoded ADS-B Messages or structured ADS-B
Reports.
Step 1: Initialize ADS-B Message Reception
Provide the ADS-B Receiving Subsystem with appropriate ADS-B Messages at

a minimum rate of two per second and having a signal level of the Receiver
MTL + 3 dB. Verify that the Receiving function decodes at least 99 % of the
messages provided to the receiver.
a. Apply Mutual Suppression pulses synchronized to start before each ADS-B

Message provided to the Receiving function.
Ensure that the duration of each Mutual Suppression pulse exceeds that of
the ADS-B Messages being provided to the Receiving function. Verify that
no ADS-B Messages are successfully decoded by the Receiving function.
b. Apply Mutual Suppression pulses that do not over lap any of the ADS-B
Messages provided to the Receiving function and are synchronized to finish
15 microseconds prior to the start of each ADS-B Message provided to the
Receiving function. Verify that at least 90 percent of the ADS-B Messages
provided to the Receiving function are properly decoded by the Receiving
function.
2.3.2.7 Diversity Operation (2.2.13.6)

20xx, RTCA, Inc.

342
2.3.2.7.1 Transmitting Diversity (2.2.13.6.1)

This test procedure verifies that an ADS-B Transmitting Subsystem implements

transmitting diversity properly by transmitting each required type of ADS-B Message
alternately from the top and bottom antennas.
Equipment Required:
Provide a method of supplying the ADS-B Transmitting Subsystem with all data
necessary to structure ADS-B Airborne Position, Airborne Velocity, and Aircraft
Identification and Category messages. All data shall be provided via the operational
interfaces. Provide a method of monitoring the ADS-B Broadcast Messages transmitted
by the ADS-B Transmitting Subsystem.
Step 1: Broadcast Message Initialization
Provide the ADS-B Transmitting Subsystem with all data necessary to structure
Airborne Position, Airborne Velocity, and Aircraft Identification and Category
ADS-B Broadcast Messages.
Step 2: Broadcast Message Verification
Verify that the ADS-B Transmitting Subsystem properly transmits the

appropriate Airborne Position Messages alternately on the Top and Bottom RF
ports.

appropriate Airborne Velocity Messages alternately on the Top and Bottom RF
ports.

appropriate Aircraft Identification and Category Messages alternately on the
Top and Bottom RF ports.
2.3.2.7.2 Receiving Diversity (2.2.13.6.2)

Appropriate test procedures to required to verify the performance of 2.2.13.6.2 are
provided in 2.3.2.7.2.1 through 2.3.2.7.2.2.
2.3.2.7.2.1 Full Receiver and Message Processing or Receiver Switching Front-End Diversity
(2.2.13.6.2)
This procedure verifies that the ADS-B Receiving Subsystem properly implements
diversity by demonstrating proper reception of ADS-B Broadcast Messages from either
the top antenna, or the bottom antenna, or both antennas. This procedure applies to those
configurations that implement Full receiver and message processing function diversity as
20xx, RTCA, Inc.

343
discussed in 2.2.13.6.2.a. This procedure also apples to those configurations that

implement Receiver Switching Front-End diversity as discussed in 2.2.13.6.2.b.
Equipment Required:
Provide a method of supplying the equipment under test with appropriate Airborne
Position ADS-B Broadcast Messages. Provide a method of monitoring the Output
Messages and/or ADS-B Reports generated by the ADS-B Receiving Subsystem.
Provide an RF Splitter/Combiner (2 port, or 3 dB type). Provide RF Attenuators (Fixed,
various attenuation values, as needed)
Step 1: Test Equipment Configuration
Connect the ADS-B Broadcast Message generator to the RF Splitter input.

Connect each output from the RF Splitter to the input of an RF Attenuator.
Connect the output of one RF Attenuator to the Top Channel RF input port of
the equipment under test. Connect the output of the other RF Attenuator to the
Bottom Channel RF input port of the equipment under test.
Step 2: Top Channel is Primary Receiver
Adjust the Top Channel attenuator such that the signal level provided to the
Top Channel RF input port is at least 3 dB above the MTL of the equipment
under test.
Adjust the Bottom Channel attenuator such that the signal level provided to the
Bottom Channel RF input port is 20 dB less than the MTL of the equipment
under test.
Configure the ADS-B Broadcast Message generator to provide only Airborne

Position Messages for a single participant with the position continuously
changing in the message.
Verify that the ADS-B Receiving Subsystem generates appropriate Output

Messages or State Vector Reports for at least 90% of the Airborne Position
Messages provided to the Top Channel RF input port.
Step 3: Bottom Channel is Primary Receiver
Bottom Channel RF input port is at least 3 dB above the MTL of the equipment
under test.
Top Channel RF input port is 20 dB less than the MTL of the equipment under
test.

20xx, RTCA, Inc.

344

Messages provided to the Bottom Channel RF input port.
Step 4: Top / Bottom Channel Equivalent
under test.
Top Channel RF input port is at least 3 dB above the MTL of the equipment
under test.


Messages or State Vector Reports for between 90% and 100% of the Airborne
Position Messages provided to the Bottom Channel RF input port.
2.3.2.7.2.2 Receiving Antenna Switching Diversity (2.2.13.6.2)

This procedure verifies that the ADS-B Receiving Subsystem properly implements
diversity by demonstrating proper reception of ADS-B Broadcast Messages from either
the top antenna or the bottom antenna. This procedure applies to those configurations
that implement Receiving Antenna switching as discussed in 2.2.13.6.2.c.
Equipment Required:
Provide a method of supplying the equipment under test with appropriate Airborne
Position ADS-B Broadcast Messages. Provide a method of monitoring the Output
Messages and/or ADS-B Reports generated by the ADS-B Receiving Subsystem.
Provide RF Attenuators (Fixed, various attenuation values, as needed).
Connect the ADS-B Broadcast Message generator to the RF Attenuator input.

Connect the output of the RF Attenuator to the Top Channel RF input port of
the equipment under test.
Adjust the attenuator such that the signal level provided to the Top Channel RF
input port is at least 3 dB above the MTL of the equipment under test.

20xx, RTCA, Inc.

345


Connect the output of the RF Attenuator to the Bottom Channel RF input port
of the equipment under test.
Adjust the attenuator such that the signal level provided to the Bottom Channel
RF input port is at least 3 dB above the MTL of the equipment under test.


2.3.2.8 Power Interruption (2.2.15)

Appropriate test procedures are found in 2.3.2.8.1 and 2.3.2.8.2.
2.3.2.8.1 Power Interruption to ADS-B Transmitting Subsystems (2.2.15)

The purpose of this procedure is to verify that the ADS-B Transmitting Subsystem
regains operational capability to within its operational limits within two seconds after the
restoration of power following a momentary power interruption.
Equipment Required:
ADS-B Transmitting Subsystem under test through the operational interface.
Step 1: Enable Transmission of Airborne Position Messages
Supply the ADS-B Transmitting Subsystem with the appropriate data necessary
to establish Airborne Position Messages.
Verify that the ADS-B Transmitting Subsystem generates appropriate Airborne

Position Messages at the rate specified in 2.2.3.3.1.1 or 2.2.3.3.2.2.
Note: If the Transmission function uses diversity and the test is being
performed on one RF output interface at a time, then the specified rate
necessary to satisfy this test is half of that given in 2.2.3.3.1.1 or
2.2.3.3.2.2.
20xx, RTCA, Inc.

346
Step 2: Apply momentary power interrupts
Apply momentary power interrupts to the ADS-B Transmitting Subsystem

under test in accordance with RTCA DO-160F section 16 and (EUROCAE ED-
14F, section 16). Then restore the power to normal operating conditions.
Verify that the ADS-B Transmitting Subsystem resumes generation of

appropriate Airborne Position Messages no later than 2.0 seconds after the
restoration of normal power.
Step 3: Repeat for additional RF Output Interfaces
If the ADS-B Transmitting Subsystem implements diversity, then repeat steps 1

and 2 on the additional RF Output Interface.
2.3.2.8.2 Power Interruption to ADS-B Receiving Subsystems (2.2.15)

The purpose of this procedure is to verify that the ADS-B Receiving Subsystem regains
operational capability to within its operational limits within two seconds after the
restoration of power following a momentary power interruption.
Equipment Required:
Provide equipment capable of supplying valid ADS-B broadcast messages to the ADS-B
Receiving Subsystem under test via the appropriate RF interface.
Step 1: Enable Reception of Airborne Position Messages
Via the receiver RF interface and in the absence of interference, apply valid
1090 MHz. Airborne Position Messages at a uniform rate of 2 per second and at
a signal level that is at least 15 dB above the MTL of the ADS-B Receiving
Subsystem.
Verify that the ADS-B Receiving Subsystem delivers appropriate Output

messages received and that the Output Message formats are consistent with the
requirements of 2.2.6.1.1.
Apply momentary power interrupts to the ADS-B Receiving Subsystem under

test in accordance with RTCA DO-160F section 16 (EUROCAE ED-14F,
section 16). Then restore the power to normal operating conditions.
Verify that the ADS-B Receiving Subsystem resumes generation of appropriate

Output Messages to the user interface or to the Report Assembly function no
later than 2.0 seconds after the restoration of power.
20xx, RTCA, Inc.

347
Then verify that the ADS-B Receiving Subsystem continues to deliver

appropriate Output Messages to the user interface or to the Report Assembly
function for all messages received and that the Output Message formats are
consistent with the requirements of 2.2.6.1.1.
If the ADS-B Receiving Subsystem implements diversity, then repeat steps 1

and 2 on the additional RF Input Interface.
2.3.2.9 Verification of Traffic Information Services Broadcast (TIS-B) (2.2.17)

No specific test procedure is required to validate the requirements of 2.2.17.
2.3.2.9.1 Verfication of TIS-B Report Generation (2.2.17.4.6)

Step 1: Verification of Non-Position Report Elements and Timing
Set up to simulate TIS-B Transmitted Messages by inputting TIS-B Message

information directly to the Receiving Subsystem. Input a simulated TIS-B
message.
Verify that within 0.5 seconds of the receipt of this message that all of the non-
position elements are reported directly as received. Repeat this step for each of
the TIS-B message types.
Step 2: Verification of Position Report Elements and Timing

message.
Verify that within 0.5 seconds of the receipt of this message that all of the
position elements (latitude, longitude, altitude, address and TOA) are reported
directly as well as all of the other information received. Repeat this step for
each of the TIS-B message types.
20xx, RTCA, Inc.

348
2.4 Equipment Test Procedures

The test procedures set forth in the following subparagraphs are considered satisfactory
for use in determining required performance under standard and stressed conditions.
Although specific test procedures are cited, it is recognized that other methods may be
preferred by the testing facility. These alternate procedures may be used if the equipment
manufacturer can show that they provide at least equivalent information. In such cases,
the procedures cited herein should be used as one criterion in evaluating the acceptability
of the alternate procedures.
2.4.1 Definition of Terms and Conditions of Test

The following definitions of terms and conditions of tests are applicable to the equipment
tests specified herein commencing at 2.4.2:
a. Power Input Voltage - Unless otherwise specified, all tests shall be conducted with
the power input voltage adjusted to design voltage 2 percent. The input voltage
shall be measured at the input terminals of the equipment under test.
b. Power Input Frequency
(1). In the case of equipment designed for operation from an AC source of

essentially constant frequency (e.g., 400 Hz), the input frequency shall be
adjusted to design frequency 2 percent.
(2). If the equipment is designed for operation from an AC source of variable

frequency (e.g., 300 to 1000 Hz), tests shall be conducted with the input
frequency adjusted to within five percent of a selected frequency and, unless
otherwise specified, within the range for which the equipment is designed.
c. Accuracy of Test Equipment - Throughout this section, the accuracy of the test
equipment is not addressed in detail, but rather is left to the calibration process
prescribed by the agency which certifies the testing facility.
d. Adjustment of Equipment - The circuits of the equipment under test shall be properly
aligned and otherwise adjusted in accordance with the manufacturers recommended
practices prior to application of the specified tests. Unless otherwise specified,
adjustments may not be made once the test procedures have started.
e. Test Instrument Precautions - During the tests, precautions shall be taken to prevent
the introduction of errors resulting from the connection of voltmeters, oscilloscopes
and other test instruments, across the input and output terminals of the equipment
under test.
f. Ambient Conditions - Unless otherwise specified, all tests shall be conducted under
conditions of ambient room temperature, pressure and humidity. However, the room
temperature shall not be lower than 10 degrees C.
g. Connected Loads - Unless otherwise specified, all tests shall be performed with the
equipment connected to loads having the impedance values for which it is designed.
20xx, RTCA, Inc.

349
h. Standard ADS-B Broadcast Message Test Signals
The ADS-B Broadcast Message general signal conventions shall be as specified in

2.2.2 and 2.2.3 through 2.2.3.2.1.7.
General Characteristics
(a). Radio Frequency: - The carrier frequency of the signal generator for ADS-B
Broadcast Messages shall be 1090 1.0 MHz.
(b). CW Output: - The CW output between pulses shall be at least 50 dB below the
peak level of the pulse.
(c). Pulse Rise and Fall Time: - Rise and fall times shall be as specified in
2.2.3.1.3.
(d). Pulse Top Ripple: - The instantaneous amplitude of the pulses shall not fall
more than 1 dB below the maximum value between the 90 percent voltage
amplitude points on the leading and trailing edge of a pulse.
(e). Signal Level: - Unless otherwise noted in the measurement procedure, the signal
level shall be -60 3 dBm.
(f). Broadcast Message Rate: - Unless otherwise noted in the measurement

procedure, ADS-B Broadcast Message Rates shall be 60 5 Hz.
(g). ICAO 24-Bit Discrete Address: - Unless otherwise noted in the measurement
procedure, the ADS-B Transmitting Subsystem address used for all broadcast
messages shall be: Hexadecimal AA AAAA, (i.e., binary 1010 1010 1010
1010 1010 1010).
2.4.2 Verification of ADS-B Transmitter Characteristics (2.2.2)

2.4.2.1 Mode S Transponder-Based Transmitters (2.2.2.1)

Transponder-based transmitters shall be tested to comply with the requirements of RTCA
DO-181D, 2.4.2.2 (EUROCAE ED-73C, section 3.3) inclusive.
Note: Class A0 and Class B0 equipment is limited to aircraft equipment only permitted
to operate below 15,000 feet.
2.4.2.1.1 Verification of RF Peak Output Power (minimum) (2.2.2.1.1)

DO-181D, 2.4.2.2.2 (EUROCAE ED-73C, 3.3.3).
20xx, RTCA, Inc.

350
2.4.2.1.1.1 Verification of Class A0 ADS-B Transponder-Based Transmitter Power

(2.2.2.1.1.1)
DO-181D, 2.4.2.2.2 (EUROCAE ED-73C, 3.3.3).
In addition, the equipment shall be tested in accordance with 2.4.2.2.10.1 of this

document.
2.4.2.1.1.2 Verification of Class A1S and A1 ADS-B Transponder-Based Transmitter Power

(2.2.2.1.1.2)
DO-181D, 2.4.2.2.2 (EUROCAE ED-73C, 3.3.3).

(2.2.2.1.1.3)
DO-181D, 2.4.2.2.2 (EUROCAE ED-73C, 3.3.3).

(2.2.2.1.1.4)
DO-181D, 2.4.2.2.2 (EUROCAE ED-73C, 3.3.3).
2.4.2.1.1.5 Verification of Class B ADS-B Transponder-Based Transmitter Power (2.2.2.1.1.5)

DO-181D, 2.4.2.2.2 (EUROCAE ED-73C, 3.3.3).
When the RF Peak Output Power (minimum) tests are not specified by RTCA DO-181D
(EUROCAE ED-73C), then the equipment shall be tested in accordance with
2.4.2.2.10.2 of this document.
2.4.2.1.2 Verification of RF Peak Output Power (maximum) (2.2.2.1.2)

DO-181D, 2.4.2.2.2 (EUROCAE ED-73C, 3.3.3).
When the RF Peak Output Power (maximum) tests are not specified by RTCA DO-181D
(EUROCAE ED-73C), then the equipment shall be tested in accordance with
2.4.2.2.10.3 of this document.
2.4.2.2 Verification of Stand Alone Transmitters (2.2.2.2)

20xx, RTCA, Inc.

351
2.4.2.2.1 Verification of Transmission Frequency (2.2.2.2.1)

Equipment Required:
ADS-B equipment under test through the operational interface. Provide a Stub Tuner
(Microlab/FXR Sl-05N, or equivalent). Provide a Variable Air Line (Line Stretcher)
(Microlab/FKR SR-05N, or equivalent). Provide a Slotted Line (HP 805C, or
equivalent).
Determine the transmission frequency
Load valid Airborne Position Data into the ADS-B Transmitting Subsystem and ensure
that the expected ADS-B transmissions occur. Adjust the stub to establish a l.5:l VSWR
at the antenna end of the coax line specified by the manufacturer. If the ADS-B
Transmitting Subsystem requires a minimum length of a specified cable type, an
attenuator equal to the loss of the minimum amount of cable may be placed between the
1.5:1 VSWR point and the equipment antenna jack. Alternately, a length of cable equal
to the specified minimum length and cable type may be used in lieu of the attenuator.
Adjust the line stretcher for maximum transmitter frequency shift above and below 1090
MHz. Determine that the frequency shift does not exceed the requirements of 2.2.2.2.1.
2.4.2.2.2 Verification of Transmission Spectrum (2.2.2.2.2)

Test procedures to validate the spectrum requirements for the ADS-B transmitted
message are provided in 2.4.3.1.3 of this document.
2.4.2.2.3 Verification of Modulation (2.2.2.2.3)

Test procedures to validate the modulation requirements for the ADS-B transmitted
message are provided in 2.4.3.1.1 and 2.4.3.1.2 of this document.
2.4.2.2.4 Verification of Pulse Shapes (2.2.2.2.4)

Test procedures to validate the pulse shape requirements for the ADS-B transmitted
2.4.2.2.5 Verification of Message Structure (2.2.2.2.5)

Test procedures to validate the message structure requirements for the ADS-B transmitted
message are provided in 2.4.3.1.1 through 2.4.3.1.4 of this document.
2.4.2.2.6 Verification of Pulse Intervals (2.2.2.2.6)

Test procedures to validate the pulse interval requirements for the ADS-B transmitted
20xx, RTCA, Inc.

352
2.4.2.2.7 Verification of Preamble (2.2.2.2.7)

Appropriate test procedures to validate the ADS-B Message Preamble are provided in
2.4.2.2.8 Verification of Data Pulses (2.2.2.2.8)

Appropriate test procedures to validate the ADS-B Message Data pulses are provided in
2.4.2.2.9 Verification of Pulse Amplitude (2.2.2.2.9)

Appropriate test procedures to validate the ADS-B Message Data Pulse amplitudes are
provided in 2.4.3.1.3 of this document.
2.4.2.2.10 Verification of RF Peak Output Power (2.2.2.2.10)

No specific test procedure is required to validate 2.2.2.2.10, which provides only
general information.
2.4.2.2.10.1 Verification of Class A0 Equipment RF Peak Output Power (2.2.2.2.10.1)

Equipment Required:
Provide a method of generating two ADS-B transmissions at the minimum interval

determined by the ADS-B system implementation. Provide a Wide Band Dual Channel
Note: The generation of the two closely spaced transmissions may be achieved in a
number of possible ways, including: (a) loading the ADS-B system with two ADS-
B transmissions that are scheduled for simultaneous transmission (which will
result in the second transmission being scheduled for transmission after the
first); or (b) configuring/stimulating the system to generate a number of ADS-B
transmissions and monitoring the transmissions until random processes schedule
two at the minimum spacing.
Generate two ADS-B transmissions at the minimum separation that the ADS-B
equipment implements. Ensure that the expected ADS-B transmissions occur at the
minimum expected spacing. Measure the single pulse having the least RF power output
in the two transmissions. Determine that the power output meets the requirements of
2.2.2.2.10.1.
2.4.2.2.10.2 Verification of Class B Equipment RF Peak Output Power (2.2.2.2.10.2)

Equipment Required:
Provide a method of generating two ADS-B transmissions at the minimum interval

determined by the ADS-B system implementation. Provide a Wide Band Dual Channel
20xx, RTCA, Inc.

353
Note: The generation of the two closely spaced transmissions may be achieved in a
number of possible ways, including: (a) loading the ADS-B system with two ADS-
B transmissions that are scheduled for simultaneous transmission (which will
result in the second transmission being scheduled for transmission after the
first); or (b) configuring/stimulating the system to generate a number of ADS-B
transmissions and monitoring the transmissions until random processes schedule
two at the minimum spacing.
Generate two ADS-B transmissions at the minimum separation that the ADS-B
equipment implements. Ensure that the expected ADS-B transmissions occur at the
minimum expected spacing. Measure the single pulse having the least RF power output
in the two transmissions. Determine that the power output meets the requirements of
2.2.2.2.10.2.
2.4.2.2.10.3 Verification of RF Peak Output Power (maximum) (2.2.2.2.10.3)

Equipment Required:
equipment under test. Provide a Wide Band Dual Channel Oscilloscope (HP 1710B, or
equivalent).
Load valid Airborne Position data into the ADS-B Transmitting Subsystem and ensure
that the expected ADS-B transmissions occur. Measure the single pulse having the
maximum RF power output. Determine that the maximum power output meets the
requirements of 2.2.2.2.10.3.
2.4.2.2.11 Verification of Unwanted Output Power (2.2.2.2.11)

Equipment Required:
Spectrum Analyzer (HP 8535A, or equivalent). Provide a Directional Coupler (HP
796D, or equivalent).
Notes:
1. For test equipment protection, the ADS-B transmitter modulation may be

disabled by external means.
2. This unwanted power requirement should be interpreted as an RF leakage test

from the ADS-B transmitter antenna. As such, the ideal implementation would
provide a means to disable ADS-B transmissions while maintaining appropriate
standby power to the transmitter function. That is, the transmitter is powered but
NOT modulated.
Ensure that no ADS-B Message data is available to the equipment under test and that
there are NO ADS-B Broadcast messages being output.
20xx, RTCA, Inc.

354
Record the maximum power output in the range of 1090 MHz plus or minus 3 MHz and
determine that the maximum power output meets the requirements of 2.2.2.2.11.
2.4.2.2.12 Verification of Broadcast Rate Capability (2.2.2.2.12)

Test procedures to validate the broadcast rate capability requirements for the ADS-B
transmitted message are provided in 2.4.3.2.7.9 through 2.4.3.3.2.12 of this document.
2.4.3 Verification of Broadcast Message Characteristics (2.2.3)

2.4.3.1 Verification of ADS-B Message Characteristics (2.2.3.1)

No specific test procedure is required to validate 2.2.3.1, which provides only general
information. The ADS-B Message characteristics are tested in the following modulation
tests as well as in all tests involving ADS-B Message decoding.
2.4.3.1.1 Verification of ADS-B Message Preamble (2.2.3.1.1)

Equipment Required:
Determine Preamble Pulse Spacing
Load valid Airborne Position data into the ADS-B Transmitting Subsystem and verify
that the messages are being transmitted by the equipment under test. Display the ADS-B
Messages on the oscilloscope. Measure the pulse duration of the first four message
pulses. Measure the pulse spacing between the leading edge of the first and each of the
second, third and fourth pulses. Determine that the spacing of the pulses is within the
tolerances specified in 2.2.3.1.1.
2.4.3.1.2 Verification of ADS-B Message Data Pulses (2.2.3.1.2)

Equipment Required:
20xx, RTCA, Inc.

355
Determine Message Data Pulse Width and Duration
Note: For tests in this section, unless otherwise specified, examine pulses at the
beginning, middle and end of the ADS-B broadcast messages.
that the messages are being transmitted by the equipment under test. Measure the pulse
duration of the pulses transmitted in the ADS-B Message throughout the message
transmission. Determine that the duration of the pulses is within the tolerance specified
in 2.2.3.1.2.
Measure the pulse spacing of the fifth reply pulse with reference to the first reply pulse.
Determine that the pulse spacing is within the tolerance specified in 2.2.3.1.2.
2.4.3.1.3 Verification of ADS-B Message Pulse Shape (2.2.3.1.3)

Equipment Required:
Step 1: ADS-B Message Pulse Amplitude Variation (2.2.3.1.3.a)
Load valid Airborne Position data into the ADS-B Transmitting Subsystem and
verify that the messages are being transmitted by the equipment under test.
Measure the maximum power differential between pulses in the ADS-B
Broadcast Message. Verify that it is within the tolerance specified in
2.2.3.1.3.a.
Step 2: ADS-B Message Pulse Shape (2.2.3.1.3.b and c)
Measure the rise and decay time of the ADS-B Broadcast Message pulses.
Verify that they are within the tolerances specified in 2.2.3.1.3.b and c.
Note: Pulse Rise Time is measured as the time interval between 10 percent
and 90 percent of peak amplitude on the leading edge of the pulse.
Pulse Decay Time is measured as the time interval between 90 percent
and 10 percent of peak amplitude on the tailing edge of the pulse. See
Caution statement below.
20xx, RTCA, Inc.

356
CAUTION: If the detector is not known to be linear, checks should be made to

determine what amplitude points on the detected pulse correspond to the
10 percent and 90 percent amplitude points of the RF pulses. In addition,
checks should be made to determine the rise and decay time of the detector.
Step 3: Frequency Spectrum of ADS-B Message Transmission (2.2.3.1.3.d)
Equipment Required:
Provide a method of loading valid data for ADS-B broadcast messages into the
ADS-B equipment under test. Provide a Spectrum Analyzer (HP 8535A, or
equivalent). Provide a Directional Coupler (HP 796D, or equivalent).
Observe the spectral response of the ADS-B Broadcast Message. Verify that it
is within the tolerances specified in Table 2-7.
2.4.3.1.4 Verification of ADS-B Message Pulse Spacing (2.2.3.1.4)

Equipment Required:
ADS-B Message Pulse Spacing Tolerance (2.2.3.1.4)
that the messages are being output. Determine that the leading edges of the reply pulses
are within 50 nanoseconds of their assigned positions.
2.4.3.2 Verification of ADS-B and TIS-B Message Baseline Format and Structures
(2.2.3.2)
2.4.3.2.1 Verification of ADS-B Message Baseline Field Descriptions (2.2.3.2.1)

20xx, RTCA, Inc.

357
2.4.3.2.1.1 Verification of DF Downlink Format Field (2.2.3.2.1.1)

Appropriate test procedures to verify the DF field (2.2.3.2.1.1) are included in the
verification of the PI field in 2.4.3.2.1.7.
2.4.3.2.1.2 Verification of CA Capability Field (used in DF=17) (2.2.3.2.1.2, 2.2.5.1.3)

The CA field is a 3-bit field (baseline message bits 6 through 8) used to report the
capability of an ADS-B Transmitting Subsystem that is based on a Mode S transponder.
The CA field is used to report the capability of the ADS-B Transmitting Subsystem and
is used in DF=11 and DF=17 transmissions. DF=11 is transmitted in response to an
ATCRBS/Mode-S All-Call, Mode-S Only All-Call, and transmitted as an Acquisition
Squitter. DF=17 is transmitted as an Extended Squitter. The codes used in the CA
field are specified in Table 2-8.
The test procedure in 2.4.3.2.1.2.1 shall be conducted for all Transponder-Based ADS-
B transmitter systems. The CA field is set according to the requirements in RTCA DO-
181D (EUROCAE ED-73C) and 2.2.3.2.1.2. ADS-B Transmitting Subsystems shall
determine the On-Ground/Airborne status as specified in 2.2.3.2.1.2 to report the CA
field reported in transponder replies.
2.4.3.2.1.2.1 Verification of On the Ground Determination (2.2.3.2.1.2, 2.2.5.1.2, 2.2.5.1.3)

This test verifies the correct encoding of the CA Capability field in ADS-B
transmissions. If an ADS-B Transmitting Subsystem supports both installations with and
without automatic means of determining on the ground/airborne status, the following
procedures shall be conducted for both configurations.
Notes:
1. Various interface specifications require that Mode S transponder installations

provide a means in which the transponder is rendered incapable of generating
replies to ATCRBS, ATCRBS/Mode S All Call, and Mode S Only All Call
interrogations, but continue to generate Mode S squitter transmissions and continue
to reply to discretely addressed Mode S interrogations when the aircraft is on the
ground. If this condition is enabled automatically when the aircraft is on the ground,
a flight crew switch is not necessary. If performed manually, this condition will have
no effect on the transmission of Extended Squitters or on the reporting of the On-
Ground status (RTCA DO-181D, 2.1.7.b.) (EUROCAE ED-73C, section 2.5).
Manual determination of the On-Ground status may be achieved through a flight
crew switch. Automatic determination of the On-Ground status can be achieved
through weight on wheels, strut switch, etc.
2. Mode-S Transponders should also ensure that all previous TCS commands have been
timed out or have been canceled prior to execution of the following procedures (refer
to RTCA DO-181D, 2.2.18.2.6 for additional information).
20xx, RTCA, Inc.

358
Step 1: CA Field Verification - No Input Data
The following procedure shall be utilized to verify that the CA field is

properly transmitted in DF=17 messages. For ADS-B Transmitting Subsystems
with automatic means of determining the On-Ground status, provide input
external to the ADS-B Transmitting Subsystem to indicate on the ground status.
For Mode-S Transponder-Based transmitting systems, force the DR field
equal to zero (0) indicating no downlink requests. Setup the ADS-B
Transmitting Subsystem to broadcast Extended Squitters by providing data
from the navigation source. After the initiation of Extended Squitters, remove
radio altitude, ground speed and airspeed.
For ADS-B systems that have automatic means of determining the On-Ground
status, verify that the CA Capability field contains a value of FOUR (binary
100) for each Extended Squitter type.
For ADS-B Transmitting Subsystems that do not have automatic means of

determining the On-Ground status, verify that the CA field equals Six (binary
110) for each Extended Squitter type.
Step 2: CA Field Verification With Input Data
Repeat the above procedure for ADS-B Transmitting Subsystems that have
automatic means of determining the On-Ground status. Setup the ADS-B
Transmitting Subsystem as in step 1 except provide external input to set the
ADS-B Transmitting Subsystem to Airborne status. Verify that the CA
Capability field reports a value of FIVE (binary 101) for all Extended Squitter
types.
Step 3: CA Field Verification - Input Data Variation
For Transponder-Based ADS-B Transmitting Subsystems that have automatic

detection of the On-the-Ground status and have ground speed, airspeed or radio
altitude available, the following procedure applies. For ADS-B Transmitting
Subsystems for installations without automatic means of determining the On-
the-Ground status, the following procedure shall verify that the CA field
remains set to 6 throughout the procedure.
Set up the ADS-B Transmitting Subsystem as in Step 1 with the On-the-Ground

status externally provided to the ADS-B Transmitting Subsystem and
additionally provide radio altitude input. Use a value greater than 50 feet.
Vary the Emitter Category data input through the range of Emitter Category
Sets that the system is capable of supporting. Verify that the ADS-B
Transmitting Subsystem correctly broadcasts each Extended Squitter message
type with the CA field equal to 5 for all Emitter Category Set A codes 2
through 6 as specified in Table 2-10.
Repeat the procedure given in the previous paragraph, except change the radio
altitude data to a value less than 50 feet. Verify for each Extended Squitter type
that the reported CA field equals 4.
20xx, RTCA, Inc.

359
Maintain the radio altitude data at a value less than 50 feet and if the system is
capable of accepting ground speed data input, provide ground speed data
greater than 100 knots to the ADS-B Transmitting Subsystem. Verify for each
Extended Squitter type that the reported CA field equals 5 for Emitter
Category Set A, codes 2 through 6.
Maintain the radio altitude data at a value less than 50 feet and set the ground
speed to a value less than, or equal to 100 knots. Verify for each Extended
Squitter type that the reported CA field equals 4.
Maintain the radio altitude data at a value less than 50 feet and the ground
speed at 100 knots or less. If the system is capable of accepting airspeed data
input, provide airspeed data greater than 100 knots to the ADS-B Transmitting
Subsystem. Verify for each Extended Squitter type that the reported CA field
equals 5 for Emitter category Set A, codes 2 through 6.
Maintain the radio altitude data at a value less than 50 feet and the ground
speed at a value less than or equal to 100 knots. Set the airspeed to a value less
than or equal to 100 knots. Verify for each Extended Squitter type that the
reported CA field equals 4.
Step 4: CA Field Verification - Input Data Variation
The following procedure verifies that ADS-B Transmitting Subsystems without

automatic detection of On-The-Ground status and capable of inputting radio
altitude, ground speed, or airspeed, correctly reports CA Field equal to SIX
(6), even when Surface Position Message broadcast is determined according to
the requirements of 2.2.3.2.1.2(c). Set up the ADS-B Transmitting Subsystem
as in Step 1 above. For ADS-B Transmitting Subsystems with automatic means
of determining On-The-Ground status, and capable of inputting radio
altitude, ground speed or airspeed, provide external input to set the system to
Airborne status and verify that the CA Field remains equal to FIVE (5)
throughout this procedure.
For ADS-B Transmitting Systems capable of accepting radio altitude input,

ground speed or airspeed, provide radio altitude data, ground speed and
airspeed data to the ADS-B Transmitting Subsystem according to the values
defined in Table 2-124 or in the case of no data, stop providing the data as
indicated. Verify that the system broadcasts Extended Squitters with the CA
Field equal to SIX (6) for each test condition in Table 2-124.
2.4.3.2.1.2.2 Verification of Air/Ground Format Selection (2.2.3.2.1.2, 2.2.5.1.3)

The following test shall verify that the ADS-B Transmission Device properly selects the
Airborne or Surface Message formats for broadcast. The determination is based upon the
Air/Ground Status data input for aircraft with automatic means of determining the On-
Ground status. Otherwise, the ADS-B Transmitting Subsystem broadcasts Airborne
Messages unless the requirements of Table 2-9 are met to emit Surface Position
Messages.
20xx, RTCA, Inc.

360
Step 1: Ground Status Verification - No Input Data
For ADS-B Transmitting Subsystems with automatic means of determining the

On-Ground status, provide input external to the ADS-B Transmitting
Subsystem to indicate the On-Ground status. Setup the ADS-B Transmitting
Subsystem to broadcast Extended Squitters by providing data from the
navigation source. Provide no radio altitude data, ground speed or airspeed
data to the ADS-B Transmitting Subsystem. For ADS-B systems that have
automatic means of determining the On-Ground status, verify that the Surface
Position Message is broadcast at the proper rate for each Extended Squitter
type. For ADS-B Transmitting Subsystems that do not have automatic means
of determining the On-Ground status, verify that the system broadcasts
Airborne Position and Velocity Messages at the proper rate.
Step 2: Airborne Status Verification No Input Data

Subsystem to indicate airborne status. Setup the ADS-B Transmitting
navigation source. Provide no radio altitude, ground speed or airspeed data to
the ADS-B Transmitting Subsystem. Verify that Airborne Position and
Velocity Messages are broadcast at the proper rate.
Step 3: Air/Ground Status Determination - Input Data Variation

Subsystem to indicate airborne status. Setup the ADS-B Transmitting
navigation source. Provide Radio Altitude data, ground speed and airspeed
data to the ADS-B Transmitting Subsystem according to the values specified in
Table 2-124 or in the case of no data, stop providing the data as indicated. For
ADS-B Transmitting Subsystems with automatic means of determining the On-
Ground status, verify that the ADS-B Transmitting Subsystem broadcasts
Airborne Position and Velocity Messages for each run. For ADS-B
Transmitting Subsystems without automatic means of determining the On-
Ground status, verify that Airborne Position and Velocity Messages or Surface
Position Messages as indicated in Table 2-124 are broadcast at the proper rate
for each run.
20xx, RTCA, Inc.

361
Table 2-124: Air/Ground Status Determination
Ground Radio Resulting

Emitter Category Airspeed
Test Speed Altitude Air/Ground
/ Coding (knots)
(knots) (feet) Status
1 A/2 6, B/7 100 100 50 AIRBORNE
2 A/2 6, B/7 100 50 25 AIRBORNE
3 A/2 6, B/7 50 100 25 AIRBORNE
4 A/2 6, B/7 50 50 50 AIRBORNE
5 A/2 6, B/7 99 99 49 ON-GROUND
6 A/2 6, B/7 50 25 No Data AIRBORNE
8 A/2 6, B/7 49 49 No Data ON-GROUND
9 A/2 6, B/7 No Data 25 No Data AIRBORNE
10 A/2 6, B/7 25 No Data No Data AIRBORNE
11 A/2 6, B/7 100 No Data 25 AIRBORNE
12 A/2 6, B/7 No Data 100 25 AIRBORNE
13 A/2 6, B/7 99 No Data 49 ON-GROUND
14 A/2 6, B/7 No Data 99 49 ON-GROUND
17 A/2 6, B/7 No Data No Data 25 AIRBORNE
18 A/2 6, B/7 No Data No Data No Data AIRBORNE
Step 4: Air/Ground Status Validation On-Ground Override

Subsystem to indicate ground status. Setup the ADS-B Transmitting
navigation source. Provide radio altitude data, ground speed and airspeed data
to the ADS-B Transmitting Subsystem according to the values specified in
Table 2-125 or in the case of no data, stop providing the data as indicated.
Verify that Airborne Position and Velocity Messages or Surface Position
Messages as indicated in Table 2-125 are broadcast at the proper rate for each
run.
20xx, RTCA, Inc.

362
Table 2-125: On-Ground Override

Emitter Ground
Speed Radio Altitude Resulting Vertical
Test Category / Speed
(knots) (feet) Status
Coding (knots)
1 A/2 6, B/7 100 100 50 ON-GROUND
2 A/2 6, B/7 100 100 51 AIRBORNE
3 A/2 6, B/7 100 101 50 AIRBORNE
4 A/2 6, B/7 101 100 50 AIRBORNE
5 A/2 6, B/7 No Data 100 50 ON-GROUND
8 A/2 6, B/7 No Data No Data 50 ON-GROUND
9 A/2 6, B/7 No Data No Data 51 AIRBORNE
10 A/2 6, B/7 100 No Data 50 ON-GROUND
13 A/2 6, B/7 100 No Data No Data ON-GROUND
14 A/2 6, B/7 101 No Data No Data AIRBORNE
15 A/2 6, B/7 No Data 100 No Data ON-GROUND
16 A/2 6, B/7 No Data 101 No Data AIRBORNE
19 A/2 6, B/7 100 100 No Data ON-GROUND
20 A/2 6, B/7 No Data No Data No Data ON-GROUND
2.4.3.2.1.3 Verification of the CF Field (used in DF=18) (0)

Appropriate test procedures to verify the CF field, used in Messages with DF=18, (0)
are included in the verification of the PI field in 2.4.3.2.1.7.
2.4.3.2.1.4 Verification of the AF Field (used in DF=19) (2.2.3.2.1.4)

Appropriate test procedures to verify the AF field (2.2.3.2.1.4) are included in the
verification of the PI field in 2.4.3.2.1.7.
2.4.3.2.1.5 Verification of AA Address Field, Announced (2.2.3.2.1.1, 2.2.5.1.1)

The following test shall be performed for Non-Transponder-Based Subsystems. The

Address Field verification of Transponder-Based Implementations is included in the
verification of the PI field in 2.4.3.2.1.7. ADS-B Transmitting Subsystems for aircraft
installations that are Non-Transponder-Based Implementations output the ICAO 24-Bit
Address or the Anonymous Address as determined by the Address Qualifier input.
20xx, RTCA, Inc.

363
The procedure requires configuring the ADS-B Transmitting Subsystem to generate

ADS-B Messages to enable capture and bit decoding of the ADS-B Message. The
Address Qualifier, ICAO 24-Bit Address, and the Anonymous Address inputs shall be
controlled as required by the following steps.
Step 1: Valid Message Contents When Selecting ICAO 24-Bit Address Verification
Input AAAAAA {HEX} for the ICAO 24-Bit Address. Select ICAO 24-Bit
Address at the Address Qualifier input to the ADS-B Transmitting Subsystem.
Verify the following message content upon decode of the transmitted data:
DF field (Message Bits 1 thru 5) equals 18.

CF field (Message Bits 6 thru 8) equals ZERO.
AA field (Message Bits 9 thru 32) equals AAAAAA {HEX}.
Step 2: Valid Message Contents When Selecting Anonymous Address Verification
Input 555555 {HEX} for the Anonymous Address. Select Anonymous

Address at the Address Qualifier input to the ADS-B Transmitting Subsystem.
Verify the following message content upon decode of the transmitted data:
DF field (Message Bits 1 thru 5) equals 18.

CF field (Message Bits 6 thru 8) equals 1.
AA field (Message Bits 9 thru 32) equals 555555 {HEX}.
2.4.3.2.1.6 Verification of ME Message, Extended Squitter (2.2.3.2.1.6)

No specific test procedure is required to validate 2.2.3.2.1.6.
2.4.3.2.1.7 Verification of PI Parity / Identity (2.2.3.2.1.7, 2.2.5.1.1)

The following test shall verify that the ADS-B Transmitting Subsystem correctly outputs
the Address (AA) field of ADS-B Messages, calculates the proper parity of ADS-B
Messages and correctly outputs the PI field in the transmitted ADS-B Messages.
Configure the ADS-B Transmitting Subsystem to emit ADS-B Messages having TYPE
Code equal to ZERO (0) and no Altitude data. Effectively, establish the messages with
the ME field set to all ZEROs as indicated in Table 2-126. Refer to Table 2-126 and
select the appropriate Set of stimulus to run for the type of equipment being tested as
follows:
a. For equipment that can transmit DF = 17 and CA = 0, use Set 1.
b. For equipment that can transmit DF = 17 and CA = 4, use Set 2.
20xx, RTCA, Inc.

364
c. For equipment that can transmit DF = 17 and CA = 5, use Set 3.
d. For equipment that can transmit DF = 17 and CA = 6, use Set 4.
e. For equipment that can transmit DF = 17 and CA = 7, use Set 5.
f. For equipment that can transmit DF = 18 with CF = 0, use Set 6. Note that this is
the case where the equipment is non-Transponder device.
g. For equipment that can transmit DF = 19 with AF = 0, use Set 7. Note that this
case is where the equipment is for Military Applications.
h. Where an equipment is capable of transmitting several of the cases described in

paragraphs a. through f., above, it should suffice that the equipment be testing to
only one of the cases since the parity encoding should work the same for all.
For the Set of stimulus given in Table 2-126 that is selected for the equipment under test,
establish each of the eight cases by establishing the message having DF, CA or CF,
AA, and ME fields as indicated in Table 2-126.
Note: Since the ADS-B Transmitting Subsystem may not accept changes in the 24-Bit
AA field after initial power on, it may be necessary to re-cycle power to the
unit under test each time that the 24-Bit AA field is changed in this procedure.
For each case of stimulus provided, verify that the ADS-B Transmitting Subsystem
properly generates the associated PI code as given in column 6 of Table 2-126.
For Transponder-Based Systems, verify that the AA field (i.e., the ICAO 24-Bit
Address) cannot be changed once the unit under test has been powered to the operational
state.
For Non-Transponder-Based Systems, where a means to change the ICAO 24-bit Address
is provided and permitted by the appropriate regulatory authority, verify that the AA
field (i.e., the ICAO 24-Bit Address) cannot be changed once the unit under test has been
powered to the operational state unless the system is in Standby mode as per 4.4.6.
20xx, RTCA, Inc.

365
Table 2-126: PI Field Encoding

Column # 1 2 3 4 5 6
Bit # 1 --- 5 6 - 8 9 -------------- 32 33 -------------- 88 89 ------ 112
SET CASE Field CA AA ME PI
# # Name DF (CF) [HEX] [HEX] [HEX]
1 1 0001 000 AA AA AA ALL ZEROs 46E012
2 1 0001 000 55 55 55 ALL ZEROs 5B7924
3 1 0001 000 77 77 77 ALL ZEROs 7DC67B
#1 4 1 0001 000 BB BB BB ALL ZEROs AA45B9
5 1 0001 000 DD DD DD ALL ZEROs C18458
6 1 0001 000 EE EE EE ALL ZEROs B9EAC
7 1 0001 000 FE DC BA ALL ZEROs 7790F4
8 1 0001 000 AB CD EF ALL ZEROs 7EE5D2
1 1 0001 100 AA AA AA ALL ZEROs D8D1FB
2 1 0001 100 55 55 55 ALL ZEROs C548CD
3 1 0001 100 77 77 77 ALL ZEROs E3F792
#2 4 1 0001 100 BB BB BB ALL ZEROs 347450
5 1 0001 100 DD DD DD ALL ZEROs 5FB5B1
6 1 0001 100 EE EE EE ALL ZEROs 95AF45
7 1 0001 100 FE DC BA ALL ZEROs E9A11D
8 1 0001 100 AB CD EF ALL ZEROs E0D43B
1 1 0001 101 AA AA AA ALL ZEROs 80A083
2 1 0001 101 55 55 55 ALL ZEROs 9D39B5
3 1 0001 101 77 77 77 ALL ZEROs BB86EA
#3 4 1 0001 101 BB BB BB ALL ZEROs 6C0528
5 1 0001 101 DD DD DD ALL ZEROs 07C4C9
6 1 0001 101 EE EE EE ALL ZEROs CDDE3D
7 1 0001 101 FE DC BA ALL ZEROs B1DD65
8 1 0001 101 AB CD EF ALL ZEROs B8A543
1 1 0001 110 AA AA AA ALL ZEROs 68330B
2 1 0001 110 55 55 55 ALL ZEROs 75AA3D
3 1 0001 110 77 77 77 ALL ZEROs 531562
#4 4 1 0001 110 BB BB BB ALL ZEROs 8496A0
5 1 0001 110 DD DD DD ALL ZEROs EF5741
6 1 0001 110 EE EE EE ALL ZEROs 254DB5
7 1 0001 110 FE DC BA ALL ZEROs 5943ED
8 1 0001 110 AB CD EF ALL ZEROs 5036CB
1 1 0001 111 AA AA AA ALL ZEROs 304273
2 1 0001 111 55 55 55 ALL ZEROs 2DDB45
3 1 0001 111 77 77 77 ALL ZEROs 0B641A
#5 4 1 0001 111 BB BB BB ALL ZEROs DCE7D8
5 1 0001 111 DD DD DD ALL ZEROs B72639
6 1 0001 111 EE EE EE ALL ZEROs 7D3CCD
7 1 0001 111 FE DC BA ALL ZEROs 013295
8 1 0001 111 AB CD EF ALL ZEROs 0847B3
1 1 0010 000 AA AA AA ALL ZEROs FDAC76
2 1 0010 000 55 55 55 ALL ZEROs E03540
3 1 0010 000 77 77 77 ALL ZEROs C68A1F
#6 4 1 0010 000 BB BB BB ALL ZEROs 1109DD
5 1 0010 000 DD DD DD ALL ZEROs 7AC83C
6 1 0010 000 EE EE EE ALL ZEROs B0D2C8
7 1 0010 000 FE DC BA ALL ZEROs CCDC90
8 1 0010 000 AB CD EF ALL ZEROs C5A9B6
1 1 0011 000 AA AA AA ALL ZEROs 3E3BAD
2 1 0011 000 55 55 55 ALL ZEROs 23A29B
3 1 0011 000 77 77 77 ALL ZEROs 051DC4
4 1 0011 000 BB BB BB ALL ZEROs D29E06
#7 5 1 0011 000 DD DD DD ALL ZEROs B95FE7
6 1 0011 000 EE EE EE ALL ZEROs 734513
7 1 0011 000 FE DC BA ALL ZEROs 0F4B4B
8 1 0011 000 AB CD EF ALL ZEROs 063E6D
2.4.3.2.2 Verification of the Determination of ADS-B and TIS-B Message Types (2.2.3.2.2)
20xx, RTCA, Inc.

366
2.4.3.2.3 Verification of ADS-B Airborne Position Messages (2.2.3.2.3)

2.4.3.2.3.1 Verification of TYPE Subfield in ADS-B Airborne Position Messages

(2.2.3.2.3.1)
This test procedure verifies that the ADS-B Transmitting Subsystem correctly outputs
Airborne Position Messages with the correct TYPE subfield data content in Message Bits
33 through 37 in DF=17 Messages for Transponder-Based Systems and DF=18 Messages
for Non-Transponder-Based Systems. The ME field of the ADS-B Airborne Position
Message contains the TYPE Code subfield in bits 1 through 5, which along with the
Navigation Integrity Category (NIC) Supplement, indicates the navigational integrity of
the position information. The ADS-B Transmitting Subsystem determines and outputs
the TYPE Code subfield based upon the input it receives from the possible Navigational
sources that may interface to the system. The ADS-B Transmitting Subsystem may
receive the TYPE Code subfield directly through an external interface instead of
dynamically determining the TYPE Code subfield. Whatever the implementation, the
test cases must exercise all of the resulting TYPE Code possibilities. If an ADS-B
Transmitting Subsystem can only generate a subset of the possible ADS-B Airborne
Position Message TYPE Codes, then only those test cases required to produce the
possible TYPE Codes shall be tested. The test configuration is based on the type(s) of
Navigational System(s) that may interface to the ADS-B Transmitting Subsystem and the
data it provides.
Step 1: Verification of TYPE Codes 9 through 18, and 20 through 22 with GNSS/Baro
Altitude
Configure the ADS-B Transmitting Subsystem to transmit Airborne Position

Messages by providing position information at the nominal update rate.
Provide the data externally at the interface to the ADS-B system. Set the ADS-
B Transmitting Subsystem to Airborne status. Provide valid non-zero
barometric pressure altitude data to the ADS-B System. For each Navigation
Integrity Category (NIC) supported, verify that the TYPE Code subfield in the
ADS-B Airborne Position Message correctly matches the TYPE Code subfield
value from the Radius of Containment (RC) depicted in Table 2-16.
Additionally, verify that the NIC Supplement contained in the Airborne
Position Message reflects the proper NIC value contained in Table 2-16 (see
2.4.3.2.7.2.6). The NIC may be derived by the Horizontal Radius of
Containment depicted in Table 2-16, or the Horizontal Integrity Limit (HIL), or
another means which establishes an appropriate Radius of Containment. To
test all of the possible resulting TYPE Codes that could be produced from the
Navigational source, degradation of the position data from the Navigation
source may require an alarm or alert condition that must be sensed by the ADS-
B Transmitting Subsystem. The TYPE Code subfield shall contain values in
the range from 9 through 18. In the cases where RC meets the criteria for NIC
values of 9, 10 and 11, verify that the proper TYPE Code and NIC Supplement
are assigned according to the criteria for each of these NIC values.
20xx, RTCA, Inc.

367
Verify that TYPE codes 9 and 10 cannot be set if the unit under test is not
provided with either a GNSS Time Mark (see 2.2.5.1.6) or UTC data unless
the Non-Coupled Case of position estimation (see 2.2.3.2.3.7.2.2 for Latitude,
and 2.2.3.2.3.8.2.2 for Longitude) is implemented.
Note: UTC data is not acceptable to be used in place of GNSS Time Mark
(see 2.2.5.1.6) because of the fact that UTC data may not be available
for any possible time up to 200 milliseconds after the leading edge of
the GNSS Time Mark. Therefore, UTC data may not be used to
establish TYPE Codes 9 and 10.
Stop providing input of barometric altitude to the ADS-B Transmitting

Subsystem and continue providing GNSS Altitude data. If the ADS-B
Transmitting Subsystem supports broadcasting TYPE Codes 20 and 21, then
verify that the TYPE Code subfield in the ADS-B Airborne Position Message
correctly matches the TYPE Code subfield value from the Radius of
Containment values depicted in Table 2-16 for TYPE codes 20 and 21. If
GNSS Altitude data is provided, but it is not possible to determine the RC, then
verify that the TYPE Code subfield is set to 22.
Verify that TYPE Codes 20 and 21 cannot be set if the unit under test is not
provided with either a GNSS Time Mark (see 2.2.5.1.6) or UTC data, unless
Stop providing inputs of barometric altitude and GNSS altitude to the ADS-B
Transmitting Subsystem, and provide position data for each of the RC values
that correspond to the horizontal containment limits for NIC values 0 to 11
(TYPE Codes 9 through 18). Verify that the TYPE Code subfield is 11 and
NIC Supplement is ZERO when RC meets the horizontal containment limits for
NIC of 9, 10 and 11. For all other cases, verify that the TYPE Code and the
NIC Supplement contain values that correspond to the RC value depicted in
Table 2-16, with the Altitude Subfield set to ALL ZEROs.
Step 2: Verification of TYPE Codes 20 through 22 with GNSS Altitude
This step shall be performed for all ADS-B Transmitting Subsystems capable
of broadcasting GNSS Altitude data. Configure the ADS-B Transmitting
Subsystem to transmit Airborne Position Messages. Provide both barometric
altitude and GNSS altitude data to the ADS-B Transmitting Subsystem.
Disconnect the barometric altitude source to the ADS-B Transmitting
Subsystem so that only GNSS altitude data is available. For each NIC value
supported, verify that the TYPE Code subfield in the ADS-B Airborne Position
Message correctly matches the TYPE Code subfield value from the RC range of
values depicted in Table 2-16 for TYPE codes 20 through 22. The TYPE Code
may be derived by the RC depicted in Table 2-16, or the HIL, or another means
20xx, RTCA, Inc.

368
which establishes an appropriate integrity containment. To test all of the

possible resulting TYPE Codes that could be produced from the Navigational
source, degradation of the position data from the Navigation source may require
an alarm or alert condition that must be sensed by the ADS-B Transmitting
Subsystem. Verify that the least capable RC value of each test case is used to
determine the TYPE Code.
Step 3: Verification of TYPE Code if the Radius of Containment is Unavailable
Configure the ADS-B Transmitting Subsystem to Airborne status as in Step

1, and provide navigation data from a source that does not provide a valid R C.
Horizontal Containment Radius is valid from a navigation source that provides
HPL, HIL, or HPL that can be derived from a RAIM protection threshold.
Input both valid barometric altitude and GNSS altitude data. Verify that in the
absence of a valid RC value, the ADS-B Transmitting Subsystem transmits
ADS-B Airborne Position Messages with a TYPE Code subfield set to 18.
Stop providing input of valid barometric altitude data to the ADS-B

Transmitting Subsystem and continue to provide GNSS altitude data. Verify
that the ADS-B Transmitting Subsystem transmits ADS-B Airborne Position
Messages with the TYPE Code subfield set to 22.
Stop providing input of valid GNSS altitude data to the ADS-B Transmitting
Subsystem. Verify that the ADS-B Transmitting Subsystem transmits ADS-B
Airborne Position Messages with the TYPE Code subfield set to ZERO.
2.4.3.2.3.1.1 Verification of Airborne Position Message TYPE Code if Radius of Containment is

Available (2.2.3.2.3.1.1)
Appropriate test procedures are provided in 2.4.3.2.3.1.
2.4.3.2.3.1.2 Verification of Airborne Position Message TYPE Code if Radius of Containment is

Not Available (2.2.3.2.3.1.2)
2.4.3.2.3.1.3 Verification of Special Processing for TYPE Code ZERO (2.2.3.2.3.1.3)

No specific test procedure is required to validate 2.2.3.2.3.1.3.
2.4.3.2.3.1.3.1 Verification of Significance of TYPE Code Equal to ZERO (2.2.3.2.3.1.3.1)

Configure the ADS-B Transmitting Subsystem to Airborne status. Provide valid altitude
code data and a permanent alert (emergency condition) to the ADS-B Transmitting
Subsystem. Connect the GNSS data input and verify that Airborne Position, Velocity
and Aircraft Identification Messages are transmitted at the proper rate.
20xx, RTCA, Inc.

369
Stop update of the Navigational source of Airborne Latitude and Longitude position
information. If the ADS-B Transmitting Subsystem is capable of receiving airborne
position data from more than one Navigation source, verify the following by
disconnecting each Navigation source separately. Verify that after 2 seconds, the TYPE
code of ZERO is transmitted twice per second. Verify that the remaining ME Bits of the
message are ZERO, except for the Altitude subfield, and the Surveillance Status subfield.
After 60 seconds, verify that the Airborne Position Message continues to be transmitted.
Stop providing valid altitude. After 60 seconds, verify that the Airborne Position
Message is no longer transmitted.
Connect the GNSS data input and verify that Airborne Position Messages are broadcast at
a nominal rate of 2 per second.
Repeat above if the Latitude and Longitude sources can be received separately. Stop
update of Latitude data while maintaining update of Longitude data and verify that TYPE
code of ZERO is transmitted twice per second after 2 seconds from data input
disconnection.
Repeat above except stop update of Longitude data while maintaining update of Latitude
data and verify that TYPE code of ZERO is transmitted twice per second after 2 seconds
from data input disconnection.
2.4.3.2.3.1.3.2 Verification of Broadcast of TYPE Code Equal to ZERO (2.2.3.2.3.1.3.2)

Appropriate test procedures are provided in 2.4.3.2.3.1.3.1.
2.4.3.2.3.1.4 Verification of TYPE Code based on Horizontal Position and Altitude Data
(2.2.3.2.3.1.4)
2.4.3.2.3.2 Verification of Surveillance Status Subfield in ADS-B Airborne Position Messages

(2.2.3.2.3.2, 2.2.5.1.4)
The Surveillance Status Subfield (SSS) is contained in ADS-B Airborne Position

Messages TYPE Codes 0, 9 through 18, and 20 through 22. The subfield is a 2-bit
subfield used to indicate Alert Conditions and SPI Condition utilized in ATCRBS for
ATC operations. The alert conditions, as defined, are generated external to the ADS-B
Transmitting Subsystem. When an alert condition is generated and appears at the input to
the ADS-B Transmitting Subsystem, the SSS shall indicate the proper code in the
Airborne Position Message, using ME Bits 6 and 7. SSS shall be verified for all possible
Airborne Position Messages. If the ADS-B Transmitting Subsystem is a Stand Alone
Transmitter, and does not have the ability to set SSS, simply verify that SSS is ZERO in
all generated Airborne Position Messages.
20xx, RTCA, Inc.

370
Step 1: Verification of SSS = 0

Messages. Disconnect the source for Permanent Alert Condition, Temporary
Alert Condition and SPI Condition to the ADS-B Transmitting Subsystem.
Verify that SSS is ZERO in Airborne Position Messages.
Step 2: Verification of SSS = Non 0
Connect the source(s) for Permanent Alert Condition, Temporary Alert

Condition and SPI Condition to the ADS-B Transmitting Subsystem. Input the
following conditions:
a. Set the Permanent Alert Condition and verify that SSS equals ONE (1) in
Airborne Position Messages.
b. Set the Temporary Alert Condition and verify that SSS equals TWO (2)
in Airborne Position Messages.
c. Ensure Temporary Alert Condition is cleared. Set the SPI Condition and
verify that SSS equals THREE (3) in Airborne Position Messages.
d. Set the Permanent Alert Condition and the SPI Condition and verify that
SSS equals ONE (1) in Airborne Position Messages.
e. Set the Temporary Alert Condition and the SPI Condition and verify that
SSS equals 2 in Airborne Position Messages.
2.4.3.2.3.3 Verification of NIC Supplement Subfield in ADS-B Airborne Position Messages

(2.2.3.2.3.3)
Step 1: Verification of NIC Supplement Transmission

Messages by providing valid trajectory information at the nominal update rate.
Provide the data externally at the interface to the ADS-B system.
Verify that for each input NIC parameter that is specified by the RC value in
Table 2-70, that the system generates ADS-B Airborne Position Messages with
the NIC Supplement subfield (ME bit 8) set equal to the corresponding
binary coding value shown in Table 2-70. Do this for all TYPE Codes in Table
2-70 for Airborne Position Messages.
Step 2: Verification of NIC Supplement Data Lifetime
Rerun the Test Procedure in Step 1. Remove the data source input for NIC
Supplement for a period of at least 5 seconds. Verify that ME bit 8 in the
Airborne Position Message is set to a value of ZERO (0).
20xx, RTCA, Inc.

371
2.4.3.2.3.4 Verification of Altitude Subfield in ADS-B Airborne Position Messages

(2.2.3.2.3.4)
2.4.3.2.3.4.1 Verification of Barometric Altitude in ADS-B Airborne Position Messages

(2.2.3.2.3.4.1, 2.2.5.1.5)
This test procedure verifies that the Barometric Altitude is reported correctly in ADS-B
Messages and that the altitude field reported matches the altitude data at the input
interface to the ADS-B Transmitting Subsystem. The Barometric Altitude is reported in
the Altitude subfield of ADS-B Message TYPE Code 0 and Airborne Position TYPE
Codes 9 through 18.
Configure the ADS-B Transmitting Subsystem to transmit Airborne Position Messages.

If the ADS-B transmitter is based on a Mode S transponder, set the ATS input to the
transponder to ZERO.
Step 1: No Barometric Altitude Data
Disconnect the altitude source from the ADS-B Transmitting Subsystem.

Verify that all altitude bits (Message Bits 41 through 52, and ME Bits 9
through 20) in Airborne Position Messages are set to ZERO.
Step 2: Barometric Altitude Data Available
Connect the Barometric Altitude source to the ADS-B Transmitting Subsystem.
Provide the ADS-B Transmitting Subsystem with the Barometric Altitude

Input_A values provided for each case in the following table. Verify that in
each case, the Q bit (ME bit 16) is set to ZERO (0).
For each case, verify that the altitude code is properly encoded into the
Airborne Position Message Altitude Subfield.
Provide the ADS-B Transmitting Subsystem with the Barometric Altitude

Input_B values provided for each case in the following table. Verify that in
each case, the Q bit (ME bit 16) is set to ONE (1).
For each case, verify that the altitude code is properly encoded into the
Airborne Position Message Altitude Subfield.
20xx, RTCA, Inc.

372
Table 2-127: Barometric Altitude Data Inputs

Altitude Input_A Altitude Input_B
Case #
(100 foot increments) (< 25 foot increments)
1 - 1000 - 1012
2 - 900 - 500
3 - 200 - 12.5
4 0 0
5 800 18025
6 2800 32050
7 6800 50175
8 14800 50200
9 30800 51600
10 62800 79800
2.4.3.2.3.4.2 Verification of GNSS Height Above the Ellipsoid (HAE) in ADS-B Airborne
Position Messages (2.2.3.2.3.4.2)
This test procedure verifies that GNSS Height (HAE) is reported correctly in ADS-B
Messages and that the altitude field reported is consistent with the GNSS Height (HAE)
data at the input interface to the ADS-B Transmitting Subsystem. The GNSS Height
(HAE) is reported in the Altitude subfield of Airborne Position Messages having TYPE
Codes 20 through 22.
Configure the ADS-B Transmitting Subsystem to transmit Airborne Position Messages

having any TYPE Code between 20 and 22. If the ADS-B transmitter is based on a
Mode S transponder, set the ATS input to ONE (1).
Step 1: No GNSS Height (HAE) Data
Disconnect the GNSS Height (HAE) source from the ADS-B Transmitting
Subsystem. Verify that all altitude bits (Message Bits 41 through 52, and ME
Bits 9 through 20) in Airborne Position Messages are set to ZERO.
Step 2: GNSS Height (HAE) Data Available
Connect the GNSS Height (HAE) source to the ADS-B Transmitting

Subsystem. Provide the ADS-B Transmitting Subsystem with the GNSS
Height (HAE) input values provided for each case in the following table. For
each case, verify that the altitude code is properly encoded into the Airborne
Position Message Altitude Subfield.
20xx, RTCA, Inc.

373
Table 2-128: GNSS Height (HAE) Data Inputs

GNSS Height (HAE)
Case # (< 25 foot increments)
1 - 1012
2 - 500
3 - 12.5
4 0
5 18025
6 32050
7 50175
8 50200
9 51600
10 79800
2.4.3.2.3.4.3 Verification of Altitude Encoding in ADS-B Airborne Position Messages

(2.2.3.2.3.4.3)
Appropriate test procedures to verify 2.2.3.2.3.4.3 were previously provided in
2.4.3.2.3.4.1 and 2.4.3.2.3.4.2.
2.4.3.2.3.5 Verification of TIME (T) Subfield in ADS-B Airborne Position Messages

(2.2.3.2.3.5, 2.2.5.1.6, 2.2.5.1.6.1, 2.2.5.1.6.2)
Configure the ADS-B Transmitting Subsystem to transmit Airborne Position Messages

by providing position information at the nominal rate. Ensure that the time of
applicability of the position data is synchronized to an exact 0.2 second UTC epoch.
Verify that the ADS-B Transmitting Subsystem accepts a GNSS TIME MARK, or
equivalent input from the navigation data source, which is required in order to be able to
update the position data from the navigation data source to an exact 0.2 second UTC
epoch. Verify that the TIME (T) subfield is set to ONE (1).
If the ADS-B Transmitting Subsystem is not capable of receiving a GNSS Time Mark, or
if the input is not available, verify that the TIME (T) subfield is set to ZERO (0).
Note: The ADS-B Transmitting Subsystem must be capable of monitoring the GNSS
Time Mark unless the non-coupled case (see 2.2.3.2.4.7.2.2) is implemented.
2.4.3.2.3.6 Verification of CPR Format (F) Subfield in ADS-B Airborne Position Messages
(2.2.3.2.3.6)
Appropriate test procedures required to validate 2.2.3.2.3.6 are provided in
2.4.3.2.3.7.1 and 2.4.3.2.3.8.1.
2.4.3.2.3.7 Verification of Encoded Latitude Subfield in ADS-B Airborne Position Messages

(2.2.3.2.3.6, 2.2.3.2.3.7, 2.2.5.1.7, 2.2.5.1.13, Appendix A.1.7)
Appropriate test procedures required to validate 2.2.3.2.3.7 are provided in
2.4.3.2.3.7.1 through 2.4.3.2.3.7.4.
20xx, RTCA, Inc.

374
2.4.3.2.3.7.1 Verification of Airborne Latitude and Longitude Data Encoding (2.2.3.2.3.6,

2.2.3.2.3.7, 2.2.3.2.3.7.1, 2.2.3.2.3.8, 2.2.3.2.3.8.1, 2.2.5.1.7, 2.2.5.1.8,
2.2.5.1.12, 2.2.5.1.13, Appendix A.1.7)
The Encoded Latitude subfield is a 17-bit field (ME Bits 23 through 39, Message Bits
55 through 71) containing the encoded latitude of the airborne position. The Encoded
Longitude subfield is a 17-bit field (ME Bits 40 through 56, Message Bits 72 through
88) containing the encoded longitude of the airborne position. The following test
procedure verifies that the ADS-B Transmitting Subsystem correctly receives Latitude
and Longitude position data from the Navigation source and outputs encoded Latitude
and Longitude data in the Airborne Position Message. The Latitude and Longitude data
is encoded according to the Compact Position Reporting (CPR) Format described in
Appendix A. The Latitude and Longitude data is dependent upon the positional accuracy
supported by the ADS-B Transmitting Subsystem.
The following procedure verifies the static Latitude and Longitude encoding where the
velocity input is 0.0 knots and is intended to verify the actual CPR Latitude and
Longitude encoding precision.
Note: The following procedures are specifically intended to indicate any gross errors
in implementation of the CPR encoding algorithm provided in Appendix A.
Step 1: Establish Initial Conditions
a. Configure the ADS-B Transmitting Subsystem to create an Airborne

Position Message, i.e., TYPE Codes 9 through 18, or 20 through 22.
b. Ensure that the Velocity input provided to the ADS-B Transmitting

Subsystem is set to ZERO.
Step 2: Verify Encoded Latitude Data
a. Via the appropriate Navigation Data Source interface, provide the ADS-B
Transmitting Subsystem with the exact latitude and longitude data pair
provided in the Angular Weighted Binary Values Latitude and Longitude
Columns for each line item given in Table 2-129.
Provide the latitude and longitude data via the interface at the nominal rate
of the navigation data source.
Allow the system to stabilize for at least 2 seconds after the data change
prior to continuing with the following steps.
20xx, RTCA, Inc.

375
Table 2-129: Airborne Position Encoding Values

Angular Weighted Binary Values (degrees) Even Airborne Odd Airborne Encoding
Encoding
Latitude Latitude Longitude Longitude Latitude Longitude Latitude Longitude
Decimal HEX Decimal HEX HEX HEX HEX HEX
-90.000000 C0000000 -180.000000 80000000 00000 10000 08000 10000
-89.950000 C0091A2B 179.500000 7FA4FA50 00444 0FF4A 08432 0FF4A
-89.500000 C05B05B0 178.500000 7EEEEEEF 02AAB 0FDDE 0A9F5 0FDDE
-89.000000 C0B60B61 175.500000 7CCCCCCD 05555 0F99A 0D3E9 0F99A
-87.500000 C1C71C72 -165.000000 8AAAAAAB 0D555 11555 151C7 11555
-86.750000 C24FA4FA -171.500000 860B60B6 11555 0182E 190B6 10C17
-86.500000 C27D27D2 -172.500000 85555555 12AAB 12000 1A5B0 01555
-85.850000 C2F37C05 65.750000 2EC16C17 16222 11889 1DC3B 0BB06
-85.000000 C38E38E4 -142.750000 9A7D27D2 1AAAB 0D3E9 0238E 19EEF
-84.250000 C416C16C 60.000000 2AAAAAAB 1EAAB 1AAAB 0627D 15555
-83.550000 C4962FC9 -60.000000 D5555555 02666 00000 09D3A 05555
-82.680000 C53490BA 120.000000 55555555 070A4 0AAAB 0E63B 00000
-81.750000 C5DDDDDE -120.000000 AAAAAAAB 0C000 0AAAB 13444 15555
-80.250000 C6EEEEEF 144.000000 66666666 14000 13333 1B222 06666
-79.750000 C749F49F -144.000000 9999999A 16AAB 00000 1DC17 0CCCD
-78.400000 C83FB72F -121.000000 A9F49F4A 1DDDE 09B06 04D5E 1471C
-77.400000 C8F5C28F 121.000000 560B60B6 03333 01111 0A148 164FA
-76.550000 C9907F6E -154.280000 924A2EE0 07BBC 0DB89 0E89B 1B6F4
-75.600000 CA3D70A4 154.280000 6DB5D120 0CCCD 1FFE3 13852 12477
-74.750000 CAD82D83 157.500000 70000000 11555 12000 17FA5 04000
-73.650000 CBA06D3A -157.500000 90000000 17333 00000 1DBF2 0E000
-72.750000 CC444444 -120.000000 AAAAAAAB 1C000 0AAAB 02777 15555
-71.550000 CD1EB852 120.000000 55555555 02666 00000 08C29 15555
-70.650000 CDC28F5C -144.000000 9999999A 07333 0CCCD 0D7AE 1999A
-69.550000 CE8ACF13 144.000000 66666666 0D111 00000 133FB 13333
-68.750000 CF1C71C7 -114.550000 AE8ACF13 11555 0A2C6 1771C 145B0
-67.750000 CFD27D28 114.550000 517530ED 16AAB 00024 1CB06 15D3A
-66.550000 D0ACF135 -67.500000 D0000000 1D111 16000 02FB7 1C000
-65.550000 D162FC96 67.500000 30000000 02666 10000 083A0 0A000
-64.450000 D22B3C4D -83.080000 C4EBBF60 08444 0760B 0DFEE 0EC34
-63.250000 D305B05B 83.080000 3B1440A0 0EAAB 0001D 1449F 189F5
-62.250000 D3BBBBBC -64.290000 D2485CD8 14000 05B44 19889 0B6B3
-61.250000 D471C71C 64.290000 2DB7A328 19555 0002C 1EC72 1A4BC
-60.250000 D527D27D -72.000000 CCCCCCCD 1EAAB 06666 0405B 0CCCD
-59.960000 D55C9D78 -120.500000 AA4FA4FA 0036A 0960B 058B1 1416C
-59.955000 D55D867C 120.000000 55555555 003D7 15555 0591C 0AAAB
-59.930000 D5621392 -119.500000 AB05B05B 005F9 01555 05B35 0BF4A
-58.000000 D6C16C17 -78.750000 C8000000 0AAAB 07000 0FD28 0E000
-58.500000 D6666666 78.750000 38000000 08000 19000 0D333 12000
-57.950000 D6CA8642 -22.500000 F0000000 0AEEF 02000 1015A 04000
20xx, RTCA, Inc.

376
Table 2-129: Airborne Position Encoding Values (continued)

Even Airborne
Angular Weighted Binary Values (degrees) Odd Airborne Encoding
Encoding
-56.850000 D792C5F9 22.500000 10000000 10CCD 00000 15DA7 1E000
-55.500000 D8888889 -52.940000 DA5A912E 18000 04B59 1CEEF 096A4
-54.620000 D928BB81 52.940000 25A56ED2 1CB18 1FFF1 018C6 1B4A7
-53.250000 DA222222 -30.000000 EAAAAAAB 04000 02AAB 08BBC 05555
-51.950000 DB0ECA86 30.000000 15555555 0AEEF 00000 0F8D1 1D555
-50.750000 DBE93E94 -75.790000 CA1ADA00 11555 06BC3 15D83 0D78D
-49.650000 DCB17E4B 75.790000 35E52600 17333 00007 1B9D0 1943D
-48.250000 DDB05B06 -27.000000 ECCCCCCD 1EAAB 02666 02F4A 04CCD
-47.000000 DE93E93F 27.000000 13333333 05555 00000 0982E 1D99A
-45.600000 DF92C5F9 -68.570000 CF3D3663 0CCCD 0619B 10DA7 0C321
-44.250000 E0888889 -180.000000 80000000 14000 00000 17EEF 10000
-42.850000 E1876543 179.500000 7FA4FA50 1B777 0E16C 1F469 1E222
-41.400000 E28F5C29 178.500000 7EEEEEEF 03333 1A222 06E14 0A444
-40.000000 E38E38E4 175.500000 7CCCCCCD 0AAAB 1E000 0E38E 0E666
-38.500000 E49F49F5 -160.900000 8D950C84 12AAB 0E190 1616C 1C666
-36.900000 E5C28F5C -171.500000 860B60B6 1B333 1382E 1E7AE 02C17
-35.250000 E6EEEEEF -172.500000 85555555 04000 00000 07222 0F555
-33.600000 E81B4E82 65.750000 2EC16C17 0CCCD 1E60B 0FC96 18889
-31.800000 E962FC96 -142.750000 9A7D27D2 16666 058E4 193A0 123E9
-30.000000 EAAAAAAB 59.500000 2A4FA4FA 00000 0DBBC 02AAB 0871C
-28.000000 EC16C16C -60.000000 D5555555 0AAAB 0AAAB 0D27D 10000
-25.900000 ED950C84 -66.700000 D091A2B4 15DDE 05C4D 182B4 0BB2A
-23.600000 EF37C049 -120.000000 AAAAAAAB 02222 00000 043B3 0AAAB
-21.100000 F0FEDCBB 41.500000 1D82D82E 0F777 0AE39 1157A 07333
-18.200000 F30ECA86 -144.000000 9999999A 1EEEF 13333 008D1 00000
-14.900000 F56789AC -121.000000 A9F49F4A 10889 1AEEF 11DB9 05B06
-10.500000 F8888889 121.000000 560B60B6 08000 0FD28 08EEF 05111
-5.100000 FC5F92C6 6.250000 0471C71C 04CCD 00C72 0540E 0038E
-2.500000 FE38E38E 154.280000 6DB5D120 12AAB 091CE 12E39 1B663
0.000000 00000000 60.000000 2AAAAAAB 00000 1AAAB 00000 15555
0.000000 00000000 -157.500000 90000000 00000 06000 00000 14000
90.000000 40000000 -180.000000 80000000 00000 10000 18000 10000
89.950000 3FF6E5D5 179.500000 7FA4FA50 1FBBC 0FF4A 17BCE 0FF4A
89.500000 3FA4FA50 178.500000 7EEEEEEF 1D555 0FDDE 1560B 0FDDE
89.000000 3F49F49F 175.500000 7CCCCCCD 1AAAB 0F99A 12C17 0F99A
87.500000 3E38E38E -165.000000 8AAAAAAB 12AAB 11555 0AE39 11555
86.750000 3DB05B06 -171.500000 860B60B6 0EAAB 0182E 06F4A 10C17
86.500000 3D82D82E -172.500000 85555555 0D555 12000 05A50 01555
85.850000 3D0C83FB 65.750000 2EC16C17 09DDE 11889 023C5 0BB06
85.000000 3C71C71C -142.750000 9A7D27D2 05555 0D3E9 1DC72 19EEF
84.250000 3BE93E94 60.000000 2AAAAAAB 01555 1AAAB 19D83 15555
20xx, RTCA, Inc.

377

Even Airborne
Encoding
83.550000 3B69D037 -60.000000 D5555555 1D99A 00000 162C6 05555
82.680000 3ACB6F46 120.000000 55555555 18F5C 0AAAB 119C5 00000
81.750000 3A222222 -120.000000 AAAAAAAB 14000 0AAAB 0CBBC 15555
80.250000 39111111 144.000000 66666666 0C000 13333 04DDE 06666
79.750000 38B60B61 -144.000000 9999999A 09555 00000 023E9 0CCCD
78.400000 37C048D1 -121.000000 A9F49F4A 02222 09B06 1B2A2 1471C
77.400000 370A3D71 121.000000 560B60B6 1CCCD 01111 15EB8 164FA
76.550000 366F8092 -154.280000 924A2EE0 18444 0DB89 11765 1B6F4
75.600000 35C28F5C 154.280000 6DB5D120 13333 1FFE3 0C7AE 12477
74.750000 3527D27D 157.500000 70000000 0EAAB 12000 0805B 04000
73.650000 345F92C6 -157.500000 90000000 08CCD 00000 0240E 0E000
72.750000 33BBBBBC -120.000000 AAAAAAAB 04000 0AAAB 1D889 15555
71.550000 32E147AE 120.000000 55555555 1D99A 00000 173D7 15555
70.650000 323D70A4 -144.000000 9999999A 18CCD 0CCCD 12852 1999A
69.550000 317530ED 144.000000 66666666 12EEF 00000 0CC05 13333
68.750000 30E38E39 -114.550000 AE8ACF13 0EAAB 0A2C6 088E4 145B0
67.750000 302D82D8 114.550000 517530ED 09555 00024 034FA 15D3A
66.550000 2F530ECB -67.500000 D0000000 02EEF 16000 1D049 1C000
65.550000 2E9D036A 67.500000 30000000 1D99A 10000 17C60 0A000
64.450000 2DD4C3B3 -83.080000 C4EBBF60 17BBC 0760B 12012 0EC34
63.250000 2CFA4FA5 83.080000 3B1440A0 11555 0001D 0BB61 189F5
62.250000 2C444444 -64.290000 D2485CD8 0C000 05B44 06777 0B6B3
61.250000 2B8E38E4 64.290000 2DB7A328 06AAB 0002C 0138E 1A4BC
60.250000 2AD82D83 -72.000000 CCCCCCCD 01555 06666 1BFA5 0CCCD
59.960000 2AA36288 -120.500000 AA4FA4FA 1FC96 0960B 1A74F 1416C
59.955000 2AA27984 120.000000 55555555 1FC29 15555 1A6E4 0AAAB
59.930000 2A9DEC6E -119.500000 AB05B05B 1FA07 01555 1A4CB 0BF4A
58.000000 293E93E9 -78.750000 C8000000 15555 07000 102D8 0E000
58.500000 2999999A 78.750000 38000000 18000 19000 12CCD 12000
57.950000 293579BE -22.500000 F0000000 15111 02000 0FEA6 04000
56.850000 286D3A07 22.500000 10000000 0F333 00000 0A259 1E000
55.500000 27777777 -52.940000 DA5A912E 08000 04B59 03111 096A4
54.620000 26D7447F 52.940000 25A56ED2 034E8 1FFF1 1E73A 1B4A7
53.250000 25DDDDDE -30.000000 EAAAAAAB 1C000 02AAB 17444 05555
51.950000 24F1357A 30.000000 15555555 15111 00000 1072F 1D555
50.750000 2416C16C -75.790000 CA1ADA00 0EAAB 06BC3 0A27D 0D78D
49.650000 234E81B5 75.790000 35E52600 08CCD 00007 04630 1943D
48.250000 224FA4FA -27.000000 ECCCCCCD 01555 02666 1D0B6 04CCD
47.000000 216C16C1 27.000000 13333333 1AAAB 00000 167D2 1D99A
45.600000 206D3A07 -68.570000 CF3D3663 13333 0619B 0F259 0C321
44.250000 1F777777 -180.000000 80000000 0C000 00000 08111 10000
20xx, RTCA, Inc.

378

Even Airborne
Encoding
42.850000 1E789ABD 179.500000 7FA4FA50 04889 0E16C 00B97 1E222
41.400000 1D70A3D7 178.500000 7EEEEEEF 1CCCD 1A222 191EC 0A444
40.000000 1C71C71C 175.500000 7CCCCCCD 15555 1E000 11C72 0E666
38.500000 1B60B60B -160.900000 8D950C84 0D555 0E190 09E94 1C666
36.900000 1A3D70A4 -171.500000 860B60B6 04CCD 1382E 01852 02C17
35.250000 19111111 -172.500000 85555555 1C000 00000 18DDE 0F555
33.600000 17E4B17E 65.750000 2EC16C17 13333 1E60B 1036A 18889
31.800000 169D036A -142.750000 9A7D27D2 0999A 058E4 06C60 123E9
30.000000 15555555 59.500000 2A4FA4FA 00000 0DBBC 1D555 0871C
28.000000 13E93E94 -60.000000 D5555555 15555 0AAAB 12D83 10000
25.900000 126AF37C -66.700000 D091A2B4 0A222 05C4D 07D4C 0BB2A
23.600000 10C83FB7 -120.000000 AAAAAAAB 1DDDE 00000 1BC4D 0AAAB
21.100000 0F012345 41.500000 1D82D82E 10889 0AE39 0EA86 07333
18.200000 0CF1357A -144.000000 9999999A 01111 13333 1F72F 00000
14.900000 0A987654 -121.000000 A9F49F4A 0F777 1AEEF 0E247 05B06
10.500000 07777777 121.000000 560B60B6 18000 0FD28 17111 05111
5.100000 03A06D3A 6.250000 0471C71C 1B333 00C72 1ABF2 0038E
2.500000 01C71C72 154.280000 6DB5D120 0D555 091CE 0D1C7 1B663
0.000000 00000000 60.000000 2AAAAAAB 00000 1AAAB 00000 15555
0.000000 00000000 -157.500000 90000000 00000 06000 00000 14000
b. For each Even interval Airborne Position Message that is broadcast by the
ADS-B Transmitting Subsystem:
(1). Verify that the CPR Format (F) subfield is set to ZERO (0), and
(2). Verify that the Encoded Even Interval Latitude subfield is encoded
exactly as shown in the Even Airborne Encoding Latitude column of
Table 2-129.
If the encoding is not exact, verify that the encoding does not differ
from the table value by more than 1 Least Significant Bit (LSB).
If the encoded value differs from the table value by more than 1 LSB,
then the test shall be considered to have Failed. Otherwise, the test
shall be considered to have passed.
(3). Verify that the Encoded Even Interval Longitude subfield is encoded
exactly as shown in the Even Airborne Encoding Longitude column of
Table 2-129.
20xx, RTCA, Inc.

379
c. For each Odd interval Airborne Position Message that is broadcast by the
(1). Verify that the CPR Format (F) subfield is set to ONE (1), and
(2). Verify that the Encoded Odd Interval Latitude subfield is encoded
exactly as shown in the Odd Airborne Encoding Latitude column of
Table 2-129.
(3). Verify that the Encoded Odd Interval Longitude subfield is encoded
exactly as shown in the Odd Airborne Encoding Longitude column of
Table 2-129.
2.4.3.2.3.7.2 Verification of Airborne Latitude Position Extrapolation/Estimation (Precision

Case, TYPE Codes 9, 10, 20 and 21) (2.2.3.2.3.7.2)
Appropriate test procedures are provided in 2.4.3.2.3.7.2.1 and 2.4.3.2.3.7.2.2.
2.4.3.2.3.7.2.1 Verification of GPS/GNSS Time Mark Coupled Case (Extrapolation, TIME (T) =
1) (2.2.3.2.3.7.2.1)
This test procedure will be used to verify that the ADS-B Transmitting Subsystem
correctly extrapolates and encodes Airborne Position data when working with GNSS
synchronized time.
Equipment Required:
Equipment capable of performing the following:
a. Load all valid data required for the ADS-B Airborne Position Message into the ADS-
B Transmitting Subsystem via the operational interfaces.
20xx, RTCA, Inc.

380
The equipment should be capable of updating Latitude position and North/South

Velocity given time, initial Latitude position, initial North/South Velocity, and
North/South acceleration. The Latitude Position provided to the ADS-B
Transmission system shall be referred to as the Computed Latitude. Likewise, the
North/South Velocity provided to the ADS-B Transmission system shall be referred
to as the Computed N/S Velocity.
The equipment should be capable of updating Longitude position and East/West

Velocity given time, initial Longitude position, initial East/West Velocity, and
East/West acceleration. The Longitude Position provided to the ADS-B
Transmission system shall be referred to as the Computed Longitude. Likewise, the
East/West Velocity provided to the ADS-B Transmission system shall be referred to
as the Computed E/W Velocity.
The equipment should be capable of providing position information and velocity

information to the ADS-B Transmitting Subsystem at a rate of not less than 5 times
per second for each navigation parameter provided.
b. Provide the ADS-B Transmitting Subsystem with an appropriate GNSS Time Mark
as described in 2.2.5.1.6.
The equipment shall also be capable of time-tagging the GNSS Time Mark leading
edge event to a minimum accuracy of 1.0 millisecond.
c. When providing the GNSS Time Mark described in subparagraph b, above, the
equipment shall have re-computed position and velocity information required by
subparagraph a, above, available at one second intervals that are synchronized with
the leading edge of the GNSS Time Mark. Initial delivery of the all new computed
position and velocity data to the ADS-B Transmission system shall be completed no
later than 200 milliseconds after the leading edge of the GNSS Time Mark.
d. The monitoring of transmitted ADS-B Airborne Position Messages and the Airborne
Velocity Messages and the extraction of all subfields as may be required. The
equipment shall also be capable of time-tagging the receipt of any ADS-B Broadcast
message to a minimum accuracy of 1.0 milliseconds.
e. Performing local unambiguous CPR decoding of the encoded latitude and longitude
subfields in accordance with Appendix A, A.1.7.4, A.1.7.5 and A.1.7.9.
f. After performing the encoded latitude and longitude local unambiguous CPR
decoding, the equipment shall be capable of computing the difference between the
Decoded Latitude Position and the Computed Latitude. Likewise, the equipment
shall be capable of computing the difference between the Decoded Longitude
Position and the Computed Longitude.
g. After extraction of the Velocity subfields from the Airborne Velocity Message, the
equipment shall compute the difference between the extracted North/South Velocity
and the Computed N/S Velocity. Likewise, the equipment shall compute the
difference between the extracted East/West Velocity and the Computed E/W
Velocity.
20xx, RTCA, Inc.

381
Step 1: Equipment Initialization (North-South)
Initialize the equipment to provide the following to the ADS-B Transmitting

Subsystem.
DO NOT START DELIVERY OF THE DATA AT THIS TIME
a. Initialize Time Reference at: t0
Set initial Computed Longitude to: 45.0 degrees WEST
Set initial Computed Latitude to: 0.0625 degrees NORTH
Set initial Computed N/S Velocity to: 1020 knots SOUTH
Note: The velocity requirements above are specified in terms of

North/South velocities. If alternate velocity and direction sources
are used, i.e., ground speed and ground track, then it is up to the
implementer to verify that such information is properly resolved
into the North/South Velocity required in the transmitted messages.
b. GNSS Time Mark as described above under Equipment subparagraphs b

and c.
c. All other data required to generate the Airborne Position Message and the
Step 2: Equipment Data Delivery Start Up
Allow the equipment to start delivery of the data specified in Step 1 and
designate this time as t0. Continue to let the equipment provide the data for at
least 35 seconds.
Step 3: Latitude Position Performance
Notes:
1. Since there has been no position or velocity data provided to the ADS-
B Transmitting Subsystem up to this time (at least for the purposes of
this test procedure), a minimal amount of time will need to be allowed
for the transmitted message data to stabilize. This fact has been
factored in to the following required response criteria.
2. Be advised that this test scenario is forcing movement across the

Equator at 1020 knots from North to South.
a. At 4.0 0.005 seconds after executing Step 2 where data has started being
provided to the ADS-B Transmitting Subsystem under test:
20xx, RTCA, Inc.

382
Verify that the Decoded Latitude Position differs from the Computed
Latitude Position by no more than 22.1 meters (i.e., approximately 0.0002
degrees of Latitude).
b. At all successive points during the time of test that occur at least 6 seconds
after the execution of Step 2:
Latitude Position by no more than 6.375 meters (i.e., approximately
0.000058 degrees of Latitude).
c. Select an Airborne Position Message that was received at least 6 seconds

after the execution of Step 2 and within 50 25 milliseconds of a GNSS
Time Mark generated by the Test Equipment and provided to the ADS-B
Transmitting Subsystem. Designate the leading edge of the GNSS Time
Mark as t1.
Latitude Position at time t1 + 200 milliseconds by no more than 6.375
meters (i.e., approximately 0.000058 degrees of Latitude).
d. Verify that the received message was encoded in the proper format, i.e.,
odd or even encoding, by correlating the received message to the stimulus
data provided by the test equipment.
Note: This test is intended to demonstrate that the UUT is encoding data
correctly in regards to the 0.2 UTC Epochs and in regards to the
alternating odd and even encodings. Since the test set knows what
the data is at given 1.0 second intervals, and it also time tags the
received data, it is reasonable to expect that this capacity is
adequate to establish the proper 0.2 UTC Epochs and the
appropriate format encoding.
Step 4: Velocity Performance (Optional. Apply only if the UUT is estimating or

extrapolating velocity)
Verify that the Extracted North/South Velocity differs no more than 5%

from the Computed North/South Velocity that was provided to the ADS-B
Transmitting Subsystem during the GNSS Epoch defined by the leading
edge of the GNSS Time Mark delivered to the ADS-B Transmitting
Subsystem at least 325 milliseconds prior to the transmission of the
Airborne Velocity Message for which the accuracy is being checked.

20xx, RTCA, Inc.

383

Step 5: Equipment Re-Initialization (South-North)
Note 1: Be advised that this test scenario is forcing movement across the
Equator at 1020 knots from South to North.
Repeat Step 1 with the following equipment settings:
Initialize Time Reference at: t0
Set initial Computed Longitude to: 45.0 degrees EAST
Set initial Computed Latitude to: 0.0625 degrees SOUTH
Set initial Computed N/S Velocity to: 1020 knots NORTH
Note 2: The velocity requirements above are specified in terms of

North/South velocities. If alternate velocity and direction
sources are used, i.e., ground speed and ground track, then it is
up to the implementer to verify that such information is properly
resolved into the North/South Velocity required in the
transmitted messages.
Step 6: Performance Check (South-North)
Repeat Steps 2 through 4.
Step 7: Equipment Re-Initialization (North Pole)
North Pole at 1020 knots from South to North. It is up to the
equipment designers to insure that equipment under test and the test
equipment properly move across the pole by moving up to 90.0
degrees North and then down from the pole for the duration of the
test.
20xx, RTCA, Inc.

384

Step 8: Performance Check (North Pole)
Step 9: Equipment Re-Initialization (South Pole)
South Pole at 1020 knots from North to South. It is up to the
degrees South and then down from the pole for the duration of the
test.

Step 10: Performance Check (South Pole)
Step 11: Maximum Velocity Performance Checks
Note: This procedure step must be performed only for those ADS-B
Transmitting Subsystems that are expected to be installed in vehicles
capable of attaining North/South or East/West velocities in excess of
1022 knots.
Repeat Steps 1 through 10 with the exception that for each case where the
velocity magnitude is specified, set the magnitude to 4,084 knots and the time
of test duration should be retained at 35 seconds.
20xx, RTCA, Inc.

385
2.4.3.2.3.7.2.2 Verification of Non-Coupled Case (Estimation, TIME (T) = 0) (2.2.3.2.3.7.2.2)

correctly extrapolates and encodes Airborne Position data when NOT working with
GNSS synchronized time.
Equipment Required:
Equipment capable of performing the following:
a. Load all valid data required for the ADS-B Airborne Position Message into the ADS-
B Transmitting Subsystem via the operational interfaces.

North/South acceleration. The Latitude Position provided to the ADS-B
Transmission system shall be referred to as the Computed Latitude. Likewise, the
North/South Velocity provided to the ADS-B Transmission system shall be referred
to as the Computed N/S Velocity.

East/West acceleration. The Longitude Position provided to the ADS-B
Transmission system shall be referred to as the Computed Longitude. Likewise, the
East/West Velocity provided to the ADS-B Transmission system shall be referred to
as the Computed E/W Velocity.

information to the ADS-B Transmitting Subsystem at a rate of not less than 5 times
per second for each navigation parameter provided.
b. Generate an appropriate GNSS Time Mark as described in 2.2.5.1.6, but DO NOT

apply the GNSS Time Mark to the ADS-B Transmitting Subsystem.
The equipment shall also be capable of time-tagging the GNSS Time Mark leading
edge event to a minimum accuracy of 1.0 milliseconds.
c. Referenced to the GNSS Time Mark described in subparagraph b, above, the

subparagraph a, above, available at one second intervals that are synchronized with
the leading edge of the GNSS Time Mark. Initial delivery of the all new computed
position and velocity data to the ADS-B Transmission system shall be completed no
later than 200 milliseconds after the leading edge of the GNSS Time Mark.
d. The monitoring of transmitted ADS-B Airborne Position Messages and the Airborne
Velocity Messages and the extraction of all subfields as may be required. The
20xx, RTCA, Inc.

386
equipment shall also be capable of time-tagging the receipt of any ADS-B Broadcast
message to a minimum accuracy of 1.0 milliseconds.
f. After performing the encoded latitude and longitude local unambiguous CPR
decoding, the equipment shall be capable of computing the difference between the
Decoded Latitude Position and the Computed Latitude. Likewise, the equipment
shall be capable of computing the difference between the Decoded Longitude
Position and the Computed Longitude.
g. After extraction of the Velocity subfields from the Airborne Velocity Message, the
equipment shall compute the difference between the extracted North/South Velocity
and the Computed N/S Velocity. Likewise, the equipment shall compute the
difference between the extracted East/West Velocity and the Computed E/W
Velocity.

Subsystem.
Set initial Computed Longitude to 45.0 degrees WEST


and c.
20xx, RTCA, Inc.

387
least 35 seconds.
Notes:
1. Since there has been no position or velocity data provided to the ADS-B
Transmitting Subsystem up to this time (at least for the purposes of this
test procedure), a minimal amount of time will need to be allowed for the
transmitted message data to stabilize. This fact has been factored in to
the following required response criteria.
2. Be advised that this test scenario is forcing movement across the Equator
at 1020 knots from North to South.
Latitude Position by no more than 22.1 meters (i.e., approximately 0.0002
degrees of Latitude).
Latitude Position by no more than 6.375 meters (i.e., approximately
0.000058 degrees of Latitude).

Mark as t1.
Latitude Position at time t1 + 200 milliseconds by no more than 6.375
meters (i.e., approximately 0.000058 degrees of Latitude).
20xx, RTCA, Inc.

388



20xx, RTCA, Inc.

389

North Pole at 1020 knots from South to North. It is up to the
degrees North and then down from the pole for the duration of the
test.

South Pole at 1020 knots from North to South. It is up to the
degrees South and then down from the pole for the duration of the
test.
20xx, RTCA, Inc.

390

1022 knots.
2.4.3.2.3.7.3 Verification of Airborne Latitude Position Extrapolation/Estimation (non -

precision) (2.2.3.2.3.7.3)
2.4.3.2.3.7.3.1 Verification of Airborne Latitude Position Extrapolation Case (non - precision)

(2.2.3.2.3.7.3.1)
The procedures provided in 2.4.3.2.3.7.2.1 shall be used to validate performance of
2.4.3.2.3.7.3.1.
2.4.3.2.3.7.3.2 Verification of Airborne Latitude Position Estimation Case (non - precision)

(2.2.3.2.3.7.3.2)
2.4.3.2.3.7.3.2.
20xx, RTCA, Inc.

391
2.4.3.2.3.7.4 Verification of Airborne Latitude Position Data Retention (2.2.3.2.3.7.4)

The extrapolation or estimation, and update of latitude data fields specified in

2.2.3.2.3.7.2 through 2.2.3.2.3.7.3.2 and shall be limited to no more than two seconds,
in the event that the latitude position data is no longer available.
At the end of two seconds, the latitude data registers and the encoded latitude field shall
be set to ALL ZEROs.
Measurement Procedures:
Step 1: Termination of Latitude Data Input - Part 1
Provide normal Airborne Position data to the ADS-B Transmitting Subsystem

at the nominal rate. First, filter the data so that the ADS-B Transmitting
Subsystem does not receive any latitude data for at least 2 seconds. After 2
seconds, verify that the latitude data registers are set to ALL ZEROs.
Note: In order to terminate latitude data, it may also be necessary to

terminate longitude information since a position fix normally includes
both latitude and longitude.
Return to providing normal Airborne Position data at the nominal rate. Next,
filter the data so that the device does not receive any latitude data. After 1
second, stop providing data. Verify that after 1 second more, the latitude
registers are set to ALL ZEROs.
2.4.3.2.3.8 Verification of Encoded Longitude Subfield in ADS-B Airborne Position

Messages (2.2.3.2.3.6, 2.2.3.2.3.8, 2.2.5.1.8, 2.2.5.1.12)
Appropriate test procedures are provided in 2.4.3.2.3.8.1 through 2.4.3.2.3.8.4.
2.4.3.2.3.8.1 Verification of Airborne Longitude Data Encoding (2.2.3.2.3.8.1, 2.2.5.1.8,

2.2.5.1.12)
Appropriate test procedures to verify the airborne longitude data encoding were
previously provided in 2.4.3.2.3.7.1.
2.4.3.2.3.8.2 Airborne Longitude Position Extrapolation/Estimation (Precision Case, TYPE

Codes 9, 10, 20 and 21)
20xx, RTCA, Inc.

392
1) (2.2.3.2.3.8.2.1)
correctly extrapolates and encodes Airborne Position data when working with GNSS
synchronized time.
Equipment Required:
Equipment requirements remain the same as provided in 2.4.3.2.3.7.2.1.
Step 1: Equipment Initialization (GM-E-W)

Subsystem.
Set initial Computed E/W Velocity to: 1020 knots WEST

East/West velocities. If alternate velocity and direction sources
into the East/West Velocity required in the transmitted messages.

and c.
least 35 seconds.
20xx, RTCA, Inc.

393
Step 3: Longitude Position Performance
Notes:
Transmitting Subsystem up to this time (at least for the purposes of this test
procedure), a minimal amount of time will need to be allowed for the
transmitted message data to stabilize. This fact has been factored in to the
following required response criteria.

Greenwich Meridian at 1020 knots from East to West. It is up to the
equipment properly move across the Greenwich Meridian by moving
across 0 degrees.
Verify that the Decoded Longitude Position differs from the Computed
Longitude Position by no more than 22.1 meters (i.e., approximately
0.0002 degrees of Longitude).

Mark as t1.
Longitude Position at time t1 + 200 milliseconds by no more than 6.375
meters (i.e., approximately 0.000058 degrees of Longitude).
20xx, RTCA, Inc.

394

Verify that the Extracted East/West Velocity differs no more than 5% from
the Computed East/West Velocity that was provided to the ADS-B
Step 5: Equipment Re-Initialization (GM-W-E)
Greenwich Meridian at 1020 knots from West to East.
Set initial Computed E/W Velocity to: 1020 knots EAST

Step 6: Performance Check (West - East)
20xx, RTCA, Inc.

395
Step 7: Equipment Re-Initialization (IDL-E-W)
International Dateline at 1020 knots from East to West.

Step 8: Performance Check (IDL-E-W)
Step 9: Equipment Re-Initialization (IDL-W-E)
Note 1: Be advised that this test scenario is forcing movement across the International
Dateline at 1020 knots from West to East. It is up to the equipment designers
to insure that equipment under test and the test equipment properly move
across the International Dateline by moving up to 180 degrees and then down
for the duration of the test.

20xx, RTCA, Inc.

396
Step 10: Performance Check (IDL-W-E)
1022 knots.
Step 12: Repeat for additional Navigation Data Sources
Repeat Steps 1 through 11 for each Navigation Data Source input interface that
the equipment is designed to accommodate.
2.4.3.2.3.8.2.2 Verification of Non-Coupled Case (Estimation, TIME (T) = 0) (2.2.3.2.3.8.2.2)

correctly extrapolates and encodes Airborne Position data when NOT working with
GNSS synchronized time.
Equipment Required:

Subsystem.
20xx, RTCA, Inc.

397


and c.
least 35 seconds.
Notes:

Greenwich Meridian at 1020 knots from East to West. It is up to the
equipment properly move across the Greenwich Meridian by moving
across 0 degrees.

20xx, RTCA, Inc.

398

Mark as t1.
Longitude Position at time t1 + 200 milliseconds by no more than 6.375
meters (i.e., approximately 0.000058 degrees of Longitude).
Note: This test is intended to demonstrate that UUT is encoding data

correctly in regards to 0.2 UTC Epochs and in regards to
received data, it is reasonable to expect that the capability is

20xx, RTCA, Inc.

399


20xx, RTCA, Inc.

400
International Dateline at 1020 knots from East to West. It is up to
the equipment designers to insure that equipment under test and the
test equipment properly move across the International Dateline by
moving up to 180 degrees and then down for the duration of the test.

1022 knots.
Repeat Steps 1 through 11 for each Navigation Data Source input interface that
the equipment is designed to accommodate.
2.4.3.2.3.8.3 Verification of Airborne Longitude Position Extrapolation/Estimation (non -

precision) (2.2.3.2.3.8.3)
20xx, RTCA, Inc.

401
2.4.3.2.3.8.3.1 Verification of Airborne Longitude Position Extrapolation Case (non - precision)

(2.2.3.2.3.8.3.1)
2.4.3.2.3.8.3.1.
2.4.3.2.3.8.3.2 Verification of Airborne Longitude Position Estimation Case (non - precision)

(2.2.3.2.3.8.3.2)
2.4.3.2.3.8.3.2.
2.4.3.2.3.8.4 Verification of Airborne Longitude Position Data Retention (2.2.3.2.3.8.4)

Step 1: Longitude Data Termination - Part 1
Provide normal Airborne Position data to the ADS-B Transmitting Subsystem

at the nominal rate. First, filter the data so that the ADS-B Transmitting
Subsystem does not receive any longitude data for at least 2 seconds. After 2
seconds, verify that the longitude data registers are set to ALL ZEROs.
Note: In order to terminate longitude data, it may also be necessary to

terminate latitude information since a position fix normally includes
Return to providing normal Airborne Position data at the nominal rate. Next,
filter the data so that the device does not receive any longitude data. After 1
second, stop providing data. Verify that after 1 second more, the longitude
registers are set to ALL ZEROs.
2.4.3.2.4 Verification of ADS-B Surface Position Messages (2.2.3.2.4)

2.4.3.2.4.1 Verification of TYPE Subfield in ADS-B Surface Position Messages (2.2.3.2.4.1)

ADS-B Surface Position Messages with the correct TYPE Code subfield data content in
Message Bits 33 through 37 in DF=17 Messages for Transponder-Based Systems and
DF=18 Messages for Non-Transponder-Based Systems. The ME field of the ADS-B
Surface Position Message contains the TYPE Code subfield in bits 1 through 5, which,
20xx, RTCA, Inc.

402
along with the Navigation Integrity Category (NIC) Supplement in the ADS-B Aircraft
Operational Status Message (2.2.3.2.7.2.6), indicates the navigational integrity of the
position information. The ADS-B Transmitting Subsystem determines and outputs the
TYPE Code subfield based upon the input it receives from the possible Navigational
sources that may interface to the system. The ADS-B Transmitting Subsystem may
receive the TYPE Code subfield directly through an external interface instead of
dynamically determining the TYPE Code subfield. Whatever the implementation, the
test cases must exercise all of the resulting TYPE Code possibilities. If an ADS-B
Transmitting Subsystem can only generate a subset of the possible ADS-B Surface
Position Message TYPE Codes, then only those test cases required to produce the
possible TYPE Codes shall be tested. The test configuration is based on the type(s) of
Navigational System(s) that may interface to the ADS-B Transmitting Subsystem and the
data it provides.
Step 1: Verification of TYPE Codes 5 through 8
Configure the ADS-B Transmitting Subsystem to transmit ADS-B Surface

Position Messages by providing position information at the nominal update
rate. Provide the data externally at the interface to the ADS-B system. Set the
ADS-B Transmitting Subsystem to On-Ground status. Provide appropriate
Ground Speed information to the ADS-B system in order to establish the high
rate of transmission for the ADS-B Surface Position Messages. For each
Navigation Integrity Category (NIC) supported, verify that the TYPE Code
subfield in the ADS-B Surface Position Message correctly matches the TYPE
Code subfield value from the Radius of Containment (RC) depicted in Table 2-
16. Additionally, verify that the NIC Supplement contained in the ADS-B
Aircraft Operational Status Message (2.2.3.2.7.2.6), along with the TYPE
Code, reflects the proper NIC value contained in Table 2-16. The TYPE Code
may be derived by the Horizontal Radius of Containment depicted in Table 2-
16, or the Horizontal Integrity Limit (HIL), or another means which establishes
an appropriate Radius of Containment. To test all of the possible resulting
TYPE Codes that could be produced from the Navigational source, degradation
of the position data from the Navigation source may require an alarm or alert
condition that must be sensed by the ADS-B Transmitting Subsystem. The
TYPE Code subfield shall contain appropriate values in the range from 5
through 8.
Verify that TYPE Codes 5 and 6 cannot be set if the unit under test is not
provided with either a GNSS Time Mark (see 2.2.5.1.6) or UTC data unless
20xx, RTCA, Inc.

403
Step 2: Verification of TYPE Codes if the Radius of Containment is Unavailable
Configure the ADS-B Transmitting Subsystem to the On-Ground status as in

Step 1, and provide navigation data from a source that does not provide a valid
RC value. Horizontal Containment Radius is valid from a navigation source
that provides HPL, HIL, or HPL that can be derived from a RAIM protection
threshold. Verify that in the absence of a valid RC value, the ADS-B
Transmitting Subsystem transmits ADS-B Surface Position Messages with a
TYPE Code subfield set to 8.
2.4.3.2.4.1.1 Verification of Surface Position Message TYPE Code if Containment Radius is

Available (2.2.3.2.4.1.1)
2.4.3.2.4.1.2 Verification of Surface Position Message TYPE Code if Containment Radius is Not
Available (2.2.3.2.4.1.2)
2.4.3.2.4.1.3 Verification of Special Processing for TYPE Code ZERO (2.2.3.2.3.1.3,

2.2.3.2.4.1.3)
2.4.3.2.4.1.3.1 Verification of Significance of TYPE Code Equal to ZERO (2.2.3.2.4.1.3.1)

TYPE Code equal to ZERO is broadcast as a result of loss of ADS-B data updates. The
following test verifies that the ADS-B Transmitting Subsystem correctly outputs TYPE
Code equal to ZERO for each ADS-B Position Message type and correctly terminates the
transmission when required.
Setup the ADS-B Transmitting Subsystem to the On-Ground status. Connect the GNSS
data input, provide valid non-zero Movement and Heading/Ground Track data to the
ADS-B System. If the ADS-B Transmitting Subsystem is capable of receiving
Movement and Heading/Ground Track data from a source other than GNSS, then
provide such data from the other source. Verify that Surface Position and Aircraft
Identification Messages are transmitted at the proper rate.
20xx, RTCA, Inc.

404
Stop update of the Navigational source of Latitude and Longitude position information.
If the ADS-B Transmitting Subsystem is capable of receiving position data from more
than one Navigation source, verify the following by disconnecting each Navigation
source separately. Verify that after 2 seconds, the TYPE code is ZERO and the
remaining ME Bits are ZERO. For Mode S Transponder-Based systems, verify that
the Surface Position Message is no longer transmitted after 60 seconds. For Non-Mode S
Transponder-Based systems, monitor for 120 seconds and verify that TYPE Code of
ZERO is output at the high transmission rate.
2.4.3.2.4.1.3.2 Verification of Broadcast of TYPE Code Equal to ZERO (2.2.3.2.4.1.3.2)

Appropriate test procedures are provided in 2.4.3.2.4.1.3.1.
2.4.3.2.4.1.4 Verification of TYPE Code based on Horizontal Protection Level or Estimated

Horizontal Position Accuracy (2.2.3.2.4.1.4)
This test procedure verifies that if valid horizontal position information is available, then
the TYPE Code in the Surface Position Message is set in the range from 5 to 8. If
the Horizontal Radius of Containment (RC) information is available from the navigation
data source, the TYPE Code is selected according to the RC value, in accordance with
Table 2-16. If RC is not available from the navigation data source, then the TYPE Code
will be set to 8.
Step 1: Verification of TYPE Code Based on RC from the Navigational Data Source
Set the ADS-B Transmitting Subsystem to the On-Ground status and enable
transmission of Surface Position Messages. Provide valid horizontal position
information with an RC value less than 7.5 m. Verify that the TYPE Code
(ME bits 1 through 5) in the next transmitted Surface Position Message is set
to FIVE (binary 0 0101). Repeat this step with RC values of less than 75m, less
than 0.1 NM (182.5m) and greater than or equal to 0.1 NM (182.5m) and verify
that TYPE Codes of 6, 7 and 8 respectively are reflected in each of the
respectively next transmitted Surface Position Messages.
Step 2: Verification of TYPE Code 8 if RC Data is Not Available
Set the ADS-B Transmitting Subsystem to the On-Ground status and enable
transmission of Surface Position Messages. Provide valid horizontal position
information without an RC value. Verify that the TYPE Code (ME bits 1
through 5) in the next transmitted Surface Position Message is set to EIGHT
(binary 0 1000).
20xx, RTCA, Inc.

405
2.4.3.2.4.2 Verification of Movement Subfield in ADS-B Surface Position Messages

(2.2.3.2.4.2)
This test procedure will verify that the ADS-B Transmitting Subsystem correctly outputs
Surface Position Messages with the correct Movement subfield data encoded, in
accordance with the encoding provided in Table 2-18, in DF=17 Messages for
Transponder-Based Systems, and DF=18 Messages for Non-Transponder-Based Systems.
Step 1: Movement Verification - Part 1
Configure the ADS-B Transmitting Subsystem to transmit Surface Position

Provide the data externally at the interface to the ADS-B system. Set up the
system to enable broadcast of Surface Position Messages at the nominal rate.
Set the ADS-B Transmitting Subsystem to On Ground status. Provide valid,
non-zero Movement data to the ADS-B System. Discontinue the
Movement data and verify that when Movement data is not provided to the
ADS-B Transmitting Subsystem, the Movement subfield is set to ZERO
(binary 000 0000).
Set up the ADS-B Transmitting Subsystem as above and set the Movement
input to represent a Movement of greater than or equal to Zero knots, but less
than 0.125 knots. Verify that the Movement subfield is set to ONE (binary
000 0001). Increase the Movement input to exactly 0.125 knots and verify
that the Movement subfield is set to TWO (binary 000 0010). Continue to
increase the Movement input data at increments of 0.125 knots and verify
that for each increment for Ground Speed greater than or equal to 0.125 knots
and less than 1 knot, the encoding of the Movement subfield corresponds to
the encoding identified in Table 2-18 representing values between 2 and 8.
Continue to increase the Movement input in increments equal to those

identified in Table 2-18 for values greater than or equal to ONE knot and less
than 175 knots. Verify that for each such increment, the encoding of the
Movement subfield is equal to that specified in Table 2-18. Increase the
Ground Speed input data to exactly 175 knots and verify that the Movement
subfield is set to 124. Continue increasing the Ground Speed data input for
values greater than 175 knots and verify that the Movement subfield
continues to be set at 124.
Note: The last three encodings (125, 126, 127) of the Movement subfield in
Table 2-18 are reserved to indicate high levels of ground speed change,
etc. The precedence of the codes is not defined yet, as inputs that
would be required are not currently available.
20xx, RTCA, Inc.

406
2.4.3.2.4.3 Verification of Status Bit for Heading/Ground Track Subfield in ADS-B Surface
Position Messages (2.2.3.2.4.3, 2.2.5.1.10)
Surface Position Messages with the correct Status Bit for Heading/Ground Track
subfield data encoded as specified in Table 2-19 in DF=17 Messages for Transponder-
Based Systems and DF=18 Messages for Non-Transponder-Based Systems.
Configure the ADS-B Transmitting Subsystem to transmit Surface Position Messages by

providing position information at the nominal update rate. Provide the data externally at
the interface to the ADS-B system. Set up the system to enable broadcast of Surface
Position Messages at the nominal rate. Set the ADS-B Transmitting Subsystem to On
Ground status. Provide valid, non-zero Heading/Ground Track data to the ADS-B
System. Verify that the Status Bit for Heading/Ground Track is set to ONE (1).
Discontinue the valid Heading data and verify that when non-valid Heading/Ground
Track data is provided to the ADS-B Transmitting Subsystem, that the Status Bit for
Heading/Ground Track subfield is set to ZERO (0).
2.4.3.2.4.4 Verification of Heading/Ground Track Subfield in ADS-B Surface Position

Messages (2.2.3.2.4.4, 2.2.5.1.10)
Surface Position Messages with the correct Heading/Ground Track subfield data
encoded as specified in Table 2-20, in DF=17 Messages for Transponder-Based Systems
and DF=18 Messages for Non-Transponder-Based Systems.
Step 1: Heading Verification - Part 1

Provide the data externally at the interface to the ADS-B system. Set up the
system to enable broadcast of Surface Position Messages at the nominal rate.
Set the ADS-B Transmitting Subsystem to On Ground status. Provide valid,
non-zero Heading data to the ADS-B System. Verify that the Heading
subfield is NOT set to ZERO (0). Set the Heading input to exactly ZERO
degrees and verify that the encoding of the Heading subfield is set to ZERO
(binary 000 0000).
20xx, RTCA, Inc.

407
Step 2: Heading Verification - Part 2
Raw data used to establish the Heading subfield will normally have more
resolution (i.e., more bits) than that required by the Heading subfield. When
converting such data to the Heading subfield, the accuracy of the data shall
be maintained such that it is not worse than LSB where the LSB is that of
the Heading subfield.
Set up the ADS-B Transmitting Subsystem as above and set the Heading data
input to 2.8125 degrees. Verify that the Heading subfield is set to ONE
(binary 000 0001). Continue increasing the Heading data input in increments
of 2.8125 degrees and verify that for each such increment, the encoding of the
Heading subfield is set to the corresponding binary code shown in Table 2-
20.
2.4.3.2.4.5 Verification of TIME (T) Subfield in ADS-B Surface Position Messages

(2.2.3.2.4.5, 2.2.5.1.6)
If the ADS-B Transmitting Subsystem is capable of synchronizing to a 0.2 second UTC

epoch, configure the ADS-B Transmitting Subsystem to transmit Surface Position
Messages by providing position information at the nominal rate. Ensure that the time of
applicability of the position data is synchronized to an exact 0.2 second UTC epoch.
Verify that the ADS-B Transmitting Subsystem accepts a GNSS TIME MARK, or
equivalent, input from the navigation data source, which is required in order to be able to
update the position data from the navigation data source to an exact 0.2 second UTC
epoch. Verify that the TIME (T) subfield is set to ONE (1).
If the ADS-B Transmitting Subsystem is not capable of synchronizing to a 0.2 second

UTC epoch, or if the input is not available, verify that the TIME (T) subfield is set to
ZERO (0).
Note: The ADS-B Transmitting Subsystem must be capable of monitoring the GNSS
Time Mark unless the non-coupled case (see 2.2.3.2.3.7.2.2) is implemented.
2.4.3.2.4.6 Verification of CPR Format (F) Subfield in ADS-B Surface Position Messages
(2.2.3.2.4.6)
Appropriate procedures to validate 2.2.3.2.4.6 are provided in 2.4.3.2.4.7.1 and
2.4.3.2.4.8.1.
2.4.3.2.4.7 Verification of Encoded Latitude Subfield in ADS-B Surface Position Messages

(2.2.3.2.4.6, 2.2.3.2.4.7, 2.2.5.1.7, 2.2.5.1.13, Appendix A.1.7)
20xx, RTCA, Inc.

408
2.4.3.2.4.7.1 Verification of Latitude Transition Points and Encoding (2.2.3.2.4.6, 2.2.3.2.4.7,

2.2.3.2.4.7.1, 2.2.5.1.7, 2.2.5.1.13, Appendix A.1.7)
2.4.3.2.4.7.1.1 Verification of Latitude Transition Points (2.2.3.2.4.6, 2.2.3.2.4.7, 2.2.3.2.4.7.1,

2.2.5.1.7, 2.2.5.1.13, Appendix A.1.7)
This test procedure verifies that the latitude transition points used in CPR encoding are
properly computed or established to satisfy the equations provided in Appendix A,
A.1.7.2.d.
Step 1: Encode Lower Values
a. Set the input longitude value to 45.00 degrees East and keep it at that value
for the duration of this test procedure.
b. For each line item in Table 2-130, set the input latitude value to the value
provided in the latlow column provided in the table.
c. Verify that the Even Surface Position latitude encoding agrees with the
value provided in the lower latitude column of the table.
If the latitude encoding does not agree with the table value, proceed to
subparagraph d.
Otherwise, verify that the Even Surface Position longitude encoding agrees
with the value provided in the lower longitude column of the table.
If the Even Surface Position latitude and longitude encoding values agree
with the values provided in the lower latitude and lower longitude
columns of the table, then this portion of the test shall be considered as
PASSED and testing shall proceed with Step 2 below.
d. Increase or decrease, as appropriate, the input latitude value until the

Surface Position latitude encoding agrees with the value provided in the
lower latitude column of the table.
Verify that the difference between the input latitude value and the latlow
value provided in the table does not exceed 2-19 * 10 degrees.
Verify that the Even Surface Position longitude encoding agrees with the
value provided in the lower longitude column of the table.
with the values provided in the lower latitude and lower longitude
PASSED and testing shall proceed with Step 2 below.
20xx, RTCA, Inc.

409
Step 2: Encode Upper Values
a. Set the input longitude value to 45.00 degrees East and keep it at that value
for the duration of this test procedure.
b. For each line item in Table 2-130, set the input latitude value to the value
provided in the latup column provided in the table.
c. Verify that the Even Surface Position latitude encoding agrees with the
value provided in the upper latitude column of the table.
If the latitude encoding does not agree with the table value, proceed to
subparagraph d.
Otherwise, verify that the Even Surface Position longitude encoding agrees
with the value provided in the upper longitude column of the table.
with the values provided in the upper latitude and upper longitude
PASSED.
d. Increase or decrease, as appropriate, the input latitude value until the

Surface Position latitude encoding agrees with the value provided in the
upper latitude column of the table.
Verify that the difference between the input latitude value and the latup
value provided in the table does not exceed 2-19 * 10 degrees.
Verify that the Even Surface Position longitude encoding agrees with the
value provided in the upper longitude column of the table.
with the values provided in the upper latitude and upper longitude
PASSED.
20xx, RTCA, Inc.

410
Table 2-130: Verification of Transition Table

Latitude in degrees (rounded to nearest AWB value) Even Surface Position Encodings
latlow latlow latup latup lower upper

Decimal HEX Decimal HEX latitude longitude latitude longitude
10.470463 077216EF 10.470474 07721777 1F5EB 10000 1F5EC 00000
14.828167 0A8B62AB 14.828178 0A8B6333 1C559 00000 1C55A 10000
18.186253 0CEEB4CD 18.186264 0CEEB555 03F93 10000 03F94 00000
21.029388 0EF44889 21.029400 0EF44911 00A08 00000 00A09 10000
23.545040 10BE3E66 23.545052 10BE3EEF 164B5 10000 164B6 00000
25.829247 125E1222 25.829258 125E12AB 07062 00000 07063 10000
27.938976 13DE22AB 27.938988 13DE2333 14081 10000 14082 00000
29.911354 15453222 29.911366 154532AB 1E1BE 00000 1E1BF 10000
31.772095 1697EEEF 31.772106 1697EF77 05CE0 10000 05CE1 00000
33.539932 17D9C222 33.539944 17D9C2AB 0B84C 00000 0B84D 10000
35.228989 190D3DDE 35.229000 190D3E66 0F8D4 10000 0F8D5 00000
36.850250 1A346222 36.850262 1A3462AB 12238 00000 12239 10000
38.412415 1B50C444 38.412426 1B50C4CD 13770 10000 13771 00000
39.922565 1C63AE66 39.922577 1C63AEEF 13AE7 00000 13AE8 10000
41.386517 1D6E2F77 41.386528 1D6E3000 12E99 10000 12E9A 00000
42.809132 1E712A22 42.809143 1E712AAB 1142F 00000 11430 10000
44.194542 1F6D5EEF 44.194553 1F6D5F77 0ED12 10000 0ED13 00000
45.546261 2063719A 45.546272 20637222 0BA75 00000 0BA76 10000
46.867332 2153F000 46.867344 2153F089 07D62 10000 07D63 00000
48.160389 223F54CD 48.160400 223F5555 036BF 00000 036C0 10000
49.427753 23260C44 49.427765 23260CCD 1E757 10000 1E758 00000
50.671497 240876EF 50.671509 24087777 18FDF 00000 18FE0 10000
51.893417 24E6E889 51.893429 24E6E911 130F4 10000 130F5 00000
53.095161 25C1ADDE 53.095173 25C1AE66 0CB26 00000 0CB27 10000
54.278172 26990A22 54.278183 26990AAB 05EF3 10000 05EF4 00000
55.443775 276D3B33 55.443787 276D3BBC 1ECCF 00000 1ECD0 10000
56.593185 283E799A 56.593197 283E7A22 17524 10000 17525 00000
57.727467 290CF6EF 57.727478 290CF777 0F84F 00000 0F850 10000
58.847637 29D8E2AB 58.847649 29D8E333 076A9 10000 076AA 00000
59.954590 2AA26666 59.954601 2AA266EF 1F080 00000 1F081 10000
61.049171 2B69A99A 61.049183 2B69AA22 1661E 10000 1661F 00000
62.132160 2C2ED089 62.132172 2C2ED111 0D7C7 00000 0D7C8 10000
63.204266 2CF1FC44 63.204277 2CF1FCCD 045B9 10000 045BA 00000
64.266163 2DB34C44 64.266174 2DB34CCD 1B02F 00000 1B030 10000
65.318447 2E72DC44 65.318459 2E72DCCD 1175D 10000 1175E 00000
66.361702 2F30C777 66.361713 2F30C800 07B76 00000 07B77 10000
67.396465 2FED26EF 67.396477 2FED2777 1DCA9 10000 1DCAA 00000
68.423218 30A81111 68.423229 30A8119A 13B20 00000 13B21 10000
69.442417 31619B33 69.442429 31619BBC 09703 10000 09704 00000
70.454510 3219DA22 70.454521 3219DAAB 1F079 00000 1F07A 10000
71.459862 32D0DEEF 71.459873 32D0DF77 147A2 10000 147A3 00000
72.458839 3386BAAB 72.458851 3386BB33 09C9E 00000 09C9F 10000
73.451763 343B7C44 73.451775 343B7CCD 1EF89 10000 1EF8A 00000
74.438931 34EF319A 74.438942 34EF3222 1407D 00000 1407E 10000
75.420559 35A1E4CD 75.420570 35A1E555 08F8D 10000 08F8E 00000
76.396843 36539EEF 76.396854 36539F77 1DCCA 00000 1DCCB 10000
77.367886 370464CD 77.367897 37046555 1283D 10000 1283E 00000
78.333733 37B43889 78.333744 37B43911 071EA 00000 071EB 10000
79.294281 38631555 79.294292 386315DE 1B9C8 10000 1B9C9 00000
80.249222 3910ECCD 80.249233 3910ED55 0FFBC 00000 0FFBD 10000
81.198006 39BDA555 81.198017 39BDA5DE 04396 10000 04397 00000
82.139568 3A690D55 82.139580 3A690DDE 184F9 00000 184FA 10000
83.071987 3B12CB33 83.071999 3B12CBBC 0C33D 10000 0C33E 00000
83.991726 3BBA3A22 83.991737 3BBA3AAB 1FD2D 00000 1FD2E 10000
84.891655 3C5E0DDE 84.891666 3C5E0E66 1305A 10000 1305B 00000
85.755409 3CFB4BBC 85.755421 3CFB4C44 0572E 00000 0572F 10000
86.535370 3D894889 86.535381 3D894911 16168 10000 16169 00000
86.999999 3DDDDDDD 87.000011 3DDDDE66 00000 00000 00001 10000
20xx, RTCA, Inc.

411
Note to Table 2-130:
An entry from Table 2-130 consists of a pair of latitudes, which, in the process of
encoding with maximum precision, will produce values that straddle the transition
latitudes as closely as possible. In addition, each entry contains 2 pairs of even surface
encodings for the positions at each latitude in the entry and 45 degrees longitude. Both
the latitudes and the encodings are distinguished by "upper" and "lower" where the
upper position is the one closer to the North Pole.
2.4.3.2.4.7.1.2 Verification of Surface Latitude and Longitude Data Encoding (2.2.3.2.4.6,

2.2.3.2.4.7, 2.2.3.2.4.7.1, 2.2.3.2.4.8, 2.2.3.2.4.8.1, 2.2.5.1.7, 2.2.5.1.8,
2.2.5.1.12, 2.2.5.1.13, Appendix A.1.7)
The Encoded Latitude subfield is a 17-bit field (ME Bits 23 through 39, Message Bits
55 through 71) containing the encoded latitude of the surface position. The following
test procedure verifies that the ADS-B Transmitting Subsystem correctly receives
Latitude position data from the Navigation source and outputs encoded Latitude data in
the Surface Position Message. The Latitude data is encoded according to the Compact
Position Reporting (CPR) Format described in Appendix A. The Latitude data is
dependent upon the positional accuracy supported by the ADS-B Transmitting
Subsystem.
The following procedure verifies the static latitude encoding where the velocity input is
0.0 knots and is intended to verify the actual CPR Latitude encoding precision.
a. Configure the ADS-B Transmitting Subsystem to create a Surface Position

Message, i.e., TYPE Codes 5 through 8.
b. Ensure that the Velocity input provided to the ADS-B Transmitting

Subsystem is set to ZERO.
Step 2: Verify Encoded Latitude Data
a. Via the appropriate Navigation Data Source interface, provide the ADS-B
Transmitting Subsystem with the exact latitude and longitude data pair
provided in the Angular Weighted Binary Values Latitude and Longitude
Columns for each line item given in Table 2-131.
Provide the latitude and longitude data via the interface at the nominal rate
of the navigation data source.
Allow the system to stabilize for at least 2 seconds after the data change
prior to continuing with the following steps.
20xx, RTCA, Inc.

412
Table 2-131: Surface Position Encoding Values

Even Surface Odd Surface
Angular Weighted Binary Values (degrees)
Encoding Encoding
-90.000000 C0000000 -180.000000 80000000 00000 00000 00000 00000
-89.950000 C0091A2B 179.500000 7FA4FA50 01111 1FD28 010C8 1FD28
-89.500000 C05B05B0 178.500000 7EEEEEEF 0AAAB 1F777 0A7D2 1F777
-89.000000 C0B60B61 175.500000 7CCCCCCD 15555 1E666 14FA5 1E666
-87.500000 C1C71C72 -165.000000 8AAAAAAB 15555 05555 1471C 05555
-86.750000 C24FA4FA -171.500000 860B60B6 05555 060B6 042D8 0305B
-86.500000 C27D27D2 -172.500000 85555555 0AAAB 08000 096C1 05555
-85.850000 C2F37C05 65.750000 2EC16C17 18889 06222 170ED 0EC17
-85.000000 C38E38E4 -142.750000 9A7D27D2 0AAAB 14FA5 08E39 07BBC
-84.250000 C416C16C 60.000000 2AAAAAAB 1AAAB 0AAAB 189F5 15555
-83.550000 C4962FC9 -60.000000 D5555555 0999A 00000 074E8 15555
-82.680000 C53490BA 120.000000 55555555 1C28F 0AAAB 198EB 00000
-81.750000 C5DDDDDE -120.000000 AAAAAAAB 10000 0AAAB 0D111 15555
-80.250000 C6EEEEEF 144.000000 66666666 10000 0CCCD 0C889 1999A
-79.750000 C749F49F -144.000000 9999999A 1AAAB 00000 1705B 13333
-78.400000 C83FB72F -121.000000 A9F49F4A 17777 06C17 1357A 11C72
-77.400000 C8F5C28F 121.000000 560B60B6 0CCCD 04444 0851F 193E9
-76.550000 C9907F6E -154.280000 924A2EE0 1EEEF 16E23 1A26B 0DBD2
-75.600000 CA3D70A4 154.280000 6DB5D120 13333 1FF8B 0E148 091DD
-74.750000 CAD82D83 157.500000 70000000 05555 08000 1FE94 10000
-73.650000 CBA06D3A -157.500000 90000000 1CCCD 00000 16FC9 18000
-72.750000 CC444444 -120.000000 AAAAAAAB 10000 0AAAB 09DDE 15555
-71.550000 CD1EB852 120.000000 55555555 0999A 00000 030A4 15555
-70.650000 CDC28F5C -144.000000 9999999A 1CCCD 13333 15EB8 06666
-69.550000 CE8ACF13 144.000000 66666666 14444 00000 0CFEE 0CCCD
-68.750000 CF1C71C7 -114.550000 AE8ACF13 05555 08B18 1DC72 116C1
-67.750000 CFD27D28 114.550000 517530ED 1AAAB 00092 12C17 174E8
-66.550000 D0ACF135 -67.500000 D0000000 14444 18000 0BEDD 10000
-65.550000 D162FC96 67.500000 30000000 0999A 00000 00E82 08000
-64.450000 D22B3C4D -83.080000 C4EBBF60 01111 1D82E 17FB7 1B0D0
-63.250000 D305B05B 83.080000 3B1440A0 1AAAB 00075 1127D 027D2
-62.250000 D3BBBBBC -64.290000 D2485CD8 10000 16D0E 06222 0DACB
-61.250000 D471C71C 64.290000 2DB7A328 05555 000AF 1B1C7 092F2
-60.250000 D527D27D -72.000000 CCCCCCCD 1AAAB 1999A 1016C 13333
-59.960000 D55C9D78 -120.500000 AA4FA4FA 00DA7 0582E 162C2 105B0
-59.955000 D55D867C 120.000000 55555555 00F5C 15555 16470 0AAAB
-59.930000 D5621392 -119.500000 AB05B05B 017E5 05555 16CD4 0FD28
-58.000000 D6C16C17 -78.750000 C8000000 0AAAB 1C000 1F49F 18000
-58.500000 D6666666 78.750000 38000000 00000 04000 14CCD 08000
20xx, RTCA, Inc.

413
Table 2-131: Surface Position Encoding Values (continued)

Encoding Encoding
-57.950000 D6CA8642 -22.500000 F0000000 0BBBC 08000 00568 10000
-56.850000 D792C5F9 22.500000 10000000 03333 00000 1769D 18000
-55.500000 D8888889 -52.940000 DA5A912E 00000 12D66 13BBC 05A91
-54.620000 D928BB81 52.940000 25A56ED2 12C60 1FFC6 0631A 0D29A
-53.250000 DA222222 -30.000000 EAAAAAAB 10000 0AAAB 02EEF 15555
-51.950000 DB0ECA86 30.000000 15555555 0BBBC 00000 1E345 15555
-50.750000 DBE93E94 -75.790000 CA1ADA00 05555 1AF0C 1760B 15E35
-49.650000 DCB17E4B 75.790000 35E52600 1CCCD 0001D 0E741 050F4
-48.250000 DDB05B06 -27.000000 ECCCCCCD 1AAAB 0999A 0BD28 13333
-47.000000 DE93E93F 27.000000 13333333 15555 00000 060B6 16666
-45.600000 DF92C5F9 -68.570000 CF3D3663 13333 1866E 0369D 10C84
-44.250000 E0888889 -180.000000 80000000 10000 00000 1FBBC 00000
-42.850000 E1876543 179.500000 7FA4FA50 0DDDE 185B0 1D1A3 18889
-41.400000 E28F5C29 178.500000 7EEEEEEF 0CCCD 08889 1B852 09111
-40.000000 E38E38E4 175.500000 7CCCCCCD 0AAAB 18000 18E39 1999A
-38.500000 E49F49F5 -160.900000 8D950C84 0AAAB 18642 185B0 1199A
-36.900000 E5C28F5C -171.500000 860B60B6 0CCCD 0E0B6 19EB8 0B05B
-35.250000 E6EEEEEF -172.500000 85555555 10000 00000 1C889 1D555
-33.600000 E81B4E82 65.750000 2EC16C17 13333 1982E 1F259 02222
-31.800000 E962FC96 -142.750000 9A7D27D2 1999A 1638E 04E82 08FA5
-30.000000 EAAAAAAB 59.500000 2A4FA4FA 00000 16EEF 0AAAB 01C72
-28.000000 EC16C16C -60.000000 D5555555 0AAAB 0AAAB 149F5 00000
-25.900000 ED950C84 -66.700000 D091A2B4 17777 17135 00ACF 0ECA8
-23.600000 EF37C049 -120.000000 AAAAAAAB 08889 00000 10ECB 0AAAB
-21.100000 F0FEDCBB 41.500000 1D82D82E 1DDDE 0B8E4 055E7 1CCCD
-18.200000 F30ECA86 -144.000000 9999999A 1BBBC 0CCCD 02345 00000
-14.900000 F56789AC -121.000000 A9F49F4A 02222 0BBBC 076E6 16C17
-10.500000 F8888889 121.000000 560B60B6 00000 1F49F 03BBC 14444
-5.100000 FC5F92C6 6.250000 0471C71C 13333 031C7 15037 00E39
-2.500000 FE38E38E 154.280000 6DB5D120 0AAAB 0473A 0B8E4 0D98B
0.000000 00000000 60.000000 2AAAAAAB 00000 0AAAB 00000 15555
0.000000 00000000 -157.500000 90000000 00000 18000 00000 10000
90.000000 40000000 -180.000000 80000000 00000 00000 00000 00000
89.950000 3FF6E5D5 179.500000 7FA4FA50 1EEEF 1FD28 1EF38 1FD28
89.500000 3FA4FA50 178.500000 7EEEEEEF 15555 1F777 1582E 1F777
89.000000 3F49F49F 175.500000 7CCCCCCD 0AAAB 1E666 0B05B 1E666
87.500000 3E38E38E -165.000000 8AAAAAAB 0AAAB 05555 0B8E4 05555
86.750000 3DB05B06 -171.500000 860B60B6 1AAAB 060B6 1BD28 0305B
86.500000 3D82D82E -172.500000 85555555 15555 08000 1693F 05555
85.850000 3D0C83FB 65.750000 2EC16C17 07777 06222 08F13 0EC17
85.000000 3C71C71C -142.750000 9A7D27D2 15555 14FA5 171C7 07BBC
20xx, RTCA, Inc.

414

Encoding Encoding
84.250000 3BE93E94 60.000000 2AAAAAAB 05555 0AAAB 0760B 15555
83.550000 3B69D037 -60.000000 D5555555 16666 00000 18B18 15555
82.680000 3ACB6F46 120.000000 55555555 03D71 0AAAB 06715 00000
81.750000 3A222222 -120.000000 AAAAAAAB 10000 0AAAB 12EEF 15555
80.250000 39111111 144.000000 66666666 10000 0CCCD 13777 1999A
79.750000 38B60B61 -144.000000 9999999A 05555 00000 08FA5 13333
78.400000 37C048D1 -121.000000 A9F49F4A 08889 06C17 0CA86 11C72
77.400000 370A3D71 121.000000 560B60B6 13333 04444 17AE1 193E9
76.550000 366F8092 -154.280000 924A2EE0 01111 16E23 05D95 0DBD2
75.600000 35C28F5C 154.280000 6DB5D120 0CCCD 1FF8B 11EB8 091DD
74.750000 3527D27D 157.500000 70000000 1AAAB 08000 0016C 10000
73.650000 345F92C6 -157.500000 90000000 03333 00000 09037 18000
72.750000 33BBBBBC -120.000000 AAAAAAAB 10000 0AAAB 16222 15555
71.550000 32E147AE 120.000000 55555555 16666 00000 1CF5C 15555
70.650000 323D70A4 -144.000000 9999999A 03333 13333 0A148 06666
69.550000 317530ED 144.000000 66666666 0BBBC 00000 13012 0CCCD
68.750000 30E38E39 -114.550000 AE8ACF13 1AAAB 08B18 0238E 116C1
67.750000 302D82D8 114.550000 517530ED 05555 00092 0D3E9 174E8
66.550000 2F530ECB -67.500000 D0000000 0BBBC 18000 14123 10000
65.550000 2E9D036A 67.500000 30000000 16666 00000 1F17E 08000
64.450000 2DD4C3B3 -83.080000 C4EBBF60 1EEEF 1D82E 08049 1B0D0
63.250000 2CFA4FA5 83.080000 3B1440A0 05555 00075 0ED83 027D2
62.250000 2C444444 -64.290000 D2485CD8 10000 16D0E 19DDE 0DACB
61.250000 2B8E38E4 64.290000 2DB7A328 1AAAB 000AF 04E39 092F2
60.250000 2AD82D83 -72.000000 CCCCCCCD 05555 1999A 0FE94 13333
59.960000 2AA36288 -120.500000 AA4FA4FA 1F259 0582E 09D3E 105B0
59.955000 2AA27984 120.000000 55555555 1F0A4 15555 09B90 0AAAB
59.930000 2A9DEC6E -119.500000 AB05B05B 1E81B 05555 0932C 0FD28
58.000000 293E93E9 -78.750000 C8000000 15555 1C000 00B61 18000
58.500000 2999999A 78.750000 38000000 00000 04000 0B333 08000
57.950000 293579BE -22.500000 F0000000 14444 08000 1FA98 10000
56.850000 286D3A07 22.500000 10000000 1CCCD 00000 08963 18000
55.500000 27777777 -52.940000 DA5A912E 00000 12D66 0C444 05A91
54.620000 26D7447F 52.940000 25A56ED2 0D3A0 1FFC6 19CE6 0D29A
53.250000 25DDDDDE -30.000000 EAAAAAAB 10000 0AAAB 1D111 15555
51.950000 24F1357A 30.000000 15555555 14444 00000 01CBB 15555
50.750000 2416C16C -75.790000 CA1ADA00 1AAAB 1AF0C 089F5 15E35
49.650000 234E81B5 75.790000 35E52600 03333 0001D 118BF 050F4
48.250000 224FA4FA -27.000000 ECCCCCCD 05555 0999A 142D8 13333
47.000000 216C16C1 27.000000 13333333 0AAAB 00000 19F4A 16666
45.600000 206D3A07 -68.570000 CF3D3663 0CCCD 1866E 1C963 10C84
20xx, RTCA, Inc.

415

Encoding Encoding
44.250000 1F777777 -180.000000 80000000 10000 00000 00444 00000
42.850000 1E789ABD 179.500000 7FA4FA50 12222 185B0 02E5D 18889
41.400000 1D70A3D7 178.500000 7EEEEEEF 13333 08889 047AE 09111
40.000000 1C71C71C 175.500000 7CCCCCCD 15555 18000 071C7 1999A
38.500000 1B60B60B -160.900000 8D950C84 15555 18642 07A50 1199A
36.900000 1A3D70A4 -171.500000 860B60B6 13333 0E0B6 06148 0B05B
35.250000 19111111 -172.500000 85555555 10000 00000 03777 1D555
33.600000 17E4B17E 65.750000 2EC16C17 0CCCD 1982E 00DA7 02222
31.800000 169D036A -142.750000 9A7D27D2 06666 1638E 1B17E 08FA5
30.000000 15555555 59.500000 2A4FA4FA 00000 16EEF 15555 01C72
28.000000 13E93E94 -60.000000 D5555555 15555 0AAAB 0B60B 00000
25.900000 126AF37C -66.700000 D091A2B4 08889 17135 1F531 0ECA8
23.600000 10C83FB7 -120.000000 AAAAAAAB 17777 00000 0F135 0AAAB
21.100000 0F012345 41.500000 1D82D82E 02222 0B8E4 1AA19 1CCCD
18.200000 0CF1357A -144.000000 9999999A 04444 0CCCD 1DCBB 00000
14.900000 0A987654 -121.000000 A9F49F4A 1DDDE 0BBBC 1891A 16C17
10.500000 07777777 121.000000 560B60B6 00000 1F49F 1C444 14444
5.100000 03A06D3A 6.250000 0471C71C 0CCCD 031C7 0AFC9 00E39
2.500000 01C71C72 154.280000 6DB5D120 15555 0473A 1471C 0D98B
0.000000 00000000 60.000000 2AAAAAAB 00000 0AAAB 00000 15555
0.000000 00000000 -157.500000 90000000 00000 18000 00000 10000
b. For each Even interval Surface Position Message that is broadcast by the
(1). Verify that the CPR Format (F) subfield is set to ZERO (0), and
(2). Verify that the Encoded Even Interval Latitude subfield is encoded
exactly as shown in the Even Surface Encoding Latitude column of Table
2-131.
If the encoding is not exact, verify that the encoding does not differ from
the table value by more than 1 Least Significant Bit (LSB).
then the test shall be considered to have Failed. Otherwise, the test shall
be considered to have passed.
(3). Verify that the Encoded Even Interval Longitude subfield is encoded
exactly as shown in the Even Surface Encoding Longitude column of
Table 2-131.
the table value by more that 1 Least Significant Bit (LSB).
20xx, RTCA, Inc.

416
c. For each Odd interval Surface Position Message that is broadcast by the ADS-
B Transmitting Subsystem:
(1). Verify that the CPR Format (F) subfield is set to ONE (1), and
(2). Verify that the Encoded Odd Interval Latitude subfield is encoded exactly
as shown in the Odd Surface Encoding Latitude column of Table 2-131.
(3). Verify that the Encoded Odd Interval Longitude subfield is encoded
exactly as shown in the Odd Surface Encoding Longitude column of
Table 2-131.
2.4.3.2.4.7.2 Verification of Surface Latitude Position Extrapolation/Estimation (Precision Case,

TYPE Codes 5 and 6) (2.2.3.2.4.7.2)
1) (2.2.3.2.4.7.2.1, 2.2.5.1.6, 2.2.5.1.7, 2.2.5.1.13)
This test procedure will be used to verify that the ADS-B Transmitting Subsystem correctly
extrapolates and encodes Surface Position data when working with GNSS synchronized
time.
Equipment Required:
Provide equipment capable of performing the following:
a. Load all valid data required for the ADS-B Surface Position Message into the ADS-B
Transmitting Subsystem via the operational interfaces.

20xx, RTCA, Inc.

417
North/South acceleration. The Latitude Position provided to the ADS-B Transmission

system shall be referred to as the Computed Latitude. Likewise, the North/South
Velocity provided to the ADS-B Transmission system shall be referred to as the
Computed N/S Velocity.

East/West acceleration. The Longitude Position provided to the ADS-B Transmission
system shall be referred to as the Computed Longitude. Likewise, the East/West
Computed E/W Velocity.

information to the ADS-B Transmitting Subsystem at a rate of not less than 5 times per
second for each navigation parameter provided.
b. Provide the ADS-B Transmitting Subsystem with an appropriate GNSS Time Mark as
described in 2.2.5.1.6.
The equipment shall also be capable of time-tagging the GNSS Time Mark leading edge
event to a minimum accuracy of 1.0 milliseconds.
c. When providing the GNSS Time Mark described in subparagraph b, above, the
subparagraph a, above, available at one second intervals that are synchronized with the
leading edge of the GNSS Time Mark. Initial delivery of the all new computed position
and velocity data to the ADS-B Transmission system shall be completed no later than
200 milliseconds after the leading edge of the GNSS Time Mark.
d. Monitoring the transmitted ADS-B Surface Position Messages and the Airborne
Velocity Messages and extracting all subfields as may be required. The equipment
shall also be capable of time-tagging the receipt of any ADS-B Broadcast message to a
minimum accuracy of 1.0 milliseconds.
f. After performing the encoded latitude and longitude local unambiguous CPR decoding,
the equipment shall be capable of computing the difference between the Decoded
Latitude Position and the Computed Latitude. Likewise, the equipment shall be capable
of computing the difference between the Decoded Longitude Position and the
Computed Longitude.

Subsystem.
20xx, RTCA, Inc.

418
Note: The velocity requirements above are specified in terms of North/South

velocities. If alternate velocity and direction sources are used, i.e.,
ground speed and ground track, then it is up to the implementer to
verify that such information is properly resolved into the North/South
Velocity required in the transmitted messages.
b. GNSS Time Mark as described above under Equipment subparagraphs b and

c.
c. All other data required to generate the Surface Position Message.
Allow the equipment to start delivery of the data specified in Step 1 and designate
this time as t0. Continue to let the equipment provide the data for at least 35
seconds.
Notes:
2. Be advised that this test scenario is forcing movement across the Equator at
1020 knots from North to South.
Verify that the Decoded Latitude Position differs from the Computed Latitude
Position by no more than 22.1 meters (i.e., approximately 0.0002 degrees
Latitude).
20xx, RTCA, Inc.

419
Latitude).
c. Select a Surface Position Message that was received at least 6 seconds after
the execution of Step 2 and within 50 25 milliseconds of a GNSS Time Mark
generated by the Test Equipment and provided to the ADS-B Transmitting
Subsystem. Designate the leading edge of the GNSS Time Mark as t1.
Position at time t1 + 200 milliseconds by no more than 3.0 meters (i.e.,
0.000027 degrees Latitude).
d. Verify that the received message was encoded in the proper format, i.e., odd
or even encoding, by correlating the received message to the stimulus data
provided by the test equipment.
received data, it is reasonable to expect that this capacity is adequate
to establish the proper 0.2 UTC Epochs and the appropriate format
encoding

20xx, RTCA, Inc.

420
Note 1: Be advised that this test scenario is forcing movement across the North
Pole at 1020 knots from South to North. It is up to the equipment
designers to insure that equipment under test and the test equipment
properly move across the pole by moving up to 90.0 degrees North and
then down from the pole for the duration of the test.

Note 1: Be advised that this test scenario is forcing movement across the South
Pole at 1020 knots from North to South. It is up to the equipment
properly move across the pole by moving up to 90.0 degrees South and

20xx, RTCA, Inc.

421
Repeat Steps 1 through 9 for each Navigation Data Source input interface that the
equipment is designed to accommodate.
2.4.3.2.4.7.2.2 Verification of Non-Coupled Case (Estimation, TIME (T) = 0) (2.2.3.2.4.7.2.2,

2.2.5.1.7, 2.2.5.1.13)
extrapolates and encodes Surface Position data when NOT working with GNSS
synchronized time.
Equipment Required:
Provide equipment capable of performing the following:
a. Load all valid data required for the ADS-B Surface Position Message into the ADS-B
Transmitting Subsystem via the operational interfaces.

North/South acceleration. The Latitude Position provided to the ADS-B Transmission
system shall be referred to as the Computed Latitude. Likewise, the North/South
Computed N/S Velocity.

East/West acceleration. The Longitude Position provided to the ADS-B Transmission
system shall be referred to as the Computed Longitude. Likewise, the East/West
Computed E/W Velocity.

information to the ADS-B Transmitting Subsystem at a rate of not less than 5 times per
second for each navigation parameter provided.
b. Generate an appropriate GNSS Time Mark as described in 2.2.5.1.6 but DO NOT

apply the GNSS Time Mark to the ADS-B Transmitting Subsystem.
The equipment shall also be capable of time-tagging the GNSS Time Mark leading edge
event to a minimum accuracy of 1.0 milliseconds.
20xx, RTCA, Inc.

422
c. Referenced to the GNSS Time Mark described in subparagraph b, above, the equipment
shall have re-computed position and velocity information required by subparagraph a,
above, available at one second intervals that are synchronized with the leading edge of
the GNSS Time Mark. Initial delivery of the all new computed position and velocity
data to the ADS-B Transmission system shall be completed no later than 200
milliseconds after the leading edge of the GNSS Time Mark.
d. Monitoring the transmitted ADS-B Surface Position Messages and the Airborne
Velocity Messages and extracting all subfields as may be required. The equipment
shall also be capable of time-tagging the receipt of any ADS-B Broadcast message to a
minimum accuracy of 1.0 milliseconds.
f. After performing the encoded latitude and longitude local unambiguous CPR decoding,
the equipment shall be capable of computing the difference between the Decoded
Latitude Position and the Computed Latitude. Likewise, the equipment shall be capable
of computing the difference between the Decoded Longitude Position and the
Computed Longitude.

Subsystem.
Note: The velocity requirements above are specified in terms of North/South

verify that such information is properly resolved into the North/South

c.
20xx, RTCA, Inc.

423
seconds.
Notes:
2. Be advised that this test scenario is forcing movement across the Equator at
1020 knots from North to South.
Latitude).
Latitude).
c. Select a Surface Position Message that was received within 150 25

milliseconds of a GNSS Time Mark generated by the Test Equipment and
provided to the ADS-B Transmitting Subsystem. Designate the leading edge
of the GNSS Time Mark as t1.
Position at time t1 + 200 milliseconds by no more than 3.0 meters (i.e.,
0.000027 degrees Latitude).
20xx, RTCA, Inc.

424

correctly in regards to 0.2 UTC Epochs and in regards to alternating
odd and even encodings. Since the test set knows what the data is at
given 1.0 second intervals, and it also time tags the received data, it
is reasonable to expect that the capability is adequate to establish the
proper 0.2 UTC Epochs and the appropriate format encoding.

Note 1: Be advised that this test scenario is forcing movement across the North
Pole at 1020 knots from South to North. It is up to the equipment
properly move across the pole by moving up to 90.0 degrees North and
20xx, RTCA, Inc.

425

Note 1: Be advised that this test scenario is forcing movement across the South
Pole at 1020 knots from North to South. It is up to the equipment
properly move across the pole by moving up to 90.0 degrees South and

2.4.3.2.4.7.3 Verification of Surface Latitude Position Extrapolation/Estimation (non - precision)

(2.2.3.2.4.7.3)
20xx, RTCA, Inc.

426
2.4.3.2.4.7.3.1 Verification of Surface Latitude Position Extrapolation Case (non - precision)

(2.2.3.2.4.7.3.1)
The test procedures provided in 2.4.3.2.4.7.2.1 shall be used to validate performance of
2.4.3.2.4.7.3.1.
2.4.3.2.4.7.3.2 Verification of Surface Latitude Position Estimation Case (non - precision)

(2.2.3.2.4.7.3.2)
2.4.3.2.4.7.3.2.
2.4.3.2.4.7.4 Verification of Surface Latitude Position Data Retention (2.2.3.2.4.7.4, 2.2.5.1.7)

The extrapolation or estimation, and update of latitude data and fields specified in
2.2.3.2.4.7.2 through 2.2.3.2.4.7.3.2 shall be limited to no more than two seconds, in the
event that the latitude position data is no longer available. At the end of two seconds, the
latitude data registers and the encoded latitude field shall be set to ALL ZEROs.
Provide normal Surface Position data to the ADS-B Transmitting Subsystem at the
nominal rate. First, filter the data so that the ADS-B Transmitting Subsystem does
not receive any latitude data for at least 2 seconds. After 2 seconds, verify that the
latitude data registers are set to ALL ZEROs.
Note: In order to terminate latitude data, it may also be necessary to terminate

longitude information since a position fix normally includes both latitude
and longitude.
For equipment that can independently filter latitude and longitude, return to
providing normal Surface Position data at the nominal rate. Next, filter the data so
that the device does not receive any latitude data. After 1 second, stop providing
data. Verify that after 1 second more, the latitude registers are set to ALL ZEROs.
2.4.3.2.4.8 Verification of Encoded Longitude Subfield in ADS-B Surface Position Messages

(2.2.3.2.4.6, 2.2.3.2.4.8, 2.2.5.1.6, 2.2.5.1.8, 2.2.5.1.13)
Appropriate test procedures are provided in 2.4.3.2.4.8 through 2.4.3.2.4.8.4.
20xx, RTCA, Inc.

427
2.4.3.2.4.8.1 Verification of Surface Longitude Data Encoding (2.2.3.2.4.8.1, 2.2.5.1.8, 2.2.5.1.13)

Appropriate test procedures to verify the surface longitude data encoding were previously
provided in 2.4.3.2.4.7.1.2.
2.4.3.2.4.8.2 Verification of Surface Longitude Position Extrapolation/Estimation (Precision Case,

TYPE Codes 5 and 6) (2.2.3.2.4.8.2)
1 ) (2.2.3.2.4.8.2.1, 2.2.5.1.6, 2.2.5.1.8, 2.2.5.1.13)
extrapolates and encodes Surface Position data when working with GNSS synchronized
time.
Equipment Required:

Subsystem.
Note: The velocity requirements above are specified in terms of East/West

verify that such information is properly resolved into the East/West

c.
20xx, RTCA, Inc.

428
seconds.
Notes:
2. Be advised that this test scenario is forcing movement across the Greenwich
Meridian at 1020 knots from East to West. It is up to the equipment designers
Longitude Position by no more than 22.1 meters (i.e., approximately 0.0002
degrees Longitude).
degree Longitude).
c. Select a Surface Position Message that was received at least 6 seconds after
the execution of Step 2 and within 50 25 milliseconds of a GNSS Time
Mark generated by the Test Equipment and provided to the ADS-B
Transmitting Subsystem. Designate the leading edge of the GNSS Time Mark
as t1.
Longitude Position at time t1 + 200 milliseconds by no more than 3.0 meters
(i.e., approximately 0.000027 degrees Longitude).
20xx, RTCA, Inc.

429
received data, it is reasonable to expect that this capacity is adequate
to establish the proper 0.2 UTC Epochs and the appropriate format
encoding.
Note 2: The velocity requirements above are specified in terms of East/West

20xx, RTCA, Inc.

430

International Dateline at 1020 knots from East to West. It is up to the
equipment properly move across the International Dateline by moving
up to 180 degrees and then down for the duration of the test.

2.4.3.2.4.8.2.2 Verification of Non-Coupled Case (Estimation, TIME (T) = 0) (2.2.3.2.4.8.2.2,

2.2.5.1.8, 2.2.5.1.13)
extrapolates and encodes Surface Position data when NOT working with GNSS
synchronized time.
20xx, RTCA, Inc.

431
Equipment Required:

Subsystem.

Note: The velocity requirements above are specified in terms of East/West
c.
seconds.
Notes:
20xx, RTCA, Inc.

432
2. Be advised that this test scenario is forcing movement across the Greenwich
Meridian at 1020 knots from East to West. It is up to the equipment designers
degrees Longitude).
degrees Longitude).
c. Select an Airborne Position Message that was received at least 6 seconds after
the execution of Step 2 and within 50 25 milliseconds of a GNSS Time Mark
generated by the Test Equipment and provided to the ADS-B Transmitting
Subsystem. Designate the leading edge of the GNSS Time Mark as t1.
Longitude Position at time t1 + 200 milliseconds by no more than 3.0 meters
(i.e., approximately 0.000027 degrees Longitude).
correctly in regards to 0.2 UTC Epochs and in regards to
received data, it is reasonable to expect that the capability is
20xx, RTCA, Inc.

433




International Dateline at 1020 knots from East to West. It is up to the
equipment properly move across the International Dateline by moving
up to 180 degrees and then down for the duration of the test.
20xx, RTCA, Inc.

434

2.4.3.2.4.8.3 Verification of Surface Longitude Position Extrapolation/Estimation (non - precision)

(2.2.3.2.4.8.3)
2.4.3.2.4.8.3.1 Verification of Surface Longitude Position Extrapolation Case (non - precision)

(2.2.3.2.4.8.3.1)
2.4.3.2.4.8.3.1.
2.4.3.2.4.8.3.2 Verification of Surface Longitude Position Estimation Case (non - precision)

(2.2.3.2.4.8.3.2)
2.4.3.2.4.8.3.2.
20xx, RTCA, Inc.

435
2.4.3.2.4.8.4 Verification of Surface Longitude Position Data Retention (2.2.3.2.4.8.4, 2.2.5.1.8)

The extrapolation or estimation, and update of longitude data and fields specified in
2.2.3.2.4.8.2 through 2.2.3.2.4.8.3.2 shall be limited to no more than two seconds, in the
event that the longitude position data is no longer available. At the end of two seconds, the
longitude data registers and the encoded longitude field shall be set to ALL ZEROs.
Provide normal Surface Position data to the ADS-B Transmitting Subsystem at the
nominal rate. First, filter the data so that the ADS-B Transmitting Subsystem does
not receive any longitude data for at least 2 seconds. After 2 seconds, verify that
the longitude data registers are set to ALL ZEROs.
Note: In order to terminate longitude data, it may also be necessary to
terminate latitude information since a position fix normally includes
For equipment that can independently filter latitude and longitude, return to
providing normal Surface Position data at the nominal rate. Next, filter the data so
that the device does not receive any longitude data. After 1 second, stop
providing data. Verify that after 1 second more, the longitude registers are set to
ALL ZEROs. Verify that after 1 second more, the longitude registers are set to
ALL ZEROs.
2.4.3.2.5 Verification of ADS-B Aircraft Identification and Category Messages (2.2.3.2.5)

The format for the Aircraft Identification and Category Message ME field contents is
specified in Figure 2-6. Testing requirements for each of the subfields is specified in the
2.4.3.2.5.1 Verification of TYPE Subfield in ADS-B Aircraft Identification and Category

Message (2.2.3.2.5.1)
The test procedures provided in 2.4.3.2.5.2 shall be used to validate performance of
2.4.3.2.5.1.
20xx, RTCA, Inc.

436
2.4.3.2.5.2 Verification of ADS-B Emitter Category Subfield in ADS-B Aircraft Identification

and Category Message (2.2.3.2.5.2, 2.2.5.1.2)
Each of the ADS-B Emitter Category Sets specified in Table 2-21. are used to identify
particular aircraft or vehicle types within the ADS-B Emitter Category Sets A, B, C, or D
identified by Message Format TYPE codes 4, 3, 2 and 1 respectively.
Step 1: Emitter Category Data Input
Provide the ADS-B Transmitting Subsystem with appropriate ADS-B Emitter

Category data via the appropriate interface. Vary the Emitter Category data
input through the range of codes, for appropriate values between 0 through 7 for
Emitter Category Sets A, B, C and D, for all Emitter Categories and
codes that the system supports.
For each ADS-B Emitter Category data input selected, verify that the Format
TYPE Code is properly transmitted in the ADS-B Aircraft Identification and
Category Message.
For each ADS-B Emitter Category data input selected, verify that the ADS-B
Emitter Category subfield is properly transmitted in the ADS-B Aircraft
Identification and Category Message in accordance with the encodings provided
in Table 2-21.
Step 2: Emitter Category Data Not Available
Set up the ADS-B Transmitting Subsystem as in Step 1 above. Discontinue the

input of valid ADS-B Emitter Category data and verify that the ADS-B Emitter
Category Subfield is set to ALL ZEROs (binary 000) in the Aircraft Identification
and Category Message.
2.4.3.2.5.3 Verification of Character Subfield in ADS-B Aircraft Identification and Category

Message (2.2.3.2.5.3, 2.2.5.1.11)
Each of the 8 Character subfields is a 6-bit field as shown in Figure 2-6.
Step 1: Aircraft Identification Data Input - Part 1

Category data via the appropriate interface. Set the input data for each of the eight
characters to the character 5.
20xx, RTCA, Inc.

437
Verify that each of the characters in the ADS-B Aircraft Identification and
Category Message is transmitted properly in accordance with the encoding
provided in A.1.4.4.1 of Appendix A. For an input character of 5, the
encoding for each character should be 110101 Binary.
Step 2: Aircraft Identification Data Input - Part 2

Category data via the appropriate interface. Set the input data for each of the eight
characters to the character J.
Verify that each of the characters in the ADS-B Aircraft Identification and
Category Message is transmitted properly in accordance with the encoding
provided in A.1.4.4.1 of Appendix A. For an input character of J, the encoding
for each character should be 001010 Binary.
Step 3: Aircraft Registration Marking Data Input
Repeat Step 1 and 2 while providing the ADS-B Transmitting Subsystem with
Aircraft Registration Marking data instead of Aircraft Identification via the
appropriate interface.
Step 4: No Aircraft Identification or Aircraft Registration Data
Discontinue the input of Aircraft Identification or Aircraft Registration Marking

Data. Verify that each of the characters in the ADS-B Aircraft Identification and
Category Message is transmitted properly with all bits of each character set to a
binary ZERO (0). The encoding for each character should be ALL ZEROs
(binary 000000).
Note: The message will continue to be transmitted as long as Category data
continues to be updated.
2.4.3.2.6 Verification of ADS-B Airborne Velocity Messages (2.2.3.2.6)

Formats for the various Airborne Velocity Messages are further classified by Subtype as
identified in Figure 2-7 and Figure 2-8. Test procedures to verify the various fields within
the Airborne Velocity Message are described in the following paragraphs.
2.4.3.2.6.1 Verification of ADS-B Airborne Velocity Message - Subtype=1 (2.2.3.2.6.1)

Appropriate test procedures required to validate the correct transmission of the parameters
of the ADS-B Airborne Velocity Message Subtype=1 are provided in 2.4.3.2.6.1.1
through 2.4.3.2.6.1.15.
Additionally, the requirement of 2.2.3.2.6.1.c states that: this message shall not be
broadcast if the only valid data is the Intent Change Flag.
20xx, RTCA, Inc.

438
Configure the ADS-B Transmitting Subsystem to transmit Airborne Velocity Messages by

providing velocity information at the nominal update rate. Provide the data externally at the
interface to the ADS-B system. Set up the system to enable broadcast of Airborne Velocity
Messages. Set the ADS-B Transmitting Subsystem to Airborne Status. Provide valid input
data and verify that Airborne Velocity Messages Subtype=1 are being broadcast.
Discontinue all of the input data to the data fields except for the Intent Change Flag data.
Wait 2.6 seconds and verify that the Airborne Velocity Message Subtype=1 is no longer
being broadcast.
Repeat this procedure for Airborne Velocity Messages of Subtypes 2, 3 and 4.
2.4.3.2.6.1.1 Verification of TYPE Subfield in Airborne Velocity Messages - Subtype=1

(2.2.3.2.6.1.1)
Appropriate test procedures are provided in 2.4.3.2.6.1.2.
2.4.3.2.6.1.2 Verification of Subtype Subfield in Airborne Velocity Messages - Subtype=1

(2.2.3.2.6.1.1, 2.2.3.2.6.1.2, 2.2.3.2.6.2.1, 2.2.3.2.6.2.2, 2.2.3.2.6.3.1, 2.2.3.2.6.3.2,
2.2.3.2.6.4.1, 2.2.3.2.6.4.2, 2.2.3.2.7.1.1, 2.2.3.2.7.1.2, 2.2.3.2.7.2.1, 2.2.3.2.7.2.2)
The Subtype subfield is contained in Message Bits 38 through 40 (ME Bits 6 through 8),
and is encoded according to Figure 2-7. This test procedure is intended to verify that the
appropriate Subtype subfield is used in all Airborne Velocity Messages.
Step 1: TYPE and Subtype Verification - Part 1
Configure the ADS-B Transmitting Subsystem to transmit Airborne Velocity

Messages by providing velocity information at the nominal update rate. Provide
the data externally at the interface to the ADS-B system. Set up the system to
enable broadcast of Airborne Velocity Messages (see additional information in
2.2.3.3.2.5, ADS-B Velocity Message Broadcast Rate). Set the ADS-B
Transmitting Subsystem to Airborne status. Provide velocity information in the
form of Velocity Over Ground (i.e., Ground Speed) with a valid value that is
greater than zero but non-supersonic (i.e., both North/South AND East/West
Velocity inputs are less than 1000 knots).
Verify that ADS-B Messages are generated with TYPE value 19 and that all
such messages contain Subtype value 1.
Raise the East/West Velocity input to a value of 1021 knots, and verify that ADS-
B Messages are generated with TYPE value 19 and that all such messages
contain Subtype value 1. Lower the East/West Velocity input to a value below
1000 knots, and raise the North/South Velocity input to a value of 1021 knots.
20xx, RTCA, Inc.

439
Lower the North/South Velocity input to a value below 1000 knots, then raise
both the East/West and North/South Velocity inputs to values of 1021 knots.
Note: During the execution of the previous step, care must be taken to ensure
that neither the East/West nor the North/South Velocity inputs are raised
to a value greater than 1021 knots.
This step verifies that the ADS-B Transmitting Subsystem correctly transitions
between Subtype equal 1 and Subtype equal 2 in Airborne Velocity
Messages.
Set up the system to enable broadcast of Airborne Velocity Messages as indicated

in Step 1. Provide velocity information in the form of Velocity Over Ground (i.e.,
Ground Speed). Initially, both the East/West Velocity input and the North/South
Velocity input shall be greater than 0 knots but less than 1000 knots, as in Step 1.
Raise the East/West Velocity to a value of 1023 knots.
Decrease the East/West Velocity input to a value of 999 knots. Verify that ADS-
B Messages are generated with TYPE value 19 and that all such messages revert
to Subtype value 1. Raise the North/South Velocity to a value of 1023 knots.
Decrease the North/South Velocity input to a value of 999 knots.
such messages revert to Subtype value 1.
Raise both North/South and East/West input values to 1023 knots, and verify that
ADS-B Messages are generated with TYPE value 19 and that all such messages
contain Subtype value 2.
Decrease both North/South and East/West input values to 999 knots, and verify
that ADS-B Messages are generated with TYPE value 19 and that all such
messages contain Subtype value 1.
20xx, RTCA, Inc.

440
Provide velocity information in the form of Airspeed and Heading Information

with a valid value that is greater than zero but non-supersonic (i.e., the Airspeed
input is less than 1000 knots).
Verify that ADS-B Airborne Velocity Messages are generated with TYPE value
19 and that all such messages contain Subtype value 3.
Raise the Airspeed input to 1021 knots, without exceeding the value of 1022 knots
in the process.
This step verifies that the ADS-B Transmitting Subsystem correctly transitions
between Subtype equal 3 and Subtype equal 4 in Airborne Velocity Messages
containing Airspeed and Heading Information.
Set up the system to enable broadcast of Airborne Velocity Messages as indicated

in Step 1 but with velocity information provided in the form of Airspeed and
Heading Information rather than Velocity Over Ground. Initially, the Airspeed
input shall be greater than 0 knots but less than 1000 knots, as in Step 1. Raise
the input Airspeed to a value of 1023 knots.
Decrease the Airspeed input to a value of 999 knots.
such messages revert to Subtype value 3.
2.4.3.2.6.1.3 Verification of Intent Change Flag Subfield in Airborne Velocity Messages -

Subtype=1 (2.2.3.2.6.1.3, 2.2.3.2.6.2.3, 2.2.3.2.6.3.3, 2.2.3.2.6.4.3, 2.2.5.1.18)
This test procedure verifies that the Intent Change Flag subfield is used to indicate a
change in intent as specified in Table 2-23, and transmitted in the Airborne Velocity
Message Message.
20xx, RTCA, Inc.

441
Step 1: Intent Change Flag Subfield in Airborne Velocity Messages (All Subtypes),
Mode-S Transponder Implementations - Setup (2.2.3.2.6.1.3.a)
For Mode-S Transponder Implementations only, configure the ADS-B

Transmitting Subsystem to transmit Airborne Velocity Messages by providing
velocity information at the nominal update rate. Provide data externally at the
interface to the ADS-B system, via GICB Registers 4016 to 4216, appropriate to
each of the four Airborne Velocity Message Subtypes (see 2.2.3.2.6), and enable
broadcasting of the Airborne Velocity Messages (see additional information in
Transmitting Subsystem to Airborne status, and provide valid non-zero velocity
data to the ADS-B Transmitting System.
Mode-S Transponder Implementations (2.2.3.2.6.1.3.a)
Change the data input to GICB Registers 4016 to 4216, and verify that after 4
seconds, and for each of the four Airborne Velocity Message Subtypes, that the
ADS-B Airborne Velocity Messages are generated with TYPE value 19, and
with Message Bit 41, ME Bit 9 (Intent Change Flag subfield) set to ONE (1).
With no further change at the data input to GICB Registers 4016 to 4216, verify that
after 18 1 seconds following the last intent change, the Message Bit 41, ME Bit 9
(Intent Change Flag subfield) is reset to ZERO (0).
Non-Transponder Implementations - Setup (2.2.3.2.6.1.3.b)
For Non-Transponder Implementations only, repeat Steps 1 and 2.
Verify that for each of the four Airborne Velocity Message Subtypes, that the
with Message Bit 41, ME Bit 9 (Intent Change Flag subfield) always set to
ZERO (0).
2.4.3.2.6.1.4 Verification of Reserved Bit-A Subfield in Airborne Velocity Messages Subtype=1

(2.2.3.2.6.1.4)
The Reserved Bits-A subfield is a 1-bit (ME bit 10, Message bit 42) field that shall be
set to ZERO (0) in all ADS-B Transmitting Subsystems that comply with these MOPS.
Configure the ADS-B Transmitting Subsystem to broadcast Airborne Velocity Messages

Subtype=1 at the nominal rate. Verify that the Reserved Bits-A subfield is set to ZERO
(0) in all transmitted messages.
20xx, RTCA, Inc.

442
2.4.3.2.6.1.5 Verification of NACV Subfield in Airborne Velocity Messages - Subtype=1

(2.2.3.2.6.1.5, 2.2.3.2.6.2.5, 2.2.3.2.6.3.5, 2.2.3.2.6.4.5, 2.2.5.1.19)
The NACV subfield is used to indicate the Navigation Accuracy Category for Velocity as
specified in Table 2-25. These test procedures are intended for use for Airborne Velocity
Messages of all Subtypes. The type and values of the input Velocity data should be set so
as to generate Airborne Velocity Messages for all appropriate Subtype fields.
Note: Subsequent to Revision A of the 1090 MHz ADS-B MOPS, the Federal Aviation
Administration requested RTCA SC-159 to develop test procedures for a velocity
accuracy test to characterize the 95% horizontal and 95% vertical velocity
accuracies during normal maneuvers of GNSS equipment, as specified in
RTCA/DO-229D, RTCA/DO-316, and RTCA/DO-253C receiver MOPS, which do
not provide a specific velocity accuracy output. These tests can be used to
substantiate Global Positioning System (GPS), GPS/Space-Based Augmentation
System (SBAS), or GPS/Ground-Based Augmentation System (GBAS) equipment to
support an ADS-B NACV =1 requirement of horizontal velocity error less than 10
meters/second (95th percentile with HDOP of 1.5 or less) and vertical velocity
error less than 50 feet/second (95th percentile, with VDOP of 3.0 or less).
Additional test procedures were developed to substantiate equipment that supports
a NACV =2 requirement of horizontal velocity error less than 3 meters/second and
vertical velocity error less than 15 feet/second. However, these tests are not
adequate for demonstrating more stringent ADS-B NACV levels (i.e., NACV =3, or
greater), but are expected to be developed as more demanding ADS-B applications
mature. The results of these tests can be used to substantiate the setting of a NAC V
value to be used when ADS-B position and velocity are provided by the GPS
equipment, presuming that that equipment does not have a specific velocity
accuracy output.
Configure the ADS-B Transmitting Subsystem to transmit Airborne Velocity Messages by

providing velocity information at the nominal update rate. Provide the data externally at the
interface to the ADS-B system. Set up the system to enable broadcast of Airborne Velocity
Messages. Set the ADS-B Transmitting Subsystem to Airborne status. Provide valid non-
zero velocity data to the ADS-B System.
From an external source, input 95% accuracy figures of merit for horizontal velocity, and
verify that for each horizontal velocity error value in Table 2-25 that the system generates
Airborne Velocity Messages with the NACV subfield set equal to the corresponding binary
coding value shown for the NACV subfield in Table 2-25.
20xx, RTCA, Inc.

443
2.4.3.2.6.1.6 Verification of East/West Direction Bit Subfield in Airborne Velocity Messages -

Subtype=1 (2.2.3.2.6.1.6, 2.2.3.2.6.2.6, 2.2.5.1.12)
The East/West Direction Bit subfield is contained in Message Bit 46 (ME Bit 14) of
Airborne Velocity Messages - Subtypes 1 and 2. This test procedure verifies that the
East/West Direction Bit subfield in Airborne Velocity Messages is correctly set to ZERO
(0) for inputs indicating travel in an eastward direction, and ONE (1) for travel in a
westward direction.
These test procedures are intended for use for Airborne Velocity Messages of Subtypes 1
and 2. The values of the input Velocity data should be set so as to generate Airborne
Velocity Messages for each Subtype value.
Step 1: East/West Direction Bit Verification when Velocity is Not Available

Messages with Subtype=1 by providing velocity information at the nominal
update rate. Provide the data externally at the interface to the ADS-B system. Set
up the system to enable broadcast of Airborne Velocity Messages (see additional
information in 2.2.3.3.2.5, ADS-B Velocity Message Broadcast Rate). Set the
ADS-B Transmitting Subsystem to Airborne status. Provide valid non-zero
velocity data to the ADS-B System.
Verify that when East/West Velocity Data is not provided to the ADS-B
Transmitting Subsystem, the East/West Direction Bit subfield is set to ZERO
(0).
Step 2: East/West Direction Bit Verification Directional Components
The method for testing this field depends largely upon the nature of the input for
East/West Velocity Data.
CASE 1:
If the directional component of the input is a single bit or a flag type (i.e. a
single discrete value is used to represent EAST, and another discrete value is
used to represent WEST), then the procedure for this step shall be as follows.
Set the input to the value that indicates travel in an eastward direction, and check
that ADS-B Airborne Velocity Messages are generated with TYPE value 19,
and that all such messages contain an East/West Direction Bit subfield with a
value of ZERO (0).
Next, set the input to the value that indicates travel in a westward direction.
Verify that ADS-B Airborne Velocity Messages are generated with TYPE value
19, and that all such messages contain an East/West Direction Bit subfield
with a value of ONE (1).
20xx, RTCA, Inc.

444
CASE 2:
If the directional component of the input is variable (e.g. a heading expressed in

degrees or other similar manner so that the input value must be evaluated by the
ADS-B Transmitting Subsystem in order to determine the proper value for the
East/West Direction Bit), then the test procedure shall be as follows. In this
case, the input variable must be made to assume values corresponding to
movement in an eastward direction.
It must be verified for each such input value that Airborne Velocity Messages are
generated with TYPE value 19 and that all such messages contain an East/West
Direction Bit subfield with a value of ZERO (0).
The input must then be varied to assume values corresponding to movement in a

westward direction. It must be verified for each such value that the system
generates Airborne Velocity Messages with TYPE value 19 and that all such
messages contain an East/West Direction Bit subfield with a value of ONE (1).
2.4.3.2.6.1.7 Verification of East/West Velocity Subfield in Airborne Velocity Messages -

Subtype=1 (2.2.3.2.6.1.7, 2.2.5.1.12)
The East/West Velocity subfield is contained in Message Bits 47 through 56 (ME Bits 15
through 24) of Airborne Velocity Messages - Subtypes 1 and 2. The following test
procedures verify that the East/West Velocity subfield in Airborne Velocity Messages is
correctly set according to the coding specified.
Step 1: East/West Velocity Verification Velocity Data Not Available

enable broadcast of Airborne Velocity Messages with Subtype=1 (see additional
velocity data to the ADS-B System. Discontinue East/West Velocity data.
Verify that when East/West Velocity Data is not provided to the ADS-B
Transmitting Subsystem, the East/West Velocity subfield is set to ZERO (binary
00 0000 0000).
Step 2: East/West Velocity Verification Velocity Equal ZERO
Setup the ADS-B Transmitting Subsystem as in Step 1 and set the East/West
Velocity input to represent a velocity of ZERO knots. Verify that the East/West
Velocity subfield is set to ONE (1) (binary 00 0000 0001).
20xx, RTCA, Inc.

445
Step 3: East/West Velocity Verification Discrete Values
Verify that for each integer East/West Velocity input value in knots in Table 2-
135, that the system generates Airborne Velocity Messages with the TYPE
Subfield equal to 19 and that the East/West Velocity subfield in each such
message is set equal to the corresponding binary coding value in Table 2-135.
Table 2-135: Discrete Values for East/West Velocity

East/West Velocity (subsonic)
Coding Meaning
(Binary) (Decimal) (E/W Velocity in knots)
00 0000 0010 2 E/W Velocity = 1 knot
Step 4: East/West Velocity Verification Maximum Values
If the resolution of the input value is the same as the resolution of the East/West
Velocity subfield in the output message (i.e., 1 knot), verify that for an input
corresponding to an eastward velocity of 1022 (in knots), Airborne Velocity
Messages are generated with TYPE 19 and all such messages contain an
East/West Velocity subfield with a value of 1023 (binary 11 1111 1111).
If the resolution of the input value is greater than the resolution of the East/West
Velocity subfield, verify that for the input value corresponding to the largest
possible eastward velocity that is less than 1021.5 knots, Airborne Velocity
Messages Subtype=1 are generated and all such messages contain an East/West
Velocity subfield with a value of 1022 (binary 11 1111 1110).
If the resolution of the input data makes it possible to enter an input value that
corresponds to exactly 1021.5 knots, then this value shall be input and it shall be
verified that the resultant East/West Velocity subfield output field is equal to
either 1022 (binary 11 1111 1110, represents 1021 knots) or 1023 (binary 11 1111
1111, represents > 1021.5 knots).
Step 5: East/West Velocity Verification - Part 5
If the input data used to establish the East/West Velocity subfield has more
resolution than that required by the East/West Velocity subfield (i.e., more than
20xx, RTCA, Inc.

446
10 bits), then this step shall be used to ensure that the accuracy of the data is
maintained such that it is not worse than LSB, where the LSB is the least
significant bit of the East/West Velocity subfield.
If the input data field that is used to determine the output value of the East/West
Velocity subfield consists of 10 bits or less, proceed to Step 6.
Enter an input value corresponding to an eastward velocity of 1.5 knots.
Verify that the value of the East/West Velocity subfield in the output message is
either 2 (binary 00 0000 0010, represents 1 knot) or 3 (binary 00 0000 0011,
represents 2 knots).
If the input field used to establish the East/West Velocity subfield has exactly
11 bits, skip to step 6. Otherwise (indicating that more than 11 bits are used to
establish East/West Velocity subfield), let Z be equal to the smallest possible
fraction that can be represented by the number of bits in the input field (i.e., Z is
the value of the least significant bit of the input field). Set the value of the input
field to correspond to an eastward velocity of (1.5 Z).
Verify that the value of the East/West Velocity subfield in the output Airborne
Velocity Message is 2 (binary 00 0000 0010, represents 1 knot).
Set the value of the input field to correspond to an eastward velocity of (1.5 + Z).
Velocity Message is 3 (binary 00 0000 0011, represents 2 knots).
Note: If the resolution of the East/West Velocity input is such that an
eastward velocity of 1.5 knots cannot be represented (but is still
greater than 1 knot, e.g., a resolution of 0.2 knot increments), then
values corresponding to eastward velocity must be tested, and the
output examined for each value to confirm that the output is within 0.5
knots (inclusive) of the input value.
Note: If the nature of the inputs is such that a separate bit or flag type field
is input to the transmitter to indicate East or West, the following
step is not necessary. However, if the transmitter must perform some
interpretation of its inputs in order to determine the correct output
value of the East/West Direction Bit, the following step must be
performed.
Repeat Steps 3, 4 and 5 so that each step is performed with East/West Velocity
input data indicating travel in both EAST and WEST directions, i.e., replace the
word eastward with westward in steps 3, 4 and 5.
20xx, RTCA, Inc.

447
2.4.3.2.6.1.8 Verification of North/South Direction Bit Subfield in Airborne Velocity Messages -

Subtype=1 (2.2.3.2.6.1.8, 2.2.3.2.6.2.8, 2.2.5.1.13)
The North/South Direction Bit subfield is contained in Message Bit 57 (ME Bit 25) of
Airborne Velocity Messages - Subtypes 1 and 2. This test procedure verifies that the
North/South Direction Bit subfield in Airborne Velocity Messages is correctly set to
ZERO (0) for travel in a northward direction, and ONE (1) for travel in a southward
direction.
Velocity Messages for all appropriate Subtype fields.
Step 1: North/South Direction Bit Verification Velocity Data Not Available

Messages by providing velocity data at the nominal update rate. Provide the data
externally at the interface to the ADS-B system. Set up the system to enable
broadcast of Airborne Velocity Messages (see additional information in
Transmitting Subsystem to Airborne status. Provide valid non-zero barometric
pressure altitude data and valid non-zero velocity data to the ADS-B System.
Verify that when North/South Velocity Data is not provided to the ADS-B
Transmitting Subsystem, the North/South Direction Bit subfield is set to ZERO
(0), as specified in 2.2.5.1.13, item (e).
Step 2: North/South Direction Bit Verification Directional Components
North/South Velocity Data.
CASE 1:
single discrete value is used to represent NORTH, and another discrete value is
used to represent SOUTH), then the procedure for this step shall be as follows:
Set this input to the value that indicates travel in a northward direction, and check
that ADS-B Airborne Velocity Messages are generated with TYPE value 19,
and that all such messages contain a North/South Direction Bit subfield with a
value of ZERO (0).
Next, set the input to the value that indicates travel in a southward direction, and
verify that ADS-B Airborne Velocity Messages are generated with TYPE value
19, and that all such messages contain a North/South Direction Bit subfield
with a value of ONE (1).
20xx, RTCA, Inc.

448
CASE 2:
If the directional component of the input is variable (e.g., a heading expressed in

degrees or other similar manner, so that the input value must be evaluated by the
North/South Direction Bit subfield), then the test procedure shall be as follows.
In this case, the input variable must be made to assume values corresponding to
movement in a northward direction, and it must be verified, for each such value,
that Airborne Velocity Messages are generated with TYPE value 19 and that all
such messages contain a North/South Direction Bit subfield with a value of
ZERO (0).
The input must then be made to assume values corresponding to movement in a

southward direction, and it must be verified, for each such value, that the
transmitter generates Airborne Velocity Messages with TYPE value 19, and that
all such messages contain a North/South Direction Bit subfield with a value of
ONE (1).
2.4.3.2.6.1.9 Verification of North/South Velocity Subfield in Airborne Velocity Messages -

Subtype=1 (2.2.3.2.6.1.9, 2.2.5.1.13)
The North/South Velocity subfield is contained in Message Bits 55 through 65 (ME Bits
23 through 33) of Airborne Velocity Messages - Subtypes 1 and 2. This test procedure
verifies that the North/South Velocity subfield in Airborne Velocity Messages is correctly
set.
Step 1: North/South Velocity Verification Velocity Data Not Available

the data externally at the interface to the ADS-B system.
Set up the system to enable broadcast of Airborne Velocity Messages with

Subtype=1 (see additional information in 2.2.3.3.2.5, ADS-B Velocity Message
Broadcast Rate). Set the ADS-B Transmitting Subsystem to Airborne status.
Provide valid non-zero velocity data to the ADS-B System.
Discontinue North/South Velocity data and verify that when North/South Velocity
Data is not provided to the ADS-B Transmitting Subsystem, the North/South
Velocity subfield is set to ZERO (binary 00 0000 0000).
Step 2: North/South Velocity Verification Velocity Equal ZERO
Set up the ADS-B Transmitting Subsystem as above and set the North/South
Velocity input to represent a velocity of ZERO knots.
20xx, RTCA, Inc.

449
Verify that the North/South Velocity subfield is set to ONE (1).
Step 3: North/South Velocity Verification Discrete Values
Verify that for each integer North/South Velocity input value in knots in Table 2-
136 that the system generates Airborne Velocity Messages with the TYPE
Subfield equal to 19 and that the North/South Velocity subfield in each such
message is set equal to the corresponding binary coding value in Table 2-136.
Table 2-136: Discrete Values for North/South Velocity

North/South Velocity (subsonic)
Coding Meaning
(Binary) (Decimal) (N/S Velocity in knots)
00 0000 0010 2 N/S Velocity = 1 knot
Step 4: North/South Velocity Verification Maximum Values
If the resolution of the input value is the same as the output resolution (i.e., 1
knot), verify that for an input corresponding to a northward velocity of 1022 (in
knots), Airborne Velocity Messages are generated with TYPE 19 and all such
messages contain a North/South Velocity subfield with a value of 1023 (binary
11 1111 1111).
If the resolution of the input value is greater than the output resolution, verify that
for input value corresponding to the largest possible northward velocity that is less
than 1021.5 knots, Airborne Velocity Messages Subtype=1 are generated and all
such messages contain a North/South Velocity subfield with a value of 1022
(binary 11 1111 1110).
If the resolution of the input data makes it possible to enter an input value that
corresponds to exactly 1021.5 knots, then this value shall be input and it shall be
verified that the resultant North/South Velocity output field is equal to either
1022 (binary 11 1111 1110, representing 1021 knots) or 1023 (binary 11 1111
1111, representing > 1021.5 knots).
20xx, RTCA, Inc.

450
Step 5: North/South Velocity Verification - Part 5
If the input data used to establish the North/South Velocity subfield has more
resolution than that required by the North/South Velocity subfield (i.e., more
than 10 bits), then this step shall be used to ensure that the accuracy of the data is
maintained such that it is not worse than LSB, where the LSB is the least
significant bit of the North/South Velocity subfield. If the input data field that
is used to determine the output value of the North/South Velocity subfield
consists of 10 bits or less, proceed to Step 6.
Enter an input value corresponding to a northward velocity of 1.5 knots.
Verify that the value of the North/South Velocity subfield in the output message
is either 2 (binary 00 0000 0010, representing 1 knot) or 3 (binary 00 0000
0011, representing 2 knots).
If the input field used to establish the North/South Velocity subfield has exactly
11 bits, skip to step 6. Otherwise (indicating that more than 11 bits are used to
establish North/South Velocity subfield), let Z be equal to the smallest possible
fraction that can be represented by the number of bits in the input field (i.e., Z is
the value of the least significant bit of the input field). Set the value of the input
field to correspond to a northward velocity of (1.5 Z).
Verify that the value of the North/South Velocity subfield in the output
Airborne Velocity Message is 2 (binary 00 0000 0010, representing 1 knot).
Set the value of the input field to correspond to a northward velocity of (1.5 + Z).
Airborne Velocity Message is 3 (binary 00 0000 0011, representing 2 knots).
Note: If the resolution of the North/South Velocity input is such that a
northward velocity of 1.5 knots cannot be represented (but is still
greater than 1 knot, e.g., a resolution of 0.2 knot increments), then
values corresponding to northward velocity must be tested, and the
output examined for each value to confirm that the output is within 0.5
knots (inclusive) of the input value.
is input to the transmitter to indicate North or South, the
following step is not necessary. However, if the transmitter must
perform some interpretation of its inputs in order to determine the
correct output value of the North/South Direction Bit, the following
step must be performed.
Repeat Steps 3, 4 and 5 so that each step is performed with North/South Velocity
input data indicating travel in both NORTH and SOUTH directions, i.e., replace
the word northward with southward in steps 3, 4 and 5.
20xx, RTCA, Inc.

451
2.4.3.2.6.1.10 Verification of Source Bit for Vertical Rate Subfield in Airborne Velocity Messages -
Subtype=1 (2.2.3.2.6.1.10, 2.2.3.2.6.2.10, 2.2.3.2.6.3.10, 2.2.3.2.6.4.10, 2.2.5.1.14)
The Source Bit for Vertical Rate subfield is contained in Message Bit 68 (ME Bit 36) of
Airborne Velocity Messages. The following test verifies that this bit is correctly set
according to the table contained in the above referenced section.
These test procedures are intended for use for Airborne Velocity Messages of all subtypes.
The type and values of the input Velocity data should be set so as to generate Airborne
Step 1: Vertical Rate Source Bit Verification - Part 1

2.2.3.3.2.5, ADS-B Velocity Information Message Broadcast Rate). Set the
barometric pressure altitude data and valid non-zero velocity data to the ADS-B
System.
Verify that if the input Vertical Rate data is from Geometric Source (GNSS or
INS), then the Source Bit for Vertical Rate subfield is set to ZERO (0).
Step 2: Vertical Rate Source Bit Verification - Part 2
Change the Vertical Rate input data so that it indicates to the ADS-B Transmitting
Subsystem that it is from Barometric Source.
Verify that the Source Bit for Vertical Rate subfield in subsequent output
messages is set to ONE (1).
2.4.3.2.6.1.11 Verification of Sign Bit for Vertical Rate Subfield in Airborne Velocity Messages -
Subtype=1 (2.2.3.2.6.1.11, 2.2.3.2.6.2.11, 2.2.3.2.6.3.11, 2.2.3.2.6.4.11, 2.2.5.1.14)
The Sign Bit for Vertical Rate subfield is contained in Message Bit 69 (ME Bit 37) of
Airborne Velocity Messages. The following test verifies that this bit is correctly set to
ZERO (0) to indicate an upward vertical rate vector (climb), and ONE (1) to indicate a
downward vertical rate vector (descent).
These test procedures are intended for use for Airborne Velocity Messages of all Subtypes.
20xx, RTCA, Inc.

452
Step 1: Sign Bit for Vertical Rate Verification Data Not Available

Verify that when Vertical Rate Data is not provided to the ADS-B Transmitting
Subsystem, the Sign Bit for Vertical Rate subfield is set to ZERO (0), as
specified in 2.2.5.1.14, item (d).
Step 2: Sign Bit for Vertical Rate Directional Component Verification
Vertical Rate subfield Data.
CASE 1:
single discrete value is used to represent UP, and another discrete value is used
to represent DOWN), then the procedure for this step shall be as follows:
Set this input to the value that indicates an upward direction, and verify that ADS-
B Airborne Velocity Messages are generated with TYPE value 19, and that all
such messages contain a Sign Bit for Vertical Rate subfield with a value of
ZERO (0).
Next, set the input to the value that indicates a downward direction, and verify that
that all such messages contain a Sign Bit for Vertical Rate subfield with a value
of ONE (1).
CASE 2:
If the directional component of the input is variable (e.g., a heading expressed in

degrees or other similar manner, so that the input value must be evaluated by the
Sign Bit for Vertical Rate subfield), then the test procedure shall be as follows.
In this case, the input variable must be made to assume values corresponding to an
upward climb, and it must be verified, for each such value, that Airborne Velocity
Messages are generated with TYPE value 19 and that all such messages contain
a Sign Bit for Vertical Rate subfield with a value of ZERO (0).
The input must then be made to assume values corresponding to a descent, and it
must be verified, for each such value, that the transmitter generates Airborne
20xx, RTCA, Inc.

453
Velocity Messages with TYPE value 19, and that all such messages contain a
Sign Bit for Vertical Rate subfield with a value of ONE (1).
2.4.3.2.6.1.12 Verification of Vertical Rate Subfield in Airborne Velocity Messages - Subtype=1

(2.2.3.2.6.1.12, 2.2.3.2.6.2.12, 2.2.3.2.6.3.12, 2.2.3.2.6.4.12, 2.2.5.1.14)
The Vertical Rate subfield is contained in Message Bits 70 through 78 (ME Bits 38
through 46) of Airborne Velocity Messages. This test procedure verifies that the Vertical
Rate subfield in Airborne Velocity Messages is correctly set.
Step 1: Vertical Rate Not Available Verification

Verify that when Vertical Rate Data is not provided to the ADS-B Transmitting
Subsystem, the Vertical Rate subfield in Airborne Velocity output messages is
set to ZERO (0) (binary 0 0000 0000).
Step 2: Vertical Rate Equal To ZERO Verification
The input for this field shall initially be set to represent a Vertical Rate of
ZERO feet per minute.
Verify that the ADS-B Transmitting Subsystem generates Airborne Velocity

Messages with TYPE 19 and that the Vertical Rate subfield in each such
message contains the value ONE (1) (binary 0 0000 0001).
Step 3: Vertical Rate Verification Discrete Values
Increase the value of the Vertical Rate Data input so that it assumes each
discrete decimal coding value from Table 2-137.
Verify that for each discrete decimal coding input value, the Vertical Rate
subfield in subsequent Airborne Velocity Messages of TYPE 19 matches
identically the corresponding Binary Coding value from Table 2-137.
20xx, RTCA, Inc.

454
Table 2-137: Vertical Rate Discrete Values

Vertical Rate
Coding Meaning
(Binary) (Decimal) (Vertical Rate in feet / minute)
0 0101 0000 80 Vertical Rate = 5,056 feet / minute
Verify that the Vertical Rate subfield in the output message is not incremented
until the input value reaches a number corresponding to an integer multiple of 64
feet/minute with an accuracy of 32 feet/minute.
Step 4: Vertical Rate Verification Out of Bounds Test
Continue to increase the value of the Vertical Rate Data input.
Verify that for values greater than 32,576 feet per minute but less than or equal to
32,608 feet per minute, the Vertical Rate subfield continues to be set to 510
(binary 1 1111 1110).
Continue to increase the value of the vertical rate input.
Verify that for values representing a vertical rate greater than 32,608 feet per
minute, up to the maximum possible input value, that the transmitter continues to
generate Airborne Velocity Messages with a TYPE subfield equal to 19 and that
the Vertical Rate subfield for all such messages is set to 511 (binary 1 1111
1111).
Step 5: Vertical Rate Verification - Part 5

Note: If the nature of the inputs is such that a separate bit or flag type field is
input to the transmitter to indicate Up or Down, the following step
is not necessary. However, if the transmitter must perform some
interpretation of its inputs in order to determine the correct output value
of the Sign Bit for Vertical Rate subfield, the following step must be
performed.
Repeat steps 3 through 5, so that each step is performed with Vertical Rate input
data indicating directional vectors of both UP (climb) and DOWN (descent) turns.
20xx, RTCA, Inc.

455
2.4.3.2.6.1.13 Verification of Reserved Bits-B Subfield in Airborne Velocity Messages Subtype=1

(2.2.3.2.6.1.13)
The Reserved Bits-B subfield is a 2-bit (ME bits 47 48, Message bits 79 80) field
that shall be set to ZERO (binary 00) in all ADS-B Transmitting Subsystems that comply
with these MOPS.
Configure the ADS-B Transmitting Subsystem to broadcast Airborne Velocity Messages

Subtype=1 at the nominal rate. Verify that the Reserved Bits-B subfield is set to ZERO
(binary 00) in all transmitted messages.
2.4.3.2.6.1.14 Verification of Difference From Barometric Altitude Sign Bit Subfield in Airborne
Velocity Messages - Subtype=1 (2.2.3.2.6.1.14, 2.2.3.2.6.2.14, 2.2.3.2.6.3.14,
2.2.3.2.6.4.14)
The Difference From Barometric Altitude Sign Bit is used to indicate the direction of the
GNSS Altitude Source data as shown in Table 2-35. These test procedures are intended for
use for Airborne Velocity Messages of all Subtypes. The type and values of the input
Velocity data should be set so as to generate Airborne Velocity Messages for all appropriate
Subtype fields.
Step 1: Difference from Baro Altitude Sign Bit Verification - Part 1

barometric pressure altitude data, valid non-zero Geometric Source data and valid
non-zero velocity data to the ADS-B System. Set the inputs so that the input
Geometric Altitude Source data is greater than (above) the input Barometric
Altitude.
Verify that the Difference From Barometric Altitude Sign Bit subfield in
subsequent Airborne Velocity output messages is set to ZERO (0).
Step 2: Difference from Baro Altitude Sign Bit Verification - Part 2
Lower the input Geometric Altitude Source data.
20xx, RTCA, Inc.

456
Verify that as long as the input Geometric Altitude Source data is greater than the
input Barometric Altitude (in feet), all transmitted Airborne Velocity Messages
continue to contain a ZERO (0) in the SIGN BIT subfield.
Verify that as soon as the input Geometric Altitude Source data becomes lower
than the input Barometric Altitude, the SIGN BIT subfield in Airborne Velocity
Messages is changed to a ONE (1).
2.4.3.2.6.1.15 Verification of Difference From Barometric Altitude Subfield in Airborne Velocity

Messages - Subtype=1 (2.2.3.2.6.1.15, 2.2.3.2.6.2.15, 2.2.3.2.6.3.15, 2.2.3.2.6.4.15)
The Difference From Barometric Altitude subfield is used to report the difference
between Geometric (GNSS or INS) Altitude Source data and Barometric Altitude when both
types of Altitude Data are available and valid, and is encoded as shown in Table 2-36.
Step 1: Difference from Barometric Altitude Verification Not Available

barometric pressure altitude data, valid non-zero Geometric Altitude Source data
and valid non-zero velocity data to the ADS-B System.
Discontinue the input of Geometric Altitude Source data and verify that
subsequent Airborne Velocity Messages contain a Difference From Barometric
Altitude subfield with a value of ZERO (0) (binary 000 0000). Stop the input of
Barometric Altitude data and verify that the value of this field remains ZERO (0)
in subsequent Airborne Velocity Messages.
Begin the input of only Geometric Altitude Source data and verify that the value
of this field remains ZERO (0) in subsequent messages of this type.
Step 2: Difference from Barometric Altitude Verification No Differences
Re-start the input of Barometric Altitude data, and set the inputs so that the
Geometric Altitude Source data input and the Barometric Altitude input both
represent the exact same altitude (in feet); i.e., the difference between the two
altitude values is ZERO.
20xx, RTCA, Inc.

457
Verify that the Difference From Barometric Altitude subfield in subsequent

Airborne Velocity Messages is set to ONE (1) (binary 000 0001, representing a
Difference of ZERO).
Step 3: Difference from Barometric Altitude Verification Discrete Values
Adjust the value of the Barometric Altitude input data so that the set of possible
inputs includes a value that represents an altitude at least 3,140 feet above the
chosen value and a value that represents an altitude at least 3,140 feet below the
chosen value. Adjust the Geometric Altitude Source data input to represent the
same altitude as that chosen for the Barometric Altitude input.
Increase the value of the Geometric Altitude Source data input while keeping the
Barometric Altitude constant so that the Geometric Altitude Source data
difference input assumes each value from Table 2-138. Verify that for each
Altitude Source Data Difference in Table 2-138 that the system generates
Airborne Velocity Messages with the Difference From Barometric Altitude
subfield in each message set equal to the corresponding binary coding value from
the table.
Table 2-138: Difference from Barometric Altitude Discrete Values

Difference From Barometric Altitude
Coding Meaning
(Binary) (Decimal) (Geometric (GNSS or INS) Altitude Source data Difference in feet)
Additionally verify that for every 25 feet increase in the difference between the
two, the Difference From Barometric Altitude subfield in subsequent Airborne
Velocity Messages of TYPE 19 is incremented by one from the previous value
(i.e., that the value of the Difference From Barometric Altitude subfield
corresponds to the decimal coding values given in the table in the above
referenced section).
Verify that the Difference From Barometric Altitude subfield in the output
message is not incremented until the difference in the input values reaches a
number corresponding to an integer multiple of 25 feet with an accuracy of 12.5
feet.
Step 4: Difference from Barometric Altitude Verification - Part 4
Continue to increase the value of the Geometric Altitude Source Data input.
20xx, RTCA, Inc.

458
Verify that, for values that are greater than 3,125 feet above the Barometric
Altitude, but less than or equal to 3,137.5 feet above the Barometric Altitude, the
Difference From Barometric Altitude subfield continues to be set to 126
(binary 111 1110).
Continue to increase the value of the Geometric Altitude Source data input.
Verify, for values representing an altitude greater than 3,137.5 feet above the
barometric altitude, up to the maximum possible input value, that the transmitter
continues to generate Airborne Velocity Messages and that the Difference From
Barometric Altitude subfield for all such messages is set to 127 (binary 111
1111).
Step 5: Difference from Barometric Altitude Verification - Part 5

is input to the transmitter to indicate Up or Down, the following
value of the Difference From Barometric Altitude Sign Bit, the
following step must be performed.
Repeat steps 3 through 5, but this time decreasing the value of the Geometric
Altitude Source data input, rather than increasing it.


(2.2.3.2.6.2.1)

(2.2.3.2.6.2.2)

Subtype=2 (2.2.3.2.6.2.3, 2.2.5.1.18)
20xx, RTCA, Inc.

459

(2.2.3.2.6.2.4)

(2.2.3.2.6.2.5, 2.2.5.1.19)
2.4.3.2.6.2.6 Verification of East/West Direction Bit Subfield in Airborne Velocity Messages -

Subtype=2 (2.2.3.2.6.2.6)
2.4.3.2.6.2.7 Verification of East/West Velocity Subfield in Airborne Velocity Messages -

Subtype=2 (2.2.3.2.6.2.7, 2.2.5.1.12)
The following test procedures verify that the East/West Velocity subfield in Airborne
Velocity Messages is correctly set according to the coding specified.
Step 1: East/West Velocity Verification Data Not Available

information in 2.2.3.3.2.5, ADS-B Velocity Message Broadcast Rate) by
providing East/West Velocity input data with a value greater than 1022 knots. Set
the ADS-B Transmitting Subsystem to Airborne status.
Discontinue East/West Velocity data and verify that when East/West Velocity
Data is not provided to the ADS-B Transmitting Subsystem, the East/West
Velocity Subfield in output Airborne Velocity Messages Subtype=2 is set to
ZERO (binary 00 0000 0000).
Step 2: East/West Velocity Verification Velocity Equal ZERO
Set up the ADS-B Transmitting Subsystem as above and set the East/West
Velocity input to represent a velocity of ZERO knots. Verify that the East/West
Velocity Subfield in subsequent Airborne Velocity Messages Subtype=2 is set
to ONE (1) (binary 00 0000 0001).
20xx, RTCA, Inc.

460
Step 3: East/West Velocity Verification Discrete Values
Verify that for each integer East/West Velocity input value in knots identified in
Table 2-139 that the system generates Airborne Velocity Messages with the
East/West Velocity Subfield set equal to the corresponding binary coding value
in the table.
Table 2-139: East/West Velocity Discrete Values

East/West Velocity (supersonic)
Coding Meaning
(Binary) (Decimal) (E/W Velocity in knots)
01 0101 0101 341 E/W Velocity = 1,360 knots
Verify that for 4 knot increases in the input value, the East/West Velocity
subfield in subsequent Airborne Velocity Messages of TYPE 19 is incremented
by one from the previous value (i.e., that the value of the East/West Velocity
subfield binary values corresponds to the values given in the table in the above
referenced section).
Verify that the East/West Velocity subfield in the output message is not
incremented to the next higher integer value until the input velocity value reaches
a number corresponding to an even multiple of 4 knots.
Step 4: East/West Velocity Verification Maximum Velocity
Continue to increase the value of the East/West Velocity Data input.
Verify that, for values greater than or equal to 4084 knots but less than or equal to
4086 knots, the output East/West Velocity subfield continues to be set to 1022
(binary 11 1111 1110).
Continue to increase the value of the East/West Velocity input.
Verify, for every input value representing an East/West Velocity greater than 4086
knots, up to the maximum possible input value, that the transmitter continues to
generate Airborne Velocity Messages with a TYPE subfield equal to 19, a
20xx, RTCA, Inc.

461
Subtype subfield equal to 2, and that the East/West Velocity subfield for all
such messages is set to 1023 (binary 11 1111 1111).
Step 5: East/West Velocity Verification Input Resolution
If the input data used to establish the East/West Velocity subfield has more
resolution than that required by the East/West Velocity subfield, then this step
shall be used to ensure that the accuracy of the data is maintained such that it is
not worse than LSB, where the LSB is the least significant bit of the
East/West Velocity subfield. If the input data field that is used to determine the
output value of the East/West Velocity subfield does not have finer resolution
than that required by the East/West Velocity subfield, proceed to Step 6.
Enter an input value corresponding to an eastward velocity of 6 knots.
Verify that the value of the East/West Velocity subfield in the output message is
either 2 (binary 00 0000 0010, representing 4 knots) or 3 (binary 00 0000
If the input field used to establish the East/West Velocity subfield does not have
resolution finer than 2 knots, skip to step 6. Otherwise (indicating that East/West
Velocity input resolution is finer than 2 knots), let Z be equal to the smallest
possible value that can be represented by the number of bits in the input field (i.e.,
Z is the value of the least significant bit of the input field).
Set the value of the input field to correspond to an eastward velocity of (6 Z).
Velocity Message is 2 (binary 00 0000 0010, representing 4 knots).
Set the value of the input field to correspond to an eastward velocity of (6 + Z).
Velocity Message is 3 (binary 00 0000 0011, representing 8 knots).
Note: If the resolution of the East/West Velocity input is such that an
eastward velocity of 6 knots cannot be represented (but is still finer
than 4 knots, e.g., a resolution of 1.75 knot increments), then values
corresponding to eastward velocity must be tested, and the output
examined for each value to confirm that the output is within 2 knots
(inclusive) of the input value.
is input to the transmitter to indicate East or West, the following
value of the East/West Direction Bit, the following step must be
performed.
20xx, RTCA, Inc.

462
Repeat Steps 3, 4 and 5 so that each step is performed with East/West Velocity
input data indicating travel in both EAST and WEST directions, i.e., replace the
word eastward with westward in steps 3, 4 and 5.
2.4.3.2.6.2.8 Verification of North/South Direction Bit Subfield in Airborne Velocity Messages -

Subtype=2 (2.2.3.2.6.2.8)
2.4.3.2.6.2.9 Verification of North/South Velocity Subfield in Airborne Velocity Messages -

Subtype=2 (2.2.3.2.6.2.9, 2.2.5.1.13)
This test procedure verifies that the North/South Velocity subfield in Airborne Velocity
Messages is correctly set.
Step 1: North/South Velocity Verification Data Not Available

information in 2.2.3.3.2.5, ADS-B Velocity Message Broadcast Rate) by
providing North/South Velocity input data with a value greater than 1022 knots.
Set the ADS-B Transmitting Subsystem to Airborne status. Discontinue

North/South Velocity data and verify that when North/South Velocity Data is not
provided to the ADS-B Transmitting Subsystem, the North/South Velocity
subfield in output Airborne Velocity Messages Subtype=2 is set to ZERO
(binary 00 0000 0000).
Step 2: North/South Velocity Verification Velocity Equal ZERO
Setup the ADS-B Transmitting Subsystem as above and set the North/South
Velocity input to represent a velocity of ZERO knots. Verify that the
North/South Velocity subfield in subsequent Airborne Velocity Messages
Subtype=2 is set to ONE (1) (binary 00 0000 0001).
Step 3: North/South Velocity Verification Discrete Values
Verify that for each integer North/South Velocity input value in knots identified in
Table 2-140 that the system generates Airborne Velocity Messages with the
North/South Velocity subfield set equal to the corresponding binary coding
value in the table.
20xx, RTCA, Inc.

463
Table 2-140: North/South Velocity Discrete Values

North/South Velocity (supersonic)
Coding Meaning
(Bianry) (Decimal) (N/S Velocity in knots)
01 0101 0101 341 N/S Velocity = 1,360 knots
Verify that for 4 knot increases in the input value, the North/South Velocity
subfield in subsequent Airborne Velocity Messages of TYPE 19 is incremented
by one from the previous value (i.e., that the value of the North/South Velocity
subfield corresponds to the values given in the table in the above referenced
section).
Verify that the North/South Velocity subfield in the output message is not
incremented until the input value reaches a number corresponding to an even
multiple of 4 knots.
Step 4: North/South Velocity Verification Maximum Velocity
Continue to increase the value of the North/South Velocity Data input.
Verify that, for discrete values greater than or equal to 4084 knots but less than or
equal to 4086 knots, the North/South Velocity subfield continues to be set to
1022 (binary 11 1111 1110).
Continue to increase the value of the North/South Velocity input.
Verify that for discrete input values representing a North/South Velocity greater
than 4086 knots, up to the maximum possible input value, that the transmitter
continues to generate Airborne Velocity Messages with a TYPE subfield equal to
19, a Subtype subfield equal to 2, and that the North/South Velocity
subfield for all such messages is set to 1023 (binary 11 1111 1111).
Step 5: North/South Velocity Verification Input Resolution
If the input data used to establish the North/South Velocity subfield has finer
resolution than that required by the North/South Velocity subfield, then this step
shall be used to ensure that the accuracy of the data is maintained such that it is
20xx, RTCA, Inc.

464
not worse than LSB, where the LSB is the least significant bit of the
North/South Velocity subfield. If the input data field that is used to determine
the output value of the North/South Velocity subfield does not have finer
resolution than that required by the North/South Velocity subfield, proceed to
Step 6.
Enter an input value corresponding to a northward velocity of 6 knots.
Verify that the value of the North/South Velocity subfield in the output message
is either 2 (binary 00 0000 0010, representing 4 knots) or 3 (binary 00 0000
If the input field used to establish the North/South Velocity subfield does not
have resolution finer than 2 knots, skip to step 6. Otherwise (North/South
Velocity input resolution is finer than 2 knots), let Z be equal to the smallest
possible value that can be represented by the number of bits in the input field (i.e.,
Z is the value of the least significant bit of the input field). Set the value of the
input field to correspond to a northward velocity of (6 Z).
Set the value of the input field to correspond to a northward velocity of (6 + Z).
Note: If the resolution of the North/South Velocity input is such that a
northward velocity of 6 knots cannot be represented (but is still finer
than 4 knots, e.g., a resolution of 1.75 knot increments), then values
corresponding to northward velocity must be tested, and the output
examined for each value to confirm that the output is within 2 knots
(inclusive) of the input value.
input to the transmitter to indicate North or South, the following
interpretation of its inputs in order to determine the correct output value
of the North/South Direction Bit, the following step must be performed.
Repeat Steps 3, 4 and 5 so that each step is performed with North/South Velocity
input data indicating travel in both NORTH and SOUTH directions, i.e., replace
the word northward with southward in steps 3, 4 and 5.
Subtype=2 (2.2.3.2.6.2.10, 2.2.5.1.14)
20xx, RTCA, Inc.

465
Subtype=2 (2.2.3.2.6.2.11, 2.2.5.1.14)

(2.2.3.2.6.2.12, 2.2.5.1.14)
2.4.3.2.6.2.13 Verification of Reserved Bits-B Subfield in Airborne Velocity Subtype=2 Messages

(2.2.3.2.6.2.13)
Velocity Messages - Subtype=2 (2.2.3.2.6.2.14)

Messages - Subtype=2 (2.2.3.2.6.2.15)


(2.2.3.2.6.3.1)

(2.2.3.2.6.3.1, 2.2.3.2.6.3.2)
20xx, RTCA, Inc.

466

Subtype=3 (2.2.3.2.6.3.3, 2.2.5.1.18)

(2.2.3.2.6.3.4)

(2.2.3.2.6.3.5, 2.2.5.1.19)
2.4.3.2.6.3.6 Verification of Heading Status Bit Subfield in Airborne Velocity Messages -

Subtype=3 (2.2.3.2.6.3.6, 2.2.3.2.6.4.6, 2.2.5.1.15)
Airborne Velocity Messages Subtypes 3 and 4, with the Heading Status Bit
correctly set to ONE (1) if Heading information is available, and ZERO (0) if it is not.
Step 1: Heading Status Bit Verification Data Available

Messages Subtypes 3 and 4 by providing airspeed and heading information
at the nominal update rate. Provide the data externally at the interface to the ADS-
B system. Set up the system to enable broadcast of Airborne Velocity Messages
(see additional information in 2.2.3.3.2.5, ADS-B Velocity Message Broadcast
Rate). Set the ADS-B Transmitting Subsystem to Airborne status. Provide non-
zero airspeed data to the ADS-B System. This data should indicate non-
supersonic velocity (less than 1000 knots) for testing Subtype=3 messages, and
supersonic (greater than 1022 knots) for testing Subtype=4 messages. Provide
heading input data to the ADS-B Transmitting Subsystem, and verify that output
Airborne Velocity Messages have Message Bit 46 (ME Bit 14) correctly set to
ONE (1).
20xx, RTCA, Inc.

467
Step 2: Heading Status Bit Verification Data Not Available
Discontinue the input of heading information to the ADS-B Transmitting

Subsystem. Verify that subsequent Airborne Velocity Messages have Message
Bit 46 (ME Bit 14) correctly set to ZERO (0).
2.4.3.2.6.3.7 Verification of Heading Subfield in Airborne Velocity Messages - Subtype=3

(2.2.3.2.6.3.7, 2.2.3.2.6.4.7, 2.2.5.1.15)
This test will verify that the Heading subfield in Airborne Velocity Messages Subtypes
3 and 4 is correctly set according to the encoding in Table 2-40. These test procedures
are intended for use for Airborne Velocity Messages of Subtypes 3 and 4. The values
of the input Velocity data should be set so as to generate Airborne Velocity Messages for all
appropriate Subtype fields.
Step 1: Heading Verification Data Equal ZERO

Messages Subtype=3 and 4 by providing airspeed information at the nominal
up the system to enable broadcast of Airborne Velocity Messages (see additional
ADS-B Transmitting Subsystem to Airborne status. Provide valid, non-zero
airspeed data to the ADS-B System. This data should indicate non-supersonic
airspeed (less than 1022 knots) for testing Subtype=3 messages, and supersonic
airspeed (greater than 1022 knots) for testing Subtype=4 messages.
Provide heading input data with a value of ZERO to the ADS-B Transmitting
Subsystem, and verify that the output Heading subfield in subsequent Airborne
Velocity Messages is set to ZERO (binary 00 0000 0000). Also verify that the
Heading Status Bit is set to ONE.
Step 2: Heading Verification Discrete Values
This test will verify that the ADS-B Transmitting Subsystem properly encodes the
Heading data for positive direction values.
Begin increasing the input Heading data so that it assumes all values identified in
Table 2-141. Verify that the value transmitted in the Heading subfield of the
ADS-B Airborne Velocity Messages corresponds to the binary coding of the input
Heading in Table 2-141.
20xx, RTCA, Inc.

468
Table 2-141: Heading Subfield Discrete Values

Heading
Coding Meaning
(Binary) (Decimal) (Heading in degrees)
00 0000 0001 1 Heading = 0.3515625 degrees
00 0000 0010 2 Heading = 0.7031250 degrees
00 0000 0011 3 Heading = 1.0546875 degrees
00 0000 0101 5 Heading = 1.7578125 degrees
00 0000 1010 10 Heading = 3.5156250 degrees
00 0000 1111 15 Heading = 5.2734375 degrees
00 0101 0000 80 Heading = 28.1250000 degrees
00 0101 1010 90 Heading = 31.6406250 degrees
00 1010 0101 165 Heading = 58.0078125 degrees
00 1010 1010 170 Heading = 59.7656250 degrees
01 0101 0101 341 Heading = 119.8828125 degrees
01 1111 1111 511 Heading = 179.6484375 degrees
10 0000 0000 512 Heading = 180.0000000 degrees
10 0000 0001 513 Heading = 180.3515625 degrees
10 0000 0010 514 Heading = 180.7031250 degrees
10 0101 0101 597 Heading = 209.8828125 degrees
10 1010 1010 682 Heading = 239.7656250 degrees
11 0101 0101 853 Heading = 299.8828125 degrees
11 1010 1010 938 Heading = 329.7656250 degrees
11 1111 1110 1022 Heading = 359.2968750 degrees
11 1111 1111 1023 Heading = 359.6484375 degrees
Note: The resolution of the raw data used as input to establish the Heading subfield may
not be capable of setting values to exact multiples of 0.3515625 degrees. Where
this is the case, the input should be set to values as close to the required values as
possible.
Step 3: Heading Verification Incremental Checks

Note: If the resolution of the Heading input to the ADS-B Transmitting
Subsystem is exactly equal to 0.3515625 degrees, then this step shall not
apply. If the resolution of the Heading input to the ADS-B Transmitting
Subsystem is greater than 0.3515625 degrees, then the LSB rule given
in Note 2 of 2.2.3.2.6.3.7 shall apply, and this step shall be used to
ensure that the accuracy of the data is maintained such that it is not
worse than LSB, where the LSB is the least significant bit of the
Heading output subfield. In this case, this means that the output data
must be accurate to within 1/2 of 0.3515625 degrees, i.e., within
0.17578125 degrees.
Set up the ADS-B Transmitting Subsystem as in Step 1. Set the input heading to
0.3515625 degrees, and verify that the output Heading subfield is set to ONE
(00 0000 0001). Increase the input value by the smallest increment possible, so
that it assumes values greater than 0.3515625 degrees but less than 0.52734375
degrees.
20xx, RTCA, Inc.

469
Verify that for any value less than 0.52734375 degrees, the output of the
Heading subfield does not change.
Increase the input value to the smallest possible value that is greater than
0.52734375 degrees.
Verify that the output Heading subfield in subsequent output messages is set to
TWO (00 0000 0010).
Decrease the input so that it is set to the largest possible value that is less than
0.52734375 degrees.
Verify that the Heading subfield reverts to ONE (00 0000 0001).
2.4.3.2.6.3.8 Verification of Airspeed Type Subfield in Airborne Velocity Messages - Subtype=3

(2.2.3.2.6.3.8, 2.2.3.2.6.4.8, 2.2.5.1.16, 2.2.5.1.17)
This test procedure will verify that the Airspeed Type subfield in Airborne Velocity
Messages, Subtypes 3 and 4 is correctly set to ZERO (0) to if the airspeed type is
Indicated Airspeed (IAS), and to ONE (1) if the Airspeed Type is True Airspeed (TAS).
Velocity Messages with the appropriate Subtype field.
Step 1: Airspeed Type Verification Indicated Airspeed

Messages Subtypes 3 and 4 by providing airspeed and heading information
B system. Set up the system to enable broadcast of Airborne Velocity Messages
(see additional information in 2.2.3.3.2.5, ADS-B Velocity Message Broadcast
Rate). Set the ADS-B Transmitting Subsystem to Airborne status. Provide non-
zero airspeed and heading data to the ADS-B System. This data should indicate
non-supersonic velocity (less than 1022 knots) for testing Subtype=3 messages,
and supersonic (greater than 1022 knots) for testing Subtype=4 messages.
Provide input airspeed data to the ADS-B Transmitting Subsystem in the form of
Indicated Airspeed (IAS) data. Verify that the output Airborne Velocity
Messages have an Airspeed Type subfield with a value of ZERO (0).
Step 2: Airspeed Type Verification True Airspeed
Discontinue the input of IAS data to the ADS-B Transmitting Subsystem and
instead provide input airspeed data in the form of True Airspeed (TAS) data.
20xx, RTCA, Inc.

470
Verify that subsequent Airborne Velocity Messages have an Airspeed Type

subfield with a value of ONE (1).
2.4.3.2.6.3.9 Verification of Airspeed Subfield in Airborne Velocity Messages - Subtype=3

(2.2.3.2.6.3.9, 2.2.5.1.16, 2.2.5.1.17)
This test procedure will verify that the Airspeed subfield in Airborne Velocity Messages
Subtypes 3 and 4 is correctly encoded by the ADS-B Transmitting Subsystem.
Step 1: Airspeed Verification Data Not Available

Messages by providing airspeed and heading information at the nominal update
rate. Provide the data externally at the interface to the ADS-B system. Set up the
system to enable broadcast of Airborne Velocity Messages - Subtype=3 (see
additional information in 2.2.3.3.2.5, ADS-B Velocity Message Broadcast
Rate). Set the ADS-B Transmitting Subsystem to Airborne status. Provide valid
non-zero, non-supersonic airspeed and heading data to the ADS-B System.
Discontinue Airspeed data and verify that when Airspeed data is not provided to
the ADS-B Transmitting Subsystem, the Airspeed subfield in subsequent
Airborne Velocity Messages Subtype=3 is set to ZERO (binary 00 0000 0000).
Step 2: Airspeed Verification Data Equal to ZERO
Setup the ADS-B Transmitting Subsystem as above and set the Airspeed input to
represent a velocity of ZERO knots. Verify that the Airspeed subfield in
subsequent Airborne Velocity Messages Subtype=3 is set to ONE (1) (binary 00
0000 0001).
Step 3: Airspeed Verification Discrete Values
Verify for each integer Airspeed (expressed in knots) in Table 2-142, that the
system generates Airborne Velocity Messages with TYPE 19 and subtype 3
and that the Airspeed subfield coding in each such message is set equal to the
corresponding binary coding value in the table.
20xx, RTCA, Inc.

471
Table 2-142: Discrete Values for Airspeed (subsonic)

Airspeed (IAS or TAS) (subsonic)
Coding Meaning
(Binary) (Decimal) (Airspeed in knots)
00 0000 0010 2 Airspeed = 1 knot
00 0000 0101 5 Airspeed = 4 knots
00 0000 1010 10 Airspeed = 9 knots
00 0000 1111 15 Airspeed = 14 knots
00 0101 0000 80 Airspeed = 79 knots
00 0101 1010 90 Airspeed = 89 knots
00 1010 0101 165 Airspeed = 164 knots
00 1010 1010 170 Airspeed = 169 knots
01 0101 0101 341 Airspeed = 340 knots
10 0101 0101 597 Airspeed = 596 knots
10 1010 1010 682 Airspeed = 681 knots
11 0101 0101 853 Airspeed = 852 knots
11 1010 1010 938 Airspeed = 937 knots
11 1111 1110 1022 Airspeed = 1021 knots
Step 4: Airspeed Verification - Part 4

input to the transmitter to indicate Indicated Airspeed or True
Airspeed, the following step is not necessary. However, if the
transmitter must perform some interpretation of its inputs in order to
determine the correct output value of the Airspeed Type, the following
Repeat Steps 2 and 3 so that each step is performed with Airspeed Type input data
indicating both Indicated Airspeed (IAS) and True Airspeed (TAS).
Subtype=3 (2.2.3.2.6.3.10, 2.2.5.1.14)
Subtype=3 (2.2.3.2.6.3.11, 2.2.5.1.14)

(2.2.3.2.6.3.12, 2.2.5.1.14)
20xx, RTCA, Inc.

472
2.4.3.2.6.3.13 Verification of Reserved Bits-B Subfield in Airborne Velocity Messages Subtype=3

(2.2.3.2.6.3.13)



(2.2.3.2.6.4.1)

(2.2.3.2.6.4.1, 2.2.3.2.6.4.2)

Subtype=4 (2.2.3.2.6.4.3, 2.2.5.1.18)

(2.2.3.2.6.4.4)
20xx, RTCA, Inc.

473

(2.2.3.2.6.4.5, 2.2.5.1.19)
2.4.3.2.6.4.6 Verification of Heading Status Bit Subfield in Airborne Velocity Messages -

Subtype=4 (2.2.3.2.6.4.6, 2.2.5.1.15)
2.4.3.2.6.4.7 Verification of Heading Subfield in Airborne Velocity Messages - Subtype=4

(2.2.3.2.6.4.7, 2.2.5.1.15)
2.4.3.2.6.4.8 Verification of Airspeed Type Subfield in Airborne Velocity Messages - Subtype=4

(2.2.3.2.6.4.8, 2.2.5.1.16, 2.2.5.1.17)
2.4.3.2.6.4.9 Verification of Airspeeed Subfield in Airborne Velocity Messages - Subtype=4

(2.2.3.2.6.4.9, 2.2.5.1.16, 2.2.5.1.17)
This test will verify that the Airspeed subfield in Airborne Velocity Messages Subtypes
3 and 4 is correctly encoded by the ADS-B Transmitting Subsystem.
Step 1: Airspeed Verification Data Not Available

Messages by providing airspeed and heading information at the nominal update
rate. Provide the data externally at the interface to the ADS-B system. Set up the
system to enable broadcast of Airborne Velocity Messages - Subtype=4 (see
additional information in 2.2.3.3.2.5, ADS-B Velocity Message Broadcast
Rate). Set the ADS-B Transmitting Subsystem to Airborne status. Provide valid
non-zero airspeed and heading data to the ADS-B System.
Discontinue the input of Airspeed data and verify that when Airspeed data is not
provided to the ADS-B Transmitting Subsystem, the Airspeed subfield in
subsequent Airborne Velocity Messages Subtype=4 is set to ZERO (binary 00
0000 0000).
20xx, RTCA, Inc.

474
Step 2: Airspeed Verification Data Equal to ZERO
Setup the ADS-B Transmitting Subsystem as above and set the Airspeed input to
represent a velocity of ZERO knots. Verify that the Airspeed subfield in
subsequent Airborne Velocity Messages Subtype=4 is set to 1.
Step 3: Airspeed Verification Discrete Values
Verify for each integer Airspeed (expressed in knots) in Table 2-143, that the
system generates Airborne Velocity Messages with TYPE 19 and subtype 4
and that the Airspeed subfield coding in each such message is set equal to the
corresponding binary coding value in the table.
Table 2-143: Discrete Values for Airspeed (supersonic)

Airspeed (IAS or TAS) (supersonic)
Coding Meaning
(Binary) (Decimal) (Airspeed in knots)
00 0000 0010 2 Airspeed = 4 knots
00 0000 0101 5 Airspeed = 16 knots
00 0000 1010 10 Airspeed = 36 knots
00 0000 1111 15 Airspeed = 56 knots
00 0101 0000 80 Airspeed = 316 knots
00 0101 1010 90 Airspeed = 356 knots
00 1010 0101 165 Airspeed = 656 knots
00 1010 1010 170 Airspeed = 676 knots
01 0101 0101 341 Airspeed = 1,360 knots
10 0101 0101 597 Airspeed = 2,384 knots
10 1010 1010 682 Airspeed = 2,724 knots
11 0101 0101 853 Airspeed = 3,408 knots
11 1010 1010 938 Airspeed = 3,748 knots
11 1111 1110 1022 Airspeed = 4,084 knots
Verify that for 4 knot increases in the input value, that the Airspeed subfield in
subsequent Airborne Velocity Messages of TYPE 19 is incremented by one
from the previous value (i.e., that the value of the Airspeed subfield corresponds
to the values given in the table in the above referenced section).
Verify that the Airspeed subfield in the output message is not incremented until
the input value reaches a number corresponding to an even multiple of 4 knots.
Continue to increase the value of the Airspeed Data input.
Verify that for discrete values above or equal to 4084 knots but below or equal to
4086 knots, the Airspeed subfield continues to be set to 1022 (binary 11 1111
1110).
Continue to increase the value of the Airspeed input.
20xx, RTCA, Inc.

475
Verify that for discrete input values representing an Airspeed greater than 4086
knots, up to the maximum possible input value, that the transmitter continues to
generate Airborne Velocity Messages with a TYPE subfield equal to 19 and that
the Airspeed subfield for all such messages is set to 1023 (binary 11 1111
1111).

input to the transmitter to indicate Indicated Airspeed or True
Airspeed, the following step is not necessary. However, if the
transmitter must perform some interpretation of its inputs in order to
determine the correct output value of the Airspeed Type, the following
Repeat Steps 2, 3 and 4 so that each step is performed with Airspeed Type input
data indicating both Indicated Airspeed (IAS) and True Airspeed (TAS).
Subtype=4 (2.2.3.2.6.4.10, 2.2.5.1.14)
Subtype=4 (2.2.3.2.6.4.11, 2.2.5.1.14)

(2.2.3.2.6.4.12, 2.2.5.1.14)
2.4.3.2.6.4.13 Verification of Reserved Bits-B Subfield in Airborne Velocity Subtype=4 Messages

(2.2.3.2.6.4.13)
20xx, RTCA, Inc.

476

2.4.3.2.6.5 Verification of ADS-B Airborne Velocity Messages - Subtypes 5, 6, & 7 (2.2.3.2.6.5)

ADS-B Airborne Velocity Messages are not specified for Subtypes 5, 6 or 7 and shall
be considered to be reserved for future expansion of Velocity Information Type Messages.
Appropriate test procedures will be added to this document as these messages are specified.
2.4.3.2.7 Verification of ADS-B Periodic Status and Event-Driven (2.2.3.2.7)

Appropriate test procedures to validate the requirements of 2.2.3.2.7 are included in the
2.4.3.2.7.1 Verification of Target State and Status Messages (2.2.3.2.7.1)

2.4.3.2.7.1.1 Verification of TYPE Subfield in Target State and Status Messages (2.2.3.2.7.1.1)
These test procedures verify that the ADS-B Transmitting Subsystem correctly outputs
Target State and Status Messages with the correct TYPE subfield data content in Message
Bits 33 through 37 in DF=17 Messages for Transponder-Based Systems and DF=18
Messages for Non-Transponder-Based Systems. The TYPE subfield for the Target State
and Status Messages should contain the value 29.
The ADS-B Transmitting Subsystem determines and outputs the TYPE subfield based
upon the input it receives from the type of Navigational System source that may interface to
the system. The ADS-B Transmitting Subsystem may receive the TYPE subfield directly
through an external interface instead of dynamically determining the TYPE subfield.
Configure the ADS-B Transmitting Subsystem to transmit Target State and Status Messages
by providing valid trajectory information at the nominal update rate. Provide the data
externally at the interface to the ADS-B system. Set the ADS-B Transmitting Subsystem to
Airborne status.
Verify that the TYPE subfield in the ADS-B Message correctly matches the TYPE
subfield value of 29 (binary 11101). See Table 2-16.
20xx, RTCA, Inc.

477
2.4.3.2.7.1.2 Verification of the Subtype Subfield in Target State and Status Messages
(2.2.3.2.7.1.2)
The Subtype subfield in the Target State and Status Message is encoded in accordance
with Table 2-45.
Configure the ADS-B Transmitting Subsystem to transmit Target State and Status Messages
by providing valid trajectory information at the nominal update rate. Provide the data
externally at the interface to the ADS-B system. Set the ADS-B Transmitting Subsystem to
Airborne status.
Verify that the TYPE subfield in the ADS-B Message is set to a value of 29 (binary
11101) and that the Subtype subfield is set to a value of ONE (binary 01).
2.4.3.2.7.1.3 Verification of the Target State and Status (Subtype=1) Format (2.2.3.2.7.1.3)
Appropriate test procedures required to validate the requirements of 2.2.3.2.7.1.3 are
included in 2.4.3.2.7.1.3.1 through 2.4.3.2.7.1.3.12.
2.4.3.2.7.1.3.1 Verification of the SIL Supplement Subfield in Target State and Status Messages
(2.2.3.2.7.1.3.1, 2.2.3.2.7.2.14, 2.2.5.1.41)
The SIL Supplement (Source Integrity Level Supplement) subfield is a 1-bit (ME bit 8,
Message bit 40) field that defines whether the reported SIL probability is based on a per
hour probability or a per sample probability as defined in Table 2-46. The purpose of
the following test procedure is to verify that the SIL Supplement subfield is being set
appropriately.
Step 1: Target State and Status Message Initialization
Via the appropriate interface, provide the ADS-B Transmitting Subsystem with
valid Mode Control Panel Selected Altitude data in order to initialize transmission
of Target State and Status Messages.
Step 2: Verification of SIL Supplement for Per Hour Probability
Via the appropriate data input interface, provide the ADS-B Transmitting
Subsystem with valid data indicating that the integrity of the geometric position
source is being established on a Per Hour basis.
20xx, RTCA, Inc.

478
Note: If an actual interface is not used to provide SIL Supplement

information, then ensure that a GNSS position source is being used to
provide geometric positon data for the purpose of establishing position in
the Airborne and Surface Position messages. (See 2.2.5.1.42).
Verify that the SIL Supplement subfield (ME bit 8, Message bit 40) in the
Target State and Status Messages is set to ZERO (0).
Step 3: Verification of SIL Supplement for Per Sample Probability
source is being established on a Per Sample basis.

information, then ensure that a Non-GNSS position source is being used
to provide geometric positon data for the purpose of establishing position
in the Airborne and Surface Position messages. (See 2.2.5.1.42).
Target State and Status Messages is set to ONE (1).
2.4.3.2.7.1.3.2 Verification of the Selected Altitude Type Subfield in Target State and Status
Messages (2.2.3.2.7.1.3.2)
Appropriate test procedures to verify setting of the Selected Altitude Type subfield in the
Target State and Status Messages are provided in 2.4.3.2.7.1.3.3.
2.4.3.2.7.1.3.3 Verification of the MCP/FCU Selected Altitude or FMS Selected Altitude Subfield in
Target State and Status Messages (2.2.3.2.7.1.3.3, 2.2.5.1.42)
The purpose of the following procedure is to verify that Selected Altitude data is properly
reported in accordance with 2.2.3.2.7.1.3.3.
Step 1: Setup of MCP / FCU Selected Altitude Data
For each line Item # in Table 2.4.3.2.7.1.3.3-1, via the appropriate interface,
provide the ADS-B Transmitting Subsystem with Mode Control Panel Selected
Altitude having a value as indicated in the Data Value (feet) Column in Table
2.4.3.2.7.1.3.3-1.
20xx, RTCA, Inc.

479
Table 2.4.3.2.7.1.3.3-1: MCP/FCU Selected Altitude in Target State and Status Messages (ARINC
Label 102)
Generic MCP / FCU Target State and Status
Selected Altitude Input (BNR) Encoding of MCP / FCU Selected Altitude
Item
Type
# Data Value TYPE Decimal Value Binary Value
of Status
(feet) (bit 9) (feet) (bit 10 ------ 20)
Value
1 Basic Valid 43,648.00 0 43,648.00 101 0101 0101
2 Basic Valid 21,792.00 0 21,792.00 010 1010 1010
3 Basic Valid 23,352.00 0 23,352.00 011 0111 0111
5 Basic Valid 65,472.00 0 65,472.00 111 1111 1111
6 Basic Rounded (1/4 LSB) 52,392.00 0 52,384.00 110 0110 0110
8 Invalid Invalid 21,792.00 0 0.00 000 0000 0000
Step 2: Setup of FMS Selected Altitude Data
For each line Item # in Table 2.4.3.2.7.1.3.3-2, via the appropriate interface,
provide the ADS-B Transmitting Subsystem with FMS Selected Altitude having a
value as indicated in the Data Value (feet) Column in Table 2.4.3.2.7.1.3.3-2.
Provide at least one data value from Table 2.4.3.2.7.1.3.3-2 while provided the
data for Line Item #1 through 7 in Table 2.4.3.2.7.1.3.3-1. Do not provide any
data from Table 2.4.3.2.7.1.3.3-2 when providing data for Line Item #8 in Table
2.4.3.2.7.1.3.3-1.
Table 2.4.3.2.7.1.3.3-2: FMS Selected Altitude in Target State and Status Messages (ARINC Label
102)
Generic FMS Target State and Status
Selected Altitude Input (BNR) Encoding of FMS Selected Altitude
Item
Type
# Data Value TYPE Decimal Value Binary Value
of Status
(feet) (bit 9) (feet) (bit 10 ------ 20)
Value
1 Basic Valid 37,088.00 1 37,088.00 100 1000 1000
2 Basic Valid 13,600.00 1 13,600.00 001 1010 1010
3 Basic Valid 22,880.00 1 22,880.00 010 1100 1100
5 Basic Valid 60,032.00 1 60,032.00 111 0101 0101
8 Invalid Invalid 13,600.00 1 0.00 000 0000 0000
Step 3: Verification of MCP / FCU Selected Altitude Data
For each line Item # given in Table 2.4.3.2.7.1.3.3-1, verify that Target State and
Status Messages are properly transmitted having:
(1). Selected Altitude Type, (bit 9), set as indicated in the TYPE (bit 9)
Column of Table 2.4.3.2.7.1.3.3-1.
20xx, RTCA, Inc.

480
(2). Selected Altitude Binary Value, set as indicated in the Binary Value (bit
10 --- 20) Column of Table 2.4.3.2.7.1.3.3-1.
Step 4: Discontinue MCP / FCU Selected Altitude Data
Discontinue the provisioning of all MCP / FCU Selected Altitude data as was
provided in Step 1, e.g., Table 2.4.3.2.7.1.3.3-1.
Step 5: Verification of FMS Selected Altitude Data
For each line Item # given in Table 2.4.3.2.7.1.3.3-2, verify that Target State and
(1). Selected Altitude Type, (bit 9), set as indicated in the TYPE (bit 9)
Column of Table 2.4.3.2.7.1.3.3-2, and
(2). Selected Altitude Binary Value, set as indicated in the Binary Value (bit
10 --- 20) Column of Table 2.4.3.2.7.1.3.3-2.
Step 6: Discontinue FMS Selected Altitude Data
Discontinue the provisioning of all MCP / FCU Selected Altitude data as was
provided in Step 1, e.g., Table 2.4.3.2.7.1.3.3-1.
Step 7: Verification of Selected Altitude Data Data Lifetime
At least 5 seconds after the execution of Step f, verify that Target State and
(1). Selected Altitude Type, (bit 9), set to ZERO (0).
(2). Selected Altitude Binary Value, set to ZERO (0).
2.4.3.2.7.1.3.4 Verification of the Barometric Pressure Setting (Minus 800 millibars) Subfield in
Target State and Status Messages (2.2.3.2.7.1.3.4, 2.2.5.1.43)
The purpose of the following procedure is to verify that Selected Altitude data is properly
reported in accordance with 2.2.3.2.7.1.3.4.
Step 1: Setup of Barometric Pressure Setting Data
For each line Item # in Table 2.4.3.2.7.1.3.4, via the appropriate interface, provide
the ADS-B Transmitting Subsystem with Barometric Pressure Setting data having
a value as indicated in the Data Value (millibars) Column in Table
2.4.3.2.7.1.3.4.
20xx, RTCA, Inc.

481
Table 2.4.3.2.7.1.3.4: Barometric Pressure Setting in Target State and Status Messages (ARINC Label
234)
Target State and Status
Barometric Pressure Setting Data Input
Encoding of Barometric Pressure Setting
Item
Type Decimal Value
# Data Value Binary Value
of Status (millibars)
(millibars) (bit 21 ------ 29)
Value (minus 800)
1 Basic Valid 942.7 142.4 0 1011 0001
2 Basic Valid 923.2 123.2 1 0101 0101
3 Basic Valid 1208.0 408.0 1 1111 1111
5 Basic Valid 927.2 127.2 0 1010 1010
6 Basic Rounded (1/4 LSB) 1099.4 299.2 1 0111 0111
7 Basic Rounded (1/2 LSB) 1099.6 300.0 1 0111 1000
8 Invalid Valid 1209.6 0.000 0 0000 0000
9 Invalid Valid 799.6 0.000 0 0000 0000
10 Invalid Invalid 927.2 0.00 0 0000 0000
Step 2: Verification of Barometric Pressure Setting Data
For each line Item # given in Table 2.4.3.2.7.1.3.4, verify that Target State and
Status Messages are properly transmitted having Barometric Pressure Setting
Binary Value set as indicated in the Binary Value (bit 21 --- 29) Column of
Table 2.4.3.2.7.1.3.4.
Step 3: Discontinue Barometric Pressure Setting Data
Discontinue the provisioning of all Barometric Pressure Setting data as was

provided in Step 1, e.g., Table 2.4.3.2.7.1.3.4.
Step 4: Verification of Barometric Pressure Setting Data Data Lifetime
At least 5 seconds after the execution of Step 3, verify that Target State and
Status Messages are properly transmitted having Barometric Pressure Setting
Binary Value (bit 21 --- 29) set to ZERO (0).
2.4.3.2.7.1.3.5 Verification of the Selected Heading Status Subfield in Target State and Status
Messages (2.2.3.2.7.1.3.5)
Appropriate test procedures to verify setting of the Selected Heading Status in Target State
and Status Messages are provided in 2.4.3.2.7.1.3.7.
2.4.3.2.7.1.3.6 Verification of the Selected Heading Sign Subfield in Target State and Status
Messages (2.2.3.2.7.1.3.6)
Appropriate test procedures to verify setting of the Selected Heading Sign in Target State
and Status Messages are provided in 2.4.3.2.7.1.3.7.
20xx, RTCA, Inc.

482
2.4.3.2.7.1.3.7 Verification of the Selected Heading Subfield in Target State and Status Messages
(2.2.3.2.7.1.3.7, 2.2.5.1.44)
The purpose of the following test procedure is to verify that Selected Heading data provided
in the Target State and Status Messages are properly reported in accordance with
2.2.3.2.7.1.3.5 through 2.2.3.2.7.1.3.7.
Step 1: Setup of Selected Heading Data
For each line Item # in Table 2.4.3.2.7.1.3.7, via the appropriate interface, provide
the ADS-B Transmitting Subsystem with Selected Heading data having a value as
indicated in the Data Value (degrees) Column in Table 2.4.3.2.7.1.3.7.
Table 2.4.3.2.7.1.3.7: Selected Heading Data in Target State and Status Messages (ARINC Label
101)
Generic Selected Heading Input (degrees) Target State and Status
[binary (BNR)] Encoding of Selected Heading
Item
Type Decimal Sign
# Sense Data Value Sense Status Binary Value
of Status Value (bit 31)
(Note 1) (degrees) (Note 1) (bit 30) (bits 32 --- 39)
Value (degrees) (Note 2)
-120.234375 -120.234375
1 Basic Valid West (CCW) Left 1 1 0101 0101
(239.765625) (239.765625)
2 Basic Valid East (CW) 119.53125 Right 119.53125 1 0 1010 1010
-24.609375 -24.609375
(335.390625) (335.390625)
-90.000 -90.000
(270.000) (270.000)
5 Basic Valid East (CW) 135.000 Right 135.000 1 0 1100 0000
Rounded -120.0585937 -120.234375
6 Valid West (CCW) Left 1 1 0101 0101
(1/4 LSB) (239.94140625) (239.765625)
Rounded -119.8828125 -119.53125
7 Valid West (CCW) Left 1 1 0101 0110
(1/2 LSB) (240.1171875) (240.46875)
Not
8 Invalid Invalid East (CW) 119.53125 0.000 0 0 0000 0000
Applicable
Notes:
1. Input data Sense refers to (a) Positive, being Clockwise (CW), commonly meaning East of North, or (b) Negative, being Counter-
Clockwise (CCW), commonly meaning West of North.
2. The Sign Bit is 1 for Negative, West of North, or Counter-Clockwise (CCW). The Sign Bit is 0 for Positive, East of North, or
Clockwise (CW).
Step 2: Verification of Selected Heading Status, Sign, and Data
For each line Item # given in Table 2.4.3.2.7.1.3.7, verify that Target State and
20xx, RTCA, Inc.

483
(1). Selected Heading Status (ME bit 30, Message Bit 62) set as indicated in
the Status (bit 30) Column of Table 2.4.3.2.7.1.3.7,
(2). Selected Heading Sign (ME bit 31, Message Bit 63) set as indicated in
the Sign (bit 31) Column of Table 2.4.3.2.7.1.3.7, and
(3). Selected heading Data (ME bits 32 through- 39, Message bits 64
through- 71) set as indicated in the Binary Value (bits 32---39) Column
of Table 2.4.3.2.7.1.3.7.
Step 3: Discontinue Selected Heading Data
Discontinue the provisioning of all Selected Heading information (e.g., Status,

Sign, Data) as was provided in Step 1, e.g., Table 2.4.3.2.7.1.3.7.
Step 4: Verification of Selected Heading Data Lifetime
At least 5 seconds after the execution of Step 3, verify that Target State and
Status Messages are properly transmitted having all Selected Heading information
(ME bits 30 through 39, Message bits 62 through 71) set to ZERO (0).
2.4.3.2.7.1.3.8 Verification of the NACP Subfield in Target State and Status Messages
(2.2.3.2.7.1.3.8, 2.2.5.1.34)
The NACP subfield in the Target State and Status Message is encoded in accordance with
Table 2-71.
Step 2: Verification of NACP Transmission
each of the EPU values indicated in Table 2-71.
Verify that for each input NACP parameter that is specified by the EPU value in
Table 2-71, that the system generates ADS-B Messages with the NACP subfield
set equal to the corresponding binary coding value shown in Table 2-71.
20xx, RTCA, Inc.

484
Step 3: Verification of NACP Data Lifetime
Rerun the Test Procedure in Step 1. Remove the data source input for valid
trajectory information for a period of at least 5 seconds. Verify that ME bits 40
through 43 in the Target State and Status Message are set to a value of ZERO
(binary 0000).
2.4.3.2.7.1.3.9 Verification of the NICBARO Subfield in Target State and Status Messages
(2.2.3.2.7.1.3.9, 2.2.5.1.35)
The NICBARO (Barometric Altitude Integrity Code) subfield in the Target State and Status
Message is used to indicate whether or not the barometric pressure altitude being reported in
the Airborne Position Message (2.2.3.2.3) has been cross checked against another source
of pressure altitude. The NICBARO subfield is encoded in accordance with Table 2-73, as
specified in the Aircraft Operational Status Message.
Step 2: Verification of NICBARO Transmission
Operationally select Barometric Pressure Altitude as the Primary Altitude

information and verify that the ALTITUDE TYPE field in ME bit 10 is set to
ZERO (0).
Input to the ADS-B Transmitting Subsystem the condition that signifies that the
barometric pressure altitude has been crosschecked against another source of
pressure altitude. Verify that the NICBARO field ME bit 44 is set to ONE (1).
barometric pressure altitude has NOT been crosschecked against another source of
pressure altitude. Verify that the NICBARO field ME bit 44 is set to ZERO (0).
Step 3: Verification of NICBARO Data Lifetime
Rerun the Test Procedure in Step 1. Remove the data source input used in step 1
for a period of at least 5 seconds. Verify that ME bit 44 in the Target State and
Status Message is set to a value of ZERO (0).
20xx, RTCA, Inc.

485
2.4.3.2.7.1.3.10 Verification of the SIL Subfield in Target State and Status Messages
(2.2.3.2.7.1.3.10, 2.2.3.2.7.2.9, 2.2.5.1.40)
position exceeding the radius of containment defined by the NIC, without alerting, assuming
no avionics faults. The SIL will address the Signal-in-Space, and will be the higher of the
faulted or fault free probability of the Signal-In-Space causing the NIC radius of
containment to be exceeded. The SIL subfield is encoded in accordance with Table 2-72,
as specified in the ADS-B Aircraft Operational Status Message. For installations where the
SIL value is being dynamically updated, if an update has not been received from an on-
board data source for SIL within the past 5 seconds, then the SIL subfield is set to a value of
ZERO (0), indicating Unknown.
Step 2: Verification of SIL Transmission
valid data to establish each of the SIL conditions indicated in Table 2-72.
Verify that for each SIL parameter input condition that is specified by the
probability of exceeding the RC Integrity Radius of Containment without detection
(i.e., the value in Table 2-72), that the system generates ADS-B Messages with the
SIL subfield set equal to the corresponding binary coding value shown in Table
2-72.
Step 3: Verification of SIL Data Lifetime
Rerun the Test Procedure in Step 1. Remove the data source input in step 1 for a
period of at least 5 seconds. Verify that ME bits 45 and 46 in the Target State and
Status Message are set to a value of ZERO (binary 00).
2.4.3.2.7.1.3.11 Verification of the Status of MCP/FCU Mode Bits Subfield in Target State and
Status Messages (2.2.3.2.7.1.3.11, 2.2.5.1.45)
The purpose of the following test procedure is to verify that Status of MCP / FCU Mode
Bits information is properly reported in accordance with 2.2.3.2.7.1.3.11.
20xx, RTCA, Inc.

486
Step 1: Initialization with NO Status
Ensure that No information is being provided to the ADS-B Transmitting

Subsystem that would indicate the status of Autopilot Engaged, VNAV Mode
Engaged, Altitude Hold Mode, or Approach Mode.
Step 2: Verification of NO Status
Verify that Target State and Status Messages are properly transmitted having the
Status of MCP / FCU Mode Bits subfield (ME bit 47, Message bit 79) set to
ZERO (0).
Step 3: Initialization with Status
Via the appropriate interface(s), provide the ADS-B Transmit Subsystem with the
status of Autopilot Engaged, VNAV Mode Engaged, Altitude Hold Mode and
Approach Mode with the status indicating Not Engaged for each of the status
parameters.
Step 4: Verification of Provided Status
Status of MCP / FCU Mode Bits subfield (ME bit 47, Message bit 79) set to
ONE (1).
2.4.3.2.7.1.3.12 Verification of the Autopilot Engaged Subfield in Target State and Status Messages
(2.2.3.2.7.1.3.12, 2.2.5.1.45)
The purpose of the following test procedure is to verify that Autopilot Engaged
information is properly reported in accordance with 2.2.3.2.7.1.3.12.
Step 1: Initialization with Autopilot NOT Engaged
the information necessary to establish that the Autopilot is Not Engaged.
Step 2: Verification of Autopilot NOT Engaged
Autopilot Engaged subfield (ME bit 48, Message bit 80) set to ZERO (0).
20xx, RTCA, Inc.

487
Step 3: Initialization with Autopilot Engaged
Via the appropriate interface, provide the ADS-B transmit subsystem with the
information necessary to establish that the Autopilot is Engaged.
Step 4: Verification of Autopilot Engaged
Autopilot Engaged subfield (ME bit 48, Message bit 80) set to ONE (1).
2.4.3.2.7.1.3.13 Verification of the VNAV Mode Engaged Subfield in Target State and Status
Messages (2.2.3.2.7.1.3.13, 2.2.5.1.45)
The purpose of the following test procedure is to verify that VNAV Mode Engaged
Step 1: Initialization with VNAV Mode Not Engaged
information necessary to establish that the VNAV Mode is Not Engaged.
Step 2: Verification of VNAV Mode Not Engaged
VNAV Mode Engaged subfield (ME bit 49, Message bit 81) set to ZERO (0).
Step 3: Initialization with VNAV Mode Engaged
information necessary to establish that the VNAV Mode is Engaged.
Step 4: Verification of VNAV Mode Engaged
VNAV Mode Engaged subfield (ME bit 49, Message bit 81) set to ONE (1).
2.4.3.2.7.1.3.14 Verification of the Altitude Hold Mode Subfield in Target State and Status Messages
(2.2.3.2.7.1.3.14, 2.2.5.1.45)
The purpose of the following test procedure is to verify that Altitude Hold information is
properly reported in accordance with 2.2.3.2.7.1.3.14.
20xx, RTCA, Inc.

488
Step 1: Initialization with Altitude Hold Mode Not Engaged
information necessary to establish that the Altitude Hold Mode is Not Engaged.
Step 2: Verification of VNAV Not Engaged
Altitude Hold subfield (ME bit 50, Message bit 82) set to ZERO (0).
Step 3: Initialization with Altitude Hold Mode Engaged
information necessary to establish that the Altitude Hold Mode is Engaged.
Step 4: Verification of Altitude Hold Mode Engaged
Altitude Hold subfield (ME bit 50, Message bit 82) set to ONE (1).
2.4.3.2.7.1.3.15 Verification of the Reserved for ADS-R Flag Subfield in Target State and Status
Messages (2.2.3.2.7.1.3.15)
ADS-B 1090ES Rebroadcast Messages are transmitted from a 1090ES ADS-B Ground
Station as a rebroadcast of an ADS-B Message that was received by that Ground Station on
an alternate ADS-B Data Link. The Airborne ADS-B Transmitting Subsystem will always
transmit a ZERO (0) in ME bit 51 of the Target State and Status Message.
These test procedures verify that ME bit 51 of the transmitted DF=17 Target State and
Status Message from an Airborne ADS-B Transmitting Subsystem is always ZERO (0).
Step 2: Verification of ADS-R Flag
Set the ADS-B Transmitting Subsystem to Airborne status. Verify that Target
State and Status Messages are broadcast with the ME bit 51 (Message bit 83) set
to ZERO (0).
20xx, RTCA, Inc.

489
2.4.3.2.7.1.3.16 Verification of the Approach Mode Subfield in Target State and Status Messages
(2.2.3.2.7.1.3.16, 2.2.5.1.45)
The purpose of the following test procedure is to verify that Approach Mode information
is properly reported in accordance with 2.2.3.2.7.1.3.16.
Step 1: Initialization with Approach Mode Not Engaged
the information necessary to establish that the Approach Mode is Not Engaged.
Step 2: Verification of Approach Mode Not Engaged
Approach Mode subfield (ME bit 52, Message bit 84) set to ZERO (0).
Step 3: Initialization with Approach Mode Engaged
information necessary to establish that the Approach Mode is Engaged.
Step 4: Verification of Approach Mode Engaged
Approach Mode subfield (ME bit 52, Message bit 84) set to ONE (1).
2.4.3.2.7.1.3.17 Verification of the TCAS Operational Subfield in Target State and Status Messages
(2.2.3.2.7.1.3.17, 2.2.5.1.48)
The purpose of the following test procedure is to verify that TCAS Operational
Step 1: Initialization with TCAS Not Operational
the information necessary to establish that TCAS is Not Operational.
Step 2: Verification of TCAS Not Operational
TCAS Operational subfield (ME bit 55, Message bit 85) set to ZERO (0).
20xx, RTCA, Inc.

490
Step 3: Initialization with TCAS Operational
information necessary to establish that TCAS is Operational.
Step 4: Verification of TCAS Operational
TCAS Operational subfield (ME bit 53, Message bit 85) set to ONE (1).
2.4.3.2.7.1.3.18 Verification of Reserved Bits in Target State and Status Messages (2.2.3.2.7.1.3.18)
The purpose of this test procedure is to verify that the Reserved bits (ME bits 54
through 56, Message bits 86 through 88) are set to ZERO (000) in this version of these
MOPS.
Step 2: Verification of Reserved Bits
Set the ADS-B Transmitting Subsystem to Airborne status. Verify that Target
State and Status Messages are broadcast with the ME bits 54 through 56
(Message bit 86 through 88) set to ZERO (0).
2.4.3.2.7.1.4 Verification of the Reserved for TYPE=29 and Subtype>1 Message Formats
(2.2.3.2.7.1.4)
No specific test procedures are required to validate 2.2.3.2.7.1.4.
2.4.3.2.7.2 Verification of Aircraft Operational Status Messages (2.2.3.2.7.2)

2.4.3.2.7.2.1 Verification of TYPE Code Subfield in Aircraft Operational Status Messages

(2.2.3.2.7.2.1)
These test procedures verify that the ADS-B Transmitting Subsystem correctly outputs
Aircraft Operational Status Messages with the correct TYPE Code subfield data content in
20xx, RTCA, Inc.

491
Message Bits 33 through 37 in DF=17 Messages for Transponder-Based Systems and

DF=18 Messages for Non-Transponder-Based Systems.
Configure the ADS-B Transmitting Subsystem to transmit Aircraft Operational Status

Messages. Verify that the output Aircraft Operational Status Messages have a TYPE Code
subfield which contains the value 31.
2.4.3.2.7.2.2 Verification of Subtype Code Subfield in Aircraft Operational Status Messages

(2.2.3.2.7.2.2, 2.2.5.1.20)
The Subtype Code subfield is used to indicate various subtypes of Aircraft Operational
Status Messages. As defined in these MOPS, Subtype=0 indicates Airborne participants
and Subtype=1 indicates Surface participants.

Messages. Set the ADS-B Transmitting Subsystem to Airborne Status. Verify that ME bits
6 through 8 are set to ZERO (binary 000) in the next output Aircraft Operational Status
Message.
Repeat this step setting the ADS-B Transmitting Subsystem to On-Ground status. Verify
that ME bits 6 through 8 are set to ONE (binary 001) in the next output Aircraft Operational
Status Message.
2.4.3.2.7.2.3 Verification of CAPABILITY CLASS (CC) Subfield in Aircraft Operational Status

Messages (2.2.3.2.7.2.3)
provided in the following subparagraphs.
2.4.3.2.7.2.3.1 Verification of the Reserved CC Code Subfield in Aircraft Operational Status

Message (2.2.3.2.7.2.3.1, 2.2.5.1.21)
Within the Capability Class subfield, bits are reserved for setting by future versions of these
MOPS. ADS-B equipment conforming to this version of these MOPS (RTCA DO-260B)
shall set these reserved bits to ALL ZEROs.

Messages by providing valid operational status information at the nominal update rate.
Provide the data externally at the interface to the ADS-B system. Verify that ME bits 9, 10,
13, 14 and 20 24 are set to ALL ZEROs.
20xx, RTCA, Inc.

492
2.4.3.2.7.2.3.2 Verification of the TCAS Operational CC Code Subfield in Aircraft Operational

Status Messages (2.2.3.2.7.2.3.2)
Appropriate test procedures required to validate the requirements of 2.2.3.2.7.2.3.2 are included in
2.4.3.2.7.1.3.17.
2.4.3.2.7.2.3.3 Verification of 1090ES IN CC Code Subfield in Aircraft Operational Status

Messages (2.2.3.2.7.2.3.3, 2.2.5.1.23)
The CC Code for 1090ES IN in Aircraft Operational Status Messages (TYPE=31,

Subtype=0 or 1) is a 1-bit field (ME bit 12, Message bit 44) that shall be set to ONE (1)
as specified in Table 2-63 if the transmitting aircraft has the capability to receive ADS-B
1090ES Messages. Otherwise, this CC code shall be ZERO (0).
Step 1: Verfification of the 1090ES IN CC Code Transmission
Configure the ADS-B Transmitting Subsystem to transmit Aircraft Operational

Status Messages (TYPE=31, Subtype=0, indicating airborne participants) by
providing valid operational status information at the nominal update rate. Set the
ADS-B Transmitting Subsystem to Airborne status. Provide appropriate data
externally at the interface to the ADS-B Transmitting Subsystem to indicate that
the installation IS NOT fitted with a properly functioning ADS-B 1090ES
Message Receiving Subsystem Verify that ME bit 12 is set to ZERO (0). Repeat
this step while indicating that the installation IS fitted with the capability to
receive ADS-B 1090ES Messages and verify that ME bit 12 is set to ONE (1).
Set the ADS-B Transmitting Subsystem to Surface status. Repeat the above
procedure while transmitting Aircraft Operational Status Messages with TYPE=31
and Subtype=1, indicating surface participants.
Step 2: Verification of 1090ES IN CC Code Data Lifetime
Rerun the Test Procedures in Step 1 for both the Airborne and Surface modes. In
each case, remove the data source input for 1090ES IN CC Code information
for a period of at least 5 seconds. Verify that ME bit 12 in the Aircraft
Operational Status Message is set to a value of ZERO (0).
20xx, RTCA, Inc.

493
2.4.3.2.7.2.3.4 Verification of the ARV Report Capability CC Code Subfield in Aircraft

Operational Status Messages (2.2.3.2.7.2.3.4, 2.2.5.1.24)
The ARV Report Capability subfield of the CC Codes subfield is a 1-bit Boolean flag that
expresses the capability of the ADS-B Subsystem for sending messages to support Air
Reference Velocity Reports, and is encoded as specified in Table 2-64.

Provide data externally at the interface to the ADS-B Transmitting Subsystem to indicate
that the installation DOES NOT have the capability to send messages that support Air
Referenced Velocity Reports.
Verify that the ME bit 15 (Message bit 47) is set to ZERO (0). Repeat this step while
indicating that the installation DOES have the capability to send messages that support Air
Referenced Velocity Reports, and verify that ME bit 15 (Message bit 47) is set to ONE
(1).
2.4.3.2.7.2.3.5 Verification of the TS Report Capability CC Code Subfield in Aircraft Operational

The Target State (TS) Report Capability subfield of the CC Codes subfield is a 1-bit
Boolean flag in the airborne format of the Aircraft Operational Status Message
(TYPE=31, Subtype=0) that expresses the capability of the ADS-B Subsystem for sending
messages to support Target State Reports, and is encoded as specified in Table 2-65.

that the installation DOES NOT have the capability to send messages that support Target
State Reports.
Verify that ME bit 16 (Message bit 48) is set to ZERO (0). Repeat this step while
indicating that the installation DOES have the capability to send messages that support
Target State Reports and verify that ME bit 16 (Message bit 48) is set to ONE (1).
20xx, RTCA, Inc.

494
2.4.3.2.7.2.3.6 Verification of the TC Report Capability CC Code Subfield in Aircraft Operational

The Trajectory Change (TC) Report Capability subfield of the CC Code subfield is a 2-bit
(ME bits 17 and 18) subfield in the airborne format of the Aircraft Operational Status
Message (TYPE=31, Subtype=0) and is defined in the ADS-B MASPS (RTCA DO-242A)
as specified in Table 2-66. For these MOPS the subfield is set to ZERO (binary 00).

Provide the data externally at the interface to the ADS-B system. Verify that ME bits 16
and 17 are set to ZERO (binary 00).
2.4.3.2.7.2.3.7 Verification of the Position Offset Applied CC Code Subfield in Surface Aircraft
Operational Status Messages (2.2.3.2.7.2.3.7)
The Position Offset Applied (POA) subfield of the CC Code subfield of the surface
format Aircraft Operational Status Message (TYPE=31, Subtype=1) is a 1-bit Boolean flag
that the ADS-B Transmitting Subsystem sets to ONE (1) as specified in Table 2-67 if the
position that it is transmitted in the ADS-B Surface Position Message (2.2.3.2.4) is known
to be the position of the ADS-B participants ADS-B Position Reference Point (RTCA DO-
242A, 3.4.4.9.7) rather than, for example, the position of the antenna of the navigation
receiver. Otherwise, the ADS-B Transmitting Subsystem sets this flag to ZERO (0).

that the installation transmits position in the ADS-B Surface Position Message that IS NOT
known to be referenced to the ADS-B Position Reference Point of the A/V. Verify that ME
bit 11 (Message bit 43) is set to ZERO (0).
Repeat this step while indicating that the installation transmits position in the ADS-B
Surface Position Message that IS known to be referenced to the ADS-B Position Reference
Point of the A/V. Verify that ME bit 11 (Message bit 43) is set to ONE (1).
20xx, RTCA, Inc.

495
2.4.3.2.7.2.3.8 Verification of the B2 Low CC Code Subfield in Aircraft Operational Status

Messages (2.2.3.2.7.2.3.8)
The B2 Low subfield (ME bit 15) of the CC Code subfield in the surface version of
the Aircraft Operational Status Message (TYPE=31, Subtype=1) is a 1-bit Boolean flag that
the ADS-B Transmitting Subsystem sets to ONE (1) if the Transmitting Subsystem is a
Non-Transponder-Based Transmitting Subsystem on a Ground Vehicle (Class B2)
transmitting with less than 70 watts of transmit power. Otherwise, this bit is set to ZERO
(0).
For a Non-Transponder-Based Class B2 Transmitting Subsystem known to have a

transmitting power of 70 watts or more, configure the Transmitting Subsystem to transmit
Aircraft Operational Status Messages by providing valid information at the nominal update
rate. Provide the data externally at the interface to the ADS-B Transmitting Subsystem to
enable transmission of Aircraft Operational Status Messages. Verify that ME bit 15
(Message bit 47) is set to ZERO (0).
For a Non-Transponder-Based Class B2 Transmitting Subsystem known to have a

transmitting power of less than 70 watts, configure the Transmitting Subsystem to transmit
Aircraft Operational Status Messages by providing valid information at the nominal update
rate. Provide the data externally at the interface to the ADS-B Transmitting Subsystem to
enable transmission of Aircraft Operational Status Messages. Verify that ME bit 15
(Message bit 47) is set to ONE (1).
2.4.3.2.7.2.3.9 Verification of NACV CC Code Subfield in Surface Aircraft Operational Status

Messages (2.2.3.2.7.2.3.9, 2.2.5.1.19)
The NACV subfield is used to indicate the Navigation Accuracy Category for Velocity as
specified in Table 2-25. These test procedures are intended for use for Surface Aircraft
Operational Status Messages for Version 2 ADS-B Transmit Subsystems.
Configure the ADS-B Transmitting Subsystem to transmit ADS-B Surface Aircraft

Operational Status Messages by providing velocity and operational status information at the
nominal update rate. Provide valid non-zero velocity data to the ADS-B System.
From an external source, input 95% accuracy figures of merit for horizontal velocity.
Verify that for each horizontal velocity error value in Table 2-25 that the system generates
ADS-B Surface Aircraft Operational Status Messages with the NACV subfield (ME bits
17 19, Message bits 49 51) set equal to the corresponding binary coding value shown for
the NACV subfield in Table 2-25.
20xx, RTCA, Inc.

496
2.4.3.2.7.2.3.10 Verification of UAT IN CC Code Subfield in Aircraft Operational Status Messages

(2.2.3.2.7.2.3.10, 2.2.5.1.22)
The UAT IN CC Code of the Aircraft Operational Status Messages (in ME bit 11,
TYPE=31, Subtype=0, for airborne participants and in ME bit 16, TYPE=31, Subtype=1,
for surface participants) is set to ONE in Aircraft Operational Status Messages if the
transmitting aircraft IS fitted with a properly functioning Universal Access Transceiver
(UAT) Receiving subsystem. Otherwise, this CC Code Subfield in Aircraft Operational
Status Messages is set to ZERO (0) if there is NO capability in the aircraft to receive ADS-
B UAT Messages.
Step 1: Verification of UAT IN CC Code Transmission

Status Messages by providing valid operational status information at the nominal
update rate. Provide appropriate data externally at the interface to the ADS-B
Transmitting Subsystem to indicate that the installation IS fitted with a properly
functioning ADS-B UAT Receiving Subsystem. Set the ADS-B Transmitting
Subsystem to Airborne status. Verify that ME bit 11 is set to ONE (1).
Repeat this step while indicating that the aircraft has NO UAT IN Receive
capability, and verify that ME bit 11 is set to ZERO (0).
Repeat this step again after setting the ADS-B Transmitting Subsystem to Surface
status, and verify that ME bit 16 is set to ZERO (0).
Step 2: Verification of UAT IN CC Code Data Lifetime
Set the ADS-B Transmitting Subsystem to Airborne status. Rerun the Test
Procedure in Step 1. Remove the data source input for UAT IN CC Code
information for a period of at least 5 seconds. Verify that ME bit 11 in the
Aircraft Operational Status Message is set to a value of ZERO (0).
Set the ADS-B Transmitting Subsystem to Surface status. Rerun the Test
Procedure in Step 1. Remove the data source input for UAT IN CC Code
information for a period of at least 5 seconds. Verify that ME bit 16 in the
2.4.3.2.7.2.3.11 Verification of NIC Supplement-C CC Code Subfield in Aircraft Operational Status

Messages (2.2.3.2.7.2.3.11)
Appropriate test procedures required to validate the requirements of 2.2.3.2.7.2.3.11 are
included in 2.4.3.2.7.2.6.
20xx, RTCA, Inc.

497
2.4.3.2.7.2.4 Verification of OPERATIONAL MODE (OM) Subfield in Aircraft Operational

Status Messages (2.2.3.2.7.2.4)
included in 2.4.3.2.7.2.4.1 through 2.4.3.2.7.2.4.4.
2.4.3.2.7.2.4.1 Verification of the OM Subfield Format Code in Aircraft Operational Status

Messages (2.2.3.2.7.2.4.1, 2.2.5.1.29)
The first two bits of the OM subfield (ME bits 25 and 26) are reserved for selecting one of
up to four OM subfield formats. For this version of these MOPS (RTCA DO-260A), the
OM subfield format code is set to ZERO (binary 00).

Provide the data externally at the interface to the ADS-B system. Verify that ME bits 25
and 26 are set to ZERO (binary 00).
2.4.3.2.7.2.4.2 Verification of the TCAS/ACAS Resolution Advisory Active OM Code Subfield in

Aircraft Operational Status Message (2.2.3.2.7.2.4.2, 2.2.5.1.30)
The ADS-B Transmitting Subsystem sets the TCAS/ACAS Resolution Advisory Active
(RA Active) Operational Mode Code to ZERO (0) as long as a TCAS II or ACAS
Resolution Advisory is known not to be in effect (i.e., an update has been received within
the last 2 seconds that indicates a TCAS/ACAS Resolution Advisory is not Active);
otherwise, it sets this OM code to ONE (1).
Step 1: Verification of RA Active Transmission

update rate. Provide data externally at the interface to the ADS-B Transmitting
Subsystem to indicate that the installation DOES NOT have an active
TCAS/ACAS Resolution Advisory in effect. Verify that ME bit 27 (Message bit
59) is set to ZERO (0)in the Aircraft Operational Status Messages.
Repeat this step while indicating that the installation DOES have an active
TCAS/ACAS Resolution Advisory in effect. Verify that the ME bit 27
(Message bit 59) is set to ONE (1).
20xx, RTCA, Inc.

498
Step 2: Verification of RA Active OM Code Data Lifetime
Rerun the Test Procedure in Step 1. Remove the data source input for RA Active
OM Code information for a period of at least 2 seconds. Verify that ME bit 27 in
the Aircraft Operational Status Message is set to a value of ZERO (0).
2.4.3.2.7.2.4.3 Verification of the IDENT Switch Active OM Code Subfield in Aircraft Operational
Status Message (2.2.3.2.7.2.4.3, 2.2.5.1.31)
The IDENT Switch Active Operational Mode code is a 1-bit subfield (ME bit 28,
message bit 60) of the OM Code subfield in Aircraft Operational Status Messages. Initially,
the IDENT Switch Active OM Code is set to ZERO (0). Upon activation of the IDENT
switch, the ADS-B Transmitting Subsystem sets this code to ONE (1) for a period of 18 1
seconds. Thereafter, the ADS-B Transmitting Subsystem sets this OM Code to ZERO (0).

that the installation has an INACTIVE IDENT switch.
Verify that ME bit 28 (Message bit 60)is set to ZERO (0). Repeat this step while indicating
that the installation has an ACTIVE IDENT switch. Verify that ME bit 28 (Message bit 60)
is set to ONE (1). Allow 18 1 second to pass and verify that ME bit 28 (Message bit 60)
has returned to a value of ZERO (0) in the next Aircraft Operational Status Message.
2.4.3.2.7.2.4.4 Verification of the bit Reserved for Receiving ATC Services OM Code Subfield in
Aircraft Operational Status Message (2.2.3.2.7.2.4.4)
ME bit 29, Message bit 61 of the OM Code subfield in Aircraft Operational Status
Messages shall be reserved for the Receiving ATC Services Operational Mode Code. If
implemented into future versions of these MOPS, an ADS-B Transmitting Subsystem would
set this OM Code to ONE when the ADS-B Transmitting Subsystem is Receiving ATC
Services, as indicated by an update having been received via an appropriate interface on
board the transmitting aircraft within the past 5 seconds. Otherwise, in this version of these
MOPS, this OM Code bit shall be set to ZERO.

Provide the data externally at the interface to the ADS-B system simulating a message from
an ADS-B Transmitting Subsystem. Verify that ME bit 29 is set to ZERO (0).
20xx, RTCA, Inc.

499
2.4.3.2.7.2.4.5 Verification of Single Antenna Flag OM Code Subfield in Aircraft Operational

Status Message (2.2.3.2.7.2.4.5, 2.2.5.1.49)
The purpose of this test procedure is to verify that the ADS-B Transmit subsystem properly
indicates the use of a Single Antenna in ME bit 30 (Message bit 62) in the OM Code of
Aircraft Operational Status Messages.
Step 1: Non-Diversity Configuration
For ADS-B Transmitting Subsystems that operate with a single antenna, configure
the system to broadcast Airborne Position Messages. Verify that the Single
Antenna subfield is set to ONE (1) at all times in the Airborne Position
Message.
Step 2: Diversity Configuration
For ADS-B Transmitting Subsystems that operate in the diversity mode, configure
the system to broadcast Airborne Position Messages. Verify that the Single
Antenna subfield is set to ZERO (0) at all times in the Airborne Position
Message.
Disable one antenna channel by whatever means that the ADS-B Transmitting
Subsystem utilizes to detect a non-functioning antenna channel. Verify that the
Single Antenna subfield is set to ONE (1) in the Airborne Position Message.
Repeat, except disable the alternate channel and verify that the Single Antenna
subfield is set to ONE (1) in the Airborne Position Message.
2.4.3.2.7.2.4.6 Verification of System Design Assurance OM Code Subfield in Aircraft Operational

Status Messages (2.2.3.2.7.2.4.6, 2.2.5.1.50)
The System Design Assurance (SDA) subfield is a 2-bit (ME bits 31 32, Message bits
63 64) field that defines the failure condition that the ADS-B system is designed to
support as defined in Table 2.2.3.2.7.2.4.6.
Step 1: Verification of System Design Assurance (SDA) OM Code Subfield

update rate. Provide data externally at the interface to the ADS-B Transmit
20xx, RTCA, Inc.

500
subsystem to establish each of the System Design Assurance (SDA) encoding

defined in Table 2.2.3.2.7.2.4.6.
Verify that each System Design Assurance (SDA) parameter input condition
that is identified in Table 2.2.3.2.7.2.4.6 that the system generates ADS-B Aircraft
Operational Status Messages with the System Design Assurance (SDA) subfield
set equal to the corresponding binary coding value indicated in Table
2.2.3.2.7.2.4.6.
Step 2: Verification of System Design Assurance (SDA) Data Lifetime
Rerun the Test Procedure in Step 1. Remove the data source input for System
Design Assurance (SDA) information for a period of at least 5 seconds. Verify
that the Aircraft Operational Status Messages are properly transmitted having the
System Design Assurance (SDA) subfield (ME bits 31 and 32, Message bits
63 and 64) set to ZERO (0).
2.4.3.2.7.2.4.7 Verification of the GPS Antenna Offset OM Code Subfield in Aircraft Operational
field in the OM Code Subfield of surface format Aircraft Operational Status Messages that
defines the position of the GPS antenna.
Blah Blah Blah ---- NEED TEST PROCEDURE HERE ZZZZZZZZZZZZ
2.4.3.2.7.2.4.8 Verification of the Reserved OM Code Subfield in Aircraft Operational Status

Messages (2.2.3.2.7.2.4.8)
Reserved bits, (ME bits 33 through 40, Message bits 65 through 72) in the OM Code
Subfield of surface format Aircraft Operational Status Messages are reserved for future
assignment. Until such future assignment, these bits shall be set to ZERO (0).
Step 1: Aircraft Operational Status Message Initialization
appropriate operational status data in order to initialize transmission of Aircraft
Operational Status Messages.
20xx, RTCA, Inc.

501
Step 2: Verification of Reserved Bits
Verify that Aircraft Operational Status Messages are broadcast with ME bits 33
through 40 (Message bits 65 through 72) set to ZERO (0).
2.4.3.2.7.2.5 Verification of ADS-B Version Number Subfield in Aircraft Operational Status

Message (2.2.3.2.7.2.5)
The ADS-B Version Number subfield is a 3-bit field (Message Bits 73 through 75, ME
Bits 41 through 43) that is used to indicate the ADS-B Version Number of the ADS-B
formats and protocols in use on the aircraft installation.

Messages at the nominal rate (see 2.2.3.3.2.6.2). Verify that the unit under test was built in
conformance with RTCA DO-260B. Verify that the Version Number subfield in the
Aircraft Operational Status Message is correctly set to binary 010 in Message Bits 73
through 75.
2.4.3.2.7.2.6 Verification of the NIC Supplement-A Subfield in Aircraft Operational Status

Messages (2.2.3.2.7.2.6)
The NIC Supplement-A subfield in the Aircraft Operational Status Message is a 1-bit
subfield (ME bit 44, Message bit 76) that, together with the TYPE subfield in Airborne
Position and Surface Position Messages, is used to encode the Navigation Integrity
Category (NIC) of the transmitting ADS-B participant.
Table 2-70 lists the possible NIC codes and the values of the TYPE Code subfield of the
Airborne and Surface Position Messages, and the NIC Supplement subfield that is used to
encode those NIC codes in messages on the 1090 MHz ADS-B data link.
Step 1: Verification of NIC Supplement Transmission

update rate. Provide the data externally at the interface to the ADS-B system.
Verify that for each input NIC parameter that is specified by the RC value in Table
2-70, that the system generates ADS-B Messages with the NIC Supplement-A
subfield (ME bit 44) set equal to the corresponding binary coding value shown
in Table 2-70. Do this for all TYPE Codes in Table 2-70 for both Airborne and
20xx, RTCA, Inc.

502
Step 2: Verification of NIC Supplement-A Data Lifetime
Rerun the Test Procedure in Step 1. Remove the data source input for NIC
Supplement-A for a period of at least 5 seconds. Verify that ME bit 44 in the
2.4.3.2.7.2.7 Verification of the Navigation Accuracy Category for Position (NACP) Subfield in
Aircraft Operational Status Messages (2.2.3.2.7.2.7)
The Navigation Accuracy Category for Position (NACP) is a 4-bit subfield of the ADS-B
Aircraft Operational Status Message (ME bits 45 to 48, Message bits 77 to 80) that
announces 95% accuracy limits for the horizontal position (and for some NACP values, the
vertical position) that is being currently broadcast in airborne position and surface position
messages. Table 2-71 specifies the accuracy limits for each NACP value.
Step 1: Verification of NACP Transmission

Verify that for each input NACP parameter that is specified by the EPU value in
Table 2-71, that the system generates ADS-B Messages with the NACP subfield
set equal to the corresponding binary coding value for the decimal value shown in
Table 2-71.
Step 2: Verification of NACP Data Lifetime
Rerun the Test Procedure in Step 1. Remove the data source input for NAC P for a
period of at least 5 seconds. Verify that ME bits 45 to 48 in the Aircraft
Operational Status Message are set to a value of ZERO (binary 0000).
2.4.3.2.7.2.8 Verification of the Geometric Vertical Accuracy (GVA) Subfield in Aircraft

Operational Status Messages (2.2.3.2.7.2.8)
The Geometric Vertical Accuracy (GVA) subfield of Subtype=0 Aircraft Operational

Status Message is a 2-bit field (ME bits 49-50, Message bits 81-82) defined in Table
2.2.3.2.7.2.8. The GVA field shall be set by using the Vertical Figure of Merit (VFOM)
(95%) from the GNSS position source used to encode the geometric altitude field in the
20xx, RTCA, Inc.

503
Step 1: Verification of GVA Transmission

update rate. Set the Vertical Figure of Merit (VFOM) field to each of the
following values in Table 2.4.3.2.7.2.8 and verify that the corresponding encoding
is set in the GVAQ field of the Aircraft Operational Status Message.
Table 2.4.3.2.7.2.8: Geometric Vertical Accuracy Validation Values

VFOM
Row GVA Encoding
(meters)
1 Invalid 0
2 30.0 1
3 44.5 1
4 45.5 0
5 327.1 0
Step 2: Verification of GVA Data Lifetime
Rerun Table 2.4.3.2.7.2.8, Row 2 from Step 1. Remove the data source input for
GVA for a period of at least 2 seconds. Verify that the GVA subfield of the
Aircraft Operational Status Message is set to ZERO (binary 00).
2.4.3.2.7.2.9 Verification of the Source Integrity Level (SIL) Subfield in Aircraft Operational
Status Messages (2.2.3.2.7.2.9)
The Source Integrity Level (SIL) is a 2-bit subfield of Subtype=0 ADS-B Aircraft
Operational Status Messages (ME bits 51 and 52, Message bits 83 and 84) that defines the
probability of the integrity containment region described by the NIC value being exceeded
for the selected geometric position source, including any external signals used by the source.
Table 2-72 defines the meaning of each SIL value. For installations where the SIL value is
being dynamically updated, if an update has not been received from an on-board data source
for SIL within the past 5 seconds, then the SIL subfield is set to a value of ZERO (0),
indicating Unknown.
Step 1: Verification of SIL Transmission

20xx, RTCA, Inc.

504
Verify that for each SIL parameter input condition that is specified by the
probability of exceeding the RC Integrity Containment Radius without detection
(i.e., the values in Table 2-72), that the system generates ADS-B Messages with
the SIL subfield set equal to the corresponding binary coding value shown in
Table 2-72.
Step 2: Verification of SIL Data Lifetime
Rerun the Test Procedure in Step 1. Remove the data source input for SIL for a
period of at least 5 seconds. Verify that ME bits 51 and 52 in the Aircraft
Operational Status Message are set to a value of ZERO (binary 00).
2.4.3.2.7.2.10 Verification of the Barometric Altitude Integrity Code (NICBARO) Subfield in

Aircraft Operational Status Messages (2.2.3.2.7.2.10)
The NICBARO (Barometric Altitude Integrity Code) is a 1-bit subfield of Subtype 0 ADS-
B Aircraft Operational Status Messages (ME bit 53, Message bit 85) that is used to
indicate whether or not the barometric pressure altitude being reported in the Airborne
Position Message (2.2.3.2.3) has been cross-checked against another source of pressure
altitude. The NICBARO subfield is encoded in accordance with Table 2-73.
Step 1: Verification of NICBARO Transmission

the ADS-B Transmitting Subsystem to the Airborne status.
Operationally select Barometric Pressure Altitude as the Primary Altitude

information and verify that the ALTITUDE TYPE field in ME bit 10 of the
Target State and Status Message is set to ZERO (0).
barometric pressure altitude has been crosschecked against another source of
pressure altitude. Verify that the NICBARO field ME bit 53 of the Aircraft
Operational Status Message is set to ONE (1).
barometric pressure altitude has NOT been crosschecked against another source of
pressure altitude. Verify that the NICBARO field ME bit 53 of the Aircraft
Operational Status Message is set to ZERO (0).
20xx, RTCA, Inc.

505
Step 2: Verification of NICBARO Data Lifetime
Rerun the Test Procedure in Step 1. Remove the data source input for valid
operational status information for a period of at least 5 seconds. Verify that ME
bit 44 in the Target State and Status Message is set to a value of ZERO (0).
Verify that the NICBARO field ME bit 53 of the Aircraft Operational Status
Message is set to ZERO (0).
2.4.3.2.7.2.11 Verification of the Aircraft/Vehicle Length and Width Code Subfield in Aircraft
Operational Status Messages (2.2.3.2.7.2.11)
The Aircraft/Vehicle (A/V) Length and Width Code Subfield is a 4-bit field (ME bits 21
to 24, Message bits 53 to 56) of the Aircraft Operational Status Messages (Subtype=1, for
Surface Participants). This field describes the amount of space that an aircraft or ground
vehicle occupies. The A/V Length and Width Code is based on the actual dimensions of the
transmitting aircraft or surface vehicle as specified in Table 2-74. Once the actual Length
and Width of the A/V has been determined, each A/V is assigned the smallest A/V Length
and Width Code from Table 2-74 for which the actual length is less than or equal to the
upper bound length for that Length/Width Code, and for which the actual width is less than
or equal to the upper bound width for that Length/Width Code.
Aircraft/Vehicle Length/Width Code 15 shall be used.

update rate. Provide the A/V Length and Width Code data externally at the
interface to the ADS-B system for an aircraft or vehicle greater than 25 meters in
length and greater than 25 meters in width.
Set up the system to enable broadcast of ADS-B Aircraft Operational Status

Messages with the air/ground status set to On-Ground according to the
conditions defined in 2.2.3.2.1.2.
Step 2: Verification of Transmission of A/V Length and Width Code ON GROUND
Verify that each of the A/V Length and Width Code values being transmitted by
the ADS-B Transmitting Subsystem, are encoded according to Table 2-74 in ME
bits 21 through 24 of the A/V Length and Width Code subfield. Verify that the
Position Offset Applied (POA) in ME bit 11 (Message bit 43) is set to either
ZERO (0) or ONE (1), based upon the input provided for the POA bit. Verify that
the A/V Length and Width Code is accurately reflected in the next nroadcast of
the Aircraft Operational Status Message.
20xx, RTCA, Inc.

506
Step 3: Verification of No Data Available
Set up the ADS-B Transmitting Subsystem as in Step 1 above, and then remove
the data input for the A/V Length and Width Codes. Verify that the value being
transmitted for the A/V Length and Width Code is set to ALL ZERO (binary
0000) in the next broadcast of the Aircraft Operational Status Message.
Step 4: Verification of Transmission of A/V Length and Width Code AIRBORNE
Set up the system to enable broadcast of ADS-B Messages with the the air/ground
status set to Airborne according to the conditions defined in 2.2.3.2.1.2.
Verify that the Aircraft Operational Status Message is being broadcast with
Subtype=0, and that the A/V Length and Width Code is not reflected in the next
broadcast of the Aircraft Operational Status Message.
2.4.3.2.7.2.12 Verification of the Track Angle/Heading Subfield in Aircraft Operational Status

Messages (2.2.3.2.7.2.12, 2.2.5.1.38)
The Track Angle/Heading subfield is a 1-bit field (ME bit 53, Message bit 85) of the
ADS-B Aircraft Operational Status Message (Subtype=1, for Surface Participants) that
allows correct interpretation of the data contained in the Heading/Ground Track subfield of
the ADS-B Surface Position Message (2.2.3.2.4) when the Air/Ground status is determined
to be in the On-Ground state as defined in 2.2.3.2.1.2. The encoding of the Track
Angle/Heading subfield is specified in Table 2-75.
Step 1: Verification of Track Angle Being Reported
Configure the ADS-B Transmitting Subsystem to transmit ADS-B Messages by

providing position information at the nominal update rate. Provide the data
externally at the interface to the ADS-B system and simulate data where the Track
Angle is being reported. Set up the system to enable broadcast of ADS-B
Messages at the nominal rate. Set the ADS-B Transmitting Subsystem to On-
Ground status. Verify that ME bit 53 (Message bit 85) is set to ZERO (0).
Step 2: Verification of Heading Being Reported

externally at the interface to the ADS-B Transmitting Subsystem and simulate
data where the Heading is being reported. Set up the system to enable broadcast
of ADS-B Messages at the nominal rate. Set the ADS-B Transmitting Subsystem
to On-Ground status. Verify that ME bit 53 (Message bit 85) is set to ONE (1).
20xx, RTCA, Inc.

507
2.4.3.2.7.2.13 Verification of the Horizontal Reference Direction (HRD) Subfield in Aircraft

Operational Status Messages (2.2.3.2.7.2.13, 2.2.5.1.39)
The Horizontal Reference Direction (HRD) subfield of the ADS-B Aircraft Operational
Status Messages is a 1-bit field (ME bit 54, Message bit 86) that indicates the reference
direction (true north or magnetic north) for horizontal directions such as heading, track
angle. The Horizontal Reference Direction subfield is encoded as specified in Table 2-76.
Step 1: Verification of True North Being Reported

externally at the interface to the ADS-B system and simulate data where the
(HRD) is True North. Verify that ME bit 54 (Message bit 86) is set to ZERO (0).
Step 2: Verification of Magnetic North Being Reported

externally at the interface to the ADS-B system and simulate data where the
(HRD) is Magnetic North. Verify that ME bit 54 (Message bit 86) is set to ONE
(1).
2.4.3.2.7.2.14 Verification of SIL Supplement Subfield in Aircraft Operational Status Messages

(2.2.3.2.7.2.14, 2.2.5.1.41)
55, Message bit 87) field that defines whether the reported SIL probability is based on a
per hour probability or a per sample probability as defined in Table 2-46. The purpose
of the following procedure is th verify that the SIL Supplement sufield is being set
appropriately.
Step 1: Aircraft Operation Status Message Initialization
valid operational status data in order to initialize transmission of Aircraft
Operational StatusMessages.
20xx, RTCA, Inc.

508
Step 2: Verification of SIL Supplement for Per Hour Probability
source is being established on a Per Hour basis.

information, then ensure that a GNSS position source is being used to
provide geometric positon data for the purpose of establishing position in
the Airborne and Surface Position messages. (See section 2.2.5.1.42).
Aircraft Operational Status Messages is set to ZERO (0).
Step 3: Verification of SIL Supplement for Per Sample Probability
source is being established on a Per Sample basis.

information, then ensure that a Non-GNSS position source is being used
to provide geometric positon data for the purpose of establishing position
in the Airborne and Surface Position messages. (See section 2.2.5.1.42).
Aircraft Operational Status Messages is set to ONE (1).
2.4.3.2.7.2.15 Verification of Reserved Subfields in Aircraft Operational Status Message

(2.2.3.2.7.2.15)
There are two Reserved subfields in the Aircraft Operational Status Message. The first is
a 2-bit field (ME bits 49 and 50, Message bits 81 and 82) of the Aircraft Operational
Status Message (Subtype=1, for Surface Participants). The second Reserved subfield is a
1-bit field (ME bit 56, Message bit 88) that is reserved for future applications.
Step 1: Reserved field for Surface Participants
Configure the ADS-B Transmitting Subsystem to transmit ADS-B Aircraft

Operational Status Messages with Subtype=1, by providing position information
B system. Verify that ME bits 49 and 50 (Message bits 81 and 82) are set to
ALL ZEROs. Verify that ME bit 56 (Message bit 88) is set to ZERO (0).
20xx, RTCA, Inc.

509
Step 2: Reserved field of all Aircraft Operational Status Messages
Configure the ADS-B Transmitting Subsystem to transmit ADS-B Aircraft

Operational Status Messages, by providing position information at the nominal
Verify that ME bit 56 (Message bit 88) is set to ZERO (0).
2.4.3.2.7.3 Verification of TYPE Code 23 ADS-B Messages for TEST (2.2.3.2.7.3)

2.4.3.2.7.4 Verification of Surface System Status Messages with TYPE Code=24 (2.2.3.2.7.4)
2.4.3.2.7.4.1 Verification of TYPE Code Subfield in Surface System Status Messages

(2.2.3.2.7.4.1)
2.4.3.2.7.4.2 Verification of SUBTYPE Code Subfield in Surface System Status Messages

(2.2.3.2.7.4.2)
2.4.3.2.7.4.3 Verification of Surface System Status Subfield in Surface System Status Messages
(2.2.3.2.7.4.3)
2.4.3.2.7.5 Verification of RESERVED TYPE Code 25 ADS-B Messages (2.2.3.2.7.5)



20xx, RTCA, Inc.

510
2.4.3.2.7.8 Verification of Extended Squitter Aircraft Status Messages with TYPE Code=28
(2.2.3.2.7.8)
2.4.3.2.7.8.1 Verification of Emergency/Priority Status and Mode A Code (Subtype=1)

(2.2.3.2.7.8.1)
2.4.3.2.7.8.1.1 Verification of Emergency/Priority Status Subfield in Aircraft Status Messages

(2.2.3.2.7.8.1.1)
The Extended Squitter Aircraft Status Message (TYPE=28) is used to provide additional
information regarding aircraft status. Subtype=1 is used specifically to provide the
Emergency / Priority status and the broadcast of the Mode A Code.
Specific formatting of the TYPE=28, Subtype=1 Message is provided in Figure 2-13 and
Appendix A, Figure A-8.
Configure the ADS-B Transmitting Subsystem to transmit Airborne Position Messages. Set
the ADS-B Transmitting Subsystem to Airborne status. Produce valid Airborne Position
Messages at the nominal rate with valid position and altitude data with the Surveillance
Status Subfield set to ONE (binary 01) to signify an emergency condition.
Verify that the ADS-B Transmitting Subsystem begins to transmit Extended Squitter
Aircraft Status Messages at the nominal rate with the TYPE Subfield set to 28 (binary 1
1100) and the Subtype Subfield set to ONE (binary 001).
Verify that for each integer Emergency/Priority Status input value in Table 2.2.3.2.7.8.1.1
the system generates Extended Squitter Aircraft Status Messages with the TYPE subfield set
to 28, the Subtype subfield set to ONE, and the Emergency/Priority Status subfield in each
such message set equal to the corresponding binary coding in Table 2.2.3.2.7.8.1.1.
2.4.3.2.7.8.1.2 Verification of Mode A (4096) Code Subfield in Aircraft Status Messages

(2.2.3.2.7.8.1.2)
The ADS-B Transmitting Subsystem will broadcast the Mode A (4096) Code setting in the
Extended Squitter Aircraft Status Message (TYPE=28, Subtype=1).
20xx, RTCA, Inc.

511
Configure the ADS-B Transmitting Subsystem to transmit Airborne Position Messages. Set
the ADS-B Transmitting Subsystem to Airborne status. Produce valid Airborne Position
Messages at the nominal rate with valid position and altitude data. Verify that the ADS-B
Transmitting Subsystem begins to transmit Extended Squitter Aircraft Status Messages at
the nominal rate with the TYPE Subfield set to 28 (binary 1 1100) and the Subtype Subfield
set to ONE (binary 001). Verify that the Mode A Code being broadcast is the one set by the
pilot.
2.4.3.2.7.8.2 Verification of the 1090ES TCAS RA Message (Subtype = 2) (2.2.3.2.7.8.2)

The Extended Squitter Aircraft Status Message (TYPE=28, Subtype=2) is used to provide
information regarding the TCAS Resolution Advisory (RA). Subtype=2 is used specifically
to provide the encoding of this information as specified in Figure 2-14. The content of the
fields of the 1090ES TCAS RA Message conform to the corresponding bits of transponder
Register 3016 and are specified in ICAO Annex 10, Vol IV, 4.3.8.4.2.2.1.
Step 1: Broadcasting the 1090ES TCAS RA Broadcast Message (2.2.3.2.7.8.2.a)

Messages by providing data at the nominal rate. Provide the data externally at the
interface to the ADS-B system. Set the ADS-B Transmitting Subsystem to
Airborne Status. Continue transmitting Airborne Position Messages at the
nominal rate with all parameters unchanged, ensuring that there is no TCAS RA
indicated. Verify that the Aircraft Status Message is not being broadcast. Insert
changed data into the ADS-B System to reflect a TCAS RA condition. Verify that
the ADS-B System begins to transmit an Aircraft Status Message with Subtype=2
within 0.5 seconds after the transponder notification of the initiation of the TCAS
RA. Verify that the ADS-B Transmitting Subsystem is broadcasting the Aircraft
Status TCAS RA Broadcast Messages at a spacing uniformly distributed over the
range of 0.75 to 0.85 seconds.
Step 2: Terminating the 1090ES Aircraft Status TCAS RA Broadcast Messages

(2.2.3.2.7.8.2.b)
Continue transmitting Aircraft Status Messages with Subtype=2 at the nominal

rate. Verify that the system generates ADS-B Aircraft Status Messages with
Subtype=2 with the appropriate subfields set equal to the corresponding binary
coding values that are specified from the transponder according to ICAO Annex
10, Volume IV, 4.3.8.4.2.2.
Set the RA Termination flag in the transponder to ONE (1), and verify that the
ADS-B System continues to transmit Aircraft Status Messages with Subtype=2 for
not less than 10 seconds. Verify that 10 seconds after the RA Termination flag
20xx, RTCA, Inc.

512
transitions from ZERO (0) to ONE (1) that the ADS-B System terminates
broadcast of the Aircraft Status Messages with Subtype=2.
Step 3: Priority of the 1090ES Aircraft Status TCAS RA Broadcast Message

(2.2.3.2.7.8.2.c)

interface to the ADS-B System. Set the ADS-B Transmitting Subsystem to
nominal rate with all parameters unchanged, ensuring that there is No
Emergency indicated. Verify that the Aircraft Status Message is not being
broadcast. Insert changed data into the ADS-B System indicating an emergency
condition specified in Table 2-57. Verify that the system generates ADS-B
Aircraft Status Messages with Subtype=1 with the Emergency/Priority Status
subfield set equal to the corresponding binary coding value that was provided as
input.

rate. Insert changed data into the ADS-B System to reflect a TCAS RA condition.
Verify that the ADS-B System begins to transmit an Aircraft Status Message with
Subtype=2 within 0.5 seconds after the transponder notification of the initiation of
the TCAS RA. Verify that the ADS-B Transmitting Subsystem is broadcasting
the Aircraft Status TCAS RA Broadcast Messages at a higher priority than the
Aircraft Status Emergency/Priority Status Messages with Subtype=1.

2.4.3.3 Verification of ADS-B Message Transmission Rates (2.2.3.3)

Note: One way to test for random uniformity is to use the Chi-squared Goodness-of-Fit
test. It is not important to have a tight confidence (85% would suffice), but it is
important to test both that the wait times are uniformly distributed and that the
difference between consecutive wait times (modulo 400 s) is uniformly distributed.
2.4.3.3.1 Verification of Transmission Rates for Transponder - Based Transmitters (2.2.3.3.1)

2.4.3.3.1.1 Verification of Transmission Rates Compliant with RTCA DO-181D (2.2.3.3.1.1)

(EUROCAE ED-73C)
Performance of ADS-B transmitters based on Mode S transponders shall validate Message
Transmit Rates in accordance with RTCA DO-181D 2.5.4.6.2 (no applicable section in
20xx, RTCA, Inc.

513
EUROCAE ED-73C), for each class of transponder specified in the latest version of FAA
TSO-C112.
2.4.3.3.1.2 Verification of Transmission Rates Not Specified in RTCA DO-181D (2.2.3.3.1.2)

(EUROCAE ED-73C)
When the transmission rate of a particular message type is not specified or is not tested in
RTCA DO-181D (EUROCAE ED-73C), then the Mode S Transponder-Based ADS-B
transmitters shall verify the message delivery performance for those messages in accordance
with 2.4.3.3.2 through 2.4.3.3.2.12 of this document for Stand Alone Transmitters. If
there is conflict between the requirements of RTCA DO-181D (EUROCAE ED-73C) and
this document, then the requirements of RTCA DO-181D (EUROCAE ED-73C) shall be
adhered to.
2.4.3.3.1.3 Verification of Maximum Transmission Rates for Transponder-Based Transmitters

(2.2.3.3.1.3)
Performance of ADS-B transmitters based on Mode S transponders shall validate maximum
transmission rates in accordance with RTCA DO-181D (EUROCAE ED-73C), for each
class of transponder specified in the latest version of FAA TSO-C112.
When the maximum transmission rate of a particular message type is not specified or is not
tested in RTCA DO-181D (EUROCAE ED-73C), then the Mode S Transponder-Based
ADS-B transmitters shall verify the maximum message delivery rate in accordance with
2.4.3.3.2.10 of this document for Stand Alone transmitters. If there is conflict between the
requirements of RTCA DO-181D (EUROCAE ED-73C) and this document, then the
requirements of RTCA DO-181D (EUROCAE ED-73C) shall be adhered to.
2.4.3.3.1.4 Verification of the ADS-B Periodic Status and Event-Driven Message Broadcast Rates
(2.2.3.3.1.4)
No specific test procedures are required to validate 2.2.3.3.1.4.
2.4.3.3.1.4.1 Verification of the ADS-B Target State and Status Message Broadcast Rates
(2.2.3.3.1.4.1)
The Target State and Status Message(s) (TYPE=29, 2.2.3.2.7.1) is initiated only when the
aircraft is airborne, and when vertical or horizontal target state information is available and
valid as a minimum.
Step 1: No ADS-B Message Broadcasts - On-Ground (2.2.3.3.1.4.1.a & 2.2.3.3.1.4.1.b)
Provide the ADS-B Transmitting Subsystem with valid data necessary for the
generation of ADS-B Target State and Status Messages (TYPE=29,
Subtype=ONE), including valid vertical target state information, valid horizontal
target state information, and with the On-Ground condition, and verify that the
20xx, RTCA, Inc.

514
ADS-B Transmitting Subsystem is not broadcasting any ADS-B Target State and
Status Messages.
Step 2: No ADS-B Message Broadcasts With Neither Vertical Nor Horizontal Valid
State Information (2.2.3.3.1.4.1.a & 2.2.3.3.1.4.1.b)
Change the status conditions to be invalid vertical target state information, invalid
horizontal target state information, and with the Airborne condition, and verify
that the ADS-B Transmitting Subsystem is not broadcasting any ADS-B Target
State and Status Messages.
Step 3: ADS-B Message Broadcasts With Only Vertical Valid State Information
(2.2.3.3.1.4.1.a & 2.2.3.3.1.4.1.b)
Change the status conditions to be valid vertical target state information, invalid
that the ADS-B Transmitting Subsystem is broadcasting ADS-B Target State and
Status Messages at a spacing uniformly distributed over the range of 1.2 to 1.3
seconds.
Step 4: ADS-B Message Broadcasts With Only Horizontal Valid State Information
(2.2.3.3.1.4.1.a & 2.2.3.3.1.4.1.b)
Change the status conditions to be invalid vertical target state information, valid
seconds.
2.4.3.3.1.4.2 Verification of the ADS-B Aircraft Operational Status Message Broadcast Rates
(2.2.3.3.1.4.2)
The rates at which the Aircraft Operational Status Messages (TYPE=31 and Subtype=0,
2.2.3.2.7.2) are broadcast is specified in 2.2.3.3.1.4.2.
Step 1: ADS-B Message Broadcasts ADS-B Target State and Status & Operational
Status Messages (2.2.3.3.1.4.2.a.ii)
generation of both Aircraft Operational Status Messages (TYPE=31,
Subtype=ZERO), and ADS-B Target State and Status Messages (TYPE=29,
Subtype=ONE), and verify that the ADS-B Transmitting Subsystem is
broadcasting both ADS-B Target State and Status Messages at a spacing
uniformly distributed over the range of 1.2 to 1.3 seconds, and Aircraft
Operational Status Messages at a spacing uniformly distributed over the range of
2.4 to 2.6 seconds.
20xx, RTCA, Inc.

515
Step 2: ADS-B Message Broadcasts ADS-B Target State and Status & Changes
(2.2.3.3.1.4.2.a.ii)
Separately initiate each of the four changes described in Condition 2 of

2.2.3.3.1.4.2, and for each separate case verify that the ADS-B Transmitting
Subsystem continues broadcasting Aircraft Operational Status Messages at a
spacing uniformly distributed over the range of 2.4 to 2.6 seconds.
Step 3a: ADS-B Message Broadcasts No ADS-B Target State and Status & With
Changes (2.2.3.3.1.4.2.b)
For each of the four cases decribed below, disable the tranmission of ADS-B
Target State and Status Messages, and perform Steps 3a and 3b in sequence before
proceeding to the next case.
Separately initiate each of the four changes described in Condition 2 of

2.2.3.3.1.4.2, and for each separate case verify that the ADS-B Transmitting
Subsystem changes the Aircraft Operational Status Messages broadcast spacing to
be uniformly distributed over the range of 0.75 to 0.85 seconds.
Step 3b: ADS-B Message Broadcasts No ADS-B Target State and Status & Following
Changes (2.2.3.3.1.4.2.a.i)
Before 23 seconds following the change for each separate case in Step 3a above,
verify that the ADS-B Transmitting Subsystem continues broadcasting Aircraft
0.75 to 0.85 seconds.
Step 3c: ADS-B Message Broadcasts No ADS-B Target State and Status & Following
Changes (2.2.3.3.1.4.2.a.i)
After 25 seconds following the change for each separate case in Step 3a above,
verify that the ADS-B Transmitting Subsystem reverts to broadcasting Aircraft
2.4 to 2.6 seconds.
Step 4: ADS-B Message Broadcasts in the On-Ground Condition Repeat Tests With
ADS-B Target State and Status & Operational Status Messages
Repeat the Step 1 setup, except replace the ADS-B Aircraft Operational Status
Messages (TYPE=31, Subtype=ZERO) with ADS-B Aircraft Operational Status
Messages (TYPE=31, Subtype=ONE), indicating an On-Ground condition, and
then verify that the ADS-B Transmitting Subsystem is not broadcasting ADS-B
Target State and Status Messages, and IS broadcastiung ADS-B Operational
seconds.
20xx, RTCA, Inc.

516
Step 5: ADS-B Message Broadcasts in the On-Ground Condition With Changes

(2.2.3.3.1.4.2)
Separately initiate each of the two (2) changes described in 2.2.3.3.1.4.2,

Condition 2 c and d, and for each separate case, verify that the ADS-B
Transmitting Subsystem continues broadcasting ADS-B Operational Status
Messages with Subtype=ONE, at a spacing uniformly distributed over the range of
2.4.3.3.1.4.3 Verification of the Extended Squitter Aircraft Status ADS-B Event-Driven Message
Broadcast Rate (2.2.3.3.1.4.3)
Appropriate test procedures to verify the broadcast rates of the Extended Squitter Aircraft
Status Messages are included in 2.4.3.3.1.4.3.1 through 2.4.3.3.1.4.3.2.
2.4.3.3.1.4.3.1 Verification of Emergency/Priority Status Message Broadcast Rates

The rate at which the Extended Squitter Aircraft Status Message (TYPE=28), (see
2.2.3.2.7.8) is broadcast using the Event-Driven protocol, varies depending on
ZZZZZZZZZZZ
Step 1: ADS-B ZZZZZZZZZZZ
generation of ADS-B Extended Squitter Aircraft Status Messages with
Emergency/Priority Status (TYPE=28, Subtype=1), ZZZZZZZZZZZ IT
MAY BE MORE APPROPRIATE TO MOVE SOME OF THE
FOLLOWING TEST STEPS TO THE FOLLOWING SUBPARAGRAPHS
AFTER INSPECTION ZZZZZZZZZZZ
Step 2: ADS-B ZZZZZZZZZZZ
Emergency/Priority Status (TYPE=28, Subtype=1), ZZZZZZZZZZZ
Step 3: ADS-B Message Broadcasts Emergency Status Termination
Terminate the Emergency State condition, and verify that the ADS-B Transmitting
Subsystem ceases broadcasting of the Extended Squitter Aircraft Status
Emergency/Priority Status Messages.
Step 4: ADS-B Message Broadcasts TCAS RA Broadcast
Provide the ADS-B Transmitting Subsystem with valid TCAS RA data necessary
for the generation of ADS-B Extended Squitter Aircraft Status TCAS RA
20xx, RTCA, Inc.

517
Broadcast Messages, and verify that the ADS-B Transmitting Subsystem is

broadcasting Extended Squitter Aircraft Status TCAS RA Broadcast Messages
(TYPE=28, Subtype=2) at a spacing uniformly distributed over the range of 0.75
to 0.85 seconds.
Step 5: ADS-B Message Broadcasts Termination of TCAS RA Broadcast
Terminate the TCAS RA condition, and verify that the ADS-B Transmitting
Subsystem ceases broadcasting of the Extended Squitter Aircraft Status TCAS RA
Broadcast Messages not less than 24 seconds after the RA Termination flag
transitions from ZERO (0) to ONE (1) (2.2.3.2.7.8.2).
2.4.3.3.1.4.3.1.1 Verification of Emergency/Priority Status Message Broadcast Rates When

Transmission of Mode A Code is Disabled (2.2.3.3.1.4.3.1.1)
ZZZZZZZZZZZ ZZZZZZZZZZZ ZZZZZZZZZZZ
2.4.3.3.1.4.3.1.2 Verification of Emergency/Priority Status Message Broadcast Rates When

Transmission of Mode A Code is Enabled (2.2.3.3.1.4.3.1.2)
2.4.3.3.1.4.3.2 Verification of TCAS RA Broadcast Message Broadcast Rate (2.2.3.3.1.4.3.2)

20xx, RTCA, Inc.

518
2.4.3.3.1.4.4 Verification of the TYPE Code=23 (TEST) ADS-B Event-Driven Message Broadcast
Rate (2.2.3.3.1.4.4)
The ADS-B Event-Driven TEST Messages with Subtype=0 is broadcast NOT MORE
THAN ONCE each time the Event-Driven Test Information is updated to the transponder.
equipment under test. Provide a method of detecting the RF pulses of the ADS-B broadcast
messages for display on an oscilloscope. Update the ADS-B Event-Driven TEST
Message and verify that it is broadcast only once. Repeat 10 times.
2.4.3.3.1.4.5 Verification of the TYPE Codes 24 27 and TYPE Code=30 ADS-B Event-Driven
Message Broadcast Rate (2.2.3.3.1.4.5)
In general, TYPE Codes 24 - 27 and TYPE Code=30 ADS-B Event-Driven Messages are
broadcast ONCE each time the Event-Driven TYPE Codes 24 - 27 or TYPE Code=30
information is updated to the transponder.
equipment under test. Provide a method of detecting the RF pulses of the ADS-B broadcast
messages for display on an oscilloscope.
These messages are reserved for future expansion. When implemented, perform the
following test:
Update each of the implemented TYPE Codes 24 through 27, or TYPE Code=30 ADS-B
Event-Driven Messages in turn and verify that it is broadcast only once. Repeat 10 times.
2.4.3.3.1.4.6 Verification of the ADS-B Message Transmission Scheduing (2.2.3.3.1.4.6)

included in 2.2.3.3.1.4.6.1.
20xx, RTCA, Inc.

519
2.4.3.3.1.4.6.1 Verification of the Event-Driven Message Scheduling Function (2.2.3.3.1.4.6.1)

The Event-Driven Message Scheduling Function ensures that the total Event-Driven
message rate does not exceed 2 transmitted messages per second. This is consistent with the
required overall maximum allowed transmission rate specified in 2.2.3.3.1.3. The
requirements for the rules of prioritizing the Event-Driven Message transmissions and
limiting the transmission rates are specified in 2.2.3.3.1.4.6.1. The broadcast rates for all
1090ES ADS-B Messages are summarized in Table 2-77.
The Measurement Procedures include the broadcast of the baseline Airborne Position,
Airborne Velocity and Aircraft ID & Category Messages at their specified nominal rates
(i.e, at combined nominal rate of 4.2 messages per second). The Measurement Procedure
would then define a specific timed sequence of events that would result in the generation
of a specific sequence of ADS-B Event-Driven Messages that is known to exceed the
nominal broadcast limit of 2 messages per second that is allocated for Event-Driven
Messages. The intent of this procedure is to cause the development of a queue of pending
ADS-B Event-Driven Messages. In order to load up the Event-Driven Message queue it
is suggested to use the Event-Driven Messages specified in Table 2-145.
Table 2-145: Event-Driven Messages to Test the Scheduling Function

Message TYPE
Message Message Priority Level
and Subtype Codes
Extended Squitter Aircraft
TYPE=28 and Subtype=1 1
Status (TCAS RA Broadcast)
Extended Squitter Aircraft
Status (Emergency/Priority TYPE=28 and Subtype=1 2
and Mode A Code)
It is necessary to inject data that would result in the Event-Driven Messages identified in
Table 2-145 being generated under the following test scenario. The test procedures shall
consist of the following steps performed as a continuous sequence of events. Commencing
with Step 2 below, it is expected that a pending ADS-B Message queue will develop that
must be managed by the ADS-B Message Scheduling Function.
Step 1: Place the ADS-B system in a test mode in which Test Messages (i.e., TYPE=23)
are generated at a nominal rate of 2 per second.
Verify: a) Test Messages are broadcast (see 2.2.3.3.1.4.4) at a nominal rate

of 2 per second over a 30 second test period.
b) A nominal total broadcast rate of < 6.2 messages per second over
the 30 second test period as in (a) above.
20xx, RTCA, Inc.

520
Step 2: With the ADS-B still in a test mode, as defined in Step 1 in which Test Messages
are being generated, inject Operational Status Message data and refresh at least
once per 0.5 second with no change in data contents.
Verify: a) Aircraft Operational Status Messages are broadcast at nominal

intervals of 0.8 seconds (see 2.2.3.3.1.4.2) over a 23 second test
period.
b) Aircraft Operational Status Messages are broadcast at nominal
intervals of 2.5 seconds after 25 seconds with no change in the
input data, verified over a 30 second test period (i.e., the test period
starts 2 seconds after the end of (a) above and continues for 30
seconds).
c) Test Messages are broadcast at nominal intervals of 1.25 seconds
over the same 23 second test period as (a) above and at nominal
intervals of 0.625 seconds over the subsequent 32 second test
period (i.e., ending coincident with the end of (b) above) and such
that the nominal total Event-Driven Message broadcast rate is a
nominal 2 messages per second.
d) A nominal total broadcast rate of < 6.2 messages per second over a
55 second test period.
Step 3: With the ADS-B still in a test mode, as defined in Step 2 in which Test Messages
and Aircraft Operational Status Messages are being generated, also inject Target
State and Status data and refresh at least once per 0.5 second.
Verify: a) Target State and Status Messages are broadcast at nominal intervals
of 1.25 seconds over a 30 second test period (see 2.2.3.3.1.4.1).
b) Aircraft Operational Status Messages are broadcast at nominal
intervals of 2.5 seconds verified over the same 30 second test
period as (a).
c) Test Messages are broadcast at nominal intervals of 1.25 seconds
over the same 23 second test period as (a) above and at nominal
intervals of 1.25 seconds over the same test period as (a) and (b)
above (i.e., such that the nominal total Event-Driven Message
broadcast rate for Event-Driven Messages is 2 per second).
d) A nominal total broadcast rate of 6.2 messages per second is not
exceeded over the same 30 second test period as (a), (b) and (c)
above.
20xx, RTCA, Inc.

521
Step 4: With the ADS-B system still in a test mode, as defined in Step 3, in which Test,
Aircraft Operational Status, and Target State and Status Messages are being
generated, inject Extended Squitter Aircraft Status Message data, and refresh at
least once per 1.0 second with no change in data contents.
Verify: a) Extended Squitter Aircraft Status Messages (TYPE=28, Subtype=1)

are broadcast at nominal intervals of 2.5 seconds (see
2.2.3.3.1.4.3) over a 30 second test period.
b) Target State and Status Messages are broadcast at nominal intervals
of 1.25 seconds over the same 30 second test period as (a).
c) Aircraft Operational Status Messages are broadcast at nominal
intervals of 2.5 seconds verified over the same 30 second test
period as (a) and (b).
d) Test Messages are broadcast at nominal intervals of 5 seconds over
the same 30 second test period as (a), (b) and (c) above.
e) A nominal total broadcast rate of 6.2 messages per second is not
exceeded over the same 30 second test period as (a), (b), (c) and
(d).
2.4.3.3.2 Verification of Transmission Rates for Stand Alone Transmitters (2.2.3.3.2)

Stand Alone Transmitters for Class A0 and Class B0 equipment are those implemented
independent of a Mode S transponder. Such transmitters must meet the transmission rate
requirements of 2.2.3.3.1.3 and the message update rate requirements specified in
2.2.3.3.2 and its subparagraphs. Extended Squitter messages must be transmitted at
random intervals that are uniformly distributed over the specified time interval using a time
quantization no greater than 15 milliseconds.
Equipment Required:
A Method of loading valid data for the generation of ADS-B Airborne Position, Surface
Position, Aircraft Identification and Category, Airborne Velocity, Target State and Status,
and Operational Status broadcast messages into the ADS-B Transmitting Subsystem under
test.
A Method of recording and time stamping all ADS-B Broadcast messages transmitted by
the ADS-B Transmitting Subsystem under test with the time stamping quantization being 15
milliseconds or less.
Step 1: ADS-B Message Broadcast Setup
Provide the ADS-B Transmitting Subsystem under test with all valid necessary
data for the generation of ADS-B Airborne Position, Aircraft Identification and
20xx, RTCA, Inc.

522
Category, Airborne Velocity, Target State and Status, and Operational Status
broadcast messages.
Verify that the ADS-B Transmitting Subsystem is broadcasting ADS-B Messages.
Step 2: ADS-B Message Recording and Time Stamping
Record and time stamp all ADS-B Messages that are broadcast by the ADS-B
Transmitting Subsystem for a period of not less than 10 minutes.
Note: At a maximum rate of 6.2 ADS-B Broadcast messages per second, the
recording period of 10 minutes should provide approximately 3,720
messages. That is, approximately 1,200 Airborne Position, 1,200
Airborne Velocity, 480 Target State and Status, 240 Operational Status,
120 Aircraft Identification and Category Messages, and up to 480 other
On-Condition Messages. This should provide a representative sample
size to support the subsequent statistical evaluations.
Step 3: Uniform Distribution Checks
Airborne Velocity, Target State and Status, and Operational Status Message types
transmitted, verify that the messages were uniformly and randomly distributed
over the specified range of transmission intervals for each particular message type.
Step 4: Interval Quantization Checks
Airborne Velocity, Target State and Status, and Operational Status Message types
transmitted, verify that the messages were distributed with the jitter spacing being
15 milliseconds or less between messages of equivalent type.
Step 5: Surface Condition checks (High Rate)
Repeat steps 1 -through- 4 using only ADS-B Surface Position and Aircraft
Identification and Category Messages using the high transmission rate (see
2.2.3.3.2.3 and 2.2.3.3.2.4) for each message type.
Step 6: Surface Condition checks (Low Rate)
Repeat steps 1 -through- 4 using only ADS-B Surface Position and Aircraft
Identification and Category messages using the low transmission rate (see
2.2.3.3.2.3 and 2.2.3.3.2.4) for each message type.
2.4.3.3.2.1 Verification of Power-On Initialization and Start Up (2.2.3.3.2.1)

20xx, RTCA, Inc.

523
2.4.3.3.2.1.1 Verification of Power-On Initialization (2.2.3.3.2.1.1)

Equipment Required
equipment under test. Provide a method of detecting the RF pulses of the ADS-B Broadcast
Message for display on an oscilloscope. Provide a Wide Band Dual Channel Oscilloscope
(HP 1710B, or equivalent).
Measurement Procedure
Step 1: No Data Available (2.2.3.3.2.1.1.a)
Ensure that no appropriate valid message data are available for any of the possible
ADS-B broadcast messages. Power up the equipment. Verify that no
transmissions occur.
Step 2: Valid Data available (2.2.3.3.2.1.1.b)
For each ADS-B Position and Velocity Message type in turn, ensure that
appropriate valid ADS-B Message data are available for that message type only.
Power up the equipment. Verify that the correct ADS-B broadcast message is
transmitted starting no later than 2.0 seconds after Power-On.
Step 3: Built-in-Test Completion (2.2.3.3.2.1.1.c)
a. Repeat the procedure provided in Step 2
b. Verify that the Unit-Under-Test (UUT) has completed all Built-in-Test

functions no later than 20 seconds after applying power to the UUT.
Note: In order to demonstrate compliance with this procedure, the

manufacturer should design the equipment to provide an appropriate
indication that the equipment is performing Built-in-Test functions
during the Power Up sequence.
2.4.3.3.2.1.2 Verification of Start Up (2.2.3.3.2.1.2)

Note: To save time and repeating of tests the tests in this section can be combined with
those testing 2.2.3.3.2.2 to 2.2.3.3.2.9 inclusive.
Equipment Required:
Message for display on an oscilloscope.
20xx, RTCA, Inc.

524
Step 1: Data Available for only One Variable Data Field (2.2.3.3.2.1.2.a and b)
Ensure that no appropriate valid message data are available for any of the possible
ADS-B broadcast messages. Power up the equipment. Verify that no
transmissions occur. For ADS-B broadcast message specified in 2.2.3.3.2.2, for
each data field in turn, make data available for only that data field. Verify that for
each data field, the message is transmitted at the rate specified in 2.2.3.3.2.3 to
2.2.3.3.2.9 inclusive.
Repeat Step 1 for all of the ADS-B broadcast message types specified in
2.2.3.3.2.3 to 2.2.3.3.2.9 inclusive.
Step 2: Data Ceases to be Available After Transmission has been Initiated

(2.2.3.3.2.1.2.c)
Ensure that appropriate valid ADS-B Message data are available for each ADS-B
Message type. For each ADS-B Message type in turn, make all data fields
unavailable and verify that the broadcast of the relevant message is discontinued
when the input data has not been available for a period as specified in
2.2.3.3.2.12.
2.4.3.3.2.2 Verification of ADS-B Airborne Position Message Broadcast Rate (2.2.3.3.2.2)

Equipment Required:
Message for display on an oscilloscope, or equivalent method of observing the message
content.
Step 1: All Data Available (2.2.3.3.2.2)
appropriate valid ADS-B Airborne Position data is available. Verify that the
ADS-B Airborne Position Message is broadcast at intervals that are uniformly
distributed over the range of 0.4 to 0.6 seconds as specified in 2.2.3.3.2.2.
Step 2: Only Barometric Altitude Data Available (2.2.3.2.3.1.3.1)
Repeat Step 1 with only barometric altitude data available this time and verifying
that the TYPE Code = 0.
20xx, RTCA, Inc.

525
Step 3: Data Ceases to be Updated (2.2.3.3.2.11a)
Establish the broadcast of the ADS-B Airborne Position Message as in Step 1

above. Then stop the input of data (no position and no altitude) for the ADS-B
Verify that the ADS-B Airborne Position Message is broadcast with all data bits
being set to ZERO 2.0 seconds after stopping the data input.
Verify that the ADS-B Airborne Position Message is no longer broadcast 60 1

seconds after stopping the data input.
2.4.3.3.2.3 Verification of ADS-B Surface Position Message Broadcast Rate (2.2.3.3.2.3)

Equipment Required:
Provide a method of loading valid data for broadcasting ADS-B Messages into the ADS-B
equipment under test. Provide a method of monitoring the transmitted ADS-B Messages
and measuring the rate at which they are output.
Step 1: Switching from High Rate to Low Rate & Data Ceases to be Updated
(2.2.3.3.2.3.a(1) and c & 2.2.3.3.2.12)
appropriate valid ADS-B Surface Position data is provided such that the position
is changing at a rate of 10.1 meters in any 30 second interval. At least 61 seconds
after the start of the data input, verify that the ADS-B Surface Position Message is
broadcast at intervals that are uniformly distributed over the range of 0.4 to 0.6
seconds as specified in 2.2.3.3.2.3.b.
Input new ADS-B Surface Position data with the position data changing at a rate
of 9.9 meters in any 30 second interval. At least 61 seconds after the inputting of
the new data, verify that the ADS-B Surface Position Message is broadcast at
intervals that are uniformly distributed over the range of 4.8 to 5.2 seconds as
Stop the input of data, and for Transponder-Based systems verify that the ADS-B
Surface Position Messages are no longer broadcast 60 1 seconds after the data
becomes unavailable. For Non-Transponder-Based systems verify that TYPE
Code of ZERO is output at the High transmission rate after 2 seconds. Monitor
for 120 seconds and verify that TYPE Code of ZERO continues to be broadcast.
Step 2: Switching from Low Rate to High Rate & Data Ceases to be Updated
(2.2.3.3.2.3.a(2) and c & 2.2.3.3.2.12)
appropriate valid ADS-B Surface Position data is provided such that the position
is stationary. At least 61 seconds after establishing the data, verify that the ADS-
20xx, RTCA, Inc.

526
B Surface Position Messages are broadcast at intervals that are uniformly

distributed over the range of 4.8 to 5.2 seconds as specified in 2.2.3.3.2.3.c.
Input new ADS-B Surface Position data such that the position is stationary and
10.1 meters away from the position above. One (1) second after inputting the new
data, verify that the ADS-B Surface Position Messages are broadcast at intervals
that are uniformly distributed over the range of 0.4 to 0.6 seconds as specified in
2.2.3.3.2.3.b. Also verify that at least 61 seconds after establishing the new data
that the ADS-B Surface Position Message is broadcast at intervals that are
uniformly distributed over the range 4.8 to 5.2 seconds as specified in
2.2.3.3.2.3.c.
Stop the input of data, and for Transponder-Based systems verify that the ADS-B
Surface Position Messages are no longer broadcast 60 1 seconds after the data
becomes unavailable. For Non-Transponder-Based systems verify that TYPE
Code of ZERO is output at the High transmission rate after 2 seconds. Monitor
for 120 seconds and verify that TYPE Code of ZERO continues to be broadcast.
2.4.3.3.2.4 Verification of ADS-B Aircraft Identification and Category Message Broadcast Rate
(2.2.3.3.2.4)
Equipment Required:
Step 1: Airborne with No Target State, and Aircraft Operational Status (2.2.3.3.2.4.a )
Verify that the ADS-B Aircraft Identification and Category Message is broadcast
at intervals that are uniformly distributed over the range of 4.8 to 5.2 seconds as
specified in 2.2.3.3.2.4.a.
Step 2: Airborne with Target State, and Aircraft Operational Status (2.2.3.3.2.4.b)
Provide the equipment with valid Target State Data necessary to establish Target
State and Status Broadcast Messages (see 2.2.3.2.7.1 and 2.2.3.3.2.6.1).
Provide the equipment with valid Target State Data necessary to establish Target
State and Status Broadcast Messages (see 2.2.3.2.7.1 and 2.2.3.3.2.6.1).
Provide the equipment with valid Operational Status Data necessary to establish
Aircraft Operational Status Messages (see 2.2.3.2.7.2 and 2.2.3.3.2.6.2).
20xx, RTCA, Inc.

527
Verify that Target State and Status, and Aircraft Operational Status Messages are
being broadcast.
Note: It is not necessary to verify the rate of broadcast for the Intent Messages at
this time since direct verification of the broadcast rates for these messages is
verified in procedures later in this document.
at an average rate of one message per 5 seconds over a time period of 60 seconds.
Step 3: On the Ground (2.2.3.3.2.4.c)
at intervals that are uniformly distributed over the range of 9.8 to 10.2 seconds as
Step 4: Data Ceases to be Updated (2.2.3.3.2.11)
Establish the broadcast of the ADS-B Aircraft Identification and Category

Message as in Step 1 above. Then stop the input of data for the ADS-B Aircraft
Identification and Category Message.
Verify that the ADS-B Aircraft Identification and Category Message continues to
be broadcast with the same data that existed prior to stopping the data input for at
least 61 seconds after stopping the data input.
2.4.3.3.2.5 Verification of ADS-B Velocity Information Message Broadcast Rate (2.2.3.3.2.5)

Equipment Required:
Step 1: Data Available (2.2.3.3.2.5)
Ensure that the appropriate valid ADS-B Velocity Information data is available.
Verify that the ADS-B Velocity Information message is broadcast at intervals that
are uniformly distributed over the range of 0.4 to 0.6 seconds as specified in
2.2.3.3.2.5.a.
Step 2: Data Ceases to be Updated (2.2.3.3.2.11)
Establish the broadcast of the ADS-B Airborne Velocity Message as in Step 1

above. Then stop the input of data for the ADS-B Airborne Velocity Message,
except for the Intent Change Flag.
20xx, RTCA, Inc.

528
Verify that the ADS-B Airborne Velocity Message is not broadcast 2.6 seconds
after stopping the data input.
2.4.3.3.2.6 Verification of ADS-B Periodic Status Message Broadcast Rates (2.2.3.3.2.6)

2.4.3.3.2.6.1 Verification of ADS-B Target State and Status Message Broadcast Rates
(2.2.3.3.2.6.1)
The requirements of 2.2.3.3.1.4.1 are applicable. The Target State and Status Messages
(TYPE=29, Subtype=0, 2.2.3.2.7.1) are broadcast at random intervals that are uniformly
distributed over the range of 1.2 to 1.3 seconds relative to the previous Target State and
Status Message for as long as data is available to satisfy the requirements of 2.2.3.3.1.4.1.
Exceptions to these transmission rate requirements are specified in 2.2.3.3.2.9.
Equipment Required:
Provide a Method of loading valid data for ADS-B broadcast messages into the ADS-B
Step 1: No ADS-B Message Broadcasts - On-Ground (2.2.3.3.1.4.1.a & 2.2.3.3.1.4.1.b)
If the ADS-B Transmitting Subsystem under test cannot be placed in the On-
Ground condition, proceed to Step 2.
Subtype=ZERO), impose an On-Ground condition, and verify that the ADS-B
Transmitting Subsystem is not broadcasting any ADS-B Target State and Status
Messages.
Step 2: No ADS-B Message Broadcasts Without Either Vertical or Horizontal Valid

State Information (2.2.3.3.1.4.1.a & 2.2.3.3.1.4.1.b)
If the ADS-B Transmitting Subsystem under test cannot be placed in all of the
following conditions, proceed to Step 3.
Subtype=ZERO), impose invalid vertical target state information, invalid
horizontal Target State information, and set to the Airborne condition, and verify
that the ADS-B Transmitting Subsystem is not broadcasting any ADS-B Target
State and Status Messages.
20xx, RTCA, Inc.

529
Step 3: ADS-B Message Broadcasts With Only Vertical Valid State Information
(2.2.3.3.1.4.1.a & 2.2.3.3.1.4.1.b)
Subtype=ZERO), impose valid vertical Target State information, invalid
horizontal target state information, and set to the Airborne condition, and verify
seconds.
Step 4: ADS-B Message Broadcasts With Only Horizontal Valid State Information
(2.2.3.3.1.4.1.a & 2.2.3.3.1.4.1.b)
Subtype=ZERO), impose invalid vertical target state information, valid horizontal
target state information, and set to the Airborne condition, and verify that the
ADS-B Transmitting Subsystem is broadcasting ADS-B Target State and Status
Messages at a spacing uniformly distributed over the range of 1.2 to 1.3 seconds.
Step 5: Mutual Suppression Exception (2.2.3.3.2.9)
If the Mutual Suppression Interface is provided, force the Mutual Suppression

condition at a time, and for a duration, which insures that the next expected ADS-
B Target State and Status Message will be delayed, and verify that the ADS-B
Target State and Status Message is delayed.
Remove the Mutual Suppression condition, and verify that ADS-B Target State
and Status Messages resume broadcasting at a spacing uniformly distributed over
the range of 1.2 to 1.3 seconds.
Step 6: ADS-B Message Broadcast Sixty Second Timeout ADS-B Target State and
Status Messages (2.2.3.3.2.11c & 2.2.3.3.2.12)
Interrupt the changing of the input data necessary for transmission of ADS-B
Target State and Status Messages (TYPE=29, Subtype=0) with new (valid) data,
and after 60 seconds verify that the unchanged data fields are NOT cleared to
ZERO.
Stop the input of data, and verify that the ADS-B Target State and Status
Messages (TYPE=29, Subtype=0) are no longer broadcast 60 1 seconds after the
data becomes unavailable.
20xx, RTCA, Inc.

530
2.4.3.3.2.6.2 Verification of ADS-B Aircraft Operational Status Message Broadcast Rates

(2.2.3.3.2.6.2)
The Aircraft Operational Status Messages (TYPE=31 and Subtype=0) (2.2.3.2.7.2) are
broadcast at varying rates as specified in 2.2.3.3.1.4.2. Exceptions to these transmission
rate requirements are specified in 2.2.3.3.2.9.
Equipment Required:
Step 1: ADS-B Message Broadcasts ADS-B Target State and Status & Operational
Status Messages (2.2.3.3.1.4.2.a.ii)
generation of both Aircraft Operational Status Messages (TYPE=31,
Subtype=ZERO), and ADS-B Target State and Status Messages (TYPE=29,
Subtype=ZERO), and verify that the ADS-B Transmitting Subsystem is
broadcasting both ADS-B Target State and Status Messages at a spacing
uniformly distributed over the range of 1.2 to 1.3 seconds, and Operational Status
Messages at a spacing uniformly distributed over the range of 2.4 to 2.6 seconds.
(2.2.3.3.1.4.2.a.ii)
Separately initiate each of the four changes described in Condition 2

(2.2.3.3.1.4.2), and for each separate case verify that the ADS-B Transmitting
Changes (2.2.3.3.1.4.2.b)
For each of the four cases decribed below, disable the tranmission of ADS-B
Target State and Status Messages, and perform Steps 3a and 3b in sequence before
proceeding to the next case.

Subsystem changes the Aircraft Operational Status Messages broadcast spacing to
be uniformly distributed over the range of 0.75 to 0.85 seconds.
20xx, RTCA, Inc.

531
Changes (2.2.3.3.1.4.2.a.i)
Changes (2.2.3.3.1.4.2.a.i)
verify that the ADS-B Transmitting Subsystem reverts to broadcasting Aircraft
2.4 to 2.6 seconds.

condition at a time, and for a duration, which insures that the next expected
Aircraft Operational Status Message will be delayed, and verify that the Aircraft
Operational Status Message is delayed.
Remove the Mutual Suppression condition, and verify that Aircraft Operational
Status Messages resume at a spacing uniformly distributed over the range of 2.4 to
2.6 seconds.
Step 5: ADS-B Message Broadcasts Repeat Tests With ADS-B Target State and Status
& Operational Status Messages
Repeat the Step 1 setup, except replace the Aircraft Operational Status Messages
(TYPE=31, Subtype=0) with Aircraft Operational Status Messages (TYPE=31,
Subtype=1), verify that the ADS-B Transmitting Subsystem is broadcasting ADS-
B Target State and Status Messages at a spacing uniformly distributed over the
range of 1.2 to 1.3 seconds, and Aircraft Operational Status Messages at a spacing
(2.2.3.3.1.4.2.c)

Changes (2.2.3.3.1.4.2.c)
For each of the four cases described below, disable the transmission of ADS-B
Target State and Status Messages, and perform Steps 7a, 7b, and 7c in sequence
before proceeding to the next case.
20xx, RTCA, Inc.

532

Subsystem continues to broadcast the Aircraft Operational Status Messages at a
spacing which is uniformly distributed over the range of 4.8 to 5.2 seconds.
Changes (2.2.3.3.1.4.2.c)
4.8 to 5.2 seconds.
Changes (2.2.3.3.1.4.2.c)
4.8 to 5.2 seconds.

condition at a time, and for a duration, which insures that the next expected
Aircraft Operational Status Message will be delayed, and verify that the Aircraft
Operational Status Message is delayed.
Remove the Mutual Suppression condition, and verify that Aircraft Operational
Status Messages resume at a spacing uniformly distributed over the range of 4.8 to
5.2 seconds.
Step 9: ADS-B Message Broadcast Sixty-Second Timeout Aircraft Operational Status

Messages (2.2.3.3.2.11.c & 2.2.3.3.2.12)
Interrupt the changing of the input data necessary for transmission of Aircraft
Operational Status Messages (TYPE=31, Subtype=1) with new (valid) data, and
after 60 seconds verify that the unchanged data fields are NOT cleared to ZERO.
Stop the input of data, and verify that the Aircraft Operational Status Messages
(TYPE=31, Subtype=1) are no longer broadcast 60 1 seconds after the data
becomes unavailable.
Step 10: ADS-B Message Broadcast Sixty Second Timeout Aircraft Operational Status
Messages (2.2.3.3.2.11.c & 2.2.3.3.2.12)
Replace the Aircraft Operational Status Messages (TYPE=31, Subtype=1) with

Aircraft Operational Status Messages (TYPE=31, Subtype=0), interrupt the
changing of the input data necessary for transmission of Aircraft Operational
Status Messages (TYPE=31, Subtype=0) with new (valid) data, and after 60
seconds verify that the unchanged data fields are NOT cleared to ZERO.
20xx, RTCA, Inc.

533
Stop the input of data, and verify that the Aircraft Operational Status Messages
(TYPE=31, Subtype=0) are no longer broadcast 60 1 seconds after the data
becomes unavailable.
2.4.3.3.2.6.3 Verification of Extended Squitter Aircraft Status ADS-B Event-Driven Message

Broadcast Rate (2.2.3.3.2.6.3)
The rate at which the Extended Squitter Aircraft Status (TYPE=28) ADS-B Event-Driven
Message (see 2.2.3.2.7.8), is being broadcast varies as defined in 2.2.3.3.1.4.3.
Exceptions to these transmission rate requirements are specified in 2.2.3.3.2.9.
Equipment Required:
Step 1: ADS-B Message Broadcasts No ADS-B Target State and Status & Extended
Squitter Aircraft Status Emergency/Priority Status Messages (2.2.3.3.1.4.3.a)
Emergency/Priority Status (TYPE=28, Subtype=1), but not ADS-B Target State
and Status Messages (TYPE=29, Subtype=0), and verify that the ADS-B
Transmitting Subsystem is broadcasting Extended Squitter Aircraft Status
Emergency/Priority Status Messages at a spacing uniformly distributed over the
range of 0.75 to 0.85 seconds.
Step 2: ADS-B Message Broadcasts ADS-B Target State and Status & Extended
Squitter Aircraft Status Emergency/Priority Status Messages (2.2.3.3.1.4.3.b)
Emergency/Priority Status (TYPE=28, Subtype=1), and ADS-B Target State and
Status Messages (TYPE=29, Subtype=0), and verify that the ADS-B Transmitting
Subsystem is broadcasting both ADS-B Target State and Status Messages at a
spacing uniformly distributed over the range of 1.2 to 1.3 seconds, and Extended
Squitter Aircraft Status Messages at a spacing uniformly distributed over the range
of 2.4 to 2.6 seconds.
Step 3: ADS-B Message Broadcasts Emergency Status Termination (2.2.3.3.1.4.3.b)
Terminate the Emergency State condition, and verify that the ADS-B Transmitting
Subsystem ceases broadcasting of the Extended Squitter Aircraft Status
Emergency/Priority Status Messages.
20xx, RTCA, Inc.

534
Step 4: Extended Squitter Aircraft Status Emergency/Priority Status Messages - Mutual

Suppression Exception (2.2.3.3.2.9)
Repeat Step 1 so that the ADS-B Transmitting Subsystem is broadcasting

Extended Squitter Aircraft Status Emergency/Priority Status Messages at a

B Extended Squitter Aircraft Status Message will be delayed, and verify that the
ADS-B Extended Squitter Aircraft Status Message is delayed.
Remove the Mutual Suppression condition, and verify that ADS-B Extended
Squitter Aircraft Status Messages resume at a spacing uniformly distributed over
Step 5: Extended Squitter Aircraft Status Emergency/Priority Status Messages - Mutual

Suppression Exception (2.2.3.3.2.9)
Repeat Step 2 so that the ADS-B Transmitting Subsystem is broadcasting

Extended Squitter Aircraft Status Emergency/Priority Status Messages at a

B Extended Squitter Aircraft Status Message will be delayed, and verify that the
ADS-B Extended Squitter Aircraft Status Message is delayed.
Remove the Mutual Suppression condition, and verify that ADS-B Extended
Squitter Aircraft Status Messages resume at a spacing uniformly distributed over
Step 6: ADS-B Message Broadcast Sixty Second Timeout ADS-B Event-Driven

Messages (2.2.3.3.2.11.c & 2.2.3.3.2.12)
Interrupt the changing of the input data necessary for transmission of Extended
Squitter Aircraft Status (TYPE=28), Emergency/Priority Status ADS-B Event-
Driven Messages (Subtype=1) with new (valid) data, and after 60 seconds verify
that the unchanged data fields are NOT cleared to ZERO.
Stop the input of data, and verify that the Extended Squitter Aircraft Status
(TYPE=28), Emergency/Priority Status ADS-B Event-Driven Messages
(Subtype=1) are no longer broadcast 60 1 seconds after the data becomes
unavailable.
Step 7: No ADS-B Target State and Status while Broadcasting the 1090ES TCAS RA
Broadcast Message (2.2.3.3.1.4.3.a)
Broadcast Messages, but not ADS-B Target State and Status Messages
20xx, RTCA, Inc.

535
(TYPE=29, Subtype=0), and verify that the ADS-B Transmitting Subsystem is

broadcasting Extended Squitter Aircraft Status TCAS RA Broadcast Messages
(TYPE=28, Subtype=2) at a spacing uniformly distributed over the range of 0.75
to 0.85 seconds.
Step 8: Broadcasting Both ADS-B Target State and Status & Extended Squitter Aircraft
Status TCAS RA Broadcast Messages (2.2.3.3.1.4.3.b)
Broadcast Messages, and ADS-B Target State and Status Messages (TYPE=29,
Subtype=0), and verify that the ADS-B Transmitting Subsystem is broadcasting
both ADS-B Target State and Status Messages at a spacing uniformly distributed
over the range of 1.2 to 1.3 seconds, and Extended Squitter Aircraft Status TCAS
RA Broadcast Messages (TYPE=28, Subtype=2) at a spacing uniformly
distributed over the range of 2.4 to 2.6 seconds.
Step 9: ADS-B Message Broadcasts Termination of TCAS RA Broadcast

(2.2.3.3.1.4.3.b)
Terminate the TCAS RA condition, and verify that the ADS-B Transmitting
Subsystem ceases broadcasting of the Extended Squitter Aircraft Status TCAS RA
Broadcast Messages not less than 10 seconds after the RA Termination flag
transitions from ZERO (0) to ONE (1) (2.2.3.2.7.8.2).
2.4.3.3.2.7 Verification of TYPE Code=23 (TEST) ADS-B Event-Driven Message Broadcast

Rate (2.2.3.3.2.7)
The TEST Message with Subtype=0 ADS-B Event-Driven Messages are broadcast NOT
MORE Than ONCE each time the Event-Driven Test Information is updated to the ADS-B
Transmitting Subsystem. The delay conditions specified in 2.2.3.3.2.9 are to be observed.
Equipment Required:
Update the TEST ADS-B Event-Driven Message and verify that it is broadcast only once.
Repeat 10 times.
20xx, RTCA, Inc.

536
2.4.3.3.2.8 Verification of TYPE Code 24 - 27 ADS-B Event-Driven Message Broadcast Rate

(2.2.3.3.2.8)
Equipment Required:
These messages are reserved for future expansion. When implemented perform the
following test:
Update each of the implemented TYPE Code 24 to 27 ADS-B Event-Driven Messages in

turn and verify that it is broadcast only once. Repeat 10 times.
2.4.3.3.2.9 Verification of ADS-B Message Transmission Scheduling (2.2.3.3.2.9)

An ADS-B Message scheduling function is used to determine the sequence of ADS-B

Messages to be broadcast and to control the overall transmission rate of Event-Driven
messages. As an exception to the general requirement for the transmission of ADS-B
Messages, the scheduled message transmission is delayed if a Mutual Suppression interface
is active.
Equipment Required:
Step 1: Scheduling Function Verification (2.2.3.3.2.9.a)
Appropriate test procedures to validate the requirements of 2.2.3.3.2.9.a are

included in 2.4.3.3.2.9.1 and 2.4.3.3.2.9.2.
Step 2: Mutual Suppression Induced Message Delay (2.2.3.3.2.9.b)
generation of ADS-B Aircraft Status Messages (TYPE=28, Subtype=1), and
verify that the ADS-B Transmitting Subsystem is broadcasting ADS-B Aircraft
Status Messages, with no Emergencies, no TCAS RAs and no Mode A Code
changes, at a spacing uniformly distributed over the range of 4.8 to 5.2 seconds.
If a Mutual Suppression Interface is provided, force a Mutual Suppression

condition such that the next expected ADS-B Aircraft Status Message will be
delayed, and verify that the delay occurs.
20xx, RTCA, Inc.

537
Remove the Mutual Suppression condition, and verify that ADS-B Aircraft Status
Messages resume at a spacing uniformly distributed over the range of 4.8 to 5.2
seconds.
2.4.3.3.2.9.1 Verification of Position, Velocity and Identification Message Scheduling (2.2.3.3.2.9.1)

The priority for transmission (from highest to lowest) for the message types that are not
Event-Driven is specified in 2.2.3.3.2.9.1. Provide a method for the generation of ADS-B
Position, Velocity, and Identification Messages in a defined order, and for the verification
that those messages have been reprioritized in their transmission order, according to the test
steps that follow.
Step 1: Message Scheduling Setup (2.2.3.3.2.9.1)
generation of an ADS-B Surface Position Message.
Step 2: Message Scheduling Airborne or Surface Position, Airborne Velocity, and

Identification Messages (2.2.3.3.2.9.1.a, b, c)
Beginning up to 15 milliseconds following the generation of the message pair in

Step 1 above, and spaced by up to 15 milliseconds, generate the following series
of messages in order as listed below:
1. A message of the TYPE and Subtype described in 2.2.3.3.2.9.1.c.
2. A message of the TYPE and Subtype described in 2.2.3.3.2.9.1.b.
3. A message (or message pair) of the TYPE and Subtype described in

2.2.3.3.2.9.1.a.
Step 3: Message Scheduling Verification (2.2.3.3.2.9.1.a, b, c)
Verify that the series of 3 message (or message pair) types, generated in Step 1
and Step 2 above, occur at a rate no more than that allowed for the message type
(see 2.2.3.3.1.3, and 2.2.3.3.2.3 b & 3c), and occur in the following order:
1. A message (or message pair) of the TYPE and Subtype described in

2.2.3.3.2.9.1.a.
2. A message of the TYPE and Subtype described in 2.2.3.3.2.9.1.b.
3. A message of the TYPE and Subtype described in 2.2.3.3.2.9.1.c.
20xx, RTCA, Inc.

538
Step 4: Message Scheduling Verification (2.2.3.3.2.9.1.a, b, c)
Repeat Step 1, Step 2, and Step 3 for each type of Position Message
(2.2.3.3.2.9.1.a), and for each Subtype variation of Airborne Velocity Message
(2.2.3.3.2.9.1.b).
2.4.3.3.2.9.2 Verification of Event-Driven Message Scheduling (2.2.3.3.2.9.2)

included in 2.4.3.3.1.4.6.1.
2.4.3.3.2.10 Verification of Maximum ADS-B Message Transmission Rates (2.2.3.3.2.10)

The maximum ADS-B Message transmission rate of non-transponder ADS-B Transmitter

implementations may not exceed 6.2 transmitted messages per second, averaged over any 60
second interval.
Equipment Required:
ADS-B equipment under test through the operational interface. Provide a method of
monitoring ADS-B broadcast messages output by the equipment under test. Provide a Wide
Band Dual Channel Oscilloscope (HP 1710B, or equivalent).
Step 1: Airborne Message Scenario (2.2.3.3.2.10)
Provide the ADS-B Transmitting Subsystem with the valid data necessary for the
generation of (a) ADS-B Airborne Position Messages, (b) ADS-B Airborne
Velocity Messages, (c) ADS-B Aircraft Identification and Category Messages,
and (d) ADS-B Target State and Status Messages (TYPE=29, Subtype=0)
resulting from more than two events per second, and over a period of several
minutes verify that the ADS-B Transmitting Subsystem is broadcasting no more
than a total of 6.2 messages per second, averaged over any 60 second interval.
Step 2: Surface Message Scenario (2.2.3.3.2.10)
Provide the ADS-B Transmitting Subsystem with the valid data necessary for the
generation of (a) ADS-B Surface Position Messages while changing aircraft
position data by more than 10 meters every 30 seconds, (b) ADS-B Airborne
Velocity Messages, (c) ADS-B Aircraft Identification and Category Messages,
and (d) ADS-B Target State and Status Messages (TYPE=29, Subtype=0)
resulting from more than two events per second, and over a period of several
minutes verify that the ADS-B Transmitting Subsystem is broadcasting no more
than a total of 6.2 messages per second, averaged over any 60 second interval.
20xx, RTCA, Inc.

539
2.4.3.3.2.11 Verification of ADS-B Message Timeout (2.2.3.3.2.11)

ADS-B Message Timeout performance is tested in 2.4.3.3.2.2 through 2.4.3.3.2.8.
2.4.3.3.2.12 Verification of ADS-B Message Termination (2.2.3.3.2.12)

Except for the requirement of Message Transmission suspension on Class B2 Ground
Vehicles as specified in 2.2.3.3.2.12.g, other requirements for ADS-B Message Timeout
performance are tested in 2.4.3.3.2.2 through 2.4.3.3.2.8.
Configure the Class B2 Non-Tansponder-Based Transmiting Subsystem for Ground

Vehilces to transmit its required subset of ADS-B Messages. Input valid data and verify
that the system is transmitting appropriate ADS-B Messages as required. Input additional
data that indicates that the vehicle has crossed a boundary defined by the mapping function
placing it outside of the user defined area. Verify that the broadcasts of all ADS-B
Messages are suspended. Repeat this procedure for each boundary of the defined area
entered into the mapping function database.
2.4.3.4 Verification of ADS-B Transmitted Message Error Protection (2.2.3.4)

ADS-B Transmitted Error Protection performance was previously tested in 2.4.3.2.1.7.
2.4.4 Verification of ADS-B Receiver Characteristics (2.2.4)

2.4.4.1 Verification of Minimum Triggering Level (MTL) Definition (2.2.4.1)

No specific test procedure is required to validate 2.2.4.1 since appropriate procedures are
provided in subsequent subparagraphs of this document.
2.4.4.2 Verification of Receivers Shared with a TCAS Unit (2.2.4.2)

ADS-B receivers implemented as part of a TCAS unit shall demonstrate compliance with
Test Procedures specified in the TCAS MOPS, RTCA DO-185B, 2.4.2.1.2 (EUROCAE
ED-143, 2.4.2.1.2).
In addition to tests specified in the TCAS MOPS, RTCA DO-185B, 2.4.2.1.2 (EUROCAE
ED-143, 2.4.2.1.2), TCAS units operating with receivers that are more sensitive than the
MTL requirements specified in RTCA DO-185B, (EUROCAE ED-143) shall be submitted
to the following test procedures provided through 2.4.4.4.
20xx, RTCA, Inc.

540
2.4.4.2.1 Verification of Dual Minimum Triggering Levels (2.2.4.2.1)

2.4.4.2.1.1 Verification of TCAS Compatibility (2.2.4.2.1.1)

This test verifies that no more than 10% of ADS-B Messages received at a level of 78 dBm
or below are passed to the TCAS surveillance function.
Input:
Equipment:

DF = 17
CA = 0
Power = -78 dBm
RF message source end of the transmission line used to interface the RF message source to
shall be adjusted to compensate for the maximum line loss for which the UUT receiver has
levels specified in the test procedures shall be lowered by 3 dB.
Step 1: Apply ADS-B Input Message
Step 2: Verify ADS-B Input Message Reception
Verify that no more than 10% of all ADS-B Messages are passed on to the TCAS
surveillance function.
Repeat Steps 1 and 2 on all other applicable receiver RF input ports of the UUT.
20xx, RTCA, Inc.

541
2.4.4.2.1.2 Verification of ADS-B Compatibility (2.2.4.2.1.2)

Appropriate test procedures to verify the requirements of 2.2.4.2.1.2 are provided in
2.4.4.3.1.1.
2.4.4.2.2 Verification of Re-Triggerable Reply Processor (2.2.4.2.2)

The following procedures verify the capability of the TCAS shared ADS-B receiver to
detect overlapping Mode-S replies or ADS-B Messages in the TCAS level range.
Inputs:
All Intruder Aircraft:

Altitude = 8000 ft.
Range = 2 NM at T = 0 sec
Equipage = Mode-S
Altitude = 8000 ft
Range = Maintained such that the leading edge of the first
preamble pulse from Intruder 2 occurs 12 1.0 s
later than the leading edge of the first preamble
pulse from Intruder 1 throughout the scenario.
TCAS Aircraft:
Altitude = 8000 ft.
Range = 0 NM
Sensitivity Level Selection = Automatic
ADS-B Message Format (Intruder 1):
All ADS-B Message transmissions shall have the following standard data field values:
DF = 17
CA = 0
AA = Any valid discrete address.
Mode-S Squitter Format (Intruder 2):
All Mode-S squitter transmissions shall have the following standard data field values:
DF = 11
CA = 0
20xx, RTCA, Inc.

542
AA = Any valid discrete address.

Conditions:
TCAS initialized and operating at T = 0 seconds. Intruders 1 and 2 shall each transmit
squitters during the squitter listening period following each whisper-shout sequence and
shall reply with a short special surveillance format (DF=0) to each TCAS discrete
interrogation.
Scenario Description:
Both Intruders are co-altitude with TCAS and each transmits squitters when TCAS is in
squitter listening mode and replies to discrete interrogations from TCAS. Intruder 2 is
overlapping the Intruder 1 reply window.
The receiver power levels specified in this procedure are relative to the loss at the RF
message source end of the transmission line used to interface the RF message source to the
UUT receiver input port. For each ADS-B equipage class, the specified power level shall
be adjusted to compensate for the maximum line loss for which the UUT receiver has been
designed. For example, if the line loss is 3 dB, then each of the RF message power levels
specified in the test procedures shall be lowered by 3 dB.
Step 1: Apply ADS-B and Mode-S Input Messages
Apply the message inputs defined above to the receiver input port.
Verify that the TCAS receiver detects intruder #2.
Repeat Steps 1 on all other applicable receiver RF input ports of the UUT.
Step 3: Vary Signal Power Levels
Repeat Steps 1 and 2 with the following additional squitter power levels:
a. Intruder Aircraft 1 Squitter Power = -30 dBm
Intruder Aircraft 2 Squitter Power = -24 dBm
b. Intruder Aircraft 1 Squitter Power = MTL + 3 dB
Intruder Aircraft 2 Squitter Power = MTL + 9 dB
Verify that the TCAS receiver detects Intruder Aircraft #2 for each case.
2.4.4.3 Verification of Receivers Not Shared With TCAS (2.2.4.3)

20xx, RTCA, Inc.

543
2.4.4.3.1 Verification of In-Band Acceptance and Re-Triggerable Capability (2.2.4.3.1)

2.4.4.3.1.1 Verification of In-Band Acceptance and Dynamic Range (2.2.4.3.1.1)

Appropriate test procedures to verify the requirements of 2.2.4.3.1.1 are provided in
2.4.4.3.1.1.1 and 2.4.4.3.1.1.2.
2.4.4.3.1.1.1 Verification of In-Band Acceptance (2.2.4.3.1.1.a)

This test verifies the compliance of the ADS-B receiver with the sensitivity requirements
specified for the particular ADS-B equipage class.
Input:
Equipment:

DF = 17
CA = 0
Power = -68 dBm
required to produce a 90 percent ADS-B Message reception rate by the UUT
receiver.
20xx, RTCA, Inc.

544
ADS-B receiver.
Verify that the measured MTL is in compliance with the limits specified in
Step 3: Verify UUT Receiver MTL over the Operational Frequency Range
Vary the RF signal frequency over the range of 1089 to 1091 MHz and determine
the variation in RF signal level required to produce 90 percent ADS-B Message
reception rate by the UUT receiver.
Verify that the measured MTL continues to comply with the limits specified in
UUT.
2.4.4.3.1.1.2 Verification of Dynamic Range (2.2.4.3.1.1.b, 2.2.4.3.1.1.c)

This test verifies that the ADS-B receiver can detect and decode valid ADS-B Messages
over the equipments specified dynamic range.
Input:
Equipment:
Provide a method of providing the UUT with:

DF = 17
CA = 0
Power = -68 dBm
20xx, RTCA, Inc.

545
required to produce 90 percent ADS-B Message reception rate by the UUT
receiver.
ADS-B receiver.
Step 3: Verify UUT Receiver Dynamic Range
Increase the input signal power level to MTL + 3 dB.
Verify that the receiver properly detects and decodes at least 99% of all ADS-B
Messages received.
Increase the input signal power level in 10 dB steps up to a signal level of -21
dBm.
At each step, verify that the receiver properly detects and decodes at least 99% of
all ADS-B Messages received.
Step 4: Verify Class A3 UUT Receiver Performance
Decrease the input signal power level to 87 dBm. Verify that the receiver
properly detects and decodes at least 15% of all ADS-B Messages input.
UUT.
2.4.4.3.1.2 Verification of Re-Triggerable Capability (2.2.4.3.1.2)

The following test procedures verify the capability of the Standalone ADS-B receiver to
detect overlapping ADS-B broadcast messages.
20xx, RTCA, Inc.

546
Input:
Equipment:

DF = 17
CA = 0
Power = -50 dBm
Followed by a second Valid Mode S Extended Squitter:

DF = 17
CA = 0
AA = Any discrete address different from the first one
Power = 42 dBm
Starting 6.0 1.0 sec later than the leading edge of the first ADS-B Message.
Apply Input at the receiver input and verify that at least the reply ratio in the
following table of the second valid ADS-B Messages are correctly decoded.
Receiver Class Class A1S/A1 Class A2 Class A3
Repeat Step 1 with the Input signal power level at MTL + 6 dB for the first
ADS-B Message and MTL + 14 dB for the second ADS-B Message.
Repeat Step 1 with Input level at -32 dBm for the first ADS-B Message and
-24 dBm for the second ADS-B Message.
20xx, RTCA, Inc.

547
UUT.
2.4.4.3.2 Verification of Out-of-Band Rejection (2.2.4.3.2)

This test verifies that the ADS-B out-of-band rejection is in accordance with the specified
values.
Input A:
Equipment:

DF = 17
CA = 0
Power = MTL + 3 dB
Where MTL is the measured value of MTL made at 1090
MHz
Input B:
Power = MTL + 6 dB
Input C:
Power = MTL + 23 dB
Input D:
Power = MTL + 43 dB
Input E:
Power = MTL + 63 dB
20xx, RTCA, Inc.

548
Input F:
Power = MTL + 6 dB
Input G:
Power = MTL + 23 dB
Input H:
Power = MTL + 43 dB
Input I:
Frequency = 1115.0 Mhz
Power = MTL + 63 dB
Step 1: Apply Initial ADS-B Input Messages
Apply Input B at the receiver input port and decrease the power level until the
percentage of decoded ADS-B Messages is less than or equal to 90 percent.
Verify that the measured signal power level required to produce a message
decoding percentage of greater than or equal to 90 percent is greater than the limit
specified in Table 2-80 of 2.2.4.3.2.
Step 2: Vary the Input Signal Power and Frequency
Repeat Step 1 using inputs C, D, E, F, G, H and I.
Repeat Steps 1 and 2 on all other applicable receiver RF input ports of the UUT.
20xx, RTCA, Inc.

549
2.4.4.3.3 Verification of Dynamic Minimum Trigger Level (DMTL) (2.2.4.3.3)

This test verifies that, when DMTL control is implemented (see 2.2.4.3.3), then the ADS-B
receiver DMTL is capable of rejecting low level signals during a valid squitter reception and
that DMTL is capable of recovering in not more than 128 microseconds after the leading
edge of the first preamble pulse of a valid ADS-B Message.
Note: This test procedure is only applicable to equipment that do not use the enhanced
reception techniques. That is, it is not applicable to equipage Classes A1S, A1, A2
and A3.
Input A:
Equipment:

DF = 17
CA = 0
Power = -61 dBm
Power = -69 dBm
ADS-B Message.
Input B:

DF = 17
CA = 0
Power = -40 dBm
20xx, RTCA, Inc.

550

Power = -49 dBm
ADS-B Message.
Input C:

DF = 17
CA = 0
Power = -21 dBm
Power = -30 dBm
ADS-B Message.
Input D:

DF = 17
CA = 0
Power = -21 dBm
Followed by a second Valid ADS-B Message having:
DF = 17
CA = 0
Power = -60 dBm
Starting 129 1 sec after the leading edge of the first preamble pulse of the first
ADS-B Message.
20xx, RTCA, Inc.

551
Input E:

DF = 17
CA = 0
Power = -70 dBm
Power = -60 dBm
Starting 4.0 sec before the leading edge of the first preamble pulse of the ADS-B
Message.
Input F:

DF = 17
CA = 0
Power = -70 dBm
Power = -60 dBm
Starting 9.0 sec before the leading edge of the first preamble pulse of the ADS-B
Message.
20xx, RTCA, Inc.

552
Apply Input A at the receiver input and verify that at least 90 percent of the valid
Repeat Step 1 using Input C.
Step 4: DMTL Recovery - Part 4
Apply Input D at the receiver input and verify that at least 90 percent of the
second valid ADS-B Messages are correctly decoded.
Step 5: DMTL Desensitization after a Single Pulse
Apply Input E at the receiver input and verify that no more than 10 percent of the
Step 6: DMTL Recovery after a Single Pulse
Apply Input F at the receiver input and verify that at least 90 percent of the valid
2.4.4.3.4 Verification of 1090 MHz ADS-B Message Reception Techniques (2.2.4.3.4)

2.4.4.3.4.1 Verification of ADS-B Message Reception (2.2.4.3.4.1)

Appropriate test procedures required to validate 2.2.4.3.4.1 are provided in 2.4.4.3.3.
2.4.4.3.4.2 Verification of Narrow Pulse Discrimination (2.2.4.3.4.2)

This test verifies that the ADS-B receiver DMTL is responsive neither to short pulses nor to
TACAN/DME pulses.
20xx, RTCA, Inc.

553
Input A:
Equipment:

DF = 17
CA = 0
Power = -61 dBm
Pulse Width = 0.20 0.05 sec
Power = -61 dBm
Starting 1.0 0.2 sec earlier than the leading edge of the first preamble pulse of
the ADS-B Message.
Input B:

DF = 17
CA = 0
Power = -61 dBm
Pulse Width = 3.00 0.20 sec
Pulse Rise Time = 0.60 0.1 sec
Pulse Fall Time = 0.60 0.1 sec
Power = -61 dBm
Starting 4.0 0.2 sec earlier than the leading edge of the first preamble pulse of
the ADS-B Message.
20xx, RTCA, Inc.

554
Step 1: Narrow Pulse Discrimination - Part 1
Apply Input A at the receiver input and verify that at least 90 percent of the valid
Step 2: Narrow Pulse Discrimination- Part 2
Repeat the Step 1 procedure while increasing the narrow pulse amplitude in 5 dB
steps up to a signal level of -21 dBm.
Step 3: TACAN/DME Discrimination - Part 1
Step 4: TACAN/DME Discrimination - Part 2
Repeat the Step 3 procedure while increasing the TACAN/DME pulse amplitude
in 5 dB steps up to a signal level of -21 dBm.
2.4.4.3.4.3 Verification of TACAN and DME Discrimination (2.2.4.3.4.3)

Appropriate test procedures required to validate 2.4.4.3.4.3 are provided in 2.4.4.3.4.2.
2.4.4.3.4.4 Verification of Pulse Characteristics of Received ADS-B Messages (2.2.4.3.4.4)

2.4.4.3.4.5 Message Formats (2.2.4.3.4.5)

Appropriate test procedures to validate 2.2.4.3.4.5 have previously been provided in
2.4.4.3.1.1 through 2.4.4.3.4.4.
2.4.4.3.4.6 Description of 1090 MHz ADS-B Message Received Signals (2.2.4.3.4.6)

20xx, RTCA, Inc.

555
2.4.4.3.4.7 Verification of ADS-B Signal Reception (2.2.4.3.4.7)

2.4.4.3.4.7.1 Verification of Criteria for ADS-B Message Transmission Pulse Detection

(2.2.4.3.4.7.1 and 2.2.4.3.4.7.2)
These test procedures verify that the ADS-B reply processor correctly detects the presence
of a valid ADS-B preamble whose pulse characteristics are within the allowable limits and
rejects preambles having pulse spacing and position characteristics that are outside the
allowable limits.
Note: This test is not applicable to equipment which uses the enhanced reception
techniques. That is, it is not applicable to equipage Classes A1S, A1, A2 and A3.
The enhanced preamble detection requirements for this equipment are tested in
2.4.4.4.2.2.
Reference Input:
Equipment:

DF = 17
CA = 0
Power = -23 dBm (for the first preamble pulse level)
Input A:
characteristics:
Input A: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 +0.05
2 0.05 - 0.1 0.05 - 0.2 -0.05 -0.125 +2
3 0.05 - 0.1 0.05 - 0.2 +0.05 +0.125 +2
4 0.05 - 0.1 0.05 - 0.2 -0.05 -0.125 0
20xx, RTCA, Inc.

556
Input B:
characteristics:
Input B: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 -0.3
2 0.05 - 0.1 0.05 - 0.2 -0.3 0 0
3 0.05 - 0.1 0.05 - 0.2 -0.3 0 0
4 0.05 - 0.1 0.05 - 0.2 -0.3 0 0
Input C:
characteristics:
Input C: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 0
2 0.05 - 0.1 0.05 - 0.2 0 +0.2 0
3 0.05 - 0.1 0.05 - 0.2 0 +0.2 0
4 0.05 - 0.1 0.05 - 0.2 0 +0.2 0
Input D:
characteristics:
Input D: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 +4.5
2 Pulse Not Present
3 Pulse Not Present
4 Pulse Not Present
20xx, RTCA, Inc.

557
Step 1: Preamble Pulse Characteristics set to the Extreme Limits of their Tolerance Range
- Part 1
Apply Input A at the receiver input and verify that at least 90 percent of the ADS-
B Messages are correctly decoded.
- Part 2
Apply Input B at the receiver input and verify that no more than 10 percent of the
Apply Input C at the receiver input and verify that no more than 10 percent of the
Apply Input D at the receiver input and verify that no more than 10 percent of the
2.4.4.3.4.7.2 Verification of Criteria for Preamble Acceptance (2.2.4.3.4.7.2)

Appropriate test procedures required to validate 2.2.4.3.4.7.2 are provided in
2.4.4.3.4.7.1.
20xx, RTCA, Inc.

558
2.4.4.3.4.7.3 Verification of Criteria for Data Block Acceptance in ADS-B Message Signals
(2.2.4.3.4.7.3)
This test verifies that ADS-B Messages are accepted when DF=17 or DF=18 and when no
more than seven consecutive bits fail the confidence test, as specified by 2.2.4.3.4.7.3.
Input A:
Equipment:

DF = 17
CA = 0
Power = -50 dBm
The normal data block content shall be modified to contain energy throughout both halves
(i.e., chips) of bit positions 33 to 39. The amplitude of the pulse in the half that would
ordinarily contain no energy shall be 2 dB below the amplitude of the normal pulse in the
other half of the bit position. The data values in bit positions 33 to 39 shall be chosen so
that at least one of these bits will be detected by the UUT with the incorrect bit value.
Input B:
Equipment:

DF = 18
CA = 0
Power = -50 dBm
20xx, RTCA, Inc.

559
Input C:
Equipment:

DF = 17
CA = 0
Power = -50 dBm
Apply Input A at the receiver input and verify that all ADS-B Messages are
correctly decoded.
Apply Input B at the receiver input and verify that all ADS-B Messages are
correctly decoded.
Step 3: Corrupted DF=17 ADS-B Messages - Part 1
Apply Input C at the receiver input and verify that ADS-B Messages are not
decoded.
UUT.
20xx, RTCA, Inc.

560
2.4.4.3.5 Verification of ADS-B Receiver Duty Factor (2.2.4.3.5)

Available ADS-B receiver duty factor (i.e., the percentage of time that the ADS-B Message
Reception function is able to receive and process ADS-B Messages at the required ADS-B
MTL), when the receiver is shared with another receiving function using the 960-1215 MHz
band, is an important consideration in meeting the intended ranges of operation for ADS-B
equipment. The available ADS-B receiver duty factor must be 90 percent or greater, as
specified in 2.2.4.3.5, averaged over a 10 second period. As an exception, if the available
ADS-B receiver duty factor is less than 90 percent, techniques for achieving equivalent
performance may be proposed and substantiated by the following analysis procedure.
Analysis Procedure:
Note that due to the many types of configurations and techniques that may be implemented
in the ADS-B Receiving Subsystem, verification of the Receiver Duty Factor is to be done
by analysis. As such, this procedure does not provide a direct test procedure.
This analysis shall take into consideration all effects presented to the ADS-B Receiving
Subsystem for an interference environment equivalent to the LA2020 traffic scenario used
in Appendix P.
Step 1: Identify Functions that Degrade Receiver Availability
The first step of the analysis is for the ADS-B Receiver manufacturer to
specifically identify all functions that may preclude the use of the ADS-B
Receiver to properly receive ADS-B Messages. Examples of such functions are
provided (but not limited to) as follows:
a. Receiver Self-Test
b. Antenna Self-Test
c. Receiver being used for other than ADS-B Receiving Subsystems
d. Antenna being used for other than ADS-B Receiving Subsystems
e. Receiver being suppressed by other in-band systems, i.e., Mode-S
Transponder, TCAS, DME, JTIDS, etc.
f. Antenna operating in other than omni-directional mode.
For each function that may preclude the use of the ADS-B Receiver to properly
receive ADS-B Messages, the analysis shall establish the probability of the
Receiver not being available to process ADS-B Messages.
Step 2: Establish the Improvements Environment for the Analysis
The Receiver manufacturer shall specifically identify all functions that may
improve the capability of the ADS-B Receiver to receive ADS-B Messages at the
MTL levels specified in 2.2.4.3.1.1, Table 2-79. Examples of such functions are
provided (but not limited to) as follows:
a. Improved antenna gain
20xx, RTCA, Inc.

561
b. Improved Receiver gain (i.e., lower MTL capability)

c. Improved message or signal processing techniques
d. Improved Error Correction techniques
For each function that improves the capability of the ADS-B Receiver to receive
ADS-B Messages, the analysis shall establish the message decode probability that
improvement will realize in the effective Receiver availability at the MTL levels
specified in 2.2.4.3.1.1, Table 2-79.
Step 3: Establish the Equivalent Receiver Performance

From the analysis performed in step 1 and 2 demonstrate that equivalent receiver
performance is sufficient to meet the required equipage class range performance.
Demonstrate that [Receiver Availability (step 1) plus (+) Reception Improvements
(step 2)] is not less than 90% of the total time when averaged over a processing
time of 10 seconds.
2.4.4.4 Verification of Enhanced Squitter Reception Techniques (2.2.4.4)

No specific test procedures are required to validate 2.2.4.4.
2.4.4.4.1 Verification of the Need for Enhanced Squitter Reception Techniques (2.2.4.4.1)
No specific test procedures are required to validate 2.2.4.4.1.
2.4.4.4.2 Verification for the Enhanced Squitter Reception Technique Overview (2.2.4.4.2)
Enhanced squitter reception techniques have been developed (see Appendix I) that provide
the ability to receive squitters with multiple overlapping Mode A/C FRUIT. Class A1S, A1,
A2 and A3 equipment must demonstrate compliance with test procedures specified in
2.4.4.4.2.1 through 2.4.4.4.3.
Note: The full set of enhanced techniques are applicable to Class A2 and A3 receiving
equipment. Class A1S and A1 receiving equipment requires only a subset of the
enhanced reception capabilities, and this is reflected in the test procedures of
2.4.4.4.2.4 and 2.4.4.4.2.5.
20xx, RTCA, Inc.

562
2.4.4.4.2.1 Test Equipment Requirements

Note: This section defines the tests that are conducted to evaluate the performance of the
improved preamble and enhanced squitter reception techniques of the equipment
under test.
The tests consist of injecting special waveforms to test the limits of preamble detection. The
tests then proceed to inject a known Mode S Extended Squitter waveform at a nominal
power level with a defined FRUIT overlap scenario to test the reception of the Extended
Squitter data block. These tests are followed by a test scenario where Mode S FRUIT
precedes a nominal Mode S Extended Squitter waveform to measure the re-triggering
capability. Finally, a test is conducted to verify that the sliding window error correction
technique is not used.
The success criteria for the tests require the monitoring of the Mode S Extended Squitter
data content. This data must be available for test monitoring. Report level monitoring is
not adequate.
In the following tests, the parameter T defines the number of trials that are to be executed.
Unless otherwise indicated, T equals 1000.
2.4.4.4.2.1.1 Mode A/C Fruit Signal Source Requirements

Five RF sources shall be provided that are capable of generating Mode A/C 14-pulse
replies. Each FRUIT source shall be capable of the following:
The waveform shall consist of framing pulses and an average of five data pulses. The data
content of the FRUIT reply shall be pseudo randomly varied each time a FRUIT reply is
generated. The data pulses shall be uniformly pseudo randomly distributed across the 12
data bit positions (the X pulse position shall not be used).
Each FRUIT source shall be able to generate Mode A/C replies at received power levels
ranging from 80 to 58 dBm as required within plus or minus 1 dB.
The FRUIT sources should be able to sustain a repetition rate of at least 100 replies per
second.
The signals for each of the FRUIT sources shall be non-coherent with any of the other
FRUIT sources and the Extended Squitter signal source (2.4.4.4.2.1.3).
The leading edge of the P1 pulse of the Extended Squitter waveform shall be defined as t=0.
The timing of the generation of the beginning of the F1 pulse of each FRUIT reply shall be
controllable to be uniformly pseudo randomly distributed over the interval -20 to +100
microseconds (Combined Extended Squitter preamble and data block with Mode A/C
FRUIT test).
The pseudo random timing of the generation of FRUIT replies from each FRUIT source
shall be independent of the timing of the other FRUIT sources.
20xx, RTCA, Inc.

563
2.4.4.4.2.1.2 Mode S Fruit Signal Source Requirements

One RF source shall be provided that is capable of generating a Mode S 112-bit
transmission as follows:
The content of the 112-bit Mode S transmission shall consist of a valid DF code (16, 17, 18,
20, 21, or 24), an 83-bit field that is set pseudo randomly for each transmission, and a 24-bit
PI field appropriate for the content of this transmission. If an Extended Squitter message
type is used (DF=17 or 18) the test equipment shall be capable of distinguishing the
reception of the desired Extended Squitter from that of the Mode S FRUIT.
The Mode S FRUIT source should be able to sustain a squitter rate of at least 100 squitters
per second.
The Mode S FRUIT source shall be capable of generating a signal power equal to 12 dB
above the minimum MTL required for the equipment class being tested within plus or minus
1 dB with no more than 1 dB droop.
The signal for the Mode S FRUIT source shall be non-coherent with the Extended Squitter
signal source (2.4.4.4.2.1.3).
The leading edge of the P1 pulse of the Extended Squitter waveform shall be defined as t=0.
The timing of the generation of the beginning of the P1 pulse of the Mode S FRUIT
waveform shall be controllable to be uniformly pseudo randomly distributed over a defined
interval or fixed as required by the test procedure. The following define the timing of the
Mode S FRUIT source relative to the Extended Squitter waveform:
+8 to +90 microseconds (Data Block Tests with Mode S Fruit)
-112 to 6 microseconds (Re-triggering Tests with Varying Position Mode S Fruit)
-6 microseconds (Re-triggering Tests with Fixed Position Mode S Fruit)
2.4.4.4.2.1.3 Extended Squitter Signal Source Requirements

One RF source shall be provided that is capable of generating a 112-bit Extended Squitter
transmissions with no more than 1 dB droop as follows:
The Extended Squitter power level shall be adjustable ranging from 21 dBm to
84 dBm within plus or minus 1 dB as required by the test procedures.
The Extended Squitter signal source should be able to sustain a squitter rate of at least 100
squitters per second.
Unless otherwise required, the contents of the Extended Squitter transmission shall consist
of the five-bit DF field set to 17, an 83-bit field that is set pseudo randomly for each
Extended Squitter transmission except for ME Field bits 1 to 5 (the Format TYPE Code)
which may be set to a fixed value, and a 24-bit PI field appropriate for the content of this
transmission.
20xx, RTCA, Inc.

564
Note: The Four-Pulse Preamble Detection tests and the Preamble Validation Tests do not
require pseudo-random message content, all other test procedures do.
Provision shall be made to record the contents of each Extended Squitter transmission
Note: This information is required to check for undetected errors.
The Extended Squitter signal source shall have the capability to selectively control the
width and/or position of individual preamble pulses with at least 25 nanosecond resolution.
The Extended Squitter signal source shall also provide the capability of individually
omitting preamble pulses or any of the first 5 data pulses from the transmission.
2.4.4.4.2.2 Four-Pulse Preamble Detection Tests

These tests verify that the ADS-B reply processor correctly detects the presence of a valid
ADS-B preamble whose pulse characteristics are within the allowable limits and rejects
preambles having pulse spacing and position characteristics that are outside the allowable
limits.
Reference Input:

DF = 17
CA = 0
Power = -23 dBm (for the first preamble pulse level)
Input A:
Same as the Reference Input, but having the following preamble pulse characteristics:

Input A: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 +0.05
2 0.05 - 0.1 0.05 - 0.2 -0.05 +0.100 +2
3 0.05 - 0.1 0.05 - 0.2 +0.05 +0.100 +2
4 0.05 - 0.1 0.05 - 0.2 -0.05 +0.100 0
20xx, RTCA, Inc.

565
Input B:

Input B: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 +0.05
2 0.05 - 0.1 0.05 - 0.2 -0.05 -0.100 +2
3 0.05 - 0.1 0.05 - 0.2 +0.05 -0.100 +2
4 0.05 - 0.1 0.05 - 0.2 -0.05 -0.100 0
Input C:

Input C: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 -0.3
2 0.05 - 0.1 0.05 - 0.2 -3.5 0 0
3 Pulse Not Present
4 Pulse Not Present
Note: Input C sets up a preamble where only P1 and P2 have actual leading edges, while
P3 and P4 have pulse positions provided by the extended P2 pulse. All pulse
positions and leading edges are at nominal positions. This test input verifies that
the UUT accepts a preamble with the minimum 2 actual leading edges using P1 and
P2. The test procedure requires that the UUT accepts this input at a rate of at least
90%.
20xx, RTCA, Inc.

566
Input D:

Input D: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 +1.0
2 Pulse Not Present
3 0.05 - 0.1 0.05 - 0.2 +1.0 0 0
4 Pulse Not Present
Note: Input D sets up a preamble where only P1 and P3 have actual leading edges, while
P2 and P4 have pulse positions provided by the extended P1 and P3 pulses. All
pulse positions and leading edges are at nominal positions. This test input verifies
that the UUT accepts a preamble with the minimum 2 actual leading edges using P1
and P3. The test procedure requires that the UUT accepts this input at a rate of at
least 90%.
Input E:
Table 2-154: Input E: Preamble Pulse Characteristics

Input E: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 +3.5
2 Pulse Not Present
3 Pulse Not Present
4 0.05 - 0.1 0.05 - 0.2 0 0 0
Note: Input E sets up a preamble where only P1 and P4 have actual leading edges, while
P2 and P3 have pulse positions provided by the extended P1 pulse. All pulse
positions and leading edges are at nominal positions. This test input verifies that
the UUT accepts a preamble with the minimum 2 actual leading edges using P1 and
P4. The test procedure requires that the UUT accepts this input at a rate of at least
90%.
20xx, RTCA, Inc.

567
Input F:
Table 2-155: Input F: Preamble Pulse Characteristics

Input F: Preamble Pulse Characteristics
1 0.05 - 0.1 0.05 - 0.2 +1.3 -0.3
2 Pulse Not Present
3 0.05 - 0.1 0.05 - 0.2 0 0 0
4 0.05 - 0.1 0.05 - 0.2 0 0 0
Note: Input F sets up a preamble where only P3 and P4 provide actual leading edges
within the allowable position limits, while P1 and P2 have pulse positions provided
by the extended P1 pulse. Pulse positions and leading edges are located at nominal
positions. This test input verifies that the UUT accepts a preamble with the
minimum 2 actual leading edges using P3 and P4. The test procedure requires that
the UUT accepts this input at a rate of at least 90%.
Input G through W:
The Inputs for G through W are the same as the Reference Input, but having the following
preamble pulse characteristics:
Table 2-156: Inputs G through W: Preamble Pulse Characteristics

Rise time Fall time Width Position Amplitude
Input Set Pulse
1 0.05 - 0.1 0.05 - 0.2 +0.3 -0.3
2 0.05 - 0.1 0.05 - 0.2 0 0 0
Input G
3 0.05 - 0.1 0.05 - 0.2 +0.3 -0.3 0
4 0.05- 0.1 0.05 - 0.2 0 0 0
1 0.05 - 0.1 0.05 - 0.2 +0.3 -0.3
2 0.05 - 0.1 0.05 - 0.2 0 0 0
Input H
3 0.05 - 0.1 0.05 - 0.2 +1.0 0 0
4 Pulse Not Present
1 0.05 - 0.1 0.05 - 0.2 -0.3
2 0.05 - 0.1 0.05 - 0.2 -0.3 0 0
Input I
3 0.05 - 0.1 0.05 - 0.2 -0.3 0 0
4 0.05 - 0.1 0.05 - 0.2 -0.3 0 0
1 0.05 - 0.1 0.05 - 0.2 +4.5
2 Pulse Not Present
Input J
3 Pulse Not Present
4 Pulse Not Present
1 0.05 - 0.1 0.05 0.2 0
Input K
2 0.05 - 0.1 0.05 0.2 +3.5 -0.2 0
20xx, RTCA, Inc.

568

Input Set Pulse
3 Pulse Not Present
4 Pulse Not Present
1 0.05 - 0.1 0.05 0.2 0
2 0.05 - 0.1 0.05 0.2 +3.5 +0.2 0
Input L
3 Pulse Not Present
4 Pulse Not Present
1 0.05 - 0.1 0.05 - 0.2 +1.0
2 Pulse Not Present
Input M
3 0.05 - 0.1 0.05 - 0.2 +1.0 -0.2 0
4 Pulse Not Present
1 0.05 - 0.1 0.05 - 0.2 +1.0
2 Pulse Not Present
Input N
3 0.05 - 0.1 0.05 - 0.2 +1.0 +0.2 0
4 Pulse Not Present
1 0.05 - 0.1 0.05 - 0.2 +3.5
2 Pulse Not Present
Input O
3 Pulse Not Present
4 0.05 - 0.1 0.05 - 0.2 0 -0.2 0
1 0.05 - 0.1 0.05 - 0.2 +3.5
2 Pulse Not Present
Input P
3 Pulse Not Present
4 0.05 - 0.1 0.05 - 0.2 0 +0.2 0
1 0.05 - 0.1 0.05 - 0.2 +1.3 -0.3
2 Pulse Not Present
Input Q
3 0.05 - 0.1 0.05 - 0.2 0 -0.125 0
4 0.05 - 0.1 0.05 - 0.2 0 +0.125 0
1 0.05 - 0.1 0.05 - 0.2 +1.3 -0.3
2 Pulse Not Present
Input R
3 0.05 - 0.1 0.05 - 0.2 0 +0.125 0
4 0.05 - 0.1 0.05 - 0.2 0 -0.125 0
1 0.05 0.1 0.05 - 0.2 +0.3 -0.3
2 0.05 0.1 0.05 - 0.2 0 -0.125 0
Input S
3 0.05 0.1 0.05 - 0.2 +0.3 -0.3 0
4 0.05 0.1 0.05 - 0.2 0 +0.125 0
Input T 1 0.05 0.1 0.05 - 0.2 +0.3 -0.3
20xx, RTCA, Inc.

569

Input Set Pulse
2 0.05 - 0.1 0.05 - 0.2 0 +0.125 0
3 0.05 - 0.1 0.05 - 0.2 +0.3 -0.3 0
4 0.05 - 0.1 0.05 - 0.2 0 -0.125 0
1 0.05 - 0.1 0.05 - 0.2 +0.3 -0.3
2 0.05 - 0.1 0.05 - 0.2 0 -0.125 0
Input U
3 0.05 - 0.1 0.05 - 0.2 +1.0 +.125 0
4 Pulse Not Present
1 0.05 - 0.1 0.05 - 0.2 +0.3 -0.3
2 0.05 - 0.1 0.05 - 0.2 0 +0.125 0
Input V
3 0.05 - 0.1 0.05 - 0.2 +1.0 -.125 0
4 Pulse Not Present
1 Pulse Not Present
2 0.05 - 0.1 0.05 0.2 0 0 0
Input W
3 0.05 - 0.1 0.05 0.2 0 0 0
4 0.05 - 0.1 0.05 0.2 0 0 0
Notes:
1. Input G sets up a preamble where only P2 and P4 provide actual leading edges within the allowable position
limits, while P1 and P3 have pulse positions. Pulse positions and leading edges are located at nominal positions.
This test input verifies that the UUT accepts a preamble with the minimum 2 actual leading edges using P2 and
P4. The test procedure requires that the UUT accepts this input at a rate of at least 90%.
2. Input H sets up a preamble where only P2 and P3 provide actual leading edges within the allowable position
limits, while P1 and P4 have pulse positions provided by the extended P1 and P3 pulses. Pulse positions and
leading edges are located at nominal positions. This test input verifies that the UUT accepts a preamble with the
minimum 2 actual leading edges using P2 and P3. The test procedure requires that the UUT accepts this input at
a rate of at least 90%.
3. Input K sets up a preamble where only P1 and P2 have actual leading edges, while P3 and P4 will have pulse
positions provided by the extended P2 pulse. The P2 leading edge position is offset by -0.2 microseconds. This
test input step verifies that the UUT uses a maximum 0.1 sample pulse leading edge position tolerance using P1
and P2. This is a negative test procedure and requires that the UUT accepts this input at a rate of 10% or less.
4. Input L sets up a preamble where only P1 and P2 have actual leading edges, while P3 and P4 will have pulse
positions provided by the extended P2 pulse. The P2 leading edge position is offset by +0.2 microseconds. This
test input step verifies that the UUT uses a maximum 0.1 sample pulse leading edge position tolerance using P1
5. Input M sets up a preamble where only P1 and P3 have actual leading edges, while P2 and P4 will have pulse
positions provided by the extended P1 and P3 pulses. The P3 leading edge position is offset by -0.2 microseconds.
This test input step verifies that the UUT uses a maximum 1 sample pulse leading edge position tolerance using
P1 and P3. This is a negative test procedure and requires that the UUT accepts this input at a rate of 10% or less.
6. Input N sets up a preamble where only P1 and P3 have actual leading edges, while P2 and P4 will have pulse
positions provided by the extended P1 and P3 pulses. The P3 leading edge position is offset by +0.2
microseconds. This test input step verifies that the UUT uses a maximum 1 sample pulse leading edge position
tolerance using P1 and P3. This is a negative test procedure and requires that the UUT accepts this input at a
rate of 10% or less.
7. Input O sets up a preamble where only P1 and P4 have actual leading edges, while P2 and P3 will have pulse
positions provided by the extended P1 pulse. The P4 leading edge position is offset by -0.2 microseconds. This
test input step verifies that the UUT uses a maximum 1 sample pulse leading edge position tolerance using P1
8. Input P sets up a preamble where only P1 and P4 have actual leading edges, while P2 and P3 will have pulse
positions provided by the extended P1 pulse. The P4 leading edge position is offset by +0.2 microseconds. This
test input step verifies that the UUT uses a maximum 1 sample pulse leading edge position tolerance using P1
20xx, RTCA, Inc.

570
9. The purpose of Input Q is to test that the UUT does not simultaneously apply both a + and sample tolerance.
Input Q sets up a preamble with no actual preamble pulse leading edges in their nominal positions. The P1
position is offset by -0.3 microseconds and width is offset by +1.3 microseconds to replace the missing P2 pulse.
This places the P1 and P2 actual leading edges out of detection range but provides pulse positions at nominal
positions. This focuses the actual leading edge detection on P3 and P4 whose leading edges are offset by -0.125
microseconds and +0.125 microseconds respectively. This is a negative test procedure and requires that the UUT
accepts this input at a rate of 10% or less.
10. The purpose of Input R is to test that the UUT does not simultaneously apply both a + and sample tolerance.
Input R sets up a preamble with no actual preamble pulse leading edges in their nominal positions. The P1
position is offset by -0.3 microseconds and width is offset by +1.3 microseconds to replace the missing P2 pulse.
This places the P1 and P2 actual leading edges out of detection range but provides pulse positions at nominal
positions. This focuses the actual leading edge detection on P3 and P4 whose leading edges are offset by +0.125
microseconds and -0.125 microseconds respectively. This is a negative test procedure and requires that the UUT
accepts this input at a rate of 10% or less.
11. The purpose of Input S is to test that the UUT does not simultaneously apply both a + and sample tolerance.
Input S sets up a preamble with no actual preamble pulse leading edges in their nominal positions. The P1 and
P3 positions are offset by -0.3 microseconds and widths are offset by +0.3 microseconds. This places the P1 and
P3 actual leading edges out of detection range but provides pulse positions at nominal positions. This focuses the
actual leading edge detection on P2 and P4 whose leading edges are offset by -0.125 microseconds and +0.125
microseconds respectively. This is a negative test procedure and requires that the UUT accepts this input at a
12. The purpose of Input T is to test that the UUT does not simultaneously apply both a + and sample tolerance.
Input T sets up a preamble with no actual preamble pulse leading edges in their nominal positions. The P1 and
P3 positions are offset by -0.3 microseconds and widths are offset by +0.3 microseconds. This places the P1 and
P3 actual leading edges out of detection range but provides pulse positions at nominal positions. This focuses the
actual leading edge detection on P2 and P4 whose leading edges are offset by +0.125 microseconds and -0.125
microseconds respectively. This is a negative test procedure and requires that the UUT accepts this input at a
13. The purpose of Input U is to test that the UUT does not simultaneously apply both a + and sample tolerance.
Input U sets up a preamble with no actual preamble pulse leading edges in their nominal positions. The P1
position is offset by -0.3 microseconds and width is offset by +0.3 microseconds. The P3 width is offset by +1.0
microsecond to replace the missing P4 pulse. This places the P1 and P4 actual leading edges out of detection
range but provides pulse positions at nominal positions. This focuses the actual leading edge detection on P2 and
P3 whose leading edges are offset by -0.125 microseconds and +0.125 microseconds respectively. This is a
negative test procedure and requires that the UUT accepts this input at a rate of 10% or less.
14. The purpose of Input V is to test that the UUT does not simultaneously apply both a + and sample tolerance.
Input V sets up a preamble with no actual preamble pulse leading edges in their nominal positions. The P1
position is offset by -0.3 microseconds and width is offset by +0.3 microseconds. The P3 width is offset by +1.0
microsecond to replace the missing P4 pulse. This places the P1 and P4 actual leading edges out of detection
range but provides pulse positions at nominal positions. This focuses the actual leading edge detection on P2 and
P3 whose leading edges are offset by +0.125 microseconds and -0.125 microseconds respectively. This is a
negative test procedure and requires that the UUT accepts this input at a rate of 10% or less.
15. Input W verifies that the UUT requires all 4 preamble pulses to be present. This test step will be repeated 3 times
with each preamble pulse taking a turn as the missing pulse. This is a negative test procedure and requires that
the UUT accepts this input at a rate of 10% or less.
the UUT receiver input port. For each ADS-B equipage class, the specified power level is
adjusted to compensate for the maximum line loss for which the UUT receiver has been
specified in the test procedures is lowered by 3 dB.
20xx, RTCA, Inc.

571
- Part 1
Apply Input A at the receiver input and verify that at least 90 percent of the ADS-
- Part 2
- Part 3
Apply Input B at the receiver input and verify that at least 90 percent of the ADS-
- Part 4
- Part 5
Apply Input C at the receiver input and verify that at least 90 percent of the ADS-
- Part 6
- Part 7
Apply Input D at the receiver input and verify that at least 90 percent of the ADS-
- Part 8
- Part 9
Apply Input E at the receiver input and verify that at least 90 percent of the ADS-
20xx, RTCA, Inc.

572
- Part 10
- Part 11
Apply Input F at the receiver input and verify that at least 90 percent of the ADS-
- Part 12
- Part 13
Apply Input G at the receiver input and verify that at least 90 percent of the ADS-
- Part 14
- Part 15
Apply Input H at the receiver input and verify that at least 90 percent of the ADS-
- Part 16
Apply Input I at the receiver input and verify that no more than 10 percent of the
Apply Input J at the receiver input and verify that no more than 10 percent of the
20xx, RTCA, Inc.

573
Apply Input K at the receiver input and verify that no more than 10 percent of the
Apply Input L at the receiver input and verify that no more than 10 percent of the
Apply Input M at the receiver input and verify that no more than 10 percent of the
Apply Input N at the receiver input and verify that no more than 10 percent of the
Apply Input O at the receiver input and verify that no more than 10 percent of the
20xx, RTCA, Inc.

574
Apply Input P at the receiver input and verify that no more than 10 percent of the
Apply Input Q at the receiver input and verify that no more than 10 percent of the
Apply Input R at the receiver input and verify that no more than 10 percent of the
Apply Input S at the receiver input and verify that no more than 10 percent of the
Apply Input T at the receiver input and verify that no more than 10 percent of the
Apply Input U at the receiver input and verify that no more than 10 percent of the
20xx, RTCA, Inc.

575
Apply Input V at the receiver input and verify that no more than 10 percent of the
Step 45: Missing Preamble Pulse - Part 1
Apply Input W at the receiver input and verify that no more than 10 percent of the
Apply Input W at the receiver input except restore the P1 pulse and remove the P2
pulse and verify that no more than 10 percent of the ADS-B Messages are
correctly decoded.
correctly decoded.
correctly decoded.
20xx, RTCA, Inc.

576
2.4.4.4.2.3 Preamble Validation Tests

These tests verify that the ADS-B reply processor correctly validates the ADS-B preamble.
It is verified that when energy with an amplitude within 6 dB of the preamble reference
level is contained in at least one chip of the first five data bits, the preamble is accepted, and
the preamble is rejected if one or more of the first five data bits has insufficient energy in
either chip.
Reference Input:

DF = 17 (or 18 as indicated in the test procedures)
CA = 0
Power = -23 dBm
The transmitted power in the first six data bits is controlled in such a way that the amplitude
of a data bit can be set independently of the others.
the UUT receiver input port. For each ADS-B equipage class, the specified power level is
adjusted to compensate for the maximum line loss for which the UUT receiver has been
specified in the test procedures is lowered by 3 dB.
For this test to be valid the receiver must perform error correction.
Step 1: Preamble Validation Missing First Data Bit - Part 1
Input the Reference Input DF=17 messages with the amplitude of the first data
bit set to 30 dB into the receiver, and verify that less than 10 percent of the ADS-
Step 2: Preamble Validation Missing First Data Bit - Part 2
Repeat Step 1 with the signal power level at -65 dBm and the first bit at 72 dBm.
20xx, RTCA, Inc.

577
Step 3: Preamble Validation Missing Second Data Bit - Part 1
Input the Reference Input DF=17 messages with the amplitude of the second data
bit set to 30 dBm into the receiver and verify that less than 10 percent of the
Step 4: Preamble Validation Missing Second Data Bit - Part 2
Repeat Step 3 with the signal power level at -65 dBm and the second bit at 72
dBm.
Step 5: Preamble Validation Missing Third Data Bit - Part 1
Input the Reference Input DF=17 messages with the amplitude of the third data
bit set to 30 dBm into the receiver and verify that less than 10 percent of the
Step 6: Preamble Validation Missing Third Data Bit - Part 2
Repeat Step 5 with the signal power level at -65 dBm and the third bit at 72
dBm.
Step 7: Preamble Validation Missing Third and Fourth Data Bit - Part 1
Input the Reference Input DF=17 messages with the amplitude of the third data
pulse (that comprises the third and fourth data bits) set to 30 dBm into the
receiver and verify that less than 10 percent of the ADS-B Messages are correctly
decoded.
Step 8: Preamble Validation Missing Third and Fourth Data Bit - Part 2
Repeat Step 7 with the signal power level at -65 dBm and the third data pulse at
72 dBm.
Step 9: Preamble Validation Missing Fourth and Fifth Data Bit - Part 1
Input the Reference Input DF=17 messages with the amplitude of the fourth data
pulse (that comprises the fourth and fifth data bits) set to 30 dBm into the
receiver and verify that less than 10 percent of the ADS-B Messages are correctly
decoded.
Step 10: Preamble Validation Missing Fourth and Fifth Data Bit - Part 2
Repeat Step 9 with the signal power level at -65 dBm and the fourth data pulse at
72 dBm.
Step 11: Preamble Validation Missing Sixth Data Bit - Part 1
Input the Reference Input DF=17 messages with no energy in either chip of the
sixth data bit into the receiver and verify that greater than 90 percent of the ADS-
20xx, RTCA, Inc.

578
Step 12: Preamble Validation Missing Sixth Data Bit - Part 2
2.4.4.4.2.4 Combined Preamble and Data Block Tests with Mode A/C FRUIT
The following tests measure the performance of the equipment under test in decoding the
Extended Squitter preamble and data block overlapped with Mode A/C FRUIT. The test
series begins with monitoring the reception performance in the absence of interference to
establish that the equipment under test is operating correctly.
Next, a series of tests are conducted with the number of Mode A/C FRUIT overlaps set to
one to five respectively for A2 and A3 equipment class. For A1S and A1 equipment class,
the tests are limited to a maximum of three Mode A/C FRUIT overlaps. For each test, the
timing of the overlapping FRUIT is uniformly pseudo randomly distributed across the
preamble and data block for seven different relative power levels. The FRUIT power levels
will be set according to the test step being conducted and will remain constant while each of
the seven Extended Squitter power levels are tested. T samples (2.4.4.4.2.1) are taken at
each power level. Squitters that are declared to be correctly received (i.e., received without
errors or successfully error corrected) are compared to the known content of the Extended
Squitter transmission. Any difference between the content of the decoded Extended Squitter
and the known content of the injected squitter is recorded as an undetected error and that
squitter reception is removed from the count of successfully received squitters.
The observed probability of correct squitter reception for each relative power level is
computed. An average value of the performance across all power levels is computed and
compared to the required performance to determine success or failure for the test.
Connect the Extended Squitter signal source and set the power level at the receiver
input equal to the MTL limit required for the UUT equipment class:
79 dBm for A1S and A1 equipment class or,
79 dBm for A2 equipment class or,
Note: The power levels given above are specified at the antenna connector and
not at the receiver unit-under-test connector.
Inject the Extended Squitter signal T times (2.4.4.4.2.1) and record the Extended
Squitters that are declared to be output as error free. Compare the decoded
content of each Extended Squitter with the known content of the injected
Extended Squitter. Any differences that are detected are recorded as an
undetected error and that squitter reception is deleted from the count of error free
receptions.
20xx, RTCA, Inc.

579

Step 2: Test with One Mode A/C Fruit Overlap
Set the power level of one Mode A/C FRUIT source at the receiver input to the
value corresponding to the UUT equipment class:
Activate the Mode A/C FRUIT source so that the FRUIT is pseudo randomly
distributed across the Extended Squitter preamble and data block as specified in
2.4.4.4.2.1.
Inject the Extended Squitter waveform T times (2.4.4.4.2.1) and record the
receptions that are declared to be error free. Check for undetected errors and
adjust as necessary the number of correctly received replies as specified in Step 1.
undetected errors.
Repeat the above step six times while increasing the Extended Squitter power
level by 4 dB with each iteration.
Calculate the average probability of reception and the total number of undetected
errors across the seven power levels.
Step 3: Test with Two Mode A/C Fruit Overlaps
Repeat Step 2 with two FRUIT overlaps set to the following power levels and
record the results:
-69 and 65 dBm for A1S, A1 or A2 equipment class or,
-74 and 70 dBm for A3 equipment class.
20xx, RTCA, Inc.

580
Step 4: Test with Three Mode A/C Fruit Overlaps
Repeat Step 2 with three FRUIT overlaps set to the following power levels and
record the results:
-71, -67 and 63 dBm for A1S, A1 or A2 equipment class or,
-76, -72 and 68 dBm for A3 equipment class.
Step 5: Test with Four Mode A/C Fruit Overlaps
Repeat Step 2 with four FRUIT overlaps set to the following power levels and
record the results:
-73, -69, -65 and 61 dBm for A2 equipment class or,
-78, -74, -70 and 66 dBm for A3 equipment class.
Step 6: Test with Five Mode A/C Fruit Overlaps
Repeat Step 2 with five FRUIT overlaps set to the following power levels and
record the results:
-75, -71, -67, -63 and 59 dBm for A2 equipment class or,
-80, -76, -72, -68 and 64 dBm for A3 equipment class.
Compare the results recorded above with the appropriate requirements in Table 2-
157, Table 2-158 or Table 2-159.
with Mode A/C Fruit Class A1S and A1 Equipment
Number of Fruit 1 2 3
Minimum Probability 0.89 0.64 0.52

Max Undetected Errors 1 1 1
20xx, RTCA, Inc.

581
Number of Fruit 1 2 3 4 5
Minimum Probability 0.93 0.89 0.88 0.79 0.74

Max Undetected Errors 1 1 1 1 1
Number of Fruit 1 2 3 4 5
Minimum Probability 0.94 0.91 0.90 0.86 0.85

Max Undetected Errors 1 1 1 1 1
2.4.4.4.2.5 Data Block Tests with Mode S Fruit

The following tests measure the performance of the equipment under test in decoding the
Extended Squitter data content overlapped with Mode S FRUIT. The test series begins with
monitoring the reception performance in the absence of interference to establish that the
equipment under test is operating correctly.
Next, a test is conducted with a single Mode S FRUIT overlap. For this test, the timing of
the overlapping FRUIT is uniformly pseudo randomly distributed across the data block for
four different relative power levels. T samples (2.4.4.4.2.1) are taken at each power level.
Squitters that are declared to be correctly received (i.e., received without errors or
successfully error corrected) are compared to the known content of the Extended Squitter
transmission. Any difference between the content of the decoded Extended Squitter and the
known content of the injected squitter is recorded as an undetected error and that squitter
reception is removed from the count of successfully received squitters.
Finally, the observed probability of correct squitter reception for each relative power level is
computed.
Connect the Extended Squitter signal source. Set and verify that the power level at
the receiver input is equal to the MTL limit required for the UUT equipment class
plus 12 dB:
20xx, RTCA, Inc.

582
Inject the signal T times (2.4.4.4.2.1) and record the Extended Squitters that are
declared to be output as error free. Compare the decoded content of each
Extended Squitter with the known content of the injected Extended Squitter. Any
differences that are detected are recorded as an undetected error and that squitter
reception is deleted from the count of error free receptions.

Step 2: Test with One Mode S Fruit Overlap
Activate the Mode S FRUIT source so that the Mode S FRUIT is pseudo
randomly distributed across the data Extended Squitter data block as specified in
2.4.4.4.2.1.2.
Set the Extended Squitter power to 0 dB relative to the Mode S FRUIT signal
level.
undetected errors.
Repeat the above step for relative powers of signal to interference (S/I) of +4, +8,
and + 12 dB.
Calculate the probability of correct reception and the number of undetected errors
for each of the four power levels.
160, Table 2-161 or Table 2-162.

with Mode S Fruit Class A1S and A1 Equipment
Relative Power (S/I) dB 0 +1 +2 +3 +4 +5 +6 +7 +8 +12
Minimum Probability 0 0 0.02 0.12 0.56 0.71 0.94 0.95 0.99 0.99
Max Undetected Errors 1 1 1 1 1 1 1 1 1 1
20xx, RTCA, Inc.

583


2.4.4.4.2.6 Re-Triggering Performance

The following tests measure the capability of the equipment under test to detect Extended
Squitters that are preceded by lower level Mode S FRUIT. The test series begins with
monitoring the reception performance in the absence of interference to establish that the
equipment under test is operating correctly.
Next, a test is conducted with a single Mode S FRUIT overlap with a varying position. For
this test, the timing of the overlapping FRUIT is uniformly pseudo randomly distributed
across the time interval beginning at 112 microseconds and ending at 6 microseconds
relative to the leading edge of the P1 preamble pulse of the Extended Squitter.
Finally, a test is conducted with a single Mode S FRUIT overlap with a fixed position. For
this test, the timing of the overlapping FRUIT is fixed at 6 microseconds relative to the
leading edge of the P1 preamble pulse of the Extended Squitter.
The re-triggering performance tests are conducted at three different relative power levels. T
samples (2.4.4.4.2.1) are taken at each power level. Squitters that are declared to have
been correctly received (i.e., received without errors or successfully error corrected) are
compared to the known content of the Extended Squitter transmission. Any difference
between the content of the decoded Extended Squitter and the known content of the injected
squitter is recorded as an undetected error and that squitter reception is removed from the
count of successfully received squitters. The observed probability of correct squitter
reception for each relative power level is computed.
20xx, RTCA, Inc.

584
Connect the Extended Squitter signal source. Set and verify that the power level
at the receiver input is equal to the MTL limit required for the UUT equipment
class plus 12 dB:
Inject the signal T times (2.4.4.4.2.1) and record the Extended Squitters that are
declared to be output as error free. Compare the decoded content of each
Extended Squitter with the known content of the injected Extended Squitter. Any
differences that are detected are recorded as an undetected error and that squitter
reception is deleted from the count of error free receptions.

Step 2: Re-triggering Test with Varying Position Mode S Fruit
Connect the Mode S Fruit signal source. Set and verify that the power level at the
receiver input is equal to the MTL limit required for the UUT equipment class
plus 12 dB:
level.
Activate the Mode S FRUIT source so that the 112-bit Mode S FRUIT signal is
uniformly randomly distributed across the time interval beginning at 112
microseconds and ending at 6 microseconds relative to the signal. The time
indicated is the spacing between the P1 pulse of the signal and the P1 pulse of the
FRUIT, where negative values indicate that the FRUIT is received earlier.
20xx, RTCA, Inc.

585

undetected errors.
Repeat the above step for relative powers of Signal to Interference (S/I) of +8, and
+ 12 dB.
for each of the three power levels.
163, Table 2-164 or Table 2-165.

with Varying Position Mode S Fruit Class A1S and A1 Equipment
Relative Power, (S/I) dB +4 +8 +12





20xx, RTCA, Inc.

586
Step 3: Re-triggering Test with Fixed Position Mode S Fruit
Connect the Mode S Fruit signal source. Set and verify that the power level at the
receiver input is equal to the MTL limit required for the UUT equipment class
plus 12 dB:
level.
Activate the Mode S FRUIT source so that the 112-bit Mode S FRUIT signal has
a fixed time 6 microseconds earlier than the signal. The 6-microsecond time is the
spacing between the P1 pulse of the Mode S FRUIT and the P1 pulse of the signal.
undetected errors.
Repeat the above step for relative powers of Signal to Interference (S/I) of +8, and
+12 dB.
for each of the three power levels.
166, Table 2-167 or Table 2-168.

with Fixed Position Mode S Fruit Class A1S and A1 Equipment
Minimum Probability 0 0.49 0.87


with Fixed Position Mode S Fruit Class A2 Equipment

20xx, RTCA, Inc.

587

with Fixed Position Mode S Fruit Class A3 Equipment

2.4.4.4.3 Verification of Error Correction (2.2.4.4.3)
2.4.4.4.3.1 Verification of Error Correction Requirements (2.2.4.4.3.1)

ADS-B Receiving Subsystems either:
a. use conservative and brute force error correction techniques as defined in I.4.3, or
b. use alternative error correction techniques that are demonstrated to provide no more
than 1 x (10-6) report error rate.
An analysis of the hardware/software design may be performed showing that conservative

and brute force error correction techniques have been used, or that the alternative techniques
meet the required undetected report error rate.
2.4.4.4.3.2 Verification of Error Correction Restrictions (2.2.4.4.3.2)

This test verifies that the sliding window error correction technique, which is used in TCAS,
is not being used in the unit under test. In lieu of this test procedure, an analysis of the
hardware/software design may be performed showing that a sliding window error correction
technique is not used.
To carry out this test, it is necessary to introduce several low-confidence flags (see Figure 2-
33) for which the corresponding information bit is incorrect in some case and in other cases
low-confidence flags for which the corresponding bit is correct. Introducing such errors and
flags may be done in different ways for different receiver designs. Given that the
implementation specifics for enhanced reception are not rigidly standardized (whereas the
reception performance is standardized), the specific means for introducing the bit errors and
flags is implementation dependent.
Note: See Appendix I, I.3.3 and I.4.3 for more details on error correcting techniques.
20xx, RTCA, Inc.

588
Figure 2-33: Bit Error and Low Confidence Flags
Equipment Required:
Provide a method of supplying the unit under test with any valid ADS-B Message having:
DF = 17
CA = 0
Message Rate = 1 Hz
Power = -50 dBm
Also provide an interference generator that can generate multiple interference pulses, in
order to introduce bit errors and low confidence flags.
Apply tha ADS-B Input Message without interference. Verify that there is at least
99% correct reception.
Step 2: Test with Low Confidence Flags
Add interfering pulses in a way that introduces six (6) low-confidence flags within
a 24-microsecond window and three (3) additional low-confidence flags away
from the 24-microsecond window. The 24-microsecond window begins with the
first low-confidence flag. For the six affected bits in 24-microseconds, one is to
have a bit error, and the other five are to have correct bit declaration. For the three
bits away from the 24-microsecond window, all three are to have correct bit
declaration. Verify that the message is not accepted under this condition.
2.4.4.5 Verification of ADS-B Received Message Error Protection (2.2.4.5)

Appropriate test procedures to verify the requirements of 2.2.4.5 are provided in
2.4.4.3.4.7.3.
20xx, RTCA, Inc.

589
2.4.5 Verification of ADS-B Transmission Device Message Processor Characteristics (2.2.5)

No specific test procedures are required to validate 2.2.5.
2.4.5.1 Verification of ADS-B Transmission Device Data Processing and Message Formatting
(2.2.5.1)
2.4.5.1.1 Verification of the Participant Address (2.2.5.1.1)

2.4.5.1.1.1 Verification of the ICAO 24-Bit Address (2.2.5.1.1.1)

Appropriate test procedures required to validate the requirements of 2.2.5.1.1.1 were
previously provided in 2.4.3.2.1.7 during verification of the PI field.
2.4.5.1.1.2 Verification of the Anonymous Address (2.2.5.1.1.2)

previously provided in 2.4.3.2.1.5 during verification of the AA field for Non-
Transponder Devices.
2.4.5.1.1.3 Verification of the Address Qualifier for Non-Transponder Devices (2.2.5.1.1.3)

previously provided in 2.4.3.2.1.5 during verification of the AA field for Non-
Transponder Devices.
2.4.5.1.2 Verification of ADS-B Emitter Category Data (2.2.5.1.2)

Appropriate test procedures required to validate the requirements of 2.2.5.1.2 were
previously provided in 2.4.3.2.5.2 during verification of the Emitter Category Data in the
Aircraft Identification and Category Message.
2.4.5.1.3 Verification of Air/Ground Status Data (2.2.5.1.3)

previously provided in 2.4.3.2.1.2 through 2.4.3.2.1.2.2 during verification of the CA
field.
20xx, RTCA, Inc.

590
2.4.5.1.4 Verification of Surveillance Status Data (2.2.5.1.4)

previously provided in 2.4.3.2.3.2 during verification of Surveillance Status in the
2.4.5.1.5 Verification of Altitude Data (2.2.5.1.5)

previously provided in 2.4.3.2.3.4 through 2.4.3.2.3.4.3 during verification of Altitude
data provided in the Airborne Position Message.
2.4.5.1.6 Verification of Time Data and Time Mark Pulse (2.2.5.1.6)

No specific test procedure is required to validate the requirements of 2.2.5.1.6.
2.4.5.1.6.1 Verification of Case, where TIME (T) = 0 (2.2.5.1.6.1)

previously provided in 2.4.3.2.3.5, 2.4.3.2.3.7.2.2 and 2.4.3.2.3.8.2.2 for the Airborne
Position Message and 2.4.3.2.4.5, 2.4.3.2.4.7.2.2 and 2.4.3.2.4.8.2.2 for the Surface
Position Message.
2.4.5.1.6.2 Verification of Case, where TIME (T) = 1 (2.2.5.1.6.2)

previously provided in 2.4.3.2.3.5, 2.4.3.2.3.7.2.1 and 2.4.3.2.3.8.2.1 for the Airborne
Position Message and 2.4.3.2.4.5, 2.4.3.2.4.7.2.1 and 2.4.3.2.4.8.2.1 for the Surface
Position Message.
2.4.5.1.7 Verification of Own Position Latitude Data (2.2.5.1.7)

previously provided in 2.4.3.2.3.7.1 through 2.4.3.2.3.7.4 for the Airborne Position
Message and 2.4.3.2.4.7.1 through 2.4.3.2.4.7.4 for the Surface Position Message.
2.4.5.1.8 Verification of Own Position Longitude Data (2.2.5.1.8)

previously provided in 2.4.3.2.3.8.1 through 2.4.3.2.3.8.4 for the Airborne Position
Message and 2.4.3.2.4.8.1 through 2.4.3.2.4.8.4 for the Surface Position Message.
20xx, RTCA, Inc.

591
2.4.5.1.9 Verification of Ground Speed Data (2.2.5.1.9)

previously provided in 2.4.3.2.4.2 during verification of the Movement subfield in the
Surface Position Message.
2.4.5.1.10 Verification of Heading/Ground Track Data (2.2.5.1.10)

previously provided in 2.4.3.2.4.3 and 2.4.3.2.4.4 during verification of Heading/Ground
Track information provided in the Surface Position Message.
2.4.5.1.11 Verification of Aircraft Identification (or Registration) Data (2.2.5.1.11)

previously provided in 2.4.3.2.5.3 during verification of Character information provided in
2.4.5.1.12 Verification of East/West Velocity Data (2.2.5.1.12)

previously provided in 2.4.3.2.6.1.6 and 2.4.3.2.6.1.7 for Subtype=1 Velocity Messages
and in 2.4.3.2.6.2.6 and 2.4.3.2.6.2.7 for Subtype=2 Velocity Messages.
2.4.5.1.13 Verification of North/South Velocity Data (2.2.5.1.13)

and in 2.4.3.2.6.2.8 and 2.4.3.2.6.2.9 for Subtype=2 Velocity Messages.
2.4.5.1.14 Verification of Vertical Rate Data (2.2.5.1.14)

previously provided in 2.4.3.2.6.1.10 and 2.4.3.2.6.1.11 for Subtype=1 Velocity
Messages and in 2.4.3.2.6.2.10 and 2.4.3.2.6.2.11 for Subtype=2 Velocity Messages.
2.4.5.1.15 Verification of Heading Data (2.2.5.1.15)

previously provided in 2.4.3.2.6.3.6 and 2.4.3.2.6.3.7 for Subtype=3 and 4 Velocity
Messages.
20xx, RTCA, Inc.

592
2.4.5.1.16 Verification of True Airspeed Data (2.2.5.1.16)

and 2.4.3.2.6.4.8 and 2.4.3.2.6.4.9 for Subtype=4 Velocity Messages.
2.4.5.1.17 Verification of Indicated Airspeed Data (2.2.5.1.17)

and 2.4.3.2.6.4.8 and 2.4.3.2.6.4.9 for Subtype=4 Velocity Messages.
2.4.5.1.18 Verification of Intent Change Data (2.2.5.1.18)

previously provided in 2.4.3.2.6.1.3 for Subtype=1 through 4 Velocity Messages.
2.4.5.1.19 Verification of NACV Data (2.2.5.1.19)

previously provided in 2.4.3.2.6.1.5 for Subtype=1 through 4 Velocity Messages.
2.4.5.1.20 Verification of Subtype (Aircraft Status) Data (2.2.5.1.20)

2.4.5.1.21 Verification of Capability Class (Reserved) Data (2.2.5.1.21)

previously provided in 2.4.3.2.7.2.3.1.
2.4.5.1.22 Verification of Capability Class (UAT IN) Data (2.2.5.1.22)

2.4.5.1.23 Verification of Capability Class (1090ES IN) Data (2.2.5.1.23)

20xx, RTCA, Inc.

593
2.4.5.1.24 Verification of Capability Class (ARV Report Capability) Data (2.2.5.1.24)

2.4.5.1.25 Verification of Capability Class (TS Report Capability) Data (2.2.5.1.25)

2.4.5.1.26 Verification of Capability Class (TC Report Capability) Data (2.2.5.1.26)

2.4.5.1.27 Verification of Capability Class (Position Offset Applied) Data (2.2.5.1.27)

2.4.5.1.28 Verification of Operational Mode (OM Format) Data (2.2.5.1.28)

2.4.5.1.29 Verification of Operational Mode (TCAS/ACAS Resolution Advisory Active) Data

(2.2.5.1.29)
2.4.5.1.30 Verification of Operational Mode (IDENT Switch Active) Data (2.2.5.1.30)

2.4.5.1.31 Verification of Operational Mode (Reserved for Receiving ATC Services) Data
(2.2.5.1.31)
20xx, RTCA, Inc.

594
2.4.5.1.32 Verification of the Radio Altitude Data (2.2.5.1.32)

previously provided in 2.4.3.2.1.2.
2.4.5.1.33 Verification of the Version Number Data (2.2.5.1.33)

2.4.5.1.34 Verification of Navigation Accuracy Category for Position (NACP) Data (2.2.5.1.34)
previously provided in 2.4.3.2.7.1.3.8 and 2.4.3.2.7.2.7.
2.4.5.1.35 Verification of Navigation Integrity Category for Barometric Altitude (NICBARO) Data
(2.2.5.1.35)
2.4.5.1.36 Verification of Navigation Integrity Category Supplement (NICSUPP) Data (2.2.5.1.36)

previously provided in 2.4.3.2.3.3 and 2.4.3.2.7.2.6.
2.4.5.1.37 Verification of A/V Length/Width Code Data (2.2.5.1.37)

2.4.5.1.38 Verification of Track Angle/Heading Data (2.2.5.1.38)

2.4.5.1.39 Verification of Horizontal Reference Direction (HRD) Data (2.2.5.1.39)

20xx, RTCA, Inc.

595
2.4.5.1.40 Verification of Source Integrity Level (SIL) Data (2.2.5.1.40)

2.4.5.1.41 Verification of SIL Supplement Data (2.2.5.1.41)

2.4.5.1.42 Verification of MCP/FCU Selected Altitude or FMS Selected Altitude Data

(2.2.5.1.42)
2.4.5.1.43 Verification of Barometric Pressure Setting (Minus 800 millibars) Data (2.2.5.1.43)
2.4.5.1.44 Verification of Selected Heading Data (2.2.5.1.44)

Appropriate test procedures required to validate the requirements of 2.2.5.1.44were
2.4.5.1.45 Verification of MCP/FCU Mode Bits Data (2.2.5.1.45)

previously provided in 2.4.3.2.7.1.3.11 through 2.4.3.2.7.1.3.16.
2.4.5.1.46 Verification of Emergency/Priority Status Data (2.2.5.1.46)

2.4.5.1.47 Verification of Mode A (4096) Code Data (2.2.5.1.47)

20xx, RTCA, Inc.

596
2.4.5.1.48 Verification of TCAS Operational Data (2.4.3.2.7.2.3.2)

2.4.5.1.49 Verification of Single Antenna Flag Data (2.2.3.2.7.2.4.5)

2.4.5.1.50 Verification of System Design Assurance (SDA) Data (2.2.3.2.7.2.4.6)

2.4.5.1.51 Verification of GNSS Vertical Figure of Merit (VFOM) Data (2.2.3.2.7.2.8)

2.4.5.2 ADS-B Transmission Device Message Latency (2.2.5.2)

No specific test procedure is required to validate the requirements of 2.2.5.2.
2.4.5.2.1 Verification of Airborne Position Message Latency (2.2.5.2.1)

This test verifies the latency of the Airborne Position Message.
Step 1: Airborne Position Message - TYPE Subfield (2.2.3.2.3.1 and 2.2.5.2.1.a)
Any change in the TYPE information identified in 2.2.3.2.3.1, or in the NIC

Supplement information identified in 2.2.3.2.3.3, shall be reflected in the TYPE
subfield of the next scheduled Airborne Position Message transmission provided
scheduled Airborne Position Message transmission.

Messages by providing position information at the nominal update rate. Provide
the data externally at the interface to the ADS-B system. Set the ADS-B
20xx, RTCA, Inc.

597
pressure altitude data to the ADS-B System. Continue transmitting Airborne

Position Messages at the nominal rate with all parameters unchanged. Verify that
the TYPE subfield in the Airborne Position Message correctly matches the TYPE
subfield value from the navigational accuracy depicted in Table 2-16.
Change input to the ADS-B System so as to affect the TYPE subfield value so
scheduled Airborne Position Message transmission. Verify that the TYPE
subfield value has changed in the next transmitted Airborne Position Message and
that it is the correct value.
Change input to the ADS-B System so as to affect the NIC Supplement subfield
value so that the change occurs and is detected at least 100 milliseconds prior to
the next scheduled Airborne Position Message transmission. Verify that the NIC
Supplement subfield value has changed in the next transmitted Airborne Position
Message and that it is the correct value.
Step 2: Airborne Position Message Surveillance Status Subfield (2.2.3.2.3.2 and

2.2.5.2.1.b)
Any change in the Surveillance Status identified in 2.2.3.2.3.2 shall be reflected

in the Surveillance Status subfield of the next scheduled Airborne Position
Message transmission provided that the change occurs and is detected at least 100
milliseconds prior to the next scheduled Airborne Position Message transmission.

Transmitting Subsystem to Airborne status. Provide valid non zero barometric
the Surveillance Status subfield in the Airborne Position Message correctly
matches the Surveillance Status subfield value from the code definitions
depicted in Table 2-17.
Change input to the ADS-B System so as to affect the Surveillance Status

subfield value so that the change occurs and is detected at least 100 milliseconds
prior to the next scheduled Airborne Position Message transmission. Verify that
the Surveillance Status subfield value has changed in the next transmitted
Airborne Position Message and that it is the correct value.
Step 3: Airborne Position Message Altitude Subfield (2.2.3.2.3.4 and 2.2.5.2.1.c)
Any change in the Altitude identified in 2.2.3.2.3.4 shall be reflected in the

Altitude subfield of the next scheduled Airborne Position Message transmission
20xx, RTCA, Inc.

598
provided that the change occurs and is detected at least 100 milliseconds prior to
the next scheduled Airborne Position Message transmission.

Transmitting Subsystem to Airborne status. Provide valid non zero barometric
the Altitude subfield in the Airborne Position Message is correct.
Change input to the ADS-B System so as to affect the Altitude subfield value so
scheduled Airborne Position Message transmission. Verify that the Altitude
subfield value has changed in the next transmitted Airborne Position Message and
that it is the correct value.
Step 4: Airborne Position Message CPR Format Subfield (2.2.3.2.3.6 and

2.2.5.2.1.d)
Appropriate test procedures to verify 2.2.5.2.1.d are provided in 2.4.3.2.3.7.2

and 2.4.3.2.3.8.2.
Step 5: Airborne Position Message Encoded Latitude Subfield (2.2.3.2.3.7 and

2.2.5.2.1.e)
Appropriate test procedures to verify 2.2.5.2.1.e are provided in 2.4.3.2.3.7.2

and 2.4.3.2.3.8.2.
Step 6: Airborne Position Message Encoded Longitude Subfield (2.2.3.2.3.8 and

2.2.5.2.1.f)
Appropriate test procedures to verify 2.2.5.2.1.f are provided in 2.4.3.2.3.7.2

and 2.4.3.2.3.8.2.
2.4.5.2.2 Verification of Surface Position Message Latency (2.2.5.2.2)

This test verifies the latency of the Surface Position Message.
Step 1: Surface Position Message TYPE Subfield (2.2.3.2.4.1 and 2.2.5.2.2.a)
Any change in the TYPE information identified in 2.2.3.2.4.1 shall be reflected

in the TYPE subfield of the next scheduled Surface Position Message transmission
20xx, RTCA, Inc.

599
provided that the change occurs and is detected at least 100 milliseconds prior to
the next scheduled Surface Position Message transmission.

Transmitting Subsystem to Surface status. Continue transmitting Surface Position
Messages at the nominal rate with all parameters unchanged. Verify that the
TYPE subfield in the Surface Position Message correctly matches the TYPE
subfield value from the navigational accuracy depicted in Table 2-16 for TYPE
codes 5, 6, 7 and 8 only.
Change input to the ADS-B System so as to affect the TYPE subfield value so
scheduled Surface Position Message transmission. Verify that the TYPE subfield
value has changed in the next transmitted Surface Position Message and that it is
the correct value.
Step 2: Surface Position Message Movement Subfield (2.2.3.2.4.2 and 2.2.5.2.2.b)
Any change in Movement (i.e., Ground Speed) identified in 2.2.3.2.4.2 shall be

reflected in the Movement subfield of the next scheduled Surface Position
Message transmission provided that the change occurs and is detected at least 100
milliseconds prior to the next scheduled Surface Position Message transmission.

Movement subfield in the Surface Position Message correctly matches the
Movement subfield value from the Movement subfield Code Definitions in Table
2-18.
Change input to the ADS-B System so as to affect the Movement subfield value
so that the change occurs and is detected at least 100 milliseconds prior to the
next scheduled Surface Position Message transmission. Verify that the
Movement subfield value has changed in the next transmitted Surface Position
Message and that it is the correct value.
20xx, RTCA, Inc.

600
Step 3: Surface Position Message Ground Track Subfield (2.2.3.2.4.3, 2.2.3.2.4.4

and 2.2.5.2.2.c)
Any change in Ground Track identified in 2.2.3.2.4.3 and 2.2.3.2.4.4 shall be

reflected in the appropriate Ground Track subfields of the next scheduled Surface
least 100 milliseconds prior to the next scheduled Surface Position Message
transmission.

Ground Track subfields in the Surface Position Message correctly matches the
Ground Track subfield values from the Table 2-19 and Table 2-20 (2.2.3.2.4.3
and 2.2.3.2.4.4).
Change input to the ADS-B System so as to affect the Ground Track subfield
values so that the change occurs and is detected at least 100 milliseconds prior to
the next scheduled Surface Position Message transmission. Verify that the
Ground Track subfield values have changed in the next transmitted Surface
Position Message and that they contain the correct values.
Step 4: Surface Position Message CPR Format Subfield (2.2.3.2.4.6 and 2.2.5.2.2.d)
Appropriate test procedures to verify 2.2.5.2.2.d are provided in 2.4.3.2.3.7.2

and 2.4.3.2.3.8.2.
Step 5: Surface Position Message Encoded Latitude Subfield (2.2.3.2.4.7 and

2.2.5.2.2.e)
Appropriate test procedures to verify 2.2.5.2.2.e are provided in 2.4.3.2.3.7.2

and 2.4.3.2.3.8.2.
Step 6: Surface Position Message Encoded Longitude Subfield (2.2.3.2.4.8 and

2.2.5.2.2.f)
Appropriate test procedures to verify 2.2.5.2.2.f are provided in 2.4.3.2.3.7.2

and 2.4.3.2.3.8.2.
2.4.5.2.3 Verification of Aircraft Identification and Category Message Latency (2.2.5.2.3)

This test verifies the latency of the Aircraft Identification and Category Message.
20xx, RTCA, Inc.

601
Step 1: Aircraft Identification and Category Message TYPE Subfield (2.2.3.2.5.1

and 2.2.5.2.3.a)
The TYPE information for the Aircraft Identification Message should be fixed and
therefore not change. However, if changes are imposed, any such change in the
TYPE information identified in 2.2.3.2.5.1 shall be reflected in the TYPE
subfield of the Aircraft Identification Message once the data has been stable (i.e.,
no changes) for a period of 4 seconds.
Configure the ADS-B Transmitting Subsystem to transmit Aircraft Identification

the data externally at the interface to the ADS-B system. Continue transmitting
Aircraft Identification Messages at the nominal rate with all parameters
unchanged.
Change input to the ADS-B System so as to force a change in the TYPE subfield
value. Continue transmitting Aircraft Identification Messages at the nominal rate
with all parameters unchanged for a minimum of 4 seconds. Verify that the
Aircraft Identification Message accurately reflects the change in the TYPE
subfield once the data has been unchanged for a period of 4 seconds.
Step 2: Aircraft Identification and Category Message Emitter Category Subfield

(2.2.3.2.5.2 and 2.2.5.2.3.b)
ADS-B Emitter Category information for the Aircraft Identification Message

should be fixed and therefore not change. However, if changes are imposed, any
such change in the ADS-B Emitter Category information identified in 2.2.3.2.5.2
shall be reflected in the ADS-B Emitter Category subfield of the Aircraft
Identification Message once the data has been stable (i.e., no changes) for a period
of 4 seconds.

unchanged.
Change input to the ADS-B System so as to force a change in the ADS-B Emitter
Category subfield value. Continue transmitting Aircraft Identification Messages
at the nominal rate with all parameters unchanged for a minimum of 4 seconds.
Verify that the Aircraft Identification Message accurately reflects the change in
the ADS-B Emitter Category subfield once the data has been unchanged for a
period of 4 seconds.
20xx, RTCA, Inc.

602
Step 3: Aircraft Identification and Category Message Character Subfields

(2.2.3.2.5.3 and 2.2.5.2.3.c)
Any change in Character information identified in 2.2.3.2.5.3 shall be reflected

in the appropriate Character subfields of the Aircraft Identification message once
the data has been stable (i.e., no changes) for a period of 4 seconds.

unchanged.
Change input to the ADS-B System so as to force a change in the Character

subfield value. Continue transmitting Aircraft Identification Messages at the
nominal rate with all parameters unchanged for a minimum of 4 seconds. Verify
that the Aircraft Identification Message accurately reflects the change in the
Character subfield once the data has been unchanged for a period of 4 seconds.
2.4.5.2.4 Verification of Airborne Velocity Message Subtype=1 Latency (2.2.5.2.4,

2.2.3.2.6.1)
The following test procedures are used to test Airborne Velocity Messages Subtype=1
transmitted by Airborne ADS-B Transmitting Subsystems when Velocity Over Ground
information is available, and the transmitting device is installed in an environment having
NON-supersonic airspeed capabilities. These test procedures verify that any changes in the
data used to structure the subfields of the Airborne Velocity Message - Subtype=1 are
reflected in the affected subfield of the next scheduled Airborne Velocity Message -
Subtype=1 provided that the change occurs and is detected at least 100 milliseconds prior to
the next scheduled Airborne Velocity Message - Subtype=1 transmission.
Step 1: Airborne Velocity Message - Subtype=1 TYPE Subfield (2.2.3.2.6.1.1 and

2.2.5.2.4)

Messages Subtype=1 by providing subsonic velocity information at the nominal
the ADS-B Transmitting Subsystem to Airborne status. Provide valid non zero
subsonic velocity data to the ADS-B System. Continue transmitting Airborne
Velocity Messages - Subtype=1 at the nominal rate with all parameters
unchanged. Verify that the TYPE subfield in the Airborne Velocity Message
20xx, RTCA, Inc.

603
Subtype=1 equals 19, which is the only TYPE value assigned to Airborne
Velocity Messages.
Step 2: Airborne Velocity Message - Subtype=1 Subtype Subfield (2.2.3.2.6.1.2 and

2.2.5.2.4)
Continue transmitting Airborne Velocity Messages - Subtype=1 at the nominal

rate with all parameters unchanged. Increase the velocity data input to the ADS-
B System to a supersonic value so that the change occurs and is detected at least
100 milliseconds prior to the next scheduled Airborne Velocity Message
transmission. Verify that the Subtype subfield value has changed to TWO (2)
in the next transmitted Airborne Velocity Message.
Step 3: Airborne Velocity Message - Subtype=1 Intent Change Flag Subfield

(2.2.3.2.6.1.3 and 2.2.5.2.4)

rate with all parameters unchanged. Insert changed data to the ADS-B System to
cause a change to occur in the Intent Change Flag so that it is detected at least 100
milliseconds prior to the next scheduled Airborne Velocity Message transmission.
Verify that the Intent Change Flag subfield value has changed to ONE (1) in the
next transmitted Airborne Velocity Message.
Step 4: Airborne Velocity Message - Subtype=1 NACV Subfield (2.2.3.2.6.1.5 and

2.2.5.2.4)

rate with all parameters unchanged. Verify that the NACV value equals Zero (0).
Insert changed data to the ADS-B System to cause a change to occur in the NACV
value and so that the change is detected at least 100 milliseconds prior to the next
scheduled Airborne Velocity Message transmission. Verify that the NACV
subfield value has changed to the correct value in the next transmitted Airborne
Velocity Message.
Step 5: Airborne Velocity Message - Subtype=1 East/West Direction Bit Subfield

(2.2.3.2.6.1.6 and 2.2.5.2.4)

rate with all parameters unchanged. Verify that the East/West Direction Bit
equals Zero (0). Insert changed data to the ADS-B System to cause a change to
occur in the East/West Direction Bit so that the direction will become West and
so that the change is detected at least 100 milliseconds prior to the next scheduled
Airborne Velocity Message transmission. Verify that the East/West Direction Bit
subfield value has changed to ONE (1) in the next transmitted Airborne Velocity
Message.
Step 6: Airborne Velocity Message - Subtype=1 East/West Velocity Subfield

(2.2.3.2.6.1.7 and 2.2.5.2.4)

20xx, RTCA, Inc.

604
subsonic East/West Velocity data to the ADS-B System. Continue transmitting
Airborne Velocity Messages - Subtype=1 at the nominal rate with all parameters
unchanged.
Insert changed data to the ADS-B System to cause a change to occur in the
East/West Velocity so that it is detected at least 100 milliseconds prior to the next
scheduled Airborne Velocity Message transmission. Verify that the East/West
Velocity subfield value has changed in the next transmitted Airborne Velocity
Message and that the value in the subfield is correct.
Step 7: Airborne Velocity Message - Subtype=1 North/South Direction Bit Subfield

(2.2.3.2.6.1.8 and 2.2.5.2.4)
Repeat the tests in Step 6 above changing the word East to North and the
word West to South.
Step 8: Airborne Velocity Message - Subtype=1 North/South Velocity Subfield

(2.2.3.2.6.1.9 and 2.2.5.2.4)
Repeat the tests in Step 7 above changing the words East/West to

North/South.
Step 9: Airborne Velocity Message - Subtype=1 Vertical Rate Source Bit Subfield
(2.2.3.2.6.1.10 and 2.2.5.2.4)
a. Continue transmitting Airborne Velocity Messages - Subtype=1 at the

nominal rate with all parameters unchanged. Verify that the Source Bit for
Vertical Rate equals Zero (0), indicating receipt of Vertical Rate information
from a Geometric Source. Insert changed data to the ADS-B System to cause a
change to occur in the Source Bit for Vertical Rate so that the Vertical Rate
information will come from a Barometric Source, and so that the change is
detected at least 100 milliseconds prior to the next scheduled Airborne
Velocity Message transmission. Verify that the Source Bit for Vertical Rate
subfield value has changed to ONE (1) in the next transmitted Airborne
Velocity Message.
b. Continue transmitting Airborne Velocity Messages Subtype=1 at the

nominal rate with all parameters unchanged and verify that the Source Bit for
Vertical Rate contains the value ONE (1). Continue transmitting Airborne
unchanged. Insert changed data to the ADS-B System to cause a change to
occur in the Source Bit for Vertical Rate so that the Vertical rate information
will come from a Geometric Source, and so that the change is detected at least
transmission. Verify that the Source Bit for Vertical Rate subfield value has
changed to ZERO (0) in the next transmitted Airborne Velocity Message.
20xx, RTCA, Inc.

605
Step 10: Airborne Velocity Message - Subtype=1 Sign Bit for Vertical Rate Subfield
(2.2.3.2.6.1.11 and 2.2.5.2.4)

nominal rate with all parameters unchanged. Verify that the Sign Bit for
Vertical Rate subfield equals ZERO (0), indicating Vertical Rate information
in the UP Direction. Insert changed data to the ADS-B System to cause a
change to occur in the Sign Bit for Vertical Rate so that the Vertical
Direction information will be DOWN, and so that the change is detected at
least 100 milliseconds prior to the next scheduled Airborne Velocity Message
transmission. Verify that the Sign Bit for Vertical Rate subfield value has
changed to ONE (1) in the next transmitted Airborne Velocity Message.

nominal rate with all parameters unchanged and verify that the Sign Bit for
Vertical Rate subfield contains the value of ONE (1). Continue transmitting
Airborne Velocity Messages - Subtype=1 at the nominal rate with all
parameters unchanged. Insert changed data to the ADS-B System to cause a
change to occur in the Sign Bit for Vertical Rate so that the Vertical
Direction information will be UP, and so that the change is detected at least
transmission. Verify that the Sign Bit for Vertical Rate subfield value has
changed to ZERO (0) in the next transmitted Airborne Velocity Message.
Step 11: Airborne Velocity Message - Subtype=1 Vertical Rate Subfield

(2.2.3.2.6.1.12 and 2.2.5.2.4)

Vertical Rate data to the ADS-B System. Continue transmitting Airborne
unchanged.
Vertical Rate so that it is detected at least 100 milliseconds prior to the next
scheduled Airborne Velocity Message transmission. Verify that the Vertical Rate
subfield value has changed in the next transmitted Airborne Velocity Message
and that the value in the subfield is correct.
Step 12: Airborne Velocity Message - Subtype=1 Difference From Barometric Altitude
Sign Bit Subfield (2.2.3.2.6.1.14 and 2.2.5.2.4)

nominal rate with all parameters unchanged. Verify that the Geometric
Altitude Source data is greater than (above) the Barometric. Verify that the
Difference From Barometric Altitude Sign Bit equals Zero (0). Insert changed
data to the ADS-B System to cause a change to occur in the Difference From
Barometric Altitude Sign Bit so that the Geometric Altitude Source Data is
less than (below) Barometric, and so that the change is detected at least 100
20xx, RTCA, Inc.

606
milliseconds prior to the next scheduled Airborne Velocity Message

transmission. Verify that the Difference From Barometric Altitude Sign Bit
subfield value has changed to ONE (1) in the next transmitted Airborne
Velocity Message.

nominal rate with all parameters unchanged and verify that the Difference
From Barometric Altitude Sign Bit contains the value ONE (1). Continue
transmitting Airborne Velocity Messages - Subtype=1 at the nominal rate with
all parameters unchanged. Insert changed data to the ADS-B System to cause
a change to occur in the Difference From Barometric Altitude Sign Bit so that
the Geometric Altitude Source data is greater than (above) the Barometric, and
so that the change is detected at least 100 milliseconds prior to the next
scheduled Airborne Velocity Message transmission. Verify that the
Difference From Barometric Altitude Sign Bit subfield value has changed to
ZERO (0) in the next transmitted Airborne Velocity Message.
Subfield (2.2.3.2.6.1.15 and 2.2.5.2.4)

the ADS-B Transmitting Subsystem to Airborne status. Provide valid Geometric
Altitude Source data and Barometric Altitude data. Continue transmitting
Airborne Velocity Messages - Subtype=1 at the nominal rate with all parameters
unchanged.
Difference From Barometric Altitude subfield so that it is detected at least 100
milliseconds prior to the next scheduled Airborne Velocity Message transmission.
Verify that the Difference From Barometric Altitude subfield value has changed
in the next transmitted Airborne Velocity Message and that the value in the
subfield is correct.
2.4.5.2.5 Verification of Airborne Velocity Message Subtype=2 Latency (2.2.3.2.6.2,

2.2.5.2.5)
information is available, and the transmitting device is installed in an environment having
Supersonic airspeed capabilities.
20xx, RTCA, Inc.

607
Repeat all tests in 2.4.5.2.4 Steps 1 through 15 changing all occurrences of Subtype=1 to
Subtype=2 and all occurrences of subsonic to supersonic and vice versa.

2.2.5.2.6)
information is NOT available, and the transmitting device is installed in an environment
having NON-supersonic airspeed capabilities. These test procedures verify that any
changes in the data used to structure the subfields of the Airborne Velocity Message -
Subtype=3 are reflected in the affected subfield of the next scheduled Airborne Velocity
Message - Subtype=3 provided that the change occurs and is detected at least 100
milliseconds prior to the next scheduled Airborne Velocity Message - Subtype=1
transmission.
Step 1: Airborne Velocity Message - Subtype=3 TYPE Subfield (2.2.3.2.6.3.1 and

2.2.5.2.6)
Repeat the test outlined in 2.4.5.2.4, Step 1 for the TYPE subfield changing all
occurrences of Subtype=1 to Subtype 3.
Step 2: Airborne Velocity Message - Subtype=3 Subtype Subfield (2.2.3.2.6.3.2 and

2.2.5.2.6)
Repeat the test outlined in 2.4.5.2.4, Step 2 for the Subtype subfield changing all
Step 3: Airborne Velocity Message - Subtype=3 Intent Change Flag Subfield

(2.2.3.2.6.3.3 and 2.2.5.2.6)
Repeat the test outlined in 2.4.5.2.4, Step 3 for the Intent Change Flag subfield
changing all occurrences of Subtype=1 to Subtype 3.
Step 4: Airborne Velocity Message - Subtype=3 NACV Subfield (2.2.3.2.6.3.5 and

2.2.5.2.6)
Repeat the test outlined in 2.4.5.2.4, Step 5 for the NACV subfield changing all
Step 5: Airborne Velocity Message - Subtype=3 Heading Status Subfield

(2.2.3.2.6.3.6 and 2.2.5.2.6)

nominal rate with all parameters unchanged. Verify that the Heading Status
20xx, RTCA, Inc.

608
Bit equals ZERO (0), indicating that Heading Data is available. Insert changed
data to the ADS-B System to indicate that Heading Data is NOT available,
and so that the change is detected at least 100 milliseconds prior to the next
scheduled Airborne Velocity Message transmission. Verify that the Heading
Status Bit subfield value has changed to ONE (1) in the next transmitted

nominal rate with all parameters unchanged and verify that the Heading Status
Bit contains the value ONE (1). Continue transmitting Airborne Velocity
Messages - Subtype=3 at the nominal rate with all parameters unchanged.
Insert changed data to the ADS-B System to indicate that Heading Data IS
available, and so that the change is detected at least 100 milliseconds prior to
the next scheduled Airborne Velocity Message transmission. Verify that the
Heading Status Bit subfield value has changed to ZERO (0) in the next
transmitted Airborne Velocity Message.
Step 6: Airborne Velocity Message - Subtype=3 Heading Subfield (2.2.3.2.6.3.7 and

2.2.5.2.6)

the ADS-B Transmitting Subsystem to Airborne status. Provide valid Heading
data. Continue transmitting Airborne Velocity Messages - Subtype=3 at the
nominal rate with all parameters unchanged.
Heading so that it is detected at least 100 milliseconds prior to the next
scheduled Airborne Velocity Message transmission. Verify that the Heading
subfield value has changed in the next transmitted Airborne Velocity Message and
that the value in the subfield is correct.
Step 7: Airborne Velocity - Subtype=3 Airspeed Type Subfield (2.2.3.2.6.3.8 and

2.2.5.2.6)

nominal rate with all parameters unchanged. Verify that the Airspeed Type
subfield equals ZERO (0), indicating that the Airspeed Type is Indicated
Airspeed (IAS). Insert changed data to the ADS-B System to indicate that
Airspeed Type has changed to True Airspeed (TAS), and so that the change is
Velocity Message transmission. Verify that the Airspeed Type subfield
value has changed to ONE (1) in the next transmitted Airborne Velocity
Message.

nominal rate with all parameters unchanged and verify that the Airspeed
Type subfield contains the value ONE (1). Continue transmitting Airborne
unchanged. Insert changed data to the ADS-B System to indicate that the
20xx, RTCA, Inc.

609
Airspeed Type has changed to Indicated Airspeed, and so that the change is
Velocity Message transmission. Verify that the Airspeed Type subfield
value has changed to ZERO (0) in the next transmitted Airborne Velocity
Message.
Step 8: Airborne Velocity Message - Subtype=3 Airspeed Subfield (2.2.3.2.6.3.9

and 2.2.5.2.6)

the ADS-B Transmitting Subsystem to Airborne status. Provide valid Airspeed
data. Continue transmitting Airborne Velocity Messages - Subtype=3 at the
nominal rate with all parameters unchanged.
Airspeed subfield so that it is detected at least 100 milliseconds prior to the next
scheduled Airborne Velocity Message transmission. Verify that the Airspeed
subfield value has changed in the next transmitted Airborne Velocity Message
and that the value in the subfield is correct.
Step 9: Airborne Velocity Message - Subtype=3 Vertical Rate Source Subfield

(2.2.3.2.6.3.10 and 2.2.5.2.6)
Repeat the test outlined in 2.4.5.2.4, Step 10 for the Source Bit For Vertical Rate
subfield changing all occurrences of Subtype=1 to Subtype 3.
Step 10: Airborne Velocity Message - Subtype=3 Sign Bit for Vertical Rate Subfield
(2.2.3.2.6.3.11 and 2.2.5.2.6)
Repeat the test outlined in 2.4.5.2.4, Step 11 for the Sign Bit for Vertical Rate
subfield changing all occurrences of Subtype=1 to Subtype 3.
Step 11: Airborne Velocity Message - Subtype=3 Vertical Rate Subfield

(2.2.3.2.6.3.12 and 2.2.5.2.6)
Repeat the test outlined in 2.4.5.2.4, Step 12 for the Vertical Rate subfield
changing all occurrences of Subtype=1 to Subtype 3.
Sign Bit Subfield (2.2.3.2.6.1.14 and 2.2.5.2.6)
Repeat the test outlined in 2.4.5.2.4, Step 14 for the Difference From Barometric
Altitude Sign Bit subfield changing all occurrences of Subtype=1 to Subtype 3.
Subfield (2.2.3.2.6.3.15 and 2.2.5.2.6)
Repeat the test outlined in 2.4.5.2.4, Step 15 for the Difference From Barometric
Altitude subfield changing all occurrences of Subtype=1 to Subtype 3.
20xx, RTCA, Inc.

610

2.2.5.2.7)
information is NOT available, and the transmitting device is installed in an environment
having supersonic airspeed capabilities.
Repeat all tests in 2.4.5.2.6 Steps 1 through 15 changing all occurrences of Subtype=3 to
Subtype=4 and all occurrences of subsonic to supersonic and vice versa.
2.4.5.2.8 Verification of Airborne Velocity Message Subtype 5 Latency (2.2.5.2.8)



2.4.5.2.11 Verification of Target State and Status Message Latency (2.2.3.2.7.1, 2.2.5.2.11)
The following test procedures verify that any changes in the data used to structure the
subfields of the Target State and Status Message are reflected in the affected subfield of the
next scheduled Target State and Status Message provided that the change occurs and is
detected at least 100 milliseconds prior to the next scheduled Target State and Status
20xx, RTCA, Inc.

611
Step 1: Target State and Status TYPE Subfield (2.2.3.2.7.1.1 and 2.2.5.2.11)
Configure the ADS-B Transmitting Subsystem to transmit Target State and Status
Messages by providing valid trajectory information at the nominal update rate.
Provide the data externally at the interface to the ADS-B system. Set the ADS-B
Transmitting Subsystem to Airborne status. Verify that the TYPE subfield in the
Target State and Status Message equals 29, which is the only TYPE value
assigned to Target State and Status Messages.
Step 2: Target State and Status Subtype Subfield (2.2.3.2.7.1.2)
Continue transmitting Target State and Status Messages at the nominal rate with
all parameters unchanged. Verify that the Subtype subfield in the Target State and
Status Messages equals ZERO (0), which is the only Subtype value currently
assigned to Target State and Status Messages.
Step 3: Target State and Status Selected Altitude Type Subfield (2.2.3.2.7.1.3.2)
Continue transmitting Target State and Status Messages at the nominal rate
ZZZZZZZZZZZ NEED TEST PROCEDURE HERE ZZZZZZZZZZZZZZ
Step 4: Target State and Status MCP/FCU Selected Altitude or FMS Selected Altitude
Subfield (2.2.3.2.7.1.3.3)
Step 5: Target State and Status Barometric Pressure Setting (Minus 800 millibars)
Subfield (2.2.3.2.7.1.3.4)
Step 6: Target State and Status Selected Heading Status Subfield (2.2.3.2.7.1.3.5)
Step 7: Target State and Status Selected Heading Sign Subfield (2.2.3.2.7.1.3.6)
Step 8: Target State and Status Selected Heading Subfield (2.2.3.2.7.1.3.7)
20xx, RTCA, Inc.

612
Step 9: Target State and Status NACP Subfield (2.2.3.2.7.1.3.8)
Continue transmitting Target State and Status Messages at the nominal rate with a
NACP value of Zero indicated. Verify that the NACP Subfield is set to ALL
ZEROs (binary 0000). For each NACP in the binary column of Table 2-71 insert
changed data to the ADS-B System to cause a change to occur in the NACP
subfield, and so that the change is detected at least 100 milliseconds prior to the
next scheduled Target State and Status Message transmission. Verify that the
binary value in the NACP Subfield equals the corresponding binary value in the
same row of the table.
Step 10: Target State and Status NICBARO Subfield (2.2.3.2.7.1.3.9)
Continue transmitting Target State and Status Messages at the nominal rate with a
non-cross checked Gilham altitude indicated. Verify that the NICBARO Subfield
equals ZERO (0). Insert changed data to the ADS-B System to cause a change to
occur in the NICBARO subfield with a cross checked Gilham altitude indicated and
such that the change is detected at least 100 milliseconds prior to the next
scheduled Target State and Status Message transmission. Verify that the NICBARO
Subfield equals ONE (1).
Step 11: Target State and Status SIL and SIL Supplement Subfields (2.2.3.2.7.1.3.1,
2.2.3.2.7.1.3.10)
Unknown SIL Data. Verify that the SIL subfield equals ZERO (binary 00). Insert
changed data to the ADS-B System to cause a change to occur in the SIL subfield
to indicate 1 x 10-3 per flight hour, and so that the change is detected at least 100
milliseconds prior to the next scheduled Target State and Status Message
transmission. Verify that the SIL subfield equals ONE (binary 01) and that the
SIL Supplement subfield equals ZERO (0). Insert changed data to the ADS-B
System to cause a change to occur in the SIL subfield to indicate 1 x 10 -5 per
sample, and so that the change is detected at least 100 milliseconds prior to the
next scheduled Target State and Status Message transmission. Verify that the SIL
subfield equals TWO (binary 10) and that the SIL Supplement subfield equals
ONE (1). Insert changed data to the ADS-B System to cause a change to occur in
the SIL subfield 1 x 10-7 per flight hour, and so that the change is detected at least
100 milliseconds prior to the next scheduled Target State and Status Message
transmission. Verify that the SIL subfield equals THREE (binary 11) and that the
SIL Supplement equals ZERO (0).
Step 12: Target State and Status Status of MCP/FCU Mode Bits (2.2.3.2.7.1.3.11)
Step 13: Target State and Status Autopilot Engaged Subfield (2.2.3.2.7.1.3.12)
20xx, RTCA, Inc.

613
Step 14: Target State and Status VNAV Mode Engaged Subfield (2.2.3.2.7.1.3.13)
Step 15: Target State and Status Altitude Hold Mode Subfield (2.2.3.2.7.1.3.14)
Step 16: Target State and Status Approach Mode Subfield (2.2.3.2.7.1.3.16)
Step 17: Target State and Status TCAS Operational Subfield (2.2.3.2.7.1.3.17)
2.4.5.2.12 Verification of Aircraft Operational Status Message Latency (2.2.3.2.7.2, 2.2.5.2.12)

These test procedures verify that any changes in the data used to structure the subfields of
the Aircraft Operational Status Message are reflected in the affected subfield of the next
scheduled Aircraft Operational Status Message provided that the change occurs and is
detected at least 100 milliseconds prior to the next scheduled Aircraft Operational Status
Step 1: Aircraft Operational Status Message - TYPE Subfield (2.2.3.2.7.2.1 and

2.2.5.2.12)

Status Messages by providing data at the nominal update rate. Provide the data
externally at the interface to the ADS-B system. Set the ADS-B Transmitting
Subsystem to Airborne Status. Continue transmitting Aircraft Operational Status
TYPE subfield in the Aircraft Operational Status Message equals 31, which is the
only TYPE value assigned to Aircraft Operational Status Messages.
Step 2: Aircraft Operational Status Message - Subtype Subfield (2.2.3.2.7.2.2 and

2.2.5.2.12)
Continue transmitting Aircraft Operational Status Messages at the nominal rate

with all parameters unchanged. Verify that the Subtype subfield in the Aircraft
Operational Status Messages equals ZERO (0).
20xx, RTCA, Inc.

614
Step 3: Aircraft Operational Status Message - Capability Class (CC) Subfield

(2.2.3.2.7.2.3 and 2.2.5.2.12)
a. Capability Class Code for TCAS Operational (2.2.3.2.7.2.3.2)
Continue transmitting Aircraft Operational Status Messages at the nominal

rate with TCAS Operational indicated. Verify that ME bit 11 is set to ONE
(1). Insert changed data to the ADS-B System to cause a change to occur in
the Capability Class subfield with TCAS not operational indicated, and so
that the change is detected at least 100 milliseconds prior to the next
scheduled Aircraft Operational Status Message transmission. Verify that ME
bit 11 is set to ZERO (0).
b. Capability Class Code for 1090ES IN (2.2.3.2.7.2.3.3)
Set the ADS-B Transmitting Subsystem to Airborne Status. Continue

transmitting Aircraft Operational Status Messages at the nominal rate with
1090ES Receive capability indicated. Verify that ME bit 12 is set to ONE
the Capability Class subfield which indicates that there is no 1090ES
Receiver available, and so that the change is detected at least 100
milliseconds prior to the next scheduled Aircraft Operational Status Message
transmission. Verify that ME bit 12 is set to ZERO (0).
Set the ADS-B Transmitting Subsystem to On-Ground Status. Rerun this

procedure and verify that the Subtype is set to ONE (1) and that ME bit 12 is
set to the appropriate state.
c. Capability Class Code for ARV Report Capability (2.2.3.2.7.2.3.4)

transmitting Aircraft Operational Status Messages at the nominal rate with no
capability for (ARV) Reports indicated. Verify that ME bit 15 is set to ZERO
the Capability Class subfield with Capability for sending messages to support
(ARV) Reports indicated, and so that the change is detected at least 100
transmission. Verify that ME bit 15 is set to ONE (1).
d. Capability Class Code for TS Report Capability (2.2.3.2.7.2.3.5)

rate with no capability for (TS) reports indicated. Verify that ME bit 16 is set
to ZERO (0). Insert changed data to the ADS-B System to cause a change to
occur in the Capability Class subfield with Capability for sending messages to
support (TS) reports indicated, and so that the change is detected at least 100
transmission. Verify that ME bit 16 is set to ONE (1).
20xx, RTCA, Inc.

615
e. Capability Class Code for TC Report Capability (2.2.3.2.7.2.3.6)

rate with no capability for (TC) reports indicated. Verify that the TC Report
Capability subfield equals ZERO (binary 00). Insert changed data to the
ADS-B System to cause a change to occur in the TC Report Capability
subfield to indicate the capability of sending messages to support TC+0
Reports only, and so that the change is detected at least 100 milliseconds prior
to the next scheduled Aircraft Operational Status Message transmission.
Verify that the TC Report Capability subfield equals ONE (binary 01). Insert
changed data to the ADS-B System to cause a change to occur in the TC
Report Capability subfield to indicate the capability of sending information
for multiple TC Reports, and so that the change is detected at least 100
transmission. Verify that the TC Report Capability subfield equals TWO
(binary 10).
f. Capability Class Code for Position Offset Applied (POA) (2.2.3.2.7.2.3.7)
Set the ADS-B Transmitting Subsystem to On-Ground Status. Continue

Position Offset Applied indicated. Verify that ME bit 11 is set to ZERO (0).
(POA) subfield with Position Offset Applied indicated, and such that the
change is detected at least 100 milliseconds prior to the next scheduled
Aircraft Operational Status Message transmission. Verify that ME bit 11 is
set to ONE (1).
g. Capability Class Code for UAT IN (2.2.3.2.7.2.3.10)

UAT Receive capability indicated. Verify that ME bit 19 is set to ONE (1).
Capability Class subfield which indicates that there is no UAT Receiver
available, and so that the change is detected at least 100 milliseconds prior to
the next scheduled Aircraft Operational Status Message transmission. Verify
that ME bit 19 is set to ZERO (0).
Set the ADS-B Transmitting Subsystem to On-Ground Status. Rerun this

procedure and verify that the Subtype is set to ONE (1) and that ME bit 16 is
set to the appropriate state.
Step 4: Aircraft Operational Status Message Subtype 0/1 - Operational Mode (OM)
Subfield (2.2.3.2.7.2.4 and 2.2.5.2.12)
a. Operational Mode Code for TCAS/ACAS Resolution Advisory Active

(2.2.3.2.7.2.4.2)
Configure the ADS-B Transmitting Subsystem to transmit Aircraft

Operational Status Messages by providing data at the nominal update rate.
20xx, RTCA, Inc.

616
Provide the data externally at the interface to the ADS-B system. Set the
ADS-B Transmitting Subsystem to Airborne Status. Continue transmitting
Aircraft Operational Status Messages at the nominal rate with no
TCAS/ACAS Resolution Advisory Active indicated. Verify that ME bits
25,26 and 27 are all set to ZERO (0). Insert changed data to the ADS-B
System to cause a change to occur in the Operational Mode subfield with a
TCAS/ACAS Resolution Advisory Active indicated. Verify that ME bits 25
and 26 are both set to ZERO (0) and that ME bit 27 is set to ONE (1).
Set the ADS-B Transmitting Subsystem to On-Ground Status. Repeat this

procedure and verify the same binary values and verify that the Subtype is set
to ONE (1).
b. Operational Mode Code for IDENT Switch Active (2.2.3.2.7.2.4.3)

IDENT switch not active indicated. Verify that ME bit 28 is set to ZERO (0).
Operational Mode subfield with IDENT switch active indicated. Verify that
ME bit 28 is set to ONE (1).

procedure and verify the same binary values and verify that the Subtype is set
to ONE (1).
c. Operational Mode Code for Reserved for Receiving ATC Services

(2.2.3.2.7.2.4.4)

transmitting Aircraft Operational Status Messages at the nominal rate. Verify
that ME bit 29 is set to ZERO (0).
d. Operational Mode Code for Single Antenna Flag (2.2.3.2.7.2.4.5)

transmitting Aircraft Operational Status Messages at the nominal rate.
Provide stimulus to indicate that the aircraft has a single antenna. Verify that
ME bit 30 is set to ONE (1). Insert changed data to the ADS-B System to
indicate that the aircraft has multiple antenna, and so that the change is
detected at least 100 milliseconds prior to the next scheduled Aircraft
Operational Status Message transmission. Verify that ME bit 30 is set to
ZERO (0). Reset the ADS-B Transmitting Subsystem to On-Ground Status
and rerun the above tests and verify that ME bit is set appropriately.
e. Operational Mode Code for System Design Assurance (2.2.3.2.7.2.4.6)

rate with Unknown SIL Data, and unknown SDA data. Verify that the SIL
subfield (ME bits 51-52) equals ZERO (binary 00) and that the SDA subfield
(ME bits 31-32) equals ZERO (binary 00). Insert changed data to the ADS-B
20xx, RTCA, Inc.

617
System to cause a change to occur in the SIL subfield to indicate 1 x 10 -3 per

flight hour, and so that the change is detected at least 100 milliseconds prior to
the next scheduled Aircraft Operational Status Message transmission. Verify
that the SIL subfield equals ONE (binary 01), and that the SIL Supplement
subfield (ME bit 55) equals ZERO (0), and that the SDA subfield equals ONE
the SIL subfield to indicate 1 x 10-5 per sample, and so that the change is
Operational Status Message transmission. Verify that the SIL and SDA
subfields equal TWO (binary 10) and that the SIL Supplement subfield equals
ONE (1). Insert changed data to the ADS-B System to cause a change to
occur in the SIL subfield 1 x 10-7 per flight hour, and so that the change is
Operational Status Message transmission. Verify that the SIL and SDA
subfields equal THREE (binary 11) and that the SIL Supplement equals
ZERO (0).
f. Operational Mode Code for GPS Antenna Offset (2.2.3.2.7.2.4.7)

Position Offset Applied indicated. Verify that ME bit 11 is set to ZERO (0).
ZZZZZZZZZ NEED MORE TEST PROCEDURE HERE ZZZZZZZZZZZ
Step 5: Aircraft Operational Status Message Aircraft Length and Width Code Subfield
(2.2.3.2.7.2.11)

transmitting Aircraft Operational Status Messages at the nominal rate with the
Minimum Length and Width values from Table 2-74 indicated. Verify that the
ME bits 21 through 24 are set to ALL ZEROs (binary 0000). For each Length and
Width combination in Table 2-74 insert changed data to the ADS-B System to
cause a change to occur in the Length and Width subfield, and so that the change
is detected at least 100 milliseconds prior to the next scheduled Aircraft
Operational Status Message transmission. Verify that the binary values in ME bits
21 through 24 equals the corresponding binary values in the same row of the table.
Step 6: Aircraft Operational Status Message Subtype 0/1 Version Number

Subfield

Status Messages by providing data at the nominal update rate. Provide the data
externally at the interface to the ADS-B system. Set the ADS-B Transmitting
Subsystem to Airborne Status. Continue transmitting Aircraft Operational Status
Messages at the nominal rate with all parameters unchanged. Verify that ME bits
41 through 43 are set to ONE (binary 001).
20xx, RTCA, Inc.

618

procedure and verify the same binary values and verify that the Subtype is set to
ONE (1).
Step 7: Aircraft Operational Status Message Subtype 0/1 NIC Supplement

Subfield (2.2.3.2.7.2.6)
Set the ADS-B Transmitting Subsystem to Airborne Status. Continue transmitting

Aircraft Operational Status Messages at the nominal rate with a TYPE Code equal
to ZERO indicated. Verify that the NIC Supplement Subfield is set to ZERO (0).
For each Airborne Position TYPE Code listed in Table 2-70 insert changed data to
the ADS-B System to cause a change to occur in the Airborne Position TYPE
Code subfield, and so that the change is detected at least 100 milliseconds prior to
the next scheduled Aircraft Operational Status Message transmission. Verify that
the binary value in the NIC Supplement Subfield equals the corresponding binary
value in the Airborne NIC Supplement column in the same row of Table 2-70.

procedure and for each Surface Position TYPE Code listed in Table 2-70 insert
changed data to the ADS-B System to cause a change to occur in the Surface
Position TYPE Code subfield, and so that the change is detected at least 100
transmission. Verify that the binary value in the NIC Supplement Subfield equals
the corresponding binary value in the Surface NIC Supplement column in the
same row of Table 2-70.
Step 8: Aircraft Operational Status Message Subtype 0/1 NACP Subfield

(2.2.3.2.7.2.7)

Aircraft Operational Status Messages at the nominal rate with an EPU greater than
or equal to 10 NM indicated. Verify that the NACP Subfield is set to ZERO
(binary 0000). For each EPU range listed in Table 2-71 insert changed data to the
ADS-B System to cause a change to occur in the NACP subfield, and so that the
change is detected at least 100 milliseconds prior to the next scheduled Aircraft
Operational Status Message transmission. Verify that the binary value in the
NACP Subfield equals the corresponding binary value in the NACP Binary column
in the same row of the table.

ONE (1).
Step 9: Aircraft Operational Status Message Subtype 0/1 SIL Subfield

(2.2.3.2.7.2.9)

Aircraft Operational Status Messages at the nominal rate with Unknown SIL Data.
Verify that the SIL subfield equals ZERO (binary 00). Insert changed data to the
ADS-B System to cause a change to occur in the SIL subfield to indicate 1 x 10 -3
per flight hour or per operation, and so that the change is detected at least 100
20xx, RTCA, Inc.

619

transmission. Verify that the SIL subfield equals ONE (binary 01). Insert
changed data to the ADS-B System to cause a change to occur in the SIL subfield
to indicate 1 x 10-5 per flight hour or per operation, and so that the change is
detected at least 100 milliseconds prior to the next scheduled Aircraft Operational
Status Message transmission. Verify that the SIL subfield equals TWO (binary
10). Insert changed data to the ADS-B System to cause a change to occur in the
SIL subfield 1 x 10-7 per flight hour or per operation, and so that the change is
Status Message transmission. Verify that the SIL subfield equals THREE (binary
11).

ONE (1).
Step 10: Aircraft Operational Status Message Subtype 0 NICBARO Subfield

(2.2.3.2.7.2.10)

Aircraft Operational Status Messages at the nominal rate with a non-cross checked
Gilham altitude indicated. Verify that the NICBARO Subfield equals ZERO (0).
NICBARO subfield with a cross checked Gilham altitude indicated and such that the
change is detected at least 100 milliseconds prior to the next scheduled Aircraft
Operational Status Message transmission. Verify that the NICBARO Subfield
equals ONE (1).
Step 11: Aircraft Operational Status Message Subtype=1 Track Angle/Heading

Subfield (2.2.3.2.7.2.12)

transmitting Aircraft Operational Status Subtype=1 Messages at the nominal rate
with Track Angle indicated. Verify that ME bit 53 is set to ZERO (0). Insert
changed data to the ADS-B System to cause a change to occur in the Track
Angle/Heading subfield with Heading indicated and such that the change is
Status Message transmission. Verify that ME bit 53 is set to ONE (1).
Step 12: Aircraft Operational Status Message Subtype 0/1 HRD Subfield
(2.2.3.2.7.2.13)

Aircraft Operational Status Subtype 0 Messages at the nominal rate with True
North indicated. Verify that ME bit 54 is set to ZERO (0). Insert changed data to
the ADS-B System to cause a change to occur in the HRD subfield with Magnetic
North indicated, such that the change is detected at least 100 milliseconds prior to
the next scheduled Aircraft Operational Status Message transmission. Verify that
ME bit 54 is set to ONE (1).
20xx, RTCA, Inc.

620

ONE (1).
2.4.5.2.13 Verification of TYPE 23 Test Message Latency (2.2.5.2.13)

The ADS-B Transmission Device Message Processor processes Vendor Specified data for
ADS-B Test Messages specified in 2.2.3.2.7.3 with any change in data being reflected in
the next scheduled Test Message provided that the change occurs and is detected at least
100 milliseconds prior to the next scheduled Test Message transmission.
Step 1: Test Message TYPE Subfield (2.2.3.2.7.3)
Configure the ADS-B Transmitting Subsystem to transmit Test Messages by

providing valid information at the nominal update rate. Provide the data
externally at the interface to the ADS-B System. Set the ADS-B Transmitting
Subsystem to Airborne status. Verify that the TYPE subfield in the Test Message
equals 23, which is the only TYPE value assigned to Test Messages.
Step 2: Test Message (2.2.3.2.7.3)
Continue transmitting Test Messages at the nominal rate with all parameters
unchanged. Insert changed data to the ADS-B System to cause a change to occur
in the Test Message so that it is detected at least 100 milliseconds prior to the next
scheduled Test Message transmission. Verify that the Test subfield value has
changed as expected in the next transmitted Test Message.
2.4.5.2.14 Verification of TYPE 24 Message Latency (2.2.5.2.14)


20xx, RTCA, Inc.

621


RESERVED for future use of Trajectory Change
2.4.5.2.18 Verification of Aircraft Status Messages Subtype=1 (2.2.5.2.18)

Any change in the data used to structure the subfields of the Aircraft Status Message
Subtype=1 (Emergency/Priority Status) are reflected in the affected subfield of the next
scheduled Aircraft Status Message Subtype=1 provided that the change occurs and is
detected at least 100 milliseconds prior to the next scheduled Aircraft Status Message
Subtype=1 transmission as specified in 2.2.5.2.18.
Step 1: Aircraft Status Message Subtype=1 TYPE Subfield

nominal rate with all parameters unchanged, ensuring that there is No
Emergency indicated. Verify that the Aircraft Status Message is not being
broadcast. Insert changed data into the ADS-B System indicating an emergency
condition specified in Table 2-57. Verify that the TYPE subfield, in the
transmitted Aircraft Status Message with Subtype=1, equals 28.
Step 2: Aircraft Status Message Subtype=1 SUBTYPE Subfield

rate with all parameters unchanged. Verify that the SUBTYPE subfield in the
Aircraft Status Message equals ONE (1).
Step 3: Aircraft Status Message Subtype=1 Emergency/Priority Status

Subtype=1 with the Emergency/Priority Status subfield set equal to the
corresponding binary coding value that was provided as input.
20xx, RTCA, Inc.

622
Change the Emergency/Priority Status subfield input to the ADS-B System so

as to change the emergency being reported, and verify that the change occurs, and
that it is detected at least 100 milliseconds prior to the next scheduled Aircraft
Status Message with Subtype=1 transmission. Verify that the
Emergency/Priority Status subfield value has changed in the next transmitted
Aircraft Status Message and that it is the correctly reported value.
2.4.5.2.19 Verification of TCAS RA Broadcast Messages Subtype=2 (2.2.5.2.19)

Any change in the data used to structure the subfields of the Aircraft Status Message
Subtype=2 (TCAS RA Broadcast) are reflected in the affected subfields of the next
scheduled Aircraft Status Message Subtype=2 provided that the change occurs and is
detected at least 100 milliseconds prior to the next scheduled Aircraft Status Message
Subtype=2 transmission as specified in 2.2.5.2.19.
Step 1: Aircraft Status Message Subtype=2 TYPE Subfield

nominal rate with all parameters unchanged, ensuring that there is no TCAS RA
indicated. Verify that the Aircraft Status Message is not being broadcast. Insert
changed data into the ADS-B System to reflect a TCAS RA condition. Verify that
the ADS-B System begins to transmit an Aircraft Status Message with Subtype=2
within 0.5 seconds after the transponder notification of the initiation of the TCAS
RA. Verify that the TYPE subfield, in the transmitted Aircraft Status Message
with Subtype=2, equals 28.
Step 2: Aircraft Status Message Subtype=2 SUBTYPE Subfield

rate with all parameters unchanged. Verify that the SUBTYPE subfield in the
Aircraft Status Message equals TWO (2).
Step 3: Aircraft Status Message Subtype=2 TCAS RA Data

Subtype=2 with the appropriate subfields set equal to the corresponding binary
coding values that are specified from the transponder according to ICAO Annex
10, Volume IV, 4.3.8.4.2.2.
Set the RA Termination flag in the transponder to ONE (1), and verify that the
ADS-B System continues to transmit Aircraft Status Messages with Subtype=2 for
not less than 10 seconds. Verify that 10 seconds after the RA Termination flag
20xx, RTCA, Inc.

623
transitions from ZERO (0) to ONE (1) that the ADS-B System terminates
broadcast of the Aircraft Status Messages with Subtype 2.
2.4.5.3 Verification of ADS-B Transmission Device Source Slecteion (2.2.5.3)

XXXXXXXXXXXXXXXXXX
2.4.6 Verification of ADS-B Receiving Device Message Processor Characteristics (2.2.6)

2.4.6.1 Verification of ADS-B Message Reception Function Requirements (2.2.6.1)

The procedures provided in 2.4.6.1.2 shall be used to validate performance of 2.4.6.1.
2.4.6.1.1 Verification of ADS-B Message Reception Function Output Message Structure

Requirements (2.2.6.1.1)
The procedures provided in 2.4.6.1.2 shall be used to validate performance of 2.4.6.1.1.
2.4.6.1.2 Verification of ADS-B and TIS-B Message Reception Function Output Message
Delivery Requirements (2.2.6.1.2)
Figure 2-18 illustrates the transmitted message receipt capabilities and the OUTPUT
MESSAGE delivery requirements. The ADS-B and TIS-B Message Reception Function
delivers All OUTPUT MESSAGES to the user interface or the Report Assembly function
within 2.0 milliseconds of the receipt of the last message bit of the transmitted message.
These test procedures verify that the ADS-B and TIS-B Receiver Function properly receives
and decodes all valid ADS-B and TIS-B transmitted messages and delivers the messages to
the user interface or to the Report Assembly function.
Step 1: ADS-B and TIS-B Message ONLY Reception (2.2.6.1, 2.2.6.1.1, 2.2.17.2)
Provide the ADS-B Receiver under test with MODE-S messages having random
data but appropriate AA or PI fields for the downlink formats DF=0, DF=4,
DF=5, DF=11, DF=16, DF=17, DF=18, DF=20, DF=21 and DF=24.
20xx, RTCA, Inc.

624
Verify that the ADS-B Receiver DOES NOT generate Output Messages for all of
the downlink formats received with the exception of DF=17 and DF=18.
Verify that the ADS-B Receiver delivers appropriate Output Messages to the user
interface or to the Report Assembly function for each DF=17 and DF=18 message
received and that the Output Message formats are consistent with the requirements
of 2.2.6.1.1 (for ADS-B) and 2.2.17.2 (for TIS-B).
Step 2: ADS-B and TIS-B Message Reception (2.2.6.1, 2.2.6.1.1, 2.2.17.2)
Provide the ADS-B and TIS-B Receiver under test with the ADS-B and TIS-B
Messages listed in Table 2-169 in the following manner:
a. The messages shall be provided sequentially as listed in Table 2-169 in a

burst of 17 messages, beginning with eleven ADS-B Messages and then three
TIS-B Messages, followed by three more ADS-B Messages, where:
b. The first preamble pulse of each message is separated from the end of the
previous message by 8.0 microseconds, and
c. The burst shall be repeated at least four times with the beginning of each burst
being separated from the end of the last burst by not more than 2.0
milliseconds.
Table 2-169: ADS-B Message Reception

ADS-B MESSAGE RECEPTION
BIT # 1 ---- 5 6-8 9 --------- 32 33 ------------------------------- 88 89 ------------------ 112
CA AA ME PI
CASE DF (CF) [24] [56] [24]
No. [5] [3] (HEX) (HEX) (HEX)
1 1 0001 000 AA AA AA AA AA AA AA AA AA AA
2 1 0001 001 55 55 55 55 55 55 55 55 55 55
3 1 0001 010 77 77 77 77 77 77 77 77 77 77
4 1 0001 011 BB BB BB BB BB BB BB BB BB BB
5 1 0001 100 DD DD DD DD DD DD DD DD DD DD
6 1 0001 101 EE EE EE EE EE EE EE EE EE EE
8 1 0001 111 55 55 55 55 55 55 55 55 55 55
9 1 0010 000 AA AA AA AA AA AA AA AA AA AA See Note
10 1 0010 000 55 55 55 55 55 55 55 55 55 55
11 1 0010 001 77 77 77 77 77 77 77 77 77 77
12 1 0010 010 BB BB BB BB BB BB BB BB BB BB
13 1 0010 011 DD DD DD DD DD DD DD DD DD DD
14 1 0010 100 EE EE EE EE EE EE EE EE EE EE
16 1 0010 110 55 55 55 55 55 55 55 55 55 55
Note: The PI subfield of the Message must be properly generated in accordance with
2.2.3.2.1.7.
20xx, RTCA, Inc.

625
Verify that each message provided to the ADS-B and TIS-B Receiver results in an
Output Message that is delivered to the user interface or Report Assembly
function in not more than 2.0 milliseconds after receipt of the last message bit of
each message. Verify that the Output Message format for each message is
consistent with the requirements of 2.2.6.1.1 (for ADS-B) and 2.2.17.2 (for
TIS-B), and represent the data provided in the message as specified in Table 2-
169.
2.4.7 Verification of the ADS-B Message Processor Characteristics (2.2.7)

2.4.7.1 Verification of the ADS-B Receiving Device Message Reception (2.2.7.1)

Appropriate test procedures to validate the requirements of this section are provided in
2.4.8.1, 2.4.8.2, 2.4.8.3, all subsections inclusive.
2.4.7.1.1 Verification of the Receipt of TYPE Code Equal to ZERO (2.2.7.1.1)

An ADS-B Message containing TYPE Code ZERO can only be used to update the altitude
data of an aircraft that is already being tracked by the entity receiving the altitude data in
TYPE Code ZERO ADS-B Message.
If an ADS-B Message with TYPE Code equal to ZERO is received, it should be checked to
see if altitude data is present and then process the altitude data as follows:
a. If altitude data is not present, the message is discarded.
b. If altitude data is present, it may be used to update altitude as needed.
2.4.10.4.1.3.
2.4.8 Verification of the ADS-B Report Characteristics (2.2.8)

All tests in 2.4.8 and its subsections using 1090ES ADS-B Messages as input must include
ADS-B Messages with TYPE Codes 24 27 and 30 in order to verify that these ADS-B
Message types do not adversely impact report assembly.
a. At least 35% of the TYPE Code 24 27 and 30 ADS-B Messages shall have
addresses (AA) that are the same as at least one of the simulated target addresses in any
one test.
20xx, RTCA, Inc.

626
b. At least 35% of the TYPE Code 24 27 and 30 ADS-B Messages shall have
addresses (AA) that are NOT the same as the addresses of the simulated targets used in
a test.
c. At least one of the TYPE Code 24 27 and 30 ADS-B Messages shall be scheduled
to arrive during each Report Assembly State (ref 2.2.10.1.1) achieved during the test.
Appropriate test procedures required to validate the requirements of 2.2.8 are included in
2.4.8.1 Verification of the ADS-B State Vector Report Characteristics (2.2.8.1)

Appropriate test procedures required to validate the requirements of 2.2.8.1 are included in
2.4.8.1.1 Verification of the State Vector Report Type and Structure Identification and Validity
Flags (2.2.8.1.1)
2.4.8.1.1.1 Verification of the State Vector Report Type and Structure Identification (2.2.8.1.1.1)
The Report Type is used to identify the type of ADS-B Report being generated by the report
generation function and being provided to the User Application. The Report Type formats
and maximum number of bytes to be contained in each report are identified in Table 2-82.
The Report Structure field is used to indicate the exact data parameters identified in Table 2-
81 that are being provided in the State Vector Report and is intended to provide a
methodology for the report processor to structure shorter reports when data for some
parameters, or groups of parameters, are not available. The basic conventions for providing
shorter reports are provided in 2.2.8.1.1.1.
For each case in Table 2-170 below, execute Step 1 followed by Step 2 with the input
simulating ADS-B Messages conforming to RTCA DO-260, as specified in Appendix N,
and referenced as Version Zero (0) Messages. Repeat each case with the input simulating
ADS-B Messages conforming to these MOPS (RTCA DO-260A) and referenced as
Version One (1) Messages. Repeat each case again with the input simulating ADS-B
Messages conforming to these MOPS (RTCA DO-260B) and referenced as Version Two
(2) Messages. With Version Zero, Version One and Version Two Message receptions,
only ADS-B Reports conformant to these MOPS should be generated with the Version
Number correctly reported for the individual Participant.
20xx, RTCA, Inc.

627
Step 1: Verification of Report Structure Bit Function (2.2.8.1.1.1.a-c)
Generate a Test Message Type (column 1), which includes the encoded data
representing any valid case of the corresponding Parameter Datum (column 2),
command the ADS-B Receiver/Report Assembly to output State Vector Reports
of Type 0001, and set to ONE the corresponding Structure Coding Bit (column
3).
Verify that the Structure Coding Bit, and the Validity Flag Bit (if specified in
column 4), for the corresponding Parameter Datum, are ONEs.
Verify that the Binary Decoded Parameter Datum appears in its proper position in
the Report (column 5), and in the proper binary format as specified in Table 2-81
(2.2.8.1).
Step 2: Verification of Report Structure Bit Function (2.2.8.1.1.1.a-c)
Repeat Step 1 while implementing the following changes:
Set the Structure Coding Bit, and the Validity Flag, to ZERO.
Verify that the Structure Coding Bit, and the Validity Flag Bit, are both ZEROs.
Verify that the Binary Decoded Parameter Datum no longer appears in the Report.
20xx, RTCA, Inc.

628
Table 2-170: Report Structure Identification Bit Test Data

Report Structure Identification Bit Coding
Column 1 Column 2 Column 3 Column 4 Column 5
State Vector Report Test Fields
Structure Validity Parameter
Test Message Type Parameter Data Type
Coding Flag Reported In
Byte Bit Byte Bit Bytes #Bits
Airborne Position Position Time of Applicability 0 2 N/A N/A 9-14 48
Airborne Velocity - Type 1 Velocity Time of Applicability 0 1 N/A N/A 9-14 48
Airborne Position Latitude (WGS-84) 0 0 3 7 15-17 24
Airborne Position Longitude (WGS-84) 0 0 3 7 18-20 24
Airborne Position Altitude, Geometric (WGS-84) 1 7 3 6 21-23 24
Airborne Velocity - Type 1 North/South Velocity 1 6 3 5 24-25 16
Airborne Velocity - Type 1 East/West Velocity 1 6 3 5 26-27 16
Surface Position Movement (i.e., Ground Speed) 1 5 3 4 28 8
Surface Position Heading while on the surface 1 4 3 3 29 8
Airborne Position Altitude, Barometric (Pressure) 1 3 3 2 30-32 24
Airborne Velocity - Type 1 Vertical Rate, Geometric (WGS-84) 1 2 3 1 33-34 16
Airborne Velocity - Type 1 Barometric Altitude Rate 1 2 3 1 33-34 16
Airborne Position NIC 1 1 N/A N/A 35 4
Airborne Position Estimated Latitude (WGS-84) 1 0 3 0 36-38 24
Airborne Position Estimated Longitude (WGS-84) 2 7 3 0 39-41 24
Airborne Velocity - Type 1 Estimated North/South Velocity 2 6 4 7 42-43 16
Airborne Velocity - Type 1 Estimated East/West Velocity 2 5 4 7 44-45 16
Airborne Position Surveillance Status / Discretes 46 4
& (for Report Formatting see 2 4 N/A N/A
Airborne Velocity 2.2.8.1.21) 46 4
Any Message Type Report Mode 2 3 N/A N/A 47 2
Not Applicable Reserved For Future Expansion 2 0-2 N/A N/A N/A N/A
2.4.8.1.1.2 Verification of State Vector Report Validity Flags Reporting (2.2.8.1.1.2)

Appropriate test procedures provided in 2.4.8.1.5 through 2.4.8.1.20 shall be used to
validate the reporting of validity flags.

Appropriate test procedures to validate the Participant Address (2.2.3.2.1.5) are included in
the verification of the PI field in 2.4.3.2.1.7.
2.4.8.1.3 Verification of the Address Qualifier (2.2.8.1.3)

The Address Qualifier subfield is used to indicate the type of Participant Address
(2.2.3.2.1.5) being reported and the encoding is specified in Table 2-85.
20xx, RTCA, Inc.

629
Step 1: Initialization
Provide valid ADS-B Position and Velocity Messages to the ADS-B Receiving
Subsystem such that the ADS-B Report Assembly Function enters the Track State
and is outputting Reports to the Report Buffer. Verify that the Report Type Code
(bits 7 through 4 of byte 0) is set to ONE (binary 0001) to indicate State Vector
Report.
Step 2: Verification of ICAO Address for Unknown Emitter
Input an ADS-B Aircraft Identification and Category Message where an ICAO

address is being reported as the Participant Address for an unknown emitter
category.
Verify that the three least significant bits of Byte 8 in the output report are set to
ALL ZEROs (binary 000).
Step 3: Verification of Non-ICAO Address for Unknown Emitter
Input an ADS-B Aircraft Identification and Category Message where a Non-ICAO

address is being reported as the Participant Address for an unknown emitter
category.
ONE (binary 001).
Step 4: Verification of ICAO Address for an Aircraft

address is being reported as the Participant Address for an aircraft.
TWO (binary 010).
Step 5: Verification of Non-ICAO Address for an Aircraft

address is being reported as the Participant Address for an aircraft.
THREE (binary 011).
Step 6: Verification of ICAO Address for a Surface Vehicle, Fixed Ground or Tethered
Obstruction

address is being reported as the Participant Address for a surface vehicle, a fixed
ground or a tethered obstruction.
20xx, RTCA, Inc.

630
FOUR (binary 100).
Step 7: Verification of Non-ICAO Address for a Surface Vehicle, Fixed Ground or

Tethered Obstruction

address is being reported as the Participant Address for a surface vehicle, a fixed
ground or a tethered obstruction.
FIVE (binary 101).
2.4.8.1.4 Verification of the Report Time of Applicability (2.2.8.1.4)

Appropriate test procedures required to validate the requirements of 2.2.8.1.4 are included
in the following subparagraphs.
2.4.8.1.4.1 Verification of the Time of Applicability for Estimated Position/Velocity (2.2.8.1.4.1)

The Time of Applicability for the estimated position and velocity is generated under the
conditions specified in 2.2.8.1.4.1.
Step 1: Verification of (TOA) for Estimated Position and Velocity Reporting Position
Updates
Within a ten (10) second period, generate a series of even and odd Airborne
Position Messages having a stable TYPE code which include encoded data (ME
Bits 23 39 for Latitude, and Bits 40 56 for Longitude) for both valid Latitude
and valid Longitude based on any convenient starting position and any valid
velocity. Verify that the Report Assembly Function outputs a State Vector Report
with the Time of Applicability for Position and Velocity Subfields updated to
reflect the data in the most recently received Airborne Position Message.
Update the State Vector Report as specified in 2.2.8.1.17 and 2.2.8.1.18 and, in
each case, verify that the Time of Applicability for Estimated Position and
Velocity presence bit, bit 3 of byte 0 (Table 2-83), is set to ONE (1), that the
Horizontal Position Validity Flag, bit 7 of byte 3 (Table 2-84), is set to ONE (1),
that the Airborne Horizontal Velocity Validity Flag, bit 5 of byte 3, is set to ONE
(1), and that the corresponding Estimated Time of Applicability for Position and
Velocity Subfield reflects these updates in the next output State Vector Report.
Repeat this step with the Time of Applicability for Estimated Position and
Velocity presence bit, bit 3 of byte 0, set to ONE (1), the Horizontal Position
Validity Flag, bit 7 of byte 3, set to ONE (1), and the Airborne Horizontal
20xx, RTCA, Inc.

631
Velocity Validity Flag, bit 5 of byte 3, set to ZERO (0). Verify that the Estimated
Time of Applicability for Position and Velocity Subfield is set to ALL ZEROs in
the next output State Vector Report.
Validity Flag, bit 7 of byte 3, set to ZERO (0), and the Airborne Horizontal
Velocity Validity Flag, bit 5 of byte 3, set to ONE (1). Verify that the Estimated
Step 2: Verification of (TOA) for Estimated Position and Velocity Reporting Velocity
Updates
Within a ten (10) second period, generate a series of even and odd Airborne
and valid Longitude based on any convenient starting position and any valid
velocity. Verify that the Report Assembly Function outputs a State Vector Report
with the Time of Applicability for Position and Velocity Subfields updated to
reflect the data in the most recently received Airborne Position Message.
Update the State Vector Report as specified in 2.2.8.1.19 and 2.2.8.1.20 and, in
each case, verify that the Time of Applicability for Estimated Position and
Velocity presence bit, bit 3 of byte 0, is set to One (1), that the Horizontal Position
Validity Flag, bit 7 of byte 3, is set to One (1), that the Airborne Horizontal
Velocity Validity Flag, bit 5 of byte 3, is set to ONE (1), and that the
corresponding Estimated Time of Applicability for Position and Velocity Subfield
reflects these updates in the next output State Vector Report.
Validity Flag, bit 7 of byte 3, set to ONE (1), and the Airborne Horizontal
Velocity Validity Flag, bit 5 of byte 3, set to ZERO (0). Verify that the Estimated
Validity Flag, bit 7 of byte 3, set to ZERO (0), and the Airborne Horizontal
Velocity Validity Flag, bit 5 of byte 3, set to ONE (1). Verify that the Estimated
Step 3: Verification of (TOA) for Estimated Position (resulting from received Surface
Position Messages) Reporting
Within a ten (10) second period, generate a series of even and odd Surface
and valid Longitude based on any convenient starting position, and which include
20xx, RTCA, Inc.

632
encoded data (ME Bits 6 12) for a Ground Speed (Movement) of 2 knots
(forces High rate of two Surface Position Messages per second). Verify that the
Report Assembly Function outputs a State Vector Report with the Report Mode
set to TWO (binary xxxx 0010) within 500 milliseconds of receipt of the second
Surface Position Message of the even and odd pair for the given Surface
Participant.
Update the State Vector Report as specified in 2.2.8.1.17, 2.2.8.1.18,

2.2.8.1.19 and 2.2.8.1.20 and, in each case, verify that the corresponding
Position Time of Applicability bit (Report Byte #2, Bit 1), and the Latitude and
Longitude Validity Flag (Report Byte #4, Bit 7), are both set to ONE.
Verify that the reported Binary Decoded Position Time of Applicability datum
(Report Bytes # 40 41) changes by less than 500 ms between reports.
Step 4: Verification of (TOA) for Estimated Velocity (resulting from received Surface
Position Messages) Reporting
Repeat step 3 and verify that the Report Assembly Function outputs a State Vector
Report with the Report Mode set to TWO (binary xxxx 0010). Generate a series
of even and odd Surface Position Messages having a stable TYPE code,
which include encoded data (ME Bits 6 12) for a Ground Speed (Movement)
of 2 knots (forces High rate of two Surface Position Messages per second), and
a Ground Track Status (ME Bit 13) of ONE, and encoded data (ME Bits 14
20) for any convenient Ground Track heading.
Update the State Vector Report as specified in 2.2.8.1.17, 2.2.8.1.18,

2.2.8.1.19 and 2.2.8.1.20 and, in each case, verify that the corresponding
Velocity Time of Applicability presence bit (Report Byte #2, Bit 0), Ground
Speed Validity Flag (Report Byte #4, Bit 0), and Ground Track Validity Flag
(Report Byte #5, Bit 7), are both set to ONE.
Verify that the reported Binary Decoded Velocity Time of Applicability datum
changes by less than 500 ms between reports.
2.4.8.1.4.2 Verification of the Position Time of Applicability (2.2.8.1.4.2)

Appropriate test procedures required to validate the requirements of 2.2.8.1.4.2 are
included in the following subparagraphs.
2.4.8.1.4.2.1 Verification of Position Time of Applicability when TIME (T)=0 (2.2.8.1.4.2.1)

These test procedures verify that each time an Airborne or Surface Position Message is
received with valid Latitude AND Longitude data and TIME (T)=0, the Report Assembly
Function updates the Position Time of Applicability data in the State Vector Report with the
Time of Message Receipt of the position message expressed as either the GPS/GNSS UTC
Measure Time data (see 2.2.8.5.1) or the Established Receiver Unit Time (see 2.2.8.5.2).
20xx, RTCA, Inc.

633
Time of Applicability is rounded to the nearest LSB of the Position Time of Applicability
field.
Equipment Required:
The unit under test must be capable of receiving messages and producing State Vector
Reports. A stimulus capable of forming and transmitting compliant 1090ES Messages at
specific times and an apparatus for analyzing State Vector Report contents are required.
Step 1: Position Time of Applicability for Airborne Position Messages When TIME
(T)=0
Generate a series of Airborne Position Messages per Table 2-171 which have a
stable TYPE Code and include encoded data (ME Bits 23 - 39 for Latitude, and
Bits 40 - 56 for Longitude) for both valid Latitude and valid Longitude based on
any convenient starting position. The latitude and longitude in each message shall
be unique among the latitudes and longitudes used in the set of messages.
Ensure that the unit under test does not have a track file for the target address used
in the Airborne Position Messages. Inject the Airborne Position Messages into the
unit under test at the times shown in the Receiver Input Time column of Table
2-171. Verify that the difference in Position TOA between State Vector Reports
matches the value in the TOA Difference Between Reports column of Table 2-
171 rounded to the nearest LSB. Verify that the Latitude and Longitude in each
State Vector Report matches the CPR Coordinate Latitude and Longitude of the
CPR Coordinates used in each Airborne Position Message.
Note: The CPR Coordinate Latitude is determined with the Locally

Unambiguous CPR Decoding procedure in A.1.7.5 using the latitudes
and longitudes that were CPR encoded into the Airborne Position
Messages.
Table 2-171: Position Message Contents for Position TOA Verification When T=0
Receiver TOA
CPR
Input Difference
Format Comment
Time Between
(F)
(UTC sec) Reports
0 t0 No Report
1 t0 + 0.5 First Report First global decode complete
0 t0 + 0.9 0.40
1 t0 + 1.5 0.60 Second global decode complete
1 t0 + 2.05 0.55
0 t0 + 2.55 0.50
20xx, RTCA, Inc.

634
Step 2: Position Time of Applicability for Surface Position Messages When TIME
(T)=0
Repeat Step 1 using Surface Position Messages. Verify that the difference in
Position TOA between State Vector Reports matches the value in the TOA
Difference Between Reports column of Table 2-171-A rounded to the nearest
LSB. Verify that the Latitude and Longitude in each State Vector Report matches
the CPR Coordinate Latitude and Longitude of the CPR Coordinates used in each
Surface Position Message.

and longitudes that were CPR encoded into the Surface Position
Messages.
2.4.8.1.4.2.2 Verification of Position Time of Applicability When TIME (T)=1 and UTC Time of
Message Receipt is Available (2.2.8.1.4.2.2)
These test procedures verify that each time an Airborne or Surface Position Message is
received with TIME (T)=1 and valid Latitude AND Longitude data, and when a valid
UTC Time of Message Receipt is available per 2.2.8.5.1, the Report Assembly Function
updates the Position Time of Applicability data in the State Vector Report with the
appropriate 0.2 second UTC epoch.
Equipment Required:
The unit under test must be provided with a UTC time reference, and must be capable of
receiving messages and producing State Vector Reports. A stimulus capable of forming and
transmitting compliant 1090ES Messages at specific UTC times and a UTC time reference
for this stimulus are required. An apparatus for capturing State Vector Reports and
analyzing their contents is also required.
Step 1: Position Time of Applicability for Airborne Position Messages When TIME
(T)=1 and UTC Time of Message Receipt is Available
Generate a series of Airborne Position Messages per Table 2-171-A which have a
stable TYPE Code and include encoded data (ME Bits 23 - 39 for Latitude, and
Bits 40 - 56 for Longitude) for both valid Latitude and valid Longitude based on
any convenient starting position. The latitude and longitude in each message shall
be unique among the latitudes and longitudes used in the set of messages.
Ensure that the unit under test does not have a track file for the target address used
in the Airborne Position Messages. Inject the Airborne Position Messages into the
unit under test at the times shown in the Receiver Input Time column of Table
2-171-A. Verify that the Position TOA in the State Vector Reports matches the
value in the Expected Position TOA column of Table 2-171-A rounded to the
20xx, RTCA, Inc.

635
nearest LSB. Verify that the Latitude and Longitude in each State Vector Report
matches the CPR Coordinate Latitude and Longitude of the CPR Coordinates used
in each Airborne Position Message.

and longitudes that were CPR encoded into the Airborne Position
Messages.
Table 2-171-A: Messages for Position TOA Verification when T=1

TOA of
CPR Receiver Expected
Lat/Lon in
Format Input Time Position Comment
Position
(F) (UTC sec) TOA
Message
teven + 0 0 teven + 0 No Report
teven + 0.6 1 teven + 0.5 teven + 0.6 First global decode complete
teven + 0.8 0 teven + 0.9 teven + 0.8
teven + 1.4 1 teven + 1.5 teven + 1.4 Second global decode complete
New data loaded and transmitted at the
beginning of the 50-150ms window
Old data transmitted at the end of the 50-150
ms window just before loading of new data
Note: teven is any integer UTC second.
Step 2: Position Time of Applicability for Surface Position Messages When TIME
(T)=1 and UTC Time of Message Receipt is Available
Repeat Step 1 using Surface Position Messages. Verify that the Position TOA in
the State Vector Reports matches the value in the Expected Position TOA
column of Table 2-171-A rounded to the nearest LSB. Verify that the Latitude
and Longitude in each State Vector Report matches the CPR Coordinate Latitude
and Longitude of the CPR Coordinates used in each Surface Position Message.

and longitudes that were CPR encoded into the Surface Position
Messages.
2.4.8.1.4.2.3 Verification of Position Time of Applicability when TIME (T) = 1 and UTC Time
of Message Receipt is NOT available (2.2.8.1.4.2.3)
The requirement in 2.2.8.1.4.2.3 is verified using the test procedure specified in
2.4.8.1.4.2.1.
20xx, RTCA, Inc.

636
2.4.8.1.4.3 Verification of the Velocity Time of Applicability (2.2.8.1.4.3)

These test procdures verify that each time an Airborne Velocity Message - Subtype=1 or
2 is received with valid East/West AND North/South Velocity data, the Report Assembly
Function updates the Velocity Time of Applicability data in the State Vector Report with
either the GPS/GNSS UTC Measure Time data (see 2.2.8.5.1) or the Established Receiver
Unit Time (see 2.2.8.5.2), whichever is applicable to the Receiving device Report
Assembly Function installation requirements.
These test procedures also verify that each time a Surface Position Message is received with
valid Movement AND Ground Track data, the Report Assembly Function updates the
Velocity Time of Applicability data in the State Vector Report with either the GPS/GNSS
UTC Measure Time data (see 2.2.8.5.1) or the Established Receiver Unit Time (see
2.2.8.5.2), whichever is applicable to the Receiving device Report Assembly Function
installation requirements.
Step 1: Velocity Time of Applicability Updating and Reporting (resulting from received
Airborne Velocity Messages - Subtype=1) Reporting
Repeat Step 1 of 2.2.8.1.4.2 and verify that the Report Assembly Function
outputs a State Vector Report with the Report Mode set to ONE (binary xxxx
0001). Generate an Airborne Velocity Message (TYPE=19, Subtype=1), which
includes encoded data (ME Bits 14 - 24 for E/W Velocity, and ME Bits 25 -
35 for N/S Velocity) based on any convenient valid velocity. Verify that the
Report Assembly Function outputs a State Vector Report with the Report Mode
set to TWO (binary xxxx 0010) within 500 milliseconds of the receipt of the
Verify that the corresponding Velocity Time of Applicability presence bit (Report
Byte #2, Bit 0), and the N/S & E/W Velocity Validity Flag (Report Byte #4, Bit
5), are set to ONEs. Verify that the Velocity Time of Applicability presence bit,
bit 1 of byte 2, is set to ONE (1).
(Report Bytes # 42 - 43) changes by less than 500 ms between reports. Table 2-
172 below shows an example of a possible time progression from a series of
reports.
Repeat this step with the Velocity Time of Applicability presence bit, bit 1 of byte
2, set to ONE (1) and the N/S & E/W Validity Flag, bit 5 of byte 3, set to ZERO
(0). Verify that the Velocity Time of Applicability Subfield is set to ALL ZEROs
in the next output State Vector Report.
20xx, RTCA, Inc.

637
Table 2-172: Velocity Time of Applicability Example Test Data

Velocity Time of Applicability
Example Time Binary Decoded Velocity
(seconds) Time of Applicability
Reference Time 0101 0101 0101 0110
Reference Time + Approximately 0.5 0101 0101 1001 0010
Step 2: Velocity Time of Applicability Updating and Reporting (resulting from received
Surface Position Messages)
Repeat Step 2 of 2.2.8.1.4.2 and verify that the Report Assembly Function
outputs a State Vector Report with the Report Mode set to TWO (binary xxxx
0010). Generate a series of even and odd Surface Position Messages having a
stable TYPE code, which include encoded data (ME Bits 6 - 12) for a Ground
Speed (Movement) of 2 knots (forces High rate of two Surface Position
Messages per second), which include a Ground Track Status (ME Bit 13) of
ONE, and which include encoded data (ME Bits 14 - 20) for any convenient
Ground Track heading.
Verify that the corresponding Velocity Time of Applicability presence bit (Report
Byte #2, Bit 0), Ground Speed validity flag (Report Byte #4, Bit 0), and Ground
Track validity flag (Report Byte #5, Bit 7), are set to ONEs. Verify that the
Velocity Time of Applicability presence bit, bit 1 of byte 2, is set to ONE (1).
changes by less than 500 ms between reports. Table 2-172 above shows an
example of a possible time progression from a series of reports.
Repeat this step with the Velocity Time of Applicability presence bit, bit 1 of byte
2, set to ONE (1) and the N/S & E/W Validity Flag, bit 5 of byte 3, set to ZERO
(0). Verify that the Velocity Time of Applicability Subfield is set to ALL ZEROs
in the next output State Vector Report.
2.4.8.1.5 Verification of Latitude (WGS-84) Reporting (2.2.8.1.5)

These test procedures verify that the ADS-B Report Assembly Function decodes the
Encoded Latitude data (2.2.3.2.3.7 and /or 2.2.3.2.4.7) provided in the ADS-B broadcast.
Decoding of the encoded latitude data is performed in accordance with A.1.7.4 through
A.1.7.8.4 of Appendix A. Latitude data is provided to the user application in the State
Vector report in angular weighted binary format (M bit = 90 degrees, S bit = negative, or
180 degrees) as specified in Table 2-81.
When valid encoded latitude data is not available, the latitude data provided to the user
application is set to ALL ZEROs, and the Horizontal Position Validity Flag bit, i.e., bit #7
20xx, RTCA, Inc.

638
(MSB) of byte #3 of the State Vector Report, is set to ZERO (0) to indicate that the reported
Horizontal Position data is not valid. Otherwise, the Horizontal Position Validity Flag bit,
i.e., bit #7 (MSB) of byte #3 of the State Vector Report, is set to ONE (1), unless modified
by other conditions.
Step 1: Latitude (WGS-84) Decoding
For each case in Table 2-174 below, generate valid Airborne Position Messages
that include the encoded data (ME Bits 23 - 39) for the Decimal Latitude value
listed, and verify that the ADS-B Receiver/Report Assembly outputs State Vector
Report of Type 0001.
Verify that the corresponding Latitude presence bit (Report Byte #0, Bit 0), and
the Horizontal Position Validity flag (Report Byte #3, Bit 7), are ONEs.
Verify that the reported Binary Decoded (WGS-84) Latitude datum match the
corresponding value in the table.
20xx, RTCA, Inc.

639
Table 2-173: Longitude Test Data

Longitude
Decimal Integer Binary Decoded
Longitude Longitude (WGS-84) Longitude
(degrees) (degrees) (angular weighted)
0.000000 0 0000 0000 0000 0000 0000 0000
0.000021 1 0000 0000 0000 0000 0000 0001
0.000043 2 0000 0000 0000 0000 0000 0010
0.000107 5 0000 0000 0000 0000 0000 0101
0.000215 10 0000 0000 0000 0000 0000 1010
0.000429 20 0000 0000 0000 0000 0001 0100
0.000880 41 0000 0000 0000 0000 0010 1001
0.001760 82 0000 0000 0000 0000 0101 0010
0.003541 165 0000 0000 0000 0000 1010 0101
0.007081 330 0000 0000 0000 0001 0100 1010
0.014162 660 0000 0000 0000 0010 1001 0100
0.028324 1320 0000 0000 0000 0101 0010 1000
0.056648 2640 0000 0000 0000 1010 0101 0000
0.113297 5280 0000 0000 0001 0100 1010 0000
0.226593 10560 0000 0000 0010 1001 0100 0000
0.453186 21120 0000 0000 0101 0010 1000 0000
0.906372 42240 0000 0000 1010 0101 0000 0000
1.812744 84480 0000 0001 0100 1010 0000 0000
3.625488 168960 0000 0010 1001 0100 0000 0000
7.250977 337920 0000 0101 0010 1000 0000 0000
14.501953 675840 0000 1010 0101 0000 0000 0000
29.003906 1351680 0001 0100 1010 0000 0000 0000
58.007813 2703360 0010 1001 0100 0000 0000 0000
116.015625 5406720 0101 0010 1000 0000 0000 0000
-127.968750 10813440 1010 0101 0000 0000 0000 0000
104.062500 4849664 0100 1010 0000 0000 0000 0000
-151.875000 9699328 1001 0100 0000 0000 0000 0000
56.250000 2621440 0010 1000 0000 0000 0000 0000
112.500000 5242880 0101 0000 0000 0000 0000 0000
-135.000000 10485760 1010 0000 0000 0000 0000 0000
90.000000 4194304 0100 0000 0000 0000 0000 0000
180.000000 8388608 1000 0000 0000 0000 0000 0000
Step 2: Longitude (WGS-84) Decoding
For each case in Table 2-173 above, generate valid Airborne Position Messages
that include the encoded data (ME Bits 40 - 56) for the Decimal Longitude
value listed, and verify that the ADS-B Receiver/Report Assembly outputs State
Vector Reports of Type 0001.
Verify that the corresponding Longitude presence bit (Report Byte #0, Bit 0), and
the Horizontal Position Validity flag (Report Byte #3, Bit 7), are ONEs.
Verify that the reported Binary Decoded (WGS-84) Longitude datum matches the
corresponding value in the table.
20xx, RTCA, Inc.

640
Table 2-174: Latitude Test Data

Latitude
Decimal Integer Binary Decoded
Latitude Latitude (WGS-84) Latitude
(degrees) (degrees) (angular weighted)
0.000000 0 0000 0000 0000 0000 0000 0000
0.000037 1 0000 0000 0000 0000 0000 0001
0.000073 3 0000 0000 0000 0000 0000 0011
0.000147 6 0000 0000 0000 0000 0000 0110
0.000294 13 0000 0000 0000 0000 0000 1101
0.000587 27 0000 0000 0000 0000 0001 1011
0.001175 54 0000 0000 0000 0000 0011 0110
0.002350 109 0000 0000 0000 0000 0110 1101
0.004699 219 0000 0000 0000 0000 1101 1011
0.009398 438 0000 0000 0000 0001 1011 0110
0.018797 876 0000 0000 0000 0011 0110 1100
0.037594 1752 0000 0000 0000 0110 1101 1000
0.075188 3504 0000 0000 0000 1101 1011 0000
0.150375 7008 0000 0000 0001 1011 0110 0000
0.300751 14016 0000 0000 0011 0110 1100 0000
0.601501 28032 0000 0000 0110 1101 1000 0000
1.203003 56064 0000 0000 1101 1011 0000 0000
2.406006 112128 0000 0001 1011 0110 0000 0000
4.812012 224256 0000 0011 0110 1100 0000 0000
9.624023 448512 0000 0110 1101 1000 0000 0000
19.248047 897024 0000 1101 1011 0000 0000 0000
38.496094 1794048 0001 1011 0110 0000 0000 0000
76.992188 3588096 0011 0110 1100 0000 0000 0000
-52.031250 14352384 1101 1011 0000 0000 0000 0000
-56.250000 14155776 1101 1000 0000 0000 0000 0000
-90.000000 12582912 1100 0000 0000 0000 0000 0000
Step 3: Latitude and Longitude Data Not Available
Keep the Latitude and Longitude presence bits at ONE, and set the Horizontal
Position Validity flag to ZERO. Verify that the reported Binary Decoded
Latitude and Longitude data are set to all ZEROs.
2.4.8.1.6 Verification of Longitude (WGS-84) Reporting (2.2.8.1.6)

Appropriate test procedures to validate the requirements of 2.2.8.1.6 are provided in
2.4.8.1.5.
20xx, RTCA, Inc.

641
2.4.8.1.7 Verification of Altitude, Geometric (WGS-84) Reporting (2.2.8.1.7)

These test procedures verify the proper reporting of altitude date as specified in 2.2.8.1.7.
Step 1: Geometric Altitude (WGS-84) Reporting for Q Bit =ONE (2.2.8.1.7.a & .c)
For each case in Table 2-175 below, generate valid Airborne Position Messages,
with TYPE codes of 20 through 22, which include the encoded datum (ME
Bits 9 - 20) for the Decimal Altitude value listed, with an imbedded Q bit
(ME Bit 16) of ONE, and verify that the ADS-B Receiver/Report Assembly
outputs State Vector Reports of Type 0001.
Verify that the corresponding Geometric Altitude presence bit (Report Byte #1,
Bit 7), and Geometric Altitude Validity Flag (Report Byte #3, Bit 6), are ONEs.
Verify that the reported Binary Decoded (WGS-84) Geometric Altitude datum
(Report Bytes # 21 23) matches the corresponding value in the table.
20xx, RTCA, Inc.

642
Table 2-175: Geometric Altitude Test Data (Q Bit = 1)

Geometric (WGS-84) Altitude (Q Bit = 1)
Decimal Altitude Integer Altitude Binary Decoded (WGS-84)
(feet) (Binary) Geometric Altitude
-1000 -64000 1111 1111 0000 0110 0000 0000
-975 -62400 1111 1111 0000 1100 0100 0000
-925 -59200 1111 1111 0001 1000 1100 0000
-825 -52800 1111 1111 0011 0001 1100 0000
-625 -40000 1111 1111 0110 0011 1100 0000
-575 -36800 1111 1111 0111 0000 0100 0000
-500 -32000 1111 1111 1000 0011 0000 0000
-225 -14400 1111 1111 1100 0111 1100 0000
-200 -12800 1111 1111 1100 1110 0000 0000
-125 -8000 1111 1111 1110 0000 1100 0000
-25 -1600 1111 1111 1111 1001 1100 0000
0 0 0000 0000 0000 0000 0000 0000
25 1600 0000 0000 0000 0110 0100 0000
50 3200 0000 0000 0000 1100 1000 0000
100 6400 0000 0000 0001 1001 0000 0000
200 12800 0000 0000 0011 0010 0000 0000
400 25600 0000 0000 0110 0100 0000 0000
800 51200 0000 0000 1100 1000 0000 0000
1600 102400 0000 0001 1001 0000 0000 0000
3200 204800 0000 0011 0010 0000 0000 0000
6400 409600 0000 0110 0100 0000 0000 0000
12800 819200 0000 1100 1000 0000 0000 0000
25600 1638400 0001 1001 0000 0000 0000 0000
49175 3147200 0011 0000 0000 0101 1100 0000
49200 3148800 0011 0000 0000 1100 0000 0000
50175 3211200 0011 0000 1111 1111 1100 0000
Step 2: Geometric Altitude (WGS-84) Reporting for Q Bit =ZERO (2.2.8.1.7.a &.c)
with Type codes of 20 through 22, which include the encoded datum (ME
Bits 9 - 20) for the Decimal Altitude value listed, with an imbedded Q bit
(ME Bit 16) of ZERO, and verify that the ADS-B Receiver/Report Assembly
Verify that the corresponding Geometric Altitude presence bit (Report Byte #1,
Bit 7), and Geometric Altitude Validity Flag (Report Byte #3, Bit 6), are set to
ONEs.
Verify that the reported Binary Decoded (WGS-84) Geometric Altitude datum
20xx, RTCA, Inc.

643
Table 2-176: Geometric Altitude Test Data (Q Bit = 0)

Geometric (WGS-84) Altitude (Q Bit = 0)
Decimal Altitude Integer Altitude Binary Decoded (WGS-84)
(feet) (Binary) Geometric Altitude
-1000 -64000 1111 1111 0000 0110 0000 0000
-800 -51200 1111 1111 0011 1000 0000 0000
-100 -6400 1111 1111 1110 0111 0000 0000
0 0 0000 0000 0000 0000 0000 0000
100 6400 0000 0000 0001 1001 0000 0000
200 12800 0000 0000 0011 0010 0000 0000
400 25600 0000 0000 0110 0100 0000 0000
800 51200 0000 0000 1100 1000 0000 0000
1600 102400 0000 0001 1001 0000 0000 0000
3200 204800 0000 0011 0010 0000 0000 0000
6400 409600 0000 0110 0100 0000 0000 0000
12800 819200 0000 1100 1000 0000 0000 0000
25600 1638400 0001 1001 0000 0000 0000 0000
51200 3276800 0011 0010 0000 0000 0000 0000
102400 6553600 0110 0100 0000 0000 0000 0000
126700 8108800 0111 1011 1011 1011 0000 0000
Step 3: Barometric Altitude (WGS-84) Reporting for Q Bit =ONE (2.2.8.1.7.b &.c)
For each case in Table 2-175 above, generate valid Airborne Position Messages,
with Type codes of 9 through 18, which include the encoded datum (ME Bits
9 - 20) for the Decimal Altitude value listed, with an imbedded Q bit (ME Bit
16) of ONE, and verify that the ADS-B Receiver/Report Assembly outputs State
Verify that the corresponding Barometric Altitude presence bit (Report Byte #1,
Bit 3), and Barometric Altitude Validity Flag (Report Byte #3, Bit 2), are ONEs.
Verify that the reported Binary Decoded (WGS-84) Barometric Altitude datum
Step 4: Barometric Altitude (WGS-84) Reporting for Q Bit = ZERO

(2.2.8.1.7.b&c)
16) of ZERO, and verify that the ADS-B Receiver/Report Assembly outputs
State Vector Reports of Type 0001.
Verify that the corresponding Barometric Altitude presence bit (Report Byte #1,
Bit 3), and Barometric Altitude Validity Flag (Report Byte #3, Bit 2), are ONEs.
Verify that the reported Binary Decoded (WGS-84) Barometric Altitude datum
20xx, RTCA, Inc.

644
Step 5: Difference from Barometric Altitude Reporting (2.2.8.1.7.b)
For each case in Table 2-177 below, generate valid Airborne Velocity Messages,
with TYPE=19, and Subtype=1, which includes the encoded data (Difference
from Barometric Altitude Sign, ME bit 49, and Difference from Barometric
Altitude, ME Bits 50 - 56) resulting from using the Decimal GNSS Altitude and
Decimal Barometric Altitude values listed, and verify that the ADS-B
Receiver/Report Assembly outputs State Vector Reports of Type 0001.
Verify that the corresponding Difference From Barometric Altitude presence bit
(Report Byte #1, Bit 7), and Geometric Altitude Validity Flag (Report Byte #3,
Bit 6), are ONEs.
Verify that the reported Binary Decoded (WGS-84) Difference from Barometric
Altitude datum matches the corresponding value in the table.
Repeat this procedure for Velocity Message Subtypes 2, 3 and 4.
Table 2-177: Difference From Barometric Altitude (w/ Sign) Test Data
Difference From Barometric Altitude
Decimal Decimal
Decimal
GNSS Barometric Binary Decoded (WGS-84)
Difference
Altitude Altitude Difference from Barometric
(feet)
(feet) (feet)
100 3250 -3150 1111 1111 1001 1101 1001 0000
100 1700 -1600 1111 1111 1100 1110 0000 0000
100 900 -800 1111 1111 1110 0111 0000 0000
100 500 -400 1111 1111 1111 0011 1000 0000
100 300 -200 1111 1111 1111 1001 1100 0000
100 200 -100 1111 1111 1111 1100 1110 0000
100 150 -50 1111 1111 1111 1110 0111 0000
100 125 -25 1111 1111 1111 1111 0011 1000
100 100 0 0000 0000 0000 0000 0000 0000
125 100 25 0000 0000 0000 0000 1100 1000
150 100 50 0000 0000 0000 0001 1001 0000
200 100 100 0000 0000 0000 0011 0010 0000
300 100 200 0000 0000 0000 0110 0100 0000
500 100 400 0000 0000 0000 1100 1000 0000
900 100 800 0000 0000 0001 1001 0000 0000
1700 100 1600 0000 0000 0011 0010 0000 0000
3250 100 3150 0000 0000 0110 0010 0111 0000
Step 6: Geometric Altitude Data Not Available (2.2.8.1.7.d)
Generate valid ADS-B Airborne Position Messages with the Altitude set to ALL
ZEROs to indicate that there is no data available. Verify that the reported Binary
Decoded Geometric Altitude data (Report Bytes # 21 23) is set to all ZEROs.
20xx, RTCA, Inc.

645
2.4.8.1.8 Verification of North/South Velocity Reporting (2.2.8.1.8)

These test procedures verify the proper reporting of North/South Velocity as specified in
2.2.8.1.8.
Step 1: North/South Velocity (Subsonic) Reporting (2.2.8.1.8.a)
For each case in Table 2-178 below, generate valid Airborne Velocity Messages
(Subtype 1, Subsonic) which include the encoded Direction Bit and Velocity data
(ME Bits 25 - 35 for North/South and Bits 14 - 24 for East/West) for the
Decimal North/South and Decimal East/West Velocity values listed, and verify
that the ADS-B Receiver/Report Assembly outputs State Vector Reports of Type
0001.
Verify that the corresponding North/South Velocity presence bit (Report Byte #1,
Bit 6), and Airborne Horizontal Velocity Validity Flag (Report Byte #3, Bit 5), are
ONEs.
Verify that the reported Binary Decoded North/South Velocity datum (Report
Bytes # 20 - 21) matches the corresponding Binary North/South Velocity value in
the table.
20xx, RTCA, Inc.

646
Table 2-178: North/South Velocity (Subsonic) Test Data

North/South Velocity (subsonic)
North/South East/West
Binary Decoded
Decimal Decimal
North/South Subsonic
Velocity Velocity
Velocity
(knots) (knots)
-1021 0 1110 0000 0001 1000
-512 0 1111 0000 0000 0000
-256 0 1111 1000 0000 0000
-128 0 1111 1100 0000 0000
-64 0 1111 1110 0000 0000
-32 0 1111 1111 0000 0000
-16 0 1111 1111 1000 0000
-8 0 1111 1111 1100 0000
-4 0 1111 1111 1110 0000
-2 0 1111 1111 1111 0000
-1 0 1111 1111 1111 1000
0 0 0000 0000 0000 0000
1 0 0000 0000 0000 1000
2 0 0000 0000 0001 0000
4 0 0000 0000 0010 0000
8 0 0000 0000 0100 0000
16 0 0000 0000 1000 0000
32 0 0000 0001 0000 0000
64 0 0000 0010 0000 0000
128 0 0000 0100 0000 0000
256 0 0000 1000 0000 0000
512 0 0001 0000 0000 0000
1021 0 0001 1111 1110 1000
Step 2: North/South Velocity (Supersonic) Reporting (2.2.8.1.8.a)
(Subtype 2, Supersonic) which include the encoded Direction Bit and Velocity
data (ME Bits 25 - 35 for North/South and Bits 14 - 24 for East/West) for the
Decimal North/South and Decimal East/West values listed, and verify that the
ADS-B Receiver/Report Assembly outputs State Vector Reports of Type 0001.
Verify that the corresponding North/South Velocity presence bit (Report Byte #1,
Bit 6), and the Airborne Horizontal Velocity Validity Flag (Report Byte #3, Bit 5),
are ONEs.
Verify that the reported Binary Decoded North/South Velocity datum matches the
corresponding Binary North/South Velocity value in the table.
20xx, RTCA, Inc.

647
Table 2-179: North/South Velocity (Supersonic) Test Data

North/South Velocity (supersonic)
Binary Decoded
Decimal Decimal
North/South Supersonic
Velocity Velocity
Velocity
(knots) (knots)
-4084 0 1000 0000 0110 0000
-2048 0 1100 0000 0000 0000
-1024 0 1110 0000 0000 0000
-512 0 1111 0000 0000 0000
-256 0 1111 1000 0000 0000
-128 0 1111 1100 0000 0000
-64 0 1111 1110 0000 0000
-32 0 1111 1111 0000 0000
-16 0 1111 1111 1000 0000
-8 0 1111 1111 1100 0000
-4 0 1111 1111 1110 0000
0 0 0000 0000 0000 0000
4 0 0000 0000 0010 0000
8 0 0000 0000 0100 0000
16 0 0000 0000 1000 0000
32 0 0000 0001 0000 0000
64 0 0000 0010 0000 0000
128 0 0000 0100 0000 0000
256 0 0000 1000 0000 0000
512 0 0001 0000 0000 0000
1024 0 0010 0000 0000 0000
2048 0 0100 0000 0000 0000
4084 0 0111 1111 1010 0000
Step 3: North/South Velocity (Subsonic / Supersonic) Data Not Available (2.2.8.1.8.b)
Keep the North/South Velocity presence bit at ONE, and set the North/South
Velocity validity flag to ZERO. Verify that the reported Binary Decoded
North/South Velocity datum is set to all ZEROs.
2.4.8.1.9 Verification of East/West Velocity Reporting (2.2.8.1.9)

These test procedures verify the proper reporting of East/West Velocity as specified in
2.2.8.1.9.
Step 1: East/West Velocity (Subsonic) Reporting (2.2.8.1.9.a)
(Subtype 1, Subsonic) which include the encoded Direction Bit and Velocity data
20xx, RTCA, Inc.

648
(ME Bits 25 - 35 for North/South and Bits 14 - 24 for East/West) for the
Decimal North/South and Decimal East/West Velocity values listed, and verify
0001.
Verify that the corresponding East/West Velocity presence bit (Report Byte #1,
Bit 6), and the Airborne Horizontal Velocity Validity Flag (Report Byte #3, Bit
#5), are ONEs.
Verify that the reported Binary Decoded East/West Velocity datum (Report Bytes
# 22 - 23) matches the corresponding Binary East/West Velocity value in the
table.
Table 2-180: East/West Velocity (Subsonic) Test Data

East/West Velocity (subsonic)
Binary Decoded
Decimal Decimal
East/West
Velocity Velocity
Subsonic Velocity
(knots) (knots)
0 -1021 1110 0000 0001 1000
0 -512 1111 0000 0000 0000
0 -256 1111 1000 0000 0000
0 -128 1111 1100 0000 0000
0 -64 1111 1110 0000 0000
0 -32 1111 1111 0000 0000
0 -16 1111 1111 1000 0000
0 -8 1111 1111 1100 0000
0 -4 1111 1111 1110 0000
0 -2 1111 1111 1111 0000
0 -1 1111 1111 1111 1000
0 0 0000 0000 0000 0000
0 1 0000 0000 0000 1000
0 2 0000 0000 0001 0000
0 4 0000 0000 0010 0000
0 8 0000 0000 0100 0000
0 16 0000 0000 1000 0000
0 32 0000 0001 0000 0000
0 64 0000 0010 0000 0000
0 128 0000 0100 0000 0000
0 256 0000 1000 0000 0000
0 512 0001 0000 0000 0000
0 1021 0001 1111 1110 1000
Step 2: East/West Velocity (Supersonic) Reporting (2.2.8.1.9.a)
(Subtype 2, Supersonic) which include the encoded Direction Bit and Velocity
data (ME Bits 25 - 35 for North/South and Bits 14 - 24 for East/West) for the
Decimal North/South and Decimal East/West values listed, and verify that the
20xx, RTCA, Inc.

649
Verify that the corresponding East/West Velocity presence bit (Report Byte #1,
Bit #6), and the Airborne Horizontal Velocity Validity Flag (Report Byte #3, Bit
#5), are ONEs.
Verify that the reported Binary Decoded North/South Velocity datum matches the
corresponding Binary East/West Velocity value in the table.
Table 2-181: East/West Velocity (Supersonic) Test Data

East/West Velocity (supersonic)
Binary Decoded
Decimal Decimal
East/West Supersonic
Velocity Velocity
Velocity
(knots) (knots)
0 -4084 1000 0000 0110 0000
0 -2048 1100 0000 0000 0000
0 -1024 1110 0000 0000 0000
0 -512 1111 0000 0000 0000
0 -256 1111 1000 0000 0000
0 -128 1111 1100 0000 0000
0 -64 1111 1110 0000 0000
0 -32 1111 1111 0000 0000
0 -16 1111 1111 1000 0000
0 -8 1111 1111 1100 0000
0 -4 1111 1111 1110 0000
0 0 0000 0000 0000 0000
0 4 0000 0000 0010 0000
0 8 0000 0000 0100 0000
0 16 0000 0000 1000 0000
0 32 0000 0001 0000 0000
0 64 0000 0010 0000 0000
0 128 0000 0100 0000 0000
0 256 0000 1000 0000 0000
0 512 0001 0000 0000 0000
0 1024 0010 0000 0000 0000
0 2048 0100 0000 0000 0000
0 4084 0111 1111 1010 0000
Step 3: East/West Velocity (Subsonic / Supersonic) Data Not Available (2.2.8.1.9.b)
Keep the East/West Velocity presence bit at ONE, and set the East/West
Velocity validity flag to ZERO. Verify that the reported Binary Decoded
East/West Velocity datum is set to all ZEROs.
2.4.8.1.10 Verification of Ground Speed Reporting While on the Surface (2.2.8.1.10)

These test procedures verify the proper reporting of Ground Speed as specified in
2.2.8.1.10.
20xx, RTCA, Inc.

650
Step 1: Ground Speed Reporting (2.2.8.1.10.a)
For each case in Table 2-182 below, generate valid Surface Position Messages
(Type codes of 5 through 8), which include the encoded datum (ME Bits 6 -
12) for the Decimal Ground Speed (Movement) values listed, and verify that the
Verify that the corresponding Ground Speed (Movement) presence bit (Report
Byte #1, Bit #5), and the Ground Speed (Movement) Validity Flag (Report Byte
#3, Bit #4), are ONEs.
Verify that the reported Binary Decoded Ground Speed datum (Report Byte # 35)
matches the corresponding value in the table.
Table 2-182: Ground Speed Test Data

Ground Speed
Decimal
Binary Decoded
Ground Speed
Ground Speed
(knots)
(Movement)
0.000 0000 0001
0.125 0000 0010
0.250 0000 0011
0.375 0000 0100
0.750 0000 0111
0.875 0000 1000
3.000 0000 1111
3.500 0001 0000
11.000 0001 1111
11.500 0010 0000
39.000 0011 1111
40.000 0100 0000
175.000 0111 1100
Step 2: Ground Speed Data Not Available (2.2.8.1.10.b)
Keep the Ground Speed (Movement) presence bit at ONE, and set the Ground
Speed (Movement) validity flag to ZERO. Verify that the reported Binary
Decoded Ground Speed (Movement) datum is set to all ZEROs.
2.4.8.1.11 Verification of Heading While on the Surface Reporting (2.2.8.1.11)

These test procedures verify the proper reporting of Heading while on the surface as
20xx, RTCA, Inc.

651
Step 1: Heading Reporting (2.2.8.1.11.a)
For each case in Table 2-183 below, generate valid Surface Position Messages
(Type codes of 5 through 8), which include the encoded data (ME Bits 13 and
14 - 20) for the Decimal Heading Status Bit and Heading values listed, and verify
0001.
Verify that the corresponding Heading presence bit (Report Byte #1, Bit 4), and
the Surface Heading Validity Flag (Report Byte #3, Bit 3), are ONEs.
Verify that the reported Binary Decoded Heading data (Report Byte # 36)
matches the corresponding value in the table.
Table 2-183: Heading Subfield Test Data

Heading
Decimal
Heading Binary Decoded
Heading
Status Heading
(degrees)
0 22.5000 0000 0000
0 357.1875 0000 0000
1 0.0000 0000 0000
1 2.8125 0000 0001
1 5.6250 0000 0010
1 11.2500 0000 0100
1 22.5000 0000 1000
1 45.0000 0001 0000
1 90.0000 0010 0000
1 180.0000 0100 0000
1 357.1875 0111 1111
Step 2: Heading Data Not Available (2.2.8.1.11.b)
Keep the Heading presence bit at ONE, and set the Heading validity flag to
ZERO. Verify that the reported Binary Decoded Heading datum is set to all
ZEROs.
2.4.8.1.12 Verification of Altitude, Barometric (Pressure Altitude) Reporting (2.2.8.1.12)

These test procedures verify the proper reporting of Barometric Altitude as specified in
2.2.8.1.12.
20xx, RTCA, Inc.

652
Step 1: Barometric (Pressure) Altitude Reporting (2.2.8.1.12.a)
16) of ONE, and verify that the ADS-B Receiver/Report Assembly outputs State
Verify that the corresponding Barometric (Pressure) Altitude presence bit (Report
Byte #1, Bit #3), and the Barometric (Pressure) Altitude Validity Flag (Report
Byte #3, Bit #2), are ONEs.
Verify that the reported Binary Decoded Barometric (Pressure) Altitude datum
(Report Bytes # 26 - 28) matches the corresponding value in the table.
Table 2-184: Barometric (Pressure) Altitude Test Data (Q Bit = 1)

Barometric (Pressure) Altitude (Q Bit = 1)
Decimal Altitude Binary Decoded
(feet) Barometric (Pressure) Altitude
-1000 1111 1111 1110 0000 1100 0000
-975 1111 1111 1110 0001 1000 1000
-925 1111 1111 1110 0011 0001 1000
-825 1111 1111 1110 0110 0011 1000
-625 1111 1111 1110 1100 0111 1000
-575 1111 1111 1110 1110 0000 1000
-500 1111 1111 1111 0000 0110 0000
-225 1111 1111 1111 1000 1111 1000
-200 1111 1111 1111 1001 1100 0000
-125 1111 1111 1111 1100 0001 1000
-25 1111 1111 1111 1111 0011 1000
0 0000 0000 0000 0000 0000 0000
25 0000 0000 0000 0000 1100 1000
50 0000 0000 0000 0001 1001 0000
100 0000 0000 0000 0011 0010 0000
200 0000 0000 0000 0110 0100 0000
400 0000 0000 0000 1100 1000 0000
800 0000 0000 0001 1001 0000 0000
1600 0000 0000 0011 0010 0000 0000
3200 0000 0000 0110 0100 0000 0000
6400 0000 0000 1100 1000 0000 0000
12800 0000 0001 1001 0000 0000 0000
25600 0000 0011 0010 0000 0000 0000
49175 0000 0110 0000 0000 1011 1000
49200 0000 0110 0000 0001 1000 0000
50175 0000 0110 0001 1111 1111 1000
20xx, RTCA, Inc.

653
Step 2: Barometric (Pressure) Altitude Reporting (2.2.8.1.12.a)
16) of ZERO, and verify that the ADS-B Receiver/Report Assembly outputs
Verify that the corresponding Barometric (Pressure) Altitude presence bit (Report
Byte #1, Bit 3), and the Barometric (Pressure) Altitude Validity Flag (Report Byte
#3, Bit 2), are ONEs.
Verify that the reported Binary Decoded Barometric (Pressure) Altitude datum
(Report Bytes # 26 - 28) matches the corresponding value in the table.
Table 2-185: Barometric (Pressure) Altitude Test Data (Q Bit = 0)

Barometric (Pressure) Altitude (Q Bit = 0)
Decimal Altitude Binary Decoded
(feet) Barometric (Pressure) Altitude
-1000 1111 1111 1110 0000 1100 0000
-800 1111 1111 1110 0111 0000 0000
-100 1111 1111 1111 1100 1110 0000
0 0000 0000 0000 0000 0000 0000
100 0000 0000 0000 0011 0010 0000
200 0000 0000 0000 0110 0100 0000
400 0000 0000 0000 1100 1000 0000
800 0000 0000 0001 1001 0000 0000
1600 0000 0000 0011 0010 0000 0000
3200 0000 0000 0110 0100 0000 0000
6400 0000 0000 1100 1000 0000 0000
12800 0000 0001 1001 0000 0000 0000
25600 0000 0011 0010 0000 0000 0000
51200 0000 0110 0100 0000 0000 0000
102400 0000 1100 1000 0000 0000 0000
126700 0000 1111 0111 0111 0110 0000
Step 3: Barometric (Pressure) Altitude Data Not Available (2.2.8.1.12.b)
Keep the Barometric (Pressure) Altitude presence bit at ONE, and set the
Barometric (Pressure) Altitude validity flag to ZERO. Verify that the reported
Binary Decoded Barometric (Pressure) Altitude datum is set to all ZEROs.
2.4.8.1.13 Verification of Vertical Rate, Geometric/Barometric (2.2.8.1.13)

The Vertical Rate field in the State Vector Report contains the altitude rate of an airborne
ADS-B Participant. This is either the rate of change of pressure altitude, or of geometric
20xx, RTCA, Inc.

654
altitude, as specified by the Vertical Rate Type element in the Mode Status Report
(2.2.8.2).
(bits 7 through 4 of byte 0) is set to ONE (binary 0001) to indicate State Vector
Report.
Step 2: Verification of Geometric Source for Vertical Rate
Input an ADS-B Airborne Velocity Message (Subtype 1) where the Vertical Rate
is from a Geometric Source. Verify that the Vertical Rate Source Bit (ME Bit 36)
is set to ZERO (0).
Step 3: Verification of Barometric Source for Vertical Rate
Input an ADS-B Airborne Velocity Message (Subtype 1) where the Vertical Rate
is from a Barometric Source. Verify that the Vertical Rate Source Bit (ME Bit 36)
is set to ONE (1).
Step 4: Verification of Vertical Rate Data Not Available
Keep the Vertical Rate Presence bit at ONE (1), and set the Vertical Rate Validity
Flag to ZERO (0). Verify that the reported Vertical Rate data is set to ALL
ZEROs.
2.4.8.1.14 Verification of Vertical Rate, Geometric (WGS-84) Reporting (2.2.8.1.14)

These test procedures verify the proper reporting of Vertical Rate as specified in
2.2.8.1.14.
Step 1: Vertical Rate, Geometric (WGS-84) Reporting (2.2.8.1.14.a)
(Subtype 1) with the Vertical Rate Source (ME Bit 36) equal ZERO (GNSS
or INS Source), and which include the encoded data (ME Bit 37 for Sign Bit
for Vertical Rate, and Bits 38 - 46 for Vertical Rate) for the Decimal Vertical
Rate values listed, and verify that the ADS-B Receiver/Report Assembly outputs
20xx, RTCA, Inc.

655
Verify that the corresponding Geometric Vertical Rate presence bit (Report Byte
#1, Bit #2), and the Geometric Vertical Rate Validity Flag (Report Byte #3, Bit
#1), are ONEs.
Verify that the reported Binary Decoded Geometric (WGS-84) Vertical Rate
datum (Report Bytes # 24 - 25) matches the corresponding value in the table.
Table 2-186: Geometric (WGS-84) Vertical Rate Test Data

Geometric (WGS-84)
Vertical Rate
Decimal
Binary Decoded
Vertical Rate
Geometric Vertical Rate
(ft./min.)
-32704 1111 1000 0000 0100
-16384 1111 1100 0000 0000
-8192 1111 1110 0000 0000
-4096 1111 1111 0000 0000
-2048 1111 1111 1000 0000
-1024 1111 1111 1100 0000
-512 1111 1111 1110 0000
-256 1111 1111 1111 0000
-128 1111 1111 1111 1000
-64 1111 1111 1111 1100
0 0000 0000 0000 0000
64 0000 0000 0000 0100
128 0000 0000 0000 1000
256 0000 0000 0001 0000
512 0000 0000 0010 0000
1024 0000 0000 0100 0000
2048 0000 0000 1000 0000
4096 0000 0001 0000 0000
8192 0000 0010 0000 0000
16384 0000 0100 0000 0000
32704 0000 0111 1111 1100
Step 2: Vertical Rate, Geometric (WGS-84) Data Not Available (2.2.8.1.14.b)
Keep the Geometric Vertical Rate presence bit at ONE, and set the Geometric
Vertical Rate Validity Flag to ZERO. Verify that the reported Binary Decoded
Geometric (WGS-84) Vertical Rate datum is set to ALL ZEROs.
2.4.8.1.15 Verification of Barometric Altitude Rate Reporting (2.2.8.1.15)

These test procedures verify the proper reporting of Barometric Altitude Rate as specified in
2.2.8.1.15.
20xx, RTCA, Inc.

656
Step 1: Vertical Rate Reporting (2.2.8.1.15.a)
(Subtype 1) with the Vertical Rate Source (ME Bit 36) equal ONE
(Barometric Source), and which include the encoded data (ME Bit 37 for Sign
Bit for Vertical Rate, and Bits 38 - 46 for Vertical Rate) for the Decimal
Vertical Rate values listed, and verify that the ADS-B Receiver/Report Assembly
Verify that the corresponding Vertical Rate presence bit (Report Byte #1, Bit #2),
and the Vertical Rate Validity Flag (Report Byte #3, Bit #0), are ONEs.
Verify that the reported Binary Decoded Vertical Rate datum (Report Bytes # 29 -
30) matches the corresponding value in the table.
Table 2-187: Vertical Rate Test Data

Vertical Rate
Decimal
Binary Decoded
Vertical Rate
Vertical Rate
(ft./min.)
-32704 1111 1000 0000 0100
-16384 1111 1100 0000 0000
-8192 1111 1110 0000 0000
-4096 1111 1111 0000 0000
-2048 1111 1111 1000 0000
-1024 1111 1111 1100 0000
-512 1111 1111 1110 0000
-256 1111 1111 1111 0000
-128 1111 1111 1111 1000
-64 1111 1111 1111 1100
0 0000 0000 0000 0000
64 0000 0000 0000 0100
128 0000 0000 0000 1000
256 0000 0000 0001 0000
512 0000 0000 0010 0000
1024 0000 0000 0100 0000
2048 0000 0000 1000 0000
4096 0000 0001 0000 0000
8192 0000 0010 0000 0000
16384 0000 0100 0000 0000
32704 0000 0111 1111 1100
Step 2: Vertical Rate Data Not Available (2.2.8.1.15.b)
Keep the Vertical Rate presence bit at ONE, and set the Vertical Rate Validity
Flag to ZERO. Verify that the reported Binary Decoded Vertical Rate datum is
set to ALL ZEROs.
20xx, RTCA, Inc.

657
2.4.8.1.16 Verification of the Navigation Integrity Code (NIC) (2.2.8.1.16)

These test procedures verify that the ADS-B Report Assembly Function extracts TYPE
Code data (2.2.3.2.3.1) and the NIC Supplement value (2.2.3.2.3.3) from the ADS-B
Airborne Position Message, or the TYPE Code data (2.2.3.2.4.1) from the ADS-B
Surface Position Message, and the NIC Supplement value (2.2.3.2.7.2.6) from the ADS-B
Aircraft Operational Status Message, and provides Navigation Integrity Category (NIC)
information to the user application in the State Vector Report as specified in Table 2-81.
Definition of the NIC coding is provided in Table 2-70.
Step 1: Verification of (NIC) on Receipt of ADS-B Messages Version Zero (0)
Set up to simulate reception of Version Zero (0) ADS-B Messages by inputting

data directly to the ADS-B Receiving Subsystem. Table 2-188 shows how a
Version One or above ADS-B Receiving Subsystem shall interpret the NUCP
Codes that it receives from a Version Zero ADS-B Transmitting Subsystem.
Using Table 2-188 input the TYPE Code values found in each row of the table and
verify that the corresponding NIC value in that row is reflected in the next output
State Vector Report. Repeat this procedure for each row in the table.
20xx, RTCA, Inc.

658
Table 2-188: Interpretation of NUCP Codes from Version Zero Transmitting Subsystems When
Received by Version One or above ADS-B Receiving Subsystems
Values Sent By Version Zero Values Inferred by Version One or Above
Transmitting Subsystem Receiving Subsystem
Notes
Message NAC NIC SIL
NUCP
TYPE Codes (2.2.3.2.7.2.7) (2.2.3.2.7.2.6) (2.2.3.2.7.2.9)
0 0 0
0 0
(HFOM > 10 NM) (RC > 20 NM) (No Integrity)
11 11 2
5 9
(HFOM < 3 m) (RC < 7.5 m) (5 nines)
10 10 2
6 8
(HFOM < 10 m) (RC < 25 m) (5 nines)
8 8 2
7 7
(HFOM < 0.05 NM) (RC < 0.1 NM) (5 nines)
0 0 0
8 6 [1]
(HFOM > 0.05 NM) (RC > 0.1 NM) (No Integrity)
11 11 2
9 9
(HFOM < 3 m) (RC < 7.5 m) (5 nines)
10 10 2
10 8
(HFOM < 10 m) (RC < 25 m) (5 nines)
8 8 2
11 7
7 7 2
12 6
6 6 2
13 5
5 5 2
14 4
4 4 2
15 3
1 1 2
16 2
(HFOM < 10.0 NM) (RC < 8 NM) (5 nines)
1 1 2
17 1
(HFOM < 10 NM) (RC < 20 NM) (5 nines)
0 0 0
18 0
(HFOM > 10 NM) (RC > 20 NM) (No Integrity)
11
11 2
20 9 (HFOM < 3 m, [2]
(RC < 7.5 m) (5 nines)
VFOM < 4 m)
10
10 2
21 8 (HFOM < 10 m, [2]
(RC < 25 m) (5 nines)
VFOM < 15 m)
0 0
0
22 TBD (HFOM > 10 NM or (RC > 25 m or [2]
(No Integrity)
unknown) unknown)
20xx, RTCA, Inc.

659
Table 2-189 shows how a Version Zero ADS-B Receiving Subsystem would interpret the
NIC Codes that it receives from a Version One or above ADS-B Transmitting Subsystem.
Table 2-189: Interpretation of NIC Codes from Version One or Above

Transmitting Subsystems When Received by Version Zero Receiving Subsystems
TYPE Code in
Message From NIC Value from Version One NUCP Value Assumed by
Version One or Above Transmitting Version Zero Notes
Transmitting Subsystem Receiving Subsystem
Subsystem
0 0
0
(RC unknown or > 20 NM) (HPL > NM or HFOM > 10 NM)
11 9
5
(RC < 7.5 m) (HPL < 7.5 m or HFOM < 3 m)
10 8
6
(RC < 25 m) (HPL < 25 m or HFOM < 10 m)
8 7
7
(RC < 0.1 NM) (HPL < 0.1 NM or HFOM < 0.05 NM)
0 6
8 [1]
(RC > 0.1 NM) (HPL > 0.1 NM or HFOM > 0.05 NM)
11 9
9
(RC < 7.5 m) (HPL < 7.5 m or HFOM < 3 m)
10 8
10
(RC < 25 m) (HPL < 25 m or HFOM < 10 m)
8 7
11
7 6
12
6 5
13 [3]
5 4
14
4 3
15
(RC < 2 NM) (HPL < 2 NM or HFOM < 1.0 NM)
2 2
16
(RC < 8 NM) (HPL < 10 NM or HFOM < 5.0 NM)
1 1
17
(RC < 20 NM) (HPL < 20 NM or HFOM < 10 NM)
0 0
18
(RC > 20 NM) (HPL > 20 NM or HFOM > 10 NM)
11 0
20 [2]
(RC < 7.5 m) (HPL and HFOM are unknown)
10 0
21 [2]
(RC < 25 m) (HPL and HFOM are unknown)
0 0
22 [2]
(RC > 25 m or unknown) (HPL and HFOM are unknown)
20xx, RTCA, Inc.

660
Notes for Table 2-188 and Table 2-189:

1. In Table 2-11 of the initial version (RTCA DO-260) of these MOPS (also see Table 2-16
in this document), a NUCP value of 6 was assigned to Surface Position Messages with a
TYPE Code of 8. This coding is preserved in Table 2-189 because that table shows how
equipment that conforms to the initial RTCA DO-260 MOPS will interpret this message
TYPE Code. However, Table 2-188 specifies that Surface Position Messages with a
TYPE Code of 8 should be interpreted by Version Two (i.e., RTCA DO-260B compliant)
Receiving Subsystems as specifying that NIC, NAC and SIL should all be ZERO (0).
This is because the information in the message is insufficient to indicate the value of
either the RC Integrity Containment Radius, or the HFOM 95% Horizontal Accuracy
Bound.
2. In the initial version of these MOPS (RTCA DO-260), message TYPE Codes of 20
through 22 were determined primarily by the HPL Containment Radius and
secondarily, if the HPL value was unknown, by the 95% Horizontal and Vertical
Accuracy Bounds. However, the initial version of the ADS-B MASPS (RTCA DO-242)
required that NUCP Codes of 8 and 9 should be determined by only the 95% Horizontal
and Vertical Accuracy Bounds. Therefore, a Version Zero 1090 MHz ADS-B Receiving
Subsystem cannot reliably assign a NUCP Code based on Airborne Position Messages
of Message TYPE Codes of 20 through 22 from Version One ADS-B Transmitting
Subsystems. It is for that reason that Table 2-189 specifies that Message TYPE Codes
of 20 through 22 from Version One and Two Transmitting Subsystems should be
interpreted by Version Zero ADS-B Receiving Susbsystems as conveying a NUCP Code
of ZERO (0), meaning that there is No Integrity or unknown integrity.
3. A Version One or Two ADS-B Transmitting Subsystem will set the TYPE Code in the
Airborne Position Message to 13 whenever the HFOM is less than 0.3 NM, but a
Version Zero ADS-B Receiving Susbsystem will assume that TYPE Code of 13 means
that HFOM is less than 0.25 NM, rather than 0.3 NM. It is assumed that there are no
client applications that would demand HFOM = 0.25 NM rather than HFOM = 0.3
NM.
Step 2: Verification of (NIC) on Receipt of ADS-B Messages Version One (1)
Set up to simulate Version One (1) ADS-B Messages by inputting data directly to
the ADS-B Receiving Subsystem being sure to first input an Aircraft Operational
Status Message indicating Version One. Using Table 2-70 input the TYPE Code
and NIC Supplement values found in each row of the table and verify that the
corresponding NIC value is reflected in the next output State Vector Report.
Repeat this procedure for each row in Table 2-70 for both Airborne and Surface
Position Messages.
Step 3: Verification of (NIC) on Receipt of ADS-B Messages Version Two (2)
Set up to simulate Version Two (2) ADS-B Messages by inputting data directly to
the ADS-B Receiving Subsystem being sure to first input an Aircraft Operational
Status Message indicating Version Two. Using Table 2-70 input the TYPE Code
and NIC Supplement values found in each row of the table and verify that the
corresponding NIC value is reflected in the next output State Vector Report.
Repeat this procedure for each row in Table 2-70 for both Airborne and Surface
Position Messages.
20xx, RTCA, Inc.

661
2.4.8.1.17 Verification of Estimated Latitude (WGS-84) Reporting (2.2.8.1.17)

These test procedures verify the proper reporting of Estimated Latitude as specified in
2.2.8.1.17.
Step 1: Estimated Latitude (WGS-84) Updating and Reporting (resulting from received
Airborne or Surface Position Message) (2.2.8.1.17.a(1))
which include the encoded data (ME Bits 23 - 39) for the Decimal Latitude
value listed, and verify that the ADS-B Receiver/Report Assembly outputs State
Verify that the corresponding Estimated Latitude presence bit (Report Byte #1, Bit
0), and the Estimated Latitude Validity Flag (Report Byte #4, Bit 7), are ONEs.
Verify that the reported Binary Decoded Estimated Latitude (WGS-84) (Report
Bytes # 44 - 46) data, match the corresponding value in the table.
20xx, RTCA, Inc.

662
Table 2-190: Estimated Longitude Test Data

Estimated Longitude
Decimal Binary Decoded (WGS-84)
Longitude Estimated Longitude
(degrees) (angular weighted)
0.000000 0000 0000 0000 0000 0000 0000
0.000037 0000 0000 0000 0000 0000 0001
0.000073 0000 0000 0000 0000 0000 0011
0.000147 0000 0000 0000 0000 0000 0110
0.000294 0000 0000 0000 0000 0000 1101
0.000587 0000 0000 0000 0000 0001 1011
0.001175 0000 0000 0000 0000 0011 0110
0.002350 0000 0000 0000 0000 0110 1101
0.004699 0000 0000 0000 0000 1101 1011
0.009398 0000 0000 0000 0001 1011 0110
0.018797 0000 0000 0000 0011 0110 1100
0.037594 0000 0000 0000 0110 1101 1000
0.075188 0000 0000 0000 1101 1011 0000
0.150375 0000 0000 0001 1011 0110 0000
0.300751 0000 0000 0011 0110 1100 0000
0.601501 0000 0000 0110 1101 1000 0000
1.203003 0000 0000 1101 1011 0000 0000
2.406006 0000 0001 1011 0110 0000 0000
4.812012 0000 0011 0110 1100 0000 0000
9.624023 0000 0110 1101 1000 0000 0000
19.248047 0000 1101 1011 0000 0000 0000
38.496094 0001 1011 0110 0000 0000 0000
76.992188 0011 0110 1100 0000 0000 0000
153.984375 0110 1101 1000 0000 0000 0000
-52.031250 1101 1011 0000 0000 0000 0000
-104.062500 1011 0110 0000 0000 0000 0000
151.875000 0110 1100 0000 0000 0000 0000
-56.250000 1101 1000 0000 0000 0000 0000
-112.500000 1011 0000 0000 0000 0000 0000
135.000000 0110 0000 0000 0000 0000 0000
-90.000000 1100 0000 0000 0000 0000 0000
180.000000 1000 0000 0000 0000 0000 0000
Step 2: Estimated Latitude and Estimated Longitude (WGS-84) Updating and Reporting
(resulting from received Airborne or Surface Position Message) (2.2.8.1.18.a(1))
which include the encoded data (ME Bits 23 - 39 for Latitude, and Bits 40 - 56
for Longitude) for the Decimal Latitude and Longitude values listed, and verify
0001.
20xx, RTCA, Inc.

663
Verify that the corresponding Estimated Latitude and Longitude presence bits
(Report Byte #1, Bit #0 for Estimated Latitude, and Byte #2, Bit #7 for Estimated
Longitude), and the Estimated Latitude / Longitude Validity Fag (Report Byte #4,
Bit #7), are ONEs.
Verify that the reported Binary Decoded Estimated Latitude (WGS-84) (Report
Bytes # 44 - 46) data, and the reported Binary Decoded Estimated Longitude
(WGS-84) (Report Bytes # 47 - 49) data, match the corresponding values in the
table.
Table 2-191: Estimated Latitude Test Data

Estimated Latitude
Decimal Binary Decoded (WGS-84)
Latitude Estimated Latitude
(degrees) (angular weighted)
0.000000 0000 0000 0000 0000 0000 0000
0.000037 0000 0000 0000 0000 0000 0001
0.000073 0000 0000 0000 0000 0000 0011
0.000147 0000 0000 0000 0000 0000 0110
0.000294 0000 0000 0000 0000 0000 1101
0.000587 0000 0000 0000 0000 0001 1011
0.001175 0000 0000 0000 0000 0011 0110
0.002350 0000 0000 0000 0000 0110 1101
0.004699 0000 0000 0000 0000 1101 1011
0.009398 0000 0000 0000 0001 1011 0110
0.018797 0000 0000 0000 0011 0110 1100
0.037594 0000 0000 0000 0110 1101 1000
0.075188 0000 0000 0000 1101 1011 0000
0.150375 0000 0000 0001 1011 0110 0000
0.300751 0000 0000 0011 0110 1100 0000
0.601501 0000 0000 0110 1101 1000 0000
1.203003 0000 0000 1101 1011 0000 0000
2.406006 0000 0001 1011 0110 0000 0000
4.812012 0000 0011 0110 1100 0000 0000
9.624023 0000 0110 1101 1000 0000 0000
19.248047 0000 1101 1011 0000 0000 0000
38.496094 0001 1011 0110 0000 0000 0000
76.992188 0011 0110 1100 0000 0000 0000
-52.031250 1101 1011 0000 0000 0000 0000
-56.250000 1101 1000 0000 0000 0000 0000
-90.000000 1100 0000 0000 0000 0000 0000
Step 3: Report Time of Applicability Updating and Reporting (resulting from received
Airborne or Surface Position Message) (2.2.8.1.17.a(2), and 2.2.8.1.18.a(2))
Generate a series of valid Airborne Position Messages, similar to the procedure

described in Step 1 above, which include the encoded data (ME Bits 23 - 39 for
Latitude, and Bits 40 - 56 for Longitude) for any suitable Decimal Latitude and
Longitude values, and verify that the ADS-B Receiver/Report Assembly outputs
20xx, RTCA, Inc.

664
Verify that the corresponding presence bits (Report Byte #1, Bit #0 for Estimated
Latitude, and Byte #2, Bit #7 for Estimated Longitude), and the Estimated
Latitude/Longitude Validity Flag (Report Byte #4, Bit #7), are ONEs.
Verify that the Binary Decoded Report Time of Applicability (Report Bytes # 55 -
56) data changes by an average of 0.5 seconds between each message
transmission.
Step 4: Estimated Latitude and Estimated Longitude (WGS-84) Updating and Reporting
(resulting from received Airborne Velocity Message - Subtype=1) (2.2.8.1.17.b(1
& 2), and 2.2.8.1.18.b(1 & 2))
Generate an Airborne Velocity Message (Subtype 1), which includes the encoded
data (ME Bits 25 - 35) for any suitable N/S Velocity, and which includes the
encoded data (ME Bits 14 - 24) for any suitable E/W Velocity, such that the
resultant is a velocity of 180 knots, and a heading of between 25 to 65 degrees.
Verify that the ADS-B Receiver/Report Assembly outputs a State Vector Report
with the Report Mode set to TWO (binary xxxx 0010). Record the Estimated N/S
Velocity (Report Bytes # 50 - 51) as Vnsest0 (knots), and record the Estimated E/W
Velocity (Report Bytes # 50 - 51) as Vewest0 (knots).
Within 200 milliseconds, generate any valid Airborne Position Message, which
includes the encoded data (ME Bits 23 - 39 for Latitude, and Bits 40 - 56 for
Longitude) for any suitable Decimal Latitude and Longitude values. Verify that
the ADS-B Receiver/Report Assembly outputs a State Vector Report with the
Report Mode set to TWO (binary xxxx 0010). Record the Position Time of
Applicability (Report Bytes # 40 - 41) as t0 (seconds), record the Estimated
Latitude (Report Bytes # 44 - 46) as Latest0 (degrees), and record the Estimated
Longitude (Report Bytes # 47 - 49) as Lonest0 (degrees).
One second after the Airborne Position Message, retransmit the same Airborne
Velocity Message (Subtype 1) as above. Verify that the ADS-B Receiver/Report
Assembly outputs State Vector Report with the Report Mode set to TWO (binary
xxxx 0010). Record the updated Estimated Latitude as Latest1 (degrees). Record
the updated Estimated Longitude as Lonest1 (degrees), and record the updated
Velocity Time of Applicability as t1 (seconds).
Verify that (see Note below):
1852 * Absolute [(Latest1 - Latest0) x 60 - Vnsest0 x (t1 - t0 + trng) / 3600] < 20 meters.
Verify that (see Note below):
1852 * Absolute [(Lonest1 - Lonest0) x 60 - Vewest0 x (t1 - t0 + trng) / 3600] < 20 meters.
Note: If t1 < t0 , then the Receiving Installation Time has exceeded the maximum
time range (see 2.2.8.5) to restart the time count at zero, then the
maximum time range, trng , must be added to (t1 - t0) to make it positive.
Otherwise, consider trng in the equation to be zero.
20xx, RTCA, Inc.

665
Repeat these Step 3 procedures as necessary, using various parameter values, in

order to establish the desired level of confidence.
Step 5: Estimation of Latitude and Longitude when Receiving Air Referenced Velocity
This step verifies that Estimated Latitude and Longitude properly updates on
receipt of ground referenced velocity and does not update on receipt of air
referenced velocity (Airborne Velocity Messages, Subtypes 3 or 4).
Repeat Step 4 above with the additional input of Airborne Velocity Messages
(Subtype 3). Input an Airspeed of 1000 knots at the nominal broadcast rate of 2
messages per second. Verify that the ADS-B Receiving Subsystem and Report
Assembly Function outputs a State Vector Report that meets the 20 meter
position accuracy required in Step 4.
Airborne Velocity Message - Subtype=1) (2.2.8.1.17.b(3), and 2.2.8.1.18.b(3))
Generate a series of valid Airborne Velocity Messages (Subtype 1), similar to the
procedure described in Step 3 above, which include the encoded data (ME Bits
25 - 35 for N/S Velocity, and ME Bits 14 - 24 for E/W Velocity) for any
suitable N/S and E/W Velocity values, and verify that the ADS-B Receiver/Report
Assembly outputs State Vector Reports of Type 0001.
Verify that the corresponding N/S Velocity presence bit (Report Byte #1, Bit 6),
and the Velocity Validity Flag (Report Byte #3, Bit #5), are ONEs.
transmission.
Step 7: Estimated Latitude and Estimated Longitude (WGS-84) Data Not Available
(2.2.8.1.17.c, and 2.2.8.1.18.c)
Keep the Estimated Latitude and Longitude presence bits at ONE, and set the
Estimated Latitude / Longitude Validity Flag to ZERO.
Verify that the reported Binary Decoded Estimated Latitude and Estimated
Longitude data are set to all ZEROs.
2.4.8.1.18 Verification of Estimated Longitude (WGS-84) Reporting (2.2.8.1.18)

Appropriate test procedures are provided in 2.4.8.1.17.
20xx, RTCA, Inc.

666
2.4.8.1.19 Verification of Estimated North/South Velocity Reporting (2.2.8.1.19)

These test procedures verify the proper reporting of Estimated North/South Velocity as
Step 1: Estimated North/South Velocity Updating and Reporting (resulting from received
Airborne Velocity Message) (2.2.8.1.19.a(1))
Generate valid Airborne Velocity Messages (Subtype 1), which include the
encoded data (ME Bits 25 - 35) for any valid Decimal North/South Velocity
values, and verify that the ADS-B Receiver/Report Assembly outputs State Vector
Reports of Type 0001.
Verify that the corresponding Estimated North/South Velocity presence bit

(Report Byte #2, Bit #6), and the Estimated Velocity Validity Flag (Report Byte
Verify that the reported Binary Decoded Estimated North/South Velocity data
(Report Bytes # 50 - 51) match the transmitted North/South Velocity values.
Surface Position Message) (2.2.8.1.19.a(1))
Generate a series of Surface Position Messages (Subtype 1 or 2), which include

encoded data (ME Bits 6 - 12) for valid Ground Speed (Movement) values,
which include a Ground Track Status (ME Bit 13) of ONE, and which include
encoded data (ME Bits 14 - 20) for valid Ground Track headings having a
significant North/South component, and verify that the ADS-B Receiver/Report
Assembly outputs a State Vector Report of Type 0001.
Verify that the North/South Velocity presence bit (Report Byte #1, Bit #6), the
Estimated North/South Velocity presence bit (Report Byte #2, Bit #6), the
Velocity Validity Flag (Report Byte #3, Bit #5), and the Estimated Velocity
Validity Flag (Report Byte #4, Bit #6), are ONEs.
Verify that for each message the N/S Velocity (Report Bytes # 20 - 21) data
matches the Estimated N/S Velocity (Report Bytes # 50 - 51) data.
Airborne Velocity or Surface Position Message) (2.2.8.1.19.a(2))
Generate a series of valid Airborne Velocity Messages (Subtype 1), which include
the encoded data (ME Bits 25 - 35) for any suitable N/S Velocity values, and
verify that the ADS-B Receiver/Report Assembly outputs State Vector Reports of
Type 0001.
20xx, RTCA, Inc.

667
Verify that the corresponding Estimated North/South Velocity presence bit

(Report Byte #2, Bit #6), and the Estimated Velocity Validity Flag (Report Byte
transmission.
Airborne or Surface Position Message) (2.2.8.1.19.b(1 & 2))
Generate any valid Surface Position Message, which includes the encoded data
(ME Bits 6 - 12) for a suitable Decimal Ground Speed (Movement) value,
which includes the encoded data (ME Bits 14 - 20) for a suitable Decimal
Ground Track value, representing a North/South movement and speed of about 25
meters in a three second period, and which includes the encoded data (ME Bits
23 - 39) for any suitable starting Decimal Latitude value. Verify that the ADS-B
Receiver/Report Assembly outputs a State Vector Report of Type 0001. Record
the Position Time of Applicability (Report Bytes # 40 - 41) as tY0 (seconds).
Record the Velocity Time of Applicability (Report Bytes # 42 - 43) as tV0
(seconds). Record the Estimated Latitude (Report Bytes # 44 - 46) as Latest0
(degrees). Record the Estimated N/S Velocity (Report Bytes # 50 - 51) as Vnsest0
(knots), and record the Report Time of Applicability (Report Bytes # 55 - 56) as
tR0 (seconds).
Three seconds after the first Surface Position Message, generate another valid
Surface Position Message, which includes the same encoded data for Decimal
Ground Speed (Movement), the same encoded data for Decimal Ground Track,
and updated encoded data for a Decimal Latitude value commensurate with the
previously recorded Latitude, the N/S Velocity (Vnsest0 ), and the time between
updates of the two Surface Position Messages (tY1 - tY0 ). Verify that the ADS-B
Receiver/Report Assembly outputs State Vector Reports of Type 0001. Record
the Position Time of Applicability as tY1 (seconds). Record the Estimated Latitude
as Latest1 (degrees), and record the Report Time of Applicability as tR1 (seconds).
Verify that tY0 = tV0. = tR0.
Verify that tY1 = tV1. = tR1.
Verify that:
1852 x Absolute [(Latest1 - Latest0) x 60 / (tY1 - tY0 + trng) - Vnsest0 / 3600] < 0.3 meters/second
Note: If tY1 < tY0 , then the Receiving Installation Time has exceeded the
maximum time range (see 2.2.8.5) to restart the time count at zero, then
the maximum time range, trng , must be added to (tY1 - tY0) to make it
positive. Otherwise, consider trng in the equation to be zero.

20xx, RTCA, Inc.

668
Airborne or Surface Position Message) (2.2.8.1.19.b(3))
Generate a series of valid Airborne Position Messages, which include the encoded
data (ME Bits 23 - 39) for any suitable changing Latitude values, and verify that
the ADS-B Receiver/Report Assembly outputs State Vector Reports of Type
0001.
Verify that the corresponding Latitude presence bit (Report Byte #0, Bit #0), and
the Latitude/Longitude Validity Flag (Report Byte #3, Bit #7), are ONEs.
transmission.
Step 6: North/South Velocity Data Not Available (2.2.8.1.19.c)
Generate a series of valid Airborne Velocity Messages, which include the encoded
data (ME Bits 25 - 35) for any suitable N/S Velocity values, force an Estimated
N/S Velocity data not available condition in the ADS-B Receiver, and verify that
the ADS-B Receiver/Report Assembly outputs State Vector Reports of Type
0001.
Verify that the N/S Velocity presence bit (Report Byte #1, Bit #6), and the
Estimated N/S Velocity presence bit (Report Byte #2, Bit #6), are ONEs, and
that the reported Estimated Velocity Validity Flag (Report Byte #4, Bit 6) is a
ZERO.
Verify that the reported Binary Decoded Estimated N/S Velocity data (Report
Bytes # 50 - 51) is set to all ZEROs.
2.4.8.1.20 Verification of Estimated East/West Velocity Reporting (2.2.8.1.20)

These test procedures verify the proper reporting of Estimated East/West Velocity as
Step 1: Estimated East/West Velocity Updating and Reporting (resulting from received
Airborne Velocity Message) (2.2.8.1.20.a(1))
Generate valid Airborne Velocity Messages (Subtype 1), which include the
encoded data (ME Bits 14 - 24) for any valid Decimal East/West Velocity
values, and verify that the ADS-B Receiver/Report Assembly outputs State Vector
20xx, RTCA, Inc.

669
Verify that the corresponding Estimated East/West Velocity presence bit (Report
Byte #2, Bit #5), and the Estimated Velocity Validity Flag (Report Byte #4, Bit
#7), are ONEs.
Verify that the reported Binary Decoded Estimated East/West Velocity data
(Report Bytes # 52 - 53) match the transmitted East/West Velocity values.
Surface Position Message) (2.2.8.1.20.a(1))
Generate a series of Surface Position Messages (Subtype 1 or 2), which include

encoded data (ME Bits 6 - 12) for valid Ground Speed (Movement) values,
which include a Ground Track Status (ME Bit 13) of ONE, and which include
encoded data (ME Bits 14 - 20) for valid Ground Track headings having a
significant East/West component, and verify that the ADS-B Receiver/Report
Assembly outputs a State Vector Report of Type 0001.
Verify that the East/West Velocity presence bit (Report Byte #1, Bit #6), the
Estimated East/West Velocity presence bit (Report Byte #2, Bit #5), the Velocity
Validity Flag (Report Byte #3, Bit #5), and the Estimated Velocity Validity Flag
(Report Byte #4, Bit #7), are ONEs.
Verify that for each message the E/W Velocity (Report Bytes # 22 - 23) data
matches the Estimated E/W Velocity (Report Bytes # 52 - 53) data.
Airborne Velocity Message or Surface Position Message) (2.2.8.1.20.a(2))
Generate a series of valid Airborne Velocity Messages (Subtype 1), which include
the encoded data (ME Bits 14 - 24) for any suitable E/W Velocity values, and
verify that the ADS-B Receiver/Report Assembly outputs State Vector Reports of
Type 0001.
Verify that the corresponding Estimated East/West Velocity presence bit (Report
Byte #2, Bit #5), and the Estimated Velocity Validity Flag (Report Byte #4, Bit 7),
are ONEs.
transmission.
Airborne or Surface Position Message) (2.2.8.1.20.b(1 & 2))
Generate any valid Surface Position Message, which includes the encoded data
(ME Bits 6 - 12) for a suitable Decimal Ground Speed (Movement) value, and
the encoded data (ME Bits 14 - 20) for a suitable Decimal Ground Track value,
representing a East/West movement and speed of about 25 meters in a three
second period, and which includes the encoded data (ME Bits 40 - 56) for any
suitable starting Decimal Latitude (Lat) and Longitude values. Verify that the
ADS-B Receiver/Report Assembly outputs a State Vector Report of Type 0001.
20xx, RTCA, Inc.

670
Record the Position Time of Applicability (Report Bytes # 40 - 41) as tX0

(seconds). Record the Velocity Time of Applicability (Report Bytes # 42 - 43) as
tV0 (seconds). Record the Estimated Longitude (Report Bytes # 44 - 46) as Lonest0
(degrees). Record the Estimated E/W Velocity (Report Bytes # 52 - 53) as Vewest0
(knots), and record the Report Time of Applicability (Report Bytes # 55 - 56) as
tR0 (seconds).
Three seconds after the first Surface Position Message, generate another valid
Surface Position Message, which includes the same encoded data for Decimal
Ground Speed (Movement), the same encoded data for Decimal Ground Track,
and updated encoded data for a Decimal Longitude value commensurate with the
previously recorded Longitude, the E/W Velocity (Vewest0 ), and the time between
updates of the two Surface Position Messages (tX1 - tX0 ). Verify that the ADS-B
Receiver/Report Assembly outputs State Vector Report of Type 0001. Record the
Position Time of Applicability as tX1 (seconds). Record the Estimated Longitude
as Lonest1 (degrees), and record the Report Time of Applicability as tR1 (seconds).
Verify that tX0 = tV0. = tR0.
Verify that tX1 = tV1. = tR1.
Verify that:
1852 x Absolute [(Lonest1 - Lonest0) x 60 / (tX1 - tX0 + trng) - Vewest0 / 3600] cos(Lat)
< 0.3 meters/second.
Note: If tX1 < tX0 , then the Receiving Installation Time has exceeded the
maximum time range (see 2.2.8.5) to restart the time count at zero, then
the maximum time range, trng , must be added to (tX1 - tX0) to make it
positive. Otherwise, consider trng in the equation to be zero.

Airborne or Surface Position Message) (2.2.8.1.20.b(3))
Generate a series of valid Airborne Position Messages, which include the encoded
data (ME Bits 40 - 56) for any suitable changing Longitude values, and verify
0001.
Verify that the corresponding Longitude presence bit (Report Byte #0, Bit #0),
and the Latitude/Longitude Validity Flag (Report Byte #3, Bit 7), are ONEs.
transmission.
20xx, RTCA, Inc.

671
Step 6: East/West Velocity Data Not Available (2.2.8.1.20.c)
Generate a series of valid Airborne Velocity Messages, which include the encoded
data (ME Bits 14 - 24) for any suitable E/W Velocity values, force an
Estimated E/W Velocity data not available condition in the ADS-B Receiver,
and verify that the ADS-B Receiver/Report Assembly outputs State Vector
Verify that the E/W Velocity presence bit (Report Byte #1, Bit #6), and the
Estimated E/W Velocity presence bit (Report Byte #2, Bit #5), are ONEs, and
set the reported Estimated Velocity Validity Flag (Report Byte #4, Bit 7) is a
ZERO.
Verify that the reported Binary Decoded Estimated E/W Velocity data (Report
Bytes # 52 - 53) is set to all ZEROs.
2.4.8.1.21 Verification of Surveillance Status / Discretes Reporting (2.2.8.1.21)

These test procedures verify the proper reporting of Surveillance Status / Discretes as
Step 1: Surveillance Status Updating and Reporting (resulting from received Airborne
Position Message) (2.2.8.1.21.a)
which includes encoded data (ME Bits 6 - 7) for the Surveillance Status Test
Condition listed, and verify that the ADS-B Receiver/Report Assembly outputs
Verify that the corresponding Surveillance Status / Discretes presence bit (Report
Byte #3, Bit 3) is a ONE.
Verify that the reported Binary Decoded Surveillance Status / Discretes data
(Report Byte # 54, Bits 5 & 4) match the corresponding bit values indicated in the
table.
Table 2-192: Surveillance Status Test Conditions

Surveillance Status / Discretes
Binary Decoded Surveillance
Surveillance Status Test Conditions
Status / Discretes
No Condition Information Axx00 xxxxA
Permanent Alert Condition (Emergency) Axx01 xxxxA
Temporary Alert Condition (change in Mode-A
Axx10 xxxxA
Identity Code other than emergency condition)
Special Position Identification (SPI) Condition Axx11 xxxxA
20xx, RTCA, Inc.

672
Step 2: Surveillance Status Data Not Available (resulting from received Airborne Position
Message) (2.2.8.1.21.b)
Generate a series of valid Airborne Position Messages, force a Surveillance

Status data not available condition in the ADS-B Receiver, and verify that the
Verify that the reported Binary Surveillance Status / Discretes data (Report Byte #
54, Bits 5 & 4) is set to all ZEROs.
Step 3: Intent Change Flag Updating and Reporting (resulting from received Airborne
Velocity Message) (2.2.8.1.21.c)
(Subtype 1), which includes encoded data (ME Bit 9) for the Intent Change Flag
Test Condition listed, and verify that the ADS-B Receiver/Report Assembly
Verify that the reported Binary Decoded Surveillance Status / Discretes data
(Report Byte # 54, Bit 1) matches the corresponding bit value indicated in the
table.
Table 2-193: Intent Change Flag Test Conditions

Surveillance Status / Discretes
Intent Change Flag Binary Decoded Surveillance
Test Conditions Status / Discretes
No Change in Intent Axxxx xx0xA
Intent Change Axxxx xx1xA
Step 4: Surveillance Status / Discrete Bit b0 (2.2.8.1.21.d)
Verify that the reported Binary Decoded Surveillance Status / Discretes datum
(Report Byte # 54, Bit 0) is set to ZERO (0).
20xx, RTCA, Inc.

673
2.4.8.1.22 Verification of Report Mode Reporting (2.2.8.1.22)

The Report Mode is used to indicate the current state of the Report for each ADS-B vehicle
being reported. Each time that the State Vector Report is updated, the Report Mode is
updated with the encoding being as shown in Table 2-195:
Table 2-195: Report Mode Encoding

Coding Report Mode
xxxx 0000 No Report Generation Capability
xxxx 0001 Acquisition Mode (see 2.2.10.2)
xxxx 0010 Track Mode (see 2.2.10.3)
xxxx 0011
through Reserved for Future Expansion
xxxx 1111
Note: x in the table above, denotes DONT CARE.
Step 1: Acquisition Mode Reporting (2.2.8.1.22, 2.2.10.2)
Generate two valid Airborne Position Messages within 10 seconds, one even
and one odd.
Verify that the reported Binary Report Mode field (Report Byte #57) is set to
xxxx 0001.
Step 2: Track State Initialization Mode Reporting (2.2.8.1.22, 2.2.10.3)
Generate one valid Airborne Velocity Message (Subtype 1) within 10 seconds

following the last Airborne Position Message provided in Step 1. Verify that the
reported Binary Report Mode field is set to xxxx 0010.
2.4.8.2 Verification of the ADS-B Mode Status Report (2.2.8.2)

2.4.8.2.1 Verification of the Mode Status Report Type and Structure Identification and Validity
Flags (2.2.8.2.1)
Appropriate test procedures are provided in 2.4.8.2.1.1 and 2.4.8.2.1.2.
20xx, RTCA, Inc.

674
2.4.8.2.1.1 Verification of Mode Status Report Type and Structure Identification (2.2.8.2.1.1)
The Report Type requirements are provided in 2.2.8.1.1. The Report Structure field is
used to indicate the exact data parameters identified in Table 2-88 that are being provided in
the Mode Status report and is intended to provide a methodology for implementers to
structure concatenated reports when data for some parameters is not available. These test
procedures verify the correct encoding of the Report Structure (Mode Status Report bits 5
through 24).
Equipment:
Provide a method of supplying the ADS-B Receiving Subsystem with valid ADS-B
Messages.
Step 1: Incapability of Concatenation:
If the Report Assembly Function is implemented such that the Mode Status Report
may be shortened when certain data is not available, skip to Step 2.
If the Report Assembly Function is implemented such that the Mode Status Report
is 36 bytes long regardless of data availability across fields, consecutively provide
the ADS-B Receiving Subsystem with valid ADS-B Messages, varying message
types appropriately to prompt output of Mode Status Reports. Ensure that in each
valid ADS-B Message provided to the ADS-B Receiving Subsystem, that the
AA field (Message Bits 9 through 32) is set to hexadecimal A60DBE. Verify
that in every Mode Status Report provided to the application, bytes 4 through 6
are hexadecimal A60DBE. Verify that the 24-bit Report Structure field is set to
ALL ONEs in every Mode Status Report provided to the application. Verify that
the Mode Status Report is 36 bytes long. This test procedure is now completed.
Step 2: Capability of Concatenation
Appropriate test procedures to validate this capability are provided in 2.4.8.2.4

through 2.4.8.2.18.
2.4.8.2.1.2 Verification of the Mode Status Report Validity Flags (2.2.8.2.1.2)

2.4.8.2.4 through 2.4.8.2.18.

Appropriate test procedures required to validate the Participant Address (2.2.3.2.1.5) are
included in the verification of the PI field in 2.4.3.2.1.7.
20xx, RTCA, Inc.

675
2.4.8.2.3 Verification of the Address Qualifier (2.2.8.2.3)

Appropriate test procedures required to validate the requiremenets of 2.2.8.2.3 are included
in 2.4.8.1.3.
2.4.8.2.4 Verification of the Mode Status Report Report Time of Applicability (2.2.8.2.4)
These test procedures verify that each time that an Individual Mode Status Report is
updated, the Report Assembly Function updates the Report Time of Applicability data in the
Mode Status Report with either the GPS / GNSS UTC Measure Time data (see 2.2.8.5.1)
or the Established Receiver Unit Time (see 2.2.8.5.2), whichever is applicable to the
Equipment:
The test equipment for this procedure depends on whether the ADS-B receiver under test is
meant for Precision Installations or Non-Precision Installations (see 2.2.8.5). For Precision
systems, the equipment will need to have the ability to provide GPS/GNSS UTC Measure
Time Data via the appropriate interface. For Non-Precision systems, the equipment will
include a clock that is appropriately synchronized with the internal clock of the ADS-B
Receiving Subsystem. In both cases, the equipment shall have the capability to mark the
time when a Mode Status Report is provided to the output buffer.
A method of providing valid ADS-B Messages that are used for constructing Mode Status
Reports. Also, provide a method of providing valid Position and Velocity Messages to the
ADS-B Receiving Subsystem. In all messages provided to the ADS-B receiver, regardless
of type, the AA field (Message bits 9 through 32) will be set to the same discrete address.
The requirement that the AA fields be identical is to ensure that the outputted Mode
Status Reports are related solely to this test procedure.
(see 2.2.10.4) and is outputting Mode Status Reports to the Report Buffer.
Step 2: Verification of Report Time of Applicability
Provide any of the set of valid ADS-B Messages that are used in producing Mode
Status Reports. After one second, provide a valid ADS-B Velocity Message to the
ADS-B Receiving Subsystem such that the ADS-B Report Assembly Function is
prompted to output a Mode Status Report to the Report Buffer.
Mark the timevia GPS/GNSS UTC for Precision Installations, or the test clock
for Non-Precision Installations. Retrieve the resulting Mode Status Report from
the Report Buffer. Calculate the time represented in the Report Time of
20xx, RTCA, Inc.

676
Applicability (Report bytes 37 through 38 in the full Mode Status Report) and
verify that this time is within 5ms of the previously marked time.
Repeat the process continuously for at least 550 seconds.
2.4.8.2.5 Verification of the Mode Status Report - Version Number (2.2.8.2.5)

The ADS-B Report Assembly Function must provide Version Number (see
2.2.3.2.7.2.5) data, as received in the Aircraft Operational Status Messages (see
2.2.3.2.7.2), when available, in the Mode Status Report. Otherwise, the Version Number
must be assumed to be ZERO.
Be able to provide valid ADS-B Aircraft Operational Status Messages to the ADS-
B Receiving Subsystem, from ADS-B Transmitting Subsystems conforming to
RTCA DO-260, RTCA DO-260A, and RTCA DO-260B such that the ADS-B
Report Assembly Function enters the Track State (see 2.2.10.4) and is outputting
Mode Status Reports to the Report Buffer.
Step 2: Verification of Version Number when Data is Not Available
Verify that the ADS-B Aircraft Operational Status Messages are being transmitted
from a system conforming to RTCA DO-260. Receive the resulting Mode Status
Report from the Report Buffer. Verify that the Version Number field (Report
Byte 39 in the full Mode Status Report) is set to ALL ZEROs (binary 000).
Step 3: Verification of Version Number
Provide a valid ADS-B Aircraft Operational Status Message to the ADS-B

Receiving Subsystem with the Version Number set as specified in Table 2-69,
from an ADS-B Transmitting Subsystem conformant to RTCA DO-260B.
Retrieve the resulting Mode Status Report from the Report Buffer. Verify that the
Version Number presence bit (Report Byte 2, bit 4) is set to ONE. Verify that the
Version Number field (Report Byte 39 in the full Mode Status Report) is set to
TWO (binary 010).
2.4.8.2.6 Verification of the Mode Status Report - Call Sign (2.2.8.2.6)

The ADS-B Report Assembly Function must extract the Aircraft Identification Character
subfields from the ADS-B Flight Identification and Category Message (2.2.3.2.5.3) for
further processing. Each character is encoded in a subset of International Alphabet No. 5
(IA-5) and formatted for the Mode Status Report in binary format specified in Table 2-88.
20xx, RTCA, Inc.

677
Equipment:
Provide a method of supplying Aircraft Identification Messages to the ADS-B Receiving

Subsystem with the Identification Character subfields (Message bits 41 through 88) set as
specified in Table 2-196. Also, provide a method of supplying Position and Velocity
Messages to the ADS-B Receiving Subsystem. In all messages provided to the ADS-B
receiver, regardless of type, the AA field (Message bits 9 through 32) will be set to the
same discrete address. The requirement that the AA fields be identical is to ensure that
the outputted Mode Status Reports are related solely to this test procedure.
Table 2-196: Mode Status Report Call Sign Encoding

Received
Identification Report Encoding
Character
001100 01001100
011010 01011010
010110 01010110
010101 01010101
100000 00100000
110110 00110110
111001 00111001
111100 00111100
110111 00110111
110011 00110011
110101 00110101
000101 01000101
001011 01001011
000011 01000011
000001 01000001
001111 01001111
010001 00010001
011001 00011001
Step 2: Verification of Call Sign Encoding when Data is Not Available
Retrieve the resulting Mode Status Report from the Report Buffer. If the Call
Sign presence bit (Report Byte 0, bit 3) is set to ONE, verify that the Call Sign
field (Report Bytes 7 through 14 in the full Mode Status Report) is set to ALL
ZEROs.
20xx, RTCA, Inc.

678
Step 3: Verification of Participant Category Encoding
For each case in Table 2-196 above, provide a valid Aircraft Identification
Message to the ADS-B Receiving Subsystem with each Identification Character
subfield numbers 1 through 8 (Message bits 41 through 88) set to the same 6-bit
encoding as specified in each entry of Table 2-196.
corresponding presence bit (Report Byte 0, bit 3) is set to ONE. Verify that each
byte of the Call Sign field (Report Bytes 6 through 13 in the full Mode Status
Report) is set to the correct value from the Report Encoding field of Table 2-
196.
2.4.8.2.7 Verification of the Mode Status Report - Emitter Category (2.2.8.2.7)

The ADS-B Report Assembly Function must correctly determine the Emitter Category
Encoding (Mode Status Report byte #19) from both TYPE and ADS-B Emitter
Category information from the Aircraft Identification and Category Message (2.2.3.2.5).
Equipment:
A method of providing Aircraft Identification and Category Messages to the ADS-B

Receiving Subsystem with TYPE (Message bits 33 through 37) and ADS-B Emitter
Category (Message bits 38 through 40) fields set as specified in Table 2-197. Also,
provide a method of providing Position and Velocity Messages to the ADS-B Receiving
Subsystem. In all messages provided to the ADS-B Receiving Subsystem, regardless of
type, the AA field (Message bits 9 through 32) will be set to the same discrete address.
The requirement that the AA fields be identical is to ensure that the outputted Mode
20xx, RTCA, Inc.

679
Table 2-197: Mode Status Report Emitter Category Meaning

ADS-B
TYPE Emitter Encoding
Category
4 0 0
4 1 1
4 2 3
4 3 5
4 4 6
4 5 7
4 6 8
4 7 10
3 0 0
3 1 11
3 2 12
3 3 16
3 4 15
3 6 13
3 7 14
2 0 0
2 1 20
2 2 21
2 3 22
1 0 0
Step 2: Verification of Emitter Category Encoding when Data is Not Available
Retrieve the resulting Mode Status Report from the Report Buffer. If the Emitter
Category presence bit (Report Byte 0, bit 0) is set to ONE, verify that the Emitter
Category field (Report Byte 19 in the Mode Status Report) is set to ALL ZEROs.
Step 3: Verification of Emitter Category Encoding
For each case in Table 2-197 above, provide a valid Aircraft Identification and
Category Message to the ADS-B Receiving Subsystem with TYPE (Message
bits 33 through 37) and ADS-B Emitter Category (Message bits 38 through 40)
fields set as specified in Table 2-197.
Retrieve the resulting Mode Status Report from the Report Buffer. When the
Encoding field of Table 2-197 is not ZERO (0), verify that the corresponding
presence bit (Report Byte 0, bit 0) is set to ONE. If the Emitter Category presence
bit (Report Byte 0, bit 0) is set to ONE, verify that the Emitter Category field
20xx, RTCA, Inc.

680
(Report Byte 19 in the Mode Status Report) is set to the correct value from the
Encoding field of Table 2-197.
2.4.8.2.8 Verification of the A/V Length and Width Code (2.2.8.2.8)

These test procedures verify that the ADS-B Report Assembly Function properly extracts
the Aircraft/Vehicle (A/V) Length and Width Code from the Aircraft Operational Status
Message (2.2.3.2.7.2) when the A/V is on the airport surface. The A/V Length and Width
Code is specified in Table 2-74, and is inserted into the Mode Status Report as specified in
Table 2-88.
Provide valid ADS-B Position and Velocity Messages, Version Zero (0) for Step
2, Version One (1) for Step 3 and Version Two (2) for step 4 to the ADS-B
Receiving Subsystem such that the ADS-B Report Assembly Function enters the
Track State and is outputting Reports to the Report Buffer. Verify that the Report
Type Code (bits 7 through 4 of byte 0) is set to TWO (binary 0010) to indicate
Mode Status Report.
Step 2: Verification of A/V Length & Width Code Data Not Available Version Zero (0)
Provide valid Version Zero (0) ADS-B Aircraft Operational Status Messages to
the ADS-B Receiving Subsystem. Verify that bit 7 of byte 1 of the output Mode
Status Report to the report buffer is set to ZERO (0).
Step 3: Verification of A/V Length & Width Code Version One (1)
Provide valid Version One (1) ADS-B Aircraft Operational Status Messages to the
ADS-B Receiving Subsystem such that the aircraft is in the On-Ground condition.
Verify that for each input A/V Length & Width value from Table 2-74, that this
value is reflected in the output Mode Status Report to the report buffer.
Step 4: Verification of A/V Length & Width Code Version Two (2)
Provide valid Version Two (2) ADS-B Aircraft Operational Status Messages to
the ADS-B Receiving Subsystem such that the aircraft is in the On-Ground
condition. Verify that for each input A/V Length & Width value from Table 2-74,
that this value is reflected in the output Mode Status Report to the report buffer.
20xx, RTCA, Inc.

681
2.4.8.2.9 Verification of the Mode Status Report - Emergency / Priority Status (2.2.8.2.9)
the 3-bit Emergency / Priority Status data from the Extended Squitter Aircraft Status
Message (2.2.3.2.7.8) (TYPE=28, Subtype=1), and provides the Emergency / Priority
Status information to the user application in the Mode Status Report in the binary format
specified in Table 2-88 as specified in 2.2.8.2.9.
Equipment:
A method of providing Aircraft Status Messages with any and all possible bit-sets of
Message Bits 9 through 11 to the ADS-B Receiving Subsystem. Also, provide a method of
providing Position and Velocity Messages to the ADS-B Receiving Subsystem. In all
messages provided to the ADS-B receiver, regardless of type, the AA field (Message bits
9 through 32) will be set to the same discrete address. The requirement that the AA fields
be identical is to ensure that the outputted Mode Status Reports are related solely to this test
procedure.
Step 2: Emergency / Priority Status - Not Available
Retrieve the resulting Mode Status Report from the Report Buffer. If the
Emergency / Priority Status presence bit (Byte 1, bit 6) is set to ONE, verify that
the three low order bits of the Emergency / Priority Status field (Report Byte 21
in the Mode Status Report) are set to ALL ZEROs.
Step 3: Verification of Emergency / Priority Status Encoding
Provide a valid ADS-B Extended Squitter Aircraft Status Message with Message
bits 9 through 11 set to 0 (binary 000). After one second, provide a valid ADS-B
Velocity Message such that a Mode Status Report is output to the Report Buffer.
Emergency / Priority Status presence bit (Byte 1, bit 6) is set to ONE (1). Verify
that the Emergency / Priority Status field (Report Byte 21 in the Mode Status
Report), bits 0, 1 and 2 are set identically to the provided Extended Squitter
Aircraft Status Message bits 9, 10 and 11 respectively. Terminate the input for the
Extended Squitter Aircraft Status Message and verify that the Mode Status Report
continues to contain the last reported state of the Emergency/Priority Status for
100 seconds. After a period of 100 seconds, verify that the Emergency/Priority
Status data field in the Mode Status Report contains ALL ZEROs, and that the
20xx, RTCA, Inc.

682
Emergency/Priority Status Validity Flag has been set in Byte 3, bit 2 (see Table 2-
90) of the Mode Status Report to indicate that the data is not valid.
Step 4: Repeat
Repeat Step 3 above, setting the provided Extended Squitter Aircraft Status
Message bits 9 through 11 to 1, 2, 3, 4 and 5 (binary 001, 010, 011, etc.). For
each input, terminate the input for the Extended Squitter Aircraft Status Message
and verify that the Mode Status Report continues to contain the last reported state
of the Emergency/Priority Status for 100 seconds. After a period of 100 seconds,
verify that the Emergency/Priority Status data field in the Mode Status Report
contains ALL ZEROs, and that the Emergency/Priority Status Validity Flag has
been set in Byte 3, bit 2 (see Table 2-90) of the Mode Status Report to indicate
that the data is not valid.
2.4.8.2.10 Verfication of the Mode Status Report - Capability Class Codes (2.2.8.2.10)
the Capability Class Codes data from the Aircraft Operational Status Message
(2.2.3.2.7.2) and provides the Capability Class Codes to the user application in the Mode
Status Report in the binary format specified in Table 2-88 as specified in 2.2.8.2.10.
(bits 7 through 4 of byte 0) is set to TWO (binary 0010) to indicate Mode Status
Report.
Step 2: Verification of Mapping of CC Codes to the Mode Status Report Version Zero
(0)
Provide valid Version Zero (0) Aircraft Operational Status Messages to the ADS-
B Receiving Subsystem. Verify that bits 9-12 of the input Capability Class
Codes data from these messages is mapped as per Table N-6 with the remaining
bits in the three byte long Capability Class Codes field of the ADS-B Mode Status
Report being set to ALL ZEROs.
Step 3: Verification of CC Codes Data Not Available Version Zero (0)
Provide valid Version Zero (0) ADS-B Messages but no Aircraft Operational
Status Messages to the ADS-B Receiving Subsystem. Verify that the Capability
Class Codes Mode Status Data Parameter bit, bit 5 of byte 1 in the next output
Mode Status Report, is set to ZERO (0).
20xx, RTCA, Inc.

683
Step 4: Verification of Mapping of CC Codes to the Mode Status Report Version One
(1)
ADS-B Receiving Subsystem. Verify that the input Capability Class Codes data
from these messages is mapped bit for bit into the three byte long Capability Class
Codes field of the ADS-B Mode Status Report as specified in Table 2-92.
Step 5: Verification of CC Codes Data Not Available Version One (1)
ADS-B Receiving Subsystem without the CC Codes data included in the
messages. Verify that the Capability Class Codes field of the ADS-B Mode Status
Report is set to ALL ZEROs.
Step 6: Verification of Mapping of CC Codes to the Mode Status Report Version Two
(2)
the ADS-B Receiving Subsystem. Verify that the input Capability Class Codes
data from these messages is mapped bit for bit into the three byte long Capability
Class Codes field of the ADS-B Mode Status Report as specified in Table 2-92.
Step 7: Verification of CC Codes Data Not Available Version Two (2)
the ADS-B Receiving Subsystem without the CC Codes data included in the
messages. Verify that the Capability Class Codes field of the ADS-B Mode Status
Report is set to ALL ZEROs.
2.4.8.2.11 Verification of the Mode Status Report - Operational Mode Data (2.2.8.2.11)
the Operational Mode data, ME bits 25 through 40, (see Table 2-68 and 2.2.3.2.7.2.4)
from the Aircraft Operational Status Message (2.2.3.2.7.2) and maps it bit for bit into the
2-byte long (Report bytes 25 through 26) Operational Mode field of the ADS-B Mode
Status Report in the binary format specified in Table 2-88.
Report.
20xx, RTCA, Inc.

684
Step 2: Verification OM Data Omission Version Zero (0)
the ADS-B Receiving Subsystem. Verify that the Operational Mode Data
Parameter bit, bit 4 of byte 1 in the next output Mode Status Report, is set to
ZERO (0).
Step 3: Verification of Mapping OM Data to the MS Report Version One (1)
ADS-B Receiving Subsystem. Verify that the input Operational Mode data
from these messages is mapped bit for bit into the two byte long Operational
Mode field of the ADS-B Mode Status Report as specified in Table 2-88.
Step 4: Verification of OM Codes Data Not Available Version One (1)
ADS-B Receiving Subsystem without the OM data included in the messages.
Verify that the Operational Mode field of the ADS-B Mode Status Report is set to
ALL ZEROs.
Step 5: Verification of Mapping OM Data to the MS Report Version Two (2)
the ADS-B Receiving Subsystem. Verify that the input Operational Mode data
from these messages is mapped bit for bit into the two byte long Operational
Mode field of the ADS-B Mode Status Report as specified in Table 2-88.
Step 6: Verification of OM Codes Data Not Available Version Two (2)
the ADS-B Receiving Subsystem without the OM data included in the messages.
Verify that the Operational Mode field of the ADS-B Mode Status Report is set to
ALL ZEROs.
2.4.8.2.12 Verification of the Mode Status Report - SV Quality NACP (2.2.8.2.12)

the NACP data from the Aircraft Operational Status Message (2.2.3.2.7.2) and from the
Target State and Status Message (2.2.3.2.7.1.3.8) and maps the NACP value bit for bit from
the most recently received ADS-B Message to the Mode Status Report in the binary format
20xx, RTCA, Inc.

685
Report.
Step 2: Verification of Mapping NACP Data to the (MS) Report Version Zero (0)
Provide valid ADS-B Messages with TYPE Codes equal to each of those specified
in Table 2-188, in Version Zero format. Verify that the corresponding NACP
value, as per Table 2-188, is mapped from the most recently received Version
Zero ADS-B Message into the Mode Status Report as specified in Table 2-88.
Step 3: Verification of Data Not Available Version Zero (0)
the ADS-B Receiving Subsystem with valid TYPE Codes included in the
messages. Allow 24 seconds to pass without an update and verify that the NAC P
field of the ADS-B Mode Status Report is set to ALL ZEROs and that bit 5 of
byte 3 is also set to ZERO (0).
Step 4: Verification of Mapping NACP Data to the (MS) Report Version One (1)
Provide valid ADS-B Aircraft Operational Status and Target State and Status
Messages to the ADS-B Receiving Subsystem in Version One (1) format. Verify
that the input NACP data from these messages is mapped bit for bit from the most
recently received ADS-B Message to the Mode Status Report as specified in Table
2-88.
Step 5: Verification of Data Not Available Version One (1)
ADS-B Receiving Subsystem with valid TYPE Codes included in the messages.
Allow 24 seconds to pass without an update and verify that the NACP field of the
ADS-B Mode Status Report is set to ALL ZEROs and that bit 5 of byte 3 is also
set to ZERO (0).
Step 6: Verification of Mapping NACP Data to the (MS) Report Version Two (2)
Messages to the ADS-B Receiving Subsystem in Version Two (2) format. Verify
that the input NACP data from these messages is mapped bit for bit from the most
2-88.
20xx, RTCA, Inc.

686
Step 7: Verification of Data Not Available Version Two (2)
messages. Allow 24 seconds to pass without an update and verify that the NACP
2.4.8.2.13 Verification of the Mode Status Report - SV Quality NACV (2.2.8.2.13)

the NACV data from the ADS-B Airborne Velocity Message (2.2.3.2.6) and maps the
NACV value bit for bit from the received ADS-B Message to the Mode Status Report in the
binary format specified in Table 2-88.
Report.
Step 2: Verification of Mapping NACV Data to the (MS) Report Version Zero (0)
Provide valid ADS-B Airborne Velocity Messages to the ADS-B Receiving

Subsystem in Version Zero (0) format. Verify that the input NUCR data from
these messages is mapped as NACV bit for bit from the most recently received
ADS-B Message to the Mode Status Report as specified in Table 2-88.
messages. Allow 24 seconds to pass without an update and verify that the NUC R
Step 4: Verification of Mapping NACV Data to the (MS) Report Version One (1)

Subsystem in Version One (1) format. Verify that the input NACV data from these
messages is mapped bit for bit from the most recently received ADS-B Message to
the Mode Status Report as specified in Table 2-88.
20xx, RTCA, Inc.

687
Allow 24 seconds to pass without an update and verify that the NACV field of the
set to ZERO (0).
Step 6: Verification of Mapping NACV Data to the (MS) Report Version Two (2)

Subsystem in Version Two (2) format. Verify that the input NACV data from
these messages is mapped bit for bit from the most recently received ADS-B
Message to the Mode Status Report as specified in Table 2-88.
messages. Allow 24 seconds to pass without an update and verify that the NACV
2.4.8.2.14 Verification of the Mode Status Report - SV Quality SIL (2.2.8.2.14)

the SIL, SILSUPP and System Design Assurance (SDA) data from the Aircraft Operational
Status Message (2.2.3.2.7.2.9) and/or from the Target State and Status Message
(2.2.3.2.7.1.3.10), and maps the SIL, SILSUPP and System Design Assurance (SDA) values
bit for bit from the most recently received ADS-B Message to the Mode Status Report in the
binary format specified in Table 2-88.
Report.
Step 2: Verification of Mapping SIL Data to the (MS) Report Version Zero (0)
Provide valid ADS-B Messages to the ADS-B Receiving Subsystem in Version

Zero format with TYPE Codes equal to each of those specified in Table 2-188.
Verify that the corresponding SIL value, as per Table 2-188, is mapped bit for bit
20xx, RTCA, Inc.

688
from the most recently received ADS-B Message to the Mode Status Report as
messages. Allow 24 seconds to pass without an update and verify that the SIL
Step 4: Verification of Mapping NACV Data to the (MS) Report Version One (1)
that the input SIL data from these messages is mapped bit for bit from the most
2-88.
Allow 24 seconds to pass without an update and verify that the SIL field of the
set to ZERO (0).
Step 6: Verification of Mapping NACV Data to the (MS) Report Version Two (2)
that the input SIL, SILSUPP and System Design Assurance (SDA) data from these
messages is mapped bit for bit from the most recently received ADS-B Message to
messages. Allow 24 seconds to pass without an update and verify that the SIL,
SILSUPP and System Design Assurance (SDA) fields of the ADS-B Mode Status
Report are set to ALL ZEROs and that bit 3 of byte 3 is also set to ZERO (0).
2.4.8.2.15 Verification of the Mode Status Report - SV Quality GVA (2.2.8.2.15)

The ADS-B Report Assembly Function shall extract the GVA data from the Aircraft
Operational Status Message (2.2.3.2.7.2.8) and map the value of the GVA field to the
Mode Status Report in the format specified in Table 2-88.
20xx, RTCA, Inc.

689
Report.
Step 2: Verification of Mapping GVA Data to the (MS) Report Version Two (2)
messages. Verify that the GVA data from these messages is mapped bit for bit
from the most recently received ADS-B Message to the Mode Status Report as
messages. Allow 24 seconds to pass without an update and verify that the GVA
field of the ADS-B Mode Status Report is set to ALL ZEROs.
Step 4: Verification of Previous Versions
No specific test procedure is required to validate the requirements for previous

link versions as this field was reserved.
2.4.8.2.16 Verification of the Mode Status Report - SV Quality NICBARO (2.2.8.2.16)

the NICBARO data from the Aircraft Operational Status Message (2.2.3.2.7.2.10) and from
the Target State and Status Message (2.2.3.2.7.1.3.9), and maps the value of the NICBARO
bit from the most recently received ADS-B Message to the Mode Status Report in the binary
format specified in Table 2-88. The NICBARO field in the Mode Status Report uses the least
significant bit of a one-byte field as a one-bit flag that indicates whether or not the
barometric pressure altitude that is provided in the State Vector Report has been cross-
checked against another source of altitude.
20xx, RTCA, Inc.

690
Report.
Step 2: Verification of Mapping NICBARO Data to the (MS) Report Version Zero (0)
Provide valid ADS-B Messages with TYPE Codes equal to each of those specified
in Table 2-188, to the ADS-B Receiving Subsystem in Version Zero (0) format.
Verify that the NICBARO Mode Status Data Parameter bit (bit 7 of byte 2) in the
next output Mode Status Report, is set to ZERO (0).
Step 3: Verification of Mapping NACBARO Data to the (MS) Report Version One (1)
that the input NICBARO data bit, the LSB from a one-byte field, from these
messages is mapped directly from the most recently received ADS-B Message to
Step 4: Verification of Mapping NACBARO Data to the (MS) Report Version Two (2)
that the input NICBARO data bit, the LSB from a one-byte field, from these
messages is mapped directly from the most recently received ADS-B Message to
2.4.8.2.17 Verification of the Track/Heading and Horizontal Reference Direction (HRD)

(2.2.8.2.17)
the Track Angle/Heading (2.2.3.2.7.2.12) and the Horizontal Reference Direction (HRD)
(2.2.3.2.7.2.13) flag bits from the Aircraft Operational Status Message (2.2.3.2.7.2) and
sets the True/Magnetic Heading field in the Mode Status Report in the binary format
specified in Table 2-88. This item within the Mode Status Report is used to indicate the
nature of the Horizontal Direction information being reported in the State Vector Reports.
This applies to the aircraft reported Horizontal Direction (in the State Vector Report). The
encoding of bits 0 and 1 of byte 32 of the Mode Status Report True/Magnetic Heading field
is specified in Table 2-93. Bit 1 of the True/Magnetic Heading field indicates when Ground
Track is being reported (i.e., set to zero) or when Heading is being reported (i.e., set to one).
Bit 0 of the True/Magnetic Heading field indicates when Heading based on True North (i.e.,
set to zero) or when heading based on Magnetic North (i.e., set to one) is being reported.
Equipment Required:
Provide a method of providing Position and Velocity Messages to the ADS-B Receiving
Subsystem. Also, provide a method of providing Aircraft Operational Status Messages with
Version Number Bits (ME Bit 41 through 43, Message Bits 73 through 75) set to either
ZERO (0) or ONE (1). In all messages provided to the ADS-B Receiving Subsystem,
regardless of TYPE, the AA field (Message Bits 9 through 32) will be set to same discrete
20xx, RTCA, Inc.

691
address. The requirement that AA fields be identical is to ensure that the outputted Mode
Report.
Step 2: No Track/Heading or HRD Information Available - Version Zero (0)
Provide valid Version Zero (0) ADS-B Surface Position Messages to the ADS-B
Receiving Subsystem with the Ground Track Status Bit set to ZERO (0). Verify
that bits 0 and 1 of byte 32 of the True/Magnetic Heading field in the output Mode
Status Report are set to ZERO (binary 00).
Provide valid Version Zero (0) ADS-B Airborne Velocity Messages with
(Subtype=3 or 4) to the ADS-B Receiving Subsystem with the Magnetic Heading
Status Bit set to ZERO (0). Verify that bits 0 and 1 of byte 32 of the
True/Magnetic Heading field in the output Mode Status Report are set to ZERO
(binary 00) in the next report.
Step 3: True Ground Track being reported - Version Zero (0)
Provide valid Version Zero (0) ADS-B Surface Position Messages to the ADS-B
Receiving Subsystem with the Ground Track Status Bit set to One (1). Verify
Status Report are set to ONE (binary 01).
Provide valid Version Zero (0) ADS-B Airborne Velocity Messages (Subtype=1
or 2) to the ADS-B Receiving Subsystem. Verify that bits 0 and 1 of byte 32 of
the True/Magnetic Heading field in the output Mode Status Report are set to ONE
(binary 01).
Step 4: Heading relative to Magnetic North being reported - Version Zero (0)
Provide valid Version Zero (0) ADS-B Airborne Velocity Messages (Subtype=3
or 4) to the ADS-B Receiving Subsystem with the Heading Status Bit set to One
(1). Verify that bits 0 and 1 of byte 32 of the True/Magnetic Heading field in the
output Mode Status Report are set to THREE (binary 11).
Step 5: No Track/Heading or HRD Information Available - Version One (1)
Provide valid Version One (1) ADS-B Aircraft Operational Status Messages
(Subtype=1) with Track Angle/Heading Bit set to ZERO (0) and Surface
Position Messages with Ground Track Status Bit set to ZERO (0) to the ADS-B
20xx, RTCA, Inc.

692
Receiving Subsystem. Verify that bits 0 and 1 of byte 32 of the True/Magnetic

Heading field in the output Mode Status Report are set to ZERO (binary 00).
(Subtype=0) with Track Angle/Heading Bit set to One (1) and Airborne
Velocity Messages with (Subtype=3 or 4) to the ADS-B Receiving Subsystem
with the Heading Status Bit set to ZERO (0). Verify that bits 0 and 1 of byte 32
of the True/Magnetic Heading field in the output Mode Status Report are set to
ZERO (binary 00).
Step 6: True Ground Track being reported - Version One (1)
Position Messages with Ground Track Status Bit set to ONE (1) to the ADS-B
Heading field in the output Mode Status Report are set to ONE (binary 01).
(Subtype=0) with Track Angle/Heading Bit set to ZERO (0) and Airborne
Velocity Messages (Subtype=1 or 2) to the ADS-B Receiving Subsystem. Verify
Step 7: Heading relative to True North being reported - Version One (1)
Provide valid Version One (1) ADS-B Airborne Velocity Messages (Subtype=3 or
4) to the ADS-B Receiving Subsystem with the Heading Status Bit set to One
(1).
(Subtype=0) to the ADS-B Receiving Subsystem such that the Track
Angle/Heading and HRD flag bits indicate Heading and True North. Verify that
bits 0 and 1 of byte 32 of the True/Magnetic Heading field in the output Mode
Status Report are set to TWO (binary 10).
Step 8: Heading relative to Magnetic North being reported -Version One (1)
Provide valid Version One (1) ADS-B Airborne Velocity Messages (Subtype=3 or
4) to the ADS-B Receiving Subsystem with the Heading Status Bit set to One
(1).
Angle/Heading and HRD flag bits indicate Heading and Magnetic North. Verify
Status Report are set to THREE (binary 11).
20xx, RTCA, Inc.

693
Step 9: No Track/Heading or HRD Information Available - Version Two (2)
Provide valid Version Two (2) ADS-B Aircraft Operational Status Messages
Position Messages with Ground Track Status Bit set to ZERO (0) to the ADS-B
Heading field in the output Mode Status Report are set to ZERO (binary 00).
(Subtype=0) with Track Angle/Heading Bit set to One (1) and Airborne
Velocity Messages with (Subtype=3 or 4) to the ADS-B Receiving Subsystem
with the Heading Status Bit set to ZERO (0). Verify that bits 0 and 1 of byte 32
of the True/Magnetic Heading field in the output Mode Status Report are set to
ZERO (binary 00).
Step 10: True Ground Track being reported - Version Two (2)
Position Messages with Ground Track Status Bit set to ONE (1) to the ADS-B
Heading field in the output Mode Status Report are set to ONE (binary 01).
(Subtype=0) with Track Angle/Heading Bit set to ZERO (0) and Airborne
Velocity Messages (Subtype=1 or 2) to the ADS-B Receiving Subsystem. Verify
Step 11: Heading relative to True North being reported - Version Two (2)
Provide valid Version Two (2) ADS-B Airborne Velocity Messages (Subtype=3
(1).
Angle/Heading and HRD flag bits indicate Heading and True North. Verify that
bits 0 and 1 of byte 32 of the True/Magnetic Heading field in the output Mode
Status Report are set to TWO (binary 10).
Step 12: Heading relative to Magnetic North being reported -Version Two (2)
Provide valid Version Two (2) ADS-B Airborne Velocity Messages (Subtype=3
(1).
Angle/Heading and HRD flag bits indicate Heading and Magnetic North. Verify
20xx, RTCA, Inc.

694
Status Report are set to THREE (binary 11).
2.4.8.2.18 Verification of the Mode Status Report - Vertical Rate Type (2.2.8.2.18)
the Vertical Rate Source (2.2.3.2.6.1.10, 2.2.3.2.6.2.10, 2.2.3.2.6.3.10, 2.2.3.2.6.4.10)
data from the ADS-B Airborne Velocity Message (2.2.3.2.6) and sets the Vertical Rate
Type in the Mode Status Report in the binary format specified in Table 2-88. The Vertical
Rate Type field uses the least significant bit of a one-byte field in the Mode Status Report.
This one-bit flag is set to ZERO (0) to indicate that the Vertical Rate field in the State
Vector Report holds the rate of change of barometric pressure altitude. Or, this one-bit flag
is set to ONE (1) to indicate that the Vertical Rate field holds the rate of change of
geometric altitude.
Report.
Step 2: Verification of Barometric Pressure Altitude Version Zero (0)
Provide valid Version Zero (0) Airborne Velocity Messages to the ADS-B
Receiving Subsystem such that Barometric Pressure Altitude is indicated. Verify
that the LSB in byte 33 of the Mode Status Report is set to ZERO (0).
Step 3: Verification of Geometric Altitude Version Zero (0)
Provide valid Version Zero (0) Airborne Velocity Messages to the ADS-B
Receiving Subsystem such that Geometric Altitude is indicated. Verify that the
LSB in byte 33 of the Mode Status Report is set to ONE (1).
Step 4: Verification of Barometric Pressure Altitude Version One (1)
Provide valid Version One (1) Airborne Velocity Messages to the ADS-B
Step 5: Verification of Geometric Altitude Version One (1)
Provide valid Version One (1) Airborne Velocity Messages to the ADS-B
20xx, RTCA, Inc.

695
Step 6: Verification of Barometric Pressure Altitude Version Two (2)
Provide valid Version Two (2) Airborne Velocity Messages to the ADS-B
Step 7: Verification of Geometric Altitude Version Two (2)
Provide valid Version Two (2) Airborne Velocity Messages to the ADS-B
2.4.8.2.19 Verification of the (Reserved for) Flight Mode Specific Data (2.2.8.2.19)
Purpose/Inroduction:
A 3-bit field in the Mode Status Report is reserved for future use as a Flight Mode Specific
Data field. In the current version of these MOPS, this field is set to ALL ZEROs.
Verify that in each Mode Status Report, the Flight Mode Specific Data field is ZERO.
2.4.8.3 Verification of the ADS-B On-Condition Report Characteristics (2.2.8.3)

2.4.8.3.1 Verification of the Target State Report (2.2.8.3.1)

2.4.8.3.1.1 Verification of the Target State Report Type and Structure Identification (2.2.8.3.1.1)
the Target State Report and is intended to provide a methodology for implementers to
structure concatenated reports when data for some parameters is not available. This test
procedure will be used to verify the correct encoding of the Report Structure (Target State
Report bits 5 through 21).
Equipment:
Messages.
20xx, RTCA, Inc.

696
If the Report Assembly Function is implemented such that the Target State Report
may be shortened when certain data is not available, skip to Step 2.
If the Report Assembly Function is implemented such that the Target State Report
is 22 bytes long regardless of data availability across fields, consecutively provide
the ADS-B Receiving Subsystem with valid ADS-B Messages, varying message
types appropriately to prompt output of Target State Reports. Ensure that in each
valid ADS-B Message provided to the ADS-B Receiving Subsystem, that the
AA field (message bits 9 through 32) is set to hexadecimal A60DBE.
Verify that in every Target State Report provided to the application, bytes 2
through 4 are hexadecimal A60DBE. Verify that the 16-bit Report Structure field
is set to ALL ONEs in every Target State Report provided to the application.
Verify that the Target State Report is 22 bytes long. This test procedure is now
completed.
Appropriate test procedures to validate this capability are provided in 2.4.8.3.1.3

through .
2.4.8.3.1.2 Verification of Target State and Status Validity Flags(2.2.8.3.1.2)

This test procedure is to verify the Validity Flags for data provided in the Target State
Report as indicated in bytes #3 and #4 of the Target State Report shown for item 0c in
Table 2-95A.
Provide valid Airborne Position and Velocity Messages to the ADS-B Receiving
(see 2.2.10.4) and is outputting Target State Reports to the Report Buffer.
Step 2: Verification of Validity Flags
Provide valid Target State and Status Messages to the ADS-B Receiving
Subsystem designed to trigger both valid and invalid validity flags via the
indicated message bit(s) for mapping the following Target State Report elements
in the appropriate bit in byte 3 of the Report as per Table 2-95A:
MCP/FCU Selected Altitude or FMS Selected Altitude (ME bits 10-20

ALL ZEROES = Invalid, Non-ZERO = Valid)
20xx, RTCA, Inc.

697
Barometric Pressure Setting (Minus 800 millibars) (ME bits 21-29 ALL
ZEROES = Invalid, Non-ZERO = Valid)
Selected Heading (ME bit 30)
MCP/FCU Mode Bits Status (ME bit 47)
The ADS-B Report Assembly Function will be prompted to output a Target State
Report to the Report Buffer. Verify that Target State Reports are generated where
the validity flags are set to both ZERO and ONE at least one time each for
MCP/FCU Selected Altitude or FMS Selected Altitude, Barometric Pressure
Setting (Minus 800 millibars), Selected Heading and MCP/FCU Mode Bits Status.
2.4.8.3.1.3 Verification of the Participant Address (2.2.8.3.1.3)

2.4.8.3.1.4 Verfication of the Address Qualifier (2.2.8.3.1.4)

included in 2.4.8.1.3.
2.4.8.3.1.5 Verification of the Target State Report - Time of Applicability (2.2.8.3.1.5)

Each time that an Individual Target State Report is updated, the Report Assembly Function
updates the Report Time of Applicability data in the Target State Report with either the GPS
/ GNSS UTC Measure Time data (see 2.2.8.5.1) or the Established Receiver Unit Time
(see 2.2.8.5.2), whichever is applicable to the Receiving device Report Assembly Function
installation requirements.
Equipment:
time when a Target State Report is provided to the output buffer.
A method of providing valid ADS-B Messages that are used for constructing Target State
20xx, RTCA, Inc.

698
The requirement that the AA fields be identical is to ensure that the outputted Target State
Reports are related solely to this test procedure.
(see 2.2.10.4) and is outputting Target State Reports to the Report Buffer.
Provide any valid Target State and Status Message. After one second, provide a
valid ADS-B Velocity Message to the ADS-B Receiving Subsystem such that the
ADS-B Report Assembly Function is prompted to output a Target State Report to
the Report Buffer.
for Non-Precision Installations. Retrieve the resulting Target State Report from
the Report Buffer. Calculate the time represented in the Report Time of
Applicability (Report bytes 16 through 17 in the full Target State Report) and
verify that this time is within 5 ms of the previously marked time.
2.4.8.3.1.6 Verification of Selected Altitude: Selected Altitude Type (2.2.8.3.1.6)

The Selected Altitude Type parameter uses the least significant bit within byte 10 to encode
the parameter values specified in 2.2.3.2.7.1.3.2.
and is outputting Reports to the Report Buffer. Verify that the Report Type
Coding bits 7 through 4 of byte 0 are set to THREE (binary 0011) to indicate
Target State Report.
Step 2: Verification of Selected Altitude: MCP/FCU
Provide a valid Target State and Status Message to the ADS-B Receiving
Subsystem indicating the data source as MCP/FCU, i.e., ME bit 9 in the Target
State and Status Message is set to ZERO. Verify that the corresponding Target
State Report indicates an MCP/FCU source.
20xx, RTCA, Inc.

699
Step 3: Verification of Selected Altitude: FMS
Subsystem indicating the data source as FMS, i.e., ME bit 9 in the Target State
and Status Message is set to ONE. Verify that the corresponding Target State
Report indicates an FMS source.
Step 4: Verification of Selected Altitude: Data Not Available
Subsystem with ME bit 9 set to ZERO and ME bits 10-20 set to ALL ZEROs in
the Target State and Status Message to indicate data not available. Verify that the
corresponding Target State Report indicates data not available.
2.4.8.3.1.7 Verification of the Selected Altitude: MCP/FCU Selected Altitude or FMS Selected
Altitude (2.2.8.3.1.7)
The MCP / FCU Selected Altitude or FMS Selected Altitude parameter uses the three (3)
least significant bits within byte 11 and the 8 bits of byte 12 to encode the parameter values
specified 2.2.3.2.7.1.3.3.
Step 2: Verification of Selected Altitude: MCP/FCU Selected Altitude or FMS Selected

Altitude
Subsystem. Verify that ME bits 10 through 20 of the Target State and Status
Message are mapped bit for bit to the Target State Report in the three least
significant bits of byte 11 and all 8 bits of byte 12 of that report.
2.4.8.3.1.8 Verification of the Selected Altitude: Barometric Pressure Setting (Minus 800
millibars) (2.2.8.3.1.8)
The Barometric Pressure Setting (Minus 800 millibars) parameter uses the three (3) least
significant bits within byte 13 and the 8 bits of byte 14 to encode the patameter values
specified in 2.2.3.2.7.1.3.4.
20xx, RTCA, Inc.

700
Step 2: Verification of Selected Altitude: Barometric Pressure Setting (Minus 800

millibars)
Subsystem. Verify that ME bits 21-29 of the Target State and Status Message are
mapped directly to the Target State Report in the least significant bit of byte 13
and the 8 bits of byte 14 of that report.
2.4.8.3.1.9 Verification of the Selected Heading (2.2.8.3.1.9)

The Selected Heading parameter uses the least significant bit of byte 15 and the 8 bits of
byte 16 to encode the heading values specified in 2.2.3.2.7.1.3.7.
Step 2: Verification of Selected Heading
Subsystem. Verify that ME bits 31-39 of the Target State and Status Message are
mapped directly to the Target State Report in the least significant bit of byte 15
and the 8 bits of byte 16 of that report.
2.4.8.3.1.10 Verification of the Mode Indicators: Autopilot Engaged (2.2.8.3.1.10)

The Autopilot Engaged parameter uses the least significant bit within byte 17 to encode the
parameter values specified in 2.2.3.2.7.1.3.12.
20xx, RTCA, Inc.

701
Step 2: Verification of Mode Indicators: Autopilot Engaged
Subsystem. Verify that ME bit 48 of the Target State and Status Message is
mapped to the Target State Report in the least significant bit of byte 17 of that
report.
2.4.8.3.1.11 Verification of the Mode Indicators: VNAV Mode Engaged (2.2.8.3.1.11)

The VNAV Mode Engaged parameter uses the least significant bit within byte 18 to encode
the parameter values specified in 2.2.3.2.7.1.3.13.
Step 2: Verification of Mode Indicators: Autopilot engaged
report.
2.4.8.3.1.12 Verification of the Mode Indicators: Altitude Hold Mode (2.2.8.3.1.12)

The Altitude Hold Mode parameter uses the least significant bit within byte 19 to encode the
20xx, RTCA, Inc.

702
Step 2: Verification of Mode Indicators: Altitude Hold Mode
report.
2.4.8.3.1.13 Verification of the Mode Indicators: Approach Mode (2.2.8.3.1.13)

The Approach Mode parameter uses the least significant bit within byte 20 to encode the
Step 2: Verification of Mode Indicators: Approach Mode
Subsystem. Verify that ME bits 52 of the Target State and Status Message is
report.
2.4.8.3.1.14 Verification of the Reserved Byte (2.2.8.3.1.14)

No specific test procedure is required to validate the requirement of 2.2.8.3.1.14.
20xx, RTCA, Inc.

703
2.4.8.3.2 Verification of the Air Referenced Velocity (ARV) Report (2.2.8.3.2)

2.4.8.3.2.1 Verification of the ARV Report Type and Structure Identification and Validity Flags
(2.2.8.3.2.1)
2.4.8.3.2.1.1 Verification of the ARV Report Type and Structure Identification (2.2.8.3.2.1.1)
the Target State Report and is intended to provide a methodology for implementers to
structure concatenated reports when data for some parameters is not available. This test
procedure will be used to verify the correct encoding of the Report Structure (ARV Report
bits 6 through 13).
Equipment:
Messages.
If the Report Assembly Function is implemented such that the ARV Report may
be shortened when certain data is not available, skip to Step 2.
If the Report Assembly Function is implemented such that the ARV Report is 14
bytes long regardless of data availability across fields, consecutively provide the
ADS-B Receiving Subsystem with valid ADS-B Messages, varying message types
appropriately to prompt output of ARV Reports. Ensure that in each valid ADS-B
Message provided to the receiver, the AA field (message bits 9 through 32) is
set to hexadecimal A60DBE.
Verify that in every ARV Report provided to the application, bytes 3 through 5
are hexadecimal A60DBE. Verify that the 16-bit Report Structure field is set to
ALL ONEs in every ARV Report provided to the application. Verify that the
ARV Report is 14 bytes long.
Appropriate test procedures to validate this capability are provided in 2.4.8.3.2.2

through 2.4.8.3.2.7.
20xx, RTCA, Inc.

704
2.4.8.3.2.1.2 Verification of the ARV Report Validity Flags (2.2.8.3.2.1.2)

The only Validity Flag specified by these MOPS for the Air Referenced Velocity Report
uses the two (2) least significant bits of the one-byte field as shown in Table 2-98. These
flags are set as specified in 2.2.8.3.2.1.2.
Coding bits 7 through 4 of byte 0 are set to FOUR (binary 0100) to indicate Air
Referenced Velocity Report.
Step 2: Verification of Invalid Airspeed and Invalid Heading
Provide a valid Version ZERO (0) Aircraft Operational Status Message and an
Airborne Velocity Message to the ADS-B Receiving Subsystem such that the
Heading Data is Not Available and the Airspeed subfield indicates No
Airspeed Information Available or the NACV / NUCR (Version 1 / 0 respectively)
Subfield is Invalid. Verify that the two least significant bits of byte 2 of the
output ARV Report are both set to ZERO (binary 00).
Repeat this step with a Version ONE (1) Aircraft Operational Status Message and
an Airborne Velocity Message and verify that the two least significant bits of byte
2 of the output ARV Report are both set to ZERO (binary 00).
Repeat this step with a Version TWO (2) Aircraft Operational Status Message and
an Airborne Velocity Message and verify that the two least significant bits of byte
2 of the output ARV Report are both set to ZERO (binary 00).
Step 3: Verification of Invalid Airspeed and Valid Heading
Provide a valid Version ZERO (0) Aircraft Operational Status and an Airborne
Velocity Message to the ADS-B Receiving Subsystem such that the Heading
Data is Valid and the Airspeed subfield indicates No Airspeed Information
Available or the NACV / NUCR (Version 1 / 0 respectively) subfield is Invalid.
Verify that the two least significant bits of byte 2 of the output ARV Report are
set to ONE (binary 01).
Repeat this step with a Version ONE (1) Aircraft Operational Status Message and
an Airborne Velocity Message and that the two least significant bits of byte 2 of
the output ARV Report are set to ONE (binary 01).
Repeat this step with a Version TWO (2) Aircraft Operational Status Message and
an Airborne Velocity Message and that the two least significant bits of byte 2 of
the output ARV Report are set to ONE (binary 01).
20xx, RTCA, Inc.

705
Step 4: Verification of Valid Airspeed and Invalid Heading
Provide valid Airborne Velocity Message to the ADS-B Receiving Subsystem

such that the Heading Data is Not Available and the Airspeed subfield indicates
A Valid Airspeed. Verify that the two least significant bits of byte 2 of the
output ARV Report are set to TWO (binary 10).
Step 5: Verification of Valid Airspeed and Valid Heading
Provide valid Airborne Velocity Message to the ADS-B Receiving Subsystem

such that the Heading Data is Valid and the Airspeed subfield indicates A
Valid Airspeed. Verify that the two least significant bits of byte 2 of the output
ARV Report are set to THREE (binary 11).
2.4.8.3.2.2 Verification of the Participant Address (2.2.8.3.2.2)

2.4.8.3.2.3 Verification of the Address Qualifier (2.2.8.3.2.3)

included in 2.4.8.1.3.
2.4.8.3.2.4 Verification of the Report Time of Applicability (2.2.8.3.2.4)

Each time that an individual Air Referenced Velocity Report is updated, the Report
Assembly Function updates the Time of Applicability data in the Air Referenced Velocity
Report with either the GPS/GNSS UTC Measure Time data (see 2.2.8.5.1) or the
Established Receiver Unit Time (see 2.2.8.5.2), whichever is applicable to the Receiving
device Report Assembly Function installation requirements. Report Time of Applicability
data is provided in the Air Referenced Velocity report in binary format as specified in Table
2-96.
Equipment:
time when a Target State Report is provided to the output buffer.
A method of providing valid ADS-B Messages that are used for constructing Target State
20xx, RTCA, Inc.

706
The requirement that the AA fields be identical is to ensure that the outputted Target State
Reports are related solely to this test procedure.
(see 2.2.10.4) and is outputting ARV Reports to the Report Buffer.
Provide any valid Target State and Status Message. After one second, provide a
valid ADS-B Velocity Message to the ADS-B Receiving Subsystem such that the
ADS-B Report Assembly Function is prompted to output an ARV Report to the
Report Buffer.
for Non-Precision Installations. Retrieve the resulting ARV Report from the
Report Buffer. Calculate the time represented in the Report Time of
Applicability (Report bytes 7 and 8 in the full ARV Report) and verify that this
time is within 5 ms of the previously marked time.
2.4.8.3.2.5 Verification of the Airspeed (2.2.8.3.2.5)

included in the following subparagraphs 2.4.8.3.2.5.1 and 2.4.8.3.2.5.2.
2.4.8.3.2.5.1 Verification of True Airspeed (TAS) Reporting (2.2.8.3.2.5)

These test procedures verify True Airspeed reported over the range of 0 to 4000 knots as
Step 1: True Air Speed (TAS) (Subsonic) Reporting
For each case in Table 2-198 below, generate valid ADS-B Airborne Velocity
Messages (Subtype 3, Subsonic) which includes the Airspeed Type Bit (ME Bit
25) equal to ONE, and the encoded data (ME Bits 26 through 35) for the
Decimal True Air Speed (TAS) values listed in the table, and verify that the ADS-
B Receiver/Report Assembly outputs ARV Reports
20xx, RTCA, Inc.

707
Verify that the corresponding Air Speed presence bit (Report Byte #0, Bit 2), and
the Air Speed Validity Flag (Report Byte #2, Bit 1), are ONEs.
Verify that the reported Binary Decoded TAS datum (Report Bytes #31 through
32) matches the corresponding True Air Speed value in the table.
Table 2-198: True Air Speed (Subsonic) Test Data

True Air Speed (Subsonic)
Decimal True Binary Decoded
Air Speed True Air Speed
(knots) (Subsonic)
0 0000 0000 0000 0000
1 0000 0000 0001 0000
2 0000 0000 0010 0000
4 0000 0000 0100 0000
8 0000 0000 1000 0000
16 0000 0001 0000 0000
32 0000 0010 0000 0000
64 0000 0100 0000 0000
128 0000 1000 0000 0000
256 0001 0000 0000 0000
512 0010 0000 0000 0000
1021 0011 1111 1101 0000
Step 2: True Air Speed (TAS) (Supersonic) Reporting
Messages (Subtype 4, Supersonic) which includes the Airspeed Type Bit (ME
Bit 25) equal to ONE, and the encoded data (ME Bits #26 through 35) for the
Decimal True Air Speed (TAS) values listed in the table, and verify that the ADS-
B Receiver/Report Assembly outputs ARV Reports.
Verify that the reported Binary Decoded TAS datum (Report Bytes #31 through
32) matches the corresponding True Air Speed value in the table.
20xx, RTCA, Inc.

708
Table 2-199: True Air Speed (Supersonic) Test Data

True Air Speed (Supersonic)
Decimal True Binary Decoded
Air Speed True Air Speed
(knots) (Supersonic)
0 0000 0000 0000 0000
4 0000 0000 0100 0000
8 0000 0000 1000 0000
16 0000 0001 0000 0000
32 0000 0010 0000 0000
64 0000 0100 0000 0000
128 0000 1000 0000 0000
256 0001 0000 0000 0000
512 0010 0000 0000 0000
1024 0100 0000 0000 0000
2048 1000 0000 0000 0000
4084 1111 1111 0100 0000
Step 3: True Air Speed (TAS) (Subsonic / Supersonic) Data Not Available
Keep the Airspeed presence bit at ONE, and set the Airspeed Validity Flag to
ZERO. Verify that the reported Binary Decoded TAS datum is set to all
ZEROs.
2.4.8.3.2.5.2 Verification of Indicated Airspeed (IAS) Reporting (2.2.8.3.2.5)

These test procedures verify Indicated Airspeed reported over the range of 0 to 4000 knots
Step 1: Indicated Air Speed (IAS) (Subsonic) Reporting
Messages (Subtype 3, Subsonic) which includes the Airspeed Type Bit (ME Bit
25) equal to ZERO, and the encoded data (ME Bits 26 through 35) for the
Decimal Indicated Air Speed (IAS) values listed in the table, and verify that the
ADS-B Receiver/Report Assembly outputs ARV Reports.
Verify that the reported Binary Decoded IAS datum (Report Bytes # 33 through
34) matches the corresponding Indicated Air Speed value in the table.
20xx, RTCA, Inc.

709
Table 2-200: Indicated Air Speed (Subsonic) Test Data

Indicated Air Speed (Subsonic)
Decimal
Binary Decoded
Indicated Air
Indicated Air Speed (Subsonic)
Speed (knots)
0 0000 0000 0000 0000
1 0000 0000 0001 0000
2 0000 0000 0010 0000
4 0000 0000 0100 0000
8 0000 0000 1000 0000
16 0000 0001 0000 0000
32 0000 0010 0000 0000
64 0000 0100 0000 0000
128 0000 1000 0000 0000
256 0001 0000 0000 0000
512 0010 0000 0000 0000
1021 0011 1111 1101 0000
Step 2: Indicated Air Speed (IAS) (Supersonic) Reporting
Messages (Subtype 4, Supersonic) which includes the Airspeed Type Bit (ME
Bit 25) equal to ZERO, and the encoded data (ME Bits 26 through 35) for the
Decimal Indicated Air Speed (IAS) values listed in the table, and verify that the
ADS-B Receiver/Report Assembly outputs ARV Reports.
Verify that the reported Binary Decoded IAS datum (Report Bytes # 33 through
34) matches the corresponding Indicated Air Speed value in the table.
Table 2-201: Indicated Air Speed (Supersonic) Test Data

Indicated Air Speed (Supersonic)
Decimal
Binary Decoded
Indicated Air
Indicated Air Speed (Supersonic)
Speed (knots)
0 0000 0000 0000 0000
4 0000 0000 0100 0000
8 0000 0000 1000 0000
16 0000 0001 0000 0000
32 0000 0010 0000 0000
64 0000 0100 0000 0000
128 0000 1000 0000 0000
256 0001 0000 0000 0000
512 0010 0000 0000 0000
1024 0100 0000 0000 0000
2048 1000 0000 0000 0000
4084 1111 1111 0100 0000
20xx, RTCA, Inc.

710
Step 3: Indicated Air Speed (IAS) (Subsonic / Supersonic) Data Not Available
Keep the Airspeed presence bit at ONE, and set the Airspeed Validity Flag to
ZERO. Verify that the reported Binary Decoded IAS datum is set to all
ZEROs.
2.4.8.3.2.6 Verification of the Airspeed Type (2.2.8.3.2.6)

These test procedures verify that the Airspeed Type and Validity field in the Air Referenced
Velocity Report is encoded as specified in Table 2-99. and 2.2.8.3.2.6.
Coding bits 7 through 4 of byte 0 are set to FOUR (binary 0100) to indicate Air
Referenced Velocity Report.
Step 2: Verification of Airspeed Field Not Valid Version Zero (0)
Provide a valid Version Zero (0) Aircraft Operational Status and an Airborne
Velocity Message - Subtype=3 to the ADS-B Receiving Subsystem such that the
value in the Airspeed subfield indicates No Airspeed Available. Verify that
the two least significant bits of byte 11 in the next ARV report are both set to
ZERO (binary 00) and that the Airspeed Valid Flag, bit 1 of byte 2, is also set to
ZERO (0). Send a second valid Version Zero (0) Airborne Velocity Message -
Subtype=3 to the ADS-B Receiving Subsystem such that the NUCR value is
ZERO (0) and verify that the two least significant bits of byte 11 in the next ARV
report are both set to ZERO (binary 00) and that the Airspeed Valid Flag, bit 1 of
byte 2, is also set to ZERO (0). Repeat this step for two Subtype 4 Airborne
Velocity Messages.
Step 3: Verification of True Airspeed (TAS) Version Zero (0)
value in the Airspeed subfield is valid and indicates True Airspeed and where
NUCR has a non-zero value. Verify that the two least significant bits of byte 11 in
the next ARV report are set to ONE (binary 01). Repeat this step for two Subtype
4 Airborne Velocity Messages.
20xx, RTCA, Inc.

711
Step 4: Verification of Indicated Airspeed (IAS) Version Zero (0)
value in the Airspeed subfield is valid and indicates Indicated Airspeed and
where NUCR has a non-zero value. Verify that the two least significant bits of
byte 11 in the next ARV report are set to TWO (binary 10). Repeat this step for
two Subtype 4 Airborne Velocity Messages.
Step 5: Verification of Airspeed Field Not Valid Version One (1)
Provide a valid Version One (1) Aircraft Operational Status and an Airborne
ZERO (0). Send a second valid Version One (1) Airborne Velocity Message,
Subtype 3 to the ADS-B Receiving Subsystem such that the NACV value is ZERO
(0) and verify that the two least significant bits of byte 11 in the next ARV report
are both set to ZERO (binary 00) and that the Airspeed Valid Flag, bit 1 of byte 2,
is also set to ZERO (0). Repeat this step for two Subtype 4 Airborne Velocity
Messages.
Step 6: Verification of True Airspeed (TAS) Version One (1)
NACV has a non-zero value. Verify that the two least significant bits of byte 11 in
Step 7: Verification of Indicated Airspeed (IAS) Version One (1)
where NACV has a non-zero value. Verify that the two least significant bits of
Step 8: Verification of Airspeed Field Not Valid Version Two (2)
Provide a valid Version Two (2) Aircraft Operational Status and an Airborne
ZERO (0). Send a second valid Version Two (2) Airborne Velocity Message,
Subtype 3 to the ADS-B Receiving Subsystem such that the NACV value is ZERO
(0) and verify that the two least significant bits of byte 11 in the next ARV report
20xx, RTCA, Inc.

712
are both set to ZERO (binary 00) and that the Airspeed Valid Flag, bit 1 of byte 2,
is also set to ZERO (0). Repeat this step for two Subtype 4 Airborne Velocity
Messages.
Step 9: Verification of True Airspeed (TAS) Version Two (2)
NACV has a non-zero value. Verify that the two least significant bits of byte 11 in
Step 10: Verification of Indicated Airspeed (IAS) Version Two (2)
where NACV has a non-zero value. Verify that the two least significant bits of
2.4.8.3.2.7 Verification of the Heading While Airborne (2.2.8.3.2.7)

These test procedures verify that the Aircrafts Heading is reported properly as specified in
2.2.8.3.2.7.
Step 1: Heading Reporting
Messages (TYPE=19, Subtype=3), which include the encoded data (ME Bits 14
and 15 through 24) for the Heading Status Bit and the Decimal Heading
values listed, and verify that the ADS-B Receiver/Report Assembly outputs ARV
Reports.
Verify that the corresponding Heading presence bit (Report Byte #0, Bit 0), and
the Heading Validity Flag (Report Byte #2, Bit 0), are ONEs.
Verify that the reported Binary Decoded Heading data (Report Bytes # 37 through
38) match the corresponding value in the table.
20xx, RTCA, Inc.

713
Table 2-202: Heading Subfield Test Data

Magnetic Heading
Decimal
Heading Binary Decoded
Heading
Status Heading
(degrees)
0 11.2500 0000 0000 0000
0 359.6484 0000 0000 0000
1 0.0000 0000 0000 0000
1 0.3516 0000 0000 0001
1 0.7031 0000 0000 0010
1 1.4063 0000 0000 0100
1 2.8125 0000 0000 1000
1 5.6250 0000 0001 0000
1 11.2500 0000 0010 0000
1 22.5000 0000 0100 0000
1 45.0000 0000 1000 0000
1 90.0000 0001 0000 0000
1 180.0000 0010 0000 0000
1 359.6484 0011 1111 1111
Step 2: Heading Data Not Available
Keep the Heading presence bit at ONE, and set the Heading Validity Flag to
ZERO. Verify that the reported Binary Decoded Heading datum is set to all
ZEROs.
2.4.8.4 Verification of the Processing of Reserved Message Types ()

Verification of the processing of reserved ADS-B Message types is accomplished by
including ADS-B Messages with TYPE Codes 24, 25, 26, 27 and 30 is the tests for State
Vector (2.4.8.1), Mode Status (2.4.8.2) and On-Condition (2.4.8.3) reports. See 2.4.8
for test scenario requirements.
2.4.8.5 Verification of the Receiving Installation Time Processing (2.2.8.5)

2.4.8.5.1 Verification of Precision Installations (2.2.8.5.1)

These test procedures verify the requirements for precision installations as specified in
2.2.8.5.1.
Equipment:
A method of providing Surface Position Messages of TYPE 5 or 6 and Airborne Position

Messages of TYPE 9, 10, 20 or 21 to the ADS-B Receiving Device. Also, a method of
20xx, RTCA, Inc.

714
providing appropriate messages to prompt output of State Vector reports to the Report
Buffer. All messages must have the TIME subfield set to ZERO.
Step 1: Verification of UTC Measure Time Data.
Configure the ADS-B Receiving device to output reports by providing the

appropriate messages at the nominal rate, providing GPS/GNSS UTC Measure
Time data appropriately. Mark TIME ZERO as the Time of Applicability
provided in the first report. Note also the time that the message was provided that
prompted the output of the first report.
Continue to provide messages at the nominal rate, extracting the Time of

Applicability from each report that is outputted. Verify that time of applicability
is properly reported within the accuracies of the established system clock.
300 seconds after the message that prompted the first report, provide a valid
Surface Position Message with the TYPE subfield set to 5 or 6, and the TIME
subfield set to ZERO.
Verify that in the resulting report, the Time of Applicability field does not reflect a
value between TIME ZERO and 300 seconds.
Step 2: Repeat:
Repeat Step 1, using Airborne Position Messages of TYPE 9, 10, 20 or 21 instead

of the previously specified Surface Position Messages.
2.4.8.5.2 Verification of the Non-Precision Installations (2.2.8.5.2)

Purpose/Introduction
These test procedures verify the requirements for non-precision installations as specified in
2.2.8.5.2.
Equipment:
A method of providing Surface Position Messages of TYPE other than 5 or 6 and Airborne
Position Messages of TYPE other than 9, 10, 20, or 21 to the ADS-B Receiving Device.
Also, a method of providing appropriate messages to prompt output of State Vector reports
to the Report Buffer. All messages must have the TIME subfield set to ZERO.
Step 1: Verification of Internal Clock Time Data.
Configure the ADS-B Receiving device to output reports by providing the

appropriate messages at the nominal rate. Mark TIME ZERO as the Time of
20xx, RTCA, Inc.

715
Applicability provided in the first report. Note also the time that the message was
provided that prompted the output of the first report.
Continue to provide messages at the nominal rate, extracting the Time of

Applicability from each report that is outputted. Verify that time of applicability
is properly reported within the accuracies of the established system clock.
300 seconds after the message that prompted the first report, provide a valid
Surface Position Message with the TYPE subfield set to other than 5 or 6, and the
TIME subfield set to ZERO.
Verify that in the resulting report, the Time of Applicability field does not reflect a
value between TIME ZERO and 300 seconds.
Step 2: Repeat:
Repeat Step 1, using Airborne Position Messages of TYPE other than 9, 10, 20, or
21 instead of the previously specified Surface Position Messages.
2.4.9 Verification of the ADS-B Report Type Requirements (2.2.9)

2.4.9.1 Verification of the ADS-B Receiver Reporting Requirements for Class A Equipage
(2.2.9.1)
2.4.9.1.1 through 2.4.9.1.4.
2.4.9.1.1 Verification of the ADS-B State Vector Reports for Class A Equipage (2.2.9.1.1)
The test procedures required to validate the requirements of 2.2.9.1.1 are included in
2.4.8.1.1 through 2.4.8.1.22.
2.4.9.1.2 Verification of the ADS-B Mode Status Reports for Class A Equipage (2.2.9.1.2)
2.4.8.2.1 through 2.4.8.2.18, and in the test steps that are identified below.
Table 2-102 presents the required elements of a Mode Status Report. The Notes below the
table indicate that several of those elements will continue to be reported in the Mode Status
Report for a time period after the specifically referenced information has last appeared in its
respective ADS-B Message. The following test procedure steps are intended to test that
function.
20xx, RTCA, Inc.

716
Step 1: Perform the test steps in 2.4.8.2.6. Terminate the input for the ADS-B Aircraft
Identification Message and verify that the Mode Status Report continues to
contain the last reported state of the Call Sign for 200 seconds.
Identification Message and verify that the Mode Status Report continues to
contain the last reported state of the Emitter Category for 200 seconds.
Operational Status Message and verify that the Mode Status Report continues to
contain the last reported state of the A/V Length and Width Codes for 100
seconds.
Operational Status Messages and/or the ADS-B Target State and Status Messages,
of the Capability Class Codes for 100 seconds.
of the Operational Mode Codes for 100 seconds.
of the NACP for 100 seconds.
Step 7: Perform the test steps in 2.4.8.2.13. Terminate the input for the ADS-B
Airborne Velocity Messages and verify that the Mode Status Report continues to
contain the last reported state of the NACV for 100 seconds.
of the SIL for 100 seconds.
Operational Status Messages and verify that the Mode Status Report continues to
contain the last reported state of the True/Magnetic Heading for 100 seconds.
Step 10: Perform the test steps in 2.4.8.2.18. Terminate the input for the ADS-B
Airborne Velocity Messages and verify that the Mode Status Report continues to
contain the last reported state of the Vertical Rate Type for 100 seconds.
20xx, RTCA, Inc.

717
2.4.9.1.3 Verification of the ADS-B Target State Reports for Class A Equipage (2.2.9.1.3)
These test procedures verify the requirements for Class A equipment to produce target State
Reports, as specified in 2.2.9.1.3.
a. Equipage Class A0, A1S and A1 equipment are not required to comply with any of the
test procedures in 2.4.8.3.
b. As a minimum, equipage Class A3 equipment shall perform test procedures outlined in

2.4.8.3.1.1 through Error! Reference source not found. in order to validate the
requirements of 2.2.9.1.3.b.
2.4.9.1.4 Verification of the ADS-B Air Referenced Velocity Reports for Class A Equipage
(2.2.9.1.4)
2.4.8.3.2 through 2.4.8.3.2.7.
2.4.9.2 Verification of the ADS-B Receiver Report Content Requirements for Class B
Equipage (2.2.9.2)
There are no report requirements for Class B, i.e., Broadcast Only, Equipage.
2.4.10 Verification of the ADS-B Receiver Report Assembly and Delivery (2.2.10)
2.4.10.1 Verification of the Fundamental Principals of Report Assembly and Delivery

(2.2.10.1)
2.4.10.1.1 Verification of the General Data Flow (2.2.10.1.1)

20xx, RTCA, Inc.

718
2.4.10.1.2 Verification of the ADS-B Report Organization (2.2.10.1.2)

These test procedures verify that all ADS-B Message receptions and Reports are organized
(i.e., indexed) in accordance with the Participant Address (see 2.2.3.2.1.1) and the Address
Qualifier (see 2.2.8.1.3). The Participant Address and Address Qualifier are required
elements in all ADS-B Reports (see Table 2-81 Items 1 and 2, Table 2-88 Items 1 and 2,
Table 2-94 Items 1 and 2, and Table 2-96 Items 1 and 2).
Equipment Required:
a. Equipment capable of loading valid data for ADS-B broadcast messages into the ADS-
B equipment under test through the operational interface.
b. A method of monitoring ADS-B broadcast messages output by the equipment under

test.
Set the Airborne condition and load valid data into all the ADS-B Broadcast messages that
can be supported by the equipment under test at a rate ensuring maximum transmission rate
for a period of at least five (5) minutes. Ensure that ADS-B Messages will cause reports to
be generated by the Report Assembly Function. Halt the transmission of ADS-B Messages
and examine the contents of the database of messages and reports and verify that the
messages and reports are being organized (i.e., indexed) in accordance with the Participant
Address.
2.4.10.1.3 Verification of the ADS-B Message Temporary Retention (2.2.10.1.3)

These test procedures verify that, unless otherwise specified, all ADS-B Messages and
decoded latitudes and longitudes received for a given Participant are appropriately time
tagged and temporarily stored for at least 200 seconds unless replaced by a received
message of equivalent type from that Participant. If no new messages have been received
from a given Participant for 250 seconds, then all records (including temporary storage)
relevant to the Participant Address will be deleted from the Report Output Storage Buffer.
20xx, RTCA, Inc.

719
Step 1: Airborne Mode 25 Participants
Set up an Airborne scenario and simulation for a minimum of 25 Participants at

various altitudes, velocities, initial positions and general directions. Design the
simulation to include Participants that are traveling toward, away from, and
crossing in the vicinity of, the ADS-B Receiving Device. The simulation must
include several random Participants that appear for a short period of time of not
less than fifteen (15), and not greater than twenty five (25) seconds, with
accompanying issue of even and odd encoded Airborne Position Messages,
and then disappear from the simulation altogether. These same Participants
should be re-introduced to the simulation after an absence of at least 500 seconds.
Configure the ADS-B Transmitting Subsystem simulation to transmit Version

Zero (0), Version One (1) and Version Two (2) Airborne Velocity Messages,
Airborne Position Messages, Aircraft Identification and Category Messages,
Aircraft Operational Status Messages, and Version One (1) and Version Two (2)
Target State and Status Messages at a rate ensuring maximum transmission rate
for a period of at least twenty (20) minutes.
Initiate the simulation and verify that all received data for a given individual
Participant is being stored in temporary storage within a single track file. Verify
that each entry contains a time tag. Verify that for those Participants that are
continuing through out the simulation that updated information replaces old
information upon the receipt of the new information. Verify that for those
Participants that were introduced for a short period of time between 15 and 25
seconds that each track file for that Participant is retained for at least 250 seconds.
Verify that if no new messages are received for a given Participant for a period of
250 seconds, that all data relevant to that Participant is deleted from the Report
Output Storage Buffer.
Verify that when this same Participant is re-introduced to the simulation that the
new set of data is stored in temporary storage and a new track file initiated with
none of the data from the previous track.
Step 2: Surface Mode 25 Participants
Set up a Surface scenario and simulation for a minimum of 25 Participants at

various ground speeds, initial positions and general direction of travel. Design
the simulation to include Participants that are traveling toward, away from, and
crossing in the vicinity of, the ADS-B Receiving Device. The simulation must
include random Participants that appear for a short period of time of not less than
fifteen (15), and not greater than twenty five (25) seconds, and then disappear
from the simulation altogether. This same Participant should be re-introduced to
the simulation after an absence of at least 500 seconds.
Configure the ADS-B Transmitting Subsystem simulation to transmit Version

Zero (0), Version One (1) and Version Two (2) Surface Position Messages,
Aircraft Identification and Category Messages, and Aircraft Operational Status
20xx, RTCA, Inc.

720
Messages, at a rate ensuring maximum transmission rate for a period of at least

twenty (20) minutes.
Initiate the simulation and verify that all received data for a given individual
Participant is being stored in temporary storage within a single track file. Verify
that each entry contains a time tag. Verify that for those Participants that are
continuing through out the simulation that updated information replaces old
information upon the receipt of the new information. Verify that for those
Participants that were introduced for a short period of time between 15 and 25
seconds that each track file for that Participant is retained for at least 250 seconds.
Verify that if no new messages are received for a given Participant for a period of
250 seconds, that all data relevant to that Participant is deleted from the Report
Output Storage Buffer.
Verify that when this same Participant is re-introduced to the simulation that the
new set of data is stored in temporary storage and a new track file initiated with
none of the data from the previous track.
Step 3: Airborne Mode 100 Participants
Repeat Step 1 above with a minimum of 100 individual Participants with various
individual altitudes, velocities, initial positions and general directions.
2.4.10.1.4 Verification of the Participant ADS-B Track Files (2.2.10.1.4)

This test procedure verifies that the ADS-B Report Assembly function maintains one, and
only one, Track File, i.e., set of reports on any given participant.
Verify that one, and only one Track file is created and maintained for each Participant.
2.4.10.2 Verification of the Report Assembly Initialization State (2.2.10.2)

Appropriate test procedures for verifying that the Report Assembly Function correctly
enters the Initialization State are provided in 2.4.10.1.3.
2.4.10.3 Verification of the Report Assembly Acquisition State (2.2.10.3)

20xx, RTCA, Inc.

721
2.4.10.3.1 Verification of the Report Assembly Acquisition State --- Airborne Participant
(2.2.10.3.1)
These test procedures verify that the Report Assembly Function properly establishes the
Acquisition State for an Airborne Participant, as specified in 2.2.10.3.1.
Step 1: Globally Unambiguous CPR Decode
a. For each test case in Table 2.4.10.3.1, provide the CPR Decoder function with
the odd and even Airborne Encodings. Provide the odd and even
Encodings to the CPR Decoder function (see A.1.7.7 of Appendix A) within
ten (10) seconds of each other.
Table 2.4.10.3.1: Input Data for Global Unambiguous Airborne Decode Zone Checks
Input Data for Global Unambiguous Airborne Decode Zone Checks
Angular Weighted Binary (AWB) Position Even Airborne Odd Airborne
of the Encoder in Degrees Encoding Encoding
Test Latitude Longitude Lat. Lon. NL Lat. Lon. NL
Case (Decimal) (HEX) (Decimal) (HEX) (HEX) (HEX) (Dec.) (HEX) (HEX) (Dec.)
1 -27.93897726 EC21DD4A 153.00998 6CCE9DE7 0AFE0 10D8D 53 0D79C 033F0 53
2 27.938976 13DE22A7 45.0000 20000000 15020 14000 53 12864 10000 53
3 -27.93897726 EC21DD4A 153.00998 6CCE9DE7 0AFE0 033F0 52 0D79C 033F0 53
4 -27.93897726 EC21DD4A 153.00998 6CCE9DE7 0AFE0 10D8D 53 0D79C 15A53 52
5 -27.93897726 EC21DD4A 153.00998 6CCE9DE7 0AFE0 033F0 52 0D79C 15A53 52
b. For test cases 1 and 2 in Table 2.4.10.3.1, verify that the CPR Decoder
function (see A.1.7.7 of Appendix A) provides an output latitude position
within 0.00015 degrees of the latitude position indicated for test cases 1 and
2.
c. For test cases 1 and 2 in Table 2.4.10.3.1, verify that the CPR Decoder
function (see A.1.7.7 of Appendix A) provides an output longitude position
within 0.00015 degrees of the longitude position indicated for test cases 1
and 2.
d. For test case 3 in Table 2.4.10.3.1, verify that the CPR Decoder function (see
A.1.7.7 of Appendix A) does not provide an output longitude position that
is consistent with the longitude position indicated for test case 3.
Note: The even encoding for test case 3 has been established by forcing
the NL lookup to 52 for encoding as opposed to 53. This will result
in significant error in the decoded position.
20xx, RTCA, Inc.

722
e. For test case 4 in Table 2.4.10.3.1, verify that the CPR Decoder function (see
A.1.7.7 of Appendix A) does not provide an output longitude position
consistent with the longitude position indicated for test case 4.
Note: The odd encoding for test case 4 has been established by forcing
f. For test case 5 in Table 2.4.10.3.1, verify that the CPR Decoder function (see
Note: The odd and even encodings for test case 5 have been
established by forcing the NL lookup to 52 for encoding as opposed
to 53. This will result in the Decoder Function selecting NL odd
equal to NL even and will produce what appears to be a valid
decode of the position. However, the decoded position will not be
consistent with the position indicated for test case 5 in Table
2.4.10.3.1.
g. Using the Airborne scenario and simulation set up in Step 1 of 2.4.10.1.3

above, verify that for each Participant for which an even and an odd pair
of encoded Airborne Position Messages is received within a ten (10) second
period that the Report Assembly Function correctly performs a successful
Globally Unambiguous CPR Decode in accordance with A.1.7.7 of
Appendix A.
h. Add an Airborne Participant to the simulation whose decoded position is

beyond the maximum operating range of the Own Ship position. Verify that
the Report Mode of the Airborne Participant is returned to the Initialization
State and that no State Vector Report is output. Verify that the remaining
Airborne Participant tracks are not terminated because of the distance
validation. Discontinue Own Ship position data so it is not available, and
verify that no tracks are discarded by the position validation. Some of the
simulation participants may be terminated due to lack of update.
Step 2: Report Mode set to Acquisition
Verify that for each Participant in the Airborne scenario and simulation set up in
Step 1 of 2.4.10.1.3 above, where you have verified in Step 1 above that an
even and an odd encoded Airborne Position Message was received within a
ten (10) second period that the Report Assembly Function correctly sets the
Report Mode to Acquisition in the State Vector Report in accordance with the
formatting specified in 2.2.8.1.22.
Step 3: State Vector Report Creation
ten (10) second period that the Report Assembly Function correctly structures all
20xx, RTCA, Inc.

723
possible fields of the State Vector Report for the given Airborne Participant in
accordance with 2.2.8.1 (all subsections inclusive).
Step 4: Report Output Storage Buffer Initialization
ten (10) second period that the Report Assembly Function correctly delivers the
first structured State Vector Report for the given Airborne Participant to the
Report Output Storage Buffer for subsequent access by the Application Interface,
within 500 milliseconds of receipt of the second Airborne Position Message of the
even and odd pair for the given Airborne Participant.
Step 5: Maintenance of Report Output Storage Buffer
ten (10) second period that the Report Assembly Function correctly maintains the
integrity of the State Vector Report for the given Airborne Participant in the
Report Output Storage Buffer for at least 200 seconds unless:
a. replaced by an updated State Vector Report, or
b. no new messages have been received from a given Airborne Participant for a
period of 100 5 seconds, in which case, verify that all reports relevant to the
Airborne Participant Address have been deleted from the Report Output
Storage Buffer.
Step 6: New Globally Unambiguous CPR Decode
Report Output Storage Buffer for at least 200 seconds unless a new Airborne
Position Message is received within a 120 second period for the given Airborne
Participant.
Verify that when a new Airborne Position Message is received for a given
Airborne Participant within a 120 second period, that the Report Assembly
Function performs a new Globally Unambiguous CPR Decode as specified in Step
1 above and verify that the new information is correctly updated in the State
Vector Report and the Report Output Storage Buffer for the given Airborne
Participant.
Verify that when no new Airborne Position Message is received for a given
Airborne Participant within a 120 second period, that the Report Assembly
Function correctly sets the Report Mode to Initialization (No Report Generation
20xx, RTCA, Inc.

724
Capability mode) in the State Vector Report in accordance with the formatting in
2.2.8.1.22.
Step 7: Purge Participant from the Report Output Storage Buffer
Report Output Storage Buffer for at least 200 seconds unless replaced by an
updated State Vector Report for the given Airborne Participant
Verify that when no new Messages of any type have been received from a given
Airborne Participant for at least 200 seconds, that the Report Assembly Function
correctly deletes all reports relevant to the given Airborne Participant Address
from the Report Output Storage Buffer.
2.4.10.3.1.1 Verification of the Latency, Report Assembly Acquisition State --- Airborne
Participant (2.2.10.3.1.1)
This test procedure verifies that Step d in 2.2.10.3.1 is completed within 500
milliseconds of receipt of the second Airborne Position Message of the even and odd
pair.
Appropriate test procedures for the verification of this requirement are provided in
2.4.10.3.1, Step 4.
2.4.10.3.2 Verification of the Report Assembly Acquisition State --- Surface Participant
(2.2.10.3.2)
Acquisition State for a Surface Participant, as specified in 2.2.10.3.2.
Step 1: Globally Unambiguous CPR Decode
a. For each test case in Table 2.4.10.3.2, provide the CPR Decoder function with
the odd and even Surface Encodings. Provide the odd and even
Encodings to the CPR Decoder function (see A.1.7.8 of Appendix A) within
fifty (50) seconds of each other.
20xx, RTCA, Inc.

725
Table 2.4.10.3.2: Input Data for Global Unambiguous Surface Decode Zone Checks
Input Data for Global Unambiguous Surface Decode Zone Checks
Angular Weighted Binary (AWB)Position Even Surface Odd Surface
1 -27.93897726 EC21DD4A 153.00998 6CCE9DE7 0BF7F 03636 53 15E70 0CFC1 53
2 27.938976 13DE22A7 45.0000 20000000 14081 10000 53 0A190 00000 53
3 -27.93897726 EC21DD4A 153.00998 6CCE9DE7 0BF7F 0CFC1 52 15E70 0CFC1 53
4 -27.93897726 EC21DD4A 153.00998 6CCE9DE7 0BF7F 03636 53 15E70 1694C 52
5 -27.93897726 EC21DD4A 153.00998 6CCE9DE7 0BF7F 0CFC1 52 15E70 1694C 52
b. For test cases 1 and 2 in Table 2.4.10.3.2, verify that the CPR Decoder
function (see A.1.7.8 of Appendix A) provides an output latitude position
within 0.00015 degrees of the latitude position indicated for test cases 1 and
2.
c. For test cases 1 and 2 in Table 2.4.10.3.2, verify that the CPR Decoder
function (see A.1.7.8 of Appendix A) provides an output longitude position
within 0.00015 degrees of the longitude position indicated for test cases 1
and 2.
d. For test case 3 in Table 2.4.10.3.2, verify that the CPR Decoder function (see
Note: The even encoding for test case 3 has been established by forcing
e. For test case 4 in Table 2.4.10.3.2, verify that the CPR Decoder function (see
Note: The odd encoding for test case 4 has been established by forcing
f. For test case 5 Table 2.4.10.3.2, verify that the CPR Decoder function (see
Note: The odd and even encodings for test case 5 have been
established by forcing the NL lookup to 52 for encoding as opposed
to 53. This will result in the Decoder Function selecting NL odd
equal to NL even and will produce what appears to be a valid
decode of the position. However, the decoded position will not be
consistent with the position indicated for row 5 in Table 2.4.10.3.2.
20xx, RTCA, Inc.

726
g. Using the Surface scenario and simulation set up in Step 2 of 2.4.10.1.3

above, verify that for each Participant for which an even and an odd pair
of encoded Surface Position Messages is received within a twenty five (25)
second period that the Report Assembly Function correctly performs a
successful Globally Unambiguous CPR Decode in accordance with A.1.7.8
of Appendix A. Input surface targets with speeds greater than 25 knots and
verify that when even and odd Position Messages are spaced more than
25 seconds apart, that a successful Globally Unambiguous CPR Decode is not
completed for such targets. Input surface targets with speeds less than 25
knots that have even and odd Position Messages spaced between 25 and
50 seconds and verify that the Report Assembly Function correctly performs a
successful Globally Unambiguous CPR Decode in accordance with A.1.7.8
of Appendix A. Input surface targets with speeds less than 25 knots that have
even and odd Position Messages spaced greater than 50 seconds apart and
verify that the Report Assembly Function does not complete a successful
Globally Unambiguous CPR Decode for such targets.
h. Add a Surface Participant to the simulation whose decoded position is beyond

the maximum operating range of the Own Ship position. Verify that the
Report Mode of the Surface Participant is returned to the Initialization State
and that no State Vector Report is output. Verify that the remaining Surface
Participant tracks are not terminated because of the distance validation.
Discontinue Own Ship position data so it is not available and verify that no
tracks are discarded by the position validation. Some of the simulation
participants may be terminated because of lack of update.
Step 2: Report Mode set to Track
Verify that for each Participant in the Surface scenario and simulation set up in
even and an odd encoded Surface Position Message was received, within the
proper time interval based on the speed of the Participant, that the Report
Assembly Function correctly sets the Report Mode to Track in the State Vector
Report in accordance with the formatting specified in 2.2.8.1.22.
Step 3: State Vector Report Creation
Assembly Function correctly structures all possible fields of the State Vector
Report for the given Surface Participant in accordance with 2.2.8.1 (all
subsections inclusive).
Step 4: Report Output Storage Buffer Initialization
20xx, RTCA, Inc.

727
Assembly Function correctly delivers the first structured State Vector Report for
the given Surface Participant to the Report Output Storage Buffer for subsequent
access by the Application Interface, within 500 milliseconds of receipt of the
second Surface Position Message of the even and odd pair for the given
Surface Participant.
Assembly Function correctly maintains the integrity of the State Vector Report for
the given Surface Participant in the Report Output Storage Buffer for at least 200
seconds unless:
a. Replaced by an updated State Vector Report, or
b. No new messages have been received from a given Surface Participant for a
period of 100 5 seconds, in which case, verify that all reports relevant to the
Surface Participant Address have been deleted from the Report Output
Storage Buffer.
Step 6: New Locally Unambiguous CPR Decode
seconds unless a new Surface Position Message is received within a 120 second
period for the given Surface Participant.
Verify that when a new Surface Position Message is received for a given Surface
Participant within a 120 second period, that the Report Assembly Function
performs a new Locally Unambiguous CPR Decode as specified in Step 1 above
and verify that the new information is correctly updated in the State Vector Report
and the Report Output Storage Buffer for the given Surface Participant.
Step 7: Purge Participant from the Report Output Storage Buffer
seconds unless replaced by an updated State Vector Report for the given Surface
Participant.
20xx, RTCA, Inc.

728
Verify that when no new Messages of any type have been received from a given
Surface Participant for at least 200 seconds, that the Report Assembly Function
correctly deletes all reports relevant to the given Surface Participant Address from
2.4.10.3.2.1 Verification of the Latency, Report Assembly Acquisition State --- Surface Participant
(2.2.10.3.2.1)
Step d in 2.2.10.3.2 is to be completed within 500 milliseconds of receipt of the second

Surface Position Message of the even and odd pair.
Appropriate test procedures for the verification of this requirement are provided in
2.4.10.3.2, Step 4.
2.4.10.3.3 Verification of the Acquisition State Data Retention (2.2.10.3.3)

This test procedure verifies that the Report Assembly Function properly retains the ADS-B
Message data as specified in 2.2.10.3.3.
Upon receipt of any of the messages identified in 2.2.10.2 for any given Participant, verify
that the Report Assembly Function checks to ensure that it has not received one half (either
even or odd) of a position message pair from this Participant within a ten second period.
Verify that when the receipt of the message is determined to be the second half (either
even or odd) of a position message pair from this Participant, that the Report Assembly
Function uses the message as specified using the Test Procedures in 2.4.10.3.1 for
Airborne Participants, or 2.4.10.3.2 for Surface Participants.
If the receipt of the message is determined to NOT be the second half of a position message,
then verify that the Report Assembly Function uses the message as specified in using the
Test Procedures in 2.4.10.1.3.
2.4.10.4 Verification of the Report Assembly Track State (2.2.10.4)

2.4.10.4.1 Verification of the Report Assembly Track State - Airborne Participant (2.2.10.4.1)
20xx, RTCA, Inc.

729
2.4.10.4.1.1 Verification of the Report Assembly Track State Initialization - Airborne Participant
(2.2.10.4.1.1)
Track State for an Airborne Participant as specified in 2.2.10.4.1.1.
Step 1: Locally Unambiguous CPR Decode and Set the Report Mode to Track
a. For each test case in Table 2.4.10.4.1.1, provide the CPR Decoder function
(see A.1.7.5 of Appendix A) with the odd and even Airborne Encodings
within five (5) seconds of each other.
Table 2.4.10.4.1.1: Input Data for Local Unambiguous Airborne Decode Zone Checks
Input Data for Local Unambiguous Airborne Decode Zone Checks
Angular Weighted Binary (AWB)Position Even Airborne Odd Airborne
1 -27.93897726 EC21DD4A 153.00998 6CCE9DE7 0AFEO 10D8D 53 0D79C 033F0 53
b. Verify that the CPR Decoder function (see A.1.7.5 of Appendix A) provides
an even and odd output latitude position within 0.00015 degrees of the
latitude position indicated for the test case in Table 2.4.10.4.1.1.
c. Verify that the CPR Decoder function (see A.1.7.5 of Appendix A) provides
an even and odd output longitude position within 0.00015 degrees of the
longitude position indicated for the test case in Table 2.4.10.4.1.1.
d. Start this test procedure step with the assumption that for a given Airborne
Participant, the Acquisition State has been established in accordance with the
Test Procedures in 2.4.10.3.1.
Verify that for each Participant in the Airborne scenario and simulation set up
in Step 1 of 2.4.10.1.3 above, where you have verified that the Acquisition
State has been established, and upon receipt of the first Airborne Velocity
Message for the given Participant, verify that the Report Assembly Function
correctly sets the Report Mode to Track in the State Vector Report in
accordance with the formatting in 2.2.8.1.22.
Step 2: Update State Vector Report
Step 1 of 2.4.10.1.3 above, where you have verified that the Acquisition State
has been established, and upon receipt of the first Airborne Velocity Message for
20xx, RTCA, Inc.

730
the given Participant, verify that the Report Assembly Function correctly
structures all possible fields in the State Vector Report in accordance with
2.2.8.1(all subsections inclusive).
Step 3: Update the Report Output Storage Buffer
structures all possible fields in the State Vector Report in accordance with 2.2.8.1
(all subsections inclusive).
Verify that the updated State Vector Report is delivered to the Report Output
Storage Buffer within 500 milliseconds of the receipt of the first Airborne
Velocity Message for the given Participant.
maintains the integrity of the State Vector Report for the given Participant in the
Report Output Storage Buffer for a period of 100 5 seconds unless replaced by
an updated State Vector Report.
Step 5: Initiate Assembly of the Mode Status Report
a. Upon receipt of the first Airborne Velocity Message from the Participant, and
the Track State has been entered as in Steps 1 through 3 above, verify that
the Report Assembly Function initiates a complete review of all messages
received for the given Participant that have been placed in temporary storage
in accordance with 2.2.10.1.3.
b. Upon completion of the review of all messages for the given Participant,
verify that the Report Assembly Function correctly structures all possible
fields of the Mode Status Report for the given Participant in accordance with
2.2.8.2 (all subsections inclusive).
c. Verify that the Mode Status Report is delivered to the Report Output Storage
Buffer within 500 milliseconds of the receipt of the first Airborne Velocity
Message that caused the initialization of the Track State for the given
Participant.
d. Verify that the integrity of the Mode Status Report is maintained for the given
Participant in the Report Output Storage Buffer for a period of 100 5
seconds, unless replaced by an updated Mode Status Report for that
Participant.
20xx, RTCA, Inc.

731
Step 6: Initiate Assembly of ADS-B Target State Report
a. Upon receipt of the first Airborne Velocity Message from the Participant, and
the Track State has been entered as in Steps 1 through 3 above, verify that
the Report Assembly Function initiates a complete review of all messages
received for the given Participant that have been placed in temporary storage
in accordance with 2.2.10.1.3.
b. Upon completion of the review of all messages for the given Participant,
verify that the Report Assembly Function correctly structures all possible
fields of the ADS-B Target State Report for the given Participant in
c. Verify that the ADS-B Target State Report is delivered to the Report Output
Storage Buffer within 500 milliseconds of the receipt of the first Airborne
Velocity Message that caused the initialization of the Track State for the
given Participant.
d. Verify that the integrity of the ADS-B Target State Report is maintained for
the given Participant in the Report Output Storage Buffer for a period of 100
5 seconds, unless replaced by an updated ADS-B Target State Report for that
Participant.
2.4.10.4.1.2 Verification of the Report Assembly Track State Maintenance - Airborne Participant
(2.2.10.4.1.2)
These test procedures verify that the Track State is maintained for a given Airborne
Participant for as long as Airborne Position Messages (see 2.2.3.2.3) and Airborne
Velocity Messages (see 2.2.3.2.6) are being received from the Participant, as specified in
2.2.10.4.1.2.
Step 1: Receipt of a new Airborne Position Message
Step 1 of 2.4.10.1.3 above, where you have verified that the Track State has been
established, and upon the receipt of a new Airborne Position Message for the
given Participant, verify that the Report Assembly Function correctly:
a. performs a locally unambiguous CPR decode of the Airborne Participant

position in accordance with A.1.7.4 and A.1.7.5 of Appendix A, and that
the reasonableness test defined in 2.2.10.6.3 is performed, and that the track
is updated if the difference in the position decodes resulting from the
reasonableness test are less than or equal to 6 NM, if the last Position Message
received was an Airborne Position Message, or less than or equal to 2.5 NM if
the last Position Message received was a Surface Position Message.
20xx, RTCA, Inc.

732
However, if the difference between the TOMRs of the previously received

Position Message and the most recently received Position Message is 30
seconds or less, and the reported position in the most recently received
Position Message differs from the previously reported position by more than
6 NM if the last Position Message received was an Airborne Position
Message, or more than 2.5 NM if the last Position Message received was a
Surface Position Message, then the most recently received position is not
b. updates all possible fields of the State Vector Report for the given Airborne
c. delivers the updated State Vector Report to the Report Output Storage Buffer
within 500 milliseconds of the receipt of the new Airborne Position Message.
d. maintains the integrity of the State Vector Report for the given Airborne
replaced by an updated State Vector Report.
Step 2: Receipt of a new Airborne Velocity Message
established, and upon the receipt of a new Airborne Velocity Message for the
given Participant, verify that the Report Assembly Function correctly:
a. updates all possible fields of the State Vector Report for the given Airborne
b. delivers the updated State Vector Report to the Report Output Storage Buffer
within 500 milliseconds of the receipt of the new Airborne Velocity Message.
c. maintains the integrity of the State Vector Report for the given Airborne
replaced by an updated State Vector Report.
Step 3: Receipt of other Messages while in Track State and Creating a Mode Status
established, and upon the receipt of a new Aircraft Identification and Category
Message, Target State and Status Message, Aircraft Operational Status Message,
or Aircraft Status Message for the given Participant, verify that the Report
Assembly Function correctly:
a. updates all possible fields of the Mode Status Report for the given Airborne
b. delivers the updated Mode Status Report to the Report Output Storage Buffer
within 500 milliseconds of the receipt of the new Message.
20xx, RTCA, Inc.

733
c. maintains the integrity of the Mode Status Report for the given Airborne
replaced by an updated Mode Status Report.
Step 4: Creating a Target State Report
established, and upon the receipt of a new Target State and Status Message having
Target State information, for the given Participant, verify that the Report
Assembly Function correctly:
a. updates all possible fields of the Target State Report for the given Airborne
b. delivers the updated Target State Report to the Report Output Storage Buffer
c. maintains the integrity of the Target State Report for the given Airborne
replaced by an updated Target State Report.
Step 5: Creating an Air Referenced Velocity Report
Verify that for each participant in the Airborne scenario and simulation set up in
Step 1 of 2.4.10.1.3 above, where you have verified that Track State has been
established, and upon the receipt of a new Airborne Velocity Message, Subtype 3
or 4 containing Air Referenced Velocity information for the given Participant,
verify that the Report Assembly Function correctly:
a. updates all possible fields of the Air Referenced Velocity Report for the given
Airborne Participant in accordance with 2.2.8.3.2 (all subparagraphs
inclusive).
b. updates all possible fields of the Air Referenced Velocity Report to the Report
Storage Buffer within 500 milliseconds of the receipt of the new message.
c. maintains the integrity of the Air Referenced Velocity Report for the given
Airborne Participant in the Report Storage Buffer for 100 5 seconds, unless
replaced by an updated Air Referenced Velocity Report.
2.4.10.4.1.3 Verification of the Report Assembly Track State Termination - Airborne Participant
(2.2.10.4.1.3)
These test procedures verify that the Report Assembly Function properly terminates the
Track State for an Airborne Participant as specified in 2.2.10.4.1.3.
20xx, RTCA, Inc.

734
Step 1: TYPE Equal ZERO Altitude Data Available
For random Participants in the Airborne scenario and simulation set up in Step 1
of 2.4.10.1.3 above, where you have verified that the Track State has been
established, induce Airborne Position Messages with the TYPE subfield set to
ZERO, and with all 56 bits of the ME field set to ZEROs, except that the
Barometric Altitude subfield is filled with valid data in accordance with
2.2.3.2.3.4.3.
Verify that for these Participants that the Report Assembly Function correctly
updates the State Vector Report with the received Barometric Altitude. Verify
that the Barometric Altitude Validity Flag, i.e., bit #3 of byte #4 of the State
Vector Report was correctly set to ONE, indicating valid Altitude data.
Step 2: TYPE Equal ZERO No Altitude Data Available
For random Participants in the Airborne scenario and simulation set up in Step 1
of 2.4.10.1.3 above, where you have verified that the Track State has been
established, induce Airborne Position Messages with the TYPE subfield set to
ZERO, and with all 56 bits of the ME field set to ZEROs.
Verify that for these Participants that the Report Assembly Function correctly
discards the received Airborne Position Message and that no change is made to the
State Vector Report as a result of the receipt of this Airborne Position Message
with TYPE equal ZERO and all other ME field bits set to ZERO.
Step 3: Track State Termination
For each Participant in the Airborne scenario and simulation set up in Step 1 of
2.4.10.1.3 above, where you have verified that the Track State has been
established, if no Airborne Position or Airborne Velocity Message has been
received from the Participant for 25 5 seconds, then verify that for each
Participant that the Track State is terminated by deleting all State Vector Reports,
Mode Status Reports and ADS-B Target State Reports that were placed in the
Report Output Storage Buffer for the given Participant.
Also verify that for this Participant that the Report Assembly Function correctly
returns to the Acquisition State as specified in 2.2.10.3.1. Verify that the Report
Mode Flag is set to Acquisition in the State Vector Report in accordance with
the encoding specified in 2.2.8.1.22.
2.4.10.4.2 Verification of the Report Assembly Track State - Surface Participant (2.2.10.4.2)
20xx, RTCA, Inc.

735
2.4.10.4.2.1 Verification of the Report Assembly Track State Initialization - Surface Participant
(2.2.10.4.2.1)
These test procedures verify the proper initialization of the Track State for a given Surface
Participant as established in accordance with 2.2.10.3.2, as well as the assembly of Mode
Status Reports as specified in 2.2.10.4.2.1.
Step 1: Locally Unambiguous CPR Decode
a. For each test case in Table 2.4.10.4.2.1, provide the CPR Decoder function
(see A.1.7.6 of Appendix A) with the odd and even Surface Encodings
within five (5) seconds of each other.
Table 2.4.10.4.2.1: Input Date for Local Unambiguous Surface Decode Zone Check
Input Data for Local Unambiguous Surface Decode Zone Checks
Angular Weighted Binary (AWB)Position Even Surface Odd Surface
1 -27.93897726 EC21DD4A 153.00998 6CCE9DE7 0BF7F 03636 53 15E70 0CFC1 53
b. Verify that the CPR Decoder function (see A.1.7.6 of Appendix A) provides
an even and odd output latitude position within 0.00015 degrees of the
latitude position indicated for the test case in Table 2.4.10.4.2.1.
c. Verify that the CPR Decoder function (see A.1.7.6 of Appendix A) provides
an even and odd output longitude position within 0.00015 degrees of the
longitude position indicated for the test case in Table 2.4.10.4.2.1.
Step 2: Track State Initialization
a. Upon receipt of an even and odd encoded Surface Position Message from
a given Surface Participant within a fifty (50) second period, verify that the
Report Assembly Function correctly sets the Report Mode to Track in
accordance with the formatting in 2.2.8.1.22.
b. Further verify that the Report Assembly Function initiates a complete review
of all messages received for the given Surface Participant that have been
placed in temporary storage in accordance with 2.2.10.1.3.
Upon completion of the review of all messages for the given Surface
Participant, verify that the Report Assembly Function correctly structures all
possible fields of the Mode Status Report for the given Surface Participant in
20xx, RTCA, Inc.

736
c. Verify that the Mode Status Report is delivered to the Report Output Storage
Buffer within 500 milliseconds of the receipt of the second half of that
even/odd pair of Surface Position Messages that caused the initialization of
the Track State for the given Surface Participant.
d. Verify that the integrity of the Mode Status Report is maintained for the given
Surface Participant in the Report Output Storage Buffer for a period of 100 5
seconds, unless replaced by an updated Mode Status Report for that
Participant.
2.4.10.4.2.2 Verification of the Report Assembly Track State Maintenance - Surface Participant
(2.2.10.4.2.2)
These test procedures verify that the Track State is maintained for a given Surface
Participant for as long as Surface Position Messages (see 2.2.3.2.4) are being received
from the Surface Participant as specified in 2.2.10.4.2.2.
Step 1: Receipt of a new Surface Position Message
Verify that for each Surface Participant in the Surface scenario and simulation set
up in Step 2 of 2.4.10.1.3 above, where you have verified that the Track State
has been established, and upon the receipt of a new Surface Position Message for
the given Participant, verify that the Report Assembly Function correctly:
a. performs a locally unambiguous CPR decode of the Surface Participant

position in accordance with A.1.7.4 and A.1.7.5 of Appendix A, and that
the reasonableness test defined in 2.2.10.6.3 is performed and that the track
is updated if the difference in the position decodes resulting from the
reasonableness test are less than or equal to 0.75 NM if the last Position
Message received was a Surface Position Message, or less than or equal 2.5
NM if the last Position Message received was an Airborne Position Message.
However, if the difference between the TOMRs of the previously received

Position Message and the most recently received Position Message is 30
seconds or less, and the reported position in the most recently received
Position Message differs from the previously reported position by more than
0.75 NM, if the last Position Message received was a Surface Position
Message, or more than 2.5 NM if the last Position Message received was an
Airborne Position Message, then the most recently received position is not
b. updates all possible fields of the State Vector Report for the given Surface
20xx, RTCA, Inc.

737
c. delivers the updated State Vector Report to the Report Output Storage Buffer
within 500 milliseconds of the receipt of the new Surface Position Message
for the given Participant.
d. maintains the integrity of the State Vector Report for the Surface Participant
in the Report Output Storage Buffer for 100 5 seconds unless replace by an
updated State Vector Report.
Step 2: Receipt of other Messages while in Track State and Creating a Mode Status
Verify that for each Surface Participant in the Surface scenario and simulation set
up in Step 2 of 2.4.10.1.3 above, where you have verified that the Track State
has been established, and upon the receipt of a new Aircraft Identification and
Category Message, Aircraft Operational Status Message, or Aircraft Status
Message for the given Surface Participant, verify that the Report Assembly
Function correctly:
a. updates all possible fields of the Mode Status Report for the given Surface
b. delivers the updated Mode Status Report to the Report Output Storage Buffer
c. maintains the integrity of the Mode Status Report for the given Surface
replaced by an updated Mode Status Report.
2.4.10.4.2.3 Verification of the Report Assembly Track State Termination - Surface Participant
(2.2.10.4.2.3)
This test procedure verifies that the Report Assembly Function properly terminates the
Track State for a Surface participant as specified in 2.2.10.4.2.3.
For each Surface Participant in the Surface scenario and simulation set up in Step 2 of
2.4.10.1.3 above, where you have verified that the Track State has been established, if no
Surface Position Message has been received from the Surface Participant for 225 5
seconds, then verify that for each Surface Participant that the Track State is terminated by
deleting all State Vector Reports and Mode Status Reports that were placed into the Report
Output Storage Buffer for the given Surface Participant.
Also verify that for this Participant that the Report Assembly Function correctly returns to
the Acquisition State as specified in 2.2.10.3.2. Verify that the Report Mode Flag is set to
Acquisition in the State Vector Report in accordance with the encoding specified in
2.2.8.1.22.
20xx, RTCA, Inc.

738
2.4.10.5 Verification of the Minimum Number of Participant Track Files (2.2.10.5)

These test procedures verify that the ADS-B Receiving Subsystem is capable of maintaining
a minimum number of track files as specified in Table 2-105 for a given equipage class, and
is properly managing the ability to discard track files if capacity is exceeded, as specified in
2.2.10.5.
Step 1: Track File Scenario Selection and Initialization
Refer to Table 2-203, below, for information required in the following paragraphs.
Select the Class of ADS-B Receiving Subsystem that is being tested from the far
left column (0) of the table.
For the Class of ADS-B Receiving Subsystem selected, establish an Airborne

scenario and simulation for the minimum number of participants shown in column
2 of the table. Select various altitudes, velocities, initial positions, and general
directions for the participants such that all participants remain within the column 1
given range of the ADS-B receiving equipment under test. Maintain the same
number of participants within the column 1 given range of the ADS-B receiving
equipment under test for a duration of at least 20 minutes to ensure full execution
of the test.
For the Class of ADS-B Receiving Subsystem selected, establish additional

Airborne scenarios and simulations for the minimum number of participants
shown in column 4 of the table. Select various altitudes, velocities, initial
positions, and general directions for the participants such that all participants
remain within the column 3 given range boundary from the ADS-B receiving
equipment under test. Maintain the same number of participants within the
column 3 given range boundary for at least 20 minutes to ensure full execution of
the test.
Table 2-203: Participant Track File Stimulus Requirements

Column (0) 1 2 3 4
Number of Extended Range Number of
Equipage Class of Range (NM) for
Participant Track (NM) for ADS-B Participant Track
ADS-B Receiving ADS-B
Files Within Receiving Class Files Within
Subsystem Receiving Class
Range (min -to- max) Extended Range
A0 10 100 10 -to- 15 50
A1S and A1 20 200 20 -to- 30 100
A2 40 400 40 -to- 60 200
A3 60 400 60 -to- 90 200
Step 2: Track File Scenario Selection and Initialization
Initiate the simulation and verify that the ADS-B Report Generator function of the
ADS-B Receiving Subsystem under test properly generates and delivers the
20xx, RTCA, Inc.

739
appropriate State Vector, Mode Status, and Target State Reports for each
Participant that is being tracked.
For the Class of ADS-B Receiving Subsystem under test, verify that the ADS-B
Report Generator function maintains appropriate track files on the minimum
number of participants provided in column 2 of Table 2-203. Regardless of the
track file capacity of the ADS-B Receiving Subsystem under test, verify that any
track files discarded are for participants at greater range than those retained.
2.4.10.6 Verification of Reasonableness Tests for CPR Decoding of Received Position Messages
(2.2.10.6)
2.4.10.6.1 Verification of Reasonableness Test Overview (2.2.10.6.1)

2.4.10.6.2 Verification of Reasonableness Test Applied to Positions Determined from Globally

Unambiguous CPR Decoding (2.2.10.6.2)
These test procedures verify that the proper validation is being performed to verify the
Globally Unambiguous CPR decode established per 2.2.10.3.1, subparagraph a or
2.2.10.3.2, subparagraph a, using the steps specified in 2.2.10.6.2.
Step 1: Airborne Target Setup
Set up the Test Generator to input to the receiver an Airborne Participant encoded
using the following Messages to demonstrate proper position validation
processing:
Test inputs:
Pair 1: A Position Message set consisting of first an even and then an odd
Position Message, both encoded with the same NL value that produces a Globally
Unambiguous CPR decode within the maximum operating range of the receiver,
and both input to the receiver within 10 seconds of each other.
Position Message, both encoded with the same NL value but different than Pair 1
that produces a Globally Unambiguous CPR decode within the maximum
operating range of the receiver, and both input to the receiver within 10 seconds of
each other.
Along with the Position Messages, configure the target to output Airborne
Velocity, Aircraft ID and Type Messages and Aircraft Operational Status
Messages beginning at the same time the input of the Position Messages in the
steps below and at the proper Airborne transmit rate.
20xx, RTCA, Inc.

740
Step 2: Verify Airborne Position Not Validated
Input a Pair 1 and verify that a State Vector Report is generated by the receipt of
the odd Position Message of Pair 1. Input a Pair 2 and verify that no State
Vector Report is output by the receipt of the odd Position Message or by the
receipt of Airborne Velocity Messages after Pair 2.
Step 3: Verify Airborne Position Validated Case 1
Input a Pair 1 and verify that a State Vector Report consistent with the Globally
Unambiguous CPR position of Pair 1 is generated by the receipt of the odd
Position Message of Pair 1. Input a Pair 2 and verify that no State Vector Report
is output by the receipt of the odd Position Message. Repeat input of Pair 1 and
verify that no State Vector Report is output by the receipt of the even Position
Message and that a State Vector Report consistent with the Globally
Position Message. Repeat input of Pair 1 and verify that each Position and
Velocity Message received results in a State Vector Report with position
consistent with the Globally Unambiguous CPR position of Pair 1.
Step 4: Verify Airborne Position Validated Case 2
Position Message. Repeat input of Pair 2 and verify that each Position and
Velocity Message received results in a State Vector Report with position
consistent with the Globally Unambiguous CPR position of Pair 2.
Step 5: Surface Target Setup
Set up the Test Generator to input to the receiver a Surface Participant encoded
using the following Messages to demonstrate proper position validation
processing:
Test inputs:
Position Message, both encoded with the same NL value that produces a Globally
Unambiguous CPR decode within the maximum operating range of the receiver,
and both input to the receiver within 25 seconds of each other.
Position Message, both encoded with the same NL value but different than Pair 1
that produces a Globally Unambiguous CPR decode within the maximum
operating range of the receiver, and both input to the receiver within 25 seconds of
each other.
20xx, RTCA, Inc.

741
Along with the Position Messages, configure the target to output Aircraft ID and
Type Messages and Aircraft Operational Status Messages beginning at the same
time the input of the Position Messages in the steps below and at the proper
Surface transmit rate.
Step 6: Verify Surface Position Not Validated
Input a Pair 1 and verify that a State Vector Report is generated by the receipt of
the odd Position Message of Pair 1. Input a Pair 2 and verify that no State
Vector Report is output by the receipt of the odd Position Message.
Step 7: Verify Surface Position Validated Case 1
Position Message. Repeat input of Pair 1 and verify that each Position Message
received results in a State Vector Report with position consistent with the
Globally Unambiguous CPR position of Pair 1.
Step 8: Verify Surface Position Validated Case 2
Position Message. Repeat input of Pair 2 and verify that each Position Message
received results in a State Vector Report with position consistent with the
Globally Unambiguous CPR position of Pair 2.
2.4.10.6.3 Verification of Reasonableness Test Applied to Positions Determined from Locally

Unambiguous CPR Decoding (2.2.10.6.3)
These test procedures verify that the proper validation is being performed to verify the
Locally Unambiguous CPR decode established per 2.2.10.4.1.2, subparagraph a.(1) for
Airborne Participants, or 2.2.10.4.2.2, subparagraph a.(1) for Surface Participants, using
the steps specified in 2.2.10.6.3.
20xx, RTCA, Inc.

742
Step 1: Airborne Target Setup
Set up the Test Generator to transmit an ADS-B Airborne Position Message with
an even format containing the exact latitude and longitude data pair provided in
the following table. Within 10 seconds, input another ADS-B Airborne Position
Message with odd format containing the exact latitude and longitude data pair
provided in the following table.
CPR Decoded Decoded

Lat Lon XZ YZ
Format Lat Lon
0 38.99836 -74 71361 65500
1 38.99836 -74 98304 51301 38.998346 -74.000000
Verify that a Global CPR Decode has occurred and that the output of the ADS-B
State Vector Report matches the corresponding values in the above table.
Input another ADS-B Airborne Position Message to the Receiving Subsystem

with even format and data as provided in the following table.
CPR Decoded Decoded

Lat Lon XZ YZ
Format Lat Lon
0 39.0000 -74.0000 71361 65536 39.000000 -74.000025
Verify that the output of the ADS-B State Vector Report matches the
corresponding values in the above table.
Step 2: Verification of Reasonableness Test with Distance Greater Than 6 NM
Input another ADS-B Airborne Position Message pair with even and odd
formats containing the exact latitude and longitude data pair provided in the
following table.
Delta
CPR Decoded Decoded
Lat Lon XZ YZ Distance
Format Lat Lon
(NM)
0 39.099888 -73.998536 71386 67718 39.099884 -73.998533 6.004688
1 39.099888 -73.998536 98328 53482 39.099876 -73.998535 6.004220
Verify that the reception of either of the Position Messages does not produce
updates to the established Participant Track nor the output of an ADS-B State
Vector Report.
20xx, RTCA, Inc.

743
Step 3: Verification of Reasonableness Test with Distance Less Than 6 NM
Input an ADS-B Airborne Position Message pair with even and odd formats
containing the exact latitude and longitude data pair provided in the following
table.
Delta
CPR Decoded Decoded
Format Lat Lon
(NM)
0 39.099788 -73.997803 71398 67716 39.099792 -73.997816 5.999666
1 39.099788 -73.997803 98340 53480 39.099783 -73.997803 5.999118
Verify that the reception of both of these Position Messages does produce updates
to the established Participant Track and the output of an ADS-B State Vector
Report matches the corresponding values in the table above.
Step 4: Verification of Reasonableness Test with Timing Test
Rerun the test procedure in Step 2 above using the same Latitude and Longitude
values, but with a difference between the TOMRs of the previously received
Position Message and the most recently received Position Message at a value
greater than 30 seconds. Verify that the reception of each of these Position
Messages does produce updates to the established Participant Track and the output
of an ADS-B State Vector Report matches the corresponding values in the Step 2
table.
Step 5: Verification of Proper Timer Reset
Rerun the Airborne Target Setup as in Step 1 above. With the Global CPR
Decode having been established, input an Airborne Position Message at what will
become Time=0 with the parameters shown in the following table.
Injection Delta
CPR Decoded Decoded
Timing Lat Lon XZ YZ Distance
Format Lat Lon
(seconds) (NM)
0 0 39.099788 -73.997803 71398 67716 39.099792 -73.997816 5.999666
18 1 39.099888 -73.998536 98328 53482 39.099876 -73.998535 6.004220
40 0 39.099888 -73.998536 71386 67718 39.099884 -73.998533 6.004688
Verify that the reception of the initial Position Message at Time=0 does produce
updates to the established Participant Track and that the output of the ADS-B
Input an Airborne Position Message at Time=18 with the parameters shown in the
above table. Verify that the reception of this Position Message does not produce
updates to the established Participant Track, nor the output of an ADS-B State
Vector Report.
20xx, RTCA, Inc.

744
Input an Airborne Position Message at Time=40 with the parameters shown in the
above table. Verify that the reception of this Position Message does produce
updates to the established Participant Track and that the output of the ADS-B
Step 6: Surface Target Setup
Set up the Test Generator to transmit an ADS-B Surface Position Message with
the even format containing the exact latitude and longitude data pair provided in
the following table. Within 10 seconds, input another ADS-B Surface Position
Message with odd format containing the exact latitude and longitude data pair
provided in the following table.
CPR Decoded Decoded

Lat Lon XZ YZ
Format Lat Lon
0 38.99836 -74 23302 130929
1 38.99836 -74 0 74133 38.998357 -74.000000
Verify that a Global CPR Decode has occurred and that the output of the ADS-B
Input another ADS-B Surface Position Message to the Receiving Subsystem with
even format and data as provided in the following table.
CPR Decoded Decoded

Lat Lon XZ YZ
Format Lat Lon
0 39.0000 -74.0000 23302 0 39.000000 -73.999995
Verify that the output of the ADS-B State Vector Report matches the
corresponding values in the above table.
Step 7: Verification of Reasonableness Test with Distance Greater Than 0.75 NM
Input an ADS-B Airborne Position Message pair with even and odd formats
table.
Delta
CPR Decoded Decoded
Format Lat Lon
(NM)
0 39.061486 -73.99817 23424 5373 39.061489 -73.998174 3.697247
1 39.061486 -73.99817 120 79557 39.061482 -73.998169 3.696844
Verify that the reception of either of these Position Messages does not produce
updates to the established Participant Track nor the output of an ADS-B State
Vector Report.
20xx, RTCA, Inc.

745
Step 8: Verification of Reasonableness Test with Distance Less Than 0.75 NM
Input an ADS-B Surface Position Message pair with even and odd formats
table.
Delta
CPR Decoded Decoded
Format Lat Lon
(NM)
0 39.01028 -73.99817 23424 898 39.010277 -73.998174 0.623613
1 39.01028 -73.99817 120 75157 39.010275 -73.998169 0.623531
Verify that each of these Position Messages does produce updates to the
established Participant Track and the output of an ADS-B State Vector Report
matches the corresponding values in the table above.
Step 9: Verification of Reasonableness Test with Timing Test
Rerun the test procedure in Step 7 above using the same Latitude and Longitude
values, but with a difference between the TOMRs of the previously received
Position Message and the most recently received Position Message at a value
greater than 30 seconds. Verify that the reception of each of these Position
Messages does produce updates to the established Participant Track and the output
of an ADS-B State Vector Report matches the corresponding values in the Step 7
table.
2.4.11 Verification of Self Test and Monitors (2.2.11)

2.4.11.1 Verification of Self Test (2.2.11.1)

These test procedures verify that self test transmissions from ADS-B Transmitting
Subsystem comply with the requirements of 2.2.11.1.
Equipment Required:
equipment under test. Provide a Wide Band Dual Channel Oscilloscope (HP 1710, or
equivalent). Provide a method of detecting and monitoring ADS-B broadcast messages.
20xx, RTCA, Inc.

746
ADS-B transmissions occur. Monitor all ADS-B broadcast messages for the occurrence of a
TYPE Code = 23.
Measure the single pulse in the TYPE Code = 23 message that has the highest RF
power and verify that the power does not exceed -40 dBm. Verify that the average rate of
the TYPE Code = 23 messages does not exceed one in a 10 second interval.
2.4.11.2 Verification of Broadcast Monitoring (2.2.11.2)

2.4.11.2.1 Verification of Transponder-Based Equipment Broadcast Monitoring (2.2.11.2.1)

These test procedures verify that the ADS-B Transmitting Subsystem properly enunciates
the Fail/Warn state if DF=17 transmissions do not occur at the rates specified in 2.2.3.3
through 2.2.3.3.2.10.
In order to not induce unnecessary intermittent Fail/Warn declarations, the squitter monitor
shall implement appropriate debounce and recovery techniques provided for in Table 2-
2.4.11.2.1. In these regards, debounce refers to the number of successive maximum
transmit intervals that a particular squitter message can be missed (e.g., not transmitted) plus
an additional time of 100 milliseconds to process and activate the Fail/Warn mechanism.
Likewise, recovery refers to the number of successive maximum transmit intervals within
which a particular squitter message must be transmitted plus 100 milliseconds to process
and de-activate the Fail/Warn mechanism.
20xx, RTCA, Inc.

747
Table 2-2.4.11.2.1: Extended Squitter Monitor Time Allocation

Maximum Maximum
Number of Number of
Transmit Time to Time to
1090ES Intervals to Intervals to
Interval Declare Clear
Message Type Declare Clear
(seconds) Fail/Warn Fail/Warn
Fail/Warn Fail/Warn
(seconds) (seconds)
Airborne Position 0.4 to 0.6 1.9 2 1.9 3
Airborne Velocity 0.4 to 0.6 1.9 2 1.9 3
Aircraft Identification and Category 4.8 to 5.2 15.7 3 5.3 1
Aircraft Identification and Category 9.8 to 10.2 30.7 3 10.3 1
Surface Position 0.4 to 0.6 1.9 2 1.9 3
Surface Position 4.8 to 5.2 15.7 3 5.3 1
Target State and Status 1.2 to 1.3 5.3 4 4.0 3
Aircraft Operational Status 0.7 to 0.9 1.9 2 1.9 2
Extended Squitter Aircraft Status 0.7 to 0.9 1.9 2 1.9 2
Extended Squitter Aircraft Status 2.4 to 2.6 5.3 2 2.7 1
Notes:
1. All Maximum Time to Declare Fail/Warn (column 3) conditions are based on the maximum transmit interval
(column 2) multiplied by the Number of Intervals to Declare Fail/Warn (column 4) plus an additional processing
time of 100 milliseconds.
2. All Maximum Time to Clear Fail/Warn (column 5) conditions are based on the maximum Transmit Interval
(column 2) multiplied by the Number of Intervals to Clear Fail/Warn (column 6) plus an additional processing
time of 100 milliseconds.
No test procedures are currently provided in 2.4.11.2.1 to address the line items above that are highlighted in Aqua.
Equipment Required:
messages. Provide a method of modifying the transmission rates of DF=17 transmitted
messages such that the rates do not comply with the rates specified in 2.2.3.3 through
2.2.3.3.2.10.
Note: The test procedures provided in the following subparagraphs require the capability
to vary the rate of ADS-B transmitted messages. It shall be acceptable for the
manufacturer to demonstrate compliance to the following procedures by software
verification.
The following procedures shall be performed in the absence of other major operations being
performed by the ADS-B Transmitting Subsystem. Specifically, if the ADS-B Transmitting
Subsystem is a subset of the Mode-S transponder, then all interrogations of the transponder
shall be terminated during the performance of the following tests.
20xx, RTCA, Inc.

748
Step 1: Minimum DF=17 transmissions for Airborne Participants
a. Provide the ADS-B transmitting monitoring function with all necessary

information to enable the transmitting function to generate the following
DF=17 transmitted messages:
Verify that the ADS-B transmitting monitoring function properly transmits
Airborne Position, Aircraft Identification and Category, and Airborne
Velocity Messages at the rates required in 2.2.3.3.2.2, 2.2.3.3.2.4, and
2.2.3.3.2.5.
Verify that the ADS-B transmitting monitoring function does not enunciate
any Fail Warn conditions.
b. Decrease the transmission rate of the Airborne Position Message below the
acceptable rate provided in 2.2.3.3.2.2. Verify that the ADS-B transmission
monitoring function properly enunciates the Fail Warn state within no more
than 1.9 seconds.
Note: The time chosen is based on 3 times the accepted maximum time of
0.6 second with an allowance of an additional 100 milliseconds.
c. Increase the transmission rate of the Airborne Position Message to comply

with the rates specified in 2.2.3.3.2.2. Verify that the ADS-B transmission
monitoring function does not enunciate any Fail Warn conditions within 1.9
seconds after returning the rate to the acceptable rate.
d. Increase the transmission rate of the Airborne Position Message such that it
exceeds the acceptable rate provided in 2.2.3.3.2.2. Verify that the ADS-B
transmission monitoring function properly enunciates the Fail Warn state
within 1.9 seconds.
e. Decrease the transmission rate of the Airborne Position Message to comply

with the rates specified in 2.2.3.3.2.2. Verify that the ADS-B transmission
f. Decrease the transmission rate of the Aircraft Identification and Category

Messages below the acceptable rate provided in 2.2.3.3.2.4. Verify that the
ADS-B transmission monitoring function properly enunciates the Fail Warn
state within 15.7 seconds.
g. Increase the transmission rate of the Aircraft Identification and Category

Messages to comply with the rates specified in 2.2.3.3.2.4. Verify that the
ADS-B transmission monitoring function does not enunciate any Fail Warn
conditions within 5.3 seconds after returning the rate to the acceptable rate.
20xx, RTCA, Inc.

749
h. Increase the transmission rate of the Aircraft Identification and Category

Messages such that it exceeds the acceptable rate provided in 2.2.3.3.2.4.
Verify that the ADS-B transmission monitoring function properly enunciates
the Fail Warn state within 15.7 seconds.
i. Decrease the transmission rate of the Aircraft Identification and Category

Message to comply with the rates specified in 2.2.3.3.2.4. Verify that the
ADS-B transmission monitoring function does not enunciate any Fail Warn
j. Repeat steps b through e for Airborne Velocity Messages using the rates
k. Set the rates of all three messages, e.g., Airborne Position, Aircraft
Identification and Category, and Airborne Velocity Messages, such that the
rates exceed those specified in 2.2.3.3.2.2, 2.2.3.3.2.4, and 2.2.3.3.2.5
respectively.
l. Verify that the ADS-B transmitting monitoring function properly enunciates

the Fail Warn state within no more than 1.9 seconds.
m. Set the rates of all three messages, e.g., Airborne Position, Aircraft
Identification and Category, and Airborne Velocity Messages, to the rates
specified in 2.2.3.3.2.2, 2.2.3.3.2.4, and 2.2.3.3.2.5 respectively.
Verify that the ADS-B transmission monitoring function does not enunciate
any Fail Warn conditions within 5.3 seconds after returning the rates to the
acceptable rates.
Step 2: Minimum DF=17 transmissions for Surface Participants

(1). Surface Position Messages (2.2.3.2.3),
Establish sufficient Ground Speed Data to the ADS-B transmitting monitoring
function to establish the high rate for Surface Position and Aircraft
Identification and Category messages.

Surface Position and Aircraft Identification and Category Messages at the
rates required in 2.2.3.3.2.3 and 2.2.3.3.2.4 respectively.
b. Decrease the transmission rate of the Surface Position Message below the
acceptable high rate provided in 2.2.3.3.2.3. Verify that the ADS-B
transmission monitoring function properly enunciates the Fail Warn state
20xx, RTCA, Inc.

750
c. Increase the transmission rate of the Surface Position Message to comply with
the high rates specified in 2.2.3.3.2.3. Verify that the ADS-B transmission
d. Increase the transmission rate of the Surface Position Message such that it
exceeds the acceptable high rate provided in 2.2.3.3.2.3. Verify that the
ADS-B transmission monitoring function properly enunciates the Fail Warn
state within 1.9 seconds.
e. Decrease the transmission rate of the Surface Position Message to comply

with the high rates specified in 2.2.3.3.2.3. Verify that the ADS-B
transmission monitoring function does not enunciate any Fail Warn
f. Decrease the transmission rate of the Aircraft Identification and Category

Messages below the acceptable high rate provided in 2.2.3.3.2.4. Verify that
the ADS-B transmission monitoring function properly enunciates the Fail
Warn state within 15.7 seconds.
g. Increase the transmission rate of the Aircraft Identification and Category

Messages to comply with the high rates specified in 2.2.3.3.2.4. Verify that
the ADS-B transmission monitoring function does not enunciate any Fail
Warn conditions within 5.3 seconds after returning the rate to the acceptable
rate.
h. Increase the transmission rate of the Aircraft Identification and Category

Messages such that it exceeds the acceptable high rate provided in
2.2.3.3.2.4. Verify that the ADS-B transmission monitoring function
properly enunciates the Fail Warn state within 15.7 seconds.
i. Decrease the transmission rate of the Aircraft Identification and Category

Message to comply with the high rates specified in 2.2.3.3.2.4. Verify that
the ADS-B transmission monitoring function does not enunciate any Fail
Warn conditions within 5.3 seconds after returning the rate to the acceptable
rate.
j. Set the rates of both messages, e.g., Surface Position and Aircraft
Identification and Category Messages, such that the rates exceed the high rates
those in 2.2.3.3.2.3 and 2.2.3.3.2.4, respectively. Verify that the ADS-B
transmitting monitoring function properly enunciates the Fail Warn state
k. Set the rates of both messages, e.g., Surface Position and Aircraft
Identification and Category Messages, to the high rates specified in
2.2.3.3.2.3 and 2.2.3.3.2.4, respectively. Verify that the ADS-B
transmission monitoring function does not enunciate any Fail Warn
conditions within 5.3 seconds after returning the rates to the acceptable rates.
20xx, RTCA, Inc.

751
l. Decrease Ground Speed Data to the ADS-B transmitting monitoring function

to establish the low rate for Surface Position and Aircraft Identification and
Category Messages. Verify that the ADS-B transmitting monitoring function
properly transmits Surface Position and Aircraft Identification and Category
Messages at the low rates required in 2.2.3.3.2.3 and 2.2.3.3.2.4,
respectively.
m. Repeat steps b through e for Surface Position Messages using the low rates
specified in 2.2.3.3.2.3 and applying the following exceptions:
(1). The response time to set the Fail Warn state shall not exceed 15.7
seconds in steps b and d.
(2). The response time to clear the Fail Warn state shall not exceed 5.3
seconds in steps c and e.
n. Repeat steps f through i for Aircraft Identification and Category Messages
using the low rates specified in 2.2.3.3.2.4 and applying the following
exceptions:
(1). The response time to set the Fail Warn state shall not exceed 30.7
seconds in steps f and h.
(2). The response time to clear the Fail Warn state shall not exceed 10.3
seconds in steps c and e.
Step 3: Maximum DF=17 transmissions for Airborne Participants

(4). Target State and Status Messages (2.2.3.2.7.1)
(5). Aircraft Operational Status Messages (2.2.3.2.7.2)
(6). Extended Squitter Aircraft Status Messages (TYPE=28) (2.2.3.2.7.8)
Airborne Position, Aircraft Identification and Category, Airborne Velocity,
Target State and Status, Aircraft Operational Status, and Extended Squitter
Aircraft Status Messages at the rates required in 2.2.3.3.2.2, 2.2.3.3.2.4,
2.2.3.3.2.5, 2.2.3.3.2.6.1, 2.2.3.3.2.6.2, and 2.2.3.3.2.6.3 respectively.
Verify that the ADS-B transmission monitor function does not enunciate any
Fail Warn conditions.
20xx, RTCA, Inc.

752
b. Decrease the transmission rate of the Target State and Status Messages below
the acceptable rate provided in 2.2.3.3.2.6.1. Verify that the ADS-B
transmission monitor function properly enunciates the Fail Warn state in no
more than 5.3 seconds.
c. Increase the transmission rate of the Target State and Status Messages to
comply with the rates specified in 2.2.3.3.2.6.1. Verify that the ADS-B
transmission monitor function does not enunciate any Fail Warn conditions
4.0 seconds after returning the rate to the acceptable rate.
d. Increase the transmission rate of the Target State and Status Messages such
that it exceeds the acceptable rate provided in 2.2.3.3.2.6.1. Verify that the
ADS-B transmission monitor function properly enunciates the Fail Warn
state in 5.3 seconds.
e. Decrease the transmission rate of the Target State and Status Messages to
f. Decrease the transmission rate of the Aircraft Operational Status Messages

below the acceptable rate provided in 2.2.3.3.2.6.2. Verify that the ADS-B
transmission monitor function properly enunciates the Fail Warn state in no
more than 5.3 seconds.
g. Increase the transmission rate of the Aircraft Operational Status Messages to

h. Increase the transmission rate of the Aircraft Operational Status Messages

such that it exceeds the acceptable rate provided in 2.2.3.3.2.6.2. Verify that
the ADS-B transmission monitor function properly enunciates the Fail Warn
state in 5.3 seconds.
i. Decrease the transmission rate of the Aircraft Operational Status Messages to

j. Decrease the transmission rate of the Extended Squitter Aircraft Status

Messages below the acceptable rate provided in 2.2.3.3.2.6.3. Verify that the
ADS-B transmission monitor function properly enunciates the Fail Warn
state in no more than 5.3 seconds.
k. Increase the transmission rate of the Extended Squitter Aircraft Status

Messages to comply with the rates specified in 2.2.3.3.2.6.3. Verify that the
ADS-B transmission monitor function does not enunciate any Fail Warn
conditions 2.7 seconds after returning the rate to the acceptable rate.
20xx, RTCA, Inc.

753
l. Increase the transmission rate of the Extended Squitter Aircraft Status

Messages such that it exceeds the acceptable rate provided in 2.2.3.3.2.6.3.
Verify that the ADS-B transmission monitor function properly enunciates the
Fail Warn state in no more than 5.3 seconds.
m. Decrease the transmission rate of the Extended Squitter Aircraft Status

Messages to comply with the rates specified in 2.2.3.3.2.6.3. Verify that the
ADS-B transmission monitor function does not enunciate any Fail Warn
conditions 2.7 seconds after returning the rate to the acceptable rate.
2.4.11.2.2 Verification of Non-Transponder-Based Equipment Broadcast Monitoring

(2.2.11.2.2)
These test procedures verify that the ADS-B Transmitting monitor function properly
enunciates the Fail Warn state if DF=18 transmissions do not occur at the rates specified
in 2.2.3.3 through 2.2.3.3.2.10.
Equipment Required:
messages. Provide a method of modifying the transmission rates of DF=18 transmitted
messages such that the rates do not comply with the rates specified in 2.2.3.3 through
2.2.3.3.2.10.
Note: The test procedures provided in the following subparagraphs require the capability
to vary the rate of ADS-B transmitted messages. It is explicitly intended that the
equipment manufacturer provide the means to accomplish this task under closed
Unit conditions.
The following procedures shall be performed in the absence of other major operations being
performed by the ADS-B transmitting monitoring function.
Repeat all of the procedures provided in 2.4.11.2.1 with the exception that all broadcast
messages use DF=18 instead of DF=17.
2.4.11.3 Verification of Address (2.2.11.3)

2.4.11.3.1 Verification of Transponder-Based Equipment Addressing (2.2.11.3.1)

Transponder-Based Equipment shall be tested in accordance with the procedures provided
in 2.4.11.3.2.
20xx, RTCA, Inc.

754
Note: The requirement to test Transponder-Based equipment is provided herein due to the
fact that the test requirements provided in RTCA DO-181D do not test the function
adequately. XXXXXX TBD XXXXXX DO WE STILL WANT TO SAY THIS ?
2.4.11.3.2 Verification of Non-Transponder-Based Equipment Addressing (2.2.11.3.2)

These test procedures verify that the ADS-B Transmitting monitor function properly
enunciates the Fail Warn condition in the event that the ICAO 24-Bit Address (2.2.5.1.1)
provided to the ADS-B Transmitting Subsystem is set to ALL ZEROs or ALL ONEs.
Equipment Required:
messages. Provide a method of modifying the ICAO 24-Bit Address provided to the Unit
Under Test (UUT).
Step 1: Initial Conditions
indicating no Fail Warn conditions.
Step 2: Address set to ALL ZEROs
Remove power from the UUT. Set the ICAO 24-Bit Address provided to the
UUT to ALL ZEROs. Apply power to the UUT. Verify that the ADS-B
transmission function properly enunciates the Fail Warn state within no more
than 2.0 seconds.
Step 3: New Initial Conditions
Repeat Step 1.
Step 4: Address set to ALL ONEs
Remove power from the UUT. Set the ICAO 24-Bit Address provided to the
UUT to ALL ONEs. Apply power to the UUT. Verify that the ADS-B
transmission function properly enunciates the Fail Warn state within no more
than 2.0 seconds.
Step 5: Restore Normal Operations
indicating no Fail Warn conditions prior to continuing with further testing.
20xx, RTCA, Inc.

755
2.4.11.4 Verification of Receiver Self Test Capability (2.2.11.4)

The purpose of this test procedure is to verify that the ADS-B Receiving Devices provide
sufficient self-test capability to detect a loss of capability to receive ADS-B Messages,
structure appropriate ADS-B reports, and make such reports available to the intended user
interface. The procedure also verifies that should the receiving device detect that these
basic functions cannot be performed properly, then the receiving device properly sets the
appropriate Fail/Warn indicators to the Fail/Warn state.
Equipment Required:
Provide a method of supplying the Receiving function under test with ADS-B Broadcast
Messages to include Airborne Position, Airborne Velocity, and Aircraft Identification and
Category Messages as a minimum. Provide a method of receiving and storing all Output
Messages or Reports generated by the receiving function under test. Provide a method of
analyzing the Output Messages or Reports generated by the receiving function under test.
Provide a method of inducing a fault condition into the Receiving function such that it can
no longer properly receive and process ADS-B Broadcast Messages.
Note: The manufacturer must provide a method of inducing or simulating failure of the
ADS-B Broadcast Message reception capability. This may be done by appropriate
Software Test provisions or may require that the unit under test be opened in order
to provide access to internal circuitry.
Step 1: Establish ADS-B Broadcast Message Stimulus
Configure the ADS-B Broadcast Message simulation function to provide the

ADS-B Receiving Subsystem under test with Airborne Position, Airborne
Velocity, and Aircraft Identification and Category Messages for at least 10
Airborne participants. Each message shall be provided at the rates specified in
2.2.3.3.
Verify that the Receiving function under test is generating the appropriate Reports
that are expected for the ADS-B Broadcast Messages being provided by the
simulation function.
Step 2: Induce Receiver Failure
Induce a failure into the ADS-B Receiving Subsystem under test such that ADS-B
Broadcast Messages can no longer be received.
Verify that the ADS-B Receiving Subsystem properly enunciates the Fail Warn
state for as long as the failure is induced.
20xx, RTCA, Inc.

756
Step 3: Remove Induced Receiver Failure
Remove the induced failure and allow the ADS-B Receiving Subsystem under test
to return to normal operation.
Verify that the ADS-B Receiving Subsystem does not enunciate the Fail Warn
state 2.0 seconds after removing the induced failure.
2.4.11.5 Verification of Failure Annunciation (2.2.11.5)

2.4.11.5.1 Verification of ADS-B Transmission Device Failure Annunciation (2.2.11.5.1)

Appropriate test procedures to validate 2.2.11.5.1 are provided in 2.4.11.2.1 through
2.4.11.3.2.
2.4.11.5.2 Verification of ADS-B Receiving Device Failure Annunciation (2.2.11.5.2)

Appropriate test procedures to validate 2.2.11.5.2 are provided in 2.4.11.4.
2.4.11.5.3 Verification of Co-Located ADS-B Transmission and Receiving Device Failure

Annunciation (2.2.11.6)
Appropriate test procedures to validate 2.2.11.5.1 are provided in 2.4.11.2.1 through
2.4.11.3.2, and 2.4.11.4.
2.4.12 Verification of Response to Mutual Suppression Pulses (2.2.12)

2.4.12.1 Verification of ADS-B Transmitting Subsystem Response to Mutual Suppression

Pulses (2.2.12.1)
These test procedures verify that the ADS-B Transmitting Subsystem functions properly in
the Mutual Suppression environment as specified in 2.2.12.1.
20xx, RTCA, Inc.

757
Equipment Required:
equipment under test. Provide a method of supplying the ADS-B Transmitting Subsystem
with Mutual Suppression Pulses. Provide a method of monitoring and recording ADS-B
transmissions and the time at which such transmissions are generated with respect to the end
of a mutual suppression pulse.
Step 1: Initialize ADS-B Airborne Participant Transmissions
Provide the ADS-B Transmitting Subsystem with all necessary information to

enable the transmitting function to generate the following DF=17 transmitted
messages:
Verify that the ADS-B Transmitting Subsystem properly transmits Airborne

Position, Aircraft Identification and Category, and Airborne Velocity Messages at
the rates required in 2.2.3.3.2.2, 2.2.3.3.2.4, and 2.2.3.3.2.5.
Apply Mutual Suppression pulses of the maximum length that the suppression
interface is designed to accept. Verify that no ADS-B transmissions occur during
the suppression period.
Record the transmissions that are generated and verify that transmissions can be
output no later than 15 microseconds after the end of the mutual suppression
pulse.
2.4.12.2 Verification of ADS-B Receiving Device Response to Mutual Suppression Pulses

(2.2.12.2)
These test procedures verify that the ADS-B Receiving device functions properly in the
Mutual Suppression environment as specified in 2.2.12.2.
Equipment Required:
Provide a method of supplying ADS-B Transmitted messages to the ADS-B Receiving

Subsystem. Provide a method of supplying the ADS-B Receiving Subsystem with Mutual
Suppression Pulses that can be synchronized to the ADS-B Transmitted messages provided
to the ADS-B Receiving Subsystem. Provide a method of monitoring and recording the
Receiving function decoded ADS-B Messages or structured ADS-B Reports.
20xx, RTCA, Inc.

758
Step 1: Initialize ADS-B Message Reception
Provide the ADS-B Receiving Subsystem with appropriate ADS-B Messages at a

minimum rate of two per second and having a signal level of the Receiver MTL
+3 dB. Verify that the Receiving function decodes at least 99 percent of the
messages provided to the receiver.
a. Apply Mutual Suppression pulses synchronized to start before each ADS-B

Message provided to the Receiving function.
Ensure that the duration of each Mutual Suppression pulse exceeds that of the
ADS-B Messages being provided to the Receiving function. Verify that no
ADS-B Messages are successfully decoded by the Receiving function.
b. Apply Mutual Suppression pulses that do not over lap any of the ADS-B
Messages provided to the Receiving function and are synchronized to finish
15 microseconds prior to the start of each ADS-B Message provided to the
Receiving function.
Verify that at least 90 percent of the ADS-B Messages provided to the

Receiving function are properly decoded by the Receiving function.
2.4.13 Verification of Antenna System (2.2.13)

2.4.13.1 Verification of Transmit Pattern Gain (2.2.13.1)

Appropriate installed equipment test procedures to verify the Transmit Pattern Gain are
2.4.13.2 Verification of Receiver Pattern Gain (2.2.13.2)

Appropriate installed equipment test procedures to verify the Receiver Pattern Gain are
2.4.13.3 Verification of Frequency Requirements for Transmit and Receive Antenna(s)

(2.2.13.3)
Appropriate installed equipment test procedures to verify the Frequency Requirements are
20xx, RTCA, Inc.

759
2.4.13.4 Verification of Impedance and VSWR (2.2.13.4)

Appropriate installed equipment test procedures to verify the Impedance and VSWR are
2.4.13.5 Verification of Polarization (2.2.13.5)

Appropriate installed equipment test procedures to verify the Polarization are provided in
3.3.4.6.5.
2.4.13.6 Verification of Diversity Operation (2.2.13.6)

2.4.13.6.1 Verification of Transmitting Diversity (2.2.13.6.1)

This test procedure verifies that an ADS-B Transmitting Subsystem implements transmitting
diversity properly by transmitting each required type of ADS-B Message alternately from
the top and bottom antenna channels as specified in 2.2.13.6.1.
Equipment Required:
Provide a method of supplying the ADS-B Transmitting Subsystem with all data necessary
to structure ADS-B Airborne Position, Airborne Velocity, and Aircraft Identification and
Category Messages. All data shall be provided via the operational interfaces. Provide a
method of monitoring the ADS-B Broadcast Messages transmitted by the ADS-B
Airborne Position, Airborne Velocity, and Aircraft Identification and Category
ADS-B Broadcast Messages.
Verify that the ADS-B Transmitting Subsystem properly transmits the appropriate
Airborne Position Messages alternately on the Top and Bottom RF ports.
Airborne Velocity Messages alternately on the Top and Bottom RF ports.
20xx, RTCA, Inc.

760
Aircraft Identification and Category Messages alternately on the Top and Bottom
RF ports.
2.4.13.6.1.1 Verification of Transmitting Diversity Channel Isolation (2.2.13.6.1.1)

This test procedure verifies that the peak RF power transmitted from the selected antenna
exceeds the power transmitted from the non-selected antenna by at least 20 dB as specified
in 2.2.13.6.1.1.
Equipment Required:
Provide a method of supplying the ADS-B Transmitting Subsystem with all data necessary
to structure ADS-B Airborne Position Broadcast messages. All data shall be provided via
the operational interfaces. Provide a method of detecting the RF pulses of the ADS-B
Airborne Position Type ADS-B Broadcast Messages.
Airborne Position Messages alternately on the Top and Bottom RF ports.
Step 3: Bottom Channel Isolation Verification
During the time that the Airborne Position Message is actually being transmitted
via the Top Channel RF Port, verify that the signal level of any transmission on
the Bottom Channel RF Port is at least 20 dB below the signal level of the
transmission on the Top Channel RF Port.
Step 4: Top Channel Isolation Verification
During the time that the Airborne Position Message is actually being transmitted
via the Bottom Channel RF Port, verify that the signal level of any transmission
on the Top Channel RF Port is at least 20 dB below the signal level of the
transmission on the bottom Channel RF Port.
20xx, RTCA, Inc.

761
2.4.13.6.2 Verification of Receiving Diversity (2.2.13.6.2)

Appropriate test procedures to verify the performance of 2.2.13.6.2 are provided in
2.4.13.6.2.1 through 2.4.13.6.2.2.
2.4.13.6.2.1 Verification of Full Receiver and Message Processing or Receiver Switching Front-End
Diversity (2.2.13.6.2)
This test procedure verifies that the ADS-B Receiving Subsystem properly implements
diversity by demonstrating proper reception of ADS-B Broadcast Messages from either the
top antenna, or the bottom antenna, or both antennas. This procedure applies to those
configurations that implement Full receiver and message processing function diversity as
discussed in 2.2.13.6.2.a. This procedure also apples to those configurations that
implement Receiver Switching Front-End diversity as discussed in 2.2.13.6.2.b.
Equipment Required:
Provide a method of supplying the equipment under test with appropriate ADS-B Airborne
Position Messages. Provide a method of monitoring the Output Messages and/or ADS-B
Reports generated by the ADS-B Receiving Subsystem. Provide an RF Splitter/Combiner
(2 port, or 3 dB type). Provide an RF Attenuators (Fixed, various attenuation values, as
needed).
Step 1: Test Equipment Configuration
Connect the ADS-B Broadcast Message generator to the RF Splitter input.

Connect each output from the RF Splitter to the input of an RF Attenuator.
Connect the output of one RF Attenuator to the Top Channel RF input port of the
equipment under test. Connect the output of the other RF Attenuator to the
Bottom Channel RF input port of the equipment under test.
Adjust the Top Channel attenuator such that the signal level provided to the Top
Channel RF input port is at least 3 dB above the MTL of the equipment under test.
Bottom Channel RF input port is 20 dB less than the MTL of the equipment under
test.

Position Messages for a single participant with the position continuously changing
in the message.
20xx, RTCA, Inc.

762

under test.
Channel RF input port is 20 dB less than the MTL of the equipment under test.

in the message.

Step 4: Top / Bottom Channel Equivalent
under test.
Channel RF input port is at least 3 dB above the MTL of the equipment under test.

in the message.

Messages or State Vector Reports for between 90% and 100% of the Airborne
Position Messages provided to the Bottom Channel RF input port.
2.4.13.6.2.2 Verification Receiving Antenna Switching Diversity (2.2.13.6.2)

This test procedure verifies that the ADS-B Receiving Subsystem properly implements
diversity by demonstrating proper reception of ADS-B Broadcast Messages from either the
top antenna or the bottom antenna. This procedure applies to those configurations that
implement Receiving Antenna switching as discussed in 2.2.13.6.2.c.
20xx, RTCA, Inc.

763
Equipment Required:
Provide a method of supplying the equipment under test with appropriate Airborne Position
ADS-B Broadcast Messages. Provide a method of monitoring the Output Messages and/or
ADS-B Reports generated by the ADS-B Receiving Subsystem. Provide RF Attenuators
(Fixed, various attenuation values, as needed).

Connect the output of the RF Attenuator to the Top Channel RF input port of the
equipment under test.
Adjust the attenuator such that the signal level provided to the Top Channel RF

in the message.


Connect the output of the RF Attenuator to the Bottom Channel RF input port of
the equipment under test.
Adjust the attenuator such that the signal level provided to the Bottom Channel RF

in the message.

2.4.14 Verification of Interfaces (2.2.14)

20xx, RTCA, Inc.

764
2.4.14.1 Verification of ADS-B Transmitting Subsystem Interfaces (2.2.14.1)

2.4.14.1.1 Verification of ADS-B Transmitting Subsystem Input Interfaces (2.2.14.1.1)

2.4.14.1.1.1 Verification of Discrete Input Interfaces (2.2.14.1.1.1)

Appropriate verification of discrete input interfaces to the ADS-B Transmitting Subsystem
was demonstrated during testing of the entire transmission function performed in 2.4.2 and
2.4.3 of this document.
Note: The manufacturer is required to document all intended data to be input via
discrete inputs and ensure full and correct functioning of the ADS-B Transmitting
Subsystem for all inputs at these interfaces. The manufacturer shall also
demonstrate that appropriate diode isolation is provided for each input interface.
Such demonstration can be done by formal documentation of the design such as
schematics and Bill of Materials (BOM).
2.4.14.1.1.2 Verification of Digital Communication Input Interfaces (2.2.14.1.1.2)

Appropriate verification of digital communication input interfaces to the ADS-B
Transmitting Subsystem was demonstrated during testing of the entire transmission function
performed in 2.4.2 and 2.4.3 of this document.
Note: The manufacturer is required to disclose the interface protocols and error control
techniques used with these interfaces and to demonstrate correct functioning of
theses interfaces in such regards. Traditionally, analysis and established
knowledge of the interface (e.g., ARINC-429) have been sufficient to satisfy these
interface integrity requirements.
2.4.14.1.1.3 Verification of Processing Efficiency (2.2.14.1.1.3)

Appropriate verification of the processing efficiency of interfaces to the ADS-B
2.4.14.1.2 Verification of ADS-B Transmitting Subsystem Output Interfaces (2.2.14.1.2)

20xx, RTCA, Inc.

765
2.4.14.1.2.1 Verification of Discrete Output Interfaces (2.2.14.1.2.1)

Appropriate verification of discrete output interfaces from the ADS-B Transmitting
Subsystem was demonstrated during testing of the entire transmission function performed in
2.4.2 and 2.4.3 of this document.
Note: The manufacturer is required to document all intended data to be output via
discrete interfaces and ensure full and correct functioning of the ADS-B
Transmitting Subsystem for all outputs at these interfaces. The manufacturer shall
also demonstrate that appropriate diode isolation is provided for each output
interface. Such demonstration can be done by formal documentation of the design
such as schematics and Bill of Materials (BOM).
2.4.14.1.2.2 Verification of Digital Communication Output Interfaces (2.2.14.1.2.2)

Appropriate verification of digital communication output interfaces from the ADS-B
2.4.14.2 Verification of ADS-B Receiving Device Interfaces (2.2.14.2)

2.4.14.2.1 Verification of ADS-B Receiving Device Input Interfaces (2.2.14.2.1)

2.4.14.2.1.1 Verification of Discrete Input Interfaces (2.2.14.2.1.1)

Appropriate verification of discrete input interfaces to the ADS-B Receiving Subsystem was
demonstrated during testing of the entire receiving function performed in 2.4.4 through
2.4.11 of this document.
Note: The manufacturer is required to document all intended data to be input via discrete
inputs and ensure full and correct functioning of the ADS-B Receiving Subsystem
for all inputs at these interfaces. The manufacturer shall also demonstrate that
appropriate diode isolation is provided for each input interface. Such
demonstration can be done by formal documentation of the design such as
20xx, RTCA, Inc.

766
2.4.14.2.1.2 Verification of Digital Communication Input Interfaces (2.2.14.2.1.2)

Appropriate verification of digital communication input interfaces to the ADS-B Receiving
Subsystem was demonstrated during testing of the entire receiving function performed in
2.4.4 through 2.4.11 of this document.
2.4.14.2.1.3 Verification of Processing Efficiency (2.2.14.2.1.3)

Appropriate verification of processing efficiency of interfaces to the ADS-B Receiving
Subsystem was demonstrated during testing of the entire receiving function performed in
2.4.4 through 2.4.11 of this document.
2.4.14.2.2 Verification of ADS-B Receiving Device Output Interfaces (2.2.14.2.2)

2.4.14.2.2.1 Verification of Discrete Output Interfaces (2.2.14.2.2.1)

Appropriate verification of discrete output interfaces from the ADS-B Receiving Subsystem
was demonstrated during testing of the entire receiving function performed in 2.4.4
through 2.4.11 of this document.
Note: The manufacturer is required to document all intended data to be output via
discrete interfaces and ensure full and correct functioning of the ADS-B Receiving
Subsystem for all outputs at these interfaces. The manufacturer shall also
demonstrate that appropriate diode isolation is provided for each output interface.
Such demonstration can be done by formal documentation of the design such as
2.4.14.2.2.2 Verification of Digital Communication Output Interfaces (2.2.14.2.2.2)

Appropriate verification of digital communication output interfaces from the ADS-B
Receiving Subsystem was demonstrated during testing of the entire receiving function
performed in 2.4.4 through 2.4.11 of this document.
20xx, RTCA, Inc.

767
2.4.15 Verification of Power Interruption (2.2.15)

2.4.15.1 Verification of Power Interruption to ADS-B Transmitting Subsystems (2.2.15)

These test procedures verify that the ADS-B Transmitting Subsystem regains operational
capability to within its operational limits within two seconds after the restoration of power
Equipment Required:
ADS-B Transmitting Subsystem under test through the operational interface.
Step 1: Enable Transmission of Airborne Position Messages
Supply the ADS-B Transmitting Subsystem with the appropriate data necessary to
establish Airborne Position Messages.
Verify that the ADS-B Transmitting Subsystem generates appropriate Airborne

Position Messages at the rate specified in 2.2.3.3.1.1 or 2.2.3.3.2.2.
Note: If the ADS-B Transmitting Subsystem uses diversity and the test is being
performed on one RF output interface at a time, then the specified rate
necessary to satisfy this test is half of that given in 2.2.3.3.1.1 or
2.2.3.3.2.2.
Apply momentary power interrupts to the ADS-B Transmitting Subsystem under

test in accordance with RTCA DO-160F section 16 (EUROCAE ED-14F, section
16). Then restore the power to normal operating conditions.
Verify that the ADS-B Transmitting Subsystem resumes generation of appropriate

Airborne Position Messages no later than 2.0 seconds after the restoration of
normal power.
If the ADS-B Transmitting Subsystem implements diversity, then repeat steps 1

and 2 on the additional RF Output Interface.
20xx, RTCA, Inc.

768
2.4.15.2 Verification of Power Interruption to ADS-B Receiving Subsystems (2.2.15)

These test procedures verify that the ADS-B Receiving Subsystem regains operational
capability to within its operational limits within two seconds after the restoration of power
Equipment Required:
An equipment capable of supplying valid ADS-B broadcast messages to the ADS-B
Receiving Subsystem under test via the appropriate RF interface.
Step 1: Enable Reception of Airborne Position Messages
Via the receiver RF interface and in the absence of interference, apply valid 1090
MHz Airborne Position Messages at a uniform rate of 2 per second and at a signal
level that is at least 15 dB above the MTL of the ADS-B Receiving Subsystem.
Verify that the ADS-B Receiving Subsystem delivers appropriate Output

Messages to the user interface or to the Report Assembly function for all messages
received and that the Output Message formats are consistent with the requirements
of 2.2.6.1.1.
Apply momentary power interrupts to the ADS-B Receiving Subsystem under test
in accordance with RTCA DO-160F section 16 (EUROCAE ED-14F, section 16).
Then restore the power to normal operating conditions.
Verify that the ADS-B Receiving Subsystem resumes generation of appropriate

Output Messages to the user interface or to the Report Assembly function no later
than 2.0 seconds after the restoration of power.
Then verify that the ADS-B Receiving Subsystem continues to deliver appropriate
Output Messages to the user interface or to the Report Assembly function for all
messages received and that the Output Message formats are consistent with the
requirements of 2.2.6.1.1.
If the ADS-B Receiving Subsystem implements diversity, then repeat steps 1 and
2 on the additional RF Input Interface.
2.4.16 Verification of Compatibility with Other Systems (2.2.16)

20xx, RTCA, Inc.

769
2.4.16.1 Verification of EMI Compatibility (2.2.16.1)

Verification of EMI/EMC/HIRF/LIGHTNING compatibility is performed during
Environmental testing in accordance with RTCA DO-160F (EUROCAE ED-14F) with the
test procedures provided in Section 2.3 of this document.
2.4.16.2 Verification of Compatibility with GPS Receivers (2.2.16.2)

Verification of compatibility with GPS Receivers is demonstrated during verification of
EMI/EMC/HIRF/LIGHTNING compatibility performed during Environmental testing in
accordance with RTCA DO-160F (EUROCAE ED-14F) with the test procedures provided
in Section 2.3 of this document.
2.4.16.3 Verification of Compatibility with Other Navigation Receivers and ATC Transponders
(2.2.16.3)
Verification of compatibility with Other Navigation Receivers and ATC Transponders is
demonstrated during verification of EMI/EMC/HIRF/LIGHTNING compatibility performed
during Environmental testing in accordance with RTCA DO-160F (EUROCAE ED-14F)
with the test procedures provided in 2.3 of this document.
2.4.17 Verification of Traffic Information Services Broadcast (TIS-B) (2.2.17)

No specific test procedure is required to validate the requirements of 2.2.17.
2.4.17.1 Verification of TIS-B Introduction (2.2.17.1)

2.4.17.2 Verification of the TIS-B Format Structure (2.2.17.2)

2.4.17.2.1 Verification of the DF Downlink Format (2.2.17.2.1)

2.4.17.2.2 Verification of the CF Control Field (2.2.17.2.2)

These test procedures verify the use of the CF field of DF=18 messages being used by
Non-Transponder-Based installations as specified in 2.2.17.2.2.
20xx, RTCA, Inc.

770
Step 1: Verification of DF=18, CF=2
Set up to transmit TIS-B Messages. Input a simulated ADS-B DF=18, CF=2

Message. Verify that a TIS-B Report is generated.

Message. Verify that a TIS-B Report is generated.

Message. Verify that a TIS-B Report is generated containing the full 112-bits of
the received 1090ES Message.
Set up to transmit TIS-B Messages. Input a simulated ADS-B DF=18, CF=5 and
IMF=0 Message. Verify that a TIS-B Report is generated. Input a simulated
ADS-B DF=18, CF=5 and IMF=1 Message. Verify that a TIS-B Report is not
generated.
Set up to transmit TIS-B Messages. Input a simulated ADS-B Message with

DF=18 and CF=6. Verify that a TIS-B Report is generated.
2.4.17.2.3 Verification of the AA Address Announced Field (2.2.17.2.3)

These test procedures verify the use of the AA Address field as specified in Table 2-106,
and 2.2.17.2.3.
Step 1: Verification of the (ICAO) AA Content in a Fine TIS-B Message

information directly to the Receiving Subsystem. Input a simulated Fine TIS-B
DF=18 Message with CF=2 and IMF=0.
Verify that the CF field holds the value TWO (binary 010) and that the
ICAO/Mode A Flag (IMF) is set to ZERO (0) in the output TIS-B Report.
20xx, RTCA, Inc.

771
Step 2: Verification of the (Mode A) AA Content in a Fine TIS-B Message

information directly to the Receiving Subsystem. Input a simulated Fine TIS-B
Verify that the CF field holds the value TWO (binary 010) and that the
ICAO/Mode A Flag (IMF) is set to ONE (1) in the output TIS-B Report.
Step 3: Verification of the (ICAO) AA Content in a Coarse TIS-B Message

information directly to the Receiving Subsystem. Input a simulated Coarse TIS-B
Verify that the CF field holds the value THREE (binary 011) and that the
ICAO/Mode A Flag (IMF) is set to ZERO (0) in the output TIS-B Report.
Step 4: Verification of the (Mode A) AA Content in a Coarse TIS-B Message

information directly to the Receiving Subsystem. Input a simulated Coarse TIS-B
Verify that the CF field holds the value THREE (binary 011) and that the
ICAO/Mode A Flag (IMF) is set to ONE (1) in the output TIS-B Report.
2.4.17.2.4 Verification of the ME Message Extended Squitter Field (2.2.17.2.4)

No specific test is required to validate 2.2.17.2.4.
2.4.17.2.5 Verification of the PI Parity/Identify Field (2.2.17.2.5)

2.4.17.3 Verification of TIS-B Messages (2.2.17.3)

No specific test is required to validate 2.2.17.3.
2.4.17.3.1 Verification of TIS-B Fine Airborne Position Message (2.2.17.3.1)

20xx, RTCA, Inc.

772
2.4.17.3.1.1 Verification of the Relationship to ADS-B Format (2.2.17.3.1.1)

This test procedure verifies that the following fields are decoded as specified for the ADS-B
Airborne Position Message defined in 2.2.3.2.3:
TYPE Code Surveillance Status
Altitude CPR Format
Encoded Latitude Encoded Longitude
Set up to simulate TIS-B Transmitted Messages by inputting TIS-B Message information

directly to the Receiving Subsystem. Input a simulated TIS-B Fine Airborne Position
Message.
Verify that the input TYPE, Surveillance Status, Altitude, CPR Format, Encoded Latitude
and Encoded Longitude fields are all reflected in the output TIS-B Report. Repeat this
procedure for TYPE Codes 9 through 18 and 20, 21 and 22, which are the TYPE Codes of
the Airborne Position Message.
2.4.17.3.1.2 Verification of the ICAO/Mode A Flag (IMF) (2.2.17.3.1.2)

These test procedures verify that the ICAO/Mode A Flag is set as specified in 2.2.17.3.1.2.
Step 1: Verification of the ICAO/Mode A Flag (IMF) in a TIS-B Message ICAO

information directly to the Receiving Subsystem. Input a simulated TIS-B DF=18
Message such that the IMF Flag is set to ZERO (0). Verify that the ICAO/Mode
A Flag (IMF) is set to ZERO (0) in the output TIS-B Report.
Step 2: Verification of the ICAO/Mode A Flag (IMF) in a TIS-B Message Mode A

Message such that the IMF Flag is set to ONE (1). Verify that the ICAO/Mode A
Flag (IMF) is set to ONE (1) in the output TIS-B Report.
2.4.17.3.2 Verification of TIS-B Fine Surface Position Message (2.2.17.3.2)

20xx, RTCA, Inc.

773

These test procedures verify that the following fields are decoded as specified for the ADS-
B Surface Position Message defined in 2.2.3.2.4:
TYPE Code Movement
Heading Status Heading
CPR Format Encoded Latitude
Encoded Longitude

directly to the Receiving Subsystem. Input a simulated TIS-B Fine Surface Position
Message. Verify that the input TYPE, Movement, Ground Track Status, CPR Format,
Encoded Latitude and Encoded Longitude fields are all reflected in the output TIS-B
Report. Repeat this procedure for TYPE Codes 5 through 8, which are the TYPE Codes for
the Surface Position Messages.

This test procedure verifies that the ICAO/Mode A Flag is set as specified in 2.2.17.3.1.2.


2.4.17.3.3 TIS-B Identification and Category Message (2.2.17.3.3)

20xx, RTCA, Inc.

774

These test procedures verify that all of the fields of the TIS-B Identification and Category
Message are decoded as specified for the ADS-B Identification and Category Message

directly to the Receiving Subsystem. Input a simulated TIS-B Identification and Category
Message with a TYPE Code equal 1. Verify that all of the input data fields in Figure 2-27
are reflected in the output TIS-B Report. Repeat this procedure for TYPE Codes 2, 3 and 4.
2.4.17.3.4 Verification of TIS-B Velocity Message (2.2.17.3.4)


Theses test procedures verify that the following fields are decoded as specified for the ADS-
B Velocity Message with Subtype=1, as specified in 2.2.3.2.6.1, or Subtype=2, as
specified in 2.2.3.2.6.2:
E/W Direction Bit E/W Velocity
N/S Direction Bit N/S Velocity
Vertical Rate Sign Vertical Rate
Height Difference Sign Bit Geometric Height Difference from Baro
Vertical Rate Type

directly to the Receiving Subsystem. Input a simulated TIS-B Velocity Message,
TYPE=19, Subtype=1.
Verify that the input TYPE, Subtype, E/W Direction Bit, E/W Velocity, N/S Direction Bit,
N/S Velocity, Sign Bit for Vertical Rate, Vertical Rate, Height Difference Sign Bit,
Geometric Height Difference from Baro, and Vertical Rate Type subfields are all
reflected in the output TIS-B Report. Repeat this procedure for TIS-B Velocity Messages,
TYPE=19 and Subtype=2.

directly to the Receiving Subsystem. Input a simulated TIS-B Velocity Message,
TYPE=19, Subtype=1, GEO=1. Verify that the input Vertical Rate Type, Height Difference
Sign Bit and Geometric Height Difference from Baro are all reflected in the output TIS-B
20xx, RTCA, Inc.

775
Report. Repeat this procedure for TIS-B Velocity Messages, TYPE=19 and Subtype=2,
GEO=1.
2.4.17.3.4.2 Verification of ICAO/Mode A Flag (IMF) (2.2.17.3.4.2)



2.4.17.3.4.3 Verification of Navigation Integrity Category (NIC) Supplement-A (2.2.17.3.4.3)

This test procedure verifies that the NIC Supplement-A bit (ME bit 47) field is used
together with the Message TYPE Code to define the NIC value for the Airborne and Surface
Position Messages. Coding of the NIC Supplement-A field is specified for the Aircraft
Operational Status Message in Table N-XX.
Step 1: Verification of NIC Supplement

Velocity Message containing pseudo-random data and include valid values in the
Airborne Position Message TYPE Code and NIC Supplement-A subfields.
Verify that for each Airborne Position Message TYPE Code and NIC Supplement-
A value in Table N-XX, that the corresponding NIC value is reflected in the
output TIS-B Report.
20xx, RTCA, Inc.

776
2.4.17.3.4.4 Verification of the Navigation Accuracy Category for Position (NACP) (2.2.17.3.4.4)
This test procedure verifies the use of the four-bit (ME bits 10 through 13) field that
defines the NACP value for the Airborne and Surface Position Messages. Coding of the
NACP field is specified for the Aircraft Operational Status Message in Table 2-71.

directly to the Receiving Subsystem. Input a simulated TIS-B Velocity Message containing
pseudo-random data but include valid values in the NACP field as per Table 2-71. Verify
that each input NACP value so entered is reflected in the output TIS-B Report.
2.4.17.3.4.5 Verification of the Navigation Accuracy Category for Velocity (NACV) (2.2.17.3.4.5)
This test procedure verifies the use of the 3-bit (ME bits 48 through 50) field that defines
the NACV value for the Airborne Velocity Message when the GEO Flag is equal to ZERO
(0). Coding of the NACV field is specified in 2.2.3.2.6.1.5.

directly to the Receiving Subsystem. Input a simulated TIS-B Velocity Message TYPE=19
with the GEO Flag set to ZERO (0) and containing pseudo-random data but include valid
values in the NACV field as per Table 2-25. Verify that each input NACV value so entered is
reflected in the output TIS-B Report.
2.4.17.3.4.6 Verification of the Source Integrity Level (SIL) (2.2.17.3.4.6)

This test procedure verifies the use of the two-bit (ME bits 52 and 53) field that defines
the SIL value for the Airborne and Surface Position Messages when the GEO Flag is equal
to ZERO (0). Coding of the SIL field is specified in Table N-XX.

values in the SIL field as per Table N-XX. Verify that each input SIL value so entered is
20xx, RTCA, Inc.

777
2.4.17.3.4.7 Verification of the True/Magnetic Heading Type (2.2.17.3.4.7)

This test procedure verifies the use of the one-bit (ME bit 55) field that defines the True
or Magnetic Heading value for the Airborne Velocity Message when the GEO Flag is equal
to ZERO (0) for a Subtype of 3 or 4. Coding of the True/Magentic Heading Type field is
specified in 2.2.3.2.7.2.13.

values in the HRD field as per Table 2-76. Verify that each input HRD value so entered is
2.4.17.3.5 Verification of the TIS-B Coarse Position Message (2.2.17.3.5)


No specific test is required to validate 2.2.17.3.5.1.



20xx, RTCA, Inc.

778
2.4.17.3.5.3 Verification of the Service Volume ID (SVID) (2.2.17.3.5.3)

This test procedure verifies that the 4-bit SVID field (ME bits 4 through 7) is properly
decoded to identify the TIS-B site that delivered the surveillance data.

directly to the Receiving Subsystem. Input a simulated even formatted TIS-B Message and,
within ten seconds, an odd formatted TIS-B Message with an identical SVID field. This
will complete a track and indicate that both messages came from the same TIS-B station.
Verify that the subsequent output TIS-B Report reflects the value in the SVID field in the
input messages.
2.4.17.3.5.4 Verification of the Pressure Altitude (2.2.17.3.5.4)

Appropriate test procedures to verify 2.2.17.3.5.4 are provided in 2.4.3.2.3.4.1 and
2.2.3.2.3.4.2.
2.4.17.3.5.5 Verification of the Ground Track Status (2.2.17.3.5.5)

This test procedure verifies the one bit (ME bit 20) field that defines the validity of the
Ground Track value as specified in 2.2.17.3.5.5.
Step 1: Verification of Ground Track Status Valid

information directly to the Receiving Subsystem. Input a simulated TIS-B coarse
position message with (ME bit 20) set to ONE (1). Verify that the contents of
Ground Track Angle field are reflected in the next output TIS-B Report and that
the validity bit (ME bit 20) is set to ONE (1).
Step 2: Verification of Ground Track Status Not Valid

position message with (ME bit 20) set to ZERO (0). Verify that the contents of
Ground Track Angle field are not reflected in the next output TIS-B Report and
that the validity bit (ME bit 20) is set to ZERO (0).
20xx, RTCA, Inc.

779
2.4.17.3.5.6 Verification of the Ground Track Angle (2.2.17.3.5.6)

This test procedure verifies the 5-bit (ME bits 21 through 25) field that defines the
direction (in degrees clockwise from true north) of aircraft motion. The Ground Track is
encoded as an unsigned angular weighted binary numeral, with an MSB of 180 degrees and
an LSB of 360/32 degrees, with ZERO (0) indicating true north. The data in the field is
rounded to the nearest multiple of 360/32 degrees.
Step 1: Verification of Ground Track Angle Input Validation

position message. Provide valid, non-zero Ground Track Angle data to the
receiver. Verify that the Ground Track Angle subfield is not set to ZERO (0).
Set the Ground Track Angle input to exactly ZERO degrees and verify that the
encoding of the Ground Track Angle subfield is set to ZERO (binary 0 0000) in
the output TIS-B Report.
Step 2: Verification of Ground Track Angle Discreet Values

message with a Ground Track Angle input set to binary 0 0001. Verify that a
Ground Track value of 11.25 degrees is reflected in the output TIS-B Report.
Continue increasing the Ground Track Angle data input value and verify that,
for each such input set to the corresponding binary value in each row shown in
Table 2-204, the Ground Track Angle in degrees is correctly reflected in the
output TIS-B Report.
Table 2-204: Ground Track Angle Encoding

Coding Meaning
(Binary) (Decimal) (Ground Track in degrees)
0 0000 0 Ground Track is ZERO
0 0001 1 Ground Track = 11.25 degrees
*** *** ***
20xx, RTCA, Inc.

780
2.4.17.3.5.7 Verification of the Ground Speed (2.2.17.3.5.7)

This test procedure verifies the 6-bit (ME bits 26 through 31) field that defines the aircraft
speed over the ground. Coding of this field is specified in Table 2-107.
Step 1: Verification of Ground Speed Data Not Available

position message with (ME bits 26-31) set to ALL ZEROs (binary 00 0000) to
indicate data not available. Verify that data not available for ground speed is
Step 2: Verification of Ground Speed Discrete Values

position message with (ME bits 26-31) set to ONE (binary 00 0001) to indicate
a ground speed less than 16 knots.
Verify that ground speed less than 16 knots is reflected in the output TIS-B
Report. Repeat this step for eight more values chosen at random from Table 2-
107 and, in each case, verify that the input value is correctly reflected in the output
TIS-B Report.
2.4.17.3.5.8 Verification of the 12-bit CPR Decoded Latitude and Longitude (2.2.17.3.5.8)
The ENCODED LATITUDE and the ENCODED LONGITUDE subfields are 12-bit
fields, ME Bits 33 through 44 and ME bits 45 through 56, in the TIS-B Coarse Position
Message. The following test procedure verifies that the ADS-B Transmitting Subsystem
correctly receives Latitude and Longitude position data from the incoming TIS-B Coarse
Position Message and outputs decoded Latitude and Longitude data in the TIS-B Report.
The following procedure verifies the static Latitude and Longitude decoding where the
velocity input is 0.0 knots to verify the actual CPR Latitude and Longitude decoding
precision.
The Encoded Latitude and the Encoded Longitude subfields are 12-bit fields (ME Bits
33 through 44 and ME Bits 45 through 56) in the TIS-B Coarse Position Message. The
following test procedure verifies that the ADS-B Receiving Subsystem correctly receives
Latitude and Longitude position data from the incoming TIS-B Coarse Position Message
and outputs decoded Latitude and Longitude data in the TIS-B Report. The Latitude and
20xx, RTCA, Inc.

781
Longitude data are encoded according to the Compact Position Reporting (CPR) Format
described in Appendix A. The Latitude and Longitude data are dependent upon the
positional accuracy supported by the TIS-B site.
The following procedure verifies the static Latitude and Longitude encoding where the
velocity input is 0.0 knots to verify the actual CPR Latitude and Longitude decoding
precision.

information directly to the Receiving Subsystem being sure to set the velocity
input to ZERO (0).
Step 2: Verify Encoded Latitude and Longitude Data
1. Provide the ADS-B Receiving Subsystem with an even formatted

TIS-B Coarse Airborne Position Message containing the exact latitude
and longitude data pair provided in the first row of the Even Airborne
Encoding Column in Table 2-205.
2. Within ten seconds, provide the ADS-B Receiving Subsystem with an

odd formatted TIS-B Coarse Airborne Position Message containing the
exact latitude and longitude data pair provided in the first row of the Odd
Airborne Encoding Column in Table 2-205.
3. For each Even interval TIS-B Coarse Position Message that is simulated:
Verify that the CPR Format (F) subfield is set to ZERO (0).
For each Odd interval TIS-B Coarse Position Message that is simulated:
Verify that the CPR Format (F) subfield is set to ONE (1).
Verify that the Reported Binary decoded Latitude and Longitude datum,
in the output TIS-B Report, match the corresponding values in the
Angular Weighted Binary columns on the same row in Table 2-205.
If the decoding is not exact, verify that the decoding does not differ from
If the decoded value differs from the table value by more than 1 LSB,
then the test is considered to have failed. Other wise the test is passed.
Repeat this procedure for each row in Table 2-205.
20xx, RTCA, Inc.

782
Table 2-205: 12-bit CPR Airborne Position Encoding Values

Even Airborne Odd Airborne
Encoding Encoding
-90.0000 C0000000 -180.0000 80000000 000 800 400 800
-89.9500 C0091A2B 179.5000 7FA4FA50 022 7FA 422 7FA
-89.5000 C05B05B0 178.5000 7EEEEEEF 155 7EF 550 7EF
-89.0000 C0B60B61 175.5000 7CCCCCCD 2AB 7CD 69F 7CD
-87.5000 C1C71C72 -165.0000 8AAAAAAB 6AB 8AB A8E 8AB
-86.7500 C24FA4FA -171.5000 860B60B6 8AB 0C1 C86 861
-86.5000 C27D27D2 -172.5000 85555555 955 900 D2E 0AB
-85.8500 C2F37C05 65.7500 2EC16C17 B11 8C4 EE2 5D8
-85.0000 C38E38E4 -142.7500 9A7D27D2 D55 69F 11C CF7
-84.2500 C416C16C 60.0000 2AAAAAAB F55 D55 314 AAB
-83.5500 C4962FC9 -60.0000 D5555555 133 000 4EA 2AB
-82.6800 C53490BA 120.0000 55555555 385 555 732 000
-81.7500 C5DDDDDE -120.0000 AAAAAAAB 600 555 9A2 AAB
-80.2500 C6EEEEEF 144.0000 66666666 A00 99A D91 333
-79.7500 C749F49F -144.0000 9999999A B55 000 EE1 666
-78.4000 C83FB7F2 -121.0000 A9F49F4A EEF 4D8 26B A39
-77.4000 C8F5C28F 121.0000 560B60B6 19A 089 50A B28
-76.5500 C9907F6E -154.2800 924A2EE0 3DE 6DC 745 DB8
-75.6000 CA3D70A4 154.2800 6DB5D120 666 FFF 9C3 924
-74.7500 CAD82D83 157.5000 70000000 8AB 900 BFD 200
-73.6500 CBA06D3A -157.5000 90000000 B9A 000 EE0 700
-72.7500 CC444444 -120.0000 AAAAAAAB E00 555 13C AAB
-71.5500 CD1EB852 120.0000 55555555 133 000 461 AAB
-70.6500 CDC28F5C -144.0000 9999999A 39A 666 6BD CCD
-69.5500 CE8ACF13 144.0000 66666666 689 000 9A0 99A
-68.7500 CF1C71C7 -114.5500 AE8ACF13 8AB 516 BB9 A2E
-67.7500 CFD27D28 114.5500 517530ED B55 001 E58 AEA
-66.5500 D0ACF135 -67.5000 D0000000 E89 B00 17E E00
-65.5500 D162FC96 67.5000 30000000 133 800 41D 500
-64.4500 D22B3C4D -83.0800 C4EBBF60 422 3B0 6FF 762
-63.2500 D305B05B 83.0800 3B1440A0 755 001 A25 C50
-62.2500 D3BBBBBC -64.2900 D2485CD8 A00 2DA CC4 5B6
-61.2500 D471C71C 64.2900 2DB7A328 CAB 001 F64 D26
-60.2500 D527D27D -72.0000 CCCCCCCD F55 333 203 666
-59.9600 D55C9D78 -120.5000 AA4FA4FA 01B 4B0 2C6 A0B
-59.9300 D5621392 -119.5000 AB05B05B 030 0AB 2DA 5FA
-58.0000 D6C16C17 -78.7500 C8000000 555 380 7E9 700
-58.5000 D6666666 78.7500 38000000 400 C80 69A 900
-57.9500 D6CA8642 -22.5000 F0000000 577 100 80B 200
-56.8500 D792C5F9 22.5000 10000000 866 000 AED F00
-55.5000 D8888889 -52.9400 DA5A912E C00 25B E77 4B5
-54.6200 D928BB81 52.9400 25A56ED2 E59 000 0C6 DA5
-53.2500 DA222222 -30.0000 EAAAAAAB 200 155 45E 2AB
-51.9500 DB0ECA86 30.0000 15555555 577 000 7C7 EAB
20xx, RTCA, Inc.

783
Table 2-205: 12-bit CPR Airborne Position Encoding Values (Continued)

Encoding Encoding
-50.7500 DBE93E94 -75.7900 CA1ADA00 8AB 35E AEC 6BC
-49.6500 DCB17E4B 75.7900 35E52600 B9A 000 DCF CA2
-48.2500 DDB05B06 -27.0000 ECCCCCCD F55 133 17A 266
-47.0000 DE93E93F 27.0000 13333333 2AB 000 4C1 ECD
-45.6000 DF92C5F9 -68.5700 CF3D3663 666 30D 86D 619
-44.2500 E0888889 -180.0000 80000000 A00 000 BF7 800
-42.8500 E1876543 179.5000 7FA4FA50 DBC 70B FA3 F11
-41.4000 E28F5C29 178.5000 7EEEEEEF 19A D11 371 522
-40.0000 E38E38E4 175.5000 7CCCCCCD 555 F00 71C 733
-38.5000 E49F49F5 -160.9000 8D950C84 955 70D B0B E33
-36.9000 E5C28F5C -171.5000 860B60B6 D9A 9C1 F3D 161
-35.2500 E6EEEEEF -172.5000 85555555 200 000 391 7AB
-33.6000 E81B4E82 65.7500 2EC16C17 666 F30 7E5 C44
-31.8000 E962FC96 -142.7500 9A7D27D2 B33 2C7 C9D 91F
-30.0000 EAAAAAAB 59.5000 2A4FA4FA 000 6DE 155 439
-28.0000 EC16C16C -60.0000 D5555555 555 555 694 800
-25.9000 ED950C84 -66.7000 D091A2B4 AEF 2E2 C16 5D9
-23.6000 EF37C049 -120.0000 AAAAAAAB 111 000 21E 555
-21.1000 F0FEDCBB 41.5000 1D82D82E 7BC 572 8AC 39A
-18.2000 F30ECA86 -144.0000 9999999A F77 99A 047 000
-14.9000 F56789AC -121.0000 A9F49F4A 844 D77 8EE 2D8
-10.5000 F8888889 121.0000 560B60B6 400 7E9 477 289
-5.1000 FC5F92C6 6.2500 0471C71C 266 064 2A0 01C
-2.5000 FE38E38E 154.2800 6DB5D120 955 48E 972 DB3
0.0000 00000000 60.0000 2AAAAAAB 000 D55 000 AAB
0.0000 00000000 -157.5000 90000000 000 300 000 A00
90.0000 40000000 -180.0000 80000000 000 800 C00 800
89.9500 3FF6E5D5 179.5000 7FA4FA50 FDE 7FA BDE 7FA
89.5000 3FA4FA50 178.5000 7EEEEEEF EAB 7EF AB0 7EF
89.0000 3F49F49F 175.5000 7CCCCCCD D55 7CD 961 7CD
87.5000 3E38E38E -165.0000 8AAAAAAB 955 8AB 572 8AB
86.7500 3DB05B06 -171.5000 860B60B6 755 0C1 37A 861
86.5000 3D82D82E -172.5000 85555555 6AB 900 2D2 0AB
85.8500 3D0C83FB 65.7500 2EC16C17 4EF 8C4 11E 5D8
85.0000 3C71C71C -142.7500 9A7D27D2 2AB 69F EE4 CF7
84.2500 3BE93E94 60.0000 2AAAAAAB 0AB D55 CEC AAB
83.5500 3B69D037 -60.0000 D5555555 ECD 000 B16 2AB
82.6800 3ACB6F46 120.0000 55555555 C7B 555 8CE 000
81.7500 3A222222 -120.0000 AAAAAAAB A00 555 65E AAB
80.2500 39111111 144.0000 66666666 600 99A 26F 333
79.7500 38B60B61 -144.0000 9999999A 4AB 000 11F 666
78.4000 37C048D1 -121.0000 A9F49F4A 111 4D8 D95 A39
77.4000 370A3D71 121.0000 560B60B6 E66 089 AF6 B28
76.5500 366F8092 -154.2800 924A2EE0 C22 6DC 8BB DB8
75.6000 35C28F5C 154.2800 6DB5D120 99A FFF 63D 924
74.7500 3527D27D 157.5000 70000000 755 900 403 200
73.6500 345F92C6 -157.5000 90000000 466 000 120 700
72.7500 33BBBBBC -120.0000 AAAAAAAB 200 555 EC4 AAB
71.5500 32E147AE 120.0000 55555555 ECD 000 B9F AAB
70.6500 323D70A4 -144.0000 9999999A C66 666 943 CCD
69.5500 317530ED 144.0000 66666666 977 000 660 99A
20xx, RTCA, Inc.

784
Table 2-205: 12-bit CPR Airborne Position Encoding Values (Continued)

Encoding Encoding
68.7500 30E38E39 -114.5500 AE8ACF13 755 516 447 A2E
67.7500 302D82D8 114.5500 517530ED 4AB 001 1A8 AEA
66.5500 2F530ECB -67.5000 D0000000 177 B00 E82 E00
65.5500 2E9D036A 67.5000 30000000 ECD 800 BE3 500
64.4500 2DD4C3B3 -83.0800 C4EBBF60 BDE 3B0 901 762
63.2500 2CFA4FA5 83.0800 3B1440A0 8AB 001 5DB C50
62.2500 2C444444 -64.2900 D2485CD8 600 2DA 33C 5B6
61.2500 2B8E38E4 64.2900 2DB7A328 355 001 09C D26
60.2500 2AD82D83 -72.0000 CCCCCCCD 0AB 333 DFD 666
59.9600 2AA36288 -120.5000 AA4FA4FA FE5 4B0 D3A A0B
59.9300 2A9DEC6E -119.5000 AB05B05B FD0 0AB D26 5FA
58.0000 293E93E9 -78.7500 C8000000 AAB 380 817 700
58.5000 2999999A 78.7500 38000000 C00 C80 966 900
57.9500 293579BE -22.5000 F0000000 A89 100 7F5 200
56.8500 286D3A07 22.5000 10000000 79A 000 513 F00
55.5000 27777777 -52.9400 DA5A912E 400 25B 189 4B5
54.6200 26D7447F 52.9400 25A56ED2 1A7 000 F3A DA5
53.2500 25DDDDDE -30.0000 EAAAAAAB E00 155 BA2 2AB
51.9500 24F1357A 30.0000 15555555 A89 000 839 EAB
50.7500 2416C16C -75.7900 CA1ADA00 755 35E 514 6BC
49.6500 234E81B5 75.7900 35E52600 466 000 231 CA2
48.2500 224FA4FA -27.0000 ECCCCCCD 0AB 133 E86 266
47.0000 216C16C1 27.0000 13333333 D55 000 B3F ECD
45.6000 206D3A07 -68.5700 CF3D3663 99A 30D 793 619
44.2500 1F777777 -180.0000 80000000 600 000 409 800
42.8500 1E789ABD 179.5000 7FA4FA50 244 70B 05D F11
41.4000 1D70A3D7 178.5000 7EEEEEEF E66 D11 C8F 522
40.0000 1C71C71C 175.5000 7CCCCCCD AAB F00 8E4 733
38.5000 1B60B60B -160.9000 8D950C84 6AB 70D 4F5 E33
36.9000 1A3D70A4 -171.5000 860B60B6 266 9C1 0C3 161
35.2500 19111111 -172.5000 85555555 E00 000 C6F 7AB
33.6000 17E4B17E 65.7500 2EC16C17 99A F30 81B C44
31.8000 169D036A -142.7500 9A7D27D2 4CD 2C7 363 91F
30.0000 15555555 59.5000 2A4FA4FA 000 6DE EAB 439
28.0000 13E93E94 -60.0000 D5555555 AAB 555 96C 800
25.9000 126AF37C -66.7000 D091A2B4 511 2E2 3EA 5D9
23.6000 10C83FB7 -120.0000 AAAAAAAB EEF 000 DE2 555
21.1000 0F012345 41.5000 1D82D82E 844 572 754 39A
18.2000 0CF1357A -144.0000 9999999A 089 99A FB9 000
14.9000 0A987654 -121.0000 A9F49F4A 7BC D77 712 2D8
10.5000 07777777 121.0000 560B60B6 C00 7E9 B89 289
5.1000 03A06D3A 6.2500 0471C71C D9A 064 D60 01C
2.5000 01C71C72 154.2800 6DB5D120 6AB 48E 68E DB3
0.0000 00000000 60.0000 2AAAAAAB 000 D55 000 AAB
0.0000 00000000 -157.5000 90000000 000 300 000 A00
2.4.17.4 Verification of TIS-B Message Processing and Report Generation (2.2.17.4)

No specific test is required to validate 2.2.17.4.
20xx, RTCA, Inc.

785
2.4.17.4.1 Verification of TIS-B Message-to-Track Correlation (2.2.17.4.1)

Appropriate tests for validating 2.2.17.4.1 are contained in 2.4.17.4.2, 2.4.17.4.3,
2.4.17.4.4, and 2.4.17.4.6.
2.4.17.4.1.1 Verification of TIS-B Messages Having a 24-Bit Address (2.2.17.4.1.1)

For a target that has a 24-bit address, that address is used for correlating new receptions with
information in the track file. Correlation is successful if the address matches exactly. If the
24-bit address in a received message is either all ZEROs or all ONEs, it is considered to be
illegal, and the message will be discarded. Otherwise, when a TIS-B Position Message
having a 24-bit address is received, and an existing TIS-B track has the same address, the
message will be correlated with the track as specified in 2.2.17.4.1.1.
Step 1: Verification of the Correlation of a Received TIS-B with an Existing TIS-B Track

position message containing an ICAO 24-bit address. Within two minutes, input
another different TIS-B message with the same ICAO address as the previous
message and verify that the position information in the second TIS-B position
message is reflected in the output TIS-B Report.
Step 2: Verification of the correlation of a Received TIS-B with an Existing ADS-B Track
Set up to simulate ADS-B and TIS-B Transmitted Messages by inputting ADS-B

and TIS-B Message information directly to the Receiving Subsystem. Input a
simulated ADS-B position message containing an ICAO 24-bit address. Within
two minutes, input a TIS-B message with a different position and the same ICAO
address as the ADS-B message and verify that the position information in the TIS-
B position message is reflected in the output TIS-B Report.
2.4.17.4.1.2 Verification of TIS-B Messages Having Mode A Code and Track Number
(2.2.17.4.1.2)
For a target not identified by a 24-bit address, but instead having a Mode A code and a
TIS-B track number, then these are used to correlate with information in the track file.
Correlation is successful if the Mode A code and the track number both match exactly.
When a TIS-B Message having a Mode A code and TIS-B track number is received, and an
existing TIS-B track has the same Mode A code and ADS-B track number, the message will
be correlated with the track as specified in 2.2.17.4.1.2.
20xx, RTCA, Inc.

786

directly to the Receiving Subsystem. Input a simulated TIS-B position message containing
a 12-bit Mode A code followed by a 12-bit track file number. Within two minutes, input
another different TIS-B position message with the same 12-bit Mode A code followed by
the same 12-bit track file number as the previous message and verify that the position
information in the second TIS-B position message is reflected in the output TIS-B Report.
2.4.17.4.2 Verification of TIS-B Position Message Decoding (2.2.17.4.2)

This test procedure verifies the requirements of TIS-B Position Message decoding as
Step 1: Verification of Global Decoding on the Reception of Even and Odd Formats
Within 10 Seconds

position message with an even format. Within ten seconds, input another TIS-B
position message with an odd format. Verify that a Global decode has
occurred by ensuring that the input position information is reflected in the output
TIS-B Report.
Step 2: Verification of Local Decoding, on Reception, When the Track is Complete
Input another simulated TIS-B position message within ten seconds of those in
step 1 above. Verify that a Local decode has occurred by ensuring that the new
input position information is reflected in the output TIS-B Report.
Step 3: Verification of the Storage of Track File Information
Wait more than ten seconds after step 2 above and input another TIS-B position
message. Verify that this new input information is stored in the track file for later
use and that it is not reflected in the output TIS-B Report.
Note: It is not necessary to save any encoded positions longer than 10 seconds.
2.4.17.4.3 Verification of TIS-B Track Update (2.2.17.4.3)

This test procedure verifies the requirements for TIS-B Track Update as specified in
2.2.17.4.3.
20xx, RTCA, Inc.

787
Step 1: Verification of Position and (TOA) Updates Complete Track

position message with an even format. Within ten seconds, input another TIS-B
position message with an odd format. This should create a Complete track.
Again, within ten seconds, input another position message. This should trigger a
local decode and update the data fields. Verify that this new position and its
corresponding TOA are reflected in the output TIS-B Report.
Step 2: Verification of Incomplete to Complete Track Promotion and Data Storage

position message with an even format. This should create an Incomplete track.
Within ten seconds, input another TIS-B position message with an odd format.
This should trigger a global decode and Complete the track. Verify that the track
has been promoted to Complete and that the latter input position and TOA are
saved in the track.
Step 3: Verification of Data Storage When Global Decode Does Not Occur

position message with an even format. After more than ten seconds, input
another position message. In this case a global decode should not occur. Verify
that the track is still Incomplete and that the latter position and TOA are saved for
possible future decodes.
2.4.17.4.4 Verification of TIS-B Track Initiation (2.2.17.4.4)

This test procedure verifies the requirements of the TIS-B Track Initiation as specified in
2.2.17.4.4.

directly to the Receiving Subsystem. Input a simulated TIS-B position message with an
even format.
Verify that there is an Incomplete track created and that the position, TOA and even/odd bit
are saved. Wait 125 seconds (to allow the first track to be dropped) and repeat this
procedure with an odd formatted position message and verify the same parameters.
20xx, RTCA, Inc.

788
2.4.17.4.5 Verification of TIS-B Track Drop (2.2.17.4.5)

This test procedure verifies the requirements of TIS-B Track Drop as specified in
2.2.17.4.5.

directly to the Receiving Subsystem. Input a simulated TIS-B position message with an
even format. Within ten seconds, input another TIS-B position message with an odd
format. This should create a Complete track.
Verify that 120 seconds after the odd position message is received, the position and TOA
information are still saved in the track. Verify that 125 seconds after the odd position
message is received, the position and TOA information are dropped (i.e.) the corresponding
data fields are set to ALL ZEROs.
2.4.17.4.6 Verification of TIS-B Report Generation (2.2.17.4.6)

This test procedure verifies the requirements of TIS-B Report Generation as specified in
2.2.17.4.6.
Step 1: Verification of Non-Position Report Elements and Timing

message.
Verify that within 0.5 seconds of the receipt of this message that all of the non-
position elements are reported directly as received. Repeat this step for each of
the TIS-B message types.
Step 2: Verification of Position Report Elements and Timing

message.
Verify that within 0.5 seconds of the receipt of this message that all of the position
elements (latitude, longitude, altitude, address and TOA) are reported directly as
well as all of the other information received, including all reserved fields for the
TIS-B fine format messages (2.2.17.3.1 to 2.2.17.3.4) and the entire message
content (i.e., including the complete 88-bit content of the DF, CF, AA and ME
fields of the Extended Squitter Message) of any received TIS-B Management
20xx, RTCA, Inc.

789
Message (Table 2-106, for CF=4). Repeat this step for each of the TIS-B message
types.
2.4.18 Verification of the ADS-B Rebroadcast Service Formats and Coding (2.2.18)
2.4.18.1 Verification of the Introduction (2.2.18.1)

2.4.18.2 Verification of the ADS-B Rebroadcast Format Definitions (2.2.18.2)

Appropriate test procedures required to validate the transmission and reception of ADS-B
Rebroadcast Messages are provided in the subparagraphs of 2.4.18.4 below.
2.4.18.3 Verification of the Control Field Allocations (2.2.18.3)

Rebroadcast Messages are provided in the subparagraphs of 2.4.18.4 below.
2.4.18.4 Verification of the ADS-B Rebroadcast Surveillance Message Definitions (2.2.18.4)

accomplished by utilizing the same ADS-B Message formats defined in Figure A-1 through
Figure A-10, with the exception of the need to transmit an indication to the 1090 MHz
Receiving Subsystem as to the type of identity associated with the aircraft data being
reported in the ADS-B Rebroadcast Message. This identification is performed using the
ICAO/Mode A Flag (IMF), which was previously discussed in 2.2.17.3.1.2 for the TIS-B
transmissions.
The insertion of this one bit into the 1090ES ADS-B Messages identified in the
subparagraphs below allows the ADS-B Receiving Subsystem to interpret the Address Field
(AF) in the following manner:
Address.
IMF = 1 indicates that the ADS-B Rebroadcast data is identified by an anonymous 24-bit
address or ground vehicle address or fixed obstruction address.
Rebroadcast Messages are provided in 2.4.18.4.1 through 2.4.18.4.7 below.
20xx, RTCA, Inc.

790
2.4.18.4.1 Verification of the Rebroadcast of ADS-B Airborne Position Messages (2.2.18.4.1)

These test procedures verify that the ME Field of the Rebroadcast Airborne Position
Message is formatted as specified in Figure 2-3, except that ME bit 8 is redefined to be the
ICAO/Mode A Flag (IMF).
Configure the ADS-B test equipment to transmit Airborne Position Messages by

providing position information at the nominal rate. Ensure the transmission of an
ADS-N Aircraft Operational Status Message to ensure receipt of the Version
Number. Ensure that the ADS-B test equipment provides a known value of
Latitude and Longitude position data from the Navigation source and that it
outputs encoded Latitude and Longitude data for the Airborne Position Message in
accordance with the CPR Format described in Appendix A. Format the Airborne
Position Message with both DF=18 and CF=4, and DF=18 and CF=6.
Step 2: Valid Message Contents When Selecting ICAO 24-Bit Address
Input an IMF value of ZERO (0) into ME Bit 8 of the Airborne Position Message
to be transmitted. Input AAAAAA {HEX} for the ICAO 24-Bit Address. Select
ICAO 24-Bit Address at the Address Qualifier input to the ADS-B test
equipment. Verify the following ADS-R Message content upon decode of the
transmitted data:
DF field (Message Bits 1 5) equals decimal 18

CF field (Message Bits 6 8) equals decimal 4 or 6 as appropriate
AA field (Message Bits 9 32) equals AAAAAA {HEX}
TYPE Code field (Message Bits 33 37) equals 9 to 18 or 20 to 22
IMF field (Message Bit 40) equals ZERO (0)
Lat/Lon fields equal transmitted Lat/Lon
Verify that the remaining fields of the ADS-R Airborne Position Message, that is
received and decoded, was encoded in the proper format, i.e., odd and even
encoding, by correlating the received Message to the stimulus data provided by
the test equipment.
Step 3: Valid Message Contents When Selecting Anonymous Address
Input an IMF value of ONE (1) into ME Bit 8 of the Airborne Position Message to
be transmitted. Input 555555 {HEX} for the Anonymous Address. Select
Anonymous Address at the Address Qualifier input to the ADS-B test
transmitted data:
20xx, RTCA, Inc.

791

CF field (Message Bits 6 8) equals decimal 4 or 6, as appropriate
AA field (Message Bits 9 32) equals 555555 {HEX}
TYPE Code field (Message Bits 33 37) equals 9 to 18 or 20 to 22
IMF field (Message Bit 40) equals ONE (1)
Verify that the remaining fields of the ADS-R Airborne Position Message, that is
the test equipment.
2.4.18.4.2 Verification of the Rebroadcast of ADS-B Surface Position Messages (2.2.18.4.2)

These test procedures verify that the ME Field of the Rebroadcast Surface Position Message
is formatted as specified in Figure 2-5, except that ME bit 21 is redefined to be the
Configure the ADS-B test equipment to transmit Surface Position Messages by

providing position information at the nominal rate. Ensure that the ADS-B test
equipment provides a known value of Latitude and Longitude position data from
the Navigation source and that it outputs encoded Latitude and Longitude data for
the Surface Position Message in accordance with the CPR Format described in
Appendix A. Format the Surface Position Message with both DF=18 and CF=4
and DF=18 and CF=6.
Input an IMF value of ZERO (0) into ME Bit 21 of the Surface Position Message
to be transmitted. Input AAAAAA {HEX} for the ICAO 24-Bit Address. Select
transmitted data:

TYPE Code field (Message Bits 33 37) equals decimal 5 to 8
20xx, RTCA, Inc.

792
Verify that the remaining fields of the ADS-R Surface Position Message, that is
the test equipment.
Input an IMF value of ONE (1) into ME Bit 8 of the Surface Position Message to
be transmitted. Input 555555 {HEX} for the Anonymous Address. Select
transmitted data:

TYPE Code field (Message Bits 33 37) equals decimal 5 to 8
Verify that the remaining fields of the ADS-R Surface Position Message, that is
the test equipment.
2.4.18.4.3 Verification of the Rebroadcast of ADS-B Aircraft Identification and Category

Messages (2.2.18.4.3)
This test procedure verifies that the ME Field of the Rebroadcast Aircraft Identification and
Category Message is formatted exactly as specified in Figure 2-6.
Note: Any Rebroadcast Aircraft Identification and Category Message does not contain the
IMF bit since aircraft using an anonymous 24-bit address will not provide identity
and category information.
The test procedures provided in 2.4.3.2.5 and its subparagraphs shall be used to validate
the transmission and reception of Rebroadcast Aircraft Identification and Category
Messages.
20xx, RTCA, Inc.

793
2.4.18.4.4 Verification of the Rebroadcast of ADS-B Airborne Velocity Messages (2.2.18.4.4)

These test procedures verify that the ME Field of the Rebroadcast Airborne Velocity
Messages is formatted as specified in Figure 2-7 for Subtype 1 & 2 Messages, and in Figure
2-8 for Subtype 3 & 4 Messages, except that ME bit 9 is redefined to be the ICAO/Mode A
Flag (IMF).
Configure the ADS-B test equipment to transmit Version ONE (1) and TWO (2)
Airborne Velocity Messages by providing velocity information at the nominal
update rate. Provide the data externally at the interface to the ADS-B test
equipment. Set up the system to enable broadcast of Airborne Velocity Messages
(see additional information in 2.2.3.3.2.5). Set the ADS-B test equipment to
Airborne status.
Step 2: Verification of Subtype 1 Messages with ICAO 24-Bit Address
Provide velocity information in the form of Velocity Over Ground (i.e., Ground
Speed) with a valid value that is greater than ZERO, but non-supersonic (i.e., both
North/South and East/West Velocity inputs are less than 1000 knots). Input an
IMF value of ZERO (0) into ME Bit 9 of the Airborne Velocity Message to be
transmitted. Input AAAAAA {HEX} for the ICAO 24-Bit Address. Select
equipment. Verify the following ADS-R Airborne Velocity Message content
upon decode of the transmitted data:

CF field (Message Bits 6 8) equals decimal 6
TYPE Code field (Message Bits 33 37) equals decimal 19
Subtype Code field (Message Bits 38 40) equals decimal 1
Decoded N/S and E/W Velocity values equal transmitted values
Verify the remaining fields of the ADS-R Airborne Velocity Message, by

correlating the decoded Message to the stimulus data provided by the test
equipment, being sure to match the data format to the correct Version Number.
Repeat the same setup as in Step 2 above. Increase the North/South velocity to
1050 knots. Verify the following ADS-R Airborne Velocity Message content
20xx, RTCA, Inc.

794

Decoded N/S and E/W Velocity values equal transmitted values

Provide velocity information in the form of Airspeed and Heading information

with a valid Airspeed value that is greater than ZERO, but non-supersonic (i.e.,
the Airspeed input is less than 1000 knots). Input an IMF value of ZERO (0) into
ME Bit 9 of the Airborne Velocity Message to be transmitted. Input AAAAAA
{HEX} for the ICAO 24-Bit Address. Select ICAO 24-Bit Address at the
Address Qualifier input to the ADS-B test equipment. Verify the following ADS-
R Airborne Velocity Message content upon decode of the transmitted data:

Decoded Airspeed Velocity value equals transmitted value

Repeat the same setup as in Step 4 above. Increase the Airspeed velocity to 1050
knots. Verify the following ADS-R Airborne Velocity Message content upon
decode of the transmitted data:
20xx, RTCA, Inc.

795

Decoded Airspeed Velocity value equals transmitted value

Step 6: Verification of Airborne Velocity Messages with Anonymous Addresses
Repeat the setups of Steps 2, 3, 4 and 5, respectively, except that the input for the
Address shall be 555555 {HEX} for the Anonymous Address. Select
equipment for each respective Test Step. Input an IMF value of ONE (1) into ME
Bit 9 of each respective Airborne Velocity Message to be transmitted. Verify that
the content of the ADS-R Airborne Velocity Message upon decode of the
transmitted data matches those outputs defined in Steps 2, 3, 4 and 5, respectively,
except that the AA field (Message Bits 9 32) equals 555555 {HEX}, and the
IMF field (Message Bit 41) equals ONE (1), in each case, being sure to match the
data format to the correct Version Number.
2.4.18.4.5 Verification of the Rebroadcast of ADS-B Aircraft Emergency/Priority Status

Messages (2.2.18.4.5)
These test procedures verify that the ME Field of the Rebroadcast Aircraft
Emergency/Priority Status Message is formatted as specified in Figure 2-13, except that ME
bit 56 is redefined to be the ICAO/Mode A Flag (IMF).
Perform set up of the unit under test as specified in the Test Procedure in
2.4.3.2.7.8.
Input an IMF value of ZERO (0) into ME Bit 56 of the Aircraft

Emergency/Priority Status Message to be transmitted. Input AAAAAA {HEX}
for the ICAO 24-Bit Address. Select ICAO 24-Bit Address at the Address
20xx, RTCA, Inc.

796
Qualifier input to the ADS-B Transmitting Subsystem. Verify the following

ADS-R Message content upon decode of the transmitted data:

Verify the remaining fields of the ADS-R Aircraft Emergency/Priority Status

Message, by correlating the decoded Message to the stimulus data provided by the
test equipment.
Reinitialize the unit under test as in Step 1 above. Input an IMF value of ONE (1)
into ME Bit 56 of the Aircraft Emergency/Priority Status Message to be
transmitted. Input 555555 {HEX} for the Anonymous Address. Select
Anonymous Address at the Address Qualifier input to the ADS-B Transmitting
Subsystem. Verify the following ADS-R Message content upon decode of the
transmitted data:

Verify the remaining fields of the ADS-R Aircraft Emergency/Priority Status

Message, by correlating the decoded Message to the stimulus data provided by the
test equipment.
2.4.18.4.6 Verification of the Rebroadcast of ADS-B Target State and Status Messages
(2.2.18.4.6)
These test procedures verify that the ME Field of the Rebroadcast Target State and Status
Message is formatted as specified in Figure 2-10, except that ME bit 51 is redefined to be
the ICAO/Mode A Flag (IMF).
20xx, RTCA, Inc.

797
Configure the ADS-B Transmitting Subsystem to transmit Target State and Status
Messages by providing valid trajectory information at the nominal rate. Provide
Transmitting Subsystem to Airborne status.
Input an IMF value of ZERO (0) into ME Bit 51 of the Target State and Status
Message to be transmitted. Input AAAAAA {HEX} for the ICAO 24-Bit
Address. Select ICAO 24-Bit Address at the Address Qualifier input to the
ADS-B Transmitting Subsystem. Verify the following ADS-R Message content

Verify the remaining fields of the ADS-R Target State and Status Message, by
equipment.
into ME Bit 51 of the Target State and Status Message to be transmitted. Input
555555 {HEX} for the Anonymous Address. Select Anonymous Address at the
Address Qualifier input to the ADS-B Transmitting Subsystem. Verify the
following ADS-R Message content upon decode of the transmitted data:

Verify the remaining fields of the ADS-R Target State and Status Message, by
equipment.
20xx, RTCA, Inc.

798
2.4.18.4.7 Verification of the Rebroadcast of ADS-B Aircraft Operational Status Messages

(2.2.18.4.7)
These test procedures verify that the ME Field of the Rebroadcast Aircraft Operational
Status Message is formatted as specified in Figure 2-11, except that ME bit 56 is redefined
to be the ICAO/Mode A Flag (IMF).

Status Messages by providing valid trajectory information at the nominal rate.
Provide the data externally at the interface to the ADS-B system. Set the ADS-B
Transmitting Subsystem to Airborne status.
Input an IMF value of ZERO (0) into ME Bit 56 of the Aircraft Operational Status
Message to be transmitted. Input AAAAAA {HEX} for the ICAO 24-Bit
Address. Select ICAO 24-Bit Address at the Address Qualifier input to the
ADS-B Transmitting Subsystem. Verify the following ADS-R Message content

Verify the remaining fields of the ADS-R Aircraft Operational Status Message, by
equipment.
Repeat this step after setting the ADS-B Transmitting Subsystem to the On-
Ground status. Verify that the only difference in the decoded output of the
Message from those specified above is that Message Bits 38 40 are set to ONE
(1) in the output of the Aircraft Operational Status Message.
into ME Bit 56 of the Aircraft Operational Status Message to be transmitted.
Input 555555 {HEX} for the Anonymous Address. Select Anonymous Address
20xx, RTCA, Inc.

799
at the Address Qualifier input to the ADS-B Transmitting Subsystem. Verify the
following ADS-R Message content upon decode of the transmitted data:

Verify the remaining fields of the ADS-R Aircraft Operational Status Message, by
equipment.
Repeat this step after setting the ADS-B Transmitting Subsystem to the On-
Ground status. Verify that the only difference in the decoded output of the
Message from those specified above is that Message Bits 38 40 are set to ONE
(1) in the output of the Aircraft Operational Status Message.
20xx, RTCA, Inc.

800
3.0 Installed Equipment Performance

This section states the minimum acceptable level of performance for the equipment when
installed in the aircraft. Installed performance requirements are the same as contained in
section 2.2, which are verified through bench and environmental testing. Some system
attributes and performance aspects may be affected by the physical installation (e.g. antenna
patterns can affect system transmit and receive performance). System integrators might
have several options when connecting to aircraft sensors or data sources. Some sources
might lack the necessary range, resolution or accuracy to support the desired applications.
This section identifies system attributes which installation techniques and choices might
affect, beyond the equipment manufacturers ability to compensate.
Note: Installation of Non-Transponder-Based 1090 MHz ADS-B equipment in airplanes

equipped with Mode-S transponders is prohibited. The transmission of squitters in
addition to TCAS interrogation responses contributes unnecessary RF energy to the
spectral environment. TCAS systems (in other airplanes) cannot take advantage of
hybrid surveillance on the ADS-B data, since the non-transponder data cannot be
validated by TCAS interrogation. ADS-B data is not directly available to ground
interrogators as when read from transponder registers.
3.1 Installed Equipment Considerations

A complete ADS-B system consists of five (5) functional elements:
1. Data sources for aircraft position, velocity, flight plan, status, etc.
2. ADS-B transmitter
3. ADS-B receiver
4. Report Generator
5. Applications
Each of these elements must meet the minimum requirements for an application in order for
operational approval to be granted for that application. Table 3-1 is an example of a system
that meets the minimum requirements for 3 generic applications. Additional guidance for
determining requirements is contained in following paragraphs.
20xx, RTCA, Inc.

801
Table 3-1: Example System
Application Data Source ADS-B Equipment Class

VFR VFR GPS
A0/Type 1 (see Note)
(e.g. Aid to Visual Acquisition) (AC20-138 Compliant)
IFR
TSO C129a,
(e.g. Aid to Terminal Separation and A2/Type 1 (see Note)
Class A2 GPS Receiver
Sequencing)
Special IFR
TSO C129a,
(e.g. Closely Spaced Parallel A3/Type 2 (see Note)
Class A1S/A1 GPS
Approaches)
Receiver
Note: The type designation refers to the Receiver Report Generator type and is included
here as an example of equipment labeling and is not to imply any specific interface
is required. The developer is free to choose any of the interface types so long as it
is properly documented and meets the end-to-end system requirements.
3.1.1 Data Sources

Data sources necessary to support an application shall meet the requirements of the
operational environment (e.g. The source of ADS-B navigation data must be approved for
IFR navigation if the ADS-B application is to be approved for IFR operations.), and shall
meet the accuracy, range, and resolution requirements of the appropriate ADS-B equipage
category.
3.1.2 ADS-B Transmit Power

The Transmit Power requirement (i.e, Effective Radiated Power) is different for different
classes of equipment because of differences in altitude capabilities and ranges of
applications. The classes are defined in 2.1.12 and the power level in each class is defined
in 2.2.2.
Different classes of equipment have different minimum message capability requirements.

Transmitted message capability requirements for Class A and Class B transmitters are
defined in 2.1.12.1. Some applications may require support for specific On-Condition
Messages.
3.1.3 ADS-B Receiver

The receiver shall be capable of supporting the message types required by application.
The receiver sensitivity limits the expected range of the installed system. The sensitivity of
the installed receiving equipment should be appropriate to the minimum range requirement
for the ADS-B equipage class. Receivers having a Minimum Trigger Level (MTL) of 74
dBm are intended to support applications at ranges up to 20 nautical miles. Receivers
having a MTL of 79 dBm are intended to support applications at ranges up to 40 nautical
miles. Receivers having a MTL of 84 dBm are intended to support applications at ranges
up to 90 nautical miles.
20xx, RTCA, Inc.

802
3.1.4 Report Generator

The report generator function shall be capable of accepting all message types and
generating all reports appropriate to the intended applications. Special attention may be
necessary for Type 1 interfaces to ensure that the equipment is properly matched to the
application requirements.
3.1.5 Applications
Applications comprise any use of ADS-B data. Applications shall be developed in
accordance with approved standards if standards exist. If approved standards do not exist,
the developer shall propose a standard early in the development process to support approval
of the operational concept and identify operational limitations.
First time operational approval for the use of installed ADS-B equipment in a given
application will be accomplished via the Type Certificate (TC) or Supplemental Type
Certificate (STC) approval process. Subsequent installations may be approved via the TC,
STC, or field approval process. It is incumbent upon the developer to show that the system
meets the requirements of the application. Operating limits of the system shall be included
in an approved aircraft/rotorcraft flight manual supplement (AFMS/RFMS).
3.2 Equipment Installation
3.2.1 Aircraft Environment

Equipment shall be installed such that environmental conditions do not exceed the
manufacturers specifications during normal operations.
3.2.2 Aircraft Power Source

The supply voltage and allowable variation shall not exceed the manufacturers
specifications during normal operations. Equipment voltage and frequency tolerance
characteristics shall be compatible with an aircraft power source of appropriate category as
specified in RTCA DO-160F (EUROCAE, ED-14F).
3.2.2.1 Power Fluctuation

The equipment shall retain memory of variable data through aircraft power transfer, which
occurs during normal operation. Typical power transfer involves switching from external
power to internal power, either battery or APU generator, or to engine driven generator(s).
The equipment shall not require re-initialization for power transfer (i.e. power loss) for a
period up to 0.5 second maximum. Power transfer shall not latch a failure indication.
Momentary failure indications, during switching, are allowed.
3.2.3 Accessibility
Controls, indicators, and displays provided for in-flight use shall be readily accessible
and/or readable from the pilots normal seated position. If two pilots are required to operate
the aircraft, the controls must be readily accessible from each pilots seated position.
Adequate protection must be provided to prevent inadvertent turnoff of the equipment.
20xx, RTCA, Inc.

803
3.2.4 Display Visibility

If there is a control panel display, then appropriate flight crew member(s) must have an
unobstructed view of displayed data when in the seated position. The brightness of any
display must be adjustable to levels suitable for data interpretation under all cockpit ambient
lighting conditions ranging from total darkness to reflected sunlight.
Note: Visors, glare shields or filters may be an acceptable means of obtaining daylight
visibility.
3.2.5 Indicators
If visual indicators are installed, they shall be visible and readable from the pilots normal
seated position. If two pilots are required to operate the aircraft, indicators shall be visible
from each pilots seated position. The brightness of any indicator must be adjustable to
levels suitable under all cockpit ambient lighting conditions ranging from total darkness to
reflected sunlight. If an indication is distracting, a means to cancel it should be provided. If
the optional Extended Squitter Inhibit capability per 2.1.5.1 is provided, the indication
when activated shall be annunciated to the pilot.
3.2.6 Alerts
If appropriate to an application, a means to alert the crew shall be provided. Aural alerts
shall provide a mechanism by which they can be prioritized with respect to other aircraft
system alerts (e.g. audio inhibit input and output discretes). Aural alerts shall include a
means by which they can be silenced.
3.2.7 Failure Protection

Probable failures of the ADS-B equipment must not degrade the normal operation of
equipment or systems connected to it. The failure of connected equipment or systems must
not degrade normal operation of the ADS-B equipment except for loss of functions that are
directly dependent upon the failed equipment.
3.2.8 Failure Indication

The ADS-B system operational status shall be available to the crew. Failures of the ADS-B
transmitter and receiver shall be annunciated to the crew. Though acceptable, dedicated
ADS-B transmit and receive failure indicators are not required. Text messages, displayed to
the crew until acknowledged, are acceptable. Systems which combine transmit and receive
functions in a common unit may use a single annunciation to indicate a failure. When an
ADS-B function is hosted in another system, the host system failure annunciation is
adequate to indicate loss of ADS-B function (e.g. If the transponder also transmits ADS-B
squitters, loss of ADS-B transmission is logically assumed with a TRANSPONDER FAIL
indication.). Otherwise, transmitter and receiver failure warnings shall be independent
(2.2.11.5).
20xx, RTCA, Inc.

804
3.2.9 Interference Effects

The equipment shall not be the source of objectionable conducted or radiated interference
nor be adversely affected by conducted or radiated interference from other equipment or
systems installed in the aircraft. If these systems are installed, check for interference when
operating on TACAN channels 60 to 72; DME channels 65 to 67 (1089 - 1091 MHz paired
with VHF frequency 133.8 to 134.05)
Note: Electromagnetic compatibility problems noted after installation of this equipment

may result from such factors as the design characteristics of previously installed
systems or equipment and the physical installation itself. The installing facility is
responsible for resolving incompatibilities between the ADS-B equipment and
previously installed equipment in the aircraft.
3.3 Antenna Installation
3.3.1 General Considerations

Antenna gain and pattern characteristics are major contributors to the system data link
performance. The location and number of antennas required for aircraft ADS-B systems is
determined by the equipage class. Class A1, A2, and A3 equipment require antenna
diversity and shall have transmitting and receiving capability on both the top and bottom of
the aircraft. Class B1 equipment requires antenna diversity and shall have transmitting
capability on both the top and bottom of the aircraft. Diverse use of the installed antennas
shall comply with the requirements of 2.2.13.6 and may be demonstrated by analysis.
Class A0, A1S, B0 and B1S antenna gain pattern performance shall be shown at least
equivalent to that of a quarter-wave resonant antenna mounted on the fuselage bottom
surface.
If the ADS-B transmitter function is hosted in a Mode-S transponder, the antennas shall
comply with the requirements of RTCA DO-181D (EUROCAE ED-73C).
If the ADS-B receiver function is hosted in a TCAS computer, the antennas shall comply
with the requirements of RTCA DO-185B (EUROCAE ED-143).
3.3.2 Transmission Lines

Transmission lines to the antennas shall have impedance, power handling, and loss
characteristics in accordance with the equipment manufacturers specifications. The
VSWR, as seen through the transmission lines to the antenna(s), shall be within the limits
specified by the manufacturer.
When a transmission line is included as a part of the installation, all minimum installed
system performance requirements stated in section 2.2, must be met. Test results provided
by the equipment manufacturer may be accepted in lieu of tests performed by the equipment
installer.
20xx, RTCA, Inc.

805
3.3.3 Antenna Location

Antennas shall be mounted as near as practical to the center line of the fuselage. Antennas
shall be located to minimize obstruction to their fields in the horizontal plane.
Note: Where possible, it is recommended that the antennas be mounted on the forward
part of the fuselage, thereby minimizing blockage due to the vertical stabilizer and
engine nacelles.
3.3.3.1 Minimum Distance from Other Antennas

The spacing between any ADS-B antenna and any transponder (Mode-S or ATCRBS)
antenna shall be sufficient to provide a minimum of 20dB of isolation between the two
antennas.
Note: If both antennas are conventional omni-directional matched quarter-wave stubs, 20

dB of isolation is obtained by providing a spacing of at least 51 cm (20 in.) between
the centers of the two antennas. If either antenna is other than a conventional stub,
the minimum spacing must be determined by measurement.
3.3.3.2 Mutual Suppression

If other equipment installed in the aircraft operates at or near 1090 MHz, such as DME, the
need for mutual suppression shall be determined. When mutual suppression is used, the
requirements of 2.2.12 shall be met. There shall be no more than one active 1090 MHz
transmitter per aircraft at any time.
3.3.4 Antenna Gain Performance

Gain performance of the ADS-B antenna(s) is tested to verify that the installed antenna gain
is not degraded from 2.2.13 requirements, beyond an acceptable value. Transmit antenna(s)
shall be located such that a receiving system reliably receives data from the transmitting
aircraft at the minimum range appropriate to the equipage category, as stated in Table 3-2.
Receive antenna(s) shall be located such that a receiving system reliably receives data from
a transmitting aircraft at the minimum range appropriate to the equipage category, as stated
in Table 3-2. If a traffic display is installed, reliable data reception is indicated by traffic
target acquisition range and smooth movement of traffic targets, without excessive pop-
up, drop-out, or position jumps.
Note: Typical ADS-B antennas have areas of reduced gain, directly above or below the
antenna, such that no signal can be received from transmitters in the cone of
silence or uncertainty cone. Reliable data reception from these areas is not
required. Approval of operational applications should consider this limitation.
20xx, RTCA, Inc.

806
Table 3-2: Minimum Ranges for Receiving Reliability

Required
Equipage Range (NM)
Class Type
A0 Minimum 10
A1S/A1 Basic 20
A2 Enhanced 40
A3 Extended 90*
Extended Desired 120*

A3+
* For each equipage class, the value shown in Table 3-2 corresponds to forward directional
coverage. Port and starboard coverage may be one half of this value; aft may be one third
of this value. (Ref. RTCA DO-242A Table 3-2(a))
3.3.4.1 Gain Performance Verification

Gain performance can be verified using one or a combination of four distinct procedures:
(a) full scale antenna range measurements,
(b) scaled model measurements,
(c) theoretical calculations,
(d) distance-area calculations, to ensure that the location of the antenna on the aircraft does
not unduly degrade its gain performance.
This procedure(s) shall be performed on final installed equipment with all appropriate
connections and antenna in order to demonstrate proper operation of the final installation.
3.3.4.1.1 Success Criteria

At an elevation angle of zero degrees relative to the fuselage reference plane, the gain of the
forward 45 degree azimuth sector of both the top and bottom antennas shall be no more
than one dB below the gain of the antenna when installed on a standard ground plane as
specified in 2.2.13. The radiation pattern gain, at zero degrees elevation, shall be within 3
dB of the gain of the ground-plane-installed antenna over 90% of the remainder of its
azimuth coverage. The verification procedures of 2.4.13.1 through 2.4.13.5 shall be
performed on final installed equipment with all appropriate connections and antenna in
order to demonstrate proper operation of the final installation.
Note: Antenna system performance tests are specified to accommodate the most stringent
envisioned applications. Operational approval of proposed applications must
consider installed antenna system performance. Installations that do not fully
comply with the above requirements may be approved for particular operations
based on the safety implications of the application.
20xx, RTCA, Inc.

807
3.3.4.2 Full Scale Anechoic Antenna Range Measurements of Gain

The gain characteristics of the antenna as mounted on the actual airframe may be measured
directly in a calibrated anechoic antenna test range using standard controlled procedures for
such measurements. Gain characteristics determined in this way require no further
validation.
Note: Anechoic range measurements are generally impractical for determining full
antenna gain patterns for large aircraft. However, such techniques may be
practical for qualifying certain sub-regions of the coverage pattern or for
validating model measurements or theoretical calculations.
3.3.4.3 Scaled Model Measurements of Gain

Aircraft models for antenna measurements are normally 1/10 to 1/40 scale. Scale selection
is dependent upon considerations such as availability of equipment, and antenna scaling,
with larger models resulting in greater accuracy.
Only the major structural features of the airframe need be constructed. Details such as
windows, doors, turbines, etc. are not required. The outside skin should be of conductive
material. Typically, the fuselage and engine nacelles are modeled from metal tubing and/or
shaped metal screening; wings and stabilizers can be modeled from flat metal plates.
Movable control surfaces are not required unless they will have significant effects upon the
antenna pattern.
Notes:
1. In general, obstructions that subtend angles at the antenna of less than a few
degrees in elevation or azimuth need not be modeled. However, smaller
obstructions such as other antennas, that are located within a few wavelengths of
the antenna under test, may have to be modeled because they can act as resonant
scatterers and could have a significant effect on the radiation pattern.
2. If the swept area of propeller blades exceeds the limits given in (1) above, the
blades can be worst-case modeled by a flat metal disk of radius proportional to
blade length. If the radiation pattern using disks for propellers satisfies the success
criteria, it can be assumed that the pattern modulation caused by the rotating
blades will not significantly degrade the ADS-B system performance.
3.3.4.4 Model Tests

Mount the scaled model antenna in the center of a ground plane whose radius is equal in
wavelengths to the ground plane used for testing the full scale antenna.
Using a calibrated anechoic antenna test range, confirm that the gain of the scaled antenna
(including possible multiple radiating elements, splitting or combining networks,
impedance, and mutual coupling effects) is within 2 dB of the full-scale antenna gain, for all
azimuth and elevation angles for which the gain of the full-scale antenna is within 6 dB of
the peak gain.
Mount the scaled model antenna on the aircraft model at the intended installation location.
20xx, RTCA, Inc.

808
Measure the antenna gain for all azimuth angles (for top and bottom antennas).
Confirm that the scaled antenna meets the success criteria of 3.3.4.1.1 above.
3.3.4.5 Theoretical Calculations of Antenna Gain

The gain characteristics of the antenna as mounted on the actual airframe may be
determined by a combination of radiation pattern calculations, and measurements designed
to validate those calculations. When using such techniques to determine the gain of a multi-
element antenna, it is necessary to show that the calculations include the inherent
characteristics of the antenna elements and their drivers, splitters, or combining networks
and any effects due to mutual coupling between those elements.
3.3.4.5.1 Validation of Theoretical Calculations

If radiation pattern calculations are used to prove the success criteria of 3.3.4.1.1 above,
the manufacturer of the antenna must provide corroborating data demonstrating the success
of the calculation technique in predicting the antenna gain on an airframe roughly similar in
size and complexity to the airframe under qualification. Such data must be obtained by
comparison with selected gain measurements made
(a) on a full-size airframe using a calibrated ramp test antenna range, or
(b) on a scaled model airframe as indicated in 3.3.4.4.
3.3.4.5.2 Distance Area Calculations

The extent to which the antenna installation minimizes obstructions in the horizontal plane
and minimizes effects of reflecting objects, may be judged by the distance to such objects
and their sizes. If the distances and sizes satisfy the condition given here, then the antenna
installation may be considered validated with regard to antenna gain. The condition is: For
target aircraft at zero degree elevation angle and at azimuth bearing between 90 degrees
and +90 degrees,
l l
A12 A22G2 A3G3
2 2 2 2
0.02
D1 D2 G2 4 D32G3
where 0.9 ft. is the free space wavelength at 1090 MHz. The first term is applicable
only if there is a metallic obstruction between the target and the ADS-B antenna. The
distance in feet to the obstruction is denoted D1 and the area in ft2 of the obstruction
projected in the direction of the ADS-B antenna is denoted A1. The second term is a
summation over flat metallic reflectors, if any, that are oriented so as to cause a specular
reflection between the ADS-B antenna and the target. The distance to the reflector, in feet,
is denoted D2, the area, in square feet, of the reflector, projected in the direction of the ADS-
B antenna is denoted A2, the antenna gain in the direction of the reflector is denoted G 2 and
is dimensionless (i.e. gain in dB = 10 log G2), and the antenna gain in the direction of the
target is denoted G2 and is dimensionless. The third term is a summation over all other
metallic objects that may cause reflections between the ADS-B antenna and the target. The
parameters D3, A3, G3, and G3 have the same meanings as in the second term. In the case
20xx, RTCA, Inc.

809
of other aircraft antennas in view of the ADS-B antenna, a minimum value for A = 0.22
square feet is to be used if the actual area of the antenna is less than 0.22 square feet.
3.3.4.5.3 Dynamic Response

The antenna(s) shall be located such that operation of the equipment is not adversely
affected by aircraft maneuvering or changes in attitude encountered in normal flight
operations.
Note: Class A0 and A1S installations are not required to install multiple (e.g., top
fuselage and bottom fuselage) antennas.
3.3.4.6 Installed Equipment Antenna System
3.3.4.6.1 Verification of Transmit Pattern Gain (2.2.13.1)

The purpose of this procedure is to verify that the gain of an omni-directional transmit
antenna is not less than the gain of a matched quarter-wave stub minus 3 dB over 90 percent
of a coverage volume from 0 to 360 degrees in azimuth and from 5 to 30 degrees above the
ground plane when installed at center of 1.2 meter (4 feet) diameter (or larger) flat circular
ground plane.
This procedure should be performed in the laboratory environment to demonstrate that the
ADS-B Transmitting Subsystem properly delivers RF ADS-B Messages to the free space
medium via the expected installation connections and radiating antenna.
This procedure shall be performed on final installed equipment with all appropriate
Equipment Required:
Provide a method of generating ADS-B Airborne Position Broadcast.
Calibrated quarter-wave stub Sense Antenna of known gain. (See Figure 3-1)
Appropriate Couplers and Connectors as required
Coaxial Connection of known attenuation (shown in Figure 3-1 as Coax #2)
Appropriate Attenuators as required
HP 8753E Spectrum Analyzer (or equivalent capability)
20xx, RTCA, Inc.

810
Transmitting Antenna
R
Calibrated Sense Antenna
Under Test
+ 30 degrees + 15 degrees R
Aircraft Surface + 5 degrees R

(ground plane) Sense Antenna
Ground Plane
R
Reference Line
R
COAX #2
- 5 degrees
(-3 dB)
- 30 degrees - 15 degrees R
ADS-B Spectrum
R
Transmitter Analyzer
COAX #1
(-3 dB)
Connector Connector
#1 #2
Figure 3-1: Antenna Test Configuration - 1
Step 1: Understand the Equation
Define:
P_out = Transmitted Power (in watts) Measured at the ADS-B Broadcast
Message Generator output connector in watts
Loss_TX = attenuation (in dB) provided by connection of the ADS-B Broadcast
Message Generator to the Transmitting Antenna. This includes the
cable (i.e., Coax #1 in Figure 3-1) and connectors
G_tx = gain (in dB) of the transmitting antenna
R = Distance between the transmitting antenna and the receiving antenna in
meters
Path_Loss = attenuation (in -dB) of a 1090 MHz signal in free space for distance = R
= [ /(4 R)]2 = [(300/1090)/(4 R)]2 = [(2.19020564 X 10-2)/R]2
= 20*log( 2.19020564 X 10-2 ) - 20*log( R )

= - 33.1903022 - 20*log( R )
G_rx = gain (in dB) of the receiving or Calibrated Sense Antenna
Loss_RX = attenuation (in dB) provided by connection of the Calibrated Sense
20xx, RTCA, Inc.

811
Antenna to the Spectrum Analyzer. This includes the cable (i.e., Coax
#2 in Figure 3-1) and connectors and should be calibrated to 3 dB
P_rx_dBw = Power (in dBw) received at the Spectrum Analyzer
P_rx_dBm = P_rx_dBw + 30 = Power (in dBm) received at the Spectrum Analyzer
Then the expected power of the 1090 MHz signal received at the Spectrum Analyzer is
given by the following equation.
EQUATION 1:
P_rx_dBw = 10*log(P_out) - Loss_TX + G_tx + Path_Loss + G_rx - Loss_RX
= 10*log(P_out) - Loss_TX + G_tx -33.1903022 -20*log( R) + G_rx - Loss_RX
Specifying a Range of 3 meters (i.e., the distance between the antennas along the reference
line shown in Figure 3-1) to be used as the Range in the following procedure provides the
following Equation 2.
P_rx_dBw = 10*log(P_out) - Loss_TX + G_tx - 33.1903022 - 9.54242509 + G_rx -
Loss_RX
EQUATION 2:
P_rx_dBw = 10*log(P_out) - Loss_TX + G_tx - 42.73272729 + G_rx - Loss_RX
Note: If the measurement distance, R, is different from 3 meters, then Equation 2 must be
recomputed for the new R and the recomputation must be based on Equation 1.
Equation 1 is based on the fact that there are 1852 meters in one nautical mile.
Also, there are 6076.1 feet in one nautical mile. Therefore, for the purpose of these
computations, there are 3.280831533 feet per meter.
The Effective Radiated Power (ERP) emitted from the Transmitting Antenna is then given
by Equation 3 as follows:
EQUATION 3:
ERP_dBw = P_rx_dBw + 42.73272729 - G_rx + Loss_RX
Note: Whenever the need to measure radiated RF power is established, the question
arises in regards to the permissible level of radiation that can be sustained by
personnel making the measurements. This document addresses such concerns in
the following paragraph of this note.
Assume that the maximum Effective Radiated Power from the Transponder or
ADS-B Transmitting Subsystem is 500 W (27 dBW) as specified in 2.2.2.1.2 of
this document and 2.2.3.2.d of RTCA DO-181D. Then, using portions of
equation 2 or 3 from above, the radiated power at 3 meters is given as follows:
P_3m_dBW = ERP - 42.73272729
= 26.98970004 dBW -42.73272729
P_3m_dBW = -15.74302725 dBW
then the power at 3 meters in watts is as follows:
20xx, RTCA, Inc.

812
10*log(P_3m_W) = -15.74302725
P_3m_W = (10 -1.574302725
= 0.02665 W
= 26.65 mW
This would appear to be a minimum amount of power: however, it does not
readily translate into Maximum Permissible Exposure (MPE) limits, which are
typically used to determine hazard levels.
Consulting FCC OET Bulletin 65, Edition 97-01, August, 1997, Evaluating
Compliance with FCC Guidelines for Human Exposure to Radiofrequency
Electromagnetic Fields, provides information as provided in the following
paragraphs.
Section 2, equation 3, page 19 of the bulletin provides the following equation for
the prediction of RF fields:
S = EIRP
4 R2
where:
S = power density (in appropriate units, e.g. mW/cm2)
EIRP = equivalent (or effective) isotropically radiated power
(inappropriate units, e.g .mW)
R = distance to the center of radiation of the antenna (appropriate
units, e.g., cm)
Applying this equation at 3 meters to the maximum radiated power (e.g., 500 W)
allowed for transponders or ADS-B Transmitting Subsystems provides the
following results:
S = (500 W)(1000 mW/W)

4 (300 cm)2
= 0.44209706 mW/cm2
Appendix A, Table 1(A) of the bulleting then provides MPE limits for
Occupational/Controlled Exposure as follows:
Frequency Range (MHz) = 300 - 1500

Electric Field Strength (E) (V/m) = Not Applicable
Magnetic Field Strength (H) (A/M) = Not Applicable
Power Density (S) (mW/cm2) = f/300
Averaging Time, S (minutes) = 6
Therefore, the MPE exposure for an average of 6 minutes at 1090 MHz is:
S_MPE_1090 = (1090)/300 = 3.63333333... mW/cm2
Note that this limit value is 8.2184 times greater than the power density at 3
meters computed above as 0.44209706 mW/cm2.
20xx, RTCA, Inc.

813
Next, the time of exposure must be considered. Page 11 of the bulletin addresses
this concern with the equation:
Sexptexp = Slimittavg
where:
Sexp = power density of exposure (mW/cm2)
Slimit = appropriate power density MPE limit (mW/cm2)
texp = allowable time of exposure for Sexp
tavg = appropriate MPE averaging time
Taking into the consideration that the transponder or ADS-B Transmitting

Subsystem will never exceed a transmitting duty cycle of 5%, the allowable time of
exposure is computed from the above equation as follows:
(0.44209706 mW/cm2)*X*(0.05) = (1090/300 mw/cm2)(6 minutes)

X = (1090/300 mw/cm2)(6 minutes)
(0.44209706 mW/cm2)(0.05)
X = 986.209 minutes
or
X = 16.4368 hours
These calculations have demonstrated that the expected power density of the
transponder or ADS-B Transmitting Subsystem at 3 meters is well within the
allowable MPE. The calculations also demonstrate that the time of 16.44 hours of
exposure to present a possible hazard is considerably longer than any time
necessary to perform the test procedures address in this subparagraph.
Step 2: Measure the Output Power of the ADS-B Transmitting Subsystem or device
On the Aircraft (or other applicable installation), disconnect the ADS-B

Transmitting Subsystem to Antenna connection at the ADS-B Transmitting
Subsystem unit connector.
Using appropriate attenuators, connectors, and coaxial cable of known attenuation

of 3 dB and impedance of 50 ohms, connect the Spectrum Analyzer to the ADS-B
Note: The use of attenuators is strongly recommended such that the RF receiver
front end of the Spectrum Analyzer is not destroyed. If such happens, it is
probable that the individual performing the test will not be performing
similar tests in the future.

Position Messages.
Using the Spectrum Analyzer set at a center frequency of 1090 MHz, capture the
strongest (i.e., highest RF power) pulse in an ADS-B Surface Position Message
Pulse Train. Then measure the frequency and pulse power.
20xx, RTCA, Inc.

814
Verify that the frequency is at 1090 MHz 1.0 MHz.
For Class A0 equipment, verify that the output power is at least 70 watts (i.e.,
18.45 dBw, or 48.45 dBm). Log the measurement as P_out.
For Class A1S, A1, A2, and A3 equipment, verify that the output power is at least
125 watts (i.e., 20.97 dBw, or 50.97 dBm). Log the measurement as P_out.
Step 3: Re-connect Aircraft Installation
Disconnect the Spectrum Analyzer from the ADS-B Transmitting Subsystem.
Restore the normal aircraft (or other) installation connection of the ADS-B
transmitting antenna to the ADS-B Transmitting Subsystem.
Step 4: Establish Measurement Reference #1
Refer to Figure 3-1.
Using an appropriate strong nylon string or similar, secure the string to the
Calibrated Sensing Antenna and to the Aircraft Antenna under test such that the
two antenna are exactly 3 meters apart along the reference line shown in Figure 3-
1. Make sure that the two antennas are at the same height from a relatively level
surface. Note this position of the Calibrated Sensing Antenna as the baseline
position.
Then, move the Calibrated Sensing Antenna to a point that is 5 degrees above the
baseline position while maintaining the Calibrated Sensing Antenna perpendicular
to the string with the string being tight but not stretched. Note this position as the
#1 Reference Position.

Position Messages.
Using the Spectrum Analyzer set at a center frequency of 1090 MHz, capture the
strongest (i.e., highest RF power) pulse in an ADS-B Surface Position Message
Pulse Train. Then measure and note the pulse power.
For Class A0 equipment, verify that the ERP (see Equation 3) is at least 70 watts
(i.e., 18.45 dBw, or 48.45 dBm). Log the measurement as ERP_dBw.
For Class A1S, A1, A2, and A3 equipment, verify that the ERP (see Equation 3) is
at least 125 watts (i.e., 20.97 dBw, or 50.97 dBm). Log the measurement as
ERP_dBw.
Step 5: Circular Measurements
Keeping the Calibrated Sensing Antenna at 5 degrees above the baseline position
as specified in Step 4, move the Calibrated Sensing Antenna in the horizontal
plane in approximately 45 degree steps such that new positions are established at
20xx, RTCA, Inc.

815
approximately 45, 90, 135, 180, 225, 270, and 315 degrees relative to #1
Reference Position.
At each new position, repeat the power measurement taken in Step 4 and log the
results in dBw.
Verify that the maximum deviation between any two measurements taken in Step
4 and this Step does not exceed 1 dBw.
Step 6: Establish new reference #2
Repeat Step 4 with the Calibrated Sensing Antenna moved to a position that is 15
degrees above the baseline position. Note this position as the #2 Reference
Position.
Repeat the power measurement made in Step 4.
Verify that the maximum difference between the measurement and that taken in
Step 4 does not exceed 1 dBw.
Repeat Step 5 about the #2 Reference Position while maintaining the Calibrated
Sensing Antenna at 15 degrees above the baseline position.
Verify that the maximum deviation between any two measurements taken in this
Step does not exceed 1 dBw.
degrees above the baseline position. Note this position as the #3 Reference
Position.
Sensing Antenna at 30 degrees above the baseline position.
degrees below the baseline position. Note this position as the #4 Reference
Position.
20xx, RTCA, Inc.

816
Sensing Antenna at 5 degrees below the baseline position.
Position.
Position.
3.3.4.6.2 Verification of Receiver Pattern Gain (2.2.13.2)

The purpose of this procedure is to verify that the gain of an omni-directional antenna
should not be less than the gain of a matched quarter-wave stub minus one dB over 90% of
20xx, RTCA, Inc.

817
a coverage volume from 0 to 360 degrees in azimuth and -15 to +20 degrees in elevation
when installed at the center of a 1.2 m (4 ft.) diameter (or larger) circular ground plane that
can be either flat or cylindrical.
This procedure shall be performed on final installed equipment with all appropriate
Equipment Required:
Provide the same equipment capability as that provided in 3.3.4.6.1.
Receiving Antenna
R
Calibrated Sense Antenna
Under Test
+ 30 degrees + 15 degrees R
Aircraft Surface + 5 degrees R

(ground plane) Sense Antenna
Ground Plane
R
Reference Line
Connector R
#1 COAX #2
- 5 degrees
(-3 dB)
- 30 degrees - 15 degrees R
ADS-B Spectrum
R
Receiver Analyzer
ADS-B COAX #1
Test (-3 dB)
Transmitter
Connector
#2
Figure 3-2: Antenna Test Configuration - 2
Note: Figure 3-2, above, is exactly the same as Figure 3-1 provided in 3.3.4.6.1 with
the exception that:
a. The ADS-B Transmitter in Figure 3-1 has been replaced with an ADS-B
Receiver and an ADS-B Test Transmitter that is to be patched in for this test
procedure.
b. The Transmitting Antenna under Test in Figure 3-1 has been replaced with a
Receiving Antenna under Test.
20xx, RTCA, Inc.

818
Step 1: Install ADS-B Transmission Capability
On the Aircraft (or other applicable installation), disconnect the ADS-B Receiving
Device to Antenna connection at the ADS-B Receiving device unit connector.
For Class A0 Receiver installations, install an ADS-B Test Transmitting device

having a minimum RF power of least 70 watts (i.e., 18.45 dBw, or 48.45 dBm)
plus 3 dB. If additional cabling or connectors are required to make the
connection, then the added attenuation must be accounted for when applying the
equations given in 3.3.4.6.1 in this procedure.
For Class A1S, A1, A2, and A3 Receiver installations, install a ADS-B Test
Transmitting device having a minimum RF power of least 125 watts (i.e.,
20.97dBw, or 50.97 dBm) plus 3 dB. If additional cabling or connectors are
required to make the connection, then the added attenuation must be accounted for
when applying the equations given in 3.3.4.6.1 in this procedure.
At this point, the ADS-B Receiving device of the ADS-B Receiving installation
has been replaced with an appropriate RF source such that the radiated pattern of
the receiving antenna installation can be verified. The premise here is that if the
radiated pattern is good, then so is the reception pattern.
Step 2: Perform Radiated Pattern Tests
Using the equations given in 3.3.4.6.1, with appropriate modifications if

necessary, repeat steps 2 through 10 of 3.3.4.6.1.
Step 3: Restore Original Installation
Disconnect and remove the ADS-B Test Transmitter and restore the original
installation of the ADS-B Receiving device.
3.3.4.6.3 Verification of Frequency Requirements for Transmit and Receive Antenna(s)

(2.2.13.3)
Procedures to properly verify the frequency of ADS-B Transmitting installations are
provided in 3.3.4.6.1, step 2.
Procedures to properly verify the frequency of ADS-B Receiving installations are provided
in 3.3.4.6.2 by verification of the transmission frequency capability.
3.3.4.6.4 Verification of Impedance and VSWR (2.2.13.4)

The purpose of this procedure is to verify that the VSWR produced by the antenna when
terminated in a 50 ohm transmission line does not exceed 1.5:1 at 1090 MHz.
20xx, RTCA, Inc.

819
Equipment Required:
Appropriate Couplers and Connectors as required. Coaxial Connection of known
attenuation (shown in Figure 3-1 and Figure 3-2 as Coax #2). Appropriate Attenuators as
required. HP 8562E Network Analyzer (or equivalent capability)
Step 1: Install Network Analyzer
For ADS-B transmitting installations, disconnect the ADS-B Transmitting

Subsystem to Antenna connection at the ADS-B Transmitting Subsystem unit
connector.
For ADS-B receiving installations, disconnect the ADS-B Receiving device to

Antenna connection at the ADS-B Receiving device unit connector.
Using appropriate attenuators, connectors, and coaxial cable of known attenuation

and impedance, connect the Network Analyzer to the cable end of the Antenna
connection (i.e., the connector just removed from the ADS-B Transmitting or
Receiving device).
Note: The use of attenuators is strongly recommended such that the RF front
end of the Network Analyzer is not destroyed. If such happens, it is
probable that the individual performing the test will not be performing
similar tests in the future.
Step 2: Perform Impedance and VSWR Measurements
Using the Network Analyzer, measure the impedance of the antenna installation at
a frequency of 1090 MHz.
Verify that the impedance does not exceed 50 ohms.
Using the Network Analyzer, measure the Voltage Standing Wave Ratio (VSWR)
of the antenna installation at a frequency of 1090 MHz.
Verify that the VSWR does not exceed 1.5:1.
3.3.4.6.5 Verification of Polarization (2.2.13.5)

Procedures to properly verify that the ADS-B Transmitting antenna is vertically polarized
are provided in 3.3.4.6.1.
Procedures to properly verify that the ADS-B Receiving antenna is vertically polarized are
3.4 Flight Environment Data Sources

Aircraft systems and/or sensors, which supply flight environment data to the ADS-B
system, shall be selected to meet the accuracy, range, and resolution requirements
20xx, RTCA, Inc.

820
appropriate to the equipage category. (Accuracy, range, and resolution may be shown to be
adequate by analysis.)
3.4.1 Navigation Accuracy Category (NAC)

The system shall report (and adjust, if necessary) NAC values appropriate to the navigation
source (including its operational mode) that supplies data to the ADS-B system. NAC value
varies with navigation source selection and the selected sensors current performance. If the
aircraft has multiple navigation systems, NAC can vary with system selection and the mode
of operation (e.g. Inertial Navigation with DME or GPS augmentation). The reported NAC
value must vary to track navigation accuracy (NAC) as it increases or decreases,
corresponding to navigation system accuracy.
3.4.2 Altitude
Barometric Pressure Altitude relative to a standard pressure of 1013.25 millibars (29.92
in.Hg.) shall be supplied to the ADS-B system . Altitude data, which is correctable for local
barometric pressure, shall not be supplied to the ADS-B system. The ADS-B system and
the ATC transponder (if installed) shall derive Pressure Altitude from the same sensor (e.g.
air data computer or encoding altimeter).
3.4.3 Surface/ Air (Vertical) Status

Aircraft systems or sensors providing vertical status to the ADS-B system shall be
implemented such that they provide a reliable indication that the aircraft is on the ground or
airborne. When considering likely failure modes, the system should fail to the air mode
where possible (e.g. air/ground relay should relax to the air mode).
3.5 Aircraft / Vehicle Data

ADS-B Messages contain information describing the aircraft or vehicle that is transmitting.
It is a responsibility of the installer to insure that the vehicle information provided to the
ADS-B system is correct.
3.5.1 Fixed Data

Data that does not change during operation, is selected or loaded at installation (e.g. ADS-B
Emitter Category, ICAO address). Fixed data shall accurately represent the individual
airplane/vehicle characteristics or registration information. If ADS-B and a Mode-S
transponder are installed, both shall use the same ICAO address (whenever both are
operating).
3.5.2 Variable Data

Controls used by the pilot/crew for data entry (e.g. flight number, call sign, emergency
status) shall correctly perform their intended functions.
Note: Where regulations permit variation of the 24 bit Mode-S and /or ADS-B address,
ADS-B and a Mode-S transponder shall use the same ICAO address (whenever both
are operating).
20xx, RTCA, Inc.

821
3.5.3 On-condition Sensors

Aircraft systems or sensors used to trigger on-condition messages shall be selected and
implemented such that they provide a reliable indication of the specific condition(s) to be
reported.
3.5.4 Class Code (basic)

Class code information shall be set to accurately transmit the capability of the system as it
is installed. Class code can vary between aircraft depending upon installed options and
equipment variations
3.5.5 Capability Class Data

Capability class data include en route, terminal area, approach and landing, and surface
operations capability information supplied by installed applications. Capability class data
must respond to changes in the availability of operational mode data (2.2.5.1.21 -
2.2.5.1.27).
3.6 Flight Test Procedures

This guidance material offers examples of flight test procedures for demonstration of
performance of selected functions.
Flight testing of installed systems may be desirable to confirm or supplement bench and
ground tests of installed performance.
Flight tests are not necessary to evaluate functions that encode, communicate, and decode
messages, assemble reports, or generate displays, except for the radio frequency functions
associated with transmission and reception of ADS-B Messages.
3.6.1 Displayed Data Readability

Determine that normal conditions of flight do not significantly affect the readability of
displayed data.
3.6.2 Interference Effects

For those aircraft systems and equipment that can only be tested in flight, determine that no
operationally significant conducted or radiated interference exists. Evaluate all reasonable
combinations of control settings and operational modes.
Note: Electromagnetic interference flight tests are often conducted on all electronic
systems in one test series, using procedures established by the aircraft
manufacturer. If such tests included the ADS-B equipment, no further tests are
required. (e.g. ADS-B functionality added to an existing transponder and/or TCAS
installation)
20xx, RTCA, Inc.

822
3.6.3 Surveillance Testing

The surveillance flight test is designed to verify that the installed ADS-B system is capable
of transmitting and/or receiving ADS-B squitter messages from other aircraft. The
following suggested procedures are typical flight test plans that could be followed in a
region of low air traffic density: but any other test that supplies equivalent data would be
acceptable.
ADS-B system testing requires verification of transmission and reception of ADS-B

Messages at the minimum range for the equipage class. If testing an aircraft installation
(Subject) that broadcasts only, the receiving equipment (Target) must provide a means
to display message information, received from the Subject, to the operator.
Shorter range (10 - 20 NM) operational requirements may be demonstrated using a ground
based Target system. Longer range operation might require an airborne Target system.
Typically the airborne Target aircraft will fly a holding pattern at a designated fix and
within 3000 feet of the Subject aircraft altitude.
Fly the Subject aircraft straight and level at the minimum operational range and verify that
data from the Subject are received reliably by the Target system. If the Subject system has
receive capability, verify that the Subject system reliably reports information about the
Target. (e.g. displays Target at appropriate range and altitude with correct identification)
Note: It is not intended that reception of individual squitter messages be verified.
Fly the Subject aircraft in a figure 8 pattern, at the minimum operational range, at bank
angles consistent with normal operations, at a constant altitude, and verify that transmitted
data are received reliably by the Target system. If the Subject system has receive capability,
verify that the Subject system reliably reports information about the Target during
maneuvering. (e.g. displays Target at appropriate range and altitude with correct
identification)
20xx, RTCA, Inc.

823
20xx, RTCA, Inc.

824
4.0 Operational Characteristics and Functional Requirements

A description of 1090 MHz ADS-B System operation is followed by functional
requirements for the System.
4.1 System Operation

This subsection describes the operation of a generic/hypothetical ADS-B system during
typical phases of flight operations. The phases considered are: pre-flight, taxi out, take
off/departure, en route, approach, landing/taxi, and shutdown. A transport aircraft is
assumed, possessing a full complement of sensors to allow reliable detection of various
phases of flight. Less complicated systems or aircraft might incorporate fewer modes of
operation and variations on mode selection logic.
4.1.1 General Operation: Transmitting Subsystem

The system has multiple operating modes to vary the amount and type of data transmitted as
appropriate to the operating environment and to minimize traffic on the radio frequency data
link(s). Mode selection should be automated to the greatest practical degree to reduce crew
work load and enhance system utility.
Pre-flight: Electrical power is applied to the airplane, thus powering the ADS-B system
components. The ADS-B function performs internal power up self tests, selects the
transmitter to Standby mode, if available, and begins to collect data about own ship for
transmission.
Firm data such as tail number or 24-bit ICAO address is loaded or reloaded. Flight number,
if used, is set to all zeros as a result of the power having been removed for a time in excess
of the transient switching interval protection. The system, sensing that the aircraft is on the
ground, attempts to acquire a new flight number (flight number sometimes will change
whenever the aircraft is on the ground). System power might not be interrupted. Position
(latitude/longitude/altitude) is acquired and State Vector messages are prepared and
refreshed as required to maintain current information ready for transmission.
Taxi Out: When the crew selects on or the ADS-B function detects a taxi, or imminent
operational condition (e.g. an engine oil pressure discrete + brake release + doors closed
while on the ground) the Surface mode is selected and squitter transmission commences,
transmitting State Vector and Partial Mode Status messages (flight identification). Squitters
might be transmitted at a reduced rate while on the ground. (General aviation airplanes
might sense a GPS ground speed /position exceeding an accuracy threshold.)
Note: Regulations might preclude automatic squitter commencement during taxi, limiting
transmissions to the movement area. Crew action may be required to begin squitter
transmissions. Transmitter power should not be reduced during surface operations,
in order to maintain probability of reception in competition with proximate
airborne transmitters.
Take off / Departure: When the ADS-B function detects a take off (e.g., speed (IAS or
Ground Speed) in excess of an appropriate minimum) the Air mode is selected.
Transmitted message type and squitter rate are adjusted as appropriate. The on-ground
20xx, RTCA, Inc.

825
status is broadcast until the ADS-B function detects an airborne condition (e.g. landing gear
WOW/squat switch) or associated conditions are met to override a malfunctioning squat
switch.
En route: Continue transmitting in Air mode.
Approach: Continue transmitting in Air mode. When the aircraft transitions to approach
(e.g. flaps set appropriately for landing and speed reduced accordingly), the Air mode is
continued and appropriate messages to support on-condition reports may be sent.
Landing / Taxi in: When the ADS-B function detects a landing configuration (e.g. gear
down (general aviation airplanes could use flap position only, or allow pilot selection), the
Air mode is continued and appropriate messages to support on-condition reports may be
sent. Surface mode is not entered until the ADS-B function detects an on-ground condition
(e.g. landing gear Weight On Wheels/squat switch). (General aviation airplanes might use
an appropriate IAS or Ground Speed, corresponding to minimum stall speed, dirty.) Logic
should be biased toward the air mode in case of a squat switch failure.
Shutdown: When the crew selects Stand-by squitter ceases.
Note: Regulations might limit squitter during taxi, to the movement area. Crew action
may be required to inhibit transmission of squitters.
4.1.2 General Operation: Receiving Subsystem

The ADS-B system receive function performs two tasks. A radio frequency receiver detects
squitters from external sources and decodes messages. A report generator collects and
organizes the individual messages into reports and outputs the reports on a data bus(s) to
user applications. The most likely application is a cockpit display of traffic information
(CDTI). Other applications might include a conflict detector to inform the pilot if
separation from other traffic is predicted to be less than desired. A logical extension of the
conflict detector is advisory information for maintaining the desired separation distance.
This section describes the operation of a generic/hypothetical ADS-B system receiver.

Unlike the ADS-B transmitter, the receiver operation varies only slightly with the phase of
flight. The RF squitter receiver continues to detect and decode any and all recognizable
ADS-B Messages. The report generator accepts control inputs from applications which
allow it to filter out messages which are not of importance to the application. Filtering
allows for more efficient use of the available computing resources.
Pre-flight: Electrical power is applied to the airplane, thus powering the ADS-B system
components. The ADS-B function performs internal power up self tests. The ADS-B
receiver monitors the 1090 MHz frequency for squitters from other aircraft and generates
reports for user systems such as a Cockpit Display of Traffic Information (CDTI). Receiver
sensitivity may be reduced in the Surface mode. The report generator collects data about
own ship such as tail number or ICAO address, used to recognize its own squitter
transmissions. Position (latitude/longitude/altitude) is acquired and continuously updated
for message filtering based on range or altitude and for conflict detection. The report
generator may accept filter criteria from ADS-B applications and send to each application
only the appropriate traffic reports.
20xx, RTCA, Inc.

826
Taxi Out: The receiver decodes messages and supplies them to the report generator. The
report generator, having received filter information from the CDTI, sends it reports only on
traffic, which is within the CDTI-selected range and altitude. The report generator, also
having received filter information from a concurrently executing conflict detection
application, sends it messages only from traffic whose position and altitude is consistent
with aircraft or vehicles in the airport traffic pattern or movement area. (Report filter
criteria may differ between applications.)
Take off / Departure: (same as preflight and taxi out except receiver sensitivity is at
maximum in the Air mode.)
En route: The receiver decodes messages and supplies them to the report generator. The
report generator, having received a range selection from the CDTI, sends it reports only on
traffic which is within the CDTI-selected range and altitude. The report generator, having
received different filter information from another concurrently executing application, might
send that further application reports on all traffic with an altitude greater than some
threshold, (possibly selected to reject traffic in overflown airport patterns or on the surface)
or near own altitude and within a given range.
Approach: The receiver decodes messages and supplies them to the report generator. The
report generator, having received a range selection from the CDTI, sends it reports only on
traffic which is within the CDTI-selected range and altitude. The report generator, having
received approach filter information from another concurrently executing ADS-B
application, might send that further application only reports consistent with aircraft in the
airport traffic pattern.
Landing / Taxi in: The receiver decodes messages and supplies them to the report
generator. The report generator, having received a range selection from the CDTI, sends its
reports on traffic that is within the CDTI-selected range and altitude. Having received
landing filter information from another concurrently executing ADS-B application that
detected Gear down (i.e. "Landing"), the generator includes reports on traffic that is on the
surface. On touch down, the application filter criteria might be revised to reject airborne
traffic above the local pattern altitude.
Shutdown: The receiver decodes messages and supplies them to the report generator until
power is removed or a standby mode is selected.
4.2 Operating Modes
4.2.1 Operating Modes: Transmit

The 1090 MHz ADS-B system has two modes of operation, surface and air. Operational
modes control variable link characteristics such as message types to be transmitted and
squitter rates. Switching between modes is accomplished automatically as required in
2.2.3.2.1.2. Operational mode selection may be determined by reference to State Vector
(SV) data elements such as speed. It is possible to force the system to either mode while
the aircraft is on the ground for testing (2.2.11.1).
20xx, RTCA, Inc.

827
4.2.1.1 Surface Mode

Surface mode is used on the ground but might be extended to low altitudes during take-off
or approach. In the Surface mode of operation, the system transmits State Vector messages
and Mode Status (Flight Identification) at a reduced squitter rate and possibly with reduced
receiver sensitivity levels. When the 1090 MHz ADS-B System is implemented using a
transponder, it is possible for a Mode-S ground sensor to command an airborne system to
operate in the surface mode for brief periods of time (see RTCA DO-181D; 2.2.23.1.5.2).
4.2.1.2 Air Mode

In the Air mode of operation, the system transmits all message types appropriate to its
equipment class at the designated rates and power output level.
4.2.2 Automatic Operation

The system transmits the required squitters for the equipment class, without crew
intervention. Own aircraft ADS-B position and velocity messages are formatted and
transmitted without crew member inputs or adjustments such as mode selection or tuning.
Similarly, ADS-B Messages from other sources are received, formatted into reports, and
output to user systems, or displays, without crew member intervention. (Mode selection on
CDTI or other displays is acceptable since they are not considered part of the ADS-B
function.)
An exception is the Participant Address (ICAO 24-bit address). In most installations, the
address does not change and is "hard wired" at installation. Where permitted by regulatory
authorities, this address may be input by the crew.
Certain messages related to Mode Status and On-Condition reports may be triggered by
crew actions that satisfy the conditions for the automatic generation of an associated
message.
ADS-B System validity status is available to the crew, as required in 2.2.11.5.
Crew member input of Mode Status (MS) information, where practical, (e.g., flight number)
is acceptable. The capability to acquire all message elements automatically is desirable.
Automatic acquisition of data reduces crew work load and avoids data entry errors.
Supplemental information may be entered via associated equipment.
4.3 Self Test
4.3.1 Receive
If the system performs self tests, testing should indicate the ability to receive ADS-B
messages.
If the system generates test squitter transmissions to verify the ADS-B receiver function, the
self test signal level at the antenna end of the transmission line shall not exceed 40 dBm as
required in 2.2.11.1.
20xx, RTCA, Inc.

828
4.3.2 Transmit
If the system performs self tests, testing should indicate the ability to send ADS-B
Messages. That ability implies the availability of the required message elements, whether
derived internal to the system or provided by other aircraft systems. The ability to send
messages also implies the availability of the 1090 MHz data link transmitter.
Note: The presence of valid incoming message(s) (from other than own ship) is not
required to indicate the availability of a data link. The ADS-B system may rely on
the link system flags, valids, self test etc. to determine availability. (ADS-B self test
failure, attributed to a data link failure, should nominate the data link in a BIT
message.)
4.3.2.1 Broadcast Monitor

If the 1090 MHz ADS-B System is not implemented using a transponder, a squitter monitor
verifies that the ADS-B transmitter generates squitter transmissions at a nominal rate. The
transmitter is considered to have failed when the monitor has detected squitter failure. (ref.
2.2.11.2)
4.3.2.2 Address Monitor

If the 1090 MHz ADS-B System is not implemented using a transponder, a Participant
Address monitor is provided. In the event that the ADS-B-transmitted Participant Address
is all zeros or all ones, the system declares a failure. (2.2.11.3)
4.3.2.3 Failure Annunciation

An output is provided to indicate the validity/non-validity of the ADS-B system. Failure to
generate squitters at the nominal rate, a failure detected by self-test, or a failure of the ICAO
address verification causes the output to assume the invalid state. Momentary power
interrupts should not cause the output to latch in the invalid state. The detection of a failure
is annunciated to the flight crew. (2.2.11.5)
4.4 Controls
4.4.1 Power On/Off (Optional)

The system should be powered whenever primary electrical power is available. Circuits
powering various system components or functions may be protected by individual circuit
breakers. Components or functions may receive power from multiple sources or busses (e.g.
115 vac and 28vdc).
Aircraft with limited electrical system capacity may employ system power controls for
energy conservation.
4.4.2 Manual Test (Optional)

The system should provide a means for a manually initiated test of the system report
generation function(s).
20xx, RTCA, Inc.

829
4.4.2.1 Traffic Report

The manual test should cause the system to output a report of a "Test" traffic target such that
the "Test" target appears on an associated CDTI display at a specified bearing and distance
from the own-aircraft symbol.
4.4.2.2 State Vector Report

The test should include a means for the crew or maintenance personnel to verify a subset of
parameters in the own-aircraft SV report data. The verifiable parameters should include:
Position (Latitude, Longitude), Pressure Altitude, and Speed. (e.g. The "Test" target
displays own aircraft altitude, heading (or ground track) and speed (IAS or Ground Speed)
while applying a constant offset to own aircraft latitude and/or longitude.)
4.4.3 Participant Address (Optional)

At the manufacturer's option, a means may be provided to alter the unique participant
address of the aircraft, within an allocated block of ICAO 24-bit addresses.
Note: The system architecture will determine if the ICAO 24-bit address is entered into
the data link unit or an associated peripheral device.
4.4.4 Flight Number (Optional)

At the manufacturer's option, a means may be provided for the flight crew to enter the flight
identification number or registration ("N" number, or equivalent).
Note: The system architecture will determine if flight identification or registration number
is entered into the data link unit or an associated peripheral device.
4.4.5 1090 MHz ADS-B Link Control (Optional)

At the manufacturer's option, a means may be provided for the flight crew to disable the
1090 MHz ADS-B link. Disabling results in the cessation of transmission and/or reception
of ADS-B Messages on 1090 MHz. Control of transmission and reception of any other
installed ADS-B systems is independent of the 1090 MHz ADS-B system status.
4.4.6 Standby
A means shall be provided for the flight crew to select a standby mode in which squitter
transmissions are inhibited.
4.4.7 Mode Control

The transmit function will accept appropriate data for on-condition or event driven message
transmissions, as appropriate to the equipment capability classification. At the
manufacturers option, a means may be provided for the flight crew to enter this data (e.g.
Minimum Fuel, No Communications, Unlawful Interference, etc.)
Control of Surface and Air mode switching shall not be available to the flight crew.
20xx, RTCA, Inc.

830
4.4.8 Barometric Altitude

A means shall be provided for the flight crew to inhibit the broadcast of barometric altitude
if directed to do so by ATC.
20xx, RTCA, Inc.

831
20xx, RTCA, Inc.

832
Membership
RTCA Special Committee 186
Chairs
Vincent Capezzuto Federal Aviation Administration
Rocky Stone United Airlines, Inc.
Secretary
Jonathan Hammer The MITRE Corporation
RTCA SC-186 Working Group 3

Minimum Operational Performance Standards for
1090 MHz Extended Squitter ADS-B
Chairs
Thomas Pagano. Federal Aviation Administration
Robert Semar United Airlines
Secretary
Gary Furr Titan Systems Corporation
MEMBERS of Working Group 3:
Jerry Anderson Federal Aviation Administration

Larry Bachman The Johns Hopkins University
Pio Blankas Honeywell International, Inc.
Philippe Brun Eurocontrol Experimental Center
Bob Burns Titan Systems Corporation
Robert Granville RWG Systems
William Harman MIT Lincoln Laboratory
Carl Jezierski Federal Aviation Administration
Ronnie Jones Federal Aviation Administration
Todd Kilbourne Trios Associates, Inc.
Gregory Kuehl United Parcel Service
James Maynard UPS Aviation Technologies
Bev Nichols C-Bev, Ltd
Azhar Osmanbhoy Boeing Air Traffic Management Services
Enrico Pupillo Marconi Mobile, Italy
Jean-Claude Richard Thales
Stacey Rowlan L-3 Communications
Pierre Ruault Eurocontrol Headquarters
Robert Saffell Rockwell Collins, Inc.
Mark Schneider Sensis Corporation
20xx, RTCA, Inc.

833
J. Stuart Searight Federal Aviation Administration

Ronald Staab Trios Associates, Inc.
Rick Stead ARINC, Inc.
Cyro Stone L-3 Communications
Dave Thomas Titan Systems Corporation
John Van Dongen Federal Aviation Administration
Warren Wilson The MITRE Corporation
Gene Wong Federal Aviation Administration
RTCA Special Committee 186

(Note: Working Group 3 Members are not repeated here)
MEMBERS
T. S. Abbott National Aeronautics & Space Administration

Gregg Anderson Federal Aviation Administration
Rob Anderson Federal Aviation Administration
Robert Anoll Federal Aviation Administration
Rose Ashford National Aeronautics & Space Administration
John Ashley The MITRE Corporation
Steven Ashley Qinetiq, ATC Research Group
Jonathan Baldwin Rannoch Corporation
Mark Ballin National Aeronautics & Space Administration
Richard Barhydt National Aeronautics & Space Administration
George Barkiewicz The MITRE Corporation
John Barrows Federal Aviation Administration
Vernol Battiste National Aeronautics & Space Administration
Raymond Bayh BAE Systems
Michael Beamish Pelorus Navigation Systems Inc.
Richard Berckefeldt Honeywell International, Inc.
Jonathan Bernays MIT Lincoln Laboratory
Michael Biggs Federal Aviation Administration
Robert Boisvert MIT Lincoln Laboratory
Randall Bone The MITRE Corporation
David Bowen Qinetiq, ATC Research Group
Jerry Bradley Titan Corporation
Robert Bradley Coleman Research Corporation
Ruy Brandao Honeywell International, Inc.
John Brown The Boeing Company
Wayne Bryant National Aeronautics & Space Administration
Sam Buckwalder ARINC, Inc.
Don Bui Federal Aviation Administration
Robert Buley Northwest Airlines, Inc.
James Burkley Raytheon Systems Company
Steve Bussolari MIT Lincoln Laboratory
Gilbert Caligaris Eurocontrol
20xx, RTCA, Inc.

834
Franklin Calkins DCS Corporation

Alan Cameron TASC
Gerry Caron Rockwell Collins, Inc.
Michael Castle The Johns Hopkins University
Mark Cato Air Line Pilot Association
Ken Carpenter Qinetiq, ATC Research Group
Francis Casaux DGAC-CENA
Rick Cassell Rannoch Corporation
Dan Castleberry Rockwell Collins, Inc.
Mark Cato Air Line Pilots Association
Jim Chadwick The MITRE Corporation
Roxaneh Chamlou The John Hopkins University
James Chen Federal Aviation Administration
Frank Cheshire American Airlines
Thomas Choyce Federal Aviation Administration
Kathryn Ciaramella Federal Aviation Administration
Jim Cieplak The MITRE Corporation
Robert Clarke Department of Defense
Bennett Cohen Rannoch Corporation
Glenn Colby U. S. Navy
Martin Cole National Air Traffic Controllers
Joseph Comeaux Delta Air Lines Inc.
George Cooley UPS Aviation Technologies
Leslie Crane The MITRE Corporation
Cynthia Cyrus Trios Associates, Inc.
Evan. Darby Federal Aviation Administration
Robert Darby Eurocontrol
Chris Daskalakis Volpe National Trans. Systems Ctr.
Phillip DeCara Federal Aviation Administration
Cynthia Deyoe Department of Transportation
Ronald Diedrichs Honeywell International, Inc.
Mark Dill National Air Traffic Controllers
Colleen Donovan Federal Aviation Administration
Mel Doss Honeywell International, Inc.
John Doughty Garmin International
Andre Dressler Independent Pilots Association
Ann Drumm MIT Lincoln Laboratory
Keith Dutch Federal Aviation Administration
Martin Eby Source Code Systems, Inc.
Claudio Eckert Regulatory Authority for Telecommunications and Post
Nagwa Eletreby The Boeing Company
Lee Etnyre UPS Aviation Technologies
Carl Evers Rannoch Corporation
Karen Feigh The MITRE Corporation
Paul Fiduccia Small Aircraft Manufacturers Association
Bill Fischer The Boeing Company
Nikolaos Fistas Eurocontrol Headquarters
Bill Flathers Consultant / Aircraft Owners & Pilots Association
Thomas Foster Rockwell Collins, Inc.
Steven Friedman Project Management Enterprises Inc.
20xx, RTCA, Inc.

835
Jeffri Frontz Ryan International Corporation

Mark Gaphardt TASC
Edward Garry Lockheed Martin Corp.
Pierre Gayraud Thales Avionics
Patrick Giles NATS
Carl Gleason Advancia, Inc.
Rocklin Gmeiner Raytheon Systems Company
John Gonda The MITRE Corporation
James Grant BAE Systems, Inc.
Andre Gregoire International Air Transport Association
Francis Grimal EUROCAE
Paul Gross Arthur D. Little, Inc.
Robert Grove UPS Aviation Technologies
Gondo Gulean Eurocontrol Headquarters
Edward Hahn The MITRE Corporation
Christine Haissig Honeywell International, Inc.
John Hallinan Federal Aviation Administration
Barbara Harrelson Trios Associates, Inc.
David Hartnett Federal Aviation Administration
Edgar Heath Department of Defense
Jim Herbert SETA
Val Heinz MIT Lincoln Laboratory
Douglas Helton UPS Aviation Technologies
Bruce Henry Federal Aviation Administration
Stephen Heppe Telenergy
James Higbie The Johns Hopkins University
Robert Hilb United Parcel Service
Craig Hodgdon Titan Systems Corporation
Eric Hoffman Eurocontrol
Steven Horvath UPS Aviation Technologies
Kris Hutchison ARINC Incorporated
Peter Hwoschinsky Federal Aviation Administration
Robert Jackson Raytheon Systems Company
Messimore James BAE Systems, Inc.
Michael Jenkins The MITRE Corporation
James Johnson Federal Aviation Administration
Stanley Jones The MITRE Corporation
Ed Juleau NTIA, Department of Commerce
Kathleen Kearns SITA
Randy Kenagy Aircraft Owners & Pilots Association
Robert Kerr Honeywell International, Inc.
William Kight Independent Pilots Association
Ludwig Kilchert Generic Aircraft Systems
Deborah Kirkman The MITRE Corporation
Worth Kirkman The MITRE Corporation
James Klein Rockwell Collins, Inc.
Steve Koczo Rockwell Collins, Inc.
Yoshio Kubota Japan Air Line Company
James Kukla Lockheed Martin Corporation
Daryal Kuntman Honeywell International, Inc.
20xx, RTCA, Inc.

836
Dieter Kuuze Becker Flugfunkweik GmbH

Chuck LaBerge Honeywell International, Inc.
Victor Lebacqz National Aeronautics & Space Administration
Daniel Leger Honeywell International, Inc.
Myron Leiter The MITRE Corporation
Robert Lilley Illgen Simulation Technologies, Inc
Gary Livack Federal Aviation Administration
Antonio LoBrutto Sensis Corporation
John Logan Unitech
Gary Lohr National Aeronautics & Space Administration
Christopher Machin Eurocontrol
Frank Mackowick SkyComm, Inc.
Robert Magee Mulkerin Associates, Inc.
Robert Manning L-3 Communications Analytics Corp. - U.S. Air Force
Eby Martin Source Code Systems, Inc.
Gerry McCartor Federal Aviation Administration
Edwin McConkey SAIC
James McDaniel Federal Aviation Administration
Tom McKendree Raytheon Company
Raymond Meissner SETA
Eric Messer Rockwell Collins, Inc.
Bradford Miller Federal Aviation Administration
Carl Minkner Honeywell International, Inc.
Thomas Montgomery Lockheed Martin Corporation
Chris Moody The MITRE Corporation
Ann Moore Federal Aviation Administration
Gary Moore Rockwell Collins, Inc.
John Morgan Honeywell International, Inc.
Tom Mosher UPS Aviation Technologies
William Morris Raytheon Systems Company
Harold Moses RTCA, Inc.
Albert Muaddi The Johns Hopkins University
Anand Mundra The MITRE Corporation
Michael Murphy ATN Systems, Inc.
Thomas Mustach The Boeing Company
K. Prasad Nair Project Management Enterprises Inc
Chris Nehls Honeywell International, Inc.
Vincent Nguyen Federal Aviation Administration
Johnny Nilsson Swedavia AB
Kevin OToole U.S. Air Force
Jason Och Avidyne Corporation
Oscar Olmos The MITRE Corporation
Dan Olsen National Air Traffic Control Association
Richard Olson Federal Aviation Administration
Vincent Orlando MIT Lincoln Laboratory
Albert Paradis The MITRE Corporation
C. Parkinson DCS Corporation
Robert Passman Federal Aviation Administration
Timothy Pawlowitz Federal Aviation Administration
Thomas Perry UK Civil Aviation Authority
20xx, RTCA, Inc.

837
Michael Petri Federal Aviation Administration

William Petruzel Federal Aviation Administration
Jean Petruzzi Federal Aviation Administration
Brent Phillips Federal Aviation Administration
Ei Mon Phyu Titan Systems Corporation
H. Robert Pilley Pilley Laboratories Inc.
Pascal Ponsot Airbus France
Gerry Preziotti The Johns Hopkins University
Robert Prill BAE Systems, Inc.
Paul Prisaznuk ARINC Incorporated
Enrico Pupillo Marconi Mobile
Edward Rafacz Air Line Pilots Association
John Rathgeber Lockheed Martin Corporation
Sethu Rathinam Rockwell Collins, Inc.
Jim Rowlette Federal Aviation Administration
William Russell Russell Systems
John Savoy Honeywell International, Inc.
Albert Sayadian Trios, Inc
John Scardina Federal Aviation Administration
Kenneth Schroer Federal Aviation Administration
Robert Seach NTIA, Department of Commerce
John Segerson Department of Defense
Chris Shaw Eurocontrol
Rick Shay United Airlines, Inc.
Geoff Silberman The Johns Hopkins University
Pete Skavel Federal Aviation Administration
Peter Skaves Federal Aviation Administration
Charles Sloane Federal Aviation Administration
Bernald Smith Soaring Society of America & FAI
John Sorensen Seagull Technology, Inc.
David Spencer MIT Lincoln Laboratory
Kip Spurio U.S. Air Force
Harry Staub Trios Associates, Inc.
Robert Stamm Raytheon C3I
Greg Stayton L-3 Communications
Robert Strain The MITRE Corporation
Paul Stringer Trios Associates, Inc.
Terry Stubblefield Federal Aviation Administration
Fred Studenberg Rockwell Collins, Inc.
John Studenny CMC Electronics, Inc.
Barry Sullivan National Aeronautics & Space Administration
Nick Talotta Federal Aviation Administration
Costas Tamvaclis Eurocontrol Experimental Center
Gerald Taylor MIT Lincoln Laboratory
Ann Tedford Federal Aviation Administration
Tom Teetor Defense Concept Associates, Inc.
William Thedford Titan Systems - U.S. Air Force
Steven Thompson MIT Lincoln Laboratory
Robert Torn Air Line Pilot Association/Delta Airlines
Vincent Trapani BAE Systems
20xx, RTCA, Inc.

838
Tin Truong Federal Aviation Administration

Michael Ylrey The Boeing Company
Hartmut Uhr Infosys
Dwight Unruh Rockwell Collins, Inc.
Kaelberger Urlich Thales ATM, Inc.
Ed Valovage Sensis Corporation
Garth Van Sickle DCS Corporation
Stephen VanTrees Federal Aviation Administration
Marvin Waller National Aeronautics & Space Administration
James Walton United Parcel Service
Ganghaui Wang The MITRE Corporation
Anthony Warren The Boeing Company
Jerry Watson Honeywell International, Inc.
Michael Webb ARINC, Inc.
Mike White Federal Aviation Administration
George Wilson Delta Air Lines, Inc.
Warren Wilson The MITRE Corporation
David Witchey United Airline, Inc.
Christopher Wolf Federal Aviation Administration
Alice Wong Federal Aviation Administration
David Wong BAE Systems, Inc.
Thomas Wright Joint Spectrum Center
Kathryn Ybarra L-3 Communications, Inc.
Steve Young National Aeronautics & Space Administration
Karim Zeghal Eurocontrol
Andrew Zeitlin The MITRE Corporation
20xx, RTCA, Inc.

Appendix A
Extended Squitter and TIS-B
Formats and Coding Definitions


Appendix A
Page A - 3
A Extended Squitter and TIS-B Formats and Coding Definitions
A.1 ADS-B 1090 MHz Formats and Coding
A.1.1 Introduction
This Appendix is intended to be consistent with Section 2 of these MOPS. However, in
the event of conflict between this Appendix and Section 2, the requirements in Section 2
shall take precedence.
Notes:
1. This section of Appendix A defines the formats and coding for Extended Squitter
ADS-B Messages. When Extended Squitter capability is incorporated into a
Mode S transponder, the registers used to contain the Extended Squitter
messages are part of the transponders Ground-Initiated Comm-B service. This
service consists of defined data available on board the aircraft being put into one
of the 255 registers (each with a length of 56 bits) in the Mode S transponder by
a serving process, e.g. ADS-B, at specified intervals. The Mode S ground
interrogator can extract the information from any of these registers at any time
and pass it to the ground-based application. In the case of Extended Squitter, the
information in the registers defined for ADS-B are spontaneously broadcast as
specified in RTCA/DO-181D. Extended Squitter messages are generated by the
Mode S transponder at periodic rates as defined by RTCA/DO-181D, when data
is present in Register numbers 0516, 0616, 0816, and 0916. Each time data is
loaded into Register 0A16 the transponder will broadcast a single event-driven
Extended Squitter. Data loaded into Registers 0716, 6116, 6216, and 6316 while
related to the Extended Squitter services is not used directly by the transponder
for any Extended Squitter broadcast. However the contents of these registers is
available as part of the transponders Ground-Initiated Comm-B service.
2. If the Extended Squitter capability is implemented as a Non-Transponder Device,

the convention for register numbering does not apply. However, the data content
is the same as specified for the transponder case, and the transmit times are as
specified in the body of these MOPS.
20xx, RTCA, Inc.

Appendix A
Page A - 4
A.1.2 Register Allocation Related to Extended Squitter

Table A-1: Register Allocation
Register Maximum update

number Assignment
interval
0516 Extended Squitter Airborne Position 0.2 s
0616 Extended Squitter Surface Position 0.2 s
0716 Extended Squitter Status 1.0 s
0816 Extended Squitter Identification and 15.0 s
Category
0916 Extended Squitter Airborne Velocity 1.3 s
0A16 Extended Squitter Event-Driven Information variable
1016 Data Link Capability Report 4.0 s (see Note 2)
1716 Common usage Capability Report 5.0 s
1816 1C16 Mode S Specific Services Capability Report See Note 5
1D16-1F16 Mode S Specific Services Capability Report 5.0 s
2016 Aircraft Identification 5.0 s
3016 TCAS Active Resolution Advisory Annex 10, Vol IV
4.3.8.4.2.2
6116 Emergency/Priority Status 1.0 s
6216 Target State and Status Information 0.5 s
6316-6416 Reserved for Extended Squitter
6516 Aircraft Operational Status 2.5 s
6616-6F16 Reserved for Extended Squitter
Notes:
1. The Register number is equivalent to the BDS B-Definition Subfield (BDS) value
2.2.14.4.20.b of DO-181D.
2. For ADS-B implementations on Mode S transponders, the data link capability report
(Register 1016) is used to indicate Extended Squitter capability (bit 34) and the
contents of this Register are updated within one second of the data changing and at
least every four seconds thereafter.
3. Register 0A16 is not to be used for GICB or ACAS crosslink readout.
4. The term minimum update rate is used in this document. The minimum update
rate is obtained when data is loaded in one Register field once every maximum
update interval.
5. A bit set in one of these Registers indicates that the service loading the Register
indicated by that bit has been installed on the aircraft. In this regard, these bits are
not cleared to reflect a real time loss of an application, as is done for Register 1716.
The details of the data to be entered into the registers assigned for Extended Squitter will
be as defined in this Appendix. Table A-1 specifies the minimum update rates at which
the appropriate transponder register(s) will be reloaded with valid data. Any valid data
will be reloaded into the relevant field as soon as it becomes available at the Mode S
20xx, RTCA, Inc.

Appendix A
Page A - 5
Specific Services Entity (SSE) interface regardless of the update rate. If data are not
available for a time no greater than twice the specified maximum update interval, or 2
seconds (whichever is the greater), then the status bit (if provided) will indicate that the
data in that field are invalid, and the field will be ZEROed.
A.1.3 General Conventions on Data Formats
A.1.3.1 Validity of Data

The bit patterns contained in the 56-bit transponder registers shall be considered to be
valid application data only if:
1. The Mode S specific services capability is present. This is indicated by bit 25 of the
data link capability report contained in BDS 1,0 being set to ONE;
2. The service corresponding to the application is shown as supported by the

corresponding bit in the Common Usage Capability Report (BDS 1,7) being set to
ONE for the Extended Squitter Registers 0516 to 0A16 inclusive.
Notes:
1. The intent of the capability bits in Register 1716 is to indicate that useful data is
contained in the corresponding register. For this reason, the bit for a register is
cleared if data becomes unavailable (A.1.6.2) and set again when data insertion
into the register resumes.
2. A bit set in Register 1816 to 1C16 indicates that the application using this register
has been installed on the aircraft. These bits are not cleared to reflect a real
time loss of an application, as is done for Register 1716.
3. The data value is valid at the time of extraction. This is indicated by a data field
status bit (if provided). When this status bit is set to ONE, the data field(s) which
follow, up to the next status bit, are valid. When this status bit is set to ZERO, the
data field(s) are invalid.
A.1.3.2 Representation of Numerical Data

Numerical data shall be represented as follows:
1. Numerical data are represented as binary numerals. When the value is signed, 2s
complement representation is used, and the bit following the status bit is the sign bit.
2. Unless otherwise specified, whenever more bits of resolution are available from the
data source than in the data field into which that data is to be loaded, the data shall be
rounded to the nearest value that can be encoded in that data field.
Note: Unless otherwise specified, it is accepted that the data source may have less
bits of resolution than the data field.
3. When the data source provides data with a higher or lower range than the data field,
the data shall be truncated to the respective maximum or minimum value that can be
encoded in the data field.
20xx, RTCA, Inc.
Appendix A
Page A - 6
4. Where ARINC 429 data are used, the ARINC 429 status bits 30 and 31 are replaced
with a single status bit, for which the value is VALID or INVALID as follows:
a) If bits 30 and 31 represent Failure Warning, No Computed Data" then the status
bit shall be set to INVALID.
b) If bits 30 and 31 represent Functional Test then the status bit shall be set to
INVALID.
c) If bits 30 and 31 represent Normal Operation, plus sign, or minus sign,

then the status bit shall be set to VALID provided that the data are being
updated at the required rate.
d) If the data are not being updated at the required rate, then the status bit shall be
set to INVALID.
For interface formats other than ARINC 429, a similar approach is used.
5. In all cases where a status bit is used, it must be set to ONE to indicate VALID and
to ZERO to indicate INVALID.
Note: This facilitates partial loading of the registers.
6. When specified in the field, the switch bit shall indicate which of two alternative data
types is being used to update the parameter in the transponder Register.
7. Where the sign bit (ARINC 429 bit 29) is not required for a parameter, it has been
actively excluded.
8. Bit numbering in the MB field shall be as specified in Annex 10, Volume IV,
3.1.2.3.1.3.
9. Registers containing data intended for broadcast Comm-B shall have the broadcast
identifier located in the eight most significant bits of the MB field.
Notes:
1. When multiple data sources are available, the one with the highest resolution should
be selected.
2. By default, values indicated in the range of the different fields of registers have been
rounded to the nearest integer value or represented as a fraction.
3. As used in these MOPS, BDS A,B is equivalent to Register Number AB16.
20xx, RTCA, Inc.

Appendix A
Page A - 7
A.1.4 Extended Squitter Formats
A.1.4.1 Format TYPE Codes

The first 5-bit (ME bits 1 5, Message bits 33 37) field in every Mode S Extended
Squitter message will contain the format TYPE. The format TYPE will differentiate the
messages into several classes: Airborne Position, Airborne Velocity, Surface Position,
Identification, Aircraft Intent, Aircraft State, etc. In addition, the format TYPE will also
encode the Navigation Integrity Category (NIC) of the source used for the position
report. The format TYPE will also differentiate the Airborne Messages as to the TYPE
of their altitude measurements: barometric pressure altitude or GNSS height (HAE). The
5-bit encoding for format TYPE will conform to the definition contained in Table A-2.
20xx, RTCA, Inc.

Working Paper 1090-WP30-18 as DRAFT Version 4.2 of DO-282B Appendix A
Page A - 8
Table A-2: TYPE Subfield Code Definitions (DF = 17 or 18)
NIC
TYPE Subtype Format Horizontal Containment Radius Limit Navigation Integrity
Supplement Altitude Type Notes
Code Code (Message Type) (RC) Category (NIC)
A B C
Not Not No Position Information Baro Altitude or
0 RC unknown NIC = 0 1, 2, 3
Present Applicable (Airborne or Surface Position Messages) No Altitude Information
1 Category Set D
2 Aircraft Identification and Category Category Set C
Not Not
Message Not Applicable Not Applicable Not Applicable
3 Present Applicable Category Set B
(2.2.3.2.5, A.1.4.4)
4 Category Set A
5 0 -- 0 RC < 7.5 m NIC = 11
6 0 -- 0 RC < 25 m NIC = 10
1 -- 0 RC < 75 m NIC = 9
7 6
Not 0 -- 0 Surface Position Message RC < 0.1 NM (185.2 m) NIC = 8
No Altitude Information
Present 1 -- 1 (2.2.3.2.4, A.1.4.3) RC < 0.2 NM (370.4 m) NIC = 7
1 -- 0 RC < 0.3 NM (555.6 m) NIC = 6
8
0 -- 1 RC < 0.6 NM (1111.2 m) NIC = 6
0 -- 0 RC > 0.6 NM (1111.2 m) or unknown NIC = 0
9 0 0 -- RC < 7.5 m NIC = 11 5
10 0 0 -- RC < 25 m NIC = 10 5
1 1 -- RC < 75 m NIC = 9
11 5, 6
0 0 -- RC < 0.1 NM (185.2 m) NIC = 8
12 0 0 -- RC < 0.2 NM (370.4 m) NIC = 7
0 1 -- RC < 0.3 NM (555.6 m) NIC = 6
13 Not 0 0 -- Airborne Position Message RC < 0.5 NM (925 m)
NIC = 6 Baro Altitude
Present 1 1 -- (2.2.3.2.3, A.1.4.2) RC < 0.6 NM (1111.2 m)
14 0 0 -- RC < 1.0 NM (1852 m) NIC = 5
15 0 0 -- RC < 2 NM (3.704 km) NIC = 4
1 1 -- RC < 4 NM (7.408 km) NIC = 3
16 7
0 0 -- RC < 8 NM (14.816 km) NIC = 2
17 0 0 -- RC < 20 NM (37.04 km) NIC = 1
18 0 0 -- RC > 20 NM (37.04 km) or unknown NIC = 0
0 Reserved
Difference between
Not Airborne Velocity Message
19 14 Not Applicable Not Applicable Baro Altitude and
Applicable (2.2.3.2.6, A.1.4.5)
GNSS Height (HAE)
57 Reserved
20 0 0 -- RC < 7.5 m NIC = 11 2, 5
Not Airborne Position Message
21 0 0 -- RC < 25 m NIC = 10 GNSS Height (HAE) 2, 5
Present (2.2.3.2.3, A.1.4.2)
22 0 0 -- RC > 25 m or unknown NIC = 0 2
Working Paper 1090-WP30-18 as DRAFT Version 4.2 of DO-282B 20xx, RTCA, Inc.
Working Paper 1090-WP30-18 as DRAFT Version 4.2 of DO-282B Appendix A
Page A - 9
Table A-2: TYPE Subfield Code Definitions (DF = 17 or 18) (Continued)
TYPE Subtype NIC Format

Code Code Supplement (Message Type)
0 Test Message (2.2.3.2.7.3)
23
16 Reserved
0 Reserved
24 1 Surface System Status (2.2.3.2.7.4) (Allocated for National Use)
27 Reserved
25 26 Reserved (2.2.3.2.7.5 and 2.2.3.2.7.6)
0 Reserved
Not
1 Applicable Extended Squitter Aircraft Status Message (Emergency/Priority Status) (A.1.4.8)
28
2 Extended Squitter Aircraft Status Message (TCAS RA Broadcast) (A.1.4.8)
37 Reserved
0 Target State and Status Message (A.1.4.9) (ADS-B Version Number=1, defined in RTCA DO-260A)
29 1 Target State and Status Message (A.1.4.9) (ADS-B Version Number=2, defined in these MOPS, RTCA DO-260B)
2-3 Reserved
30 07 Reserved
01 Aircraft Operational Status Message (A.1.4.10)
31
27 Reserved
Working Paper 1090-WP30-18 as DRAFT Version 4.2 of DO-282B 20xx, RTCA, Inc.
Appendix A
Page A - 10
Notes for Table A-2:
1. Baro-Altitude refers to barometric pressure altitude, relative to a standard

pressure of 1013.25 millibars (29.92 in Hg). It does not refer to baro corrected
altitude.
2. TYPE codes 20 to 22 or TYPE Code 0 are to be used when valid Baro Altitude is
not available.
3. After initialization, when horizontal position information is not available but altitude
information is available, the Airborne Position Message is transmitted with a type
code of zero in bits 1-5, the barometric pressure altitude in bits 9 to 20, and bits 22
to 56 set to ZERO. If neither horizontal position nor barometric altitude information
is available, then all 56 bits of Register 0516 are set to ZERO. The ZERO (binary
00000) TYPE Code field indicates that Latitude and Longitude information is not
available, while the ZERO altitude field indicates that altitude information is not
available.
4. If the position source is an ARINC 743A GNSS receiver, then the ARINC 429 data
label 130 data word from that receiver is a suitable source of information for RC,
the horizontal integrity containment radius. (The label 130 data word is variously
called HPL (Horizontal Protection Limit) or HIL (Autonomous Horizontal Integrity
Limit) in different documents.
5. This TYPE Code value implies limits for the RC (horizontal containment limit). If this
limit is not satisfied, then a different value for the TYPE Code should be selected.
6. The NIC supplement field in the Airborne Position Message (A.1.4.2) and in the
Aircraft Operational Status Message (0) enables the Report Assembly Function in
ADS-B Receiving Subsystems to determine whether the ADS-B Transmitting
Subsystem is announcing NIC=8 (RC < 0.1 NM) or NIC=9 (RC < 75 m).
7. The NIC supplement field in the Airborne Position Message (A.1.4.2) and in the
Aircraft Operational Status Message (0) enables the Report Assembly Function in
ADS-B Receiving Subsystems to determine whether the ADS-B Transmitting
Subsystem is announcing NIC=2 (RC < 8 NM) or NIC=3 (RC < 4 NM).
8. The term broadcast as used in this Appendix, refers to a spontaneous transmission

by the transponder. This is distinct from the Comm-B broadcast protocol.
9. Future versions of these MOPS may limit transmission of Surface Position Messages
at lower NIC and/or NACP values for Transponder-Based systems.
A.1.4.1.1 Airborne Position Message TYPE Code
A.1.4.1.1.1 Airborne Position Message TYPE Code if Containment Radius is Available
ARINC 743A characteristic, a suitable source of information for the containment
radius (RC), is ARINC 429 label 130 from that GNSS receiver.
20xx, RTCA, Inc.

Appendix A
Page A - 11
If RC (containment radius) information is available from the navigation data source, then
the transmitting ADS-B subsystem will determine the TYPE Code (the value of the
TYPE subfield) of Airborne Position Messages as follows.
a. If current valid horizontal position information is not available to the ADS-B

Transmitting Subsystem, then the TYPE Code subfield of Airborne Position
Messages will be set to ZERO (0).
b. If valid horizontal position and barometric pressure altitude information are both
available to the ADS-B Transmitting Subsystem, then the ADS-B Transmitting
Subsystem will set the TYPE Code subfield of Airborne Position Messages to a value
in the range from 9 to 18 in accordance with Table A-2.
c. If valid horizontal position information is available to the ADS-B Transmitting

Subsystem, but valid barometric pressure altitude information is not available, and
valid geometric altitude information is available, the ADS-B Transmitting Subsystem
will set the TYPE Code subfield of Airborne Position Messages to a value in the
range from 20 to 22 depending on the radius of containment (RC ) in accordance with
Table A-2.
d. If valid horizontal position information is available to the ADS-B Transmitting

Subsystem, but neither valid barometric altitude information nor valid geometric
altitude information is available, the ADS-B Transmitting Subsystem will set the
TYPE Code subfield in Airborne Position Messages to a value in the range from 9 to
18 depending on the radius of containment RC in accordance with Table A-2. (In that
case, the ALTITUDE subfield of the Airborne Position Messages would be set to all
ZEROs in order to indicate that valid altitude information is not available.)
A.1.4.1.1.2 Airborne Position Message TYPE Code if Containment Radius is Not Available
If RC (radius of containment) information is NOT available from the navigation data
source, then the ADS-B Transmitting Subsystem will indicate NIC=0 by selecting a
TYPE Code of 0, 18, or 22 in the Airborne Position Messages, as follows:
a. The ADS-B Transmitting Subsystem will set the TYPE Code subfield to ZERO (0) if
valid horizontal position information is not available.
b. The ADS-B Transmitting Subsystem will set the TYPE Code subfield to 18 if valid
pressure altitude information is available, or if neither valid pressure altitude nor
valid geometric altitude information is available.
If valid pressure altitude is not available, but valid geometric altitude information is
available, the ADS-B Transmitting Subsystem will set the TYPE Code subfield to 22.
A.1.4.1.2 Surface Position Message TYPE Code
A.1.4.1.2.1 Surface Position Message TYPE Code if Containment Radius is Available

If RC (horizontal radius of containment) information is available from the navigation data
source, then the ADS-B Transmitting Subsystem will use RC to determine the TYPE
Code used in the Surface Position Message in accordance with Table A-2.
20xx, RTCA, Inc.

Appendix A
Page A - 12
ARINC 743A characteristic, a suitable source of information for the containment
radius (RC), is ARINC 429 label 130 from that GNSS receiver.
A.1.4.1.2.2 Surface Position Message TYPE Code if Radius of Containment is Not Available
If RC (horizontal radius of containment) information is not available from the navigation
data source, then the ADS-B Transmitting Subsystem will indicate NIC=0 by selecting a
TYPE Code of 0 or 8 in the Surface Position Messages, as follows:
a. The ADS-B Transmitting Subsystem will set the TYPE Code subfield to ZERO (0) if
valid horizontal position information is not available.
b. The ADS-B Transmitting Subsystem will set the TYPE Code subfield to 8 if valid
horizontal position information is available. (This TYPE Code indicates that radius
of containment, RC, is either unknown or greater than or equal to 0.1 NM.)
A.1.4.1.2.3 TYPE Code based on Horizontal Protection Level or Estimated Horizontal Position
Accuracy
a. If valid horizontal position information is available, then the TYPE Code in the
Surface Position Message will be set in the range from 5 to 8.
b. If RC (Horizontal Radius of Containment) information is available from the

navigation data source, the TYPE Code will be selected according to the RC value,
in accordance with Table A-2.
c. If RC is not available from the navigation data source, then the TYPE Code will be
set to 8.
A.1.4.2 Airborne Position Format

The Airborne Position squitter will be formatted as specified in the definition of Register
0516 in Figure A-1.
Note: Additional details are specified in the following paragraphs.
A.1.4.2.1 Compact Position Reporting (CPR) Format (F)

In order to achieve coding that is unambiguous world wide, CPR will use two format
types, known as even and odd. This one-bit field (ME bit 22, Message bit 54) shall
be used to define the CPR Format (F) type. A CPR Format equal to ZERO (0) shall
denote an even format coding, while a CPR Format equal to ONE (1) shall denote an
odd format coding (A.1.7.7).
A.1.4.2.2 Time Synchronization (T)

This one-bit field (ME bit 21, Message bit 53) will indicate whether or not the Time of
Applicability of the message is synchronized with UTC time. T equal to ZERO (0)
will denote that the time is not synchronized to UTC. T equal to ONE (1) will denote
20xx, RTCA, Inc.

Appendix A
Page A - 13
that Time of Applicability is synchronized to UTC time. Synchronization will only be
used for Airborne Position Messages having the top two horizontal position precision
categories (TYPE Codes 9, 10, 20 and 21).
When T=1, the time of validity in the Airborne Message format will be encoded in the 1-
bit F field which (in addition to CPR format type) will indicate the 0.2 second time tick
for UTC Time of Position Validity. The F bit will alternate between 0 and 1 for
successive 0.2 second time ticks, beginning with F=0 when the Time of Applicability will
be an exact even-numbered UTC second.
A.1.4.2.3 CPR Encoded Latitude/Longitude

The CPR Encoded Latitude/Longitude field in the Airborne Position Message will be a
34-bit field (ME bits 23 56, Message bits 55 88) containing the Latitude and
Longitude of the Aircrafts Airborne Position. The Latitude and Longitude will each
occupy 17 bits. The Airborne Latitude and Longitude encoding will contain Airborne
CPR-encoded values in accordance with A.1.7. The unambiguous range for the local
decoding of Airborne Messages will be 666 km (360 NM). The positional accuracy
maintained by the Airborne CPR encoding will be approximately 5.1 meters.
Notes:
1. The Latitude/Longitude encoding is also a function of the CPR format value (the F
bit) described above.
2. Although the positional accuracy of the airborne CPR encoding is approximately 5.1
meters in most cases, implementers should be aware that the longitude position
accuracy may only be approximately 10.0 meters when the latitude is either 87.0
+/- 1.0 degrees, or +87 +/- 1.0 degrees.
A.1.4.2.3.1 Extrapolating Position (When T=1)

If T is set to one, Airborne Position Messages with TYPE Codes 9, 10, 20 and 21 will
have Times of Applicability that are exact 0.2 UTC second epochs. In that case, the F
bit will be ZERO (0) if the Time of Applicability is an even-numbered 0.2 second UTC
epoch, or ONE (1) if the Time of Applicability is an odd-numbered 0.2 second epoch.
Note 1: Here, an even-numbered 0.2 second epoch means an epoch that occurs an
even number of 200-millisecond time intervals after an even-numbered UTC
second. An odd-numbered 0.2 second epoch means an epoch that occurs an
odd number of 200-millisecond time intervals after an even-numbered UTC
second. Examples of even-numbered 0.2 second UTC epochs are 12.0 s,
12.4 s, 12.8 s, 13.2 s, 13.6 s, etc. Examples of odd-numbered UTC epochs are
12.2 s, 12.6 s, 13.0 s, 13.4 s, 13.8 s, etc.
The CPR-encoded Latitude and Longitude that are loaded into the Airborne Position
register will comprise an estimate of the A/V position at the Time of Applicability of that
Latitude and Longitude, which is an exact 0.2 second UTC epoch. The register will be
loaded no earlier than 150 ms before the Time of Applicability of the data being loaded,
and no later than 50 ms before the Time of Applicability of that data.
This timing ensures that the ADS-B Receiving Subsystem may easily recover the Time of
Applicability of the data in the Airborne Position Message, as follows:
20xx, RTCA, Inc.

Appendix A
Page A - 14
If F=0, the Time of Applicability shall be the nearest even-numbered 0.2 second
UTC epoch to the time that the Airborne Position Message is received.
If F=1, the Time of Applicability shall be the nearest odd-numbered 0.2 second
UTC epoch to the time that the Airborne Position Message is received.
Note 2: If the Airborne Position register is loaded every 200 ms, the ideal time to load
that register would be 100 ms before the Time of Applicability of the data
being loaded. The register would then be re-loaded, with data applicable at
the next subsequent 0.2 second UTC epoch, 100 ms before that next subsequent
0.2 second epoch. That way, the time of transmission of an Airborne Position
Message would never differ by more than 100 ms from the Time of
Applicability of the data in that message. By specifying 100 ms 50 ms
rather than 100 ms exactly, some tolerance is allowed for variations in
implementation.
The position data that is loaded into the Airborne Position register will be an estimate of
the A/V position at the Time of Applicability.
Note 3: The position may be estimated by extrapolating the position from the time of
validity of the fix (included in the position fix) to the Time of Applicability of
the data in the register (which, if T=1, is an exact 0.2 UTC time tick). This
may be done by a simple linear extrapolation using the velocity provided with
the position fix and the time difference between the position fix validity time
and the Time of Applicability of the transmitted data. Alternatively, other
methods of estimating the position, such as alpha-beta trackers or Kalman
filters, may be used.
Every 200 ms, the contents of the position registers will be updated by estimating the
A/V position at the next subsequent 0.2 second UTC epoch. This process will continue
with new position fixes as they become available from the source of navigation data.

T will be set to ZERO (0) if the Time of Applicability of the data being loaded into the
position register is not synchronized to any particular UTC epoch. In that case, the
position register will be re-loaded with position data at intervals that are no more than
200 ms apart. The position being loaded into the register will have a Time of
Applicability that is never more than 200 ms different from any time during which the
register holds that data.
Note: This may be accomplished by loading the Airborne Position register at intervals
that are, on average, no more than 200 ms apart, with data for which the Time of
Applicability is between the time the register is loaded and the time that it is
loaded again. (Shorter intervals than 200 ms are permitted, but not required.)
If T is ZERO (0), then ADS-B Receiving Subsystems will accept Airborne Position
Messages as being current as of the Time of Receipt. The ADS-B Transmitting
Subsystem will re-load the Airborne Position register with updated estimates of the A/V
position, at intervals that are no more than 200 ms apart. The process will continue with
new position reports as they become available.
20xx, RTCA, Inc.

Appendix A
Page A - 15
A.1.4.2.3.3 Time-Out When New Position Data is Unavailable
In the event that the navigation input ceases, the extrapolation described in A.1.4.2.3.1
and A.1.4.2.3.2 will be limited to no more than two seconds. At the end of this timeout
of two seconds, all fields of the Airborne Position register, except the altitude field, will
be cleared (set to zero).
Note: The altitude field, bits 9 to 20 of the register, would only be cleared if current
altitude data were no longer available.
With the appropriate register fields cleared, the ZERO TYPE Code field will serve to
notify ADS-B Receiving Subsystems that the data in the Latitude and Longitude fields
are invalid.
A.1.4.2.4 Altitude
This 12-bit field (ME bits 9 20, Message bits 41 52) will provide the aircraft altitude.
Depending on the TYPE Code, this field will contain either:
1. Barometric altitude encoded in 25 or 100 foot increments (as indicated by the Q Bit)
or,
2. GNSS height above ellipsoid (HAE).
Note: GNSS altitude MSL is not accurate enough for use in the position report.
A.1.4.2.5 NIC Supplement-B

The first 5-bit field (ME bits 1 5, Message bits 33 37) in every Mode S Extended
Squitter Message contains the format TYPE Code. The format TYPE Code differentiates
the 1090ES Messages into several classes: Airborne Position, Airborne Velocity, Surface
Position, Identification and Category, Aircraft Intent, Aircraft Status, etc. In addition, the
format TYPE Code also encodes the Navigation Integrity Category (NIC) value of the
source used for the position report.
The NIC Supplement-B is a 1-bit (ME bit 8, Message bit 40) subfield in the Airborne
Position Message that is use in conjunction with the TYPE Code and NIC value to allow
surveillance applications to determine whether the reported geometric position has an
acceptable level of integrity containment region for the intended use. The NIC integrity
containment region is described horizontally using the radius of containment, RC. The
format TYPE Code also differentiates the Airborne Messages as to the type of their
altitude measurements: barometric pressure altitude or GNSS height (HAE). The 5-bit
encoding for format TYPE Code and related NIC values conforms to the definition
contained in Table A-25. If an update has not been received from an on-board data
source for the determination of the TYPE Code value based on the radius of containment
within the past 5 seconds, then the TYPE Code value will be encoded to indicate that RC
is Unknown.
20xx, RTCA, Inc.

Appendix A
Page A - 16
A.1.4.3 Surface Position Format

The Surface Position squitter will be formatted as specified in the definition of Register
0616 in Figure A-2.
A.1.4.3.1 Movement
This 7-bit field (ME bits 6 12, Message bits 38 44) will provide information on the
Ground Speed of the aircraft. A non-linear scale will be used as defined in the Table A-
3, where speeds are given in km/h (kt).
Table A-3: Coding of the Movement Field

Coding Meaning Quantization
(Decimal)
0 No Movement Information Available
1 Aircraft Stopped (Ground Speed = 0 knots)
2 0 knots < Ground Speed 0.2315 km/h (0.125 kt)
3-8 0.2315 km/h (0.125 kt) < Ground Speed 1.852 km/h (1 kt) 0.2700833 km/h steps
9 - 12 1.852 km/h (1 kt) < Ground Speed 3.704 km/h (2 kt) 0.463 km /h (0.25 kt) steps
124 324.1 km/h (175 kt) < Ground Speed
125 Reserved for Aircraft Decelerating
126 Reserved for Aircraft Accelerating
127 Reserved for Aircraft Backing-Up
A.1.4.3.2 Heading
A.1.4.3.2.1 Heading/Ground Track Status

This one bit field (ME bit 13, Message bit 45) will define the validity of the Heading
value. Coding for this field will be as follows: 0=not valid and 1= valid.
Note: If a source of A/V Heading is not available to the ADS-B Transmitting

Subsystem, but a source of Ground Track Angle is available, then Ground Track
Angle may be used instead of Heading, provided that the STATUS BIT FOR
HEADING subfield is set to ZERO (0) whenever the Ground Track Angle is not a
reliable indication of the A/Vs Heading. (The Ground Track Angle is not a
reliable indication of the A/Vs Heading when the A/Vs Ground Speed is low.)
A.1.4.3.2.2 Heading/Ground Track Value

This 7-bit field (ME bits 14 20, Message bits 46 52) will define the direction (in
degrees clockwise from true or magnetic north) of aircraft motion on the surface. The
Ground Track will be encoded as an unsigned Angular Weighted Binary numeral, with
an MSB of 180 degrees and an LSB of 360/128 degrees, with ZERO (binary 000 0000)
20xx, RTCA, Inc.

Appendix A
Page A - 17
indicating a value of ZERO degrees. The data in the field will be rounded to the nearest
multiple of 360/128 degrees.
Note: The reference direction for Heading (whether True North or Magnetic North) is
Operational Status Message (A.1.4.10.13).

The one-bit (ME bit 22, Message bit 54) CPR Format (F) field for the Surface Position
Message will be encoded as specified for the Airborne Position Message. That is, F = 0
will denote an even format coding, while F = 1 will denote an odd format coding
(A.1.7.7).
A.1.4.3.4 Time Synchronization (T)

This one-bit field (ME bit 21, Message bit 53) will indicate whether or not the Time of
Applicability of the message is synchronized with UTC time. T equal to ZERO (0)
will denote that the time is not synchronized to UTC. T equal to ONE (1) will denote
that Time of Applicability is synchronized to UTC time. Synchronization will only be
used for Surface Position Messages having the top two horizontal position precision
categories (TYPE Codes 5 and 6).
When T=1, the time of validity in the Airborne Message format will be encoded in the 1-
bit F field that (in addition to CPR format type) will indicate the 0.2 second time tick
for UTC time of position validity. The F bit will alternate between ZERO (0) and ONE
(1) for successive 0.2 second time ticks, beginning with F=0 when the Time of
Applicability is an exact even-numbered UTC second.
A.1.4.3.5 CPR Encoded Latitude/Longitude

The CPR Encoded Latitude/Longitude field in the Surface Position Message will be a 34-
bit field (ME bits 23 56, Message bits 55 88) containing the Latitude and Longitude
coding of the Aircraft's Surface Position. The Latitude (Y) and Longitude (X) will each
occupy 17 bits. The Surface Latitude and Longitude encoding will contain Surface CPR-
encoded values in accordance with A.1.7. The unambiguous range for local decoding of
Surface Messages will be 166.5 km (90 NM). The positional accuracy maintained by the
Surface CPR encoding will be approximately 1.25 meters.
Notes:
1. The Latitude/Longitude encoding is also a function of the CPR format value (the F
bit).
2. Although the positional accuracy of the surface CPR encoding is approximately 1.25
meters in most cases, implementers should be aware that the longitude position
accuracy may only be approximately 3.0 meters when the latitude is either 87.0
1.0 degrees, or +87 1.0 degrees.
20xx, RTCA, Inc.

Appendix A
Page A - 18

This extrapolation will conform to A.1.4.2.3.1 (Substitute "surface" for "airborne"
where appropriate).

This extrapolation will conform to A.1.4.2.3.2 (Substitute "surface" for "airborne"
where appropriate).
A.1.4.3.5.3 Time-Out When New Position Data is Unavailable

This time-out will conform to A.1.4.2.3.3 (Substitute "surface" for "airborne" where
appropriate).
A.1.4.4 Identification and Category Format

The Identification and Category squitter will be formatted as specified in the definition of
Register 0816 in Figure A-4.
A.1.4.4.1 Aircraft Identification Coding

Note: The coding of Aircraft Identification is defined in 2.2.19.1.13 of RTCA/DO-
181D. It is reproduced here for convenience.
Each character will be coded as a six-bit subset of the ICAO 7-unit coded character set
(ICAO Annex 10, Vol. IV, 3.1.2.9.1.2, Table 3-9) as specified in the Table A-4. The
character set will be transmitted with the most significant bit (MSB) first. The reported
aircraft code will begin with character 1. Characters will be coded consecutively without
an intervening SPACE code. Any unused character spaces at the end of the subfield will
contain a SPACE character code.
20xx, RTCA, Inc.

Appendix A
Page A - 19
Table A-4: Aircraft Identification Character Coding
b6 0 0 1 1
b5 0 1 0 1
b4 b3 b2 b1
0 0 0 0 P SP1 0
0 0 0 1 A Q 1
0 0 1 0 B R 2
0 0 1 1 C S 3
0 1 0 0 D T 4
0 1 0 1 E U 5
0 1 1 0 F V 6
0 1 1 1 G W 7
1 0 0 0 H X 8
1 0 0 1 I Y 9
1 0 1 0 J Z
1 0 1 1 K
1 1 0 0 L
1 1 0 1 M
1 1 1 0 N
1 1 1 1 O
1
SP = SPACE code
A.1.4.5 Airborne Velocity Format

The Airborne Velocity squitter will be formatted as specified in the definition of Register
0916 in Figure A-5.
A.1.4.5.1 Subtypes 1 and 2

Subtypes 1 and 2 of the Airborne Velocity format will be used when the transmitting
aircraft's velocity over ground is known. Subtype 1 will be used for velocities under
1000 knots and Subtype 2 will be used for aircraft capable of supersonic flight when the
velocity might exceed 1022 knots.
This message will not be broadcast if the only valid data is the Intent Change flag
(A.1.4.5.3). After initialization, broadcast will be suppressed by loading Register 0916
with ALL ZEROs and then discontinuing updating the register until data input is
available again.
The supersonic version of the velocity coding will be used if either the East-West OR
North-South velocities exceed 1022 knots. A switch to the normal velocity coding will
be made if both the East-West AND North-South velocities drop below 1000 knots.
20xx, RTCA, Inc.

Appendix A
Page A - 20
A.1.4.5.2 Subtypes 3 and 4

Subtypes 3 and 4 of the Airborne Velocity format will be used when the transmitting
aircraft's velocity over ground is not known. These Subtypes will substitute Airspeed and
Heading for the velocity over ground. Subtype 3 will be used at subsonic velocities,
while Subtype 4 will be reserved for Airspeeds in excess of 1000 knots.
The Air Referenced Velocity is contained in the Airborne Velocity Subtypes 3 and 4, and
the velocity information is required from only certain classes of ADS-B equipped
aircraft.
Note: Air Referenced Velocity Messages may be received from airborne aircraft that
are also broadcasting messages containing ground referenced velocity
information. ADS-B Receiving Subsystems conformant to these MOPS are
required to receive and process ground referenced and Air Referenced Velocity
Messages from the same aircraft and output the corresponding reports.
Although not required in these MOPS, future versions of these MOPS will specify
under what conditions both ground referenced and air referenced velocity would
be transmitted. This is intended to provide compatibility with anticipated future
requirements for the transmission of both types of velocity information.
This Airborne Velocity Message will not be broadcast if the only valid data is the Intent
Change flag (A.1.4.5.3). After initialization, broadcast will be suppressed by loading
Register 0916 with ALL ZEROs and then discontinuing updating the register until data
input is available again.
The supersonic version of the Velocity Message coding will be used if the Airspeed
exceeds 1022 knots. A switch to the normal velocity coding will be made if the Airspeed
drops below 1000 knots.
A.1.4.5.3 Intent Change Flag in Airborne Velocity Messages

An Intent Change event will be triggered 4 seconds after the detection of new information
being inserted in Registers 4016 to 4216. The code will remain set for 18 1 seconds
following an intent change.
Intent Change Flag coding:

0 = no change in intent
1 = intent change
Notes:
1. Register 4316 is not included since it contains dynamic data that will be continuously
changing.
2. A four-second delay is required to provide for settling time for intent data derived
from manually set devices.
A.1.4.5.4 HEADING TO BE DELETED PREVIOUSLY IFR Capability Flag
20xx, RTCA, Inc.

Appendix A
Page A - 21
A.1.4.5.5 Navigation Accuracy Category for Velocity (NACV)
This 3-bit (ME bits 11-13, Message bits 43-45) subfield will indicate the Navigation
Accuracy Category for Velocity (NACV) as specified in Table A-5.
The ADS-B Transmitting Subsystem will accept, via an appropriate data interface, data
from which the own-vehicle Navigation Accuracy Category for Velocity (NACV) may be
determined, and it will use such data to establish the NACV subfields in transmitted ADS-
B Airborne Velocity Messages.
If the external data source provides 95% accuracy figures of merit for horizontal and
vertical velocity, then the ADS-B Transmitting Subsystem will determine the value of the
NACV field in the Airborne Velocity Messages, Subtypes 1, 2, 3 and 4 according to Table
A-5.
Table A-5: Determining NACV Based on Position Source Declared Horizontal

Velocity Error
Navigation Accuracy Category for Velocity
Coding
(Binary) (Decimal)
000 0 > 10 m/s
001 1 < 10 m/s
010 2 < 3 m/s
011 3 < 1 m/s
100 4 < 0.3 m/s
A.1.4.5.6 Heading in Airborne Velocity Messages
A.1.4.5.6.1 Heading Status

This one bit (ME bit 14, Message bit 46) subfield in Airborne Velocity Messages,
Subtype 3 or 4 will define the availability of the Heading value. Coding for this field will
be: 0 = not available and 1 = available.
A.1.4.5.6.2 Heading Value

This 10-bit (ME bits 15 24, Message bits 47 56) subfield in Airborne Velocity
Messages, Subtype 3 or 4 will give the Aircraft Heading (in degrees clockwise from true
or magnetic north) when velocity over ground is not available. The Heading will be
encoded as an unsigned Angular Weighted Binary numeral with an MSB of 180 degrees
and an LSB of 360/1024 degrees, with ALL ZEROs (binary 00 0000 0000) indicating a
value of ZERO degrees. The data in the field will be rounded to the nearest multiple of
360/1024 degrees.
Note: The reference direction for Heading (whether True North or Magnetic North) is
Operational Status Message (A.1.4.10.13).
20xx, RTCA, Inc.

Appendix A
Page A - 22
A.1.4.5.7 Difference from Baro Altitude in Airborne Velocity Messages

This 8-bit (ME bits 49 56, Message bits 81 88) subfield will give the signed
difference between barometric and GNSS altitude. (Coding for this field will be as
indicated in Figure A-5 and Figure A-6).
If Airborne Position is being reported using Format TYPE Codes 9 or 10, only GNSS
HAE will be used. For Format TYPE Codes 9 or 10, if GNSS HAE is not available, the
field will be coded with ALL ZEROs. For Format TYPE Codes 11 through 18, either
GNSS HAE or altitude MSL will be used. The basis for the Baro Altitude difference
(either GNSS HAE or altitude MSL) will be used consistently for the reported difference.
Note: The difference between Baro Altitude and GNSS height above ellipsoid (HAE) is
preferred. However, GNSS altitude (MSL) may be used when Airborne Position
is being reported using Format TYPE Codes 11 through 18.
A.1.4.6 Aircraft Status Register Format

The Aircraft Status register will be formatted as specified in the definition of Register
0716 in Figure A-3.
A.1.4.6.1 Purpose
Note: Unlike the other Extended Squitter registers, the contents of this register are not
broadcast. The purpose of this register is to serve as an interface between the
transponder function and the General Formatter/Manager function (GFM,
A.1.6). The two fields defined for this format are the Transmission Rate Subfield
and the Altitude Type Subfield.
A.1.4.6.2 Transmission Rate Subfield (TRS)

This field will only be used for a transponder implementation of Extended Squitter.
The TRS will be used to notify the transponder of the aircraft motion status while on the
surface. If the aircraft is moving, the surface position squitter will be broadcast at a rate
of twice per second, and identity squitters at a rate of once per 5 seconds. If the aircraft is
stationary, the surface position squitter will be broadcast at a rate of once per 5 seconds
and the identity squitter at a rate of once per 10 seconds.
The algorithm specified in the definition of Register 0716 will be used by the GFM
(A.1.6) to determine motion status and the appropriate code will be set in the TRS
subfield. The transponder will examine the TRS subfield to determine which rate to use
when it is broadcasting surface squitters.
20xx, RTCA, Inc.

Appendix A
Page A - 23
A.1.4.6.3 Altitude Type Subfield (ATS)
This field will only be used for a transponder implementation of Extended Squitter.
Note: The transponder normally loads the altitude field of the airborne position
squitter from the same digital source as used for addressed replies. This is done
to minimize the possibility that the altitude in the squitter is different from the
altitude that would be obtained by direct interrogation.
If the GFM (A.1.6) inserts GNSS height (HAE) into the airborne position squitter, it
will instruct the transponder not to insert the baro altitude into the altitude field. The
ATS subfield will be used for this purpose.
A.1.4.7 Event-Driven Protocol

A message inserted in Register 0A16 (or an equivalent transmit register) will be broadcast
once by the transponder at the earliest opportunity. Formats for messages using this
protocol will be identical to those defined for Registers 6116 to 6F16 (see Figure A-7).
Note: The GFM (A.1.6) is responsible for ensuring pseudo-random timing, priority
and for observing the maximum transmission rate for this register of 2 per
second. Additional details are specified in A.1.6.4 and in the following
paragraphs.
A.1.4.7.1 Purpose
Note: The Event-Driven protocol is intended as a flexible means to support the
broadcast of messages beyond those defined for position, velocity, and
identification. These typically will be messages that are broadcast regularly for
a period of time based on the occurrence of an event and/or having a variable
broadcast rate as determined by processes external to the transponder. Two
examples are: (1) the broadcast of Emergency/Priority Status at a periodic rate
during a declared aircraft emergency, and (2) the broadcast of TCAS Resolution
Advisory data during a declared event.
A.1.4.7.2 TCAS Resolution Advisory (RA) Broadcast

The 1090ES TCAS RA Broadcast Message contains the same information as the RA
message readout using the GICB protocol, including the aircraft ICAO 24-bit Address. A
ground-based 1090ES receiver with an omni-directional receiving capability can provide
TCAS RA Messages to the ground systems much sooner that with a scanning beam
antenna. The TCAS RA information is defined as a Subtype=2 of the existing 1090ES
Aircraft Status Message.
The airborne aircraft broadcast rates and priorities for the TCAS RA Broadcast Message
are defined below and in ICAO Document 9871, B.2.3.8.2. The format for broadcasting
a 1090ES Aircraft Status Message with TCAS RA Message content (1090ES Message
TYPE=28, Subtype=2) is defined here in Figure A-8b, and in ICAO Document 9871,
Table B-2-97b.
20xx, RTCA, Inc.

Appendix A
Page A - 24
A.1.4.7.2.1 Transmission Rate

The ADS-B Aircraft Status (TYPE=28) TCAS RA Broadcast Message (Subtype=2) will
be broadcast starting within 0.5 seconds after the transponder notification of the initiation
of a TCAS Resolution Advisory.
The ADS-B Aircraft Status (TYPE=28) TCAS RA Broadcast Message (Subtype=2) will
be broadcast at random intervals that are uniformly distributed over the range of 0.7 to
0.9 seconds for the duration of the TCAS Resolution Advisory.
A.1.4.7.2.2 Message Delivery

ADS-B Aircraft Status TCAS RA Broadcast Message delivery is accomplished using the
Event-Driven protocol. The broadcast of the TCAS RA Broadcast Message will be
terminated 24 1 seconds after the Resolution Advisory Termination (RAT) flag (see
ICAO Annex 10, Volume IV, 4.3.8.4.2.2.1.3) transitions from ZERO (0) to ONE (1).
The broadcast of the ADS-B Aircraft Status TCAS RA Broadcast Message takes priority
over the Emergency/Priority Status broadcast, and all other Event-Driven Message types,
as specified in A.1.6.4.3.
A.1.4.8 Emergency/Priority Status

Register 6116 contains an exact bit-for-bit duplication of the Emergency/Priority Status
information that is broadcast using an Event-Driven Aircraft Status Extended Squitter
Message (TYPE=28 and Subtype=1). Subtype=1 is used specifically to provide
Emergency/Priority Status information and the broadcast of the Mode A (4096) Code.
The contents of Register 6116 will be formatted as specified in Figure A-8a.
A.1.4.8.1 Transmission Rate

The Aircraft Status (TYPE=28) Emergency/Priority Status ADS-B Message (Subtype=1)
will be broadcast using the EventDriven protocol. The rate of transmission varies
depending on other conditions. If the transmission of the Mode A Code is disabled, the
transmission of the Emergency/Priority Status Message occurs only when an
emergency condition is active. When the transmission of the Mode A Code is enabled,
the transmission rate of the Emergency/Priority Status Message depends on whether
the Mode A Code is changed, or if an emergency condition is active.
When the Mode A Code is set to 3000, the 1090ES Transmitting Subsystem will
disable the transmission of the Mode A Code and broadcast the Emergency/Priority
Message in accordance with A.1.4.8.1.1 only when an emergency is declared.
Otherwise, the Mode A Code transmission is enabled and the broadcast rates of
A.1.4.8.1.2 apply.
Note: The use of Mode A Code 3000 for this purpose is in accordance with the ICAO
Doc 9871 provision to disable the transmission of the Mode A Code on 1090ES.
This will occur at such time that the ATC systems no longer depend on the Mode
A Code to identify aircraft.
20xx, RTCA, Inc.

Appendix A
Page A - 25
A.1.4.8.1.1 Emergency/Priority Status Message Broadcast Rates When Transmission of

Mode A Code is Disabled
When the Mode A Code transmission is disabled as per A.1.4.8.1, the following
a. The Emergency/Priority Status Message (TYPE=28, Subtype=1) will be broadcast

relative to the previous Emergency/Priority Status for the duration of the
emergency condition which is established by any value other than ZERO in the
Emergency/Priority Status subfield.
b. In the case where there is no emergency condition established by a ZERO value in

the Emergency/Priority Status subfield, then the Emergency/Priority Status
Message will not be broadcast.
A.1.4.8.1.2 Emergency/Priority Status Message Broadcast Rates When Transmission of Mode

A Code is Enabled
When the Mode A Code transmission is enabled as per A.1.4.8.1, the following transmit
rates apply:
a. The Emergency/Priority Status (TYPE=28, Subtype=1) will be broadcast at

random intervals that are uniformly distributed over the range of 0.7 to 0.9 seconds
relative to the previous Emergency/Priority Status under the following conditions:
i. For a duration of 24 1 seconds following a Mode A Code change by the pilot

except if the Mode A Code is changed to 7500, 7600 or 7700.
Note: The case where the Mode A Code is set to 7500, 7600 or 7700, the
transmission of the emergency condition is covered by ii. below. Setting
the Mode A Code to 7500, 7600 or 7700 is indicated by a Permanent
Alert in the Surveillance Status field (value of 1) (see 2.2.3.2.3.2). A
change in the Mode A Code, except to 7500, 7600 or 7700, is indicated
by a Temporary Alert in the Surveillance Status subfield (value of 2)
(see 2.2.3.2.3.2).
ii. For the duration of an emergency condition by any non-ZERO value in the
Emergency/Priority Status subfield, if the emergency code is cleared by the
pilot changing the Mode A Code to other than 7500, 7600 or 7700, the broadcast
of the Emergency/Priority Status Message will be continued for 24 1 seconds
as i above.
b. In the absence of conditions specified in a above, the Emergency/Priority Status

Message will be broadcast at random intervals that are uniformly distributed over the
range of 4.8 to 5.2 seconds relative to the previous Emergency / Priority Status
Message.
20xx, RTCA, Inc.

Appendix A
Page A - 26
A.1.4.8.2 Message Delivery

The Aircraft Status (TYPE=28) Emergency/Priority Status (Subtype=1) Message
delivery will be accomplished using the Event-Driven protocol (A.1.4.7). The broadcast
of this message takes priority over the Event-Driven protocol broadcasts of all other
message types, except for the ADS-B Aircraft Status TCAS RA Broadcast Message
(TYPE=28, Subtype=2), which takes priority over the Emergency/Priority Status
broadcast, and all other Event-Driven Message types, as specified in A.1.6.4.3.
A.1.4.9 Target State and Status Information

Register 6216 contains an exact bit-for-bit duplicate of the Target State and Status
Extended Squitter Message (TYPE=29 and Subtype=1), and will be formatted as
specified in Figure A-9b.

This message will be broadcast at random intervals uniformly distributed over the range
of 1.2 to 1.3 seconds for the duration of the operation.
A.1.4.9.2 Source Integrity Level (SIL) Supplement

8, Message bit 40) field that defines whether the reported SIL probability is based on a
per hour probability or a per sample probability as defined in Table A-6.
Table A-6: SIL Supplement Subfield Encoding

Coding Meaning
0 Probability of exceeding NIC radius of containment is based on per hour
1 Probability of exceeding NIC radius of containment is based on per sample
Per Hour: The probability of the reported geometric position laying outside the
NIC containment radius in any given hour without an alert or an alert
longer than the allowable time-to-alert. The per hour representation
will typically be used when the probability of exceeding the NIC is
greater for the faulted versus fault-free Signal-in-Space case (When
the Signal-in-Space fault rate is defined as hourly).

containment for GNSS position sources are based on a per
hour basis, as the NIC will be derived from the GNSS
Horizontal Protection Level (HPL) which is based on a
probability of 1X10-7 per hour.
Per Sample: The probability of a reported geometric position laying outside the
NIC containment radius. The per sample representation will
typically be used when the probability of exceeding the NIC is
greater for the fault-free Signal-in-Space case, or when the position
source does not depend on a Signal-in-Space.
20xx, RTCA, Inc.
Appendix A
Page A - 27
containment for IRU, DME/DME and DME/DME/LOC
position sources may be based on a per sample basis.
A.1.4.9.3 Selected Altitude Type

The Selected Altitude Type subfield is a 1-bit (ME bit 9, Message bit 41) field that
will be used to indicate the source of Selected Altitude data that is being used to encode
ME bits 10 through 20 (Message bits 42 through 52). Encoding of the Selected
Altitude Type is defined in Table A-7. Whenever there is no valid MCP / FCU or FMS
Selected Altitude data available, then the Selected Altitude Type subfield is set to
ZERO (0).
Table A-7: Selected Altitude Type Subfield Encoding

Coding Meaning
0 Mode Control Panel / Flight Control Unit (MCP / FCU) or equivalent
equipment.
1
Flight Management System (FMS).
A.1.4.9.4 MCP/FCU Selected Altitude or FMS Selected Altitude

a. The MCP / FCU Selected Altitude or FMS Selected Altitude subfield is an 11-bit
(ME bits 10 through 20, Message bits 42 through 52) field that contains either
MCP / FCU Selected Altitude or FMS Selected Altitude data in accordance with
b. Whenever valid Selected Altitude data is available from the Mode Control Panel /
Flight Control Unit (MCP / FCU) or equivalent equipment, such data will be used to
encode ME bits 10 through 20 (Message bits 42 through 52) in accordance with
Table A-8. Use of MCP / FCU Selected Altitude is then declared in the Selected
Altitude Type subfield as specified in Table A-7.
c. Whenever valid Selected Altitude data is NOT available from the Mode Control
Panel / Flight Control Unit (MCP / FCU) or equivalent equipment, but valid Selected
Altitude data is available from the Flight Management System (FMS), then the FMS
Selected Altitude data is used to encode ME bits 10 through 20 (Message bits 42
through 52) in accordance with Table A-8. Use of FMS Selected Altitude is then
declared in the Selected Altitude Type subfield as specified in Table A-7.
d. Encoding of Selected Altitude data in ME bits 10 through 20 (Message bits 42

through 52) is in accordance with Table A-8. Encoding of the data is rounded so as
to preserve accuracy of the source data within LSB.
e. Whenever there is NO valid MCP / FCU or FMS Selected Altitude data available,
then the MCP / FCU Selected Altitude or FMS Selected Altitude subfield (ME
bits 10 through 20, Message bits 42 through 52) will be set to ZERO (0) as indicated
in Table A-8.
20xx, RTCA, Inc.

Appendix A
Page A - 28
Table A-8: MCP/FCU Selected Altitude or FMS Selected Altitude Subfield

Encoding
Coding
(Binary) (Decimal)
000 0000 0001 1 0 feet
000 0000 0010 2 32 feet
000 0000 0011 3 64 feet
*** **** **** *** *** **** ****
*** **** **** *** *** **** ****
*** **** **** *** *** **** ****
111 1111 1110 2046 65440 feet
111 1111 1111 2047 65472 feet
A.1.4.9.5 Barometric Pressure Setting (Minus 800 millibars)

a. The Barometric Pressure Setting (Minus 800 millibars) subfield is a 9-bit (ME
bits 21 through 29, Message bits 53 through 61) field that contains Barometric
Pressure Setting data that has been adjusted by subtracting 800 millibars from the
data received from the Barometric Pressure Setting source.
b. After adjustment by subtracting 800 millibars, the Barometric Pressure Setting is

encoded in ME bits 21 through 29 (Message bits 53 through 61) in accordance with
Table A-9.
c. Encoding of Barometric Pressure Setting data in ME bits 21 through 29 (Message

bits 53 through 61) will be rounded so as to preserve a reporting accuracy within
LSB.
d. Whenever there is NO valid Barometric Pressure Setting data available, then the
Barometric Pressure Setting (Minus 800 millibars) subfield (ME bits 21 through
29, Message bits 53 through- 1) will be set to ZERO (0) as indicated in Table A-9.
e. Whenever the Barometric Pressure Setting data is greater than 1209.5 or less than
800 millibars, then the Barometric Pressure Setting (Minus 800 millibars) subfield
(ME bits 21 through 29, Message bits 53 through 61) will be set to ZERO (0).
20xx, RTCA, Inc.

Appendix A
Page A - 29
Table A-9: Barometric Pressure Setting (Minus 800 millibars) Subfield Encoding
Coding
(Binary) (Decimal)
0 0000 0001 1 0 millibars
0 0000 0010 2 0.8 millibars
0 0000 0011 3 1.6 millibars
* **** **** *** *** **** ****
* **** **** *** *** **** ****
* **** **** *** *** **** ****
1 1111 1110 510 407.2 millibars
1 1111 1111 511 408.0 millibars
A.1.4.9.6 Selected Heading Status

The Selected Heading Status subfield is a 1-bit (ME bit 30, Message bit 62) field that
will be used to indicate the status of Selected Heading data that is being used to encode
ME bits 32 through 39 (Message bits 64 through 71) in accordance with Table A-10.
Table A-10: Selected Heading Status Subfield Encoding

Coding
Meaning
(ME bit 30)
0 64 through 71) is either NOT Available or is INVALID. See Table
A-12.
1
64 through 71) is Available and is VALID. See Table A-12.
A.1.4.9.7 Selected Heading Sign

The Selected Heading Sign subfield is a 1-bit (ME bit 31, Message bit 63) field that
will be used to indicate the arithmetic sign of Selected Heading data that is being used to
encode ME bits 32 through 39 (Message bits 64 through 71) in accordance with Table
A-11.
Table A-11: Selected Heading Sign Subfield Encoding

Coding
Meaning
(ME bit 31)
64 through 71) is Positive in an angular system having a range
between +180 and 180 degrees. (For an Angular Weighted Binary
0
system which ranges from 0.0 to 360 degrees, the sign bit is positive
or Zero for all values that are less than 180 degrees). See Table A-
12.
64 through 71) is Negative in an angular system having a range
1 between +180 and 180 degrees. (For an Angular Weighted Binary
system which ranges from 0.0 to 360 degrees, the sign bit is ONE
for all values that are greater than 180 degrees). See Table A-12.
20xx, RTCA, Inc.

Appendix A
Page A - 30
A.1.4.9.8 Selected Heading

a. The Selected Heading subfield is an 8-bit (ME bits 32 through 39, Message bits
64 through 71) field that contains Selected Heading data encoded in accordance with
Table A-12.
b. Encoding of Selected Heading data in ME bits 31 through 39 (Message bits 63

through 71) will be rounded so as to preserve accuracy of the source data within
LSB.
c. Whenever there is NO valid Selected Heading data available, then the Selected
Heading Status, Sign, and Data subfields (ME bits 30 through 39, Message bits 62
through 71) will be set to ZERO (0) as indicated in Table A-12.
Table A-12: Selected Heading Status, Sign and Data Subfields Encoding
ME Bit Coding
30 31 32 -------- 39 Meaning
Status Sign Data
1 0 0000 0000 0.0 degrees
1 0 0000 0001 0.703125 degrees
1 0 0000 0010 1.406250 degrees
* * **** **** **** **** ****
* * **** **** **** **** ****
* * **** **** **** **** ****
1 0 1111 1111 179.296875 degrees
1 1 0000 0000 180.0 or -180.0 degrees
1 1 0000 0001 180.703125 or -179.296875 degrees
1 1 0000 0010 181.406250 or -178.593750 degrees
* * **** **** **** **** ****
* * **** **** **** **** ****
* * **** **** **** **** ****
1 1 1000 0000 270.000 or -90.0000 degrees
1 1 1000 0001 270.703125 or -89.296875 degrees
1 1 1000 0010 271.406250 or -88.593750 degrees
1 1 1111 1110 358.593750 or -1.4062500 degrees
1 1 1111 1111 359.296875 or -0.7031250 degrees
A.1.4.9.9 Navigation Accuracy Category for Position (NACP)

This 4-bit (ME bits 40 43, Message bits 72 75) subfield will be used to indicate the
Navigational Accuracy Category of the navigation information used as the basis for the
aircraft reported position. The NACP subfield will be encoded as shown in Table A-15.
If an update has not been received from an on-board data source for NACP within the past
5 seconds, then the NACP subfield will be encoded as a value indicating Unknown
Accuracy.
20xx, RTCA, Inc.

Appendix A
Page A - 31
Table A-15: Encoding of Navigation Accuracy Category for Position (NACP)
Coding Meaning = 95% Horizontal Accuracy Bounds (EPU)
(Binary) (Decimal)
0000 0 EPU 18.52 km (10 NM) - Unknown accuracy
0001 1 EPU < 18.52 km (10 NM) - RNP-10 accuracy
0100 4 EPU < 1852 m (1NM) - RNP-1 accuracy
0101 5 EPU < 926 m (0.5 NM) - RNP-0.5 accuracy
0110 6 EPU < 555.6 m ( 0.3 NM) - RNP-0.3 accuracy
0111 7 EPU < 185.2 m (0.1 NM) - RNP-0.1 accuracy
1000 8 EPU < 92.6 m (0.05 NM) - e.g., GPS (with SA)
1001 9 EPU < 30 m - e.g., GPS (SA off)
1010 10 EPU < 10 m - e.g., WAAS
1011 11 EPU < 3 m - e.g., LAAS
1100 - 12 -
Reserved
1111 15
Notes:
1. The Estimated Position Uncertainty (EPU) used in the table is a 95% accuracy
bound on horizontal position. EPU is defined as the radius of a circle, centered on
the reported position, such that the probability of the actual position lying outside the
circle is 0.05. When reported by a GPS or GNSS system, EPU is commonly called
HFOM (Horizontal Figure of Merit).
2. RNP accuracy includes error sources other than sensor error, whereas horizontal
error for NACP only refers to horizontal position error uncertainty.
A.1.4.9.10 Navigation Integrity Category for Baro (NICBARO)

This 1-bit (ME bit 44, Message bit 76) subfield will be used to indicate whether or not
the barometric pressure altitude being reported in the Airborne Position Message
(A.1.4.2) has been cross-checked against another source of pressure altitude. The
NICBARO subfield will be encoded as shown in Table A-16. If an update has not been
received from an on-board data source for NICBARO within the past 5 seconds, then the
NICBARO subfield will be encoded as a value of ZERO (0).
Table A-16: NICBARO Encoding

Coding Meaning
Airborne Position Message is based on a Gilham coded
0
input that has not been cross-checked against another
source of pressure altitude
Airborne Position Message is either based on a Gilham code
1 input that has been cross-checked against another source of
pressure altitude and verified as being consistent, or is based
on a non-Gilham coded source
20xx, RTCA, Inc.

Appendix A
Page A - 32
Notes:
1. The barometric altitude value itself is conveyed within the ADS-B Position Message.
2. The NICBARO subfield provides a method of indicating a level of data integrity for
aircraft installed with Gilham encoding barometric altitude sources. Because of the
potential of an undetected error when using a Gilham encoded altitude source, a
comparison will be performed with a second source and only if the two sources
agree will the NICBARO subfield be set to a value of 1. For other barometric
altitude sources (Synchro or DADS) the integrity of the data is indicated with a
validity flag or SSM. No additional checks or comparisons are necessary. For these
sources the NICBARO subfield will be set to a value of 1 whenever the barometric
altitude is valid.
3. The use of Gilham type altimeters is strongly discouraged because of the potential
for undetected altitude errors.
A.1.4.9.11 Source Integrity Level (SIL)

This 2-bit (ME bits 45 46, Message bits 77 78) subfield will be used to define the
probability of the reported horizontal position exceeding the radius of containment
defined by the NIC, without alerting, assuming no avionics faults. The SIL will address
the Signal-in-Space, if applicable, and will be the higher of the faulted or fault free
probability of the Signal-In-Space causing the NIC radius of containment to be exceeded.
no Signal-in-Space.
SIL Supplement (SILSUPP) in A.1.4.9.2.
The SIL subfield is encoded in accordance with Table A-17. For installations where
the SIL value is being dynamically updated, if an update has not been received from an
on-board data source for SIL within the past 5 seconds, then the SIL subfield will be
encoded as a value of ZERO (0), indicating Unknown.
Table A-17: Source Integrity Level (SIL) Encoding

SIL Coding Probability of Exceeding the NIC
(Binary) (Decimal) Containment Radius (RC)
00 0 Unknown or > 1 x 10-3
1 10-3
01 1
1 10-5
10 2
1 10-7
11 3
20xx, RTCA, Inc.

Appendix A
Page A - 33
Note: Implementers should not arbitrarily set the SIL to ZERO (0) just because SIL is
not provided by the position source. Implementers should perform an off-line
analysis of the installed position source to determine the appropriate SIL.
A.1.4.9.12 Status of MCP/FCU Mode Bits

The Status of MCP / FCU Mode Bits subfield is a 1-bit (ME bit 47, Message bit 79)
field that will be used to indicate whether the mode bits (ME bits 48, 49, 50 and 52,
Message bits 80, 81, 82 and 84) are actively being populated (e.g., set) in the Target State
and Status Message in accordance with Table A-18.
If information is provided to the ADS-B Transmitting Subsystem to set either ME bit

48, 49, 50, or 52 (Message bit 80, 81, 82 or 84) to either 0 or 1, then bit 47 will be set
to ONE (1). Otherwise, bit 47 will be set to ZERO (0).
Table A-18: Status of MCP/FCU Mode Bits Subfield Encoding

Coding
Meaning
(ME Bit 47)
No Mode Information is being provided in ME bits 48, 49, 50 or
0
52 (Message bits 80, 81, 82, or 84)
Mode Information is deliberately being provided in ME bits 48,
1
49, 50 or 52 (Message bits 80, 81, 82, or 84)
A.1.4.9.13 Autopilot Engaged

The Autopilot Engaged subfield is a 1-bit (ME bit 48, Message bit 80) field that will
be used to indicate whether the autopilot system is engaged or not.
a. The ADS-B Transmitting Subsystem will accept information from an appropriate

interface that indicates whether or not the Autopilot is engaged.
b. The ADS-B Transmitting Subsystem will set ME bit 48 (Message bit 80) in
accordance with Table A-19.
Table A-19: Autopilot Engaged Subfield Encoding
Coding
Meaning
(ME Bit 48)
0 Autopilot is NOT Engaged (e.g., not actively coupled and flying the aircraft)
1 Autopilot is Engaged (e.g., actively coupled and flying the aircraft)
A.1.4.9.14 VNAV Mode Engaged

The VNAV Mode Engaged subfield is a 1-bit (ME bit 49, Message bit 81) field that
will be used to indicate whether the Vertical Navigation Mode is active or not.

interface that indicates whether or not the Vertical Navigation Mode is active.
20xx, RTCA, Inc.

Appendix A
Page A - 34
accordance with Table A.1.4.9.14.
Table A.1.4.9.14: VNAV Engaged Subfield Encoding
Coding
Meaning
(ME Bit 49)
0 VNAV Mode is NOT Active
1 VNAV Mode is Active
A.1.4.9.15 Altitude Hold Mode

The Altitude Hold Mode subfield is a 1-bit (ME bit 50, Message bit 82) field that
will be used to indicate whether the Altitude Hold Mode is active or not.

interface that indicates whether or not the Altitude Hold Mode is active.
Table A.1.4.9.15: Altitude Hold Mode Subfield Encoding
Coding
Meaning
(ME Bit 50)
0 Altitude Hold Mode is NOT Active
1 Altitude Hold Mode is Active
A.1.4.9.16 Reserved for ADS-R Flag

The Reserved for ADS-R Flag subfield is a 1-bit (ME bit 51, Message bit 83) field
that shall be used as specified in 2.2.18.4.6.
A.1.4.9.17 Approach Mode

The Approach Mode subfield is a 1-bit (ME bit 52, Message bit 84) field that will be
used to indicate whether the Approach Mode is active or not.

interface that indicates whether or not the Approach Mode is active.
20xx, RTCA, Inc.

Appendix A
Page A - 35
Table A.1.4.9.17: Approach Mode Subfield Encoding
Coding
Meaning
(ME Bit 52)
0 Approach Mode is NOT Active
1 Approach Mode is Active
A.1.4.9.18 TCAS/ACAS Operational

The TCAS/ACAS Operational subfield is a 1-bit (ME bit 53, Message bit 85) field
that will be used to indicate whether the TCAS/ACAS System is Operational or not.

interface that indicates whether or not the TCAS/ACAS System is Operational.
Table A.1.4.9.18: TCAS/ACAS Operational Subfield Encoding
Coding
Meaning
(ME Bit 53)
0 TCAS/ACAS System is NOT Operational
1 TCAS/ACAS System IS Operational
Note: As a reference point, RTCA DO-181D Mode-S Transponders consider that the
TCAS/ACAS System is operational when MB bit 16 of Register 1016 is set to
ONE (1). This occurs when the transponder / TCAS/ACAS interface is
operational and the transponder is receiving TCAS/ACAS RI=2, 3 or 4. (Refer to
RTCA DO-181D [EUROCAE ED-73C], Appendix B, Table B-3-16.
A.1.4.10 Aircraft Operational Status Message

Register 6516 contains an exact bit-for-bit duplicate of the Aircraft Operational Status
Message Extended Squitter (TYPE=31 and Subtype=0). The contents of the Aircraft
Operational Status Message will be formatted as specified Figure A-10.

The Aircraft Operational Status (TYPE=31 and Subtype=0, for airborne participants)
ADS-B Message will be broadcast at random intervals that are uniformly distributed over
the range of 0.7 to 0.9 seconds when the Target State and Status Message (TYPE=29 and
Subtype=1) is not being broadcast and there has been a change within the past 24 1
seconds for value of any of the following message parameters:
a. TCAS/ACAS Operational
b. ACAS/TCAS resolution advisory active
20xx, RTCA, Inc.

Appendix A
Page A - 36
c. NACP
d. SIL
Otherwise the Aircraft Operational Status (TYPE= 31 and Subtype=0, for airborne
participants) ADS-B Message will be broadcast at random intervals that are uniformly
distributed over the range of 2.4 to 2.6 seconds.
A.1.4.10.2 Message Delivery

Message delivery will be accomplished using the Event-Driven protocol (A.1.4.7).
A.1.4.10.3 Capability Class (CC) Codes

This 16-bit (ME bits 9 24, Message bits 41 56) subfield in the Airborne Aircraft
Operational Status Message (Subtype=0) or 12-bit (ME bits 9 20, Message bits 41 52)
subfield in the Surface Aircraft Operational Status Message (Subtype=1) will be used to
report the operational capability of the aircraft. Encoding of the CC subfield will be
defined as specified in Table A-21 and Table A-22.
For an ADS-B Transmitting Subsystem compliant with DO-260B, if an update has not
been received from an on-board data source within the past 5 seconds for any data
element of the Capability Class Codes subfield, then the data associated with that data
element will be considered invalid and so reflected in the encoding of that message
element to reflect No Capability or Unknown capability.
Table A-21: Airborne Capability Class (CC) Code for Version 2 Systems
Msg Bit
41 42 43 44 45 46 47 48 49 50 51 52 -- 56
#
ME
9 10 11 12 13 14 15 16 17 18 19 20 -- 24
Bit #
Reserved TCAS 1090ES Reserved UAT Reserved
Content ARV TS TC
= 0,0 Operational IN = 0,0 IN [6]
0,1 Reserved
1,0 Reserved
1,1 Reserved
Subfield Coding:
1. TCAS Operational
= 0: TCAS/ACAS is NOT Operational
= 1: TCAS/ACAS IS Operational
2. 1090ES IN (1090 MHz Extended Squitter)

= 0: Aircraft has NO 1090ES Receive capability
= 1: Aircraft has 1090ES Receive capability
3. ARV (Air-Referenced Velocity Report Capability)

= 0: No capability for sending messages to support Air Referenced Velocity Reports
20xx, RTCA, Inc.

Appendix A
Page A - 37
= 1: Capability of sending messages to support Air-Referenced Velocity Reports.
4. TS (Target State Report Capability)

= 0: No capability for sending messages to support Target State Reports
= 1: Capability of sending messages to support Target State Reports
5. TC (Target Change Report Capability)

= 0: No capability for sending messages to support Trajectory Change Reports
= 1: Capability of sending messages to support TC+0 Report only
= 2: Capability of sending information for multiple TC reports
= 3: Reserved
6. UAT IN (Universal Access Transceiver)

= 0: Aircraft has No UAT Receive capability
= 1: Aircraft has UAT Receive capability
Table A-22: Surface Capability Class (CC) Code for Version 2 Systems
Msg Bit
41 42 43 44 45 46 47 48 49 --- 51 52
#
ME
9 10 11 12 13 14 15 16 17 --- 19 20
Bit #
Reserved NIC
Reserved 1090ES B2 UAT NACV
Content POA Supplement-C
= 0,0 IN = 0,0 Low IN [3]
[1]
0,1 Reserved
1,0 Reserved
1,1 Reserved
Subfield Coding:
1. POA (Position Offset Applied)
= 0: Position transmitted is not the ADS-B position reference point
= 1: Position transmitted is the ADS-B position reference point
2. 1090ES IN (1090 MHz Extended Squitter)

= 0: Aircraft has NO 1090ES Receive capability
= 1: Aircraft has 1090ES Receive capability
3. B2 Low (Class B2 Transmit Power Less Than 70 Watts)

= 0: Greater than or equal to 70 Watts Transmit Power
= 1: Less than 70 Watts Transmit Power
4. UAT IN (Universal Access Transceiver)

= 0: Aircraft has NO UAT Receive capability
= 1: Aircraft has UAT Receive capability
5. NACV (Navigation Accuracy Category for Velocity)
6. NIC Supplement-C (NIC Supplement for use on the Surface)
20xx, RTCA, Inc.

Appendix A
Page A - 38
A.1.4.10.4 Operational Mode (OM)

This 16-bit (ME bits 25 40, Message bits 57 72) subfield will be used to indicate the
Operational Modes that are active on board the aircraft. Encoding of the OM subfield for
Airborne Operational Status Messages (Subtype=0) will be as shown in Table A-23A.
Encoding of the OM subfield for Surface Operational Status Messages (Subtype=1) will
be as shown in Table A-23B.
Table A-23A: Airborne Operational Mode (OM) Subfield Format

Msg Bit
57 58 59 60 61 62 63 -- 64 65 --- 72
#
"ME
25 26 27 28 29 30 31 -- 32 33 --- 40
Bit #
Reserved
RA Switch Receiving Antenna Design Reserved
00
Active Active ATC Flag Assurance [8]
OM [1] [1] Services [1] [2]
Format [1]
01 Reserved
10 Reserved
11 Reserved
Subfield Coding:
1. TCAS Resolution Advisory (RA) Active
= 0: TCAS II or ACAS RA not active
= 1: TCAS RA is active
2. IDENT Switch Active

= 0: Ident switch not active
= 1: Ident switch active retained for 18 1 seconds
3. Reserved for Receiving ATC Services

= 0: Set to ZERO for this version of these MOPS
4. Single Antenna Flag

= 0: Systems with two functioning antennas
= 1: Systems that use only one antenna
5. System Design Assurance (SDA)

(see Table A.1.4.10.14)
20xx, RTCA, Inc.

Appendix A
Page A - 39
Table A-23B: Surface Operational Mode (OM) Subfield Format
Msg Bit
57 58 59 60 61 62 63 -- 64 65 --- 72
#
"ME
25 26 27 28 29 30 31 -- 32 33 --- 40
Bit #
Reserved
TCAS IDENT for Single System GPS
RA Switch Receiving Antenna Design Antenna
00
Active Active ATC Flag Assurance Offset
OM [1] [1] Services [1] [2] [8]
Format [1]
01 Reserved
10 Reserved
11 Reserved
Subfield Coding:
1. TCAS Resolution Advisory (RA) Active
= 0: TCAS II or ACAS RA not active
= 1: TCAS RA is active
2. IDENT Switch Active

= 0: Ident switch not active
= 1: Ident switch active retained for 18 1 seconds
3. Reserved for Receiving ATC Services

= 0: Set to ZERO for this version of these MOPS
4. Single Antenna Flag

= 0: Systems with two functioning antennas
= 1: Systems that use only one antenna
5. System Design Assurance (SDA)

(see Table A.1.4.10.14)
6. GPS Antenna Offset

(see Table A.1.4.10.21A and Table A.1.4.10.21B)
20xx, RTCA, Inc.

Appendix A
Page A - 40
A.1.4.10.5 Version Number

This 3-bit (ME bits 41 43, Message bits 73 75) subfield will be used indicate the
Version Number of the formats and protocols in use on the aircraft installation. Encoding
of the subfield will be as shown in Table A-24.
Table A-24: Version Number Encoding

VERSION NUMBER SUBFIELD
Coding Meaning
(Binary) (Decimal)
000 0 Conformant to DO-260 and DO-242
001 1 Conformant to DO-260A and DO-242A
010 2 Conformant to DO-260B and DO-242B
011 111 37 Reserved
A.1.4.10.6 Navigation Integrity Category (NIC) and NIC Supplement-A

The first 5-bit field (ME bits 1 5, Message bits 33 37) in every Mode S Extended
Squitter Message contains the format TYPE Code. The format TYPE Code differentiates
the 1090ES Messages into several classes: Airborne Position, Airborne Velocity, Surface
Position, Identification and Category, Aircraft Intent, Aircraft Status, etc. In addition, the
format TYPE Code also encodes the Navigation Integrity Category (NIC) value of the
source used for the position report.
The NIC Supplement-A is a 1-bit (ME bit 44, Message bit 76) subfield in the Aircraft
Operational Status Message that is use in conjunction with the TYPE Code and NIC
value to allow surveillance applications to determine whether the reported geometric
position has an acceptable level of integrity containment region for the intended use. The
NIC integrity containment region is described horizontally using the radius of
containment, RC. The format TYPE Code also differentiates the Airborne Messages as to
the type of their altitude measurements: barometric pressure altitude or GNSS height
(HAE). The 5-bit encoding for format TYPE Code and NIC values conforms to the
definition contained in Table A-25. If an update has not been received from an on-board
data source for the determination of the TYPE Code value based on the radius of
containment within the past 5 seconds, then the TYPE Code value will be encoded to
indicate that RC is Unknown.
20xx, RTCA, Inc.

Appendix A
Page A - 41
Table A-25: Navigation Integrity Category (NIC) Encoding.
Airborne Surface
NIC NIC
NIC Radius of Containment Airborne Supplement Surface Supplement
Value (RC) Position Codes Position Codes
TYPE Code TYPE Code
A B A C
0 RC unknown 0, 18 or 22 0 0 0, 8 0 0
1 RC < 20 NM (37.04 km) 17 0 0 N/A N/A N/A
2 RC < 8 NM (14.816 km) 16 0 0 N/A N/A N/A
3 RC < 4 NM (7.408 km) 16 1 1 N/A N/A N/A
4 RC < 2 NM (3.704 km) 15 0 0 N/A N/A N/A
5 RC < 1 NM (1852 m) 14 0 0 N/A N/A N/A
RC < 0.6 NM (1111.2 m) 13 1 1 8 0 1
6 RC < 0.5 NM (926 m) 13 0 0 N/A N/A N/A
RC < 0.3 NM (555.6 m) 13 0 1 8 1 0
7 RC < 0.2 NM (370.4 m) 12 0 0 8 1 1
8 RC < 0.1 NM (185.2 m) 11 0 0 7 0 0
9 RC < 75m 11 1 1 7 1 0
10 RC < 25m 10 or 21 0 0 6 0 0
11 RC < 7.5m 9 or 20 0 0 5 0 0
12 Reserved
13 Reserved
14 Reserved
15 Reserved
Notes:
1. N/A means This NIC value is not available in the ADS-B Surface Position
Message formats.
2. NIC Supplement-A is broadcast in the Aircraft Operational Status Message, ME

bit 44 (Message bit 76, see Figure A-10). NIC Supplement-B is broadcast in the
Airborne Position Message, ME bit 8 (Message bit 40, see Figure A-1). NIC
Supplement-C is broadcast in the Surface Capability Class (CC) Code Subfield of the
Aircraft Operational Status Message, ME bit 20 (Message bit 52, see Table A-22).
A.1.4.10.7 Navigation Accuracy Category for Position (NACP)

This 4-bit (ME bits 45 48, Message bits 77 80) subfield will be used to announce
95% accuracy limits for the horizontal position (and for some NACP values, the vertical
position) that is being currently broadcast in Airborne Position and Surface Position
Messages. Encoding of the subfield will be as shown in Table A-15. If an update has not
been received from an on-board data source for NACP within the past 5 seconds, then the
NACP subfield will be encoded as a value indicating Unknown Accuracy.
20xx, RTCA, Inc.

Appendix A
Page A - 42
A.1.4.10.8 Geometric Vertical Accuracy (GVA)

This 2-bit (ME bits 49 50, Message bits 81 82) subfield in the Airborne Operational
Status Message (Subtype=0) will be encoded as shown in Table A.1.4.10.8, and set by
using the Vertical Figure of Merit (VFOM) (95%) from the GNSS position source used to
encode the geometric altitude field in the Airborne Position Message.
Table A.1.4.10.8: Encoding of the Geometric Vertical Accuracy (GVA) Subfield in Aircraft
GVA Encoding Meaning
(decimal) (meters)
0 Unknown or > 45 meters
1 45 meters
2 Reserved
3 Reserved
Note: For the purposes of these MOPS (RTCA DO-260B) values for 0 and 1 are
encoded. Decoding values for 2 and 3 should be treated as < 45 meters until
future versions of these MOPS redefine the values.
A.1.4.10.9 Source Integrity Level (SIL)

This 2-bit (ME bits 51 52, Message bits 83 84) subfield is defined for the Target State
and Status Message in A.1.4.9.11 and Table A-17, and remains the same in the
Operational Status Message.
A.1.4.10.10 Barometric Altitude Integrity Code (NICBARO)

This 1-bit (ME bit 53, Message bit 85) subfield will be used to indicate whether or not
the barometric pressure altitude being reported in the Airborne Position Message
(A.1.4.2) has been cross-checked against another source of pressure altitude. The
NICBARO subfield will be encoded as shown in Table A-16. If an update has not been
received from an on-board data source for NICBARO within the past 5 seconds, then the
NICBARO subfield will be encoded as a value of ZERO (0).
A.1.4.10.11 Aircraft Length and Width Codes

This 4-bit (ME bits 21 24, Message bits 53 56) subfield will be used in the Surface
Aircraft Operational Status Message (Subtype=1) to describe the amount of space that an
Aircraft or Ground Vehicle occupies. The A/V Length and Width Code will be based on
the actual dimensions of the transmitting Aircraft or Surface Vehicle as specified in Table
A-26. Once the actual Length and Width of the A/V has been determined, each A/V will
be assigned the smallest A/V Length and Width Code from Table A-26 for which the
actual length is less than or equal to the upper bound length for that Length/Width Code,
and for which the actual width is less than or equal to the upper bound width for that
Length/Width Code.
20xx, RTCA, Inc.

Appendix A
Page A - 43
Table A-26: A/V Length and Width Code
Width Upper-Bound Length and Width
Length Code
A/V - L/W Code for Each Length/Width Code
Code ME ME ME ME
Length Width
(Decimal) Bit Bit Bit Bit
49 50 51 52 (meters) (meters)
0 0 0 0 0 No Data or Unknown
1 0 0 0 1 15 23
2 0 28.5
0 0 1 25
3 1 34
4 0 33
0 1 0 35
5 1 38
6 0 39.5
0 1 1 45
7 1 45
8 0 45
1 0 0 55
9 1 52
10 0 59.5
1 0 1 65
11 1 67
12 0 72.5
1 1 0 75
13 1 80
14 0 80
1 1 1 85
15 1 90
Aircraft/Vehicle Length/Width Code 15 will be used.
Note: For example, consider a powered glider with overall length of 24 m and
wingspan of 50 m. Normally, an aircraft of that length would be in length
category 1 (that is, have a length code of 1). But since the wingspan exceeds 34
m, it does not qualify for even the wide subcategory (width code = 1) of length
category 1. Such an aircraft would be assigned length code = 4 and width code
= 1, meaning length less than 55 m and width less than 52 m.
A.1.4.10.12 Track Angle/Heading

The Track Angle/Heading is a 1-bit (ME bit 53, Message bit 85) subfield of the ADS-B
Aircraft Operational Status Message (Subtype=1, for Surface Participants) that allows
correct interpretation of the data contained in the Heading/Ground Track subfield of the
ADS-B Surface Position Message when the Air/Ground status is determined to be in the
On-Ground state as defined in 2.2.3.2.1.2.
A.1.4.10.13 Horizontal Reference Direction (HRD)

This 1-bit (ME bit 54, Message bit 86) subfield will be used to indicate the reference
direction (true north or magnetic north) for horizontal directions such as Heading, Track
Angle. The Horizontal Reference Direction subfield will be encoded as specified in
Table A-27.
20xx, RTCA, Inc.

Appendix A
Page A - 44
Table A-27: Horizontal Reference Direction (HRD) Encoding.

HRD Value Meaning
0 True North
1 Magnetic North
A.1.4.10.14 System Design Assurance (SDA)

The System Design Assurance (SDA) subfield is a 2-bit (ME bits 31 32, Message
bits 63 64) field that will define the failure condition that the ADS-B system is
designed to support as defined in Table A.1.4.10.14.
The supported failure condition will indicate the probability of an ADS-B system fault
causing false or misleading information to be transmitted. The definitions and
probabilities associated with the supported failure effect are defined in AC 25.1309-1A,
AC 23-1309-1C, and AC 29-2C. All relevant systems attributes should be considered
including software and complex hardware in accordance with RTCA DO-178B
(EUROCAE ED-12B) or RTCA DO-254 (EUROCAE ED-80).
The ADS-B system includes the ADS-B transmission equipment, ADS-B processing
equipment, position source, and any other equipment that processes the position data
transmitted by the ADS-B system.
Table A.1.4.10.14: System Design Assurance OM Subfield in Aircraft Operational Status

Messages
SDA Value Probability of Undetected

Software & Hardware
Supported Failure Fault causing transmission
Design Assurance Level Note
(decimal) (binary) Condition Note 2 of False or Misleading 1,3
Information Note 3,4
Unknown/ No safety > 1X10-3 per flight hour
0 00 N/A
effect or Unknown
1 01 Minor 1X10-3 per flight hour D
2 10 Major 1X10 per flight hour
-5
C
3 11 Hazardous 1X10 per flight hour
-7
B
Notes:
1. Software Design Assurance per RTCA DO-178B (EUROCAE ED-12B). Airborne Electronic
Hardware Design Assurance per RTCA DO-254 (EUROCAE ED-80).
2. Supported Failure Classification defined in AC-23.1309-1C, AC-25.1309-1A, and AC 29-2C.
3. Because the broadcast position can be used by any other ADS-B equipped aircraft or by ATC, the
provisions in AC 23-1309-1C that allow reduction in failure probabilities and design assurance level
for aircraft under 6,000 pounds do not apply.
4. Includes probability of transmitting false or misleading latitude, longitude, velocity, or associated
accuracy and integrity metrics.
20xx, RTCA, Inc.

Appendix A
Page A - 45
A.1.4.10.15 SIL Supplement
8, Message bit 40) field that will define whether the reported SIL probability is based on
a per hour probability or a per sample probability as defined in A.1.4.9.2 and Table
A-6.
A.1.4.10.16 TCAS/ACAS Operational

The TCAS/ACAS Operational subfield (ME bit 11, Message bit 43) of the CC Codes
subfield in ADS-B Aircraft Operational Status Messages (TYPE=31, SUBTYPE=0, for
airborne participants) is used to indicate whether the TCAS/ACAS System is Operational
or not, and remains as defined for use in the Target State and Status Message
(A.1.4.9.18), with the encoding as specified in Table A.1.4.9.18.
A.1.4.10.17 1090ES IN
The CC Code subfield for 1090ES IN in Aircraft Operational Status Messages
(TYPE=31, Subtype=0 or 1) is a 1-bit field (ME bit 12, Message bit 44) that is set to
ONE (1) if the transmitting aircraft has the capability to receive ADS-B 1090ES
Messages. Otherwise, this CC code subfield is set to ZERO (0).
A.1.4.10.18 UAT IN
The UAT IN CC Code subfield (ME bit 19, Message bit 51, TYPE=31, Subtype=0,
for airborne participants AND ME Bit 16, Message bit 48, TYPE=31, Subtype=1 for
surface participants) in ADS-B Aircraft Operational Status Messages is so called because
it denotes whether the aircraft is equipped with the capability to receive ADS-B
Universal Access Transceiver (UAT) Messages.
The UAT IN CC Code in Aircraft Operational Status Messages is set to ZERO (0) if
the aircraft is NOT fitted with the capability to receive ADS-B UAT Messages. The
UAT IN CC Code Subfield is set to ONE (1) if the aircraft has the capability to receive
ADS-B UAT Messages.
A.1.4.10.19 Navigation Accuracy Category for Velocity (NACV)

This 3-bit subfield (ME bits 17-19, Message bits 49-51) indicates the Navigation
Accuracy Category for Velocity (NACV) as defined in A.1.4.5.5, with the encoding as
specified in Table A-5.
A.1.4.10.20 NIC Supplement-C

The NIC Supplement-C subfield in the Aircraft Operational Status Message is a one-bit
subfield (ME bit 20, Message bit 52) that, together with the TYPE subfield in Surface
Position Messages and the NIC Supplement-A in the Operational Status Message (ME
20xx, RTCA, Inc.

Appendix A
Page A - 46
Bit 44, Message Bit 76), is used to encode the Navigation Integrity Category (NIC) of the
transmitting ADS-B participant.
the NIC value within the past 5 seconds, then the NIC Supplement subfield is encoded to
indicate the larger Radius of Containment (RC).
Table A-25 lists the possible NIC codes and the values of the TYPE subfield of the
Airborne and Surface Position Messages, and of the NIC Supplement subfields that are
used to encode those NIC codes in messages on the 1090 MHz ADS-B data link.
A.1.4.10.21 GPS Antenna Offset

field in the OM Code Subfield of surface format Aircraft Operational Status Messages
that defines the position of the GPS antenna in accordance with the following, when the
Position Offset Applied (see Table A-22) is set to ZERO (0).
a. Lateral Axis GPS Antenna Offset:
ME bits 33 through 35 (Message bits 65 through 67) are used to encode the lateral
distance of the GPS Antenna from the longitudinal axis (Roll) axis of the aircraft.
Encoding is established in accordance with Table A.1.4.10.21A.
Table A.1.4.10.21A: Lateral Axis GPS Antenna Offset Encoding

ME Bit
33 34 35 Along Lateral (Pitch) Axis
(65) (66) (67) Left or Right of Longitudinal (Roll) Axis
0 = left Encoding
1 = right Bit 1 Bit 0 Direction (meters)
0 0 0 or NO DATA
0 1 2
0 LEFT
1 0 4
1 1 6
0 0 0 or NO DATA
0 1 2
1 RIGHT
1 0 4
1 1 6
Notes:
1. Left means toward the left wing tip moving from the longitudinal
center line of the aircraft.
2. Right means toward the right wing tip moving from the
longitudinal center line of the aircraft.
3. Maximum distance left or right of aircraft longitudinal (roll) axis is
6 meters or 19.685 feet.
20xx, RTCA, Inc.

Appendix A
Page A - 47
b. Longitudinal Axis GPS Antenna Offset:
ME bits 36 through 40 (Message bits 68 through 72) are used to encode the
longitudinal distance of the GPS Antenna from the NOSE of the aircraft. Encoding is
established in accordance with Table A.1.4.10.21B.
Table A.1.4.10.21B: Longitudinal Axis GPS Antenna Offset Encoding

ME Bit
36 37 38 39 40 Along Longitudinal (Roll) Axis
(68) (69) (70) (71) (72) Aft From Aircraft Nose
Encoding
Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 (meters)
0 0 0 0 0 0 or NO DATA
0 0 0 0 1 2
0 0 0 1 0 4
0 0 0 1 1 6
0 0 1 0 0 8
* * * * * ***
* * * * * ***
* * * * * ***
1 1 1 1 1 62
Note: Maximum distance aft from aircraft nose is 62 meters or 203.412 feet.
When Position Offset Applied (see Table A-22) is set to ONE (1), the GPS Antenna
Offset subfield is set to ALL ZEROs (0).
Note: When Position Offset Applied (see Table A-22) is set to ONE (1), it means that
the GPS antenna position has already been compensated for in the reported
latitude and longitude position subfields of the Surface Position Message.
Ensuring that the GPS Antenna subfield is set to ALL ZEROs in this case ensures
that the offset compensation is not performed again by a receiving application.
A.1.5 Initialization and Timeout

Note: Initialization and timeout functions for Extended Squitter broadcast are
performed by the transponder and are specified in RTCA/DO-181D. A
description of these functions is presented in the following paragraphs to serve
as reference material for the section on the GFM (A.1.6).
20xx, RTCA, Inc.

Appendix A
Page A - 48
A.1.5.1 Initiation of Extended Squitter Broadcast

At power up initialization, the transponder will commence operation in a mode in which
it broadcasts only acquisition squitters. The transponder will initiate the broadcast of
Extended Squitters for Airborne Position, Surface Position, Aircraft Identification and
Category, Airborne Velocity, Target State and Status and Operational Status when data
are inserted into Registers 0516, 0616, 0816, 0916, 6216 and 6516 respectively. This
determination will be made individually for each squitter type. The insertion of just
altitude or surveillance status data into Register 0516 by the transponder will not satisfy
the minimum requirement for broadcast of the airborne position squitter.
Note: This suppresses the transmission of Extended Squitters from aircraft that are
unable to report position, velocity or identity information.
A.1.5.2 Register Timeout

Notes:
1. These Registers are cleared to prevent the reporting of outdated position and velocity
information.
2. During a register timeout event, the ME field of the ADS-B Broadcast Message
may contain ALL ZEROs, except for those fields that may be updated due to the
receipt of new data.
a. The ADS-B Transmitting Subsystem will clear all but the altitude and surveillance
status subfields of the Airborne Position Message, if no new position data is received
within two (2) seconds of the previous input data update.
Note: During a timeout event the Format TYPE Code is set to ZERO (see
2.2.3.2.3.1.3.1).
b. The ADS-B Transmitting Subsystem will clear all 56-bits of the Surface Position
Message if no new position data is received within two (2) seconds of the previous
input data update.
Notes:
1. During a timeout event the Format TYPE Code is set to ZERO (see
2.2.3.2.4.1.3.1).
2. When position is available, the ADS-B Transmitting Subsystem manages the

movement and the ground track subfields such that the subfields and applicable
status bits are set to ZERO (0) if no new data is received for the subfield within
2.6 seconds of the last data update of the subfield.
3. When position data is not received, all bits of the Surface Position Message are
set to ZERO to avoid confusion with altitude data in the Airborne Position
Message sent with TYPE Code ZERO (0).
c. The ADS-B Transmitting Subsystem will clear all 56-bits of the Airborne Velocity
Message if no data is received within 2.6 seconds of the previous input data update.
20xx, RTCA, Inc.

Appendix A
Page A - 49
Note: The Intent Change information is not sufficient to consider that new data has
been received (2.2.3.2.6.1.3).
d. The ADS-B Transmitting Subsystem will not clear the Aircraft Identification
Message (see 2.2.3.2.5).
Note: The Aircraft Identification Message, is not cleared since it contains data that
rarely changes in flight and is not frequently updated.
e. The ADS-B Transmitting Subsystem will clear each of the Selected Altitude,
Selected Heading, or Barometric Pressure Setting subfields of the Target State and
Status Message (see 2.2.3.2.7.1) if no new data is received within 2.0 seconds of the
previous input data update for the respective subfield. Each of the subfields will be
cleared independently of the other subfields. That is, each of the three specified
subfields will be processed mutually exclusively of the other two specified subfields.
The remaining subfields of the Target State and Status Message will not be cleared,
as they contain other integrity, mode, or status information.
f. The ADS-B Transmitting Subsystem will not clear the Operational Status Messages
(see 2.2.3.2.7.2) since the subfields of the Message contain various integrity, mode,
or status information..
g. The ADS-B Transmitting Subsystem will not clear the Event-Driven Messages (see
2.2.3.2.7.8).
Note: The Event-Driven Messages do not need to be cleared since contents of such
messages are only broadcast once each time that new data is received.
A.1.5.3 Termination of Extended Squitter Broadcast

If input to Register 0516, or 0616 stops for 60 seconds, broadcast of the associated
Extended Squitter type will be discontinued until data insertion is resumed. The insertion
of altitude by the transponder will satisfy the minimum requirement for continuing to
broadcast the airborne position squitter.
If input to Register 0916 stops for 2.6 seconds, broadcast of the associated Extended
Squitter type will be discontinued until data insertion is resumed.
Notes:
1. Until timeout, an Extended Squitter type may contain an ME field of ALL ZEROs.
2. Continued transmission for 60 seconds is required so that receiving aircraft will

know that the data source for the message has been lost.
A.1.5.4 Requirements for Non-Transponder Devices

Non-Transponder Devices will provide the same functionality for initialization, Register
timeout and broadcast termination as specified for the transponder case in A.1.5.1
through A.1.5.3.
1. A Non-Transponder Device will not broadcast acquisition squitters, and
20xx, RTCA, Inc.

Appendix A
Page A - 50
2. A Non-Transponder Device operating on the surface will continue to broadcast

DF=18 Messages with the TYPE Code=0 at a rate specified for the Surface Position
Message, even though it has lost its navigation input.
Note: Continued broadcast of the Surface Position Message is needed to support

the operation of surface multi-lateration systems.
A.1.6 General Formatter/Manager (GFM)

Note: The General Formatter/Manager (GFM) is the name that will be used to refer to
the function that formats messages for insertion in the Extended Squitter
registers. In addition to data formatting, there are other tasks that have to be
performed by this function.
A.1.6.1 Navigation Source Selection

The GFM will be responsible for the selection of the default source for aircraft position
and velocity, the commanded altitude source, and for the reporting of the associated
position and altitude errors.
A.1.6.2 Loss of Input Data

The GFM will be responsible for loading the registers for which it is programmed at the
required update rate. If for any reason data is unavailable for a time equal to twice the
update interval or 2 seconds (whichever is greater), the GFM will ZERO old data (on a
per field basis) and insert the resulting message into the appropriate register.
Note: For Register 0516 and 0616 a loss of position data would cause the GFM to set the
Format TYPE Code to ZERO as the means of indicating no position data since
ALL ZEROs in the lat/lon fields is a legal value.
A.1.6.3 Special Processing for Format TYPE Code Zero
A.1.6.3.1 Significance of Format TYPE Code Equal to Zero

Notes:
1. Format TYPE Code ZERO (0) is labeled no position information. This is intended
to be used when the lat/lon information is not available or invalid, and still permit
the reporting of baro altitude loaded by the transponder. The principal use of this
message case is to provide ACAS the ability to passively receive altitude.
2. Special handling is required for the airborne and Surface Position Messages because
a CPR encoded value of ALL ZEROs in the Lat/Lon field is a valid value.
20xx, RTCA, Inc.

Appendix A
Page A - 51
A.1.6.3.2 Broadcast of Format TYPE Code Equal to Zero
Format TYPE Code 0 will only be set by the following events:
1. Airborne Position or Surface Position (Register 0516, and 0616) has not been loaded
by the GFM for 2 seconds. In this case the transponder clears the entire 56 bits of the
register that timed out. (In the case of the Airborne Position register, the altitude
subfield is only ZEROed if no altitude data is available). Transmission of the
Airborne and Surface Position Extended Squitter that broadcasts the timed out
register will itself stop in 60 seconds except for the Airborne Position Message when
Altitude is still available. Broadcast of this Extended Squitter will resume when the
GFM begins to insert data into the register.
2. The GFM determines that all navigation sources that can be used for the Extended
Squitter airborne or Surface Position Message are either missing or invalid. In this
case the GFM can clear the Format TYPE Code and all other fields of the airborne
position, surface position and insert this zeroed message in the appropriate register.
This should only be done once so that the transponder can detect the loss of data
insertion and suppress the broadcast of the related squitter.
Note that in all of the above cases, a Format TYPE Code of ZERO contains a message of
ALL ZEROs. The only exception is the airborne position format that may contain
barometric altitude and surveillance status data as set by the transponder. There is no
analogous case for the other Extended Squitter format types, since a ZERO value in any
of the fields indicates no information. No other squitter types are broadcast with TYPS
Code equal ZERO (0).
A.1.6.3.3 Reception of Format TYPE Code Equal to Zero

If a squitter with format TYPE Code equal to ZERO (0) is received, it will be checked to
see if altitude is present. If altitude is not present, the message will be discarded. If
altitude is present, it may be used to update altitude. An Extended Squitter containing
Format TYPE Code ZERO will only be used to update the altitude of an aircraft already
in track.
Note: For ACAS, this could be an aircraft that was being maintained via hybrid
surveillance when the position data input failed. In this case, altitude only could
be used for a short period of time. Interrogation would have to begin at the
update rate for that track to ensure update of range and bearing information on
the display.
A.1.6.4 Handling of Event-Driven Protocol

The Event-Driven interface protocol will provide a general-purpose interface into the
transponder function for either those messages beyond those that are regularly
transmitted all the time (provided input data is available), or those that are transmitted at
a fixed periodic rate. This protocol will operate by having the transponder broadcast a
message once each time the Event-Driven register is loaded by the GFM.
Note: This gives the GFM complete freedom in setting the update rate (up to a
maximum) and duration of broadcast for applications such as emergency status
and intent reporting.
20xx, RTCA, Inc.

Appendix A
Page A - 52
In addition to formatting, the GFM will control the timing of message insertion so that it
provides the necessary pseudo-random timing variation and does not exceed the
maximum transponder broadcast rate for the Event-Driven protocol.
A.1.6.4.1 Transponder Support for the Event Driven Protocol

A message will be transmitted once by the transponder, each time that Register 0A16 is
loaded. Transmission will be delayed if the transponder is busy at the time of insertion.
Note: Delay times are short, a maximum of several milliseconds for the longest
transponder transaction.
The maximum transmission rate for the Event-Driven protocol will limited by the
transponder to twice per second. If a message is inserted in the Event-Driven register and
cannot be transmitted due to rate limiting, it will be held and transmitted when the rate
limiting condition has cleared. If a new message is received before transmission is
permitted, it will overwrite the earlier message.
Note: The squitter transmission rate and the duration of squitter transmissions is
application dependent. Choices made should be the minimum rate and duration
consistent with the needs of the application.
A.1.6.4.2 GFM Use of the Event-Driven Protocol

Note: More than one application at a time may be supported by the Event-Driven
protocol. The GFM handles requests for broadcast by these applications and is
the only function that is capable of inserting data into Register 0A 16. In this way,
the GFM can provide the pseudo random timing for all applications using this
protocol and maintain a maximum insertion rate that does not exceed the
transponder imposed limit.
An application that wants to use the Event-Driven protocol will notify the GFM of the
format type and required update rate. The GFM will then locate the necessary input data
for this format type and begin inserting data into Register 0A16 at the required rate. The
GFM will also insert this message into the register for this format type. This register
image will be maintained to allow readout of this information by air-ground or air-air
register readout. When broadcast of a format type ceases, the GFM will clear the
corresponding register assigned to this message.
The maximum rate that can be supported by the Event-Driven protocol will be twice per
second from one or a collection of applications. For each Event-Driven format type
being broadcast, the GFM will retain the time of the last insertion into Register 0A 16.
The next insertion will be scheduled at a random interval that is uniformly distributed
over the range of the update interval 0.1 second relative to the previous insertion into
Register 0A16 for this format type.
The GFM will monitor the number of insertions scheduled in any one second interval. If
more than two would occur, the GFM will schedule the pending messages based on
message priorities and queue management rules defined in A.1.4.6.3 in order to ensure
that the limit of two messages per second is observed while ensuring that high priority
Extended Squitter Message as broadcast at the required rates.
20xx, RTCA, Inc.

Appendix A
Page A - 53
A.1.6.4.3 Event-Driven Message Transmission Scheduling Function
The Event-Driven Message Scheduling Function will ensure that the total Event-Driven
Message rate does not exceed 2 transmitted messages per second.
The Event-Driven Message Scheduling Function will apply the following rules as a
means of prioritizing the Event-Driven Message transmissions and limited the
transmission rates:
a. The Event-Driven Message scheduling function will reorder, as necessary, pending

Event-Driven Messages according to the following message priorities, listed below in
descending order from highest to lowest priority:
i. When an Extended Squitter Status Message is active for the broadcast of an

Emergency/Priority Condition (TYPE=28 and Subtype=1), or a TCAS RA
Broadcast (TYPE=28, Subtype=2), then that message will continue to be
transmitted at random intervals that are uniformly distributed over the range of
0.7 to 0.9 seconds, relative to the previous respective Aircraft Status Message for
the duration of the emergency or TCAS RA condition if the Target State and
Status Message is not being broadcast. If the Target State and Status Message
with Subtype=0 is being broadcast, then the Emergency/Priority Status, or the
TCAS RA Broadcast Message will be broadcast at random intervals that are
uniformly distributed over the range of 2.4 to 2.6 seconds relative to the previous
respective Aircraft Status Message for the duration of the emergency condition
established in accordance with Figure A-8, Note 2, or TCAS RA (established in
accordance with the notes in Figure A-8b). The broadcast of the 1090ES ADS-B
Aircraft Status TCAS RA Broadcast Message takes priority over the
Emergency/Priority Status broadcast, and all other Event-Driven Message types.
ii. Reserved for future use.
iii. Reserved for future use.
iv. When an Aircraft Operational Status Message is active (TYPE=31 and

Subtype=0) and there has been a change in one or more of the message
parameters within the past 24 seconds that results in a higher update rate
reporting requirement, the Aircraft Operational Status Message will be broadcast
at random intervals that are uniformly distributed over the range of 0.7 to 0.9
seconds. When enabled, the TEST Message with Subtype=7 shall be
broadcast at random intervals that are uniformly distributed over the range of
11.8 to 12.2 seconds from the time of transmission of the previous TEST
Message with Subtype=7.
v. When a Target State and Status Message is active for the broadcast of Target
State information (message TYPE=29 and Subtype=0) the Target State and
Status Message will be transmitted at random intervals that are uniformly
distributed over the range of 1.2 to 1.3 seconds relative to the previous Target
State and Status Message for as long as target state information is available and
valid.
vi. Reserved for future use.
20xx, RTCA, Inc.

Appendix A
Page A - 54
vii. When an Aircraft Operational Status Message is active (TYPE=31 and

Subtype=0) and there has been no change in the message parameters that would
require an increased broadcast rate, the Aircraft Operational Status Message will
be broadcast at random intervals uniformly distributed over the range of 2.4 to
2.6 seconds.
viii. This priority level applies as a default to any Event-Driven Message TYPE and
Subtype combination not specifically identified at a higher priority level above.
Event-Driven Messages of this default priority level will be delivered to the
transponder on a first-in-first-out basis at equal priority.
b. The Event-Driven Message scheduling function will limit the number of Event-
Driven Messages provided to the transponder to two (2) messages per second.
c. If (b) results in a queue of messages awaiting delivery to the transponder, the higher
priority pending messages, according to (a) above will be delivered to the
transponder for transmission before lower priority messages.
d. If (b) results in a queue of messages awaiting delivery to the transponder, new Event-
Driven messages will directly replace older messages of the same exact Type and
Subtype (where a Subtype is defined) that are already in the pending message queue.
The updated message will maintain the same position in the message queue as the
pending message that is being replaced.
e. If (b) above results in a queue of messages awaiting delivery to the transponder, then
pending message(s), will be deleted from the message transmission queue if not
delivered to the transponder for transmission, or not replaced with a newer message
of the same message Type and Subtype, within the Message Lifetime value specified
in the Table A-28 below:
Table A-28: Event-Driven Message Lifetime

Message Message Message Lifetime
TYPE Subtype (seconds)
=0 5.0 seconds (+/- 0.2 sec.)
23 = 1, 2, 3, 4, 5, or 6 Reserved (see Note)
=7 24 seconds (+/- 0.2 sec.)
=1 5.0 seconds (+/- 0.2 sec.)
28
0, > 1 Reserved (see Note)
=0 2.5 seconds (+/- 0.2 sec.)
29
>0 Reserved (see Note)
= 0, 1 5.0 seconds (+/- 0.2 sec.)
31
>1 Reserved (see Note)
Note: A default message lifetime of 20 seconds will be used for queue management
unless otherwise specified.
20xx, RTCA, Inc.

Appendix A
Page A - 55
A.1.7 Latitude/Longitude Coding Using Compact Position Reporting (CPR)
A.1.7.1 Principle of the CPR algorithm

Notes:
1. The Mode S Extended Squitters use Compact Position Reporting (CPR) to encode
Latitude and Longitude efficiently into messages. The resulting messages are
compact in the sense that several higher-order bits, which are normally constant for
long periods of time, are not transmitted in every message. For example, in a direct
binary representation of latitude, one bit would designate whether the aircraft is in
the northern or southern hemisphere. This bit would remain constant for a long time,
possibly the entire life of the aircraft. To repeatedly transmit this bit in every
position message would be inefficient.
2. Because the higher-order bits are not transmitted, it follows that multiple locations
on the earth will produce the same encoded position. If only a single position
message were received, the decoding would involve ambiguity as to which of the
multiple solutions is the correct location of the aircraft. The CPR technique includes
a provision to enable a receiving system to unambiguously determine the location of
the aircraft. This is done by encoding in two ways that differ slightly. The two
formats, called even-format and odd-format, are each transmitted fifty percent of the
time. Upon reception of both types within a short period (approximately 10 seconds
for airborne formats and 50 seconds for surface formats), the receiving system can
unambiguously determine the location of the aircraft.
3. Once this process has been carried out, the higher-order bits are known at the
receiving station, so subsequent single message receptions serve to unambiguously
indicate the location of the aircraft as it moves.
4. In certain special cases, a single reception can be decoded into the correct location
without an even/odd pair. This decoding is based on the fact that the multiple
locations are spaced by at least 360 NM. In addition to the correct locations, the
other locations are separated by integer multiples of 360 NM to the north and south
and also integer multiples of 360 NM to the east and west. In a special case in which
it is known that reception is impossible beyond a range of 180 NM, the nearest
solution is the correct location of the aircraft.
5. The parameter values in the preceding paragraph (360 and 180 NM) apply to the
airborne CPR encoding. For aircraft on the surface, the CPR parameters are
smaller by a factor of 4. This encoding yields better resolution but reduces the
spacing of the multiple solutions.
20xx, RTCA, Inc.

Appendix A
Page A - 56
A.1.7.2 CPR Algorithm Parameters and Internal Functions

The CPR algorithm shall utilize the following parameters whose values are set as follows
for the Mode S Extended Squitter application:
1. The number of bits used to encode a position coordinate, Nb, is set as follows:
For airborne encoding, used in the ADS-B
Airborne Position Message and the TIS-B Nb = 17
Fine Airborne Position Message:
For surface encoding, used in the ADS-B
Surface Position Message and the TIS-B Fine Nb = 19
Surface Position Message:
For intent encoding: Nb = 14
For TIS-B encoding, used only in the TIS-B
Nb = 12
Coarse Airborne Position Message:
Note 1: The Nb parameter determines the encoded position precision

(approximately 5 m for the airborne encoding, 1.25 m for the surface
encoding, 41 m for the intent encoding and 164 m for the TIS-B encoding).
2. The number of geographic latitude zones between the equator and a pole, denoted
NZ, is set to 15.
Note 2: The NZ parameter determines the unambiguous airborne range for

decoding (360 NM). The surface Latitude/Longitude encoding omits the
high-order 2 bits of the 19-bit CPR encoding, so the effective unambiguous
range for surface position reports is 90 NM.
The CPR algorithm shall define internal functions to be used in the encoding and
decoding processes.
a. The notation floor(x) denotes the floor of x, which is defined as the greatest integer
value k such that k x.
Note 3: For example, floor(3.8) = 3, while floor(-3.8) = -4.
b. The notation x denotes the absolute value of x, which is defined as the value x when
x 0 and the value x when x < 0.
c. The notation MOD(x,y) denotes the modulus function, which is defined to return
the value
x
MOD x, y x y floor where y 0.
y
Note 4: The value y is always positive in the following CPR algorithms. When x is
non-negative, MOD(x,y) is equivalent to the remainder of x divided by y.
When x represents a negative angle, an alternative way to calculate
MOD(x,y) is to return the remainder of (x+360 ) divided by y.
20xx, RTCA, Inc.

Appendix A
Page A - 57
For example, MOD 40 ,6 MOD(320 ,6 ) 2 .
d. The notation NL(x) denotes the number of longitude zones function of the latitude
angle x. The value returned by NL(x) is constrained to the range from 1 to 59.
NL(x) is defined for most latitudes by the equation,
1
1 cos
2 NZ ,
NL lat floor 2 arccos 1
2
cos lat
180
where lat denotes the latitude argument in degrees. For latitudes at or near the N or S
pole, or the equator, the following points are defined:
For lat = 0 (the equator), NL = 59
For lat = +87 degrees, NL = 2
For lat = -87 degrees, NL = 2
For lat > +87 degrees, NL = 1
For lat < -87 degrees, NL = 1
Note 5: This equation for NL() is impractical for a real-time implementation. A

table of transition latitudes can be pre-computed using the following
equation:
1 cos
180 2 NZ for NL = 2 to 4 NZ 1,
lat arccos
2
1 cos
NL
and a table search procedure used to obtain the return value for NL( ).
The table value for NL = 1 is 90 degrees. When using the look up table
established by using the equation above, the NL value is not expected to
change to the next lower NL value until the boundary (latitude established
by the above equation) has actually been crossed when moving from the
equator towards the pole.
A.1.7.3 CPR Encoding Process

The CPR encoding process shall calculate the encoded position values XZi and YZi for
either airborne, surface, intent, or TIS-B Latitude and Longitude fields from the global
position lat (latitude in degrees), lon (longitude in degrees), and the CPR encoding type i
(0 for even format and 1 for odd format), by performing the following sequence of
computations. The CPR encoding for intent always uses the even format (i = 0), whereas
the airborne, surface, and TIS-B encoding use both even (i = 0) and odd (i = 1) formats.
20xx, RTCA, Inc.

Appendix A
Page A - 58
a. Dlati (the latitude zone size in the N-S direction) is computed from the equation:
360
Dlati
4 NZ i
b. YZi (the Y-coordinate within the Zone) is then computed from Dlati and lat using
separate equations:
MOD lat, Dlati 1
For Nb = 17: YZi floor 217
Dlat i 2
MOD lat, Dlati 1

For Nb = 19: YZi floor 219
Dlat i 2
MOD lat, Dlat0 1

For Nb = 14: YZ0 floor 214
Dlat 0 2
MOD lat, Dlati 1

For Nb = 12: YZ i floor 212
Dlati 2
c. Rlati (the latitude that a receiving ADS-B system will extract from the transmitted
message) is then computed from lat, YZi, and Dlati using separate equations:
YZi lat
For Nb = 17: Rlati Dlat i 17 floor
2 Dlati
YZi lat
For Nb = 19: Rlati Dlat i 19 floor
2 Dlati
YZ 0 lat
For Nb = 14: Rlat0 Dlat0 floor
214 Dlat0
YZ i lat
For Nb = 12 Rlati Dlati floor
212 Dlati
d. Dloni (the longitude zone size in the E-W direction) is then computed from Rlati
using the equation:
360
, when NL Rlati i 0
NL Rlati i
Dloni
360 , when NL Rlati i 0
Note: When performing the NL function, the encoding process must ensure that the
NL value is established in accordance with Note 5 of A.1.7.2.d.
20xx, RTCA, Inc.

Appendix A
Page A - 59
e. XZi (the X-coordinate within the Zone) is then computed from lon and Dloni using
separate equations:
MOD lon, Dloni 1
For Nb = 17: XZi floor 217
Dloni 2
MOD lon, Dloni 1

For Nb = 19: XZi floor 219
Dloni 2
MOD lon, Dlon0 1

For Nb = 14: XZ0 floor 214
Dlon0 2
MOD lon, Dloni 1

For Nb = 12: XZ i floor 212
Dloni 2
f. Finally, limit the values of XZi and YZi to fit in the 17-bit, 14-bit or 12-bit field
allotted to each coordinate:
17
YZi MOD YZi , 2 ,
For Nb = 17: 17
XZi MOD XZi ,2
17
YZi MOD YZi , 2 ,
For Nb = 19: 17
XZi MOD XZi ,2
14
YZ0 MOD YZ0 ,2 ,
For Nb = 14: 14
XZ0 MOD XZ 0,2
12
YZi MOD YZi , 2 ,
For Nb = 12: 12
XZi MOD XZi ,2
A.1.7.4 Locally Unambiguous CPR Decoding

The CPR algorithm shall decode a geographic position (latitude, Rlati, and longitude,
Rloni,) that is locally unambiguous with respect to a reference point (lats, lons) known to
be within 180 NM of the true airborne position (or within 45 NM for a surface message).
Note: This reference point may be a previously tracked position that has been
confirmed by global decoding (A.1.7.7) or it may be the own aircraft position,
which would be used for decoding a new tentative position report.
The encoded position coordinates XZi and YZi and the CPR encoding type i (0 for the
even encoding and 1 for the odd encoding) contained in a Mode S Extended Squitter
20xx, RTCA, Inc.

Appendix A
Page A - 60
message shall be decoded by performing the sequence of computations given in A.1.7.5

for the airborne and intent format types and in A.1.7.6 for the surface format type.
A.1.7.5 Locally Unambiguous CPR Decoding for Airborne, TIS-B and Intent Lat/Lon
The following computations shall be performed to obtain the decoded lat/lon for the
airborne, intent, and TIS-B messages. For intent lat/lon, i is always 0 (even encoding),
whereas airborne and TIS-B lat/lon use both even (i=0) and odd (i=1) encodings. For
airborne lat/lon, Nb=17, for intent, Nb=14, and for TIS-B Nb=12
a. Dlati is computed from the equation:
360
Dlati
4 NZ i
b. The latitude zone index number, j, is then computed from the values of lats, Dlati and
YZi using the equation:
lats 1 MOD lats, Dlati YZi
j floor floor Nb
Dlati 2 Dlati 2
c. The decoded position latitude, Rlati, is then computed from the values of j, Dlati, and
YZi
Rlati Dlat i j Nb
2
d. Dloni (the longitude zone size in the E-W direction) is then computed from Rlati
using the equation:
360
, when NL Rlati i 0
NL Rlati i
Dloni
e. The longitude zone coordinate m is then computed from the values of lons, Dloni, and
XZi using the equation:
lons 1 MOD lons ,Dloni XZi
m floor floor Nb
Dloni 2 Dloni 2
f. The decoded position longitude, Rloni, is then computed from the values of m, XZi,
and Dloni using the equation:
XZi
Rloni Dloni m Nb
2
20xx, RTCA, Inc.

Appendix A
Page A - 61
A.1.7.6 Locally Unambiguous Decoding for Surface Position
The following computations shall be performed to obtain the decoded Latitude and
Longitude for the surface position format.
1. Dlati is computed from the equation:
90
Dlati
4 NZ i
2. The latitude zone index, j, is then computed from the values of lats, Dlati and YZi
using the equation:
lats 1 MOD lats , Dlati YZ i
j floor floor
Dlati 2 Dlati 217
3. The decoded position latitude, Rlati, is then computed from the values of j, Dlati, and
YZ i
Rlati Dlati j
217
4. Dloni (the longitude zone size, in the E-W direction) is then computed from Rlati
using the equation:
90
, when NL Rlati i 0
NL Rlati i
Dloni
5. The longitude zone coordinate m is then computed from the values of lons, Dloni, and
XZi using the equation:
lons 1 MOD lons , Dloni XZ i
m floor floor
Dloni 2 Dloni 217
6. The decoded position longitude, Rloni, is then computed from the values of m, XZi,
and Dloni using the equation:
XZ i
Rloni Dloni m
217
A.1.7.7 Globally Unambiguous Airborne Position Decoding

The CPR algorithm shall utilize one airborne-encoded even format reception (denoted
XZ0, YZ0), together with one airborne-encoded odd format reception (denoted XZ1, YZ1),
to regenerate the global geographic position latitude, Rlat, and longitude, Rlon. The time
between the even and odd format encoded position reports shall be not longer than
10 seconds for airborne formats.
20xx, RTCA, Inc.

Appendix A
Page A - 62
Note 1: This algorithm might be used to obtain globally unambiguous position reports
for aircraft out of the range of ground sensors, whose position reports are
coming via satellite data links. It might also be applied to ensure that local
positions are being correctly decoded over long ranges from the receiving
sensor.
Note 2: The time difference limit of 10 seconds between the even- and odd-format
position reports for airborne formats is determined by the maximum permitted
separation of 3 NM. Positions greater than 3 NM apart cannot be used to
solve for a unique global position. An aircraft capable of a speed of 1,850
km/h (1,000 kt) will fly about 5.1 km (2.8 NM) in 10 seconds. Therefore, the
CPR algorithm will be able to unambiguously decode its position over a 10-
second delay between position reports.
Given a 17-bit airborne position encoded in the even format (XZ0, YZ0) and another
encoded in the odd format (XZ1, YZ1), separated by no more than 10 seconds (= 3 NM),
the CPR algorithm shall regenerate the geographic position from the encoded position
reports by performing the following sequence of steps:
a. Compute Dlat0 and Dlat1 from the equation:

360
Dlati
4 NZ i
b. Compute the latitude index:
59 YZ 0 60 YZ1 1
j floor
217 2
c. Compute the values of Rlat0 and Rlat1 using the following equation:
YZ i
Rlati Dlati MOD j,60 i
217
Southern hemisphere values of Rlati will fall in the range from 270 to 360.
Subtract 360 from such values, thereby restoring Rlati to the range from 90 to
+90 .
d. If NL(Rlat0) is not equal to NL(Rlat1) then the two positions straddle a transition
latitudethus a solution for global longitude is not possible. Wait for positions
where they are equal.
Note 3: When performing the NL function, the encoding process must ensure that
the NL value is established in accordance with Note 5 of A.1.7.2.d. This
is more important in the Global Unambiguous Decode because large
longitude errors are induced if the decode function is not selecting the NL
value properly as discussed in Note 5 of A.1.7.2.d.
20xx, RTCA, Inc.

Appendix A
Page A - 63
e. If NL(Rlat0) is equal to NL(Rlat1) then proceed with computation of Dloni, according
to whether the most recently received Airborne Position Message was encoded with
the even format (i = 0) or the odd format (i = 1) :
360
Dloni ,
ni
where ni greater of NL(Rlati ) i and 1 .
f. Compute m, the longitude index:
XZ 0 NL 1 XZ 1 NL 1
m floor ,
217 2
where NL NL Rlati .
g. Compute the global longitude, Rlon0 or Rlon1, according to whether the most recently
received Airborne Position Message was encoded using the even format (that is, with
i = 0) or the odd format (i = 1):
XZi
Rloni Dloni MOD m,ni 17 ,
2
where ni greater of NL(Rlati ) i and 1 .
h. A reasonableness test shall be applied to the resulting decoded position in accordance

with A.1.7.10.2.
A.1.7.8 Globally Unambiguous CPR Decoding of Surface Position

This algorithm shall utilize one CPR surface position encoded even format message
together with one CPR surface position encoded odd format message, to regenerate the
geographic position of the aircraft or target.
As surface-format messages are initially received from a particular aircraft, if there is no

prior history of this aircraft, then a global decode shall be performed using even and
odd format receptions, as described in this section.
Note 1: If the aircraft has been transmitting airborne format messages and their
receptions were in-track, then it is not necessary to use even-odd decoding.
Beginning with the first individual Surface Position Message reception, the
location can be decoded using the local-decode technique, based on the
previous target location as the reference.
20xx, RTCA, Inc.

Appendix A
Page A - 64
Note 2: Even if the aircraft is appearing for the first time in surface format receptions,
any single message could be decoded by itself into multiple locations, one
being the correct location of the transmitting aircraft, and all of the others
being separated by 90 NM or more from the correct location. Therefore, if it
were known that the transmitting aircraft cannot be farther away than 45 NM
from a known location, then the first received message could be decoded using
the locally unambiguous decoding method described in A.1.7.6. Under some
circumstances it may be possible for an aircraft to be first detected when it is
transmitting Surface Position Messages farther than 45 NM away from the
receiving station. For this reason, even-odd decoding is required when
messages are initially received from a particular aircraft. After this initial
decode, as subsequent messages are received, they can be decoded individually
(without using the even-odd technique), provided that the intervening time is
not excessive. This subsequent decoding is based on the fact that the aircraft
location has not changed by more than 45 NM between each new reception
and the previously decoded location.
The even-odd decoding process shall begin by identifying a pair of receptions, one in the
even format, the other in the odd format, and whose separation in time does not
exceed the time interval of X seconds, where X=50 seconds, unless the Ground Speed in
either Surface Position Message is greater than 25 knots, or is unknown, in which cases
X=25 seconds.
Note 3: The limit of 25 seconds is based on the possible change of location within this
time interval. Detailed analysis of CPR indicates that if the change of location
is 0.75 NM or less, then the decoding will yield the correct location of the
aircraft. To assure that the change of location is actually no larger, and
considering the maximum aircraft speed of 100 knots specified for the
transmission of the surface format, the combination indicates that 25 seconds
will provide the needed assurance. For targets on the airport surface when
speeds are much less and the transmission rate is as low as one per 5 seconds,
the corresponding time limit is 50 seconds.
Given a CPR 17-bit surface position encoded in the even format (XZ0, YZ0) and
another encoded in the odd format (XZ1, YZ1), separated by no more than X seconds,
the algorithm shall regenerate the geographic position (latitude Rlat, and longitude Rlon)
of the aircraft or target by performing the following sequence of steps:
a. Compute the latitude zone sizes Dlat0 and Dlat1 from the equation:
90
Dlati
60 i
b. Compute the latitude index:

59 YZ o 60YZ1 1
j floor
217 2
20xx, RTCA, Inc.

Appendix A
Page A - 65
c. Latitude. The following formulas will yield two mathematical solutions for latitude
(for each value of i), one in the northern hemisphere and the other in the southern
hemisphere. Compute the northern hemisphere solution of Rlat0 and Rlat1 using the
following equation:
YZ i
Rlati Dlati MOD j,60 i
217
The southern hemisphere value is the above value minus 90 degrees.
To determine the correct latitude of the target, it is necessary to make use of the
location of the receiver. Only one of the two latitude values will be consistent with
the known receiver location, and this is the correct latitude of the transmitting
aircraft.
d. The first step in longitude decoding is to check that the even-odd pair of messages do
not straddle a transition latitude. It is rare, but possible, that NL(Rlat0) is not equal to
NL(Rlat1). If so, a solution for longitude cannot be calculated. In this event,
abandon the decoding of this even-odd pair, and examine further receptions to
identify another pair. Perform the decoding computations up to this point and check
that these two NL values are equal. When that is true, proceed with the following
decoding steps.
NL value is established in accordance with Note 5 of A.1.7.2.d. This is
more important in the Global Unambiguous Decode because large longitude
errors are induced if the decode function is not selecting the NL value
properly as discussed in Note 5 of A.1.7.2.d.
e. Compute the longitude zone size Dloni, according to whether the most recently
received surface position message was encoded with the even format (i=0) or the odd
format (i=1):
90
Dloni , where ni is the greater of [NL(Rlati ) - i] and 1.
ni
f. Compute m, the longitude index:

XZ 0 NL 1) XZ 1 NL 1
m floor
217 2
where NL = NL (Rlati )
20xx, RTCA, Inc.

Appendix A
Page A - 66
g. Longitude. The following formulas will yield four mathematical solutions for
longitude (for each value of i), one being the correct longitude of the aircraft, and the
other three separated by at least 90 degrees. To determine the correct location of the
target, it will be necessary to make use of the location of the receiver. Compute the
longitude, Rlon0 or Rlon1, according to whether the most recently received surface
position message was encoded using the even format (that is, with i=0) or the odd
format (i=1):
XZi
Rloni Dloni MOD m,ni
217
where ni is the greater of [NL(Rlati ) - i] and 1.
This solution for Rloni will be in the range 0 to 90. The other three solutions are
90, 180, and 270 to the east of this first solution.
h. A reasonableness test shall be applied to the resulting decoded position in accordance

with A.1.7.10.2.
To then determine the correct longitude of the transmitting aircraft, it is necessary to

make use of the known location of the receiver. Only one of the four mathematical
solutions will be consistent with the known receiver location, and this is the correct
longitude of the transmitting aircraft.
Note: Near the equator the minimum distance between the multiple longitude solutions
is more than 5000 NM, so there is no question as to the correct longitude. For
locations away from the equator, the distance between solutions is less, and
varies according to the cosine of latitude. For example at 87 degrees latitude,
the minimum distance between solutions is 280 NM. This is sufficiently large to
provide assurance that the correct aircraft location will always be obtained.
Currently no airports exist within 3 degrees of either pole, so the decoding as
specified here will yield the correct location of the transmitting aircraft for all
existing airports.
A.1.7.9 CPR Decoding of Received Position Reports
A.1.7.9.1 Overview
Note: The techniques described in the preceding paragraphs (locally and globally
unambiguous decoding) are used together to decode the lat/lon contained in
airborne, surface intent and TIS-B position reports. The process begins with
globally unambiguous decoding based upon the receipt of an even and an odd
encoded position squitter. Once the globally unambiguous position is
determined, the emitter centered local decoding technique is used for subsequent
decoding based on a single position report, either even or odd encoding.
20xx, RTCA, Inc.

Appendix A
Page A - 67
A.1.7.9.2 Emitter Centered Local Decoding
In this approach, the most recent position of the emitter shall be used as the basis for the
local decoding.
Note: This produces an unambiguous decoding at each update, since the transmitting
aircraft cannot move more than 360 NM between position updates.
A.1.7.10 Reasonableness Test for CPR Decoding of Received Position Messages
A.1.7.10.1 Overview
Note: Although receptions of Position Messages will normally lead to a successful
target position determination, it is necessary to safeguard against Position
Messages that would be used to initiate or update a track with an erroneous
position. A reasonableness test applied to the computed position resulting from
receipt of a Position Message can be used to discard erroneous position updates.
Since an erroneous globally unambiguous CPR decode could potentially exist for
the life of a track, a reasonableness test and validation of the position protects
against such occurrences.
A.1.7.10.2 Reasonableness Test Applied to Position Determined from Globally Unambiguous

Decoding
A reasonableness test shall be applied to a position computed using the Globally
Unambiguous CPR decoding per A.1.7.7 for Airborne Participants, or per A.1.7.8 for
Surface Participants. Upon receipt of the even or odd encoded Position Message that
completes the Globally Unambiguous CPR decode, the receiver shall perform a
reasonableness test on the position decode by performing the following:
If the receiver position is known, calculate the distance between the decoded position and
the receiver position, and verify that the distance is less than the maximum reception
range of the receiver. If the validation fails, the receiver shall discard the decoded
position that the even and odd Position Messages used to perform the globally
unambiguous CPR decode, and reinitiate the Globally Unambiguous CPR decode
process.
A further validation of the Globally Unambiguous CPR decode, passing the above test,
shall be performed by the computation of a second Globally Unambiguous CPR decode
based on reception of a new odd and an even Position Message as per A.1.7.7 for an
Airborne Participant, or per A.1.7.8 for a Surface Participant, both received subsequent
to the respective odd and even Position Message used in the Globally Unambiguous
CPR decode under validation. Upon accomplishing the additional Globally
Unambiguous CPR decode, this decoded position and the position from the locally
unambiguous CPR decode resulting from the most recently received Position Message
shall be checked to be identical to within 5 meters for an airborne decode and 1.25
meters for a surface decode.. If the two positions are not identical to within this
tolerance, the validation is failed and the initial Globally Unambiguous CPR decode
under validation shall be discarded and the track shall be reinitialized.
20xx, RTCA, Inc.

Appendix A
Page A - 68
Note: The position obtained from the initial global CPR decode is subsequently
updated using local CPR decoding, until an independent odd and even
Position Message pair has been received. When this occurs, a second global
CPR decode is performed. The resulting position is compared to the position
update obtained from the local CPR decode using the most recently received
Position Message. These two positions should agree since they are computed
from the same message.
A.1.7.10.3 Reasonableness Test Applied to Position Determined from Locally Unambiguous

Decoding
A reasonableness test shall be applied to a position computed using the Locally
Unambiguous CPR decoding per A.1.7.5 for Airborne, TIS-B or Intent Participants, or
per A.1.7.6 for Surface Participants. Upon receipt of the even or odd encoded
Position Message that completes the Locally Unambiguous CPR decode, the receiver
shall perform a reasonableness test on the most recently received position decode by
performing the following test:
If the difference between the TOMRs of the previously received Position Message
and the most recently received Position Message is 30 seconds or less, and the
reported position in the most recently received Position Message differs from the
previously reported position by more than X NM,
where:
X=6 for Airborne Participants receiving Airborne Position Messages, or
X=2.5 for Airborne Participants that have received a Surface Position Message, or
X=2.5 for Surface Participants that have received an Airborne Position Message, or
X=0.75 for Surface Participants receiving Surface Position Messages,
then the most recently received position shall not be used to update the track.
Note: The position threshold value is based on the assumption of a maximum

aircraft velocity of V knots (where V=600 for Airborne and V=50 for
Surface) over a maximum time period of 30 seconds. This yields a maximum
positional difference of approximately 5 NM for Airborne, and 0.5 NM for
Surface. An additional measure of 1 NM for Airborne, and 0.25 NM for
Surface are added to account for additional ADS-B positional measurement
uncertainty.
A.1.8 Formats for Extended Squitter

The Extended Squitter messages will be formatted as defined in the following tables.
Note: In some cases, ARINC 429 labels are referenced for specific message fields.
These references are only intended to clarify the field content, and are not
intended as a requirement to use these ARINC 429 labels as the source for the
message field.
20xx, RTCA, Inc.

Appendix A
Page A - 69
Figure A-1: Extended Squitter Airborne Position
Register 0516
1 Purpose: To provide accurate airborne position information.

2
3 FORMAT TYPE CODE
4 (A.1.4.1) Surveillance Status Coding
5 0 = no condition information
6 1 = permanent alert (emergency condition)
SURVEILLANCE STATUS
7 2 = temporary alert (change in Mode A identity code other
8 NIC SUPPLEMENT-B (A.1.4.2.5) than emergency condition
9 3 = SPI condition
10
11 ALTITUDE Codes 1 and 2 take precedence over code 3.
12 Specified by the Format TYPE Code
13
14 (1) the altitude code (AC) as specified in 2.2.13.1.2 of Note: When horizontal position information is unavailable,
15 DO-181D, but with the M-bit removed (Ref ARINC 429 but altitude information is available, the Airborne
16 Label 203), or Position Message is transmitted with a Format TYPE
17 Code of ZERO in bits 1-5 and the barometric pressure
18 (2) GNSS Height (HAE) (Ref. ARINC 429 Label 370) altitude in bits 9 to 20. If neither horizontal position
19 nor barometric altitude information is available, then
20 all 56 bits of Register 0516 are ZEROed. The ZERO
21 TIME (T) (A.1.4.2.2)
Format TYPE Code field indicates that Latitude and
22 CPR FORMAT (F) (A.1.4.2.1)
Longitude information is unavailable, while the ZERO
23 MSB
24
altitude field indicates that altitude information is
25
unavailable.
26
27
28
29
30 CPR ENCODED LATITUDE
31
32 (CPR Airborne Format A.1.7.1 to A.1.7.7)
33
34
35
36
37
38
39 LSB
40 MSB
41
42
43
44
45
46
47 CPR ENCODED LONGITUDE
48
49 (CPR Airborne Format A.1.7.1 to A.1.7.7)
50
51
52
53
54
55
56 LSB
20xx, RTCA, Inc.

Appendix A
Page A - 70
Figure A-2: Extended Squitter Surface Position
Register 0616
1 Purpose: To provide accurate surface position information.

2
3 FORMAT TYPE CODE
4 (A.1.4.1)
5
6
7
8
9 MOVEMENT
10 (A.1.4.3.1)
11
12
13 STATUS for Heading (1 = valid, 0 = not valid)
14 MSB
15
16 HEADING (7 bits)
17 (A.1.4.3.2)
18 Resolution = 360/128 degrees
19
20 LSB
21 TIME (T) (A.1.4.2.2)
22 CPR FORMAT (F) (A.1.4.2.1)
23 MSB
24
25
26
27
28
29
31
32 (CPR Surface Format A.1.7.1 to A.1.7.7)
33
34
35
36
37
38
39 LSB
40 MSB
41
42
43
44
45
46
48
49 (CPR Surface Format A.1.7.1 to A.1.7.7)
50
51
52
53
54
55
56 LSB
20xx, RTCA, Inc.

Appendix A
Page A - 71
Figure A-3: Extended Squitter Status
Register 0716
1 Purpose: To provide information on the capability and status

TRANSMISSION RATE SUBFIELD (TRS)
2 of the Extended Squitter rate of the transponder.
3 ALTITUDE TYPE SUBFIELD (ATS)
4
5 Transmission Rate Subfield (TRS) coding:
6 0 = No capability to determine surface squitter rate
7 1 = High surface squitter rate selected
8 2 = Low surface squitter rate selected
9 3 = Reserved
10
11
12 Altitude Type Subfield (ATS) coding:
13 0 = Barometric altitude
14 1 = GNSS Height (HAE), ARINC 429 Label 370
15
16
17 Note: Aircraft determination of surface squitter rate. For
18 aircraft that have the capability to automatically
19 determine their surface squitter rate, the method that
20 must be used to switch between the high and low
21 transmission rates is as follows:
22
23 a) Switching from high to low rate: Aircraft must
24 switch from high to low rate when the onboard
25 navigation unit reports that the aircrafts
26 position has not changed more than 10 meters in
27 any 30 second interval.
28 RESERVED
29 b) Switching from low to high rate: Aircraft must
30 switch from low to high rate as soon as the
31 aircrafts position has changed by 10 meters, or
32 more since the low rate was selected.
33
34 In all cases, the automatically selected transmission
35 rate is subject to being overridden by commands
36 received from ground control.
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
20xx, RTCA, Inc.

Appendix A
Page A - 72
Figure A-4: Extended Squitter Identification and Category
Register 0816
1 Purpose: To provide aircraft identification and category.

2
3 FORMAT TYPE CODE
4 (A.1.4.1) TYPE Coding:
5 1 = Aircraft identification, Category Set D
6 2 = Aircraft identification, Category Set C
7 AIRCRAFT EMITTER CATEGORY 3 = Aircraft identification, Category Set B
8 4 = Aircraft identification, Category Set A
9 MSB
10
11 CHARACTER 1 ADS-B Aircraft Emitter Category coding:
12
13 Set A
14 LSB 0 = No ADS-B Emitter Category Information
15 MSB 1 = Light (< 15500 lbs)
16 2 = Small (15500 to 75000 lbs)
17 CHARACTER 2 3 = Large (75000 to 300000 lbs)
18 4 = High Vortex Large (aircraft such as B-757)
19 5 = Heavy (> 300000 lbs)
20 LSB 6 = High Performance (> 5g acceleration and 400 kts)
21 MSB 7 = Rotorcraft
22
23 CHARACTER 3
24 Set B
25 0 = No ADS-B Emitter Category Information
26 LSB 1 = Glider / sailplane
27 MSB 2 = Lighter-than-air
28 3 = Parachutist / Skydiver
29 CHARACTER 4 4 = Ultralight / hang-glider / paraglider
30 5 = Reserved
31 6 = Unmanned Aerial Vehicle
32 LSB 7 = Space / Trans-atmospheric vehicle
33 MSB
34
35 CHARACTER 5 Set C
37 1 = Surface Vehicle Emergency Vehicle
38 LSB 2 = Surface Vehicle Service Vehicle
39 MSB 3 = Point Obstacle (includes tethered balloons)
40 4 = Cluster Obstacle
41 CHARACTER 6 5 = Line Obstacle
42 6 = Reserved
43 7 = Reserved
44 LSB
45 MSB
46 Set D (Reserved)
47 CHARACTER 7
48
49 Aircraft Identification coding:
50 LSB Character coding as specified in A.1.4.4.
51 MSB
52
53 CHARACTER 8
54
55
56 LSB
20xx, RTCA, Inc.

Appendix A
Page A - 73
Figure A-5: Extended Squitter Airborne Velocity

(Subtypes 1 and 2: Velocity Over Ground)
Register 0916
1 MSB 1 Purpose: To provide additional state information for both

2 0 normal and supersonic flight.
3 FORMAT TYPE CODE = 19 0
4 1
5 LSB 1 Subtype Coding:
6 Subtype 1 0 Subtype 2 0
7 0 1 Code Velocity Type
8 1 0 0 Reserved
9 INTENT CHANGE FLAG (A.1.4.5.3) 1 Ground Normal
10 RESERVED-A 2 Speed Supersonic
11 3 Airspeed, Normal
NAVIGATION ACCURACY CATEGORY FOR VELOCITY
12 4 Heading Supersonic
(NACV) (A.1.4.5.5)
13 5 Not Assigned
14 DIRECTION BIT for E-W Velocity (0=East, 1=West) 6 Not Assigned
15 EAST-WEST VELOCITY (10 bits) 7 Not Assigned
16 NORMAL : LSB = 1 knot SUPERSONIC : LSB = 4 knots
17 All zeros = no velocity info All zeros = no velocity info
18 Value Velocity Value Velocity Reference ARINC Labels for Velocity:
19 1 0 kts 1 0 kts East - West North - South
20 2 1 kt 2 4 kts GPS: 174 GPS: 166
21 3 2 kts 3 8 kts INS: 367 INS: 366
22 --- --- --- ---
23 1022 1021 kts 1022 4084 kts
24 1023 >1021.5 kts 1023 > 4086 kts Reference ARINC Labels:
25 DIRECTION BIT for N-S Velocity (0=North, 1=South) GNSS Height (HAE): GPS 370
26 NORTH SOUTH VELOCITY (10 bits) GNSS Altitude (MSL): GPS: 076
29 Value Velocity Value Velocity
30 1 0 kts 1 0 kts
31 2 1 kt 2 4 kts
32 3 2 kts 3 8 kts
33 --- --- --- ---
34 1022 1021 kts 1022 4084 kts
35 1023 > 1021.5 kts 1023 > 4086 kts
36 SOURCE BIT FOR VERTICAL RATE (0=Geometric, 1=Baro)
37 SIGN BIT FOR VERTICAL RATE (0=Up, 1=Down)
38 VERTICAL RATE (9 bits)
39 All zeros no vertical rate info, LSB = 64 feet/min
40 Value Vertical Rate Reference
41 1 0 ft/min ARINC 429 labels
42 2 64 ft/min GPS: 165
43 --- --- INS: 365
44 510 32576 ft/min
45 511 > 32608 ft/min
46
47
RESERVED-B
48
49 DIFFERENCE SIGN BIT (0 = Above Baro, 1 = Below Baro Alt)
GEOMETRIC HEIGHT DIFFERENCE FROM BARO ALT.
50
(7 bits) (A.1.4.5.7) (All zeros = no info) (LSB = 25 feet)
51 Value Difference
52 1 0 feet
53 2 25 feet
54 --- ---
55 126 3125 feet
56 127 > 3137.5 feet
20xx, RTCA, Inc.

Appendix A
Page A - 74
Figure A-6: Extended Squitter Airborne Velocity

(Subtypes 3 and 4: Airspeed and Heading)
Register 0916
1 MSB 1 Purpose: To provide additional state information for both

2 0 normal and supersonic flight based on airspeed and heading.
3 FORMAT TYPE CODE = 19 0
4 1
5 LSB 1 Note: This format is only used if velocity over ground is not
6 Subtype 3 0 Subtype 4 1 available.
7 1 0
8 1 0
9 INTENT CHANGE FLAG (A.1.4.5.3) Subtype Coding:
10 RESERVED-A
11 Code Velocity Type
NAVIGATION ACCURACY CATEGORY FOR VELOCITY
12 0 Reserved
(NACV) (A.1.4.5.5)
13 1 Ground Normal
14 STATUS BIT (1 = Heading available, 0 = Not available) 2 Speed Supersonic
15 MSB 3 Airspeed, Normal
17 5 Not Assigned
18 HEADING (10 bits) 6 Not Assigned
19 (A.1.4.5.6) 7 Not Assigned
21
22 Reference ARINC Label
23 INS: 320 Reference ARINC 429 Labels
24 LSB for Air Data Source:
25 AIRSPEED TYPE (0 = IAS, 1 = TAS) IAS: 206
26 AIRSPEED (10 bits) TAS: 210
27 NORMAL: LSB = 1 knot SUPERSONIC: LSB = 4 knots
29 Value Velocity Value Velocity Reference ARINC Labels:
30 1 0 kts 1 0 kts GNSS Height (HAE): GPS 370
31 2 1 kt 2 4 kts GNSS Altitude (MSL): GPS: 076
32 3 2 kts 3 8 kts
33 --- --- --- ---
34 1022 1021 kts 1022 4084 kts
35 1023 > 1021.5 kts 1023 > 4086 kts
36 SOURCE BIT FOR VERTICAL RATE (0=Geo, 1=Baro)
37 SIGN BIT FOR VERTICAL RATE (0=Up, 1=Down)
39 All zeros no vertical rate information
40 LSB = 64 feet/min
41 Value Vertical Rate Reference
42 1 0 ft/min ARINC Labels
43 2 64 ft/min GPS: 165
44 --- --- INS: 365
45 510 32576 ft/min
46 511 > 32608 ft/min
47
RESERVED-B
48
49 DIFFERENCE SIGN BIT (0 = Above Baro, 1 = Below Baro Alt)
GEOMETRIC HEIGHT DIFFERENCE FROM BARO ALT
50
51 Value Vertical Rate
52 1 0 ft
53 2 25 ft
54 --- ---
55 126 3125 ft
56 127 > 3137.5 ft
20xx, RTCA, Inc.

Appendix A
Page A - 75
Figure A-7: Extended Squitter Event-Driven Register
Register 0A16
1 Purpose: To provide a flexible means to squitter messages

2 other than position, velocity and identification.
3
4
5 Note: The data in this Register is not intended for Extraction
6 using GICB or TCAS crosslink protocols. Readout (if
7 required) is accomplished by extracting the Contents
8 of the appropriate Register 6116 to 6F16.
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
20xx, RTCA, Inc.

Appendix A
Page A - 76
Figure A-8a: Extended Squitter Aircraft Status

(Subtype 1: Emergency/Priority Status and Mode A Code)
Register 6116
1 MSB PURPOSE: To provide additional information on aircraft status.

2
3 FORMAT TYPE CODE = 28
4 Subtype shall be coded as follows:
5 LSB
6 MSB 0 = No information
7 SUBTYPE CODE = 1 1 = Emergency/Priority Status and Mode A Code
8 LSB 2 = TCAS RA Broadcast
9 MSB 3 to 7 = Reserved
10 EMERGENCY STATE
11 LSB Emergency state shall be coded as follows:
12 MSB
13 Value Meaning
14 0 No emergency
15 1 General emergency
16 2 Lifeguard/Medical
17 MODE A (4096) CODE 3 Minimum fuel
18 4 No communications
19 5 Unlawful interference
20 6 Downed aircraft
21 7 Reserved
22
23 Notes:
24 LSB 1) Message delivery is accomplished once per 0.8 seconds using
25 the Event-Driven protocol.
26
27 2) Termination of emergency state is detected by coding in the
28 surveillance status field of the Airborne Position Message.
29
30 3) Subtype 2 message broadcasts take priority over Subtype 1
31 message broadcasts.
32
33 4) Emergency State value 1 is set when Mode A code 7700 is
34 provided to the transponder.
35
37 provided to the transponder.
38
40 RESERVED provided to the transponder.
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
20xx, RTCA, Inc.

Appendix A
Page A - 77
Figure A-8b: Extended Squitter Aircraft Status

(Subtype 2: 1090ES TCAS RA Broadcast)
Register 6116
1 MSB PURPOSE: To report resolution advisories (RAs) generated by
2 TCAS equipment.
4 Subtype Coding:
5 LSB
6 MSB 0 = No information
7 Subtype CODE = 2 1 = Emergency/Priority Status
8 LSB 2 = TCAS RA Broadcast
9 MSB 3 to 7 = Reserved
10
11 TCAS RA Broadcast Coding:
12
13 The coding of bits 9 to 56 of this Message conforms to the
14 corresponding bits of Register 3016 as specified in Annex 10,
15 ACTIVE RESOLUTION ADVISORIES Volume IV, 4.3.8.4.2.2.
16
17 Notes:
18
19 1) Message delivery is accomplished once per 0.8 seconds
20 using the event-driven protocol.
21
22 LSB 2) RA Broadcast begins within 0.5 seconds after transponder
23 MSB notification of the initiation of an TCAS RA.
24 RACs RECORD
25 3) RA Broadcast is terminated 24 1 seconds after the RAT flag
26 LSB (Annex 10, Volume IV, 4.3.8.4.2.2.1.3) transitions from
27 RA TERMINATED ZERO (0) to ONE (1).
28 MULTIPLE THREAT ENCOUNTER
29 MSB THREAT TYPE INDICATOR 4) Subtype 2 message broadcasts take priority over subtype 1
30 LSB message broadcasts.
31 MSB
32
33
34
35
36
37
38
39
40
41
42
43 THREAT IDENTITY DATA
44
45
46
47
48
49
50
51
52
53
54
55
56 LSB
20xx, RTCA, Inc.

Appendix A
Page A - 78
Figure A-9a: Target State and Status Information

(Subtype = 0: Compatible with DO-260A, ADS-B Version Number=1)
Register 6216
1 PURPOSE: To provide aircraft state and status

2 information.
4
5
6 MSB SUBTYPE CODE = 0
7 LSB
8 MSB Vertical Data Available / Source Indicator
9 LSB (A.1.4.9.3)
10 Target Altitude Type (A.1.4.9.4)
11 Backward Compatibility Flag = 0
12 MSB Target Altitude Capability
13 LSB (A.1.4.9.5)
14 MSB Vertical Mode Indicator
15 LSB (A.1.4.9.6)
16 MSB
17
18
19
20 Target Altitude
21 (A.1.4.9.7)
22
23
24
25 LSB
26 MSB Horizontal Data Available / Source Indicator
27 LSB (A.1.4.9.8)
28 MSB
29
30
31
32 Target Heading / Track Angle
33 (A.1.4.9.9)
34
35
36 LSB
37 Target Heading / Track Indicator (A.1.4.9.10)
38 MSB Horizontal Mode Indicator
39 LSB (A.1.4.9.11)
40 MSB
41 Navigation Accuracy Category Position (NACP)
42 (A.1.4.9.12)
43 LSB
44 Navigation Integrity Category Baro (NICBARO) (A.1.4.9.13)
45 MSB Surveillance Integrity Level (SIL)
46 LSB (A.1.4.9.14)
47
48
49 Reserved
50
51
52 MSB Capability / Mode Codes
53 LSB (A.1.4.9.15)
54 MSB
55 Emergency / Priority Status
56 LSB (A.1.4.9.16)
20xx, RTCA, Inc.

Appendix A
Page A - 79
Figure A-9b: Target State and Status Information

(Subtype = 1: Compatible with DO-260B, ADS-B Version Number=2)
Register 6216
1 PURPOSE: To provide aircraft state and status

2 information.
4
5
6 MSB SUBTYPE CODE = 1
7 LSB
8 SIL SUPPLEMENT (0=Per Hour, 1=Per Sample)
9 SELECTED ALTITUDE TYPE (0=MCP/FCU, 1=FMS)
10 MSB = 32768 feet
11 MCP / FCU SELECTED ALTITUDE
12 (when Selected Altitude Type = 0)
13 FMS SELECTED ALTITUDE
14 (when Selected Altitude Type = 1)
15 Coding: 111 1111 1111 = 65472 feet
16 *** **** ****
17 000 0000 0010 = 32 feet
18 000 0000 0001 = 0 feet
19 000 0000 0000 = No data or Invalid
20 LSB = 32 feet
21 MSB = 204.8 millibars
22 BAROMETRIC PRESSURE SETTING (MINUS 800 millibars)
23 Range = [0, 408.0] Resolution = 0.8 millibars
24 Coding: 1 1111 1111 = 408.00 millibars
25 * **** ****
26 0 0000 0010 = 0.800 millibars
27 0 0000 0001 = 0.000 millibars
28 0 0000 0000 = No Data or Invalid
29 LSB = 0.8 millibars
30 STATUS (0=Invalid, 1=Valid)
31 Sign (0=Positive, 1=Negative)
32 MSB = 90.0 degrees
33
34 SELECTED HEADING
35 Range = [+/- 180] degrees, Resolution = 0.703125 degrees
36 (Typical Selected Heading Label = 101)
37
38
39 LSB = 0.703125 degrees (180/256)
40 MSB
41 NAVIGATION ACCURACY CATEGORY FOR POSITION (NACP)
42 (A.1.4.9.9)
43 LSB
44 NAVIGATION INTEGRITY CATEGORY FOR BARO (NICBARO)
45 MSB
SOURCE INTEGRITY LEVEL (SIL)
46 LSB
47 STATUS OF MCP / FCU MODE BITS (0 = Invalid, 1 = Valid)
48 AUTOPILOT ENGAGED (0 = Not Engaged, 1 = Engaged)
49 VNAV MODE ENGAGED (0 = Not Engaged, 1 = Engaged)
50 ALTITUDE HOLD MODE (0 = Not Engaged, 1 = Engaged)
51 Reserved for ADS-R Flag (see 2.2.18.4.6)
52 APPROACH MODE (0 = Not Engaged, 1 = Engaged)
53 TCAS OPERATIONAL (0 = Not Operational, 1 = Operational)
54 MSB
55 RESERVED
56 LSB
20xx, RTCA, Inc.

Appendix A
Page A - 80
Figure A-10: Aircraft Operational Status
Register 6516
1 MSB PURPOSE: To provide the capability class and current operational

2 mode of ATC-related applications and other operational information..
4
5 LSB Subtype Coding:
6 MSB MSB
7 SUBTYPE CODE = 0 SUBTYPE CODE = 1 0 = Airborne Status Message
8 LSB LSB 1 = Surface Status Message
9 MSB MSB 2 7 = Reserved
10
11
12
13
14 AIRBORNE SURFACE
15 CAPABILITY CLASS (CC) CAPABILITY CLASS (CC)
16 CODES CODES
17 (A.1.4.10.3) (A.1.4.10.3)
18
19
20 LSB
21 MSB
22 LENGTH/WIDTH CODES
23 (A.1.4.10.11)
24 LSB LSB
25 MSB MSB
26
27
28
29
30 AIRBORNE SURFACE
31 OPERATIONAL OPERATIONAL
32 MODE (OM) CODES MODE (OM) CODES
33 (A.1.4.10.4) (A.1.4.10.4)
34
35
36
37
38
39
40 LSB LSB
41 MSB
42 VERSION NUMBER (A.1.4.10.5)
43 LSB
44 NIC SUPPLEMENT-A (A.1.4.10.6)
45 MSB
46 NAVIGATIONAL ACCURACY CATEGORY POSITION
47 (NACP) (A.1.4.10.7)
48 LSB
49 MSB GVA RESERVED
50 LSB (A.1.4.10.8)
51 MSB SOURCE INTEGRITY LEVEL (SIL)
52 LSB (A.1.4.10.9)
53 NICBARO (A.1.4.10.10) TRK/HDG (A.1.4.10.12)
54 HRD (A.1.4.10.13)
55 SIL SUPPLEMENT (A.1.4.10.14)
56 RESERVED
20xx, RTCA, Inc.

Appendix A
Page A - 81
A.2 Traffic Information Services Broadcast (TIS-B) Formats and Coding
A.2.1 Introduction
Notes:
1. This section of Appendix A defines the formats and coding for a Traffic Information
Service Broadcast (TIS-B) based on the same 112-bit 1090 MHz signal transmission
that is used for ADS-B on 1090 MHz.
2. TIS-B complements the operation of ADS-B by providing ground-to-air broadcast of

surveillance data on aircraft that are not equipped for 1090 MHz ADS-B. The basis
for this ground surveillance data may be an ATC Mode S radar, a surface or
approach multi-lateration system or a multi-sensor data processing system. The TIS-
B ground-to-air transmissions use the same signal formats as 1090 MHz ADS-B and
can therefore be accepted by a 1090 MHz ADS-B receiver.
3. TIS-B service is the means for providing a complete surveillance picture to 1090
MHz ADS-B users during a transition period. After transition, it also provides a
means to cope with a user that has lost its 1090 MHz ADS-B capability, or is
broadcasting incorrect information.
A.2.2 TIS-B Format Definition

TIS-B information is broadcast using the 112-bit Mode S DF=18 format as shown below
in Figure A-11.
TIS-B Format Definition
Bit # 1 ----- 5 6 --- 8 9 ----- 32 33 --------------------------- 88 89 ---- 112
DF=1 DF CF AA ME PI
8 [5] [3] [24] [56] [24]
Field 10010
Names
MSB MSB MSB MSB MSB
LSB LSB LSB LSB LSB
Figure A-11: TIS-B Format Definition
A.2.3 Control Field Allocation

The content of the DF=18 transmission is defined by the value of the control field, as
specified in Table A-29.
20xx, RTCA, Inc.

Appendix A
Page A - 82
Table A-29: CF Field Code Definitions in DF=18 ADS-B and TIS-B Messages
CF ICAO/Mode A
Meaning
Value Flag (IMF)
ADS-B Message from a non-transponder device,
0 N/A
Reserved for ADS-B Message in which the AA field holds
1 N/A anonymous address or ground vehicle address or fixed
obstruction address
Fine TIS-B Message,
0
2 Fine TIS-B Message,
1 AA field contains the 12-bit Mode A code followed by a 12-bit
track file number
Coarse TIS-B Airborne Position and Velocity Message,
0
3 Coarse TIS-B Airborne Position and Velocity Message,
1 AA field contains the 12-bit Mode A code followed by a 12-bit
track file number.
TIS-B and ADS-R Management Message
4 N/A
AA field contains TIS-B/ADS-R management information.
Fine TIS-B Message
0
5 AA field contains a non-ICAO 24-bit address
1 Reserved
Rebroadcast of ADS-B Message from an alternate data link
0
6 Rebroadcast of ADS-B Message from an alternate data link
1 AA field holds anonymous address or ground vehicle address
or fixed obstruction address
7 N/A Reserved
A.2.4 TIS-B Surveillance Message Definition
A.2.4.1 TIS-B Fine Airborne Position Message

The TIS-B fine airborne position ME field will be formatted as specified in Figure A-12.
A.2.4.1.1 ICAO/Mode A Flag (IMF)

This one-bit field (bit 8) will indicate the type of identity associated with the aircraft data
reported in the TIS-B message. IMF equal to ZERO (0) will indicate that the TIS-B data
is identified by an ICAO 24-bit address. IMF equal to ONE (1) will indicate that the
TIS-B data is identified by a Mode A code. A TIS-B report on a primary radar target
will indicate a Mode A code of all ZEROs.
20xx, RTCA, Inc.

Appendix A
Page A - 83
Notes:
1. The AA field is coded differently for 24-bit addresses and Mode A codes as specified
in Table A-22.
2. A target with a ZERO Mode A code and a reported altitude is an SSR target.
A.2.4.1.2 Pressure Altitude

This 12-bit field will provide the aircraft pressure altitude. This field will contain
barometric altitude encoded in 25 or 100-foot increments (as indicated by the Q Bit). All
zeroes in this field will indicate that there is no altitude data.

This field will be set as specified in A.1.4.2.1.
A.2.4.1.4 Latitude/Longitude
The Latitude/Longitude fields in the TIS-B fine Airborne Position Message will be set as
specified in A.1.4.2.3.
A.2.4.2 TIS-B Surface Position Message

The TIS-B surface position ME field will be formatted as specified in Figure A-13.
A.2.4.2.1 Movement
A.2.4.2.1.1 Ground Track (True)
A.2.4.2.1.1.1 Ground Track Status

This field will be set as specified in A.1.4.3.2.1.
A.2.4.2.1.1.2 Ground Track Angle

This field will be set as specified in A.1.4.3.2.2.
A.2.4.2.1.2 ICAO/Mode A Flag (IMF)

This one-bit field (bit 21) will indicate the type of identity associated with the aircraft
data reported in the TIS-B message. Coding is specified in A.2.4.1.1.
A.2.4.2.1.3 Compact Position Reporting (CPR) Format (F)

20xx, RTCA, Inc.

Appendix A
Page A - 84
A.2.4.2.1.4 Latitude/Longitude
The Latitude/Longitude fields in the TIS-B fine Surface Position Message will be set as
specified in A.1.4.3.5.
A.2.4.3 Identification and Category Message

The TIS-B identification and category ME field will be formatted as specified in Figure
A-14. This message will only be used for aircraft identified with an ICAO 24-bit
address.
A.2.4.3.1 Aircraft Identification Coding

A.2.4.4 Velocity Message

The TIS-B Velocity ME field will be formatted as specified in the Figure A-15 for
Subtypes 1 and 2, and in Figure A-16 for Subtypes 3 and 4.
A.2.4.4.1 Subtype Field

Subtypes 1 through 4 will be used for the TIS-B Velocity Message. Subtype 1 will be
used for velocities over ground under 1000 knots and Subtype 2 will be used for aircraft
capable of supersonic flight when the velocity over ground might exceed 1022 knots.
The supersonic version of the velocity coding will be used if either the East-West OR
North-South velocities exceed 1022 knots. A switch to the normal velocity coding will
be made if both the East-West AND North-South velocities drop below 1000 knots.
Subtypes 3 and 4 will be used when Airspeed and Heading are substituted for velocity
over ground. Subtype 3 will be used at subsonic airspeeds, while Subtype 4 will be used
for aircraft capable of supersonic flight when the Airspeed might exceed 1022 knots.
The supersonic version of the Airspeed coding will be used if the Airspeed exceeds 1022
knots. A switch to the normal Airspeed coding will be made if the Airspeed drops below
1000 knots.

reported in the TIS-B message. Coding is specified in A.2.4.1.1.
20xx, RTCA, Inc.

Appendix A
Page A - 85
A.2.4.5 Coarse Airborne Position Message
The TIS-B coarse airborne position ME field will be formatted as specified in Figure A-
17.
Notes:
1. This message is used if the surveillance source for TIS-B is not of high enough
quality to justify the use of the fine formats. An example of such a source is a
scanning beam Mode S interrogator.
2. Additional details are specified in the following paragraphs.

reported in the TIS-B message. Coding is specified in A.2.4.1.1.
A.2.4.5.2 Service Volume ID (SVID)

The 4-bit SVID field will identify the TIS-B site that delivered the surveillance data.
Note: In the case where TIS-B messages are being received from more than one TIS-B
ground stations, the SVID can be used to select coarse messages from a single
source. This will prevent the TIS-B track from wandering due to the different
error biases associated with different sources.
A.2.4.5.3 Pressure Altitude

This 12-bit field will provide the aircraft pressure altitude. This field will contain
barometric altitude encoded in 25 or 100-foot increments (as indicated by the Q Bit).
A.2.4.5.4 Ground Track Status

This one bit (ME bit 20) field will define the validity of the ground track value. Coding
for this field will be as follows: 0=not valid and 1= valid.
A.2.4.5.5 Ground Track Angle

This 5-bit (ME bits 21-25) field will define the direction (in degrees clockwise from true
north) of aircraft motion. The ground track will be encoded as an unsigned angular
weighted binary numeral, with an MSB of 180 degrees and an LSB of 360/32 degrees,
with ZERO (0) indicating true north. The data in the field will be rounded to the nearest
multiple of 360/32 degrees.
A.2.4.5.6 Ground Speed

This 6-bit (ME bits 26-31) field will define the aircraft speed over the ground. Coding of
this field will be as specified in 2.2.17.3.5.6.
20xx, RTCA, Inc.

Appendix A
Page A - 86
A.2.4.5.7 Latitude/Longitude
The Latitude/Longitude fields in the TIS-B Coarse Airborne Position Message will be set
as specified in A.1.4.2.3, except that the 12-bit form of CPR coding will be used.
A.2.5 TIS-B and ADS-R Management Messages

The TIS-B/ADS-R Management Messages use Extended Squitter format DF=18 and
CF=4 to provide information related to the provision of the TIS-B and/or ADS-R Service
Volume in the specific airspace being serviced by the local ground broadcast site(s).
The TIS-B/ADS-R Management Message is used to provide a specific announcement of

the Service Volume and the service availability in local airspace where the TIS-B and/or
ADS-R service is being supported by the ground infrastructure.
A.2.6 Formats for 1090 MHz TIS-B Messages
20xx, RTCA, Inc.

Appendix A
Page A - 87
Figure A-12: TIS-B Fine Airborne Position Message
1 Purpose: To provide airborne position information for

2 aircraft that are not equipped with 1090 MHz ADS-B
3 FORMAT TYPE CODE service is based on high quality surveillance data.
4 (See A.1.4.1 and Note 1)
5
6 MSB SURVEILLANCE STATUS Surveillance Status coding:
7 LSB 0 = no condition information
8 IMF (A.2.4.1.1) 1 = permanent alert (emergency condition)
9 2 = temporary alert (change in Mode A identity code other than
10 emergency condition)
11 3 = SPI condition
12
13 PRESURE ALTITUDE
14 Codes 1 and 2 take precedence over code 3.
15
16 The altitude code (AC) as specified in 2.2.13.1.2 of
17 DO-181D, but with the M-bit removed.
18
19
20
21 RESERVED
22 CPR FORMAT (F) (A.1.4.2.1)
23 MSB
24
25
26
27
28
30 CPR Airborne Format
31 (A.1.7.1 to A.1.7.7)
32
33
34
35
36
37
38
39 LSB
40 MSB
41
42
43
44
45
47 CPR Airborne Format
48 (A.1.7.1 to A.1.7.7)
49
50
51
52
53
54
55
56 LSB
20xx, RTCA, Inc.

Appendix A
Page A - 88
Figure A-13: TIS-B Fine Surface Position Message
1 Purpose: To provide surface position information for

2 aircraft that are not equipped with 1090 MHz ADS-B.
3 FORMAT TYPE CODE
4 (A.1.4.1)
5
6
7
8
9 MOVEMENT
10 (A.1.4.3.1)
11
12
13 STATUS for Heading/Ground Track (1=valid, 0=not valid)
14 MSB
15
16 HEADING / GROUND TRACK (7 bits)
17 (Referenced to true north)
19
20 LSB
21 IMF (A.2.4.2.1.2)
22 CPR FORMAT (F) (A.1.4.2.1)
23 MSB
24
25
26
27
28
29
31 CPR Surface Format
32 (A.1.7.1 to A.1.7.7)
33
34
35
36
37
38
39 LSB
40 MSB
41
42
43
44
45
46
48 CPR Surface Format
49 (A.1.7.1 to A.1.7.7)
50
51
52
53
54
55
56 LSB
20xx, RTCA, Inc.

Appendix A
Page A - 89
Figure A-14: TIS-B Identification and Category Message
1 Purpose: To provide aircraft identification and category for

2 aircraft that are not equipped with 1090 MHz ADS-B.
3 FORMAT TYPE CODE
4 (A.1.4.1)
5 TYPE Coding:
6 1 = Aircraft identification, Category Set D
7 AIRCRAFT EMITTER CATEGORY 2 = Aircraft identification, Category Set C
8 3 = Aircraft identification, Category Set B
9 MSB 4 = Aircraft identification, Category Set A
10
11 CHARACTER 1
12 ADS-B Aircraft Emitter Category coding:
13
14 LSB Set A
15 MSB 0 = No ADS-B Emitter Category Information
16 1 = Light (< 15500 lbs)
17 CHARACTER 2 2 = Small (15500 to 75000 lbs)
18 3 = Large (75000 to 300000 lbs)
19 4 = High Vortex Large (aircraft such as B-757)
20 LSB 5 = Heavy (> 300000 lbs)
21 MSB 6 = High Performance (> 5g acceleration and 400 kts)
22 7 = Rotorcraft
23 CHARACTER 3
24
25 Set B
26 LSB 0 = No ADS-B Emitter Category Information
27 MSB 1 = Glider / sailplane
28 2 = Lighter-than-air
29 CHARACTER 4 3 = Parachutist / Skydiver
30 4 = Ultralight / hang-glider / paraglider
31 5 = Reserved
32 LSB 6 = Unmanned Aerial Vehicle
33 MSB 7 = Space / Trans-atmospheric vehicle
34
35 CHARACTER 5
36 Set C
38 LSB 1 = Surface Vehicle Emergency Vehicle
39 MSB 2 = Surface Vehicle Service Vehicle
40 3 = Point Obstacle (includes tethered balloons)
41 CHARACTER 6 4 = Cluster Obstacle
42 5 = Line Obstacle
43 6 = Reserved
44 LSB 7 = Reserved
45 MSB
46
47 CHARACTER 7 Set D
48 (Reserved)
49
50 LSB Aircraft Identification coding:
51 MSB Character coding as specified in A.1.4.4.
52
53 CHARACTER 8
54
55
56 LSB
20xx, RTCA, Inc.

Appendix A
Page A - 90
Figure A-15: TIS-B Velocity Messages

1 MSB 1 Purpose: To provide velocity information for aircraft that

2 0 are not equipped with 1090 MHz ADS-B when the TIS-B
3 FORMAT TYPE CODE = 19 0 service is based on high quality surveillance data.
4 1
5 LSB 1 Subtype Coding:
7 0 1 Code Velocity Type
8 1 0 1 Ground Normal
9 IMF (A.2.4.4.2) 2 Speed Supersonic
10 MSB
11 NAVIGATION ACCURACY CATEGORY FOR POSITION
12 (NACP) (A.1.4.10.7) Note: The Vertical Rate and Geometric Height
13 LSB Difference From Barometric fields for surface
14 DIRECTION BIT for E-W Velocity (0=East, 1=West) aircraft do not need to be processed by TIS-B
15 EAST-WEST VELOCITY (10 bits) receivers.
19 1 0 kts 1 0 kts
20 2 1 kt 2 4 kts
3 2 kts 3 8 kts
22 --- --- --- ---
23 1022 1021 kts 1022 4084 kts
24 1023 >1021.5 kts 1023 > 4086 kts
25 DIRECTION BIT for N-S Velocity (0=North, 1=South)
26 NORTH SOUTH VELOCITY (10 bits)
30 1 0 kts 1 0 kts
31 2 1 kt 2 4 kts
32 3 2 kts 3 8 kts
33 --- --- --- ---
34 1022 1021 kts 1022 4084 kts
35 1023 > 1021.5 kts 1023 > 4086 kts
36 GEO FLAG BIT (1 bit) (GEO = 0) GEO FLAG BIT (1 bit) (GEO = 1)
37 SIGN BIT FOR VERTICAL RATE (0=Up, 1=Down) SIGN BIT FOR VERTICAL RATE (0=Up, 1=Down)
38 VERTICAL RATE (9 bits) VERTICAL RATE (9 bits)
39 All zeros no vertical rate info, LSB = 64 feet/min All zeros no vertical rate info, LSB = 64 feet/min
40 Value Vertical Rate Value Vertical Rate
41 1 0 ft/min 1 0 ft/min
42 2 64 ft/min 2 64 ft/min
43 --- --- --- ---
44 510 32576 ft/min 510 32576 ft/min
45 511 > 32608 ft/min 511 > 32608 ft/min
46
47 NIC SUPPLEMENT (A.1.4.10.6) NIC SUPPLEMENT (A.1.4.10.6)
48 RESERVED (1 bit)
49 NAVIGATION ACCURACY CATEGORY FOR VELOCITY DIFFERENCE SIGN BIT (0 = Above Baro, 1 = Below Baro Alt)
(NACV) (A.1.4.5.5) GEOMETRIC HEIGHT DIFFERENCE FROM BARO ALT.
50
51 SURVEILLANCE INTEGRITY LEVEL (SIL) Value Difference
52 (A.1.4.10.9) 1 0 feet
53 2 25 feet
54 RESERVED (4 bits) --- ---
55 126 3125 feet
56 127 > 3137.5 feet
20xx, RTCA, Inc.

Appendix A
Page A - 91
Figure A-16: TIS-B Velocity Messages

(Subtypes 3 and 4: Air Referenced Velocity)
1 MSB 1 Purpose: To provide velocity information for aircraft that

2 0 are not equipped with 1090 MHz ADS-B when the TIS-B
3 FORMAT TYPE CODE = 19 0 service is based on high quality surveillance data.
4 1
5 LSB 1
7 1 0
8 1 0
9 IMF (A.2.4.4.2) Subtype Coding:
10
11 Code Velocity Type
NAVIGATION ACCURACY CATEGORY FOR POSITION
12 3 Airspeed, Normal
(NACP) (A.1.4.10.7)
14 HEADING STATUS BIT (1 = Available, 0 = Not Available)
15 MSB
16 Note: The Vertical Rate and Geometric Height
17 Difference From Barometric fields for surface
18 HEADING (10 bits) aircraft do not need to be processed by TIS-B
19 (A.1.4.5.6) receivers
21
22
23
24 LSB
25 AIRSPEED TYPE (0 = IAS, 1 = TAS)
26 AIRSPEED (10 bits)
27 NORMAL: LSB = 1 knot SUPERSONIC: LSB = 4 knots
30 1 0 kts 1 0 kts
31 2 1 kt 2 4 kts
32 3 2 kts 3 8 kts
33 --- --- --- ---
34 1022 1021 kts 1022 4084 kts
35 1023 > 1021.5 kts 1023 > 4086 kts
36 GEO FLAG Bit (GEO = 0) GEO FLAG Bit (GEO =1)
37 SIGN BIT FOR VERTICAL RATE (0=Up, 1=Down) SIGN BIT FOR VERTICAL RATE (0=Up, 1=Down)
38 VERTICAL RATE (9 bits) VERTICAL RATE (9 bits)
39 All zeros no vertical rate information All zeros no vertical rate information
40 LSB = 64 feet/min LSB = 64 feet/min
41 Value Vertical Rate Value Vertical Rate
42 1 0 ft/min 1 0 ft/min
43 2 64 ft/min 2 64 ft/min
44 --- --- --- ---
45 510 32576 ft/min 510 32576 ft/min
46 511 > 32608 ft/min 511 > 32608 ft/min
47 NIC SUPPLEMENT (A.1.4.10.6) NIC SUPPLEMENT (A.1.4.10.6)
48 RESERVED (1 bit)
49 NAVIGATION ACCURACY CATEGORY FOR VELOCITY DIFFERENCE SIGN BIT (0 = Above Baro, 1 = Below Baro Alt)
(NACV) (A.1.4.5.5) GEOMETRIC HEIGHT DIFFERENCE FROM BARO ALT
50
51 SURVEILLANCE INTEGRITY LEVEL Value Vertical Rate
52 (A.1.4.10.9) 1 0 ft
53 RESERVED 2 25 ft
54 RESERVED --- ---
55 TRUE / MAGNETIC HEADING (0 = True, 1 = Magnetic) 126 3125 ft
56 RESERVED 127 > 3137.5 ft
20xx, RTCA, Inc.

Appendix A
Page A - 92
Figure A-17: TIS-B Coarse Airborne Position Message
1 IMF (A.2.4.5.1) Purpose: To provide airborne position information for

2 aircraft that are not equipped with 1090 MHz ADS-B
SURVEILLANCE STATUS
3 when TIS-B service is based on moderate quality
4 MSB surveillance data.
5 SERVICE VOLUME ID (SVID)
6
7 LSB
8 MSB
9
10
11
12
13 PRESSURE ALTITUDE
14
15
16
17
18
19 LSB
20 GROUND TRACK STATUS (1 = Valid, 0 = Invalid)
21
22
23 GROUND TRACK ANGLE
24 (A.2.4.5.5)
25
26
27
28 GROUND SPEED
29 (A.2.4.5.6)
30
31
32 CPR FORMAT (F) (0 = Even, 1 = Odd)
33 MSB
34
35
36
37
39 (A.2.4.5.7)
40
41
42
43
44 LSB
45 MSB
46
47
48
49
51 (A.2.4.5.7)
52
53
54
55
56 LSB
20xx, RTCA, Inc.

Appendix A
Page A - 93
A.3 ADS-B Rebroadcast Service Formats and Coding
A.3.1 Introduction
The TIS-B MASPS, RTCA/DO-286B defines an ADS-B Rebroadcast Service, as a
Fundamental TIS-B Service, that may be provided. The Messages of the ADS-B
Rebroadcast Service are not transmitted by aircraft, but by ADS-B ground stations.
Notes:
1. This section of Appendix A defines the formats and coding for an ADS-B Rebroadcast
Service (see the TIS-B MASPS, RTCA/DO-286B, 1.4.1) based on the same 112-bit
1090 MHz Extended Squitter signal transmission that is used for DF=17 ADS-B
Messages on 1090 MHz.
2. The ADS-B Rebroadcast Service complements the operation of ADS-B and the
Fundamental TIS-B Service (see the TIS-B MASPS, RTCA/DO-286B, 1.4.1) by
providing ground-to-air rebroadcast of ADS-B data about aircraft that are not
equipped for 1090 MHz Extended Squitter ADS-B, but are equipped with an alternate
form of ADS-B (e.g., Universal Access Transceiver (UAT)). The basis for the ADS-B
Rebroadcast transmission is the ADS-B Report received at the ground station using a
receiver compatible with the alternate ADS-B data link.
3. The ADS-B Rebroadcast ground-to-air transmissions use the same signal formats as
the DF=17 1090 MHz Extended Squitter ADS-B and can therefore be accepted by a
1090 MHz ADS-B Receiving Subsystem, with the exceptions identified in the
following sections.
A.3.2 ADS-B Rebroadcast Format Definition

ADS-B Rebroadcast information is transmitted using the 112-bit Mode S DF=18 format
specified in Figure A-11.
A.3.3 Control Field Allocation

The content of the DF=18 transmission is defined by the value of the Control Field (CF).
As specified in Table A-29, ADS-B Rebroadcasts (i.e., ADS-R) transmissions shall use
CF=6 and ADS-R Management information transmissions (i.e., defining ADS-R Service
Volume and service availability) shall use CF=4.
A.3.4 ADS-B Rebroadcast Surveillance Message Definitions

accomplished by utilizing the same ADS-B Message formats defined in Figure A-1
through Figure A-10, with the exception of the need to transmit an indication to the 1090
MHz Receiving Subsystem as to the type of identity associated with the aircraft data
being reported in the ADS-B Rebroadcast Message. This identification is performed
using the ICAO/Mode A Flag (IMF), which was previously discussed in A.2.4.1.1 for
the TIS-B transmissions.
20xx, RTCA, Inc.

Appendix A
Page A - 94
The insertion of this one bit into the ADS-B Messages identified below allows the ADS-
B Receiving Subsystem to interpret the Address Field (AF) in the following manner:
Address
IMF = 1 indicates that the ADS-B Rebroadcast data is identified by an anonymous 24-
bit Address
A.3.4.1 Rebroadcast Airborne Position Message

The ME Field of the Rebroadcast Airborne Position Message will be formatted as
specified in section A.1.4.2 and Figure A-1, except that ME bit 8 is redefined to be the
A.3.4.2 Rebroadcast Surface Position Message

The ME Field of the Rebroadcast Surface Position Message will be formatted as specified
in section A.1.4.3 and Figure A-2, except that ME bit 21 is redefined to be the
A.3.4.3 Rebroadcast Aircraft Identification and Category Message

The ME Field of the Rebroadcast Aircraft Identification and Category Message will be
formatted exactly as specified in section A.1.4.4 and Figure A-4.
Note: Any Rebroadcast Aircraft Identification and Category Message does not contain
the IMF bit since aircraft using an anonymous 24-bit address will not provide
identity and category information.
A.3.4.4 Rebroadcast Airborne Velocity Message

The ME Field of the Rebroadcast Airborne Velocity Messages will be formatted as
specified in section A.1.4.5.1 and Figure A-5 for Subtype 1 & 2 Messages, and in
section A.1.4.5.2 and Figure A-6 for Subtype 3 & 4 Messages, except that ME bit 9 is
redefined to be the ICAO/Mode A Flag (IMF).
A.3.4.5 Rebroadcast Extended Squitter Aircraft Status Message

The ME Field of the Rebroadcast Extended Squitter Aircraft Status Message will be
formatted as specified in section A.1.4.8 and Figure A-8, except that ME bit 56 is
redefined to be the ICAO/Mode A Flag (IMF).
20xx, RTCA, Inc.

Appendix A
Page A - 95
A.3.4.6 Rebroadcast Target State and Status Message
The ME Field of the Rebroadcast Target State and Status Message will be formatted as
specified in section A.1.4.9 and Figure A-9, except that ME bit 51 is redefined to be the
A.3.4.7 Rebroadcast Aircraft Operational Status Message

The ME Field of the Rebroadcast Aircraft Operational Status Message will be formatted
as specified in section A.1.4.10 and Figure A-10, except that ME bit 56 is redefined to
be the ICAO/Mode A Flag (IMF).
20xx, RTCA, Inc.

Appendix A
Page A - 96
20xx, RTCA, Inc.

APPENDIX B
ACRONYMS & DEFINITION OF TERMS


Appendix B
Page B - 3
B Acronyms and Definition of Terms
B.1 Acronyms
1090ES 1090 MHz Extended Squitter
AC - Advisory Circular
ACARS - Aircraft Communications, Addressing and Reporting System
ACAS Airborne Collision Avoidance System
ADS - Automatic Dependent Surveillance
ADS-B - Automatic Dependent Surveillance-Broadcast
ADS-R ADS-B Rebroadcast Service
AGC Automatic Gain Control
AGL - Above Ground Level
AIP - Aviation Information Publications
A/V - Aircraft/Vehicle
ARINC - ARINC Incorporated (formally Aeronautical Radio Incorporated)
ASIC - Application Specific Integrated Circuit
ATCRBS - Air Traffic Control Radar Beacon System
ATC - Air Traffic Control
ATM - Air Traffic Management
ATS - Air Traffic Services
ATIS - Automatic Terminal Information Service
AWB Angular Weighted Binary
BCD - Binary Coded Decimal
BDS - Comm-B Data Selector
BER - Bit Error Rate
BNR - Binary Numbers
20xx, RTCA, Inc.

Appendix B
Page B - 4
BW - Bandwidth
C/A - Coarse Acquisition
CC - Clock Correction
CDI - Course Deviation Indicator
CF - Course-to-Fix
CPA - Closest Point of Approach
CNS - Communications, Navigation and Surveillance
CDTI - Cockpit Display of Traffic Information
CRC - Cyclic Redundancy Check
CTAS - Center TRACON Automation System
CW - Continuous Wave
DME - Distance Measuring Equipment
DMTL - Dynamic Minimum Trigger Level
DOD - U.S. Department of Defense
DOP - Dilution Of Precision
DP - Datum Point
dps - Degrees Per Second
DR - Dead Reckoning
DRWP - Departure End of Runway Waypoint (associated with a departure procedure)
EC - Ephemeris Correction
ECEF - Earth Centered Earth Fixed
EFIS - Electronic Flight Instruments System
EL - Glidepath Angle (approach path elevation angle)
20xx, RTCA, Inc.

Appendix B
Page B - 5
ELT - Emergency Locating Transmitter
EPU - Estimated Position Uncertainty
ERP - Effective Radiated Power
ETA - Estimated Time of Arrival
EUROCAE - European Organization for Civil Aviation Equipment
FAA - Federal Aviation Administration
FAF - Final Approach Fix
FAR - Federal Aviation Regulation
FAS - Final Approach Segment
FAWP - Final Approach Waypoint
FD - Fault Detection
FDE - Fault Detection and Exclusion
FIS-B - Flight Information Services-Broadcast
FTE - Flight Technical Error
FMS - Flight Management System
fpm - Feet Per Minute
FRUIT False Replies Unsynchronized In Time
FSD - Full Scale Deflection
FSS - Flight Service Station
FTE - Flight Technical Error
GFM General Formatter/Manager
GICB - Ground Initiated Comm-B
GL - Ground Level
GNSS - Global Navigation Satellite System
20xx, RTCA, Inc.

Appendix B
Page B - 6
GPS - Global Positioning System
{HEX} Hexadecimal
HF - High Frequency
HIRF - High Intensity Radiation Fields
Hz - Hertz
IAC - Instantaneous Airborne Count
IAS - Indicated Airspeed
ICAO - International Civil Aviation Organization
IFR - Instrument Flight Rules
ILS - Instrument Landing System
IMC - Instrument Meteorological Conditions
INS - Inertial Navigation System
I/O - Input and/or Output
ITC - In-Trail Climb
ITD - In-Trail Decent
ITU - International Telecommunication Union
JAA - Joint Aviation Authorities
JAR - Joint Aviation Requirements
L1 - 1575.42 MHz (a navigation frequency associated with GPS)
LAAS - Local Area Augmentation System
LADGPS - Landing Area Differential GPS
lb. - pounds
20xx, RTCA, Inc.

Appendix B
Page B - 7
LORAN - Long Range Navigation
LSB - Least Significant Bit
LSR - Least Squares Residual
MASPS - Minimum Aviation System Performance Standards
MFD - Multi-Functional Display
MHz - Megahertz
MOPS - Minimum Operational Performance Standards
MTBF - Mean Time Between Failure
MS - Mode Status
MSL - Minimum Signal Level
MTL - Minimum Trigger Level
MTTR - Mean-Time-To-Restore
MTR - Military Training Route
NACBARO Navigation Accuracy Category - Barometric
NACP Navigation Accuracy Category Position
NACV Navigation Accuracy Category Velocity
NAD-83 - North American Datum 1983
NAS - U.S. National Airspace System
NAV - Navigation
NAVAID - Navigation Aid
NIC Navigation Integrity Category
NICBARO Navigation Integrity Category Barometric
NM - Nautical Mile
NOTAM - Notice to Airmen
20xx, RTCA, Inc.

Appendix B
Page B - 8
NTD Non-Mode S Transponder Device
NUCP - Navigation Uncertainty Category - Position
NUCR - Navigation Uncertainty Category - Velocity
OBS - Omni Bearing Selector
OC - On Condition
PIREP - Pilot Report
PPM - Pulse Position Modulation
PRC - Pseudo range Correction
PRM - Precision Runway Monitoring
Pr - Probability of Receipt
PSR - Primary Surveillance Radar
PUC - Position Uncertainty Category
RA - Resolution Advisory
RAIM - Receiver Autonomous Integrity Monitoring
RC Radius of Containment
RCP - Required Communication Performance
RF - Radio Frequency
RMP - Required Monitoring Performance
rms - Root Mean Square
RNP - Required Navigation Performance
RSP - Required System Performance
rss - Root-Sum-Square
RVR - Runway Visual Range
20xx, RTCA, Inc.

Appendix B
Page B - 9
RVSM - Reduced Vertical Separation Minimum
SA or S/A - Selective Availability
SAE - Standard Aerospace Equipment
SAR - Search And Rescue
SARPS - Standards and Recommended Practices
SID - Standard Instrument Departure
SIL Surveillance Integrity Level
SNR - Signal-to-Noise Ratio
sps - symbols per second
SPS - Standard Positioning Service
SSR - Secondary Surveillance Radar
STAR - Standard Terminal Arrival Routes
SUA - Special Use Airspace
SV - State Vector
TA - Traffic Advisory
TAS - True Airspeed
TCAS - Traffic Alert and Collision Avoidance System
TCP - Trajectory Change Point
TERPS - Terminal Instrument Procedures
TIS - Traffic Information Service
TIS-B - Traffic Information Service-Broadcast
TMA - Terminal Maneuvering Area
TRS Transmission Rate Subfield
TSD - Traffic Situation Display (see also CDTI)
20xx, RTCA, Inc.

Appendix B
Page B - 10
TSE - Total System Error
TSO - Technical Standards Order
TTG - Time to Go
U.S. - United States
UTC - Coordinated Universal Time
VFR - Visual Flight Rules
VMC - Visual Meteorological Conditions
VNAV - Vertical Navigation
VUL - Vertical Uncertainty Level
VHF - Very High Frequency
VNAV - Vertical Navigation
VOR - VHF Omnidirectional Range
VUC - Velocity Uncertainty Category
WAAS - Wide Area Augmentation System
WGS-84 - World Geodetic System 1984
Xmt - Transmit
B.2 Definition of Terms

Accuracy - A measure of the difference between the A/V position reported in the ADS-
B message field as compared to the true position. Accuracy is usually defined in
statistical terms of either 1) a mean (bias) and a variation about the mean as defined by
the standard deviation (sigma) or a root mean square (rms) value from the mean. The
values given in this document are in terms of the two-sigma variation from an assumed
zero mean error.
20xx, RTCA, Inc.

Appendix B
Page B - 11
Acquisition Squitter A short message (format DF=11) that Mode S Transponders

transmit automatically, without needing to be interrogated by a radar, to announce the
own-ship aircrafts presence to nearby TCAS-equipped aircraft. (Also see Extended
Squitter.)
Active Waypoint - A waypoint to or from which navigational guidance is being

provided. For a parallel offset, the active waypoint may or may not be at the same
geographical position as the parent waypoint. When not in the parallel offset mode
(operating on the parent route), the active and parent waypoints are at the same
geographical position.
ADS-B (Automatic Dependent Surveillance Broadcast) A system for airborne or

surface aircraft, or other surface vehicles operating within the airport surface movement
area, that periodically transmits a State Vector and other information.
ADS-B Broadcast and Receive Equipment - Equipment that can transmit and receive
ADS-B messages. Defined as Class A equipment.
ADS-B Broadcast Only Equipment - Equipment that can transmit but not receive ADS-
B messages. Includes transponder based equipment that is capable of receiving 1030
MHz SSR interrogations. Defined as Class B equipment.
ADS-B Message - A modulated packet of formatted data which conveys information

used in the development of ADS-B reports.
ADS-B Only Transmitter - An ADS-B transmitter that is not part of a Mode S

transponder.
ADS-B Rebroadcast Service This is one of the Services provided by the TIS-B system
(see the TIS-B MASPS, RTCA/DO-286A, 1.4.2). The ADS-B Rebroadcast Service is a
TIS-B Service in which ground stations Rebroadcast on one data link (e.g., 1090 MHz
Extended Squitter as described in these MOPS) ADS-B Messages that were originally
transmitted by an aircraft or vehicle on another data link (e.g., the Universal Access
Transceiver, UAT).
ADS-B Receiver or 1090 MHz Receiver - An ADS-B receiver that is not a TCAS 1090
MHz receiver.
ADS-B Report - Specific Information provided by the ADS-B user participant subsystem
to external applications. Reports contain identification, state vector, and status/intent
information. Elements of the ADS-B Report that are used and the frequency with which
they must be updated will vary by application. The portions of an ADS-B Report that are
provided will vary by the capabilities of the transmitting participant.
ADS-B Subsystem - The set of avionics or equipment that performs ADS-B

functionality in an aircraft or for ground-based, non-aircraft, participants.
ADS-B System - A collection of ADS-B subsystems wherein ADS-B messages are

broadcast and received by appropriately equipped participant subsystems. Capabilities of
participant subsystems will vary based upon class of equipage.
20xx, RTCA, Inc.

Appendix B
Page B - 12
Advisory - An annunciation that is generated when crew awareness is required and

subsequent crew action may be required; the associated color is unique but not red or
amber/yellow. (Source: Advisory Circular AC 25 - 11).
Aircraft Address - The term address is used to indicate the information field in an
ADS-B message that identifies the ADS-B unit that issued the message. The address
provides a continent means by which ADS-B receiving units or end applications
can sort messages received from multiple issuing units.
Aircraft/Vehicle (A/V) - Either 1) a machine or service capable of atmospheric flight, or

2) a vehicle on the airport surface movement area. In addition to A/Vs, ADS-B equipage
may be extended to temporarily uncharted obstacles (i.e., obstacles not identified by a
current NOTAM).
Air Mass - Air mass data includes barometric altitude and air speed.
Alert Zone - In the Free Flight environment, each aircraft will be surrounded by two
zones, a protected zone and an alert zone. The alert zone is used to indicate a condition
where intervention may be necessary. The size of the alert zone is determined by aircraft
speed, performance, and by CNS/ATM capabilities.
Along-Track Distance - The distance along the desired track from the waypoint to the
perpendicular line from the desired track to the aircraft.
Altitude, Barometric See barometric altitude.
Altitude, Geometric See geometric height.
Applications - Specific use of systems that address particular user requirements. For the
case of ADS-B, applications are defined in terms of specific operational scenarios.
Barometric Altitude - Geopotential altitude in the earth's atmosphere above mean

standard sea level pressure datum surface, measured by a pressure (barometric) altimeter.
Barometric Altitude Error - For a given true barometric pressure, Po, the error is the
difference between the transmitted pressure altitude and the altitude determined using a
standard temperature and pressure model with Po.
Call Sign - The term aircraft call sign means the radiotelephony call sign assigned to
an aircraft for voice communications purposes. (This term is sometimes used
interchangeably with flight identification or flight ID). For general aviation aircraft,
the aircraft call sign is normally its national registration number; for airline and commuter
aircraft, it is usually comprised of the company name and flight number (and therefore
not linked to a particular airframe); and for the military, it usually consists of numbers
and code words with special significance for the operation being conducted.
20xx, RTCA, Inc.

Appendix B
Page B - 13
Caution - An annunciation that is generated when immediate crew awareness is required

and subsequent crew action will be required; the associated color is amber/yellow.
(Source: Advisory Circular AC25 - 11).
Closest Point of Approach (CPA) - The minimum horizontal distance between two
aircraft during a close proximity encounter, a.k.a. miss distance.
Cockpit Display of Traffic Information (CDTI) - A function which provides the

pilot/flight-crew with surveillance information about other aircraft, including their
position. The information may be presented on a dedicated multi-function display
(MFD), or be processed for presentation on existing cockpit flight displays. Traffic
information for the CDTI function may be obtained from one or multiple sources
(including ADS-B, TCAS, and TIS) and it may be used for a variety of purposes.
Requirements for CDTI information will be based on intended use of the data (i.e.,
application).
Collision Avoidance - An unplanned maneuver to avoid a collision.
Conflict - Any situation involving two or more aircraft, or an aircraft and an airspace, or
an aircraft and ground terrain, in which the applicable separation minima may be
violated.
Conflict Detection - The process of projecting an aircrafts trajectory to determine

whether it is probable that the applicable separation minimum will not be maintained
between the aircraft and either 1, another aircraft or vehicle, 2, a given airspace, or 3,
ground terrain. The level of uncertainty in the projection is reduced with increased
knowledge about the situation, including aircraft capabilities, flight plan, short term
intent information, etc.
Conflict Management - Process of detecting and resolving conflicts.
Conflict Probe - The flight paths are projected to determine if the minimum required
separation will be violated. If the minima are not [projected to be] violated, a brief
preventive instruction will be issued to maintain separation. If the projection shows the
minimum required separation will be violated, the conflict resolution software suggests
an appropriate maneuver.
Conflict Resolution - The process of identifying a maneuver or set of maneuvers that,

when followed, do not cause a conflict or reduce the likelihood of conflict between an
aircraft and either 1, another aircraft or vehicle, 2, a given airspace, or 3, ground terrain.
Maneuvers may be given to multiple aircraft to fully resolve a conflict.
Conformance - The condition established when the surveillance report of an aircrafts

position at some time t (established by the Automated Tracking function) is within the
conformance region constructed around that aircraft at its nominal position at time t,
according to the agreed upon trajectory.
Cooperative Separation - This concept envisions a transfer of responsibility for aircraft

separation from ground based systems to the air-crew of appropriately equipped aircraft,
for a specific separation function such as In-trail merging or separation management of
close proximity encounters. It is cooperative in the sense that ground-based ATC is
20xx, RTCA, Inc.

Appendix B
Page B - 14
involved in the handover process, and in the sense that all involved aircraft must be
appropriately equipped, e.g., with RNAV and ADS-B capability, to perform such
functions.
Cross-link - A cross-link is a special purpose data transmission mechanism for

exchanging data between two aircrafta two-way addressed data link. For example, the
TCAS II system uses a cross-link with another TCAS II to coordinate resolution
advisories that are generated. A cross-link may also be used to exchange other
information that is not of a general broadcast nature, such as intent information.
Desired Course - Can be either 1) True - A predetermined desired course direction to be

followed (measured in degrees from true north), or 2) Magnetic - A predetermined
desired course direction to be followed (measured in degrees from local magnetic north).
Effective Update Interval - The time interval between successful message receipt with at
least 98% probability of successful reception. For example, if ADS-B messages are sent
at one second intervals in signal-to-noise conditions with 75% probability of success per
transmission, then the probability of obtaining at least one message in three tries is
= 1. - (0.25) 3 ~ 98.4%. Thus the effective update interval for this case = 1 sec x 3 = 3
sec.
Effective Update Rate - The reciprocal of effective update interval, e.g. rate = 1/3 ~
0.33 Hz for the example above.
En Route - A phase of navigation covering operations between departure and

termination phases. En route phase of navigation has two subcategories: en route
domestic/continental and en route oceanic.
Event Driven Messages - Those messages that are transmitted from Mode S
Transponder-Based ADS-B Transmitting Subsystems in response to a certain event:
namely, the loading of the event-driven register, Mode S Transponder register 0A
{HEX}. This is according to the event-driven protocol described in the Mode S
Transponder MOPS (RTCA/DO-181D, 2.2.23.1.2). When these message formats are
transmitted from Non-Transponder-Based devices, they might still be called event-driven
messages, but a better term would be On-Condition messages. (See On-Condition.)
Extended Squitter A long message (format DF=17) that Mode S Transponders

transmit automatically, without needing to be interrogated by a radar, to announce the
won-ship aircrafts presence to nearby ADS-B equipped aircraft. (Also see Acquisition
Squitter.)
Final Approach Fix (FAF) - A point in space used to indicate the position at which an
aircraft on a standard approach should be stabilized with appropriate guidance being
supplied for the Final Approach Segment. (Source: FAA)
20xx, RTCA, Inc.

Appendix B
Page B - 15
Flight Technical Error (FTE) - The accuracy with which the aircraft is controlled as
measured by the indicated aircraft position with respect to the indicated command or
desired position. It does not include blunder errors.
Free Flight - Free Flight is a safe and efficient flight operating capability under IFR in
which the operators have the freedom to select their path and speed in real time.[TF3,
Oct. 1995].
FRUIT - False Replies [from transponders] Unsynchronized In Time. See Garble, Non-
synchronous.
Garble, Non-synchronous - Interfering reception of two or more replies. Interfering

replies received from a transponder that is being interrogated by some other source is
called FRUIT.
Geometric Dilution of Position (GDOP) - The ratio of position error of a multi-

lateration system. More precisely, it is the ratio of the standard deviation of the position
error to the standard deviation of the measurement errors, assuming all measurement
errors are statistically independent and have a zero mean and the same standard
distribution. GDOP is the measure of the "goodness" of the geometry of the multi-latera-
tion sources as seen by the observer; a low GDOP is desirable, a high GDOP undesirable.
(See also PDOP, HDOP and VDOP.)
Geometric height - The minimum altitude above or below a plane tangent to the earths
ellipsoid as defined by WGS84.
Geometric height error - Geometric height error is the error between the true geometric
height and the transmitted geometric height.
Global Navigation Satellite System (GNSS) - GNSS is a world-wide position, velocity,

and time determination system, that includes one or more satellite constellations,
receivers, and system integrity monitoring, augmented as necessary to support the
required navigation performance for the actual phase of operation.
Global Positioning System (GPS) - A space-based positioning, velocity and time system
composed of space, control and user segments. The space segment, when fully
operational, will be composed of 24 satellites in six orbital planes. The control segment
consists of five monitor stations, three ground antennas and a master control station. The
user segment consists of antennas and receiver-processors that provide positioning,
velocity, and precise timing to the user.
GNSS Altitude (MSL) - The height of the aircraft (or of its GNSS antenna) above the
geoid, which is the surface that represents mean sea level. The term geoid, as defined by
the National Geodetic Surveys Geodetic Glossary, is the equipotential surface of the
Earths gravity field which best fits, in the least squares sense, mean sea level.
Graticule - A network of lines on a map representing geographic parallels and

meridians.
20xx, RTCA, Inc.

Appendix B
Page B - 16
Height Above Touchdown (HAT) - Specifically, the height above the Runway Intercept
Waypoint. In using this term for airborne equipment specifications, care should be taken
to define the point on the aircraft (GPS antenna, wheel height, center of mass) that
applies.
Horizontal Dilution of Precision (HDOP) - The ratio of user-referenced horizontal

position error to measurement error of a multi-lateration system. (See GDOP for a more
detailed description.)
In-Trail Climb - In-trail climb (ITC) procedures enables trailing aircraft to climb to a
more fuel-efficient or less turbulent altitude.
In-Trail Descent - In-trail descent (ITD) procedures enables trailing aircraft to descend
to a more fuel-efficient or less turbulent altitude.
Interactive Participants - An ADS-B network member that is a supplier of information to

the local ADS-B subsystem and a user of information output by the subsystem.
Interactive participants receive messages and assemble reports specified for the respective
equipage class.
Latency - The latency of an ADS-B transmission is the time period from the time of
applicability of the aircraft/vehicle position ADS-B report until the transmission of that
ADS-B report is completed.
Latency Compensation - High accuracy applications may correct for system latency
introduced position errors using ADS-B time synchronized position and velocity
information.
Latitude In this document, latitude always means WGS-84 geodetic latitude. That
is, the latitude of a point is the angle that a line that passes through that point, and that is
normal to the WGS-84 ellipsoid, makes with the equatorial plane of that ellipsoid. North
latitudes are positive, and south latitudes are negative.
Longitude In this document, longitude always means WGS-84 geodetic longitude.

That is, the longitude of a point is the angle between the plane of that points local
geodetic meridian and the plane of the WGS-84 prime meridian (the meridian of
Greenwich). East longitudes are positive, and west longitudes are negative.
Maximum Operating Range The maximum range at which it is expected that the
ADS-B Airborne System will provide the performance necessary to meet the ADS-B
MASPS (RTCA/DO-242A) requirements.
Message See ADS-B Message.
20xx, RTCA, Inc.

Appendix B
Page B - 17
Mode S - A secondary surveillance radar (SSR) system that operates using addressed
interrogations on 1030 MHz and transponder replies on 1090 MHz. Mode S supports a
two-way data link and an ADS-B service known as Extended Squitter.
NACP Navigation Accuracy Category for Position. Values of this parameter are based
on values of Estimated Position Uncertainty (EPU), as defined in 2.1.2.13 of RTCA
DO-242A.
NACV Navigation Accuracy Category for Velocity. Values of this parameter are based
on 95% bounds on the errors in reported velocity and are defined in 2.1.2.14 of RTCA
DO-242A.
Navigation Mode - The navigation mode refers to the equipment operating to meet the
requirements for a specific phase of flight. The navigation modes are: oceanic/remote, en
route, terminal, non-precision approach, and precision approach. The oceanic/remote
mode is optional; if it is not provided, the en route mode can be substituted for the
oceanic mode.
Near Term - Near-term applications are defined as those that can be supported by an
initial ADS-B implementation and that may be operationally feasible within the context
of a current ATC system or the ATC systems of the near future.
NIC Navigation Integrity Category. A parameter that specifies an integrity

containment radius, RC.
Non-Transponder-Based Implementation - An ADS-B Transmitting Subsystem that is not

part of a Mode S transponder.
Normal Maneuver - Any maneuvers within the aircrafts approved flight-loads envelope
that does not exceed 60 degrees angle of bank, or results in an abrupt change in the
aircrafts attitude or accelerations. Abrupt changes in accelerations are those which
exceed the values shown below. Note that g = acceleration of gravity = 9.8 m/s2.
Horizontal Vertical Total

Acceleration Acceleration Jerk
0.58 g 0.5 g 0.25 g/s
NUC Navigation Uncertainty Category. Uncertainty categories for the state vector
navigation variables are characterized by a NUC data set provided in the ADS-B sending
system. The NUC includes both position and velocity uncertainties.
On-Condition Messages Those messages that are transmitted from 1090 MHz ADS-B
Transmitting Subsystems for the duration of an operational condition. When a Mode S
Transponder is used as the ADS-B Transmitting Subsystem, On-Condition messages are
when Register 0A16 is loaded with the message contents. (See Event-Driven Messages.)
Various On-Condition messages are described in subparagraphs under 2.2.3.2.7 of these
MOPS, and include the Target State and Status Message (TYPE=29, Subtype=0,
20xx, RTCA, Inc.

Appendix B
Page B - 18
2.2.3.2.7.1), the Aircraft Operational Status Message (TYPE=31, Subtype=0 for

airborne, Subtype=1 for surface, 2.2.3.2.7.2), and the 1090ES Aircraft Status Message
(TYPE=28, 2.2.3.2.7.8), which contains both the Emergency/Priority Status Message
(Subtype=1), and the TCAS Resolution Advisory (RA) Broadcast Message (Subtype=2).
Passing Maneuvers - Procedures whereby pilots use: 1, onboard display of traffic to

identify an aircraft they wish to pass; 2, traffic display and weather radar to establish a
clear path for the maneuver; and 3, voice communication with controllers to positively
identify traffic to be passed, state intentions and report initiation and completion
maneuver.
Planned Primary Means - Use of ADS-B for Planned Primary Means will be possible
for selected airspace operations based upon predictable conditions, e.g., GNSS
constellation, type of operation, and extent of ADS-B equipage for participating aircraft.
That is, ADS-B will be available as a primary means of surveillance for particular periods
of time in particular geographical regions for approved operations.
Phase of Flight - The phases of flight are defined as follows:
1. Oceanic/Remote - Radio updating is not viable due to either very limited

navigation aid coverage or no navigation aid coverage.
2. En route/Domestic - Aircraft sequences above 15,500 feet while not actively

flying a SID, or is above 15,500 and sequences the last way point of a SID, or the
phase of flight is Oceanic and radio updating is viable.
3. Terminal - Aircraft sequences below 15,000 feet; or when the aircraft is in

Approach and exceeds 3,000 feet above arrival airport elevation if there is no
missed approach holding point, or the missed approach holding point is
sequenced; or the aircraft is in Takeoff and exceeds 3,000 feet above departure
airport elevation if no SID exist in active flight plan, or the last way point of the
SID is sequenced below 15,500.
4. Approach - The first way point on the active approach or approach transition is
sequenced, or the aircraft sequences below 2,000 feet above arrival airport
elevation. Approach flight phase will not be active when a VFR approach is in
the active flight plan.
Position Uncertainty Category (PUC) - The position uncertainty category (PUC) is

needed for surveillance applications to determine whether the reported position has an
acceptable level of position uncertainty. The category is based on the aircrafts estimate
of position uncertainty (EPU), as defined in 3.1.2 of the RNP MASPS[9]
Primary Means of Navigation - The airborne navigation equipment that meets the
requirements of radio navigation for the intended phase of flight (route to be flown).
These requirements include satisfying the necessary level of accuracy, integrity,
continuity, and availability for a particular area, route, procedure, or operation. Examples
of systems which provide a primary means of navigation include:
20xx, RTCA, Inc.

Appendix B
Page B - 19
a. VOR for domestic en route, terminal, and non precision approach where it is
available;
b. VOR/DME for domestic en route above flight level 240, terminal, and non
precision approach where it is available;
c. OMEGA for Oceanic Operation;
d. INS for Oceanic Operation;
Protected Zone - In the Free Flight environment, each aircraft will be surrounded by two
zones, a protected zone and an alert zone. The protected zone must remain sterile to
assure separation. It can be envisioned as a distance-based hockey puck with radius
equal to half the horizontal separation minimum and vertical extent equal to + half the
vertical separation minimum. The size of the protected zone is a direct reflection of the
position determination accuracy.
Received Update Rate - The sustained rate at which periodic ADS-B messages are
successfully received, at a specified probability of reception.
Reliability - The probability of performing a specified function without failure under

given conditions for a specified period of time.
Resolution - The smallest increment reported in an ADS-B message field. The

representation of the least significant bit in an ADS-B message field.
Report - See ADS-B Report.
Required Navigation Performance (RNP) - A measure of the navigation system

performance within a defined airspace, route, or procedure, including the operating
parameters of the navigations systems used within that airspace. (Source: Adapted from
the ICAO Separation Panel).
Seamless - A chock-to-chock continuous and common view of the surveillance

situation from the perspective of all users.
Sole Means of Navigation - An approved navigation system for a given operation or

phase of flight that must allow the aircraft to meet, for the operation or phase of flight, all
four navigation system performance requirements: accuracy, integrity, availability, and
continuity of service.
Squitter A message transmitted from a Mode S Transponder or other ADS-B

transmission device that is broadcast automatically, without the need for the transponder
to be interrogated by a radar. (Also see Acquisition Squitter and Extended Squitter.)
Station-keeping - Station-keeping provides the capability for a pilot to maintain an

aircrafts position relative to the designated aircraft. For example, an aircraft taxiing
20xx, RTCA, Inc.

Appendix B
Page B - 20
behind another aircraft can be cleared to follow and maintain separation on a lead
aircraft. Station-keeping can be used to maintain a given (or variable) separation. An
aircraft that is equipped with an ADS-B receiver could be cleared to follow an FMS or
GNSS equipped aircraft on a GNSS/FMS/RNP approach to an airport. An aircraft doing
station-keeping would be required to have, as a minimum, some type of CDTI.
State Vector - An aircraft or vehicles current kinematic state.
Supplemental Means of Navigation - An approved navigation system that can be used in

controlled airspace of the NAS in conjunction with a sole means of navigation.
Tactical Parameters - Tactical information may be used to enhance the performance of

designated applications. System designs should be flexible enough to support tactical
parameters; however, it is not required to provide the parameters in all implementations.
TCAS Implementation - ADS-B transmit and receive capability implemented as part of

a TCAS installation (1090 MHz transmit and receive).
Terminal Area - A general term used to describe airspace in which approach control
service or airport traffic control service is provided.
Total System Error (TSE) - Generic: The root-sum-square of the navigation source
error, airborne component error, display error and flight technical error. Specific: The
root-sum-square of the position fixing error, display error, course selection error and
flight technical error.
Track Angle - Instantaneous angle measured from either true or magnetic north to the
aircraft's track.
Transmission Rate - The sustained rate at which periodic ADS-B messages are
transmitted.
Transponder Based Implementation - An ADS-B transmitter implemented as part of, or

added capability to, a Mode S transponder.
Traffic Situation Display (TSD) - A TSD is a cockpit device that provides graphical
information on proximate traffic as well as having a processing capability that identifies
potential conflicts with other traffic or obstacles. The TSD may also have the capability
to provide conflict resolutions.
Trajectory Change Point (TCP) - TCPs provide tactical information specifying

space/time points at which the current trajectory of the vehicle will change. This change
in vehicle trajectory could be in the form of a change in altitude (climb/descent), a change
in heading, a change in airspeed (increase/decrease), or any combination thereof.
20xx, RTCA, Inc.

Appendix B
Page B - 21
Velocity Uncertainty Category (VUC) - The velocity uncertainty category (VUC) is

needed for surveillance applications to determine whether the reported velocity has an
acceptable level of velocity uncertainty.
Vertical Profile - A line or curve, or series of connected lines and/or curves in the
vertical plane, defining an ascending or descending flight path either emanating from or
terminating at a specified waypoint and altitude, or connecting two or more specified
waypoints and altitudes. In this sense, a curve may be defined by performance of the
airplane relative to the airmass.
Warning - An annunciation that is generated when immediate recognition and corrective

or compensatory action is required; the associated color is red. (Source: Advisory
Circular AC25 - 11)
World Geodetic Survey (WGS) - A consistent set of parameters describing the size and
shape of the earth, the positions of a network of points with respect to the center of mass
of the earth, transformations from major geodetic datums, and the potential of the earth
(usually in terms of harmonic coefficients).
World Geodetic System 1984 -- A set of quantities, developed by the U.S. Department
of Defense for determining geometric and physical geodetic relationships on a global
scale, based on a geocentric origin and a reference ellipsoid with semi-major axis
6378137 and flattening 1/298.257223563.
20xx, RTCA, Inc.

Appendix B
Page B - 22
B.3 Illustrations of Geodetic Coordinate Definitions
B.3.1 Latitude, Longitude and Geodetic Height
Figure B-1 illustrates the definitions of the geodetic coordinates: latitude (), longitude
(), and geodetic height (h).
north pole WGS-84 ellipsoid
Prime
(Greenwich)
Meridian Geodetic height (h) of the
P(, , h)
point P is the length of the line
segment from P to the
surface of the ellipsoid, that is
h normal (perpendicular) to the
ellipsoid.
Longitude () is the angle Latitude () is angle between

between the plane of the normal through P to the
prime meridian and the ellipsoid and the plane of the
plane of the local meridian. equator.

WGS-84 equator
south pole
Figure B-1: Geodetic Coordinate Definitions
20xx, RTCA, Inc.

Appendix B
Page B - 23
Figure B-2 illustrates the definition of latitude in more detail by showing the WGS-84
ellipsoid with a very exaggerated eccentricity.
Geodetic height (h) of the point P north pole P(, , h)

is the length of the line segment
from P to the surface of the
h WGS-84 ellipsoid (shown with
ellipsoid, that is normal
exaggerated eccentricity)
(perpendicular) to the ellipsoid.
Latitude () is angle between

normal through P to the ellipsoid
and the plane of the equator.
plane of the
equator
south pole
Figure B-2: Latitude Definition
20xx, RTCA, Inc.

Appendix B
Page B - 24
B.3.2 Latitude and Longitude Representations

Latitude and longitude are angles, and so may be represented in various angular units of
measure: radians, degrees, or circles. One important way of representing angles is as
binary fractions of a circle (angular weighted binary, or AWB). Many avionics
position data sources use ARINC 429 data buses to deliver such angular parameters as
latitude, longitude, and heading, and the binary ARINC 429 data words use the angular
weighted binary notation for representing angles.
Figure B-3 illustrates how latitude and longitude are represented using radians, degrees,
and binary fractions of a circle.
North Pole
+/2 radians
+90 degrees Equator
binary 0.01000... circles 0 radians
0 degrees
binary 0.00000... circles
2nd quadrant 1st quadrant

Latitude
Representations 3rd quadrant 4th quadrant
South pole
-/2 radians
-90 degrees
90 deg. E longitude
+/2 radians
+90 degrees
Longitude
Representations Prime meridian
2nd quadrant 1st quadrant 0 radians
0 degrees
180 th
meridian binary 0.00000... circles
radians 3rd quadrant 4th quadrant
180 degrees
90 deg. W longitude
-/2 radians
-90 degrees
Figure B-3: Representations of Latitude and Longitude
20xx, RTCA, Inc.

Appendix C
Aircraft Antenna Characteristics


Appendix C
Page C - 3
C Aircraft Antenna Characteristics
C.1 Introduction
Transmissions and receptions of signals in the 1090 MHz frequency band are affected
significantly by aircraft antenna gain characteristics. Such effects are known to be
significant in the performance of the existing ATCRBS, Mode S surveillance and
collisions avoidance (TCAS/ACAS) systems. Similarly, aircraft antenna effects can be
expected to be significant in the performance of Extended Squitter ADS-B.
To support surveillance from the ground, ideally an aircraft antenna would provide
coverage that is omnidirectional in azimuth, and that maintains signal strength when an
aircraft banks and/or pitches. Furthermore the physical antenna should be small to
minimize drag. Practical antennas installed on aircraft differ from the ideal in several
ways. The most obvious difference is that a single antenna provides good coverage over
just one of the two hemispheres. A bottom mounted antenna provides coverage in
downward directions, and a top mounted antenna provides coverage in upward directions,
and both top and bottom antennas provide coverage horizontally. Primary applications of
1090 MHz Extended Squitter require full solid angle mutual observability. Operational
performance for IFR applications must be provided in any geometry between any two
aircraft. Unlike ground based surveillance, message exchanges are required between all
aircraft within line of sight and within range for reception prescribed for each equipment
type. Therefore the installed antenna performance must provide adequate coverage in the
volume fully surrounding an airborne aircraft. It follows that there is a significant benefit
in having a diversity installation consisting of both a top antenna and a bottom antenna.
Another departure from ideal performance is caused by the obstruction of signals by the
tail of the aircraft, which affects top antenna performance. Typically a top antenna
pattern will exhibit a reduction in gain in the aft direction. Because of the size of an
aircraft tail relative to one wavelength (which is about 1 foot at 1090 MHz), the signal is
not completely blocked by the tail, but instead it is made weaker by several dB. Signals
in this direction may be still useful, depending on the range and other factors in the link
power budget.
In addition to the tail, objects such as other antennas, propeller blades, engines, wheels,
and flaps can also cause blockage of 1090 MHz signals. Furthermore it is possible for
reflections from a wing or other flat surface on the aircraft to interfere constructively or
destructively with the signal and cause additional fluctuations in signal strength.
Considerations such as these have prompted a viewpoint that the entire aircraft should be
considered as part of the antenna. In the descriptions and data that follow, this point of
view is adopted. Antenna gain is considered to be a characterization of the installed
antenna, including all effects of the aircraft.
Given the operational requirement for mutual observability, the installed antenna(s) must
support adequate received power at the maximum range for the each equipment type. At
these ranges the practical observation angles between operationally relevant aircraft for
A1S/A1 equipment are limited to the values of 10 degrees. At the greatest ADS B range
for A3 the angles are limited to the same values even with extreme altitude differences
which must be supported. Mutual observation at high angle slant ranges must be
continuous with adequate received power to maintain reception probability necessary to
20xx, RTCA, Inc.

Appendix C
Page C - 4
provide the Report update rates required at the current range. Antenna gain patterns
change rapidly with increasing elevation angles from horizontal. Consequent degradation
may by compensated by the improved range advantage in realistic geometric conditions
producing high angular values (e.g., 75 degrees). Antenna installation designs must
maximize air to air surveillance functionality to be essentially free of operational holes.
Upper and lower antenna configurations and diversity techniques will typically be
necessary to support applications intended for IFR airspace procedures. The following
sections provide indications of the variations in coverage and link pattern performance
expected for antenna locations and diversity systems.
C.2 Model Aircraft Antenna Pattern Measurements

A large set of antenna gain measurements is given in Reference C-1. These were made
using 20:1 scale aircraft models. The measurements were made in an antenna test range.
The model aircraft was installed on a movable mount that enabled testing in every
direction. Measurements were made in 2 degree steps in both azimuth and elevation.
The measurement techniques are described in the reference. Measurements were made
for the following types of aircraft, and for several antenna locations on each aircraft,
some top mounted and some bottom mounted.
Piper Cherokee
Shrike Commander
Cessna 150
Cessna 402B
Cessna Cardinal
Beech Baron
Beech B99
Twin Otter
Helio U10D
Gates Lear Jet
Grumman Gulfstream II
These include both high wing and low wing aircraft, single engine and twin engine
aircraft, and small jet aircraft. The focus on General Aviation types of aircraft was
intended to complement data that already existed for larger air carrier types. Photos in
this reference show each of the aircraft models, and indicate the antenna locations that
were tested. The measured patterns are given in the form of polar plots showing the three
principal planes for each antenna on each aircraft. Similar model measurements were
also made for several air carrier aircraft, namely,
Boeing 727
Boeing 737
Boeing 707
Boeing 747
as described in Reference C-2.
C.3 Analysis of Aircraft Antenna Gain Measurements

The data given in Reference C-1 has been analyzed in several different ways, as
described in Reference C-2. This report presents a different plotting format called the
Gain-Contour Plot, which has the advantage of showing the entire antenna pattern (in
every direction) on one plot. The resulting plots reveal patterns that can be recognized as
20xx, RTCA, Inc.
Appendix C
Page C - 5
effects of obstruction and in some cases vertical lobing caused by reflection from a wing.
These interpretations are described in the report.
Reference C-2 also presents a statistical analysis, which is useful in system design and
performance assessments. Results are presented showing the probability of each possible
value of antenna gain. Therefore, while recognizing that certain very low values of
antenna gain exist, these results indicate how common these conditions are. Results are
also presented showing the degradation in performance due to conditions of flaps down,
wheels down, and banking.
Building on those analyses and results, Reference C-3 presents a set of antenna gain
contour plots for a large number of aircraft-antenna combinations. The results are useful
in that they extend the cases described in Ref. C-2, providing a much larger number of
cases in which to observe the described effects.
Building further on the results in Reference C-2, an additional analysis is given in

Reference C-4. The results provide a probability distribution of aircraft antenna gain for
the entire set of aircraft, including all of the antenna locations tested (page 18). This
curve, which is the cumulative probability distribution of antenna gain values, is useful in
designing a system, in which it is important to allow for many different aircraft types and
antenna locations. The application of this data to the system design of TCAS is the main
subject of this report. The results presented in Ref. C-4 are given in two ways, one for
aircraft having a single bottom mounted antenna, and the other for aircraft equipped with
a diversity combination consisting of a top antenna and a bottom antenna. To
characterize top-bottom diversity, this analysis assigns the antenna gain in a particular
direction to be the larger of the two values (gain of the bottom antenna and gain of the
top antenna).
An explicit mathematical model for aircraft antenna gain is given in the TLAT report
(Ref. C-5). This is a stochastic model that is consistent with the frequency of occurrence
of antenna-gain values in Ref. C-4, and includes a formula to characterize the effects of
elevation angle for top and bottom antennas. This antenna-gain model was used for the
performance assessments made in the TLAT Report (Ref. C-5).
In summary, the probability distribution of antenna gain values given in Ref. C-4 and C-5
is a useful characterization of aircraft antenna gain deviations caused by banking,
obstructions, and reflections. It is the product of model measurements made on a number
of aircraft, including both general aviation and air carrier types, and a number of possible
antenna locations on each. This data was used in designing the air-to-air power budget
for TCAS, and has been used for air-to-air and air-to-ground transmission and reception
of Extended Squitter signals.
20xx, RTCA, Inc.

Appendix C
Page C - 6
APPENDIX C REFERENCES
C-1. K. J. Keeping and J. C. Sureau, Scale Model Pattern Measurements of Aircraft L-Band Beacon
Antennas, M I T Lincoln Laboratory Project Report ATC-47, April 1975.
C-2. G. J. Schlieckert, An Analysis of Aircraft L-Band Beacon Antenna Patterns, M I T Lincoln

Laboratory Project Report ATC-37, Jan. 1975.
C-3. D. W. Mayweather, Model aircraft L-Band Beacon Antenna Pattern Gain Maps, M I T Lincoln
Laboratory Project Report ATC-44, May 1975.
C-4. W. H. Harman, Effects of RF Power Deviations on BCAS Link Reliability, M I T Lincoln

Laboratory Project Report ATC-76, June 1976.
C-5. The ADS-B Technical Link Assessment Team (TLAT) Technical Link Assessment Report, March
2001, Appendix J.
20xx, RTCA, Inc.

APPENDIX D
1090 MHz ADS-B

GROUND ARCHITECTURE EXAMPLE


Appendix D
Page D - 3
D 1090 MHz ADS-B Ground Architecture Example
D.1 Introduction and Purpose

This appendix defines examples of ground architectures that can support (1) surveillance
for ATC using Extended Squitter ADS-B reports and (2) Traffic Information Service
Broadcast (TIS-B) on 1090 MHz.
ATC Surveillance
The FAA is interested in Extended Squitter as a means of surveillance of aircraft via

ground stations. Surveillance of both airborne aircraft and aircraft on the airport surface
are of interest. The FAA has been investigating ground architectures that would be
appropriate for this purpose. The results are summarized in this appendix. An example
1090 ground architecture for high density airspace in a current radar environment is
summarized in this appendix. As new information arises from programs such as Safe
Flight 21 (including evaluation efforts in Ohio River Valley and Alaska Capstone), the
FAA and the NAS users will collectively revise the architecture to refine the course of
NAS modernization.
Note that the Traffic Information Service (TIS) capability is not included in the Extended
Squitter ground station, since this service will be provided by conventional secondary
radars with Mode S capability.
Traffic Information Service - Broadcast
Traffic Information Service - Broadcast (TIS-B) on 1090 MHz is a ground-to-aircraft

broadcast service that provides "ADS-B like" surveillance transmissions for aircraft that
are not equipped for 1090 MHz ADS-B. TIS-B makes non-equipped aircraft visible to an
aircraft with an ADS-B receiver. The surveillance source for this ground-to-aircraft
broadcast can be a rotating beam terminal or enroute radar. Other possible surveillance
sources are enroute, terminal/approach radars and surface multilateration systems. Such
multilateration systems provide a higher update rate and better surveillance accuracy than
terminal or enroute radars.
TIS-B is considered to be an integral part of an ADS-B system since it is an important

element in transition. If Extended Squitter surveillance is in use in a region of airspace,
TIS-B can make all aircraft visible to a user with a 1090 MHz receiver even though not
all aircraft are equipped for Extended Squitter.
D.2 ATC Surveillance
D.2.1 Avionics Equipage

In order to achieve a surveillance system that is based on Extended Squitter, it is
necessary to define a transition strategy for integrating Extended Squitter into the existing
system that will accommodate the mixed environment that will exist for many years
during the transition from SSR to a possible full use of Extended Squitter. For this
reason, the following avionics equipment must be accommodated:
1. Mode A/C transponder
20xx, RTCA, Inc.

Appendix D
Page D - 4
2. Mode S transponder without Extended Squitter
3. Mode S transponder with Extended Squitter
4. Non-transponder Extended Squitter device.
D.2.2 Transition Issues

A number of issues must be addressed in this transition strategy. Significant issues
include:
1. Potential loss of independence between surveillance, navigation and communication

functions.
2. Validation (or at least a reasonableness test) of reported position until reliability of

this data is established by experience.
3. Surveillance in a mixed ADS-B/SSR environment for ATC airborne and surface

surveillance
4. Backup surveillance for loss of GNSS function for individual aircraft due to an
equipment malfunction.
5. Backup surveillance for loss of GNSS function over an extended area due to
interference effects on GNSS operation.
6. The ability to suppress the creation of tracks on ADS-B reports that contain
intentionally incorrect position information (i.e., spoofers).
D.2.3 Ground surveillance of airborne aircraft
D.2.3.1 Surveillance techniques
D.2.3.1.1 Current technology

ATC surveillance of airborne aircraft is currently provided by narrow scanning beam
SSRs often collocated with primary radars. SSRs intended for terminal surveillance
have a maximum range of 60 to 100 NM and a scan interval of 4 to 6 seconds. En route
coverage is provided by SSRs with a maximum range of 200 to 250 NM and a scan
interval of 8 to 12 seconds.
Different capabilities exist for these SSRs. This includes Mode A/C only capability
based on sliding window or monopulse azimuth processing. The newest SSRs have
Mode S (and Mode A/C) capability with monopulse azimuth determination. Mode S
interrogators are able to support the readout of aircraft developed information on identity,
aircraft state and intent. This latter capability is referred to as enhanced surveillance.
D.2.3.1.2 End state surveillance using Extended Squitter

The Extended Squitter technique provides formats for airborne use that are optimized for
ATC surveillance. These formats include position, velocity, ICAO address and aircraft
20xx, RTCA, Inc.

Appendix D
Page D - 5
call sign. Provision is made to report the quality of the reported surveillance data based
upon the accuracy of the navigation source data.
As appropriate experience is gained and a transition is made to ADS-B, squitter receiving

stations might be able to replace some current SSRs. Terminal area squitter stations
would have ranges up to 100 NM. Squitter stations would provide coverage up to 250
NM in en route airspace and up to 300 NM as required in remote areas. The squitter
stations would be capable of transmitting interrogations in order to obtain additional
information from the transponder, such as intent and Mode A code.
While these stations would provide omni-directional coverage, in most cases this would
be achieved with an antenna having six to twelve sectors. Operation with such an antenna
requires the use of a receiver associated with each antenna sector, with a single
transmitter that may be switched between the sectors as required. The use of multiple
sectors will be required at high density environments for increased traffic capacity, since
each receiver only has to cope with the traffic in one sector. Such an antenna will also be
required at en route stations in order to achieve the antenna gain required for long range
operation. For illustrative purposes, six-sector antennas are used in this appendix for
ground system configuration examples employing multi-sector antennas.
D.2.3.2 Airspace considerations

The potential for transition of ATC surveillance to Extended Squitter depends on the type
of airspace being covered. The most likely application of Extended Squitter will be in
airspace that does not currently have secondary radar surveillance coverage. This could
be in a remote area or low altitude coverage in any airspace.
It is unlikely that ADS-B will replace secondary radar surveillance in any high density
airspace for the foreseeable future. A principal consideration is the need for
independence between surveillance and navigation in such airspace. A second
consideration is the vulnerability of satellite navigation sources to low level interference.
Such an interference event could result in the loss of satellite navigation service over
areas measured in tens of kilometers. Providing backup surveillance for large numbers of
aircraft will significantly increase the cost of the ADS-B ground station to the point
where ADS-B may not be a cost effective replacement for radar. ADS-B replacement of
secondary radar in high density airspace will likely require the development of a robust
satellite navigation source, or the use of an alternate navigation source such as an inertial
platform as a backup.
D.2.3.3 Transition strategy
D.2.3.3.1 Validation
If necessary, position validation can be performed by a single station equipped with a
multi-sector antenna. Range would be determined by direct interrogation of the
transponder, while bearing would be determined by measuring the relative amplitude of
the received signals in the antenna sectors. Aircraft equipped with a non transponder
device would only be able to support bearing validation unless the ground system is
equipped with multilateration capability (e.g., airport surface surveillance).
20xx, RTCA, Inc.

Appendix D
Page D - 6
Analysis indicates that a six-sector antenna can provide a bearing accuracy of around 2
degrees. This should be accurate enough for a reasonableness test in low density
airspace, but would not be sufficient for a terminal area.
Where provided for backup service, multilateration can be performed in the background
mode for validated aircraft for periodic revalidation of position. When validation is
performed by direct interrogation, a technique similar to TCAS hybrid surveillance could
be implemented to revalidate aircraft that have flight paths in close proximity to other
aircraft.
D.2.3.3.2 Backup
If necessary, backup surveillance could be provided in terminal environments using a
time- difference of arrival multilateration technique. Multilateration will require the use
of multiple receiving stations. This could be configured as a central station surrounded
by three or more outrigger stations. In this configuration, the central station would be a
full Extended Squitter ground station with transmit and receive capability and a multi-
sector antenna. The outrigger stations would be simple receivers with omni-directional
antennas. If the multilateration system is provided with sufficient capacity,
multilateration could provide backup for single aircraft or area failures of GNSS
functionality.
Where multilateration is not available, aircraft will need to be interrogated at the nominal
scan interval. Backup surveillance for non-transponder devices would only be possible if
multiple bearing measurements are available through overlapping ground station
coverage.
D.2.3.3.3 Mixed equipage

Surveillance on Mode S aircraft that are not equipped with Extended Squitter can be
performed using multilateration on the short squitter, or by direct interrogation.
Surveillance of Mode A/C only aircraft would require an active interrogation approach.
The use of active interrogations (single or whisper shout depending upon the Mode A/C
traffic density) would be used to elicit Mode A or C replies at a regular rate. In effect,
the ground station operates like a TCAS unit, but with a lower interrogation rate and at
higher effective radiated power due to its increased operating range. Since the majority
of the aircraft in high density environments will be Mode S equipped, at most 8
whisper/shout levels should be needed for Mode A/C surveillance out to 60 to 100 NM.
The central station could obtain range and a coarse bearing estimate from its multi-sector
antenna. The position could be refined by use of multilateration data from the outriggers.
The coarse position estimate would be very helpful in eliminating phantoms (position
reports made up of replies from different aircraft). Side lobe suppression will be required
to limit replies in the antenna side lobes.
D.2.3.4 Special considerations for precision runway monitoring

One surveillance application is the monitoring of aircraft on precision approaches. This
is sometimes referred to as precision runway monitoring (PRM). Using current
technology, aircraft navigate on the approach using ILS or MLS and are monitored by
20xx, RTCA, Inc.

Appendix D
Page D - 7
SSR, sometimes operating at a higher scan rate than for normal ATC surveillance. Thus
the navigation and monitoring techniques are completely independent.
Consideration is being given to use GNSS as the basis for future landing systems. If
GNSS is used for this purpose, it is likely that some independent form of validation
would be required for ADS-B surveillance data before it could also be used for PRM.
Without independent validation, ADS-B for PRM would not be able to detect a blunder
caused by a malfunction of the navigation equipment. Such a malfunction would result
in both the air crew and the ground believing that the aircraft was on the correct
approach, when in fact a deviation had occurred.
One example of a validation for PRM is the use of multilateration on the Extended
Squitter transmission, as described earlier. This technique would provide the necessary
independence of surveillance and navigation. Another example of independent validation
of the ADS-B reports from aircraft is readout of the ADS-B message and comparison to
the ground radar position when the airport is equipped with a Mode S interrogator.
Another application of ADS-B in PRM is to use CDTI and associated alert algorithms for
monitoring parallel approaches. To support this air-to-air application of ADS-B, the
current ground-based techniques should be adequate as monitoring responsibility rests
primarily in the cockpit.
D.2.4 Surface surveillance
D.2.4.1 Surveillance techniques
D.2.4.1.1 Current technology

Current surveillance on the airport surface is provided by primary radar in the form of the
Airport Surface Detection Equipment (ASDE). The ASDE provides reliable surveillance
on all targets (regardless of equipage) but does not provide identity, which is useful for
blunder detection and resolution. For this reason, techniques for providing aircraft
identity using the aircraft transponder are being considered.
Surveillance on the airport surface requires that the positional error be small compared to
the size of an aircraft in order to provide reliable correlation with the ASDE report. This
rules out the use of direct range and azimuth measurement, or even range-range
multilateration due to the tolerance in the transponder turnaround delay. For this reason
SSR-based surface systems such as ASDE-X (first operational site planned for mid-2003)
use time-difference of arrival multilateration, since it is based only on the difference in
time of the receipt of an aircraft transmission at spatially diverse ground stations.
D.2.4.1.2 End state surveillance using Extended Squitter

The Extended Squitter design provides formats for use on the airport surface that are
optimized for surface surveillance. These formats include position, velocity, ICAO
address and aircraft call sign. The accuracy needed for surface surveillance can be
supported by GNSS using local or wide area differential corrections.
20xx, RTCA, Inc.

Appendix D
Page D - 8
D.2.4.2 Transition strategy
D.2.4.2.1 Validation
If necessary, validation of surface position reports can be performed using multilateration
on the Extended Squitter or acquisition squitter transmission. Once validated, the ADS-B
reports can be used for improved surveillance performance. Multilateration can be
performed in the background mode for validated aircraft for periodic revalidation of
position.
D.2.4.2.2 Backup
The background process of multilateration provides position and identity for short or long
squitter reports that do not contain GNSS position information. A total loss of GNSS
service would cause the surveillance system to revert to full multilateration operation.
This would result in lower surveillance performance since the position accuracy and
update rate will be somewhat degraded and the aircraft will no longer provide velocity
information. However, surveillance could continue throughout the loss of GNSS service.
D.2.4.2.3 Mixed equipage

With multilateration, the only aircraft requirement for surveillance is a periodic
transmission. All Mode S transponders (even those that do not support Extended
Squitter) transmit a short squitter on an average of once per second. This is a high
enough rate to support multilateration for surface surveillance.
Mode A/C transponders do not squitter, so provision would have to be made to elicit
periodic replies if Mode A/C aircraft are to participate in surface surveillance during the
transition period. One approach is to modify the transponders to generate a reply once
per second. This may not be a feasible approach, since high equipment modification
costs could lead operators to resist such a modification. A second approach may be used
if only a small percentage of surface aircraft are Mode A/C equipped (i.e., most aircraft
are Mode S equipped). This approach is based on the use of the whisper/shout technique
used by TCAS to interrogate only a subset of the Mode A/C aircraft within range.
D.2.4.2.4 ASDE-X Surface Surveillance System

The previous sections (D.2.4.2.2 and D.2.4.2.3) provided a general strategy for
addressing transition issues that can lead to an end-state surface surveillance system
based on Extended Squitter. This section summarizes the high-level capabilities of an
operational system in the National Airspace System, called ASDE-X, that can provide a
smooth transition to end-state surface surveillance systems.
ASDE-X is a new generation surface surveillance system that is being deployed in 25

airports starting in mid-2003. It consists of the following four major system components:
1. A surface movement primary radar that is similar to ASDE, but operating in

the X-Band frequency.
2. A Transponder-Based multilateration/ADS-B system that provides position and

identification to all Transponder-equipped aircraft or vehicles. The remote
Receive/Transmit (R/T) stations of the multilateration system can interrogate
20xx, RTCA, Inc.
Appendix D
Page D - 9
Mode A/C Transponders using whisper-and-shout sequences to determine target

position based on time-difference-of-arrival techniques. The remote R/T and
Receive Only (R/O) stations of multilateration also process Extended Squitters to
derive position and identification information.
3. An automation that combines all of the sensor reports (primary/secondary radars,

multilateration, ADS-B Extended Squitter) into a single track.
4. New high bright color displays.
The surface multilateration system of the ASDE-X provides validation of 1090 MHz
ADS-B data, as well as back-up in the event of GNSS failure. Since surface
multilateration also uses a whisper/shout technique to interrogate Mode A/C aircraft,
ASDE-X can provide surveillance in a mixed equipage environment (Mode A/C and
Mode S). Additionally, ASDE-X is capable of detecting surface targets that are not
equipped with any type of Transponder and those targets with malfunctioning
Transponders.
The FAA also plans to upgrade the existing 34 ASDE-3 systems with multilateration and
multi-sensor data fusion capabilities.
In the end-state when all aircraft are 1090 MHz ADS-B equipped, ASDE-X can serve as
an operational platform for providing surface surveillance through its R/O or R/T
stations.
D.2.5 Transition Strategy Summary

A strategy for transitioning from an SSR to an Extended Squitter environment has been
defined. An example of a planned operational surface surveillance system, ASDE-X, is
provided to illustrate the implementation of a transition strategy. The strategy makes use
of the capabilities of those SSR transponders to support validation, backup and mixed
equipage scenarios through direct range and bearing measurement and multilateration.
Since the ADS-B message is contained in an SSR waveform, the same equipment that is
needed for independent position measurement of the SSR transponders can also be used
to receive the ADS-B squitters. Transition is greatly simplified by the integration of the
ADS-B function with the Mode S transponder.
D.2.6 Ground Architecture for Air-Ground Surveillance
D.2.6.1 Introduction
D.2.6.1.1 Purpose
The previous sections described a possible transition strategy for ATC use of Extended
Squitter. The capability of Extended Squitter ground receiving stations was defined in
general operational terms. The purpose of this section is to provide more details on the
architecture that might be used to provide Extended Squitter surveillance for ground ATC
use.
20xx, RTCA, Inc.

Appendix D
Page D - 10
D.2.6.1.2 Overview
This section begins with a description of the currently implemented Mode S ground
interrogators. This is relevant to Extended Squitter since ADS-B surveillance data can be
obtained by a conventional Mode S interrogator via direct readout of the Mode S
transponder. Such readout will likely be the initial technique for ATC use of ADS-B
data. This is followed by a description of the architecture of increasingly more capable
Extended Squitter ground stations.
D.2.6.1.3 Interface Considerations

Extended squitter ground stations will require the ability to interface with other ATC
surveillance resources to generate a consolidated surveillance image. For this reason,
these ground stations will be required to conform to an appropriate output interface
standard (e.g., the internationally accepted Eurocontrol ASTERIX formats).
D.2.6.2 Mode S SSR Ground Station

A Mode S SSR normally operates with a scanning narrow beam antenna. This antenna is
often mounted on the same pedestal as a co-located primary radar. Terminal Mode S
SSRs operate with a scan time of 4 to 6 seconds and provide coverage out to 60 to 100
NM. En route Mode S SSRs operate with scan times of 8 to 12 seconds out to a range of
200 to 250 NM. A functional diagram of a Mode S SSR ground station is provided in
Figure D-1.
GNSS Mode S
Receiver Transponder
Downlink of
Extended Squitter Data
Mode A/C/S Rotating

interr ogation/reply Antenna
Mode S
SSR
Figure D-1: Mode S Secondary Surveillance Radar ground station providing

surveillance of all Mode A/C/S aircraft in high density environments, as well as ADS-
B surveillance (via enhanced surveillance), validation and spoofing resistance.
A Mode S SSR provides surveillance and data link service to Mode S equipped aircraft
and surveillance service for Mode A/C equipped aircraft. Due to the use of monopulse,
(a technique for determining the off-boresight angle of received replies) surveillance to a
20xx, RTCA, Inc.

Appendix D
Page D - 11
Mode S aircraft is normally provided via a single interrogation per scan. Additional
interrogations are scheduled each scan as needed to provide data link service.
One data link service supported by a Mode S SSR is the readout of transponder data
registers that can be loaded by the aircraft to contain aircraft state, intent, weather data,
etc. These registers can be accessed on demand by the Mode S SSR using the ground
initiated Comm-B (GICB) protocol. This protocol is employed to provide the enhanced
surveillance capability being mandated by States in the core area of central Europe.
Extended squitter information that is broadcast by a Mode S transponder is stored in the

GICB registers. This means that ADS-B data is available on demand to a Mode S SSR.
The ability to obtain GNSS position and velocity, as well as intent information, via a
Mode S SSR can be an important benefit during a transition to ADS-B. In addition,
ground readout of ADS-B data provides an opportunity to monitor the status of ADS-B
implementation and, more importantly, the reliability of this data since it can be directly
compared to the Mode S radar data.
D.2.6.3 Extended Squitter Ground Stations
D.2.6.3.1 Overview
An Extended Squitter ground station can be configured to provide different levels of
performance as required.
A block diagram of the subsystems that could be included in a basic Extended Squitter
transmit/receive ground station is shown in Figure D-2. The configuration shown is for a
ground station with an omni-directional antenna. A ground system with a multi-sector
antenna would require a receiver and reply processors for each antenna sector. A single
transmitter would be used, with a switch to connect it to any antenna sector under control
of the computer system.
20xx, RTCA, Inc.

Appendix D
Page D - 12
1030/1090 MHz GPS

Antenna Antenna
Mode S GPS
Squitter RECEIVER
1090 MHz Processor & CLOCK
RECEIVER
Mode S COMPUTER
Reply SYSTEM /
Processor COMMUNICATIONS
SUBSYSTEM
TRANSMITTER MODULATOR
1030 MHz
Local Monitor /
Data Recorded Port
BUILT-IN
SELF TEST Communications
port
Figure D-2: Basic Extended Squitter System Block Diagram
D.2.6.3.2 Omni Antenna, Receive only

Capabilities: The simplest ground station only has the ability to passively receive
Extended Squitter ADS-B reports. It operates with an omni directional antenna.
Intended Use: This configuration is expected to be used in low density or remote

airspace not currently within ATC surveillance coverage.
A block diagram of this configuration is presented in Figure D-3.
20xx, RTCA, Inc.

Appendix D
Page D - 13
Mode S
T rans po nd er
G PS
or Trans mit-
Rec eiver
O nly Device
1090-MHz
E xtended S quitter
Omnidirec tional
in Azimuth
A ntenna
E xtend ed S quitter
G roundS tation
Figure D-3: Simple receive-only Extended Squitter ground station configuration

providing ADS-B surveillance.
D.2.6.3.3 Omni Antenna, Receive only, Angle of Arrival Capability

Capabilities: This configuration provides the same reception capability as above, but it is
augmented with a simple angle-of-arrival capability in order to obtain an approximate
estimate of aircraft azimuth. This ground station configuration can provide azimuth
validation on ADS-B equipped aircraft in low density airspace. Azimuth accuracy for
such an antenna has been measured to be approximately 8 degrees, one sigma.
Validation: The angle-of-arrival validation capability enables the ground station to

provide approximate validation of the ADS-B azimuth through direct comparison of the
actively measured azimuth with the azimuth calculated from the ADS-B position report.
In cases where overlapping coverage exists for this type of ground station, approximate
aircraft positions can be developed using azimuth triangulation from the ground stations.
This system allows for independent validation of ADS-B position reports.
Intended Use: The approximate position location provided by this configuration would
make it suitable only for use in low density airspace.
A block diagram of this configuration is presented in Figure D-4. Note that multiple
stations of this type that have overlapping coverage could perform azimuth triangulation.
20xx, RTCA, Inc.

Appendix D
Page D - 14
Mode S
GNSS Transponder
Receiver or Transmit-
Only Device
1090-MHz
E xtended S quitter
Omnidirec tional
in Azimuth
Antenna
An gle-of -Arri val

S en sor Extended Squitter
GroundStation
Figure D-4: Receive only Extended Squitter ground station with angle-of-arrival
sensor configuration providing ADS-B surveillance, azimuth verification and
spoofing resistance.
D.2.6.3.4 Six-Sector Antenna, Receive/Transmit

Capabilities: This configuration provides the same reception capabilities as the preceding
configuration. In addition, it is equipped with a six-sector antenna, with one receiver per
antenna beam and a single transmitter that may be switched to any beam as required. The
use of the six-sector antenna allows operation into higher density than is possible with an
omni antenna, since each receiver has to cope only with the squitters and Mode A/C
replies received from a single antenna beam. An analysis of side lobe structure and
traffic distribution indicates that such an antenna can be expected to provide a capacity
2.5 times the capacity of a ground station using an omni-directional antenna.
Validation and Fall-Back Surveillance: In addition to increased capacity, the six-sector

antenna enables this ground station to provide a higher level of validation than the omni
directional configuration. This is due to the ability of the six-sector antenna to provide
azimuth measurement to an accuracy of 2-3 degrees using a simple amplitude monopulse
processor. This coarse azimuth capability together with measured range (for a
transponder implementation of Extended Squitter) can also be used to provide fall-back
surveillance in the event of the loss of the navigation input for ADS-B. Fall-back
surveillance refers to a lower performance form of surveillance that can be used during an
outage of the principal surveillance system.
Mode S and Mode A/C Surveillance: The six-sector antenna enables this ground station
configuration to provide improved surveillance on Mode S and Mode A/C equipped
aircraft compared to the previous configuration.
Intended Use: This configuration is expected to be used in low to medium density en

route airspace where a fall-back azimuth accuracy of 2-3 degrees may be operationally
20xx, RTCA, Inc.
Appendix D
Page D - 15
acceptable. Antennas with a greater number of sectors may be used to achieve higher
capacity or improved azimuth measurement accuracy as required.
A block diagram of this configuration is presented in Figure D-5.
GNSS Mode S
Receiver Transponder
1090-MHz
Extended Squitter
Mode A/C/S Multisector

interrogation/reply Antenna
Extended
Ground
Squitter
Station
Figure D-5: Extended squitter ground station providing ADS-B surveillance,
position validation, spoofing resistance, coarse surveillance of all Mode A/C/S
aircraft and fall-back surveillance for ADS-B aircraft.
D.2.6.3.5 Multilateration Augmentation

Capabilities: This configuration is equipped with a number of receiving sites for the
purpose of providing a time-difference of arrival multilateration capability.
Multilateration augmentation may be added to any combination of the ground station
configurations listed in D.2.6.3 provided that three or more sites are located in view of
target aircraft in the surveillance volume. Multilateration stations can be very simple,
consisting of a 1090 MHz receiver, a reply processor, a means to accomplish accurate
time stamping, and a communications modem. The physical size would be small, about
the size of an SSR transponder. However, intersite communications would be required
and 3 or more sites would have to be in view of a particular aircraft in order to obtain a
multilateration solution.
Backup Surveillance: Depending on the geometry of the ground stations, multilateration

position accuracy can equal or exceed that of an SSR. With this level of position
accuracy, backup surveillance is possible. Backup surveillance refers to an alternative
surveillance capability that can be used during an outage of the principal surveillance
system that provides equivalent performance to the principle system.
Mode S and Mode A/C Surveillance: Mode S and Mode A/C surveillance capability can
also be provided via active interrogation. The coarse position information provided by
the six-sector antenna would be very useful in eliminating false targets that could
otherwise result from performing multilateration on non-discrete Mode A Code replies.
20xx, RTCA, Inc.

Appendix D
Page D - 16
Intended Use: The level of capability provided by this configuration would be

appropriate for use in a terminal area.
A block diagram showing multilateration augmentation to a representative mix of ground

station types providing primary and backup surveillance is presented in Figure D-6.
G PS Mo d e S
R ec eive r Tran s p o nd er
1090-MHz
E xtend ed S qu itter
Mode A /C /S
in terrog atio n /reply
Mo de A /C /S Mod e A /C /S Mod e A /C /S
R ec eiver, R ec eiver, T ran s c ever,
C o mmon T ime C o mmon T ime C o mmon T ime
S o u rc e S o u rc e S o urc e
Multilateration Multilateration Extended Squitter

Outrigger Outrigger Ground Station
N o tes : -B ac kup req uires 3-4 g ro und s tations in c overag e
-Bac kup pro vides surveillanc e on all Mode A /C /S airc raft
Figure D-6: Extended squitter ground station providing ADS-B surveillance,

position validation, spoofing resistance, accurate surveillance of all Mode A/C/S
aircraft and backup surveillance for ADS-B aircraft.
D.2.7 Ground Architecture for Surface Surveillance
D.2.7.1 Overview
The purpose of this section is to describe the ground architecture that may be used for
surface surveillance using Extended Squitter. As indicated above, transition and
validation requirements will require the use of multilateration is support of surface
surveillance. In addition, inputs from air-ground surveillance devices will also be
required to monitor arriving aircraft
D.2.7.2 Extended Squitter Surface Ground System

Extended squitter ground stations for surface surveillance can be 1090 MHz receive only
or may have 1030 MHz transmit capability in order to (optionally) manage surface
squitter rates. These stations would use omni or single sector beam antennas as
appropriate to cover the airport maneuvering area.
20xx, RTCA, Inc.

Appendix D
Page D - 17
D.2.7.3 Candidate Ground Architecture

A candidate ground architecture for surface surveillance is shown in Figure D-7. This
architecture features a surveillance server with data fusion capability to provide a
surveillance picture based on the combined resources of ADS-B, multilateration, ASDE
and the airport surveillance radar (ASR). This surveillance information is used to support
a conflict alert algorithm. The surveillance and conflict alert results are provided to
ground ATC. Provision is also made to data link alerts to the cockpit.
DGPS
Corrections
Primary Radar LAN

ASDE ATC Displays
ASR/ARTS DGPS Corrections,
Position & Alert Data
Position Data
Surveillance Aircraft Display
CDTI*
Server with Datalink
Cooperative Surveillance Conflict Alerts
ADS-B/ Multilateration Data Fusion,
Conflict Alert Vehicle Display
Position & ID Data
Datalink Situational Awareness
Algorithms
Conflict Alerts
Ground Vehicle
ADS-B Position & ID Data
Figure D-7: Ground architecture for surface surveillance using ADS-B,

multilateration and radar.
D.2.8 Integration with Other Radars and Automation Systems
D.2.8.1 Overview
With the introduction of ADS-B, the surveillance architecture will consist of a mix of
primary and secondary air surveillance radars, one or more of the ADS-B ground station
options described earlier in this Appendix and surface surveillance sensors including
multilateration and ASDE. The sensors represent a mix in several respects:
several different primary and secondary models,
airport and en route equipage each support several different combinations of the
primary and secondary models,
surveillance installations interface with several different automation systems.
A few areas of CONUS, as well as parts of Alaska and Hawaii, currently have coverage
gaps that may be filled with ADS-B ground stations, most likely with some degree of
overlap. Most other areas currently have primary and secondary radars that provide
substantial multiple coverage overlaps. The implementation of ADS-B ground stations in
these areas will increase the basic coverage as well as the number of overlaps. Aircraft
transponder equipage currently varies and it may well vary in the future with the ADS-B
equipage options being considered.
20xx, RTCA, Inc.

Appendix D
Page D - 18
Given this substantial mix and the growth toward free flight, made possible with ADS-B,
there is an underlying need for a flexible integration scheme that can exploit the
improved surveillance track database to produce unified tracks. That is, the sum of the
track data available on a target from multiple surveillance sensors (radars and ADS-B)
and from neighboring installations can be fused to provide a unified track on each target
with much higher accuracy for ATC and ATM purposes. The FAA has been
investigating methods that can fuse data from multiple and varied sensors toward this end
goal.
D.2.8.2 The Need for Fusion

The need for sensor data fusion is predicated on several related key factors. They
include:
the surveillance sensor mixes encountered in the US and Internationally,

particularly in European airspace,
the absolute imperative to maintain safety as aircraft with mixed equipage share
the same airspace will not allow reduced safe spacing requirements with current
automation mosaicing techniques,
the potential to reduce cost by reducing numbers of surveillance sensors may be

enabled by fusing tracks from the remaining overlapping sensors,
fused ground based surveillance from all sensor types supports a seamless gate-
to-gate view of aircraft and surface vehicle surveillance which will support future
automation and procedural alternatives,
fused data will provide a source of information to support an ADS-B related

product known as Traffic Information Service Broadcast (TIS-B),
supporting ATC and ATM in a Free Flight Environment requires improved

surveillance performance in both air-air and air-ground modes, and
efficiency in operations made possible by improved surveillance performance

may lead to reduced separation minimums and reduced controller workload
D.2.8.3 Architecture Considerations

Surveillance and Automation teams within the FAA are currently investigating several
technical issues that must be considered in selecting an effective and affordable fusion
architecture approach. Consideration must also be given to hardware and software
implementations that can be introduced as part of a larger transition in the NAS
modernization process. Conceptually, each automation end point will be supported by
one or more surveillance servers and a surveillance hub. Together they will provide the
necessary interface to process and integrate data, which can be synchronous or
asynchronous and can be displaced in time due to sensor locations. Data formats will
have to be upgraded to incorporate longer data messages per target, preserve sensor data
accuracy and event time and introduce new message content such as pilot intent. Key
technical considerations include:
20xx, RTCA, Inc.

Appendix D
Page D - 19
the number and type of sensors and automation systems which are to be served,
the interface data format (ASTERIX is the primary candidate),
the flexibility for compensating sensor bias (registration) errors since these are
usually the limiting factor in fusion,
the selection of data combining techniques , that is the combining of data reports
before fused track files are formed versus the fusing of individual sensor track
files versus a hybrid combination of both methods,
adaptability to sensor failures,
communication requirements in terms of data link bandwidth,
processor sizing and placement,
current and projected state-of-the-art in fusion,
the establishment of requirements to be applied to the surveillance data fusion

system.
Figure D-8 illustrates an example of the many sites and types of equipage that would
introduce target data to a surveillance hub and surveillance servers that implement fusion
and provide a unified target database to automation.
20xx, RTCA, Inc.

Appendix D
Page D - 20
Figure D-8: Conceptual architecture for implementing surveillance fusion of multi-sensor /

multi-site target reports
D.2.9 ATC Surveillance Summary

The Extended Squitter system provides a wide range of options for aircraft surveillance.
For surveillance of airborne aircraft, these options range from simple, low cost, ADS-B
receive-only ground stations, to a six-sector configuration with multilateration that can
provide ADS-B service plus surveillance of Mode A/C/S aircraft suitable for use in a
terminal area. In the highest density airspace, the option exists for the use of Mode S
Secondary Surveillance Radars that will support the surveillance of all Transponder-
equipped aircraft in addition to readout of ADS-B data.
For surface surveillance, these options include ADS-B only, or ADS-B in combination
with multilateration to support transition and validation activities.
D.3 Traffic Information Service Broadcast (TIS-B)
D.3.1 Overview
The formats and protocols required for avionics implementing TIS-B on 1090 MHz are
specified in the body of these MOPS and in Appendix A. Ground processing for TIS-B
on 1090 MHz must implement these same formats and compatible algorithms to
interoperate with airborne equipment.
20xx, RTCA, Inc.

Appendix D
Page D - 21
Specific requirements for the ground processing component of TIS-B are contained in the
TIS-B MASPS. The TIS-B MASPS contain requirements for TIS-B in a link
independent manner. The purpose of this section of Appendix D is to provide additional
guidance on implementing ground processing for TIS-B service on 1090 MHz.
D.3.2 Ground Determination of Extended Squitter Equipage

The normal mode of TIS-B operation on 1090 MHz is to transmit traffic information only
for targets that are not equipped with Extended Squitter. It is therefore necessary for
TIS-B ground processing to determine which aircraft are Extended Squitter equipped.
Mode S transponders are equipped to provide a data link capability report in response to
an interrogation from a Mode S ground radar. This data link report contains a bit flag to
indicate if the transponder is equipped for Extended Squitter. However, this bit flag is
not a reliable indicator of actual Extended Squitter operation. The bit flag is a static
indication of the capability of the transponder support for Extended Squitter formats and
protocols. It would not reflect the loss of extended quitter operation due to a malfunction
of the transponder or to the navigation input.
The recommended technique for determining active Extended Squitter operation is to

monitor 1090 MHz for Extended Squitter reception in an omni directional fashion. The
most convenient way to implement this monitoring is to equip the 1090 MHz TIS-B
ground stations to receive as well as transmit. This approach will also provide Extended
Squitter determination for aircraft equipped with non-transponder devices.
D.3.3 Ground Radar Data Considerations

Wherever possible, the ground radar data used as the basis for TIS-B service should be
based upon Mode S surveillance. The availability of ground surveillance data identified
with the aircraft 24-bit address for Mode S equipped aircraft significantly enhances the
correlation of ground surveillance data with received Extended Squitters. If an ATCRBS
radar is used as the basis for TIS-B service, correlation between the ground radar data and
the received Extended Squitters must be based only on position and altitude since Mode
A code is not provided by any of the ADS-B systems.
D.3.4 TIS-B Format Selection

Two types of formats are defined for TIS-B on 1090 MHz:
1. Fine Formats
The fine TIS-B formats are similar to those used for Extended Squitter ADS-B operation.
These formats are intended for use with surveillance data that is the same quality as that
used for ADS-B. Examples of such data quality are surveillance inputs obtained by
monitoring other ADS-B links, or a ground-based multilateration system.
20xx, RTCA, Inc.

Appendix D
Page D - 22
The following fine TIS-B format types are defined:
Airborne Position
Airborne Velocity
Surface Position
Identification and Category
2. Coarse Format
The coarse format combines both position and velocity data into a single message. It is
intended for use with surveillance data sources that are not accurate enough to warrant
the use of the fine formats. The principal example is surveillance data derived from a
scanning beam ground radar.
D.3.5 Ground Architecture
D.3.5.1 Overview
Because of the limited range and geometry of a single ground station, a network of
ground transmitting stations will be required. Each station will have associated with it
two types of coverage. One is the radio coverage of the transmitted signal. The radio
coverage volume is the airspace that can be usefully reached by signal from the ground
station. The other type of coverage is the service coverage. This is the geometric scope
of responsibility that the ground station assumes for the TIS-B broadcast. The service
coverage is, by definition, a subset of the radio coverage.
The TIS-B service area could be composed of a number of hexagonal cells. Each cell
defines the area of service for the TIS-B transmitter located in the center of that cell.
Overlap (or buffer zone) at cell boundaries only needs to be large enough to ensure
continuity of service across the cell boundary. A minimum service overlap between
adjacent cells is desirable in order to eliminate unnecessary duplicate TIS-B
transmissions. Since TIS-B aircraft position reports are expected to be reasonably
accurate in order to provide useful service, a buffer zone of 2 NM is assumed at cell
boundaries.
A description of a typical TIS-B cell is presented in Figure D-9.
20xx, RTCA, Inc.

Appendix D
Page D - 23
Figure D-9: TIS-B Cell Characteristics
D.3.5.2 TIS-B Cell Size Considerations

The cell size has an important role in determining TIS-B operating characteristics. A
Smaller cell size is desirable for the following reasons:
1. A reduced maximum transmission range increases the probability of squitter

reception.
2. A smaller cell contains fewer aircraft. This lowers the cell transmission rate and thus
reduces the hot spot effect.
3. Due to earth curvature effects, a shorter operating range results in better low altitude
coverage.
20xx, RTCA, Inc.

Appendix D
Page D - 24
20xx, RTCA, Inc.

Appendix E
Air-to-Air Range as Limited by Power


Appendix E
Page E - 3
E Air-to-Air Range as Limited by Power

The requirements for transmitter power and receiver sensitivity are different for the
different avionics classes. These requirements, given in 2.2, can be summarized as
follows.
Table E-1: Summary of Transmitter and Receiver Requirements
Avionics Transmitter Power MTL

Class (dBm at antenna) (dBm at antenna)
A0 48.5 to 57 -72 or lower
A1 51 to 57 -79 or lower
A2 51 to 57 -79 or lower
MTL(90%) = -84 or lower
A3 53 to 57
MTL(15%) = -87 or lower
As a result of these differences, the maximum air-to-air range differs from class to class.
Following are the values of air-to-air range as limited by these power level requirements.
In other words, these are the air-to-air ranges in an interference-free environment. These
results apply to a receiving aircraft having the worst-case value of MTL for that class,
and they apply to 95 percent of transmitting aircraft whose transmitter power levels are
characterized by the models described in Appendix P. Aircraft antenna gains for both
transmitting aircraft and receiving aircraft are characterized by the TLAT antenna-gain
model (ref., Technical Link Assessment Report, Appendix D, RTCA Free Flight Select
Committee, Eurocontrol ADS Programme, March 2001). For Class A0 and Class A1S,
the results apply to a single bottom mounted antenna. For the other classes, the results
apply to top-bottom antenna diversity.
Table E-2: Air-to-Air Range as Limited by Power
Avionics Classes Air-to-Air Range

(NM)
A0 to A0 10
A1S to A1 47
A1S to A2 47
A1S to A3 75
A1 to A1 66
A2 to A2 66
A3 to A3 140
20xx, RTCA, Inc.


Appendix F
MASPS Compliance Matrix


Appendix F
Page F-3
F. MASPS Compliance Matrix
F.1 Introduction
In previous versions of this document, Appendix F, in Section F.2, contained a traceability
matrix mapping the compliance of these MOPS with all requirements specified in the ADS-B
MASPS (RTCA DO-242/DO-242A). A similar traceability matrix was also produced for
RTCA DO-282A, Minimum Operational Performance Standards (MOPS) for the Universal
Access Transceiver (UAT) Automatic Dependent Surveillance Broadcast (ADS-B). These
traceability matrices permitted both ADS-B link MOPS to be assessed as to their compliance
with the ADS-B system requirements specified in the ADS-B MASPS.
F.2 ADS-B MASPS Compliance Matrix

The development of revised MOPS, for both UAT and 1090ES, has been performed in direct
support of FAA and EASA rulemaking for ADS-B equipage, without first revising the ADS-
B MASPS. Agreed-to changes which necessitate changes to ADS-B system requirements
and are not merely link implementation specific have been documented in a series of Issue
Papers maintained within RTCA Special Committee 186. These Issue Papers will serve as
the basis for a future revision of the ADS-B MASPS (presumably RTCA DO-242B). At the
time of publication of these MOPS, it is planned that part of any future revision of the ADS-B
MASPS will include a matrix listing all MASPS requirements and mapping the
corresponding requirement(s) from the current versions of both the UAT and 1090ES ADS-B
link MOPS to the updated MASPS requirements.
F.3 Traffic Information Services Broadcast (TIS-B) MASPS Compliance

TIS-B complements the operation of ADS-B by providing ground-to-air broadcast of
surveillance data on aircraft that are not equipped for 1090 MHz ADS-B. The basis for this
ground surveillance data may be an ATC Mode S radar, a surface or approach multilateration
system or a multi-sensor data processing system. The TIS-B ground-to-air transmissions use
the same signal formats as 1090 MHz ADS-B and can therefore be accepted by a 1090 MHz
ADS-B receiver.
While the TIS-B MASPS were not completed at the time of the publication of these MOPS, it
is anticipated that these MOPS will meet all of the requirements that flow down from the TIS-
B MASPS.
2009, RTCA, Inc.

Appendix F
Page F-4
2009, RTCA, Inc.

Appendix G
1090 MHz ADS-B Transition Issues for Avionics


Appendix G
Page G - 3
G 1090 MHz ADS-B Transition Issues for Avionics
G.1 Introduction
The objective of the 1090 MHz ADS-B System is to provide a real-time operational data
interface between aircraft and ground vehicle user systems, and with ground-based Air
Traffic System (ATS) controllers and automation. As a new technology component of
operational systems, ADS-B will be introduced on an incremental basis to gain
operational experience with the technology and to validate both the ADS-B delivery
system and the implementation of applications that use ADS-B reports.
While this document addresses only the ADS-B equipment and its interfaces, ADS-B
design and performance requirements must anticipate that applications, substantively
supported by ADS-B reports, will be expected to provide users reliable, safe situational
awareness and an acceptable basis for IFR operational procedures. Upon validation of
ADS-B report and report delivery performance, ADS-B is intended to become a key
component of systems used for the separation of aircraft.
This Appendix addresses transition issues for ADS-B avionics. ADS-B transition
strategy and the evolution of ADS-B implementation within ATS ground systems and
automation are discussed in Appendix D.
G.2 Air-to-Air ADS-B Applications

Initial demonstration of acceptable ADS-B performance and validation of acceptable
designs of operator interfaces are likely to be based primarily upon air-to-air applications.
Such applications identified for demonstration and potential early operational
implementation include improved visual acquisition under VFR conditions, improved
terminal operations in low visibility conditions, enhanced operations for en route and
oceanic phases of flight, improved separation assurance in non-radar airspace, and
parallel approaches to closely spaced runways under IFR conditions. ADS-B equipment
implementations in air transport class platforms during this initial period are anticipated
to take advantage of existing Mode S and TCAS avionics and will be integrated into
airframes using existing on-board data busses and infrastructure. Other initial ADS-B
implementations are likely to be optimized toward targeted initial applications
expandability of these implementations will be a key factor as the transition to ADS-B
progresses. Implementation of the reception of Flight Information Service-Broadcast
(FIS-B) and Traffic Information Service-Broadcast (TIS-B) information within ADS-B
avionics may be considered.
G.3 Aircraft Integration

This document addresses both standalone implementations of ADS-B equipment and
implementations integrated into existing aircraft configurations based on Mode S
transponders and TCAS/ACAS equipment. Other aircraft integration issues include
interfaces (e.g., to Flight Management Systems and GPS navigation equipment) to obtain
source data for ADS-B messages. Separation of functions, specific interdependencies,
hardware/software partitioning and failure detection/mitigation requirements must ensure
the integrity, availability, and reliability of all functions to the extent necessary for the
multiple services supported. Furthermore, as the NAS transitions to the use of GNSS,
with appropriate augmentations for particular phases of operation, the ADS-B equipment
20xx, RTCA, Inc.
Appendix G
Page G - 4
should be able to use upgraded source data without the ADS-B equipment itself requiring
retrofit.
1090 MHz technology is supported by U.S. and international standards specifically for
ATS surveillance and separation services. Additionally, the technology is central to the
collision avoidance function TCAS/ACAS now required for many commercial operators
to provide an independent supplement to the ground-based ATS system. Implementation
of 1090 MHz ADS-B data delivery capabilities will be facilitated through application and
adaptation of existing standards and equipment to the maximum extent consistent with
the ADS-B MASPS, RTCA DO-242A, in providing for air-to-air and air-to-ground
situational awareness and separation support capabilities.
G.4 Air-Ground Surveillance Applications

For ground-based surveillance applications, initial validation of ADS-B will be
supported, where possible, using the existing ground surveillance infrastructure. For
example, it is intended that 1090 MHz ADS-B messages may be correlated against
Secondary Surveillance Radars (SSRs) and enhancements made to those radars to support
distribution of ADS-B information to appropriate ground-based systems. Further,
transponder-based ADS-B implementations in aircraft are likely to be polled by SSRs
when the ground-based surveillance systems require further data: such ADS-B
implementations will need to support this interrogation.
G.5 Operational Approvals

It is recognized that data provided via ADS-B will be used in applications that will be
evaluated on an end-to-end basis for each intended use. Approval of specific operational
use will be predicated on the results of an analysis of the total systems involved. Data
availability, reliability, and integrity will be a significant factor in these approvals. As
operational experience with ADS-B is achieved, it is anticipated that application-specific
standards will be developed to facilitate operational approvals.
20xx, RTCA, Inc.

Appendix H
Report Assembly Guidance


Appendix H
Page H - 3
H Report Assembly Guidance
H.1 Scope and Purpose

This Appendix is provided as a guide to the implementation of the Report Assembly
Function in an ADS-B Receiving Subsystem. The actual requirements on the Report
Assembly Function are to be found in Section 2 of this MOPS, particularly subsections
2.2.8 and 2.2.10. This Appendix is provided as a narrative guide to those requirements
and to how they might be met.
H.2 Data Flow Into and Out Of the Report Assembly Function
See Figure H-1, which is a copy of Figure 2-15 from Section 2 of this document. The
Report Assembly Function takes ADS-B Messages after they have been received and
corrected for possible bit errors by the Message Input Processing. From these messages
it composes ADS-B reports and delivers those reports to the report output storage buffer,
from which they can be retrieved by the user application. The actual interface between
the report output storage buffer and the ADS-B user application is beyond the scope of
these MOPS.
ADS-B MOPs
Boundary
Application
Report
Control
Report Report Report Output

Message Report Data
ADS-B ADS-B Output to Application
Input Assembly
Messages Reports Storage Application Interface Interface
Processing Function
Buffer Interface Control
Specified by the
Specified by the
ADS-B / Application
ADS-B MOPs
Interface Specification
Figure H-1: ADS-B Message and Report General Data Flow.
H.2.1 Optional Report Control Interface

The dashed-line arrow in Figure H-1 represents an optional Report Control Interface by
which an application may configure the output of the Report Assembly Function for its
particular needs. The requirements on this optional interface have not been specified in
this document. This interface, if present, might be used in the following ways.
a. The Report Control Interface could let the application specify for which ADS-B
Participants it desires to receive reports, and for which participants it does not require
reports. For instance, an application might specify, via the Report Control Interface,
20xx, RTCA, Inc.

Appendix H
Page H - 4
that it does not require reports for aircraft that are more than 50 nautical miles away
from the own-ship. Again, the application might use the Report Control Interface to
specify that it does not require reports concerning targets that are above (or below) a
specified altitude.
b. The Report Control Interface could let the application specify, for specific targets,
which report data elements are required and which may be omitted. For example, a
Paired Approach application (as in RTCA DO-242A, D.1.14) would require more
information about the target with which the own-ship is paired for the approach than
the a concurrently running Aid To Visual Acquisition application would require for
other nearby ADS-B Participants.
H.2.2 Type 1 and Type 2 Report Assembly Functions

The concept of Type 1 and Type 2 Report Assembly Functions, as described in 2.2.6,
subparagraphs b and c, is similar to, but not quite the same as, that of the optional
report control interface.
A Type 2 Report Assembly Function has the full functionality. That is, it is capable
of meeting all Report Assembly Function requirements. If a Report Control Interface
is provided, then the user application may use that interface to throttle back the
Report Assembly Function, causing it to provide fewer report elements for some or
all of the targets.
A Type 1 Report Assembly Function has reduced functionality customized for a

particular set of user applications. Although the outputs of a Type 1 Report
Assembly Function are similar to those of a Type 2 function with a Report Control
Interface, in the case of the Type 1 function it has already been statically pre-
configured to meet the specific needs of a particular user application or set of
applications.
H.2.3 TIS-B Report Assembly Function

The requirements for the generation of TIS-B reports are provided in 2.2.17.4.6. These
MOPS do not specify the reporting format for TIS-B reports. However, the information
content is specified by 2.2.17.4.6. The generation of TIS-B reports is substantially less
complex than ADS-B report generation since in the former case the report elements,
except for position and Time of Applicability, are directly mapped from the TIS-B
message contents. The remainder of this Appendix deals only with the ADS-B report
generation function.
20xx, RTCA, Inc.

Appendix H
Page H - 5
H.3 Messages and Reports
H.3.1 ADS-B Messages (Input Data for Report Assembly)

Table H-1 lists the types of ADS-B Messages that may be received and used when
assembling ADS-B reports.
Table H-1: 1090 MHz ADS-B Message Types

Message Reference
Type Section
ADS-B Airborne Position 2.2.3.2.3
ADS-B Surface Position 2.2.3.2.4
ADS-B Aircraft Identification and Category 2.2.3.2.5
ADS-B Airborne Velocity Message 2.2.3.2.6
Target State and Status 2.2.3.2.7.1
Aircraft Operational Status 2.2.3.2.7.2
Extended Squitter Aircraft Status 2.2.3.2.7.8
H.3.2 ADS-B Reports (Data Delivered By Report Assembly Function)
H.3.2.1 State Vector Reports

Table H-2 lists the fields in State Vector (SV) Reports and the sources of the data in those
fields.
The SV Report contains three different Times of Applicability (TOA): TOA-P, TOA-V,
and TOA-R. The third column of Table H-2 indicates for each SV Report element,
which of these three times of applicability is the TOA for that report element. In a
minimum system, in which the Report Assembly Function outputs SV Reports only when
a position or velocity message is received, TOA-R, the Time of Applicability of the SV
Report, would always be either TOA-P or TOA-V, the Time of Applicability of the
position or velocity message which triggered the outputting of that report. In a more-
than-minimum system that outputs SV Reports at additional times, the TOA of the report,
TOA-R, may differ from either TOA-P or TOA-V. For Aircraft/Vehicles on the airport
surface, both position and velocity related information are conveyed within the Surface
Position Messages (2.2.3.2.4). Therefore the TOA for the SV Report elements
associated with both position and velocity information are listed in Table H-2 as TOA-P.
20xx, RTCA, Inc.

Appendix H
Page H - 6
Table H-2: State Vector Report Data

Item # State Vector Report Subfield TOA Obtained From
0a Report Type TOA R Report Assembly Function
0b Report Structure TOA R Report Assembly Function
0c Validity Flags TOA R Report Assembly Function
1 Participant Address TOA R All message types AA subfield
Aircraft Identification and Category Message and
2 Address Qualifier TOA R for all message types received from non-
transponder devices (i.e.., DF=18) the CF subfield
Report Time of Applicability
3 (Position and Velocity) (see Provided by Report Assembly Function
note 4)
Encoded Latitude Airborne Position Message or
4 TOA P
(WGS-84) Surface Position Message
Encoded Longitude Airborne Position Message or
5 TOA P
(WGS-84) Surface Position Message
Altitude, Geometric (see note 1)
6 TOA R Computed by Report Assembly Function
(WGS-84)
7 North / South Velocity TOA V Airborne Velocity Message
8 East / West Velocity TOA V Airborne Velocity Message
9 Ground Speed while on the Surface TOA P Surface Position Message
10 Heading while on the Surface TOA P Surface Position Message
Altitude, Barometric
11 TOA P Airborne Position Message
(Pressure Altitude)
Vertical Rate, Geometric/Barometric
12 TOA V Airborne Velocity Message
(WGS-84)
Airborne Position Message or
13 Navigation Integrity Category (NIC) TOA P
Surface Position Message
14 Estimated Latitude (WGS-84) TOA R Estimate Computed by Report Assembly Function
15 Estimated Longitude (WGS-84) TOA R Estimate Computed by Report Assembly Function
16 Estimated North/South Velocity TOA R Estimate Computed by Report Assembly Function
17 Estimated East/West Velocity TOA R Estimate Computed by Report Assembly Function
Surveillance Status/Discretes (see Airborne Position and Airborne Velocity
18 TOA R
note 3) Messages
19 Report Mode TOA R Report Assembly Function
Notes:
1. The Geometric Altitude must be computed by the Report Assembly Function, using the
barometric pressure altitude from the Airborne Position Message and the difference between
barometric and geometric altitudes from the Airborne Velocity Message. H.4.3 below
describes one acceptable computation method.
2. The Airspeed and Magnetic Heading values are only available from Airborne Participants that
are not providing information about their velocities over the ground. Normally, an Airborne
Participant would emit Subtype 1 or Subtype 2 Airborne Position Messages, which do
provide the N/S and E/W components of its velocity over the ground. But, if velocity over the
ground were not available, an Airborne Participant could emit Subtype 3 or Subtype 4
Velocity Messages, that contain Airspeed and Heading fields.
3. The Surveillance Status/Discretes includes elements mapped from both the Airborne Position
and the Airborne Velocity Messages. See 2.2.8.1.21 for details.
20xx, RTCA, Inc.
Appendix H
Page H - 7
4. The Report Time of Applicability field, as defined in 2.2.8.1.4, contains three separate data
sub-elements for reporting the Time of Applicability (TOA) for: TOA-R for the estimated
position and estimate velocity information; TOA-P the position information; and TOA-V for the
velocity information.
5. For details of the fields in SV Reports, see 2.2.8.1 of this document and subsections of that
section.
H.3.2.2 Mode Status Reports

Table H-3 lists the fields in Mode Status (MS) Reports and the sources of the data in
those fields.
Table H-3: Mode Status Report Data

Item # Mode Status Report Subfield Obtained From
0a Report Type Report Assembly Function
0b Report Structure Report Assembly Function
0c Validity Flags Report Assembly Function
1 Participant Address All Message Types AA Field
Aircraft Identification and Category
Message and for Aircraft Operational
2 Address Qualifier Status Messages received from Non-
Transponder Devices (i.e.., DF=18) the
CF subfield
3 Time of Applicability Report Assembly Function
4 ADS-B Version Aircraft Operational Status Message
5a Call Sign
Message
5b Emitter Category
Message
5c A/V Length and Width Codes Aircraft Operational Status Message
Extended Squitter Status Message
6 Emergency/Priority Status
Subtype 1
Aircraft Operational Status Message
7 Capability Codes
and- Target State and Status Message
Aircraft Operational Status Message
8 Operational Mode
and- Target State and Status Message
Aircraft Operational Status Message or-
9a SV Quality - NACP
9b SV Quality - NACV Airborne Velocity Message
9c SV Quality SIL
9d SV Quality GVA Aircraft Operational Status Message
9e SV Quality NICBARO
10a Track/Heading and HRD Aircraft Operational Status Message
10b Vertical Rate Type Airborne Velocity Message
11 Other (Reserved) N/A
20xx, RTCA, Inc.

Appendix H
Page H - 8
Notes:
1. Certain message parameters are conveyed within both the Aircraft

Operational Status Message and also within the Target State and Status
Message. In this case the Mode Status Report will use the most recently
received message that contains the required data element (i.e., source will be
either the Aircraft Operational Status Message OR the Target State and
Status Message. In the case of the Capability Codes and Operational Mode
parameters, the Target State and Status Message conveys only a subset of the
codes conveyed by the Aircraft Operational Status Message. For this case
the Mode Status Report will report the codes always using data from the
Aircraft Operational Status Message for those codes only reported in this
message type. For the case where the same codes are conveyed in both
message types, then the most recently received message will be used for
Report Assembly. Thus when both message types are being received a
combination of data extracted from the Aircraft Operational Status Message
AND the Target State and Status Message may be required to fully report the
most current Capability Codes and Operational Status.
2. For details of the fields in Mode Status Reports, see 2.2.8.2 of this
document and subsections of that section.
20xx, RTCA, Inc.

Appendix H
Page H - 9
H.3.2.3 Target State Reports

Table H-4 lists the fields in Target State Reports and the sources of the data in those
fields.
Table H-4: Target State Report Data

Item # TS Report Subfield Obtained From
1 Participant Address Report Assembly Function
2 Address Qualifier All Message Types AA Field
Aircraft Identification and
Category Message and for Target
3 Report Time of Applicability State and Status Messages received
from Non-Transponder Devices
(i.e.., DF=18) the CF subfield
Horizontal Intent: Horizontal Data
4a Available & Horizontal Target Source Target State and Status Message
Indicator
Horizontal Intent: Target Heading or
4b Target State and Status Message
Track Angle
Horizontal Intent: Target Heading/Track
4c Target State and Status Message
Indicator
4d N/A
Heading/Track Capability
Horizontal Intent: Horizontal Mode
4e Target State and Status Message
Indicator
4f N/A
Horizontal Conformance
Vertical Intent: Vertical Data Available
5a Target State and Status Message
& Vertical Target Source Indicator
5b Vertical Intent: Target Altitude Target State and Status Message
5c Vertical Intent: Target Altitude Type Target State and Status Message
Vertical Intent: Target Altitude
5d Target State and Status Message
Capability
5e Vertical Intent: Vertical Mode Indicator Target State and Status Message
Vertical Intent: Reserved for Vertical
5f N/A
Conformance
Note: For details of the fields in Target State Reports, see 2.2.8.3.1 of this document
and subsections of that section.
20xx, RTCA, Inc.

Appendix H
Page H - 10
H.3.2.4 Air Reference Velocity Reports

Table H-5 lists the fields in Air Referenced Velocity (ARV) Reports and the sources of
the data in those fields.
Table H-5: Air Referenced Velocity Report Data

Item # TS Report Subfield Obtained From
0c Validity Flags
1 Participant Address Report Assembly Function
Airborne Velocity Message
2 Address Qualifier
Subtype 3 or 4 AA Field
3 Report Time of Applicability
Subtype 3 or 4
4a Airspeed
Subtype 3 or 4
4b Airspeed Type
Subtype 3
5 Heading While Airborne
Subtype 3
Note: For details of the fields in Air Referenced Velocity Reports, see 2.2.8.3.2 of this
document and subsections of that section.
H.4 Estimating Report Field Values

Notice from Table H-2 in H.3.2.1 above that not all of the information required in the
fields of a State Vector (SV) Report is received in the same type of message. Indeed,
some SV Report elements, such the Geometric Altitude, can only be computed by
combining information from more than one type of 1090 MHz ADS-B Message.
Notice also that Estimated Latitude, Estimated Longitude, Estimated N/S Velocity,
and Estimated E/W Velocity fields, SV Report items #14 to #17, all have TOA-R as
their Times of Applicability. These fields together present an estimate of the horizontal
position and horizontal velocity that is time-registered to the same Time of Applicability.
The Report Assembly Function must estimate the values of the horizontal position
(latitude and longitude) SV Report elements at TOA-R, the Time of Applicability of the
report, based on the data received in Position and Velocity Messages that are received at
different times. At the option of the implementer, the SV Report may also contain
estimated horizontal velocity fields that are applicable at TOA-R. This estimation may
be implemented in a variety of ways, such as by alpha-beta filters, alpha-beta-gamma
filters, Kalman filters, or linear extrapolation. The following subparagraphs discuss the
estimation of some of the SV Report field elements in a little more detail.
20xx, RTCA, Inc.

Appendix H
Page H - 11
H.4.1 Estimating Horizontal Position (Latitude and Longitude)

SV Report elements #14 and #15, Estimated Latitude and Estimated Longitude,
contain the position of the ADS-B Participant at the Time of Applicability of the SV
Report (TOA-R, a sub-element of SV item #3). For an Airborne Participant, the Report
Assembly Function must estimate the horizontal position of that participant at the Time
of Applicability of the Report (TOA-R) based on the values it has received in Airborne
Position and Airborne Velocity Messages from that ADS-B Participant.
As Figure H-2 illustrates, at most latitudes everywhere except in very close proximity
to the N or S pole the change in latitude, , and the change in longitude, , due to the
own-ship moving for a short time t with East-West velocity component dx/dt and North-
South velocity component dy/dt may be approximated by the formulas
dx
x t R cos
dt
dy
y t R
dt
where R is the radius of the sphere used to represent the earth and latitude, , and
longitude, are expressed in radians.
20xx, RTCA, Inc.

Appendix H
Page H - 12
R cos
R cos
y=R
x = (R cos
Figure H-2: Expressing a Small Change in Latitude and Longitude ( , )

As a Change in Local Cartesian Coordinates (x,y).
If the radius R of the sphere used to represent the earth is chosen so that one minute of arc
on a meridian one minute of latitude is one nautical mile, and the velocities VNS and
VEW are expressed in knots (nautical miles per hour), and the changes in latitude and in
longitude are expressed in degrees, then the formulas become
VNS t sec onds

Latitudedeg rees
3600
VEW t sec onds
Longitudedeg rees
3600 cos Latitude
This approximation is adequate for extrapolating the position of an ADS-B Participant

forward in time over an interval t of a few seconds.
For the case when the target position is very close to the North or South pole, however,
where the cosine of the latitude approaches zero, the above approximation is inadequate.
Figure H-3 shows the situation for an ADS-B Participant that is in close proximity to the
pole. As Figure H-3 shows, for such a situation the latitude-longitude graticule is no
longer adequately represented by a rectangular grid. If ADS-B Receiving Subsystem is
to be used in aircraft that travels over the poles, the position-extrapolation algorithm used
20xx, RTCA, Inc.

Appendix H
Page H - 13
in that equipment should be designed to handle the situation shown in Figure H-3.
Implementers should take particular care when the (North or South) own-ship latitude
exceeds 89 degrees.
y
(grid north)
N or S pole
A+VA t = (XA+(VA)x t, YA+(VA)Y t)

(participant's future position)
(vA)y
(vA)x
A = (XA, YA)
(participant's present position)
x
origin of local grid (grid east)
coordinate system
Figure H-3: Non-Rectangular Latitude/Longitude Graticule Near the Poles.
H.4.2 Estimating Horizontal Velocity

State Vector Report elements #7 and #8, North/South Velocity and East/West
Velocity, contain the horizontal velocity of an airborne ADS-B Participant as received
in the most recent Airborne Velocity Message from that ADS-B Participant. The Time of
Applicability of these Report elements is the Time of Applicability of that most recent
Airborne Velocity Message (TOA-V, a sub-element of SV item #3), so no estimation or
extrapolation is required.
Likewise, SV Report elements #9 and #10, Ground Speed and Heading While on the
Surface contain the horizontal velocity of a surface ADS-B Participant as received in the
Movement and Heading fields of the most recent Surface Position Message from that
20xx, RTCA, Inc.
Appendix H
Page H - 14
ADS-B Participant. The Time of Applicability of these Report elements is the Time of
Applicability of that Surface Position Message (TOA-P, a sub-element of SV item #3), so
no estimation or extrapolation is required; the E/W and N/S south components of the
Estimated Velocity are merely computed by converting the velocity from polar form
(Ground Speed and Heading) to rectangular form (E/W and N/S velocity).
However, SV Report elements #16 and #17, Estimated North/South Velocity and
Estimated East/West Velocity contain the participants horizontal velocity at time
TOA-R, the Time of Applicability of the SV Report, which may not be the same as the
Time of Applicability of the most recent Velocity Message. These Report elements are
optional at the discretion of the implementer (see 2.2.8.1.19 and 2.2.8.1.20). If these
Report elements are provided, the estimation may be done in a variety of ways, including
linear extrapolation, alpha-beta or alpha-beta-gamma filters, and Kalman filters.
Appendix K discusses the results of simulation studies for some of these methods.
H.4.3 Computing Geometric Altitude (Height Above WGS-84 Ellipsoid)

If an Airborne Position Message from a particular ADS-B Participant has TYPE Code 20,
21, or 22, then the altitude field in that message contains the geometric altitude (Height
Above WGS-84 Ellipsoid) for that ADS-B Participant at the Time of Applicability of that
Message. But SV Report element #6, geometric altitude is the altitude at TOA-R, the
Time of Applicability of the SV Report, not the Time of Applicability of the Airborne
Position Message. The ADS-B Report Assembly Function must compute the geometric
altitude, h, at the Time of Applicability of the Report, tR = TOA-R. This could be done by
linear extrapolation, by an alpha-beta filter, alpha-beta-gamma-filter, or Kalman filter.
Most Airborne Position Messages, however, will have TYPE Codes in the range from 9
to 18, indicating that their altitude fields contain barometric pressure altitude, HP, rather
than the geometric altitude, h. It is still possible for the Report Assembly Function to
estimate a value for SV element #6, geometric altitude, at the Time of Applicability of the
SV Report, tR = TOA-R. One way to do this would be by linear extrapolation, using
HP(tP), the pressure altitude from the most recently received Airborne Position
Message,
Diff(tV), the difference of geometric altitude from pressure altitude, from the most
recently received Airborne Velocity Message, and
dHP/dt or dh/dt, the vertical rate from the most recently received Airborne Velocity
Message.
Let:
HP(tP) = barometric pressure altitude from the most recent Airborne Position
Message, for which the Time of Applicability is tP = TOA-P,
Diff(t) = h(t) HP(t) = difference between geometric altitude, h, and barometric
pressure altitude, HP, as a function of time, t, and
h(tR) = geometric altitude, h, at the time of validity, tR = TOA-R, of the SV
Report
20xx, RTCA, Inc.

Appendix H
Page H - 15
Then h(tR), the geometric altitude at the Time of Applicability of the SV Report, could be
estimated as follows:
h tR H P tR Diff t R
dH p d
H P tP tR tP Diff tV t R tV h HP
dt dt
If the rate of change of the difference, Diff = h HP, is small, it might be ignored, so that
the final term in the above formula, (tR-tV)d(h-HP)/dt is omitted. It would probably be
appropriate, however, to track Diff = (h-HP) as received in successive Airborne Velocity
Messages. The tracking filter, which might be an alpha-beta filter, an alpha-beta-gamma
filter, or a Kalman filter, could then provide an estimate of the rate of change, d(h-HP)/dt.
H.5 Tracking ADS-B Participants

The ADS-B Report Assembly Function must assemble reports giving the status of
multiple ADS-B Participants. With respect to each such Participant, the Report
Assembly Function transitions between several states, as specified in 2.2.10.
When the first message from a Participant is received, the Report Assembly Function
enters Initialization State with respect to that participant. It assigns a block of memory
to hold messages from that Participant.
When both even and odd Airborne Position or Surface Position Messages have been
received from the Participant, so that an unambiguous decoding of the Participants CPR-
encoded position into latitude and longitude can be performed, the Report Assembly
Function enters Acquisition State with respect to that Participant and begins to output
SV Reports for that Participant into the Report Output Storage Buffer. The Report
Mode field in those reports (SV item #19) is set to indicate Acquisition Mode.
When both an unambiguously decoded position and a velocity have been received for the
participant, the Report Assembly Function enters Track State for that participant, and
begins to output SV Reports in which the Report Mode field is set to Track.
H.6 Track Acquisition and Coast Considerations

State Vector update intervals of 3 (three) seconds are required (1 second desired) by the
ADS-B MASPS for short range surveillance applications. Long range airspace
deconfliction applications, on the other hand, can be supported by state vector update
intervals of 12 seconds or longer dependent on range. Track files must be initiated and
maintained on all ADS-B Participants of interest to the supported applications, while the
different applications are likely to have different target acquisition and track maintenance
needs.
Recognizing this, this document requires the ADS-B Report Assembly Function to retain
information on an ADS-B System Participant for at least 200 seconds when the Report
Assembly Function is in Acquisition or Track state with respect to that participant.
The information provided in the State Vector Reports (i.e., separate times of applicability
for velocity, position, and estimated (i.e. time-registered) position and velocity
information), combined with the fact that ADS-B Reports are not required to be
20xx, RTCA, Inc.

Appendix H
Page H - 16
generated for an ADS-B Participant unless a new ADS-B Message has been received
from that Participant, gives the following characteristics to a minimum system:
Information may be associated with and retained for an ADS-B Participant longer
than required for the particular applications serviced by the ADS-B Receiving
Subsystem.
The ADS-B application has the information required for it to make all necessary
determinations on coasting, dropping, etc., of an ADS-B System Participant.
Acquisition/reacquisition time for ADS-B System Participants is reduced.
ADS-B implementations which output ADS-B Reports for a System Participant without
receiving a new ADS-B Message from that Participant contain a separate Time of
Applicability for the extrapolated State Vector information. By comparing the various
Times of Applicability in the SV Report, the application will be able to determine the risk
of error in the extrapolated ADS-B Report.
20xx, RTCA, Inc.

Appendix I
Extended Squitter Enhanced Reception Techniques


Appendix I
Page I - 3
I Extended Squitter Enhanced Reception Techniques
I.1 Purpose and Scope

The purpose of this Appendix is to provide a description of improved squitter reception
techniques. Elements of improved squitter reception include (1) the use of amplitude to
improve bit and confidence declaration accuracy, (2) more capable error
detection/correction algorithms, (3) more selective preamble detection approaches, and
(4) combinations of the above.
The improved techniques presented in this Appendix represent one way of achieving the
performance requirements specified in 2.2.4.4 for enhanced squitter reception. The
squitter processing configuration used as the basis for these performance requirements is
specified in I.5.
The reception techniques, as required in 2.2.4.3.4 of these MOPS, are also described in
this appendix for comparison with the enhancements.
I.2 Background
Squitter reception includes the detection of the Mode S 1090 MHz waveform preamble,
declaration of the bit and confidence values, error detection, and (if necessary) error
correction. The current techniques for squitter reception are based upon techniques
developed for use in Mode S narrow-beam interrogators and for TCAS. In both of these
applications, the rate of Mode A/C FRUIT (see glossary) that is stronger than the Mode S
waveform is relatively low, nominally less than 4,000 FRUIT per second.
Early applications investigated for Extended Squitter, prior to the development of this
document, included long range air-ground surveillance, surface surveillance and support
for TCAS. Of these three applications, the only one with the potential for operating in
significantly higher FRUIT environments was the air-ground application. For this
application, it is possible to use sectorized antennas (6 to 12 sectors) to limit the amount
of FRUIT detected by any receiver.
Extended Squitter applications have now been defined in DO-242A, including long range
(up to 90 NM) air-air surveillance in support of free flight. This type of surveillance is
referred to as Cockpit Display of Traffic Information (CDTI). For this application,
sectorized antennas are not an option. In high-density environments, it is possible to
operate with FRUIT rates of 40,000 FRUIT per second and higher.
Even with these FRUIT rates, Extended Squitter reception using current techniques will
provide useful performance. However, operation of Extended Squitter in very high Mode
A/C FRUIT environments has led to the development of improved squitter reception
techniques to support long range CDTI in high-density environments.
I.3 Current Squitter Reception Techniques

Receiving systems for Mode S replies and squitters are currently implemented
operationally in ground based Mode S interrogator/receiver systems and in TCAS
avionics. For TCAS, the current reception techniques are defined in DO-185B. These
20xx, RTCA, Inc.

Appendix I
Page I - 4
current reception techniques are the basis for the reception requirements in these MOPS
(section 2.2). The enhanced techniques that are the subject of this Appendix are not
required in this version of the MOPS, but are planned to be required in a future version.
I.3.1 Overview of Current Techniques

Extended squitter uses the 112-bit Mode S waveform shown in Figure I-1. Other than bit
assignments, this is the same as the long reply waveform currently used operationally for
air-ground replies and for air-air coordination messages in TCAS. This waveform
encodes data using pulse position modulation (PPM). A chip in the leading half of the bit
position represents a binary ONE. A chip in the trailing half bit position represents a
binary ZERO. Reception of the Squitter begins with the detection of the four-pulse
preamble. At preamble detection a dynamic threshold is set 6 dB below the level of the
preamble. Any signal received below this threshold will not be seen by the squitter
reception processor. This eliminates the effect of low level Mode A/C and Mode S
FRUIT on the reception process.
Figure I-1: Mode S Extended Squitter Waveform
Once all of the bits have been received, error detection is performed using the 24-bit CRC
contained in the PI field. If no error is detected, the squitter is passed on to surveillance
processing. If an error is detected (indicated by a non-zero error syndrome) an error
correction technique is applied. The current error correction algorithm can correct the
errors caused by one stronger overlapping Mode A/C FRUIT.
I.3.2 Current Techniques for Bit and Confidence Declaration

Currently, bit values are declared by comparing the amplitudes of the centers of the two
chips; the chip with the greater amplitude is declared the bit value. This amplitude
comparison technique limits bit errors caused by FRUIT of lower level than the squitter
being received (Figure I-2, parts a and b).
20xx, RTCA, Inc.

Appendix I
Page I - 5
a. Pure signal
1 1 0 0 1 0
b. Signal plus weaker interference current techniques

CE NTER SAMP LE COMPA RE inte rfe rence
decoded a s 1 (corre ct)

c. Signal plus stronger interference current techniques
THRESHOLD
decoded a s 0 (e rror)
flagged a s low confide nce
inconsiste nt
d. Use of amplitude (enhancement) consiste nt a mplitude
a mplitude
preambl e 3 dB
decoded a s 1 (corre ct)
e. Multiple sample technique (enhancement)
preambl e 3 dB
10 sa mples / s
Figure I-2: Current and Enhanced Bit Demodulation Techniques
Note: The vertical scale represents log video signals.
20xx, RTCA, Inc.

Appendix I
Page I - 6
Currently confidence for each bit is declared by observing if signals are above threshold
on both chips. If only one chip is above threshold, it is declared to be high confidence
since there is no evidence of overlapping FRUIT. If both chips have amplitude above
threshold, low confidence is declared since some form of interference had to be present to
cause this condition (Figure I-2, part c).
Since the nominal width of a Mode A/C pulse is 0.45 microsecond, an interfering Mode
A/C pulse can affect only 1 of the 2 chips of a Mode S bit position. If the chip affected is
the one with the Mode S pulse, the level of the pulse in the chip will be altered, but since
it is the only chip with energy, the bit will be declared as high confidence. If instead the
interfering pulse affects the blank chip, pulses will exist in both positions and the Mode S
bit will be declared as low confidence. Since the bit decision is based on the larger pulse,
if the Mode A/C FRUIT is stronger than the Mode S signal, any such bit will be declared
in error, while if the Mode S signal is stronger, any such bit will be declared correctly.
I.3.3 Current Error Detection and Correction Techniques
I.3.3.1 Overview
When a Mode A/C FRUIT interferes with a Mode S Extended Squitter, some of the
Mode S bits may be declared in error. The current Mode S error correction algorithm
attempts to correct these errors by locating a string of 24 consecutive bits such that the
low confidence bits in the window cover the bits in the corresponding error syndrome
[reference I-1]. If such a window is found, all low confidence bits matching the
syndrome are flipped, and the message is declared correct.
I.3.3.2 Sliding Window Technique

This algorithm operates by examining successive 24 bit windows, starting with bits 89-
112 of the message. In order to achieve a successful error correction, each message bit in
the window corresponding to a one (1) in the error syndrome must have its value
complemented (i.e., a one is changed to a zero (0) and a zero is changed to a one). This
complementing can only be done if each of the bits is declared to be low confidence. If
so, each of the bits is complemented and the message is declared to be error corrected. If
not, the window is shifted one bit downward, a transformed syndrome is computed and
the process repeats. The process ends when a correctable error pattern has been found, or
the sliding window reaches the beginning of the message. In order to control undetected
errors, correction is not attempted if there are more than 12 low confidence bits in the
window.
This technique provides error correction in cases where a Mode S message has been
overlaid with one stronger Mode A/C FRUIT (that caused all bit errors) and one or more
weaker Mode A/C FRUIT that were above the dynamic threshold (and caused only low
confidence bits). This technique is well suited to the low levels of Mode A/C FRUIT
observed in a narrow-beam Mode S interrogator or a TCAS. This technique is not
appropriate for high FRUIT rate environments since it produces a high undetected error
rate; for this reason, its use is prohibited in 2.2.4.4.
20xx, RTCA, Inc.

Appendix I
Page I - 7
I.4 Enhanced Squitter Reception Techniques
I.4.1 Enhanced Preamble Detection

Preamble detection identifies the beginning of an Extended Squitter reception. The
process has two outputs: (1) the start time of the signal and (2) the received power level
of this signal. This process includes validation that uses the receptions during the first 5
bits in the data block and several other validation tests. Following is a description of a
particular enhanced preamble detection technique that has been used successfully in
achieving the performance required in these MOPS.
I.4.1.1 Log Video Samples

The preamble detection process described here operates on data in the form of samples of
the log video received waveform. Specifically, the sample rate is 10 samples per
microsecond, although other sample rates, including 8 samples per microsecond, have
been found to be effective. In developing these enhanced decoding techniques, both an 8
MHz and 10 MHz sampling rate implementation were tested. It was determined that the
10 MHz sampling rate yielded better reception performance. In general, a higher
sampling rate will perform better because of more samples for bit and confidence
decoding. For these MOPS, the 10 MHz sampling rate implementation was used to
establish the reception performance required for Class A3 equipment, and the 8 MHz
sampling rate implementation was used to set the required performance for the Class A2
equipment.
I.4.1.2 Threshold
The preamble detection process includes a threshold power level used to discard very
weak receptions. Typical value = -88 dBm (referred to the antenna) for an A3 receiver.
The Minimum Triggering Level (MTL), which is the point of 90 percent receptions in the
absence of interference, is typically about 4 dB higher than the threshold.
I.4.1.3 Valid Pulse Position

A sample that is above threshold and also is followed consecutively by N or more
samples above threshold is defined to be a "Valid Pulse Position." If the sample rate is
10 per microsecond, then N = 3. This definition has the effect of defining a pulse as an
event in which at least 4 consecutive samples are above threshold. For other sample
rates, N is adjusted so that a pulse is declared when the signal is above threshold for more
than 0.3 microseconds.
I.4.1.4 Leading Edge

A Leading Edge is declared for a particular sample if it is a Valid Pulse Position and also
has substantial slope in the interval before this sample and less than substantial slope in
the next interval. Substantial slope is defined by the power change between one sample
and the next. The slope threshold is 48 dB per microsecond (applicable to receiver
bandwidth of approximately 8 MHz). Therefore if the sample rate is 10 samples per
microsecond, the threshold is 4.8 dB.
20xx, RTCA, Inc.

Appendix I
Page I - 8
I.4.1.5 Initial Detection of a 4-Pulse Preamble

The preamble detection process begins when four pulses have been detected, having the
spacing of the Mode S preamble. The detection criterion is:
Finding four pulses having timing of 0 - 1.0 - 3.5 - 4.5 microsecond
Two or more of these must be Leading Edges.
The others can be Valid Pulse Positions
Sample tolerance can be plus or minus 1 (but not both)
Note that the power levels in the four pulses need not agree. Note also that trailing edges
are not used.
I.4.1.6 Arrival Time

The signal arrival time is initially estimated to be the leading edge of the first of these
four pulses. Subsequently this is adjusted by +1 or -1 sample if two or more of the other
three pulses have leading edges with that timing.
I.4.1.7 Reference Level Generation

A Reference Power Level is generated during preamble detection for use in re-triggering
and during demodulation of the data block. Step 1 is to identify a set of samples to use.
Among the four preamble pulses, those whose leading edges agree with the preamble
timing are used; samples from the other pulses are not used. Next, for each pulse used,
select the M samples after the leading edge sample. If the sample rate is 10 per
microsecond, then M = 3. For other sample rates, the value of M is equal to the value of
N defined in I.4.1.3.
Step 2 is an algorithm to generate the Reference Level from these samples. For each
sample, compute the number of other samples that are within 2 dB. Then find the
maximum of these counts. If the maximum count is unique, then the sample used to form
that count is taken to be the Reference Level.
Otherwise, when there are two or more samples whose counts are maximum and equal,
discard any samples whose counts are less than this maximum. For the remaining
samples, find the minimum power and then discard any samples that are more than 2 dB
stronger than that minimum. Compute the average of the remaining samples. This is
taken to be the Reference Level for the preamble.
I.4.1.8 Overlapping Signals and Re-Triggering

The preamble detection process is capable of processing multiple overlapped preambles,
but the data block processing, which is more extensive, can only accept one signal at a
time. For this reason, a re-triggering function is included. This function will reject
certain preamble detections when a subsequent stronger signal is received.
One step in the re-triggering process checks for overlap by later Mode S signals having
certain specific timing offsets. For example, if the subsequent signal is 1 microsecond
later, then two of the preamble pulses in the later signal coincide with preamble pulses in
the original signal, which can cause a problem if the later signal is stronger. The
20xx, RTCA, Inc.

Appendix I
Page I - 9
potential problem is that the stronger pulses can cause the power estimate for the first
signal to be too high, and therefore prevent re-triggering. This type of problem can also
occur if the timing difference is 3.5 or 4.5 microseconds. Figure I-3 illustrates the 1
microsecond overlap that motivates this test.
later preamble
0 4 8 12
earlier preamble
Figure I-3: Overlap of a Weak Signal by a Later and Stronger Signal
1-Microsecond Test. To counter this potential problem, the next step after preamble
detection is to check for excessive power in pulse positions 1.0, 2.0, 4.5, and 5.5
microseconds after the start. For each of these pulse positions, one sample is used to
estimate the power of a pulse at that time. Letting T = 0 denote the time one sample after
the leading edge time of the first preamble pulse, then the four pulses are taken to be the
samples at times T = 1.0, 2.0, 4.5, and 5.5 microseconds. From these four power
measurements, the minimum is used to compare against the maximum of the samples at T
= 0 and 3.5 microseconds. If this difference indicates that the preamble under
consideration is -3 dB or weaker relative to the other four samples, then this preamble is
rejected.
3.5-microsecond test. A similar test is performed to protect against overlap by a stronger

signal 3.5 microseconds later. The minimum power in samples at T = 3.5, 4.5, 7.0, and
8.0 is compared against the maximum of the samples at T = 0 and 1.0 microseconds. If
this difference indicates that the preamble under consideration is -3 dB or weaker relative
to the other four samples, then this preamble is rejected.
4.5-microsecond test. A similar test is performed to protect against overlap by a stronger

signal 4.5 microseconds later. The minimum power in samples at T = 4.5, 5.5, 8.0, and
9.0 microseconds is compared against the maximum of the samples at T = 0, 1.0, and 3.5
microseconds. If this difference indicates that the preamble under consideration is -3 dB
or weaker relative to the other four samples, then this preamble is rejected.
I.4.1.9 Consistent Power Test

Another test is applied to validate the preamble. This test asks whether at least two of the
four preamble pulses agree in power level with the Reference Level to within +/-3 dB. If
not, this preamble is rejected.
20xx, RTCA, Inc.

Appendix I
Page I - 10
I.4.1.10 DF Validation
An additional validation is made using the first five bits in the data block. Each of the
five bits is considered to consist of two chips, each of duration 0.5 microseconds. Pulse
detection is carried out for the 10 chips as follows. For a particular chip, a pulse is
detected if a Valid Pulse Position is found at the leading edge time for this chip or within
+/-1 sample of the leading edge time. The preamble is then validated if, for each of these
five bits, a pulse is detected either in the first chip or in the second chip or both and the
peak amplitude of the pulse is equal to 6 dB below the preamble reference level or
greater. Otherwise the preamble is rejected. The peak amplitude is determined by using
the highest amplitude sample of the M samples that comprise the pulse (where M = N + 1
for N as defined in I.4.1.3).
I.4.1.11 Re-Triggering
After a preamble is detected, the preamble detection process continues to be applied
searching for later preambles. All of the steps described above are applied even when
detected preambles are overlapped. If a particular preamble detection has survived these
tests, its reference level and the amplitude of each of the five data pulses during DF
validation is now compared against any earlier signal currently being processed. If the
new signal is stronger by 3 dB or more, then the earlier signal is rejected, so that data
block demodulation of the new signal can proceed. Otherwise (if an earlier signal is
being processed and the new signal is not stronger by 3 dB or more), the new signal is
rejected, so that the earlier signal processing can continue.
20xx, RTCA, Inc.

Appendix I
Page I - 11
I.4.1.12 Preamble Detection Summary

Figure I-4 summarizes the preamble detection process.
Outputs:
Pulse detection Leading edges
Valid Pulse Positions
Outputs:
4-pulse detection Preamble detection
Time
Output:
Ref. level generation Reference Level
Mode S - Mode S
validations
1 s test
Consistent power? DF validation
Do at least 2 of the 4
3.5 s test preamble pulses agree within
Uses DMTL, 6 dB
+/- 3 dB with the Ref. Level? below the ref. level
4.5 s test Output:

Output:
Reject certain preambles Reject certain
preambles
Output:
Reject certain preambles
Pass all validations?
Output:
Retriggering Reject certain preambles
Figure I-4: Overview of Extended Squitter Preamble Detection
20xx, RTCA, Inc.

Appendix I
Page I - 12
I.4.2 Enhanced Bit and Confidence Declaration
I.4.2.1 Overview
The current technique of declaring a bit based upon the higher of the two chips will
generate bit errors in cases of higher level overlapping Mode A/C FRUIT (Figure I-2,
part c). The use of amplitude to correlate the received pulse with the preamble pulse
level will improve bit declaration accuracy. Four techniques have been investigated.
One is a very simple approach that uses only the amplitude measured at the center of each
chip. The remaining three use a more capable approach that takes advantage of all
samples per chip that are taken to establish bit and confidence. Each of these techniques
is described in the following paragraphs.
The following description of the center sample technique is intended to provide an

example of processing performance needed to meet the requirements of Class A1S and
A1 equipment. This description also serves as an introduction to the three more capable
approaches. The center sample technique will not provide sufficient performance to meet
requirements specified for Class A2 and A3 equipment in the test procedures of 2.4.4.4.
The specified performance for these latter classes of equipment can only be met by an
approach that performs equivalently to one of the multi-sample techniques.
I.4.2.2 Use of Center Amplitude

An improvement in the declaration of Mode S data bits can be achieved if the actual
amplitudes of the center samples of the '1' and '0' chips can be measured for each data
position, rather than just a comparison of which chip sample is greater. All Mode S
pulses, including those of the preamble, have approximately the same level (within 1 or 2
dB). Thus if the preamble level is measured, the expected level of each data pulse will be
known. Then if both center samples of a data position are above threshold, but only one
is within a 3 dB band centered at the preamble level, it would be reasonable to assume
that the corresponding chip is the correct Mode S pulse location. This is illustrated in
Figure I-2, part d.
Figure I-5 illustrates the new data and confidence declaration algorithms that result when
the actual sample amplitudes can be measured, and both samples are above threshold. As
shown in Figure I-5, a bit is high confidence when 1 and only 1 of the two samples
correlate with the preamble level. The correlating sample, rather than the larger sample,
is declared to be the true data value. If both samples, or neither sample, correlates with
the preamble, a low confidence bit is declared. In this case, the larger sample is selected
as the bit value, as in the current technique.
20xx, RTCA, Inc.

Appendix I
Page I - 13
bit = 1
a. One in window confidence = high
Preamble 3 dB
bit = 1
b. One in window confidence = high
Preamble 3 dB
bit = 0
c. Neither in window, second larger confidence = low
Preamble 3 dB
bit = 0
d. Both in window, second larger confidence = low
Preamble 3 dB
Figure I-5: Center Amplitude Bit and Confidence Declaration
The major advantage of this scheme is the significant reduction in low confidence and bit
errors generated for the Mode S message. Presently, any data position with both samples
above threshold is declared low confidence. This translates to a low confidence
declaration whenever an above-threshold Mode A/C FRUIT overlaps a Mode S empty
20xx, RTCA, Inc.

Appendix I
Page I - 14
chip position. If the Mode A/C signal is of greater power, the bit position is declared in
error.
With the center amplitude technique, a low confidence bit is declared only when the
Mode A/C FRUIT is within 3 dB of the Mode S signal. Mode A/C FRUIT of either
lower or higher power in general cause neither errors nor low confidence bits. Thus the
region of concern for Mode A/C aircraft is reduced from all the aircraft at closer range to
just those at approximately co-range. This is particularly significant when the system is
attempting to listen to far-range Mode S aircraft.
It is occasionally possible for this new algorithm to produce high confidence bit errors.
The most likely case occurs when two Mode A/C pulses overlay the same Mode S bit
position. If one overlaps the data pulse, and drives its sample out of the preamble
window, then an error will result if the other Mode A/C pulse lands on the other chip and
its amplitude is within the preamble window. Such occurrences will in general create a
rejected message, rather than an undetected error.
I.4.2.3 Use of Multiple Amplitude Samples

The above amplitude data declaration approach can be improved if all 10 samples (5 per
chip) that are taken for each Mode S bit position are utilized in the decision process. In
particular, the event of both center samples within the preamble window can often be
resolved. For example, consider the typical such situation depicted in Figure I-2, part e.
Although both center samples are within the window, the fact that the earlier chip has all
samples within the window, whereas the later chip has several samples below the window
suggests that the signal is present in the earlier chip. This error situation can often be
rectified when all 10 samples are examined. Also, in some cases when an interference
pulse overlaps a signal pulse, the small frequency difference will produce variations in
amplitude, whereas the signal by itself would be more constant, and such patterns can be
useful in declaring the bit and confidence.
I.4.2.3.1 Baseline Multi-Sample Technique

The multi-sample enhanced bit and confidence declaration technique makes use of all 10
samples for each Mode S bit position to determine the bit and confidence values. Sample
amplitudes in each chip are compared to the amplitude reference level established by the
preamble to quantify the number of samples in each chip that:
(a) match the preamble amplitude indicating the presence of a pulse, or
(b) are significantly lower in amplitude indicating a lack of transmitted energy.
The first step is to establish an amplitude window that will include samples that are
within +/- 3 dB of the preamble reference level and a minimum amplitude threshold set to
6 dB below the reference level. Samples that fall within the window are considered to
match the preamble and samples that are below the minimum threshold are considered to
indicate a lack of transmitted energy. The samples are categorized as follows:
A: within the +/- 3 dB preamble window
B: below threshold (6 dB or more below the preamble)
20xx, RTCA, Inc.

Appendix I
Page I - 15
The second step is to count the number of samples in each chip that are of each category.
Less weight is given to the samples near the transitional areas of each chip (the
transitional samples are the first and last samples of each chip). To facilitate this,
samples other than those at each end will count double. Therefore, with weighting
factored in, and a 10 MHz sampling rate, the counts for each category will range from 0
to 8 for each chip (1 sample at each end + 3 samples in-between x 2). The four counts
are summarized as follows:
1ChipTypeA = #of weighted samples in the 1 chip of type A (Match Preamble)
1ChipTypeB = #of weighted samples in the 1 chip of type B (Lack energy)
0ChipTypeA = #of weighted samples in the 0 chip of type A (Match Preamble)
0ChipTypeB = #of weighted samples in the 0 chip of type B (Lack Energy)
Next, two equations using the above counts will produce two scores that indicate how
well the sample pattern matches a transmitted 0 and how well the sample pattern matches
a transmitted 1. The equations are as follows:
1Score = 1ChipTypeA 0ChipTypeA + 0ChipTypeB 1ChipTypeB
0Score = 0ChipTypeA 1ChipTypeA + 1ChipTypeB 0ChipTypeB
The highest score determines the bit value. In the case of a tie, the bit defaults to zero
(0). If the difference is 3 or more the bit is high confidence. The confidence threshold of
3 was determined by testing the algorithm with a 10 MHz sampling rate with thousands
of iterations with a high FRUIT rate. If the algorithm is applied with a different sampling
rate, the appropriate confidence threshold may need to be determined under similar test
conditions.
I.4.2.3.2 Multi-Sample Technique With Full Table Lookup

To take advantage of the differences between a pure signal and a combination of signal
plus interference, a technique was developed based on a lookup table, whose contents are
derived from many runs of a simulation. Specifically, each of the 10 samples is
quantized into four levels:
0: below threshold (-6 dB relative to the preamble)
1: above threshold but below the +/- 3 dB preamble window
2: within the +/- 3 dB preamble window
3: above the +/- 3 dB preamble window
Since there are 10 samples, with 4 possible values each, a Mode S data position can have
410 = 1048576 (1M) different sample patterns. Two 1-bit tables, each stored in a 1M x 1
ROM, are defined over the set of patterns: the first declaring the bit position to be a '1' or
20xx, RTCA, Inc.

Appendix I
Page I - 16
'0', the second high or low confidence. Once the pattern existing for a given bit is
determined, two table lookups supply the proper declaration. If higher sampling rates are
used, the number of sample patterns and the table size will increase exponentially.
These tables are generated by running millions of simulations of Mode S messages in

40,000 FRUIT per second environments. For each bit of each trial, the pattern and the
correct Mode S bit value are noted. The result could be, for example, 5876 examples of
pattern 16453, of which 5477 occurred when the Mode S bit was a 1. The table values
are then defined as follows, assuming an "uncertainty parameter" value of 10%:
H1: 90% or more of the samples occurred when the bit was a '1'
L1: 50% - 90% of the samples occurred when the bit was a '1'
H0: 10% or fewer of the samples occurred when the bit was a '1'.
Since pulse shapes are critical to this method, live data verification of the table entries is
required to establish these values.
I.4.2.3.3 Multi-Sample Technique With Reduced Table Lookup

The above 10 sample approach requires lookup tables of size 1M, adding cost to the
hardware implementation of the decoder. A variation of this method that only requires
tables of size 1K, called the 5-5 approach, has been designed to reduce this expense.
The 5-5 method forms two estimates of the bit data and confidence values, one using the
odd samples (1-3-5-7-9) and the other using the even samples (2-4-6-8-10); the final
decision is then a combination of the individual estimates. Since each set includes
samples in both chip positions, pattern matching is still possible, although the fineness of
the pattern variation is cut in half. Since only 5 samples are in each set, and each sample
is quantized to the same 4 levels as above, 45 = 1024 patterns are possible for each set.
To counteract the loss of resolution, and to aid in the combining operation, 3 levels of
confidence (high, medium, and low) are defined for each pattern. Following the
simulation generation scheme described above, the table values are defined as follows:
H1: 90% or more of the samples occurred when the bit was a '1'
M1: 70% - 90% of the samples occurred when the bit was a '1'
M0: 10% - 30% of the samples occurred when the bit was a '1'
H0: 10% or fewer of the samples occurred when the bit was a '1'.
20xx, RTCA, Inc.

Appendix I
Page I - 17
The values of 10% and 30% are parameters; the value of 30% was selected to provide the
performance discussed below. Since 3 confidence levels now exist, the confidence
lookup table for each sample set is sized 1024x2. The total table requirement for data
and confidence, for the two sample sets, is thus 1024x6.
Once the values and confidences are determined for each set of samples, odd and even,
the composite values actually declared for the bit are found according to Table I-1.
Table I-1: Combining Odd and Even Outputs

Odd Even
H1 M1 L1 H0 M0 L0
H1 H1 H1 H1 L0 H1 H1
M1 H1 H1 L1 H0 L0 L1
L1 H1 L1 L1 H0 L0 L0
H0 L0 H0 H0 H0 H0 H0
M0 H1 L0 L0 H0 H0 L0
L0 H1 L1 L0 H0 L0 L0
Note that if either sample set is high confidence, that sets data value rules unless the
samples conflict and are both high confidence. Also notice that two agreeing medium
confidence samples produce a high confidence result. With the parameter for medium
confidence set at 30%, the probability of error for medium confidence agreement is 0.3 x
0.3 = 0.1, which matches the 10 sample probability of error for a high confidence
decision. Finally, when the sample decisions conflict at the same confidence level, a low
confidence 0 is declared for lack of a better estimate.
If a sampling rate other than 10 MHz is used, the number of samples from the odd and
even samples and the resulting table sizes will be adjusted accordingly. For example, if a
8 MHz sampling rate is used, there are 4 samples in each set, and each sample is
quantized to the same 4 levels as above, 44 = 256 patterns are possible for each set. The
total table requirement for data and confidence, for the two sample sets, is thus 256x6. If
a 16 MHz sampling rate is used, there are 8 samples in each set, and each sample is
quantized to the same 4 levels as above, 48 = 65,536 (64K) patterns are possible for each
set. The total table requirement for data and confidence, for the two sample sets, is thus
64Kx6. Once the values and confidences are determined for each set of samples, odd and
even, the composite values are declared according to Table I-1 independent of the
sampling rate.
I.4.3 Enhanced Error Detection and Correction Techniques
I.4.3.1 Overview
Three new error detection/correction techniques have been developed. The first, termed
the Conservative technique is a variation on the current Sliding Window technique,
intended to reduce the undetected error rate. The second, termed the Whole Message
technique, models the effect of whole Mode A/C FRUIT on the bit and confidence
declarations. The third, termed the Brute Force technique, performs a bounded
exhaustive search of all combinations of bit reversals for low confidence bits. The
following sections describe these techniques in more detail.
20xx, RTCA, Inc.

Appendix I
Page I - 18
I.4.3.2 Conservative Technique

The sliding window technique is suitable for the low FRUIT environments of a rotating
beam antenna (long range, narrow beam) or a TCAS (omni-directional, short range).
However, the FRUIT environment for the long-range air-to-air application (which uses
omni-directional antennas) may be very severe and therefore, the sliding window
technique cannot be used because of undetected error considerations.
For the very severe FRUIT environments, a simpler approach, known as the conservative
technique is used. Using this technique, error correction is only attempted if all of the
low confidence bits in the message are within a 24-bit window, and there are no more
than 12 low confidence bits. This constraint limits the application of error correction to
signals that nominally had only a single overlapping stronger Mode A/C FRUIT. This is
a conservative approach in that the conditions for attempting error correction are much
more restrictive than with sliding window. It produces a lower level of successful error
correction since it does not attempt to correct messages with multiple Mode A/C
overlaps. However, it produces a very low undetected error rate, as intended.
If the conditions for applying the conservative technique are met, the error syndrome is
generated for the window position and (as for the sliding window technique) a check is
made to see if the ones (1) in the error syndrome correspond to low confidence bits in the
window. If so, error correction is accomplished. If not, the process is terminated.
If the low confidence bits span less than 24-bits, more than one window could be defined
to span them. This will not effect the error correction action, since regardless of the 24-
bit window selected to span the low confidence bits, the ones (1) in the error syndrome
will identify the same message bits. That is, if the window is moved one bit, the error
syndrome will shift by one bit.
Note that in the above description, there is only one possible successful error correction
possibility. Regardless of the specific 24-bit window position, the same message bits are
identified. All of the bits corresponding to a one (1) in the error syndrome must be
complemented. This can only happen if they are all low confidence. Therefore, there is
at most, one correctable error pattern that can be achieved with the conservative error
correction technique.
I.4.3.3 Whole Message Error Detection and Correction Technique

The limitation of the current error correction technique described in I.3.3 of being able to
handle only a single overlapping Mode A/C FRUIT has led to the development of the
Whole Message error correction technique, which can be applied when the Conservative
technique has failed. This technique is designed to handle up to five overlapping FRUIT,
provided they do not overlap each other, hence creating "individual interference regions."
This technique is applicable only when the center sampling technique is used (I.4.2.2).
As described in I.3.2, the correctness of low confidence bits depend upon the amplitude
of the Mode A/C interference relative to the Mode S squitter: if the Mode A/C FRUIT is
stronger than the Mode S signal, any low confidence bit will usually be declared in error,
while if the Mode S signal is stronger, any low confidence bit will usually be declared
correctly. This observation leads to the following hypothesis, which serves as the basis
of the Whole Message error correction routine:
20xx, RTCA, Inc.

Appendix I
Page I - 19
For a given Mode A/C interference region, either all low confidence bits will
be correct, or all low confidence bits will be wrong.
Although this hypothesis is generally correct, it should be noted that three effects can
lead to its violation:
1. If the interfering Mode A/C FRUIT is at approximately the same power level as the
Mode S signal, or
2. If the interfering Mode A/C FRUIT pulses are wider than 0.50 microseconds (the
spec allows up to 0.55 microseconds, and some out-of-spec transponders even go
beyond this value), or
3. If the Mode S signal is near enough to the noise level for noise to corrupt some of the
samples.
The Whole Message algorithm attempts to divide the Mode S message into disjoint 24-bit
regions, one for each presumed Mode A/C interfering FRUIT. Then the syndrome of
each region, assuming all bits to be in error, is generated (see below in I.4.3.4 for an
explanation of syndrome generation for bit sets). Finally, all possible combinations of
syndromes are considered. If one and only one combination matches the Mode S
syndrome, all low confidence bits within the interference regions corresponding to the
winning combination are reversed. Flowcharts for the Whole Message error correction
technique are presented in Figure I-6 and Figure I-7. Figure I-8 presents an example of
the application of this method.
20xx, RTCA, Inc.

Appendix I
Page I - 20
1
Compute
Error
Syndrome
4
2 3
Compute No Yes Accept Message
=0?
Width of Low as Received
Confidence
Region
7 8
No Convolve Compare Syndrome

> 24 Bits Syndrome to Low 1s to Low
Confidence Region Confidence Bits
Yes
6
9
Use New Yes
Match?
Algorithm
No
Correct Reject Message

Corresponding Low
as Being
Confidence Bits and Uncorrectable
Accept Message
Figure I-6: Whole Message Top Level Error Correction Algorithm
20xx, RTCA, Inc.

Appendix I
Page I - 21
1
Bitnum = 0
2
None
Find 1st Low Confidence Bit > Bitnum
4 3
Bitnum += 24 Create New 24-Bit Segment

Starting With That Bit
Compute
Syndrome of
Each Segment
Form Syndromes
of All Segment
Combinations
8
7
No Reject Message as
Any Match? Being Uncorrectable
Yes
Correct All Low Confidence Bits

of All Segments in Matching
Combination and Accept Message
Figure I-7: Whole Message Detailed Error Correction Algorithm
20xx, RTCA, Inc.

Appendix I
Page I - 22
Assume Error Syndrome = B12472
1st FRUIT Region 2nd FRUIT Region 3rd FRUIT Region

Low Conf Bits Low Conf Bits Low Conf Bits
Syndrome S1= Syndrome S2= Syndrome S3=

Hex A128B3 Hex 02FE11 Hex 100CC1
S1 XOR S3 = B12472 = Error Syndrome
Therefore, Invert All Low Confidence Bits in Regions 1 & 3
Figure I-8: Whole Message Error Correction Example
I.4.3.4 Brute Force Error Correction Technique

If the bit declaration algorithm has performed its function properly, all errors in Mode S
data values will reside in bits declared low confidence. If this is true, a simple approach
to error correction is to try all possible combination of low confidence bits, and accept
the set that matches the error syndrome (provided only one success is discovered). For
obvious reasons, this method has been named the Brute Force Technique. It is applicable
to any method of data and confidence declaration, with or without amplitude. As
illustrated in Figure I-9, Brute Force error correction is applied after the other techniques
have failed.
20xx, RTCA, Inc.

Appendix I
Page I - 23
DEMODULATED
MESSAGE
NO Errors OUTPUT (112 bits)
ERROR DETECTION
(112 information bits
and
112 confidence bits)
YES Message has some errors
CONSERVATIVE NO Errors OUTPUT (112 bits)

ERROR
CORRECTION
YES Message still has some errors
BRUTE FORCE NO Errors OUTPUT (112 bits)

ERROR
CORRECTION
(N=5)
YES Message still has some errors
Discard
Figure I-9: Error Detection and Correction
20xx, RTCA, Inc.

Appendix I
Page I - 24
Implementation of this technique depends upon the fact that each Mode S bit position
corresponds to a unique syndrome, and that sets of bits produce a syndrome that is the
exclusive OR of all individual bit syndromes. For example, if bit 1 is the only bit
declared in error, the error syndrome at the receiver will be hex 3935EA, while bit 31
produces hex FDB444, and bit 111 has syndrome hex 000002. Thus if those three bits
are all declared in error, the error syndrome will be calculated to be hex C481AC. The
table of individual bit syndromes is pre-calculated and stored in the receiver.
It is possible for two or more subsets of the low confidence bits to match the syndrome.
In such cases, the message is rejected, and no harm is done. However, if a high
confidence bit has been declared in error, and a single subset of the low confidence bits
matches the syndrome, the message will be "corrected" to the wrong message, producing
an undetected error. (If no subset matches the syndrome, it must be true that a high
confidence bit error has been made, and the message is rejected.)
Clearly, for processing time and error bounding reasons, the maximum number of low
confidence bits to process must be limited. The number of cases to consider is given by
2n. If n low confidence bits exist for a message; this grows exponentially with n (32 at n
= 5, 4096 at n = 12). The undetected error rate is proportional to the number of cases,
and thus also grows exponentially with n. Fortunately, the Hamming distance of 6 for
the Mode S parity code implies that undetected errors are essentially zero if n</=5 is
enforced. For this reason, a value of n = 5 has been used in the development of the brute
force algorithm.
I.5 Improved Reception Performance in a High Fruit Environment

For improved reception performance in a high FRUIT environment, the optimum
configuration has been found to be:
1. Enhanced preamble detection (I.4.1)
2. Bit and confidence declaration based on the Baseline Multi-sample Technique

(I.4.2.3.1)
3. Error detection using the Mode S 24-bit CRC technique (Ref. RTCA DO-185B)
4. First pass error correction using the conservative technique (I.4.3.2)
5. Second pass error correction using the brute force technique with n=5 (I.4.3.4)
The process proceeds as follows. Preamble detection and bit and confidence declaration
are performed. Next, Mode S error detection is applied. If the message passes, the
process ends, and the message is delivered. If an error is detected, then conservative
error correction is applied, and if a correction results, then the process ends, and the
message is delivered. If the constraint for conservative correction is not satisfied, then
the brute force technique is applied.
The above configuration was used as the basis for the performance required for enhanced
squitter reception as specified in 2.2.4.4.
20xx, RTCA, Inc.

Appendix I
Page I - 25
I.6 Summary
New techniques have been developed for enhancing reception of Extended Squitters in
environments of high interference. The new techniques include improvements in
preamble detection, improvements in declaration of information bits and confidence bits
within the squitter message, and improvements in error detection/correction.
These developments were originally carried out using pulse-level simulation to assess the
resulting performance. Subsequently flight tests have been conducted using these
techniques, making comparisons relative to the current techniques. Both the simulation
and flight test results indicate that substantial improvements in performance are
achievable using these techniques when operating in an environment of high interference.
APPENDIX I REFERENCES
I-1. J. L. Gertz, Fundamentals of Mode S Parity Coding, M I T Lincoln Laboratory Project Report
ATC-117, April 1984.
20xx, RTCA, Inc.

Appendix I
Page I - 26
20xx, RTCA, Inc.

Appendix J
Determining The Navigation Accuracy Category

For Velocity (NACV)


Appendix J
Page J - 3
J Determining the Navigation Accuracy Category for Velocity (NACV)
J.1 Purpose and Scope

This Appendix describes the manner in which GNSS position sources, which do not
output velocity accuracy, can be characterized so that a velocity accuracy value
associated with the position source can be input into ADS-B equipment as part of the
installation process. Section J.4 discusses the expected velocity accuracy performance of
GNSS during stable flight (the NACV is specified in such a manner that it needs to
accommodate velocity errors during normal maneuvers of the aircraft).
J.2 Rationale for Table 2-25, Determining NACV Based on Position Source Declared
Until recently, acceptable means to substantiate a navigation sources capability to
support NACV were not clearly established in Global Positioning System (GPS) sensor
minimum operational performance standards. In light of this deficiency, a best-method
was originally established in 2.2.3.2.6.1.5 of RTCA DO-260A (ADS-B Version Number
= 1) to utilize the HFOM/VFOM quality indicator as a surrogate for setting the NAC V
value. The rationale for this method was documented in Appendix J of DO-260A.
However, the use of HFOM/VFOM to set NACV was not considered acceptable, since it
does not provide an appropriate indication of the true horizontal velocity error as
established by the position sensor manufacturer.
To remedy this deficiency, the FAA requested RTCA SC-159 to develop test procedures
for a velocity accuracy test to characterize the 95% horizontal and 95% vertical velocity
accuracies during normal maneuvers as specified in RTCA/DO-229D and RTCA/DO-
253B receiver MOPS. These tests can be used to substantiate Global Positioning System
(GPS), GPS/Space-Based Augmentation System (SBAS), or GPS/Ground-Based
Augmentation System (GBAS) equipment to support an ADS-B NACV =1 requirement of
horizontal velocity error less than 10 meters/second (95th percentile with HDOP of 1.5 or
less) and vertical velocity error less than 50 feet/second (95th percentile, with VDOP of
3.0 or less). Additional test procedures were developed to substantiate equipment that
supports a NACV =2 requirement of horizontal velocity error less than 3 meters/second
and vertical velocity error less than 15 feet/second. However, these tests are not adequate
for demonstrating more stringent ADS-B NACV levels (i.e., NACV = 3, or greater) such
tests are expected to be developed as more demanding ADS-B applications mature.
Navigation equipment manufacturers can submit the results of this testing with their TSO
application or as additional information if they have already received TSO approval, for
acceptance as approved data. Manufacturers of navigation equipment that pass these tests
should document their equipments 95% figure of merit velocity accuracy in their
installation manual (or provide a velocity accuracy quality metric output for direct use by
the ADS-B equipment.) The velocity output has no explicit integrity beyond the 95%
figure of merit for the stated HDOP and VDOP.
Note: FAA AIR-100 memorandum dated October 10, 2008 serves as an interim
reference describing testing procedures acceptable to the FAA until the
procedures are incorporated into more formal GPS MOPS guidance material.
2009, RTCA, Inc.

Appendix J
Page J - 4
J.3 Tests to Determine Velocity Accuracy for Support Setting NACV = 1 or 2

The ADS-B installations with a position source capable of providing velocity accuracy
should have the NACV derived from the position source, and the velocity accuracy should
be validated during the position source manufacturers certification testing. The
following procedures, developed by RTCA SC-159, are one means of accomplishing this
testing.
The purpose of GNSS velocity accuracy test is to characterize the 95% horizontal and
95% vertical velocity accuracies during normal maneuvers as specified in RTCA/DO-
229D and RTCA/DO-253B receiver MOPS for equipment intended to support either
NACV =1 or NACV = 2. Test procedures for higher levels are expected to be developed
as more demanding ADS-B applications mature.
The tests to verify velocity accuracy performance shall be run for each of the scenarios
described below for all operating modes of the receiver where a valid position and/or
velocity could be output by the receiver.
Note: It is possible that a given receiver may use a different velocity algorithm when
computing an un-augmented GPS position solution versus computing a solution
augmented with differential corrections. In that case, this test must be repeated
for both the augmented and un-augmented modes of operation. Even in the case
where the velocity algorithm is the same whether in un-augmented or augmented
mode, there are still enough variables like the software path, inputs, outputs etc.,
that it is required to repeat the test. However it is not required to repeat the test
for different sub-modes of an un-augmented or augmented mode where the
inputs, velocity algorithm and outputs are the same.
J.3.1 Horizontal Velocity Accuracy Test Conditions Commensurate with NACV = 1

1. Ensure the simulator scenario has enough GPS satellites to provide a HDOP of 1.5 or
less.
2. One satellite shall set at maximum power (including maximum combined satellite
and aircraft antenna gain), and the other satellites shall be set at minimum power
(including minimum antenna gain).
3. Broadband GNSS test noise (IGNSS,Test) of spectral density as defined in DO-229D

accuracy test 2.5.8. Broadband external interference (Iext,test) and thermal noise
contribution from the sky and the antenna (Nsky,antenna) shall be simulated.
4. The airborne equipment shall be initialized with the appropriate position and time. It
is assumed that the receiver has obtained a valid almanac for the simulator scenario to
be tested prior to conducting the test.
5. Platform Dynamics for the horizontal velocity accuracy test shall be as defined in
Table J-1.
2009, RTCA, Inc.

Appendix J
Page J - 5
Table J-1: Platform Dynamics for the Horizontal Velocity Accuracy Test
Time (s) Dynamics Start Jerk (g/s) End Jerk (g/s)
From To North East Down Total North East Down Total

0 T Static 0 0 0 0 0 0 0 0
T+1 T+71 0.58g longitudinal acceleration to 0.xx 0.xx 0 0.25 0.xx 0.xx 0 0.25
411 m/s Note 1 Note 1 Note 1 Note 1
T+72 T+129 Straight un-accelerated flight 0 0 0 0 0 0 0 0
T+130 T+194 -0.45g longitudinal acceleration to 0.xx 0.xx 0 0.2 0.xx 0.xx 0 0.2
125 m/s Note 1 Note 1 Note 1 Note 1
T+255 T+325 turn 180 with 0.58g lateral 0.xx 0.xx 0 0.25 0.xx 0.xx 0 0.25
acceleration Note 1 Note 1 Note 1 Note 1
Notes:
1. The components of the jerk in the North and East direction depend on the heading chosen in the
scenario. The total jerk is the not to exceed vector combination of north, east, and down jerk
components. The maximum total jerk to quickly achieve the desired dynamics should be used, but the
jerk should not exceed the normal maneuver total jerk requirement of 0.25g/s.
2. The actual times may vary based on the simulator scenario control settings.
6. Signal and RF Interference conditions can be modified during static period to aid
acquisition. Ensure the receiver enters the desired Operation mode before dynamics
and appropriate signal and interference conditions are applied.
7. Use the simulator velocity truth data (Vi east_truth, Vi north_truth) and the GNSS receiver
velocity data (Vi east, Vi north) to determine the horizontal velocity error after the
GNSS receiver has entered the desired Navigation mode with the specified signal and
RF Interference conditions:
hi (Vi east _ truth Vi east ) 2 (Vi north _ truth Vi north ) 2
J.3.1.1 Pass/Fail Determination

The 95% Horizontal Velocity accuracy statistic shall be computed using the formula
given below. The equipment shall pass if the statistic is less than 10 m/s.
2
N 1.5 hi
2*
i 1
HDOP i
N
2009, RTCA, Inc.

Appendix J
Page J - 6
Where:
hi is the horizontal velocity error (m/sec)
N Number of sample points used
For this test, the number of samples shall include all samples where the receiver is in the
desired Navigation mode and when in motion.
Note: The minimum of samples is 420 for 1 Hz solution and 2100 for 5 Hz solution
(i.e., 5* 420).
The receiver velocity data and the HFOMV data shall be used to determine the percentage
of samples bounded by the HFOMV as shown below. The test passes only if TSh,b is
greater than or equal to 0.95.
1 N
TS h ,b bh ,i
N i1
N number of samples
1 hi HFOM V
bh ,i
0 hi HFOM V
J.3.1.2 Vertical Velocity Accuracy Test Conditions Commensurate with NACV = 1

1. Ensure the simulator scenario has enough GPS satellites to provide a VDOP of 3.0 or
less.
2. One satellite shall set at maximum power (including maximum combined satellite
and aircraft antenna gain), and the other satellites shall be set at minimum power
(including minimum antenna gain).
3. Broadband GNSS test noise (IGNSS,Test) of spectral density as defined in RTCA DO-
229D accuracy test 2.5.8. Broadband external interference (Iext,test) and thermal
noise contribution from the sky and the antenna (Nsky,antenna) shall be simulated.
4. The airborne equipment shall be initialized with the appropriate position and time. It
is assumed that the receiver has obtained a valid almanac for the simulator scenario to
be tested prior to conducting the test.
5. Platform Dynamics for the vertical velocity accuracy test shall be as defined in Table
J-2.
2009, RTCA, Inc.

Appendix J
Page J - 7
Table J-2: Platform Dynamics for the Vertical Velocity Accuracy Test
Time (s) Dynamics Start Jerk (g/s) End Jerk (g/s)
From To North East Down Total North East Down Total
0 T Static 0 0 0 0 0 0 0 0
T+1 T+71 0.58g longitudinal 0.xx 0.xx 0 0.25 0.xx 0.xx 0 0.25
acceleration to 411 m/s Note 1 Note 1 Note 1 Note
1
T+72 T+130 Straight and level un- 0 0 0 0 0 0 0 0
accelerated flight
T+131 T+131+X Climb, increasing the 0 0 0.xx 0.25 0 0 0.xx 0.25
vertical climb rate from Note 1 Note 1
0 to 21 m/s, then
decrease the rate back
to 0 m/s and repeat this
increasing and
decreasing pattern until
the time out.
T+132+X T+192+X Straight and level un- 0 0 0 0 0 0 0 0
accelerated flight
T+193+X T+193+2X Descend, increasing the 0 0 0.xx 0.25 0 0 0.xx 0.25
vertical descent rate Note 1 Note 1
from 0 to 21 m/s, then
decrease the rate back
to 0 m/s and repeat this
increasing and
decreasing pattern until
the time out.
T+194+2X T+274+2X Straight and level un- 0 0 0 0 0 0 0 0
accelerated flight
Notes:
1. The components of the jerk in the North and East direction depend on the heading chosen in the
scenario. The total jerk is the not to exceed vector combination of north, east, and down jerk
components. The maximum total jerk to quickly achieve the desired dynamics should be used, but the
jerk should not exceed the normal maneuver total jerk requirement of 0.25g/s.
2. The actual times may vary based on the simulator scenario control settings.
3. The value of X must be at least 63 seconds to have enough samples during vertical acceleration.
6. Signal and RF Interference conditions can be modified during static period to aid
acquisition. Ensure the receiver enters the desired Operation mode before dynamics
and appropriate signal and interference conditions are applied.
7. Use the simulator velocity truth data (Vivertical_truth) and the GNSS receiver velocity
data (Vivertical) to determine the vertical velocity error (vi) after the GNSS receiver has
entered the desired Navigation mode with the specified signal and RF Interference
conditions: vi =| Vivertical_truth Vivertical | .
2009, RTCA, Inc.

Appendix J
Page J - 8
J.3.1.3 Pass/Fail Determination

The 95% Vertical Velocity accuracy statistic shall be computed using the formula given
below. The equipment shall be considered pass only if the statistic is less than 50 ft/s.
2
N 3 vi
2*
i 1
VDOP i
N
Where:
vi - is the vertical velocity error (ft/sec)
N Number of sample points used
For this test, the number of samples shall include all samples where the receiver is in the
desired Operation mode.
Note: The minimum of samples is 420 for 1 Hz solution and 2100 for 5 Hz solution.
The receiver velocity data and the VFOMV data shall determine the percentage of
samples bounded by the VFOMV as shown below. The test passes if is greater than or
equal to 0.95.
1 N
TS v ,b bv ,
N i1 i
N number of samples
1 vi VFOM V
bv ,i
0 vi VFOM V
J.3.2 Additional Tests to Demonstrate Accuracy Commensurate with NACV = 2

The following procedure is one acceptable means for equipment capable of better
accuracy performance to demonstrate compliance with the horizontal velocity error
requirement of less than 3 m/s.
1. Run the scenario in Table J-1 with all satellites set at high power and no RF
interference.
2. This accuracy evaluation shall only include those data samples collected during the
acceleration period.
3. Find the particular hi (noted as Tacc) so that 95% of hi samples are less than or equal
to Tacc .
4. Re-run the scenario in Table J-1 with the same satellite and RF interference
conditions as the 10 m/s (NACV=1) test.
2009, RTCA, Inc.

Appendix J
Page J - 9
5. This time only the data samples during the non-acceleration period with the specified
signal and RF Interference conditions are used.
2
N non _ acc
1.5 hi _ non _ acc
i 1 HDOPi _ non _ acc
6. Compute Tnon _ acc 2*
N non _ acc
Where HDOPi_non_acc and Nnon_acc are the HDOP values for each sample i and the total
number of samples (non-acceleration period), respectively.
7. The test passes only if Tacc + Tnon_acc is less than 3 m/s.
8. The velocity FOM is evaluated in the same way as for the 10 m/s test, i.e., the
samples during acceleration and non-acceleration periods of the above 2 runs are
evaluated together against the 0.95 threshold.
The vertical velocity requirement of 15 ft/s should be tested using the exact same
philosophy as the test of 3 m/s above but with the scenario in Table J-2.
J.4 Expected GNSS Velocity Accuracy in Stable Flight

Although NACV will accommodate derived velocity lags at turn rates of up to 0.5g, it
over-bounds by a substantial amount the 95% velocity error of about 0.2 m/s per axis
which should be expected in stable flight1. This conservative bounding of expected GPS
velocity quality has led application designers and simulators to incorrect impressions of
the potential value of the instantaneous velocity provided in the GPS state vector.
Velocity lag errors have long been an issue in the use of ATC automation derived
velocity with radars as the sensor input. Assurance that better velocity is available when
flight dynamics permit is obtained by separately specifying acceptable ATC tracker
errors for stable and turning tracks. The STARS requirement on estimated heading error
is indicated by values in Table Q-3.
Table J-3: Heading Accuracy (RMS degrees)

Speed Stable Flight Transient Tracks
(knots) Heading error Heading error
100 12 51
250 6 30
400 3 31
1
NAVSTAR GPS User Equipment Introduction, 1996, Page 3-7 and Measurement of Aircraft Velocity Using
GPS, Institute of Electronics, Information and Communication Engineers Technical Report, Japan, 2005.
2009, RTCA, Inc.
Appendix J
Page J - 10
Based on experience with GPS, and without requiring changes to the GPS receiver
acceptance test requirements, there seems to be no risk in adding some clarification to the
use of NACV by ATC automation systems indicating that considerably better than the
high turn rate limiting encoded error value should be expected in the normal flight
conditions which apply for the supported application. Normally experienced velocity
errors at the 95th percentile should be on the order of one tenth of the encoded maximum
value, for NACV equal to 1 or 2.
2009, RTCA, Inc.

Appendix K
Velocity Accuracy As Affected By Report Assembly


Appendix K
Page K - 3
K Velocity Accuracy As Affected By Report Assembly
K.1 Purpose
This appendix provides documentation of analyses performed on velocity accuracy of the
Mode S Extended Squitter. This analysis is intended to compare the velocity accuracy
that results from the characteristics of the Extended Squitter against the velocity accuracy
requirements given in the ADS-B MASPS.
K.2 Background
The 1090 MHz Extended Squitter ADS-B system transmits the surveillance state vector
(position, velocity) information in two pieces. In order to form the full state vector some
method of state vector reconstruction must be applied. This may involve filtering the
incoming messages to time register a full state vector, reporting latent data in the state
vector report, or a combination of both.
Two methods of state vector reconstruction are analyzed:
1. After receipt of a position message, update the position half of the state vector report
but do not update velocity. After receipt of a velocity message, update both position
(by extrapolation using the latest velocity data) and velocity (using the most recently
received velocity message). (This is referred to as minimum technique.)
2. After receipt of either a position or velocity message, update both halves of the state
vector report by applying a Kalman filter or other tracking filter. (This is referred to
as Kalman technique.)
This Appendix analyzes the results using these two alternatives. The analysis is
performed in two ways:
1. Use the ADS-B MASPS in a strict sense: Examine velocity errors after each state
vector update.
2. Examine velocity errors once a second regardless of whether an ADS-B Message is

received and an ADS-B State Vector Report is issued.
The analysis below applies to short-range surveillance, for which the nominal
surveillance update period is 3 seconds. A related analysis is provided in Reference K-1,
which applies to longer-range air-to-air surveillance, for which the nominal surveillance
update time is 12 seconds. The results in Reference K-1 are consistent with the results
given in this Appendix.
K.3 Scenarios and Results

To evaluate velocity accuracy, Monte-Carlo simulations of a maneuvering scenario were
run. Statistical results on velocity accuracy were then collected using the scenario shown
in Figure K-1. In this scenario, the aircraft travels at 150 knots, and executes 180 degree
turn with a turn rate of 3 degrees per second. This results in an acceleration of slightly
less than 0.5 g (where g is the acceleration due to gravity), the ADS-B MASPS defined
limit condition for state vector accuracy.
20xx, RTCA, Inc.

Appendix K
Page K - 4
0
-6 0 0 0 -4 0 0 0 -2 0 0 0 0 2000 4000 6000 8000 10000
X (ft)
-2 0 0 0
-4 0 0 0
-6 0 0 0
-8 0 0 0
D ire c t io n o f flig h t
-1 0 0 0 0
Y (ft)
-1 2 0 0 0
Figure K-1: Scenario Geometry Used in the Evaluation
Figure K-2 shows results for velocity errors after each state vector report update. In
addition to the segmented message based results, results for a benchmark full state-vector
message are included. Sending this hypothetical message at an update period of T=3
seconds, and a probability of receipt of 0.95 was simulated. These values correspond
directly to the ADS-B MASPS requirements, from RTCA DO-242A, Table 3-4(a). The
probability of Extended Squitter reception of 0.46 per message used in Figure K-2 was
chosen because it is the minimum probability that assures reception of both a position
message and a velocity message within a 3 second period with 0.95 probability.
It is observed that a benchmark full state vector update meets the ADS-B MASPS
requirements as stated. This is because both position and velocity of the state vector
report are updated with recent information upon receipt of a state vector message. The
only errors introduced in velocity are quantization errors. The simulated quantization
errors were chosen to meet the ADS-B MASPS requirements.
According to a literal interpretation of the ADS-B MASPS, the segmented state vector
does not meet the ADS-B MASPS required accuracy for velocity after each state vector
report update. However, the following analysis shows that state vector reports provided
by the 1090 MHz Extended Squitter system have operational characteristics that conform
to those implied by the ADS-B MASPS. The largest errors are observed when ADS-B
receives position and velocity is not updated. Applying a Kalman filter to the segmented
messages still does not result in compliance with the literal ADS-B MASPS
requirements. With the segmented message set, the velocity portion of the state vector
report lags the actual velocity after receipt of a position message. Without updating
velocity after the receipt of a position message, the velocity is as old as the last velocity
received. Applying a Kalman filter, velocity updates occur whenever a position report is
20xx, RTCA, Inc.

Appendix K
Page K - 5
received, but the resulting velocity estimates still lag the true velocity more than the
MASPS allows.
14
Minimum Technique
Pd = 0.46
12
Velocity Error (x dot) Standard Deviation (ft/s)

10
Kalman Technique
Pd=0.46
8 -
Benchmark Full State Vector 6

T=3 s Pd=0.95
Manuever start
4
MASPS Requirement
2
0
80 70 60 50 40 30 20 10 0
Time to Scenario End (Seconds)
Figure K-2: Velocity Accuracy at Time of Each State Vector Report Update
Figure K-3 illustrates results of sampling the velocity error in 1 second epochs. In this
case the velocity of a benchmark full state vector update with T=3 seconds will lag the
true velocity for several seconds after each update. Since we do not expect ADS-B
applications to synchronize their use of ADS-B data to the message transmission period,
the error analysis shown in Figure K-3 may better represent the error observed by an
ADS-B application than the error analysis shown in Figure K-2.
In a sense, the curve labeled benchmark full state vector in Figure K-3 represents the
effective error observed by an application randomly sampling state vector reports that
meet the letter of the ADS-B MASPS requirement. The benchmark full state vector
curve can be thought of as the intent of the ADS-B MASPS, and ADS-B systems whose
errors fall at or below this curve are meeting the operational intent of the ADS-B
MASPS.
In this context, the squitter velocity accuracy needs reexamination. It is observed in

Figure K-3 that the Extended Squitter state vector report accuracy is better than the
benchmark full state vector curve for required (pd=0.46) detection probabilities, with or
without a Kalman Filter. The benchmark is achieved with a Kalman filter and update
probabilities as low as 0.26, and without a filter and update probabilities as low as 0.38.
20xx, RTCA, Inc.

Appendix K
Page K - 6
35
Minimum Technique
Pd =0.38
30
Kalman Technique
Benchmark Full State Vector
Pd = 0.26
T=3 pd=0.95
Velocity Error (X dot) Mean + 1 Standard Deviation (ft/s)

25
20
-
Minimum Technique
Pd=0.46
15
KalmanTechnique
pd = 0.46
10
0
70 60 50 40 30 20 10 0
Time to End of Scenario (S)
Figure K-3: Velocity Accuracy Sampled at 1 Second Epochs
K.4 A Minimum Report Assembly Technique

Following the requirements of 2.2.8.1, this section describes a minimum implementation
of a state vector report assembly technique.
There are two methods of updating a state vector; one is used when a position report is
received, and the other is used when a velocity measurement is received. For simplicity,
only equations for the x coordinate of a state vector are shown here; an identical process
was used for the y coordinate as well.
Upon receipt of the nth position measurement a state vector is updated as follows:
x (n) xm (n) (4-1)
x (n) x m (k ) (4-2)
where xm (n) is the nth position measurement and x m (k ) is the most recently received
velocity measurement, and x (n), x (n) is the x component of the state vector.
Upon receipt of the mth velocity measurement the state vector is updated as follows:
x (m) x (m 1) dt ( xm )(m) (4-3)
20xx, RTCA, Inc.

Appendix K
Page K - 7
x (m) x m (m) (4-4)

where dt is the time difference between the last measurement and the current
measurement.
K.5 A Kalman Filter Report Assembly Technique

The Kalman filter that was used in this analysis, and may be suitable for implementation
for ADS-B, consists of three independent, two state Kalman filters. The filters state
consists of position and velocity. The state is tracked in each of three orthogonal
Cartesian dimensions (x, y, and z). The state estimates are assumed to be independent in
each of the three dimensions.
Linear dynamics are assumed in each of the three dimensions. The filter takes as input
the measured position or velocity, the previous track state, and the previous track state
covariance. The filter also requires as input the time of the measurement. The filter
produces as output an updated track state and covariance.
The filter, which is identical in all three dimensions, will now be detailed.
K.5.1 Filter State and Covariance

The filter maintains a state consisting of position and velocity and a state covariance
matrix that represents the uncertainty in the state estimate.
The filter state estimate in the x-dimension is represented by the vector: x x . Note
t
that here the variable x is used to show the filter state in one of the three dimensions;
the y and z dimensions have a state and covariance representation which exactly parallels
that of x. The covariance matrix of the state estimate in the x-dimension is represented
by the matrix:
2
x xx
2
xx x
where
2
x represents the variance in the position estimate;
2
x
represents the variance in the velocity estimate;
xx
represents the covariance of position and velocity.
K.5.2 Initial State And Covariance

Before any measurements are received, the state estimates and the state covariance matrix
are initialized. The state estimate is initialized by setting both the position and velocity
estimate to zero. The state covariance matrix is initialized according to equation 5-1:
2
x xx
0
2
(5-1)
xx x
0
20xx, RTCA, Inc.

Appendix K
Page K - 8
For the purposes of an actual implementation, infinity can be represented by a large real
number.
K.5.3 Kalman Filter Steady State Algorithm

The standard Kalman filter consists of five steps:
1. State extrapolation
2. Covariance matrix extrapolation
3. Residual calculation
4. State vector update
5. Covariance matrix update.
The first two steps are identical regardless of whether the measurement is a position,
velocity, or both. The last three steps depend on the form of the measurement.
K.5.3.1 State Extrapolation

The first step in the filter is to extrapolate the state estimates to the time of the current
measurement. Equations 5-2 detail the mechanics of the state extrapolation:
x x x (dt )
(5-2)

x x
where
x is the predicted (extrapolated) x position;

x is the predicted velocity in the x direction;
x is the current position estimate for x;
x is the current velocity estimate in the x direction;
dt is the time difference between the current measurement and the last state
update.
K.5.3.2 Covariance Matrix Extrapolation

The next step in the filtering process is the extrapolation of the covariance matrix.
2 2 2 2 Q(dt ) 4
x x (dt ) x
2dt xx
(5-3)
4
2 2
(dt ) 2 Q (5-4)
x x
2 (dt ) 3 Q
(dt ) (5-5)
xx xx xx x
2
where Q is the process (plant) noise variance.
Typical values are on the order of 0.0025 g2. In our simulations, a second, higher value
was used for Q when the ADS-B message indicated that a turning maneuver was taking
place. The maneuver Q was set at 0.0625 g2.
20xx, RTCA, Inc.

Appendix K
Page K - 9
K.5.3.3 Track Residual, Filter Gain, Track Smoothing, and Covariance Update Calculations
The next three steps in the Kalman filter involve calculating the covariance of the
measurement residual, calculating the filter gain, and updating the track state covariance
estimate.
These calculations are dependent on the exact form of the measurement, and therefore
differ depending on whether the received measurement is position or a velocity.
K.5.3.3.1 Residual Variance, Gain, Track Smoothing, and Covariance Update for Position
Measurement
If the received measurement contains position information only, the filter gain is a two
element vector and is calculated as shown below.
First, the residual (or innovations) variance is calculated:

2 2 2
(5-6)
v x xm
where
2
xm is the variance of the position measurement.
The gain vector (w) is then calculated according to equations (5-7) and (5-8):
2
x
w0 2
(5-7)
v

xx
w1 2
(5-8)
v
The update of the state estimate is performed according to equations (5-9) and (5-10):
x x w0 ( xm x ) (5-9)

x x w1 ( xm x ) (5-10)
where
xm is the current position measurement.
The update of the covariance matrix is then performed according to equations 5-11, 5-12,
and 5-13:
2 2
x
(1 w0 ) x
(5-11)
xx
(1 w0 ) (5-12)
xx
2 2
x w1 (5-13)
x xx
20xx, RTCA, Inc.

Appendix K
Page K - 10
The update of the state and covariance completes the Kalman filter operations for the
current measurement.
K.5.3.3.2 Residual Variance, Gain, Track Smoothing, and Covariance Update for Velocity
Measurement
In the case of a velocity measurement, the residual is the difference between the velocity
prediction and the velocity measurement; the residual variance is then:
2 2 2
v xm (5-14)
x
where
2
xm is the variance of the velocity measurement.
The filter gain vector is then calculated as shown below:
xx
w0 2
(5-15)
v
2

x
w1 2
(5-16)
v
The track state is then updated through use of the velocity residual:

x x w0 ( x m x ) (5-17)

x x w1 ( x m x ) (5-18)
Finally, the track state covariance is updated as per equations 5-19 through 5-21:
2 2
x x
w0 (5-19)
xx
xx
(1 w1 ) (5-20)
xx
2 2
x
(1 w1 ) (5-21)
x
K.6 Real Time Performance Evaluation

The Kalman filters described above were implemented in ANSI C, compiled using the
Metrowerks CodeWarrior compiler with full optimization, and bench-marked on two
Macintosh machines. The two machines were the Macintosh Power PC 7500 running at
100 MHz and a Macintosh Quadra running at 33 MHz. The Power PC uses the Motorola
601 processor; the Quadra uses a Motorola 68040 processing chip. Table K-1 shows the
average run times for a position and velocity Kalman filter update measured on these
machines using the CodeWarrior profiler. Run times on more recent processors should
be appreciably smaller.
20xx, RTCA, Inc.

Appendix K
Page K - 11
Table K-1: Run Time For Kalman Filter Update
Measurement Type Power PC (100 MHz) Quadra (33 MHz)

Position 2 s 11 s
Velocity 2 s 11 s
K.7 Conclusions
The 1090 MHz Extended Squitter ADS-B implementation, which segments state vectors
into multiple messages, has been shown to meet the operational intent of the ADS-B
MASPS velocity accuracy requirements associated with a 3 second 95% state vector
update period without filtering in regimes where the probability of message reception
after participant acquisition is greater than 0.38. To meet the ADS-B MASPS state
vector update requirements for this scenario, the message reception probability must be
0.46 or higher. Therefore, velocity accuracy has been shown not to be the limiting factor
for meeting the requirements for this scenario. Based on Figure K-3 results, acceptance
tests for report assembly should recognize that user applications can still be supported
with test results meeting the limits articulated in Figure K-2.
Appendix K - References
K-1. 1090 MHz Extended Squitter Assessment Report, June 2002, prepared by the FAA
and the Eurocontrol Experimental Centre. This report is available for download and
review under the following RTCA SC-186 Working Group 3 web link for Agendas,
Minutes and Working Papers, in the table for Meeting 12, identified as Working Paper
1090-WP-12-05: http://adsb.tc.faa.gov/WG3.htm
20xx, RTCA, Inc.

Appendix K
Page K - 12
20xx, RTCA, Inc.

Appendix L
Impact of Radio Frequency Interference

on Extended Squitter Report Integrity


Appendix L
Page L - 3
L Impact of Radio Frequency Interference on Extended Squitter Report Integrity
L.1 Undetected Report Error Rate

ADS-B system integrity is defined in the MASPS (RTCA DO-242A, 3.3.6.5) in terms
of the probability of an undetected error in a report received by an application, given that
the transmitting ADS-B system participant is supplied with correct source data. An
important component of ADS-B integrity is attributable to radio interference, whose
effects are largely controlled by the use of error detection and correction applied upon
reception. Several different techniques for error detection and correction have been
considered, including the techniques currently used in TCAS (defined in the TCAS
MOPS, RTCA DO-185B) and several new techniques, described in Appendix I. The rate
of undetected errors is a key consideration in the development of new techniques,
because of the inherent trade between undetected error rate and reliable acceptance of
signals. Analysis and simulation have been used by two organizations to evaluate
performance in terms of undetected error rate in a number of cases. Results of these
evaluations, carried out for the LAX-99 interference environment, are summarized in
Table L-1 and shown in more detail in Figure L-1. From the results in the table, it has
been concluded that the undetected error rate increases as receiver MTL is reduced, and
that the conservative error correction technique and the enhanced error correction
technique are effective in controlling the error rate. As a result, these MOPS standards
now require conservative error correction or enhanced error correction for all equipment
Classes other than A0. Note, therefore, that some of the rows in Table L-1 are
hypothetical combinations that are not allowed by these MOPS.
Table L-1: Undetected Report Error Rate

Evaluated contribution to undetected
Receiver MTL error rate (per report)
Reception and Error William J. Hughes
(referred MIT Lincoln
Correction Techniques Technical Center,
to antenna) Laboratory
FAA
DO-260 reception techniques
MTL -72 dBm
DO-260 error correction 0.09 x (10-6) 0.08 x (10-6)

MTL -74 dBm

MTL -79 dBm

DO-260 error correction 5 x (10-6) 10.1 x (10-6)

MTL -84 dBm
Conservative error correction
N/A < 0.01 x (10-6)
Enhanced reception techniques

Enhanced error correction
N/A 0.05 x (10-6)
20xx, RTCA, Inc.

Appendix L
Page L - 4
The last row of Table L-1 applies directly to Class A3 equipment, and the first row
applies to Class A0. Because of the higher MTL values in Classes A2, A1 and A1S,
relative to A3, lower error rates are expected, but because of the statistical nature of the
Monte Carlo technique, it was not practical to evaluate these cases directly. The
summary that follows provides error rate bounds for these two classes.
Class A3, error rate is approximately 0.05 x (10-6) per report
Class A2, error rate < 0.05 x (10-6) per report
Class A1S, error rate < 0.05 x (10-6) per report
Class A1, error rate < 0.05 x (10-6) per report
Class A0, error rate is approximately 0.09 x (10-6) per report.
Current reception techniques.

10 0
ACCEPTANCE
ACCEPTANCE AND ERROR RATES
10 -1 Probability of correct reception
10 -2
10 -3
per acceptance UNDETECTED ERRORS

10 -4 Undetected errors
having correct address
10 -5
per transmission
10 -6
10 -7
-90 -85 -80 -75 -70
RECEIVED POWER (dBm)
Figure L-1: Simulation Results Giving Acceptance Probability and Undetected Error Rate.
Based on the results in Table L-1, that show that lower MTL is associated with higher
error rates, a more detailed study was undertaken, producing the results in Figure L-1.
Reception rates are shown here as a function of received power level, giving both
acceptance of valid signals (the upper curve) and undetected errors (the lower curves). A
Monte Carlo simulation was used to obtain these results. The data in Figure L-1 is
limited to the RTCA DO-260 reception techniques, which do not have the benefit of
conservative or enhanced error correction. Otherwise, the error rates are much lower, and
it is more difficult to assess performance using the Monte Carlo technique.
More specifically, the upper curve in Figure L-1 shows the probability of correct signal
acceptance, including the effects of error detection and correction, as a function of
received signal power. The lower curves represent the probability that an undetected
error is received and is reflected in an ADS-B report. Simulation results are shown here
20xx, RTCA, Inc.
Appendix L
Page L - 5
in two forms, normalized to the transmission rate in the lower curve, and normalized to
the reception rate in the middle curve.
The results show a clear trend in which the error rate, expressed either way, degrades as
received signal power decreases. This behavior is consistent with the results in Table L-
1. Together they underscore the need for the additional performance requirement when
receiver MTL is enhanced relative to TCAS receivers.
20xx, RTCA, Inc.

Appendix L
Page L - 6
20xx, RTCA, Inc.

Appendix M
Extended Range Reception Techniques


Appendix M
Page M - 3
M Extended Range Reception Techniques
M.1 Purpose and Scope

The purpose of this Appendix is to provide a description of techniques for extending the
effective air-to-air reception range of 1090 MHz ADS-B systems. Two reception
techniques are explored: (1) use of a directional antenna with an integral low noise
preamplifier for 1090 MHz Extended Squitter reception; (2) optimized 1090 MHz ADS-
B reception employing a reduced bandwidth receiver to provide improved reception
sensitivity under low-to-moderate 1090 MHz fruit conditions. Also the transmission
power for Class A3 airborne installations is discussed.
M.2 Background
The ADS-B MASPS, RTCA DO-242A, specifies the required air-to-air reception range
for a number of ADS-B applications. The one application identified by RTCA DO-242A
with the longest reception range requirement is the Long Range Conflict Management
application. When the requirements of all applications defined by RTCA DO-242A are
considered, the required reception range varies as a function of target bearing from the
receiving aircraft. Specifically as defined in RTCA DO-242A, Note 3 to Table 3-4(a),
the required air-to-air reception range that would be applicable to Class A3 ADS-B
systems is:
90 NM required (120 NM desired) in the forward direction
64 NM required (85 NM desired) +/- 45 degrees of forward direction
45 NM required toward the port and starboard directions
40 NM required (42 NM desired) toward the aft
RTCA DO-242A defines the Long Range Conflict Management (i.e., flight path de-
confliction) application as being applicable to cooperative separation in oceanic/low
density en route airspace. Thus as currently defined by the ADS-B MASPS, this
application is not explicitly required to be supported in moderate to high traffic density
en route or terminal airspace. Currently the most demanding applications applicable to
high density, high interference airspace are associated with separation assurance and
sequencing. RTCA DO-242A only requires air-to-air reception ranges of 40 NM to
support such applications. However, RTCA DO-242A includes similar notes under
Tables 2-8 and 3-4(a) stating that the operational concept and constraints associated
with using ADS-B for separation assurance and sequencing have not been fully validated.
It is possible that longer ranges may be necessary. Also, the minimum range required
may apply even in high interference environments, such as over-flight of high traffic
density terminal areas. The latter statement in this note applies by reference to the Long
Range Conflict Management application.
Additional optimizations in the design of airborne 1090 MHz ADS-B systems may prove
useful in satisfying the air-to-air reception range requirements associated of future ADS-
B applications.
M.3 Current Reception Range

The most capable class of ADS-B receiver specified by these MOPS is for Class A3.
This receiver class is specified to have an MTL of 84 dBm. An A3 class receiver when
20xx, RTCA, Inc.
Appendix M
Page M - 4
used in conjunction with omni-directional diversity aircraft antennas is intended to satisfy

the requirement of RTCA DO-242A for an air-to-air reception range of 90 NM. This
assumes all of the target aircraft of interest at the maximum range are equipped with
Transmitter Class A3 having a transmit power (at the antenna) of 125 watts to 500 watts
(see M.5 below). The 90 NM reception range capability is thus focused on users
operating in high altitude airspace where the most capable class of avionics would be
applicable. Also the Class A3 requirements included in these MOPS that are associated
with a 90 NM reception range were predicated on a low-density airspace with low levels
of RF interference.
M.4 Techniques for Extended Reception Range

The focus of this Appendix is on detailing techniques to provide for extended reception
range (i.e., beyond 90 NM) in the forward direction, especially in low to moderate 1090
MHz fruit environments. Certain of these techniques apply only to receivers and
antennas not shared with TCAS or used for by Mode S transponders for transmissions.
This is a consequence of employing antennas and receiver characteristics that are
optimized specifically for the reception of 1090 MHz Extended Squitters in support of
the ADS-B function. The described techniques for enhanced reception range apply
primarily to Class A3 receivers. Further, these techniques apply specifically to extending
the ADS-B reception range between aircraft operating in high altitude en route or oceanic
airspace. Some of the described techniques are expected to also prove useful in
supporting increased air-to-air reception range while over-flying high density, high
interference operational environments.
The approach described would add a dedicated directional receive-only antenna to the top
of the airframe in combination with a 1090 MHz receiver optimized for extended squitter
reception.
M.4.1 Optimized 1090 MHz Antenna

The proposed approach for supporting an extended squitter reception range would
include the provision of an additional dedicated aircraft 1090 MHz receive-only antenna
(i.e., a third antenna in addition to the baseline diversity antennas) with a gain pattern that
is optimized for the required ADS-B system performance requirements, as summarized in
section M.2 above. The baseline aircraft antenna configuration that is applicable to Class
A3 ADS-B airborne systems is assumed to employ omni-directional top and bottom
diversity antennas and are assumed to be consistent with the characteristics described in
Appendix C. A more optimum aircraft antenna configuration is possible where a third
antenna is added that is optimized specifically for the reception of 1090 MHz Extended
Squitters at the maximum range in the forward direction. Such an optimized aircraft
antenna configuration employing 3 antennas must still support reception at the ranges
required by RTCA DO-242A in non-forward directions and must, at least, not degrade
reception performance in the highest 1090 MHz fruit environments. A candidate
optimized aircraft antenna configuration is described below that satisfies these
constraints.
In this optimized configuration the diversity top and bottom aircraft antenna have antenna
gain pattern characteristics as in a baseline 1090 MHz ADS-B configuration (i.e., omni-
directional). However, for extended reception range these standard diversity antennas are
supplemented with a top-mounted multi-element directional antenna providing a nominal
+2 to +5 dB of additional gain in the forward direction, as compared to an omni-
20xx, RTCA, Inc.
Appendix M
Page M - 5
directional antenna. A typical configuration for the enhanced directional aircraft antenna
is summarized below:
employs one driven quarter wavelength element and one or more passive elements.
The elements are tuned to provide peak gain and minimum VSWR at or near 1090
MHz. and providing a nominal +2 to +5 dB gain increase at or just above the horizon
in the forward direction (exclusive of any internal amplification), as compared to the
baseline omni-directional antenna.
includes an internal low noise preamplifier with 12 dB to 15dB of gain and a noise
figure at 1090 MHz. consistent with the overall MTL requirements of the receiving
system.
The directional top antenna is to be used in combination with omni-directional top and
bottom diversity antennas and each of the three antennas would be connected to
independent 1090 MHz receivers. Since the directional top antenna would be dedicated
to ADS-B reception, this could allow for a more optimum mounting location to be
selected in support of the goal of providing improved reception performance from the
forward direction. This would typically lead to a desired mounting location forward on
the airframes top center-line.
M.4.2 Optimized Receiver Characteristics
M.4.2.1 Optimized Receiver Bandwidth

Class A3 receivers that are not shared with TCAS are specified to have an MTL (at the
antenna) of 84 dBm (Table 2-62 of these MOPS). The out-of-band rejection for a
message frequency difference of + 5.5 MHz is specified by Table 2-63 of these MOPS to
be at least 3 dB above this MTL. These out-of-band rejection characteristics correspond
to a receiver design that employs intermediate frequency (IF) filtering with an effective
bandwidth of approximately 8 MHz. Modeling of the enhanced decoding techniques, as
defined in Appendix I of these MOPS, have shown that reducing the IF bandwidth to
significantly less than 8 MHz (e.g., 4 MHz) may slightly degrade the enhanced decoder
performance in very high 1090 MHz Mode A/C fruit environments. However, such a
reduction in the IF bandwidth will allow for decreased receiver MTL values resulting in
improved reception range when used in low-to-moderate Mode A/C fruit environments.
An optimum 1090 MHz Extended Squitter airborne architecture would allow for use of a
narrower bandwidth receiver connected to a dedicated top-mounted directional antenna,
as described in section M.4.1 above.
The use of a dedicated ADS-B receiver with reduced bandwidth provides the opportunity
for improving the sensitivity of the receiver. The MTL for Class A3 receivers,
conformant to these MOPS, is 84 dBm or lower (Table 2-62). Airborne installations
may achieve up to a 3 dB improvement from this reception performance level (i.e., MTL
less than or equal to -87 dBm) as a direct result of the reduction of the receiver
bandwidth, as described above.
Additional improvements in receiver sensitivity are possible with the use of a low noise
preamplifier mounted near or integral with the dedicated receiving antenna as described
in section M.4.1 above. If an antenna-mounted low noise preamp is used in combination
with a narrow bandwidth receiver, then a receiver MTL as low as 90 dBm may be
20xx, RTCA, Inc.

Appendix M
Page M - 6
possible. Such a configuration could be used to provide for maximum reception range in
a low to moderate 1090 MHz. fruit environment.
M.4.2.2 Optimized Receiver Extended Squitter Decoding

Class A3 receivers are required by these MOPS to incorporate enhanced reception
techniques. The associated test procedures of these MOPS are consistent with an 8 MHz
sampling rate of the received video waveform (i.e., 8 samples per bit). Higher sampling
rates are known to provide improved probability of correct decoding when using the
baseline multi-sample enhanced decoding techniques defined in Appendix I in a high
Mode A/C fruit environment. Therefore, a sampling rate of 10 MHz or higher is
recommended for use as a means of extending the reception range of 1090 MHz ADS-B
in high Mode A/C fruit environments. Applying a decoder with a higher sampling rate is
expected to help offset the degradation to decoding performance that would result from
use of a reduced bandwidth receiver as described in M.4.2.1 above.
M.5 Transmission Power

Currently all 1090 MHz ADS-B airborne systems, other than Class A0, are required by
these MOPS to have a transmit power within the range of 21 dBW (125 watts) to 27
dBW (500 watts), as measured at the antenna port. As noted in 2.2.2.1.1.4 of these
MOPS: Future version of these MOPS may require that Class A3 1090 MHz ADS-B
systems have a transmission capability with a minimum RF peak power of 23 dBW (200
Watts) measured at the antenna terminals. As the ADS-B MASPS mature, further
refinements to the air-to-air range requirements are expected. Also as the ASA MASPS
are completed new requirements may emerge that require either improvements in
received update rates or increased reception ranges. A 1090 MHz ADS-B airborne
installation satisfying only the minimum transmit power requirement of 21 dBW, as
currently required by these MOPS, is expected to be compatible with the 90 NM
reception range requirement, as applicable to Class A3 systems, only under near ideal
conditions (with a nominal antenna gain patterns and in a RF non-interference
environment). A 2dB increase in the minimum transmit power from 21 dBW to 23 dBW
for Class A3 airborne systems is expected to offer a meaningful improvement in the
actual air-to-air reception range supported between Class A3 users, especially under non-
ideal conditions.
20xx, RTCA, Inc.

Appendix N
Proposed DO-260B Provisions for Backward
Compatibility with DO-260 and DO-260A
Message Formats


Appendix N
Page N - 3
N Proposed DO-260A Provisions for Backward Compatibility with DO-260 Message

Formats
N.1 Introduction
N.1.1 Purpose of this Appendix

This Appendix:
a) Defines the formats and coding for extended squitter ADS-B Messages that are
broadcast by ADS-B Version Zero (0), RTCA DO-260 conformant 1090 MHz ADS-
B Subsystems; and
b) Defines how the ADS-B report generation function of Version One (1) 1090 MHz
ADS-B Receiving Subsystems is to utilize messages received from targets that are
broadcasting with Version Zero (0) message formats.
N.1.2 Message Version Number

The Version Number for all 1090 MHz ADS-B Messages originating for each specific
ADS-B target is determined from the decoding of the Version Number subfield of the
Aircraft Operational Status Message. An ADS-B Version One (1) Receiving Subsystem
initially assumes that the messages conform to Version Zero (0) message formats, until or
unless received Version Number data indicates otherwise. The Version Number is
retained and associated with all messages from that specific target. This Version Number
is used for determining the applicable message formats to be applied for the decoding of
all 1090 MHz ADS-B Messages received from that target.
N.2 1090 MHz ADS-B Message Types

Table N-1 provides those ADS-B Version Zero (0) (i.e., originating from a RTCA DO-
260 conformant 1090 MHz ADS-B Transmitting Subsystem) 1090 MHz ADS-B
Messages that are to be used for ADS-B report generation by a Version One (1)
conformant 1090 MHz ADS-B Receiving Subsystem.
Note: Table N-1 lists only those Version Zero (0) 1090 MHz ADS-B Message types that
are required to be received and used for ADS-B report generation by a Version
One (1) 1090 MHz ADS-B Receiving Subsystem. The other Version Zero (0)
ADS-B Messages types defined by RTCA DO-260, including messages types 29
and 30, are not to be used by Version One (1) ADS-B Receiving Subsystems for
the purpose of ADS-B report generation.
20xx, RTCA, Inc.

Appendix N
Page N - 4
Table N-1: Version Zero (0) ADS-B Message Types
Message
Format TYPE Assignment Nominal Broadcast Rate
Code(s)
Extended Squitter Identification and
1 through 4 5.0 s airborne/10.0 s surface
Category
5 through 8 Extended Squitter Surface Position 0.5 s in motion/5.0 s stationary
9 through 18
and Extended Squitter Airborne Position 0.5 s
20 through 22
19 Extended Squitter Airborne Velocity 0.5 s
Extended Squitter Aircraft Status (e.g.,
28 1.0 s
emergency/priority)
31 Aircraft Operational Status 1.7 s
N.2.1 Message TYPE Codes

The first 5-bit field in every 1090 MHz ADS-B Message contains the message format
TYPE. As shown in Table N-2, the TYPE code (i.e., format type) is used to differentiate
the messages into several classes: airborne position, airborne velocity, surface position,
identification, aircraft status, etc. The general definition for all ADS-B Messages Types
used for Version Zero (0) ADS-B Messages has been retained for Version One (1)
messages. It must be noted for Version Zero (0) ADS-B Messages, format TYPE Code
29 was defined but the corresponding messages were not to be transmitted. For Version
Zero (0) ADS-B Subsystems, TYPE code 29 was associated with intent messages
conveying Trajectory Change Point (TCP) information. Although the message formats
for TCP related messages were defined within RTCA DO-260 the requirements and the
associated test procedures prohibited the broadcast of such messages. RTCA DO-260
defined TYPE Code 30 for Aircraft Operational Coordination Messages. The
requirements and associated provisions for Aircraft Operational Coordination Messages
have now been withdrawn by this version of these MOPS. Although RTCA DO-260
(i.e., Version 0) conformant implementations are not prohibited from transmitting
Aircraft Operational Coordination Messages (i.e., using TYPE Code 30), Version One (1)
conformant ADS-B Receiving Subsystems have no requirement for the reception and
processing of these broadcasts. Version One (1) ADS-B Receiving Subsystems will
generate ADS-B reports based only on the reception of Version Zero (0) ADS-B
Messages with ADS-B Message TYPE Code values of 0 through 22, 29 and 31.
20xx, RTCA, Inc.

Appendix N
Page N - 5
Table N-2: Format TYPE Codes for Version 0 and Version 1 Messages
TYPE Version 0 Version 1
Code Message Format Message Format
0 No Position Information No Position Information
1 Identification (Category Set D) Identification (Category Set D)
2 Identification (Category Set C) Identification (Category Set C)
3 Identification (Category Set B) Identification (Category Set B)
4 Identification (Category Set A) Identification (Category Set A)
5 Surface Position Surface Position
9 Airborne Position Airborne Position
19 Airborne Velocity Airborne Velocity
23 Reserved for Test Purposes Test Message
24 Reserved for Surface System Status Reserved for Surface System Status
25 Reserved Reserved
26 Reserved Reserved
27 Reserved Reserved for Trajectory Change
28 Extended Squitter Aircraft Status Extended Squitter Aircraft Status
29 Reserved for Trajectory Intent Target State and Status
30 Operational Coordination Reserved
31 Operational Status Operational Status
N.3 State Vector Reports Generated using Version Zero (0) Messages
The following subparagraphs summarize the ADS-B State Vector Report generation
requirements (see 2.2.8.1) for Version One (1) systems when receiving Version Zero (0)
ADS-B Messages.
The contents of State Vector Reports are specified in Table 2.2.8.1. The contents of the
State Vector Reports are composed primarily from the information received from
airborne aircraft in Airborne Position Messages and Airborne Velocity Messages or for
aircraft/vehicles on the airport surface in Surface Position Messages. Many of the
parameters contained within these messages are encoded the same, and occupy the same
positions with the overall message structure, for both Version Zero (0) and for Version
One (1) messages. However, in a few cases the decoding and/or report assembly
processing must be handled differently for Version Zero (0) messages as compared to that
required by these MOPS (2.2.8.1) for Version One (1) messages. The following
subparagraphs describe the required use of Version Zero (0) messages for ADS-B report
generation by a Version One (1) compliant ADS-B Receiving Subsystem.
20xx, RTCA, Inc.

Appendix N
Page N - 6
N.3.1 State Vector Report to 1090 MHz ADS-B Message Mapping

Table 2.2.8.1 specifies the overall State Vector Report format and the source for each
parameter that is to be reported when the target aircraft/vehicle is broadcasting with
Version One (1) ADS-B Message formats. In a similar fashion, Table N-3 below defines
the 1090 MHz ADS-B Message-to-State Vector Report mapping that will be used when
the target aircraft/vehicle is broadcasting using Version Zero (0) ADS-B Messages. Note
there are some minor differences in the specific names applied to certain otherwise
identical Version Zero (0) versus Version (1) messages subfields. The only new or
changed State Vector Report parameter between RTCA DO-260 (i.e., Version 0) and
these MOPS is for Navigation Integrity Category (NIC), which has replaced Navigation
Uncertainty Category (NUC) from the initial version of these MOPS. The following
subparagraph discusses the NIC parameter and its mapping from Version Zero (0)
messages to the State Vector Report. The remaining State Vector Report parameters are
described in 2.2.8.1.
The format of the Version Zero (0) 1090 MHz ADS-B Messages are specified in Figure
N-1 through Figure N-7.
20xx, RTCA, Inc.

Appendix N
Page N - 7
Table N-3: ADS-B State Vector Data Elements Version Zero (0) 1090 MHz ADS-B Messages to Report Structure Mapping
VERSION ZERO (0) MESSAGE STRUCTURE
REPORT STRUCTURE REPORT STRUCTURE RELEVANT
Column # RELEVANT
1 2 3 4 5 6 7 8 9 10 11
Received ME Message # of Data
Item # Parameter / Contents Notes Range Resolution Units Data Structure
Message Structure Field Bits Field Bits Bits Byte #
Report Type and MddL Mddd dddddddd
0a, 0b 4 Airborne Position - DF N/A 15 24 N/A N/A discrete 0 -2
Structure Identification ddddddL
0c Validity Flags N/A N/A N/A 16 N/A N/A discrete dddddddd dddddddd 3-4
Airborne Position - AA N/A 9 - 32
Mddddddd dddddddd
1 Participant Address 4 Surface Position - AA N/A 9 32 24 N/A N/A discrete 5-7
DddddddL
Airborne Velocity AA N/A 9 - 32
2 Address Qualifier N/A N/A N/A 8 N/A N/A discrete 00000M0L 8
Airborne Position Time 21 53 Mddddddd dddddddL
Time of Applicability 0.0078125
3 4 Surface Position Time 21 53 24 511.9921875 seconds Mddddddd dddddddL 9 - 11
(Position and Velocity) (1/128)
Airborne Velocity N/A N/A Mddddddd dddddddL
Airborne Position
23 - 39 55 - 71
Latitude Encoded Latitude SMdddddd dddddddd
4 4 24 +/- 180 0.0000215 degrees 12 - 14
(WGS-84) Surface Position DddddddL
23 - 39 55 71
Encoded Latitude
Airborne Position
40 - 56 72 - 88
Longitude Encoded Longitude SMdddddd dddddddd
5 4 24 +/- 180 0.0000215 degrees 15 - 17
(WGS-84) Surface Position DddddddL
40 - 56 72 88
Encoded Longitude
Airborne Position TYPE, &
1 - 5, & 33 - 37
Altitude
9 - 20 41 52
Altitude, Geometric Airborne Velocity SMdddddd dddddddd
6 4, 5 24 +/- 131,072 0.015625 feet 18 - 20
(WGS-84) Diff. Sign Bit & dddddddL
49 81
Geo Height Diff. from Baro.
50 - 56 82 - 88
Alt.
Airborne Velocity
25 57
7 North / South Velocity 4, 5 Direction Bit for N-S Vel. & 16 +/- 4,096 0.125 knots SMdddddd dddddddL 21 - 22
26 - 35 58 67
N/S Velocity
Airborne Velocity
14 46
8 East / West Velocity 4, 5 Direction Bit E-W Vel. & 16 +/- 4,096 0.125 knots SMdddddd dddddddL 23 - 24
15 - 24 47 56
E/W Velocity
Ground Speed while on
9 4, 6 Surface Position Movement 6 - 12 38 44 8 N/A N/A discrete MddddddL 25
the Surface
20xx, RTCA, Inc.

Appendix N
Page N - 8
VERSION ZERO (0) MESSAGE STRUCTURE

REPORT STRUCTURE REPORT STRUCTURE RELEVANT
Column # RELEVANT
1 2 3 4 5 6 7 8 9 10 11
Received ME Message # of Data
Item # Parameter / Contents Notes Range Resolution Units Data Structure
Message Structure Field Bits Field Bits Bits Byte #
Heading while on the Surface Position Ground
10 4, 6 14 - 20 46 52 8 +/- 180 1.40625 degrees SMdddddL 26
Surface Track
Airborne Position TYPE, &
Altitude, Barometric 1-5 33 37 SMdddddd dddddddd
11 4, 5 Altitude 24 +/- 131,072 0.015625 feet 27 - 29
(Pressure Altitude) 9 - 20 41 52 dddddddL
Airborne Velocity
Vertical Rate, 36 68
Source Bit for Vert. Rate ,
12 Geometric/Barometric 4, 5 37 69 16 +/- 32,768 1.0 ft./min. SMdddddd dddddddL 30 - 31
Sign Bit for Vert. Rate &
(WGS-84) 38 - 46 70 78
Vert. Rate
Navigation Integrity Airborne Position Type Code 15 33 37
13 4 8 N/A N/A discrete 0000MddL 32
Category (NIC) Surface Position Type Code 1-5 33 - 37
Airborne Position
23 - 39 55 - 71
Estimated Latitude Encoded Latitude 0.00002
14 7 24 24 +/- 180 degrees 33 - 35
(WGS-84) Surface Position 15
23 - 39 55 71
Encoded Latitude
Airborne Position
40 - 56 72 - 88
Estimated Longitude Encoded Longitude 0.00002
15 7 24 24 +/- 180 degrees 36 - 38
(WGS-84) Surface Position 15
40 - 56 72 88
Encoded Longitude
Airborne Velocity
Estimated North/South 25 57
16 7 Direction Bit for N-S Vel. & 16 +/- 4,096 0.125 knots SMdddddd dddddddL 39 - 40
Velocity 26 - 35 58 67
N-S Velocity
Airborne Velocity
Estimated East/West Direction Bit for E-W Vel. 14 46
17 7 16 +/- 4,096 0.125 knots SMdddddd dddddddL 41 - 42
Velocity & 15 - 24 47 56
E-W Velocity
Airborne Position
67 38 39 4
Surveillance Surveillance. Status
18 N/A N/A discrete dddd dddd 43
Status/Discretes Airborne Velocity
9 9 4
Intent Change Flag
19 Report Mode N/A N/A N/A 8 N/A N/A discrete 000000ML 44
TOTAL BYTES 45
20xx, RTCA, Inc.

Appendix N
Page N - 9
Notes for Table N-3:
1. In the Data Structure column (i.e., column 10), S indicates the sign-bit, M
indicates the Most Significant Bit of the data field, d indicates data bits in the field,
L indicates the Least Significant Bit of the data field, 0 indicates the bit is to
always be set to a value of zero (0) and x indicates Dont Care bits in the data
field.
2. If data is not available to support theses fields, then the entire data field shall be set to
ALL ZEROs if the field is delivered to the application.
3. The Report Type Identifier is used to identify the type of ADS-B Report being generated
as defined in 2.2.8.1.1.1.
4. Items annotated with Note 4 represent Critical State Vector items, however certain
items are only applicable while airborne and others only applicable while on the
surface (see Notes 5 and 6 below).
5. Parameters annotated with Note 5 are only present in the State Vector Report when the
aircraft is airborne
6. Parameters annotated with Note 6 are only present in the State Vector Report with the
aircraft is on the airport surface
7. Estimated values may be either an actual value from a received message, if available, or
a calculated value such as produced by a surveillance tracker algorithm. For example
it is possible for a surveillance tracker to produce an updated estimate of the targets
horizontal position based on just the receipt of a new velocity message.
8. The Time of Applicability is actually a grouping of 3 individual parameters as defined in

2.2.8.1.4
N.3.1.1 Navigation Integrity Category (NIC)

The ADS-B Version Zero (0) Surface and Airborne Position Messages have associated
with each specific TYPE Code a corresponding Horizontal Protection Limit and a 95%
Containment Radius. For the purpose of generating a State Vector Report, RTCA DO-
260 (i.e., Version 0) mapped these message parameters to a Navigation Uncertainty
Category (NUC). As defined by Table 2-11, Version One (1) Surface and Airborne
Position Messages associated the ADS-B Message TYPE Code with the parameters of
Horizontal Containment Limit (RC) and Navigation Integrity Category (NIC). Although
Version Zero (0) ADS-B Messages were not defined by RTCA DO-260 to directly
include a value for NIC, the values defined by Table 2-11 for RC and NIC have been
selected such that the it is possible to map the TYPE Code values from Version Zero (0)
ADS-B Message to a corresponding value for NIC. The Surface and Airborne Position
Message TYPE Codes associated with Version Zero (0) 1090 MHz ADS-B Messages are
mapped to the NIC values shown in Table N-4 for the purpose of generating State Vector
Reports.
20xx, RTCA, Inc.

Appendix N
Page N - 10
Table N-4: Version Zero (0) Format Type Code Mapping to Navigation Source Characteristics
TYPE Subfield Code Definitions (DF = 17 or 18)
TYPE Reported
Format Horizontal Protection Limit, HPL Altitude Type
Code NIC
Baro Altitude or No Altitude
0 No Position Information 0
Information
5 Surface Position HPL < 7.5 m No Altitude Information 11
6 Surface Position HPL < 25 m No Altitude Information 10
7 Surface Position HPL < 185.2 m (0.1 NM) No Altitude Information 8
8 Surface Position HPL > 185.2 m (0.1 NM) No Altitude Information 0
9 Airborne Position HPL < 7.5 m Baro Altitude 11
10 Airborne Position 7.5 m < HPL < 25 m Baro Altitude 10
11 Airborne Position 25 m < HPL < 185.2 m (0.1 NM) Baro Altitude 8
12 Airborne Position 185.2 m (0.1 NM) < HPL < 370.4 m (0.2 NM) Baro Altitude 7
13 Airborne Position 380.4 m (0.2 NM) < HPL < 926 m (0.5 NM) Baro Altitude 6
14 Airborne Position 26 m (0.5 NM) < HPL < 1852 m (1.0 NM) Baro Altitude 5
15 Airborne Position 1852 m (1.0 NM) < HPL < 3704 m (2.0 NM) Baro Altitude 4
16 Airborne Position 7.704 km (2.0 NM) < HPL < 18.52 km (10 NM) Baro Altitude 1
17 Airborne Position 18.52 km (10 NM) < HPL < 37.04 km (20 NM) Baro Altitude 1
18 Airborne Position HPL > 37.04 km (20 NM) Baro Altitude 0
20 Airborne Position HPL < 7.5 m GNSS Height (HAE) 11
21 Airborne Position HPL < 25 m GNSS Height (HAE) 10
22 Airborne Position HPL > 25 m GNSS Height (HAE) 0
1. Baro-Altitude refers to barometric pressure altitude, relative to a standard pressure of 1013.25 millibars (29.92 in Hg). It does not refer to baro corrected
altitude.
2. The GNSS height (HAE) defined in Type Codes 20 to 22 is used when baro altitude is not available.
3. The horizontal protection level, HPL, is derived from ARINC 429 label 130, which is variously called HIL (Horizontal Integrity Limit) or HPL (Horizontal
Protection Level).
20xx, RTCA, Inc.

Appendix N
Page N - 11
N.4 Mode Status Reports

Table 2.2.8.2 defines the overall Mode Status Report format and the source for each
parameter that is to be reported when the target aircraft/vehicle is broadcasting with
Version One (1) ADS-B Message formats. In a similar fashion, Table N-5 below defines
the 1090 MHz ADS-B Message-to-State Vector Report mapping that will be used when
the target aircraft/vehicle is broadcasting using Version Zero (0) ADS-B Messages. Note
that there are some significant differences in the message parameters available from
Version Zero (0) versus Version (1) ADS-B Messages. This results in Mode Status
Reports related to target aircraft/vehicles broadcasting Version Zero (0) ADS-B
Messages being substantially less complete than would be possible when Version One (1)
ADS-B Messages are being received. The following subparagraphs discuss those Mode
Status Report parameters that must be processed and/or mapped differently for Version
Zero (0) ADS-B Messages. The remaining Mode Status Report parameters not
specifically addressed in the following subparagraphs will be generated as specified in
2.2.8.2 (i.e., using the same mapping as for Version One (1) ADS-B Messages).
The format of the Version Zero (0) 1090 MHz ADS-B Messages are specified in Figure
N-1 through Figure N-7.
20xx, RTCA, Inc.

Appendix N
Page N - 12
Table N-5: ADS-B Mode Status Data Elements Version Zero (0) 1090 MHz ADS-B Messages to Report Structure Mapping
# 1 2 3 4 5 6 7 8 9 10 11
ME Message
Received Version 0 # of Data
Bits Bits
N/A N/A 24 MddL Mddd dddddddd
0a,0b Report Type and Structure N/A N/A N/A discrete 0-2
dddddddL
0c Validity Flags N/A N/A N/A 8 N/A N/A discrete dddddddd 3
Airborne Velocity - AA 9 32
N/A 24
- OR -
Operational Status AA 9 32 Mddddddd dddddddd
N/A 24
1 Participant Address - OR - N/A N/A discrete dddddddL 46
Aircraft Identification 9 32
N/A 24
AA
2 Address Qualifier N/A reserved for future use 8 N/A N/A discrete 00000M0L 7
0.0078125
3 Time of Applicability N/A N/A N/A 16 511.9921875 seconds Mddddddd dddddddL 8-9
(1/128)
Operational Status
4 ADS-B Version 41 - 43 73 - 75 8 0-7 1 discrete 00000MdL 10
Version Number
0MdddddL 0MdddddL
11 18
Aircraft Identification 0MdddddL 0MdddddL
Ident Char. 0MdddddL 0MdddddL
5a Call Sign 14 56 41 88 64 Alphanumeric
N/A N/A 0MdddddL
characters
0MdddddL
Aircraft Identification 19
5b Emitter Category 68 38 - 40 8 N/A N/A discrete 000MdddL
Emitter Category
A/V Length and Width
5c 5 N/A 21 - 24 53 - 56 8 N/A N/A N/A 00000000 20
Codes
Aircraft Status Message
6 Emergency/Priority Status Subtype 1 8 N/A N/A discrete 00000MbL 21
9 - 11 36 - 38
Emergency/Priority Status
00000000 dd000000
7 Capability Codes Operational Status CC-4 9 - 12 41 - 44 24 See Section N.4.4 22 - 24
00000000
8 Operational Mode 4 N/A 16 N/A N/A N/A 00000000 00000000 25 - 26
Airborne Position Type
SV Quality - NACp Code 15 33 37 8
9a N/A N/A discrete 00000000 27
Surface Position Type 1-5 33 - 37
Code
Airborne Velocity Message 11 - 13 43-45
9b SV Quality - NACv 8 N/A N/A discrete 00000MdL 28

20xx, RTCA, Inc.

Appendix N
Page N - 13

# 1 2 3 4 5 6 7 8 9 10 11
ME Message
Received Version 0 # of Data
Bits Bits
NUCR
Airborne Position
Type Code 15 33 37
9c SV Quality SIL 4, 5 8 N/A N/A discrete 000000ML 29
Surface Position
Type Code 1-5 33 - 37
SV Quality BAQ
9d N/A N/A N/A 8 N/A N/A discrete 000000ML 30
(reserved)
9e SV Quality NICbaro 4 N/A N/A N/A 8 N/A N/A discrete 0000000L 31
Airborne Velocity
SUBTYPE 6-8 38 - 40
Track/Heading and - Magnetic Heading Status 14 46
10a Horizontal Reference 4 Bit 8 N/A N/A discrete 0000000L 32
Direction (HRD) Surface Position Message
Status Bit for Ground 13 45
Track
Airborne Velocity Vert.
10b Vertical Rate Type 36 68 8 N/A N/A discrete 0000000L 33
Rate Source
11 Other (Reserved) Reserved 8 Reserved dddddddd 34
TOTAL BYTES: 35

1. In the Data Structure column (i.e., column 10), S indicates the sign-bit, M indicates the Most Significant Bit of the data field, d indicates data bits
in the field, L indicates the Least Significant Bit of the data field, 0 indicates the bit is to always be set to a value of zero (0), and x indicates Dont
Care bits in the data field.
2. If data is not available to support these fields, then the entire data field shall be set to ALL ZEROs.
3. The Report Type Identifier is used to identify the type of ADS-B Report being generated as defined in 2.2.8.1.1.1.
4. This parameter is not available for aircraft/vehicles broadcasting Version Zero (0) ADS-B Messages. If included in the Mode Status report the value of this
parameter is to be set to all zeros otherwise it may be omitted from the Mode Status Report and its omission indicated in the Report Type and Structure
Parameter using the format defined in Table 2.2.8.2.1.1.
5. This parameter is not available for aircraft/vehicles broadcasting Version Zero (0) ADS-B messages. This parameter is to be omitted from the Mode Status
Report and its omission indicated in the Report Type and Structure Parameter using the format defined in Table 2.2.8.2.1.1.
20xx, RTCA, Inc.

Appendix N
Page N - 14
N.4.1 ADS-B Version

The format of the Aircraft Operational Status Message substantially differs between the
Version Zero (0) ADS-B Message format shown in Figure N-7 and the Version One (1)
ADS-B Message format specified in 2.2.3.2.7.3 of these MOPS. The Version One (1)
Aircraft Operational Status Message format includes an explicit Version Number subfield
(ME bits 41-43). For a Version Zero (0) ADS-B Aircraft Operational Status Message,
these same bits are unassigned and are expected to be set to a value of ZERO (0). A
Version One (1) ADS-B Receiving Subsystem will, as a default, assume the received
messages are using Version Zero (0) ADS-B Message format unless, or until, an Aircraft
Operational Status Message is received and the Version Number is confirmed to be other
than Zero. However, in the case of a Version One (1) ADS-B Subsystems reception of
an Aircraft Operational Status Message, the ADS-B Receiving Subsystem will decode
ME bits 41-43 and determine if the target aircraft is broadcasting messages that are
ADS-B Version Zero (0) or Version One (1) and then decode the remainder of the
message in accordance with the message format applicable to that Version Number.
Note: The Version Number determined from the decoding of the Version Number
subfield of the Aircraft Operational Status message must be retained and
associated with the specific target since it is used in determining the applicable
formats to be used for the decoding of the other message types.
N.4.2 Emitter Category

The ADS-B Report Assembly Function will extract TYPE and ADS-B Emitter
Category from the Aircraft Identification and Category Message (Figure N-3) and
encode the Emitter Category field of the Mode Status Report as shown in Table
2.2.8.2.7. The Emitter Category conveyed in the Aircraft Identification and Category
Message is mapped into the Mode Status Report, Emitter Category field as specified by
Table 2.2.8.2.7. However, it must be noted that in the Version Zero (0) Aircraft
Identification and Category Message, the Emitter Category subfield conveys a subset of
the Emitter Categories allowed by the Mode Status Report.
N.4.3 A/V Length and Width Code

The A/V Length and Width Code is not conveyed by Version Zero (0) 1090 MHz ADS-B
Messages. This parameter is only included in the Mode Status Report when reporting on
an aircraft or vehicle that is on the airport surface. When no A/V Length and Wide Code
is available, as is the case for target A/V that are broadcasting Version Zero (0) ADS-B
Messages, the A/V Length and Wide Code parameter will not be included in the Mode
Status Report and its omission so indicated in the Report Type and Structure Parameter
using the coding specified in Table 2.2.8.2.1.1.
N.4.4 Emergency/Priority Status

The Emergency/Priority Status conveyed in the Aircraft Status Message (Figure N-6) will
be directly mapped into the Mode Status Report, Emergency/Priority Status field as
specified in 2.2.8.2.9. However, it must be noted that in the Version Zero (0) Aircraft
20xx, RTCA, Inc.

Appendix N
Page N - 15
Extended Squitter Status Message, the Emergency/Priority Status subfield conveys a

subset of the Emergency/Priority Status categories allowed by the Mode Status Report.
N.4.5 Capability Codes

The Version Zero (0) Operational Status Message (Figure N-7) conveys Control Codes
with information limited to TCAS and CDTI capabilities, as shown in Table N-6. The
Version Zero (0) Aircraft Operational Status Message format specifies coding only for
the case of CC-4 (En Route Operational Capabilities). Therefore the CC-1, CC-2 and
CC-3 subfields, as specified in Figure N-7, are to be considered reserved and not used for
Version Zero (0) ADS-B Messages.
For the case of CC-4, this 4-bit (bits 9-12) subfield will be mapped to the Capability
Code field of the Mode Status Report as shown in Table N-6. The remaining bits within
the Mode Status Report Capability Code field will be set to Zero (0). If no Aircraft
Operational Status Message has been received, then the Capability Code field may be
omitted from the Mode Status Report and its omission so indicated in the Report Type
and Structure Parameter using the coding specified in Table 2.2.8.2.1.1.
Table N-6: En-Route Operational Capabilities Encoding

CC-4 Encoding: En Route Operational Capabilities
CC-4 Coding Mapping to MS Report
(Version Zero (0) Messages)
Meaning Capability Code field
(Version Zero (0) Messages)
Bit 9,10 Bit 11,12 CC Field Bits 11, 12
TCAS Operational or unknown;
00 CDTI not Operational or unknown 10
TCAS Operational or unknown;
01 CDTI Operational 11
00 TCAS not Operational; CDTI not
10 Operational or unknown 00
TCAS not Operational; CDTI
11 Operational 01
N.4.6 Operational Modes

Version Zero (0), RTCA DO-260 conformant, ADS-B Message formats do not define
coding for the Operational Mode subfield of the operational status message. Therefore
the OM-1, OM-2, OM-3 and OM-4 subfields, as shown in Figure N-7, are to be
considered reserved and not used for ADS-B Version Zero (0) messages. Mode Status
Reports for target aircraft/vehicles broadcasting Version Zero (0) ADS-B Messages will
not include the Operational Mode field in the report and indicate the omission of this
parameter in the Report Type and Structure Parameter using the coding specified in Table
2.2.8.2.1.1.
N.4.7 Navigation Accuracy Category for Position (NACP)

The Version Zero (0) ADS-B Surface and Airborne Position Messages have associated
with each specific TYPE code a corresponding Horizontal Protection Limit and a 95%
20xx, RTCA, Inc.

Appendix N
Page N - 16
Containment Radius (i.e., position error). For a Version One (1) ADS-B Receiving
Subsystem, the TYPE codes of the received Version Zero (0) ADS-B Messages will be
mapped into the value of the Navigation Accuracy Category for Position (NACP) as
shown below in Table N-7 for the purpose of generating the Mode Status Report.
Table N-7: Type Code to NACP Mapping

Version 0 ADS-B
Position Error
Message Message Format MS Report
(95%)
TYPE CODE NACP value
0 No Position Info Unknown 0
5 Surface Position <3m 11
6 Surface Position < 10 m 10
7 Surface Position < 0.05 NM 8
8 Surface Position > 0.05 NM 0
9 Airborne Position <3m 11
10 Airborne Position < 10 m 10
11 Airborne Position < 0.05 NM 8
15 Airborne Position < 1 NM 4
18 Airborne Position > 10 NM 0
20 Airborne Position <4m 11
21 Airborne Position < 15 m 10
22 Airborne Position > 15 m 0
Note: The Position Error column of the table indicates the greater of the horizontal or
vertical 95% containment radius as listed in Table N-4 for Version Zero (0)
messages.
N.4.8 Navigation Accuracy Category for Velocity (NACV)

The Version Zero (0) ADS-B Airborne Velocity Message (see Figure N-4 and Figure N-
5) includes a subfield that conveys the Navigation Uncertainty Category for Velocity
(NUCR). The received value of NUCR will be mapped directly one-for-one to the
Navigation Accuracy Category for Velocity (NACV) field of Mode Status Report.
N.4.9 Surveillance Integrity Level (SIL)

The Surveillance Integrity Level (SIL) defines the probability of the integrity
containment region described by the NIC parameter being exceed for the selected
geometric position source, including any external signals used by the source. The value
of SIL can only be inferred from the information conveyed in Version Zero (0) ADS-B
Messages. Table N-8 provides the mapping between the message Type Code for a
Version Zero (0) transmitting system and the value of SIL to be reported by a Version
One (1) receiving system within the Mode Status Report (see 2.2.8.2.14).
20xx, RTCA, Inc.

Appendix N
Page N - 17
Table N-8: SIL Reporting

Version 0
Integrity Level (probability of ADS-B
Message
Message Format exceeding the horizontal containment MS Report
TYPE
radius (RC) without an indication) SIL value
CODE
0 No Position Info No Integrity 0
5 Surface Position 1 X 10-5 per flight hour or per sample 2
9 Airborne Position 1 X 10-5 per flight hour or per sample 2
18 Airborne Position No Integrity 0
22 Airborne Position No Integrity 0
N.4.10 Barometric Altitude Integrity Code (NICBARO)

The Barometric Altitude Integrity Code (NICBARO) parameter of the Mode Status Report
is a 1-bit flag used to indicate if the barometric altitude being reported in the State Vector
Report has been cross-checked against another source of pressure altitude. The Version
Zero (0) ADS-B Messages do not include information related to the cross-checking of
barometric altitude. Therefore, Mode Status Reports for target aircraft/vehicles
broadcasting Version Zero (0) ADS-B Messages will not include the NICBARO field in the
report and therefore will indicate the omission of this parameter in the Report Type and
Structure Parameter using the coding specified in Table 2.2.8.2.1.1.
N.4.11 Track/Heading and Horizontal Reference Direction (HRD)

Version Zero (0) Airborne Velocity Messages with SUBTYPE equal to 3 or 4 include a
Magnetic Heading Status Bit as shown in Figure N-4. A 1090 MHz ADS-B Receiving
Subsystem, upon receiving an Airborne Velocity Message with a Subtype of 3 or 4, must
decode the Magnetic Heading Status Bit to determine if Magnetic Heading Data is
Available. The ADS-B Receiving Subsystem will set the value of the True/Magnetic
Heading subfield (see 2.2.8.2.17, of the Mode Status Report), as specified in Table N-9.
20xx, RTCA, Inc.

Appendix N
Page N - 18
Table N-9: Track/Heading and HRD Subfield

Airborne Surface ADS-B
Version 0
Velocity Position MS Report
Airborne
Message Message True/Magnetic
Velocity Meaning
Magnetic Ground Heading subfield
Message
Heading Track Status coding
SUBTYPE
Status Bit Bit Bits 1 - 0
No Valid Track/
Heading or
Heading Direction
N/A N/A 0 00
Reference
information
available
Ground Track
1 or 2 N/A 1 01
being reported
Heading relative
3 or 4 0 N/A to true north being 00
reported
Heading relative
3 or 4 1 N/A to magnetic north 11
being reported
Notes:
1. When no valid data is available the Track/Heading and HRD parameter may be
reported as ALL ZEROs, or omitted, from the Mode Status Report and the omission
of this parameter indicated in the Report Type and Structure Parameter using the
coding defined in Table 2.2.8.2.1.1.
2. As defined in 2.2.8.2.17, when receiving Version One (1) messages, the

Track/Heading and HRD information are conveyed within the Operation Status
Message. However, when receiving Version Zero (0) messages the equivalent
information can be determined for airborne aircraft from the value of the
SUBTYPE subfield and for Subtype=3 or 4 messages the value of the Magnetic
Heading Status Bit of the Airborne Velocity Message (Figure N-4 and Figure N-5).
When a target aircraft/vehicle is on the surface a value of 01 should be reported
when a Surface Position Message (Figure N-2) is received with the Ground Track
Status Bit set to a value of ONE (1) indicating that the valid ground track data is
provided.
3. Version 0 Airborne Velocity Messages, Subtypes 3 and 4 always report Heading

relative to Magnetic North, never relative to True North.
N.5 Air Referenced Velocity Reports

The requirements of 2.2.8.3.2 for Air Referenced Velocity (ARV) Reports apply to the
ARV Report Assembly requirements when the target aircraft is broadcasting either
Version Zero (0) or Version One (1) ADS-B Message formats.
20xx, RTCA, Inc.

Appendix N
Page N - 19
N.6 Target Status Reports

RTCA DO-260 defined a message format using message TYPE Code 29 to convey
Aircraft Trajectory Intent information in the form of Trajectory Change Point (TCP)
information. A 1090 MHz ADS-B Receiving Subsystem conforming to these MOPS
(i.e., RTCA DO-242A) does not use any message with a TYPE Code of 29 that is
received from a Version Zero (0) ADS-B Transmitting Subsystem for the purpose of
report generation.
Note: Prior to generation of a Target Status Report, the 1090 MHz ADS-B Receiving
Subsystem must positively confirm that any received message with a TYPE Code
of 29 has originated from a target aircraft with an ADS-B Version Number other
than Zero (0). The ADS-B Version can be determined from the contents of the
Version Number subfield of the Aircraft Operational Status Message (see
2.2.8.2.5 and N.4.1).
N.7 Formats for Version Zero (0) 1090 MHz ADS-B Messages
1090 MHz ADS-B Receiving Subsystems conformant to these MOPS (RTCA DO-260A)
are required to receive and decode all Version One (1) compliant messages plus, for
backward compatibility, must receive and decode certain messages types conforming to
the previous RTCA DO-260, ADS-B Version Zero (0), formats. The following figures
define the format of ADS-B Version Zero (0) Extended Squitter Messages that must be
received and decoded and used for the generation of ADS-B reports as defined in N.3
through N.6.
Notes:
1. In some cases, ARINC 429 labels are referenced for specific message fields. These
references are only intended to clarify the field content, and are not intended as a
requirement to use these ARINC 429 labels as the source for the message field.
2. The formats of the Version Zero (0) ADS-B Messages that are not required to be
received and used for report generation by a Version One (1) 1090 MHz ADS-B
receiving system are not shown in the following figures.
20xx, RTCA, Inc.

Appendix N
Page N - 20
Figure N-1: Extended Squitter Airborne Position Message
1
2
3 FORMAT TYPE CODE
4 (See N.2.1) Purpose: To provide accurate airborne
5 position information
6 SURVEILLANCE STATUS
7
8 SINGLE ANTENNA FLAG (SAF)
9 Surveillance Status coding
10
11 ALTITUDE 0 = no condition information
12 Specified by the Format Type Code 1 = permanent alert (emergency condition)
13 2 = temporary alert (change in Mode A identity
14 (1) the altitude code (AC) as specified
15 in 2.2.13.1.2 of DO-181D but code other than emergency condition)
16 with the M-bit removed 3 = SPI condition
17 (Ref ARINC 429 Label 203), or
18
19 (2) GNSS height (HAE) Codes 1 and 2 take precedence over code 3.
20 (Ref. ARINC 429 Label 370)
21 TIME (T)
Note: When horizontal position information is
22 CPR FORMAT
23 MSB unavailable, but altitude information is
24 available, the airborne position message is
25 transmitted with a Format Type Code of
26
27 ZERO in bits 1-5 and the barometric
28 pressure altitude in bits 9 to 20. If neither
29
30 ENCODED LATITUDE
horizontal position nor barometric altitude
31 information is available, then all 56 bits of
32 (CPR Airborne Format) Register 0516 shall be ZEROed. The ZERO
33
34
Format Type Code field indicates that
35 latitude and longitude information is
36 unavailable, while the ZERO altitude field
37
38 indicates that altitude information is
39 LSB unavailable.
40 MSB
41
42
43
44
45
46
47 ENCODED LONGITUDE
48
49 (CPR Airborne Format)
50
51
52
53
54
55
56 LSB
20xx, RTCA, Inc.

Appendix N
Page N - 21
Figure N-2: Extended Squitter Surface Position Message
1
2
3 FORMAT TYPE CODE
4 (See N.2.1) Purpose: To provide accurate surface position
5 information.
6
7
8
9 MOVEMENT
10
11
12
13 STATUS for Gnd Tk (1 =valid, 0 = not valid)
14 MSB
15
16 GROUND TRACK (7 bits)
17
18
19 Resolution = 360/128 deg
20 LSB
21 TIME (T
22 CPR FORMAT (F)
23 MSB
24
25
26
27
28
29
30 ENCODED LATITUDE
31
32 (CPR Surface Format)
33
34
35
36
37
38
39 LSB
40 MSB
41
42
43
44
45
46
47 ENCODED LONGITUDE
48
49 (CPR Surface Format)
50
51
52
53
54
55
56 LSB
20xx, RTCA, Inc.

Appendix N
Page N - 22
Figure N-3: Extended Squitter Aircraft Identification and Category Message
Purpose: To provide aircraft identification and

1 category.
2
3 FORMAT TYPE CODE
4 (See N.2.1) Type coding:
5
6 1 = Aircraft identification, category set D
7 AIRCRAFT CATEGORY
8 2 = Aircraft identification, category set C
9 MSB 3 = Aircraft identification, category set B
10 4 = Aircraft identification, category set A
11 CHARACTER 1
12
13 ADS-B Emitter Category coding:
14 LSB
15 MSB
16
Set A
17 CHARACTER 2 0 =
18 1 =
Light (< 15 500 lbs.)
19
20 LSB 2 =
Small (15 500 to 75 000 lbs.)
21 MSB 3 =
Large (75 000 to 300 000 lbs.)
22 4 =
High Vortex Large (aircraft such as B-
23 CHARACTER 3
24 757)
25 5 = Heavy (> 300 000 lbs.)
26 LSB 6 = High Performance ( > 5 g acceleration and
27 MSB
28 > 400kts)
29 CHARACTER 4 7 = Rotorcraft
30
31
32 LSB Set B
33 MSB 0 = No ADS-B Emitter Category Information
34 1 = Glider/sailplane
35 CHARACTER 5
36 2 = Lighter-than-Air
37 3 = Parachutist/Skydiver
38 LSB
39 MSB
4 = Ultralight/hang-glider/paraglider
40 5 = Reserved
41 CHARACTER 6 6 = Unmanned Aerial Vehicle
42
43
7 = Space/Trans-atmospheric vehicle
44 LSB
45 MSB Set C
46
47 CHARACTER 7
0 = No ADS-B Emitter Category Information
48 1 = Surface Vehicle Emergency Vehicle
49 2 = Surface Vehicle Service Vehicle
50 LSB
51 MSB
3 = Fixed Ground or Tethered Obstruction
52 4-7 = Reserved
53 CHARACTER 8
54
55
Set D : Reserved
56 LSB
Aircraft identification coding:
Coding as specified for N.4.4
20xx, RTCA, Inc.

Appendix N
Page N - 23
Figure N-4: Extended Squitter Airborne Velocity Message

1 MSB 1
2 0
3 FORMAT TYPE CODE = 19 0 Purpose: To provide additional state
4 (See N.2.1) 1 information for both normal and
5 LSB 1
6 SUBTYPE 1 0 SUBTYPE 2 0 supersonic flight.
7 0 1
8 1 0 Subtype Coding
9 INTENT CHANGE FLAG)
10 IFR CAPABILITY FLAG Code Velocity Type
11 NAVIGATION UNCERTAINTY 0 As in first edition of the
12 CATEGORY VELOCITY ICAO Manual on Mode S Specific Services
13 (NUC_R) 1 Ground speed normal
14 DIRECTION BIT for E-W velocity (0=East, 1=West) 2 supersonic
15 EAST-WEST VELOCITY (10 bits) 3 Airspeed, heading normal
16 NORMAL : LSB = 1 knot SUPERSONIC : LSB =4 knots
4 supersonic
5 Not assigned
19 1 0 kts 1 0 kt 6 Not assigned
20 2 1 kt 2 4 kt 7 Not assigned
21 3 2 kt 3 8 kt
22 - - - - IFR Capability Flag coding:
23 1022 1021 kt 1022 4084 kt
24 1023 >1021.5 kt 1023 > 4086kt 0 = Transmitting aircraft has no capability
25 DIRECTION BIT for N-S velocity (0=North, 1=South) for applications requiring ADS-B
26 NORTH-SOUTH VELOCITY (10 bits) equipage class A1S/A1 or above
27 NORMAL : LSB = 1 knot SUPERSONIC : LSB =4 knots
28 All zeros = no velocity info All zeros = no velocity info 1 = Transmitting aircraft has capability for
29 Value Velocity Value Velocity applications requiring ADS-B equipage
30 1 0 kts 1 0 kt
31 2 1 kt 2 4 kt
class A1S/A1 or above.
32 3 2 kt 3 8 kt
33 - - - - Ref. ARINC Labels for Velocity:
34 1022 1021 kt 1022 4084 kt East-West North-South
35 1023 >1021.5 kt 1023 > 4086kt
SOURCE BIT FOR VERTICAL RATE: 0 = Geometric, 1 = GPS: 174 GPS: 166
36
baro (1 bit) INS: 367 INS: 366
37 SIGN BIT FOR VERTICAL RATE: 0 = up, 1 = down
39 All zeros no vertical rate information, LSB = 64 ft/min
Ref. ARINC Labels
40 Value Vertical rate Ref. ARINC 429 GNSS Height (HAE): GPS: 370
labels GNSS Altitude (MSL): GPS: 076
41 1 0 ft/min GPS: 165
42 2 64 ft/min INS: 365
43 - - Navigation Uncertainty Category:
44 510 32576 ft/min
45 511 > 32608 ft/min
HFOMR value VFOMR value NUCR
46
value
47 TURN INDICATOR (2 bits)
48 TBD HFOMR < 0.3 m/s AND VFOMR < 0.46 m/s 4
49 DIFFERENCE SIGN BIT (0 = above baro, 1 = below baro alt) (0.984 fps) (1.5 fps)
) HFOMR < 1 m/s AND VFOMR < 1.5 m/s 3
GEOMETRIC HEIGHT DIFFERENCE FROM BARO. ALT. (7 (3.28 fps) (5.0 fps)
50
bits) HFOMR < 3 m/s AND VFOMR < 4.6 m/s 2
51 All zeros = no info; LSB = 25 ft (9.84 fps) (15.0 fps)
52 Value Difference HFOMR < 10 m/s AND VFOMR < 15.2 m/s 1
53 1 0 ft (32.8 fps) (50 fps)
54 2 25 ft HFOMR unknown VFOMR unknown
55 - - or OR or 0
56 126 3125 ft HFOMR 10 m/s VFOMR 15.2 m/s
127 > 3137.5 ft (32.8 fps) (50 fps)
20xx, RTCA, Inc.

Appendix N
Page N - 24
Figure N-5: Extended Squitter Airborne Velocity Message

(Subtypes 3 and 4: Airspeed and Heading)
1 MSB 1
2 0
3 FORMAT TYPE CODE = 19 0 Purpose: To provide
4 (See N.2.1) 1 additional state information
5 LSB 1
6 SUBTYPE 3 0 SUBTYPE 4 1 for both normal and
7 1 0 supersonic flight based on
8 1 0
9 INTENT CHANGE FLAG) airspeed and heading.
10 IFR CAPABILITY FLAG
11 NAVIGATION UNCERTAINTY Note: This format is only used
12 CATEGORY VELOCITY
13 (NUCR) if velocity over ground
14 STATUS BIT 1 = Magnetic heading available, 0 = not available is not available
15 MSB
16
17 See the definition of NUCR in
18 MAGNETIC HEADING (10 bits) DO-260 2.2.3.2.6.1.5.
19 (N.4.5.5)
20
21 Ref. ARINC 429 Label: Subtype Coding
22 INS: 320 Code Velocity Type
23 Resolution = 360/1024 deg As in first edition of the
24 LSB 0 ICAO Manual on Mode S
25 AIRSPEED TYPE: 0 = IAS, 1 = TAS Specific Services
26 AIRSPEED (10 bits) Ground normal
27 NORMAL : LSB = 1 knot SUPERSONIC : LSB =4 knots 1 speed
28 All zeros = no velocity info All zeros = no velocity info 2 supersonic
3 Airspeed, normal
30 1 0 kts 1 0 kt
heading
31 2 1 kt 2 4 kt
32 3 2 kt 3 8 kt 4 supersonic
33 - - - - 5 Not assigned
34 1022 1021 kt 1022 4084 kt 6 Not assigned
35 1023 >1021.5 kt 1023 > 4086 kt 7 Not assigned
36 SOURCE BIT FOR VERTICAL RATE: 0 = Geometric, 1 = baro (1 bit)
37 SIGN BIT FOR VERTICAL RATE: 0 = up, 1 = down
IFR Capability Flag coding:
39 All zeros no vertical rate information
40 LSB = 64 ft/min 0 = Transmitting aircraft has
41 Value Vertical rate Ref. ARINC labels
42 1 0 ft/min GPS: 165 no capability for
43 2 64 ft/min INS: 365 applications requiring
44 - - ADS-B equipage class
45 510 32576 ft/min
46 511 > 32608 ft/min A1S/A1 or above
47 TURN INDICATOR (2 bits)
48 TBD
49 DIFFERENCE SIGN BIT (0 = above baro, 1 = below baro alt) )
1 = Transmitting aircraft has
50 GEOMETRIC HEIGHT DIFFERENCE FROM BARO. ALT. (7 bits) capability for applications
51 All zeros = no info; LSB = 25 ft requiring ADS-B equipage
52 Value Vertical rate Ref. ARINC 429
labels
class A1S/A1 or above.
53 1 0 ft
54 2 25 ft Ref. ARINC 429 Labels
55 - -
56 126 3125 ft for Air Data Source:
127 > 3137.5 ft IAS: 206
TAS: 210
20xx, RTCA, Inc.

Appendix N
Page N - 25
Figure N-6: Extended Squitter Aircraft Status Message

(Subtype 1: Emergency/Priority Status)
1
2
3 FORMAT TYPE CODE = 28 Purpose. To provide additional
4 (See N.2.1) information on aircraft status.
5
6
7 Subtype Code = 1
8
Subtype Coding:
9 EMERGENCY/PRIORITY
10 STATUS (3 bits) 0 = No Information
11 1 = Emergency/Priority Status
12
13
2-7 = Reserved
14
15 Emergency/Priority Status Coding
16
17
18 Value Meaning
19 0 No emergency
20
21 1 General emergency
22 2 Lifeguard/medical
23
24
3 Minimum fuel
25 4 No communications
26 5 Unlawful interference
27
28
6 Reserved
29 7 Reserved
30
31
32 Notes:
33 RESERVED 1. Message delivery is accomplished
34 once per second using the event
35
36 driven protocol.
37
38
39
2. Termination of emergency state is
40 detected by coding in the surveillance
41 status field of the airborne position
42
43
message.
44
45
46
47
48
49
50
51
52
53
54
55
56
20xx, RTCA, Inc.

Appendix N
Page N - 26
Figure N-7: Aircraft Operational Status Message

1 MSB
2
3 FORMAT TYPE CODE = 31 Purpose: To provide the
4 (See N.2.1) Capability Class and
5 LSB Current Operational Mode
6 MSB Of ATC related applications
7 SUBTYPE Code = 0 On board the aircraft.
8 LSB
9 MSB
10 En-Route Operational Capabilities (CC-4)
11
12 LSB
13 MSB
14 Terminal Area Operational Capabilities(CC-3)
15
16 LSB
17 MSB
18 Approach/ Landing Operational Capabilities (CC-2)
19
23 LSB
21 MSB
22 Surface Operational Capabilities (CC-1)
23
24 LSB
25 MSB
26 Enroute Operational Capability Status (OM 4)
27
28 LSB
29 MSB
30 Terminal Area Operational Capability Status (OM-3)
31
32 LSB
33 MSB
34 Approach/ Landing Operational Capability Status (OM-2)
35
36 LSB
37 MSB
38 Surface Operational Capability Status (OM-1)
39
40 LSB
41
42
43
44
45
46
47
48 Not Assigned
49
50
51
52
53
54
55
56
20xx, RTCA, Inc.

Appendix O
Accommodation of Trajectory Change Reporting


Appendix O
Page O - 3
O Accommodation of Trajectory Change Reporting
O.1 Introduction
In addition to the ADS-B requirements on which these MOPS are based, RTCA
DO-242A also provides a description of additional intent communications for which
future requirements are being considered. Trajectory Change (TC) Reports are defined,
although operational applications and resulting broadcast requirements are still under
development. Anticipating the possible use of TC Reports in the future, this Appendix
provides corresponding specifics for implementing this communication using Extended
Squitter. The analysis in this Appendix assumes that all communications of intent
information will be non-addressed air-to-air broadcasts. However, it should be noted that
as applications are developed that require long-range intent information, especially data
supporting reports beyond TC+1, it is quite possible that information will be transmitted
air-to-ground and/or in addressed communications such as the Mode S interrogation-
reply data link between transponder equipped aircraft and radar ground stations.
TC Reports are an extension to the Trajectory Change Point (TCP) reporting that was
described in both RTCA DO-242 and RTCA DO-260. During the update to the ADS-B
MASPS to version RTCA DO-242A it was concluded that the previously defined TCP
reporting provisions were not sufficient for the intended purpose. The preliminary
requirements reflected in RTCA DO-242A for TC Reports are intended to accommodate
a variety of airborne capabilities. Thus, some aircraft may broadcast only a subset of the
TC information allowed for by RTCA DO-242A in the TC Report structure. Section
2.1.2.19.2 of RTCA DO-242A describes the operational requirements for TC Reporting
and 3.4.8 of RTCA DO-242A provides the technical and performance requirements for
TC Reporting. RTCA DO-242A does not define the minimum set of TC related
parameters that must be broadcast. RTCA DO-242A defines preliminary requirements
for reporting of information related to the first through forth point at which the aircraft
trajectory will change. The associated reports are designated as TC+0, TC+1, TC+2 and
TC+3 reports. RTCA DO-242A suggests that additional TC Reports may ultimately be
defined. This Appendix specifically addresses only the accommodation of TC+0 and
TC+1 reports with an indication of the potential support for additional TC Reports.
O.2 Summary of Trajectory Change Reporting Requirements

RTCA DO-242A, Table 3-24 defines the content requirements for TC+0 and TC+n
Reports. The broadcast of messages supporting TC+0 Reports will be required for all
Class A2 and Class A3 ADS-B equipped aircraft, as per RTCA DO-242A, Table 3-3(a).
The broadcast of messages supporting TC+n Reports would only be required of Class A3
ADS-B equipped aircraft, as per RTCA DO-242A, Table 3-3(a). Table O-1 below defines
the requirements for TC Report content is a simplified version derived from the Table 3-
24 of RTCA DO-242A.
20xx, RTCA, Inc.

Appendix O
Page O - 4
Table O-1: Proposed Trajectory Change (TC) Report Definition

Needed Only For TC+0 Reports
TC
Report Contents [Notes] [Resolution or # of Bits]
Elem. #
ID 1 Participant Address [24 bits]
2 Address Qualifier [1 bit]
TOA 3 Time of Applicability [1 s resolution]
TC Report # 4 TC Report Sequence Number [2 bits]
TC Report 5a TC Report Cycle Number [2 bits]
Version 5b (Reserved for TC Management Indicator ) [3 bit]
TTG 6 Time To Go [4 s resolution]
Horizontal Data Available and Horizontal
7a [4 bits]
TC Type
7b TC Latitude [700 m or better]
Horizontal 7c TC Longitude [700 m or better]
TC Report 7d Turn Radius [700 m or better]
Information 7e Track to TCP [1 degree]
7f Track from TCP [1 degree]
7g (Reserved for Horizontal Conformance) [1 bit]
7h Horizontal Command/Planned Flag [1 bit]
Vertical Data Available and Vertical
8a [4 bits]
TC Type
8b TC Altitude [100 ft resolution]
Vertical TC 8c TC Altitude Type [1bit]
Report 8d (Reserved for Altitude Constraint Type) [2 bits]
Information
8e (Res. for Able/Unable Altitude Constraint) [1 bit]
8f (Reserved For Vertical Conformance) [1 bit]
8g Vertical Command/Planned Flag [1 bit]
O.3 1090 MHz ADS-B Message for Trajectory Change Information

The Trajectory Change information will be broadcast from the aircraft using a Trajectory
Change (TC) Message. Message TYPE Code 27 has been reserved for this purpose as
indicated in Table 2-11 of these MOPS. For Message TYPE Code 27 a 2-bit SUBTYPE
subfield will be defined with 4 codes reserved for conveying the Trajectory Change
information associated with TC+0 and TC+1 Reports (as required by RTCA DO-242A).
The TYPE Code plus the SUBTYPE subfield would occupy the first 7 bits of the 56-bit
ME field of the extended squitter. This results in the 49 remaining bits being available to
convey the Trajectory Change information. With this limitation on the transmission
frame size, the broadcast of Trajectory Change information will need to be segmented.
Two Trajectory Change Messages will be required to convey the complete set of
Trajectory Change information defined for a complete TC+0 or a TC+n Report.
The preliminary concept would be to define the 4 Message SUBTYPES as shown in

Table O-2.
20xx, RTCA, Inc.

Appendix O
Page O - 5
Table O-2: Proposed TC Message SUBTYPE Values

SUBTYPE = 00 TC+0 Basic Information
SUBTYPE = 01 TC+1 Basic Information
SUBTYPE = 10 1st Supplemental Message
SUBTYPE = 11 2nd Supplemental Message
For SUBTYPEs 00 and 01 there would be 49 bits available to convey the basic
information needed for generation of TC+0 and TC+1 reports. SUBTYPEs 10 and 11
would be used for TC Messages that convey the additional information necessary to
generate a TC+0 or a TC+1 Reports that is beyond the basic TC information being
conveyed in the SUBTYPE=00 or 01 Messages. The TC Message format for conveying
TC supplemental information will use the TC Report Sequence Number and the TC
Report Cycle Number to allow the Supplemental TC information to be correctly
associated the intended Basic TC Messages.
If the TC Basic Message can support the minimum application requirements for the TC
Report, and can therefore be transmitted without an associated TC Supplement Message,
a means conveying whether or not TC Supplemental Messages are being broadcast must
be provided. (Possible means include coding schemes within TC Basic Messages, or
within Operational Status Messages.)
Table O-3 shows how the information required for a TC+0 and TC+1 reports would be
conveyed by the 1090 MHz ADS-B Messages.
It is proposed that if TC+3 or subsequent Trajectory Change points are desired, with the
1090 MHz system, these would be supported only as an addressed air-ground service and
would not be supported as a broadcast service using Extended Squitter.
20xx, RTCA, Inc.

Appendix O
Page O - 6
Table O-3: Bit Allocation for Messages Supporting Trajectory Change Reports
TC Trajectory Change Message SUBTYPEs

Report How conveyed by 1090 MHz
Contents
Element ADS-B Messages
# TC+0 Basic TC+1 Basic Supplemental TC
1 Participant Address Conveyed in Message Header 0 bits 0 bits 0 bits

ID Conveyed in Aircraft ID and
2 Address Qualifier N/A N/A N/A
Category Message
TOA 3 Time of Applicability Added by Receiver N/A N/A N/A
TC Report Sequence Number
TC Report # 4 TYPE 27 ADS-B Message 2 bits 2 bits 2 bits
(conveyed by the SUBTYPE Code)
TC Report 5a TC Report Cycle Number TYPE 27 ADS-B Message 2 bits 2 bits 2 bits
Version 5b (Reserved for TC Management Indicator) TYPE 27 ADS-B Message N//A N/A [note 1]
TTG 6 Time To Go TYPE 27 ADS-B Message 9 bits 9 bits N/A
7a Horizontal Data Available and Horizontal TC Type TYPE 27 ADS-B Message 3 bits [note 2] 3 bits [note 2] N/A [note 2]
7b TC Latitude TYPE 27 ADS-B Message 10 bits 10 bits N/A
7c TC Longitude TYPE 27 ADS-B Message 10 bits 10 bits N/A
Horizontal
7d Turn Radius TYPE 27 ADS-B Message N/A N/A 7 bits
TC Report
7e Track to TCP TYPE 27 ADS-B Message N/A N/A 9 bits
Information
7f Track from TCP TYPE 27 ADS-B Message N/A N/A 9 bits
7g (Reserved for Horizontal Conformance) TYPE 27 ADS-B Message N/A N/A [note 1]
7h Horizontal Command/Planned Flag TYPE 27 ADS-B Message 1 bit 1 bit N/A
8a Vertical Data Available and Vertical TC Type TYPE 27 ADS-B Message 3 bits [note 2] 3 bits [note 2] N/A
8b TC Altitude TYPE 27 ADS-B Message 10 bits 10 bits N/A
Vertical TC 8c TC Altitude Type TYPE 27 ADS-B Message 1 bit 1 bit N/A
Report 8d (Reserved for Altitude Constraint Type) TYPE 27 ADS-B Message N/A N/A [note 1]
Information 8e (Reserved for Able/Unable Altitude Constraint) TYPE 27 ADS-B Message N/A N/A [note 1]
8f (Reserved For Vertical Conformance)] TYPE 27 ADS-B Message N/A N/A [note 1]
8g Vertical Command/Planned Flag TYPE 27 ADS-B Message N/A N/A 1 bit
Spare Bits 0 0 19
ME Bits for TYPE Code 5 5 5
TOTAL ME Bits 56 56 56
Notes:
1. Report elements indicated by RTCA DO-242A as reserved are not assigned bits. If required by a future ADS-B MASPS revision, such report elements would be
accommodated within a Supplemental TC Message using the spare bits.
2. Although RTCA DO-242A assumes 4 bits are provided for this parameter, less than eight values were assigned by RTCA DO-242A with the remainder being reserved. In
order to provide the most efficient use of the 1090 MHz ADS-B Message structure, the allowed values for this parameter within the TC+0 and TC+1 Messages will be
restricted to the range of 0 to 7, requiring only 3 bits for encoding. If in the future a need arises that requires values that cannot be accommodated within 3 bits, then a
binary value of 111 could be used to indicate that the value of the parameter is 7 or greater, and the specific value would then be included in the Supplemental TC
Message.
20xx, RTCA, Inc.

Appendix O
Page O - 7
O.4 Transmission Rate Requirements

RTCA DO-242A does not define a specific update rate requirement for TC+0 or TC+1
Reports. However, RTCA DO-242A, Appendix N provides an estimate for TC+0
Reports where air-to-air update rates are range dependent. RTCA DO-242A, Table N-8
defines a nominal update interval at 95% probability for TC+0 Reports as:
Range < 20 NM --- Update Interval = 12 seconds (Class A2 and A3 systems)

Range = 40 NM --- Update Interval = 18 seconds (Class A2 and A3 systems)
Range = 90 NM --- Update Interval = 41 seconds (Class A3 systems)
RTCA DO-242A, Table N-8 also defines a 12-second update interval following a TC+0
state change at ranges to 40 NM.
No update rates are provided for air-to-ground delivery of TC information, nor is the role
of the ground ATM system adequately considered in the operational concept presented in
the RTCA DO-242A, Appendix N.
The 1090 MHz ADS-B TC Messages required to support conveying the complete
information defined by RTCA DO-242A for a TC+0 Report includes both the TC+0
Basic and the 1st Supplemental TC Messages. However, it may be possible to transmit
the TC+0 Basic Message at a higher rate than the TC Supplemental Message since the
TC+0 Basic Message provides the most essential information and a small delay in
receiving updates to the supplemental information may be acceptable. It is also probable
that some or perhaps many Class A2 and A3 aircraft will not be equipped to provide
other than the Basic TC information. In this case, if it is operationally determined that
this information is satisfactory to support the desired applications, then the Supplemental
TC Message would not be required. It is not possible at this time to establish the specific
update rate requirements for the individual data elements defined by RTCA DO-242A for
the TC+0 Reports. As the operational concepts and definition of applications that use TC
Reports mature, this may become possible. The other 1090 MHz ADS-B Messages and
their associated nominal broadcast rates that will routinely be broadcast for an Airborne
Class A2 or A3 system are:
Position: 2.0 per second
Velocity: 2.0 per second
AC ID & Type: 0.2 per second
Operational Status: 0.4 per second
Target State: 0.8 per second
Total: 5.4 per second
These MOPS, as well as the Mode S Transponder MOPS (RTCA DO-181D), limit the
total transmission rate of all Extended Squitters to 6.2 per second. This means that if
implemented under the current overall rate limit of 6.2 squitters per second, the broadcast
of Trajectory Change information would need to be limited to not more than 0.8
messages per second. Given this current overall limit of 6.2 squitters per second, only
TC+0 can be considered and supported. Support for TC+1 Messages will require an
increase in the overall rate limit. Since the complete set of TC information requires both
a Basic TC Message plus a TC Supplemental Message, there are two alternatives:
20xx, RTCA, Inc.

Appendix O
Page O - 8
1. Broadcast both the Basic TC+0 Message and the associated Supplemental TC
Message at a rate of 0.4 (i.e., at 2.5 second intervals).
2. If it is deemed appropriate to update the data elements contained in the

Supplemental TC Message at a lower rate than the information included in the Basic
TC+0 Message, then it may be appropriate to broadcast the Basic TC+0 Message at
perhaps 0.5 messages per second and the TC+0 Supplemental Message at perhaps a
rate of 0.3 messages per second.
As indicated above, there may be many aircraft that are only capable of broadcasting the
information included in the Basic TC Message (i.e., TC Supplemental Message not being
broadcast), in which case the Basic TC Message could be broadcast at the rate of 0.8
messages per second.
Even support for TC+0 could be enhanced by allowing for a total Extended Squitter
broadcast rate above the current limit of 6.2 squitters per second. Ideally, the TC+0
related messages, or at least the Basic TC+0 Message would be broadcast at the same rate
as that used for the Target State Messages (0.8 per second). If both of the TC+0
Supplemental Messages were each to be broadcast at 0.8 per second, then the maximum
Extended Squitter broadcast rate would need to be raised to 7 per second for those
aircraft equipped to provide the full set of TC information.
Accommodating both the TC+0 and TC+1 related messages will require that the
maximum allowed Extended Squitter rate be increased to at least 7 squitters per second
and more realistically to perhaps on the order of 8 squitters per second.
These above suggested maximum rates are considered appropriate to satisfy the RTCA
DO-242A preliminary requirements and estimates for aircraft-to-aircraft reporting of
Trajectory Change information in moderate to perhaps high density airspace (at up to 40
NM). In low density airspace the reception probabilities increase because of lower 1090
MHz fruit rates and as a result, more modest transmission rates would suffice to support
the required reception ranges and TC Report update rates.
O.5 Estimated Performance
O.5.1 TC+0 Performance Estimate

There are many factors that will impact the ability of the 1090 MHz ADS-B system to
deliver Trajectory Change information. As discussed above in O.4 there are a number
of alternatives as to the rate at which TC+0 messages are broadcast. The broadcast rate
will depend on both the aircraft equipage (e.g., only able to provide basic TC information
versus more extensive TC information) and also on the ability to revise the Mode S
transponder standards, both within RTCA and ICAO, to permit an increase in the peak
transmission rates for Extended Squitters. The full set of TC+0 Report information must
be split into two Extended Squitter Messages for transmission. For the case where a
given aircraft is only capable of providing the information contained in the Basic TC+0
Message, reception of this single message type will be sufficient to generate an TC+0
Report. For the case of an aircraft equipped to provide the full TC+0 information set,
then the reception of both a Basic TC+0 and a Supplemental TC+0 Message would be
required in order to update the TC+0 Report.
20xx, RTCA, Inc.

Appendix O
Page O - 9
Given these uncertainties and potential variations in the broadcast capabilities, estimates
were developed for three alternative cases for the broadcast of TC+0 Messages.
Simulations runs have not been specifically conducted for these alternative cases. Rather
a simplified approach was employed where the per squitter reception probability was
calculated that would be required to satisfy the RTCA DO-242A, Appendix N guidance
material for TC+0 Report nominal update rates. The simulation results were then
reviewed to estimate at what range the calculated per squitter reception probability would
be supported. Since two different simulations were used to estimate the performance,
both the results from the Johns Hopkins-APL simulations and the results from the MIT
Lincoln Laboratory simulations are provided. These simulations are described in
Appendix P of these MOPS. The simulation results are presented for both a low density
traffic environment as well as the postulated future Los Angles traffic environment for
the year 2020. The LA2020 scenario with 24,000 Mode A/C fruit per second
interference level was used for the analysis of TC reception performance in a high density
environment. The effects of increased loading on the 1090 MHz channel from the
increased rate of Extended Squitter transmissions that would be necessary to
accommodate TC Reporting have not been considered in the analysis. The effect of the
increased channel loading is expected to be minor for the case where the total Extended
Squitter transmission rate is limited to 6.2 squitters per second. As the requirements for
TC Reporting mature, further studies should be conducted to determine an appropriate
upper limit on Extended Squitter transmission rates and under what conditions such
maximum transmission rates would be permitted.
Note that the applicability of TC reporting is currently limited within RTCA DO-242A to
air-to-air ranges of up to 40 NM within high density airspace as represented by the
LA2020 scenario, and up to 90 NM in low density airspace. RTCA DO-242A does note,
however, that the minimum range required may apply even in high interference
environments, such as over-flight of high traffic density terminal areas.
RTCA DO-242A also proposed increased reporting rates following a change in certain
elements of the TC Reports. The 1090 MHz ADS-B system could accommodate this by
temporarily lowering the broadcast rate of lower priority messages. This is supported by
the message scheduling function defined in these MOPS. However, the potential
requirement for increased TC+0 reporting rates following a change in TC information is
not specifically considered in the following performance analysis (i.e., only the nominal
TC+0 reporting case is considered).
Case 1
The first case to be considered is that in which only the Basic TC+0 Message is being
broadcast. In this case it is assumed that the TC+0 Messages would be broadcast at the
same rate as used for the Target State and Status Messages (i.e., 0.8 messages per
second). In order to support the ADS-B MASPS guidance for TC+0 Report updates at
95% probability, the nominal required per message reception probability is described by
the formula: 0.95 = 1 (1-Pmessage)N or rewriting for calculating the necessary per
squitter reception probability: Pmessage = 1 (1 - 0.95)1/N where N is the number of
transmissions within the required received update interval. The following table indicates
the per message reception probability needed to satisfy the RTCA DO-242A guidance for
the nominal air-to-air reporting of TC+0 information at ranges of 20, 40 and 90 NM.
20xx, RTCA, Inc.

Appendix O
Page O - 10
Table O-4: Case 1 TC Message Reception Probability

TC+0 Report Required Message
Air-Air Range
Nominal Update Rate Reception Probability
20 NM 12 Seconds 26.8%
In Case 1, the effective reporting rate for TC+0, in which only a Basic TC+0 Message is
being broadcast, would be essentially the same as for TS Reports as described in
Appendix P. The estimated TC+0 reporting rate is summarized in the Table O-5 and
Figures O-1, O-2 and O-3 for the LA2020 and low traffic density scenarios. These
performance estimates are for the case of Class A3 receiving systems.
Table O-5: Case 1 TC Report Performance

Estimated Air-Air Estimated Air-Air Estimated Air-Air
TC+0
Range for Low Range LA2020 Range LA2020
Report
Density Scenario Scenario Scenario
Update
(A3 Tx -to- A3 Rx) (A2 Tx -to- A3 Rx) (A3 Tx -to- A3 Rx)
Rate
APL LL APL LL APL LL
12 Sec. 90 NM 115 NM 30 NM 24 NM 40 NM 30 NM
20xx, RTCA, Inc.

Appendix O
Page O - 11
50
40
APL Results
LL Results
TCR Update Period (sec.)
30
20
MASPS GUIDANCE
10
0
0 10 20 30 40 50 60 70 80 90 100
Air-Air Range (NM)
Figure O-1: Case 1 LA2020-[24k] for A3 Tx -to- A3 Rx
20xx, RTCA, Inc.

Appendix O
Page O - 12
60
50
40
APL Results
LL Results
30
20
MASPS GUIDANCE
10
0
0 10 20 30 40 50 60 70 80 90
Air - Air Range (NM)
20xx, RTCA, Inc.

Appendix O
Page O - 13
60
50
APL Results @
TCR Upadate Period (sec.)
5K Mode A/C
40 Fruit
30 LL Results
(@ 5K Mode A/C
Fruit)
20
MASPS GUIDANCE
10 LL Results
(@ 1.25K Mode
A/C Fruit)
0
0 20 40 60 80 100 120 140
Air-Air Range (NM)
Figure O-3: Case 1 Low Density A3 Tx -to- A3 Rx
Case 2
For Case 2, the full TC+0 information set is split between a Basic and a Supplemental
TC+0 Message and each message is broadcast at the rate of 0.8 messages per second.
This case would only be possible if the allowed peak Extended Squitter broadcast rate
were increased to 7 Extended Squitters per second or greater. In order to support the
ADS-B MASPS guidance for TC+0 Report updates at 95% probability the nominal
required per message reception probability is described by the formula: 0.95 = [1 (1-
Pmessage)N]2 or rewriting for calculating the necessary per squitter reception probability:
Pmessage = 1 [1- (0.95)1/2]1/N where N is the number of transmissions within the required
received update interval. Table O-6 indicates the per message reception probability
needed to satisfy the RTCA DO-242A guidance for the nominal air-to-air reporting of
TC+0 information at ranges of 20, 40 and 90 NM.

Air-Air Range
20xx, RTCA, Inc.

Appendix O
Page O - 14
In Case 2, the effective reporting rate for TC+0 information, in which both a Basic TC+0
Message and a Supplemental TC+0 Message is being broadcast, the estimated TC+0
reporting rate is summarized in Table O-7 and Figure O-4, Figure O-5 and Figure O-5 for
the LA2020 and the low traffic density scenarios for the case of Class A3 receiving
systems.

TC+0
Report
Update
Rate
60
50 APL Results
40
LL Results
30
20
MASPS GUIDANCE
10
0
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70
Air-Air Range (NM)
20xx, RTCA, Inc.

Appendix O
Page O - 15
60
50
APL Results LL Results

40
30
20
MASPS GUIDANCE
10
0
0 10 20 30 40 50 60 70 80 90
Air-Air Range (NM)
20xx, RTCA, Inc.

Appendix O
Page O - 16
60
LL Results
(@ 5K Mode A/C
50 Fruit)
APL Results @
5K Mode A/C
Fruit
40
30
20
MASPS GUIDANCE
10
LL Results
(@ 1.25K Mode
A/C Fruit)
0
0 20 40 60 80 100 120 140
Air-Air Range (NM)
Case 3
For Case 3, it is assumed that both a TC+0 Basic and a TC+0 Supplemental Messages
would be broadcast at 0.4 messages per second. This would be the worst-case situation,
in which the peak Extended Squitter transmission rate is limited to 6.2 squitters per
second, where the aircraft is sending the full TC+0 information set and where the
supplemental information could not be updated at a lower rate than the basic information.
In order to support the ADS-B MASPS guidance for TC+0 Report updates at 95%
probability, the nominal required per message reception probability is described by the
formula: 0.95 = [1 (1-Pmessage)N]2 or rewriting for calculating the necessary per squitter
reception probability: Pmessage = 1 [1- (0.95)1/2]1/N where N is the number of
transmissions within the required received update interval. The Table O-8 indicates the
per message reception probability needed to satisfy the RTCA DO-242A guidance for the
nominal air-to-air reporting of TC+0 information at ranges of 20, 40 and 90 NM.

Air-Air Range
20xx, RTCA, Inc.

Appendix O
Page O - 17
In Case 3, the effective reporting rate for TC+0, in which both a Basic TC+0 Message
and a Supplemental TC+0 Message is being broadcast, and the broadcast rate for each is
0.4 messages per second, the estimated TC+0 reporting rate is summarized in Table O-9
and Figure O-7, Figure O-8 and Figure O-9 for the LA2020 and the low traffic density
scenarios for the case of Class A3 receiving systems.

TC+0
Report
Update
Rate
60
50
40
LL Results
30
APL Results
20
MASPS GUIDANCE
10
0
0 5 10 15 20 25 30 35 40 45 50
Air-Air Range (NM)
20xx, RTCA, Inc.

Appendix O
Page O - 18
60
50
40 APL Results
30
20
LL Results
MASPS GUIDANCE
10
0
0 5 10 15 20 25 30 35 40 45 50
Air-Air Range (NM)
20xx, RTCA, Inc.

Appendix O
Page O - 19
60
50
APL Results @
5K Mode A/C
40 Fruit
LL Results
(@ 5K Mode
A/C Fruit)
30
20
LL Results
(@ 1.25K Mode
MASPS GUIDANCE
A/C Fruit)
10
0
0 20 40 60 80 100 120 140
Air - Air Range (NM)
O.5.2 TC+1 Performance Estimate

The broadcast of TC+1 information in support of an air-to-air application should only be
considered on 1090 MHz if the allowed peak Extended Squitter rate is increased above
the current RTCA MOPS and ICAO SARPs limit of 6.2 squitters per second. If the limit
were increased to the order of 8 to 8.6 squitters per second then the performance for
TC+1 reporting would be similar to that described above in O.5.1 for Case 1 and Case
2. However, in order to limit channel loading and in order to gain ICAO acceptance for
an increase in the peak allowed squitter rate, the transmission of TC+1 Messages might
need to be limited to operations above a fixed altitude threshold, such as only in high
altitude en route airspace where airborne flight path de-confliction might be operationally
authorized.
O.6 Other Factors and Issues

The performance estimates presented above in O.5 address only the air-to-air reception
of TC information. It is possible that the primary needs for TC information are not best
served by the exclusive use of ADS-B as the delivery mechanism and/or are not best
offered as an air-to-air service. For example, this could be the case with high density
terminal environments where the responsibility for aircraft separation will remain the
responsibility of the ATC controller and supported by the ground automation tools. For
this case, addressed Mode S services may be a technically superior method for the ground
ATC automation system to obtain the aircrafts intent information. Once the intent
information is obtained by the ground ATC automation and used by the ground decision
20xx, RTCA, Inc.

Appendix O
Page O - 20
support tools, it may be appropriate to employ an addressed (or broadcast) ground-to-air

communications service to provide airborne applications with the information they to
achieve conflict free flight paths.
The air-to-ground performance for 1090 MHz Extended Squitter is substantially better
than for the air-to-air case. This is a consequence of the use of substantially higher gain
antennas at the ground stations and the ground station receivers are subjected to
substantially lower levels of co-channel interference (i.e., fruit) as a result of Earth
curvature and other line-of-sight obstructions. Also ground stations equipped with sector
antennas are expected to achieve further improvements improved signal strength and
reduced interference levels. Furthermore, the networking of multiple ground stations can
provide a more robust service with higher effective update rates. The rate at which TC
information is broadcast may need to be tailored to satisfy the most important of the
operational needs. This could imply that the broadcast rate, and perhaps the information
contents of TC Messages, be varied depending on the operational environment in which
the aircraft is operating. A simple example would be to include an altitude dependency
on the types of intent information being broadcast (e.g., TC+1 only broadcast above a
fixed altitude).
O.7 Conclusions
The predicted performance for the reception of Trajectory Change information on 1090
MHz ADS-B is expected to well exceed the RTCA DO-242A, Appendix N, guidance on
TC+0 Report update rates in low density environments where air-to-air ranges in excess
of 100 NM are possible.
For the future LA2020 high density scenario the two simulation models employed for this
assessment have produced similar results. Both sets of simulation results indicate that for
Class A3 receivers receiving broadcasts from Class A3 transmitters it may be possible to
satisfy the ADS-B MASPS guidance for TC+0 reporting at air-to-air ranges of
approximately 40 to 50 NM if only TC Basic messages are being transmitted as described
in Case 1. The performance for all three (3) Cases are summarized in Table O-10. At
longer air-to-air ranges the effective update rate for TC+0 Reports would fall below the
ADS-B MASPS guidance, but may prove usable for certain applications at ranges up to
60 NM where TC+0 updates rates of less than 40 seconds may be practical.
The performance for the reception of TC broadcasts from Class A2 systems being
received by Class A3 systems is predicted to fall short of the ADS-B MASPS guidance in
the case of the LA2020-[24k] scenario. For the case the ADS-B MASPS guidance on TC
Report rates is predicted to be satisfied at air-to-air ranges to on the order of 20 to 30 NM
if only TC Basic messages are being transmitted as described in Case 1. The
performance for all three (3) Cases are summarized in Table O-10. However, beyond 30
NM the TC reporting rates may prove to be useful to certain applications at ranges of
perhaps up to 40 NM where a TC Report update rate of less than 30 seconds may be
possible.
However, in order to support such air-to-air ranges in the LA2020-[24k] scenario, and
also to support the TC Report complete set of parameters defined in RTCA DO-242A,
the peak transmission rate for Extended Squitters would need to be increased above the
currently allowed maximum of 6.2 squitters per second. Support for TC+1 would also
require an increase in the maximum rate allowed for Extended Squitter transmission.
20xx, RTCA, Inc.

Appendix O
Page O - 21
For the case of an enroute aircraft directly over-flying LAX, the duration of time in
which the air-to-air performance would be limited to the above ranges is perhaps 5
minutes or less. This is a consequence of the simulation models only considering the
case in which the receiving aircraft is in the worst-case interference environment (i.e.
near LAX). Experience from the 1090 MHz data collection conducted by the FAA in
1999 suggests that the 1090 MHz interference levels peak in the immediate vicinity of
LAX and decrease away from this area.
It must be noted that the above analysis and conclusions are based on the air-to-air
delivery of TC information in support of airborne based applications. In certain
operational environments it may be more appropriate to focus on the air-to-ground
delivery of TC information in support of ground-based ATC automation tools, rather than
in support of airborne based applications. It is expected that for the air-to-ground
delivery of TC Messages, the desired update rates could be achieved using the 1090 MHz
ADS-B system within a future high density environment, such as represented by the
LA2020 scenario.
Table O-10: Summary of TC Performance
Case 1 Case 2 Case 3

TC Basic & TC Basic &
Messages Sent TC Basic
Supplemental Supplemental
Extended Squitter Rate 6.2 ES / sec 7.0 ES / sec 6.2 ES / sec
TC Message Rate 0.8 msg / sec 0.8 msg / sec 0.4 msg / sec
A3-to-A3 with 24K Fruit 40 50 NM 27 40 NM 10 15 NM
A3-to-A3 with 5K Fruit > 120 NM > 120 NM > 120 NM
A2-to-A3 with 24K Fruit 23 30 NM 20 22 NM 10 12 NM
20xx, RTCA, Inc.

Appendix O
Page O - 22
20xx, RTCA, Inc.

Appendix P
1090 MHz System Performance Simulation Results


Appendix P
Page P - 3
P 1090 MHz System Performance Simulation Results
P.1 Introduction
The air-to-air performance of 1090 MHz Extended Squitter (1090 ES) has been
evaluated, as described in this Appendix. Two detailed evaluations were carried out
using different techniques, although the air traffic scenarios evaluated were the same.
The results from the two evaluations are relatively close and tend to support each other.
One evaluation was carried out by the Johns Hopkins University Applied Physics
Laboratory (APL), and is described in Section P.2. The other evaluation was performed
by MIT Lincoln Laboratory (LL), and is described in Section P.3. In both cases, the
evaluations were applied to the Los Angeles Basin High Density (LA) scenario and the
Low Density scenario defined in the ADS-B MASPS (RTCA DO-242A). This scenario
is a future estimate derived by applying a growth factor of 1.5 to measured values. For
the LA scenario, two cases were considered. In order to represent two potential worst-
case interference environments, a nominal case with Mode A/C fruit rate of 24,000 per
second, herein referenced as LA-[24k], and a more severe case of 30,000 Mode A/C
fruit per second, herein referenced as LA-[30k]. These scenarios are intended to
represent the worst-case location for ADS-B reception within the LA Basin.
In other respects, very similar or identical models were used in the two evaluations.
Aircraft Antenna Gain. The Technical Link Assessment Team (TLAT) model for
aircraft antenna gain was used in both evaluations. This model, which is documented
in Reference P-1, includes a function giving antenna gain vs. elevation angle, and
also includes a statistical component, which has a defined distribution. The statistical
distribution has a bell-shaped curve, skewed slightly toward negative values.
Transmitter Power. The following statistical models were used in both evaluations.
For class A0, power referred to the antenna is uniformly distributed between 48.5 and
51.5 dBm. For class A1 and class A2, power referred to the antenna input is
uniformly distributed between 51 and 54 dBm. For class A3, power referred to the
antenna is uniformly distributed between 53 and 56 dBm.
Receiver MTL. Receiver MTL was treated as a constant in both evaluations, and was
set to the worst-case value permitted by these MOPS.
Fruit rates. Steps were taken to match the fruit rate models in the two evaluations.
This was done by beginning with the APL model, running the part of the evaluation
whose output is fruit rate and power distribution, shown separately for Mode A/C
fruit and Mode S fruit. These curves were then used as inputs to the LL evaluation.
The LL evaluation was performed under fruit conditions matched to the APL fruit
rate results.
Analytical models and detailed simulations of data links operating in future scenarios are
necessary to assess expected capabilities in stressed circumstances. Accurately modeling
future capabilities for potential system designs in a fair way, however, is challenging.
Since validation of simulation results in future environments is unrealistic, other means
of verification such as the following are required. System characteristics represented in
these simulations should agree with actual measurements on components of the proposed
2009, RTCA, Inc.

Appendix P
Page P - 4
design, e.g., bench measurements on prototype equipment and calibrated flight test data
should be used, when possible, for the receiver/decoder capabilities and as comparison
with modeled link budgets. Similarly, suitable interference models help to support
estimates of how these conditions may change in future scenarios. Credibility of any
simulation results for future scenarios also requires that they be able to model current
conditions and provide results that appropriately agree with measurements made under
these conditions. Existing tools have been used as crosschecks where possible for the
final detailed simulations and models. The differences between the results of the two
evaluations are not surprising, given the above considerations and the different
simulation approaches.
P.2 Performance Evaluation by APL

This section presents the evaluation of 1090 ES performance by APL, using the
simulation models and techniques discussed below.
P.2.1 1090 Extended Squitter Detailed Simulation Features and Methodology

The APL 1090 ES detailed simulation is written in C and allows for horizontal, constant-
velocity motion of the aircraft in the scenario. The simulation reads in the inputs
specifying the particular case to be run (including a co-channel interference environment
file produced by the Volpe/TASC simulator cited as Reference P-2), generates all of the
ADS-B transmissions and additional interference for 300 seconds, calculates signal levels
and times of arrival for each of these transmissions, and determines the corresponding
message error rates for each ADS-B transmission at the individual times of arrival by all
aircraft within line of sight of the victim receiver. This information is then written to an
output file, one entry line for each ADS-B transmission, which is then analyzed by post-
simulation software. A number of the real-world effects included in the simulation are
discussed in Section P.2.1.1. Section P.2.1.2 will describe the post-simulation processing
of the data.
P.2.1.1 1090 ES Detailed Simulation Features

This section describes some of the features of the 1090 ES detailed simulation:
Propagation and other losses. The 1090 ES simulation calculates the free-space
propagation loss for each transmission, using the range between transmitter and
receiver at the time of transmission. There is also a receiver cable loss of 3 dB
incorporated in the calculation. An optional transmit cable loss is also included in the
simulation, but since the transmit powers have been defined at the antenna, the
transmit cable loss has been set to zero for this study.
Antenna gains. The antenna gain model used here was that specified in the TLAT
Report [Reference P-1].
Propagation delays. The propagation delay incurred by the signal in traversing the
free space between transmitter and receiver has been included in the 1090 ES
simulation.
Co-channel interference. The 1090 ES transmissions co-exist with transmissions
from other sources at the same frequency, such as Mode A/C, Mode S, and TCAS
replies. These transmissions are responses to interrogations originating from ground
interrogators and, in the case of TCAS, other aircraft. The ground interrogator
2009, RTCA, Inc.

Appendix P
Page P - 5
environment is described in the TLAT report [Reference P-1]. All A2 and A3

aircraft are assumed to be equipped with TCAS, for a total of 40% of all aircraft in
the LA- scenario. The cases evaluated had no loading of the channel due to Mode S
air-ground data link. Several different estimates of the co-channel interference
environment were examined for the high-density LA scenario:
24,000 Mode A/C, 2,500 Mode S at levels greater than 84 dBm
30,000 Mode A/C, 3,600 Mode S at levels greater than 84 dBm
For the low density scenario, a rate of 5,000 Mode A/C was used.
Co-site interference. Co-site transmissions of 1090 ES messages, DME
interrogations, Mode S interrogations and replies, whisper-shout interrogations, and
Mode A/C replies are all modeled as interference in the 1090 ES simulation. All of
these are treated as self-interference, and it is assumed that no 1090 ES reception
may occur during any of these co-site transmissions (including a 15 microsecond
ramp-down period added to the end of each co-site transmission). (See RTCA DO-
282 for more detailed explanation of the co-site interference environment.)
Multiple interference sources. The arrivals of 1090 ES messages at the victim
receiver is a random process, due to the random nature of the transmissions and the
propagation delays. There may be a number of messages and other interfering
signals (e.g., Mode A/C) overlapping one another, and these overlaps will be for
variable amounts of time. This interference is accounted for in the multi-aircraft
simulation. Multiple interferers are treated in the receiver performance model by
combining their interference levels in a way consistent with bench test measurements.
The simultaneous presence of 1090 ES interference, co-channel interference, and
self-interference is treated in a detailed fashion by the model.
Alternating transmissions. The model simulates the alternating transmission
sequence between top and bottom antennas as specified for A1, A2, and A3
equipage. For A0 equipage, the model simulates transmission from a top antenna.
Receiver diversity. For A1, A2, and A3 equipage, the model simulates receiver
diversity by calculating the message error rate at both the top and bottom receive
antennas and calculating the joint reception probability. For A0-equipped aircraft,
reception is only permitted from a top antenna.
Transmit power variability. The transmit power specified at the antenna of an aircraft
is chosen from a uniform distribution given by the limits specified by the authors of
these MOPS for the aircraft equipage. For this analysis the ranges used were:
A3: 53-56 dBm
A2/A1: 51-54 dBm
A0: 48.5-51.5 dBm
Note: These ranges were selected as being representative of equipment expected to

be produced and deployed. It should be noted, however, that these MOPS
allow for larger ranges of transmit powers and include, for example, the
possibility of an A3 transmit power as low as 51 dBm.
Receiver re-triggering. The 1090 ES simulation checks each individual ADS-B
message arriving at the victim receiver for its message error rate. This procedure
amounts to allowing for re-triggering in the receiver, i.e. the potential for the receiver
2009, RTCA, Inc.

Appendix P
Page P - 6
to switch from receiving a message to a stronger message signal that arrives after the
start of the reception of the first message.
Receiver performance model. The receiver performance model used in the 1090 ES
simulation is based on experimental data collected on 1090 receivers that were
provided for that purpose. The measurement data for these receivers were modified
by simulation results provided by MIT Lincoln Laboratories (LL) and the FAA
William J. Hughes Technical Center (FAATC). These simulation results were
designed to emulate the enhanced decoding techniques, which have been
incorporated as performance requirements for 1090 ES equipment. The development
of the receiver performance model is described in Section 2 of this Appendix. The
assumed sensitivity of the receiver is different for the different equipage classes, -84
dBm for class A3 and -79 dBm for A2/A1 equipage. This represents the signal level
at which 90% of the messages are received correctly in the absence of interference.
This parameter was validated in the simulation by examination of the signal vs.
message error rate in the absence of interference. However, because the MOPS
requirement of 15% message success at 87 dBm for A3 equipage is a more severe
constraint, the effective MTL required is around 85.5 dBm for A3 aircraft. This is
the value that was used in this analysis. The A1 equipage class receiver does not
require the enhanced decoding techniques, so a different receiver performance model
was used to evaluate A1 performance.
Message transmission frequency and content. Section 2.2.3 defines the types of
messages, their content, and the frequency of messages transmitted for each category
of aircraft equipage. This is modeled in detail by the 1090 ES simulation.
P.2.1.2 Calculation of the Performance Metrics

The result of the 1090 ES detailed simulation is a file containing time-ordered
information about each ADS-B squitter transmitted by every aircraft within line-of-sight
of the victim receiver during the 300-second duration of the simulation. The main
elements of information for each individual squitter include squitter type (information
content) and the probabilities of reception on each of the top and bottom receive
antennas. Each squitter will have individual reception probabilities which depend not
only on signal level at each receive antenna at that time, but also on the interference
environment at each of the antennas during the arrival of the squitter.
For each transmitting aircraft in a range bin of width ten nautical miles, the time-ordered
sequence of squitters is then examined, and, using Monte Carlo techniques and the
reception probabilities at each of the antennas, it is determined which of that transmit
aircrafts squitters are successfully decoded by the receiver during the 300-second
interval. From these successes, the State Vector update times are determined by
computing the time difference between arrivals of successive squitters containing either
position or velocity information. These update times are then ordered, and the 95 th
percentile value is then chosen. This value represents the 95th percentile update time for
that particular transmitting aircraft. This procedure is then followed for each transmitting
aircraft, resulting in a 95th percentile update time for each aircraft.
All of the 95th percentile update times for all of the aircraft in each range bin are then
ordered, and the 95th percentile of these update times is selected for the 95-95 State
Vector update time. Thus, 95% of the aircraft in each range bin will have a 95% State
Vector update time that is better than the 95-95 value for that bin.
2009, RTCA, Inc.

Appendix P
Page P - 7
The same procedure is then followed for the messages supporting Target State (TS)
Reports, to determine the 95-95 update time for that type of message. The results of this
analysis are presented in Sections P.2.3.2 and P.2.4.2 below, and results and conclusions
are presented in Section P.2.5.
P.2.2 Receiver Performance Model
P.2.2.1 Background
In order to develop a receiver performance model for 1090 Extended Squitter (ES) to be
used for the Technical Link Assessment Team (TLAT) ADS-B data link evaluation,
bench test measurements of the Message Error Rate (MER) receive performance were
made on an available 1090 ES receiver, which included a number of features of enhanced
decoding. Development of this receiver performance model is described in the TLAT
Report Appendix I. Subsequent to publication of the TLAT Report in April, 2001, the
results of these measurements, compared with flight test measurements, led to the
judgment that this receiver implemented a multi-sample technique that was not as
effective at decoding 1090 ES messages as the multi-sampling technique incorporated in
these MOPS. Thus, although some features of enhanced decoding were implemented in
the tested receiver, it was felt that better performance could be achieved through
modification of the decoding processing. For A2 and A3 category aircraft, these MOPS
require performance equivalent to that achieved by the multi-sample techniques.
Therefore, the receiver performance model was adapted to reflect those requirements.
P.2.2.2 Modifications to the Receiver Performance Model

The FAATC and LL developed and implemented simulations to predict 1090 ES receiver
performance using enhanced decoding techniques, including multi-sampling. Several
cases of Mode A/C interference were investigated, which led to detailed results for these
cases being available for comparison with the predictions of the receiver performance
model. The model was adjusted to account for these cases, resulting in a modified
receiver performance model.
This modified receiver performance model was discovered to produce optimistic

predictions in high-density environments, when compared with the overall results of the
FAATC and LL predictions in these environments. It is not surprising that the results,
which were based on a very small sample of the interference space, should differ from
what is produced when extrapolated to and averaged over the entire high-density
interference space. It was decided that it is more important to reflect the overall effects of
the entire interference environment than to exactly replicate the few individual cases
upon which the revised model was based.
The methodology adopted for this second modification of the receiver performance
model was to map the model results to be consistent with the simulation results of the
FAATC or LL, as appropriate. FAATC results were achieved by feeding video signals
into a 1090 ES receiver front end and performing non-real-time software processing to
determine message reception in a simulated high-density Mode A/C environment. The
results were presented as the total message success probability as a function of the
received desired signal level for the total Mode A/C interference environment. Individual
cases were not identified, so a message success probability for a given signal level
2009, RTCA, Inc.

Appendix P
Page P - 8
represents the averaging done over many different individual interference situations
which characterize the entire interference environment.
For the A2 receiver, LL results were achieved by software simulation of signals and high-
density interference (including phase and frequency fluctuations) and performing pulse-
by-pulse non-real-time analysis to determine message reception. Again, as for the A3
results from the FAATC, the A2 results from LL (see Figure P-19) were presented as the
total message success probability as a function of the received desired signal level for the
total interference environment.
When compared to the results from the FAATC and LL simulations, which sampled the
entire interference environment, the receiver performance model was found to be overly
optimistic in its predictions of performance. In order to compensate for this bias, the
receiver performance model was mapped separately to conform to the results of each of
the two simulations, as illustrated for an A3 receiver in a 30,000 Mode A/C fruit
environment shown in Figure P-1 below. This mapping was done separately to adjust the
receiver performance model to the various interference levels and receiver sensitivities.
1
APL Mapped Data
Tech Center Data
0.9
0.8
0.7
0.6
Pct. Det.
0.5
0.4
0.3
0.2
0.1
0
-90 -85 -80 -75 -70 -65
Signal Level (dBm)
Figure P-1: Comparison of Mapped APL Receiver Performance Model Prediction with FAATC
Simulation Results
Each of the various mappings (corresponding to scenario, fruit level, and multi-sampling
type) was used for the appropriate receiver case. For example, to evaluate Class A3
performance in the 24,000 Mode A/C LA scenario, the receiver performance model was
mapped to match the FAATC results for the 10 MHz sampling rate enhanced decoder for
this fruit rate.
2009, RTCA, Inc.

Appendix P
Page P - 9
P.2.3 Los Angeles Basin High Density (LA)
P.2.3.1 LA Scenario Description

This scenario is based on the LA Basin 1999 maximum estimate. It is assumed that air
traffic in this area would increase by a few percent each year until it would be 50 %
higher than in 1999. The distribution of aircraft in the scenario is based on
approximations of measured altitude and range density distributions.
The following assumptions are made for the airborne and ground aircraft, and ground
vehicles for the LA Basin scenario:
The density of airborne aircraft is taken to be:
Constant in range from the center of the area out to 225 nautical miles (5.25
aircraft/NM), (i.e., the inner circle of radius one NM would contain
approximately five aircraft, as would the ring from 224 to 225 NM) and
Constant in area from 225 NM to 400 NM (.00375 aircraft/NM2).
There are assumed to be a fixed number of aircraft on the ground (within a circle of
radius 5 NM at each airport), divided among LAX, San Diego, Long Beach, and five
other small airports, totaling 225 aircraft. Half of the aircraft at each airport were
assumed to be moving at 15 knots, while the other half were stationary. In addition,
a total of 50 ground vehicles are distributed at these airports as well.
The altitude distribution of the airborne aircraft is assumed to be exponential, with a
mean altitude of 5500 feet. This distribution is assumed to apply over the entire area.
The airborne aircraft are assumed to have the following average velocities,
determined by their altitude. The aircraft velocities for aircraft below 25000 feet are
uniformly distributed over a band of average velocity +/- 30 percent.
0-3,000 feet altitude 130 knots
3,000-10,000 ft 200 knots
10,000-25,000 ft 300 knots
25,000-up 450 knots
The aircraft are all assumed to be moving in random directions.
In the LA scenario, ADS-B equipage Class A0 aircraft are assumed to fly below
18,000 feet. All other aircraft are assumed to be capable of flying at any altitude.
The aircraft in the LA scenario are assumed to be in the following proportions:
A3 30%
A2 10%
A1 40%
A0 20%
2009, RTCA, Inc.

Appendix P
Page P - 10
The scenario for the LA high density case contains a total of 2694 aircraft: 1180 within
the core area of 225 NM, 1289 between 225-400 NM, and 225 on the ground. This
represents a scaling of the estimated maximum 1999 LA Basin levels upward by 50
percent. Of these aircraft, 471 lie within 60 NM of the center. (This includes aircraft on
the ground.) Around ten percent of the total number of aircraft are above 10,000 ft in
altitude, and more than half of the aircraft are located in the outer (non-core) area of the
scenario.
An attempt was made to at least partially account for the expected lower aircraft density
over the ocean. In the third quadrant (between 180 degrees and 270 degrees), for
distances greater than 100 NM from the center of the scenario, the density of aircraft is
reduced to 25 % of the nominal value used. The other 75% of aircraft that would have
been placed in this area are distributed uniformly among the other three quadrants at the
same range from the center. This results in relative densities of 1:5 between the third
quadrant and the others.
P.2.3.2 LA Results and Analysis

The ADS-B MASPS requirements for ADS-B air-to-air surveillance range and report
update interval are used to assess how each ADS-B link performs in relation to the free
flight operational enhancements identified by the RTCA Safe Flight 21 Steering
Committee. These requirements specify the minimum range for acquisition of the State
Vector, Mode Status and Target State Reports where applicable, as well as the maximum
update periods allowed for this information (See ADS-B MASPS, RTCA DO-242A).
These air/air criteria specify ranges, use of short-term intent information (TS Reports),
and update times. The projected Trajectory Change (TC) long-term intent reporting
capabilities of 1090 ES are described in Appendix O of these MOPS.
Results are presented as a series of plots of 95% update times as a function of range for
State Vector updates and intent updates, where applicable. The 95% time means that at
the range specified, 95% of aircraft pairs will achieve a 95% update rate at least equal to
that shown. The 95-95 metric was calculated by placing the aircraft in range bins of ten
(10) NM width and plotted in the form of histograms. The ADS-B MASPS requirements
are also included on the plots for reference. Since the transmit power and receiver
configuration are defined for each aircraft equipage class, performance is shown
separately for each combination of transmit-receive pair types for A2 and A3 class
equipment. Results are shown in Figure P-2 through Figure P-13 and conclusions are
presented below. Note that, due to unavailability of receiver performance results for A2
in the 30,000/second Mode A/C environment, results for A2 are presented only for the
24,000/second case. The ADS-B MASPS requirements for State Vector, and projected
requirements for TS Report updates are also shown on the plots. Performance in
compliance with MASPS requirements is indicated by results that are below the MASPS
line.
2009, RTCA, Inc.

Appendix P
Page P - 11
Figure P-2: 95-95 State Vector Update Rate for A3-to-A3 Air-to-Air Reception in LA-[24k]
Figure P-3: 95-95 TSR Update Rate for A3-to-A3 Air-to-Air Reception in LA-[24k]
2009, RTCA, Inc.

Appendix P
Page P - 12
Figure P-5: 95-95 TSR Rate for A2-to-A3 Air-to-Air Reception in LA-[24k]
2009, RTCA, Inc.

Appendix P
Page P - 13
2009, RTCA, Inc.

Appendix P
Page P - 14
2009, RTCA, Inc.

Appendix P
Page P - 15
Figure P-11: 95-95 TSR Rate for A3-to-A2 Air-to-Air Reception in LA-[24k]
2009, RTCA, Inc.

Appendix P
Page P - 16
2009, RTCA, Inc.

Appendix P
Page P - 17
The results for LA shown in Figure P-2 through Figure P-13 are summarized in Table P-
1. The values in the table are determined from the histograms by looking at the bars in
the ten-mile bins and using the upper range for the last bin that is under the requirement
line. For example, in Figure P-13 above, the ten-mile bar from 10-20 NM is the last bin
under the requirement line, so the range for the 95-95 metric for A2-to-A2 TSR updates
is 20 NM.
Table P-1: APL Air-to-Air 1090 ES Performance Relative to ADS-B MASPS
Range to Which MASPS

Performance is Met
Transmitter Receiver Mode A/C
State Vector Target State
A3 A3 24,000 70 NM 50 NM
A2 A3 24,000 50 NM 20 NM
A3 A3 30,000 60 NM 40 NM
A2 A3 30,000 40 NM 20 NM
A3 A2 24,000 40 NM 20 NM
A2 A2 24,000 30 NM 20 NM
Note: For the LA scenario, two cases were considered, in order to represent two
potential worst-case interference environments, a nominal case with Mode A/C
fruit rate of 24,000 per second, herein referenced as LA-[24k], and a more
severe case of 30,000 Mode A/C fruit per second, herein referenced as LA-
[30k].
P.2.4 Low Density Scenario
P.2.4.1 Low Density Scenario Description

In addition to the high-density LA scenario described above, a scenario was also run to
represent low-density traffic levels. This scenario, for simplicity, was developed by
scaling the current LA Basin distributions downward by a factor of five, amounting to
360 total aircraft. These aircraft are uniformly distributed in the horizontal plane within a
circle of 400 nautical miles. In the vertical direction, they are distributed uniformly
between 25,000 feet and 37,000 feet. The velocities are all set to 450 knots and are
randomly distributed in azimuth. All of the aircraft are assumed to be A3 equipped.
2009, RTCA, Inc.

Appendix P
Page P - 18
P.2.4.2 Low Density Results and Analysis

Results of the simulation runs for the low-density scenario are shown in Figure P-14 and
Figure P-15, and conclusions are presented below. The ADS-B MASPS requirements for
State Vector and TSR updates are shown as black lines on the plots. The ADS-B
MASPS specify that the maximum ranges for air-air update rates required for A3 to 90
NM (120 NM desired), while the Eurocontrol criteria extend to 150 NM for A3.
Performance in compliance with MASPS requirements is indicated by results that are
below the black line.
Figure P-14: 95-95 State Vector Update Rate for A3-to-A3 Air-to-Air Reception in 5,000 Mode A/C
per Second in the Low Density Scenario
2009, RTCA, Inc.

Appendix P
Page P - 19
Figure P-15: 95-95 TSR Update Rate for A3-to-A3 Air-to-Air Reception in 5,000 Mode A/C per
Second in the Low Density Scenario
The results for the low-density scenario may be summarized as follows:

ADS-B MASPS air-air requirements and desired criteria are met for State Vector and
TS Report updates at all ranges specified by the ADS-B MASPS for the low density
scenario.
P.2.5 Results and Conclusions

This section summarizes the results of the APL simulation studies and states conclusions
that may be drawn about expected 1090 ES performance in the scenarios considered.
This summary will be presented in Section P.2.5.2. Section P.2.5.1 will first point out a
number of considerations that should be taken into account when interpreting the results.
P.2.5.1 Considerations
The following considerations should be noted when interpreting the results of this
analysis:
The transmit power distribution for A3 transmitters, which was used for this analysis,
was uniform from 53-56 dBm. These MOPS allow for A3 transmitters to extend as
low as 51 dBm. This corresponds more closely to the transmit power distribution
assumed for A2 class aircraft in this analysis; therefore, for a class A3 aircraft with a
transmit power near the lower limit of the allowed range, it would be expected that
performance would be given by A2 transmit results, rather than A3.
2009, RTCA, Inc.

Appendix P
Page P - 20
The receiver performance model that was used for this analysis was based on non-
real-time simulation results provided by the FAATC and MIT Lincoln Laboratory.
Several manufacturer representatives have indicated that they felt that performance
equivalent to that required by these MOPS was achievable. Still, there has been no
testing of performance on MOPS-compliant equipment, and until this is done the
receiver performance model has not been validated and remains hypothetical. In
addition, the receiver performance model thus derived was designed to match the
average performance predicted by the simulation results discussed above. This was
necessary due to time and resources constraints and may add some additional
uncertainty to the results.
The results of this study should not be directly compared with any analysis not
described in this Appendix, without taking into account differences in assumptions
and analysis techniques. For example, the 1090 ES analysis in the TLAT report
[Reference P-1] assumed different transmit power distributions, receiver decode
performance, and Mode A/C interference levels, so it is not surprising that the results
of that study differ from those reported here.
Finally, in evaluating expected performance through the use of simulations, it is
important to be aware of the inherent uncertainties in results due to the indeterminate
nature of the assumptions, as well as the uncertainties in the modeling process itself.
This is true for performance predictions resulting from any type of simulation
technique. For example, in this analysis it was assumed that the number of aircraft in
the LA Basin would increase by 50%, that most aircraft would be Mode S equipped,
that a number of TCAS improvements would be universally deployed, and that the
A3 transmit power would be as described above. These assumptions all include
associated uncertainty; modifying any of the assumptions could result in a change in
predicted performance.
P.2.5.2 Summary
Keeping in mind the conditions described in the previous section, the performance of
1090 Extended Squitter in the two scenarios examined may be summarized as follows:
In the LA high density air traffic scenario, this analysis concludes that A3 aircraft
should be capable of participating with other A3 aircraft in the applications defined
in RTCA DO-242A which require State Vector and TS Report for ranges up to and
including 40 NM. For applications that require State Vector only, the range is
extended to 60-70 NM, depending on the interference environment.
In the low density air traffic scenario, this analysis concludes that A3 aircraft should
be capable of participating with other A3 aircraft in the applications defined in RTCA
DO-242A which require State Vector and TS Report for all required and desired
ranges.
In the LA-[24k] (24,000 Mode A/C) high density air traffic scenario, this analysis
concludes that A3 aircraft should be capable of participating with A2 aircraft in the
applications defined in RTCA DO-242A which require State Vector only for ranges
up to and including 40 NM. The exchange of TS Report information is limited to 20
NM between A2 and A3 equipage aircraft.
In the LA-[24k] (24,000 Mode A/C) high density air traffic scenario, this analysis
concludes that A2 aircraft should be capable of participating with A2 aircraft in the
applications defined in RTCA DO-242A which require State Vector only for ranges
2009, RTCA, Inc.

Appendix P
Page P - 21
up to and including 30 NM. The exchange of TS Report information is limited to 20

NM between A2 equipage aircraft.
Neither A1 nor A0 equipage was evaluated for this analysis.
This analysis has not evaluated the effect of transmitting more detailed intent
information, such as TCRs. Future revisions of these MOPS should consider modifying
the transmit power requirement for A3 equipage, so that the minimum power corresponds
to that assumed in this analysis. In addition, improved A2 performance could be
achieved by modifying either or both of the MTL requirement and the enhanced decoding
techniques used.
P.3 Performance Evaluation by MIT Lincoln Laboratory

MIT Lincoln Laboratory employed two simulation tools to determine ADS-B reception
performance as a function of range for the LA (as defined in P.2.3.1) and low density
scenarios. The first tool is a pulse-level simulation, whose output gives the probability of
correct reception of an Extended Squitter signal as a function of received signal power
level. The second tool is a track-level simulation, whose input is the per-squitter
reception probability from the pulse-level simulation, and whose output gives the
performance over a time period, such as 12 seconds. When applied to long-range air-to-
air surveillance, this simulation can be used to determine the maximum range at which 95
percent or more of the targets are being received sufficiently reliably to be in track and
being updated regularly as required by the ADS-B MASPS (RTCA DO-242A).
P.3.1 Pulse Level Simulation

The pulse-level simulation generates a sample-by-sample received Extended Squitter
signal in the presence of interference, consisting of Mode A/C fruit and Mode S replies
and squitters, in both long and short formats. When used in this study, the interfering
reception rates and power distributions were selected to match the interference
environment in Los Angeles in two cases and the low density environment in the other.
The interference rates and power distributions are described below.
P.3.1.1 Formulation of the Pulse-Level Simulation

This simulation was originally created for developing enhanced reception techniques for
Extended Squitter. The simulation represents signals and interference as 1090 MHz radio
frequency waveforms having amplitude and phase, so that destructive and constructive
summation is represented. Each transponder is assigned a specific carrier frequency,
which need not be exactly 1090 MHz. The frequency offsets were random, uniformly
distributed over +/-1 MHz in this study. Minor pulse width deviations were also
incorporated in this study. All pulses have rise times and fall times that correspond to the
effects of both transmitter and receiver. The simulation can be run using different values
of receiver bandwidth. Bandwidth was set equal to 8 MHz in this study. In addition to
the received interference, the simulation also includes receiver noise, whose power was -
100.7 dBm referred to the antenna in this study.
2009, RTCA, Inc.

Appendix P
Page P - 22
The received waveform, which is a sum of the Extended Squitter signal and all
overlapping interference plus noise, is then converted to a log video waveform, which is
sampled at a steady rate. These steps are illustrated in Figure P-16. The simulation can
be run at a sampling rate of 8 samples per microsecond or 10 samples per microsecond.
The rate of 8 per microseconds was used in this evaluation. The log video samples are
then processed using the enhanced reception techniques. These techniques include an
improved form of preamble detection, the 4-4 table method of declaring the 112 bits and
associated confidence bits, and the error detection/correction technique called "Brute
Force, n=5".
Signals
(Ext. Squitters)
Mode A,C
Interference
Sum of RF OUTPUT
receptions Log-Video Sampler
Short Mode S Amplifier
8 samples per Log Video
Long Mode S real-imag. microsec. Samples
formulation
Receiver Noise
Signal-to-interference power ratios, controlled by aircraft ranges and fading.

Bandwidth affect on pulse shapes.
Frequency deviations for Mode A,C (2 MHz typ.) and Mode S (1 MHz typ.)
Phases of each pulse
Pulsewidth deviations
Receiver noise (power = -100.7 dBm referred to the antenna, typ.)
Figure P-16: Overview of the Pulse-Level Simulation
To generate reception probability as a function of received power level, the process is as

follows. The user assigns a total number of aircraft (1000 aircraft for example) and
provides a range distribution. The simulation generates the ranges of these aircraft using
a pseudo-random process, following the given range distribution. Then for each aircraft,
the nominal value of received power level is calculated using the following formula:
Nom. Received power (dBm at antenna) = -83.5 - 20 log10(range/100 NM)
The next step is to apply a random power deviation to account for both transmitter power
differences from aircraft to aircraft and antenna gain effects. The user also assigns a
transmission rate for each of the three types of signals. The simulation is run for a fixed
time period set by the user, typically 10 seconds. For each transmitting aircraft, the
transmissions are made random in time, uniformly distributed over the run time. The
reception times are modeled as a Poisson process, having a constant average reception
rate for each of the three types of signals.
These particular assignments of nominal power and power deviations are used only in the
pulse-level simulation, and only for the purpose of generating a fruit distribution
appropriate for the environment being studied.
2009, RTCA, Inc.

Appendix P
Page P - 23
As each Extended Squitter is received, it is processed to determine whether the 112 bit
message is correctly received, including the effects of error detection/correction. All
such receptions, whether correct or not, are saved in bins according to the received power
level. Five-dB bins were used in this study. After the full run, which includes several
thousand reception opportunities in each of the major bins of interest, the number of
correct receptions in compared with the total number of opportunities. The probability of
correct reception is computed as the ratio:
Probability of correct reception = (no. of correct receptions)/(no. of opportunities)
P.3.1.2 Interference Rates and Power Distribution

In running the pulse-level simulation for the Los Angeles environments, it was necessary
to specify the rates and power distributions of the interfering signals. For Los Angeles,
this was done based on results from airborne measurements in the LA Basin in 1999 and
on results from the Volpe simulation [Reference P-3]. It was found that the power
distribution of Mode A/C fruit from the LA Volpe simulation agrees with the airborne
measurements above 75 dBm, except being higher in fruit rate, which would be
expected because of the future higher aircraft densities. The Volpe results were then used
to provide the fruit-rate input to the Lincoln Laboratory pulse-level simulation. Figure P-
17 shows the Mode A/C and Mode S fruit rates and power distributions used as inputs for
this study. This applies to a scenario called LA-[24k], in which the receiving aircraft is
located near LAX airport at 40,000 feet altitude. Mode S interference is characterized by
short Mode S transmissions from each aircraft at a rate of 6 per second, and long Mode S
transmission at a rate of 5.4 per second. The total Mode A/C fruit rate when referred to a
power level of -84 dBm at antenna is 24,000 fruit per second, for bottom antenna
receptions. For top antenna receptions the corresponding fruit rate is 18,000 fruit per
second.
2009, RTCA, Inc.

Appendix P
Page P - 24
Figure P-17: Top and Bottom Antenna Fruit, LA-[24k]
P.3.1.3 Pulse-Level Simulation Results for A3 to A3

The pulse-level simulation was run for the LA scenario with two different cases of fruit
levels representing different interference environments for future higher aircraft densities.
The first case called LA-[24k] has 24,000 Mode A/C fruit per second, as described
above. The second, more severe case, called LA-[30K], has 30,000 Mode A/C fruit per
second, with the same Mode S interference as in LA-[24k]. The pulse-level simulation
results are shown in Figure P-18 for Air-to-Air performance of A3 to A3.
2009, RTCA, Inc.

Appendix P
Page P - 25
Figure P-18: Reception Probability versus Received Power for A3-to-A3
P.3.1.4 Pulse-Level Simulation Results for A2

The pulse-level simulation is used to determine reception probability as a function of
received signal power level. The simulation results, plotted in Figure P-19, show a
comparison between MTL = -79 dBm (Class A2) and MTL = -84 dBm (Class A3), for
the LA-[24k] environment.
2009, RTCA, Inc.

Appendix P
Page P - 26
Figure P-19: Pulse-Level Simulation Results (bottom antenna receptions)
The results indicate that the only significant effect is near MTL. Class A2 reception
probability is reduced in the vicinity of the MTL power level, and otherwise nearly the
same as for Class A3. A curve fit was applied to the data in Figure P-19, for use in the
Track-Level Simulations and is shown in Figure P-20.
2009, RTCA, Inc.

Appendix P
Page P - 27
Figure P-20: Curve Fit to Simulation Results
P.3.2 Track-Level Simulation

After the pulse-level simulation has generated results in the form of reception probability
as a function of received signal power, the track-level simulation can be used to
determine system performance.
P.3.2.1 Formulation of the Track-Level Simulation

The track-level simulation is formulated using a Monte Carlo technique in which one run
represents one pair of aircraft at a given air-to-air range. In each run, pseudo random
variables are used to generate the antenna gain values and the transmitter power for that
particular transmitting aircraft.
The TLAT model is used for the statistical variation of aircraft antenna gains. The
scenario considered in these runs applies to altitudes that are nearly the same, and for
which the antenna vertical patterns are not used. Altitude differences were studied
separately, as described below.
After being generated at random, the antenna gain values are held constant for that
particular pair of aircraft. The cases being addressed in this study apply to antenna
diversity on both the transmitting and the receiving aircraft. Therefore each aircraft pair
has four antenna gain values. These four values are generated independently in the
simulation. Transmitter power is generated at random using a given distribution. For a
Class A3 aircraft, is modeled as uniformly distributed over 53 to 56 dBm referred to the
antenna.
2009, RTCA, Inc.

Appendix P
Page P - 28
The simulation is run for a particular air-to-air range. Using the transmitter power and
the four antenna gains, the four values of received power are calculated (top-to-top, top-
to-bottom, bottom-to-top, and bottom-to-bottom). For each case the probability curve
(from the pulse-level simulation) is then used to determine the reception probability for
that particular antenna combination.
Receiver blanking caused by co-site interference is included at this point. The values of
reception probability calculated as above are now multiplied by 0.93 to account for these
effects.
To account for receiving antenna diversity, the probability of correct reception is

calculated using the following formula:
Prob(correct) = Maximum[P(top) , P(bot)]
where P(top) and P(bot) are the reception probabilities for top only and bottom only. In
other words, only the better of the two receiving antennas is used; the other does not
contribute to performance.
Subsequently, to account for transmitting antenna diversity, the reception probability is

calculated separately for top-transmit and bottom-transmit, and then these two values are
averaged. This averaging is based on the fact that each antenna transmits 50 percent of
the squitters.
This process yields the value of reception probability for a particular pair of aircraft. The
process is repeated for a large number of aircraft pairs (1000 pairs). Performance for the
95th percentile pair is determined by sorting the 1000 values and identifying the value
that is exceeded by 95% of the population. This result gives the 95-percentile reception
probability for the range being considered. Repeating the process for different ranges
provides system performance as a function of range.
P.3.2.2 Track-Level Simulation Results for A3-to-A3

For the LA-[24k] scenario, both the pulse-level simulation and the track-level simulation
were run, yielding the results given in Table P-2, and shown in Figure P-21 and Figure P-
22.
Table P-2: LL A3-to-A3 Performance as a Function of Range for LA-[24k]

RANGE Prob (95) T95/95
NM Reception Probability second
10 0.681 0.7
20 0.429 1.3
30 0.272 2.4
40 0.185 3.7
50 0.130 5.4
60 0.106 6.7
70 0.077 9.3
80 0.058 12.5
90 0.055 13.2
100 0.045 16.3
2009, RTCA, Inc.
Appendix P
Page P - 29
Figure P-21: Future A3-to-A3 System Performance in the Los Angeles Basin
2009, RTCA, Inc.

Appendix P
Page P - 30
Figure P-22: State Vector Update Performance for A3-to-A3
The results in Figure P-22, showing State Vector update time, were generated from the
probability values as follows. In a time T, the number of reception opportunities is:
N = T / 0.25 seconds.
Given the reception probability from the pulse-level simulation, the probability of correct
reception during the time T is therefore:
P(recep. in T) = 1 - (1 - p1)N
where p1 is the single-squitter reception probability. Requiring 95% reception in time T,

or P(recep. in T) = 0.95, the solution for time T is:
T95 = 0.25 * ln(0.05) / ln(1 - p1)
This calculation is made for each pair of aircraft among 1000 pairs. The results are
sorted, in order to determine the T95 value for which performance is as good or better for
95% of the aircraft pairs. The result is denoted T95/95 to indicate that it applies to 95%
surveillance update reliability for 95% of aircraft pairs.
2009, RTCA, Inc.

Appendix P
Page P - 31

Using the curve fit shown in Figure P-20, the Track-Level simulation was run for 1000
aircraft pairs (one aircraft transmitting and one receiving). The formulation of the
simulation is documented in P.3.2.1. The simulation includes co-site interference in the
form of 93% receiver availability.
For the case of A2 to A2 aircraft pairs, the results are shown in Table P-3.
Table P-3: LL Simulation Results for A2-to-A2 in LA [24k]

Range Reception Prob State Vector TS Report
NM 95 percentile T95/95 (sec.) T95/95 (sec.)
10 0.597 0.8 4.1
15 0.418 1.4 6.9
20 0.333 1.8 9.2
25 0.255 2.5 12.7
30 0.209 3.2 16.0
35 0.145 4.8 23.9
40 0.105 6.8 33.8
45 0.068 10.6 53.2
50 0.048 15.2 76.1
55 0.032 23.0 115.1
60 0.014 53.1 265.6

The other case to consider is Class A3 transmissions received by Class A2 aircraft. The
only difference between this case and the first case is the higher power level of the A3
transmitters. In the model being used, A3 transmitters are between 53 and 56 dBm
whereas Class A2 transmitters are between 51 and 54 dBm. This difference affects the
results as a 2 dB change in ranges for each level of performance. Therefore the results in
Table P-3 can be converted to the results in Table P-4 for the A3 to A2 case.
Table P-4: LL Simulation Results for A3-to-A2 in LA [24k]

Range Reception Prob State Vector TS Report
NM 95 percentile T95/95 (sec.) T95/95 (sec.)
12.3 0.597 0.8 4.1
18.9 0.418 1.4 6.9
25.2 0.333 1.8 9.2
31.5 0.255 2.5 12.7
38 0.209 3.2 16.0
44 0.145 4.8 23.9
50 0.105 6.8 33.8
57 0.068 10.6 53.2
2009, RTCA, Inc.

Appendix P
Page P - 32
These results are plotted in Figure P-23 and Figure P-24, where they are compared with
the ADS-B MASPS (RTCA DO-242A) standards. Air-to-air surveillance is seen to
satisfy the MASPS standards in both cases, A2-to-A2 and A3-to-A2. Air-to-air
communication of TS Report information (Figure P-24) satisfies the MASPS standards
for A3-to-A2, whereas in the case of A2-to-A2, performance falls short of the MASPS
beyond about 24 NM.
Figure P-23: State Vector Update Rate for A3-to-A2 in LA [24k]
Figure P-24: TSR Update Rate for A3-to-A2 in LA [24k]
2009, RTCA, Inc.

Appendix P
Page P - 33
P.3.3 Effects of Altitude

In the normal formulation, the two aircraft are considered to be at approximately the same
altitude, and therefore the elevation-angle portion of the antenna gain model was not used
(only the statistical portion was used). For an additional study of altitude effects, the
formulation was changed so that the transmitting aircraft has a specific altitude (a
parameter entered by the user) while the receiving aircraft is at the fixed altitude of
40,000 feet. Therefore the results depend on the transmitter altitude. The TLAT model
of aircraft antenna gain as a function of elevation angle was used in this study [Reference
P-1].
The results for several values of transmitter altitude are shown in Figure P-25 and Figure
P-26. The results indicate that performance is somewhat degraded when the transmitter
is changed from 40,000 feet to 5000 feet. The degradation is more pronounced at shorter
range, which seems reasonable because of the steeper elevation angles. Beyond 50 NM,
performance is not changed significantly.
Figure P-25: Effects of Transmitting Aircraft Altitude (A3-A2, LA-[24k]) on State Vector
2009, RTCA, Inc.

Appendix P
Page P - 34
Figure P-26: Effects of Transmitting Aircraft Altitude (A3-A2, LA-[24k]) on TSR Update
Rate
Note: Altitudes marked in the figure apply to the transmitting aircraft. The receiving
aircraft is at 40,000 feet.
Looking at intermediate results from the simulation, one can see several reasons why
altitude would not be expected to have much effect at long range. For long range, the
elevation angle change is small. For example, for range of 100 NM and transmitter
altitude of 5000 feet, the elevation angles are +/-3.3 degrees. According to the TLAT
antenna gain model, this causes a drop by only 1.1 dB for one antenna and a boost by 1.0
dB for the other. The effects are small and nearly identical.
Figure P-26 indicates that the slope of the performance curves is similar to the slope of
the TSR requirement. As a result, the relatively small degradation in TSR performance in
this figure causes the MASPS intersection point to drop more dramatically. Although the
MASPS requirement is not strictly met beyond that point, the performance is only a few
seconds different from the requirement.
In conclusion, the results from the normal runs, in which altitude differences were not
used, have been shown to be accurate at long ranges, regardless of the actual altitude of
the transmitting aircraft. The results indicate that performance is not very sensitive to
transmitter altitude between 20,000 feet and 40,000 feet, although sensitivity increases
for very low transmitters.
2009, RTCA, Inc.

Appendix P
Page P - 35
P.3.4 Higher Fruit LA Environment

In performing the evaluation for the higher-fruit case, 30,000 Mode A/C fruit per second,
the same process was followed. The results are included in Figure P-21 and Figure P-22.
P.3.5 Low Density Environment

The Low Density Environment defined in the ADS-B MASPS (RTCA DO-242A) was
also evaluated. The aircraft are uniformly distributed in area over a circle of 400 NM
radius. The total number of aircraft is 360, so the density is 0.0007 aircraft per square
NM.
P.3.5.1 Reception Probability versus Signal Power

In evaluating performance in this environment, the first step was to determine reception
probability as a function of range. The conclusion is that the MTL curve by itself is an
appropriate characterization of reception performance as a function of received power in
the low density environment. The MTL curve used in this evaluation was based on
bench tests performed at the FAATC. The curve satisfies both MTL requirements (90%
at -84 dBm and 15% at -87 dBm) and is otherwise the worst-case curve.
P.3.5.2 Low Density Environment Track-Level Simulation

The track-level simulation was then run, using the same procedure as was used for LA-
[24k] except for the probability input curve, which embodies the characteristics of the
low density environment. The runs apply to Class A3 transmissions received by Class
A3 aircraft. Both aircraft have antenna diversity. A receiver dead time factor of 0.93
was also used.
The simulation results are given in Table P-5 and shown in Figure P-27 and Figure P-28.
These results exhibit more statistical fluctuations than in the previous cases, which can be
attributed to the abruptness of the MTL curve. As a result, the simulation was run twice
at each range. Both points were tabulated and plotted, to indicate the degree of accuracy
in these results as influenced by the number of trials (1000 aircraft pairs contributing to
each point).
2009, RTCA, Inc.

Appendix P
Page P - 36
Table P-5: LL Performance in the Low Density Environment

Range Reception Probability T95/95
NM P(95) seconds
0.696 0.629
70
0.676 0.665
0.481 1.142
80
0.552 0.933
0.465 1.197
90
0.465 1.197
0.465 1.197
100
0.465 1.197
0.464 1.201
110
0.402 1.457
0.215 3.094
120
0.278 2.299
0.142 4.890
130
0.094 7.587
0.018 41.232
140
0.018 41.232
Figure P-27: Reception Probability in the Low Density Environment
2009, RTCA, Inc.

Appendix P
Page P - 37
Figure P-28: State Vector Updates in the Low Density Environment for A3-to-A3 with 1250 Mode
A/C Fruit
The results exhibit an interesting flat spot from 80 to 110 NM. Looking at this, one can
see that it is a result of the steep MTL curve. It's not common, but occurs at around the
95 percentile worst cases, that one of the two transmitting antennas has higher power, for
which reception is the maximum value (0.93), while the other transmitting antenna has
lower power, for which reception is zero. Therefore the overall probability is (0.93 +
0)/2 = 0.465. This is the probability value at the flat spot.
The results in Figure P-28 indicate that the MASPS standards for State Vector are met
out to about 130 NM air-to-air range for Class A3-to-A3. The same evaluation was
performed for TS Reports, and the results indicate that the MASPS standards are met out
to about 130 NM for Class A3-to-A3 avionics.
2009, RTCA, Inc.

Appendix P
Page P - 38
P.4 Summary of DO-260A Performance Analysis

Table P-6 and Table P-7 summarize the results from the simulations run by Johns
Hopkins University Applied Physics Laboratory (APL), and by MIT Lincoln Laboratory
(LL). These tables show to what range the report update requirements from the ADS-B
MASPS, RTCA DO-242A where met for a given equipment class combination and Mode
A/C fruit level. Also shown is the range to which the update requirements are required
and desired as described in RTCA DO-242A.
Note: For the high density scenarios of 24,000 and 30,000 Mode A/C fruit (see P.1),
RTCA DO-242A specifies that operational ranges are only to extend to 40 NM.
However, it should be noted that as applications are developed and validated,
these required ranges might be extended to 90 NM in high density airspace for
A3 equipment.
Table P-6: Simulation Summaries for State Vector Report Update Ranges
Mode RTCA DO-242A

Transmitter Receiver APL LL
A/C Required Desired
A3 A3 24,000 70 NM 78 NM 40 NM 120 NM
A2 A3 24,000 50 NM 62 NM 40 NM 50 NM
A3 A3 30,000 60 NM 70 NM 40 NM 120 NM
A3 A2 30,000 [1] 53 NM 40 NM 120 NM
A2 A3 30,000 40 NM 55 NM 40 NM 50 NM
A2 A2 30,000 [1] 42 NM 40 NM 50 NM
A3 A2 24,000 40 NM 59 NM 40 NM 120 NM
A2 A2 24,000 30 NM 47 NM 40 NM 50 NM
A3 A3 5,000 >120 NM 115 NM 90 NM 120 NM
A3 A3 1,250 >120 NM ~130 NM 90 NM 120 NM
Table P-7: Simulation Summaries for Target State Report Update Ranges
Mode RTCA DO-242A

Transmitter Receiver APL LL
A/C Required Desired
A3 A3 24,000 50 NM 40 NM 40 NM 50 NM
A2 A3 24,000 20 NM 32 NM 40 NM 50 NM
A3 A3 30,000 40 NM 28 NM 40 NM 50 NM
A3 A2 30,000 [1] [1] 40 NM 50 NM
A2 A3 30,000 20 NM 28 NM 40 NM 50 NM
A2 A2 30,000 [1] 21 NM 40 NM 50 NM
A3 A2 24,000 20 NM 40 NM 40 NM 50 NM
A2 A2 24,000 20 NM 24 NM 40 NM 50 NM
A3 A3 5,000 >120 NM 115 NM 40 NM 50 NM
A3 A3 1,250 >120 NM ~130 NM 40 NM 50 NM
[1] - Not evaluated
2009, RTCA, Inc.

Appendix P
Page P - 39
The above summary tables show that the 1090 MHz ES ADS-B system, as defined in
these MOPS, will meet the report update requirements from RTCA DO-242A beyond the
required ranges for A3 equipment interacting with A3 equipment at recommended power
levels. It should be noted, however, that if the operational range of 40 NM for high
density airspace would be increased to that of 90 NM used for low-density airspace, the
performance of the 1090 MHz ES system would not meet the update requirements
through that extended range.
For State Vector update performance, the requirements for RTCA DO-242A are also met
for A3 equipment interacting with A2 equipment at recommended power levels.
Performance requirements up to 40 NM for State Vector updates will be met in the high
density environments between A3 and A2 equipment, however, results are unclear if A2-
to-A2 communications will meet the 40 NM requirement in LA. The results show that
update requirements will not be met in high density airspace for the TS Reports for A2
equipment interfacing with either A2 or A3 systems.
The transmission rate for A2 equipment has been selected in light of the current 6.2
transmissions per second limit and is tailored to A3 equipment, and retains capability to
support the Trajectory Change Reports (see Appendix O). Future editions of these
MOPS may consider increasing the transmission rate of short term intent information
supporting TS Reports for A2 equipment in order to provide longer range performance in
the highest density environments.
As described in P.3.3, relatively small variations in predicted TSR performance may

result in significant differences in the ranges at which the MASPS TSR updates rates are
satisfied.
Table P-6 shows performance for the MASPS low density scenario with two different
Mode A/C fruit rates. These results indicate for Mode A/C fruit rates approaching 5000
per second that the 1090 MHz system for A3-to-A3 interactions offers the MASPS
desired range of 120 NM.
The performance results reported in Appendix P were derived from two independent
evaluations, one by APL and the other by LL. Examination of Tables P-6 and P-7 shows
(only) three differences in simulated performance results provided by APL and LL that
impact the determination of whether particular RTCA DO-242A requirements are
projected to be met by the 1090 MHz Extended Squitter system in the LA air traffic
scenario (Table P-6, A2 transmitter and A2 receiver at 24,000 Mode A/C fruit; Table P-7,
A3 transmitter and A3 receiver at 30,000 Mode A/C fruit; and Table P-7, A3 transmitter
and A2 receiver at 24,000 Mode A/C fruit). A significant effort was made to understand
the reason for any differences between the results reported by each evaluation. The APL
and LL evaluation techniques, while using similar assumptions on, for example,
probability of correct reception of a single Extended Squitter as a function of received
signal power, use different simulator architectures and, for A3 receivers, a different
sampling rate. These differences, in conjunction with uncertainties inherent in the
simulation processes, are the likely source of the differences in the values for update
ranges obtained.
2009, RTCA, Inc.

Appendix P
Page P - 40
P.5 Additional Performance Analysis for DO-260B

Additional analysis was carried out for the publication of DO-260B, in order to examine
the performance of 1090 ES in more dense traffic environments and evaluate the
performance of the newly-defined single-antenna A1 category of equipage. In order to
be consistent with the performance metrics used in the rest of this appendix, it was
decided to use the same update interval benchmarks that were used in the previous
Appendix P that was done for DO-260A. These benchmarks were based on initial
estimates of the application requirements provided by the ADS-B MASPS (DO-242A)
that were published in 2002. Since the publication of DO-260A, much work has been
done to refine the air-to-air applications and the accompanying requirements, so these
benchmarks may have changed. Nevertheless, for consistency this section will use the
DO-242A values. For further information on more recent update interval requirements,
see DO-289, DO-312, and DO-314. In addition, there is ongoing work to define new air-
to-air applications.
P.5.1 East Coast Air Traffic Scenario
A new air traffic scenario was developed for this analysis. Since ADS-B will be sharing
the 1090 MHz frequency with existing SSRs, TCAS, and other systems, understanding
the current interference environment is necessary to provide confidence in the predictions
of future interference environments in which the system will need to operate. The
Northeast corridor of the United States was the selected environment to base future air
traffic and interference predictions since high air traffic density, TCAS equipage, and
SSRs contribute to a high 1090 MHz environment. There were several data recordings
and measurements that were utilized to compile air traffic counts and flight tests to
measure 1090 MHz interference rates. Initial analysis of air traffic counts were derived
from the Enhanced Traffic Management System (ETMS) data from the Northeast in
2004. Based on Instrument Flight Rules (IFR) traffic measurements and the estimated of
IFR to Visual Flight Rules (VFR) operations, the total traffic estimate was compiled.
A flight test was conducted on January 26th, 2006 in the Northeast corridor of the United
States for the purpose of measuring and assessing 1030/1090 MHz activity. The 1030
MHz measurements were collected to help identify the source of 1090 MHz interference
signals since interrogations on the 1030 MHz frequency produce ATCRBS and Mode S
replies on the 1090 MHz frequency. Interference measurements on 1090 MHz included
both ATCRBS and Mode S rates along with associated power levels to characterize the
signal distributions received by instrumentation on the flight test aircraft. ATCRBS reply
rates on 1090 MHz vary greatly over time and location.
An additional flight test was conducted on July 25, 2007 where 1030 and 1090 MHz
measurements similar to the January 2006 flight test were taken. The traffic counts
during this flight test were higher than the January 2006 flight test and one of the reasons
for this was that the flight test was conducted during the afternoon peak traffic interval.
The peak traffic time was missed in the January 2006 flight test which resulted in lower
aircraft densities.
The air traffic scenario used to predict the current and future interference environments
was derived from the data collected during the July 2007 flight test. The distribution of
the traffic was captured by taking snapshots of all aircraft seen by as many as 33 east
coast enroute and terminal radars. The composite picture was created by converting the
2009, RTCA, Inc.

Appendix P
Page P - 41
measured radar coordinates of all the aircraft at the time of the snapshot into latitude and
longitude, superimposing the pictures seen by all the radars, and eliminating duplicate
reports of the same aircraft as seen by multiple radars.
Work with the scenarios showed how critical things like aircraft distribution in range and
altitude were when creating the predicted fruit rates. As a result, a significant effort was
made to develop a new baseline model for 2007 that matched characteristics of the
measured data as much as possible.
The scenario for generation of 1090 interference for the future years was based on a new
model based on the results of the flight of 25Jul07. The measured results from the flight
were characterized in detail so that the parameters of the model could be adjusted to
match the contribution of each type of interference to the source of a particular type. The
distribution of aircraft as a function of range and altitude was defined from the measured
data. The percentage of each fruit type was also defined from the test data. The rates of
the various types of interference varied considerably as a function of aircraft position.
The various parameters of the model were then adjusted until the percentage of Mode S
contribution of the scenario matched the table values for the number of aircraft present
during the flight test of 25Jul07. The number of aircraft was normalized to 1000 within
300 miles of the victim for this purpose. The actual number varied depending on the
position of the aircraft at the time. This number of aircraft was then increased to produce
Environments 1 through 4. The aircraft density at 6 miles was held constant at the value
measured during the flight of 25Jul07. It was allowed to grow at further ranges
according to the predicted distribution as a function of range. The total number of
aircraft predicted for Environment 4 was 3000 within 300 miles.
P.5.2 Interference Environments

The 1090 ES ADS-B air-to-air performance was evaluated using four different
interference environments, labeled Environments 1-4, derived from the East Coast
Scenario. The four environments are categorized in Table P-8 below. The Mode S and
ATCRBS numbers represent the number of those interference types at or above a signal
level of -84 dBm.
Note: The current environment as measured was approximately 384 aircraft within a
radius of 100 NM, and somewhere between 1,100 and 1,200 aircraft within a
radius of 300 NM. The factors in the first column of Table XX indicate the
growth in the numbers of aircraft within 100 NM.
Table P-8: Four Interference Environments for Evaluating A1S Air-to-Air ADS-B Performance
Approx. No. AC in Approx. No. AC in Mode S ATCRBS

100 NM 300 NM (per sec) (per sec)
Env 1 (x1.4) 539 1,700 8,311 32,996
Env 2 (x1.7) 653 2,060 10,218 40,074
Env 3 (x2.1) 794 2,502 13,268 48,848
Env 4 (x2.5) 952 3,000 16,009 58,811
2009, RTCA, Inc.

Appendix P
Page P - 42
P.5.3 Air-to-Air Performance Results

This section presents the air-to-air performance results in the four interference
environments described in the previous section. All update intervals were calculated on
the assumption that an update could be done upon receipt of either a position or velocity
squitter. Some applications may put more stringent requirements on the nature of
updates.
P.5.3.1 A1S Results

The single-antenna A1 category of ADS-B equipage (A1S) was evaluated for air-to-air
performance using four different interference environments, labeled Environments 1-4, to
determine its capability of participating in potential airborne applications. The analysis
was done assuming that both transmitter and receiver were A1S equipped aircraft. The
air-to-air ranges examined were 15 NM, 20 NM, 30 NM, and 40 NM. The update
intervals used as benchmarks for these ranges, along with the A1S performance results
for the different environments, are shown in Table P-9.
Table P-9: A1S Air-to-Air ADS-B Performance in Four Interference Environments

T95(3NM) T95(10NM) T95(20NM) T95(30NM) T95(40NM)
Update Int
3s 5s 7s 12 s 12 s
(95%)
Env 1 1s 8s 25 s X X
Env 2 2s 10 s X X X
Env 3 2s 15 s X X X
Env 4 3s 20 s X X X
An X in a box indicates that the value was very large. From the table, the A1S was
unable to meet the update interval requirements past 3 NM for any of the high density
environments considered.
P.5.3.2 A3 Results
The A3 category of ADS-B equipage was evaluated for air-to-air performance using the
same four interference environments used to evaluate A1S, representing different
numbers of aircraft within 300 NM of the victim receiver, labeled Environments 1-4, to
determine its capability of participating in potential airborne applications in increasingly
high air traffic density. The analysis was done assuming that both transmitter and
receiver were A3 equipped aircraft. The update intervals used as benchmarks for these
ranges, along with the A3 performance results for the different environments, are shown
in Table P-10.
2009, RTCA, Inc.

Appendix P
Page P - 43
Table P-10: A3 Air-to-Air ADS-B Performance in Four Interference Environments

T95(3NM) T95(10NM) T95(20NM) T95(40NM) T95(60NM)
Update Int
3s 5s 7s 12 s 12 s
(95%)
Env 1 1s 1s 2s 8s 23 s
Env 2 1s 1s 3s 12 s 36 s
Env 3 1s 2s 4s 33 s X
Env 4 1s 2s 7s X X
An X in a box indicates that the value was very large. From the table, the A3 was able
to meet the update interval requirements to 40 NM for two of the high density
environments considered and to 20 NM for all of the environments.
REFERENCES:
P-1. Technical Link Assessment Report, Safe Flight 21 Steering Committee, ADS-B
Technical Link Assessment Team (TLAT), March 2001.
P-2. A. G. Cameron, et al, The 1030/1090 MHz Interference Simulation Technical

Description and Initial Results, TR-9454-02-01, TASC Inc., April 2001.
P-3. Measurement of 1090 MHz Extended Squitter Performance In the Los Angeles
Basin, DOT/FAA/ND-00/7, May 2000.
2009, RTCA, Inc.

Appendix P
Page P - 44
This Page Intentionally Left Blank.
2009, RTCA, Inc.

Appendix Q
Proposed Future Runway Threshold Speed On-Condition Message


Appendix Q
Page Q - 3
Q Proposed Future Runway Threshold Speed On-Condition Message
Applications are under development that rely on knowledge of aircraft planned final
approach speed. The requirements for these applications will be included in future
RTCA documents and may be reflected in future versions of these MOPS. Until this
work is concluded, this Appendix suggests a coding scheme for those desiring early
implementation of this capability.
Q.1 Background
There are at least two applications under development that are expected to use planned
runway threshold information to enhance airport capacity. The best documented is one
that uses planned aircraft approach speeds for enhancing the capacity of converging
runway configurations for airports such as Chicagos OHare. Potential capacity gains of
10-20 arrivals per hour in Instrument Meteorological Conditions (IMC) for such airports
have been estimated (See Mundra and Smith, 2001). Another possibility is approach
spacing. This analysis is currently underway, and may yield capacity benefits of the
order of 3 to 4 arrivals per hour for any single runway operation under certain wind
conditions.
To enable these procedures, the expected or planned speed of the aircraft across the
threshold (i.e., the landing speed) must be known at least 10 to 15 minutes prior to touch-
down. In practice, a logical time for computing and down-linking this speed is probably
at top of descent. If transmitted more than 20 minutes before touch down, provision
should also be made for at least one revised estimate.
This information would be input directly into terminal automation for aircraft spacing.
This would thus be safety critical information and adequate reliability must be ensured,
whether through redundancies or multiple transmissions.
20xx, RTCA, Inc.

Appendix Q
Page Q - 4
Q.2 Information Content

Information should be in the following format:
Table Q-1: Proposed Runway Threshold Speed Encoding
Coding Meaning
(Runway Threshold Speed in knots
(Binary) (Decimal) in 1 knot increments)
000 0000 0 Runway Threshold Speed Not Available
000 0001 1 Runway Threshold Speed < 70 knots
000 0010 2 Runway Threshold Speed = 70 knots

111 1111 127 Runway Threshold Speed > 194 knots
The encoding in Table Q-1 represents positive magnitude data only.
Values of approach speed are assumed to be rounded to the nearest knot.
Q.3 Reference
Anand D. Mundra and Arthur P. Smith (2001), Capacity Enhancements in IMC for
Converging Configurations with down-link of aircraft expected final approach speeds,
20th Digital Avionics Systems Conference, Dayton Beach, Florida, October 2001
20xx, RTCA, Inc.

Appendix R
Extended Squitter Broadcast Rate Analysis

This Page Intentionally Left Blank.

Appendix R
Page R - 3
R Extended Squitter Broadcast Rate Analysis
R.1 Purpose and Scope

The purpose of this Appendix is to provide a calculation of 1090 MHz Extended Squitter
broadcast rates for different operational scenarios to show that transmission rates
achieved over a 60 second period meet the required average rate over 60 seconds, and
that there is no need to implement a function to limit the total number of 1090 MHz
Extended Squitters transmitted over a certain period of time.
R.2 Background
This version of these ADS-B MOPS, specifies different types of 1090 MHz Extended
Squitters with different transmission rates (see Table 2-77)
There is no requirement to limit the transmissions over a 1 second period, other than a
maximum of 2 Event-Driven Messages. The transmission rate averaged over 60 seconds
must be less than or equal to 6.2 squitters per second.
R.3 Analysis of Extended Squitter Broadcast Rates for Specific Scenarios
R.3.1 Scenario 1: Airborne Steady State Conditions

Conditions:
Airborne
Target State and Status Message being broadcast
Table R-1: Airborne Steady State Conditions

Time
Average Peak Number
Between
Number Number over
2 Comment
per per 60
Transmissions
Second Second Seconds
(seconds)
Airborne Position Message 0.5 2 2 120
Airborne Velocity Message 0.5 2 2 120
Aircraft Identification 5 0.2 1 12
Target State and Status 1.25 0.8 1 48
2.5 0.4 24
Aircraft Operational Status 1
0.8 1.25 -
5 0.2 12
Aircraft Status 1
0.8 1.25 -
Total number over the period 8 336
Average /second 5.60
2009, RTCA, Inc.

Appendix R
Page R - 4
R.3.2 Scenario 2: Airborne with Mode A Code Change

Conditions:
Airborne
Change in Mode A Code occurs
Table R-2: Airborne with Mode A Code Change

Time
Average Peak Number
Between
Number Number over
2 Comment
per per 60
Transmissions
(seconds)
2.5 0.4 24
0.8 1.25 -
5 0.2 7 for remaining 36s
for 24s after Mode
Aircraft Status 2
0.8 1.25 30 A Code change +
36s RA
2009, RTCA, Inc.

Appendix R
Page R - 5
R.3.3 Scenario 3: Airborne, TSS, Permanent Alert State (7500, 7600, 7700)
Conditions:
Airborne
Permanent Alert State (7500, 7600, 7700)
Table R-3: Airborne, TSS, Permanent Alert State (7500, 7600, 7700)
Time
Average Peak Number
Between
Number Number over
2 Comment
per per 60
Transmissions
(seconds)
2.5 0.4 1 24
Aircraft Operational Status
0.8 1.25 -
5 0.2 -
Aircraft Status
0.8 1.25 2 75 for 60s
For this scenario the average number of Extended Squitters is greater than 6.2 per second.
However, it can be considered that the occurrence of this scenario is a rare event, and if it
happens it will be on a very limited number of aircraft in the coverage.
2009, RTCA, Inc.

Appendix R
Page R - 6
R.3.4 Scenario 4: Airborne, no TSS, NAC/SIL Change

Conditions:
Airborne
Target State and Status Message not being broadcast
Change occurs in the status of one or more of TCAS/NAC/SIL
Table R-4: Airborne, no TSS, NAC/SIL Change

Time
Average Peak Number
Between
Number Number over
2 Comment
per per 60
Transmissions
(seconds)
Target State and Status 1.25 0.8 - -
2.5 0.4 14 for 36s
Aircraft Operational Status for 24s after a
0.8 1.25 30
2 NAC/SIL change
5 0.2 12
Aircraft Status
0.8 1.25 1 -
2009, RTCA, Inc.

Appendix R
Page R - 7
R.3.5 Scenario 5: Airborne, no TSS, TCAS/NAC/SIL Change, Mode A Code Change

Conditions:
Airborne
Target State and Status Message not being broadcast
Change in Mode A Code
Change in the status of one or more of TCAS/NAC/SIL
Table R-5: Airborne, no TSS, TCAS/NAC/SIL Change, Mode A Code Change

Time
Average Peak Number
Between
Number Number over
2 Comment
per per 60
Transmissions
(seconds)
Target State and Status 1.25 0.8 - -
2.5 0.4 14 for 36s
for 24s after a
Aircraft Operational Status
0.8 1.25 2 30 TCAS/NAC/
SIL change
5 0.2 7 for 36s
Aircraft Status 2 for 24s after Mode
0.8 1.25 30
A Code change
2009, RTCA, Inc.

Appendix R
Page R - 8
R.3.6 Scenario 6: On-the-Ground, Moving, Mode A Code Change, NICSUPP/NAC/SIL

Change
Conditions:
On-the-Ground
Moving
Change in Mode A Code
Change in the status of one or more of NICSUPP/NAC/SIL
Table R-6: On-the-Ground, Moving, Mode A Code Change, NICSUPP/NAC/SIL Change

Time
Average Peak Number
Between
Number Number over
2 Comment
per per 60
Transmissions
(seconds)
Surface Position Message 0.5 2 2 120
2.5 0.4 14 for 36s
for 24s after a
0.8 1.25 30 NIC/NAC/SIL
change
5 0.2 7 for 36s
Aircraft Status 2 for 24s after Mode
0.8 1.25 30
A Code change
2009, RTCA, Inc.


1090 WP30 18 Draft - Do 260B V42

Uploaded by

Copyright:

Available Formats

You might also like

1090 WP30 18 Draft - Do 260B V42

Uploaded by

Document Information

Original Title

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

1090 WP30 18 Draft - Do 260B V42

Uploaded by

Copyright:

Available Formats

Working Paper 1090-WP30-18 as DRAFT Version 4.

Minimum Operational Performance Standards for

This is a DRAFT Version 4.2 Working Copy of this document.

RTCA DO-260B Prepared by: SC-186

Working Paper 1090-WP30-18 as DRAFT Version 4.2 of DO-282B

Copies of this document may be obtained from

Please call RTCA for price and ordering information.

Working Paper 1090-WP30-18 as DRAFT Version 4.2 of DO-282B

Working Paper 1090-WP30-18 as DRAFT Version 4.2 of DO-282B

This page intentionally left blank.

Working Paper 1090-WP30-18 as DRAFT Version 4.2 of DO-282B

This page intentionally left blank.

1.0 PURPOSE AND SCOPE

Compliance with these standards by manufacturers, installers and users is recommended as

In addition, since the measured values of equipment performance characteristics may be a

20xx, RTCA, Inc.

Appendix A is normative whereas Appendices B through Q are informative. The following

Appendix C discusses aircraft antenna performance characteristics and identifies

Appendix F presents a traceability matrix to the ADS-B MASPS (RTCA DO-242A).

Appendix G discusses transition issues for ADS-B avionics.

Appendix J discusses determining the Navigation Accuracy Category for velocity

20xx, RTCA, Inc.

Appendix M provides a description of techniques for extending the effective air-to-air

Appendix O provides specifics for possible future use of additional intent

Appendix Q presents a proposed format for a Runway Threshold On-Condition

1.2 System Overview

20xx, RTCA, Inc.

TIS-B (Traffic Information Service Broadcast) is a function in which transmitters on the

Figure 1-1: The Scope of the 1090 MHz ADS-B System

20xx, RTCA, Inc.

Figure 1-2: Scope of the 1090 MHz TIS-B System

1.2.2 1090 MHz ADS-B System

1.2.3 ADS-B Avionics Integrity

20xx, RTCA, Inc.

Guidance on the above assessments can be found in:

SAE ARP4754/ED79 -- Certification Considerations for Highly-Integrated or

FAA AC 23.1309-1C Equipment, Systems, and Installations in Part 23

FAA AC 25.1309-1A -- Advisory Circular, System Design and Analysis.

20xx, RTCA, Inc.

1.2.4 1090 MHz ADS-B Subsystem Implementations

1090 MHz ADS-B Transmitting Subsystem

1090 MHz ADS-B & TIS-B Receiving Subsystem

Figure 1-3: 1090 MHz ADS-B Subsystems.

1.2.4.1 Source 1090 MHz ADS-B Transmitting Subsystem

1.2.4.1.1 Transponder-Based Subsystems

20xx, RTCA, Inc.

1.2.4.1.2 Non-Transponder-Based Subsystems

1. The term Non-Transponder-Based within the context of DO-260B is not intended to

2. Installation of Non-Transponder-Based 1090 MHz ADS-B equipment in airplanes

1.2.4.2 1090 MHz ADS-B & TIS-B Receiving Subsystem

20xx, RTCA, Inc.

1.2.4.2.1 Type 1 Report Assembly Function

1.2.4.2.2 Type 2 Report Assembly

1.2.4.3 Major Operating Characteristics

20xx, RTCA, Inc.

Non-Transponder-Based ADS-B Transmitting Subsystems and TIS-B Transmitting

1.2.5 Typical System Operation

20xx, RTCA, Inc.