Abstract

Introduction

Crowdsourced aviation data has changed many fields over the past 20 years, from academic research in air traffic management and many adjacent fields to journalistic open-source investigations [Strohmeier 2020].

The OpenSky Network has been collecting air traffic data for these use cases for over a decade, growing from only a handful to over 6000 registered sensors. It has enabled around 500 academic publications and publishes regular reports describing avenues for open aviation data use (see [Olive et al. 2020; Sun et al. 2021; Sun et al. 2022]). In recent years, it added Mode S, FLARM and VHF data to the initial ADS-B collection. However, natural crowdsourced growth remains mostly in industrialized countries, leaving large parts of the inhabited world and uninhabited places such as oceans and mountains without any type of data coverage.

This major problem can be partly rectified by the Automatic Dependent Surveillance - Contract (ADS-C) technology. ADS-C is an advanced surveillance system that utilizes the onboard systems of an aircraft to automatically relay pertinent information such as position, altitude, speed, navigation intent, and meteorological data. What sets ADS-C apart from ADS-B is that this contract data is transmitted from the aircraft to specific Air Traffic Services Units (ATSU) or Aeronautical operational control (AOC) facilities via satellite, which in turn can be received by anyone on the ground with a software-defined radio.

Contributions

• We provide a brief background on the ADS-C system, how it works, and how it can be useful for enhancing crowdsourced air traffic research data.

• We discuss our first implementation of a software-defined radio ADS-C downlink satellite receiver.

• We take a first look at the reception capabilities of such a receiver and give an overview of the received data, 227’126 messages collected over 4 months.

We are working on merging the ADS-C data feed into the OpenSky Network, which would prove to be a significant advancement for researchers around the world. Given that ADS-C encompasses many areas currently not within OpenSky’s purview, such an integration could potentially outweigh the benefits of adding numerous new ADS-B receivers. For the time being, we open source the collected ADS-C data on Zenodo [Xapelli et al. 2023] to enable researchers to integrate it into their own analyses.

Background

In this section, we focus on introducing ADS-C and aviation protocols in general as an understanding of these protocols is the prerequisite to the further analysis in this paper. The following sections address questions such as why ADS-C was developed and what its impact is today. Additionally, we delve into the larger ecosystem of aviation communication to highlight how ADS-C relates to other protocols.

History

Born from the challenges in aviation, the International Civil Aviation Organization (ICAO) in 1983 initiated a committee to align emerging technologies with growing air transport needs. By 1987, the committee found issues with the prevailing navigation systems, including communication limitations and the lack of digital links. The answer was satellite technology integration.

This led to the creation of FANS, comprising CPDLC and ADS-C. ADS-C addresses the constraints of High Frequency (HF) and VHF systems through SATCOM, enabling surveillance in remote locations. It also minimizes voice communication by sending automatic position updates digitally. By 1991, manufacturers adopted FANS technology. Boeing introduced FANS-1, while Airbus presented FANS-A. These were later merged into the widely-used FANS-1/A.

It is noteworthy that there is also the competing “Satellite ADS-B” technology, whereby satellite constellations in low-Earth orbit receive ADS-B signals from equipped aircraft [Strohmeier et al. 2019]. However, ADS-C is enjoying more popularity and was chosen by the US Federal Aviation Administration as the main means of oceanic surveillance in 2019 [III 2019]. Notably, Satellite ADS-B signals cannot be received openly on the ground and are thus not available for research.

Impact

Advancements in communication and surveillance technologies have greatly improved aviation safety and efficiency. The traditional separation between aircraft, previously set at 50 nautical miles (nm) laterally and 80 nm longitudinally, has been significantly reduced to 23 nm in both directions for aircraft with FANS systems, without compromising safety [United States Government Accountability Office]. This improved separation has optimized airspace utilization, reduced the likelihood of altitude adjustments due to conflicting paths, and enabled more direct routes thanks to the integration of SATCOM and advanced surveillance [Honeywell]. These improvements have led to less fuel consumption and notable cost-savings for airlines. As a result, the adoption of FANS technology has become widespread, initially in the Pacific and now covering almost all oceanic regions and some continental areas. In the North Atlantic, its implementation is even mandatory [Universal Avionics 2020].

