1. Introduction
Modern aircraft surveillance relies heavily on Mode S data links around the world. Mode S provides air traffic controllers possibilities to selectively interrogate a wide range of flight information related to an aircraft. Different surveillance uplink and downlink protocols are designed in Mode S [
1,
2]. Among these protocols, Comm-B is the most widely used protocol for surveillance downlink, with a downlink format (DF) of 20 and 21. Services such as Mode S elementary surveillance (ELS) and Mode S enhanced surveillance (EHS) both use the Comm-B downlink [
3]. Besides interrogation-based surveillance protocols, Automatic Dependent Surveillance-Broadcast (ADS-B) is also implemented using the Mode S extended squitter (ES) in downlink format 17.
Each Mode S service contains multiple downlink message types. The message types are distinguished by the Comm-B data selector (BDS) code.
Table 1 shows the common Mode S services and related messages. It is worth noting that the BDS codes are not always included in the downlink messages. However, they can be inferred using a set of rules [
4].
The common usage Ground-initiated Comm-B (GICB) capabilities report is a message type of Comm-B downlink belonging to the ELS service. It is used by secondary surveillance radars to obtain Mode S capabilities of a certain aircraft.
Before performing a specific interrogation, the surveillance radar must acquire the transponder capabilities of an aircraft. This is done by obtaining the transponder capability (CA) field, which is extracted from the Mode S all-call reply (DF 11) or ADS-B. The CA field indicates whether the transponder supports 112-bit data downlink. When the long format message downlink is supported, BDS 1,0 (data link capability report) and elementary surveillance (BDS 1,7, BDS 2,0, and BDS 3,0) can be requested. BDS 1,7 (GICB report) indicates if a specific register contains valid data and is updated recently. For example, it can indicate whether specific enhanced surveillance information (BDS 4,0, BDS 5,0, or BDS 6,0) is available for interrogation.
Since a GICB message tells us information regarding aircraft transponders, we can understand how they are equipped globally by using Mode S data from all around the world. In this paper, we make use of raw Mode S data collected by receivers of the OpenSky research network to conduct an extensive study of how the world’s civil aviation aircraft enable their Mode S transponder capabilities. In
Figure 1, the entire process is illustrated.
Given the large quantity of raw data collected by the OpenSky network, we selected the entire month of September 2019 for the analysis. Raw data are downloaded, and GICB messages are extracted and decoded to construct the analysis of this paper.
2. Methods
2.1. Data Extraction from OpenSky Using the Impala Interface
First of all, we need to obtain GICB Mode S replies from the OpenSky historical database. In this task, we used the
pyopensky library (formally known as
pyModeS-opensky [
5]) to perform the Impala querying and Comm-B messages types inference.
OpenSky Impala interface provides access to historical raw Mode S messages that have been collected by receivers in the OpenSky network. Raw data stored in the rollcall_replies_data4 table are extracted for the analysis completed in this paper. We have selected September 2019 as the month for the demonstration. Since the total amount of data are too large to be downloaded through the internet within a reasonable time, we have extracted the data selectively. For every 15 min, we download the first one-minute segments of all raw messages around the world.
These extracted Mode S messages from the OpenSky database do not contain any information regarding the BDS codes. Hence, we first need to infer the BDS code for each message using
pyModeS [
4]. It can identify and decode common Mode S messages, including BDS 1,7 messages.
2.2. Structure of GICB Messages
Currently, 24 of the 56 bits are used in a GICB message. They indicate a variety of common Comm-B capabilities. The definitions for these fields are shown in
Table 2. In this table, each bit reveals whether the corresponding capability is available from the transponder. The first column of the table shows the common capabilities, specifying the corresponding BDS code. The second column indicates the bit location in the downlink message, while the last column indicates the bit location in the MB field (part of the message where Comm-B information is located).
A bit is set to 1 when the corresponding register has a valid value that has been updated within the required rate. When a certain register is not available, it indicates that either the capability is not enabled by the aircraft or that the corresponding value is temporarily unavailable. Therefore, it is possible that the same aircraft reports different GICB reports in time due to the availability of the source data.
We can see there are several groups of capabilities. MB bits 1 to 5 represent the extended squitter (ADS-B) capabilities. MB bit 7 represents one of the ELS capabilities. MB bits 9, 16, and 24 indicate EHS capabilities. The last 32 bits are reserved for future use or testing purposes.
2.3. Identification of a GICB Message
In pyModeS, the identification process relies on the predefined message structure and known bits of all common Comm-B messages to infer the message type (BDS code). For a GICB message, we use the following logic as the identification criteria:
We adopt the first criterion because the aircraft identification is the most basic information in a Mode S communication, and it is required for any ELS compatible transponder. The second criterion is chosen because all reserved bits in Mode S must be set to zero.
When inferring the potential Comm-B message types, pyModeS produces a list of possible BDS codes for each message. We filter only messages with BDS 1,7 (GICB) or messages that have BDS 1,7 as a possible BDS code. For example, both of the following messages are considered in the analysis:
Here, the first message is identified as a GICB message, and the other messages have multiple possibilities including the GICB message. A true GICB message with multiple message types inferred can happen when certain key bits are set to one. These significant bits are:
Bit 12: a status bit in track and turn report, corresponds to capability 4,3 Next, waypoint information in GICB.
Bit 13: a status bit in heading and speed report, corresponds to capability 4,4 Meteorological routine report in GICB.
Bit 14: a status bit in selected vertical intention, corresponds to 4,5 Meteorological hazard report in GICB.
Hence, when the multiple message types case occurs, a relevant approach can be taken:
Do not consider the message as GICB message: This will remove almost all aircraft that have capabilities of Next, waypoint information, Meteorological routine report, or Meteorological hazard report from the dataset.
Consider the message as GICB message: We can obtain aircraft with corresponding capabilities when the message is a true GICB message. However, when the message is not a real GICB message, we are introducing false capabilities for some aircraft.
After exploring the data, we decided to adopt the second approach in this paper. In order to reduce the chance of classifying false GICB messages, we introduce a threshold. A message that has multiple message types needs to have a certain number of occurrences (five in this paper) before it can be considered as a valid GICB message.
2.4. Extracting Aircraft GICB Information
Once a GICB message is successfully identified, corresponding Comm-B capabilities are extracted as shown in
Table 2. Based on the transponder address code (ICAO24 address), we can relate each message to a specific aircraft where the registration, typecode, and model are known (OpenSky aircraft database,
https://opensky-network.org/aircraft-database) is used to find out specific aircraft information).
Since the same aircraft can transmit different GICB messages depending on the availability of source data, we consider all capabilities that are enabled by an aircraft during the entire period of the data as the final GICB capabilities of the transponder. After combining duplicated messages for each aircraft, around 200,000 unique messages are found.
Once GICB information from all aircraft is gathered, we can perform different analyses using this aggregated dataset.
3. Results and Analysis
The analysis consists of four different parts. With these analyses, we can see how often each common GICB capability is enabled among all aircraft and how each aircraft is equipped with different common GICB capabilities. With this data, we can also see the compliance of EHS and ADS-B compatible transponders. Finally, we show which aircraft types are able to transmit meteorological reports.
3.1. Overall GICB Capabilities
In
Figure 2, the overall statistics of common usage GICB capabilities among all aircraft are shown. Since we have assumed that every aircraft is capable of transmitting BDS 2,0, the total number of aircraft in the aggregated data with known aircraft type is around 50,000.
In this figure, we can see that the most common group of capabilities includes BDS 0,5–0,9, which are for Mode S extended squitter (ADS-B). BDS 4,0/5,0/6,0, which are enhanced surveillance parameters, are also frequently enabled.
The least common group of capabilities includes BDS 5,4 - 5,6, which are used to report waypoints. Similarly, the next waypoint information (BDS 4,1–4,3) are less often used, as is also the case for codes 4,5 and 4,8, which are used for meteorological hazard and VHF channel report, respectively.
3.2. GICB Capabilities by Aircraft Type
It is also possible to analyze the common GICB capabilities by aircraft type. In
Figure 3, the statistics for most common aircraft types are displayed. In this figure, we use the darkness and size of the dots to indicate the fraction of aircraft with the same typecode that has enabled certain capabilities. The results in this figure still conform with the overall statistics we have obtained in the earlier
Figure 2. In addition, we now can see the variation between certain BDS codes among different aircraft. Most commercial aircraft are able to transmit ADS-B messages (BDS 0,5–0,9) and enhanced Mode S (BDS 4,0/5,0/6,0). We can see that Embraer E190 is an exception. The number of Embraer E190 aircraft without ADS-B is quite clear from the figure.
3.3. EHS and ADS-B Compliance
Certain Mode S capabilities are mandatory for aircraft that are flying in European airspace. ELS is mandatory for all aircraft that fly instrument flight rules (IFR) in general air traffic (GAT). EHS is mandatory for all fix-wing aircraft flying IFR in GAT with a maximum takeoff weight larger than 5700 kg, or with a maximum cruise speed higher than 250 kt. While the mandate of ADS-B keeps getting postponed, the vast majority of commercial aircraft have ADS-B enabled according to study [
6].
However, compliance for EHS and ADS-B is much lower globally. In
Figure 4, the percentages of EHS and ADS-B compliant aircraft are shown. In the figure, EHS or ADS-B is compliant if at least one of the capabilities in each group is enabled. We can see that only around 67% of the aircraft are equipped with EHS and ADS-B compliant transponders. If we take a look at only Airbus (typecode A3xx) and Boeing (typecode B7xx) aircraft, more than 99% of them can transmit ADS-B and EHS.
3.4. Meteorological Capabilities
In some of our previous studies [
7,
8], meteorological parameters such as wind and temperature have been proven to be important. These types of meteorological parameters are transmitted in the BDS 4,4 meteorological routine report (MRAR). In
Figure 5, we can see that only a small number of aircraft (around 1800 out of 50,000 aircraft) are capable of transmitting the MRAR.
This result also largely agrees with an earlier study conducted by the Royal Netherlands Meteorological Institute, which studied aircraft’s MRAR capabilities in the MUAC area [
9]. However, compared to this earlier study, we have found that a small number of Airbus and Boeing aircraft (Airbus A320s, Boeing 737s, and Boeing 777s) seem to be able to transmit BDS 4,4 messages.
3.5. Database
The resulting data from this paper is shared publicly (The dataset can be found at:
https://github.com/junzis/gicb-db). It contains approximately 50,000 aircraft that were seen by the OpenSky network during the month of September 2019. The structure of this dataset is illustrated with the following fragment (with commas removed):
The first three columns are transponder address, aircraft registration, and aircraft typecode. The remaining columns are the Comm-B Data Selector (BDS) codes, which correspond to specific GICB capabilities. When a value is set to 1, the corresponding aircraft is capable of transmitting these types of downlink messages.
4. Conclusions
In this paper, we studied commonly supported Mode S Comm-B capabilities in aircraft around the world, using the Mode S common usage GICB reply messages, which are designed for air traffic controllers to acquire Mode S capabilities of aircraft. The inference and decoding of this type of messages are made possible by the open-source library pyModeS.
We made use of one month of global raw Mode S data from the OpenSky network to conduct this research. Combined with the OpenSky open aircraft database, we are able to produce statistics for approximately 50,000 aircraft flown during this month globally, including passenger, cargo, general aviation, helicopters, and other aircraft categories. Among all available Mode S capabilities, the statistics showed that around 67% of the aircraft are compliant with the requirements of ADS-B and Mode S enhanced surveillance. It is also found that, among all the aircraft, only around 3.5% of them support downlinking meteorological reports.
It is worth noting that the BDS identification process may introduce errors. Sometimes, other types of messages can be identified as BDS 1,7 messages. In rare cases, it is also possible that errors in one message would produce a valid BDS 1,7 message that seems to come from a different aircraft. This is the limitation of inferring and decoding Mode S message as a third-party observer. To mitigate this problem, in the future, we could make use of larger segments of continuous data instead of the one-minute sample as in this paper. This would allow us to better filter out BDS 1,7 messages.
The resulting database of this paper is shared publicly. However, only the sampling of an entire month of data are analyzed and produced in this paper. This is due to the extremely long duration for downloading large-scale data using the OpenSky impala interface. Aircraft that are out of OpenSky coverage and those aircraft did not fly during the selected month are not considered in the results. Nevertheless, with sufficient time for data downloading, the process described in this paper can be used to explore a large temporal scale of GICB capability information. This can potentially be used for studying the evolution of Mode S transponder capabilities over the world in future studies.