idnits 2.17.1 draft-ietf-drip-reqs-09.txt: -(8): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1783): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 159 has weird spacing: '...perator x ...' == Line 922 has weird spacing: '...bserver x x...' -- The document date (17 February 2021) is 1164 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRIP S. Card, Ed. 3 Internet-Draft A. Wiethuechter 4 Intended status: Informational AX Enterprize 5 Expires: 21 August 2021 R. Moskowitz 6 HTT Consulting 7 A. Gurtov 8 Linköping University 9 17 February 2021 11 Drone Remote Identification Protocol (DRIP) Requirements 12 draft-ietf-drip-reqs-09 14 Abstract 16 This document defines terminology and requirements for Drone Remote 17 Identification Protocol (DRIP) Working Group solutions to support 18 Unmanned Aircraft System Remote Identification and tracking (UAS RID) 19 for security, safety, and other purposes. Complementing external 20 technical standards as regulator-accepted means of compliance with 21 UAS RID regulations, DRIP will facilitate use of existing Internet 22 resources to support RID and to enable enhanced related services, and 23 will enable online and offline verification that RID information is 24 trustworthy. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 21 August 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Motivation and External Influences . . . . . . . . . . . 2 61 1.2. Concerns and Constraints . . . . . . . . . . . . . . . . 7 62 1.3. DRIP Scope . . . . . . . . . . . . . . . . . . . . . . . 9 63 1.4. Document Scope . . . . . . . . . . . . . . . . . . . . . 10 64 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 10 65 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 10 66 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 67 3. UAS RID Problem Space . . . . . . . . . . . . . . . . . . . . 18 68 3.1. Network RID . . . . . . . . . . . . . . . . . . . . . . . 20 69 3.2. Broadcast RID . . . . . . . . . . . . . . . . . . . . . . 23 70 3.3. USS in UTM and RID . . . . . . . . . . . . . . . . . . . 26 71 3.4. DRIP Focus . . . . . . . . . . . . . . . . . . . . . . . 27 72 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 28 73 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 28 74 4.2. Identifier . . . . . . . . . . . . . . . . . . . . . . . 30 75 4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 31 76 4.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 33 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 79 7. Privacy and Transparency Considerations . . . . . . . . . . . 35 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 36 82 8.2. Informative References . . . . . . . . . . . . . . . . . 36 83 Appendix A. Discussion and Limitations . . . . . . . . . . . . . 39 84 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 87 1. Introduction 89 1.1. Motivation and External Influences 91 Many considerations (especially safety and security) necessitate 92 Unmanned Aircraft Systems (UAS) Remote Identification and tracking 93 (RID). 95 Unmanned Aircraft (UA) may be fixed wing, rotary wing (e.g., 96 helicopter), hybrid, balloon, rocket, etc. Small fixed wing UA 97 typically have Short Take-Off and Landing (STOL) capability; rotary 98 wing and hybrid UA typically have Vertical Take-Off and Landing 99 (VTOL) capability. UA may be single- or multi-engine. The most 100 common today are multicopters: rotary wing, multi engine. The 101 explosion in UAS was enabled by hobbyist development, for 102 multicopters, of advanced flight stability algorithms, enabling even 103 inexperienced pilots to take off, fly to a location of interest, 104 hover, and return to the take-off location or land at a distance. 105 UAS can be remotely piloted by a human (e.g., with a joystick) or 106 programmed to proceed from Global Navigation Satellite System (GNSS) 107 waypoint to waypoint in a weak form of autonomy; stronger autonomy is 108 coming. 110 Small UA are "low observable" as they: 112 * typically have small radar cross sections; 114 * make noise quite noticeable at short range but difficult to detect 115 at distances they can quickly close (500 meters in under 17 116 seconds at 60 knots); 118 * typically fly at low altitudes (e.g., for those to which RID 119 applies in the US, under 400 feet Above Ground Level (AGL) as per 120 [Part107]); 122 * are highly maneuverable so can fly under trees and between 123 buildings. 125 UA can carry payloads including sensors, cyber and kinetic weapons, 126 or can be used themselves as weapons by flying them into targets. 127 They can be flown by clueless, careless, or criminal operators. Thus 128 the most basic function of UAS RID is "Identification Friend or Foe" 129 (IFF) to mitigate the significant threat they present. 131 Diverse other applications can be enabled or facilitated by RID. 132 Consider the importance of identifiers in many Internet protocols and 133 services, e.g., Fully Qualified Domain Names (FQDNs), transport 134 protocol identifiers, UDP and TCP ports, Uniform Resource Identifiers 135 (URIs), X.509 public key identifiers, E.164 numbers, Network Access 136 Identifiers (NAIs), email addresses, Digital Object Identifiers 137 (DOIs), and pretty much anything for which IANA is responsible. 139 The general UAS RID usage scenario is illustrated in Figure 1. 141 UA1 UA2 142 x x x x 143 xxxxx xxxxx 145 General x x Public 146 Public xxxxx xxxxx Safety 147 Observer x x Observer 148 x x 149 x x ---------+ +---------- x x 150 x x | | x x 151 | | 152 + + 153 xxxxxxxxxx 154 x x 155 +----------+x Internet x+------------+ 156 | x x | 157 UA1 x | xxxxxxxxxx | x UA2 158 Pilot/ xxxxx + + + xxxxx Pilot/ 159 Operator x | | | x Operator 160 x | | | x 161 x x | | | x x 162 x x | | | x x 163 | | | 164 +----------+ | | | +----------+ 165 | |------+ | +-------| | 166 | Public | | | Private | 167 | Registry | +-----+ | Registry | 168 | | | DNS | | | 169 +----------+ +-----+ +----------+ 171 Figure 1: "General UAS RID Usage Scenario" 173 Figure 1 illustrates a typical case where there may be: multiple 174 Observers, some of them members of the general public, others 175 government officers with public safety/security responsibilities; 176 multiple UA in flight within observation range, each with its own 177 pilot/operator; at least one registry each for lookup of public and 178 (by authorized parties only) private information regarding the UAS 179 and their pilots/operators; and in the DRIP vision, DNS resolving 180 various identifiers and locators of the entities involved. Note the 181 absence of any links to/from the UA in the figure; this is because 182 UAS RID and other connectivity involving the UA varies as described 183 below. 185 An Observer of UA may need to classify them, as illustrated 186 notionally in Figure 2, for basic airspace Situational Awareness 187 (SA). An Observer who classifies a UAS: as Taskable, can ask it to 188 do something useful; as Low Concern, can reasonably assume it is not 189 malicious and would cooperate with requests to modify its flight 190 plans for safety concerns that arise; as High Concern or 191 Unidentified, can focus surveillance on it. 193 xxxxxxx +--------------+ 194 x x No | | 195 x ID? x+---->| Unidentified | 196 x x | | 197 xxxxxxx +--------------+ 198 + 199 | Yes 200 v 201 xxxxxxx 202 x x 203 +---------+x Type? x+----------+ 204 | x x | 205 | xxxxxxx | 206 | + | 207 v v v 208 +--------------+ +--------------+ +--------------+ 209 | | | | | | 210 | Taskable | | Low Concern | | High Concern | 211 | | | | | | 212 +--------------+ +--------------+ +--------------+ 214 Figure 2: "Notional UAS Classification" 216 ASTM International, Technical Committee F38 (UAS), Subcommittee 217 F38.02 (Aircraft Operations), Work Item WK65041, developed the widely 218 cited Standard Specification for Remote ID and Tracking [F3411-19]: 219 the published standard is available for purchase from ASTM and as an 220 ASTM membership premium; early drafts are freely available as 221 [OpenDroneID] specifications. [F3411-19] is frequently referenced in 222 DRIP, where building upon its link layers and both enhancing support 223 for and expanding the scope of its applications are central foci. 225 In many applications, including UAS RID, identification and 226 identifiers are not ends in themselves; they exist to enable lookups 227 and provision of other services. 229 Using UAS RID to facilitate vehicular (V2X) communications and 230 applications such as Detect And Avoid (DAA), which would impose 231 tighter latency bounds than RID itself, is an obvious possibility, 232 explicitly contemplated in the United States (US) Federal Aviation 233 Administration (FAA) Remote Identification of Unmanned Aircraft rule 234 [FRUR]. However, applications of RID beyond RID itself, including 235 DAA, have been declared out of scope in ASTM F38.02 WK65041, based on 236 a distinction between RID as a security standard vs DAA as a safety 237 application. 239 [Opinion1] and [WG105] cite the Direct Remote Identification (DRI) 240 previously required and specified, explicitly stating that whereas 241 DRI is primarily for security purposes, the "Network Identification 242 Service" [Opinion1] (in the context of U-space [InitialView]) or 243 "Electronic Identification" [WG105] is primarily for safety purposes 244 (e.g., Air Traffic Management, especially hazards deconfliction) and 245 also is allowed to be used for other purposes such as support of 246 efficient operations. These emerging standards allow the security 247 and safety oriented systems to be separate or merged. In addition to 248 mandating both Broadcast and Network one-way to Observers, they will 249 use V2V to other UAS (also likely to and/or from some manned 250 aircraft). These reflect the broad scope of the European Union (EU) 251 U-space concept, as being developed in the Single European Sky ATM 252 Research (SESAR) Joint Undertaking, the U-space architectural 253 principles of which are outlined in [InitialView]. 255 ASD-STAN is an Associated Body to CEN (European Committee for 256 Standardization) for Aerospace Standards. It is publishing an EU 257 standard "Aerospace series - Unmanned Aircraft Systems - Part 002: 258 Direct Remote Identification; English version prEN 4709-002:2020" for 259 which a current (early 2021) informal overview is freely available in 260 [ASDRI]. It will provide compliance to cover the identical DRI 261 requirements applicable to drones of classes C1 - [Delegated] Part 2, 262 C2 - [Delegated] Part 3, C3 - [Delegated] Part 4, C5 - [Amended] Part 263 16, and C6 - [Amended] Part 17. 265 The standard contemplated in [ASDRI] will provide UA capability to be 266 identified in real time during the whole duration of the flight, 267 without specific connectivity or ground infrastructure link, 268 utilizing existing mobile devices within broadcast range. It will 269 use Bluetooth 4, Bluetooth 5, Wi-Fi NAN and/or Wi-Fi Beacon modes. 270 The EU standard emphasis was compatibility with [F3411-19], although 271 there are differences in mandatory and optional message types and 272 fields. 274 The DRI system will broadcast locally: 276 1. the UAS operator registration number; 277 2. the [CTA2063A] compliant unique serial number of the UA; 279 3. a time stamp, the geographical position of the UA, and its height 280 AGL or above its take-off point; 282 4. the UA ground speed and route course measured clockwise from true 283 north; 285 5. the geographical position of the remote pilot, or if that is not 286 available, the geographical position of the UA take-off point; 287 and 289 6. for Classes C1, C2, C3, the UAS emergency status. 291 The data will be sent in plain text and the UAS operator registration 292 number will be represented as a 16-byte string including the state 293 code. The private id part will contain 3 characters which are not 294 broadcast but used by authorities to access regional registration 295 databases for verification. 297 ASD-STAN also contemplates corresponding Network Remote 298 Identification (NRI) functionality. The ASD-STAN RID target is to 299 revise their current standard with additional functionality (e.g., 300 DRIP) to be published before 2022 [ASDRI]. 302 Security oriented UAS RID essentially has two goals: enable the 303 general public to obtain and record an opaque ID for any observed UA, 304 which they can then report to authorities; enable authorities, from 305 such an ID, to look up information about the UAS and its operator. 306 Safety oriented UAS RID has stronger requirements. Aviation 307 community Standards Development Organizations (SDOs) set a higher bar 308 for safety than for security, especially with respect to reliability. 310 Although dynamic establishment of secure communications between the 311 Observer and the UAS pilot seems to have been contemplated by the FAA 312 UAS ID and Tracking Aviation Rulemaking Committee (ARC) in their 313 [Recommendations], it is not addressed in any of the subsequent 314 regulations or technical specifications. 316 1.2. Concerns and Constraints 318 Disambiguation of multiple UA flying in close proximity may be very 319 challenging, even if each is reporting its identity, position, and 320 velocity as accurately as it can. 322 The origin of all information in UAS RID is operator self-reports. 323 Reports may be initiated by the remote pilot at the Ground Control 324 Station (GCS) console, by a software process on the GCS, or by a 325 process on the UA. Data in the reports may come from the UA (e.g., 326 an on-board GNSS receiver), the GCS (e.g., dead reckoning UA location 327 based on takeoff location and piloting commands given since takeoff), 328 and/or sensors available to the operator (e.g., radar or cameras). 329 Whether information comes proximately from the operator, or from 330 automated systems configured by the operator, there are possibilities 331 not only of unintentional error in, but also of intentional 332 falsification of, this data. 334 Minimal specified information must be made available to the public. 335 Access to other data, e.g., UAS operator Personally Identifiable 336 Information (PII), must be limited to strongly authenticated 337 personnel, properly authorized in accordance with applicable policy. 338 The balance between privacy and transparency remains a subject for 339 public debate and regulatory action; DRIP can only offer tools to 340 expand the achievable trade space and enable trade-offs within that 341 space. [F3411-19], the basis for most current (2021) thinking about 342 and efforts to provide UAS RID, specifies only how to get the UAS ID 343 to the Observer: how the Observer can perform these lookups and how 344 the registries first can be populated with information are 345 unspecified therein. 347 The need for nearly universal deployment of UAS RID is pressing: 348 consider how negligible the value of an automobile license plate 349 system would be if only 90% of the cars displayed plates. This 350 implies the need to support use by Observers of already ubiquitous 351 mobile devices (typically smartphones and tablets). Anticipating 352 Civil Aviation Authority (CAA) requirements to support legacy 353 devices, especially in light of [Recommendations], [F3411-19] 354 specifies that any UAS sending Broadcast RID over Bluetooth must do 355 so over Bluetooth 4, regardless of whether it also does so over newer 356 versions; as UAS sender devices and Observer receiver devices are 357 unpaired, this implies extremely short "advertisement" (beacon) 358 frames. 360 Wireless data links on the UA are challenging due to low altitude 361 flight amidst structures and foliage over terrain, as well as the 362 severe Cost, Size, Weight, and Power (CSWaP) constraints of devices 363 onboard UA. CSWaP is a burden not only on the designers of new UA 364 for production and sale, but also on owners of existing UA that must 365 be retrofit. Radio Controlled (RC) aircraft modelers, "hams" who use 366 licensed amateur radio frequencies to control UAS, drone hobbyists, 367 and others who custom build UAS, all need means of participating in 368 UAS RID, sensitive to both generic CSWaP and application-specific 369 considerations. 371 To accommodate the most severely constrained cases, all these 372 conspire to motivate system design decisions that complicate the 373 protocol design problem. All UA are constrained by their batteries 374 (both instantaneous power and total energy) and small UA imply small 375 antennas, so wireless air to ground links will generally be slow and 376 unreliable. Densely populated volumes will suffer from link 377 congestion: even if UA in an airspace volume are few, other 378 transmitters nearby on the ground, sharing the same license free 379 spectral band may be many. Broadcast RID uses one-way data links. 380 Bluetooth 4 restricts broadcast messages to fit in extremely short 381 "advertisement" packets. UA onboard devices may have Internet 382 connectivity only intermittently, or not at all, during flight. 383 Internet-disconnected operation of Observer devices has been deemed 384 by ASTM F38.02 too infrequent to address, but for some users is 385 important and presents further challenges. 387 As RID must often operate within these constraints, heavyweight 388 cryptographic security protocols or even simple cryptographic 389 handshakes are infeasible, yet trustworthiness of UAS RID information 390 is essential. Under [F3411-19], _even the most basic datum, the UAS 391 ID itself, can be merely an unsubstantiated claim_. 393 Observer devices being ubiquitous, thus popular targets for malware 394 or other compromise, cannot be generally trusted (although the user 395 of each device is compelled to trust that device, to some extent); a 396 "fair witness" functionality (inspired by [Stranger]) is desirable. 398 Despite work by regulators and SDOs, there are substantial gaps in 399 UAS standards generally and UAS RID specifically. [Roadmap] catalogs 400 UAS related standards, ongoing standardization activities and gaps 401 (as of 2020); Section 7.8 catalogs those related specifically to UAS 402 RID. DRIP will address the most fundamental of these gaps, as 403 foreshadowed above. 405 1.3. DRIP Scope 407 DRIP's initial goal is to make RID immediately actionable, in both 408 Internet and local-only connected scenarios (especially emergencies), 409 in severely constrained UAS environments, balancing legitimate (e.g., 410 public safety) authorities' Need To Know trustworthy information with 411 UAS operators' privacy. By "immediately actionable" is meant 412 information of sufficient precision, accuracy, timeliness, etc. for 413 an Observer to use it as the basis for immediate decisive action, 414 whether that be to trigger a defensive counter-UAS system, to attempt 415 to initiate communications with the UAS operator, to accept the 416 presence of the UAS in the airspace where/when observed as not 417 requiring further action, or whatever, with potentially severe 418 consequences of any action or inaction chosen based on that 419 information. For further explanation of the concept of immediate 420 actionability, see [ENISACSIRT]. 422 Note that UAS RID must achieve nearly universal adoption, but DRIP 423 can add value even if only selectively deployed. Authorities with 424 jurisdiction over more sensitive airspace volumes may set a higher 425 than generally mandated RID requirement for flight in such volumes. 426 Those with a greater need for high-confidence IFF can equip with 427 DRIP, enabling strong authentication of their own aircraft and allied 428 operators without regard for the weaker (if any) authentication of 429 others. 431 DRIP (originally Trustworthy Multipurpose Remote Identification, TM- 432 RID) potentially could be applied to verifiably identify other types 433 of registered things reported to be in specified physical locations, 434 and providing timely trustworthy identification data is also 435 prerequisite to identity-oriented networking, but the urgent 436 motivation and clear initial focus is UAS. Existing Internet 437 resources (protocol standards, services, infrastructure, and business 438 models) should be leveraged. 440 1.4. Document Scope 442 This document describes the problem space for UAS RID conforming to 443 proposed regulations and external technical standards, defines common 444 terminology, specifies numbered requirements for DRIP, identifies 445 some important considerations (IANA, security, privacy and 446 transparency), and discusses limitations. 448 A natural Internet based approach to meet these requirements is 449 described in a companion architecture document [drip-architecture] 450 and elaborated in other DRIP documents. 452 2. Terms and Definitions 454 2.1. Requirements Terminology 456 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 457 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 458 "OPTIONAL" in this document are to be interpreted as described in BCP 459 14 [RFC2119] [RFC8174] when, and only when, they appear in all 460 capitals, as shown here. 462 2.2. Definitions 464 This section defines a non-comprehensive set of terms expected to be 465 used in DRIP documents. This list is meant to be the DRIP 466 terminology reference; as such, some of the terms listed below are 467 not used in this document. 469 [RFC4949] provides a glossary of Internet security terms that should 470 be used where applicable. 472 In the UAS community, the plural form of acronyms generally is the 473 same as the singular form, e.g., Unmanned Aircraft System (singular) 474 and Unmanned Aircraft Systems (plural) are both represented as UAS. 475 On this and other terminological issues, to encourage comprehension 476 necessary for adoption of DRIP by the intended user community, that 477 community's norms are respected herein, and definitions are quoted in 478 cases where they have been found in that community's documents. Most 479 of the listed terms are from that community (even if specific source 480 documents are not cited); any that are DRIP-specific or invented by 481 the authors of this document are marked "(DRIP)". 483 4-D 484 Four-dimensional. Latitude, Longitude, Altitude, Time. Used 485 especially to delineate an airspace volume in which an operation 486 is being or will be conducted. 488 AAA 489 Attestation, Authentication, Authorization, Access Control, 490 Accounting, Attribution, Audit, or any subset thereof (uses differ 491 by application, author, and context). (DRIP) 493 ABDAA 494 AirBorne DAA. Accomplished using systems onboard the aircraft 495 involved. Supports "self-separation" (remaining "well clear" of 496 other aircraft) and collision avoidance. 498 ADS-B 499 Automatic Dependent Surveillance - Broadcast. "ADS-B Out" 500 equipment obtains aircraft position from other on-board systems 501 (typically GNSS) and periodically broadcasts it to "ADS-B In" 502 equipped entities, including other aircraft, ground stations, and 503 satellite based monitoring systems. 505 AGL 506 Above Ground Level. Relative altitude, above the variously 507 defined local ground level, typically of a UA, measured in feet or 508 meters. Should be explicitly specified as either barometric 509 (pressure) or geodetic (GNSS) altitude. 511 ATC 512 Air Traffic Control. Explicit flight direction to pilots from 513 ground controllers. Contrast with ATM. 515 ATM 516 Air Traffic Management. A broader functional and geographic scope 517 and/or a higher layer of abstraction than ATC. "The dynamic, 518 integrated management of air traffic and airspace including air 519 traffic services, airspace management and air traffic flow 520 management - safely, economically and efficiently - through the 521 provision of facilities and seamless services in collaboration 522 with all parties and involving airborne and ground-based 523 functions" [ICAOATM]. 525 Authentication Message 526 [F3411-19] Message Type 2. Provides framing for authentication 527 data, only. 529 Basic ID Message 530 [F3411-19] Message Type 0. Provides UA Type, UAS ID Type, and UAS 531 ID, only. 533 BVLOS 534 Beyond Visual Line Of Sight. See VLOS. 536 CAA 537 Civil Aviation Authority of a regulatory jurisdiction. Often so 538 named, but other examples include the United States Federal 539 Aviation Administration (FAA) and the Japan Civil Aviation Bureau. 541 CSWaP 542 Cost, Size, Weight, and Power. 544 C2 545 Command and Control. Previously mostly used in military contexts. 546 Properly refers to a function, exercisable over arbitrary 547 communications; but in the small UAS context, often refers to the 548 communications (typically RF data link) over which the GCS 549 controls the UA. 551 DAA 552 Detect And Avoid, formerly Sense And Avoid (SAA). A means of 553 keeping aircraft "well clear" of each other and obstacles for 554 safety. "The capability to see, sense or detect conflicting 555 traffic or other hazards and take the appropriate action to comply 556 with the applicable rules of flight" [ICAOUAS]. 558 DRI (not to be confused with DRIP) 559 Direct Remote Identification. EU regulatory requirement for "a 560 system that ensures the local broadcast of information about a UA 561 in operation, including the marking of the UA, so that this 562 information can be obtained without physical access to the UA". 563 [Delegated] that presumably can be satisfied with appropriately 564 configured [F3411-19] Broadcast RID. 566 DSS 567 Discovery and Synchronization Service. Formerly Inter-USS. The 568 UTM system overlay network backbone. Most importantly, it enables 569 one USS to learn which other USS have UAS operating in a given 4-D 570 airspace volume, for strategic deconfliction of planned operations 571 and Network RID surveillance of active operations. [F3411-19] 573 EUROCAE 574 European Organisation for Civil Aviation Equipment. Aviation SDO, 575 originally European, now with broader membership. Cooperates 576 extensively with RTCA. 578 GBDAA 579 Ground Based DAA. Accomplished with the aid of ground based 580 functions. 582 GCS 583 Ground Control Station. The part of the UAS that the remote pilot 584 uses to exercise C2 over the UA, whether by remotely exercising UA 585 flight controls to fly the UA, by setting GNSS waypoints, or 586 otherwise directing its flight. 588 GNSS 589 Global Navigation Satellite System. Satellite based timing and/or 590 positioning with global coverage, often used to support 591 navigation. 593 GPS 594 Global Positioning System. A specific GNSS, but in the UAS 595 context, the term is typically misused in place of the more 596 generic term GNSS. 598 GRAIN 599 Global Resilient Aviation Interoperable Network. ICAO managed 600 IPv6 overlay internetwork based on IATF, dedicated to aviation 601 (but not just aircraft). Currently (2021) in design, 602 accommodating the proposed DRIP identifier. 604 IATF 605 International Aviation Trust Framework. ICAO effort to develop a 606 resilient and secure by design framework for networking in support 607 of all aspects of aviation. 609 ICAO 610 International Civil Aviation Organization. A United Nations 611 specialized agency that develops and harmonizes international 612 standards relating to aviation. 614 LAANC 615 Low Altitude Authorization and Notification Capability. Supports 616 ATC authorization requirements for UAS operations: remote pilots 617 can apply to receive a near real-time authorization for operations 618 under 400 feet in controlled airspace near airports. US partial 619 stopgap until UTM comes. 621 Location/Vector Message 622 [F3411-19] Message Type 1. Provides UA location, altitude, 623 heading, speed, and status. 625 LOS 626 Line Of Sight. An adjectival phrase describing any information 627 transfer that travels in a nearly straight line (e.g., 628 electromagnetic energy, whether in the visual light, RF, or other 629 frequency range) and is subject to blockage. A term to be avoided 630 due to ambiguity, in this context, between RF LOS and VLOS. 632 Message Pack 633 [F3411-19] Message Type 15. The framed concatenation, in message 634 type index order, of at most one message of each type of any 635 subset of the other types. Required to be sent in Wi-Fi NAN and 636 in Bluetooth 5 Extended Advertisements, if those media are used; 637 cannot be sent in Bluetooth 4. 639 MSL 640 Mean Sea Level. Shorthand for relative altitude, above the 641 variously defined mean sea level, typically of a UA (but in [FRUR] 642 also for a GCS), measured in feet or meters. Should be explicitly 643 specified as either barometric (pressure) or geodetic (e.g., as 644 indicated by GNSS, referenced to the WGS84 ellipsoid). 646 Net-RID DP 647 Network RID Display Provider. [F3411-19] logical entity that 648 aggregates data from Net-RID SPs as needed in response to user 649 queries regarding UAS operating within specified airspace volumes, 650 to enable display by a user application on a user device. 651 Potentially could provide not only information sent via UAS RID 652 but also information retrieved from UAS RID registries or 653 information beyond UAS RID. Under superseded [NPRM], not 654 recognized as a distinct entity, but a service provided by USS, 655 including Public Safety USS that may exist primarily for this 656 purpose rather than to manage any subscribed UAS. 658 Net-RID SP 659 Network RID Service Provider. [F3411-19] logical entity that 660 collects RID messages from UAS and responds to NetRID-DP queries 661 for information on UAS of which it is aware. Under superseded 662 [NPRM], the USS to which the UAS is subscribed ("Remote ID USS"). 664 Network Identification Service 665 EU regulatory requirement in [Opinion1] and [WG105] that 666 presumably can be satisfied with appropriately configured 667 [F3411-19] Network RID. 669 Observer 670 An entity (typically but not necessarily an individual human) who 671 has directly or indirectly observed a UA and wishes to know 672 something about it, starting with its ID. An observer typically 673 is on the ground and local (within VLOS of an observed UA), but 674 could be remote (observing via Network RID or other surveillance), 675 operating another UA, aboard another aircraft, etc. (DRIP) 677 Operation 678 A flight, or series of flights of the same mission, by the same 679 UAS, separated by at most brief ground intervals. (Inferred from 680 UTM usage, no formal definition found) 682 Operator 683 "A person, organization or enterprise engaged in or offering to 684 engage in an aircraft operation" [ICAOUAS]. 686 Operator ID Message 687 [F3411-19] Message Type 5. Provides CAA issued Operator ID, only. 688 Operator ID is distinct from UAS ID. 690 PIC 691 Pilot In Command. "The pilot designated by the operator, or in 692 the case of general aviation, the owner, as being in command and 693 charged with the safe conduct of a flight" [ICAOUAS]. 695 PII 696 Personally Identifiable Information. In the UAS RID context, 697 typically of the UAS Operator, Pilot In Command (PIC), or Remote 698 Pilot, but possibly of an Observer or other party. 700 Remote Pilot 701 A pilot using a GCS to exercise proximate control of a UA. Either 702 the PIC or under the supervision of the PIC. "The person who 703 manipulates the flight controls of a remotely-piloted aircraft 704 during flight time" [ICAOUAS]. 706 RF 707 Radio Frequency. Adjective, e.g., "RF link", or noun. 709 RF LOS 710 RF Line Of Sight. Typically used in describing a direct radio 711 link between a GCS and the UA under its control, potentially 712 subject to blockage by foliage, structures, terrain, or other 713 vehicles, but less so than VLOS. 715 RTCA 716 Radio Technical Commission for Aeronautics. US aviation SDO. 717 Cooperates extensively with EUROCAE. 719 Self-ID Message 720 [F3411-19] Message Type 3. Provides a 1 byte descriptor and 23 721 byte ASCII free text field, only. Expected to be used to provide 722 context on the operation, e.g., mission intent. 724 SDO 725 Standards Development Organization. ASTM, IETF, et al. 727 SDSP 728 Supplemental Data Service Provider. An entity that participates 729 in the UTM system, but provides services beyond those specified as 730 basic UTM system functions (e.g., weather data). [FAACONOPS] 732 System Message 733 [F3411-19] Message Type 4. Provides general UAS information, 734 including remote pilot location, multiple UA group operational 735 area, etc. 737 U-space 738 EU concept and emerging framework for integration of UAS into all 739 classes of airspace, specifically including high density urban 740 areas, sharing airspace with manned aircraft [InitialView]. 742 UA 743 Unmanned Aircraft. In popular parlance, "drone". "An aircraft 744 which is intended to operate with no pilot on board" [ICAOUAS]. 746 UAS 747 Unmanned Aircraft System. Composed of UA, all required on-board 748 subsystems, payload, control station, other required off-board 749 subsystems, any required launch and recovery equipment, all 750 required crew members, and C2 links between UA and control station 751 [F3411-19]. 753 UAS ID 754 UAS identifier. Although called "UAS ID", unique to the UA, 755 neither to the operator (as some UAS registration numbers have 756 been and for exclusively recreational purposes are continuing to 757 be assigned), nor to the combination of GCS and UA that comprise 758 the UAS. _Maximum length of 20 bytes_ [F3411-19]. 760 UAS ID Type 761 UAS Identifier type index. 4 bits, see Section 3, Paragraph 6 for 762 currently defined values 0-3. [F3411-19] 764 UAS RID 765 UAS Remote Identification and tracking. System to enable 766 arbitrary Observers to identify UA during flight. 768 UAS RID Verifier Service 769 System component designed to handle the authentication 770 requirements of RID by offloading verification to a web hosted 771 service [F3411-19]. 773 USS 774 UAS Service Supplier. "A USS is an entity that assists UAS 775 Operators with meeting UTM operational requirements that enable 776 safe and efficient use of airspace" and "... provide services to 777 support the UAS community, to connect Operators and other entities 778 to enable information flow across the USS Network, and to promote 779 shared situational awareness among UTM participants" [FAACONOPS]. 781 UTM 782 UAS Traffic Management. "A specific aspect of air traffic 783 management which manages UAS operations safely, economically and 784 efficiently through the provision of facilities and a seamless set 785 of services in collaboration with all parties and involving 786 airborne and ground-based functions" [ICAOUTM]. In the US, 787 according to the FAA, a "traffic management" ecosystem for 788 "uncontrolled" low altitude UAS operations, separate from, but 789 complementary to, the FAA's ATC system for "controlled" operations 790 of manned aircraft. 792 V2V 793 Vehicle-to-Vehicle. Originally communications between 794 automobiles, now extended to apply to communications between 795 vehicles generally. Often, together with Vehicle-to- 796 Infrastructure (V2I) etc., generalized to V2X. 798 VLOS 799 Visual Line Of Sight. Typically used in describing operation of a 800 UA by a "remote" pilot who can clearly directly (without video 801 cameras or any aids other than glasses or under some rules 802 binoculars) see the UA and its immediate flight environment. 803 Potentially subject to blockage by foliage, structures, terrain, 804 or other vehicles, more so than RF LOS. 806 3. UAS RID Problem Space 808 Civil Aviation Authorities (CAAs) worldwide are mandating UAS RID. 809 The European Union Aviation Safety Agency (EASA) has published 810 [Delegated] and [Implementing] Regulations. The US FAA has published 811 a "final" rule [FRUR] and has described the key role that UAS RID 812 plays in UAS Traffic Management (UTM) in [FAACONOPS] (especially 813 Section 2.6). CAAs currently (2021) promulgate performance-based 814 regulations that do not specify techniques, but rather cite industry 815 consensus technical standards as acceptable means of compliance. 817 The most widely cited such industry consensus technical standard for 818 UAS RID is [F3411-19], which defines two means of UAS RID: 820 Network RID defines a set of information for UAS to make available 821 globally indirectly via the Internet, through servers that can be 822 queried by Observers. 824 Broadcast RID defines a set of messages for UA to transmit locally 825 directly one-way over Bluetooth or Wi-Fi (without IP or any other 826 protocols between the data link and application layers), to be 827 received in real time by local Observers. 829 UAS using both means must send the same UAS RID application layer 830 information via each [F3411-19]. The presentation may differ, as 831 Network RID defines a data dictionary, whereas Broadcast RID defines 832 message formats (which carry items from that same data dictionary). 833 The interval (or rate) at which it is sent may differ, as Network RID 834 can accommodate Observer queries asynchronous to UAS updates (which 835 generally need be sent only when information, such as location, 836 changes), whereas Broadcast RID depends upon Observers receiving UA 837 messages at the time they are transmitted. 839 Network RID depends upon Internet connectivity in several segments 840 from the UAS to each Observer. Broadcast RID should need Internet 841 (or other Wide Area Network) connectivity only for UAS registry 842 information lookup using the directly locally received UAS Identifier 843 (UAS ID) as a key. Broadcast RID does not assume IP connectivity of 844 UAS; messages are encapsulated by the UA without IP, directly in 845 Bluetooth or Wi-Fi Neighbor Awareness Networking [WiFiNAN] link layer 846 frames. 848 [F3411-19] specifies three UAS ID types: 850 TYPE-1 A static, manufacturer assigned, hardware serial number as 851 defined in ANSI/CTA-2063-A "Small Unmanned Aerial System 852 Serial Numbers" [CTA2063A]. 854 TYPE-2 A CAA assigned (generally static) ID, like the registration 855 number of a manned aircraft. 857 TYPE-3 A UTM system assigned UUID [RFC4122], which can but need not 858 be dynamic. 860 Per [Delegated], the EU allows only Type 1. Under [FRUR], the US 861 allows Types 1 and 3. [NPRM] proposed that a Type 3 "Session ID" 862 would be "e.g., a randomly-generated alphanumeric code assigned by a 863 Remote ID USS on a per-flight basis designed to provide additional 864 privacy to the operator", but given the omission of Network RID from 865 [FRUR], how this is to be assigned in the US is still to be 866 determined. 868 As yet apparently there are no CAA public proposals to use Type 2. 869 In the preamble of [FRUR], the FAA argues that registration numbers 870 should not be sent in RID, insists that the capability of looking up 871 registration numbers from information contained in RID should be 872 restricted to FAA and other Government agencies, and implies that 873 Session ID would be linked to the registration number only indirectly 874 via the serial number in the registration database. The possibility 875 of cryptographically blinding registration numbers, such that they 876 can be revealed under specified circumstances, does not appear to be 877 mentioned in applicable regulations or external technical standards. 879 Under [Delegated], the EU also requires an operator registration 880 number (an additional identifier distinct from the UAS ID) that can 881 be carried in an [F3411-19] optional Operator ID message. 883 [FRUR] allows RID requirements to be met by either the UA itself, 884 which is then designated a "standard remote identification unmanned 885 aircraft", or by an add-on "remote identification broadcast module". 886 Relative to a standard RID UA, the different requirements for a 887 module are that the latter: must transmit its own serial number 888 (neither the serial number of the UA to which it is attached, nor a 889 Session ID); must transmit takeoff location as a proxy for the 890 location of the pilot/GCS; need not transmit UA emergency status; and 891 is allowed to be used only for operations within VLOS of the remote 892 pilot. 894 Jurisdictions may relax or waive RID requirements for certain 895 operators and/or under certain conditions. For example, [FRUR] 896 allows operators with UAS not equipped for RID to conduct VLOS 897 operations at counter-intuitively named "FAA-recognized 898 identification areas" (FRIA); radio controlled model aircraft flying 899 clubs and other eligible organizations can apply to the FAA for such 900 recognition of their operating areas. 902 3.1. Network RID 904 x x UA 905 xxxxxxx 906 | \ 907 | \ 908 | \ 909 | \ ******************** 910 | \* ------*---+------------+ 911 | *\ / * | NET_Rid_SP | 912 | * ------------/ +---*--+------------+ 913 | RF */ | * 914 | / INTERNET | * +------------+ 915 | /* +---*--| NET_Rid_DP | 916 | / * +----*--+------------+ 917 + / * | * 918 x / ****************|*** x 919 xxxxx | xxxxx 920 x +------- x 921 x x 922 x x Operator's GCS Observer x x 923 x x x x 925 Figure 3: "Network RID Information Flow" 927 Figure 3 illustrates Network RID information flows. Only two of the 928 three typically wireless links shown involving the UAS (UA-GCS, UA- 929 Internet, and GCS-Internet) need exist. All three may exist, at the 930 same or different times, especially in Beyond Visual Line Of Sight 931 (BVLOS) operations. There must be some information flow path (direct 932 or indirect) between the GCS and the UA, for the former to exercise 933 C2 over the latter. If this path is two-way (as increasingly it is, 934 even for inexpensive small UAS), the UA will also send its status 935 (and position, if suitably equipped, e.g., with GNSS) to the GCS. 936 There also must be some path between at least one subsystem of the 937 UAS (UA or GCS) and the Internet, for the former to send status and 938 position updates to its USS (serving _inter alia_ as a Net-RID SP). 940 Direct UA-Internet wireless links are expected to become more common, 941 especially on larger UAS, but currently (2021) are rare. Instead, 942 the RID data flow typically originates on the UA and passes through 943 the GCS, or originates on the GCS. Network RID data makes three 944 trips through the Internet (GCS-SP, SP-DP, DP-Observer, unless any of 945 them are colocated), implying use of IP (and other middle layer 946 protocols) on those trips. IP is not necessarily used or supported 947 on the UA-GCS link (if indeed that direct link exists, as it 948 typically does now, but in BVLOS operations often will not). 950 Network RID is publish-subscribe-query. In the UTM context: 952 1. The UAS operator pushes an "operational intent" (the current term 953 in UTM corresponding to a flight plan in manned aviation) to the 954 USS (call it USS#1) that will serve that UAS (call it UAS#1) for 955 that operation, primarily to enable deconfliction with other 956 operations potentially impinging upon that operation's 4-D 957 airspace volume (call it Volume#1). 959 2. Assuming the operation is approved and commences, UAS#1 960 periodically pushes location/status updates to USS#1, which 961 serves _inter alia_ as the Network RID Service Provider (Net-RID 962 SP) for that operation. 964 3. When users of any other USS (whether they be other UAS operators 965 or Observers) develop an interest in any 4-D airspace volume 966 (e.g., because they wish to submit an operational intent or 967 because they have observed a UA), they query their own USS on the 968 volumes in which they are interested. 970 4. Their USS query, via the UTM Discovery and Synchronization 971 Service (DSS), all other USS in the UTM system, and learn of any 972 USS that have operations in those volumes (including any volumes 973 intersecting them); thus those USS whose query volumes intersect 974 Volume#1 (call them USS#2 through USS#n) learn that USS#1 has 975 such operations. 977 5. Interested parties can then subscribe to track updates on that 978 operation of UAS#1, via their own USS, which serve as Network RID 979 Display Providers (Net-RID DP) for that operation. 981 6. USS#1 (as Net-RID SP) will then publish updates of UAS#1 status 982 and position to all other subscribed USS in USS#2 through USS#n 983 (as Net-RID DP). 985 7. All Net-RID DP subscribed to that operation of UAS#1 will deliver 986 its track information to their users who subscribed to that 987 operation of UAS#1, via unspecified (generally presumed to be web 988 browser based) means. 990 Network RID has several variants. The UA may have persistent onboard 991 Internet connectivity, in which case it can consistently source RID 992 information directly over the Internet. The UA may have intermittent 993 onboard Internet connectivity, in which case the GCS must source RID 994 information whenever the UA itself is offline. The UA may not have 995 Internet connectivity of its own, but have instead some other form of 996 communications to another node that can relay RID information to the 997 Internet. In this last case, the relay would typically be the GCS 998 (which to perform its function must know where the UA is, although C2 999 link outages do occur). 1001 The UA may have no means of sourcing RID information, in which case 1002 the GCS or some other interface available to the operator must source 1003 it. In the extreme case, this could be the pilot using a web 1004 browser/application to designate, to a UAS Service Supplier (USS) or 1005 other UTM entity, a time-bounded airspace volume in which an 1006 operation will be conducted. This is referred to as a "non-equipped 1007 network participant". This may impede disambiguation of ID if 1008 multiple UAS operate in the same or overlapping 4-D volumes. 1010 In most cases in the near term (2021), the Network RID first hop data 1011 link is likely to be cellular Long Term Evolution (LTE), which can 1012 also support BVLOS C2 over existing large coverage areas, or Wi-Fi, 1013 which can also support Broadcast RID. However, provided the data 1014 link can support at least UDP/IP and ideally also TCP/IP, its type is 1015 generally immaterial to higher layer protocols. The UAS, as the 1016 ultimate source of Network RID information, feeds a Network RID 1017 Service Provider (Net-RID SP, typically the USS to which the UAS 1018 operator subscribes), which proxies for the UAS and other data 1019 sources. An Observer or other ultimate consumer of Network RID 1020 information obtains it from a Network RID Display Provider (Net-RID 1021 DP, also typically a USS), which aggregates information from multiple 1022 Net-RID SPs to offer airspace Situational Awareness (SA) coverage of 1023 a volume of interest. Network RID Service and Display providers are 1024 expected to be implemented as servers in well-connected 1025 infrastructure, communicating with each other via the Internet, and 1026 accessible by Observers via means such as web Application Programming 1027 Interfaces (APIs) and browsers. 1029 Network RID is the less constrained of the defined UAS RID means. 1030 [F3411-19] specifies only Net-RID SP to Net-RID DP information 1031 exchanges. It is presumed that IETF efforts supporting the more 1032 constrained Broadcast RID (see next section) can be generalized for 1033 Network RID and potentially also for UAS to USS or other UTM 1034 communications. 1036 3.2. Broadcast RID 1038 x x UA 1039 xxxxx 1040 | 1041 | 1042 | app messages directly over one-way RF data link 1043 | 1044 | 1045 + 1046 x 1047 xxxxx 1048 x 1049 x 1050 x x Observer's device (e.g., smartphone) 1051 x x 1053 Figure 4: "Broadcast RID Information Flow" 1055 Figure 4 illustrates Broadcast RID information flow. Note the 1056 absence of the Internet from the figure. This is because Broadcast 1057 RID is one-way direct transmission of application layer messages over 1058 a RF data link (without IP or other middle layer protocols) from the 1059 UA to local Observer devices. Internet connectivity is involved only 1060 in what the Observer chooses to do with the information received, 1061 such as verify signatures using a web based verifier service and look 1062 up information in registries using the UAS ID as the primary unique 1063 key. 1065 Broadcast RID is conceptually similar to Automatic Dependent 1066 Surveillance - Broadcast (ADS-B). However, for various technical and 1067 other reasons, regulators including the EASA have not indicated 1068 intent to allow, and FAA has explicitly prohibited, use of ADS-B for 1069 UAS RID. 1071 [F3411-19] specifies four Broadcast RID data links: Bluetooth 4.x, 1072 Bluetooth 5.x with Extended Advertisements and Long Range Coded PHY 1073 (S=8), Wi-Fi with Neighbor Awareness Networking (NAN) at 2.4 GHz, and 1074 Wi-Fi NAN at 5 GHz. A UA must broadcast (using advertisement 1075 mechanisms where no other option supports broadcast) on at least one 1076 of these. If sending on Bluetooth 5.x, it is also required 1077 concurrently to do so on 4.x (referred to in [F3411-19] as Bluetooth 1078 Legacy); current (2021) discussions in ASTM F38.02 on revising the 1079 standard include reversing this. If broadcasting Wi-Fi NAN at 5 GHz, 1080 it is also required concurrently to do so at 2.4 GHz; current 1081 discussions in F38.02 include relaxing this. Wi-Fi Beacons are also 1082 under consideration. Future revisions of [F3411-19] may allow other 1083 data links. 1085 The selection of the Broadcast media was driven by research into what 1086 is commonly available on 'ground' units (smartphones and tablets) and 1087 what was found as prevalent or 'affordable' in UA. Further, there 1088 must be an Application Programming Interface (API) for the observer's 1089 receiving application to have access to these messages. As yet only 1090 Bluetooth 4.x support is readily available, thus the current focus is 1091 on working within the 25 byte limit of the Bluetooth 4.x "Broadcast 1092 Frame" transmitted on beacon channels. After nominal overheads, this 1093 limits the UAS ID string to a maximum length of 20 bytes, and 1094 precludes the same frame carrying position, velocity, and other 1095 information that should be bound to the UAS ID, much less strong 1096 authentication data. This requires segmentation ("paging") of longer 1097 messages and correlation of short messages (anticipated by ASTM to be 1098 done on the basis of MAC address, which is weak and unverifiable) on 1099 Bluetooth 4.x; data elements are not so detached on other media (see 1100 Message Pack below). 1102 [F3411-19] Broadcast RID specifies several message types. The 4 bit 1103 message type field in the header can index up to 16 types. Only 7 1104 are currently defined. Only 2 are mandatory. All others are 1105 optional, unless required by a jurisdictional authority, e.g., a CAA. 1106 To satisfy EASA and FAA rules, all types are needed, except Self-ID 1107 and Authentication. The Message Pack (type 0xF) is not actually a 1108 message, but the framed concatenation of at most one message of each 1109 type of any subset of the other types, in type index order; it is the 1110 sole frame type on links that can encapsulate it (Bluetooth 5.x and 1111 Wi-Fi). 1113 +-----------------------+-----------------+-----------+-----------+ 1114 | Index | Name | Req | Notes | 1115 +-----------------------+-----------------+-----------+-----------+ 1116 | 0x0 | Basic ID | Mandatory | - | 1117 +-----------------------+-----------------+-----------+-----------+ 1118 | 0x1 | Location/Vector | Mandatory | - | 1119 +-----------------------+-----------------+-----------+-----------+ 1120 | 0x2 | Authentication | Optional | paged | 1121 +-----------------------+-----------------+-----------+-----------+ 1122 | 0x3 | Self-ID | Optional | free text | 1123 +-----------------------+-----------------+-----------+-----------+ 1124 | 0x4 | System | Optional | - | 1125 +-----------------------+-----------------+-----------+-----------+ 1126 | 0x5 | Operator | Optional | - | 1127 +-----------------------+-----------------+-----------+-----------+ 1128 | 0xF | Message Pack | - | BT5 and | 1129 | | | | Wi-Fi | 1130 +-----------------------+-----------------+-----------+-----------+ 1131 | See Section 5.4.5 and | - | - | - | 1132 | Table 3 of [F3411-19] | | | | 1133 +-----------------------+-----------------+-----------+-----------+ 1135 Table 1: F3411-19 Message Types 1137 [F3411-19] Broadcast RID specifies very few quantitative performance 1138 requirements: static information must be transmitted at least once 1139 per 3 seconds; dynamic information (the Location/Vector message) must 1140 be transmitted at least once per second and be no older than one 1141 second when sent. [FRUR] requires all information be sent at least 1142 once per second. 1144 [F3411-19] Broadcast RID transmits all information as cleartext 1145 (ASCII or binary), so static IDs enable trivial correlation of 1146 patterns of use, unacceptable in many applications, e.g., package 1147 delivery routes of competitors. 1149 Any UA can assert any ID using the [F3411-19] required Basic ID 1150 message, which lacks any provisions for verification. The Position/ 1151 Vector message likewise lacks provisions for verification, and does 1152 not contain the ID, so must be correlated somehow with a Basic ID 1153 message: the developers of [F3411-19] have suggested using the MAC 1154 addresses on the Broadcast RID data link, but these may be randomized 1155 by the operating system stack to avoid the adversarial correlation 1156 problems of static identifiers. 1158 The [F3411-19] optional Authentication Message specifies framing for 1159 authentication data, but does not specify any authentication method, 1160 and the maximum length of the specified framing is too short for 1161 conventional digital signatures and far too short for conventional 1162 certificates. The one-way nature of Broadcast RID precludes 1163 challenge-response security protocols (e.g., observers sending nonces 1164 to UA, to be returned in signed messages). An Observer would be 1165 seriously challenged to validate the asserted UAS ID or any other 1166 information about the UAS or its operator looked up therefrom. 1168 3.3. USS in UTM and RID 1170 UAS RID and UTM are complementary; Network RID is a UTM service. The 1171 backbone of the UTM system is comprised of multiple USS: one or 1172 several per jurisdiction; some limited to a single jurisdiction, 1173 others spanning multiple jurisdictions. USS also serve as the 1174 principal or perhaps the sole interface for operators and UAS into 1175 the UTM environment. Each operator subscribes to at least one USS. 1176 Each UAS is registered by its operator in at least one USS. Each 1177 operational intent is submitted to one USS; if approved, that UAS and 1178 operator can commence that operation. During the operation, status 1179 and location of that UAS must be reported to that USS, which in turn 1180 provides information as needed about that operator, UAS, and 1181 operation into the UTM system and to Observers via Network RID. 1183 USS provide services not limited to Network RID; indeed, the primary 1184 USS function is deconfliction of airspace usage by different UAS and 1185 other (e.g., manned aircraft, rocket launch) operations. Most 1186 deconfliction involving a given operation is hoped to be completed 1187 prior to commencing that operation, and is called "strategic 1188 deconfliction". If that fails, "tactical deconfliction" comes into 1189 play; ABDAA may not involve USS, but GBDAA likely will. Dynamic 1190 constraints, formerly called UAS Volume Restrictions (UVR), can be 1191 necessitated by local emergencies, extreme weather, etc., specified 1192 by authorities on the ground, and propagated in UTM. 1194 No role for USS in Broadcast RID is currently specified by regulators 1195 or [F3411-19]. However, USS are likely to serve as registries (or 1196 perhaps registrars) for UAS (and perhaps operators); if so, USS will 1197 have a role in all forms of RID. Supplemental Data Service Providers 1198 (SDSP) are also likely to find roles, not only in UTM as such but 1199 also in enhancing UAS RID and related services. Whether USS, SDSP, 1200 etc. are involved or not, RID services, narrowly defined, provide 1201 regulator specified identification information; more broadly defined, 1202 RID services may leverage identification to facilitate related 1203 services or functions, likely beginning with V2X. 1205 3.4. DRIP Focus 1207 In addition to the gaps described above, there is a fundamental gap 1208 in almost all current or proposed regulations and technical standards 1209 for UAS RID. As noted above, ID is not an end in itself, but a 1210 means. Protocols specified in [F3411-19] etc. provide limited 1211 information potentially enabling, and no technical means for, an 1212 Observer to communicate with the pilot, e.g., to request further 1213 information on the UAS operation or exit from an airspace volume in 1214 an emergency. The System Message provides the location of the pilot/ 1215 GCS, so an observer could physically go to the asserted location to 1216 look for the remote pilot; this is at best slow and may not be 1217 feasible. What if the pilot is on the opposite rim of a canyon, or 1218 there are multiple UAS operators to contact, whose GCS all lie in 1219 different directions from the Observer? An Observer with Internet 1220 connectivity and access privileges could look up operator PII in a 1221 registry, then call a phone number in hopes someone who can 1222 immediately influence the UAS operation will answer promptly during 1223 that operation; this is at best unreliable and may not be prudent. 1224 Should pilots be encouraged to answer phone calls while flying? 1225 Internet technologies can do much better than this. 1227 Thus complementing [F3411-19] with protocols enabling strong 1228 authentication, preserving operator privacy while enabling immediate 1229 use of information by authorized parties, is critical to achieve 1230 widespread adoption of a RID system supporting safe and secure 1231 operation of UAS. 1233 DRIP will focus on making information obtained via UAS RID 1234 immediately usable: 1236 1. by making it trustworthy (despite the severe constraints of 1237 Broadcast RID); 1239 2. by enabling verification that a UAS is registered for RID, and if 1240 so, in which registry (for classification of trusted operators on 1241 the basis of known registry vetting, even by observers lacking 1242 Internet connectivity at observation time); 1244 3. by facilitating independent reports of UA aeronautical data 1245 (location, velocity, etc.) to confirm or refute the operator 1246 self-reports upon which UAS RID and UTM tracking are based; 1248 4. by enabling instant establishment, by authorized parties, of 1249 secure communications with the remote pilot. 1251 The foregoing considerations, beyond those addressed by baseline UAS 1252 RID standards such as [F3411-19], imply the following requirements 1253 for DRIP. 1255 4. Requirements 1257 The following requirements apply to DRIP as a set of related 1258 protocols, various subsets of which, in conjunction with other IETF 1259 and external technical standards, may suffice to comply with the 1260 regulations in any given jurisdiction or meet any given user need. 1261 It is not intended that each and every DRIP protocol alone satisfy 1262 each and every requirement. 1264 4.1. General 1266 GEN-1 Provable Ownership: DRIP MUST enable verification that the 1267 UAS ID asserted in the Basic ID message is that of the actual 1268 current sender of the message (i.e., the message is not a 1269 replay attack or other spoof, authenticating, e.g., by 1270 verifying an asymmetric cryptographic signature using a 1271 sender provided public key from which the asserted ID can be 1272 at least partially derived), even on an Observer device 1273 lacking Internet connectivity at the time of observation. 1275 GEN-2 Provable Binding: DRIP MUST enable binding all other 1276 [F3411-19] messages from the same actual current sender to 1277 the UAS ID asserted in the Basic ID message. 1279 GEN-3 Provable Registration: DRIP MUST enable verification that the 1280 UAS ID is in a registry and identification of which one, even 1281 on an Observer device lacking Internet connectivity at the 1282 time of observation; with UAS ID Type 3, the same sender may 1283 have multiple IDs, potentially in different registries, but 1284 each ID must clearly indicate in which registry it can be 1285 found. 1287 GEN-4 Readability: DRIP MUST enable information (regulation 1288 required elements, whether sent via UAS RID or looked up in 1289 registries) to be read and utilized by both humans and 1290 software. 1292 GEN-5 Gateway: DRIP MUST enable Broadcast RID to Network RID 1293 application layer gateways to stamp messages with precise 1294 date/time received and receiver location, then relay them to 1295 a network service (e.g., SDSP or distributed ledger). 1297 GEN-6 Finger: DRIP MUST enable dynamically establishing, with AAA, 1298 per policy, end-to-end strongly encrypted communications with 1299 the UAS RID sender and entities looked up from the UAS ID, 1300 including at least the remote pilot and USS. 1302 GEN-7 QoS: DRIP MUST enable policy based specification of 1303 performance and reliability parameters, such as maximum 1304 message transmission intervals and delivery latencies. 1306 GEN-8 Mobility: DRIP MUST support physical and logical mobility of 1307 UA, GCS and Observers. DRIP SHOULD support mobility of 1308 essentially all participating nodes (UA, GCS, Observers, Net- 1309 RID SP, Net-RID DP, Private Registry, SDSP, and potentially 1310 others as RID and UTM evolve). 1312 GEN-9 Multihoming: DRIP MUST support multihoming of UA and GCS, for 1313 make-before-break smooth handoff and resiliency against path/ 1314 link failure. DRIP SHOULD support multihoming of essentially 1315 all participating nodes. 1317 GEN-10 Multicast: DRIP SHOULD support multicast for efficient and 1318 flexible publish-subscribe notifications, e.g., of UAS 1319 reporting positions in designated airspace volumes. 1321 GEN-11 Management: DRIP SHOULD support monitoring of the health and 1322 coverage of Broadcast and Network RID services. 1324 Requirements imposed either by regulation or [F3411-19] are not 1325 reiterated here, but drive many of the numbered requirements listed 1326 here. The [FRUR] regulatory QoS requirement currently would be 1327 satisfied by ensuring information refresh rates of at least 1 Hertz, 1328 with latencies no greater than 1 second, at least 80% of the time, 1329 but these numbers may vary between jurisdictions and over time. So 1330 instead the DRIP QoS requirement is that performance, reliability, 1331 etc. parameters be user policy specifiable, which does not imply 1332 satisfiable in all cases, but (especially together with the 1333 management requirement) implies that when specifications are not met, 1334 appropriate parties are notified. 1336 The "provable ownership" requirement addresses the possibility that 1337 the actual sender is not the claimed sender (i.e., is a spoofer). 1338 The "provable binding" requirement addresses the MAC address 1339 correlation problem of [F3411-19] noted above. The "provable 1340 registration" requirement may impose burdens not only on the UAS 1341 sender and the Observer's receiver, but also on the registry; yet it 1342 cannot depend upon the Observer being able to contact the registry at 1343 the time of observing the UA. The "readability" requirement may 1344 involve machine assisted format conversions, e.g., from binary 1345 encodings. 1347 The "gateway" requirement is in pursuit of three objectives: (1) mark 1348 up a RID message with where and when it was actually received, which 1349 may agree or disagree with the self-report in the set of messages; 1350 (2) defend against replay attacks; and (3) support optional SDSP 1351 services such as multilateration, to complement UAS position self- 1352 reports with independent measurements. This is the only instance in 1353 which DRIP transports [F3411-19] messages; most of DRIP pertains to 1354 the authentication of such messages and identifiers carried in them. 1356 4.2. Identifier 1358 ID-1 Length: The DRIP entity identifier MUST NOT be longer than 20 1359 bytes, to fit in the UAS ID field of the Basic ID message of 1360 [F3411-19]. 1362 ID-2 Registry ID: The DRIP identifier MUST be sufficient to identify 1363 a registry in which the entity identified therewith is listed. 1365 ID-3 Entity ID: The DRIP identifier MUST be sufficient to enable 1366 lookups of other data associated with the entity identified 1367 therewith in that registry. 1369 ID-4 Uniqueness: The DRIP identifier MUST be unique within the 1370 applicable global identifier space from when it is first 1371 registered therein until it is explicitly de-registered 1372 therefrom (due to, e.g., expiration after a specified lifetime, 1373 revocation by the registry, or surrender by the operator). 1375 ID-5 Non-spoofability: The DRIP identifier MUST NOT be spoofable 1376 within the context of a minimal Remote ID broadcast message set 1377 (to be specified within DRIP to be sufficient collectively to 1378 prove sender ownership of the claimed identifier). 1380 ID-6 Unlinkability: The DRIP identifier MUST NOT facilitate 1381 adversarial correlation over multiple operations. If this is 1382 accomplished by limiting each identifier to a single use or 1383 brief period of usage, the DRIP identifier MUST support well- 1384 defined, scalable, timely registration methods. 1386 The DRIP identifier can refer to various entities. In the primary 1387 initial use case, the entity to be identified is the UA. Entities to 1388 be identified in other likely use cases include but are not limited 1389 to the operator, USS, and Observer. In all cases, the entity 1390 identified must own (have the exclusive capability to use, such that 1391 receivers can verify its ownership of) the identifier. 1393 The DRIP identifier can be used at various layers. In Broadcast RID, 1394 it would be used by the application running directly over the data 1395 link. In Network RID, it would be used by the application running 1396 over HTTPS (and possibly other protocols). In RID initiated V2X 1397 applications such as DAA and C2, it could be used between the network 1398 and transport layers (e.g., with HIP or DTLS). 1400 Registry ID (which registry the entity is in) and Entity ID (which 1401 entity it is, within that registry) are requirements on a single DRIP 1402 entity identifier, not separate (types of) ID. In the most common 1403 use case, the entity will be the UA, and the DRIP identifier will be 1404 the UAS ID; however, other entities may also benefit from having DRIP 1405 identifiers, so the entity type is not prescribed here. 1407 Whether a UAS ID is generated by the operator, GCS, UA, USS, 1408 registry, or some collaboration thereamong, is unspecified; however, 1409 there must be agreement on the UAS ID among these entities. 1411 4.3. Privacy 1413 PRIV-1 Confidential Handling: DRIP MUST enable confidential handling 1414 of private information (i.e., any and all information 1415 designated by neither cognizant authority nor the information 1416 owner as public, e.g., personal data). 1418 PRIV-2 Encrypted Transport: DRIP MUST enable selective strong 1419 encryption of private data in motion in such a manner that 1420 only authorized actors can recover it. If transport is via 1421 IP, then encryption MUST be end-to-end, at or above the IP 1422 layer. DRIP MUST NOT encrypt safety critical data to be 1423 transmitted over Broadcast RID in any situation where it is 1424 unlikely that local Observers authorized to access the 1425 plaintext will be able to decrypt it or obtain it from a 1426 service able to decrypt it. DRIP MUST NOT encrypt data when/ 1427 where doing so would conflict with applicable regulations or 1428 CAA policies/procedures, i.e., DRIP MUST support configurable 1429 disabling of encryption. 1431 PRIV-3 Encrypted Storage: DRIP SHOULD facilitate selective strong 1432 encryption of private data at rest in such a manner that only 1433 authorized actors can recover it. 1435 PRIV-4 Public/Private Designation: DRIP SHOULD facilitate 1436 designation, by cognizant authorities and information owners, 1437 which information is public and which private. By default, 1438 all information required to be transmitted via Broadcast RID, 1439 even when actually sent via Network RID, is assumed to be 1440 public; all other information contained in registries for 1441 lookup using the UAS ID is assumed to be private. 1443 PRIV-5 Pseudonymous Rendezvous: DRIP MAY enable mutual discovery of 1444 and communications among participating UAS operators whose UA 1445 are in 4-D proximity, using the UAS ID without revealing 1446 pilot/operator identity or physical location. 1448 In some jurisdictions, the configurable enabling and disabling of 1449 encryption may need to be outside the control of the operator. 1450 [FRUR] mandates manufacturers design RID equipment with some degree 1451 of tamper resistance; the preamble and other FAA commentary suggest 1452 this is to reduce the likelihood that an operator, intentionally or 1453 unintentionally, might alter the values of the required data elements 1454 or disable their transmission in the required manner (e.g., as 1455 cleartext). 1457 How information is stored on end systems is out of scope for DRIP. 1458 Encouraging privacy best practices, including end system storage 1459 encryption, by facilitating it with protocol design reflecting such 1460 considerations, is in scope. Similar logic applies to methods for 1461 designating information as public or private. 1463 The privacy requirements above are for DRIP, neither for [F3411-19] 1464 (which requires obfuscation of location to any Network RID subscriber 1465 engaging in wide area surveillance, limits data retention periods, 1466 etc., in the interests of privacy), nor for UAS RID in any specific 1467 jurisdiction (which may have its own regulatory requirements). The 1468 requirements above are also in a sense parameterized: who are the 1469 "authorized actors", how are they designated, how are they 1470 authenticated, etc.? 1472 4.4. Registries 1474 REG-1 Public Lookup: DRIP MUST enable lookup, from the UAS ID, of 1475 information designated by cognizant authority as public, and 1476 MUST NOT restrict access to this information based on identity 1477 or role of the party submitting the query. 1479 REG-2 Private Lookup: DRIP MUST enable lookup of private information 1480 (i.e., any and all information in a registry, associated with 1481 the UAS ID, that is designated by neither cognizant authority 1482 nor the information owner as public), and MUST, according to 1483 applicable policy, enforce AAA, including restriction of 1484 access to this information based on identity or role of the 1485 party submitting the query. 1487 REG-3 Provisioning: DRIP MUST enable provisioning registries with 1488 static information on the UAS and its operator, dynamic 1489 information on its current operation within the U-space/UTM 1490 (including means by which the USS under which the UAS is 1491 operating may be contacted for further, typically even more 1492 dynamic, information), and Internet direct contact information 1493 for services related to the foregoing. 1495 REG-4 AAA Policy: DRIP AAA MUST be specifiable by policies; the 1496 definitive copies of those policies must be accessible in 1497 registries; administration of those policies and all DRIP 1498 registries must be protected by AAA. 1500 Registries are fundamental to RID. Only very limited information can 1501 be Broadcast, but extended information is sometimes needed. The most 1502 essential element of information sent is the UAS ID itself, the 1503 unique key for lookup of extended information in registries. Beyond 1504 designating the UAS ID as that unique key, the registry information 1505 model is not specified herein, in part because regulatory 1506 requirements for different registries (UAS operators and their UA, 1507 each narrowly for UAS RID and broadly for U-space/UTM) and business 1508 models for meeting those requirements are in flux. However those may 1509 evolve, the essential registry functions remain the same, so are 1510 specified herein. 1512 5. IANA Considerations 1514 This document does not make any IANA request. 1516 6. Security Considerations 1518 DRIP is all about safety and security, so content pertaining to such 1519 is not limited to this section. This document does not define any 1520 protocols, so security considerations of such are speculative. 1521 Potential vulnerabilities of DRIP solutions to these requirements 1522 include but are not limited to: 1524 * Sybil attacks 1526 * confusion created by many spoofed unsigned messages 1528 * processing overload induced by attempting to verify many spoofed 1529 signed messages (where verification will fail but still consume 1530 cycles) 1532 * malicious or malfunctioning registries 1534 * interception of (e.g., Man In The Middle attacks on) registration 1535 messages 1537 * UA impersonation through private key extraction, improper key 1538 sharing, or carriage of a small (presumably harmless) UA, i.e., as 1539 a "false flag", by a larger (malicious) UA 1541 It may be inferred from the general requirements (Section 4.1) for 1542 provable ownership, provable binding, and provable registration, 1543 together with the identifier requirements (Section 4.2), that DRIP 1544 must provide: 1546 * message integrity 1548 * non-repudiation 1550 * defense against replay attacks 1552 * defense against spoofing 1554 One approach to so doing involves verifiably binding the DRIP 1555 identifier to a public key. Providing these security features, 1556 whether via this approach or another, is likely to be especially 1557 challenging for Observers without Internet connectivity at the time 1558 of observation. For example, checking the signature of a registry on 1559 a public key certificate received via Broadcast RID in a remote area 1560 presumably would require that the registry's public key had been 1561 previously installed on the Observer's device, yet there may be many 1562 registries and the Observer's device may be storage constrained, and 1563 new registries may come on-line subsequent to installation of DRIP 1564 software on the Observer's device. Thus there may be caveats on the 1565 extent to which requirements can be satisfied in such cases, yet 1566 strenuous effort should be made to satisfy them, as such cases, e.g., 1567 firefighting in a national forest, are important. 1569 7. Privacy and Transparency Considerations 1571 Privacy and transparency are important for legal reasons including 1572 regulatory consistency. [EU2018] states "harmonised and 1573 interoperable national registration systems... should comply with the 1574 applicable Union and national law on privacy and processing of 1575 personal data, and the information stored in those registration 1576 systems should be easily accessible." 1578 Privacy and transparency (where essential to security or safety) are 1579 also ethical and moral imperatives. Even in cases where old 1580 practices (e.g., automobile registration plates) could be imitated, 1581 when new applications involving PII (such as UAS RID) are addressed 1582 and newer technologies could enable improving privacy, such 1583 opportunities should not be squandered. Thus it is recommended that 1584 all DRIP work give due regard to [RFC6973] and more broadly 1585 [RFC8280]. 1587 However, privacy and transparency are often conflicting goals, 1588 demanding careful attention to their balance. 1590 DRIP information falls into two classes: that which, to achieve the 1591 purpose, must be published openly as cleartext, for the benefit of 1592 any Observer (e.g., the basic UAS ID itself); and that which must be 1593 protected (e.g., PII of pilots) but made available to properly 1594 authorized parties (e.g., public safety personnel who urgently need 1595 to contact pilots in emergencies). 1597 How properly authorized parties are authorized, authenticated, etc. 1598 are questions that extend beyond the scope of DRIP, but DRIP may be 1599 able to provide support for such processes. Classification of 1600 information as public or private must be made explicit and reflected 1601 with markings, design, etc. Classifying the information will be 1602 addressed primarily in external standards; herein it will be regarded 1603 as a matter for CAA, registry, and operator policies, for which 1604 enforcement mechanisms will be defined within the scope of DRIP WG 1605 and offered. Details of the protection mechanisms will be provided 1606 in other DRIP documents. Mitigation of adversarial correlation will 1607 also be addressed. 1609 8. References 1611 8.1. Normative References 1613 [F3411-19] ASTM International, "Standard Specification for Remote ID 1614 and Tracking", February 2020, 1615 . 1617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1618 Requirement Levels", BCP 14, RFC 2119, 1619 DOI 10.17487/RFC2119, March 1997, 1620 . 1622 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1623 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1624 May 2017, . 1626 8.2. Informative References 1628 [Amended] European Union Aviation Safety Agency (EASA), "Commission 1629 Delegated Regulation (EU) 2020/1058 of 27 April 2020 1630 amending Delegated Regulation (EU) 2019/945", April 2020, 1631 . 1634 [ASDRI] ASD-STAN, "Introduction to the European UAS Digital Remote 1635 ID Technical Standard", January 2021, . 1639 [CPDLC] Gurtov, A., Polishchuk, T., and M. Wernberg, "Controller- 1640 Pilot Data Link Communication Security", MDPI 1641 Sensors 18(5), 1636, 2018, 1642 . 1644 [CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", 1645 September 2019, . 1648 [Delegated] 1649 European Union Aviation Safety Agency (EASA), "Commission 1650 Delegated Regulation (EU) 2019/945 of 12 March 2019 on 1651 unmanned aircraft systems and on third-country operators 1652 of unmanned aircraft systems", March 2019, 1653 . 1655 [drip-architecture] 1656 Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., and 1657 A. Gurtov, "Drone Remote Identification Protocol (DRIP) 1658 Architecture", Work in Progress, Internet-Draft, draft- 1659 ietf-drip-arch-08, 21 January 2021, 1660 . 1662 [ENISACSIRT] 1663 European Union Agency for Cybersecurity (ENISA), 1664 "Actionable information for Security Incident Response", 1665 November 2014, . 1669 [EU2018] European Parliament and Council, "2015/0277 (COD) PE-CONS 1670 2/18", February 2018, 1671 . 1674 [FAACONOPS] 1675 FAA Office of NextGen, "UTM Concept of Operations v2.0", 1676 March 2020, . 1679 [FRUR] Federal Aviation Administration, "Remote Identification of 1680 Unmanned Aircraft", January 2021, 1681 . 1685 [I-D.maeurer-raw-ldacs] 1686 Maeurer, N., Graeupl, T., and C. Schmitt, "L-band Digital 1687 Aeronautical Communications System (LDACS)", Work in 1688 Progress, Internet-Draft, draft-maeurer-raw-ldacs-06, 2 1689 October 2020, 1690 . 1692 [ICAOATM] International Civil Aviation Organization, "Doc 4444: 1693 Procedures for Air Navigation Services: Air Traffic 1694 Management", November 2016, . 1698 [ICAOUAS] International Civil Aviation Organization, "Circular 328: 1699 Unmanned Aircraft Systems", February 2011, 1700 . 1703 [ICAOUTM] International Civil Aviation Organization, "Unmanned 1704 Aircraft Systems Traffic Management (UTM) - A Common 1705 Framework with Core Principles for Global Harmonization, 1706 Edition 3", October 2020, 1707 . 1710 [Implementing] 1711 European Union Aviation Safety Agency (EASA), "Commission 1712 Implementing Regulation (EU) 2019/947 of 24 May 2019 on 1713 the rules and procedures for the operation of unmanned 1714 aircraft", May 2019, 1715 . 1717 [InitialView] 1718 SESAR Joint Undertaking, "Initial view on Principles for 1719 the U-space architecture", July 2019, 1720 . 1724 [NPRM] United States Federal Aviation Administration (FAA), 1725 "Notice of Proposed Rule Making on Remote Identification 1726 of Unmanned Aircraft Systems", December 2019, 1727 . 1731 [OpenDroneID] 1732 Intel Corp., "Open Drone ID", March 2019, 1733 . 1735 [Opinion1] European Union Aviation Safety Agency (EASA), "Opinion No 1736 01/2020: High-level regulatory framework for the U-space", 1737 March 2020, . 1740 [Part107] United States Federal Aviation Administration, "Code of 1741 Federal Regulations Part 107", June 2016, 1742 . 1744 [Recommendations] 1745 FAA UAS Identification and Tracking Aviation Rulemaking 1746 Committee, "UAS ID and Tracking ARC Recommendations Final 1747 Report", September 2017, . 1751 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1752 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1753 DOI 10.17487/RFC4122, July 2005, 1754 . 1756 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1757 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1758 . 1760 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1761 Morris, J., Hansen, M., and R. Smith, "Privacy 1762 Considerations for Internet Protocols", RFC 6973, 1763 DOI 10.17487/RFC6973, July 2013, 1764 . 1766 [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights 1767 Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, 1768 October 2017, . 1770 [Roadmap] American National Standards Institute (ANSI) Unmanned 1771 Aircraft Systems Standardization Collaborative (UASSC), 1772 "Standardization Roadmap for Unmanned Aircraft Systems 1773 draft v2.0", April 2020, . 1777 [Stranger] Heinlein, R.A., "Stranger in a Strange Land", June 1961. 1779 [WG105] EUROCAE, "WG-105 draft ED-282 Minimum Operational 1780 Performance Standards (MOPS) for Unmanned Aircraft System 1781 (UAS) Electronic Identification", June 2020. 1783 [WiFiNAN] Wi-Fi Alliance, "Wi-Fi Aware™ Specification Version 3.2", 1784 October 2020, . 1787 Appendix A. Discussion and Limitations 1789 This document is largely based on the process of one SDO, ASTM. 1790 Therefore, it is tailored to specific needs and data formats of this 1791 standard. Other organizations, for example in EU, do not necessary 1792 follow the same architecture. 1794 The need for drone ID and operator privacy is an open discussion 1795 topic. For instance, in the ground vehicular domain each car carries 1796 a publicly visible plate number. In some countries, for nominal cost 1797 or even for free, anyone can resolve the identity and contact 1798 information of the owner. Civil commercial aviation and maritime 1799 industries also have a tradition of broadcasting plane or ship ID, 1800 coordinates, and even flight plans in plain text. Community networks 1801 such as OpenSky and Flightradar use this open information through 1802 ADS-B to deploy public services of flight tracking. Many researchers 1803 also use these data to perform optimization of routes and airport 1804 operations. Such ID information should be integrity protected, but 1805 not necessarily confidential. 1807 In civil aviation, aircraft identity is broadcast by a device known 1808 as transponder. It transmits a four-digit squawk code, which is 1809 assigned by a traffic controller to an airplane after approving a 1810 flight plan. There are several reserved codes such as 7600 which 1811 indicate radio communication failure. The codes are unique in each 1812 traffic area and can be re-assigned when entering another control 1813 area. The code is transmitted in plain text by the transponder and 1814 also used for collision avoidance by a system known as Traffic alert 1815 and Collision Avoidance System (TCAS). The system could be used for 1816 UAS as well initially, but the code space is quite limited and likely 1817 to be exhausted soon. The number of UAS far exceeds the number of 1818 civil airplanes in operation. 1820 The ADS-B system is utilized in civil aviation for each "ADS-B Out" 1821 equipped airplane to broadcast its ID, coordinates, and altitude for 1822 other airplanes and ground control stations. If this system is 1823 adopted for drone IDs, it has additional benefit with backward 1824 compatibility with civil aviation infrastructure; then, pilots and 1825 dispatchers will be able to see UA on their control screens and take 1826 those into account. If not, a gateway translation system between the 1827 proposed drone ID and civil aviation system should be implemented. 1828 Again, system saturation due to large numbers of UAS is a concern. 1830 Wi-Fi and Bluetooth are two wireless technologies currently 1831 recommended by ASTM specifications due to their widespread use and 1832 broadcast nature. However, those have limited range (max 100s of 1833 meters) and may not reliably deliver UAS ID at high altitude or 1834 distance. Therefore, a study should be made of alternative 1835 technologies from the telecom domain (WiMAX / IEEE 802.16, 5G) or 1836 sensor networks (Sigfox, LORA). Such transmission technologies can 1837 impose additional restrictions on packet sizes and frequency of 1838 transmissions, but could provide better energy efficiency and range. 1839 In civil aviation, Controller-Pilot Data Link Communications (CPDLC) 1840 is used to transmit command and control between the pilots and ATC. 1841 It could be considered for UAS as well due to long range and proven 1842 use despite its lack of security [CPDLC]. 1844 L-band Digital Aeronautical Communications System (LDACS) is being 1845 standardized by ICAO and IETF for use in future civil aviation 1846 [I-D.maeurer-raw-ldacs]. It provides secure communication, 1847 positioning, and control for aircraft using a dedicated radio band. 1848 It should be analyzed as a potential provider for UAS RID as well. 1849 This will bring the benefit of a global integrated system creating a 1850 global airspace use awareness. 1852 Acknowledgments 1854 The work of the FAA's UAS Identification and Tracking (UAS ID) 1855 Aviation Rulemaking Committee (ARC) is the foundation of later ASTM 1856 [F3411-19] and IETF DRIP efforts. The work of Gabriel Cox, Intel 1857 Corp., and their Open Drone ID collaborators opened UAS RID to a 1858 wider community. The work of ASTM F38.02 in balancing the interests 1859 of diverse stakeholders is essential to the necessary rapid and 1860 widespread deployment of UAS RID. IETF volunteers who have 1861 extensively reviewed or otherwise contributed to this document 1862 include Amelia Andersdotter, Carsten Bormann, Mohamed Boucadair, 1863 Toerless Eckert, Susan Hares, Mika Jarvenpaa, Daniel Migault, 1864 Alexandre Petrescu, Saulo Da Silva and Shuai Zhao. 1866 Authors' Addresses 1868 Stuart W. Card (editor) 1869 AX Enterprize 1870 4947 Commercial Drive 1871 Yorkville, NY 13495 1872 United States of America 1874 Email: stu.card@axenterprize.com 1876 Adam Wiethuechter 1877 AX Enterprize 1878 4947 Commercial Drive 1879 Yorkville, NY 13495 1880 United States of America 1882 Email: adam.wiethuechter@axenterprize.com 1884 Robert Moskowitz 1885 HTT Consulting 1886 Oak Park, MI 48237 1887 United States of America 1889 Email: rgm@labs.htt-consult.com 1890 Andrei Gurtov 1891 Linköping University 1892 IDA 1893 SE-58183 Linköping 1894 Sweden 1896 Email: gurtov@acm.org