ADS-IP

ADS-IP: Automatic Dependent Surveillance - Internet Protocol:

This is a proposal to create a community-based system that facilitates electronic conspicuity, using an Internet connection, centrally aggregated, with open-data available to the entire flight community. The hope is that this becomes an international community-supported resource, not privately owned, and not for-profit. This depends on open and trustworthy control, with no hidden tracking or profiteering.

To that end, this site has been created as an example. The term Automatic Dependent Surveillance - Internet Protocol (ADS-IP) has been coined to describe this system.

Introduction

To increase flight safety, the US Federal Aviation Administration (FAA) developed the ADS-B system. Use is mandated for aircraft, in most countries, to fly in specific airspaces. Generally speaking, these airspaces (i.e. above 10,000 feet and around large airports) have a focus toward commercial aviation. In all other airspace, typically used by smaller aircraft, participation is voluntary.

The ADS-B system is a certified system. Certification is not simple, and therefore the necessary equipment is relatively expensive. However, most light aircraft have not been equipped with ADS-B systems, and virtually no ultralights, microlights, paramotors, paragliders, or drones participate in the system.

For the sake of safety, it would be advantageous if all aircraft broadcasted their location on a shared system so that all other aircraft could see and avoid them. This would require full voluntary participation. This is an idealistic but worthy goal.

Full voluntary participation only works if participation has no barriers or disadvantages.

Click here for a full screen of the current map: https://ads-ip.net/map

ADS-B and Existing System Definitions

  • Conspicuity: The quality of being noticeable or easy to see.

  • Electronic Conspicuity: Using a digital device to provide conspicuity. This term is currently being used in the aviation community to mean ADS-B or similar.

  • ADS-B: Automatic Dependent Surveillance - Broadcast: The certified system as a whole where aircraft broadcast their position using an AM transmitter (ADSB-Out). Other aircraft receive this message (ADSB-In) and show this traffic on an onboard display. This basic function does not rely on any ground system; it is aircraft-to-aircraft communication. It is split into two frequencies, 1090 MHz and 978 MHz.

  • IP: Internet Protocol. Informally used to indicate that something is Internet based.

  • Aggregator: The ADS-B system uses AM radios for communication. These are digital but not encrypted transmissions. Thousands of worldwide volunteers have set up computer-based receivers to listen for local transmissions and forward them to aggregators. An aggregator collects, filters, and provides a complete data set. This is where we get services like FlightAware, FlightTracker24, adsb.fi, etc. These are unofficial non-certified sources, but generally show most of the ADS-B traffic in real time.

  • EFB: Electronic Flight Bag: A common term for apps which provide a moving map, flight navigation, flight planning, and other tools commonly used by pilots. These apps have replaced the paper maps, map scales, and slide rules historically found in a flight bag. Examples of EFB and flight navigation apps:

    • ForeFlight
    • Garmin Pilot
    • iFly EFB
    • WingX Pro
    • FlyQ
    • DroidEFB
    • Avare
    • SimpleFly
    • Gaggle
    • XCTrack
    • SafeSky

Proposed ADS-IP System

There are several separate systems providing some sort of Electronic Conspicuity. The basic problem is that these do not interact.

  • The certified ADS-B is FAA's official system. The 1090 MHz frequency is used almost exclusively. The 978 MHz frequency was apparently provided for non-commercial aircraft in the USA, but has not been widely adopted and is not used outside of the US.

  • There are non-certified ADS-B transmitters, like SkyEcho. In the US they are relegated to the 978 UAT frequency.

  • Then there are a couple of separate proprietary systems like FLARM, or apps which track users for other users, like Gaggle or XCTrack, but they do not show up on the ADS-B aggregators.

  • Radio Controlled (RC) drones have a FAA required positional broadcast system. It is a completely different and broadcasts via WiFi or Bluetooth.

There is only one sky, and all of us are in it!

We all should be communicating to each other on the same system.

Fortunately...