System Overview

Having introduced some of ADS-C’s history and impact, we proceed to provide some context on the protocols used to transmit ADS-C messages, and illustrate how they compare to similar protocols. This is a necessary step for understanding ADS-C, as the aviation communication ecosystem can be complex and somewhat intransparent at times. In order to achieve this, we categorize aviation protocols into the layers Application, Network, and Physical, an approach similar to the ISO/OSI model, although rather simplified. [fig:osi] shows an example of this. In the two application layers, there are ATS protocols such as Oceanic and Departure Clearance, as well as the FANS protocols ADS-C and CPDLC. All these protocols are transmitted over the Aircraft Communications Addressing and Reporting System (ACARS), which is used in most regions of the world. A variant of CPDLC and other ATS clearance applications are transmitted over the newer, Aeronautical Telecommunication Network (ATN-B1), which is only used in Europe [Rogers]. While ATN-B1 uses Very high Frequency Data Link Mode 2 (VDL 2) as the physical layer, the ACARS network can use Satellite Communication (SATCOM) (via Iridium or Inmarsat constellations), High Frequency Data Link (HFDL) or the predecessor of VDL 2 (VDL 0). As these different physical layers use radio waves, they all classify as wireless communication systems.

ADS-C Specific Protocols

In the aviation communication ecosystem, ADS-C operates using specific protocols depicted in [fig:osi]. At the application layer, we have ADS-C and FANS; ACARS at the network layer; and Iridium, Inmarsat, HFDL, and VDL 0 at the physical layer. [fig:system-overview] shows an aircraft with onboard communication and navigation systems. When it sends an ADS-C message, the position is determined, often via GNSS, and transmitted using SATCOM, HFDL, or VDL 0 to a Communication Service Provider (CSP). The CSP then sends it to an Air Traffic Service Unit (ATSU) for processing. The primary focus is on the SATCOM provider Inmarsat due to its prevalent use over Iridium in transmitting FANS messages [Habler et al. 2023].

Protocol Stack

In the following, we focus on understanding the protocols relevant to this paper – ADS-C, FANS, ACARS, and Aero (the communication protocol used by Inmarsat) – in more depth.

In the process of creating and transmitting ADS-C messages, each of the above-mentioned protocols prepends headers and appends checksums to the content of the message. We will now discuss each of these layers, starting with ADS-C, and examine how each layer works and what data it adds to an ADS-C message.

ADS-C

Naturally, at the core of this entire protocol stack lies the ADS-C message itself. As previously mentioned, ADS-C stands for Automatic Dependent Surveillance - Contract. Automatic signifies that ADS-C does not require any interaction with the flight crew; it runs automatically. Dependent means that the system depends on external data such as position and velocity. Next, Surveillance means that the protocol provides data necessary to surveil the aircraft; this includes aspects such as position, velocity, and waypoints. Finally, Contract means that aircraft and ATSUs negotiate contracts to exchange data [Australia]. Although aircraft can establish contracts with multiple ATSUs at once, messages are only exchanged between the aircraft and ATSU that concluded a specific contract. This stands in contrast to ADS-B, where the aircraft broadcasts its messages to all ATSUs in range.

Contracts

Contracts are pivotal to ADS-C. All aircraft surveillance data that researchers might be interested in is transmitted via these contracts on the downlink. To initiate one, the ATSU sends a contract request detailing the desired surveillance data to an aircraft. The aircraft can respond in three ways: a positive acknowledgement with the relevant report, a negative acknowledgement if the message is unintelligible, or a non-compliance notification if it does not have the requested data.

The established contract type determines the data the aircraft relays to the ATSU:

• Periodic contract: This type allows the ATSU to request ADS-C reports at designated intervals. Key information such as flight ID, predicted route, earth reference, meteorological data, airframe ID, air reference, and aircraft intent are included.

