Minimum Aviation System Performance Standards for Aircraft ...

1150 18 th Street, NW, Suite 910 

Washington, DC 20036, USA 

Minimum Aviation System Performance Standards 

for Aircraft Surveillance Applications 

Draft Version 6.0 

Month day, 20xx Prepared by: SC-186 

RTCA/DO-3?? © 20xx, RTCA, Inc.

Copies of this document may be obtained from 

RTCA, Inc. 

1150 18 th Street, NW, Suite 910 

Washington, DC 20036, 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 RTCA Special Committee 186 (SC-186), and was approved for 

publication by the RTCA Program Management Committee (PMC) on Month Day, 20xx. 

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. RTCA’s 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 organization’s 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 

1 PURPOSE AND SCOPE......................................................................................................................1 

1.1 Introduction .........................................................................................................................................1 

1.2 System Overview.................................................................................................................................2 

1.2.1 Definition of Aircraft Surveillance Applications .............................................................................2 

1.2.2 Application Assumptions .................................................................................................................3 

1.2.3 ASA Architecture .............................................................................................................................3 

1.2.3.1 ASA Transmit Participant Subsystem ...........................................................................................4 

1.2.3.2 ASA Receive Participant Subsystem.............................................................................................5 

1.2.3.3 Ground Subsystems .......................................................................................................................6 

1.2.4 Relationship to TCAS.......................................................................................................................6 

1.2.5 Relationship to Other RTCA / EUROCAE Documents ...................................................................7 

1.3 Operational Application(s) ..................................................................................................................8 

1.3.1 Initial Applications ...........................................................................................................................9 

1.3.1.1 Enhanced Visual Acquisition (EVAcq).........................................................................................9 

1.3.1.2 AIRB..............................................................................................................................................9 

1.3.1.3 Visual Separation on Approach (VSA) .........................................................................................9 

1.3.1.4 Basic Surface Situational Awareness (SURF)...............................................................................9 

1.3.1.5 Oceanic In-Trail Procedures (ITP) ..............................................................................................10 

1.3.2 Emerging Applications...................................................................................................................10 

1.3.2.1 Airport Surface Situational Awareness with Indications and Alerts (SURF IA) ........................10 

1.3.2.2 Traffic Situational Awareness with Alerts (TSAA) ....................................................................10 

1.3.2.3 Flight-Deck Based Interval Management-Spacing (FIM-S) .......................................................10 

1.4 System Scope and Definition of Terms.............................................................................................10 

2 OPERATIONAL REQUIREMENTS...............................................................................................13 

2.1 General Requirements .......................................................................................................................13 

2.1.1 General Performance ......................................................................................................................13 

2.1.1.1 Consistent Quantization of Data..................................................................................................13 

2.1.1.2 ADS-B Reports Characteristics ...................................................................................................14 

2.1.1.3 Expandability...............................................................................................................................14 

2.2 System Performance – Standard Operational Conditions..................................................................14 

2.2.1 ADS-B System-Level Performance................................................................................................14 

2.2.1.1 ADS-B System-Level Performance—Aircraft Needs .................................................................21 

2.2.1.2 ADS-B System-Level Performance – ATS Provider Needs for Separation and Conflict 

Management................................................................................................................................................31 

2.2.2 ATS Conformance Monitoring Needs............................................................................................37 

2.2.2.1 Operational Scenario (Parallel Runway Monitoring) ..................................................................38 

2.2.2.2 Requirements...............................................................................................................................38 

3 ADS-B AND AIRBORNE SYSTEMS DEFINITION AND PERFORMANCE 

REQUIREMENTS....................................................................................................................................39 

3.1 System Descriptions ..........................................................................................................................39 

3.1.1 ADS-B Subsystem Description (Transmit and Receive)................................................................39 

3.1.1.1 Context Level Description...........................................................................................................39 

3.1.1.2 Participant Architecture Examples .............................................................................................. 44 

3.1.1.3 Equipage Classifications..............................................................................................................45 

i

3.1.2 ASSAP Subsystem Description......................................................................................................49 

3.1.2.1 ASSAP/CDTI System Boundaries ..............................................................................................49 

3.1.3 CDTI Subsystem Description.........................................................................................................51 

3.1.4 ANSP Systems................................................................................................................................51 

3.1.4.1 ADS-B (Ground Receive) ...........................................................................................................51 

3.1.4.2 TIS-B and ADS-R Service Description.......................................................................................54 

3.1.4.3 TIS-B and ADS-R Subsystem Requirements ..............................................................................64 

3.1.5 Surface Vehicles.............................................................................................................................77 

3.2 Broadcast Information Elements Requirements ................................................................................78 

3.2.1 Time of Applicability (TOA) .........................................................................................................78 

3.2.2 Identification...................................................................................................................................78 

3.2.2.1 Call Sign / Flight ID ....................................................................................................................78 

3.2.2.2 Participant Address and Address Qualifier..................................................................................78 

3.2.2.3 ADS-B Emitter Category.............................................................................................................80 

3.2.2.4 Mode 3/A Code ...........................................................................................................................81 

3.2.3 A/V Length and Width Codes ........................................................................................................81 

3.2.4 Position...........................................................................................................................................81 

3.2.4.1 ADS-B Position Reference Point.................................................................................................82 

3.2.4.2 Altitude........................................................................................................................................85 

3.2.5 Horizontal Velocity ........................................................................................................................86 

3.2.6 Vertical Rate...................................................................................................................................86 

3.2.7 Heading...........................................................................................................................................87 

3.2.8 Capability Class (CC) Codes..........................................................................................................87 

3.2.8.1 TCAS/ACAS Operational ...........................................................................................................87 

3.2.8.2 1090 MHz ES Receive Capability...............................................................................................88 

3.2.8.3 ARV Report Capability Flag .......................................................................................................88 

3.2.8.4 TS Report Capability Flag...........................................................................................................88 

3.2.8.5 TC Report Capability Level ........................................................................................................88 

3.2.8.6 UAT Receive Capability .............................................................................................................89 

3.2.8.7 Other Capability Codes ...............................................................................................................89 

3.2.9 Operational Mode (OM) Codes......................................................................................................89 

3.2.9.1 TCAS/ACAS Resolution Advisory Active Flag .........................................................................89 

3.2.9.2 IDENT Switch Active Flag .........................................................................................................89 

3.2.9.3 Reserved for Receiving ATC Services Flag................................................................................90 

3.2.9.4 Single Antenna Flag ....................................................................................................................90 

3.2.9.5 System Design Assurance (SDA)................................................................................................90 

3.2.9.6 GPS Antenna Offset ....................................................................................................................91 

3.2.9.7 Other Operational Mode Codes...................................................................................................93 

3.2.10 Navigation Integrity Category......................................................................................................93 

3.2.11 Navigation Accuracy Category for Position (NACP) ...................................................................95 

3.2.12 Navigation Accuracy Category for Velocity (NACV) ..................................................................96 

3.2.13 Source Integrity Level (SIL).........................................................................................................97 

3.2.14 Barometric Altitude Integrity Code (NICBARO) ............................................................................98 

3.2.15 Emergency/Priority Status............................................................................................................98 

3.2.16 Geometric Vertical Accuracy (GVA)...........................................................................................99 

3.2.17 TCAS/ACAS Resolution Advisory (RA) Data Block..................................................................99 

3.2.18 ADS-B Version Number...............................................................................................................99 

3.2.19 Selected Altitude Type .................................................................................................................99 

3.2.20 MCP/FCU or FMS Selected Altitude Field................................................................................100 

3.2.21 Barometric Pressure Setting (Minus 800 millibars) Field ..........................................................101 

3.2.22 Selected Heading Status Field ....................................................................................................102 

3.2.23 Selected Heading Sign Field.......................................................................................................102 

3.2.24 Selected Heading Field...............................................................................................................103 

ii

3.2.25 Status of MCP/FCU Mode Bits ..................................................................................................103 

3.2.26 Mode Indicator: Autopilot Engaged Field..................................................................................104 

3.2.27 Mode Indicator: VNAV Mode Engaged Field ...........................................................................104 

3.2.28 Mode Indicator: Altitude Hold Mode Field................................................................................104 

3.2.29 Mode Indicator: Approach Mode Field ......................................................................................105 

3.2.30 Mode Indicator: LNAV Mode Engaged Field............................................................................105 

3.3 System Application Requirements ..................................................................................................106 

3.3.1 Latency .........................................................................................................................................106 

3.3.1.1 Key Latency Definitions............................................................................................................106 

3.3.1.2 System Interface Definitions .....................................................................................................108 

3.3.1.3 Total Latency for ADS-B and ADS-R.......................................................................................111 

3.3.1.4 Navigation Subsystem Latency Allocation ...............................................................................111 

3.3.1.5 TIS-B Subsystem Latency Allocation .......................................................................................111 

3.3.1.6 Latency Compensation Error.....................................................................................................112 

3.3.2 ADS-R/TIS-B Service Status Update Interval..............................................................................112 

3.4 Subsystem Requirements.................................................................................................................113 

3.4.1 Subsystem Requirements for ASSAP...........................................................................................113 

3.4.1.1 Definitions .................................................................................................................................114 

3.4.1.2 General Requirements ...............................................................................................................115 

3.4.1.3 Input Interface Requirements ....................................................................................................115 

3.4.1.4 ASSAP Functional Requirements..............................................................................................118 

3.4.1.5 Output Interface Requirements to CDTI ...................................................................................119 

3.4.1.6 ASSAP Performance Requirements ..........................................................................................120 

3.4.2 Subsystem Requirements for CDTI..............................................................................................120 

3.4.2.1 General CDTI Requirements .....................................................................................................120 

3.4.2.2 Time of Applicability ................................................................................................................121 

3.4.2.3 Information Integrity .................................................................................................................121 

3.4.2.4 Applications Supported .............................................................................................................121 

3.4.2.5 Units of Measure .......................................................................................................................122 

3.4.2.6 Information Exchange with ASSAP..........................................................................................122 

3.4.2.7 Traffic Symbols .........................................................................................................................122 

3.4.2.8 TCAS Integration ......................................................................................................................122 

3.4.2.9 Multi-Function Display (MFD) Integration ..............................................................................123 

3.4.2.10 Failure Annunciation ...............................................................................................................123 

3.4.2.11 Suitability of Traffic for Applications .....................................................................................123 

3.4.2.12 Warnings and Alerts ................................................................................................................123 

3.4.2.13 Display Configuration .............................................................................................................123 

3.4.2.14 Accessibility of Controls .........................................................................................................124 

3.4.2.15 Information Displayed.............................................................................................................124 

3.4.2.16 General CDTI Symbol Requirements......................................................................................124 

3.4.2.17 CDTI Design Assurance..........................................................................................................124 

3.4.2.18 Ownship State Information......................................................................................................124 

3.4.3 Subsystem Requirements for ADS-B ...........................................................................................125 

3.4.3.1 ADS-B Surveillance Coverage..................................................................................................125 

3.4.3.2 ADS-B Information Exchange Requirements by Equipage Class.............................................127 

3.4.3.3 ADS-B Data Exchange Requirements.......................................................................................130 

3.4.3.4 ADS-B Network Capacity .........................................................................................................137 

3.4.3.5 ADS-B Medium.........................................................................................................................141 

3.4.3.6 ADS-B System Quality of Service ............................................................................................142 

3.5 Messages and Reports .....................................................................................................................145 

3.5.1 ADS-B Messages and Reports......................................................................................................145 

3.5.1.1 Report Assembly Design Considerations ..................................................................................146 

3.5.1.2 ADS-B Message Exchange Technology Considerations in Report Assembly..........................146 

iii

3.5.1.3 ADS-B State Vector Report.......................................................................................................147 

3.5.1.4 Mode Status Report ...................................................................................................................156 

3.5.1.5 On-Condition Reports................................................................................................................162 

3.5.1.6 Air Referenced Velocity (ARV) Report ....................................................................................163 

3.5.1.7 Target State (TS) Report............................................................................................................165 

3.5.2 Traffic Information Services – Broadcast (TIS-B) Messages and Reports ..................................167 

3.5.2.1 Introduction to TIS-B ................................................................................................................167 

3.5.2.2 TIS-B Message Processing and Report Generation...................................................................168 

3.5.3 ADS-B Rebroadcast Service (ADS-R) Messages and Reports ....................................................168 

3.6 External Subsystem Requirements ..................................................................................................168 

3.6.1 Own-ship Position Data Source....................................................................................................168 

3.6.2 Air Data Source ............................................................................................................................170 

3.6.3 Heading Source.............................................................................................................................170 

3.6.4 TCAS............................................................................................................................................171 

3.6.5 Airport Surface Maps ...................................................................................................................171 

3.6.5.1 Features......................................................................................................................................172 

3.6.5.2 Quality .......................................................................................................................................172 

3.6.5.3 Reference Datum .......................................................................................................................173 

3.6.6 Flight ID Source ...........................................................................................................................173 

3.6.7 Flight Control System/Mode Control Panel .................................................................................173 

3.6.8 Other External Systems ................................................................................................................173 

3.7 Functional Level Requirements.......................................................................................................173 

4 ADS-B IN SYSTEM APPLICATIONS REQUIREMENTS.........................................................176 

4.1 Basic Airborne Situation Awareness (AIRB)..................................................................................176 

4.2 Visual Separation on Approach (VSA) ...........................................................................................176 

4.3 Basic Surface Situational Awareness (SURF).................................................................................176 

4.4 In Trail Procedures (ITP).................................................................................................................176 

4.5 Interval Management.......................................................................................................................177 

4.5.1 FIM...............................................................................................................................................177 

4.5.2 GIM-S...........................................................................................................................................177 

4.6 Future Applications .........................................................................................................................178 

4.6.1 Airport Surface with Indications and Alerts (SURF-IA)..............................................................178 

4.6.2 Traffic Situational Awareness with Alerts (TSAA) .....................................................................179 

iv

APPENDICES 

Appendix A 

Acronyms and Definitions of Terms (taken from DO-242A 

Appendix A and B, and Appendix AA from DO-289) 

Gary Furr 

Appendix B 

Bibliography and References (taken from DO-242A, Appendix 

C, and Appendix AB from DO-289) 

Gary Furr 

Appendix C Derivation of Link Quality Requirements for Future Applications Dean Miller 

Appendix D 

Receive Antenna Coverage Constraints 

(update old DO-242A Appendix H) 

Tom Pagano 

Stan Jones 

Appendix E Target State stuff to be moved from the Body into this Appendix Tom Pagano 

Appendix F 

Derivation of Track Acquisition and Maintenance Requirements 

(update old DO- 242A Appendix L) 

Tom Pagano 

Appendix G 

Future Air-Referenced Velocity (ARV) Broadcast Conditions 

(update old DO-242A Appendix Q) 

Tom Pagano 

v

LIST OF TABLES 

Table 2-5: High Level Considerations for ADS-B In Applications by Category ...................................... 16 

Table 2-6: Required Information Elements to Support Selected ADS-B Applications.............................. 17 

Table 2-7: ADS-B Transmit Sources – Minimum Required Performance vs ADS-B In 

Application Requirements ................................................................................................ 18 

Table 2-8: Summary of A/V-to-A/V Performance Assumptions for Support of Indicated 

Applications...................................................................................................................... 20 

Table 2-9(a): Summary of Expected ATS Provider Surveillance and Conflict Management 

Current Capabilities for Sample Scenarios ....................................................................... 32 

Table 2-9(b): Additional Expected Capabilities Appropriate for ADS-B Supported Sample 

Scenarios........................................................................................................................... 33 

Table 2-10: ADS-B Out Applications to Support ATC Surveillance - Minimum Performance 

Requirements .................................................................................................................... 35 

Table 3.1.1.3.2a: Subsystem Classes and Their Features .......................................................................... 48 

Table 3.1.4.3.1.1a: Transmitted 1090 TIS-B Message Types..................................................................... 65 

Table 3.1.4.3.1.1b: Payload Composition of 1090ES TIS-B Messages ..................................................... 66 

Table 3.1.4.3.1.1c: Payload Composition of UAT TIS-B Messages .......................................................... 67 

Table 3.1.4.3.1.2.1: Requirements for Track Accuracy.............................................................................. 70 

Table 3.1.4.3.2.1: 1090ES ADS-R Message Types to Encode Upon Receipt of UAT Message 

Types................................................................................................................................. 73 

Table 3.2.4.1a: Dimensions of Defining Rectangle for Position Reference Point...................................... 83 

Table 3.2.8.3: ARV Report Capability Flag ............................................................................................... 88 

Table 3.2.8.4: TS Report Capability Flag ................................................................................................... 88 

Table 3.2.8.5: TC Report Capability Levels ............................................................................................... 88 

Table 3.2.9.5: SDA OM Subfield in Aircraft Operational Status Messages............................................... 91 

Table 3.2.9.6A: Lateral Axis GPS Antenna Offset Values......................................................................... 92 

Table 3.2.9.6B: Longitudinal Axis GPS Antenna Offset Encoding ........................................................... 93 

Table 3.2.10a: Navigation Integrity Categories (NIC). ............................................................................. 94 

Table 3.2.11a: Navigation Accuracy Categories for Position (NACP). ..................................................... 96 

Table 3.2.12a: Navigation Accuracy Categories for Velocity (NACV). .................................................... 97 

Table 3.2.13a: Source Integrity Level (SIL) Encoding............................................................................... 98 

Table 3.2.15a: Emergency State Encoding ................................................................................................. 98 

Table 3.2.16: Geometric Vertical Accuracy (GVA) Parameter .................................................................. 99 

Table 3.2.18: ADS-B Version Number....................................................................................................... 99 

Table 3.2.19: Selected Altitude Type Field Values .................................................................................. 100 

Table 3.2.20: “MCP/FCU Selected Altitude or FMS Selected Altitude” Field Values............................ 101 

Table 3.2.21: Barometric Pressure Setting (Minus 800 millibars) Field Values ...................................... 102 

Table 3.2.22: Selected Heading Status Field Values ................................................................................ 102 

Table 3.2.23: Selected Heading Sign Field Values................................................................................... 102 

Table 3.2.24: Selected Heading Status, Sign and Data Field Values........................................................ 103 

Table 3.2.25: Status of MCP/FCU Mode Bits Field Values..................................................................... 104 

Table 3.2.26: Mode Indicator: Autopilot Engaged Field Values.............................................................. 104 

Table 3.2.27: “Mode Indicator: VNAV Engaged” Field Values .............................................................. 104 

Table 3.2.28: “Mode Indicator: Altitude Hold Mode” Field Values ........................................................ 105 

Table 3.2.29: “Mode Indicator: Approach Mode” Field Values............................................................... 105 

Table 3.2.30: “Mode Indicator: LNAV Mode Engaged” Field Values .................................................... 105 

Table 3.4.1.3: ASSAP Input Interface Requirements ............................................................................... 115 

Table 3.4.3.1a: Operational Range and Normalized Transmit/Receive Parameters by Interactive 

Aircraft Equipage Class .................................................................................................. 126 

vi

Table 3.4.3.1b: Interoperability Ranges in NM for Aircraft Equipage Class Parameters Given in 

Table 3.4.3.1a.................................................................................................................. 127 

Table 3.4.3.2a: Interactive Aircraft/Vehicle Equipage Type Operational Capabilities ........................... 128 

Table 3.4.3.2b: Broadcast and Receive Only Equipage Type Operational Capabilities.......................... 129 

Table 3.4.3.3.1.1a: SV Update Interval and Acquisition Range Requirements....................................... 132 

Table 3.4.3.3.1.2a: MS Acquisition Range Requirements....................................................................... 134 

Table 3.4.3.3.1.3a: Summary of TS Report Acquisition Range and Update Interval Requirements........ 137 

Table 3.5.1.3: State Vector Report Definition ......................................................................................... 147 

Table 3.5.1.3.19: SV Report Mode Values............................................................................................... 156 

Table 3.5.1.4: Mode Status (MS) Report Definition................................................................................. 157 

Table 3.5.1.6: Air Referenced Velocity (ARV) Report Definition.......................................................... 163 

Table 3.5.1.6.5: Airspeed Type Encoding ................................................................................................ 164 

Table 3.5.1.7: Target State (TS) Report Definition ................................................................................. 165 

Table 3.6.4: TCAS Traffic Data Interface to ASSAP............................................................................... 171 

LIST OF FIGURES 

Figure 1-1: Overview of ASA Architecture.................................................................................................. 4 

Figure 1-2: Relationship Between Combined MASPS And Other RTCA Documents ................................ 7 

Figure 3-1: Illustrative ADS-B System Level Context Diagram ................................................................ 41 

Figure 3-2: ADS-B Subsystem Level Context Diagram for ADS-B System ............................................. 42 

Figure 3-3: ADS-B Functional Level Context Diagram for Aircraft Interactive Subsystem ..................... 43 

Figure 3-4: Example of A/C Pair Supporting Aid to Visual Acquisition and TSAA ................................. 44 

Figure 3-5: Example of A/C Pair Capable of Supporting Advanced ADS-B Applications ....................... 45 

Figure 3-6: Example of ADS-B Support of Ground ATS Applications ..................................................... 46 

Figure 3-7: ASSAP/CDTI Subsystem Boundaries .................................................................................... 50 

Figure 3-8: SBS System Reference Architecture....................................................................................... 55 

Figure 3-9: ADS-R Service Data Flows Data............................................................................................. 56 

Figure 3-10: ADS-R and TIS-B Functional Architecture and Data Flows................................................. 57 

Figure 3-11: ADS-R Client Proximity Determination................................................................................ 59 

Figure 3-12: TIS-B Service Data Flow....................................................................................................... 61 

Figure 3-13: TIS-B Client Proximity Determination.................................................................................. 63 

Figure 3-14: Position Reference Point Definition...................................................................................... 84 

Figure 3-15: End to End ASA System Latency Diagram ......................................................................... 107 

Figure 3-16: ASA System Latency Diagram ............................................................................................ 108 

Figure 3-17: ASSAP Input / Output and Requirement Section Summary................................................ 114 

Figure xx: Radial traffic distributions during Northeast Corridor test flight............................................ 139 

Figure zz: Cumulative Altitude Distribution Model vs. 25Jul07 Data ..................................................... 140 

Figure yy: Recent ZNY traffic growth forecasts ...................................................................................... 141 

Figure 3-18: GNSS/ADS-B Surveillance/Navigation Failure Recovery Modes ...................................... 144 

Figure 4-1: Overview of IM Applications ................................................................................................ 178 

Figure 4-2: Example for SURF IA Indication (left) and A SURF IA warning alert (right) ..................... 179 

vii

This Page Intentionally Left Blank. 

viii

1 PURPOSE AND SCOPE 

1.1 Introduction 

This document contains Minimum Aviation System Performance Standards (MASPS) for 

Aircraft Surveillance Applications (ASA). This document is intended to specify 

requirements for and describe assumptions for all sub-systems supporting the operational 

application of ASA, e.g., Automatic Dependent Surveillance - Broadcast (ADS-B), 

Airborne Surveillance and Separation Assurance Processing (ASSAP), and Cockpit 

Display of Traffic Information (CDTI). 

These standards specify characteristics that should be useful to designers, installers, 

manufacturers, service providers and users for systems intended for operational use 

within the United States National Airspace System (NAS). Where systems are global in 

nature, the system may have international applications that are taken into consideration. 

Compliance with these standards is recommended as one means of assuring that the 

system and each subsystem will perform its intended function(s) satisfactorily under 

conditions normally encountered in routine aeronautical operations for the environments 

intended. This MASPS may be implemented by one or more regulatory documents or 

advisory documents (e.g., certifications, authorizations, approvals, commissioning, 

advisory circulars, notices, etc.) and may be implemented in part or in total. Any 

regulatory application of this document is the sole responsibility of the appropriate 

governmental agencies. 

Chapter 1 of this document describes the Aircraft Surveillance Applications system and 

provides information needed to understand the rationale for function characteristics and 

requirements. This section describes typical applications and operational goals, as 

envisioned by members of RTCA Special Committee 186, and establishes the basis for 

the standards stated in Chapters 2 through 4. Definitions and assumptions essential to the 

proper understanding of this document are also provided in this section. Additional 

definitions are provided in Appendix A. 

Chapter 2 describes minimum system performance requirements for the ASA system 

under standard operating and environmental conditions. ASA functional requirements 

and associated performance requirements are provided. 

Chapter 3 contains the minimum performance standards for each subsystem that is a 

required element of the minimum system performance specified in Chapter 2, as well as 

the interface requirements between these subsystems. Assumptions about expected 

standards for systems external to ASA are also documented. 

Chapter 4 contains the minimum performance standards for each ASSAP system 

application requiring the processing of ADS-B messages that have been received and 

assembled into reports. The applications are grouped into broad categories of situational 

awareness, spacing applications, and separation applications. 

The appendices are as follows: 

A: Acronyms and Definitions of Terms 

B: Bibliography and References 

C: Derivation of Link Quality Requirements for Future Applications 

© 20xx, RTCA, Inc. 

1

2 

D: Receive Antenna Coverage Constraints 

E: Target State stuff to be removed from the body and captured in this 

Appendix 

F: Derivation of Track Acquisition and Maintenance Requirements 

G: Future Air-Referenced Velocity (ARV) Broadcast Conditions 

The word “sub-function” as used in this document includes all components that make up 

a major independent, necessary and essential functional part of the system (i.e., a 

subsystem) so that the system can properly perform its intended function(s). If the 

system, including any sub-functions, includes computer software or electronic hardware, 

the guidelines contained in [RTCA DO-178B and DO-254] should be considered even for 

non-aircraft applications. 

1.2 System Overview 

Today’s airspace system provides separation assurance for aircraft operating under 

Instrument Flight Rules (IFR) via air traffic control and air traffic services (ATC/ATS), 

which are ground-based. These services utilize ground radar surveillance (primary and 

secondary surveillance radars), controller radar displays, air route infrastructure, airspace 

procedures including flight crew see and avoid, and VHF voice communications to assure 

separation standards are maintained. In the event of failure of this separation assurance 

system, aircraft equipped with Airborne Collision Avoidance Systems (ACAS), i.e., 

TCAS, are warned of potential mid-air collisions as a safety back up. 

In order to accommodate expected increases in air traffic, a future separation assurance 

system is evolving using new technologies and automation processing support that is 

expected to enable the delegation of certain spacing or separation tasks to the flight deck. 

ASA represents the aircraft-based portion of this future separation assurance system. A 

wide range of separation assurance applications are expected to be developed over time 

that will enable enhanced airspace operations. These enhanced operations are intended to 

provide improved operational efficiencies, such as increased system capacity and 

throughput, while maintaining or improving air safety. Both aircraft-based and groundbased 

applications are discussed in this document. 

1.2.1 Definition of Aircraft Surveillance Applications 


The ASA system comprises a number of flight-deck-based aircraft surveillance and 

separation assurance capabilities that may directly provide flight crews with surveillance 

information, as well as surveillance-based guidance and alerts. Surveillance information 

consists of position and other state data about other aircraft and surface vehicles and 

obstacles when on or near the airport surface. 

ASA applications are intended to both enhance safety and increase the capacity and 

efficiency of the air transportation system. Safety will be enhanced by providing 

improved traffic situational awareness to pilots, as well as capabilities to assist in conflict 

prevention, conflict detection, and 4-D conflict resolution. Capacity and efficiency will 

be enhanced by enabling aircraft to fly closer to one another and potentially delegating 

certain spacing or separation tasks to the flight crew, for example: 

� Improving runway throughput in instrument meteorological conditions (IMC) 

through use of new cockpit tools; 

� More efficient departure sequencing without increases in ATC workload;

� Enabling aircraft in oceanic airspace to fly more optimal cruise profiles and pass 

other aircraft on parallel routes; and 

� Accommodating more kinds of flight trajectories than ATC currently authorizes. 

The individual ASA applications are described in §1.3. It is a goal of these applications 

to minimize any increase in workload while ensuring safety. Particular attention is paid 

to preventing workload increases during critical phases of flight, such as final approach 

and landing. 

Some ASA applications are independent of ground systems and air traffic control, while 

others depend on or interact with services provided by ground systems and air traffic 

control. This MASPS does specify requirements for ground systems such as Traffic 

Information Service – Broadcast (TIS-B) and the Automatic Dependent Surveillance – 

Rebroadcast (ADS-R) service and states assumptions about the functional and 

performance capabilities of the services they provide to the extent that these are required 

by ASA applications. ADS-B is used to augment or improve current ATC ground 

surveillance. 

1.2.2 Application Assumptions 

To achieve the expected gains, this document makes certain assumptions about the use of 

new technology. These assumptions include, but are not limited to: 

A. Flight crews, in appropriately equipped aircraft, will be able to perform some 

functions currently done by ATC, some of which may be at reduced separation 

standards compared to current separation standards. 

B. The variability in the spacing between aircraft in the airport arrival and/or 

departure streams will be reduced with the use of certain ASA applications. 

C. Pilots will be willing to accept additional separation responsibility beyond what 

they have today that is currently provided by ATC. 

D. Pilot and ATC workload will not be increased substantially by ASA applications. 

E. Most aircraft will eventually be equipped with avionics to perform ASA 

applications (this is necessary to maximize system benefits). 

F. ATC will be willing to act as a “monitor” and retain separation responsibility 

between designated aircraft. 

G. ADS-B avionics and applications will be compatible with future ATC systems and 

operating procedures. 

These assumptions have not yet been fully validated. 

1.2.3 ASA Architecture 

Figure 1-1 provides an overview of the ASA system architecture and depicts the 

interfaces between functional elements for an ASA aircraft participant and external 

systems. The ASA system architecture consists of three major components: subsystems 

for the transmit participant, subsystems for the receive participant, and the ground 

systems. The ASA also interfaces with other aircraft systems. 


3

4 

TIS-B, ADS-R Messages 

Figure 1-1: Overview of ASA Architecture 

Note that there is a clear distinction in the diagram between messages and reports. An 

ADS-B message is a block of formatted data that conveys the information elements used 

in the development of ADS-B reports. Message content and formats are unique for each 

of the ADS-B data links. The MASPS does not address these message definitions and 

structures. An ADS-B Report contains the information elements assembled by an ADS B 

receiver using message content received from ADS-B, ADS-R, and TIS-B messages from 

transmitting airborne and ground participants. These reports are available for use by 

applications external to the ADS B system. 

Aircraft ASA systems which include both link message transmit and receive capability 

are defined to be Class A systems. Systems which include only the link transmit 

capability are defined to be Class B systems. Subcategories within the classes define 

capability thresholds based on parameters such as transmit power and receiver sensitivity 

to align equipment capabilities with intended applications. Ground systems are defined to 

be Class C systems. 

1.2.3.1 ASA Transmit Participant Subsystem 


The subsystem for the ASA transmit participant accepts navigation and other data inputs 

from the aircraft, processes it to create the link unique ADS-B messages, and then 

broadcasts those ADS-B messages. The navigation data contains position and velocity 

information, as well as the accuracy and integrity parameters characterizing that data, 

either directly from a Global Navigation Satellite System (GNSS) receiver or a GNSS 

based navigation system. There are increasingly restrictive thresholds for the accuracy 

and integrity metrics of the navigation data as the system applications progress in 

criticality from situational awareness to separation assurance. 

Other data sources include the barometric altitude and altitude rate and pilot inputs such 

as the flight identification. A critical performance requirement in the transmit subsystem

is minimizing the latency between the time the GNSS sensor makes the position 

measurement and broadcasting it in the ADS-B messages. 

1.2.3.2 ASA Receive Participant Subsystem 

The subsystem for the ASA receive participant accepts ADS-B message from aircraft and 

other vehicles, ADS-R and TIS-B messages from the ground system, and navigation and 

other data inputs from the aircraft. 

1.2.3.2.1 ADS-B, TIS-B, ADS-R Receive Subsystem 

The received ADS-B, ADS-R, and TIS-B messages are processed by the ADS-B, ADS- 

R, TIS-B receive subsystem in the ASA aircraft. The receive subsystem processes these 

messages and provides reports to the ASSAP subsystem. The reports are then processed 

by the ASSAP subsystem. 

1.2.3.2.2 ASSAP Subsystem 

1.2.3.2.3 CDTI 

Processing is performed by ASSAP, which takes the incoming surveillance information 

and processes it according to the appropriate ASA application(s) as selected by the flight 

crew. For example, the ASSAP may predict a violation of the applicable separation 

minima, and determine appropriate resolution guidance. 

ASSAP is the processing subsystem that accepts surveillance reports, performs any 

necessary correlation and/or tracking, and performs application-specific separation 

assurance processing. Surveillance reports, tracks, and any application-specific alerts or 

guidance are output by ASSAP to the CDTI function. In addition to these interfaces and 

depending on the actual ASA application, ASSAP may interface to the Flight 

Management System (FMS) and / or the Flight Control (FC) systems for flight path 

changes, speed commands, etc. 

Display is accomplished through a Cockpit Display of Traffic Information (CDTI). The 

CDTI provides the flight crew interface to the ASA system. It displays traffic 

information as processed by the ASSAP. It provides other necessary information, such as 

alerts and warnings, and guidance information. The CDTI also provides flight crew 

inputs to the system, such as display preferences, application selection, and designation 

of specific targets and parameters for certain applications. 

The CDTI subsystem includes the actual visual display media, any aural alerting and the 

necessary controls to interface with the flight crew. Thus, the CDTI consists of a display 

and a control panel. The control panel may be a dedicated CDTI control panel or it may 

be incorporated into another control, e.g., a multi-function control display unit (MCDU). 

Similarly, the CDTI display may also be a stand-alone display (dedicated display) or the 

CDTI information may be presented on an existing display (e.g., multi-function display). 

The TCAS traffic display may be a separate display or TCAS traffic may be integrated 

with ASA surveillance data and presented in a combined format. If TCAS traffic is 

integrated with other surveillance data, only one symbol should be displayed to the flight 

crew for any one aircraft. 

Note: It is highly desirable that the TCAS traffic display be integrated with the CDTI. 


5

6 

1.2.3.3 Ground Subsystems 

1.2.3.3.1 TIS-B 

1.2.3.3.2 ADS-R 

Not all aircraft will be equipped to broadcast their position via ADS-B. It is anticipated 

that there will be a long transition period over which aircraft owners decide to equip their 

aircraft, and that some aircraft owners may choose never to equip. In addition, situations 

will occur where the ADS-B reporting equipment on an aircraft is not operating although 

it is installed. 

To fill this information gap, the concept of Traffic Information Service Broadcast (TIS- 

B) [DO-286B] was developed. Within their coverage areas, ground surveillance systems 

can determine the positions of transponder-equipped aircraft and broadcast this position 

data to ASA-equipped aircraft via TIS-B. Recently developed multi-lateration 

surveillance systems planned for the airport surface can provide position accuracies 

comparable to those from GPS. Away from the vicinity of the airport, ground radar 

systems will provide less accuracy, but the position information may still be suitable for 

providing situational awareness with respect to aircraft not equipped with ADS-B 

position reporting. 

Automatic Dependent Surveillance – Rebroadcast (ADS-R) messages are crosslink 

translations from UAT to 1090ES and from 1090ES to UAT provided by the ground 

surveillance service. The ADS-R service is only provided when an aircraft in range of 

the broadcast antenna indicates that it has the capability to accept messages that are 

relayed from the UAT ADS-B link to 1090ES ADS-B link, and likewise from 1090ES to 

UAT equipped aircraft. 

1.2.3.3.3 ADS-B Surveillance Sensors 

The ADS-B ground system is comprised of a network of radio stations designed to 

provide surveillance coverage throughout the NAS that is equivalent or better that 

existing radar coverage. The ADS-B system will provide aircraft position and state data 

with substantially better accuracy and update rates for ATC automation systems, which 

provide an opportunity for reduced separation standards and more efficient flight 

operations. 

1.2.4 Relationship to TCAS 


The Traffic-Alert and Collision Avoidance System (TCAS), known internationally as the 

Airborne Collision Avoidance System (ACAS), provides flight crews with a traffic 

situation display and with safety alerts. Its success, and the attempt to use it for some 

additional applications for which it was not intended or well suited, helped promote 

interest in a more general ASA system to address those applications not directly 

associated with collision avoidance. 

TCAS provides a backup safety system for separation assurance. On aircraft that carry 

both an ASA and a TCAS, the TCAS collision avoidance function must continue to 

function correctly when ASA fails. This need does not preclude an avionics architecture 

that integrates TCAS and ASA functionality in the same equipment, provided the 

frequency of common mode failures is sufficiently small in the context of providing 

collision avoidance protection when separation provision has failed. The operational

uses of TCAS and ASA, and in particular their flight crew interfaces, will have to be 

carefully coordinated in order to ensure that all the intended safety and operational 

benefits are provided. 

Note: If future ASA applications are proven to provide increased safety, the interaction 

between ASA and TCAS may be altered; this will require validation. 

ADS-B surveillance differs from TCAS surveillance in that ADS-B broadcasts position 

and velocity information while TCAS derives relative position information through an 

interrogate – reply protocol. ADS-B covers a larger range (potentially 90 to 120 NM), 

and has greater overall accuracy. Altitude information in both systems is dependent upon 

on-board equipment. As a last-minute safety system, TCAS only needs to provide 

surveillance to approximately 15 NM. While TCAS measures range with great accuracy, 

it is unable to make highly accurate bearing measurements because of the limitations 

imposed by the available antenna technology that can be installed on aircraft. When 

GNSS is used as the navigation data source for ADS-B, highly accurate position 

measurements can generally be provided in all dimensions. This may allow added 

integrity to vertical height based only on pressure altitude. The relative position between 

two aircraft is calculated from these position reports, rather than measured, and the 

accuracy does not depend on the distance between the aircraft. The relative position will 

also differ from TCAS systems in allowing for relatively compact and inexpensive 

implementations suitable for categories of aircraft where TCAS is not required and is not 

economically attractive. 

1.2.5 Relationship to Other RTCA / EUROCAE Documents 

The diagram in Figure 1-2 shows the relationships between the Aircraft Separation 

Assurance (ASA) MASPS and other RTCA SC-186 documents, such as the Automatic 

Dependent Surveillance – Broadcast (ADS-B) and Traffic Information Service – 

Broadcast (TIS-B) MASPS and the various link Minimum Operational Performance 

Standards (MOPS). 

Figure 1-2: Relationship Between Combined MASPS And Other RTCA Documents 

Two RTCA link MOPS have been identified: 1090 MHz Extended Squitter ADS-B 

(1090ES) and Universal Access Transceiver (UAT). The 1090ES MOPS has recently 


7

8 

been revised and issued as [RTCA DO-260B], Minimum Operational Performance 

Standards for 1090 MHz Extended Squitter Automatic Dependent Surveillance – 

Broadcast (ADS-B) and Traffic Information Services (TIS-B). The UAT MOPS has 

recently been revised and issued as [RTCA DO-282B], Minimum Operational 

Performance Standards for Universal Access Transceiver (UAT) Automatic Dependent 

Surveillance – Broadcast (ADS-B). EUROCAE Working Group 51 has issued [ED- 

108A], an updated MOPS for VDL Mode 4, and a third ADS-B link. Additionally, 

EUROCAE Working Group 51 has released [ED-102A] which is identical to [RTCA 

DO-260B]. 

Note: The VDL-4 ADS-B Link MOPS is a EUROCAE document, not an RTCA 

document. 

The Airborne Surveillance and Separation Assurance Processing (ASSAP) and the 

Cockpit Display of Traffic Information (CDTI) functions are closely related items and are 

written as a joint MOPS [RTCA DO-317A], Airborne Surveillance Application System 

(ASA) MOPS. 

Figure 1-2 also shows the functions under the auspices of RTCA SC-186 and those 

systems outside the scope of RTCA SC-186. This MASPS document makes 

requirements allocations to the functions under the auspices of RTCA SC-186 and makes 

assumptions on the systems outside the scope of RTCA SC-186. 

Surveillance Systems that are outside of the scope of RTCA SC-186 are the TCAS, 

Traffic Information Service (TIS), weather radar, and Flight Information Service – 

Broadcast (FIS-B). Terrain systems, e.g., Terrain Awareness and Warning System 

(TAWS) and Navigation systems, e.g., GPS, are also outside the scope of RTCA SC-186. 

1.3 Operational Application(s) 


The situational awareness and separation assurance capabilities of ASA are provided by 

applications. Numerous applications have been proposed, and it is expected that 

additional applications will be developed and standardized in future versions of this 

MASPS. The applications fall into five broad categories: situational awareness, 

enhanced situational awareness, spacing, delegated spacing, and self-separation. 

Situational awareness applications are aimed at enhancing the flight crews’ knowledge of 

the surrounding traffic situation both in the air and on the airport surface, and thus 

improving the flight crew’s decision process for the safe and efficient management of 

their flight. No changes in separation tasks or responsibility are required for these 

applications Enhanced situational applications add provisions such as cueing to the pilot 

through indications and alerts, or providing a new separation standard during the 

procedure. 

Spacing applications require flight crews to achieve and maintain a given spacing with 

designated aircraft, as specified in a new ATC instruction. Although the flight crews are 

given new tasks, separation provision is still the controller's responsibility and applicable 

separation minima are unchanged. 

In delegated separation applications, the controller delegates separation responsibility and 

transfers the corresponding separation tasks to the flight crew, who ensures that the 

applicable airborne separation minima are met. The separation responsibility delegated 

to the flight crew is limited to designated aircraft, specified by a new clearance, and is 

limited in time, space, and scope. Except in these specific circumstances, separation

provision is still the controller's responsibility. These applications will require the 

definition of airborne separation standards. 

Self separation applications require flight crews to separate their flight from all 

surrounding traffic, in accordance with the applicable airborne separation minima and 

rules of flight. 

1.3.1 Initial Applications 

This document specifies detailed requirements for an initial set of applications. EVAcq 

defines the requirements ASA systems must meet to provide ADS-B enhanced traffic 

situational awareness. The AIRB application defines the requirements ASA systems 

must meet to provide enhanced traffic situational awareness and provide a foundation for 

additional applications. The remaining applications (SURF, VSA and ITP) are optional. 

1.3.1.1 Enhanced Visual Acquisition (EVAcq) 

The Enhanced Visual Acquisition (EVAcq), application represents the most basic of ASA 

applications, and use of the CDTI. The CDTI provides traffic information to assist the 

flight crew in visually acquiring traffic out the window. The CDTI can be used to 

initially acquire traffic or as a supplement to other sources of traffic information. This 

application is expected to improve both safety and efficiency by providing the flight crew 

enhanced traffic awareness. Refer to RTCA DO-289 for a complete EVAcq description. 

1.3.1.2 AIRB 

The Basic Airborne Situational Awareness (AIRB), application extends the EVAcq 

application by adding the Flight ID and ground speed of selected traffic that are added to 

the CDTI. The CDTI provides traffic information to assist the flight crew in visually 

acquiring traffic out the window and provides traffic situational awareness beyond visual 

range. The CDTI can be used to initially acquire traffic or as a supplement to other 

sources of traffic information. Refer to RTCA DO-319/EUROCAE ED-164 for a 

complete AIRB description. 

1.3.1.3 Visual Separation on Approach (VSA) 

The Visual Separation on Approach (VSA), application is an extension of the current 

visual approach procedure. The CDTI is used to assist the flight crew in acquiring and 

maintaining visual contact during visual separation on approach. The CDTI is also used 

in conjunction with visual, out-the-window contact to follow the preceding aircraft 

during the approach. The application is expected to improve both the safety and the 

performance of visual separation on approach. It may allow for the continuation of visual 

separation on approach when they otherwise would have to be suspended because of the 

difficulty of visually acquiring and tracking the other preceding aircraft. Refer to RTCA 

DO-314/EUROCAE ED-160 for a complete VSA description. 

1.3.1.4 Basic Surface Situational Awareness (SURF) 

The Basic Surface Situational Awareness (SURF), application is to provide the flight 

crew with own-ship positional and traffic situational awareness information relative to an 

airport map. The CDTI includes an airport surface map underlay, and is used to support 

the flight crew in making decisions about taxiing, takeoff and landing. This application 

is expected to increase efficiency of operations on the airport surface and reduce the 


9

10 

possibility of runway incursions and collisions. Refer to RTCA DO-322/EUROCAE 

ED-165 for a description of the SURF application. 

1.3.1.5 Oceanic In-Trail Procedures (ITP) 

In-Trail Procedures (ITP) in Oceanic Air Space enables aircraft that desire flight level 

changes in procedural airspace to achieve these changes on a more frequent basis, thus 

improving flight efficiency and safety. The ITP achieves this objective by permitting a 

climb-through or descend-through maneuver between properly equipped aircraft, using a 

new distance-based longitudinal separation minimum during the maneuver. The ITP 

requires the flight crew to use information derived on the aircraft to determine if the 

initiation criteria required for an ITP are met. Refer to RTCA DO-312/EUROCAE ED- 

159 for a complete ITP description. 

1.3.2 Emerging Applications 

This document specifies detailed requirements for an initial set of applications. 

1.3.2.1 Airport Surface Situational Awareness with Indications and Alerts (SURF IA) 

Airport Surface Situational Awareness with Indications and Alerts (SURF IA) is a flightdeck 

based application that adds to the Airport Traffic Situation Awareness application 

by graphically highlighting traffic or runways on the airport map to inform flight crew of 

detected conditions which may require their attention. For detected non-normal – alert 

level – situations, which require immediate flight crew awareness, additional attention 

getting cues are provided. Refer to RTCA DO-323 for a more complete description of 

SURF IA. 

1.3.2.2 Traffic Situational Awareness with Alerts (TSAA) 

Traffic Situational Awareness with Alerts (TSAA) will provide traffic advisories in the 

near term by using the CDTI and alerts to assist the pilot or flight crew with visual 

acquisition and avoidance of traffic in both Visual Meteorological Conditions and 

Instrument Meteorological Conditions. The application is applicable under both Visual 

Flight Rules (VFR) and Instrument Flight Rules (IFR). It builds on the Basic Traffic 

Situational Awareness application by providing the pilot or flight crew with alerts for 

conflicting traffic that may or may not have been pointed out by ATC. This alert is for 

detected airborne conflicts. 

1.3.2.3 Flight-Deck Based Interval Management-Spacing (FIM-S) 

Flight-Deck Based Interval Management-Spacing (FIM-S) is a suite of functional 

capabilities that can be combined to produce operational applications to achieve or 

maintain an interval or spacing from a target aircraft. ATC will be provided with a new 

set of (voice or datalink) instructions directing, for example, that the flight crew establish 

and maintain a given time from a reference aircraft. 

1.4 System Scope and Definition of Terms 


The ASA system scope is all of the elements depicted in Figure 1-1. It should be noted 

that the transmit function shown in Figure 1-1 can be implemented in either the airborne 

segment (ADS-B Out) or in a ground segment, as for the TIS-B or ADS-R functions.

The ADS-B system scope is the middle three elements shown in Figure 1-1, including: 

the Transmit subsystem, the broadcast link RF medium, and the Receive & Report 

Generation function. It should be noted that the transmit function shown in Figure 1-1 

can be implemented in the airborne segment (ADS-B Out). 

The list of acronyms and definitions of terms are included in Appendix A. 


11

12 


This Page Intentionally Left Blank.

2 Operational Requirements 

2.1 General Requirements 

ADS-B is designed to support numerous applications. Many of these applications are 

described in this Section and in the Appendices. 

Since the initial publication of this document, many of the ADS-B Out and ADS-B In 

applications have undergone a rigorous development of their operational and 

performance requirements which have been published in other RTCA documents. The 

high level performance requirements for the ADS-B In applications are summarized in 

Table 2-7. The high level performance requirements for the ADS-B Out applications are 

summarized in Table 2-10. 

This section describes the operational performance requirements for the existing 

applications and a candidate set of potential future ADS-B applications. A candidate 

number of scenarios are defined that identify conditions that are driving factors in 

deriving full capability ADS-B system-wide functional and performance requirements. 

This candidate set should not be interpreted as a minimum or maximum for a given 

implementation. Furthermore, all implementations are not required to support all 

applications. 

The following key terms are used within this section. 

� ADS-B Message. An ADS-B Message is a block of data that is formatted and 

transmitted that conveys the information elements used in the development of ADS-B 

reports. Message contents and formats are specific to each of the ADS-B data links; 

these MASPS does not address message definitions and structures. 

� ADS-B Report. An ADS-B report contains the information elements assembled by 

an ADS-B receiver using messages received from a transmitting participant. These 

information elements are available for use by applications external to the ADS-B 

system. 

2.1.1 General Performance 

2.1.1.1 Consistent Quantization of Data 

When the full resolution of available aircraft data cannot be accommodated within an 

ADS-B Message, a common quantization algorithm shall {242AR2.1} be used to ensure 

consistent performance across different implementations. To minimize uncertainty, a 

standard algorithm for rounding/truncation is required for all parameters. For example, if 

one system rounds altitude to the nearest 100 feet and another truncates, then the same 

measured altitude could be reported as different values. 

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

be rounded to the nearest value that can be encoded in that data field. 


13

14 

Notes: 

1. Unless otherwise specified, it is accepted that the data source may have less bits of 

resolution than the data field. 

2. Users of the ADS-B Message formats should perform a comparison between the 

quality metrics applied and the resolution of each message element that those metrics 

are applied against. There are some combinations of message data elements and 

quality metrics that are not compatible. For example, in the 1090 MHz Extended 

Squitter system, the application of a NACV = 4 (Velocity accuracy < 0.3 m/s) 

requirement to the Airborne Velocity Message (Register 0916) Subtypes 1 or 3 

(subsonic), which has a minimum resolution of only 1 knot (~0.5 m/s). Another 

example would be the application of a NACV = 3 (Velocity accuracy < 1 m/s) or 

NACV = 4 requirement to the Airborne Velocity Message Subtypes 2 or 4 

(supersonic), which have a minimum resolution of 4 knots (~2 m/s). 

2.1.1.2 ADS-B Reports Characteristics 

2.1.1.3 Expandability 

The output of ADS-B shall {242AR2.2} be standardized so that it can be translated 

without compromising accuracy. The ADS-B Reports should support surface and 

airborne applications anywhere around the globe and should support chock-to-chock 

operations without the need for pilot adjustments or calibrations. 

Applications envisioned for using the information provided by ADS-B are not fully 

developed. In addition, the potential for future applications to need information from an 

ADS-B system is considered fairly high. Therefore the ADS-B system defined to meet 

the requirements in these MASPS needs to be flexible and expandable. Any broadcast 

technique should have excess capacity to accommodate increases and changes in message 

structure, message length, message type and update rates. 

Note: The update rate is the effective received update rate as measured at the receiving 

end system application (e.g., the automation system interface by ADS ground 

processing), not the transmission rate of the ADS-B system. 

These MASPS identifies different report parameters with different update rates. In some 

cases the resolution of the parameters may be different depending on the intended use. 

Ideally, the system should be designed so that message type, message structures, and 

report update rates can be changed and adapted by system upgrades. 

2.2 System Performance – Standard Operational Conditions 

2.2.1 ADS-B System-Level Performance 


The standard operating conditions for ADS-B are determined by the operational needs of 

the target applications listed in Table 2-5. System performance requirements and needs 

for ADS-B are provided in terms of the operational environments and the information 

needs of applications making use of ADS-B information in those environments.

The following subsections describe representative scenarios used to derive ADS-B 

system-wide functional and performance requirements. 

Application scenarios are grouped according to whether the user is operating an aircraft/ 

vehicle (ADS-B In) or is an Air Traffic Services provider (ADS-B Out). These scenarios 

outline the operational needs in terms of the information required, such as its timeliness, 

integrity, or accuracy. The intent for these is to meet the requirements in a manner which 

is independent of the technology which provides the underlying needs. Information 

timeliness, for example, may be provided either through a higher transmission rate or 

through a transmission environment that has a higher message delivery success rate. 

A high level assessment of operational considerations for each airborne ADS-B In 

application category is summarized in Table 2-5. The top level traffic (“targets”) 

performance requirements for the existing ADS-B In applications compared to the 

minimum performance levels for each category of ADS-B transmit sources (i.e., ADS-B 

[direct air to air], ADS-R and TIS-B) are presented in Table 2-7. The airborne source’s 

performance levels are from the FAA Final ADS-B Out Rule and Advisory Circular 

AC20-165 (Refs TBD). The TIS-B and ADS-R performance levels are from the latest 

version of the SBS Air ICD (Ref TBD). 

A summary of the broadcast information provided by ADS-B and its applicability to the 

target applications is provided in Table 2-6. Assumptions for A/V-to-A/V scenarios are 

summarized in Table 2-8. A summary of ATS provider surveillance and conflict 

management current capabilities for sample scenarios is provided in Table 2-9(a). 

Additional and refined capabilities appropriate for ADS-B are provided in Table 2-9(b). 

Note that earlier versions of the ADS-B MASPS documents used the term “Station- 

Keeping” to describe a category of ADS-B In applications. Those applications are now 

categorized as “Spacing Applications” in this version. Also previous versions used the 

term “Cooperative Separation” to describe an advanced category of ADS-B In 

applications. That category is now designated as “Delegated Separation” applications in 

this document. Similarly, the “Flight Path Deconfliction Planning” function is now 

assumed to be part of the Delegated Separation and Self Separation applications. 

Note: Table entries not containing references supporting the value specified are based 

on operational judgment and may need further validation in future versions of 

these MASPS. 


15

16 


Table 2-5: High Level Considerations for ADS-B In Applications by Category 

1 SA Applications 2 "Enhanced SA" Applications 3 Spacing Apps 4 Delegated Separation Applications 5 Self Separation 

Airborne Approach Surface Oceanic Approach Surface EnRoute / Terminal EnRoute / Terminal EnRoute / Terminal 

Requirement AIRB VSA SURF ITP 

CAVS/ 

CEDS 

SURF IA FIM-S Advanced FIM-DS DS-C/P ICSPA DSWRM FC Self Sep 

Separation Responsibility ATC (1) ATC (1, 2) ATC (1) ATC ATC ATC ATC ATC Shared Shared Shared Shared Aircraft Aircraft 

100% OUT Equipage? 

(Direct, ADS-R or TIS-B) 

No No No No No No No No TBD TBD TBD TBD TBD TBD 

100% IN / CDTI Equipage? No No No No No No No No TBD TBD TBD TBD TBD TBD 

Operational Conditions TBD VMC Only No Reqmt VMC / IMC VMC / IMC No Reqmt VMC / IMC VMC / IMC VMC / IMC VMC / IMC VMC / IMC VMC / IMC VMC / IMC VMC / IMC 

3D / 4D Intent Data? No No No No No No TBD TBD TBD TBD TBD TBD Yes Yes 

Wake Vortex Data? No No No No No No No No No TBD TBD Yes TBD TBD 

Increased Perf Levels? (3) 

(> FAA 2020 Mandate) 

No No Yes No TBD Yes TBD TBD TBD TBD TBD TBD TBD TBD 

Notes: 

1. Only when aircraft is on IFR Flight Plan. 

2. ATC for all aircraft except ATC designated traffic to follow. 

3. Performance level used for comparison is that of FAA Final ADS-B OUT Rule and AC 20-165 (Ref TBD). 

4. Red highlighting means that there may be a problem meeting the minimum performance requirements of the application. 

5. Yellow highlighting means that the requirements are not defined.

Airborne 

Situational 

Awareness 

(AIRB) 

Table 2-6: Required Information Elements to Support Selected ADS-B Applications 

Enhanced 

Situational 

Awareness 

(ITP) 

Spacing 

(FIM-S) 

Delegated 

Separation 

Assurance 

& 

Sequencing 

(FIM-DS) 

Simultaneous 

Approaches 

(DS) 

Airport 

Surface 

(A/V to A/V 

& A/V to 

ATS) 

Self 

Separation 

ATS 

Surveillance 

ADS-B 

OUT 

Traffic 

Situation 

Awareness 

W/Alerts 

(TSAA) 

Notes 

Information Element 

� 

Identification 

Flight ID (Call Sign) � � � � � � � 1 

Address � � � � � � � � � 

Category � � � � � 

Mode A Code 

State Vector 

� 

Horizontal Position � � � � � � � � � 

Vertical Position � � � � � � � � 

Horizontal Velocity � � � � � � � � 

Vertical Velocity � � � � � � � � 

Surface Heading � 

Ground Speed � 

NIC 

Mode Status 

� � � � � � � � 

Emergency/ 

Priority Status 

� � � � 

Capability Codes � � � � � � � � 

Operational Modes � � � � � � � � 

NACP � � � � � � � � � 

NACV � � � � � � � � 

SIL � � � � � � � � 

SDA � � � � � � � � � 

ARV TBD 

Intent Data (Note 1) TBD TBD TBD 

Notes for Table 2-6: 

• = Expected Application Requirement 

1. ADS-B is one potential means to provide intent information to support ATS. Other alternatives, not involving ADS-B, may become available. 


17

18 

Table 2-7: ADS-B Transmit Sources – Minimum Required Performance vs ADS-B In Application Requirements 

1 SA Applications 2 "Enhanced SA" Applications 3 Spacing Applications 4 Delegated Separation Applications 5 Self Separation 

Airborne Approach Surface Oceanic Approach Surface EnRoute / Terminal EnRoute / Terminal EnRoute / Terminal 

AIRB VSA SURF ITP CAVS SURF IA FIM-S FIM-DS ICSPA DS-C/P DSWRM FC Self Sep 

TRANSMIT SOURCES DO-319 DO-314 DO-322 DO-312 CEDS DO-323 DO-328 

A. Airborne Platforms 

Accuracy (NACP) 8 5 6 7 / 9 (5) 5 9 / 10 / 11 6 / 7 9 

Integrity (NIC) 7 N / A 6 N / A 5 N / A 5 / 7 9 

Vel Acc (NACV) 1 1 1 2 1 1 1 3 

Src Integ Lvl (SIL) 3 N / A 1 N / A 2 2 2 2 

Sys Design Assur (SDA) 2 1 1 1 / 2 (3) 2 2 2 TBD 

DO-289 

Apndx J 

Flight ID Yes N / A Required N / A Required N / A Required Required 

B. Ground Segment: ADS-R 

Accuracy (NACP) 9 max 5 6 7 / 9 (5) N / A 9 / 10 / 11 6 / 7 9 

Integrity (NIC) 8 max N / A 6 N / A N / A N / A 5 / 7 9 

Vel Acc (NACV) 1 1 1 2 N / A 1 1 3 

Src Integ Lvl (SIL) 3 N / A 1 N / A N / A 2 2 2 

Sys Design Assur (SDA) 2 1 1 1 / 2 (3) N / A 2 2 TBD 

Flight ID Yes N / A Required N / A N / A N / A Required Required 

C. Ground Segment: TIS-B TIS-B as currently implemented was not intended to support these applications. 

Accuracy (NACP) 5 / 6 / 9 (2) 5 6 7 / 9 (5) N / A 9 / 10 / 11 6 / 7 9 

Integrity (NIC) 0 N / A 6 N / A N / A N / A 5 / 7 9 

Vel Acc (NACV) 0 1 1 2 N / A 1 1 3 

Src Integ Lvl (SIL) 0 N / A 1 N / A N / A 2 2 2 

Sys Design Assur (SDA) 2 (4) 1 1 1 / 2 (3) N / A 2 2 TBD 

Flight ID No N / A Required N / A N / A N / A Required Required 

Legend: Green = Source meets application’s requirements 

Red = Source does not meet application’s requirements 

Yellow = Source does not meet application’s requirements but one or more mitigation methods are available. 

© 20xx, RTCA, Inc.


1. The airborne source’s performance levels (in Group A) are from the FAA Final ADS-B Out Rule and Advisory Circular AC 20-165 (Refs TBD). The 

ADS-R (in Group B) and TIS-B (in Group C) performance levels are from the latest version of the SBS Air ICD SRT Revision 01 (Ref TBD). 

2. TIS-B NACP values for the En Route & Terminal Environments are ≥5. TIS-B NACP values are for airborne (6) & surface (9) targets in the Surface 

Environment. 

3. FAA TSO-C195 states applications' Hazard Level for ownship when airborne or on surface > 80 knots = Major (SDA=2), Hazard Level for ownship 

< 80 knots = Minor (SDA=1). 

4. TIS-B Service does not broadcast a SDA value but the SBS Air ICD defines TIS-B service SDA equivalent to 2. 

5. SURF surface targets require NACP ≥ 9, SURF airborne targets require NACP = 7 or 9 depending on parallel runway spacing. 


19

20 

Information 

� 

Initial Acquisition 

of Required 


Elements (NM) 

Operational 

Traffic Densities 

# A/V 

(within range) 

(Note 3) 

Service 

Availability % 

(Note 4) 


Airborne 

Situational 

Awareness 

EVAcq/ 

AIRB 

Table 2-8: Summary of A/V-to-A/V Performance Assumptions for Support of Indicated Applications 

Enhanced 

Situational 

Awareness 

ITP 

Conflict 

Avoidance 

and 

Collision 

Avoidance 

Integrated 

Collision 

Avoidance 

Terminal 

Spacing 

FIM-S 

10 20 20 

21 

(< 10 NM) 

24 

(< 5 NM); 

80 

(< 10 NM); 

250 

(< 20 NM) 

6 

(< 20 NM) 

Operational Capability 

Separation 

Assurance and Sequencing 

Delegated 

Separation 

FIM-DS 

40 

(50 desired) 

(Note 6 & 8) 

120 

(< 40 NM) 

Delegated 

Separation in 

Oceanic/ Low 

Density 

En route 

90 

(120 desired) 

(Note 6) 

30 

(< 90 NM) 

Simultaneous 

Approach 

Delegated 

Separation 

CSPA, ICSPA 

Airport Surface 

Situational 

Awareness 

(Note 4) 

10 5 

32 landing; 

3 outside 

extended 

runway; 

5 beyond runway 

25 within 500 ft 

150 within 5 NM 

95 99.9 99.9 99.9 99.9 99.9 99.9


1. System must support all traffic in line of sight that have operational significance for 

the associated applications (i.e., within operationally relevant ranges and altitudes 

for these applications). The numbers in the table indicate the number of aircraft 

expected to participate in or affect a given operation. (Refer to Table TBD for 

requirements which are based on operational traffic densities derived from the Los 

Angeles basin model). 

2. Service availability includes any other systems providing additional sources of 

surveillance information. 

3. Initial acquisition of intent information is also required at this range. 

4. This includes inappropriate runway occupancy at non-towered airports. 

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

2.2.1.1 ADS-B System-Level Performance—Aircraft Needs 

The following scenarios focus on aircraft systems and applications that use surveillance 

information pertaining to other aircraft within operationally relevant geometries and 

ranges. These scenarios assume that participating aircraft are CDTI equipped, with 

appropriate features, to assist in these operations. However, this does not imply that 

CDTI is required for these applications. Detailed traffic display requirements are 

provided in the appropriate application MOPS. Air-to-air capabilities enabled by ADS-B 

equipage classes are depicted in Figure 2-3. The applications are identified 

[Abbreviation] by the terminology used in the AIWP Version 2 document (Ref TBD). 

Note: For aircraft (targets) that will support higher integrity categories of ADS-B In 

applications such as spacing or delegated separation, a capability to 

independently validate the ADS-B surveillance information is likely to be 

required [6]. Alternative validation means are under study. An example of this 

independent validation would be the possible use of TCAS ranging data to 

validate the received Version 0 and 1 ADS-B Position Messages. This has been 

required by the FAA for the In Trail Procedure (ITP) in the FAA ITP Policy 

Memo, Ref TBD. Application developers should note the useful range of TCAS 

for this function is well below the effective range of the higher ADS-B classes 

such as A3. 

2.2.1.1.1 Aircraft Needs While Performing Airborne Situational Awareness [AIRB] 

Transmission, air-to-air reception, and cockpit display of ADS-B information enables the 

Airborne Situational Awareness CDTI application (AIRB). This scenario is applicable in 

all airspace domains when ownship is airborne. See Table 2-6 for the information 

exchange needs and Table 2-8 for operational performance requirements to support the 

aid to visual acquisition. 

2.2.1.1.2 Aircraft Needs for Approach Applications – Enhanced Visual Approach [VSA] 

The enhanced visual approach (VSA) application is an extension of the current visual 

approach procedure. In this application, the CDTI is used by the flight crew to detect and 


21

22 

track the preceding aircraft. The CDTI may also be used to monitor traffic on a parallel 

approach. This application is expected to improve the safety as well as the routine 

performance of visual approaches. See Table 2-6 for the information exchange needs and 

Table 2-8 for operational performance requirements to support the enhanced visual 

approach applications. 

2.2.1.1.3 Aircraft Needs for Enhanced Situational Awareness Applications [CAVS, CEDS, 

ITP] 


Enhanced Situational Awareness application versions (CAVS or CEDS) have been 

developed to reduce the minimum weather conditions during which “visual” approaches 

can be maintained after the initial visual acquisition of the target or lead aircraft has been 

established. 

The enhanced category of SA applications also includes the In Trail Procedures (ITP) 

application which provides flight crews with improved opportunities to attain their 

optimal flight profile on long range flights over oceanic airspace. The application allows 

ITP equipped aircraft a reduced separation standard during the ITP climb or descent as 

compared to un-equipped aircraft. Thus they can achieve a higher percentage of 

successful (accepted) requests from ATC for climbs or descents to their optimal flight 

level during each phase of the flight. 

Environment 

This application is utilized in oceanic airspace in either an organized track system such as 

PACOTS (Pacific Organized Track System) or in User Preferred Routes (UPR) airspace. 

Aircraft in procedural airspace frequently fly in close proximity to other aircraft traveling 

along the Same Track but separated vertically. These similar ground paths may be 

published routes (or tracks) with identical ground paths for each aircraft, or user preferred 

routes with similar ground paths over a portion of the flight. Safe separation is 

maintained procedurally. 

Frequently, operational efficiency or safety could be enhanced by climbing or 

descending, but the current procedural separation minima preclude the aircraft’s climbing 

or descending through the adjacent Flight Level. In this situation, the aircraft desiring the 

Flight Level change would be blocked from making the climb or descent to the desired 

level by aircraft at an Intermediate Flight Level. 

Operational and safety benefits could be achieved by enabling more Flight Level changes 

in these blocked situations. With a new procedure and appropriate equipment, aircraft 

may be allowed to change Flight Levels more frequently. Automatic Dependent 

Surveillance-Broadcast (ADS-B) data and onboard equipment can enable Flight Level 

changes in procedural airspace using procedures similar to other standard, distance based 

procedures. Distance-based longitudinal separation minima for climbs and descents have 

been established in procedural airspace, using information supplied by the crew to the 

controller for the determination of along-track distance. 

The objective of the In-Trail Procedure is to enable aircraft that desire Flight Level 


improving flight efficiency and safety. When ITP Criteria are met, the ITP achieves this 

objective by permitting a climb-through or descend-through maneuver past a Potentially 

Blocking Aircraft, using a new longitudinal separation minimum during the ITP, where

this new distance-based longitudinal separation minimum is less than current longitudinal 

separation minima. 

The In-Trail Procedure (ITP) makes climbs and descents through normally blocked Flight 

Levels possible, providing a safe and practical method for Air Traffic Service Providers 

to approve, and flight crews to conduct, such operations. The ITP would require the 

flight crew to use information derived on the aircraft to determine if the criteria required 

for making an ITP request and subsequently beginning the procedure are met. The 

aircraft-derived information includes Aircraft ID, Flight Level, Same Direction, ITP 

Distance, and Ground Speed Differential (all relative to Potentially Blocking Aircraft). 

The ITP Speed/Distance Criteria are designed such that the estimated positions between 

the ITP Aircraft and Reference Aircraft should get no closer than the ITP Separation 

Minimum during the portion of the climb or descent where vertical separation does not 

exist. ATC would verify that the ITP and Reference Aircraft were Same Track and that 

the maximum Positive Mach Differential was not exceeded. Once these criteria are met, 

and the controller determines that standard separation minima will be met with all Other 

Aircraft, the Flight Level change request may be granted. The ITP is comprised of a set 

of six different Flight Level change geometries with the specific geometry dictated by 

whether the ITP Aircraft desires to climb or descend and its proximate relationship with 

Potentially Blocking Aircraft. 

The ITP is an Airborne Traffic Situational Awareness (ATSAW) application. It does not 

change the responsibilities of either pilots or controllers; the flight crew continues to be 

responsible for the operation of the aircraft and conformance to its clearance, and the 

controller continues to be responsible for separation and the issuance of clearances. The 

ITP does include new tasks for the flight crew in determining that the ITP Criteria are 

met. The ITP does not require the crew to monitor or maintain spacing to any aircraft 

during the ITP maneuver. The safety of the ITP is attained by the initial conditions 

which include the ITP Distance, Ground Speed Differential, vertical speed, and the 

vertical distance for the Flight Level change. Once it is begun, safety is assured by the 

crew’s compliance with the Flight Level change clearance. 

Operational Scenario 

Traffic levels in procedural (e.g., oceanic) airspace are increasing. In an organized track 

system, some Flight Levels on a track may be loaded upon track entry with longitudinal 

separations at or near the separation minimum, while other Flight Levels have gaps 

between traffic that far exceed this minimum separation. Even in airspace with user 

preferred routes (UPRs), traffic situations exist where the longitudinal spacing between 

the only two aircraft in the immediate vicinity is less than the applicable procedural 

separation minimum. 

An aircraft originally cleared to its initial optimum cruising Flight Level will burn 

sufficient fuel after several hours to justify climbing 2,000 feet or more to a new optimum 

cruising Flight Level. More favorable winds at higher Flight Levels may also create a 

desire for climbs of 2,000 to 4,000 feet. Flight crews may also desire lower Flight 

Levels, perhaps to avoid turbulence or when winds are more favorable at the lower Flight 

Levels. 

Often, when an aircraft desires a Flight Level change, this change may be blocked by 

another aircraft. The ITP is designed to address situations where this blocking aircraft is 

at a same-direction Flight Level (from 1,000 to 3,000 feet higher or lower) and is also 

less than the current longitudinal separation minimum ahead of or behind the aircraft 

desiring to make the Flight Level change. In this situation, the controller would be 


23

24 

required to deny a Flight Level change request because the separation minima would not 

be met once vertical separation was lost. 

Flight Level changes can significantly improve flight efficiency by reducing fuel use. 

This is because there is no single Flight Level that provides an optimum cruising Flight 

Level over the substantial period of time that aircraft spend in procedural airspace. As 

the optimum, no-wind Flight Level increases throughout the flight (as fuel is burned and 

aircraft weight is reduced); the aircraft would need to climb to maintain optimum cruise 

efficiency. Additionally, higher or lower Flight Levels may be more efficient because of 

more favorable winds. 

In addition to efficiency improvements, Flight Level changes can increase safety when 

turbulent conditions exist at the current Flight Level. A Flight Level change for this 

reason would reduce the risk of injury to passengers or cabin crew, and increase 

passenger comfort. 

See Table 2-6 for the information exchange needs and Table 2-8 for operational 

performance requirements to support the enhanced situational awareness applications 

such as ITP. 

2.2.1.1.4 Aircraft Needs for Future Collision Avoidance [ADS-B Integrated Collision 

Avoidance] 


A future collision avoidance system based on ADS-B could contain enhancements 

beyond the present TCAS capability; for example: 

� A surveillance element that processes ADS-B data, 

� A collision avoidance logic that makes use of the improved surveillance 

information in detecting and resolving collision threats, 

� A cockpit display of traffic information (CDTI) that may include predictive 

traffic position, enhanced collision alerts, and related information, 

� A means of presenting Resolution Advisory (RA) maneuver guidance to the 

flight crew, possibly in the horizontal dimension as well as vertical. 

TCAS II systems requirements have been updated to incorporate a hybrid surveillance 

scheme (combining active TCAS interrogation and passive reception of ADS-B broadcast 

data) to further reduce interference with ground ATS in the Hybrid Surveillance 

application, RTCA DO-300 (Ref TBD). Future enhancements may use ADS-B data in 

horizontal miss-distance filtering to further reduce the number of unnecessary RAs. 

Other modifications may include the use of ADS-B information in aircraft trajectory 

modeling and prediction or for lateral RA guidance. 

These early applications of ADS-B in enhanced TCAS systems, beyond improving the 

performance of those systems, will also serve to validate the use of ADS-B through years 

of flight experience. The use of ADS-B to either supplement TCAS/ACAS or drive an 

independent CAS needs to be studied and simulated, addressing such issues as: 

� Interoperability with existing collision avoidance systems,

� Mechanisms for aircraft-aircraft maneuver coordination, 

� Optimization of threat detection thresholds, 

� Surveillance reliability, availability and integrity, 

� Need for intruder aircraft capability and status information, 

� Handling special collision avoidance circumstances such as RA sense reversals, 

� Data correlation and display merge issues, etc. 

Further studies and test validation will need to be conducted to ensure compatibility of 

ADS-B with existing systems. Investigations will also be conducted to assess the need 

for a separate crosslink channel to handle information requests (such as for tracked 

altitude and rate, maneuver coordination, intruder capability, etc.). 

Ultimately, assuming full ADS-B equipage and successful validation, collision avoidance 

based on active interrogation of transponders could be phased out in favor of ADS-B. 

The broadcast positions and velocities from the surrounding aircraft and the predicted 

intersection of their paths with own aircraft will be used to identify potential conflicts. 

Horizontal trajectory prediction based on the ADS-B data could reduce the number of 

unnecessary alerts, and will result in more accurate conflict prediction and resolution. 


performance requirements to support collision avoidance. 

Because a threat of collision could arise from a failure in ADS-B, future collision 

avoidance applications may need a method to validate, independently, any ADS-B data 

they use. It might become possible to eliminate the need for independent validation if it 

is demonstrated that ADS-B can provide sufficient reliability, availability, and integrity 

to reduce, to an acceptable level, the risk that collision avoidance based on ADS-B would 

fail when the risk of collision arises from a failure of ADS-B. 

Environment 

The transitional environment will consist of mixed aircraft populations in any 

combination of the following equipage types: 

� Users of ADS-B that are transponder equipped. 

� Enhanced TCAS, that can broadcast and process ADS-B messages to improve 

TCAS/ACAS surveillance functions. 

� Legacy TCAS II, including Mode S transponders. 

� Sources and users of ADS-B that are not equipped with transponders. 

� Aircraft equipped with transponders, but not with ADS-B. 


The scenario used for analysis of the collision avoidance capability of ADS-B consists of 

two co-altitude aircraft initially in a parallel configuration with approximately 1.5 NM 


25

26 

horizontal separation and velocities of 150 knots each. One of the aircraft performs a 180 

degree turn at a turn rate of 3 degrees per second which results in a head on collision if no 

evasive action is taken. The false alarm scenario used for analysis consists of two aircraft 

in a head-on configuration both with speeds of 150 knots. 

2.2.1.1.5 Aircraft Needs While Performing Spacing Applications [FIM-S] 


A combination of FMS and ADS-B IN / CDTI technology will enable pilots to assist in 

maintenance of aircraft spacing appropriate for a segment of an arrival and approach. At 

busy airports today aircraft are often sequenced at altitude to intervals of 10 to 12 miles. 

If looked at in terms of time over a point, the aircraft are roughly 80 seconds apart. Other 

than the cleared arrival flight path, pilots do not know the overall strategy or which 

aircraft are involved. Controllers begin speed adjustments and off arrival vectoring to 

assist in maintaining this interval and in achieving mergers of traffic. As the aircraft 

arrive at the runway, the spacing has in some cases been reduced to 2.5 miles or 55 

seconds at approach speed. The speed adjustments and vectoring are an inefficiency that 

is accepted in the name of safety. 

With ADS-B IN spacing applications, the pilot can assist the controller’s efforts to keep 

the spacing appropriate for the phase of flight. This is not to say that the pilot assumes 

separation responsibility, but rather assists the controller in managing spacing, while 

flying a prescribed arrival procedure. The arrival procedures could be built so that with 

the normally prevalent winds, aircraft could be fed into the arrival slot with a time 

interval that would hold fairly constant through a series of speed adjustments. The 

speeds, allowable speed tolerance and desired spacing would all be defined by the 

procedure or specified by the controller based on ground automation systems. 

Procedures need to be developed to accommodate merges; this could be done on the 

aircraft by the use of Required Time of Arrival, or on the ground using the ATC 

automation ground systems. The benefits would not only be in fuel savings but in 

reduced ATS communications requirements and increased capacity as standard operating 

procedures would govern more of the arrival operations. 


performance requirements to support a terminal spacing application. 

Environment 

Spacing may occur in all operational domains. The subsequent scenario will focus on a 

terminal spacing application. 


Terminal spacing will start at approach control and end at landing. Two aircraft are in a 

high volume terminal environment with mixed equipage. Both aircraft are under positive 

control by the terminal area controller, who issues an instruction to the in-trail aircraft to 

maintain a fixed separation (distance or time) behind the lead aircraft. The in-trail 

aircraft has an ADS-B IN CDTI to display all of the aircraft involved in the maneuver. 

ADS-B IN spacing applications in the terminal domain can assist flight crews in the final 

approach. An opportunity for spacing occurs with aircraft cleared to fly an FMS 4D 

profile to the final approach fix. Another aircraft can perform ADS-B IN spacing to 

follow the lead aircraft using a CDTI that provides needed cues and situational data on

the lead and other proximate aircraft. In this scenario, spacing allows a lesser equipped 

aircraft to fly the same approach as the FMS-equipped aircraft. The in-trail aircraft will 

maintain minimum separation standards, including wake vortex limits, with respect to the 

lead aircraft. 

Specific scenarios include, but are not limited to: 

1. Common route on arrival (where an aircraft is merged between two other aircraft in 

an arrival stream) 

2. IM turn prior to merge (where path stretching or shortening is used to adjust spacing 

when speed changes alone would not be sufficient), 

3. Arrivals supporting Optimized Profile Descents (OPD) 

4. Crossing runways 

5. Departure spacing 

6. Dependent runway spacing 

2.2.1.1.6 Aircraft Needs for Delegated Separation Assurance and Sequencing [FIM-DS, FIM- 

DSWRM] 

Delegated separation applications are an operational concept in which the participating 

aircraft have the freedom to select their path and speed in real time. Research is in 

progress to fully develop operational concepts and requirements for delegated-separation. 

Delegated separation applications use the concept of “alert” and “protected” airspace 

surrounding each aircraft. In this concept, both general aviation and air carriers would 

benefit. Aircraft operations can thus proceed with due regard to other aircraft, while the 

air traffic management system would monitor the flight’s progress to ensure safe 

separation. 

Delegated separation applications include a transfer of responsibility for separation 

assurance from ground based ATC to aircraft pairs involved in close proximity 

encounters. The delegation of responsibility may not be for all dimensions i.e., ATC may 

only delegate a responsibility for cross track separation from a particular aircraft to the 

flight crew. In this scenario ATC would retain the responsibility for longitudinal (alongtrack) 

separation and altitude separation from all other aircraft. Per Table 2-5, 

participating aircraft will be specially equipped with high accuracy and high integrity 

navigation capabilities and high reliability ADS-B capability for these increased 

criticality flight operations. The airborne separation assurance function includes 

separation monitoring, conflict prediction, and providing guidance for resolution of 

predicted conflicts. 


performance requirements to support aircraft needs while performing delegated 

separation applications. 

Note that to support delegated-separation, aircraft must be able to acquire both state 

vector and intent information for an approaching aircraft at the required operational 

range. 


27

28 

Environment 

Each delegated separation applications aircraft supports electronically enhanced visual 

separation using a cockpit display of traffic information. All delegated separation 

applications aircraft perform conflict management and separation assurance. The pilot 

has available aircraft position, velocity vector information, and may have tactical intent 

information concerning proximate aircraft. Instead of negotiating maneuvers, the pilot 

uses “rules of the air” standards for maneuvers to resolve potential conflicts, or automatic 

functions that provide proposed resolutions to potential conflicts. There is a minimal 

level of interaction between potentially conflicting aircraft. Each aircraft in delegated 

separation applications airspace broadcasts the ADS-B state vector; higher capability 

aircraft equipped with flight management systems may also provide intent information 

such as current flight path intended and next path intended. 

Only relevant aircraft will be displayed on the CDTI although hundreds of aircraft may 

be within the selected CDTI range, but well outside altitudes of interest for conflict 

management. Once both aircraft have been cleared for delegated-separation, the ATS 

provider will monitor the encounter but is not required to intervene. 


Delegated separation applications are applicable in all operational domains, including, for 

example, en route aircraft overflying high density terminal airspace containing both 

airborne and airport surface traffic. The worst case conflict is two high speed commercial 

aircraft converging from opposite directions. Each aircraft has a maximum speed of 600 

knots, resulting in a closure speed of 1200 knots (note that at coastal boundaries and in 

oceanic airspace, the potential exist for supersonic closure speeds of 2000 knots). A 

minimum advance conflict notice of two minutes is required to allow sufficient time to 

resolve the conflict 

Messages to indicate intended trajectory are used to reduce alerts and improve resolution 

advisories. These intent messages include information such as: a) target altitude for 

aircraft involved in vertical transitions; and b) planned changes in the horizontal path. 

The specific scenario used for evaluation of the delegated separation applications conflict 

detection requirements consists of two aircraft traveling with a speed of 300 knots each. 

The aircraft are initially at right angles to each other. One of the aircraft executes a 90 

degree turn with a 30 degree bank angle. The geometry is such that a collision would 

occur if no evasive action were taken. A conflict alert should be issued with a 2 minute 

warning time. 

The false alarm delegated separation applications scenario assumes a separation standard 

of 2 NM. Two aircraft approach each other in a head-on configuration. Each aircraft 

travels at a speed of 550 knots. The final horizontal miss distance of the two aircraft is 

13,500 feet, slightly greater than the assumed separation standard. It is desired to keep 

false alarm rates low. 

2.2.1.1.7 Aircraft Needs for Delegated Separation in Oceanic / Low Density En Route 

Airspace [ICSR, DS-C, DS-P] 


This scenario addresses ADS-B requirements for aircraft performing delegated-separation 

while operating in oceanic or low density en route airspace. In such an operational

environment there is a need to support cockpit display of traffic information and conflict 

detection at relatively longer ranges than for operations in higher density airspace. 


performance requirements to support aircraft needs while performing delegated 

separation in low density en route airspace. 

Environment 

Participating aircraft are in oceanic or low density en route airspace performing delegated 

separation. Each participating aircraft supports an extended range cockpit display of 

traffic information. The pilots have available state vector, identification, and intent 

information concerning proximate aircraft. (Some near-term operational environments 

may allow delegated-separation without provision of full intent information, but require 

at least a 90 mile range in the forward direction). 

Operational Scenarios 

For these scenarios, all aircraft within the 90 mile range are ADS-B equipped and have 

CDTI. The pilot can elect to display all aircraft or relevant aircraft. Once participating 

aircraft are cleared for delegated-separation, the ATS provider will monitor the encounter 

but is not required to intervene. Scenarios include in-trail climb and descent, spacing, 

passing, and separation assurance. 

2.2.1.1.8 Aircraft Needs While Performing Delegated Separation Simultaneous Approaches 

[PCSPA, ICSPA] 

Operational improvements through the use of ADS-B for closely spaced runway 

operations are categorized as delegated separation applications. ADS-B supported 

applications will enable increased capacity at airports currently without PRM support. 

ADS-B permits faster detection times for the blunder, resulting in the ability to operate 

with lower separations between runways for simultaneous approaches. By providing 

information in the cockpit, the pilot can detect and react to a blunder without incurring 

delays associated with the controller-to-pilot communication link. Currently, allowances 

are made for such communication problems as blocked transmissions and non-receipt of 

controller maneuver instructions. These allowances are needed to achieve desired levels 

of safety but they result in greater separation between runways than would be required if 

pilots received the critical information more quickly. Note that the example ICSPA 

application described in Appendix J of RTCA DO-289 (Ref TBD) has ATC delegating 

responsibility for cross track separation to the airborne segment while retaining 

separation responsibility for along track and altitude separation. The high level 

requirements for this example ICSPA application are provided in Table 2-7. 


performance requirements to support aircraft needs while performing simultaneous 

independent approaches. 

Environment 

The environment includes aircraft on final approach to parallel runways as well as 

aircraft in the runway threshold area. ADS-B will be used to assure safe separation of 

adjacent aircraft. 


29

30 


The scenario used for evaluation of closely spaced parallel runway approaches was a 30 

degree blunder. 

� Case 1: Runway centerline separation is 1000 feet. 

� Case 2: Runway centerline separation is 2500 feet. 

� Evader aircraft speed is 140 knots; intruder aircraft speed is 170 knots. 

� The intruder aircraft turns 30 degrees, at 3 degrees per second, with a resulting 

near mid-air collision. 

� A false alarm scenario consists of the two runway spacings with normal 

approaches and landings. 

� Plant noise (normal aircraft dynamics in flight) is added to the aircraft trajectories 

to simulate total system error in the approach. 

2.2.1.1.9 Aircraft Needs for Airport Surface Situational Awareness and Surface Alerting 

[SURF, SURF IA] 


On the airport surface, ADS-B may be used in conjunction with a CDTI to improve 

safety and efficiency. The pilot could use CDTI and a moving map display for basic 

surface situational awareness. Advanced surface applications could support traffic 

alerting, low visibility taxi guidance and surface spacing. ADS-B used in conjunction 

with a moving map display may be used to show cleared taxi travel paths. Other 

proximate vehicles within the surface movement area and aircraft may also be identified 

using ADS-B information. At night, or at times of poor visibility, the airport surface 

digital map may be used for separation and navigation purposes. To support spacing on 

the airport surface, the in-trail aircraft needs to monitor the position and speed of the lead 

aircraft and to detect changes of speed to ensure that safe separation is maintained. 

An additional operational need is for detection and alerting of unauthorized aircraft 

intrusion into the runway and taxiway protected area. Runway incursion detection and 

alerting while operating on the airport surface is different from airborne conflict 

detection. Because of the geometry and dynamics involved, extended projection of 

aircraft position based on current state vector is not feasible for runway incursion 

detection; however, projections on the order of 5 seconds may be feasible. 


performance requirements to support aircraft needs while operating on the airport surface. 

Environment 

The environment includes aircraft and vehicles moving on the airport surface (i.e., 

runways and taxiways), as well as approaching and departing aircraft. ADS-B will be 

used to monitor this operational environment.


Blind Taxi: 

The aircraft are taxiing in conditions of impaired visibility (down to 100 meters RVR). 

One aircraft is following another, with both maintaining 30 knots. The desired spacing 

between the aircraft while moving is 150 meters (nose to tail). The lead aircraft 

decelerates at 1.0 m/sec 2 until it stops. The pilot in the following aircraft is alerted to the 

lead aircraft’s deceleration. Pilot reaction time is 0.75 seconds. The in-trail aircraft 

deceleration is 1.0 m/sec 2 to a stop. The required minimum separation is 50 meters under 

such conditions (nose to tail). 

Runway Incursion: 

An aircraft is on final approach while another aircraft is stopped at the hold short line, 

approximately 50 m from the runway edge. The stopped aircraft begins to accelerate at 

1.0 m/ sec 2 and intrudes onto the runway. An alert should be generated approximately 5 

seconds before the aircraft intrudes onto the runway. 

2.2.1.1.10 Aircraft Needs for Self Separation – [Flow Corridors and Self Separation 

Applications] 

The long term roadmap for ADS-B In surveillance applications is the concept of self 

separation where the flight crew assumes the primary responsibility for separation 

assurance for a defined segment of the flight and ATC assumes a secondary monitoring 

function. As part of their responsibility, the flight crew is granted authority to modify 

their trajectory within defined degrees of freedom without renegotiating with ATC. The 

self-separation portion of the flight generally terminates with an agreed time of arrival at 

the point where separation responsibility is transferred back to the ATC. The application 

can be implemented in either a homogeneous environment, in which all aircraft are selfseparating, 

or in a mixed-operations environment, in which some aircraft are receiving a 

separation service from the ATC. In mixed operations, ATC is not responsible for 

separating any aircraft where any of the relevant aircraft includes a self-separating 

aircraft. 

Per Table 2-5, this concept could require increased performance requirements that would 

support this category of higher integrity airborne functions. It could also potentially 

require the broadcast of new classes of data such as intent data and/or wake vortex 

parameters that are not currently required for existing categories of ADS-B In 

applications. 

2.2.1.2 ADS-B System-Level Performance – ATS Provider Needs for Separation and 

Conflict Management 

The following discussion focuses on ground ATS surveillance and automation systems 

that use ADS-B surveillance information pertaining to aircraft within the area of 

operational control (ADS-B Out). A summary of the current ATS surveillance system 

capabilities is provided in Table 2-9(a). While the individual parameter values in the 

table may not be directly applicable to the ADS-B system, the ADS-B System is expected 

to support equivalent or better overall system level performance for the cited 

applications. ADS-B Out requirements, developed for the regional mandates, are 


31

32 

expected to satisfy the required surveillance performance for the ADS-B In air-to-air 

applications. 

For aircraft required to support ATS surveillance in en route and terminal airspace, a 

capability to independently validate the ADS-B surveillance information is likely to be 

required [6]. Alternative validation means are under study. An example of this 

independent validation would be in areas of radar coverage the use of radar ranging and 

azimuth data to validate the received ADS-B position messages. 

The current en route and terminal surveillance environments consist of primary radars 

and SSRs providing high altitude and terminal airspace coverage. While air carrier 

operations generally stay within en route and terminal radar coverage, commuter, 

corporate, and general aviation operators frequently conduct operations that extend 

outside radar coverage. Existing radar technology provides surveillance performance and 

capabilities that fully support the current ATS operational concepts, but the benefits in 

some low traffic areas do not justify the cost of a full radar system. Improved 

surveillance capabilities, based on ADS-B, will provide in a cost effective manner, the 

extended coverage necessary to support advanced ATS capabilities. ADS-B broadcasts 

will be received, processed, fused with other traffic management information, and 

provided to the system having ATS jurisdiction for that airspace. 


� 

Initial Acquisition of 

A/V Call Sign and 

A/V Category 

Altitude 

Resolution (ft) 

(Note 5) 

Horizontal Position 

Error 

Received Update 

Period 

(Note 2) 

Update Success 

Rate 

Operational Domain 

Radius 

(NM) 

Operational Traffic 

Densities (# A/V) 

(Note 3) 

Service 

Availability (%) 

(Note 4) 


Table 2-9(a): Summary of Expected ATS Provider Surveillance and Conflict 

Management Current Capabilities for Sample Scenarios 


En Route Terminal 

Airport 

Surface 

within 

24 sec. 

within 

10 sec. 

within 

10 sec. 

Parallel Runway 

Conform Mon. 

25 25 25 25 

388 m @ 200 NM 

116 m @ 60 NM 

35 m @ 18 NM 

116 m @ 60 NM 

35 m @ 18 NM 

3 m. rms, 

9 m. bias 

[15],[6], [11] 

n/a 

9 m. 

12 sec. [10] 5 sec. [6] 1 sec. 1 sec. 

98% 98% 98% [6] 98% 

200 60 5 

1250 [6] 750 [6] 

99.999 [10] 

99.9 (low alt) 

99.999 [10] 

99.9 (low alt) 

100 in motion; 

150 fixed 

The lesser of 30 

NM, or the point 

where the aircraft 

intercepts the final 

approach course 

50 dual; 

75 triple; 

w/o filter: 150 

99.999 [10] 99.9

Table 2-9(b): Additional Expected Capabilities Appropriate for ADS-B Supported 

Sample Scenarios 


� 

Altitude Rate 

Error (1�) 

Horizontal Velocity 

Error (1�) 

Geometric 

Altitude 


En Route Terminal 

Airport 

Surface 

33 

Parallel Runway 

Conform Mon. 

1 fps 1 fps 1 fps 1 fps 

5 m/s 0.6 m/s 0.3 m/s 0.3 m/s 

Yes Yes Yes Yes 

Notes for Table 2-9(a) and Table 2-9(b): 

n/a (not applicable) = the requirement is not stressful and would not be higher than any 

other requirement, i.e., does not drive the design. 

1) References are provided where applicable. Else, best judgment was used to obtain 

performance data. 

2) Received update period is the period between received state vector updates. A/V Call 

Sign and A/V Category can be received at a lower rate. 

3) One or multiple ground receivers may be used in the operational domain to ensure 

acceptable performance for the intended traffic load. The numbers in the table 

indicate the number of aircraft expected to participate in or affect a given operation. 

(Refer to Table 2-8 for requirements which are based on operational traffic densities 

derived from the Los Angeles basin model). 

4) Service availability includes any other systems providing additional sources of 

surveillance information. 

5) Altitude accuracy: Some aircraft currently have only 100 foot resolution capability. 

As ADS-B is introduced, it is important for ATS to retain the flexibility to continue to 

use the existing surveillance systems based on SSR transponders. Therefore, it can be 

expected that in radar controlled environments, equipping with ADS-B will not initially 

eliminate the current requirement to carry SSR transponders. It may be possible in some 

cases for an aircraft to equip with ADS-B without adding a transponder. Many 

automation systems rely on SSR Mode A codes to identify aircraft. Use of ADS-B 

reports by the ground surveillance systems may require correlation with an ATS assigned 

SSR Mode A code for some applications. 

Currently ground-based surveillance systems are mostly independent of aircraft 

navigation systems and surveillance data is largely verified through ground surveillance 

monitoring systems. Initially, some level of navigation independence and verification 

will continue to be required for ATS surveillance applications in certain airspace. The 

surveillance capabilities in Table 2-9(a) are acceptable because they are part of the 

current airspace management system, which has this level of independence. A detailed 

failure modes and effects analysis should be performed before a surveillance system that 

is less independent of aircraft navigation systems is approved for operational use. 

Note: Surveillance of air traffic plays a significant role in aviation security. For 

security reasons, ATS surveillance requirements in certain airspace may include 

a need for independent sources of surveillance information. 

© 20xx, RTCA, Inc.

34 

2.2.1.2.1 ATS Provider Needs for Separation and Conflict Management in En Route and 

Terminal Airspace 


Current requirements in the En Route and Terminal airspace are deemed to be much less 

stressful than the other applications in Section TBD. This airspace may be further 

divided into the use of ADS-B Out in Non Radar Airspace (NRA) and ADS-B Out in 

Radar Airspace (RAD). Characteristics of surveillance systems currently in use in the 

NAS for En Route and Terminal are listed in Table 2-9(a). These characteristics are 

provided for information and comparison only. ADS-B will support equal or better 

surveillance application performance (e.g., see Table 2-9(b)). Traffic densities and 

operational domain radius can be used for expected loading on the ADS-B data link 

broadcast medium. 

The high level performance requirements for the existing ADS-B Out NRA, RAD and 

APT applications are contained in Table 2-10. 

The existing degree of independence between navigation and surveillance will be needed 

in the future until combined system performance standards are developed [6].

Scenario � 

NRA – 5 NM 

EnRoute 

Table 2-10: ADS-B Out Applications to Support ATC Surveillance - Minimum Performance Requirements 

NRA – 3 NM 

EnRoute / 

Terminal 

RAD – 5 NM 

Enroute 

RAD – 3 NM 

Terminal 

RAD–2.5 NM 

Approach 

RAD-2.0 NM 

Approach 

RAD 

Independent 

Parrallel 

Approach 

SPR Doc � DO-303 DO-303 DO-318 DO-318 DO-318 DO-318 DO-318 DO-321 

NACP 5 6 7 8 8 8 8 

NACV N / A N / A N / A N / A N / A N / A N / A 

Vertical 

Accuracy, 

95% 

38.1m / 

125 ft 

38.1m / 

125 ft 

38.1m / 

125 ft 

38.1m / 

125 ft 

38.1m / 

125 ft 

38.1m / 

125 ft 

SIL 2 2 3 3 3 3 3 

38.1m / 

125 ft 

NIC 4 5 5 6 7 7 7 0 

SDA 2 2 2 2 2 2 2 > 1 

Note: Refer to the FAA Final ADS-B OUT Rule. 


APT 

6 for V0 




35

36 

2.2.1.2.2 ATS Provider Needs for Separation and Conflict Management on the Airport 

Surface 


On the airport surface, ADS-B will provide improved surveillance within the surface 

movement area. The system will display both surface vehicles and aircraft within the 

surface movement area to provide a comprehensive view of the airport traffic. 

Surveillance information will be provided to all control authorities within the airport, 

coverage will be provided for moving and static aircraft and vehicles, and positive 

identification will be provided for all authorized movements. 

ATS will utilize ADS-B information to provide services consistent with a move toward 

Delegated separation applications. In this environment, a majority of aircraft will need to 

be equipped with ADS-B in order to provide significant benefit to the user or ATS 

service providers. 

In the early stages of implementation, functions supported by ADS-B can be integrated 

with the controller’s automation tools to provide several benefits including: 

1) Reduction in taxi delays, based on improved controller situational awareness, 

2) Operation in zero-visibility conditions for equipped aircraft and airport surface 

vehicles, and 

3) Improved controller ability to predict and intervene in potential incursions, along 

with a reduction in false alarms. 

In the long term, ADS-B would become the principal surveillance system to support 

surveillance of the airport surface movement area. For air traffic management, 

controllers, and air carriers, the greatest additional benefits would result in reducing taxi 

delays and coordinating with arriving and departing traffic. These long-term benefits are 

based on the use of cockpit automation and exchange of data between the cockpit and 

airport automation systems. This includes moving map displays, data linking of taxi 

routes, etc. 

The airport traffic management system continuously monitors each aircraft’s current and 

projected positions with respect to all possible conflicts. Detectable conflicts should 

include: 

� Potential collision with a moving/active aircraft or vehicle, 

� Potential collision with a known, static obstacle, aircraft, or vehicle, 

� Potential incursion into a restricted area (weight/wingspan limited areas, closed 

areas, construction areas, etc.). 

� Potential incursion into a controlled area (runways, taxiways, ILS critical areas, 

etc.). 

It may be necessary for the ATS system to make use of known routes and conformance 

monitoring to effectively detect these conflicts.

Aircraft type classification, status and clearance information will play an important role 

in conflict management processing. Individual areas may be restricted to certain vehicles 

or aircraft and not others. For example, a taxiway may be off limits to vehicles over a 

specified weight. In this case, a conflict or taxiway incursion alert will be generated if a 

heavy vehicle approaches or enters the taxiway while a lighter vehicle would have 

unrestricted access. In addition, an aircraft may be cleared to enter selected areas at 

specific times. For example, if an aircraft is cleared for a runway, it may enter it without 

restriction. If an uncleared aircraft enters the runway, a runway incursion alert will be 

generated. 

Environment 

Operational environment includes airport movement area up to 1500 feet above airport 

level so as to cover missed approaches and low level helicopter operations. The surface 

movement area is that part of an airport used for the takeoff, landing, and taxiing of 

aircraft. 


Participants are high-end aircraft performing taxi and departures during low visibility 

arrival operations (visibility less than 200 meters). 

Aircraft are approaching an active runway with aircraft on final approach. ADS-B is 

used to provide the pilot and controller with alert information of potential conflicts. This 

alert information consists of an indication to the pilot and controller of the time remaining 

until a conflict will occur. 

Requirements 

See Table 2-6 for information exchange needs and see Table 2-9(a) and Table 2-9(b) for 

operational performance needs to support ATS surveillance on the airport surface. 

Surface surveillance should interface seamlessly with terminal airspace to provide 

information on aircraft 5 NM from the touchdown point for each runway. 

2.2.2 ATS Conformance Monitoring Needs 

With ADS-B, ATS would monitor the ADS-B messages ensuring that an aircraft 

maintains conformance to its intended trajectory. Conformance monitoring occurs for all 

controlled aircraft or airspace, and applies to all operational airspace domains. In the 

case of protected airspace or SUA, conformance monitoring is performed to ensure that 

an aircraft does not enter or leave a specific airspace. 

In the terminal environment, the ATS provider will monitor the aircraft’s reported 

position and velocity vector to ensure that the aircraft’s current and projected trajectory is 

within acceptable bounds. The increased accuracy and additional information directly 

provided by the aircraft (via ADS-B), in comparison to radar-based monitoring, will 

result in quicker blunder detection and reduce false alarms. 


37

38 

2.2.2.1 Operational Scenario (Parallel Runway Monitoring) 

2.2.2.2 Requirements 


A specific example of conformance monitoring is PRM and simultaneous approach, a 

surveillance and automation capability that enables a reduction in minimum runway 

spacing for independent approaches to parallel runways in IMC. All aircraft participating 

in a given parallel approach should be ADS-B equipped. 

Initial use of ADS-B for PRM could be achieved before full equipage by limiting access 

to parallel approaches at specified airports only to ADS-B equipped aircraft. This may 

not be practical until a significant number of aircraft are equipped with ADS-B. When 

sufficient aircraft are equipped for ADS-B, an evolution to the full use of ADS-B to 

support PRM can occur. At that time, radar-based PRM system would no longer be 

needed. 

See Table 2-6 for information exchange needs and see Table 2-9(a) and Table 2-9(b) for 

operational performance needs to support ATS parallel runway conformance monitoring.

3 ADS-B and Airborne Systems Definition and Performance Requirements 

This section defines, within the context of ASA operational applications, the ADS-B 

System and its functional and performance requirements. The system description and 

user equipage classifications are summarized in Section 3.1. The broadcast information 

element requirements are given in Section 3.2. System application requirements are 

given in Section 3.3. Subsystem requirements are stated in Section 3.4, and ADS-B 

output report characteristics supporting application needs are described in Section 3.5. 

3.1 System Descriptions 

3.1.1 ADS-B Subsystem Description (Transmit and Receive) 

This section describes the ADS-B system, provides examples of ADS-B system 

architectures, and defines ADS-B equipage classes. 

3.1.1.1 Context Level Description 

3.1.1.1.1 System Level 

Context diagrams, which are data flow diagrams at successive levels of system detail, are 

used to define information exchanges across system elements and indicate how required 

functions are partitioned. The following subsections present context diagrams for ADS-B 

at three successive levels of detail: (1) the ADS-B system level, (2) subsystem level, and 

(3) functional level. 

ADS-B system level information exchange capabilities are illustrated in the top-level 

context diagram of Figure 3-1. As depicted in this and subsequent figures, four symbols 

are used to define data flows in context diagrams: 

Entities external to the ADS-B System are identified by rectangles 

Data flows are labeled lines with directional arrowheads 

Processes are defined by circles 

Data storage or delays are indicated by parallel lines. 

Information flows into or out of any context layer must be consistent with those 

identified at the next layer. 

The ADS-B system level includes ADS-B subsystems supporting each participant and the 

means necessary for them to exchange messages over the broadcast medium. The ADS- 

B system accepts own-ship source data from each of N aircraft/vehicle interactive 

participants, B aircraft/vehicle broadcast-only participants, and G fixed ground broadcastonly 

participants, and makes it available through the RF medium to each of the other N 

interactive participants as well as R receive-only ground sites. Interactive ground 

facilities may also exist in some ADS-B systems. 


39

40 

In Figure 3-1, own-ship source data for each broadcasting participant are denoted by the 

subscript “o” and include: 

Own-ship geometric and air mass referenced state vector reports (SVo) which include 

aircraft position, velocity, navigation integrity category (NICo) indicating integrity 

containment radius RC of position data, and address, Ado. 

Mode-status reports (MSo) which include address, Ado, aircraft/vehicle identification IDo 

(flight or tail number if enabled by user, and aircraft category), emergency/priority 

status, information on supported applications, and navigation accuracy categories 

indicating the accuracy of position (NACP) and velocity (NACV) data. 

On-condition reports (OCo) include aircraft/vehicle address Ado. Types of OC reports 

may include Trajectory Change+0 and Trajectory Change+n reports for longer-term 

intent information. 

Data for on-condition reports are accompanied as needed by appropriate control inputs 

(e.g., “transmit an ADS-B message under these conditions” as opposed to following a 

strictly periodic pattern of transmission). Messages transmitted by other ADS-B system 

participants are received by the onboard ADS-B subsystem and used to generate ADS-B 

reports (indicated by subscript “i”) which are made available for onboard applications. 

The address, common to all message types, is used for correlating received information. 

System level requirements are given in §3.3 and format characteristics associated with the 

required information exchanges are summarized in §3.5. 

3.1.1.1.2 Subsystem Level 


Further details of the many-to-many information exchange supported by the ADS-B 

system are given in the subsystem level context diagram of Figure 3-2. Subsystems 

supporting each type of participant are shown in the figure with their respective user 

interfaces and associated message exchanges over the RF medium. As described above, 

the aggregate of all ADS-B subsystems interconnected over the broadcast medium 

comprises the ADS-B system. 

Interactive Aircraft/vehicle participant system interfaces to the supporting ADS-B 

subsystem are illustrated in the upper left part of the figure. State vector source data 

(SVo) are provided by the platform dynamic navigation systems and sensors. Modestatus 

and on-condition source data (MSo, OCo) are available from onboard flight status 

source data or by flight crew entry. This own-ship information is transmitted over the RF 

medium as appropriately encoded ADS-B messages (Mo). Similarly defined messages 

are received from other participants (Mi), processed by the subsystem, and made 

available as ADS-B reports (SVi, MSi, OCi) to surveillance-related on-board applications. 

The operational mode is determined by the subsystem control logic, e.g., a different 

broadcast mode may be used while on the airport surface. 

Functional capabilities and information flows for other classes of subsystems are also 

indicated in Figure 3-1. Other subsystem classes are aircraft/vehicle broadcast-only 

(requiring inputs from an onboard navigation system and database, but providing no 

output information to on-board applications); fixed ground broadcast-only (requiring 

previously surveyed data inputs); and ground receive-only (providing ADS-B reports to

Participant - N 

Participant - 2 


support ATS and other applications). Subsystem control inputs are shown as dashed 

lines for each subsystem. Subsystem requirements are given in §3.4. 









Figure 3-1: Illustrative ADS-B System Level Context Diagram 

Abbreviations: 

SVo = own state vector source data 

MSo = own mode-status source data 

OCo = own event driven or on condition source data 

SVi = other participants’ state vector reports 

MSi = other participants’ mode-status reports 

OCi = other participants’ on condition reports 

41 


© 20xx, RTCA, Inc.

42 

Dynamic NAV State 

Data 

Subsystem Control 

Logic 

Database 

MSi 

Crew Entry and 

Flight Status Data 

SV0 

MS0 OC0 

MSi 

Participant 

Applications 

ADS-B Subsystem 

(Aircraft / Vehicle 

Interactive 

Participant) 

SVi OCi 

SVi 


Logic 


(Fixed Ground 

Broadcast Only 

Participant) 

Mi 

M0 

M0 

ADS-B medium 

Crew Entry and 

Flight Status Data 

Mi 

M0 

MS0 


(Aircraft / Vehicle 

Broadcast Only 

Participant) 


(Ground Surveillance 

Participant) 

Dynamic NAV State 

Data 

SV0 


Logic 

Surveillance 

Application 

SVi MSi OCi 


Logic 

Figure 3-2: ADS-B Subsystem Level Context Diagram for ADS-B System 

Note: M0 represents own ship transmitted message, Mi denotes messages received from other 

participants. The vector notation, M denotes one or more messages, depending on 

implementation. Different participants may supply and / or use different types of information 

© 20xx, RTCA, Inc.

ADS-B 

Message 

Generation 

Function 

ADS-B 

Message 

Exchange 

Function 

(Transmission) 

SV0 

MS0 

I/F Control, 

NAV update, 

Message 

Assembler and 

Encoder 

Modular and 

Transmitter 

Transmit 

Aantenna 

Subsystem 

OC0 

Input Interface (I/F) 

and Buffer 

M0 

Message 

Transmit 

Control 

Subsystem 

Control 

Control I/F 

Report 

Output 

Control 

ADS-B Medium 

Mi 

SVi 

MSi 

OCi 

Output Interface (I/F) 

and Buffer 

Decoder, Report 

Assembly and 

I/F Control 

Receiver and 

Demodulator 

Receive Antenna 

Subsystem 

ADS-B 

Report 

Assembly 

Function 

ADS-B 

Message 

Exchange 

Function 

(Reception) 

Figure 3-3: ADS-B Functional Level Context Diagram for Aircraft Interactive 

Subsystem 


43

44 

3.1.1.1.3 Functional Level 

Subsystem functional partitioning and interfaces are illustrated for an interactive aircraft 

participant in the functional level context diagram of Figure 3-3. Functional capabilities 

required to (1) accept source data inputs and control information to the subsystem from 

onboard systems, and generate the required ADS-B messages; (2) exchange messages 

with other ADS-B participants; and (3) assemble ADS-B reports containing required 

information from other participants for use by onboard applications, are outlined here. 

Subsystem functional partitioning and interfaces for broadcast-only and receive-only 

participants are described by an appropriate subset of this functionality. 

3.1.1.2 Participant Architecture Examples 


Examples of ADS-B subsystem architectures and their interactions are given in Figure 3- 

4, Figure 3-5 and Figure 3-6. Figure 3-4 illustrates the minimum capabilities on-board 

aircraft A to support aid to visual acquisition and ADS-B traffic situational awareness 

with alerting on-board aircraft B. 

Figure 3-4: Example of A/C Pair Supporting Aid to Visual Acquisition and TSAA 

Figure 3-5 illustrates expanded capabilities enabled by the more sophisticated onboard 

avionics. With more capable ADS-B transmit and receive avionics, and the ability to 

support appropriate user applications, each aircraft may be approved for more advanced 

ADS-B applications. 

Figure 3-6 illustrates ADS-B applied to air-ground surveillance. The precise velocity, 

geometric and air mass data along with selected altitude and heading information 

provided by ADS-B enables advanced surveillance and conflict management 

implementations. Ground system track processing and correlation of ADS-B data with 

other ground derived surveillance data can provide an integrated view to ground 

automation and controller interfaces. 

Approval for the above operational uses of ADS-B requires certification of ADS-B 

equipage integrated with other aircraft/vehicle and ground systems and demonstration of 

acceptable end-to-end performance. The approved system design must include the 

originating sources and the user applications necessary to support appropriate operational 

levels defined above. Interdependencies between the ADS-B subsystems, interfacing 

sources and user applications will probably need to be addressed as part of the subsystem

certification process. The distributed elements of the total system comprising the 

operational capability typically will be individually certified. 

3.1.1.3 Equipage Classifications 

Surveillance 

Data 

Primary 

Geometric 

Position / Velocity 

Baro Alt / 

Ground Track 

Address Type / Flt 

ID 

Intent Data 

Current / Future 

- RNAV 

-Other 

As illustrated above, ADS-B equipment must be integrated into platform architectures 

according to platform characteristics, capabilities desired and operational objectives for 

the overall implementation. The technical requirements for ADS-B have been derived 

from consolidation of the scenarios presented in Section 2 within the context of the use of 

the ADS-B System as primary-use capable. The operational capabilities are divided into 

hierarchical levels (with each level including all capabilities of the preceding level): 

Aid to Visual Acquisition: basic state vector information 

VSA and ITP: state vector information augmented with identification 

Aircraft - A 

D 

A 

T 

A 

I 

N 

P 

U 

T 

M 

E 

S 

S 

A 

G 

E 

G 

E 

N 

E 

R 

A 

T 

O 

R 

M 

E 

S 

S 

A 

G 

E 

T 

R 

A 

N 

S 

M 

I 

T 

T 

E 

R 

RF 

medium 

M 

E 

S 

S 

A 

G 

E 

R 

E 

C 

E 

I 

V 

E 

R 

R 

E 

P 

O 

R 

T 

A 

S 

S 

E 

M 

B 

L 

E 

R 

D 

I 

G 

I 

T 

A 

L 

O 

U 

T 

P 

U 

T 

Aircraft - B 

Primary 

Geometric Nav 

Aid to Visual 

Acquisition 

TSAA 

FIM-S & FIM-DS 

RNAV 

De-conflict 

Application 

Figure 3-5: Example of A/C Pair Capable of Supporting Advanced ADS-B 

Applications 


45

46 

Surveillance 

Data 

Primary 

Geometric 

Position / Velocity 

Baro Alt / 

Ground Track 

Address Type / Flt 

ID 

Intent Data 

Current / Future 

- RNAV 

-Other 

Aircraft - A 

D 

A 

T 

A 

I 

N 

P 

U 

T 

M 

E 

S 

S 

A 

G 

E 

G 

E 

N 

E 

R 

A 

T 

O 

R 

M 

E 

S 

S 

A 

G 

E 

T 

R 

A 

N 

S 

M 

I 

T 

T 

E 

R 

RF 

medium 

M 

E 

S 

S 

A 

G 

E 

R 

E 

C 

E 

I 

V 

E 

R 

R 

E 

P 

O 

R 

T 

A 

S 

S 

E 

M 

B 

L 

E 

R 

D 

I 

G 

I 

T 

A 

L 

O 

U 

T 

P 

U 

T 

Ground 

System 

Ground ADS-B 

Data Fusion 

Enhanced ATM 

Applications 

Other 

Surveillance 

Sources 

Figure 3-6: Example of ADS-B Support of Ground ATS Applications 

ADS-B equipage is categorized according to the classes listed in Table 3.1.1.3.2a. ADS- 

B equipage classes are defined in terms of the levels of operational capabilities discussed 

above. The classifications include airborne and ground participants, and include those 

that are fully interactive and those that only receive or transmit. In addition to defining 

equipage classifications the table summarizes salient features associated with these 

capabilities. 

ADS-B systems used on surface vehicles are expected to require certification similar to 

that applicable to airborne ADS-B systems in order to ensure conformance to required 

transmission characteristics. If required due to spectrum considerations, surface vehicles 

must have an automatic means to disable transmission of ADS-B messages when outside 

the surface movement area. 

3.1.1.3.1 Interactive Aircraft/Vehicle ADS-B Subsystems (Class A) 


Functional capabilities of interactive aircraft/vehicle subsystems are indicated in the 

context diagram of Figure 3-3. These subsystems accept own-platform source data, 

exchange appropriate ADS-B messages with other interactive ADS-B System 

participants, and assemble ADS-B reports supporting own-platform applications. Such 

interactive aircraft subsystems, termed Class A subsystems, are further defined by 

equipage classification according to the provided user capability. 

The following types of Class A subsystems are defined in (Table 3.1.1.3.2a): 

Class A0: Supports minimum interactive capability for participants. Broadcast ADS-B 

messages are based upon own-platform source data. ADS-B messages received from 

other aircraft support generation of ADS-B reports that are used by on-board 

applications (e.g., CDTI for aiding visual acquisition of other-aircraft tracks by the

own-aircraft’s air crew). This equipage class may also support interactive ground 

vehicle needs on the airport surface. 

Class A1 supports all class A0 functionality and additionally supports, e.g., ADS-B-based 

airborne conflict management and other applications at ranges < 20 NM. Class A1 is 

intended for operation in IFR designated airspace. 

Class A2: Supports all class A1 functionality and additionally provides extended range to 

40 NM and information processing to support longer range applications, e.g. oceanic 

climb to co-altitude. 

Class A3: Supports all class A2 functionality and has additional range capability out to 

90 NM, supporting, e.g., long range airborne applications. 

3.1.1.3.2 Broadcast-Only Subsystems (Class B) 

Some ADS-B system participants may not need to be provided information from other 

participants but do need to broadcast their state vector and associated data. Class B ADS- 

B subsystems meet the needs of these participants. Class B subsystems are defined as 

follows (Table 3.1.1.3.2a): 

Class B0: Aircraft broadcast-only subsystem, as shown in Figure 3-2. Class B0 

subsystems require an interface with own-platform navigation systems. Class B0 

subsystems require transmit powers and information capabilities equivalent to those 

of class A0. 

Class B1: Aircraft broadcast-only subsystem, as shown in Figure 3-2. Class B1 

subsystems require an interface with own-platform navigation systems. Class B1 

subsystems require transmit powers and information capabilities equivalent to those 

of class A1. 

Class B2: Ground vehicle broadcast-only ADS-B subsystem. Class B2 subsystems 

require a high-accuracy source of navigation data and a nominal 5 NM effective 

broadcast range. Surface vehicles qualifying for ADS-B equipage are limited to 

those that operate within the surface movement area. 

Class B3: Fixed obstacle broadcast-only ADS-B subsystem. Obstacle coordinates may 

be obtained from available survey data. Collocation of the transmitting antenna with 

the obstacle is not required as long as broadcast coverage requirements are met. 

Fixed obstacle qualifying for ADS-B are structures and obstructions identified by 

ATS authorities as a safety hazard. 


47

48 

Table 3.1.1.3.2a: Subsystem Classes and Their Features 

Class Subsystem Description Features Comments 

Interactive Aircraft/Vehicle Participant Subsystems (Class A) 

A0 Minimum Supports basic enhanced Lower transmit power and less Minimum interactive capability with 

Interactive 

visual acquisition sensitive receive than Class A1 

CDTI. 

Aircraft/Vehicle 

permitted. 

A1 Basic Interactive A0 plus provides standard Standard transmit and receive Provides standard range 

Aircraft 

range 

A2 Enhanced A1 plus improved range Standard transmit power and more Supports longer range applications 

Interactive 

sensitive receive. Interface with 


avionics source required for TS. 

A3 Extended 

A2 plus long range Higher transmit power and more Extends range for advanced 

Interactive 

sensitive receive. Interface with 

applications. 


avionics source required for TS. 

Broadcast-Only Participant Subsystems (Class B) 

B0 Aircraft Supports A0 Applications Transmit power may be matched to Enables aircraft to be seen by Class A 

Broadcast only for other participants 

coverage needs. 

and Class C users. 

B1 Aircraft Supports A1 Applications Transmit power may be matched to Enables aircraft to be seen by Class A 

Broadcast only for other participants 

coverage needs. 


B2 Ground vehicle Supports airport surface Transmit power matched to surface Enables vehicle to be seen by Class A 

Broadcast only situational awareness coverage needs. High accuracy 

position input required. 


B3 Fixed obstacle Supports visual acquisition Fixed coordinates. No position Enables NAV hazard to be detected by 

and airborne conflict input required. Collocation with 

Class A users. 

management 

obstacle not required with 

appropriate broadcast coverage. 

Ground Receive Subsystems (Class C) 

C1 ATS En route and Supports ATS cooperative Requires ATS certification and Supports provision of ATS 

Terminal Area 

surveillance 

interface to ATS sensor fusion Surveillance for ADS-B System 

Operations 

system. 

Participants where adequate Air- 

Ground range and integrity have been 

demonstrated. 

C2 ATS Parallel 

Runway and 

Surface 

Operation 

C3 Flight Following 

Surveillance 

Supports ATS cooperative 

surveillance 

Supports private user 

operations planning and 

flight following 

Requires ATS certification and 

interface to ATS sensor fusion 

system. 

Does not require ATS interface. 

Certification requirements 

determined by user application. 

3.1.1.3.3 Ground Receive-Only Subsystems (Class C) 


Expected en route coverage out to 200 

NM. Expected terminal coverage out 

to 60 NM. 

Expected approach coverage out to 30 

NM, or – if of lesser value - the point 

where the aircraft intercepts the final 

approach course. Expected surface 

coverage out to 5 NM. 

Coverage determined by application. 

Surveillance state vector reports, mode-status reports, and on-condition reports are 

available from ADS-B system participants within the coverage domain of ground ADS-B 

receive-only, or Class C subsystems. The following Class C subsystems are defined 

(Table 3.1.1.3.2a): 

Class C1: Ground ATS Receive-Only ADS-B Subsystems for En Route and Terminal 

area applications. Class C1 subsystems should meet continuity and availability 

requirements determined by the ATS provider.

Class C2: Ground ATS Receive-Only ADS-B Subsystems for approach monitoring and 

surface surveillance applications. Class C2 subsystems have more stringent accuracy 

and latency requirements than Class C1 systems. Class C2 systems may be required, 

depending upon the ADS-B System design, to recognize and process additional 

ADS-B message formats not processed by Class C1 subsystems. 

Class C3: Ground ATS Receive-Only ADS-B Subsystems for flight following 

surveillance is available from this equipage class for use by private operations 

planning groups or for provision of flight following and SAR. 

3.1.2 ASSAP Subsystem Description 

The Airborne Surveillance and Separation Assurance Processing (ASSAP) subsystem 

represents the surveillance and application-specific processing functions of ASA. 

ASSAP surveillance processing consists of correlation, and track processing of ADS-B, 

ADS-R, TIS-B, and TCAS (if equipped) traffic reports. ASSAP application processing 

provides the application-specific processing for all ASA applications. The extent of 

ASSAP application processing is dependent upon the aircraft’s capabilities, as 

determined by each application’s minimum performance requirements. ASSAP 

application processing may be minimal for airborne situational awareness applications 

(e.g., EVAcq or AIRB), or may require more significant processing for surface situational 

awareness applications (e.g., SURF) or future guidance applications (e.g., FIM-S). The 

ASSAP subsystem also monitors and processes flight crew inputs via the interface from 

the Cockpit Display of Traffic Information (CDTI) subsystem, and provides all traffic 

surveillance data and ASA application-specific data for visual and /or aural display to the 

CDTI for the flight crew. 

3.1.2.1 ASSAP/CDTI System Boundaries 

Figure 3-7 illustrate the ASSAP/CDTI system boundaries as two subsystems of the ASA 

System, and is based on Figure 1-1. The dashed line represents the system boundary for 

the ASSAP and CDTI subsystems. The allocated requirements for ASSAP and the CDTI 

are found in §3.4.1 and §3.4.2, respectively. 


49

50 

B3 

A3 


Subsystems for ASA Receive Participant 

ADS-B, 

ADS-R, 

TIS-B 

Receive 

Subsystem 

E 

ADS-B 

ADS-R 

TIS-B 

Reports 

Navigation Sensors 

(e.g. GPS receiver) 

Airborne 

Surveillance & 

Separation 

Assurance 

Processing 

Barometric Altitude, 

Altitude Rate 

Data Sources on Receiving Aircraft 

F G 

CDTI 

Display 

and 

Control 

Panel 

E F G 

Pilot Input 

(e.g. Call Sign) 

Figure 3-7: ASSAP/CDTI Subsystem Boundaries 

Flight 

Crew 

Note: Detailed ASSAP and CDTI performance and subsystem requirements are 

addressed in the ASA System MOPS, the latest version of DO-317( ). 

While ASSAP provides all application-specific processing for ASA, it also maintains the 

interfaces to and from the CDTI. It is due to the close association of the ASSAP and the 

CDTI, and their shared interface, that the ASSAP and CDTI MOPS was developed as a 

single requirements document. The two sub-systems, ASSAP and CDTI, constitute the 

“Aircraft Surveillance Application Systems“ and the Minimum Operational Performance 

Standards document for this system is termed the “ASA System MOPS” the latest version 

of DO-317( ). 

As shown in Figure 3-7, the CDTI subsystem also serves as the ASA interface to the 

flight crew. 

B3 

A3

3.1.3 CDTI Subsystem Description 

The CDTI subsystem includes the actual visual and aural display media and the necessary 

controls to interface with the flight crew. Thus the CDTI consists of all displays and 

controls necessary to support the applications. The controls may be a dedicated CDTI 

control panel or it may be incorporated into other controls, (e.g., multifunction control 

display unit (MCDU) or Electronic Flight Bag (EFB)). Similarly, the CDTI display may 

be a stand-alone display or displays (dedicated display(s)) or the CDTI information may 

be present on an existing display(s) (e.g., multi-function display) or an EFB. At a 

minimum, CDTI includes a graphical plan-view (top down) traffic display (a “Traffic 

Display”), and the controls for the display and applications (as required). Additional 

graphical and non-graphical display surfaces may also be included. The CDTI receives 

position information of traffic and Own-ship from the airborne surveillance and 

separation assurance processing (ASSAP) function. The ASSAP receives such 

information from the surveillance sensors and Own-ship position sensors. 

A physical display screen may have more than one instance of a CDTI Display on it. For 

example, a display with a split screen that has a Traffic Display on one half of the screen 

and a list of targets on the other half has two instances of CDTI Displays. 

The Traffic Display is a graphical plan-view (top down) traffic display. Every CDTI 

installation includes a Traffic Display. The Traffic Display may be a stand-alone display 

or displays (dedicated display(s)) or the CDTI information may be present on an existing 

display(s) (e.g., multi-function display) or an EFB. 

Specific requirements for the Traffic Display are shown in the ASA MOPS. The Traffic 

Display is required to indicate own-ship position and, to show the positions, relative to 

the own-ship, of traffic. The Traffic Display is also required to provide specific traffic 

information elements in associated data tag and traffic symbology. 

3.1.4 ANSP Systems 

3.1.4.1 ADS-B (Ground Receive) 

3.1.4.1.1 ADS-B Non-Radar-Airspace (NRA) Application (ADS-B-NRA) 

The ADS-B-NRA application (see Table 2-10) is designed to support and enhance Air 

Traffic Services in both En- route and Terminal Maneuvering Area (TMA) airspaces in 

non-radar areas. 

The ADS-B-NRA application will provide enhanced Air Traffic Services in areas where 

radar surveillance currently does not exist. 

The ADS-B-NRA application will be most beneficial in areas where, the level of traffic, 

location, or the cost of the equipment, cannot justify the installation of a radar. Examples 

of such areas include remote locations, off-shore oil rigs and small island environments. 

ADS-B-NRA may also be used in areas where an existing radar is to be de-commissioned 

and the replacement costs cannot be justified. 

The ADS-B-NRA application is designed to enhance the following ICAO Air Traffic and 

Flight Information Services: 


51

52 

� Operation of air traffic control service 

� Separation minima 

� Transfer of responsibility for control 

� Air traffic control clearances 

� Scope of flight information service 

� Alerting Service, principally for the following functions: Notification of rescue coordination 

centers 

� Plotting of aircraft in a state of emergency 

� Air Traffic Advisory Services 

ADS-B-NRA will provide benefits to capacity and enhancements to these services, when 

compared to current capabilities, in a way similar to the introduction of SSR radar. This 

will be especially true when and where many aircraft become ADS-B equipped. 

It is expected that this application will provide, efficiency and safety in a similar way as 

could be achieved by the introduction of SSR radar. 

ADS-B-NRA will enhance the Air Traffic Control Service by providing controllers with 

improved situational awareness of aircraft positions and the possibility of applying 

separation minima much smaller than what is presently used with current procedures. 

The Alerting Service will be enhanced by more accurate information on the latest 

position of aircraft. Furthermore, the broadcast of ADS-B emergency status information 

will be displayed to the controller independently from any radio communications. 

The intention of the ADS-B-NRA application is to allow the procedures using radar 

surveillance to be enabled by ADS-B, assuming that the quality of service of ADS-B 

surveillance is similar to (or better than) SSR radar and that appropriate air-ground 

communications coverage is available. 

While the role of the controller and pilot will remain unchanged, there may be impact on 

their workloads because of new control procedures and the provision of enhanced 

services. Flight crews may interface with the ADS-B transmitter in a way similar to that 

of a SSR transponder. 

ADS-B-NRA is discussed in more detail in RTCA DO-303, Safety, Performance and 

Interoperability Requirements Document for the ADS-B Non-Radar-Airspace (NRA) 

Application. 

3.1.4.1.2 Enhanced Air Traffic Services in Radar-Controlled Areas Using ADS-B 

Surveillance (ADS-B-RAD) 


The ADS-B-RAD application (see Table 2-10) will support, and in some cases enhance, 

Air Traffic Services through the addition of ADS-B surveillance in areas where radar 

surveillance exists. It will apply to the En Route and terminal airspace in classes A to D. 

The application is designed to support the following ICAO Air Traffic Services: 

1. Air Traffic Control Service, including 

a. Area Control Service

. Approach Control Service 

2. Flight Information Service; 

3. Alerting Service; 

4. Air Traffic Advisory Service. 

The introduction of ADS-B may enhance these services by improving the overall quality 

of surveillance, i.e., radar plus ADS-B such that an operational benefit may include a 

reduction in the applied separation standards from that applied in today's airspace but not 

below the ICAO minima, e.g., 10 NM to 5 NM. 

Enhanced Air Traffic Services in Radar-Controlled Areas Using ADS-B Surveillance is 

discussed in more detail in RTCA DO-318, Safety, Performance and Interoperability 

Requirements Document for Enhanced Air Traffic Services in Radar-Controlled Areas 

Using ADS-B Surveillance (ADS-B-RAD). 

3.1.4.1.3 ADS-B Airport Surface Surveillance Application (ADS-B-APT) 

The ADS-B-APT application (see Table 2-10) aims to enhance aerodrome operations by 

adding ADS-B surveillance to a non-surveilled aerodrome and provide the controller with 

an appropriate graphical display to view the surveillance data. 

The ADS-B-APT application will provide the controller with a display of the airport 

layout (showing as a minimum runway and taxiway boundaries) and the positions of the 

aircraft and ground vehicles on the Maneuvering Area, along with the surveillance data 

associated with these vehicles. 

ADS-B-NRA surveillance data is intended to augment the controller's situational 

awareness and help manage the traffic in a more efficient way. The ADS-B-APT 

application will support the controller in performing the Aerodrome Control Service 

tasks, for example to assist in the detection of runway incursions. In this respect, the 

application does not aim to reduce the occurrence of runway incursions, but may reduce 

the occurrence of runway collisions by assisting in the detection of the incursions. 

Controllers use radio communications and out the window scans, as well as manual aidememoires 

to obtain and maintain traffic situational awareness in support of the 

Aerodrome Control Service. As visual observation is the primary source of aircraft and 

ground vehicle situation awareness, ADS-B-APT is expected to bring its greatest benefits 

in poor visibility conditions, when visual observation may become difficult and the 

controller becomes more reliant on voice and other aids. 

The most similar existing environment to the ADS-B-APT environment is an 

environment with a Surface Movement Radar (SMR) in that both are designed as an 

augmentation to Aerodrome Procedures and not designed to be used on their own (such 

as for A-SMGCS). 

In the Target Environment, all existing procedures for flight crews and controllers used 

for Aerodrome Operations remain valid and unchanged when compared to the Reference 

Environment, except transponder procedures which will be required to be applied before 


53

54 

entering the Maneuvering Area. Flight crew and controller roles and responsibilities are 

also unchanged by the introduction of ADS-B-APT. Further, the design of the airport is 

unchanged with the introduction of ADS-B-APT. 

Some data items that ADS-B provides (e.g., identification) are not available in the SMR 

environment. In this regard, guidance is provided on identification procedures, though 

there are no new procedures relating to the identification of aircraft or ground vehicles. 

The controller may correlate the callsign with the Mode A code or use direct recognition 

of the vehicle's Identity Information in the ADS-B label. 

The Target Environment is assumed to be a simple to complex aerodrome layout with 

many taxiways, possibly multiple terminals and aprons and possibly multiple runways, 

but limited up to two active runways at a time, with ADS- B as a unique means of 

surveillance. 100% ADS-B OUT qualified equipage for the aircraft or ground vehicles in 

the Maneuvering Area is assumed. 

The ADS-B-APT application is not designed to assist in the detection of Intruders, as 

they are not authorized and/or not equipped. 

ADS-B-APT is discussed in more detail in RTCA DO-321, Safety, Performance and 

Interoperability Requirements Document for ADS-B Airport Surface Surveillance 

Application (ADS-B-APT). 

3.1.4.2 TIS-B and ADS-R Service Description 


This section defines the Automatic Dependent Surveillance-Rebroadcast (ADS-R) and 

Traffic Information Broadcast Services (TIS-B) services provided by the FAA 

Surveillance and Broadcast Services System (SBS – Ground System). Together, ADS-R 

and TIS-B, provide the ADS-B user pilot’s CDTI with aircraft/vehicle (A/V) position 

data that will compliment and complete the view of neighboring traffic. 

ADS-R is an SBS service that receives ADS-B-OUT position broadcasts and rebroadcasts 

that information to aircraft in the vicinity equipped with a different ADS-B data link. 

ADS-R service provides for interoperability between ADS-B equipped aircraft with 

different data links. 

TIS-B is a surveillance service that derives traffic information from FAA radar/sensor 

sources, and uplinks this traffic information to ADS-B-equipped aircraft. TIS-B enables 

ADS-B-equipped aircraft to receive position reports on non-ADS-B-equipped aircraft in 

the NAS. 

Note: TIS-B Service is intended for the transition period to full ADS-B equipage. 

Figure 3-8 illustrates the top-level architecture for the SBS – Ground System. It is 

composed of three segments: Radio Station, Control, and Network. ADS-R and TIS-B 

services are provided to aircraft at the air interface (top of figure). Surveillance and 

sensor data are provided to the TIS-B service as shown at the bottom of the figure (FAA 

TIS-B Data SDP). ADS-B surveillance data are provided to the ADS-R service within 

the Radio Segment, the determination of user need for ADS-R service and scheduling of 

ADS-R messages is performed within the Control Segment.

3.1.4.2.1 ADS-R Service 

Figure 3-8: SBS System Reference Architecture 

Automatic Dependent Surveillance–Rebroadcast (ADS-R) is a service that relays ADS-B 

information transmitted by an aircraft using one link technology to aircraft of an 

incompatible link technology. The high level data flows supporting ADS-R are 

illustrated in Figure 3-9. The SBS – Ground System control station infrastructure 

monitors ADS-B transmissions by active ADS-B equipped aircraft and continuously 

monitors the presence of proximate aircraft with incompatible link technologies (e.g., 

UAT and 1090ES). When such aircraft are in proximity of each other, the SBS – Ground 

System control station infrastructure instructs ground radio stations within range of both 

aircraft to rebroadcast surveillance information received on one link frequency to aircraft 

on the other link frequency. The ADS-R Service currently supports only advisory level 

surveillance applications. 


55

56 

ADS‐R 

Non‐Equipped 

UAT 

1090ES 

FIS‐B 

Provider 

3.1.4.2.1.1 ADS-R Concept of Operations 


Radio 

Station 

Control 

Station 

Cross‐Linking Cross‐Linking of of ADS‐B ADS‐B data data for for Aircraft Aircraft Situational Situational Awareness 

Awareness 

Figure 3-9: ADS-R Service Data Flows Data 

FAA 

Since two incompatible ADS-B link technologies are allowed, aircraft equipped with a 

single link technology input will not be able to receive ADS-B transmissions from the 

other link technology, and therefore will be unable to receive all ADS-B transmissions. 

The ADS-R service closes this gap. In defined airspace regions, the ADS-R service will 

receive ADS-B transmissions on one link, and retransmit them on the complementary 

link when there is an aircraft of the complementary link technology in the vicinity. 

An aircraft or vehicle that is an active ADS-B user and is receiving ADS-R service is 

known as an ADS-R Client. An ADS-B equipped aircraft or vehicle on the opposite link 

of the ADS-R Client that has its messages translated and transmitted by the SBS System 

is known as an ADS-R Target. 

Figure 3-10 describes a more detailed ADS-R and TIS-B functional data flow. ADS-B 

dual data link equipped aircraft or vehicles (e.g., 1090ES and UAT), shown at the top of 

the figure, do not require ADS-R service as they will receive ADS-B messages directly 

from single and dual data link equipped aircraft and vehicles.

USER AIR 

INTERFACE 

ADS-B 

MESSAGES 

RADIO SEGMENT 

ADS-B 

REPORTS & METRICS 

ADS-B 

REPORTS & METRICS 

1090 ES Equipped A/V 1090 ES/UAT Dual Equipped A/V 

UAT Equipped A/V 

ADS-B 

Message 

RCV/Decode 

ADS-B 

Report Generation 

NETWORK SEGMENT 

CONTROL SEGMENT 

ADS-B 

Report 

Generation, 

Processing 

and 

Distribution 

NETWORK SEGMENT 

FAA ATC Automation 

FAA SERVICE DELIVERY POINTS 

ADS-R/TIS-B 

MESSAGES 

ADS-B 

REPORTS 

ADS-R 

TRANSMIT SCHEDULING 

ADS-R STATUS 

USER SATUS 

& VALIDATION 

ADS-B 

MESSAGES 

ADS-R 

Message 

Generation 

ADS-R 

Message 

Scheduling 

TIS-B 

,MESSAGES 

ADS-B 

MESSAGES 

ADS-R 

TIS-B 

STATUS REPORTS 

TIS-B STATUS 

ADS-R 

SCHEDULE 

FAA Service Monitor 

ADS-R / TIS-B 

Message 

Transmission 

TIS-B 

Message Generation 

TIS-B 

Track 

Report 

Processing 

and 

Scheduling 

TRACK 

REPORTS 

TIS-B REPORTS & 

SERVICE STATUS 

ADS-R/TIS-B 

MESSAGES 

ADS-B REPORTS 

Figure 3-10: ADS-R and TIS-B Functional Architecture and Data Flows 

3.1.4.2.1.2 ADS-R Client Identification 

57 

Multi-Sensor 

Track 

Generation 

Radar Data 

Conversion 

SENSOR 

DATA 

FAA Surveillance 

Sources (Radar, Mode S) 

In order to receive ADS-R service an aircraft must be in an airspace region where the 

ADS-R service is offered, must be ADS-B-OUT, must have produced valid position data 

within the last 30 seconds to a SBS ground station, and must be ADS-B-IN on only one 

link (if ADS-B-IN on both links, ADS-R is not needed). The SBS – Ground System 

monitors the received ADS-B reports to identify active ADS-B users, and the ADS-B-IN 

link technologies operating on the aircraft. 

Note: With respect to the user aircraft/vehicle (A/V) data links; ADS-B-OUT indicates 

the A/V can transmit ADS-B messages, ADS-B-IN indicates the A/V can receive 

service messages such as ADS-R and TIS-B. A dual data link equipped A/V can 

transmit and receive both 1090ES and UAT services. 

© 20xx, RTCA, Inc.

58 

ADS-R client identification is provided by the ADS-B Report Generation, Processing, 

and Distribution function shown in Figure 3-10 Control Segment block and sent to the 

ADS-R Message Scheduling function (User Status and Validation). The identification 

information contained in the “User Status and Validation” message includes: 

1. A/V ICAO Address 

2. Link Technology Indicator 

In addition the ADS-B Report Generation, Processing, and Distribution function provides 

the A/V’s: 

1. Position data 

2. Altitude 

3. Validation Status 

A/V validation status is referring to the capability of the SBS Control Station Segment 

providing an independent validation of the position information received in the ADS-B 

Messages. In certain Service Volumes, the FAA will require that the ADS-B Service 

provide independent validation. The validation capability may assure to a specified 

probability that each ADS-B Message, and the position information contained within, is 

from a real aircraft/vehicle with a valid position source rather than from a source 

broadcasting erroneous information or a spoofer. The validation methods are: 

1) Comparison of ADS-B position data to radar position data, 

2) Comparing a one way “passive range” with range to target indicated by ADS-B 

position data (available for UAT equipped targets), and 

3) Use of time difference of arrival techniques. 

3.1.4.2.1.3 ADS-R Target Identification 


The SBS – Ground System identifies all aircraft that need to receive ADS-R 

transmissions for each active ADS-B transmitter. It does this by maintaining a list of all 

active ADS-B users, and their associated input link technologies. ADS-R target 

identification is provided by the ADS-B Report Generation, Processing, and Distribution 

function shown in Figure 3-10 Control Segment block and sent to the ADS-R Message 

Scheduling function. The identification information is contained in the targets ADS-B- 

OUT messages; the ID information includes: 



For each transmitting ADS-B aircraft the SBS – Ground System determines all aircraft 

that do not have ADS-B-IN of the same link technology, that are within the vicinity, and 

need to receive ADS-R transmissions.

3.1.4.2.1.4 ADS-R in Enroute and Terminal Airspace Domains 

To determine if a client requires ADS-R service, the SBS – Ground System will examine 

all candidate proximity aircraft, i.e., aircraft within a 15 NM horizontal range and ±5000 

feet altitude of a client aircraft as shown in Figure 3-11. Aircraft that do not have ADS- 

B-IN of the same link technology as the client, and they are within the cylinder shown in 

Figure 3-11, are candidate ADS-R targets whose ID, position data, etc are required to be 

transmitted to the client. 

In addition, ADS-B targets in a ground state are not provided to ADS-B-IN airborne 

clients, i.e., airborne clients within the Enroute or Terminal SVs. 

3.1.4.2.1.5 ADS-R in Surface Domains 

Figure 3-11: ADS-R Client Proximity Determination 

In a surface domain SV, a client is provided all applicable ADS-R targets in SV domain. 

This includes all targets in the ground state within the movement area (runways and 

taxiways) as well as all airborne targets within 5 NM and 2000 feet AGL of the airport 

reference point (ARP). 

3.1.4.2.1.6 Transmission of ADS-R Targets over the Air Interface 

Each ADS-R Target aircraft may have one or more client aircraft that need to receive 

ADS-R transmissions, possibly in different domains. The SBS – Ground System 

determines the ADS-R transmission rate required by the client in the most demanding 

domain. The SBS – Ground System also determines the radio or set of radios necessary 

to transmit ADS-R messages to all clients. 

If a radio selected for transmissions to a client is also receiving transmissions from the 

client the ADS-R Message Scheduling function shown in Figure 3-10 prepares an ADS-R 

transmission schedule and submits it to the radio. The ADS-R transmission schedule 

identifies the 24-Bit address of the target aircraft, and an update interval. When the radio 

receives transmissions from the target aircraft it will retransmit the report on the opposite 


59

60 

3.1.4.2.2 TIS-B Service 

link, according to the provided schedule. Most ADS-R transmissions are of this type. In 

the uncommon case where a client and target are not served by a common radio, the SBS 

– Ground System will receive the ADS-B report from the receiving radio, and forward 

the report to the transmitting radio. 

A client aircraft that is receiving ADS-R service will receive reports for ADS-B aircraft 

on the opposite link within its vicinity. Since a single target may have multiple clients, 

sometimes in different domains, a client may receive ADS-R reports more frequently 

than required for the client’s domain. An aircraft may also be in range of a ground radio 

station that is transmitting reports required by other aircraft. When this is the case the 

client aircraft will receive reports of aircraft that are outside the altitude and horizontal 

range of its vicinity. 

The cumulative number of messages transmitted by all SBS – Ground System radio 

stations within reception range of any aircraft in the NAS will not exceed 1000 1090ES 

messages per second with received signal strength greater than -78 dBm. This limit 

applies to both the ADS-R and TIS-B Service combined. The cumulative maximum 

number of UAT messages received by an aircraft will not exceed 400 messages per 

second with received signal strength greater than -82 dBm. 

3.1.4.2.2.1 TIS-B Service Concept of Operations 


The TIS-B service provides active ADS-B users with a low-latency stream of position 

reports of non-ADS-B equipped aircraft. TIS-B service is available in supported Service 

Volumes when there is both adequate surveillance coverage from non-ADS-B ground 

sensors and adequate Radio Frequency (RF) coverage from SBS – Ground System radio 

stations. The high level data flows supporting TIS-B service are illustrated in Figure 3- 

12 below. 

An aircraft or vehicle that is an active ADS-B user and is receiving TIS-B service is 

known as a TIS-B Client. A non-ADS-B equipped aircraft or vehicle that has its position 

transmitted in TIS-B reports is known as a TIS-B Target.

TIS‐B 

Non‐Equipped 

UAT 

FIS‐B 

Provider 

Radio 

Station 

Control 

Station 

FAA 

Uplink Uplink of of Surveillance Surveillance Data Data of of Non‐ADSB Non‐ADSB equipped equipped aircraft aircraft for for Aircraft Aircraft Situational Situational Awareness 

Awareness 

3.1.4.2.2.2 TIS-B Client Identification 

Figure 3-12: TIS-B Service Data Flow 

61 

1090ES 

The SBS – Ground System control station monitors the ADS-B received reports to 

identify TIS-B Client aircraft. In order to be considered a TIS-B Client, an aircraft must 

be ADS-B-OUT, must have produced valid position data within the last 30s to a SBS 

ground station, must be under surveillance of at least one secondary radar and must be 

ADS-B-IN on at least one link. The TIS-B Service Status message is provided to UAT 

clients to indicate TIS-B service availability; this is considered to be a key safety benefit. 

The SBS – Ground System monitors the received ADS-B reports to identify active ADS- 

B users, and the ADS-B-IN link technologies operating on the aircraft. 

Note: With respect to the user aircraft/vehicle (A/V) data links; ADS-B-OUT indicates 

the A/V can transmit ADS-B messages, ADS-B-IN indicates the A/V can receive 

service messages such as ADS-R and TIS-B. A dual data link equipped A/V can 

transmit and receive both 1090ES and UAT services. 

© 20xx, RTCA, Inc.

62 

TIS-B client identification is provided by the ADS-B Report Generation, Processing, and 

Distribution function shown in Figure 3-10 Control Segment block and sent to the TIS-B 

Track Report Processing and Scheduling function (User Status and Validation). The 

identification information contained in the “User Status and Validation” message 

includes: 



In addition the ADS-B Report Generation, Processing, and Distribution function provides 

the A/V’s: 

1. Position data 

2. Altitude 

3. Validation Status 

A/V validation is referring to the capability of the SBS Control Station Segment 

providing an independent validation of the position information received in the ADS-B 

Messages. In certain Service Volumes, the FAA will require that the ADS-B Service 

provide independent validation. The validation capability may assure to a specified 

probability that each ADS-B Message, and the position information contained within, is 

from a real aircraft/vehicle with a valid position source rather than from a source 

broadcasting erroneous information or a spoofer. The validation methods are: 

1) Comparison of ADS-B position data to radar position data 

2) Comparing a one way “passive range” with range to target indicated by ADS-B 

position data (available for UAT equipped targets), and 

3) Use of time difference of arrival techniques. 

3.1.4.2.2.3 TIS-B Target Identification 


The SBS – Ground System monitors surveillance information from the FAA; the 

surveillance data is correlated and merged from multiple surveillance sources into 

individual aircraft tracks. Aircraft tracks that cannot be correlated with an active ADS-B 

user track are potential TIS-B Targets. 

The Multi-Sensor Tracker (MST) function is shown in Figure 3-10. The MST receives 

FAA sensor data from external sources and ADS-B messages from the ADS-B Report 

Generation, Processing and Distribution function. The MST establishes tracks from 

position data received. Track correlations are attempted with each position update of a 

track. FAA surveillance sensor tracks that cannot be correlated with ADS-B established 

tracks are candidate TIS-B targets. 

Each ATCRBS and Mode S aircraft track identified by the tracker is assigned a unique 

ID when a 24-Bit address is unavailable for that target. When an ICAO address is

available for a Mode S track (typically only in the surface service volumes), then this 

address is provided in the TIS-B messages. The SBS – Ground System has multiple 

trackers, deployed regionally such that there is an airborne tracker dedicated to the 

airspace of each FAA Enroute Center/Terminal Area. There is no correlation of track IDs 

between trackers, so as a TIS-B Target transitions across Service Volume boundaries 

between Enroute Centers, its Track ID will change, which may cause duplicate symbols 

to overlap while the old track ID times out on a CDTI. The avionics may need to be 

aware of the potential for track ID changes and perform correlation and association 

processing to associate aircraft across the track ID change in order to minimize duplicate 

symbols and perception of dropped tracks. 

When ADS-R services are not offered in an airspace, the TIS-B service provides Client 

ADS-B equipped aircraft with proximity targets that are ADS-B equipped on the opposite 

link technology. 

3.1.4.2.2.4 TIS-B in Enroute and Terminal Airspace Domains 

The SBS – Ground System examines each potential TIS-B target to determine if it is 

within proximity of one or more TIS-B clients. In order to become a TIS-B target, a 

potential target must be contained in a cylinder defined by lateral and vertical distance 

from Client aircraft. The size of this cylinder depends on the airspace domain of the 

Client aircraft. TIS-B Service is provided to aircraft operating in the En Route and 

Terminal Service Volumes. There is a Service Ceiling of 24,000 feet, above which TIS- 

B clients will not be provided TIS-B service. 

In the En Route and Terminal domains, proximity aircraft include all aircraft within a 15 

NM radius and ±3500 feet of altitude. Aircraft or vehicles determined to be operating on 

the surface will not be considered valid TIS-B targets for aircraft operating in En Route 

and Terminal Service Volumes. 

Figure 3-13: TIS-B Client Proximity Determination 


63

64 

3.1.4.2.2.5 TIS-B in Surface Domains 

In a surface domain SV, a client is provided all applicable TIS-B targets in SV domain. 

This includes all targets in the ground state within the movement area as well as airborne 

targets within 5 NM and 2000 feet AGL of the airport reference point (ARP). 

Additionally, TIS-B in surface domains covers expanding volumes along the approach 

and departure corridors. 

3.1.4.2.2.6 Transmission of TIS-B Target Messages 

The SBS – Ground System transmits TIS-B reports for every TIS-B Target that is in 

proximity of one or more Clients. An individual Target may be in proximity of multiple 

Clients, with the potential for the Clients to be in separate airspace domains, with 

differing update rates. The SBS – Ground System will transmit TIS-B reports for a Target 

aircraft at the highest rate required by any of the clients of that aircraft. For example, if a 

Target aircraft has clients in both terminal and en route domains, TIS-B reports for that 

Target aircraft will be transmitted at the rate required for the terminal domain. 

The cumulative number of messages transmitted by all SBS – Ground System radio 

stations within reception range of any aircraft in the NAS will not exceed 1000 1090ES 

messages per second with received signal strength greater than -78 dBm. This limit 

applies to both the ADS-R and TIS-B Service combined. The cumulative maximum 

number of UAT messages received by an aircraft will not exceed 400 messages per 

second with received signal strength greater than -82 dBm. 

3.1.4.3 TIS-B and ADS-R Subsystem Requirements 

3.1.4.3.1 TIS-B Service Messages and Performance Requirements 

TIS-B is an Essential service as defined by the SBS Essential Services Specification. The 

TIS-B Service provides users equipped with ADS-B Out and In avionics the ability to 

receive, process, and display state information on proximate traffic that are not ADS-B 

equipped and are only tracked by other ground-based surveillance systems (i.e., radar and 

multilateration systems). The performance that is required in delivering the TIS-B 

Service is detailed in following paragraphs. 

3.1.4.3.1.1 TIS-B Information Units –Message Content 


The 1090 TIS-B Service shall deliver and encode the TIS-B Message types contained in 

Table 1 and their corresponding message elements per RTCA DO-260B §2.2.17 and 

§A.2. 

TIS-B Velocity Messages shall be transmitted for Surface targets in order to convey the 

NACP to ADS-B-IN users for surface applications (although velocity data is ZERO’d 

out). 

The 1090 TIS-B Downlink Format (DF) shall be 18 and the Control Field shall be either 

set to 2 (target with ICAO address) or 5 (target with track file identifier).

Three squitters (even position, odd position, and velocity) shall be sent for every TIS-B 

report sent over the 1090 link. These transmissions are sent as a group, close together in 

time (as specified in §3.1.4.3.1.2.8), and if necessary will be repeated to ensure 

probability of detection. 

The 1090 TIS-B/ADS-R Service Status message format is defined in RTCA DO-317A 

and shall be broadcast for 1090 ADS-B-IN Link Version 2 clients. 

Table 3.1.4.3.1.1a: Transmitted 1090 TIS-B Message Types 

Message Types 

RTCA DO-260B 

Reference Paragraphs 

TIS-B Fine Airborne Position §2.2.17.3.1 & §A.2.4.1 

TIS-B Fine Surface Position §2.2.17.3.2 & §A.2.4.2 

TIS-B Velocity §2.2.17.3.4 & §A.2.4.4 

TIS-B/ADS-R Service Status 

Management 

§2.2.17.2 & §A.2 


65

66 

TIS-B 

Message 

All 

TIS-B Fine Airborne Position 

TIS-B Fine Surface Position 

TIS-B Velocity 


Table 3.1.4.3.1.1b: Payload Composition of 1090ES TIS-B Messages 

Encoding Used TIS-B Message Field 

MSG 

Bit # 

DO-260B 

Reference 

Set to decimal 18 (10010) for all TIS-B Messages DF TYPE 1-5 §2.2.17.2.1 

“2” for Fine TIS-B Message with AA=24-bit ICAO 

address and “5” for Fine TIS-B Message with 

AA=TIS-B Service generated 24-bit track ID 

A 24-bit address; ICAO address or service generated 

track ID 

Algorithm that operates on the first 88 bits of the 

message 

Control Field (CF) 6-8 §2.2.17.2.2 

Address Announced (AA) 9-32 §2.2.17.2.3 

Parity / Identity (PI) 89-112 §2.2.3.2.1.7 

Determined from altitude type and NIC TYPE 33-37 §2.2.3.2.3.1 

Set to 00 for all TIS-B Messages Surveillance Status 38-39 §2.2.3.2.3.2 

“0” to indicate a 24 bit address 

Note: This flag is always set to 0 since Mode 3/A 

code is not allowed to be embedded in the 24-bit 

address 

ICAO Mode Flag (IMF) 40 §2.2.17.3.1.2 

12 bits of barometric altitude data. Pressure Altitude 41-52 §2.2.3.2.3.4.1 

Set to ZERO Reserved 53 - 

Transmit Function to alternate between “0” = even; 

“1” = odd. 

CPR Format 54 §2.2.3.2.3.6 

CPR encoded Latitude and Longitude of target CPR Latitude 55-71 §2.2.3.2.3.7 

position. CPR Longitude 72-88 §2.2.3.2.3.8 

Determined from altitude type and NIC TYPE 33-37 §2.2.3.2.4.1 

Ground Speed of target on surface (Note: the 

movement field is different in DO-260B) 

Movement 38-44 §2.2.3.2.4.2 

Validity of heading/ground track Heading Status 45 §2.2.3.2.4.3 

Ground Track/Heading of target on surface Heading 46-52 §2.2.3.2.4.4 

“0” to indicate 24 bit ICAO address ICAO Mode Flag 53 §2.2.17.3.1.2 

Transmit Function to alternate between “0” = even; 

“1” = odd. 

CPR Format 54 §2.2.3.2.4.6 

CPR encoded Latitude and Longitude of target 

Latitude 55-71 §2.2.3.2.4.7 

position. Longitude 72-88 §2.2.3.2.4.8 

Set to 19 (10011) for all Velocity Messages TYPE 33-37 §2.2.3.2.6.1.1 

Determined based on availability of data on target 

velocity over ground and whether target is supersonic 

Subtype 38-40 §2.2.3.2.6.1.2 

“0” to indicate 24 bit ICAO address ICAO Mode Flag 41 §2.2.17.3.1.2 

TIS-B Service generated NACP value NACP 42-45 §2.2.17.3.4.4 

Velocity data on 

target 

(Always set to 

ZEROs for Surface 

Targets) 

Subtype 1& 2 

All Subtypes 

E/W Direction 46 §2.2.3.2.6.1.6 

E/W Velocity 47-56 §2.2.3.2.6.1.7 

N/S Direction 57 §2.2.3.2.6.1.8 

N/S Velocity 58-67 §2.2.3.2.6.1.9 

Vertical Rate Source 

(GEO Flag) 

68 §2.2.3.2.6.1.10 

Vertical Rate Sign 69 §2.2.3.2.6.1.11 

Vertical Rate 70-78 §2.2.3.2.6.1.12

TIS-B 

Message 

Encoding Used 

Based on position TYPE codes and integrity 

containment radius for target position 

TIS-B Message Field 

MSG 

Bit # 

Always set to “0” NACV 80-82 

For Messages with 

GEO Flag = 0 

For Messages with 

GEO Flag = 1 

DO-260B 

Reference 

NIC Supplement 79 §2.2.17.3.4.3 

Configured Value SIL 83-84 

Set to decimal 0 (0000) Reserved 85-88 

Set to 0 Reserved 80 

Based on altitude difference Diff from Baro. Alt Sign 81 

between barometric 

geometric sources 

and 

Diff. from Baro. Alt. 82-88 

§2.2.3.2.6.1.14 

§2.2.3.2.6.1.15 

UAT TIS-B Messages shall transmit only a “long” (Payload Type code 1) message. 

The UAT TIS-B Address Qualifier shall either be set to 2 (target with ICAO address) or 

3 (target with track file identifier). When the UAT Address Qualifier is 2, there are no 

other fields which convey whether the message is TIS-B or ADS-R. 

Table 3.1.4.3.1.1c: Payload Composition of UAT TIS-B Messages 

Encoding TIS-B Message Field 

RTCA 

DO-282B 

Reference 

Always Encode as ONE “PAYLOAD TYPE CODE” §2.2.4.5.1.1 

Encoded based on address type available 

consistent with referenced section of DO-282B 

“ADDRESS QUALIFIER” §2.2.4.5.1.2 

A 24-bit ICAO address, or service-generated 

“ADDRESS” 

track ID number 

§2.2.4.5.1.3 

Encoded consistent with referenced section of “LATITUDE” 

DO-282B §2.2.4.5.2.1 

“LONGITUDE” 

Encode as ZERO if Pressure Altitude data is 

and 

§2.2.4.5.2.1 

available; otherwise encode as ONE if the 

“Geometric Altitude” data is available 

“ALTITUDE TYPE” §2.2.4.5.2.2 

Pressure Altitude if available, 

Geometric Altitude if available. 

otherwise 

“ALTITUDE” §2.2.4.5.2.3 

Encoded based on determined NIC value 

“NIC” §2.2.4.5.2.4 

Service generated and encoding consistent with 

DO-282B §2.2.4.5.2.5 

Service generated and encoding consistent with 

DO-282B §2.2.4.5.3.1, excluding a value of 

“0000”. 

Encoded per relevant section of DO-282B when 

data available 

“A/G STATE” §2.2.4.5.2.5 

“HORIZONTAL 

VELOCITY” 

§2.2.4.5.2.6 

“VERTICAL VELOCITY” §2.2.4.5.2.7 

“TIS-B SITE ID” §2.2.4.5.3.1 

“EMITTER CATEGORY 

AND CALL SIGN 

CHARACTERS #1 AND #2” 

67 

§2.2.4.5.4.1, 

§2.2.4.5.4.2 

© 20xx, RTCA, Inc.

68 

Encode as UNKNOWN 


Encoding TIS-B Message Field 

“CALL SIGN 

CHARACTERS #3, #4 AND 

#5” 

“CALL SIGN 

CHARACTERS #6, #7 AND 

#8” 

“EMERGENCY/PRIORITY 

STATUS” 

RTCA 

DO-282B 

Reference 

§2.2.4.5.4.2 

§2.2.4.5.4.2 

§2.2.4.5.4.4 

Encode as TWO “UAT MOPS VERSION” §2.2.4.5.4.5 

Configured Value “SIL” §2.2.4.5.4.6 

The 6 LSBs of the MSO selected for this TIS-B 

“TRANSMIT MSO” §2.2.4.5.4.7 

Message 

Set to “2” “SDA” §2.2.4.5.4.8 

Encoded consistent with DO-282B §2.2.4.5.4.9 “NACP” §2.2.4.5.4.9 

Always encode as ZERO “NACV” §2.2.4.5.4.10 

Always encode as ZERO 

Always encode as: 

“NICBARO” §2.2.4.5.4.11 

- CDTI Traffic Display Capability: NO 

“CAPABILITY CODES” §2.2.4.5.4.12 

- TCAS/ACAS Installed and Operational: YES 

Always encode as ALL ZERO “OPERATIONAL MODES” §2.2.4.5.4.13 

Always encode as ZERO “TRUE/MAG” §2.2.4.5.4.14 

Always encode as ONE “CSID” §2.2.4.5.4.15 

Always encode as ONE “SILsupp” §2.2.4.5.4.16 

Always encode as ZERO “GVA”, “SA Flag”, and 

Encoded based on determined NIC value “NICsupp” §2.2.4.5.4.19 

Always encode as ZERO Reserved §2.2.4.5.4.20 

At airports with both Secondary Surveillance Radar (SSR) and multilateration systems, 

the ground infrastructure should sustain the TIS-B track ID or Mode S address for TIS-B 

target aircraft as they transition from a surface service volume (

The TIS-B/ADS-R Service Status message shall be broadcast such that each client will 

receive this message with their 24-bit address with an update interval of 20 seconds 

(95%). 

The TIS-B/ADS-R Service Status message shall only be provided to clients that are 

eligible for both TIS-B and ADS-R service. 

Notes: 

1. An aircraft or vehicle that is an active ADS-B user and is receiving ADS-R service is 

known as an ADS-R Client. 

2. TIS-B is deployed as a client-oriented service and provides near-by traffic 

information to ADS-B equipped aircraft. TIS-B service area is a cylinder centered 

on the client. TIS-clients are determined based on the set of ADS-B reports received 

by the SBSS Radio Stations. 

3.1.4.3.1.2.1 TIS-B Integrity and Accuracy: 

The probability that TIS-B Service introduces any error into a TIS-B Message shall be 

less than or equal to 10 -5 per Message (equivalent to a System Design Assurance level of 

2 – Major). This probability of error includes the linear position extrapolation process 

using the instantaneous velocity reported for a target. 

The Source Integrity Level (SIL) is a SBS system-wide configured value that shall be 

provided by TIS-B service. 

The Navigation Integrity Category (NIC) shall be computed for TIS-B messages based 

on the configured SIL value, the target’s NACP (described below), and the containment 

error ‘tail’ based on radar plot error measurements and specified performance values. 

Radar PARROTs and Certification Targets will be monitored for faults and excessive 

biases such that the sensors are not used when a fault is detected. 

The SIL supplement shall be encoded as 1 to indicate that the probability of a TIS-B 

target exceeding the NIC containment radius is calculated on a per sample basis. 

Although the SDA and SIL supplement are not transmitted over the 1090ES link, they 

shall assume to be “2” and “1”, respectively, to coincide with the design of the service. 

TIS-B reports shall be sent with a NACV. The NACV will typically be 0 unless a value 

>=1 can be calculated from the supporting sensors. 

The TIS-B Service shall reference a target’s barometric pressure altitude to standard 

temperature and pressure. 

The TIS-B Service shall compute a NACP, as defined in Table 3.2.11a, for each target at 

each track state vector update. For the applications supported by TIS-B, Navigation 

Accuracy Category - Position (NACP) is limited to the horizontal position information. 

NACP for a TIS-B target is based on the surveillance sources used to derive the target 

position rather than navigation sources used to supply ADS-B position. Therefore, the 

derivation of NACP for TIS-B is different from that for ADS-B. For example, the NACP 


69

70 

Central 

Sensor 

Short Range 

Sensor 

(ATCBI-5) 

Long Range 

Sensor 

(ATCBI-5) 

value must include the uncertainty in converting slant range measurements to horizontal 

position estimates. 

TIS-B Track angle and position accuracy in the for surface targets shall be provided by 

TIS-B service. 

The TIS-B Service shall set the Track Angle to Invalid when the target ground speed 

drops below a defined threshold (currently set to 11.84 Knots) 

In En Route and Terminal environments the track accuracy shall meet or exceed the 

values shown in Table 3.1.4.3.1.2.1. 

Flight Path 

Linear 

Acceleration† 

180° 

Speed 

(kts) 

Table 3.1.4.3.1.2.1: Requirements for Track Accuracy 

Rng. 

(NM) 

Position Error (NM) Heading Error (°) 

Peak 

RMS 

Position 

Error 

Mean 

Position 

Error 

Peak 

RMS 

Heading 

Error 

Mean 

RMS 

Heading 

Error 

Speed Error 

(kts) 

Peak 

RMS 

Speed 

error 

650- 

>250- 

Center 0.4 13 37 

>650 All 0.6 19 60 

100 48 0.4(0.4+) 97 (70+) 20 (10+) 

250-700 (case 3) 

50*** 

0.4(0.4+) 32 (30+) 20 (10+) 

700*** 

Mean 

RMS 

Speed 

error 

Radial 100 0.1 (0.1#) 7 (2#) 5 (4#) 

Tangential 100 (case 2) 0.1 (0.1#) 5 (5#) 9 (7#) 

Linear 

Acceleration† 

650- 

>250- 

>650 

n/a 0.5 13 60 

90° turn 100-400 84 1.1 (0.4+) 70 (38+) 60+ 

(case 2) 1.8 (0.4+) 34 (14+) 54 (14+) 

Radial 100-700 100 0.5 11 

Tangential 100-700 80 0.4 7 15 

Notes: 


1. Table symbology: 

† These scenarios were generated and the values in this table are based on best 

engineering judgment. 

+ These multisensor cases use existing scenarios (because they are not spatially 

distributed). 

# These multisensor cases use a single target path from existing scenarios and are run 

multiple times through the standalone filter algorithm, with independent noise 

generated each time (i.e., run Monte Carlo iterations).

3.1.4.3.1.2.2 TIS-B Position Update Interval: 

The TIS-B Service updates target position and velocity data based on surveillance 

measurement events and is therefore dependent on the availability of source sensors for 

new data. The following specifications apply only when sensor data is available to the 

TIS-B Service to support the performance requirements. Under lightly-loaded conditions 

the TIS-B service may transmit reports at a rate higher than the minimum specified rate. 

Graceful Degradation algorithms are implemented which will throttle transmissions back 

to the required update rate as the system becomes more loaded. Sometimes it will be 

necessary to transmit the same report multiple times in order to ensure the required 

update rate and probability of detection. 

The maximum message transmission rate for a TIS-B Target to a 1090 and UAT clients 

shall be 1 time per second (this is the expected rate for targets in Surface Service 

volumes where ASDE-X sends track updates at approximately 1 Hz). 

Each 1090 TIS-B message packet shall consist of 2 position messages and 1 velocity 

message (both surface and airborne targets). 

Note: All of the 1090 TIS-B messages in the packet will be transmitted within 

milliseconds of each other. 

The expected minimum power received by UAT avionics is -93 dBm. The TIS-B link 

margin for UAT clients shall be > 3 dB for at least 95% of the time for throughout the 

SV airspace. 

The expected minimum power received by 1090 avionics is -79 dBm in low interference 

environments and -72 dBm in high interference environments. The TIS-B link margin 

for 1090 clients shall be > 3 dB for at least 95% of the time for throughout the SV 

airspace. 

3.1.4.3.1.2.3 Surface Update Interval: 

The TIS-B Service shall transmit the number of TIS-B Messages necessary to meet an 

update interval of no greater than 2 seconds (95%) for each client aircraft for all traffic 

within 5 NM and within +/-2000 feet of each client within the Surface Service Volume. 

3.1.4.3.1.2.4 Terminal Update Interval: 



within 15 NM and within +/-3500 feet of each client within the Terminal Service 

Volume. 

Airborne TIS-B targets in a Surface SV shall also be provided to clients in a terminal SV. 

Ground state TIS-B targets shall not be provided to clients in terminal SV. 


71

72 

3.1.4.3.1.2.5 En-Route Update Interval: 


update interval of no greater than 12.1 seconds (95%) for each client aircraft for all traffic 

within 15 NM and within +/-3500 feet of each client within the En-Route Service 

Volume. 

3.1.4.3.1.2.6 TIS-B Latency: 

The latency for TIS-B Service processing of TIS-B data shall be less than 1.5 seconds as 

measured from the Ground System Surveillance Sensor interface (see Figure 1-1) to the 

start of the TIS-B Message transmission. 

Overall end-to-end latency from sensor measurement to start of the TIS-B transmission 

shall be less than 3.25 seconds. 

This requirement applies to services delivered to the airport surface, terminal airspace and 

en route airspace. There is an allocation of 3.25 s from sensor measurement to TIS-B 

Message transmission. The expected maximum delay associated with getting target 

measurements from a radar sensor is 1.725 s, leaving the balance of time to the TIS-B 

Service. 

The Ground Surveillance Sources Interface to TIS-B transmission latency shall be 

compensated in the TIS-B horizontal position by linearly extrapolating to the time of 

transmission. 

Note: It is expected that a Ground Station would be capable of determining the time of 

transmission of a TIS-B message to within 100 ms. 

The TIS-B Service shall not introduce any additional position error to that which might 

otherwise be introduced by a linear extrapolation using the instantaneous velocity 

provided for the target. 

3.1.4.3.1.2.7 TIS-B Service Availability: 

The TIS-B service is a safety-essential service as classified by NAS-SR-1000A for 

surveillance services. The availability of the TIS-B Service specified in this section is 

limited to the SBS system. It includes the ADS-B Receive Function, but does not include 

FAA surveillance sensors providing sensor data. The TIS-B Service shall meet a 

minimum Availability of 0.999 for the TIS-B Clients. 

3.1.4.3.1.2.8 TIS-B Media Access: 


1090 TIS-B transmissions contend with air-to-air 1090 ADS-B transmissions and 

potentially with nearby SBS Ground Station 1090 transmissions. TIS-B 1090 

transmissions shall be randomized to minimize interference. 

UAT TIS-B transmissions contend with air-to-air UAT ADS-B transmissions since they 

are in the ADS-B segment of the UAT Frame (not the Ground Segment) and potentially 

with nearby SBS Ground Station UAT transmissions.

UAT transmissions shall be randomized to minimize interference. 

Although TIS-B transmissions are event-driven by receptions of radar/Airport Surface 

Surveillance Capability (ASSC) System updates, both 1090 and UAT shall have 

configurable minimum TIS-B transmit intervals (nominally set to 2 ms) with an added 

random time (up to nominally 3 ms) appended to the minimum interval. Additionally, 

typically only one Ground Station uplinks a particular target at any given time. 

Note: These transmit parameters are set in consideration of maximum capacity, update 

interval, and interference environment requirements for each Ground Station. 

3.1.4.3.2 ADS-R Service Messages and Performance 

The ADS-R Service is dependent upon the ADS-B Service, in that the ADS-B Messages 

are first received on one data link before they can be rebroadcast on the other. The 

performance that is required in delivering the ADS-R Service is detailed in following 

paragraphs. 

3.1.4.3.2.1 ADS-R Information Units –Message Content 

UAT ADS-R Targets to 1090 Clients: 

The ADS-R Service for 1090 Clients shall encode the Message types contained in Table 

5 and their corresponding message elements per RTCA DO-260B §2.2.18 and §A.3. 

If a UAT Target has an emergency condition (as indicated in its ADS-B message), then 

ADS-R shall also broadcast the 1090 Aircraft Status Subtype 1 message for that Target 

during the course of the emergency. 

The 1090 ADS-R Downlink Format shall be 18 and the Control Field shall be set to 6. 

The ADS-R service shall set the ICAO/Mode A Flag field in the position messages to 

denote whether the target has an ICAO address. 

Table 3.1.4.3.2.1: 1090ES ADS-R Message Types to Encode Upon Receipt of UAT 

Message Types 

1090ES Message Type 

0 1 

UAT Message Payload Type 

2 3 4 5 6 

Position X X X X X X X 

Aircraft ID and Category X X 

Velocity X X X X X X X 

Operational Status X X 

Aircraft Status: Subtype 1 

(Only during emergencies) 

X X 

1090 ADS-R Targets to UAT Clients: 


73

74 

The ADS-R Service for UAT Clients shall broadcast “long” (Payload Type code 1) 

messages. 

The UAT ADS-R Address Qualifier shall be set to either 2 (target with ICAO address) or 

6 (target with non-ICAO address). When the UAT Address Qualifier is 2, there are no 

other fields which convey whether the message is TIS-B or ADS-R. 

3.1.4.3.2.2 Quality of Service 

3.1.4.3.2.2.1 ADS-R Integrity and Accuracy: 

The probability that ADS-R Service introduces any error into a rebroadcast ADS-B 

Message shall be less than or equal to 10-5 per Message (equivalent to a System Design 

Assurance level of 2 – Major). This probability of error includes the linear position 

extrapolation process using the instantaneous velocity reported for a target on the 

opposite ADS-B data link. 

3.1.4.3.2.2.2 ADS-R Position Update Interval: 


The ADS-R Service shall broadcast state vector updates for aircraft/vehicles transmitting 

on one data link to aircraft/vehicles on the other data link at an interval that will support 

the aircraft/vehicle based applications that are to be performed in the Service Volume. 

The state vector update intervals required to support each application are detailed in the 

SBS CONOPS and summarized as follows: 

• Traffic Situation Awareness – Basic (12.1 seconds) 

• Airport Traffic Situation Awareness (2 seconds) 

• Airport Traffic Situation Awareness with Indications and Alerts (2 seconds) 

• Traffic Situation Awareness for Visual Approach (5 seconds) 

• Traffic Situation Awareness with Alerts (10 seconds) 

• Flight-Deck Based Interval Management–Spacing (10 seconds) 

The ADS-R update interval requirements is based upon the most stringent application 

that is to be supported within each domain. The update intervals apply to the reception 

by a client aircraft of all eligible ADS-R aircraft/vehicles within the range and altitude 

limits at any point within the Service Volume. Thus, the 1090 interference environments 

need to be considered to meet the update intervals. 

Note: The ADS-R update interval is limited by the ADS-B Message reception rate from 

each aircraft/vehicle (as rebroadcasts may be made only when Messages are 

received), the UAT uplink capacity, spectrum restrictions for 1090ES, the 

performance characteristics of the aircraft/vehicle ADS-B equipment, and the 

interference environment.

The nominal message transmission rate for a 1090 Target ADS-R to a UAT client is 2 

times per second since a Ground Station will receive a 1090 position message 

approximately every 0.5 seconds. 

The expected minimum power received by UAT avionics is -93 dBm. The ADS-R link 

margin for UAT clients shall be > 3 dB for at least 95% of the time throughout the SV 

airspace. 

The nominal message packet transmission rate for a UAT Target ADS-R to a 1090 client 

is 1 time per second since a Ground Station will receive a UAT message approximately 

every 1 second. 

A typical 1090 ADS-R message packet shall consist of 2 position messages, 1 Aircraft 

ID and Category message, 1 Velocity message (if airborne), and 1 Operational Status 

message. 

Notes: 

1. All of the 1090 ADS-R messages in the packet should be transmitted within 

milliseconds of each other. 

2. If an aircraft is reporting an emergency condition, ADS-R will also rebroadcast the 

Emergency Status message for that aircraft during that event. 

The expected minimum power received by 1090 avionics is -79 dBm in low interference 

environments and -72 dBm in high interference environments. The ADS-R link margin 

for 1090 clients shall be > 3 dB for at least 95% of the time throughout the SV airspace. 

As the system becomes loaded with more than 250 ADS-R targets on each link, these 

target message transmission rates shall decrease in a process known as Graceful 

Degradation. The purpose of Graceful Degradation (GD) is to gradually throttle the 

ADS-R messages sent to Aircraft/Vehicles based on load. The GD algorithm uses 

several configurable parameters to control the flow of reports and messages until the 

maximum load is reached. As the Ground Station nears its configured target capacity, the 

per-target minimum transmit interval increases gradually until reaching a minimum rate 

of transmission for each target to support the service volume update interval. 

3.1.4.3.2.2.3 Surface Update Interval: 

The ADS-R Service shall transmit the number of ADS-R Messages necessary to meet an 


within 5 NM and within +/-2000 feet of each client within the Surface Service Volume. 

3.1.4.3.2.2.4 Terminal Update Interval: 



within 15 NM and within +/-5000 feet of each client within the Terminal Service 

Volume. 


75

76 

3.1.4.3.2.2.5 En-Route Update Interval: 



within 15 NM and within +/-5000 feet of each client within the En-Route Service 

Volume. 

3.1.4.3.2.2.6 ADS-R Latency: 

The additional latency introduced by the ground infrastructure shall be less than the 

latency required by the most stringent applications in the SBS CONOPS minus the 

inherent airborne latencies on both ends. 

The maximum delay between the time of message received of an ADS-B Message that 

results in the generation of ADS-R Uplink Messages and the transmission of the first bit 

of any corresponding broadcast Message on the opposite link technology shall be less 

than or equal to 1 second. 

The ADS-B to ADS-R transmission latency shall be compensated in the ADS-R 

horizontal position by linearly extrapolating to the time of transmission. 

Note: It is expected that a Ground Station would be capable of determining the time of 

transmission of an ADS-R message to within 100 ms. 

The ADS-R Service shall not introduce any additional position error to that which might 

otherwise be introduced by a linear extrapolation using the instantaneous velocity 

reported for the target on the other ADS-B data link. 

3.1.4.3.2.2.7 ADS-R Service Availability: 

The ADS-R service is currently a safety-essential service as classified by NAS-SR- 

1000A for surveillance services. The ADS-R Service shall meet a minimum Availability 

of 0.999 at SDPs (in this case, SDP refers to client aircraft that are receiving ADS-R). 

Note: The ADS-R service should be capable of being enhanced to meet a minimum 

availability of 0.99999 for Safety Critical applications. 

3.1.4.3.2.3 ADS-R Media Access: 


1090 ADS-R transmissions contend with air-to-air 1090 ADS-B transmissions and 

potentially with nearby SBS Ground Station 1090 transmissions. 

1090 ADS-R transmissions shall be randomized to minimize interference. 

Note: On a target basis, 1090 ADS-R should trigger on UAT ADS-B receptions which 

are generated on a pseudo-random basis per the MOPS. Each Ground Station 

would randomize its transmit intervals independently of other Ground Stations. 

UAT ADS-R transmissions contend with air-to-air UAT ADS-B transmissions since they 

are in the ADS-B segment of the UAT Frame (not the Ground Segment) and potentially 

with nearby SBS Ground Station UAT transmissions.

UAT transmissions shall be randomized to minimize interference. 

Note: On a target basis, UAT ADS-R should trigger on 1090 ADS-B position message 

receptions which are generated on a pseudo-random basis per the link MOPS. 

Each Ground Station would randomize its transmit intervals independently of 

other Ground Stations. 

Although ADS-R transmissions are event-driven by receptions of ADS-B messages, both 

1090 and UAT shall have configurable minimum ADS-R transmit intervals (nominally 

set to 2 ms) with an added random time (up to nominally 3 ms) appended to the minimum 

interval. Additionally, typically only one Ground Station rebroadcasts a particular target 

at any given time. 

Note: These transmit parameters are set in consideration of maximum capacity, update 

interval, and interference environment requirements for each Ground Station. 

3.1.5 Surface Vehicles 

Surface vehicles include those that tow and service aircraft, load cargo and transport 

passengers, and emergency vehicles. ADS-B enables properly equipped ground vehicles 

to broadcast their state vector, horizontal and vertical position, horizontal and vertical 

velocity, and other information. These ADS-B Message broadcasts are received by 

aircraft in the vicinity and by ground surveillance systems, including those that directly 

use the ADS-B information content and those that use multilateration techniques to 

derive position. Aircraft equipped with the proper equipment receive the ADS-B 

Messages, process and display the information for use in air-to-air applications, air-toground 

applications, and ground-to-ground applications. 

The vehicle ADS-B transmitting systems are intended to support the following ADS-B 

applications: 

- Air Traffic Control (ATC) Surveillance for Airport Situational Awareness 

- Airport Traffic Situational Awareness 

- Airport Traffic Situational Awareness with Indications and Alerts 

Surface vehicles, because of spectrum restrictions, are generally limited to transmitting 

while in the airport movement area. The surface vehicle transmit power is reduced from 

aircraft equipage class transmit requirements because surface coverage area reduces the 

maximum operating range. However, it is necessary to provide a minimum range of 5 

NM to be detected and tracked by aircraft on approach to the airport. Surface vehicles 

are defined by the equipage Class B2 (see §3.1.1.3.2). If ADS-B link technologies 

support the use of lower power than the link requires for the minimum B2 equipage class, 

there needs to be an indication of this in the Mode Status information so that ADS-B 

receivers can identify these lower power vehicles. Position accuracy requirements for 

surface vehicles will typically be more demanding on surface vehicle ADS-B transmitters 

in order to support potential future surface applications. 


77

78 

3.2 Broadcast Information Elements Requirements 

The ADS-B system shall {242AR2.3} be capable of transmitting messages and issuing 

reports containing the information specified in the following subsections. These MASPS 

do not specify a particular message structure or encoding technique. The information 

specified in the following subparagraphs can be sent in one or more messages in order to 

meet the report update requirements specified in Section §3.4.3.3. 

3.2.1 Time of Applicability (TOA) 

3.2.2 Identification 

The time of applicability (TOA) of ADS-B reports indicates the time at which the 

reported values were valid. Time of applicability shall {242AR2.4} be provided in all 

reports. Requirements on the accuracy of the time of applicability are addressed in 

Section §3.4.3.3.2.2 and paraphrased in §3.5.1.3.3. 

Note: The required resolution of the Time of Applicability value is a function of the 

Report Type. 

The basic identification information to be conveyed by ADS-B shall {242AR2.5} 

include the following elements: 

� Call Sign / Flight ID (§3.2.2.1) 

� Participant Address (§3.2.2.2.1) and Address Qualifier (§3.2.2.2.2) 

� ADS-B Emitter Category (§3.2.2.3) 

� Mode 3/A Code (§3.2.2.4) 

3.2.2.1 Call Sign / Flight ID 

ADS-B shall {242AR2.6} be able to convey an aircraft Call Sign or Flight ID of up to 8 

alphanumeric characters in length [6]. For aircraft/vehicles not receiving ATS services 

and military aircraft the call sign is not required. 

Note: The call sign is reported in the Mode Status (MS) report (§3.5.4 and §3.5.4.4). 

3.2.2.2 Participant Address and Address Qualifier 


The ADS-B system design shall {242AR2.7} include a means (e.g., an address) to (a), 

correlate all ADS-B messages transmitted from the A/V and (b), differentiate it from 

other A/Vs in the operational domain. 

Those aircraft requesting ATC services may be required in some jurisdictions to use the 

same 24 bit address for all CNS systems. Aircraft with Mode-S transponders using an 

ICAO 24 bit address shall {242AR2.8} use the same 24 bit address for ADS-B. All

aircraft/vehicle addresses shall {242AR2.9} be unique within the applicable operational 

domain(s). 

The ADS-B system design shall {242AR2.10} accommodate a means to ensure 

anonymity whenever pilots elect to operate under flight rules permitting an anonymous 

mode. 

Notes: 

1. Some flight operations do not require one to fully disclose either the A/V call sign or 

address. This feature is provided to encourage voluntary equipage and operation of 

ADS-B by ensuring that ADS-B messages will not be traceable to an aircraft if the 

operator requires anonymity. 

2. Correlation of ADS-B messages with Mode S transponder codes will facilitate the 

integration of radar and ADS-B information on the same aircraft during transition. 

3. The TIS-B Service in the EnRoute and Terminal service volumes may use a Track ID 

value, rather than the ICAO 24-bit Address. 

3.2.2.2.1 Participant Address 

The Participant Address field shall {242AR2.11} be included in all ADS-B reports. This 

24-bit field contains either the ICAO 24-bit address assigned to the particular aircraft 

about which the report is concerned, or another kind of address that is unique within the 

operational domain, as determined by the Address Qualifier field. 

3.2.2.2.2 Address Qualifier 

The Address Qualifier field shall {242AR2.12} be included in all ADS-B reports. This 

field describes whether or not the Address field contains the 24-bit ICAO address of a 

particular aircraft, or another kind of address that is unique within the operational 

domain. 

Notes: 

1. The particular encoding used for the Address Qualifier is not specified in these 

MASPS, but is left for specification in lower level documents, such as the MOPS for a 

particular ADS-B data link. 

2. Surface vehicles for a given airport need to have unique addresses only within range 

of the airport; vehicle addresses may be reused at other airports. 

3. A participant’s address and address qualifier are included as parts of all reports 

about that participant. 


79

80 

3.2.2.3 ADS-B Emitter Category 

An ADS-B participant’s “emitter category” is conveyed in the Mode Status report (§3.5.4 

and §3.5.4.5). The emitter category describes the type of A/V or other ADS-B 

participant. The ADS-B system shall {242AR2.13} provide for at least the following 

emitter categories: 

� Light (ICAO) – 7,000 kg (15,500 lbs) or less 

� Small aircraft – 7,000 kg to 34,000 kg (15,500 lbs to 75,000 lbs) 

� Large aircraft – 34,000 kg to 136,000 kg (75,000 lbs to 300,000 lbs) 

� High vortex large (aircraft such as B-757) 

� Heavy aircraft (ICAO) – 136,000 kg (300,000 lbs) or more 

� Highly maneuverable ( > 5g acceleration capability) and high speed (> 400 knots 

cruise) 

� Rotorcraft 

� Glider/Sailplane 

� Lighter-than-air 

� Unmanned Aerial vehicle 

� Space/Trans-atmospheric vehicle 

� Ultralight / Hang glider / Paraglider 

� Parachutist/Skydiver 

� Surface Vehicle – emergency vehicle 

� Surface Vehicle – service vehicle 

� Point obstacle (includes tethered balloons) 

� Cluster obstacle 

� Line obstacle 

Notes: 


1. ICAO Medium aircraft – 7,000 to 136,000 kg (15,500 to 300,000 lbs) can be 

represented as either small or large aircraft as defined above. 

2. Obstacles can be either fixed or movable. Movable obstacles would require a 

position source. 

3. Weights given for determining participant categories are maximum gross weights, 

not operating weights.

3.2.2.4 Mode 3/A Code 

Since the Mode 3/A code is utilized by many Ground ATC systems for aircraft 

identification, it may continue to be necessary for ADS-B participants in certain airspace 

to transmit the Mode 3/A code. ADS-B shall {R3.xxx New Reqmt} have the capability 

to transmit the Mode 3/A code. 

3.2.3 A/V Length and Width Codes 

3.2.4 Position 

The A/V length and width codes describe the amount of space that an aircraft or ground 

vehicle occupies and are components of the Mode Status report (§3.5.4, §3.5.4.6). The 

aircraft length and width codes are not required to be transmitted by all ADS-B 

participants all of the time. However, they are required (§3.5.1.4.6) to be transmitted by 

aircraft above a certain size, at least while those aircraft are in the airport surface 

movement area. 

Position information shall {242AR2.14} be transmitted in a form that can be translated, 

without loss of accuracy and integrity, to latitude, longitude, geometric height, and 

barometric pressure altitude. The position report elements may be further categorized as 

geometric position and barometric altitude. 

� The geometric position report elements are horizontal position (latitude and 

longitude), and geometric height. All geometric position elements shall 

{242AR2.15} be referenced to the WGS-84 ellipsoid. 

� Barometric pressure altitude shall {242AR2.16} be reported referenced to standard 


For any ADS-B participant that sets the “reporting reference point position” CC code (in 

MS report element #7g, §3.5.4.9.7) to ONE, the position that is broadcast in ADS-B 

messages as that participant’s nominal position shall {242AR2.17} be the position of that 

participant’s ADS-B position reference point (§3.3.4.1 below). 

For any ADS-B participant that sets the “reporting reference point position” CC code (in 

MS report element #7g, §3.5.4.9.7) to ZERO, the position that is broadcast in ADS-B 

messages is not corrected from the position as given by the participant’s navigation 

sensor to the position of that participant’s ADS-B position reference point. 

Note: Surface movement and runway incursion applications will require high NACP 

values. To obtain those high values, it may be necessary to correct the reported 

position to that of the ADS-B Position Reference Point (§3.3.4.1) if the antenna 

of the navigation sensor is not located in very close proximity to the ADS-B 

reference point. 


81

82 

3.2.4.1 ADS-B Position Reference Point 


The nominal location of a transmitting ADS-B participant – the position that is reported 

to user applications in SV reports about that participant – is the location of the 

participant’s ADS-B Position Reference Point. 

Note 1: The “reporting reference point position” CC code (in MS report element #7g) 

indicates whether a transmitting ADS-B participant has corrected the position 

given by its navigation sensor (e.g., the position of the antenna of a GPS 

receiver) to the location of its ADS-B position reference point. (The process of 

correcting the position to that of the position reference point need not be done 

in the transmitting ADS-B subsystem; it might be applied in the navigation 

sensor, or in another device external to the ADS-B transmitting subsystem.) 

(See the description of MS report element #7g, §3.5.4.9.7) 

The ADS-B position reference point of an A/V shall {242AR2.18} be defined as the 

center of a rectangle (the “defining rectangle for position reference point”) that has the 

following properties: 

a. The defining rectangle for position reference point shall {242AR2.18-A} have 

length and width as defined in Table 3.2.4.1a below for the length and width 

codes that the participant is transmitting in messages to support the MS report. 

b. The defining rectangle for position reference point shall {242AR2.18-B} be 

aligned parallel to the A/V’s heading. 

c. The ADS-B position reference point (the center of the defining rectangle for 

position reference point) shall {242AR2.18-C} lie along the axis of symmetry of 

the A/V. (For an asymmetrical A/V, the center of the rectangle should lie 

midway between the maximum port and starboard extremities of the A/V.) 

d. The forward extremity of the A/V shall {242AR2.18-D} just touch the forward 

end of the defining rectangle for position reference point.

Table 3.2.4.1a: Dimensions of Defining Rectangle for Position Reference Point. 

A/V – L/W 

Code 

(Decimal) 

Length Code 

(binary) 

Width 

Code 

(binary) 

Upper-Bound Length and Width 

for Each Length/Width Code 

Length 

Width 

(meters) 

(meters) 

0 0 0 0 0 No Data or Unknown 

1 0 0 0 1 15 23 

2 

3 

0 0 1 

0 

1 

25 

28.5 

34 

4 

5 

0 1 0 

0 

1 

35 

33 

38 

6 

7 

0 1 1 

0 

1 

45 

39.5 

45 

8 

9 

1 0 0 

0 

1 

55 

45 

52 

10 

11 

1 0 1 

0 

1 

65 

59.5 

67 

12 

13 

1 1 0 

0 

1 

75 

72.5 

80 

14 

15 

1 1 1 

0 

1 

85 

80 

90 

Note 2: The lengths and widths given in Table 3.2.4.1a are least upper bounds for the 

possible lengths and widths of an aircraft that reports the given length and 

width code (§3.5.1.4.6). An exception, however, is made for the largest length 

and width codes, since there is no upper bound for the size of an aircraft that 

broadcasts those largest length and width codes. 


83

84 


Figure 3-14 illustrates the location of the ADS-B reference point, for an example aircraft 

of length 31 m and width 29 m. Such an aircraft will have length code 2 (L < 35 m) and 

width code 0 (W < 33m). The ADS-B position reference point is then the center of a 

rectangle that is 35 m long and 33 m wide and positioned as given in the requirements 

just stated. This is the position that a transmitting ADS-B participant broadcasts when 

the GPS Antenna Offset is compensated by the Sensor to be the position of the ADS-B 

position reference point (see §3.2.9.6). 

Actual 

aircraft 

length 

is 31 m 

Reported Width = 33 m 

Actual Aircraft width is 29 m 

The defining rectangle for the 

position reference point has 

the least-upper bound length 

and width (35 m and 33 m 

respectively) for the aircraft's 

length and width codes. This 

defining rectangle should touch 

the aircraft's forward end. 

The ADS-B position 

reference point is at the 

center of its defining 

rectangle. 

Center of larger rectangle 

(that is, ADS-B position 

reference point) lies on the 

centerline of the smaller, 

circumscribing rectangle 

(which is almost always the 

axis of symmetry of the 

aircraft). 

Figure 3-14: Position Reference Point Definition. 

Note 3: When on the surface, the ability to correct for inaccuracies because of offsets 

in position between the navigation sensor and the ADS-B position reference 

point must be provided. If the navigation sensor or the transmitting ADS-B 

participant does not correct for this offset, the lateral distance from the lateral 

axis of the aircraft and the longitudinal distance from the nose of the aircraft 

must be conveyed so that the ADS-B application can account for this offset. A 

Reported Length = 35 m

3.2.4.2 Altitude 

means to indicate that the position is corrected to the ADS-B reference point 

must be provided (see §3.2.9.6). 

Note 4: There are operational applications where the ADS-B position being reported 

needs to be related to the extremities of large aircraft; such as, runway 

incursion alerting and other future surface applications. Therefore, for the 

aircraft size codes and NACp codes defined, the position being broadcast must 

be translated to a common reference point on the aircraft. The translation 

calculation on position sensor source data may be performed outside of the 

ADS-B transmitting subsystem, therefore, specific requirements for this 

function are not defined in these MASPS. 

Both barometric pressure altitude and geometric altitude (height above the WGS-84 

ellipsoid) shall {242AR2.19} be provided, if available, to the transmitting ADS-B 

subsystem. Some applications may have to compensate if only one source is available. 

However, when an A/V is operating on the airport surface, the altitude is not required to 

be reported, provided that the A/V indicates that it is on the surface. 

Altitude shall {242AR2.20} be provided with a range from -1,000 feet up to +100,000 

feet. For fixed or movable obstacles, the altitude of the highest point should be reported. 

3.2.4.2.1 Pressure Altitude 

ADS-B link equipment shall {242AR2.21} support a means for the pilot to indicate that 

the broadcast of altitude information from pressure altitude sources is invalid. This 

capability can be used at the request of ATC or when altitude is determined to be invalid 

by the pilot. 

Barometric pressure altitude is the reference for vertical separation within the NAS and 

ICAO airspace. Barometric pressure altitude is reported referenced to standard 


Pressure altitude, which is currently reported by aircraft in SSR Mode C and Mode S, 

will also be transmitted in ADS-B messages and reported to client applications in SV 

reports. The pressure altitude reported shall {242AR2.22} be derived from the same 

source as the pressure altitude reported in Mode C and Mode S for aircraft with both 

transponder and ADS-B. 

3.2.4.2.2 Geometric Altitude 

Geometric altitude is defined as the shortest distance from the current aircraft position to 

the surface of the WGS-84 ellipsoid, known as Height Above Ellipsoid (HAE). It is 

positive for positions above the WGS-84 ellipsoid surface, and negative for positions 

below that surface. 


85

86 

3.2.5 Horizontal Velocity 

3.2.6 Vertical Rate 


There are two kinds of velocity information: 

� “Ground-referenced” or geometric velocity is the velocity of an A/V relative to a 

coordinate system that is fixed with respect to the earth. Ground-referenced velocity 

is communicated in the SV report (§3.5.1.3). 

� Air-referenced velocity (ARV) is the velocity of an aircraft relative to the air mass 

through which it is moving. Airspeed, the magnitude of the air-referenced velocity 

vector, is communicated in the ARV report, §3.5.1.6. The ARV report also includes 

heading (§3.5.1.6.6), which is used in that report as an estimate of the direction of the 

air-referenced velocity vector. Conditions for when the broadcast of ARV data is 

required are specified in §3.5.1.6.1. 

ADS-B geometric velocity information shall {242AR2.23} be referenced to WGS-84. 

Transmitting A/Vs that are not fixed or movable obstacles shall {242AR2.24} provide 

ground-referenced geometric horizontal velocity. 

Note: In this context, a “movable obstacle” means an obstacle that can change its 

position, but only slowly, so that its horizontal velocity may be ignored. 

Transmitting A/Vs that are not fixed or movable obstacles and that are not known to be 

on the airport surface shall {242AR2.25} provide vertical rate. 

Note 1: In this context, a “movable obstacle” means an obstacle that can change its 

position, but only slowly, so that its vertical rate may be ignored. 

Vertical Rate shall {242AR2.26} be designated as climbing or descending and shall 

{242AR2.27} be reported up to 32,000 feet per minute (fpm). Barometric altitude rate is 

defined as the current rate of change of barometric altitude. Likewise, geometric altitude 

rate is the rate of change of geometric altitude. At least one of the two types of vertical 

rate (barometric and geometric) shall {242AR2.28} be reported. 

If only one of these two types of vertical rate is reported, it shall {242AR2.29} be 

obtained from the best available source of vertical rate information. 

� Question: Is there a requirement to have vertical rate from the same source as the 

altitude broadcast?? � 

1. Inertial filtered barometric altitude rate will be the preferred source of altitude rate 

information. 

2. If differentially corrected GPS (WAAS, LAAS, or other) is available, geometric 

altitude rate as derived from the GPS source should be transmitted. 

3. If differentially corrected GPS is not available, unaugmented GNSS vertical rate 

should be used.

3.2.7 Heading 

4. Pure barometric rate. 

Note 2: Future versions of these MASPS are expected to include requirements on the 

accuracy and latency of barometric altitude rate. 

Note 3: Vertical rate is reported in the SV report (§3.5.1.3.16). 

Heading indicates the orientation of an A/V, that is, the direction in which the nose of the 

aircraft is pointing. Heading is described as an angle measured clockwise from true north 

or magnetic north. The heading reference direction (true north or magnetic north) is 

conveyed in the Mode Status report (§3.5.1.4). 

Heading occurs not only in the SV report (§3.5.1.3) for participants on the airport 

surface, but also in the ARV report (§3.5.1.6) for airborne participants. 

3.2.8 Capability Class (CC) Codes 

A transmitting ADS-B participant broadcasts Capability Class (CC) codes (§3.5.1.4.9) so 

as to indicate capabilities that may be of interest to other ADS-B participants. The 

subfields of the CC codes field are described in the following subparagraphs. 

3.2.8.1 TCAS/ACAS Operational 

The CC code for “TCAS/ACAS operational” shall {242AR3.102-A} be set to ONE if the 

transmitting subsystem receives information from an appropriate interface that indicates 

that the TCAS/ACAS system is operational. Otherwise, this CC code shall 

{242AR3.102-C} be set to ZERO. 

Notes: 

1. ADS-B does not consider TCAS/ACAS Operational equal to ONE (1) unless the 

TCAS/ACAS is in a state which can issue an RA (e.g., RI=3 or 4). RTCA DO-181E 

(EUROCAE ED-73E) 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/ACAS interface is operational and the transponder is 

receiving TCAS RI=2, 3 or 4. (Refer to RTCA DO-181E (EUROCAE ED-73E), 

Appendix B, Table B-3-16.) RI=0 is STANDBY, RI=2 is TA ONLY and RI=3 is 

TA/RA. 

2. A change in the value of this field will trigger the transmission of messages 

conveying the updated value. These messages will be consistent with higher report 

update rates to be specified in a future version of these MASPS. The duration for 

which the higher report update requirements are to be maintained will also be 

defined in a future version of these MASPS. 


87

88 

3.2.8.2 1090 MHz ES Receive Capability 

The CC Code for “1090ES IN” shall {242AR3.103-C} be set to ONE (1) if the 

transmitting aircraft also has the capability to receive ADS-B 1090ES Messages. 

Otherwise, this CC code subfield shall {242AR3.103-D} be set to ZERO (0). 

3.2.8.3 ARV Report Capability Flag 

The Air Reference Velocity (ARV) Report Capability Flag is a one-bit field that shall 

{242AR3.106} be encoded as in Table 3.2.8.3. 

ARV 

Capability Flag 

0 

3.2.8.4 TS Report Capability Flag 

1 

Table 3.2.8.3: ARV Report Capability Flag 

Meaning 

No capability for sending messages to support Air 

Referenced Velocity Reports 

Capability of sending messages to support Air-Referenced 

Velocity Reports. 

The Target State (TS) Report Capability Flag is a one-bit field that shall {242AR3.107} 

be encoded as in Table 3.2.8.4. 

TS Report 

Capability Flag 

0 

3.2.8.5 TC Report Capability Level 


1 

Table 3.2.8.4: TS Report Capability Flag 

Meaning 

No capability for sending messages to support 

Target State Reports. 

Capability of sending messages to support 

Target State Reports. 

The Trajectory Change (TC) Report Capability Level is a two-bit field that shall 

{242AR3.108} be encoded as in Table 3.2.8.5. 

TC Report 

Capability Level 

0 

Table 3.2.8.5: TC Report Capability Levels 

Meaning 

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 for future use.)

3.2.8.6 UAT Receive Capability 

The “UAT IN” CC Code shall {242AR3.109-C} be set to ZERO (0) if the aircraft is 

NOT fitted with the capability to receive ADS-B UAT Messages. The “UAT IN” CC 

Code shall {242AR3.109-D} be set to ONE (1) if the aircraft has the capability to receive 

ADS-B UAT Messages. 

3.2.8.7 Other Capability Codes 

Other capability codes are expected to be defined in later versions of these MASPS. 

3.2.9 Operational Mode (OM) Codes 

Operational Mode (OM) codes are used to indicate the current operational modes of 

transmitting ADS-B participants. Specific operational mode codes are described in the 

following subparagraphs. 

3.2.9.1 TCAS/ACAS Resolution Advisory Active Flag 

The CC code for “TCAS/ACAS Resolution Advisory Active” shall {242AR3.110-A} be 

set to ONE if the transmitting aircraft has a TCAS II or ACAS computer that is currently 

issuing a Resolution Advisory (RA). Likewise, this CC code shall {242AR3.110-B} be 

set to ONE if the transmitting ADS-B equipment cannot ascertain whether the TCAS II 

or ACAS computer is currently issuing an RA. This CC code shall {242AR3.110-C} be 

ZERO only if it is explicitly known that a TCAS II or ACAS computer is not currently 

issuing a Resolution Advisory (RA). 

Note: A change in the value of this field will trigger the transmission of messages 

conveying the updated value. These messages will be consistent with higher 

report update rates to be specified in a future version of this MASPS. The 

duration for which the higher report update requirements are to be maintained 

will also be defined in a future version of this MASPS. 

3.2.9.2 IDENT Switch Active Flag 

The “IDENT Switch Active” Flag is a one-bit OM code that is activated by an IDENT 

switch. Upon activation of the IDENT switch, this flag shall {242AR3.111-B} be set to 

ONE for a period of 20 �3 seconds; thereafter, it shall {242AR3.111-C} be reset to 

ZERO. 

Note: These MASPS do not specify the means by which the “IDENT Switch Active” 

flag is set. That is left to lower-level documents, such as the MOPS for a 

particular ADS-B data link. 


89

90 

3.2.9.3 Reserved for Receiving ATC Services Flag 

The “Reserved for Receiving ATC Services” flag is a one-bit OM code. If implemented 

into future versions of these MASPS, when set to ONE, this code shall {242AR3.112} 

indicate that the transmitting ADS-B participant is receiving ATC services; otherwise this 

flag should be set to ZERO. 

Note: The means by which the “Reserved for Receiving ATC Services” flag is set is 

beyond the scope of this MASPS and is not specified in this document. 

3.2.9.4 Single Antenna Flag 

The “Single Antenna Flag” is a 1-bit field that shall {242AR3.112-A} be used to indicate 

that the ADS-B Transmitting Subsystem is operating with a single antenna. The 

following conventions shall {242AR3.112-B} 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 

{242AR3.112-C} set the Single Antenna subfield to “ONE” at all times. 

b. Diversity, i.e., those transmitting functions designed to use two antennas, shall 

{242AR3.112-D} 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 Flag shall {242AR3.112-E} be set to “ONE.” 

Note: Certain applications may require confirmation that each participant has 

functioning antenna diversity for providing adequate surveillance coverage. 

3.2.9.5 System Design Assurance (SDA) 


The position transmission chain includes the ADS-B transmission equipment, ADS-B 

processing equipment, position source, and any other equipment that processes the 

position data and position quality metrics that will be transmitted. 

The “System Design Assurance” (SDA) field is a 2-bit field that shall {242AR3.112-F} 

define the failure condition that the position transmission chain is designed to support as 

defined in Table 3.2.9.5. 

The supported failure condition will indicate the probability of a position transmission 

chain fault causing false or misleading position information to be transmitted. The 

definitions and probabilities associated with the supported failure effect are defined in 

AC 25.1309-1A, AC 23-1309-1D, 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).

SDA Value 

(decimal) (binary) 

0 00 

Table 3.2.9.5: SDA OM Subfield in Aircraft Operational Status Messages 

Supported 

Failure 

Condition 

Unknown/ No 

safety effect 

Note 2 

Probability of Undetected Fault 

causing transmission of False or 

Note 3,4 

Misleading Information 

> 1x10 -3 per flight hour 

or Unknown 

91 

Software & Hardware 

Design Assurance 

Note 1,3 

Level 

1 01 Minor ≤ 1x10 -3 per flight hour D 

2 10 Major ≤ 1x10 -5 per flight hour C 

3 11 Hazardous ≤ 1x10 -7 per flight hour 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-1D, 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-1D that allow reduction in failure probabilities and design assurance level 

for aircraft under 6000 pounds do not apply. 

4. Includes probability of transmitting false or misleading latitude, longitude, or associated accuracy 

and integrity metrics. 

3.2.9.6 GPS Antenna Offset 

The “GPS Antenna Offset” field is an 8-bit field in the OM Code Subfield of surface 

format Aircraft Operational Status Messages that shall {242AR3.112-G} define the 

position of the GPS antenna in accordance with the following. 

a. Lateral Axis GPS Antenna Offset: 

The Lateral Axis GPS Antenna Offset shall {242AR3.112-H} be used to encode the 

lateral distance of the GPS Antenna from the longitudinal axis (Roll) axis of the 

aircraft. Encoding shall {242AR3.112-I} be established in accordance with Table 

3.2.9.6A. 

N/A 

© 20xx, RTCA, Inc.

92 


Table 3.2.9.6A: Lateral Axis GPS Antenna Offset Values 

0 = left Values 

Upper Bound of the 

GPS Antenna Offset 

Along Lateral (Pitch) Axis 

Left or Right of Longitudinal (Roll) Axis 

1 = right Bit 1 Bit 0 Direction (meters) 

0 0 NO DATA 

0 

0 

1 

1 

0 

LEFT 

2 

4 

1 1 

6 

0 0 0 

1 

0 

1 

1 

0 

RIGHT 

2 

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. If the distance is greater than 6 meters, then the encoding should be set 

to 6 meters. 

4. The “No Data” case is indicated by encoding of “000” as above, while the “ZERO” 

offset case is represented by encoding of “100” as above. 

5. The accuracy requirement is assumed to be better than 2 meters, consistent with the 

data resolution. 

b. Longitudinal Axis GPS Antenna Offset: 

The Longitudinal Axis GPS Antenna Offset shall {242AR3.112-J} be used to encode 

the longitudinal distance of the GPS Antenna from the NOSE of the aircraft. 

Encoding shall {242AR3.112-K} be established in accordance with Table 3.2.9.6B. 

If the Antenna Offset is compensated by the Sensor to be the position of the ADS-B 

participant’s ADS-B Position Reference Point (see §3.2.4.1), then the encoding is set 

to binary “00001” in Table 3.2.9.6B.

Table 3.2.9.6B: Longitudinal Axis GPS Antenna Offset Encoding 

Longitudinal Axis GPS Antenna Offset Encoding 

Upper Bound of the 

Values 

GPS Antenna Offset 

Along Longitudinal (Roll) Axis 

Aft From Aircraft Nose 

Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 (meters) 

0 0 0 0 0 NO DATA 

0 0 0 0 1 Position Offset Applied by Sensor 

0 0 0 1 0 2 

0 0 0 1 1 4 

0 0 1 0 0 6 

* * * * * *** 

* * * * * *** 

* * * * * *** 

1 1 1 1 1 60 

Notes: 

1. Maximum distance aft from aircraft nose is 60 meters or 196.85 feet. If the distance 

is greater than 60 meters, then the encoding should be set to 60 meters. 

2. The accuracy requirement is assumed to be better than 2 meters, consistent with the 

minimum data resolution of the 2 meter encoding steps. 

3.2.9.7 Other Operational Mode Codes 

Other operational mode (OM) codes may be defined in later versions of these MASPS. 

3.2.10 Navigation Integrity Category 

The Navigation Integrity Category (NIC) is reported so that surveillance applications 

may determine whether the reported geometric position has an acceptable integrity 

containment region for the intended use. The Navigation Integrity Category is intimately 

associated with the SIL (Source Integrity Level) parameter described in §3.2.13. NIC 

specifies an integrity containment region. The SIL parameter specifies the probability of 

the reported horizontal position exceeding the containment radius defined by the NIC 

without alerting, assuming no avionics faults. 

Note: “NIC” and “NACP” as used in these MASPS was previously changed in an 

earlier version of the ADS-B MASPS (RTCA DO-242A), which replaced the 

earlier term, “NUCP”, used in the first edition of the ADS-B MASPS (RTCA DO- 

242). 

The Navigation Integrity Category is reported in the State Vector (SV) report 

(§3.5.1.3.18). 

Table 3.2.10a defines the navigation integrity categories that transmitting ADS-B 

participants shall {242AR2.30} use to describe the integrity containment radius, RC, 


93

94 


associated with the horizontal position information in ADS-B messages from those 

participants. 

Table 3.2.10a: Navigation Integrity Categories (NIC). 

NIC 

(Notes 1, 2) 

Notes for Table 3.2.10a: 

0 

Horizontal Containment 

Bounds 

RC 

Unknown 

Notes 

1 RC < 37.04 km (20 NM) 6 

2 RC < 14.816 km (8 NM) 3, 6 

3 RC < 7.408 km (4 NM) 6 

4 RC < 3.704 km (2 NM) 6 

5 RC < 1852 m (1 NM) 6 

6 RC < 1111.2 m (0.6 NM) 5, 6 

6 RC < 555.6 m (0.3 NM) 5, 6 

7 RC < 370.4 m (0.2 NM) 6 

8 RC < 185.2 m (0.1 NM) 6 

9 RC < 75 m 4 

10 RC < 25 m 4 

11 RC < 7.5 m 4 

1. NIC is reported by an aircraft because there will not be a uniform level of navigation 

equipage among all users. Although GNSS is intended to be the primary source of 

navigation data used to report ADS-B horizontal position, it is anticipated that 

during initial uses of ADS-B or during temporary GNSS outages an alternate source 

of navigation data may be used by the transmitting A/V for ADS-B position 


2. “NIC” in this column corresponds to “NUCP” of Table 2-1(a) in the first version of 

these MASPS, DO-242, dated February 19, 1998. 

3. The containment radius for NIC = 2 has been changed (from the corresponding 

radius for NUCP = 2 in the first edition of these MASPS) so as to correspond to the 

RNP-4 RNAV limit of DO-236A, rather than the RNP-5 limit of the earlier DO-236. 

This is because RNP-5 is not a recognized ICAO standard RNP value. 

4. HIL/HPL may be used to represent RC for GNSS sensors. 

5. RC < 0.3 NM was added in this version of these MASPS and assigned NIC value of 6. 

It is left to the ADS-B data link to provide a means to distinguish between RC < 0.3 

NM and RC < 0.6 NM. 

6. RNP containment integrity refers to total system error containment including sources 

other than sensor error, whereas horizontal containment for NIC only refers to 

sensor position error containment.

It is recommended that the coded representations of NIC should be such that: 

a. Equipment that conforms to the current edition of these MASPS (“version 2” 

equipment) or to the previous, RTCA DO-242A, edition (“version 1” equipment) 

will recognize the equivalent NUCP codes from the first edition of these MASPS 

(RTCA DO-242, version “0” equipment), and 

b. Equipment that conforms to the initial, RTCA DO-242, edition of these MASPS 

(“version 0” equipment) will treat the coded representations of NIC coming from 

version 1 or 2 equipment as if they were the corresponding “NUCP” values from 

the initial, RTCA DO-242, version of these MASPS. 

3.2.11 Navigation Accuracy Category for Position (NACP) 

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. 

Table 3.2.11a defines the navigation accuracy categories that shall {242AR2.31} be used 

to describe the accuracy of positional information in ADS-B messages from transmitting 

ADS-B participants. 

Notes: 

1. “NIC” and “NACP” as used in these MASPS replace the earlier term, “NUCP”, used 

in the initial, DO-242, edition of these MASPS . 

2. It is likely that surface movement and runway incursion applications will require 

high NACP values. To obtain those high values, it may be necessary to correct the 

reported position to that of the ADS-B Position Reference Point (§3.2.4.1) if the 

antenna of the navigation sensor is not located in very close proximity to the ADS-B 

reference point. 

3. The Estimated Position Uncertainty (EPU) used in Table 3.2.11a 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 being outside 

the circle is 0.05. When reported by a GPS or GNSS system, EPU is commonly 

called HFOM (Horizontal Figure of Merit). 

4. The EPU limit for NACP = 2 has been changed (from the corresponding limit for 

NUCP = 2 in the first edition of these MASPS) so as to correspond to the RNP-4 

RNAV limit of DO-236A, rather than the RNP-5 limit of the earlier DO-236. This is 

because RNP-5 is not an ICAO standard RNP value. 


95

96 

Table 3.2.11a: Navigation Accuracy Categories for Position (NACP). 


NACP 

95% Horizontal Accuracy Bounds 

(EPU) 

Notes 

0 EPU � 18.52 km (10 NM) 

1 EPU < 18.52 km (10 NM) 1 

2 EPU < 7.408 km (4 NM) 1 

3 EPU < 3.704 km (2 NM) 1 

4 EPU < 1852 m (1NM) 1 

5 EPU < 926 m (0.5 NM) 1 

6 EPU < 555.6 m ( 0.3 NM) 1 

7 EPU < 185.2 m (0.1 NM) 1 

8 EPU < 92.6 m (0.05 NM) 1 

9 EPU < 30 m 2 

10 EPU < 10 m 2 

11 EPU < 3 m 2 

1. RNP accuracy includes error sources other than sensor error, whereas horizontal 

error for NACP only refers to horizontal position error uncertainty. 

2. A non-excluded satellite failure requires that the NACP and NACV parameters be set 

to ZERO along with RC being set to Unknown to indicate that the position accuracy 

and integrity have been determined to be invalid. Factors such as surface multipath, 

which has been observed to cause intermittent setting of Label 130 bit 11, 

should be taken into account by the ADS-B application and ATC. 

3.2.12 Navigation Accuracy Category for Velocity (NACV) 

The velocity accuracy category of the least accurate velocity component being supplied 

by the reporting A/V’s source of velocity data shall {242AR2.33} be as indicated in 

Table 3.2.12a. 

Notes: 


1. NACV is another name for the parameter that was called NUCR in the initial (DO- 

242) version of these MASPS. 

2. Navigation sources, such as GNSS and inertial navigation systems, provide a direct 

measure of velocity which can be significantly better than that which could be 

obtained by position differences. 

3. Refer to RTCA DO-260B, Appendix J (RTCA DO-282B, Appendix Q) for guidance 

material on determination of NACV. The referenced Appendices describe 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 3.2.12a: Navigation Accuracy Categories for Velocity (NACV). 


Horizontal Velocity Error 

NACV 

(95%) 

0 Unknown or � 10 m/s 

1 < 10 m/s 

2 < 3 m/s 

3 < 1 m/s 

4 < 0.3 m/s 

1. When an inertial navigation system is used as the source of velocity information, 

error in velocity with respect to the earth (or to the WGS-84 ellipsoid used to 

represent the earth) is reflected in the NACV value. 

2. When any component of velocity is flagged as not available the value of NACV will 

apply to the other components that are supplied. 

3. A non-excluded satellite failure requires that the RC be set to Unknown along with 

the NACV and NACP parameters being set to ZERO. 

3.2.13 Source Integrity Level (SIL) 

The Source Integrity Level (SIL) defines the probability of the reported horizontal 

position exceeding the containment radius defined by the NIC (§3.2.10), without alerting, 

assuming no avionics faults. Although the SIL assumes there are no unannunciated faults 

in the avionics system, the SIL must consider the effects of a faulted Signal-in-Space, if a 

Signal-in-Space is used by the position source. The probability of an avionics fault 

causing the reported horizontal position to exceed the radius of containment defined by 

the NIC, without alerting, is covered by the System Design Assurance (SDA) parameter. 

The Source Integrity Limit encoding shall {242AR2.34} be as indicated in Table 3.2.13a. 

The SIL probability can be defined as either “per sample” or “per hour.” 

Note: It is assumed that SIL is a static (unchanging) value that depends on the position 

sensor being used. Thus, for example, if an ADS-B participant reports a NIC 

code of 0 because four or fewer satellites are available for a GPS fix, there 

would be no need to change the SIL code until a different navigation source were 

selected for the positions being reported in the SV report. 


97

98 

Table 3.2.13a: Source Integrity Level (SIL) Encoding. 

SIL 

0 

1 

2 

3 

Probability of Exceeding the 

NIC Containment Radius 

Unknown or > 1 x 10 -3 

per flight hour or per sample 

1 � 10 -3 


1 � 10 -5 


1 � 10 -7 


3.2.14 Barometric Altitude Integrity Code (NICBARO) 

The Barometric Altitude Integrity Code, NICBARO, is a one-bit flag that indicates whether 

or not the barometric pressure altitude provided in the State Vector Report has been 

cross-checked against another source of pressure altitude. 

Note: NICBARO, the barometric altitude integrity code, is reported in the Mode Status 

report (§3.5.1.4). 

3.2.15 Emergency/Priority Status 


The ADS-B system shall {242AR2.36} be capable of supporting broadcast of emergency 

and priority status. Emergency/priority status is reported in the MS report (§3.5.1.4) and 

the emergency states are defined in the following Table 3.2.15a. 

Table 3.2.15a: Emergency State Encoding 

Value Meaning 

0 No Emergency 

1 General Emergency 

2 Lifeguard / Medical 

3 Minimum Fuel 

4 No Communications 

5 Unlawful Interference 

6 Downed Aircraft 

7 Reserved

3.2.16 Geometric Vertical Accuracy (GVA) 

The Geometric Vertical Accuracy subfield is a 2-bit field as specified in Table 3.2.16. 

The GVA field shall (R3.xxx new reqmt) be set by using the Vertical Figure of Merit 

(VFOM) (95%) from the GNSS position source used to report the geometric altitude. 

Table 3.2.16: Geometric Vertical Accuracy (GVA) Parameter 

GVA Encoding 

(decimal) 

Meaning 

(meters) 

0 Unknown or > 150 meters 

1 ≤ 150 meters 

2 < 45 meters 

3 Reserved 

Note: For the purposes of these MASPS, values for 0, 1 and 2 are encoded. Decoding 

values for 3 should be treated as < 45 meters until future versions of these 

MASPS redefine the value. 

3.2.17 TCAS/ACAS Resolution Advisory (RA) Data Block 

For those aircraft equipped with TCAS/ACAS, in addition to the TCAS/ACAS 

Resolution Advisory Active broadcast flag, the RA Message Block is also required to be 

broadcast during an active RA and following termination so that ADS-B receiving 

systems can sense the termination of the RA. The message subfields are the data 

elements that are specified in RTCA DO-185B §2.2.3.9.3.2.3.1.1. 

3.2.18 ADS-B Version Number 

The ADS-B Version Number is a 3-bit field that specifies the ADS-B version of the 

transmitting ADS-B system. The ADS-B Version Number shall {242AR3.92} be 

defined as specified in Table 3.2.18 below. 

3.2.19 Selected Altitude Type 

Table 3.2.18: ADS-B Version Number 

Value ADS-B Version 

0 DO-242 

1 DO-242A 

2 DO-260B & DO-282B 

3-7 Reserved for future growth. 

a. The “Selected Altitude Type” subfield is a 1-bit field that is used to indicate the 

source of Selected Altitude data. Encoding of the “Selected Altitude Type” shall 

{242AR3.132-A} be in accordance with Table 3.2.19. 

b. Whenever there is no valid MCP / FCU or FMS Selected Altitude data available, then 

the “Selected Altitude Type” subfield shall {242AR3.132-B} be set to ZERO (0). 


99

100 

Note: Users of this data are cautioned that the selected altitude value transmitted by 

the ADS-B Transmitting Subsystem does not necessarily reflect the true intention 

of the airplane during certain flight modes (e.g., during certain VNAV or 

Approach modes), and does not necessarily correspond to the target altitude (the 

next altitude level at which the aircraft will level off). 

In addition, on many airplanes, the ADS-B Transmitting Subsystem does not 

receive selected altitude data from the FMS and will only transmit Selected 

Altitude data received from a Mode Control Panel / Flight Control Unit (MCP / 

FCU). 

Table 3.2.19: Selected Altitude Type Field Values 

Coding Meaning 

Data being used to encode the Selected Altitude data field is derived from 

0 the Mode Control Panel / Flight Control Unit (MCP / FCU) or equivalent 

equipment. 

Data being used to encode the Selected Altitude data field is derived from 

1 

the Flight Management System (FMS). 

3.2.20 MCP/FCU or FMS Selected Altitude Field 


a. The “MCP / FCU Selected Altitude or FMS Selected Altitude” subfield is an 11-bit 

field that shall {242AR3.133-A} contain either the MCP / FCU Selected Altitude or 

the FMS Selected Altitude data in accordance with the following subparagraphs. 

b. Whenever valid Selected Altitude data is available from the Mode Control Panel / 

Flight Control Unit (MCP / FCU) or equivalent equipment, such data shall 

{242AR3.133-B} be used to encode the Selected Altitude data field in accordance 

with Table 3.2.20. Use of MCP / FCU Selected Altitude shall {242AR3.133-C} then 

be declared in the “Selected Altitude Type” subfield as specified in Table 3.2.19. 

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 {242AR3.133-D} be used to encode the Selected 

Altitude data field in accordance with Table 3.2.20 provided in paragraph “d.” Use 

of FMS Selected Altitude shall {242AR3.133-E} then be declared in the “Selected 

Altitude Type” subfield as specified in Table 3.2.19. 

d. Encoding of the Selected Altitude data field shall {242AR3.133-F} be in accordance 

with Table 3.2.20. Encoding of the data shall {242AR3.133-G} be 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 shall 

{242AR3.133-H} be set to ZERO (0) as indicated in Table 3.2.20. 

Note: Users of this data are cautioned that the selected altitude value transmitted by 

the ADS-B Transmitting Subsystem does not necessarily reflect the true intention

101 

of the airplane during certain flight modes (e.g., during certain VNAV or 

Approach modes), and does not necessarily correspond to the target altitude (the 

next altitude level at which the aircraft will level off). 

In addition, on many airplanes, the ADS-B Transmitting Subsystem does not 

receive selected altitude data from the FMS and will only transmit Selected 

Altitude data received from a Mode Control Panel / Flight Control Unit (MCP / 

FCU). 

Table 3.2.20: “MCP/FCU Selected Altitude or FMS Selected Altitude” Field Values 

Coding 

(Binary) (Decimal) 

Meaning 

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 

3.2.21 Barometric Pressure Setting (Minus 800 millibars) Field 

a. The “Barometric Pressure Setting (Minus 800 millibars)” subfield is a 9-bit field that 

shall {242AR3.136-A} 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 

{242AR3.136-B} be encoded in accordance with Table 3.2.21. 

c. Encoding of Barometric Pressure Setting data shall {242AR3.136-C} 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 shall {242AR3.136-D} 

be set to ZERO (0) as indicated in Table 3.2.21. 

e. Whenever the Barometric Pressure Setting data is greater than 1208.4 or less than 

800 millibars, then the “Barometric Pressure Setting (Minus 800 millibars}” subfield 

shall {242AR3.136-E} be set to ZERO (0). 

Note: This Barometric Pressure Setting data can be used to represent QFE or 

QNH/QNE, depending on local procedures. It represents the current value being 

used to fly the aircraft. 

© 20xx, RTCA, Inc.

102 

Table 3.2.21: Barometric Pressure Setting (Minus 800 millibars) Field Values 

Value 

(Binary) (Decimal) 

Meaning 


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 

3.2.22 Selected Heading Status Field 

The “Selected Heading Status” is a 1-bit field that shall {242AR3.137-A} be used to 

indicate the status of Selected Heading data that is being used to encode the Selected 

Heading data in accordance with Table 3.2.22. 

3.2.23 Selected Heading Sign Field 


Table 3.2.22: Selected Heading Status Field Values 

Value Meaning 

Data being used to encode the Selected Heading data is either NOT 

0 

Available or is INVALID. See Table 3.5.1.7.9. 

Data being used to encode the Selected Heading data is Available 

1 

and is VALID. See Table 3.5.1.7.9. 

The “Selected Heading Sign” is a 1-bit field that shall {242AR3.138-A} be used to 

indicate the arithmetic sign of Selected Heading data that is being used to encode the 

Selected Heading data in accordance with Table 3.2.23. 

Table 3.2.23: Selected Heading Sign Field Values 

Value Meaning 

Data being used to encode the Selected Heading data is Positive in an 

angular system having a range between +180 and –180 degrees. (For an 

0 Angular Weighted Binary 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 3.2.24. 

Data being used to encode the Delected Heading data is Negative in an 

angular system having a range between +180 and –180 degrees. (For an 

1 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 3.2.24.

3.2.24 Selected Heading Field 

a. The “Selected Heading” is an 8-bit field that shall {242AR3.139-A} contain Selected 

Heading data encoded in accordance with Table 3.2.24. 

b. Encoding of Selected Heading data shall {242AR3.139-B} be rounded so as to 

preserve accuracy of the source data within ±½ LSB. 

103 

c. Whenever there is NO valid Selected Heading data available, then the Selected 

Heading Status, Sign, and Data subfields shall {242AR3.139-C} be set to ZERO (0) 

as indicated in Table 3.2.24. 

Note: On many airplanes, the ADS-B Transmitting Subsystem receives Selected 

Heading from a Mode Control Panel / Flight Control Unit (MCP / FCU). Users 

of this data are cautioned that the Selected Heading value transmitted by the 

ADS-B Transmitting Subsystem does not necessarily reflect the true intention of 

the airplane during certain flight modes (e.g., during LNAV mode). 

Table 3.2.24: Selected Heading Status, Sign and Data Field Values 

Values for Selected Heading: 

Status Sign Data 

Meaning 


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 

3.2.25 Status of MCP/FCU Mode Bits 

The “Status of MCP / FCU Mode Bits” is a 1-bit field that shall {242AR3.140-A} be 

used to indicate whether the mode indicator bits are actively being populated (e.g., set) in 

accordance with Table 3.2.25. 

If information is provided to the ADS-B Transmitting Subsystem to set the Mode 

Indicator bits to either “0” or “1,” then the “Status of MCP/FCU Mode Bits” shall 

© 20xx, RTCA, Inc.

104 

{242AR3.140-B} be set to ONE (1). Otherwise, the “Status of MCP/FCU Mode Bits” 

shall {242AR3.140-C} be set to ZERO (0). 

Table 3.2.25: Status of MCP/FCU Mode Bits Field Values 

Values Meaning 

0 No Mode Information is being provided in the Mode Indicator bits 

Mode Information is deliberately being provided in the Mode 

1 

Indicator bits 

3.2.26 Mode Indicator: Autopilot Engaged Field 

The “Mode Indicator: Autopilot Engaged” subfield is a 1-bit field that shall 

{242AR3.142-A} be used to indicate whether the autopilot system is engaged or not. 

a. The ADS-B Transmitting Subsystem shall {242AR3.142-B} accept information from 

an appropriate interface that indicates whether or not the Autopilot is engaged. 

b. The ADS-B Transmitting Subsystem shall {242AR3.142-C} set the Mode Indicator: 

Autopilot Engaged field in accordance with Table 3.2.26. 

Table 3.2.26: Mode Indicator: Autopilot Engaged Field Values 


Autopilot is NOT Engaged or Unknown (e.g., not actively coupled and flying 

0 

the aircraft) 

1 Autopilot is Engaged (e.g., actively coupled and flying the aircraft) 

3.2.27 Mode Indicator: VNAV Mode Engaged Field 

The “Mode Indicator: VNAV Mode Engaged” is a 1-bit field that shall {242AR3.146-A} 

be used to indicate whether the Vertical Navigation Mode is active or not. 


an appropriate interface that indicates whether or not the Vertical Navigation Mode is 

active. 


VNAV Mode Engaged field in accordance with Table 3.2.27. 

Table 3.2.27: “Mode Indicator: VNAV Engaged” Field Values 


0 VNAV Mode is NOT Active or Unknown 

1 VNAV Mode is Active 

3.2.28 Mode Indicator: Altitude Hold Mode Field 


The “Mode Indicator: Altitude Hold Mode” is a 1-bit field that shall {242AR3.147-A} be 

used to indicate whether the Altitude Hold Mode is active or not.

105 


an appropriate interface that indicates whether or not the Altitude Hold Mode is 

active. 


Altitude Hold Mode field in accordance with Table 3.2.28. 

Table 3.2.28: “Mode Indicator: Altitude Hold Mode” Field Values 


0 Altitude Hold Mode is NOT Active or Unknown 

1 Altitude Hold Mode is Active 

3.2.29 Mode Indicator: Approach Mode Field 

The “Mode Indicator: Approach Mode” is a 1-bit field that shall {242AR3.148-A} be 

used to indicate whether the Approach Mode is active or not. 


an appropriate interface that indicates whether or not the Approach Mode is active. 


Approach Mode field in accordance with Table 3.2.29. 

Table 3.2.29: “Mode Indicator: Approach Mode” Field Values 


0 Approach Mode is NOT Active or Unknown 

1 Approach Mode is Active 

3.2.30 Mode Indicator: LNAV Mode Engaged Field 

The “Mode Indicator: LNAV Mode Engaged” is a 1-bit field that shall {242AR3.149-A} 

be used to indicate whether the Lateral Navigation Mode is active or not. 


an appropriate interface that indicates whether or not the Lateral Navigation Mode is 

active. 


LNAV Mode Engaged field in accordance with Table 3.2.30. 

Table 3.2.30: “Mode Indicator: LNAV Mode Engaged” Field Values 


0 LNAV Mode is NOT Active 

1 LNAV Mode is Active 

© 20xx, RTCA, Inc.

106 

3.3 System Application Requirements 

3.3.1 Latency 


In general, latency is synonymous with data age. As used in this document it is the 

difference between the time attributed to source data and the time that data are presented 

at a particular interface. {This definition was adapted from DO-289 §2.4.5.3.3.4} Some 

data latency can be compensated with extrapolation techniques; however, there will 

always be a small amount of latency compensation error that needs to be minimized. 

This section includes the requirements for the end-to-end latency, referred to as total 

latency, for ADS-B, ADS-R and TIS-B; the latency allocations to some key subsystems; 

and the allowable latency compensation error for ADS-B. 

3.3.1.1 Key Latency Definitions 

The following are key definitions related to the understanding of latency. 

Total Latency: is the total time between the availability of information at a lower 

interface ‘X’ to the time of completion of information transfer at an upper interface ‘Y’. 

Total Latency is the sum of Compensated Latency and Latency Compensation Error and 

is expressed as a single upper value. The related position error is the product of Total 

Latency and acceleration uncertainty valid for the duration of the Total Latency. 

Compensated Latency: is that part of Total Latency that is compensated for to a new 

time of applicability, valid at an interface ‘Y’, through data extrapolation aiming at 

reducing the effects of latency. Compensated Latency may change for each new 

received/processed track. The related position error is the product of Compensated 

Latency and the accuracy error of the A/V velocity used for the extrapolation. 

Latency Compensation Error (formerly referred to as “Uncompensated Latency”): is 

that part of Total Latency that is not compensated and/or under/overcompensated for. 

The value is usually positive but overcompensation might produce negative values as 

well. The Latency Compensation Error may change for each new received/processed 

track. The related position error is the product of Latency Compensation Error and true 

A/V velocity. 

Time of applicability (TOA): at an interface ‘Y’, is the TOA as valid at a lower 

interface ‘X’ plus the amount of Compensated Latency applied to and valid at an upper 

interface ‘Y’. Therefore, the Time of Applicability uncertainty is the (sum of) Latency 

Compensation Errors up to interface ‘Y’. Regarding the notion of a “common” TOA, it 

is noted that the time of applicability uncertainty will generally vary between tracks. 

The ground segment interfaces used to define latency are shown in Figure 1-1 and the 

airborne interfaces used to define latency measurements shown in Figure 3-15.

Figure 3-15: End to End ASA System Latency Diagram 


107

108 


Notes: 

1. The Time Mark is an implementation detail of an ARINC 743A compliant GNSS. 

Other position sensors do not typically output a Time Mark. 

2. Transmit Time of Applicability (TTOA) may occur before, after, or coincide with 

Time of Transmission (TOT) depending on the ADS-B link implementation. 

3. GNSS Engine Design Tolerance is dependent on the implementation of the GNSS 

engine, but typically is on the order of microseconds. 

4. DO-229D requires that the digital solution associated with the Time Mark be 

delivered in 200 ms. 

5. The bold lines indicate defined interfaces and match Figure 2-7 in DO-289. The 

exception is interface A4 which doesn’t appear in DO-289 and was added to clarify 

the latency allocation to the transmit subsystem. 

3.3.1.2 System Interface Definitions 

In the following, the term “system interface” expresses timing reference points. With 

respect to timing requirements, each interface is associated with the time the last bit of a 

complete data (or signal) set has been transferred over that interface. 

Figure 3-15 provides for a detailed end-to-end latency diagram, showing the latency 

components of both ADS-B Transmit aircraft and ASA aircraft. 

The following Figure 3-16 provides for a simple indication of the ASA System latency 

interfaces with respect to both own-ship and traffic position information. 

GNSS 

Rcv 

3.3.1.2.1 Interface A1 

ASSAP 

or other 

CDTI 

A3 A5 B3 F G 

Own-ship 

Link 

Rcv 

ASSAP CDTI 

D E F 

Traffic 

Figure 3-16: ASA System Latency Diagram 

Interface A1 is defined as the input to the position sensor of an ASA Transmit 

Participant. The time associated with this physical interface is called the Time of 

Measurement. 

The term Time of Measurement has a very specific meaning in the GNSS literature. It is 

the time that the Satellite Measurements are sampled with the GNSS RF hardware. 

Depending on the regulatory document and the equipment class that the GNSS is 

certified to, the time between the Time of Measurement (A1) and the Time of 

Applicability (A4) can be 300 ms to 1 second. To meet the Latency allocations in these 

MOPS, the maximum Total latency Latency between A1 and A4 may not exceed 500 ms. 

G





3.3.1.2.6 Interface B1 

109 

Interface A2 is defined as the input to the position sensor of a TIS-B Participant or the 

reception of position data of an ADS-R Participant. The time associated with this 

physical interface is called the Time of Measurement or Time of Reception respectively. 

This interface is not depicted in Figure 3-15, refer to Figure 1-1. 

Interface A3 is identical to A1 but is defined as applicable to the ownship position 

source. This interface is not depicted in Figure 3-15, refer to Figure 1-1. 

Interface A4 is introduced in this appendix and defined as the output of the position 

sensor of an ASA Transmit Participant. The time associated with this physical interface 

is called the Time of Applicability. 

The term Time of Applicability has a very specific meaning in the GNSS literature. It is 

the time that the digital solution transmitted from the sensor is applicable. This Time of 

Applicability coincides with the leading edge of a pulse known as the Time Mark. A 

GNSS sensor provides this pulse on a dedicated set of pins; usually as a differential pair 

to provide better noise immunity. 

The reported digital solution quality metrics (accuracy, integrity) are also valid at the 

Time of Applicability. Latency present in the system after Interface A4 is NOT 

accounted for in the quality metrics provided by the GNSS including the Latency 

inherent in delivering the data to Host/Link Equipment. The latency between A4 and B1 

is to be included when establishing the ADS-B State Data Latency. 

This interface is identical to A4 but is defined as applicable to the ownship position 

source. As between A4 and B1, the latency between A5 and B3 resulting from the 

various system elements that can be included between both interfaces, has to be included 

when establishing the ownship State Data Latency. This interface is not depicted in 

Figure 3-15. 

Interface B1 is defined as the input to the ADS-B Transmit Subsystem. The requirements 

of this function are controlled by DO-260()/ED-102(), DO-282() and ED-108(). In a 

distributed architecture, there could be various system elements between A4 and B1. For 

instance, a modern integrated cockpit with a high speed databus may require a block of 

circuitry on either side of it to transfer PVT data on and off of the bus. 

For GNSS systems, the maximum Total Latency between A4 and B1 may not exceed 400 

ms. This latency is usually not compensated for and, hence, becomes part of the Latency 

Compensation Error budget. 

© 20xx, RTCA, Inc.

110 



3.3.1.2.9 Interface D 

3.3.1.2.10 Interface E 

3.3.1.2.11 Interface F 

3.3.1.2.12 Interface G 


Interface B2 is defined as the input to the TIS-B & ADS-R Surveillance Processing and 

Distribution system. This interface is not depicted in Figure 3-15, refer to Figure 1-1. 

Interface B3 is defined as the input to the ASSAP function on ownship. This interface is 

not depicted in Figure 3-15, refer to Figure 1-1. 

Interface D is defined as the Time of Transmission (i.e., the RF message leaving the 

transmit antenna). Depending on which transmit case is implemented in the link 

equipment, the Transmit Time of Applicability may coincide with the Time of 

Transmission or be within some specified time tolerance between these. 

For the purposes of latency allocation, Travel Time is not significant. Therefore, 

Interface D also defines the Time of Reception (i.e., the RF message arriving at the 

receive antenna). 

The Link Transmit and Receive Equipment requirements are controlled by DO-260()/ED- 

102(), DO-282() and ED-108(). 

Interface E is defined as the time an ADS-B (or TIS-B/ADS-R) Report is delivered to 

ASSAP. ASSAP requirements are controlled by this document. The ASSAP function 

will extrapolate the traffic positions to a common time of applicability, within required 

tolerances, prior to performing application specific calculations and passing the traffic to 

the CDTI interface (F). 

In an integrated architecture, Interface E may not be observable. For example, in an Air 

Transport installation, it is possible that the ADS-B Receiver will be integrated with the 

TCAS II equipment that may also implement the ASSAP requirements. 

Interface F is defined as the time the ownship and traffic tracks are delivered to the CDTI. 

For architectures that do not process ownship and traffic data together, the Time of 

Delivery at interface F might differ. 

The latency budget allocated between E and F was based on a feasibility study of 

implementing ASSAP in TCAS II equipment and supporting legacy equipment upgrades. 

Interface G is defined as the Time of Display, i.e., the time when the track information 

appears on the display.

111 

The CDTI function may translate and rotate the traffic as needed to maintain a smooth 

and consistent display. The CDTI function is not required to extrapolate the traffic from 

the ASSAP Time of Applicability to the Time of Display. However, it may be desirable 

for the ASSAP Time of Applicability (at interface F) to coincide with the Time of 

Display by design to minimize display latency. 

3.3.1.3 Total Latency for ADS-B and ADS-R 

The total latency for ADS-B and ADS-R is the time difference between the Time of 

Measurement (TOM) of the source data at the transmitting aircraft (Interface A1) and the 

time that data are displayed to the user on the receiving aircraft (Interface G). 

The total latency for State data in ADS-B and ADS-R shall (R3.xxx new reqmt) be no 

greater than 5.5 seconds from A1 to G to support the applications included in section 

2.2.1.1 for ADS-B and 2.1.1 for ADS-R. {This requirement is consistent with the ASA 

MOPS FRAC draft, September 2011, but is less stringent than the FAA final Program 

Requirements (fPR) for SBS, version 3.0, 23 July 2010, which requires 5 seconds.} 

The total latency for updated ID/Status {DO-289, §2.4.5.1} information in ADS-B and 

ADS-R from interface A1 to G shall (R3.xxx, new reqmt) be no greater than 30 seconds. 

{This requirement is consistent with the FAA final Program Requirements (fPR) for SBS, 

version 3.0, 23 July 2010} � May need a Note here to explain: (1) Check App-L from 

DO-242A, (2) And, additional concern about the mixing of update and latency 

requirements. � 

The total latency for own-ship position data sources shall (R3.xxx, new reqmt) be no 

greater than 1 second from the Time Of Measurement (Interface A3) to the time the data 

is supplied to ASSAP (Interface B3, see Figure 1-1). 

The total latency for State data in ADS-B and ADS-R from Interface B1 to D shall 

(R3.xxx, new reqmt) be no greater than 1.1 seconds. 

The total latency for State data in ADS-B and ADS-R from Interface D to G shall 

(R3.xxx, new reqmt) be no greater than 3.5 seconds. 

3.3.1.4 Navigation Subsystem Latency Allocation 

The total latency allocation for the navigation subsystem that measures the source 

position and velocity for the ADS-B transmitting aircraft/vehicle is assumed to be no 

greater than 0.5 seconds from Interface A1 to A4. The total latency allocation from 

Interface A1 to B1 is assumed to be no greater than 0.9 seconds. {These requirements 

are consistent with the ASA MOPS DO-317A FRAC draft version, September 2011} 

Note: These subsystem latency allocations are included in the total latency. 

3.3.1.5 TIS-B Subsystem Latency Allocation 

The TIS-B subsystem latency is the difference between the TOM of the source position 

data and the time of transmission of the TIS-B Message by the ground radio station, 

interfaces A2 to D in Figure 1-1. 

© 20xx, RTCA, Inc.

112 

The latency allocation for the TIS-B ground subsystem shall (R3.xxx, new reqmt) be no 

greater than 3.25 seconds to support the applications included in section 2.2.1.1. {This 

requirement is consistent with DO-289, §3.1.1.5, (no number assigned to the shall in this 

section), 286R2.5-01, and the FAA Essential Services Specification for SBS, version 2.2, 

29 November 2010} � Note: In the future there may be a need for separate requirements 

for airborne and/or surface TIS-B � 

3.3.1.6 Latency Compensation Error 

The latency compensation error is the residual after the TOM on the transmitting 

aircraft/vehicle or the Time of Applicability (TOA) of the position data on the receiving 

aircraft/vehicle has been estimated. The allowable errors in the following requirements 

are included in the total latency defined above. {The requirements in this section are 

consistent with the FRAC version of the ASA MOPS, DO-317A. The transmit-side 

latency compensation error is consistent with the FAA final Program Requirements (fPR) 

for SBS, version 3.0, 23 July 2010, however, the receive-side error is not accounted for in 

the fPR.} 

The latency compensation error of measured geometric position data in the 

aircraft/vehicle transmitting ADS-B (interfaces A1 to D in Figure 3-15) shall (R3.xxx) be 

no greater than +0.6 seconds (at 95% probability). {reference AC20-165, and DO-260B, 

Appendix-U} 

The latency over-compensation error of measured geometric position data in the 

aircraft/vehicle transmitting ADS-B (interfaces A1 to D) shall (R3.xxx) be limited to 200 

ms (at 95% probability). {reference AC20-165, and DO-260B, Appendix-U} 

The latency compensation error of retransmitted geometric position data by the ADS-R 

ground subsystem (interfaces B2 to D in Figure 1-1) shall (R3.xxx) be no greater than 0.1 

seconds (at 95% probability). 

The latency compensation error of source position data by the TIS-B ground subsystem 

(interfaces A2 to D in Figure 1-1) shall (R3.xxx) be no greater than ±0.5 seconds (at 95% 

probability). {Reference 286R2.5-02} 

The latency compensation error of measured geometric position data in the 

aircraft/vehicle receiving ADS-B, ADS-R or TIS-B (interfaces D to E in figure 3.3.1-1) 

shall (R3.xxx) be no greater than 0.5 seconds (at 95% probability). 

� Editors Note: In DO-317A Table 2-2 this is a total latency requirement, not a LCE 

requirement. {reference DO-242A 3.3.3.2.2} � 

The latency compensation error of measured geometric position data (from Interface E to 

G) shall (R3.xxx) be no greater than ±500 ms (at 95% probability). 

3.3.2 ADS-R/TIS-B Service Status Update Interval 


The update interval is the time between successive updates of particular information at 

the receiving aircraft/vehicle.

113 

The update interval of ADS-R or TIS-B Service Status information in the receiving 

aircraft shall (Rx.xxx) be less than 30 seconds (measured at Interface D). {This 

requirement is consistent with the FAA final Program Requirements (fPR) for SBS, 

version 3.0, 23 July 2010} 

3.4 Subsystem Requirements 

3.4.1 Subsystem Requirements for ASSAP 

ASSAP is the surveillance and separation assurance processing component of ASA. 

ASSAP processes incoming data from own-ship, and other aircraft/vehicles (A/V), and 

derives information for display on the CDTI. Flight crew command and control inputs 

that affect application functions are also processed by ASSAP. In the future, ASSAP is 

expected to provide alerting and guidance information to the flight crew via the CDTI. 

The two major functions of ASSAP are surveillance processing and applications 

processing. Functional requirements for ASSAP are described in §3.4.1.4. 

Surveillance processing: 

� Establishes tracks from ADS-B, ADS-R, and TIS-B traffic reports 

� Cross-references traffic from different surveillance sources (ADS-B, ADS-R, 

TIS-B, and TCAS) 

� Estimates track state (e.g., position, velocity), and track quality 

� Deletes tracks that are beyond the maximum allowable coast time for any ASA 

applications 

Applications processing: 

� Determines the appropriateness of track information for various applications, and 

forwards the track data to the CDTI 

� May performs alerting functions in future applications 

� May derive guidance information in future applications 

Each ASA transmit participant should input to ASSAP the highest quality state data that 

is available on-board; this information should be the same as that used for ADS-B 

transmission. ASSAP assesses own-ship performance and transmitted data quality and 

assesses received traffic data quality as specified in Table 2-7 to determine if an active 

application can be supported. 

© 20xx, RTCA, Inc.

114 

Figure 3-17 summarizes ASSAP input / output interfaces to other subsystems and 

indicates the sections where the interface, functional, and performance requirements can 

be found in this document. 

ADS-B / TIS-B / 

ADS-R Receiver 

TCAS 

Own-ship 

Navigation 

Map 

3.4.1.1 Definitions 


§3.4.1.3 

§3.4.1.3 

§3.4.1.3 

§3.4.1.3 

ASSAP Function 

Surveillance Processing §3.4.1.4.1 

Application Processing §3.4.1.4.2 

Performance §3.4.1.6 

§3.4.1.5 

§3.4.1.3 

Figure 3-17: ASSAP Input / Output and Requirement Section Summary 

Key definitions used in this section include: 

CDTI 

Correlation: The process of determining that a new measurement belongs to an existing 

track. 

Estimation: The process of determining a track’s state based on new measurement 

information 

Extrapolation: The process of moving a track’s state forward in time based on the 

track’s last estimated kinematic state. 

TCAS Target status: The status of the TCAS track, if applicable, from the TCAS 

system. The four states are: Resolution Advisory (RA), Traffic Advisory (TA), 

proximate, and other. {are we standardizing on “target” or “traffic” for this document?} 

Track: A sequence of time-tagged measurements and state information relating to a 

particular aircraft or vehicle. The track may be a simple list file of A/V position and time

data extrapolated to a common time for processing and display, or may include track 

estimation and Kalman filtering. 

Track State: The basic kinematic variables that define the state of the aircraft or vehicle 

of a track, e.g., position, velocity, acceleration. 

3.4.1.2 General Requirements 

When integrated with TCAS systems the ASSAP function shall (R3.xxx) not interfere 

with TCAS guidance to the flight crew. 

3.4.1.3 Input Interface Requirements 

115 

ASSAP provides the central processing for ASA and interfaces with many other avionics 

subsystems. Depending on the class of aircraft, either EVAcq or AIRB defines the basic 

use of ASA for enhanced traffic situational awareness, and support for this application is 

the minimum requirement for all ASA implementations. The remaining applications 

(VSA, ITP, and SURF) are optional. Although VSA, ITP, and SURF applications are 

optional, when they are implemented, the requirements designated for these applications 

must be met. 

ASSAP shall (R3.xxx) {289R3.213} provide all input interfaces to support the minimum 

requirements for all installed applications as indicated in Table 3.4.1.3 by a dot (•). 

ASSAP shall (R3.xxx) provide input interface method for validation status information 

(e.g., validity bit, or value of zero) for each required information element input to the 

ASSAP from the ADS-B / ADS-R / TIS-B receiver. 

Table 3.4.1.3: ASSAP Input Interface Requirements 

Source Info Category Information Element 6 

ADS-B / ADS-R / TIS-B Receiver 

Aircraft State Data 

Time Of Applicability � � � � � 

Latitude (WGS-84) � � � � � 

Longitude (WGS-84) � � � � � 

Geometric Altitude 1, 9 � � � � � 

Air / Ground State � � � � � 

North Velocity While Airborne 9 � � � � � 

East Velocity While Airborne 9 � � � � � 

Ground Speed While on the Surface � � � � 

Heading (true / mag) or Ground Track While on the Surface � � � � � 

Pressure Altitude 9 � � � � � 

Vertical Rate 9 � � � � � 

Navigation Integrity Category (NIC) � � � � � 

EVAcq 

AIRB 

VSA 

ITP 


SURF

116 


ADS-B / ADS-R / TIS-B Receiver (continued) 

ID / Status 


ADS-B Link Version Number � � � � � 

Participant Address � � � � � 

Address Qualifier � � � � � 

Call Sign / Flight ID � � � � 

A/V Length and Width Codes 8, 9 � 

Emitter Category � � � � 

Emergency / Priority Status 7 � � � � � 

Navigation Accuracy Category for Position (NACP) � � � � � 

Navigation Accuracy Category for Velocity (NACV ) � � � � � 

Geometric Vertical Accuracy 1, 9 (GVA) � � � � � 

Surveillance Integrity Level (SIL) � � � 

System Design Assurance (SDA) 

True/Magnetic Heading Reference [why not required?] 

� � � � � 

TIS-B / ADS-R Service Status 2 � � � � � 

EVAcq 

AIRB 

VSA 

ITP 

SURF


TCAS Target 

Navigation 

CDTI 

Target Status � � � � � 

Range � � � � � 

Bearing 

Pressure Altitude 

� � � � � 

3 � � � � � 

Altitude Rate � � � � � 

Vertical Sense � � � � � 

Mode S Address 3 TCAS related data 

� � � � � 

5 

Track ID � � � � � 

Time of Applicability � � � � � 

Horizontal Position � � � � � 

Horizontal Velocity � � � � � 

Geometric Altitude 1 � � � � � 

Pressure Altitude � � � � � 

Ground Speed (on surface) � 

Heading, True 4 Own-ship state data 

� � � � � 

Track Angle, True � 

A/V Length and Width Codes 8 � 

Position Integrity Containment Region � � � 

Source Integrity Level � � � 

Horizontal Position Uncertainty � � � � � 

Vertical Position Uncertainty 1 Own-ship quality 

� � � � � 

Velocity Uncertainty � � � � � 

ID / Status 

24 bit Address 

Air / Ground State 

� 

� 

� 

� 

� 

� 

� 

� 

� 

� 

Flight Crew Inputs 

Application Selection 

Selected Traffic 

� 

� 

� 

� 

� 

� 

� 

� 

� 

� 

Designated Traffic [replaced coupled] � � � � � 

Map Database Airport Map Status � � � � � 

EVAcq 

AIRB 

VSA 

ITP 

117 

� = Required 

Notes for Table 3.4.1.3: 

1. When geometric altitude is used to determine relative altitude. 

2. For systems that don’t receive information from TCAS. 

3. This information requires a change to the standard TCAS bus outputs defined in 

ARINC 735A/B that currently does not provide the Mode S address code, nor does it 

necessarily output pressure altitude. 

4. For systems that receive information from TCAS or determine relative bearing for 

traffic. 


SURF

118 

5. Required if TCAS is present in the configuration and an integrated TCAS/ASA traffic 

display is used. These outputs are expected to be supplied by current TCAS 

installation. 

6. Each future application will add columns for minimum requirement. 

7. When used to display the Emergency/Priority Status. 

8. When used to display the physical extent of the aircraft. 

9. Not required for surface vehicles. 

3.4.1.4 ASSAP Functional Requirements 

ASSAP functional requirements are broken into surveillance processing requirements 

(§3.4.1.4.1) and applications processing requirements (§3.4.1.4.2). 

3.4.1.4.1 ASSAP Surveillance Processing Requirements 


ASSAP surveillance processing function receives information for traffic A/V’s from 

various surveillance sources, correlates the data, registers the data, and outputs a track file 

consisting of state and other information about each A/V under track. Requirements for 

the surveillance sub-function follow. Note that the tracking and correlation functions 

make extensive use of the data that is provided in state data (Table 3.4.1.3). 

ASSAP shall (R3.xxx) {derived from 289R3.177} acquire all State data necessary to 

generate tracks for A/Vs and own-ship. 

ASSAP may receive A/V data from different surveillance sources. 

ASSAP shall (R3.xxx) {289R3.169} perform a tracking function on each traffic A/V. 

ASSAP shall (R3.xxx) {289R3.188} extrapolate the target horizontal position (i.e., 

latitude and longitude), for tracks of airborne traffic for which a position update has not 

been received, to a common time reference prior to providing information to the CDTI. 

Note: A linear extrapolation is expected to be used to compensate for any delays 

incurred leading up to the time of transmission. Extrapolation is only performed 

on targets determined to be airborne. The pressure altitude should not be 

extrapolated since the altitude rate accuracy may induce larger altitude errors 

than the provided in the original data. 

ASSAP shall (R3.xxx) minimize position error due to extrapolation. 

Note: An acceptable means of this would be linear extrapolation using the 

instantaneous velocity reported for the target. 

ASSAP shall (R3.xxx) maintain tracks for multiple A/Vs. 

ASSAP may receive A/V data for the same A/V from different surveillance sources. 

The ASSAP tracking function shall {289R3.172} include a correlation function that 

associates traffic data from any surveillance sources that relate to the same A/V’s track to 

minimize the probability of processing and displaying duplicate A/Vs.

If the ASSAP determines that multiple source tracks correlate, the best quality source 

track shall {289R3.72} be used. 

119 

The ASSAP tracking function shall {289R3.178} terminate a track when the maximum 

coast interval or data age (see FRAC draft DO-317A, Table 2-2) has been exceeded for 

all of the applications for which the track is potentially being used. 

3.4.1.4.2 ASSAP Application Processing Requirements 

The ASSAP will determine if the available data, quality, and track information is 

sufficient to support the minimum requirements display an A/V on the CDTI, and to run 

the installed applications. 

If an A/V track is being surveilled by multiple sources, the determination of acceptability 

for applications should be based on the track quality as derived by ASSAP, rather than on 

quality of any individual source. 

If the sole surveillance source of information provided to the ASSAP for a given target is 

ADS-B, ADS-R, or TIS-B, the track quality assessment shall {289R3.196} be based on 

the surveillance quality indicators (e.g., NIC, NACP, NACV, SIL). 

ASSAP track quality (§3.3.2.1.1) shall (R3.xxx) {derived from 289R3.185-A} be 

compared with minimum performance requirement values for each applications. 

ASSAP shall {289R2.27} assess the ability of own-ship and traffic targets to support the 

active applications. 

ASSAP shall {289R3.187} make ASSAP track reports available to the CDTI for all 


ASSAP shall {289R3.188} deliver track reports to the CDTI for all aircraft of sufficient 

quality for at least EVAcq or AIRB. 

Note: Precise conditions under which airborne and surface traffic is to be displayed 

and filtered is developed in the ASA SYSTEM MOPS, the latest version of DO- 

317( ). 

The ASSAP track report shall {289R3.198} indicate if the track’s quality is insufficient 

for EVAcq or AIRB. 

3.4.1.5 Output Interface Requirements to CDTI 

Information elements that are required as inputs to the ASSAP are also required to be 

available as outputs from the ASSAP to the CDTI to support the installed applications. 

Some CDTIs may be implemented on existing NAV displays that already have their ownship 

position data sources input directly. In that architecture, the interfaces from the 

ASSAP to the CDTI for those data sources are not a minimum requirement. In this case, 

the CDTI would have to make sure that the own-ship quality/integrity thresholds for the 

associated applications are met to perform each application. Alternatively, the necessary 

information could be sent from the CDTI to the ASSAP. 

© 20xx, RTCA, Inc.

120 

ASSAP shall (R3.xxx) provide all output interfaces to the CDTI to support the minimum 

requirements for all installed applications 

Note: No longer providing the data element (e.g., label or data word) may be another 

method of inferring valid/invalid status. 

3.4.1.6 ASSAP Performance Requirements 

The ASSAP function shall (R3.xxx) provide a traffic capacity sufficient to support the 


Note: A capacity of at least 60 tracks (30 airborne and 30 surface) is sufficient for the 

initial applications covered in these MASPS in 3.4.2.4. 

ASSAP outputs shall (R3.xxx) be sent to the CDTI at a rate sufficient to support the 


Note: An output rate of once per second is sufficient to support the applications 

covered in these MASPS in 3.4.2.4. 

3.4.2 Subsystem Requirements for CDTI 

Note: The requirements in this section are extended in the latest version of the ASA 

MOPS, RTCA DO-317(). 

3.4.2.1 General CDTI Requirements 


The CDTI shall (R3.xxx) {289.Section 2.4.3.5}{317A. Section 1.5.2.2} be presented on 

one or more of the following: 

1. A standalone display dedicated to traffic information only. 

2. A shared/multi-function display. 

3. An Electronic Flight Bag (EFB). 

The CDTI shall (R3.xxx) {317A.Section 1.2.2.2, 2.3.1} include a Traffic Display, as 

defined in Appendix A. 

The CDTI shall (R3.xxx) satisfy all applicable requirements listed in this document in all 

flight environments (e.g., expected temperatures and pressures) and operating areas (e.g., 

domestic and oceanic airspaces) for which it is intended. 

Note: For example, in order to satisfy this requirement fully, CDTI’s intended for 

operation over or in the vicinity of the geographic poles would have to include 

an adequate provision for representing directionality of displayed traffic 

elements. A suitable coordinate transformation may be required and could be 

allocated to the ASSAP or the CDTI function.

121 

The operating range of display luminance and contrast shall (R3.xxx) {317A.3021} be 

sufficient to ensure display readability through the full range of normally expected flight 

deck illumination conditions. 

CDTI information should {317A.Section 2.3.3.1} be discernable, legible, and 

unambiguous within all flight environments (e.g., ambient illumination), even when 

displayed in combination with other information (e.g., electronic map). 

The CDTI and associated alerting should {317A.Section 1.5.2.4} be properly integrated 

with other display functions and should not interfere with critical functions or other 

alerting. 

The CDTI should {289.Section 2.4.3.5} be designed so as to maximize usability, 

minimize flight crew workload, and reduce flight crew errors. 

The CDTI display should {289.Section 2.4.3.5} be consistent with the requirements of 

current airborne display standards. 

If non-traffic information is integrated with the traffic information on the display, the 

directional orientation, range, and own-ship position shall (R3.xxx) {317A.3117} be 

consistent among the different information sets. 

Any probable failure of the CDTI shall (R3.xxx) {317A.7005} not degrade the normal 

operation of equipment or systems connected to it. 

The failure of interfaced equipment or systems shall (R3.xxx) {317A.7006} not degrade 

normal operation of the CDTI. 

3.4.2.2 Time of Applicability 

The CDTI shall (R3.xxx) display all traffic and ownship state information extrapolated to 

a common time of applicability. 

Note: ASSAP delivers all traffic state data extrapolated to a common time of 

applicability. In some architectures, ASSAP will also deliver ownship state 

information extrapolated to the same time of applicability. 

3.4.2.3 Information Integrity 

The CDTI shall (R3.xxx) {289.R3.243} {317A.3014} display information with an 

integrity that meets the requirements of the installed applications. 

3.4.2.4 Applications Supported 

The CDTI shall (R3.xxx) {317A.3000} support the AIRB or the EVAcq application. 

Note: Other applications are optional. 

The CDTI may {317A.2.3.1} support any subset of the following additional applications: 

© 20xx, RTCA, Inc.

122 

1. Basic Surface Situation Awareness (SURF). 

2. Visual Separation on Approach (VSA). 

3. In-Trail Procedures (ITP). 

The CDTI shall (R3.xxx) not present conflicting information or guidance. 

Note: Installations supporting multiple applications or functional capabilities may 

require design considerations to ensure a clearly defined management of outputs 

from multiple applications or functional capabilities. 

3.4.2.5 Units of Measure 

The CDTI should {289.R3.258} portray data using units of measure that are consistent 

with the design of the flight deck in which it is installed. 

The CDTI shall (R3.xxx) portray all data using consistent units of measure and reference 

frames. 

3.4.2.6 Information Exchange with ASSAP 

The CDTI shall (R3.xxx) {317A.3015} accept all information provided to it by ASSAP. 

The CDTI shall (R3.xxx) {317A.2045} provide ASSAP the information needed for the 

activation and deactivation of applications, including those that operate on specifically 

selected and/or designated traffic. 

3.4.2.7 Traffic Symbols 

The Traffic Display shall (R3.xxx) {289.R3.236} {317A.3035} display one traffic 

symbol for each traffic report received from ASSAP that meets the traffic display criteria 

for the active applications subject to the maximum number of traffic symbols. 

The Traffic Display shall (R3.xxx) be capable of displaying the minimum number of 

traffic symbols commensurate with the requirements of the installed applications. 

3.4.2.8 TCAS Integration 


On TCAS-integrated CDTI systems, the CDTI shall (R3.xxx) prioritize the display of 

TCAS information in such a manner as to preserve the integrity of the safety objectives 

for TCAS. 

In order to provide more complete traffic situational awareness, the CDTI should 

{289.Section 2.2.2.5.1.15}, on aircraft also equipped with TCAS, integrate the display of 

TCAS information.

3.4.2.9 Multi-Function Display (MFD) Integration 

123 

Symbols, colors, and other encoded information that have a certain meaning in the traffic 

display function should not {317A.Section 2.3.8.1} have a different meaning in another 

MFD function. 

The MFD system should {317A.Section 2.3.8.1} provide the capability to enable and 

disable display of traffic information (i.e., to overlay traffic or turn traffic information 

off). 

3.4.2.10 Failure Annunciation 

The CDTI shall (R3.xxx) be capable of annunciating all failure / abnormal conditions of 

the CDTI or its inputs that affect the proper operation of the CDTI or the ability to 

conduct applications, including the loss of surveillance data needed for an application. 

3.4.2.11 Suitability of Traffic for Applications 

If any additional applications are installed (more stringent than AIRB or EVAcq), the 

CDTI system shall (R3.xxx) {317A.3052} have a means to determine the traffic’s 

application capability with respect to each installed application. 

3.4.2.12 Warnings and Alerts 

The CDTI shall (R3.xxx) provide sufficiently and appropriately salient warnings and 

alerts for all warning and alert conditions. 

The CDTI shall (R3.xxx) provide sufficient awareness as to the causes for the warnings 

and alerts. 

Aural alerts shall (R3.xxx) {317A.3103} be audible and distinguishable in all expected 

flight deck ambient noise conditions. 

CDTI alerts should {289.Section 2.3.6.5} be consistent with, and capable of being 

integrated into the flight deck alerting system, giving proper priority to alerts with regard 

to safety of flight. 

3.4.2.13 Display Configuration 

The CDTI shall (R3.xxx) be configurable as necessary to support the installed 

applications. 

The CDTI shall (R3.xxx) provide a sufficient set of controls to enable and disable all 

configurations, enable and disable all installed applications and to exercise all of its 

features. 

The CDTI shall (R3.xxx) provide a sufficient set of indications to portray the CDTI’s 

current configuration and the status of installed applications in a readily appreciable 

manner. 

© 20xx, RTCA, Inc.

124 

3.4.2.14 Accessibility of Controls 

The CDTI shall (R3.xxx) be designed so that controls intended for use during flight 

cannot be operated in any position, combination or sequence that would result in a 

condition detrimental to the operation of the aircraft or the reliability of the equipment. 

3.4.2.15 Information Displayed 

The CDTI shall (R3.xxx) be capable of displaying the types of information needed for 

the execution of the installed applications. 

Note: Extensive, detailed requirements can be found in the latest version of the ASA 

MOPS, RTCA DO-317(). 

3.4.2.16 General CDTI Symbol Requirements 

Each CDTI symbol shall (R3.xxx) {317A.3022} be identifiable and distinguishable from 

other CDTI symbols. 

The shape, color, dynamics, and other symbol characteristics should {317A.Section 

2.3.3.4} have the same meaning within the CDTI. 

CDTI symbol modifiers should {317A.Section 2.3.3.4} follow rules that are consistent 

across the symbol set. 

If symbols are used to depict elements that have standard symbols (such as navigational 

fixes), the CDTI should {289.Section 3.3.3.1.2} use symbols that are consistent with 

established industry standards. 

The CDTI system should {317A.Section 2.3.8} be consistent with the rest of the flight 

deck in terms of color, standardization, automation, symbology, interaction techniques 

and operating philosophy. 

3.4.2.17 CDTI Design Assurance 

The CDTI shall (R3.xxx) be designed such that the probability of providing misleading 

information and the probability of loss of function are acceptable for the most stringent 

application supported. 

3.4.2.18 Ownship State Information 


The CDTI may receive ownship state (horizontal and vertical position, direction and 

speed) from ASSAP, in which case ASSAP also provides validity status of that 

information. Alternatively, the CDTI may receive ownship state information from other 

onboard sources. In the latter case, the CDTI shall (R3.xxx) receive valid status of the 

ownship information from the onboard sources and/or perform an appropriate validation 

of the information.

3.4.3 Subsystem Requirements for ADS-B 

125 

This section describes ADS-B system requirements. Specifications in this document are 

intended to be design independent. Surveillance coverage as well as information 

exchange requirements for the defined equipage classes are contained in this section. 

Additionally, performance requirements including report accuracy, update period and 

acquisition range are provided. Other performance considerations are provided including 

ADS-B link capacity, ADS-B medium requirements and ADS-B quality of service. 

Additional information on design considerations are contained in appendices. Appendix 

D discusses antenna considerations and the use of receive antenna pattern shaping to 

increase aircraft-to-aircraft forward sector operational range. Acquisition and tracking 

considerations are discussed in Appendix F. Additional design considerations and 

analysis related to ADS-B equipage class capabilities is contained in appendices in 

RTCA DO-242A. 

3.4.3.1 ADS-B Surveillance Coverage 

Air-to-air coverage requirements for illustrative operational scenarios were given in 

Table 2-8, and values associated with current ATS surveillance capabilities were 

summarized in Table 2-9(a). Transmitter and receiver requirements follow from these 

coverage requirements. Ideally, all airborne participants would have the same transmitter 

power and same receiver sensitivity. Recognizing, however, that lower equipage costs 

may be achieved with lower transmit power and receiver sensitivity, surveillance 

coverage requirements are based on minimum acceptable capability. Users interested in a 

certain level of operational capability can thus select an equipage class appropriate to 

their needs (see Table 3.1.1.3.2a). 

ADS-B equipage classes summarized in Table 3.1.1.3.2a shall {242AR3.1} provide the 

air-to-air coverage specified in Table 3.4.3.1a. The stated ranges are the basis for the 

indicated relative effective radiated power (ERP) and the receiver sensitivity requirement 

for each transmit unit. 

Since many users will share the same airspace, and all must be seen by ATS, all A, B, 

and C equipage classes must be interoperable. The ERP and minimum signal detection 

capabilities shall {242AR3.2} support the associated pair-wise minimum operational 

ranges listed in Table 3.4.3.1b. Broadcast only aircraft (class B0 and B1) shall 

{242AR3.3} have ERP values equivalent to those of class A0 and A1, respectively, as 

determined by own aircraft maximum speed, operating altitude, and corresponding 

coverage requirements. Ground vehicles operating on the airport surface (class B2) shall 

{242AR3.4} provide a 5 NM coverage range for class A receivers. If required due to 

spectrum considerations, ADS-B transmissions from ground vehicles (class B2) shall 

{242AR3.5} be automatically prohibited when those vehicles are outside the surface 

movement area (i.e., runways and taxiways). ERP for these vehicles may thus be as low 

as -12 dB relative to class A1. Fixed obstacle (class B3) broadcast coverage shall 

{242AR3.6} be sufficient to provide a 10 NM coverage range from the location of the 

obstacle. 

Following is the rationale for the powers and ranges in Table 3.4.3.1a and Table 3.4.3.1b. 

Given the air-to-air ranges from Table 2-8, and repeated in Table 3.4.3.1a, an acceptable 

range of relative transmitter power was assumed, and appropriate receiver sensitivities 

were then derived. From these normalized transmitter power and receiver sensitivity 

© 20xx, RTCA, Inc.

126 


values, the interoperability ranges shown in Table 3.4.3.1b were derived. An omnidirectional 

aircraft transmit antenna is required for ATS support. While omni-directional 

receive antennas will generally be employed, a higher gain receive antenna may be used 

to increase coverage in the forward direction for extended range air-to-air applications (at 

the expense of reduced coverage in other directions). Appendix E discusses the impact of 

this directional antenna on alert time and shows that a directional aircraft receive antenna 

gain increase is limited to about 4 dB. When determining absolute power and sensitivity 

for the operational ranges given in Table 3.4.3.1a, it should be noted that the target 

should be acquired and under firm track at the indicated ranges. This implies that an 

additional margin for acquisition time is required. The ranges specified in Table 3.4.3.1a 

and Table 3.4.3.1b are minimum requirements; other applications may require longer 

ranges. 

Ground receiver only subsystem (class C1) coverage examples are given in Table 2-9(a). 

Since en route air-ground ranges are longer than those for air-to-air, some ATS receivers 

must be more sensitive than airborne receivers. This need may be met with the aid of 

higher gain ground receive antennas. It is beyond the scope of these MASPS to specify 

ground receiver sensitivities (Class C). 

Table 3.4.3.1a: Operational Range and Normalized Transmit/Receive Parameters 

by Interactive Aircraft Equipage Class 

Equipage 

Required 

Range 

(NM) 

Transmit 

ERP 

relative to 

P0 (dB) 

Receive 

Sensitivity 

relative to 

S0 (dB) 

Class Type 

A0 Minimum 10 >= -2.5 +3.5 

A1 Basic 20 0 0 

A2 Enhanced 40 +3 -3 

A3 Extended 90

Table 3.4.3.1b: Interoperability Ranges in NM for Aircraft Equipage Class Parameters 

Given in Table 3.4.3.1a 

Rx Aircraft � 

Tx Aircraft ERP 

A0: Minimum 

(P0-2.5dB) 

A1: Basic 

(P0) 

A2: Enhanced 

(P0+3dB) 

A3: Extended 

(P0+6dB) 

A3+: 

Extended Desired 

(P0+6dB) 

A0 

Minimum 

(S0+3.5dB) 

A1 

Basic 

(S0) 

A2 

Enhanced 

(S0-3dB) 

A3 

Expanded 

(S0-7dB) 


127 

A3+ 

Expanded 

Desired 

(S0-9.5dB) 

10 15 21 34 45 

13 20 28 45 60 

18 28 40 64 85 

26 40 56 90 120 

26 40 56 90 120 

3.4.3.2 ADS-B Information Exchange Requirements by Equipage Class 

Subsystems must be able to (1) broadcast at least the minimum set of data required for 

operation in airspace shared with others, and (2) receive and process pair-wise 

information required to support their intended operational capability. Each equipage 

class shall {242AR3.7} meet the required information broadcast and receiving capability 

at the indicated range to support the capability indicated in Table 3.4.3.2a and Table 

3.4.3.2b. 

The rationale for the requirements in Table 3.4.3.2a is as follows. Column 1 of Table 

3.4.3.2a combines the equipage classes (which are based on user operational interests) 

from Table 3.1.1.3.2a with the required ranges given in Table 3.4.3.1a. Information 

exchange requirements by application were taken from Table 2-7 to determine the 

broadcast and receive data required for each equipage class (column 2 of Table 3.4.3.2a 

and Table 3.4.3.2b). A correlation between the equipage class and the ability of that class 

to support and perform that application was done next. (The determination of the 

information exchange ability of an equipage class to support a specific application is 

determined by the information transmitted by that equipage class, while the ability to 

perform a specific application is determined by the ability of that equipage class to 

receive and process the indicated information.)

Equipage Class 

� 

A0 

Minimum 

R�10 NM 

A1 

Basic 

R�20 NM 

A2 

Enhanced 

R�40 NM 

A3 

Extended 

R�90 NM 

Notes: 

Table 3.4.3.2a: Interactive Aircraft/Vehicle Equipage Type Operational Capabilities 

Domain � Terminal, En Route, Oceanic Approach Airport Surface 

Data Required to 

Support Operational 

Capability 

Transmit Receive 

SV 

MS 

SV 

MS 

SV 

MS 

TS 

SV 

MS 

TS 

SV 

MS 

SV 

MS 

SV 

MS 

TS 

SV 

MS 

TS 

R �10 NM 

e.g., Enhanced 

Visual 

Acquisition 

Support 

Perform 

Support 

R �20 NM 

Perform 

1. SV= State Vector Report; MS = Mode Status Report; TS = Target State Report. 

R �40 NM 

Support 

Perform 

Support 

R �90 NM 


R �10 NM 


Visual Approach 

Support 


R �5 NM 

e.g., Airport 

Surface Situation 

Awareness 

Yes Yes Yes No No No No No No No Yes Yes 

Yes Yes Yes Yes No No No No Yes Yes Yes Yes 

Yes Yes Yes Yes Yes Yes No No Yes Yes Yes Yes 

Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes 

2. A transmitting ADS-B participant supports an application by broadcasting the required data that receiving ADS-B participants need for that application. 

3. A receiving ADS-B participant performs an application by processing received messages from transmitting ADS-B participants that support that application. 

4. Operation in airspace with high closure rates may require longer range. 

5. Class A2 and A3 users may equip for low visibility taxi following. 

6. Class A1 equipment may optionally support TS reports. 

7. MS reports contain time-critical report elements that, when their values change, need to be updated at higher rates than that of the MS reports. See §3.5.4.1, 

§3.5.8.5, and §3.5.8.6 for details.) 


Support 

Perform


� 

B0 


R�10 NM 

B1 


R�20 NM 

B2 

Ground Vehicle 

B3 

Fixed Obstacle 

C1 

ATS En route & 

Terminal 

C2 

Approach & 

Surface 

C3 

Flight Following 

Notes: 

Table 3.4.3.2b: Broadcast and Receive Only Equipage Type Operational Capabilities 

Domain � Terminal, En Route, and Oceanic / Remote Non-Radar Approach 

Data Required to 

Support Operational 

Capability 

Transmit Receive 

SV 

MS 

SV 

MS 

SV 

MS 

SV 

MS 

No 

No 

No 

R � 10 NM 

e.g., 

Enhanced 

Visual 

Acquisition 

Support 


R � 20 NM 

Support 


R � 40 NM 

Support 


R � 90 NM 

Support 


R � 10 NM 



Support 


Airport 

Surface 

R � 5 NM 

e.g., Airport 

Surface 

Situation 

Awareness 

SupPerportform No Yes No Yes No No No No No No No Yes No 

No Yes No Yes No No No No No No No Yes No 



SV 

MS 

TS 

SV 

MS 

TS 

SV 

MS 

No Yes No Yes No Yes No Yes No No No No 

No Yes No Yes No No No No No Yes No Yes 

No Yes No No No No No No No No No No 

1. SV= State Vector; MS = Mode Status; TS = Target State Report 

2. A transmitting ADS-B participant supports an application by broadcasting the required data that receiving ADS-B participants need for that application. 

3. A receiving ADS-B participant performs an application by processing received messages from transmitting ADS-B participants that support that application. 

� 20xx, RTCA, Inc.

3.4.3.3 ADS-B Data Exchange Requirements 

3.4.3.3.1 Report Accuracy, Update Period and Acquisition Range 

The subparagraphs below specify the report accuracy, update period, and acquisition 

range requirements for state vector, modes status, and specific on-condition reports. For 

each of these subparagraphs, report acquisition shall {242AR3.8} be considered 

accomplished when all report elements required for an operational scenario have been 

received by an ADS-B participant. In order to meet these requirements, the receiving 

participant must begin receiving messages at some range outside the minimum range for 

a given application. Appendix F illustrates examples of expected acquisition time for 

state vector, mode-status, and on-condition reports as a function of message period and 

probability of receipt. Appendix F also treats the necessary acquisition time for 

segmented state vector messages. 

3.4.3.3.1.1 State Vector Report Acquisition, Update Interval and Acquisition Range 

� 20xx, RTCA, Inc. 

State vector (SV) report accuracy, update period and acquisition range requirements are 

derived from the sample scenarios of Chapter 2, and are specified in Table 3.4.3.3.1.1a. 

The state vector report shall {242AR3.9} meet the update period and 99 percentile 

update period requirements for each operational range listed. The rationale for these 

values is given in RTCA DO-242A, Appendix J. The formulation in RTCA DO-242A, 

Appendix J examines the loss of alert time resulting from data inaccuracies, report update 

interval, and probability of reception. The scope of the analysis was not sufficient to 

guarantee that the specific operations considered will be supported. Several range values 

are specified in the table because the alert time requirements are more demanding for 

short range than they are for surveillance of targets at longer ranges. The first value is 

based on minimum range requirements. Beyond this range, update period and/or receive 

probability may be relaxed for each sample scenario, as given by the other values. 

For each of the scenarios included in Table 3.4.3.3.1.1a, the state vectors from at least 

95% of the observable user population (radio line-of-sight) supporting that application 

shall {242AR3.10} be acquired and achieve the time and probability update requirements 

specified for the operational ranges. The state vector report is constantly changing and is 

important to all applications, including the safety critical ones. Algorithms designed to 

use the state vector reports will assume that the information provided is correct. (Some 

applications may even require that the information is validated before using it.) 

Note: For the remainder of the user population that has not been acquired at the 

specified acquisition range, it is expected that those ADS-B participants will be 

acquired at the minimum ranges needed for safety applications. It is anticipated 

that certain of these safety applications that are applicable in en route and 

potentially certain terminal airspace, may require that 99% of the airborne ADS- 

B equipped target aircraft in the surrounding airspace are acquired at least 2 

minutes in advance of a predicted time for closest point of approach. This 

assumes that the target aircraft will have been transmitting ADS-B for some 

minutes prior to the needed acquisition time and are within line-on-sight of the 

receiving aircraft. 

Required ranges for acquisition shall {242AR3.11} be as specified in Table 3.4.3.3.1.1a: 

(10 NM for A0, 20 NM for A1, 40 NM for A2, and 90 NM for A3).

Table 3.4.3.3.1.1a shows accuracy values in two ways: one describing the ADS-B report 

information available to applications, and the other presenting the error budget 

component allocated to ADS-B degradation of this information. The ADS-B system 

shall {242AR3.12} satisfy the error budget requirements specified in the table in order to 

assure satisfaction of ADS-B report accuracies. Degradation is defined here to mean 

additional errors imposed by the ADS-B system on position and velocity measurements 

above the inherent navigation source errors. The errors referred to in this section are 

specifically due to ADS-B quantization of state vector information, and other effects such 

as tracker lag. ADS-B timing and latency errors are treated as a separate subject under 

heading §3.4.3.3.2. The maximum errors specified in Table 3.4.3.3.1.1a are limited to 

contributions from the following two error sources: 

� Quantization errors. The relationship between the quantization error and the number 

of bits required in the ADS-B message are described in Appendix D. This discussion 

also treats the effect of data sampling time uncertainties on report accuracy. 

� Errors due to a tracker. The ADS-B system design may include a smoothing filter or 

tracker as described in Appendix D. If a smoothing filter or tracker is used in the 

ADS-B design, the quality of the reports shall {242AR3.13} be sufficient to provide 

equivalent track accuracy implied in Table 3.4.3.3.1.1a over the period between 

reports, under target centripetal accelerations of up to 0.5g with aircraft velocities of 

up to 600 knots. Tracker lag may be considered to be a latency (§3.4.3.3.2). 



� 

Table 3.4.3.3.1.1a: SV Update Interval and Acquisition Range Requirements 

Terminal, En Route, and Oceanic / Remote Non-Radar � Approach � 

Airport 

Surface � 

(Note 4) 

Applicable Range � R � 10 NM 10 NM < R � 20 NM 20 NM < R � 40 NM 40 NM < R � 90 NM R � 10 NM (R � 5 NM) 

Equipage Class � 

Example 

Applications � 

Required 95 th 

percentile SV 

Acquisition Range 

Required SV 

Nominal Update 

Interval 

(95th percentile) 

(Note 5) 

Required 99th 

Percentile SV 

Received Update 

Period 

(Coast Interval) 


A0-A3 

B0, B1, B3 

A1-A3 

B0, B1, B3 

Airborne Conflict Management (ACM) 

Enhanced 

Visual 

Acquisition 

Standard Range 

10 NM 20 NM 

� 3 s (3 NM) 

� 5 s (10 NM) 

(Note 11) 

� 6s (3 NM) 

� 10 s 

(10 NM) 

(Note 11) 

� 5 s (10 NM) 

(1 s desired, 

Note 2) 

� 7 s 

(20 NM) 

� 10 s (10 NM) 

� 14 s (20 NM) 

Definitions for Table 3.4.3.3.1.1a: 

A2-A3 A3 A1-A3 

Long Range 

Applications 

40 NM 

(Note 12) 

(50 NM desired) 

� 7 s (20 NM) 

� 12 s (40 NM) 

� 14 s (20 NM) 

� 24 s (40 NM) 

σhp: standard deviation of horizontal position error. 

σhv: standard deviation of horizontal velocity error. 

σvp: standard deviation of vertical position error. 

σvv: standard deviation of vertical velocity error. 

n/a: not applicable. 

Notes for Table 3.4.3.3.1.1a: 

Extended Range 

Applications 

90 NM 

(Notes 3, 10) 


� 12 s 

� 24 s 

AILS, 

Paired 

Approach 

A0-A3 

B0, B1, B3 

Surface 

Situational 

Awareness 

10 NM 5 NM 

� 1.5 s 

(1000 ft 

runway 

separation) 

� 3 s 

(1s desired) 

(2500 ft 

runway 

separation) 

� 3s 

(1000 ft 

runway 

separation) 

(1s desired, 

Note 2) 

� 7s 

(2500 ft 

runway 

separation) 

1. The lower number represents the desired accuracy for best operational performance 

and maximum advantage of ADS-B. The higher number, representative of GPS 

standard positioning service, represents an acceptable level of ADS-B performance, 

when combined with barometric altimeter. 

� 1.5 s 

� 3 s

2. The analysis in RTCA DO-242A, Appendix J indicates that a 3-second report 

received update period for the full state vector will yield improvements in both 

safety and alert rate relative to TCAS II, which does not measure velocity. Further 

improvement in these measures can be achieved by providing a one-second report 

received update rate. Further definition of ADS-B based separation and conflict 

avoidance system(s) may result in refinements to the values in the Table. 

3. The 90 NM range requirement applies in the forward direction (that is, the direction 

of the own aircraft’s heading). The required range aft is 40 NM. The required 

range 45 degrees to port and starboard of the own aircraft's heading is 64 NM (see 

Appendix D). The required range 90 degrees to port and starboard of the own 

aircraft’s heading is 45 NM. [The 120 NM desired range applies in the forward 

direction. The desired range aft is 42 NM. The desired range 45 degrees to port 

and starboard of the own-aircraft’s heading is 85 NM.] 

4. Requirements apply to both aircraft and vehicles. 

5. Supporting analyses for update period and update probability are provided in 

RTCA DO-242A, Appendices J and L. 

6. Specific system parameter requirements in Table 3.4.3.3.1.1a can be waived 

provided that the system designer shows that the application design goals stated in 

RTCA DO-242A, Appendix J, or equivalent system level performance can be 

achieved. 

7. Air-to-air ranges extending to 90 NM were originally intended to support the 

application of Flight Path Deconfliction Planning, Cooperative Separation in 

Oceanic/Low Density En Route Airspace, as described in RTCA DO-242A, §2.2.2.6. 

It is noted in RTCA DO-242A, §2.2.2.6, in connection with Table 2-8, 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. 

8. Requirements for applications at ranges less than 10 NM are under development. 

The 3-second update period is required for aircraft pairs with horizontal separation 

less than [1.1 NM] and vertical separation less than [1000 feet]. The 3 second 

update period is also required to support ACM for aircraft pairs within 3 NM 

lateral separation and 6000 feet vertical separation that are converging at a rate of 

greater than 500 feet per minute vertically or greater than 6000 feet per minute 

horizontally. The update rate can be reduced to once per 5 seconds (95%) for 

aircraft pairs that are not within these geometrical constraints and for applications 

other than ACM. Requirements for ACM are under development. Requirements for 

future applications may differ from those stated here. 

9. These values are based on the scenario in RTCA DO-242A, §2.2.2.5.2 which 

assumes a reduced horizontal separation standard of 2 NM. Separation standards 

of more than 2 NM may require longer acquisition ranges to provide adequate 

alerting times. 


3.4.3.3.1.2 Mode Status Acquisition, Update Interval and Acquisition Range 


� 

Mode Status (MS) acquisition range requirements are derived from the sample scenarios 

of Chapter 2, and are specified in Table 3.4.3.3.1.2a. For each of the equipage classes 

included in Table 3.4.3.3.1.2a, the Mode Status reports from at least 95% of the 

observable (radio line of sight) population shall {242AR3.14-A} be acquired at the range 

specified in the “Required 95th Percentile Acquisition Range” row of Table 3.4.3.3.1.2a 

(10 NM for A0, 20 NM for A1, 40 NM for A2, and 90 NM for A3). Likewise, for each 

of the equipage classes included in Table 3.4.3.3.1.2a, the Mode Status reports from at 

least 99% of the observable (radio line of sight) population shall {242AR3.14-B} be 

acquired at the reduced range specified in the “Required 99th Percentile Acquisition 

Range” row of Table 3.4.3.3.1.2a. 

Note: As requirements mature for applications that require MS reports, the required 

probably of acquisition at specified ranges may change. It is possible that these 

requirements may be more stringent in later versions of these MASPS. 

Mode Status (MS) update intervals are not specified directly. Only the minimum 

acquisition ranges are specified. From these minimum ranges, combinations of update 

intervals and receive probabilities for MS can be derived for media specific ADS-B 

implementations. 

Table 3.4.3.3.1.2a: MS Acquisition Range Requirements 

Terminal, En Route, and Oceanic / Remote Non-Radar � Approach � 

Airport 

Surface � 

(Note 1) 

Applicable Range � R � 10 NM 10 NM < R � 20 NM 20 NM < R � 40 NM 40 NM < R � 90 NM R � 10 NM (R � 5 NM) 


Note XX � 

Example 

Applications � 


percentile MS 



percentile MS 


(Notes 4, 5) 


A0-A3 

B0, B1, B3 

A1-A3 

B0, B1, B3 

Airborne Conflict Management (ACM) 

Enhanced 

Visual Standard Range 

Acquisition 

10 NM 20 NM 

8 NM 17 NM 

Definitions for Table 3.4.3.3.1.2a: 

n/a: not applicable. 

Notes for Table 3.4.3.3.1.2a: 

A2-A3 A3 

Long Range 

Applications 

40 NM 

(Note 6) 


34 NM 

(Note 6) 

Extended Range 

Applications 

90 NM 

(Notes 2, 3) 


A1-A3 

B2 ?? 

AILS, 

Paired 

Approach 

A0-A3 

B0, B1, B3 

B2 ?? 

Surface 

Situational 

Awareness 

10 NM 5 NM 

n/a n/a n/a 

1. Requirements apply to both aircraft and vehicles. Also, the minimum range required 

may apply even in high interference environments, such as over-flight of high traffic 

density terminal areas.

2. The 90 NM range requirement applies in the forward direction (that is, the direction 

of the own aircraft’s heading). The required range aft is 40 NM. The required range 

45 degrees to port and starboard of the own aircraft's heading is 64 NM (see 

Appendix D). The required range 90 degrees to port and starboard of the own 

aircraft’s heading is 45 NM. [The 120 NM desired range applies in the forward 

direction. The desired range aft is 42 NM. The desired range 45 degrees to port and 

starboard of the own-aircraft’s heading is 85 NM.] 

3. Air-to-air ranges extending to 90 NM are intended to support the application of 

Cooperative Separation in Oceanic/Low Density En Route Airspace, as described in 

RTCA DO-242A, §2.2.2.6. It is noted in RTCA DO-242A, §2.2.2.6, in connection 

with Table 2-8, 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. 

4. These requirements are to be met for essential level applications. As these 

applications are developed, these requirements may be further refined in terms of 

more stringent ranges and acquisition probability. 

5. It is assumed that the population for which these acquisition requirements is to be 

met are aircraft that have been operating and broadcasting MS reports within radio 

line of sight at ranges significantly greater than the acquisition range. 

6. These values are based on the scenario in RTCA DO-242A, §2.2.2.5.2 which assumes 

a reduced horizontal separation standard of 2 NM. Separation standards of more 

than 2 NM may require longer acquisition ranges to provide adequate alerting times. 

3.4.3.3.1.3 Target State Report Acquisition, Update Interval and Acquisition Range 

� Editor’s Note: We need to scrub this section and probably remove the performance 

derivation. Pull this out and establish a new Appendix � 

Target State (TS) report update periods and acquisition range requirements are 

summarized in Table 3.4.3.3.1.3a. These requirements are specified in terms of 

acquisition range and required update interval to be achieved by at least 95% of the 

observable user population (radio line of sight) supporting TS within the specified 

acquisition range or time interval. 







minutes in advance of a predicted time for the when loss of required separation 

will occur. This assumes that the target aircraft will have been transmitting 

ADS-B for some minutes prior to the needed acquisition time and are within lineon-sight 

of the receiving aircraft. 

The requirements for the minimum update periods for TS reports are functions of range. 

Tighter requirements (smaller required update periods) are desired on these reports for a 

time period equal to two update periods immediately following any major change in the 

information previously broadcast as specified in §3.4.7.2 and §3.4.8.2. These 


equirements are specified in terms of acquisition range and required update interval to 

achieve a 95% confidence of receiving a TS within the specified acquisition range or time 

interval. 

The nominal TS report update period for A2 equipage at ranges within 40 NM and for A3 

equipage at ranges in the forward direction within 90 NM shall {242AR3.21} be TU, 

such that 

T U 

� 

s � 

� max �12 

s, 

0. 

45 � R� 

� NM � 

where R is the range to the broadcasting aircraft and TU is rounded to the nearest whole 

number of seconds. If implemented, these requirements are applicable to TS report 

update rates for A1 equipment for ranges of 20 NM or less. 

Notes: 


1. It is desired that requirement 242AR3.21 should be met by A2 equipment at ranges 

up to and including 50 NM and by A3 equipment up to and including 120 NM. 

2. Future versions of these MASPS might include higher update rates when there is a 

major change in the intent information being broadcast. Rates in the order of 

� 

s � 

TU � max �12 

s, 

0. 

22 � R� 

are under investigation for future applications 

� NM � 

and should be considered desired design goals. 

Table 3.4.3.3.1.3a shows the values for the required minimum update periods as 

calculated by the above formulae at the ranges indicated as required and desired for A2 

and A3 aircraft. 

If the TS report is implemented in ADS-B systems of equipage class A1, such systems 

shall {242AR3.22} have a 20 NM acquisition range for TS Report. For equipage class 

A2, the acquisition range for TS reports shall {242AR3.23} be 40 NM, with 50 NM 

desired. For equipage class A3, the acquisition range for TC reports in the forward 

direction shall {242AR3.24} be 90 NM, with 120 NM desired. The range requirements 

in all other directions for A3 equipment shall {242AR3.25} be consistent with those 

stated in Note 3 of Table 3.4.3.3.1.3a.

Table 3.4.3.3.1.3a: Summary of TS Report Acquisition Range and Update Interval 

Requirements 

Operational 

Domain � 

Applicable Range 

� 


� 

TS Report 

Acquisition 

Range 

TS Report state 

change update 

period 

(note 3) 

TS Report 

nominal update 

period 

R � 20 NM 

A1 optional 

A2 required 

20 NM 

(A1 optional) 

12 s 

Terminal, En Route, and Oceanic / Remote Non-Radar � 

R


The scenario representing the highest current traffic density, and the highest expected 

future ADS-B interference environment was derived from a review of ATC traffic level 

records as well as flight test data. The highest traffic density has been experienced in the 

Northeast Corridor so this air volume has been used as the basis for link capacity analysis 

and future traffic prediction. A baseline traffic scenario in the dense Northeast Corridor 

has been established from data collected during a July 2007 Northeast Corridor test 

flight. The traffic distribution was captured by taking ‘snapshots’ of all aircraft seen by 

as many as 33 En Route and terminal SSRs that provided coverage of the core area of 

interest. The composite picture was created by converting the measured SSR coordinates 

of all the aircraft at the time of the snapshot into latitude and longitude, superimposing 

the aircraft seen by all the SSRs, and eliminating duplicate reports of the same aircraft as 

seen by multiple SSRs. 

Figure xx shows the number of aircraft as a function of horizontal range from N39 (the 

test aircraft), the Newark airport (EWR) SSR site (which generally had the highest 

number of aircraft in view), and several other reference points. N39 was approximately 

10 NM from EWR at the time of the snapshot. At this time, there were 10 aircraft within 

6 NM of N39. A victim receiver over EWR would have had three aircraft within 6 NM 

at this time. 

An approximate analytic fit to the data in the region around EWR is also shown on the 

plot. This general model, normalized to the test data, is given by: 

No �� 750 Ro �� 200 � �� 0.2 

� � 1 

nd No 

� 1 

Ro � 

�� 

( ) 

nd � 1.56 �( R) 

nd R � 

�� 

N( R) 

R 

� 

�� ( R) 

dR 

� 

0 

where No is the total traffic count within a range, Ro, and ζ is the empirically determined 

traffic distribution shape factor.

Instaneous air count 

800 

700 

600 

500 

400 

300 

200 

100 

Relative to N39 

Relative to EWR 

Relative to JFK 

Relative to PHL 

Relative to BWI 

Approx fit 

0 

0 25 50 75 100 125 150 175 200 

Range from reference point, NM 

Figure xx: Radial traffic distributions during Northeast Corridor test flight 

The traffic in view is also restricted by the line of sight range limit at lower altitudes or at 

ground sites. The fraction of traffic subjected to this limit depends on the altitude 

distribution of the traffic. An exponential altitude cumulative distribution model was 

initially fit to earlier New York regional collected data used as an input into Standard 

Terminal Automation Replacement System (STARS) processing load requirements 

determinations. The model is given by: 

C �� 0.09 p( h) 

Ce C � h � 

�� 

F( H) 

H 

� 

�� ph ( ) dh 

� 

0 

This model is shown in Figure zz to be in good agreement with measurements made 

during the 2007 test flight. 


Cumulative Distribution 


1 

FH ( ) 

Fm 

0 

0.8 

0.6 

0.4 

0.2 

0 

0 10 20 30 

0 H�Hm Altitude (1000 ft) 

Model Ca = 0.09 

EWR measured p 330 

Figure zz: Cumulative Altitude Distribution Model vs. 25Jul07 Data 

Future traffic levels in each region of the NAS are estimated by each ATC Traffic 

Control Center based on forecast growth rates of each airborne user class – commercial, 

general aviation, and military. These growth rates are sensitive to economic conditions 

as illustrated by a review of predicted growths over the last ten or so years. Recent 

growth rates forecast for the New York Center, ZNY, are compared in Figure yy with 

historical high and low estimates. 

Future traffic models may be determined from these forecasts and the analytic fit to the 

current radial traffic distribution under the assumption that although the overall density 

will increase, the general horizontal and altitude distribution shapes will remain relatively 

unchanged. This just requires multiplication of the reference traffic count by the 

appropriate growth factor. Local adjustments to these results may be prudent for some 

applications of the model to assure nearby traffic densities are consistent with separation 

standards and ATC practices. 

Interference estimates may also depend on the types of ADS-B users. Some change in 

this traffic mix is expected over the out years due to differences in user class growth 

rates. For example, while 82% of the current ZNY IFR handles are commercial aircraft, 

this is expected to increase to 84.5% in FY2025, and 85.1% in 2030. The general 

aviation fraction of the population will experience a slight decline from the current level 

of 12% to 11.3% in 2030. The military percentages over this period will drop from the 

current 6% to 3.6% in 2030. 

40 

40

Growth Factor GNY( ma �� ) ( 1 � a) 

m 

�� Future year FY( m) 

�� 2010 � m 

FY2011 ZNYY IFR forecast avg annual % growth, a = 2.8% for 2010-2030 

FY2010 ZNY IFR forecast avg annual % growth, a = 3.1% for 2009-2030 

Forecast traffic growth factor 

2.5 

2.4 

2.3 

2.2 

2.1 

2 

1.9 

1.8 

1.7 

1.6 

1.5 

1.4 

1.3 

1.2 

1.1 

3.4.3.5 ADS-B Medium 

Recent avg a = 2.95% 

FY08 high a = 4.1% 

FY02 low a 1.5% 

1 

2010 2012 2014 2016 2018 2020 2022 2024 2026 2028 2030 

Future year 

Traffic growth factor for recent average ZNY forecast IFR growth rate with 

historical high and low forecast bounds 

Figure yy: Recent ZNY traffic growth forecasts 

The ADS-B RF medium shall {242AR3.33} be suitable for all-weather operation, and 

ADS B system performance will be specified relative to a defined interference 

environment for the medium. Radio frequencies used for ADS-B Message transmission 

shall {242AR3.34} operate in an internationally allocated aeronautical radionavigation 

band(s). Appendix E summarizes certain antenna and multipath considerations that relate 

to the selection of a frequency band and message format. 

Note: The interference environment for a particular ADS-B medium will be specified in 

the relevant MOPS. 


3.4.3.6 ADS-B System Quality of Service 

3.4.3.6.1 Required Surveillance Performance 

The term Required Surveillance Performance (RSP) refers to capabilities of an airspace 

user to surveill other users and be surveilled by other users and ATS at a level sufficient 

for participation of the user in both strategic and tactical operations. RSP is intended to 

characterize aircraft path prediction capability and received accuracy, integrity, 

continuity of service, and availability of a surveillance system for a given volume of 

airspace and/or phase of operation. Important surveillance system parameters such as 

state vector report received update rate can be derived from the primary RSP parameters. 

Aircraft path prediction capability is defined by a 95 percent position uncertainty volume 

as a function of prediction time over a specified look ahead interval. Surveillance 

integrity (assurance of accurate, reliable information), where there is availability of 

service, must be defined consistent with the desired airspace application. Surveillance 

continuity of service and availability also must be defined consistent with the desired 

airspace application. 

ADS-B delivery technologies, data definition, and applications must conform to 

appropriate RSP specifications on an end-to-end basis. 

3.4.3.6.2 Failure Mode and Availability Considerations 


Navigation and radar surveillance in the horizontal dimensions are independent; this 

independence is beneficial under certain failure modes. Today, an aircraft with failed 

navigation capability may get failure mode recovery vectors from ATS based on 

SSR/PSR tracks. Today, an aircraft with a failed transponder may still report navigation 

based position information to ATS for safe separation from other traffic even if no PSR is 

available. On the other hand, a navigation capability failure in an ADS-B only 

surveillance environment results in both the aircraft and ATS experiencing uncertainty 

about the aircraft’s location. The operational impact of such a failure depends upon the 

nature of the failure: i.e., a single unit failure, or an area wide outage. Additional factors 

include the duration of the failure, the traffic density at the time of the failure, and the 

overall navigation and surveillance architecture. Detailed treatment of these issues 

should consider the failure mode recovery process in the context of the service outage 

duration and the total CNS environment. Figure 3-18 suggests how such a failure mode 

recovery process depends upon the total ATS architecture. Different states may 

implement different ATS architectures. 

It is anticipated that ADS-B will be used as a supplemental means of surveillance for 

some ATS-based airspace operations during a transition period leading to full ADS-B 

equipage. When used as a supplemental means of surveillance, ADS-B adds availability 

within a larger surveillance system. Primary means of surveillance is defined as a 

preferred means (when other means are available) of obtaining surveillance data for 

aircraft separation and avoidance of obstacles. Use of ADS-B as a sole means of 

surveillance presumes that aircraft can engage in operations with no other means of 

surveillance. If ADS-B were to be used as a sole means of surveillance, availability 

would be calculated using only ADS B, aircraft sources, and applications. ADS-B is not 

expected to be used as a sole means of ATS surveillance for the near future in US 

domestic airspace.

Where the ADS-B System is used as a supplemental means of surveillance, the ADS B 

system is expected to be available with a probability of at least 0.95 for all operations, 

independent of the availability of appropriate inputs to the ADS-B system. Where the 

ADS-B System is used as a primary means of surveillance, the system is expected to be 

available with a probability of at least 0.999 for all air-air operations. 

If an ADS-B system is used as a primary means of surveillance, then a supplemental 

surveillance system, independent of the navigation system, is expected to be available. 

The overall surveillance system will need to satisfy fail-safe operation of navigation and 

surveillance, i.e., a failure of the navigation system will not result in a failure of the 

surveillance function. This will enable ATS to provide an independent means of 

guidance to aircraft losing all navigation capability. The overall requirement for the 

surveillance system is adequate availability of the surveillance function, independent of 

navigation system availability. Where this requirement cannot be satisfied in a system 

intended for primary means of surveillance, the avionics and support infrastructure 

should be designed such that the simultaneous loss of both navigation and surveillance is 

extremely improbable. The expected availability of the total surveillance system is at 

least 0.99999, independent of navigation system availability. 

3.4.3.6.3 ADS-B Availability Requirements 

Availability is calculated as the ADS-B System Mean-Time-Between-Failures (MTBF) 

divided by the sum of the MTBF and Mean-Time-To-Restore (MTTR). ADS B equipage 

is defined to be available for an operation if the following conditions are met: (1) ADS B 

equipage outputs are provided at the rates defined in Table 3-4(a) through Table 3-4(e), 

and (2) the ADS B reports have the integrity required by §Section TBD. For the 

purposes of calculating availability, an ADS-B transmission subsystem is considered to 

be one participant’s message generation function and message exchange (transmission) 

function. An ADS B receiver subsystem is considered to be one participant’s message 

exchange (receiver) and one report generation function. 

ADS-B availability shall {242AR3.35} be 0.9995 for class A0 through class A3 and 

class B0 through class B3 transmission subsystems. ADS-B availability shall 

{242AR3.36) be 0.95 for class A0 receiver subsystems. Class A1, A2, and A3 receiver 

subsystems shall {242AR3.37} have an availability of 0.9995. The ADS-R Service shall 

(R3.xxx) have an availability of 0.99999. The TIS-B Service shall (R3.xxx) have an 

availability of 0.999 Specification of Class C receiver subsystem availability 

requirements are beyond the scope of this MASPS. 

High transmission availability (0.9995) is required of all classes in order to support the 

use of ADS-B as a primary means of surveillance for ATS. The combination of 0.9995 

availability of transmission and 0.9995 availability of receive for classes A1 through A3 

results in availability of 0.999, allowing the use of ADS-B as a primary means of 

surveillance for some air-to-air operations. A lower availability is permissible for Class 

A0 receiver subsystems as ADS-B is expected to be used as a supplemental, rather than 

as a primary tool of separation, for this class. 


Figure 3-18: GNSS/ADS-B Surveillance/Navigation Failure Recovery Modes 

3.4.3.6.4 ADS-B Continuity of Service 

The probability that the ADS B System, for a given ADS-B Message Generation 

Function and in-range ADS B Report Generation Processing Function, is unavailable 

during an operation, presuming that the System was available at the start of that 

operation, shall {242AR3.38} be no more than 2 x 10 -4 per hour of flight. The allocation 

of this requirement to ADS B System Functions should take into account the use of 

redundant/diverse implementations and known or potential failure conditions such as 

equipment outages and prolonged interference in the ADS B broadcast channel. 

3.4.3.6.5 Subsystem Reliability 


Each subsystem design should be capable of supporting ADS B system Quality of 

Service (QOS) described in §TBD. Specifications of each subsystem implementation 

will define requirements necessary to support the QOS. The subsystem should provide

eliability required for the intended service environment commensurate with the 

criticality levels supported. Requirements for single thread or redundant configurations 

will depend on the FAR category of the operator, the aircraft system approval 

requirements, and the airspace operations supported by the subsystems. 

MOPS or other subsystem specifications should provide definitive allocation of 

reliability factors considering failure probabilities, detected and undetected failure effects 

and probabilities specifically applicable to acquiring/transmitting and to 

receiving/reporting ADS B exchanged information. Reliability includes maintenance of 

integrity in the applicable broadcast exchange technology. Attributes of the subsystem 

and the specific exchange technology must be shown to meet the operational and system 

requirements of Section 2.2 and Section 3.4 respectively. These requirements apply 

between all subsystems on a pair-wise basis. Assumptions pertaining to reliable 

exchange of data intended for use in separation support will be required to support 

certification and operational approval. All MOPS or other specifications governing 

implementations should define major design assumptions, system/subsystem allocations 

and means to validate the subsystem results. 

3.5 Messages and Reports 

The ADS-B/TIS-B and ADS-R Receive Subsystem receives ADS-B, TIS-B and ADS-R 

Messages, processes them, and converts them into ADS-B/TIS-B/ADS-R reports for 

ASSAP. 

3.5.1 ADS-B Messages and Reports 

This section provides requirements and definition of ADS-B reports and the relationship 

between these reports and the received messages. The ADS-B output report definitions 

establish the standard contents and conditions for outputting data qualified for user 

applications. Exchange of broadcast messages and report assembly considerations are 

discussed in §3.5.1.2. Report data elements are specified in §3.5.1.3 to §3.5.1.8 and 

standardized according to content, nomenclature, parameter type, applicable coordinate 

system, logical content, and operational conditions. Reports required for each Equipment 

Class and supporting message contents are defined in §3.4.3.2. Report contents and 

message requirements are based on the information requirements summarized in Table 2- 

6. These definitions provide the basis for: 

� Independence between applications and broadcast link technologies 

� Interoperability of applications utilizing different ADS-B technologies. 

Specific digital formats are not defined since interface requirements will determine those 

details. Such interfaces may be internal processor buses or inter-system buses such as 

those described in ARINC, IEEE, and military standards. Additional information 

requirements may develop in the future and result in expansion to the report definitions 

specified in this document. ADS-B system designs should be sufficiently flexible to 

accommodate such future expansion. 


3.5.1.1 Report Assembly Design Considerations 

Four report types are defined as ADS-B outputs to applications. They provide flexibility 

in meeting delivery and performance requirements for the information needed to support 

the operations identified in Section 2. Report types are: 

� Surveillance State Vector Report (SV, §3.5.1.3); 

� Mode Status Report (MS, §3.5.1.4); 

� Various On-Condition Reports (OC, §3.5.1.5) – a category that includes the 

following report types: 

� Air Referenced Velocity Report (ARV, §3.5.1.6), 

� Target State Report (TS, §3.5.1.7), and 

� Other On-Condition Reports, which may possibly be defined in future versions 

of this MASPS. 

All interactive participants must receive messages and assemble reports specified for the 

respective equipage class (Table 3.4.3.2a). All transmitting participants must output at 

least the minimum data for the SV and MS reports. The minimum requirements for 

exchanged information and report contents applicable for equipage classes are provided 

in §3.4.3.2. 

3.5.1.2 ADS-B Message Exchange Technology Considerations in Report Assembly 


ADS-B participants can vary both in the information exchanged and in the applications 

supported. ADS-B reports are assembled from received ADS-B messages. Message 

formats are defined in MOPS or equivalent specifications for each link technology 

chosen for ADS-B implementation. Reports are independent of the particular message 

format and network protocol. In some ADS-B broadcast exchange technologies the 

information may be conveyed as a single message, while others may utilize multiple 

messages which require assembly in the receiving subsystem to generate the ADS-B 

report. The report assembly function must be performed by the ADS-B subsystem prior 

to disseminating the report to the application. 

Broadcast technologies vary in broadcast rate and probability of message reception. The 

receiving subsystem, therefore, must process messages compatibly with the message 

delivery performance to satisfy required performance as observed in the ADS-B report 

outputs. Also, data compression techniques may be used to reduce the number of 

transmitted bits in message exchange designs. 

The messages shall {242AR3.40} be correlated, collated, uncompressed, re-partitioned, 

or otherwise manipulated as necessary to form the output reports specifically defined in 

§3.5.1.3 to §3.5.1.8 below. The message and report assembly processing capability of 

the receiving subsystem shall {242AR3.41} support the total population of the 

participants within detection range provided by the specific data link technology. 

Receiving subsystem designs must provide reports based on all decodable messages 

received, i.e., for each participant the report shall {242AR3.42} be updated and made 

available to ADS-B applications any time a new message containing all, or a portion of,

its component information is received from that participant with the exception that no 

type of report is required to be issued at a rate of greater than once per second. The 

Report Assembler function converts the received messages into the reports appropriate to 

the information conveyed from the transmitting participant. The applicable reports shall 

{242AR3.43) be made available to the applications on a continual basis in accordance 

with the local system interface requirements. 

Each ADS-B report contains an address, for the purpose of enabling the receiver to 

associate the receptions into a single track. If the ADS-B design uses the ICAO 24-bit 

address, then there shall {242AR3.44} be agreement between the address currently being 

used by the Mode S transponder and the reported ADS-B address, for aircraft with both 

transponder and ADS-B. 

3.5.1.3 ADS-B State Vector Report 

Table 3.5.1.3 lists the report elements that comprise the State Vector (SV) report. The 

SV report contains information about an aircraft or vehicle’s current kinematic state. 

Measures of the State Vector quality are contained in the NIC element of the SV report 

and in the NACP, NACV, NICBARO and SIL elements of the Mode Status Report 

(§3.5.1.4). 

Table 3.5.1.3: State Vector Report Definition 

SV 

Elem. 

# 

Contents 

Required from surface participants 

Required from airborne 

participants 

[Resolution or # of bits] 

Reference 

Section 

Notes 

ID 

1 

2 

Participant Address 

Address Qualifier 

[24 bits] 

[1 bit] 

� 

� 

� 

� 

3.3.2.2.1 

3.3.2.2.2 1 

TOA 3 Time Of Applicability [0.2 s] � � 3.5.1.3.3 

Geometric 

Position 

4a 

4b 

4c 

5a 

Latitude (WGS-84) 

Longitude (WGS-84) 

Horizontal Position Valid 

Geometric Altitude 

[1 bit] 

� 

� 

� 

� 

� 

� 

� 

3.5.1.3.4 

3.5.1.3.5 

3.5.1.3.6 

2, 3 

3, 4 

5b Geometric Altitude Valid [1 bit] � 3.5.1.3.7 

Horizontal 

Velocity 

6a 

6b 

6c 

7a 

North Velocity while airborne 

East Velocity while airborne 

Airborne Horizontal Velocity Valid 

Ground Speed while on the surface 

[1 bit] 

[1 knot] 

� 

� 

� 

� 

3.5.1.3.8 

3.5.1.3.9 

3.5.1.3.10 

3 

3 

7b Surface Ground Speed Valid [1 bit] � 3.5.1.3.11 

Heading 

8a 

8b 

Heading while on the Surface 

Heading Valid 

[6� or better (6 bits)] 

[1 bit] 

� 

� 

3.5.1.3.12 

3.5.1.3.13 

Baro Altitude 

9a 

9b 

Pressure Altitude 

Pressure Altitude Valid [1 bit] 

� 

� 

3.5.1.3.14 

3.5.1.3.15 

3, 4 

Vertical Rate 10a Vertical Rate (Baro/Geo) � 3.5.1.3.16 3 

10b Vertical Rate Valid [1 bit] � 3.5.1.3.17 

NIC 11 Navigation Integrity Category [4 bits] � � 3.5.1.3.18 

Report Mode 12 SV Report Mode [2 bits] 3.5.1.3.19 



1. The minimum number of bits required by this MASPS for the Address Qualifier field is just one 

bit. However, when ADS-B is implemented on a particular data link, more than one bit may be 

required for the address qualifier if that data link supports other services in addition to the ADS- 

B service. The number of bits allocated for the Address Qualifier field may be different on 

different ADS-B data links. 

2. A horizontal position resolution finer than 20 m will be required if the NACP element of the MS 

report (§3.5.1.4) is 9 or greater (§3.3.11). 

3. Resolution requirements of these elements must be sufficient to meet the error requirements 

specified in Table 3.4.3.3.1.1a. 

4. Future revisions of this MASPS may not require that both geometric and pressure altitudes – if 

available – to be broadcast at the SV rate. Conditions will need to be specified as to when each 

altitude must be the “primary” altitude being sent at the SV rate. 

3.5.1.3.1 Air/Ground State 

A transmitting ADS-B participant’s air/ground state is an internal state in the transmitting 

ADS-B subsystem that affects which SV report elements are to be broadcast, but which is 

not required to be broadcast in ADS-B messages from that participant. 

Notes: 

1. It is possible that a future edition of this MASPS would require a participant’s 

air/ground state to be broadcast. This would occur if an operational concept for a 

user application that needs air/ground state were to be included in a future version of 

this MASPS. 

2. A transmitting ADS-B participant’s air/ground state also affects whether the aircraft 

size (length and width) codes in the MS report are to be broadcast (see §3.5.1.4.6). 

A transmitting participant’s air/ground state has the following possible values: 

� “Known to be airborne,” 

� “Known to be on the surface,” and 

� “Uncertain whether airborne or on the surface.” 

3.5.1.3.1.1 Determination of Air/Ground State 


A transmitting ADS-B participant applies the following tests to determine its air/ground 

state: 

1. If a transmitting ADS-B participant is not equipped with a means, such as a weighton-wheels 

switch, to determine whether it is airborne or on the surface, and that 

participant’s emitter category is one of the following, then it shall {242AR3.45} set 

its air/ground state to “known to be airborne:” 

a. Light Aircraft 

b. Glider or Sailplane

c. Lighter Than Air 

d. Unmanned Aerial Vehicle 

e. Ultralight, Hang Glider, or Paraglider 

f. Parachutist or Skydiver 

g. Point Obstacle 

h. Cluster Obstacle 

i. Line Obstacle 

Note 1: Because it is important for fixed ground or tethered obstacles to report 

altitude, Point Obstacles, Cluster Obstacles, and Line obstacles always 

report the “Airborne” state. 



participant’s emitter category is one of the following, then that participant shall 

{242AR3.46} set its air/ground state to “known to be on the surface:” 

a. Surface Vehicle – Emergency 

b. Surface Vehicle – Service 



participant’s emitter category is “rotorcraft,” then that participant shall {242AR3.47} 

set its air/ground state to “uncertain whether airborne or on the surface.” 

Note 2: Because of the unique operating capability of rotorcraft (i.e., hover, etc.) 

an operational rotorcraft always reports the “uncertain” air/ground state, 

unless the “surface” state is specifically declared. This causes the 

rotorcraft to transmit those SV elements that are required from airborne 

ADS-B participants. 


switch, to determine whether it is airborne or on the surface, and its ADS- 

B emitter category is not one of those listed under tests 1, 2, and 3 above, then that 

participant’s ground speed (GS), airspeed (AS) and radio height (RH) shall 

{242AR3.48-A} be examined, provided that some or all of those three parameters are 

available to the transmitting ADS-B subsystem. If GS < 100 knots, or AS < 100 

knots, or RH < 50 feet, then the transmitting ADS-B participant shall {242AR3.48- 

B} set its Air/Ground state to “known to be on the surface.” 

5. 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, 

and that automatic means indicates that the participant is airborne, then that 

participant shall {242AR3.49} set its air/ground state to “known to be airborne.” 

6. 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, 


and that automatic means indicates that the participant is on the surface, then the 

following additional tests shall {242AR3.50} be performed to validate the “on-thesurface” 

condition: 

a. If the participant’s ADS-B emitter category is any of the following: 

� “Small Aircraft” or 

� “Medium Aircraft” or 

� “High-Wake-Vortex Large Aircraft” or 

� “Heavy Aircraft” or 

� “Highly Maneuverable Aircraft” or 

� “Space or Trans-atmospheric Vehicle” 

AND one or more of the following parameters is available to the transmitting 

ADS-B system: 

� Ground Speed (GS) or 

� Airspeed (AS) or 

� Radio height from radio altimeter (RH) 

AND any of the following conditions is true: 

� GS > 100 knots or 

� AS > 100 knots or 

� RH > 100 50 ft, 

THEN, the participant shall {242AR3.51-A} set its Air/Ground state to “known 

to be airborne.” 

b. Otherwise, the participant shall {242AR3.51-B} set its Air/Ground state to 

“known to be on the surface.” 

3.5.1.3.1.2 Effect of Air/Ground State 


The set of SV elements to be broadcast by ADS-B participants is determined by those 

participants’ air/ground state as follows: 

a. ADS-B participants that are known to be on the surface shall {242AR3.52} transmit 

those State Vector report elements that are indicated with bullets (“•”) in the 

“required from surface participants” column of Table 3.5.1.3.

. ADS-B participants that are known to be airborne shall {242AR3.53} transmit those 

SV report elements that are indicated by bullets (“•”) in the “required from airborne 

participants” column of Table 3.5.1.3. 

c. ADS-B participants for which the air/ground state is uncertain shall {242AR3.54} 

transmit those SV report elements that are indicated by bullets in the “required from 

airborne participants” column. It is recommended that such participants should also 

transmit those SV elements that are indicated with bullets in the “required from 

surface participants” column. 

3.5.1.3.2 SV Report Update Requirements 

Required SV report update rates, described by operating range, are given in Table 

3.4.3.3.1.1a (§3.4.3.3.1.1). 

a. A receiving ADS-B subsystem shall {242AR3.55} update the SV report that it 

provides to user applications about a transmitting ADS-B participant whenever it 

receives messages from that participant providing updated information about any of 

the SV report elements with the exception that SV reports are not required to be 

issued at a rate of greater than once per second. 

b. For ADS-B systems that use segmented messages for SV data, time-critical SV report 

elements that are not updated in the current received message shall {242AR3.56} be 

estimated whenever the SV report is updated. The time-critical SV elements are 

defined as the following: 

1. Geometric position (latitude, longitude, geometric height, and their validity 

flags – elements 4a, 4b, 4c, 5a, 5b); 

2. Horizontal velocity and horizontal velocity validity (elements 6a, 6b, 6c, 7a, 

7b); 

3. Heading while on the surface (elements 8a, 8b); 

4. Pressure altitude (elements 9a, 9b); 

5. Vertical rate (elements 10a, 10b); and 

6. NIC (element 11). 

Note 1: Estimation of NIC is done by simply retaining the last reported value. 

c. For time-critical elements of the SV report, a ADS-B receiving subsystem’s report 

assembly function shall {242AR3.57} indicate “no data available” if no data are 

received in the preceding coast interval specified in Table 3.4.3.3.1.1a (§3.4.3.3.1.1). 

Note 2: An ADS-B receiving subsystem may mark data elements as “no data 

available” by setting the associated validity bit(s) to ZERO. For NIC this 

is done by setting the value of NIC to ZERO. 


3.5.1.3.3 Time of Applicability (TOA) Field for SV Report 

The Time of Applicability (TOA) field in the SV report describes the time at which the 

elements of that report are valid. 

Note: As mentioned in the definition of latency in §3.4.3.3.2.1, the times of applicability 

of position and velocity may differ. The TOA field in the SV report contains the 

time of applicability of position. 

The time of applicability (TOA) relative to local system time shall {242AR3.58} be 

updated with each State Vector report update. 

Requirements on the accuracy of the TOA field in the SV report are given in §3.4.3.3.2.2, 

and may be paraphrased as follows: 

a. The standard deviation of the SV report time error is to be less than 0.5 s. 

b. The mean report time error for the position elements of the SV report is not to exceed 

0.5 s. 

c. The mean report time error for the velocity elements of the SV report is not to exceed 

1.5 s. 

Note: The recommended TOA resolution of 0.2 s specified in Table 3.5.1.3 will meet the 

specifications in items a, b, and c above. 

3.5.1.3.4 Horizontal Position 

Horizontal position (§3.3.4) shall {242AR3.59} be reported as WGS-84 latitude and 

longitude. Horizontal position shall {242AR3.60} be reported with the full range of 

possible latitudes (-90� to +90�) and longitudes (-180� to +180�). 

Horizontal position shall {242AR3.61} be communicated and reported with a resolution 

sufficiently fine so that it does not compromise the accuracy reported in the NACP field 

(§3.3.11) of the Mode Status report (§3.5.1.4). Moreover, horizontal position shall 

{242AR3.62} be communicated and reported with a resolution sufficiently fine that it 

does not compromise the one-sigma maximum ADS-B contribution to horizontal position 

error, �hp, listed in Table 3.4.3.3.1.1a 20 m for airborne participants, or �hp = 2.5 m for 

surface participants. 

3.5.1.3.5 Horizontal Position Valid Field 


The Horizontal Position Valid field in the SV report shall {242AR3.63-A} be set to ONE 

if a valid horizontal position is being provided in geometric position (latitude and 

longitude) fields of that report; otherwise, the Horizontal Position Valid field shall 

{242AR3.63-B} be ZERO.

3.5.1.3.6 Geometric Altitude Field 

Geometric altitude shall {242AR3.64} be reported with a range from -1,000 feet up to 

+100,000 feet. If the NACP code (§3.3.11) reported in the MS report (§3.5.1.4) is 9 or 

greater, the geometric altitude shall {242AR3.65} be communicated and reported with a 

resolution sufficiently fine that it does not compromise the vertical accuracy reported in 

the NACP field. Moreover, geometric altitude shall {242AR3.66} be communicated and 

reported with a resolution sufficiently fine so that it does not compromise the one-sigma 

maximum ADS-B contribution to vertical position error, �vp, listed in Table 3.4.3.3.1.1a, 

�vp = 30 feet for airborne participants. 

Note: A resolution of 100 feet or finer is sufficient not to compromise the one-sigma 

(one standard deviation) ADS-B contribution to vertical position error listed in 

Table 3.4.3.3.1.1a. This is because the error introduced by rounding altitude to 

the nearest multiple of 100 feet has a uniform probability distribution, for which 

the standard deviation is 100 feet divided by the square root of 12, that is, about 

28.9 feet. 

3.5.1.3.7 Geometric Altitude Valid Field 

The Geometric Altitude Valid field in the SV report is a one-bit field which shall 

{242AR3.67] be ONE if valid data is being provided in the Geometric Altitude field 

(§3.5.1.3.6), or ZERO otherwise. 

3.5.1.3.8 Geometric Horizontal Velocity 

Geometric horizontal velocity is the horizontal component of the velocity of an A/V with 

respect to the earth (or with respect to an earth-fixed reference system, such as the WGS- 

84 ellipsoid). The range of reported horizontal velocity shall {242AR3.68] 

accommodate speeds of up to 250 knots for surface participants and up to 4000 knots for 

airborne participants. Horizontal velocity shall {242AR3.69} be communicated and 

reported with a resolution sufficiently fine that it does not compromise the accuracy 

reported in the NACV field of the Mode Status report. Moreover, horizontal velocity 

shall {242AR3.70} be communicated and reported with a resolution sufficiently fine so 

that it does not compromise the one-sigma maximum ADS-B contribution to horizontal 

velocity error, �hv, listed in Table 3.4.3.3.1.1a, that is, 0.5 m/s (about 1 knot) for airborne 

participants with speeds of 600 knots or less, or 0.25 m/s (about 0.5 knot) for surface 

participants. 

Note: The rounding of velocity to the nearest encoded representation may be modeled 

with a uniform probability distribution. As such, the standard deviation (onesigma 

velocity error, �hv) due to rounding to the nearest possible encoded 

representation is the weight of the LSB divided by the square root of 12. Thus, 

�hv = 0.5 m/s (about 1 knot) for airborne participants implies a resolution of 

reshv � � hv � 12 = 1.73 m/s (about 3.4 knots), so even a horizontal velocity 

resolution of 2 knots is sufficiently fine to meet the constraint imposed by Table 

3.4.3.3.1.1a on airborne participants with speeds up to 600 knots. Likewise, a 

horizontal velocity resolution of 1 knot is sufficiently fine to satisfy the constraint 

imposed by Table 3.4.3.3.1.1a for surface participants. 


3.5.1.3.9 Airborne Horizontal Velocity Valid Field 

The Airborne Horizontal Velocity Valid field in the SV report is a one-bit field which 

shall {242AR3.71-A} be set to ONE if a valid horizontal geometric velocity is being 

provided in the “North Velocity while airborne” and “East velocity while airborne” fields 

of the SV report; otherwise, the “Airborne Horizontal Velocity Valid” field shall 

{242AR3.71-B} be ZERO. 

3.5.1.3.10 Ground Speed While on the Surface Field 

The ground speed (the magnitude of the geometric horizontal velocity) of an A/V that is 

known to be on the surface shall {242AR3.72} be reported in the “ground speed while on 

the surface” field of the SV report. For A/Vs moving at ground speeds less than 70 

knots, the ground speed shall {242AR3.73} be communicated and reported with a 

resolution of 1 knot or finer. Moreover, the resolution with which the “ground speed 

while on the surface” field is communicated and reported shall {242AR3.74} be 

sufficiently fine so as not to compromise the accuracy of that speed as communicated in 

the NACV field of the MS report (§3.5.1.4). 

3.5.1.3.11 Surface Ground Speed Valid Field 

The Surface Ground Speed Valid field in the SV report is a one-bit field which shall 

{242AR3.75} be ONE if valid data is available in the Ground Speed While on the 

Surface field (§3.5.1.3.10), or ZERO otherwise. 

3.5.1.3.12 Heading While on the Surface Field 

Heading (§3.3.7) indicates the orientation of an A/V, that is, the direction in which the 

nose of an aircraft is pointing. ADS-B Participants are not required to broadcast heading 

if their length/width code (part of the aircraft size code, Table 3.3.4.1a) is Zero (0). 

However, each ADS B participant that reports a length code of 2 or greater shall 

{242AR3.76} transmit messages to support the heading element of the SV report when 

that participant is on the surface and has a source of heading available to its ADS-B 

transmitting subsystem. 

Heading shall {242AR3.77-A} be reported for the full range of possible headings (the 

full circle, from 0° to nearly 360°). The heading of surface participants shall 

{242AR3.77-B} be communicated and reported with a resolution of 6 degrees of arc or 

finer. 

Notes: 


1. If heading is encoded as a binary fraction of a circle, a resolution of 6° of arc or 

finer would require at least 6 binary bits. 

2. The reference direction for heading (true north or magnetic north) is communicated 

in the True/Magnetic Heading Flag (§3.2.7) of the Mode Status report.

3. For operations at some airports, heading may be required to enable proper 

orientation and depiction of an A/V by applications supporting those surface 

operations. 

3.5.1.3.13 Heading Valid Field 

The “heading valid” field in the SV report shall {242AR3.78-A} be ONE if a valid 

heading is provided in the “heading while on the surface” field of the SV report; 

otherwise, it shall {242AR3.78-B} be ZERO. 

3.5.1.3.14 Pressure Altitude Field 

Barometric pressure altitude shall {242AR3.79} be reported referenced to standard 

temperature and pressure (1013.25 hPa or mB, or 29.92 in Hg). Barometric pressure 

altitude shall {242AR3.80} be reported over the range of -1,000 feet to +100,000 feet. 

If a pressure altitude source with 25 foot or better resolution is available to the ADS-B 

transmitting subsystem, then pressure altitude from that source shall {242AR3.81-A} be 

communicated and reported with 25 foot or finer resolution. Otherwise, if a pressure 

altitude source with 100 foot or better resolution is available, pressure altitude from that 

source shall {242AR3.81-B} be communicated and reported with 100 foot or finer 

resolution. 

3.5.1.3.15 Pressure Altitude Valid Field 

The “pressure altitude valid” field in the SV report is a one-bit field which shall 

{242AR3.82-A} be ONE if valid information is provided in the “pressure altitude” field; 

otherwise, the “pressure altitude valid” field shall {242AR3.82-B) be ZERO. 

3.5.1.3.16 Vertical Rate Field 

The “vertical rate” field in the SV report contains the altitude rate of an airborne ADS-B 

participant. This shall {242AR3.83} be either the rate of change of pressure altitude or 

of geometric altitude, as specified by the “vertical rate type” element in the MS report. 

The range of reported vertical rate shall {242AR3.84} accommodate up to ±32000 ft/min 

for airborne participants. Geometric vertical rate shall {242AR3.85} be communicated 

and reported with a resolution sufficiently fine that it does not compromise the accuracy 

reported in the NACV field of the Mode Status report. Moreover, vertical rate shall 

{242AR3.86} be communicated and reported with a resolution sufficiently fine that it 

does not compromise the one-sigma maximum ADS-B contribution to vertical rate error, 

�vv, listed in Table 3.4.3.3.1.1a, that is, 1.0 ft/s for airborne participants. 

3.5.1.3.17 Vertical Rate Valid Field 

The “vertical rate valid” field in the SV report is a one-bit field which shall {242AR3.87- 

A} be ONE if valid information is provided in the “vertical rate” field; otherwise, the 

“vertical rate valid” field shall {242AR3.87-B} be ZERO. 


3.5.1.3.18 Navigation Integrity Category (NIC) Field 

The NIC field in the SV report is a 4-bit field that shall {242AR3.88} report the 

Navigation Integrity Category described in Table 3.3.10a (§3.3.10). 

3.5.1.3.19 Report Mode Field 

The “Report Mode” provides a positive indication when SV and MS acquisition is 

complete and all applicable data sets and modal capabilities have been determined for the 

participant or that a default condition is determined by the Report Assembly function. 

The information for this SV element is not transmitted over the ADS-B data link, but is 

provided by the report assembly function at the receiving ADS-B participant. Table 

3.5.1.3.19 lists the possible values for the SV Report Mode. 

3.5.1.4 Mode Status Report 


Table 3.5.1.3.19: SV Report Mode Values. 

Value Meaning 

0 Acquisition 

1 Track 

2 Default 

The mode-status (MS) report contains current operational information about the 

transmitting participant. This information includes participant type, mode specific 

parameters, status data needed for certain pair-wise operations, and assessments of the 

integrity and accuracy of position and velocity elements of the SV report. Specific 

requirements for a participant to supply data for and/or generate this report subgroup will 

vary according to the equipage class of each participant. §3.4.3.2 defines the required 

capabilities for each Equipage Class defined in §3.2.1.3.3. Equipage classes define the 

level of MS information to be exchanged from the source participant to support correct 

classification onboard the user system. 

The Mode Status report for each acquired participant contains the unique participant 

address for correlation purposes, static and operational mode information and Time of 

Applicability. Contents of the Mode Status report are summarized in Table 3.5.1.4. 

The static and operational mode data includes the following information: 

� Capability Class (CC) Codes – used to indicate the capabilities of a transmitting 

ADS-B participant. 

� Operational Mode (OM) Codes – used to indicate the current operating mode of a 

transmitting ADS-B participant. 

For each participant the Mode-status report shall {242AR3.89} be updated and made 

available to ADS-B applications any time a new message containing all, or a portion of, 

its component information is accepted from that participant.

MS 

Elem. 

# 

Table 3.5.1.4: Mode Status (MS) Report Definition. 

Elements That Require Rapid Update 

Contents [Resolution or # of bits] 

Reference 

Section 

ID 

1 

2 



[24 bits] 

[1 bit] 

3.3.2.2.1 

3.3.2.2.2 1 

TOA 3 Time of Applicability [1 s resolution] 3.5.1.4.2 

Notes 

Version 4 ADS-B Version Number [3 bits] 3.5.1.4.3 

ID, 

Continued 

5a 

5b 

5c 

Call Sign [up to 8 alpha-numeric characters] 

Emitter Category [5 bits] 

A/V Length and Width Codes [4 bits] 

3.5.1.4.4 

3.5.1.4.5 

3.5.1.4.6 2 

Status 

6a 

6b 

Mode Status Data Available 

Emergency/Priority Status 

[1 bit] 

[3 bits] 

3.5.1.4.7 

3.5.1.4.8 3 

Capability Class (CC) Codes [16 bits] 3.5.1.4.9 

7a: TCAS/ACAS operational [1 bit] � 3.5.1.4.9 4 

CC, 

Capability 

Codes 

7 

7b: 1090 MHz ES Receive Capability 

7c: ARV report Capability Flag 

7d: TS report Capability Flag 

7e: TC report Capability Level 

[1 bit] 

[1 bit] 

[1 bit] 

[2 bits] 

3.5.1.4.9 

3.5.1.4.9 

3.5.1.4.9 

3.5.1.4.9 

7f: UAT Receive Capability [1 bit] 3.5.1.4.9 

(CC Codes reserved for future growth) [3 bits] 3.5.1.4.9 

Operational Mode (OM) Parameters [16 bits] 3.5.1.4.10 

8a: TCAS/ACAS resolution advisory active [1 bit] � 3.5.1.4.10 4 

OM, 

Operational 

Mode 

8 

8b: IDENT Switch Active 

8c: Reserved for Receiving ATC services 

8d: Single Antenna Flag 

8e: System Design Assurance 

[1 bit] 

[1 bit] 

[1 bit] 

[2 bits] 

3.5.1.4.10 

3.5.1.4.10 

3.5.1.4.10 

3.5.1.4.10 

3 

8f: GPS Antenna Offset [8 bits] 3.5.1.4.10 

(Reserved for future growth) [2 bits] 3.5.1.4.10 

9a Nav. Acc. Category for Position (NACP) [4 bits] � 3.5.1.4.11 4 

9b Nav. Acc. Category for Velocity (NACV ) [3 bits] � 3.5.1.4.12 4 

SV Quality 

9c 

9d 

Source Integrity Level (SIL) 

NICBARO - Altitude Cross Checking Flag 

[2 bits] 

[1 bit] 

� 3.5.1.4.13 

3.5.1.4.14 

4 

9e Geometric Vertical Accuracy (GVA) [2 bits] 3.5.1.4.15 

9f (Reserved for future growth) [2 bits] 3.5.1.4.16 

Data 10a True/Magnetic Heading [1 bit] 3.5.1.4.17 

Reference 10b Vertical Rate Type (Baro./Geo.) [1 bit] 3.5.1.4.18 

Other 11 Reserved for Flight Mode Specific Data [3 bits] 3.5.1.4.19 


1. The minimum number of bits required by this MASPS for the Address Qualifier field 

is just one bit. However, when ADS-B is implemented on a particular data link, more 

than one bit may be required for the address qualifier if that data link supports other 

services in addition to the ADS-B service. For example, address qualifier bits might 

be needed to distinguish reports about TIS-B targets from reports about ADS-B 

targets. The number of bits allocated for the Address Qualifier field may be different 

on different ADS-B data links. 

2. The aircraft size code only has to be transmitted by aircraft above a certain size, and 

only while those aircraft are on the ground. (See §3.5.1.4.6 for details.) 


3. These elements are primarily for air-to-ground use. Update rate requirements for 

ground applications are not defined in these MASPS. If higher rates are later 

deemed to be required, they will be addressed in a future revision of these MASPS. 

4. Changes to the values of these elements may trigger the transmission of messages 

conveying the changed values at higher than nominal update rates. (Only those 

elements whose values have changed need be updated, not the entire MS report.) 

These update rates, the duration for which those rates must be maintained, and the 

operational scenario to be used to evaluate these requirements are to be defined in a 

future revision of these MASPS. 

3.5.1.4.1 MS Report Update Requirements 

The report assembly function shall {242AR3.90-A} provide update when received. For 

those elements indicated in Table 3.5.1.4 as “elements that require rapid update”, the 

report assembly function shall {242AR3.90-B} indicate the data has not been refreshed 

with the “Mode Status Data Available” bit (§3.5.1.4.7) if no update is received in the 

preceding 24 second period. 

Note: The 24-second period before which the “Mode Status Data Available” bit is 

cleared was chosen as being the longest coast interval for SV reports, as 

indicated in Table 3.4.3.3.1.1a. 

3.5.1.4.2 Time of Applicability (TOA) Field for MS Report 

The time of applicability relative to local system time shall {242AR3.91} be updated 

with every Mode Status report update. 

3.5.1.4.3 ADS-B Version Number 

The ADS-B Version Number conveyed in the MS report specifies the ADS-B version of 

the ADS-B transmitting system as specified in Table 3.3.20. 

3.5.1.4.4 Call Sign Field 


Note: Messages transmitted to support this report element might signify lower level 

document (i.e., MOPS) version. However, ADS-B reports need to – at a 

minimum – signify the MASPS version so that applications can appropriately 

interpret received ADS-B data. 

An ADS-B participant’s call sign (§3.3.2.1) is conveyed in the Call Sign field of the MS 

report. The call sign shall {242AR3.93} consist of up to 8 alphanumeric characters. The 

characters of the call sign shall {242AR3.94} consist only of the capital letters A-Z, the 

decimal digits 0-9, and – as trailing pad characters only – the “space” character.

3.5.1.4.5 Emitter Category Field 

An ADS-B participant’s category code (§3.3.2.3) is conveyed in the Emitter Category 

field of the MS report. The particular encoding of the emitter category is not specified in 

these MASPS, being left for lower level specification documents, such as the MOPS for a 

particular ADS-B data link. Provision in the encoding shall {242AR3.95} be made for at 

least 24 distinct emitter categories, including the particular categories listed in §3.3.2.3 

above. 

3.5.1.4.6 A/V Length and Width Codes 

The “A/V Length and Width Codes” field in the MS field is a 4-bit field that describes 

the amount of space that an aircraft or ground vehicle occupies. The aircraft/vehicle 

length and width codes shall {242AR3.96} be as described in Table 3.3.4.1a. The 

aircraft size code is a four-bit code, in which the 3 most significant bits (the length code) 

classify the aircraft into one of eight length categories, and the least significant bit (the 

width code) classifies the aircraft into a “narrow” or “wide” subcategory. 

Each aircraft shall {242AR3.97} be assigned the smallest length and width codes for 

which its overall length and wingspan qualify it. 

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. But since the wingspan exceeds 34 m, it will not fit within even the 

“wide” subcategory of length category 1. Such an aircraft would be assigned 

length category 4 and width category 1, meaning “length less than 55 m and 

wingspan less than 52 m.” 

Each aircraft ADS-B participant for which the length code is 2 or more (length greater 

than or equal to 25 m or wingspan greater than 34 m) shall {242AR3.98} transmit its 

aircraft size code while it is known to be on the surface. For this purpose, the 

determination of when an aircraft is on the surface shall {242AR3.99} be as described in 

§3.5.1.3.1.1. 

3.5.1.4.7 Mode Status Data Available Field 

The Mode Status Data Available field is a one-bit field in the MS report. The report 

assembly function shall {242AR3.100-A} set this field to ZERO if no data has been 

received within 24 seconds under the conditions specified in §3.5.1.4.1; otherwise the 

report assembly function shall {242AR3.100-B} set this bit to ONE. 

3.5.1.4.8 Emergency/Priority Field 

The emergency/priority status field in the MS report is a 3-bit field which shall 

{242AR3.101} be encoded as indicated in Table 3.3.15a. 


3.5.1.4.9 Capability Class (CC) Code Fields 

Capability Class (CC) codes are used to indicate the capability of a participant to support 

engagement in various operations. Known specific capability class codes that are 

included in the MS report are listed below. However, this is not an exhaustive set and 

provision should be made for future expansion of available class codes, including 

appropriate combinations thereof. 

Airborne Capability Class Codes 

� TCAS/ACAS operational (§TBD) 

� 1090ES IN & UAT IN 

� ARV report capability (§TBD) 

� TS report capability (§TBD) 

� TC report capability level (§TBD) 

� Other capabilities, to be defined in later versions of these MASPS 

� 

Surface Capability Class Codes 

� 1090ES IN & UAT IN 

� Service Level of the transmitting A/V (B2 Low) (§TBD)(unique to 1090ES) 

� NACV (§TBD) 

� Other capabilities, to be defined in later versions of these MASPS 

3.5.1.4.10 Operational Mode (OM) Codes 


Operational Mode (OM) codes are used to indicate the current operational mode of 

transmitting ADS-B participants. Specific operational mode codes included in the MS 

report are listed below. Unless noted, these parameters shall (R3.xxx New Reqmt) be 

broadcast in both airborne and surface operational status messages. However, this is not 

an exhaustive set and provision should be made for future expansion of available OM 

codes, including appropriate combinations thereof. 

� TCAS/ACAS resolution advisory active (§TBD). 

� IDENT switch active flag (§TBD) 

� Reserved for Receiving ATC services (§TBD) 

� Single Antenna Flag 

� System Design Assurance (SDA) (§TBD) 

� GPS Antenna Offset (Surface OM Messages Only, §3.3.9.6) 

� Other operational modes, to be defined in later versions of these MASPS.

3.5.1.4.11 Navigation Accuracy Category for Position (NACP) Field 

The Navigation Accuracy Category for Position (NACP, §3.3.11) is reported so that 

surveillance applications may determine whether the reported position has an acceptable 

level of accuracy for the intended use. The NACP field in the MS report is a 4-bit field 

which shall {242AR3.113} be encoded as described in Table 3.3.11a in §3.3.11. 





will also be defined in a future version of these MASPS. 

3.5.1.4.12 Navigation Accuracy Category for Velocity (NACV) Field 

The Navigation Accuracy Category for Velocity (NACV, §3.3.12) is reported so that 

surveillance applications may determine whether the reported velocity has an acceptable 

level of accuracy for the intended use. The NACV field in the MS report is a 3-bit field 

which shall {242AR3.114} be encoded as described in Table 3.3.12a (§3.3.12). 



report update rates to be specified in a future version of these MASPS. The 


will also be defined in a future version of these MASPS. 

3.5.1.4.13 Source Integrity Level (SIL) Field 

3.5.1.4.14 NICBARO Field 

The SIL field in the MS report is a 2-bit field which shall {242AR3.115} be coded as 

described in Table 3.3.13a (§3.3.13). 





will also be defined in a future version of this MASPS. 

The NICBARO field in the MS report is a one-bit flag that indicates whether or not the 

barometric pressure altitude provided in the State Vector Report has been cross-checked 

against another source of pressure altitude. A transmitting ADS B participant shall 

{242AR3.117-A} set NICBARO to ONE in the messages that it sends to support the MS 

report only if there is more than one source of barometric pressure altitude data and 

cross-checking of one altitude source against the other is performed so as to clear the 

“barometric altitude valid” flag in the SV report if the two altitude sources do not agree. 

Otherwise, it shall {242AR3.117-B} set this flag to ZERO. 


3.5.1.4.15 Geometric Vertical Accuracy (GVA) 

The Geometric Vertical Accuracy parameter in the MS report is an encoded 

representation of the 95% accuracy estimate of the geometric altitude (HAE) as output by 

the GNSS position source. In some GNSS position sources this output parameter is 

known as the Vertical Figure of Merit (VFOM). 

3.5.1.4.16 Reserved for MS Report 

A 2-bit field in the MS Report shall {242AR3.116} is be reserved for future use. 

3.5.1.4.17 True/Magnetic Heading Flag 

The True/Magnetic Heading Flag in the Mode Status report is a one-bit field which shall 

{242AR3.118} be ZERO to indicate that heading is reported referenced to true north, or 

ONE to indicate that heading is reported referenced to magnetic north. 

Note: The True/Magnetic Heading Flag applies to the heading being reported in the SV 

report while on the surface (§3.5.1.3.12), heading reported in the ARV report 

while airborne (§3.5.1.6.6), and the selected target heading reported in the TS 

report (§3.5.1.7.9). 

3.5.1.4.18 Vertical Rate Type Field 

The Primary Vertical Rate Type field in the MS report is a one-bit flag which shall 

{242AR3.119} be ZERO to indicate that the vertical rate field in the SV report 

§3.5.1.3.16 holds the rate of change of barometric pressure altitude, or ONE to indicate 

that the vertical rate field holds the rate of change of geometric altitude. 

3.5.1.4.19 (Reserved for) Flight Mode Specific Data Field 

A 3-bit field in the MS Report is reserved for future use as a “Flight Mode Specific Data” 

field. In the current version (RTCA DO-3xx) of these MASPS, the “Reserved for Flight 

Mode Specific Data” field shall {242AR3.120} be ZERO. 

3.5.1.5 On-Condition Reports 


The following paragraphs (§3.5.1.6 to §3.5.1.7) describe various On Condition (OC) 

reports. The OC reports are those for which messages are not transmitted all the time, but 

only when certain conditions are satisfied. Those OC report types currently defined are 

as follows: 

ARV: Air Referenced Velocity (ARV) Report (§3.5.1.6). 

TS: Target State (TS) Report (§3.5.1.7). 

Other On-Condition reports may be defined in future versions of these MASPS.

3.5.1.6 Air Referenced Velocity (ARV) Report 

The Air Referenced Velocity (ARV) report contains velocity information that is not 

required from all airborne ADS-B transmitting participants, and that may not be required 

at the same update rate as the position and velocity elements in the SV report. Table 

3.5.1.6 lists the elements of the ARV Report. 

Table 3.5.1.6: Air Referenced Velocity (ARV) Report Definition 

ARV Contents [Resolution or # of bits] Reference Notes 

Elem. # 

Section 

ID 

1 

2 



[24 bits] 

[1 bit] 

3.3.2.2.1 

3.3.2.2.2 1 


Airspeed 

4a 

4b 

Airspeed [1 knot or 4 knots] 

Airspeed Type and Validity [2 bits] 

3.5.1.6.4 

3.5.1.6.5 

Heading 

5a 

5b 

Heading while airborne 

Heading Valid 

[1 degree] 

[1 bit] 

3.5.1.6.6 

3.5.1.6.7 

2 


1. The minimum number of bits required by this MASPS for the Address Qualifier field 

is just one bit. However, when ADS-B is implemented on a particular data link, more 

than one bit may be required for the address qualifier if that data link supports other 

services in addition to the ADS-B service. The number of bits allocated for the 

Address Qualifier field may be different on different ADS-B data links. 

2. The heading reference direction (true north or magnetic north) is given in the MS 

report (§3.5.1.4). 

3.5.1.6.1 Conditions for Transmitting ARV Report Elements 

There are no conditions specified in this MASPS for which it is required to transmit 

messages supporting ARV reports. Possible future conditions being considered for 

requiring ARV reports are discussed in Appendix G. 

Notes: 

1. Uses of the ARV report are anticipated for future applications such as in-trail 

spacing, separation assurance when the transmitting aircraft is being controlled to 

an air-referenced heading, and for precision turns. For example, ARV report 

information allows wind conditions encountered by the transmitting aircraft to be 

derived. Current heading also provides a consistent reference when the aircraft is 

being controlled to a target heading. Such anticipated uses for ARV information are 

described in Appendix G. 

2. Such uses will be associated with conditions for transmitting messages to support the 

ARV report. It is anticipated that when the requirements for such future applications 

are better understood, that additional conditions for transmitting the ARV report 

information may be included in a future revision of this MASPS. 


3.5.1.6.2 ARV Report Update Requirements 

This section is reserved for update rate requirements when future versions of this MASPS 

define conditions under which the support of ARV reports is required. 

Note: It is expected that required ARV report update rates will not exceed those for 

State Vector (SV) reports. 

3.5.1.6.3 Time of Applicability (TOA) Field for ARV Report 


with every Air-Referenced Velocity report update. 

3.5.1.6.4 Airspeed Field 

Reported airspeed ranges shall {242AR3.122} be 0-4000 knots airborne. Airspeeds of 

600 knots or less shall {242AR3.123} be reported with a resolution of 1 knot or finer. 

Airspeeds between 600 and 4000 knots shall {242AR3.124} be reported with a 

resolution of 4 knots or finer. 

3.5.1.6.5 Airspeed Type and Validity 

The Airspeed Type and Validity field in the ARV report is a 2-bit field that shall 

{242AR3.125} be encoded as specified in Table 3.5.1.6.5. 

3.5.1.6.6 Heading While Airborne Field 


Table 3.5.1.6.5: Airspeed Type Encoding 

Airspeed Type Meaning 

0 Airspeed Field Not Valid 

1 True Airspeed (TAS) 

2 Indicated Airspeed (IAS) 

3 Reserved for Mach 

An aircraft’s heading (§3.3.7) is reported as the angle measured clockwise from the 

reference direction (magnetic north or true north) to the direction in which the aircraft’s 

nose is pointing. If an ADS B participant broadcasts messages to support ARV reports, 

and heading is available to the transmitting ADS-B subsystem, then it shall 

{242AR3.126} provide heading in those messages. Reported heading range shall 

{242AR3.127} cover a full circle, from 0 degrees to (almost) 360 degrees. The heading 

field in ARV reports shall {242AR3.128} be communicated and reported with a 

resolution at least as fine as 1 degree of arc. 

Note: The reference direction for heading (true north or magnetic north) is reported in 

the True/Magnetic Heading Flag of the Mode Status report §3.5.1.4.16 above).

3.5.1.6.7 Heading Valid Field 

The “Heading Valid” field in the ARV report shall {242AR3.129} be ONE if the 

“Heading While Airborne” field contains valid heading information, or ZERO if that 

field does not contain valid heading information. 

3.5.1.7 Target State (TS) Report 

The Target State (TS) Report provides information on the current status of the MCP/FCU 

or FMS Selected Altitude and the Selected Heading. Table 3.5.1.7 lists the elements of 

this report. 

TS 

Report 

Elem. # 

Table 3.5.1.7: Target State (TS) Report Definition 

Contents [Resolution or # of bits] 

Reference 

Section 

ID 

1 

2 



[24 bits] 

[1 bit] 

3.3.2.1 

3.3.2.2 


4a Selected Altitude Type [1 bit] 3.5.1.7.4 

Selected 4b MCP/FCU or FMS Selected Altitude [16 bits] 3.5.1.7.5 

Altitude 4c Barometric Pressure Setting (minus 800 millibars) [16 

bits] 

3.5.1.7.6 

Selected 

Heading 

5 Selected Heading [16 bits] 3.5.1.7.9 

6a Autopilot Engaged [1 bit] 3.5.1.7.11 

Mode 

Indicators 

6b 

6c 

6d 

VNAV Mode Engaged 

Altitude Hold Mode 

Approach Mode 

[1 bit] 

[1 bit] 

[1 bit] 

3.5.1.7.12 

3.5.1.7.13 

3.5.1.7.14 

6e LNAV Mode Engaged [1 bit] 3.5.1.7.15 

Reserved (Reserved for Future Growth) [4 bits] 

3.5.1.7.1 Conditions for Transmitting TS Report Information 

An airborne ADS-B participant of equipage class A2 or A3 shall {242AR3.130} transmit 

messages to support the TS report when airborne and target state information is available. 

Note: TS Reports are also optional for A1 equipment. If A1 equipment chooses to 

support TS reports those reports must meet the requirements specified in §3.5.1.7 

and all of its subsections. 

3.5.1.7.2 TS Report Update Requirements 

The nominal update interval for TS Report information is specified in §3.4.3.3.1.4 and 

Table 3.4.3.3.1.1d. 


The higher “state change” update interval requirements specified for TS report 

information in §3.4.3.3.1.4 and Table 3.4.3.3.1.1d shall {242AR3.131} be met whenever 

there is a change in the value of any of the TS report fields. 

Editor’s Note: � The basic Target State information is being moved from 3.4.3.3 to a 

new appendix, so these references will need to be updated. � 

3.5.1.7.3 Time of Applicability (TOA) field for TS Report 


with every Target State report update. 

3.5.1.7.4 Selected Altitude Type 

The “Selected Altitude Type” subfield is a field in the TS report that is used to indicate 

the source of Selected Altitude data. Encoding of the “Selected Altitude Type” is 

specified in Table 3.3.19. 

3.5.1.7.5 MCP/FCU or FMS Selected Altitude Field 

The “MCP / FCU Selected Altitude or FMS Selected Altitude” subfield is a field in the 

TS report that contains either the MCP / FCU Selected Altitude or the FMS Selected 

Altitude data as specified in Table 3.3.20. 

3.5.1.7.6 Barometric Pressure Setting (Minus 800 millibars) Field 

The “Barometric Pressure Setting (Minus 800 millibars)” subfield is a field in the TS 

report that contains Barometric Pressure Setting data that has been adjusted by 

subtracting 800 millibars from the data received from the Barometric Pressure Setting 

source. After adjustment by subtracting 800 millibars, the Barometric Pressure Setting is 

encoded as specified in Table 3.3.21. 

3.5.1.7.7 Selected Heading Field 

The “Selected Heading” is a field in the TS report that contains Selected Heading data 

encoded as specified in Table 3.3.24. 

3.5.1.7.8 MCP/FCU Mode Indicator: Autopilot Engaged Field 


The “Mode Indicator: Autopilot Engaged” subfield is a field in the TS report that is used 

to indicate whether the autopilot system is engaged or not, as specified by Table 3.3.26.

3.5.1.7.9 MCP/FCU Mode Indicator: VNAV Mode Engaged Field 

The “Mode Indicator: VNAV Mode Engaged” is a field in the TS report that is used to 

indicate whether the Vertical Navigation Mode is active or not, as specified in Table 

3.3.27. 

3.5.1.7.10 MCP/FCU Mode Indicator: Altitude Hold Mode Field 

The “Mode Indicator: Altitude Hold Mode” is a field in the TS report that is used to 

indicate whether the Altitude Hold Mode is active or not, as specified in Table 3.3.28. 

3.5.1.7.11 MCP/FCU Mode Indicator: Approach Mode Field 

The “Mode Indicator: Approach Mode” is a field in the TS report that is used to indicate 

whether the Approach Mode is active or not, as specified in Table 3.3.29. 

3.5.1.7.12 MCP/FCU Mode Indicator: LNAV Mode Engaged Field 

The “Mode Indicator: LNAV Mode Engaged” is a field in the TS report that is used to 

indicate whether the Lateral Navigation Mode is active or not, as specified in Table 

3.3.30. 

3.5.2 Traffic Information Services – Broadcast (TIS-B) Messages and Reports 

3.5.2.1 Introduction to TIS-B 

The formats and coding for a Traffic Information Service Broadcast (TIS-B) are based on 

the same ADS-B signal transmission. 

TIS-B complements the operation of ADS-B by providing ground-to-air broadcast of 

surveillance data on aircraft that are not equipped for 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 ADS-B broadcasts and can therefore be accepted by an 

ADS-B receiver. 

TIS-B data content on the signal does not include all of the parameters, such as the 

System Design Assurance (SDA) and the SIL Supplement, which are normally associated 

with ADS-B transmissions from aircraft. Those parameters that are not broadcast will 

need to be provided by the TIS-B Service Provider. 

TIS-B service is the means for providing a complete surveillance picture to ADS-B users 

during a transition period. After transition, it also provides a means to cope with a user 

that has lost its ADS-B capability, as well as a means to provide ADS-B users with 

information from surface or approach multi-lateration systems. 


3.5.2.2 TIS-B Message Processing and Report Generation 

The information received in TIS-B Messages is reported directly to applications. 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. 

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. 

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. 

3.5.3 ADS-B Rebroadcast Service (ADS-R) Messages and Reports 

The formats and coding for an ADS-B Rebroadcast Service (ADS-R) are based on the 

same ADS-B signal transmission characteristics as are defined for each individual ADS- 

B data link. 

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 ADS-B-1, but are equipped with an alternate form of ADS-B (e.g., ADS-B-2). 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. 

The ADS-R ground-to-air transmissions use the same signal formats as the respective 

ADS-B data links and can therefore be accepted by an alternate ADS-B Receiving 

Subsystem. 

3.6 External Subsystem Requirements 

Ownship subsystems external to ASA include navigation, TCAS, flight management and 

flight controls, etc. This section provides requirements associated with both the transmit 

(ADS-B Out) and receive (ADS-B In) functions, and assumptions on the systems external 

to the ASA system bounds. 

3.6.1 Own-ship Position Data Source 


The availability of ASA is dependent on a source of own-ship position information. 

It is assumed that the majority of airborne ASA installations will be equipped with GNSS 

as the geometric position and velocity data source based on the ability to meet the 

performance requirements necessary to support installed applications. 

At the time these MASPS were written, there are no known non-GNSS position sources 

(e.g. VOR/DME, DME/DME, loran, or inertial for position determination) that meet the 

performance requirements for ASA. It is possible that future development may lead to a 

non-GNSS position source that can meet the performance requirements for ASA. These

alternate position sources may not necessarily meet the criteria for the primary position 

source, however, it is possible that they can be utilized to update own-ship position 

during short instances of GNSS intermittency, while it can be determined that the 

performance requirements for the active application(s) are met. 

ASA installations shall (R3.xxx) be equipped with a source of own-ship geometric 

position and velocity data. 

The same own-ship position source shall (R3.xxx) be utilized by both “ADS-B In” 

applications, as well as “ADS-B Out” transmissions. 

To qualify for use by ASA, the selected own-ship position data source is assumed to meet 

the following requirements. 

The own-ship position data source will be capable of providing A/V geometric position 

and velocity data that meets the integrity and accuracy performance requirements. 

The own-ship position data will include the following: 

� Own-ship horizontal position in latitude and longitude referenced to WGS-84 

ellipsoid. 

� Own-ship geometric height above ellipsoid surface, if available. 

� The position data accompanied with accuracy and integrity metrics for determination 

of Navigation Accuracy Category for position (NACP) and Navigation Integrity 

Category (NIC) of the data. Refer to §3.1.2.3.1 for definitions of NACP and NIC. 

� Individual horizontal position and geometric height validity flags. 

� Geometric Vertical Accuracy 

The own-ship velocity data will include the following: 

� Own-ship horizontal velocity. The velocity may be provided in rectangular 

(north/east velocity for airborne operations) or polar (ground speed and track for 

surface operations) coordinates. When heading is provided, an indication of true/mag 

reference is required. Heading referenced to true north is preferred. 

� Velocity data accompanied with accuracy metrics for determination of Navigation 

Accuracy Category for velocity (NACV) of the data. When a velocity accuracy 

metric is not output by a source, a qualified means to determine a velocity accuracy 

should be performed. Refer to §3.1.2.3.1 for definition of NACV. 

� A velocity validity flag 

There shall (R3.xxx) be a means to determine the SIL value for the own-ship position 

data source. 

There shall (R3.xxx) be a means to determine when a own-ship position data source has 

failed so that an acceptable alternate own-ship position source may be selected, if 

available. 

The maximum time to indicate a change in integrity of the own-ship position data outputs 

will be less than 10 seconds. 


3.6.2 Air Data Source 

It is assumed that the majority of airborne ASA installations will be equipped with air 

data sources to provide pressure altitude, pressure altitude rate, barometric pressure 

setting and air speed, if required. To qualify for use by ASA, the selected air data source 

is assumed to meet the following requirements. 

Note: Future versions of these MASPS may require that the airspeed data be broadcast 

by ADS-B Out, and be available to the ASSAP and CDTI. 

1. The air data source will be capable of providing digital outputs of A/V pressure 

altitude and pressure altitude rate suitable for surveillance based applications. 

2. The pressure altitude data will include the following: 

� Pressure altitude referenced to standard temperature and pressure (1013.25 hPa 

or mB, or 29.92 in. Hg). 

� Pressure altitude outputs covering the operating altitude range of the A/V. 

� Pressure altitude validity flag. 

� Quantization data to determine if pressure altitude outputs are encoded as 25, or 

100 ft. 

Note: The finer altitude data resolution of 25 ft is preferred. 

3. The altitude rate data, if available, will include the following: 

3.6.3 Heading Source 


� Rate of change of pressure altitude outputs covering the operating altitude rate 

range of the A/V. 

� Pressure altitude rate validity flag. 

Note: Complimentary inertial/barometric filtered altitude rate is the preferred 

source. 

It is assumed that the majority of airborne ASA installations will be equipped with 

heading data sources to indicate the directional orientation of the A/V. To qualify for use 

by ASA, the selected heading data source is assumed to meet the following requirements. 

The heading data source will be capable of providing outputs of A/V heading suitable for 

surveillance based applications. 

The heading data source will provide heading outputs supporting the full range of 

possible headings (e.g. full circle from 0º to 360º). 

The heading data source will provide heading with a resolution of 6º of arc or finer. 

The heading data source will provide heading with an accuracy of ±10º, or better (95%).

3.6.4 TCAS 

The heading data will include the following: 

� Means to determine if A/V heading is referenced to true north or magnetic north. 

� Heading validity flag. 

TCAS interfaces to ASA in two ways: first, if TCAS is installed on an ADS-B 

transmitting ship, the fact that TCAS is installed, and the TCAS status (e.g., resolution 

advisory) are included in the ADS-B transmission (§3.1.5.26). The installation and status 

is reported by the ADS-B receiver (§3.3.1.1.1). If TCAS is installed with ASA, and if the 

CDTI is also used as the TCAS traffic display, TCAS tracks and their status should be 

supplied to ASA. TCAS interfaces directly to ASSAP, as indicated in Figure 3-1. Table 

3.6.4 indicates the traffic data that should be interfaced to ASSAP from TCAS. 

Table 3.6.4: TCAS Traffic Data Interface to ASSAP 

Data Item [note 4] Reference Section 

TCAS Traffic Status §3.4.1.3 

Target Range §3.4.1.3 

Target Bearing §3.4.1.3 

Target Pressure Altitude [note 2] §3.4.1.3 

TCAS Altitude Rate [notes 3] §3.4.1.3 

Mode S Address [note 1 and 2] §3.4.1.3 

TCAS Track ID §3.4.1.3 

TCAS Report Time [note 2] §3.4.1.3 

Notes for Table 3.6.4: 

1. ASSAP that are hosted in the internal TCAS LRU have access to the Mode S (ICAO 

24-bit) address (on 1090 MHz Extended Squitter installations). 

2. For ASSAPs that are hosted externally to TCAS, this information requires a change 

to the standard TCAS bus outputs defined in ARINC 735B that currently does not 

provide the Mode S address code, nor does it necessarily output Mode C pressure 

altitude. 

3. For display of up/down arrow on the CDTI if there is no ADS-B track that correlates 

with the TCAS track. 

4. Range rate and range acceleration may be required in the future. 

3.6.5 Airport Surface Maps 

An airport surface map is necessary to support the SURF application for each airport 

where these applications are used. 

The subsystem that provides the airport surface maps is external to ASA system 

boundaries defined in this MASPS. Airport surface maps are assumed to be encoded into 

an electronic database. The features, quality, and reference datum assumptions for this 

ASA external database are stated in the following sub-sections. 

Unless stated otherwise, all of the assumptions within this section including its 

subsections apply for the SURF application. 


3.6.5.1 Features 

3.6.5.2 Quality 


All airport features shown on the CDTI for the SURF application is based on the airport 

surface map database. At a minimum, this database is assumed to contain the runways 

and taxiways within the maneuvering area of the airport. 

Other airport features are desired to be represented in the database including, for 

example, apron areas, stand guidance lines, parking stand areas, deicing areas, clearways, 

and vertical objects like buildings and towers. 

Note 1: The “maneuvering area” of an airport is defined as the part of an airport used 

for take-off, landing, and taxiing of aircraft, excluding aprons [reference ICAO 

Annex 14, section 1]. 

All features of the database are assumed to have sufficient information to support: 

1. Determining their horizontal position with respect to the WGS-84 reference datum, 

and 

2. Appropriately labeling the feature on the CDTI. 

It is further assumed that the vertical position for at least one feature for each airport 

surface map is given. 

Note 2: Vertical position is used by the SURF application to support determining 

whether or not a flying aircraft is close enough to the airport surface for SURF 

situational awareness display purposes. 

Airport surface map database quality is assessed in terms of feature position accuracy, 

resolution, integrity, and timeliness (currency). 

The accuracy, resolution, and integrity quality of the airport surface map database are 

assumed to comply with at least one of the following: 

1. The database requirements specified in RTCA DO-257A (or subsequent revision) for 

the Aerodrome Moving Map Display (AMMD), or 

2. RTCA DO-272C (or subsequent revision) “Medium” or higher quality database 

standard (see note 1 below), or 

3. Database judged by the approval authority to be current and operationally acceptable 

for the intended application(s). 

Note 1: Airport map database requirements are defined in RTCA DO-272C. RTCA 

DO-272C defines three categories of airport map data including “Coarse,” 

“Medium,” and “Fine.” The categories are groupings for the minimum 

required accuracy, resolution, and integrity quality of the database. 

The database is assumed to be current. 

Note 2: The valid dates of applicability for the airport surface map database are 

defined by the Aeronautical Information Regulation and Control (AIRAC).

3.6.5.3 Reference Datum 

The airport surface map database shall (R3.xxx) use WGS-84 as its reference datum. 

Note: There are at least three reasons for using WGS 84 as the reference datum for the 

airport map. First, international standards require “geographical coordinates 

indicating latitude and longitude [for airport data] be determined and reported 

to the aeronautical information services authority in terms of WGS 84,” 

according to §2.1.5 in ICAO Annex 14. Thus, the data in WGS-84 is likely to be 

available. Second, WGS 84 is the coordinate frame required for transmitting 

traffic position on ADS-B. Third, ownship position is provided to ASSAP/CDTI 

in WGS-84 reference datum. While it is possible to transform data from one 

coordinate frame to another, it is required for the standards documents to use a 

common standard coordinate frame. 

3.6.6 Flight ID Source 

ASA receive participants utilize Flight IDs received from ASA transmit participants. The 

Flight ID of traffic can also be used by crews to unambiguously identify ASA 

participants on the CDTI. The own-ship Flight ID might be provided by one of many 

different sources, including; Mode S/TCAS Control Panel, Flight Management System, 

ACARS, or an Electronic Flight Bag. 

The ASA transmit subsystem shall (R3.xxx) be provided with an own-ship Flight ID of 

up to 8 characters. 

3.6.7 Flight Control System/Mode Control Panel 

The ASA installation will be provided with information available from the Flight Control 

System/Mode Control Panel, which may include; Selected Heading, Selected Altitude, 

and CAS/Mach display mode indication. 

3.6.8 Other External Systems 

In the future, ASA may interface with other systems, such as: 

� Flight control systems 

� FIS-B / Weather and NAS status updates / TIS-B Service status 

� Terrain and obstacles 

� Addressed data link 

� ADS-Contract 

� Flight Management Systems for other ASA application data 

3.7 Functional Level Requirements 

(UNASSIGNED) 





4 ADS-B IN System Applications Requirements 

4.1 Basic Airborne Situation Awareness (AIRB) 

CDTI provides traffic information to assist the flight crew in visually acquiring traffic out 

the window and provide traffic situational awareness beyond visual range. The CDTI can 

be used to initially acquire traffic or as a supplement to other sources of traffic 

information. The AIRB application is expected to improve both safety and efficiency by 

providing the flight crew enhanced traffic awareness. The AIRB application also 

provides Flight ID and ground speed of selected traffic. Refer to RTCA DO-319 

[EUROCAE ED-164] for a complete AIRB description. 

A basic version of the application, Enhanced Visual Acquisition (EVAcq), is defined in 

RTCA DO-317A [EUROCAE ED-194] to support the most basic General Aviation users. 

In this application, CDTI provides traffic information to assist the flight crew in visually 

acquiring traffic out the window. The CDTI can be used to initially acquire traffic or as a 

supplement to other sources of traffic information. This application is expected to 

improve both safety and efficiency by providing the flight enhanced traffic awareness. 

4.2 Visual Separation on Approach (VSA) 

The CDTI is used to assist the flight crew in acquiring and maintaining visual contact 

during visual separation on approach. The CDTI is also used in conjunction with visual, 

out-the-window contact to follow the preceding aircraft during the approach. The VSA 

application is expected to improve both the safety and the performance of visual 

separation on approach. It may allow for the continuation of visual separation on 

approach when they otherwise would have to be suspended because of the difficulty of 

visually acquiring and tracking the other preceding aircraft. Refer to RTCA DO-314 

[EUROCAE ED-160] for a complete VSA description. 

4.3 Basic Surface Situational Awareness (SURF) 

In this application, the CDTI includes an airport surface map underlay, and is used to 

support the flight crew in making decisions about taxiing, takeoff and landing. This 

application is expected to increase efficiency of operations on the airport surface and 

reduce the possibility of runway incursions and collisions. Refer to RTCA DO-322 

[EUROCAE ED-165] for a description of the SURF application. 

4.4 In Trail Procedures (ITP) 


The objective of the In-Trail Procedure (ITP) is to enable aircraft that desire flight level 


improving flight efficiency and safety. The ITP achieves this objective by permitting a 

climb-through or descend-through maneuver between properly equipped aircraft, using a 

new distance-based longitudinal separation minimum during the maneuver. The ITP 

requires the flight crew to use information derived on the aircraft to determine if the 

initiation criteria required for an ITP are met. The initiation criteria are designed such 

that the spacing between the estimated positions of own ship and surrounding aircraft is 

no closer than an approved distance throughout the maneuver. ITP requires specific

application-unique processing and display parameters. Refer to RTCA DO-312 

[EUROCAE ED-159] for a complete ITP description. 

4.5 Interval Management 

4.5.1 FIM 

4.5.2 GIM-S 

Airborne Spacing - Flight Deck Interval Management (ASPA-FIM) (as defined in RTCA 

DO-328) describes a set of airborne (i.e., flight deck) capabilities designed to support a 

range of Interval Management (IM) Operations whose goal is precise inter-aircraft 

spacing. IM is defined as the overall system that enables the improved means for 

managing traffic flows and aircraft spacing. This includes both the use of ground and 

airborne tools, where ground tools assist the controller in evaluating the traffic picture 

and determining appropriate clearances to merge and space aircraft efficiently and safely, 

and airborne tools allow the flight crew to conform to the IM Clearance. 

IM requires a controller using IM to provide an IM Clearance. While some IM 

Clearances will keep the IM Aircraft on its current route and result only in speed 

management, other clearances may include a turn for path lengthening or shortening. 

The objective of the IM Clearance is for the IM Aircraft to achieve and/or maintain an 

Assigned Spacing Goal relative to a Target Aircraft. The key addition to current 

operations is the provision of precise guidance within the flight deck to enable the flight 

crew to actively manage the spacing relative to the Target Aircraft. During IM 

Operations, the controller retains responsibility for separation, while the flight crew is 

responsible for using the FIM Equipment to achieve and/or maintain the ATC Assigned 

Spacing Goal. This does not differ greatly from current operations when controllers 

provide speed and turn clearances to manage traffic. With ASPA-FIM, however, the 

flight crew has the capabilities and responsibility to actively manage the speed of the 

aircraft to meet the operational goals set by the controller. Enabling flight crews to 

manage their spacing using the FIM Equipment is expected to reduce controller workload 

related to the IM Aircraft by relieving the controller of the need to communicate several 

speed and/or vector instructions. 

In response to projected increases in air traffic volume and complexity for the National 

Airspace System (NAS), applications for Interval Management (IM) are being developed 

to enhance interval management, including merging and spacing operations in en route 

and terminal areas for the near-term and mid-term timeframes. These applications 

include Flight deck-based IM (FIM), in which the flight crew makes use of specialized 

avionics that provides speed and turn commands. The utilization of FIM in the NAS 

presupposes the existence of appropriate and integrated Ground-based IM (GIM) 

capabilities that provides controllers the capabilities to initiate, monitor, and terminate 

FIM-S operations as well as manage non FIM equipped flights. During IM operations, 

responsibility for separation may reside with the controller (referred to as spacing 

applications or GIM/FIM-S) or with the flight crew (referred to as delegated separation 

applications or GIM/FIM-DS). Figure 4-1 provides an overview of the various 

applications that can be part of IM. 



Interval Management – 

Spacing (IM‐S) 

Ground IM‐S 

(GIM‐S) 

Interval Management 

Flight Deck 

Based IM‐S 

(FIM‐S) 

Interval Management – 

Delegated Separation (IM‐ 

DS) 

Ground IM‐DS 

(GIM‐DS) 

Flight Deck Based 

IM‐DS (FIM‐DS) 

Figure 4-1: Overview of IM Applications 

FIM‐DS with Wake 

Risk Management 

GIM-S applications, either together with the use of FIM-S or by itself, improve aircraft 

spacing during departure, arrival, and cruise phase of flight. The GIM-S applications 

assist in reducing the effect of airborne congestion, while increasing runway throughput, 

and increase the efficiency and capacity of interval management, including merging and 

spacing operations. The GIM-S application utilizes Automatic Dependent Surveillance – 

Broadcast (ADS-B) that increases accuracy in trajectory prediction and facilitates more 

efficient spacing control through the use of speed advisories. While GIM-S can be 

operated without FIM-S, benefits are expected to increase with the participation of FIM-S 

aircraft to deliver aircraft at higher accuracy, consistency, and at comparable or lower 

controller workload. 

4.6 Future Applications 

(We agreed to put in a paragraph on Conflict Detection) 

4.6.1 Airport Surface with Indications and Alerts (SURF-IA) 

The Airport Surface with Indications and Alerts (SURF IA) application enhances the 

basic SURF application (as described in RTCA DO-322 and EUROCAE ED-165) to 

increase its effectiveness in preventing runway incursions. The SURF IA application 

adds two distinct components to the basic SURF for that purpose, (1) SURF IA 

indications and (2) SURF IA alerts. 

SURF IA indications identify the runway status and traffic status that could represent a 

safety hazard. SURF IA indications are presented under normal operational conditions, 

do not require immediate flight crew awareness, and do not include auditory and visual 

attention getters. Secondly, SURF IA alerts are displayed to attract the flight crews’ 

attention to non-normal surface traffic conditions. SURF IA alerts facilitate a timely 

response via auditory and visual attention getters. SURF IA alerts are non-directive and 

do not provide guidance about how to respond to the alert. See Figure 4-2 for a notional 

example of displays. SURF IA indications and alerts include the display of off-scale 

indications for safety relevant traffic that would otherwise not be visible on the display.

Figure 4-2: Example for SURF IA Indication (left) and A SURF IA warning alert 

(right) 

SURF IA is applicable for operations at controlled and uncontrolled airports and 

designed for installation on airplanes. SURF IA indications and alerts are supplemental 

to existing means and procedures of maneuvering aircraft on and near an airport. 

SURF IA is described in RTCA DO-323, which contains the detailed safety, 

performance, and interoperability requirements for the application. RTCA DO-323 

requires ADS-B IN, but does not require ground infrastructure such as Traffic 

Information Service – Broadcast (TIS-B) or Automatic Dependent Surveillance 

Rebroadcast (ADS-R). However, SURF IA will utilize that surveillance information if 

available at sufficient quality and integrity. 

4.6.2 Traffic Situational Awareness with Alerts (TSAA) 

The intended function of Traffic Situational Awareness with Alerts (TSAA) application 

is to increase flight crew traffic situation awareness by providing timely alerts of airborne 

traffic in the vicinity. TSAA is intended to reduce the risk of a near mid-air or mid-air 

collision by aiding in visual acquisition as part of the flight crew’s existing see-and-avoid 

capability. 

TSAA provides alerts using the Traffic Display and aural messages to direct attention out 

the window, assisting the pilot or flight crew with visual acquisition in both Visual 

Meteorological Conditions and Instrument Meteorological Conditions, if possible. The 

application functions under both Visual Flight Rules (VFR) and Instrument Flight Rules 

(IFR). When a Traffic Display is available, it builds on the Enhanced Visual Acquisition, 

or AIRB application. TSAA is also capable of providing alerts without a Traffic Display. 

These alerts are for predicted airborne conflicts or relevant nearby traffic. 

The alert acts as an attention-getting mechanism that reduces the effort used to scan the 

Traffic Display (if installed) while still permitting the pilot or flight crew to determine if 

a conflict exists and which aircraft are in conflict. After receiving the alert, the pilot or 



flight crew will take the necessary action in accordance with the operational rules in 

effect at the time.



Appendix A 

Acronyms and Definitions of Terms

This page intentionally left blank.

A Acronyms and Definitions of Terms 

A.1 Acronyms 

Appendix A 

Page A-1 

The following acronyms and symbols for units of measure are used in this document. 

1090ES 1090 MHz Extended Squitter 

A/S Adjacent Ship 

A/V Aircraft/Vehicle 

AC Aviation Circular (FAA) 

AC Aircraft 

ACAS Airborne Collision Avoidance System. (ACAS is the ICAO standard for 

TCAS) 

ACL ASA Capability Level 

ACM Airborne Conflict Management 

ADS Automatic Dependent Surveillance 

ADS-A Addressed ADS 

ADS-B Automatic Dependent Surveillance – Broadcast 

ADS-C ADS-Contract 

ADS-R ADS-B – Rebroadcast 

AGC Automatic Gain Control 

AGL Above Ground Level 

AIC Aeronautical Information Circular 

AILS Airborne Information for Lateral Spacing 

AIM Aeronautical Information Manual, (FAA publication) 

AIWP Applications Integrated Work Plan 

ALPA Air Line Pilots Association 

AMASS Airport Movement Area Safety Systems 

AMMD Aerodrome Moving Map Display (an acronym from [DO-257A]) 

ANSD Assured Normal Separation Distance 

AOC Aeronautical Operational Control 

AOC Airline Operations Center 

AOPA Aircraft Owners and Pilots Association 

APU Auxiliary Power Unit 

ARFF Aircraft Rescue and Fire Fighting 

ARTCC Air Route Traffic Control Center 

ARV Air Referenced Velocity 

ASA Aircraft Surveillance Applications (to be distinguished from Airborne 

Surveillance Applications which not referenced as ASA in this 

document) 

ASAS (1) Airborne Separation Assurance System (an acronym used in 

[PO-ASAS]) or (2) Aircraft Surveillance Applications System (an 

acronym used in these MASPS). The two terms are equivalent. 

ASDE-3 Airport Surveillance Detection Equipment version 3 

ASDE-X Airport Surveillance Detection Equipment X-band 

ASF Air Safety Foundation (AOPA organization) 

ASIA Approach Spacing for Instrument Approaches 

ASOR Allocation of Safety Objectives and Requirements 

ASRS Aviation Safety Reporting Service 

ASSA Airport Surface Situational Awareness 

ASSAP Airborne Surveillance and Separation Assurance Processing 

©20xx, RTCA, Inc.

Appendix A 

Page A-2 

©20xx, RTCA, Inc. 

AT Air Traffic 

ATC Air Traffic Control 

ATCRBS Air Traffic Control Radar Beacon System 

ATIS Automated Terminal Information System 

ATM Air Traffic Management 

ATP Airline Transport Pilot (rating) 

ATS Air Traffic Services 

ATSA Airborne Traffic Situational Awareness 

ATSP Air Traffic Service Provider 

A/V Aircraft or Vehicle 

BAQ Barometric Altitude Quality 

Bps Bits per Second 

CAASD Center for Advanced Aviation System Development 

CARE Co-operative Actions of R&D in EUROCONTROL 

CAZ Collision Avoidance Zone 

CC Capability Class 

CD Conflict Detection 

CD&R Conflict Detection and Resolution 

CDTI Cockpit Display of Traffic Information 

CDU Control and Display Unit 

CDZ Conflict Detection Zone 

CFR Code of Federal Regulations 

CNS Communications, Navigation, Surveillance 

CP Conflict Prevention 

CPA Closest Point of Approach 

CPDLC Controller Pilot Data Link Communications 

CR Conflict Resolution 

CRC Cyclic Redundancy Check 

CRM Crew Resource Management 

CSPA Closely Spaced Parallel Approaches 

CTAF Common Traffic Advisory Frequency 

CTAS Center TRACON Automation System 

DAG Distributed Air Ground 

DGPS Differential GPS 

DH Decision Height 

DME Distance Measuring Equipment 

DMTL Dynamic Minimum Trigger Level 

dps Degree per Second 

DOT Department of Transportation, U. S. Government 

ECAC European Civil Aviation Conference 

ELT Emergency Locator Transmitter 

EMD Electronic Map Display 

EPU Estimated Position Uncertainty 

ERP Effective Radiated Power 

ES Extended Squitter 

ETA Estimated Time of Arrival 

EUROCAE European Organization for Civil Aviation Equipment 

EUROCONTROL European Organization for the Safety of Air Navigation 

EVAcq Enhanced Visual Acquisition

EVApp Enhanced Visual Approach 

FAA Federal Aviation Administration 

FAF Final Approach Fix 

FAR Federal Aviation Regulation 

FAROA Final Approach and Runway Occupancy Awareness 

FAST Final Approach Spacing Tool 

FEC Forward Error Correction 

FFAS Free Flight Airspace 

FIS-B Flight Information Services - Broadcast 

FL Flight Level 

FMEA Failure Modes and Effects Analysis 

FMS Flight Management System 

fpm Feet Per Minute 

FRUIT False Replies Unsynchronized in Time (also see Garble) 

FSDO Flight Standards District Office (FAA) 

FSS Flight Service Station 

ft Feet 

g Acceleration due to earth's gravity 

GA General Aviation 

GBAS Ground-Based Augmentation System 

GHz Giga Hertz 

GLONASS Global Orbiting Navigation Satellite System 

GLS GNSS Landing System 

gnd Ground 

GNSS Global Navigation Satellite System 

GPS Global Positioning System 

GSA Ground-based Surveillance Application 

GVA Geometric Vertical Accuracy 

HFOM Horizontal Figure Of Merit 

HGS Head-Up Guidance System 

HIRF High Intensity Radiated Field 

HMI Hazardously Misleading Information 

HPL Horizontal Protection Limit 

HUD Head-Up Display 

Hz Hertz 

IAC Instantaneous Aircraft Count 

IAS Indicated Airspeed 

ICAO International Civil Aviation Organization 

ICR Integrity Containment Risk 

ICSPA Independent Closely Spaced Parallel Approaches 

ID Identification 

IFR Instrument Flight Rules 

ILS Instrument Landing System 

IMC Instrument Meteorological Conditions 

INS Inertial Navigation System 

ITC In-Trail Climb 

ITD In-Trail Descent 

ITU International Telecommunication Union 

Appendix A 

Page A-3 

©20xx, RTCA, Inc.

Appendix A 

Page A-4 


JTIDS Joint Tactical Information Distribution System 

kg Kilogram 

LA Los Angeles 

LAAS Local Area Augmentation System 

LAHSO Land And Hold Short Operations 

lb Pound 

LL Low Level 

LOS Loss of Separation 

LSB Least Significant Bit 

m meter (or “metre”), the SI metric system base unit for length 

MA Maneuver Advisory 

MAC Midair Collision 

MACA Midair Collision Avoidance 

MAS Managed Airspace 

MASPS Minimum Aviation System Performance Standards 

MCP Mode Control Panel 

MFD Multi-Function Display 

MHz Mega Hertz 

mm Millimeter 

MOPS Minimum Operation Performance Standards (RTCA documents) 

mrad milliradian. 1 mrad = 0.001 radian 

MS Mode status 

MSL Minimum Signal Level 

MTL Minimum Trigger Level 

MTBF Mean-Time-Between-Failures 

MTR Military Training Route 

MTTF Mean Time To Failure 

MTTR Mean-Time To Restore 

N/A Not Applicable or No Change 

NAC Navigation Accuracy Category (sub “p” is for position and sub “v” is for 

velocity) 

NAS National Airspace System 

NASA National Aeronautics and Space Administration 

ND Navigation Display 

NIC Navigation Integrity Category 

NICBARO 

Barometric Altitude Integrity code 

NLR Nationaal Lucht- en Ruimtevaartlaboratorium - National Aerospace 

Laboratory in the Netherlands 

NM Nautical Mile 

NMAC Near Mid Air Collision 

NMPH Nautical Miles Per Hour 

NOTAM NOTice to AirMen 

NPA Non-Precision Approach 

NSE Navigation System Error 

NTSB National Transportation Safety Board 

NUC Navigation Uncertainty Category 

O/S Own Ship

OC On Condition 

OH Operational Hazard 

OHA Operational Hazard Assessment 

OPA Operational Performance Assessment 

OSA Operational Safety Analysis 

OSED Operational Services and Environment Description 

OTW Out-the-Window 

Appendix A 

Page A-5 

PA Prevention Advisory 

PAPI Precision Approach Path Indicator 

PAZ Protected Airspace Zone 

PF Pilot Flying 

PFD Primary Flight Display 

PIREP Pilot Report 

PNF Pilot Not Flying 

PO-ASAS Principles of Operation for the Uses of ASAS (See the entry in Appendix 

B for [PO-ASAS]) 

PRM Precision Runway Monitor 

PSR Primary Surveillance Radar 

R&D Research and Development 

RA Resolution Advisory (TCAS II), 

rad radian, an SI metric system derived unit for plane angle 

RAIM Receiver Autonomous Integrity Monitoring 

RC 

Radius of Containment 

RCP Required Communications Performance 

Rcv Receive 

REQ No. Requirement Number 

RIPS Runway Incursion Prevention System 

RMP Required Monitoring Performance 

RMS Root Mean Square 

RNAV Area Navigation 

RNP Required Navigation Performance 

RSP Required Surveillance Performance 

RTA Required Time of Arrival 

RVR Runway Visual Range 

RVSM Reduced Vertical Separation Minimum 

Rx receive, receiver 

s second, the SI metric system base unit for time or time interval 

SA Selective Availability 

SAE Society of Automotive Engineers 

SAR Search and Rescue 

SARPs Standards and Recommended Practices 

SBAS Satellite-Based Augmentation System 

SC Special Committee 

SDA System Design Assurance 

SF21 Safe Flight 21 

SGS Surface Guidance System 

SI Système International d’Unités (International System of Units not to be 

confused with the Mode Select Beacon system SI function) 

SIL Source Integrity Level 

©20xx, RTCA, Inc.

Appendix A 

Page A-6 


SIRO Simultaneous Intersecting Runway Operations 

SM Statute Miles 

SMM Surface Moving Map 

SNR Signal-to-Noise Ratio 

SPR Surveillance Position Reference point 

SPS Standard Positioning Service 

SSR Secondary Surveillance Radar 

STP Surveillance Transmit Processing 

SUA Special Use Airspace 

SV State Vector 

SVFR Special Visual Flight Rules 

TA Traffic Advisory (TCAS II) 

TAS True Airspeed 

TAWS Terrain Awareness and Warning System 

TBD To Be Defined 

TC Trajectory Change (for Trajectory Change report) 

TCAS Traffic Alert and Collision Avoidance System (See ACAS) 

TCAS I TCAS system that does not provide resolution advisories 

TCAS II TCAS system that provides resolution advisories 

TCMI Trajectory Change Management Indicator 

TCP Trajectory Change Point 

TCV Test Criteria Violation 

TESIS Test and Evaluation Surveillance and Information System 

TIS Traffic Information Service 

TIS-B Traffic Information Service – Broadcast 

TLAT Technical Link Assessment Team 

TLS Target Level Safety 

TMA Traffic Management Area 

TMC Traffic Management Coordinator 

TMU Traffic Management Unit 

TOA Time of Applicability 

TORCH Technical ecOnomical and opeRational assessment of an ATM Concept 

acHiveable from the year 2005 

TQL Transmit Quality Level 

TRACON Terminal Area CONtrol 

TS Target State (for Target State report) 

TSD Traffic Situation Display 

TSE Total System Error 

TTF Traffic To Follow 

TTG Time to Go 

Tx Transmit 

U.S. United States of America 

UAT Universal Access Transceiver 

UHF Ultra High Frequency: The band of radio frequencies between 300 MHz 

and 3 GHz, with wavelengths between 1 m and 100 mm. 

UMAS Unmanaged Airspace 

UPT User Preferred Trajectory 

USAF United States Air Force. 

UTC Universal Time, Coordinated, formerly Greenwich Mean Time 

Vapp Final Approach Speed

Appendix A 

Page A-7 

VDL-4 Very High Frequency Data Link Mode 4 

VEPU Vertical Position Uncertainty 

VFOM Vertical Figure Of Merit 

VFR Visual Flight Rules 

VHF Very High Frequency: The band of radio frequencies between 30 MHz 

and 300 MHz, with wavelengths between 10 m and 1 m. 

VMC Visual Meteorological Conditions 

VOR Very High Frequency Omni-directional Radio 

VPL Vertical Protection Limit 

Vref Reference Landing Velocity 

WAAS Wide Area Augmentation System 

WCB Worst Case Blunder 

WG Working Group 

WGS-84 World Geodetic System - 1984 

xmit transmit, transmitter 

©20xx, RTCA, Inc.

Appendix A 

Page A-8 

A.2 Definitions of Terms 

The following are definitions of terms used in this document. Square brackets, e.g. [RTCA DO-242A], 

refer to entries in the bibliography in Appendix B. 

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. 

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 Aircraft Subsystem – The set of avionics, including antenna(s), which perform ADS-B 

functionality in an aircraft. Several Equipage Classes of ADS B Aircraft Subsystems are 

specified, with different performance capabilities. 

ADS-B Application – An operational application, external to the ADS B System, which requires ADS B 

Reports as input. 

ADS-B Participant – An ADS-B network member that is a supplier of information to the local ADS-B 

subsystem and/or a user of information output by the transmitting subsystem. This does not 

include the ADS-B subsystem itself. 

ADS-B Participant Subsystem – An entity which can either receive ADS B messages and recover ADS- 

B Reports (Receiving Subsystem) and/or generate and transmit ADS-B messages (Transmitting 

Subsystem). 

ADS-B Message – An ADS-B Message is a block of formatted data which conveys information used in 

the development of ADS B reports in accordance with the properties of the ADS B Data Link. 

ADS-B Message Assembly Function – Takes as inputs ADS B source data. Prepares contents of, but 

not envelope for, ADS-B messages and delivers same to the ADS B Message Exchange Function. 

ADS-B Message Exchange Function – Takes as inputs the message data to be transmitted, packages the 

data within implementation specific envelopes to form messages to be transmitted. Messages are 

transmitted and received. Received messages are validated and accepted and the implementation 

specific envelope is discarded. The received message data is provided to the ADS-B Report 

Assembly Function. Some subsystems transmit only; some subsystems receive only. The 

message exchange function includes the transmit and receive antennas along with any diversity 

mechanisms. 

ADS-B Position Reference Point – The ADS-B position reference point is the position on an A/V that is 

broadcast in ADS-B messages as the nominal position of that A/V. For aircraft and ground 

vehicles, this position is the center of a rectangle that is aligned parallel to the A/V’s heading and 

has length and width equal to the longest possible length and width for an aircraft with the same 

length and width codes as that element transmits while on the surface. The ADS-B position 

reference point is located such that the actual extent of the A/V is contained entirely that rectangle 

centered on the ADS-B position reference point. 

©20xx, RTCA, Inc.

Appendix A 

Page A-9 

ADS-B Report – ADS-B Reports are specific information provided by the ADS B receive 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 Report Assembly Function – Takes as inputs the received message data provided from the 

ADS-B Message Exchange Function. Develops ADS B reports using the received message data 

to provide an ADS-B report as output to an ADS-B application. 

ADS-B Source Data – The qualified source data provided to the ADS B Message Generation Function 

and ultimately used in the development of ADS B Reports. 

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. 

Aeronautical Radionavigation Service – A radionavigation service intended for the benefit and safe 

operation of aircraft. 

Airborne Collision – This occurs when two aircraft that are in flight come into contact. The word 

“collision” is not an antonym of the word “separation.” 

Airborne Separation Assistance System (ASAS) – An aircraft system based on airborne surveillance 

that provides assistance to the flight crew supporting the separation of their aircraft from other 

aircraft. 

Airborne Separation Assistance Application – A set of operational procedures for controllers and flight 

crews that makes use of an Airborne Separation Assistance System to meet a defined operational 

goal.Airborne Surveillance and Separation Assurance Processing (ASSAP) – ASSAP is the 

processing subsystem that accepts surveillance inputs, (e.g., ADS-B reports), performs 

surveillance processing to provide reports and tracks, and performs application-specific 

processing. Surveillance reports, tracks, and any application-specific alerts or guidance are 

output by ASSAP to the CDTI function. ASSAP surveillance processing consists of track 

processing and correlation of ADS-B, TIS-B, ADS-R, and TCAS reports). 

Airborne Traffic Situational Awareness applications (ATSA applications) – These applications are 

aimed at enhancing the flight crews’ knowledge of the surrounding traffic situation, both in the 

air and on the airport surface, and thus improving the flight crew’s decision process for the safe 

and efficient management of their flight. No changes in separation tasks are required for these 

applications.” [PO-ASAS, p.1]Aircraft Surveillance Applications (ASA) – Airborne and 

surface functions that use ADS-B data and on board processing to be displayed to the flight crew 

to enhance their situational awareness, identify potential conflicts and/or collisions, and in the 

future to change the own-ship’s spacing from other aircraft. 

Aircraft/Vehicle (A/V) – Either: 1) a machine or service capable of atmospheric flight, or 2) a vehicle on 

the airport surface movement area. 

A/V Address – The term “address” is used to indicate the information field in an ADS-B Message that 

identifies the A/V that issued the message. The address provides a convenient means by which 

ADS-B receiving units, or end applications, can sort messages received from multiple issuing 

units. 

©20xx, RTCA, Inc.

Appendix A 

Page A-10 

Air/Ground State – An internal state in the transmitting ADS-B subsystem that affects which SV report 

elements are to be broadcast, but which is not required to be broadcast in ADS-B messages from 

that participant. 

Air Mass Data – Air mass data includes barometric altitude, air speed, and heading. 

Air Referenced Velocity (AVR) Report 

Alert – A general term that applies to all advisories, cautions, and warning information, can include 

visual, aural, tactile, or other attention-getting methods. 

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. 

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. 

Approach Spacing for Instrument Approaches (ASIA) – An application, described in Appendix I, in 

which, when approaching an airport, the flight crew uses the CDTI display to help them control 

their own-ship distance behind the preceding aircraft. 

ASAS application – A set of operational procedures for controllers and flight crews that makes use of the 

capabilities of ASAS to meet a clearly defined operational goal. [PO-ASAS, p. 1] 

Assured Collision Avoidance Distance (ACAD) – The minimum assured vertical and horizontal 

distances allowed between aircraft geometric centers. If this distance is violated, a collision or 

dangerously close spacing will occur. These distances are fixed numbers calculated by risk 

modeling. 

Assured Normal Separation Distance (ANSD) – The normal minimum assured vertical and horizontal 

distances allowed between aircraft geometric centers. These distances are entered by the pilot or 

set by the system. Initially the ANSD will be based on current separation standards (and will be 

larger than the ACAD). In the long term, collision risk modeling will set the ANSD. Ultimately 

the ANSD may be reduced toward the value of the ACAD. 

Automatic Dependent Surveillance-Broadcast (ADS-B) – ADS-B is a function on an aircraft or surface 

vehicle operating within the surface movement area that periodically broadcasts its state vector 

(horizontal and vertical position, horizontal and vertical velocity) and other information. ADS-B 

is automatic because no external stimulus is required to elicit a transmission; it is dependent 

because it relies on on-board navigation sources and on-board broadcast transmission systems to 

provide surveillance information to other users. 

Automatic Dependent Surveillance – Rebroadcast (ADS-R) – ADS-R is a “gateway” function on 

ground systems that rebroadcasts an ADS-B-like message from traffic (including surface 

vehicles) that utilizes one broadcast link (RF medium) to users such as airborne receive systems 

that utilize a different ADS-B broadcast link. 

Availability – Availability is an indication of the ability of a system or subsystem to provide usable 

service. Availability is expressed in terms of the probability of the system or subsystem being 

available at the beginning of an intended operation. 

©20xx, RTCA, Inc.

Appendix A 

Page A-11 

Background Application – An application that applies to all surveilled traffic of operational interest. 

One or more background applications may be in use in some or all airspace (or on the ground), 

but without flight crew input or automated input to select specific traffic. Background 

applications include: Enhanced Visual Acquisition (EV Acq), Conflict Detection (CD), Airborne 

Conflict Management (ACM), Airport Surface Situational Awareness (ASSA), and Final 

Approach and Runway Occupancy Awareness (FAROA). 

Barometric altitude – Geopotential altitude in the earth’s atmosphere above mean standard sea level 

pressure datum plane, measured by a pressure (barometric) altimeter. 

Barometric altitude error – For a given true barometric pressure, P0, the error is the difference between 

the transmitted pressure altitude and the altitude determined using a standard temperature and 

pressure model with P0. 

Barometric Altitude Integrity Code (NICBARO) – NICBARO is a one-bit flag that indicates whether or not 

the barometric pressure altitude provided in the State Vector Report has been cross-checked 

against another source of pressure altitude. 

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. 

Capability Class Codes – Codes that indicate the capability of a participant to support engagement in 

various operations. 

Closest Point of Approach (CPA) – The minimum horizontal distance between two aircraft during a 

close proximity encounter, also know as miss distance. 

Coast Interval – The maximum time interval allowed for maintaining an ADS-B report when no 

messages supporting that report are received. Requirements for coast interval are typically 

specified in terms of 99% probability of reception at a given range. 

Cockpit Display of Traffic Information (CDTI) – The pilot interface portion of a surveillance system. 

This interface includes the traffic display and all the controls that interact with such a display. 

The CDTI receives position information of traffic and own-ship from the airborne surveillance 

and separation assurance processing (ASSAP) function. The ASSAP receives such information 

from the surveillance sensors and own-ship position sensors. 

Cockpit Display of Traffic Information (CDTI) Display – A single CDTI display format. A physical 

display screen may have more than one instance of a CDTI Display on it. For example, a display 

with a split screen that has a Traffic Display on one half of the screen and a list of targets on the 

other half has two instances of CDTI Displays. 

Collision Avoidance – An unplanned maneuver to avoid a collision. 

Collision Avoidance Zone (CAZ) – Zone used by the system to predict a collision or dangerously close 

spacing. The CAZ is defined by the sum of Assured Collision Avoidance Distance (ACAD) and 

position uncertainties. 

©20xx, RTCA, Inc.

Appendix A 

Page A-12 

Collision Avoidance Zone (CAZ) Alert – An alert that notifies aircraft crew that a CAZ penetration will 

occur if immediate action is not taken. Aggressive avoidance action is essential. 

Conflict – A predicted violation of parameterized minimum separation criteria for adverse weather, 

aircraft traffic, special use airspace, other airspace, turbulence, noise sensitive areas, terrain and 

obstacles, etc. There can be different levels or types of conflict based on how the parameters are 

defined. Criteria can be either geometry based or time-based. This document only addresses 

aircraft traffic. See Traffic Conflict. 

Conflict Detection – The discovery of a conflict as a result of a computation and comparison of the 

predicted flight paths of two or more aircraft for the purpose of determining conflicts (ICAO). 

Conflict Detection Zone (CDZ) Alert – An alert issued at the specified look ahead time prior to CDZ 

penetration if timely action is not taken. Timely avoidance action is required. 

Conflict Detection Zone (CDZ) Penetration Notification – Notification to the crew when the measured 

separation is less than the specified CDZ. 

Conflict Detection Zone (CDZ) – Zone used by the system to detect conflicts. The CDZ is defined by 

the sum of ANSD, position uncertainties, and trajectory uncertainties. By attempting to maintain 

a measured separation no smaller than the CDZ, the system assures that the actual separation is 

no smaller than the ANSD. 

Conflict Management – Process of detecting and resolving conflicts. 

Conflict Prevention – The act of informing the flight crew of flight path changes that will create 

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 – A maneuver that removes all predicted conflicts over a specified “look-ahead” 

horizon. (ICAO - The determination of alternative flight paths, which would be free from 

conflicts and the selection of one of these flight paths for use.) 

Conformal – A desirable property of map projections. A map projection (a function that associate points 

on the surface of an ellipsoid or sphere representing the earth to points on a flat surface such as 

the CDTI display) is said to be conformal if the angle between any two curves on the first surface 

is preserved in magnitude and sense by the angle between the corresponding curves on the other 

surface. 

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

Cooperative Surveillance – Surveillance in which the target assists by cooperatively providing data 

using on-board equipment. 

Correlation – The process of determining that a new measurement belongs to an existing track. 

©20xx, RTCA, Inc.

Appendix A 

Page A-13 

Coupled Application – Coupled applications are those applications that operate only on specificallychosen 

(either by the flight crew or automation) traffic. They generally operate only for a 

specific flight operation. Coupled applications include Enhanced Visual Approach, Approach 

Spacing for Instrument Approaches, and Independent Closely Spaced Parallel Approaches. 

Coupled Target – A coupled target is a target upon which a coupled application is to be conducted. 

Covariance – A two dimensional symmetric matrix representing the uncertainty in a track’s state. The 

diagonal entries represent the variance of each state; the off-diagonal terms represent the 

covariances of the track state. 

Cross-link – A cross-link is a special purpose data transmission mechanism for exchanging data between 

two aircraft—a 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 


Data Block – A block of information about a selected target that is displayed somewhere around the edge 

of the CDTI display, rather than mixed in with the symbols representing traffic targets in the main 

part of the display. 

Data Tag – A block of information about a target that is displayed next to symbol representing that target 

in the main part of the CDTI display. 

Desirable – The capability denoted as Desirable is not required to perform the procedure but would 

increase the utility of the operation. 

Display range – The maximum distance from own-ship that is represented on the CDTI display. If the 

CDTI display is regarded as a map, then longer display ranges correspond to smaller map scales, 

and short display ranges correspond to larger map scales. 

Domain – Divisions in the current airspace structure that tie separation standards to the surveillance and 

automation capabilities available in the ground infrastructure. Generally there are four domains: 

surface, terminal, en route, and oceanic/remote and uncontrolled. For example, terminal airspace, 

in most cases comprises airspace within 30 miles and 10,000 feet AGL of airports with a terminal 

automation system and radar capability. Terminal IFR separation standards are normally 3 miles 

horizontally and 1000 feet vertically. 

Enhanced Visual Acquisition (EV Acq) – The enhanced visual acquisition application is an 

enhancement for the out-the-window visual acquisition of aircraft traffic and potentially ground 

vehicles. Pilots will use a CDTI to supplement and enhance out-the-window visual acquisition. 

Pilots will continue to visually scan out of the window while including the CDTI in their 

instrument scan,Note: An extended display range capability of at least 90 NM from own-ship is 

desirable for the ACM application. 

Estimation – The process of determining a track’s state based on new measurement information. 

Explicit Coordination – Explicit coordination of resolutions requires that the aircraft involved in a 

conflict communicate their intentions to each other and (in some strategies) authorize/confirm 

each other's maneuvers. One example of an explicit coordination technique would be the 

assignment of a 'master' aircraft, which determines resolutions for other aircraft involved in the 

conflict. Another is the crosslink used in ACAS. 

©20xx, RTCA, Inc.

Appendix A 

Page A-14 

Extended Display Range – Extended display range is the capability of the CDTI to depict traffic at 

ranges beyond the standard display range maximum of 40 NM. 

Note: An extended display range capability of at least 90 NM from own-ship is desirable for the 

ACM application. 

Extended Runway Center Line – An extension outwards of the center line of a runway, from one or 

both ends of that runway. 

Extrapolation – The process of predicting a track’s state forward in time based on the track’s last 

kinematic state. 

Field of View – The field of view of a CDTI is the geographical region within which the CDTI shows 

traffic targets. (Some other documents call this the field of regard.) 

Flight Crew – One or more cockpit crew members required for the operation of the aircraft. 

Foreground Application – An ASA application that the crew can activate and/or deactivate, the 

foreground applications is not intended to run full-time or activate automatically without crew 

interaction. 

Garble – Garble is either nonsynchronous, in which reply pulses are received from a transponder being 

interrogated by some other source (see FRUIT), or synchronous, in which an overlap of reply 

pulses occurs when two or more transponders reply to the same interrogation. 

Generic Conflict – A violation of parameterized minimum separation criteria for adverse weather, 

aircraft traffic, special use airspace, other airspace, turbulence, noise sensitive areas, terrain and 

obstacles, etc. There can be different levels or types of conflict based on how the parameters are 

defined. Criteria can be either geometry based or time-based. 

Geometric height – The minimum altitude above or below a plane tangent to the earth’s ellipsoid as 

defined by WGS-84. 

Geometric height error – Geometric height error is the error between the true geometric height and the 

transmitted geometric height. 

Geometric Vertical Accuracy (GVA) – The GVA parameter is a quantized 95% bound of the error of 

the reported geometric altitude, specifically the Height Above the WGS-84 Ellipsoid (HAE). 

This parameter is derived from the Vertical Figure of Merit (VFOM) output by the position 

source. 

GNSS sensor integrity risk – The probability of an undetected failure that results in NSE (navigation 

system error) that significantly jeopardizes the total system error (TSE) exceeding the 

containment limit. [DO-247, §5.2.2.1] 

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. 

Ground Speed – The magnitude of the horizontal velocity vector (see velocity). In these MASPS it is 

always expressed relative to a frame of reference that is fixed with respect to the earth’s surface 

such as the WGS-84 ellipsoid. 

©20xx, RTCA, Inc.

Appendix A 

Page A-15 

Ground Track Angle – The direction of the horizontal velocity vector (see velocity) relative to the 

ground as noted in Ground Speed. 

Hazard Classification – An index into the following table: 

Hazard Class Acceptable failure rate 

1 “Catastrophic” consequences 10 -9 per flight hour 

2 “Hazardous/Severe Major” consequences 10 -7 per flight hour 

3 “Major” consequences 10 -5 per flight hour 

4 “Minor” consequences 10 -3 per flight hour 

5 Inconsequential, no effect 

Hertz (Hz) – A rate where 1 Hz = once per second. 

Horizontal Protection Limit (HPL) – The radius of a circle in the horizontal plane (i.e. the plane tangent 

to the WGS-84 ellipsoid), with its center being the true position, which describes the region 

which is assured to contain the indicated horizontal position. This computed value is based upon 

the values provided by the augmentation system. 

Horizontal velocity – The horizontal component of velocity relative to a ground reference (see Velocity). 

Implicit Coordination – Implicitly coordinated resolutions are assured not to conflict with each other 

because the responses of each pilot are restricted by common rules. A terrestrial example of an 

implicit coordination rule is “yield to the vehicle on of conflict based on how the parameters are 

defined.” Criteria can be either geometry based or time-based. 

Integrity Containment Risk (ICR) – The per-flight-hour probability that a parameter will exceed its 

containment bound without being detected and reported within the required time to alert. (See 

also Integrity and Source Integrity Level.) 

In-Trail Climb – In-trail climb (ITC) procedures enables trailing aircraft to climb to more fuel-efficient 

or less turbulent altitude. 

In-Trail Descent – In-trail descent (ITD) procedures enables trailing aircraft to climb to more fuelefficient 

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. 

International Civil Aviation Organization (ICAO) – A United Nations organization that is responsible 

for developing international standards, recommended practices, and procedures covering a variety 

of technical fields of aviation. 

Latency – Latency is the time incurred between two particular interfaces. Total latency is the delay 

between the true time of applicability of a measurement and the time that the measurement is 

reported at a particular interface (the latter minus the former). Components of the total latency 

are elements of the total latency allocated between different interfaces. Each latency component 

will be specified by naming the interfaces between which it applies. 

©20xx, RTCA, Inc.

Appendix A 

Page A-16 

Latency Compensation – High accuracy applications may correct for system latency introduced position 

errors using ADS-B time synchronized position and velocity information. 

Low Level Alert – An optional alert issued when CDZ penetration is predicted outside of the CDZ alert 

boundary. 

Mixed Equipage – An environment where all aircraft do not have the same set of avionics. For example, 

some aircraft may transmit ADS-B and others may not, which could have implications for ATC 

and pilots. A mixed equipage environment will exist until all aircraft operating in a system have 

the same set of avionics. 

Nautical mile (NM) – A unit of length used in the fields of air and marine navigation. In this document, 

a nautical mile is always the international nautical mile of 1852 meters exactly. 

Navigation Accuracy Category - Position (NACP) – The NACP parameter describes the accuracy region 

about the reported position within which the true position of the surveillance position reference 

point is assured to lie with a 95% probability at the reported time of applicability. 

Navigation Accuracy Category - Velocity (NACV) – The NACV parameter describes the accuracy about 

the reported velocity vector within which the true velocity vector is assured to be with a 95% 

probability at the reported time of applicability. 

Navigation Integrity Category (NIC) – NIC describes an integrity containment region about the 

reported position, within which the true position of the surveillance position reference point is 

assured to lie at the reported time of applicability. 

Navigation sensor availability – An indication of the ability of the guidance function to provide usable 

service within the specified coverage area, and is defined as the portion of time during which the 

sensor information is to be used for navigation, during which reliable navigation information is 

presented to the crew, autopilot, or other system managing the movement of the aircraft. 

Navigation sensor availability is specified in terms of the probability of the sensor information 

being available at the beginning of the intended operation. [RTCA DO-247, §5.2.2.3] 

Navigation sensor continuity – The capability of the sensor (comprising all elements generating the 

signal in space and airborne reception) to perform the guidance function without non-scheduled 

interruption during the intended operation. [RTCA DO-247, §5.2.2.2] 

Navigation sensor continuity risk – The probability that the sensor information will be interrupted and 

not provide navigation information over the period of the intended operation. [RTCA DO-247, 

§5.2.2.2] 

Navigation System Integrity – This relates to the trust that can be placed in the correctness of the 

navigation information supplied. Integrity includes the ability to provide timely and valid 

warnings to the user when the navigation system must not be used for navigation.Navigation 

Uncertainty Category (NUC) – 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. (This term was used in DO-242. DO-242A separated 

the integrity and accuracy components of NUC into NIC, NAC, and SIL parameters.) 

Operational Mode Code – A code used to indicate the current operational mode of transmitting ADS-B 

participants. 

©20xx, RTCA, Inc.

Appendix A 

Page A-17 

Own-ship – From the perspective of a flight crew, or of the ASSAP and CDTI functions used by that 

flight crew, the own-ship is the ASA participant (aircraft or vehicle) that carries that flight crew 

and those ASSAP and CDTI functions. 

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. 

Persistent Error – A persistent error is an error that occurs regularly. Such an error may be the absence 

of data or the presentation of data that is false or misleading. An unknown measurement bias 

may, for example, cause a persistent error. 

Positional Uncertainty – Positional uncertainty is a measure of the potential inaccuracy of an aircraft’s 

position-fixing system and, therefore, of ADS-B-based surveillance. Use of the Global 

Positioning System (GPS) reduces positional inaccuracy to small values, especially when the 

system is augmented by either space-based or ground-based subsystems. However, use of GPS as 

the position fixing system for ADS-B cannot be assured, and positional accuracy variations must 

be take into account in the calculation of CDZ and CAZ. When aircraft are in close proximity 

and are using the same position-fixing system, they may be experiencing similar degrees of 

uncertainty. In such a case, accuracy of relative positioning between the two aircraft may be 

considerably better than the absolute positional accuracy of either. If, in the future, the accuracy 

of relative positioning can be assured to the required level, it may be possible to take credit for 

the phenomenon in calculation of separation minima. For example, vertical separation uses this 

principle by using a common barometric altitude datum that is highly accurate only in relative 

terms. 

Primary Surveillance Radar (PSR) – A radar sensor that listens to the echoes of pulses that it transmits 

to illuminate aircraft targets. PSR sensors, in contrast to secondary surveillance radar (SSR) 

sensors, do not depend on the carriage of transponders on board the aircraft targets. 

Proximity Alert – An alert to the flight crew that something is within pre-determined proximity limits 

(e.g., relative range, or relative altitude difference) of own vehicle. 

Range reference – The CDTI feature of displaying range rings or other range markings at specified radii 

from the own-ship symbol. 

Received Update Rate – The sustained rate at which periodic ADS-B messages are successfully 

received, at a specified probability of reception. 

©20xx, RTCA, Inc.

Appendix A 

Page A-18 

Regime – Divisions in the future airspace structure in contrast to the current concept of domains. Based 

on the European concept the three regimes are: 

1. Managed Airspace (MAS) 


� Known traffic environment 

� Route network 2D/3D and free routing 

� Separation responsibility on the ground, but may be delegated to the pilots in defined 

circumstances 

2. Free Flight Airspace (FFAS) – FFAS is also known as Autonomous Airspace. 

� Known traffic environment 

3. Autonomous operations Separation responsibility in the air Unmanaged Airspace 

(UMAS) 

� Unknown traffic environment 

� See [Rules of the air]. 

Registration – The process of aligning measurements from different sensors by removing systematic 

biases. 

Required – The capability denoted as Required is necessary to perform the desired application. 

Resolution – The smallest increment reported in an ADS-B message field. The representation of the least 

significant bit in an ADS-B message field. 

Safe Flight 21 – The Safe Flight 21 Program was a joint government/industry initiative designed to 

demonstrate and validate, in a real-world environment, the capabilities of advanced surveillance 

systems and air traffic procedures. The program is demonstrating nine operational enhancements 

selected by RTCA, and providing the FAA and industry with valuable information needed to 

make decisions about implementing applications that have potential for significant safety, 

efficiency, and capacity benefits. 

Seamless – A “chock-to-chock” continuous and common view of the surveillance situation from the 

perspective of all users. 

Secondary Surveillance Radar (SSR) – A radar sensor that listens to replies sent by transponders 

carried on board airborne targets. SSR sensors, in contrast to primary surveillance radar (PSR) 

sensors, require the aircraft under surveillance to carry a transponder. 

Selected Target – A selected target is a target for which additional information is requested by the flight 

crew. 

Sensor – A measurement device. An air data sensor measures atmospheric pressure and temperature, to 

estimate pressure altitude, and pressure altitude rate, airspeed, etc. A primary surveillance radar 

(PSR) sensor measures its antenna direction and the times of returns of echoes of pulses that it 

transmits to determine the ranges and bearings of airborne targets. A secondary surveillance 

radar (SSR) sensor measures its antenna direction and the times of returns of replies from 

airborne transponders to estimate the ranges and bearings of airborne targets carrying those 

transponders.

Appendix A 

Page A-19 

Separation – Requirements or Separation Standards – The minimum distance between aircraft/vehicles 

allowed by regulations. Spacing requirements vary by various factors, such as radar coverage 

(none, single, composite), flight regime (terminal, en route, oceanic), and flight rules (instrument 

or visual). 

Separation Violation – Violation of appropriate separation requirements. 

Source Integrity Level (SIL) – The Source Integrity Level (SIL) defines the probability of the reported 

horizontal position exceeding the radius of containment defined by the NIC, without alerting, 

assuming no avionics faults. Although the SIL assumes there are no unannunciated faults in the 

avionics system, the SIL must consider the effects of a faulted Signal-in-Space, if a Signal-in- 

Space is used by the position source. The probability of an avionics fault causing the reported 

horizontal position to exceed the radius of containment defined by the NIC, without alerting, is 

covered by the System Design Assurance (SDA) parameter. 

Spacing – A distance maintained from another aircraft for specific operations. 

State (vector) – An aircraft’s current horizontal position, vertical position, horizontal velocity, vertical 

velocity, turn indication, and navigational accuracy and integrity. 

Station-keeping – Station-keeping provides the capability for a pilot to maintain an aircraft’s position 

relative to the designated aircraft. For example, an aircraft taxiing 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. 

Subsystem Availability Risk – The probability, per flight hour, that an ASA subsystem is not available, 

that is, that it is not meeting its functional and performance requirements. 

was operating at the start of the hour or operation, that the subsystem will continue to be available 

through the remainder of the hour or operation. 

System Design Assurance (SDA) – Defines the failure condition that the position transmission chain is 

designed to support. The position transmission chain includes the ADS-B transmission 

equipment, ADS-B processing equipment, position source, and any other equipment that 

processes the position data and position quality metrics that will be transmitted. The supported 

failure condition will indicate the probability of a position transmission chain 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). 

Target Selection – Manual process of flight crew selecting a target. 

Target – Traffic of particular interest to the flight crew. 

Target Altitude – The aircraft’s next intended level flight altitude if in a climb or descent or its current 

intended altitude if commanded to hold altitude. 

Target Heading – The aircraft’s intended heading after turn completion or its current intended heading if 

in straight flight. 

©20xx, RTCA, Inc.

Appendix A 

Page A-20 

Target State Report (TS Report) – An on-condition report specifying short-term intent information. 

Target Track Angle – The aircraft’s intended track angle over the ground after turn completion or its 

current intended track angle if in straight flight. 

TCAS Potential Threat – A traffic target, detected by TCAS equipment on board the own-ship, that has 

passed the Potential Threat classification criteria for a TCAS TA (traffic advisory) and does not 

meet the Threat Classification criteria for a TCAS RA (resolution advisory). ([DO-185A, §1.8) 

(If the ASAS own-ship CDTI display is also used as a TCAS TA display, then information about 

TCAS potential threats will be conveyed to the CDTI, possibly via the ASSAP function.) 

TCAS Proximate Traffic – A traffic target, detected by TCAS equipment on board the own-ship, that is 

within 1200 feet and 6 NM of the own-ship. ([DO-185A]. §1.8) (If the ASAS own-ship CDTI 

display is also used as a TCAS TA display, then information about TCAS proximate traffic 

targets will be conveyed to the CDTI, possibly via the ASSAP function.) 

TCAS-Only Target – A traffic target about which TCAS has provided surveillance information, but 

which the ASSAP function has not correlated with targets from other surveillance sources (such 

as ADS-B, TIS, or TIS-B). 

Time of Applicability – The time that a particular measurement or parameter is (or was) relevant. 

TIS-B – Traffic Information Services – Broadcast (TIS-B) is a function on ground systems that 

broadcasts an ADS-B-like message that includes current position information of aircraft/vehicles 

within its surveillance volume. The aircraft/vehicle position information may be measured by a 

ground surveillance system such as a secondary surveillance radar (SSR) or a multilateration 

system. 

Track – (1) A sequence of reports from the ASSAP function that all pertain to the same traffic target. 

(2) Within the ASSAP function, a sequence of estimates of traffic target state that all pertain to 

the same traffic target. 

Track angle – See ground track angle. 

Track State – The basic kinematic variables that define the state of the aircraft or vehicle of a track, e.g., 

position, velocity, acceleration. 

Traffic – All aircraft/vehicles that are within the operational vicinity of own-ship. 

Traffic Conflict – Predicted converging of aircraft in space and time, which constitutes a violation of a 

given set of separation minima. (ICAO). 

Traffic Display – The Traffic Display is a graphical plan-view (top down) traffic display. The Traffic 

Display may be a stand-alone display or displays (dedicated display(s)) or the CDTI information 

may be present on an existing display(s) (e.g., multi-function display) or an EFB. 

Traffic Display Criteria (TDC) – The surveillance range of ASA will frequently include more traffic 

than is of interest to the flight crew. Displaying too many traffic elements on the Traffic Display 

may result in clutter, and compromise the intended function of the CDTI. To determine the 

traffic of interest to the flight crew, a set of TDC is used to filter the traffic. Criteria generally 

include range and altitude. Additional criteria may also be used. The flight crew may change the 

TDC. 

©20xx, RTCA, Inc.

Appendix A 

Page A-21 

Traffic Information Service – Broadcast – A surveillance service that broadcasts traffic information 

derived from one or more ground surveillance sources to suitably equipped aircraft or surface 

vehicles, with the intention of supporting ASA applications. 

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. 

Traffic symbol – A depiction on the CDTI display of an aircraft or vehicle other than the own-ship. 

Traffic target – This is an aircraft or vehicle under surveillance. In the context of the ASA subsystems at 

a receiving ASA participant, traffic targets are aircraft or vehicles about which information is 

being provided (by ADS-B, TIS-B, TCAS, etc.) to the ASSAP. 

Transmission Rate – The sustained rate at which periodic ADS-B messages are transmitted. 

Transponder – A piece of equipment carried on board an aircraft to support the surveillance of that 

aircraft by secondary surveillance radar sensors. A transponder receives on the 1030 MHz and 

replies on the 1090 MHz downlink frequency. 

Trajectory Uncertainty – Trajectory uncertainty is a measure of predictability of the future trajectory of 

each aircraft. There are a number of factors involved in trajectory predictability. These include 

knowledge of a valid future trajectory, capability of the aircraft to adhere to that trajectory, 

system availability (e.g., ability to maintain its intended trajectory with a system failure in a non 

redundant system versus a triple redundant system), and others. 

Update Interval – The time interval between successful message receipt with a given probability of 

successful reception at a specified range. (Nominal Update Interval is considered 95% 

probability of successful reception at a specified range.) 

Update Rate – The reciprocal of update interval (e.g. if the update interval is 5 s, the update rate = 1/5 ~ 

0.20 Hz for the example above). 

User-Preferred Trajectories (UPT) – A series of one or more waypoints that the crew has determined to 

best satisfy their requirements. 

Velocity – The rate of change of position. Horizontal velocity is the horizontal component of velocity 

and vertical velocity is the vertical component of velocity. In these MASPS, velocity is always 

expressed relative to a frame of reference, such as the WGS-84 ellipsoidVref – The reference 

landing air speed for an aircraft. It is weight dependent. Flight crews may vary their actual 

landing speed based on winds, etc. 

©20xx, RTCA, Inc.

Appendix A 

Page A-22 

DO-3xx 

Reqmts 

Details ? 

Yes (§4.1) 

Yes (§4.1) 

Yes (§4.2) 

Yes (§4.3) 

Future (§4.6) 

Yes (§4.4) 


Proposed 

DO-3xx MASP 

Name 

Enhanced Visual 

Acquisition 

(EVAcq) 

(Part 23 only) 

Basic Airborne 

Situational 

Awareness 

(AIRB) 

Visual Separation 

on Approach 

(VSA) 

Basic Surface 

Situational 

Awarenenss 

(SURF) 

Airport Traffic 

Situational 

Awareness with 

Indications and 

Alerts (SURF - 

IA) 

Oceanic In-Trail 

Procedures (ITP) 

DO-3xx 

Category 

(Tables 2-5 & 

2-7) 

SA Application 




Enhanced SA 

Application 

Enhanced SA 

Application 

ADS-B IN Application Reference Matrix 

DO-289 MASP 

Name 


Acquisition 

(EVAcq) 


Approach 

(EVApp) 

Airport Surface 

Situational 

Awareness 

(ASSA) / 

Final Approach 

Runway 

Occupancy 

Awareness 

(FAROA) 

DO-317A 

MOPS Name 


Acquisition 

(EVAcq) 

Basic Airborne 

Situational 

Awareness 

(AIRB) 

Visual Separation 

on Approach 

(VSA) 

Basic Surface 

Situational 

Awarenenss 

(SURF) 

TSO C-195 

Name 

Airborne 


Approach 

Surface (Runways 

& Taxiways) 

Requirements 

Focus Group 

Name (SPR) 

Enhanced traffic 

situational 

awareness during 

flight operations 

(ATSA-AIRB) 

[DO-319] 

Enhanced visual 

separation on 

approach (ATSA- 

VSA) [DO-314] 


situational 

awareness on the 

airport surface 

(ATSA-SURF) 

[DO-322] 


situational 

awareness on the 

airport surface 

with indications 

and alerts (SURF 

IA) [DO-323] 

In-Trail 

Procedures in 

Oceanic AIrspace 

(ATSA-ITP) 

[DO-312] 

AIWP 2.0 

Name 

(App 1) Traffic 

Situation 

Awareness - 

Basic 


Situation 

Awareness - 

Basic 


Situation 

Awareness for 


(App 3) Airport 

Traffic Situational 

Awareness 

(App 4) Airport 

Traffic Situational 


Indications and 

Alerts 

(App 5) Oceanic 

In-Trail 

Procedures (ITP) 

AIWP 

Category 

Situational 

Awareness 

Situational 

Awareness 

Situational 

Awareness 

Situational 

Awareness 

Situational 


Alerting 

Uncategorized

DO-3xx 

Reqmts 

Details ? 



None 

None 

None 

None 

None 

None 

Proposed 

DO-3xx MASP 

Name 

Flight Deck 

Based Interval 

Management - 

Spacing (FIM-S) 

Traffic Situation 


Alerts (TSAA) 

Flight-Deck 

Based Interval 

Management-with 

Delegated 

Separation (FIM- 

DS) - future rev 

of 3XX 

DO-3xx 

Category 

(Tables 2-5 & 

2-7) 

Spacing 

Application 

(not addressed) 

Enhanced SA 

Application 

Delegated 

Separation 

Delegated 

Separation 

Delegated 

Separation 

Delegated 

Separation 

Delegated 

Separation 

Delegated 

Separation 

DO-289 MASP 

Name 

Approach 

Spacing for 

Instrument 

Approaches 

(ASIA) 

Independent 

Closely Spaced 

Parallel 

Approaches 

(ICSPA) 

DO-317A 

MOPS Name 

TSO C-195 

Name 

Requirements 

Focus Group 

Name (SPR) 

Airborne Spacing 

- Flight Deck 

Interval 

Management - 

Spacing (ASPA- 

FIM) [DO-328] 

AIWP 2.0 

Name 

(App 6) Flight 

Deck Based 

Interval 

Management - 

Spacing (FIM-S) 


Situation 


Alerts (TSAA) 

(App 8) Flight- 

Deck Based 

Interval 

Management-with 

Delegated 

Separation (FIM- 

DS) 

(App 9) 

Independent 


Routes (ICSR) 

(App 10) Paired 


Parallel 

Approaches 

(App 11) 

Independent 


Parallel 

Approaches 

(App 12) 

Delegated 

Separation- 

Crossing 

(App 13) 

Delegated 

Separation- 

Passing 

Appendix A 

Page A-23 

AIWP 

Category 

Airborne Spacing 

Situational 


Alerting 

Delegated 

Separation 

Delegated 

Separation 

Delegated 

Separation 

Delegated 

Separation 

Delegated 

Separation 

Delegated 

Separation 

©20xx, RTCA, Inc.

Appendix A 

Page A-24 

DO-3xx 

Reqmts 

Details ? 

None 


Proposed 

DO-3xx MASP 

Name 

DO-3xx 

Category 

(Tables 2-5 & 

2-7) 

Delegated 

Separation 

None not addressed 

None Self Separation 

None Self Separation 

DO-289 MASP 

Name 

Airborne Conflict 

Management 

(ACM) 

DO-317A 

MOPS Name 

TSO C-195 

Name 

Requirements 

Focus Group 

Name (SPR) 

AIWP 2.0 

Name 

(App 14) Flight 

Deck Interval 

Management - 

Delegated 

Separation with 

Wake Risk 

Management 

(App 15) ADS-B 

Integrated 

Collision 

Avoidance 

(App 16) Flow 

Corridors 

(App 17) Self 

Separation 

AIWP 

Category 

Delegated 

Separation 

Hazard 

Avoidance 

Self Seapration 

Self Separation

Appendix B 

Bibliography and References


B Bibliography and References 

Appendix B 

Page B-1 

[1] ARINC Characteristic 735A/B, Traffic Computer TCAS and ADS-B Functionality, Date: 

12/14/2007, Aeronautical Radio Inc., Annapolis Maryland. 

[2] ARINC Characteristic 743A-5, GNSS Sensor, Date: 5/29/2009, Aeronautical Radio Inc., Annapolis 

Maryland. 

[3] Department of Defense World Geodetic System 1984: Its definition and relationships with local 

geodetic systems, second edition. Defense Mapping Agency Technical Report TR-8350.2, Defense 

Mapping Agency, Fairfax, Virginia, September 1991. 

[4] EUROCAE, Minimum Operational Performance Standards for VDL Mode 4 Aircraft Transceiver, 

ED-108A, Paris France, September 2005. 

[5] EUROCAE, ADS-B Application Interoperability Requirements for VDL Mode 4, ED-156A, Paris, 

France, March 2010. 

[6] FAA, Advisory Circular 20-165, Airworthiness Approval of Automatic Dependent Surveillance - 

Broadcast (ADS-B) Out Systems, Date: 5/21/2010, Washington, DC. 

[7] FAA, Advisory Circular 23.1309-1D, System Safety Analysis and Assessment for Part 23 Airplanes, 

Date: 1/16/2009, Washington, DC. 

[8] FAA, Advisory Circular 25.1309-1A, System Design and Analysis, Date: 6/21/1988, Washington, 

DC. 

[9] FAA, Advisory Circular 29-2C, Certification of Transport Category Rotocraft, Date: 9/30/2008, 

Washington, DC. 

[10] FAA, Technical Standard Order, TSO-C88, Automatic Pressure Altitude Reporting Code 

Generating Equipment, Date: 8/18/83, Washington, DC. 

[11] ICAO, Aeronautical Telecommunications, Annex 10 to the Convention on International Civil 

Aviation, International Civil Aviation Organization, Montreal, Canada. 

[12] ICAO, Manual of ATS Data Link Applications, Part VII - Automatic Dependent Surveillance- 

Broadcast, Document 9694, Montreal, Canada, May 1999. 

[13] RTCA Task Force 3, Final Report of Task Force Three on Free Flight Implementation, 

Washington, DC, October 1995. 

[14] RTCA, Software Considerations in Airborne Systems and Equipment Certification, DO-178B, 

Washington, DC, December 1992. (also see EUROCAE ED-12B) 

© 2011, RTCA, Inc.

Appendix B 

Page B-2 

[15] RTCA, Traffic Alert Collision Avoidance System (TCAS) I Functional Guidelines, 

DO-184, Washington, DC, May 1983. 

[16] RTCA, Minimum Operational Performance Standards for Traffic Alert and Collision Avoidance 

System (TCAS) Airborne Equipment, DO-185A, Volumes I and II, Washington, DC, November, 

1997. 

[17] RTCA, Minimum Operational Performance Standards for Traffic Alert and Collision Avoidance 

System (TCAS) Airborne Equipment, DO-185B, Volumes I and II, Washington, DC, June 2008. 

[18] RTCA, Minimum Operational Performance Standards for Airborne ADS Equipment, 

DO-212, Washington, DC, October 1992. 

[19] RTCA, Aeronautical Spectrum Planning for 1997-2010, DO-237, Washington, DC, January 1997. 

[20] RTCA, Minimum Operational Performance Standards for Global Positioning System/Wide Area 

Augmentation System Airborne Equipment, DO-229D, Washington, DC, December 2006. 

[21] RTCA. Minimum Aviation System Performance Standards: Required Navigation Performance for 

Area Navigation, DO-236A, Washington, DC, September 2000. 

[22] RTCA, Minimum Aviation System Performance Standards for Automatic Dependent Surveillance – 

Broadcast (ADS-B), DO-242, Washington, DC, February 1998. 

[23] RTCA, Minimum Aviation System Performance Standards for Automatic Dependent Surveillance – 

Broadcast (ADS-B), DO-242A, Washington, DC, June 2002. 

[24] RTCA, Guidance for Initial Implementation of Cockpit Display of Traffic Information (CDTI), DO- 

243, Washington, DC, February 1998. 

[25] RTCA, Minimum Aviation System Performance Standards for the Local Area Augmentation System 

(LAAS), DO-245, Washington, DC, September 1998. 

[26] RTCA, GNSS-Based Precision Approach Local Area Augmentation System (LAAS) Signal-in-Space 

Interface Control Document (ICD), DO-246A, Washington, DC, January 2000. 

[27] RTCA, Minimum Operational Performance Standards for GPS Local Area Augmentation System 

Airborne Equipment, DO-253, Washington, DC, January 2000. 

[28] RTCA, Design Assurance Guidance for Airborne Electronic Hardware, DO-254, Washington, DC, 

April 2000. (also see EUROCAE ED-80) 

[29] RTCA, Minimum Operational Performance Standards for the Depiction of Navigation Information 

on Electronic Maps, DO-257A, Washington, DC, June 2003. 

[30] RTCA, Application Descriptions for Initial Cockpit Display of Traffic Information (CDTI) 

Applications, DO-259, Washington, DC, September 2000. 

© 2011, RTCA, Inc.

Appendix B 

Page B-3 

[31] RTCA, Minimum Operational Performance Standards for 1090 MHz Automatic Dependent 

Surveillance – Broadcast (ADS-B), DO-260, Washington, DC, September 2000. (also see 

EUROCAE ED-102) 


Surveillance – Broadcast (ADS-B) and Traffic Information Services – Broadcast (TIS-B), DO- 

260A, Washington, DC, April 2003. 


Surveillance – Broadcast (ADS-B) and Traffic Information Services – Broadcast (TIS-B), DO- 

260B, Washington, DC, December 2009. (also see EUROCAE ED-102A) 

[34] RTCA, Application of Airborne Conflict Management: Detection, Prevention, & Resolution, DO- 

263, Washington, DC, December 2000. 

[35] RTCA, User Requirements for Aerodrome Mapping Information, DO-272C, Washington, DC, 

September 2011. 

[36] RTCA, Minimum Operational Performance Standards for Universal Access Transceiver (UAT) 

Automatic Dependent Surveillance – Broadcast (ADS-B), DO-282, Washington, DC, August 2002. 


Automatic Dependent Surveillance – Broadcast (ADS-B), DO-282A, Washington, DC, July 2004. 


Automatic Dependent Surveillance – Broadcast (ADS-B), DO-282B, Washington, DC, December 

2009. 

[39] RTCA, Minimum Aviation System Performance Standards for Traffic Information Service – 

Broadcast (TIS-B) Data Link Communications, DO-286B, Washington, DC, October 2007. 

[40] RTCA, Minimum Aviation System Performance Standards for Aircraft Surveillance Applications 

(ASA), DO-289, Volumes I and II, Washington, DC, December 2003. 

[41] RTCA, Minimum Operational Performance Standards (MOPS) for Traffic Alert and Collision 

Avoidance System II (TCAS II) Hybrid Surveillance, DO-300, Washington, DC, December 2006. 

[42] RTCA, Safety, Performance and Interoperability Requirements Document for the ADS-B Non- 

Radar-Airspace (NRA) Application, DO-303, Washington, DC, December 2006. 

[43] RTCA, Safety, Performance and Interoperability Requirements Document for the In-Trail 

Procedure in Oceanic Airspace (ATSA-ITP) Application, DO-312, Washington, DC, June 2008. 

(also see EUROCAE ED-159) 

© 2011, RTCA, Inc.

Appendix B 

Page B-4 

[44] RTCA, Safety, Performance and Interoperability Requirements Document for Enhanced Visual 

Separation on Approach (ATSA-VSA), DO-314, Washington, DC, December 2008. (also see 


[45] RTCA, Minimum Operational Performance Standards (MOPS) for Aircraft Surveillance 

Applications System (ASAS), DO-317A, Washington, DC, December 2011. (also see EUROCAE 

ED-194) 

[46] RTCA, Safety, Performance and Interoperability Requirements Document for Enhanced Air Traffic 

Services in Radar-Controlled Areas Using ADS-B Surveillance (ADS-B-RAD), DO-318, 

Washington, DC, September 2009. (also see EUROCAE ED-161) 

[47] RTCA, Safety, Performance and Interoperability Requirements Document for Enhanced Traffic 

Situational Awareness During Flight Operations (ATSA-AIRB), DO-319, Washington, DC, March 

2010. (also see EUROCAE ED-164) 

[48] RTCA, Safety, Performance and Interoperability Requirements Document for ADS-B Airport 

Surface Surveillance Application (ADS-B-APT), DO-321, Washington, DC, December 2010. (also 

see EUROCAE ED-163) 

[49] RTCA, Safety, Performance and Interoperability Requirements Document for ATSA-SURF 

Application, DO-322, Washington, DC, December 2010. (also see EUROCAE ED-165) 

[50] RTCA, Safety, Performance and Interoperability Requirements Document for Enhanced Traffic 

Situational Awareness on the Airport Surface with Indications and Alerts (SURF IA), DO-323, 

Washington, DC, December 2010. 

[51] RTCA, Safety, Performance and Interoperability Requirements Document for Airborne Spacing – 

Flight Deck Interval Management (ASPA-FIM), DO-328, Washington, DC, June 2011. (also see 


[52] 

© 2011, RTCA, Inc.

Appendix C 

Derivation of Link Quality Requirements for Future Applications

C Derivation of Link Quality Requirements for Future Applications 

C.1 Background 

C.2 Link – Physical Quality Parameters 

There are several key physical parameters of a surveillance link which will 

either allow that link to support or limit its utilization for future applications. 

Among them are: RF range coverage, RF coverage vs altitude and effective 

total latency or update rate. 

C.2.1 RF Range Coverage 

In the future as ADS-B In applications are assigned a greater level of 

criticality and integrity it may be necessary to assign a minimum RF range 

coverage requirement (in NM) to the links that support each application. 

The major factors affecting the free space RF range are the effective RF 

transmitted power, the path loss for that frequency or frequencies over the 

minimum required distance, and the receive system minimum sensitivity 

threshold. 

C.2.2 RF Coverage versus Altitude 

The current situational awareness applications do not have minimum RF 

coverage requirements, either for range or by altitude. As for range, future 

higher criticality applications may have minimum requirements for RF 

coverage over a required altitude band. Examples of this would be: 

a)coverage down to touchdown for an approach application such as CEDS 

or: b)coverage over the active airport surface movement area for a surface 

CDTI application such as SURF IA. These requirements could apply to both 

the direct path (air vehicle to air vehicle) as well as to the air – ground path 

if either TIS-B and/or ADS-R data would be required for the application. 

Several proof of concept demonstrations for surface applications have shown 

that careful attention must be paid to the expected RF performance on the 

surface – just because the source and the receiver are “close” to each other 

does not ensure reliable data updates! 

C.2.3 Effective Update Rate 

The effective update rate is the average/mean? elapsed time for 95% of all 

the transmitted messages to be received and decoded. Factors influencing 

this include RF interference, intentional spoofing and jamming. If a 

surveillance message is transmitted every x seconds but only 75% of the 

transmitted messages are successfully received and decoded; it will take

multiple retransmissions for some to be received and the effective update 

rate for that message will be considerably longer than the baseline transmit 

rate of x seconds. 

C.3 Link – Performance Quality Parameters 

C.3.1 Position Accuracy 

The maximum accuracy of a broadcast position data system is limited by the 

resolution of the position data fields. Currently in the 1090ES broadcast link 

the resolution of the airborne position message is around 5 meters at the 

worst case locations. There is a NACp category of 11 which requires 95% 

position accuracy of +/- 3 meters – this position accuracy quality metric 

could not be applied to the current 1090ES airborne targets. While no 

airborne applications have applied a NACp=11 requirement yet, a surface 

application SPR does contain this requirement. (SURF IA/DO-323) The 

current resolution of the 1090ES surface position messages is around 1.5 

meters at the worst case locations. 

C.3.2 Position Integrity 

Refer to Section C.3.7 for a general discussion on data latency which 

includes the position integrity metrics NIC and SIL. 

C.3.3 Velocity Accuracy 

The fundamental limit for the accuracy of broadcast velocity data is the 

resolution of the velocity data fields. Developers of future applications 

utilizing the current ADS-B Message formats should perform a comparison 

between the quality metrics applied and the resolution of each message 

element that those metrics are applied against. There are some combinations 

of message data types and horizontal velocity quality metrics that are not 

compatible. For example, in the 1090ES link, the application of a NACV = 4 

(Velocity accuracy < 0.3 m/s) requirement to the Airborne Velocity Message 

(Register 0916) Subtypes 1 or 3 (subsonic), which has a minimum resolution 

of only 1 knot (~0.5 m/s). Another example would be the application of a 

NACV = 3 (Velocity accuracy < 1 m/s) or NACV = 4 requirement to the 

Airborne Velocity Message Subtypes 2 or 4 (supersonic), which have a 

minimum resolution of 4 knots (~2 m/s).

C.3.4 Altitude Accuracy 

The fundamental limit for the accuracy of broadcast altitude data is the 

resolution of the altitude data fields. Currently in the 1090ES link Version 2 

link standards there are assumed accuracy bounds on the Barometric 

Pressure derived altitude data and a separate accuracy parameter (GVA) for 

GNSS derived geometric altitude data. 

C.3.5 Vertical Rate Accuracy 

The fundamental limit for the accuracy of broadcast vertical rate data is the 

resolution of the vertical rate data fields. Currently there are no published 

requirements for vertical rate accuracy in the existing applications. In the 

1090ES link there are no defined vertical rate accuracy fields in the Version 

2 link standard. 

C.3.6 System Design Assurance (SDA) 

The error checking that is inherent in each surveillance link’s standard (or 

the lack thereof) is an important factor in the highest SDA or System Hazard 

Level that that link can support. For example, a single bit parity checking 

method such as that currently employed by existing ARINC 429 airborne 

data systems may not support as high of level of system hazard level as a 

cyclic redundancy check (CRC) implementation. 

Also the system architecture is a major factor in determining what level of 

SDA in the transmit system and Hazard Level in the receiving system can be 

supported. In general redundant multichannel systems or a single channel 

system with a parallel full time monitor channel can support a higher system 

hazard level function than a single channel system is able to support. 

C.3.7 Data Latency 

The ability of each link to provide timely data updates of not only state data 

such as position/velocity/altitude but also the associated quality metrics for 

this state data must be evaluated and coordinated together. For example, it 

may be of little benefit to future applications if the state data updates are 

provided twice per second but the quality metrics only reflect a change in 

that data every 20 seconds. This would be of most importance for situations 

where one or more targets went from transmitting data compliant to an 

application’s requirements to transmitting non-compliant data for that 

application.

Another aspect of data latency that must be evaluated is related to the 

proposed receive side mitigation techniques for surface applications. These 

are for both shortfalls in broadcast position accuracy (NACp) and velocity 

accuracy (NACv) from existing aircraft that do not meet the surface 

applications’ requirements. For example, they may require observation of 

multiple position messages in order to develop an independent assessment of 

the target’s real time velocity accuracy as opposed to using the target’s 

broadcast NACv value. However there is also a requirement for the receive 

function to deliver real time (low latency) data to the application on each 

target’s quality metrics. Thus – only a finite amount of observation and 

averaging can be performed within the allowable report generation window.

The Page Intentionally Left Blank.

Appendix F 

Track Acquisition and Maintenance Requirements


F Track Acquisition and Maintenance Requirements 

F.1 Introduction 

Appendix F 

Page F-1 

ADS-B surveillance information required to support various operational needs is 

transmitted differently depending on the data link. If information is transmitted using 

different message types, the receive processor must correlate information contained in the 

different message types from different aircraft and associate this information with the 

correct source aircraft. These correlated, time registered data are then provided to the onboard 

user application in the form of ADS-B reports. Depending upon the design, the 

ADS-B receive processor may also support additional functions that are traditionally 

considered to be part of surveillance tracking. The following discussion first reviews the 

familiar role of trackers employed in radar surveillance and then identifies some of the 

ways the ADS-B tracker function differs from radar tracking. ADS-B link reliability 

required to support ADS-B tracking is then discussed in Sections 2, 3, and 4. 

Radar trackers are a familiar part of both skin paint (PSR) and cooperative (SSR) radar 

surveillance systems, but ADS-B report information content and quality of the 

information differs appreciably from the target estimates available from a radar sensor. 

The following discussion identifies some of these differences, discusses the impact of 

these differences in defining ADS-B tracker requirements, and illustrates how trackerrelated 

features influence the determination of acceptable ADS-B link interference limits. 

F.1.1 Radar Trackers 

Radar surveillance systems output position (and sometimes other parameters such as 

altitude and radial-velocity) estimates on each target detected during a beam scan. 

Extraneous detections (clutter in the case of PSR and FRUIT replies in the case of SSR) 

are also output during the beam scan. Trackers are used to suppress these extraneous 

detections while maintaining surveillance on targets of interest. The process of sorting 

out extraneous detections from desired detections is based on the expected behavior or 

scan-to-scan consistency of desired target detections in contrast with the more random 

nature of undesired detections. This sorting, or track acquisition, process requires that at 

least m out of n successive scan detections have some kind of correlation in order to 

initiate a new track. This correlation requirement reduces the probability that extraneous 

detections (false alarms) will be forwarded to displays or surveillance algorithm using 

this data. 

Radar trackers also smooth target position estimates and derive target velocity estimates 

based on successive position estimates. This derived velocity is updated with each 

position estimate and can be used to coast the tracked target through periods of missed 

updates as long as a new update is obtained before the track coast period has exceeded 

some operationally accepted interval. For example, the acceptable coast interval may be 

limited by the required track correlation bin size, or by the time allowed before detection 

of a worst case threat maneuver by a track in the coast state. Coast periods for the 

relatively close TCAS target separations are limited to less than ten seconds; coast 

periods for en route radar traffic environments, on the other hand, are tens of seconds. 

Similar time considerations apply to initial acquisition of pop-up targets or reacquisition 

of dropped tracks. 

© 20xx RTCA, Inc.

Appendix F 

Page F-2 

F.1.2 ADS-B Trackers 

ADS-B surveillance and supporting tracker considerations differ from radar in several 

respects: 

� ADS-B extraneous decodes are produced by undetected message errors; these are 

extremely rare with use of forward error detection codes. All correctly decoded 

ADS-B messages contain valid surveillance related information on some aircraft 

within detection range. 

� ADS-B information exchanges are of three types: 1) State Vector data (SV) which 

are broadcast at a relatively high rate, 2) Mode Status data (MS), and 3) future intent 

data. MS data, or MS and future intent data may be contained in the same message 

as SV data in some designs, or MS and future intent data may be broadcast as 

separate messages at a lower rate. All messages in any design contain the 

transmitting aircraft address. Different operational capabilities require receipt of 

different levels of information. For example, SV data alone aids visual acquisition of 

targets and supports basic conflict avoidances; higher levels of operational capability 

require augmentation of SV data with MS data, or MS and future intent data. 

� Different ADS-B message types from the same aircraft are unambiguously associated 

with the same aircraft track through the above mentioned aircraft address contained 

in each message. Since ADS-B SV messages contain high accuracy velocity data, 

there is no need for tracker derived velocity estimates based on the difference in 

successive position updates. A tracker employing extrapolation, correlation, and 

smoothing is required, however, to reassemble segmented position and velocity SV 

messages if they are used. 

F.1.3 Operational Needs 

© 20xx RTCA, Inc. 

Dynamic considerations associated with following an aircraft maneuver using ADS-B 

based surveillance are similar to those for radar tracking. Certain benefits are, however, 

obtained from the complete target state vector and other operational information provided 

in received ADS-B messages. Acquisition ranges and the information exchange 

requirements for the operational applications of interest are summarized in Table 

3.4.3.3.1.1a. 

Surveillance on target separations out to about 20 nmi may be supported by only the 

position, velocity, and aircraft address information contained in the full state vector (SV) 

message. These tracks, once acquired, may be maintained by reception of at least one 

full SV message update within the permitted track coast interval. An acceptable coast 

interval is somewhat dependent on the operational application supported, but might 

typically be defined as two update opportunity (or broadcast) intervals. IFR traffic 

separation requirements impose the need for information in addition to the SV, such as 

aircraft identification and flight status that is included in the augmenting Partial Mode 

Status (MS-P) message type. Since MS-P information is relatively static and is directly 

associated with SV messages through the common aircraft address, it does not require the 

same broadcast rate as SV messages. Both SV and MS-P messages must be received, 

however, to support this IFR operational need.

F.2 Approach 

F.2.1 Assumptions 

Appendix F 

Page F-3 

Predicting aircraft separations based on SV information alone is limited to the above 

mentioned separations of about 20 NM by false alerts due to aircraft plant noise (normal 

variations in the track angle during flight) and the fact that the aircraft of interest may 

maneuver during the approaching encounter alert interval. Beyond 40 NM, after initial 

SV, MS and future intent data are acquired, a received SV update interval equal to that of 

current en route radars seems adequate at these separations. Permitted coast intervals are 

correspondingly longer. 

As discussed above, while maneuver dynamic data contained in SV messages alone 

support track requirements for separation from nearby aircraft, different operational 

concerns drive requirements for initial acquisition and track of more distant aircraft. In 

the latter case, if the operational application requires a specified alert and response time 

(determined by operational considerations), then the time required to accumulate the 

required SV, MS and future intent information must be added to the operationally 

required alert time when determining the maximum detection range required for the 

supported application. 

Various combinations of ADS-B state vector broadcast update rates, MS and future intent 

broadcast arrangements, and probabilities of correct reception can satisfy the above stated 

track acquisition/reacquisition and track maintenance requirements. The following 

examination determines minimum acceptable values supporting tracker operation. These 

message reception probabilities may limit the effective range of a particular design when 

it operates in a high interference environment. Several design alternatives (representing 

possible random access and TDMA system designs) are shown to illustrate performance 

tradeoffs. It is assumed that all the required information is contained in either a full state 

vector report or in segmented state vector reports. Operations requiring the reassembly of 

augmenting information exchanged in additional message types are then considered. 

The information elements required for various surveillance applications and the coverage 

ranges of interest are summarized in Table 3.4.3.3.1.1a. It has been previously shown 

that required SV update intervals for conflict avoidance is 3 seconds and, optimized 

separation is about 6 seconds. on the basis of acceptable loss in alert time for a specified 

threat target maneuver. From the ADS-B report assembly perspective, we are also 

interested here in 1) how long it takes to acquire the SV and any necessary augmenting 

information for the application of interest, and 2) the probability that the acquired track 

will be dropped if not updated by an SV message within the assumed coast period of two 

report update intervals. Acquisition time requirements for this examination are assumed 

to be 6 seconds at a 99% confidence level for conflict avoidance (this is slightly higher 

than the 95% value given in Table 3.4.3.3.1.1a) and 15 seconds at a 95% confidence level 

for optimized separation. A reasonable value for the acceptable probability of a dropped 

track depends on the operational environment, but is taken here to be 0.01. Only random 

interference is considered. That is, all targets are assumed to be within detection range 

and received messages are above the link fade margin. 

© 20xx RTCA, Inc.

Appendix F 

Page F-4 

F.2.2 Design Alternatives 

F.3 Analysis 

The following analysis determines the lowest acceptable probability of correct message 

decode, Ps, required to meet tracker requirements for the following message broadcast 

design alternatives: 

1. SV messages are segmented with alternate broadcast of position and velocity 

messages at intervals of 0.25 sec between segment transmissions. MS and future 

intent messages are each transmitted in separate messages at intervals of Ts= 5 sec for 

each if either is transmitted alone, or on intervals of 2.5 sec. if both message types are 

required. That is, the interval for both MS and future intent transmissions is 5 sec. 

The net transmission rate for segmented SV, MS, and future intent messages is thus 

4.4 Hz per aircraft supporting applications requiring additional information that is 

conveyed in an additional MS or future intent message. The rate is 4.2 Hz for all 

others broadcasting SV and MS data. These assumptions represent a possible 

random access design. 

2. Full SV data and MS data (partial or full) are combined in one message and broadcast 

at intervals of 1 sec or 3 sec. Separate future intent messages are interleaved with 

these SV/MS messages as needed on a Ts= 6 sec frame interval in these two designs. 

The one second interval represents an alternate random access design. The three 

second interval could be representative of a TDMA design. 

3. Each message contains all SV, MS and future intent data and broadcast at intervals of 

3 sec. This represents an alternate TDMA design. 

F.3.1 Performance with State Vector Only 

Based on TCAS and simulation experience, assume an ADS-B tactical separation track is 

updated at intervals of t sec, and is dropped if an SV update is not received within Td =6 

sec. An ADS-B design with a state vector update interval, t, (t=1/update rate) has 

md=Td/t opportunities to update the track before it is dropped. For at least one success in 

md tries, the probability of maintaining a track during the permitted coast interval is then 

Pd= 1- (1- p) m d ; md= Td/t (3-1) 

where p is the single report probability of correct reception and each try is assumed to be 

independent.� 

Full State Vector 

� The assumption of independence applies for random interference or low S/N considerations. Link fading 

must be treated separately. 

© 20xx RTCA, Inc.

Appendix F 

Page F-5 

Because an ADS-B report provides full dynamic information on the aircraft of interest, a 

single full SV message is adequate for SV data acquisition. Track acquisition or 

reacquisition within some fraction, �, of the coast period requires at least one out of m 

full state vector updates. The probability of acquisition is thus given by 

Pacq= 1-(1-p) m (3-2) 

where m= �Td/t. When �= 1, m= md. 

Segmented State Vector 

Acquisition of segmented state vector reports is a little different. In this case, both the 

position report segment and the velocity report segment must be received and correlated 

to initiate track. For interleaved segmented reports and the same broadcast rate, 

Pacq= [1-(1-p) m/2 ] 2 (3-3) 

since both segments must be received and each segment is transmitted only m/2 times in 

the permitted acquisition interval. 

Minimum Acceptable Decode Probabilities 

Equation (3-2) and (3-3) show the probability of receiving at least one full state vector 

update out of m opportunities to receive an update as a function of the single try 

probability of receiving an update, p. If, as in equation (3-1), m= md, then (3-2) and (3-3) 

give the probability of maintaining a track requiring an SV update within Td=mdt 

seconds. With a little manipulation, (3-2) may be rewritten as: 

Pf= 1- q 1/m d (3-4) 

where q=1-Pacq and is the probability the track is dropped if not updated within Td sec. 

The single report probability p=Pf, is the minimum probability supporting an acceptable 

probability of track loss, q with a full SV broadcast every t sec. 

Now consider a segmented SV design alternately transmitting position and velocity 

messages at a rate of n segments in t seconds. The probability of a full SV update in t 

seconds is then given by (3-3) where m=n. An update capability equivalent to that of the 

full SV design within Tf=mdt sec may then be determined by setting this value equal to Pf 

in (3-4) and solving for the required probability of decoding each of the segmented SV 

messages, Ps. The resulting minimum value for segmented SV messages is 

Ps= 1- 1 � 1 � q 1/m d � 

2/ 

� n 

(3-5) 

© 20xx RTCA, Inc.

Appendix F 

Page F-6 

F.3.2 Performance with Augmenting Messages 


Acquisition requirements for more distant aircraft that are not in immediate conflict may, 

as discussed above, be stated in terms of being (say) 95% confident of acquisition of the 

required information elements by the time the aircraft is within the required surveillance 

range. If Pacq is the probability of SV acquisition in an interval, �Td, and initial 

acquisition is required within a time, Tacq, we may approximate the cumulative 

probability of State Vector information acquisition by assuming Tacq to contain h 

acquisition cells �Td long. Thus, h= Tacq/(��Td), and the cumulative probability of SV 

acquisition within a time, Tacq, is 

Pcum= 1-(1- Pacq) h (3-6) 

where Pacq is again given by (3-2) for full state vector reports, and (3-3) for segmented 

reports. 

Since separation assurance applications require SV+MS data, and since applications at 

longer ranges may require future intent as well as MS+SV information, track acquisition 

is not achieved in these cases until the augmenting message(s) is/are also received. 

Augmenting information may be exchanged in two ways: 

� Include MS and future intent data along with SV data in a single message broadcast 

at a rate 1/t 

� Augment SV data (broadcast at a rate 1/t) with separate MS and future intent 

messages interleaved with SV messages at a lower rate (1/Ts), for example once 

every five or six seconds. 

In the first case where a single message contains SV, MS and future intent information, 

extended range initial acquisition is also given by (3-6). The second case may be 

implemented in any of a number of different ways. To illustrate, consider the design 

based on segmented SV messages broadcast at an average 0.25 sec interval between SV 

segments, and with MS and future intent messages interleaved on a Ts= 5 sec average 

frame time as needed. The cumulative probability of acquiring SV+MS information 

within T= h x 5 sec is then 

PCSM = [1-(1-Psv) h ] [1-(1-p) h ] (3-7) 

where Psv is the probability of acquiring SV data within 5 sec given by (3-3) as 

Psv= [1-(1-p) 10 ] 2 (3-8) 

and the second term in (3-7) is the probability of receiving the MS message within a 

period of h x 5 sec. If MS and future intent data are contained in separate interleaved 

messages, then the [1-(1-p) h ] term in (3-7) is squared to account for the joint probability 

of receiving both MS and future intent as well as SV messages within T= h x 5 sec.

F.4 Results and Discussion 

Appendix F 

Page F-7 

Equations (3-2) and (3-3) are plotted in Figure F-1 for the segmented SV design with an 

update interval, ts= 0.25 sec, and for full SV designs with update intervals tf= 3 sec and 

1 sec. As a matter of interest, a full SV design with tf= 0.5 sec is also shown for 

comparison with ts= 0.25 sec segmented SV design. Each curve shows the probability of 

obtaining at least one SV update within 3 sec as a function of the single message 

probability of correct decode, p. These values correspond to the requirements for a basic 

conflict avoidance capability operating without required IFR augmenting information. 

As discussed above, the minimum required probabilities of message decode may also be 

related to operational needs by examining the single message decode probability required 

to assure that 99% of the tracks are updated within the specified coast interval of twice 

the operationally required update interval. Figure F-2 shows this minimum acceptable 

value dependence on 2x update interval for the above designs (equations 3-4, and 3-5). 

Here, as expected, each design accommodates some decrease in the required minimum 

value of p for SV or segmented SV messages as the permitted update interval increases. 

These acceptable p values, however, only apply in cases where all the operationally 

required information is contained in a single message type. If different message types are 

used, at least one message of each required type must be decoded for acquisition. 

© 20xx RTCA, Inc.

Appendix F 

Page F-8 


1 

0.9 

0.8 

0.7 

0.6 

0.5 

0.4 

0.3 

t f = 0.5s 

t s = 0.25s 

t f = 1s t f = 3s 

0.2 

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 

Probability of Single Message Reception (p) 

Figure F-1: Probability of Update Within 3 Sec Interval vs. Single Message 

Reception Probability for Several Broadcast Intervals

0.9 

0.8 

0.7 

0.6 

0.5 

0.4 

0.3 

0.2 

0.1 

0 

Conflict 

Avoidance 

t s = .025s 

t f =0.5s 

Opt imized 

Separat ion 

t f =1s 

Appendix F 

Page F-9 

5 10 15 20 25 

2 x Update Interval (sec) 

t f =3s 

Airspace 

Deconflict ion 

Figure F-2: Required Probability of Message Decode vs. Twice the Required Update 

Interval for 99% Confidence Track is Updated Within Twice the Update Interval 

© 20xx RTCA, Inc.

Appendix F 

Page F-10 


1 

0.9 

0.8 

0.7 

0.6 

0.5 

0.4 

0.3 

SC+MS 

(p=0.39) 

SC+MS 

(p=0.25) 

0.2 

0 10 20 30 40 50 60 70 80 90 100 

tas(k) 

SC+MS+OC 

(p=0.17) 

Acquisition Time (sec) 

Figure F-3: Probability of Acquiring Multiple Message Types for Segmented State 

Vector Design with ts=0.25s and Augmenting Messages Interleaved on a Ts= 5 sec Basis

F.5 Summary 

Appendix F 

Page F-11 

Although the minimum acceptable probabilities of decode, p, given in Figure F-2 show 

what is required to support SV track maintenance requirements for conflict avoidance 

update intervals of 3 seconds, ADS-B Separation update intervals of 6 seconds, and 

longer range update intervals of 12 seconds, all surveillance services except basic conflict 

avoidance require augmenting the SV update data with MS-P, MS or future intent type 

information. Figure F-3 illustrates how low values of p, which are acceptable interims of 

the SV update requirements alone, limit the acquisition process when multiple message 

types must be received in order to aggregate all the associated surveillance and intent 

information required for potential longer range applications. This figure is plotted for the 

segmented SV design and shows the probability of acquiring the full state vector, SV, as 

well as the required augmenting messages within the indicated acquisition time. Here we 

note that although p= 0.17 supports the 24 sec coast time of Figure F-2, the time to 

acquire the needed SV, MS and future intent data with this value of p is 95 seconds at a 

95% confidence level. Either the system detection range must be adequate to support this 

long acquisition time, or operations must be limited to conditions where a higher level of 

p is obtained in order to acquire all required data within a shorter time say, 30 seconds. 

The other two curves on Figure F-3 show similar problems for the other operational 

services of interest: conflict avoidance, and optimal separation 

Figure F-4 shows the same acquisition time relationship for the two designs combining 

SV and MS into one SV/MS message and augmenting this with an interleaved future 

intent message at Ts= 6 sec as needed. In this case the p= 0.44 value required for tf= 3 

sec track update also supports acquisition of future intent data within 30 seconds at a 95% 

confidence level. However, the lower value of p= 0.18 for the tf= 1 sec design 

(acceptable for SV/MS update requirements) leads to long delays in future intent data 

acquisition 

Table F-1 summarizes these results by comparing minimum acceptable p values 

determined only by SV track update requirements, with corresponding values derived on 

the basis that the augmenting MS and future intent message acquisition times are the 

determining factors. The table is based on the assumed requirements of a 6 sec 

acquisition time for conflict avoidance, a 15 sec MS acquisition time for ADS-B 

optimum separation, and a 30 sec MS and future intent acquisition time for longer range 

applications. As an illustration, at a 1200 kt closure rate, a 30 sec acquisition time adds 

10 nmi to the required coverage in order to meet the desired alert time. 

Inspection of Table F-1 shows that, using the assumed acquisition times and MS and 

future intent message transmission periods, augmenting message acquisition 

considerations are more demanding than track maintenance requirements for the 

segmented SV (t= 0.25 sec) design. This is also true for longer range applications with 

the SV/MS (t= 1 sec) design. Several possibilities may be considered in these cases: 

1. Detection ranges may be extended to accommodate the long acquisition times. 

2. The design SV and MS and future intent interleave rates may be changed. 

3. Support of the intended operational capability may be restricted to low interference 

environments where higher values of p can be achieved. 

© 20xx RTCA, Inc.

Appendix F 

Page F-12 

1 

0.9 

0.8 

0.7 

0.6 

0.5 

0.4 

0.3 

0.2 

SV/MS+OC 

(t f=3s,p=0.44) 

0 10 20 30 40 50 60 

Aquisition Time (sec) 

SV/MS+OC 

(t f=1s,p=0.18) 

Figure F-4: Probability of Acquiring Augmenting Message for Full State Vector Plus Mode 

Status Design for tf=3 sec and 1 sec with Augmenting Message Interleaved on a Ts= 6 sec 

Basis 

© 20xx RTCA, Inc.

Design 

Alternative 

Segmented 

SV 

t= 0.25 sec 

Ts= 5 sec 

SV/MS 

t= 1 sec 

Ts= 6 sec 

SV/MS 

t= 3 sec 

Ts= 6 sec 

SV/MS/ 

future 

intent 

t= 3 sec 

Appendix F 

Page F-13 

Table F-1: Summary of Message Probabilities of Correct Decode Required 

for Each Design Alternative in Support of Desired Operational Capabilities 

Short RangeTd= 

6 sec (99%) 

Tacq= 6 sec (99%) 

SV or SV/MS 

for Td 

Notes: 

0.39 

0.53 

0.9 

Medium RangeTd= 12 sec 

(99%) 

Tacq= 15 sec (95%) 

SV or SV/MS 

only for Td 

0.25 

(note 1) 

0.32 

0.69 

SV+MS 

for Tacq 

0.63 

n/a 

n/a 

Potential Longer Range 

Application 

Td= 24 sec (99%) 

Tacq= 30 sec (95%) 

SV or SV/MS 

only for Td 

0.17 

(note 1) 

0.18 

(note 1) 

0.44 

(note 1) 

SV+MS 

and future 

intent 

for Tacq 

0.46 

0.45 

0.46 

0.9 0.69 n/a 0.44 n/a 

1. These values only support an indication of target presence. They will not support the 

intended application. 

2. n/a indicates service requirement determined by Td requirement. 

In summary, for any design, final system requirements must reflect the most demanding 

requirement determined by track maintenance, track acquisition time, and lost alert time 

considerations. 

© 20xx RTCA, Inc.

Appendix F 

Page F-14 



Appendix G 

Future Air-Referenced Velocity (ARV) Broadcast Conditions


G Future Air-Referenced Velocity (ARV) Broadcast Conditions 

G.1 Background 

Appendix G 

Page G-1 

In this version of these MASPS (RTCA DO-3xx), there are no conditions that require the 

transmission of air-referenced velocity data (heading and airspeed). There is optional 

transmission of ARV data in the event of loss of ground velocity to maintain tracks when 

ground data is lost. However, there are other future applications that could make use of 

ARV reports. Among those applications: 

� Collision Avoidance and Separation Assurance and Sequencing: ARV data can be 

used to improve accuracy of conflict detection, prevention, and resolution routines 

when the transmitting aircraft is being controlled to either an air-referenced or a 

ground referenced velocity. 

� For Interval Management and other future spacing applications, ARV data enables 

near real-time wind estimation and provides improved situation awareness for trailing 

aircraft. 

� ARV data, allowing wind direction and speed estimates, provides improved real-time 

information for Ground ATC automation functions and supports improved weather 

monitoring. 

G.2 Applications Benefited by ARV data 

G.2.1 Collision Avoidance and Separation Assurance and Sequencing 

G.2.1.1 Operational Scenarios 

ADS-B receiving aircraft or ground stations can use ARV along with the ground track 

and ground speed (available through the state vector) to approximate wind information 

encountered by a transmitting aircraft. Consideration of winds should improve the 

performance of conflict detection, prevention, and resolution routines in cases where the 

transmitting aircraft is flown in a heading-referenced flight mode, or when the predicted 

flight path encounters changes in along-track winds. Operational examples include 

heading select and heading hold modes often used while being vectored by air traffic 

control or deviating around hazardous weather. Figure G-1 shows the effect of wind on 

an aircraft’s ground track when turning from a northerly to westerly heading in the 

presence of a 30-knot wind from the south. The ground track is extended for two minutes 

after turn completion. Throughout the scenario, the aircraft flies at a constant true 

airspeed of 250 knots and maintains a constant bank angle corresponding to a standard 

rate turn (360 degrees in four minutes). For comparison, the no-wind ground track is also 

shown. 

© 20xx, RTCA, Inc.

Appendix G 

Page G-2 

North Position (NM) 


Constant 250 Knot True Airspeed and 30 Knot Wind from South 

Constant Bank Angle Corresponding to 4 Minute Standard Rate Turn 

-9 -7 -5 -3 

4.5 

4 

3.5 

3 

2.5 

2 

1.5 

1 

0.5 

0 

-1 1 3 

East Position (NM) 

Figure G-1: Wind Effects on Heading-Referenced Flight Modes 

Wind 

No Wind 

In the wind condition, the aircraft completes the turn a half-mile north of the no-wind 

case. After flying in the crosswind for two minutes, the aircraft has drifted an additional 

mile to the north. The combination of these wind errors could affect the accuracy of 

predicted conflicts. Although this example assumes a simplified constant bank angle 

turn, the wind effects are apparent nonetheless. 

Consider a second example of two aircraft engaged in an air-air separation assurance 

application. In Figure G-2, an aircraft operating in a heading hold mode is flying 3000 

feet below another aircraft flying a defined ground track angle. The lower aircraft begins 

a constant 1500 ft/min climb and encounters a left crosswind that is 30 knots greater at 

the higher aircraft’s altitude. This scenario is designed to represent the common 

occurrence of changing wind conditions with altitude. Each aircraft can combine the 

other aircraft’s air and ground-referenced velocity vectors to approximate the wind 

encountered by that aircraft. Assuming each aircraft knows its own wind conditions, the 

wind differential encountered by the climbing aircraft can be approximated by a ramp 

function. Figure G-2 shows the ground track of the climbing aircraft in the presence of 

the ramp wind. The crosswind causes the climbing aircraft to drift a half-mile during the 

climb. If the climbing aircraft in this example were to encounter a changing headwind or 

tailwind component, the availability of ARV information would also enable a more 

accurate location and time prediction of the point in which it climbs through the other 

aircraft’s altitude.

Relative Altitude (ft) 

3000 

2500 

2000 

1500 

1000 

500 

0 

Cross Wind Increases 10 Knots / 1000 Ft 

0 0.1 0.2 0.3 0.4 0.5 

Cross Track Position (NM) 

Figure G-2: Drift Due to Ramp Cross Wind 

Appendix G 

Page G-3 

Wind 

No Wind 

ARV broadcast while operating in comparable scenarios may be beneficial. Certain 

addressed datalink systems allow some aircraft to provide ground stations with current 

wind conditions [1]. Under this concept, ground-based command and control systems 

process incoming wind data and make them available to participating aircraft. However, 

ADS-B may enable more current and localized wind approximation for aircraft engaged 

in paired applications. ARV information is expected to be particularly beneficial when 

aircraft are operating in heading-referenced flight modes. It may also lead to improved 

predictions for fly-by turn segments. In normal conditions, winds do not affect aircraft 

predictions when flying straight and level ground-referenced legs. 

Controllers may also benefit from ARV information when providing radar vectors and 

speed commands to sequence aircraft in the terminal area. Due to the inability of some 

aircraft to determine ground track and ground speed, controllers issue these commands in 

the form of magnetic heading and indicated airspeed. Controllers must anticipate the 

heading and airspeed targets needed in order to produce the desired ground track. This 

process often requires the controller to verify current heading and airspeed over the radio. 

After issuing vectors and speed commands, controllers have no direct way to ensure 

compliance. Direct broadcast of ARV information would enable more accurate control 

and would likely make this process easier [2]. 

G.2.1.2 Possible ARV Broadcast Conditions 

In order to improve the accuracy of conflict detection, prevention, and resolution 

routines, ARV information should be broadcast at a rate sufficient to derive wind 

estimates for the ADS-B transmitting aircraft 

In order to support air traffic control use of radar vectors and speed commands, the 

following ARV broadcast condition may be needed: 

© 20xx, RTCA, Inc.

Appendix G 

Page G-4 

ARV information should be broadcast at a rate consistent with that for ADS-B state 

vectors when engaged in identified terminal operations such as approach transition, as 

indicated by an appropriate ADS-B air-ground service level or as identified by other 

means such as pilot input. The ARV information should continue to be broadcast until an 

appropriate signal or condition occurs that signifies that the information is no longer 

needed (such as arrival at the Outer Marker). 

G.2.2 Spacing Applications 

G.2.2.1 Operational Scenario 

Spacing applications may also benefit from ARV information. Accurate wind 

information, potentially derived from ARV, is essential for establishing proper spacing 

intervals. Current airspeed information could also enhance situation awareness for 

trailing aircraft. One proposed spacing concept attempts to achieve a constant thresholdcrossing 

interval for a stream of landing traffic. Prior to reaching the final approach fix, 

the trailing aircraft is required to maintain a specified time spacing behind the lead 

aircraft, consistent with safety. The time spacing is based on the difference in final 

approach speeds between the lead and trailing aircraft after passing the final approach fix 

(when the aircraft is configured for landing) and the current wind conditions 

ARV information notifies the trailing aircraft to speed changes initiated by the lead 

aircraft. These speed changes could be part of ATC clearances or associated with 

unplanned speed reductions (e.g., for required arrival timing). Situation awareness 

resulting from ARV information should enable trailing aircraft flight crews to take 

necessary actions to prevent separation loss. 

ARV broadcasts enable wind estimation. Wind affects the amount of time in which the 

differences in final approach speeds act to close or stretch the gap between aircraft after 

passing the final approach fix. For example, a strong headwind would leave more time 

for a faster trailing aircraft to close the gap between a slower lead aircraft. Inaccurate 

wind information will lead to greater variability in threshold crossing time, thereby 

reducing efficiency. 

G.2.2.2 Possible ARV Broadcast Condition 

In order to support in-trail spacing applications and to provide appropriate situation 

awareness information to aircraft in an arrival stream, the following ARV broadcast 

condition may be needed: 

ARV information should be broadcast at a rate consistent with that for ADS-B 

state vectors when engaged in certain in-trail separation applications as indicated 

by an appropriate ADS-B service level or by other means such as pilot input. 

The ARV information should continue to be broadcast until an appropriate signal 

or condition occurs that signifies the end of the separation application. 


G.2.2.3 Air Referenced Velocity Acquisition, Update Interval and Acquisition Range 

Appendix G 

Page G-5 

Air referenced velocity (ARV) proposed update periods and acquisition range 

requirements are summarized in Table G.2.2.3a. These requirements are specified in 

terms of acquisition range and required update interval to be achieved by at least 95% of 

the observable user population (radio line of sight) supporting ARV on-condition reports 

within the specified acquisition range or time interval. 







minutes in advance of a predicted time for closest point of approach. This 

assumes that the target aircraft will have been transmitting ADS-B for some 

minutes prior to the needed acquisition time and are within line-on-sight of the 

receiving aircraft. 

Table G.2.2.3a: Summary of Air Referenced Velocity Report Acquisition Range and 

Update Interval Requirements 

Operational Domain � Terminal, En Route, and Oceanic / Remote Non-Radar � 

Applicable Range � R � 10 NM 10 NM < R � 20 NM 20 NM < R � 40 NM 40 NM < R � 90 NM 

Equipage Class � A1 required A1 required A2 required A3 required 

ARV Acquisition 

Range 

ARV Nominal Update 

Period (95%) when 

ground referenced 

velocity data not 

available 

NA 

(see note) 

20 NM 40 NM 90 NM 

5 s 7 s 12 s 12 s 

Note: This row is meant to specify the minimum acquisition ranges for all class A 

equipage classes. Since A1, A2, and A3 equipment all have minimum acquisition 

ranges greater than 0 NM, no requirement is specified in this cell. 

The following update rates apply when an ARV report is required: 

a. The ARV report’s nominal update interval should be 5 seconds for A1, A2, and 

A3 equipment at ranges of 10 NM and closer. 

b. The ARV report’s nominal update interval should be 7 seconds for A1, A2, and 

A3 equipment at ranges greater than 10 NM and less than or equal to 20 NM. 

c. The ARV report’s nominal update interval should be 12 seconds for A2 

equipment at ranges greater than 20 NM and less than or equal to 40 NM. 

d. The ARV report’s nominal update interval should be 12 seconds for A3 

equipment at ranges greater than 40 NM and less than or equal to 90 NM. 

© 20xx, RTCA, Inc.

Appendix G 

Page G-6 


The ARV report acquisition range in the forward direction should be: 

a. 20 NM for equipage class A1, 

b. 40 NM for equipage class A2, and 

c. 90 NM for equipage class A3. 

The acquisition range requirements in directions other than forward should be consistent 

with those stated in Note 3 of Table 3.4.3.3.1.1a. 

For air-to-air use of ARV to potentially support spacing applications, the received update 

rates for wind speed and direction broadcasts are a 15 second 95% update interval for 

lead-trail aircraft distances less than 10 NM, and a 30 second 95% update interval for 

nearby aircraft less than 20 NM away. 

G.3 Summary 

ARV information is likely to be most beneficial to equipped aircraft engaged in certain 

applications, such as those described above. Further application usages of ARV 

broadcasts may be identified in future MASPS revisions. Periodic low-rate ARV 

broadcast may also enable coarse wind predictions that can be used to improve back-up 

surveillance necessitated by the loss of ground track or ground speed information. 

Further research done on potential benefits of ARV information and the required update 

rates and conditions needed to achieve those benefits could lead to ARV reporting 

requirements in future MASPS. 

References 

[1] “Minimum Interoperability Standards (MIS) for Automated Meteorological Transmission 

(AUTOMET),” RTCA, DO-252, Washington, 2000. 

[2] Rose, A., “The Airborne Impact of Mode S Enhanced Surveillance and Down-linked Aircraft 

Parameters,” Eurocontrol, SUR3.82.ST03.2150, Nov. 1999, p. 24.

Minimum Aviation System Performance Standards for Aircraft ...

Create successful ePaper yourself

Delete template?

Save as template?