Everybody that flies probably carries a smartphone. This device has a GPS and way to connect to the outside world. This is the way all EFB apps all work. But even the most popular apps, which track, collect, and saves almost everything about your flight to their system does not provide this information out to the world during your flight.

Therefore:

This proposal is for an international, works everywhere, open-source, open-data, community-supported aggregator which aggregates everything and shows everything flying!

It should be simple. You should just need a smartphone with any flight app to both receive traffic and transmit location to any other app (ADS-B but on IP).

It should be all-inclusive. Any aggregation system which requires a proprietary app, an account, special access, hidden tracking, advertisements, or any sort of hurdle will limit participation. The goal is to get everybody on-board. This website is an example of what can be done, and should be considered a starting point for this work.

Next Steps

Again, this website, this system, is a proposal. It is a preliminary prototype of what can be done. It is functioning, but it does need to be developed and overseen by those in the aviation and technology communities with much more knowledge and experience than myself. The obvious next steps are then:

  • Organization: Establish a foundation and create a board of directors.

  • Technology: Develop a more robust online database and server system. Something that is open to all, but protected from a few.

At this point, I am asking for help from the experts in the aviation community. I individually do not have the skills and resources to move this forward. It really could be great, but help is needed.

ADS-IP Application Programming Interface (API) Standards

If you are a developer or maintainer of an EFB or flight navigation app, the following is for you...

Providing Electronic Conspicuity is insanely easy to do with even the simplest moving-map flight-navigation app. These apps already knows where the user is, you just need somewhere to go with a small amount of information. If this information is to be a common and shared resource, it will require standardization.

The following is a draft of the proposed standardized information packets:

  • Packets shall be as small as possible. This minimizes informational traffic.

  • Packets shall be presented in a commonly available format. The examples below are shown in JSON format.

  • The system shall differentiate users only by a UUID. This shall not be tied to a user name, user email, a MAC address of the sending device, an aircraft tail number, etc. nor shall any personal information be stored on the system. Privacy shall be honored in an effort toward full voluntary participation.

  • The primary use is aircraft-to-aircraft avoidance.

  • With the above stated, there will be requests for additional features to be added to the packet (such as aircraft type, a graphic of the aircraft, a flight plan reference, the flight track, etc.). This should not be prohibited, but these should not become part of the base system. Whatever additional information is necessary for the proprietary feature will be imposed on every other user of the system and will simply increase informational traffic. A suggested solution is for apps to send the base packet to ADS-IP and then use their own system for additional features.

Packet Examples

Packet Standard

JSON For Position Reports, Example:

{"ts":1711929600,
"uu":"44444444-3333-2222-1111-000000000000",
"id":"name-of-user",
"sc":"name-of-app",
"la":45.123456,
"lo":-120.123456,
"sp":100.0,
"di":180.0,
"ad":300.0,
"ac":320.0,
"ms":"Hello World"}

JSON Keys and Values

Key Descriptions:

"ts": Time Stamp in Epoch seconds.
"uu": Unique ID.
"id": The name of the user.
"sc": The name of the source or app.
"la": Latitude in WGS84 degrees.
"lo": Longitude in WGS84 degrees.
"sp": Speed in kilometers per hour.
"di": Direction in WGS84 degrees.
"ad": Altitude, WGS84 datum, in meters.
"ac": Altitude, EGM corrected, in meters.
"ms": Miscellaneous/Message.

Value Descriptions:

"ts": Int 10 (%010i) / no negatives, no decimals.
"uu": String 36 (%.36s) / OSF UUID Standard.
"id": String 20 (%.20s) / truncated.
"sc": String 20 (%.20s) / truncated.
"la": Float 8.6 (%+010.06f) / -90.000000 to +90.000000
"lo": Float 9.6 (%+011.06f) / -179.999999 to +180.000000
"sp": Float 5.1 (%.01f) / 0.0 to 9999.9
"di": Float 4.1 (%.01f) / 0.0 to 359.9
"ad": Float 6.1 (%.01f) / 0.0 to 99999.9
"ac": Float 6.1 (%.01f) / 0.0 to 99999.9
"ms": String 50 (%.50s) / truncated.