• Event contract: With this contract, the aircraft sends reports when certain events occur, like altitude changes or reaching a predetermined waypoint. The events can be vertical range changes, altitude range alterations, waypoint shifts, and lateral deviations.

• Demand contract: In this scenario, the aircraft transmits a singular report, this is useful in particular if a periodic report does not arrive as scheduled.

Modes of Operation

The above-mentioned contracts usually operate in normal-mode. Apart from normal-mode, ADS-C contracts can also operate in emergency-mode. The emergency-mode can be initiated by either the aircraft, which can send an emergency report, or the ATSU, which can transmit an emergency contract. Once the emergency mode is activated, aircraft send reports more frequently than in normal mode.

Each ADS-C report or message includes at least a basic report, which contains the latitude, longitude, and altitude of the aircraft, as well as a timestamp and a figure of merit. The figure of merit indicates the accuracy of the positional data in the report and whether Traffic Alert and Collision Avoidance System (TCAS) is operational. Beyond this basic report, ADS-C messages can append optional submessages or tags.

There are 18 different tags for the downlink format. Referring to Table 1), the tag for the basic report is 07. Furthermore, 09, 10, 18, 19, 20 also provide a detailed position report. Some submessages/tags can be used to predict the future aircraft position (13, 14, 15, 22, 23).

Detailed information on form and function of ADS-C messages can be found in [Airlines Electronic Engineering Committee 1993] and [Radio Technical Commission for Aeronautics 2005].

FANS

ADS-C uses the above-mentioned FANS-1/A version of FANS. This implies that it is a FANS application used over the ACARS network defined by the ARINC 622 [Airlines Electronic Engineering Committee 2001] data communication standard. In the following, we will refer to FANS-1/A simply as FANS.

In order to implement the ARINC 622 standard, FANS prepends a header to the ADS-C message, and adds an integrity check to the end of the message. This integrity check consists of a 16 bit long cyclic redundancy check (CRC). This structure is shown in [fig:fans1a]. The header fields include the address of the ATC center from which the message originates, the Imbedded Message Identifier (IMI), and the Aircraft Registration Number (AN). Since ACARS is a character-oriented network, and ADS-C is bit oriented, the ADS-C message is converted to a character-oriented message using Bit-to-hex conversion (ISO-5).

More information on all the FANS fields and their meaning can be found in [Airlines Electronic Engineering Committee 2001].

ACARS

ACARS is a protocol used to transmit character-oriented data between aircraft and ground systems. It has originally been used by aircraft and their airline to transmit messages concerning information such as fuel and loading status. However, ACARS has more recently also been used to transmit Air Traffic Service applications such as departure clearance, and FANS messages.

The ACARS network is responsible to route messages to the intended destination. This task is achieved by prepending headers and appending a checksum to the message content. The resulting message differs in the uplink and downlink direction. The structure of an uplink ACARS message is shown in [fig:acars], and contains the following fields:

A downlink message additionally contains the fields Message Source, Message Number, Block Sequence Character, Airline Identifier, Flight Identifier, which are inserted before the FANS part of the message.

More information on ACARS message structure and content can be found in [Airlines Electronic Engineering Committee 2016] and [Airlines Electronic Engineering Committee 1998].

Classic Aero

Classic Aero is the last piece in the ADS-C protocol stack. It is an aviation satellite system operated by Inmarsat. This protocol provides voice and data communication using “a space segment of geostationary satellites” [International Civil Aviation Organization 2010], which was originally created to provide connectivity to the shipping industry. Since the late 1980s, Inmarsat also provides its service to the aviation industry. Next to ADS-C over FANS it is also used for applications such as Oceanic Clearance and Digital Automatic Terminal Information Service [International Civil Aviation Organization 2010].

[fig:aero] shows an overview of the Classic Aero system. It depicts an aircraft, called a Aircraft Earth Station (AES), that can receive and transmit data on the L-Band at around 1.6 GHz to a satellite. The satellite ground station, called a Ground Earth Station (GES), can receive data from the satellite on the C-Band at around 3.6 GHz, and transmit signals on around 6.5 GHz.

