ASTM F3411-22a

This international standard was developed in accordance with internationally recognized principles on standardization established in the Decision on Principles for the
Development of International Standards, Guides and Recommendations issued by the World Trade Organization Technical Barriers to Trade (TBT) Committee.
Designation:F3411 −22a
Standard Specification for
Remote ID and Tracking
This standard is issued under the fixed designation F3411; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
NOTE—Subsection 5.4.3 and Table A3.3 were corrected, with other editorial changes made throughout, and the yeardate changed on
June 17, 2022.
1. Scope lance radar transponders, nor does it purport to solve ID needs
of UAS for all operations.
1.1 This specification covers the performance requirements
1.4.3 In particular, this specification does not purport to
for remote identification (Remote ID) of unmanned aircraft
address identification needs for UAS that are not participating
systems (UAS). Remote ID allows governmental and civil
in Remote ID or operators that purposefully circumvent
identification of UAS for safety, security, and compliance
Remote ID.
purposes. The objective is to increase UAS remote pilot
accountabilitybyremovinganonymitywhilepreservingopera- 1.5 The values stated in SI units are to be regarded as
tional privacy for remote pilots, businesses, and their custom- standard. The values given in parentheses after SI units are
ers. Remote ID is an enabler of enhanced operations such as provided for information only and are not considered standard.
beyond visual line of sight (BVLOS) operations as well as 1.5.1 Units of measurement included in this specification:
operations over people.
m meters
deg, ° degrees of latitude and longitude, compass direction
1.2 This specification defines message formats, transmis-
s seconds
sion methods, and minimum performance standards for two Hz Hertz (frequency)
dBm decibel-milliwatts (radio frequency power)
forms of Remote ID: broadcast and network. Broadcast Re-
ppm parts per million (radio frequency variation)
mote ID is based on the transmission of radio signals directly
µs microseconds
from a UAS to receivers in the UAS’s vicinity. Network
ms milliseconds
RemoteIDisbasedoncommunicationbymeansoftheinternet
1.6 Table of Contents:
from a network Remote ID service provider (Net-RID SP) that
Title Section
interfaces directly or indirectly with the UAS, or with other
Scope 1
Referenced Documents 2
sources in the case of intent-based network participants.
Terminology 3
1.3 This specification addresses the communications and
Remote ID and Network Interoperability Conceptual Overview 4
Performance Requirements 5
test requirements of broadcast or network Remote ID, or both,
TEST METHODS
in UAS and Net-RID SP systems.
Scope 6
Significance and Use 7
1.4 Applicability:
Hazards 8
1.4.1 This specification is applicable to UAS that operate at
Test Units 9
Procedure 10
very low level (VLL) airspace over diverse environments
Precision and Bias 11
including but not limited to rural, urban, networked, network
Product Marking 12
degraded, and network denied environments, regardless of
Packaging and Package Marking 13
Keywords 14
airspace class.
ANNEX A1—Broadcast Authentication Verifier Service Annex A1
1.4.2 This specification neither purports to address UAS
ANNEX A2—Network Remote ID Interoperability Requirements, Annex A2
operating with approval to use ADS-B or secondary surveil-
APIs, and Testing
ANNEX A3—Tables of Values Annex A3
ANNEX A4—USS-DSS and USS-USS OpenAPI YAML Annex A4
Description
This specification is under the jurisdiction of ASTM Committee F38 on
ANNEX A5—Number Registrar Management Policy Annex A5
UnmannedAircraftSystemsandisthedirectresponsibilityofSubcommitteeF38.02
APPENDIX X1—Performance Characteristics Appendix X1
on Flight Operations.
APPENDIX X2—List of Subcommittee Participants and Appendix X2
Current edition approved June 17, 2022. Published July 2022. Originally
Contributors
approved in 2019. Last previous edition approved in 2022 as F3411–22. DOI:
APPENDIX X3—Background Information Appendix X3
10.1520/F3411-22A.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
F3411−22a
1.7 This standard does not purport to address all of the WGS-84 World Geodetic System — 1984
safety concerns, if any, associated with its use. It is the
3. Terminology
responsibility of the user of this standard to establish appro-
priate safety, health, and environmental practices and deter- 3.1 This standard uses terminology contained within F3341,
mine the applicability of regulatory limitations prior to UAS Terminology Standard, and F3060,Aircraft Terminology
use. SomespecifichazardsstatementsaregiveninSection8on Standard.These terms are not duplicated within this document.
Hazards.
3.2 Unique and Common Terminology—Terminology used
1.8 This international standard was developed in accor-
in multiple standards is defined in F3341 and F3060. Termi-
dance with internationally recognized principles on standard-
nology that is unique to this specification is defined in 3.3.
ization established in the Decision on Principles for the
3.3 Definitions of Terms Specific to This Standard:
Development of International Standards, Guides and Recom-
3.3.1 authentication, n—the process or action of verifying
mendations issued by the World Trade Organization Technical
that the source of a Remote ID message is the originator of the
Barriers to Trade (TBT) Committee.
message.
3.3.2 broadcast, v—to transmit data to no specific destina-
2. Referenced Documents
tion or recipient; data can be received by anyone within
2.1 ASTM Standards:
broadcast range.
F3060 Terminology for Aircraft
3.3.3 broadcast UAS, n—a UAS that is equipped for and is
F3341 Terminology for Unmanned Aircraft Systems
actively broadcasting Remote ID data during an operation;
2.2 Other Standards:
being a broadcast UAS is not mutually exclusive with being a
ANSI/CTA-2063-A Small Unmanned Aerial Systems Serial
networked UAS.
Numbers
4,5 6
3.3.4 discovery, n—the process of determining the set of
Bluetooth Core Specification 5.0
USSs with which data exchange is required for some UTM
IEEE 802.11 Standard for Information technology--
function; discovery is accomplished by means of the discovery
Telecommunications and information exchange between
and synchronization service (DSS).
systems - Local and metropolitan area networks--Specific
3.3.5 DSS entity, n—a generic concept that refers to infor-
requirements - Part 11: Wireless LAN Medium
mation that can be discovered using the discovery and syn-
Access Control (MAC) and Physical Layer (PHY)
7,5
chronization service (DSS).
Specifications
3.3.5.1 Discussion—Entities are characterized by a 4-D
IEEE 1609.2 IEEE Standard for Wireless Access in Vehicu-
volumeofairspace(thatis,avolumedefinedin x, y, zplustime
lar Environments--Security Services for Applications and
limits). For Remote ID, the entity type is referred to as an
Management Messages
identification service area. Operations and constraints are
IETF RFC3339 Date andTime on the Internet:Timestamps
examples of other types of entities that are the subject of other
IETF RFC4122 A Universally Unique IDentifier (UUID)
UTM standards.
URN Namespace
IETF RFC8126 Guidelines for Writing an IANA Consider-
3.3.6 DSS pool, n—a synchronized set of DSS instances
ations Section in RFCs
where operations may be performed on any instance with the
11,5
Neighbor Awareness Networking Specification
same result, and information may be queried from any instance
FAAUTM ConOps v1.0 UnmannedAircraft System (UAS)
with the same result. A DSS region will often have a produc-
Traffic Management (UTM) Concept of Operations
tion DSS pool along with one or more test or staging DSS
pools.
3.3.7 DSS region, n—the geographic area supported by a
For referenced ASTM standards, visit the ASTM website, www.astm.org, or DSS pool.
contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM
3.3.8 dynamic data, n—data that changes over the duration
Standards volume information, refer to the standard’s Document Summary page on
the ASTM website. of the flight; for example, longitude and latitude.
Available fromAmerican National Standards Institute (ANSI), 25 W. 43rd St.,
3.3.9 Ground Control Station (GCS), n—the part of a UAS
4th Floor, New York, NY 10036, http://www.ansi.org.
thatremotelycontrolstheUA.Itmayormaynothavearemote
Used throughout the specification, Bluetooth is a registered trademark of
Bluetooth SIG, Inc., 5209 Lake Washington Blvd. NE, Suite 350, Kirkland, WA
pilot directly manipulating the controls.
98033.
5 3.3.10 identify—the result of the process to establish the
Other names and brands may be claimed as the property of others.
Available from https://www.bluetooth.com/specifications/archived- identity of a specific UAS that is traceable to the owner and
%20specifications/.
remote pilot.
Available from Institute of Electrical and Electronics Engineers, Inc. (IEEE),
3.3.11 intent-based network participant, n—a UAS for
445 Hoes Ln., Piscataway, NJ 08854-4141, https://standards.ieee.org/standard/802
_11-2016.html.
which the operator has reported an intended area (a volume of
Available from IETF Tools, https://tools.ietf.org/html/rfc3339.
Available from IETF Tools, https://tools.ietf.org/html/rfc4122.
Available from https://datatracker.ietf.org/doc/html/rfc8126. Available from International CivilAviation Organization (ICAO), 999 Robert-
Available from Wi-Fi Alliance, 10900-B Stonelake Boulevard, Suite 126, Bourassa Boulevard, Montréal, Quebec, Canada H3C 5H7, https://www.icao.int/
Austin, TX 78759, https://www.wi-fi.org/discover-wi-fi/wi-fi-aware. safety/pbn/Documentation/EUROCONTROL/
Available from https://utm.arc.nasa.gov/docs/2018-UTM-ConOps-v1.0.pdf. Eurocontrol%20WGS%2084%20Implementation%20Manual.pdf.
F3411−22a
airspace) and time for an operation through a Net-RID service compliance (for example, threshold values, test methods,
provider; such information is then reported through the net- oversight, and references to other standards). “Should” state-
work Remote ID infrastructure. Intent-based Remote ID par- ments also represent parameters that could be used in safety
ticipationisanoptionfornon-equippedUASorUASoperating evaluations, and could lead to development of future require-
in environments that preclude broadcast or network participa- ments. “May” statements are provided to clarify acceptability
tion. of a specific item or practice, and offer options for satisfying
requirements.
3.3.12 network Remote ID (Net-RID) service provider, n—a
logical entity denoting a UTM system or comparable UAS 3.3.22 static data, n—datathatremainsthesameordoesnot
flight management system that participates in network Remote change often over the duration of a flight (for example, Unique
ID and provides data for and about UAS it manages. ID); this is in contrast to dynamic data that may change more
frequently (such as longitude and latitude).
3.3.13 network Remote ID (Net-RID) display provider, n—a
logical entity that aggregates network Remote ID data from 3.3.23 UAS operation plan, n—a UAS operation plan is
potentially multiple Net-RID service providers and provides developed prior to the operation and should indicate the
the data to a display application (that is, an app or website); in
volume of airspace within which the operation is expected to
practice, it is expected that many USSs may be both Net-RID occur,thetimesandlocationsofthekeyeventsassociatedwith
display providers and Net-RID service providers, but stand-
the operation, including launch, recovery, and any other
alone Net-RID display providers are possible. information deemed important (for example, segmentation of
the operation trajectory by time).
3.3.14 network publishing, v—the act of transmitting data to
UTM ConOps v1.0
aninternetserviceorfederationofservices;clients,whetherair
traffic control (ATC), public safety officials, or possibly the
3.3.24 UAS registration ID, n—an identification number or
general public can access the data to obtain ID and tracking combination of letters and numbers assigned by a CAA or
information for UAS for which such data has been published.
authorized representative to a UAS; this is sometimes referred
to as a registration number (which may or may not contain
3.3.15 networked UAS, n—a UAS that during operations is
letters).
in electronic communication with a Net-RID service provider
(for example, by means of internet Wi-Fi, cellular, or 3.3.25 UAS service supplier (USS), n—USSs provide UTM
satellite, or other communications medium such as short burst
services to support the UAS community, to connect operators
data satellite communications). and other entities to enable information flow across the USS
network, and to promote shared situational awareness among
3.3.16 non-equipped UAS, n—in the context of Remote ID,
UTM participants. UTM ConOps v1.0
a UAS that is neither a networked nor broadcast UAS (for
example, a radio controlled model aircraft) and cannot directly
3.3.26 unique ID, n—a data element that can be traced to a
report its location or identity.
unique UAS and its operator.
3.3.17 operator, n—theindividualororganizationwhouses,
3.4 Acronyms and Abbreviations:
causes to use, or authorizes to use an aircraft for the purpose of
3.4.1 AES, n—advanced encryption standard
air navigation, including the piloting of an aircraft, with or
3.4.2 AGL, adj—above ground level
without the right of legal control (as owner, lessee, or
3.4.3 API, n—application programming interface
otherwise). F3060
3.4.4 ARC, n—aviation rulemaking committee
3.3.18 operator location, n—the geographic location of the
remote pilot in command of a UAS. 3.4.5 BVLOS, adj—beyond visual line of sight
3.3.19 position extrapolation, n—a capability of a Net-RID
3.4.6 C2, n—command and control
service provider to predict the location of a UAS based on a
3.4.7 CAA, n—Civil Aviation Authority
modeled 4-D trajectory derived from an intended UAS opera-
3.4.8 CONUS, n—contiguous United States
tion plan.
3.4.9 DAR, n—DSS airspace representation
3.3.20 registration, n—the process by which an owner/
3.4.10 DSS, n—discovery and synchronization service
operator (including contact information and other PII) and
aircraft (for example, make, model) are associated with an
3.4.11 EIRP, n—effective isotropic radiated power
assigned, unique identifier.
3.4.12 EMI, n—electromagnetic interference
3.3.21 shall, must versus should versus may—use of the
3.4.13 FAA, n—Federal Aviation Administration
word “shall” implies that a procedure or statement is manda-
3.4.14 GCS, n—ground control station
tory and must be followed to comply with this practice,
“should” implies recommended, and “may” implies optional at
3.4.15 Hz—Hertz (cycles per second)
the discretion of the supplier, manufacturer, or operator.
3.4.16 inHg—inch of mercury
3.3.21.1 Discussion—Since “shall” and “must” statements
3.4.17 km—kilometers
arerequirements,theyincludesufficientdetailneededtodefine
3.4.18 kts—knots (nautical miles per hour)
3.4.19 LAANC—low altitude authorization and notification
Used throughout the specification, Wi-Fi is a registered trademark of Wi-Fi
Alliance, 10900-B Stonelake Boulevard, Suite 126, Austin, TX 78759. capability
F3411−22a
3.4.20 LE—little endian (least significant byte first) 4. Remote ID and Network Interoperability Conceptual
Overview
3.4.21 LSB—least significant bit
3.4.22 LTA—lighter than air (for example, balloon or blimp) 4.1 This section provides a conceptual overview of Remote
ID as defined in this specification, explains the scope of the
3.4.23 m—meters
specification, and clarifies the differences between broadcast
3.4.24 m/s—meters per second
and network Remote ID. This overview does not address all
3.4.25 mb—millibars
nuances of the specification. The intention is to provide a
3.4.26 mm—millimeters contextual framework to understand the requirements con-
tained in this specification. No requirements are provided in
3.4.27 MAC—media access control
this section.
3.4.28 MPH—miles per hour
4.2 This section also provides an overview of the general
3.4.29 MSB, n—most significant bit
approach to interoperability between USSs for both Network
3.4.30 Net-RID, n—network Remote ID
Remote ID and other UTM-related services.
3.4.31 PHY, n—physical layer
4.3 Scope of Standard and Remote ID Components:
3.4.32 PII, n—personally identifiable information
4.3.1 Fig. 1 identifies the actors and interfaces between
3.4.33 PPM—parts per million
actors in the Remote ID environment.
3.4.34 Remote ID, n—remote identification
4.3.2 The scope of this specification is identified by the
3.4.35 TLS, n—transport layer security
contents of the dotted purple box in the center of the diagram.
3.4.36 UA, n—unmanned aircraft
4.4 Broadcast Remote ID:
3.4.37 UAS, n—unmanned aircraft system
4.4.1 Broadcast Remote ID is depicted in the upper, central
3.4.38 USS, n—UAS service supplier portion of Fig. 1 in blue. Equipment on participating UAS
continuouslytransmitRemoteIDdatausingoneofthetransmit
3.4.39 UTM, n—UAS traffic management
protocols in this specification (Bluetooth or Wi-Fi). It is
3.4.40 UUID, n—universally unique identifier based on
possible that additional transmit protocols may be added in the
RFC4122 (128 bit)
future as warranted by available technology. The initial tech-
3.4.41 VIP, n—very important person
nologies were selected for compatibility with commonly car-
3.4.42 VLL, adj—verylowlevel(airspace—generallybelow ried hand-held devices that have their own receiver antenna.
However,equipmenttoreceivethebroadcastdataisnotpartof
150 m (500 ft))
FIG. 1Remote ID Conceptual Overview
F3411−22a
the specification. Other implementations, such as receivers not 4.5.3 ForNetworkRemoteID,twoUSSrolesareidentified:
integrated with hand-held devices, are possible. NetworkRemoteID(Net-RID)ServiceProvidersandNet-RID
Display Providers. In practice, these roles can be fulfilled by a
4.4.2 Both Bluetooth and Wi-Fi continuously broadcast
single USS and potentially one that also provides flight
messages to advertise the presence of the associated device.
These advertisements normally allow other devices to discover planning and deconfliction, LAANC, or other UTM services,
or combinations thereof. However, they are identified sepa-
and establish connections with the associated device, but the
advertisements themselves can carry a payload. These adver- rately to provide flexibility for industry participants to pursue
their preferred business objectives and implementation scope.
tisements contain the broadcast Remote ID data. A hand-held
device does not need to establish a connection to receive This architecture supports one or more Net-RID Service
Providers and one or more Net-RID Display Providers.
Remote ID data, instead it need only receive and process the
advertisements.
4.5.4 Net-RID Service Providers nominally remain in con-
4.4.3 Broadcast Remote ID can be used anywhere, but is
tact with UAS during flight and receive information (for
necessary in areas where network coverage is unreliable,
example, position updates) used to fulfill requests from Net-
disrupted, or not available.
RID Display Providers. For Network Remote ID, some re-
4.4.4 The specification also includes a range of options for quired data (for example, the UAS ID) may be retained by the
authenticationofbroadcastdata.Someofthoseoptionsinclude
Net-RID Service provider after UAS authentication and not
digital signatures over portions or all of the Remote ID transmitted continuously from the UAS. As this specification
message set. While the specification does not specify the
does not specify the details of the UAS to Net-RID Service
encoding format associated with signatures, it does include a
provider interface, implementations are generally valid as long
standardAPI that would be used by a receiver of the broadcast
as complete and correct Remote ID data is obtained by
data(forexample,anapponasmartphone)tocontactaverifier
Net-RIDServiceProvidersatsomepointandmadeavailableto
with the signature data for a broadcast to determine message
Net-RID Display Providers.
validity. This is described in more detail in Annex A1,
4.5.5 Net-RID Service Providers may also have the ability
Broadcast Authentication Verifier Service.
to supply extrapolated position information for UAS that
intermittently lose network connectivity.
4.5 Network Remote ID:
4.5.1 Network Remote ID can be used when both UAS 4.5.6 Net-RID Display Providers fulfill a broker role be-
operations and end users of Remote ID display applications tween Remote ID Display Applications used by an end user
access the internet, typically by means of cellular network. and all Net-RID Service Providers that have flights in an area.
Cellular coverage tends to be higher in urban areas. When an end user display application requests Remote ID data
foranarea,theNet-RIDDisplayProviderservicingthedisplay
4.5.2 Network Remote ID is depicted in the lower, central
application determines what Net-RID Service Providers have
portion of Fig. 1 in orange and enclosed in a dashed line cloud.
operations in the area and then obtains appropriate Remote ID
The nominal case supports Networked UAS (that is, UAS that
remain in contact with a Remote ID Service Provider during data from each. The aggregated data is returned to the Remote
ID Display Application. The aggregated data includes both
flight either directly or through an intermediate device such as
a ground control station), although the specification accommo- current location and a window of near-real-time data for each
flight.
dates intermittent loss of network connectivity. Network Re-
mote ID also includes provisions for participation in Remote
4.5.7 Net-RIDDisplayProvidersensureRemoteIDDisplay
ID through intent-based preflight reporting, also referred to as
Applications can only access and view data within a limited
Intent-Based participation. This technique provides an alterna-
range and must dispose of aggregated data obtained from
tive for UAS that are non-equipped (that is, UAS that are
Net-RID Service Providers within a defined time period.
neither broadcast capable nor equipped to communicate with a
Limiting the range helps implementations satisfy performance
Remote ID Service Provider during flight, such as many
requirements in this specification by bounding the volume of
radio-controlledmodelaircraft)aswellasforUASthatmaybe
data that must be gathered, processed, and displayed. Limiting
equipped but are operating in an environment where participa-
the range (that is, only accessing required data) and disposing
tion in either broadcast or network Remote ID is infeasible due
of such data when no longer needed helps protect privacy and
to the presence of electromagnetic interference (for example,
sensitive data of consumers and operators.
an inspection inside an electrical tower) or radio signal
4.5.8 For a UAS to be included in response to queries for
blocking material (for example, areas under a bridge shielded
Remote ID data, it must either be within the requested area at
by thick concrete or inside a tunnel). Intent-based participants
the time of the request or recently therein (that is, within a
report their operations (for example, aircraft ID, location in
small window of time such as a minute). This specification
termsofavolumeofairspace,operatingtimes)inadvance.The
does not provide remote identification data for UAS that are
information is used to create a position report for use by
projected to be within an area in the future.
Remote ID display applications where the uncertainty of the
4.5.9 Industry-standard encryption and authentication are
position report is defined by the airspace volume for the
required from the UAS or the operator of an intent-based
operation. The current telemetry of the aircraft within the
network participant to the Net-RID Service and from the
volume is not known and cannot be displayed to a Remote ID
Net-RID Service Providers to Net-RID Display providers.
end user, but the display application can display the volume
and provide the identity of the UAS. 4.6 Remote ID Display Applications:
F3411−22a
4.6.1 Receivers and Remote ID Display Applications are 4.7.2.1 The broadcast UAS transmits Remote ID data using
shown on the right side of Fig. 1. A typical implementation one of the methods described in 5.4. The UAS is controlled
would be a smartphone or tablet with an internal receiver for locally by the Remote Pilot and has no interface with a USS.
Bluetooth and Wi-Fi, but other implementations are possible. 4.7.2.2 The networked UAS is operated under USS1. This
The display applications ingest Broadcast Remote ID data or
USS acts as a Net-RID Service Provider and a Net-RID
interact with a Net-RID Display Provider, or both, to acquire Display Provider.
Network Remote ID data and present the information to end
4.7.2.3 The Remote Pilot of the model aircraft uses a
users.
smartphone app to report the location and time of the
4.6.2 A typical user interface might be map-based with
operation, and provides the ID for the model aircraft. The
symbols for UAS in the area. However, the manner in which
smartphone app is the user interface that connects the user to a
the information is presented is beyond the scope of this
second Net-RID Service Provider, USS2.
specification and other implementations are possible.
4.7.3 The interested observer accesses a Remote ID Display
4.6.3 It is anticipated that Remote ID Display Applications
Application (RIDApp) that uses USS1 as its Net-RID Display
that integrate Broadcast and Network Remote ID data will be
Provider. This display application shows UAS locations and a
producedbyindustry;however,thisalsoisbeyondthescopeof
near-real-timetrailofpositionreportsonamap,andassociated
the specification.
identification information when a particular UA is selected.
4.6.4 From a network Remote ID perspective, this specifi-
4.7.4 When the interested observer opens the Remote ID
cation levies performance requirements on Net-RID Display
app on a smartphone and centers the map on the current
Providers in responding to requests from Remote ID Display
location, Remote ID data is acquired as follows:
Applications.
4.7.4.1 The broadcast UAS is transmitting its Remote ID
advertisements continuously. The smartphone uses its internal
4.7 Representative Remote ID Scenario:
4.7.1 Fig. 2 depicts a representative Remote ID scenario. radios to listen for the advertisements from the UAS, extract
the Remote ID data, and show the location of the UA on the
Thetextthatfollowsdescribestheflowofinformationamongst
the Remote ID components introduced above. map. As new position updates are received, the prior position
reportsbecomepartofanear-real-timetrailrepresentingwhere
4.7.2 Three UAS are simultaneously operating in close
the UA most recently flew.
proximity (within 1 km) to each other: one is broadcasting
Remote ID data, one is networked, and one is a model aircraft 4.7.4.2 Simultaneously, the DisplayApp makes a request to
withnobroadcastornetworkcapability.Aninterestedobserver itsNet-RIDDisplayProvider,USS1.USS1’sroleasaNet-RID
wants to identify the three UAS. Display Provider is to aggregate Remote ID data for all flights
FIG. 2Representative Remote ID Scenario
F3411−22a
in the area managed by Net-RID Service Providers. USS1 4.7.4.8 The interested observer closes the app. After a
knows that it is a Net-RID Service Provider and has flights in period of time, USS1 discards the information for the Intent-
the area. BasedNetworkParticipantbecauseitismanagedbyadifferent
4.7.4.3 USS1 additionally discovers USS2, which has no USS (USS2).
real-time-managed flights in the area, but has an operation
4.8 USS Interoperability:
reported for the model aircraft (that is, the Intent-Based
4.8.1 This specification assumes that UTM services in a
Network Participant).The Remote Pilot of the radio-controlled
given location are provided by a set of one or more UAS
model aircraft reports the operation to USS2 prior to the flight
Service Suppliers (USSs). USSs must be interoperable in this
and no dynamic position updates are provided. USS2 provides
environment, sharing data as necessary to accomplish the
the information for this operation back to USS1.
objective of a particular service such as Network Remote ID or
4.7.4.4 USS1 adds the Remote ID data for the networked
flight plan exchange for strategic deconfliction.
UASthatitismanaging(fulfillingitsroleasaNet-RIDService
4.8.2 The interoperability paradigm defined in this specifi-
Provider) and provides the aggregated data back to the Display
cation is intended to support both Network Remote ID and
Application (fulfilling its role as a Net-RID Display Provider).
otherservicesthatmaybeincludedinsubsequentUTM-related
4.7.4.5 The display app adds the network data to the map
ASTM standards. The requirements and application program-
that is already showing the broadcast information. The Net-
ming interfaces (APIs) associated with the interoperability
workedUASisshownwithuptoa60 strailofpositionreports
paradigm are included in this document because it is the first
(referred to as near-real-time data). The Intent-Based Network
UTM-related ASTM standard. Subsequent UTM-related
Participant is shown as a polygon.
ASTM standards may introduce additional service-specific
4.7.4.6 As long as the interested observer continues to view
interoperability requirements and API functions. Some of the
the Remote ID display app for the area, the app continues to
interoperabilityrequirementsandAPIsmaymovetoadifferent
communicate with USS1 as its Net-RID Display Provider to
standard in the future.
obtain position updates. Since the information for the Intent-
4.8.3 The interoperability paradigm consists of two parts:
Based network participant does not update, no additional
4.8.3.1 A standardized discovery mechanism, referred to as
updates are provided for it from USS2. USS1 continues to
the Discovery and Synchronization Service (DSS), the primary
provide position updates for the Networked UAS in its role as
functions of which are to identify USSs with which data
the Net-RID Service Provider.
exchange is required, and to verify that a USS considered
4.7.4.7 The interested observer selects the UA symbols for
relevant information from other USSs when necessary (for
the Broadcast UAS and the Networked UAS on the map and
example, when planning a new operation); and,
views the corresponding ID information. The interested ob-
server then selects the polygon for the Intent-Based Network 4.8.3.2 Service-specific data exchange protocols used to
Participant and sees the operation schedule and the ID of the obtain the details of relevant information discovered by means
of the DSS from the owning USS.
aircraft.
FIG. 3USS Interoperability Overview
F3411−22a
4.8.4 Fig. 3 illustrates the interactions involved in this 4.8.10.3 Get Details—Given the list of discovered entities,
paradigm in a service-independent manner. (The instantiation the requesting USS switches to the applicable Data Exchange
of this paradigm for Remote ID is detailed later.) Protocol to contact the owning USS and obtain the complete
details. Data Exchange Protocols are service-specific.
4.8.5 DSS-related interactions are shown at the top in the
4.8.10.4 Subscription Notifications—If the requesting USS
blue-shaded area; data exchange protocols between USSs are
established a subscription in the DSS (for a 4-D area of
represented by the green-shaded area.
interest),whenanotherUSSwritesanewentitytotheDSSthat
4.8.6 For availability purposes, the DSS is a redundant
intersectsthesubscription,theDSSinformsthewritingUSSof
service as indicated in Fig. 3. Instances of the DSS in a region
the subscription and the writing USS contacts the subscribing
synchronize with each other in a standardized manner (de-
USS to provide the details. (This is often described as a push
scribed later in this specification). A region is the geographic
of the information.)
scope supported by a set of DSS instances.
4.8.11 While not needed for Remote ID, OVNs come into
4.8.7 Only approved USSs will be given access to the DSS.
play on interaction if the entity written to the DSS is of a type
(The specifics of an approval process are beyond the scope of
that requires deconfliction with other entities (for example, a
this specification.)
new UAS operation requires deconfliction; a constraint does
4.8.8 An instance of discoverable information is referred to
not). When writing the new operation to the DSS, the USS
as an entity. There are different types of entities, such as
must provide the OVNs for all other operations and constraints
operations,constraints,or,relevanttothisspecification,anarea
in the area of the new operation. For applicable entity types,
where network remote identification services are being pro-
OVNs are part of the detailed information obtained from other
vided.TheconceptisextendabletofutureUTMserviceswhere
USSs in step 3. If the DSS determines the set of OVNs is
other types of entities may need to be discoverable. A key
completeandcurrent,itallowsthenewoperationtobewritten;
characteristic of entities is that they have an associated 4-D
if not, the DSS informs the writing USS what OVNs are
volume (that is, a volume defined in x, y, and z plus time
missing or obsolete.
limits).
4.8.12 Although complete details for entities are not stored
4.8.9 The DSS encapsulates an airspace model into which
in the DSS, it serves as the single source of truth for what
entities are mapped. The implementation details of this air-
entities exist in the airspace and provides the mechanism
space representation are hidden from DSS clients; however,
necessary to ensure that USSs attempting to create a new
conceptually, the airspace model can be thought of as a grid
operation have considered the current version of all other
and mapping an entity into the airspace model is determining
relevant entities in the airspace.
what grid cells the entity intersects.The complete details of the
4.8.13 Unless noted otherwise, references to the DSS
entities and any associated Personally Identifiable Information
throughout this specification refer to the set of DSS instances
(PII) are not stored in the DSS but instead are retained by the
supporting the region in which a related activity is occurring
owning USS; only limited information such as the type of
(for example, creating entity summaries, discovering entities).
entity, its location (in terms of what cells of the airspace model
4.8.14 This overview omits many details of the DSS and
it intersects), the current opaque version number (OVN) of the
data exchange protocols. The Remote ID-specific interoper-
entity(OVNsareupdatedwhenevertheentityismodified),and
ability requirements, completeAPIs, and additional details are
how to contact the owner of the entity are stored in the DSS.
provided in Annex A2.
4.8.10 Given that context, the primary interactions (num-
bered in Fig. 3) are:
5. Performance Requirements
4.8.10.1 Make Discoverable—A USS with an entity about
5.1 Remote ID is comprised of a set of standardized data,
which other USSs need to know (for example, an operation, a
messages, transport mechanisms for communicating the
constraint, an area where Remote ID services are provided)
messages, and performance requirements governing certain
makes it discoverable by writing the limited entity summary
attributes of an implementation such as message periodicity.
information (information type, identifier, location, owner) to
For Broadcast Remote ID, the message format is the same
the DSS.
regardless of the transport mechanism. These messages are
4.8.10.2 Discover—Other USSs that are interested in enti-
coded as a “block message” implementation of the Data
ties of some type query the DSS using a 4-D volume to
Dictionary to optimize for the transport mechanism size
characterize the area of interest. The DSS maps the query onto
constraints and to minimize potential broadcast interference.
theairspacerepresentationandfindsintersectinggridcellswith
For Network Remote ID, the message format is a network
entities of the desired type (if any). (Because entities are
adaption of the Data Dictionary using common internet proto-
mapped into grid cells and the DSS does not retain the precise
cols.Forbroadcastmessages,eachmessagehasamessagetype
extents,theDSSwilloccasionallyreturnanentitythatdoesnot
that is identified in the message header. The message type
intersectthepreciseareaofinterest;however,itwillneveromit
defines the message format and is classified as static or
an entity that intersects the area of interest.) The DSS then
dynamic, which also sets the requirements for the minimal rate
returns to the requesting USS a list of the discovered entities
at which each message type shall be transmitted. The common
andtheirowners.Thiscanbeaone-timequery(oftendescribed
name for this broadcast messaging protocol is “Open Drone
as a pull of the information) or the requesting USS can also
ID.”
establish a subscription to be notified of new or modified
entities in the area of interest (discussed further below). 5.2 Conventions used in this section:
F3411−22a
5.2.1 Requirement IDs are shown below. The prefix to each omni-directional pattern using commonly available compo-
ID identifies groupings: nents. This can be accomplished using either of the following
two options:
5.2.1.1 BURxxxx - Broadcast Update Rate
(a) The average Effective Isotropic Radiated Power (EIRP)
5.2.1.2 BMGxxxx - Broadcast Messages
around the horizontal plane of the antenna system shall be at
5.2.1.3 BB4xxxx - Broadcast Bluetooth 4
least [BcMinAvgEIRP] and the Peak to Average gain around
5.2.1.4 BB5xxxx - Broadcast Bluetooth 5
the horizontal plane of the antenna system shall be no more
5.2.1.5 BWFxxxx - Broadcast Wi-Fi
than [BcMaxPeakToAvg]. The average EIRP is calculated by
5.2.1.6 NETxxxx - Network
adding the conducted power into the antenna system to the
5.2.1.7 DSSxxxx - Discovery and Synchronization Service
average gain of the antenna system in the horizontal plane; or
(Annex A2)
(b) The minimum EIRP around the entire horizontal plane
5.2.2 Constantvaluesrepresentingarequiredtime,distance,
of the antenna system shall be at least [BcMinEIRP]. The
etc. are consolidated into Annex A3. These values are refer-
minimum EIRP is calculated by adding the conducted power
enced within the requirements text in this section using square
into the antenna system to the minimum gain of the antenna
brackets around the constant name. Constants pertaining to
system in the horizontal plane.
broadcast Remote ID are prefixed with “Bc” and constants
These options are intended to allow for use of manufacturer
pertaining to network Remote ID are prefixed with “Net” as
datasheetstodemonstratecompliance.TheHorizontalPlaneis
shown in the following examples:
defined as a plane of the transmission pattern that approxi-
5.2.2.1 [BcMinUasLocRefreshRate]
mately corresponds to the horizontal plane during the most
5.2.2.2 [NetMinUasLocRefreshRate]
common average orientation of the vehicle when flying. The
5.2.3 In some cases, notes to clarify the intent of a require-
UAS should be mechanically designed in a way to minimize
ment are provided. These notes are numbered and prefaced radio pattern distortion of Remote ID.
with “Note:.” They are for clarification purposes only and do
5.4.4 Update Rates:
not contain requirements.
5.4.4.1 For broadcast messages, dynamic messages (as in-
dicated in the block message section) shall (BUR0010) be sent
5.3 Common Data Dictionary:
at least every [BcMinUasLocRefreshRate] second(s). Static
5.3.1 Table 1 defines the required and optional data fields
messages (as indicated in the block message section) shall
forRemoteID,includingminimumcharacteristicsthatmustbe
(BUR0020) be sent at least every [BcMinStatic
supported by both network and broadcast implementations.
RefreshRate] second(s) and the maximum potential time
Since broadcast Remote ID uses size-limited messages, for
elapsed since the time of applicability of the dynamic fields in
some data fields it is necessary to use encoding methods that
the Location/Vector Message shall (BUR0030) be no older
adjust the resolution or aggregate ranges of values, whereas
than [BcMaxDataAge]. If a multi-sector antenna configuration
these size-limiting techniques are not necessary for network
isused,thentheseupdaterequirementsshallbeappliedtoeach
Remote ID. The required minimum characteristics provided
sector. Should channel saturation block or interfere with
below ensure a prescribed degree of consistency between
transmission (as may occur due to “listen before talk” interfer-
broadcast and network Remote ID to facilitate integration in a
ence handling technique), the system shall (BUR0040) make a
RemoteIDdisplayapplication.Thespecificrepresentationsfor
“best effort” to transmit when the saturation level allows.
broadcast and network Remote ID are provided in their
5.4.4.2 Counters—After each frame of the same message
respective requirements sections.
type is updated, the Message Counter (for that message type)
5.3.2 An asterisk (*) adjacent to a data field name denotes
shall (BUR0050) be incremented and reset to 0 after 0xFF is
an optional field. Optional fields and certain field options may
reached.Therefore, each message type (defined in Table 3) has
be required in some jurisdictions.
a separate counter. For Message Packs (message type 0xF),
5.4 Broadcast:
only 1 counter is maintained and updated each time any data
5.4.1 This section describes requirements for the RF broad-
within the message pack is updated. If the data being transmit-
cast of Remote ID messages from a participating UA. Four
ted has not changed, incrementing the Message Counter is
broadcast transport mechanisms are supported by this specifi-
optional. If a message is multi-paged (such as a multi-page
cation:
authentication message), then the Message Counter shall
5.4.1.1 Bluetooth Legacy (4.x compatible)
(BUR0060) be the same for each page in the page set.
5.4.1.2 Bluetooth 5.x Long Range (must be transmitted
5.4.5 Block Messages:
concurrently with Legacy mode)
5.4.5.1 The “Block” messages are designed to be packed
5.4.1.3 Wi-Fi Neighbor Awareness Network (NAN)
into lightweight direct broadcast packets within Wi-Fi or
5.4.1.4 Wi-Fi Beacon (vendor-specific information element Bluetooth “Beacon Advertisements.” The message types are
in the SSID beacon frame) identified in Table 3. Subsequent subsections further describe
each message type.
5.4.2 The four transport mechanisms share common re-
quirements for update rates and message definition. 5.4.5.2 Each message shall (BMG0010) be 25 bytes in
length (padded with nulls as needed).
5.4.3 Output Power and Pattern—For output power and
pattern, the requirement (BPW0010) seeks to provide a suffi- 5.4.5.3 Each message shall (BMG0020) begin with a 1 byte
ciently high power transmission that generally emits in an header followed by 24 bytes of data, which shall be encoded as
F3411−22a
TABLE 1 Common Data Dictionary
Data Field Description/Rationale
UAS ID Consists of four options:
1. Serial Number: This is expressed in the CTA-2063-A Serial Number format.
2. Registration ID: If a CAA provides a method of registering UAS, this number is provided by the CAA or its authorized
representative.
A
Format: ., ASCII encoded, only uppercase letters (A-Z), dot (.), and digits (0-9) are
allowed. Example (US): N.123456
3. UTM (UUID): A UTM-provided universally unique ID traceable to a non-obfuscated ID where this UTM UUID acts as a “session id”
to protect exposure of operationally sensitive information.
4. Specific Session ID: A unique 20 byte ID intended to identify a specific flight (session) while providing a greater level of privacy to
the operator. The first byte is the registered unique Specific Session ID Type maintained by a registrar (see Annex A5), and the
remaining 19 bytes is the Session ID in accordance with the Specific Session ID Type specification.
Initial scheme registry entries shall include:
0 – reserved;
1 – Internet Engineering Task Force (IETF) Drone Remote Id
...