rfc9153.original.xml   rfc9153.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- draft submitted in xml v3 -->
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?> <!DOCTYPE rfc [
<?rfc sortrefs="yes"?> <!ENTITY nbsp "&#160;">
<?rfc compact="yes" ?> <!ENTITY zwsp "&#8203;">
<?rfc subcompact="no" ?> <!ENTITY nbhy "&#8209;">
<?rfc iprnotified="no" ?> <!ENTITY wj "&#8288;">
<?rfc strict="no" ?> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
docName="draft-ietf-drip-reqs-18" category="info" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-drip-
ipr="trust200902" obsoletes="" updates="" submissionType="IETF" reqs-18" number="9153" ipr="trust200902" obsoletes="" updates="" submissionType=
xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" "IETF" category="info" consensus="true" xml:lang="en" tocInclude="true" symRefs=
version="3"> "true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.37.1 --> <!-- xml2rfc v2v3 conversion 2.37.1 -->
<front> <front>
<title abbrev="DRIP Requirements">Drone Remote Identification Protocol <title abbrev="DRIP Requirements">Drone Remote Identification Protocol (D
(DRIP) Requirements</title> RIP) Requirements and Terminology
<seriesInfo name="Internet-Draft" value="draft-ietf-drip-reqs-18"/> </title>
<seriesInfo name="RFC" value="9153"/>
<author fullname="Stuart W. Card" <author fullname="Stuart W. Card"
initials="S." surname="Card" role="editor"> initials="S." surname="Card" role="editor">
<organization>AX Enterprize</organization> <organization>AX Enterprize</organization>
<address> <address>
<postal> <postal>
<street>4947 Commercial Drive</street> <street>4947 Commercial Drive</street>
<city>Yorkville</city> <city>Yorkville</city>
<region>NY</region> <region>NY</region>
<code>13495</code> <code>13495</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>stu.card@axenterprize.com</email> <email>stu.card@axenterprize.com</email>
</address> </address>
</author> </author>
<author fullname="Adam Wiethuechter" <author fullname="Adam Wiethuechter"
initials="A." surname="Wiethuechter"> initials="A." surname="Wiethuechter">
<organization>AX Enterprize</organization> <organization>AX Enterprize</organization>
<address> <address>
<postal> <postal>
<street>4947 Commercial Drive</street> <street>4947 Commercial Drive</street>
<city>Yorkville</city> <city>Yorkville</city>
<region>NY</region> <region>NY</region>
<code>13495</code> <code>13495</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>adam.wiethuechter@axenterprize.com</email> <email>adam.wiethuechter@axenterprize.com</email>
</address> </address>
</author> </author>
<author fullname="Robert Moskowitz" <author fullname="Robert Moskowitz"
initials="R" surname="Moskowitz"> initials="R" surname="Moskowitz">
<organization>HTT Consulting</organization> <organization>HTT Consulting</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>Oak Park</city> <city>Oak Park</city>
<region>MI</region> <region>MI</region>
<code>48237</code> <code>48237</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>rgm@labs.htt-consult.com</email> <email>rgm@labs.htt-consult.com</email>
</address> </address>
</author> </author>
<author fullname="Andrei Gurtov" initials="A." surname="Gurtov"> <author fullname="Andrei Gurtov" initials="A." surname="Gurtov">
<organization>Linköping University</organization> <organization>Linköping University</organization>
<address> <address>
<postal> <postal>
<street>IDA</street> <street>IDA</street>
<city>Linköping</city> <city>Linköping</city>
<code>58183</code> <code>58183</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>gurtov@acm.org</email> <email>gurtov@acm.org</email>
</address> </address>
</author> </author>
<date year="2021"/> <date year="2022" month="February" />
<area>Internet</area> <area>Internet</area>
<workgroup>DRIP</workgroup> <workgroup>DRIP</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>DRIP</keyword> <keyword>DRIP</keyword>
<abstract> <abstract>
<t> <t>
This document defines terminology and requirements for Drone Remote This document defines terminology and requirements for solutions produced by
Identification Protocol (DRIP) Working Group solutions to support the Drone Remote Identification Protocol (DRIP) Working Group. These
Unmanned Aircraft System Remote Identification and tracking (UAS solutions will support Unmanned Aircraft System Remote Identification and
RID) for security, safety, and other purposes (e.g., initiation of tracking (UAS RID) for security, safety, and other purposes (e.g.,
identity based network sessions supporting UAS applications). DRIP initiation of identity-based network sessions supporting UAS applications).
will facilitate use of existing Internet resources to support RID DRIP will facilitate use of existing Internet resources to support RID and
and to enable enhanced related services, and will enable online and to enable enhanced related services, and it will enable online and offline
offline verification that RID information is trustworthy. verification that RID information is trustworthy.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <name>Introduction</name> <section numbered="true" toc="default"> <name>Introduction</name>
<t>
This document defines terminology and requirements for solutions produced by
the Drone Remote Identification Protocol (DRIP) Working Group. These
solutions will support Unmanned Aircraft System Remote Identification and
tracking (UAS RID) for security, safety, and other purposes (e.g.,
initiation of identity-based network sessions supporting UAS applications).
DRIP will facilitate use of existing Internet resources to support RID and
to enable enhanced related services, and it will enable online and offline
verification that RID information is trustworthy.
</t>
<t> <t>
For any unfamiliar or <em>a priori</em> ambiguous terminology For any unfamiliar or a priori ambiguous terminology
herein, see <xref target="terms" format="default"/>. herein, see <xref target="terms" format="default"/>.
</t> </t>
<section numbered="true" toc="default"> <name>Motivation and External Influences </name> <section numbered="true" toc="default"> <name>Motivation and External Influences </name>
<t> <t>
Many considerations (especially safety and security) necessitate Many considerations (especially safety and security) necessitate
Unmanned Aircraft Systems (UAS) Remote Identification and tracking Unmanned Aircraft System Remote Identification and tracking
(RID). (UAS RID).
</t> </t>
<t> <t>
Unmanned Aircraft (UA) may be fixed wing, rotary wing (e.g., Unmanned Aircraft (UA) may be fixed-wing, rotary-wing (e.g.,
helicopter), hybrid, balloon, rocket, etc. Small fixed wing UA helicopter), hybrid, balloon, rocket, etc. Small fixed-wing UA
typically have Short Take-Off and Landing (STOL) capability; rotary typically have Short Take-Off and Landing (STOL) capability; rotary-wing
wing and hybrid UA typically have Vertical Take-Off and Landing and
hybrid UA typically have Vertical Take-Off and Landing
(VTOL) capability. UA may be single- or multi-engine. The most (VTOL) capability. UA may be single- or multi-engine. The most
common today are multicopters: rotary wing, multi engine. The common today are multicopters (rotary-wing, multi-engine). The
explosion in UAS was enabled by hobbyist development, for explosion in UAS was enabled by hobbyist development
multicopters, of advanced flight stability algorithms, enabling of advanced flight stability algorithms for multicopters that enabled ev
even inexperienced pilots to take off, fly to a location of en
interest, hover, and return to the take-off location or land at a inexperienced pilots to take off, fly to a location of interest,
hover, and return to the takeoff location or land at a
distance. UAS can be remotely piloted by a human (e.g., with a distance. UAS can be remotely piloted by a human (e.g., with a
joystick) or programmed to proceed from Global Navigation Satellite joystick) or programmed to proceed from Global Navigation Satellite
System (GNSS) waypoint to waypoint in a weak form of autonomy; System (GNSS) waypoint to waypoint in a weak form of autonomy;
stronger autonomy is coming. stronger autonomy is coming.
</t> </t>
<t> <t>
Small UA are "low observable" as they: Small UA are "low observable" as they:
</t> </t>
<ul spacing="normal" empty="false"> <ul spacing="normal" empty="false">
<li> <li>
typically have small radar cross sections; typically have small radar cross sections;
</li> </li>
<li> <li>
make noise quite noticeable at short ranges but difficult to make noise that is quite noticeable at short ranges but difficult to
detect at distances they can quickly close (500 meters in under detect at distances they can quickly close (500 meters in under
13 seconds by the fastest consumer mass market drones available 13 seconds by the fastest consumer mass-market drones available
in early 2021); in early 2021);
</li> </li>
<li> <li>
typically fly at low altitudes (e.g., for those to which RID typically fly at low altitudes (e.g.,
applies in the US, under 400 feet Above Ground Level (AGL) as under 400 feet Above Ground Level (AGL) for UA to which RID appli
per <xref target="Part107" format="default"/>); es in the US, as
per <xref target="Part107" format="default"/>); and
</li> </li>
<li> <li>
are highly maneuverable so can fly under trees and between are highly maneuverable and thus can fly under trees and between
buildings. buildings.
</li> </li>
</ul> </ul>
<t> <t>
UA can carry payloads including sensors, cyber and kinetic weapons, UA can carry payloads (including sensors, cyber weapons, and kinetic weap ons)
or can be used themselves as weapons by flying them into targets. or can be used themselves as weapons by flying them into targets.
They can be flown by clueless, careless, or criminal operators. They can be flown by clueless, careless, or criminal operators.
Thus the most basic function of UAS RID is "Identification Friend Thus, the most basic function of UAS RID is "Identification Friend
or Foe" (IFF) to mitigate the significant threat they present. or Foe (IFF)" to mitigate the significant threat they present.
</t> </t>
<t> <t>
Diverse other applications can be enabled or facilitated by RID. Diverse other applications can be enabled or facilitated by RID.
Internet protocols typically start out with at least one entity Internet protocols typically start out with at least one entity
already knowing an identifier or locator of another; but an entity already knowing an identifier or locator of another; but an entity
(e.g., UAS or Observer device) encountering an <em>a priori</em> (e.g., UAS or Observer device) encountering an a priori
unknown UA in physical space has no identifier or logical space unknown UA in physical space has no identifier or logical space
locator for that UA, unless and until one is provided somehow. RID locator for that UA, unless and until one is provided somehow. RID
provides an identifier, which, if well chosen, can facilitate use provides an identifier, which, if well chosen, can facilitate use
of a variety of Internet family protocols and services to support of a variety of Internet family protocols and services to support
arbitrary applications, beyond the basic security functions of RID. arbitrary applications beyond the basic security functions of RID.
For most of these, some type of identifier is essential, e.g., For most of these, some type of identifier is essential, e.g.,
Network Access Identifier (NAI), Digital Object Identifier (DOI), Network Access Identifier (NAI), Digital Object Identifier (DOI),
Uniform Resource Identifier (URI), domain name, or public key. DRIP Uniform Resource Identifier (URI), domain name, or public key. DRIP
motivations include both the basic security and the broader motivations include both the basic security and the broader
application support functions of RID. The general scenario is application support functions of RID. The general scenario is
illustrated in <xref target="Scenario" format="default"/>. illustrated in <xref target="Scenario" format="default"/>.
</t> </t>
<figure anchor="Scenario"> <figure anchor="Scenario">
<name>"General UAS RID Usage Scenario"</name> <name>General UAS RID Usage Scenario</name>
<artwork type="ascii-art"> <artwork type="ascii-art">
+-----+ +-----+ +-----+ +-----+
| UA1 | | UA2 | | UA1 | | UA2 |
+-----+ +-----+ +-----+ +-----+
+----------+ +----------+ +----------+ +----------+
| General | | Public | | General | | Public |
| Public | | Safety | | Public | | Safety |
| Observer o------\ /------o Observer | | Observer o------\ /------o Observer |
+----------+ | | +----------+ +----------+ | | +----------+
skipping to change at line 203 skipping to change at line 210
| Public o---/ | \---o Private | | Public o---/ | \---o Private |
| Registry | | | Registry | | Registry | | | Registry |
+----------+ | +----------+ +----------+ | +----------+
+--o--+ +--o--+
| DNS | | DNS |
+-----+ +-----+
</artwork> </artwork>
</figure> </figure>
<t> <t>
<xref target="Scenario" format="default"/> illustrates a typical <xref target="Scenario" format="default"/> illustrates a typical
case where there may be: multiple Observers, some of them members case where there may be the following:
of the general public, others government officers with public
safety/security responsibilities; multiple UA in flight within
observation range, each with its own pilot/operator; at least one
registry each for lookup of public and (by authorized parties only)
private information regarding the UAS and their pilots/operators;
and in the DRIP vision, DNS resolving various identifiers and
locators of the entities involved.
</t> </t>
<ul>
<li> multiple Observers, some of them members of the general public
and others government officers with public safety and security
responsibilities,</li>
<li> multiple UA in flight within observation range, each with its own
pilot/operator,</li>
<li> at least one registry each for lookup of public and (by authorized
parties only) private information regarding the UAS and their
pilots/operators, and</li>
<li> in the DRIP vision, DNS resolving various identifiers and locators
of the entities involved.</li>
</ul>
<t> <t>
Note the absence of any links to/from the UA in the figure; this is Note the absence of any links to/from the UA in the figure; this is
because UAS RID and other connectivity involving the UA varies. because UAS RID and other connectivity involving the UA varies.
Some connectivity paths do or do not exist depending upon the Some connectivity paths do or do not exist depending upon the
scenario. Command and Control (C2) from the GCS to the UA via the scenario. Command and Control (C2) from the Ground Control Station (GCS) to the UA via the
Internet (e.g., using LTE cellular) is expected to become much more Internet (e.g., using LTE cellular) is expected to become much more
common as Beyond Visual Line Of Sight (BVLOS) operations increase; common as Beyond Visual Line Of Sight (BVLOS) operations increase;
in such a case, there is typically not also a direct wireless link in such a case, there is typically not also a direct wireless link
between the GCS and UA. Conversely, if C2 is running over a direct between the GCS and UA. Conversely, if C2 is running over a direct
wireless link, then typically the GCS has but the UA lacks Internet wireless link, then the GCS typically has Internet
connectivity. Further, paths that nominally exist, such as between connectivity, but the UA does not. Further, paths that nominally exist, s
uch as between
an Observer device and the Internet, may be severely intermittent. an Observer device and the Internet, may be severely intermittent.
These connectivity constraints are likely to have an impact, e.g., These connectivity constraints are likely to have an impact, e.g.,
on how reliably DRIP requirements can be satisfied. on how reliably DRIP requirements can be satisfied.
</t> </t>
<t> <t>
An Observer of UA may need to classify them, as illustrated An Observer of UA may need to classify them, as illustrated
notionally in <xref target="Classification" format="default"/>, for notionally in <xref target="Classification" format="default"/>, for
basic airspace Situational Awareness (SA). An Observer who basic airspace Situational Awareness (SA).
classifies a UAS: as Taskable, can ask it to do something useful; An Observer can classify a UAS as one of the following and treat as:
as Low Concern, can reasonably assume it is not malicious and would
cooperate with requests to modify its flight plans for safety
concerns that arise; as High Concern or Unidentified, can focus
surveillance on it.
</t> </t>
<ul>
<li> Taskable: can ask it to do something useful.</li>
<li> Low Concern: can reasonably assume it is not
malicious and would cooperate with requests to modify its flight
plans for safety concerns that arise.</li>
<li> High Concern or Unidentified: can focus surveillance on it.</li>
</ul>
<figure anchor="Classification"> <figure anchor="Classification">
<name>"Notional UAS Classification"</name> <name>Notional UAS Classification</name>
<artwork type="ascii-art"> <artwork type="ascii-art">
xxxxxxx xxxxxxx
x x No +--------------+ x x No +--------------+
x ID? x+---->| Unidentified | x ID? x+---->| Unidentified |
x x +--------------+ x x +--------------+
xxxxxxx xxxxxxx
+ +
| Yes | Yes
v v
xxxxxxx xxxxxxx
x x x x
skipping to change at line 259 skipping to change at line 279
xxxxxxx xxxxxxx
x x x x
.---------+x Type? x+----------. .---------+x Type? x+----------.
| x x | | x x |
| xxxxxxx | | xxxxxxx |
| + | | + |
v v v v v v
+--------------+ +--------------+ +--------------+ +--------------+ +--------------+ +--------------+
| Taskable | | Low Concern | | High Concern | | Taskable | | Low Concern | | High Concern |
+--------------+ +--------------+ +--------------+ +--------------+ +--------------+ +--------------+
</artwork> </artwork>
</figure> </figure>
<t> <t>
ASTM International, Technical Committee F38 (UAS), Subcommittee The widely cited "Standard Specification for Remote ID and Tracking" <xre
F38.02 (Aircraft Operations), Work Item WK65041, developed the f
widely cited Standard Specification for Remote ID and Tracking target="F3411-19" format="default"/> was developed by ASTM International
<xref target="F3411-19" format="default"/>: the published standard , Technical Committee F38 (UAS), Subcommittee F38.02
is available for purchase from ASTM and as an ASTM membership (Aircraft Operations), Work Item WK65041.
premium; early drafts are freely available as <xref The published standard is
target="OpenDroneID" format="default"/> specifications. <xref available for purchase from ASTM and is also available as an ASTM members
target="F3411-19" format="default"/> is frequently referenced in hip premium;
DRIP, where building upon its link layers and both enhancing early draft versions are freely available as Open Drone ID specifications
support for and expanding the scope of its applications are <xref target="OpenDroneID" format="default"/>. <xref target="F3411-19"
central foci. format="default"/> is frequently referenced in DRIP, where building
upon its link layers and both enhancing support for and expanding the
scope of its applications are central foci.
</t> </t>
<t> <t>
In many applications, including UAS RID, identification and In many applications, including UAS RID, identification and
identifiers are not ends in themselves; they exist to enable identifiers are not ends in themselves; they exist to enable
lookups and provision of other services. lookups and provision of other services.
</t> </t>
<t> <t>
Using UAS RID to facilitate vehicular (V2X) communications and Using UAS RID to facilitate vehicular (i.e., Vehicle-to-Everything (V2X)) communications and
applications such as Detect And Avoid (DAA), which would impose applications such as Detect And Avoid (DAA), which would impose
tighter latency bounds than RID itself, is an obvious possibility, tighter latency bounds than RID itself, is an obvious possibility; this i
explicitly contemplated in the United States (US) Federal Aviation s
Administration (FAA) Remote Identification of Unmanned Aircraft explicitly contemplated in the "Remote Identification of Unmanned Aircraf
rule <xref target="FRUR" format="default"/>. However, usage of RID t"
rule of the US Federal Aviation
Administration (FAA) <xref target="FRUR" format="default"/>. However, usa
ge of RID
systems and information beyond mere identification (primarily to systems and information beyond mere identification (primarily to
hold operators accountable after the fact), including DAA, have hold operators accountable after the fact), including DAA, were
been declared out of scope in ASTM F38.02 WK65041, based on a declared out of scope in ASTM F38.02 WK65041, based on a
distinction between RID as a security standard vs DAA as a safety distinction between RID as a security standard versus DAA as a safety
application. Aviation community Standards Development Organizations application. Standards Development Organizations
(SDOs) generally set a higher bar for safety than for security, (SDOs) in the aviation community generally set a higher bar for safety th
an for security,
especially with respect to reliability. Each SDO has its own especially with respect to reliability. Each SDO has its own
cultural set of connotations of safety vs security; the denotative cultural set of connotations of safety versus security; the denotative
definitions of the International Civil Aviation Organization (ICAO) definitions of the International Civil Aviation Organization (ICAO)
are cited in <xref target="terms" format="default"/>. are cited in <xref target="terms" format="default"/>.
</t> </t>
<t> <t>
<xref target="Opinion1" format="default"/> and <xref target="WG105" <xref target="Opinion1" format="default"/> and <xref target="WG105"
format="default"/> cite the Direct Remote Identification (DRI) format="default"/> cite the Direct Remote Identification (DRI)
previously required and specified, explicitly stating that whereas previously required and specified, explicitly stating that whereas
DRI is primarily for security purposes, the "Network Identification DRI is primarily for security purposes, the "Network Identification
Service" <xref target="Opinion1" format="default"/> (in the context Service" <xref target="Opinion1" format="default"/> (in the context
of U-space <xref target="InitialView" format="default"/>) or of U-space <xref target="InitialView" format="default"/>) or
"Electronic Identification" <xref target="WG105" format="default"/> "Electronic Identification" <xref target="WG105" format="default"/>
is primarily for safety purposes (e.g., Air Traffic Management, is primarily for safety purposes (e.g., Air Traffic Management,
especially hazards deconfliction) and also is allowed to be used especially hazards deconfliction) and also is allowed to be used
for other purposes such as support of efficient operations. These for other purposes such as support of efficient operations. These
emerging standards allow the security and safety oriented systems emerging standards allow the security- and safety-oriented systems
to be separate or merged. In addition to mandating both Broadcast to be separate or merged. In addition to mandating both Broadcast
and Network one-way to Observers, they will use V2V to other UAS and Network RID one-way to Observers, they will use Vehicle-to-Vehicle (V 2V) to other UAS
(also likely to and/or from some manned aircraft). These reflect (also likely to and/or from some manned aircraft). These reflect
the broad scope of the European Union (EU) U-space concept, as the broad scope of the European Union (EU) U-space concept, as
being developed in the Single European Sky ATM Research (SESAR) being developed in the Single European Sky ATM Research (SESAR)
Joint Undertaking, the U-space architectural principles of which Joint Undertaking, the U-space architectural principles of which
are outlined in <xref target="InitialView" format="default"/>. are outlined in <xref target="InitialView" format="default"/>.
</t> </t>
<t> <t>
ASD-STAN is an Associated Body to CEN (European Committee for ASD-STAN is an Associated Body to CEN (European Committee for
Standardization) for Aerospace Standards. It is publishing an EU Standardization) for Aerospace Standards. It has published an EU
standard "Aerospace series - Unmanned Aircraft Systems - Part 002: standard titled "Aerospace series - Unmanned Aircraft Systems - Part 002:
Direct Remote Identification; English version prEN 4709-002:2020" Direct Remote Identification" <xref target="ASDSTAN4709-002" format="defa
for which a current (early 2021) informal overview is freely ult"/>;
available in <xref target="ASDRI" format="default"/>. It will a current (early 2021) informal overview is freely
available in <xref target="ASDRI" format="default"/> (note that <xref tar
get="ASDRI" format="default"/> may not precisely reflect the final standard as i
t was published before <xref target="ASDSTAN4709-002" format="default"/>). It wi
ll
provide compliance to cover the identical DRI requirements provide compliance to cover the identical DRI requirements
applicable to drones of classes C1 - <xref target="Delegated" applicable to drones of the following classes:
format="default"/> Part 2, C2 - <xref target="Delegated"
format="default"/> Part 3, C3 - <xref target="Delegated"
format="default"/> Part 4, C5 - <xref target="Amended"
format="default"/> Part 16, and C6 - <xref target="Amended"
format="default"/> Part 17.
</t> </t>
<ul>
<li>C1 (<xref target="Delegated" format="default"/>, Part 2) </li>
<li>C2 (<xref target="Delegated" format="default"/>, Part 3) </li>
<li>C3 (<xref target="Delegated" format="default"/>, Part 4) </li>
<li>C5 (<xref target="Amended" format="default"/>, Part 16) </li>
<li>C6 (<xref target="Amended" format="default"/>, Part 17) </li>
</ul>
<t> <t>
The standard contemplated in <xref target="ASDRI" The standard contemplated in <xref target="ASDRI"
format="default"/> will provide UA capability to be identified in format="default"/> will provide UA capability to be identified in
real time during the whole duration of the flight, without specific real time during the whole duration of the flight, without specific
connectivity or ground infrastructure link, utilizing existing connectivity or ground infrastructure link, utilizing existing
mobile devices within broadcast range. It will use Bluetooth 4, mobile devices within broadcast range. It will use Bluetooth 4,
Bluetooth 5, Wi-Fi Neighbor Awareness Networking (NAN, also known Bluetooth 5, Wi-Fi Neighbor Awareness Networking (NAN) (also known
as Wi-Fi Aware, <xref target="WiFiNAN" format="default"/>) and/or as "Wi-Fi Aware" <xref target="WiFiNAN" format="default"/>), and/or
IEEE 802.11 Beacon modes. The EU standard emphasis was IEEE 802.11 Beacon modes. The emphasis of the EU standard is
compatibility with <xref target="F3411-19" format="default"/>, compatibility with <xref target="F3411-19" format="default"/>,
although there are differences in mandatory and optional message although there are differences in mandatory and optional message
types and fields. types and fields.
</t> </t>
<t> <t>
The <xref target="ASDRI" format="default"/> contemplated DRI system The DRI system contemplated in <xref target="ASDRI" format="default"/>
will broadcast locally: will broadcast the following locally:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li> <li>
the UAS operator registration number; the UAS operator registration number;
</li> </li>
<li> <li>
the <xref target="CTA2063A" format="default"/> compliant unique the <xref target="CTA2063A" format="default"/>-compliant unique
serial number of the UA; serial number of the UA;
</li> </li>
<li> <li>
a time stamp, the geographical position of the UA, and its a time stamp, the geographical position of the UA, and its
height AGL or above its take-off point; height AGL or above its takeoff point;
</li> </li>
<li> <li>
the UA ground speed and route course measured clockwise from the UA ground speed and route course measured clockwise from
true north; true north;
</li> </li>
<li> <li>
the geographical position of the remote pilot, or if that is the geographical position of the Remote Pilot, or if that is
not available, the geographical position of the UA take-off not available, the geographical position of the UA takeoff
point; and point; and
</li> </li>
<li> <li>
for Classes C1, C2, C3, the UAS emergency status. for classes C1, C2, C3, the UAS emergency status.
</li> </li>
</ol> </ol>
<t> <t>
Under the <xref target="ASDRI" format="default"/> contemplated Under the
standard, data will be sent in plain text and the UAS operator standard contemplated in <xref target="ASDRI" format="default"/>, data wi
ll be sent in plaintext, and the UAS operator
registration number will be represented as a 16-byte string registration number will be represented as a 16-byte string
including the (European) state code. The corresponding private ID including the (European) state code. The corresponding private ID
part will contain 3 characters that are not broadcast but used by part will contain three characters that are not broadcast but used by
authorities to access regional registration databases for authorities to access regional registration databases for
verification. verification.
</t> </t>
<t> <t>
ASD-STAN also contemplates corresponding Network Remote ASD-STAN also contemplates corresponding Network Remote Identification
Identification (NRI) functionality. The ASD-STAN RID target is to (NRI) functionality. ASD-STAN plans to revise their current standard
revise their current standard with additional functionality (e.g., with additional functionality (e.g., DRIP) to be published no later
DRIP) to be published before 2022 <xref target="ASDRI" than 2022 <xref target="ASDRI" format="default"/>.
format="default"/>.
</t> </t>
<t> <t>
Security oriented UAS RID essentially has two goals: enable the Security-oriented UAS RID essentially has two goals: 1) enable the
general public to obtain and record an opaque ID for any observed general public to obtain and record an opaque ID for any observed
UA, which they can then report to authorities; and enable UA, which they can then report to authorities and 2) enable
authorities, from such an ID, to look up information about the UAS authorities, from such an ID, to look up information about the UAS
and its operator. Safety oriented UAS RID has stronger and its operator. Safety-oriented UAS RID has stronger
requirements. requirements.
</t> </t>
<t> <t>
Although dynamic establishment of secure communications between the Dynamic establishment of secure communications between the Observer
Observer and the UAS pilot seems to have been contemplated by the and the UAS pilot seems to have been contemplated by the FAA UAS ID
FAA UAS ID and Tracking Aviation Rulemaking Committee (ARC) in and Tracking Aviation Rulemaking Committee (ARC) in <xref
their <xref target="Recommendations" format="default"/>, it is not target="Recommendations" format="default"/>; however, aside from DRIP,
addressed in any of the subsequent regulations or international SDO it is not addressed in any of the subsequent regulations or
technical specifications, other than DRIP, known to the authors as international SDO technical specifications known to the authors as of
of early 2021. early 2021.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <name>Concerns and Constraints</name> <section numbered="true" toc="default"> <name>Concerns and Constraints</name>
<t> <t>
Disambiguation of multiple UA flying in close proximity may be very Disambiguation of multiple UA flying in close proximity may be very
challenging, even if each is reporting its identity, position, and challenging, even if each is reporting its identity, position, and
velocity as accurately as it can. velocity as accurately as it can.
</t> </t>
<t> <t>
The origin of information in UAS RID and UAS Traffic Management The origin of information in UAS RID and UAS Traffic Management
(UTM) generally is the UAS or its operator. Self-reports may be (UTM) generally is the UAS or its operator. Self-reports may be
initiated by the remote pilot at the console of the Ground Control initiated by the Remote Pilot at the console of the GCS (the UAS subsyste
Station (GCS, the UAS subsystem used to remotely operate the UA), m used to remotely operate the UA)
or automatically by GCS software; in Broadcast RID, they typically or automatically by GCS software; in Broadcast RID, they are typically
would be initiated automatically by a process on the UA. Data in initiated automatically by a process on the UA. Data in
the reports may come from sensors available to the operator (e.g., the reports may come from sensors available to the operator (e.g.,
radar or cameras), the GCS (e.g., "dead reckoning" UA location, radar or cameras), the GCS (e.g., "dead reckoning" UA location,
starting from the takeoff location and estimating the displacements starting from the takeoff location and estimating the displacements
due to subsequent piloting commands, wind, etc.), or the UA itself due to subsequent piloting commands, wind, etc.), or the UA itself
(e.g., an on-board GNSS receiver); in Broadcast RID, all the data (e.g., an on-board GNSS receiver). In Broadcast RID, all the data
must be sent proximately by, and most of the data comes ultimately must be sent proximately by the UA, and most of the data ultimately comes
from, the UA itself. Whether information comes proximately from the from the UA. Whether information comes proximately from the
operator, or from automated systems configured by the operator, operator or from automated systems configured by the operator,
there are possibilities not only of unintentional error in but also there are possibilities of unintentional error in and
of intentional falsification of this data. Mandating UAS RID, intentional falsification of this data.
specifying data elements required to be sent, monitoring compliance Mandating UAS RID,
and enforcing it (or penalizing non-compliance) are matters for specifying data elements required to be sent, monitoring compliance,
Civil Aviation Authorities (CAAs) et al; specifying message and enforcing compliance (or penalizing non-compliance) are matters for
formats, etc. to carry those data elements has been addressed by Civil Aviation Authorities (CAAs) and potentially other authorities. Spec
other SDOs; offering technical means, as extensions to external ifying message
formats and supporting technologies to carry those data elements has been
addressed by
other SDOs. Offering technical means, as extensions to external
standards, to facilitate verifiable compliance and standards, to facilitate verifiable compliance and
enforcement/monitoring, are opportunities for DRIP. enforcement/monitoring is an opportunity for DRIP.
</t> </t>
<t> <t>
Minimal specified information must be made available to the public. Minimal specified information must be made available to the public.
Access to other data, e.g., UAS operator Personally Identifiable Access to other data, e.g., UAS operator Personally Identifiable
Information (PII), must be limited to strongly authenticated Information (PII), must be limited to strongly authenticated
personnel, properly authorized in accordance with applicable personnel, properly authorized in accordance with applicable
policy. The balance between privacy and transparency remains a policy. The balance between privacy and transparency remains a
subject for public debate and regulatory action; DRIP can only subject for public debate and regulatory action; DRIP can only
offer tools to expand the achievable trade space and enable offer tools to expand the achievable trade space and enable
trade-offs within that space. <xref target="F3411-19" trade-offs within that space. <xref target="F3411-19"
format="default"/>, the basis for most current (2021) thinking format="default"/>, the basis for most current (2021) thinking
about and efforts to provide UAS RID, specifies only how to get the about and efforts to provide UAS RID, specifies only how to get the
UAS ID to the Observer: how the Observer can perform these lookups UAS ID to the Observer: how the Observer can perform these lookups
and how the registries first can be populated with information are and how the registries first can be populated with information are
unspecified therein. not specified therein.
</t> </t>
<t> <t>
The need for nearly universal deployment of UAS RID is pressing: The need for nearly universal deployment of UAS RID is pressing:
consider how negligible the value of an automobile license plate consider how negligible the value of an automobile license plate
system would be if only 90% of the cars displayed plates. This system would be if only 90% of the cars displayed plates. This
implies the need to support use by Observers of already ubiquitous implies the need to support use by Observers of already-ubiquitous
mobile devices (typically smartphones and tablets). Anticipating mobile devices (typically smartphones and tablets). Anticipating
CAA requirements to support legacy devices, especially in light of CAA requirements to support legacy devices, especially in light of
<xref target="Recommendations" format="default"/>, <xref <xref target="Recommendations" format="default"/>, <xref
target="F3411-19" format="default"/> specifies that any UAS sending target="F3411-19" format="default"/> specifies that any UAS sending
Broadcast RID over Bluetooth must do so over Bluetooth 4, Broadcast RID over Bluetooth must do so over Bluetooth 4,
regardless of whether it also does so over newer versions; as UAS regardless of whether it also does so over newer versions. As UAS
sender devices and Observer receiver devices are unpaired, this sender devices and Observer receiver devices are unpaired, this
implies extremely short "advertisement" (beacon) frames. unpaired state requires use of the extremely short BT4 "advertisement"
(beacon) frames.
</t> </t>
<t> <t>
Wireless data links to or from UA are challenging. Flight is often Wireless data links to or from UA are challenging. Flight is often
amidst structures and foliage at low altitudes over varied terrain. amidst structures and foliage at low altitudes over varied terrain.
UA are constrained in both total energy and instantaneous power by UA are constrained in both total energy and instantaneous power by
their batteries. Small UA imply small antennas. Densely populated their batteries. Small UA imply small antennas. Densely populated
volumes will suffer from link congestion: even if UA in an airspace volumes will suffer from link congestion: even if UA in an airspace
volume are few, other transmitters nearby on the ground, sharing volume are few, other transmitters nearby on the ground, sharing
the same license free spectral band, may be many. Thus air to air the same license free spectral band, may be many. Thus, air-to-air
and air to ground links will generally be slow and unreliable. and air-to-ground links will generally be slow and unreliable.
</t> </t>
<t> <t>
UAS Cost, Size, Weight, and Power (CSWaP) constraints are severe. UAS Cost, Size, Weight, and Power (CSWaP) constraints are severe.
CSWaP is a burden not only on the designers of new UAS for sale, CSWaP is a burden not only on the designers of new UAS for sale
but also on owners of existing UAS that must be retrofit. Radio but also on owners of existing UAS that must be retrofit. Radio
Controlled (RC) aircraft modelers, "hams" who use licensed amateur Controlled (RC) aircraft modelers, "hams" who use licensed amateur
radio frequencies to control UAS, drone hobbyists, and others who radio frequencies to control UAS, drone hobbyists, and others who
custom build UAS, all need means of participating in UAS RID, custom build UAS all need means of participating in UAS RID
sensitive to both generic CSWaP and application-specific that are sensitive to both generic CSWaP and application-specific
considerations. considerations.
</t> </t>
<t> <t>
To accommodate the most severely constrained cases, all these To accommodate the most severely constrained cases, all of the concerns descri
conspire to motivate system design decisions that complicate the bed above
protocol design problem. conspire to motivate system design decisions that complicate the
protocol design problem.
</t> </t>
<t> <t>
Broadcast RID uses one-way local data links. UAS may have Internet Broadcast RID uses one-way local data links. UAS may have Internet
connectivity only intermittently, or not at all, during flight. connectivity only intermittently, or not at all, during flight.
</t> </t>
<t> <t>
Internet-disconnected operation of Observer devices has been deemed Internet-disconnected operation of Observer devices has been deemed
by ASTM F38.02 too infrequent to address. However, the preamble to by ASTM F38.02 as too infrequent to address. However, the preamble to
<xref target="FRUR" format="default"/> cites "remote and rural <xref target="FRUR" format="default"/> cites "remote and rural
areas that do not have reliable Internet access" as a major reason areas that do not have reliable Internet access" as a major reason
for requiring Broadcast rather than Network RID, and states that for requiring Broadcast rather than Network RID. <xref target="FRUR" form
"Personal wireless devices that are capable of receiving 47 CFR at="default"/> also states:</t>
<blockquote>
Personal wireless devices that are capable of receiving 47 CFR
part 15 frequencies, such as smart phones, tablets, or other part 15 frequencies, such as smart phones, tablets, or other
similar commercially available devices, will be able to receive similar commercially available devices, will be able to receive
broadcast remote identification information directly without broadcast remote identification information directly without
reliance on an Internet connection". Internet-disconnected reliance on an Internet connection.
</blockquote>
<t>Internet-disconnected
operation presents challenges, e.g., for Observers needing access operation presents challenges, e.g., for Observers needing access
to the <xref target="F3411-19" format="default"/> web based to the <xref target="F3411-19" format="default"/> web-based
Broadcast Authentication Verifier Service or needing to do external Broadcast Authentication Verifier Service or needing to do external
lookups. lookups.
</t> </t>
<t> <t>
As RID must often operate within these constraints, heavyweight As RID must often operate within these constraints, heavyweight
cryptographic security protocols or even simple cryptographic cryptographic security protocols or even simple cryptographic
handshakes are infeasible, yet trustworthiness of UAS RID handshakes are infeasible, yet trustworthiness of UAS RID
information is essential. Under <xref target="F3411-19" information is essential. Under <xref target="F3411-19"
format="default"/>, <em>even the most basic datum, the UAS ID format="default"/>, <em>even the most basic datum, the UAS ID
itself, can be merely an unsubstantiated claim</em>. itself, can be merely an unsubstantiated claim</em>.
skipping to change at line 522 skipping to change at line 551
lookups. lookups.
</t> </t>
<t> <t>
As RID must often operate within these constraints, heavyweight As RID must often operate within these constraints, heavyweight
cryptographic security protocols or even simple cryptographic cryptographic security protocols or even simple cryptographic
handshakes are infeasible, yet trustworthiness of UAS RID handshakes are infeasible, yet trustworthiness of UAS RID
information is essential. Under <xref target="F3411-19" information is essential. Under <xref target="F3411-19"
format="default"/>, <em>even the most basic datum, the UAS ID format="default"/>, <em>even the most basic datum, the UAS ID
itself, can be merely an unsubstantiated claim</em>. itself, can be merely an unsubstantiated claim</em>.
</t> </t>
<t> <t>
Observer devices being ubiquitous, thus popular targets for malware Observer devices are ubiquitous; thus, they are popular targets for malwa
or other compromise, cannot be generally trusted (although the user re
of each device is compelled to trust that device, to some extent); or other compromise, so they cannot be generally trusted (although the us
a "fair witness" functionality (inspired by <xref target="Stranger" er
of each device is compelled to trust that device, to some extent).
A "fair witness" functionality (inspired by <xref target="Stranger"
format="default"/>) is desirable. format="default"/>) is desirable.
</t> </t>
<t> <t>
Despite work by regulators and SDOs, there are substantial gaps in Despite work by regulators and SDOs, there are substantial gaps in
UAS standards generally and UAS RID specifically. <xref UAS standards generally and UAS RID specifically. <xref
target="Roadmap" format="default"/> catalogs UAS related standards, target="Roadmap" format="default"/> catalogs UAS-related standards,
ongoing standardization activities and gaps (as of 2020); Section ongoing standardization activities, and gaps (as of 2020); Section
7.8 catalogs those related specifically to UAS RID. DRIP will 7.8 catalogs those related specifically to UAS RID. DRIP will
address the most fundamental of these gaps, as foreshadowed above. address the most fundamental of these gaps, as foreshadowed above.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <name>DRIP Scope</name> <section numbered="true" toc="default"> <name>DRIP Scope</name>
<t> <t>
DRIP’s initial charter is to make RID immediately actionable, in DRIP's initial objective is to make RID immediately actionable,
both Internet and local-only connected scenarios (especially especially in emergencies, in severely constrained UAS environments
emergencies), in severely constrained UAS environments, balancing (both Internet and local-only connected scenarios), balancing legitimate
legitimate (e.g., public safety) authorities’ Need To Know (e.g., public safety) authorities' Need To Know trustworthy information
trustworthy information with UAS operators’ privacy. By with UAS operators' privacy.
"immediately actionable" is meant information of sufficient The phrase
precision, accuracy, timeliness, etc. for an Observer to use it as "immediately actionable" means information of sufficient
the basis for immediate decisive action, whether that be to trigger precision, accuracy, and timeliness for an Observer to use it as
a defensive counter-UAS system, to attempt to initiate the basis for immediate decisive action (e.g., triggering
communications with the UAS operator, to accept the presence of the a defensive counter-UAS system, attempting to initiate
communications with the UAS operator, accepting the presence of the
UAS in the airspace where/when observed as not requiring further UAS in the airspace where/when observed as not requiring further
action, or whatever, with potentially severe consequences of any action, etc.) with potentially severe consequences of any
action or inaction chosen based on that information. For further action or inaction chosen based on that information. For further
explanation of the concept of immediate actionability, see <xref explanation of the concept of immediate actionability, see <xref
target="ENISACSIRT" format="default"/>. target="ENISACSIRT" format="default"/>.
</t> </t>
<t> <t>
Note that UAS RID must achieve nearly universal adoption, but DRIP Note that UAS RID must achieve nearly universal adoption, but DRIP can
can add value even if only selectively deployed. Authorities with add value even if only selectively deployed. Authorities with
jurisdiction over more sensitive airspace volumes may set a higher jurisdiction over more sensitive airspace volumes may set a RID
than generally mandated RID requirement for flight in such volumes. requirement, for flight in such volumes, that is higher than generally
Those with a greater need for high-confidence IFF can equip with mandated. Those with a greater need for high-confidence IFF can equip
DRIP, enabling strong authentication of their own aircraft and with DRIP, enabling strong authentication of their own aircraft and
allied operators without regard for the weaker (if any) allied operators without regard for the weaker (if any) authentication
authentication of others. of others.
</t> </t>
<t> <t>
DRIP (originally Trustworthy Multipurpose Remote Identification, DRIP (originally "Trustworthy Multipurpose Remote Identification
TM-RID) potentially could be applied to verifiably identify other (TM-RID)") could be applied to verifiably identify other types of
types of registered things reported to be in specified physical registered things reported to be in specified physical
locations, and providing timely trustworthy identification data is locations. Providing timely trustworthy identification data is also
also prerequisite to identity-oriented networking, but the urgent prerequisite to identity-oriented networking. Despite the value of
motivation and clear initial focus is UAS. Existing Internet DRIP to these and other potential applications, UAS RID is the urgent
resources (protocol standards, services, infrastructure, and motivation and clear initial focus of DRIP. Existing Internet
business models) should be leveraged. resources (protocol standards, services, infrastructure, and business
models) should be leveraged.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <name>Document Scope</name> <section numbered="true" toc="default"> <name>Document Scope</name>
<t> <t>
This document describes the problem space for UAS RID conforming to This document describes the problem space for UAS RID conforming to
proposed regulations and external technical standards, defines proposed regulations and external technical standards, defines
common terminology, specifies numbered requirements for DRIP, common terminology, specifies numbered requirements for DRIP,
identifies some important considerations (IANA, security, privacy identifies some important considerations (IANA, security, privacy,
and transparency), and discusses limitations. and transparency), and discusses limitations.
</t> </t>
<t> <t>
A natural Internet-based approach to meet these requirements is A natural Internet-based approach to meet these requirements is
described in a companion architecture document <xref described in a companion architecture document <xref
target="I-D.ietf-drip-arch" format="default"/> and elaborated in target="I-D.ietf-drip-arch" format="default"/> and elaborated in
other DRIP documents. other DRIP documents.
</t> </t>
</section> </section>
</section> </section>
<section anchor="terms" numbered="true" toc="default"> <name>Terms and Definitio ns</name> <section anchor="terms" numbered="true" toc="default"> <name>Terms and Definitio ns</name>
<section numbered="true" toc="default"> <name>Requirements Terminology</name> <section numbered="true" toc="default"> <name>Requirements Terminology</name>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
and "OPTIONAL" in this document are to be interpreted as described IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
in BCP 14 <xref target="RFC2119" format="default"/> <xref NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
target="RFC8174" format="default"/> when, and only when, they RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="default"> <name>Definitions</name> <section numbered="true" toc="default"> <name>Definitions</name>
<t> <t>
This section defines a non-comprehensive set of terms expected to This section defines a non-comprehensive set of terms expected to be
be used in DRIP documents. This list is meant to be the DRIP used in DRIP documents. This list is meant to be the DRIP
terminology reference; as such, some of the terms listed below are terminology reference; as such, some of the terms listed below are
not used in this document. not used in this document.
</t> </t>
<t> <t>
<xref target="RFC4949" format="default"/> provides a glossary To encourage comprehension necessary for adoption of DRIP by the
of Internet security terms that should be used where applicable. intended user community, the UAS community's norms are respected
herein, and definitions are quoted in cases where they have been
found in that community's documents. Most of the terms listed
below are from that community (even if specific source documents
are not cited); any terms that are DRIP-specific or defined by
this document are marked "(DRIP)".
</t> </t>
<t> <t>
In the UAS community, the plural form of acronyms generally is the Note that, in the UAS community, the plural form of an acronym,
same as the singular form, e.g., Unmanned Aircraft System (singular) generally, is the same as the singular form, e.g., Unmanned Aircraft
and Unmanned Aircraft Systems (plural) are both represented as UAS. System (singular) and Unmanned Aircraft Systems (plural) are both
On this and other terminological issues, to encourage comprehension represented as UAS.
necessary for adoption of DRIP by the intended user community, that
community's norms are respected herein, and definitions are quoted
in cases where they have been found in that community's documents.
Most of the listed terms are from that community (even if specific
source documents are not cited); any that are DRIP-specific or
invented by the authors of this document are marked "(DRIP)".
</t> </t>
<t>
<xref target="RFC4949" format="default"/> provides a glossary
of Internet security terms that should be used where applicable.
</t>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>4-D</dt> <dt>4-D</dt>
<dd> <dd>
Four-dimensional. Latitude, Longitude, Altitude, Time. Us ed Four-dimensional. Latitude, Longitude, Altitude, Time. Us ed
especially to delineate an airspace volume in which an especially to delineate an airspace volume in which an
operation is being or will be conducted. operation is being or will be conducted.
</dd> </dd>
<dt>AAA</dt> <dt>AAA</dt>
<dd> <dd>
Attestation, Authentication, Authorization, Access Contro l, Attestation, Authentication, Authorization, Access Contro l,
skipping to change at line 652 skipping to change at line 691
AirBorne DAA. Accomplished using systems onboard the AirBorne DAA. Accomplished using systems onboard the
aircraft involved. Supports "self-separation" (remaining aircraft involved. Supports "self-separation" (remaining
"well clear" of other aircraft) and collision avoidance. "well clear" of other aircraft) and collision avoidance.
</dd> </dd>
<dt>ADS-B</dt> <dt>ADS-B</dt>
<dd> <dd>
Automatic Dependent Surveillance - Broadcast. "ADS-B Out" Automatic Dependent Surveillance - Broadcast. "ADS-B Out"
equipment obtains aircraft position from other on-board equipment obtains aircraft position from other on-board
systems (typically GNSS) and periodically broadcasts it t o systems (typically GNSS) and periodically broadcasts it t o
"ADS-B In" equipped entities, including other aircraft, "ADS-B In" equipped entities, including other aircraft,
ground stations, and satellite based monitoring systems. ground stations, and satellite-based monitoring systems.
</dd> </dd>
<dt>AGL</dt> <dt>AGL</dt>
<dd> <dd>
Above Ground Level. Relative altitude, above the variousl y Above Ground Level. Relative altitude, above the variousl y
defined local ground level, typically of a UA, measured i n defined local ground level, typically of a UA, measured i n
feet or meters. Should be explicitly specified as either feet or meters. Should be explicitly specified as either
barometric (pressure) or geodetic (GNSS) altitude. barometric (pressure) or geodetic (GNSS) altitude.
</dd> </dd>
<dt>ATC</dt> <dt>ATC</dt>
<dd> <dd>
Air Traffic Control. Explicit flight direction to pilots Air Traffic Control. Explicit flight direction to pilots
from ground controllers. Contrast with ATM. from ground controllers. Contrast with ATM.
</dd> </dd>
<dt>ATM</dt> <dt>ATM</dt>
<dd> <dd>
Air Traffic Management. A broader functional and geograph ic Air Traffic Management. A broader functional and geograph ic
scope and/or a higher layer of abstraction than ATC. "The scope and/or a higher layer of abstraction than ATC.
<xref
target="ICAOATM" format="default"/> defines ATM as the f
ollowing: "The
dynamic, integrated management of air traffic and airspac e dynamic, integrated management of air traffic and airspac e
including air traffic services, airspace management and a ir including air traffic services, airspace management and a ir
traffic flow management - safely, economically and traffic flow management -- safely, economically and
efficiently - through the provision of facilities and efficiently -- through the provision of facilities and
seamless services in collaboration with all parties and seamless services in collaboration with all parties and
involving airborne and ground-based functions" <xref involving airborne and ground-based functions".
target="ICAOATM" format="default"/>. </dd>
</dd>
<dt>Authentication Message</dt> <dt>Authentication Message</dt>
<dd> <dd>
<xref target="F3411-19" format="default"/> Message Type 2 . <xref target="F3411-19" format="default"/> Message Type 2 .
Provides framing for authentication data, only; the only Provides framing for authentication data only; the only
message that can be extended in length by segmenting it message that can be extended in length by segmenting it
across more than one page. across more than one page.
</dd> </dd>
<dt>Basic ID Message</dt> <dt>Basic ID Message</dt>
<dd> <dd>
<xref target="F3411-19" format="default"/> Message Type 0 . <xref target="F3411-19" format="default"/> Message Type 0 .
Provides UA Type, UAS ID Type (and Specific Session ID Provides UA Type, ID Type (and Specific Session ID
subtype if applicable), and UAS ID, only. subtype if applicable), and UAS ID only.
</dd> </dd>
<dt>Broadcast Authentication Verifier Service</dt> <dt>Broadcast Authentication Verifier Service</dt>
<dd> <dd>
System component designed to handle any authentication of System component designed to handle any authentication of
Broadcast RID by offloading signature verification to a w eb Broadcast RID by offloading signature verification to a w eb
service <xref target="F3411-19" format="default"/>. service <xref target="F3411-19" format="default"/>.
</dd> </dd>
<dt>BVLOS</dt> <dt>BVLOS</dt>
<dd> <dd>
Beyond Visual Line Of Sight. See VLOS. Beyond Visual Line Of Sight. See VLOS.
</dd> </dd>
<dt>byte</dt> <dt>byte</dt>
<dd> <dd>
Used here in its now-customary sense as a synonym for Used here in its now-customary sense as a synonym for
"octet", as "byte" is used exclusively in definitions of "octet", as "byte" is used exclusively in definitions of
data structures specified in <xref target="F3411-19" data structures specified in <xref target="F3411-19"
format="default"/> format="default"/>.
</dd> </dd>
<dt>CAA</dt> <dt>CAA</dt>
<dd> <dd>
Civil Aviation Authority of a regulatory jurisdiction. Civil Aviation Authority of a regulatory jurisdiction.
Often so named, but other examples include the United Often so named, but other examples include the United
States Federal Aviation Administration (FAA) and the Japa n States Federal Aviation Administration (FAA) and the Japa n
Civil Aviation Bureau. Civil Aviation Bureau.
</dd> </dd>
<dt>CSWaP</dt> <dt>CSWaP</dt>
<dd> <dd>
Cost, Size, Weight, and Power. Cost, Size, Weight, and Power
</dd> </dd>
<dt>C2</dt> <dt>C2</dt>
<dd> <dd>
Command and Control. Previously mostly used in military Command and Control. Previously mostly used in military
contexts. Properly refers to a function, exercisable over contexts. Properly refers to a function that is exercisab
arbitrary communications; but in the small UAS context, le over
arbitrary communications, but in the small UAS context,
often refers to the communications (typically RF data lin k) often refers to the communications (typically RF data lin k)
over which the GCS controls the UA. over which the GCS controls the UA.
</dd> </dd>
<dt>DAA</dt> <dt>DAA</dt>
<dd> <dd>
Detect And Avoid, formerly Sense And Avoid (SAA). A means Detect And Avoid, formerly "Sense And Avoid (SAA)". A
of keeping aircraft "well clear" of each other and means of keeping aircraft "well clear" of each other
obstacles for safety. "The capability to see, sense or and obstacles for safety. <xref target="ICAOUAS"
detect conflicting traffic or other hazards and take the format="default"/> defines DAA as the following: "The
appropriate action to comply with the applicable rules of capability to see, sense or detect conflicting traffic
flight" <xref target="ICAOUAS" format="default"/>. or other hazards and take the appropriate action to
comply with the applicable rules of flight".
</dd> </dd>
<dt>DRI (not to be confused with DRIP)</dt> <dt>DRI (not to be confused with DRIP)</dt>
<dd> <dd>
Direct Remote Identification. EU regulatory requirement f or Direct Remote Identification. EU regulatory requirement f or
"a system that ensures the local broadcast of information "a system that ensures the local broadcast of information
about a UA in operation, including the marking of the UA, about a UA in operation, including the marking of the UA,
so that this information can be obtained without physical so that this information can be obtained without physical
access to the UA". <xref target="Delegated" access to the UA" <xref target="Delegated"
format="default"/> that presumably can be satisfied with format="default"/>. This requirement can presumably be sa
tisfied with
appropriately configured <xref target="F3411-19" appropriately configured <xref target="F3411-19"
format="default"/> Broadcast RID. format="default"/> Broadcast RID.
</dd> </dd>
<dt>DSS</dt> <dt>DSS</dt>
<dd> <dd>
Discovery and Synchronization Service. The UTM system Discovery and Synchronization Service. The UTM system
overlay network backbone. Most importantly, it enables on e overlay network backbone. Most importantly, it enables on e
USS to learn which other USS have UAS operating in a give n USS to learn which other USS have UAS operating in a give n
4-D airspace volume, for strategic deconfliction of plann ed 4-D airspace volume, for strategic deconfliction of plann ed
operations and Network RID surveillance of active operations and Network RID surveillance of active
operations. <xref target="F3411-19" format="default"/> operations. See <xref target="F3411-19" format="default"/ >.
</dd> </dd>
<dt>EUROCAE</dt> <dt>EUROCAE</dt>
<dd> <dd>
European Organisation for Civil Aviation Equipment. European Organisation for Civil Aviation Equipment.
Aviation SDO, originally European, now with broader Aviation SDO, originally European, now with broader
membership. Cooperates extensively with RTCA. membership. Cooperates extensively with RTCA.
</dd> </dd>
<dt>GBDAA</dt> <dt>GBDAA</dt>
<dd> <dd>
Ground Based DAA. Accomplished with the aid of ground bas ed Ground-Based DAA. Accomplished with the aid of ground-bas ed
functions. functions.
</dd> </dd>
<dt>GCS</dt> <dt>GCS</dt>
<dd> <dd>
Ground Control Station. The part of the UAS that the remo Ground Control Station. The part of the UAS that the Remo
te te
pilot uses to exercise C2 over the UA, whether by remotel Pilot uses to exercise C2 over the UA, whether by remotel
y y
exercising UA flight controls to fly the UA, by setting exercising UA flight controls to fly the UA, by setting
GNSS waypoints, or otherwise directing its flight. GNSS waypoints, or by otherwise directing its flight.
</dd> </dd>
<dt>GNSS</dt> <dt>GNSS</dt>
<dd> <dd>
Global Navigation Satellite System. Satellite based timin g Global Navigation Satellite System. Satellite-based timin g
and/or positioning with global coverage, often used to and/or positioning with global coverage, often used to
support navigation. support navigation.
</dd> </dd>
<dt>GPS</dt> <dt>GPS</dt>
<dd> <dd>
Global Positioning System. A specific GNSS, but in the UA S Global Positioning System. A specific GNSS, but in the UA S
context, the term is typically misused in place of the mo re context, the term is typically misused in place of the mo re
generic term GNSS. generic term "GNSS".
</dd> </dd>
<dt>GRAIN</dt> <dt>GRAIN</dt>
<dd> <dd>
Global Resilient Aviation Interoperable Network. ICAO Global Resilient Aviation Interoperable
managed IPv6 overlay internetwork based on IATF, dedicate Network. ICAO-managed IPv6 overlay internetwork based
d on IATF that is dedicated to aviation (but not just
to aviation (but not just aircraft). Currently (2021) in aircraft). As currently (2021) designed, it accommodates
design, accommodating the proposed DRIP identifier. the proposed DRIP identifier.
</dd> </dd>
<dt>IATF</dt> <dt>IATF</dt>
<dd> <dd>
International Aviation Trust Framework. ICAO effort to International Aviation Trust Framework. ICAO effort to
develop a resilient and secure by design framework for develop a resilient and secure by design framework for
networking in support of all aspects of aviation. networking in support of all aspects of aviation.
</dd> </dd>
<dt>ICAO</dt> <dt>ICAO</dt>
<dd> <dd>
International Civil Aviation Organization. A United Natio International Civil Aviation Organization. A
ns specialized agency of the United Nations that develops an
specialized agency that develops and harmonizes d harmonizes
international standards relating to aviation. international standards relating to aviation.
</dd> </dd>
<dt>IFF</dt> <dt>IFF</dt>
<dd> <dd>
Identification Friend or Foe. Originally, and in its narr ow Identification Friend or Foe.&nbsp;Originally, and in its narrow
sense still, a self-identification broadcast in response to sense still, a self-identification broadcast in response to
interrogation via radar, to reduce friendly fire incident s, interrogation via radar to reduce friendly fire incidents ,
which led to military and commercial transponder systems which led to military and commercial transponder systems
such as ADS-B. In the broader sense used here, any proces s such as ADS-B. In the broader sense used here, any proces s
intended to distinguish friendly from potentially hostile intended to distinguish friendly from potentially hostile
UA or other entities encountered. UA or other entities encountered.
</dd> </dd>
<dt>LAANC</dt> <dt>LAANC</dt>
<dd> <dd>
Low Altitude Authorization and Notification Capability. Low Altitude Authorization and Notification Capability.
Supports ATC authorization requirements for UAS operation s: Supports ATC authorization requirements for UAS operation s:
remote pilots can apply to receive a near real-time Remote Pilots can apply to receive a near real-time
authorization for operations under 400 feet in controlled authorization for operations under 400 feet in controlled
airspace near airports. FAA authorized partial stopgap in airspace near airports. FAA- authorized partial stopgap i n
the US until UTM comes. the US until UTM comes.
</dd> </dd>
<dt>Location/Vector Message</dt> <dt>Location/Vector Message</dt>
<dd> <dd>
<xref target="F3411-19" format="default"/> Message Type 1 . <xref target="F3411-19" format="default"/> Message Type 1 .
Provides UA location, altitude, heading, speed, and statu s. Provides UA location, altitude, heading, speed, and statu s.
</dd> </dd>
<dt>LOS</dt> <dt>LOS</dt>
<dd> <dd>
Line Of Sight. An adjectival phrase describing any Line Of Sight. An adjectival phrase describing any
skipping to change at line 847 skipping to change at line 893
</dd> </dd>
<dt>Message Pack</dt> <dt>Message Pack</dt>
<dd> <dd>
<xref target="F3411-19" format="default"/> Message Type 1 5. <xref target="F3411-19" format="default"/> Message Type 1 5.
The framed concatenation, in message type index order, of The framed concatenation, in message type index order, of
at most one message of each type of any subset of the oth er at most one message of each type of any subset of the oth er
types. Required to be sent in Wi-Fi NAN and in Bluetooth 5 types. Required to be sent in Wi-Fi NAN and in Bluetooth 5
Extended Advertisements, if those media are used; cannot be Extended Advertisements, if those media are used; cannot be
sent in Bluetooth 4. sent in Bluetooth 4.
</dd> </dd>
<dt>MSL</dt> <dt>MSL</dt>
<dd> <dd>
Mean Sea Level. Shorthand for relative altitude, above th e Mean Sea Level. Shorthand for relative altitude, above th e
variously defined mean sea level, typically of a UA (but in variously defined mean sea level, typically of a UA (but in
<xref target="FRUR" format="default"/> also for a GCS), <xref target="FRUR" format="default"/>, also for a GCS),
measured in feet or meters. Should be explicitly specifie d measured in feet or meters. Should be explicitly specifie d
as either barometric (pressure) or geodetic (e.g., as as either barometric (pressure) or geodetic (e.g., as
indicated by GNSS, referenced to the WGS84 ellipsoid). indicated by GNSS, referenced to the WGS84 ellipsoid).
</dd> </dd>
<dt>Net-RID DP</dt> <dt>Net-RID DP</dt>
<dd> <dd>
Network RID Display Provider. <xref target="F3411-19" Network RID Display Provider. <xref target="F3411-19"
format="default"/> logical entity that aggregates data fr om format="default"/> logical entity that aggregates data fr om
Net-RID SPs as needed in response to user queries regardi ng Net-RID SPs as needed in response to user queries regardi ng
UAS operating within specified airspace volumes, to enabl e UAS operating within specified airspace volumes to enable
display by a user application on a user device. Potential ly display by a user application on a user device. Potential ly
could provide not only information sent via UAS RID but could provide not only information sent via UAS RID but
also information retrieved from UAS RID registries or also information retrieved from UAS RID registries or
information beyond UAS RID. Under superseded <xref information beyond UAS RID. Under superseded <xref
target="NPRM" format="default"/>, not recognized as a target="NPRM" format="default"/>, not recognized as a
distinct entity, but a service provided by USS, including distinct entity, but as a service provided by USS, includ
Public Safety USS that may exist primarily for this purpo ing
se public safety USS that may exist primarily for this purpo
se
rather than to manage any subscribed UAS. rather than to manage any subscribed UAS.
</dd> </dd>
<dt>Net-RID SP</dt> <dt>Net-RID SP</dt>
<dd> <dd>
Network RID Service Provider. <xref target="F3411-19" Network RID Service Provider. <xref target="F3411-19"
format="default"/> logical entity that collects RID format="default"/> logical entity
messages from UAS and responds to NetRID-DP queries for that collects RID
messages from UAS and responds to Net-RID DP queries for
information on UAS of which it is aware. Under superseded information on UAS of which it is aware. Under superseded
<xref target="NPRM" format="default"/>, the USS to which <xref target="NPRM" format="default"/>, the USS to which
the UAS is subscribed ("Remote ID USS"). the UAS is subscribed (i.e., the "Remote ID USS").
</dd> </dd>
<dt>Network Identification Service</dt> <dt>Network Identification Service</dt>
<dd> <dd>
EU regulatory requirement in <xref target="Opinion1" EU regulatory requirement in <xref target="Opinion1"
format="default"/> and <xref target="WG105" format="default"/>, corresponding to the Electronic Ident
format="default"/> that presumably can be satisfied with ification for which Minimum Operational Performance Standards are specified in <
xref target="WG105"
format="default"/>, which presumably can be satisfied wit
h
appropriately configured <xref target="F3411-19" appropriately configured <xref target="F3411-19"
format="default"/> Network RID. format="default"/> Network RID.
</dd> </dd>
<dt>Observer</dt> <dt>Observer</dt>
<dd> <dd>
An entity (typically but not necessarily an individual An entity (typically, but not necessarily, an individual
human) who has directly or indirectly observed a UA and human) who has directly or indirectly observed a UA and
wishes to know something about it, starting with its ID. An wishes to know something about it, starting with its ID. An
Observer typically is on the ground and local (within VLO S Observer typically is on the ground and local (within VLO S
of an observed UA), but could be remote (observing via of an observed UA), but could be remote (observing via
Network RID or other surveillance), operating another UA, Network RID or other surveillance), operating another UA,
aboard another aircraft, etc. (DRIP) aboard another aircraft, etc. (DRIP)
</dd> </dd>
<dt>Operation</dt> <dt>Operation</dt>
<dd> <dd>
A flight, or series of flights of the same mission, by th e A flight, or series of flights of the same mission, by th e
same UAS, separated by at most brief ground intervals. same UAS, separated by, at most, brief ground intervals.
(Inferred from UTM usage, no formal definition found) (Inferred from UTM usage; no formal definition found.)
</dd> </dd>
<dt>Operator</dt> <dt>Operator</dt>
<dd> <dd>
"A person, organization or enterprise engaged in or "A person, organization or
offering to engage in an aircraft operation" <xref enterprise engaged in or offering to engage in an
target="ICAOUAS" format="default"/>. aircraft operation" <xref target="ICAOUAS"
format="default"/>.
</dd> </dd>
<dt>Operator ID Message</dt> <dt>Operator ID Message</dt>
<dd> <dd>
<xref target="F3411-19" format="default"/> Message Type 5 . <xref target="F3411-19" format="default"/> Message Type 5 .
Provides CAA issued Operator ID, only. Operator ID is Provides CAA-issued Operator ID only. Operator ID is
distinct from UAS ID. distinct from UAS ID.
</dd> </dd>
<dt>page</dt> <dt>page</dt>
<dd> <dd>
Payload of a frame, containing a chunk of a message that Payload of a frame, containing a chunk of a message that
has been segmented, to allow transport of a message longe has been segmented, that allows transport of a message lo
r nger
than can be encapsulated in a single frame. <xref than can be encapsulated in a single frame. See <xref
target="F3411-19" format="default"/> target="F3411-19" format="default"/>.
</dd> </dd>
<dt>PIC</dt> <dt>PIC</dt>
<dd> <dd>
Pilot In Command. "The pilot designated by the operator, Pilot In Command. "The pilot designated by the
or operator, or in the case of general aviation, the
in the case of general aviation, the owner, as being in owner, as being in command and charged with the safe
command and charged with the safe conduct of a flight" conduct of a flight" <xref target="ICAOUAS"
<xref target="ICAOUAS" format="default"/>. format="default"/>.
</dd> </dd>
<dt>PII</dt> <dt>PII</dt>
<dd> <dd>
Personally Identifiable Information. In the UAS RID Personally Identifiable Information. In the UAS RID
context, typically of the UAS Operator, Pilot In Command context, typically of the UAS Operator,
(PIC), or Remote Pilot, but possibly of an Observer or PIC, or Remote Pilot, but possibly of an Observer or
other party. This specific term is used primarily in the other party. This specific term is used primarily in the
US; other terms with essentially the same meaning are mor e US; other terms with essentially the same meaning are mor e
common in other jurisdictions (e.g., "personal data" in t he common in other jurisdictions (e.g., "personal data" in t he
EU). Used herein generically to refer to personal EU). Used herein generically to refer to personal
information, which the person might wish to keep private, information that the person might wish to keep private
or may have a statutorily recognized right to keep privat e or may have a statutorily recognized right to keep privat e
(e.g., under the EU <xref target="GDPR" (e.g., under the EU <xref target="GDPR"
format="default"/>), potentially imposing (legally or format="default"/>), potentially imposing (legally or
ethically) a confidentiality requirement on ethically) a confidentiality requirement on
protocols/systems. protocols/systems.
</dd> </dd>
<dt>Remote Pilot</dt> <dt>Remote Pilot</dt>
<dd> <dd>
A pilot using a GCS to exercise proximate control of a UA . A pilot using a GCS to exercise proximate control of a UA .
Either the PIC or under the supervision of the PIC. "The Either the PIC or under the supervision of the PIC. "The
skipping to change at line 954 skipping to change at line 1009
protocols/systems. protocols/systems.
</dd> </dd>
<dt>Remote Pilot</dt> <dt>Remote Pilot</dt>
<dd> <dd>
A pilot using a GCS to exercise proximate control of a UA . A pilot using a GCS to exercise proximate control of a UA .
Either the PIC or under the supervision of the PIC. "The Either the PIC or under the supervision of the PIC. "The
person who manipulates the flight controls of a person who manipulates the flight controls of a
remotely-piloted aircraft during flight time" <xref remotely-piloted aircraft during flight time" <xref
target="ICAOUAS" format="default"/>. target="ICAOUAS" format="default"/>.
</dd> </dd>
<dt>RF</dt> <dt>RF</dt>
<dd> <dd>
Radio Frequency. Adjective, e.g., "RF link", or noun. Radio Frequency. Can be used as an adjective (e.g., "RF l ink") or as a noun.
</dd> </dd>
<dt>RF LOS</dt> <dt>RF LOS</dt>
<dd> <dd>
RF Line Of Sight. Typically used in describing a direct RF Line Of Sight. Typically used in describing a direct
radio link between a GCS and the UA under its control, radio link between a GCS and the UA under its control,
potentially subject to blockage by foliage, structures, potentially subject to blockage by foliage, structures,
terrain, or other vehicles, but less so than VLOS. terrain, or other vehicles, but less so than VLOS.
</dd> </dd>
<dt>RTCA</dt> <dt>RTCA</dt>
<dd> <dd>
Radio Technical Commission for Aeronautics. US aviation Radio Technical Commission for Aeronautics. US aviation
SDO. Cooperates extensively with EUROCAE. SDO. Cooperates extensively with EUROCAE.
</dd> </dd>
<dt>Safety</dt> <dt>Safety</dt>
<dd> <dd>
"The state in which risks associated with aviation "The state in which risks associated with aviation
activities, related to, or in direct support of the activities, related to, or in direct support of the
operation of aircraft, are reduced and controlled to an operation of aircraft, are reduced and controlled to an
acceptable level." From Annex 19 of the Chicago Conventio acceptable level" (from Annex 19 of the Chicago Conventio
n, n,
quoted in <xref target="ICAODEFS" format="default"/> quoted in <xref target="ICAODEFS" format="default"/>).
</dd> </dd>
<dt>Security</dt> <dt>Security</dt>
<dd> <dd>
"Safeguarding civil aviation against acts of unlawful "Safeguarding civil aviation against acts of unlawful
interference." From Annex 17 of the Chicago Convention, interference" (from Annex 17 of the Chicago Convention,
quoted in <xref target="ICAODEFS" format="default"/> quoted in <xref target="ICAODEFS" format="default"/>).
</dd> </dd>
<dt>Self-ID Message</dt> <dt>Self-ID Message</dt>
<dd> <dd>
<xref target="F3411-19" format="default"/> Message Type 3 . <xref target="F3411-19" format="default"/> Message Type 3 .
Provides a 1 byte descriptor and 23 byte ASCII free text Provides a 1-byte descriptor and 23-byte ASCII free text
field, only. Expected to be used to provide context on th e field, only. Expected to be used to provide context on th e
operation, e.g., mission intent. operation, e.g., mission intent.
</dd> </dd>
<dt>SDO</dt> <dt>SDO</dt>
<dd> <dd>
Standards Development Organization. ASTM, IETF, et al. Standards Development Organization, such as ASTM, IETF, e tc.
</dd> </dd>
<dt>SDSP</dt> <dt>SDSP</dt>
<dd> <dd>
Supplemental Data Service Provider. An entity that Supplemental Data Service Provider. An entity that
participates in the UTM system, but provides services participates in the UTM system but provides services (e.g
beyond those specified as basic UTM system functions (e.g .,
., weather data) beyond those specified as basic UTM system
weather data). <xref target="FAACONOPS" format="default"/ functions. See <xref target="FAACONOPS" format="default"/
> >.
</dd> </dd>
<dt>System Message</dt> <dt>System Message</dt>
<dd> <dd>
<xref target="F3411-19" format="default"/> Message Type 4 . <xref target="F3411-19" format="default"/> Message Type 4 .
Provides general UAS information, including remote pilot Provides general UAS information, including Remote Pilot
location, multiple UA group operational area, etc. location, multiple UA group operational area, etc.
</dd> </dd>
<dt>U-space</dt> <dt>U-space</dt>
<dd> <dd>
EU concept and emerging framework for integration of UAS EU concept and emerging framework for integration of
into all classes of airspace, specifically including high UAS into all types of airspace, including but not
density urban areas, sharing airspace with manned aircraf limited to volumes that are in high-density urban
t areas and/or shared with manned aircraft <xref
<xref target="InitialView" format="default"/>. target="InitialView" format="default"/>.
</dd> </dd>
<dt>UA</dt> <dt>UA</dt>
<dd> <dd>
Unmanned Aircraft. In popular parlance, "drone". "An Unmanned Aircraft. In popular parlance, "drone". "An
aircraft which is intended to operate with no pilot on aircraft which is intended to operate with no pilot on
board" <xref target="ICAOUAS" format="default"/>. board" <xref target="ICAOUAS" format="default"/>.
</dd> </dd>
<dt>UAS</dt> <dt>UAS</dt>
<dd> <dd>
Unmanned Aircraft System. Composed of UA, all required Unmanned Aircraft System. Composed of UA, all required
skipping to change at line 1038 skipping to change at line 1096
format="default"/>. format="default"/>.
</dd> </dd>
<dt>UAS ID</dt> <dt>UAS ID</dt>
<dd> <dd>
UAS identifier. Although called "UAS ID", it is actually UAS identifier. Although called "UAS ID", it is actually
unique to the UA, neither to the operator (as some UAS unique to the UA, neither to the operator (as some UAS
registration numbers have been and for exclusively registration numbers have been and for exclusively
recreational purposes are continuing to be assigned), nor recreational purposes are continuing to be assigned), nor
to the combination of GCS and UA that comprise the UAS. to the combination of GCS and UA that comprise the UAS.
<em>Maximum length of 20 bytes</em> <xref target="F3411-1 9" <em>Maximum length of 20 bytes</em> <xref target="F3411-1 9"
format="default"/>. If the UAS ID Type is 4, the proposed format="default"/>. If the ID Type is 4, the proposed
Specific Session ID, then the 20 bytes includes the subty pe Specific Session ID, then the 20 bytes includes the subty pe
index, leaving only 19 bytes for the actual identifier. index, leaving only 19 bytes for the actual identifier.
</dd> </dd>
<dt>UAS ID Type</dt>
<dt>ID Type</dt>
<dd> <dd>
UAS Identifier type index. 4 bits, see <xref UAS identifier type index. 4 bits. See <xref
target="IDtypes" format="default"></xref> for currently target="IDtypes" format="default"></xref> for current
defined values 0-3. <xref target="F3411-19" standard values 0-3 and currently proposed additional
format="default"/> value 4. See also <xref target="F3411-19"
format="default"/>.
</dd> </dd>
<dt>UAS RID</dt> <dt>UAS RID</dt>
<dd> <dd>
UAS Remote Identification and tracking. System to enable UAS Remote Identification and tracking. System to enable
arbitrary Observers to identify UA during flight. arbitrary Observers to identify UA during flight.
</dd> </dd>
<dt>USS</dt> <dt>USS</dt>
<dd> <dd>
UAS Service Supplier. "A USS is an entity that assist s UAS Service Supplier. "A USS is an entity that assist s
UAS Operators with meeting UTM operational requirement s UAS Operators with meeting UTM operational requirement s
that enable safe and efficient use of airspace" and that enable safe and efficient use of airspace" <xref
"... provide services to support the UAS community, t target="FAACONOPS" format="default"/>. In addition,
o "USSs provide services to support the UAS community, to
connect Operators and other entities to enable informatio n connect Operators and other entities to enable informatio n
flow across the USS Network, and to promote shared flow across the USS Network, and to promote shared
situational awareness among UTM participants" <xref situational awareness among UTM participants" <xref
target="FAACONOPS" format="default"/>. target="FAACONOPS" format="default"/>.
</dd> </dd>
<dt>UTM</dt> <dt>UTM</dt>
<dd> <dd>
UAS Traffic Management. "A specific aspect of air traffic UAS Traffic Management. "A specific aspect of air traffic
management which manages UAS operations safely, management which manages UAS operations safely,
economically and efficiently through the provision of economically and efficiently through the provision of
facilities and a seamless set of services in collaboratio n facilities and a seamless set of services in collaboratio n
with all parties and involving airborne and ground-based with all parties and involving airborne and ground-based
functions" <xref target="ICAOUTM" format="default"/>. In functions" <xref target="ICAOUTM" format="default"/>. In
the US, according to the FAA, a "traffic management" the US, according to the FAA, a "traffic management"
ecosystem for "uncontrolled" low altitude UAS operations, ecosystem for "uncontrolled" UAS operations at low altitu des,
separate from, but complementary to, the FAA's ATC system separate from, but complementary to, the FAA's ATC system
for "controlled" operations of manned aircraft. for "controlled" operations of manned aircraft.
</dd> </dd>
<dt>V2V</dt> <dt>V2V</dt>
<dd> <dd>
Vehicle-to-Vehicle. Originally communications between Vehicle-to-Vehicle. Originally communications between
automobiles, now extended to apply to communications automobiles, now extended to apply to communications
between vehicles generally. Often, together with between vehicles generally. Often, together with
Vehicle-to-Infrastructure (V2I) etc., generalized to V2X. Vehicle-to-Infrastructure (V2I) and similar functions, ge neralized to V2X.
</dd> </dd>
<dt>VLOS</dt> <dt>VLOS</dt>
<dd> <dd>
Visual Line Of Sight. Typically used in describing Visual Line Of Sight. Typically used in describing
operation of a UA by a "remote" pilot who can clearly operation of a UA by a "remote" pilot who can clearly and
directly (without video cameras or any aids other than directly (without video cameras or any aids other than
glasses or under some rules binoculars) see the UA and it s glasses or, under some rules, binoculars) see the UA and its
immediate flight environment. Potentially subject to immediate flight environment. Potentially subject to
blockage by foliage, structures, terrain, or other blockage by foliage, structures, terrain, or other
vehicles, more so than RF LOS. vehicles, more so than RF LOS.
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <name>UAS RID Problem Space</name> <section numbered="true" toc="default"> <name>UAS RID Problem Space</name>
<t> <t>
CAAs worldwide are mandating UAS RID. The European Union Aviation CAAs worldwide are mandating UAS RID. The European Union Aviation
Safety Agency (EASA) has published <xref target="Delegated" Safety Agency (EASA) has published <xref target="Delegated"
format="default"/> and <xref target="Implementing" format="default"/> and <xref target="Implementing"
format="default"/> Regulations. The US FAA has published a "final" format="default"/> regulations. The US FAA has published a "final"
rule <xref target="FRUR" format="default"/> and has described the rule <xref target="FRUR" format="default"/> and has described the
key role that UAS RID plays in UAS Traffic Management (UTM) in key role that UAS RID plays in UAS Traffic Management
(UTM) in
<xref target="FAACONOPS" format="default"/> (especially Section <xref target="FAACONOPS" format="default"/> (especially Section
2.6). CAAs currently (2021) promulgate performance-based 2.6). At the time of writing, CAAs promulgate performance-based
regulations that do not specify techniques, but rather cite regulations that do not specify techniques but rather cite
industry consensus technical standards as acceptable means of industry consensus technical standards as acceptable means of
compliance. compliance.
</t> </t>
<t> <t>
The most widely cited such industry consensus technical standard The most widely cited such industry consensus technical standard
for UAS RID is <xref target="F3411-19" format="default"/>, which for UAS RID is <xref target="F3411-19" format="default"/>, which
defines two means of UAS RID: defines two means of UAS RID:
</t> </t>
<ul spacing="normal" empty="true">
<ul spacing="normal">
<li> <li>
Network RID defines a set of information for UAS to make Network RID defines a set of information for UAS to make
available globally indirectly via the Internet, through servers available globally indirectly via the Internet, through servers
that can be queried by Observers. that can be queried by Observers.
</li> </li>
<li> <li>
Broadcast RID defines a set of messages for UA to transmit Broadcast RID defines a set of messages for UA to transmit
locally directly one-way over Bluetooth or Wi-Fi (without IP or locally directly one-way over Bluetooth or Wi-Fi (without IP or
any other protocols between the data link and application any other protocols between the data link and application
layers), to be received in real time by local Observers. layers), to be received in real time by local Observers.
skipping to change at line 1130 skipping to change at line 1195
available globally indirectly via the Internet, through servers available globally indirectly via the Internet, through servers
that can be queried by Observers. that can be queried by Observers.
</li> </li>
<li> <li>
Broadcast RID defines a set of messages for UA to transmit Broadcast RID defines a set of messages for UA to transmit
locally directly one-way over Bluetooth or Wi-Fi (without IP or locally directly one-way over Bluetooth or Wi-Fi (without IP or
any other protocols between the data link and application any other protocols between the data link and application
layers), to be received in real time by local Observers. layers), to be received in real time by local Observers.
</li> </li>
</ul> </ul>
<t> <t>
UAS using both means must send the same UAS RID application layer UAS using both means must send the same UAS RID application-layer
information via each <xref target="F3411-19" format="default"/>. information via each <xref target="F3411-19" format="default"/>.
The presentation may differ, as Network RID defines a data The presentation may differ, as Network RID defines a data
dictionary, whereas Broadcast RID defines message formats (which dictionary, whereas Broadcast RID defines message formats (which
carry items from that same data dictionary). The interval (or rate) carry items from that same data dictionary). The interval (or rate)
at which it is sent may differ, as Network RID can accommodate at which it is sent may differ, as Network RID can accommodate
Observer queries asynchronous to UAS updates (which generally need Observer queries asynchronous to UAS updates (which generally need
be sent only when information, such as location, changes), whereas be sent only when information, such as location, changes), whereas
Broadcast RID depends upon Observers receiving UA messages at the Broadcast RID depends upon Observers receiving UA messages at the
time they are transmitted. time they are transmitted.
</t> </t>
skipping to change at line 1142 skipping to change at line 1208
information via each <xref target="F3411-19" format="default"/>. information via each <xref target="F3411-19" format="default"/>.
The presentation may differ, as Network RID defines a data The presentation may differ, as Network RID defines a data
dictionary, whereas Broadcast RID defines message formats (which dictionary, whereas Broadcast RID defines message formats (which
carry items from that same data dictionary). The interval (or rate) carry items from that same data dictionary). The interval (or rate)
at which it is sent may differ, as Network RID can accommodate at which it is sent may differ, as Network RID can accommodate
Observer queries asynchronous to UAS updates (which generally need Observer queries asynchronous to UAS updates (which generally need
be sent only when information, such as location, changes), whereas be sent only when information, such as location, changes), whereas
Broadcast RID depends upon Observers receiving UA messages at the Broadcast RID depends upon Observers receiving UA messages at the
time they are transmitted. time they are transmitted.
</t> </t>
<t> <t>
Network RID depends upon Internet connectivity in several segments Network RID depends upon Internet connectivity in several segments
from the UAS to each Observer. Broadcast RID should need Internet from the UAS to each Observer.
(or other Wide Area Network) connectivity only to retrieve UAS Broadcast RID should need Internet
registry information using the directly locally received UAS (or other Wide Area Network) connectivity only to retrieve registry
Identifier (UAS ID) as the primary unique key for database lookup. information, using, as the primary unique key for database lookup,
the UAS
Identifier (UAS ID) that was directly locally received.
Broadcast RID does not assume IP connectivity of UAS; messages are Broadcast RID does not assume IP connectivity of UAS; messages are
encapsulated by the UA <em>without IP</em>, directly in link layer encapsulated by the UA <em>without IP</em>, directly in link-layer
frames (Bluetooth 4, Bluetooth 5, Wi-Fi NAN, IEEE 802.11 Beacon, or frames (Bluetooth 4, Bluetooth 5, Wi-Fi NAN, IEEE 802.11 Beacon, or
in the future perhaps others). perhaps others in the future).
</t> </t>
<t anchor="IDtypes"> <t anchor="IDtypes">
<xref target="F3411-19" format="default"/> specifies three UAS ID <xref target="F3411-19" format="default"/> specifies three ID
Type values and its currently (August 2021) proposed revision adds Type values, and its proposed revision (at the time of writing) adds
a fourth: a fourth:
</t> </t>
<ol spacing="normal" type="%d" group="type"> <ol spacing="normal" type="%d" group="type">
<li> <li>
A static, manufacturer assigned, hardware serial number as A static, manufacturer-assigned, hardware serial number as
defined in ANSI/CTA-2063-A "Small Unmanned Aerial System Serial defined in "Small Unmanned Aerial Systems Serial
Numbers" <xref target="CTA2063A" format="default"/>. Numbers" <xref target="CTA2063A" format="default"/>.
</li> </li>
<li> <li>
A CAA assigned (generally static) ID, like the registration A CAA-assigned (generally static) ID, like the registration
number of a manned aircraft. number of a manned aircraft.
</li> </li>
<li> <li>
A UTM system assigned UUID <xref target="RFC4122" A UTM-system-assigned Universally Unique Identifier (UUID) <xref target="RFC4122"
format="default"/>, which can but need not be dynamic. format="default"/>, which can but need not be dynamic.
</li> </li>
<li> <li>
A Specific Session ID, of any of an 8 bit range of subtypes A Specific Session ID, of any of an 8-bit range of subtypes
defined external to ASTM and registered with ICAO, for which defined external to ASTM and registered with ICAO, for which
subtype 1 has been reserved by ASTM for the DRIP entity ID. subtype 1 has been reserved by ASTM for the DRIP entity ID.
</li> </li>
</ol> </ol>
<t> <t>
Per <xref target="Delegated" format="default"/>, the EU allows only Per <xref target="Delegated" format="default"/>, the EU allows only
UAS ID Type 1. Under <xref target="FRUR" format="default"/>, the US ID Type 1. Under <xref target="FRUR" format="default"/>, the US
allows types 1 and 3. <xref target="NPRM" format="default"/> allows ID Type 1 and ID Type 3. <xref target="NPRM" format="default"/>
proposed that a type 3 "Session ID" would be "e.g., a proposed that a "Session ID" would be "e.g., a
randomly-generated alphanumeric code assigned by a Remote ID UAS randomly-generated alphanumeric code assigned by a Remote ID UAS
Service Supplier (USS) on a per-flight basis designed to provide Service Supplier (USS) on a per-flight basis designed to provide
additional privacy to the operator", but given the omission of additional privacy to the operator", but given the omission of
Network RID from <xref target="FRUR" format="default"/>, how this Network RID from <xref target="FRUR" format="default"/>, how this
is to be assigned in the US is still to be determined. is to be assigned in the US is still to be determined.
</t> </t>
<t> <t>
As yet apparently there are no CAA public proposals to use UAS ID As yet, there are apparently no CAA public proposals to use ID
Type 2. In the preamble of <xref target="FRUR" format="default"/>, Type 2. In the preamble of <xref target="FRUR" format="default"/>,
the FAA argues that registration numbers should not be sent in RID, the FAA argues that registration numbers should not be sent in RID,
insists that the capability of looking up registration numbers from insists that the capability of looking up registration numbers from
information contained in RID should be restricted to FAA and other information contained in RID should be restricted to FAA and other
Government agencies, and implies that Session ID would be linked to Government agencies, and implies that Session ID would be linked to
the registration number only indirectly via the serial number in the registration number only indirectly via the serial number in
the registration database. The possibility of cryptographically the registration database. The possibility of cryptographically
blinding registration numbers, such that they can be revealed under blinding registration numbers, such that they can be revealed under
specified circumstances, does not appear to be mentioned in specified circumstances, does not appear to be mentioned in
applicable regulations or external technical standards. applicable regulations or external technical standards.
</t> </t>
<t> <t>
Under <xref target="Delegated" format="default"/>, the EU also Per <xref target="Delegated" format="default"/>, the EU also
requires an operator registration number (an additional identifier requires an operator registration number (an additional identifier
distinct from the UAS ID) that can be carried in an <xref distinct from the UAS ID) that can be carried in an <xref
target="F3411-19" format="default"/> optional Operator ID message. target="F3411-19" format="default"/> optional Operator ID Message.
</t> </t>
<t> <t>
<xref target="FRUR" format="default"/> allows RID requirements to <xref target="FRUR" format="default"/> allows RID requirements to
be met by either the UA itself, which is then designated a be met either by the UA itself, which is then designated a
"standard remote identification unmanned aircraft", or by an add-on "standard remote identification unmanned aircraft", or by an add-on
"remote identification broadcast module". Relative to a standard "remote identification broadcast module".
RID UA, the different requirements for a module are that the
latter: must transmit its own serial number (neither the serial The requirements for a module are different than for a standard RID UA. The
number of the UA to which it is attached, nor a Session ID); must module:
transmit takeoff location as a proxy for the location of the
pilot/GCS; need not transmit UA emergency status; and is allowed to
be used only for operations within VLOS of the remote pilot.
</t> </t>
<ul>
<li>must transmit its own serial number (neither the serial number of the UA
to which it is attached, nor a Session ID),</li>
<li>must transmit takeoff location as a proxy for the location of the
pilot/GCS,</li>
<li>need not transmit UA emergency status, and</li>
<li>is allowed to be used only for operations within VLOS of the Remote
Pilot.</li>
</ul>
<t> <t>
Jurisdictions may relax or waive RID requirements for certain Jurisdictions may relax or waive RID requirements for certain
operators and/or under certain conditions. For example, <xref operators and/or under certain conditions. For example, <xref
target="FRUR" format="default"/> allows operators with UAS not target="FRUR" format="default"/> allows operators with UAS not
equipped for RID to conduct VLOS operations at counter-intuitively equipped for RID to conduct VLOS operations at counterintuitively
named "FAA-recognized identification areas" (FRIA); radio named "FAA-Recognized Identification Areas (FRIAs)"; radio-controlled mod
controlled model aircraft flying clubs and other eligible el aircraft flying clubs and other eligible
organizations can apply to the FAA for such recognition of their organizations can apply to the FAA for such recognition of their
operating areas. operating areas.
</t> </t>
<section numbered="true" toc="default"> <name>Network RID</name> <section numbered="true" toc="default"> <name>Network RID</name>
<t>
<xref target="NetRID" format="default"/> illustrates Network RID
information flows. Only two of the three typically wireless links
shown involving the UAS (UA-GCS, UA-Internet, and GCS-Internet)
need exist to support C2 and Network RID. All three may exist, at
the same or different times, especially in BVLOS operations. There
must be at least one information flow path (direct or indirect) between t
he
GCS and the UA, for the former to exercise C2 over the latter. If
this path is two-way (as increasingly it is, even for inexpensive small
UAS), the UA will also send its status (and position, if
suitably equipped, e.g., with GNSS) to the GCS. There also must be
a path between at least one subsystem of the UAS (UA or GCS) and
the Internet, for the former to send status and position updates to
its USS (serving inter alia as a Net-RID SP).
</t>
<figure anchor="NetRID"> <figure anchor="NetRID">
<name>"Network RID Information Flow"</name> <name>Network RID Information Flow</name>
<artwork type="ascii-art"> <artwork type="ascii-art">
+-------------+ ****************** +-------------+ ******************
| UA | * Internet * | UA | * Internet *
+--o-------o--+ * * +--o-------o--+ * *
| | * * | | * *
| | * * +------------+ | | * * +------------+
| '--------*--(+)-----------*-----o | | '--------*--(+)-----------*-----o |
| * | * | | | * | * | |
| .--------*--(+)-----------*-----o NET-Rid SP | | .--------*--(+)-----------*-----o Net-RID SP |
| | * * | | | | * * | |
| | * .------*-----o | | | * .------*-----o |
| | * | * +------------+ | | * | * +------------+
| | * | * | | * | *
| | * | * +------------+ | | * | * +------------+
| | * '------*-----o | | | * '------*-----o |
| | * * | NET-Rid DP | | | * * | Net-RID DP |
| | * .------*-----o | | | * .------*-----o |
| | * | * +------------+ | | * | * +------------+
| | * | * | | * | *
| | * | * +------------+ | | * | * +------------+
+--o-------o--+ * '------*-----o Observer's | +--o-------o--+ * '------*-----o Observer's |
| GCS | * * | Device | | GCS | * * | Device |
+-------------+ ****************** +------------+ +-------------+ ****************** +------------+
</artwork> </artwork>
</figure> </figure>
<t>
<xref target="NetRID" format="default"/> illustrates Network RID
information flows. Only two of the three typically wireless links
shown involving the UAS (UA-GCS, UA-Internet, and GCS-Internet)
need exist to support C2 and Network RID. All three may exist, at
the same or different times, especially in BVLOS operations. There
must be some information flow path (direct or indirect) between the
GCS and the UA, for the former to exercise C2 over the latter. If
this path is two-way (as increasingly it is, even for inexpensive
small UAS), the UA will also send its status (and position, if
suitably equipped, e.g., with GNSS) to the GCS. There also must be
some path between at least one subsystem of the UAS (UA or GCS) and
the Internet, for the former to send status and position updates to
its USS (serving <em>inter alia</em> as a Net-RID SP).
</t>
<t> <t>
Direct UA-Internet wireless links are expected to become more Direct UA-Internet wireless links are expected to become more
common, especially on larger UAS, but currently (2021) are rare. common, especially on larger UAS, but, at the time of writing, they are r are.
Instead, the RID data flow typically originates on the UA and Instead, the RID data flow typically originates on the UA and
passes through the GCS, or originates on the GCS. Network RID data passes through the GCS, or it originates on the GCS. Network RID data
makes three trips through the Internet (GCS-SP, SP-DP, DP-Observer, makes three trips through the Internet (GCS-SP, SP-DP, DP-Observer,
unless any of them are colocated), implying use of IP (and other unless any of them are colocated), implying use of IP (and other
middle layer protocols, e.g., TLS/TCP or DTLS/UDP) on those trips. middle-layer protocols, e.g., TLS/TCP or DTLS/UDP) on those trips.
IP is not necessarily used or supported on the UA-GCS link (if IP is not necessarily used or supported on the UA-GCS link (if
indeed that direct link exists, as it typically does now, but in indeed that direct link exists, as it typically does now, but in
BVLOS operations often will not). BVLOS operations often will not).
</t> </t>
<t> <t>
Network RID is publish-subscribe-query. In the UTM context: Network RID is publish-subscribe-query. In the UTM context:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li> <li>
The UAS operator pushes an "operational intent" (the current The UAS operator pushes an "operational intent" (the current
term in UTM corresponding to a flight plan in manned aviation) term in UTM corresponding to a flight plan in manned aviation)
to the USS (call it USS#1) that will serve that UAS (call it to the USS (call it USS#1) that will serve that UAS (call it
UAS#1) for that operation, primarily to enable deconfliction UAS#1) for that operation, primarily to enable deconfliction
with other operations potentially impinging upon that with other operations potentially impinging upon that
operation's 4-D airspace volume (call it Volume#1). operation's 4-D airspace volume (call it Volume#1).
</li> </li>
<li> <li>
Assuming the operation is approved and commences, UAS#1 Assuming the operation is approved and commences, UAS#1
periodically pushes location/status updates to USS#1, which periodically pushes location/status updates to USS#1, which
serves <em>inter alia</em> as the Network RID Service Provider serves inter alia as the Network RID Service Provider
(Net-RID SP) for that operation. (Net-RID SP) for that operation.
</li> </li>
<li> <li>
When users of any other USS (whether they be other UAS When users of any other USS (whether they be other UAS
operators or Observers) develop an interest in any 4-D airspace operators or Observers) develop an interest in any 4-D airspace
volume (e.g., because they wish to submit an operational intent volume (e.g., because they wish to submit an operational intent
or because they have observed a UA), they query their own USS or because they have observed a UA), they query their own USS
on the volumes in which they are interested. on the volumes in which they are interested.
</li> </li>
<li> <li>
Their USS query, via the UTM Discovery and Synchronization Their USS query, via the UTM
Service (DSS), all other USS in the UTM system, and learn of Discovery and Synchronization
Service (DSS), all other USS in the UTM system and learn of
any USS that have operations in those volumes (including any any USS that have operations in those volumes (including any
volumes intersecting them); thus those USS whose query volumes volumes intersecting them); thus, those USS whose query volumes
intersect Volume#1 (call them USS#2 through USS#n) learn that intersect Volume#1 (call them USS#2 through USS#n) learn that
USS#1 has such operations. USS#1 has such operations.
</li> </li>
<li> <li>
Interested parties can then subscribe to track updates on that Interested parties can then subscribe to track updates on that
operation of UAS#1, via their own USS, which serve as Network operation of UAS#1, via their own USS, which serve as
RID Display Providers (Net-RID DP) for that operation. Network RID
Display Providers (Net-RID DPs) for that operation.
</li> </li>
<li> <li>
USS#1 (as Net-RID SP) will then publish updates of UAS#1 status USS#1 (as Net-RID SP) will then publish updates of UAS#1 status
and position to all other subscribed USS in USS#2 through USS#n and position to all other subscribed USS in USS#2 through USS#n
(as Net-RID DP). (as Net-RID DP).
</li> </li>
<li> <li>
All Net-RID DP subscribed to that operation of UAS#1 will All Net-RID DP subscribed to that operation of UAS#1 will
deliver its track information to their users who subscribed to deliver its track information to their users who subscribed to
that operation of UAS#1 (via means unspecified by <xref that operation of UAS#1 (via means unspecified by <xref
target="F3411-19" format="default"/> etc., but generally target="F3411-19" format="default"/>, etc., but generally
presumed to be web browser based). presumed to be web browser based).
</li> </li>
</ol> </ol>
<t> <t>
Network RID has several connectivity scenarios: Network RID has several connectivity scenarios:
</t> </t>
<ul spacing="normal" empty="true"> <ul spacing="normal">
<li>
<em>Persistently Internet connected UA</em> can consistently <li>
<em>Persistently Internet-connected UA</em> can consistently
directly source RID information; this requires wireless directly source RID information; this requires wireless
coverage throughout the intended operational airspace volume, coverage throughout the intended operational airspace volume,
plus a buffer (e.g., winds may drive the UA out of the volume). plus a buffer (e.g., winds may drive the UA out of the volume).
</li> </li>
<li> <li>
<em>Intermittently Internet connected UA</em>, can usually <em>Intermittently Internet-connected UA</em>, can usually
directly source RID information, but when offline (e.g., due to directly source RID information, but when offline (e.g., due to
signal blockage by a large structure being inspected using the signal blockage by a large structure being inspected using the
UAS), need the GCS to proxy source RID information. UAS), need the GCS to proxy source RID information.
</li> </li>
<li> <li>
<em>Indirectly connected UA</em> lack the ability to send IP <em>Indirectly connected UA</em> lack the ability to send IP
packets that will be forwarded into and across the Internet, packets that will be forwarded into and across the Internet
but instead have some other form of communications to another but instead have some other form of communications to another
node that can relay or proxy RID information to the Internet; node that can relay or proxy RID information to the Internet;
typically this node would be the GCS (which to perform its typically, this node would be the GCS (which to perform its
function must know where the UA is, although C2 link outages do function must know where the UA is, although C2 link outages do
occur). occur).
</li> </li>
<li> <li>
<em>Non-connected UA</em> have no means of sourcing RID <em>Non-connected UA</em> have no means of sourcing RID
information, in which case the GCS or some other interface information, in which case the GCS or some other interface
available to the operator must source it. In the extreme case, available to the operator must source it. In the extreme case,
this could be the pilot or other agent of the operator using a this could be the pilot or other agent of the operator using a
web browser/application to designate, to a USS or other UTM web browser or application to designate, to a USS or other UTM
entity, a time-bounded airspace volume in which an operation entity, a time-bounded airspace volume in which an operation
will be conducted. This is referred to as a "non-equipped will be conducted. This is referred to as a "non-equipped
network participant" engaging in "area operations". This may network participant" engaging in "area operations". This may
impede disambiguation of ID if multiple UAS operate in the same impede disambiguation of ID if multiple UAS operate in the same
or overlapping 4-D volumes. In most airspace volumes, most or overlapping 4-D volumes. In most airspace volumes, most
classes of UA will not be permitted to fly if non-connected. classes of UA will not be permitted to fly if non-connected.
</li> </li>
</ul> </ul>
<t> <t>
In most cases in the near term (2021), the Network RID first hop In most cases in the near term (2021), the Network RID first-hop
data link is likely to be cellular, which can also support BVLOS C2 data link is likely to be either cellular (which can also support BVLOS C
over existing large coverage areas, or Wi-Fi, which can also 2
support Broadcast RID. However, provided the data link can support over existing large coverage areas) or Wi-Fi (which can also
support Broadcast RID). However, provided the data link can support
at least UDP/IP and ideally also TCP/IP, its type is generally at least UDP/IP and ideally also TCP/IP, its type is generally
immaterial to higher layer protocols. The UAS, as the ultimate immaterial to higher-layer protocols. The UAS, as the ultimate
source of Network RID information, feeds a Net-RID SP (typically source of Network RID information, feeds a Net-RID SP (typically
the USS to which the UAS operator subscribes), which proxies for the USS to which the UAS operator subscribes), which proxies for
the UAS and other data sources. An Observer or other ultimate the UAS and other data sources. An Observer or other ultimate
consumer of Network RID information obtains it from a Net-RID DP consumer of Network RID information obtains it from a Net-RID DP
(also typically a USS), which aggregates information from multiple (also typically a USS), which aggregates information from multiple
Net-RID SPs to offer airspace Situational Awareness (SA) coverage Net-RID SPs to offer airspace Situational Awareness (SA) coverage
of a volume of interest. Network RID Service and Display providers of a volume of interest. Network RID Service and Display Providers
are expected to be implemented as servers in well-connected are expected to be implemented as servers in well-connected
infrastructure, communicating with each other via the Internet, and infrastructure, communicating with each other via the Internet and
accessible by Observers via means such as web Application accessible by Observers via means such as web Application
Programming Interfaces (APIs) and browsers. Programming Interfaces (APIs) and browsers.
</t> </t>
<t> <t>
Network RID is the less constrained of the defined UAS RID means. Network RID is the less constrained of the defined means of UAS RID.
<xref target="F3411-19" format="default"/> specifies only Net-RID <xref target="F3411-19" format="default"/> only specifies information exc
SP to Net-RID DP information exchanges. It is presumed that IETF hanges from Net-RID
SP to Net-RID DP. It is presumed that IETF
efforts supporting the more constrained Broadcast RID (see next efforts supporting the more constrained Broadcast RID (see next
section) can be generalized for Network RID and potentially also section) can be generalized for Network RID and potentially also
for UAS to USS or other UTM communications. for UAS-to-USS or other UTM communications.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <name>Broadcast RID</name> <section anchor="broadcast-rid" numbered="true" toc="default"> <name>Broadcast R
ID</name>
<t>
<xref target="B-RID" format="default"/> illustrates the Broadcast RID
information flow. Note the absence of the Internet from the figure.
This is because Broadcast RID is one-way direct transmission of
application-layer messages over an RF data link (without IP) from
the UA to local Observer devices. Internet connectivity is involved
only in what the Observer chooses to do with the information
received, such as verify signatures using a web-based Broadcast
Authentication Verifier Service and look up information in
registries using the UAS ID as the primary unique key.
</t>
<figure anchor="B-RID"> <figure anchor="B-RID">
<name>"Broadcast RID Information Flow"</name> <name>Broadcast RID Information Flow</name>
<artwork type="ascii-art"> <artwork type="ascii-art">
+-------------------+ +-------------------+
| Unmanned Aircraft | | Unmanned Aircraft |
+---------o---------+ +---------o---------+
| |
| |
| |
| app messages directly over one-way RF data link | app messages directly over one-way RF data link
| |
| |
v v
skipping to change at line 1424 skipping to change at line 1524
| |
| |
| |
| app messages directly over one-way RF data link | app messages directly over one-way RF data link
| |
| |
v v
+------------------o-------------------+ +------------------o-------------------+
| Observer's device (e.g., smartphone) | | Observer's device (e.g., smartphone) |
+--------------------------------------+ +--------------------------------------+
</artwork> </artwork>
</figure> </figure>
<t> <t>
<xref target="B-RID" format="default"/> illustrates Broadcast RID Broadcast RID is conceptually similar to
information flow. Note the absence of the Internet from the figure. Automatic Dependent
This is because Broadcast RID is one-way direct transmission of Surveillance - Broadcast (ADS-B). However, for various technical
application layer messages over a RF data link (without IP) from
the UA to local Observer devices. Internet connectivity is involved
only in what the Observer chooses to do with the information
received, such as verify signatures using a web-based Broadcast
Authentication Verifier Service and look up information in
registries using the UAS ID as the primary unique key.
</t>
<t>
Broadcast RID is conceptually similar to Automatic Dependent
Surveillance - Broadcast (ADS-B). However, for various technical
and other reasons, regulators including the EASA have not indicated and other reasons, regulators including the EASA have not indicated
intent to allow, and FAA has explicitly prohibited, use of ADS-B intent to allow, and FAA has explicitly prohibited, use of ADS-B
for UAS RID. for UAS RID.
</t> </t>
<t> <t>
<xref target="F3411-19" format="default"/> specifies four Broadcast <xref target="F3411-19" format="default"/> specifies four Broadcast
RID data links: Bluetooth 4.x, Bluetooth 5.x with Extended RID data links: Bluetooth 4.x, Bluetooth 5.x with Extended
Advertisements and Long Range Coded PHY (S=8), Wi-Fi NAN at 2.4 Advertisements and Long-Range Coded PHY (S=8), Wi-Fi NAN at 2.4
GHz, and Wi-Fi NAN at 5 GHz. A UA must broadcast (using GHz, and Wi-Fi NAN at 5 GHz. A UA must broadcast (using
advertisement mechanisms where no other option supports broadcast) advertisement mechanisms where no other option supports broadcast)
on at least one of these. If sending on Bluetooth 5.x, it is also on at least one of these. If sending on Bluetooth 5.x, it is
required concurrently to do so on 4.x (referred to in <xref required to do so concurrently on 4.x (referred to in <xref
target="F3411-19" format="default"/> as Bluetooth Legacy); current target="F3411-19" format="default"/> as "Bluetooth Legacy"); current
(2021) discussions in ASTM F38.02 on revising the standard, (2021) discussions in ASTM F38.02 on revising <xref target="F3411-19" for
motivated by European standards drafts, suggest that both Bluetooth mat="default"/>,
motivated by drafts of European standards, suggest that both Bluetooth
versions will be required. If broadcasting Wi-Fi NAN at 5 GHz, it versions will be required. If broadcasting Wi-Fi NAN at 5 GHz, it
is also required concurrently to do so at 2.4 GHz; current is required to do so concurrently at 2.4 GHz; current
discussions in F38.02 include relaxing this. Wi-Fi Beacons are also discussions in ASTM F38.02 include relaxing this. Wi-Fi Beacons are also
under consideration. Future revisions of <xref target="F3411-19" under consideration. Future revisions of <xref target="F3411-19"
format="default"/> may allow other data links. format="default"/> may allow other data links.
</t> </t>
<t> <t>
The selection of the Broadcast media was driven by research into The selection of Broadcast RID media was driven by research into
what is commonly available on 'ground' units (smartphones and what is commonly available on "ground" units (smartphones and
tablets) and what was found as prevalent or 'affordable' in UA. tablets) and what was found as prevalent or "affordable" in UA.
Further, there must be an API for the Observer's receiving Further, there must be an API for the Observer's receiving
application to have access to these messages. As yet only Bluetooth application to have access to these messages. As yet, only Bluetooth
4.x support is readily available, thus the current focus is on 4.x support is readily available; thus, the current focus is on
working within the 31 byte payload limit of the Bluetooth 4.x working within the 31-byte payload limit of the Bluetooth 4.x
"Broadcast Frame" transmitted as an "advertisement" on beacon "Broadcast Frame" transmitted as an "advertisement" on beacon
channels. After overheads, this limits the RID message to 25 bytes channels. After overheads, this limits the RID message to 25 bytes
and UAS ID string to a maximum length of 20 bytes. and the UAS ID string to a maximum length of 20 bytes.
</t> </t>
<t> <t>
Length constraints also preclude a single Bluetooth 4.x frame A single Bluetooth 4.x advertisement frame can just barely fit any UAS ID long
carrying not only the UAS ID but also position, velocity, and other enough to
information that should be bound to the UAS ID, much less strong be sufficiently unique for its purpose.</t>
authentication data. Messages that cannot be encapsulated in a
single frame (thus far, only the Authentication Message) must be <t>
segmented into message "pages" (in the terminology of <xref There is related information, which especially includes, but is not limited t
target="F3411-19" format="default"/>). Message pages must somehow o,
be correlated as belonging to the same message. Messages carrying the UA position and velocity, which must be represented by data
position, velocity and other data must somehow be correlated with elements long enough to provide precision sufficient for their
the Basic ID message that carries the UAS ID. This correlation is purpose while remaining unambiguous with respect to their reference
expected to be done on the basis of MAC address: this may be frame.</t>
complicated by MAC address randomization; not all the common <t>
devices expected to be used by Observers have APIs that make sender In order to enable Observer devices to verify that 1) the claimed UAS ID is i
MAC addresses available to user space receiver applications; and ndeed owned by the sender
MAC addresses are easily spoofed. Data elements are not so detached and 2) the related information was indeed sent by the owner of that same UAS ID,
on other media (see Message Pack in the paragraph after next). authentication data elements
would typically be lengthy with conventional cryptographic signature schemes. T
hey would be
too long to fit in a single frame, even with the latest schemes currently being
standardized.</t>
<t>
Thus, it is infeasible to bundle information related to the UAS ID and correspon
ding
authentication data elements in a single Bluetooth 4.x frame; yet, somehow all t
hese must
be securely bound together.</t>
<t>
Messages that cannot be encapsulated in a
single frame (thus far, only the Authentication Message) must be segmented
into message "pages" (in the terminology of <xref target="F3411-19"
format="default"/>). Message pages must somehow be correlated as belonging
to the same message. Messages carrying position, velocity and other data
must somehow be correlated with the Basic ID Message that carries the UAS
ID.
This correlation is expected to be done on the basis of Media Access
Control (MAC) address. This may be complicated by MAC address
randomization. Not all the common devices expected to be used by Observers
have APIs that make sender MAC addresses available to user space receiver
applications. MAC addresses are easily spoofed.
Data elements are not
so detached on other media (see Message Pack in the paragraph after next).
</t> </t>
<t> <t>
<xref target="F3411-19" format="default"/> Broadcast RID specifies <xref target="F3411-19" format="default"/> Broadcast RID specifies
several message types. The 4 bit message type field in the header several message types (see Section 5.4.5 and Table 3 of <xref
can index up to 16 types. Only 7 are currently defined. Only 2 are target="F3411-19" format="default"/>). The table below lists
these message types. The 4-bit Message Type field in the header can
index up to 16 types. Only seven are defined at the time of writing. Only
two are
mandatory. All others are optional, unless required by a mandatory. All others are optional, unless required by a
jurisdictional authority, e.g., a CAA. To satisfy both EASA and FAA jurisdictional authority, e.g., a CAA. To satisfy both EASA and FAA
rules, all types are needed, except Self-ID and Authentication, as rules, all types are needed, except Self-ID and Authentication, as the
the data elements required by the rules are scattered across data elements required by the rules are scattered across several
several message types (along with some data elements not required message types (along with some data elements not required by the
by the rules). rules).
</t> </t>
<t> <t>
The Message Pack (type 0xF) is not actually a message, but the The Message Pack (type 0xF) is not actually a message but the
framed concatenation of at most one message of each type of any framed concatenation of at most one message of each type of any
subset of the other types, in type index order. Some of the subset of the other types, in type index order. Some of the
messages that it can encapsulate are mandatory, others optional. messages that it can encapsulate are mandatory; others are optional.
The Message Pack itself is mandatory on data links that can The Message Pack itself is mandatory on data links that can
encapsulate it in a single frame (Bluetooth 5.x and Wi-Fi). encapsulate it in a single frame (Bluetooth 5.x and Wi-Fi).
</t> </t>
<table anchor="MsgTypes"> <table anchor="MsgTypes">
<name>F3411-19 Message Types</name> <name>Message Types Defined in <xref target="F3411-19" format="default"/> </name>
<thead> <thead>
<tr><td>Index</td><td>Name</td><td>Req</td><td>Notes</td></tr> <tr><td>Index</td><td>Name</td><td>Req</td><td>Notes</td></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td>0x0</td><td>Basic ID</td><td>Mandatory</td> <tr><td>0x0</td><td>Basic ID</td><td>Mandatory</td>
<td>-</td></tr> <td>-</td></tr>
<tr><td>0x1</td><td>Location/Vector</td><td>Mandatory</td> <tr><td>0x1</td><td>Location/Vector</td><td>Mandatory</td>
<td>-</td></tr> <td>-</td></tr>
<tr><td>0x2</td><td>Authentication</td><td>Optional</td> <tr><td>0x2</td><td>Authentication</td><td>Optional</td>
<td>paged</td></tr> <td>paged</td></tr>
<tr><td>0x3</td><td>Self-ID</td><td>Optional</td> <tr><td>0x3</td><td>Self-ID</td><td>Optional</td>
<td>free text</td></tr> <td>free text</td></tr>
<tr><td>0x4</td><td>System</td><td>Optional</td> <tr><td>0x4</td><td>System</td><td>Optional</td>
<td>-</td></tr> <td>-</td></tr>
<tr><td>0x5</td><td>Operator</td><td>Optional</td> <tr><td>0x5</td><td>Operator ID</td><td>Optional</td>
<td>-</td></tr> <td>-</td></tr>
<tr><td>0xF</td><td>Message Pack</td><td>-</td> <tr><td>0xF</td><td>Message Pack</td><td>-</td>
<td>BT5 and Wi-Fi</td></tr> <td>BT5 and Wi-Fi</td></tr>
</tbody> </tbody>
<tfoot>
<tr><td>See Section 5.4.5 and Table 3 of <xref
target="F3411-19" format="default"/></td>
<td>-</td><td>-</td><td>-</td></tr>
</tfoot>
</table> </table>
<t> <t>
<xref target="F3411-19" format="default"/> Broadcast RID specifies <xref target="F3411-19" format="default"/> Broadcast RID specifies
very few quantitative performance requirements: static information very few quantitative performance requirements: static information
must be transmitted at least once per 3 seconds; dynamic must be transmitted at least once per three seconds, and dynamic
information (the Location/Vector message) must be transmitted at information (the Location/Vector Message) must be transmitted at
least once per second and be no older than one second when sent. least once per second and be no older than one second when sent.
<xref target="FRUR" format="default"/> requires all information be <xref target="FRUR" format="default"/> requires all information be
sent at least once per second. sent at least once per second.
</t> </t>
<t> <t>
<xref target="F3411-19" format="default"/> Broadcast RID transmits <xref target="F3411-19" format="default"/> Broadcast RID transmits
all information as cleartext (ASCII or binary), so static IDs all information as cleartext (ASCII or binary), so static IDs
enable trivial correlation of patterns of use, unacceptable in many enable trivial correlation of patterns of use, which is unacceptable in m any
applications, e.g., package delivery routes of competitors. applications, e.g., package delivery routes of competitors.
</t> </t>
<t> <t>
Any UA can assert any ID using the <xref target="F3411-19" Any UA can assert any ID using the <xref target="F3411-19" format="defaul
format="default"/> required Basic ID message, which lacks any t"/> required Basic ID Message, which lacks any
provisions for verification. The Position/Vector message likewise provisions for verification. The Location/Vector Message likewise
lacks provisions for verification, and does not contain the ID, so lacks provisions for verification and does not contain the ID, so it
must be correlated somehow with a Basic ID message: the developers must be correlated somehow with a Basic ID Message: the developers
of <xref target="F3411-19" format="default"/> have suggested using of <xref target="F3411-19" format="default"/> have suggested using
the MAC addresses on the Broadcast RID data link, but these may be the MAC addresses on the Broadcast RID data link, but these may be
randomized by the operating system stack to avoid the adversarial randomized by the operating system stack to avoid the adversarial
correlation problems of static identifiers. correlation problems of static identifiers.
</t> </t>
<t> <t>
The <xref target="F3411-19" format="default"/> optional The <xref target="F3411-19" format="default"/> optional
Authentication Message specifies framing for authentication data, Authentication Message specifies framing for authentication data
but does not specify any authentication method, and the maximum but does not specify any authentication method, and the maximum
length of the specified framing is too short for conventional length of the specified framing is too short for conventional
digital signatures and far too short for conventional certificates digital signatures and far too short for conventional certificates
(e.g., X.509). Fetching certificates via the Internet is not always (e.g., X.509). Fetching certificates via the Internet is not always
possible (e.g., Observers working in remote areas, such as national possible (e.g., Observers working in remote areas, such as national
forests), so devising a scheme whereby certificates can be forests), so devising a scheme whereby certificates can be
transported over Broadcast RID is necessary. The one-way nature of transported over Broadcast RID is necessary. The one-way nature of
Broadcast RID precludes challenge-response security protocols Broadcast RID precludes challenge-response security protocols
(e.g., Observers sending nonces to UA, to be returned in signed (e.g., Observers sending nonces to UA, to be returned in signed
messages). Without DRIP extensions to <xref target="F3411-19" messages). Without DRIP extensions to <xref target="F3411-19"
skipping to change at line 1581 skipping to change at line 1691
possible (e.g., Observers working in remote areas, such as national possible (e.g., Observers working in remote areas, such as national
forests), so devising a scheme whereby certificates can be forests), so devising a scheme whereby certificates can be
transported over Broadcast RID is necessary. The one-way nature of transported over Broadcast RID is necessary. The one-way nature of
Broadcast RID precludes challenge-response security protocols Broadcast RID precludes challenge-response security protocols
(e.g., Observers sending nonces to UA, to be returned in signed (e.g., Observers sending nonces to UA, to be returned in signed
messages). Without DRIP extensions to <xref target="F3411-19" messages). Without DRIP extensions to <xref target="F3411-19"
format="default"/>, an Observer would be seriously challenged to format="default"/>, an Observer would be seriously challenged to
validate the asserted UAS ID or any other information about the UAS validate the asserted UAS ID or any other information about the UAS
or its operator looked up therefrom. or its operator looked up therefrom.
</t> </t>
<t> <t>
In the currently (2021) proposed revision to ASTM <xref At the time of writing, the proposed revision of <xref target="F3411-19"
target="F3411-19" format="default"/>, a new Authentication Type 5 format="default"/> defines a new Authentication Type 5 ("Specific Authentication
has been defined, "Specific Authentication Method" (SAM), to enable Method (SAM)")
to enable
SDOs other than ASTM to define authentication payload formats. The SDOs other than ASTM to define authentication payload formats. The
first byte of the payload is the SAM Type, used to demultiplex such first byte of the payload is the SAM Type, used to demultiplex such
variant formats. All formats for other than private experimental variant formats. All formats (aside from those for private experimental
use must be registered with ICAO, which assigns the SAM Type. Any use) must be registered with ICAO, which assigns the SAM Type. Any
authentication message payload that is to be sent in exactly the Authentication Message payload that is to be sent in exactly the
same form over all currently specified Broadcast RID media is same form over all currently specified Broadcast RID media is
limited by lower layer constraints to a total length of 201 bytes. limited by lower-layer constraints to a total length of 201 bytes.
For Authentication Type 5, expected to be used by DRIP, the SAM For Authentication Type 5, which is expected to be used by DRIP, the SAM
Type byte consumes the first of these, limiting DRIP authentication Type byte consumes the first of these, limiting DRIP authentication
payload formats to a maximum of 200 bytes. payload formats to a maximum of 200 bytes.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <name>USS in UTM and RID</name> <section numbered="true" toc="default"> <name>USS in UTM and RID</name>
<t> <t>
UAS RID and UTM are complementary; Network RID is a UTM service. UAS RID and UTM are complementary; Network RID is a UTM service.
The backbone of the UTM system is comprised of multiple USS: one or The backbone of the UTM system is comprised of multiple USS: one or
several per jurisdiction; some limited to a single jurisdiction, several per jurisdiction with some being limited to a single jurisdiction
others spanning multiple jurisdictions. USS also serve as the while
principal or perhaps the sole interface for operators and UAS into others span multiple jurisdictions. USS also serve as the
principal, or perhaps the sole, interface for operators and UAS into
the UTM environment. Each operator subscribes to at least one USS. the UTM environment. Each operator subscribes to at least one USS.
Each UAS is registered by its operator in at least one USS. Each Each UAS is registered by its operator in at least one USS. Each
operational intent is submitted to one USS; if approved, that UAS operational intent is submitted to one USS; if approved, that UAS
and operator can commence that operation. During the operation, and operator can commence that operation. During the operation,
status and location of that UAS must be reported to that USS, which status and location of that UAS must be reported to that USS, which,
in turn provides information as needed about that operator, UAS, in turn, provides information as needed about that operator, UAS,
and operation into the UTM system and to Observers via Network RID. and operation into the UTM system and to Observers via Network RID.
</t> </t>
<t> <t>
USS provide services not limited to Network RID; indeed, the USS provide services not limited to Network RID; indeed, the primary
primary USS function is deconfliction of airspace usage by USS function is deconfliction of airspace usage between different UAS (an
different UAS and other (e.g., manned aircraft, rocket launch) d their
operations. Most deconfliction involving a given operation is hoped operators). It will occasionally deconflict UAS from non-UAS operations,
to be completed prior to commencing that operation, and is called such as
"strategic deconfliction". If that fails, "tactical deconfliction" manned aircraft and rocket
comes into play; ABDAA may not involve USS, but GBDAA likely will. launch. Most deconfliction involving a given operation is hoped to be
Dynamic constraints, formerly called UAS Volume Restrictions (UVR), completed prior to commencing that operation; this is called "strategic
can be necessitated by local emergencies, extreme weather, etc., deconfliction". If that fails, "tactical deconfliction" comes into
specified by authorities on the ground, and propagated in UTM. play; AirBorne DAA (ABDAA) may not involve USS, but Ground-Based DAA (GBD
AA)
likely will. Dynamic
constraints, formerly called "UAS Volume Restrictions (UVRs)", can be
necessitated by circumstances such as local emergencies and extreme weath
er, specified by
authorities on the ground, and propagated in UTM.
</t> </t>
<t> <t>
No role for USS in Broadcast RID is currently specified by No role for USS in Broadcast RID is currently specified by
regulators or <xref target="F3411-19" format="default"/>. However, regulators or by <xref target="F3411-19" format="default"/>. However,
USS are likely to serve as registries (or perhaps registrars) for USS are likely to serve as registries (or perhaps registrars) for
UAS (and perhaps operators); if so, USS will have a role in all UAS (and perhaps operators); if so, USS will have a role in all
forms of RID. Supplemental Data Service Providers (SDSP) are also forms of RID. Supplemental Data Service Providers (SDSPs) are also
likely to find roles, not only in UTM as such but also in enhancing likely to find roles, not only in UTM as such but also in enhancing
UAS RID and related services. Whether USS, SDSP, etc. are involved UAS RID and related services.
or not, RID services, narrowly defined, provide regulator specified RID services are used
identification information; more broadly defined, RID services may in concert with USS, SDSP, or other UTM entities (if and as needed and availa
leverage identification to facilitate related services or ble).
functions, likely beginning with V2X. Narrowly defined, RID services provide
regulator-specified identification information; more broadly defined,
RID services may leverage identification to facilitate related
services or functions, likely beginning with V2X.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <name>DRIP Focus</name> <section numbered="true" toc="default"> <name>DRIP Focus</name>
<t> <t>
In addition to the gaps described above, there is a fundamental gap In addition to the gaps described above, there is a fundamental gap
in almost all current or proposed regulations and technical in almost all current or proposed regulations and technical
standards for UAS RID. As noted above, ID is not an end in itself, standards for UAS RID. As noted above, ID is not an end in itself,
but a means. Protocols specified in <xref target="F3411-19" but a means. Protocols specified in <xref target="F3411-19"
format="default"/> etc. provide limited information potentially format="default"/> etc. provide limited information potentially
enabling, and no technical means for, an Observer to communicate enabling (but no technical means for) an Observer to communicate
with the pilot, e.g., to request further information on the UAS with the pilot, e.g., to request further information on the UAS
operation or exit from an airspace volume in an emergency. The operation or exit from an airspace volume in an emergency. The
System Message provides the location of the pilot/GCS, so an System Message provides the location of the pilot/GCS, so an
Observer could physically go to the asserted location to look for Observer could physically go to the asserted location to look for
the remote pilot; this is at best slow and may not be feasible. the Remote Pilot; this is slow, at best, and may not be feasible.
What if the pilot is on the opposite rim of a canyon, or there are What if the pilot is on the opposite rim of a canyon, or there are
multiple UAS operators to contact, whose GCS all lie in different multiple UAS operators to contact whose GCS all lie in different
directions from the Observer? An Observer with Internet directions from the Observer? An Observer with Internet
connectivity and access privileges could look up operator PII in a connectivity and access privileges could look up operator PII in a
registry, then call a phone number in hopes someone who can registry and then call a phone number in hopes that someone who can
immediately influence the UAS operation will answer promptly during immediately influence the UAS operation will answer promptly during
that operation; this is at best unreliable and may not be prudent. that operation; this is unreliable, at best, and may not be prudent.
Should pilots be encouraged to answer phone calls while flying? Should pilots be encouraged to answer phone calls while flying?
Internet technologies can do much better than this. Internet technologies can do much better than this.
</t> </t>
<t> <t>
Thus complementing <xref target="F3411-19" format="default"/> with Thus, to achieve widespread adoption of a RID system supporting safe and secur
protocols enabling strong authentication, preserving operator e
privacy while enabling immediate use of information by authorized operation of UAS, protocols must do the following (despite the intrinsic tensi
parties, is critical to achieve widespread adoption of a RID system on among
supporting safe and secure operation of UAS. Just as <xref these objectives):
</t>
<ul>
<li>preserve operator privacy,</li>
<li>enable strong authentication, and</li>
<li>enable the immediate use of information by authorized parties.</li>
</ul>
<t>
Just as <xref
target="F3411-19" format="default"/> is expected to be approved by target="F3411-19" format="default"/> is expected to be approved by
regulators as a basic means of compliance with UAS RID regulations, regulators as a basic means of compliance with UAS RID regulations,
DRIP is expected likewise to be approved to address further issues, DRIP is likewise expected to be approved to address further issues,
starting with the creation and registration of Session IDs. starting with the creation and registration of Session IDs.
</t> </t>
<t> <t>
DRIP will focus on making information obtained via UAS RID DRIP will focus on making information obtained via UAS RID
immediately usable: immediately usable:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li> <li>
by making it trustworthy (despite the severe constraints by making it trustworthy (despite the severe constraints
of Broadcast RID); of Broadcast RID);
</li> </li>
<li> <li>
by enabling verification that a UAS is registered for RID, and by enabling verification that a UAS is registered for RID, and,
if so, in which registry (for classification of trusted if so, in which registry (for classification of trusted
operators on the basis of known registry vetting, even by operators on the basis of known registry vetting, even by
Observers lacking Internet connectivity at observation time); Observers lacking Internet connectivity at observation time);
</li> </li>
<li> <li>
by facilitating independent reports of UA aeronautical data by facilitating independent reports of UA aeronautical data
(location, velocity, etc.) to confirm or refute the operator (location, velocity, etc.) to confirm or refute the operator
self-reports upon which UAS RID and UTM tracking are based; self-reports upon which UAS RID and UTM tracking are based;
</li> </li>
<li> <li>
by enabling instant establishment, by authorized parties, by enabling instant establishment, by authorized parties,
of secure communications with the remote pilot. of secure communications with the Remote Pilot.
</li> </li>
</ol> </ol>
<t> <t>
The foregoing considerations, beyond those addressed by baseline The foregoing considerations, beyond those addressed by baseline
UAS RID standards such as <xref target="F3411-19" UAS RID standards such as <xref target="F3411-19"
format="default"/>, imply the following requirements for DRIP. format="default"/>, imply the requirements for DRIP detailed in <xref tar get="reqs"/>.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <name>Requirements</name> <section numbered="true" toc="default" anchor="reqs"> <name>Requirements</name>
<t> <t>
The following requirements apply to DRIP as a set of related The following requirements apply to DRIP as a set of related
protocols, various subsets of which, in conjunction with other IETF protocols, various subsets of which, in conjunction with other IETF
and external technical standards, may suffice to comply with the and external technical standards, may suffice to comply with the
regulations in any given jurisdiction or meet any given user need. regulations in any given jurisdiction or meet any given user need.
It is not intended that each and every DRIP protocol alone satisfy It is not intended that each and every protocol of the DRIP set, alone, s atisfy
each and every requirement. To satisfy these requirements, Internet each and every requirement. To satisfy these requirements, Internet
connectivity is required some of the time: e.g., to support DRIP connectivity is required some of the time (e.g., to support DRIP
entity identifier creation/registration; but not all of the time, Entity Identifier creation/registration) but not all of the time
e.g., authentication of an asserted DRIP entity identifier can be (e.g., authentication of an asserted DRIP Entity Identifier can be
achieved by a fully working and provisioned Observer device even achieved by a fully working and provisioned Observer device even
when that device is off-line so is required at all times. when that device is off-line so is required at all times).
</t> </t>
<section numbered="true" toc="default"> <name>General</name> <section numbered="true" toc="default" anchor="gen-req"> <name>General</name>
<section numbered="true" toc="default"> <name>Normative Requirements</name> <section numbered="true" toc="default"> <name>Normative Requirements</name>
<ol spacing="normal" type="GEN-%d" group="gen"> <ol spacing="normal" type="GEN-%d" group="gen" indent="9">
<li>
Provable Ownership: DRIP MUST enable verification that the <li>
asserted entity (typically UAS) ID is that of the actual Provable Ownership: DRIP <bcp14>MUST</bcp14> enable verification that the
current sender (i.e., the entity ID in the DRIP authenticated asserted entity (typically UAS) ID is that of the actual current sender
message set is not a replay attack or other spoof, e.g., by (i.e., the Entity ID in the DRIP authenticated message set is not a replay
verifying an asymmetric cryptographic signature using a sender attack or other spoof), even on an Observer device lacking Internet
provided public key from which the asserted UAS ID can be at connectivity at the time of observation.
least partially derived), even on an Observer device lacking
Internet connectivity at the time of observation.
</li> </li>
<li> <li>
Provable Binding: DRIP MUST enable the cryptographic binding of Provable Binding: DRIP <bcp14>MUST</bcp14> enable the cryptograph ic binding of
all other <xref target="F3411-19" format="default"/> messages all other <xref target="F3411-19" format="default"/> messages
from the same actual current sender to the UAS ID asserted in from the same actual current sender to the UAS ID asserted in
the Basic ID message. the Basic ID Message.
</li> </li>
<li> <li>
Provable Registration: DRIP MUST enable cryptographically Provable Registration: DRIP <bcp14>MUST</bcp14> enable cryptograp hically
secure verification that the UAS ID is in a registry and secure verification that the UAS ID is in a registry and
identification of that registry, even on an Observer device identification of that registry, even on an Observer device
lacking Internet connectivity at the time of observation; the lacking Internet connectivity at the time of observation; the
same sender may have multiple IDs, potentially in different same sender may have multiple IDs, potentially in different
registries, but each ID must clearly indicate in which registry registries, but each ID must clearly indicate in which registry
it can be found. it can be found.
</li> </li>
<li> <li>
Readability: DRIP MUST enable information (regulation required Readability: DRIP <bcp14>MUST</bcp14> enable information (regulat ion required
elements, whether sent via UAS RID or looked up in registries) elements, whether sent via UAS RID or looked up in registries)
to be read and utilized by both humans and software. to be read and utilized by both humans and software.
</li> </li>
<li> <li>
Gateway: DRIP MUST enable Broadcast RID to Network RID Gateway: DRIP <bcp14>MUST</bcp14> enable
application layer gateways to stamp messages with precise application-layer gateways from Broadcast RID to Network RID to s
tamp messages with precise
date/time received and receiver location, then relay them to a date/time received and receiver location, then relay them to a
network service (e.g., SDSP or distributed ledger) whenever the network service (e.g., SDSP or distributed ledger) whenever the
gateway has Internet connectivity. gateway has Internet connectivity.
</li> </li>
<li> <li>
Contact: DRIP MUST enable dynamically establishing, with AAA, Contact: DRIP <bcp14>MUST</bcp14> enable dynamically establishing, with
per policy, strongly mutually authenticated, end-to-end AAA,
strongly encrypted communications with the UAS RID sender and per policy, strongly mutually authenticated, end-to-end
entities looked up from the UAS ID, including at least the strongly encrypted communications with the UAS RID sender and
pilot (remote pilot or Pilot In Command), the USS (if any) entities looked up from the UAS ID, including at least the
under which the operation is being conducted, and registries in (1) pilot (Remote Pilot or Pilot In Command), (2) the USS (if any)
which data on the UA and pilot are held, whenever each party to under which the operation is being conducted, and (3) registries
such desired communications has a currently usable means of in which data on the UA and pilot are held. This requirement applies
resolving the other party's DRIP entity identifier to a locator whenever each
(IP address) and currently usable bidirectional IP (not party to such desired communications has a currently usable
necessarily Internet) connectivity with the other party. means of resolving the other party's DRIP Entity Identifier
to a locator (IP address) and currently usable bidirectional
IP (not necessarily Internet) connectivity with the other
party.
</li> </li>
<li> <li>
QoS: DRIP MUST enable policy based specification of performance QoS: DRIP <bcp14>MUST</bcp14> enable policy-based specification o f performance
and reliability parameters. and reliability parameters.
</li> </li>
<li> <li>
Mobility: DRIP MUST support physical and logical mobility of Mobility: DRIP <bcp14>MUST</bcp14> support physical and logical m
UA, GCS and Observers. DRIP SHOULD support mobility of obility of
UA, GCS, and Observers. DRIP <bcp14>SHOULD</bcp14> support mobili
ty of
essentially all participating nodes (UA, GCS, Observers, essentially all participating nodes (UA, GCS, Observers,
Net-RID SP, Net-RID DP, Private Registry, SDSP, and potential ly Net-RID SP, Net-RID DP, Private Registries, SDSP, and potentially
others as RID and UTM evolve). others as RID and UTM evolve).
</li> </li>
<li> <li>
Multihoming: DRIP MUST support multihoming of UA and GCS, for Multihoming: DRIP <bcp14>MUST</bcp14> support multihoming of UA a nd GCS, for
make-before-break smooth handoff and resiliency against make-before-break smooth handoff and resiliency against
path/link failure. DRIP SHOULD support multihoming of path or link failure. DRIP <bcp14>SHOULD</bcp14> support multihom ing of
essentially all participating nodes. essentially all participating nodes.
</li> </li>
<li> <li>
Multicast: DRIP SHOULD support multicast for efficient Multicast: DRIP <bcp14>SHOULD</bcp14> support multicast for effic ient
and flexible publish-subscribe notifications, e.g., of UAS and flexible publish-subscribe notifications, e.g., of UAS
reporting positions in designated airspace volumes. reporting positions in designated airspace volumes.
</li> </li>
<li> <li>
Management: DRIP SHOULD support monitoring of the health Management: DRIP <bcp14>SHOULD</bcp14> support monitoring of the health
and coverage of Broadcast and Network RID services. and coverage of Broadcast and Network RID services.
</li> </li>
</ol> </ol>
</section> </section>
<section numbered="true" toc="default"> <name>Rationale</name> <section numbered="true" toc="default"> <name>Rationale</name>
<t> <t>
Requirements imposed either by regulation or <xref Requirements imposed either by regulation or by <xref
target="F3411-19" format="default"/> are not reiterated here, but target="F3411-19" format="default"/> are not reiterated in this document,
drive many of the numbered requirements listed here. The <xref but they
target="FRUR" format="default"/> regulatory QoS requirement drive many of the numbered requirements listed here. The regulatory perfo
rmance requirement in <xref
target="FRUR" format="default"/>
currently would be satisfied by ensuring information refresh rates currently would be satisfied by ensuring information refresh rates
of at least 1 Hertz, with latencies no greater than 1 second, at of at least 1 Hertz, with latencies no greater than 1 second, at
least 80% of the time, but these numbers may vary between least 80% of the time, but these numbers may vary between
jurisdictions and over time. So instead the DRIP QoS requirement is jurisdictions and over time. Instead, the DRIP QoS requirement is
that performance, reliability, etc. parameters be user policy that parameters such as performance and reliability be specifiable by use
specifiable, which does not imply satisfiable in all cases, but r policy,
(especially together with the management requirement) implies that which does not imply satisfiable in all cases but
does imply (especially together with the Management requirement) that
when specifications are not met, appropriate parties are notified. when specifications are not met, appropriate parties are notified.
</t> </t>
<t> <t>
The "provable ownership" requirement addresses the possibility that The Provable Ownership requirement addresses the possibility that the
the actual sender is not the claimed sender (i.e., is a spoofer). actual sender is not the claimed sender (i.e., is a spoofer). DRIP
The "provable binding" requirement addresses the MAC address could meet this requirement by, for example, verifying an asymmetric
correlation problem of <xref target="F3411-19" format="default"/> cryptographic signature using a sender-provided public key from which
noted above. The "provable registration" requirement may impose the asserted UAS ID can be at least partially derived. The Provable
burdens not only on the UAS sender and the Observer's receiver, but Binding requirement addresses the problem with MAC address correlation
also on the registry; yet it cannot depend upon the Observer being <xref target="F3411-19" format="default"/> noted in <xref
able to contact the registry at the time of observing the UA. The target="broadcast-rid" format="default"/>. The Provable Registration
"readability" requirement pertains to the structure and format of requirement may impose burdens not only on the UAS sender and the
information at endpoints rather than its encoding in transit, so Observer's receiver, but also on the registry; yet, it cannot depend
may involve machine assisted format conversions, e.g., from binary upon the Observer being able to contact the registry at the time of
encodings, and/or decryption (see <xref target="priv" observing the UA. The Readability requirement pertains to the
format="default"/>). structure and format of information at endpoints rather than its
encoding in transit, so it may involve machine-assisted format
conversions (e.g., from binary encodings) and/or decryption (see <xref
target="priv" format="default"/>).
</t> </t>
<t> <t>
The "gateway" requirement is in pursuit of three objectives: (1) The Gateway requirement is in pursuit of three objectives: (1)
mark up a RID message with where and when it was actually received, mark up a RID message with where and when it was actually received,
which may agree or disagree with the self-report in the set of which may agree or disagree with the self-report in the set of
messages; (2) defend against replay attacks; and (3) support messages; (2) defend against replay attacks; and (3) support
optional SDSP services such as multilateration, to complement UAS optional SDSP services such as multilateration, to complement UAS
position self-reports with independent measurements. This is the position self-reports with independent measurements. This is the
only instance in which DRIP transports <xref target="F3411-19" only instance in which DRIP transports <xref target="F3411-19" format="de
format="default"/> messages; most of DRIP pertains to the fault"/> messages; most of DRIP pertains to the
authentication of such messages and identifiers carried in them. authentication of such messages and identifiers carried in them.
</t> </t>
<t> <t>
The "contact" requirement allows any party that learns a UAS ID The Contact requirement allows any party that learns a UAS ID
(that is a DRIP entity identifier rather than another UAS ID Type) (that is a DRIP Entity Identifier rather than another ID Type)
to request establishment of a communications session with the to request establishment of a communications session with the
corresponding UAS RID sender and certain entities associated with corresponding UAS RID sender and certain entities associated with
that UAS, but AAA and policy restrictions, <em>inter alia</em> on that UAS, but AAA and policy restrictions, inter alia on
resolving the identifier to any locators (typically IP addresses), resolving the identifier to any locators (typically IP addresses),
should prevent unauthorized parties from distracting or harassing should prevent unauthorized parties from distracting or harassing
pilots. Thus some but not all Observers of UA, receivers of pilots. Thus, some but not all Observers of UA, receivers of
Broadcast RID, clients of Network RID, and other parties can Broadcast RID, clients of Network RID, and other parties can
become successfully initiating endpoints for these sessions. become successfully initiating endpoints for these sessions.
</t> </t>
<t> <t>
The "QoS" requirement is only that performance and reliability The QoS requirement is only that performance and reliability
parameters can be <em>specified</em> by policy, not that any such parameters can be <em>specified</em> by policy, not that any such
specifications must be guaranteed to be met; any failure to meet specifications must be guaranteed to be met; any failure to meet
such would be reported under the "management" requirement. Examples such would be reported under the Management requirement. Examples
of such parameters are the maximum time interval at which messages of such parameters are the maximum time interval at which messages
carrying required data elements may be transmitted, the maximum carrying required data elements may be transmitted, the maximum
tolerable rate of loss of such messages, and the maximum tolerable tolerable rate of loss of such messages, and the maximum tolerable
latency between a dynamic data element (e.g., GNSS position of UA) latency between a dynamic data element (e.g., GNSS position of UA)
being provided to the DRIP sender and that element being delivered being provided to the DRIP sender and that element being delivered
by the DRIP receiver to an application. by the DRIP receiver to an application.
</t> </t>
<t> <t>
The "mobility" requirement refers to rapid geographic mobility of The Mobility requirement refers to rapid geographic mobility of
nodes, changes of their points of attachment to networks, and nodes, changes of their points of attachment to networks, and
changes to their IP addresses; it is not limited to micro-mobility changes to their IP addresses; it is not limited to micro-mobility
within a small geographic area or single Internet access provider. within a small geographic area or single Internet access provider.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <name> Identifier</name> <section numbered="true" toc="default" anchor="id-req"> <name> Identifier</name>
<section numbered="true" toc="default"> <name>Normative Requirements</name> <section numbered="true" toc="default"> <name>Normative Requirements</name>
<ol spacing="normal" type="ID-%d" group="id"> <ol spacing="normal" type="ID-%d" group="id" indent="9">
<li> <li>
Length: The DRIP entity identifier MUST NOT be longer than 19 Length: The DRIP Entity Identifier <bcp14>MUST NOT</bcp14> be lon ger than 19
bytes, to fit in the Specific Session ID subfield of the UAS ID bytes, to fit in the Specific Session ID subfield of the UAS ID
field of the Basic ID message of the currently (August 2021) field of the Basic ID Message of the
proposed revision of <xref target="F3411-19" proposed revision of <xref target="F3411-19"
format="default"/>. format="default"/> (at the time of writing).
</li> </li>
<li> <li>
Registry ID: The DRIP identifier MUST be sufficient to identify Registry ID: The DRIP identifier <bcp14>MUST</bcp14> be sufficien t to identify
a registry in which the entity identified therewith is listed. a registry in which the entity identified therewith is listed.
</li> </li>
<li> <li>
Entity ID: The DRIP identifier MUST be sufficient to enable Entity ID: The DRIP identifier <bcp14>MUST</bcp14> be sufficient to enable
lookups of other data associated with the entity identified lookups of other data associated with the entity identified
therewith in that registry. therewith in that registry.
</li> </li>
<li> <li>
Uniqueness: The DRIP identifier MUST be unique within the Uniqueness: The DRIP identifier <bcp14>MUST</bcp14> be unique wit hin the
applicable global identifier space from when it is first applicable global identifier space from when it is first
registered therein until it is explicitly de-registered registered therein until it is explicitly deregistered
therefrom (due to, e.g., expiration after a specified lifetime, therefrom (due to, e.g., expiration after a specified lifetime,
revocation by the registry, or surrender by the operator). revocation by the registry, or surrender by the operator).
</li> </li>
<li> <li>
Non-spoofability: The DRIP identifier MUST NOT be spoofable Non-spoofability: The DRIP identifier <bcp14>MUST NOT</bcp14> be spoofable
within the context of a minimal Remote ID broadcast message set within the context of a minimal Remote ID broadcast message set
(to be specified within DRIP to be sufficient collectively to (to be specified within DRIP to be sufficient collectively to
prove sender ownership of the claimed identifier). prove sender ownership of the claimed identifier).
</li> </li>
<li> <li>
Unlinkability: The DRIP identifier MUST NOT facilitate Unlinkability: The DRIP identifier <bcp14>MUST NOT</bcp14> facili tate
adversarial correlation over multiple operations. If this is adversarial correlation over multiple operations. If this is
accomplished by limiting each identifier to a single use or accomplished by limiting each identifier to a single use or
brief period of usage, the DRIP identifier MUST support brief period of usage, the DRIP identifier <bcp14>MUST</bcp14> su pport
well-defined, scalable, timely registration methods. well-defined, scalable, timely registration methods.
</li> </li>
</ol> </ol>
</section> </section>
<section numbered="true" toc="default"> <name>Rationale</name> <section numbered="true" toc="default"> <name>Rationale</name>
<t> <t>
The DRIP identifier can refer to various entities. In the primary The DRIP identifier can refer to various entities. In the primary
initial use case, the entity to be identified is the UA. Entities initial use case, the entity to be identified is the UA. Entities to
to be identified in other likely use cases include but are not be identified in other likely use cases include, but are not limited to,
limited to the operator, USS, and Observer. In all cases, the the operator, USS, and Observer. In all cases, the entity identified
entity identified must own (have the exclusive capability to use, must own the identifier (i.e., have the exclusive capability to use
such that receivers can verify its ownership of) the identifier. the identifier, such that receivers can verify the entity's ownership
of it).
</t> </t>
<t> <t>
The DRIP identifier can be used at various layers. In Broadcast The DRIP identifier can be used at various layers. In Broadcast RID,
RID, it would be used by the application running directly over the it would be used by the application running directly over the data
data link. In Network RID, it would be used by the application link. In Network RID, it would be used by the application running over
running over HTTPS (not required by DRIP but generally used by HTTPS (not required by DRIP but generally used by Network RID
Network RID implementations) and possibly other protocols. In RID implementations) and possibly other protocols. In RID-initiated V2X
initiated V2X applications such as DAA and C2, it could be used applications such as DAA and C2, it could be used between the network
between the network and transport layers, e.g., with the Host and transport layers (e.g., with the Host Identity Protocol (HIP)
Identity Protocol (HIP, <xref target="RFC9063" format="default"/>, <xref target="RFC9063" format="default"/> <xref target="RFC7401"
<xref target="RFC7401" format="default"/>, etc.), or between the format="default"/>) or between the transport and application
transport and application layers, e.g., with Datagram Transport layers (e.g., with DTLS <xref
Layer Security (DTLS, <xref target="RFC6347" format="default"/>). target="RFC6347" format="default"/>).
</t> </t>
<t> <t>
Registry ID (which registry the entity is in) and Entity ID (which Registry ID (which registry the entity is in) and Entity ID (which
entity it is, within that registry) are requirements on a single entity it is, within that registry) are requirements on a single
DRIP entity identifier, not separate (types of) ID. In the most DRIP Entity Identifier, not separate (types of) ID. In the most
common use case, the entity will be the UA, and the DRIP identifier common use case, the entity will be the UA, and the DRIP identifier
will be the UAS ID; however, other entities may also benefit from will be the UAS ID; however, other entities may also benefit from
having DRIP identifiers, so the entity type is not prescribed here. having DRIP identifiers, so the entity type is not prescribed here.
</t> </t>
<t> <t>
Whether a UAS ID is generated by the operator, GCS, UA, USS, Whether a UAS ID is generated by the operator, GCS, UA, USS,
registry, or some collaboration thereamong, is unspecified; registry, or some collaboration among them is unspecified;
however, there must be agreement on the UAS ID among these however, there must be agreement on the UAS ID among these
entities. Management of DRIP identifiers is the primary function of entities. Management of DRIP identifiers is the primary function of
their registration hierarchies, from the root (presumably IANA), their registration hierarchies, from the root (presumably IANA),
through sector-specific and regional authorities (presumably ICAO through sector-specific and regional authorities (presumably ICAO
and CAAs), to the identified entities themselves. and CAAs), to the identified entities themselves.
</t> </t>
<t> <t>
While "uniqueness" might be considered an implicit requirement for While Uniqueness might be considered an implicit requirement for
any identifier, here the point of the explicit requirement is not any identifier, here the point of the explicit requirement is not
just that it should be unique, but also where and when it should be just that it should be unique, but also where and when it should be
unique: global scope within a specified space, from registration to unique: global scope within a specified space, from registration to
deregistration. deregistration.
</t> </t>
<t> <t>
While "non-spoofability" imposes requirements for and on a DRIP While Non-spoofability imposes requirements for and on a DRIP
authentication protocol, it also imposes requirements on the authentication protocol, it also imposes requirements on the
properties of the identifier itself. An example of how the nature properties of the identifier itself. An example of how the nature
of the identifier can support non-spoofability is embedding a hash of the identifier can support non-spoofability is embedding a hash
of both the registry ID and a public key of the entity in the of both the Registry ID and a public key of the entity in the
entity identifier, thus making it self-authenticating any time the entity identifier, thus making it self-authenticating any time the
entity's corresponding private key is used to sign a message. entity's corresponding private key is used to sign a message.
</t> </t>
<t> <t>
While "unlinkability" is a privacy desideratum (see next section), While Unlinkability is a privacy desideratum (see <xref target="priv"/>),
it imposes requirements on the DRIP identifier itself, as distinct it imposes requirements on the DRIP identifier itself, as distinct
from other currently permitted choices for the UAS ID (including from other currently permitted choices for the UAS ID (including
primarily the static serial number of the UA or RID module). primarily the static serial number of the UA or RID module).
</t> </t>
</section> </section>
</section> </section>
<section anchor="priv" numbered="true" toc="default"> <name>Privacy</name> <section anchor="priv" numbered="true" toc="default"> <name>Privacy</name>
<section numbered="true" toc="default"> <name>Normative Requirements</name> <section numbered="true" toc="default"> <name>Normative Requirements</name>
<ol spacing="normal" type="PRIV-%d" group="priv"> <ol spacing="normal" type="PRIV-%d" group="priv" indent="9">
<li> <li>
Confidential Handling: DRIP MUST enable confidential Confidential Handling: DRIP <bcp14>MUST</bcp14> enable confidenti
handling of private information (i.e., any and all information al
designated by neither cognizant authority nor the information handling of private information (i.e., any and all
owner as public, e.g., personal data). information that neither the cognizant authority nor
the information owner has designated as public, e.g., personal data)
.
</li> </li>
<li> <li>
Encrypted Transport: DRIP MUST enable selective strong Encrypted Transport: DRIP <bcp14>MUST</bcp14> enable selective st rong
encryption of private data in motion in such a manner that only encryption of private data in motion in such a manner that only
authorized actors can recover it. If transport is via IP, then authorized actors can recover it. If transport is via IP, then
encryption MUST be end-to-end, at or above the IP layer. DRIP encryption <bcp14>MUST</bcp14> be end-to-end, at or above the IP
MUST NOT encrypt safety critical data to be transmitted over layer. DRIP
<bcp14>MUST NOT</bcp14> encrypt safety critical data to be transm
itted over
Broadcast RID in any situation where it is unlikely that local Broadcast RID in any situation where it is unlikely that local
Observers authorized to access the plaintext will be able to Observers authorized to access the plaintext will be able to
decrypt it or obtain it from a service able to decrypt it. DRIP decrypt it or obtain it from a service able to decrypt it. DRIP
MUST NOT encrypt data when/where doing so would conflict with <bcp14>MUST NOT</bcp14> encrypt data when/where doing so would co nflict with
applicable regulations or CAA policies/procedures, i.e., DRIP applicable regulations or CAA policies/procedures, i.e., DRIP
MUST support configurable disabling of encryption. <bcp14>MUST</bcp14> support configurable disabling of encryption.
</li> </li>
<li> <li>
Encrypted Storage: DRIP SHOULD facilitate selective strong Encrypted Storage: DRIP <bcp14>SHOULD</bcp14> facilitate selectiv e strong
encryption of private data at rest in such a manner that only encryption of private data at rest in such a manner that only
authorized actors can recover it. authorized actors can recover it.
</li> </li>
<li> <li>
Public/Private Designation: DRIP SHOULD facilitate designation, Public/Private Designation: DRIP <bcp14>SHOULD</bcp14> facilitate designation,
by cognizant authorities and information owners, of which by cognizant authorities and information owners, of which
information is public and which is private. By default, all information is public and which is private. By default, all
information required to be transmitted via Broadcast RID, even information required to be transmitted via Broadcast RID, even
when actually sent via Network RID or stored in registries, is when actually sent via Network RID or stored in registries, is
assumed to be public; all other information held in registries assumed to be public; all other information held in registries
for lookup using the UAS ID is assumed to be private. for lookup using the UAS ID is assumed to be private.
</li> </li>
<li> <li>
Pseudonymous Rendezvous: DRIP MAY enable mutual discovery of Pseudonymous Rendezvous: DRIP <bcp14>MAY</bcp14> enable mutual di scovery of
and communications among participating UAS operators whose UA and communications among participating UAS operators whose UA
are in 4-D proximity, using the UAS ID without revealing are in 4-D proximity, using the UAS ID without revealing
pilot/operator identity or physical location. pilot/operator identity or physical location.
</li> </li>
</ol> </ol>
</section> </section>
<section numbered="true" toc="default"> <name>Rationale</name> <section numbered="true" toc="default"> <name>Rationale</name>
<t> <t>
Most data to be sent via Broadcast RID or Network RID is public, Most data to be sent via Broadcast RID or Network RID is public;
thus the "encrypted transport" requirement for private data is thus, the Encrypted Transport requirement for private data is
selective, e.g., for the entire payload of the Operator ID Message, selective, e.g., for the entire payload of the Operator ID Message,
but only the pilot/GCS location fields of the System Message. but only the pilot/GCS location fields of the System Message.
Safety critical data includes at least the UA location. Other data Safety critical data includes at least the UA location. Other data
also may be deemed safety critical, e.g., in some jurisdictions the also may be deemed safety critical, e.g., in some jurisdictions the
pilot/GCS location is implied to be safety critical. pilot/GCS location is implied to be safety critical.
</t> </t>
<t> <t>
UAS have several potential means of assessing the likelihood that UAS have several potential means of assessing the likelihood that
local Observers authorized to access the plaintext will be able to local Observers authorized to access the plaintext will be able to
decrypt it or obtain it from a service able to decrypt it. If the decrypt it or obtain it from a service able to decrypt it. If the
UAS is not participating in UTM, an Observer would have no means of UAS is not participating in UTM, an Observer would have no means of
obtaining a decryption key or decryption services from a cognizant obtaining a decryption key or decryption services from a cognizant
USS. If the UAS is participating in UTM, but has lost connectivity USS. If the UAS is participating in UTM but has lost connectivity
with its USS, then an Observer within visual LOS of the UA is also with its USS, then an Observer within visual LOS of the UA is also
unlikely to be able to communicate with that USS (whether due to unlikely to be able to communicate with that USS (whether due to
the USS being offline or the UAS and Observer being in an area with the USS being offline or the UAS and Observer being in an area with
poor Internet connectivity). Either of these conditions (UTM poor Internet connectivity). Either of these conditions (UTM
non-participation or USS unreachability) would be known to the UAS. non-participation or USS unreachability) would be known to the UAS.
</t> </t>
<t> <t>
In some jurisdictions, the configurable enabling and disabling of In some jurisdictions, the configurable enabling and disabling of
encryption may need to be outside the control of the operator. encryption may need to be outside the control of the operator.
<xref target="FRUR" format="default"/> mandates manufacturers <xref target="FRUR" format="default"/> mandates that manufacturers
design RID equipment with some degree of tamper resistance; the design RID equipment with some degree of tamper resistance; the
preamble and other FAA commentary suggest this is to reduce the preamble of <xref target="FRUR" format="default"/> and other FAA commenta ry suggest this is to reduce the
likelihood that an operator, intentionally or unintentionally, likelihood that an operator, intentionally or unintentionally,
might alter the values of the required data elements or disable might alter the values of the required data elements or disable
their transmission in the required manner (e.g., as cleartext). their transmission in the required manner (e.g., as cleartext).
</t> </t>
<t> <t>
How information is stored on end systems is out of scope for DRIP. How information is stored on end systems is out of scope for DRIP.
Encouraging privacy best practices, including end system storage Encouraging privacy best practices, including end system storage
encryption, by facilitating it with protocol design reflecting such encryption, by facilitating it with protocol design reflecting such
considerations, is in scope. Similar logic applies to methods for considerations is in scope. Similar logic applies to methods for
designating information as public or private. designating information as public or private.
</t> </t>
<t> <t>
The privacy requirements above are for DRIP, neither for <xref The Privacy requirements above are for DRIP, neither for <xref
target="F3411-19" format="default"/> (which requires obfuscation of target="F3411-19" format="default"/> (which, in the interest of
location to any Network RID subscriber engaging in wide area privacy, requires obfuscation of location to any Network RID
surveillance, limits data retention periods, etc., in the interests subscriber engaging in wide area surveillance, limits data retention
of privacy), nor for UAS RID in any specific jurisdiction (which periods, etc.), nor for UAS RID in any specific jurisdiction (which may
may have its own regulatory requirements). The requirements above have its own regulatory requirements). The requirements above are also
are also in a sense parameterized: who are the "authorized actors", in a sense parameterized: who are the "authorized actors", how are
how are they designated, how are they authenticated, etc.? they designated, how are they authenticated, etc.?
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <name>Registries</name> <section numbered="true" toc="default"> <name>Registries</name>
<section numbered="true" toc="default"> <name>Normative Requirements</name> <section numbered="true" toc="default"> <name>Normative Requirements</name>
<ol spacing="normal" type="REG-%d" group="reg"> <ol spacing="normal" type="REG-%d" group="reg" indent="9">
<li> <li>
Public Lookup: DRIP MUST enable lookup, from the UAS ID, of Public Lookup: DRIP <bcp14>MUST</bcp14> enable lookup, from the U
information designated by cognizant authority as public, and AS ID, of
MUST NOT restrict access to this information based on identity information designated by cognizant authority as public and
<bcp14>MUST NOT</bcp14> restrict access to this information based
on identity
or role of the party submitting the query. or role of the party submitting the query.
</li> </li>
<li> <li>
Private Lookup: DRIP MUST enable lookup of private information Private Lookup: DRIP <bcp14>MUST</bcp14> enable lookup of private information
(i.e., any and all information in a registry, associated with (i.e., any and all information in a registry, associated with
the UAS ID, that is designated by neither cognizant authority the UAS ID, that is designated by neither cognizant authority
nor the information owner as public), and MUST, according to nor the information owner as public), and <bcp14>MUST</bcp14>, ac cording to
applicable policy, enforce AAA, including restriction of access applicable policy, enforce AAA, including restriction of access
to this information based on identity or role of the party to this information based on identity or role of the party
submitting the query. submitting the query.
</li> </li>
<li> <li>
Provisioning: DRIP MUST enable provisioning registries with Provisioning: DRIP <bcp14>MUST</bcp14> enable provisioning regist ries with
static information on the UAS and its operator, dynamic static information on the UAS and its operator, dynamic
information on its current operation within the U-space/UTM information on its current operation within the U-space/UTM
(including means by which the USS under which the UAS is (including means by which the USS under which the UAS is
operating may be contacted for further, typically even more operating may be contacted for further, typically even more
dynamic, information), and Internet direct contact information dynamic, information), and Internet direct contact information
for services related to the foregoing. for services related to the foregoing.
</li> </li>
<li> <li>
AAA Policy: DRIP AAA MUST be specifiable by policies; the AAA Policy: DRIP AAA <bcp14>MUST</bcp14> be specifiable by polici es; the
definitive copies of those policies must be accessible in definitive copies of those policies must be accessible in
registries; administration of those policies and all DRIP registries; administration of those policies and all DRIP
registries must be protected by AAA. registries must be protected by AAA.
</li> </li>
</ol> </ol>
</section> </section>
<section numbered="true" toc="default"> <name>Rationale</name> <section numbered="true" toc="default"> <name>Rationale</name>
<t> <t>
Registries are fundamental to RID. Only very limited information Registries are fundamental to RID. Only very limited information can
can be Broadcast, but extended information is sometimes needed. The be transmitted via Broadcast RID, but extended information is sometimes n
most essential element of information sent is the UAS ID itself, eeded. The most
the unique key for lookup of extended information in registries. essential element of information sent is the UAS ID itself, the unique
Beyond designating the UAS ID as that unique key, the registry key for lookup of extended information in registries.
information model is not specified herein, in part because The regulatory requirements for the registry information models for UAS and
regulatory requirements for different registries (UAS operators and their operators for RID and, more broadly, for U-space/UTM needs are in flux.
their UA, each narrowly for UAS RID and broadly for U-space/UTM) Thus, beyond designating the UAS ID as that unique key, the registry information
and business models for meeting those requirements are in flux. model is not specified in this document.
While it is expected that registry functions will be integrated While it is expected that
with USS, who will provide them is not yet determined in most, and registry functions will be integrated with USS, who will provide them
is expected to vary between, jurisdictions. However this evolves, is expected to vary between jurisdictions and has not yet been determined
the essential registry functions, starting with management of in
identifiers, are expected to remain the same, so are specified most jurisdictions. However this evolves, the essential registry
herein. functions, starting with management of identifiers, are expected to
remain the same, so those are specified herein.
</t> </t>
<t> <t>
While most data to be sent via Broadcast or Network RID is public, While most data to be sent via Broadcast or Network RID is public,
much of the extended information in registries will be private. much of the extended information in registries will be private.
Thus AAA for registries is essential, not just to ensure that Thus, AAA for registries is essential, not just to ensure that
access is granted only to strongly authenticated, duly authorized access is granted only to strongly authenticated, duly authorized
parties, but also to support subsequent attribution of any leaks, parties, but also to support subsequent attribution of any leaks,
audit of who accessed information when and for what purpose, etc. audit of who accessed information when and for what purpose, etc.
As specific AAA requirements will vary by jurisdictional Specific AAA requirements will vary by jurisdictional
regulation, provider philosophy, customer demand, etc., they are regulation, provider philosophy, customer demand, etc., so they are
left to specification in policies, which should be human readable left to specification in policies. Such policies should be human readable
to facilitate analysis and discussion, and machine readable to to facilitate analysis and discussion, be machine readable to
enable automated enforcement, using a language amenable to both, enable automated enforcement, and use a language amenable to both,
e.g., XACML. e.g., eXtensible Access Control Markup Language (XACML).
</t> </t>
<t> <t>
The intent of the negative and positive access control requirements The intent of the negative and positive access control requirements
on registries is to ensure that no member of the public would be on registries is to ensure that no member of the public would be
hindered from accessing public information, while only duly hindered from accessing public information, while only duly
authorized parties would be enabled to access private information. authorized parties would be enabled to access private information.
Mitigation of Denial of Service attacks and refusal to allow Mitigation of denial-of-service attacks and refusal to allow
database mass scraping would be based on those behaviors, not on database mass scraping would be based on those behaviors, not on
identity or role of the party submitting the query <em>per se</em>, identity or role of the party submitting the query per se;
but querant identity information might be gathered (by security however,
systems protecting DRIP implementations) on such misbehavior. information on the identity of the party submitting the query might be
gathered on such misbehavior by security systems protecting DRIP
implementations.
</t> </t>
<t> <t>
By "Internet direct contact information" is meant a locator (e.g., "Internet direct contact information" means a locator (e.g.,
IP address), or identifier (e.g., FQDN) that can be resolved to a IP address), or identifier (e.g., FQDN) that can be resolved to a
locator, which would enable initiation of an end-to-end locator, which enables initiation of an end-to-end
communication session using a well known protocol (e.g., SIP). communication session using a well-known protocol (e.g., SIP).
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"> <name>IANA Considerations< /name> <section anchor="IANA" numbered="true" toc="default"> <name>IANA Considerations< /name>
<t> <t>
This document does not make any IANA request. This document has no IANA actions.
</t> </t>
</section> </section>
<section anchor="Security" numbered="true" toc="default"> <name>Security Conside rations</name> <section anchor="Security" numbered="true" toc="default"> <name>Security Conside rations</name>
<t> <t>
DRIP is all about safety and security, so content pertaining to DRIP is all about safety and security, so content pertaining to
such is not limited to this section. This document does not define such is not limited to this section. This document does not define
any protocols, so security considerations of such are speculative. any protocols, so security considerations of such are speculative.
Potential vulnerabilities of DRIP solutions to these requirements Potential vulnerabilities of DRIP solutions to these requirements
include but are not limited to: include but are not limited to:
</t> </t>
skipping to change at line 2188 skipping to change at line 2326
</li> </li>
<li> <li>
processing overload induced by attempting to verify many processing overload induced by attempting to verify many
spoofed signed messages (where verification will fail but spoofed signed messages (where verification will fail but
still consume cycles) still consume cycles)
</li> </li>
<li> <li>
malicious or malfunctioning registries malicious or malfunctioning registries
</li> </li>
<li> <li>
interception by on-path attacker of (i.e., Man In The interception by on-path attacker of (i.e., man-in-the-mid
Middle attacks on) registration messages dle attacks on) registration messages
</li> </li>
<li> <li>
UA impersonation through private key extraction, improper UA impersonation through private key extraction, improper
key sharing, or carriage of a small (presumably harmless) key sharing, or carriage of a small (presumably harmless)
UA, i.e., as a "false flag", by a larger (malicious) UA UA, i.e., as a "false flag", by a larger (malicious) UA
</li> </li>
</ul> </ul>
<t> <t>
It may be inferred from the general requirements (Section 4.1) for It may be inferred from the General requirements (<xref target="gen-req"/
provable ownership, provable binding, and provable registration, >) for
together with the identifier requirements (Section 4.2), that DRIP Provable Ownership, Provable Binding, and Provable Registration,
together with the Identifier requirements (<xref target="id-req"/>), that
DRIP
must provide: must provide:
</t> </t>
<ul> <ul>
<li> <li>
message integrity message integrity
</li> </li>
<li> <li>
non-repudiation non-repudiation
</li> </li>
<li> <li>
skipping to change at line 2224 skipping to change at line 2361
defense against spoofing defense against spoofing
</li> </li>
</ul> </ul>
<t> <t>
One approach to so doing involves verifiably binding the DRIP One approach to so doing involves verifiably binding the DRIP
identifier to a public key. Providing these security features, identifier to a public key. Providing these security features,
whether via this approach or another, is likely to be especially whether via this approach or another, is likely to be especially
challenging for Observers without Internet connectivity at the time challenging for Observers without Internet connectivity at the time
of observation. For example, checking the signature of a registry of observation. For example, checking the signature of a registry
on a public key certificate received via Broadcast RID in a remote on a public key certificate received via Broadcast RID in a remote
area presumably would require that the registry’s public key had area presumably would require that the registry's public key had
been previously installed on the Observer’s device, yet there may been previously installed on the Observer's device, yet there may
be many registries and the Observer’s device may be storage be many registries and the Observer's device may be storage
constrained, and new registries may come on-line subsequent to constrained, and new registries may come on-line subsequent to
installation of DRIP software on the Observer’s device. See also installation of DRIP software on the Observer's device. See also
<xref target="Scenario" format="default"/> and the associated <xref target="Scenario" format="default"/> and the associated
explanatory text, especially the second paragraph after the figure. explanatory text, especially the second paragraph after the figure.
Thus there may be caveats on the extent to which requirements can Thus, there may be caveats on the extent to which requirements can
be satisfied in such cases, yet strenuous effort should be made to be satisfied in such cases, yet strenuous effort should be made to
satisfy them, as such cases, e.g., firefighting in a national satisfy them, as such cases are important, e.g., firefighting in a nation
forest, are important. Each numbered requirement <em>a priori</em> al
forest. Each numbered requirement a priori
expected to suffer from such limitations (General requirements for expected to suffer from such limitations (General requirements for
Gateway and Contact functionality) contains language stating when Gateway and Contact functionality) contains language stating when
it applies. it applies.
</t> </t>
</section> </section>
<section anchor="Privacy" numbered="true" toc="default"> <section anchor="Privacy" numbered="true" toc="default">
<name>Privacy and Transparency Considerations</name> <name>Privacy and Transparency Considerations</name>
<t> <t>
Privacy and transparency are important for legal reasons including Privacy and transparency are important for legal reasons including
regulatory consistency. <xref target="EU2018" format="default"/> regulatory consistency. <xref target="EU2018" format="default"/>
states "harmonised and interoperable national registration states:</t>
systems... should comply with the applicable Union and national law <blockquote>
harmonised and interoperable national registration
systems ... should comply with the applicable Union and national law
on privacy and processing of personal data, and the information on privacy and processing of personal data, and the information
stored in those registration systems should be easily accessible.” stored in those registration systems should be easily accessible.
</t> </blockquote>
<t> <t>
Privacy and transparency (where essential to security or safety) Transparency (where essential to security or safety) and privacy
are also ethical and moral imperatives. Even in cases where old are also ethical and moral imperatives. Even in cases where old
practices (e.g., automobile registration plates) could be imitated, practices (e.g., automobile registration plates) could be imitated,
when new applications involving PII (such as UAS RID) are addressed when new applications involving PII (such as UAS RID) are addressed
and newer technologies could enable improving privacy, such and newer technologies could enable improving privacy, such
opportunities should not be squandered. Thus it is recommended that opportunities should not be squandered. Thus, it is recommended that
all DRIP work give due regard to <xref target="RFC6973" all DRIP work give due regard to <xref target="RFC6973"
format="default"/> and more broadly <xref target="RFC8280" format="default"/> and, more broadly, to <xref target="RFC8280"
format="default"/>. format="default"/>.
</t> </t>
<t> <t>
However, privacy and transparency are often conflicting goals, However, privacy and transparency are often conflicting goals,
demanding careful attention to their balance. demanding careful attention to their balance.
</t> </t>
<t> <t>
DRIP information falls into two classes: that which, to achieve the DRIP information falls into two classes:</t>
<ul spacing="normal" empty="false">
<li>that which, to achieve the
purpose, must be published openly as cleartext, for the benefit of purpose, must be published openly as cleartext, for the benefit of
any Observer (e.g., the basic UAS ID itself); and that which must any Observer (e.g., the basic UAS ID itself); and </li>
<li>that which must
be protected (e.g., PII of pilots) but made available to properly be protected (e.g., PII of pilots) but made available to properly
authorized parties (e.g., public safety personnel who urgently need authorized parties (e.g., public safety personnel who urgently need
to contact pilots in emergencies). to contact pilots in emergencies).</li>
</t> </ul>
<t> <t>
How properly authorized parties are authorized, authenticated, etc. How properly authorized parties are authorized, authenticated, etc.
are questions that extend beyond the scope of DRIP, but DRIP may be are questions that extend beyond the scope of DRIP, but DRIP may be
able to provide support for such processes. Classification of able to provide support for such processes. Classification of
information as public or private must be made explicit and information as public or private must be made explicit and
reflected with markings, design, etc. Classifying the information reflected with markings, design, etc. Classifying the information
will be addressed primarily in external standards; herein it will will be addressed primarily in external standards; in this document, it w ill
be regarded as a matter for CAA, registry, and operator policies, be regarded as a matter for CAA, registry, and operator policies,
for which enforcement mechanisms will be defined within the scope for which enforcement mechanisms will be defined within the scope
of DRIP WG and offered. Details of the protection mechanisms will of the DRIP WG and offered. Details of the protection mechanisms will
be provided in other DRIP documents. Mitigation of adversarial be provided in other DRIP documents. Mitigation of adversarial
correlation will also be addressed. correlation will also be addressed.
</t> </t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-drip-arch" to="drip-architecture"/> <displayreference target="I-D.ietf-drip-arch" to="DRIP-ARCH"/>
<displayreference target="I-D.ietf-raw-ldacs" to="LDACS"/>
<references> <name>References</name> <references> <name>References</name>
<references> <name>Normative References</name> <references> <name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
nce.RFC.2119.xml"/> C.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
nce.RFC.8174.xml"/> C.8174.xml"/>
<reference anchor="F3411-19" target="http://www.astm.org/cgi-bin/resolver .cgi?F3411"> <reference anchor="F3411-19" target="http://www.astm.org/cgi-bin/resolver .cgi?F3411">
<front> <front>
<title>Standard Specification for Remote ID and Tracking</title> <title>Standard Specification for Remote ID and Tracking</title>
<author> <author>
<organization>ASTM International</organization> <organization>ASTM International</organization>
</author> </author>
<date month="02" year="2020"/> <date month="02" year="2020"/>
</front> </front>
<seriesInfo name="ASTM" value="F3411-19"/>
<seriesInfo name="DOI" value="10.1520/F3411-19"/>
</reference> </reference>
</references> </references>
<references> <name>Informative References</name> <references> <name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
nce.RFC.4122.xml"/> C.4122.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
nce.RFC.4949.xml"/> C.4949.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
nce.RFC.6347.xml"/> C.6347.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
nce.RFC.6973.xml"/> C.6973.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
nce.RFC.7401.xml"/> C.7401.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
nce.RFC.8280.xml"/> C.8280.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
nce.RFC.9063.xml"/> C.9063.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refer
ence.I-D.ietf-drip-arch.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refer
ence.I-D.ietf-raw-ldacs.xml"/>
<reference anchor="Amended" target="https://eur-lex.europa.eu/legal-conte <!-- [I-D.ietf-drip-arch] IESG state I-D Exists -->
nt/EN/TXT/?uri=CELEX%3A32020R1058">
<reference anchor='I-D.ietf-drip-arch'>
<front>
<title>Drone Remote Identification Protocol (DRIP) Architecture</title>
<author initials='S' surname='Card' fullname='Stuart Card'>
<organization />
</author>
<author initials='A' surname='Wiethuechter' fullname='Adam Wiethuechter'>
<organization />
</author>
<author initials='R' surname='Moskowitz' fullname='Robert Moskowitz'>
<organization />
</author>
<author initials='S' surname='Zhao' fullname='Shuai Zhao' role="editor">
<organization />
</author>
<author initials='A' surname='Gurtov' fullname='Andrei Gurtov'>
<organization />
</author>
<date year='2022' month='January' day="28" />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-drip-arch-20'/>
</reference>
<!-- [I-D.ietf-raw-ldacs] IESG state Publication Requested -->
<reference anchor='I-D.ietf-raw-ldacs'>
<front>
<title>L-band Digital Aeronautical Communications System (LDACS)</title>
<author initials='N' surname='Maeurer' fullname='Nils Maeurer' role="editor">
<organization />
</author>
<author initials='T' surname='Graeupl' fullname='Thomas Graeupl' role="editor">
<organization />
</author>
<author initials='C' surname='Schmitt' fullname='Corinna Schmitt' role="editor">
<organization />
</author>
<date year='2021' month='October' day="22" />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-raw-ldacs-09'/>
</reference>
<reference anchor="Amended" target="https://eur-lex.europa.eu/eli/reg_del
/2020/1058/oj">
<front> <front>
<title>Commission Delegated Regulation (EU) 2020/1058 of 27 April 2020 amending Delegated Regulation (EU) 2019/945</title> <title>Commission Delegated Regulation (EU) 2020/1058 of 27 April 2020 amending Delegated Regulation (EU) 2019/945 as regards the introduction of two new unmanned aircraft systems classes</title>
<author> <author>
<organization>European Union Aviation Safety Agency (EASA )</organization> <organization>European Parliament and Council</organizati on>
</author> </author>
<date month="04" year="2020"/> <date month="04" year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="ASDRI" target="https://asd-stan.org/wp-content/uploads /ASD-STAN_DRI_Introduction_to_the_European_digital_RID_UAS_Standard.pdf"> <reference anchor="ASDRI" target="https://asd-stan.org/wp-content/uploads /ASD-STAN_DRI_Introduction_to_the_European_digital_RID_UAS_Standard.pdf">
<front> <front>
<title>Introduction to the European UAS Digital Remote ID Technic al Standard</title> <title>Introduction to the European UAS Digital Remote ID Technic al Standard</title>
<author> <author>
<organization> ASD-STAN </organization> <organization> ASD-STAN </organization>
</author> </author>
<date month="01" year="2021"/> <date month="01" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="ASDSTAN4709-002" target="https://asd-stan.org/download
s/asd-stan-pren-4709-002-p1/">
<front>
<title>Aerospace series - Unmanned Aircraft Systems - Part 002: D
irect Remote Identification</title>
<author>
<organization>ASD-STAN</organization>
</author>
<date month="10" year="2021"/>
</front>
<seriesInfo name="ASD-STAN prEN" value="4709-002 P1"/>
<refcontent></refcontent>
</reference>
<reference anchor="CPDLC" target="https://www.mdpi.com/1424-8220/18/5/16 36"> <reference anchor="CPDLC" target="https://www.mdpi.com/1424-8220/18/5/16 36">
<front> <front>
<title>Controller-Pilot Data Link Communication Security</title> <title>Controller-Pilot Data Link Communication Security</title>
<author initials = "A." surname = "Gurtov"> <organization /> < /author> <author initials = "A." surname = "Gurtov"> <organization /> < /author>
<author initials = "T." surname = "Polishchuk"> <organization /> </author> <author initials = "T." surname = "Polishchuk"> <organization /> </author>
<author initials = "M." surname = "Wernberg"> <organization /> </author> <author initials = "M." surname = "Wernberg"> <organization /> </author>
<date month="" year="2018" /> <date month="" year="2018" />
</front> </front>
<seriesInfo name="MDPI Sensors" value="18(5), 1636"/> <seriesInfo name="DOI" value="10.3390/s18051636"/>
<refcontent>Sensors 18, no. 5: 1636</refcontent>
</reference> </reference>
<reference anchor="CTA2063A" target="https://shop.cta.tech/products/small -unmanned-aerial-systems-serial-numbers"> <reference anchor="CTA2063A" target="https://shop.cta.tech/products/small -unmanned-aerial-systems-serial-numbers">
<front> <front>
<title>Small Unmanned Aerial Systems Serial Numbers</title> <title>Small Unmanned Aerial Systems Serial Numbers</title>
<author> <author>
<organization>ANSI</organization> <organization>ANSI</organization>
</author> </author>
<date month="09" year="2019"/> <date month="09" year="2019"/>
</front> </front>
<seriesInfo name="ANSI/CTA" value="2063-A"/>
</reference> </reference>
<reference anchor="Delegated" target="https://eur-lex.europa.eu/eli/reg_d el/2019/945/oj"> <reference anchor="Delegated" target="https://eur-lex.europa.eu/eli/reg_d el/2019/945/oj">
<front> <front>
<title>Commission Delegated Regulation (EU) 2019/945 of 12 March 2019 on unmanned aircraft systems and on third-country operators of unmanned air craft systems</title> <title>Commission Delegated Regulation (EU) 2019/945 of 12 March 2019 on unmanned aircraft systems and on third-country operators of unmanned air craft systems</title>
<author> <author>
<organization>European Union Aviation Safety Agency (EASA )</organization> <organization>European Parliament and Council</organizati on>
</author> </author>
<date month="03" year="2019"/> <date month="03" year="2019"/>
</front> </front>
</reference> </reference>
<reference anchor="ENISACSIRT" target="https://www.enisa.europa.eu/topics
/csirt-cert-services/reactive-services/copy_of_actionable-information"> <reference anchor="ENISACSIRT" target="https://www.enisa.europa.eu/topics
/csirt-cert-services/reactive-services/copy_of_actionable-information/actionable
-information">
<front> <front>
<title>Actionable information for Security Incident Response</tit le> <title>Actionable information for Security Incident Response</tit le>
<author> <author>
<organization>European Union Agency for Cybersecurity (EN ISA)</organization> <organization>European Union Agency for Cybersecurity (EN ISA)</organization>
</author> </author>
<date month="11" year="2014"/> <date month="11" year="2014"/>
</front> </front>
</reference> </reference>
<reference anchor="EU2018" target="https://www.consilium.europa.eu/media/ 35805/easa-regulation-june-2018.pdf"> <reference anchor="EU2018" target="https://www.consilium.europa.eu/media/ 35805/easa-regulation-june-2018.pdf">
<front> <front>
<title>2015/0277 (COD) PE-CONS 2/18</title> <title>2015/0277 (COD) PE-CONS 2/18</title>
<author> <author>
<organization>European Parliament and Council</organizati on> <organization>European Parliament and Council</organizati on>
</author> </author>
<date month="02" year="2018"/> <date month="June" year="2018"/>
</front> </front>
</reference> </reference>
<reference anchor="FAACONOPS" target="https://www.faa.gov/uas/research_de velopment/traffic_management/media/UTM_ConOps_v2.pdf"> <reference anchor="FAACONOPS" target="https://www.faa.gov/uas/research_de velopment/traffic_management/media/UTM_ConOps_v2.pdf">
<front> <front>
<title>UTM Concept of Operations v2.0</title> <title>UTM Concept of Operations v2.0</title>
<author> <author>
<organization>FAA Office of NextGen</organization> <organization>FAA Office of NextGen</organization>
</author> </author>
<date month="03" year="2020"/> <date month="03" year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="FR24" target="https://www.flightradar24.com/about"> <reference anchor="FR24" target="https://www.flightradar24.com/about">
<front> <front>
<title>Flightradar24 Live Air Traffic</title> <title>About Flightradar24</title>
<author> <author>
<organization>Flightradar24 AB</organization> <organization>Flightradar24</organization>
</author> </author>
<date month="05" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="FRUR" target="https://www.federalregister.gov/document s/2021/01/15/2020-28948/remote-identification-of-unmanned-aircraft"> <reference anchor="FRUR" target="https://www.federalregister.gov/document s/2021/01/15/2020-28948/remote-identification-of-unmanned-aircraft">
<front> <front>
<title>Remote Identification of Unmanned Aircraft</title> <title>Remote Identification of Unmanned Aircraft</title>
<author> <author>
<organization>Federal Aviation Administration</organizati on> <organization>Federal Aviation Administration (FAA)</orga nization>
</author> </author>
<date month="01" year="2021"/> <date month="01" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="GDPR" target="https://eur-lex.europa.eu/eli/reg/2016/6 79/oj"> <reference anchor="GDPR" target="https://eur-lex.europa.eu/eli/reg/2016/6 79/oj">
<front> <front>
<title>General Data Protection Regulation</title> <title>Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard t o the processing of personal data and on the free movement of such data, and rep ealing Directive 95/46/EC (General Data Protection Regulation)</title>
<author> <author>
<organization>European Parliament and Council</organizati on> <organization>European Parliament and Council</organizati on>
</author> </author>
<date month="04" year="2016"/> <date month="04" year="2016"/>
</front> </front>
</reference> </reference>
<reference anchor="ICAOATM" target="https://store.icao.int/en/procedures- for-air-navigation-services-air-traffic-management-doc-4444"> <reference anchor="ICAOATM" target="https://store.icao.int/en/procedures- for-air-navigation-services-air-traffic-management-doc-4444">
<front> <front>
<title>Doc 4444: Procedures for Air Navigation Services: Air Traf fic Management</title> <author> <title>Procedures for Air Navigation Services: Air Traffic Manage ment</title> <author>
<organization>International Civil Aviation Organization</ organization> <organization>International Civil Aviation Organization</ organization>
</author> </author>
<date month="11" year="2016"/> <date month="11" year="2016"/>
</front> </front>
<seriesInfo name="Doc" value="4444"/>
</reference> </reference>
<reference anchor="ICAODEFS" target="https://www.icao.int/safety/cargosaf ety/Documents/Draft%20Glossary%20of%20terms.docx"> <reference anchor="ICAODEFS" target="https://www.icao.int/safety/cargosaf ety/Documents/Draft%20Glossary%20of%20terms.docx">
<front> <front>
<title>Defined terms from the Annexes to the Chicago Convention a nd ICAO guidance material</title> <author> <title>Defined terms from the Annexes to the Chicago Convention a nd ICAO guidance material</title> <author>
<organization>International Civil Aviation Organization</ organization> <organization>International Civil Aviation Organization</ organization>
</author> </author>
<date month="07" year="2017"/> <date month="07" year="2017"/>
</front> </front>
</reference> </reference>
<reference anchor="ICAOUAS" target="https://www.icao.int/meetings/uas/doc uments/circular%20328_en.pdf"> <reference anchor="ICAOUAS" target="https://www.icao.int/meetings/uas/doc uments/circular%20328_en.pdf">
<front> <front>
<title>Circular 328: Unmanned Aircraft Systems</title> <author> <title>Unmanned Aircraft Systems</title> <author>
<organization>International Civil Aviation Organization</ organization> <organization>International Civil Aviation Organization</ organization>
</author> </author>
<date month="02" year="2011"/> <date year="2011"/>
</front> </front>
<seriesInfo name="Circular" value="328"/>
</reference> </reference>
<reference anchor="ICAOUTM" target="https://www.icao.int/safety/UA/Docume nts/UTM%20Framework%20Edition%203.pdf"> <reference anchor="ICAOUTM" target="https://www.icao.int/safety/UA/Docume nts/UTM%20Framework%20Edition%203.pdf">
<front> <front>
<title>Unmanned Aircraft Systems Traffic Management (UTM) - A Com mon Framework with Core Principles for Global Harmonization, Edition 3</title> < author> <title>Unmanned Aircraft Systems Traffic Management (UTM) - A Com mon Framework with Core Principles for Global Harmonization, Edition 3</title> < author>
<organization>International Civil Aviation Organization</ organization> <organization>International Civil Aviation Organization</ organization>
</author> </author>
<date month="10" year="2020"/> <date month="10" year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="Implementing" target="https://eur-lex.europa.eu/eli/re g_impl/2019/947/oj"> <reference anchor="Implementing" target="https://eur-lex.europa.eu/eli/re g_impl/2019/947/oj">
<front> <front>
<title>Commission Implementing Regulation (EU) 2019/947 of 24 May 2019 on the rules and procedures for the operation of unmanned aircraft</title> <title>Commission Implementing Regulation (EU) 2019/947 of 24 May 2019 on the rules and procedures for the operation of unmanned aircraft</title>
<author> <author>
<organization>European Union Aviation Safety Agency (EASA )</organization> <organization>European Parliament and Council</organizati on>
</author> </author>
<date month="05" year="2019"/> <date month="05" year="2019"/>
</front> </front>
</reference> </reference>
<reference anchor="InitialView" target="https://www.sesarju.eu/sites/defa ult/files/documents/u-space/SESAR%20principles%20for%20U-space%20architecture.pd f"> <reference anchor="InitialView" target="https://www.sesarju.eu/sites/defa ult/files/documents/u-space/SESAR%20principles%20for%20U-space%20architecture.pd f">
<front> <front>
<title>Initial view on Principles for the U-space architecture</t itle> <title>Initial view on Principles for the U-space architecture</t itle>
<author> <author>
<organization>SESAR Joint Undertaking</organization> <organization>SESAR Joint Undertaking</organization>
</author> </author>
<date month="07" year="2019"/> <date month="07" year="2019"/>
</front> </front>
</reference> </reference>
<reference anchor="NPRM" target="https://www.federalregister.gov/document s/2019/12/31/2019-28100/remote-identification-of-unmanned-aircraft-systems"> <reference anchor="NPRM" target="https://www.federalregister.gov/document s/2019/12/31/2019-28100/remote-identification-of-unmanned-aircraft-systems">
<front> <front>
<title>Notice of Proposed Rule Making on Remote Identification of Unmanned Aircraft Systems</title> <title>Notice of Proposed Rule Making on Remote Identification of Unmanned Aircraft Systems</title>
<author> <author>
<organization>United States Federal Aviation Administrati on (FAA)</organization> <organization>United States Federal Aviation Administrati on (FAA)</organization>
</author> </author>
<date month="12" year="2019"/> <date month="12" year="2019"/>
</front> </front>
</reference> </reference>
<reference anchor="OpenDroneID" target="https://github.com/opendroneid/sp ecs"> <reference anchor="OpenDroneID" target="https://github.com/opendroneid/sp ecs">
<front> <front>
<title>Open Drone ID</title> <title>The Open Drone ID specification</title>
<author> <author>
<organization>Intel Corp.</organization> <organization></organization>
</author> </author>
<date month="03" year="2019"/> <date month="03" year="2020"/>
</front> </front>
<seriesInfo name="commit" value="c4c8bb8"/>
</reference> </reference>
<reference anchor="OpenSky" target="https://opensky-network.org/about/abo ut-us"> <reference anchor="OpenSky" target="https://opensky-network.org/about/abo ut-us">
<front> <front>
<title>The OpenSky Network</title> <title>About the OpenSky Network</title>
<author> <author>
<organization>OpenSky Network non-profit association</org anization> <organization>OpenSky Network</organization>
</author> </author>
<date month="05" year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="Opinion1" target="https://www.easa.europa.eu/document- library/opinions/opinion-012020"> <reference anchor="Opinion1" target="https://www.easa.europa.eu/document- library/opinions/opinion-012020">
<front> <front>
<title>Opinion No 01/2020: High-level regulatory framework for th e U-space</title> <title>High-level regulatory framework for the U-space</title>
<author> <author>
<organization>European Union Aviation Safety Agency (EASA )</organization> <organization>European Union Aviation Safety Agency (EASA )</organization>
</author> </author>
<date month="03" year="2020"/> <date month="03" year="2020"/>
</front> </front>
<seriesInfo name="Opinion" value="No 01/2020"/>
</reference> </reference>
<reference anchor="Part107" target="https://www.ecfr.gov/cgi-bin/text-idx ?node=pt14.2.107"> <reference anchor="Part107" target="https://www.ecfr.gov/cgi-bin/text-idx ?node=pt14.2.107">
<front> <front>
<title>Code of Federal Regulations Part 107</title> <title>Part 107 - SMALL UNMANNED AIRCRAFT SYSTEMS</title>
<author> <author>
<organization>United States Federal Aviation Administrati on</organization> <organization>Code of Federal Regulations</organization>
</author> </author>
<date month="06" year="2016"/> <date month="06" year="2016"/>
</front> </front>
</reference> </reference>
<reference anchor="Recommendations" target="https://www.faa.gov/regulatio ns_policies/rulemaking/committees/documents/media/UAS%20ID%20ARC%20Final%20Repor t%20with%20Appendices.pdf"> <reference anchor="Recommendations" target="https://www.faa.gov/regulatio ns_policies/rulemaking/committees/documents/media/UAS%20ID%20ARC%20Final%20Repor t%20with%20Appendices.pdf">
<front> <front>
<title>UAS ID and Tracking ARC Recommendations Final Report</titl <title>UAS Identification and Tracking (UAS ID) Aviation
e> Rulemaking Committee (ARC): ARC Recommendations Final Report
</title>
<author> <author>
<organization>FAA UAS Identification and Tracking Aviatio n Rulemaking Committee</organization> <organization>FAA UAS Identification and Tracking (UAS ID ) Aviation Rulemaking Committee (ARC)</organization>
</author> </author>
<date month="09" year="2017"/> <date month="09" year="2017"/>
</front> </front>
</reference> </reference>
<reference anchor="Roadmap" target="https://share.ansi.org/Shared Documen ts/Standards Activities/UASSC/UASSC_20-001_WORKING_DRAFT_ANSI_UASSC_Roadmap_v2.p df"> <reference anchor="Roadmap" target="https://share.ansi.org/Shared Documen ts/Standards Activities/UASSC/UASSC_20-001_WORKING_DRAFT_ANSI_UASSC_Roadmap_v2.p df">
<front> <front>
<title>Standardization Roadmap for Unmanned Aircraft Systems draf <title>Standardization Roadmap for Unmanned Aircraft Systems
t v2.0</title> </title>
<author> <author>
<organization>American National Standards Institute (ANSI ) Unmanned Aircraft Systems Standardization Collaborative (UASSC)</organization> <organization>ANSI Unmanned Aircraft Systems Standardizat ion Collaborative (UASSC)</organization>
</author> </author>
<date month="04" year="2020"/> <date month="04" year="2020"/>
</front> </front>
<refcontent>Working
Draft, Version 2.0</refcontent>
</reference> </reference>
<reference anchor="Stranger" target="">
<reference anchor="Stranger">
<front> <front>
<title>Stranger in a Strange Land</title> <title>Stranger in a Strange Land</title>
<author surname="Heinlein" initials="R.A."> <author surname="Heinlein" initials="R.">
</author> </author>
<date month="06" year="1961"/> <date month="06" year="1961"/>
</front> </front>
</reference> </reference>
<reference anchor="WG105" target=""> <reference anchor="WG105" target="">
<front> <front>
<title>WG-105 draft ED-282 Minimum Operational Performance Standa rds (MOPS) for Unmanned Aircraft System (UAS) Electronic Identification</title> <title>Minimum Operational Performance Standards (MOPS) for Unman ned Aircraft System (UAS) Electronic Identification</title>
<author> <author>
<organization>EUROCAE</organization> <organization>EUROCAE</organization>
</author> </author>
<date month="06" year="2020"/> <date month="06" year="2020"/>
</front> </front>
<refcontent>WG-105 SG-32 draft ED-282</refcontent>
</reference> </reference>
<reference anchor="WiFiNAN" target="https://www.wi-fi.org/downloads-regis
tered-guest/Wi-Fi_Aware_Specification_v3.2.pdf/29731"> <reference anchor="WiFiNAN" target="https://www.wi-fi.org/discover-wi-fi/
wi-fi-aware">
<front> <front>
<title>Wi-Fi Aware™ Specification Version 3.2</title> <title>Wi-Fi Aware</title>
<author> <author>
<organization>Wi-Fi Alliance</organization> <organization>Wi-Fi Alliance</organization>
</author> </author>
<date month="10" year="2020"/> <date month="10" year="2020"/>
</front> </front>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="Discussion" numbered="true" toc="default"> <name>Discussion and Limitations</name> <section anchor="Discussion" numbered="true" toc="default"> <name>Discussion and Limitations</name>
<t> <t>
This document is largely based on the process of one SDO, ASTM. This document is largely based on the process of one SDO -- ASTM.
Therefore, it is tailored to specific needs and data formats of Therefore, it is tailored to specific needs and data formats of ASTM's
this standard. Other organizations, for example in EU, do not "Standard Specification for Remote ID and Tracking" <xref
necessarily follow the same architecture. target="F3411-19" format="default"/>. Other organizations (for
example, in the EU) do not necessarily follow the same architecture.
</t> </t>
<t> <t>
The need for drone ID and operator privacy is an open discussion The need for drone ID and operator privacy is an open discussion
topic. For instance, in the ground vehicular domain each car topic. For instance, in the ground vehicular domain, each car
carries a publicly visible plate number. In some countries, for carries a publicly visible plate number. In some countries, for
nominal cost or even for free, anyone can resolve the identity and nominal cost or even for free, anyone can resolve the identity and
contact information of the owner. Civil commercial aviation and contact information of the owner. Civil commercial aviation and
maritime industries also have a tradition of broadcasting plane or maritime industries also have a tradition of broadcasting plane or
ship ID, coordinates, and even flight plans in plain text. ship ID, coordinates, and even flight plans in plaintext.
Community networks such as OpenSky <xref target="OpenSky" Community networks such as OpenSky <xref target="OpenSky"
format="default"/> and Flightradar24 <xref target="FR24" format="default"/> and Flightradar24 <xref target="FR24"
format="default"/> use this open information through ADS-B to format="default"/> use this open information through ADS-B to
deploy public services of flight tracking. Many researchers also deploy public services of flight tracking. Many researchers also
use these data to perform optimization of routes and airport use these data to perform optimization of routes and airport
operations. Such ID information should be integrity protected, but operations. Such ID information should be integrity protected, but
not necessarily confidential. not necessarily confidential.
</t> </t>
<t> <t>
In civil aviation, aircraft identity is broadcast by a device known In civil aviation, aircraft identity is broadcast by a device known
as transponder. It transmits a four octal digit squawk code, which as transponder. It transmits a four-octal digit squawk code, which
is assigned by a traffic controller to an airplane after approving is assigned by a traffic controller to an airplane after approving
a flight plan. There are several reserved codes such as 7600 which a flight plan. There are several reserved codes, such as 7600, that
indicate radio communication failure. The codes are unique in each indicate radio communication failure. The codes are unique in each
traffic area and can be re-assigned when entering another control traffic area and can be re-assigned when entering another control
area. The code is transmitted in plain text by the transponder and area. The code is transmitted in plaintext by the transponder and
also used for collision avoidance by a system known as Traffic also used for collision avoidance by a system known as Traffic
alert and Collision Avoidance System (TCAS). The system could be alert and Collision Avoidance System (TCAS). The system could be
used for UAS as well initially, but the code space is quite limited used for UAS as well initially, but the code space is quite limited
and likely to be exhausted soon. The number of UAS far exceeds the and likely to be exhausted soon. The number of UAS far exceeds the
number of civil airplanes in operation. number of civil airplanes in operation.
</t> </t>
<t> <t>
The ADS-B system is utilized in civil aviation for each “ADS-B Out” The ADS-B system is utilized in civil aviation for each "ADS-B Out"
equipped airplane to broadcast its ID, coordinates, and altitude equipped airplane to broadcast its ID, coordinates, and altitude
for other airplanes and ground control stations. If this system is for other airplanes and ground control stations. If this system is
adopted for drone IDs, it has additional benefit with backward adopted for drone IDs, it has additional benefit with backward
compatibility with civil aviation infrastructure; then, pilots and compatibility with civil aviation infrastructure; then, pilots and
dispatchers will be able to see UA on their control screens and dispatchers will be able to see UA on their control screens and
take those into account. If not, a gateway translation system take those into account. If not, a gateway translation system
between the proposed drone ID and civil aviation system should be between the proposed drone ID and civil aviation system should be
implemented. Again, system saturation due to large numbers of UAS implemented. Again, system saturation due to large numbers of UAS
is a concern. is a concern.
</t> </t>
<t> <t>
The Mode S transponders used in all TCAS and most ADS-B Out The Mode S transponders used in all TCAS and most "ADS-B Out"
installations are assigned an ICAO 24 bit "address" (arguably installations are assigned an ICAO 24-bit "address" (arguably
really an identifier rather than a locator) that is associated with really an identifier rather than a locator) that is associated with
the aircraft as part of its registration. In the US alone, well the aircraft as part of its registration. In the US alone, well
over 2^20 UAS are already flying; thus, a 24 bit space likely would over 2<sup>20</sup> UAS are already flying; thus, a 24-bit space likely w ould
be rapidly exhausted if used for UAS (other than large UAS flying be rapidly exhausted if used for UAS (other than large UAS flying
in controlled airspace, especially internationally, under rules in controlled airspace, especially internationally, under rules
other than those governing small UAS at low altitudes). other than those governing small UAS at low altitudes).
</t> </t>
<t> <t>
Wi-Fi and Bluetooth are two wireless technologies currently Wi-Fi and Bluetooth are two wireless technologies currently
recommended by ASTM specifications due to their widespread use and recommended by ASTM specifications due to their widespread use and
broadcast nature. However, those have limited range (max 100s of broadcast nature. However, those have limited range (max 100s of
meters) and may not reliably deliver UAS ID at high altitude or meters) and may not reliably deliver UAS ID at high altitude or
distance. Therefore, a study should be made of alternative distance. Therefore, a study should be made of alternative
technologies from the telecom domain (WiMAX / IEEE 802.16, 5G) or technologies from the telecom domain (e.g., WiMAX / IEEE 802.16, 5G) or
sensor networks (Sigfox, LoRa). Such transmission technologies can sensor networks (e.g., Sigfox, LoRa). Such transmission technologies can
impose additional restrictions on packet sizes and frequency of impose additional restrictions on packet sizes and frequency of
transmissions, but could provide better energy efficiency and transmissions but could provide better energy efficiency and
range. range.
</t> </t>
<t> <t>
In civil aviation, Controller-Pilot Data Link Communications In civil aviation, Controller-Pilot Data Link Communications
(CPDLC) is used to transmit command and control between the pilots (CPDLC) is used to transmit command and control between the pilots
and ATC. It could be considered for UAS as well due to long range and ATC. It could be considered for UAS as well due to long-range
and proven use despite its lack of security <xref target="CPDLC" and proven use despite its lack of security <xref target="CPDLC"
format="default"/>. format="default"/>.
</t> </t>
<t> <t>
L-band Digital Aeronautical Communications System (LDACS) is being L-band Digital Aeronautical Communications System (LDACS) is being
standardized by ICAO and IETF for use in future civil aviation standardized by ICAO and IETF for use in future civil aviation
<xref target="I-D.ietf-raw-ldacs" format="default"/>. It <xref target="I-D.ietf-raw-ldacs" format="default"/>. LDACS
provides secure communication, positioning, and control for aircraft provides secure communication, positioning, and control for aircraft
using a dedicated radio band. It should be analyzed as a potential using a dedicated radio band. It should be analyzed as a potential
provider for UAS RID as well. This will bring the benefit of a provider for UAS RID as well. This will bring the benefit of a
global integrated system creating a global airspace use global integrated system creating awareness of global airspace use.
awareness.
</t> </t>
</section> </section>
<section numbered="false" toc="default"> <name>Acknowledgments</name> <section numbered="false" toc="default"> <name>Acknowledgments</name>
<t> <t>
The work of the FAA's UAS Identification and Tracking (UAS ID) The work of the FAA's UAS Identification and Tracking
Aviation Rulemaking Committee (ARC) is the foundation of later ASTM Aviation Rulemaking Committee (ARC) is the foundation of later ASTM
<xref target="F3411-19" format="default"/> and IETF DRIP efforts. <xref target="F3411-19" format="default"/> and IETF DRIP efforts.
The work of Gabriel Cox, Intel Corp., and their Open Drone ID The work of <contact fullname="Gabriel Cox"/>, Intel Corp., and their Ope n Drone ID
collaborators opened UAS RID to a wider community. The work of ASTM collaborators opened UAS RID to a wider community. The work of ASTM
F38.02 in balancing the interests of diverse stakeholders is F38.02 in balancing the interests of diverse stakeholders is
essential to the necessary rapid and widespread deployment of UAS essential to the necessary rapid and widespread deployment of UAS
RID. IETF volunteers who have extensively reviewed or otherwise RID. IETF volunteers who have extensively reviewed or otherwise
contributed to this document include Amelia Andersdotter, Carsten contributed to this document include <contact fullname="Amelia Andersdott
Bormann, Toerless Eckert, Susan Hares, Mika Jarvenpaa, Alexandre er"/>, <contact fullname="Carsten
Petrescu, Saulo Da Silva and Shuai Zhao. Thanks to Linda Dunbar for Bormann"/>, <contact fullname="Toerless Eckert"/>, <contact fullname="Sus
the Secdir review, Nagendra Nainar for the Opsdir review and Suresh an Hares"/>, <contact fullname="Mika Jarvenpaa"/>, <contact fullname="Alexandre
Krishnan for the Gen-ART review. Thanks to IESG members Roman Petrescu"/>, <contact fullname="Saulo Da Silva"/>, and <contact fullname=
Danyliw, Erik Kline, Murray Kucherawy and Robert Wilton for helpful "Shuai Zhao"/>. Thanks to <contact fullname="Linda Dunbar"/> for
and positive comments. Thanks to chairs Daniel Migault and Mohamed the SECDIR review, <contact fullname="Nagendra Nainar"/> for the OPSDIR r
Boucadair for direction of our team of authors and editor, some of eview, and <contact fullname="Suresh
Krishnan"/> for the Gen-ART review. Thanks to IESG members <contact fulln
ame="Roman
Danyliw"/>, <contact fullname="Erik Kline"/>, <contact fullname="Murray K
ucherawy"/>, and <contact fullname="Robert Wilton"/> for helpful
and positive comments. Thanks to chairs <contact fullname="Daniel Migault
"/> and <contact fullname="Mohamed
Boucadair"/> for direction of our team of authors and editor, some of
whom are newcomers to writing IETF documents. Thanks especially to whom are newcomers to writing IETF documents. Thanks especially to
Internet Area Director Eric Vyncke for guidance and support. Internet Area Director <contact fullname="Éric Vyncke"/> for guidance and
support.
</t><t>This work was partly supported by the EU project AiRMOUR (enabling
sustainable air mobility in urban contexts via
emergency and medical services) under grant agreement no. 101006601.
</t> </t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 464 change blocks. 
838 lines changed or deleted 1170 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/