Technical Provisions for Mode S Services and Extended Squitter
Technical Provisions for Mode S Services and Extended Squitter
Technical Provisions for Mode S Services and Extended Squitter
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Doc 9871<br />
AN/460<br />
<strong>Technical</strong> <strong>Provisions</strong><br />
<strong>for</strong> <strong>Mode</strong> S <strong>Services</strong><br />
<strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
________________________________<br />
DRAFT <strong>for</strong> TSG – Paris June 2011<br />
Draft<br />
Approved by the Secretary General<br />
<strong>and</strong> published under his authority<br />
First Second Edition — 200920xx<br />
International Civil Aviation Organization<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Published in separate English, French, Russian <strong>and</strong> Spanish editions by the<br />
INTERNATIONAL CIVIL AVIATION ORGANIZATION<br />
999 University Street, Montréal, Quebec, Canada H3C 5H7<br />
For ordering in<strong>for</strong>mation <strong>and</strong> <strong>for</strong> a complete listing of sales agents<br />
<strong>and</strong> booksellers, please go to the ICAO website at www.icao.int<br />
First Second edition 200920xx<br />
ICAO Doc 9871, <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Order Number: 9871<br />
ISBN 978-92-9231-117-9<br />
© ICAO 200920xx<br />
Draft<br />
All rights reserved. No part of this publication may be reproduced, stored in a<br />
retrieval system or transmitted in any <strong>for</strong>m or by any means, without prior<br />
permission in writing from the International Civil Aviation Organization.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
AMENDMENTS<br />
Amendments are announced in the supplements to the Catalogue of ICAO<br />
Publications; the Catalogue <strong>and</strong> its supplements are available on the ICAO<br />
website at www.icao.int. The space below is provided to keep a record of such<br />
amendments.<br />
RECORD OF AMENDMENTS AND CORRIGENDA<br />
AMENDMENTS CORRIGENDA<br />
No. Date Entered by No. Date Entered by<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
FOREWORD<br />
The purpose of this manual is to specify technical provisions <strong>for</strong> the <strong>for</strong>mats <strong>and</strong> associated protocols used in<br />
<strong>Mode</strong> S services <strong>and</strong> extended squitter. These detailed technical provisions supplement requirements contained in<br />
Annex 10 — Aeronautical Telecommunications, Volume III (Part I — Digital Data Communication Systems), <strong>and</strong><br />
Volume IV — Surveillance Radar <strong>and</strong> Collision Avoidance Systems, <strong>and</strong> are necessary to ensure global interoperability.<br />
The manual also includes implementation guidelines as well as in<strong>for</strong>mation on future <strong>Mode</strong> S <strong>and</strong> extended squitter<br />
services that are under development.<br />
The provision of <strong>Mode</strong> S services, specified in this document, include the following:<br />
a) data <strong>for</strong>mats <strong>for</strong> transponder registers;<br />
b) <strong>for</strong>mats <strong>for</strong> <strong>Mode</strong> S specific protocols:<br />
traffic in<strong>for</strong>mation broadcast; <strong>and</strong><br />
dataflash;<br />
c) <strong>Mode</strong> S broadcast protocols, including:<br />
1) uplink broadcast; <strong>and</strong><br />
2) downlink broadcast.<br />
Formats <strong>and</strong> protocols <strong>for</strong> extended squitter automatic dependent surveillance — broadcast (ADS-B) messages are also<br />
included since registers are defined <strong>for</strong> each of these messages. Those registers are assigned so that the extended<br />
squitter messages can be read out on dem<strong>and</strong> by a ground interrogator, in addition to being delivered via an ADS-B<br />
message.<br />
The second edition of this manual introduces a new version of extended squitter <strong>for</strong>mats <strong>and</strong> protocols (Version 2). The<br />
first edition of this manual specified earlier versions of extended squitter messages (versions 0 <strong>and</strong> 1). Version 2<br />
<strong>for</strong>mats <strong>and</strong> protocols were developed to enhance integrity <strong>and</strong> accuracy reporting. To support identified operational<br />
needs <strong>for</strong> the use of ADS-B not covered by Version 1, a number of additional parameters are included in Version 2.<br />
Additionally, several parameters are modified <strong>and</strong> a number of parameters no longer required to support ADS-B<br />
applications are removed.<br />
Draft<br />
The manual also includes implementation guidelines as well as in<strong>for</strong>mation on future <strong>Mode</strong> S services that are under<br />
development.<br />
This manual has been developed by the Aeronautical Surveillance Panel (ASP). Comments on this manual from States<br />
<strong>and</strong> other parties outside ICAO would be appreciated. Comments should be addressed to:<br />
The Secretary General<br />
International Civil Aviation Organization<br />
999 University Street<br />
Montreal, Quebec<br />
Canada H3C 5H7<br />
_____________________<br />
(v)<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
TABLE OF CONTENTS<br />
Glossary ................................................................................................................................................................. (ix)<br />
Acronyms ............................................................................................................................................................... (xiii)<br />
Chapter 1. Introduction ........................................................................................................................................ 1-1<br />
Chapter 2. Overview of <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong> Version 0 ....................................................... 2-1<br />
Chapter 3. Overview of <strong>Extended</strong> <strong>Squitter</strong> Version 1 .......................................................................................... 3-1<br />
Chapter 4. Overview of <strong>Extended</strong> <strong>Squitter</strong> Version 2 ......................................................................................... 4-1<br />
Appendix A. Data/message <strong>for</strong>mats <strong>and</strong> control parameters <strong>for</strong> <strong>Mode</strong> S Specific <strong>Services</strong> <strong>and</strong><br />
<strong>Extended</strong> <strong>Squitter</strong> Version 0......................................................................................................... A-1<br />
Appendix B. <strong>Provisions</strong> <strong>for</strong> <strong>Extended</strong> <strong>Squitter</strong> Version 1 .................................................................................. B-1<br />
Appendix C. <strong>Provisions</strong> <strong>for</strong> <strong>Extended</strong> <strong>Squitter</strong> Version 2................................................................................. C-1<br />
Appendix CD. Implementation guidelines......................................................................................................... CD-1<br />
Appendix DE. <strong>Services</strong> under development ..................................................................................................... DE-1<br />
Draft<br />
_____________________<br />
(vii)<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Page
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
GLOSSARY<br />
Aircraft. The term aircraft may be used to refer to <strong>Mode</strong> S emitters (e.g. aircraft/vehicles), where appropriate.<br />
Aircraft address. A unique combination of 24 bits available <strong>for</strong> assignment to an aircraft <strong>for</strong> the purpose of air-ground<br />
communications, navigation <strong>and</strong> surveillance.<br />
Aircraft data link processor (ADLP). An aircraft-resident processor that is specific to a particular air-ground data link<br />
(e.g. <strong>Mode</strong> S) <strong>and</strong> which provides channel management, <strong>and</strong> segments <strong>and</strong>/or reassembles messages <strong>for</strong> transfer.<br />
It is connected on one side to aircraft elements common to all data link systems <strong>and</strong> on the other side to the airground<br />
link itself.<br />
Aircraft/Vehicle. May be used to describe either a machine or device capable of atmospheric flight, or a vehicle on the<br />
airport surface movement area (i.e. runways <strong>and</strong> taxiways).<br />
Air-initiated Comm-B (AICB) protocol. A procedure initiated by a <strong>Mode</strong> S aircraft installation <strong>for</strong> delivering a Comm-B<br />
message to the ground.<br />
Automatic dependent surveillance — broadcast (ADS-B) IN. A function that receives surveillance data from ADS-B<br />
OUT data sources.<br />
Automatic dependent surveillance — broadcast (ADS-B) OUT. A function on an aircraft or vehicle that periodically<br />
broadcasts its state vector (position <strong>and</strong> velocity) <strong>and</strong> other in<strong>for</strong>mation derived from on-board systems in a <strong>for</strong>mat<br />
suitable <strong>for</strong> ADS-B IN capable receivers.<br />
Automatic dependent surveillance — rebroadcast (ADS-R). The rebroadcast by a ground station of surveillance<br />
in<strong>for</strong>mation received via one ADS-B link over an alternative ADS-B link providing interoperability in airspace where<br />
multiple different ADS-B data links are operating.<br />
Draft<br />
BDS Comm-B Data Selector. The 8-bit BDS code determines the transponder register whose contents are to be<br />
transferred in the MB field of a Comm-B reply. It is expressed in two groups of 4 bits each, BDS1 (most significant 4<br />
bits) <strong>and</strong> BDS2 (least significant 4 bits).<br />
Broadcast. The protocol within the <strong>Mode</strong> S system that permits uplink messages to be sent to all aircraft in the<br />
coverage area, <strong>and</strong> downlink messages to be made available to all interrogators that have the aircraft wishing to<br />
send the message under surveillance.<br />
Capability Report. In<strong>for</strong>mation identifying whether the transponder has a data link capability as reported in the<br />
capability (CA) field of an all-call reply or squitter transmission (see Data link capability report).<br />
Close-out. A comm<strong>and</strong> from a <strong>Mode</strong> S interrogator that terminates a <strong>Mode</strong> S link layer communications transaction.<br />
Comm-A. A 112-bit interrogation containing the 56-bit MA message field. This field is used by the uplink st<strong>and</strong>ard<br />
length message (SLM) <strong>and</strong> broadcast protocols.<br />
Comm-B. A 112-bit reply containing the 56-bit MB message field. This field is used by the downlink SLM,<br />
ground-initiated <strong>and</strong> broadcast protocols.<br />
(ix)<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
(x) <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Comm-C. A 112-bit interrogation containing the 80-bit MC message field. This field is used by the uplink extended<br />
length message (ELM) protocol.<br />
Comm-D. A 112-bit reply containing the 80-bit MD message field. This field is used by the downlink ELM protocol.<br />
Data link capability report. In<strong>for</strong>mation in a Comm-B reply identifying the complete <strong>Mode</strong> S communication<br />
capabilities of the aircraft installation.<br />
Downlink. A term referring to the transmission of data from an aircraft to the ground. <strong>Mode</strong> S air-to-ground signals are<br />
transmitted on the 1 090 MHz reply frequency channel.<br />
Frame. The basic unit of data transfer at the link level. A frame can include from one to four Comm-A or Comm-B<br />
segments, from two to sixteen Comm-C segments, or from one to sixteen Comm-D segments.<br />
General Formatter/Manager (GFM). The aircraft function responsible <strong>for</strong> <strong>for</strong>matting messages to be inserted in the<br />
transponder registers. It is also responsible <strong>for</strong> detecting <strong>and</strong> h<strong>and</strong>ling error conditions such as the loss of input<br />
data.<br />
Ground Data Link Processor (GDLP). A ground-resident processor that is specific to a particular air-ground data link<br />
(e.g., <strong>Mode</strong> S) <strong>and</strong> which provides channel management, <strong>and</strong> segments <strong>and</strong>/or reassembles messages <strong>for</strong> transfer.<br />
It is connected on one side (by means of its data circuit terminating equipment (DCE)) to ground elements common<br />
to all data link systems, <strong>and</strong> on the other side to the air-ground link itself.<br />
Ground-initiated Comm-B (GICB). The ground-initiated Comm-B protocol allows the interrogator to extract Comm-B<br />
replies containing data from one of the 255 transponder registers within the transponder in the MB field of the reply.<br />
Ground-initiated protocol. A procedure initiated by a <strong>Mode</strong> S interrogator <strong>for</strong> delivering st<strong>and</strong>ard length (via Comm-A)<br />
or extended length (via Comm-C) messages to a <strong>Mode</strong> S aircraft installation.<br />
Horizontal Integrity Limit (HIL). The radius of a circle in the horizontal plane (i.e., the plane tangent to the WGS-84<br />
ellipsoid), with its center being the true position, which describes the region which is assured to contain the<br />
indicated horizontal position.<br />
Draft<br />
Horizontal Protection Limit (HPL). The radius of a circle in the horizontal plane (i.e., the plane tangent to the WGS-84<br />
ellipsoid), with its center being the true position, which describes the region which is assured to contain the<br />
indicated horizontal position.<br />
Note. — The terms HPL <strong>and</strong> HIL (Horizontal Integrity Limit) are used interchangeably in various documents.<br />
<strong>Mode</strong> S broadcast protocols. Procedures allowing st<strong>and</strong>ard length uplink or downlink messages to be received by<br />
more than one transponder or ground interrogator, respectively.<br />
<strong>Mode</strong> S packet. A packet con<strong>for</strong>ming to the <strong>Mode</strong> S subnetwork st<strong>and</strong>ard, designed to minimize the b<strong>and</strong>width<br />
required from the air-ground link. ISO 8208 packets may be trans<strong>for</strong>med into <strong>Mode</strong> S packets <strong>and</strong> vice versa.<br />
<strong>Mode</strong> S Specific Protocol (MSP). A protocol that provides a restricted datagram service within the <strong>Mode</strong> S subnetwork.<br />
<strong>Mode</strong> S specific services. A set of communication services provided by the <strong>Mode</strong> S system which are not available<br />
from other air-ground subnetworks <strong>and</strong> there<strong>for</strong>e not interoperable.<br />
Packet. The basic unit of data transfer among communications devices within the network layer (e.g., an ISO 8208<br />
packet or a <strong>Mode</strong> S packet).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Glossary (xi)<br />
Required Navigation Per<strong>for</strong>mance (RNP). A statement of the navigation per<strong>for</strong>mance accuracy necessary <strong>for</strong><br />
operation within a defined airspace.<br />
Segment. A portion of a message that can be accommodated within a single MA/MB field in the case of an SLM, or a<br />
single MC/MD field in the case of an ELM. This term is also applied to the <strong>Mode</strong> S transmissions containing these<br />
fields.<br />
St<strong>and</strong>ard Length Message (SLM). An exchange of digital data using selectively addressed Comm-A interrogations<br />
<strong>and</strong>/or Comm-B replies.<br />
Subnetwork. An actual implementation of a data network that employs a homogeneous protocol <strong>and</strong> addressing plan<br />
<strong>and</strong> is under the control of a single authority.<br />
Timeout. The cancellation of a transaction after one of the participating entities has failed to provide a required<br />
response within a pre-defined period of time.<br />
Traffic in<strong>for</strong>mation service — broadcast (TIS-B). The principle use of TIS-B is to complement the operation of ADS-B<br />
by providing ground-to-air broadcast of surveillance data on aircraft that are not equipped <strong>for</strong> 1090 MHz ADS-B<br />
OUT as an aid to transition to a full ADS-B environment. The basis <strong>for</strong> this ground surveillance data may be an air<br />
traffic control (ATC) <strong>Mode</strong> S radar, a surface or approach multilateration system, or a multi-sensor data processing<br />
system. The TIS-B ground-to-air transmissions use the same signal <strong>for</strong>mats as 1090 MHz ADS-B <strong>and</strong> can<br />
there<strong>for</strong>e be accepted by a 1 090 MHz ADS-B receiver.<br />
Uplink. A term referring to the transmission of data from the ground to an aircraft. <strong>Mode</strong> S ground-to-air signals are<br />
transmitted on the 1030 MHz interrogation frequency channel.<br />
Vertical Protection Limit (VPL). The vertical geometric position integrity containment region defined by the vertical<br />
distance centered on the reported vertical position within which the true vertical position lies.<br />
_____________________<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
ACRONYMS<br />
ACAS Airborne collision avoidance system<br />
ADLP Airborne data link processor<br />
ADS-B Automatic dependent surveillance — broadcast<br />
ADS-R Automatic dependent surveillance — rebroadcast<br />
ANP Actual navigation per<strong>for</strong>mance<br />
ATN Aeronautical telecommunication network<br />
ATS Air traffic service<br />
A/V Aircraft/vehicle<br />
BDS Comm-B data selector<br />
BITE Built-in test equipment<br />
CFDIU Centralized fault display interface unit<br />
CPR Compact position reporting<br />
ELM <strong>Extended</strong> length message<br />
ES <strong>Extended</strong> squitter<br />
FCC Flight control computer<br />
FCU Flight control unit<br />
FMS Flight management system<br />
GDLP Ground data link processor<br />
GFM General <strong>for</strong>matter/manager<br />
GICB Ground-initiated Comm-B<br />
GNSS Global navigation satellite system<br />
GVA Geometric vertical accuracy<br />
HAE Height above the ellipsoid<br />
HIL Horizontal integrity limit<br />
HPL Horizontal protection limit<br />
II Interrogator identifier<br />
LSB Least significant bit<br />
MA Message, Comm-A<br />
MB Message, Comm-B<br />
MC Message, Comm-C<br />
MCP <strong>Mode</strong> control panel<br />
MD Message, Comm-D<br />
MOPS Minimum operational per<strong>for</strong>mance st<strong>and</strong>ards<br />
MSB Most significant bit<br />
MSP <strong>Mode</strong> S specific protocol<br />
MSSS <strong>Mode</strong> S specific services<br />
NACP Navigational accuracy category — position<br />
NACV Navigational accuracy category — velocity<br />
NIC Navigation integrity category<br />
NUCP Navigational uncertainty category — position<br />
NUCR Navigational uncertainty category — rate<br />
RC Radius of containment<br />
RNP Required navigation per<strong>for</strong>mance<br />
SAF Single antenna flag<br />
SARPs St<strong>and</strong>ards <strong>and</strong> Recommended Practices<br />
SDA System Design Assurance<br />
Draft<br />
(xiii)<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
(xiv) <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
SI Surveillance identifier<br />
SIL Surveillance integrity level (Version 1, Edition 1, Appendix B)<br />
SIL Source integrity level (Version 2, Edition 2, Appendix C)<br />
SLM St<strong>and</strong>ard length message<br />
SPI Special position identification<br />
SSE <strong>Mode</strong> S specific services entity<br />
SSR Secondary surveillance radar<br />
TIS Traffic in<strong>for</strong>mation service<br />
TIS-B Traffic in<strong>for</strong>mation service — broadcast<br />
UAT Universal Access Transceiver<br />
UTC Universal time clock (Coordinated universal time)<br />
_____________________<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Chapter 1<br />
INTRODUCTION<br />
1.1 OUTLINE OF THE MANUAL<br />
1.1.1 This manual specifies detailed technical provisions related to the implementation of the St<strong>and</strong>ards <strong>and</strong><br />
Recommended Practices (SARPs) <strong>for</strong> surveillance systems using <strong>Mode</strong> S services <strong>and</strong> extended squitter (1090ES):<br />
These detailed technical provisions supplement requirements that are contained in Annex 10 — Aeronautical<br />
Telecommunications, Volume III (Part I — Digital Data Communication Systems), <strong>and</strong> Volume IV — Surveillance Radar<br />
<strong>and</strong> Collision Avoidance Systems, <strong>and</strong> are necessary to ensure global interoperability.<br />
1.1.2 The structure of the manual is as follows:<br />
a) Chapter 1 presents the outline, objectives <strong>and</strong> scope of this manual;<br />
b) Chapter 2 contains specifications <strong>for</strong> transponder register <strong>for</strong>mats, protocols <strong>and</strong> related requirements<br />
<strong>for</strong> <strong>Mode</strong> S services <strong>and</strong> <strong>for</strong> Version 0 1090ES which is was suitable <strong>for</strong> early implementation of<br />
1090ES applications. Using these 1090ES message <strong>for</strong>mats, ADS-B surveillance quality is reported by<br />
navigation uncertainty category (NUC) which can be an indication of either the accuracy or integrity of<br />
the navigation data being broadcast. However, there is no indication as to whether the NUC value is<br />
based on integrity or accuracy; <strong>and</strong><br />
c) Chapter 3 contains specifications <strong>for</strong> Version 1 1090ES message <strong>for</strong>mats <strong>and</strong> related requirements that<br />
apply to more advanced ADS-B applications. Surveillance accuracy <strong>and</strong> integrity are reported<br />
separately as navigation accuracy category (NAC), navigation integrity category (NIC) <strong>and</strong> surveillance<br />
integrity level (SIL). Version 1 1090ES <strong>for</strong>mats also include provisions <strong>for</strong> enhanced reporting of status<br />
in<strong>for</strong>mation <strong>and</strong>, the ground-to-air transmission of traffic in<strong>for</strong>mation service — broadcast (TIS-B)<br />
messages <strong>and</strong> ADS-B rebroadcast (ADS-R) messages, <strong>and</strong><br />
Draft<br />
d) Chapter 4 contains specifications <strong>for</strong> Version 2 1090ES message <strong>for</strong>mats <strong>and</strong> related requirements that<br />
reflected needed revisions based on operational experience with ADS-B. The integrity level of the ADS-<br />
B source has been redefined <strong>and</strong> changes made to the definitions of the NIC <strong>and</strong> NAC parameters.<br />
Version 2 1090ES <strong>for</strong>mats now include the transmission of selected altitude, selected heading, <strong>and</strong><br />
barometric pressure setting in the target state <strong>and</strong> status messages. Version 2 1090ES <strong>for</strong>mats also<br />
include both the transmission of the <strong>Mode</strong> A (4096) codes, <strong>and</strong> the content of Register 3016 (ACAS<br />
active resolution advisory).<br />
1.1.3 The <strong>for</strong>mats <strong>for</strong> the two versions 0, 1 <strong>and</strong> 2 are interoperable in the delivery of critical data. An extended<br />
squitter receiver can recognize <strong>and</strong> decode both Version 0 <strong>and</strong> Version 1 message <strong>for</strong>mats. Version 2 <strong>for</strong>mats are<br />
interoperable with Version 0 <strong>and</strong> 1 <strong>for</strong>mats, except <strong>for</strong> minor differences of certain non-critical data, as presented in<br />
detail in Appendix C <strong>and</strong> summarized in Table 4-1. It is recognized that Civil Aviation Authorities may require aircraft to<br />
support Version 1 transmit capabilities in combination with ES reception capabilities to support certain applications.<br />
Additional guidance is provided in Appendix C D of this document <strong>and</strong> in the Aeronautical Surveillance Manual on the<br />
Secondary Surveillance Radar (SSR) Systems (Doc 96849924).<br />
1-1<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1-2 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
1.2 RELATED DOCUMENTS<br />
Ref. 1. Annex 10 — Aeronautical Telecommunications, Volume III, Part I — Digital Data Communication Systems,<br />
Chapter 5.<br />
Ref. 2. Annex 10 — Aeronautical Telecommunications, Volume IV — Surveillance Radar <strong>and</strong> Collision Avoidance<br />
Systems, Chapters 2 through 4.<br />
Ref. 3. RTCA/DO-260 (equivalent to EUROCAE/ED-102), Minimum Operational Per<strong>for</strong>mance St<strong>and</strong>ards <strong>for</strong> 1090<br />
MHz Automatic Dependent Surveillance — Broadcast (ADS-B), RTCA, September 2000.<br />
Ref. 34. RTCA/DO-260A, Minimum Operational Per<strong>for</strong>mance St<strong>and</strong>ards <strong>for</strong> 1090 MHz Automatic Dependent<br />
Surveillance — Broadcast (ADS-B) <strong>and</strong> Traffic In<strong>for</strong>mation <strong>Services</strong> (TIS-B), RTCA, April 2003, including<br />
Change 1 to RTCA/DO-260A, June 27, 2006, <strong>and</strong> Change 2 to RTCA/DO-260A, December 13, 2006.<br />
Ref. 5. RTCA/DO-260B (equivalent to EUROCAE/ED-102A), Minimum Operational Per<strong>for</strong>mance St<strong>and</strong>ards <strong>for</strong><br />
1090 MHz Automatic Dependent Surveillance — Broadcast (ADS-B) <strong>and</strong> Traffic In<strong>for</strong>mation <strong>Services</strong> (TIS-<br />
B), RTCA <strong>and</strong> EUROCAE, December 2009.<br />
_____________________<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Chapter 2<br />
OVERVIEW OF MODE S SERVICES AND<br />
EXTENDED SQUITTER VERSION 0<br />
2.1 INTRODUCTION<br />
2.1.1 The selective addressing feature of <strong>Mode</strong> S provides a natural mechanism <strong>for</strong> a data link. The link design<br />
provides <strong>for</strong> ground-to-air, air-to-air, air-to-ground, <strong>and</strong> surface message transfers. Air-to-ground messages may be<br />
either air initiated or ground initiated. The ground initiated message transfer is provided to efficiently read technical<br />
in<strong>for</strong>mation available on board the aircraft. <strong>Mode</strong> S also includes certain unique data link capabilities that are referred to<br />
as <strong>Mode</strong> S services.<br />
2.1.2 Formats <strong>and</strong> protocols <strong>for</strong> 1090ES ADS-B messages are also included since registers are defined <strong>for</strong> each<br />
of these messages so that extended squitter messages can be read out on dem<strong>and</strong> by a ground interrogator, in addition<br />
to being delivered via ADS-B.<br />
2.2 PURPOSE<br />
The purpose of this chapter is to specify detailed technical provisions <strong>for</strong> the <strong>for</strong>mats <strong>and</strong> associated protocols <strong>for</strong> the<br />
following:<br />
a) transponder registers;<br />
b) <strong>Mode</strong> S specific protocols, including:<br />
i) traffic in<strong>for</strong>mation broadcast; <strong>and</strong><br />
ii) dataflash;<br />
c) <strong>Mode</strong> S broadcast protocols, including:<br />
i) uplink broadcast;<br />
ii) downlink broadcast; <strong>and</strong><br />
d) extended squitter Version 0.<br />
Draft<br />
2.3 EXTENDED SQUITTER VERSION 0<br />
2.3.1 The initial st<strong>and</strong>ardization of 1090ES was consistent with RTCA/DO-260 [Ref 43] <strong>and</strong> was termed 1090ES<br />
Version 0. Using these 1090ES message <strong>for</strong>mats, ADS-B surveillance quality is reported by navigation uncertainty<br />
category (NUC), which can be an indication of either the accuracy or integrity of the navigation data used by ADS-B.<br />
However, there is no indication as to whether the NUC value is based on integrity or accuracy.<br />
2-1<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
2-2 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
2.3.2 A number of revisions have been implemented into the Compact Position Reporting (CPR) algorithm since the<br />
publication of Edition 1 of this Manual. These revisions have been incorporated into the CPR algorithm specification in<br />
section C.2.6 of Appendix C. For this reason, the original specification of CPR has been removed from section A.2.6 of<br />
Appendix A.<br />
Note.— A Change 1 to RTCA/DO-260 has been published as, “Minimum Operational Per<strong>for</strong>mance<br />
St<strong>and</strong>ards <strong>for</strong> 1090 MHz Automatic Dependent Surveillance — Broadcast (ADS-B), RTCA, dated June 26, 2006.” The<br />
revisions identified in that change have not affected the material in this document.<br />
2.4 DETAILED TECHNICAL PROVISIONS<br />
Detailed technical provisions <strong>for</strong> data <strong>for</strong>mats <strong>and</strong> control parameters <strong>for</strong> <strong>Mode</strong> S services <strong>and</strong> Version 0 1090ES are<br />
specified in Appendix A.<br />
2.5 IMPLEMENTATION GUIDELINES<br />
Implementation guidelines <strong>for</strong> <strong>Mode</strong> S services <strong>and</strong> Version 0 1090ES <strong>for</strong>mats <strong>and</strong> protocols are provided in Appendix<br />
CD.<br />
2.6 SERVICES UNDER DEVELOPMENT<br />
<strong>Technical</strong> in<strong>for</strong>mation on potential future <strong>Mode</strong> S <strong>and</strong> extended squitter services is presented in Appendix DE.<br />
_____________________<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Chapter 3<br />
OVERVIEW OF EXTENDED SQUITTER VERSION 1<br />
3.1 EXTENDED SQUITTER VERSION 1<br />
3.1.1 The <strong>for</strong>mats <strong>and</strong> protocols <strong>for</strong> 1090ES were revised in part to overcome the limitation of the reporting of<br />
surveillance quality using only navigation uncertainty category (NUC). In the revised <strong>for</strong>mats <strong>and</strong> protocols, surveillance<br />
accuracy <strong>and</strong> integrity are reported separately as:<br />
a) navigation accuracy category (NAC);<br />
b) navigation integrity category (NIC); <strong>and</strong><br />
c) surveillance integrity level (SIL).<br />
3.1.2 Other features added in Version 1 messages include the reporting of additional status parameters <strong>and</strong><br />
<strong>for</strong>mats <strong>for</strong> traffic in<strong>for</strong>mation service — broadcast <strong>and</strong> ADS-B rebroadcast (ADS-R).<br />
3.1.3 Version 1 <strong>for</strong>mats are fully compatible with those of Version 0, in that a receiver of either version can<br />
correctly receive <strong>and</strong> process messages of either version. The Version 1 <strong>for</strong>mats <strong>and</strong> protocols in this manual are<br />
consistent with RTCA DO-260A [Ref 34].<br />
3.2 TRAFFIC INFORMATION SERVICE — BROADCAST (TIS-B)<br />
Draft<br />
3.2.1 The principle use of TIS-B is to complement the operation of ADS-B by providing ground-to-air broadcast of<br />
surveillance data on aircraft that are not equipped <strong>for</strong> 1090 MHz ADS-B OUT as an aid to transition to a full ADS-B<br />
environment. The basis <strong>for</strong> this ground surveillance data may be an air traffic control (ATC) <strong>Mode</strong> S radar, a surface or<br />
approach multilateration system or a multi-sensor data processing system. The TIS-B ground-to-air transmissions use<br />
the same signal <strong>for</strong>mats as 1090 MHz ADS-B <strong>and</strong> can there<strong>for</strong>e be accepted by a 1090 MHz ADS-B receiver.<br />
3.2.2 TIS-B service is intended to provide a complete surveillance picture to 1090 MHz ADS-B IN users during a<br />
transition period. After transition, it also provides a means to cope with a user that has lost 1090 MHz ADS-B capability,<br />
or is broadcasting incorrect in<strong>for</strong>mation.<br />
3.3 AUTOMATIC DEPENDENT SURVEILLANCE — REBROADCAST (ADS-R)<br />
The principle use of ADS-R is to provide interoperability in airspace where multiple different ADS-B data links are<br />
operating. ADS-B transmissions on a data link other than 1090 MHz are received <strong>and</strong> converted to extended squitter<br />
<strong>for</strong>mats <strong>and</strong> broadcast by a ground system on the 1090 MHz ADS-B data link.<br />
3-1<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
3-2 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
3.4 DETAILED TECHNICAL PROVISIONS<br />
Detailed technical provisions <strong>for</strong> data <strong>for</strong>mats <strong>and</strong> control parameters <strong>for</strong> 1090ES Version 1 <strong>and</strong> TIS-B/ADS-R are<br />
specified in Appendix B.<br />
3.5 IMPLEMENTATION GUIDELINES<br />
Implementation guidelines <strong>for</strong> <strong>Mode</strong> S services <strong>and</strong> 1090ES Version 1 <strong>for</strong>mats <strong>and</strong> protocols are provided in Appendix<br />
CD.<br />
3.6 SERVICES UNDER DEVELOPMENT<br />
<strong>Technical</strong> in<strong>for</strong>mation on potential future <strong>Mode</strong> S <strong>and</strong> extended squitter services is presented in Appendix DE.<br />
_____________________<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Chapter 4<br />
OVERVIEW OF EXTENDED SQUITTER VERSION 2<br />
4.1 EXTENDED SQUITTER VERSION 2<br />
4.1.1 The <strong>for</strong>mats <strong>and</strong> protocols <strong>for</strong> ES Version 2 were revised based on experience gained from operational<br />
usage with ADS-B that revealed a number of needed improvements. These included:<br />
a) separated reporting of source <strong>and</strong> system integrity;<br />
b) additional levels of NIC to better support airborne <strong>and</strong> surface applications;<br />
c) incorporation of the broadcast of the <strong>Mode</strong> A code into the emergency/priority message, increased<br />
transmission rates after a <strong>Mode</strong> A code change, <strong>and</strong> the broadcast of the <strong>Mode</strong> A code on the surface;<br />
d) revision to the target state <strong>and</strong> status message to include additional parameters;<br />
e) eliminated the vertical component of NIC <strong>and</strong> NAC;<br />
f) T=0 position extrapolation accuracy changed from within 200 ms of the time of transmission to within<br />
100 ms; <strong>and</strong><br />
f) capabilities were added to support airport surface applications.<br />
Draft<br />
4.1.2 Traffic in<strong>for</strong>mation service — broadcast (TIS-B) (see 3.2) remained unchanged because it is version<br />
independent. ADS-R <strong>for</strong>mats were updated to Version 2 to be compatible with changes to ADS-B <strong>for</strong>mats.<br />
4.1.3 The Version 2 <strong>for</strong>mats <strong>and</strong> protocols in this manual are consistent with RTCA DO-260B <strong>and</strong> EUROCAE ED-<br />
102A [Ref 5].<br />
4.1.4 The <strong>for</strong>mats <strong>for</strong> versions 0, 1 <strong>and</strong> 2 are interoperable in the delivery of critical data. Version 2 <strong>for</strong>mats are<br />
interoperable with Version 0 <strong>and</strong> 1 <strong>for</strong>mats, except <strong>for</strong> minor differences of certain non-critical data, as presented in<br />
detail in Appendix C <strong>and</strong> summarized in Table 4-1.<br />
4-1<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
4-2 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Table 4-1. ADS-B Version 2 Backward Compatibility Summary<br />
Description of ADS-B Version 2 Change Backward Compatibility Impact to Version 1 Receiver<br />
1<br />
Add duplicate address processing <strong>for</strong> ADS-B <strong>and</strong><br />
ADS-R.<br />
None – Modifies Version 2 receiver requirements so no<br />
impact to Version 1 receivers.<br />
ADS-B<br />
None - Uses an additional bit in transmitted message to<br />
2<br />
Add NIC value <strong>for</strong> RC of 0.3 NM between currently<br />
defined NIC values <strong>for</strong> RC of 0.2 <strong>and</strong> 0.5 NM.<br />
encode. Version 1 receivers will decode as RC of<br />
0.6 NM.<br />
ADS-R<br />
None – Version 2 Additional bit allocated in Operational<br />
Status Message <strong>for</strong> ADS-R NIC Supplement B.<br />
3<br />
Add ability to transmit UTC Coupled (T=1) <strong>for</strong> the<br />
non-precision NIC values.<br />
Add broadcast of <strong>Mode</strong> A code at higher rates than<br />
None.<br />
4<br />
Version 1. Different update rates are required<br />
between the steady state condition (no <strong>Mode</strong> A code<br />
change) <strong>and</strong> when the code is changed.<br />
Delete requirement <strong>for</strong> “Receiving ATC Service” bit,<br />
Transparent to Version 1 receivers except they will<br />
receive more messages due to higher transmit rate.<br />
5 but note it as reserved <strong>for</strong> that purpose in the future if<br />
<strong>Mode</strong> A code is ever supplanted.<br />
None—not used air-to-air.<br />
6 NACV definition clarification. None.<br />
7<br />
Remove vertical components from NACP, NACV, NIC<br />
<strong>and</strong> SIL.<br />
None.<br />
8 Add parameter <strong>for</strong> Geometric Vertical Accuracy. None - Uses reserved bits that will not be decodable.<br />
9<br />
Redefine SIL <strong>and</strong> add SIL Supplement <strong>and</strong> System<br />
Design Assurance.<br />
None - New Source Integrity Level parameter replaces<br />
Surveillance Integrity Level. SIL Supplement <strong>and</strong><br />
SDA uses reserved bits that will not be decodable.<br />
10<br />
Delete CDTI bit <strong>and</strong> create 2 bit field to denote UAT<br />
IN <strong>and</strong> 1090ES IN (<strong>for</strong> Ground use).<br />
The CDTI bit will be decoded incorrectly—but is not used<br />
by current avionics.<br />
Since a different code is used <strong>for</strong> the updated message,<br />
Version 1 receivers will not decode the message at all.<br />
There are no current applications that use the target state<br />
Revise Target State <strong>and</strong> Status Message to add data. However, since there are some integrity <strong>and</strong><br />
11 selected altitude, modify mode bits <strong>and</strong> include the accuracy parameters transmitted in the Target State <strong>and</strong><br />
pilot selected pressure altitude correction.<br />
Add note to explain that NIC is to be immediately set<br />
Status Message, Version 1 receivers will not be receiving<br />
these parameters at the proper update rate. However,<br />
not all aircraft transmit the Target State <strong>and</strong> Status<br />
Message.<br />
12 to ZERO on receipt of an alarm discrete from GPS<br />
sensor.<br />
T=0 position extrapolation accuracy changed from<br />
None.<br />
13 within 200 ms of the time of transmission to within<br />
100 ms.<br />
None.<br />
Version 1 contained a Single Antenna Flag but since it<br />
14 Support a Single Antenna Flag.<br />
has moved, receivers will not properly decode it. Current<br />
applications do not use the Single Antenna Flag.<br />
Slight change in values at lower Ground speeds, but<br />
15 Ground Speed encoding change.<br />
since the Ground speed is highly inaccurate in the range<br />
of the change, not a significant impact.<br />
16<br />
Include Loss of GPS Position as a criteria <strong>for</strong> a<br />
fail/warn annunciation.<br />
None.<br />
Draft<br />
4-2<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Chapter 2. Overview of <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong> Version 2 2-3<br />
Description of ADS-B Version 2 Change Backward Compatibility Impact to Version 1 Receiver<br />
17<br />
Redefine Length/Width Codes to add a code <strong>for</strong> “No<br />
In<strong>for</strong>mation Available.”<br />
Minor impact since smallest represented length/width<br />
would be interpreted as unknown.<br />
18<br />
Change definition of TCAS Operational <strong>and</strong> TCAS<br />
RA active bits.<br />
These bits will be decoded incorrectly—but are not used<br />
by current avionics.<br />
19<br />
Add additional NIC values when reporting surface<br />
position data so that larger RC values can be<br />
represented when on the surface.<br />
None – Receivers will decode additional NICs as<br />
unknown integrity.<br />
20 Add TCAS RA broadcast. None - Uses reserved code that will not be decodable.<br />
21<br />
Add new equipment class to allow single antenna<br />
with A1 power level.<br />
None.<br />
22<br />
Modify Local CPR Reasonableness Test to account<br />
<strong>for</strong> air-to-ground <strong>and</strong> ground-to-air transitions.<br />
None.<br />
4.2 DETAILED TECHNICAL PROVISIONS<br />
Detailed technical provisions <strong>for</strong> data <strong>for</strong>mats <strong>and</strong> control parameters <strong>for</strong> 1090ES Version 2 <strong>and</strong> TIS-B/ADS-R are<br />
specified in Appendix C.<br />
4.3 IMPLEMENTATION GUIDELINES<br />
Implementation guidelines <strong>for</strong> <strong>Mode</strong> S services <strong>and</strong> 1090ES Version 2 <strong>for</strong>mats <strong>and</strong> protocols are provided in Appendix D.<br />
4.4 SERVICES UNDER DEVELOPMENT<br />
<strong>Technical</strong> in<strong>for</strong>mation on potential future <strong>Mode</strong> S <strong>and</strong> extended squitter services is presented in Appendix E.<br />
Draft<br />
_____________________<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
4-4 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
This page intentionally left blank.<br />
Draft<br />
4-4<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A<br />
DATA/MESSAGE FORMATS AND CONTROL PARAMETERS<br />
FOR MODE S SPECIFIC SERVICES AND<br />
EXTENDED SQUITTER VERSION 0<br />
A.1. INTRODUCTION<br />
A.1.1 Appendix A defines data/message <strong>for</strong>mats <strong>and</strong> control parameters that shall be used <strong>for</strong> communications<br />
using <strong>Mode</strong> S services <strong>and</strong> extended squitter Version 0.<br />
Note 1.— Appendix A is arranged in the following manner:<br />
Section A.1 Introduction<br />
Section A.2 Data <strong>for</strong>mats <strong>for</strong> transponder registers<br />
Section A.3 Formats <strong>for</strong> <strong>Mode</strong> S specific protocols (MSP)<br />
Section A.4 <strong>Mode</strong> S broadcast protocols<br />
Note 2.— Implementation guidelines on data sources, the use of control parameters, <strong>and</strong> the protocols involved are<br />
given in Appendix CD.<br />
A.2. DATA FORMATS FOR TRANSPONDER REGISTERS<br />
Draft<br />
A.2.1 REGISTER ALLOCATION<br />
Applications shall use the allocated register numbers as shown in the table below:<br />
Transponder register<br />
number<br />
Assignment Maximum update interval (1)<br />
0016 Not valid N/A<br />
0116 UnassignedReserved N/A<br />
0216 Linked Comm-B, segment 2 N/A<br />
0316 Linked Comm-B, segment 3 N/A<br />
0416 Linked Comm-B, segment 4 N/A<br />
0516 <strong>Extended</strong> squitter airborne position (2) 0.2s<br />
0616 <strong>Extended</strong> squitter surface position (2) 0.2s (see §A.2.3.3.1 <strong>and</strong> §A.2.3.3.2)<br />
0716 <strong>Extended</strong> squitter status (2) 1.0s<br />
0816 <strong>Extended</strong> squitter identification <strong>and</strong> typecategory (2) 15.0s<br />
0916 <strong>Extended</strong> squitter airborne velocity (2) 1.3s<br />
0A16 <strong>Extended</strong> squitter event-driven in<strong>for</strong>mation (2) variable<br />
A-1<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-2 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Transponder register<br />
number<br />
Assignment Maximum update interval (1)<br />
0B16 Air/air in<strong>for</strong>mation 1 (aircraft state) 1.3s<br />
0C16 Air/air in<strong>for</strong>mation 2 (aircraft intent) 1.3s<br />
0D16-0E16 Reserved <strong>for</strong> air/air state in<strong>for</strong>mation To be determined<br />
0F16 Reserved <strong>for</strong> ACAS To be determined<br />
1016 Data link capability report ≤4.0s (see §A.2.1.2)<br />
1116-1616 Reserved <strong>for</strong> extension to datalink capability reports 5.0s<br />
1716 Common usage GICB capability report 5.0s<br />
1816 – 1C16 <strong>Mode</strong> S specific services capability reports see §A.2.5.4.2.1<br />
18161D16-1F16 <strong>Mode</strong> S specific services capability reports 5.0s<br />
2016 Aircraft identification 5.0s<br />
2116 Aircraft <strong>and</strong> airline registration markings 15.0s<br />
2216 Antenna positions 15.0s<br />
2316 Reserved <strong>for</strong> antenna position 15.0s<br />
2416 Reserved <strong>for</strong> aircraft parameters 15.0s<br />
2516 Aircraft type 15.0s<br />
2616-2F16 UnassignedReserved N/A<br />
3016 ACAS active resolution advisory [see Ref 2, §4.3.8.4.2.2]<br />
3116-3F16 UnassignedReserved N/A<br />
4016 Selected vertical intention 1.0s<br />
4116 Next waypoint identifier 1.0s<br />
4216 Next waypoint position 1.0s<br />
4316 Next waypoint in<strong>for</strong>mation 0.5s<br />
4416 Meteorological routine air report 1.0s<br />
4516 Meteorological hazard report 1.0s<br />
4616 Reserved <strong>for</strong> flight management system <strong>Mode</strong> 1 To be determined<br />
4716 Reserved <strong>for</strong> flight management system <strong>Mode</strong> 2 To be determined<br />
Draft<br />
4816 VHF channel report 5.0s<br />
4916-4F16 UnassignedReserved N/A<br />
5016 Track <strong>and</strong> turn report 1.3s<br />
5116 Position report coarse 1.3s<br />
5216 Position report fine 1.3s<br />
5316 Air-referenced state vector 1.3s<br />
5416 Waypoint 1 5.0s<br />
5516 Waypoint 2 5.0s<br />
5616 Waypoint 3 5.0s<br />
5716-5E16 UnassignedReserved N/A<br />
5F16 Quasi-static parameter monitoring 0.5s<br />
6016 Heading <strong>and</strong> speed report 1.3s<br />
6116 <strong>Extended</strong> squitter emergency/priority status (2) 1.0s<br />
6216 Reserved <strong>for</strong> target state <strong>and</strong> status in<strong>for</strong>mation (2) N/A<br />
6316 Reserved <strong>for</strong> extended squitter (2) N/A<br />
6416 Reserved <strong>for</strong> extended squitter (2) N/A<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-3<br />
Transponder register<br />
number<br />
Assignment Maximum update interval (1)<br />
6516 <strong>Extended</strong> squitter aircraft operational status (2) 1.7s<br />
6616-6F16 Reserved <strong>for</strong> extended squitter (2) N/A<br />
7016-7516 Reserved <strong>for</strong> future aircraft downlink parameters N/A<br />
7616-E016 UnassignedReserved N/A<br />
E116-E216 Reserved <strong>for</strong> <strong>Mode</strong> S BITE N/A<br />
E316 Transponder type/part number 15s<br />
E416 Transponder software revision number 15s<br />
E516 ACAS unit part number 15s<br />
E616 ACAS unit software revision number 15s<br />
E716 Transponder Status <strong>and</strong> Diagnostics 15s<br />
E816 Reserved <strong>for</strong> Future Diagnostics N/A<br />
E916 Reserved <strong>for</strong> Future Diagnostics N/A<br />
EA16 Vendor Specific Status <strong>and</strong> Diagnostics 15s<br />
EB16 Reserved <strong>for</strong> Future Vendor Specific Diagnostics N/A<br />
EC16 Reserved <strong>for</strong> Future Vendor Specific Diagnostics N/A<br />
E716ED16-F016 UnassignedReserved N/A<br />
F116 Military applications 15s<br />
F216 Military applications 15s<br />
F316-FF16 UnassignedReserved N/A<br />
Notes.—<br />
1. The term “minimum update rate” is used in the document. The minimum update rate is obtained when data is<br />
loaded in one register field once every maximum update interval.<br />
2. Register 0A16 is not to be used <strong>for</strong> GICB or ACAS crosslink readout.<br />
3. If <strong>Extended</strong> <strong>Squitter</strong> is implemented, then Register 0816 is not cleared or ZEROed once either Flight Identification or<br />
Aircraft Registration data has been loaded into the Register during the current power-on cycle. Register 0816 is not<br />
cleared since it provides in<strong>for</strong>mation that is fundamental to track file management in the ADS-B environment. Refer to<br />
§D.2.4.3.3 <strong>for</strong> implementation guidelines regarding Register 0816.<br />
4. These registers define version 0 extended squitters.<br />
Draft<br />
A.2.1.1 The details of the data to be entered into the assigned registers shall be as defined in this appendix. The<br />
above table specifies the minimum update ratesmaximum update interval at which the appropriate transponder<br />
register(s) shall be reloaded with valid data. Any valid data shall be reloaded into the relevant register field as soon as it<br />
becomes available at the <strong>Mode</strong> S specific services entity (SSE) interface regardless of the update rate. If Unless<br />
otherwise specified, if data are not available <strong>for</strong> a time no greater than twice the specified maximum update interval or 2<br />
seconds (whichever is the greater), the status bit (if specified <strong>for</strong> that field) shall indicate that the data in that field are<br />
invalid <strong>and</strong> the field shall be zeroed.<br />
Note.— Implementation guidelines on the loading <strong>and</strong> clearing of fields of transponder registers is provided in<br />
Appendix CD.<br />
A.2.1.2 The register number shall be equivalent to the Comm-B data selector (BDS) value used to address that<br />
register (see §3.1.2.6.11.2.1 of Annex 10, Volume IV). The data link capability report (register number 1016) shall be<br />
updated within one second of the data changing <strong>and</strong> at least every four seconds thereafter.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-4 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.2.2 GENERAL CONVENTIONS ON DATA FORMATS<br />
A.2.2.1 VALIDITY OF DATA<br />
The bit patterns contained in the 56-bit transponder registers (other than registers accessed by BDS codes 0,2; 0,3; 0,4;<br />
1,0; 1,7 to 1,C; 2,0 <strong>and</strong> 3,0) shall be considered as valid application data only if:<br />
1) the <strong>Mode</strong> S specific services capability is present. bit is set in register number 1016. This is indicated by bit 25<br />
of the data link capability report contained in register 1016 being set to “ONE”, <strong>and</strong><br />
2) the GICB service corresponding to the application is shown as “supported” by the corresponding bit in the GICB<br />
capability reportCommon Usage Capability Report (register numbers 1716 )to 1C16 being set to “ONE”; <strong>and</strong><br />
Note 1.— The intent of the capability bits in register number 1716 is to indicate that useful data are is<br />
contained in the corresponding transponder register. For this reason, each bit <strong>for</strong> a register is cleared if data<br />
becomes unavailable (see §A.2.5.4.1) <strong>and</strong> set again when data insertion into the register resumes.<br />
Note 2.— A bit set in registers numbers 1816 to 1C16 indicates that the application using this register has<br />
been installed on the aircraft. These bits are not cleared to reflect the real-time loss of an application, as is<br />
done <strong>for</strong> register number 1716 (see §A.2.5.4.2).<br />
3) the data value is valid at the time of extraction. This is indicated by a data field status bit (if specified <strong>for</strong> that<br />
fieldprovided). When this status bit is set to “ONE” the data field(s) which follow, up to the next status bit, are<br />
valid. When this status bit is set to “ZERO”, the data field(s) are invalid.<br />
Numerical data shall be represented as follows:<br />
A.2.2.2 REPRESENTATION OF NUMERICAL DATA<br />
1) Numerical data shall be represented as binary numerals. When the value is signed, two’s complement<br />
representation shall be used, <strong>and</strong> the bit following the status bit shall be the sign bit.<br />
2) Unless otherwise specified, whenever more bits of resolution are available from the data source than in the<br />
data field into which that data are is to be loaded, the data shall be rounded to the nearest value that can be<br />
encoded in that data field.<br />
Draft<br />
Note.— Unless otherwise specified, it is accepted that the data source may have fewer less bits of<br />
resolution than the data field.<br />
3) When the data source provides data with a higher or lower range than the data field, the data shall be truncated<br />
to the respective maximum or minimum value that can be encoded in the data field.<br />
4) Where ARINC 429 data are used, the ARINC 429 status bits 30 <strong>and</strong> 31 shall be replaced with a single status<br />
bit, <strong>for</strong> which the value is VALID or INVALID as follows:<br />
a) If bits 30 <strong>and</strong> 31 represent “Failure Warning, No Computed Data” then the status bit shall be set to<br />
“INVALID”.<br />
b) If bits 30 <strong>and</strong> 31 represent “Functional Test” then the status bit shall be set to “INVALID”.<br />
c) If bits 30 <strong>and</strong> 31 represent “Normal Operation,” “plus sign,” or “minus sign,” then the status bit shall be set<br />
to “VALID” provided that the data are being updated at the required rate (see §A.2.1.1).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-5<br />
d) If the data are not being updated at the required rate (see §A.2.1.1), then the status bit shall be set to<br />
“INVALID”.<br />
For interface <strong>for</strong>mats other than ARINC 429, a similar approach is used.<br />
5) In all cases where a status bit is specified in the data field it shall be set to “ONE” to indicate VALID <strong>and</strong> to<br />
“ZERO” to indicate INVALID.<br />
Note.— This facilitates partial loading of the registers.<br />
6) When specified in the field, the switch bit shall indicate which of two alternative data types is being used to<br />
update the parameter in the transponder register.<br />
7) Where the sign bit (ARINC 429 bit 29) is not required <strong>for</strong> a parameter, it has been actively excluded.<br />
8) Bit numbering in the MB field shall be as specified in Annex 10, Volume IV (see §3.1.2.3.1.3).<br />
89) Registers containing data intended <strong>for</strong> broadcast Comm-B shall have the broadcast identifier located in the<br />
eight most significant bits of the MB field.<br />
A.2.2.2.1 Recommendation.— When multiple data sources are available, the one with the highest resolution should<br />
be selected.<br />
Note 1.— Tables are numbered Table A.2-X where “X” is the decimal equivalent of the BDS code that is used to<br />
access the register to which the <strong>for</strong>mat applies. As used in this Manual, BDS A,B is equivalent to Register AB16.<br />
Note 2.— By default, values indicated in the range of the different fields of registers have been rounded to the<br />
nearest integer value or represented as a fraction.<br />
A.2.2.3 RESERVED FIELDS<br />
Unless specified in this document, these bit fields shall be are reserved <strong>for</strong> future allocation by ICAO <strong>and</strong> they shall be<br />
set to ZERO.<br />
Draft<br />
A.2.3 EXTENDED SQUITTER FORMATS<br />
This section defines the <strong>for</strong>mats <strong>and</strong> coding that shall be used <strong>for</strong> extended squitter ADS-B messages. The convention<br />
<strong>for</strong> register numbering shall not be required <strong>for</strong> an extended squitter/non-transponder device (ES/NT, Annex 10,<br />
Volume IV, §3.1.2.8.7). The data content <strong>and</strong> the transmit times shall be the same as specified <strong>for</strong> the transponder case.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-6 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.2.3.1 FORMAT TYPE CODES<br />
The <strong>for</strong>mat TYPE Code shall differentiate the <strong>Mode</strong> S extended squitter messages into several classes as specified in<br />
the following table:<br />
TYPE<br />
Code<br />
Format<br />
0 No position in<strong>for</strong>mation<br />
1<br />
2<br />
3<br />
4<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Identification<br />
(Category Set D)<br />
Identification<br />
(Category Set C)<br />
Identification<br />
(Category Set B)<br />
Identification<br />
(Category Set A)<br />
“TYPE” Subfield Code Definitions (DF = 17 or 18)<br />
Horizontal<br />
protection limit<br />
(HPL)<br />
95% Containment radius,<br />
µ <strong>and</strong> v, on horizontal<br />
<strong>and</strong> vertical position<br />
error<br />
Altitude type<br />
(see §A.2.3.2.4)<br />
Barometric altitude or<br />
no altitude in<strong>for</strong>mation<br />
Not applicable<br />
Not applicable<br />
Not applicable<br />
Not applicable<br />
5 Surface position HPL < 7.5 m µ < 3 m No altitude in<strong>for</strong>mation 9<br />
6 Surface position HPL < 25 m 3 m ≤ µ < 10 m No altitude in<strong>for</strong>mation 8<br />
7 Surface position<br />
8 Surface position<br />
HPL < 185.2 m<br />
(0.1 NM)<br />
HPL > 185.2 m<br />
(0.1 NM)<br />
10 m ≤ µ < 92.6 m<br />
(0.05 NM)<br />
NUCP<br />
No altitude in<strong>for</strong>mation 7<br />
(0.05 NM) 92.6 m ≤ µ No altitude in<strong>for</strong>mation 6<br />
9 Airborne position HPL < 7.5 m µ < 3 m Barometric altitude 9<br />
10 Airborne position 7.5 m ≤ HPL < 25 m 3 m ≤ µ < 10 m Barometric altitude 8<br />
11 Airborne position<br />
12 Airborne position<br />
13 Airborne position<br />
14 Airborne position<br />
15 Airborne position<br />
16 Airborne position<br />
17 Airborne position<br />
25 m ≤ HPL < 185.2 m<br />
(0.1 NM)<br />
10 m ≤ µ < 92.6 m<br />
(0.05 NM)<br />
Barometric altitude 7<br />
Draft<br />
185.2 m (0.1 NM) ≤ HPL<br />
< 370.4 m (0.2 NM)<br />
370.4 m (0.2 NM) ≤ HPL<br />
< 926 m (0.5 NM)<br />
926 m (0.5 NM) ≤ HPL<br />
< 1 852 m (1.0 NM)<br />
1 852 m (1.0 NM) ≤ HPL<br />
< 3 704 m (2.0 NM)<br />
3.704 km (2.0 NM) ≤ HPL<br />
< 18.52 km (10 NM)<br />
18.52 km (10 NM) ≤ HPL<br />
< 37.04 km (20 NM)<br />
92.6 m (0.05 NM) ≤ µ<br />
< 185.2 m (0.1 NM)<br />
185.2 m (0.1 NM) ≤ µ<br />
< 463 m (0.25 NM)<br />
463 m (0.25 NM) ≤ µ<br />
< 926 m (0.5 NM)<br />
926 m (0.5 NM) ≤ µ<br />
< 1 852 m (1.0 NM)<br />
1.852 km (1.0 NM) ≤ µ<br />
< 9.26 km (5.0 NM)<br />
9.26 km (5.0 NM) ≤ µ<br />
< 18.52 km (10.0 NM)<br />
Barometric altitude 6<br />
Barometric altitude 5<br />
Barometric altitude 4<br />
Barometric altitude 3<br />
Barometric altitude 2<br />
Barometric altitude 1<br />
18 Airborne position HPL ≥ 37.04 km (20 NM) 18.52 km (10.0 NM) ≤ µ Barometric altitude 0<br />
19 Airborne velocity Not applicable Not applicable<br />
Difference between<br />
“Barometric altitude”<br />
<strong>and</strong> “GNSS height<br />
(HAE) or GNSS altitude<br />
(MSL)”<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
0<br />
N/A
Appendix A A-7<br />
TYPE<br />
Code<br />
Format<br />
Horizontal<br />
protection limit<br />
(HPL)<br />
95% Containment radius,<br />
µ <strong>and</strong> v, on horizontal<br />
<strong>and</strong> vertical position<br />
error<br />
Altitude type<br />
(see §A.2.3.2.4)<br />
(2.3.5.7)<br />
20 Airborne position HPL < 7.5 m µ < 3 m <strong>and</strong> v < 4 m GNSS height (HAE) 9<br />
21 Airborne position HPL < 25 m µ < 10 m <strong>and</strong> v < 15 m GNSS height (HAE) 8<br />
22 Airborne position HPL ≥ 25 m µ > 10 m or v ≥ 15 m GNSS height (HAE) 0<br />
23 Reserved <strong>for</strong> test purposes<br />
24<br />
Reserved <strong>for</strong> surface system<br />
status<br />
25 – 27 Reserved<br />
28<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
<strong>Extended</strong> squitter aircraft<br />
emergency priority status<br />
29 Reserved<br />
30 Reserved<br />
31 Aircraft operational status<br />
In normal operating conditions, HPL or HIL in<strong>for</strong>mation is available from the navigation data source <strong>and</strong> shall be used to<br />
determine the <strong>for</strong>mat TYPE Code. The TYPE Code <strong>for</strong> airborne <strong>and</strong> surface position messages shall be determined<br />
based on the availability of integrity <strong>and</strong>/or accuracy in<strong>for</strong>mation as defined below:<br />
a) If horizontal protection level (HPL) in<strong>for</strong>mation is available from the navigation data source, then the<br />
transmitting ADS-B system shall use HPL <strong>and</strong> Altitude Type to determine the TYPE Code used in the Airborne<br />
Position Message in accordance with the above table.<br />
b) If HPL (or HIL) is temporarily not available from the navigation data source, then the transmitting ADS-B system<br />
shall use HFOM (95% bound on the horizontal position error), VFOM (95% bound on the vertical position error),<br />
<strong>and</strong> Altitude Type to determine the TYPE Code used in the Airborne Position Message in accordance with the<br />
above table.<br />
NUCP<br />
Draft<br />
c) If position data is available but the associated accuracy <strong>and</strong>/or integrity is unknown (i.e., the conditions in a)<br />
<strong>and</strong> b) above are not applicable), then the transmitting ADS-B system shall use <strong>for</strong> airborne position messages<br />
TYPE Code 18 or 22, depending on the altitude type, <strong>and</strong> <strong>for</strong> surface position messages TYPE Code 8 in<br />
accordance with the above table.<br />
Note 1.— The term “broadcast”, when applied to extended squitter, refers to a spontaneous transmission by the<br />
transponder. This is distinct from the Comm-B broadcast protocol.<br />
Note 2.— The Type Code allows users to determine whether the quality of the position is good enough <strong>for</strong> the<br />
intended application.<br />
Note 3.— Airborne Position Messages with Type Code 18 or 22 (NUCP=0), <strong>and</strong> Surface Position Messages with<br />
Type Code 8 (NUCP=6, HPL≥185.2m, μ≥92.6m) are not appropriate to support most ADS-B applications since these<br />
Type Codes indicate the accuracy <strong>and</strong> integrity of the broadcast position is unknown. Messages with these Type Codes<br />
are typically transmitted from installations where the ADS-B position is obtained from sources with no accompanying<br />
integrity in<strong>for</strong>mation.<br />
Note 4.— It is recommended that Version 0 extended squitter messages with Type Codes 8, 18 or 22 only be used<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-8 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
if either the position accuracy or integrity can be verified by other means, or the application has no specific requirements<br />
<strong>for</strong> these parameters.<br />
A.2.3.2 AIRBORNE POSITION FORMAT<br />
The airborne position squitter shall be <strong>for</strong>matted as specified in the definition of transponder register 0516. Additional<br />
details are specified in the following paragraphs.<br />
A.2.3.2.1 COMPACT POSITION REPORTING (CPR) FORMAT (F)<br />
In order to achieve coding that is unambiguous worldwide, CPR shall use two <strong>for</strong>mat types, known as even <strong>and</strong> odd.<br />
This 1-bit field (bit 22) shall be used to define the CPR <strong>for</strong>mat type. F=0 shall denote an even <strong>for</strong>mat coding, while F=1<br />
shall denote an odd <strong>for</strong>mat coding (see §AC.2.6.7).<br />
A.2.3.2.2 TIME SYNCHRONIZATION (T)<br />
This 1-bit field (bit 21) shall indicate whether or not the time of applicability of the message is synchronized with UTC<br />
time. T=0 shall denote that the time is not synchronized to UTC. T=1 shall denote that the time of applicability is<br />
synchronized to UTC time. Synchronization shall only be used <strong>for</strong> airborne position messages having the top two<br />
horizontal position precision categories (<strong>for</strong>mat TYPE Codes 9, 10, 20 <strong>and</strong> 21).<br />
When T=1, the time of validity in the airborne position message <strong>for</strong>mat shall be encoded in the 1-bit F field which, in<br />
addition to CPR <strong>for</strong>mat type, indicates the 0.2-second time tick <strong>for</strong> UTC time of position validity. The F bit shall alternate<br />
between 0 <strong>and</strong> 1 <strong>for</strong> successive 0.2-second time ticks, beginning with F=0 when the time of applicability is an exact evennumbered<br />
UTC second.<br />
A.2.3.2.3 LATITUDE/LONGITUDE<br />
The latitude/longitude field in the airborne position message shall be a 34-bit field containing the latitude <strong>and</strong> longitude of<br />
the aircraft airborne position. The latitude <strong>and</strong> longitude shall each occupy 17 bits. The airborne latitude <strong>and</strong> longitude<br />
encodings shall contain the 17 bits of the CPR-encoded values defined in §AC.2.6.<br />
Draft<br />
Note 1.— The unambiguous range <strong>for</strong> the local decoding of airborne messages is 666 km (360 NM). The positional<br />
accuracy maintained by the airborne CPR encoding is approximately 5.1 metres. The latitude/longitude encoding is also<br />
a function of the CPR <strong>for</strong>mat value (the “F” bit) described above.<br />
Note 2.— Although the positional accuracy of the airborne CPR encoding is approximately 5.1 metres in most cases,<br />
the longitude position accuracy may only be approximately 10.0 metres when the latitude is either –87.0 ±1.0 degrees,<br />
or +87 ±1.0 degrees.<br />
A.2.3.2.3.1 Extrapolating position (when T = 1)<br />
If T is set to one, airborne position messages with <strong>for</strong>mat TYPE Codes 9, 10, 20 <strong>and</strong> 21 shall have times of applicability<br />
which are exact 0.2s UTC epochs. In that case, the F bit shall be 0 if the time of applicability is an even-numbered 0.2s<br />
UTC epoch, or 1 if the time of applicability is an odd-numbered 0.2s UTC epoch.<br />
Note.— In such a case, an “even-numbered 0.2s epoch” means an epoch which occurs an even number of 200-ms<br />
time intervals after an even-numbered UTC second. An “odd-numbered 0.2s epoch” means an epoch which occurs an<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-9<br />
odd number of 200-ms time intervals after an even-numbered UTC second. Examples of even-numbered 0.2s UTC<br />
epochs are 12.0s, 12.4s, 12.8s, 13.2s, 13.6s, etc. Examples of odd-numbered UTC epochs are 12.2s, 12.6s, 13.0s,<br />
13.4s, 13.8s, etc.<br />
The CPR-encoded latitude <strong>and</strong> longitude that are loaded into the airborne position register shall comprise an estimate of<br />
the aircraft/vehicle (A/V) position at the time of applicability of that latitude <strong>and</strong> longitude, which is an exact 0.2s UTC<br />
epoch. The register shall be loaded no earlier than 150 ms be<strong>for</strong>e the time of applicability of the data being loaded, <strong>and</strong><br />
no later than 50 ms be<strong>for</strong>e the time of applicability of that data.<br />
This timing shall ensure that the receiving ADS-B system may recover the time of applicability of the data in the airborne<br />
position message, as follows:<br />
1) If F = 0, the time of applicability shall be the nearest even-numbered 0.2s UTC epoch to the time that the<br />
airborne position message is received.<br />
2) If F = 1, the time of applicability shall be the nearest odd-numbered 0.2s UTC epoch to the time that the<br />
airborne position message is received.<br />
Recommendation.— If the airborne position register is updated at its minimum (every 200 ms), that register should<br />
be loaded 100 ms be<strong>for</strong>e the time of applicability. The register should then be reloaded, with data applicable at the next<br />
subsequent 0.2s UTC epoch, 100 ms be<strong>for</strong>e that next subsequent 0.2s epoch.<br />
Note 1.— In this way, the time of transmission of an airborne position message would never differ by more than<br />
100 ms from the time of applicability of the data in that message. By specifying “100 ms ± 50 ms” rather than 100 ms<br />
exactly, some tolerance is allowed <strong>for</strong> variations in implementation.<br />
Note 2.— The position may be estimated by extrapolating the position from the time of validity of the fix (included in<br />
the position fix) to the time of applicability of the data in the register (which, if T = 1, is an exact 0.2s UTC time tick). This<br />
may be done by a simple linear extrapolation using the velocity provided with the position fix <strong>and</strong> the time difference<br />
between the position fix validity time <strong>and</strong> the time of applicability of the transmitted data. Alternatively, other methods of<br />
estimating the position, such as alpha-beta trackers or Kalman filters, may be used.<br />
Every 200 ms, the contents of the position registers shall be updated by estimating the A/V position at the next<br />
subsequent 0.2s UTC epoch. This process shall continue with new position fixes as they become available from the<br />
source of navigation data.<br />
A.2.3.2.3.2 Extrapolating position (when T = 0)<br />
Draft<br />
T shall be set to zero if the time of applicability of the data being loaded into the position register is not synchronized to<br />
any particular UTC epoch. In that case, the position register shall be reloaded with position data at intervals that are no<br />
more than 200 ms apart. The position being loaded into the register shall have a time of applicability that is never more<br />
than 200 ms different from any time during which the register holds that data.<br />
Note.— This may be accomplished by loading the airborne position register at intervals that are, on average, no<br />
more than 200 ms apart, with data <strong>for</strong> which the time of applicability is between the time the register is loaded <strong>and</strong> the<br />
time that it is loaded again. (Shorter intervals than 200 ms are permitted, but not required.)<br />
If T = 0, receiving ADS-B equipment shall accept airborne position messages as being current as of the time of receipt.<br />
The transmitting ADS-B equipment shall reload the airborne position register with updated estimates of the A/V position,<br />
at intervals that are no more than 200 ms apart. The process shall continue with new position reports as they become<br />
available.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-10 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.2.3.2.3.3 Time-out when new position data are unavailable<br />
In the event that the navigation input ceases, the extrapolation described in §A.2.3.2.3.1 <strong>and</strong> §A.2.3.2.3.2 shall be<br />
limited to no more than two seconds. At the end of this time-out of two seconds, all fields of the airborne position<br />
register, except the altitude field, shall be cleared (set to zero). When the appropriate register fields are cleared, the<br />
zero TYPE Code field shall serve to notify ADS-B receiving equipment that the data in the latitude <strong>and</strong> longitude fields<br />
are invalid.<br />
A.2.3.2.4 ALTITUDE<br />
This 12-bit field shall provide the aircraft altitude. Depending on the TYPE Code, this field shall contain either:<br />
1) Barometric altitude encoded in 25- or 100-foot increments (as indicated by the Q bit) or,<br />
2) GNSS height above ellipsoid (HAE).<br />
Barometric altitude shall be interpreted as barometric pressure-altitude, relative to a st<strong>and</strong>ard pressure of 1 013.25<br />
hectopascals (29.92 in Hg). It shall not be interpreted as barometric corrected altitude.<br />
Format TYPE Code 20 to 22 shall be reserved <strong>for</strong> the reporting of GNSS height (HAE) which represents the height<br />
above the surface of the WGS-84 ellipsoid <strong>and</strong> may be used when barometric altitude is not available.<br />
Note.— GNSS altitude (MSL) is not accurate enough <strong>for</strong> use in the position report.<br />
A.2.3.2.5 SINGLE ANTENNA FLAG (SAF)<br />
This 1-bit field shall indicate the type of antenna system that is being used to transmit extended squitters. SAF=1 shall<br />
signify a single transmit antenna. SAF=0 shall signify a dual transmit antenna system.<br />
At any time that the diversity configuration cannot guarantee that both antenna channels are functional, then the single<br />
antenna subfield shall be set to ONE.<br />
A.2.3.2.6 SURVEILLANCE STATUS<br />
Draft<br />
The surveillance status field in the airborne position message <strong>for</strong>mat shall encode in<strong>for</strong>mation from the aircraft’s <strong>Mode</strong> A<br />
code <strong>and</strong> SPI condition indication as specified in Annex 10, Volume IV, §3.1.2.8.6.3.1.1.<br />
A.2.3.3 SURFACE POSITION FORMAT<br />
The surface position squitter shall be <strong>for</strong>matted as specified in the definition of register number 0616 in the following<br />
paragraphs.<br />
A.2.3.3.1 MOVEMENT<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
This 7-bit field shall provide in<strong>for</strong>mation on the ground speed of the aircraft. The minimum update rate of this field, as<br />
well as the ground track (true) field, shall be once per 1.3s, whereas the minimum update rate of all other fields of<br />
register 0616 shall be once per 0.2s. A non-linear scale shall be used as defined in the following table where speeds are<br />
given in km/h <strong>and</strong> kt.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-11<br />
Encoding Meaning Quantization<br />
0 No in<strong>for</strong>mation available<br />
1 Aircraft stopped (ground speed < 0.2315 km/h (0.125 kt))<br />
2 ― 8 0.2315 km/h (0.125 kt) ≤ ground speed < 1.852 km/h (1 kt) (in 0.2315 km/h (0.125 kt) steps)<br />
9 ― 12 1.852 km/h (1 kt) ≤ ground speed < 3.704 km/h (2 kt) (in 0.463 km/h (0.25 kt) steps)<br />
13 ― 38 3.704 km/h (2 kt) ≤ ground speed < 27.78 km/h (15 kt) (in 0.926 km/h (0.5 kt) steps)<br />
39 ― 93 27.78 km/h (15 kt) ≤ ground speed < 129.64 km/h (70 kt) (in 1.852 km/h (1.0 kt) steps)<br />
94 ― 108 129.64 km/h (70 kt) ≤ ground speed < 185.2 km/h (100 kt) (in 3.704 km/h (2.0 kt) steps)<br />
109 ― 123 185.2 km/h (100 kt) ≤ ground speed < 324.1 km/h (175 kt) (in 9.26 km/h (5.0 kt) steps)<br />
124 Ground speed ≥ 324.1 km/h (175 kt)<br />
125 Reserved<br />
126 Reserved<br />
127 Reserved<br />
A.2.3.3.2 GROUND TRACK (TRUE)<br />
A.2.3.3.2.1 Ground track status<br />
This 1-bit field shall define the validity of the ground track value. Coding <strong>for</strong> this field shall be as follows: 0=invalid <strong>and</strong><br />
1=valid. The minimum update rate of this field, as well as the movement field, shall be once per 1.3s, whereas the<br />
minimum update rate of all other fields of register 0616 shall be once per 0.2s.<br />
A.2.3.3.2.2 Ground track value<br />
Draft<br />
This 7-bit (14-20) field shall define the direction (in degrees clockwise from true north) of aircraft motion on the surface.<br />
The ground track shall be encoded as an unsigned angular weighted binary numeral, with an MSB of 180 degrees <strong>and</strong><br />
an LSB of 360/128 degrees, with zero indicating true north. The data in the field shall be rounded to the nearest multiple<br />
of 360/128 degrees.<br />
A.2.3.3.3 COMPACT POSITION REPORTING (CPR) FORMAT (F)<br />
The 1-bit (22) CPR <strong>for</strong>mat field <strong>for</strong> the surface position message shall be encoded as specified <strong>for</strong> the airborne message.<br />
That is, F=0 shall denote an even <strong>for</strong>mat coding, while F=1 shall denote an odd <strong>for</strong>mat coding (see §AC.2.6.7).<br />
A.2.3.3.4 TIME SYNCHRONIZATION (T)<br />
This 1-bit field (21) shall indicate whether or not the time of applicability of the message is synchronized with UTC time.<br />
T = 0 shall denote that the time is not synchronized to UTC. T = 1 shall denote that time of applicability is synchronized<br />
to UTC time. Synchronization shall only be used <strong>for</strong> surface position messages having the top two horizontal position<br />
precision categories (<strong>for</strong>mat TYPE Codes 5 <strong>and</strong> 6).<br />
When T = 1, the time of validity in the surface message <strong>for</strong>mat shall be encoded in the 1-bit F field which (in addition to<br />
CPR <strong>for</strong>mat type) indicates the 0.2s time tick <strong>for</strong> UTC time of position validity. The F bit shall alternate between 0 <strong>and</strong> 1<br />
<strong>for</strong> successive 0.2s time ticks, beginning with F = 0 when the time of applicability is an exact even-numbered UTC<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-12 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
second.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A.2.3.3.5 LATITUDE/LONGITUDE<br />
The latitude/longitude field in the surface message shall be a 34-bit field containing the latitude <strong>and</strong> longitude coding of<br />
the aircraft’s surface position. The latitude (Y) <strong>and</strong> longitude (X) shall each occupy 17 bits. The surface latitude <strong>and</strong><br />
longitude encodings shall contain the low-order 17 bits of the 19-bit CPR-encoded values defined in §AC.2.6.<br />
Note 1.— The unambiguous range <strong>for</strong> local decoding of surface messages is 166.5 km (90 NM). The positional<br />
accuracy maintained by the surface CPR encoding is approximately 1.25 metres. The latitude/longitude encoding is<br />
also a function of the CPR <strong>for</strong>mat value (the “F” bit) described above.<br />
Note 2.— Although the positional accuracy of the surface CPR encoding is approximately 1.25 meters in most<br />
cases, the longitude position accuracy may only be approximately 3.0 meters when the latitude is either –87.0 ±1.0<br />
degrees, or +87 ±1.0 degrees.<br />
A.2.3.3.5.1 Extrapolating position (when T = 1)<br />
This extrapolation shall con<strong>for</strong>m to §A.2.3.2.3.1 (substitute “surface” <strong>for</strong> “airborne” where appropriate).<br />
A.2.3.3.5.2 Extrapolating position (when T = 0)<br />
This extrapolation shall con<strong>for</strong>m to §A.2.3.2.3.2 (substitute “surface” <strong>for</strong> “airborne” where appropriate).<br />
A.2.3.3.5.3 Time-out when new position data are unavailable<br />
This time-out shall con<strong>for</strong>m to §A.2.3.2.3.3 (substitute “surface” <strong>for</strong> “airborne” where appropriate).<br />
Draft<br />
A.2.3.4 IDENTIFICATION AND CATEGORY FORMAT<br />
The identification <strong>and</strong> category squitter shall be <strong>for</strong>matted as specified in the definition of transponder register 0816.<br />
A.2.3.5 AIRBORNE VELOCITY FORMAT<br />
The airborne velocity squitter shall be <strong>for</strong>matted as specified in the definition of transponder register number 0916 <strong>and</strong> in<br />
the following paragraphs.<br />
A.2.3.5.1 SUBTYPES 1 AND 2<br />
Subtypes 1 <strong>and</strong> 2 of the airborne velocity <strong>for</strong>mat shall be used when the transmitting aircraft’s velocity over ground is<br />
known. Subtype 1 shall be used at subsonic velocities while subtype 2 shall be used when the velocity exceeds 1 022 kt.<br />
This message shall not be broadcast if the only valid data are the intent change flag <strong>and</strong> the IFR capability flag (see<br />
§A.2.3.5.3, §A.2.3.5.4). After initialization, the broadcast shall be suppressed by loading register 0916 with all zeros <strong>and</strong><br />
then discontinuing the updating of the register until data input is available again.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-13<br />
The supersonic version of the velocity coding shall be used if either the east-west OR north-south velocities exceed<br />
1 022 kt. A switch to the normal velocity coding shall be made if both the east-west AND north-south velocities drop<br />
below 1 000 kt.<br />
A.2.3.5.2 SUBTYPES 3 <strong>and</strong> 4<br />
Subtypes 3 <strong>and</strong> 4 of the airborne velocity <strong>for</strong>mat shall be used when the transmitting aircraft’s velocity over ground is not<br />
known. These subtypes substitute airspeed <strong>and</strong> heading <strong>for</strong> the velocity over ground. Subtype 3 shall be used at<br />
subsonic velocities, while subtype 4 shall be used when the velocity exceeds 1 022 kt.<br />
This message shall not be broadcast if the only valid data are the intent change flag <strong>and</strong> the IFR capability flag (see<br />
§A.2.3.5.3, §A.2.3.5.4). After initialization, broadcast shall be suppressed by loading register 0916 with all zeros <strong>and</strong> then<br />
discontinuing the updating of the register until data input is available again.<br />
The supersonic version of the velocity coding shall be used if the airspeed exceeds 1 022 kt. A switch to the normal<br />
velocity coding shall be made if the airspeed drops below 1 000 kt.<br />
A.2.3.5.3 INTENT CHANGE FLAG IN AIRBORNE VELOCITY MESSAGES<br />
An intent change event shall be triggered 4 seconds after the detection of new in<strong>for</strong>mation being inserted in registers<br />
4016 to 4216. The code shall remain set <strong>for</strong> 18 ±1 second following an intent change.<br />
Intent change flag coding:<br />
0 = no change in intent<br />
1 = intent change<br />
Note 1.— Register 4316 is not included since it contains dynamic data which will be continuously changing.<br />
Note 2.— A four-second delay is required to provide <strong>for</strong> settling time <strong>for</strong> intent data derived from manually set<br />
devices.<br />
A.2.3.5.4 IFR CAPABILITY FLAG (IFR) IN AIRBORNE VELOCITY MESSAGES<br />
Draft<br />
The IFR capability flag shall be a 1-bit (bit 10) subfield in the subtypes 1, 2, 3 <strong>and</strong> 4 airborne velocity messages. IFR=1<br />
shall signify that the transmitting aircraft has a capability <strong>for</strong> applications requiring ADS-B equipage class A1 or above.<br />
Otherwise, IFR shall be set to 0.<br />
A.2.3.5.5 RESERVED<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A.2.3.5.6 MAGNETIC HEADING IN AIRBORNE VELOCITY MESSAGES<br />
A.2.3.5.6.1 Magnetic heading status<br />
This 1-bit field shall define the availability of the magnetic heading value. Coding <strong>for</strong> this field shall be: 0 = not available<br />
<strong>and</strong> 1 = available.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-14 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.2.3.5.6.2 Magnetic heading value<br />
This 10-bit field shall contain the aircraft magnetic heading (in degrees clockwise from magnetic north) when velocity<br />
over ground is not available. The magnetic heading shall be encoded as an unsigned angular weighted binary numeral<br />
with an MSB of 180 degrees <strong>and</strong> an LSB of 360/1 024 degrees, with zero indicating magnetic north. The data in the<br />
field shall be rounded to the nearest multiple of 360/1 024 degrees.<br />
A.2.3.5.7 DIFFERENCE FROM BAROMETRIC ALTITUDE IN AIRBORNE VELOCITY MESSAGES<br />
This 8-bit field shall contain the signed difference between barometric <strong>and</strong> GNSS altitude. (Coding <strong>for</strong> this field shall be<br />
as indicated in Tables A-2-9a <strong>and</strong> A-2-9b.)<br />
The difference between barometric altitude <strong>and</strong> GNSS height above ellipsoid (HAE) shall be used if available. If GNSS<br />
HAE is not available, GNSS altitude (MSL) shall be used when airborne position is being reported using <strong>for</strong>mat TYPE<br />
Codes 11 through 18.<br />
If airborne position is being reported using <strong>for</strong>mat TYPE Code 9 or 10, only GNSS (HAE) shall be used. For <strong>for</strong>mat<br />
TYPE Code 9 or 10, if GNSS (HAE) is not available, the field shall be coded with all zeros. The basis <strong>for</strong> the barometric<br />
altitude difference (either GNSS (HAE) or GNSS altitude MSL) shall be used consistently <strong>for</strong> the reported difference.<br />
A.2.3.6 STATUS REGISTER FORMAT<br />
The status register shall be <strong>for</strong>matted as specified in the definition of transponder register number 0716 <strong>and</strong> in the<br />
following paragraphs.<br />
A.2.3.6.1 PURPOSE<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Unlike the other extended squitter registers, the contents of this register shall not be broadcast. The purpose of this<br />
register shall be to serve as an interface between the transponder function <strong>and</strong> the general <strong>for</strong>matter/manager function<br />
(GFM, 2.5). The two fields defined <strong>for</strong> this <strong>for</strong>mat shall be the transmission rate subfield <strong>and</strong> the altitude type subfield.<br />
A.2.3.6.2 TRANSMISSION RATE SUBFIELD (TRS)<br />
Draft<br />
This field is only used <strong>for</strong> a transponder implementation of extended squitter.<br />
The TRS shall be used to notify the transponder of the aircraft motion status while on the surface. If the aircraft is<br />
moving, the surface position squitter shall be broadcast at a rate of twice per second, <strong>and</strong> identity squitters at a rate of<br />
once per 5 seconds. If the aircraft is stationary, the surface position squitter shall be broadcast at a rate of once per<br />
5 seconds <strong>and</strong> the identity squitter at a rate of once per 10 seconds.<br />
The algorithm specified in the definition of transponder register number 0716 shall be used by the GFM (2.5) to determine<br />
motion status <strong>and</strong> the appropriate code shall be set in the TRS subfield. The transponder shall examine the TRS<br />
subfield to determine which rate to use when it is broadcasting surface squitters.<br />
A.2.3.6.3 ALTITUDE TYPE SUBFIELD (ATS)<br />
This field shall only be used <strong>for</strong> a transponder implementation of extended squitter.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-15<br />
The transponder shall load the altitude field of the airborne position squitter from the same digital source as used <strong>for</strong><br />
addressed replies.<br />
Note.— This is done to minimize the possibility that the altitude in the squitter is different from the altitude that would<br />
be obtained by direct interrogation.<br />
If the GFM (2.5) inserts GNSS height (HAE) into the airborne position squitter, it shall instruct the transponder not to<br />
insert the barometric altitude into the altitude field. The ATS subfield shall be set to ONE <strong>for</strong> this purpose.<br />
A.2.3.7 EVENT-DRIVEN PROTOCOL<br />
The event-driven protocol register shall be as specified in the definition of transponder register number 0A16 in §A.2.5.5<br />
<strong>and</strong> in the following paragraphs.<br />
A.2.3.7.1 PURPOSE<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
The event-driven protocol shall be used as a flexible means to support the broadcast of messages beyond those defined<br />
<strong>for</strong> position, velocity, <strong>and</strong> identification.<br />
Note.— These typically will be messages that are broadcast regularly <strong>for</strong> a period of time based on the occurrence<br />
of an event. An example is the broadcast of emergency/priority status every second during a declared aircraft<br />
emergency. A second example is the periodic broadcast of intent in<strong>for</strong>mation <strong>for</strong> the duration of the operational<br />
condition.<br />
A.2.3.8 EMERGENCY/PRIORITY STATUS<br />
The emergency/priority status squitter shall be <strong>for</strong>matted as specified in the definition of transponder register number<br />
6116 <strong>and</strong> in the following paragraphs.<br />
A.2.3.8.1 TRANSMISSION RATE<br />
Draft<br />
This message shall be broadcast once per second <strong>for</strong> the duration of the emergency.<br />
A.2.3.8.2 MESSAGE DELIVERY<br />
Message delivery shall be accomplished using the event-driven protocol (see §A.2.3.7). The broadcast of this message<br />
shall take priority over the event-driven protocol broadcast of all other message types, as specified in §A.2.5.5.3.<br />
A.2.3.9 RESERVED<br />
A.2.3.10 RESERVED<br />
A.2.3.11 AIRCRAFT OPERATIONAL STATUS<br />
The aircraft operational status message squitter shall be <strong>for</strong>matted as specified in the definition of register number 6516<br />
<strong>and</strong> in the following paragraphs.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-16 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.2.3.11.1 TRANSMISSION RATE<br />
This message shall be broadcast once per 1.7 seconds <strong>for</strong> the duration of the operation.<br />
A.2.3.11.2 MESSAGE DELIVERY<br />
Message delivery shall be accomplished using the event-driven protocol (see §A.2.3.7).<br />
A.2.3.11.3 EN-ROUTE OPERATIONAL CAPABILITIES (CC-4)<br />
This 4-bit (9-12) subfield shall be used to indicate en-route operational capabilities of the ADS-B transmitting system to<br />
other aircraft as specified by the following encoding.<br />
CC-4 ENCODING: EN-ROUTE OPERATIONAL CAPABILITIES<br />
CC-4 CODING<br />
Bit 9, 10 Bit 11, 12 MEANING<br />
0 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
0 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
Draft<br />
1 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-17<br />
A.2.3.11.4 TERMINAL AREA OPERATIONAL CAPABILITIES (CC-3)<br />
This 4-bit (13-16) subfield shall be used to indicate terminal area operational capabilities of the ADS-B transmitting<br />
system to other aircraft as specified by the following encoding.<br />
CC-3 ENCODING: TERMINAL AREA OPERATIONAL CAPABILITIES<br />
CC-3 CODING<br />
Bit 13, 14 Bit 15, 16 MEANING<br />
0 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
0 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-18 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.2.3.11.5 APPROACH AND LANDING OPERATIONAL CAPABILITIES (CC-2)<br />
This 4-bit (17-20) subfield shall be used to indicate approach <strong>and</strong> l<strong>and</strong>ing operational capabilities of the ADS-B<br />
transmitting system to other aircraft as specified by the following encoding.<br />
CC-2 ENCODING: APPROACH AND LANDING OPERATIONAL CAPABILITIES<br />
CC-2 CODING<br />
Bit 17, 18 Bit 19, 20 MEANING<br />
0 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
0 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-19<br />
A.2.3.11.6 SURFACE OPERATIONAL CAPABILITIES (CC-1)<br />
This 4-bit (21-24) subfield shall be used to indicate surface operational capabilities of the ADS-B transmitting system to<br />
other aircraft as specified by the following encoding.<br />
CC-1 ENCODING: SURFACE OPERATIONAL CAPABILITIES<br />
CC-1 CODING<br />
Bit 21, 22 Bit 23, 24 MEANING<br />
0 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
0 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-20 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.2.3.11.7 EN-ROUTE OPERATIONAL CAPABILITY STATUS (OM-4)<br />
This 4-bit (25-28) subfield shall be used to indicate the en-route operational capability status of the ADS-B transmitting<br />
system to other aircraft as specified by the following encoding.<br />
OM-4 ENCODING: EN-ROUTE OPERATIONAL CAPABILITY STATUS<br />
OM-4 CODING<br />
Bit 25, 26 Bit 27, 28 MEANING<br />
0 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
0 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-21<br />
A.2.3.11.8 TERMINAL AREA OPERATIONAL CAPABILITY STATUS (OM-3)<br />
This 4-bit (29-32) subfield shall be used to indicate the terminal area operational capability status of the ADS-B<br />
transmitting system to other aircraft as specified by the following encoding.<br />
OM-3 ENCODING: TERMINAL AREA OPERATIONAL CAPABILITY STATUS<br />
OM-3 CODING<br />
Bit 29, 30 Bit 31, 32 MEANING<br />
0 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
0 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-22 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.2.3.11.9 APPROACH AND LANDING OPERATIONAL CAPABILITY STATUS (OM-2)<br />
This 4-bit (33-36) subfield shall be used to indicate the approach <strong>and</strong> l<strong>and</strong>ing operational capability status of the ADS-B<br />
transmitting system to other aircraft as specified by the following encoding.<br />
OM-2 ENCODING: APPROACH AND LANDING OPERATIONAL<br />
CAPABILITY STATUS<br />
OM-2 CODING<br />
Bit 33, 34 Bit 35, 36 MEANING<br />
0 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
0 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-23<br />
A.2.3.11.10 SURFACE OPERATIONAL CAPABILITY STATUS (OM-1)<br />
This 4-bit (37-40) subfield shall be used to indicate the surface operational capability status of the ADS-B transmitting<br />
system to other aircraft as specified by the following encoding.<br />
OM-1 ENCODING: SURFACE OPERATIONAL CAPABILITY STATUS<br />
OM1 CODING<br />
Bit 37, 38 Bit 39, 40 MEANING<br />
0 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
0 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 0 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
1 1 0 0 Reserved<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
Draft<br />
A.2.4 EXTENDED SQUITTER INITIALIZATION AND TIME-OUT<br />
Initialization <strong>and</strong> time-out functions <strong>for</strong> extended squitter broadcast shall be per<strong>for</strong>med by the transponder <strong>and</strong> are<br />
specified in Annex 10, Volume IV, §3.1.2.8.6.4 <strong>and</strong> §3.1.2.8.6.6.<br />
Note.— A description of these functions is presented in the following paragraphs to serve as reference material <strong>for</strong><br />
the section on the general <strong>for</strong>matter/manager (GFM) (see §A.2.5).<br />
A.2.4.1 INITIATION OF EXTENDED SQUITTER BROADCAST<br />
At power-up initialization, the transponder shall commence operation in a mode in which it broadcasts only acquisition<br />
squitters. The transponder shall initiate the broadcast of extended squitters <strong>for</strong> airborne position, surface position,<br />
airborne velocity <strong>and</strong> aircraft identification when data are inserted into transponder registers 0516, 0616, 0916 <strong>and</strong> 0816,<br />
respectively. This determination shall be made individually <strong>for</strong> each squitter type. The insertion of altitude or surveillance<br />
status data into transponder register 0516 by the transponder shall not satisfy the minimum requirement <strong>for</strong> broadcast of<br />
the airborne position squitter.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-24 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Note.— This suppresses the transmission of extended squitters from aircraft that are unable to report position,<br />
velocity or identity in<strong>for</strong>mation.<br />
A.2.4.2 REGISTER TIME-OUT<br />
The transponder shall clear all but the altitude <strong>and</strong> surveillance status subfields in the airborne position register<br />
(transponder register 0516) <strong>and</strong> all 56 bits of the surface position, squitter status <strong>and</strong> airborne velocity registers<br />
(transponder registers numbers 0616, 0716 <strong>and</strong> 0916) if these registers are not updated <strong>for</strong> a time no greater than twice<br />
the specified maximum update interval, or 2 seconds (whichever is the greater). This time-out shall be determined<br />
separately <strong>for</strong> each of these registers. The insertion of altitude or surveillance status data by the transponder into these<br />
registers shall not qualify as a register update <strong>for</strong> the purposes of this time-out condition.<br />
Note 1.— These registers are cleared to prevent the reporting of outdated position, velocity <strong>and</strong> squitter rate<br />
in<strong>for</strong>mation.<br />
Note 2.— The identification register, 0816, is not cleared since it contains data that rarely changes in flight <strong>and</strong> is<br />
less not frequently updated (see §A.2.1, Note 3). The event-driven register, 0A16 or equivalent transmit register, does<br />
not need to be cleared since its contents are only broadcast once each time that the register is loaded (see §A.2.5.5).<br />
Refer to §D.2.4.3.3 <strong>for</strong> implementation guidelines regarding Register 0816.<br />
Note 3.— During a register time-out event, the ME field of the extended squitter may contain all zeros, except <strong>for</strong><br />
any data inserted by the transponder.<br />
A.2.4.3 TERMINATION OF EXTENDED SQUITTER BROADCAST<br />
If input to the register <strong>for</strong> a squitter type stops <strong>for</strong> 60 seconds, broadcast of that extended squitter type shall be<br />
discontinued until data insertion is resumed. The insertion of altitude by the transponder satisfies the minimum<br />
requirement <strong>for</strong> continuing to broadcast the airborne position squitter.<br />
Note 1.— Until time-out, a squitter type may contain an ME field of all zeros.<br />
Draft<br />
Note 2.— Continued transmission <strong>for</strong> 60 seconds is required so that receiving aircraft will know that the data source<br />
<strong>for</strong> the message has been lost.<br />
A.2.4.4 REQUIREMENTS FOR NON-TRANSPONDER DEVICES<br />
Non-transponder devices shall provide the same functionality <strong>for</strong> initialization; register time-out <strong>and</strong> broadcast<br />
termination as specified <strong>for</strong> the transponder case in §A.2.4.1 to §A.2.4.3, except that:<br />
a) It shall not broadcast acquisition squitters; <strong>and</strong><br />
b) When the navigation input fails, when operating on the surface it shall continue to broadcast DF=18 with<br />
message TYPE Code = 0 at the high rate specified <strong>for</strong> the surface position message (Annex 10, Volume IV,<br />
§3.1.2.8.6.4.3).<br />
Note.— Continued broadcast of the surface position message is needed to support the operation of surface<br />
multilateration systems.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-25<br />
A.2.5 GENERAL FORMATTER/MANAGER (GFM)<br />
The general <strong>for</strong>matter/manager (GFM) shall <strong>for</strong>mat messages <strong>for</strong> insertion in the transponder registers.<br />
A.2.5.1 NAVIGATION SOURCE SELECTION<br />
The GFM shall be responsible <strong>for</strong> the selection of the default source <strong>for</strong> aircraft position <strong>and</strong> velocity, the comm<strong>and</strong>ed<br />
altitude source, <strong>and</strong> <strong>for</strong> the reporting of the associated position <strong>and</strong> altitude errors.<br />
A.2.5.2 LOSS OF INPUT DATA<br />
The GFM shall be responsible <strong>for</strong> loading the registers <strong>for</strong> which it is programmed at the required update rate. If <strong>for</strong> any<br />
reason data are unavailable, the GFM shall per<strong>for</strong>m the actions specified in §A.2.1.1.<br />
For transponder registers 0516 <strong>and</strong> 0616, a loss of position data shall cause the GFM to set the <strong>for</strong>mat TYPE Code to<br />
zero as the means of indicating “no position data” since all zeros in the latitude/longitude fields is a legal value.<br />
A.2.5.3 SPECIAL PROCESSING FOR FORMAT TYPE CODE ZERO<br />
A.2.5.3.1 SIGNIFICANCE OF FORMAT TYPE CODE EQUAL TO ZERO<br />
Format TYPE Code = 0 shall signify “no position in<strong>for</strong>mation”. This shall be used when the latitude/longitude in<strong>for</strong>mation<br />
is not available or invalid <strong>and</strong> still permit the reporting of barometric altitude loaded by the transponder.<br />
Note 1.— The principal use of this message is to provide ACAS the ability to passively receive altitude.<br />
Note 2.— Special h<strong>and</strong>ling is required <strong>for</strong> the airborne <strong>and</strong> surface position messages because a CPR encoded<br />
value of all zeros in the latitude/longitude field is a valid value.<br />
A.2.5.3.2 BROADCAST OF FORMAT TYPE CODE EQUAL TO ZERO<br />
Format TYPE Code = 0 shall only be set by the following events:<br />
Draft<br />
1) An extended squitter register monitored by the transponder (registers 0516, 0616, 0716 <strong>and</strong> 0916) has timed out<br />
(see §A.2.4.2). In this case, the transponder shall clear the entire 56 bits of the register that timed out. In the<br />
case of the airborne position register, the altitude subfield shall only be zeroed if no altitude data are available.<br />
Transmission of the extended squitter that broadcasts the timed out register shall itself stop in 60 seconds.<br />
Broadcast of this extended squitter shall resume when the GFM begins to insert data into the register.<br />
2) The GFM determines that all navigation sources that can be used <strong>for</strong> the extended squitter airborne or surface<br />
position message are either missing or invalid. In this case, the GFM shall clear the <strong>for</strong>mat TYPE Code <strong>and</strong> all<br />
other fields of the airborne or surface position message <strong>and</strong> insert this zeroed message in the appropriate<br />
register. This shall only be done once so that the transponder can detect the loss of data insertion <strong>and</strong><br />
suppress the broadcast of the related squitter.<br />
Note.— In all of the above cases, a <strong>for</strong>mat TYPE Code of zero contains a message of all zeros. The only exception<br />
is the airborne position <strong>for</strong>mat that may contain barometric altitude <strong>and</strong> surveillance status data as set by the<br />
transponder. There is no analogous case <strong>for</strong> the other extended squitter message types, since a zero value in any of<br />
the fields indicates no in<strong>for</strong>mation.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-26 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.2.5.3.3 RECEPTION OF FORMAT TYPE CODE EQUAL TO ZERO<br />
An extended squitter containing <strong>for</strong>mat TYPE Code equal to zero shall not be used to initiate an ADS-B track.<br />
Note.— If a squitter with <strong>for</strong>mat TYPE Code equal to zero is received <strong>and</strong> if altitude is present it can be used to<br />
update altitude of an existing ADS-B track.<br />
A.2.5.4 TRANSPONDER CAPABILITY REPORTING<br />
The GFM shall be responsible <strong>for</strong> setting the transponder capability registers numbers 1016, <strong>and</strong> 1816 to 1C16. It shall<br />
also clear individual bits in register number 1716 in the event of a loss of a data source or an application.<br />
A particular bit shall remain set if at least one field in the corresponding register message is being updated.<br />
A.2.5.4.1 COMMON USAGE CAPABILITY REPORT (REGISTER NUMBER 1716)<br />
A bit in register number 1716 shall be cleared if there is a loss of corresponding input data (see §A.2.5.2), <strong>for</strong> all data<br />
fields of the register, <strong>and</strong> shall be set when data insertion into the register resumes. Bit 36 of register 1016 shall be<br />
toggled to indicate a change of capability.<br />
A.2.5.4.2 MODE S SPECIFIC SERVICES CAPABILITY REPORT<br />
A.2.5.4.2.1 <strong>Mode</strong> S specific services GICB capability report (registers numbers 1816 to 1C16)<br />
A bit set in one of these registers shall indicate that the service loading the register indicated by that bit has been<br />
installed on the aircraft. In this regard, these bits shall not be cleared to reflect a real-time loss of an application, as is<br />
done <strong>for</strong> register 1716.<br />
Draft<br />
A.2.5.4.2.2 <strong>Mode</strong> S specific services MSP capability report (registers numbers 1D16 to 1F16)<br />
Each bit shall indicate that the MSP it represents requires service when set to 1.<br />
A.2.5.4.3 TRANSPONDER MONITORING<br />
As indicated in §A.2.4, the transponder’s role in this process shall be to serve as a backup in the event of the loss of<br />
GFM functionality. For this reason, the transponder shall:<br />
1) clear the extended squitter registers (0516, 0616, 0716 <strong>and</strong> 0916) if they have not been updated <strong>for</strong> a time no<br />
greater than twice the specified maximum update interval, or 2 seconds (whichever is the greater).<br />
2) clear all of the registers loaded by the GFM if it detects a loss of GFM capability (e.g., a bus failure). In this<br />
case, it would also clear all of the bits in register number 1716 since a bit in this register means “application<br />
installed <strong>and</strong> operational”.<br />
The transponder shall not clear the other capability registers numbers (1816 to 1C16) since they are intended to mean<br />
only “application installed”.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-27<br />
A.2.5.5 HANDLING OF EVENT-DRIVEN PROTOCOL<br />
The event-driven interface protocol provides a general purpose interface into the transponder function <strong>for</strong> messages<br />
beyond those that are regularly transmitted all the time (provided input data are available). This protocol shall operate<br />
by having the transponder broadcast a message once each time the event-driven register is loaded by the GFM.<br />
Note.— This gives the GFM complete freedom in setting the update rate (up to a maximum) <strong>and</strong> duration of<br />
broadcast <strong>for</strong> applications such as emergency status <strong>and</strong> intent reporting.<br />
In addition to <strong>for</strong>matting, the GFM shall control the timing of message insertion so that it provides the necessary pseudor<strong>and</strong>om<br />
timing variation <strong>and</strong> does not exceed the maximum transponder broadcast rate <strong>for</strong> the event-driven protocol.<br />
A.2.5.5.1 TRANSPONDER SUPPORT FOR EVENT-DRIVEN MESSAGES<br />
A message shall only be transmitted once by the transponder each time that register number 0A16 is loaded.<br />
Transmission shall be delayed if the transponder is busy at the time of insertion.<br />
Note 1.— Delay times are short. They are usually a maximum of several milliseconds <strong>for</strong> the longest transponder<br />
transaction.<br />
The maximum transmission rate <strong>for</strong> the event-driven protocol shall be limited by the transponder to twice per second. If a<br />
message is inserted in the event-driven register <strong>and</strong> cannot be transmitted due to rate limiting, it shall be held <strong>and</strong><br />
transmitted when the rate limiting condition has cleared. If a new message is received be<strong>for</strong>e transmission is permitted,<br />
it shall overwrite the earlier message.<br />
Note 2.— The squitter transmission rate <strong>and</strong> the duration of squitter transmissions are application dependent.<br />
A.2.5.5.1.1 Recommendation.— The minimum rate <strong>and</strong> duration consistent with the needs of the application should<br />
be chosen.<br />
A.2.5.5.2 GFM USE OF EVENT-DRIVEN PROTOCOL<br />
Draft<br />
An application that selects the event-driven protocol shall notify the GFM of the <strong>for</strong>mat type <strong>and</strong> required update rate.<br />
The GFM shall then locate the necessary input data <strong>for</strong> this <strong>for</strong>mat type <strong>and</strong> begin inserting data into register number<br />
0A16 at the required rate. The GFM shall also insert this message into the register <strong>for</strong> this <strong>for</strong>mat type. This register<br />
image shall be maintained to allow read-out of this in<strong>for</strong>mation by air-ground or air-air register read-out. When broadcast<br />
of a <strong>for</strong>mat type ceases, the GFM shall clear the corresponding register assigned to this message.<br />
The maximum rate that shall be supported by the event-driven protocol is twice per second from one or a collection of<br />
applications. For each event-driven <strong>for</strong>mat type being broadcast, the GFM shall retain the time of the last insertion into<br />
register number 0A16. The next insertion shall be scheduled at a r<strong>and</strong>om interval that shall be uni<strong>for</strong>mly distributed over<br />
the range of the update interval ±0.1 second (using a time quantization no greater than 15 ms) relative to the previous<br />
insertion into register number 0A16 <strong>for</strong> this <strong>for</strong>mat type.<br />
The GFM shall monitor the number of insertions scheduled in any one second interval. If more than two would occur, it<br />
shall add a delay as necessary to ensure that the limit of two messages per second is observed.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-28 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.2.5.5.3 EVENT-DRIVEN PRIORITY<br />
If the event-driven message transmission rate must be reduced in order not to exceed the maximum rate specified in<br />
§A.2.5.5.2, transmission priority shall be assigned as follows:<br />
1) If the emergency/priority status message (see §A.2.3.8) is active, it shall be transmitted at the specified rate of<br />
once per second. Other active event-driven messages shall be assigned equal priority <strong>for</strong> the remaining<br />
capacity.<br />
2) If the emergency/priority status message is not active, transmission priority shall be allocated equally to all<br />
active event-driven messages.<br />
A.2.5.6 DERIVATION OF MODE FIELD BITS FOR AIRCRAFT INTENTION PARAMETERS<br />
For aircraft architectures that do not present the GFM with a dedicated status word (containing the mode field definitions<br />
associated with aircraft intention parameters), the GFM shall derive the status from each of the appropriate FCC status<br />
words in order to set the respective bits in each of the mode fields of the register number 4016.<br />
A.2.6 LATITUDE/LONGITUDE CODING USING COMPACT POSITION REPORTING (CPR)<br />
A.2.6.1 PRINCIPLE OF THE CPR ALGORITHM<br />
The <strong>Mode</strong> S extended squitters use compact position reporting (CPR) to encode latitude <strong>and</strong> longitude efficiently into<br />
messages, as specified in §C.2.6.<br />
Notes.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1. The resulting messages are compact in the sense that several higher-order bits, which are normally constant <strong>for</strong><br />
long periods of time, are not transmitted in every message. For example, in a direct binary representation of latitude,<br />
one bit would designate whether the aircraft is in the northern or southern hemisphere. This bit would remain<br />
constant <strong>for</strong> a long time, possibly the entire life of the aircraft. To repeatedly transmit this bit in every position<br />
message would be inefficient.<br />
Draft<br />
2. Because the higher-order bits are not transmitted, it follows that multiple locations on the earth will produce the<br />
same encoded position. If only a single position message were received, the decoding would involve ambiguity as<br />
to which of the multiple solutions is the correct location of the aircraft. The CPR technique includes a provision to<br />
enable a receiving system to unambiguously determine the location of the aircraft. This is done by encoding in two<br />
ways that differ slightly. The two <strong>for</strong>mats, called even-<strong>for</strong>mat <strong>and</strong> odd-<strong>for</strong>mat, are each transmitted 50 per cent of<br />
the time. Upon reception of both types within a short period (approximately 10 seconds), the receiving system can<br />
unambiguously determine the location of the aircraft.<br />
3. Once this process has been carried out, the higher-order bits are known at the receiving station, so subsequent<br />
single message receptions serve to unambiguously indicate the location of the aircraft as it moves.<br />
4. In certain special cases, a single reception can be decoded into the correct location without an even/odd pair. This<br />
decoding is based on the fact that the multiple locations are spaced by at least 360 NM. In addition to the correct<br />
locations, the other locations are separated by integer multiples of 360 NM to the north <strong>and</strong> south <strong>and</strong> also integer<br />
multiples of 360 NM to the east <strong>and</strong> west. In a special case in which it is known that reception is impossible beyond<br />
a range of 180 NM, the nearest solution is the correct location of the aircraft.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-29<br />
5. The parameter values in the preceding paragraph (360 <strong>and</strong> 180 NM) apply to the airborne CPR encoding. For<br />
aircraft on the surface, the CPR parameters are smaller by a factor of 4. This encoding yields better resolution but<br />
reduces the spacing of the multiple solutions.<br />
A.2.6.2 CPR ALGORITHM PARAMETERS AND INTERNAL FUNCTIONS<br />
The CPR algorithm shall utilize the following parameters whose values are set as follows <strong>for</strong> the <strong>Mode</strong> S extended<br />
squitter application:<br />
a) The number of bits used to encode a position coordinate, Nb, is set as follows:<br />
Nb = 17 <strong>for</strong> airborne encoding used in the ADS-B airborne position message <strong>and</strong> the TIS-B fine airborne<br />
message,<br />
Nb = 19 <strong>for</strong> surface encoding used in the ADS-B surface position message <strong>and</strong> the TIS-B fine surface position<br />
message,<br />
Nb = 14 <strong>for</strong> intent encoding,<br />
Nb = 12 <strong>for</strong> TIS-B encoding, used in the TIS-B coarse airborne position message.<br />
Note 1.— The Nb parameter determines the encoded position precision (approximately 5 m <strong>for</strong> the<br />
airborne encoding, 1.25 m <strong>for</strong> the surface encoding, <strong>and</strong> 41 m <strong>for</strong> the intent encoding <strong>and</strong> 164 m <strong>for</strong> the TIS-B<br />
encoding).<br />
b) The number of geographic latitude zones between the equator <strong>and</strong> a pole, denoted NZ, is set to 15.<br />
Note 2.— The NZ parameter determines the unambiguous airborne range <strong>for</strong> decoding (360 NM). The<br />
surface latitude/longitude encoding omits the high-order 2 bits of the 19 bit CPR encoding, so the effective<br />
unambiguous range <strong>for</strong> surface position reports is 90 NM.<br />
Draft<br />
The CPR algorithm shall define internal functions to be used in the encoding <strong>and</strong> decoding processes.<br />
c) The notation floor(x) denotes the floor of x, which is defined as the greatest integer value k such that k
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-30 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
d) The notation |x| denotes the absolute value of x, which is defined as the value x when x>0 <strong>and</strong> the value –x<br />
when x +87 degrees, NL = 1<br />
For lat < -87 degrees, NL = 1<br />
Draft<br />
Note 5.— This equation <strong>for</strong> NL( ) is impractical <strong>for</strong> real-time implementation. A table of transition latitudes<br />
can be pre-computed using the following equation:<br />
⎛ ⎛ π ⎞ ⎞<br />
⎜ 1−cos⎜ ⎟ ⎟<br />
180° ⎜ ⎝2⋅NZ lat = ⋅arccos<br />
⎠ ⎟ <strong>for</strong> NL = 2 to 4⋅NZ –1<br />
π ⎜ ⎛ 2π<br />
⎞ ⎟<br />
⎜ 1−cos ⎜ ⎜ ⎟ ⎟<br />
⎝ ⎠ ⎟<br />
⎝<br />
NL<br />
⎠<br />
<strong>and</strong> a table search procedure used to obtain the return value <strong>for</strong> NL( ). The table value <strong>for</strong> NL = 1 is 90<br />
degrees. When using the look-up table established by using the equation above, the NL value is not expected<br />
to change to the next lower NL value until the boundary (latitude established by the above equation) has<br />
actually been crossed when moving from the equator towards the pole.<br />
A.2.6.3 CPR ENCODING PROCESS<br />
The CPR encoding process shall calculate the encoded position values XZi <strong>and</strong> YZi <strong>for</strong> either airborne, surface intent or<br />
TIS-B latitude <strong>and</strong> longitude fields from the global position lat (latitude in degrees), lon (longitude in degrees), <strong>and</strong> the<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-31<br />
CPR encoding type i (0 <strong>for</strong> even <strong>for</strong>mat <strong>and</strong> 1 <strong>for</strong> odd <strong>for</strong>mat), by per<strong>for</strong>ming the following sequence of computations.<br />
The CPR encoding <strong>for</strong> intent shall always use the even <strong>for</strong>mat (i = 0), whereas the airborne, surface <strong>and</strong> TIS-B encoding<br />
shall use both even (i = 0) <strong>and</strong> odd (i = 1) <strong>for</strong>mats.<br />
a) Dlati (the latitude zone size in the N-S direction) is computed from the equation:<br />
360°<br />
Dlati<br />
=<br />
4 ⋅ NZ − i<br />
b) YZi (the Y-coordinate within the Zone) is then computed from Dlati <strong>and</strong> lat using separate equations:<br />
For Nb=17 encoding:<br />
For Nb=19 encoding:<br />
For Nb=14 encoding:<br />
For Nb=12 encoding:<br />
( lat Dlat )<br />
⎛ 17 MOD , i 1 ⎞<br />
YZi<br />
= floor ⎜<br />
2 ⋅ + ⎟<br />
Dlati<br />
2 ⎟<br />
⎝ ⎠<br />
( lat Dlat )<br />
⎛ 19 MOD , i 1 ⎞<br />
YZi<br />
= floor ⎜<br />
2 ⋅ + ⎟<br />
Dlati<br />
2 ⎟<br />
⎝ ⎠<br />
YZ<br />
0<br />
( lat Dlat )<br />
⎛ 14 MOD , 0 1 ⎞<br />
= floor ⎜<br />
2 ⋅ + ⎟<br />
Dlat 2 ⎟<br />
⎝ 0 ⎠<br />
( lat Dlat )<br />
⎛ 12 MOD , i 1 ⎞<br />
YZi<br />
= floor ⎜<br />
2 ⋅ + ⎟<br />
Dlati<br />
2 ⎟<br />
⎝ ⎠<br />
c) Rlati (the latitude that a receiving ADS-B system will extract from the transmitted message) is then computed<br />
from lat, YZi, <strong>and</strong> Dlati using separate equations:<br />
⎛YZ ⎛ i lat ⎞⎞<br />
For Nb=17 encoding: Rlati = Dlati<br />
⋅ ⎜ + floor<br />
⎜ 17 ⎜ ⎟⎟<br />
2 Dlat ⎟<br />
⎝ ⎝ i ⎠⎠<br />
⎛YZ ⎛ i lat ⎞⎞<br />
For Nb=19 encoding: Rlati = Dlati<br />
⋅ ⎜ + floor<br />
⎜ 19 ⎜ ⎟⎟<br />
2 Dlat ⎟<br />
⎝ ⎝ i ⎠⎠<br />
Draft<br />
⎛YZ ⎛ 0 lat ⎞⎞<br />
For Nb=14 encoding: Rlat0 = Dlat0⋅<br />
⎜ + floor<br />
⎜ 14 ⎜ ⎟⎟<br />
2 Dlat ⎟<br />
⎝ ⎝ 0 ⎠⎠<br />
⎛YZ ⎛ i lat ⎞⎞<br />
For Nb=12 encoding Rlati = Dlati<br />
⋅ ⎜ + floor<br />
⎜ 12 ⎜ ⎟⎟<br />
2 Dlat ⎟<br />
⎝ ⎝ i ⎠⎠<br />
d) Dloni (the longitude zone size in the E-W direction) is then computed from Rlati using the equation:<br />
⎧ 360°<br />
⎪<br />
, when NL ( Rlati ) − i > 0<br />
⎪NL<br />
( Rlati ) − i<br />
Dloni<br />
= ⎨<br />
⎪ 360 ° , when NL ( Rlati ) − i = 0<br />
⎪<br />
⎩<br />
Note.— When per<strong>for</strong>ming the NL function, the encoding process must ensure that the NL value is<br />
established in accordance with Note 5 of §A.2.6.2.f.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-32 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
e) XZi (the X-coordinate within the Zone) is then computed from lon <strong>and</strong> Dloni using separate equations:<br />
For Nb=17 encoding:<br />
For Nb=19 encoding:<br />
For Nb=14 encoding:<br />
For Nb=12 encoding:<br />
( lon Dlon )<br />
⎛ 17 MOD , i 1 ⎞<br />
XZi<br />
= floor ⎜<br />
2 ⋅ + ⎟<br />
Dloni<br />
2 ⎟<br />
⎝ ⎠<br />
( lon Dlon )<br />
⎛ 19 MOD , i 1 ⎞<br />
XZi<br />
= floor ⎜<br />
2 ⋅ + ⎟<br />
Dloni<br />
2 ⎟<br />
⎝ ⎠<br />
XZ<br />
0<br />
( lon Dlon )<br />
⎛ 14 MOD , 0 1 ⎞<br />
= floor ⎜<br />
2 ⋅ + ⎟<br />
Dlon 2 ⎟<br />
⎝ 0 ⎠<br />
( lon Dlon )<br />
⎛ 12 MOD , i 1 ⎞<br />
XZi<br />
= floor ⎜<br />
2 ⋅ + ⎟<br />
Dloni<br />
2 ⎟<br />
⎝ ⎠<br />
f) Finally, limit the values of XZi <strong>and</strong> YZi to fit in the 17-bit or 14-bit field allotted to each coordinate:<br />
For Nb=17 encoding:<br />
For Nb=19 encoding:<br />
17 ( )<br />
17 ( )<br />
YZ = MOD YZ ,2 ,<br />
i i<br />
XZ = MOD XZ ,2<br />
i i<br />
17 ( )<br />
17 ( )<br />
YZ = MOD YZ ,2 ,<br />
i i<br />
XZ = MOD XZ ,2<br />
i i<br />
For Nb=14 encoding: 14<br />
YZ0 = MOD ( YZ0,2)<br />
,<br />
14<br />
XZ0 = MOD ( XZ0,2)<br />
For Nb=12 encoding: 12<br />
YZi = MOD ( YZi,2)<br />
,<br />
12<br />
XZi = MOD ( XZi,2)<br />
Draft<br />
A.2.6.4 LOCALLY UNAMBIGUOUS CPR DECODING<br />
The CPR algorithm shall decode a geographic position (latitude, Rlati, <strong>and</strong> longitude, Rloni,) that is locally unambiguous<br />
with respect to a reference point (lats, lons) known to be within 180 NM of the true airborne position (or within 45 NM <strong>for</strong><br />
a surface message).<br />
Note.— This reference point may be a previously tracked position that has been confirmed by global decoding (see<br />
§A.2.6.7) or it may be the own-aircraft position, which would be used <strong>for</strong> decoding a new tentative position report.<br />
The encoded position coordinates XZi <strong>and</strong> YZi <strong>and</strong> the CPR encoding type i (0 <strong>for</strong> the even encoding <strong>and</strong> 1 <strong>for</strong> the odd<br />
encoding) contained in a <strong>Mode</strong> S extended squitter message shall be decoded by per<strong>for</strong>ming the sequence of<br />
computations given in §A.2.6.5 <strong>for</strong> the airborne intent <strong>and</strong> TIS-B <strong>for</strong>mat types <strong>and</strong> in §A.2.6.6 <strong>for</strong> the surface <strong>for</strong>mat type.<br />
A.2.6.5 LOCALLY UNAMBIGUOUS AIRBORNE POSITION DECODING<br />
The following computations shall be per<strong>for</strong>med to obtain the locally ambiguous decoded latitude/longitude <strong>for</strong> the<br />
airborne intent <strong>and</strong> TIS-B message <strong>for</strong>mats. For the intent <strong>for</strong>mat, i will always be set to 0 (even encoding), whereas the<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-33<br />
airborne <strong>for</strong>mat shall use both even (i = 0) <strong>and</strong> odd (i = 1) encoding. For the airborne <strong>and</strong> fine TIS-B <strong>for</strong>mats, Nb shall<br />
equal 17, <strong>for</strong> the intent <strong>for</strong>mat, Nb shall equal 14 <strong>and</strong> <strong>for</strong> the coarse TIS-B <strong>for</strong>mat, Nb shall equal 12.<br />
a) Dlati is computed from the equation:<br />
360°<br />
Dlati<br />
=<br />
4 ⋅ NZ − i<br />
b) The latitude zone index number, j, is then computed from the values of lats, Dlati <strong>and</strong> YZi using the equation:<br />
( lat Dlat )<br />
⎛ lat ⎞ ⎛1MOD s, s i YZ ⎞ i<br />
j = floor ⎜ ⎟+ floor ⎜ Nb<br />
Dlat ⎜<br />
+ − ⎟<br />
i 2 Dlati<br />
2 ⎟<br />
⎝ ⎠ ⎝ ⎠<br />
c) The decoded position latitude, Rlati, is then computed from the values of j, Dlati, <strong>and</strong> YZi using the equation:<br />
⎛ YZi<br />
⎞<br />
Rlati = Dlati ⋅ ⎜ j + Nb ⎟<br />
⎝ 2 ⎠<br />
d) Dloni (the longitude zone size in the E-W direction) is then computed from Rlati using the equation:<br />
⎧ 360°<br />
⎪<br />
, when NL ( Rlati ) − i > 0<br />
⎪NL<br />
( Rlati ) − i<br />
Dloni<br />
= ⎨<br />
⎪ 360 ° , when NL ( Rlati ) − i = 0<br />
⎪<br />
⎩<br />
Note.— When per<strong>for</strong>ming the NL function, the encoding process must ensure that the NL value is<br />
established in accordance with Note 5 of §A.2.6.2.f.<br />
e) The longitude zone coordinate m is then computed from the values of lons, Dloni, <strong>and</strong> XZi using the equation:<br />
( lon Dlon )<br />
⎛ lon ⎞ ⎛1MOD s, s i XZ ⎞ i<br />
m = floor ⎜ ⎟+ floor ⎜ Nb<br />
Dlon ⎜<br />
+ − ⎟<br />
i 2 Dloni<br />
2 ⎟<br />
⎝ ⎠ ⎝ ⎠<br />
Draft<br />
f) The decoded position longitude, Rloni, is then computed from the values of m, XZi, <strong>and</strong> Dloni using the equation:<br />
⎛ XZi<br />
⎞<br />
Rloni = Dloni ⋅ ⎜m+ Nb ⎟<br />
⎝ 2 ⎠<br />
A.2.6.6 LOCALLY UNAMBIGUOUS SURFACE POSITION DECODING<br />
The following computations shall be per<strong>for</strong>med to obtain the decoded latitude <strong>and</strong> longitude <strong>for</strong> the surface position<br />
<strong>for</strong>mat.<br />
a) Dlati is computed from the equation:<br />
90°<br />
Dlati<br />
=<br />
4 ⋅ NZ − i<br />
b) The latitude zone index, j, is then computed from the values of lats, Dlati <strong>and</strong> YZi using the equation:<br />
( lat Dlat )<br />
⎛ lat ⎞ ⎛1MOD ,<br />
s s i YZ ⎞ i<br />
j = floor ⎜ ⎟+ floor ⎜ 17<br />
Dlat ⎜<br />
+ − ⎟<br />
i 2 Dlati<br />
2 ⎟<br />
⎝ ⎠ ⎝ ⎠<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-34 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
c) The decoded position latitude, Rlati, is then computed from the values of j, Dlati, <strong>and</strong> YZi using the equation:<br />
⎛ YZi<br />
⎞<br />
Rlati = Dlati ⋅ ⎜ j + 17 ⎟<br />
⎝ 2 ⎠<br />
d) Dloni (the longitude zone size, in the E-W direction) is then computed from Rlati using the equation:<br />
⎧ 90°<br />
⎪<br />
, when NL ( Rlati ) − i > 0<br />
⎪NL<br />
( Rlati ) − i<br />
Dloni<br />
= ⎨<br />
⎪ 90 ° , when NL ( Rlati ) − i = 0<br />
⎪<br />
⎩<br />
Note.— When per<strong>for</strong>ming the NL function, the encoding process must ensure that the NL value is<br />
established in accordance with Note 5 of §A.2.6.2.f.<br />
e) The longitude zone coordinate m is then computed from the values of lons, Dloni, <strong>and</strong> XZi using the equation:<br />
( lon Dlon )<br />
⎛ lon ⎞ ⎛1MOD ,<br />
s s i XZ ⎞ i<br />
m = floor ⎜ ⎟+ floor ⎜ 17<br />
Dlon ⎜<br />
+ − ⎟<br />
i 2 Dloni<br />
2 ⎟<br />
⎝ ⎠ ⎝ ⎠<br />
f) The decoded position longitude, Rloni, is then computed from the values of m, XZi, <strong>and</strong> Dloni using the equation:<br />
⎛ XZi<br />
⎞<br />
Rloni = Dloni ⋅ ⎜m+ 17 ⎟<br />
⎝ 2 ⎠<br />
A.2.6.7 GLOBALLY UNAMBIGUOUS AIRBORNE POSITION DECODING<br />
The CPR algorithm shall utilize one airborne-encoded “even” <strong>for</strong>mat reception (denoted XZ0, YZ0), together with one<br />
airborne-encoded “odd” <strong>for</strong>mat reception (denoted XZ1, YZ1), to regenerate the global geographic position latitude, Rlat,<br />
<strong>and</strong> longitude, Rlon. The time between the “even” <strong>and</strong> “odd” <strong>for</strong>mat encoded position reports shall be no longer than<br />
10 seconds.<br />
Draft<br />
Note 1.— This algorithm might be used to obtain globally unambiguous position reports <strong>for</strong> aircraft out of the range<br />
of ground sensors, whose position reports are coming via satellite data links. It might also be applied to ensure that local<br />
positions are being correctly decoded over long ranges from the receiving sensor.<br />
Note 2.— The time difference limit of 10 seconds between the even- <strong>and</strong> odd-<strong>for</strong>mat position reports is determined<br />
by the maximum permitted separation of 3 NM. Positions greater than 3 NM apart cannot be used to solve a unique<br />
global position. An aircraft capable of a speed of 1 852 km/h (1 000 kt) will fly about 5.1 km (2.8 NM) in 10 seconds.<br />
There<strong>for</strong>e, the CPR algorithm will be able to unambiguously decode its position over a 10-second delay between<br />
position reports.<br />
As airborne-<strong>for</strong>mat messages are initially received from a particular aircraft, if there is no established track on this<br />
aircraft, then a global decode shall be per<strong>for</strong>med using even <strong>and</strong> odd <strong>for</strong>mat receptions, as described in this section.<br />
Note 3.— If the aircraft has been transmitting surface <strong>for</strong>mat messages <strong>and</strong> their receptions were in track, then it is<br />
not necessary to use even-odd decoding. Beginning with the first individual airborne message reception, the location can<br />
be decoded using the local decode technique, based on the previous target location as the reference.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-35<br />
Given a 17-bit airborne position encoded in the “even” <strong>for</strong>mat (XZ0, YZ0) <strong>and</strong> another encoded in the “odd” <strong>for</strong>mat (XZ1,<br />
YZ1), separated by no more than 10 seconds (= 3 NM), the CPR algorithm shall regenerate the geographic position from<br />
the encoded position reports by per<strong>for</strong>ming the following sequence of steps:<br />
a) Compute Dlat0 <strong>and</strong> Dlat1 from the equation:<br />
b) Compute the latitude index:<br />
360°<br />
Dlati<br />
=<br />
4 ⋅ NZ − i<br />
⎛59 ⋅YZ0 −60⋅YZ1 1 ⎞<br />
j = floor ⎜ +<br />
17<br />
2 2<br />
⎟<br />
⎝ ⎠<br />
c) Compute the values of Rlat0 <strong>and</strong> Rlat1 using the following equation:<br />
⎛ YZi<br />
⎞<br />
Rlati = Dlati ⋅⎜MOD ( j,60 − i ) + 17 ⎟<br />
⎝ 2 ⎠<br />
Southern hemisphere values of Rlati will fall in the range from 270° to 360°. Subtract 360° from such values,<br />
thereby restoring Rlati to the range from –90° to +90°.<br />
d) If NL(Rlat0) is not equal to NL(Rlat1) then the two positions straddle a transition latitude, thus a solution <strong>for</strong><br />
global longitude is not possible. Wait <strong>for</strong> positions where they are equal.<br />
e) If NL(Rlat0) is equal to NL(Rlat1) then proceed with computation of Dloni i, according to whether the most<br />
recently received airborne position message was encoded with the even <strong>for</strong>mat (i = 0) or the odd <strong>for</strong>mat (i = 1):<br />
f) Compute m, the longitude index:<br />
360°<br />
Dloni<br />
=<br />
n<br />
where ni = greater of [NL(Rlati) – i] <strong>and</strong> 1.<br />
i<br />
Draft<br />
( )<br />
⎛ XZ0⋅ NL −1− XZ1⋅NL 1 ⎞<br />
m = floor ⎜<br />
+<br />
17<br />
⎟<br />
2<br />
2 ⎟<br />
⎝ ⎠<br />
where NL = NL(Rlati).<br />
g) Compute the global longitude, Rlon0 or Rlon1, according to whether the most recently received airborne position<br />
message was encoded using the even <strong>for</strong>mat (that is, with i = 0) or the odd <strong>for</strong>mat (i = 1):<br />
⎛ XZi<br />
⎞<br />
Rloni = Dloni ⋅ ⎜MOD ( m, ni)<br />
+ 17 ⎟<br />
⎝ 2 ⎠<br />
where ni = greater of [NL(Rlati) – i] <strong>and</strong> 1.<br />
h) A reasonableness test is applied to the resulting decoded position in accordance with §A.2.7.2.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-36 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.2.6.8 GLOBALLY UNAMBIGUOUS SURFACE POSITION DECODING<br />
This algorithm shall utilize one CPR surface position encoded “even” <strong>for</strong>mat message together with one CPR surface<br />
position encoded “odd” <strong>for</strong>mat message, to regenerate the geographic position of the aircraft or target.<br />
As surface-<strong>for</strong>mat messages are initially received from a particular aircraft, if there is no established track on this aircraft,<br />
then a global decode shall be per<strong>for</strong>med using even <strong>and</strong> odd <strong>for</strong>mat receptions, as described in this section.<br />
Note 1.— If the aircraft has been transmitting airborne <strong>for</strong>mat messages <strong>and</strong> their receptions were in track, then it is<br />
not necessary to use even-odd decoding. Beginning with the first individual surface message reception, the location can<br />
be decoded using the local-decode technique, based on the previous target location as the reference.<br />
Note 2.— Even if the aircraft is appearing <strong>for</strong> the first time in surface <strong>for</strong>mat receptions, any single message could<br />
be decoded by itself into multiple locations, one being the correct location of the transmitting aircraft, <strong>and</strong> all of the others<br />
being separated by 90 NM or more from the correct location. There<strong>for</strong>e, if it were known that the transmitting aircraft<br />
cannot be farther away than 45 NM from a known location, then the first received message could be decoded using the<br />
locally unambiguous decoding method described in §A.2.6.6. Under some circumstances it may be possible <strong>for</strong> an<br />
aircraft to be first detected when it is transmitting surface position messages farther than 45 NM away from the receiving<br />
station. For this reason, even-odd decoding is required when messages are initially received from a particular aircraft.<br />
After this initial decode, as subsequent messages are received, they can be decoded individually (without using the<br />
even-odd technique), provided that the intervening time is not excessive. This subsequent decoding is based on the fact<br />
that the aircraft location has not changed by more than 45 NM between each new reception <strong>and</strong> the previously decoded<br />
location.<br />
The even-odd decoding process shall begin by identifying a pair of receptions, one in the “even” <strong>for</strong>mat, the other in the<br />
“odd” <strong>for</strong>mat, <strong>and</strong> whose separation in time does not exceed the time interval of X seconds, where X=50 seconds,<br />
unless the Ground Speed in either Surface Position Message is greater than 25 knots, or is unknown, in which cases<br />
X=25 seconds.<br />
Note 3.— The limit of 25 seconds is based on the possible change of location within this time interval. Detailed<br />
analysis of CPR indicates that if the change of location is 0.75 NM or less, then the decoding will yield the correct<br />
location of the aircraft. To assure that the change of location is actually no larger, <strong>and</strong> considering the maximum aircraft<br />
speed of 100 knots specified <strong>for</strong> the transmission of the surface <strong>for</strong>mat, the combination indicates that 25 seconds will<br />
provide the needed assurance. For targets on the airport surface when speeds are much less <strong>and</strong> the transmission rate<br />
is as low as one per 5 seconds, the corresponding time limit is 50 seconds.<br />
Draft<br />
Given a CPR 17-bit surface position encoded in the “even” <strong>for</strong>mat (XZ0, YZ0) <strong>and</strong> another encoded in the “odd” <strong>for</strong>mat<br />
(XZ1, YZ1), separated by no more than X seconds, the algorithm shall regenerate the geographic position (latitude Rlat,<br />
<strong>and</strong> longitude Rlon) of the aircraft or target by per<strong>for</strong>ming the following sequence of steps:<br />
a) Compute the latitude zone sizes Dlat0 <strong>and</strong> Dlat1 from the equation:<br />
b) Compute the latitude index:<br />
90°<br />
Dlati<br />
=<br />
60 − i<br />
⎛59 ⋅YZo −60YZ1<br />
1 ⎞<br />
j = floor ⎜ +<br />
17<br />
2 2<br />
⎟<br />
⎝ ⎠<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-37<br />
c) Latitude. The following <strong>for</strong>mulas will yield two mathematical solutions <strong>for</strong> latitude (<strong>for</strong> each value of i), one in the<br />
northern hemisphere <strong>and</strong> the other in the southern hemisphere. Compute the northern hemisphere solution of<br />
Rlat0 <strong>and</strong> Rlat1 using the following equation:<br />
⎛ YZi<br />
⎞<br />
Rlati = Dlati ⎜MOD( j,60− i ) + 17 ⎟<br />
⎝ 2 ⎠<br />
The southern hemisphere value is the above value minus 90 degrees.<br />
To determine the correct latitude of the target, it is necessary to make use of the location of the receiver. Only<br />
one of the two latitude values will be consistent with the known receiver location, <strong>and</strong> this is the correct latitude<br />
of the transmitting aircraft.<br />
d) The first step in longitude decoding is to check that the even-odd pair of messages do not straddle a transition<br />
latitude. It is rare, but possible, that NL(Rlat0) is not equal to NL(Rlati). If so, a solution <strong>for</strong> longitude cannot be<br />
calculated. In this event, ab<strong>and</strong>on the decoding of this even-odd pair, <strong>and</strong> examine further receptions to identify<br />
another pair. Per<strong>for</strong>m the decoding computations up to this point <strong>and</strong> check that these two NL values are equal.<br />
When that is true, proceed with the following decoding steps.<br />
e) Compute the longitude zone size Dloni, according to whether the most recently received surface position<br />
message was encoded with the even <strong>for</strong>mat (i = 0) or the odd <strong>for</strong>mat (i = 1):<br />
f) Compute m, the longitude index:<br />
90°<br />
Dloni<br />
=<br />
n , where ni is the greater of [NL(Rlati ) – i] <strong>and</strong> 1.<br />
i<br />
( )<br />
⎛ XZ0⋅ NL −1) − XZ1⋅NL 1 ⎞<br />
m = floor ⎜<br />
+<br />
17<br />
⎟<br />
2<br />
2 ⎟<br />
⎝ ⎠<br />
where NL = NL (Rlati)<br />
Draft<br />
g) Longitude. The following <strong>for</strong>mulas will yield four mathematical solutions <strong>for</strong> longitude (<strong>for</strong> each value of i), one<br />
being the correct longitude of the aircraft, <strong>and</strong> the other three separated by at least 90 degrees. To determine<br />
the correct location of the target, it will be necessary to make use of the location of the receiver. Compute the<br />
longitude, Rlon0 or Rlon1, according to whether the most recently received surface position message was<br />
encoded using the even <strong>for</strong>mat (that is, with i = 0) or the odd <strong>for</strong>mat (i = 1):<br />
⎛ XZi ⎞<br />
Rloni = Dloni ⋅ ⎜MOD ( m, ni)<br />
+ 17 ⎟<br />
⎝ 2 ⎠<br />
where ni = greater of [NL(Rlati) – i] <strong>and</strong> 1.<br />
This solution <strong>for</strong> Rloni will be in the range 0° to 90°. The other three solutions are 90°, 180°, <strong>and</strong> 270° to the<br />
east of this first solution.<br />
To then determine the correct longitude of the transmitting aircraft, it is necessary to make use of the known<br />
location of the receiver. Only one of the four mathematical solutions will be consistent with the known receiver<br />
location, <strong>and</strong> this is the correct longitude of the transmitting aircraft.<br />
Note.— Near the equator the minimum distance between the multiple longitude solutions is more than<br />
5 000 NM, so there is no question as to the correct longitude. For locations away from the equator, the distance<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-38 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
between solutions is less, <strong>and</strong> varies according to the cosine of latitude. For example at 87 degrees latitude,<br />
the minimum distance between solutions is 280 NM. This is sufficiently large to provide assurance that the<br />
correct aircraft location will always be obtained. Currently no airports exist within 3 degrees of either pole, so<br />
the decoding as specified here will yield the correct location of the transmitting aircraft <strong>for</strong> all existing airports.<br />
h) A reasonableness test is applied to the resulting decoded position in accordance with §A.2.7.2.<br />
A.2.6.9.1 OVERVIEW<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A.2.6.9 CPR DECODING OF RECEIVED POSITION MESSAGES<br />
The techniques described in the preceding paragraphs (locally <strong>and</strong> globally unambiguous decoding) shall be used<br />
together to decode the latitude/longitude contained in airborne, surface, intent <strong>and</strong> TIS-B position messages. The<br />
process shall begin with globally unambiguous decoding based upon the receipt of an even <strong>and</strong> an odd encoded<br />
position squitter. Once the globally unambiguous position is determined, emitter centered decoding shall be used to<br />
support subsequent decoding based upon a single position report, either even or odd encoding.<br />
A.2.6.9.2 EMITTER CENTERED LOCAL DECODING<br />
In this approach, the most recent position of the emitter shall be used as the basis <strong>for</strong> the local decoding.<br />
Note.— This produces an unambiguous decoding at each update since the transmitting aircraft cannot move more<br />
than 180 NM between position updates.<br />
A.2.7 REASONABLENESS TEST FOR CPR DECODING OF RECEIVED POSITION MESSAGES<br />
A.2.7.1 OVERVIEW<br />
Draft<br />
Note.— Although receptions of position messages will normally lead to a successful target position determination, it<br />
is necessary to safeguard against position messages that would be used to initiate or update a track with an erroneous<br />
position. A reasonableness test applied to the computed position resulting from receipt of a position message can be<br />
used to discard erroneous position updates. Since an erroneous globally unambiguous CPR decode could potentially<br />
exist <strong>for</strong> the life of a track, a reasonableness test <strong>and</strong> validation of the position protects against such occurrences.<br />
A.2.7.2 REASONABLENESS TEST APPLIED TO POSITIONS DETERMINED<br />
FROM GLOBALLY UNAMBIGUOUS DECODING<br />
A reasonableness test shall be applied to a position computed using the globally unambiguous CPR decoding per<br />
§A.2.6.7 <strong>for</strong> airborne participants or per §A.2.6.8 <strong>for</strong> surface participants. Upon receipt of the even or odd encoded<br />
position message that completes the globally unambiguous CPR decode, the receiver shall per<strong>for</strong>m a reasonableness<br />
test on the position decode by the following:<br />
If the receiver position is known, calculate the distance between the decoded position <strong>and</strong> the receiver position <strong>and</strong><br />
verify that the distance is less than the maximum operating range. If the validation fails, the receiver shall discard the<br />
decoded position, the even <strong>and</strong> odd position messages used to per<strong>for</strong>m the globally unambiguous CPR decode, <strong>and</strong><br />
reinitiate the globally unambiguous CPR decode process.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-39<br />
A further validation of the globally unambiguous CPR decode, passing the above test, shall be per<strong>for</strong>med by the<br />
computation of a second globally unambiguous CPR decode based on reception of a new odd <strong>and</strong> an even position<br />
message as per §A.2.6.7 <strong>for</strong> an airborne participant or per §A.2.6.8 <strong>for</strong> a surface participant, both received subsequent<br />
to the respective odd <strong>and</strong> even position message used in the globally unambiguous CPR decode under validation. Upon<br />
accomplishing the additional globally unambiguous CPR decode, this decoded position <strong>and</strong> the position from the locally<br />
unambiguous CPR decode resulting from the most recently received position message shall be checked to be identical<br />
to within 5 m <strong>for</strong> an airborne decode <strong>and</strong> 1.25 m <strong>for</strong> a surface decode. If the two positions are not identical to within this<br />
tolerance, the validation is failed <strong>and</strong> the initial globally unambiguous CPR decode under validation shall be discarded<br />
<strong>and</strong> the track shall be reinitialized.<br />
Note.— The position obtained from the initial global CPR decode is subsequently updated using local CPR<br />
decoding, until an independent odd <strong>and</strong> even message pair has been received. When this occurs a second global CPR<br />
decode is per<strong>for</strong>med. The resulting position is compared to the position update obtained from the local CPR decode<br />
using the most recently received message. These two positions should agree since they are computed from the same<br />
message.<br />
A.2.7.3 REASONABLENESS TEST APPLIED TO POSITIONS DETERMINED<br />
FROM LOCALLY UNAMBIGUOUS DECODING<br />
A reasonableness test shall be per<strong>for</strong>med to verify that the new position does not represent an unreasonable offset from<br />
the previous aircraft position. If an unreasonable offset is detected, the local decode shall not be used to update the<br />
track.<br />
Note 1.— An unreasonable offset can result from an undetected error in the received position message.<br />
Note 2.— Although the 24-bit aircraft address <strong>for</strong> every aircraft is required to be unique, if situations arise where<br />
multiple aircraft within range of a receiver are transmitting the same 24-bit aircraft address, loss of detection of aircraft<br />
can result from per<strong>for</strong>ming the above reasonableness test. To safeguard against this, the position data that failed the<br />
reasonableness test can be used to support detection <strong>and</strong> reporting of a duplicate address track. Since data transmitted<br />
from aircraft with duplicate addresses can not always be easily <strong>and</strong> reliably distinguished, receivers that support<br />
detection <strong>and</strong> tracking of duplicate addresses are expected to appropriately identify these as duplicate address reports.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-40 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.2.7 TABLES FOR SECTION A.2<br />
Tables are numbered A-2-X where “X” is the decimal equivalent of the BDS code Y,Z where Y is the BDS1 code <strong>and</strong> Z<br />
is the BDS2 code, used to access the data <strong>for</strong>mat <strong>for</strong> a particular register.<br />
The following tables are not included in this document because they are used by communications protocols, or reserved<br />
<strong>and</strong> not yet defined:<br />
A-2-1<br />
A-2-2 to A-2-4 (Used by the linked Comm-B protocol)<br />
A-2-13 to A-2-14 (Reserved <strong>for</strong> air/air state in<strong>for</strong>mation)<br />
A-2-15 (Reserved <strong>for</strong> ACAS)<br />
A-2-17 to A-2-22<br />
A-2-35 (Reserved <strong>for</strong> antenna position)<br />
A-2-36 (Reserved <strong>for</strong> aircraft parameters)<br />
A-2-38 to A-2-47<br />
A-2-49 to A-2-63<br />
A-2-70 to A-2-71<br />
A-2-73 to A-2-79<br />
A-2-87 to A-2-94<br />
A-2-98 to A-2-100<br />
A-2-102 to A-2-111 (Reserved <strong>for</strong> extended squitter)<br />
A-2-112 to A-2-224<br />
A-2-225 to A-2-226 (Reserved <strong>for</strong> <strong>Mode</strong> S BITE)<br />
A-2-231 232 to A-2-233<br />
A-2-235 to A-2-240<br />
A-2-243 to A-2-255<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-41<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-5. BDS code 0,5 — <strong>Extended</strong> squitter airborne position<br />
1 MSB<br />
2 FORMAT TYPE CODE<br />
3<br />
4<br />
(specified in §A.2.3.1)<br />
5 LSB<br />
6 MSB SURVEILLANCE STATUS<br />
7 LSB (specified in §A.2.3.2.6)<br />
8 SINGLE ANTENNA FLAG (SAF) (specified in §A.2.3.2.5)<br />
9<br />
10<br />
11<br />
MSB<br />
12 ALTITUDE<br />
13<br />
14<br />
15<br />
(specified by the FORMAT TYPE CODE)<br />
16 This is (1) the altitude code (AC) as specified in<br />
17 §3.1.2.6.5.4 of Annex 10, Volume IV, but with the<br />
18<br />
19<br />
M-bit removed, or (2) the GNSS height (HAE)<br />
20 LSB<br />
21 TIME (T) (specified in §A.2.3.2.2)<br />
22 CPR FORMAT (F) (specified in §A.2.3.2.1)<br />
23<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29<br />
MSB<br />
30 ENCODED LATITUDE<br />
31<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
(CPR airborne <strong>for</strong>mat specified in §AC.2.6)<br />
39 LSB<br />
40<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
MSB<br />
47 ENCODED LONGITUDE<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
(CPR airborne <strong>for</strong>mat specified in §AC.2.6)<br />
56 LSB<br />
PURPOSE: To provide accurate airborne position in<strong>for</strong>mation.<br />
Surveillance status shall be coded as follows:<br />
0 = No condition<br />
1 = Permanent alert (emergency condition)<br />
2 = Temporary alert (change in <strong>Mode</strong> A identity code other<br />
than emergency condition)<br />
3 = SPI condition<br />
Codes 1 <strong>and</strong> 2 shall take precedence over code 3.<br />
When horizontal position in<strong>for</strong>mation is unavailable, but altitude<br />
in<strong>for</strong>mation is available, the airborne position message shall be<br />
transmitted with a <strong>for</strong>mat TYPE Code of ZERO (0) in bits 1 — 5<br />
<strong>and</strong> the barometric pressure altitude in bits 9 to 20. If neither<br />
horizontal position nor barometric altitude in<strong>for</strong>mation is available,<br />
then all 56 bits of transponder register 0516 shall be zeroed. The<br />
ZERO <strong>for</strong>mat TYPE Code field shall indicate that latitude <strong>and</strong><br />
longitude in<strong>for</strong>mation is unavailable, while the ZERO altitude field<br />
shall indicate that altitude in<strong>for</strong>mation is unavailable.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-42 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-6. BDS code 0,6 — <strong>Extended</strong> squitter surface position<br />
1 MSB PURPOSE: To provide accurate surface position in<strong>for</strong>mation.<br />
2 FORMAT TYPE CODE<br />
3<br />
4<br />
(specified in §A.2.3.1)<br />
5 LSB<br />
6<br />
7<br />
MSB<br />
8 MOVEMENT<br />
9<br />
10<br />
11<br />
(specified in §A.2.3.3.1)<br />
12 LSB<br />
13 STATUS <strong>for</strong> ground track: 0 = Invalid, 1 = Valid<br />
14<br />
15<br />
MSB = 180 degrees<br />
16 GROUND TRACK (TRUE)<br />
17<br />
18<br />
19<br />
(specified in §A.2.3.3.2)<br />
20 LSB = 360/128 degrees<br />
21 TIME (T) (specified in §A.2.3.3.4)<br />
22 CPR FORMAT (F) (specified in §A.2.3.3.3)<br />
23<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29<br />
MSB<br />
30 ENCODED LATITUDE 17 bits<br />
31<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
(CPR surface <strong>for</strong>mat specified in §AC.2.6)<br />
39 LSB<br />
40<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
MSB<br />
47 ENCODED LONGITUDE 17 bits<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
(CPR surface <strong>for</strong>mat specified in §AC.2.6)<br />
56 LSB<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-43<br />
MB FIELD<br />
1 MSB TRANSMISSION RATE<br />
2<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
LSB SUBFIELD (TRS)<br />
3 ALTITUDE TYPE SUBFIELD (ATS)<br />
4<br />
5<br />
6<br />
7<br />
8<br />
9<br />
10<br />
11<br />
12<br />
13<br />
14<br />
15<br />
16<br />
17<br />
18<br />
19<br />
20<br />
21<br />
22<br />
23<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29<br />
30 RESERVED<br />
31<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
47<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56<br />
Table A-2-7. BDS Code 0,7 — <strong>Extended</strong> squitter status<br />
PURPOSE: To provide in<strong>for</strong>mation on the capability <strong>and</strong> status<br />
of the extended squitter rate of the transponder.<br />
Transmission rate subfield (TRS) shall be coded as follows:<br />
0 = No capability to determine surface squitter rate<br />
1 = High surface squitter rate selected<br />
2 = Low surface squitter rate selected<br />
3 = Reserved<br />
Altitude type subfield (ATS) shall be coded as follows:<br />
0 = Barometric altitude<br />
1 = GNSS height (HAE)<br />
Aircraft determination of surface squitter rate:<br />
For aircraft that have the capability to automatically determine their<br />
surface squitter rate, the method used to switch between the high <strong>and</strong><br />
low transmission rates shall be as follows:<br />
a) Switching from high to low rate: Aircraft shall switch from high to low<br />
rate when the on-board navigation unit reports that the aircraft’s<br />
position has not changed more than 10 metres in any 30 second<br />
interval. The algorithm used to control the squitter rate shall save the<br />
aircraft’s position at the time that low rate is selected.<br />
b) Switching from low to high rate: Aircraft shall switch from low to high<br />
rate as soon as the aircraft’s position has changed by 10 metres or<br />
more since the low rate was selected.<br />
For transponder-based implementations, the automatically selected<br />
transmission rate shall be subject to being overridden by comm<strong>and</strong>s<br />
received from the ground control.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-44 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-8. BDS code 0,8 — <strong>Extended</strong> squitter aircraft identification <strong>and</strong> category<br />
1 MSB<br />
2 FORMAT TYPE CODE<br />
3 (specified in §A.2.3.1)<br />
4<br />
5 LSB<br />
6 MSB<br />
7 AIRCRAFT CATEGORY<br />
8 LSB<br />
9 MSB<br />
10<br />
11 CHARACTER 1<br />
12<br />
13<br />
14 LSB<br />
15 MSB<br />
16<br />
17 CHARACTER 2<br />
18<br />
19<br />
20 LSB<br />
21 MSB<br />
22<br />
23 CHARACTER 3<br />
24<br />
25<br />
26 LSB<br />
27 MSB<br />
28<br />
29 CHARACTER 4<br />
30<br />
31<br />
32 LSB<br />
33 MSB<br />
34<br />
35 CHARACTER 5<br />
36<br />
37<br />
38 LSB<br />
39 MSB<br />
40<br />
41 CHARACTER 6<br />
42<br />
43<br />
44 LSB<br />
45 MSB<br />
46<br />
47 CHARACTER 7<br />
48<br />
49<br />
50 LSB<br />
51 MSB<br />
52<br />
53 CHARACTER 8<br />
54<br />
55<br />
56 LSB<br />
PURPOSE: To provide aircraft identification <strong>and</strong> category.<br />
Note.— Since there is no internationally agreed criteria <strong>for</strong> wake vortex<br />
categorization, code 4 (set “A”) is interpreted as indicating a medium<br />
category aircraft exhibiting higher than typical wake vortex characteristics.<br />
Format type shall be coded as follows:<br />
1 = Identification aircraft, category set D<br />
2 = Identification aircraft, category set C<br />
3 = Identification aircraft, category set B<br />
4 = Identification aircraft, category set A<br />
Aircraft/vehicle category shall be coded as follows:<br />
Set A:<br />
Set B:<br />
Set C:<br />
0 = No aircraft category in<strong>for</strong>mation<br />
1 = Light (< 15 500 lbs or 7 031 kg)<br />
2 = Medium 1 (>15 500 to 75 000 lbs, or 7 031 to 34 019 kg)<br />
3 = Medium 2 (>75 000 to 300 000 lbs, or 34 019 to 136 078 kg)<br />
4 = High vortex aircraft<br />
5 = Heavy (> 300 000 lbs or 136 078 kg)<br />
6 = High per<strong>for</strong>mance (> 5g acceleration) <strong>and</strong> high speed (> 400 kt)<br />
7 = Rotorcraft<br />
0 = No aircraft category in<strong>for</strong>mation<br />
1 = Glider/sailplane<br />
2 = Lighter-than-air<br />
3 = Parachutist/skydiver<br />
4 = Ultralight/hang-glider/paraglider<br />
5 = Reserved<br />
6 = Unmanned aerial vehicle<br />
7 = Space/transatmospheric vehicle<br />
0 = No aircraft category in<strong>for</strong>mation<br />
1 = Surface vehicle — emergency vehicle<br />
2 = Surface vehicle — service vehicle<br />
3 = Fixed ground or tethered obstruction<br />
4 – 7 = Reserved<br />
Draft<br />
Set D: Reserved<br />
Aircraft identification coding (characters 1 – 8) shall be:<br />
As specified in Table A-2-32.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-45<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-9a. BDS code 0,9 — <strong>Extended</strong> squitter airborne velocity<br />
(Subtypes 1 <strong>and</strong> 2: Velocity over ground)<br />
1 MSB 1<br />
PURPOSE: To provide additional state in<strong>for</strong>mation <strong>for</strong> both<br />
2 0<br />
normal <strong>and</strong> supersonic flight.<br />
3 FORMAT TYPE CODE = 19 0<br />
4 1 Subtype shall be coded as follows:<br />
5 LSB 1<br />
6 SUBTYPE 1 0 SUBTYPE 2 0 Code Velocity Type<br />
7 0 1 0 Reserved<br />
8<br />
9<br />
1<br />
INTENT CHANGE FLAG (specified in §A.2.3.5.3)<br />
0 1<br />
2<br />
GroundSpeed<br />
Normal<br />
Supersonic<br />
10<br />
11<br />
IFR CAPABILITY FLAG<br />
MSB NAVIGATION UNCERTAINTY<br />
3<br />
4<br />
Airspeed,Heading<br />
Normal<br />
Supersonic<br />
12 CATEGORY FOR VELOCITY 5 Reserved<br />
13 LSB (NUCR) 6 Reserved<br />
14 DIRECTION BIT <strong>for</strong> E-W Velocity: 0 = East, 1 = West 7 Reserved<br />
15 EAST — WEST VELOCITY<br />
16 NORMAL: LSB = 1 knot SUPERSONIC: LSB = 4 knots IFR capability shall be coded as follows:<br />
17<br />
18<br />
19<br />
All zeros = no velocity in<strong>for</strong>mation<br />
Value Velocity<br />
1 0 kt<br />
All zeros = no velocity in<strong>for</strong>mation<br />
Value Velocity<br />
1 0 kt<br />
0 = Transmitting aircraft has no capability <strong>for</strong> ADS-Bbased<br />
conflict detection or higher level (class A1 or<br />
above) applications.<br />
20 2 1 kt 2 4 kt<br />
21<br />
22<br />
23<br />
3<br />
…<br />
1 022<br />
2 kt<br />
…<br />
1 021 kt<br />
3<br />
…<br />
1 022<br />
8 kt<br />
…<br />
4 084 kt<br />
1 = Transmitting aircraft has capability <strong>for</strong> ADS-B-based<br />
conflict detection <strong>and</strong> higher level (class A1 or<br />
above) applications.<br />
24 1 023 >1 021.5 kt 1 033 >4 086 kt<br />
25 DIRECTION BIT <strong>for</strong> N-S Velocity: 0 = North, 1 = South<br />
26 NORTH — SOUTH VELOCITY NUCR shall be coded as follows:<br />
27 NORMAL: LSB = 1 knot SUPERSONIC: LSB = 4 knots<br />
28 All zeros = no velocity in<strong>for</strong>mation All zeros = no velocity in<strong>for</strong>mation<br />
Horizontal<br />
Vertical<br />
29<br />
30<br />
Value<br />
1<br />
Velocity<br />
0 kt<br />
Value<br />
1<br />
Velocity<br />
0 kt<br />
NUCR Velocity<br />
Error (95%)<br />
Velocity<br />
Error (95%)<br />
31 2 1 kt 2 4 kt 0 Unknown Unknown<br />
32 3 2 kt 3 8 kt 1 < 10 m/s < 15.2 m/s (50 fps)<br />
33 … … … … 2 < 3 m/s < 4.6 m/s (15 fps)<br />
34 1 022 1 021 kt 1 022 4 084 kt 3 < 1 m/s < 1.5 m/s (5 fps)<br />
35 1 023 >1 021.5 kt 1 023 >4 086 kt 4 < 0.3 m/s < 0.46 m/s (1.5 fps)<br />
36 SOURCE BIT FOR VERTICAL RATE: 0 = GNSS, 1 = Baro<br />
37 SIGN BIT FOR VERTICAL RATE: 0 = Up, 1 = Down<br />
38 VERTICAL RATE<br />
39 All zeros = no vertical rate in<strong>for</strong>mation; LSB = 64 ft/min<br />
40 Value Vertical Rate<br />
41 1 0 ft/min<br />
42 2 64 ft/min<br />
43 … …<br />
44 510 32 576 ft/min<br />
45<br />
46<br />
511 >32 608 ft/min<br />
47<br />
48<br />
RESERVED FOR TURN INDICATOR<br />
49 GNSS ALT. SIGN BIT: 0 = Above baro alt., 1 = Below baro alt.<br />
50 GNSS ALT. DIFFERENCE FROM BARO. ALT.<br />
51 All zeros = no in<strong>for</strong>mation; LSB = 25 ft<br />
52 Value Difference<br />
53 1 0 ft<br />
54 2 25 ft<br />
55 126 3 125 ft<br />
56 127 3 137.5 ft<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-46 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-9b. BDS code 0,9 — <strong>Extended</strong> squitter airborne velocity<br />
(Subtypes 3 <strong>and</strong> 4: Airspeed <strong>and</strong> heading)<br />
1 MSB 1 PURPOSE: To provide additional state in<strong>for</strong>mation <strong>for</strong> both<br />
2 0 normal <strong>and</strong> supersonic flight based on airspeed <strong>and</strong> heading.<br />
3 FORMAT TYPE CODE = 19 0<br />
4 1 Subtype shall be coded as follows:<br />
5 LSB 1<br />
6 SUBTYPE 3 0 SUBTYPE 4 1 Code Velocity Type<br />
7 1 0 0 Reserved<br />
8<br />
9<br />
1<br />
INTENT CHANGE FLAG (specified in §A.2.3.5.3)<br />
0 1<br />
2<br />
GroundSpeed<br />
Normal<br />
Supersonic<br />
10<br />
11<br />
IFR CAPABILITY FLAG<br />
MSB NAVIGATION UNCERTAINTY<br />
3<br />
4<br />
Airspeed,Heading<br />
Normal<br />
Supersonic<br />
12 CATEGORY FOR VELOCITY 5 Reserved<br />
13 LSB (NUCR) 6 Reserved<br />
14 STATUS BIT: 0 = Magnetic heading not available, 1 = available 7 Reserved<br />
15 MSB = 180 degrees<br />
16<br />
IFR capability shall be coded as follows:<br />
17<br />
18<br />
19<br />
20<br />
MAGNETIC HEADING<br />
(specified in §A.2.3.5.6)<br />
0 = Transmitting aircraft has no capability <strong>for</strong> ADS-B-based<br />
conflict detection or higher level (class A1 or above)<br />
applications.<br />
21<br />
22<br />
23<br />
1 = Transmitting aircraft has capability <strong>for</strong> ADS-B-based<br />
conflict detection <strong>and</strong> higher level (class A1 or above)<br />
applications.<br />
24 LSB = 360/1 024 degrees<br />
25 AIRSPEED TYPE: 0 = IAS, 1 = TAS<br />
26 AIRSPEED NUCR shall be coded as follows:<br />
27 NORMAL: LSB = 1 knot SUPERSONIC: LSB = 4 knots<br />
28<br />
29<br />
All zeros = no velocity in<strong>for</strong>mation<br />
Value Velocity<br />
All zeros = no velocity in<strong>for</strong>mation<br />
Value Velocity<br />
Horizontal<br />
Velocity<br />
Vertical<br />
Velocity<br />
30 1 0 kt 1 0 kt NUCR Error (95%) Error (95%)<br />
31 2 1 kt 2 4 kt 0 Unknown Unknown<br />
32 3 2 kt 3 8 kt 1 < 10 m/s < 15.2 m/s (50 fps)<br />
33 … … … … 2 < 3 m/s < 4.6 m/s (15 fps)<br />
34 1 022 1 021 kt 1 022 4 084 kt 3 < 1 m/s < 1.5 m/s (5 fps)<br />
35 1 023 >1 021.5 kt 1 023 >4 086 kt 4 < 0.3 m/s < 0.46 m/s (1.5 fps)<br />
36 SOURCE BIT FOR VERTICAL RATE: 0 = GNSS, 1 = Baro<br />
37 SIGN BIT FOR VERTICAL RATE: 0 = Up, 1 = Down<br />
38 VERTICAL RATE<br />
This <strong>for</strong>mat shall only be used if velocity over ground<br />
39 All zeros = no vertical rate in<strong>for</strong>mation; LSB = 64 ft/min<br />
is not available.<br />
40 Value Vertical Rate<br />
41 1 0 ft/min<br />
42 2 64 ft/min<br />
43 … …<br />
44 510 32 576 ft/min<br />
45<br />
46<br />
511 >32 608 ft/min<br />
47<br />
48<br />
RESERVED FOR TURN INDICATOR<br />
49 DIFFERENCE SIGN BIT (0 = Above baro alt, 1 = Below baro alt.)<br />
50 GEOMETRIC HEIGHT DIFFERENCE FROM BARO. ALT.<br />
51 All zeros = no in<strong>for</strong>mation; LSB = 25 ft<br />
52 Value Difference<br />
53 1 0 ft<br />
54 2 25 ft<br />
55 126 3 125 ft<br />
56 127 >3 137.5 ft<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-47<br />
MB FIELD<br />
1<br />
2<br />
3<br />
4<br />
5<br />
6<br />
7<br />
8<br />
9<br />
10<br />
11<br />
12<br />
13<br />
14<br />
15<br />
16<br />
17<br />
18<br />
19<br />
20<br />
21<br />
22<br />
23<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29<br />
30<br />
31<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
47<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-10. BDS code 0,A — <strong>Extended</strong> squitter event-driven in<strong>for</strong>mation<br />
PURPOSE: To provide a flexible means to squitter messages<br />
other than position, velocity <strong>and</strong> identification.<br />
1) A message inserted in this register (or an equivalent transmit buffer)<br />
shall be broadcast once by the transponder at the earliest<br />
opportunity.<br />
2) Formats <strong>for</strong> messages using this protocol shall be specified in<br />
transponder registers 6116 to 6F16., except <strong>for</strong> Registers 6216 <strong>and</strong><br />
6516.<br />
3) The GFM (§A.2.5) shall be responsible <strong>for</strong> ensuring pseudo-r<strong>and</strong>om<br />
timing <strong>and</strong> <strong>for</strong> observing the maximum transmission rate <strong>for</strong> this<br />
register of 2 per second (§A.2.5.5.1).<br />
4) Read-out (if required) of this register shall be accomplished by<br />
extracting the contents of the appropriate transponder registers 6116<br />
<strong>and</strong> 6F16.<br />
Note.—The data in this register is not intended <strong>for</strong> extraction using<br />
GICB or ACAS cross-link protocols. The read out of this register is<br />
discouraged since the contents are indeterminate.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-48 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-11. BDS code 0,B — Air/air state in<strong>for</strong>mation 1 (aircraft state)<br />
1 STATUS<br />
2 MSB = 1 024 knots<br />
3<br />
4<br />
5 TRUE AIR SPEED<br />
6<br />
7<br />
8 Range = [0, 2 047] knots<br />
9<br />
10<br />
11<br />
12 LSB = 1.0 knot<br />
13 SWITCH (0 = Magnetic heading, 1 = True heading)<br />
14 STATUS<br />
15 SIGN<br />
16 MSB = 90 degrees<br />
17<br />
18 HEADING<br />
19<br />
20<br />
21 Range = [–180, +180] degrees<br />
22<br />
23<br />
24 LSB = 360/1 024 degrees<br />
25 STATUS<br />
26 SIGN<br />
27 MSB = 90 degrees<br />
28<br />
29<br />
30<br />
31 TRUE TRACK ANGLE<br />
32<br />
33<br />
34<br />
35<br />
36 Range = [–180, +180] degrees<br />
37<br />
38<br />
39<br />
40 LSB = 360/32 768 degrees<br />
41 STATUS<br />
42 MSB = 1 024 knots<br />
43<br />
44<br />
45<br />
46 GROUND SPEED<br />
47<br />
48<br />
49<br />
50<br />
51 Range = [0, 2 048] knots<br />
52<br />
53<br />
54<br />
55 LSB = 1/8 knot<br />
56 RESERVED<br />
PURPOSE: To report threat aircraft state in<strong>for</strong>mation in order<br />
to improve the ability of ACAS to evaluate the threat <strong>and</strong> select<br />
a resolution manoeuvre.<br />
Note.— Two’s complement coding is used <strong>for</strong> all signed fields as<br />
specified in §A.2.2.2.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-49<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-12. BDS code 0,C — Air/air state in<strong>for</strong>mation 2 (aircraft intent)<br />
1 STATUS<br />
2 MSB = 32 768 feet<br />
3<br />
4<br />
5<br />
6 LEVEL OFF ALTITUDE<br />
7<br />
8 Range = [0, 65 520] feet<br />
9<br />
10<br />
11<br />
12<br />
13 LSB = 16 feet<br />
14 STATUS<br />
15 SIGN<br />
16 MSB = 90 degrees<br />
17<br />
18<br />
19 NEXT COURSE (TRUE GROUND TRACK)<br />
20<br />
21 Range = [–180, +180] degrees<br />
22<br />
23<br />
24 LSB = 360/1 024 degrees<br />
25 STATUS<br />
26 MSB = 128 seconds<br />
27<br />
28 TIME TO NEXT WAYPOINT<br />
29 All ONEs = time exceeds 255 seconds<br />
30<br />
31<br />
32 Range = [0, 256] seconds<br />
33<br />
34 LSB = 0.5 seconds<br />
35 STATUS<br />
36 SIGN<br />
37 MSB = 8 192 ft/min<br />
38<br />
39 VERTICAL VELOCITY (UP IS POSITIVE)<br />
40<br />
41 Range = [–16 384, +16 320] ft/min<br />
42<br />
43<br />
44 LSB = 64 ft/min<br />
45 STATUS<br />
46 SIGN<br />
47 MSB = 45 degrees<br />
48<br />
49 ROLL ANGLE<br />
50<br />
51 Range = [–90, +89] degrees<br />
52<br />
53 LSB = 45/64 degrees<br />
54<br />
55 RESERVED<br />
56<br />
PURPOSE: To report threat aircraft state in<strong>for</strong>mation in order to<br />
improve the ability of ACAS to evaluate the threat <strong>and</strong> select<br />
a resolution maneuver.<br />
Note.— Two’s complement coding is used <strong>for</strong> all signed fields as<br />
specified in §A.2.2.2.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-50 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 MSB<br />
2<br />
3<br />
4 BDS Code 1,0<br />
5<br />
6<br />
7<br />
8 LSB<br />
9 Continuation flag (see 9)<br />
10<br />
11<br />
12 RESERVED<br />
13<br />
14<br />
15 Overlay Comm<strong>and</strong> Capability (OCC) (see 19)<br />
16 Reserved <strong>for</strong> ACAS (see 1)<br />
17 MSB<br />
18<br />
19<br />
20 <strong>Mode</strong> S subnetwork version number (see 12)<br />
21<br />
22<br />
23 LSB<br />
24 Transponder enhanced protocol indicator (see 4)<br />
25 <strong>Mode</strong> S specific services capability (see 2)<br />
26 MSB<br />
27 Uplink ELM average throughput capability (see 13)<br />
28 LSB<br />
29 Downlink ELM: throughput capability of downlink ELM<br />
30 containing the maximum number of ELM segments that the<br />
transponder can deliver in response to a single requesting<br />
31<br />
interrogation (UF = 24). (see 14)<br />
32<br />
33 Aircraft identification capability (see 11)<br />
34 <strong>Squitter</strong> capability subfield (SCS) (see 5)<br />
35 Surveillance identifier code (SIC) (see 6)<br />
36 Common usage GICB capability report (see 7)<br />
37<br />
38 RESERVED FOR ACAS (see 1)<br />
39<br />
40<br />
41 MSB<br />
42<br />
43<br />
44<br />
45<br />
46<br />
47 Bit array indicating the support status of DTE<br />
48 Sub-addresses 0 to 1 5 (see 3 <strong>and</strong> 8)<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56 LSB<br />
Table A-2-16. BDS code 1,0 — Data link capability report<br />
PURPOSE: To report the data link capability of the <strong>Mode</strong> S<br />
transponder/data link installation.<br />
The coding of this register shall con<strong>for</strong>m to:<br />
1) Annex 10, Volume IV, §3.1.2.6.10.2 <strong>and</strong> §4.3.8.4.2.2.2.<br />
2) When bit 25 is set to 1, it shall indicate that at least one <strong>Mode</strong> S<br />
specific service (other than GICB services related to registers 0216,<br />
0316, 0416, 1016, 1716 to 1C16, 2016 <strong>and</strong> 3016) is supported <strong>and</strong> the<br />
particular capability reports shall be checked.<br />
Note.— Registers accessed by BDS Codes 0,2; 0,3; 0,4; 1,0; 1,7<br />
to 1,C; 2,0 <strong>and</strong> 3,0 do not affect the setting of bit 25.<br />
3) Starting from the MSB, each subsequent bit position shall represent<br />
the DTE subaddress in the range from 0 to 15.<br />
4) The enhanced protocol indicator shall denote a Level 5 transponder<br />
when set to 1, <strong>and</strong> a Level 2 to 4 transponder when set to 0.<br />
5) The squitter capability subfield (SCS) shall be set to 1 if both registers<br />
0516 <strong>and</strong> 0616 have been updated within the last ten, plus or minus<br />
one, seconds. Otherwise, it shall be set to 0.<br />
Note.— Registers 0516 <strong>and</strong> 0616 are used <strong>for</strong> the extended squitter<br />
Airborne <strong>and</strong> surface position reports, respectively.<br />
6) The surveillance identifier code (SIC) bit shall be interpreted as<br />
follows:<br />
0 = no surveillance identifier code capability<br />
1 = surveillance identifier code capability<br />
7) Bit 36 shall be toggled each time the common usage GICB capability<br />
report (register 1716) changes. To avoid the generation of too many<br />
broadcast capability report changes, register 1716 shall be sampled at<br />
approximately one minute intervals to check <strong>for</strong> changes.<br />
8) The current status of the on-board DTE shall be periodically reported<br />
to the GDLP by on-board sources. Since a change in this field results<br />
in a broadcast of the capability report, status inputs shall be sampled<br />
at approximately one minute intervals.<br />
Draft<br />
9) In order to determine the extent of any continuation of the data link<br />
capability report (into those registers reserved <strong>for</strong> this purpose:<br />
register 1116 to register 1616), bit 9 shall be reserved as a continuation<br />
flag to indicate if the subsequent register shall be extracted. For<br />
example: upon detection of bit 9 = 1 in register 1016, then register<br />
1116 shall be extracted. If bit 9 = 1, in register 1116, then register 1216<br />
shall be extracted, <strong>and</strong> so on (up to register 1616). Note that if bit<br />
9 = 1 in register 1616, then this shall be considered as an error<br />
condition.<br />
10 The <strong>Mode</strong> S transponder may update bits 1-8, 16, 33, 35 <strong>and</strong> 37-40<br />
independent of the ADLP. These bits are provided by the<br />
transponder when the data link capability report is broadcast as a<br />
result of a transponder detected change in capability reported by the<br />
ADLP (§3.1.2 of Annex 10 Volume IV).<br />
(Requirements are continued on the next page)<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-51<br />
Table A-2-16. BDS code 1,0 — Data link capability report (concluded)<br />
11) Bit 33 indicates the availability of Aircraft Identification data. It shall be set by the<br />
transponder if the data comes to the transponder through a separate interface <strong>and</strong><br />
not through the ADLP.<br />
12) The <strong>Mode</strong> S subnetwork version number shall be coded as follows:<br />
Version<br />
Number<br />
ICAO RTCA EUROCAE<br />
0 <strong>Mode</strong> S subnetwork not available<br />
1 ICAO Doc 9688 (1996)<br />
2 ICAO Doc 9688 (1998)<br />
3 ICAO Annex 10, Vol III, Amdt 77<br />
4 ICAO Doc 9871, Edition 1 DO-181D ED-73C<br />
5 ICAO Doc 9871, Edition 2 DO-181E ED-73E<br />
6 - 127 Reserved<br />
13) Uplink ELM average throughput capability shall be coded as follows:<br />
0 = No UELM Capability<br />
1 = 16 UELM segments in 1 second<br />
2 = 16 UELM segments in 500 ms<br />
3 = 16 UELM segments in 250 ms<br />
4 = 16 UELM segments in 125 ms<br />
5 = 16 UELM segments in 60 ms<br />
6 = 16 UELM segments in 30 ms<br />
7 = Reserved<br />
14) Downlink ELM throughput capability shall be coded as follows:<br />
0 = No DELM Capability<br />
1 = One 4 segment DELM every second<br />
2 = One 8 segment DELM every second<br />
3 = One 16 segment DELM every second<br />
4 = One 16 segment DELM every 500 ms<br />
5 = One 16 segment DELM every 250 ms<br />
6 = One 16 segment DELM every 125 ms<br />
7-15 = Reserved<br />
15) Bit 16 shall be set to ONE (1) to indicate that ACAS is operational <strong>and</strong> set to<br />
ZERO (0) to indicate that ACAS has failed or is on st<strong>and</strong>by.<br />
16) Bit 37 shall be set to ONE (1) to indicate the capability of hybrid surveillance,<br />
<strong>and</strong> set to ZERO (0) to indicate that there is no hybrid surveillance capability.<br />
Draft<br />
17) Bit 38 shall be set to ONE (1) to indicate that the ACAS is generating both TAs<br />
<strong>and</strong> RAs, <strong>and</strong> set to ZERO (0) to indicate the generation of TAs only.<br />
18)<br />
Bit 40 Bit 39 Applicable MOPS Documents<br />
0 0 RTCA DO-185 (see note 1)<br />
0 1 RTCA DO-185A (see note 1)<br />
1 0 RTCA DO-185B<br />
1<br />
Notes.–<br />
1 Reserved <strong>for</strong> future versions<br />
1. RTCA DO-185 equipment is also referenced as TCAS logic version 6.04A.<br />
Equipment compliant to DO-185A, or later versions, are SARPs compliant.<br />
2. Future versions of ACAS will be identified using Part Numbers <strong>and</strong> Software<br />
Version Numbers specified in Registers E516 <strong>and</strong> E616.<br />
19) The Overlay Comm<strong>and</strong> Capability (OCC) in Bit 15 shall be interpreted as follows:<br />
0 = No Overlay Comm<strong>and</strong> Capability<br />
1 = Overlay Comm<strong>and</strong> Capability<br />
Note.– Additional implementation guidelines are provided in §D.2.4.1.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-52 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-23. BDS code 1,7 — Common usage GICB capability report<br />
1 0,5 <strong>Extended</strong> squitter sirborne position<br />
2 0,6 <strong>Extended</strong> squitter surface position<br />
3 0,7 <strong>Extended</strong> squitter status<br />
4 0,8 <strong>Extended</strong> squitter type <strong>and</strong> identification <strong>and</strong> category<br />
5 0,9 <strong>Extended</strong> squitter airborne velocity in<strong>for</strong>mation<br />
6 0,A <strong>Extended</strong> squitter event-driven in<strong>for</strong>mation<br />
7 2,0 Aircraft identification<br />
8 2,l Aircraft registration number<br />
9 4,0 Selected vertical intention<br />
10 4,l Next waypoint identifier<br />
11 4,2 Next waypoint position<br />
12 4,3 Next waypoint in<strong>for</strong>mation<br />
13 4,4 Meteorological routine report<br />
14 4,5 Meteorological hazard report<br />
15 4.8 VHF channel report<br />
16 5,0 Track <strong>and</strong> turn report<br />
17 5,1 Position coarse<br />
18 5,2 Position fine<br />
19 5,3 Air-referenced state vector<br />
20 5,4 Waypoint 1<br />
21 5,5 Waypoint 2<br />
22 5,6 Waypoint 3<br />
23 5,F Quasi-static parameter monitoring<br />
24 6,0 Heading <strong>and</strong> speed report<br />
25 Reserved <strong>for</strong> aircraft capability<br />
26 Reserved <strong>for</strong> aircraft capability<br />
27 E,1 Reserved <strong>for</strong> <strong>Mode</strong> S BITE (Built In Test Equipment)<br />
28 E,2 Reserved <strong>for</strong> <strong>Mode</strong> S BITE (Built In Test Equipment)<br />
29 F,1 Military applications<br />
30<br />
31<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41<br />
42 RESERVED<br />
43<br />
44<br />
45<br />
46<br />
47<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56<br />
PURPOSE: To indicate common usage GICB services currently<br />
supported.<br />
1) Each bit position shall indicate that the associated register is<br />
available in the aircraft installation when set to 1.<br />
2) All registers shall be constantly monitored at a rate consistent with<br />
their individual required update rate <strong>and</strong> the corresponding capability<br />
bit shall be set to 1 only when valid data is being input to that register<br />
at the required rate or above.<br />
3) The capability bit shall be set to a 1 if at least one field in the register<br />
is receiving valid data at the required rate with the status bits <strong>for</strong> all<br />
fields not receiving valid data at the required rate set to ZERO (0).<br />
4) Registers 1816 to 1C16 shall be independent of register 1716.<br />
5) Bit 6 is set to ONE (1) upon the first loading of register 0A16 <strong>and</strong> shall<br />
remain set until either the transponder is powered OFF or ADS-B<br />
transmission is terminated.<br />
6) Bits 17 <strong>and</strong> 18 shall only be set to ONE (1) if the STATUS bits in<br />
register 5116 <strong>and</strong> 5216 are set to 1.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-53<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-24. BDS code 1,8 — <strong>Mode</strong> S specific services<br />
GICB capability report (1 of 5)<br />
1 BDS 3,8<br />
PURPOSE: To indicate GICB services that are installed.<br />
2<br />
3<br />
4<br />
BDS 3,7<br />
BDS 3,6<br />
BDS 3,5<br />
Each bit position shall indicate that the GICB service that it<br />
represents has been implemented in the aircraft installation<br />
when set to 1.<br />
5 BDS 3,4<br />
6<br />
7<br />
BDS 3,3<br />
BDS 3,2<br />
Starting from the LSB, each bit position shall represent the<br />
register number, in accordance with the following table:<br />
8 BDS 3,1 BDS Code Capability installed <strong>for</strong> register<br />
9 BDS 3,0 BDS 1,8 011 6 to 3816<br />
10 BDS 2,F BDS 1,9 391 6 to 7016<br />
11 BDS 2,E BDS 1,A 711 6 to A816<br />
12 BDS 2,D BDS 1,B A91 6 to E016<br />
13 BDS 2,C BDS 1,C E11 6 to FF16<br />
14 BDS 2,B<br />
15 BDS 2,A The 25 most significant bits of register 1C16 shall not be used.<br />
16 BDS 2,9<br />
17 BDS 2,8<br />
Note.— Additional implementation guidelines are provided in<br />
18 BDS 2,7<br />
§CD.2.4.2.<br />
19 BDS 2,6<br />
20 BDS 2,5<br />
21 BDS 2,4<br />
22 BDS 2,3<br />
23 BDS 2,2<br />
24 BDS 2,1<br />
25 BDS 2,0<br />
26 BDS 1,F<br />
27 BDS 1,E<br />
28 BDS 1,D<br />
29 BDS 1,C<br />
30 BDS 1,B<br />
31 BDS 1,A<br />
32 BDS 1,9<br />
33 BDS 1,8<br />
34 BDS 1,7<br />
35 BDS 1,6<br />
36 BDS 1,5<br />
37 BDS 1,4<br />
38 BDS 1,3<br />
39 BDS 1,2<br />
40 BDS 1,1<br />
41 BDS 1,0<br />
42 BDS 0,F<br />
43 BDS 0,E<br />
44 BDS 0,D<br />
45 BDS 0,C<br />
46 BDS 0,B<br />
47 BDS 0,A<br />
48 BDS 0,9<br />
49 BDS 0,8<br />
50 BDS 0,7<br />
51 BDS 0,6<br />
52 BDS 0,5<br />
53 BDS 0,4<br />
54 BDS 0,3<br />
55 BDS 0,2<br />
56 BDS 0,1<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-54 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
1 BDS 7,0<br />
2 BDS 6,F<br />
3 BDS 6,E<br />
4 BDS 6,D<br />
5 BDS 6,C<br />
6 BDS 6,B<br />
7 BDS 6,A<br />
8 BDS 6,9<br />
9 BDS 6,8<br />
10 BDS 6,7<br />
11 BDS 6,6<br />
12 BDS 6,5<br />
13 BDS 6,4<br />
14 BDS 6,3<br />
15 BDS 6,2<br />
16 BDS 6,1<br />
17 BDS 6,0<br />
18 BDS 5,F<br />
19 BDS 5,E<br />
20 BDS 5,D<br />
21 BDS 5,C<br />
22 BDS 5,B<br />
23 BDS 5,A<br />
24 BDS 5,9<br />
25 BDS 5,8<br />
26 BDS 5,7<br />
27 BDS 5,6<br />
28 BDS 5,5<br />
29 BDS 5,4<br />
30 BDS 5,3<br />
31 BDS 5,2<br />
32 BDS 5,1<br />
33 BDS 5,0<br />
34 BDS 4,F<br />
35 BDS 4,E<br />
36 BDS 4,D<br />
37 BDS 4,C<br />
38 BDS 4,B<br />
39 BDS 4,A<br />
40 BDS 4,9<br />
41 BDS 4,8<br />
42 BDS 4,7<br />
43 BDS 4,6<br />
44 BDS 4,5<br />
45 BDS 4,4<br />
46 BDS 4,3<br />
47 BDS 4,2<br />
48 BDS 4,1<br />
49 BDS 4,0<br />
50 BDS 3,F<br />
51 BDS 3,E<br />
52 BDS 3,D<br />
53 BDS 3,C<br />
54 BDS 3,B<br />
55 BDS 3,A<br />
56 BDS 3,9<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-25. BDS code 1,9 — <strong>Mode</strong> S specific services<br />
GICB capability report (2 of 5)<br />
PURPOSE: To indicate GICB services that are installed.<br />
Each bit position shall indicate that the GICB service that it represents<br />
has been implemented in the aircraft installation when set to 1.<br />
Note.— Additional implementation guidelines are provided in<br />
§CD.2.4.2.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-55<br />
MB FIELD<br />
1 BDS A,8<br />
2 BDS A,7<br />
3 BDS A,6<br />
4 BDS A,5<br />
5 BDS A,4<br />
6 BDS A,3<br />
7 BDS A,2<br />
8 BDS A,1<br />
9 BDS A,0<br />
10 BDS 9,F<br />
11 BDS 9,E<br />
12 BDS 9,D<br />
13 BDS 9,C<br />
14 BDS 9,B<br />
15 BDS 9,A<br />
16 BDS 9,9<br />
17 BDS 9,8<br />
18 BDS 9,7<br />
19 BDS 9,6<br />
20 BDS 9,5<br />
21 BDS 9,4<br />
22 BDS 9,3<br />
23 BDS 9,2<br />
24 BDS 9,1<br />
25 BDS 9,0<br />
26 BDS 8,F<br />
27 BDS 8,E<br />
28 BDS 8,D<br />
29 BDS 8,C<br />
30 BDS 8,B<br />
31 BDS 8,A<br />
32 BDS 8,9<br />
33 BDS 8,8<br />
34 BDS 8,7<br />
35 BDS 8,6<br />
36 BDS 8,5<br />
37 BDS 8,4<br />
38 BDS 8,3<br />
39 BDS 8,2<br />
40 BDS 8,1<br />
41 BDS 8,0<br />
42 BDS 7,F<br />
43 BDS 7,E<br />
44 BDS 7,D<br />
45 BDS 7,C<br />
46 BDS 7,B<br />
47 BDS 7,A<br />
48 BDS 7,9<br />
49 BDS 7,8<br />
50 BDS 7,7<br />
51 BDS 7,6<br />
52 BDS 7,5<br />
53 BDS 7,4<br />
54 BDS 7,3<br />
55 BDS 7,2<br />
56 BDS 7,1<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-26. BDS code 1,A — <strong>Mode</strong> S specific services<br />
GICB capability report (3 of 5)<br />
PURPOSE: To indicate GICB services that are installed.<br />
Each bit position shall indicate that the GICB service that it represents<br />
has been implemented in the aircraft installation when set to 1.<br />
Note.— Additional implementation guidelines are provided in<br />
§CD.2.4.2.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-56 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
1 BDS E,0<br />
2 BDS D,F<br />
3 BDS D,E<br />
4 BDS D,D<br />
5 BDS D,C<br />
6 BDS D,B<br />
7 BDS D,A<br />
8 BDS D,9<br />
9 BDS D,8<br />
10 BDS D,7<br />
11 BDS D,6<br />
12 BDS D,5<br />
13 BDS D,4<br />
14 BDS D,3<br />
15 BDS D,2<br />
16 BDS D,1<br />
17 BDS D,0<br />
18 BDS C,F<br />
19 BDS C,E<br />
20 BDS C,D<br />
21 BDS C,C<br />
22 BDS C,B<br />
23 BDS C,A<br />
24 BDS C,9<br />
25 BDS C,8<br />
26 BDS C,7<br />
27 BDS C,6<br />
28 BDS C,5<br />
29 BDS C,4<br />
30 BDS C,3<br />
31 BDS C,2<br />
32 BDS C,1<br />
33 BDS C,0<br />
34 BDS B,F<br />
35 BDS B,E<br />
36 BDS B,D<br />
37 BDS B,C<br />
38 BDS B,B<br />
39 BDS B,A<br />
40 BDS B,9<br />
41 BDS B,8<br />
42 BDS B,7<br />
43 BDS B,6<br />
44 BDS B,5<br />
45 BDS B,4<br />
46 BDS B,3<br />
47 BDS B,2<br />
48 BDS B,1<br />
49 BDS B,0<br />
50 BDS A,F<br />
51 BDS A,E<br />
52 BDS A,D<br />
53 BDS A,C<br />
54 BDS A,B<br />
55 BDS A,A<br />
56 BDS A,9<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-27. BDS code 1,B — <strong>Mode</strong> S specific services<br />
GICB capability report (4 of 5)<br />
PURPOSE: To indicate GICB services that are installed.<br />
Each bit position shall indicate that the GICB service that it represents<br />
has been implemented in the aircraft installation when set to 1.<br />
Note.— Additional implementation guidelines are provided in<br />
§CD.2.4.2.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-57<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1<br />
2<br />
3<br />
4<br />
5<br />
6<br />
7<br />
8<br />
9<br />
10<br />
11<br />
12<br />
13 RESERVED<br />
14<br />
15<br />
16<br />
17<br />
18<br />
19<br />
20<br />
21<br />
22<br />
23<br />
24<br />
25<br />
26 BDS F,F<br />
27 BDS F,E<br />
28 BDS F,D<br />
29 BDS F,C<br />
30 BDS F,B<br />
31 BDS F,A<br />
32 BDS F,9<br />
33 BDS F,8<br />
34 BDS F,7<br />
35 BDS F,6<br />
36 BDS F,5<br />
37 BDS F,4<br />
38 BDS F,3<br />
39 BDS F,2<br />
40 BDS F,1<br />
41 BDS F,0<br />
42 BDS E,F<br />
43 BDS E,E<br />
44 BDS E,D<br />
45 BDS E,C<br />
46 BDS E,B<br />
47 BDS E,A<br />
48 BDS E,9<br />
49 BDS E,8<br />
50 BDS E,7<br />
51 BDS E,6<br />
52 BDS E,5<br />
53 BDS E,4<br />
54 BDS E,3<br />
55 BDS E,2<br />
56 BDS E,1<br />
Table A-2-28. BDS code 1,C — <strong>Mode</strong> S specific services<br />
GICB capability report (5 of 5)<br />
PURPOSE: To indicate GICB services that are installed.<br />
Each bit position shall indicate that the GICB service that it represents<br />
has been implemented in the aircraft installation when set to 1.<br />
Note.— Additional implementation guidelines are provided in<br />
§CD.2.4.2.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-58 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 Uplink MSP Channel 1<br />
2 Uplink MSP Channel 2<br />
3 Uplink MSP Channel 3<br />
4 Uplink MSP Channel 4<br />
5 Uplink MSP Channel 5<br />
6 Uplink MSP Channel 6<br />
7 Uplink MSP Channel 7<br />
8 Uplink MSP Channel 8<br />
9 Uplink MSP Channel 9<br />
10 Uplink MSP Channel 10<br />
Table A-2-29. BDS code 1,D — <strong>Mode</strong> S specific services<br />
MSP capability report (1 of 3)<br />
PURPOSE: To indicate MSP services that are installed <strong>and</strong> require a<br />
service.<br />
Each bit shall indicate that the MSP it represents requires service<br />
when set to 1.<br />
Starting from the MSB, each bit position shall represent the MSP<br />
channel number <strong>for</strong> both uplink <strong>and</strong> downlink channel fields, in<br />
accordance with the following table:<br />
11 Uplink MSP Channel 11 BDS code MSP channels<br />
12 Uplink MSP Channel 12 BDS 1,D 1 to 28 up <strong>and</strong> down<br />
13 Uplink MSP Channel 13 BDS 1,E 29 to 56 up <strong>and</strong> down<br />
14 Uplink MSP Channel 14 BDS 1,F 57 to 63 up <strong>and</strong> down<br />
15 Uplink MSP Channel 15<br />
16<br />
17<br />
Uplink MSP Channel 16<br />
Uplink MSP Channel 17<br />
1) In register 1F16 the least significant bits of both uplink <strong>and</strong> downlink<br />
channel fields shall not be used.<br />
18<br />
19<br />
Uplink MSP Channel 18<br />
Uplink MSP Channel 19<br />
2) The conditions <strong>for</strong> setting the capability bits shall be as defined in the<br />
specification of the corresponding service, see section §A.3.<br />
20 Uplink MSP Channel 20<br />
21 Uplink MSP Channel 21<br />
22 Uplink MSP Channel 22<br />
23 Uplink MSP Channel 23<br />
24 Uplink MSP Channel 24<br />
25 Uplink MSP Channel 25<br />
26 Uplink MSP Channel 26<br />
27 Uplink MSP Channel 27<br />
28 Uplink MSP Channel 28<br />
29 Downlink MSP Channel 1<br />
30 Downlink MSP Channel 2<br />
31 Downlink MSP Channel 3<br />
32 Downlink MSP Channel 4<br />
33 Downlink MSP Channel 5<br />
34 Downlink MSP Channel 6<br />
35 Downlink MSP Channel 7<br />
36 Downlink MSP Channel 8<br />
37 Downlink MSP Channel 9<br />
38 Downlink MSP Channel 10<br />
39 Downlink MSP Channel 11<br />
40 Downlink MSP Channel 12<br />
41 Downlink MSP Channel 13<br />
42 Downlink MSP Channel 14<br />
43 Downlink MSP Channel 15<br />
44 Downlink MSP Channel 16<br />
45 Downlink MSP Channel 17<br />
46 Downlink MSP Channel 18<br />
47 Downlink MSP Channel 19<br />
48 Downlink MSP Channel 20<br />
49 Downlink MSP Channel 21<br />
50 Downlink MSP Channel 22<br />
51 Downlink MSP Channel 23<br />
52 Downlink MSP Channel 24<br />
53 Downlink MSP Channel 25<br />
54 Downlink MSP Channel 26<br />
55 Downlink MSP Channel 27<br />
56 Downlink MSP Channel 28<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-59<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 Uplink MSP Channel 29<br />
2 Uplink MSP Channel 30<br />
3 Uplink MSP Channel 31<br />
4 Uplink MSP Channel 32<br />
5 Uplink MSP Channel 33<br />
6 Uplink MSP Channel 34<br />
7 Uplink MSP Channel 35<br />
8 Uplink MSP Channel 36<br />
9 Uplink MSP Channel 37<br />
10 Uplink MSP Channel 38<br />
11 Uplink MSP Channel 39<br />
12 Uplink MSP Channel 40<br />
13 Uplink MSP Channel 41<br />
14 Uplink MSP Channel 42<br />
15 Uplink MSP Channel 43<br />
16 Uplink MSP Channel 44<br />
17 Uplink MSP Channel 45<br />
18 Uplink MSP Channel 46<br />
19 Uplink MSP Channel 47<br />
20 Uplink MSP Channel 48<br />
21 Uplink MSP Channel 49<br />
22 Uplink MSP Channel 50<br />
23 Uplink MSP Channel 51<br />
24 Uplink MSP Channel 52<br />
25 Uplink MSP Channel 53<br />
26 Uplink MSP Channel 54<br />
27 Uplink MSP Channel 55<br />
28 Uplink MSP Channel 56<br />
29 Downlink MSP Channel 29<br />
30 Downlink MSP Channel 30<br />
31 Downlink MSP Channel 31<br />
32 Downlink MSP Channel 32<br />
33 Downlink MSP Channel 33<br />
34 Downlink MSP Channel 34<br />
35 Downlink MSP Channel 35<br />
36 Downlink MSP Channel 36<br />
37 Downlink MSP Channel 37<br />
38 Downlink MSP Channel 38<br />
39 Downlink MSP Channel 39<br />
40 Downlink MSP Channel 40<br />
41 Downlink MSP Channel 41<br />
42 Downlink MSP Channel 42<br />
43 Downlink MSP Channel 43<br />
44 Downlink MSP Channel 44<br />
45 Downlink MSP Channel 45<br />
46 Downlink MSP Channel 46<br />
47 Downlink MSP Channel 47<br />
48 Downlink MSP Channel 48<br />
49 Downlink MSP Channel 49<br />
50 Downlink MSP Channel 50<br />
51 Downlink MSP Channel 51<br />
52 Downlink MSP Channel 52<br />
53 Downlink MSP Channel 53<br />
54 Downlink MSP Channel 54<br />
55 Downlink MSP Channel 55<br />
56 Downlink MSP Channel 56<br />
Table A-2-30. BDS code 1,E — <strong>Mode</strong> S specific services<br />
MSP capability report (2 of 3)<br />
PURPOSE: To indicate MSP services that are installed <strong>and</strong> require a<br />
service.<br />
Each bit shall indicate that the MSP it represents requires<br />
service when set to 1.<br />
1) The conditions <strong>for</strong> setting the capability bits shall be as defined in the<br />
specification of the corresponding service, see section §A.3.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-60 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 Uplink MSP Channel 57<br />
2 Uplink MSP Channel 58<br />
3 Uplink MSP Channel 59<br />
4 Uplink MSP Channel 60<br />
5 Uplink MSP Channel 61<br />
6 Uplink MSP Channel 62<br />
7 Uplink MSP Channel 63<br />
8<br />
9<br />
10<br />
11<br />
12<br />
13<br />
14<br />
15<br />
16<br />
17<br />
18 RESERVED<br />
19<br />
20<br />
21<br />
22<br />
23<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29 Downlink MSP Channel 57<br />
30 Downlink MSP Channel 58<br />
31 Downlink MSP Channel 59<br />
32 Downlink MSP Channel 60<br />
33 Downlink MSP Channel 61<br />
34 Downlink MSP Channel 62<br />
35 Downlink MSP Channel 63<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46 RESERVED<br />
47<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56<br />
Table A-2-31. BDS code 1,F — <strong>Mode</strong> S specific services<br />
MSP capability report (3 of 3)<br />
PURPOSE: To indicate MSP services that are installed <strong>and</strong> require a<br />
service.<br />
Each bit shall indicate that the MSP it represents requires service when set<br />
to 1.<br />
1) In register 1F16 the least significant bits of both uplink <strong>and</strong> downlink<br />
channel fields shall not be used.<br />
2) The conditions <strong>for</strong> setting the capability bits shall be as defined in the<br />
specification of the corresponding service, see section §A.3.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-61<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 MSB<br />
2<br />
3<br />
4 BDS Code 2,0<br />
5<br />
6<br />
7<br />
8 LSB<br />
9 MSB<br />
10<br />
11 CHARACTER 1<br />
12<br />
13<br />
14 LSB<br />
15 MSB<br />
16<br />
17 CHARACTER 2<br />
18<br />
19<br />
20 LSB<br />
21 MSB<br />
22<br />
23 CHARACTER 3<br />
24<br />
25<br />
26 LSB<br />
27 MSB<br />
28<br />
29<br />
30 CHARACTER 4<br />
31<br />
32 LSB<br />
33 MSB<br />
34<br />
35<br />
36 CHARACTER 5<br />
37<br />
38 LSB<br />
39 MSB<br />
40<br />
41<br />
42 CHARACTER 6<br />
43<br />
44 LSB<br />
45 MSB<br />
46<br />
47<br />
48 CHARACTER 7<br />
49<br />
50 LSB<br />
51 MSB<br />
52<br />
53<br />
54 CHARACTER 8<br />
55<br />
56 LSB<br />
Table A-2-32. BDS code 2,0 — Aircraft identification<br />
PURPOSE: To report aircraft identification to the ground.<br />
1) Annex 10, Volume IV, §3.1.2.9.<br />
2) The character coding to be used shall be identical to that defined in<br />
Table 3-7 of Chapter 3, Annex 10, Volume IV.<br />
3) This data may be input to the transponder from sources other than<br />
the <strong>Mode</strong> S ADLP.<br />
4) Characters 1 — 8 of this <strong>for</strong>mat shall be used by the extended<br />
squitter application.<br />
5) Capability to support this register shall be indicated by setting bit 33<br />
in register 1016 <strong>and</strong> the relevant bits in registers 1716 <strong>and</strong> 1816.<br />
6) The aircraft identification shall be that employed in the flight plan.<br />
When no flight plan is available, the registration marking of the<br />
aircraft shall be used.<br />
Note.— Additional implementation guidelines are provided in<br />
§CD.2.4.3.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-62 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 STATUS<br />
2 MSB<br />
3<br />
4 CHARACTER 1<br />
5<br />
6<br />
7 LSB<br />
8 MSB<br />
9<br />
10 CHARACTER 2<br />
11<br />
12<br />
13 LSB<br />
14 MSB<br />
15<br />
16 CHARACTER 3<br />
17<br />
18<br />
19 LSB<br />
20 MSB<br />
21<br />
22 CHARACTER 4<br />
23<br />
24<br />
25 LSB<br />
26 MSB<br />
27<br />
28 CHARACTER 5<br />
29<br />
30<br />
31 LSB<br />
32 MSB<br />
33<br />
34 CHARACTER 6<br />
35<br />
36<br />
37 LSB<br />
38 MSB<br />
39<br />
40 CHARACTER 7<br />
41<br />
42<br />
43 LSB<br />
44 STATUS<br />
45 MSB<br />
46<br />
47 CHARACTER 1<br />
48<br />
49<br />
50 LSB<br />
51 MSB<br />
52<br />
53 CHARACTER 2<br />
54<br />
55<br />
56 LSB<br />
Table A-2-33. BDS code 2,1 — Aircraft <strong>and</strong> airline registration markings<br />
AIRCRAFT<br />
REGISTRATION<br />
NUMBER<br />
Draft<br />
ICAO AIRLINE<br />
REGISTRATION<br />
MARKING<br />
PURPOSE: To permit ground systems to identify the aircraft without the<br />
necessity of compiling <strong>and</strong> maintaining continuously updated data<br />
banks.<br />
The character coding shall be as defined in Table 3-7 of Chapter 3,<br />
Annex 10, Volume IV.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-63<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 MSB<br />
2 ANTENNA TYPE<br />
3 LSB<br />
4<br />
5<br />
MSB = 32 metres<br />
6 X POSITION<br />
7<br />
8<br />
Range = [1, 63] ANTENNA 1<br />
9 LSB = 1 metre<br />
10<br />
11<br />
MSB = 16 metres<br />
12 Z POSITION<br />
13 Range = [1, 31]<br />
14 LSB = 1 metre<br />
15 MSB<br />
16 ANTENNA TYPE<br />
17 LSB<br />
18<br />
19<br />
MSB = 32 metres<br />
20 X POSITION<br />
21<br />
22<br />
Range = [1, 63] ANTENNA 2<br />
23 LSB = 1 metre<br />
24<br />
25<br />
MSB = 16 metres<br />
26 Z POSITION<br />
27 Range = [1, 31]<br />
28 LSB = 1 metre<br />
29 MSB<br />
30 ANTENNA TYPE<br />
31 LSB<br />
32<br />
33<br />
MSB = 32 metres<br />
34 X POSITION<br />
35<br />
36<br />
Range = [1, 63] ANTENNA 3<br />
37 LSB = 1 metre<br />
38<br />
39<br />
MSB = 16 metres<br />
40 Z POSITION<br />
41 Range = [1, 31]<br />
42 LSB = 1 metre<br />
43 MSB<br />
44 ANTENNA TYPE<br />
45 LSB<br />
46<br />
47<br />
MSB = 32 metres<br />
48 X POSITION<br />
49<br />
50<br />
Range = [1, 63] ANTENNA 4<br />
51 LSB = 1 metre<br />
52<br />
53<br />
MSB = 16 metres<br />
54 Z POSITION<br />
55 Range = [1, 31]<br />
56 LSB = 1 metre<br />
Table A-2-34. BDS code 2,2 — Antenna positions<br />
PURPOSE: To provide in<strong>for</strong>mation on the position of <strong>Mode</strong> S <strong>and</strong> GNSS<br />
antennas on the aircraft in order to make very accurate measurements of<br />
aircraft position possible.<br />
1) The antenna type field shall be interpreted as follows:<br />
0 = Invalid<br />
1 = <strong>Mode</strong> S bottom antenna<br />
2 = <strong>Mode</strong> S top antenna<br />
3 = GNSS antenna<br />
4 to 7 = Reserved<br />
2) The X position field shall be the distance in meters along the aircraft<br />
center line measured from the nose of the aircraft. The field shall be<br />
interpreted as invalid if the value is ZERO (0) <strong>and</strong> the value of 63<br />
shall mean that the antenna position is 63 metres or more from the<br />
nose.<br />
3) The Z position field shall be the distance in meters of the antenna<br />
from the ground, measured with the aircraft unloaded <strong>and</strong> on the<br />
ground. The field shall be interpreted as invalid if the value is ZERO<br />
(0), <strong>and</strong> the value of 31 shall mean that the antenna position is 31<br />
metres or more from the ground.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-64 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1<br />
2<br />
MSB<br />
3<br />
4<br />
5<br />
AIRCRAFT TYPE<br />
6 LSB<br />
7 MSB<br />
8 NUMBER OF ENGINES<br />
9 LSB<br />
10<br />
11<br />
MSB<br />
12<br />
13<br />
14<br />
ENGINE TYPE<br />
15 LSB<br />
16<br />
17<br />
MSB<br />
18<br />
19<br />
20<br />
CHARACTER 1<br />
21 LSB<br />
22<br />
23<br />
MSB<br />
24<br />
25<br />
26<br />
CHARACTER 2<br />
27 LSB<br />
28<br />
29<br />
MSB<br />
30 CHARACTER 3<br />
MODEL<br />
31<br />
32<br />
DESIGNATION<br />
33 LSB<br />
34<br />
35<br />
MSB<br />
36<br />
37<br />
38<br />
CHARACTER 4<br />
39 LSB<br />
40<br />
41<br />
MSB<br />
42<br />
43<br />
44<br />
CHARACTER 5<br />
45 LSB<br />
46<br />
47<br />
MSB<br />
48<br />
WAKE TURBULENCE<br />
49<br />
50<br />
CATEGORY<br />
51<br />
52<br />
53<br />
LSB<br />
54<br />
55<br />
56<br />
RESERVED<br />
Table A-2-37. BDS code 2,5 — Aircraft type<br />
PURPOSE: To provide in<strong>for</strong>mation on aircraft type.<br />
1) Subfield coding<br />
The coding shall be as in Doc 8643 — Aircraft Type Designators. All<br />
the subfields that contain characters shall be encoded using the 6-bit<br />
subset of IA-5 as specified in Table 3-9 of Annex 10, Volume IV.<br />
2) <strong>Mode</strong>l designation<br />
Coding shall consist of four characters as specified in Doc 8643. The<br />
fifth character shall be reserved <strong>for</strong> future expansion <strong>and</strong> shall contain<br />
all ZEROs until it is specified. 2222 in the first four characters shall<br />
mean that the designator is not specified.<br />
3) Number of engines<br />
This subfield shall be encoded as a binary number where number 7<br />
means 7 or more engines.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-65<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1<br />
2<br />
3<br />
MSB<br />
4<br />
5<br />
6<br />
7<br />
BDS Code 3,0<br />
8 LSB<br />
9<br />
10<br />
11<br />
12<br />
13<br />
14<br />
MSB<br />
15<br />
16<br />
17<br />
18<br />
19<br />
20<br />
21<br />
ACTIVE RESOLUTION ADVISORIES<br />
22 LSB<br />
23 MSB<br />
24<br />
25<br />
RACs RECORD<br />
26 LSB<br />
27 RA TERMINATED<br />
28 MULTIPLE THREAT ENCOUNTER<br />
29 MSB THREAT-TYPE INDICATOR<br />
30 LSB<br />
31<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41<br />
42<br />
MSB<br />
43<br />
44<br />
45<br />
46<br />
47<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
THREAT IDENTITY DATA<br />
56 LSB<br />
Table A-2-48. BDS code 3,0 — ACAS active resolution advisory<br />
PURPOSE: To report resolution advisories (RAs) generated by ACAS<br />
equipment.<br />
The coding of this register shall con<strong>for</strong>m to:<br />
1) Annex 10, Volume IV, §4.3.8.4.2.2.<br />
2) Bit 27 shall mean RA terminated when set to 1.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-66 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 STATUS<br />
2<br />
3<br />
4<br />
MSB = 32 768 feet<br />
5<br />
6<br />
MCP/FCU SELECTED ALTITUDE<br />
7<br />
8<br />
9<br />
10<br />
11<br />
12<br />
Range = [0, 65 520] feet<br />
13 LSB = 16 feet<br />
14 STATUS<br />
15<br />
16<br />
17<br />
MSB = 32 768 feet<br />
18<br />
19<br />
FMS SELECTED ALTITUDE<br />
20<br />
21<br />
22<br />
23<br />
24<br />
25<br />
Range = [0, 65 520] feet<br />
26 LSB = 16 feet<br />
27 STATUS<br />
28<br />
29<br />
30<br />
31<br />
MSB = 204.8 mb<br />
32 BAROMETRIC PRESSURE SETTING<br />
33<br />
34<br />
MINUS 800 mb<br />
35<br />
36<br />
37<br />
38<br />
Range = [0, 410] mb<br />
39<br />
40<br />
41<br />
42<br />
43<br />
LSB = 0.1 mb<br />
44<br />
45<br />
46<br />
47<br />
RESERVED<br />
48 STATUS OF MCP/FCU MODE BITS<br />
49 VNAV MODE<br />
50 ALT HOLD MODE MCP/FCU <strong>Mode</strong> bits<br />
51 APPROACH MODE<br />
52<br />
53<br />
RESERVED<br />
54 STATUS OF TARGET ALT SOURCE BITS<br />
55 MSB TARGET ALT SOURCE<br />
56 LSB<br />
Table A-2-64. BDS code 4,0 — Selected vertical intention<br />
PURPOSE: To provide ready access to in<strong>for</strong>mation about the aircraft’s current vertical<br />
intentions, in order to improve the effectiveness of conflict probes <strong>and</strong> to provide<br />
additional tactical in<strong>for</strong>mation to controllers.<br />
1) Target altitude shall be the short-term intent value, at which the aircraft will level<br />
off (or has leveled off) at the end of the current maneuver. The data source that<br />
the aircraft is currently using to determine the target altitude shall be indicated in<br />
the altitude source bits (54 to 56) as detailed below.<br />
Note.— This in<strong>for</strong>mation which represents the real “aircraft intent,” when available,<br />
represented by the altitude control panel selected altitude, the flight management<br />
system selected altitude, or the current aircraft altitude according to the aircraft’s<br />
mode of flight (the intent may not be available at all when the pilot is flying the<br />
aircraft).<br />
2) The data entered into bits 1 to 13 shall be derived from the mode control<br />
panel/flight control unit or equivalent equipment. Alerting devices may be used to<br />
provide data if it is not available from “control” equipment. The associated mode<br />
bits <strong>for</strong> this field (48 to 51) shall be as detailed below.<br />
3) The data entered into bits 14 to 26 shall de derived from the flight management<br />
system or equivalent equipment managing the vertical profile of the aircraft.<br />
4) The current barometric pressure setting shall be calculated from the value<br />
contained in the field (bits 28 to 39) plus 800 mb.<br />
When the barometric pressure setting is less than 800 mb or greater than<br />
1 209.5 mb, the status bit <strong>for</strong> this field (bit 27) shall be set to indicate invalid data.<br />
5) Reserved bits 40 to 47 shall be set to ZERO (0).<br />
56) Bits 48 to 56 shall indicate the status (see §CD.2.4.4) of the values provided in bits<br />
1 to 26 as follows:<br />
Bit 48 shall indicate whether the mode bits (49, 50 <strong>and</strong> 51) are already being<br />
populated:<br />
0 = No mode in<strong>for</strong>mation provided<br />
1 = <strong>Mode</strong> in<strong>for</strong>mation deliberately provided<br />
Bits 49, 50 <strong>and</strong> 51:<br />
0 = Not active<br />
1 = Active<br />
Draft<br />
Reserved bits 52 <strong>and</strong> 53 shall be set to ZERO (0).<br />
Bit 54 shall indicate whether the target altitude source bits (55 <strong>and</strong> 56) are actively<br />
being populated:<br />
0 = No source in<strong>for</strong>mation provided<br />
1 = Source in<strong>for</strong>mation deliberately provided<br />
Bits 55 <strong>and</strong> 56 shall indicate target altitude source:<br />
00 = Unknown<br />
01 = Aircraft altitude<br />
10 = FCU/MCP selected altitude<br />
11 = FMS selected altitude<br />
Note.— Additional implementation guidelines are provided in §CD.2.4.4.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-67<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 STATUS<br />
2 MSB<br />
3<br />
4 CHARACTER 1<br />
5<br />
6<br />
7 LSB<br />
8 MSB<br />
9<br />
10 CHARACTER 2<br />
11<br />
12<br />
13 LSB<br />
14 MSB<br />
15<br />
16 CHARACTER 3<br />
17<br />
18<br />
19 LSB<br />
20 MSB<br />
21<br />
22 CHARACTER 4<br />
23<br />
24<br />
25 LSB<br />
26 MSB<br />
27<br />
28 CHARACTER 5<br />
29<br />
30<br />
31 LSB<br />
32 MSB<br />
33<br />
34 CHARACTER 6<br />
35<br />
36<br />
37 LSB<br />
38 MSB<br />
39<br />
40 CHARACTER 7<br />
41<br />
42<br />
43 LSB<br />
44 MSB<br />
45<br />
46 CHARACTER 8<br />
47<br />
48<br />
49 LSB<br />
50 MSB<br />
51<br />
52 CHARACTER 9<br />
53<br />
54<br />
55 LSB<br />
56 RESERVED<br />
Table A-2-65. BDS code 4,1 — Next waypoint details<br />
PURPOSE: To provide ready access to details about the next waypoint<br />
on an aircraft’s route, without the need to establish a data link dialogue<br />
with the flight management system. This will assist with short <strong>and</strong><br />
medium term tactical control.<br />
1) Each character shall be encoded as specified in Annex 10,<br />
Volume IV, §3.1.2.9.1.2.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-68 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 STATUS<br />
2 SIGN<br />
3 MSB = 90 degrees<br />
4<br />
5<br />
6<br />
7<br />
8<br />
9 WAYPOINT LATITUDE<br />
10<br />
11 Range = [–180, +180] degrees<br />
12<br />
13<br />
14<br />
15<br />
16<br />
17<br />
18<br />
19<br />
20 LSB = 90/131 072 degrees<br />
21 STATUS<br />
22 SIGN<br />
23 MSB = 90 degrees<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29<br />
30 WAYPOINT LONGITUDE<br />
31<br />
32 Range = [–180, +180] degrees<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40 LSB = 90/131 072 degrees<br />
41 STATUS<br />
42 SIGN<br />
43 MSB = 65 536 feet<br />
44<br />
45<br />
46<br />
47 WAYPOINT CROSSING<br />
48 ALTITUDE<br />
49<br />
50 Range = [–131 072, +131 064] feet<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56 LSB = 8 feet<br />
Table A-2-66. BDS code 4,2 — Next waypoint details<br />
PURPOSE: To provide ready access to details about the next waypoint<br />
on an aircraft’s route, without the need to establish a data link dialogue<br />
with the flight management system. This will assist with short <strong>and</strong><br />
medium term tactical control.<br />
Note.— Two’s complement coding is used <strong>for</strong> all signed fields as<br />
specified in §A.2.2.2.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-69<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 STATUS<br />
2 SIGN<br />
3 MSB = 90 degrees<br />
4<br />
5<br />
6 BEARING TO WAYPOINT<br />
7<br />
8 Range = [–180, +180] degrees<br />
9<br />
10<br />
11<br />
12 LSB = 360/2 048 degrees<br />
13 STATUS<br />
14 MSB = 204.8 minutes<br />
15<br />
16<br />
17<br />
18 TIME TO GO<br />
19<br />
20 Range = [0, 410] minutes<br />
21<br />
22<br />
23<br />
24<br />
25 LSB = 0.1 minutes<br />
26 STATUS<br />
27 MSB = 3 276.8 NM<br />
28<br />
29<br />
30<br />
31<br />
32<br />
33 DISTANCE TO GO<br />
34<br />
35 Range = [0, 6 554] NM<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41<br />
42 LSB = 0.1 NM<br />
43<br />
44<br />
45<br />
46<br />
47<br />
48<br />
49<br />
50 RESERVED<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56<br />
Table A-2-67. BDS code 4,3 — Next waypoint details<br />
PURPOSE: To provide ready access to details about the next waypoint on<br />
an aircraft’s route, without the need to establish a data link dialogue with the<br />
flight management system. This will assist with short <strong>and</strong> medium term<br />
tactical control.<br />
1) The bearing to waypoint is the bearing from the current aircraft heading<br />
position to the waypoint position referenced to true north.<br />
Note.— Two’s complement coding is used <strong>for</strong> all signed fields as<br />
specified in §A.2.2.2.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-70 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 MSB<br />
2 FOM/SOURCE<br />
3<br />
4 LSB<br />
5 STATUS (wind speed <strong>and</strong> direction)<br />
6 MSB = 256 knots<br />
7<br />
8<br />
9 WIND SPEED<br />
10<br />
11 Range = [0, 511] knots<br />
12<br />
13<br />
14 LSB = 1 knot<br />
15 MSB = 180 degrees<br />
16<br />
17<br />
18 WIND DIRECTION (True)<br />
19<br />
20 Range = [0, 360] degrees<br />
21<br />
22<br />
23 LSB =180/256 degrees<br />
24 SIGN<br />
25 MSB = 64°C<br />
26<br />
27<br />
28<br />
29 STATIC AIR TEMPERATURE<br />
30<br />
31 Range = [–128, +128] °C<br />
32<br />
33<br />
34 LSB = 0.25°C<br />
35 STATUS<br />
36 MSB = 1 024 hPa<br />
37<br />
38<br />
39<br />
40<br />
41<br />
AVERAGE STATIC PRESSURE<br />
42<br />
43<br />
44<br />
45<br />
Range = [0, 2 048] hPa<br />
46 LSB = 1 hPa<br />
47 STATUS<br />
48 MSB TURBULENCE (see 1)<br />
49 LSB<br />
50 STATUS<br />
51<br />
52<br />
MSB = 100 %<br />
53 HUMIDITY<br />
54<br />
55<br />
Range = [0, 100] %<br />
56 LSB = 100/64 %<br />
Table A-2-68. BDS code 4,4 — Meteorological routine air report<br />
PURPOSE: To allow meteorological data to be collected by<br />
ground systems.<br />
FOM/SOURCE coding:<br />
The decimal value of the binary coded (figure of merit)<br />
FOM/SOURCE parameter shall be interpreted as follows:<br />
0 = Invalid<br />
1 = INS<br />
2 = GNSS<br />
3 = DME/DME<br />
4 = VOR/DME<br />
5 to 15 = Reserved<br />
1) The interpretation of the two bits assigned to TURBULENCE shall be as<br />
shown in the table <strong>for</strong> register 4516.<br />
Note 1.— The average static pressure is not a requirement of Annex 3.<br />
Note 2.— Two’s complement coding is used <strong>for</strong> all signed fields as<br />
specified in §A.2.2.2.<br />
Note 3.— The requirement <strong>for</strong> the range of wind speeds in Annex 3 is<br />
from 0 to 250 knots.<br />
Note 4.— The requirement <strong>for</strong> the range of static air temperature in<br />
Annex 3 is from –80° C to +60° C.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-71<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 STATUS<br />
2 MSB TURBULENCE<br />
3 LSB<br />
4 STATUS<br />
5 MSB WIND SHEAR<br />
6 LSB<br />
Table A-2-69. BDS code 4,5 — Meteorological hazard report<br />
PURPOSE: To provide reports on the severity of meteorological hazards, in<br />
particular <strong>for</strong> low flight.<br />
Hazard coding:<br />
The interpretation of the two bits assigned to each hazard shall be as<br />
defined in the table below:<br />
7 STATUS Bit 1 Bit 2<br />
8 MSB MICROBURST 0 0 NIL<br />
9 LSB 0 1 LIGHT<br />
10 STATUS 1 0 MODERATE<br />
11 MSB ICING 1 1 SEVERE<br />
12 LSB<br />
13 STATUS<br />
The definition of the terms LIGHT, MODERATE <strong>and</strong> SEVERE shall be those<br />
14 MSB WAKE VORTEX<br />
defined in the PANS-ATM (Doc 4444), where applicable.<br />
15<br />
16<br />
LSB<br />
STATUS<br />
Note 1.— The requirement <strong>for</strong> the range of static air temperature in<br />
Annex 3 is from –80° C to +60° C.<br />
17 SIGN<br />
18<br />
19<br />
MSB = 64°C<br />
Note 2.— Two’s complement coding is used <strong>for</strong> all signed fields as<br />
specified in §A.2.2.2.<br />
20<br />
21<br />
STATIC AIR TEMPERATURE<br />
22<br />
23<br />
24<br />
25<br />
Range = [–128, +128] °C<br />
26 LSB = 0.25°C<br />
27 STATUS<br />
28<br />
29<br />
30<br />
31<br />
MSB = 1 024 hPa<br />
32<br />
33<br />
AVERAGE STATIC PRESSURE<br />
34<br />
35<br />
36<br />
37<br />
Range = [0, 2 048] hPa<br />
38 LSB = 1 hPa<br />
39 STATUS<br />
40<br />
41<br />
42<br />
43<br />
MSB = 32 768 feet<br />
44<br />
45<br />
RADIO HEIGHT<br />
46<br />
47<br />
48<br />
49<br />
50<br />
Range = [0, 65 528] ft<br />
51<br />
52<br />
53<br />
LSB = 16 ft<br />
54<br />
55<br />
56<br />
RESERVED<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-72 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
1 MSB<br />
2<br />
3<br />
4<br />
5<br />
6<br />
7<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-72. BDS code 4,8 — VHF channel report<br />
PURPOSE: To allow the ATC system to monitor the settings of the VHF<br />
communications channel <strong>and</strong> to determine the manner in which each channel<br />
is being monitored by the aircrew.<br />
Channel report coding:<br />
Each VHF communications channel shall be determined <strong>for</strong>m the 15-bit<br />
positive binary number, N in kHz, according to the <strong>for</strong>mula:<br />
8 VHF 1 Channel (MHz) = Base + N x 0.001 (MHz)<br />
9<br />
10<br />
where: Base = 118.000 MHz<br />
11<br />
12<br />
13<br />
Notes. —<br />
1) The use of binary to define the channel improves the coding efficiency.<br />
2) This coding is compatible with analogue channels on 25 kHz, 8.33 kHz<br />
channel spacing <strong>and</strong> VDL as described below.<br />
14<br />
3) VDL has a full four bits allocated such that the active status of each of its<br />
15 LSB<br />
four multiplex channels can be ascertained.<br />
16 STATUS<br />
17 MSB VHF 1 25 kHz VDL: <strong>Mode</strong> 3 Analogue<br />
18 LSB AUDIO STATUS Bit<br />
19 MSB 16 Status Status<br />
20 15 (LSB) MSB (12 800 kHz) MSB (12 800 kHz)<br />
21<br />
22<br />
…<br />
Range 118.000 to 143.575 Range 118.000 to 143.575<br />
136.975 (military use) 136.975 (military use)<br />
23 6 LSB (25 kHz) LSB (25 kHz)<br />
24 5 Unused<br />
25 4 4 x channel active flags Unused<br />
26 VHF 2 3 Unused<br />
27 2 8.33 indicator = 0<br />
28<br />
29<br />
30<br />
1 (MSB) VDL indicator = 1 VDL indicator = 0<br />
31 8.33 kHz Analogue<br />
32 Bit<br />
33 LSB 16 Status<br />
34 STATUS 15 (LSB) MSB (17 066 kHz)<br />
35<br />
36<br />
MSB<br />
LSB<br />
VHF 2<br />
AUDIO STATUS<br />
…<br />
Range 118.000 to 152.112<br />
136.975 (military use)<br />
37 MSB 4 LSB (17 066/2 048 kHz)<br />
38 3 Unused<br />
39 2 8.33 indicator = 1<br />
40<br />
41<br />
42<br />
1 (MSB) VDL indicator = 0<br />
43 VHF 3<br />
44<br />
Audio status coding:<br />
45<br />
46<br />
47<br />
Each pair of audio status bits shall be used to describe the aircrew<br />
monitoring of that audio channel according to the following table:<br />
48 Bit 1 (MSB) Bit 2 (LSB)<br />
49 0 0 UNKNOWN<br />
50 0 1 NOBODY<br />
51 LSB 1 0 HEADPHONES ONLY<br />
52 STATUS 1 1 LOUDSPEAKER<br />
53 MSB VHF 3<br />
54 LSB AUDIO STATUS<br />
55 MSB 121.5 MHz<br />
56 LSB AUDIO STATUS<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-73<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 STATUS<br />
2 SIGN 1 = Left Wing Down<br />
3 MSB = 45 degrees<br />
4<br />
5<br />
6 ROLL ANGLE<br />
7<br />
8 Range = [–90, + 90] degrees<br />
9<br />
10<br />
11 LSB = 45/256 degrees<br />
12 STATUS<br />
13 SIGN 1 = West (e.g. 315 = -45 degrees)<br />
14 MSB = 90 degrees<br />
15<br />
16<br />
17 TRUE TRACK ANGLE<br />
18<br />
19 Range = [–180, +180] degrees<br />
20<br />
21<br />
22<br />
23 LSB = 90/512 degrees<br />
24 STATUS<br />
25 MSB = 1 024 knots<br />
26<br />
27<br />
28 GROUND SPEED<br />
29<br />
30 Range = [0, 2 046] knots<br />
31<br />
32<br />
33<br />
34 LSB = 1 024/512 knots<br />
35 STATUS<br />
36 SIGN 1 = Minus<br />
37 MSB = 8 degrees/second<br />
38<br />
39<br />
40 TRACK ANGLE RATE<br />
41 Range = [–16, +16] degrees/second<br />
42<br />
43<br />
44<br />
45 LSB = 8/256 degrees/second<br />
46 STATUS<br />
47 MSB = 1 024 knots<br />
48<br />
49<br />
50 TRUE AIRSPEED<br />
51<br />
52 Range = [0, 2 046] knots<br />
53<br />
54<br />
55<br />
56 LSB = 2 knots<br />
Table A-2-80. BDS code 5,0 — Track <strong>and</strong> turn report<br />
PURPOSE: To provide track <strong>and</strong> turn data to the ground systems.<br />
1) If the value of the parameter from any source exceeds the range<br />
allowable in the register definition, the maximum allowable value in<br />
the correct positive or negative sense shall be used instead.<br />
Note. — This requires active intervention by the GFM.<br />
2) The data entered into the register shall, whenever possible, be<br />
derived from the sources that are controlling the aircraft.<br />
3) If any parameter is not available on the aircraft, all bits corresponding<br />
to that parameter shall be actively set to ZERO by the GFM.<br />
4) The LSB of all fields shall be obtained by rounding.<br />
Note 1.— Two’s complement coding is used <strong>for</strong> all signed fields as<br />
specified in §A.2.2.2.<br />
Note 2.— Additional implementation guidelines are provided in<br />
§CD.2.4.5.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-74 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 STATUS (see 1)<br />
2 SIGN<br />
3 MSB = 90 degrees<br />
4<br />
5<br />
6<br />
7<br />
8<br />
9 LATITUDE<br />
10<br />
11 Range = [–180, +180] degrees<br />
12 (see 2)<br />
13<br />
14<br />
15<br />
16<br />
17<br />
18<br />
19<br />
20<br />
21 LSB = 360/1 048 576 degrees<br />
22 SIGN<br />
23 MSB = 90 degrees<br />
24<br />
25<br />
26<br />
27<br />
28 LONGITUDE<br />
29<br />
30 Range = [–180, +180] degrees<br />
31<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41 LSB = 360/1 048 576 degrees<br />
42 SIGN<br />
43 MSB = 65 536 feet<br />
44<br />
45<br />
46<br />
47 PRESSURE<br />
48 ALTITUDE<br />
49<br />
50 Range = [–1 000, +126 752] feet<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56 LSB = 8 feet<br />
Table A-2-81. BDS code 5,1 — Position report coarse<br />
PURPOSE: To provide a three-dimensional report of aircraft position.<br />
1) The single status bit (bit 1) shall only be set to ZERO (0)ONE (1) if<br />
any of the three parameters is invalid at least latitude <strong>and</strong> longitude in<br />
register 5116 <strong>and</strong> FOM in register 5216 are valid. This bit shall be<br />
identical to the status bit in register 5216.<br />
2) The required valid range <strong>for</strong> latitude is +90 degrees to –90 degrees,<br />
but the parameter shall be coded with an MSB of 90 degrees to allow<br />
the use of the same coding algorithm as <strong>for</strong> longitude.<br />
3) The source of the in<strong>for</strong>mation in this register shall be the same as<br />
that indicated in the FOM/SOURCE field of register 5216.<br />
Note.— Two’s complement coding is used <strong>for</strong> all signed fields as<br />
specified in §A.2.2.2.<br />
4) If the barometric pressure is invalid, then the field shall be set to ALL<br />
ZEROs, but the status (bit 1) shall not be affected.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-75<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 STATUS (see 1)<br />
2 MSB<br />
3 FOM/SOURCE<br />
4<br />
5 LSB<br />
6 MSB = 90/128 degrees<br />
7<br />
8<br />
9<br />
10<br />
11<br />
12<br />
13 LATITUDE FINE<br />
14<br />
15 Range = [0, 180/128] degrees<br />
16<br />
17<br />
18<br />
19<br />
20<br />
21<br />
22<br />
23 LSB = 90/16 777 216 degrees<br />
24 MSB = 90/128 degrees<br />
25<br />
26<br />
27<br />
28<br />
29<br />
30<br />
31 LONGITUDE FINE<br />
32<br />
33 Range = [0, 180/128] degrees<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41 LSB = 90/16 777 216 degrees<br />
42 SIGN<br />
43 MSB = 65 536 feet<br />
44<br />
45<br />
46<br />
47 PRESSURE-ALTITUDE<br />
48 OR<br />
49 GNSS HEIGHT (HAE)<br />
50<br />
51 (as specified by FOM / SOURCE coding)<br />
52<br />
53 Range = [–1 000, +126 752] feet<br />
54<br />
55<br />
56 LSB = 8 feet<br />
Table A-2-82. BDS code 5,2 — Position report fine<br />
PURPOSE: To provide a high-precision three-dimensional report on<br />
aircraft position when used in conjunction with register 5116.<br />
in<strong>for</strong>mation on the source of the data is included.<br />
FOM/SOURCE Coding:<br />
The decimal value of the binary-coded (Figure of Merit) FOM /<br />
SOURCE parameter shall be interpreted as follows:<br />
10 = FOM > 10 NM or Unknown Accuracy<br />
11 = FOM 10 NM/18.5 km (e.g. INS data) pressure-altitude<br />
12 = FOM 4 NM/7.4 km (e.g. VOR/DME) pressure-altitude<br />
13 = FOM 2 NM/3.7 km (e.g. DME/DME or GNSS) pressure-altitude<br />
14 = FOM 1 NM/1.85 km (e.g. DME/DME or GNSS) pressure-altitude<br />
15 = FOM 0.5 NM/926 m (e.g. DME/DME or GNSS) pressure-altitude<br />
16 = FOM 0.3 NM/555.6 m (e.g. DME/DME or GNSS) pressure-altitude<br />
17 = FOM 0.1 NM/185.2 m (ILS, MLS or differential GNSS) pressure-altitude<br />
18 = FOM 0.05 NM/92.6 m (ILS, MLS or differential GNSS) pressure-altitude<br />
19 = FOM 30 m (ILS, MLS or differential GNSS) pressure-altitude<br />
10 = FOM 10 m (ILS, MLS or differential GNSS) pressure-altitude<br />
11 = FOM 3 m (ILS, MLS or differential GNSS) pressure-altitude<br />
12 = FOM 30 m (ILS, MLS or differential GNSS) GNSS height<br />
13 = FOM 10 m (ILS, MLS or differential GNSS) GNSS height<br />
14 = FOM 3 m (ILS, MLS or differential GNSS) GNSS height<br />
15 = Reserved<br />
Note 1. — When GNSS is the source, then the FOM is encoded by<br />
the HFOM parameter. When RNP FMS is the source the FOM is encoded<br />
by the ANP.<br />
1) The single status bit (bit 1) shall only be set to ZERO (0)ONE (1) if any<br />
of the three parameters are invalid at least latitude <strong>and</strong> longitude in<br />
register 5116 <strong>and</strong> FOM in register 5216 are valid. This bit shall be <strong>and</strong> is<br />
identical to the status bit in register 5116.<br />
2) The LATITUDE (fine) <strong>and</strong> LONGITUDE (fine) parameters are in 2’s<br />
complement coding so they shall be interpreted in conjunction with the<br />
corresponding parameters in register 5116.<br />
3) When GNSS height is contained in bits 42 to 56, the pressure-altitude<br />
can be obtained from register 5116.<br />
4) If the Pressure Altitude <strong>and</strong> the GNSS Height are invalid, then the field<br />
shall be set to ALL ZEROs, but the status (bit 1) shall not be affected.<br />
Draft<br />
Note 2.— Two’s complement coding is used <strong>for</strong> all signed fields as<br />
specified in §A.2.2.2.<br />
Note 3.— The Figure of Merit selected is the smallest number that<br />
encompasses the HFOM or the ANP.<br />
Note 4.— When LATITUDE (fine) <strong>and</strong> LONGITUDE (fine) are not<br />
available, the setting of the single Status bit is not impacted, <strong>and</strong> LATITUDE<br />
(fine) <strong>and</strong> LONGITUDE (fine) are zeroed.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-76 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 STATUS<br />
2 SIGN<br />
3 MSB = 90 degrees<br />
4<br />
5<br />
6 MAGNETIC HEADING<br />
7<br />
8 Range = [–180, +180] degrees<br />
9<br />
10<br />
11<br />
12 LSB = 90/512 degrees<br />
13 STATUS<br />
14 MSB = 512 knots<br />
15<br />
16<br />
17 INDICATED AIRSPEED (IAS)<br />
18<br />
19 Range = [0, 1 023] knots<br />
20<br />
21<br />
22<br />
23 LSB = 1 knot<br />
24 STATUS<br />
25 MSB = MACH 2.048<br />
26<br />
27<br />
28 MACH NUMBER<br />
29<br />
30 Range = [0, 4.096] MACH<br />
31<br />
32<br />
33 LSB = MACH 0.008<br />
34 STATUS<br />
35 MSB = 1 024 knots<br />
36<br />
37<br />
38<br />
39<br />
40 TRUE AIRSPEED<br />
41<br />
42 Range = [0, 2 048] knots<br />
43<br />
44<br />
45<br />
46 LSB = 0.5 knots<br />
47 STATUS<br />
48 SIGN<br />
49 MSB = 8 192 feet/minute<br />
50<br />
51 ALTITUDE RATE<br />
52<br />
53 Range = [–16 384, +16 320] feet/minute<br />
54<br />
55<br />
56 LSB = 64 feet/minute<br />
Table A-2-83. BDS code 5,3 — Air-referenced state vector<br />
PURPOSE: To provide the ATC system with current measured values of<br />
magnetic heading, IAS/MACH, altitude rate <strong>and</strong> TAS.<br />
Note.— Two’s complement coding is used <strong>for</strong> all signed fields as<br />
specified in §A.2.2.2.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-77<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-84 to A-2-86. BDS codes 5,4 to 5,6 — Waypoints 1, 2 <strong>and</strong> 3<br />
1 STATUS (see 1)<br />
2 MSB<br />
3<br />
4 CHARACTER 1<br />
5<br />
6<br />
7 LSB<br />
8 MSB<br />
9<br />
10 CHARACTER 2<br />
11<br />
12<br />
13 LSB<br />
14 MSB<br />
15<br />
16 CHARACTER 3<br />
17<br />
18<br />
19 LSB<br />
20 MSB<br />
21<br />
22 CHARACTER 4<br />
23<br />
24<br />
25 LSB<br />
26 MSB<br />
27<br />
28 CHARACTER 5<br />
29<br />
30<br />
31 LSB<br />
32 MSB = 30 minutes<br />
33<br />
34 ESTIMATED TIME OF ARRIVAL<br />
35 (NORMAL FLIGHT)<br />
36<br />
37 Range = [0, 60] minutes<br />
38<br />
39<br />
40 LSB = 60/512 minutes<br />
41 MSB = 320 FL<br />
42<br />
43 ESTIMATED FLIGHT LEVEL<br />
44 (NORMAL FLIGHT)<br />
45 Range = [0, 630] FL<br />
46 LSB = 10 FL<br />
47 MSB = 30 minutes<br />
48<br />
49 TIME TO GO<br />
50 (DIRECT ROUTE)<br />
51<br />
52 Range = [0, 60] minutes<br />
53<br />
54<br />
55 LSB = 60/512 minutes<br />
56 RESERVED<br />
PURPOSE: To provide in<strong>for</strong>mation on the next three waypoints, register 5416<br />
contains in<strong>for</strong>mation on the next waypoint, register 5516 contains in<strong>for</strong>mation on<br />
the next waypoint plus one, <strong>and</strong> register 5616 contains in<strong>for</strong>mation on the next<br />
waypoint plus two.<br />
1) The single status bit shall be set to ZERO (0) if any of the parameters are<br />
invalid.<br />
2) The actual time or flight level shall be calculated from the trajectory<br />
scheduled in the FMS.<br />
Note.— <strong>Mode</strong> detail on the next waypoint is given in register 4116 to 4316.<br />
3) When the waypoint identity has only three characters, two leading ZERO<br />
characters shall be added (e.g. CDN becomes 00CDN).<br />
4) Estimated time is in minutes <strong>and</strong> all ones shall be used to indicate that the<br />
waypoint referred to is one hour or more away.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-78 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 MSB MCP/FCU SELECTED ALTITUDE<br />
2 LSB<br />
3<br />
4<br />
RESERVED<br />
5<br />
6<br />
RESERVED<br />
7<br />
8<br />
RESERVED<br />
9<br />
10<br />
RESERVED<br />
11<br />
12<br />
RESERVED<br />
13 MSB NEXT WAYPOINT<br />
14 LSB<br />
15<br />
16<br />
RESERVED<br />
17 MSB FMS VERTICAL MODE<br />
18 LSB<br />
19 MSB VHF CHANNEL REPORT<br />
20 LSB<br />
21 MSB METEOROLOGICAL HAZARDS<br />
22 LSB<br />
23 MSB FMS SELECTED ALTITUDE<br />
24 LSB<br />
25 MSB BAROMETRIC PRESSURE<br />
26<br />
27<br />
28<br />
29<br />
30<br />
31<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40<br />
LSB SETTING MINUS 800 mb<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
47<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56<br />
RESERVED<br />
Table A-2-95. BDS code 5,F — Quasi-static parameter monitoring<br />
PURPOSE: To permit the monitoring of changes in parameters that do<br />
not normally change very frequently, i.e., those expected to be stable <strong>for</strong><br />
5 minutes or more by accessing a single register.<br />
Parameter Monitor Coding:<br />
1) The changing of each parameter shall be monitored by 2 bits.<br />
The value 00 shall indicate that no valid data are available on this<br />
parameter. The decimal value <strong>for</strong> this 2-bit field shall be cycled<br />
through 1, 2 <strong>and</strong> 3, each step indicating a change in the monitored<br />
parameter.<br />
2) The meteorological hazards subfield shall report changes to<br />
turbulence, wind shear, wake vortex, icing <strong>and</strong> microburst, as in<br />
register number 4516.<br />
3) The next waypoint subfield shall report change to data contained in<br />
registers 4116, 4216 <strong>and</strong> 4316.<br />
4) The FMS vertical mode shall report change to bits 48 to 51 in<br />
register 4016.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-79<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 STATUS<br />
2 SIGN 1=West (e.g. 315 = -45 degrees)<br />
3 MSB = 90 degrees<br />
4<br />
5<br />
6 MAGNETIC HEADING<br />
7<br />
8 Range = [–180, +180] degrees<br />
9<br />
10<br />
11<br />
12 LSB = 90/512 degrees<br />
13 STATUS<br />
14 MSB = 512 knots<br />
15<br />
16<br />
17 INDICATED AIRSPEED<br />
18<br />
19 Range = [0, 1023] knots<br />
20<br />
21<br />
22<br />
23 LSB = 1 knot<br />
24 STATUS<br />
25 MSB = 2.048 MACH<br />
26<br />
27<br />
28 MACH<br />
29<br />
30 Range = [0, 4.092] MACH<br />
31<br />
32<br />
33<br />
34 LSB = 2.048/512 MACH<br />
35 STATUS<br />
36 SIGN 1 = Below<br />
37 MSB = 8 192 feet/minute<br />
38<br />
39<br />
40 BAROMETRIC ALTITUDE RATE<br />
41<br />
42 Range = [–16 384, +16 352] feet/minute<br />
43<br />
44<br />
45 LSB = 8 192/256 = 32 feet/minute<br />
46 STATUS<br />
47 SIGN 1 = Below<br />
48 MSB = 8 192 feet/minute<br />
49<br />
50<br />
51 INERTIAL VERTICAL VELOCITY<br />
52<br />
53 Range = [–16 384, +16 352] feet/minute<br />
54<br />
55<br />
56 LSB = 8 192/256 = 32 feet/minute<br />
Table A-2-96. BDS code 6,0 — Heading <strong>and</strong> speed report<br />
PURPOSE: To provide heading <strong>and</strong> speed data to ground systems.<br />
1) If the value of a parameter from any source exceeds the range<br />
allowable in the register definition, the maximum allowable value in the<br />
correct positive or negative sense shall be used instead.<br />
Note.— This requires active intervention by the GFM.<br />
2) The data entered into the register shall whenever possible be derived<br />
from the sources that are controlling the aircraft.<br />
3) The LSB of all fields shall be obtained by rounding.<br />
4) When barometric altitude rate is integrated <strong>and</strong> smoothed with inertial<br />
vertical velocity (baro-inertial in<strong>for</strong>mation), it shall be transmitted in the<br />
Inertial Vertical Velocity field.<br />
Note 1.— Barometric Altitude Rate contains values solely derived from<br />
barometric measurement. The Barometric Altitude<br />
Rate is usually very unsteady <strong>and</strong> may suffer from<br />
barometric instrument inertia.<br />
Note 2.— The Inertial Vertical Velocity is also providing in<strong>for</strong>mation<br />
on vertical movement of the aircraft but it comes from<br />
equipments (IRS, AHRS) using different sources used <strong>for</strong><br />
navigation. The in<strong>for</strong>mation is a more filtered <strong>and</strong> smooth<br />
parameter.<br />
Note 3. — Two’s complement coding is used <strong>for</strong> all signed fields as<br />
specified in §A.2.2.2.<br />
Note 4.— Additional implementation guidelines are provided in<br />
§CD.2.4.6.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-80 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-97. BDS code 6,1 — <strong>Extended</strong> squitter emergency/priority status<br />
1<br />
2<br />
MSB PURPOSE: To provide additional in<strong>for</strong>mation on aircraft status.<br />
3 FORMAT TYPE CODE = 28<br />
4 Subtype shall be coded as follows:<br />
5 LSB<br />
6 MSB 0 = No in<strong>for</strong>mation<br />
7 SUBTYPE CODE = 1 1 = Emergency/priority status<br />
8 LSB 2 to 7 = Reserved<br />
9 MSB<br />
10 EMERGENCY STATE<br />
11<br />
12<br />
LSB Emergency state shall be coded as follows:<br />
13 Value Meaning<br />
14 0 No emergency<br />
15 1 General emergency<br />
16 2 Lifeguard/Medical<br />
17 3 Minimum fuel<br />
18 4 No communications<br />
19 5 Unlawful interference<br />
20 6 Reserved<br />
21<br />
22<br />
7 Reserved<br />
23<br />
1) Message delivery shall be accomplished once per 0.8 seconds using<br />
24<br />
the event-driven protocol.<br />
25<br />
26<br />
27<br />
2) Termination of emergency state shall be detected by coding in the<br />
surveillance status field of the airborne position message.<br />
28<br />
29<br />
3) Emergency State value 1 shall be set when <strong>Mode</strong> A code 7700 is<br />
provided to the transponder.<br />
30<br />
4) Emergency State value 4 shall be set when <strong>Mode</strong> A code 7600 is<br />
31<br />
provided to the transponder.<br />
32<br />
33<br />
34 RESERVED<br />
5) Emergency State value 5 shall be set when <strong>Mode</strong> A code 7500 is<br />
provided to the transponder.<br />
35<br />
Note.—The data in this register is not intended <strong>for</strong> extraction using<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
47<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56<br />
GICB or ACAS cross-link protocols. The read out of this register is<br />
discouraged since the contents are indeterminate.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-81<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-101. BDS code 6,5 — <strong>Extended</strong> squitter aircraft operational status<br />
1<br />
2<br />
MSB<br />
3<br />
4<br />
FORMAT TYPE CODE = 31<br />
5 LSB<br />
6 MSB<br />
7 SUBTYPE CODE = 0<br />
8 LSB<br />
9 MSB<br />
10 EN-ROUTE OPERATIONAL<br />
11 CAPABILITIES (CC-4)<br />
12 LSB (specified in §A.2.3.11.3)<br />
13 MSB<br />
14 TERMINAL AREA OPERATIONAL<br />
15 CAPABILITIES (CC-3)<br />
16 LSB (specified in §A.2.3.11.4)<br />
17 MSB<br />
18 APPROACH/LANDING OPERATIONAL<br />
19 CAPABILITIES (CC-2)<br />
20 LSB (specified in §A.2.3.11.5)<br />
21 MSB<br />
22 SURFACE OPERATIONAL<br />
23 CAPABILITIES (CC-1)<br />
24 LSB (specified in §A.2.3.11.6)<br />
25 MSB<br />
26 EN-ROUTE OPERATIONAL CAPABILITY<br />
27 STATUS (OM-4)<br />
28 LSB (specified in §A.2.3.11.7)<br />
29 MSB<br />
30 TERMINAL AREA OPERATIONAL CAPABILITY<br />
31 STATUS (OM-3)<br />
32 LSB (specified in §A.2.3.11.8)<br />
33 MSB<br />
34 APPROACH/LANDING OPERATIONAL CAPABILITY<br />
35 STATUS (OM-2)<br />
36 LSB (specified in §A.2.3.11.9)<br />
37 MSB<br />
38 SURFACE OPERATIONAL CAPABILITY<br />
39 STATUS (OM-1)<br />
40<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
47<br />
LSB (specified in §A.2.3.11.10)<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56<br />
RESERVED<br />
PURPOSE: To provide the capability class <strong>and</strong> current operational mode<br />
of ATC-related applications on board the aircraft.<br />
1) Message delivery shall be accomplished using the event-driven<br />
protocol.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-82 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-227. BDS code E,3 — Transponder type / part number<br />
1 STATUS<br />
2 MSB FORMAT TYPE<br />
3 LSB<br />
4 MSB MSB<br />
5 P/N<br />
6 Digit 1 CHARACTER 1<br />
7 LSB<br />
8 MSB<br />
9 P/N LSB<br />
10 Digit 2 MSB<br />
11 LSB<br />
12 MSB CHARACTER 2<br />
13 P/N<br />
14 Digit 3<br />
15 LSB LSB<br />
16 MSB MSB<br />
17 P/N<br />
18 Digit 4 CHARACTER 3<br />
19 LSB<br />
20 MSB<br />
21 P/N LSB<br />
22 Digit 5 MSB<br />
23 LSB<br />
24 MSB CHARACTER 4<br />
25 P/N<br />
26 Digit 6<br />
27 LSB LSB<br />
28 MSB MSB<br />
29 P/N<br />
30 Digit 7 CHARACTER 5<br />
31 LSB<br />
32 MSB<br />
33 P/N LSB<br />
34 Digit 8 MSB<br />
35 LSB<br />
36 MSB CHARACTER 6<br />
37 P/N<br />
38 Digit 9<br />
39 LSB LSB<br />
40 MSB MSB<br />
41 P/N<br />
42 Digit 10 CHARACTER 7<br />
43 LSB<br />
44 MSB<br />
45 P/N LSB<br />
46 Digit 11 MSB<br />
47 LSB<br />
48 MSB CHARACTER 8<br />
49 P/N<br />
50 Digit 12<br />
51<br />
52<br />
53<br />
LSB LSB<br />
54<br />
55<br />
56<br />
RESERVED RESERVED<br />
PURPOSE: To provide <strong>Mode</strong> S transponder part number or type as<br />
defined by the supplier.<br />
FORMAT TYPE CODING:<br />
Bit 2 Bit 3<br />
0 0 = Part number (P/N) coding<br />
0 1 = Character coding<br />
1 0 = Reserved<br />
1 1 = Reserved<br />
1) When available it is recommended to use the part number. P/N Digits<br />
are BCD encoded. Digit 1 is the first left digit of the part number.<br />
2) If the part number is not available, the first 8 characters of the<br />
commercial name can be used with the <strong>for</strong>mat type “01.”<br />
3) If <strong>for</strong>mat type “01” is used, the coding of character 1 to 8 shall be as<br />
defined in Table 3-7 of Chapter 3, Annex 10, Volume IV. Character 1 is<br />
the first left character of the transponder type.<br />
4) For operational reasons, some military installations may not implement<br />
this <strong>for</strong>mat.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-83<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-228. BDS code E,4 — Transponder software revision number<br />
1 STATUS<br />
2 MSB FORMAT TYPE<br />
3 LSB<br />
4 MSB MSB<br />
5 P/N<br />
6 Digit 1 CHARACTER 1<br />
7 LSB<br />
8 MSB<br />
9 P/N LSB<br />
10 Digit 2 MSB<br />
11 LSB<br />
12 MSB CHARACTER 2<br />
13 P/N<br />
14 Digit 3<br />
15 LSB LSB<br />
16 MSB MSB<br />
17 P/N<br />
18 Digit 4 CHARACTER 3<br />
19 LSB<br />
20 MSB<br />
21 P/N LSB<br />
22 Digit 5 MSB<br />
23 LSB<br />
24 MSB CHARACTER 4<br />
25 P/N<br />
26 Digit 6<br />
27 LSB LSB<br />
28 MSB MSB<br />
29 P/N<br />
30 Digit 7 CHARACTER 5<br />
31 LSB<br />
32 MSB<br />
33 P/N LSB<br />
34 Digit 8 MSB<br />
35 LSB<br />
36 MSB CHARACTER 6<br />
37 P/N<br />
38 Digit 9<br />
39 LSB LSB<br />
40 MSB MSB<br />
41 P/N<br />
42 Digit 10 CHARACTER 7<br />
43 LSB<br />
44 MSB<br />
45 P/N LSB<br />
46 Digit 11 MSB<br />
47 LSB<br />
48 MSB CHARACTER 8<br />
49 P/N<br />
50 Digit 12<br />
51<br />
52<br />
53<br />
LSB LSB<br />
54<br />
55<br />
56<br />
RESERVED RESERVED<br />
PURPOSE: To provide <strong>Mode</strong> S transponder software revision number as<br />
defined by the supplier.<br />
FORMAT TYPE CODING:<br />
Bit 2 Bit 3<br />
0 0 = Part number (P/N) coding<br />
0 1 = Character coding<br />
1 0 = Reserved<br />
1 1 = Reserved<br />
1) When a part number is allocated to the software revision, it is<br />
recommended to use the <strong>for</strong>mat type “00.” In this case, P/N Digits are<br />
BCD encoded. Digit 1 is the first left digit of the part number.<br />
2) If <strong>for</strong>mat type “01” is used, the coding of character 1 to 8 shall be as<br />
defined in Table 3-9 of Chapter 3, Annex 10, Volume IV. Character 1<br />
is the first left character of the software revision number.<br />
3) For operational reasons, some military installations may not<br />
implement this <strong>for</strong>mat.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-84 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 STATUS<br />
2 MSB FORMAT TYPE<br />
3 LSB<br />
4 MSB MSB<br />
5 P/N<br />
6 Digit 1 CHARACTER 1<br />
7 LSB<br />
8 MSB<br />
9 P/N LSB<br />
10 Digit 2 MSB<br />
11 LSB<br />
12 MSB CHARACTER 2<br />
13 P/N<br />
14 Digit 3<br />
15 LSB LSB<br />
16 MSB MSB<br />
17 P/N<br />
18 Digit 4 CHARACTER 3<br />
19 LSB<br />
20 MSB<br />
21 P/N LSB<br />
22 Digit 5 MSB<br />
23 LSB<br />
24 MSB CHARACTER 4<br />
25 P/N<br />
26 Digit 6<br />
27 LSB LSB<br />
28 MSB MSB<br />
29 P/N<br />
30 Digit 7 CHARACTER 5<br />
31 LSB<br />
32 MSB<br />
33 P/N LSB<br />
34 Digit 8 MSB<br />
35 LSB<br />
36 MSB CHARACTER 6<br />
37 P/N<br />
38 Digit 9<br />
39 LSB LSB<br />
40 MSB MSB<br />
41 P/N<br />
42 Digit 10 CHARACTER 7<br />
43 LSB<br />
44 MSB<br />
45 P/N LSB<br />
46 Digit 11 MSB<br />
47 LSB<br />
48 MSB CHARACTER 8<br />
49 P/N<br />
50 Digit 12<br />
51<br />
52<br />
53<br />
LSB LSB<br />
54<br />
55<br />
56<br />
RESERVED RESERVED<br />
Table A-2-229. BDS code E,5 — ACAS unit part number<br />
PURPOSE: To provide ACAS unit part number or type as defined by the<br />
supplier.<br />
FORMAT TYPE CODING:<br />
Bit 2 Bit 3<br />
0 0 = Part number (P/N) coding<br />
0 1 = Character coding<br />
1 0 = Reserved<br />
1 1 = Reserved<br />
1) When available it is recommended to use the part number. P/N Digits<br />
are BCD encoded. Digit 1 is the first left digit of the part number.<br />
2) If the part number is not available, the first 8 characters of the<br />
commercial name can be used with the <strong>for</strong>mat type “01.”<br />
3) If <strong>for</strong>mat type “01” is used, the coding of character 1 to 8 shall be as<br />
defined in Table 3-9 of Chapter 3, Annex 10, Volume IV. Character 1<br />
is the first left character of the ACAS unit type.<br />
4) For operational reasons, some military installations may not<br />
implement this <strong>for</strong>mat.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-85<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-230. BDS code E,6 — ACAS unit software revision<br />
1 STATUS<br />
2 MSB FORMAT TYPE<br />
3 LSB<br />
4 MSB MSB<br />
5 P/N<br />
6 Digit 1 CHARACTER 1<br />
7 LSB<br />
8 MSB<br />
9 P/N LSB<br />
10 Digit 2 MSB<br />
11 LSB<br />
12 MSB CHARACTER 2<br />
13 P/N<br />
14 Digit 3<br />
15 LSB LSB<br />
16 MSB MSB<br />
17 P/N<br />
18 Digit 4 CHARACTER 3<br />
19 LSB<br />
20 MSB<br />
21 P/N LSB<br />
22 Digit 5 MSB<br />
23 LSB<br />
24 MSB CHARACTER 4<br />
25 P/N<br />
26 Digit 6<br />
27 LSB LSB<br />
28 MSB MSB<br />
29 P/N<br />
30 Digit 7 CHARACTER 5<br />
31 LSB<br />
32 MSB<br />
33 P/N LSB<br />
34 Digit 8 MSB<br />
35 LSB<br />
36 MSB CHARACTER 6<br />
37 P/N<br />
38 Digit 9<br />
39 LSB LSB<br />
40 MSB MSB<br />
41 P/N<br />
42 Digit 10 CHARACTER 7<br />
43 LSB<br />
44 MSB<br />
45 P/N LSB<br />
46 Digit 11 MSB<br />
47 LSB<br />
48 MSB CHARACTER 8<br />
49 P/N<br />
50 Digit 12<br />
51<br />
52<br />
53<br />
LSB LSB<br />
54<br />
55<br />
56<br />
RESERVED RESERVED<br />
PURPOSE: To provide ACAS unit software revision number<br />
as defined by the supplier.<br />
FORMAT TYPE CODING:<br />
Bit 2 Bit 3<br />
0 0 = Part number (P/N) coding<br />
0 1 = Character coding<br />
1 0 = Reserved<br />
1 1 = Reserved<br />
1) When available it is recommended to use the part number. P/N Digits<br />
are BCD encoded. Digit 1 is the first left digit of the part number.<br />
2) If <strong>for</strong>mat type “01” is used, the coding of character 1 to 8 shall be as<br />
defined in Table 3-9 of Chapter 3, Annex 10, Volume IV. Character 1<br />
is the first left character of the ACAS unit software revision.<br />
3) For operational reasons, some military installations may not<br />
implement this <strong>for</strong>mat.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-86 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-231. BDS code E,7 — Transponder status <strong>and</strong> diagnostics<br />
1 MSB PURPOSE: To report the configuration <strong>and</strong> status of the transponder<br />
2<br />
3<br />
at any given GICB request.<br />
4<br />
5<br />
BDS Register Number = E,7 The coding of this Register shall con<strong>for</strong>m to:<br />
6 SDI Code shall be coded as follows:<br />
7 “00” = Not Used “01” = Side 1<br />
8 LSB “10” = Side 2 “11” = Not Used<br />
9 MSB SDI Code<br />
10 LSB Non-Diversity Transponder shall be coded as follows:<br />
11 Non-Diversity Transponder “0” = Diversity “1” = Non-Diversity<br />
12 Diversity Failure<br />
13 Upper Receiver Failure Bits 12 through 16, <strong>and</strong> 24 through 26 shall be coded as follows:<br />
14 Lower Receiver Failure “0” = Ok “1” = Failure<br />
15 Upper <strong>Squitter</strong> Failure<br />
16 Lower <strong>Squitter</strong> Failure Bits 17 through 20, <strong>and</strong> Bit 23 shall be coded as follows:<br />
17 Air/Ground #1 Input Status “0” = Inactive or Unknown<br />
18 Air/Ground #2 Input Status “1” = Active<br />
19 GPS Time Mark #1 Status<br />
20 GPS Time Mark #2 Status <strong>Mode</strong> S Limiting During Power-ON Cycle shall be coded as follows:<br />
21 <strong>Mode</strong> S Limiting During Power-ON Cycle “0” = No Limiting Event<br />
22 <strong>Mode</strong> S Limiting “1” = Active (e.g., In Limiting)<br />
23 <strong>Extended</strong> <strong>Squitter</strong> Disable Status<br />
24 TCAS Input Inactive Bits 24 through 26 shall be coded as follows:<br />
25 ADS-B Out Status “0” = Active “1” = Inactive or Failed<br />
26 Selected Control Inactive or Failure<br />
27 MSB Control Input Selection Control Input Selection shall be coded as follows:<br />
28 LSB “00” = Burst Time “01” = Port A or 1<br />
29 MSB Multiple Air Data Source Reporting “10” = Port B or 2 “11” = Port C or 3<br />
30 LSB Selection (e.g.,, Source in Use)<br />
31 Altitude Alternate Port Selection Bits 29 through 30 <strong>and</strong> 41 through 42 shall be coded as follows:<br />
32 MSB Altitude Port A Status “00” = No Data or Not Used “01” = Source #1 is being Used<br />
33 LSB “10” = Source #2 is being used “11” = Source # 3 is being Used<br />
34 MSB Altitude Port B Status<br />
35 LSB Altitude Alternate Port Selection shall be coded as follows:<br />
36 FMC/GNSS Source Select “0” = Port A Selected<br />
37 MSB FMC/GNSS #1 Bus Status “1” = Alternate Port Selection is Active, e.g., Port B selected<br />
38 LSB<br />
39 MSB FMC/GNSS #2 Bus Status Bits 32 through 35, 37 through 40, 44 through 47, <strong>and</strong> 49 through 56<br />
40 LSB shall be coded as follows:<br />
41 MSB Multiple IRS/AHRS Data Source “00” = No Data or Not Used “01” = Active<br />
42 LSB Reporting Selection (e.g., source in Use) “10” = Inactive “11” = Fail<br />
43 IRS/FMS Source Select<br />
44 MSB IRS/FMS/Data Concentrator In #1 Bits 36, 43, <strong>and</strong> 48 shall be coded as follows:<br />
45 LSB “0” = Port #1 Selected<br />
46 MSB IRS/FMS/Data Concentrator In #2 “1” = Port #2 Selected<br />
47 LSB<br />
48 FMC Select<br />
49 MSB FMC #1/Gen. In Bus Status<br />
50 LSB<br />
51 MSB FMC #2/Gen. In Bus Status<br />
52 LSB<br />
53 MSB MSP/ATSU/CMU In #1 Status<br />
54 LSB<br />
55 MSB MSP/ATSU/CMU In #2 Status<br />
56 LSB<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-87<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table A-2-234. BDS code E,A — Vendor specific status <strong>and</strong> diagnostics<br />
1 MSB PURPOSE: To report diagnostic status <strong>and</strong> configuration in<strong>for</strong>mation<br />
2<br />
3<br />
in a <strong>for</strong>mat defined by the transponder manufacturer.<br />
4 BDS Register Number “E,A” 1) This Register allows manufacturers to define configuration <strong>and</strong><br />
5 status data that may be specific to their implementation or<br />
6 installation. This Register is designed to be a compliment to<br />
7 Register E716.<br />
8 LSB<br />
9 2) This Register should only be serviced if the transponder hardware<br />
10 <strong>and</strong> software can be identified via service of Register E316 <strong>and</strong>/or<br />
11<br />
12<br />
13<br />
14<br />
15<br />
16<br />
17<br />
18<br />
19<br />
20<br />
21<br />
22<br />
23<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29<br />
30<br />
31<br />
Register E416.<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
47<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56<br />
Manufacturer defined diagnostic field<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-88 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 STATUS<br />
2 Character Field (see 1 )<br />
3 C1<br />
4 A1<br />
5 C2<br />
6 A2<br />
7 C4<br />
8 A 4 MODE 1 CODE<br />
9 X<br />
10 B1<br />
11 D1<br />
12 B2<br />
13 D2<br />
14 B4<br />
15 D4<br />
16 STATUS<br />
17 C1<br />
18 A1<br />
19 C2<br />
20 A2<br />
21 C4<br />
22 A 4 MODE 2 CODE<br />
23 X<br />
24 B1<br />
25 D1<br />
26 B2<br />
27 D2<br />
28 B4<br />
29 D4<br />
30<br />
31<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41<br />
42 RESERVED<br />
43<br />
44<br />
45<br />
46<br />
47<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56<br />
Table A-2-241. BDS code F,1 — Military applications<br />
PURPOSE: To provide data in support of military applications.<br />
1) The character field shall be used to indicate whether 2 characters or<br />
4 characters are used in the <strong>Mode</strong> 1 code. The logic shall be as<br />
follows:<br />
0 = 2 octal codes<br />
(A1 — A4 <strong>and</strong> B1 — B4)<br />
1 = 4 octal codes<br />
(A1 — A4, B1 — B4, C1 — C4 <strong>and</strong> D1 — D4)<br />
2) The status fields shall be used to indicate whether the data are<br />
available or unavailable. The logic shall be as follows:<br />
0 = Unavailable<br />
1 = Available<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-89<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1<br />
2<br />
MSB<br />
3<br />
4<br />
AF=2, TYPE CODE = 1<br />
5 LSB<br />
6 STATUS<br />
7 CHARACTER FIELD (see 1)<br />
8 C1<br />
9 A1<br />
10 C2<br />
11 A2<br />
12 C4<br />
13 A4<br />
14 X MODE 1 CODE<br />
15 B1<br />
16 D1<br />
17 B2<br />
18 D2<br />
19 B4<br />
20 D4<br />
21 STATUS<br />
22 C1<br />
23 A1<br />
24 C2<br />
25 A2<br />
26 C4<br />
27 A4<br />
28 X MODE 2 CODE<br />
29 B1<br />
30 D1<br />
31 B2<br />
32 D2<br />
33 B4<br />
34 D4<br />
35 STATUS<br />
36 C1<br />
37 A1<br />
38 C2<br />
39 A2<br />
40 C4<br />
41 A4<br />
42 X MODE A CODE<br />
43 B1<br />
44 D1<br />
45 B2<br />
46 D2<br />
47 B4<br />
48<br />
49<br />
50<br />
51<br />
D4<br />
52<br />
53<br />
54<br />
55<br />
56<br />
RESERVED<br />
Table A-2-242. BDS code F,2 — Military applications<br />
PURPOSE: This register is used <strong>for</strong> military applications involving DF=19.<br />
Its purpose is to provide data in support of military applications.<br />
‘TYPE CODE’ shall be encoded as follows:<br />
0 = UnassignedReserved<br />
1 = <strong>Mode</strong> code in<strong>for</strong>mation<br />
2-31 = UnassignedReserved<br />
1) The character field shall be used to indicate whether 2 characters or 4<br />
characters are used in the <strong>Mode</strong> 1 code. The logic shall be as follows:<br />
0 = 2 octal codes<br />
(A1 — A4 <strong>and</strong> B1 — B4)<br />
1 = 4 octal codes<br />
(A1 — A4, B1 — B4, C1 — C4 <strong>and</strong> D1 — D4)<br />
2) The status fields shall be used to indicate whether the data are available or<br />
unavailable. The logic shall be as follows:<br />
0 = Unavailable<br />
1 = Available<br />
DF = 19 Application Field (AF) shall be encoded as follows:<br />
0 = Reserved <strong>for</strong> civil extended squitter <strong>for</strong>mats<br />
1 = Reserved <strong>for</strong> <strong>for</strong>mation flight<br />
2 = Reserved <strong>for</strong> military applications<br />
3–7 = Reserved<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-90 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.3. FORMATS FOR MODE S SPECIFIC PROTOCOLS (MSP)<br />
A.3.1 MSP CHANNEL NUMBER ALLOCATIONS<br />
The details of protocols <strong>and</strong> data transfers shall be as specified in the following paragraphs.<br />
Note.— Some MSP channel numbers have been assigned (see Annex 10, Volume III, Part I, Chapter 5, Table 5-25).<br />
A.3.2 UPLINK MSP CHANNELS<br />
The following sections are numbered §A.3.2.X, where ‘X’ is the decimal equivalent of the uplink MSP channel number.<br />
This shall be done to allow definitions of the hitherto undefined <strong>for</strong>mats to be inserted without affecting the paragraph<br />
numbers.<br />
For MSP packet <strong>for</strong>mats refer to Annex 10, Volume III, Part I, Chapter 5.<br />
(Reserved <strong>for</strong> specific services management)<br />
The description of this channel has not yet been developed.<br />
A.3.2.2.1 PURPOSE<br />
A.3.2.1 UPLINK MSP CHANNEL 1<br />
A.3.2.2 UPLINK MSP CHANNEL 2: TRAFFIC INFORMATION SERVICE (TIS)<br />
The TIS shall have the capability to generate automatic alert in<strong>for</strong>mation on any aircraft that carries an operating<br />
transponder (<strong>Mode</strong> A/C or <strong>Mode</strong> S). Aircraft that are under primary radar tracking can also be used to generate reports.<br />
Draft<br />
Note.— The traffic in<strong>for</strong>mation service (TIS) is intended to improve the safety <strong>and</strong> efficiency of “see <strong>and</strong> avoid” flight<br />
by providing the pilot with an automatic display of nearby traffic <strong>and</strong> warnings of any potentially threatening traffic<br />
conditions. The TIS is functionally equivalent to ACAS I, providing traffic advisories but no resolution advisory<br />
in<strong>for</strong>mation. By utilizing the surveillance database maintained by <strong>Mode</strong> S ground interrogators <strong>and</strong> its data link, the TIS<br />
can provide airborne traffic alerting with a minimum airborne equipage requirement. The TIS is provided without any<br />
ATC involvement.<br />
A.3.2.2.2 TIS UPLINK MESSAGE FORMATS<br />
All TIS uplink messages shall be structured as shown below. Each TIS uplink message shall be 56 bits. TIS traffic data<br />
messages shall consist of one or more short-<strong>for</strong>m MSP packets. There shall be three types of TIS uplink messages as<br />
follows:<br />
1) “Keep-alive”<br />
2) “Goodbye”<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
3) “Traffic data”<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-91<br />
Header<br />
Message<br />
type<br />
Traffic<br />
block 1<br />
Traffic<br />
block 2<br />
8 bits 6 bits 21 bits 21 bits<br />
Note.— The <strong>for</strong>mats of TIS downlink messages are defined in §A.4 of this appendix under broadcast identifier 0216.<br />
A.3.2.2.2.1 Message header<br />
The 8-bit header shall be present in all TIS messages. The message header <strong>for</strong> TIS shall have the value 02<br />
(hexadecimal), since all TIS messages utilize the short-<strong>for</strong>m MSP protocol <strong>and</strong> TIS is assigned MSP channel 2.<br />
A.3.2.2.2.2 Message type<br />
The 6-bit message type field shall be used to differentiate the different types of uplink messages:<br />
Message type value TIS message uplink type<br />
0 to 59 Traffic data, first segment (own-heading)<br />
60 Traffic data, intermediate segment(s)<br />
61 Traffic data, final segment<br />
62 Goodbye<br />
63 Keep-alive<br />
In the case of “first segment” traffic data messages, the 6-bit message type field shall contain the <strong>Mode</strong> S interrogatorderived<br />
tracked own-heading of the aircraft receiving the TIS message. This heading shall be quantized in 6 degree<br />
increments <strong>and</strong> shall be expressed with reference to magnetic north at the interrogator. The own-heading value in traffic<br />
data messages shall be provided to permit display heading correction on board the TIS-equipped aircraft by using an<br />
airborne heading sensor.<br />
Note.— Such a heading correction may be necessary when the aircraft is manoeuvring or crabbing due to wind.<br />
Draft<br />
Since there may be several TIS traffic data messages to a given aircraft during a given scan, TIS processing shall be<br />
able to group the TIS traffic data uplinks together correctly. The “first”, “intermediate”, <strong>and</strong> “final” segment type values<br />
shall provide the necessary in<strong>for</strong>mation to per<strong>for</strong>m this grouping process. The mechanism <strong>for</strong> this shall be as specified<br />
below. Buffer space <strong>for</strong> at least 4 TIS traffic data messages (eight aircraft) shall be provided.<br />
A.3.2.2.2.2.1 Keep-alive message<br />
The TIS keep-alive message shall contain the message header <strong>and</strong> the message type fields as described above. The<br />
message type field shall be set to 63 decimal. The remaining bits of the message shall be unused.<br />
A.3.2.2.2.2.2 Goodbye message<br />
The TIS goodbye message shall contain the message header <strong>and</strong> the message type fields as described above. The<br />
message type field shall be set to 62 decimal. The remaining bits of the message shall be unused.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-92 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.3.2.2.2.3 Traffic in<strong>for</strong>mation block<br />
Each TIS traffic data message shall contain two 21-bit traffic in<strong>for</strong>mation blocks whose structure is shown below. The six<br />
fields in a traffic in<strong>for</strong>mation block shall describe one TIS alert aircraft. One TIS traffic data message shall be able to<br />
define one or two alert aircraft.<br />
Note.— A number ‘n’ of TIS traffic data messages may be uplinked in a given scan to convey in<strong>for</strong>mation on up to<br />
2n alert aircraft.<br />
Traffic bearing Traffic range Relative altitude Altitude rate Traffic heading Traffic status<br />
A.3.2.2.2.3.1 Traffic bearing<br />
6 bits 4 bits 5 bits 2 bits 3 bits 1 bit<br />
The 6-bit traffic bearing field shall contain the bearing angle from the own-aircraft heading to the alert aircraft, quantized<br />
in 6 degree increments. The valid range <strong>for</strong> the traffic bearing field shall be 0 to 59 (with the exception described below).<br />
Note.— Since this bearing angle is defined by TIS with respect to its measured own-aircraft heading, corrections<br />
from an airborne heading source can be applied.<br />
If there is only one alert aircraft in a given TIS traffic data message, the traffic bearing field in the unused traffic<br />
in<strong>for</strong>mation block shall be set to the value 63 (a bearing angle greater than 360 degrees) <strong>and</strong> the remainder of the bits in<br />
the traffic in<strong>for</strong>mation block shall be ignored. This shall be termed as a “null alert” block.<br />
A.3.2.2.2.3.2 Traffic range<br />
The 4-bit traffic range field shall contain the distance between own-aircraft <strong>and</strong> the alert aircraft. A non-linear range<br />
encoding shall be used to minimize the number of bits required <strong>for</strong> this field as follows:<br />
Traffic range<br />
value (r)<br />
Range<br />
(in increments of 230 m (0.125 NM))<br />
Draft<br />
0 0 < r ≤ 1<br />
1 1 < r ≤ 3<br />
2 3 < r ≤ 5<br />
3 5 < r ≤ 7<br />
4 7 < r ≤ 9<br />
5 9 < r ≤ 11<br />
6 11 < r ≤ 13<br />
7 13 < r ≤ 15<br />
8 15 < r ≤ 18<br />
9 18 < r ≤ 22<br />
10 22 < r ≤ 28<br />
11 28 < r ≤ 36<br />
12 36 < r ≤ 44<br />
13 44 < r ≤ 52<br />
14 52 < r ≤ 56<br />
15 r > 56<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-93<br />
A.3.2.2.2.3.3 Relative altitude<br />
The 5-bit relative altitude field shall contain the difference in altitude between the own-aircraft <strong>and</strong> the alert aircraft. A<br />
non-linear encoding shall be used to minimize the number of bits required <strong>for</strong> this field. A special encoding value shall be<br />
used to indicate that the alert aircraft has no reported altitude. By convention, a positive value in the relative altitude field<br />
shall indicate that the alert aircraft is above the own-aircraft.<br />
Relative altitude shall be given by:<br />
where altitudes are indicated in feet.<br />
The TIS encoding <strong>for</strong> relative altitude shall be:<br />
Relative altitude = AltitudeAlert aircraft – AltitudeOwn-aircraft<br />
Relative altitude value<br />
(alt) Relative altitude (feet)<br />
0 0 ≤ alt ≤ +100<br />
1 +100 < alt ≤ +200<br />
2 +200 < alt ≤ +300<br />
3 +300 < alt ≤ +400<br />
4 +400 < alt ≤ +500<br />
5 +500 < alt ≤ +600<br />
6 +600 < alt ≤ +700<br />
7 +700 < alt ≤ +800<br />
8 +800 < alt ≤ +900<br />
9 +900 < alt ≤ +1 000<br />
10 +1 000 < alt ≤ +1 500<br />
11 +1 500 < alt ≤ +2 000<br />
12 +2 000 < alt ≤ +2 500<br />
13 +2 500 < alt ≤ +3 000<br />
14 +3 000 < alt ≤ +3 500<br />
15 +3 500 < alt<br />
16 No reported altitude<br />
17 –100 ≤ alt < 0<br />
18 –200 ≤ alt < –100<br />
19 –300 ≤ alt < –200<br />
20 –400 ≤ alt < –300<br />
21 –500 ≤ alt < –400<br />
22 –600 ≤ alt < –500<br />
23 –700 ≤ alt < –600<br />
24 –800 ≤ alt < –700<br />
25 –900 ≤ alt < –800<br />
26 –1 000 ≤ alt < –900<br />
27 –1 500 ≤ alt < –1 000<br />
28 –2 000 ≤ alt < –1 500<br />
29 –2 500 ≤ alt < –2 000<br />
30 –3 000 ≤ alt < –2 500<br />
31 alt < –3 000<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-94 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.3.2.2.2.3.4 Altitude rate<br />
The 2-bit altitude rate field shall indicate whether the alert aircraft is climbing, descending, or level. An altitude rate of<br />
500 ft/min shall be used as a threshold. The encoding of the TIS altitude rate field shall be:<br />
A.3.2.2.2.3.5 Traffic heading<br />
Altitude rate field value Altitude rate<br />
0 Unused<br />
1 Climbing (>500 ft/min)<br />
2 Descending (>500 ft/min)<br />
3 Level<br />
The 3-bit traffic heading field shall contain the heading of the alert aircraft quantized to 45-degree increments. This<br />
heading shall be based on the <strong>Mode</strong> S ground interrogator track <strong>for</strong> the alert aircraft.<br />
Note.— The coarse quantization of traffic heading is sufficient to aid the pilot receiving the TIS alert message to<br />
visually acquire the traffic alert aircraft.<br />
A.3.2.2.2.3.6 Traffic status<br />
The 1-bit traffic status field shall identify the type of alert represented by this traffic in<strong>for</strong>mation block. A status value of<br />
“ZERO” shall indicate a “proximity” alert <strong>and</strong> a status value of “ONE” shall indicate a “threat” alert.<br />
A.3.2.2.2.4 H<strong>and</strong>ling multiple TIS alerts<br />
As described above, the traffic data in<strong>for</strong>mation <strong>for</strong> a given scan shall consist of one or more TIS traffic data messages.<br />
The last traffic in<strong>for</strong>mation block of the last TIS uplink message <strong>for</strong> this scan shall be a null-alert block if there is an odd<br />
number of alert aircraft in this message. The null-alert condition shall be indicated by the value 63 decimal in the traffic<br />
bearing field of the traffic in<strong>for</strong>mation block.<br />
Draft<br />
A.3.2.2.2.4.1 The TIS traffic in<strong>for</strong>mation blocks within a given TIS traffic data message shall be arranged with the highest<br />
priority alerts first. All traffic in<strong>for</strong>mation blocks with the status “threat” shall precede traffic in<strong>for</strong>mation blocks with the<br />
status “proximity”. Within a status class, the traffic in<strong>for</strong>mation blocks shall be put in order of increasing traffic range.<br />
Note.— This ordering ensures that the most critical traffic alerts will be at the head of the list of traffic in<strong>for</strong>mation<br />
blocks. There<strong>for</strong>e, TIS will report on the most significant aircraft up to the limit of the number of messages transferable in<br />
one scan.<br />
A.3.2.2.3 TIS TRAFFIC DATA MESSAGES GROUPING MECHANISM<br />
A.3.2.2.3.1 The mechanism <strong>for</strong> grouping TIS traffic data messages <strong>for</strong> a given scan shall be based on the message<br />
type field in each message as described in §3.2.2.2.<br />
A.3.2.2.3.2 Since the <strong>Mode</strong> S Comm-A protocol can deliver multiple copies of the same message, the initial step in<br />
message grouping shall be a check to eliminate duplicate messages. This shall be accomplished by a bit comparison of<br />
successive messages received with the same message type.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-95<br />
A.3.2.2.3.3 After duplicate elimination, the TIS traffic data <strong>for</strong> a given grouping shall always begin with a “first” segment<br />
message. This message shall contain the own-heading value <strong>for</strong> the group. Additional TIS traffic data messages in the<br />
grouping (if present) shall be structured as indicated in the table below:<br />
Number of traffic aircraft Structure of group<br />
1 First<br />
2 First<br />
3 First <strong>and</strong> final<br />
4 First <strong>and</strong> final<br />
5 First, 1 intermediate, <strong>and</strong> final<br />
6 First, 1 intermediate, <strong>and</strong> final<br />
7 First, 2 intermediates, <strong>and</strong> final<br />
8 First, 2 intermediates, <strong>and</strong> final<br />
etc. First, intermediates, <strong>and</strong> final<br />
A.3.2.2.3.4 The receipt of a “first” segment shall start the <strong>for</strong>mation of a message group. Subsequent TIS traffic data<br />
uplink messages shall be added to the group until one of the following conditions occurs:<br />
a) a TIS uplink of type “final” is received (the final is part of the group);<br />
b) a TIS uplink of type “first” segment, “keep-alive”, or “goodbye” is received; or<br />
c) more than 6 seconds have elapsed since the start of the group.<br />
A.3.2.2.3.5 All the traffic blocks in the TIS traffic data message group (1 to n) shall <strong>for</strong>m the display <strong>for</strong> the current time.<br />
A new group shall then be initiated by the receipt of another TIS traffic data uplink “first” segment message. TIS traffic<br />
data uplink messages of type “intermediate” or “final” shall be ignored if a new group has not been initiated by receipt of<br />
a “first” segment.<br />
A.3.2.2.4 TIS ESTABLISHMENT/DISCONNECTION PROTOCOLS<br />
Draft<br />
The processing required to establish/disconnect TIS with <strong>Mode</strong> S ground interrogators when coverage boundaries are<br />
crossed shall be based upon in<strong>for</strong>mation contained in the capability registers within the aircraft’s <strong>Mode</strong> S transponder as<br />
well as two specific TIS uplink messages.<br />
A.3.2.2.4.1 <strong>Mode</strong> S capability report<br />
Transponder register 1016 within the <strong>Mode</strong> S transponder shall contain bits that indicate the capability level of the aircraft<br />
with respect to <strong>Mode</strong> S functions. This register shall be read by each <strong>Mode</strong> S ground interrogator that acquires the<br />
aircraft. Bit 25 of this register shall be set to “ONE” if the aircraft carries any MSP data link services (i.e. TIS).<br />
Note.— This bit merely indicates the presence of MSP data link services on board the aircraft — it does NOT<br />
indicate whether any of these services are in use by the aircrew at a given time.<br />
A.3.2.2.4.2 MSP capability report<br />
Transponder registers 1D16 to 1F16 within the <strong>Mode</strong> S transponder contain bits which indicate the dynamic state of<br />
certain MSP data services on board the aircraft (where defined in applications, e.g. TIS). These registers shall be read<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-96 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
by each <strong>Mode</strong> S ground interrogator that acquires the aircraft if the <strong>Mode</strong> S capability report indicates that the aircraft<br />
carries MSP data link services. Bit 2 of the MSP capability report register 1D16 shall be set to “ONE” if TIS support is<br />
desired; otherwise, the bit shall be set to “ZERO”. Setting <strong>and</strong> resetting this bit shall be done in conjunction with the<br />
generation of TIS “service connect requests” (TSCR) <strong>and</strong> “service disconnect requests” (TSDR) downlink messages as<br />
specified in section §A.4.3.2 <strong>for</strong> downlink broadcast identifier 0216.<br />
A.3.2.2.4.3 Keep-alive timer<br />
In the absence of TIS traffic data messages, TIS keep-alive messages shall be uplinked by the <strong>Mode</strong> S ground<br />
interrogator. The TIS airborne processor shall keep a timer that measures the time interval between TIS uplink<br />
messages received. The timer shall be reset each time a TIS uplink message is received. If this “keep-alive” timer<br />
reaches 60 seconds (the “keep-alive” time parameter <strong>for</strong> TIS), the TIS ground-to-air service shall be declared to have<br />
failed <strong>and</strong> TIS support is no longer available from the <strong>Mode</strong> S ground interrogator.<br />
Note.— The data link service processing <strong>for</strong> TIS must receive periodic uplink messages from the <strong>Mode</strong> S ground<br />
interrogator in order to ensure that the ground-to-air link is maintained <strong>and</strong> that the ground TIS support is continuing.<br />
A.3.2.2.4.4 TIS principal interrogator code protocol<br />
Note.— Each TIS uplink message is accompanied by a 4-bit interrogator identifier (II) code or a 6-bit surveillance<br />
identifier (SI) code (contained in the SD field) that identifies which <strong>Mode</strong> S ground interrogator (or interrogator cluster)<br />
generated it.<br />
The II or SI code shall be used to generate a 7-bit ILAB code. If the <strong>Mode</strong> S ground interrogator is identified via a 4-bit II<br />
code, then the high-order three bits of the ILAB shall be cleared to zero <strong>and</strong> the II code shall be contained in the<br />
low-order 4 bits of the ILAB. Otherwise, if the <strong>Mode</strong> S ground interrogator is identified via a 6-bit SI code, then the<br />
high-order bit of the ILAB shall be set to one <strong>and</strong> the SI code shall be contained in the low-order 6 bits of the ILAB. At<br />
any given moment, only one <strong>Mode</strong> S ground interrogator shall be declared as the “principal interrogator” (PI). In areas<br />
having overlapping <strong>Mode</strong> S coverage by interrogators with different ILAB codes, an “alternate interrogator” (AI) shall also<br />
be declared. The TIS protocol <strong>for</strong> h<strong>and</strong>ling ILAB codes shall be as defined below.<br />
A.3.2.2.4.5 TIS display generation<br />
Draft<br />
If TIS messages are received from more than one interrogator at a time, only those TIS messages from the interrogator<br />
currently declared as the PI shall be displayed to the pilot. TIS messages from interrogators other than the PI shall be<br />
discarded, except <strong>for</strong> the AI processing described below.<br />
A.3.2.2.4.6 Alternate interrogator (AI) identification<br />
The ILAB code of the most recently received TIS message not from the PI shall be retained as the AI. In the case that no<br />
TIS messages have been received from interrogators other than the PI (as described below), no current AI shall be<br />
defined. The AI definition shall be initialized to the “none state” when TIS is enabled (TSCR) or disabled (TSDR) by the<br />
pilot.<br />
A.3.2.2.4.7 Principal interrogator (PI) identification<br />
The ILAB code of the first <strong>Mode</strong> S ground interrogator to respond to the TSCR downlink message with a TIS uplink<br />
message becomes the PI. The PI shall be retained until either:<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-97<br />
a) the PI sends a TIS “goodbye” uplink message; or<br />
b) there is a TIS “keep-alive” time-out on the PI.<br />
In either case, the AI (if one is present) shall be promoted to PI <strong>and</strong> its TIS messages shall now be displayed. A new AI<br />
shall now be identified. If there was no available AI, no PI is now available <strong>and</strong> the airborne TIS processor shall be in the<br />
“no TIS supported” state. This state shall continue until a TIS message (either traffic or keep-alive) is received from a<br />
<strong>Mode</strong> S ground interrogator. When such an uplink message is received, the ILAB code associated with the message<br />
shall become the PI <strong>and</strong> the airborne processing shall resume the display of TIS. The PI definition shall be initialized to<br />
the “none” state when TIS is enabled (TSCR) or disabled (TSDR) by the pilot.<br />
(Reserved <strong>for</strong> ground-to-air alert)<br />
The description of this channel has not yet been developed.<br />
(Reserved <strong>for</strong> ground-derived position)<br />
The description of this channel has not yet been developed.<br />
A.3.2.3 UPLINK MSP CHANNEL 3<br />
A.3.2.4 UPLINK MSP CHANNEL 4<br />
A.3.2.5 UPLINK MSP CHANNEL 5: ACAS SENSITIVITY LEVEL CONTROL<br />
The description of this channel has not yet been developed.<br />
Bit 5 in Register 1D16 shall be set to zero at all times.<br />
Notes.—<br />
1. This service allows ground stations to control the Sensitivity Level of ACAS by sending a message to the<br />
transponder <strong>for</strong> delivery to ACAS. This service is required when a transponder supports an ACAS installation. Refer to<br />
Annex 10, Vol. IV §4.3.8.4.2 <strong>for</strong> complete requirements.<br />
2. ACAS installed <strong>and</strong> operational is communicated in the Data Link Capability Report (Register 1016). There<strong>for</strong>e,<br />
this service is not required to be marked in Register 1D16.<br />
A.3.2.6.1 PURPOSE<br />
Draft<br />
A.3.2.6 UPLINK MSP CHANNEL 6: DATAFLASH<br />
This service shall provide a means of requesting access to services supported by the aircraft. When implemented, bit 6<br />
of the register accessed by BDS code 1,D shall be set to a 1.<br />
A.3.2.6.2 FORMAT<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
The request shall be transferred in an uplink MSP packet with the channel number set to 6 <strong>and</strong>, in the case of a long<br />
<strong>for</strong>m MSP packet, with SP set to “ZERO”. The first byte of the user data field shall contain a service request (SR) header.<br />
The contents <strong>and</strong> <strong>for</strong>mat of the service request are specified by the application.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-98 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.3.2.6.3 SR HEADER ASSIGNMENTS<br />
A.3.2.6.3.1 Dataflash<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A.3.2.6.3.1.1 Dataflash request <strong>for</strong>mat<br />
Decimal value of SR<br />
0 UnassignedReserved<br />
1 Dataflash<br />
2 Local system management<br />
3 to 255 UnassignedReserved<br />
The <strong>for</strong>mat of the user data field shall be as specified in Table A-3-1. The user data field of the requesting MSP packet<br />
shall contain the decimal value of “ONE” in the first byte (SR header), followed by one or more requests <strong>for</strong> dataflash<br />
services. Each request shall contain a 2-byte dataflash request header (DH), followed by a 1-byte field to define the<br />
minimum time interval permitted between reports (MT field), a 4-bit field to determine the event criterion (EC field), a<br />
4-bit field to determine stable time (ST field), <strong>and</strong> if indicated in EC, a change quanta field (CQ) <strong>and</strong> a change threshold<br />
(CT) field. The 4-bit ST field shall indicate the decimal value in seconds <strong>and</strong> how long the changed data has been stable<br />
be<strong>for</strong>e a message shall be initiated. All zeros in the dataflash header (DH) shall indicate that there are no more dataflash<br />
requests in the packet. When an MSP packet is completely filled with dataflash requests, or when there is not sufficient<br />
room in the packet <strong>for</strong> another dataflash request header, it shall be assumed that the dataflash request sequence is<br />
complete.<br />
A.3.2.6.3.1.1.1 All aircraft dataflash equipment <strong>and</strong> installations shall support 16 dataflash contracts. Aircraft<br />
equipment <strong>and</strong> installations originally certified after 1 January 2001 shall support 64 dataflash contracts.<br />
Note 1.— A single dataflash contract relates to a single contract number (see §A.3.2.6.3.1.2.1) <strong>for</strong> a single register<br />
<strong>for</strong> a particular II code. There<strong>for</strong>e, dataflash services, with different DH values <strong>for</strong> each II code, can be established<br />
simultaneously with the same aircraft. These may be modified or discontinued independently of each other.<br />
A.3.2.6.3.1.1.2 Recommendation. — When a request has been accepted by the aircraft system, a dataflash response<br />
should be triggered immediately regardless of thresholds or event criteria. If no response is received in 30 seconds then<br />
a check should be made that the aircraft is still available on roll call <strong>and</strong>, if so, a new request should be generated. In<br />
order to avoid repeated dataflash requests that produce no response, the number of such requests (N) should be limited<br />
(N=3).<br />
Draft<br />
A.3.2.6.3.1.1.3 When a new contract request is received <strong>for</strong> a contract already in existence, the old contract shall be<br />
discontinued <strong>and</strong> replaced immediately by the latest one.<br />
A.3.2.6.3.1.2 Dataflash header (DH) 16 bits<br />
The 16-bit DH field is divided into four subfields separated by 3 reserved bits (14 through 16) see Table A-3-1.<br />
A.3.2.6.3.1.2.1 Contract number subfield (CNS) 4 bits (Bits 9 to 12 of the uplink MSP 6 user data field when SR = 1)<br />
This subfield shall be interpreted as a contract number permitting 16 different contracts to be associated with the register<br />
specified by the BDS1 <strong>and</strong> BDS2 codes of this contract request. Contract numbers available are 0 to 15 <strong>and</strong> shall be<br />
associated with the II code of the contract request.<br />
A.3.2.6.3.1.2.2 Request data subfield (RDS) 1 bit (Bit 13 of the uplink MSP 6 user data field when SR = 1)<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-99<br />
This subfield shall indicate whether or not the contents of the register being monitored by the requested contract must be<br />
sent in the MSP packets on downlink channel 3 that are sent each time the criterion <strong>for</strong> the contract is met. The subfield<br />
shall be interpreted as follows:<br />
RDS = 0 Send only bits 1 to 40 of the user data field on downlink MSP 3 when the contract criterion is met.<br />
RDS = 1 Send bits 1 to 96 of the user data field on downlink MSP 3 when the contract criterion is met.<br />
Note.— RDS only indicates the length of the user data field in downlink MSP 3 when responding with a value zero<br />
in the CI field (see §A.3.3.3.4.3.1).<br />
A.3.2.6.3.1.2.3 BDS1 <strong>and</strong> BDS2 codes 8 bits (Bits 17 to 24 of the uplink MSP6 user data field)<br />
BDS1 <strong>and</strong> BDS2 codes of the register <strong>for</strong> which the contract is required shall be as specified in Annex 10, Volume IV.<br />
A.3.2.6.3.1.3 Minimum time (MT) 8 bits<br />
The decimal value of the 8-bit MT field shall represent the minimum time in seconds that shall elapse after a report has<br />
been event-triggered <strong>and</strong> sent to the transponder, be<strong>for</strong>e a new report can be initiated. The report sent to the<br />
transponder shall always be the most current data available.<br />
A.3.2.6.3.1.4 Event initiation<br />
Event initiation shall be controlled by the two following fields.<br />
A.3.2.6.3.1.4.1 Event criterion subfield (EC) 4 bits<br />
The EC field shall be the four most significant bits following the MT field. If multiple events occur within a single register<br />
being monitored by a dataflash contract, (e.g. if more than one parameter shows a significant change) only one<br />
message shall be triggered. The decimal value of the EC field shall be interpreted as follows:<br />
Draft<br />
EC field value Meaning<br />
0 No report required, discontinue service <strong>for</strong> the contract specified in the DH field.<br />
1 Report any change.<br />
2 56-bit change field (CQ) follows ST. Only report changes to bits indicated by a “ONE” in CQ.<br />
3<br />
4<br />
5<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
56-bit field CQ follows ST. For each parameter report all status changes <strong>and</strong> all changes of the<br />
parameter greater than the quantum value indicated in the same units <strong>and</strong> resolution of the field in<br />
CQ corresponding to that parameter. A zero in the field in CQ corresponding to the parameter<br />
indicates that no reports are required.<br />
112 bits of CQ plus CT follow ST. The first 56 bits are as <strong>for</strong> the EC value 3 above. The second 56<br />
bits are the CT field indicating a threshold value in the field corresponding to the parameter. Report<br />
all changes above the threshold where the value in CQ gives the change quantum.<br />
112 bits of CQ plus CT follow ST. Same as <strong>for</strong> the EC value 4 above except: report all changes<br />
below the threshold.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
A-100 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
EC field value Meaning<br />
6<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
112 bits of CQ plus CT follows ST. Same as <strong>for</strong> EC values 4 <strong>and</strong> 5 above except: report only when<br />
the threshold is crossed (in either direction).<br />
7 to 14 Not assignedReserved<br />
15 Cancel all contracts <strong>for</strong> the II code in this request.<br />
A.3.2.6.3.1.4.2 Stable time field (ST) 4 bits<br />
The ST field shall be the 4 bits following the EC field. The decimal value of ST shall indicate in seconds how long the<br />
changed data have been stable, to within the change quanta specified in the CQ field, be<strong>for</strong>e a message shall be<br />
initiated. A value of “ZERO” in this subfield shall indicate that there is no minimum stable time <strong>and</strong> any change<br />
immediately initiates a message. The significance of the ST shall be dependent on which EC mode is being used. For<br />
EC <strong>Mode</strong>s 4 <strong>and</strong> 5, regarding stability whilst above/below a threshold, if a parameter value remains above/below the<br />
defined threshold <strong>for</strong> greater than the ST time then a dataflash message shall be generated even if the value does not<br />
remain stable to within one quantum. Subsequent quantum changes which are stable <strong>for</strong> greater than the ST time shall<br />
generate further dataflash messages until the value falls below/rises above the threshold.<br />
A.3.2.6.3.1.5 Change fields — change quanta (CQ) <strong>and</strong> change threshold (CT)<br />
These fields shall be present when indicated in EC. For a transponder register service (i.e. <strong>for</strong> BDS1 <strong>and</strong> BDS2 from 1 to<br />
255 inclusive), CQ shall be contained in bits 41 to 96 of the MSP 6 user data field. CT, when required, shall be contained<br />
in bits 97 to 152 of the MSP 6 user data field. The quantum value in the CQ field shall be indicated in the same units <strong>and</strong><br />
resolution as those specified <strong>for</strong> the register being monitored. It shall specify the amount by which the parameter must<br />
change, from its value at the initialization of the contract, <strong>and</strong> thereafter from the value last reported by a dataflash<br />
response, in order to trigger a new dataflash response on downlink MSP channel 3 (see Table A-3-1).<br />
A.3.2.6.3.2 Local system management<br />
Draft<br />
The purpose of the local system management is to provide a particular ground-air service request that can be defined<br />
locally to meet particular requirements (such as <strong>for</strong> ground station “remote setting” of parameters at the far-field monitor).<br />
(Reserved <strong>for</strong> response to air-to-ground service request)<br />
The description of this channel has not yet been developed.<br />
(Reserved <strong>for</strong> trajectory negotiation)<br />
The description of this channel has not yet been developed.<br />
A.3.2.7 UPLINK MSP CHANNEL 7<br />
A.3.2.8 UPLINK MSP CHANNEL 8<br />
A.3.2.9 UPLINK MSP CHANNELS 9 TO 63<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-101<br />
These channels have not been assigned.<br />
A.3.3 DOWNLINK MSP CHANNELS<br />
The following sections are numbered A.3.3.X, where “X” is the decimal number equivalent to the downlink MSP channel<br />
number. This is done to allow definitions of the hitherto undefined <strong>for</strong>mats to be inserted without affecting paragraph<br />
numbers.<br />
A.3.3.1 DOWNLINK MSP CHANNEL 1<br />
(Reserved <strong>for</strong> specific services management)<br />
The description of this channel has not yet been developed.<br />
This channel has not been assigned.<br />
A.3.3.3.1 PURPOSE<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A.3.3.2 DOWNLINK MSP CHANNEL 2<br />
A.3.3.3 DOWNLINK MSP CHANNEL 3<br />
Dataflash is a service which announces the availability of in<strong>for</strong>mation from air-to-ground on an event-triggered basis.<br />
When implemented, bit 31 of the register accessed by BDS code 1,D shall be set to a 1.<br />
Note.— This is an efficient means of downlinking in<strong>for</strong>mation which changes occasionally <strong>and</strong> unpredictably.<br />
A.3.3.3.2 SERVICE INITIATION AND TERMINATION<br />
Draft<br />
A.3.3.3.2.1 The dataflash service shall be initiated or discontinued by a service request <strong>and</strong> is received on uplink MSP<br />
channel 6 with a decimal value of ONE in the service request (SR) header, which is contained in the first byte of the user<br />
data field. This indicates that the rest of the user data field shall contain a dataflash request. On the receipt of such a<br />
request, a dataflash message from the register concerned with the request shall immediately be made available <strong>and</strong><br />
announced to the ground regardless of the setting of the RDS field in the contract request <strong>and</strong> of any event criteria. The<br />
response shall be as follows.<br />
A.3.3.3.2.2 When the requested register is being serviced, the contract shall be established <strong>and</strong> an MSP packet as<br />
specified in Table A-3-2 shall be announced to the ground on MSP channel 3. The CI field must be set to a value of 1.<br />
The message shall be used by the ground system to confirm that the service has been initiated.<br />
A.3.3.3.2.3 If the requested register is not being serviced, the contract shall not be established. This shall be indicated<br />
by announcing the MSP packet on downlink MSP channel 3 to the ground containing only bits 1 to 40 as specified in<br />
Table A-3-2, <strong>and</strong> with a value of 2 in the CI field.<br />
A.3.3.3.2.4 If the maximum number of contracts that can be supported is already established, then the new contract<br />
shall be refused. This shall be indicated by announcing to the ground an MSP packet on downlink channel 3, as<br />
specified in Table A-3-2, <strong>and</strong> with a value of 3 in the CI field.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-102 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.3.3.3.2.5 In the case of a request from the ground to terminate the service <strong>for</strong> a particular register, the termination of<br />
the service shall be confirmed by announcing to the ground an MSP packet on downlink channel 3, as shown in<br />
Table A-3-2, <strong>and</strong> with a value of 4 in the CI field.<br />
A.3.3.3.2.6 In the case of a request from the ground to terminate the service <strong>for</strong> all contracts to a particular II code, the<br />
termination of the service shall be confirmed by announcing to the ground an MSP packet on downlink channel 3, as<br />
shown in Table A-3-2, <strong>and</strong> with a value of 5 in the CI field.<br />
A.3.3.3.2.7 When the transponder register service fails <strong>for</strong> an established contract, the contract shall be terminated by<br />
the airborne application. This will be indicated by announcing to the ground an MSP packet on the downlink channel 3,<br />
as shown in Table A-3-2, <strong>and</strong> with a value of 7 in the CI field. Transponder register service shall be deemed to have<br />
failed when any of the parameters specified to be monitored in the negotiation of the contract are not being updated at<br />
the specified minimum rate.<br />
A.3.3.3.2.8 When a contract is refused due to an invalid value of the EC field in the contract request, this shall be<br />
indicated by announcing to the ground an MSP packet on downlink channel 3, as shown in Table A-3-2, <strong>and</strong> with a value<br />
of 15 in the CI field.<br />
A.3.3.3.2.9 If any message is not extracted from the transponder by a ground interrogator within 30 seconds, the<br />
aircraft subnetwork shall cancel the message <strong>and</strong> generate a delivery failure notice (i.e. the TZ timer expires), which shall<br />
be delivered to the aircraft MSP service provider. When a delivery failure notice is received the service shall be<br />
automatically terminated by the dataflash function with no indication to the ground system.<br />
Note.— This is to prevent the transponder message queues being blocked when the ground interrogator stops<br />
supplying the message extraction service, either due to a fault or loss of cover. It is the responsibility of the ground<br />
application to monitor the dataflash service taking this into account.<br />
A.3.3.3.2.10 When the transponder has not been selectively interrogated by a <strong>Mode</strong> S interrogator with a particular II<br />
code <strong>for</strong> 60 seconds (determined by monitoring the IIS subfield in all accepted <strong>Mode</strong> S interrogations), all dataflash<br />
contracts related to that II code shall be cancelled with no indication to the ground system.<br />
A.3.3.3.3 SERVICE PROVISION<br />
Draft<br />
On the receipt of a dataflash request, the requested parameters shall be monitored <strong>and</strong> transferred to the ground using<br />
the <strong>Mode</strong> S air-initiated protocols directed to the II code that was contained in the requesting interrogation. In order to<br />
prevent the flooding of the transponder with dataflash messages, an upper limit of ten messages in a six-second period<br />
shall be imposed. When the limit of ten messages within a six-second period is reached, further messages shall be<br />
queued until they can be sent. Messages queued in this way shall respond with a CI field value of 6. If, after initiating a<br />
dataflash message to the ground, the change criterion is met again prior to the message being entered into the<br />
transponder <strong>for</strong> announcement, the message is considered stale <strong>and</strong> shall be replaced by the most up-to-date<br />
in<strong>for</strong>mation.<br />
A.3.3.3.4 DOWNLINK MESSAGE STRUCTURE<br />
The in<strong>for</strong>mation shall be transferred in a downlink MSP packet with the channel number M/CH = 3. The <strong>for</strong>mat is shown<br />
in Table A-3-2. The first two bytes of the user data (UD) field shall contain a dataflash header (DH) which shall be<br />
identical to the DH field that was contained in the request <strong>for</strong> service.<br />
A.3.3.3.4.1 Bits 17 to 31 of UD <strong>for</strong>m the II code contract report (CR) field in which each bit shall indicate that at least<br />
one contract is active with the II code, which the bit represents when it is set to a ONE; otherwise, there are no active<br />
contracts with that II code.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-103<br />
A.3.3.3.4.2 Bits 32 to 36 of UD are not assigned.<br />
A.3.3.3.4.3 Bits 37 to 40 of UD <strong>for</strong>m the contract in<strong>for</strong>mation (CI) field which shall be interpreted as follows:<br />
CI field value Meaning<br />
0 Response to existing contract<br />
1 New contract established<br />
2 New contract not accepted, or existing contract terminated, due to no transponder<br />
register data service<br />
3 New contract not accepted due to maximum number of contracts already being<br />
serviced<br />
4 Contract terminated <strong>for</strong> the DH in this response due to a request from the ground<br />
5 All contracts terminated <strong>for</strong> the II code that delivered the MSP packet having an EC<br />
value of 15 that requested this response<br />
6 Response has been queued due to the limit of six dataflash messages in a ten<br />
second period<br />
7 Contract terminated due to failure of the register data service<br />
8 to 14 UnassignedReserved<br />
15 New contract not accepted due to invalid number in EC field of requested uplink<br />
MSP packet<br />
A.3.3.3.4.3.1 When the CI field is equal to ZERO, the response shall be as requested by the RDS field in the dataflash<br />
header of the contract (see §A.3.2.6.3.1.2.2). When the CI field is not equal to ZERO, the response shall only contain<br />
bits 1 to 40 of the user data field on downlink MSP 3 (see Table A-3-2).<br />
A.3.3.3.5 DATA EXTRACTION BY MODE S GROUND STATIONS<br />
Draft<br />
The dataflash transaction shall be announced as a downlink frame in response to interrogations UF 4, 5, 20, or 21. The<br />
transaction announced shall be either a single segment Comm-B frame or a two segment Comm-B frame, as requested<br />
by the contract negotiations. The air-directed Comm-B first segment shall contain the MSP header, dataflash header,<br />
<strong>and</strong> control in<strong>for</strong>mation <strong>for</strong> that particular contract. In the case of a contract <strong>for</strong> a single segment response, if the data is<br />
required, it is acquired directly by the ground station extracting the register in question.<br />
(Reserved <strong>for</strong> position request)<br />
The description of this channel has not yet been developed.<br />
A.3.3.4 DOWNLINK MSP CHANNEL 4<br />
A.3.3.5 DOWNLINK MSP CHANNEL 5<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-104 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
This channel has not been assigned.<br />
A.3.3.6 DOWNLINK MSP CHANNEL 6<br />
(Reserved <strong>for</strong> response to ground-to-air service request.) (See Table A-3-3.)<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-105<br />
The first byte of the user data (UD) field in the downlink MSP channel 6 shall be used to define a response type (RT)<br />
field as follows:<br />
RT = 0 Unassigned(Reserved)<br />
RT = 1 (Reserved)<br />
RT = 2 Local system management<br />
RT = 3 to 255 Unassigned(Reserved)<br />
When implemented, bit 34 of register 1D16 is set to a 1.<br />
Note.— The response to a ground-air service request can be used to transfer in<strong>for</strong>mation resulting from such a<br />
service.<br />
(Reserved <strong>for</strong> air-to-ground request)<br />
The description of this channel has not yet been developed.<br />
(Reserved <strong>for</strong> trajectory negotiation)<br />
The description of this channel has not yet been developed.<br />
These channels have not been assigned.<br />
A.3.3.7 DOWNLINK MSP CHANNEL 7<br />
A.3.3.8 DOWNLINK MSP CHANNEL 8<br />
A.3.3.9 DOWNLINK MSP CHANNELS 9 TO 63<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-106 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
TABLES FOR SECTION A.3<br />
Table A-3-1. Request <strong>for</strong> dataflash monitoring service<br />
<strong>Mode</strong> S SLM frame containing uplink MSP packet on channel 6 when SR = 1<br />
MSP 6 USER DATA FIELD<br />
Bits 1 to 40 Bits 41 — 96 (if required) Bits 97-152 (if required)<br />
DP = 0 (1 BIT) MSB 41 MSB 97 MSB<br />
MP = 0 (1 BIT) 42 98<br />
MSB 43 99<br />
UPLINK MSP 44 100<br />
M/CH = 6 (6 BITS) HEADER 45 101<br />
(1 BYTE) 46 102<br />
47 103<br />
LSB LSB 48 104<br />
1 MSB 49 105<br />
2 50 106<br />
3 51 107<br />
4 SERVICE REQUEST (SR) = 1 52 108<br />
5 53 109<br />
6 54 110<br />
7 55 111<br />
8 LSB 56 112<br />
9 MSB CONTRACT MSB 57 113<br />
10 NUMBER 58 114<br />
11 SUBFIELD 59 115<br />
12 LSB (CNS) 60 CHANGE 116 CHANGE<br />
13 REQUEST DATA (RDS) 61 QUANTA 117 THRESHOLD<br />
14 62 FIELD (CQ) 118 FIELD (CT)<br />
15 RESERVED DATAFLASH 63 119<br />
16 HEADER 64 120<br />
17 MSB 65 121<br />
18 BDS1 66 122<br />
19 CODE 67 123<br />
20 LSB 68 124<br />
21 MSB 69 125<br />
22 BDS2 70 126<br />
23 CODE 71 127<br />
24 LSB LSB 72 128<br />
25 MSB 73 129<br />
26 74 130<br />
27 MINIMUM 75 131<br />
28 TIME (MT) 76 132<br />
29 INTERVAL 77 133<br />
30 78 134<br />
31 79 135<br />
32 LSB = 1 second 80 136<br />
33 MSB 81 137<br />
34 EVENT 82 138<br />
35 CRITERION (EC) 83 139<br />
36 LSB 84 140<br />
37 MSB 85 141<br />
38 STABLE TIME (ST) 86 142<br />
39 87 143<br />
40 88 144<br />
89 145<br />
90 146<br />
91 147<br />
The last byte of the final MA field shall always be unassigned 92 148<br />
93 149<br />
94 150<br />
95 151<br />
96 LSB 152 LSB<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix A A-107<br />
Table A-3-2. Dataflash <strong>for</strong> register monitoring service<br />
<strong>Mode</strong> S frame containing downlink MSP packet on Channel 3<br />
MSP 3 USER DATA FIELD<br />
Bits 1 to 40 Bits 41 to 96<br />
MSB LINKED COMM B SUBFIELD (LBS) (2 BITS) 41 MSB<br />
LSB 42<br />
DP = 1 (1 BIT) MSB 43<br />
MP = 0 (1 BIT) 44<br />
MSB 45<br />
46<br />
M/CH = 3 (6 BITS) 47<br />
MSP 48<br />
HEADER 49<br />
LSB 50<br />
MSB 51<br />
52<br />
FILL 1 = 0 (6 BITS) 53<br />
54<br />
55<br />
LSB LSB 56<br />
1 MSB CONTRACT MSB 57<br />
2 NUMBER 58<br />
3 SUBFIELD 59<br />
4 LSB (CNS) 60<br />
5 REQUEST DATA SUBFIELD (RDS) 61<br />
6 62<br />
7 RESERVED 63<br />
8 DATAFLASH 64 REGISTER<br />
9 MSB HEADER (DH) 65 MESSAGE<br />
10 BDS1 66 CONTENT<br />
11 CODE 67<br />
12 LSB 68<br />
13 MSB 69<br />
14 BDS2 70<br />
15 CODE 71<br />
16 LSB LSB 72<br />
17 II=1 73<br />
18 II=2 74<br />
19 II=3 75<br />
20 II=4 76<br />
21 II=5 77<br />
22 II=6 78<br />
23 II= 7 II CODE 79<br />
24 II= 8 CONTRACT 80<br />
25 II= 9 REPORT (CR) 81<br />
26 II=10 82<br />
27 II=11 83<br />
28 II=12 84<br />
29 II=13 85<br />
30 II=14 86<br />
31 II=15 87<br />
32 88<br />
33 89<br />
34 NOT ASSIGNEDRESERVED 90<br />
35 91<br />
36 92<br />
37 MSB 93<br />
38 CONTRACT 94<br />
39 INFORMATION (CI) 95<br />
40 LSB 96 LSB<br />
Note.— See Annex 10, Volume III,<br />
Part I, §5.2.7.3 <strong>for</strong> specification of MSP<br />
Packets<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-108 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Table A-3-3 Response to ground-to-air service request<br />
<strong>Mode</strong> S frame containing downlink MSP packet on channel 6<br />
MSP 6 USER DATA FIELD<br />
Bits 1 to 40 Bits 41 to 96<br />
MSB LINKED COMM B SUB FIELD (LBS) 41 MSB<br />
LSB (2 BITS) 42<br />
DP = 0 (1 BIT) MSB 43<br />
MP = 0 (1 BIT) 44<br />
MSB 45<br />
46<br />
M/CH = 6 (6 BITS) 47<br />
48<br />
MSP 49<br />
LSB HEADER 50<br />
MSB 51<br />
52<br />
FILL 1 = 0 (6 BITS) 53<br />
54<br />
55<br />
LSB LSB 56<br />
1 MSB 57<br />
2 58<br />
3 59 REGISTER<br />
4 60 MESSAGE<br />
5 61 CONTENT<br />
6 62<br />
7 63<br />
8 RESPONSE 64<br />
9 TYPE 65<br />
10 66<br />
11 67<br />
12 68<br />
13 69<br />
14 70<br />
15 71<br />
16 LSB 72<br />
17 73<br />
18 74<br />
19 75<br />
20 76<br />
21 77<br />
22 78<br />
23 79<br />
24 80<br />
25 81<br />
26 82<br />
27 83<br />
28 84<br />
29 USER 85<br />
30 DEFINED 86<br />
31 87<br />
32 88<br />
33 89<br />
34 90<br />
35 91<br />
36 92<br />
37 93<br />
38 94<br />
39 95<br />
40 96 LSB<br />
This packet shall always<br />
be sent as a linked Comm-B. The<br />
second segment being a direct<br />
copy of the relevant register.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-109<br />
A.4. MODE S BROADCAST PROTOCOLS<br />
A.4.1 BROADCAST CHANNEL NUMBER ALLOCATIONS<br />
The broadcast identifiers shall be represented as a two-digit hexadecimal number, e.g. “XX16”.<br />
Note.— There are 255 broadcast identifiers available on both the uplink <strong>and</strong> downlink. Broadcast identifier<br />
numbers have been assigned <strong>for</strong> some applications (see Annex 10, Volume III, Part 1, Chapter 5, Table 5-23).<br />
The data <strong>for</strong>mats <strong>for</strong> the data link capability report <strong>and</strong> <strong>for</strong> aircraft identification together with the assignment of the<br />
broadcast identifiers shall be as defined in this document <strong>and</strong> Annex 10, Volumes III <strong>and</strong> IV, respectively.<br />
A.4.2 UPLINK BROADCAST IDENTIFIERS<br />
The following sections are numbered A.4.2.X, where “X” is the decimal equivalent of the uplink broadcast identifier<br />
number. This is done to allow definitions of the hitherto undefined <strong>for</strong>mats to be inserted without affecting the paragraph<br />
numbering.<br />
(Reserved <strong>for</strong> differential GNSS correction)<br />
A.4.2.1 UPLINK BROADCAST IDENTIFIER 0116<br />
The description of this identifier has not yet been developed.<br />
These identifiers have not been assigned.<br />
(Not valid)<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A.4.2.2 TO A.4.2.47 UPLINK BROADCAST IDENTIFIERS 0216 TO 2F16<br />
Draft<br />
A.4.2.48 UPLINK BROADCAST IDENTIFIER 3016<br />
A.4.2.49 UPLINK BROADCAST IDENTIFIERS 3116<br />
(Reserved <strong>for</strong> RA broadcast (see Annex 10, Volume IV, §4.3.8.4.2.3.4)).<br />
A.4.2.50 UPLINK BROADCAST IDENTIFIERS 3216<br />
(Reserved <strong>for</strong> ACAS (see Annex 10, Volume IV, §4.3.8.4.2.3.3)).<br />
These identifiers have not been assigned.<br />
A.4.2.51 TO A.4.2.255 UPLINK BROADCAST IDENTIFIERS 3316 TO FF16<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-110 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A.4.3 DOWNLINK BROADCAST IDENTIFIER<br />
The following sections are numbered A.4.3.X, where “X” is the decimal equivalent of the downlink broadcast identifier<br />
number. This is done to allow definitions of the hitherto undefined <strong>for</strong>mats to be inserted without affecting the paragraph<br />
numbering.<br />
This identifier has not been assigned.<br />
A.4.3.2.1 INTRODUCTION<br />
A.4.3.1 DOWNLINK BROADCAST IDENTIFIER 0116<br />
A.4.3.2 DOWNLINK BROADCAST IDENTIFIER 0216 : TRAFFIC INFORMATION SERVICE<br />
The traffic in<strong>for</strong>mation service shall be provided by uplinking in<strong>for</strong>mation on proximate aircraft that may be of interest to<br />
own-aircraft by a <strong>Mode</strong> S interrogator on uplink MSP channel 2.<br />
Note.— The service <strong>and</strong> uplink messages are specified in §A.3.2.2 under “Uplink MSP Channel 2”.<br />
It shall be possible <strong>for</strong> the aircraft to request to be either connected to or disconnected from the TIS service. These<br />
requests shall be made using the <strong>Mode</strong> S broadcast protocol using broadcast identifier 0216. These requests shall be the<br />
only downlink messages used by the TIS.<br />
A.4.3.2.2 TIS DOWNLINK MESSAGES<br />
The TIS airborne data link service shall be able to generate two types of <strong>Mode</strong> S downlink messages:<br />
a) TIS service connect request (TSCR); <strong>and</strong><br />
b) TIS service disconnect request (TSDR).<br />
Draft<br />
Both the TSCR <strong>and</strong> the TSDR shall be sent as Comm-B broadcast messages using the broadcast identifier 0216.<br />
Note.— The use of the <strong>Mode</strong> S Comm-B broadcast protocol deals with the case of multiple <strong>Mode</strong> S interrogators<br />
with overlapping coverage, which are in contact with a given TIS aircraft at the same time.<br />
The <strong>for</strong>mat of a TIS downlink message (either TSCR or TSDR) shall be as specified below:<br />
Header DIN 1 DIN 2 DIN 3 DIN 4 DIN 5 DIN 6<br />
8 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits<br />
The message header shall be the st<strong>and</strong>ard message header <strong>for</strong> TIS described in uplink MSP channel 2 (see §A.3.2.2).<br />
The 8-bit data link service identifier numbers (DIN) shall be read <strong>and</strong> processed sequentially from the TCSR or TSDR<br />
message until either:<br />
a) DIN i = 0; or<br />
b) all bits of the downlink message have been processed.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix A A-111<br />
Note 1.— This structure <strong>and</strong> protocol <strong>for</strong> MSP downlink service requests allow <strong>for</strong> future expansion <strong>and</strong> use by<br />
other MSP data link services.<br />
Note 2.— The principal <strong>and</strong> alternate TIS II codes in the TIS process (see §A.3.2.2) are set to the “none” state when<br />
either a TSCR or TSDR is generated.<br />
A.4.3.2.2.1 TCSR <strong>for</strong>mat<br />
This TIS Comm-B downlink message shall be generated when the pilot requests the initiation of TIS service. The TSCR<br />
message shall be generated at the same time as the MSP capability report bit <strong>for</strong> TIS is set to “ONE”. A TSCR shall be<br />
identified by a DIN value of 1. The TSCR shall be defined as a Comm-B broadcast message so that any <strong>Mode</strong> S ground<br />
interrogator capable of supporting TIS can respond to it.<br />
A.4.3.2.2.2 TSDR <strong>for</strong>mat<br />
This TIS Comm-B broadcast downlink message shall be generated when the pilot requests termination of TIS service.<br />
The TSDR message shall be generated at the same time as the MSP capability report bit <strong>for</strong> TIS is set to “ZERO”. A<br />
TSDR shall be identified by a DIN value of 2. The TSDR shall be defined as a Comm-B broadcast message so that any<br />
<strong>Mode</strong> S interrogator supporting TIS can respond to it.<br />
These identifiers have not been assigned.<br />
See Table A-2-16.<br />
These identifiers have not been assigned.<br />
See Table A-2-32.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
These identifiers have not been assigned.<br />
(Reserved <strong>for</strong> update request)<br />
A.4.3.3 TO A.4.3.15 DOWNLINK BROADCAST IDENTIFIERS 0316 TO 0F16<br />
A.4.3.16 DOWNLINK BROADCAST IDENTIFIER 1016 : DATA LINK CAPABILITY REPORT<br />
See Annex 10, Volume III, Part I, Chapter 5.<br />
Draft<br />
A.4.3.17 TO A.4.3.31 DOWNLINK BROADCAST IDENTIFIERS 1116 TO 1F16<br />
A.4.3.32 DOWNLINK BROADCAST IDENTIFIER 2016 : AIRCRAFT IDENTIFICATION<br />
A.4.3.33 TO A.4.3.253 DOWNLINK BROADCAST IDENTIFIERS 2116 TO FD16<br />
A.4.3.254 DOWNLINK BROADCAST IDENTIFIER FE16<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
A-112 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
(Reserved <strong>for</strong> search request)<br />
See Annex 10, Volume III, Part I, Chapter 5.<br />
A.4.3.255 DOWNLINK BROADCAST IDENTIFIER FF16<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix B<br />
PROVISIONS FOR EXTENDED SQUITTER VERSION 1<br />
B.1. INTRODUCTION<br />
B.1.1 Appendix B defines data <strong>for</strong>mats <strong>and</strong> protocols that shall be used <strong>for</strong> implementations of extended squitter<br />
Version 1.<br />
Note 1.— Appendix B is arranged in the following manner:<br />
Section B.1 Introduction<br />
Section B.2 Data <strong>for</strong>mats <strong>for</strong> transponder registers<br />
Section B.3 Traffic in<strong>for</strong>mation service — broadcast (TIS-B) <strong>for</strong>mats <strong>and</strong> coding<br />
Section B.4 ADS-B Rebroadcast (ADS-R) <strong>for</strong>mats <strong>and</strong> coding<br />
Note 2.— Implementation guidelines on possible data sources, the use of control parameters, <strong>and</strong> the protocols<br />
involved is given in Appendix CD.<br />
B.2. DATA FORMATS FOR TRANSPONDER REGISTERS<br />
Draft<br />
B.2.1 REGISTER ALLOCATION<br />
The register allocation shall be as specified in §A.2.1, except that the name of register 6116 is changed to aircraft<br />
statuswith the exception that extended squitter registers <strong>for</strong> version 1 are defined in the following table.<br />
B-1<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
B-2 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Register<br />
number<br />
Assignment<br />
Maximum update<br />
interval<br />
0516 <strong>Extended</strong> <strong>Squitter</strong> Airborne Position 0.2 s<br />
0616 <strong>Extended</strong> <strong>Squitter</strong> Surface Position 0.2 s<br />
0716 <strong>Extended</strong> <strong>Squitter</strong> Status 1.0 s<br />
0816 <strong>Extended</strong> <strong>Squitter</strong> Identification <strong>and</strong> Category 15.0 s<br />
0916 <strong>Extended</strong> <strong>Squitter</strong> Airborne Velocity 1.3 s<br />
0A16 <strong>Extended</strong> <strong>Squitter</strong> Event-Driven In<strong>for</strong>mation variable<br />
6116 <strong>Extended</strong> <strong>Squitter</strong> Aircraft Status 1.0 s<br />
6216 Target State <strong>and</strong> Status In<strong>for</strong>mation 0.5 s<br />
6316-6416 Reserved <strong>for</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
6516 <strong>Extended</strong> <strong>Squitter</strong> Aircraft Operational Status 2.5 s<br />
6616-6F16 Reserved <strong>for</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Notes.–<br />
1. The term “minimum update rate” is used in the document. The minimum update rate is obtained when data is<br />
loaded in one register field once every maximum update interval.<br />
2. Register 0A16 is not to be used <strong>for</strong> GICB or ACAS crosslink readout.<br />
3. If <strong>Extended</strong> <strong>Squitter</strong> is implemented, then Register 0816 is not cleared or ZEROed once either Flight Identification or<br />
Aircraft Registration data has been loaded into the Register during the current power-on cycle. Register 0816 is not<br />
cleared since it provides in<strong>for</strong>mation that is fundamental to track file management in the ADS-B environment. Refer to<br />
§C.2.4.3.3 <strong>for</strong> implementation guidelines regarding Register 0816.<br />
4. These registers define version 1 extended squitters.<br />
B.2.2 GENERAL CONVENTIONS ON DATA FORMATS<br />
General conventions on data <strong>for</strong>mats shall be as specified in §A.2.2.<br />
B.2.3 EXTENDED SQUITTER FORMATS<br />
Draft<br />
This section defines the <strong>for</strong>mats <strong>and</strong> coding that shall be used <strong>for</strong> extended squitter ADS-B messages. When the<br />
extended squitter capability is implemented as an extended squitter/non-transponder device (ES/NT, Annex 10, Volume<br />
IV, §3.1.2.8.7), the convention <strong>for</strong> register numbering shall not be required. However, the data content <strong>and</strong> the transmit<br />
times <strong>for</strong> any ES/NT device shall be the same as specified <strong>for</strong> the transponder case.<br />
B.2.3.1 FORMAT TYPE CODES<br />
The first 5-bit (“ME” bits 1–5, Message bits 33–37) field in every <strong>Mode</strong> S extended squitter message shall contain the<br />
<strong>for</strong>mat TYPE. The <strong>for</strong>mat TYPE shall differentiate the messages into several classes: Airborne Position, Airborne<br />
Velocity, Surface Position, Identification, Aircraft Intent, Aircraft State, etc. In addition, the <strong>for</strong>mat TYPE shall also<br />
encode the Navigation Integrity Category (NIC) of the source used <strong>for</strong> the position report. The <strong>for</strong>mat TYPE shall also<br />
differentiate the Airborne Messages as to the TYPE of their altitude measurements: barometric pressure-altitude or<br />
GNSS height (HAE). The 5-bit encoding <strong>for</strong> <strong>for</strong>mat TYPE shall con<strong>for</strong>m to the definition contained in the following table:<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix B B-3<br />
TYPE<br />
code<br />
Subtype<br />
code<br />
0 Not<br />
present<br />
NIC<br />
supplement<br />
Not<br />
applicable<br />
Format<br />
(message type)<br />
No position<br />
in<strong>for</strong>mation(airborne<br />
or surface position)<br />
Horizontal containment<br />
radius limit (RC)<br />
Navigation integrity<br />
category (NIC)<br />
RC unknown NIC = 0 Barometric altitude<br />
or<br />
no altitude<br />
in<strong>for</strong>mation<br />
Altitude<br />
type Notes<br />
1 Category set D<br />
2 Not Not Aircraft identification<br />
Not<br />
Not<br />
Not Category set C<br />
3<br />
present applicable <strong>and</strong> category(§B.2.3.4)<br />
applicable<br />
applicable applicable<br />
Category set B<br />
4<br />
5 Not 0 Surface RC < 7.5 m NIC = 11<br />
6<br />
present<br />
0<br />
position(§B.2.3.3)<br />
RC < 25 m NIC = 10<br />
7<br />
8<br />
1 RC < 75 m NIC = 9<br />
0 RC < 0.1 NM (185.2 m) NIC = 8<br />
0<br />
RC > 0.1 NM (185.2 m) or unknown NIC = 0<br />
No altitude<br />
in<strong>for</strong>mation<br />
1, 2, 3<br />
Category set A<br />
9 Not 0 Airborne position RC < 7.5 m <strong>and</strong> VPL < 11 m NIC = 11 5<br />
10<br />
present<br />
0<br />
(§B.2.3.2)<br />
RC < 25 m <strong>and</strong> VPL < 37.5 m NIC = 10 5<br />
11<br />
1 RC < 75 m <strong>and</strong> VPL < 112 m NIC = 9<br />
0 RC < 0.1 NM (185.2 m) NIC = 8<br />
12 0 RC < 0.2 NM (370.4 m) NIC = 7<br />
13<br />
1 RC < 0.6 NM (1111.2 m)<br />
0 RC < 0.5 NM (926 m)<br />
NIC = 6<br />
14 0 RC < 1.0 NM (1852 m) NIC = 5<br />
15 0 RC < 2 NM (3.704 km) NIC = 4<br />
16<br />
1 RC < 4 NM (7.408 km) NIC = 3<br />
0 RC < 8 NM (14.816 km) NIC = 2<br />
17 0 RC < 20 NM (37.04 km) NIC = 1<br />
18<br />
19<br />
0<br />
0 Not<br />
Reserved<br />
1 — 4<br />
applicable<br />
Airborne velocity<br />
(§B.2.3.5)<br />
5 — 7<br />
Reserved<br />
RC > 20 NM (37.04 km) or unknown NIC = 0<br />
Not<br />
applicable<br />
Not<br />
applicable<br />
Barometric<br />
altitude<br />
Difference between<br />
“barometric<br />
altitude” <strong>and</strong><br />
“GNSS height<br />
(HAE)”<br />
Draft<br />
20 Not 0 Airborne RC < 7.5 m <strong>and</strong> VPL < 11 m NIC = 11 GNSS height<br />
2, 5<br />
21<br />
present<br />
0<br />
position(§B.2.3.2)<br />
RC < 25 m <strong>and</strong> VPL < 37.5 m NIC = 10<br />
(HAE)<br />
2, 5<br />
22<br />
23<br />
24<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
0<br />
0<br />
Not<br />
Test message<br />
1 — 6 applicable Reserved<br />
7 Allocated <strong>for</strong> national use<br />
0 Reserved <strong>for</strong> surface system status<br />
RC > 25 m or VPL > 37.5 m or RC or<br />
VPL are unknown<br />
1 Surface System Status (Allocated <strong>for</strong> National Use)<br />
2 – 7 Reserved<br />
25<br />
26<br />
Reserved<br />
27 Reserved <strong>for</strong> trajectory change<br />
28 0 Reserved<br />
1 Emergency/priority status (§B.2.3.8)<br />
2 ACAS RA broadcast<br />
3 — 7<br />
Reserved<br />
NIC = 0<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
6<br />
5, 6<br />
7<br />
2
B-4 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
TYPE<br />
code<br />
29<br />
Subtype<br />
code<br />
NIC<br />
supplement<br />
Format<br />
(message type)<br />
Horizontal containment<br />
radius limit (RC)<br />
0 Target state <strong>and</strong> status in<strong>for</strong>mation (§B.2.3.9)<br />
1 — 3 Reserved<br />
30 0 — 7 Reserved<br />
31<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
0 — 1 Aircraft operational status (§B.2.3.10)<br />
2 — 7 Reserved<br />
Navigation integrity<br />
category (NIC)<br />
Altitude<br />
type Notes<br />
Note 1.— “Barometric altitude” refers to barometric pressure-altitude, relative to a st<strong>and</strong>ard pressure of 1 013.25<br />
hectopascals (29.92 in Hg). It does not refer to barometric corrected altitude.<br />
Note 2.— TYPE Codes 20 to 22 or TYPE Code 0 are to be used when valid “Barometric altitude” is not available.<br />
Note 3.— After initialization, when horizontal position in<strong>for</strong>mation is not available but altitude in<strong>for</strong>mation is<br />
available, the airborne position message is transmitted with a TYPE Code of ZERO in bits 1-5, the barometric pressurealtitude<br />
in bits 9 to 20, <strong>and</strong> bits 22 to 56 set to ZERO. If neither horizontal position nor barometric altitude in<strong>for</strong>mation is<br />
available, then all 56 bits of Register 05 {HEX} are set to ZERO. The ZERO (binary 00000) TYPE Code field indicates<br />
that latitude <strong>and</strong> longitude in<strong>for</strong>mation is not available, while the ZERO altitude field indicates that altitude in<strong>for</strong>mation<br />
is not available.<br />
Note 4.— If the position source is an ARINC 743A GNSS receiver, then the ARINC 429 data “label 130” data word<br />
from that receiver is a suitable source of in<strong>for</strong>mation <strong>for</strong> RC, the horizontal integrity containment radius. (The label 130<br />
data word is variously called HPL (Horizontal Protection Limit) or HIL (Autonomous Horizontal Integrity Limit) in different<br />
documents).<br />
Note 5.— This TYPE Code value implies limits <strong>for</strong> both RC (horizontal containment limit) <strong>and</strong> VPL (Vertical<br />
Protection Limit). If either of these limits is not satisfied, then a different value <strong>for</strong> the TYPE Code is selected.<br />
Note 6.— The “NIC supplement” field in the Aircraft Operational Status Message (see §B.2.3.10) enables the<br />
Report Assembly Function in ADS-B Receiving Subsystems to determine whether the ADS-B Transmitting Subsystem is<br />
announcing NIC = 8 (RC < 0.1 NM) or NIC = 9 (RC < 75 m).<br />
Note 7.— The “NIC supplement” field in the Aircraft Operational Status Message (see §B.2.3.10) enables the<br />
Report Assembly Function in ADS-B Receiving Subsystems to determine whether the ADS-B Transmitting Subsystem is<br />
announcing NIC = 2 (RC < 8 NM) or NIC = 3 (RC < 4 NM).<br />
Draft<br />
Note 86.— The term “broadcast” as used in this appendix, refers to a spontaneous transmission by the transponder.<br />
This is distinct from the Comm-B broadcast protocol.<br />
Note 7.— The position quality in Version 1 extended squitter messages is provided by the Navigational Accuracy<br />
Category (NACP), Navigational Integrity Category (NIC), NIC Supplement, <strong>and</strong> Surveillance Integrity Level (SIL)<br />
parameters.<br />
Note 8.— NACP provides an indication of position accuracy, while SIL, NIC, <strong>and</strong> the NIC Supplement in combination<br />
provide an indication of the integrity associated with the broadcast position. NACP, SIL, <strong>and</strong> the NIC Supplement are<br />
transmitted in the <strong>Extended</strong> <strong>Squitter</strong> Aircraft Operational Status Message. NACP <strong>and</strong> SIL are also transmitted in the<br />
Target State <strong>and</strong> Status Message. NIC is determined from the message Type Code. The NIC Supplement is used with<br />
some values of NIC to distinguish between two possible values of the containment radius. In the absence of the NIC<br />
Supplement the higher NIC containment radius should be used.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix B B-5<br />
Note 9.— Version 1 position messages with Type Codes 8, 18, or 22, <strong>and</strong> position messages associated with SIL of<br />
0 or NACP of 0 are not appropriate to support most ADS-B applications since the accuracy or integrity of the position<br />
broadcast in these messages is unknown by the transmitting device.<br />
Note 10.— It is recommended that Version 1 extended squitter messages with unknown accuracy or integrity only<br />
be used if either the position accuracy or integrity can be verified by other means, or the application has no specific<br />
requirements <strong>for</strong> these parameters.<br />
B.2.3.1.1 AIRBORNE POSITION MESSAGE TYPE CODE<br />
B.2.3.1.1.1 Airborne position message TYPE Code if containment radius is available<br />
Note.— If the position in<strong>for</strong>mation comes from a GNSS receiver that con<strong>for</strong>ms to the ARINC 743A Characteristic, a<br />
suitable source of in<strong>for</strong>mation <strong>for</strong> the containment radius (RC), is ARINC 429 label 130 from that GNSS receiver.<br />
If RC (containment radius) in<strong>for</strong>mation is available from the navigation data source, then the transmitting ADS-B<br />
subsystem shall determine the TYPE Code (the value of the TYPE subfield) of airborne position messages as follows.<br />
a) If current valid horizontal position in<strong>for</strong>mation is not available to the ADS-B Transmitting Subsystem, then the<br />
TYPE subfield of Airborne Position Messages shall be set to ZERO (0).<br />
b) If valid horizontal position <strong>and</strong> barometric pressure-altitude in<strong>for</strong>mation are both available to the ADS-B<br />
Transmitting Subsystem, then the ADS-B Transmitting Subsystem shall set the TYPE subfield of Airborne<br />
Position Messages to a value in the range from 9 to 18 in accordance with the table of §B.2.3.1.<br />
c) If valid horizontal position in<strong>for</strong>mation is available to the ADS-B Transmitting Subsystem, but valid barometric<br />
pressure-altitude in<strong>for</strong>mation is not available, <strong>and</strong> valid geometric altitude in<strong>for</strong>mation is available, the ADS-B<br />
Transmitting Subsystem shall set the TYPE subfield of Airborne Position Messages to a value in the range from<br />
20 to 22 depending on the containment radius RC <strong>and</strong> vertical protection limit VPL in accordance with the table<br />
of §B.2.3.1.<br />
d) If valid horizontal position in<strong>for</strong>mation is available to the ADS-B Transmitting Subsystem, but neither valid<br />
barometric altitude in<strong>for</strong>mation nor valid geometric altitude in<strong>for</strong>mation is available, the ADS-B Transmitting<br />
Subsystem shall set the TYPE subfield in Airborne Position Messages to a value in the range from 9 to 18<br />
depending on the containment radius RC in accordance with the table of §B.2.3.1. (In that case, the ALTITUDE<br />
subfield of the Airborne Position Messages would be set to all ZEROs in order to indicate that valid altitude<br />
in<strong>for</strong>mation is not available.)<br />
Draft<br />
B.2.3.1.1.2 Airborne position message TYPE Code if containment radius is not available<br />
If RC (containment radius) in<strong>for</strong>mation is NOT available from the navigation data source, then the ADS-B Transmitting<br />
Subsystem shall indicate NIC=0 by selecting a TYPE Code of 0, 18, or 22 in the Airborne Position Messages, as follows:<br />
a) the ADS-B Transmitting Subsystem shall set the TYPE subfield to ZERO (0) if valid horizontal position<br />
in<strong>for</strong>mation is not available; <strong>and</strong><br />
b) the ADS-B Transmitting Subsystem shall set the TYPE subfield to 18 if valid pressure-altitude in<strong>for</strong>mation is<br />
available, or if neither valid pressure-altitude nor valid geometric altitude in<strong>for</strong>mation is available.<br />
If valid pressure-altitude is not available, but valid geometric altitude in<strong>for</strong>mation is available, the ADS-B Transmitting<br />
Subsystem shall set the TYPE subfield to 22.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
B-6 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
B.2.3.1.2 SURFACE POSITION MESSAGE TYPE CODE<br />
B.2.3.1.2.1 Surface position message TYPE Code if containment radius is available<br />
If RC (horizontal containment radius) in<strong>for</strong>mation is available from the navigation data source, then the ADS-B<br />
Transmitting Subsystem shall use RC to determine the TYPE Code used in the Surface Position Message in accordance<br />
with the table of §B.2.3.1.<br />
Note.— If the position in<strong>for</strong>mation comes from a GNSS receiver that con<strong>for</strong>ms to the ARINC 743A characteristic, a<br />
suitable source of in<strong>for</strong>mation <strong>for</strong> the containment radius (RC), is ARINC 429 label 130 from that GNSS receiver.<br />
B.2.3.1.2.2 Surface position message TYPE Code if containment radius is not available<br />
If RC (horizontal containment radius) in<strong>for</strong>mation is not available from the navigation data source, then the ADS-B<br />
Transmitting Subsystem shall indicate NIC=0 by selecting a TYPE Code of 0 or 8 in the Surface Position Messages, as<br />
follows:<br />
a) the ADS-B Transmitting Subsystem shall set the TYPE subfield to ZERO if valid horizontal position in<strong>for</strong>mation<br />
is not available; <strong>and</strong><br />
b) the ADS-B Transmitting Subsystem shall set the TYPE subfield to 8 if valid horizontal position in<strong>for</strong>mation is<br />
available. (This TYPE code indicates that containment radius, RC, is either unknown or greater than or equal to<br />
0.1 NM.)<br />
B.2.3.1.3 TYPE CODE BASED ON HORIZONTAL PROTECTION LEVEL<br />
If valid horizontal position in<strong>for</strong>mation is available, then the “TYPE” code in the Surface Position Message shall be set in<br />
the range from “5” to “8.”<br />
Draft<br />
a) If RC (Horizontal Containment Radius) in<strong>for</strong>mation is available from the navigation data source, the “TYPE”<br />
coding shall be selected according to the RC value, in accordance with the table of §B.2.3.1.<br />
b) If RC is not available from the navigation data source, then the “TYPE” coding shall be set to 8.<br />
B.2.3.2 AIRBORNE POSITION FORMAT<br />
The airborne position squitter shall be <strong>for</strong>matted as specified in §A.2.3.2.<br />
B.2.3.3 SURFACE POSITION FORMAT<br />
The surface position squitter shall be <strong>for</strong>matted as specified in the definition of register number 0616 <strong>and</strong> in the following<br />
paragraphs.<br />
B.2.3.3.1 MOVEMENT<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
The movement field shall be <strong>for</strong>matted as specified in §A.2.3.3.1.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix B B-7<br />
B.2.3.3.2 HEADING/GROUND TRACK<br />
B.2.3.3.2.1 Heading/ground track status<br />
This 1-bit field shall define the validity of the heading/ground track value. Coding <strong>for</strong> this field shall be as follows:<br />
0=invalid <strong>and</strong> 1=valid.<br />
Note.— If a source of A/V heading is not available to the ADS-B transmitting subsystem, but a source of ground<br />
track angle is available, then ground track angle may be used instead of heading, provided that the status bit <strong>for</strong> heading<br />
subfield is set to ZERO (0) whenever the ground track angle is not a reliable indication of the A/V’s Heading. (The<br />
ground track angle is not a reliable indication of the A/V’s heading when the A/V’s ground speed is low.)<br />
B.2.3.3.2.2 Heading/ground track value<br />
This 7-bit (14-20) field shall define the direction (in degrees clockwise from true or magnetic north) of aircraft motion on<br />
the surface. The value shall be encoded as an unsigned angular weighted binary numeral, with an MSB of 180 degrees<br />
<strong>and</strong> an LSB of 360/128 degrees, with zero indicating true north. The data in the field shall be rounded to the nearest<br />
multiple of 360/128 degrees.<br />
Note.— The reference direction <strong>for</strong> heading (whether true north or magnetic north) is indicated in the horizontal<br />
reference direction (HRD) field of the aircraft operational status message (see §B.2.3.10.13).<br />
B.2.3.3.3 COMPACT POSITION REPORTING (CPR) FORMAT (F)<br />
The CPR <strong>for</strong>mat field shall be <strong>for</strong>matted as specified in §A.2.3.3.3.<br />
B.2.3.3.4 TIME SYNCHRONIZATION (T)<br />
Draft<br />
The time synchronization field shall be <strong>for</strong>matted as specified in §A.2.3.3.4.<br />
B.2.3.3.5 LATITUDE/LONGITUDE<br />
The latitude/longitude field shall be <strong>for</strong>matted as specified in §A.2.3.3.5.<br />
B.2.3.4 IDENTIFICATION AND CATEGORY FORMAT<br />
The identification <strong>and</strong> category squitter shall be <strong>for</strong>matted as specified in §A.2.3.4.<br />
B.2.3.5 AIRBORNE VELOCITY FORMAT<br />
The airborne velocity squitter shall be <strong>for</strong>matted as specified in the definition of register number 0916 <strong>and</strong> in the following<br />
paragraphs.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
B-8 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
B.2.3.5.1 SUBTYPES 1 AND 2<br />
Subtypes 1 <strong>and</strong> 2 shall be used as specified in §A.2.3.5.1.<br />
B.2.3.5.2 SUBTYPES 3 AND 4<br />
Subtypes 3 <strong>and</strong> 4 shall be used as specified in §A.2.3.5.2.<br />
B.2.3.5.3 INTENT CHANGE FLAG IN AIRBORNE VELOCITY MESSAGES<br />
The intent change flag shall be <strong>for</strong>matted as specified in §A.2.3.5.3.<br />
B.2.3.5.4 IFR CAPABILITY FLAG (IFR) IN AIRBORNE VELOCITY MESSAGES<br />
The IFR capability flag shall be <strong>for</strong>matted as specified in §A.2.3.5.4.<br />
B.2.3.5.5 NAVIGATION ACCURACY CATEGORY FOR VELOCITY (NACV)<br />
This 3-bit (ME bits 11-13, Message bits 43-45) subfield shall indicate the navigation accuracy category <strong>for</strong> velocity<br />
(NACV).<br />
The ADS-B transmitting subsystem shall accept, via an appropriate data interface, data from which the own-vehicle<br />
navigation accuracy category <strong>for</strong> velocity (NACV) may be determined, <strong>and</strong> it shall use such data to establish the NACV<br />
subfields in transmitted ADS-B airborne velocity messages.<br />
B.2.3.5.5.1 If the external data source provides 95 per cent accuracy figures of merit <strong>for</strong> horizontal <strong>and</strong> vertical velocity<br />
[HFOMR (horizontal figure of merit <strong>for</strong> velocity) <strong>and</strong> VFOMR (vertical figure of merit <strong>for</strong> velocity)], then the ADS-B<br />
transmitting subsystem shall determine the value of the NACV field in the airborne velocity messages, subtypes 1, 2, 3<br />
<strong>and</strong> 4 as specified in the following table.<br />
Draft<br />
NACV value<br />
(Decimal) HFOMR value VFOMR value<br />
4 HFOMR < 0.3 m/s (0.984 fps) AND VFOMR < 0.46 m/s (1.5 fps)<br />
3 HFOMR < 1 m/s (3.28 fps) AND VFOMR < 1.52 m/s (5.0 fps)<br />
2 HFOMR < 3 m/s (9.84 fps) AND VFOMR < 4.57 m/s (15.0 fps)<br />
1 HFOMR < 10 m/s (32.8 fps) AND VFOMR < 15.24 m/s (50 fps)<br />
0 HFOMR unknown or HFOMR<br />
≥ 10 m/s (32.8 fps)<br />
OR VFOMR unknown or VFOMR ≥<br />
15.24 m/s (50 fps)<br />
Note.— The tests in the table are to be applied in the order shown, from the most stringent test (<strong>for</strong> NACV = 4) to the<br />
least stringent (<strong>for</strong> NACV = 0). That is, if HFOMR <strong>and</strong> VFOMR do not satisfy the conditions <strong>for</strong> NACV = 4, then they are<br />
tested against the conditions <strong>for</strong> NACV = 3. If they do not satisfy the conditions <strong>for</strong> NACV = 3, they are tested against the<br />
conditions <strong>for</strong> NACV = 2, <strong>and</strong> so on.<br />
B.2.3.5.5.2 If the external data source does not provide HFOMR <strong>and</strong> VFOMR, the 95 per cent accuracy figures of merit<br />
<strong>for</strong> horizontal <strong>and</strong> vertical velocity, but it does provide 95 per cent accuracy figures of merit <strong>for</strong> the horizontal <strong>and</strong> vertical<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix B B-9<br />
positions [HFOM, horizontal figure of merit <strong>for</strong> position, <strong>and</strong> VFOM, vertical figure of merit <strong>for</strong> position], then the following<br />
tables shall be used to determine the NACV value to be inserted in the Airborne Velocity message. The following table<br />
shall be used if the position <strong>and</strong> velocity are obtained from a GNSS/GBAS or GNSS/SBAS receiver (Global Navigation<br />
Satellite System with Ground Based Augmentation System or with Satellite Based Augmentation System) when that<br />
receiver is operating in GBAS or SBAS mode.<br />
NACV value<br />
(Decimal)<br />
HFOM <strong>and</strong> VFOM values<br />
4 HFOM ≤ 1 m <strong>and</strong> VFOM ≤ 5.85 ft<br />
3 (HFOM > 1 m or VFOM > 5.85 ft) <strong>and</strong> HFOM ≤ 4.5 m,<br />
<strong>and</strong> VFOM ≤ 23.3 ft<br />
2 (HFOM > 4.5 m or VFOM > 23.3 ft) <strong>and</strong> HFOM ≤ 14.5 m,<br />
<strong>and</strong> VFOM ≤ 73.3 ft<br />
1 (HFOM > 14.5 m or VFOM > 73.3 ft) <strong>and</strong> HFOM ≤ 49.5 m,<br />
<strong>and</strong> VFOM ≤ 248 ft<br />
0 HFOM > 49.5 m or VFOM > 248 ft<br />
B.2.3.5.5.3 The following table shall be used if the position <strong>and</strong> velocity are obtained from a GNSS receiver operating<br />
in autonomous mode (that is, without GBAS or SBAS differential corrections).<br />
NACV value<br />
(Decimal)<br />
HFOM <strong>and</strong> VFOM values<br />
2 HFOM ≤ 125 m, <strong>and</strong> VFOM ≤ 585 ft<br />
0 HFOM > 475 m or VFOM > 2 335 ft<br />
1<br />
(HFOM > 125 m or VFOM > 585 ft)<br />
<strong>and</strong> HFOM ≤ 475 m, <strong>and</strong> VFOM ≤ 2 335 ft<br />
Draft<br />
B.2.3.5.5.4 If the external source of position <strong>and</strong> velocity data provides neither 95 per cent bounds on the accuracy of<br />
the velocity data (HFOMR <strong>and</strong> VFOMR) nor 95 per cent bounds on the accuracy of the position data (HFOM <strong>and</strong> VFOM),<br />
then the transmitting ADS-B device shall set the value of the NACV field in the Airborne Velocity Messages to zero.<br />
B.2.3.5.6 HEADING IN AIRBORNE VELOCITY MESSAGES<br />
The heading in the airborne velocity message shall be <strong>for</strong>matted as specified in §A.2.3.5.6.<br />
Note.— The reference direction <strong>for</strong> heading (whether True North or Magnetic North) is indicated in the Horizontal<br />
Reference Direction (HRD) field of the Aircraft Operational Status Message (see §B.2.3.10.13).<br />
B.2.3.5.7 DIFFERENCE FROM BAROMETRIC ALTITUDE IN AIRBORNE VELOCITY MESSAGES<br />
The difference from barometric altitude field shall be <strong>for</strong>matted as specified in §A.2.3.5.7.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
B-10 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
B.2.3.6 STATUS REGISTER FORMAT<br />
The status register shall be <strong>for</strong>matted as specified in §A.2.3.6.<br />
B.2.3.7 EVENT-DRIVEN PROTOCOL<br />
The event-driven protocol register shall be as specified in §A.2.3.7.<br />
B.2.3.8.1 EMERGENCY/PRIORITY STATUS<br />
B.2.3.8.1.1 Format<br />
B.2.3.8 AIRCRAFT STATUS<br />
The aircraft status squitter that conveys emergency/priority status in<strong>for</strong>mation shall be <strong>for</strong>matted as specified in the<br />
definition of transponder register 6116, Table B-2-97a.<br />
B.2.3.8.1.2 Transmission rate<br />
This message shall be broadcast at r<strong>and</strong>om intervals that are uni<strong>for</strong>mly distributed between 0.7 <strong>and</strong> 0.9 seconds <strong>for</strong> the<br />
duration of the emergency.<br />
B.2.3.8.1.3 Message delivery<br />
Message delivery shall be accomplished using the event-driven protocol (see §A.2.3.7). The broadcast of this message<br />
shall not take priority over the ACAS RA broadcast but shall take priority over all other event-driven message types, as<br />
specified in §B.2.5.5.3.<br />
B.2.3.8.2 ACAS RA BROADCAST<br />
B.2.3.8.2.1 Format<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Draft<br />
The aircraft status squitter that conveys ACAS RA broadcast in<strong>for</strong>mation shall be <strong>for</strong>matted as specified in the definition<br />
of transponder register 6116, Table B-2-97b.<br />
B.2.3.8.2.2 Transmission rate<br />
This message shall be broadcast at r<strong>and</strong>om intervals that are uni<strong>for</strong>mly distributed between 0.7 <strong>and</strong> 0.9 seconds <strong>for</strong> the<br />
duration of the emergency.<br />
B.2.3.8.2.3 Message delivery<br />
Message delivery shall be accomplished using the event-driven protocol (see §A.2.3.7). The broadcast of this message<br />
shall take priority over the emergency/priority status broadcast <strong>and</strong> all other event-driven message types, as specified in<br />
§B.2.5.5.3.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix B B-11<br />
B.2.3.9 RESERVED FOR TARGET STATE AND STATUS INFORMATION<br />
The target state <strong>and</strong> status in<strong>for</strong>mation squitter shall be <strong>for</strong>matted as specified in the definition of register 6216 <strong>and</strong> in the<br />
following paragraphs:<br />
B.2.3.9.1 TRANSMISSION RATE<br />
The Target State <strong>and</strong> Status Message shall be broadcast at r<strong>and</strong>om intervals uni<strong>for</strong>mly distributed over the range of 1.2<br />
to 1.3 seconds <strong>for</strong> the duration of the operation.<br />
B.2.3.9.2 MESSAGE DELIVERY<br />
<strong>Extended</strong> <strong>Squitter</strong> Message delivery shall be accomplished using the event-driven protocol (see §A.2.3.7).<br />
B.2.3.9.3 VERTICAL DATA AVAILABLE/SOURCE INDICATOR<br />
This 2-bit (ME bits 8 — 9, Message bits 40 — 41) subfield shall be used to identify if aircraft vertical state in<strong>for</strong>mation is<br />
available <strong>and</strong> present as well as the data source <strong>for</strong> the vertical data when present in the subsequent subfields.<br />
Encoding shall be defined as specified in the following table. Any message parameter associated with vertical target<br />
state <strong>for</strong> which an update has not been received from an on-board data source with the past 5 seconds shall be<br />
considered invalid <strong>and</strong> so indicated in the Vertical Data Available/Source Indicator subfield.<br />
Coding<br />
(Binary) (Decimal)<br />
Meaning<br />
00 0 No valid Vertical Target State data is available<br />
01 1<br />
Autopilot control panel selected value, such as <strong>Mode</strong> Control Panel<br />
(MCP) or Flight Control Unit (FCU)<br />
Draft<br />
10 2 Holding altitude<br />
11 3 FMS/RNAV system<br />
B.2.3.9.4 TARGET ALTITUDE TYPE<br />
This one bit (ME bit 10, Message bit 42) subfield shall be used to identify whether the altitude reported in the “Target<br />
Altitude” subfield is referenced to mean sea level (MSL) or to a flight level (FL). A value of ZERO (0) shall indicate target<br />
altitude referenced to pressure-altitude (flight level). A value of ONE (1) shall indicate a target altitude referenced to<br />
barometric corrected altitude (mean sea level).<br />
B.2.3.9.5 TARGET ALTITUDE CAPABILITY<br />
This 2-bit subfield (ME bits 12 — 13, Message bits 44 — 45) shall be used to describe the aircraft’s capabilities <strong>for</strong><br />
providing the data reported in the target altitude subfield. The target altitude capability subfield shall be encoded as<br />
specified in the following table.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
B-12 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Coding<br />
(Binary) (Decimal)<br />
Meaning<br />
00 0 Capability <strong>for</strong> reporting holding altitude only<br />
01 1<br />
10 2<br />
11 3 Reserved<br />
Capability <strong>for</strong> reporting either holding altitude or autopilot control panel<br />
selected altitude<br />
Capability <strong>for</strong> reporting either holding altitude, autopilot control panel<br />
selected altitude, or any FMS/RNAV level-off altitude<br />
B.2.3.9.6 VERTICAL MODE INDICATOR<br />
This 2-bit (ME bits 14 — 15, Message bits 46 — 47) subfield shall be used to indicate whether the target altitude is in the<br />
process of being acquired (i.e., aircraft is climbing or descending toward the target altitude) or whether the target altitude<br />
has been acquired/being held. The Vertical <strong>Mode</strong> Indicator subfield shall be encoded as specified in the following table.<br />
Coding<br />
(Binary) (Decimal)<br />
Meaning<br />
00 0 Unknown mode or in<strong>for</strong>mation unavailable<br />
01 1 “Acquiring” <strong>Mode</strong><br />
10 2 “Capturing” or “Maintaining” <strong>Mode</strong><br />
11 3 Reserved<br />
B.2.3.9.7 Target Altitude<br />
This 10-bit (ME bits 16 — 25, Message bits 48 — 57) subfield shall be used to provide aircraft’s next intended level off<br />
altitude if in a climb or descent, or the aircraft current intended altitude if it is intending to hold its current altitude. The<br />
reported target altitude shall be the operational altitude recognized by the aircraft’s guidance system. The target altitude<br />
subfield shall be as specified in the following table.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix B B-13<br />
Coding<br />
(Binary) (Decimal) Meaning<br />
00 0000 0000 0 Target altitude = -1 000 feet<br />
00 0000 0001 1 Target altitude = -900 feet<br />
00 0000 0010 2 Target altitude = -800 feet<br />
*** *** ***<br />
00 0000 1011 11 Target altitude = zero (0) feet<br />
00 0000 1100 12 Target altitude = 100 feet<br />
*** *** ***<br />
11 1111 0010 1010 Target altitude = 100 000 feet<br />
11 1111 0011 —<br />
11 1111 1111<br />
1011 — 1023 Invalid (out of range)<br />
B.2.3.9.8 HORIZONTAL DATA AVAILABLE/SOURCE INDICATOR<br />
This 2-bit (ME bits 26 — 27, message bits 58 — 59) subfield shall be used to identify if aircraft horizontal state<br />
in<strong>for</strong>mation is available <strong>and</strong> present as well as the data source <strong>for</strong> the horizontal target data when present in the<br />
subsequent subfields. The horizontal data available/source Indicator subfield shall be encoded as specified in the<br />
following table. Any message parameter associated with horizontal target state <strong>for</strong> which an update has not been<br />
received from an on-board data source within the past 5 seconds shall be considered invalid <strong>and</strong> so indicated in the<br />
horizontal data available/source indicator subfield.<br />
Coding<br />
(Binary) (Decimal) Meaning<br />
Draft<br />
00 0 No valid horizontal target state data is available<br />
01 1<br />
10 2<br />
Autopilot control panel selected value, such as <strong>Mode</strong> Control Panel<br />
(MCP) or Flight Control Unit (FCU)<br />
Maintaining current heading or track angle (e.g. autopilot mode<br />
select)<br />
11 3 FMS/RNAV system (indicates track angle specified by leg type)<br />
B.2.3.9.9 TARGET HEADING/TRACK ANGLE<br />
This 9-bit (ME bits 28 — 36, message bits 60 — 68) subfield shall be used to provide aircraft’s intended (i.e. target or<br />
selected) heading or track. The target heading/track angle subfield shall be encoded as specified in the following table.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
B-14 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Coding<br />
(Binary) (Decimal) Meaning<br />
0 0000 0000 0 Target heading/track = Zero degrees<br />
0 0000 0001 1 Target heading/track = 1 degree<br />
0 0000 0010 2 Target heading/track = 2 degrees<br />
*** *** ***<br />
1 0110 0111 359 Target heading/track = 359 degrees<br />
1 0110 1000 through<br />
1 1111 1111<br />
360 through 511<br />
Invalid<br />
B.2.3.9.10 TARGET HEADING/TRACK INDICATOR<br />
This 1-bit (ME bit 37, message bit 69) subfield shall be used to indicate whether a Heading Angle or a track angle is<br />
being reported in the target heading/track angle subfield. A value of ZERO (0) shall indicate the Target Heading Angle is<br />
being reported. A value of ONE (1) shall indicate that Track Angle is being reported.<br />
B.2.3.9.11 HORIZONTAL MODE INDICATOR<br />
This 2-bit (ME bits 38 — 39, Message bits 70 — 71) subfield shall be used to indicate whether the target heading/track is<br />
being acquired (i.e. lateral transition toward the target direction is in progress) or whether the target heading/track has<br />
been acquired <strong>and</strong> is currently being maintained. The horizontal mode Indicator subfield shall be encoded as specified<br />
in the following table.<br />
Coding<br />
(Binary) (Decimal) Meaning<br />
00 0 Unknown mode or in<strong>for</strong>mation unavailable<br />
01 1 “Acquiring” mode<br />
Draft<br />
10 2 “Capturing” or “Maintaining” mode<br />
11 3 Reserved<br />
B.2.3.9.12 NAVIGATION ACCURACY CATEGORY FOR POSITION (NACP)<br />
This 4-bit (ME bits 40 — 43, message bits 72 — 75) subfield shall be used to indicate the navigational accuracy<br />
category of the navigation in<strong>for</strong>mation used as the basis <strong>for</strong> the aircraft reported position. The NACP subfield shall be<br />
encoded as specified in the following table. If an update has not been received from an on-board data source <strong>for</strong> NACP<br />
within the past 5 seconds, then the NACP subfield shall be encoded as a value indicating unknown accuracy.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix B B-15<br />
Coding<br />
(Binary) (Decimal)<br />
Meaning = 95% horizontal <strong>and</strong> vertical accuracy bounds<br />
(EPU <strong>and</strong> VEPU)<br />
0000 0 EPU ≥ 18.52 km (10 NM) — Unknown accuracy<br />
0001 1 EPU < 18.52 km (10 NM) — RNP-10 accuracy<br />
0010 2 EPU < 7.408 km (4 NM) — RNP-4 accuracy<br />
0011 3 EPU < 3.704 km (2 NM) — RNP-2 accuracy<br />
0100 4 EPU < 1852 m (1NM) — RNP-1 accuracy<br />
0101 5 EPU < 926 m (0.5 NM) — RNP-0.5 accuracy<br />
0110 6 EPU < 555.6 m ( 0.3 NM) — RNP-0.3 accuracy<br />
0111 7 EPU < 185.2 m (0.1 NM) — RNP-0.1 accuracy<br />
1000 8 EPU < 92.6 m (0.05 NM) — e.g. GPS (with SA)<br />
1001 9 EPU < 30 m <strong>and</strong> VEPU < 45 m — e.g. GPS (SA off)<br />
1010 10 EPU < 10 m <strong>and</strong> VEPU < 15 m — e.g. WAAS<br />
1011 11 EPU < 3 m <strong>and</strong> VEPU < 4 m — e.g. LAAS<br />
1100 ―<br />
1111<br />
12 ― 15 Reserved<br />
Note 1.— The Estimated Position Uncertainty (EPU) used in the table is a 95 per cent accuracy bound on horizontal<br />
position. EPU is defined as the radius of a circle, centered on the reported position, such that the probability of the<br />
actual position lying outside the circle is 0.05. When reported by a GPS or GNSS system, EPU is commonly called<br />
HFOM (Horizontal Figure of Merit).<br />
Note 2.— Vertical Estimated Position Uncertainty (VEPU) is a 95 per cent accuracy limit on the vertical position<br />
(geometric altitude). VEPU is defined as a vertical position limit, such that the probability of the actual geometric altitude<br />
differing from the reported geometric altitude by more than that limit is 0.05. When reported by a GPS or GNSS system,<br />
VEPU is commonly called VFOM (Vertical Figure of Merit).<br />
Note 3.— RNP accuracy includes error sources other than sensor error, whereas horizontal error <strong>for</strong> NACP only<br />
refers to horizontal position error uncertainty.<br />
Note 4.— If geometric altitude is not being reported, then the VEPU tests are not assessed.<br />
Draft<br />
B.2.3.9.13 NAVIGATION INTEGRITY CATEGORY FOR BARO (NICBARO)<br />
This 1-bit (ME bit 44, message bit 76) subfield shall be used to indicate whether or not the barometric pressure-altitude<br />
being reported in the airborne position message (see §A.2.3.2) has been crosschecked against another source of<br />
pressure-altitude. The NICBARO subfield shall be encoded as specified in the following table. If an update has not been<br />
received from an on-board data source <strong>for</strong> NICBARO within the past 5 seconds, then the NICBARO subfield shall be<br />
encoded as a value of ZERO (0).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
B-16 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Coding Meaning<br />
0<br />
1<br />
The barometric altitude that is being reported in the Airborne<br />
Position Message is based on a Gilham coded input that has not<br />
been cross-checked against another source of pressure-altitude.<br />
The barometric altitude that is being reported in the Airborne<br />
Position Message is either based on a Gilham code input that has<br />
been cross-checked against another source of pressure-altitude<br />
<strong>and</strong> verified as being consistent, or is based on a non-Gilham<br />
coded source.<br />
Note 1.— The barometric altitude value itself is conveyed within the ADS-B Position Message.<br />
Note 2.— The NICBARO subfield provides a method of indicating a level of data integrity <strong>for</strong> aircraft installed with<br />
Gilham encoding barometric altitude sources. Because of the potential of an undetected error when using a Gilham<br />
encoded altitude source, a comparison shall be per<strong>for</strong>med with a second source <strong>and</strong> only if the two sources agree shall<br />
the NICBARO subfield be set to a value of “1”. For other barometric altitude sources (Synchro or DADS) the integrity of<br />
the data is indicated with a validity flag or SSM. No additional checks or comparisons are necessary. For these sources<br />
the NICBARO subfield shall be set to a value of “1” whenever the barometric altitude is valid.<br />
Note 3.— The use of Gilham type altimeters is strongly discouraged because of the potential <strong>for</strong> undetected altitude<br />
errors.<br />
B.2.3.9.14 SURVEILLANCE INTEGRITY LEVEL (SIL)<br />
This 2-bit (ME bits 45 — 46, message bits 77 — 78) subfield shall be used to define the probability of the integrity<br />
containment region described by the NIC subfield being exceeded <strong>for</strong> the selected position source, including any<br />
external signals used by the source. The SIL subfield shall be encoded as specified in the following table. If an update<br />
has not been received from an on-board data source <strong>for</strong> SIL within the past 5 seconds, then the SIL subfield shall be<br />
encoded as a value indicating “Unknown.”<br />
Draft<br />
The probability specified by the SIL subfield shall be the largest likelihood of any one of the following occurring when a<br />
valid geometric position is provided by the selected position source:<br />
a. a position source equipment malfunction (per hour),<br />
b. the per sample probability of a position source error larger than the horizontal or vertical integrity containment region<br />
associated with the NIC value(s), or,<br />
c. <strong>for</strong> GNSS, the probability of the signal-in-space causing a position error larger than the horizontal or vertical<br />
containment region associated with the NIC value(s) without an indication (see Note 1 below the table), within a<br />
time period determined by the positioning source, as indicated in the table.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix B B-17<br />
Coding<br />
(Binary) (Decimal)<br />
Probability of exceeding the Horizontal<br />
Containment Radius (RC) reported in the NIC<br />
Subfield without an indication<br />
Probability of exceeding the Vertical<br />
Integrity Containment Region (VPL)<br />
without an indication<br />
00 0 Unknown Unknown<br />
01 1<br />
10 2<br />
11 3<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
≤1 × 10 –3<br />
per flight hour or per sample<br />
≤1 × 10 –5<br />
per flight hour or per sample<br />
≤1 × 10 –7<br />
per flight hour or per sample<br />
≤1 × 10 –3<br />
per flight hour or per sample<br />
≤1 × 10 –5<br />
per flight hour or per sample<br />
≤2 × 10 –7<br />
per 150 seconds or per sample<br />
Note 1.— “An Indication” may include, <strong>for</strong> example, a flag <strong>for</strong> invalid position report, or a change in NIC, or switching<br />
to another data source.<br />
Note 2.— A problem <strong>for</strong> installations that include currently available GNSS receivers <strong>and</strong> FMS systems is that SIL is<br />
not output by these systems. Most implementers are expected to determine SIL by off-line analysis of the installed<br />
configuration. This off-line analysis can be per<strong>for</strong>med on the various primary <strong>and</strong> alternate means of determining the<br />
reported position. SIL is a static value <strong>for</strong> each of these configurations.<br />
Note 3.— The vertical integrity containment column only applies to NIC values greater than 8.<br />
Note 4.— The SIL code value is the lower of the horizontal or vertical coding values.<br />
Note 5.— It is recognized that there are three possible derivations of SIL: (a) the integrity value provided by<br />
navigation sensors with self-monitoring capability (e.g., GPS), (b) the reliability of aircraft systems given as indicated by<br />
a failure rate commensurate with the equipment design assurance, <strong>and</strong> (c) the integrity of other navigation systems,<br />
(e.g., RNP) that rely on ground-based self-monitoring equipment <strong>for</strong> integrity assurance, <strong>and</strong> <strong>for</strong> which no specific hourly<br />
integrity value can be ascribed. These three values are not readily interchangeable. Selection of the largest of the<br />
values as specified in the table above is felt to provide a reasonable bound on the order of magnitude of the probability<br />
of possible failures affecting ADS-B applications.<br />
Draft<br />
Note 6.— GNSS systems report integrity in terms of flight hours <strong>and</strong> FMS systems report in terms of per<br />
measurement sample (derived from a number of position measurements). While these are not equivalent measures of<br />
integrity, the difference is not considered to be critical <strong>for</strong> initial applications.<br />
B.2.3.9.14.1 Recommendations. —<br />
1. SIL is intended to reflect the integrity of the navigation source of the position in<strong>for</strong>mation broadcast, there<strong>for</strong>e the<br />
SIL value transmitted should be indicative of the true integrity of the ADS-B position data.<br />
2. If SIL in<strong>for</strong>mation is not provided by the navigation source, implementers should not arbitrarily set a SIL value of<br />
zero indicating unknown integrity.<br />
3. Unless there is a tightly coupled navigation source where SIL can be unambiguously determined <strong>and</strong> set<br />
dynamically, the ADS-B Transmitting Subsystem should provision <strong>for</strong> the static setting of SIL as part of the<br />
installation procedure.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
B-18 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
B.2.3.9.15 CAPABILITY/MODE CODES<br />
This 2-bit (ME bits 52 — 53, Message bits 84 — 85) subfield shall be used to indicate the current operational status of<br />
TCAS/ACAS systems/functions. This subfield shall be encoded as specified in the following table. If an update has not<br />
been received from an on-board data source <strong>for</strong> a Capability/<strong>Mode</strong> Code data element within the past 2 seconds, then<br />
that data element shall be encoded with a value of zero (0).<br />
Coding Meaning<br />
ME bit 52 = 0 TCAS/ACAS operational or unknown<br />
ME bit 52 = 1 TCAS/ACAS not operational<br />
ME bit 53 = 0 No TCAS/ACAS Resolution Advisory active<br />
ME bit 53 = 1 TCAS/ACAS Resolution Advisory active<br />
B.2.3.9.16 EMERGENCY/PRIORITY STATUS<br />
This 3-bit (ME bits 54 — 56, message bits 86 — 88) subfield shall be used to provide additional in<strong>for</strong>mation regarding<br />
aircraft status. The Emergency/Priority Status subfield shall be encoded as specified in the following table. If an update<br />
has not been received from an on-board data source <strong>for</strong> the Emergency/Priority Status within the past 5 seconds, then<br />
the emergency/priority status subfield shall be encoded with a value indicating no emergency.<br />
Coding<br />
(Binary) (Decimal) Meaning<br />
000 0 No emergency<br />
001 1 General emergency<br />
010 2 Lifeguard/medical emergency<br />
011 3 Minimum fuel<br />
Draft<br />
100 4 No communications<br />
101 5 Unlawful interference<br />
110 6 Downed aircraft<br />
111 7 Reserved<br />
B.2.3.10 AIRCRAFT OPERATIONAL STATUS<br />
The aircraft operational status message squitter shall be <strong>for</strong>matted as specified in the definition of register number 6516<br />
<strong>and</strong> in the following paragraphs.<br />
B.2.3.10.1 TRANSMISSION RATE<br />
The aircraft operational status (type = 31 <strong>and</strong> subtype=0, <strong>for</strong> airborne participants) ADS-B message shall be broadcast<br />
at r<strong>and</strong>om intervals that are uni<strong>for</strong>mly distributed over the range of 0.7 to 0.9 seconds when the target state <strong>and</strong> status<br />
message (type=29 <strong>and</strong> subtype=0) is not being broadcast <strong>and</strong> there has been a change within the past 24 ±1 seconds<br />
<strong>for</strong> the value of any of the following message parameters:<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix B B-19<br />
a) ACAS operational;<br />
b) ACAS resolution advisory active;<br />
c) NACP;<br />
d) SIL.<br />
Otherwise the aircraft operational status (type = 31 <strong>and</strong> subtype = 0, <strong>for</strong> airborne participants) ADS-B message shall be<br />
broadcast at r<strong>and</strong>om intervals that are uni<strong>for</strong>mly distributed over the range of 2.4 to 2.6 seconds.<br />
B.2.3.10.2 MESSAGE DELIVERY<br />
Message delivery shall be accomplished using the event-driven protocol (see §B.2.3.7).<br />
B.2.3.10.3 CAPABILITY CLASS (CC) CODES<br />
This 16-bit (ME bits 9–24, Message bits 41–56) subfield in the airborne aircraft operational status message (subtype=0)<br />
or 12-bit (ME bits 9–20, message bits 41–52) subfield in the surface aircraft operational status message (subtype=1)<br />
shall be used to report the operational capability of the aircraft. Encoding of the CC subfield shall be defined as specified<br />
in the following tables.<br />
For an ADS-B transmitting subsystem compliant with this appendix, if an update has not been received from an onboard<br />
data source within the past 5 seconds <strong>for</strong> any data element of the capability class codes subfield, then the data<br />
associated with that data element shall be considered invalid <strong>and</strong> so reflected in the encoding of that message element<br />
to reflect no capability or unknown capability.<br />
Airborne Capability Class (CC) Code <strong>for</strong> Version 1 Systems<br />
Msg Bit # 41 42 43 44 45 46 47 48 49 50 51 – 56<br />
Draft<br />
“ME” Bit # 9 10 11 12 13 14 15 16 17 18 19 – 24<br />
Content<br />
Subfield Coding:<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Service level<br />
MSBs = 0 0<br />
Not-ACAS CDTI<br />
1. Not-ACAS (Airborne Collision Avoidance System Status)<br />
0 = ACAS operational or unknown<br />
1 = ACAS not installed or not operational<br />
2. CDTI (Cockpit Display of Traffic In<strong>for</strong>mation Status)<br />
0 = Traffic display not operational<br />
1 = Traffic display operational<br />
Service level<br />
LSBs = 0 0<br />
3. ARV (Air-Referenced Velocity Report Capability)<br />
0 = No capability <strong>for</strong> sending messages to support Air-Referenced Velocity Reports<br />
1 = Capability of sending messages to support Air-Referenced Velocity Reports<br />
ARV TS TC Reserved<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
B-20 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
4. TS (Target State Report Capability)<br />
0 = No capability <strong>for</strong> sending messages to support Target State Reports<br />
1 = Capability of sending messages to support Target State Reports<br />
5. TC (Target Change Report Capability)<br />
0 = No capability <strong>for</strong> sending messages to support Trajectory Change Reports<br />
1 = Capability of sending messages to support TC+0 Report only<br />
2 = Capability of sending in<strong>for</strong>mation <strong>for</strong> multiple TC Reports<br />
3 = Reserved<br />
Surface Capability Class (CC) Code <strong>for</strong> Version 1 Systems<br />
Msg Bit # 41 42 43 44 45 46 47 48 49 50 51 52<br />
“ME” Bit # 9 10 11 12 13 14 15 16 17 18 19 20<br />
Content<br />
Subfield Coding:<br />
Service level<br />
MSBs = 0 0<br />
POA CDTI<br />
1. CDTI (Cockpit Display of Traffic In<strong>for</strong>mation)<br />
0 = Traffic display not operational<br />
1 = Traffic display operational<br />
Service level<br />
LSBs = 0 0<br />
2. POA (Position Offset Applied)<br />
0 = Position transmitted is not the ADS-B position reference point<br />
1 = Position transmitted is the ADS-B position reference point<br />
3. B2 Low (Class B2 transmit power less than 70 Watts)<br />
0 = Greater than or equal to 70 Watts transmit power<br />
1 = Less than 70 Watts transmit power<br />
B.2.3.10.4 OPERATIONAL MODE (OM)<br />
B2<br />
Low<br />
Reserved<br />
Draft<br />
This 16-bit (ME bits 25–40, message bits 57–72) subfield shall be used to indicate the operational modes that are active<br />
on board the aircraft. Encoding of the subfield shall be as specified in the following table.<br />
Msg Bit # 57 58 59 60 61 62-72<br />
“ME” Bit # 25 26 27 28 29 30-40<br />
OM <strong>for</strong>mat<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
0 0<br />
ACAS<br />
RA active<br />
0 1 Reserved<br />
1 0 Reserved<br />
1 1 Reserved<br />
IDENT switch<br />
active<br />
Receiving ATC<br />
services<br />
Reserved<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix B B-21<br />
Subfield Coding:<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1. ACAS Resolution Advisory (RA) active<br />
0 = ACAS II or ACAS RA not active<br />
1 = ACAS RA is active<br />
2. IDENT switch active<br />
0 = Ident switch not active<br />
1 = Ident switch active — retained <strong>for</strong> 18 ±1 seconds<br />
3. Receiving ATC services<br />
0 = Aircraft not receiving ATC services<br />
1 = Aircraft receiving ATC services<br />
B.2.3.10.5 EXTENDED SQUITTER VERSION NUMBER<br />
This 3-bit (ME bits 41–43, message bits 73–75) subfield shall be used to indicate the version number of the <strong>for</strong>mats <strong>and</strong><br />
protocols in use on the aircraft installation. Encoding of the subfield shall be as specified in the following table.<br />
Coding<br />
(Binary) (Decimal)<br />
<strong>Extended</strong> squitter version number subfield<br />
Meaning<br />
000 0 Con<strong>for</strong>mant to Doc 9871, 1st Edition, Appendix A<br />
001 1 Con<strong>for</strong>mant to Doc 9871, 1st Edition, Appendix B<br />
010 – 111 2 – 7 Reserved<br />
B.2.3.10.6 NAVIGATION INTEGRITY CATEGORY (NIC) AND NIC SUPPLEMENT<br />
Draft<br />
This B.2.3.10.6.1 The NIC supplement is a 1-bit (ME bit 44, message bit 76) subfield that shall be used in conjunction<br />
with the TYPE Code to encode the navigation integrity category (NIC) of the transmitting ADS-B participant to allow<br />
surveillance applications to determine whether the reported geometric position has an acceptable integrity containment<br />
region <strong>for</strong> the intended use. Encoding of the NIC Supplement subfield shall be as specified in the following table. If an<br />
update has not been received from an on-board data source <strong>for</strong> the NIC Supplement subfield within the past 5 seconds,<br />
then the NIC Supplement subfield shall be encoded to indicate that RC is “Unknown.”<br />
Note. — The first 5-bit field (“ME” bits 1–5, Message bits 33–37) in every <strong>Mode</strong> S extended squitter message<br />
contains the <strong>for</strong>mat TYPE code. The <strong>for</strong>mat TYPE code differentiates the messages into several classes: Airborne<br />
Position, Airborne Velocity, Surface Position, Identification, Aircraft Intent, Aircraft State, etc. In addition, the <strong>for</strong>mat<br />
TYPE code also encodes the Navigation Integrity Category (NIC) value of the source used <strong>for</strong> the position report. The<br />
NIC value is used to allow surveillance applications to determine whether the reported geometric position has an<br />
acceptable level of integrity containment region <strong>for</strong> the intended use. The NIC integrity containment region is described<br />
horizontally <strong>and</strong> vertically using two parameters: the containment radius, RC, <strong>and</strong> the Vertical Protection Limit, VPL. The<br />
<strong>for</strong>mat TYPE code also differentiates the Airborne Messages as to the type of their altitude measurements: barometric<br />
pressure altitude or GNSS height (HAE). The 5-bit encoding <strong>for</strong> <strong>for</strong>mat TYPE code <strong>and</strong> NIC values con<strong>for</strong>m to the<br />
definition contained in the table in §B.2.3.1.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
B-22 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
B.2.3.10.6.2 If an update has not been received from an on-board data source <strong>for</strong> the NIC value within the past 5<br />
seconds, then the TYPE Code <strong>and</strong> NIC Supplement shall be encoded to indicate that RC is “Unknown.”<br />
NIC<br />
value<br />
Containment Radius (RC) <strong>and</strong><br />
Vertical Protection Limit (VPL)<br />
Airborne<br />
position<br />
TYPE Code<br />
Airborne Surface<br />
NIC<br />
supplement<br />
Code<br />
Surface<br />
position<br />
TYPE Code<br />
NIC<br />
supplement<br />
Code<br />
0 RC unknown 0, 18 or 22 0 0, 8 0<br />
1 RC < 20 NM (37.04 km) 17 0 N/A N/A<br />
2 RC < 8 NM (14.816 km) 16 0 N/A N/A<br />
3 RC < 4 NM (7.408 km) 16 1 N/A N/A<br />
4 RC < 2 NM (3.704 km) 15 0 N/A N/A<br />
5 RC < 1 NM (1 852 m) 14 0 N/A N/A<br />
6<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
RC < 0.6 NM (1 111.2 m) 13 1<br />
RC < 0.5 NM (926 m) 13 0<br />
N/A N/A<br />
7 RC < 0.2 NM (370.4 m) 12 0 N/A N/A<br />
8 RC < 0.1 NM (185.2 m) 11 0 7 0<br />
9 RC < 75 m <strong>and</strong> VPL < 112 m 11 1 7 1<br />
10 RC < 25 m <strong>and</strong> VPL < 37.5 m 10 or 21 0 6 0<br />
11 RC < 7.5 m <strong>and</strong> VPL < 11 m 9 or 20 0 5 0<br />
Note 1.— “N/A” means “This NIC value is not available in the ADS-B surface position message <strong>for</strong>mats.”<br />
Note 2.— The NIC parameter is broadcast partly in the TYPE subfield of airborne position <strong>and</strong> surface position<br />
messages, <strong>and</strong> partly in the NIC Supplement subfield of the aircraft operational status message. The NIC integrity<br />
containment region is described horizontally <strong>and</strong> vertically using the two parameters, RC <strong>and</strong> VPL.<br />
B.2.3.10.7 NAVIGATION ACCURACY CATEGORY FOR POSITION (NACP)<br />
Draft<br />
This 4-bit (ME bits 45–48, message bits 77–80) subfield shall be used to announce 95 per cent accuracy limits <strong>for</strong> the<br />
horizontal position (<strong>and</strong> <strong>for</strong> some NACP values, the vertical position) that is being currently broadcast in Airborne<br />
Position <strong>and</strong> Surface Position Messages. Encoding of the subfield shall be as specified in the following table. If an<br />
update has not been received from an on-board data source <strong>for</strong> NACP within the past 5 seconds, then the NACP subfield<br />
shall be encoded as a value indicating unknown accuracy.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix B B-23<br />
Coding<br />
(Binary) (Decimal) Meaning = 95% horizontal <strong>and</strong> vertical accuracy bounds (EPU <strong>and</strong> VEPU)<br />
0000 0 EPU ≥ 18.52 km (10 NM) — Unknown accuracy<br />
0001 1 EPU < 18.52 km (10 NM) — RNP-10 accuracy<br />
0010 2 EPU < 7.408 km (4 NM) — RNP-4 accuracy<br />
0011 3 EPU < 3.704 km (2 NM) — RNP-2 accuracy<br />
0100 4 EPU < 1 852 m (1 NM) — RNP-1 accuracy<br />
0101 5 EPU < 926 m (0.5 NM) — RNP-0.5 accuracy<br />
0110 6 EPU < 555.6 m ( 0.3 NM) — RNP-0.3 accuracy<br />
0111 7 EPU < 185.2 m (0.1 NM) — RNP-0.1 accuracy<br />
1000 8 EPU < 92.6 m (0.05 NM) — e.g. GPS (with SA)<br />
1001 9 EPU < 30 m <strong>and</strong> VEPU < 45 m — e.g. GPS (SA off)<br />
1010 10 EPU < 10 m <strong>and</strong> VEPU < 15 m — e.g. WAAS<br />
1011 11 EPU < 3 m <strong>and</strong> VEPU < 4 m — e.g. LAAS<br />
1100 –<br />
1111<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
12 – 15<br />
Reserved<br />
Note 1.— The Estimated Position Uncertainty (EPU) used in the table is a 95 per cent accuracy bound on horizontal<br />
position. EPU is defined as the radius of a circle, centered on the reported position, such that the probability of the actual<br />
position lying outside the circle is 0.05. When reported by a GNSS system, EPU is commonly called HFOM (Horizontal<br />
Figure of Merit).<br />
Note 2.— Vertical Estimated Position Uncertainty (VEPU) is a 95 per cent accuracy limit on the vertical position<br />
(geometric altitude). VEPU is defined as a vertical position limit, such that the probability of the actual geometric altitude<br />
differing from the reported geometric altitude by more than that limit is 0.05. When reported by a GNSS system, VEPU is<br />
commonly called VFOM (Vertical Figure of Merit).<br />
Draft<br />
Note 3.— RNP accuracy includes error sources other than sensor error, whereas horizontal error <strong>for</strong> NACP only<br />
refers to horizontal position error uncertainty.<br />
Note 4.— If geometric altitude is not being reported, then the VEPU tests are not assessed.<br />
B.2.3.10.8 BAROMETRIC ALTITUDE QUALITY (BAQ)<br />
This 2-bit (ME bits 49–50, message bits 81–82) subfield in the airborne operational status message (subtype=0) shall be<br />
set to zero (0) by ADS-B transmitting subsystems.<br />
B.2.3.10.9 SURVEILLANCE INTEGRITY LEVEL (SIL)<br />
This 2-bit (ME bits 51–52, Message bits 83–84) subfield shall be used to define the probability of the integrity<br />
containment region described by the NIC parameter being exceeded <strong>for</strong> the selected position source, including any<br />
external signals used by the source. Encoding of the subfield shall be as shown in the following table. For installations<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
B-24 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
where the SIL value is being dynamically updated, if an update has not been received from an on-board data source <strong>for</strong><br />
SIL within the past 5 seconds, then the SIL subfield shall be encoded as a value indicating “Unknown.”<br />
The probability specified by the SIL subfield shall be the largest likelihood of any one of the following occurring when a<br />
valid geometric position is provided by the selected position source:<br />
a) a position source equipment malfunction (per hour);<br />
b) the per sample probability of a position source error larger than the horizontal or vertical integrity containment<br />
region associated with the NIC value(s); or<br />
c) <strong>for</strong> GNSS, the probability of the signal-in-space causing a position error larger than the horizontal or vertical<br />
containment region associated with the NIC value(s) without an indication (see note 1 below the table), within a<br />
time period determined by the positioning source, as indicated in the table.<br />
Coding<br />
(Binary) (Decimal)<br />
Probability of exceeding the Horizontal<br />
Containment Radius (RC) reported in the<br />
NIC Subfield without an indication<br />
Probability of exceeding the<br />
Vertical Integrity Containment Region (VPL)<br />
without an indication<br />
00 0 Unknown Unknown<br />
01 1 ≤1 × 10 - 3 per flight hour or per sample ≤1 × 10 - 3 per flight hour or per sample<br />
10 2 ≤1 × 10 - 5 per flight hour or per sample ≤1 × 10 - 5 per flight hour or per sample<br />
11 3 ≤1 × 10 - 7 per flight hour or per sample ≤2 × 10 - 7 per 150 seconds or per sample<br />
Note 1.— “An Indication” may include, <strong>for</strong> example, a flag <strong>for</strong> invalid position report, or a change in NIC, or switching<br />
to another data source.<br />
Note 2.— A problem <strong>for</strong> installations that include currently available GNSS receivers <strong>and</strong> FMS systems is that SIL is<br />
not output by these systems. Most implementers are expected to determine SIL by off-line analysis of the installed<br />
configuration. This off-line analysis can be per<strong>for</strong>med on the various primary <strong>and</strong> alternate means of determining the<br />
reported position. SIL is a static value <strong>for</strong> each of these configurations.<br />
Draft<br />
Note 3.— The vertical integrity containment column applies to NIC values greater than 8.<br />
Note 4.— The SIL code value is the lower of the horizontal or vertical coding values.<br />
Note 5.— It is recognized that there are three possible derivations of SIL: (a) the integrity value provided by<br />
navigation sensors with self-monitoring capability (e.g. GPS), (b) the reliability of aircraft systems given as indicated by a<br />
failure rate commensurate with the equipment design assurance, <strong>and</strong> (c) the integrity of other navigation systems,<br />
(e.g. RNP) that rely on ground-based self-monitoring equipment <strong>for</strong> integrity assurance, <strong>and</strong> <strong>for</strong> which no specific hourly<br />
integrity value can be ascribed. These three values are not readily interchangeable. Selection of the largest of the values<br />
as specified in the table above is felt to provide a reasonable bound on the order of magnitude of the probability of<br />
possible failures affecting ADS-B applications.<br />
Note 6.— GNSS systems report integrity in terms of flight hours <strong>and</strong> FMS systems report in terms of per<br />
measurement sample (derived from a number of position measurements). While these are not equivalent measures of<br />
integrity, the difference is not considered to be critical <strong>for</strong> initial applications.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix B B-25<br />
B.2.3.10.9.1 Recommendations.—<br />
1. SIL is intended to reflect the integrity of the navigation source of the position in<strong>for</strong>mation broadcast, there<strong>for</strong>e<br />
the SIL value transmitted should be indicative of the true integrity of the ADS-B position data.<br />
2. If SIL in<strong>for</strong>mation is not provided by the navigation source, implementers should not arbitrarily set an SIL value<br />
of zero indicating unknown integrity.<br />
3. Unless there is a tightly coupled navigation source where SIL can be unambiguously determined <strong>and</strong> set<br />
dynamically, the ADS-B Transmitting Subsystem should provision <strong>for</strong> the static setting of SIL as part of the<br />
installation procedure.<br />
B.2.3.10.10 BAROMETRIC ALTITUDE INTEGRITY CODE (NICBARO)<br />
This 1-bit (ME bit 53, message bit 85) subfield shall be used to indicate whether or not the barometric pressure-altitude<br />
being reported in the airborne position message has been crosschecked against another source of pressure-altitude.<br />
The NICBARO subfield shall be encoded as shown in the following table. If an update has not been received from an onboard<br />
data source <strong>for</strong> NICBARO within the past 5 seconds, then the NICBARO subfield shall be encoded as a value of<br />
ZERO (0).<br />
Coding Meaning<br />
0<br />
1<br />
The barometric altitude that is being reported in the Airborne<br />
Position Message is based on a Gilham coded input that has not<br />
been cross-checked against another source of pressure-altitude<br />
The barometric altitude that is being reported in the Airborne<br />
Position Message is either based on a Gilham code input that has<br />
been cross-checked against another source of pressure-altitude<br />
<strong>and</strong> verified as being consistent, or is based on a non-Gilham<br />
coded source<br />
Draft<br />
Note 1.— The barometric altitude value itself is conveyed within the ADS-B Position Message.<br />
B.2.3.10.10.1 The NICBARO subfield provides a method of indicating a level of data integrity <strong>for</strong> aircraft installed with<br />
Gilham encoding barometric altitude sources. Because of the potential of an undetected error when using a Gilham<br />
encoded altitude source, a comparison shall be per<strong>for</strong>med with a second source <strong>and</strong> only if the two sources agree shall<br />
the NICBARO subfield be set to a value of “1”. For other barometric altitude sources (Synchro or DADS) the integrity of<br />
the data is indicated with a validity flag or SSM. No additional checks or comparisons are necessary. For these sources<br />
the NICBARO subfield shall be set to a value of “1” whenever the barometric altitude is valid.<br />
B.2.3.10.11 AIRCRAFT LENGTH AND WIDTH CODES<br />
This 4-bit (ME bits 21–24, message bits 53–56) subfield shall be used in the surface aircraft operational status message<br />
(subtype=1) to describe the amount of space that an Aircraft or Ground Vehicle occupies. The A/V length <strong>and</strong> width<br />
code shall be based on the actual dimensions of the transmitting Aircraft or Surface Vehicle as specified in the following<br />
table. Each aircraft or vehicle shall be assigned the smallest A/V length <strong>and</strong> width code consistent with its actual<br />
dimensions. Each A/V shall be assigned the smallest A/V length <strong>and</strong> width codes from the following table <strong>for</strong> which the<br />
actual length <strong>and</strong> width is less than or equal to specified upper bounds.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
B-26 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
A/V — L/W<br />
code (Decimal)<br />
ME bit<br />
49<br />
Length code Width code<br />
ME bit<br />
50<br />
ME bit<br />
51<br />
ME bit<br />
52<br />
Upper-bound length <strong>and</strong> width <strong>for</strong><br />
each length/width code<br />
Length<br />
(metres)<br />
Width<br />
(metres)<br />
0<br />
0 0 0<br />
0<br />
15<br />
11.5<br />
1<br />
1<br />
23<br />
2<br />
0 0 1<br />
0<br />
25<br />
28.5<br />
3<br />
1<br />
34<br />
4<br />
0 1 0<br />
0<br />
35<br />
33<br />
5<br />
1<br />
38<br />
6<br />
0 1 1<br />
0<br />
45<br />
39.5<br />
7<br />
1<br />
45<br />
8<br />
1 0 0<br />
0<br />
55<br />
45<br />
9<br />
1<br />
52<br />
10<br />
1 0 1<br />
0<br />
65<br />
59.5<br />
11<br />
1<br />
67<br />
12<br />
1 1 0<br />
0<br />
75<br />
72.5<br />
13<br />
1<br />
80<br />
14<br />
1 1 1<br />
0<br />
85<br />
80<br />
15<br />
1<br />
90<br />
If the aircraft is longer than 85 m or wider than 90 m, L/W Code 15 shall be used.<br />
B.2.3.10.12 TRACK ANGLE/HEADING<br />
Draft<br />
The track angle/heading shall be a 1-bit (“ME” bit 53, Message bit 85) subfield of the ADS-B aircraft operational status<br />
message (subtype=1, <strong>for</strong> surface participants) that allows correct interpretation of the data contained in the<br />
heading/ground track subfield of the ADS-B surface position message. The bit values shall be interpreted as follows:<br />
0 = Target heading angle is being reported.<br />
1 = Track angle is being reported.<br />
B.2.3.10.13 HORIZONTAL REFERENCE DIRECTION (HRD)<br />
This 1-bit (ME bit 54, Message bit 86) subfield shall be used to indicate the reference direction (True North or Magnetic<br />
North) <strong>for</strong> horizontal directions such as heading, track angle, selected heading, selected track angle, etc. The horizontal<br />
reference direction subfield shall be encoded as specified in the following table:<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix B B-27<br />
HRD value Meaning<br />
0 True North<br />
1 Magnetic North<br />
B.2.4 EXTENDED SQUITTER INITIALIZATION AND TIMEOUT<br />
Initialization <strong>and</strong> timeout functions <strong>for</strong> extended squitter broadcast shall be per<strong>for</strong>med by the transponder <strong>and</strong> are<br />
specified in Annex 10, Volume IV, 3.1.2.<br />
Note.— A description of these functions is presented in the following paragraphs to serve as reference material <strong>for</strong><br />
the section on the general <strong>for</strong>matter/manager (GFM) (see §B.2.5).<br />
B.2.4.1 INITIATION OF EXTENDED SQUITTER BROADCAST<br />
Initialization of extended squitter broadcast shall be per<strong>for</strong>med by the transponder as specified in §A.2.4.1.<br />
B.2.4.2 REGISTER TIME-OUT<br />
Register time-out processing shall be per<strong>for</strong>med by the transponder as specified in §A.2.4.2.<br />
B.2.4.3 TERMINATION OF EXTENDED SQUITTER BROADCAST<br />
Termination of extended squitter broadcast shall be per<strong>for</strong>med by the transponder as specified in §A.2.4.3.<br />
B.2.4.4 REQUIREMENTS FOR NON-TRANSPONDER DEVICES<br />
Draft<br />
Non-transponder devices shall provide the same functionality <strong>for</strong> initialization; register time-out <strong>and</strong> broadcast<br />
termination as specified <strong>for</strong> the transponder case in §B.2.4.1 to §B.2.4.3, except that a non-transponder device operating<br />
on the surface shall continue to broadcast DF=18 with message TYPE Code=0 at a rate specified <strong>for</strong> the surface<br />
position message even though it has lost its navigation input.<br />
Note.— Continued broadcast of the surface position message is needed to support the operation of surface<br />
multilateration systems.<br />
B.2.5 GENERAL FORMATTER/MANAGER (GFM)<br />
The general <strong>for</strong>matter/manager (GFM) shall <strong>for</strong>mat messages <strong>for</strong> insertion in the transponder registers.<br />
Note.— In addition to data <strong>for</strong>matting, there are other tasks that are per<strong>for</strong>med by this function.<br />
B.2.5.1 NAVIGATION SOURCE SELECTION<br />
The GFM shall per<strong>for</strong>m navigation source selection as specified in §A.2.5.1.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
B-28 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
B.2.5.2 LOSS OF INPUT DATA<br />
The GFM shall h<strong>and</strong>le loss of input data as specified in §A.2.5.2.<br />
B.2.5.3 SPECIAL PROCESSING FOR FORMAT TYPE CODE ZERO<br />
Special processing <strong>for</strong> <strong>for</strong>mat TYPE Code zero shall be per<strong>for</strong>med as specified in §A.2.5.3.<br />
B.2.5.4 TRANSPONDER CAPABILITY REPORTING<br />
Transponder capability reporting shall be per<strong>for</strong>med as specified in §A.2.5.4.<br />
B.2.5.5 HANDLING OF EVENT-DRIVEN PROTOCOL<br />
The event-driven interface protocol provides a general purpose interface into the transponder function <strong>for</strong> messages<br />
beyond those that are regularly transmitted all the time (provided input data are available). This protocol shall operate by<br />
having the transponder broadcast a message once each time the event-driven register is loaded by the GFM.<br />
Note.— This gives the GFM complete freedom in setting the update rate (up to a maximum) <strong>and</strong> duration of<br />
broadcast <strong>for</strong> applications such as emergency status <strong>and</strong> intent reporting.<br />
In addition to <strong>for</strong>matting, the GFM shall control the timing of message insertion so that it provides the necessary pseudor<strong>and</strong>om<br />
timing variation <strong>and</strong> does not exceed the maximum transponder broadcast rate <strong>for</strong> the event-driven protocol.<br />
B.2.5.5.1 TRANSPONDER SUPPORT FOR EVENT-DRIVEN MESSAGES<br />
Transponder support <strong>for</strong> event-driven messages shall be as specified in §A.2.5.5.1.<br />
B.2.5.5.2 GFM USE OF EVENT-DRIVEN PROTOCOL<br />
GFM use of the event-driven protocol shall be as specified in §A.2.5.5.2.<br />
B.2.5.5.3 EVENT-DRIVEN MESSAGE TRANSMISSION SCHEDULING FUNCTION<br />
Draft<br />
The event-driven message scheduling function shall ensure that the total event-driven message rate does not exceed 2<br />
transmitted messages per second.<br />
The event-driven message scheduling function shall apply the following rules as a means of prioritizing the event-driven<br />
message transmissions <strong>and</strong> limiting the transmission rates:<br />
a) the event-driven message scheduling function shall reorder, as necessary, pending event-driven messages<br />
according to the following message priorities, listed below in descending order from highest to lowest priority.<br />
1) When an extended squitter aircraft status message is active <strong>for</strong> the broadcast of an emergency/priority<br />
condition (type=28 <strong>and</strong> subtype=1), or an ACAS RA broadcast (type=28, subtype=2), that message shall<br />
continue to be transmitted at r<strong>and</strong>om intervals that are uni<strong>for</strong>mly distributed over the range of 0.7 to 0.9<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix B B-29<br />
seconds, relative to the previous aircraft status message <strong>for</strong> the duration of the emergency or RA condition<br />
if the target state <strong>and</strong> status message is not being broadcast. If the target state <strong>and</strong> status message with<br />
subtype=zero (0) is being broadcast, then the aircraft status shall be broadcast at r<strong>and</strong>om intervals that are<br />
uni<strong>for</strong>mly distributed over the range of 2.4 to 2.6 seconds relative to the previous aircraft status message<br />
<strong>for</strong> the duration of the emergency conditions established in accordance with Tables B-2-97a <strong>and</strong> B-2-97b.<br />
2) Reserved <strong>for</strong> future use.<br />
3) Reserved <strong>for</strong> future use.<br />
4) When an aircraft operational status message is active (type=31 <strong>and</strong> subtype=0) <strong>and</strong> there has been a<br />
change in one or more of the message parameters within the past 24 seconds that results in a higher<br />
update rate-reporting requirement, the aircraft operational status message shall be transmitted at the rate<br />
specified in §B.2.3.10.1.<br />
5) When a target state <strong>and</strong> status message is active <strong>for</strong> the broadcast of target state in<strong>for</strong>mation (message<br />
type=29 <strong>and</strong> subtype=0) the target state <strong>and</strong> status message shall be transmitted at r<strong>and</strong>om intervals that<br />
are uni<strong>for</strong>mly distributed over the range of 1.2 to 1.3 seconds relative to the previous target state <strong>and</strong><br />
status message <strong>for</strong> as long as target state in<strong>for</strong>mation is available <strong>and</strong> valid.<br />
6) Reserved <strong>for</strong> future use.<br />
7) When an aircraft operational status message is active (type=31 <strong>and</strong> subtype=0) <strong>and</strong> there has been no<br />
change in the message parameters that would require an increased broadcast rate, the aircraft operational<br />
status message shall be transmitted at the rate specified in §B.2.3.10.1.<br />
8) This priority level applies as a default to any event-driven message type <strong>and</strong> subtype combination not<br />
specifically identified at a higher priority level above. Event-driven messages of this default priority level<br />
shall be delivered to the transponder on a first-in-first-out basis at equal priority.<br />
b) the event-driven message scheduling function shall limit the number of event-driven messages provided to the<br />
transponder to two (2) messages per second.<br />
Draft<br />
c) if (b) results in a queue of messages awaiting delivery to the transponder, the higher priority pending<br />
messages, according to (a) above shall be delivered to the transponder <strong>for</strong> transmission be<strong>for</strong>e lower priority<br />
messages.<br />
d) if (b) results in a queue of messages awaiting delivery to the transponder, new Event-Driven messages shall<br />
directly replace older messages of the same exact type <strong>and</strong> subtype (where a subtype is defined) that are<br />
already in the pending message queue. The updated message shall maintain the same position in the message<br />
queue as the pending message that is being replaced.<br />
e) if (b) above results in a queue of messages awaiting delivery to the transponder, then pending message(s)<br />
shall be deleted from the message transmission queue if not delivered to the transponder <strong>for</strong> transmission, or<br />
not replaced with a newer message of the same message Type <strong>and</strong> Subtype, within the Message Lifetime<br />
value specified in the following table.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
B-30 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Message type Message subtype Message lifetime<br />
23<br />
0 5.0 seconds (±0.2 s)<br />
> 0 Reserved<br />
24 Reserved<br />
25 Reserved<br />
26 Reserved<br />
27 Reserved<br />
28<br />
29<br />
= 1 5.0 seconds (±0.2 s)<br />
= 2<br />
0, > 2 Reserved<br />
10 seconds after RAT<br />
transitions from 0 to 1<br />
= 0 2.5 seconds (±0.2 s)<br />
> 0 Reserved<br />
30 Reserved<br />
31<br />
= 0, 1 5.0 seconds (±0.2 s)<br />
> 1 Reserved<br />
B.2.5.5.4 A default message lifetime of 20 seconds shall be used <strong>for</strong> queue management unless otherwise specified.<br />
B.2.5.6 DERIVATION OF MODE FIELD BITS FOR AIRCRAFT INTENTION PARAMETERS<br />
Derivation of mode field bits <strong>for</strong> aircraft intention parameters shall be per<strong>for</strong>med as specified in §A.2.5.6.<br />
B.2.6 LATITUDE/LONGITUDE CODING USING COMPACT POSITION REPORTING (CPR)<br />
CPR coding shall be per<strong>for</strong>med as specified in §AC.2.6.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix B B-31<br />
TABLES FOR SECTION B.2<br />
Formats that shall be used <strong>for</strong> the following tables are presented in this section:<br />
Table B-2-6. BDS code 0,6 — <strong>Extended</strong> squitter surface position<br />
Table B-2-8. BDS code 0,8 — <strong>Extended</strong> squitter aircraft identification <strong>and</strong> category<br />
Table B-2-9a. BDS code 0,9 — <strong>Extended</strong> squitter airborne velocity<br />
(Subtypes 1 <strong>and</strong> 2: Velocity over ground)<br />
Table B-2-9b. BDS code 0,9 — <strong>Extended</strong> squitter airborne velocity<br />
(Subtypes 3 <strong>and</strong> 4: Airspeed <strong>and</strong> heading)<br />
Table B-2-97a. BDS code 6,1 — Aircraft status<br />
(Subtype 1: Emergency/priority status)<br />
Table B-2-97b. BDS code 6,1 — Aircraft status<br />
(Subtype 2: <strong>Extended</strong> squitter ACAS RA broadcast)<br />
Table B-2-101. BDS code 6,5 — Aircraft operational status<br />
All other tables shall be <strong>for</strong>matted as specified in Appendix A.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
B-32 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table B-2-6. BDS code 0,6 — <strong>Extended</strong> squitter surface position<br />
1 MSB<br />
2 FORMAT TYPE CODE<br />
3 (specified in §B.2.3.1)<br />
4<br />
5 LSB<br />
6 MSB<br />
7<br />
8 MOVEMENT<br />
9 (specified in §B.2.3.3.1)<br />
10<br />
11<br />
12 LSB<br />
13 STATUS <strong>for</strong> Heading/ground track: 0 = Invalid, 1 = Valid<br />
14 MSB = 180 degrees<br />
15<br />
16 HEADING/GROUND TRACK<br />
17 (specified in §B.2.3.3.2)<br />
18<br />
19<br />
20 LSB = 360/128 degrees<br />
21 TIME (T) (specified in §B.2.3.3.4)<br />
22 CPR FORMAT (F) (specified in §B.2.3.3.3)<br />
23 MSB<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29<br />
30 ENCODED LATITUDE 17 bits<br />
31 (CPR surface <strong>for</strong>mat specified in §BC.2.6)<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39 LSB<br />
40 MSB<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
47 ENCODED LONGITUDE 17 bits<br />
48 (CPR surface <strong>for</strong>mat specified in §BC.2.6)<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56 LSB<br />
PURPOSE: To provide accurate surface position in<strong>for</strong>mation.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix B B-33<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table B-2-8. BDS code 0,8 — <strong>Extended</strong> squitter aircraft identification <strong>and</strong> category<br />
1 MSB<br />
2 FORMAT TYPE CODE<br />
3 (specified in §B.2.3.1)<br />
4<br />
5 LSB<br />
6 MSB<br />
7 EMITTER CATEGORY<br />
8 LSB<br />
9 MSB<br />
10<br />
11 CHARACTER 1<br />
12<br />
13<br />
14 LSB<br />
15 MSB<br />
16<br />
17 CHARACTER 2<br />
18<br />
19<br />
20 LSB<br />
21 MSB<br />
22<br />
23 CHARACTER 3<br />
24<br />
25<br />
26 LSB<br />
27 MSB<br />
28<br />
29 CHARACTER 4<br />
30<br />
31<br />
32 LSB<br />
33 MSB<br />
34<br />
35 CHARACTER 5<br />
36<br />
37<br />
38 LSB<br />
39 MSB<br />
40<br />
41 CHARACTER 6<br />
42<br />
43<br />
44 LSB<br />
45 MSB<br />
46<br />
47 CHARACTER 7<br />
48<br />
49<br />
50 LSB<br />
51 MSB<br />
52<br />
53 CHARACTER 8<br />
54<br />
55<br />
56 LSB<br />
PURPOSE: To provide aircraft identification <strong>and</strong> category <strong>for</strong> aircraft that are<br />
equipped with 1 090 MHz ADS-B.<br />
Format type shall be coded as follows:<br />
1 = Aircraft identification, category set D<br />
2 = Aircraft identification, category set C<br />
3 = Aircraft identification, category set B<br />
4 = Aircraft identification, category set A<br />
Aircraft/vehicle category shall be coded as follows:<br />
Set A:<br />
Set B:<br />
Set C:<br />
0 = No ADS-B emitter category in<strong>for</strong>mation<br />
1 = Light (< 15 500 lbs or 7 031 kg)<br />
2 = Small (15 500 to < 75 000 lbs or 7 031 to < 34 019 kg)<br />
3 = Large (75 000 to 300 000 lbs or 34 019 to 136 078 kg)<br />
4 = High vortex aircraft<br />
5 = Heavy (> 300 000 lbs or 136 078 kg)<br />
6 = High per<strong>for</strong>mance (> 5g acceleration) <strong>and</strong> high speed (> 400 kts)<br />
7 = Rotorcraft<br />
0 = No ADS-B emitter category in<strong>for</strong>mation<br />
1 = Glider/sailplane<br />
2 = Lighter-than-air<br />
3 = Parachutist/skydiver<br />
4 = Ultralight/hang-glider/paraglider<br />
5 = Reserved<br />
6 = Unmanned aerial vehicle<br />
7 = Space/Trans-atmospheric vehicle<br />
0 = No ADS-B emitter category in<strong>for</strong>mation<br />
1 = Surface vehicle — emergency vehicle<br />
2 = Surface vehicle — service vehicle<br />
3 = Fixed ground or tethered obstruction<br />
4 = Cluster obstacle<br />
5 = Line obstacle<br />
6 – 7 = Reserved<br />
Draft<br />
Set D: Reserved<br />
Aircraft identification coding (characters 1 – 8) shall be:<br />
As specified in Annex 10, Volume IV, Table 3-9.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
B-34 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table B-2-9a. BDS code 0,9 — <strong>Extended</strong> squitter airborne velocity<br />
(Subtypes 1 <strong>and</strong> 2: Velocity over ground)<br />
1 MSB 1<br />
PURPOSE: To provide additional state in<strong>for</strong>mation <strong>for</strong> both<br />
2 0<br />
normal <strong>and</strong> supersonic flight.<br />
3 FORMAT TYPE CODE = 19 0<br />
4 1 Subtype shall be coded as follows:<br />
5 LSB 1<br />
6 SUBTYPE 1 0 SUBTYPE 2 0 Code Velocity Type<br />
7 0 1 0 Reserved<br />
8 1 0 1 Ground<br />
Normal<br />
9 INTENT CHANGE FLAG (specified in §B.2.3.5.3) 2<br />
Speed Supersonic<br />
10 IFR CAPABILITY FLAG 3 Airspeed,<br />
Normal<br />
11 MSB 4<br />
Heading Supersonic<br />
12 NAVIGATION ACCURACY CATEGORY FOR VELOCITY 5 Reserved<br />
13 LSB (NACV) (specified in §B.2.3.5.5) 6 Reserved<br />
14 DIRECTION BIT <strong>for</strong> E-W Velocity: 0 = East, 1 = West 7 Reserved<br />
15 EAST — WEST VELOCITY<br />
16 NORMAL: LSB = 1 knot SUPERSONIC: LSB = 4 knots IFR capability shall be coded as follows:<br />
17<br />
18<br />
19<br />
All zeros = no velocity in<strong>for</strong>mation<br />
Value Velocity<br />
1 0 kt<br />
All zeros = no velocity in<strong>for</strong>mation<br />
Value Velocity<br />
1 0 kt<br />
0 = Transmitting aircraft has no capability <strong>for</strong> ADS-B-based<br />
conflict detection or higher level (class A1 or above)<br />
applications.<br />
20 2 1 kt 2 4 kt<br />
21<br />
22<br />
23<br />
3<br />
…<br />
1 022<br />
2 kt<br />
…<br />
1 021 kt<br />
3<br />
…<br />
1 022<br />
8 kt<br />
…<br />
4 084 kt<br />
1 = Transmitting aircraft has capability <strong>for</strong> ADS-B-based<br />
conflict detection <strong>and</strong> higher level (class A1 or above)<br />
applications.<br />
24 1 023 >1 021.5 kt 1 033 >4 086 kt<br />
25 DIRECTION BIT <strong>for</strong> N-S Velocity: 0 = North, 1 = South<br />
26 NORTH — SOUTH VELOCITY<br />
27 NORMAL: LSB = 1 knot SUPERSONIC: LSB = 4 knots<br />
28 All zeros = no velocity in<strong>for</strong>mation All zeros = no velocity in<strong>for</strong>mation<br />
29 Value Velocity Value Velocity<br />
30 1 0 kt 1 0 kt<br />
31 2 1 kt 2 4 kt<br />
32 3 2 kt 3 8 kt<br />
33 … … … …<br />
34 1 022 1 021 kt 1 022 4 084 kt<br />
35 1 023 >1 021.5 kt 1 023 >4 086 kt<br />
36 SOURCE BIT FOR VERTICAL RATE: 0 = GNSS, 1 = Baro<br />
37 SIGN BIT FOR VERTICAL RATE: 0 = Up, 1 = Down<br />
38 VERTICAL RATE<br />
39 All zeros = no vertical rate in<strong>for</strong>mation; LSB = 64 ft/min<br />
40 Value Vertical Rate<br />
41 1 0 ft/min<br />
42 2 64 ft/min<br />
43 … …<br />
44 510 32 576 ft/min<br />
45<br />
46<br />
511 >32 608 ft/min<br />
47<br />
48<br />
RESERVED<br />
49 GNSS ALT. SIGN BIT: 0 = Above baro alt., 1 = Below baro alt.<br />
50 GNSS ALT. DIFFERENCE FROM BARO. ALT.<br />
51 All zeros = no in<strong>for</strong>mation; LSB = 25 ft<br />
52 Value Difference<br />
53 1 0 ft<br />
54 2 25 ft<br />
55 126 3 125 ft<br />
56 127 > 3 137.5 ft<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix B B-35<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table B-2-9b. BDS code 0,9 — <strong>Extended</strong> squitter airborne velocity<br />
(Subtypes 3 <strong>and</strong> 4: Airspeed <strong>and</strong> heading)<br />
1 MSB 1<br />
PURPOSE: To provide additional state in<strong>for</strong>mation <strong>for</strong> both<br />
2 0<br />
normal <strong>and</strong> supersonic flight based on airspeed <strong>and</strong> heading.<br />
3 FORMAT TYPE CODE = 19 0<br />
4 1 Subtype shall be coded as follows:<br />
5 LSB 1<br />
6 SUBTYPE 3 0 SUBTYPE 4 1 Code Velocity Type<br />
7 1 0 0 Reserved<br />
8 1 0 1 Ground<br />
Normal<br />
9 INTENT CHANGE FLAG (specified in §B.2.3.5.3) 2<br />
Speed Supersonic<br />
10 IFR CAPABILITY FLAG 3 Airspeed,<br />
Normal<br />
11 MSB 4<br />
Heading Supersonic<br />
12 NAVIGATION ACCURACY CATEGORY FOR VELOCITY 5 Reserved<br />
13 LSB (NACV) (specified in §B.2.3.5.5) 6 Reserved<br />
14 STATUS BIT: 0 = Magnetic heading not available, 1 = available 7 Reserved<br />
15 MSB = 180 degrees<br />
16<br />
IFR capability shall be coded as follows:<br />
17<br />
18<br />
19<br />
20<br />
MAGNETIC HEADING<br />
(specified in §B.2.3.5.6)<br />
0 = Transmitting aircraft has no capability <strong>for</strong> ADS-B-based<br />
conflict detection or higher level (class A1 or above)<br />
applications.<br />
21<br />
22<br />
23<br />
1 = Transmitting aircraft has capability <strong>for</strong> ADS-B-based<br />
conflict detection <strong>and</strong> higher level (class A1 or above)<br />
applications.<br />
24 LSB = 360/1 024 degrees<br />
This <strong>for</strong>mat shall only be used if velocity over ground<br />
25 AIRSPEED TYPE: 0 = IAS, 1 = TAS<br />
is not available.<br />
26 AIRSPEED<br />
27 NORMAL: LSB = 1 knot SUPERSONIC: LSB = 4 knots<br />
28 All zeros = no velocity in<strong>for</strong>mation All zeros = no velocity in<strong>for</strong>mation<br />
29 Value Velocity Value Velocity<br />
30 1 0 kt 1 0 kt<br />
31 2 1 kt 2 4 kt<br />
32 3 2 kt 3 8 kt<br />
33 … … … …<br />
34 1 022 1 021 kt 1 022 4 084 kt<br />
35 1 023 >1 021.5 kt 1 023 >4 086 kt<br />
36 SOURCE BIT FOR VERTICAL RATE: 0 = GNSS, 1 = Baro<br />
37 SIGN BIT FOR VERTICAL RATE: 0 = Up, 1 = Down<br />
38 VERTICAL RATE<br />
39 All zeros = no vertical rate in<strong>for</strong>mation; LSB = 64 ft/min<br />
40 Value Vertical Rate<br />
41 1 0 ft/min<br />
42 2 64 ft/min<br />
43 … …<br />
44 510 32 576 ft/min<br />
45<br />
46<br />
511 >32 608 ft/min<br />
47<br />
48<br />
RESERVED<br />
49 DIFFERENCE SIGN BIT (0 = Above baro alt, 1 = Below baro alt.)<br />
50 GEOMETRIC HEIGHT DIFFERENCE FROM BARO. ALT.<br />
51 All zeros = no in<strong>for</strong>mation; LSB = 25 ft<br />
52 Value Difference<br />
53 1 0 ft<br />
54 2 25 ft<br />
55 126 3 125 ft<br />
56 127 >3 137.5 ft<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
B-36 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table B-2-97a. BDS code 6,1 — Aircraft status (Subtype 1: Emergency/priority status)<br />
1 MSB<br />
2<br />
3 FORMAT TYPE CODE = 28<br />
4<br />
5 LSB<br />
6 MSB<br />
7 SUBTYPE CODE = 1<br />
8 LSB<br />
9 MSB<br />
10 EMERGENCY STATE<br />
11 LSB<br />
12<br />
13<br />
14<br />
15<br />
16<br />
17<br />
18<br />
19<br />
20<br />
21<br />
22<br />
23<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29<br />
30<br />
31<br />
32<br />
33<br />
34 RESERVED<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
47<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56<br />
PURPOSE: To provide additional in<strong>for</strong>mation on aircraft status.<br />
Subtype shall be coded as follows:<br />
0 = No in<strong>for</strong>mation<br />
1 = Emergency/priority status<br />
2 = ACAS RA Broadcast<br />
3 to 7 = Reserved<br />
Emergency state shall be coded as follows:<br />
Value Meaning<br />
0 No emergency<br />
1 General emergency<br />
2 Lifeguard/Medical<br />
3 Minimum fuel<br />
4 No communications<br />
5 Unlawful interference<br />
6 Downed aircraft<br />
7 Reserved<br />
1) Message delivery shall be accomplished once per 0.8 seconds using the<br />
event-driven protocol.<br />
2) Termination of emergency state shall be detected by coding in the<br />
surveillance status field of the airborne position message.<br />
3) Subtype 2 message broadcast shall take priority over subtype 1<br />
message broadcast.<br />
4) Emergency State value 1 shall be set when <strong>Mode</strong> A code 7700 is<br />
provided to the transponder.<br />
5) Emergency State value 4 shall be set when <strong>Mode</strong> A code 7600 is<br />
provided to the transponder.<br />
6) Emergency State value 5 shall be set when <strong>Mode</strong> A code 7500 is<br />
provided to the transponder.<br />
Note.—The data in this register is not intended <strong>for</strong> extraction using<br />
GICB or ACAS cross-link protocols. The read out of this register is<br />
discouraged since the contents are indeterminate.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix B B-37<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table B-2-97b. BDS code 6,1 — Aircraft status (Subtype 2: <strong>Extended</strong> squitter ACAS RA Broadcast)<br />
1<br />
2<br />
MSB<br />
3<br />
4<br />
FORMAT TYPE CODE = 28<br />
5 LSB<br />
6 MSB<br />
7 SUBTYPE CODE = 2<br />
8 LSB<br />
9<br />
10<br />
11<br />
12<br />
13<br />
14<br />
MSB<br />
15<br />
16<br />
17<br />
18<br />
19<br />
20<br />
21<br />
ACTIVE RESOLUTION ADVISORIES<br />
22 LSB<br />
23 MSB<br />
24<br />
25<br />
RACs RECORD<br />
26 LSB<br />
27 RA TERMINATED<br />
28 MULTIPLE THREAT ENCOUNTER<br />
29 MSB THREAT — TYPE INDICATOR<br />
30 LSB<br />
31<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41<br />
42<br />
MSB<br />
43<br />
44<br />
45<br />
46<br />
47<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
THREAT IDENTITY DATA<br />
56 LSB<br />
PURPOSE: To report resolution advisories (RAs) generated by ACAS<br />
equipment.<br />
Subtype shall be coded as follows:<br />
0 = No in<strong>for</strong>mation<br />
1 = Emergency/priority status<br />
2 = ACAS RA Broadcast<br />
3 to 7 = Reserved<br />
Emergency state shall be coded as follows:<br />
The coding of bits 9 to 56 of this register shall con<strong>for</strong>m to the<br />
corresponding bits of Register 3016 as specified in Annex 10,<br />
Volume IV, §4.3.8.4.2.2.<br />
1) Message delivery shall be accomplished once per 0.8 seconds using<br />
the event-driven protocol.<br />
2) RA Broadcast shall begin within 0.5 seconds after transponder<br />
notification of the initiation of an ACAS RA.<br />
3) RA Broadcast shall be terminated 10 seconds after the RAT flag<br />
(§4.3.8.4.2.2.1.3) transitions from ZERO to ONE.<br />
4) Subtype 2 message broadcast shall take priority over subtype 1<br />
message broadcast.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
B-38 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table B-2-98. BDS Code 6,2 — Target state <strong>and</strong> status in<strong>for</strong>mation<br />
1<br />
2<br />
3<br />
4<br />
5<br />
FORMAT TYPE CODE = 29<br />
6 MSB SUBTYPE CODE = 0<br />
7 LSB<br />
8 MSB Vertical Data Available / Source Indicator<br />
9 LSB (see §B.2.3.9.3)<br />
10 Target Altitude Type (see §B.2.3.9.4)<br />
11 Backward Compatibility Flag = 0<br />
12 MSB Target Altitude Capability<br />
13 LSB (see §B.2.3.9.5)<br />
14 MSB Vertical <strong>Mode</strong> Indicator<br />
15 LSB (see §B.2.3.9.6)<br />
16<br />
17<br />
18<br />
19<br />
MSB<br />
20 Target Altitude<br />
21<br />
22<br />
23<br />
24<br />
(see §B.2.3.9.7)<br />
25 LSB<br />
26 MSB Horizontal Data Available / Source Indicator<br />
27 LSB (see §B.2.3.9.8)<br />
28<br />
29<br />
30<br />
31<br />
MSB<br />
32 Target Heading / Track Angle<br />
33<br />
34<br />
35<br />
(see §B.2.3.9.9)<br />
36 LSB<br />
37 Target Heading / Track Indicator (see §B.2.3.9.10)<br />
38 MSB Horizontal <strong>Mode</strong> Indicator (see §B.2.3.9.11)<br />
39 LSB<br />
40 MSB<br />
41 Navigation Accuracy Category — Position (NACP)<br />
42 (see §B.2.3.9.12)<br />
43 LSB<br />
44 Navigation Integrity Category — Baro (NICBARO) (see §B.2.3.9.13)<br />
45 MSB Surveillance Integrity Level (SIL)<br />
46<br />
47<br />
48<br />
LSB (see §B.2.3.9.14)<br />
49<br />
50<br />
51<br />
Reserved<br />
52 MSB Capability / <strong>Mode</strong> Codes<br />
53 LSB (see §B.2.3.9.15)<br />
54 MSB<br />
55 Emergency / Priority Status<br />
56 LSB (see §B.2.3.9.16)<br />
PURPOSE: To provide aircraft state <strong>and</strong> status in<strong>for</strong>mation.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix B B-39<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table B-2-101. BDS code 6,5 — <strong>Extended</strong> squitter aircraft operational status<br />
1<br />
2<br />
MSB<br />
3<br />
4<br />
FORMAT TYPE CODE = 31<br />
5 LSB<br />
6 MSB MSB<br />
7 SUBTYPE CODE = 0 SUBTYPE CODE = 1<br />
8 LSB LSB<br />
9<br />
10<br />
11<br />
12<br />
13<br />
MSB MSB<br />
14 AIRBORNE SURFACE<br />
15 CAPABILITY CLASS (CC) CAPABILITY CLASS (CC)<br />
16 CODES CODES<br />
17<br />
18<br />
19<br />
(see §B.2.3.10.3) (see §B.2.3.10.3)<br />
20 LSB<br />
21 MSB<br />
22 LENGTH/WIDTH CODES<br />
23 (see §B.2.3.10.11)<br />
24 LSB LSB<br />
25<br />
26<br />
27<br />
28<br />
29<br />
30<br />
31<br />
MSB<br />
32 OPERATIONAL MODE (OM) CODES<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
(see §B.2.3.10.4)<br />
40 LSB<br />
41 MSB<br />
42 VERSION NUMBER (see §B.2.3.10.5)<br />
43 LSB<br />
44 NIC SUPPLEMENT (see §B.2.3.10.6)<br />
45 MSB<br />
46 NAVIGATIONAL ACCURACY CATEGORY — POSITION<br />
47 (NACP) (see §B.2.3.10.7)<br />
48 LSB<br />
49 MSB BAQ = 0 RESERVED<br />
50 LSB (see §B.2.3.10.8)<br />
51 MSB SURVEILLANCE INTEGRITY LEVEL (SIL)<br />
52 LSB (see §B.2.3.10.9)<br />
53 NICBARO (see §B.2.3.10.10) TRK/HDG (see §B.2.3.10.12)<br />
54 HRD (see §B.2.3.10.13)<br />
55<br />
56<br />
RESERVED<br />
PURPOSE: To provide the capability class <strong>and</strong> current operational<br />
mode of ATC-related applications <strong>and</strong> other operational in<strong>for</strong>mation..<br />
Subtype Coding:<br />
0 = Airborne Status Message<br />
1 = Surface Status Message<br />
2 – 7 = Reserved<br />
1) Message delivery shall be accomplished using the event-driven<br />
protocol.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
B-40 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
B.3. CF FIELD CODE DEFINITIONS IN DF=18 ADS-B AND TIS-B MESSAGES<br />
B.3.1 INTRODUCTION<br />
Note 1.— This section defines the <strong>for</strong>mats <strong>and</strong> coding <strong>for</strong> a traffic in<strong>for</strong>mation service broadcast (TIS-B) service<br />
based on the same 112-bit 1 090 MHz signal transmission that is used <strong>for</strong> ADS-B on 1 090 MHz.<br />
Note 2.— TIS-B complements the operation of ADS-B by providing ground-to-air broadcast of surveillance data on<br />
aircraft that are not equipped <strong>for</strong> 1 090 MHz ADS-B as an aid to transition to a full ADS-B environment. The basis <strong>for</strong> this<br />
ground surveillance data may be ATC <strong>Mode</strong> S radar, a surface or approach multilateration system or a multi-sensor data<br />
processing system. The TIS-B ground-to-air transmissions use the same signal <strong>for</strong>mats as 1 090 MHz ADS-B <strong>and</strong> can<br />
there<strong>for</strong>e be accepted by a 1 090 MHz ADS-B receiver.<br />
Note 3.— TIS-B service is intended to provide a complete surveillance picture to 1 090 MHz ADS-B users during a<br />
transition period. After transition, it also provides a means to cope with a user that has lost its 1 090 MHz ADS-B<br />
capability, or is broadcasting incorrect in<strong>for</strong>mation.<br />
B.3.2 TIS-B FORMAT DEFINITION<br />
TIS-B in<strong>for</strong>mation shall be broadcast using the 112-bit <strong>Mode</strong> S DF=18 <strong>for</strong>mat as shown below in the following table.<br />
TIS-B Format Definition<br />
Bit # 1 ---- 5 6 --- 8 9 ----- 32 33 ------------------------- 88 89 ---- 112<br />
DF=18Field<br />
Names<br />
DF[5] CF[3] AA[24] ME[56] PI[24]<br />
10010<br />
MSB MSB MSB MSB MSB<br />
LSB LSB LSB LSB LSB<br />
Draft<br />
B.3.3 CONTROL FIELD ALLOCATION<br />
The content of the DF=18 transmission shall be defined by the value of the control field, as specified in the following<br />
table.<br />
CF<br />
value<br />
2<br />
3<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CF Field Code Definitions in DF=18 ADS-B <strong>and</strong> TIS-B Messages<br />
ICAO/<strong>Mode</strong> A<br />
Flag (IMF)<br />
Meaning<br />
0 Fine TIS-B message, AA field contains the 24-bit ICAO aircraft address<br />
1<br />
0<br />
1<br />
Fine TIS-B message, AA field contains the 12-bit <strong>Mode</strong> A code followed by a<br />
12-bit track file number<br />
Coarse TIS-B airborne position <strong>and</strong> velocity message, AA field contains the<br />
24-bit ICAO aircraft address<br />
Coarse TIS-B airborne position <strong>and</strong> velocity message, AA field contains the<br />
12-bit <strong>Mode</strong> A code followed by a 12-bit track file number.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix B B-41<br />
CF<br />
value<br />
ICAO/<strong>Mode</strong> A<br />
Flag (IMF)<br />
4 N/A<br />
5<br />
6<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
0<br />
1 Reserved<br />
0<br />
1<br />
Meaning<br />
Reserved <strong>for</strong> TIS-B management message AA field contains TIS-B/ADS-R<br />
management in<strong>for</strong>mation<br />
TIS-B messages that relay ADS-B Messages using anonymous 24-bit<br />
addresses<br />
ADS-B rebroadcast using the same TYPE Codes <strong>and</strong> message <strong>for</strong>mats as<br />
defined <strong>for</strong> DF=17 ADS-B messages<br />
AA field contains the 24-bit ICAO aircraft address<br />
ADS-B rebroadcast using the same TYPE Codes <strong>and</strong> message <strong>for</strong>mats as<br />
defined <strong>for</strong> DF=17 ADS-B messages<br />
AA field contains a 24-bit anonymous aircraft address<br />
B.3.4 TIS-B SURVEILLANCE MESSAGE DEFINITION<br />
B.3.4.1 TIS-B FINE AIRBORNE POSITION MESSAGE<br />
The TIS-B fine airborne position ME field shall be <strong>for</strong>matted as specified in Table B-3-1.<br />
B.3.4.1.1 ICAO/MODE A FLAG (IMF) FOR THE AIRBORNE POSITION MESSAGE<br />
This one-bit field (bit 8) shall indicate the type of identity associated with the aircraft data reported in the TIS-B message.<br />
IMF equal to ZERO (0) shall indicate that the TIS-B data is identified by an ICAO 24-bit address. IMF equal to ONE (1)<br />
shall indicate that the TIS-B data is identified by a “<strong>Mode</strong> A” code. A TIS-B report on a primary radar target shall indicate<br />
a “<strong>Mode</strong> A” code of all ZEROs.<br />
Draft<br />
Note.— The AA field is coded differently <strong>for</strong> 24-bit addresses <strong>and</strong> <strong>Mode</strong> A codes as specified in §B.3.3.<br />
B.3.4.1.2 PRESSURE-ALTITUDE<br />
This 12-bit field shall provide the aircraft pressure-altitude. This field shall contain barometric altitude encoded in 25- or<br />
100-foot increments (as indicated by the Q Bit).<br />
Note.— All zeros in this field indicate that there is no altitude data.<br />
B.3.4.1.3 COMPACT POSITION REPORTING (CPR) FORMAT (F)<br />
This field shall be set as specified in 2.3.2.1 of Appendix A.<br />
B.3.4.1.4 LATITUDE/LONGITUDE<br />
The Latitude/Longitude fields in the TIS-B fine Airborne Position Message shall be set as specified in §A.2.3.2.3.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
B-42 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
B.3.4.2 TIS-B SURFACE POSITION MESSAGE<br />
The TIS-B surface position ME field shall be <strong>for</strong>matted as specified in Table B-3-2.<br />
B.3.4.2.1 MOVEMENT<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
This field shall be set as specified in §B.2.3.3.1<br />
B.3.4.2.2 GROUND TRACK (TRUE)<br />
B.3.4.2.2.1 Ground track status<br />
This field shall be set as specified in §B.2.3.3.2.1.<br />
B.3.4.2.2.2 Ground track angle<br />
This field shall be set as specified in §B.2.3.3.2.2.<br />
B.3.4.2.3 ICAO/MODE A FLAG (IMF) FOR THE SURFACE POSITION MESSAGE<br />
This one-bit field (bit 21) shall indicate the type of identity associated with the aircraft data reported in the TIS-B<br />
message. Coding is specified in §B.3.4.1.1.<br />
B.3.4.2.4 COMPACT POSITION REPORTING (CPR) FORMAT (F)<br />
This field shall be set as specified in §A.2.3.3.3.<br />
B.3.4.2.5 LATITUDE/LONGITUDE<br />
Draft<br />
The Latitude/Longitude fields in the TIS-B fine Surface Position Message shall be set as specified in §A.2.3.3.5.<br />
B.3.4.3 IDENTIFICATION AND CATEGORY MESSAGE<br />
The TIS-B identification <strong>and</strong> category ME field shall be <strong>for</strong>matted as specified in Table B-3-3. This message shall only be<br />
used <strong>for</strong> aircraft identified with an ICAO 24-bit address.<br />
B.3.4.3.1 AIRCRAFT IDENTIFICATION CODING<br />
This field shall be set as specified in the definition of BDS 0,8.<br />
B.3.4.4 VELOCITY MESSAGE<br />
The TIS-B Velocity ME field shall be <strong>for</strong>matted as specified in Tables B-3-4a <strong>and</strong> B-3-4b.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix B B-43<br />
B.3.4.4.1 SUBTYPE FIELD<br />
Subtypes 1 <strong>and</strong> 2 shall be used <strong>for</strong> the velocity message when velocity over ground is reported. Subtypes 3 <strong>and</strong> 4 shall<br />
be used when airspeed <strong>and</strong> heading are reported.<br />
Subtype 2 (the supersonic version of the velocity coding) shall be used if either the east-west OR north-south velocities<br />
exceed 1 022 knots. A switch to subtype 1 (the normal velocity coding) shall be made if both the east-west AND northsouth<br />
velocities drop below 1 000 knots.<br />
Subtype 4 (the supersonic version of the airspeed coding) shall be used if airspeed exceeds 1 022 knots. A switch to<br />
subtype 3 (the normal airspeed coding) shall be made if the airspeed drops below 1 000 knots.<br />
B.3.4.4.2 ICAO/MODE A FLAG (IMF) FOR THE VELOCITY MESSAGE<br />
This one-bit field (bit 9) shall indicate the type of identity associated with the aircraft data reported in the TIS-B message.<br />
Coding is specified in §B.3.4.1.1.<br />
B.3.4.5 COARSE AIRBORNE POSITION MESSAGE<br />
The TIS-B coarse airborne position ME field shall be <strong>for</strong>matted as specified in Table B-3-5.<br />
Note.— This message is used if the surveillance source <strong>for</strong> TIS-B is not of high enough quality to justify the use of<br />
the fine <strong>for</strong>mats. An example of such a source is a scanning beam <strong>Mode</strong> S interrogator.<br />
B.3.4.5.1 ICAO/MODE A FLAG (IMF) FOR THE COARSE AIRBORNE POSITION MESSAGE<br />
This one-bit field (bit 1) shall indicate the type of identity associated with the aircraft data reported in the TIS-B message<br />
in §B.3.4.1.1.<br />
B.3.4.5.2 SERVICE VOLUME ID (SVID)<br />
Draft<br />
The 4-bit SVID field shall identify the TIS-B site that delivered the surveillance data.<br />
Note 1.— In the case where TIS-B messages are being received from more than one TIS-B service, the Service ID<br />
can be used to select coarse messages from a single service. This will prevent the TIS-B track from w<strong>and</strong>ering due to<br />
the different error characteristics associated with the different services.<br />
Note 2.— The SVID is defined by the service provider.<br />
B.3.4.5.3 PRESSURE-ALTITUDE<br />
This 12-bit field shall provide the aircraft pressure-altitude. This field shall contain barometric altitude encoded in 25- or<br />
100-foot increments (as indicated by the Q Bit).<br />
B.3.4.5.4 GROUND TRACK STATUS<br />
This one bit (ME bit 20) field shall define the validity of the ground track value. Coding <strong>for</strong> this field shall be as follows:<br />
0=not valid <strong>and</strong> 1=valid.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
B-44 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
B.3.4.5.5 GROUND TRACK ANGLE<br />
This 5-bit (ME bits 21-25) field shall define the direction (in degrees clockwise from true north) of aircraft motion. The<br />
ground track shall be encoded as an unsigned angular weighted binary numeral, with an MSB of 180 degrees <strong>and</strong> an<br />
LSB of 360/32 degrees, with ZERO (0) indicating true north. The data in the field shall be rounded to the nearest multiple<br />
of 360/32 degrees.<br />
B.3.4.5.6 GROUND SPEED<br />
This 6-bit (ME bits 26-31) field shall define the aircraft speed over the ground. Coding of this field shall be as specified in<br />
the following table:<br />
B.3.4.5.7 LATITUDE/LONGITUDE<br />
Coding Ground speed (GS) in knots<br />
0 No ground speed in<strong>for</strong>mation<br />
1 GS ≤ 16<br />
2 16 ≤ GS < 48<br />
3 48 < GS < 80<br />
***** *****<br />
62 1936 ≤ GS < 1968<br />
63 GS ≥ 1968<br />
The Latitude/Longitude fields in the TIS-B Coarse Airborne Position Message shall be set as specified in §A.2.3.2.3<br />
except that the 12-bit <strong>for</strong>m of CPR coding shall be used.<br />
Draft<br />
B.3.4.6 RESERVED FOR TIS-B/ADS-R MANAGEMENT MESSAGES<br />
Note.— TIS-B/ADS-R Management Messages could announce in<strong>for</strong>mation such as location <strong>and</strong> the service of the<br />
TIS-B ground station. There is no requirement <strong>for</strong> Management Messages. Format DF=18 with CF=4 has been reserved<br />
<strong>for</strong> the future use of such messages.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix B B-45<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1<br />
2<br />
MSB<br />
3 FORMAT TYPE CODE<br />
4 (see §B.2.3.1)<br />
5 LSB<br />
6 MSB SURVEILLANCE STATUS<br />
7 LSB<br />
8 IMF (see §B.3.4.1.1)<br />
9<br />
10<br />
11<br />
12<br />
MSB<br />
13<br />
14<br />
PRESSURE-ALTITUDE<br />
15 This is the altitude code (AC) as specified in §3.1.2.6.5.4<br />
16<br />
17<br />
18<br />
19<br />
of Annex 10, Volume IV, but with the M-bit removed<br />
20 LSB<br />
21 RESERVED<br />
22 CPR FORMAT (F) (see §A.2.3.2.1)<br />
23<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29<br />
MSB<br />
30<br />
31<br />
CPR ENCODED LATITUDE<br />
32<br />
(CPR airborne <strong>for</strong>mat<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
specified in §BC.2.6)<br />
39 LSB<br />
40<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
MSB<br />
47<br />
48<br />
CPR ENCODED LONGITUDE<br />
49<br />
(CPR airborne <strong>for</strong>mat<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
specified in §BC.2.6)<br />
56 LSB<br />
Table B-3-1. TIS-B fine airborne position message<br />
PURPOSE: To provide airborne position in<strong>for</strong>mation <strong>for</strong> aircraft that are<br />
not equipped with 1 090 MHz ADS-B when the TIS-B service is based on<br />
high quality surveillance data.<br />
Surveillance Status coding:<br />
0 = no condition in<strong>for</strong>mation<br />
1 = permanent alert (emergency condition)<br />
2 = temporary alert (change in <strong>Mode</strong> A identity code other than<br />
emergency condition)<br />
3 = SPI condition<br />
Codes 1 <strong>and</strong> 2 take precedence over code 3.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
B-46 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 MSB<br />
2<br />
3<br />
FORMAT TYPE CODE<br />
4<br />
(see §B.2.3.1)<br />
5 LSB<br />
6 MSB<br />
7<br />
8<br />
9<br />
MOVEMENT<br />
10<br />
(see §B.2.3.3.1)<br />
11<br />
12 LSB<br />
13 STATUS <strong>for</strong> Heading/Ground Track (1 = valid, 0 = not valid)<br />
14 MSB<br />
15<br />
16<br />
HEADING/GROUND TRACK<br />
17<br />
(Referenced to true north)<br />
18<br />
19<br />
20 LSB = 360/128 degrees<br />
21 IMF (see §B.3.4.2.3)<br />
22 CPR FORMAT (F) (see §A.2.3.3.3)<br />
23 MSB<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29<br />
30 CPR ENCODED LATITUDE<br />
31<br />
32 CPR Surface Format<br />
33 (specified in §BC.2.6)<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39 LSB<br />
40 MSB<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
47 CPR ENCODED LONGITUDE<br />
48<br />
49<br />
CPR Surface Format<br />
50<br />
(specified in §BC.2.6)<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56 LSB<br />
Table B-3-2. TIS-B fine surface position message<br />
PURPOSE: To provide surface position in<strong>for</strong>mation <strong>for</strong> aircraft that<br />
are not equipped with 1 090 MHz ADS-B.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix B B-47<br />
MSB<br />
2 FORMAT TYPE CODE<br />
3 (see §B.2.3.1)<br />
4<br />
5 LSB<br />
6 MSB<br />
7 EMITTER CATEGORY<br />
8 LSB<br />
9 MSB<br />
10<br />
11 CHARACTER 1<br />
12<br />
13<br />
14 LSB<br />
15 MSB<br />
16<br />
17 CHARACTER 2<br />
18<br />
19<br />
20 LSB<br />
21 MSB<br />
22<br />
23 CHARACTER 3<br />
24<br />
25<br />
26 LSB<br />
27 MSB<br />
28<br />
29 CHARACTER 4<br />
30<br />
31<br />
32 LSB<br />
33 MSB<br />
34<br />
35 CHARACTER 5<br />
36<br />
37<br />
38 LSB<br />
39 MSB<br />
40<br />
41 CHARACTER 6<br />
42<br />
43<br />
44 LSB<br />
45 MSB<br />
46<br />
47 CHARACTER 7<br />
48<br />
49<br />
50 LSB<br />
51 MSB<br />
52<br />
53 CHARACTER 8<br />
54<br />
55<br />
56 LSB<br />
Table B-3-3. TIS-B identification <strong>and</strong> category message<br />
PURPOSE: To provide aircraft identification <strong>and</strong> category <strong>for</strong> aircraft that are<br />
not equipped with 1 090 MHz ADS-B.<br />
Type coding:<br />
1 = Aircraft identification, category set D<br />
2 = Aircraft identification, category set C<br />
3 = Aircraft identification, category set B<br />
4 = Aircraft identification, category set A<br />
ADS-B Emitter Category coding:<br />
Set A:<br />
Set B:<br />
Set C:<br />
0 = No ADS-B emitter category in<strong>for</strong>mation<br />
1 = Light (< 15 500 lbs or 7 031 kg)<br />
2 = Small (15 500 to < 75 000 lbs or 7 031 to < 34 019 kg)<br />
3 = Large (75 000 to 300 000 lbs or 34 019 to 136 078 kg)<br />
4 = High vortex aircraft<br />
5 = Heavy (> 300 000 lbs or 136 078 kg)<br />
6 = High per<strong>for</strong>mance (> 5g acceleration) <strong>and</strong> high speed (> 400 kts)<br />
7 = Rotorcraft<br />
0 = No ADS-B emitter category in<strong>for</strong>mation<br />
1 = Glider/sailplane<br />
2 = Lighter-than-air<br />
3 = Parachutist/skydiver<br />
4 = Ultralight/hang-glider/paraglider<br />
5 = Reserved<br />
6 = Unmanned Aerial Vehicle<br />
7 = Space/Trans-atmospheric vehicle<br />
0 = No ADS-B emitter category in<strong>for</strong>mation<br />
1 = Surface vehicle — emergency vehicle<br />
2 = Surface vehicle — service vehicle<br />
3 = Fixed ground or tethered obstruction<br />
4 = Cluster obstacle<br />
5 = Line obstacle<br />
6 – 7 = Reserved<br />
Set D: Reserved<br />
Draft<br />
Aircraft identification coding:<br />
As specified in Annex 10, Volume IV, Table 3-9.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
B-48 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table B-3-4a. TIS-B velocity messages (Subtypes 1 <strong>and</strong> 2: Velocity over ground)<br />
1 MSB 1<br />
2 0<br />
3 FORMAT TYPE CODE = 19 0<br />
4 1<br />
5 LSB 1<br />
PURPOSE: To provide velocity in<strong>for</strong>mation <strong>for</strong> aircraft that are not<br />
equipped with 1 090 MHz ADS-B when the TIS-B service is based on<br />
high quality surveillance data.<br />
Subtype shall be coded as follows:<br />
6 SUBTYPE 1 0 SUBTYPE 2 0 Code Velocity Type<br />
7 0 1 0 Reserved<br />
8 1 0 1 Ground<br />
Normal<br />
9 IMF (specified in §B.3.4.4.2) 2<br />
Speed Supersonic<br />
10 MSB 3 Airspeed,<br />
Normal<br />
11 NAVIGATION ACCURACY CATEGORY FOR POSITION 4<br />
Heading Supersonic<br />
12 (NACP) (specified in §B.2.3.10.7) 5 Reserved<br />
13 LSB 6 Reserved<br />
14 DIRECTION BIT <strong>for</strong> E-W Velocity: 0 = East, 1 = West 7 Reserved<br />
15 EAST — WEST VELOCITY<br />
16 NORMAL: LSB = 1 knot SUPERSONIC: LSB = 4 knots<br />
17 All zeros = no velocity in<strong>for</strong>mation All zeros = no velocity in<strong>for</strong>mation Note 1.— The “vertical rate” <strong>and</strong> “geometric height difference<br />
18<br />
19<br />
Value<br />
1<br />
Velocity<br />
0 kt<br />
Value<br />
1<br />
Velocity<br />
0 kt<br />
from barometric altitude” fields <strong>for</strong> surface aircraft do not need to be<br />
processed by TIS-B receivers.<br />
20 2 1 kt 2 4 kt<br />
21 3 2 kt 3 8 kt<br />
22 … … … …<br />
23 1 022 1 021 kt 1 022 4 084 kt<br />
24 1 023 >1 021.5 kt 1 033 >4 086 kt<br />
25 DIRECTION BIT <strong>for</strong> N-S Velocity: 0 = North, 1 = South<br />
26 NORTH — SOUTH VELOCITY<br />
27 NORMAL: LSB = 1 knot SUPERSONIC: LSB = 4 knots<br />
28 All zeros = no velocity in<strong>for</strong>mation All zeros = no velocity in<strong>for</strong>mation<br />
29 Value Velocity Value Velocity<br />
30 1 0 kt 1 0 kt<br />
Note 2.— When bit 36 = 0, then bits 37 – 56 contain the fields<br />
31<br />
32<br />
2<br />
3<br />
1 kt<br />
2 kt<br />
2<br />
3<br />
4 kt<br />
8 kt<br />
shown in the left h<strong>and</strong> side of this page. When bit 36 = 1, then<br />
bits 37 – 56 contain the fields shown below.<br />
33 … … … …<br />
34 1 022 1 021 kt 1 022 4 084 kt<br />
35 1 023 >1 021.5 kt 1 023 >4 086 kt<br />
36 GEO FLAG (GEO = 0) 36 GEO FLAG (GEO = 1)<br />
37 SIGN BIT FOR VERTICAL RATE: 0 = Up, 1 = Down 37 SIGN BIT FOR VERTICAL RATE: 0 = Up, 1 = Down<br />
38 VERTICAL RATE 38 VERTICAL RATE<br />
39 All zeros = no vertical rate in<strong>for</strong>mation; LSB = 64 ft/min 39 All zeros = no vertical rate in<strong>for</strong>mation; LSB = 64 ft/min<br />
40 Value Vertical Rate 40 Value Vertical Rate<br />
41 1 0 ft/min 41 1 0 ft/min<br />
42 2 64 ft/min 42 2 64 ft/min<br />
43 … … 43 … …<br />
44 510 32 576 ft/min 44 510 32 576 ft/min<br />
45 511 >32 608 ft/min 45 511 >32 608 ft/min<br />
46 46<br />
47 NIC SUPPLEMENT (see §B.2.3.10.6) 47 NIC SUPPLEMENT (see §B.2.3.10.6)<br />
48 MSB 48 RESERVED<br />
49 NAVIGATION ACCURACY CATEGORY FOR VELOCITY 49 DIFFERENCE SIGN BIT: (0=above baro alt, 1=below baro alt)<br />
50 LSB (NACV) (see §B.2.3.5.5) 50 GEOMETRIC HEIGHT DIFFERENCE FROM BARO. ALT.<br />
51 MSB SURVEILLANCE INTEGRITY LEVEL 51 All zeros = no in<strong>for</strong>mation; LSB = 25 ft<br />
52 LSB (SIL) (see §B.2.3.10.9) 52 Value Difference<br />
53 53 1 0 ft<br />
54 RESERVED 54 2 25 ft<br />
55 55 126 3 125 ft<br />
56 56 127 >3 137.5 ft<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix B B-49<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table B-3-4b. TIS-B velocity messages (Subtypes 3 <strong>and</strong> 4: Air Referenced Velocity)<br />
1 MSB 1<br />
2 0<br />
3 FORMAT TYPE CODE = 19 0<br />
4 1<br />
5 LSB 1<br />
6 SUBTYPE 3 0 SUBTYPE 4 1<br />
PURPOSE: To provide velocity in<strong>for</strong>mation <strong>for</strong> aircraft that are not<br />
equipped with 1 090 MHz ADS-B when the TIS-B service is based<br />
on high quality surveillance data.<br />
Subtype shall be coded as follows:<br />
7 1 0 Code Velocity Type<br />
8 1 0 0 Reserved<br />
9<br />
10<br />
IMF (specified in §B.3.4.4.2)<br />
MSB<br />
1<br />
2<br />
GroundSpeed<br />
Normal<br />
Supersonic<br />
11<br />
12<br />
NAVIGATION ACCURACY CATEGORY FOR POSITION<br />
(NACP) (specified in §B.2.3.10.7)<br />
3<br />
4<br />
Airspeed,Heading<br />
Normal<br />
Supersonic<br />
13 LSB 5 Reserved<br />
14 HEADING STATUS BIT: 0 = Not Available, 1 = Available 6 Reserved<br />
15<br />
16<br />
17<br />
MSB = 180 degrees 7 Reserved<br />
18 HEADING<br />
Note 1.— The “vertical rate” <strong>and</strong> “geometric height difference<br />
19<br />
20<br />
21<br />
22<br />
23<br />
(specified in §B.2.3.5.6)<br />
from barometric altitude” fields <strong>for</strong> surface aircraft<br />
do not need to be processed by TIS-B receivers<br />
24 LSB = 360/1 024 degrees<br />
25 AIRSPEED TYPE: 0 = IAS, 1 = TAS<br />
26 AIRSPEED<br />
27 NORMAL: LSB = 1 knot SUPERSONIC: LSB = 4 knots<br />
28 All zeros = no velocity in<strong>for</strong>mation All zeros = no velocity in<strong>for</strong>mation<br />
29 Value Velocity Value Velocity<br />
30 1 0 kt 1 0 kt<br />
Note 2.— When bit 36 = 0, then bits 37 – 56 contain the fields<br />
31<br />
32<br />
2<br />
3<br />
1 kt<br />
2 kt<br />
2<br />
3<br />
4 kt<br />
8 kt<br />
shown in the left h<strong>and</strong> side of this page. When bit 36 = 1,<br />
then bits 37 – 56 contain the fields shown below.<br />
33 … … … …<br />
34 1 022 1 021 kt 1 022 4 084 kt<br />
35 1 023 >1 021.5 kt 1 023 >4 086 kt<br />
36 GEO FLAG (GEO = 0) 36 GEO FLAG (GEO = 1)<br />
37 SIGN BIT FOR VERTICAL RATE: 0 = Up, 1 = Down 37 SIGN BIT FOR VERTICAL RATE: 0 = Up, 1 = Down<br />
38 VERTICAL RATE 38 VERTICAL RATE<br />
39 All zeros = no vertical rate in<strong>for</strong>mation; LSB = 64 ft/min 39 All zeros = no vertical rate in<strong>for</strong>mation; LSB = 64 ft/min<br />
40 Value Vertical Rate 40 Value Vertical Rate<br />
41 1 0 ft/min 41 1 0 ft/min<br />
42 2 64 ft/min 42 2 64 ft/min<br />
43 … … 43 … …<br />
44 510 32 576 ft/min 44 510 32 576 ft/min<br />
45 511 >32 608 ft/min 45 511 >32 608 ft/min<br />
46 46<br />
47 NIC SUPPLEMENT (see §B.2.3.10.6) 47 NIC SUPPLEMENT (see §B.2.3.10.6)<br />
48 MSB 48 RESERVED<br />
49 NAVIGATIONAL ACCURACY CATEGORY FOR VELOCITY 49 DIFFERENCE SIGN BIT: (0=above baro alt, 1=below baro alt)<br />
50 LSB (NACV) (see §B.2.3.5.5) 50 GEOMETRIC HEIGHT DIFFERENCE FROM BARO. ALT.<br />
51 MSB SURVEILLANCE INTEGRITY LEVEL (SIL) 51 All zeros = no in<strong>for</strong>mation; LSB = 25 ft<br />
52 LSB (see §B.2.3.10.9) 52 Value Difference<br />
53 RESERVED 53 1 0 ft<br />
54 54 2 25 ft<br />
55 TRUE/MAGNETIC HEADING (0 = True, 1 = Magnetic) 55 126 3 125 ft<br />
56 RESERVED 56 127 >3 137.5 ft<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
B-50 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 IMF (see §B.3.4.1.1)<br />
2 MSB SURVEILLANCE STATUS<br />
3 LSB (see Annex 10, Volume IV, §3.1.2.8.6.3.1.1)<br />
4 MSB<br />
5<br />
SERVICE VOLUME ID (SVID)<br />
6<br />
(see §B.3.4.5.2)<br />
7 LSB<br />
8<br />
9<br />
10<br />
11<br />
MSB<br />
12<br />
13<br />
PRESSURE-ALTITUDE<br />
14 (This is the altitude code (AC) as specified in §3.1.2.6.5.4<br />
15<br />
16<br />
17<br />
18<br />
of Annex 10, Volume IV, but with the M-bit removed)<br />
19 LSB<br />
20 GROUND TRACK STATUS (1 = valid, 0 = invalid)<br />
21<br />
22<br />
MSB<br />
23<br />
GROUND TRACK ANGLE<br />
24<br />
(see §B.3.4.5.5)<br />
25 LSB<br />
26<br />
27<br />
MSB<br />
28<br />
GROUND SPEED<br />
29<br />
30<br />
(see §B.3.4.5.6)<br />
31 LSB<br />
32 CPR FORMAT (F) (0 = even, 1 = odd)<br />
33<br />
34<br />
35<br />
36<br />
37<br />
MSB<br />
38<br />
39<br />
CPR ENCODED LATITUDE<br />
40<br />
41<br />
42<br />
43<br />
(see §B.3.4.5.7)<br />
44 LSB<br />
45<br />
46<br />
47<br />
48<br />
49<br />
MSB<br />
50<br />
51<br />
CPR ENCODED LONGITUDE<br />
52<br />
53<br />
54<br />
55<br />
(see §B.3.4.5.7)<br />
56 LSB<br />
Table B-3-5. TIS-B coarse airborne position message<br />
PURPOSE: To provide airborne position in<strong>for</strong>mation <strong>for</strong> aircraft that are not<br />
equipped with 1 090 MHz ADS-B when the TIS-B service is based on<br />
moderate quality surveillance data.<br />
Surveillance status shall be coded as follows:<br />
0 = No condition in<strong>for</strong>mation<br />
1 = Permanent alert (emergency condition)<br />
2 = Temporary alert (change in <strong>Mode</strong> A identity code other than<br />
emergency condition)<br />
3 = SPI condition<br />
Codes 1 <strong>and</strong> 2 shall take precedence over code 3.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix B B-51<br />
B.4. ADS-B REBROADCAST (ADS-R) FORMATS AND CODING<br />
B.4.1 INTRODUCTION<br />
Notes. —<br />
1.— This section defines the <strong>for</strong>mats <strong>and</strong> coding <strong>for</strong> an ADS-B Rebroadcast (ADS-R) Service based on the same<br />
112-bit 1 090 MHz extended squitter signal transmission that is used <strong>for</strong> ADS-B messages on 1 090 MHz.<br />
2.— ADS-R complements the operation of ADS-B <strong>and</strong> TIS-B by providing ground-to-air rebroadcast of ADS-B data<br />
about aircraft that are not equipped <strong>for</strong> 1 090 MHz extended squitter ADS-B, but are equipped with an alternate <strong>for</strong>m of<br />
ADS-B (e.g. universal access transceiver (UAT)). The basis <strong>for</strong> the ADS-R transmission is the ADS-B report received at<br />
the ground station using a receiver compatible with the alternate ADS-B data link.<br />
3.— The ADS-R ground-to-air transmissions use the same signal <strong>for</strong>mats as the 1 090 MHz extended squitter ADS-<br />
B <strong>and</strong> can there<strong>for</strong>e be accepted by a 1 090 MHz ADS-B receiving subsystem, with the exceptions identified in the<br />
following sections.<br />
B.4.2 ADS-B REBROADCAST FORMAT DEFINITIONS<br />
ADS-B rebroadcast in<strong>for</strong>mation shall be transmitted using the 112-bit <strong>Mode</strong> S DF=18 <strong>for</strong>mat.<br />
B.4.3 CONTROL FIELD ALLOCATION<br />
The content of the DF=18 transmission shall be defined by the value of the control field (CF). ADS-B rebroadcast<br />
transmissions shall use CF=6.<br />
Draft<br />
B.4.4 ADS-B REBROADCAST SURVEILLANCE MESSAGE DEFINITIONS<br />
Note.— The rebroadcast of ADS-B in<strong>for</strong>mation on the 1 090 MHz extended squitter data link is accomplished by<br />
utilizing the same ADS-B message <strong>for</strong>mats defined in the tables in Section 2 of this appendix, with the exception of the<br />
need to transmit an indication to the 1 090 MHz receiving subsystem as to the type of identity associated with the aircraft<br />
data being reported in the ADS-B rebroadcast message. This identification is per<strong>for</strong>med using the ICAO/<strong>Mode</strong> A flag<br />
(IMF), which is defined in §B.3.3.1.<br />
B.4.4.1 REBROADCAST AIRBORNE POSITION MESSAGE<br />
The ME Field of the rebroadcast airborne position message shall be <strong>for</strong>matted as specified in Table A-2-5, except that<br />
ME bit 8 shall be redefined to be the ICAO/<strong>Mode</strong> A flag (IMF). This bit shall be defined as follows:<br />
IMF = 0 shall indicate that the ADS-B rebroadcast data is identified by an ICAO 24-bit address.<br />
IMF = 1 shall indicate that the ADS-B rebroadcast data is identified by an anonymous 24-bit address, or ground vehicle<br />
address, or fixed obstruction address.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
B-52 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
B.4.4.2 REBROADCAST SURFACE POSITION MESSAGE<br />
The ME field of the rebroadcast surface position message shall be <strong>for</strong>matted as specified in Table B-2-6, except that ME<br />
bit 21 is redefined to be the ICAO/<strong>Mode</strong> A flag (IMF). Coding of IMF flag shall be as specified in §B.4.4.1.<br />
B.4.4.3 REBROADCAST AIRCRAFT IDENTIFICATION AND CATEGORY MESSAGE<br />
The ME field of the rebroadcast aircraft identification <strong>and</strong> category message shall be <strong>for</strong>matted as specified in<br />
Table B-2-8.<br />
Note.— A rebroadcast aircraft identification <strong>and</strong> category message does not contain the IMF bit since aircraft using<br />
an anonymous 24-bit address will not provide identity <strong>and</strong> category in<strong>for</strong>mation.<br />
B.4.4.4 REBROADCAST AIRBORNE VELOCITY MESSAGE<br />
The ME field of the rebroadcast airborne velocity messages shall be <strong>for</strong>matted as specified in Table B-2-9a <strong>for</strong> subtype 1<br />
& 2 messages, <strong>and</strong> in Table B-2-9b <strong>for</strong> subtype 3 & 4 messages, except that ME bit 9 is redefined to be the ICAO/<strong>Mode</strong><br />
A flag (IMF). Coding of IMF flag shall be as specified in §B.4.4.1.<br />
B.4.4.5 REBROADCAST AIRCRAFT STATUS MESSAGE<br />
The ME field of the rebroadcast aircraft status message (subtype=1) shall be <strong>for</strong>matted as specified in Table B-2-97a,<br />
except that ME bit 56 is redefined to be the ICAO/<strong>Mode</strong> A flag (IMF). Coding of IMF flag shall be as specified in §B.4.4.1.<br />
B.4.4.6 RESERVED FOR THE REBROADCAST TARGET STATE AND STATUS MESSAGE<br />
B.4.4.7 REBROADCAST AIRCRAFT OPERATIONAL STATUS MESSAGE<br />
Draft<br />
The ME field of the rebroadcast aircraft operational status message shall be <strong>for</strong>matted as specified in Table B-2-101,<br />
except that ME bit 56 is redefined to be the ICAO/<strong>Mode</strong> A flag (IMF). Coding of IMF flag shall be as specified in §B.4.4.1.<br />
_____________________<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C<br />
PROVISIONS FOR EXTENDED SQUITTER VERSION 2<br />
C.1 INTRODUCTION<br />
C.1.1 INTRODUCTION<br />
Appendix C defines data <strong>for</strong>mats <strong>and</strong> protocols that shall be used <strong>for</strong> implementation of 1090 MHz extended squitter,<br />
Version Two (2).<br />
Note 1. – Appendix C is arranged in the following manner:<br />
Section C.1 Introduction<br />
Section C.2 Data <strong>for</strong>mats <strong>for</strong> transponder registers<br />
Section C.3 Traffic in<strong>for</strong>mation services – broadcast (TIS-B) <strong>for</strong>mats <strong>and</strong> coding<br />
Section C.4 ADS-B Rebroadcast (ADS-R) <strong>for</strong>mats <strong>and</strong> coding<br />
Section C.5 <strong>Provisions</strong> <strong>for</strong> Backward Compatibility with Version 0 <strong>and</strong> Version 1 ADS-B Systems<br />
Note 2. – Implementation guidelines on possible data sources, the use of control parameters, <strong>and</strong> the procotols<br />
involved is given in Appendix D.<br />
C.2 DATA FORMATS FOR TRANSPONDER REGISTERS<br />
Draft<br />
C.2.1 REGISTER ALLOCATION<br />
The register allocation shall be as specified in §A.2.1, with the exception that extended squitter registers <strong>for</strong> version 2<br />
are defined in Table C-1.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
C-2 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Notes.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Register<br />
number<br />
Table C-1. Register Allocation<br />
Assignment<br />
Maximum update<br />
interval<br />
05 16 <strong>Extended</strong> <strong>Squitter</strong> Airborne Position 0.2 s<br />
06 16 <strong>Extended</strong> <strong>Squitter</strong> Surface Position 0.2 s<br />
07 16 <strong>Extended</strong> <strong>Squitter</strong> Status 1.0 s<br />
08 16 <strong>Extended</strong> <strong>Squitter</strong> Identification <strong>and</strong> Category 15.0 s<br />
09 16 <strong>Extended</strong> <strong>Squitter</strong> Airborne Velocity 1.3 s<br />
0A 16 <strong>Extended</strong> <strong>Squitter</strong> Event-Driven In<strong>for</strong>mation variable<br />
61 16 <strong>Extended</strong> <strong>Squitter</strong> Aircraft Status 1.0 s<br />
62 16 Target State <strong>and</strong> Status In<strong>for</strong>mation 0.5 s<br />
63 16-64 16 Reserved <strong>for</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
65 16 <strong>Extended</strong> <strong>Squitter</strong> Aircraft Operational Status 2.5 s<br />
66 16-6F 16 Reserved <strong>for</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
1. The Register number is equivalent to the BDS B-Definition Subfield (BDS) value (see §2.2.14.4.20.b of<br />
RTCA DO-181D [EUROCAE ED-73C, §3.18.4.18.b]).<br />
2. Register 0A16 is not to be used <strong>for</strong> GICB or ACAS crosslink readout.<br />
3. The term “minimum update rate” is used in this Manual. The “minimum update rate” is obtained when data is<br />
loaded in one Register field once every “maximum update interval.”<br />
4. If <strong>Extended</strong> <strong>Squitter</strong> is implemented, then Register 0816 is not cleared or ZEROed once either Flight<br />
Identification or Aircraft Registration data has been loaded into the Register during the current power-on cycle.<br />
Register 0816 is not cleared since it provides in<strong>for</strong>mation that is fundamental to track file management in the ADS-B<br />
environment. Refer to §C.2.4.3.3 <strong>for</strong> implementation guidelines regarding Register 0816.<br />
5. These registers define version 2 extended squitters<br />
Draft<br />
C.2.1.1 The details of the data to be entered into the registers assigned <strong>for</strong> <strong>Extended</strong> <strong>Squitter</strong> shall be as defined in<br />
this Appendix. Table C-1 specifies the maximum update interval at which the appropriate transponder register(s)<br />
shall be reloaded with valid data. Any valid data shall be reloaded into the relevant field as soon as it becomes<br />
available at the <strong>Mode</strong> S Specific <strong>Services</strong> Entity (SSE) interface regardless of the update rate. Unless otherwise<br />
specified, if data are not available <strong>for</strong> a time no greater than twice the specified “maximum update interval,” or 2<br />
seconds (whichever is the greater), then the status bit (if provided) shall indicate that the data in that field are invalid,<br />
<strong>and</strong> the field shall be ZEROed.<br />
C.2.1.2 The register number shall be equivalent to the Comm-B data selector (BDS) value used to address that<br />
register (see §3.1.2.6.11.2.1 of Annex 10, Volume IV).<br />
C.2.2 GENERAL CONVENTIONS ON DATA FORMATS<br />
For requirements on the validity of data, see §A.2.2.1.<br />
C.2.2.1 VALIDITY OF DATA<br />
C.2.2.2 REPRESENTATION OF NUMERICAL DATA<br />
Numerical data shall be represented as specified in §A.2.2.2.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-3<br />
C.2.2.3 RESERVED FIELDS<br />
Unless specified in this Manual, these bit fields shall be reserved <strong>for</strong> future allocation by ICAO.<br />
C.2.3 EXTENDED SQUITTER FORMATS<br />
This section defines the <strong>for</strong>mats <strong>and</strong> coding that shall be used <strong>for</strong> extended squitter ADS-B messages.<br />
The convention <strong>for</strong> register numbering shall not be required <strong>for</strong> an extended squitter/non-transponder device (ES/NT,<br />
§3.1.2.8.7 of Annex 10, Volume IV). The data content <strong>and</strong> the transmit times shall be the same as specified <strong>for</strong> the<br />
transponder case.<br />
C.2.3.1 FORMAT TYPE CODES<br />
The first 5-bit (“ME” bits 1 – 5, Message bits 33 – 37) field in every <strong>Mode</strong> S <strong>Extended</strong> <strong>Squitter</strong> message shall contain<br />
the <strong>for</strong>mat TYPE Code. The <strong>for</strong>mat TYPE Code differentiates the messages into several classes: Airborne Position,<br />
Airborne Velocity, Surface Position, Identification, Aircraft Intent, Aircraft State, etc. In addition, the <strong>for</strong>mat TYPE<br />
Code encodes the Navigation Integrity Category (NIC) of the source used <strong>for</strong> the position report. The <strong>for</strong>mat TYPE<br />
Code also differentiates the Airborne Messages as to the type of their altitude measurements: barometric pressure<br />
altitude or GNSS height (HAE). The 5-bit encoding <strong>for</strong> <strong>for</strong>mat TYPE shall con<strong>for</strong>m to the definition contained in Table<br />
C-2.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
C-4 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table C-2. “TYPE” Code Subfield Definitions (DF = 17 or 18)<br />
TYPE<br />
Code<br />
Subtype<br />
Code<br />
NIC<br />
Supplement<br />
A B C<br />
Format<br />
(Message Type)<br />
Horizontal Containment Radius<br />
Limit (RC)<br />
Navigation Integrity<br />
Category (NIC)<br />
Altitude Type Notes<br />
0<br />
Not<br />
Present<br />
Not<br />
Applicable<br />
No Position In<strong>for</strong>mation<br />
(Airborne or Surface Position<br />
Messages)<br />
RC unknown NIC = 0<br />
Baro Altitude or<br />
No Altitude In<strong>for</strong>mation<br />
1, 2, 3<br />
1<br />
2<br />
3<br />
4<br />
Not<br />
Present<br />
Not<br />
Applicable<br />
Aircraft Identification <strong>and</strong> Category<br />
Message<br />
(§C.2.3.4)<br />
Not Applicable Not Applicable Not Applicable<br />
Category Set D<br />
Category Set C<br />
Category Set B<br />
Category Set A<br />
5 0 -- 0 RC < 7.5 m NIC = 11<br />
6 0 -- 0 RC < 25 m NIC = 10<br />
7<br />
Not<br />
Present<br />
1<br />
0<br />
1<br />
--<br />
--<br />
--<br />
0<br />
0<br />
1<br />
Surface Position Message<br />
(§C.2.3.3)<br />
RC < 75 m<br />
RC < 0.1 NM (185.2 m)<br />
RC < 0.2 NM (370.4 m)<br />
NIC = 9<br />
NIC = 8<br />
NIC = 7<br />
No Altitude In<strong>for</strong>mation<br />
5<br />
8<br />
1<br />
0<br />
--<br />
--<br />
0<br />
1<br />
RC < 0.3 NM (555.6 m)<br />
RC < 0.6 NM (1111.2 m)<br />
NIC = 6<br />
8<br />
0 -- 0<br />
RC > 0.6 NM (1111.2 m) or unknown NIC = 0<br />
9 0 0 -- RC < 7.5 m NIC = 11<br />
10 0 0 -- RC < 25 m NIC = 10<br />
11<br />
1<br />
0<br />
1<br />
0<br />
--<br />
--<br />
RC < 75 m<br />
RC < 0.1 NM (185.2 m)<br />
NIC = 9<br />
NIC = 8<br />
5<br />
12 0 0 -- RC < 0.2 NM (370.4 m) NIC = 7<br />
0 1 -- RC < 0.3 NM (555.6 m)<br />
13 Not<br />
Present<br />
0<br />
1<br />
0<br />
1<br />
--<br />
--<br />
Airborne Position Message<br />
(§C.2.3.2)<br />
RC < 0.5 NM (926 m)<br />
RC < 0.6 NM (1111.2 m)<br />
NIC = 6<br />
Baro Altitude<br />
7<br />
14 0 0 -- RC < 1.0 NM (1852 m) NIC = 5<br />
15 0 0 -- RC < 2 NM (3.704 km) NIC = 4<br />
16<br />
1<br />
0<br />
1<br />
0<br />
--<br />
--<br />
RC < 4 NM (7.408 km)<br />
RC < 8 NM (14.816 km)<br />
NIC = 3<br />
NIC = 2<br />
6<br />
17 0 0 -- RC < 20 NM (37.04 km) NIC = 1<br />
18<br />
0 0 --<br />
RC > 20 NM (37.04 km) or unknown NIC = 0<br />
19<br />
0<br />
1 – 4<br />
5 – 7<br />
Not<br />
Applicable<br />
Reserved<br />
Airborne Velocity Message<br />
(§C.2.3.5)<br />
Reserved<br />
Not Applicable Not Applicable<br />
Difference between<br />
“Baro Altitude” <strong>and</strong><br />
”GNSS Height (HAE)”<br />
20<br />
21<br />
22<br />
Not<br />
Present<br />
0<br />
0<br />
0<br />
0<br />
0<br />
0<br />
--<br />
--<br />
--<br />
Airborne Position Message<br />
(§C.2.3.2)<br />
RC < 7.5 m<br />
RC < 25 m<br />
RC > 25 m or unknown<br />
NIC = 11<br />
NIC = 10<br />
NIC = 0<br />
GNSS Height (HAE) 2<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-5<br />
Table C-2. “TYPE” Code Subfield Definitions (DF = 17 or 18) (Continued)<br />
TYPE Subtype NIC Format<br />
Code Code Supplement (Message Type)<br />
23<br />
0<br />
1 – 7<br />
Test Message<br />
Reserved<br />
0 Reserved<br />
24 1 Surface System Status (Allocated <strong>for</strong> National Use)<br />
2 – 7 Reserved<br />
25 –<br />
26<br />
Reserved<br />
27 Reserved <strong>for</strong> Trajectory Change Message<br />
0 Not Reserved<br />
28<br />
1<br />
2<br />
Applicable <strong>Extended</strong> <strong>Squitter</strong> Aircraft Status Message (Emergency/Priority Status <strong>and</strong> <strong>Mode</strong> A Code) (§C.2.3.7.3)<br />
<strong>Extended</strong> <strong>Squitter</strong> Aircraft Status Message (1090ES TCAS RA Broadcast Message) (§C.2.3.7.2)<br />
3 – 7 Reserved<br />
0 Target State <strong>and</strong> Status Message (ADS-B Version Number=1, defined in RTCA DO-260A, §N.3.5)<br />
29 1 Target State <strong>and</strong> Status Message (§C.2.3.9) (ADS-B Version Number=2, defined in this Manual)<br />
2 - 3 Reserved<br />
30 0 – 7 Reserved<br />
31<br />
0 – 1<br />
2 – 7<br />
Aircraft Operational Status Message (§C.2.3.10)<br />
Reserved<br />
Notes <strong>for</strong> Table C-2.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1. “Baro Altitude” means barometric pressure altitude, relative to a st<strong>and</strong>ard pressure of 1013.25 millibars (29.92 in.Hg.). It does not mean baro corrected altitude.<br />
2. TYPE codes 20 to 22 or TYPE Code 0 are to be used when valid “Baro Altitude” is not available.<br />
Draft<br />
3. After initialization, when horizontal position in<strong>for</strong>mation is not available but altitude in<strong>for</strong>mation is available, the Airborne Position Message is transmitted with a TYPE<br />
Code of ZERO in bits 1-5, the barometric pressure altitude in bits 9 – 20, <strong>and</strong> bits 22 – 56 set to ZERO (0). If neither horizontal position nor barometric altitude<br />
in<strong>for</strong>mation is available, then all 56 bits of Register 0516 are set to zero. The ZERO (0) TYPE Code field indicates that latitude <strong>and</strong> longitude in<strong>for</strong>mation is not<br />
available, while the Zero altitude field indicates that altitude in<strong>for</strong>mation is not available.<br />
4. If the position source is an ARINC 743A GNSS receiver, then the ARINC 429 data “label 130” data word from that receiver is a suitable source of in<strong>for</strong>mation <strong>for</strong> RC, the<br />
horizontal integrity containment radius. (The label 130 data word is variously called HPL (Horizontal Protection Limit) or HIL (Autonomous Horizontal Integrity Limit) in<br />
different documents.<br />
5. The “NIC Supplement-A” in the Aircraft Operational Status Message (see §C.2.3.10.6) enables the Report Assembly Function in ADS-B Receiving Subsystem to<br />
determine whether the ADS-B Transmitting Subsystem is announcing NIC=8 (RC < 0.1 NM) or NIC=9 (R C < 75 m).<br />
6. The “NIC Supplement-B” field in the Airborne Position Message (see §C.2.3.2.5), <strong>and</strong> NIC Supplement-A in the Aircraft Operational Status Message (see §C.2.3.10.6)<br />
enables the Report Assembly Function in ADS-B Receiving Subsystem to determine whether the ADS-B Transmitting Subsystem is announcing NIC=2 (RC < 8 NM) or<br />
NIC=3 (RC < 4 NM).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
C-6 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
7 The “NIC Supplement-B” field in the Airborne Position Message (see §C.2.3.2.5) <strong>and</strong> the "NIC Supplement-A" in the Aircraft Operational Status Message (see<br />
§C.2.3.10.6) enables the Report Assembly Function in ADS-B Receiving Subsystem to determine whether the ADS-B Transmitting Subsystem is announcing RC < 0.3<br />
NM, or RC < 0.5 NM or R C < 0.6 NM.<br />
8. The NIC Supplement-A field in the Aircraft Operational Status Message (see §C.2.3.10.6) together with the NIC Supplement-C field in the Surface Capability Class (CC)<br />
Code Subfield of the Aircraft Operational Status Message (see §C.2.3.10.20) enable the Report Assembly Function in ADS-B Receiving Subsystem to determine<br />
whether the ADS-B Transmitting Subsystem is announcing NIC=7 with either (RC < 0.2 NM) or NIC=6 (R C < 0.3 NM) or NIC=6 with (R C < 0.6 NM) or NIC=0 with (R C<br />
>= 0.6 NM or unknown).<br />
9. Future versions of this Manual may limit transmission of Surface Position Messages at lower NIC <strong>and</strong>/or NAC P values <strong>for</strong> Transponder-Based systems.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-7<br />
C.2.3.1.1 Airborne Position Message TYPE Code<br />
C.2.3.1.1.1 Airborne Position Message TYPE Code if Containment Radius is Available<br />
Note.— If the position in<strong>for</strong>mation comes from a GNSS receiver that con<strong>for</strong>ms to the ARINC 743A<br />
characteristic, a suitable source of in<strong>for</strong>mation <strong>for</strong> the containment radius (RC), is ARINC 429 label 130 from<br />
that GNSS receiver.<br />
If RC (containment radius) in<strong>for</strong>mation is available from the navigation data source, then the transmitting<br />
ADS-B subsystem shall determine the TYPE Code (the value of the TYPE subfield) of Airborne Position<br />
Messages as follows.<br />
a. If current valid horizontal position in<strong>for</strong>mation is not available to the ADS-B Transmitting<br />
Subsystem, then the TYPE Code subfield of Airborne Position Messages shall be set to ZERO (0).<br />
b. If valid horizontal position <strong>and</strong> barometric pressure altitude in<strong>for</strong>mation are both available to the<br />
ADS-B Transmitting Subsystem, then the ADS-B Transmitting Subsystem shall set the TYPE Code<br />
subfield of Airborne Position Messages to a value in the range from 9 to 18 in accordance with<br />
Table C-2.<br />
c. If valid horizontal position in<strong>for</strong>mation is available to the ADS-B Transmitting Subsystem, but valid<br />
barometric pressure altitude in<strong>for</strong>mation is not available, <strong>and</strong> valid geometric altitude in<strong>for</strong>mation is<br />
available, the ADS-B Transmitting Subsystem shall set the TYPE Code subfield of Airborne<br />
Position Messages to a value in the range from 20 to 22 depending on the radius of containment<br />
(RC ) in accordance with Table C-2.<br />
d. If valid horizontal position in<strong>for</strong>mation is available to the ADS-B Transmitting Subsystem, but neither<br />
valid barometric altitude in<strong>for</strong>mation nor valid geometric altitude in<strong>for</strong>mation is available, the ADS-B<br />
Transmitting Subsystem shall set the TYPE Code subfield in Airborne Position Messages to a value<br />
in the range from 9 to 18 depending on the radius of containment RC in accordance with Table C-2.<br />
(In that case, the ALTITUDE subfield of the Airborne Position Messages shall be set to all ZEROs<br />
in order to indicate that valid altitude in<strong>for</strong>mation is not available.)<br />
C.2.3.1.1.2 Airborne Position Message TYPE Code if Containment Radius is Not<br />
Available<br />
Draft<br />
If RC (radius of containment) in<strong>for</strong>mation is NOT available from the navigation data source, then the ADS-B<br />
Transmitting Subsystem shall indicate NIC=0 by selecting a TYPE Code of 0, 18, or 22 in the Airborne<br />
Position Messages, as follows:<br />
a. The ADS-B Transmitting Subsystem shall set the TYPE Code subfield to ZERO (0) if valid<br />
horizontal position in<strong>for</strong>mation is not available.<br />
b. The ADS-B Transmitting Subsystem shall set the TYPE Code subfield to 18 if valid pressure<br />
altitude in<strong>for</strong>mation is available, or if neither valid pressure altitude nor valid geometric altitude<br />
in<strong>for</strong>mation is available.<br />
If valid pressure altitude is not available, but valid geometric altitude in<strong>for</strong>mation is available, the ADS-B<br />
Transmitting Subsystem shall set the TYPE Code subfield to 22.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-8 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.2.3.1.1.3 Airborne Position Message TYPE Code During Fault Detection <strong>and</strong><br />
Exclusion Condition<br />
Under normal operating conditions, the R C can be directly determined from Horizontal Protection Limit (HPL)<br />
or Horizontal Integrity Limit (HIL) inputs to the ADS-B Transmitting Subsystem from the GPS/GNSS receiver.<br />
However, there are times when the Fault Detection <strong>and</strong> Exclusion (FDE) function of the GPS/GNSS receiver<br />
has detected a satellite failure but has not excluded the satellite from the navigation data solution. For the<br />
purposes of this Manual, the condition just described will be referred to as an “FDE Fault” which is typically<br />
annunciated by the GPS/GNSS receiver by an appropriate method. For example, ARINC 743A compliant<br />
GPS/GNSS receivers will set Label “130” bit “11” to ONE (1) to indicate the “FDE Fault.” If an “FDE Fault”<br />
does not exist, then bit “11” is set to ZERO (0). Of importance is the situation that even though an “FDE<br />
Fault” indication has been set, the GPS/GNSS typically continues to provide HPL or HIL data as well as<br />
Latitude, Longitude, <strong>and</strong> Velocity data while continuing to declare them to be valid on the interface. As the<br />
“FDE Fault” condition represents a condition where the position <strong>and</strong> accuracy data cannot be guaranteed by<br />
the GPS/GNSS receiver, the ADS-B Transmitting Subsystem shall apply the following process upon<br />
detection of the “FDE Fault” annunciation:<br />
Note 1.— If position sources can be demonstrated to overcome this degraded state of integrity when the<br />
“FDE Fault” condition occurs, then the following requirements do not apply.<br />
a. The “TYPE” Code of Airborne Position Messages shall be set to either “18” or “22,” whichever is<br />
applicable in order to indicate that RC is UNKNOWN.<br />
Note 2.— The “TYPE” Code is not required to be set to ZERO (0), as to do so would indicate that there<br />
is NO Position Data which will result in the ADS-B Transmitting Subsystem declaring an ADS-B Function<br />
Failure (see RTCA DO-260B, §2.2.11.6).<br />
b. Valid Latitude <strong>and</strong> Longitude Position data shall continue to be processed <strong>and</strong> reported in the<br />
Airborne Position Message as required.<br />
c. The NIC Supplement-B subfield in the Airborne Position Message will be set to ZERO (0) in<br />
accordance with §C.2.3.10.6 <strong>and</strong> Table C-28 <strong>for</strong> a NIC Value of ZERO (0) when “TYPE” Code is<br />
set to either “18” or “22”.<br />
d. The NIC Supplement-A subfield in the Airborne Aircraft Operational Status Message (TYPE=31,<br />
Subtype=0) shall be set to ZERO (0) in accordance with §C.2.3.10.6 <strong>and</strong> Table C-28 <strong>for</strong> a NIC<br />
Value of ZERO (0) when “TYPE” code is set to either “18” or “22.”<br />
e. The NACP subfield in the Aircraft Operational Status Message (TYPE=31, Subtype=0) shall be set<br />
to ZERO (0) in accordance with §C.2.3.9.9 <strong>and</strong> Table C-13 in order to specify that the accuracy is<br />
UNKNOWN.<br />
Draft<br />
f. The NACV subfield in the Airborne Velocity Message (TYPE=19) shall be set to ZERO (0) in<br />
accordance with §C.2.3.5.4 <strong>and</strong> Table C-5.<br />
Note 3.— Factors such as surface multi-path have been observed to cause intermittent annunciation of<br />
“FDE Faults” by the GPS/GNSS receiver. Such occurrences will result in the intermittent settings of the<br />
subfields addressed in subparagraphs “a,” “c” <strong>and</strong> “d” above. These intermittent conditions should be taken<br />
into account by ADS-B <strong>and</strong> Air Traffic <strong>Services</strong> that are using the data provided by the ADS-B Transmitting<br />
Subsystems.<br />
C.2.3.1.1.4 Broadcast of TYPE Code Equal to ZERO (0)<br />
The TYPE Code Equal to ZERO message may be required as a consequence of the following events:<br />
a. An ADS-B Airborne Position or Surface Position Message register has not been loaded with data in the<br />
last 2 seconds. In this case, the ADS-B Message register shall be cleared (i.e., all 56 bits set to ZERO)<br />
once it has timed out. Transmission of the ADS-B Message that broadcasts the contents of the register<br />
shall be terminated if the ADS-B Message register has not been loaded in 60 seconds, except that<br />
transmission termination of Surface Position Messages does not apply to Non-Transponder-Based<br />
Devices on aircraft that are on the surface, on surface vehicles, or if barometric altitude in<strong>for</strong>mation is<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-9<br />
available. Broadcast of the ADS-B Airborne Position or Surface Position Message shall resume once<br />
data has been loaded into the ADS-B Message register.<br />
b. The data management function responsible <strong>for</strong> loading the ADS-B Message registers determines that all<br />
navigation sources that can be used <strong>for</strong> the Airborne or Surface Position Message are either missing or<br />
invalid. In this case the data management function shall clear (set all data fields to ALL ZEROs) the<br />
TYPE Code <strong>and</strong> all other fields of the Airborne or Surface Position Message <strong>and</strong> insert the ZEROed<br />
message into the appropriate ADS-B Message register. This should only be done once in support of the<br />
detection of the loss of data insertion <strong>and</strong> shall result in the suppression of the broadcast of the related<br />
ADS-B Message.<br />
c. Note that in all of the cases discussed above, a TYPE Code of ZERO infers a message of ALL ZEROs.<br />
The only exception is that the Airborne Position Message <strong>for</strong>mat shall contain barometric altitude code<br />
as set by the transponder when so implemented. There is no analogous case <strong>for</strong> the other <strong>Extended</strong><br />
<strong>Squitter</strong> Message Types, since a ZERO value in any of the fields indicates that no valid in<strong>for</strong>mation is<br />
available.<br />
C.2.3.1.2 Surface Position Message TYPE Code<br />
C.2.3.1.2.1 Surface Position Message TYPE Code if Containment Radius is Available<br />
If RC (horizontal radius of containment) in<strong>for</strong>mation is available from the navigation data source, then the<br />
ADS-B Transmitting Subsystem shall use RC to determine the TYPE Code used in the Surface Position<br />
Message in accordance with Table C-2.<br />
Note.— If the position in<strong>for</strong>mation comes from a GNSS receiver that con<strong>for</strong>ms to the ARINC 743A<br />
characteristic, a suitable source of in<strong>for</strong>mation <strong>for</strong> the containment radius (RC), is ARINC 429 label 130 from<br />
that GNSS receiver.<br />
C.2.3.1.2.2 Surface Position Message TYPE Code if Radius of Containment is Not<br />
Available<br />
If RC (horizontal radius of containment) in<strong>for</strong>mation is not available from the navigation data source, then the<br />
ADS-B Transmitting Subsystem shall indicate NIC=0 by selecting a TYPE Code of 0 or 8 in the Surface<br />
Position Messages, as follows:<br />
a. The ADS-B Transmitting Subsystem shall set the TYPE Code subfield to ZERO (0) if valid<br />
horizontal position in<strong>for</strong>mation is not available.<br />
Draft<br />
b. The ADS-B Transmitting Subsystem shall set the TYPE Code subfield to 8 if valid horizontal<br />
position in<strong>for</strong>mation is available. (This TYPE Code indicates that radius of containment, RC, is<br />
either unknown or greater than or equal to 0.1 NM.)<br />
C.2.3.1.2.3 Surface Position Message TYPE Code based on Horizontal Protection Level<br />
or Estimated Horizontal Position Accuracy<br />
a. If valid horizontal position in<strong>for</strong>mation is available, then the “TYPE” Code in the Surface Position<br />
Message shall be set in the range from “5” to “8.”<br />
b. If RC (Horizontal Radius of Containment) in<strong>for</strong>mation is available from the navigation data source,<br />
the “TYPE” Code shall be selected according to the RC value, in accordance with Table C-2.<br />
c. If RC is not available from the navigation data source, then the “TYPE” Code shall be set to 8, <strong>and</strong><br />
that NIC Supplement-A <strong>and</strong> NIC Supplement-C are set to ZERO (0).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-10 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.2.3.1.2.4 Surface Position Message TYPE Code During Fault Detection <strong>and</strong><br />
Exclusion Condition<br />
Under normal operating conditions, the R C can be directly determined from Horizontal Protection Limit (HPL)<br />
or Horizontal Integrity Limit (HIL) inputs to the ADS-B Transmitting Subsystem from the GPS/GNSS receiver.<br />
However, there are times when the Fault Detection <strong>and</strong> Exclusion (FDE) function of the GPS/GNSS receiver<br />
has detected a satellite failure but has not excluded the satellite from the navigation data solution. For the<br />
purposes of this Manual, the condition just described will be referred to as an “FDE Fault” which is typically<br />
annunciated by the GPS/GNSS receiver by an appropriate method. For example, ARINC 743A compliant<br />
GPS/GNSS receivers will set Label “130” bit “11” to ONE (1) to indicate the “FDE Fault.” If an “FDE Fault”<br />
does not exist, then bit “11” is set to ZERO (0). Of importance is the situation that even though an “FDE<br />
Fault” indication has been set, the GPS/GNSS typically continues to provide HPL or HIL data as well as<br />
Latitude, Longitude, <strong>and</strong> Velocity data while continuing to declare them to be valid on the interface. As the<br />
“FDE Fault” condition represents a condition where the position <strong>and</strong> accuracy data cannot be guaranteed by<br />
the GPS/GNSS receiver, the ADS-B Transmitting Subsystem shall apply the following process upon<br />
detection of the “FDE Fault” annunciation:<br />
Note 1.— If position sources can be demonstrated to overcome this degraded state of integrity when the<br />
“FDE Fault” condition occurs, then the following requirements do not apply.<br />
a. The “TYPE” Code of Surface Position Messages shall be set to “8” in order to indicate that RC is<br />
UNKNOWN.<br />
Note 2.— The “TYPE” Code is not required to be set to ZERO (0), as to do so would indicate that there<br />
is NO Position Data which will result in the ADS-B Transmitting Subsystem declaring an ADS-B Function<br />
Failure (see RTCA DO-260B, §2.2.11.6).<br />
b. Valid Latitude <strong>and</strong> Longitude Position data shall continue to be processed <strong>and</strong> reported in the<br />
Surface Position Message as required.<br />
c. The NIC Supplement-A <strong>and</strong> NIC Supplement-C subfields in the Surface Aircraft Operational Status<br />
Message (TYPE=31, Subtype=1) shall be set to ZERO (0) in accordance with §C.2.3.10.6 <strong>and</strong><br />
Table C-28 <strong>for</strong> a NIC Value of ZERO (0) when “TYPE” Code is set to “8.”<br />
d. The NACP subfield in the Surface Aircraft Operational Status Message (TYPE=31, Subtype=1) shall<br />
be set to ZERO (0) in accordance with §C.2.3.9.9 <strong>and</strong> Table C-13 in order to specify that the<br />
accuracy is UNKNOWN.<br />
e. The NACV CC subfield in the Surface Aircraft Operational Status Message (TYPE=31, Subtype=1)<br />
shaill be set to ZERO (0) in accordance with §C.2.3.5.4 <strong>and</strong> Table C-5.<br />
Draft<br />
Note 3.— Factors such as surface multi-path have been observed to cause intermittent annunciation of<br />
“FDE Faults” by the GPS/GNSS receiver. Such occurrences will result in the intermittent settings of the<br />
subfields addressed in subparagraphs “a,” “c” <strong>and</strong> “d” above. These intermittent conditions should be taken<br />
into account by ADS-B <strong>and</strong> Air Traffic <strong>Services</strong> that are using the data provided by the ADS-B Transmitting<br />
Subsystems.<br />
C.2.3.2 AIRBORNE POSITION FORMAT<br />
The Airborne Position squitter shall be <strong>for</strong>matted as specified in the definition of Register 0516 in Figure C-1<br />
<strong>and</strong> described in the following paragraphs.<br />
C.2.3.2.1 Compact Position Reporting (CPR) Format (F)<br />
In order to achieve coding that is unambiguous world wide, CPR shall use two <strong>for</strong>mat types, known as<br />
“even” <strong>and</strong> “odd.” This one-bit field (“ME” bit 22, Message bit 54) shall be used to define the CPR Format<br />
(F) type. A CPR Format equal to ZERO (0) shall denote an “even” <strong>for</strong>mat coding, while a CPR Format equal<br />
to ONE (1) shall denote an “odd” <strong>for</strong>mat coding (§C.2.6.7).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-11<br />
C.2.3.2.2 Time Synchronization (T)<br />
This one-bit field (“ME” bit 21, Message bit 53) shall indicate whether or not the Time of Applicability of the<br />
message is synchronized with UTC time. “T” equal to ZERO (0) shall denote that the time is not<br />
synchronized to UTC. “T” equal to ONE (1) shall denote that Time of Applicability is synchronized to UTC<br />
time.<br />
When T=1, the time of validity in the Airborne Message <strong>for</strong>mat shall be encoded in the 1-bit “F” field which<br />
(in addition to CPR <strong>for</strong>mat type) shall indicate the 0.2 second time tick <strong>for</strong> UTC Time of Position Validity.<br />
The “F” bit shall alternate between 0 <strong>and</strong> 1 <strong>for</strong> successive 0.2 second time ticks, beginning with F=0 when<br />
the Time of Applicability shall be an exact even-numbered UTC second.<br />
C.2.3.2.3 CPR Encoded Latitude/Longitude<br />
The CPR Encoded Latitude/Longitude field in the Airborne Position Message shall be a 34-bit field (“ME” bits<br />
23 – 56, Message bits 55 – 88) containing the Latitude <strong>and</strong> Longitude of the Aircraft’s Airborne Position. The<br />
Latitude <strong>and</strong> Longitude shall each occupy 17 bits. The Airborne Latitude <strong>and</strong> Longitude encoding shall<br />
contain Airborne CPR-encoded values in accordance with §C.2.6. The unambiguous range <strong>for</strong> the local<br />
decoding of Airborne Messages shall be 666 km (360 NM). The positional accuracy maintained by the<br />
Airborne CPR encoding shall be approximately 5.1 meters.<br />
Notes.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1. The Latitude/Longitude encoding is also a function of the CPR <strong>for</strong>mat value (the “F” bit)<br />
described above.<br />
2. Although the positional accuracy of the airborne CPR encoding is approximately 5.1 meters in<br />
most cases, implementers should be aware that the longitude position accuracy may only be<br />
approximately 10.0 meters when the latitude is either –87.0 ±1.0 degrees, or +87 ±1.0 degrees.<br />
C.2.3.2.3.1 Extrapolating Position (When T=1)<br />
If “T” is set to one, Airborne Position Messages shall have Times of Applicability that are exact 0.2 UTC<br />
second epochs. In that case, the “F” bit shall be ZERO (0) if the Time of Applicability is an even-numbered<br />
0.2 second UTC epoch, or ONE (1) if the Time of Applicability is an odd-numbered 0.2 second epoch.<br />
Note 1.— Here, an “even-numbered 0.2 second epoch” means an epoch that occurs an even number of<br />
200-millisecond time intervals after an even-numbered UTC second. An “odd-numbered 0.2 second epoch”<br />
means an epoch that occurs an odd number of 200-millisecond time intervals after an even-numbered UTC<br />
second. Examples of even-numbered 0.2 second UTC epochs are 12.0 s, 12.4 s, 12.8 s, 13.2 s, 13.6 s, etc.<br />
Examples of odd-numbered UTC epochs are 12.2 s, 12.6 s, 13.0 s, 13.4 s, 13.8 s, etc.<br />
Draft<br />
The CPR-encoded Latitude <strong>and</strong> Longitude that are loaded into the Airborne Position register will comprise<br />
an estimate of the A/V position at the Time of Applicability of that Latitude <strong>and</strong> Longitude, which is an exact<br />
0.2 second UTC epoch. The register shall be loaded no earlier than 150 ms be<strong>for</strong>e the Time of Applicability<br />
of the data being loaded, <strong>and</strong> no later than 50 ms be<strong>for</strong>e the Time of Applicability of that data.<br />
This timing ensures that the ADS-B Receiving Subsystem may easily recover the Time of Applicability of the<br />
data in the Airborne Position Message, as follows:<br />
• If F=0, the Time of Applicability shall be the nearest even-numbered 0.2 second UTC epoch to the<br />
time that the Airborne Position Message is received.<br />
• If F=1, the Time of Applicability shall be the nearest odd-numbered 0.2 second UTC epoch to the<br />
time that the Airborne Position Message is received.<br />
Note 2.— If the Airborne Position register is loaded every 200 ms, the ideal time to load that register<br />
would be 100 ms be<strong>for</strong>e the Time of Applicability of the data being loaded. The register would then be reloaded,<br />
with data applicable at the next subsequent 0.2 second UTC epoch, 100 ms be<strong>for</strong>e that next<br />
subsequent 0.2 second epoch. That way, the time of transmission of an Airborne Position Message would<br />
never differ by more than 100 ms from the Time of Applicability of the data in that message. By specifying<br />
“100 ms ± 50 ms” rather than 100 ms exactly, some tolerance is allowed <strong>for</strong> variations in implementation.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-12 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
The position data that is loaded into the Airborne Position register shall be an estimate of the A/V position at<br />
the Time of Applicability.<br />
Note 3.— The position may be estimated by extrapolating the position from the time of validity of the fix<br />
(included in the position fix) to the Time of Applicability of the data in the register (which, if T=1, is an exact<br />
0.2 UTC time tick). This may be done by a simple linear extrapolation using the velocity provided with the<br />
position fix <strong>and</strong> the time difference between the position fix validity time <strong>and</strong> the Time of Applicability of the<br />
transmitted data. Alternatively, other methods of estimating the position, such as alpha-beta trackers or<br />
Kalman filters, may be used.<br />
Every 200 ms, the contents of the position registers shall be updated by estimating the A/V position at the<br />
next subsequent 0.2 second UTC epoch. This process shall continue with new position fixes as they<br />
become available from the source of navigation data.<br />
C.2.3.2.3.2 Extrapolating Position (When T=0)<br />
“T” shall be set to ZERO (0) if the Time of Applicability of the data being loaded into the position register is<br />
not synchronized to any particular UTC epoch. The position being transmitted must have a Time of<br />
Applicability that is no greater than 100 milliseconds from the time of transmission. Additionally, the position<br />
register shall be re-loaded with position data at intervals that are no more than 200 ms apart. This ensures<br />
that the position contained in the position registers will have a Time of Applicability that is never more than<br />
200 ms different from any time during which the register holds that data. If the transmitted position data is<br />
loaded from the position register, the position register shall be updated such that the 100 millisecond<br />
per<strong>for</strong>mance is achieved.<br />
Note.— This may be accomplished by loading the Airborne Position register at intervals that are no<br />
more than 200 ms apart, with data <strong>for</strong> which the Time of Applicability is between the time the register is<br />
loaded <strong>and</strong> the time that it is loaded again. For example, loading the register at 200 millisecond intervals<br />
would require that the time of applicability at register load time is exactly 100 milliseconds ahead of the<br />
register load time. Greater flexibility in the time of applicability at register load time is provided by increasing<br />
the update rate.<br />
If “T” is ZERO (0), then ADS-B Receiving Subsystems shall accept Airborne Position Messages as being<br />
current as of the Time of Receipt. Updating the position data as above ensures that the ADS-B Transmitting<br />
Subsystem does not induce more than 100 milliseconds of timing error into the transmitted position data.<br />
C.2.3.2.3.3 Time-Out When New Position Data is Unavailable<br />
Draft<br />
In the event that the navigation input ceases, the extrapolation described in §C.2.3.2.3.1 <strong>and</strong> §C.2.3.2.3.2<br />
shall be limited to no more than two (2) seconds. At the end of this timeout of two seconds, all fields of the<br />
Airborne Position register, except the altitude field, shall be cleared (set to ZERO).<br />
Note.— The altitude field, bits 9 to 20 of the register, would only be cleared if current altitude data were<br />
no longer available.<br />
With the appropriate register fields cleared, the broadcast of the ZERO TYPE Code field shall serve to notify<br />
ADS-B Receiving Subsystems that the data in the Latitude <strong>and</strong> Longitude fields are invalid.<br />
C.2.3.2.4 Altitude<br />
This 12-bit field (“ME” bits 9 – 20, Message bits 41 – 52) shall provide the aircraft altitude. Depending on the<br />
TYPE Code, this field shall contain either:<br />
1. Barometric altitude encoded in 25 or 100 foot increments (as indicated by the Q Bit) or,<br />
2. GNSS height above ellipsoid (HAE).<br />
Note.— GNSS altitude MSL is not accurate enough <strong>for</strong> use in the position report.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-13<br />
C.2.3.2.5 NIC Supplement-B<br />
The first 5-bit field (“ME” bits 1 – 5, Message bits 33 – 37) in every <strong>Mode</strong> S <strong>Extended</strong> <strong>Squitter</strong> Message<br />
contains the <strong>for</strong>mat TYPE Code. The <strong>for</strong>mat TYPE Code differentiates the 1090ES Messages into several<br />
classes: Airborne Position, Airborne Velocity, Surface Position, Identification <strong>and</strong> Category, Aircraft Intent,<br />
Aircraft Status, etc. In addition, the <strong>for</strong>mat TYPE Code also encodes the Navigation Integrity Category (NIC)<br />
value of the source used <strong>for</strong> the position report.<br />
The NIC Supplement-B is a 1-bit (“ME” bit 8, Message bit 40) subfield in the Airborne Position Message that<br />
is used in conjunction with the TYPE Code <strong>and</strong> NIC value to allow surveillance applications to determine<br />
whether the reported geometric position has an acceptable level of integrity containment region <strong>for</strong> the<br />
intended use. The NIC integrity containment region is described horizontally using the radius of<br />
containment, RC. The <strong>for</strong>mat TYPE Code also differentiates the Airborne Messages as to the type of their<br />
altitude measurements: barometric pressure altitude or GNSS height (HAE). The 5-bit encoding <strong>for</strong> <strong>for</strong>mat<br />
TYPE Code <strong>and</strong> related NIC values con<strong>for</strong>ms to the definition contained in Table C-28. If an update has not<br />
been received from an on-board data source <strong>for</strong> the determination of the TYPE Code value based on the<br />
radius of containment within the past 2 seconds, then the TYPE Code value shall be encoded to indicate that<br />
RC is “Unknown.”<br />
C.2.3.3 SURFACE POSITION FORMAT<br />
The Surface Position squitter shall be <strong>for</strong>matted as specified in the definition of Register 0616 in Figure C-2,<br />
<strong>and</strong> described in the following paragraphs.<br />
C.2.3.3.1 Movement<br />
This 7-bit field (“ME” bits 6 – 12, Message bits 38 – 44) shall provide in<strong>for</strong>mation on the Ground Speed of the<br />
aircraft. A non-linear scale shall be used as defined in the Table C-3, where speeds are given in km/h (kt).<br />
Table C-3. Coding of the Movement Field<br />
Coding<br />
(Decimal)<br />
Meaning Quantization<br />
0 No Movement In<strong>for</strong>mation Available<br />
1 Aircraft Stopped (Ground Speed = 0 knots)<br />
2 0 knots < Ground Speed ≤ 0.2315 km/h (0.125 kt)<br />
3 - 8 0.2315 km/h (0.125 kt) < Ground Speed ≤ 1.852 km/h (1 kt) 0.2700833 km/h steps<br />
9 - 12 1.852 km/h (1 kt) < Ground Speed ≤ 3.704 km/h (2 kt) 0.463 km /h (0.25 kt) steps<br />
13 - 38 3.704 km/h (2 kt) < Ground Speed ≤ 27.78 km/h (15 kt) 0.926 km/h (0.50 kt) steps<br />
39 - 93 27.78 km/h (15 kt) < Ground Speed ≤ 129.64 km/h (70 kt) 1.852 km/h (1.00 kt) steps<br />
94 - 108 129.64 km/h (70 kt) < Ground Speed ≤ 185.2 km/h (100 kt) 3.704 km/h (2.00 kt) steps<br />
109 - 123 185.2 km/h (100 kt) < Ground Speed ≤ 324.1 km/h (175 kt) 9.26 km/h (5.00 kt) steps<br />
124 324.1 km/h (175 kt) < Ground Speed<br />
125 Reserved <strong>for</strong> Aircraft Decelerating<br />
126 Reserved <strong>for</strong> Aircraft Accelerating<br />
127 Reserved <strong>for</strong> Aircraft Backing-Up<br />
Draft<br />
C.2.3.3.2 Heading<br />
C.2.3.3.2.1 Heading/Ground Track Status<br />
This one bit field (“ME” bit 13, Message bit 45) shall define the validity of the Heading/Ground Track value.<br />
Coding <strong>for</strong> this field shall be as follows: 0=not valid <strong>and</strong> 1= valid.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
C-14 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Note.— If a source of A/V Heading is not available to the ADS-B Transmitting Subsystem, but a source<br />
of Ground Track Angle is available, then Ground Track Angle may be used instead of Heading, provided that<br />
the STATUS BIT FOR HEADING subfield is set to ZERO (0) whenever the Ground Track Angle is not a<br />
reliable indication of the A/V’s Heading. (The Ground Track Angle is not a reliable indication of the A/V’s<br />
Heading when the A/V’s Ground Speed is low.)<br />
C.2.3.3.2.2 Heading/Ground Track Value<br />
This 7-bit field (“ME” bits 14 – 20, Message bits 46 – 52) shall define the direction (in degrees clockwise from<br />
true or magnetic north) of aircraft motion on the surface. The Heading/Ground Track shall be encoded as an<br />
unsigned Angular Weighted Binary numeral, with an MSB of 180 degrees <strong>and</strong> an LSB of 360/128 degrees,<br />
with ZERO (binary 000 0000) indicating a value of ZERO degrees. The data in the field shall be rounded to<br />
the nearest multiple of 360/128 degrees.<br />
Note.— The reference direction <strong>for</strong> Heading (whether True North or Magnetic North) is indicated in the<br />
Horizontal Reference Direction (HRD) field of the Aircraft Operational Status Message (§C.2.3.10.13).<br />
C.2.3.3.3 Compact Position Reporting (CPR) Format (F)<br />
The one-bit (“ME” bit 22, Message bit 54) CPR Format (F) field <strong>for</strong> the Surface Position Message shall be<br />
encoded as specified <strong>for</strong> the Airborne Position Message. That is, F=0 shall denote an “even” <strong>for</strong>mat coding,<br />
while F=1 shall denote an “odd” <strong>for</strong>mat coding (§C.2.6.7).<br />
C.2.3.3.4 Time Synchronization (T)<br />
This one-bit field (“ME” bit 21, Message bit 53) shall indicate whether or not the Time of Applicability of the<br />
message is synchronized with UTC time. “T” equal to ZERO (0) shall denote that the time is not<br />
synchronized to UTC. “T” equal to ONE (1) shall denote that Time of Applicability is synchronized to UTC<br />
time.<br />
When T=1, the time of validity in the Airborne Message <strong>for</strong>mat shall be encoded in the 1-bit “F” field that (in<br />
addition to CPR <strong>for</strong>mat type) shall indicate the 0.2 second time tick <strong>for</strong> UTC time of position validity. The “F”<br />
bit shall alternate between ZERO (0) <strong>and</strong> ONE (1) <strong>for</strong> successive 0.2 second time ticks, beginning with F=0<br />
when the Time of Applicability is an exact even-numbered UTC second.<br />
C.2.3.3.5 CPR Encoded Latitude/Longitude<br />
Draft<br />
The CPR Encoded Latitude/Longitude field in the Surface Position Message shall be a 34-bit field (“ME” bits<br />
23 – 56, Message bits 55 – 88) containing the Latitude <strong>and</strong> Longitude coding of the Aircraft's Surface<br />
Position. The Latitude (Y) <strong>and</strong> Longitude (X) shall each occupy 17 bits. The Surface Latitude <strong>and</strong> Longitude<br />
encoding shall contain Surface CPR-encoded values in accordance with §C.2.6. The unambiguous range<br />
<strong>for</strong> local decoding of Surface Messages shall be 166.5 km (90 NM). The positional accuracy maintained by<br />
the Surface CPR encoding shall be approximately 1.25 meters.<br />
Notes.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1. The Latitude/Longitude encoding is also a function of the CPR <strong>for</strong>mat value (the “F” bit).<br />
2. Although the positional accuracy of the surface CPR encoding is approximately 1.25 meters in<br />
most cases, implementers should be aware that the longitude position accuracy may only be<br />
approximately 3.0 meters when the latitude is either –87.0 ±1.0 degrees, or +87 ±1.0 degrees.<br />
C.2.3.3.5.1 Extrapolating Position (When T=1)<br />
This extrapolation shall con<strong>for</strong>m to §C.2.3.2.3.1 (Substitute "surface" <strong>for</strong> "airborne" where appropriate).<br />
C.2.3.3.5.2 Extrapolating Position (When T=0)<br />
This extrapolation shall con<strong>for</strong>m to §C.2.3.2.3.2 (Substitute "surface" <strong>for</strong> "airborne" where appropriate).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-15<br />
C.2.3.3.5.3 Time-Out When New Position Data is Unavailable<br />
This time-out shall con<strong>for</strong>m to §C.2.3.2.3.3 (Substitute "surface" <strong>for</strong> "airborne" where appropriate).<br />
C.2.3.4 IDENTIFICATION AND CATEGORY FORMAT<br />
The Identification <strong>and</strong> Category squitter shall be <strong>for</strong>matted as specified in the definition of Register 08 16 in<br />
Figure C-4, <strong>and</strong> described in the following paragraphs.<br />
C.2.3.4.1 Aircraft Identification Coding<br />
Note.— The coding of Aircraft Identification is defined in §2.2.19.1.13 of RTCA DO-181D (EUROCAE<br />
ED-73C, §3.23.1.13). It is reproduced here <strong>for</strong> convenience.<br />
Each character shall be coded as a six-bit subset of the ICAO 7-unit coded character set (ICAO Annex 10,<br />
Vol. IV, §3.1.2.9.1.2, Table 3-9) as specified in the Table C-4. The character set shall be transmitted with<br />
the most significant bit (MSB) first. The reported aircraft code shall begin with character 1. Characters shall<br />
be coded consecutively without leading or an intervening SPACE code. Any unused character spaces at the<br />
end of the subfield shall contain a SPACE character code.<br />
Table C-4. Aircraft Identification Character Coding<br />
b 6 0 0 1 1<br />
b 5 0 1 0 1<br />
b<br />
4<br />
0<br />
b<br />
3<br />
0<br />
b<br />
2<br />
0<br />
b<br />
1<br />
0 P SP 1 0<br />
0 0 0 1 A Q 1<br />
0 0 1 0 B R 2<br />
0 0 1 1 C S 3<br />
0 1 0 0 D T 4<br />
0 1 0 1 E U 5<br />
0 1 1 0 F V 6<br />
0 1 1 1 G W 7<br />
1 0 0 0 H X 8<br />
1 0 0 1 I Y 9<br />
1 0 1 0 J Z<br />
1 0 1 1 K<br />
1 1 0 0 L<br />
1 1 0 1 M<br />
1 1 1 0 N<br />
1 1 1 1 O<br />
Draft<br />
1 SP = SPACE code<br />
C.2.3.5 AIRBORNE VELOCITY FORMAT<br />
The Airborne Velocity squitter shall be <strong>for</strong>matted as specified in the definition of Register 0916 in Figure C-5,<br />
<strong>and</strong> described in the following paragraphs.<br />
C.2.3.5.1 Subtypes 1 <strong>and</strong> 2<br />
Subtypes 1 <strong>and</strong> 2 of the Airborne Velocity <strong>for</strong>mat shall be used when the transmitting aircraft's velocity over<br />
ground is known. Subtype 1 shall be used <strong>for</strong> velocities under 1000 knots <strong>and</strong> Subtype 2 shall be used <strong>for</strong><br />
aircraft capable of supersonic flight when the velocity might exceed 1022 knots.<br />
This message shall not be broadcast if the only valid data is the Intent Change flag (§C.2.3.5.3). After<br />
initialization, broadcast shall be suppressed by loading Register 09 16 with ALL ZEROs <strong>and</strong> then<br />
discontinuing updating the register until data input is available again.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-16 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
The supersonic version of the velocity coding shall be used if either the East-West OR North-South velocities<br />
exceed 1022 knots. A switch to the normal velocity coding shall be made if both the East-West AND North-<br />
South velocities drop below 1000 knots.<br />
C.2.3.5.2 Subtypes 3 <strong>and</strong> 4<br />
Subtypes 3 <strong>and</strong> 4 of the Airborne Velocity <strong>for</strong>mat shall be used when the transmitting aircraft's velocity over<br />
ground is not known. These Subtypes shall substitute Airspeed <strong>and</strong> Heading <strong>for</strong> the velocity over ground.<br />
Subtype 3 shall be used at subsonic velocities, while Subtype 4 shall be reserved <strong>for</strong> Airspeeds in excess of<br />
1000 knots.<br />
The Air Referenced Velocity is contained in the Airborne Velocity Subtypes 3 <strong>and</strong> 4, <strong>and</strong> the velocity<br />
in<strong>for</strong>mation is required from only certain classes of ADS-B equipped aircraft.<br />
Note.— Air Referenced Velocity Messages may be received from airborne aircraft that are also<br />
broadcasting messages containing ground referenced velocity in<strong>for</strong>mation. ADS-B Receiving Subsystems<br />
con<strong>for</strong>mant to this Manual are required to receive <strong>and</strong> process ground referenced <strong>and</strong> Air Referenced<br />
Velocity Messages from the same aircraft <strong>and</strong> output the corresponding reports. Although not required in<br />
this Manual, future versions of this Manual will specify under what conditions both ground referenced <strong>and</strong> air<br />
referenced velocity would be transmitted. This is intended to provide compatibility with anticipated future<br />
requirements <strong>for</strong> the transmission of both types of velocity in<strong>for</strong>mation.<br />
This Airborne Velocity Message shall not be broadcast if the only valid data is the Intent Change flag<br />
(§C.2.3.5.3). After initialization, broadcast shall be suppressed by loading Register 0916 with ALL ZEROs<br />
<strong>and</strong> then discontinuing updating the register until data input is available again.<br />
The supersonic version of the Velocity Message coding shall be used if the Airspeed exceeds 1022 knots. A<br />
switch to the normal velocity coding shall be made if the Airspeed drops below 1000 knots.<br />
C.2.3.5.3 Intent Change Flag in Airborne Velocity Messages<br />
An Intent Change event shall be triggered 4 seconds after the detection of new in<strong>for</strong>mation being inserted in<br />
Registers 4016 to 4216. The code shall remain set <strong>for</strong> 18 ±1 seconds following an intent change.<br />
Intent Change Flag coding:<br />
0 = no change in intent<br />
1 = intent change<br />
Notes.—<br />
Draft<br />
1. Register 43 16 is not included since it contains dynamic data that will be continuously changing.<br />
2. A four-second delay is required to provide <strong>for</strong> settling time <strong>for</strong> intent data derived from manually<br />
set devices.<br />
C.2.3.5.4 Navigation Accuracy Category <strong>for</strong> Velocity (NACV)<br />
This 3-bit (“ME” bits 11-13, Message bits 43-45) subfield shall indicate the Navigation Accuracy Category <strong>for</strong><br />
Velocity (NACV) as specified in Table C-5.<br />
The ADS-B Transmitting Subsystem shall accept, via an appropriate data interface, data from which the<br />
own-vehicle Navigation Accuracy Category <strong>for</strong> Velocity (NACV) may be determined, <strong>and</strong> it shall use such<br />
data to establish the NACV subfields in transmitted ADS-B Airborne Velocity Messages.<br />
If the external data source provides 95% accuracy figures of merit <strong>for</strong> horizontal velocity, then the ADS-B<br />
Transmitting Subsystem shall determine the value of the NAC V field in the Airborne Velocity Messages,<br />
Subtypes 1, 2, 3 <strong>and</strong> 4 according to Table C-5.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-17<br />
Table C-5. Determining NACV Based on Position Source Declared<br />
Horizontal Velocity Error<br />
Navigation Accuracy Category <strong>for</strong> Velocity<br />
Coding<br />
(Binary) (Decimal)<br />
Horizontal Velocity Error<br />
000 0 > 10 m/s<br />
001 1 < 10 m/s<br />
010 2 < 3 m/s<br />
011 3 < 1 m/s<br />
100 4 < 0.3 m/s<br />
Note.— A non-excluded satellite failure requires that the NACV parameter be set to ZERO (binary<br />
000) along with RC being set to Unknown to indicate that the velocity error is ≥10 m/s (see §C.2.3.1.1.3 <strong>and</strong><br />
§C.2.3.1.2.4).<br />
C.2.3.5.5 Heading in Airborne Velocity Messages<br />
C.2.3.5.5.1 Heading Status<br />
This one bit (“ME” bit 14, Message bit 46) subfield in Airborne Velocity Messages, Subtype 3 or 4 shall<br />
define the availability of the Heading value. Coding <strong>for</strong> this field will be: 0=not available <strong>and</strong> 1=available.<br />
C.2.3.5.5.2 Heading Value<br />
This 10-bit (“ME” bits 15 – 24, Message bits 47 – 56) subfield in Airborne Velocity Messages, Subtype 3 or 4<br />
shall give the Aircraft Heading (in degrees clockwise from true or magnetic north) when velocity over ground<br />
is not available. The Heading shall be encoded as an unsigned Angular Weighted Binary numeral with an<br />
MSB of 180 degrees <strong>and</strong> an LSB of 360/1024 degrees, with ALL ZEROs (binary 00 0000 0000) indicating a<br />
value of ZERO degrees. The data in the field shall be rounded to the nearest multiple of 360/1024 degrees.<br />
Note.— The reference direction <strong>for</strong> Heading (whether True North or Magnetic North) is indicated in<br />
the Horizontal Reference Direction (HRD) field of the Aircraft Operational Status Message (§C.2.3.10.13).<br />
C.2.3.5.6 Difference from Baro Altitude in Airborne Velocity Messages<br />
Draft<br />
This 8-bit (“ME” bits 49 – 56, Message bits 81 – 88) subfield shall give the signed difference between<br />
barometric <strong>and</strong> GNSS altitude. Coding <strong>for</strong> this field shall be as indicated in Figure C-5 <strong>and</strong> Figure C-6.<br />
If Airborne Position is being reported using Format TYPE Codes 9 or 10, only GNSS HAE shall be used.<br />
For Format TYPE Codes 9 or 10, if GNSS HAE is not available, the field shall be coded with ALL ZEROs.<br />
For Format TYPE Codes 11 through 18, either GNSS HAE or altitude MSL shall be used. The basis <strong>for</strong> the<br />
Baro Altitude difference (either GNSS HAE or altitude MSL) shall be used consistently <strong>for</strong> the reported<br />
difference.<br />
Note.— The difference between Baro Altitude <strong>and</strong> GNSS height above ellipsoid (HAE) is preferred.<br />
However, GNSS altitude (MSL) may be used when Airborne Position is being reported using Format TYPE<br />
Codes 11 through 18.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-18 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.2.3.6 AIRCRAFT STATUS REGISTER FORMAT<br />
The Aircraft Status register shall be <strong>for</strong>matted as specified in the definition of Register 07 16 in Figure C-3,<br />
<strong>and</strong> described in the following paragraphs.<br />
C.2.3.6.1 Purpose<br />
Note.— Unlike the other <strong>Extended</strong> <strong>Squitter</strong> registers, the contents of this register are not broadcast.<br />
The purpose of this register is to serve as an interface between the transponder function <strong>and</strong> the General<br />
Formatter/Manager function (GFM, §C.2.5). The two fields defined <strong>for</strong> this <strong>for</strong>mat are the Transmission Rate<br />
Subfield <strong>and</strong> the Altitude Type Subfield.<br />
C.2.3.6.2 Transmission Rate Subfield (TRS)<br />
This field shall only be used <strong>for</strong> a transponder implementation of <strong>Extended</strong> <strong>Squitter</strong>.<br />
The TRS shall be used to notify the transponder of the aircraft motion status while on the surface. If the<br />
aircraft is moving, the surface position squitter shall be broadcast at a rate of twice per second, <strong>and</strong> identity<br />
squitters at a rate of once per 5 seconds. If the aircraft is stationary, the surface position squitter shall be<br />
broadcast at a rate of once per 5 seconds <strong>and</strong> the identity squitter at a rate of once per 10 seconds.<br />
The algorithm specified in the definition of Register 0716 shall be used by the GFM (§C.2.5) to determine<br />
motion status <strong>and</strong> the appropriate code shall be set in the TRS subfield. The transponder shall examine the<br />
TRS subfield to determine which rate to use when it is broadcasting surface squitters.<br />
C.2.3.6.3 Altitude Type Subfield (ATS)<br />
This field shall only be used <strong>for</strong> a transponder implementation of <strong>Extended</strong> <strong>Squitter</strong>.<br />
Note.— The transponder normally loads the altitude field of the airborne position squitter from the<br />
same digital source as used <strong>for</strong> addressed replies. This is done to minimize the possibility that the altitude in<br />
the squitter is different from the altitude that would be obtained by direct interrogation.<br />
If the GFM (§C.2.5) inserts GNSS height (HAE) into the airborne position squitter, it shall instruct the<br />
transponder not to insert the baro altitude into the altitude field. The ATS subfield shall be used <strong>for</strong> this<br />
purpose.<br />
Draft<br />
C.2.3.7 EVENT-DRIVEN PROTOCOL<br />
A message inserted in Register 0A16 (or an equivalent transmit register) shall be broadcast once by the<br />
transponder at the earliest opportunity. Formats <strong>for</strong> messages using this protocol shall be identical to those<br />
defined <strong>for</strong> Register 6116 (see Figure C-7).<br />
Note.— The GFM (§C.2.5) is responsible <strong>for</strong> ensuring pseudo-r<strong>and</strong>om timing, priority <strong>and</strong> <strong>for</strong><br />
observing the maximum transmission rate <strong>for</strong> this register of 2 per second. Additional details are specified in<br />
§C.2.5.4 <strong>and</strong> in the following paragraphs. A summary of the transmission rates <strong>for</strong> all extended squitters is<br />
shown in Table C-35.<br />
C.2.3.7.1 Purpose<br />
Note.— The Event-Driven protocol is intended as a flexible means to support the broadcast of<br />
messages beyond those defined <strong>for</strong> position, velocity, <strong>and</strong> identification. These typically will be messages<br />
that are broadcast regularly <strong>for</strong> a period of time based on the occurrence of an event <strong>and</strong>/or having a<br />
variable broadcast rate as determined by processes external to the transponder. Two examples are: (1) the<br />
broadcast of Emergency/Priority Status at a periodic rate during a declared aircraft emergency, <strong>and</strong> (2) the<br />
broadcast of TCAS Resolution Advisory data during a declared event.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-19<br />
C.2.3.7.2 TCAS Resolution Advisory (RA) Broadcast<br />
The 1090ES TCAS RA Broadcast Message contains the same in<strong>for</strong>mation as the RA message readout<br />
using the GICB protocol, including the aircraft ICAO 24-bit Address. A ground-based 1090ES receiver with<br />
an omni-directional receiving capability can provide TCAS RA Messages to the ground systems much<br />
sooner than with a scanning beam antenna. The TCAS RA in<strong>for</strong>mation is defined as a Subtype=2 of the<br />
existing 1090ES Aircraft Status Message.<br />
The airborne aircraft broadcast rates <strong>and</strong> priorities <strong>for</strong> the TCAS RA Broadcast Message are defined below.<br />
The <strong>for</strong>mat <strong>for</strong> broadcasting a 1090ES Aircraft Status Message with TCAS RA Message content (1090ES<br />
Message TYPE=28, Subtype=2) is defined here in Figure C-8b.<br />
C.2.3.7.2.1 Transmission Rate<br />
The ADS-B Aircraft Status (TYPE=28) TCAS RA Broadcast Message (Subtype=2) shall be broadcast<br />
starting within 0.5 seconds after the transponder notification of the initiation of a TCAS Resolution Advisory.<br />
The ADS-B Aircraft Status (TYPE=28) TCAS RA Broadcast Message (Subtype=2) shall be broadcast using<br />
the Event-Driven Protocol at r<strong>and</strong>om intervals that are uni<strong>for</strong>mly distributed over the range of 0.7 to 0.9<br />
seconds <strong>for</strong> the duration of the TCAS Resolution Advisory. A summary of the transmission rates <strong>for</strong> all<br />
extended squitters is shown in Table C-35.<br />
C.2.3.7.2.2 Message Delivery<br />
ADS-B Aircraft Status TCAS RA Broadcast Message delivery is accomplished using the Event-Driven<br />
protocol. The broadcast of the TCAS RA Broadcast Message shall be terminated 24 ±1 seconds after the<br />
Resolution Advisory Termination (RAT) flag (see §4.3.8.4.2.2.1.3 of ICAO Annex 10, Volume IV) transitions<br />
from ZERO (0) to ONE (1). The broadcast of the ADS-B Aircraft Status TCAS RA Broadcast Message takes<br />
priority over the Emergency/Priority Status broadcast, <strong>and</strong> all other Event-Driven Message types, as<br />
specified in §C.2.5.4.3.<br />
C.2.3.7.3 Emergency/Priority Status <strong>and</strong> <strong>Mode</strong> A Code<br />
Register 6116 contains an exact bit-<strong>for</strong>-bit duplication of the Emergency/Priority Status in<strong>for</strong>mation that is<br />
broadcast using an Event-Driven Aircraft Status <strong>Extended</strong> <strong>Squitter</strong> Message (TYPE=28 <strong>and</strong> Subtype=1).<br />
Subtype=1 is used specifically to provide Emergency/Priority Status in<strong>for</strong>mation <strong>and</strong> the broadcast of the<br />
<strong>Mode</strong> A (4096) Code. The contents of Register 6116 shall be <strong>for</strong>matted as specified in Figure C-8a, <strong>and</strong><br />
described in the following paragraphs.<br />
Draft<br />
C.2.3.7.3.1 Transmission Rate<br />
The Aircraft Status (TYPE=28) Emergency/Priority Status ADS-B Message (Subtype=1) shall be broadcast<br />
using the Event–Driven protocol. The rate of transmission varies depending on other conditions. If the<br />
transmission of the <strong>Mode</strong> A Code is disabled, the transmission of the “Emergency/Priority Status Message”<br />
occurs only when an emergency condition is active. When the transmission of the <strong>Mode</strong> A Code is enabled,<br />
the transmission rate of the “Emergency/Priority Status Message” depends on whether the <strong>Mode</strong> A Code is<br />
changed, or if an emergency condition is active.<br />
When the <strong>Mode</strong> A Code is set to “1000,” the 1090ES Transmitting Subsystem shall disable the transmission<br />
of the <strong>Mode</strong> A Code <strong>and</strong> broadcast the “Emergency/Priority Message” in accordance with §C.2.3.7.3.1.1 only<br />
when an emergency is declared. Otherwise, the <strong>Mode</strong> A Code transmission is enabled <strong>and</strong> the broadcast<br />
rates of §C.2.3.7.3.1.2 apply. A summary of the transmission rates <strong>for</strong> all extended squitters is shown in<br />
Table C-35.<br />
Note.— The use of <strong>Mode</strong> A Code “1000” <strong>for</strong> this purpose is in accordance with the provision to<br />
disable the transmission of the <strong>Mode</strong> A Code on 1090ES. This will occur at such time that the ATC systems<br />
no longer depend on the <strong>Mode</strong> A Code to identify aircraft.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-20 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.2.3.7.3.1.1 “Emergency/Priority Status Message” Broadcast Rates When Transmission<br />
of <strong>Mode</strong> A Code is Disabled<br />
When the <strong>Mode</strong> A Code transmission is disabled as per §C.2.3.7.3.1, the following transmit rates apply:<br />
a. The “Emergency/Priority Status Message” (TYPE=28, Subtype=1) shall be broadcast at r<strong>and</strong>om<br />
intervals that are uni<strong>for</strong>mly distributed over the range of 0.7 to 0.9 seconds relative to the previous<br />
“Emergency/Priority Status” <strong>for</strong> the duration of the emergency condition which is established by any<br />
value other than ZERO in the “Emergency/Priority Status” subfield.<br />
Note.— Emergency conditions resulting from the <strong>Mode</strong> A Code being set to 7500, 7600 or<br />
7700 are covered by the requirements in §C.2.3.7.3.1.2.<br />
b. In the case where there is no emergency condition established by a ZERO value in the<br />
“Emergency/Priority Status” subfield, then the “Emergency/Priority Status Message” shall not be<br />
broadcast.<br />
C.2.3.7.3.1.2 Emergency/Priority Status Message” Broadcast Rates When Transmission<br />
of <strong>Mode</strong> A Code is Enabled<br />
When the <strong>Mode</strong> A Code transmission is enabled as per §C.2.3.7.3.1, the following transmit rates apply:<br />
a. The “Emergency/Priority Status” (TYPE=28, Subtype=1) shall be broadcast at r<strong>and</strong>om intervals that<br />
are uni<strong>for</strong>mly distributed over the range of 0.7 to 0.9 seconds relative to the previous<br />
“Emergency/Priority Status” under the following conditions:<br />
i. For a duration of 24 ±1 seconds following a <strong>Mode</strong> A Code change by the pilot except if the<br />
<strong>Mode</strong> A Code is changed to 7500, 7600 or 7700.<br />
Note.— The case where the <strong>Mode</strong> A Code is set to 7500, 7600 or 7700, the transmission<br />
of the emergency condition is covered by ”ii”. below. Setting the <strong>Mode</strong> A Code to 7500, 7600<br />
or 7700 is indicated by a Permanent Alert in the “Surveillance Status” field (value of 1) (see<br />
Figure C-1). A change in the <strong>Mode</strong> A Code, except to 7500, 7600 or 7700, is indicated by a<br />
Temporary Alert in the “Surveillance Status” subfield (value of 2) (see Figure C-1).<br />
ii. For the duration of an emergency condition by any non-ZERO value in the “Emergency/Priority<br />
Status” subfield, if the emergency code is cleared by the pilot changing the <strong>Mode</strong> A Code to<br />
other than 7500, 7600 or 7700, the broadcast of the “Emergency/Priority Status” Message shall<br />
be continued <strong>for</strong> 24 ±1 seconds as “i” above.<br />
Draft<br />
b. In the absence of conditions specified in “a” above, the “Emergency/Priority Status” Message shall<br />
be broadcast at r<strong>and</strong>om intervals that are uni<strong>for</strong>mly distributed over the range of 4.8 to 5.2 seconds<br />
relative to the previous “Emergency / Priority Status” Message.<br />
C.2.3.7.3.2 Message Delivery<br />
The Aircraft Status (TYPE=28) Emergency/Priority Status (Subtype=1) Message delivery shall be<br />
accomplished using the Event-Driven protocol (§C.2.3.7). The broadcast of this message takes priority over<br />
the Event-Driven protocol broadcasts of all other message types, except <strong>for</strong> the ADS-B Aircraft Status TCAS<br />
RA Broadcast Message (TYPE=28, Subtype=2), which takes priority over the Emergency/Priority Status<br />
broadcast, <strong>and</strong> all other Event-Driven Message types, as specified in §C.2.5.4.3.<br />
C.2.3.8 PERIODIC STATUS MESSAGES<br />
Operational Status Messages <strong>and</strong> Target State <strong>and</strong> Status Messages are Periodic Status Messages that are<br />
broadcast independently in the same manner as the Airborne Position, Surface Position, Airborne Velocity<br />
<strong>and</strong> Aircraft Identification Messages. In previous Editions of this Manual, Operational Status <strong>and</strong> Target<br />
State <strong>and</strong> Status Messages were included under the event-driven protocol <strong>and</strong> subject to the hard limit of 2<br />
transmissions per second in any second as per §C.2.5.4. Analysis is provided that verifies that the<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-21<br />
combination of Periodic Status Messages <strong>and</strong> Event-Driven Messages does not exceed 2 messages per<br />
second averaged over 60 seconds.<br />
C.2.3.9 TARGET STATE AND STATUS INFORMATION<br />
Register 62 16 contains an exact bit-<strong>for</strong>-bit duplicate of the Target State <strong>and</strong> Status <strong>Extended</strong> <strong>Squitter</strong><br />
Message (TYPE=29 <strong>and</strong> Subtype=1), <strong>and</strong> shall be <strong>for</strong>matted as specified in Figure C-9, <strong>and</strong> described in the<br />
following paragraphs.<br />
C.2.3.9.1 Transmission Rate<br />
The Target State <strong>and</strong> Status Message shall be broadcast at r<strong>and</strong>om intervals uni<strong>for</strong>mly distributed over the<br />
range of 1.2 to 1.3 seconds <strong>for</strong> the duration of the operation. A summary of the transmission rates <strong>for</strong> all<br />
extended squitters is shown in Table C-35.<br />
Note.— In previous Editions of this Manual, the Target State <strong>and</strong> Status Message was delivered<br />
using the Event-Driven protocol.<br />
C.2.3.9.2 Source Integrity Level (SIL) Supplement<br />
The “SIL Supplement” (Source Integrity Level Supplement) subfield is a 1-bit (“ME” bit 8, Message bit 40)<br />
field that defines whether the reported SIL probability is based on a “per hour” probability or a “per sample”<br />
probability as defined in Table C-6.<br />
Table C-6. “SIL Supplement” Subfield Encoding<br />
Coding Meaning<br />
0 Probability of exceeding NIC radius of containment is based on “per hour”<br />
1 Probability of exceeding NIC radius of containment is based on “per sample”<br />
► Per Hour: The probability of the reported geometric position laying outside the NIC<br />
containment radius in any given hour without an alert or an alert longer than<br />
the allowable time-to-alert.<br />
Note.— The probability of exceeding the integrity radius of containment <strong>for</strong><br />
GNSS position sources are based on a per hour basis, as the NIC will be<br />
derived from the GNSS Horizontal Protection Level (HPL) which is based on a<br />
probability of 1x10 -7 per hour.<br />
Draft<br />
► Per Sample: The probability of a reported geometric position laying outside the NIC<br />
containment radius <strong>for</strong> any given sample.<br />
Note.— The probability of exceeding the integrity radius of containment <strong>for</strong><br />
IRU, DME/DME <strong>and</strong> DME/DME/LOC position sources may be based on a per<br />
sample basis.<br />
C.2.3.9.3 Selected Altitude Type<br />
The “Selected Altitude Type” subfield is a 1-bit (“ME” bit 9, Message bit 41) field that shall be used to<br />
indicate the source of Selected Altitude data that is being used to encode “ME” bits 10 – 20 (Message bits 42<br />
– 52). Encoding of the “Selected Altitude Type” is defined in Table C-7. Whenever there is no valid MCP /<br />
FCU or FMS Selected Altitude data available, then the “Selected Altitude Type” subfield is set to ZERO (0).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-22 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Table C-7. “Selected Altitude Type” Subfield Encoding<br />
Coding Meaning<br />
Data being used to encode “ME” bits 10 – 20 is derived from the <strong>Mode</strong><br />
0<br />
Control Panel / Flight Control Unit (MCP / FCU) or equivalent equipment.<br />
Data being used to encode “ME” bits 10 – 20 is derived from the Flight<br />
1<br />
Management System (FMS).<br />
C.2.3.9.4 MCP/FCU Selected Altitude or FMS Selected Altitude<br />
a. The “MCP / FCU Selected Altitude or FMS Selected Altitude” subfield is an 11-bit (“ME” bits 10 – 20,<br />
Message bits 42 – 52) field that contains either “MCP / FCU Selected Altitude” or “FMS Selected<br />
Altitude” data in accordance with the following subparagraphs.<br />
b. Whenever valid Selected Altitude data is available from the <strong>Mode</strong> Control Panel / Flight Control Unit<br />
(MCP / FCU) or equivalent equipment, such data shall be used to encode “ME” bits 10 – 20 (Message<br />
bits 42 – 52) in accordance with Table C-8. Use of MCP / FCU Selected Altitude is then declared in the<br />
“Selected Altitude Type” subfield as specified in Table C-7.<br />
c. Whenever valid Selected Altitude data is NOT available from the <strong>Mode</strong> Control Panel / Flight Control<br />
Unit (MCP / FCU) or equivalent equipment, but valid Selected Altitude data is available from the Flight<br />
Management System (FMS), then the FMS Selected Altitude data is used to encode “ME” bits 10 – 20<br />
(Message bits 42 – 52) in accordance with Table C-8. Use of FMS Selected Altitude is then declared in<br />
the “Selected Altitude Type” subfield as specified in Table C-7.<br />
d. Encoding of Selected Altitude data in “ME” bits 10 – 20 (Message bits 42 – 52) is in accordance with<br />
Table C-8. Encoding of the data is rounded so as to preserve accuracy of the source data within ±½<br />
LSB.<br />
e. Whenever there is NO valid MCP / FCU or FMS Selected Altitude data available, then the “MCP / FCU<br />
Selected Altitude or FMS Selected Altitude” subfield (“ME” bits 10 – 20, Message bits 42 – 52) shall be<br />
set to ZERO (0) as indicated in Table C-8.<br />
Table C-8. “MCP/FCU Selected Altitude or FMS Selected Altitude” Subfield<br />
Encoding<br />
Coding<br />
(“ME” bits 10 ---- 20)<br />
Meaning<br />
(Binary) (Decimal)<br />
000 0000 0000 0 NO Data or INVALID Data<br />
000 0000 0001 1 0 feet<br />
000 0000 0010 2 32 feet<br />
000 0000 0011 3 64 feet<br />
*** **** **** *** *** **** ****<br />
*** **** **** *** *** **** ****<br />
*** **** **** *** *** **** ****<br />
111 1111 1110 2046 65440 feet<br />
111 1111 1111 2047 65472 feet<br />
Draft<br />
C.2.3.9.5 Barometric Pressure Setting (Minus 800 millibars)<br />
a. The “Barometric Pressure Setting (Minus 800 millibars)” subfield is a 9-bit (“ME” bits 21 – 29, Message<br />
bits 53 – 61) field that contains Barometric Pressure Setting data that has been adjusted by subtracting<br />
800 millibars from the data received from the Barometric Pressure Setting source.<br />
b. After adjustment by subtracting 800 millibars, the Barometric Pressure Setting is encoded in “ME” bits<br />
21 – 29 (Message bits 53 – 61) in accordance with Table C-9.<br />
c. Encoding of Barometric Pressure Setting data in “ME” bits 21 – 29 (Message bits 53 – 61) shall be<br />
rounded so as to preserve a reporting accuracy within ±½ LSB.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-23<br />
d. Whenever there is NO valid Barometric Pressure Setting data available, then the “Barometric Pressure<br />
Setting (Minus 800 millibars) subfield (“ME” bits 21 – 29, Message bits 53 – 61) shall be set to ZERO (0)<br />
as indicated in Table C-9.<br />
e. Whenever the Barometric Pressure Setting data is greater than 1208.4 or less than 800 millibars, then<br />
the “Barometric Pressure Setting (Minus 800 millibars) subfield (“ME” bits 21 – 29, Message bits 53 –<br />
61) shall be set to ZERO (0).<br />
Note.— This Barometric Pressure Setting data can be used to represent QFE or QNH/QNE,<br />
depending on local procedures. It represents the current value being used to fly the aircraft.<br />
Table C-9. “Barometric Pressure Setting (Minus 800 millibars)” Subfield<br />
Encoding<br />
Coding<br />
(“ME” bits 21 ---- 29)<br />
Meaning<br />
(Binary) (Decimal)<br />
0 0000 0000 0 NO Data or INVALID Data<br />
0 0000 0001 1 0 millibars<br />
0 0000 0010 2 0.8 millibars<br />
0 0000 0011 3 1.6 millibars<br />
* **** **** *** *** **** ****<br />
* **** **** *** *** **** ****<br />
* **** **** *** *** **** ****<br />
1 1111 1110 510 407.2 millibars<br />
1 1111 1111 511 408.0 millibars<br />
C.2.3.9.6 Selected Heading Status<br />
The “Selected Heading Status” subfield is a 1-bit (“ME” bit 30, Message bit 62) field that shall be used to<br />
indicate the status of Selected Heading data that is being used to encode “ME” bits 32 – 39 (Message bits<br />
64 – 71) in accordance with Table C-10.<br />
Coding<br />
(“ME” bit 30)<br />
0<br />
1<br />
Table C-10. “Selected Heading Status” Subfield Encoding<br />
Meaning<br />
Draft<br />
Data being used to encode “ME” bits 32 – 39 (Message bits 64 –<br />
71) is either NOT Available or is INVALID. See Table C-12.<br />
Data being used to encode “ME” bits 32 – 39 (Message bits 64 –<br />
71) is Available <strong>and</strong> is VALID. See Table C-12.<br />
C.2.3.9.7 Selected Heading Sign<br />
The “Selected Heading Sign” subfield is a 1-bit (“ME” bit 31, Message bit 63) field that shall be used to<br />
indicate the arithmetic sign of Selected Heading data that is being used to encode “ME” bits 32 – 39<br />
(Message bits 64 – 71) in accordance with Table C-11.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-24 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Coding<br />
(“ME” bit 31)<br />
0<br />
1<br />
Table C-11. “Selected Heading Sign” Subfield Encoding<br />
Meaning<br />
Data being used to encode “ME” bits 32 – 39 (Message bits 64 – 71) is<br />
Positive in an angular system having a range between +180 <strong>and</strong> –180<br />
degrees. (For an Angular Weighted Binary system which ranges from 0.0 to<br />
360 degrees, the sign bit is positive or Zero <strong>for</strong> all values that are less than<br />
180 degrees). See Table C-12.<br />
Data being used to encode “ME” bits 32 – 39 (Message bits 64 – 71) is<br />
Negative in an angular system having a range between +180 <strong>and</strong> –180<br />
degrees. (For an Angular Weighted Binary system which ranges from 0.0 to<br />
360 degrees, the sign bit is ONE <strong>for</strong> all values that are greater than 180<br />
degrees). See Table C-12.<br />
C.2.3.9.8 Selected Heading<br />
a. The “Selected Heading” subfield is an 8-bit (“ME” bits 32 – 39, Message bits 64 – 71) field that contains<br />
Selected Heading data encoded in accordance with Table C-12.<br />
b. Encoding of Selected Heading data in “ME” bits 31 – 39 (Message bits 63 – 71) shall be rounded so as<br />
to preserve accuracy of the source data within ±½ LSB.<br />
c. Whenever there is NO valid Selected Heading data available, then the Selected Heading Status, Sign,<br />
<strong>and</strong> Data subfields (“ME” bits 30 – 39, Message bits 62 – 71) shall be set to ZERO (0) as indicated in<br />
Table C-12.<br />
Table C-12. “Selected Heading Status, Sign <strong>and</strong> Data” Subfields Encoding<br />
“ME” Bit Coding<br />
30 31 32 -------- 39<br />
Meaning<br />
Status Sign Data<br />
0 0 0000 0000 NO Data or INVALID Data<br />
1 0 0000 0000 0.0 degrees<br />
1 0 0000 0001 0.703125 degrees<br />
1 0 0000 0010 1.406250 degrees<br />
* * **** **** **** **** ****<br />
* * **** **** **** **** ****<br />
* * **** **** **** **** ****<br />
1 0 1111 1111 179.296875 degrees<br />
1 1 0000 0000 180.0 or -180.0 degrees<br />
1 1 0000 0001 180.703125 or -179.296875 degrees<br />
1 1 0000 0010 181.406250 or -178.593750 degrees<br />
* * **** **** **** **** ****<br />
* * **** **** **** **** ****<br />
* * **** **** **** **** ****<br />
1 1 1000 0000 270.000 or -90.0000 degrees<br />
1 1 1000 0001 270.703125 or -89.296875 degrees<br />
1 1 1000 0010 271.406250 or -88.593750 degrees<br />
1 1 1111 1110 358.593750 or -1.4062500 degrees<br />
1 1 1111 1111 359.296875 or -0.7031250 degrees<br />
Draft<br />
C.2.3.9.9 Navigation Accuracy Category <strong>for</strong> Position (NACP)<br />
This 4-bit (“ME” bits 40 – 43, Message bits 72 – 75) subfield shall be used to indicate the Navigational<br />
Accuracy Category of the navigation in<strong>for</strong>mation used as the basis <strong>for</strong> the aircraft reported position. The<br />
NAC P subfield shall be encoded as shown in Table C-13. If an update has not been received from an onboard<br />
data source <strong>for</strong> NAC P within the past 2 seconds, then the NAC P subfield shall be encoded as a value<br />
indicating “Unknown Accuracy.”<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-25<br />
Notes.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table C-13. Encoding of Navigation Accuracy Category <strong>for</strong> Position (NACP)<br />
Coding<br />
(Binary) (Decimal)<br />
Meaning = 95% Horizontal Accuracy Bounds (EPU)<br />
0000 0 EPU ≥ 18.52 km (10 NM) - Unknown accuracy<br />
0001 1 EPU < 18.52 km (10 NM) - RNP-10 accuracy<br />
0010 2 EPU < 7.408 km (4 NM) - RNP-4 accuracy<br />
0011 3 EPU < 3.704 km (2 NM) - RNP-2 accuracy<br />
0100 4 EPU < 1852 m (1NM) - RNP-1 accuracy<br />
0101 5 EPU < 926 m (0.5 NM) - RNP-0.5 accuracy<br />
0110 6 EPU < 555.6 m ( 0.3 NM) - RNP-0.3 accuracy<br />
0111 7 EPU < 185.2 m (0.1 NM) - RNP-0.1 accuracy<br />
1000 8 EPU < 92.6 m (0.05 NM) - e.g., GPS (with SA)<br />
1001 9 EPU < 30 m - e.g., GPS (SA off)<br />
1010 10 EPU < 10 m - e.g., WAAS<br />
1011 11 EPU < 3 m - e.g., LAAS<br />
1100 -<br />
1111<br />
12 -<br />
15<br />
Reserved<br />
1. The Estimated Position Uncertainty (EPU) used in the table is a 95% accuracy bound on<br />
horizontal position. EPU is defined as the radius of a circle, centered on the reported position, such that<br />
the probability of the actual position lying outside the circle is 0.05. When reported by a GPS or GNSS<br />
system, EPU is commonly called HFOM (Horizontal Figure of Merit).<br />
2. RNP accuracy includes error sources other than sensor error, whereas horizontal error <strong>for</strong><br />
NACP only refers to horizontal position error uncertainty.<br />
3. A non-excluded satellite failure requires that the NACP parameter be set to ZERO (binary<br />
0000) along with RC being set to Unknown to indicate that the position has been determined to be<br />
invalid (see §C.2.3.1.1.3 <strong>and</strong> §C.2.3.1.2.4).<br />
C.2.3.9.10 Navigation Integrity Category <strong>for</strong> Baro (NICBARO)<br />
This 1-bit (“ME” bit 44, Message bit 76) subfield shall be used to indicate whether or not the barometric<br />
pressure altitude being reported in the Airborne Position Message (§C.2.3.2) has been cross-checked<br />
against another source of pressure altitude. The NICBARO subfield shall be encoded as shown in Table C-14.<br />
If an update has not been received from an on-board data source <strong>for</strong> NICBARO within the past 2 seconds,<br />
then the NICBARO subfield shall be encoded as a value of ZERO (0).<br />
Draft<br />
Table C-14. NICBARO Encoding<br />
Coding Meaning<br />
The barometric altitude that is being reported in the Airborne Position<br />
0 Message is based on a Gilham coded input that has not been crosschecked<br />
against another source of pressure altitude<br />
The barometric altitude that is being reported in the Airborne Position<br />
Message is either based on a Gilham code input that has been cross-<br />
1<br />
checked against another source of pressure altitude <strong>and</strong> verified as being<br />
consistent, or is based on a non-Gilham coded source<br />
Notes.—<br />
1. The barometric altitude value itself is conveyed within the ADS-B Position Message.<br />
2. The NICBARO subfield provides a method of indicating a level of data integrity <strong>for</strong> aircraft installed with<br />
Gilham encoding barometric altitude sources. Because of the potential of an undetected error when<br />
using a Gilham encoded altitude source, a comparison will be per<strong>for</strong>med with a second source <strong>and</strong> only<br />
if the two sources agree will the NICBARO subfield be set to a value of “1”. For other barometric altitude<br />
sources (Synchro or DADS) the integrity of the data is indicated with a validity flag or SSM. No<br />
additional checks or comparisons are necessary. For these sources the NICBARO subfield will be set to a<br />
value of “1” whenever the barometric altitude is valid.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-26 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
3. The use of Gilham type altimeters is strongly discouraged because of the potential <strong>for</strong> undetected<br />
altitude errors.<br />
C.2.3.9.11 Source Integrity Level (SIL)<br />
This 2-bit (“ME” bits 45 – 46, Message bits 77 – 78) subfield shall be used to define the probability of the<br />
reported horizontal position exceeding the radius of containment defined by the NIC, without alerting,<br />
assuming no avionics faults. Although the SIL assumes there are no unannunciated faults in the avionics<br />
system, the SIL must consider the effects of a faulted Signal-in-Space, if a Signal-in-Space is used by the<br />
position source. The probability of an avionics fault causing the reported horizontal position to exceed the<br />
radius of containment defined by the NIC, without alerting, is covered by the System Design Assurance<br />
(SDA) parameter (§C.2.3.10.14).<br />
The SIL probability can be defined as either “per sample” or “per hour” as defined in the SIL Supplement<br />
(SILSUPP) in §C.2.3.9.2.<br />
Notes. —<br />
1. For GNSS position sources the HIL or HPL is provided with a probability of 1x10 -7 per hour, which<br />
should be used to set the SIL to 3.<br />
2. The GPS defined HPL probability rate of 10 -7 per hour is based on the GPS constellation fault rate<br />
of 10 -4 per hour <strong>and</strong> a 10 -3 probability of missed detection, given that the fault occurs. Different<br />
containment radii indicated by the HPL are all defined at the missed detection probability of 10 -3 .<br />
3. Fault detection is an essential consideration in determining the SIL parameter. Fault detection<br />
assures, at a specified probability of missed detection, that the error is no greater than a specified<br />
limit without an alert.<br />
4. For alternate ADS-B position sources to report integrity, they will need to be certified <strong>for</strong> their fault<br />
detection characteristics.<br />
The “SIL” subfield is encoded in accordance with Table C-15. For installations where the SIL value is being<br />
dynamically updated, if an update has not been received from an on-board data source <strong>for</strong> SIL within the<br />
past 2 seconds, then the SIL subfield shall be encoded as a value of ZERO (0), indicating “Unknown.”<br />
Table C-15. Source Integrity Level (SIL) Encoding<br />
SIL Coding<br />
(Binary) (Decimal)<br />
00 0<br />
01 1<br />
Probability of Exceeding the NIC<br />
Containment Radius (RC)<br />
Unknown or > 1 x 10 -3<br />
per flight hour or per sample<br />
≤ 1 × 10 -3<br />
per flight hour or per sample<br />
≤ 1 × 10 -5<br />
per flight hour or per sample<br />
≤ 1 × 10 -7<br />
per flight hour or per sample<br />
Draft<br />
10 2<br />
11 3<br />
C.2.3.9.12 Status of MCP/FCU <strong>Mode</strong> Bits<br />
The “Status of MCP / FCU <strong>Mode</strong> Bits” subfield is a 1-bit (“ME” bit 47, Message bit 79) field that shall be used<br />
to indicate whether the mode bits (“ME” bits 48, 49, 50, <strong>and</strong> 52 <strong>and</strong> 54, Message bits 80, 81, 82, <strong>and</strong> 84, <strong>and</strong><br />
86) are actively being populated (e.g., set) in the Target State <strong>and</strong> Status Message in accordance with Table<br />
C-16.<br />
If in<strong>for</strong>mation is provided to the ADS-B Transmitting Subsystem to set either “ME” bit 48, 49, 50, or 52 or 54<br />
(Message bit 80, 81, 82, or 84 or 86) to either “0” or “1,” then bit 47 shall be set to ONE (1). Otherwise, bit<br />
47 shall be set to ZERO (0).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-27<br />
Table C-16. “Status of MCP/FCU <strong>Mode</strong> Bits” Subfield Encoding<br />
Coding<br />
(“ME” Bit 47)<br />
0<br />
1<br />
Meaning<br />
No <strong>Mode</strong> In<strong>for</strong>mation is being provided in “ME” bits 48, 49, 50,<br />
or 52 or 54 (Message bits 80, 81, 82, or 84 or 86)<br />
<strong>Mode</strong> In<strong>for</strong>mation is deliberately being provided in “ME” bits 48,<br />
49, 50, or 52, or 54 (Message bits 80, 81, 82, or 84, or 86)<br />
C.2.3.9.13 Autopilot Engaged<br />
The “Autopilot Engaged” subfield is a 1-bit (“ME” bit 48, Message bit 80) field that shall be used to indicate<br />
whether the autopilot system is engaged or not.<br />
a. The ADS-B Transmitting Subsystem shall accept in<strong>for</strong>mation from an appropriate interface that<br />
indicates whether or not the Autopilot is engaged.<br />
b. The ADS-B Transmitting Subsystem shall set “ME” bit 48 (Message bit 80) in accordance with<br />
Table C-17.<br />
Coding<br />
(“ME” Bit 48)<br />
Table C-17. “Autopilot Engaged” Subfield Encoding<br />
Meaning<br />
0 Autopilot is NOT Engaged (e.g., not actively coupled <strong>and</strong> flying the aircraft)<br />
1 Autopilot is Engaged (e.g., actively coupled <strong>and</strong> flying the aircraft)<br />
C.2.3.9.14 VNAV <strong>Mode</strong> Engaged<br />
The “VNAV <strong>Mode</strong> Engaged” subfield is a 1-bit (“ME” bit 49, Message bit 81) field that shall be used to<br />
indicate whether the Vertical Navigation <strong>Mode</strong> is active or not.<br />
a. The ADS-B Transmitting Subsystem shall accept in<strong>for</strong>mation from an appropriate interface that<br />
indicates whether or not the Vertical Navigation <strong>Mode</strong> is active.<br />
Draft<br />
b. The ADS-B Transmitting Subsystem shall set “ME” bit 49 (Message bit 81) in accordance with<br />
Table C-18.<br />
Coding<br />
(“ME” Bit 49)<br />
Table C-18. “VNAV Engaged” Subfield Encoding<br />
0 VNAV <strong>Mode</strong> is NOT Active<br />
1 VNAV <strong>Mode</strong> is Active<br />
Meaning<br />
C.2.3.9.15 Altitude Hold <strong>Mode</strong><br />
The “Altitude Hold <strong>Mode</strong>” subfield is a 1-bit (“ME” bit 50, Message bit 82) field that shall be used to indicate<br />
whether the Altitude Hold <strong>Mode</strong> is active or not.<br />
a. The ADS-B Transmitting Subsystem shall accept in<strong>for</strong>mation from an appropriate interface that<br />
indicates whether or not the Altitude Hold <strong>Mode</strong> is active.<br />
b. The ADS-B Transmitting Subsystem shall set “ME” bit 50 (Message bit 82) in accordance with<br />
Table C-19.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
C-28 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Coding<br />
(“ME” Bit 50)<br />
Table C-19. “Altitude Hold <strong>Mode</strong>” Subfield Encoding<br />
0 Altitude Hold <strong>Mode</strong> is NOT Active<br />
1 Altitude Hold <strong>Mode</strong> is Active<br />
Meaning<br />
C.2.3.9.16 Reserved <strong>for</strong> ADS-R Flag<br />
The “Reserved <strong>for</strong> ADS-R Flag” subfield in the Target State <strong>and</strong> Status Message is a 1-bit (“ME” bit 51,<br />
Message bit 83) field that shall be used to specify the rebroadcast of a 1090 MHz ADS-B Message received<br />
by a ground station on an alternate ADS-B data link, as indicated in §C.4.4.6.<br />
C.2.3.9.17 Approach <strong>Mode</strong><br />
The “Approach <strong>Mode</strong>” subfield is a 1-bit (“ME” bit 52, Message bit 84) field that shall be used to indicate<br />
whether the Approach <strong>Mode</strong> is active or not.<br />
a. The ADS-B Transmitting Subsystem shall accept in<strong>for</strong>mation from an appropriate interface that<br />
indicates whether or not the Approach <strong>Mode</strong> is active.<br />
b. The ADS-B Transmitting Subsystem shall set “ME” bit 52 (Message bit 84) in accordance with<br />
Table C-20.<br />
Coding<br />
(“ME” Bit 52)<br />
Table C-20. “Approach <strong>Mode</strong>” Subfield Encoding<br />
0 Approach <strong>Mode</strong> is NOT Active<br />
1 Approach <strong>Mode</strong> is Active<br />
Meaning<br />
C.2.3.9.18 TCAS/ACAS Operational<br />
Draft<br />
The “TCAS/ACAS Operational” subfield is a 1-bit (“ME” bit 53, Message bit 85) field that shall be used to<br />
indicate whether the TCAS/ACAS System is Operational or not.<br />
a. The ADS-B Transmitting Subsystem shall accept in<strong>for</strong>mation from an appropriate interface that<br />
indicates whether or not the TCAS/ACAS System is Operational.<br />
b. The ADS-B Transmitting Subsystem shall set “ME” bit 53 (Message bit 85) in accordance with<br />
Table C-21.<br />
Notes. —<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Coding<br />
(“ME” Bit 53)<br />
Table C-21. “TCAS/ACAS Operational” Subfield Encoding<br />
Meaning<br />
0 TCAS/ACAS System is NOT Operational (Any time RI ≠ 3 or 4)<br />
1 TCAS/ACAS System IS Operational (RI = 3 or 4)<br />
1. ADS-B does not consider TCAS Operational equal to ONE (1) unless the TCAS is in a state<br />
which can issue an RA (e.g., RI=3 or 4).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-29<br />
2. As a reference point, RTCA DO-181D (EUROCAE ED-73C) <strong>Mode</strong>-S Transponders consider<br />
that the TCAS/ACAS System is operational when “MB” bit 16 of Register 1016 is set to “ONE” (1). This<br />
occurs when the transponder / TCAS/ACAS interface is operational <strong>and</strong> the transponder is receiving<br />
TCAS/ACAS RI=2, 3 or 4. (Refer to RTCA DO-181D (EUROCAE ED-73C), Appendix B, Table B-3-16.)<br />
RI=0 is STANDBY, RI=2 is TA ONLY <strong>and</strong> RI=3 is TA/RA.<br />
C.2.3.9.19 LNAV <strong>Mode</strong> Engaged<br />
The “LNAV <strong>Mode</strong> Engaged” subfield is a 1-bit (“ME” bit 54, Message bit 86) field that is used to indicate<br />
whether the Lateral Navigation <strong>Mode</strong> is active or not.<br />
a. The ADS-B Transmitting Subsystem accepts in<strong>for</strong>mation from an appropriate interface that<br />
indicates whether or not the Lateral Navigation <strong>Mode</strong> is active.<br />
b. The ADS-B Transmitting Subsystem sets the “ME” bit 54 (Message bit 86) in accordance with<br />
Table C-22.<br />
Coding<br />
(“ME” Bit 54)<br />
Table C-22. “LNAV” <strong>Mode</strong> Engaged” Subfield Encoding<br />
Meaning<br />
0 LNAV <strong>Mode</strong> is NOT Active or Unknown<br />
1 LNAV <strong>Mode</strong> is Active<br />
C.2.3.10 AIRCRAFT OPERATIONAL STATUS MESSAGE<br />
Register 6516 contains an exact bit-<strong>for</strong>-bit duplicate of the Aircraft Operational Status Message <strong>Extended</strong><br />
<strong>Squitter</strong> (TYPE=31 <strong>and</strong> Subtype=0/1). The contents of the Aircraft Operational Status Message shall be<br />
<strong>for</strong>matted as specified Figure C-10, <strong>and</strong> described in the following paragraphs.<br />
C.2.3.10.1 Transmission Rate<br />
The rate at which the ADS-B Aircraft Operational Status Messages (TYPE=31 <strong>and</strong> Subtype=0/1) are<br />
broadcast is given <strong>for</strong> various conditions in the following subparagraphs. A summary of the transmission<br />
rates <strong>for</strong> all extended squitters is shown in Table C-35.<br />
Draft<br />
a. Airborne Aircraft Operational Status Messages (TYPE=31, Subtype=0) shall be broadcast at the rates<br />
given in the following subparagraphs when aircraft operational status in<strong>for</strong>mation is valid <strong>and</strong> when in<br />
the airborne state;<br />
(1). No Change in TCAS RA Active/NAC P/SIL/NIC SUPP Data:<br />
If there has been no change in the TCAS RA Active, NACP, SIL or NICSUPP in<strong>for</strong>mation provided in<br />
the Airborne Aircraft Operational Status Message (TYPE=31, Subtype=0), then the messages shall<br />
be broadcast at r<strong>and</strong>om intervals that are uni<strong>for</strong>mly distributed over the range of 2.4 to 2.6 seconds<br />
relative to the previous Airborne Aircraft Operational Status Message <strong>for</strong> as long as data is<br />
available to satisfy the requirements of subparagraph “a.” above.<br />
(2). Change in TCAS RA Active/NAC P/SIL/NIC SUPP Data with Target State <strong>and</strong> Status:<br />
If there has been a change in the TCAS RA Active, NAC P, SIL or NIC SUPP in<strong>for</strong>mation provided in<br />
the Airborne Aircraft Operational Status Message (TYPE=31, Subtype=0), <strong>and</strong> Target State <strong>and</strong><br />
Status Messages are being broadcast, then the Airborne Aircraft Operational Status Messages<br />
(TYPE=31, Subtype=0) shall be broadcast at r<strong>and</strong>om intervals that are uni<strong>for</strong>mly distributed over<br />
the range of 2.4 to 2.6 seconds relative to the previous Airborne Aircraft Operational Status<br />
Message <strong>for</strong> as long as data is available to satisfy the requirements of subparagraph “a.” above.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-30 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
(3). Change in TCAS RA Active/NAC P/SIL/NIC SUPP Data with No Target State <strong>and</strong> Status:<br />
If there has been a change in the TCAS RA Active, NAC P, SIL or NIC SUPP in<strong>for</strong>mation provided in<br />
the Airborne Aircraft Operational Status Message (TYPE=31, Subtype=0), <strong>and</strong> Target State <strong>and</strong><br />
Status Messages are NOT being broadcast, then the Airborne Aircraft Operational Status<br />
Messages (TYPE=31, Subtype=0) shall be broadcast at r<strong>and</strong>om intervals that are uni<strong>for</strong>mly<br />
distributed over the range of 0.7 to 0.9 seconds relative to the previous Airborne Aircraft<br />
Operational Status Message <strong>for</strong> a period of 24 ±1 seconds.<br />
b. Surface Aircraft Operational Status Messages (TYPE=31, Subtype=1) shall be broadcast at the rates<br />
given in the following subparagraphs when aircraft operational status in<strong>for</strong>mation is valid <strong>and</strong> when in<br />
the ON-Ground state;<br />
(1). Aircraft/Vehicle Not Moving:<br />
If the aircraft/vehicle is on-ground <strong>and</strong> NOT moving, then Surface Aircraft Operational Status<br />
Messages (TYPE=31, Subtype=1) shall be broadcast at r<strong>and</strong>om intervals that are uni<strong>for</strong>mly<br />
distributed over the range of 4.8 to 5.2 seconds relative to the previous Surface Aircraft Operational<br />
Status Message <strong>for</strong> as long as data is available to satisfy the requirements of subparagraph “b.”<br />
above.<br />
(2). Aircraft/Vehicle Is Moving but No Change in NIC SUPP/NAC/SIL Data:<br />
If the Aircraft/Vehicle IS Moving <strong>and</strong> there has been no change in the NICSUPP, NAC, or SIL data<br />
provided in the Surface Aircraft Operational Status Message (TYPE=31, Subtype=1), then the<br />
messages shall be broadcast at r<strong>and</strong>om intervals that are uni<strong>for</strong>mly distributed over the range of<br />
2.4 to 2.6 seconds relative to the previous Surface Aircraft Operational Status Message <strong>for</strong> as long<br />
as data is available to satisfy the requirements of subparagraph “b.” above.<br />
(3). Aircraft/Vehicle Is Moving With Change in NIC SUPP/NAC/SIL Data:<br />
If the Aircraft/Vehicle IS Moving <strong>and</strong> there has been a change in the NICSUPP, NAC, or SIL data<br />
provided in the Surface Aircraft Operational Status Message (TYPE=31, Subtype=1), then the<br />
messages shall be broadcast at r<strong>and</strong>om intervals that are uni<strong>for</strong>mly distributed over the range of<br />
0.7 to 0.9 seconds relative to the previous Surface Aircraft Operational Status Message <strong>for</strong> a period<br />
of 24 ±1 seconds<strong>for</strong> as long as data is available to satisfy the requirements of subparagraph “b.”<br />
above.<br />
C.2.3.10.2 Message Delivery<br />
Draft<br />
Message delivery is independent of the Event-Driven protocol <strong>and</strong> is classified as a Periodic Status<br />
Message.<br />
Note.— In previous Editions of this Manual, the Operational Status Message was delivered using the<br />
Event-Driven protocol.<br />
C.2.3.10.3 Capability Class (CC) Codes<br />
This 16-bit (“ME” bits 9 – 24, Message bits 41 – 56) subfield in the Airborne Aircraft Operational Status<br />
Message (Subtype=0) or 12-bit (“ME” bits 9 – 20, Message bits 41 – 52) subfield in the Surface Aircraft<br />
Operational Status Message (Subtype=1) shall be used to report the operational capability of the aircraft.<br />
Encoding of the CC subfield shall be defined as specified in Table C-23 <strong>and</strong> Table C-24.<br />
For an ADS-B Transmitting Subsystem compliant with this Manual, if an update has not been received from<br />
an on-board data source within the past 2 seconds <strong>for</strong> any data element of the Capability Class Codes<br />
subfield, then the data associated with that data element shall be considered invalid <strong>and</strong> so reflected in the<br />
encoding of that message element to reflect “No Capability” or “Unknown” capability.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Msg Bit<br />
#<br />
“ME”<br />
Bit #<br />
Appendix C C-31<br />
Content = 0,0<br />
Table C-23. Airborne Capability Class (CC) Code <strong>for</strong> Version 2 Systems<br />
41 42 43 44 45 46 47 48 49 50 51 52 53 – 56<br />
9 10 11 12 13 14 15 16 17 18 19 20 21 -- 24<br />
TCAS<br />
Operational<br />
0,1 Reserved<br />
1,0 Reserved<br />
1,1 Reserved<br />
Subfield Coding:<br />
1090ES<br />
IN<br />
Reserved<br />
= 0,0<br />
1. TCAS Operational<br />
= 0: TCAS/ACAS is NOT Operational<br />
= 1: TCAS/ACAS IS Operational<br />
2. 1090ES IN (1090 MHz <strong>Extended</strong> <strong>Squitter</strong>)<br />
= 0: Aircraft has NO 1090ES Receive capability<br />
= 1: Aircraft has 1090ES Receive capability<br />
ARV TS TC<br />
3. ARV (Air-Referenced Velocity Report Capability)<br />
= 0: No capability <strong>for</strong> sending messages to support Air Referenced Velocity Reports<br />
= 1: Capability of sending messages to support Air-Referenced Velocity Reports.<br />
4. TS (Target State Report Capability)<br />
= 0: No capability <strong>for</strong> sending messages to support Target State Reports<br />
= 1: Capability of sending messages to support Target State Reports<br />
UAT<br />
IN<br />
5. TC (Target Change Report Capability)<br />
= 0: No capability <strong>for</strong> sending messages to support Trajectory Change Reports<br />
= 1: Capability of sending messages to support TC+0 Report only<br />
= 2: Capability of sending in<strong>for</strong>mation <strong>for</strong> multiple TC reports<br />
= 3: Reserved<br />
6. UAT IN (Universal Access Transceiver)<br />
= 0: Aircraft has No UAT Receive capability<br />
= 1: Aircraft has UAT Receive capability<br />
Msg Bit<br />
#<br />
“ME” Bit<br />
#<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Content = 0,0<br />
Subfield Coding:<br />
Reserved<br />
<strong>for</strong><br />
ADS-R<br />
Reserved<br />
[4]<br />
Draft<br />
Table C-24. Surface Capability Class (CC) Code <strong>for</strong> Version 2 Systems<br />
41 42 43 44 45 46 47 48 49 --- 51 52<br />
9 10 11 12 13 14 15 16 17 --- 19 20<br />
Reserved<br />
= 0<br />
0,1 Reserved<br />
1,0 Reserved<br />
1,1 Reserved<br />
1090ES<br />
IN<br />
Reserved<br />
= 0,0<br />
1. 1090ES IN (1090 MHz <strong>Extended</strong> <strong>Squitter</strong>)<br />
= 0: Aircraft has NO 1090ES Receive capability<br />
= 1: Aircraft has 1090ES Receive capability<br />
B2<br />
Low<br />
UAT<br />
IN<br />
NACV<br />
[3]<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
NIC<br />
Supplement-C<br />
[1]
C-32 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
2. B2 Low (Class B2 Transmit Power Less Than 70 Watts)<br />
= 0: Greater than or equal to 70 Watts Transmit Power<br />
= 1: Less than 70 Watts Transmit Power<br />
3. UAT IN (Universal Access Transceiver)<br />
= 0: Aircraft has NO UAT Receive capability<br />
= 1: Aircraft has UAT Receive capability<br />
4. NAC V (Navigation Accuracy Category <strong>for</strong> Velocity)<br />
5. NIC Supplement-C (NIC Supplement <strong>for</strong> use on the Surface)<br />
C.2.3.10.4 Operational <strong>Mode</strong> (OM)<br />
This 16-bit (“ME” bits 25 – 40, Message bits 57 – 72) subfield shall be used to indicate the Operational<br />
<strong>Mode</strong>s that are active on board the aircraft. Encoding of the OM subfield <strong>for</strong> Airborne Operational Status<br />
Messages (Subtype=0) shall be as shown in Table C-25. Encoding of the OM subfield <strong>for</strong> Surface<br />
Operational Status Messages (Subtype=1) shall be as shown in Table C-26.<br />
Msg Bit<br />
#<br />
"ME”<br />
Bit #<br />
OM<br />
Format<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table C-25. Airborne Operational <strong>Mode</strong> (OM) Subfield Format<br />
57 58 59 60 61 62 63 -- 64 65 --- 72<br />
25 26 27 28 29 30 31 -- 32 33 --- 40<br />
= 0 0<br />
TCAS<br />
RA<br />
Active<br />
[1]<br />
0, 1 Reserved<br />
1, 0 Reserved<br />
1, 1 Reserved<br />
IDENT<br />
Switch<br />
Active<br />
[1]<br />
Subfield Coding:<br />
1. TCAS Resolution Advisory (RA) Active<br />
= 0: TCAS II or ACAS RA not active<br />
= 1: TCAS RA is active<br />
Reserved<br />
<strong>for</strong><br />
Receiving<br />
ATC<br />
<strong>Services</strong><br />
[1]<br />
Single<br />
Antenna<br />
Flag<br />
[1]<br />
System<br />
Design<br />
Assurance<br />
[2]<br />
Reserved<br />
[8]<br />
Draft<br />
2. IDENT Switch Active<br />
= 0: Ident switch not active<br />
= 1: Ident switch active – retained <strong>for</strong> 18 ±1 seconds<br />
3. Reserved <strong>for</strong> Receiving ATC <strong>Services</strong><br />
= 0: Set to ZERO <strong>for</strong> this Edition of this Manual<br />
4. Single Antenna Flag<br />
= 0: Systems with two functioning antennas<br />
= 1: Systems that use only one antenna<br />
5. System Design Assurance (SDA)<br />
(see Table C-32)<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-33<br />
Msg Bit<br />
#<br />
"ME”<br />
Bit #<br />
OM<br />
Format<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table C-26. Surface Operational <strong>Mode</strong> (OM) Subfield Format<br />
57 58 59 60 61 62 63 -- 64 65 --- 72<br />
25 26 27 28 29 30 31 -- 32 33 --- 40<br />
= 0, 0<br />
Subfield Coding:<br />
TCAS<br />
RA<br />
Active<br />
[1]<br />
0, 1 Reserved<br />
1, 0 Reserved<br />
1, 1 Reserved<br />
IDENT<br />
Switch<br />
Active<br />
[1]<br />
1. TCAS Resolution Advisory (RA) Active<br />
= 0: TCAS II or ACAS RA not active<br />
= 1: TCAS RA is active<br />
Reserved<br />
<strong>for</strong><br />
Receiving<br />
ATC<br />
<strong>Services</strong><br />
[1]<br />
2. IDENT Switch Active<br />
= 0: Ident switch not active<br />
= 1: Ident switch active – retained <strong>for</strong> 18 ±1 seconds<br />
3. Reserved <strong>for</strong> Receiving ATC <strong>Services</strong><br />
= 0: Set to ZERO <strong>for</strong> this Edition of this Manual<br />
4. Single Antenna Flag<br />
= 0: Systems with two functioning antennas<br />
= 1: Systems that use only one antenna<br />
5. System Design Assurance (SDA)<br />
(see Table C-32)<br />
6. GPS Antenna Offset<br />
(see Table C-33 <strong>and</strong> Table C-34)<br />
Single<br />
Antenna<br />
Flag<br />
[1]<br />
System<br />
Design<br />
Assurance<br />
[2]<br />
GPS<br />
Antenna<br />
Offset<br />
[8]<br />
Draft<br />
C.2.3.10.5 Version Number<br />
This 3-bit (“ME” bits 41 – 43, Message bits 73 – 75) subfield shall be used indicate the Version Number of<br />
the <strong>for</strong>mats <strong>and</strong> protocols in use on the aircraft installation. Encoding of the subfield shall be as shown in<br />
Table C-27.<br />
Table C-27. Version Number Encoding<br />
Coding<br />
(Binary) (Decimal)<br />
VERSION NUMBER SUBFIELD<br />
Meaning<br />
000 0 Con<strong>for</strong>mant to Doc 9871, Appendix A<br />
001 1 Con<strong>for</strong>mant to Doc 9871, Appendix B<br />
010 2 Con<strong>for</strong>mant to Doc 9871, Appendix C<br />
011 – 111 3 – 7 Reserved<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
C-34 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.2.3.10.6 Navigation Integrity Category (NIC) <strong>and</strong> NIC Supplement-A<br />
The first 5-bit field (“ME” bits 1 – 5, Message bits 33 – 37) in every <strong>Mode</strong> S <strong>Extended</strong> <strong>Squitter</strong> Message<br />
contains the <strong>for</strong>mat TYPE Code. The <strong>for</strong>mat TYPE Code differentiates the 1090ES Messages into several<br />
classes: Airborne Position, Airborne Velocity, Surface Position, Identification <strong>and</strong> Category, Aircraft Intent,<br />
Aircraft Status, etc. In addition, the <strong>for</strong>mat TYPE Code also encodes the Navigation Integrity Category (NIC)<br />
value of the source used <strong>for</strong> the position report.<br />
The NIC Supplement-A is a 1-bit (“ME” bit 44, Message bit 76) subfield in the Aircraft Operational Status<br />
Message that is used in conjunction with the TYPE Code <strong>and</strong> NIC value to allow surveillance applications to<br />
determine whether the reported geometric position has an acceptable level of integrity containment region<br />
<strong>for</strong> the intended use. The NIC integrity containment region is described horizontally using the radius of<br />
containment, RC. The <strong>for</strong>mat TYPE Code also differentiates the Airborne Messages as to the type of their<br />
altitude measurements: barometric pressure altitude or GNSS height (HAE). The 5-bit encoding <strong>for</strong> <strong>for</strong>mat<br />
TYPE Code <strong>and</strong> NIC values con<strong>for</strong>ms to the definition contained in Table C-28. If an update has not been<br />
received from an on-board data source <strong>for</strong> the determination of the TYPE Code value based on the radius of<br />
containment within the past 2 seconds, then the TYPE Code value shall be encoded to indicate that RC is<br />
“Unknown.”<br />
NIC<br />
Value<br />
Table C-28. Navigation Integrity Category (NIC) Encoding<br />
Radius of Containment<br />
(RC)<br />
Airborne Surface<br />
Airborne<br />
Position<br />
TYPE Code<br />
NIC<br />
Supplement<br />
Codes<br />
A B<br />
Surface<br />
Position<br />
TYPE Code<br />
NIC<br />
Supplement<br />
Codes<br />
A C<br />
0 RC unknown 0, 18 or 22 0 0 0, 8 0 0<br />
1 RC < 20 NM (37.04 km) 17 0 0 N/A N/A N/A<br />
2 RC < 8 NM (14.816 km) 16 0 0 N/A N/A N/A<br />
3 RC < 4 NM (7.408 km) 16 1 1 N/A N/A N/A<br />
4 RC < 2 NM (3.704 km) 15 0 0 N/A N/A N/A<br />
5 RC < 1 NM (1852 m) 14 0 0 N/A N/A N/A<br />
RC < 0.6 NM (1111.2 m) 13 1 1 8 0 1<br />
6 RC < 0.5 NM (926 m) 13 0 0 N/A N/A N/A<br />
RC < 0.3 NM (555.6 m) 13 0 1 8 1 0<br />
7 RC < 0.2 NM (370.4 m) 12 0 0 8 1 1<br />
8 RC < 0.1 NM (185.2 m) 11 0 0 7 0 0<br />
9 RC < 75m 11 1 1 7 1 0<br />
10 RC < 25m 10 or 21 0 0 6 0 0<br />
11 RC < 7.5m 9 or 20 0 0 5 0 0<br />
12 Reserved<br />
13 Reserved<br />
14 Reserved<br />
15 Reserved<br />
Notes.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Draft<br />
1. “N/A” means “This NIC value is not available in the ADS-B Surface Position Message <strong>for</strong>mats.”<br />
2. NIC Supplement-A is broadcast in the Aircraft Operational Status Message, “ME” bit 44<br />
(Message bit 76, see Figure C-10). NIC Supplement-B is broadcast in the Airborne Position Message,<br />
“ME” bit 8 (Message bit 40, see Figure C-1). NIC Supplement-C is broadcast in the Surface Capability<br />
Class (CC) Code Subfield of the Aircraft Operational Status Message, “ME” bit 20 (Message bit 52, see<br />
Table C-24).<br />
3. A non-excluded satellite failure requires that the RC be set to Unknown along with the NAC P<br />
parameter being set to ZERO to indicate that the position has been determined to be invalid (see<br />
§C.2.3.1.1.3 <strong>and</strong> §C.2.3.1.2.4).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-35<br />
C.2.3.10.7 Navigation Accuracy Category <strong>for</strong> Position (NACP)<br />
This 4-bit (“ME” bits 45 – 48, Message bits 77 – 80) subfield shall be used to announce 95% accuracy limits<br />
<strong>for</strong> the horizontal position (<strong>and</strong> <strong>for</strong> some NAC P values, the vertical position) that is being currently broadcast<br />
in Airborne Position <strong>and</strong> Surface Position Messages. Encoding of the subfield shall be as shown in Table C-<br />
13. If an update has not been received from an on-board data source <strong>for</strong> NAC P within the past 2 seconds,<br />
then the NAC P subfield shall be encoded as a value indicating “Unknown Accuracy.”<br />
C.2.3.10.8 Geometric Vertical Accuracy (GVA)<br />
This 2-bit (“ME” bits 49 – 50, Message bits 81 – 82) subfield in the Airborne Operational Status Message<br />
(Subtype=0) shall be encoded as shown in Table C-29, <strong>and</strong> set by using the Vertical Figure of Merit (VFOM)<br />
(95%) from the GNSS position source used to encode the geometric altitude field in the Airborne Position<br />
Message.<br />
Table C-29. Encoding of the Geometric Vertical Accuracy (GVA)<br />
Subfield in Aircraft Operational Status Messages<br />
GVA Encoding<br />
Meaning<br />
(decimal)<br />
(meters)<br />
0 Unknown or > 150 meters<br />
1 ≤ 150 meters<br />
2 ≤ 45 meters<br />
3 Reserved<br />
Note.— For the purposes of this Manual, values <strong>for</strong> 0, 1 <strong>and</strong> 2 are encoded. Decoding values <strong>for</strong> 3<br />
should be treated as < 45 meters until future versions of this Manual redefine the value.<br />
C.2.3.10.9 Source Integrity Level (SIL)<br />
This 2-bit (“ME” bits 51 – 52, Message bits 83 – 84) subfield is defined <strong>for</strong> the Target State <strong>and</strong> Status<br />
Message in §C.2.3.9.11 <strong>and</strong> Table C-15, <strong>and</strong> remains the same in the Operational Status Message.<br />
C.2.3.10.10 Barometric Altitude Integrity Code (NICBARO)<br />
Draft<br />
This 1-bit (“ME” bit 53, Message bit 85) subfield shall be used to indicate whether or not the barometric<br />
pressure altitude being reported in the Airborne Position Message (§C.2.3.2) has been cross-checked<br />
against another source of pressure altitude. The NICBARO subfield shall be encoded as shown in Table C-14.<br />
If an update has not been received from an on-board data source <strong>for</strong> NICBARO within the past 2 seconds,<br />
then the NICBARO subfield shall be encoded as a value of ZERO (0).<br />
C.2.3.10.11 Aircraft Length <strong>and</strong> Width Codes<br />
This 4-bit (“ME” bits 21 – 24, Message bits 53 – 56) subfield shall be used in the Surface Aircraft Operational<br />
Status Message (Subtype=1) to describe the amount of space that an Aircraft or Ground Vehicle occupies.<br />
The A/V Length <strong>and</strong> Width Code shall be based on the actual dimensions of the transmitting Aircraft or<br />
Surface Vehicle as specified in Table C-30. Once the actual Length <strong>and</strong> Width of the A/V has been<br />
determined, each A/V shall be assigned the smallest A/V Length <strong>and</strong> Width Code from Table C-30 <strong>for</strong> which<br />
the actual length is less than or equal to the upper bound length <strong>for</strong> that Length/Width Code, <strong>and</strong> <strong>for</strong> which<br />
the actual width is less than or equal to the upper bound width <strong>for</strong> that Length/Width Code.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-36 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Table C-30. A/V Length <strong>and</strong> Width Code<br />
A/V - L/W<br />
Length Code Width Upper-Bound Length <strong>and</strong> Width<br />
Code<br />
Code<br />
<strong>for</strong> Each Length/Width Code<br />
(Decimal) “ME” “ME” “ME” “ME” Length<br />
Width<br />
Bit 49 Bit 50 Bit 51 Bit<br />
52<br />
(meters)<br />
(meters)<br />
0 0 0 0 0 No Data or Unknown<br />
1 0 0 0 1 15 23<br />
2<br />
3<br />
0 0 1<br />
0<br />
1<br />
25<br />
28.5<br />
34<br />
4<br />
5<br />
0 1 0<br />
0<br />
1<br />
35<br />
33<br />
38<br />
6<br />
7<br />
0 1 1<br />
0<br />
1<br />
45<br />
39.5<br />
45<br />
8<br />
9<br />
1 0 0<br />
0<br />
1<br />
55<br />
45<br />
52<br />
10<br />
11<br />
1 0 1<br />
0<br />
1<br />
65<br />
59.5<br />
67<br />
12<br />
13<br />
1 1 0<br />
0<br />
1<br />
75<br />
72.5<br />
80<br />
14<br />
15<br />
1 1 1<br />
0<br />
1<br />
85<br />
80<br />
90<br />
If the Aircraft or Vehicle is longer than 85 meters, or wider than 90 meters, then decimal Aircraft/Vehicle<br />
Length/Width Code 15 shall be used.<br />
Note.— For example, consider a powered glider with overall length of 24 meters <strong>and</strong> wingspan of<br />
50 meters. Normally, an aircraft of that length would be in length category 1 (that is, have a length code of<br />
1). But since the wingspan exceeds 34 meters, it does not qualify <strong>for</strong> even the “wide” subcategory (width<br />
code = 1) of length category 1. Such an aircraft would be assigned length code = 4 <strong>and</strong> width code = 1,<br />
meaning “length less than 55 meters <strong>and</strong> width less than 52 meters.”<br />
C.2.3.10.12 Track Angle/Heading<br />
The Track Angle/Heading is a 1-bit (“ME” bit 53, Message bit 85) subfield of the ADS-B Aircraft Operational<br />
Status Message (Subtype=1, <strong>for</strong> Surface Participants) that allows correct interpretation of the data contained<br />
in the Heading/Ground Track subfield of the ADS-B Surface Position Message when the Air/Ground status is<br />
determined to be in the “On-Ground” state as indicated in §3.1.2.6.10.1.2 of Annex 10, Vol. IV.<br />
Draft<br />
C.2.3.10.13 Horizontal Reference Direction (HRD)<br />
This 1-bit (“ME” bit 54, Message bit 86) subfield will be used to indicate the reference direction (true north or<br />
magnetic north) <strong>for</strong> horizontal directions such as Heading, Track Angle. The Horizontal Reference Direction<br />
subfield will be encoded as specified in Table C-31.<br />
Table C-31. Horizontal Reference Direction (HRD) Encoding<br />
HRD Value Meaning<br />
0 True North<br />
1 Magnetic North<br />
C.2.3.10.14 System Design Assurance (SDA)<br />
The position transmission chain includes the ADS-B transmission equipment, ADS-B processing equipment,<br />
position source, <strong>and</strong> any other equipment that processes the position data <strong>and</strong> position quality metrics that<br />
shall be transmitted.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-37<br />
The “System Design Assurance” (SDA) subfield is a 2-bit (“ME” bits 31 – 32, Message bits 63 – 64) field that<br />
shall define the failure condition that the position transmission chain is designed to support as defined in<br />
Table C-32.<br />
The supported failure condition shall indicate the probability of a position transmission chain fault causing<br />
false or misleading in<strong>for</strong>mation to be transmitted. The definitions <strong>and</strong> probabilities associated with the<br />
supported failure effect are defined in AC 25.1309-1A, AC 23-1309-1C, <strong>and</strong> AC 29-2C. All relevant systems<br />
attributes should be considered including software <strong>and</strong> complex hardware in accordance with RTCA DO-<br />
178B (EUROCAE ED-12B) or RTCA DO-254 (EUROCAE ED-80).<br />
Table A-32. “System Design Assurance” OM Subfield in Aircraft Operational Status<br />
Messages<br />
SDA Value Supported Probability of Undetected Fault Software & Hardware<br />
(decimal<br />
)<br />
(binary)<br />
Failure<br />
Note 2<br />
Condition<br />
causing transmission of False or<br />
Note 3,4<br />
Misleading In<strong>for</strong>mation<br />
Design Assurance<br />
Note 1,3<br />
Level<br />
0 00<br />
Unknown/ No<br />
safety effect<br />
> 1x10 -3 per flight hour<br />
or Unknown<br />
N/A<br />
1 01 Minor ≤ 1x10 -3 per flight hour D<br />
2 10 Major ≤ 1x10 -5 per flight hour C<br />
3 11 Hazardous ≤ 1x10 -7 per flight hour B<br />
Notes.—<br />
1. Software Design Assurance per RTCA DO-178B (EUROCAE ED-12B). Airborne Electronic Hardware<br />
Design Assurance per RTCA DO-254 (EUROCAE ED-80).<br />
2. Supported Failure Classification defined in AC-23.1309-1D, AC-25.1309-1A, AC-27-1B <strong>and</strong> AC 29-2C.<br />
3. Because the broadcast position can be used by any other ADS-B equipped aircraft or by ATC, the<br />
provisions in AC 23-1309-1D that allow reduction in failure probabilities <strong>and</strong> design assurance level <strong>for</strong><br />
aircraft under 6000 pounds do not apply.<br />
4. Includes probability of transmitting false or misleading latitude, longitude, or associated accuracy <strong>and</strong><br />
integrity metrics.<br />
C.2.3.10.15 SIL Supplement<br />
The “SIL Supplement” (Source Integrity Level Supplement) subfield is a 1-bit (“ME” bit 8, Message bit 40)<br />
field that shall define whether the reported SIL probability is based on a “per hour” probability or a “per<br />
sample” probability as defined in §C.2.3.9.2 <strong>and</strong> Table C-6.<br />
Draft<br />
C.2.3.10.16 TCAS/ACAS Operational<br />
The “TCAS/ACAS Operational” subfield (“ME” bit 11, Message bit 43) of the CC Codes subfield in ADS-B<br />
Aircraft Operational Status Messages (TYPE=31, SUBTYPE=0, <strong>for</strong> airborne participants) is used to indicate<br />
whether the TCAS/ACAS System is Operational or not, <strong>and</strong> remains as defined <strong>for</strong> use in the Target State<br />
<strong>and</strong> Status Message (§C.2.3.9.18), with the encoding as specified in Table C-21.<br />
C.2.3.10.17 1090ES IN<br />
The CC Code subfield <strong>for</strong> “1090ES IN” in Aircraft Operational Status Messages (TYPE=31, Subtype=0 or 1)<br />
is a 1-bit field (“ME” bit 12, Message bit 44) that is set to ONE (1) if the transmitting aircraft has the capability<br />
to receive ADS-B 1090ES Messages. Otherwise, this CC code subfield is set to ZERO (0).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-38 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.2.3.10.18 UAT IN<br />
The “UAT IN” CC Code subfield (“ME” bit 19, Message bit 51, TYPE=31, Subtype=0, <strong>for</strong> airborne<br />
participants AND “ME” Bit 16, Message bit 48, TYPE=31, Subtype=1 <strong>for</strong> surface participants) in ADS-B<br />
Aircraft Operational Status Messages is so called because it denotes whether the aircraft is equipped with<br />
the capability to receive ADS-B Universal Access Transceiver (UAT) Messages.<br />
The “UAT IN” CC Code in Aircraft Operational Status Messages is set to ZERO (0) if the aircraft is NOT<br />
fitted with the capability to receive ADS-B UAT Messages. The “UAT IN” CC Code Subfield is set to ONE<br />
(1) if the aircraft has the capability to receive ADS-B UAT Messages.<br />
C.2.3.10.19 Navigation Accuracy Category <strong>for</strong> Velocity (NACV)<br />
This 3-bit subfield (“ME” bits 17 – 19, Message bits 49 – 51) indicates the Navigation Accuracy Category <strong>for</strong><br />
Velocity (NACV) as defined in §C.2.3.5.4, with the encoding as specified in Table C-5.<br />
C.2.3.10.20 NIC Supplement-C<br />
The NIC Supplement-C subfield in the Aircraft Operational Status Message is a one-bit subfield (“ME” bit 20,<br />
Message bit 52) that, together with the TYPE subfield in Surface Position Messages <strong>and</strong> the NIC<br />
Supplement-A in the Operational Status Message (“ME” Bit 44, Message Bit 76), is used to encode the<br />
Navigation Integrity Category (NIC) of the transmitting ADS-B participant.<br />
If an update has not been received from an on-board data source <strong>for</strong> the determination of the NIC value<br />
within the past 2 seconds, then the NIC Supplement subfield is encoded to indicate the larger Radius of<br />
Containment (RC). Table C-28 lists the possible NIC codes <strong>and</strong> the values of the TYPE subfield of the Airborne <strong>and</strong> Surface<br />
Position Messages, <strong>and</strong> of the NIC Supplement-A, NIC Supplement-B <strong>and</strong> NIC Supplement-C subfields that<br />
are used to encode those NIC codes in messages on the 1090 MHz ADS-B data link.<br />
C.2.3.10.21 GPS Antenna Offset<br />
The “GPS Antenna Offset” subfield is an 8-bit (“ME” bits 33 – 40, Message bits 65 – 72) field in the OM<br />
Code Subfield of surface <strong>for</strong>mat Aircraft Operational Status Messages that defines the position of the GPS<br />
antenna in accordance with the following.<br />
a. Lateral Axis GPS Antenna Offset:<br />
Draft<br />
“ME” bits 33 – 35 (Message bits 65 – 67) are used to encode the lateral distance of the GPS Antenna<br />
from the longitudinal axis (Roll) axis of the aircraft. Encoding is established in accordance with Table C-<br />
33.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-39<br />
Notes.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table C-33. Lateral Axis GPS Antenna Offset Encoding<br />
“ME” Bit<br />
(Message Bit)<br />
33 34<br />
(65) (66)<br />
35<br />
(67)<br />
Upper Bound of the<br />
GPS Antenna Offset<br />
Along Lateral (Pitch) Axis<br />
Left or Right of Longitudinal (Roll) Axis<br />
0 = left Encoding<br />
1 = right Bit 1 Bit 0 Direction (meters)<br />
0 0 NO DATA<br />
0<br />
0<br />
1<br />
1<br />
0<br />
LEFT<br />
2<br />
4<br />
1 1<br />
6<br />
0 0 0<br />
1<br />
0<br />
1<br />
1<br />
0<br />
RIGHT<br />
2<br />
4<br />
1 1<br />
6<br />
1. Left means toward the left wing tip moving from the longitudinal center line of the aircraft.<br />
2. Right means toward the right wing tip moving from the longitudinal center line of the aircraft.<br />
3. Maximum distance left or right of aircraft longitudinal (roll) axis is 6 meters or 19.685 feet. If the<br />
distance is greater than 6 meters, then the encoding should be set to 6 meters.<br />
4. The “No Data” case is indicated by encoding of “000” as above, while the “ZERO” offset case is<br />
represented by encoding of “100” as above.<br />
5. The accuracy requirement is assumed to be better than 2 meters, consistent with the data<br />
resolution.<br />
b. Longitudinal Axis GPS Antenna Offset:<br />
“ME” bits 36 – 40 (Message bits 68 – 72) are used to encode the longitudinal distance of the GPS<br />
Antenna from the NOSE of the aircraft. Encoding is established in accordance with Table C-34. If the<br />
Antenna Offset is compensated by the Sensor to be the position of the ADS-B participant’s ADS-B<br />
Position Reference Point (RTCA DO-242A, §3.4.4.9.7), then the encoding is set to binary “00001” in<br />
Table C-34.<br />
Table C-34. Longitudinal Axis GPS Antenna Offset Encoding<br />
Draft<br />
36<br />
(68)<br />
“ME” Bit<br />
(Message Bit)<br />
37 38 39<br />
(69) (70) (71)<br />
Encoding<br />
40<br />
(72)<br />
Upper Bound of the<br />
GPS Antenna Offset<br />
Along Longitudinal (Roll) Axis<br />
Aft From Aircraft Nose<br />
Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 (meters)<br />
0 0 0 0 0 NO DATA<br />
0 0 0 0 1 Position Offset Applied by Sensor<br />
0 0 0 1 0 2<br />
0 0 0 1 1 4<br />
0 0 1 0 0 6<br />
* * * * * ***<br />
* * * * * ***<br />
* * * * * ***<br />
1 1 1 1 1 60<br />
Notes.—<br />
1. Maximum distance aft from aircraft nose is 60 meters or 196.85 feet.<br />
2. The accuracy requirement is assumed to be better than 2 meters, consistent with the data<br />
resolution.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-40 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.2.4 INITIALIZATION AND TIMEOUT<br />
Note.— Initialization <strong>and</strong> timeout functions <strong>for</strong> <strong>Extended</strong> <strong>Squitter</strong> broadcast are per<strong>for</strong>med by the<br />
transponder <strong>and</strong> are specified in RTCA/DO-181D (EUROCAE ED-73C). A description of these functions is<br />
presented in the following paragraphs to serve as reference material <strong>for</strong> the section on the GFM (§C.2.5).<br />
C.2.4.1 INITIATION OF EXTENDED SQUITTER BROADCAST<br />
At power up initialization, the transponder shall commence operation in a mode in which it broadcasts only<br />
acquisition squitters. The transponder shall initiate the broadcast of <strong>Extended</strong> <strong>Squitter</strong>s <strong>for</strong> Airborne<br />
Position, Surface Position, Aircraft Identification <strong>and</strong> Category, Airborne Velocity, Target State <strong>and</strong> Status<br />
<strong>and</strong> Operational Status when data are inserted into Registers 0516, 0616, 0816, 0916, 6216 <strong>and</strong> 6516 respectively. This determination shall be made individually <strong>for</strong> each squitter type. The insertion of just<br />
altitude or surveillance status data into Register 0516 by the transponder shall not satisfy the minimum<br />
requirement <strong>for</strong> broadcast of the airborne position squitter.<br />
Note.— This suppresses the transmission of <strong>Extended</strong> <strong>Squitter</strong>s from aircraft that are unable to report<br />
position, velocity or identity in<strong>for</strong>mation.<br />
C.2.4.2 EXTENDED SQUITTER BROADCAST RATES<br />
The maximum 1090 MHz ADS-B message transmission rate shall not exceed 6.2 transmitted messages per<br />
second, averaged over any 60 second interval (see §3.1.2.8.9.1, Annex 10, Vol. IV).<br />
Note.— Transponders are limited to no more than 2 Event Driven messages per second. There<strong>for</strong>e, the<br />
average of 2 Airborne Position, 2 Airborne Velocity, 0.2 Identification, <strong>and</strong> 2 Periodic Status <strong>and</strong> Event<br />
Driven messages per second, averaged over any 60 second interval, yields the required 6.2 messages per<br />
second.<br />
The summary of all extended squitter broadcast rates is presented in Table C-35.<br />
Table C-35. 1090 MHz <strong>Extended</strong> <strong>Squitter</strong> ADS-B Message Broadcast Rates<br />
Transponder<br />
Register<br />
Event Driven<br />
Message<br />
Priority<br />
1090ES ADS-B Message<br />
On-the-Ground,<br />
not moving<br />
Broadcast Rate<br />
On-the-Ground<br />
<strong>and</strong> moving<br />
Airborne<br />
BDS 0,5 N/A Airborne Position N/A N/A<br />
2 / 1 second<br />
(0.4 – 0.6 sec)<br />
LOW RATE<br />
HIGH RATE<br />
BDS 0,6 N/A Surface Position<br />
1 / 5 seconds<br />
2 / 1 second<br />
N/A<br />
(4.8 – 5.2 sec)<br />
(0.4 – 0.6 sec)<br />
LOW RATE<br />
HIGH RATE<br />
HIGH RATE<br />
BDS 0,8 N/A Aircraft Identification <strong>and</strong> Category 1 / 10 seconds<br />
1 / 5 seconds<br />
1 / 5 seconds<br />
(9.8 – 10.2 sec)<br />
(4.8 – 5.2 sec)<br />
(4.8 – 5.2 sec)<br />
BDS 0,9 N/A Airborne Velocity N/A N/A<br />
TCAS RA or <strong>Mode</strong> A Code Change<br />
2 / 1 second<br />
(0.4 – 0.6 sec)<br />
BDS 6,1<br />
TCAS RA = 1<br />
Emergency = 2<br />
Aircraft Status<br />
(Emergency/Priority Status, Subtype=1)<br />
(TCAS RA Broadcast, Subtype=2)<br />
0.7 – 0.9 seconds<br />
No TCAS RA, No <strong>Mode</strong> A Change<br />
4.8 – 5.2 seconds<br />
No TCAS RA, No <strong>Mode</strong> A Change, No Emergency, <strong>Mode</strong> A Code set to 10008 No Transmission<br />
BDS 6,2 N/A Target State <strong>and</strong> Status (TSS) N/A N/A 1.2 – 1.3 seconds<br />
No change NICSUPP/NAC/SIL 2.4 – 2.6 seconds<br />
TSS being broadcast or not<br />
No change TCAS/NAC/SIL/NICSUPP 2.4 – 2.6 seconds<br />
TSS being broadcast<br />
BDS 6,5 N/A Aircraft Operational Status 4.8 – 5.2 seconds<br />
Change in NICSUPP/NAC/SIL 0.7 – 0.9 seconds<br />
Change in TCAS/NAC/SIL/NICSUPP 2.4 – 2.6 seconds<br />
TSS not broadcast 2<br />
Change in TCAS/NAC/SIL/NICSUPP 0.7 – 0.9 seconds<br />
N/A = Not Applicable<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-41<br />
Notes.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C.2.4.3 REGISTER TIMEOUT<br />
1. These Registers are cleared to prevent the reporting of outdated position <strong>and</strong> velocity<br />
in<strong>for</strong>mation.<br />
2. During a register timeout event, the “ME” field of the ADS-B Broadcast Message may contain<br />
ALL ZEROs, except <strong>for</strong> those fields that may be updated due to the receipt of new data.<br />
a. The ADS-B Transmitting Subsystem shall clear all but the altitude <strong>and</strong> surveillance status subfields<br />
of the Airborne Position Message, if no new position data is received within two (2) seconds of the<br />
previous input data update.<br />
Note.— During a timeout event the Format TYPE Code is set to ZERO (see §C.2.3.1.1.4).<br />
b. The ADS-B Transmitting Subsystem shall clear all 56-bits of the Surface Position Message if no<br />
new position data is received within two (2) seconds of the previous input data update.<br />
Notes.—<br />
1. During a timeout event the Format TYPE Code is set to ZERO (see §C.2.3.1.1.4).<br />
2. When position is available, the ADS-B Transmitting Subsystem manages the movement<br />
<strong>and</strong> the heading/ground track subfields such that the subfields <strong>and</strong> applicable status bits are set to<br />
ZERO (0) if no new data is received <strong>for</strong> the subfield within 2.6 seconds of the last data update of<br />
the subfield.<br />
3. When position data is not received, all bits of the Surface Position Message are set to<br />
ZERO to avoid confusion with altitude data in the Airborne Position Message sent with TYPE Code<br />
ZERO (0).<br />
c. The ADS-B Transmitting Subsystem shall clear all 56-bits of the Airborne Velocity Message if no<br />
data is received within 2.6 seconds of the previous input data update.<br />
Note.— The Intent Change in<strong>for</strong>mation is not sufficient to consider that new data has been<br />
received (see §C.2.3.5.3).<br />
Draft<br />
d. The ADS-B Transmitting Subsystem shall not clear the Aircraft Identification Message (see<br />
§C.2.3.4).<br />
Note.— The Aircraft Identification Message, is not cleared since it contains data that rarely<br />
changes in flight <strong>and</strong> is not frequently updated.<br />
e. The ADS-B Transmitting Subsystem shall clear each of the Selected Altitude, Selected Heading, or<br />
Barometric Pressure Setting subfields of the Target State <strong>and</strong> Status Message (see §C.2.3.9) if no<br />
new data is received within 2.0 seconds of the previous input data update <strong>for</strong> the respective<br />
subfield. Each of the subfields shall be cleared independently of the other subfields. That is, each<br />
of the three specified subfields shall be processed mutually exclusively of the other two specified<br />
subfields. The remaining subfields of the Target State <strong>and</strong> Status Message shall not be cleared, as<br />
they contain other integrity, mode, or status in<strong>for</strong>mation.<br />
f. The ADS-B Transmitting Subsystem shall not clear the Operational Status Messages (see<br />
§C.2.3.10) since the subfields of the Message contain various integrity, mode, or status<br />
in<strong>for</strong>mation..<br />
g. The ADS-B Transmitting Subsystem shall not clear the Event-Driven Messages (see §C.2.3.7).<br />
Note.— The Event-Driven Messages do not need to be cleared since contents of such<br />
messages are only broadcast once each time that new data is received.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
C-42 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.2.4.4 TERMINATION OF EXTENDED SQUITTER BROADCAST<br />
If input to Register 05 16, or 06 16 stops <strong>for</strong> 60 seconds, broadcast of the associated <strong>Extended</strong> <strong>Squitter</strong> type<br />
shall be discontinued until data insertion is resumed. The insertion of altitude by the transponder shall<br />
satisfy the minimum requirement <strong>for</strong> continuing to broadcast the airborne position squitter.<br />
If input to Register 09 16 stops <strong>for</strong> 2.6 seconds, broadcast of the associated <strong>Extended</strong> <strong>Squitter</strong> type shall be<br />
discontinued until data insertion is resumed.<br />
Notes.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1. Until timeout, an <strong>Extended</strong> <strong>Squitter</strong> type may contain an “ME” field of ALL ZEROs.<br />
2. Continued transmission <strong>for</strong> 60 seconds is required so that receiving aircraft will know that the data<br />
source <strong>for</strong> the message has been lost.<br />
C.2.4.5 REQUIREMENTS FOR NON-TRANSPONDER DEVICES<br />
Non-Transponder Devices shall provide the same functionality <strong>for</strong> initialization, Register timeout <strong>and</strong><br />
broadcast termination as specified <strong>for</strong> the transponder case in §C.2.4.1 through §C.2.4.3.<br />
a. A Non-Transponder Device shall not broadcast acquisition squitters, <strong>and</strong><br />
b. A Non-Transponder Device operating on the surface shall continue to broadcast DF=18 Messages<br />
with the TYPE Code=0 at a rate specified <strong>for</strong> the Surface Position Message, even though it has lost<br />
its navigation input.<br />
Note.— Continued broadcast of the Surface Position Message is needed to support the<br />
operation of surface multi-lateration systems.<br />
C.2.5 GENERAL FORMATTER/MANAGER (GFM)<br />
Note.— The General Formatter/Manager (GFM) is the name that will be used to refer to the function<br />
that <strong>for</strong>mats messages <strong>for</strong> insertion in the <strong>Extended</strong> <strong>Squitter</strong> registers. In addition to data <strong>for</strong>matting, there<br />
are other tasks that have to be per<strong>for</strong>med by this function.<br />
C.2.5.1 NAVIGATION SOURCE SELECTION<br />
Draft<br />
The GFM shall be responsible <strong>for</strong> the selection of the default source <strong>for</strong> aircraft position <strong>and</strong> velocity, the<br />
comm<strong>and</strong>ed altitude source, <strong>and</strong> <strong>for</strong> the reporting of the associated position <strong>and</strong> altitude errors.<br />
C.2.5.2 LOSS OF INPUT DATA<br />
The GFM shall be responsible <strong>for</strong> loading the registers <strong>for</strong> which it is programmed at the required update<br />
rate. If <strong>for</strong> any reason data is unavailable <strong>for</strong> a time equal to twice the update interval or 2 seconds<br />
(whichever is greater), the GFM shall ZERO old data (on a per field basis) <strong>and</strong> insert the resulting message<br />
into the appropriate register.<br />
Note.— For Register 0516 <strong>and</strong> 0616 a loss of position data would cause the GFM to set the Format<br />
TYPE Code to ZERO as the means of indicating “no position data” since ALL ZEROs in the lat/lon fields is a<br />
legal value.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-43<br />
Notes. —<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C.2.5.3 SPECIAL PROCESSING FOR FORMAT TYPE CODE ZERO<br />
C.2.5.3.1 Significance of Format TYPE Code Equal to Zero<br />
1. Format TYPE Code ZERO (0) is labeled “no position in<strong>for</strong>mation.” This is intended to be used<br />
when the lat/lon in<strong>for</strong>mation is not available or invalid, <strong>and</strong> still permit the reporting of baro altitude<br />
loaded by the transponder. The principal use of this message case is to provide ACAS the ability to<br />
passively receive altitude.<br />
2. Special h<strong>and</strong>ling is required <strong>for</strong> the airborne <strong>and</strong> Surface Position Messages because a CPR<br />
encoded value of ALL ZEROs in the Lat/Lon field is a valid value.<br />
C.2.5.3.2 Broadcast of Format TYPE Code Equal to Zero<br />
Format TYPE Code 0 shall only be set by the following events:<br />
a. Airborne Position or Surface Position (Register 0516, <strong>and</strong> 0616) has not been loaded by the GFM <strong>for</strong><br />
2 seconds. In this case the transponder clears the entire 56 bits of the register that timed out. (In<br />
the case of the Airborne Position register, the altitude subfield is only ZEROed if no altitude data is<br />
available). Transmission of the Airborne <strong>and</strong> Surface Position <strong>Extended</strong> <strong>Squitter</strong> that broadcasts<br />
the timed out register shall itself stop in 60 seconds except <strong>for</strong> the Airborne Position Message when<br />
Altitude is still available. Broadcast of this <strong>Extended</strong> <strong>Squitter</strong> shall resume when the GFM begins to<br />
insert data into the register.<br />
b. The GFM determines that all navigation sources that can be used <strong>for</strong> the <strong>Extended</strong> <strong>Squitter</strong><br />
airborne or Surface Position Message are either missing or invalid. In this case the GFM can clear<br />
the Format TYPE Code <strong>and</strong> all other fields of the airborne position, surface position <strong>and</strong> insert this<br />
zeroed message in the appropriate register. This should only be done once so that the transponder<br />
can detect the loss of data insertion <strong>and</strong> suppress the broadcast of the related squitter.<br />
Note that in all of the above cases, a Format TYPE Code of ZERO contains a message of ALL ZEROs. The<br />
only exception is the airborne position <strong>for</strong>mat that may contain barometric altitude <strong>and</strong> surveillance status<br />
data as set by the transponder. There is no analogous case <strong>for</strong> the other <strong>Extended</strong> <strong>Squitter</strong> <strong>for</strong>mat types,<br />
since a ZERO value in any of the fields indicates no in<strong>for</strong>mation. No other squitter types are broadcast with<br />
TYPE Code equal ZERO (0).<br />
Draft<br />
C.2.5.3.3 Reception of Format TYPE Code Equal to Zero<br />
If a squitter with <strong>for</strong>mat TYPE Code equal to ZERO (0) is received, it shall be checked to see if altitude is<br />
present. If altitude is not present, the message shall be discarded. If altitude is present, it may be used to<br />
update altitude. An <strong>Extended</strong> <strong>Squitter</strong> containing Format TYPE Code ZERO shall only be used to update<br />
the altitude of an aircraft already in track.<br />
Note.— For ACAS, this could be an aircraft that was being maintained via hybrid surveillance when the<br />
position data input failed. In this case, altitude only could be used <strong>for</strong> a short period of time. Interrogation<br />
would have to begin at the update rate <strong>for</strong> that track to ensure update of range <strong>and</strong> bearing in<strong>for</strong>mation on<br />
the display.<br />
C.2.5.4 HANDLING OF EVENT-DRIVEN PROTOCOL<br />
The Event-Driven interface protocol shall provide a general-purpose interface into the transponder function<br />
<strong>for</strong> either those messages beyond those that are regularly transmitted all the time (provided input data is<br />
available), or those that are transmitted at a fixed periodic rate. This protocol shall operate by having the<br />
transponder broadcast a message once each time the Event-Driven register is loaded by the GFM.<br />
Note.— This gives the GFM complete freedom in setting the update rate (up to a maximum) <strong>and</strong><br />
duration of broadcast <strong>for</strong> applications such as emergency status <strong>and</strong> intent reporting.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-44 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
In addition to <strong>for</strong>matting, the GFM shall control the timing of message insertion so that it provides the<br />
necessary pseudo-r<strong>and</strong>om timing variation <strong>and</strong> does not exceed the maximum transponder broadcast rate<br />
<strong>for</strong> the Event-Driven protocol.<br />
C.2.5.4.1 Transponder Support <strong>for</strong> the Event Driven Protocol<br />
A message shall be transmitted once by the transponder, each time that Register 0A 16 is loaded.<br />
Transmission shall be delayed if the transponder is busy at the time of insertion.<br />
Note.— Delay times are short, a maximum of several milliseconds <strong>for</strong> the longest transponder<br />
transaction.<br />
The maximum transmission rate <strong>for</strong> the Event-Driven protocol shall limited by the transponder to twice per<br />
second. If a message is inserted in the Event-Driven register <strong>and</strong> cannot be transmitted due to rate limiting,<br />
it shall be held <strong>and</strong> transmitted when the rate limiting condition has cleared. If a new message is received<br />
be<strong>for</strong>e transmission is permitted, it shall overwrite the earlier message. A summary of the transmission rates<br />
<strong>for</strong> all extended squitters is shown in Table C-35.<br />
Note.— The squitter transmission rate <strong>and</strong> the duration of squitter transmissions is application<br />
dependent. Choices made should be the minimum rate <strong>and</strong> duration consistent with the needs of the<br />
application.<br />
C.2.5.4.2 GFM Use of the Event-Driven Protocol<br />
Note.— More than one application at a time may be supported by the Event-Driven protocol. The GFM<br />
h<strong>and</strong>les requests <strong>for</strong> broadcast by these applications <strong>and</strong> is the only function that is capable of inserting data<br />
into Register 0A16. In this way, the GFM can provide the pseudo r<strong>and</strong>om timing <strong>for</strong> all applications using this<br />
protocol <strong>and</strong> maintain a maximum insertion rate that does not exceed the transponder imposed limit.<br />
An application that wants to use the Event-Driven protocol shall notify the GFM of the <strong>for</strong>mat type <strong>and</strong><br />
required update rate. The GFM shall then locate the necessary input data <strong>for</strong> this <strong>for</strong>mat type <strong>and</strong> begin<br />
inserting data into Register 0A16 at the required rate. The GFM shall also insert this message into the<br />
register <strong>for</strong> this <strong>for</strong>mat type. This register image shall be maintained to allow readout of this in<strong>for</strong>mation by<br />
air-ground or air-air register readout. When broadcast of a <strong>for</strong>mat type ceases, the GFM shall clear the<br />
corresponding register assigned to this message.<br />
The maximum rate that can be supported by the Event-Driven protocol shall be twice per second from one or<br />
a collection of applications. For each Event-Driven <strong>for</strong>mat type being broadcast, the GFM shall retain the<br />
time of the last insertion into Register 0A16. The next insertion shall be scheduled at a r<strong>and</strong>om interval that<br />
is uni<strong>for</strong>mly distributed over the range of the update interval ±0.1 second relative to the previous insertion<br />
into Register 0A16 <strong>for</strong> this <strong>for</strong>mat type.<br />
Draft<br />
The GFM shall monitor the number of insertions scheduled in any one second interval. If more than two<br />
would occur, the GFM shall schedule the pending messages based on message priorities <strong>and</strong> queue<br />
management rules defined in §C.2.5.4.3 in order to ensure that the limit of two messages per second is<br />
observed while ensuring that high priority <strong>Extended</strong> <strong>Squitter</strong> Message as broadcast at the required rates.<br />
C.2.5.4.3 Event-Driven Message Transmission Scheduling Function<br />
The Event-Driven Message Scheduling Function shall ensure that the total Event-Driven Message rate does<br />
not exceed 2 transmitted messages per second.<br />
The Event-Driven Message Scheduling Function shall apply the following rules as a means of prioritizing the<br />
Event-Driven Message transmissions <strong>and</strong> limiting the transmission rates:<br />
a. The Event-Driven Message scheduling function shall reorder, as necessary, pending Event-Driven<br />
Messages according to the following message priorities, listed below in descending order from<br />
highest to lowest priority:<br />
(1). The broadcast of the <strong>Extended</strong> <strong>Squitter</strong> Aircraft Status Message TCAS RA Broadcast<br />
(TYPE=28, Subtype=2).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-45<br />
(2). The broadcast of the <strong>Extended</strong> <strong>Squitter</strong> Aircraft Status Message Emergency/Priority<br />
Condition (TYPE=28, Subtype=1).<br />
(3). This priority level applies as a default to any Event-Driven Message TYPE <strong>and</strong> Subtype<br />
combination not specifically identified at a higher priority level above. Event-Driven<br />
Messages of this default priority level shall be delivered to the transponder on a first-in-firstout<br />
basis at equal priority.<br />
b. The Event-Driven Message scheduling function shall limit the number of Event-Driven Messages<br />
provided to the transponder to two (2) messages per second.<br />
c. If (b) results in a queue of messages awaiting delivery to the transponder, the higher priority<br />
pending messages, according to (a) above shall be delivered to the transponder <strong>for</strong> transmission<br />
be<strong>for</strong>e lower priority messages.<br />
d. If (b) results in a queue of messages awaiting delivery to the transponder, new Event-Driven<br />
messages shall directly replace older messages of the same exact Type <strong>and</strong> Subtype (where a<br />
Subtype is defined) that are already in the pending message queue. The updated message shall<br />
maintain the same position in the message queue as the pending message that is being replaced.<br />
e. If (b) above results in a queue of messages awaiting delivery to the transponder, then pending<br />
message(s), shall be deleted from the message transmission queue if not delivered to the<br />
transponder <strong>for</strong> transmission, or not replaced with a newer message of the same message Type<br />
<strong>and</strong> Subtype, within the Message Lifetime value specified in the Table C-36 below:<br />
Table C-36. Event-Driven Message Lifetime<br />
Message<br />
Message<br />
Message Lifetime<br />
TYPE<br />
Subtype<br />
(seconds)<br />
23<br />
= 0<br />
= 1 – 7<br />
5.0 seconds (±0.2 sec.)<br />
Reserved (see Note)<br />
24 Reserved (see Note)<br />
25 Reserved (see Note)<br />
26 Reserved (see Note)<br />
27 Reserved (see Note)<br />
= 1 5.0 seconds (±0.2 sec.)<br />
28<br />
= 2<br />
24 ±1 seconds after RAT<br />
transitions from 0 to 1<br />
0 <strong>and</strong> > 2 Reserved (see Note)<br />
30 Reserved (see Note)<br />
Draft<br />
Note.— A default message lifetime of 20 seconds will be used <strong>for</strong> queue management<br />
unless otherwise specified.<br />
C.2.6 LATITUDE/LONGITUDE CODING USING COMPACT POSITION REPORTING (CPR)<br />
Notes.—<br />
C.2.6.1 PRINCIPLE OF THE CPR ALGORITHM<br />
1. The <strong>Mode</strong> S <strong>Extended</strong> <strong>Squitter</strong>s use Compact Position Reporting (CPR) to encode<br />
Latitude <strong>and</strong> Longitude efficiently into messages. The resulting messages are compact in the<br />
sense that several higher-order bits, which are normally constant <strong>for</strong> long periods of time, are not<br />
transmitted in every message. For example, in a direct binary representation of latitude, one bit<br />
would designate whether the aircraft is in the northern or southern hemisphere. This bit would<br />
remain constant <strong>for</strong> a long time, possibly the entire life of the aircraft. To repeatedly transmit this bit<br />
in every position message would be inefficient.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-46 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
2. Because the higher-order bits are not transmitted, it follows that multiple locations on the<br />
earth will produce the same encoded position. If only a single position message were received, the<br />
decoding would involve ambiguity as to which of the multiple solutions is the correct location of the<br />
aircraft. The CPR technique includes a provision to enable a receiving system to unambiguously<br />
determine the location of the aircraft. This is done by encoding in two ways that differ slightly. The<br />
two <strong>for</strong>mats, called even-<strong>for</strong>mat <strong>and</strong> odd-<strong>for</strong>mat, are each transmitted fifty percent of the time.<br />
Upon reception of both types within a short period (approximately 10 seconds <strong>for</strong> airborne <strong>for</strong>mats<br />
<strong>and</strong> 50 seconds <strong>for</strong> surface <strong>for</strong>mats), the receiving system can unambiguously determine the<br />
location of the aircraft.<br />
3. Once this process has been carried out, the higher-order bits are known at the receiving<br />
station, so subsequent single message receptions serve to unambiguously indicate the location of<br />
the aircraft as it moves.<br />
4. In certain special cases, a single reception can be decoded into the correct location<br />
without an even/odd pair. This decoding is based on the fact that the multiple locations are spaced<br />
by at least 360 NM. In addition to the correct locations, the other locations are separated by integer<br />
multiples of 360 NM to the north <strong>and</strong> south <strong>and</strong> also integer multiples of 360 NM to the east <strong>and</strong><br />
west. In a special case in which it is known that reception is impossible beyond a range of 180 NM,<br />
the nearest solution is the correct location of the aircraft.<br />
5. The parameter values in the preceding paragraph (360 <strong>and</strong> 180 NM) apply to the airborne<br />
CPR encoding. For aircraft on the surface, the CPR parameters are smaller by a factor of 4. This<br />
encoding yields better resolution but reduces the spacing of the multiple solutions.<br />
C.2.6.2 CPR ALGORITHM PARAMETERS AND INTERNAL FUNCTIONS<br />
The CPR algorithm shall utilize the following parameters whose values are set as follows <strong>for</strong> the <strong>Mode</strong> S<br />
<strong>Extended</strong> <strong>Squitter</strong> application:<br />
1. The number of bits used to encode a position coordinate, Nb, is set as follows:<br />
For airborne encoding, used in the ADS-B Airborne<br />
Position Message <strong>and</strong> the TIS-B Fine Airborne Position<br />
Nb = 17<br />
Message:<br />
For surface encoding, used in the ADS-B Surface<br />
Position Message <strong>and</strong> the TIS-B Fine Surface Position<br />
Nb = 19<br />
Message:<br />
For intent encoding: Nb = 14<br />
For TIS-B encoding, used only in the TIS-B Coarse<br />
Nb = 12<br />
Airborne Position Message:<br />
Draft<br />
Note 1.— The Nb parameter determines the encoded position precision (approximately 5 m <strong>for</strong> the<br />
airborne encoding, 1.25 m <strong>for</strong> the surface encoding, 41 m <strong>for</strong> the intent encoding <strong>and</strong> 164 m <strong>for</strong> the TIS-<br />
B encoding).<br />
2. The number of geographic latitude zones between the equator <strong>and</strong> a pole, denoted NZ, is set to 15.<br />
Note 2.— The NZ parameter determines the unambiguous airborne range <strong>for</strong> decoding (360 NM).<br />
The surface Latitude/Longitude encoding omits the high-order 2 bits of the 19-bit CPR encoding, so the<br />
effective unambiguous range <strong>for</strong> surface position reports is 90 NM.<br />
The CPR algorithm shall define internal functions to be used in the encoding <strong>and</strong> decoding processes.<br />
a. The notation floor(x) denotes the floor of x, which is defined as the greatest integer value k such<br />
that k ≤ x.<br />
Note 3.—For example, floor(3.8) = 3, while floor(-3.8) = -4.<br />
b. The notation |x| denotes the absolute value of x, which is defined as the value x when x ≥0 <strong>and</strong> the<br />
value –x when x < 0.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-47<br />
c. The notation MOD(x,y) denotes the “modulus” function, which is defined to return the value<br />
⎛ x ⎞<br />
⎝ y ⎠<br />
( x, y)<br />
= x − y ⋅floor⎜<br />
⎟<br />
MOD where y ≠ 0 .<br />
Note 4.—The value y is always positive in the following CPR algorithms. When x is non-negative,<br />
MOD(x,y) is equivalent to the remainder of x divided by y. When x represents a negative angle, an<br />
alternative way to calculate MOD(x,y) is to return the remainder of (x+360°) divided by y.<br />
For example, ( − 40°<br />
, 6°<br />
) = MOD( 320°<br />
, 6°<br />
) = 2°<br />
MOD .<br />
d. The notation NL(x) denotes the “number of longitude zones” function of the latitude angle x. The<br />
value returned by NL(x) is constrained to the range from 1 to 59. NL(x) is defined <strong>for</strong> most latitudes<br />
by the equation,<br />
NL<br />
( lat)<br />
⎛<br />
⎜ ⎡ ⎛ ⎛ π ⎞ ⎞⎤<br />
⎜ ⎢ ⎜ 1−<br />
cos⎜<br />
⎟ ⎟⎥<br />
⎜ ⎢ ⎜ ⎝ 2 ⋅ NZ<br />
= floor 2π<br />
⋅ arccos 1−<br />
⎠ ⎟⎥<br />
⎜ ⎢ ⎜ ⎛ ⎞ ⎟<br />
2 π ⎥<br />
⎜ ⎢ ⎜ cos ⎜ ⋅ lat ⎟ ⎟⎥<br />
⎝ ⎣ ⎝ ⎝180°<br />
⎠ ⎠⎦<br />
where lat denotes the latitude argument in degrees. For latitudes at or near the N or S pole, or the<br />
equator, the following points are defined:<br />
For lat = 0 (the equator), NL = 59<br />
For lat = +87 degrees, NL = 2<br />
For lat = -87 degrees, NL = 2<br />
For lat > +87 degrees, NL = 1<br />
For lat < -87 degrees, NL = 1<br />
Note 5.— This equation <strong>for</strong> NL() is impractical <strong>for</strong> a real-time implementation. A table of transition<br />
latitudes can be pre-computed using the following equation:<br />
Draft<br />
−1<br />
⎞<br />
⎟<br />
⎟<br />
,<br />
⎟<br />
⎟<br />
⎟<br />
⎠<br />
⎛<br />
⎞<br />
⎜ ⎛ π ⎞<br />
1−<br />
cos⎜<br />
⎟ ⎟<br />
180 ° ⎜ ⎝ 2 ⋅ NZ ⎠ ⎟ <strong>for</strong> NL = 2 to 4⋅NZ –1,<br />
lat = ⋅ arccos<br />
π ⎜ ⎛ 2π<br />
⎞ ⎟<br />
⎜ 1−<br />
cos ⎟<br />
⎜<br />
⎜ ⎟<br />
⎟<br />
⎝ ⎝ NL ⎠ ⎠<br />
<strong>and</strong> a table search procedure used to obtain the return value <strong>for</strong> NL( ). The table value <strong>for</strong> NL = 1<br />
is 90 degrees. When using the look up table established by using the equation above, the NL value<br />
is not expected to change to the next lower NL value until the boundary (latitude established by the<br />
above equation) has actually been crossed when moving from the equator towards the pole.<br />
C.2.6.3 CPR ENCODING PROCESS<br />
The CPR encoding process shall calculate the encoded position values XZi <strong>and</strong> YZi <strong>for</strong> either airborne,<br />
surface, intent, or TIS-B Latitude <strong>and</strong> Longitude fields from the global position lat (latitude in degrees), lon<br />
(longitude in degrees), <strong>and</strong> the CPR encoding type i (0 <strong>for</strong> even <strong>for</strong>mat <strong>and</strong> 1 <strong>for</strong> odd <strong>for</strong>mat), by per<strong>for</strong>ming<br />
the following sequence of computations. The CPR encoding <strong>for</strong> intent always uses the even <strong>for</strong>mat (i = 0),<br />
whereas the airborne, surface, <strong>and</strong> TIS-B encoding use both even (i = 0) <strong>and</strong> odd (i = 1) <strong>for</strong>mats.<br />
a. Dlati (the latitude zone size in the N-S direction) is computed from the equation:<br />
Dlat i =<br />
360°<br />
4 ⋅ NZ − i<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-48 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
b. YZi (the Y-coordinate within the Zone) is then computed from Dlati <strong>and</strong> lat using separate equations:<br />
( )<br />
For Nb = 17: YZi = floor 2 17 ⋅ MOD lat, Dlat ⎛<br />
i<br />
⎜<br />
⎝<br />
Dlat i<br />
( )<br />
For Nb = 19: YZi = floor 2 19 ⋅ MOD lat, Dlat ⎛<br />
i<br />
⎜<br />
⎝<br />
Dlat i<br />
( )<br />
For Nb = 14: YZ0 = floor 2 14 ⋅ MOD lat, Dlat ⎛<br />
0<br />
⎜<br />
⎝ Dlat0 ⎛ 12 MOD(<br />
lat,<br />
Dlat )<br />
For Nb = 12: i<br />
YZ<br />
i<br />
= floor<br />
⎜<br />
⎜2<br />
⎝<br />
⋅<br />
Dlat<br />
+ 1⎞<br />
⎟<br />
2<br />
⎟<br />
⎠<br />
+ 1⎞<br />
⎟<br />
2<br />
⎟<br />
⎠<br />
+ 1⎞<br />
⎟<br />
2<br />
⎟<br />
⎠<br />
1 ⎞<br />
+ ⎟<br />
2 ⎠<br />
c. Rlati (the latitude that a receiving ADS-B system will extract from the transmitted message) is then<br />
computed from lat, YZi, <strong>and</strong> Dlati using separate equations:<br />
For Nb = 17: Rlati = Dlati ⋅ YZ ⎛ ⎛<br />
⎜ i<br />
⎜ 17 + floor ⎜<br />
⎝ 2 ⎝<br />
For Nb = 19: Rlati = Dlati ⋅ YZ ⎛ ⎛<br />
⎜ i<br />
⎜ 19 + floor ⎜<br />
⎝ 2 ⎝<br />
For Nb = 14:<br />
For Nb = 12<br />
Rlat<br />
0<br />
Draft<br />
i<br />
lat<br />
Dlat i<br />
lat<br />
Dlat i<br />
⎞ ⎞<br />
⎟ ⎟<br />
⎟ ⎟<br />
⎠ ⎠<br />
⎞ ⎞<br />
⎟ ⎟<br />
⎟ ⎟<br />
⎠ ⎠<br />
⎛ YZ ⎛ ⎞⎞<br />
⎜ 0 lat<br />
= Dlat<br />
⎟<br />
0 ⋅<br />
⎜<br />
+ floor ⎜<br />
⎟<br />
14<br />
⎟<br />
⎝ 2 ⎝ Dlat0<br />
⎠⎠<br />
⎛ YZ ⎛ ⎞⎞<br />
⎜ i lat<br />
Rlat ⎟<br />
i = Dlati<br />
⋅<br />
⎜<br />
+ floor ⎜<br />
⎟<br />
⎟<br />
⎝ 2 ⎝ Dlati<br />
⎠⎠<br />
12<br />
d. Dloni (the longitude zone size in the E-W direction) is then computed from Rlati using the equation:<br />
360°<br />
NL( Rlati )−i Dloni =<br />
, when NL Rlat ⎧<br />
⎪<br />
( i )−i > 0<br />
⎪<br />
⎨<br />
⎪ 360°, when NL( Rlati )−i = 0<br />
⎩<br />
⎪<br />
Note.— When per<strong>for</strong>ming the NL function, the encoding process must ensure that the NL value<br />
is established in accordance with Note 5 of §C.2.6.2.d.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-49<br />
e. XZi (the X-coordinate within the Zone) is then computed from lon <strong>and</strong> Dloni using separate<br />
equations:<br />
( )<br />
For Nb = 17: XZi = floor 2 17 ⋅ MOD lon, Dlon ⎛<br />
i<br />
⎜<br />
⎝<br />
Dlon i<br />
( )<br />
For Nb = 19: XZi = floor 2 19 ⋅ MOD lon, Dlon ⎛<br />
i<br />
⎜<br />
⎝<br />
Dlon i<br />
( )<br />
For Nb = 14: XZ0 = floor 2 14 ⋅ MOD lon, Dlon ⎛<br />
0<br />
⎜<br />
⎝ Dlon0 ⎛ 12 MOD(<br />
lon,<br />
Dlon )<br />
For Nb = 12: i<br />
XZ<br />
i<br />
= floor<br />
⎜<br />
⎜2<br />
⎝<br />
⋅<br />
Dlon<br />
+ 1⎞<br />
⎟<br />
2⎠<br />
+ 1⎞<br />
⎟<br />
2⎠<br />
+ 1⎞<br />
⎟<br />
2⎠<br />
1 ⎞<br />
+<br />
⎟<br />
2 ⎠<br />
f. Finally, limit the values of XZi <strong>and</strong> YZi to fit in the 17-bit, 14-bit or 12-bit field allotted to each<br />
coordinate:<br />
For Nb = 17:<br />
YZi = MOD YZi,2 17 ( ),<br />
XZi = MOD XZi,2 17<br />
For Nb = 19:<br />
For Nb = 14:<br />
For Nb = 12:<br />
( )<br />
YZi = MOD YZi,2 17 ( ),<br />
XZi = MOD XZi,2 17<br />
( )<br />
( ),<br />
YZ0 = MOD YZ0 ,2 14<br />
XZ0 = MOD XZ 0,2 14<br />
( )<br />
YZi = MOD YZi,2 12 ( ),<br />
XZi = MOD XZi,2 12<br />
( )<br />
Draft<br />
C.2.6.4 LOCALLY UNAMBIGUOUS CPR DECODING<br />
The CPR algorithm shall decode a geographic position (latitude, Rlati, <strong>and</strong> longitude, Rloni,) that is locally<br />
unambiguous with respect to a reference point (lats, lons) known to be within 180 NM of the true airborne<br />
position (or within 45 NM <strong>for</strong> a surface message).<br />
Note.— This reference point may be a previously tracked position that has been confirmed by<br />
global decoding (§C.2.6.7) or it may be the own aircraft position, which would be used <strong>for</strong> decoding a<br />
new tentative position report.<br />
The encoded position coordinates XZ i <strong>and</strong> YZ i <strong>and</strong> the CPR encoding type i (0 <strong>for</strong> the even encoding <strong>and</strong> 1<br />
<strong>for</strong> the odd encoding) contained in a <strong>Mode</strong> S <strong>Extended</strong> <strong>Squitter</strong> message shall be decoded by per<strong>for</strong>ming<br />
the sequence of computations given in §C.2.6.5 <strong>for</strong> the airborne <strong>and</strong> intent <strong>for</strong>mat types <strong>and</strong> in §C.2.6.6 <strong>for</strong><br />
the surface <strong>for</strong>mat type.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
i
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-50 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.2.6.5 LOCALLY UNAMBIGUOUS CPR DECODING FOR AIRBORNE, TIS-B AND INTENT<br />
LAT/LON<br />
The following computations shall be per<strong>for</strong>med to obtain the decoded lat/lon <strong>for</strong> the airborne, intent, <strong>and</strong> TIS-<br />
B messages. For intent lat/lon, i is always 0 (even encoding), whereas airborne <strong>and</strong> TIS-B lat/lon use both<br />
even (i=0) <strong>and</strong> odd (i=1) encodings. For airborne lat/lon, Nb=17, <strong>for</strong> intent, Nb=14, <strong>and</strong> <strong>for</strong> TIS-B Nb=12<br />
a. Dlati is computed from the equation:<br />
Dlat i<br />
360°<br />
=<br />
4⋅<br />
NZ − i<br />
b. The latitude zone index number, j, is then computed from the values of lats, Dlati <strong>and</strong> YZi using the<br />
equation:<br />
⎛ lat ⎞<br />
s 1<br />
j = floor ⎜<br />
⎟<br />
⎝ Dlat<br />
⎟ + floor<br />
i ⎠ 2 + MOD lat ( s, Dlati )<br />
−<br />
Dlati YZi 2 Nb<br />
⎛<br />
⎞<br />
⎜<br />
⎟<br />
⎝<br />
⎠<br />
c. The decoded position latitude, Rlati, is then computed from the values of j, Dlati, <strong>and</strong> YZi using the<br />
equation:<br />
Rlati = Dlati ⋅ j + YZ ⎛ ⎞ i<br />
⎜ ⎟<br />
⎝ ⎠<br />
2 Nb<br />
d. Dloni (the longitude zone size in the E-W direction) is then computed from Rlati using the equation:<br />
⎧ 360°<br />
⎪<br />
,<br />
NL(<br />
Rlati<br />
) − i<br />
Dloni<br />
= ⎨<br />
⎪ 360°<br />
,<br />
⎪⎩<br />
when NL<br />
when NL<br />
( Rlat )<br />
i<br />
( Rlat )<br />
i<br />
− i > 0<br />
− i = 0<br />
Note.— When per<strong>for</strong>ming the NL function, the encoding process must ensure that the NL value<br />
is established in accordance with Note 5 of §C.2.6.2.d.<br />
e. The longitude zone coordinate m is then computed from the values of lons, Dloni, <strong>and</strong> XZi using the<br />
equation:<br />
⎛<br />
m = floor ⎜<br />
⎝<br />
lon s<br />
Draft<br />
Dlon i<br />
( )<br />
⎞<br />
⎟ + floor<br />
⎠<br />
1<br />
2 + MOD lon ⎛<br />
s,Dloni ⎜<br />
⎝<br />
Dlon i<br />
− XZi 2 Nb<br />
⎞<br />
⎟<br />
⎠<br />
f. The decoded position longitude, Rloni, is then computed from the values of m, XZi, <strong>and</strong> Dloni using<br />
the equation:<br />
Rloni = Dloni ⋅ m + XZ ⎛ ⎞ i<br />
⎜ ⎟<br />
⎝ ⎠<br />
C.2.6.6 LOCALLY UNAMBIGUOUS DECODING FOR SURFACE POSITION<br />
The following computations shall be per<strong>for</strong>med to obtain the decoded Latitude <strong>and</strong> Longitude <strong>for</strong> the surface<br />
position <strong>for</strong>mat.<br />
1. Dlati is computed from the equation:<br />
Dlat i<br />
90°<br />
=<br />
4 ⋅ NZ − i<br />
2. The latitude zone index, j, is then computed from the values of lats, Dlati <strong>and</strong> YZi using the equation:<br />
2 Nb<br />
( lat , Dlat )<br />
⎛ lat ⎞ ⎛<br />
⎞<br />
s 1 MOD s i YZi<br />
j = floor ⎜<br />
⎟ + floor<br />
⎜ +<br />
−<br />
⎟ 17<br />
⎝ Dlati<br />
⎠ ⎝ 2 Dlati<br />
2 ⎠<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-51<br />
3. The decoded position latitude, Rlati, is then computed from the values of j, Dlati, <strong>and</strong> YZi using the<br />
equation:<br />
Rlat<br />
i<br />
⎛ YZi<br />
= Dlati<br />
⋅⎜<br />
j + 17<br />
⎝ 2<br />
⎞<br />
⎟<br />
⎠<br />
4. Dloni (the longitude zone size, in the E-W direction) is then computed from Rlati using the equation:<br />
⎧ 90°<br />
⎪<br />
,<br />
NL(<br />
Rlati<br />
) − i<br />
Dloni<br />
= ⎨<br />
⎪ 90°<br />
,<br />
⎪⎩<br />
when NL<br />
when NL<br />
( Rlat )<br />
i<br />
( Rlat )<br />
i<br />
− i > 0<br />
− i = 0<br />
Note.— When per<strong>for</strong>ming the NL function, the encoding process must ensure that the NL value<br />
is established in accordance with Note 5 of §C.2.6.2.d.<br />
5. The longitude zone coordinate m is then computed from the values of lons, Dloni, <strong>and</strong> XZi using the<br />
equation:<br />
( lon , Dlon )<br />
⎛ lon ⎞ ⎛<br />
⎞<br />
s 1 MOD s i XZ i<br />
m = floor ⎜<br />
⎟ + floor<br />
⎜ +<br />
−<br />
⎟ 17<br />
⎝ Dloni<br />
⎠ ⎝ 2 Dloni<br />
2 ⎠<br />
6. The decoded position longitude, Rloni, is then computed from the values of m, XZi, <strong>and</strong> Dloni using<br />
the equation:<br />
⎛ XZi<br />
⎞<br />
Rlon i = Dloni<br />
⋅⎜<br />
m + 17 ⎟<br />
⎝ 2 ⎠<br />
C.2.6.7 GLOBALLY UNAMBIGUOUS AIRBORNE POSITION DECODING<br />
The CPR algorithm shall utilize one airborne-encoded “even” <strong>for</strong>mat reception (denoted XZ0, YZ0), together<br />
with one airborne-encoded “odd” <strong>for</strong>mat reception (denoted XZ1, YZ1), to regenerate the global geographic<br />
position latitude, Rlat, <strong>and</strong> longitude, Rlon. The time between the “even” <strong>and</strong> “odd” <strong>for</strong>mat encoded position<br />
reports shall be not longer than 10 seconds <strong>for</strong> airborne <strong>for</strong>mats.<br />
Notes.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Draft<br />
1. This algorithm might be used to obtain globally unambiguous position reports <strong>for</strong> aircraft out of the<br />
range of ground sensors, whose position reports are coming via satellite data links. It might also be applied<br />
to ensure that local positions are being correctly decoded over long ranges from the receiving sensor.<br />
2. The time difference limit of 10 seconds between the even- <strong>and</strong> odd-<strong>for</strong>mat position reports <strong>for</strong><br />
airborne <strong>for</strong>mats is determined by the maximum permitted separation of 3 NM. Positions greater than 3 NM<br />
apart cannot be used to solve <strong>for</strong> a unique global position. An aircraft capable of a speed of 1850 km/h<br />
(1000 kt) will fly about 5.1 km (2.8 NM) in 10 seconds. There<strong>for</strong>e, the CPR algorithm will be able to<br />
unambiguously decode its position over a 10-second delay between position reports.<br />
Given a 17-bit airborne position encoded in the “even” <strong>for</strong>mat (XZ0, YZ0) <strong>and</strong> another encoded in the “odd”<br />
<strong>for</strong>mat (XZ1, YZ1), separated by no more than 10 seconds (= 3 NM), the CPR algorithm shall regenerate the<br />
geographic position from the encoded position reports by per<strong>for</strong>ming the following sequence of steps:<br />
a. Compute Dlat0 <strong>and</strong> Dlat1 from the equation:<br />
Dlat i<br />
360°<br />
=<br />
4⋅<br />
NZ − i<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-52 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
b. Compute the latitude index:<br />
j =<br />
⎛ 59⋅<br />
YZ0<br />
− 60⋅<br />
YZ<br />
⎜<br />
⎝ 2<br />
floor 17<br />
1<br />
1 ⎞<br />
+ ⎟<br />
2 ⎠<br />
c. Compute the values of Rlat0 <strong>and</strong> Rlat1 using the following equation:<br />
Rlat<br />
i<br />
⎛<br />
YZ<br />
= Dlati<br />
⋅⎜<br />
MOD<br />
17<br />
⎝<br />
⎞<br />
i<br />
( j,<br />
60 − i)<br />
+ ⎟<br />
2 ⎠<br />
Southern hemisphere values of Rlati shall fall in the range from 270° to 360°. Subtract 360° from<br />
such values, thereby restoring Rlati to the range from −90° to +90°.<br />
d. If NL(Rlat0) is not equal to NL(Rlat1) then the two positions straddle a transition latitude—thus a<br />
solution <strong>for</strong> global longitude is not possible. Wait <strong>for</strong> positions where they are equal.<br />
Note 3.— When per<strong>for</strong>ming the NL function, the encoding process must ensure that the NL<br />
value is established in accordance with Note 5 of §C.2.6.2.d. This is more important in the Global<br />
Unambiguous Decode because large longitude errors are induced if the decode function is not<br />
selecting the NL value properly as discussed in Note 5 of §C.2.6.2.d.<br />
e. If NL(Rlat0) is equal to NL(Rlat1) then proceed with computation of Dloni, according to whether the<br />
most recently received Airborne Position Message was encoded with the even <strong>for</strong>mat (i = 0) or the<br />
odd <strong>for</strong>mat (i = 1) :<br />
Dlon i = 360°<br />
n i<br />
where n i = greater of NL(Rlat i) − i<br />
f. Compute m, the longitude index:<br />
,<br />
⎛ XZ<br />
⎜<br />
⎝<br />
⋅<br />
[ ] <strong>and</strong> 1.<br />
( NL −1)<br />
− XZ1<br />
⋅ NL 1 ⎞<br />
+ ⎟<br />
2 ⎠<br />
Draft<br />
0<br />
m = floor ,<br />
17<br />
where NL NL(<br />
Rlat )<br />
2<br />
= i .<br />
g. Compute the global longitude, Rlon0 or Rlon1, according to whether the most recently received<br />
Airborne Position Message was encoded using the even <strong>for</strong>mat (that is, with i = 0) or the odd <strong>for</strong>mat<br />
(i = 1):<br />
⎛<br />
Rloni = Dloni ⋅ ⎜ MOD m,ni ⎝<br />
⎞<br />
( )+ XZi 2 17 ⎟ ,<br />
⎠<br />
[ ] <strong>and</strong> 1.<br />
where n i = greater of NL(Rlat i) − i<br />
h. A reasonableness test shall be applied to the resulting decoded position in accordance with<br />
§C.2.6.10.2.<br />
C.2.6.8 GLOBALLY UNAMBIGUOUS CPR DECODING OF SURFACE POSITION<br />
This algorithm shall utilize one CPR surface position encoded “even” <strong>for</strong>mat message together with one<br />
CPR surface position encoded “odd” <strong>for</strong>mat message, to regenerate the geographic position of the aircraft<br />
or target.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-53<br />
As surface-<strong>for</strong>mat messages are initially received from a particular aircraft, if there is no prior history of this<br />
aircraft, then a global decode shall be per<strong>for</strong>med using “even” <strong>and</strong> “odd” <strong>for</strong>mat receptions, as described in<br />
this section.<br />
Note 1.— If the aircraft has been transmitting airborne <strong>for</strong>mat messages <strong>and</strong> their receptions were intrack,<br />
then it is not necessary to use even-odd decoding. Beginning with the first individual Surface Position<br />
Message reception, the location can be decoded using the local-decode technique, based on the previous<br />
target location as the reference.<br />
Note 2.— Even if the aircraft is appearing <strong>for</strong> the first time in surface <strong>for</strong>mat receptions, any single<br />
message could be decoded by itself into multiple locations, one being the correct location of the transmitting<br />
aircraft, <strong>and</strong> all of the others being separated by 90 NM or more from the correct location. There<strong>for</strong>e, if it<br />
were known that the transmitting aircraft cannot be farther away than 45 NM from a known location, then the<br />
first received message could be decoded using the locally unambiguous decoding method described in<br />
§C.2.6.6. Under some circumstances it may be possible <strong>for</strong> an aircraft to be first detected when it is<br />
transmitting Surface Position Messages farther than 45 NM away from the receiving station. For this reason,<br />
even-odd decoding is required when messages are initially received from a particular aircraft. After this<br />
initial decode, as subsequent messages are received, they can be decoded individually (without using the<br />
even-odd technique), provided that the intervening time is not excessive. This subsequent decoding is<br />
based on the fact that the aircraft location has not changed by more than 45 NM between each new<br />
reception <strong>and</strong> the previously decoded location.<br />
The even-odd decoding process shall begin by identifying a pair of receptions, one in the “even” <strong>for</strong>mat, the<br />
other in the “odd” <strong>for</strong>mat, <strong>and</strong> whose separation in time does not exceed the time interval of X seconds,<br />
where X=50 seconds, unless the Ground Speed in either Surface Position Message is greater than 25 knots,<br />
or is unknown, in which cases X=25 seconds.<br />
Note 3.— The limit of 25 seconds is based on the possible change of location within this time interval.<br />
Detailed analysis of CPR indicates that if the change of location is 0.75 NM or less, then the decoding will<br />
yield the correct location of the aircraft. To assure that the change of location is actually no larger, <strong>and</strong><br />
considering the maximum aircraft speed of 100 knots specified <strong>for</strong> the transmission of the surface <strong>for</strong>mat, the<br />
combination indicates that 25 seconds will provide the needed assurance. For targets on the airport surface<br />
when speeds are much less <strong>and</strong> the transmission rate is as low as one per 5 seconds, the corresponding<br />
time limit is 50 seconds.<br />
Given a CPR 17-bit surface position encoded in the “even” <strong>for</strong>mat (XZ0, YZ0) <strong>and</strong> another encoded in the<br />
“odd” <strong>for</strong>mat (XZ1, YZ1), separated by no more than X seconds, the algorithm shall regenerate the<br />
geographic position (latitude Rlat, <strong>and</strong> longitude Rlon) of the aircraft or target by per<strong>for</strong>ming the following<br />
sequence of steps:<br />
Draft<br />
a. Compute the latitude zone sizes Dlat 0 <strong>and</strong> Dlat 1 from the equation:<br />
Dlati = 90°<br />
60 − i<br />
b. Compute the latitude index:<br />
⎛ 59 ⋅YZo<br />
− 60YZ1<br />
1 ⎞<br />
j = floor⎜<br />
+ ⎟<br />
17<br />
⎝ 2 2 ⎠<br />
c. Latitude. The following <strong>for</strong>mulas will yield two mathematical solutions <strong>for</strong> latitude (<strong>for</strong> each value of<br />
i), one in the northern hemisphere <strong>and</strong> the other in the southern hemisphere. Compute the<br />
northern hemisphere solution of Rlat 0 <strong>and</strong> Rlat 1 using the following equation:<br />
⎛<br />
Rlati = Dlati⎜ MOD j,60−i<br />
⎝<br />
( )+ YZi 2 17<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
⎞<br />
⎟<br />
⎠
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-54 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
The southern hemisphere value is the above value minus 90 degrees.<br />
To determine the correct latitude of the target, it is necessary to make use of the location of the<br />
receiver. Only one of the two latitude values will be consistent with the known receiver location,<br />
<strong>and</strong> this is the correct latitude of the transmitting aircraft.<br />
d. The first step in longitude decoding is to check that the even-odd pair of messages do not straddle<br />
a transition latitude. It is rare, but possible, that NL(Rlat 0) is not equal to NL(Rlat 1). If so, a solution<br />
<strong>for</strong> longitude cannot be calculated. In this event, ab<strong>and</strong>on the decoding of this even-odd pair, <strong>and</strong><br />
examine further receptions to identify another pair. Per<strong>for</strong>m the decoding computations up to this<br />
point <strong>and</strong> check that these two NL values are equal. When that is true, proceed with the following<br />
decoding steps.<br />
Note.— When per<strong>for</strong>ming the NL function, the encoding process must ensure that the NL value<br />
is established in accordance with Note 5 of §C.2.6.2.d. This is more important in the Global<br />
Unambiguous Decode because large longitude errors are induced if the decode function is not<br />
selecting the NL value properly as discussed in Note 5 of §C.2.6.2.d.<br />
e. Compute the longitude zone size Dloni, according to whether the most recently received surface<br />
position message was encoded with the even <strong>for</strong>mat (i=0) or the odd <strong>for</strong>mat (i=1):<br />
f. Compute m, the longitude index:<br />
°<br />
Dloni<br />
=<br />
n<br />
90 , where ni is the greater of [NL(Rlati ) - i] <strong>and</strong> 1.<br />
⎛ XZ<br />
m = floor⎜<br />
⎝<br />
i<br />
where NL = NL (Rlat i )<br />
0<br />
⋅<br />
( NL −1)<br />
− XZ ⋅ NL)<br />
2<br />
17<br />
1<br />
1 ⎞<br />
+ ⎟<br />
2 ⎠<br />
g. Longitude. The following <strong>for</strong>mulas will yield four mathematical solutions <strong>for</strong> longitude (<strong>for</strong> each<br />
value of i), one being the correct longitude of the aircraft, <strong>and</strong> the other three separated by at least<br />
90 degrees. To determine the correct location of the target, it will be necessary to make use of the<br />
location of the receiver. Compute the longitude, Rlon0 or Rlon1, according to whether the most<br />
recently received surface position message was encoded using the even <strong>for</strong>mat (that is, with i=0) or<br />
the odd <strong>for</strong>mat (i=1):<br />
Draft<br />
Rloni = Dloni ⋅ MOD( m,ni)+ XZi<br />
⎛<br />
⎞<br />
⎜<br />
⎟<br />
⎝<br />
⎠<br />
2 17<br />
where n i is the greater of [NL(Rlat i ) - i] <strong>and</strong> 1.<br />
This solution <strong>for</strong> Rloni will be in the range 0° to 90°. The other three solutions are 90°, 180°, <strong>and</strong><br />
270° to the east of this first solution.<br />
h. A reasonableness test shall be applied to the resulting decoded position in accordance with<br />
§C.2.6.10.2.<br />
To then determine the correct longitude of the transmitting aircraft, it is necessary to make use of the known<br />
location of the receiver. Only one of the four mathematical solutions will be consistent with the known<br />
receiver location, <strong>and</strong> this is the correct longitude of the transmitting aircraft.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-55<br />
Note.— Near the equator the minimum distance between the multiple longitude solutions is more than<br />
5000 NM, so there is no question as to the correct longitude. For locations away from the equator, the<br />
distance between solutions is less, <strong>and</strong> varies according to the cosine of latitude. For example at 87<br />
degrees latitude, the minimum distance between solutions is 280 NM. This is sufficiently large to provide<br />
assurance that the correct aircraft location will always be obtained. Currently no airports exist within 3<br />
degrees of either pole, so the decoding as specified here will yield the correct location of the transmitting<br />
aircraft <strong>for</strong> all existing airports.<br />
C.2.6.9 CPR DECODING OF RECEIVED POSITION REPORTS<br />
C.2.6.9.1 Overview<br />
Note.— The techniques described in the preceding paragraphs (locally <strong>and</strong> globally unambiguous<br />
decoding) are used together to decode the lat/lon contained in airborne, surface intent <strong>and</strong> TIS-B position<br />
reports. The process begins with globally unambiguous decoding based upon the receipt of an even <strong>and</strong> an<br />
odd encoded position squitter. Once the globally unambiguous position is determined, the emitter centered<br />
local decoding technique is used <strong>for</strong> subsequent decoding based on a single position report, either even or<br />
odd encoding.<br />
C.2.6.9.2 Emitter Centered Local Decoding<br />
In this approach, the most recent position of the emitter shall be used as the basis <strong>for</strong> the local decoding.<br />
Note.— This produces an unambiguous decoding at each update, since the transmitting aircraft cannot<br />
move more than 360 NM between position updates.<br />
C.2.6.10 REASONABLENESS TEST FOR CPR DECODING OF RECEIVED POSITION MESSAGES<br />
C.2.6.10.1 Overview<br />
Note.— Although receptions of Position Messages will normally lead to a successful target position<br />
determination, it is necessary to safeguard against Position Messages that would be used to initiate or<br />
update a track with an erroneous position. A reasonableness test applied to the computed position resulting<br />
from receipt of a Position Message can be used to discard erroneous position updates. Since an erroneous<br />
globally unambiguous CPR decode could potentially exist <strong>for</strong> the life of a track, a reasonableness test <strong>and</strong><br />
validation of the position protects against such occurrences.<br />
Draft<br />
C.2.6.10.2 Reasonableness Test Applied to Position Determined from Globally<br />
Unambiguous Decoding<br />
A reasonableness test shall be applied to a position computed using the Globally Unambiguous CPR<br />
decoding per §C.2.6.7 <strong>for</strong> Airborne Participants, or per §C.2.6.8 <strong>for</strong> Surface Participants. Upon receipt of the<br />
“even” or “odd” encoded Position Message that completes the Globally Unambiguous CPR decode, the<br />
receiver shall per<strong>for</strong>m a reasonableness test on the position decode by per<strong>for</strong>ming the following:<br />
If the receiver position is known, calculate the distance between the decoded position <strong>and</strong> the receiver<br />
position, <strong>and</strong> verify that the distance is less than the maximum reception range of the receiver. If the<br />
validation fails, the receiver shall discard the decoded position that the “even” <strong>and</strong> “odd” Position Messages<br />
used to per<strong>for</strong>m the globally unambiguous CPR decode, <strong>and</strong> reinitiate the Globally Unambiguous CPR<br />
decode process.<br />
A further validation of the Globally Unambiguous CPR decode, passing the above test, shall be per<strong>for</strong>med<br />
by the computation of a second Globally Unambiguous CPR decode based on reception of a new “odd” <strong>and</strong><br />
an “even” Position Message as per §C.2.6.7<strong>for</strong> an Airborne Participant, or per §C.2.6.8 <strong>for</strong> a Surface<br />
Participant, both received subsequent to the respective “odd” <strong>and</strong> “even” Position Message used in the<br />
Globally Unambiguous CPR decode under validation. Upon accomplishing the additional Globally<br />
Unambiguous CPR decode, this decoded position <strong>and</strong> the position from the locally unambiguous CPR<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
C-56 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
decode resulting from the most recently received Position Message shall be checked to be identical to within<br />
5 meters <strong>for</strong> an airborne decode <strong>and</strong> 1.25 meters <strong>for</strong> a surface decode.. If the two positions are not identical<br />
to within this tolerance, the validation is failed <strong>and</strong> the initial Globally Unambiguous CPR decode under<br />
validation shall be discarded <strong>and</strong> the track shall be reinitialized.<br />
Note.— The position obtained from the initial global CPR decode is subsequently updated using local<br />
CPR decoding, until an independent ”odd” <strong>and</strong> “even” Position Message pair has been received. When this<br />
occurs, a second global CPR decode is per<strong>for</strong>med. The resulting position is compared to the position<br />
update obtained from the local CPR decode using the most recently received Position Message. These two<br />
positions should agree since they are computed from the same message.<br />
C.2.6.10.3 Reasonableness Test Applied to Position Determined from Locally<br />
Unambiguous Decoding<br />
A reasonableness test shall be applied to a position computed using the Locally Unambiguous CPR<br />
decoding per §C.2.6.5 <strong>for</strong> Airborne, TIS-B or Intent Participants, or per §C.2.6.6 <strong>for</strong> Surface Participants.<br />
Upon receipt of the “even” or “odd” encoded Position Message that completes the Locally Unambiguous<br />
CPR decode, the receiver shall per<strong>for</strong>m a reasonableness test on the most recently received position<br />
decode by per<strong>for</strong>ming the following test:<br />
If the difference between the TOMRs of the previously received Position Message <strong>and</strong> the most recently<br />
received Position Message is 30 seconds or less, <strong>and</strong> the difference in the reported position in the most<br />
recently received Position Message is greater than or equal to X NM,<br />
where:<br />
X=6 <strong>for</strong> Airborne Participants receiving Airborne Position Messages, or<br />
X=2.5 <strong>for</strong> Airborne Participants that have received a Surface Position Message, or<br />
X=2.5 <strong>for</strong> Surface Participants that have received an Airborne Position Message, or<br />
X=0.75 <strong>for</strong> Surface Participants receiving Surface Position Messages,<br />
then the validation shall be considered failed, <strong>and</strong>:<br />
1) the most recently received position shall not be used to update the track, <strong>and</strong><br />
2) the received position shall be used to initiate or update a c<strong>and</strong>idate duplicate address track or<br />
update a duplicate address track in accordance with §C.2.6.10.4.<br />
Notes.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Draft<br />
1. If no duplicate address or c<strong>and</strong>idate duplicate address Report exists <strong>for</strong> this ICAO 24-bit<br />
address, the position message is used to initiate a c<strong>and</strong>idate duplicate address Report. If a c<strong>and</strong>idate<br />
duplicate address Report exists, the position message is used to update the c<strong>and</strong>idate duplicate<br />
address Report. Otherwise, the position message is used to update the duplicate address Report<br />
unless the position message fails this validation test (see §C.2.6.10.4).<br />
2. The position threshold value is based on the assumption of a maximum aircraft velocity of V<br />
knots (where V=600 <strong>for</strong> Airborne <strong>and</strong> V=50 <strong>for</strong> Surface) over a maximum time period of 30 seconds.<br />
This yields a maximum positional difference of approximately 5 NM <strong>for</strong> Airborne, <strong>and</strong> 0.5 NM <strong>for</strong><br />
Surface. An additional measure of 1 NM <strong>for</strong> Airborne, <strong>and</strong> 0.25 NM <strong>for</strong> Surface are added to account<br />
<strong>for</strong> additional ADS-B positional measurement uncertainty. The position threshold of 2.5 nautical miles<br />
between surface <strong>and</strong> airborne participants was derived from the assumption of 250 knots maximum<br />
speed <strong>for</strong> a target transitioning from the surface state to an airborne state over 30 seconds, yielding<br />
approximately 2 nautical miles, with an additional 0.5 NM being added to allow <strong>for</strong> positional errors.<br />
C.2.6.10.4 Duplicate Address Processing<br />
The ICAO 24-bit address transmitted in each ADS-B Message <strong>and</strong> the derived Address Qualifier is used to<br />
identify <strong>and</strong> associate the messages <strong>for</strong> a particular aircraft/vehicle. Though each aircraft/vehicle should<br />
have a unique ICAO 24-bit address, there may be occasions on which more than one aircraft/vehicle is<br />
transmitting the same ICAO 24 bit address. It is important <strong>for</strong> ADS-B applications that receive 1090ES ADS-<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-57<br />
B Reports to have knowledge of aircraft within receiving range. The requirements in the following<br />
subparagraphs enable detection of a duplicate address aircraft/vehicle when horizontal position separation is<br />
outside of the local CPR reasonableness test criteria of §C.2.6.10.3.<br />
Notes.—<br />
1. Without duplicate address detection, an aircraft/vehicle that enters the range of the receiver<br />
with the same ICAO 24-bit address as that of an existing ADS-B Report would go undetected <strong>and</strong><br />
message data from the undetected aircraft/vehicle could be erroneously associated with the existing<br />
ADS-B Report.<br />
2. Duplicate Address processing is not required <strong>for</strong> TIS-B targets. The assumption is that the<br />
ADS-B Ground Stations will protect against any Duplicate Address situation.<br />
C.2.6.10.4.1 C<strong>and</strong>idate Duplicate Address Report<br />
A c<strong>and</strong>idate duplicate address Report shall be initiated when a position message is received <strong>for</strong> an ICAO 24bit<br />
address that fails the local CPR reasonableness test validation of §C.2.6.10.3 <strong>and</strong> no c<strong>and</strong>idate duplicate<br />
address Report or duplicate address Report is currently active <strong>for</strong> the received ICAO 24-bit address. If<br />
initiated, the c<strong>and</strong>idate duplicate address Report is set to Initialization State as per RTCA DO-260B,<br />
§2.2.10.2 <strong>and</strong> the position message is stored <strong>for</strong> this c<strong>and</strong>idate duplicate address Report. The ADS-B<br />
Report <strong>for</strong> which the position message did not pass the validation test of §C.2.6.10.3, the local CPR<br />
reasonableness test, is the primary ADS-B Report <strong>for</strong> this ICAO 24-bit address. Once a c<strong>and</strong>idate duplicate<br />
address Report is initiated, association of subsequent position messages with this ICAO 24-bit address shall<br />
be first attempted on the primary ADS-B Report <strong>for</strong> this ICAO 24-bit address. If the position message does<br />
not pass the validation test of §C.2.6.10.3 on the primary ADS-B Report, the position message shall be used<br />
to attempt Track Initialization on the c<strong>and</strong>idate duplicate address Report as per RTCA DO-260B, §2.2.10.2.<br />
Notes.—<br />
1. TIS-B Reports <strong>and</strong> ADS-R Reports are separate <strong>and</strong> distinct from ADS-B Reports as per §C.3 <strong>and</strong><br />
§C.4, so there is no duplicate address issues between these Report types <strong>and</strong> ADS-B Reports.<br />
2. Inter-source correlation is addressed in RTCA DO-317.<br />
Draft<br />
C.2.6.10.4.2 Duplicate Address Condition<br />
A duplicate address condition shall be declared <strong>for</strong> an ICAO 24-bit address when a global CPR decode is<br />
completed by the receipt of both an even <strong>and</strong> odd position message within 10 seconds <strong>for</strong> the c<strong>and</strong>idate<br />
duplicate address <strong>and</strong> passes the global CPR reasonableness test. Once declared, a duplicate address<br />
condition shall result in the Duplicate Address Flag in the State Vector Report set to “ON” in the ADS-B<br />
Report upon output of either ADS-B Report in the duplicate address condition. ADS-B Position Messages<br />
shall be associated with the ADS-B Report in the duplicate address condition that passes the local CPR<br />
reasonableness test in §C.2.6.10.3. Each ADS-B Report in the duplicate address condition shall be updated<br />
upon receipt of other <strong>Extended</strong> <strong>Squitter</strong> Messages containing the duplicate ICAO 24-bit address since there<br />
is no means to associate these messages with the correct aircraft.<br />
ADS-B Position, Velocity, Aircraft Identification <strong>and</strong> Category <strong>and</strong> Emergency / Priority Status (Subtype=1)<br />
Messages from aircraft/vehicles with ICAO 24-bit addresses identified as Duplicate Addresses shall be<br />
processed as Version ZERO (0) <strong>for</strong>mat Messages. Since Target State <strong>and</strong> Status Messages can be<br />
associated with the appropriate MOPS Version Number based on the Subtype, <strong>and</strong> Operational Status<br />
Messages contain the MOPS Version Number, these messages can be decoded directly.<br />
Notes.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1. The Duplicate Address Flag is used to indicate to ADS-B applications that in<strong>for</strong>mation associated<br />
with that address can not be correctly associated with either ADS-B Report in the duplicate address<br />
condition. Additionally, the correct MOPS Version Number <strong>for</strong> each of the aircraft/vehicles can not be readily<br />
determined so interpretation of message data defaults to Version ZERO (0).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-58 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
2. The update <strong>and</strong> output of both ADS-B Reports when <strong>Extended</strong> <strong>Squitter</strong> Messages are received<br />
with the duplicate ICAO 24-bit address results in additional overhead since output of both ADS-B Reports<br />
possibly occurs upon message reception. However, this approach gives ADS-B applications the ability to<br />
associate in<strong>for</strong>mation with the correct ADS-B Report if they choose to attempt to correlate using the<br />
additional provided in<strong>for</strong>mation.<br />
The duplicate address condition shall be cleared after 60 seconds has elapsed with no Position Message<br />
update <strong>for</strong> a Participant with an ADS-B Report identified in the duplicate address condition. The relevant<br />
ADS-B Report <strong>for</strong> the Participant shall be deleted from the Report Output Storage Buffer. Output of the<br />
remaining ADS-B Report shall contain a State Vector Report with the Duplicate Address Flag set to “OFF”.<br />
Note.— After clearing the duplicate address condition, the ADS-B Report <strong>for</strong> the aircraft/vehicle that<br />
continues to receive Position Messages that pass the local CPR reasonableness test, as well as other<br />
1090ES ADS-B Messages, is retained <strong>and</strong> updated as per RTCA DO-260B, §2.2.10.4.<br />
C.2.6.10.4.3 Duplicate Address Report Capacity<br />
The ADS-B Receiving Subsystem shall be capable of maintaining <strong>and</strong> processing a minimum of three<br />
concurrent duplicate address Reports.<br />
Note.— The required capacity includes duplicate address Reports from both ADS-B <strong>and</strong> ADS-R targets.<br />
Since duplicate address situations are expected to be infrequent events, the ability to h<strong>and</strong>le three duplicate<br />
address Reports is expected to be sufficient.<br />
C.2.7 FORMATS FOR EXTENDED SQUITTER<br />
The <strong>Extended</strong> <strong>Squitter</strong> messages shall be <strong>for</strong>matted as defined in the following tables.<br />
Note.— In some cases, ARINC 429 labels are referenced <strong>for</strong> specific message fields. These references<br />
are only intended to clarify the field content, <strong>and</strong> are not intended as a requirement to use these ARINC 429<br />
labels as the source <strong>for</strong> the message field.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-59<br />
Register 0516<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Figure C-1. <strong>Extended</strong> <strong>Squitter</strong> Airborne Position<br />
1<br />
2<br />
Purpose: To provide accurate airborne position in<strong>for</strong>mation.<br />
3 FORMAT TYPE CODE<br />
4 (§C.2.3.1) Surveillance Status Coding<br />
5 0 = no condition in<strong>for</strong>mation<br />
6<br />
7<br />
SURVEILLANCE STATUS<br />
1 = permanent alert (emergency condition)<br />
2 = temporary alert (change in <strong>Mode</strong> A identity code other<br />
8 NIC SUPPLEMENT-B (§C.2.3.2.5) than emergency condition<br />
9<br />
10<br />
3 = SPI condition<br />
11 ALTITUDE Codes 1 <strong>and</strong> 2 take precedence over code 3.<br />
12 Specified by the Format TYPE Code<br />
13<br />
14 (1) the altitude code (AC) as specified in §2.2.13.1.2 of<br />
15 DO-181D (EUROCAE ED-73C §3.17.1.b), but with<br />
16 the M-bit removed (Ref ARINC 429 Label 203), or<br />
17<br />
18 (2) GNSS Height (HAE) (Ref. ARINC 429 Label 370)<br />
19<br />
20<br />
21 TIME (T) (§C.2.3.2.2)<br />
22 CPR FORMAT (F) (§C.2.3.2.1)<br />
23 MSB<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29<br />
30 CPR ENCODED LATITUDE<br />
31<br />
32 (CPR Airborne Format §C.2.6.1 to §C.2.6.10)<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39 LSB<br />
40 MSB<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
47 CPR ENCODED LONGITUDE<br />
48<br />
49 (CPR Airborne Format §C.2.6.1 to §C.2.6.10)<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56 LSB<br />
Note.— When horizontal position in<strong>for</strong>mation is unavailable,<br />
but altitude in<strong>for</strong>mation is available, the Airborne<br />
Position Message is transmitted with a Format TYPE<br />
Code of ZERO in bits 1-5 <strong>and</strong> the barometric<br />
pressure altitude in bits 9 to 20. If neither horizontal<br />
position nor barometric altitude in<strong>for</strong>mation is<br />
available, then all 56 bits of Register 0516 are<br />
ZEROed. The ZERO Format TYPE Code field<br />
indicates that Latitude <strong>and</strong> Longitude in<strong>for</strong>mation is<br />
unavailable, while the ZERO altitude field indicates<br />
that altitude in<strong>for</strong>mation is unavailable.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
C-60 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Register 0616<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Figure C-2. <strong>Extended</strong> <strong>Squitter</strong> Surface Position<br />
1<br />
2<br />
Purpose: To provide accurate surface position in<strong>for</strong>mation.<br />
3 FORMAT TYPE CODE<br />
4<br />
5<br />
(§C.2.3.1)<br />
6 MOVEMENT<br />
7 Coding Meaning Quantization<br />
8 0 No Movement Info Available<br />
9 MOVEMENT 1 A/C Stopped (GS = 0 knots)<br />
10 (§C.2.3.3.1) 2 0 knots < GS ≤ 0.125 knot<br />
11 3 – 8 0.125 knots < GS ≤ 1.0 knot 0.2700833 km/h<br />
12 9 – 12 1.0 knots < GS ≤ 2.0 knots 0.25 knot steps<br />
13 STATUS <strong>for</strong> Heading/Ground Track (1 = valid, 0 = not valid) 13 – 38 2 knots < GS ≤ 15.0 knots 0.50 knot steps<br />
14 MSB 39 – 93 15.0 knots < GS ≤ 70.0 knots 1.00 knot steps<br />
15 94 – 108 70.0 knots < GS ≤ 100.0 knots 2.00 knot steps<br />
16 HEADING/GROUND TRACK (7 bits) 109 – 123 100.0 knots < GS ≤ 175.0 knots 5.00 knot steps<br />
17 (§C.2.3.3.2) 124 175.0 knots < GS<br />
18 Resolution = 360/128 degrees 125 Reserved <strong>for</strong> A/C Decelerating<br />
19 126 Reserved <strong>for</strong> A/C Acelerating<br />
20 LSB 127 Reserved <strong>for</strong> A/C Backing Up<br />
21 TIME (T) (§C.2.3.2.2)<br />
22 CPR FORMAT (F) (§C.2.3.2.1)<br />
23<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29<br />
MSB<br />
30<br />
31<br />
CPR ENCODED LATITUDE<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
(CPR Surface Format §C.2.6.1 to §C.2.6.10)<br />
39 LSB<br />
40<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
MSB<br />
47<br />
48<br />
CPR ENCODED LONGITUDE<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
(CPR Surface Format §C.2.6.1 to §C.2.6.10)<br />
56 LSB<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-61<br />
Register 0716<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Figure C-3. <strong>Extended</strong> <strong>Squitter</strong> Status<br />
1<br />
2<br />
TRANSMISSION RATE SUBFIELD (TRS)<br />
Purpose: To provide in<strong>for</strong>mation on the capability <strong>and</strong> status<br />
of the <strong>Extended</strong> <strong>Squitter</strong> rate of the transponder.<br />
3<br />
4<br />
ALTITUDE TYPE SUBFIELD (ATS)<br />
5 Transmission Rate Subfield (TRS) coding:<br />
6 0 = No capability to determine surface squitter rate<br />
7 1 = High surface squitter rate selected<br />
8 2 = Low surface squitter rate selected<br />
9<br />
10<br />
11<br />
3 = Reserved<br />
12 Altitude Type Subfield (ATS) coding:<br />
13 0 = Barometric altitude<br />
14<br />
15<br />
16<br />
1 = GNSS Height (HAE), ARINC 429 Label 370<br />
17<br />
Note.— Aircraft determination of surface squitter rate. For<br />
18<br />
19<br />
20<br />
21<br />
22<br />
aircraft that have the capability to automatically<br />
determine their surface squitter rate, the method that<br />
must be used to switch between the high <strong>and</strong> low<br />
transmission rates is as follows:<br />
23<br />
a) Switching from high to low rate: Aircraft must<br />
24<br />
switch from high to low rate when the onboard<br />
25<br />
navigation unit reports that the aircraft’s position<br />
26<br />
27<br />
has not changed more than 10 meters in any 30<br />
second interval.<br />
28 RESERVED<br />
29<br />
b) Switching from low to high rate: Aircraft must<br />
30<br />
31<br />
32<br />
33<br />
switch from low to high rate as soon as the<br />
aircraft’s position has changed by 10 meters, or<br />
more since the low rate was selected.<br />
34<br />
In all cases, the automatically selected transmission<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
47<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56<br />
rate is subject to being overridden by comm<strong>and</strong>s<br />
received from ground control.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
C-62 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Register 0816<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Figure C-4. <strong>Extended</strong> <strong>Squitter</strong> Identification <strong>and</strong> Category<br />
1<br />
2<br />
Purpose: To provide aircraft identification <strong>and</strong> category.<br />
3 FORMAT TYPE CODE<br />
4 (§C.2.3.1) TYPE Coding:<br />
5 1 = Aircraft identification, Category Set D<br />
6 2 = Aircraft identification, Category Set C<br />
7 AIRCRAFT EMITTER CATEGORY 3 = Aircraft identification, Category Set B<br />
8 4 = Aircraft identification, Category Set A<br />
9<br />
10<br />
MSB<br />
11<br />
12<br />
CHARACTER 1 ADS-B Aircraft Emitter Category coding:<br />
13 Set A<br />
14 LSB 0 = No ADS-B Emitter Category In<strong>for</strong>mation<br />
15 MSB 1 = Light (< 15500 lbs)<br />
16 2 = Small (15500 to 75000 lbs)<br />
17 CHARACTER 2 3 = Large (75000 to 300000 lbs)<br />
18 4 = High Vortex Large (aircraft such as B-757)<br />
19 5 = Heavy (> 300000 lbs)<br />
20 LSB 6 = High Per<strong>for</strong>mance (> 5g acceleration <strong>and</strong> 400 kts)<br />
21<br />
22<br />
MSB 7 = Rotorcraft<br />
23 CHARACTER 3<br />
24 Set B<br />
25 0 = No ADS-B Emitter Category In<strong>for</strong>mation<br />
26 LSB 1 = Glider / sailplane<br />
27 MSB 2 = Lighter-than-air<br />
28 3 = Parachutist / Skydiver<br />
29 CHARACTER 4 4 = Ultralight / hang-glider / paraglider<br />
30 5 = Reserved<br />
31 6 = Unmanned Aerial Vehicle<br />
32 LSB 7 = Space / Trans-atmospheric vehicle<br />
33<br />
34<br />
MSB<br />
35 CHARACTER 5 Set C<br />
36 0 = No ADS-B Emitter Category In<strong>for</strong>mation<br />
37 1 = Surface Vehicle – Emergency Vehicle<br />
38 LSB 2 = Surface Vehicle – Service Vehicle<br />
39 MSB 3 = Point Obstacle (includes tethered balloons)<br />
40 4 = Cluster Obstacle<br />
41 CHARACTER 6 5 = Line Obstacle<br />
42 6 = Reserved<br />
43 7 = Reserved<br />
44 LSB<br />
45 MSB<br />
46 Set D (Reserved)<br />
47<br />
48<br />
CHARACTER 7<br />
49 Aircraft Identification coding:<br />
50 LSB Character coding as specified in §C.2.3.4.<br />
51<br />
52<br />
MSB<br />
53<br />
54<br />
55<br />
CHARACTER 8<br />
56 LSB<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-63<br />
Register 0916<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Figure C-5. <strong>Extended</strong> <strong>Squitter</strong> Airborne Velocity<br />
(Subtypes 1 <strong>and</strong> 2: Velocity Over Ground)<br />
1 MSB 1 Purpose: To provide additional state in<strong>for</strong>mation <strong>for</strong> both<br />
2 0 normal <strong>and</strong> supersonic flight.<br />
3 FORMAT TYPE CODE = 19 0<br />
4 (§C.2.3.1) 1<br />
5 LSB 1 Subtype Coding:<br />
6 Subtype 1 0 Subtype 2 0<br />
7 0 1 Code Velocity Type<br />
8 1 0 0 Reserved<br />
9 INTENT CHANGE FLAG (§C.2.3.5.3) 1 Ground Normal<br />
10 RESERVED-A 2 Speed Supersonic<br />
11<br />
12<br />
13<br />
NAVIGATION ACCURACY CATEGORY FOR VELOCITY<br />
(NACV) (§C.2.3.5.4)<br />
3<br />
4<br />
5<br />
Airspeed, Normal<br />
Heading Supersonic<br />
Not AssignedReserved<br />
14 DIRECTION BIT <strong>for</strong> E-W Velocity (0=East, 1=West) 6 Not AssignedReserved<br />
15 EAST-WEST VELOCITY (10 bits) 7 Not AssignedReserved<br />
16 NORMAL : LSB = 1 knot SUPERSONIC : LSB = 4 knots<br />
17 All zeros = no velocity info All zeros = no velocity info<br />
18 Value Velocity Value Velocity Reference ARINC Labels <strong>for</strong> Velocity:<br />
19 1 0 kts 1 0 kts East - West North - South<br />
20 2 1 kt 2 4 kts GPS: 174 GPS: 166<br />
21 3 2 kts 3 8 kts INS: 367 INS: 366<br />
22 --- --- --- ---<br />
23 1022 1021 kts 1022 4084 kts<br />
24 1023 >1021.5 kts 1023 > 4086 kts Reference ARINC Labels:<br />
25 DIRECTION BIT <strong>for</strong> N-S Velocity (0=North, 1=South) GNSS Height (HAE): GPS 370<br />
26 NORTH – SOUTH VELOCITY (10 bits) GNSS Altitude (MSL): GPS: 076<br />
27 NORMAL : LSB = 1 knot SUPERSONIC : LSB = 4 knots<br />
28 All zeros = no velocity info All zeros = no velocity info<br />
29 Value Velocity Value Velocity<br />
30 1 0 kts 1 0 kts<br />
31 2 1 kt 2 4 kts<br />
32 3 2 kts 3 8 kts<br />
33 --- --- --- ---<br />
34 1022 1021 kts 1022 4084 kts<br />
35 1023 > 1021.5 kts 1023 > 4086 kts<br />
36 SOURCE BIT FOR VERTICAL RATE (0=Geometric, 1=Baro)<br />
37 SIGN BIT FOR VERTICAL RATE (0=Up, 1=Down)<br />
38 VERTICAL RATE (9 bits)<br />
39 All zeros – no vertical rate info, LSB = 64 feet/min<br />
40 Value Vertical Rate Reference<br />
41 1 0 ft/min ARINC 429 labels<br />
42 2 64 ft/min GPS: 165<br />
43 --- --- INS: 365<br />
44 510 32576 ft/min<br />
45<br />
46<br />
511 > 32608 ft/min<br />
47<br />
48<br />
RESERVED-B<br />
49 DIFFERENCE SIGN BIT (0 = Above Baro, 1 = Below Baro Alt)<br />
50<br />
GEOMETRIC HEIGHT DIFFERENCE FROM BARO ALT.<br />
(7 bits) (§C.2.3.5.6) (All zeros = no info) (LSB = 25 feet)<br />
51 Value Difference<br />
52 1 0 feet<br />
53 2 25 feet<br />
54 --- ---<br />
55 126 3125 feet<br />
56 127 > 3137.5 feet<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
C-64 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Register 0916<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Figure C-6. <strong>Extended</strong> <strong>Squitter</strong> Airborne Velocity<br />
(Subtypes 3 <strong>and</strong> 4: Airspeed <strong>and</strong> Heading)<br />
1 MSB 1 Purpose: To provide additional state in<strong>for</strong>mation <strong>for</strong> both<br />
2 0 normal <strong>and</strong> supersonic flight based on airspeed <strong>and</strong> heading.<br />
3 FORMAT TYPE CODE = 19 0<br />
4 (§C.2.3.1) 1<br />
5 LSB 1<br />
Note.— This <strong>for</strong>mat is only used if velocity over ground is not<br />
6 Subtype 3 0 Subtype 4 1<br />
available.<br />
7 1 0<br />
8 1 0<br />
9 INTENT CHANGE FLAG (§C.2.3.5.3) Subtype Coding:<br />
10 RESERVED-A<br />
11<br />
12<br />
13<br />
NAVIGATION ACCURACY CATEGORY FOR VELOCITY<br />
(NACV) (§C.2.3.5.4)<br />
Code<br />
0<br />
1<br />
Velocity Type<br />
Reserved<br />
Ground Normal<br />
14 STATUS BIT (1 = Heading available, 0 = Not available) 2 Speed Supersonic<br />
15 MSB 3 Airspeed, Normal<br />
16 4 Heading Supersonic<br />
17 5 Not AssignedReserved<br />
18 HEADING (10 bits) 6 Not AssignedReserved<br />
19 (§C.2.3.5.5) 7 Not AssignedReserved<br />
20<br />
21<br />
Resolution = 360/1024 degrees<br />
22 Reference ARINC Label<br />
23 INS: 320 Reference ARINC 429 Labels<br />
24 LSB <strong>for</strong> Air Data Source:<br />
25 AIRSPEED TYPE (0 = IAS, 1 = TAS) IAS: 206<br />
26 AIRSPEED (10 bits) TAS: 210<br />
27 NORMAL: LSB = 1 knot SUPERSONIC: LSB = 4 knots<br />
28 All zeros = no velocity info All zeros = no velocity info<br />
29 Value Velocity Value Velocity Reference ARINC Labels:<br />
30 1 0 kts 1 0 kts GNSS Height (HAE): GPS 370<br />
31 2 1 kt 2 4 kts GNSS Altitude (MSL): GPS: 076<br />
32 3 2 kts 3 8 kts<br />
33 --- --- --- ---<br />
34 1022 1021 kts 1022 4084 kts<br />
35 1023 > 1021.5 kts 1023 > 4086 kts<br />
36 SOURCE BIT FOR VERTICAL RATE (0=Geo, 1=Baro)<br />
37 SIGN BIT FOR VERTICAL RATE (0=Up, 1=Down)<br />
38 VERTICAL RATE (9 bits)<br />
39 All zeros – no vertical rate in<strong>for</strong>mation<br />
40 LSB = 64 feet/min<br />
41 Value Vertical Rate Reference<br />
42 1 0 ft/min ARINC Labels<br />
43 2 64 ft/min GPS: 165<br />
44 --- --- INS: 365<br />
45 510 32576 ft/min<br />
46 511 > 32608 ft/min<br />
47<br />
48<br />
RESERVED-B<br />
49 DIFFERENCE SIGN BIT (0 = Above Baro, 1 = Below Baro Alt)<br />
50<br />
GEOMETRIC HEIGHT DIFFERENCE FROM BARO ALT<br />
(7 bits) (§C.2.3.5.6) (All zeros = no info) (LSB = 25 feet)<br />
51 Value Vertical Rate<br />
52 1 0 ft<br />
53 2 25 ft<br />
54 --- ---<br />
55 126 3125 ft<br />
56 127 > 3137.5 ft<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-65<br />
Register 0A16<br />
Figure C-7. <strong>Extended</strong> <strong>Squitter</strong> Event-Driven Register<br />
1 Purpose: To provide a flexible means to squitter messages<br />
2<br />
3<br />
4<br />
other than position, velocity <strong>and</strong> identification.<br />
5<br />
Note.—The data in this register is not intended <strong>for</strong> extraction using<br />
6<br />
GICB or ACAS cross-link protocols. The read out of this<br />
7<br />
register is discouraged since the contents are<br />
8<br />
9<br />
10<br />
11<br />
12<br />
13<br />
14<br />
15<br />
16<br />
17<br />
18<br />
19<br />
20<br />
21<br />
22<br />
23<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29<br />
30<br />
31<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
47<br />
48<br />
49<br />
50<br />
indeterminate.<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
C-66 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Register 6116<br />
Figure C-8a. <strong>Extended</strong> <strong>Squitter</strong> Aircraft Status<br />
(Subtype 1: Emergency/Priority Status <strong>and</strong> <strong>Mode</strong> A Code)<br />
1<br />
2<br />
MSB PURPOSE: To provide additional in<strong>for</strong>mation on aircraft status.<br />
3 FORMAT TYPE CODE = 28<br />
4 (§C.2.3.1) Subtype shall be coded as follows:<br />
5 LSB<br />
6 MSB 0 = No in<strong>for</strong>mation<br />
7 SUBTYPE CODE = 1 1 = Emergency/Priority Status <strong>and</strong> <strong>Mode</strong> A Code<br />
8 LSB 2 = TCAS RA Broadcast<br />
9 MSB 3 to 7 = Reserved<br />
10 EMERGENCY STATE<br />
11 LSB Emergency state shall be coded as follows:<br />
12 MSB<br />
13 Value Meaning<br />
14 0 No emergency<br />
15 1 General emergency<br />
16 2 Lifeguard/Medical<br />
17 MODE A (4096) CODE 3 Minimum fuel<br />
18 (§C.2.3.7.3) 4 No communications<br />
19 5 Unlawful interference<br />
20 6 Downed aircraft<br />
21<br />
22<br />
7 Reserved<br />
23 Notes.—<br />
24 LSB 1) Message delivery is accomplished using the Event-Driven<br />
25<br />
26<br />
Protocol as specified in §C.2.3.7.3.1.<br />
27 2) Termination of emergency state is detected by coding in the<br />
28<br />
29<br />
surveillance status field of the Airborne Position Message.<br />
30 3) Subtype 2 message broadcasts take priority over Subtype 1<br />
31<br />
32<br />
message broadcasts.<br />
33 4) Emergency State value 1 is set when <strong>Mode</strong> A code 7700 is<br />
34<br />
35<br />
provided to the transponder.<br />
36 5) Emergency State value 4 is set when <strong>Mode</strong> A code 7600 is<br />
37<br />
38<br />
provided to the transponder.<br />
39 6) Emergency State value 5 is set when <strong>Mode</strong> A code 7500 is<br />
40<br />
41<br />
RESERVED provided to the transponder.<br />
42 7) The <strong>Mode</strong> A code shall be coded as defined in ICAO Annex<br />
43<br />
44<br />
10, Volume IV, §3.1.2.6.7.1.<br />
45<br />
Note.—The data in this register is not intended <strong>for</strong> extraction<br />
46<br />
using GICB or ACAS cross-link protocols. The read out of this<br />
47<br />
48<br />
49<br />
50<br />
51<br />
register is discouraged since the contents are indeterminate.<br />
52<br />
53<br />
54<br />
55<br />
56<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-67<br />
Figure C-8b. <strong>Extended</strong> <strong>Squitter</strong> Aircraft Status<br />
(Subtype 2: 1090ES TCAS RA Broadcast)<br />
Register 6116<br />
1 MSB PURPOSE: To report resolution advisories (RAs) generated by<br />
2 TCAS equipment.<br />
3 FORMAT TYPE CODE = 28<br />
4 Subtype Coding:<br />
5 LSB<br />
6 MSB 0 = No in<strong>for</strong>mation<br />
7 Subtype CODE = 2 1 = Emergency/Priority Status<br />
8 LSB 2 = TCAS RA Broadcast<br />
9<br />
10<br />
MSB 3 to 7 = Reserved<br />
11<br />
12<br />
TCAS RA Broadcast Coding:<br />
13 The coding of bits 9 to 56 of this Message con<strong>for</strong>ms to the<br />
14 corresponding bits of Register 3016 as specified in Annex 10,<br />
15<br />
16<br />
ACTIVE RESOLUTION ADVISORIES Volume IV, §4.3.8.4.2.2.<br />
17<br />
18<br />
Notes.—<br />
19 1) Message delivery is accomplished once per 0.8 seconds<br />
20<br />
21<br />
using the event-driven protocol.<br />
22 LSB 2) RA Broadcast begins within 0.5 seconds after transponder<br />
23 MSB notification of the initiation of an TCAS RA.<br />
24 RACs RECORD<br />
25 3) RA Broadcast is terminated 24 ±1 seconds after the RAT flag<br />
26 LSB (Annex 10, Volume IV, §4.3.8.4.2.2.1.3) transitions from<br />
27 RA TERMINATED ZERO (0) to ONE (1).<br />
28 MULTIPLE THREAT ENCOUNTER<br />
29 MSB THREAT – TYPE INDICATOR 4) Subtype 2 message broadcasts take priority over subtype 1<br />
30 LSB message broadcasts.<br />
31<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40<br />
41<br />
42<br />
MSB<br />
43<br />
44<br />
45<br />
46<br />
47<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
THREAT IDENTITY DATA<br />
56 LSB<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-68 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Figure C-9. Target State <strong>and</strong> Status In<strong>for</strong>mation<br />
(Subtype = 1: Compatible with ADS-B Version Number=2)<br />
Register 6216<br />
1 PURPOSE: To provide aircraft state <strong>and</strong> status<br />
2 in<strong>for</strong>mation.<br />
3<br />
4<br />
5<br />
FORMAT TYPE CODE = 29<br />
6 MSB SUBTYPE CODE = 1<br />
7 LSB<br />
8 SIL SUPPLEMENT (0=Per Hour, 1=Per Sample)<br />
9 SELECTED ALTITUDE TYPE (0=MCP/FCU, 1=FMS)<br />
10 MSB = 32768 feet<br />
11 MCP / FCU SELECTED ALTITUDE<br />
12 (when Selected Altitude Type = 0)<br />
13 FMS SELECTED ALTITUDE<br />
14 (when Selected Altitude Type = 1)<br />
15 Coding: 111 1111 1111 = 65472 feet<br />
16 *** **** ****<br />
17 000 0000 0010 = 32 feet<br />
18 000 0000 0001 = 0 feet<br />
19 000 0000 0000 = No data or Invalid<br />
20 LSB = 32 feet<br />
21 MSB = 204.8 millibars<br />
22 BAROMETRIC PRESSURE SETTING (MINUS 800 millibars)<br />
23 Range = [0, 408.0] Resolution = 0.8 millibars<br />
24 Coding: 1 1111 1111 = 408.00 millibars<br />
25 * **** ****<br />
26 0 0000 0010 = 0.800 millibars<br />
27 0 0000 0001 = 0.000 millibars<br />
28 0 0000 0000 = No Data or Invalid<br />
29 LSB = 0.8 millibars<br />
30 STATUS (0=Invalid, 1=Valid)<br />
31 Sign (0=Positive, 1=Negative)<br />
32<br />
33<br />
MSB = 90.0 degrees<br />
34 SELECTED HEADING<br />
35 Range = [+/- 180] degrees, Resolution = 0.703125 degrees<br />
36<br />
37<br />
38<br />
(Typical Selected Heading Label = “101”)<br />
39 LSB = 0.703125 degrees (180/256)<br />
40 MSB<br />
41 NAVIGATION ACCURACY CATEGORY FOR POSITION (NACP)<br />
42 (§C.2.3.9.9)<br />
43 LSB<br />
44 NAVIGATION INTEGRITY CATEGORY FOR BARO (NICBARO)<br />
45<br />
46<br />
MSB<br />
LSB<br />
SOURCE INTEGRITY LEVEL (SIL)<br />
47 STATUS OF MCP / FCU MODE BITS (0 = Invalid, 1 = Valid)<br />
48 AUTOPILOT ENGAGED (0 = Not Engaged, 1 = Engaged)<br />
49 VNAV MODE ENGAGED (0 = Not Engaged, 1 = Engaged)<br />
50 ALTITUDE HOLD MODE (0 = Not Engaged, 1 = Engaged)<br />
51 Reserved <strong>for</strong> ADS-R Flag<br />
52 APPROACH MODE (0 = Not Engaged, 1 = Engaged)<br />
53 TCAS OPERATIONAL (0 = Not Operational, 1 = Operational)<br />
54 LNAV MODE (0 = Not Engaged, 1 = Engaged)<br />
55<br />
56<br />
MSB<br />
LSB<br />
RESERVED<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-69<br />
Register 6516<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Figure C-10. Aircraft Operational Status<br />
1 MSB PURPOSE: To provide the capability class <strong>and</strong> current operational<br />
2 mode of ATC-related applications <strong>and</strong> other operational in<strong>for</strong>mation..<br />
3 FORMAT TYPE CODE = 31<br />
4<br />
5 LSB Subtype Coding:<br />
6 MSB MSB<br />
7 SUBTYPE CODE = 0 SUBTYPE CODE = 1 0 = Airborne Status Message<br />
8 LSB LSB 1 = Surface Status Message<br />
9 MSB MSB 2 – 7 = Reserved<br />
10<br />
11<br />
12<br />
13<br />
14 AIRBORNE SURFACE<br />
15 CAPABILITY CLASS (CC) CAPABILITY CLASS (CC)<br />
16 CODES CODES<br />
17 (§C.2.3.10.3) (§C.2.3.10.3)<br />
18<br />
19<br />
20 LSB<br />
21 MSB<br />
22 LENGTH/WIDTH CODES<br />
23 (§C.2.3.10.11)<br />
24 LSB LSB<br />
25 MSB MSB<br />
26<br />
27<br />
28<br />
29<br />
30 AIRBORNE SURFACE<br />
31 OPERATIONAL OPERATIONAL<br />
32 MODE (OM) CODES MODE (OM) CODES<br />
33 (§C.2.3.10.4) (§C.2.3.10.4)<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39<br />
40 LSB LSB<br />
41 MSB<br />
42 VERSION NUMBER (§C.2.3.10.5)<br />
43 LSB<br />
44 NIC SUPPLEMENT-A (§C.2.3.10.6)<br />
45 MSB<br />
46 NAVIGATIONAL ACCURACY CATEGORY – POSITION<br />
47 (NACP) (§C.2.3.10.7)<br />
48 LSB<br />
49 MSB GVA RESERVED<br />
50 LSB (§C.2.3.10.8)<br />
51 MSB SOURCE INTEGRITY LEVEL (SIL)<br />
52 LSB (§C.2.3.10.9)<br />
53 NICBARO (§C.2.3.10.10) TRK/HDG (§C.2.3.10.12)<br />
54 HRD (§C.2.3.10.13)<br />
55 SIL SUPPLEMENT (§C.2.3.10.15)<br />
56 RESERVED <strong>for</strong> ADS-R<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
C-70 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.3 Traffic In<strong>for</strong>mation <strong>Services</strong> – Broadcast (TIS-B) Formats <strong>and</strong><br />
Coding<br />
Notes.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C.3.1 INTRODUCTION<br />
1. This section defines the <strong>for</strong>mats <strong>and</strong> coding <strong>for</strong> a Traffic In<strong>for</strong>mation Service Broadcast (TIS-B)<br />
based on the same 112-bit 1090 MHz signal transmission that is used <strong>for</strong> ADS-B on 1090 MHz.<br />
2. TIS-B complements the operation of ADS-B by providing ground-to-air broadcast of<br />
surveillance data on aircraft that are not equipped <strong>for</strong> 1090 MHz ADS-B. The basis <strong>for</strong> this ground<br />
surveillance data may be an ATC <strong>Mode</strong> S radar, a surface or approach multi-lateration system or a<br />
multi-sensor data processing system. The TIS-B ground-to-air transmissions use the same signal<br />
<strong>for</strong>mats as 1090 MHz ADS-B <strong>and</strong> can there<strong>for</strong>e be accepted by a 1090 MHz ADS-B receiver.<br />
3. TIS-B data content on the 1090 MHz signal does not include all of the parameters, such as the<br />
System Design Assurance (SDA) <strong>and</strong> the SIL Supplement, which are normally associated with ADS-B<br />
transmissions from aircraft. Those parameters that are not broadcast will need to be provided by the<br />
TIS-B Service Provider.<br />
4. TIS-B service is the means <strong>for</strong> providing a complete surveillance picture to 1090 MHz ADS-B<br />
users during a transition period. After transition, it also provides a means to cope with a user that has<br />
lost its 1090 MHz ADS-B capability, or is broadcasting incorrect in<strong>for</strong>mation.<br />
C.3.2 TIS-B FORMAT DEFINITION<br />
TIS-B in<strong>for</strong>mation shall be broadcast using the 112-bit <strong>Mode</strong> S DF=18 <strong>for</strong>mat as shown below in Figure C-<br />
11.<br />
TIS-B Format Definition<br />
Bit # 1 ----- 5 6 --- 8 9 ----- 32 33 --------------------------- 88 89 ---- 112<br />
DF=18 DF CF AA<br />
“ME”<br />
PI<br />
Field [5] [3] [24]<br />
[56]<br />
[24]<br />
Names 10010<br />
MSB MSB MSB MSB MSB<br />
LSB LSB LSB LSB LSB<br />
Draft<br />
Figure C-11. TIS-B Format Definition<br />
C.3.3 CONTROL FIELD ALLOCATION<br />
The content of the DF=18 transmission shall be defined by the value of the control field, as specified in Table<br />
C-37.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix C C-71<br />
Table C-37. CF Field Code Definitions in DF=18 ADS-B <strong>and</strong> TIS-B Messages<br />
CF<br />
Value<br />
ICAO/<strong>Mode</strong> A<br />
Flag (IMF)<br />
Meaning<br />
0 N/A<br />
ADS-B Message from a non-transponder device,<br />
AA field holds 24-bit ICAO aircraft address<br />
1 N/A<br />
Reserved <strong>for</strong> ADS-B Message in which the AA field holds anonymous<br />
address or ground vehicle address or fixed obstruction address<br />
0<br />
Fine TIS-B Message,<br />
AA field contains the 24-bit ICAO aircraft address<br />
2<br />
Fine TIS-B Message,<br />
1 AA field contains the 12-bit <strong>Mode</strong> A code followed by a 12-bit track file<br />
number<br />
0<br />
Coarse TIS-B Airborne Position <strong>and</strong> Velocity Message,<br />
AA field contains the 24-bit ICAO aircraft address<br />
3<br />
Coarse TIS-B Airborne Position <strong>and</strong> Velocity Message,<br />
1 AA field contains the 12-bit <strong>Mode</strong> A code followed by a 12-bit track file<br />
number.<br />
4 N/A<br />
TIS-B <strong>and</strong> ADS-R Management Message<br />
AA field contains TIS-B/ADS-R management in<strong>for</strong>mation.<br />
5<br />
0<br />
Fine TIS-B Message<br />
AA field contains a non-ICAO 24-bit address<br />
1 Reserved<br />
0<br />
Rebroadcast of ADS-B Message from an alternate data link<br />
AA field holds 24-bit ICAO aircraft address<br />
6<br />
Rebroadcast of ADS-B Message from an alternate data link<br />
1 AA field holds anonymous address or ground vehicle address or fixed<br />
obstruction address<br />
7 N/A Reserved<br />
C.3.4 TIS-B SURVEILLANCE MESSAGE DEFINITION<br />
C.3.4.1 TIS-B FINE AIRBORNE POSITION MESSAGE<br />
The TIS-B fine airborne position “ME” field shall be <strong>for</strong>matted as specified in Figure C-12, <strong>and</strong> described in<br />
the following paragraphs.<br />
Draft<br />
C.3.4.1.1 ICAO/<strong>Mode</strong> A Flag (IMF)<br />
This one-bit field (bit 8) shall indicate the type of identity associated with the aircraft data reported in the TIS-<br />
B message. IMF equal to ZERO (0) shall indicate that the TIS-B data is identified by an ICAO 24-bit<br />
address. IMF equal to ONE (1) shall indicate that the TIS-B data is identified by a “<strong>Mode</strong> A” code. A TIS-B<br />
report on a primary radar target shall indicate a “<strong>Mode</strong> A” code of ALL ZEROs.<br />
Notes.—<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1. The AA field is coded differently <strong>for</strong> 24-bit addresses <strong>and</strong> <strong>Mode</strong> A codes as specified in Table<br />
C-24.<br />
2. A target with a ZERO “<strong>Mode</strong> A” code <strong>and</strong> a reported altitude is an SSR target.<br />
C.3.4.1.2 Pressure Altitude<br />
This 12-bit field shall provide the aircraft pressure altitude. This field shall contain barometric altitude<br />
encoded in 25 or 100-foot increments (as indicated by the Q Bit). ALL ZEROs in this field shall indicate that<br />
there is no altitude data.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-72 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.3.4.1.3 Compact Position Reporting (CPR) Format (F)<br />
This field shall be set as specified in §C.2.3.2.1.<br />
C.3.4.1.4 Latitude/Longitude<br />
The Latitude/Longitude fields in the TIS-B fine Airborne Position Message shall be set as specified in<br />
§C.2.3.2.3.<br />
C.3.4.2 TIS-B SURFACE POSITION MESSAGE<br />
The TIS-B surface position “ME” field shall be <strong>for</strong>matted as specified in Figure C-13, <strong>and</strong> described in the<br />
following paragraphs.<br />
This field shall be set as specified in §C.2.3.3.1.<br />
This field shall be set as specified in §C.2.3.3.2.1.<br />
This field shall be set as specified in §C.2.3.3.2.2.<br />
C.3.4.2.1 Movement<br />
C.3.4.2.1.1 Ground Track (True)<br />
C.3.4.2.1.1.1 Ground Track Status<br />
C.3.4.2.1.1.2 Ground Track Angle<br />
C.3.4.2.1.2 ICAO/<strong>Mode</strong> A Flag (IMF)<br />
This one-bit field (bit 21) shall indicate the type of identity associated with the aircraft data reported in the<br />
TIS-B message. Coding is specified in §C.3.4.1.1.<br />
C.3.4.2.1.3 Compact Position Reporting (CPR) Format (F)<br />
This field shall be set as specified in §C.2.3.3.3.<br />
Draft<br />
C.3.4.2.1.4 Latitude/Longitude<br />
The Latitude/Longitude fields in the TIS-B Fine Surface Position Message shall be set as specified in<br />
§C.2.3.3.5.<br />
C.3.4.3 IDENTIFICATION AND CATEGORY MESSAGE<br />
The TIS-B Identification <strong>and</strong> Category “ME” field shall be <strong>for</strong>matted as specified in Figure C-14, <strong>and</strong><br />
described in the following paragraphs. This message shall only be used <strong>for</strong> aircraft identified with an ICAO<br />
24-bit address.<br />
This field shall be set as specified in §C.2.3.4.1.<br />
C.3.4.3.1 Aircraft Identification Coding<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-73<br />
C.3.4.4 VELOCITY MESSAGE<br />
The TIS-B Velocity “ME” field shall be <strong>for</strong>matted as specified in the Figure C-15, <strong>and</strong> described in the<br />
following paragraphs, <strong>for</strong> Subtypes 1 <strong>and</strong> 2, <strong>and</strong> in Figure C-16 <strong>for</strong> Subtypes 3 <strong>and</strong> 4.<br />
C.3.4.4.1 Subtype Field<br />
Subtypes 1 through 4 shall be used <strong>for</strong> the TIS-B Velocity Message. Subtype 1 shall be used <strong>for</strong> velocities<br />
over ground under 1000 knots <strong>and</strong> Subtype 2 shall be used <strong>for</strong> aircraft capable of supersonic flight when the<br />
velocity over ground might exceed 1022 knots.<br />
The supersonic version of the velocity coding shall be used if either the East-West OR North-South velocities<br />
exceed 1022 knots. A switch to the normal velocity coding shall be made if both the East-West AND North-<br />
South velocities drop below 1000 knots.<br />
Subtypes 3 <strong>and</strong> 4 shall be used when Airspeed <strong>and</strong> Heading are substituted <strong>for</strong> velocity over ground.<br />
Subtype 3 shall be used at subsonic airspeeds, while Subtype 4 shall be used <strong>for</strong> aircraft capable of<br />
supersonic flight when the Airspeed might exceed 1022 knots.<br />
The supersonic version of the Airspeed coding shall be used if the Airspeed exceeds 1022 knots. A switch<br />
to the normal Airspeed coding shall be made if the Airspeed drops below 1000 knots.<br />
C.3.4.4.2 ICAO/<strong>Mode</strong> A Flag (IMF)<br />
This one-bit field (bit 9) shall indicate the type of identity associated with the aircraft data reported in the TIS-<br />
B message. Coding is specified in §C.3.4.1.1.<br />
C.3.4.5 COARSE AIRBORNE POSITION MESSAGE<br />
The TIS-B coarse airborne position “ME” field shall be <strong>for</strong>matted as specified in Figure C-17, <strong>and</strong> described<br />
in the following paragraphs.<br />
Note.— This message is used if the surveillance source <strong>for</strong> TIS-B is not of high enough quality to justify<br />
the use of the fine <strong>for</strong>mats. An example of such a source is a scanning beam <strong>Mode</strong> S interrogator.<br />
C.3.4.5.1 ICAO/<strong>Mode</strong> A Flag (IMF)<br />
Draft<br />
This one-bit field (bit 1) shall indicate the type of identity associated with the aircraft data reported in the TIS-<br />
B message. Coding is specified in §C.3.4.1.1.<br />
C.3.4.5.2 Service Volume ID (SVID)<br />
The 4-bit SVID field shall identify the TIS-B site that delivered the surveillance data.<br />
Note.— In the case where TIS-B messages are being received from more than one TIS-B ground<br />
stations, the SVID can be used to select coarse messages from a single source. This will prevent the TIS-B<br />
track from w<strong>and</strong>ering due to the different error biases associated with different sources.<br />
C.3.4.5.3 Pressure Altitude<br />
This 12-bit field shall provide the aircraft pressure altitude. This field shall contain barometric altitude<br />
encoded in 25 or 100-foot increments (as indicated by the Q Bit).<br />
C.3.4.5.4 Ground Track Status<br />
This one bit (“ME” bit 20) field shall define the validity of the ground track value. Coding <strong>for</strong> this field shall be<br />
as follows: 0=not valid <strong>and</strong> 1= valid.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-74 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.3.4.5.5 Ground Track Angle<br />
This 5-bit (“ME” bits 21 – 25) field shall define the direction (in degrees clockwise from true north) of aircraft<br />
motion. The ground track shall be encoded as an unsigned angular weighted binary numeral, with an MSB<br />
of 180 degrees <strong>and</strong> an LSB of 360/32 degrees, with ZERO (0) indicating true north. The data in the field<br />
shall be rounded to the nearest multiple of 360/32 degrees.<br />
C.3.4.5.6 Ground Speed<br />
This 6-bit (“ME” bits 26 – 31) field shall define the aircraft speed over the ground. Coding of this field shall<br />
be as specified in Table C-38.<br />
Table C-38. TIS-B Aircraft Speed Over-the-Ground<br />
Coding<br />
Meaning<br />
(Binary) (Decimal)<br />
(Ground Speed in knots)<br />
00 0000 0 No Ground Speed in<strong>for</strong>mation available<br />
00 0001 1 Ground Speed < 16 knots<br />
00 0010 2 16 knots ≤ GS < 48 knots<br />
00 0011 3 48 knots ≤ GS < 80 knots<br />
*** *** ***<br />
11 1110 62 1936 knots ≤ GS < 1968 knots<br />
11 1111 63 GS ≥ 1968 knots<br />
Notes.—<br />
1. The encoding shown in the table represents Positive Magnitude data only.<br />
2. Raw data used to establish the Ground Speed Subfield will normally have more resolution (i.e., more<br />
bits) than that required by the Ground Speed Subfield. When converting such data to the Ground<br />
Speed Subfield, the accuracy of the data must be maintained such that it is not worse than ±½ LSB<br />
where the LSB is that of the Ground Speed Subfield.<br />
C.3.4.5.7 Latitude/Longitude<br />
The Latitude/Longitude fields in the TIS-B Coarse Airborne Position Message shall be set as specified in<br />
§C.2.3.2.3, except that the 12-bit <strong>for</strong>m of CPR coding shall be used.<br />
Draft<br />
C.3.5 TIS-B AND ADS-R MANAGEMENT MESSAGES<br />
The TIS-B/ADS-R Management Messages shall use <strong>Extended</strong> <strong>Squitter</strong> <strong>for</strong>mat DF=18 <strong>and</strong> CF=4 to provide<br />
in<strong>for</strong>mation related to the provision of the TIS-B <strong>and</strong>/or ADS-R Service Volume in the specific airspace being<br />
serviced by the local ground broadcast site(s).<br />
The TIS-B/ADS-R Management Message shall be used to provide a specific announcement of the Service<br />
Volume <strong>and</strong> the service availability in local airspace where the TIS-B <strong>and</strong>/or ADS-R service is being<br />
supported by the ground infrastructure.<br />
C.3.6 TIS-B REPORT GENERATION<br />
The in<strong>for</strong>mation received in TIS-B Messages shall be reported directly to applications, with one exception.<br />
The exception is latitude-longitude position in<strong>for</strong>mation, which is CPR-encoded when it is received, <strong>and</strong> must<br />
be decoded be<strong>for</strong>e reporting. In order to accomplish CPR decoding, it is necessary to track received<br />
messages, so that even-<strong>for</strong>mat <strong>and</strong> odd-<strong>for</strong>mat messages can be combined to determine the latitude <strong>and</strong><br />
longitude of the target.<br />
In the most common case, a particular target will result in TIS-B Message receptions or ADS-B Message<br />
receptions, but not both. It is possible, however, <strong>for</strong> both types of messages to be received <strong>for</strong> a single<br />
target. If this happens, the TIS-B in<strong>for</strong>mation is processed <strong>and</strong> reported independently of the ADS-B<br />
receptions <strong>and</strong> reporting.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-75<br />
As TIS-B Messages are received, the in<strong>for</strong>mation is reported to applications. All received in<strong>for</strong>mation<br />
elements, other than position, shall be reported directly, including all reserved fields <strong>for</strong> the TIS-B fine <strong>for</strong>mat<br />
messages <strong>and</strong> the entire message content (i.e., including the complete 88-bit content of the DF, CF, AA <strong>and</strong><br />
“ME” fields of the <strong>Extended</strong> <strong>Squitter</strong> Message) of any received TIS-B Management Message (Table C-37,<br />
<strong>for</strong> CF=4). The reporting <strong>for</strong>mat is not specified in detail, except that the in<strong>for</strong>mation content shall be the<br />
same as the in<strong>for</strong>mation content received. The report shall be issued within 0.5 seconds of the message<br />
reception.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-76 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.3.7 FORMATS FOR 1090 MHZ TIS-B MESSAGES<br />
Figure C-12. TIS-B Fine Airborne Position Message<br />
1 Purpose: To provide airborne position in<strong>for</strong>mation <strong>for</strong><br />
2 aircraft that are not equipped with 1090 MHz ADS-B<br />
3 FORMAT TYPE CODE service is based on high quality surveillance data.<br />
4<br />
5<br />
(See §C.2.3.1 <strong>and</strong> Note 1)<br />
6 MSB SURVEILLANCE STATUS Surveillance Status coding:<br />
7 LSB 0 = no condition in<strong>for</strong>mation<br />
8 IMF (§C.3.4.1.1) 1 = permanent alert (emergency condition)<br />
9 2 = temporary alert (change in <strong>Mode</strong> A identity code other than<br />
10 emergency condition)<br />
11<br />
12<br />
3 = SPI condition<br />
13 PRESURE ALTITUDE<br />
14<br />
15<br />
Codes 1 <strong>and</strong> 2 take precedence over code 3.<br />
16 The altitude code (AC) as specified in §2.2.13.1.2 of<br />
17 DO-181D (EUROCAE ED-73C, §3.17.1.b),<br />
18<br />
19<br />
20<br />
but with the M-bit removed.<br />
21 RESERVED<br />
22 CPR FORMAT (F) (§C.2.3.2.1)<br />
23<br />
24<br />
25<br />
26<br />
27<br />
28<br />
MSB<br />
29 CPR ENCODED LATITUDE<br />
30 CPR Airborne Format<br />
31<br />
32<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
(§C.2.6.1 to §C.2.6.10)<br />
39 LSB<br />
40<br />
41<br />
42<br />
43<br />
44<br />
45<br />
MSB<br />
46 CPR ENCODED LONGITUDE<br />
47 CPR Airborne Format<br />
48<br />
49<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
(§C.2.6.1 to §C.2.6.10)<br />
56 LSB<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-77<br />
Figure C-13. TIS-B Fine Surface Position Message<br />
1 Purpose: To provide surface position in<strong>for</strong>mation <strong>for</strong><br />
2 aircraft that are not equipped with 1090 MHz ADS-B.<br />
3 FORMAT TYPE CODE<br />
4 (§C.2.3.1)<br />
5<br />
6<br />
7<br />
8<br />
9 MOVEMENT<br />
10 (§C.2.3.3.1)<br />
11<br />
12<br />
13 STATUS <strong>for</strong> Heading/Ground Track (1=valid, 0=not valid)<br />
14 MSB<br />
15<br />
16 HEADING / GROUND TRACK (7 bits)<br />
17 (Referenced to true north)<br />
18 Resolution = 360/128 degrees<br />
19<br />
20 LSB<br />
21 IMF (§C.3.4.2.1.2)<br />
22 CPR FORMAT (F) (§C.2.3.2.1)<br />
23 MSB<br />
24<br />
25<br />
26<br />
27<br />
28<br />
29<br />
30 CPR ENCODED LATITUDE<br />
31 CPR Surface Format<br />
32 (§C.2.6.1 to §C.2.6.10)<br />
33<br />
34<br />
35<br />
36<br />
37<br />
38<br />
39 LSB<br />
40 MSB<br />
41<br />
42<br />
43<br />
44<br />
45<br />
46<br />
47 CPR ENCODED LONGITUDE<br />
48 CPR Surface Format<br />
49 (§C.2.6.1 to §C.2.6.10)<br />
50<br />
51<br />
52<br />
53<br />
54<br />
55<br />
56 LSB<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-78 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Figure C-14. TIS-B Identification <strong>and</strong> Category Message<br />
1 Purpose: To provide aircraft identification <strong>and</strong> category <strong>for</strong><br />
2 aircraft that are not equipped with 1090 MHz ADS-B.<br />
3 FORMAT TYPE CODE<br />
4 (§C.2.3.1)<br />
5 TYPE Coding:<br />
6 1 = Aircraft identification, Category Set D<br />
7 AIRCRAFT EMITTER CATEGORY 2 = Aircraft identification, Category Set C<br />
8 3 = Aircraft identification, Category Set B<br />
9<br />
10<br />
MSB 4 = Aircraft identification, Category Set A<br />
11 CHARACTER 1<br />
12<br />
13<br />
ADS-B Aircraft Emitter Category coding:<br />
14 LSB Set A<br />
15 MSB 0 = No ADS-B Emitter Category In<strong>for</strong>mation<br />
16 1 = Light (< 15500 lbs)<br />
17 CHARACTER 2 2 = Small (15500 to 75000 lbs)<br />
18 3 = Large (75000 to 300000 lbs)<br />
19 4 = High Vortex Large (aircraft such as B-757)<br />
20 LSB 5 = Heavy (> 300000 lbs)<br />
21 MSB 6 = High Per<strong>for</strong>mance (> 5g acceleration <strong>and</strong> 400 kts)<br />
22 7 = Rotorcraft<br />
23<br />
24<br />
CHARACTER 3<br />
25 Set B<br />
26 LSB 0 = No ADS-B Emitter Category In<strong>for</strong>mation<br />
27 MSB 1 = Glider / sailplane<br />
28 2 = Lighter-than-air<br />
29 CHARACTER 4 3 = Parachutist / Skydiver<br />
30 4 = Ultralight / hang-glider / paraglider<br />
31 5 = Reserved<br />
32 LSB 6 = Unmanned Aerial Vehicle<br />
33<br />
34<br />
MSB 7 = Space / Trans-atmospheric vehicle<br />
35 CHARACTER 5<br />
36 Set C<br />
37 0 = No ADS-B Emitter Category In<strong>for</strong>mation<br />
38 LSB 1 = Surface Vehicle – Emergency Vehicle<br />
39 MSB 2 = Surface Vehicle – Service Vehicle<br />
40 3 = Point Obstacle (includes tethered balloons)<br />
41 CHARACTER 6 4 = Cluster Obstacle<br />
42 5 = Line Obstacle<br />
43 6 = Reserved<br />
44 LSB 7 = Reserved<br />
45<br />
46<br />
MSB<br />
47 CHARACTER 7 Set D<br />
48<br />
49<br />
(Reserved)<br />
50 LSB Aircraft Identification coding:<br />
51<br />
52<br />
MSB Character coding as specified in §C.2.3.4.<br />
53<br />
54<br />
55<br />
CHARACTER 8<br />
56 LSB<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-79<br />
Figure C-15. TIS-B Velocity Messages<br />
(Subtypes 1 <strong>and</strong> 2: Velocity Over Ground)<br />
1 MSB 1 Purpose: To provide velocity in<strong>for</strong>mation <strong>for</strong> aircraft that<br />
2 0 are not equipped with 1090 MHz ADS-B when the TIS-B<br />
3 FORMAT TYPE CODE = 19 0 service is based on high quality surveillance data.<br />
4 1<br />
5 LSB 1 Subtype Coding:<br />
6 Subtype 1 0 Subtype 2 0<br />
7 0 1 Code Velocity Type<br />
8 1 0 1 Ground Normal<br />
9 IMF (§C.3.4.4.2) 2 Speed Supersonic<br />
10 MSB<br />
11 NAVIGATION ACCURACY CATEGORY FOR POSITION<br />
12 (NACP) (§C.2.3.10.7)<br />
Note.— The “Vertical Rate” <strong>and</strong> “Geometric Height<br />
13<br />
14<br />
15<br />
LSB<br />
DIRECTION BIT <strong>for</strong> E-W Velocity (0=East, 1=West)<br />
EAST-WEST VELOCITY (10 bits)<br />
Difference From Barometric” fields <strong>for</strong> surface<br />
aircraft do not need to be processed by TIS-B<br />
receivers.<br />
16 NORMAL : LSB = 1 knot SUPERSONIC : LSB = 4 knots<br />
17 All zeros = no velocity info All zeros = no velocity info<br />
18 Value Velocity Value Velocity<br />
19 1 0 kts 1 0 kts<br />
20 2 1 kt 2 4 kts<br />
21 3 2 kts 3 8 kts<br />
22 --- --- --- ---<br />
23 1022 1021 kts 1022 4084 kts<br />
24 1023 >1021.5 kts 1023 > 4086 kts<br />
25 DIRECTION BIT <strong>for</strong> N-S Velocity (0=North, 1=South)<br />
26 NORTH – SOUTH VELOCITY (10 bits)<br />
27 NORMAL : LSB = 1 knot SUPERSONIC : LSB = 4 knots<br />
28 All zeros = no velocity info All zeros = no velocity info<br />
29 Value Velocity Value Velocity<br />
30 1 0 kts 1 0 kts<br />
31 2 1 kt 2 4 kts<br />
32 3 2 kts 3 8 kts<br />
33 --- --- --- ---<br />
34 1022 1021 kts 1022 4084 kts<br />
35 1023 > 1021.5 kts 1023 > 4086 kts<br />
36 GEO FLAG BIT (1 bit) (GEO = 0) GEO FLAG BIT (1 bit) (GEO = 1)<br />
37 SIGN BIT FOR VERTICAL RATE (0=Up, 1=Down) SIGN BIT FOR VERTICAL RATE (0=Up, 1=Down)<br />
38 VERTICAL RATE (9 bits) VERTICAL RATE (9 bits)<br />
39 All zeros – no vertical rate info, LSB = 64 feet/min All zeros – no vertical rate info, LSB = 64 feet/min<br />
40 Value Vertical Rate Value Vertical Rate<br />
41 1 0 ft/min 1 0 ft/min<br />
42 2 64 ft/min 2 64 ft/min<br />
43 --- --- --- ---<br />
44 510 32576 ft/min 510 32576 ft/min<br />
45<br />
46<br />
511 > 32608 ft/min 511 > 32608 ft/min<br />
47 NIC SUPPLEMENT-A (§C.2.3.10.6) NIC SUPPLEMENT-A (§C.2.3.10.6)<br />
48 RESERVED (1 bit)<br />
49 NAVIGATION ACCURACY CATEGORY FOR VELOCITY DIFFERENCE SIGN BIT (0 = Above Baro, 1 = Below Baro Alt)<br />
50<br />
(NACV) (§C.2.3.5.4)<br />
GEOMETRIC HEIGHT DIFFERENCE FROM BARO ALT.<br />
(7 bits) (§C.2.3.5.6) (All zeros = no info) (LSB = 25 feet)<br />
51 SOURCE INTEGRITY LEVEL (SIL) Value Difference<br />
52 (§C.2.3.10.9) 1 0 feet<br />
53 2 25 feet<br />
54 RESERVED (4 bits) --- ---<br />
55 126 3125 feet<br />
56 127 > 3137.5 feet<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-80 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Figure C-16. TIS-B Velocity Messages<br />
(Subtypes 3 <strong>and</strong> 4: Air Referenced Velocity)<br />
1 MSB 1 Purpose: To provide velocity in<strong>for</strong>mation <strong>for</strong> aircraft that<br />
2 0 are not equipped with 1090 MHz ADS-B when the TIS-B<br />
3 FORMAT TYPE CODE = 19 0 service is based on high quality surveillance data.<br />
4 1<br />
5 LSB 1<br />
6 Subtype 3 0 Subtype 4 1<br />
7 1 0<br />
8 1 0<br />
9<br />
10<br />
IMF (§C.3.4.4.2) Subtype Coding:<br />
11<br />
12<br />
13<br />
NAVIGATION ACCURACY CATEGORY FOR POSITION<br />
(NACP) (§C.2.3.10.7)<br />
Code<br />
3<br />
4<br />
Velocity<br />
Airspeed,<br />
Heading<br />
Type<br />
Normal<br />
Supersonic<br />
14 HEADING STATUS BIT (1=Available, 0=Not Available)<br />
15 MSB<br />
16<br />
Note.— The “Vertical Rate” <strong>and</strong> “Geometric Height<br />
17<br />
Difference From Barometric” fields <strong>for</strong> surface<br />
18 HEADING (10 bits)<br />
aircraft do not need to be processed by TIS-B<br />
19 (§C.2.3.5.5)<br />
receivers<br />
20<br />
21<br />
22<br />
23<br />
Resolution = 360/1024 degrees<br />
24 LSB<br />
25 AIRSPEED TYPE (0=IAS, 1=TAS)<br />
26 AIRSPEED (10 bits)<br />
27 NORMAL: LSB = 1 knot SUPERSONIC: LSB = 4 knots<br />
28 All zeros = no velocity info All zeros = no velocity info<br />
29 Value Velocity Value Velocity<br />
30 1 0 kts 1 0 kts<br />
31 2 1 kt 2 4 kts<br />
32 3 2 kts 3 8 kts<br />
33 --- --- --- ---<br />
34 1022 1021 kts 1022 4084 kts<br />
35 1023 > 1021.5 kts 1023 > 4086 kts<br />
36 GEO FLAG Bit (GEO=0) GEO FLAG Bit (GEO=1)<br />
37 SIGN BIT FOR VERTICAL RATE (0=Up, 1=Down) SIGN BIT FOR VERTICAL RATE (0=Up, 1=Down)<br />
38 VERTICAL RATE (9 bits) VERTICAL RATE (9 bits)<br />
39 All zeros – no vertical rate in<strong>for</strong>mation All zeros – no vertical rate in<strong>for</strong>mation<br />
40 LSB = 64 feet/min LSB = 64 feet/min<br />
41 Value Vertical Rate Value Vertical Rate<br />
42 1 0 ft/min 1 0 ft/min<br />
43 2 64 ft/min 2 64 ft/min<br />
44 --- --- --- ---<br />
45 510 32576 ft/min 510 32576 ft/min<br />
46 511 > 32608 ft/min 511 > 32608 ft/min<br />
47 NIC SUPPLEMENT-A (§C.2.3.10.6) NIC SUPPLEMENT-A (§C.2.3.10.6)<br />
48 RESERVED (1 bit)<br />
49 NAVIGATION ACCURACY CATEGORY FOR VELOCITY DIFFERENCE SIGN BIT (0 = Above Baro, 1 = Below Baro Alt)<br />
50<br />
(NACV) (§C.2.3.5.4) GEOMETRIC HEIGHT DIFFERENCE FROM BARO ALT<br />
(7 bits) (§C.2.3.5.6) (All zeros = no info) (LSB = 25 feet)<br />
51 SOURCE INTEGRITY LEVEL Value Vertical Rate<br />
52 (§C.2.3.10.9) 1 0 ft<br />
53 RESERVED 2 25 ft<br />
54 RESERVED --- ---<br />
55 TRUE / MAGNETIC HEADING (0=True, 1=Magnetic) 126 3125 ft<br />
56 RESERVED 127 > 3137.5 ft<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-81<br />
Figure C-17. TIS-B Coarse Airborne Position Message<br />
1 IMF (§C.3.4.5.1) Purpose: To provide airborne position in<strong>for</strong>mation <strong>for</strong><br />
2<br />
3<br />
SURVEILLANCE STATUS<br />
aircraft that are not equipped with 1090 MHz ADS-B<br />
when TIS-B service is based on moderate quality<br />
4 MSB surveillance data.<br />
5<br />
6<br />
SERVICE VOLUME ID (SVID)<br />
7 LSB<br />
8<br />
9<br />
10<br />
11<br />
12<br />
MSB<br />
13<br />
14<br />
15<br />
16<br />
17<br />
18<br />
PRESSURE ALTITUDE<br />
19 LSB<br />
20<br />
21<br />
22<br />
GROUND TRACK STATUS (1=Valid, 0=Invalid)<br />
23 GROUND TRACK ANGLE<br />
24<br />
25<br />
26<br />
27<br />
(§C.3.4.5.5)<br />
28 GROUND SPEED<br />
29<br />
30<br />
31<br />
(§C.3.4.5.6)<br />
32 CPR FORMAT (F) (0=Even, 1=Odd)<br />
33<br />
34<br />
35<br />
36<br />
37<br />
MSB<br />
38 CPR ENCODED LATITUDE<br />
39<br />
40<br />
41<br />
42<br />
43<br />
(§C.3.4.5.7)<br />
44 LSB<br />
45<br />
46<br />
47<br />
48<br />
49<br />
MSB<br />
50 CPR ENCODED LONGITUDE<br />
51<br />
52<br />
53<br />
54<br />
55<br />
(§C.3.4.5.7)<br />
56 LSB<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-82 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.4 ADS-B Rebroadcast Service – Formats <strong>and</strong> Coding<br />
C.4.1 INTRODUCTION<br />
The TIS-B MASPS, RTCA/DO-286B defines an “ADS-B Rebroadcast Service”, as a “Fundamental TIS-B<br />
Service,” that may be provided. The Messages of the ADS-B Rebroadcast Service are not transmitted by<br />
aircraft, but by ADS-B ground stations.<br />
Notes.—<br />
1. This section of Appendix A defines the <strong>for</strong>mats <strong>and</strong> coding <strong>for</strong> an ADS-B Rebroadcast Service (see<br />
the TIS-B MASPS, RTCA/DO-286B, §1.4.1) based on the same 112-bit 1090 MHz <strong>Extended</strong> <strong>Squitter</strong> signal<br />
transmission that is used <strong>for</strong> DF=17 ADS-B Messages on 1090 MHz.<br />
2. The ADS-B Rebroadcast Service complements the operation of ADS-B <strong>and</strong> the Fundamental TIS-B<br />
Service (see the TIS-B MASPS, RTCA/DO-286B, §1.4.1) by providing ground-to-air rebroadcast of ADS-B<br />
data about aircraft that are not equipped <strong>for</strong> 1090 MHz <strong>Extended</strong> <strong>Squitter</strong> ADS-B, but are equipped with an<br />
alternate <strong>for</strong>m of ADS-B (e.g., Universal Access Transceiver (UAT)). The basis <strong>for</strong> the ADS-B Rebroadcast<br />
transmission is the ADS-B Report received at the ground station using a receiver compatible with the<br />
alternate ADS-B data link.<br />
3. The ADS-B Rebroadcast ground-to-air transmissions use the same signal <strong>for</strong>mats as the DF=17<br />
1090 MHz <strong>Extended</strong> <strong>Squitter</strong> ADS-B <strong>and</strong> can there<strong>for</strong>e be accepted by a 1090 MHz ADS-B Receiving<br />
Subsystem, with the exceptions identified in the following sections.<br />
C.4.2 ADS-B REBROADCAST FORMAT DEFINITION<br />
ADS-B Rebroadcast in<strong>for</strong>mation is transmitted using the 112-bit <strong>Mode</strong> S DF=18 <strong>for</strong>mat specified in Figure C-<br />
11.<br />
C.4.3 CONTROL FIELD ALLOCATION<br />
The content of the DF=18 transmission is defined by the value of the Control Field (CF). As specified in<br />
Table C-37, ADS-B Rebroadcasts (i.e., ADS-R) transmissions shall use CF=6 <strong>and</strong> ADS-R Management<br />
in<strong>for</strong>mation transmissions (i.e., defining ADS-R Service Volume <strong>and</strong> service availability) shall use CF=4.<br />
Draft<br />
C.4.4 ADS-B REBROADCAST SURVEILLANCE MESSAGE DEFINITIONS<br />
The Rebroadcast of ADS-B in<strong>for</strong>mation on the 1090 MHz <strong>Extended</strong> <strong>Squitter</strong> data link is accomplished by<br />
utilizing the same ADS-B Message <strong>for</strong>mats defined in Figure C-1 through Figure C-10, with the exception of<br />
the need to transmit an indication to the 1090 MHz Receiving Subsystem as to the type of identity<br />
associated with the aircraft data being reported in the ADS-B Rebroadcast Message. This identification is<br />
per<strong>for</strong>med using the ICAO/<strong>Mode</strong> A Flag (IMF), which was previously discussed in §C.3.4.1.1 <strong>for</strong> the TIS-B<br />
transmissions.<br />
The insertion of this one bit into the ADS-B Messages identified below allows the ADS-B Receiving<br />
Subsystem to interpret the Address Field (AF) in the following manner:<br />
IMF = 0 indicates that the ADS-B Rebroadcast data is identified by an ICAO 24-bit Address<br />
IMF = 1 indicates that the ADS-B Rebroadcast data is identified by an anonymous 24-bit Address<br />
C.4.4.1 REBROADCAST OF ADS-B AIRBORNE POSITION MESSAGES<br />
The ADS-B Receiving Subsystem receives, decodes <strong>and</strong> processes the “ME” Field of the ADS-R Airborne<br />
Position Messages, <strong>and</strong> updates <strong>and</strong> maintains ADS-R Reports with the decoded data in accordance with<br />
§C.3.5. The <strong>for</strong>mat is identical to the Airborne Position Message specified in section §C.2.3.2 <strong>and</strong> Figure C-<br />
1, except that “ME” bit 8 is redefined to be the ICAO/<strong>Mode</strong> A Flag (IMF).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-83<br />
C.4.4.2 ADS-R SURFACE POSITION MESSAGE<br />
The ADS-B Receiving Subsystem receives, decodes <strong>and</strong> processes the “ME” Field of the ADS-R Surface<br />
Position Messages, <strong>and</strong> updates <strong>and</strong> maintains ADS-R Reports with the decoded data in accordance with<br />
§C.3.5. The <strong>for</strong>mat is identical to the ADS-B Surface Position Message specified in section §C.2.3.3 <strong>and</strong><br />
Figure C-2, except that “ME” bit 21 is redefined to be the ICAO/<strong>Mode</strong> A Flag (IMF).<br />
C.4.4.3 ADS-R AIRCRAFT IDENTIFICATION AND CATEGORY MESSAGE<br />
The ADS-B Receiving Subsystem receives, decodes <strong>and</strong> processes the “ME” Field of the ADS-R Aircraft<br />
Identification <strong>and</strong> Category Messages, <strong>and</strong> updates <strong>and</strong> maintains ADS-R Reports with the decoded data in<br />
accordance with §C.3.5. The <strong>for</strong>mat is as specified in section §C.2.3.4 <strong>and</strong> Figure C-4.<br />
Note.— Any Rebroadcast Aircraft Identification <strong>and</strong> Category Message does not contain the IMF bit<br />
since aircraft using an anonymous 24-bit address will not provide identity <strong>and</strong> category in<strong>for</strong>mation.<br />
C.4.4.4 ADS-R AIRBORNE VELOCITY MESSAGE<br />
The ADS-B Receiving Subsystem receives, decodes <strong>and</strong> processes the “ME” Field of the ADS-R Airborne<br />
Velocity Messages, <strong>and</strong> updates <strong>and</strong> maintains ADS-R Reports with the decoded data in accordance with<br />
§C.3.5. The <strong>for</strong>mats are identical to the ADS-B Airborne Velocity Messages specified in section §C.2.3.5.1<br />
<strong>and</strong> Figure C-5 <strong>for</strong> Subtype 1 & 2 Messages, <strong>and</strong> in section §C.2.3.5.2 <strong>and</strong> Figure C-6 <strong>for</strong> Subtype 3 & 4<br />
Messages, except that “ME” bit 9 is redefined to be the ICAO/<strong>Mode</strong> A Flag (IMF)..<br />
Note.— Bit 10 of the “ME” field in ADS-B Version One (1) is the IFR Capability Flag which is not<br />
conveyed in ADS-B Version Two (2) ADS-B Transmitting Subsystems.<br />
C.4.4.5 ADS-R EXTENDED SQUITTER AIRCRAFT STATUS MESSAGE<br />
The ADS-B Receiving Subsystem receives, decodes <strong>and</strong> processes the “ME” Field of the ADS-R <strong>Extended</strong><br />
<strong>Squitter</strong> Aircraft Status Messages, <strong>and</strong> updates <strong>and</strong> maintains ADS-R Reports with the decoded data in<br />
accordance with §C.3.5. The <strong>for</strong>mat is identical to the Aircraft Emergency/Priority Status Message specified<br />
in section §C.2.3.7.3 <strong>and</strong> Figure C-8a, except that “ME” bit 56 is redefined to be the ICAO/<strong>Mode</strong> A Flag<br />
(IMF).<br />
Draft<br />
C.4.4.6 ADS-R TARGET STATE AND STATUS MESSAGE<br />
The ADS-B Receiving Subsystem receives, decodes <strong>and</strong> processes the “ME” Field of the Rebroadcast<br />
Target State <strong>and</strong> Status Messages, <strong>and</strong> updates <strong>and</strong> maintains ADS-R Reports with the decoded data in<br />
accordance with §C.3.5. The <strong>for</strong>mat is identical to the ADS-B Target State <strong>and</strong> Status Message<br />
(Subtype=1) in section §C.2.3.9 <strong>and</strong> Figure C-9, except that “ME” bit 51 is redefined to be the ICAO/<strong>Mode</strong> A<br />
Flag (IMF).<br />
C.4.4.7 ADS-R AIRCRAFT OPERATIONAL STATUS MESSAGE<br />
The ADS-B Receiving Subsystem receives, decodes <strong>and</strong> processes the “ME” Field of the Rebroadcast<br />
Aircraft Operational Status Messages, <strong>and</strong> updates <strong>and</strong> maintains ADS-R Reports with the decoded data in<br />
accordance with §C.3.5. The <strong>for</strong>mat is identical to the ADS-B Aircraft Operational Status Message specified<br />
in section §C.2.3.10 <strong>and</strong> Figure C-10, except that “ME” bit 56 is redefined to be the ICAO/<strong>Mode</strong> A Flag (IMF)<br />
<strong>and</strong> bit 20 of the Capability Class Code conveys the NIC Supplement-B.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
C-84 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.4.5 ADS-R REPORT PROCESSING<br />
ADS-R Reports are to be maintained <strong>and</strong> output <strong>for</strong> DF=18, with CF=6 ADS-R Messages. ADS-R Reports<br />
are to be provided <strong>for</strong> both ADS-B Version ONE (1) <strong>and</strong> Version TWO (2) <strong>for</strong>matted ADS-R Messages in<br />
accordance with the message <strong>for</strong>mats provided in §C.4.<br />
C.5 <strong>Provisions</strong> <strong>for</strong> Backward Compatibility with Version 0 <strong>and</strong> Version 1<br />
ADS-B Systems<br />
This section defines:<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C.5.1 INTRODUCTION<br />
C.5.1.1 PURPOSE OF THIS SECTION<br />
a) the <strong>for</strong>mats <strong>and</strong> coding <strong>for</strong> <strong>Extended</strong> <strong>Squitter</strong> ADS-B Messages that are broadcast by ADS-B Version<br />
Zero (0), RTCA DO-260/EUROCAE ED-102 con<strong>for</strong>mant 1090 MHz ADS-B Subsystems;<br />
b) the <strong>for</strong>mats <strong>and</strong> coding <strong>for</strong> extended squitter ADS-B Messages that are broadcast by ADS-B Version<br />
One (1), RTCA DO-260A con<strong>for</strong>mant 1090 MHz ADS-B Subsystems;<br />
c) how the ADS-B report generation function of ADS-B Version Two (2) 1090 MHz ADS-B Receiving<br />
Subsystems is to utilize messages received from targets that are broadcasting with either ADS-B<br />
Version Zero (0) or ADS-B Version One (1) message <strong>for</strong>mats.<br />
C.5.1.2 MESSAGE VERSION NUMBER<br />
The ADS-B Version Number <strong>for</strong> all 1090 MHz ADS-B Messages originating <strong>for</strong> each specific ADS-B target is<br />
shall be determined from the decoding of the ADS-B Version Number subfield of the Aircraft Operational<br />
Status Message. An ADS-B Version Two (2) Receiving Subsystem shall initially assumes that the<br />
messages con<strong>for</strong>m to ADS-B Version Zero (0) message <strong>for</strong>mats, until or unless, a received ADS-B Version<br />
Number data indicates otherwise. The ADS-B Version Number is shall be retained <strong>and</strong> associated with all<br />
messages from that specific target. This ADS-B Version Number is shall be used <strong>for</strong> determining the<br />
applicable message <strong>for</strong>mats to be applied <strong>for</strong> the decoding of all 1090 MHz ADS-B Messages received from<br />
that target.<br />
Draft<br />
C.5.2 1090 MHZ ADS-B VERSION ZERO (0) MESSAGE PROCESSING<br />
C.5.2.1 ADS-B VERSION ZERO (0) MESSAGE TYPES<br />
Table C-39 provides specifies those ADS-B Version Zero (0) (i.e., originating from a 1090 MHz ADS-B<br />
Transmitting Subsystem con<strong>for</strong>mant to the requirements of Appendix A) 1090 MHz ADS-B Messages that<br />
are toshall be used <strong>for</strong> ADS-B report generation by a ADS-B Version Two (2) con<strong>for</strong>mant 1090 MHz ADS-B<br />
Receiving Subsystem.<br />
Note.— Table C-39 lists only those ADS-B Version Zero (0) 1090 MHz ADS-B Message types that are<br />
required to be received <strong>and</strong> used <strong>for</strong> ADS-B report generation by a ADS-B Version Two (2) 1090 MHz ADS-<br />
B Receiving Subsystems. The other ADS-B Version Zero (0) ADS-B Messages Types defined in Appendix<br />
A, including Messages Types 29 <strong>and</strong> 30, are not to be used by ADS-B Version Two (2) ADS-B Receiving<br />
Subsystems <strong>for</strong> the purpose of ADS-B report generation.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-85<br />
Message<br />
Format TYPE<br />
Code(s)<br />
1 through 4<br />
Table C-39. Version Zero (0) ADS-B Message Types<br />
Assignment Nominal Broadcast Rate<br />
<strong>Extended</strong> <strong>Squitter</strong> Identification <strong>and</strong><br />
Category<br />
5.0 s airborne/10.0 s surface<br />
5 through 8 <strong>Extended</strong> <strong>Squitter</strong> Surface Position 0.5 s in motion/5.0 s stationary<br />
9 through 18<br />
<strong>and</strong><br />
20 through 22<br />
<strong>Extended</strong> <strong>Squitter</strong> Airborne Position 0.5 s<br />
19 <strong>Extended</strong> <strong>Squitter</strong> Airborne Velocity 0.5 s<br />
28<br />
<strong>Extended</strong> <strong>Squitter</strong> Aircraft Status<br />
(e.g., emergency/priority)<br />
1.0 s<br />
31 Aircraft Operational Status 1.7 s<br />
C.5.2.1.1 Message TYPE Codes<br />
The first 5-bit field in every 1090 MHz ADS-B Message shall contains the message <strong>for</strong>mat TYPE. As shown<br />
in Table C-40, the TYPE Code (i.e., <strong>for</strong>mat type) is shall be used to differentiate the ADS-B Messages into<br />
several classes: airborne position, airborne velocity, surface position, identification, aircraft status, etc.<br />
Notes.—<br />
1. The general definition <strong>for</strong> all ADS-B Messages Types used <strong>for</strong> ADS-B Version Zero (0) ADS-B<br />
Messages has been retained <strong>for</strong> ADS-B Version One (1) <strong>and</strong> ADS-B Version Two (2) Messages. It must be<br />
noted <strong>for</strong> ADS-B Version Zero (0) ADS-B Messages, <strong>for</strong>mat TYPE Code 29 was defined but the<br />
corresponding messages are not to be transmitted. For ADS-B Version Zero (0) ADS-B Subsystems, TYPE<br />
Code 29 was associated with intent messages conveying Trajectory Change Point (TCP) in<strong>for</strong>mation.<br />
Although the message <strong>for</strong>mats <strong>for</strong> TCP related messages were defined within Appendix A, the requirements<br />
<strong>and</strong> the associated test procedures prohibited the broadcast of such messages.<br />
2. Appendix A defined TYPE Code 30 <strong>for</strong> Aircraft Operational Coordination Messages. The<br />
requirements <strong>and</strong> associated provisions <strong>for</strong> Aircraft Operational Coordination Messages have now been<br />
withdrawn by this Edition of this Manual. Although Appendix A (i.e., Version Zero) con<strong>for</strong>mant<br />
implementations are not prohibited from transmitting Aircraft Operational Coordination Messages (i.e., using<br />
TYPE Code 30), ADS-B Version Two (2) con<strong>for</strong>mant ADS-B Receiving Subsystems have no requirement <strong>for</strong><br />
the reception <strong>and</strong> processing of these broadcasts.<br />
Draft<br />
ADS-B Version Two (2) ADS-B Receiving Subsystems will shall process ADS-B Messages based only on<br />
the reception of ADS-B Version Zero (0) ADS-B Messages with ADS-B Message TYPE Code values of 0<br />
through 22, 28 <strong>and</strong> 31.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-86 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Table C-40. Format TYPE Codes <strong>for</strong> Version 0 <strong>and</strong> Version 2 Messages<br />
TYPE<br />
Version Zero (0)<br />
Version Two (2)<br />
Code<br />
Message Format<br />
Message Format<br />
0 No Position In<strong>for</strong>mation No Position In<strong>for</strong>mation<br />
1 Identification (Category Set D) Identification (Category Set D)<br />
2 Identification (Category Set C) Identification (Category Set C)<br />
3 Identification (Category Set B) Identification (Category Set B)<br />
4 Identification (Category Set A) Identification (Category Set A)<br />
5 Surface Position Surface Position<br />
6 Surface Position Surface Position<br />
7 Surface Position Surface Position<br />
8 Surface Position Surface Position<br />
9 Airborne Position Airborne Position<br />
10 Airborne Position Airborne Position<br />
11 Airborne Position Airborne Position<br />
12 Airborne Position Airborne Position<br />
13 Airborne Position Airborne Position<br />
14 Airborne Position Airborne Position<br />
15 Airborne Position Airborne Position<br />
16 Airborne Position Airborne Position<br />
17 Airborne Position Airborne Position<br />
18 Airborne Position Airborne Position<br />
19 Airborne Velocity Airborne Velocity<br />
20 Airborne Position Airborne Position<br />
21 Airborne Position Airborne Position<br />
22 Airborne Position Airborne Position<br />
23 Reserved <strong>for</strong> Test Purposes Test Message<br />
24 Reserved <strong>for</strong> Surface System Status Surface System Status<br />
25 Reserved Reserved<br />
26 Reserved Reserved<br />
27 Reserved Reserved <strong>for</strong> Trajectory Change<br />
28 <strong>Extended</strong> <strong>Squitter</strong> Aircraft Status <strong>Extended</strong> <strong>Squitter</strong> Aircraft Status<br />
29 Reserved <strong>for</strong> Trajectory Intent Target State <strong>and</strong> Status<br />
30 Operational Coordination Reserved<br />
31 Operational Status Operational Status<br />
Draft<br />
C.5.2.2 VERSION TWO (2) ADS-B REPORTS USING VERSION ZERO (0) MESSAGES<br />
Notes.—<br />
1. The following subparagraphs summarize the ADS-B Report requirements <strong>for</strong> ADS-B Version Two<br />
(2) systems when receiving ADS-B Version Zero (0) ADS-B Messages with ADS-B Message TYPE Code<br />
values of 0 through 22, 28 <strong>and</strong> 31.<br />
2. The ADS-B Reports of ADS-B Version 2, received from a ADS-B Version Zero transmitting<br />
subsystem are composed primarily from the in<strong>for</strong>mation received from airborne aircraft in Airborne Position<br />
Messages <strong>and</strong> Airborne Velocity Messages, or <strong>for</strong> aircraft/vehicles on the airport surface in Surface Position<br />
Messages. Many of the parameters contained within these messages are encoded the same, <strong>and</strong> occupy<br />
the same bit positions within the overall message structure, <strong>for</strong> both ADS-B Version Zero (0) <strong>and</strong> <strong>for</strong> ADS-B<br />
Version Two (2) messages. However, in a few cases the decoding process must be h<strong>and</strong>led differently <strong>for</strong><br />
ADS-B Version Zero (0) messages as compared to that required by this Manual <strong>for</strong> ADS-B Version Two (2)<br />
messages. The following subparagraphs describe the required use of ADS-B Version Zero (0) message<br />
data <strong>for</strong> ADS-B Reports by a ADS-B Version Two (2) compliant ADS-B Receiving Subsystem.<br />
C.5.2.2.1 ADS-B Report to 1090 MHz ADS-B Message Mapping<br />
Notes.—<br />
1. There are some minor differences in the specific names applied to certain otherwise identical ADS-<br />
B Version Zero (0) versus ADS-B Version Two (2) messages subfields. For example, a changed ADS-B<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-87<br />
Report parameter between Version Zero (0) described in Appendix A, <strong>and</strong> Version One (1) described in<br />
Appendix B, <strong>and</strong> Version Two (2) described in this Appendix, is the Navigation Integrity Category (NIC)<br />
parameter, which replaced the Navigation Uncertainty Category (NUC) from ADS-B Version Zero (0). The<br />
following subparagraphs discuss the NIC parameter <strong>and</strong> its mapping from ADS-B Version Zero (0)<br />
messages to the Version Two (2) ADS-B Report. Additional differences in ADS-B Version Zero (0) <strong>and</strong><br />
Version Two (2) are also described below.<br />
2. The <strong>for</strong>mats of the ADS-B Version Zero (0) 1090 MHz ADS-B Messages are specified in Table A-2-<br />
5 through Table A-2-10, Table A-2-97 <strong>and</strong> Table A-2-101.<br />
C.5.2.2.2 Navigation Integrity Category (NIC)<br />
Note.— The ADS-B Version Zero (0) Surface <strong>and</strong> Airborne Position Messages have associated with<br />
each specific TYPE Code a corresponding Horizontal Protection Limit <strong>and</strong> a 95% Containment Radius (RC). For the purpose of generating an ADS-B Report, ADS-B Version Zero mapped these message parameters<br />
to a Navigation Uncertainty Category (NUC). As defined by Table C-2, ADS-B Version Two (2) Surface <strong>and</strong><br />
Airborne Position Messages associate the ADS-B Message TYPE Code with the parameters of Horizontal<br />
Containment Limit (RC) <strong>and</strong> Navigation Integrity Category (NIC). Although ADS-B Version Zero (0) ADS-B<br />
Messages were not defined in Appendix A to directly include a value <strong>for</strong> NIC, the values defined by Table C-<br />
2 <strong>for</strong> RC <strong>and</strong> NIC have been selected such that the it is possible to map the TYPE Code values from ADS-B<br />
Version Zero (0) ADS-B Message to a corresponding value <strong>for</strong> NIC.<br />
The Surface <strong>and</strong> Airborne Position Message TYPE Codes associated with ADS-B Version Zero (0) 1090<br />
MHz ADS-B Messages are shall be mapped to the NIC values shown in Table C-41 <strong>for</strong> the purpose of<br />
generating ADS-B Version Two (2) ADS-B Reports.<br />
Table C-41. Version Zero (0) Format Type Code Mapping to Navigation Source<br />
Characteristics<br />
TYPE<br />
Code<br />
Format<br />
“TYPE” Subfield Code Definitions (DF = 17 or 18)<br />
Horizontal Protection Limit, HPL (RC) Altitude Type<br />
Reported<br />
NIC<br />
0<br />
No Position<br />
In<strong>for</strong>mation<br />
Baro Altitude or No Altitude<br />
In<strong>for</strong>mation<br />
0<br />
5 Surface Position HPL < 7.5 m No Altitude In<strong>for</strong>mation 11<br />
6 Surface Position HPL < 25 m No Altitude In<strong>for</strong>mation 10<br />
7 Surface Position HPL < 185.2 m (0.1 NM) No Altitude In<strong>for</strong>mation 8<br />
8 Surface Position HPL > 185.2 m (0.1 NM) No Altitude In<strong>for</strong>mation 0<br />
9 Airborne Position HPL < 7.5 m Baro Altitude 11<br />
10 Airborne Position 7.5 m < HPL < 25 m Baro Altitude 10<br />
11 Airborne Position 25 m < HPL < 185.2 m (0.1 NM) Baro Altitude 8<br />
12 Airborne Position 185.2 m (0.1 NM) < HPL < 370.4 m (0.2 NM) Baro Altitude 7<br />
13 Airborne Position 380.4 m (0.2 NM) < HPL < 926 m (0.5 NM) Baro Altitude 6<br />
14 Airborne Position 926 m (0.5 NM) < HPL < 1852 m (1.0 NM) Baro Altitude 5<br />
15 Airborne Position 1852 m (1.0 NM) < HPL < 3704 m (2.0 NM) Baro Altitude 4<br />
16 Airborne Position 7.704 km (2.0 NM) < HPL < 18.52 km (10 NM) Baro Altitude 1<br />
17 Airborne Position 18.52 km (10 NM) < HPL < 37.04 km (20 NM) Baro Altitude 1<br />
18 Airborne Position HPL > 37.04 km (20 NM) Baro Altitude 0<br />
20 Airborne Position HPL < 7.5 m GNSS Height (HAE) 11<br />
21 Airborne Position HPL < 25 m GNSS Height (HAE) 10<br />
22 Airborne Position HPL > 25 m GNSS Height (HAE) 0<br />
Draft<br />
Notes.—<br />
1. “Baro-Altitude” refers to barometric pressure altitude, relative to a st<strong>and</strong>ard pressure of 1013.25<br />
millibars (29.92 in Hg). It does not refer to baro corrected altitude.<br />
2. The GNSS height (HAE) defined in Type Codes 20 to 22 is used when baro altitude is not available.<br />
3. The radius of containment (RC), is derived from ARINC 429 label 130, which is variously called HIL<br />
(Horizontal Integrity Limit) or HPL (Horizontal Protection Level).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-88 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.5.2.2.3 Movement<br />
Notes.—<br />
1. The quantization in the Movement subfield conveyed in Version Two (2) Surface Position<br />
Messages is different than the Movement subfield contained in Version Zero (0). The encoding of the<br />
Version Zero (0) Movement subfield is contained in §A.2.3.3.1.<br />
2. Note.— ADS-B Applications must use the version number to properly decode the Movement<br />
subfield.<br />
C.5.2.2.4 ADS-B Version Number<br />
Note.— The <strong>for</strong>mat of the Aircraft Operational Status Message substantially differs between the ADS-B<br />
Version Zero (0) ADS-B Message <strong>for</strong>mat shown in Figure A-2-101 <strong>and</strong> the ADS-B Version Two (2) ADS-B<br />
Message <strong>for</strong>mat specified in §C.2.3.10 of this Manual. The ADS-B Version Two (2) Aircraft Operational<br />
Status Message <strong>for</strong>mat includes an explicit ADS-B Version Number subfield (ME bits 41-43). For a ADS-B<br />
Version Zero (0) ADS-B Aircraft Operational Status Message, these same bits were unassigned reserved<br />
<strong>and</strong> were expected to be set to a value of ZERO (0).<br />
An ADS-B Version Two (2) Receiving Subsystem willshall, as a default, assume the received messages are<br />
using ADS-B Version Zero (0) ADS-B Message <strong>for</strong>mat unless, or until, an Aircraft Operational Status<br />
Message is received <strong>and</strong> the ADS-B Version Number is confirmed to be other than Zero (0). However, inIn<br />
the case of a ADS-B Version Two (2) ADS-B Subsystem’s reception of an Aircraft Operational Status<br />
Message, the ADS-B Receiving Subsystem will shall decode “ME” bits 41-43 <strong>and</strong> determine if the target<br />
aircraft is broadcasting messages that are ADS-B Version Zero (0), or Version One (1), or Version Two (2),<br />
<strong>and</strong> then decode the remainder of the message in accordance with the message <strong>for</strong>mat applicable to that<br />
ADS-B Version Number.<br />
Note.— The ADS-B Version Number determined from the decoding of the ADS-B Version Number<br />
subfield of the Aircraft Operational Status Message must be retained <strong>and</strong> associated with the specific target<br />
since it is used in determining the applicable <strong>for</strong>mats to be used <strong>for</strong> the decoding of the other message<br />
types.<br />
C.5.2.2.5 Emitter Category<br />
The ADS-B Report Assembly Function will shall extract “TYPE” <strong>and</strong> “ADS-B Emitter Category” from the<br />
Aircraft Identification <strong>and</strong> Category Message (Table A-2-8) <strong>and</strong> encode the “Emitter Category” field. The<br />
Emitter Category conveyed in the Aircraft Identification <strong>and</strong> Category Message is shall be mapped into the<br />
ADS-B Report, Emitter Category field as specified by Table A-2-8. However, it must be noted that in<br />
Draft<br />
Note.—In the ADS-B Version Zero (0) Aircraft Identification <strong>and</strong> Category Message, the Emitter<br />
Category subfield conveys a subset of the Emitter Categories allowed by the ADS-B Report.<br />
C.5.2.2.6 A/V Length <strong>and</strong> Width Code<br />
The A/V Length <strong>and</strong> Width Code is not conveyed by ADS-B Version Zero (0) 1090 MHz ADS-B Messages.<br />
This parameter is only included in the ADS-B Report when reporting on an aircraft or vehicle that is on the<br />
airport surface. When no A/V Length <strong>and</strong> Width Code is available, as is the case <strong>for</strong> target A/V that are<br />
broadcasting ADS-B Version Zero (0) ADS-B Messages, the A/V Length <strong>and</strong> Width Code parameter will<br />
shall not be included in the ADS-B Report.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-89<br />
C.5.2.2.7 Emergency/Priority Status<br />
The Emergency/Priority Status conveyed in the Aircraft Status Message (Table A-2-97) will shall be directly<br />
mapped into the ADS-B Report, Emergency/Priority Status field as specified in §C.2.3.7.3. However, it must<br />
be noted that in the<br />
Note.— In the ADS-B Version Zero (0) Aircraft <strong>Extended</strong> <strong>Squitter</strong> Status Message, the<br />
Emergency/Priority Status subfield conveys a subset of the Emergency/Priority Status categories allowed by<br />
an ADS-B Report.<br />
C.5.2.2.8 Capability Codes<br />
The ADS-B Version Zero (0) Operational Status Message (Table A-2-101) conveys Control Codes with<br />
in<strong>for</strong>mation limited to TCAS <strong>and</strong> CDTI capabilities, as shown in Table C-42. The ADS-B Version Zero (0)<br />
Aircraft Operational Status Message <strong>for</strong>mat specifies coding only <strong>for</strong> the case of CC-4 (En Route<br />
Operational Capabilities). There<strong>for</strong>e the CC-1, CC-2 <strong>and</strong> CC-3 subfields, as specified in Table A-2-101, are<br />
toshall be considered reserved <strong>and</strong> not used <strong>for</strong> ADS-B Version Zero (0) ADS-B Messages.<br />
For the case of CC-4, this 4-bit (bits 9-12) subfield will shall be mapped to the Capability Code field of the<br />
ADS-B Report as shown in Table C-42. The remaining bits within the ADS-B Report Capability Code field<br />
will shall be set to Zero (0). If no Aircraft Operational Status Message has been received, then the Capability<br />
Code field may shall be omitted from the ADS-B Report.<br />
Table C-42. En-Route Operational Capabilities Encoding<br />
CC-4 Encoding: En Route Operational Capabilities<br />
CC-4 Coding<br />
Mapping to ADS-B Report<br />
(Version Zero (0)<br />
Meaning<br />
Capability Code field<br />
Messages)<br />
(Version Zero (0) Messages)<br />
Bit 9,10 Bit 11,12<br />
CC Field Bits 11, 12<br />
0 0<br />
TCAS Operational or unknown;<br />
CDTI not Operational or<br />
unknown<br />
10<br />
0 0<br />
0 1<br />
TCAS Operational or unknown;<br />
CDTI Operational<br />
11<br />
1 0<br />
TCAS not Operational; CDTI<br />
not Operational or unknown<br />
00<br />
1 1<br />
TCAS not Operational; CDTI<br />
Operational<br />
01<br />
Draft<br />
C.5.2.2.9 Operational <strong>Mode</strong>s<br />
ADS-B Version Zero (0) messages con<strong>for</strong>mant to <strong>for</strong>mats in Appendix A, do not define coding <strong>for</strong> the<br />
Operational <strong>Mode</strong> subfield of the Operational Status Message (Table A-2-101). There<strong>for</strong>e the OM-1, OM-2,<br />
OM-3 <strong>and</strong> OM-4 subfields, as shown in Table A-2-101, are toshall be considered reserved <strong>and</strong> not used <strong>for</strong><br />
ADS-B Version Zero (0) Messages. ADS-B Reports <strong>for</strong> target aircraft/vehicles broadcasting ADS-B Version<br />
Zero (0) ADS-B Messages will shall not include the Operational <strong>Mode</strong> field in the report.<br />
C.5.2.2.10 Navigation Accuracy Category <strong>for</strong> Position (NACP)<br />
The ADS-B Version Zero (0) ADS-B Surface <strong>and</strong> Airborne Position Messages have associated with each<br />
specific TYPE code a corresponding Horizontal Protection Limit <strong>and</strong> a 95% Containment Radius (i.e.,<br />
position error). For a ADS-B Version Two (2) Receiving Subsystem, the TYPE codes of the received ADS-B<br />
Version Zero (0) Messages will shall be mapped into the value of the Navigation Accuracy Category <strong>for</strong><br />
Position (NAC P) as shown in Table C-43 <strong>for</strong> the purpose of generating the ADS-B Report.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-90 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Version 0<br />
Message<br />
TYPE CODE<br />
Table C-43. Type Code to NACP Mapping<br />
Message Format<br />
Position Error<br />
(95%)<br />
ADS-B<br />
Report NACP<br />
value<br />
0 No Position Info Unknown 0<br />
5 Surface Position < 3 m 11<br />
6 Surface Position < 10 m 10<br />
7 Surface Position < 0.05 NM 8<br />
8 Surface Position > 0.05 NM 0<br />
9 Airborne Position < 3 m 11<br />
10 Airborne Position < 10 m 10<br />
11 Airborne Position < 0.05 NM 8<br />
12 Airborne Position < 0.1 NM 7<br />
13 Airborne Position < 0.25 NM 6<br />
14 Airborne Position < 0.5 NM 5<br />
15 Airborne Position < 1 NM 4<br />
16 Airborne Position < 5 NM 1<br />
17 Airborne Position < 10 NM 1<br />
18 Airborne Position > 10 NM 0<br />
20 Airborne Position < 4 m 11<br />
21 Airborne Position < 15 m 10<br />
22 Airborne Position > 15 m 0<br />
Note.— The Position Error column of the table indicates the greater of the horizontal or vertical 95%<br />
containment radius as listed in Table C-41 <strong>for</strong> ADS-B Version Zero (0) messages.<br />
C.5.2.2.11 Navigation Accuracy Category <strong>for</strong> Velocity (NACV)<br />
The ADS-B Version Zero (0) Airborne Velocity Message (see Table A-2-9a <strong>and</strong> Table A-2-9b) includes a<br />
subfield that conveys the Navigation Uncertainty Category <strong>for</strong> Velocity (NUCR). The received value of NUCR will shall be mapped directly one-<strong>for</strong>-one to the Navigation Accuracy Category <strong>for</strong> Velocity (NACV) field of an<br />
ADS-B Report.<br />
Draft<br />
C.5.2.2.12 Source Integrity Level (SIL)<br />
The Source Integrity Level (SIL) defines the probability of the integrity containment region described by the<br />
NIC parameter being exceeded <strong>for</strong> the selected geometric position source, including any external signals<br />
used by the source. The value of SIL can only be inferred from the in<strong>for</strong>mation conveyed in ADS-B Version<br />
Zero (0) Messages. Table C-44 shall be used to provides the mapping between the message TYPE Code<br />
<strong>for</strong> a ADS-B Version Zero (0) Transmitting Subsystem <strong>and</strong> the value of SIL to be reported by a ADS-B<br />
Version Two (2) Receiving Subsystem within the ADS-B Report.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-91<br />
Version 0<br />
Message<br />
TYPE CODE<br />
Message Format<br />
Table C-44. SIL Reporting<br />
Probability of Exceeding the Horizontal<br />
Containment Radius<br />
(RC)<br />
ADS-B<br />
Report<br />
SIL<br />
value<br />
0 No Position Info No Integrity 0<br />
5 Surface Position 1 X 10 -5 per flight hour or per sample 2<br />
6 Surface Position 1 X 10 -5 per flight hour or per sample 2<br />
7 Surface Position 1 X 10 -5 per flight hour or per sample 2<br />
8 Surface Position 1 X 10 -5 per flight hour or per sample 2<br />
9 Airborne Position 1 X 10 -5 per flight hour or per sample 2<br />
10 Airborne Position 1 X 10 -5 per flight hour or per sample 2<br />
11 Airborne Position 1 X 10 -5 per flight hour or per sample 2<br />
12 Airborne Position 1 X 10 -5 per flight hour or per sample 2<br />
13 Airborne Position 1 X 10 -5 per flight hour or per sample 2<br />
14 Airborne Position 1 X 10 -5 per flight hour or per sample 2<br />
15 Airborne Position 1 X 10 -5 per flight hour or per sample 2<br />
16 Airborne Position 1 X 10 -5 per flight hour or per sample 2<br />
17 Airborne Position 1 X 10 -5 per flight hour or per sample 2<br />
18 Airborne Position No Integrity 0<br />
20 Airborne Position 1 X 10 -5 per flight hour or per sample 2<br />
21 Airborne Position 1 X 10 -5 per flight hour or per sample 2<br />
22 Airborne Position No Integrity 0<br />
C.5.2.2.13 Barometric Altitude Integrity Code (NICBARO)<br />
The Barometric Altitude Integrity Code (NICBARO) parameter of the ADS-B Report is a 1-bit flag used to<br />
indicate if the barometric altitude being reported in the ADS-B Report has been cross-checked against<br />
another source of pressure altitude. The ADS-B Version Zero (0) Messages do not include in<strong>for</strong>mation<br />
related to the cross-checking of barometric altitude. There<strong>for</strong>e, ADS-B Reports <strong>for</strong> target aircraft/vehicles<br />
broadcasting ADS-B Version Zero (0) Messages will shall not include the NICBARO field in the report.<br />
C.5.2.2.14 Track/Heading <strong>and</strong> Horizontal Reference Direction (HRD)<br />
Draft<br />
ADS-B Version Zero (0) Airborne Velocity Messages with Subtype equal to 3 or 4 include a “Magnetic<br />
Heading Status Bit” as shown in Table A-2-9b. A Version Two (2) 1090 MHz ADS-B Receiving Subsystem,<br />
upon receiving an Airborne Velocity Message with a Subtype of 3 or 4, must decode the Magnetic Heading<br />
Status Bit to determine if Magnetic Heading Data is “Available.” The ADS-B Receiving Subsystem will shall<br />
set the value of the True/Magnetic Heading subfield, as specified in Table C-45.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-92 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Version 0<br />
Airborne<br />
Velocity<br />
Message<br />
SUBTYPE<br />
Table C-45. Track/Heading <strong>and</strong> HRD Subfield<br />
Airborne<br />
Velocity<br />
Message<br />
“Magnetic<br />
Heading Status<br />
Bit”<br />
Surface<br />
Position<br />
Message<br />
“Ground<br />
Track Status<br />
Bit”<br />
N/A N/A 0<br />
1 or 2 N/A 1<br />
3 or 4 0 N/A<br />
3 or 4 1 N/A<br />
Meaning<br />
No Valid Track/<br />
Heading or<br />
Heading Direction<br />
Reference<br />
in<strong>for</strong>mation<br />
available<br />
Ground Track<br />
being reported<br />
Heading relative<br />
to true north being<br />
reported<br />
Heading relative<br />
to magnetic north<br />
being reported<br />
ADS-B<br />
Report<br />
True/Magnetic<br />
Heading subfield<br />
encoding<br />
Notes.—<br />
1. When no valid data is available the “Track/Heading <strong>and</strong> HRD” parameter may be reported as ALL<br />
ZEROs.<br />
2. When receiving ADS-B Version Two (2) Messages, the Track/Heading <strong>and</strong> HRD in<strong>for</strong>mation are<br />
conveyed within the Operation Status Message. However, when receiving ADS-B Version Zero (0)<br />
Messages the equivalent in<strong>for</strong>mation can be determined <strong>for</strong> airborne aircraft from the value of the “Subtype”<br />
subfield <strong>and</strong> <strong>for</strong> Subtype=3 or 4 messages the value of the “Magnetic Heading Status Bit” of the Airborne<br />
Velocity Message (Table A-2-9b). When a target aircraft/vehicle is on the surface, a value of 01 should be<br />
reported when a Surface Position Message (Table A-2-6) is received with the “Heading/Ground Track Status<br />
Bit” set to a value of ONE (1) indicating that the valid ground track data is provided.<br />
3. ADS-B Version Zero (0) Airborne Velocity Messages, Subtypes 3 <strong>and</strong> 4 always report Heading<br />
relative to Magnetic North, never relative to True North.<br />
C.5.2.3 AIR REFERENCED VELOCITY REPORTS<br />
Draft<br />
The requirements <strong>for</strong> Air Referenced Velocity (ARV) Reports shall apply to the ARV Report Assembly<br />
requirements when the target aircraft is broadcasting either ADS-B Version Zero (0) or Version Two (2)<br />
Message <strong>for</strong>mats (Table A-2-9b).<br />
C.5.2.4 TARGET STATUS REPORTS<br />
Appendix A defines a message <strong>for</strong>mat using message TYPE Code 29 to convey Aircraft Trajectory Intent<br />
in<strong>for</strong>mation in the <strong>for</strong>m of Trajectory Change Point (TCP) in<strong>for</strong>mation. A 1090 MHz ADS-B Receiving<br />
Subsystem con<strong>for</strong>ming to this Manual does shall not use any message with a TYPE Code of 29 that is<br />
received from a ADS-B Version Zero (0) Transmitting Subsystem <strong>for</strong> the purpose of report generation.<br />
Note.— Prior to generation of a Target Status Report, the 1090 MHz ADS-B Receiving Subsystem must<br />
positively confirm that any received message with a TYPE Code of 29 has originated from a target aircraft<br />
with an ADS-B Version Number other than Zero (0). The ADS-B Version Number can be determined from<br />
the contents of the ADS-B Version Number subfield (see §C.2.3.10.5) of the Aircraft Operational Status<br />
Message.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
00<br />
01<br />
00<br />
11
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-93<br />
C.5.3 1090 MHZ ADS-B VERSION 1 MESSAGE PROCESSING<br />
C.5.3.1 ADS-B VERSION ONE (1) MESSAGE TYPES<br />
Note.— ADS-B Version One (1) (i.e., 1090 MHz ADS-B Transmitting Subsystem con<strong>for</strong>mant to<br />
Appendix B) 1090 MHz ADS-B Messages are the same basic message types as ADS-B Version Two (2).<br />
Some messages have different <strong>for</strong>mats <strong>and</strong> contain additional or eliminated message subfields.<br />
For example, the Target State <strong>and</strong> Status Message changed between ADS-B Version One (1) to ADS-B<br />
Version Two (2). ADS-B Version One (1) Transmitting Subsystems use Subtype Zero (0) <strong>for</strong> the Target<br />
State <strong>and</strong> Status Message, <strong>and</strong> ADS-B Version Two (2) Transmitting Subsystems use Subtype One (1) to<br />
maintain backward compatibility. ADS-B Version Two (2) Receiving Subsystems do not generate ADS-B<br />
Reports from ADS-B Version One (1) Target State <strong>and</strong> Status Messages, but utilize the accuracy <strong>and</strong><br />
integrity parameters in the Message. See Appendix B <strong>for</strong> ADS-B Version One (1) Message <strong>for</strong>mats. ADS-B<br />
Version One (1) Transmitting Subsystems do not broadcast the <strong>Extended</strong> <strong>Squitter</strong> Aircraft Status Message<br />
(Subtype 2), the 1090ES TCAS Resolution Advisory (RA) Message.<br />
C.5.3.1.1 Message TYPE Codes<br />
The first 5-bit field in every 1090 MHz ADS-B Message contains the message <strong>for</strong>mat TYPE. The TYPE<br />
Code (i.e., <strong>for</strong>mat type) is shall be used to differentiate the messages into several classes: airborne position,<br />
airborne velocity, surface position, identification, aircraft status, etc. The general definition <strong>for</strong> all ADS-B<br />
Messages Types used <strong>for</strong> ADS-B Version One (1) Messages has been retained <strong>for</strong> ADS-B Version Two (2)<br />
Messages.<br />
C.5.3.2 VERSION TWO (2) ADS-B REPORTS GENERATED USING VERSION ONE (1) MESSAGES<br />
Note.— The following subparagraphs summarize the ADS-B Report generation requirements <strong>for</strong> ADS-B<br />
Version Two (2) systems when receiving ADS-B Version One (1) ADS-B Messages.<br />
The contents of ADS-B Reports are composed primarily from the in<strong>for</strong>mation received from airborne aircraft<br />
in Airborne Position Messages <strong>and</strong> Airborne Velocity Messages or <strong>for</strong> aircraft/vehicles on the airport surface<br />
in Surface Position Messages. Many of the parameters contained within these messages are encoded the<br />
same, <strong>and</strong> occupy the same positions with the overall message structure, <strong>for</strong> both ADS-B Version One (1)<br />
<strong>and</strong> <strong>for</strong> ADS-B Version Two (2) Messages. However, in a few cases the decoding <strong>and</strong>/or report assembly<br />
processing must be h<strong>and</strong>led differently <strong>for</strong> ADS-B Version One (1) Messages as compared to that required<br />
by this Manual <strong>for</strong> ADS-B Version Two (2) Messages. The following subparagraphs describe the required<br />
use of ADS-B Version One (1) Messages <strong>for</strong> ADS-B Report generation by a ADS-B Version Two (2)<br />
compliant ADS-B Receiving Subsystem.<br />
Draft<br />
C.5.3.2.1 Navigation Integrity Category (NIC)<br />
As defined by Table C-2, ADS-B Version Two (2) Surface <strong>and</strong> Airborne Position Messages have associated<br />
with each specific ADS-B Message TYPE Code a corresponding Horizontal Containment Limit (RC) <strong>and</strong><br />
Navigation Integrity Category (NIC). The TYPE Code is used along with the NIC Supplement-A in the<br />
Operational Status Message to decode the NIC. The Surface <strong>and</strong> Airborne Position Message TYPE Codes<br />
associated with ADS-B Version One (1) 1090 MHz ADS-B Messages along with the NIC Supplement-A are<br />
shall be used to map to the NIC values shown in Table B-2 <strong>for</strong> the purpose of generating ADS-B Reports.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-94 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
C.5.3.2.2 Movement<br />
Notes.—<br />
1. The quantization in the Movement subfield conveyed in Version Two (2) Surface Position<br />
Messages is different than the Movement subfield contained in Version One (1). The encoding of the<br />
Version One (1) Movement subfield is the same as that contained in Version Zero (0) <strong>and</strong> is defined in<br />
§A.2.3.3.1.<br />
Note.— 2. ADS-B Applications must use the version number to properly decode the Movement<br />
subfield.<br />
C.5.3.2.3 ADS-B Version Number<br />
Note.— The <strong>for</strong>mat of the Aircraft Operational Status Message differs between the ADS-B Version One<br />
(1) Message <strong>for</strong>mat shown in Table B-2-101 <strong>and</strong> the ADS-B Version Two (2) Message <strong>for</strong>mat specified in<br />
§C.2.3.10 of this Manual. There are additional parameters in ADS-B Version Two (2) Aircraft Operational<br />
Status Messages that are not contained in ADS-B Version One (1) Messages.<br />
A ADS-B Version Two (2) Receiving Subsystem willshall, as a default, assume the received messages are<br />
using ADS-B Version Zero (0) Message <strong>for</strong>mat unless, or until, an Aircraft Operational Status Message is<br />
received <strong>and</strong> the ADS-B Version Number is confirmed to be other than Zero (0). However, inIn the case of a<br />
ADS-B Version Two (2) Subsystem’s reception of an Aircraft Operational Status Message, the ADS-B<br />
Receiving Subsystem will shall decode “ME” bits 41-43 <strong>and</strong> determine if the target aircraft is broadcasting<br />
messages that are ADS-B Version Zero (0), Version One (1), or Version Two (2), or higher, <strong>and</strong> then decode<br />
the remainder of the message in accordance with the message <strong>for</strong>mat applicable to that ADS-B Version<br />
Number.<br />
Note.— The ADS-B Version Number determined from the decoding of the Version Number subfield of<br />
the Aircraft Operational Status message must be retained <strong>and</strong> associated with the specific target since it is<br />
used in determining the applicable <strong>for</strong>mats to be used <strong>for</strong> the decoding of the other message types.<br />
C.5.3.2.4 Emitter Category<br />
The ADS-B Report Assembly Function will shall extract “TYPE” <strong>and</strong> “ADS-B Emitter Category” from the<br />
Aircraft Identification <strong>and</strong> Category Message (Table A-2-8) <strong>and</strong> encode the “Emitter Category” field. The<br />
Emitter Category conveyed in the Aircraft Identification <strong>and</strong> Category Message is shall be mapped into the<br />
ADS-B Report, Emitter Category field as specified by Table A-2-8. However, it must be noted that in<br />
Draft<br />
Note.— In the ADS-B Version One (1) Aircraft Identification <strong>and</strong> Category Message, the Emitter<br />
Category subfield conveys a subset of the Emitter Categories allowed by the ADS-B Report.<br />
C.5.3.2.5 A/V Length <strong>and</strong> Width Code<br />
This parameter is onlyshall be included in the ADS-B Report when reporting on an aircraft or vehicle that is<br />
on the airport surface using the coding specified in Table C-46. When no A/V Length <strong>and</strong> Width Code is<br />
available, the A/V Length <strong>and</strong> Width Code parameter will shall not be included in the ADS-B Report.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix C C-95<br />
Table C-46. Version One (1) “Aircraft/Vehicle Length <strong>and</strong> Width Code” Decoding<br />
A/V - L/W<br />
Code<br />
(Decimal)<br />
Length Code<br />
ME ME ME<br />
Bit 21 Bit 22 Bit 23<br />
Width<br />
Code<br />
ME<br />
Bit<br />
24<br />
Upper-Bound Length <strong>and</strong> Width<br />
<strong>for</strong> Each Length/Width Code<br />
Length<br />
Width<br />
(meters)<br />
(meters)<br />
0 0 0 0 0 No Data or Unknown<br />
1 0 0 0 1 15 23<br />
2<br />
3<br />
0 0 1<br />
0<br />
1<br />
25<br />
28.5<br />
34<br />
4<br />
5<br />
0 1 0<br />
0<br />
1<br />
35<br />
33<br />
38<br />
6<br />
7<br />
0 1 1<br />
0<br />
1<br />
45<br />
39.5<br />
45<br />
8<br />
9<br />
1 0 0<br />
0<br />
1<br />
55<br />
45<br />
52<br />
10<br />
11<br />
1 0 1<br />
0<br />
1<br />
65<br />
59.5<br />
67<br />
12<br />
13<br />
1 1 0<br />
0<br />
1<br />
75<br />
72.5<br />
80<br />
14<br />
15<br />
1 1 1<br />
0<br />
1<br />
85<br />
80<br />
90<br />
Note.— In Appendix B encoding of decimal ZERO (0) A/V Length/Width Code was specified as<br />
Length=15 meters <strong>and</strong> Width=11.5 meters. However, there may be ADS-B Transmitting Subsystems<br />
implemented that are consistent with the interpretation of the ICAO SARPs of defining an ALL ZERO<br />
condition to be interpreted as “No Data or Unknown.” Version TWO (2) ADS-B Reports based on receiving<br />
an ALL ZERO A/V Length/Width Code from a Version One (1) Transmitting Subsystem will be reported as<br />
“Unknown.”<br />
C.5.3.2.6 Emergency/Priority Status<br />
The Emergency/Priority Status conveyed in the Aircraft Status Message (Table B-2-101) <strong>and</strong> the Target<br />
State <strong>and</strong> Status Message (Table B-2-98) will shall be directly mapped into the ADS-B Report,<br />
Emergency/Priority Status field.<br />
Draft<br />
C.5.3.2.7 Capability Codes<br />
The ADS-B Report Assembly Function will shall extract the “Capability Class Codes” data from Aircraft<br />
Operational Status Messages <strong>and</strong> the Target State <strong>and</strong> Status Messages <strong>and</strong> provide the Capability Class<br />
Codes to the user application in the ADS-B Report.<br />
When valid “Capability Class” data is not available <strong>for</strong> a given parameter, then the Capability Class data sent<br />
to the user application <strong>for</strong> that parameter is shall be set to ALL ZEROs.<br />
When an ADS-B Report is generated <strong>and</strong> when the only received update to the “Capability Class” data has<br />
come from a Target State <strong>and</strong> Status Message, the reported value of all Capability Class parameters are<br />
shall be based on the most recently received Operational Status Message, except updated with the data<br />
(i.e., TCAS parameter) received in the subsequent Target State <strong>and</strong> Status Message.<br />
C.5.3.2.8 Source Integrity Level (SIL)<br />
The Source Integrity Level (SIL) defines the probability of the integrity containment region described by the<br />
NIC parameter being exceed <strong>for</strong> the selected geometric position source, including any external signals used<br />
by the source. In ADS-B Version One (1), the Surveillance Integrity Level parameter represented this<br />
probability as well as other elements of integrity. The Surveillance Integrity Level may have also included<br />
the reliability of the aircraft systems given by a failure rate corresponding to the equipment design<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
C-96 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
assurance. In ADS-B Version Two (2), this aspect of integrity is represented by the System Design<br />
Assurance (SDA) parameter. The ADS-B Report Assembly Function will shall extract the Surveillance<br />
Integrity Level data from Aircraft Operational Status Messages <strong>and</strong> the Target State <strong>and</strong> Status Messages<br />
<strong>and</strong> provide the Source Integrity Level to the user application in the <strong>Mode</strong> Status Report in the binary <strong>for</strong>mat.<br />
Note.— Applications using Reports from ADS-B Version One (1) participants may be able to use the<br />
Surveillance Integrity Level to derive both Source Integrity Level <strong>and</strong> System Design Assurance (SDA).<br />
C.5.3.2.9 Track/Heading <strong>and</strong> Horizontal Reference Direction (HRD)<br />
The ADS-B Report Assembly Function will shall extract the Track Angle/Heading (see §C.2.3.10.12) <strong>and</strong> the<br />
Horizontal Reference Direction (HRD) (see §C.2.3.10.13) flag bits from the Aircraft Operational Status<br />
Message (see §C.2.3.10) <strong>and</strong> set the True/Magnetic Heading field in the ADS-B Report. This item within the<br />
ADS-B Report is used to indicate the nature of the Horizontal Direction in<strong>for</strong>mation being reported in the<br />
ADS-B Reports <strong>and</strong> Target State Reports. This applies to the aircraft reported Horizontal Direction (in the<br />
ADS-B Report).<br />
C.5.3.2.10 Air Referenced Velocity Reports<br />
The requirements <strong>for</strong> Air Referenced Velocity (ARV) Reports shall apply to the ARV Report Assembly<br />
requirements when the target aircraft is broadcasting either ADS-B Version One (1) or Version Two (2)<br />
Message <strong>for</strong>mats (Table A-2-9b).<br />
C.5.3.2.11 Target State Reports<br />
Note.— Since the content <strong>and</strong> use of Target State Reports changed between ADS-B Version One (1)<br />
<strong>and</strong> Version Two (2), there is no requirement <strong>for</strong> an ADS-B Version Two (2) receiving subsystem to output<br />
ADS-B Version One (1) Target State Reports.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix CD<br />
IMPLEMENTATION GUIDELINES<br />
CD.1 INTRODUCTION<br />
CD.1.1 GENERAL<br />
CD.1.1.1 This appendix provides implementation guidelines on data <strong>for</strong>mats <strong>for</strong> applications using <strong>Mode</strong> S specific<br />
services <strong>and</strong> extended squitter contained in Appendices A, B <strong>and</strong> B C of this document.<br />
CD.1.1.2 The appendix contains implementation guidelines <strong>for</strong> the following:<br />
a) Transponder Comm-B registers <strong>and</strong> extended squitter;<br />
b) <strong>Mode</strong> S specific protocols;<br />
c) <strong>Mode</strong> S broadcast protocols; <strong>and</strong><br />
d) <strong>Extended</strong> squitter ground stations.<br />
CD.1.1.3 The appendix is intended <strong>for</strong> use by the avionics industry <strong>and</strong> by the developers of air traffic services (ATS)<br />
applications.<br />
CD.1.2 MODE S SPECIFIC SERVICES OVERVIEW<br />
CD.1.2.1 <strong>Mode</strong> S specific services are data link services that can be accessed by a separate dedicated interface to the<br />
<strong>Mode</strong> S subnetwork. On the ground they can also be accessed via the aeronautical telecommunication network (ATN).<br />
They operate with a minimum of overhead <strong>and</strong> delay <strong>and</strong> use the link efficiently, which makes them highly suited to ATS<br />
applications.<br />
CD.1.2.2 There are three categories of service provided:<br />
Draft<br />
a) Ground-initiated Comm-B (GICB) protocol. This service consists of defined data available on board the aircraft<br />
being put into one of the 255 transponder registers (each with a length of 56 bits) in the <strong>Mode</strong> S transponder at<br />
specified intervals by a serving process, e.g. airborne collision avoidance system (ACAS) or the aircraft data<br />
link processor (ADLP). A <strong>Mode</strong> S ground interrogator or an ACAS unit can extract the in<strong>for</strong>mation from any of<br />
these transponder registers at any time <strong>and</strong> pass it <strong>for</strong> onward transmission to ground-based or aircraft<br />
applications.<br />
b) <strong>Mode</strong> S specific protocols (MSPs). This service uses one or more of the 63 uplink or downlink channels<br />
provided by this protocol to transfer data in either short- or long-<strong>for</strong>m MSP packets from the ground data link<br />
processor (GDLP) to the ADLP or vice versa.<br />
c) <strong>Mode</strong> S broadcast protocol. This service permits a limited amount of data to be broadcast from the ground to all<br />
aircraft. In the downlink direction, the presence of a broadcast message is indicated by the transponder, <strong>and</strong><br />
this message can be extracted by all <strong>Mode</strong> S systems that have the aircraft in coverage at the time. An<br />
identifier is included as the first byte of all broadcasts to permit the data content <strong>and</strong> <strong>for</strong>mat to be determined.<br />
CD-1<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CD-2 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
CD.1.2.3 In the case of an uplink broadcast, the application on board the aircraft will not be able to determine, other<br />
than on an interrogator identifier (II) or surveillance identifier (SI) code basis, the source of an interrogation. When<br />
necessary, the data source must be identified within the data field. On the downlink, however, the originating aircraft is<br />
known due to its aircraft address.<br />
CD.1.3 EXTENDED SQUITTER OVERVIEW<br />
<strong>Extended</strong> squitter is an ADS-B system utilizing the frequencies <strong>and</strong> <strong>for</strong>mats of the <strong>Mode</strong> S system <strong>for</strong> broadcasting<br />
ADS-B in<strong>for</strong>mation. The result is an integrated approach <strong>for</strong> surveillance that permits aircraft equipped with a <strong>Mode</strong> S<br />
transponder <strong>and</strong> an acceptable navigations source to participate in both ADS-B <strong>and</strong> beacon ground environments. This<br />
facilitates a smooth transition from a beacon-based to an ADS-B based environment. In addition, extended squitter can<br />
support hybrid surveillance. Hybrid surveillance is a technique <strong>for</strong> allowing ACAS to use passive ADS-B surveillance <strong>for</strong><br />
non-threatening aircraft to reduce its active interrogation rate.<br />
CD.2 DATA FORMATS FOR TRANSPONDER REGISTERS<br />
CD.2.1 TRANSPONDER REGISTER ALLOCATION<br />
Applications have been allocated transponder register numbers as specified in §A.2.1.<br />
Note 1.— The transponder register number is equivalent to the Comm-B data selector (BDS) value used to address<br />
that transponder register (see §3.1.2.6.11.2.1 of Annex 10, Volume IV).<br />
Note 2.— Data requirements <strong>and</strong> availability <strong>for</strong> the data to be entered into transponder registers are shown in<br />
§A.2.1.<br />
CD.2.2 GENERAL CONVENTIONS ON DATA FORMATS<br />
CD.2.2.1 VALIDITY OF DATA<br />
The bit patterns contained in the 56-bit transponder registers are considered as valid application data only if they comply<br />
with the conditions specified in Appendix A. Figure CD-1 is a summary of the provisions contained in Appendix A with<br />
respect to the loading <strong>and</strong> clearing of data into the transponder register.<br />
Numerical data are represented as follows:<br />
Draft<br />
CD.2.2.2 REPRESENTATION OF NUMERICAL DATA<br />
Whenever applicable, the resolution <strong>for</strong> data fields has been aligned with ICAO documents or with corresponding ARINC<br />
429 labels. Unless otherwise specified in the individual table, where ARINC 429 labels are given in the tables, they are<br />
given as an example <strong>for</strong> the source of data <strong>for</strong> that particular field. Other data sources providing equivalent data may be<br />
used.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix CD CD-3<br />
ACTIONS EVENTS<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Data update at<br />
the XPDR<br />
interface<br />
Field updates Register updates<br />
Field timer<br />
expiry (T1)<br />
Reset T1 Set the status<br />
bit of the field<br />
to 0 (if any)<br />
<strong>and</strong> ZERO<br />
Update the<br />
that data field<br />
data field<br />
A.2.1.1<br />
Figure CD-1. Detailed process <strong>for</strong> the clearing <strong>and</strong> loading of data in the fields of transponder register<br />
CD.2.3 DATA SOURCES FOR TRANSPONDER REGISTERS<br />
Draft<br />
Tables C-1-1 to C-1-6 show possible Typical ARINC labeled data sources that can be used to derive the required data<br />
fields in the transponder GICB registers are detailed in the latest published version of ARINC 718A. Data sources are<br />
identified with parameter range, resolution <strong>and</strong> update interval <strong>for</strong> typical Air Transport transponder applications.<br />
Alternatives are given where they have been identified.<br />
CD.2.4 FOR TRANSPONDER REGISTER FORMATTING<br />
CD.2.4.1 TRANSPONDER REGISTER 1016<br />
All T1s have<br />
expired T2 expiry<br />
Update register 17 16<br />
Item 2 of Table<br />
A-2-23<br />
Shaded boxes show the corresponding sections of Appendix A.<br />
Item 7 of Table<br />
A-2-16<br />
Reset T2<br />
T1 = a time no greater than twice the specified maximum update interval or 2s (whichever is the greater) —<br />
T1 is actually the contribution of the transponder to the data age. There are as many T1 timers as data fields<br />
in the transponder register.<br />
T2 = approximately 60s — used to control register 17 changes<br />
Current<br />
sample of<br />
register 1716<br />
different from<br />
previous<br />
sample?<br />
Toggle bit 36<br />
(Register 10 broadcast)<br />
The following sections state the requirements <strong>and</strong> guidance material that apply <strong>for</strong> the setting of some specific bits of<br />
transponder register 1016. These requirements are contained in Table A-2-16 of Appendix A or Annex 10, Volume IV.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
N<br />
16<br />
Y
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CD-4 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
CD.2.4.1.1 BIT 9 (CONTINUATION FLAG)<br />
This bit should be set as specified in Table A-2-16 of Appendix A.<br />
In order to determine the extent of any continuation of the data link capability report (into those registers reserved <strong>for</strong> this<br />
purpose: register 1116 to register 1616), bit 9 is reserved as a ‘continuation flag’ to indicate if the subsequent register can<br />
be extracted. For example: upon detection of bit 9=1 in register 1016 then register 1116 can be extracted. If bit 9=1 in<br />
register 1116 then register 1216 can be extracted, <strong>and</strong> so on (up to register 1616). Note that if bit 9=1 in register 1616 then<br />
this shall be considered as an error condition.<br />
As long as transponder registers 1116 to 1616 are undefined, bit 9 should be set to 0.<br />
CD.2.4.1.2 BIT 16 AND BITS 37-40 (ACAS BITS)<br />
The setting of these bits is dynamic. They are set by ACAS <strong>and</strong> possibly overwritten by the transponder.<br />
These bits should be set as specified in Table A-2-16.<br />
Bit 16 should be set to ONE (1) to indicate that the transponder ACAS interface is operational <strong>and</strong> the transponder is<br />
receiving TCAS RI=2, 3 or 4.<br />
Bit 37 should be set to ONE (1) to indicate the capability of Hybrid Surveillance, <strong>and</strong> set to ZERO (0) to indicate that<br />
there is no Hybrid Surveillance capability.<br />
Bit 38 should be set to ONE (1) to indicate that the ACAS is generating both TAs <strong>and</strong> RAs, <strong>and</strong> set to ZERO (0) to<br />
indicate the generation of TAs only.<br />
Bits 39 <strong>and</strong> 40 should be set according to the ACAS version:<br />
Bit 40 Bit 39 Meaning<br />
0 0 RTCA DO-185 (6.04A) (see Note 2)<br />
0 1 RTCA DO-185A (see Note 2)<br />
1 0 RTCA DO-185B / EUROCAE ED-143<br />
1 1 Reserved <strong>for</strong> future versions<br />
Note 1.— Future versions of ACAS will be identified using Part Numbers <strong>and</strong> Software Version Numbers<br />
specified in Registers E516 <strong>and</strong> E616.<br />
Note 2.— RTCA DO-185 equipment is also referenced as TCAS logic version 6.04A. Equipment compliant to<br />
RTCA DO-185A, or later versions, are SARPs compliant.<br />
CD.2.4.1.3 BITS 17-23 (MODE S SUBNETWORK VERSION NUMBER)<br />
These bits should be set as specified in Table A-2-16 of Appendix A.<br />
17-23 <strong>Mode</strong> S subnetwork version number.<br />
0 = <strong>Mode</strong> S subnetwork not available<br />
1 = Version No. 1 (ICAO Doc 9688 - 1996)<br />
2 = Version No. 2 (ICAO Doc 9688 - 1998)<br />
3 = Version No. 3 (Annex 10 Vol III, Amendment 77 - 2002)<br />
4 = Version No. 4 (2007), 1st Edition of this document<br />
5 = Version No. 5 2nd Edition of this document<br />
56-127 = Unassigned<br />
Draft<br />
The <strong>Mode</strong> S subnetwork version number should be set to a non-zero value if at least one DTE or <strong>Mode</strong> S specific<br />
service is installed. For example, if register 4016 is loaded with data, it means that the GICB service associated to<br />
register 4016 is installed. In that case bits 17-23 will be set to a non-zero value, e.g. value 3 if the <strong>for</strong>mat of register 4016<br />
meets the requirements of Amendment 77 (applicable in 2002).<br />
If the installed DTE or the <strong>Mode</strong> S specific services meet the requirements of Amendment 71 <strong>and</strong> ICAO Doc 9688<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix CD CD-5<br />
(applicable in 1996) only, then the <strong>Mode</strong> S subnetwork number should be set to 1.<br />
If the installed DTE or the <strong>Mode</strong> S specific services meet the requirements of Amendment 73 (applicable in 1998) only<br />
<strong>and</strong>/or the transponder register <strong>for</strong>mats meet the requirements of Doc 9688 version 1, then the <strong>Mode</strong> S subnetwork<br />
number should be set to 2.<br />
If the installed DTE or the <strong>Mode</strong> S specific services meet the requirements of Amendment 77, then the <strong>Mode</strong> S<br />
subnetwork number should be set to 3.<br />
If the installed DTE or the <strong>Mode</strong> S specific services meet the requirements of ICAO Doc 9871, Edition 1, then the <strong>Mode</strong><br />
S subnetwork version number should be set to 4.<br />
If the installed DTE or the <strong>Mode</strong> S specific services meet the requirements of ICAO Doc 9871, Edition 2, which<br />
additionally complies with RTCA DO-181D <strong>and</strong> EUROCAE ED-73C, including Change 1, then the <strong>Mode</strong> S subnetwork<br />
version number should be set to 5.<br />
The setting of these bits is static.<br />
CD.2.4.1.4 BIT 24 (TRANSPONDER ENHANCED PROTOCOL INDICATOR)<br />
This bit is set to 1 when the transponder is a level 5 transponder. This bit is set by the transponder itself. It is a static bit.<br />
CD.2.4.1.5 BIT 25 (MODE S SPECIFIC SERVICES CAPABILITY)<br />
This bit should be set as specified in Table A-2-16, item 2 of Appendix A.<br />
When bit 25 is set to 1, it indicates that at least one <strong>Mode</strong> S specific service is supported <strong>and</strong> the particular capability<br />
reports should be checked.<br />
Note.— Registers accessed by BDS codes 0,2; 0,3; 0,4; 1,0; 1,7 through 1,C; 2,0 <strong>and</strong> 3,0 do not affect the setting of<br />
bit 25.<br />
This bit actually indicates if the aircraft installation enables the loading of airborne parameters in at least one register not<br />
accessed by the BDS codes mentioned above.<br />
The setting of this bit is preferably static.<br />
Draft<br />
CD.2.4.1.6 BITS 26-32 (UPLINK AND DOWNLINK ELM THROUGHPUT CAPABILITY)<br />
Bits 26-28 indicate the uplink ELM average throughput capability. These bits are set by the transponder <strong>and</strong> are<br />
preferably static.<br />
Bits 29-32 indicate the throughput capability of downlink ELM containing the maximum number of ELM segments that<br />
the transponder can deliver in response to an interrogation. These bits are set by the transponder <strong>and</strong> are preferably<br />
static.<br />
CD.2.4.1.7 BIT 33 (AIRCRAFT IDENTIFICATION CAPABILITY)<br />
This bit should be set as required in Annex 10, Volume IV, §3.1.2.9.1.3:<br />
Aircraft identification capability report. Transponders which respond to a ground-initiated request <strong>for</strong> aircraft identification<br />
shall report this capability in the data link capability report (Annex 10, Volume IV, §3.1.2.6.10.2.2.2) by setting bit 33 of<br />
the MB subfield to 1.<br />
This bit actually indicates whether the aircraft installation supports an interface to load the aircraft identification into the<br />
transponder register 2016. It does not take into account the consistency of the data loaded into the register.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CD-6 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
The setting of this bit is preferably dynamic. In case it is statically h<strong>and</strong>led it should be <strong>for</strong>ced to 1.<br />
When this bit is dynamic, it is always equal to bit 7 of register 1716. It might be different from bit 25 of register 1816 since<br />
the bits of registers 1816 to 1C16 are not reset once they are set. If the interface availability changes during the flight,<br />
bit 33 of register 1016 <strong>and</strong> bit 7 of register 1716 will be updated accordingly whereas bit 25 of register 1816 will remain<br />
unchanged.<br />
This is explained in notes 1 <strong>and</strong> 2 of §A.2.2.1.<br />
Note 1.— The intent of the capability bits in register number 1716 is to indicate that useful data are contained in the<br />
corresponding transponder register. For this reason, each bit <strong>for</strong> a register is cleared if data becomes unavailable (see<br />
§A.2.5.4.1) <strong>and</strong> set again when data insertion into the register resumes.<br />
Note 2.— A bit set in register numbers 1816 to 1C16 indicates that the application using this register has been<br />
installed on the aircraft. These bits are not cleared to reflect the real-time loss of an application, as is done <strong>for</strong> register<br />
number 1716 (see §A.2.5.4.2).<br />
It is also to be noted that register 1016 will be broadcast twice following the interface availability change. The first time<br />
because bit 33 will change, then because bit 36 will also toggle approximately one minute later to indicate that the<br />
content of register 1716 has changed.<br />
CD.2.4.1.8 BIT 34 (SQUITTER CAPABILITY SUBFIELD)<br />
This bit should be set as specified in Table A-2-16 of Appendix A.<br />
The squitter capability subfield (SCS) is interpreted as follows:<br />
0 = squitter registers are not updated<br />
1 = squitter registers are being updated<br />
SCS: This 1-bit squitter capability subfield reports the capability of the transponder to transmit extended squitter position<br />
reports. It shall be set to 1 if BDS registers 05 <strong>and</strong> 06 {HEX} have been updated within the last ten plus or minus one<br />
seconds. Otherwise, it shall be set to 0.<br />
Bit 34 is there<strong>for</strong>e an AND of bits 1 <strong>and</strong> 2 of transponder register 1716 <strong>and</strong> the setting of this bit is dynamic.<br />
Note that register 1016 will be broadcast twice in case bit 34 changes. The first time because bit 34 will change, then<br />
because bit 36 will also toggle one minute later to indicate that the content of register 1716 has changed.<br />
CD.2.4.1.9 BIT 35 (SI CODE CAPABILITY)<br />
This bit should be set as specified in Table A-2-16 of Appendix A, item 6.<br />
The surveillance identifier code (SIC) bit is interpreted as follows:<br />
0 = no surveillance identifier code capability<br />
1 = surveillance identifier code capability<br />
Draft<br />
SIC: This 1-bit surveillance identifier capability subfield reports the capability of the transponder to support the<br />
surveillance identifier (SI) codes.<br />
The setting of this bit is static. If the transponder software version h<strong>and</strong>les SI codes then this bit should be set to 1.<br />
CD.2.4.1.10 BIT 36 (COMMON USAGE GICB CAPABILITY REPORT)<br />
This bit should be set as specified in Table A-2-16 of Appendix A, item 7.<br />
Bit 36 toggles each time the common usage GlCB capability report (BDS code 1,7) changes. To avoid the generation of<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix CD CD-7<br />
too many broadcast capability report changes, BDS code 1,7 is sampled at approximately one minute intervals to check<br />
<strong>for</strong> changes. The setting of this bit is there<strong>for</strong>e dynamic.<br />
CD.2.4.2 TRANSPONDER REGISTER 1816 TO 1c16<br />
The bits contained in Registers 1816 to 1C16 indicate the capability of the installation <strong>and</strong> are there<strong>for</strong>e specific to the<br />
plat<strong>for</strong>m on which the transponder is installed.<br />
It is accepted that these bits can be set once the corresponding data has been received by the transponder over a<br />
period of time. This can happen at any time <strong>and</strong> not only during the power-on cycle of the transponder as equipment<br />
providing expected in<strong>for</strong>mation could be powered-on later.<br />
Once a bit is set, it remains set until the power-off of the transponder.<br />
CD.2.4.3.1 AIRBORNE FUNCTION<br />
CD.2.4.3 TRANSPONDER REGISTER 2016<br />
Annex 10, Volume IV requirements (Annex 10, Volume IV, §3.1.2.9.1.1) state the following <strong>for</strong> data in transponder<br />
register 2016:<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
“AIS, aircraft identification subfield in MB. The transponder shall report the aircraft identification in the 48-bit (41-88) AIS<br />
subfield of MB. The aircraft identification transmitted shall be that employed in the flight plan. When no flight plan is<br />
available, the registration marking of the aircraft shall be inserted in this subfield.<br />
Note.— When the registration marking of the aircraft is used, it is classified as ‘fixed direct data’ (3.1.2.10.5.1.1).<br />
When another type of aircraft identification is used, it is classified as ‘variable direct data’ (3.1.2.10.5.1.3).”<br />
When the aircraft installation does not use an external source to provide the aircraft identification (most of the time it will<br />
be the call sign used <strong>for</strong> communications between pilot <strong>and</strong> controllers), the text above means that the aircraft<br />
identification is considered as variable direct data. It also means that such data characterize the flight condition of the<br />
aircraft (not the aircraft itself) <strong>and</strong> are there<strong>for</strong>e subject to dynamic changes. It further means that variable direct data are<br />
also subject to the following requirement when data become unavailable.<br />
Paragraph §A.2.1.1 states:<br />
Draft<br />
“If data are not available <strong>for</strong> a time no greater than twice the specified maximum update interval or 2 seconds (whichever<br />
is the greater), the status bit (if specified <strong>for</strong> that field) shall indicate that the data in that field are invalid <strong>and</strong> the field<br />
shall be zeroed.”<br />
There<strong>for</strong>e, if the external source providing the aircraft identification fails or delivers corrupted data, transponder register<br />
2016 should be zeroed. It should not include the registration marking of the aircraft since the airborne installation has<br />
initially been declared as providing variable direct data <strong>for</strong> the aircraft identification.<br />
The loss of the aircraft identification data will be indicated to the ground since transponder register 2016 will be broadcast<br />
following its change. If the registration marking of the aircraft was inserted in lieu of the call sign following a failure of the<br />
external source, it would not help the ground systems since the registration marking of the aircraft is not the in<strong>for</strong>mation<br />
that was inserted in the aircraft flight plan being used by the ground ATC systems.<br />
In conclusion, the aircraft identification is either fixed (aircraft registration) or variable direct data (call sign). It depends<br />
whether the aircraft installation uses a data source providing the call sign; if so, data contained in transponder register<br />
2016 should meet the requirement of the SARPs. When data become unavailable because of a data source failure,<br />
transponder register 2016 should contain all zeros.<br />
CD.2.4.3.2 GROUND CONSIDERATIONS<br />
Aircraft identification data can be used to correlate surveillance in<strong>for</strong>mation with flight plan in<strong>for</strong>mation. If the data source<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CD-8 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
providing the aircraft identification fails, the aircraft identification in<strong>for</strong>mation will no longer be available in the surveillance<br />
data flow. In this case, the following means could enable the ground system to continue correlating the surveillance <strong>and</strong><br />
flight plan in<strong>for</strong>mation of a given target.<br />
If the aircraft identification is used to correlate surveillance <strong>and</strong> flight plan data, extra in<strong>for</strong>mation such as the <strong>Mode</strong> A<br />
code, if any, <strong>and</strong> the ICAO 24-bit aircraft address of the target could be provided to the flight data processing system.<br />
This would enable the update of the flight plan of the target with this extra in<strong>for</strong>mation.<br />
In case the aircraft identification becomes unavailable, it would still be possible to correlate both data flows using (<strong>for</strong><br />
example) the ICAO 24-bit aircraft address in<strong>for</strong>mation to per<strong>for</strong>m the correlation. It is there<strong>for</strong>e recommended that<br />
ground systems update the flight plan of a target with extra identification in<strong>for</strong>mation that is available in the surveillance<br />
data flow, e.g. the ICAO 24-bit aircraft address, the <strong>Mode</strong> A code (if any) or the tail number (if available from transponder<br />
register 2116).<br />
This extra identification in<strong>for</strong>mation might then be used in lieu of the aircraft identification in<strong>for</strong>mation contained in<br />
transponder register 2016 in case the data source providing this in<strong>for</strong>mation fails.<br />
D.2.4.3.3 IMPLEMENTATION CONSIDERATIONS FOR IDENTIFICATION REGISTER 0816<br />
If <strong>Extended</strong> <strong>Squitter</strong> is implemented, then §A.2.1 Note 3 <strong>and</strong> §A.2.4.2 Note 2 provide an introduction to Register 0816<br />
implementation. Implementation of Register 0816 should also consider the following:<br />
a. If valid Flight Identification data is available, then the data should be used to populate the character subfields in<br />
Register 0816.<br />
b. After using Flight Identification data to populate the character subfields in Register 0816 in a given power-on cycle, if<br />
Flight Identification data becomes invalid or not available, then the last known valid Flight Identification data should<br />
be retained <strong>and</strong> used to continue population of the character subfields in Register 0816 <strong>for</strong> the duration of the poweron<br />
cycle.<br />
c. If valid Flight Identification data is not available, but valid Aircraft Registration data is available in a given power-on<br />
cycle, then the valid Aircraft Registration data should be used to populate the character subfields in Register 0816 <strong>for</strong><br />
the duration of the power-on cycle.<br />
d. If Register 0816 has been populated using Aircraft Registration data in a given power-on cycle, <strong>and</strong> valid Flight<br />
Identification data becomes available, then the Flight Identification data should be used to populate the character<br />
subfields in Register 0816 <strong>for</strong> the remainder of the power-on cycle.<br />
e. Once valid Flight Identification data has been used to populate Register 0816 in a given power-on cycle, Aircraft<br />
Registration data should not be used to populate the character subfields of Register 0816, even if Flight Identification<br />
data becomes invalid or not available during the power-on cycle.<br />
Draft<br />
CD.2.4.4 TRANSPONDER REGISTER NUMBER 4016<br />
Paragraph §CD.2.4.4.1 gives a general example of what are the different selected altitudes <strong>and</strong> the relationship with the<br />
target altitude <strong>and</strong> introduces the meaning of the different parameters <strong>and</strong> notions used in this section.<br />
Paragraphs §CD.2.4.4.2, §CD.2.4.4.3 <strong>and</strong> §CD.2.4.4.4 provide more detailed in<strong>for</strong>mation <strong>for</strong> some specific plat<strong>for</strong>ms.<br />
CD.2.4.4.1 GENERAL EXAMPLE FOR THE LOADING OF DATA IN REGISTER 4016<br />
Figure CD-2 provides a general example <strong>for</strong> the loading of data in Register 4016.<br />
The goal of Figure CD-2 is to clarify the differences between the FMS selected altitude <strong>and</strong> the FCU/MCP selected<br />
altitude, <strong>and</strong> also to clarify how the target altitude of the aircraft <strong>and</strong> the MCP/FCU mode bits are determined depending<br />
on the phase of flight in the vertical profile.<br />
Notions <strong>and</strong> terms used:<br />
— Cleared flight level: Flight level cleared by the controller, i.e. the flight level aircraft should reach <strong>and</strong> maintain.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix CD CD-9<br />
— MCP/FCU selected altitude<br />
• The Autopilot Flight Director System (AFDS) is more commonly known as autopilot (A/P). Its task is to<br />
laterally <strong>and</strong> vertically control the aircraft when selected by the crew. In general in modern aircraft, the<br />
AFDS is a system consisting of several individual Flight Control Computers (FCCs) <strong>and</strong> a single Flight<br />
Control Panel (FCP) mounted directly between the pilots just under the windshield. Fundamentally, the<br />
autopilot attempts to acquire or maintain target parameters determined either by manual inputs made by<br />
the pilot or by computations from the Flight Management System.<br />
• MCP: <strong>Mode</strong> Control Panel is the usual name given on Boeing plat<strong>for</strong>ms to the FCP which provides control<br />
of the Autopilot, Flight Director, Altitude Alert <strong>and</strong> Autothrottle System. The MCP is used to select <strong>and</strong><br />
activate Autopilot Flight Director System (AFDS) modes <strong>and</strong> establish altitudes, speeds <strong>and</strong> climb/descent<br />
profiles.<br />
• FCU: Flight Control Unit is similar to MCP but <strong>for</strong> Airbus plat<strong>for</strong>ms.<br />
• MCP/FCU selected altitude: The altitude set by pilots on the MCP/FCU controlling the auto-pilot system. In<br />
the great majority of cases pilots set the MCP/FCU altitude to the altitude cleared by Air Traffic Control<br />
(ATC) be<strong>for</strong>e engaging a vertical mode. The autopilot will try to reach this MCP/FCU selected altitude<br />
using different selectable vertical modes: constant vertical rate (e.g. V/S), Flight Level change at a given<br />
airspeed (e.g. FL CH), vertical path given by the FMS (VNAV), <strong>and</strong> maintain it using the altitude hold mode<br />
(ALT HOLD).<br />
Note.— If the aircraft is not equipped with an autopilot this in<strong>for</strong>mation may be derived from equipment<br />
generating an alert when the FL is reached (e.g. altitude alerter system).<br />
— FMS selected altitude<br />
• The Flight Management System (FMS or FMC <strong>for</strong> Flight Management Computer) is a computer onboard<br />
aircraft that controls the navigation, per<strong>for</strong>mance, flight planning, <strong>and</strong> guidance aspects of flight. The FMS<br />
navigation component determines where the aircraft is. The FMS per<strong>for</strong>mance component calculates<br />
necessary per<strong>for</strong>mance data. The FMS flight planning component allows <strong>for</strong> the creation <strong>and</strong> modification<br />
of flight plans. The FMS guidance component issues comm<strong>and</strong>s necessary to guide the aircraft along the<br />
route programmed into the FMS. The current <strong>and</strong> programmed paths of the aircraft are monitored threedimensionally,<br />
by flying from waypoint to waypoint <strong>and</strong> by obeying crossing restrictions.<br />
Draft<br />
• The FMS guidance component will there<strong>for</strong>e compute selected altitude constraints to be reached at<br />
different points. This is known as FMS selected altitude. These selected altitudes are used to control the<br />
aircraft in specific modes of autopilot, <strong>for</strong> example, when Vertical Navigation mode (VNAV) is selected on<br />
MCP/FCU. VNAV mode is the highest level of vertical profile automation, <strong>and</strong> maximizes fuel economy.<br />
— Target altitude: this is the next altitude at which the aircraft will level-off if in a climb or descent, or the aircraft<br />
current intended altitude if it is intending to hold its altitude.<br />
• The target altitude may be:<br />
• The MCP/FCU selected altitude when the autopilot is directly controlled by comm<strong>and</strong> entered by the<br />
crew.<br />
• The FMS selected altitude when in VNAV or similar modes.<br />
• The current altitude.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CD-10 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
• Unknown.<br />
— MCP/FCU mode bits:<br />
• VNAV indicates when a VNAV or equivalent mode in which the A/P is controlled by FMS is selected.<br />
• ALT HOLD indicates when A/P Alt Hold mode is selected. It does not correspond to a general altitude<br />
capture <strong>and</strong> does not cover VNAV hold situation.<br />
• Approach indicates that a mode to capture ILS localizer <strong>and</strong> glide slope is engaged.<br />
— Priority of MCP/FCU selected altitude on FMS selected altitude<br />
The MCP/FCU selected altitude is the altitude that the aircraft shall not violate <strong>and</strong> there<strong>for</strong>e it has always<br />
priority on FMS selected altitude.<br />
Explanation of the different steps in Figure CD-2:<br />
Generally, Figure CD-2 shows a theoretical sequence of cases which should not be considered as a real operational<br />
sequence. For example, some steps may be more realistic when the aircraft is in descent.<br />
Step 1: The MCP/FCU selected altitude has been set to first cleared flight level (FL100). The Autopilot/Flight Director is<br />
engaged <strong>and</strong> the aircraft is holding the latest MCP/FCU selected altitude which has been reached be<strong>for</strong>e step 1. The<br />
target altitude is the MCP/FCU selected altitude. VNAV mode is not engaged. The FMS selected altitude is not the target<br />
altitude.<br />
Step 2: A new clear flight level has been allocated to the aircraft by ATC. The pilot has entered this value into the<br />
MCP/FCU resulting in a new MCP/FCU selected altitude. The pilot has engaged the VNAV mode. The aircraft<br />
speed/path is determined by the FMS. The FMS contains a flight path with an altitude restriction at a given waypoint<br />
(FL250). The FMS selected altitude corresponds to the associated altitude restriction. This FMS selected altitude is less<br />
than the MCP/FCU selected altitude <strong>and</strong> there<strong>for</strong>e becomes the target altitude to which the aircraft is climbing.<br />
Step 3: There is an altitude restriction associated with a waypoint. The aircraft has captured <strong>and</strong> is maintaining the FMS<br />
selected altitude until crossing the waypoint. The VNAV mode remains active. In an operational environment, aircrew<br />
should also set the MCP/FCU altitude to the intermediate levels on a stepped climb SID if workload permits.<br />
Draft<br />
Step 4: The waypoint with restricted altitude is passed. A new FMS selected altitude is now valid. The aircraft resumes<br />
its climbing to try to reach this new FMS selected altitude. VNAV mode is still engaged. Although the aircraft is trying to<br />
reach the FMS selected altitude (FL350) it will level off at the MCP/FCU selected altitude, which is lower than the FMS<br />
selected altitude, there<strong>for</strong>e the selected altitude is the MCP/FCU selected altitude.<br />
Step 5: The MCP/FCU selected altitude is lower than the FMS selected altitude. The aircraft there<strong>for</strong>e first approaches<br />
this MCP/FCU selected altitude which is a limit to not violate. This MCP/FCU altitude is captured <strong>and</strong> held by the aircraft.<br />
This automatically disengages the VNAV mode.<br />
Step 6: The flight crew has disengaged the autopilot <strong>and</strong> is flying the aircraft manually. The target altitude is not known.<br />
However on an operational point of view it must be noted that such mode would not be allowed in regulated airspace<br />
unless the aircrew had declared an emergency or had obtained a new ATC clearance. In the latter case the ATC<br />
clearance should be entered in the MCP/FCU. It is more probable that this case may happen on a “descent when ready”<br />
profile. In all cases, the MCP/FCU selected altitude may still be useful because it should be the value used in the altitude<br />
alerter.<br />
Step 7: The pilot selects altitude hold (Alt Hold or equivalent mode) making the current altitude equivalent to the target<br />
altitude. Note that although MCP/FCU selected altitude could become the same (pilot entering the new flight level in the<br />
MCP/FCU) this is not m<strong>and</strong>atory <strong>and</strong>, there<strong>for</strong>e, only altitude represents with full confidence the level the aircraft is<br />
maintaining.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix CD CD-11<br />
CD.2.4.4.1.1 Target Altitude Summary<br />
If MCP/FCU altitude is between your current altitude <strong>and</strong> FMS Selected Altitude, then the target altitude is MCP/FCU. If<br />
VNAV is engaged <strong>and</strong> the previous case is not in effect, then FMS is the target altitude. If Alt Hold is selected <strong>and</strong> the<br />
current altitude is not equal to either of the selected altitudes, then target altitude is altitude.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
CD-12 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
General example <strong>for</strong> the loading of data in register 40 16<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Hypothesis on in<strong>for</strong>mation available to transponder<br />
The FMS selected altitude (calculated by the FMS) <strong>and</strong> the target altitude source in<strong>for</strong>mation are available on aircraft buses (this is not<br />
necessarily the case today) as well as the MCP/FCU mode bits. Bits 48 <strong>and</strong> 54 are set to 1 all the time with this hypothesis. The reverse<br />
hypothesis would require bits 48–51 <strong>and</strong> bits 54–56 to be all set to 0 <strong>and</strong> the FMS selected altitude field to be all zeroed.<br />
Pilot selects<br />
ALT HOLD mode<br />
The autopilot holds the<br />
current aircraft altitude<br />
MCP/FCU selected altitude captured (ALT CAP)<br />
VNAV mode automatically disengaged<br />
ALT HOLD mode automatically selected<br />
New cleared flight level entered in MCP/FCU<br />
Selection of VNAV or equivalent mode where<br />
flight is controlled by FMS<br />
Pilot disengages autopilot <strong>and</strong><br />
flights manual<br />
Intermediate FMS selected<br />
altitude capture <strong>and</strong> hold<br />
Draft<br />
Autopilot/flight director engaged<br />
Cleared flight level 1 (FL100) entered in MCP/FCU<br />
Holding last MCP/FCU selected altitude<br />
New FMS selected<br />
altitude<br />
FL 350<br />
FL 300<br />
Selected altitude<br />
calculated by the FMS<br />
in order to fulfil flight<br />
plan <strong>and</strong> best vertical<br />
profile<br />
FL 250<br />
MCP/FCU<br />
Selected altitude<br />
=<br />
Cleared flight level<br />
FL 100<br />
Aircraft flight path<br />
MCP/FCU selected altitude 100 300 300 300 300 300 300<br />
FMS selected altitude 250 250 250 350 350 350 350<br />
MCP/FCU mode bits Provided 1 1 1 1 1 1 1<br />
VNAV 0 1 1 1 0 0 0<br />
Alt hold 1 0 0 0<br />
1 0 1<br />
Approach 0 0 0 0 0 0 0<br />
Figure D-2. General example <strong>for</strong> the loading of data in register 4016<br />
Register<br />
4016 content<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
FCU/MCP FMS FMS FCU/MCP FCU/MCP Unknown Altitude<br />
Target altitude<br />
(Unknown, Altitude, FCU/MCP, FMS)<br />
1 2 3 4 5 6 7<br />
Step
Appendix CD CD-13<br />
CD.2.4.4.1.2 Possible uses of selected altitude <strong>and</strong> target altitude<br />
1. MCP/FCU selected altitude will be downlinked as an additional read-back in order to check that the cleared flight<br />
level has been correctly understood <strong>and</strong> entered in the airborne system by the pilot.<br />
2. Target altitude <strong>and</strong> associated mode of flight may be of interest to reduce the Short Term Conflict Alert false alarm<br />
rate.<br />
CD.2.4.4.1.3 Target altitude implementation difficulties<br />
It is recognized that all in<strong>for</strong>mation to determine which altitude is the target altitude or which mode of flight is currently<br />
used may not always be available to the transponder in the current airborne implementation. In addition it may be very<br />
dependent on the plat<strong>for</strong>m. It is there<strong>for</strong>e preferable to set to 0 the corresponding bits of register 4016 rather than<br />
sending wrong in<strong>for</strong>mation.<br />
CD.2.4.4.2 TRANSPONDER REGISTER NUMBER 4016 ON AIRBUS AIRCRAFT<br />
CD.2.4.4.2.1 Target altitude<br />
In order to clarify how aircraft intention in<strong>for</strong>mation is reported in transponder register 4016 a mapping (Table CD-2) has<br />
been prepared to illustrate, <strong>for</strong> a number of conditions:<br />
a) how the altitude data are derived that are loaded into transponder register 4016, <strong>and</strong><br />
b) how the corresponding source bits are set.<br />
CD.2.4.4.2.1.1 A330/A340 family<br />
Auto pilot or<br />
flight director<br />
status<br />
(AP on <strong>and</strong> FD<br />
on/off) or (AP off<br />
<strong>and</strong> FD on)<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table CD-2. Transponder register number 4016 on Airbus A330/340 aircraft<br />
Auto pilot or<br />
flight director vertical<br />
mode<br />
Conditions: vertical status/altitude<br />
(FCU, FMS or aircraft)<br />
Target<br />
altitude<br />
used Bit 55 Bit 56<br />
Draft<br />
Vertical speed (V/S) V/S > ( ( () A/C ALT / 0 0<br />
V/S = 0 A/C ALT 0 1<br />
FPA > ( ( () A/C ALT / 0 0<br />
FPA = 0 A/C ALT 0 1<br />
Aircraft operating with FCU altitude FCU ALT 1 0<br />
Aircraft capturing a constrained altitude imposed<br />
by the FMS<br />
FMS ALT 1 1<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
CD-14 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Auto pilot or<br />
flight director<br />
status<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Auto pilot or<br />
flight director vertical<br />
mode<br />
Conditions: vertical status/altitude<br />
(FCU, FMS or aircraft)<br />
Target<br />
altitude<br />
used Bit 55 Bit 56<br />
Altitude hold (ALT) A/C ALT 0 1<br />
Descent (DES) FCU ALT > next FMS ALT FCU ALT 1 0<br />
Open descent<br />
(OPEN DES)<br />
FCU ALT ≤ next FMS ALT FMS ALT 1 1<br />
No next FMS ALT FCU ALT 1 0<br />
<strong>Mode</strong> used to descend directly to the FCU ALT<br />
disregarding the computed descent path <strong>and</strong> FMS<br />
constraints<br />
FCU ALT 1 0<br />
Climb (CLB) FCU ALT < next FMS ALT FCU ALT 1 0<br />
FCU ALT ≥ next FMS ALT FMS ALT 1 1<br />
No next FMS ALT FCU ALT 1 0<br />
Open climb (OPEN CLB) <strong>Mode</strong> used to climb directly to the FCU ALT<br />
disregarding the computed descent path <strong>and</strong> FMS<br />
constraints<br />
FCU ALT 1 0<br />
Take off (TO) FCU ALT < next FMS ALT FCU ALT 1 0<br />
FCU ALT ≥ next FMS ALT FMS ALT 1 1<br />
No next FMS ALT FCU ALT 1 0<br />
Go around (GA) FCU ALT > A/C ALT <strong>and</strong> FCU ALT < next<br />
FMS ALT<br />
Other vertical modes (final<br />
approach, l<strong>and</strong>, glide<br />
slope)<br />
FCU ALT > A/C ALT <strong>and</strong> FCU ALT ≥ next<br />
FMS ALT<br />
FCU ALT 1 0<br />
FMS ALT 1 1<br />
FCU ALT > A/C ALT <strong>and</strong> no next FMS ALT FCU ALT 1 0<br />
FCU ALT ≤ A/C ALT / 0 0<br />
/ 0 0<br />
Draft<br />
AP off <strong>and</strong> FD off / 0 0<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix CD CD-15<br />
D.2.4.4.2.1.2 A320 family<br />
Auto pilot or<br />
flight director<br />
status<br />
(AP on <strong>and</strong> FD<br />
on/off) or (AP off<br />
<strong>and</strong> FD on)<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table CD-3. Transponder register number 4016 on Airbus A320 aircraft<br />
Auto pilot or<br />
flight director vertical<br />
mode<br />
Conditions: vertical status/altitude<br />
(FCU, FMS or aircraft)<br />
Target<br />
altitude<br />
used Bit 55 Bit 56<br />
Vertical speed (V/S) V/S > ( ( () A/C ALT / 0 0<br />
V/S = 0 A/C ALT 0 1<br />
FPA > ( ( () A/C ALT / 0 0<br />
FPA = 0 A/C ALT 0 1<br />
Aircraft operating with FCU altitude FCU ALT 1 0<br />
Aircraft capturing a constrained altitude imposed<br />
by the FMS<br />
FMS ALT 1 1<br />
Altitude hold (ALT) A/C ALT 0 1<br />
Descent (DES) or<br />
immediate descent<br />
(IM DES)<br />
Open descent<br />
(OPEN DES) or expedite<br />
(EXP)<br />
Climb (CLB) or immediate<br />
climb (IM CLB)<br />
Open climb (OPEN CLB)<br />
or expedite (EXP)<br />
FCU ALT > next FMS ALT FCU ALT 1 0<br />
FCU ALT ≤ next FMS ALT FMS ALT 1 1<br />
No next FMS ALT FCU ALT 1 0<br />
<strong>Mode</strong> used to descend directly to the FCU ALT<br />
disregarding the computed descent path <strong>and</strong><br />
FMS constraints<br />
FCU ALT 1 0<br />
FCU ALT < next FMS ALT FCU ALT 1 0<br />
FCU ALT ≥ next FMS ALT FMS ALT 1 1<br />
Draft<br />
No next FMS ALT FCU ALT 1 0<br />
<strong>Mode</strong> used to climb directly to the FCU ALT<br />
disregarding the computed descent path <strong>and</strong><br />
FMS constraints<br />
FCU ALT 1 0<br />
Take off (TO) FCU ALT < next FMS ALT FCU ALT 1 0<br />
FCU ALT ≥ next FMS ALT FMS ALT 1 1<br />
No next FMS ALT FCU ALT 1 0<br />
Go around (GA) FCU ALT > A/C ALT <strong>and</strong> FCU ALT < next<br />
FMS ALT<br />
Other vertical modes<br />
(final approach, l<strong>and</strong>,<br />
glide slope)<br />
FCU ALT > A/C ALT <strong>and</strong> FCU ALT ≥ next<br />
FMS ALT<br />
FCU ALT 1 0<br />
FMS ALT 1 1<br />
FCU ALT > A/C ALT <strong>and</strong> no next FMS ALT FCU ALT 1 0<br />
FCU ALT ≤ A/C ALT / 0 0<br />
/ 0 0<br />
AP off <strong>and</strong> FD off / 0 0<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CD-16 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
The A320 (see Table CD-3) has two additional modes compared to the A330/A340:<br />
• The Expedite <strong>Mode</strong>: it climbs or descends at, respectively, “green dot” speed or Vmax speed.<br />
• The Immediate <strong>Mode</strong>: it climbs or descends immediately while respecting the FMS constraints.<br />
CD.2.4.4.2.1.3 Synthesis<br />
Tables CD-2 <strong>and</strong> CD-3 show the following:<br />
a) Depending on the AP/FD vertical modes <strong>and</strong> some conditions, the desired “target” altitude might differ.<br />
There<strong>for</strong>e a logical software combination should be developed in order to load the appropriate parameter in<br />
transponder register 4016 with its associated source bit value <strong>and</strong> status.<br />
b) A large number of parameter values are required to implement the logic: the V/S, the FCU ALT, the A/C ALT,<br />
the FPA, the FMS ALT <strong>and</strong> the AP/FD status <strong>and</strong> vertical modes. The following labels might provide the<br />
necessary in<strong>for</strong>mation to satisfy this requirement:<br />
1. V/S: label 212 (Vertical Rate) from ADC<br />
2. FCU ALT: label 102<br />
from FCC<br />
(Selected Altitude)<br />
3. A/C ALT: label 361<br />
from IRS/ADIRS<br />
(Inertial Altitude)<br />
4. FPA: label 322<br />
from FMC<br />
(Flight Path Angle)<br />
5. FMS ALT: label 102<br />
from FMC<br />
(Selected Altitude)<br />
6. AP/FD: labels 272<br />
273 (Arm modes) <strong>and</strong><br />
274 (Pitch modes).<br />
(Auto-throttle modes),<br />
Draft<br />
The appropriate “target” altitude should, whatever its nature (A/C, FMS or FCU), be included in a dedicated label<br />
(e.g. 271) which would be received by the GFM that will then include it in transponder register 4016. A dedicated label<br />
(such as label 271) could then contain the in<strong>for</strong>mation on the source bits <strong>for</strong> target altitude. This is demonstrated<br />
graphically in Figure C-3.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix CD CD-17<br />
AP/FD mode<br />
V/S-FPA value<br />
FMS ALT<br />
A/C ALT<br />
AP/FD status<br />
FCU ALT<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Figure CD-3. Logic to derive the target altitude data in<strong>for</strong>mation<br />
D.2.4.4.2.2 Selected altitude from the altitude control panel<br />
When selected altitude from the altitude control panel is provided in bits 1 to 13, the status <strong>and</strong> mode bits (48 – 51) may<br />
be provided from the following sources:<br />
Status of altitude control panel<br />
mode bits (bit 48)<br />
Managed vertical mode (bit 49) Label 274 bit 11 (climb)<br />
Label 274 bit 12 (descent)<br />
Bus FMGC A<br />
Altitude hold mode (bit 50) Label 274 bit 19 (Alt mode)<br />
Bus FMGC A<br />
Approach mode (bit 51) Label 273 bit 23<br />
Bus AFS FCU<br />
A320 A340<br />
SSM labels 273/274 SSM labels 274/275<br />
Label 275 bit 11 (climb)<br />
Label 275 bit 15 (descent)<br />
Bus FMGEC G GE-1<br />
Label 275 bit 20 (Alt hold)<br />
Bus FMGEC G GE-1<br />
Label 273 bit 15<br />
Bus AFS FCU<br />
Draft<br />
CD.2.4.4.3 TRANSPONDER REGISTER NUMBER 4016 ON BOEING 747-400, 757 AND 767 AIRCRAFT<br />
In order to clarify how selected altitude in<strong>for</strong>mation from the altitude control panel <strong>and</strong> target altitude is reported in<br />
transponder register 4016, a mapping has been prepared to illustrate how the status <strong>and</strong> mode bits can be derived.<br />
Transponder<br />
register<br />
bit no. Description Label<br />
48 Status of mode bits SSM of 272 <strong>and</strong> 273<br />
49 Managed vertical mode 272 bit 13<br />
50 Altitude hold mode 272 bit 9 / 273 bit 19<br />
51 Approach mode 272 bit 9 / 273 bit 19<br />
54 Status of target altitude source bits SSM of new label (TBD)<br />
55<br />
56<br />
LOGIC<br />
Target altitude (label TBD)<br />
Target altitude source bits (label 271)<br />
Target altitude source bits New label (TBD)<br />
General <strong>for</strong>mat<br />
manager (GFM)<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CD-18 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
The selected altitude from the mode control panel may be obtained from label 102 (source ID 0A1). The status bit may<br />
be derived from the SSM of label 102.<br />
CD.2.4.4.4 SETTING OF THE TARGET ALTITUDE SOURCE BITS (BITS 54-56)<br />
These bits should be set as required in Appendix A, Table A-2-64, item 5:<br />
Bit 54 indicates whether the target altitude source bits (55 <strong>and</strong> 56) are actively being populated.<br />
0 = No source in<strong>for</strong>mation provided<br />
1 = Source in<strong>for</strong>mation deliberately provided<br />
Bits 55 <strong>and</strong> 56, indicate target altitude source:<br />
00 = Unknown<br />
01 = Aircraft altitude<br />
10 = FCU/MCP selected altitude<br />
11 = FMS selected altitude<br />
Aircraft which are not equipped with the logic described in §CD.2.4.3.1 <strong>and</strong> §CD.2.4.3.2 are not able to determine the<br />
target altitude source of the aircraft. In that case bit 54 should be set to 0 (no source in<strong>for</strong>mation provided) <strong>and</strong> bits 55<br />
<strong>and</strong> 56 should be set to 00 (unknown).<br />
D.2.4.4.5 SETTING OF THE RESERVED BITS (BITS 40 TO 47, 52 & 53)<br />
Bits 40 to 47, 52 <strong>and</strong> 53 of Register 4016 “MB” field should be set to ZERO (0).<br />
CD.2.4.5 TRANSPONDER REGISTER 5016<br />
When ARINC 429 data is used an example implementation is the following:<br />
BDS Data<br />
bit no. bit no. Description<br />
1 STATUS 1 = valid data<br />
2 SIGN 1 = left (left wing down)<br />
3<br />
4<br />
MSB=45 degrees<br />
5 Roll angle<br />
6<br />
7<br />
ARINC label 325<br />
8<br />
9<br />
10<br />
Range = [-90, +90]<br />
11 LSB = 45/256 degrees<br />
12 STATUS 1 = valid data<br />
13 SIGN 1 = west (e.g. 315°= -45°)<br />
14<br />
15<br />
16<br />
MSB = 90 degrees<br />
17 True track angle<br />
18<br />
19<br />
ARINC label 313<br />
20<br />
21<br />
22<br />
Range = [-180, +180]<br />
23 LSB = 90/512 degrees<br />
24 STATUS 1 = valid data<br />
25<br />
26<br />
MSB = 1 024 kt<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix CD CD-19<br />
BDS<br />
bit no.<br />
Data<br />
bit no. Description<br />
27<br />
28 Ground speed<br />
29 ARINC label 312<br />
30<br />
31 Range = [0, 2 046]<br />
32<br />
33<br />
34 LSB = 1 024/512 = 2kt<br />
35 STATUS 1 = valid data<br />
36 SIGN 1 = minus<br />
37 MSB = 8 degrees/s<br />
38<br />
39 Track angle rate<br />
40 ARINC label 335<br />
41<br />
42 Range = [ -16, +16]<br />
43<br />
44<br />
45 LSB = 8/256 degrees<br />
46 STATUS 1 = valid data<br />
47 MSB = 1 024 kt<br />
48<br />
49 True air speed<br />
50 ARINC label 210<br />
51<br />
52 Range = [0, 2 046]<br />
53<br />
54<br />
55<br />
56 LSB = 1 024/512 = 2 kt<br />
The status bits are determined as explained in §A.2.2.2. The data is rounded as specified in §A.2.2.2. The encoding<br />
accuracy of the data in the subfield is ±½ LSB by rounding.<br />
For ARINC GAMA configuration, label 335 is not used <strong>for</strong> the track angle rate but <strong>for</strong> another parameter. For this<br />
particular ARINC configuration the track angle rate field should be loaded with all zeroes. In such cases, ground<br />
applications can compute the equivalent of the track angle rate thanks to the true air speed <strong>and</strong> the roll angle in<strong>for</strong>mation.<br />
Draft<br />
CD.2.4.6 TRANSPONDER REGISTER 6016<br />
When ARINC 429 data is used an example, implementation is the following:<br />
BDS Data<br />
bit no. bit no. Description<br />
1 STATUS 1 = valid data<br />
2 SIGN 1 = West (eg.315 degrees= -45 degrees)<br />
3<br />
4<br />
5<br />
MSB = 90 degrees<br />
6 Magnetic heading<br />
7<br />
8<br />
ARINC label 320<br />
9<br />
10<br />
11<br />
Range = [-180, +180]<br />
12 LSB = 90/512 degrees<br />
13 STATUS 1 = valid data<br />
14<br />
15<br />
MSB = 512 kt<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CD-20 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
BDS<br />
bit no.<br />
Data<br />
bit no. Description<br />
16<br />
17 Indicated airspeed<br />
18 ARINC label 206<br />
19<br />
20 Range = [0, 1 023]<br />
21<br />
22<br />
23 LSB = 512/512 = 1 kt<br />
24 STATUS 1 = valid data<br />
25 MSB = 2.048<br />
26<br />
27 Mach<br />
28 ARINC label 205<br />
29<br />
30 Range = [0, 4.092]<br />
31<br />
32<br />
33<br />
34 LSB = 2.048/512<br />
35 STATUS 1 = valid data<br />
36 SIGN 1 = below<br />
37 MSB = 8 192 ft/min<br />
38<br />
39 Barometric altitude rate<br />
40 ARINC label 212<br />
41<br />
42 Range = [-16 384, +16 352]<br />
43<br />
44<br />
45 LSB = 8 192/256 = 32 ft/min<br />
46 STATUS 1 = valid data<br />
47 SIGN 1 = below<br />
48 MSB = 8 192 ft/min<br />
49<br />
50 Inertial vertical velocity<br />
51 ARINC label 365<br />
52<br />
53 Range = [-16 384, +16 352]<br />
54<br />
55<br />
56 LSB = 8 192/256 = 32 ft/min<br />
Draft<br />
The status bits are determined as explained in §A.2.2.2. The data is rounded as specified in §A.2.2.2. The encoding<br />
accuracy of the data in the subfield is ±½ LSB by rounding.<br />
“Barometric Altitude Rate” contains values that are solely derived from barometric measurement. The Barometric<br />
Altitude Rate may be very unsteady <strong>and</strong> may suffer from barometric instrument inertia.<br />
The “Inertial Vertical Velocity” also provides in<strong>for</strong>mation on vertical attitude of the aircraft but it comes from equipment<br />
(IRS, AHRS) which use different sources used <strong>for</strong> navigation. The in<strong>for</strong>mation is a more filtered <strong>and</strong> smoothed<br />
parameter.<br />
CD.2.4.7.1 INTRODUCTION TO CPR<br />
CD.2.4.7 COMPACT POSITION REPORTING (CPR) TECHNIQUE<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix CD CD-21<br />
CPR is a data compression technique used to reduce the number of bits needed <strong>for</strong> lat/lon reporting in the airborne <strong>and</strong><br />
surface position squitters. Data compression is based upon truncation of the high order bits of latitude <strong>and</strong> longitude.<br />
Airborne lat/lon reports are unambiguous over 666 km (360 NM). Surface reports are unambiguous over 166.5 km (90<br />
NM). In order to maintain this ambiguity distance (<strong>and</strong> the values of the LSB), longitude must be re-scaled as latitude<br />
increases away from the equator to account <strong>for</strong> the compression of longitude.<br />
CD.2.4.7.2 LAT/LON ENCODING CONSIDERATIONS<br />
CD.2.4.7.2.1 Unambiguous range<br />
The unambiguous ranges were selected to meet most of the needs of surveillance applications to be supported by<br />
ADS-B. To accommodate applications with longer range requirements, a global encoding technique has been included<br />
that uses a different encoding framework <strong>for</strong> alternate position encoding (labeled even <strong>and</strong> odd). A comparison of a pair<br />
of even <strong>and</strong> odd encoded position reports will permit globally unambiguous position reporting. When global decoding is<br />
used, it need only be per<strong>for</strong>med once at acquisition since subsequent position reports can be associated with the correct<br />
666 (or 166.5) km (360 (or 90) NM) patch. Re-establishment of global decoding would only be required if a track were<br />
lost <strong>for</strong> a long enough time to travel 666 km (360 NM) while airborne or 166.5 km (90 NM) while on the surface. Loss of<br />
track input <strong>for</strong> this length of time would lead to a track drop, <strong>and</strong> global decoding would be per<strong>for</strong>med when the aircraft<br />
was required as a new track.<br />
CD.2.4.7.2.2 Reported position resolution<br />
Reported resolution is determined by:<br />
a) the needs of the user of this position in<strong>for</strong>mation; <strong>and</strong><br />
b) the accuracy of the available navigation data.<br />
For airborne aircraft, this leads to a resolution requirement of about 5 m. Surface surveillance must be able to support<br />
the monitoring of aircraft movement on the airport surface. This requires position reporting with a resolution that is small<br />
with respect to the size of an aircraft. A resolution of about 1 m is adequate <strong>for</strong> this purpose.<br />
CD.2.4.7.3 SEAMLESS GLOBAL ENCODING<br />
While the encoding of lat/lon does not have to be globally unambiguous, it must provide consistent per<strong>for</strong>mance<br />
anywhere in the world including the polar regions. In addition, any encoding technique must not have discontinuities at<br />
the boundaries of the unambiguous range cells.<br />
CD.2.4.7.4 CPR ENCODING TECHNIQUES<br />
CD.2.4.7.4.1 Truncation<br />
Draft<br />
The principal technique <strong>for</strong> obtaining lat/lon coding efficiency is to truncate the high order bits, since these are only<br />
required <strong>for</strong> globally unambiguous coding. The approach is to define a minimum size area cell within which the position<br />
is unambiguous. The considerations in §D.2.4.7.2.1 <strong>and</strong> §D.2.4.7.3 have led to the adoption of a minimum cell size as a<br />
(nominal) square with a side of 666 km (360 NM) <strong>for</strong> airborne aircraft <strong>and</strong> 166.5 km (90 NM) <strong>for</strong> surface aircraft. This cell<br />
size provides an unambiguous range of 333 km (180 NM) <strong>and</strong> 83 km (45 NM) <strong>for</strong> airborne <strong>and</strong> surface aircraft,<br />
respectively.<br />
Depending on receiver sensitivity, surveillance of aircraft at very long ranges may require the use of sector beam<br />
antennas in order to provide sufficient link reliability <strong>for</strong> st<strong>and</strong>ard transponder transmit power. The area covered by a<br />
sector beam provides additional in<strong>for</strong>mation to resolve ambiguities beyond the 333 km (180 NM) range provided by the<br />
coding. In theory, use of a sector beam to resolve ambiguity could provide <strong>for</strong> an operating range of 666 km (360 NM). In<br />
practice, this range will be reduced to about 600 km (325 NM) to provide protection against squitter receptions through<br />
the sidelobes of the sector beams.<br />
In any case, this is well in excess of the maximum operating range available with this surveillance technique. It is also<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CD-22 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
well in excess of any operationally useful coverage since an aircraft at 600 km (325 NM) will only be visible to a surface<br />
receiver if the aircraft is at an altitude greater than 21 000 m (70 000 ft).<br />
The elements of this coding technique are illustrated in Figure CD-4. For ease of explanation, the figure shows four<br />
contiguous area cells on a flat earth. The basic encoding provides unambiguous position within the dotted box centered<br />
on the receiver, i.e. a minimum of 333 km (180 NM). Beyond this range, ambiguous position reporting can result. For<br />
example, an aircraft shown at A would have an ambiguous image at B. However, in this case the in<strong>for</strong>mation provided<br />
by the sector antenna eliminates the ambiguity. This technique will work out to a range shown as the aircraft labeled C.<br />
At this range, the image of C (shown as D) is at a range where it could be received through the sidelobes of the sector<br />
antenna.<br />
360 NM<br />
360 NM<br />
360 NM<br />
x x<br />
B D<br />
360 NM<br />
Draft<br />
Figure CD-4. Maximum range considerations <strong>for</strong> CPR encoding<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
x<br />
A<br />
C x
Appendix CD CD-23<br />
CD.2.4.7.5 BINARY ENCODING<br />
Note.— For the rest of this appendix, 360 NM is not converted.<br />
Once an area cell has been defined, nominally 360 by 360 NM, the encoding within the cell is expressed as a binary<br />
fraction of the aircraft position within the cell. This means that the aircraft latitude <strong>and</strong> longitude are all zeroes at a point<br />
when the aircraft is at the origin of the cell (the south west corner <strong>for</strong> the proposed encoding) <strong>and</strong> all ones at point one<br />
resolution step away from the diagonally opposite corner.<br />
This provides the seamless transition between cells. This technique <strong>for</strong> seamless encoding is illustrated in Figure CD-5<br />
<strong>for</strong> the area cells defined above. For simplicity, only two-bit encoding is shown.<br />
CD.2.4.7.6 ENCODING<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
The above techniques would be sufficient <strong>for</strong> an encoding system if the Earth were a cube. However, to be consistent on<br />
a sphere, additional features must be applied to h<strong>and</strong>le the change in longitude extent as latitudes increase away from<br />
the equator. The polar regions must also be covered by the coding.<br />
All lines of longitude must have the same nominal radius, so the latitude extent of an area cell is constant. The use of a<br />
360 NM minimum unambiguous range leads to 15 latitude zones from the equator to the poles.<br />
00<br />
11<br />
10<br />
01<br />
00<br />
11<br />
10<br />
01<br />
00<br />
00<br />
360 NM 360 NM<br />
Draft<br />
01 10 11 00 01 10 11 00<br />
Figure CD-5. CPR seamless encoding<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
360 NM<br />
360 NM
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CD-24 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Circles of latitude become smaller with increasing latitude away from the equator. This means that the maintenance of<br />
360 NM between ambiguous positions requires that the number of longitude cells at a particular latitude decrease at<br />
latitudes away from the equator. In order to maintain minimum unambiguous range <strong>and</strong> resolution size, the vertical<br />
extent of a longitude cell is divided into latitude b<strong>and</strong>s, each with an integral number of zones.<br />
Longitude zone assignment versus latitude is illustrated in Figure CD-6 <strong>for</strong> a simple case showing five of the latitude<br />
b<strong>and</strong>s in the northern hemisphere. At the equator, 59 zones are used as required to obtain a minimum longitude<br />
dimension of 360 NM at the northern extent of the zone. In fact, it is that precise latitude at which the northern extent of<br />
the zone is 360 NM that defines the value of latitude A in the northern hemisphere (it would be the southern extent of the<br />
zone <strong>for</strong> the southern hemisphere). At latitude A, one less longitude zone is used. This number of zones is used until the<br />
northern (southern) extent of the longitude zone equals 360 NM, which defines latitude B. The process continues <strong>for</strong><br />
each of the five b<strong>and</strong>s.<br />
For lines of longitude, 60 zones are used in the CPR system to give the desired cell size of 360 NM. For circles of<br />
latitude, only 59 zones can be used at the equator in order to assure that the zone size at the northern latitude limit is at<br />
least 360 NM. This process continues through each of 59 latitude b<strong>and</strong>s, each defined by one less zone per latitude<br />
b<strong>and</strong> than the previous. Finally, the polar latitude b<strong>and</strong>s are defined as a single zone beyond 87 degrees north <strong>and</strong><br />
south latitude. A complete definition of the latitude zone structure is given in Table CD-4.<br />
Greenwich<br />
meridian<br />
360 NM<br />
Latitude E<br />
(54 zones)<br />
360 NM<br />
Latitude D<br />
(55 zones)<br />
360 NM<br />
Latitude C<br />
(56 zones)<br />
Draft<br />
360 NM<br />
Latitude B<br />
(57 zones)<br />
360 NM<br />
Latitude A<br />
(58 zones)<br />
360 NM<br />
Equator<br />
(59 zones)<br />
Figure CD-6 Longitude zone size assignment versus latitude.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix CD CD-25<br />
CD.2.4.7.7 GLOBALLY UNAMBIGUOUS POSITION<br />
Globally unambiguous position decoding is typically used to initially establish the position of a target. Once the target’s<br />
position is determined it can be updated using local decoding. Local decoding may be used exclusively only when there<br />
is no possibility of message reception from targets farther than the ambiguous range of 180 NM. In applications where<br />
ADS-B messages are received more than 180 NM from the receiving station, it will be necessary to use globally<br />
unambiguous decoding.<br />
The CPR system includes a technique <strong>for</strong> globally unambiguous coding. It is based on a technique similar to the use of<br />
different pulse repetition intervals (PRI) in radars to eliminate second-time-around targets. In CPR, this takes the <strong>for</strong>m of<br />
coding the lat/lon using a different number of zones on alternate reports. Reports labeled T = 0 are coded using 15<br />
latitude zones <strong>and</strong> a number of longitude zones defined by the CPR coding logic <strong>for</strong> the position to be encoded (59 at<br />
the equator). The reports on the alternate second (T = 1) are encoded using 14 zones <strong>for</strong> latitude <strong>and</strong> N – 1 zones <strong>for</strong><br />
longitude, where N is the number used <strong>for</strong> T = 0 encoding. An example of this coding structure is illustrated in Figure<br />
CD-7.<br />
A user receiving reports of each type can directly decode the position within the unambiguous area cell <strong>for</strong> each report,<br />
since each type of report is uniquely identified. In addition, a comparison of the two types of reports will provide the<br />
identity of the area cell, since there is only one area cell that would provide consistent position decoding <strong>for</strong> the two<br />
reports. An example of the relative decoded positions <strong>for</strong> T = 0 <strong>and</strong> T = 1 is shown in Figure CD-8.<br />
Equator<br />
Greenwich<br />
meridian<br />
Draft<br />
T = 0 zone<br />
T = 1 zone<br />
Figure CD-7. Zone structure <strong>for</strong> globally unambiguous reporting.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
CD-26 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Figure CD-8. Determination of globally unambiguous position from a T = 0 <strong>and</strong> T = 1 report.<br />
CD.2.4.7.8 SUMMARY OF CPR ENCODING CHARACTERISTICS<br />
The CPR encoding characteristics are summarized as follows:<br />
Lat/lon encoding 17 bits <strong>for</strong> each<br />
Nominal airborne resolution 5.1 metres<br />
Nominal surface resolution 1.2 metres<br />
Maximum unambiguous encoded range, airborne 333 km (180 NM)<br />
Maximum unambiguous encoded range, surface 83 km (45 NM)<br />
Draft<br />
Provision <strong>for</strong> globally unique coding using two reports from a T = 0 <strong>and</strong> T = 1 report.<br />
Zone<br />
no.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Equator<br />
Transition latitude<br />
(degrees)<br />
Greenwich<br />
meridian<br />
Zone<br />
no.<br />
T = 0 (Even) zone boundary<br />
T = 1 (Odd) zone boundary<br />
Table CD-4. Transition latitudes<br />
Transition latitude<br />
(degrees)<br />
Actual target position<br />
T = 0 (Even) zone <strong>and</strong> T = 1 (Odd) zone<br />
locations coincide<br />
Zone<br />
no.<br />
T = 0 (Even) zone location<br />
T = 1 (Odd) zone location<br />
Transition latitude<br />
(degrees)<br />
Zone<br />
no.<br />
Transition latitude<br />
(degrees)<br />
59 10.4704713 44 42.8091401 29 61.0491777 14 76.3968439<br />
58 14.8281744 43 44.1945495 28 62.1321666 13 77.3678946<br />
57 18.1862636 42 45.5462672 27 63.2042748 12 78.3337408<br />
56 21.0293949 41 46.8673325 26 64.2661652 11 79.2942823<br />
55 23.5450449 40 48.1603913 25 65.3184531 10 80.2492321<br />
54 25.8292471 39 49.4277644 24 66.3617101 9 81.1980135<br />
53 27.9389871 38 50.6715017 23 67.3964677 8 82.1395698<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix CD CD-27<br />
Zone<br />
no.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Transition latitude<br />
(degrees)<br />
Zone<br />
no.<br />
Transition latitude<br />
(degrees)<br />
Zone<br />
no.<br />
Transition latitude<br />
(degrees)<br />
Zone<br />
no.<br />
Transition latitude<br />
(degrees)<br />
52 29.9113569 37 51.8934247 22 68.4232202 7 83.0719944<br />
51 31.7720971 36 53.0951615 21 69.4424263 6 83.9917356<br />
50 33.5399344 35 54.2781747 20 70.4545107 5 84.8916619<br />
49 35.2289960 34 55.4437844 19 71.4598647 4 85.7554162<br />
48 36.8502511 33 56.5931876 18 72.4588454 3 86.5353700<br />
47 38.4124189 32 57.7274735 17 73.4517744 2 87.0000000<br />
46 39.9225668 31 58.8476378 16 74.4389342<br />
45 41.3865183 30 59.9545928 15 75.4205626<br />
CD.3. IMPLEMENTATION GUIDELINES FOR APPLICATIONS<br />
CD.3.1 DATAFLASH<br />
CD.3.1.1 OVERVIEW<br />
Dataflash is a service which announces the availability of in<strong>for</strong>mation from air-to-ground on an event-triggered basis.<br />
This is an efficient means of downlinking in<strong>for</strong>mation which changes occasionally <strong>and</strong> unpredictably.<br />
A contract is sent to the airborne application through the <strong>Mode</strong> S transponder <strong>and</strong> the ADLP using an uplink <strong>Mode</strong> S<br />
specific protocol (MSP) (MSP 6, SR = 1) as specified in Annex 10 Volume III, Appendix to Chapter 5. This uplink MSP<br />
packet contains in<strong>for</strong>mation specifying the events which should be monitored regarding the changes of data in a<br />
transponder register. When the event occurs, this is announced to the ground installation using the AICB protocol.<br />
The ground installation may then request the downlink in<strong>for</strong>mation which takes the <strong>for</strong>m of a downlink MSP packet on<br />
channel 3 constituted of one or two linked Comm-B segments. The second segment is a direct copy of the relevant<br />
transponder register specified in the contract.<br />
The ground system with the embedded dataflash application should determine if an aircraft supports the dataflash<br />
protocol as follows:<br />
Draft<br />
• if bit 25 of transponder register 1016 is set to 1, the system will extract transponder register 1D16, then,<br />
• if bit 6 <strong>and</strong> bit 31 of transponder register 1D16 are set to 1, then the aircraft supports the dataflash service.<br />
CD.3.1.2 MINIMUM NUMBER OF CONTRACTS<br />
The minimum number of contracts activated simultaneously that can be supported by the airborne installation should be<br />
at least 64. In the case of a software upgrade of existing installations, at least 16 dataflash contracts should be<br />
supported.<br />
CD.3.1.3 CONTRACT REQUEST FOR A TRANSPONDER REGISTER NOT SERVICED BY THE AIRBORNE INSTALLATION<br />
On the receipt of a dataflash service request, a downlink dataflash message should immediately be announced to the<br />
ground regardless of any event criteria. This message is used by the ground system to confirm that the service has been<br />
initiated. The message will only consist of one segment. In the case of a service request <strong>for</strong> an unavailable transponder<br />
register, the message sent to the ground should only contain bits 1 to 40 of the downlink message structure with a CI<br />
field value of 2. This value will indicate to the ground system that the service request cannot be honored because of the<br />
unavailability of the transponder register. The service will then be terminated by the airborne dataflash function, <strong>and</strong> the<br />
ground system should notify the user which has initiated the request that the service request cannot be honored by the<br />
airborne installation.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CD-28 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
When a transponder register (which was previously supported) becomes unavailable <strong>and</strong> is currently monitored by a<br />
dataflash contract, a downlink dataflash message containing bits 1 to 40 will be sent with a CI field value of 7. This will<br />
indicate to the ground that the transponder register is not serviced anymore. The related contract is terminated by the<br />
airborne application, <strong>and</strong> the ground system should notify the user which has initiated the request that the service<br />
request has been terminated by the airborne installation. An alternative means <strong>for</strong> the ground system to detect that the<br />
transponder register is not serviced any longer is to analyze the resulting transponder register 1016 which will be<br />
broadcast by the transponder to indicate to the ground system that transponder register 1716 has changed. The <strong>Mode</strong> S<br />
sensor should then extract transponder register 1716 <strong>and</strong> send it to the ground application. The ground application<br />
should then analyze the content of this transponder register <strong>and</strong> should notice that the transponder register monitored by<br />
a dataflash contract is no longer supported by the airborne installation.<br />
CD.3.1.4 SERVICE CONTINUITY IN OVERLAPPING COVERAGE WITH RADARS USING THE SAME II CODE<br />
Depending on the system configuration the following guidance should be taken into account to ensure service continuity<br />
in overlapping coverage of radars working with the same II code.<br />
CD.3.1.4.1 RADAR WITH THE DATAFLASH APPLICATION EMBEDDED IN THE RADAR SOFTWARE<br />
For this configuration it is necessary to manage the contract numbers which will be used by each station <strong>and</strong> to ensure<br />
that the same contract number <strong>for</strong> the same transponder register is not used by another sensor having overlapping<br />
coverage <strong>and</strong> working with the same II code. The reason <strong>for</strong> this is that a sensor has no means of detecting if a contract<br />
it has initialized has been overwritten by another sensor using an identical dataflash header. Also one sensor could<br />
terminate a contract because an aircraft is leaving its coverage <strong>and</strong> no other sensor would know that this contract had<br />
been closed. For this reason, no dataflash contract termination should be attempted by either sensor in order to ensure<br />
a service continuity.<br />
When two ground stations with overlapping coverage <strong>and</strong> having the same II code each set up dataflash contracts with<br />
the same transponder register <strong>for</strong> the same aircraft, it is essential to ensure that the contract number is checked by each<br />
ground station prior to the closeout of any AICB which is announcing a dataflash message.<br />
CD.3.1.4.2 USE OF AN ATC CENTRE-BASED DATAFLASH APPLICATION<br />
The ATC system hosting the dataflash application should manage the distribution of contract numbers <strong>for</strong> sensors<br />
operating with the same II code. This ATC system will also have the global view of the aircraft path within the ATC<br />
coverage to either initiate or close dataflash contracts when appropriate. This is the preferred configuration since a<br />
central management of the contract numbers is possible which also allows a clean termination of the contracts.<br />
Draft<br />
C.3.1.5 GROUND MANAGEMENT OF MULTIPLE CONTRACTS FOR THE SAME TRANSPONDER REGISTER<br />
The ground system managing the dataflash application must ensure that when it receives a request from ground<br />
applications <strong>for</strong> several contracts to monitor different parameters, or different threshold criteria, related to the same<br />
transponder register <strong>for</strong> a particular aircraft/II code pair, it assigns a unique contract number <strong>for</strong> each contract sent to the<br />
aircraft.<br />
CD.3.1.6 SERVICE TERMINATION<br />
There are three ways to terminate a dataflash service (one from the ground initiative, two from the airborne installation):<br />
1. The ground can send an MSP with the ECS field set to 0 which means that the service is to be discontinued by<br />
the airborne installation.<br />
2. The airborne installation will terminate the service with no indication to the ground system if any message is not<br />
extracted from the transponder by a ground interrogator within 30 seconds following the event specified in the dataflash<br />
contract (TZ timer).<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix CD CD-29<br />
3. When the transponder has not been selectively interrogated by a <strong>Mode</strong> S interrogator with a particular II code<br />
<strong>for</strong> 60 seconds (this is determined by monitoring the IIS subfield in all accepted <strong>Mode</strong> S interrogations), all dataflash<br />
contracts related to that II code will be cancelled with no indication to the ground system.<br />
The termination from the ground initiative is the preferable way to terminate the service since both the ground <strong>and</strong> the<br />
airborne systems terminate the service thanks to a mutually understood data link exchange. This termination should<br />
nevertheless not be allowed in certain configurations especially with adjacent sensors (with the dataflash application<br />
embedded in the sensor software) working with the same II code as explained in §CD.2.1. If the termination of the<br />
contract by a ground system is to be exercised, it should also be noticed that the ground system should anticipate the<br />
exit of the aircraft from its coverage to send the close-out message.<br />
CD.3.1.7 DATAFLASH REQUEST CONTAINING MULTIPLE CONTRACTS<br />
It is possible to merge several contracts into one single dataflash request. If multiple events occur which are related to<br />
several contracts of the initial dataflash request, one downlink message <strong>for</strong> each individual event should be triggered<br />
containing the associated transponder register. Each of these downlink messages should use the air initiated protocol.<br />
CD.3.1.8 TRANSPONDER REGISTER DATA CONTAINED IN THE DOWNLINK MESSAGE<br />
The transponder register data received by the ground system following the extraction of a downlink dataflash message<br />
consisting of two segments are the transponder register data at the time of the event. The transponder register data may<br />
be up to 1 aerial scan old since the event may occur just after the illumination of the aircraft. Should the end-user need<br />
more up-to-date data, the user should use the event announcement to trigger extraction via GICB protocol to get the<br />
latest transponder register data.<br />
CD.3.2 TRAFFIC INFORMATION SERVICE (TIS)<br />
TBD<br />
CD.3.3 EXTENDED SQUITTER<br />
TBD<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table C-1-1. MODE S TRANSPONDER REGISTER DATA REQUIREMENTS AND INPUT AVAILABILITY<br />
EDITOR’S NOTE: In Doc 9871 Edition 1, there were six (6) separate Table numbers <strong>for</strong> the continuance of the same Table (Table C-1-1, C-1-2, C-1-3, C-1-4, C-1-5,<br />
<strong>and</strong> C-1-6) <strong>and</strong> numerous pages of associated Notes. With the revisions of Edition 2, all six tables <strong>and</strong> all associated Notes will be deleted.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CD-30 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong>
Appendix CD CD-31<br />
CD.4 IMPLEMENTATION GUIDELINES FOR EXTENDED SQUITTER GROUND SYSTEMS<br />
CD.4.1 INTRODUCTION<br />
The provisions presented within the following subsections are focused on requirements applicable to specific classes of<br />
airborne <strong>and</strong> ground transmitting systems that support the applications of ADS-B, TIS-B <strong>and</strong> ADS-R. Airborne systems<br />
transmit ADS-B messages. Ground stations may transmit extended squitter messages containing TIS-B <strong>and</strong>/or the<br />
rebroadcast of ADS-B in<strong>for</strong>mation (referred to as ADS-Rebroadcast or ADS-R). TIS-B uses surveillance data received<br />
by a non-ADS-B source (e.g. SSR). ADS-R uses ADS-B in<strong>for</strong>mation received via other than an extended squitter ADS-B<br />
link, to generate <strong>and</strong> transmit messages, via the extended squitter link, that convey essentially the same in<strong>for</strong>mation as<br />
included in ADS-B messages.<br />
C4D.4.2 SIGNAL-IN-SPACE CHARACTERISTICS<br />
Ground stations supporting TIS-B <strong>and</strong>/or ADS-R transmit on 1 090 MHz with the same signal-in-space characteristics as<br />
defined in Annex 10, Volume IV, Chapter 3 <strong>for</strong> replies from <strong>Mode</strong> S transponders, with the exception that only the long<br />
<strong>for</strong>mat containing 112 in<strong>for</strong>mation bits are used.<br />
CD.4.3 DATA STRUCTURES<br />
Ground stations supporting TIS-B <strong>and</strong>/or ADS-R transmit using the same data structure as defined in Annex 10,<br />
Volume IV, Chapter 3 <strong>for</strong> <strong>Mode</strong> S replies containing 112 in<strong>for</strong>mation bits transmitted by <strong>Mode</strong> S transponders. This<br />
includes the requirements defined under 3.1.2.3.1 <strong>for</strong> data encoding, under 3.1.2.3.2 <strong>and</strong> 3.1.2.8.7 <strong>for</strong> the <strong>for</strong>mat of<br />
<strong>Mode</strong> S replies with DF=18, <strong>and</strong> the requirements defined under 3.1.2.3.3 <strong>for</strong> error protection of <strong>Mode</strong> S replies.<br />
CD.4.4 GROUND STATION TRANSMISSION CHARACTERISTICS<br />
Ground stations supporting TIS-B <strong>and</strong>/or ADS-R use an extended squitter transmission capability. The characteristics of<br />
such ground stations, in terms of transmitter power, antenna gain, transmission rates, etc., are tailored to provide the<br />
required per<strong>for</strong>mance of the service over the desired TIS-B/ADS-R service volume of the specific ground station,<br />
assuming that airborne users are equipped with (at least) Class A1 receiving systems as defined in Annex 10, Volume<br />
IV, Chapter 5.<br />
Specifically:<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Draft<br />
a. The minimum trigger threshold level (MTL) of a class A1 airborne receiver is specified as –79 dBm (as listed in<br />
Annex 10, Volume IV, Chapter 5). When moderate to high levels of interference are expected to exist within the<br />
defined TIS-B/ADS-R service volume, increased ground station Effective Isotropic Radiated Power (EIRP) levels<br />
<strong>and</strong>/or increased transmission rates may be necessary to overcome the degraded reception per<strong>for</strong>mance (i.e. by<br />
the airborne receiver) caused by the interfering signals. The following example shows the maximum ground-to-air<br />
line-of-sight range that can reliably be supported versus the ground station’s EIRP <strong>for</strong> the case of a class A1<br />
equipped airborne receiver operating in an environment with a very low level of interference on the 1 090 MHz<br />
channel. This represents the minimum EIRP that should be considered <strong>and</strong> provision of a higher EIRP may be<br />
necessary in order to provide RF link margin to accommodate less than ideal per<strong>for</strong>mance from the airborne or<br />
ground installation. The combination of the ground station’s transmitter power, cable losses <strong>and</strong> antenna<br />
gain/pattern are selected such that the EIRP from the ground station is sufficient to ensure that when a class A1<br />
equipped aircraft is located at the extreme edge of the TIS-B/ADS-R service volume (e.g. at the maximum range<br />
from the ground station), the received signal strength will be at –79 dBm or greater.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CD-32 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Nominal Reception<br />
Range<br />
Minimum required<br />
ground station EIRP<br />
15 NM 11 dBW<br />
30 NM 17 dBW<br />
60 NM 23 dBW<br />
120 NM 29 dBW<br />
b. It is necessary to limit the average (i.e. longer-term) transmit duty cycle so as not to cause any significant<br />
interference to other local users of the 1 090 MHz RF spectrum (i.e. ground SSR interrogators or to nearby ACAS<br />
equipped aircraft). The maximum suitable transmit duty cycle, both peak short-term as well as average, needs to be<br />
determined based on the local 1 090 MHz RF environment. To accomplish this, the ground station needs to have<br />
the ability to limit both the peak short-term <strong>and</strong> average transmit duty cycles to the maximums authorized <strong>for</strong> that<br />
site. The peak duty cycle should not exceed one extended squitter transmission within a 1 millisecond interval. The<br />
average duty cycle should not exceed 500 extended squitter transmissions per second. However, this may be<br />
further limited to comply with local RF spectrum authorization.<br />
c. The ground station antenna’s radiation pattern in the horizontal plane needs to be consistent with the TIS-B/ADS-R<br />
service volume to be supported by that ground station. An omnidirectional radiation pattern is expected to be<br />
suitable <strong>for</strong> most cases.<br />
d. The ground station antenna should be vertically polarized.<br />
e. The ground station’s antenna should have a radiation pattern in the vertical plane that provides positive gain at<br />
elevation angles above the horizon with a cut-off of gain (i.e. negative gain) at elevation angles below the horizon.<br />
This is required to minimize the negative effects of signal reflections from the ground. Antennas with multiple active<br />
elements providing vertical aperture are typically used to produce both increased gain at elevation angles above the<br />
horizon <strong>and</strong> a sharp cut-off in gain below the horizon, <strong>and</strong> are suitable <strong>for</strong> both transmission <strong>and</strong> reception of<br />
extended squitter signals. Such antennas provide positive gain at elevation angles above the horizon <strong>and</strong> peak<br />
gains within the range from +6 dB to +9 dB are typical at elevation angles of 10 to 15 degrees above the horizon.<br />
The implementation should take into account that such antennas usually have a null in the gain in the vertical<br />
dimension which causes a cone of silence.<br />
f. Ground stations supporting an ADS-R capability need to incorporate the ADS-R message generation function <strong>and</strong><br />
the ADS-R message exchange function.<br />
Draft<br />
CD.4.5 MESSAGE EXCHANGE FUNCTION<br />
The message exchange function includes the 1 090 MHz receiving antenna <strong>and</strong> the radio equipment<br />
(receiver/demodulator/decoder/data buffer) sub-functions.<br />
CD.4.5.1 MESSAGE EXCHANGE FUNCTIONAL CHARACTERISTICS<br />
The airborne <strong>Mode</strong> S extended squitter receiving system supports the reception <strong>and</strong> decoding of all extended squitter<br />
messages as listed in Annex 10, Volume IV, Chapter 5. The ground ADS-B extended squitter receiving system, as a<br />
minimum, supports the reception <strong>and</strong> decoding of all extended squitter message types that convey in<strong>for</strong>mation needed<br />
to support the generation of the ADS-B reports of the types required by the client ATM ground applications.<br />
CD.4.5.2 MESSAGE RECEPTION PERFORMANCE<br />
CD.4.5.2.1 The airborne <strong>Mode</strong> S extended squitter receiver/demodulation/decoder employs the reception techniques<br />
<strong>and</strong> has a receiver minimum trigger threshold level (MTL) as listed in Annex 10, Volume IV, Chapter 5 as a function of<br />
the airborne receiver class.<br />
CD.4.5.2.2 The ground station’s antenna characteristics in combination with the extended squitter receiver’s reception<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix CD CD-33<br />
technique <strong>and</strong> MTL are selected to provide the reception per<strong>for</strong>mance (i.e. range <strong>and</strong> update rates) as required by the<br />
client ATM ground applications throughout the defined ADS-B surveillance volume. The type of messages that must be<br />
received <strong>and</strong> the type of reports that must be generated will depend on the requirements of the client ground ATM<br />
applications. The per<strong>for</strong>mance required of ADS-B ground station receivers supporting ATM surveillance applications will<br />
depend on the individual ground station’s required service volume, the associated required reporting rates, <strong>and</strong> on the<br />
interference levels on the 1 090 MHz channel at that location. It is appropriate to derive the characteristics of the ground<br />
station’s extended squitter receiver, in terms of MTL <strong>and</strong> reception techniques, based on what has been defined <strong>for</strong> the<br />
airborne extended squitter receivers in Annex 10, Volume IV, Chapter 5. However, when a higher gain ground station<br />
antenna is used (i.e. than that of a typical airborne antenna), the resulting air-to-ground reception range can be expected<br />
to be greater than <strong>for</strong> the air-to-air case. The characteristics of the ground station’s antenna along with the associated<br />
receiver’s characteristics need to be consistent with the intended service volume.<br />
CD.4.5.2.3 ADS-B ground stations intended <strong>for</strong> use in locations anticipated to have moderate to high levels of<br />
1 090 MHz co-channel interference need to have an MTL <strong>and</strong> use reception techniques at least equivalent to those<br />
listed in Annex 10, Volume IV, Chapter 5 <strong>for</strong> a Class A3 airborne receiver.<br />
CD.4.5.2.4 The ground station antenna used <strong>for</strong> reception should have the same characteristics as specified <strong>for</strong><br />
transmission in CD.4.4.<br />
_____________________<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
CD-34 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
This page was intentionally left blank.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix DE<br />
SERVICES UNDER DEVELOPMENT<br />
DE.1 INTRODUCTION<br />
Appendix D E presents the latest status of <strong>Mode</strong> S <strong>and</strong> extended squitter services that are under development. When<br />
these services are mature, they will be proposed as a revision to the technical provisions in Appendix A or BC, <strong>and</strong>/or<br />
the relevant SARPs.<br />
D.2 EXTENDED SQUITTER TARGET STATE AND STATUS MESSAGE<br />
Note.— §B.2.3.9 has been reserved <strong>for</strong> this material.<br />
TARGET STATE AND STATUS INFORMATION<br />
The target state <strong>and</strong> status in<strong>for</strong>mation squitter shall be <strong>for</strong>matted as specified in the definition of register number 6216<br />
<strong>and</strong> in the following paragraphs:<br />
D.2.1 TRANSMISSION RATE<br />
This message shall be broadcast at r<strong>and</strong>om intervals uni<strong>for</strong>mly distributed over the range of 1.2 to 1.3 seconds <strong>for</strong> the<br />
duration of the operation.<br />
Draft<br />
D.2.2 MESSAGE DELIVERY<br />
<strong>Extended</strong> <strong>Squitter</strong> Message delivery shall be accomplished using the event-driven protocol (see §A.2.3.7).<br />
D.2.3 VERTICAL DATA AVAILABLE/SOURCE INDICATOR<br />
This 2-bit (ME bits 8 — 9, Message bits 40 — 41) subfield shall be used to identify if aircraft vertical state in<strong>for</strong>mation is<br />
available <strong>and</strong> present as well as the data source <strong>for</strong> the vertical data when present in the subsequent subfields.<br />
Encoding shall be defined as specified in the following table. Any message parameter associated with vertical target<br />
state <strong>for</strong> which an update has not been received from an on-board data source with the past 5 seconds shall be<br />
considered invalid <strong>and</strong> so indicated in the Vertical Data Available/Source Indicator subfield.<br />
DE-1<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
DE-2 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
Coding<br />
(Binary) (Decimal) Meaning<br />
00 0 No valid Vertical Target State data is available<br />
01 1<br />
10 2 Holding altitude<br />
11 3 FMS/RNAV system<br />
Autopilot control panel selected value, such as <strong>Mode</strong> Control Panel<br />
(MCP) or Flight Control Unit (FCU)<br />
D.2.4 TARGET ALTITUDE TYPE<br />
This one bit (ME bit 10, Message bit 42) subfield shall be used to identify whether the altitude reported in the “Target<br />
Altitude” subfield is referenced to mean sea level (MSL) or to a flight level (FL). A value of ZERO (0) shall indicate target<br />
altitude referenced to pressure-altitude (flight level). A value of ONE (1) shall indicate a target altitude referenced to<br />
barometric corrected altitude (mean sea level).<br />
D.2.5 TARGET ALTITUDE CAPABILITY<br />
This 2-bit subfield (ME bits 12 — 13, Message bits 44 — 45) shall be used to describe the aircraft’s capabilities <strong>for</strong><br />
providing the data reported in the target altitude subfield. The target altitude capability subfield shall be encoded as<br />
specified in the following table.<br />
Coding<br />
(Binary) (Decimal)<br />
Meaning<br />
Draft<br />
00 0 Capability <strong>for</strong> reporting holding altitude only<br />
01 1<br />
10 2<br />
11 3 Reserved<br />
Capability <strong>for</strong> reporting either holding altitude or autopilot control panel<br />
selected altitude<br />
Capability <strong>for</strong> reporting either holding altitude, autopilot control panel<br />
selected altitude, or any FMS/RNAV level-off altitude<br />
D.2.6 VERTICAL MODE INDICATOR<br />
This 2-bit (ME bits 14 — 15, Message bits 46 — 47) subfield shall be used to indicate whether the target altitude is in the<br />
process of being acquired (i.e. aircraft is climbing or descending toward the target altitude) or whether the target altitude<br />
has been acquired/being held. The Vertical <strong>Mode</strong> Indicator subfield shall be encoded as specified in the following table.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix DE DE-3<br />
Coding<br />
(Binary) (Decimal)<br />
Meaning<br />
00 0 Unknown mode or in<strong>for</strong>mation unavailable<br />
01 1 “Acquiring” <strong>Mode</strong><br />
10 2 “Capturing” or “Maintaining” <strong>Mode</strong><br />
11 3 Reserved<br />
D.2.7 TARGET ALTITUDE<br />
This 10-bit (ME bits 16 — 25, Message bits 48 — 57) subfield shall be used to provide aircraft’s next intended level-off<br />
altitude if in a climb or descent, or the aircraft current intended altitude if it is intending to hold its current altitude. The<br />
reported target altitude shall be the operational altitude recognized by the aircraft’s guidance system. The target altitude<br />
subfield shall be as specified in the following table.<br />
Coding<br />
(Binary) (Decimal) Meaning<br />
00 0000 0000 0 Target altitude = -1 000 feet<br />
00 0000 0001 1 Target altitude = -900 feet<br />
00 0000 0010 2 Target altitude = -800 feet<br />
*** *** ***<br />
00 0000 1011 11 Target altitude = zero (0) feet<br />
00 0000 1100 12 Target altitude = 100 feet<br />
Draft<br />
*** *** ***<br />
11 1111 0010 1010 Target altitude = 100 000 feet<br />
11 1111 0011 —<br />
11 1111 1111<br />
1011 — 1023 Invalid (out of range)<br />
D.2.8 HORIZONTAL DATA AVAILABLE/SOURCE INDICATOR<br />
This 2-bit (ME bits 26 — 27, message bits 58 — 59) subfield shall be used to identify if aircraft horizontal state<br />
in<strong>for</strong>mation is available <strong>and</strong> present as well as the data source <strong>for</strong> the horizontal target data when present in the<br />
subsequent subfields. The horizontal data available/source Indicator subfield shall be encoded as specified in the<br />
following table. Any message parameter associated with horizontal target state <strong>for</strong> which an update has not been<br />
received from an on-board data source within the past 5 seconds shall be considered invalid <strong>and</strong> so indicated in the<br />
horizontal data available/source indicator subfield.<br />
Coding Meaning<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
DE-4 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
(Binary) (Decimal)<br />
00 0 No valid horizontal target state data is available<br />
01 1<br />
10 2<br />
Autopilot control panel selected value, such as <strong>Mode</strong> Control Panel<br />
(MCP) or Flight Control Unit (FCU)<br />
Maintaining current heading or track angle (e.g. autopilot mode<br />
select)<br />
11 3 FMS/RNAV system (indicates track angle specified by leg type)<br />
D.2.9 TARGET HEADING/TRACK ANGLE<br />
This 9-bit (ME bits 28 — 36, message bits 60 — 68) subfield shall be used to provide aircraft’s intended (i.e. target or<br />
selected) heading or track. The target heading/track angle subfield shall be encoded as specified in the following table.<br />
Coding<br />
(Binary) (Decimal) Meaning<br />
0 0000 0000 0 Target heading/track = Zero degrees<br />
0 0000 0001 1 Target heading/track = 1 degree<br />
0 0000 0010 2 Target heading/track = 2 degrees<br />
*** *** ***<br />
1 0110 0111 359 Target heading/track = 359 degrees<br />
1 0110 1000 through<br />
1 1111 1111<br />
360 through 511<br />
Invalid<br />
Draft<br />
D.2.10 TARGET HEADING/TRACK INDICATOR<br />
This 1-bit (ME bit 37, message bit 69) subfield shall be used to indicate whether a Heading Angle or a track angle is<br />
being reported in the target heading/track angle subfield. A value of ZERO (0) shall indicate the Target Heading Angle is<br />
being reported. A value of ONE (1) shall indicate that Track Angle is being reported.<br />
D.2.11 HORIZONTAL MODE INDICATOR<br />
This 2-bit (ME bits 38 — 39, Message bits 70 — 71) subfield shall be used to indicate whether the target heading/track is<br />
being acquired (i.e. lateral transition toward the target direction is in progress) or whether the target heading/track has<br />
been acquired <strong>and</strong> is currently being maintained. The horizontal mode Indicator subfield shall be encoded as specified in<br />
the following table.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Appendix DE DE-5<br />
Coding<br />
(Binary) (Decimal) Meaning<br />
00 0 Unknown mode or in<strong>for</strong>mation unavailable<br />
01 1 “Acquiring” mode<br />
10 2 “Capturing” or “Maintaining” mode<br />
11 3 Reserved<br />
D.2.12 NAVIGATION ACCURACY CATEGORY FOR POSITION (NACP)<br />
This 4-bit (ME bits 40 — 43, message bits 72 — 75) subfield shall be used to indicate the navigational accuracy<br />
category of the navigation in<strong>for</strong>mation used as the basis <strong>for</strong> the aircraft reported position. The NACP subfield shall be<br />
encoded as specified in the following table. If an update has not been received from an on-board data source <strong>for</strong> NACP<br />
within the past 5 seconds, then the NACP subfield shall be encoded as a value indicating unknown accuracy.<br />
Coding<br />
(Binary) (Decimal)<br />
Meaning = 95% horizontal <strong>and</strong> vertical accuracy bounds<br />
(EPU <strong>and</strong> VEPU)<br />
0000 0 EPU ≥ 18.52 km (10 NM) — Unknown accuracy<br />
0001 1 EPU < 18.52 km (10 NM) — RNP-10 accuracy<br />
0010 2 EPU < 7.408 km (4 NM) — RNP-4 accuracy<br />
0011 3 EPU < 3.704 km (2 NM) — RNP-2 accuracy<br />
0100 4 EPU < 1852 m (1NM) — RNP-1 accuracy<br />
0101 5 EPU < 926 m (0.5 NM) — RNP-0.5 accuracy<br />
0110 6 EPU < 555.6 m ( 0.3 NM) — RNP-0.3 accuracy<br />
Draft<br />
0111 7 EPU < 185.2 m (0.1 NM) — RNP-0.1 accuracy<br />
1000 8 EPU < 92.6 m (0.05 NM) — e.g. GPS (with SA)<br />
1001 9 EPU < 30 m <strong>and</strong> VEPU < 45 m — e.g. GPS (SA off)<br />
1010 10 EPU < 10 m <strong>and</strong> VEPU < 15 m — e.g. WAAS<br />
1011 11 EPU < 3 m <strong>and</strong> VEPU < 4 m — e.g. LAAS<br />
1100 ―<br />
1111<br />
12 ― 15 Reserved<br />
Note 1.— The Estimated Position Uncertainty (EPU) used in the table is a 95 per cent accuracy bound on horizontal<br />
position. EPU is defined as the radius of a circle, centered on the reported position, such that the probability of the actual<br />
position lying outside the circle is 0.05. When reported by a GPS or GNSS system, EPU is commonly called HFOM<br />
(Horizontal Figure of Merit).<br />
Note 2.— Vertical Estimated Position Uncertainty (VEPU) is a 95 per cent accuracy limit on the vertical position<br />
(geometric altitude). VEPU is defined as a vertical position limit, such that the probability of the actual geometric altitude<br />
differing from the reported geometric altitude by more than that limit is 0.05. When reported by a GPS or GNSS system,<br />
VEPU is commonly called VFOM (Vertical Figure of Merit).<br />
Note 3.— RNP accuracy includes error sources other than sensor error, whereas horizontal error <strong>for</strong> NACP only<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
DE-6 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
refers to horizontal position error uncertainty.<br />
Note 4.— If geometric altitude is not being reported, then the VEPU tests are not assessed.<br />
D.2.13 NAVIGATION INTEGRITY CATEGORY FOR BARO (NICBARO)<br />
This 1-bit (ME bit 44, message bit 76) subfield shall be used to indicate whether or not the barometric pressure-altitude<br />
being reported in the airborne position message (see §A.2.3.2) has been crosschecked against another source of<br />
pressure-altitude. The NICBARO subfield shall be encoded as specified in the following table. If an update has not been<br />
received from an on-board data source <strong>for</strong> NICBARO within the past 5 seconds, then the NICBARO subfield shall be<br />
encoded as a value of ZERO (0).<br />
Coding Meaning<br />
0<br />
1<br />
The barometric altitude that is being reported in the Airborne<br />
Position Message is based on a Gilham coded input that has not<br />
been cross-checked against another source of pressure-altitude.<br />
The barometric altitude that is being reported in the Airborne<br />
Position Message is either based on a Gilham code input that has<br />
been cross-checked against another source of pressure-altitude<br />
<strong>and</strong> verified as being consistent, or is based on a non-Gilham<br />
coded source.<br />
Note 1.— The barometric altitude value itself is conveyed within the ADS-B Position Message.<br />
Note 2.— The NICBARO subfield provides a method of indicating a level of data integrity <strong>for</strong> aircraft installed with<br />
Gilham encoding barometric altitude sources. Because of the potential of an undetected error when using a Gilham<br />
encoded altitude source, a comparison shall be per<strong>for</strong>med with a second source <strong>and</strong> only if the two sources agree shall<br />
the NICBARO subfield be set to a value of “1”. For other barometric altitude sources (Synchro or DADS) the integrity of the<br />
data is indicated with a validity flag or SSM. No additional checks or comparisons are necessary. For these sources the<br />
NICBARO subfield shall be set to a value of “1” whenever the barometric altitude is valid.<br />
Draft<br />
Note 3.— The use of Gilham type altimeters is strongly discouraged because of the potential <strong>for</strong> undetected altitude<br />
errors.<br />
D.2.14 SURVEILLANCE INTEGRITY LEVEL (SIL)<br />
This 2-bit (ME bits 45 — 46, message bits 77 — 78) subfield shall be used to define the probability of the integrity<br />
containment region described by the NIC subfield being exceeded <strong>for</strong> the selected position source, including any<br />
external signals used by the source. The SIL subfield shall be encoded as specified in the following table. If an update<br />
has not been received from an on-board data source <strong>for</strong> SIL within the past 5 seconds, then the SIL subfield shall be<br />
encoded as a value indicating “Unknown.”<br />
The probability specified by the SIL subfield shall be the largest likelihood of any one of the following occurring when a<br />
valid geometric position is provided by the selected position source:<br />
a. a position source equipment malfunction (per hour),<br />
b. the per sample probability of a position source error larger than the horizontal or vertical integrity containment region<br />
associated with the NIC value(s), or,<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix DE DE-7<br />
c. <strong>for</strong> GNSS, the probability of the signal-in-space causing a position error larger than the horizontal or vertical<br />
containment region associated with the NIC value(s) without an indication (see Note 1 below the table), within a<br />
time period determined by the positioning source, as indicated in the table.<br />
Coding<br />
(Binary) (Decimal)<br />
Probability of exceeding the Horizontal<br />
Containment Radius (RC) reported in the NIC<br />
Subfield without an indication<br />
Probability of exceeding the Vertical<br />
Integrity Containment Region (VPL)<br />
without an indication<br />
00 0 Unknown Unknown<br />
01 1<br />
10 2<br />
11 3<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
≤1 × 10 –3<br />
per flight hour or per sample<br />
≤1 × 10 –5<br />
per flight hour or per sample<br />
≤1 × 10 –7<br />
per flight hour or per sample<br />
≤1 × 10 –3<br />
per flight hour or per sample<br />
≤1 × 10 –5<br />
per flight hour or per sample<br />
≤2 × 10 –7<br />
per 150 seconds or per sample<br />
Note 1.— “An Indication” may include, <strong>for</strong> example, a flag <strong>for</strong> invalid position report, or a change in NIC, or switching<br />
to another data source.<br />
Note 2.— A problem <strong>for</strong> installations that include currently available GNSS receivers <strong>and</strong> FMS systems is that SIL is<br />
not output by these systems. Most implementers are expected to determine SIL by off-line analysis of the installed<br />
configuration. This off-line analysis can be per<strong>for</strong>med on the various primary <strong>and</strong> alternate means of determining the<br />
reported position. SIL is a static value <strong>for</strong> each of these configurations.<br />
Note 3.— The vertical integrity containment column only applies to NIC values greater than 8.<br />
Note 4.— The SIL code value is the lower of the horizontal or vertical coding values.<br />
Note 5.— It is recognized that there are three possible derivations of SIL: (a) the integrity value provided by<br />
navigation sensors with self-monitoring capability (e.g. GPS), (b) the reliability of aircraft systems given as indicated by a<br />
failure rate commensurate with the equipment design assurance, <strong>and</strong> (c) the integrity of other navigation systems, (e.g.<br />
RNP) that rely on ground-based self-monitoring equipment <strong>for</strong> integrity assurance, <strong>and</strong> <strong>for</strong> which no specific hourly<br />
integrity value can be ascribed. These three values are not readily interchangeable. Selection of the largest of the values<br />
as specified in the table above is felt to provide a reasonable bound on the order of magnitude of the probability of<br />
possible failures affecting ADS-B applications.<br />
Draft<br />
Note 6.— GNSS systems report integrity in terms of flight hours <strong>and</strong> FMS systems report in terms of per<br />
measurement sample (derived from a number of position measurements). While these are not equivalent measures of<br />
integrity, the difference is not considered to be critical <strong>for</strong> initial applications.<br />
D.2.14.1 Recommendations.—<br />
1. SIL is intended to reflect the integrity of the navigation source of the position in<strong>for</strong>mation broadcast, there<strong>for</strong>e the<br />
SIL value transmitted should be indicative of the true integrity of the ADS-B position data.<br />
2. If SIL in<strong>for</strong>mation is not provided by the navigation source, implementers should not arbitrarily set a SIL value of<br />
zero indicating unknown integrity.<br />
3. Unless there is a tightly coupled navigation source where SIL can be unambiguously determined <strong>and</strong> set<br />
dynamically, the ADS-B Transmitting Subsystem should provision <strong>for</strong> the static setting of SIL as part of the<br />
installation procedure.<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
DE-8 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
D.2.15 CAPABILITY/MODE CODES<br />
This 2-bit (ME bits 52 — 53, Message bits 84 — 85) subfield shall be used to indicate the current operational status of<br />
TCAS/ACAS systems/functions. This subfield shall be encoded as specified in the following table. If an update has not<br />
been received from an on-board data source <strong>for</strong> a Capability/<strong>Mode</strong> Code data element within the past 2 seconds, then<br />
that data element shall be encoded with a value of zero (0).<br />
Coding Meaning<br />
ME bit 52 = 0 TCAS/ACAS operational or unknown<br />
ME bit 52 = 1 TCAS/ACAS not operational<br />
ME bit 53 = 0 No TCAS/ACAS Resolution Advisory active<br />
ME bit 53 = 1 TCAS/ACAS Resolution Advisory active<br />
D.2.16 EMERGENCY/PRIORITY STATUS<br />
This 3-bit (ME bits 54 — 56, message bits 86 — 88) subfield shall be used to provide additional in<strong>for</strong>mation regarding<br />
aircraft status. The Emergency/Priority Status subfield shall be encoded as specified in the following table. If an update<br />
has not been received from an on-board data source <strong>for</strong> the Emergency/Priority Status within the past 5 seconds, then<br />
the emergency/priority status subfield shall be encoded with a value indicating no emergency.<br />
Coding<br />
(Binary) (Decimal) Meaning<br />
000 0 No emergency<br />
001 1 General emergency<br />
Draft<br />
010 2 Lifeguard/medical emergency<br />
011 3 Minimum fuel<br />
100 4 No communications<br />
101 5 Unlawful interference<br />
110 6 Downed aircraft<br />
111 7 Reserved<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix DE DE-9<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
Table D-2-98. BDS Code 6,2 — Target state <strong>and</strong> status in<strong>for</strong>mation<br />
1<br />
2<br />
3<br />
4<br />
5<br />
FORMAT TYPE CODE = 29<br />
6 MSB SUBTYPE CODE = 0<br />
7 LSB<br />
8 MSB Vertical Data Available / Source Indicator<br />
9 LSB (see §D.2.3)<br />
10 Target Altitude Type (see §D.2.4)<br />
11 Backward Compatibility Flag = 0<br />
12 MSB Target Altitude Capability<br />
13 LSB (see §D.2.5)<br />
14 MSB Vertical <strong>Mode</strong> Indicator<br />
15 LSB (see §D.2.6)<br />
16<br />
17<br />
18<br />
19<br />
MSB<br />
20 Target Altitude<br />
21<br />
22<br />
23<br />
24<br />
(see §D.2.7)<br />
25 LSB<br />
26 MSB Horizontal Data Available / Source Indicator<br />
27 LSB (see §D.2.8)<br />
28<br />
29<br />
30<br />
31<br />
MSB<br />
32 Target Heading / Track Angle<br />
33<br />
34<br />
35<br />
(see §D.2.9)<br />
36 LSB<br />
37 Target Heading / Track Indicator (see §D.2.10)<br />
38 MSB Horizontal <strong>Mode</strong> Indicator (see §D.2.11)<br />
39 LSB<br />
40 MSB<br />
41 Navigation Accuracy Category — Position (NACP)<br />
42 (see §D.2.12)<br />
43 LSB<br />
44 Navigation Integrity Category — Baro (NICBARO) (see §D.2.13)<br />
45 MSB Surveillance Integrity Level (SIL)<br />
46<br />
47<br />
48<br />
LSB (see §D.2.14)<br />
49<br />
50<br />
51<br />
Reserved<br />
52 MSB Capability / <strong>Mode</strong> Codes<br />
53 LSB (see §D.2.15)<br />
54 MSB<br />
55 Emergency / Priority Status<br />
56 LSB (see §D.2.16)<br />
PURPOSE: To provide aircraft state <strong>and</strong> status in<strong>for</strong>mation.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
DE-10 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
D.3E.2 REVISED FORMATS FOR METEOROLOGICAL REGISTERS 4416 AND 4516<br />
D.3E.2.1 In order to keep registers 4416 <strong>and</strong> 4516 in con<strong>for</strong>mance with the definitions used over other data links, the<br />
<strong>for</strong>mat of register 4416 <strong>and</strong> 4516 will be modified in the future as shown in the following tables.<br />
Note.— When the revised <strong>for</strong>mats are mature, they will be proposed <strong>for</strong> insertion as a revision to Appendix A.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
Appendix DE DE-11<br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1<br />
2 RESERVED<br />
3<br />
4<br />
5 STATUS<br />
6 MSB = 256 knots<br />
7<br />
8<br />
9 WIND SPEED<br />
10<br />
11 Range = [0, 511] knots<br />
12<br />
13<br />
14 LSB = 1 knot<br />
15 STATUS<br />
16 MSB = 180 degrees<br />
17<br />
18 WIND DIRECTION (True)<br />
19<br />
20 Range = [0, 360] degrees<br />
21<br />
22<br />
23 LSB = 180/128 degrees<br />
24 STATUS<br />
25 SIGN<br />
26 MSB = 64°C<br />
27<br />
28<br />
29 STATIC AIR TEMPERATURE<br />
30<br />
31 Range = [-128, +128] ºC<br />
32<br />
33<br />
34<br />
35 LSB = 0.125°C<br />
36 STATUS<br />
37 MSB = 1 024 hPa<br />
38<br />
39<br />
40 AVERAGE STATIC PRESSURE<br />
41<br />
42 Range = [0, 2 047] hPa<br />
43<br />
44<br />
45<br />
46<br />
47 LSB = 1 hPa<br />
48 TURBULENCE FLAG<br />
49 STATUS<br />
50 MSB = 64%<br />
51<br />
52<br />
53 HUMIDITY<br />
54 Range = [0, 127] %<br />
55<br />
56 LSB = 1 %<br />
Table DE-2-68. BDS Code 4,4 — Meteorological routine air report<br />
PURPOSE: To allow meteorological data to be collected by ground systems.<br />
1) The definition of bit 48: Turbulence flag:<br />
0 = signifies turbulence data not available in Register 4516.<br />
1 = signifies turbulence data available in Register 4516.<br />
Note 1.— The average static pressure is not a requirement of Annex 3.<br />
Note 2.— Humidity calculation may result in values greater than 100%.<br />
Note 3.— Two’s complement coding is used <strong>for</strong> all signed fields as<br />
specified in §A.2.2.2.<br />
Note 4.— The requirement <strong>for</strong> the range of wind speeds in Annex 3 is<br />
from 0 to 250 knots.<br />
Note 5.— The requirement <strong>for</strong> the range of static air temperature in<br />
Annex 3 is from –80°C to +60°C.<br />
Draft<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris
DE-12 <strong>Technical</strong> <strong>Provisions</strong> <strong>for</strong> <strong>Mode</strong> S <strong>Services</strong> <strong>and</strong> <strong>Extended</strong> <strong>Squitter</strong><br />
MB FIELD<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris<br />
1 STATUS<br />
2 MSB WIND SHEAR HAZARD<br />
3 LSB<br />
4 STATUS<br />
5 MSB MICROBURST HAZARD<br />
6 LSB<br />
7 STATUS<br />
8 MSB ICING HAZARD<br />
Table DE-2-69. BDS code 4,5 — Meteorological hazard report<br />
PURPOSE: To provide reports on the severity of meteorological hazards<br />
<strong>and</strong> related in<strong>for</strong>mation.<br />
1) Hazard coding:<br />
The interpretation of the two bits assigned to each hazard shall be as<br />
defined in the table below:<br />
9 LSB Bit 1 Bit 2<br />
10 STATUS 0 0 NIL<br />
11 MSB WAKE VORTEX HAZARD 0 1 LIGHT<br />
12 LSB 1 0 MODERATE<br />
13 STATUS 1 1 SEVERE<br />
14 SIGN<br />
15 MSB = 64°C<br />
The definition of the terms LIGHT, MODERATE <strong>and</strong> SEVERE shall be those<br />
16<br />
defined in the PANS-ATM (Doc 4444), where applicable.<br />
17<br />
18<br />
19<br />
STATIC AIR TEMPERATURE<br />
2) Any EDR (Eddy Dissipation Rate) value larger than 1.26 shall be<br />
represented as 1.26.<br />
20<br />
21<br />
22<br />
Range = [–128, +128]°C<br />
Note 1.— The status bit defined in bit 38 indicates that Average<br />
Turbulence EDR Metric, Peak Turbulence EDR Metric <strong>and</strong> Turbulence<br />
Peak Delay Interval are valid.<br />
23<br />
Note 2.— Two’s complement coding is used <strong>for</strong> all signed fields as<br />
24 LSB = 0.125°C<br />
specified in §A.2.2.2.<br />
25<br />
26<br />
27<br />
28<br />
29<br />
30<br />
31<br />
STATUS<br />
MSB = 4 096 feet<br />
Note 3.— The requirement <strong>for</strong> the range of static air temperature in<br />
Annex 3 is from –80°C to +60°C.<br />
32<br />
33<br />
RADIO HEIGHT<br />
34<br />
35<br />
36<br />
Range = [0, 8 190] feet<br />
37 LSB = 2 feet<br />
38 STATUS<br />
39<br />
40<br />
MSB = 0.64<br />
41<br />
42<br />
AVERAGE TURBULENCE EDR METRIC<br />
43 Range = [0, 1.26] (see 2)<br />
44 LSB = 0.02<br />
45<br />
46<br />
MSB = 0.64<br />
47<br />
48<br />
PEAK TURBULENCE EDR METRIC<br />
49 Range = [0, 1.26] (see 2)<br />
50 LSB = 0.02<br />
51 MSB = 8 minutes<br />
52 TURBULENCE PEAK DELAY INTERVAL<br />
53 Range = [0, 15] minutes<br />
54 LSB = 1 minute<br />
55<br />
56<br />
RESERVED<br />
Draft<br />
— END —<br />
DRAFT - Working Paper ASP TSGWP11-01 <strong>for</strong> review by the TSG during the meeting in June 2011 in Paris