ADS-IP Endpoints

If you are a software developer and would like to give the system a try, there are send and receive endpoints available:

An Endpoint in this context is the networked destination or source API. The following endpoints are functional and available, but only at the level for testing and development. Intentionally, there is no filtering of incoming packets nor any need to create some sort of user account. It is encouraged that you give it a try.

Sending Data

Once the information packets are generated by your app, they need an Internet endpoint destination. The ADS-IP Out destination (from the perspective of the aircraft) endpoint API:

UDP to ads-ip.net:31001

From a command line, this example posts an aircraft in the middle of Oregon:

echo '{"ts":1733612234,"uu":"44444444-3333-2222-1111-000000000000","id":"JustTesting","sc":"FakeNews","la":44.000000,"lo":-120.000000,"sp":123.4,"di":180.0,"ad":1123.4,"ac":1234.5,"ms":"Hello World"}' | socat - UDP:ads-ip.net:31001

Receiving Data

To receive information, the following endpoint will return a JSON list. ADS-IP In source (from the perspective of the aircraft) endpoint API:

https://ads-ip.net/00a/out.php

From a browser or from the command line retrieves this list:

curl https://ads-ip.net/00a/out.php

Future Filters

Currently, the above received list includes all available data. In the future, the ADS-IP In API should require the following JSON posts to filter and limit the data results:

Send the location to limit the results to an area (such as this location plus or minus one degree):

{"la":45.123456, "lo":-120.123456}

Send any of the following to limit the results equal to the value sent:

{"uu":"44444444-3333-2222-1111-000000000000",
"sc":"name-of-app",
"id":"name-of-user"}

UUIDs

The UUIDs of the specific user are required in position reports and specific information requests. However, the UUIDs should not be publicly transmitted. They should remain private. This should limit the ability to create false reports about or spam messages to a specific user.

Data Privacy and Trust

Currently, positional data is archived for a limited period of time. For privacy, it is not stored indefinitely. This is being done only to assist in search-and-rescue type needs. These are not accessible from the APIs.

There is no other tracking or data collection hidden from the users.

Maintaining openness and trust is and will be paramount.

Current Status

The ads-ip.net website is a functional platform meant to be used for development and testing. If you are developing an application, feel free to use the endpoints as noted above. As features are developed, this web page will be updated.

Additionally, the API directory /00000000/ is a placeholder and is temporary. It is expected that this will be replaced with /v1/ (for version 1) or something similar once this moves beyond the development stage. Any app you develop should not be permanently coded to these directories; some method should be provided to your users to update the endpoint locations in your app.

In addition to the above, the current client/server system is one based on a file server receiving http posts to a php script. The positional information for each target is saved on the server as an individual file. Data set requests are made to a php script. It is expected that this will transition to a SQL database, being served on multiple and redundant servers, with client/server communication via UDP (or some other type of socket). At that point, your app will require the new method to send and receive information.

Ignorant Data

The downside of a completely open system is the vulnerability to false data. Yep, I have considered the idea of a bunch of targets, arranged Space Invaders style, placed over Area 51. Yes, kids will be kids.

The alternative is to maintain some sort of app and data validation, which would require developers to register as a provider. This may be a necessity, but it should not be limiting. The goal is to have every app providing to and receiving from this system.

In Closing

This is all being provided in the hopes that it is helpful.

It is hoped that a community group or organization will step forward and take on the role of overseeing this work. If this happens, this site will be available for their use, and transferred to their control.

In the meantime, I will watch over it.

Regards,

Worktable CNC, LLC
worktablecnc.us
Robert Haines
Oregon, USA

Contact ads-ip.net

Copyright, provided, and protected by Worktable CNC, LLC. For Details and Terms of Use see: worktablecnc.us/legal

Disclaimer: This site and its services are not certified in any way for flight navigation or control. Absolutely no guarantee is being provided for anything. All owners, agents, associates, etc. of this work shall be indemnified and held harmless. By use of this work you agree to these terms. Use at you own risk.