Communication Channels

The communication between satellite, AES, and GES happens on four different channel types:

• P Channel: This channel type is used in the downlink direction to transmit both signalling and user data. The transmission is continuous, meaning empty packets are sent if there is no user data to be transmitted. In this channel, user data is divided into small Signal Units (SU) prior to transmission; then, multiple SUs are combined in a frame and transmitted.
  

• R Channel: Both the R and T channels are used in the downlink direction. In this case, R stands for Random access channel, signifying that SUs are sent individually in the form of short bursts.
  

• T Channel: Here, T stands for Time Division Multiple Access. It refers to a process where an AES has to request a time slot in which it can transmit data to a GES. This data is then divided into SUs and combined into one large frame, which is then transmitted in a burst.
  

• C Channel: The C channel is used in both directions to carry voice communication.

Many of these channels are grouped together on neighbouring frequency bands and used simultaneously by a single satellite.

In conclusion, ADS-C was developed to use the airspace more efficiently while maintaining the same level of safety. In order to transmit ADS-C messages, they are wrapped in the FANS, ACARS, and Aero protocols. For open aviation research, we focus exclusively on the contracts found on the ADS-C Downlink.

ADS-C Downlink Receiver Setup

The building of an ADS-C downlink receiver requires Line-of-Sight to the satellite to communicate effectively.

Software

This project heavily relies on two pieces of open source software with which one can receive and decode ADS-C messages. The first application is JAERO [Olds 2023], a software which demodulates and decodes ADS-C signals. One shortcoming of JAERO is that it can only decode one Aero channel at a time. This is problematic because, as discussed in [sec:background], ADS-C messages are sent on multiple channels simultaneously. To solve this problem, the second software – SDRReceiver [jeroenbeijer 2023] – has been developed. It splits digital signals into smaller frequency bands, and outputs them individually using the message library ZeroMQ [ZeroMQ]. With this software, multiple JAERO instances can decode each of these signals individually.

In order to receive and store ADS-C messages, we built a pipeline around these already available applications. This pipeline consists of an antenna and an SDR used to receive the ADS-C signal. Additionally, an MQTT client implemented in Python, subscribes to the JAERO instances publishing successfully decoded messages. The client then augments messages with meta information related to the Aero channel the message was received on; this meta information includes frequency, channel type, and data rate. Since ADS-C messages are sent in plain text, no further steps to decode the message are needed. Finally, all this data and its timestamp is stored in a SQLite database, which is sufficient even in the long-term due to the relatively low data volume. This entire process is depicted in [fig:software].

Hardware

As the downlink signal is weak, a satellite dish is required to receive the signal. We used the following hardware to set up our exemplary ADS-C receiver (see Figure 7).

• Antenna: Stationary 2.4 meter C-Band antenna (CPI SAT Series 1252)

• Antenna Feed: C-Band feed with circular polarization (FEED-VSRP3CP300)

• Cable: M&P HyperFlex 10 coaxial cable

• LNB: Low-noise block downconverter (Norsat C-BAND PLL 3000)

• Power Supply: 2 Port LNB power supply (ETL Systems 2785)

• SDR: RTL-SDR RTL2832U

• Intel NUC: Machine running SDRReceiver and JAERO to demodulate and decode the signal.

Setup

Location

Setting up the receiver is complex for several reasons. The location of a downlink receiver is highly restricted because it suffers from interference with the stronger 5G signals on the same frequencies — in practice, it is highly challenging to receive signals in areas with 5G connectivity. Besides these two difficulties, a downlink antenna also needs a clear view of the horizon, as the elevation of geo-stationary satellites used by Inmarsat can be quite low. This view can, for example, be obstructed by mountain ranges. With all of these restrictions, finding a suitable place becomes more and more challenging in the future.

Identifying Satellite and Frequencies

The first step in setting up an ADS-C receiver is to identify the satellite from which to receive data. This is not as straightforward as one might assume because the satellites are constantly updated, migrated, and replaced [Satellitenservices]. Additionally, there is little official information from Inmarsat to be found regarding the position and coverage of their satellites. One of the more recent maps depicting this coverage is presented in [fig:inmarsat-coverage]. According to this map, Central Europe is primarily covered by the Alphasat satellite.

