CAAs worldwide are mandating UAS RID. The European Union Aviation Safety Agency (EASA) has published [Delegated
] and [Implementing
] regulations. The US FAA has published a "final" rule [FRUR
] and has described the key role that UAS RID plays in UAS Traffic Management (UTM) in [FAACONOPS
] (especially Section 2.6). At the time of writing, CAAs promulgate performance-based regulations that do not specify techniques but rather cite industry consensus technical standards as acceptable means of compliance.
The most widely cited such industry consensus technical standard for UAS RID is [F3411-19
], which defines two means of UAS RID:
Network RID defines a set of information for UAS to make available globally indirectly via the Internet, through servers that can be queried by Observers.
Broadcast RID defines a set of messages for UA to transmit locally directly one-way over Bluetooth or Wi-Fi (without IP or any other protocols between the data link and application layers), to be received in real time by local Observers.
UAS using both means must send the same UAS RID application-layer information via each [F3411-19
]. The presentation may differ, as Network RID defines a data dictionary, whereas Broadcast RID defines message formats (which carry items from that same data dictionary). The interval (or rate) at which it is sent may differ, as Network RID can accommodate Observer queries asynchronous to UAS updates (which generally need be sent only when information, such as location, changes), whereas Broadcast RID depends upon Observers receiving UA messages at the time they are transmitted.
Network RID depends upon Internet connectivity in several segments from the UAS to each Observer. Broadcast RID should need Internet (or other Wide Area Network) connectivity only to retrieve registry 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 encapsulated by the UA without IP
, directly in link-layer frames (Bluetooth 4, Bluetooth 5, Wi-Fi NAN, IEEE 802.11 Beacon, or perhaps others in the future).
] specifies three ID Type values, and its proposed revision (at the time of writing) adds a fourth:
A static, manufacturer-assigned, hardware serial number as defined in "Small Unmanned Aerial Systems Serial Numbers" [CTA2063A].
A CAA-assigned (generally static) ID, like the registration number of a manned aircraft.
A UTM-system-assigned Universally Unique Identifier (UUID) [RFC 4122], which can but need not be dynamic.
A Specific Session ID, of any of an 8-bit range of subtypes defined external to ASTM and registered with ICAO, for which subtype 1 has been reserved by ASTM for the DRIP entity ID.
], the EU allows only ID Type 1. Under [FRUR
], the US allows ID Type 1 and ID Type 3. [NPRM
] proposed that a "Session ID" would be "e.g., a randomly-generated alphanumeric code assigned by a Remote ID UAS Service Supplier (USS) on a per-flight basis designed to provide additional privacy to the operator", but given the omission of Network RID from [FRUR
], how this is to be assigned in the US is still to be determined.
As yet, there are apparently no CAA public proposals to use ID Type 2. In the preamble of [FRUR
], the FAA argues that registration numbers should not be sent in RID, insists that the capability of looking up registration numbers from information contained in RID should be restricted to FAA and other Government agencies, and implies that Session ID would be linked to the registration number only indirectly via the serial number in the registration database. The possibility of cryptographically blinding registration numbers, such that they can be revealed under specified circumstances, does not appear to be mentioned in applicable regulations or external technical standards.
], the EU also requires an operator registration number (an additional identifier distinct from the UAS ID) that can be carried in an [F3411-19
] optional Operator ID Message.
] allows RID requirements to be met either by the UA itself, which is then designated a "standard remote identification unmanned aircraft", or by an add-on "remote identification broadcast module". The requirements for a module are different than for a standard RID UA. The module:
must transmit its own serial number (neither the serial number of the UA to which it is attached, nor a Session ID),
must 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.
Jurisdictions may relax or waive RID requirements for certain operators and/or under certain conditions. For example, [FRUR
] allows operators with UAS not equipped for RID to conduct VLOS operations at counterintuitively named "FAA-Recognized Identification Areas (FRIAs)"; radio-controlled model aircraft flying clubs and other eligible organizations can apply to the FAA for such recognition of their operating areas.
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 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 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).
| UA | * Internet *
+--o-------o--+ * *
| | * *
| | * * +------------+
| '--------*--(+)-----------*-----o |
| * | * | |
| .--------*--(+)-----------*-----o Net-RID SP |
| | * * | |
| | * .------*-----o |
| | * | * +------------+
| | * | *
| | * | * +------------+
| | * '------*-----o |
| | * * | Net-RID DP |
| | * .------*-----o |
| | * | * +------------+
| | * | *
| | * | * +------------+
+--o-------o--+ * '------*-----o Observer's |
| GCS | * * | Device |
+-------------+ ****************** +------------+
Direct UA-Internet wireless links are expected to become more common, especially on larger UAS, but, at the time of writing, they are rare. Instead, the RID data flow typically originates on the UA and 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, 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. 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 BVLOS operations often will not).
Network RID is publish-subscribe-query. In the UTM context:
The UAS operator pushes an "operational intent" (the current 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 UAS#1) for that operation, primarily to enable deconfliction with other operations potentially impinging upon that operation's 4-D airspace volume (call it Volume#1).
Assuming the operation is approved and commences, UAS#1 periodically pushes location/status updates to USS#1, which serves inter alia as the Network RID Service Provider (Net-RID SP) for that operation.
When users of any other USS (whether they be other UAS operators or Observers) develop an interest in any 4-D airspace volume (e.g., because they wish to submit an operational intent or because they have observed a UA), they query their own USS on the volumes in which they are interested.
Their USS query, via the UTM 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 volumes intersecting them); thus, those USS whose query volumes intersect Volume#1 (call them USS#2 through USS#n) learn that USS#1 has such operations.
Interested parties can then subscribe to track updates on that operation of UAS#1, via their own USS, which serve as Network RID Display Providers (Net-RID DPs) for that operation.
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 (as Net-RID DP).
All Net-RID DP subscribed to that operation of UAS#1 will deliver its track information to their users who subscribed to that operation of UAS#1 (via means unspecified by [F3411-19], etc., but generally presumed to be web browser based).
Network RID has several connectivity scenarios:
Persistently Internet-connected UA can consistently directly source RID information; this requires wireless coverage throughout the intended operational airspace volume, plus a buffer (e.g., winds may drive the UA out of the volume).
Intermittently Internet-connected UA, can usually directly source RID information, but when offline (e.g., due to signal blockage by a large structure being inspected using the UAS), need the GCS to proxy source RID information.
Indirectly connected UA lack the ability to send IP packets that will be forwarded into and across the Internet but instead have some other form of communications to another node that can relay or proxy RID information to the Internet; typically, this node would be the GCS (which to perform its function must know where the UA is, although C2 link outages do occur).
Non-connected UA have no means of sourcing RID information, in which case the GCS or some other interface available to the operator must source it. In the extreme case, this could be the pilot or other agent of the operator using a web browser or application to designate, to a USS or other UTM entity, a time-bounded airspace volume in which an operation will be conducted. This is referred to as a "non-equipped network participant" engaging in "area operations". This may impede disambiguation of ID if multiple UAS operate in the same or overlapping 4-D volumes. In most airspace volumes, most classes of UA will not be permitted to fly if non-connected.
In most cases in the near term (2021), the Network RID first-hop data link is likely to be either cellular (which can also support BVLOS C2 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 immaterial to higher-layer protocols. The UAS, as the ultimate source of Network RID information, feeds a Net-RID SP (typically the USS to which the UAS operator subscribes), which proxies for the UAS and other data sources. An Observer or other ultimate consumer of Network RID information obtains it from a Net-RID DP (also typically a USS), which aggregates information from multiple Net-RID SPs to offer airspace Situational Awareness (SA) coverage of a volume of interest. Network RID Service and Display Providers are expected to be implemented as servers in well-connected infrastructure, communicating with each other via the Internet and accessible by Observers via means such as web Application Programming Interfaces (APIs) and browsers.
Network RID is the less constrained of the defined means of UAS RID. [F3411-19
] only specifies information exchanges from Net-RID SP to Net-RID DP. It is presumed that IETF efforts supporting the more constrained Broadcast RID (see next section) can be generalized for Network RID and potentially also for UAS-to-USS or other UTM communications.
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.
| Unmanned Aircraft |
| app messages directly over one-way RF data link
| Observer's device (e.g., smartphone) |
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 intent to allow, and FAA has explicitly prohibited, use of ADS-B for UAS RID.
] specifies four Broadcast 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 GHz, and Wi-Fi NAN at 5 GHz. A UA must broadcast (using advertisement mechanisms where no other option supports broadcast) on at least one of these. If sending on Bluetooth 5.x, it is required to do so concurrently on 4.x (referred to in [F3411-19
] as "Bluetooth Legacy"); current (2021) discussions in ASTM F38.02 on revising [F3411-19
], motivated by drafts of European standards, suggest that both Bluetooth versions will be required. If broadcasting Wi-Fi NAN at 5 GHz, it is required to do so concurrently at 2.4 GHz; current discussions in ASTM F38.02 include relaxing this. Wi-Fi Beacons are also under consideration. Future revisions of [F3411-19
] may allow other data links.
The selection of Broadcast RID media was driven by research into what is commonly available on "ground" units (smartphones and tablets) and what was found as prevalent or "affordable" in UA. Further, there must be an API for the Observer's receiving application to have access to these messages. As yet, only Bluetooth 4.x support is readily available; thus, the current focus is on working within the 31-byte payload limit of the Bluetooth 4.x "Broadcast Frame" transmitted as an "advertisement" on beacon channels. After overheads, this limits the RID message to 25 bytes and the UAS ID string to a maximum length of 20 bytes.
A single Bluetooth 4.x advertisement frame can just barely fit any UAS ID long enough to be sufficiently unique for its purpose.
There is related information, which especially includes, but is not limited to, the UA position and velocity, which must be represented by data elements long enough to provide precision sufficient for their purpose while remaining unambiguous with respect to their reference frame.
In order to enable Observer devices to verify that 1) the claimed UAS ID is indeed owned by the sender and 2) the related information was indeed sent by the owner of that same UAS ID, authentication data elements would typically be lengthy with conventional cryptographic signature schemes. They would be too long to fit in a single frame, even with the latest schemes currently being standardized.
Thus, it is infeasible to bundle information related to the UAS ID and corresponding authentication data elements in a single Bluetooth 4.x frame; yet, somehow all these must be securely bound together.
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 [F3411-19
]). 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).
] Broadcast RID specifies several message types (see Section 5.4.5 and Table 3 of [F3411-19
]). 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 jurisdictional authority, e.g., a CAA. To satisfy both EASA and FAA rules, all types are needed, except Self-ID and Authentication, as the data elements required by the rules are scattered across several message types (along with some data elements not required by the rules).
The Message Pack (type 0xF) is not actually a message but the framed concatenation of at most one message of each type of any subset of the other types, in type index order. Some of the messages that it can encapsulate are mandatory; others are optional. The Message Pack itself is mandatory on data links that can encapsulate it in a single frame (Bluetooth 5.x and Wi-Fi).
Table 1: Message Types Defined in
||BT5 and Wi-Fi
] Broadcast RID specifies very few quantitative performance requirements: static information must be transmitted at least once per three seconds, and dynamic information (the Location/Vector Message) must be transmitted at least once per second and be no older than one second when sent. [FRUR
] requires all information be sent at least once per second.
] Broadcast RID transmits all information as cleartext (ASCII or binary), so static IDs enable trivial correlation of patterns of use, which is unacceptable in many applications, e.g., package delivery routes of competitors.
Any UA can assert any ID using the [F3411-19
] required Basic ID Message, which lacks any provisions for verification. The Location/Vector Message likewise lacks provisions for verification and does not contain the ID, so it must be correlated somehow with a Basic ID Message: the developers of [F3411-19
] have suggested using the MAC addresses on the Broadcast RID data link, but these may be randomized by the operating system stack to avoid the adversarial correlation problems of static identifiers.
] optional Authentication Message specifies framing for authentication data but does not specify any authentication method, and the maximum length of the specified framing is too short for conventional digital signatures and far too short for conventional certificates (e.g., X.509). Fetching certificates via the Internet is not always possible (e.g., Observers working in remote areas, such as national forests), so devising a scheme whereby certificates can be transported over Broadcast RID is necessary. The one-way nature of Broadcast RID precludes challenge-response security protocols (e.g., Observers sending nonces to UA, to be returned in signed messages). Without DRIP extensions to [F3411-19
], an Observer would be seriously challenged to validate the asserted UAS ID or any other information about the UAS or its operator looked up therefrom.
At the time of writing, the proposed revision of [F3411-19
] defines a new Authentication Type 5 ("Specific Authentication Method (SAM)") to enable SDOs other than ASTM to define authentication payload formats. The first byte of the payload is the SAM Type, used to demultiplex such variant formats. All formats (aside from those for private experimental use) must be registered with ICAO, which assigns the SAM Type. Any Authentication Message payload that is to be sent in exactly the same form over all currently specified Broadcast RID media is limited by lower-layer constraints to a total length of 201 bytes. For Authentication Type 5, which is expected to be used by DRIP, the SAM Type byte consumes the first of these, limiting DRIP authentication payload formats to a maximum of 200 bytes.
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 several per jurisdiction with some being limited to a single jurisdiction while 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. Each UAS is registered by its operator in at least one USS. Each operational intent is submitted to one USS; if approved, that UAS and operator can commence that operation. During the operation, status and location of that UAS must be reported to that USS, which, in turn, provides information as needed about that operator, UAS, and operation into the UTM system and to Observers via Network RID.
USS provide services not limited to Network RID; indeed, the primary USS function is deconfliction of airspace usage between different UAS (and their operators). It will occasionally deconflict UAS from non-UAS operations, such as manned aircraft and rocket launch. Most deconfliction involving a given operation is hoped to be completed prior to commencing that operation; this is called "strategic deconfliction". If that fails, "tactical deconfliction" comes into play; AirBorne DAA (ABDAA) may not involve USS, but Ground-Based DAA (GBDAA) likely will. Dynamic constraints, formerly called "UAS Volume Restrictions (UVRs)", can be necessitated by circumstances such as local emergencies and extreme weather, specified by authorities on the ground, and propagated in UTM.
No role for USS in Broadcast RID is currently specified by regulators or by [F3411-19
]. However, USS are likely to serve as registries (or perhaps registrars) for UAS (and perhaps operators); if so, USS will have a role in all forms of RID. Supplemental Data Service Providers (SDSPs) are also likely to find roles, not only in UTM as such but also in enhancing UAS RID and related services. RID services are used in concert with USS, SDSP, or other UTM entities (if and as needed and available). 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.
In addition to the gaps described above, there is a fundamental gap in almost all current or proposed regulations and technical standards for UAS RID. As noted above, ID is not an end in itself, but a means. Protocols specified in [F3411-19
] etc. provide limited information potentially enabling (but no technical means for) an Observer to communicate with the pilot, e.g., to request further information on the UAS operation or exit from an airspace volume in an emergency. The System Message provides the location of the pilot/GCS, so an Observer could physically go to the asserted location to look for 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 multiple UAS operators to contact whose GCS all lie in different directions from the Observer? An Observer with Internet connectivity and access privileges could look up operator PII in a registry and then call a phone number in hopes that someone who can immediately influence the UAS operation will answer promptly during that operation; this is unreliable, at best, and may not be prudent. Should pilots be encouraged to answer phone calls while flying? Internet technologies can do much better than this.
Thus, to achieve widespread adoption of a RID system supporting safe and secure operation of UAS, protocols must do the following (despite the intrinsic tension among these objectives):
preserve operator privacy,
enable strong authentication, and
enable the immediate use of information by authorized parties.
Just as [F3411-19
] is expected to be approved by regulators as a basic means of compliance with UAS RID regulations, DRIP is likewise expected to be approved to address further issues, starting with the creation and registration of Session IDs.
DRIP will focus on making information obtained via UAS RID immediately usable:
by making it trustworthy (despite the severe constraints of Broadcast RID);
by enabling verification that a UAS is registered for RID, and, if so, in which registry (for classification of trusted operators on the basis of known registry vetting, even by Observers lacking Internet connectivity at observation time);
by facilitating independent reports of UA aeronautical data (location, velocity, etc.) to confirm or refute the operator self-reports upon which UAS RID and UTM tracking are based;
by enabling instant establishment, by authorized parties, of secure communications with the Remote Pilot.
The foregoing considerations, beyond those addressed by baseline UAS RID standards such as [F3411-19
], imply the requirements for DRIP detailed in Section 4