Internet DRAFT - draft-wiethuechter-drip-csrid
draft-wiethuechter-drip-csrid
DRIP R. Moskowitz
Internet-Draft HTT Consulting
Intended status: Standards Track A. Wiethuechter
Expires: 11 January 2024 AX Enterprize
10 July 2023
Crowd Sourced Remote ID
draft-wiethuechter-drip-csrid-00
Abstract
This document describes a way for an Internet connected device to
forward/proxy received Broadcast Remote ID to Network Remote ID using
UAS Traffic Management (UTM) Supplemental Data Service Providers
(SDSPs). This enables more comprehensive situational awareness and
reporting of Unmanned Aircraft (UA) in a “crowd sourced” manner.
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 11 January 2024.
Copyright Notice
Copyright (c) 2023 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.
Moskowitz & Wiethuechter Expires 11 January 2024 [Page 1]
Internet-Draft CS-RID July 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Role of Supplemental Data Service Provider (SDSP) . . . . 3
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Advantages of Broadcast Remote ID . . . . . . . . . . . . 5
3.2. Meeting the needs of Network Remote ID . . . . . . . . . 5
3.3. Trustworthiness of Proxy Data . . . . . . . . . . . . . . 5
3.4. Defense against fraudulent RID Messages . . . . . . . . . 6
4. SDSP Security Relationship . . . . . . . . . . . . . . . . . 6
4.1. Finder Map . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Managing Finders . . . . . . . . . . . . . . . . . . . . 7
5. Crowd Sourced RID Protocol . . . . . . . . . . . . . . . . . 7
5.1. Detection & Report Structure . . . . . . . . . . . . . . 7
5.2. Unidirectional . . . . . . . . . . . . . . . . . . . . . 8
5.2.1. HTTPS . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Bidirectional . . . . . . . . . . . . . . . . . . . . . . 8
5.3.1. Messages . . . . . . . . . . . . . . . . . . . . . . 9
5.3.2. HIP . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.3. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. GPS Inaccuracy . . . . . . . . . . . . . . . . . . . 12
Appendix B. Using LIDAR for UA location . . . . . . . . . . . . 13
Appendix C. UA location via multilateration . . . . . . . . . . 13
Appendix D. CS-RID Report Examples . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Note: This document is directly related and builds from
[moskowitz-csrid]. 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.
Moskowitz & Wiethuechter Expires 11 January 2024 [Page 2]
Internet-Draft CS-RID July 2023
This document defines a mechanism to capture Broadcast Remote ID
(RID) [F3411] messages on any Internet connected device that receives
them and can forward them to the Supplemental Data Service Providers
(SDSPs) responsible for the geographic area the UA and receivers are
in. This data can be aggregated and further decimated to other
entities in Unmanned Aircraft Systems (UAS) Traffic Management (UTM)
using Network RID [F3411].
These Internet connected devices are herein called “Finders”, as they
find UAs by listening for Broadcast RID. The Finders are Broadcast
RID forwarding proxies. Their potentially limited spacial view of
RID messages could result in bad decisions on what messages to send
to the SDSP and which to drop. Thus they will send all received
messages and the SDSP will make any filtering decisions in what it
forwards into the UTM.
Finders can be smartphones, tablets, connected cars, CS-RID special
purpose devices or any computing platform with Internet connectivity
that can meet the requirements defined in this document. It is not
expected, nor necessary, that Finders have any information about a
UAS beyond the content found in Broadcast RID.
Finders MAY only need a loose association with SDSPs. The SDSP MAY
require a stronger relationship to the Finders. The relationship MAY
be completely open, but still authenticated to requiring encryption.
The transport MAY be client-server based (using things like HIP or
DTLS) to client push (using things like UDP or HTTPS).
1.1. Role of Supplemental Data Service Provider (SDSP)
The DRIP Architecture [drip-arch] introduces the basic CS-RID
entities including CS-RID Finder and SDSP. This document has minimal
information about the actions of SDSPs. In general the SDSP is out
of scope of this document. That said, the SDSPs should not simply
proxy cast RID messages to their UTM(s). They should perform some
minimal level of filtering and content checking before forwarding
those messages that pass these tests in a secure manner to the
UTM(s).
The SDSPs are also capable of maintaining a monitoring map, based on
location of active Finders. UTMs may use this information to notify
authorized observers of where there is and there is not monitoring
coverage. They may also use this information of where to place pro-
active monitoring coverage.
An SDSP should only forward Authenticated messages like those defined
in [drip-auth] to the UTM(s). Further, the SDSP SHOULD validate the
RID and the Authentication signature before forwarding anything from
Moskowitz & Wiethuechter Expires 11 January 2024 [Page 3]
Internet-Draft CS-RID July 2023
the UA, and flagging those RIDs that were not validated. The SDSP
MAY forward all Broadcast RID messages to the UTM, leaving all
decision making on Broadcast messages veracity to the receiving UTM
entity.
When 3 or more Finders are reporting to an SDSP on a specific UA, the
SDSP is in a unique position to perform multilateration on these
messages and compute the Finder’s view of the UA location to compare
with the UA Location/Vector messages. This check against the UA’s
location claims is both a validation on the UA’s reliability as well
as the trustworthiness of the Finders. Other than providing data to
allow for multilateration, this SDSP feature is out of scope of this
document. This function is limited by the location accuracy for both
the Finders and UA.
2. Terms and Definitions
2.1. Requirements 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.
This document uses terms defined in [RFC9153] and [drip-arch].
2.2. Definitions
ECIES: Elliptic Curve Integrated Encryption Scheme. A hybrid
encryption scheme which provides semantic security against an
adversary who is allowed to use chosen-plaintext and chosen-
ciphertext attacks.
Finder: In Internet connected device that can receive Broadcast RID
messages and forward them to a SDSP.
Multilateration: Multilateration (more completely, pseudo range
multilateration) is a navigation and surveillance technique based
on measurement of the times of arrival (TOAs) of energy waves
(radio, acoustic, seismic, etc.) having a known propagation speed.
3. Problem Space
Broadcast and Network RID formats are both defined in [F3411] using
the same data dictionary. Network RID is specified in JSON sent over
HTTPS while Broadcast RID is byte structures sent over wireless
links.
Moskowitz & Wiethuechter Expires 11 January 2024 [Page 4]
Internet-Draft CS-RID July 2023
3.1. Advantages of Broadcast Remote ID
Advantages over Network RID include:
* more readily be implemented directly in the UA. Network RID will
more frequently be provided by the GCS or a pilot’s Internet
connected device.
- If Command and Control (C2) is bi-directional over a direct
radio connection, Broadcast RID could be a straight-forward
addition.
- Small IoT devices can be mounted on UA to provide Broadcast
RID.
* also be used by the UA to assist in Detect and Avoid (DAA).
* is available to observers even in situations with no Internet like
natural disaster situations.
3.2. Meeting the needs of Network Remote ID
The USA Federal Aviation Authority (FAA), in the January 2021 Remote
ID Final rule [FAA-FR], postponed Network Remote ID and focused on
Broadcast Remote ID. This was in response to the UAS vendors
comments that Network RID places considerable demands on then
currently used UAS.
However, Network RID, or equivalent, is necessary for UTM knowing
what soon may be in an airspace and is mandated as required in the
EU. A method that proxies Broadcast RID into UTM can function as an
interim approach to Network RID and continue adjacent to Network RID.
3.3. Trustworthiness of Proxy Data
When a proxy is introduced in any communication protocol, there is a
risk of corrupted data and DOS attacks.
The Finders, in their role as proxies for Broadcast RID, SHOULD be
authenticated to the SDSP (see Section 4). The SDSP can compare the
information from multiple Finders to isolate a Finder sending
fraudulent information. SDSPs can additionally verify authenticated
messages that follow [drip-auth].
The SPDP can manage the number of Finders in an area (see
Section 4.2) to limit DOS attacks from a group of clustered Finders.
Moskowitz & Wiethuechter Expires 11 January 2024 [Page 5]
Internet-Draft CS-RID July 2023
3.4. Defense against fraudulent RID Messages
The strongest defense against fraudulent RID messages is to focus on
[drip-auth] conforming messages. Unless this behavior is mandated,
an SDSP will have to use assorted algorithms to isolate messages of
questionable content.
4. SDSP Security Relationship
SDSPs and Finders SHOULD use EdDSA [RFC8032] keys as their trusted
Identities. The public keys SHOULD be registered DRIP UAS Remote ID
(DETs) [RFC9374] and [drip-reg]. Other similar methods may be used.
During this registration, the Finder gets the SDSP’s EdDSA Public
Key. These Public Keys allow for the following options for
authenticated messaging from the Finder to the SDSP.
The SDSP uses some process (out of scope here) to register the
Finders and their EdDSA Public Key. During this registration, the
Finder gets the SDSP’s EdDSA Public Key. These Public Keys allow for
the following options for authenticated messaging from the Finder to
the SDSP.
1. EdDSA keys are converted to X25519 keys per Curve25519 [RFC7748]
to use in ECIES.
2. ECIES can be used with a unique nonce to authenticate each
message sent from a Finder to the SDSP.
3. ECIES can be used at the start of some period (e.g. day) to
establish a shared secret that is then used to authenticate each
message sent from a Finder to the SDSP sent during that period.
4. HIP [RFC7401] can be used to establish a session secret that is
then used with ESP [RFC4303] to authenticate each message sent
from a Finder to the SDSP.
5. DTLS [RFC5238] can be used to establish a secure connection that
is then used to authenticate each message sent from a Finder to
the SDSP.
4.1. Finder Map
The Finders are regularly providing their SDSP with their location.
This is through the Broadcast RID Proxy Messages and Finder Location
Update Messages. With this information, the SDSP can maintain a
monitoring map. That is a map of where there Finder coverage.
Moskowitz & Wiethuechter Expires 11 January 2024 [Page 6]
Internet-Draft CS-RID July 2023
4.2. Managing Finders
Finder density will vary over time and space. For example, sidewalks
outside an urban train station can be packed with pedestrians at rush
hour, either coming or going to their commute trains. An SDSP may
want to proactively limit the number of active Finders in such
situations.
Using the Finder mapping feature, the SDSP can instruct Finders to
NOT proxy Broadcast RID messages. These Finders will continue to
report their location and through that reporting, the SDSP can
instruct them to again take on the proxying role. For example a
Finder moving slowly along with dozens of other slow-moving Finders
may be instructed to suspend proxying. Whereas a fast-moving Finder
at the same location (perhaps a connected car or a pedestrian on a
bus) would not be asked to suspend proxying as it will soon be out of
the congested area.
5. Crowd Sourced RID Protocol
The CS-RID model is for Finders to send “batch reports” (Section 5.1)
to one or more SDSPs they have a relationship with. This
relationship can be highly anonymous with little prior knowledge of
the Finder (({unidirectional})) to very well defined and pre-
established (Section 5.3).
5.1. Detection & Report Structure
Figure 2 is the report object, defined in CDDL, that is translated
and adapted depending on the specific transport. It carries a batch
of detections (up to a max of 10), the CDDL definition of which is
shown in Figure 1.
csrid_detection = (
timestamp: uint, ; UTC timestamp
? latitude: uint, ; scaled by 10^7
? longitude: uint, ; scaled by 10^7
? altitude: float, ; wgs84 meters
rid_mac: hexdig .size 12,
rid_message: hexdig .size(26..255)
)
Figure 1: Detection CDDL
Moskowitz & Wiethuechter Expires 11 January 2024 [Page 7]
Internet-Draft CS-RID July 2023
csrid_report = {
finder_id: hexdig .size 32 / tstr,
finder_mac: hexdig .size 12,
detection_count: int .size(1..10),
detections: [+ csrid_detection],
signature: tstr
}
Figure 2: Report CDDL
Examples of various translations can be found in Appendix D.
5.2. Unidirectional
Author Note: Section Title is WIP, suggestions welcome
The unidirectional variant can allow for anonymous (non-strongly-
authenticated) Finders to make reports to a publicly known SDSP
endpoint. This is attractive for implementation to be lightweight,
easy to deploy and use, such as over an open HTTPS API. Many clients
(who run Finders in their software) may not be worried of being
tracked for sending such reports.
It is recommended to use bare EdDSA25519 keypairs during the
interactions as keys are expected to change frequently and DETs would
allow for long term tracking of Finders.
5.2.1. HTTPS
Use Section 5.1 as CBOR/JSON.
5.2.2. UDP
Use Section 5.1 as CBOR.
5.3. Bidirectional
Author Note: Section Title is WIP, suggestions welcome
The bidirectional variant imposes a strong authentication and Finder
onboarding process. It is attractive for well defined deployments of
CS-RID, such as being used for area security. Implementations are
RECOMMENDED to use HIP [RFC7401] or DTLS with a DET [RFC9374] as
their primary identity.
A CS-RID SDSP SHOULD allow for any valid registered DET to report to
it.
Moskowitz & Wiethuechter Expires 11 January 2024 [Page 8]
Internet-Draft CS-RID July 2023
Send Section 5.1 as CBOR.
Bidirectionally also gives an added benefit of sending various
commands to Finders to alter their behavior with the relationship.
Unlike Section 5.2 where there is no control of the Finder behavior.
5.3.1. Messages
Defined all in CDDL. Adapted accordingly to given transport.
5.3.1.1. Batch Report
Same as Section 5.1 but removes the lat/lon/alt from detections as
stored and updated separately.
5.3.1.2. Location Update
Provides the lat/lon/alt of the Finder.
5.3.1.3. Parameter Update
Enables SDSP to negotiate changes to Finder parameters such as
detection_count maximum.
5.3.1.4. Filter Conditions
Enabled SDSP to give “smarter” Finders filtering conditions of
detections to be sent back to the SDSP.
5.3.2. HIP
TODO
5.3.3. DTLS
TODO
6. IANA Considerations
TBD
7. Security Considerations
TBD
Moskowitz & Wiethuechter Expires 11 January 2024 [Page 9]
Internet-Draft CS-RID July 2023
7.1. Privacy Concerns
TBD
8. 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.
9. References
9.1. Normative References
[moskowitz-csrid]
Moskowitz, R., Card, S. W., Wiethuechter, A., Zhao, S.,
and H. Birkholz, "Crowd Sourced Remote ID", Work in
Progress, Internet-Draft, draft-moskowitz-drip-crowd-
sourced-rid-10, 8 May 2023,
<https://datatracker.ietf.org/doc/html/draft-moskowitz-
drip-crowd-sourced-rid-10>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
Gurtov, "Drone Remote Identification Protocol (DRIP)
Requirements and Terminology", RFC 9153,
DOI 10.17487/RFC9153, February 2022,
<https://www.rfc-editor.org/info/rfc9153>.
9.2. Informative References
Moskowitz & Wiethuechter Expires 11 January 2024 [Page 10]
Internet-Draft CS-RID July 2023
[drip-arch]
Card, S. W., Wiethuechter, A., Moskowitz, R., Zhao, S.,
and A. Gurtov, "Drone Remote Identification Protocol
(DRIP) Architecture", Work in Progress, Internet-Draft,
draft-ietf-drip-arch-31, 6 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
arch-31>.
[drip-auth]
Wiethuechter, A., Card, S. W., and R. Moskowitz, "DRIP
Entity Tag Authentication Formats & Protocols for
Broadcast Remote ID", Work in Progress, Internet-Draft,
draft-ietf-drip-auth-30, 27 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-drip-
auth-30>.
[drip-reg] Wiethuechter, A. and J. Reid, "DRIP Entity Tag (DET)
Identity Management Architecture", Work in Progress,
Internet-Draft, draft-ietf-drip-registries-12, 10 July
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
drip-registries-12>.
[F3411] ASTM International, "Standard Specification for Remote ID
and Tracking", July 2022,
<https://www.astm.org/f3411-22a.html>.
[FAA-FR] United States Federal Aviation Administration (FAA), "FAA
Remote Identification of Unmanned Aircraft", January 2021,
<https://www.govinfo.gov/content/pkg/FR-2021-01-15/
pdf/2020-28948.pdf>.
[gps-ionosphere]
Unknown, "Ionospheric response to the 2015 St. Patrick's
Day storm A global multi-instrumental overview", September
2015, <https://doi.org/10.1002/2015JA021629>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
the Datagram Congestion Control Protocol (DCCP)",
RFC 5238, DOI 10.17487/RFC5238, May 2008,
<https://www.rfc-editor.org/info/rfc5238>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
Moskowitz & Wiethuechter Expires 11 January 2024 [Page 11]
Internet-Draft CS-RID July 2023
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<https://www.rfc-editor.org/info/rfc7401>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
"DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
<https://www.rfc-editor.org/info/rfc9374>.
Appendix A. GPS Inaccuracy
Single-band, consumer grade, GPS on small platforms is not accurate,
particularly for altitude. Longitude/latitude measurements can
easily be off by 3M based on satellite position and clock accuracy.
Altitude accuracy is reported in product spec sheets and actual tests
to be 3x less accurate. Altitude accuracy is hindered by ionosphere
activity. In fact, there are studies of ionospheric events (e.g.
2015 St. Patrick’s day [gps-ionosphere]) as measured by GPS devices
at known locations. Thus where a UA reports it is rarely accurate,
but may be accurate enough to map to visual sightings of single UA.
Smartphones and particularly smartwatches are plagued with the same
challenge, though some of these can combine other information like
cell tower data to improve location accuracy. FCC E911 accuracy, by
FCC rules is NOT available to non-E911 applications due to privacy
concerns, but general higher accuracy is found on some smart devices
than reported for consumer UA. The SDSP MAY have information on the
Finder location accuracy that it can use in calculating the accuracy
of a multilaterated location value. When the Finders are fixed
assets, the SDSP may have very high trust in their location for
trusting the multilateration calculation over the UA reported
location.
Moskowitz & Wiethuechter Expires 11 January 2024 [Page 12]
Internet-Draft CS-RID July 2023
Appendix B. Using LIDAR for UA location
If the Finder has LIDAR or similar detection equipment (e.g. on a
connected car) that has full sky coverage, the Finder can use this
equipment to locate UAs in its airspace. The Finder would then be
able to detect non-participating UAs. A non-participating UA is one
that the Finder can “see” with the LIDAR, but not “hear” any
Broadcast RID messages.
These Finders would then take the LIDAR data, construct appropriate
Broadcast RID messages, and forward them to the SDSP as any real
Broadcast RID messages. There is an open issue as what to use for
the actual RemoteID and MAC address.
The SDSP would do the work of linking information on a non-
participating UA that it has received from multiple Finders with
LIDAR detection. In doing so, it would have to select a RemoteID to
use.
A seemingly non-participating UA may actually be a UA that is beyond
range for its Broadcast RID but in the LIDAR range.
This would provide valuable information to SDSPs to forward to UTMs
on potential at-risk situations.
At this time, research on LIDAR and other detection technology is
needed. there are full-sky LIDAR for automotive use with ranges
varying from 20M to 250M. Would more than UA location information be
available? What information can be sent in a CS-RID message for such
“unmarked” UAs?
Appendix C. UA location via multilateration
The SDSP can confirm/correct the UA location provided in the
Location/Vector message by using multilateration on data provided by
at least 3 Finders that reported a specific Location/Vector message
(Note that 4 Finders are needed to get altitude sign correctly). In
fact, the SDSP can calculate the UA location from 3 observations of
any Broadcast RID message. This is of particular value if the UA is
only within reception range of the Finders for messages other than
the Location/Vector message.
This feature is of particular value when the Finders are fixed assets
with highly reliable GPS location, around a high value site like an
airport or large public venue.
Appendix D. CS-RID Report Examples
Moskowitz & Wiethuechter Expires 11 January 2024 [Page 13]
Internet-Draft CS-RID July 2023
{
finder_id: "20010030000000050000000000000000",
finder_mac: "001122334455",
detection_count: 1,
detections: [
{
timestamp: 0.0,
latitude: 0.0,
longitude: 0.0,
altitude: 0.0,
rid_mac: "667788990011",
rid_message: "0002000000000000000000000000000000000000000000000000"
}
],
signature: "base64"
}
Figure 3: Example JSON Report
Authors' Addresses
Robert Moskowitz
HTT Consulting
Oak Park, MI 48237
United States of America
Email: rgm@labs.htt-consult.com
Adam Wiethuechter
AX Enterprize
4947 Commercial Drive
Yorkville, NY 13495
United States of America
Email: adam.wiethuechter@axenterprize.com
Moskowitz & Wiethuechter Expires 11 January 2024 [Page 14]