In a next step, we determined on which frequencies the chosen satellite is transmitting signals. A first reference point to achieve this can be public information from aviation enthusiasts such as [Orchard] and [eroenbeijer]. These sources indicate the approximate frequency bands where one could potentially receive signals. However, similar to the satellites’ position, these frequencies are subject to constant change. Therefore, identifying the exact frequencies to receive messages is a manual trial and error process. We have found examining a spectral density plot of the approximate frequency bands in an appropriate tool to be the most successful strategy. Using SDRReceiver, we have obtained the exact frequencies of the signals [Orchard].

Preliminary ADS-C Data Analysis

We now briefly describe the dataset and its basic structure and content. Note that all following data is based only on the Alphasat satellite.

Dataset

We are collecting downlink ADS-C data with our setup with the aim of making it available for open aviation research. In the following we analyse the dataset collected from the 7th July 2023 till the 20th of October 2023, where a cumulative total of 227’126 ADS-C messages have been recorded. Fig. 9 shows the number of received messages per day. The setup has been working for a total of 106 days. Of those, it received messages for 83 days and did not receive messages for 23 days. While the gaps around the beginning of August and in September are explained through outages during our experimentation phase, we observe different levels of message reception, which are caused by the number of detected ADS-C channels from the observed Alphasat satellite. With a single main channel active, the receiver observes between 1500 and 2000 messages a day, with two active channels this doubled to over 4000 messages per day from the end of September.

The dataset has been made available on Zenodo [Xapelli et al. 2023], in the future, we plan to integrate it into the OpenSky data services.

Hourly Analysis

The messages were predominantly received between 00:00 and 16:00 CEST, with an active reception window of approximately 9–10 hours per day. This limited time window is due to the stationary nature of the setup and the fact that the satellite, even though it is geostationary, moves during the course of one day. Beyond the limited daily time, collection shifts earlier by 3.66 minutes a day.

This pattern offers insights into the prevalent operational hours, potentially serving as a significant parameter for ongoing and future research undertakings. In Figure 10 the aggregate variation of messages per hour can be observed over time.

Message Content

Focusing on the content of the messages, it is essential to note that the analysis captures only a subsample of ADS-C messages exchanged on a given flight, as only Alphasat messages were recorded.

An ADS-C message may contain various detailed sections like a Basic Group, a Predicted Route Group, or a Meteorological Group, each serving its unique purpose in conveying crucial flight or environment-related information.

Of all messages, 196,951, equivalent to 86.71%, encompassed a basic report that detailed the position of the respective aircraft (tags 07, 09, 10, 18, 19 and 20). Such positional data is essential for a range of research and operational applications, facilitating effective aircraft location and tracking. Also, approximately 64% of ADS-C messages feature the Predicted Route Group . This comes from the fact that route prediction data is pivotal for Air Traffic Control in traffic management. However, a mere 0.004% and a 0.001% of messages contain an Airframe Identification Group and a Cancel Emergency Mode. Table 1 illustrates the groups of data found in the recorded messages. It is noteworthy that a significant number of these messages include multiple groups.

Table 1 provides the complete list for all 18 recorded tags.

In total, messages from 2999 unique aircraft registrations have been recorded. The aircraft with the most messages (2216) was an Airbus A330-941 from Corsair with the aircraft registration F-HHUG.

Geographic Coverage

After analyzing the messages, 45% of them are sent to the North Atlantic airspace ATSUs, which is the busiest oceanic airspace in the world [Skybrary Change it]. Also, 21% are sent to the Indian Ocean facilities and 15% are located in the African airspace.

Overall, we observed that the captured messages were destined to 72 different ATSUs around the globe. Table 2 lists the 10 most used facilities. Shanwick is far and away the most used in our sample with 55,102 messages, followed by Mogadishu (30,405) and Gander (16,391).

