Protocol for Crowd Sourcing Air Domain Awareness

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 23 April 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

• Note: This document is directly related and builds from [MOSKOWITZ-CSRID] expanding it to be more general for ADA. That draft is a "top, down" approach to understand the concept and high level design. This document is a "bottom, up" implementation of the CS-RID concept. The content of this draft is subject to change and adapt as further development continues.¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Architecture

With the initial use case of providing Broadcast RID for ADA to UTM this architecture closely follows and integrates into the wider UTM. See Appendix A of [RFC9434] for more information. All data models in this document are defined in the Concise Data Definition Language (CDDL, [RFC8610]).¶

+--------+
| Finder |
+----o---+
     |
     |         +-----------------+
     |         | Supplemental    |
     '---------o Data Service    o----------.
               | Provider (SDSP) |          |
               +-----------------+          |
                                            |
                                      +-----o-------+
                                      | ADA Clients |
                                      +-------------+

• Author TODO: expand Figure 1 to showcase different Finder sources and optional SDSP-to-SDSP interactions.¶

In this architecture the SDSP depends upon Finders to provide data via its "ingress" and exposes to clients on its "egress" data that has been filtered, aggregated and/or fused.¶

For CS-RID, defined in Section 4, Finders report a mix of raw detections or pre-processed UAS data (detected from Broadcast RID) to the SDSP to be further refined and translated to Network RID for UTM Clients.¶

Links between the SDSP and other entities is assumed to be bi-directional unless otherwise noted by a specific use-case. It is up to a given sensor use case to determine more in depth interaction models between the entities.¶

SDSPs can redirect "ingress" reports with unknown data elements if it knows another SDSP under the same ADA ecosystem that will process those unknown elements. An SDSPs "egress" may feed into another SDSP for further aggregation/fusion with other data sources.¶

It is RECOMMENDED that all participating entities of this ecosystem have a DRIP Entity Tag (DET, [RFC9374]) to enable between the parties during all interactions.¶

report = {
  reporter_id: bstr / tstr / #6.54 / uuid,
  report_window: [
    start: tdate / time,
    end: tdate / time / uint
  ],
  ? brid: [+ detection],
  ? uas: [+ uas_datum],
  ? gnss: gnss_datum,
  ? reporter => reporter-datum,
  ? status => status-datum,
  * &(tstr, int) => any
}

4. Crowd Sourced Remote ID

This document defines two data models, Section 4.1 and Section 4.2, to be used between the Finder and SDSP. The UTM, RID data encapsulation and transportation is already standardized with an overview provided in Appendix A.¶

For CS-RID, Finders and SDSP MUST support Web Tokens over HTTPS (Section 3.2.2) as the primary encapsulation and transport method. The other defined transports in Section 3.2 MAY be supported by an SDSP. Interactions started by the SDSP to the Finder are out of scope for this document with that link (Finder to SDSP) expected to be unidirectional.¶

detection = [
  reporter_position: #6.103 / null,
  detection_time: tdate / time,
  antenna: [ + antenna-info],
  transport: &transport-enum,
  mac_address: #6.48,
  message_counter: uint,
  brid_message: bstr,
  compliance: [* uint]
]

antenna-info = [
  frequency: number / null,
  sector: tstr / null,
  rssi: number
]
transport-enum = (
  0: UKN, 1: BLE, 2: BLR, 3: BCN, 4: NAN, 5: SIK
)

uas_datum = [
  reporter_position: #6.103,
  transports: {
    + &transport-enum: [+ mac_address: #6.48]
  },
  datum: {
    ? timestamp => utc,
    ? uas_type => 0..15,
    ? uas_ids => [
      + [
        id_type: 0..15,
        uas_id: uas-id
      ]
    ],
    ? ua_status => 0..15,
    ? ua_position => [
      lla: position,
      barometric_altitude: number / null
    ],
    ? ua_bearing => uint,
    ? ua_speed => [
      vertical: number / null,
      horizontal: number / null
    ],
    ? ua_height => [
      agl: bool,
      height: number
    ],
    ? accuracy => [
      vertical: 0..15,
      horizontal: 0..15,
      altitude: 0..15,
      barometric: 0..15,
      timestamp: 0..15
    ],
    ? auth => [
      + [
        auth_type: 0..15,
        data: auth-data
      ]
    ],
    ? self_id => [
      desc_type: 0..255,
      desc: tstr .size 23
    ],
    ? fixed_operator_position => position,
    ? gnss_operator_position => position,
    ? take_off_position => position,
    ? classification => [
      region: 0..8,
      category: 0..15,
      class: 0..15
    ],
    ? area => [
      count: 1..255,
      radius: number,
      floor: number,
      ceiling: number
    ],
    ? operator_id => [
      operator_type: 0..255,
      operator_id: tstr .size 20
    ],
    ? compliance => [+ uint]
  }
]

transport-enum = (
  0: UKN, 1: BLE, 2: BLR, 3: BCN, 4: NAN, 5: SIK
)

5. DRIP Requirements Addressed

This document addresses the following requirements from [RFC9153]: GEN-5 (Gateway)¶

6. IANA Considerations

7. Security Considerations

TBD¶

8. Privacy & Transparency Considerations

TBD¶

9. Acknowledgments

The Crowd Sourcing idea in this document came from the Apple "Find My Device" presentation at the International Association for Cryptographic Research's Real World Crypto 2020 conference.¶

10. References

Appendix A. ASTM Network RID Overview

This appendix is normative and an overview of the Network RID portion of [F3411].¶

This appendix is intended a guide to the overall object of Network RID and generally how it functions in context with a SDSP supporting CS-RID. Please refer to the actual standard of [F3411] for specifics in implementing said protocol.¶

For CS-RID the goal is for the SDSP to act as both a Network RID Service Provider (SP) and Network RID Display Provider (DP). The endpoints and models MUST follow the specifications for these roles so UTM clients do not need to implement specific endpoints for CS-RID and can instead leverage existing endpoints.¶

An SDSP SHOULD use Network RID, as it is able, to query a USS for UAS sending telemetry in a given area to integrate into the Broadcast RID it is receiving from Finders. How the SDSP discovers which USS to query is out of scope for this document.¶

An SDSP MUST provide the Network RID DP interface for clients that wish to subscribe for updates on aircraft in the SDSP aggregated coverage area.¶

Appendix B. Additional Report Models

gnss_datum = [
  status: gnss-status,
  errors: [* gnss-error]
]
gnss-status = [
  timestamp: tdate / time,
  position: #6.103,
  dop: [
    hdop: number,
    vdop: number,
    pdop: number
  ] / null,
  fix: 0..3,
  bearing: number,
  speed: number,
  satellites_in_view: uint,
  satellites: [
    * [
      id: uint,
      snr: number,
      elevation: number,
      azimuth: number
    ]
  ]
]
gnss-error = [
  field: tstr,
  reported: any,
  threshold: any
]

reporter-datum = {
  serial: tstr,
  ? make: tstr,
  ? model: tstr,
  ? ip_addr: tstr / #6.52 / #6.54,
  * &(tstr, int) => any
}

status-datum = {
  ? last_detect_time: tdate / time,
  * &(tstr, int) => any
}

Author's Address