Figure 11 compares the ADS-B coverage of OpenSky during the month of August 2023 with the ADS-C coverage collected during our experiments. The comparison is not entirely straightforward, as there are many more ADS-B data points available due to its much higher update rate.

Still, the potential of even a single satellite, covering large parts of the Atlantic up to the North Pole, the African continent and the Indian Ocean, is staggeringly large. Also note that the lack of coverage over Libya and Sudan comes from no-flight zones over conflict areas. Figure 12 additionally shows some concrete sample flights collected on 18th October 2023.

It is important to note that the location of the ADS-C receiver is not relevant, it collects the same data anywhere in the Alphasat coverage region as long as it is pointed at the same satellite (one may be able to see more than one satellite in some regions). Consequently, four receivers pointed at the four ADS-C satellites can in principle cover the Earth.

Discussion

Potential Research Use Cases

Both the complementary content and in particular the global distribution of the aircraft sending ADS-C data, make it a very interesting resource for researchers. Until now, Africa, for example has largely been neglected by aviation researchers due to the lack of accessible data.

In particular, ADS-C is useful for completing trajectories by combining it with finegrained ground-based ADS-B data. Whereas ADS-B can accurately capture the take-off of an aircraft flying from, say, Europe to the US, ADS-C can fill the gap that happens when the aircraft leaves ground coverage and enters the oceanic airspace. Until now, researchers had to make do with basic dead reckoning methods, drawing a straight line across the ocean and missing many potential intricacies.

Some examples of existing ADS-C work in the literature include temperature and wind observations [De Haan et al. 2013], oceanic collision risk [Mori 2014], or aircraft performance [Mori 2014]. Until now, the data typically came from closed and proprietary sources inaccessible for most researchers and use cases.

Differences between ADS-B and ADS-C

Despite the similar names, there are some inherent technological differences between ADS-B and ADS-C that are relevant to open data collection and research, which we want to explicitly mention.

The most obvious one is certainly the update rate. ADS-B data is typically updated twice a second, Mode S data potentially more often. ADS-C on the other hand has update rates around 10 minutes or more, sufficient to obtain the broad track of an aircraft but not on a tactical or operational level.

Data collection is much more resource-intensive for the individual than cheap ADS-B installations. While costs can be brought down with significant engineering knowledge, installing an ADS-C receiver is only possible for the most enthusiastic of planespotters and more in the realm of institutions. This fact makes it not truly crowdsourced.

Beyond mere aircraft positions, the data content is different. While there is interesting ADS-C specific research content as outlined in this paper, there is no physical-layer data and a lot of Mode S data missing that has been used in the literature for security purposes [Felux et al. 2023].

Finally, as discussed, the coverage is very different between the ground-based ADS-B, which is broadcast almost globally by every transponder-equipped aircraft and ADS-C, which focuses on relatively few equipped large commercial aircraft. ADS-B remains superior in many areas yet ADS-C is a useful complement (see Fig. 11).

Limitations

The most evident limitation is the coverage of our current setup. Operating with only one stationary satellite dish restricts us from achieving a 24/7 coverage. Hence, integrating a second satellite dish focused on the same satellite would be a valuable enhancement. Other satellites may be covered from the same or other vantage points. While this requires significant additional resources, and must be done with global partners, it would extract much additional value for the academic research community. Finally, a more expensive and complex tracking setup can cover a single satellite with only one dish.

Conclusion

In this work, we discussed the utility of the Automatic Dependent Surveillance – Contract technology, long used by several commercial web aggregators such as Flightradar24 and ADSBExchange, for open aviation data. We provided sufficient background to understand the system and its capabilities, needed to start an ADS-C collection station. We implemented such a system, described the data we collected over 4 months and discussed the inherent limitations and differences to the well-known ADS-B data.

Hopefully, this work and our lead will serve as an inspiration. We will keep sharing the data and integrate ADS-C capabilities for open aviation researchers through the OpenSky Network. In light of ADS-C’s great research potential and the fact that only a few ground stations in the Americas and Asia can cover the whole globe, we call on other institutions to do the same.