[要約] RFC 9153は、ドローンの遠隔識別プロトコル（DRIP）の要件と用語を定義します。この文書の目的は、ドローンの安全な統合と識別を支援するための標準を確立することです。利用場面には、航空交通管理、プライバシー保護、セキュリティ対策が含まれます。
Internet Engineering Task Force (IETF) S. Card, Ed.
Request for Comments: 9153 A. Wiethuechter
Category: Informational AX Enterprize
ISSN: 2070-1721 R. Moskowitz
HTT Consulting
A. Gurtov
Linköping University
February 2022
Drone Remote Identification Protocol (DRIP) Requirements and Terminology
ドローンリモート識別プロトコル（DRIP）要件と用語
Abstract
概要
This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) Working Group. These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy.
この文書は、ドローンリモート識別プロトコル（DRIP）ワーキンググループによって作成されたソリューションの用語と要件を定義しています。これらの解決策は、セキュリティ、安全性、およびその他の目的のための無人航空機システムのリモート識別と追跡（UASアプリケーションをサポートするIdentityベースのネットワークセッションの開始）をサポートします。DRIPは、RIDをサポートし、関連サービスを強化できるようにするために既存のインターネットリソースの使用を容易にし、RID情報が信頼できることをオンラインおよびオフラインで検証することができます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。それは情報提供のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書はインターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それはパブリックレビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9153.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9153で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF信頼と文書の著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
1.1. Motivation and External Influences
1.2. Concerns and Constraints
1.3. DRIP Scope
1.4. Document Scope
2. Terms and Definitions
2.1. Requirements Terminology
2.2. Definitions
3. UAS RID Problem Space
3.1. Network RID
3.2. Broadcast RID
3.3. USS in UTM and RID
3.4. DRIP Focus
4. Requirements
4.1. General
4.1.1. Normative Requirements
4.1.2. Rationale
4.2. Identifier
4.2.1. Normative Requirements
4.2.2. Rationale
4.3. Privacy
4.3.1. Normative Requirements
4.3.2. Rationale
4.4. Registries
4.4.1. Normative Requirements
4.4.2. Rationale
5. IANA Considerations
6. Security Considerations
7. Privacy and Transparency Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Discussion and Limitations
Acknowledgments
Authors' Addresses
This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) Working Group. These solutions will support Unmanned Aircraft System Remote Identification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existing Internet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy.
この文書は、ドローンリモート識別プロトコル（DRIP）ワーキンググループによって作成されたソリューションの用語と要件を定義しています。これらの解決策は、セキュリティ、安全性、およびその他の目的のための無人航空機システムのリモート識別と追跡（UASアプリケーションをサポートするIdentityベースのネットワークセッションの開始）をサポートします。DRIPは、RIDをサポートし、関連サービスを強化できるようにするために既存のインターネットリソースの使用を容易にし、RID情報が信頼できることをオンラインおよびオフラインで検証することができます。
For any unfamiliar or a priori ambiguous terminology herein, see Section 2.
ここでのいかなる不慣れなまたは先験的なあいまいな用語については、セクション2を参照のこと。
Many considerations (especially safety and security) necessitate Unmanned Aircraft System Remote Identification and tracking (UAS RID).
多くの考慮事項（特に安全性とセキュリティ）は、無人航空機システムの遠隔識別と追跡を必要としています（UAS RID）。
Unmanned Aircraft (UA) may be fixed-wing, rotary-wing (e.g., helicopter), hybrid, balloon, rocket, etc. Small fixed-wing UA typically have Short Take-Off and Landing (STOL) capability; rotary-wing and hybrid UA typically have Vertical Take-Off and Landing (VTOL) capability. UA may be single- or multi-engine. The most common today are multicopters (rotary-wing, multi-engine). The explosion in UAS was enabled by hobbyist development of advanced flight stability algorithms for multicopters that enabled even inexperienced pilots to take off, fly to a location of interest, hover, and return to the takeoff location or land at a distance. UAS can be remotely piloted by a human (e.g., with a joystick) or programmed to proceed from Global Navigation Satellite System (GNSS) waypoint to waypoint in a weak form of autonomy; stronger autonomy is coming.
無人機（UA）は、固定翼、回転翼（例えば、ヘリコプター）、ハイブリッド、バルーン、ロケットなどであり得る。小さな固定翼UAは通常、短い離陸および着陸（石）能力を有する。ロータリーウィングとハイブリッドUAは通常、垂直離陸および着陸（VTOL）機能を有する。UAは単一またはマルチエンジンであり得る。今日最も一般的なものはマルチコプター（ロータリーウィング、マルチエンジン）です。UASの爆発は、経験の浅いパイロットでさえ離陸することができ、関心のある場所に飛ぶことができるマルチコプターのための高度な飛行安定アルゴリズムの趣味の開発によって有効にされました。UASは、人間（例えばジョイスティックで）によって遠隔操作されていてもよく、またはグローバルナビゲーション衛星システム（GNSS）ウェイポイントから弱い形の自治体で進むようにプログラムされることができる。より強い自治が来ています。
Small UA are "low observable" as they:
小さいUAは、「低観測」です。
* typically have small radar cross sections;
* 典型的には小さなレーダ断面を有する。
* make noise that is quite noticeable at short ranges but difficult to detect at distances they can quickly close (500 meters in under 13 seconds by the fastest consumer mass-market drones available in early 2021);
* 短い範囲でかなり目立つ騒音を作るが、距離で検出するのが難しく、急速に閉じることができる（2021年初めて入手可能な最速の消費者の大量マーケットドローンによって13秒以内に500メートル）。
* typically fly at low altitudes (e.g., under 400 feet Above Ground Level (AGL) for UA to which RID applies in the US, as per [Part107]); and
* 典型的には低い高度で（例えば、米国で米国に適用されるUAのための400フィートの下で400フィート未満）で飛ぶ。と
* are highly maneuverable and thus can fly under trees and between buildings.
* 非常に操作可能で、したがって木の下や建物の間で飛ぶことができます。
UA can carry payloads (including sensors, cyber weapons, and kinetic weapons) or can be used themselves as weapons by flying them into targets. They can be flown by clueless, careless, or criminal operators. Thus, the most basic function of UAS RID is "Identification Friend or Foe (IFF)" to mitigate the significant threat they present.
UAはペイロード（センサー、サイバー武器、および運動兵器を含む）を運ぶことができますか、またはそれらをターゲットに飛ばして武器として使用することができます。彼らは、無知、不注意な、または犯罪者によって飛行することができます。したがって、UAS RIDの最も基本的な機能は、彼らが存在する重大な脅威を軽減するために「識別友人や敵（IFF）」です。
Diverse other applications can be enabled or facilitated by RID. Internet protocols typically start out with at least one entity already knowing an identifier or locator of another; but an entity (e.g., UAS or Observer device) encountering an a priori unknown UA in physical space has no identifier or logical space locator for that UA, unless and until one is provided somehow. RID provides an identifier, which, if well chosen, can facilitate use of a variety of Internet family protocols and services to support arbitrary applications beyond the basic security functions of RID. For most of these, some type of identifier is essential, e.g., Network Access Identifier (NAI), Digital Object Identifier (DOI), Uniform Resource Identifier (URI), domain name, or public key. DRIP motivations include both the basic security and the broader application support functions of RID. The general scenario is illustrated in Figure 1.
他の多様なアプリケーションは、RIDによって有効または促進することができます。インターネットプロトコルは通常、既に識別子またはロケータを知っている少なくとも1つのエンティティで起動します。しかし、物理空間内の先験的に未知のUAに遭遇するエンティティ（例えば、UASまたはオブザーバデバイス）は、どういうわけか、そして何が提供されない限り、そのUAのための識別子または論理スペースロケータはない。RIDは識別子を提供します。これは、RIDの基本的なセキュリティ機能を超えて任意のアプリケーションをサポートするために、さまざまなインターネットファミリプロトコルやサービスの使用を容易にすることができます。これらのほとんどの場合、いくつかの種類の識別子は必須、例えば、ネットワークアクセス識別子（NAI）、デジタルオブジェクト識別子（DOI）、統一リソース識別子（URI）、ドメイン名、または公開鍵である。DRIPの動機は、RIDの基本的なセキュリティとより広いアプリケーションサポート機能の両方を含みます。一般的なシナリオを図1に示します。
+-----+ +-----+
| UA1 | | UA2 |
+-----+ +-----+
+----------+ +----------+
| General | | Public |
| Public | | Safety |
| Observer o------\ /------o Observer |
+----------+ | | +----------+
| |
*************
+----------+ * * +----------+
| UA1 | * * | UA2 |
| Pilot/ o------* Internet *------o Pilot/ |
| Operator | * * | Operator |
+----------+ * * +----------+
*************
| | |
+----------+ | | | +----------+
| Public o---/ | \---o Private |
| Registry | | | Registry |
+----------+ | +----------+
+--o--+
| DNS |
+-----+
Figure 1: General UAS RID Usage Scenario
図1：一般的なUAS RID使用シナリオ
Figure 1 illustrates a typical case where there may be the following:
図1は、次のような典型的な場合を示しています。
* multiple Observers, some of them members of the general public and others government officers with public safety and security responsibilities,
* 複数の観察者、彼らの何人かの一般の公的およびその他の政府職員の公的安全性とセキュリティの責任を持つ役員
* multiple UA in flight within observation range, each with its own pilot/operator,
* 観測範囲内のフライト内の複数のUA、それぞれ独自のパイロット/オペレータを備えた
* at least one registry each for lookup of public and (by authorized parties only) private information regarding the UAS and their pilots/operators, and
* 公共の検索および（許可された締約国によってのみ）UASとそのパイロット/演算子に関する個人情報、および
* in the DRIP vision, DNS resolving various identifiers and locators of the entities involved.
* DRIP VISIONでは、関係するエンティティのさまざまな識別子とロケータを解決するDNS。
Note the absence of any links to/from the UA in the figure; this is because UAS RID and other connectivity involving the UA varies. Some connectivity paths do or do not exist depending upon the scenario. Command and Control (C2) from the Ground Control Station (GCS) to the UA via the Internet (e.g., using LTE cellular) is expected to become much more common as Beyond Visual Line Of Sight (BVLOS) operations increase; in such a case, there is typically not also a direct wireless link between the GCS and UA. Conversely, if C2 is running over a direct wireless link, then the GCS typically has Internet connectivity, but the UA does not. Further, paths that nominally exist, such as between an Observer device and the Internet, may be severely intermittent. These connectivity constraints are likely to have an impact, e.g., on how reliably DRIP requirements can be satisfied.
図中のUAへのリンク/からのリンクがないことに注意してください。これは、UAS RIDおよびUAを含むその他の接続性が異なるためです。シナリオに応じて、コネクティビティパスの中には存在しません。インターネットを介して（例えば、LTEセルラーを使用する）地上制御ステーション（GCS）からUAへのコマンドおよび制御（C2）は、視覚的な視線（BVLO）の操作の増加のようにはるかに一般的になると予想される。そのような場合、GCSとUAとの間に直接の無線リンクも典型的にはない。逆に、C2が直接無線リンクを介して実行されている場合、GCSは通常インターネット接続を持ちますが、UAはそうではありません。さらに、観察者装置とインターネットとの間のように、名目上存在する経路は厳しく断続的であり得る。これらの接続性の制約は、例えば確実にドリップ要件を満たすことができる方法について、影響を与える可能性があります。
An Observer of UA may need to classify them, as illustrated notionally in Figure 2, for basic airspace Situational Awareness (SA). An Observer can classify a UAS as one of the following and treat as:
基本的な空域状況認識（SA）のために、図2に概念的に示すように、UAの観察者はそれらを分類する必要があるかもしれません。オブザーバーは、以下のいずれかとしてUASを分類し、次のように扱うことができます。
* Taskable: can ask it to do something useful.
* taskable：役に立つことをするように依頼することができます。
* Low Concern: can reasonably assume it is not malicious and would cooperate with requests to modify its flight plans for safety concerns that arise.
* 低い懸念は悪意のあるものではなく、生じる安全上の懸念のための飛行計画を変更するための要求と合理的に協力することができます。
* High Concern or Unidentified: can focus surveillance on it.
* 高い懸念または不明瞭：監視を焦点を合わせることができます。
xxxxxxx
x x No +--------------+
x ID? x+---->| Unidentified |
x x +--------------+
xxxxxxx
+
| Yes
v
xxxxxxx
x x
.---------+x Type? x+----------.
| x x |
| xxxxxxx |
| + |
v v v
+--------------+ +--------------+ +--------------+
| Taskable | | Low Concern | | High Concern |
+--------------+ +--------------+ +--------------+
Figure 2: Notional UAS Classification
図2：概念UAS分類
The widely cited "Standard Specification for Remote ID and Tracking" [F3411-19] was developed by ASTM International, Technical Committee F38 (UAS), Subcommittee F38.02 (Aircraft Operations), Work Item WK65041. The published standard is available for purchase from ASTM and is also available as an ASTM membership premium; early draft versions are freely available as Open Drone ID specifications [OpenDroneID]. [F3411-19] is frequently referenced in DRIP, where building upon its link layers and both enhancing support for and expanding the scope of its applications are central foci.
「リモートIDと追跡のための標準仕様」[F3411-19]は、ASTM International、Technical Committee F38（UAS）、小委員会F38.02（航空機の運用）、作業項目WK65041によって開発されました。公開されている標準はASTMから購入可能であり、ASTM会員増額料金として入手できます。早期ドラフトバージョンは、オープンドローンID仕様[OpenDroneID]として自由に利用できます。[F3411-19]は頻繁にDRIPで参照されます。そこでは、そのリンク層の上に構築し、その応用の範囲を拡張して拡張し、その応用の範囲を拡大していますが中央焦点です。
In many applications, including UAS RID, identification and identifiers are not ends in themselves; they exist to enable lookups and provision of other services.
UAS RIDを含む多くのアプリケーションでは、識別と識別子は自分自身では終わりません。それらは、他のサービスの検索と提供を可能にするために存在します。
Using UAS RID to facilitate vehicular (i.e., Vehicle-to-Everything (V2X)) communications and applications such as Detect And Avoid (DAA), which would impose tighter latency bounds than RID itself, is an obvious possibility; this is explicitly contemplated in the "Remote Identification of Unmanned Aircraft" rule of the US Federal Aviation Administration (FAA) [FRUR]. However, usage of RID systems and information beyond mere identification (primarily to hold operators accountable after the fact), including DAA, were declared out of scope in ASTM F38.02 WK65041, based on a distinction between RID as a security standard versus DAA as a safety application. Standards Development Organizations (SDOs) in the aviation community generally set a higher bar for safety than for security, especially with respect to reliability. Each SDO has its own cultural set of connotations of safety versus security; the denotative definitions of the International Civil Aviation Organization (ICAO) are cited in Section 2.
UAS RIDを使用して、RID自体よりも厳しい待ち時間の範囲を課すようにするための車両（すなわち、ビヒクルから全部（V2X））の通信およびアプリケーション（DAA）を促進する（DAA）、明らかな可能性がある。これは、米国連邦航空局（FAA）の「無人航空機の遠隔識別」規則（FRUR]の規則で明示的に考えられる。しかし、DAAを含む単なる識別を超えたRIDシステムと情報の使用法（主に事実上の責任者に責任を占める）は、RIDの範囲をセキュリティ規格とDAAとしての区別に基づいて、ASTM F38.02 WK65041の範囲外に宣言されました。安全アプリケーション航空コミュニティにおける標準開発組織（SDO）は、特に信頼性に関して、セキュリティよりも安全のためのより高いバーを設定します。各SDOには、安全対セキュリティの独自の文化的な意味合いがあります。国際民間航空機関（ICAO）の意味定義はセクション2で引用されています。
[Opinion1] and [WG105] cite the Direct Remote Identification (DRI) previously required and specified, explicitly stating that whereas DRI is primarily for security purposes, the "Network Identification Service" [Opinion1] (in the context of U-space [InitialView]) or "Electronic Identification" [WG105] is primarily for safety purposes (e.g., Air Traffic Management, especially hazards deconfliction) and also is allowed to be used for other purposes such as support of efficient operations. These emerging standards allow the security-and safety-oriented systems to be separate or merged. In addition to mandating both Broadcast and Network RID one-way to Observers, they will use Vehicle-to-Vehicle (V2V) to other UAS (also likely to and/or from some manned aircraft). These reflect the broad scope of the European Union (EU) U-space concept, as being developed in the Single European Sky ATM Research (SESAR) Joint Undertaking, the U-space architectural principles of which are outlined in [InitialView].
[Peconict1]と[WG105]が以前に必要とされ、指定された直接のリモート識別（DRI）を引用し、DRIは主にセキュリティ目的で、「ネットワーク識別サービス」[PECIST1]（U-Spaceのコンテキストでの[InitialView） ]）または「電子識別」[WG105]は、主に安全上の目的のため（例えば、航空交通管理、特に危険侵害）であり、また効率的な操作の支援などの他の目的に使用されることが許可されている。これらの新たな基準により、セキュリティおよび安全指向のシステムを別々またはマージすることができます。ブロードキャストとネットワークリッスの両方をオブザーバーに命令することに加えて、それらは他のUAS（いくつかの有人航空機のおよび/またはいくつかの有人航空機）に車両間（V2V）を使用する。これらは、ヨーロッパのヨーロッパの空のATM研究（SESAR）共同研究（SESAR）の共同研究で開発されている欧州連合（EU）U-Spaceの概念の広範な範囲を反映しています。
ASD-STAN is an Associated Body to CEN (European Committee for Standardization) for Aerospace Standards. It has published an EU standard titled "Aerospace series - Unmanned Aircraft Systems - Part 002: Direct Remote Identification" [ASDSTAN4709-002]; a current (early 2021) informal overview is freely available in [ASDRI] (note that [ASDRI] may not precisely reflect the final standard as it was published before [ASDSTAN4709-002]). It will provide compliance to cover the identical DRI requirements applicable to drones of the following classes:
ASD-Stanは、航空宇宙標準のためのCEN（標準化のためのヨーロッパ委員会）への関連機関です。「航空宇宙シリーズ - 無人航空機システム - パート002：ASDSTAN4709-002」と題したEU規格を発表しました。現在の（2021年初頭）非公式の概要は[ASDRI]で自由に利用できます（[ASDRI]が[ASDSTAN4709-002]の前に公開されたように最終規格を正確に反映させることはできません。以下のクラスのドローンに適用可能な同一のDRI要件をカバーする準拠を提供します。
* C1 ([Delegated], Part 2)
* C1（委任委員会）、その2）
* C2 ([Delegated], Part 3)
* C2（委任委員会）
* C3 ([Delegated], Part 4)
* C3（委任委任）、第4報）
* C5 ([Amended], Part 16)
* C5（[修正]、第16号）
* C6 ([Amended], Part 17)
* C6（[修正]、第17回）
The standard contemplated in [ASDRI] will provide UA capability to be identified in real time during the whole duration of the flight, without specific connectivity or ground infrastructure link, utilizing existing mobile devices within broadcast range. It will use Bluetooth 4, Bluetooth 5, Wi-Fi Neighbor Awareness Networking (NAN) (also known as "Wi-Fi Aware" [WiFiNAN]), and/or IEEE 802.11 Beacon modes. The emphasis of the EU standard is compatibility with [F3411-19], although there are differences in mandatory and optional message types and fields.
[ASDRI]で企図される規格は、放送範囲内の既存のモバイル機器を利用して、特定の接続性または地下インフラストラクチャリンクなしで、フライトの全期間中、リアルタイムで識別されるUA機能を提供する。Bluetooth 4、Bluetooth 5、Wi-Fi近隣の認識ネットワーキング（NaN）（「Wi-Fi対応」[WiFinan]）、および/またはIEEE 802.11ビーコンモードを使用します。EU規格の強調は[F3411-19]との互換性がありますが、必須のメッセージタイプとフィールドには違いがあります。
The DRI system contemplated in [ASDRI] will broadcast the following locally:
[ASDRI]で考えられるDRIシステムは、ローカルに次のようにブロードキャストされます。
1. the UAS operator registration number;
1. UASオペレータ登録番号。
2. the [CTA2063A]-compliant unique serial number of the UA;
2. UAの[CTA2063A] - Compliant一意のシリアル番号。
3. a time stamp, the geographical position of the UA, and its height AGL or above its takeoff point;
3. タイムスタンプ、UAの地理的位置、およびその高さAGLまたはその離陸ポイントの上。
4. the UA ground speed and route course measured clockwise from true north;
4. UAの地上速度と経路経路は、真の北から時計回りに測定されました。
5. the geographical position of the Remote Pilot, or if that is not available, the geographical position of the UA takeoff point; and
5. リモートパイロットの地理的な位置、またはそれが利用できない場合は、UAの離陸ポイントの地理的位置です。と
6. for classes C1, C2, C3, the UAS emergency status.
6. クラスC1、C2、C3、UAS緊急ステータス。
Under the standard contemplated in [ASDRI], data will be sent in plaintext, and the UAS operator registration number will be represented as a 16-byte string including the (European) state code. The corresponding private ID part will contain three characters that are not broadcast but used by authorities to access regional registration databases for verification.
[ASDRI]で企図される標準の下で、データは平文で送信され、UAS演算子登録番号は（ヨーロッパ）の状態コードを含む16バイトの文字列として表されます。対応するプライベートID部分には、ブロードキャストされていない3文字が含まれていますが、検証のために地域登録データベースにアクセスするための当局によって使用されます。
ASD-STAN also contemplates corresponding Network Remote Identification (NRI) functionality. ASD-STAN plans to revise their current standard with additional functionality (e.g., DRIP) to be published no later than 2022 [ASDRI].
ASD-Stanはまた、対応するネットワークリモート識別（NRI）機能を企図しています。ASD-STANは、2022年以降で公開されていない追加の機能（例えばDRIP）で現在の規格を修正することを計画しています[ASDRI]。
Security-oriented UAS RID essentially has two goals: 1) enable the general public to obtain and record an opaque ID for any observed UA, which they can then report to authorities and 2) enable authorities, from such an ID, to look up information about the UAS and its operator. Safety-oriented UAS RID has stronger requirements.
セキュリティ指向UAS RIDは基本的に2つの目標を持っています。UASとそのオペレータについて。安全指向のUAS RIDはより強い要件を持っています。
Dynamic establishment of secure communications between the Observer and the UAS pilot seems to have been contemplated by the FAA UAS ID and Tracking Aviation Rulemaking Committee (ARC) in [Recommendations]; however, aside from DRIP, it is not addressed in any of the subsequent regulations or international SDO technical specifications known to the authors as of early 2021.
オブザーバーとUASパイロットとの間の安全な通信の動的確立は、FAA UAS IDおよびトラッキング航空ルーミーション委員会（ARC）が[推奨事項]で企図されているように思われる。ただし、DRIPとは別に、2021年初めの著者に知られているその後の規制または国際SDOの技術仕様のいずれには対処されていません。
Disambiguation of multiple UA flying in close proximity may be very challenging, even if each is reporting its identity, position, and velocity as accurately as it can.
たとえそれぞれが可能な限り正確にそのアイデンティティ、位置、および速度を報告しているとしても、非常に困難であるかもしれません。
The origin of information in UAS RID and UAS Traffic Management (UTM) generally is the UAS or its operator. Self-reports may be initiated by the Remote Pilot at the console of the GCS (the UAS subsystem used to remotely operate the UA) or automatically by GCS software; in Broadcast RID, they are typically initiated automatically by a process on the UA. Data in the reports may come from sensors available to the operator (e.g., radar or cameras), the GCS (e.g., "dead reckoning" UA location, starting from the takeoff location and estimating the displacements due to subsequent piloting commands, wind, etc.), or the UA itself (e.g., an on-board GNSS receiver). In Broadcast RID, all the data must be sent proximately by the UA, and most of the data ultimately comes from the UA. Whether information comes proximately from the operator or from automated systems configured by the operator, there are possibilities of unintentional error in and intentional falsification of this data. Mandating UAS RID, specifying data elements required to be sent, monitoring compliance, and enforcing compliance (or penalizing non-compliance) are matters for Civil Aviation Authorities (CAAs) and potentially other authorities. Specifying message formats and supporting technologies to carry those data elements has been addressed by other SDOs. Offering technical means, as extensions to external standards, to facilitate verifiable compliance and enforcement/monitoring is an opportunity for DRIP.
UAS RIDおよびUASトラフィック管理（UTM）内の情報の起源は、一般にUASまたはそのオペレータである。自己レポートは、GCSのコンソールでリモートパイロット（UAのリモートで使用されているUASサブシステム）またはGCSソフトウェアによって自動的に開始される可能性があります。ブロードキャストRIDでは、それらは通常、UA上のプロセスによって自動的に開始されます。レポート内のデータは、演算子（例えば、レーダまたはカメラ）、GCS（例えば、「デッド航法」UAの位置（例えば、「デッド航法」UAの位置、およびその後の操縦コマンド、風などによる変位を推定する。 。）、またはUA自体（例えば、オンボードGNSS受信機）。ブロードキャストRIDでは、すべてのデータをUAによって近くに送信する必要があり、ほとんどのデータは最終的にUAから来る。情報がオペレータまたはオペレータによって構成された自動化されたシステムからの近くに、またはこのデータの意図的な誤りと意図的な改ざんの可能性があります。 UAS RIDを命令する、送信する必要があるデータ要素を指定し、コンプライアンスを監視し、コンプライアンスを強制する（または不適合を罰する）、民間航空当局（CAAS）とその潜在的に他の当局のための事項は重要です。これらのデータ要素を運ぶためのメッセージフォーマットとサポート技術の指定は、他のSDOによってアドレス指定されています。検証可能なコンプライアンスと執行/監視を容易にするために、外部標準への拡張として技術的な手段を提供することは、DRIPの機会です。
Minimal specified information must be made available to the public. Access to other data, e.g., UAS operator Personally Identifiable Information (PII), must be limited to strongly authenticated personnel, properly authorized in accordance with applicable policy. The balance between privacy and transparency remains a subject for public debate and regulatory action; DRIP can only offer tools to expand the achievable trade space and enable trade-offs within that space. [F3411-19], the basis for most current (2021) thinking about and efforts to provide UAS RID, specifies only how to get the UAS ID to the Observer: how the Observer can perform these lookups and how the registries first can be populated with information are not specified therein.
指定された情報は、一般に公開されている必要があります。他のデータ、例えばUASオペレータの個人的に識別可能な情報（PII）へのアクセスは、適用されるポリシーに従って適切に承認されている、強く認証された要員に限定されなければならない。プライバシーと透明性のバランスは、公共の議論と規制行動の対象です。DRIPは達成可能な貿易スペースを拡大し、そのスペース内でトレードオフを可能にするためのツールを提供することしかできません。[F3411-19]、UAS RIDを提供するためのほとんどの最新の（2021）の考察の基礎と、UAS RIDを提供するための努力を指定する方法は、オブザーバにUAS IDを取得する方法だけを指定します。情報が指定されていません。
The need for nearly universal deployment of UAS RID is pressing: consider how negligible the value of an automobile license plate system would be if only 90% of the cars displayed plates. This implies the need to support use by Observers of already-ubiquitous mobile devices (typically smartphones and tablets). Anticipating CAA requirements to support legacy devices, especially in light of [Recommendations], [F3411-19] specifies that any UAS sending Broadcast RID over Bluetooth must do so over Bluetooth 4, regardless of whether it also does so over newer versions. As UAS sender devices and Observer receiver devices are unpaired, this unpaired state requires use of the extremely short BT4 "advertisement" (beacon) frames.
UAS RIDのほぼ普遍的な展開の必要性はプレスしています。自動車のナンバープレートシステムの価値が、車の90％しか表示されている場合には無視できないことを検討してください。これは、すでに既知のモバイルデバイス（通常はスマートフォンとタブレット）のオブザーバによる使用をサポートする必要性を意味します。特に[推奨事項]に照らして、レガシーデバイスをサポートするCAA要件を予想する[F3411-19]は、Bluetoothを介してブロードキャストRID RID RID RID RIDを送信しなければならないUASを、それが新しいバージョンを超えてもかまらないかにかかわらず、Bluetooth 4を介して行わなければならないことを指定します。UAS送信機デバイスおよびオブザーバ受信装置が不適切であるため、この不安定な状態は、非常に短いBT4「広告」（ビーコン）フレームの使用を必要とする。
Wireless data links to or from UA are challenging. Flight is often amidst structures and foliage at low altitudes over varied terrain. UA are constrained in both total energy and instantaneous power by their batteries. Small UA imply small antennas. Densely populated volumes will suffer from link congestion: even if UA in an airspace volume are few, other transmitters nearby on the ground, sharing the same license free spectral band, may be many. Thus, air-to-air and air-to-ground links will generally be slow and unreliable.
UAまたはUAへの無線データリンクは困難です。フライトは、さまざまな地形で低標準で、構造や葉の中でしばしば河川です。UAは、それらの電池によって全エネルギーと瞬間的な電力の両方で制約されています。小さいUAは小さなアンテナを意味します。密集したボリュームはリンクの輻輳に苦しんでいます。したがって、空気への空気と空気から空気へのリンクは一般に遅く、信頼性が低くなります。
UAS Cost, Size, Weight, and Power (CSWaP) constraints are severe. CSWaP is a burden not only on the designers of new UAS for sale but also on owners of existing UAS that must be retrofit. Radio Controlled (RC) aircraft modelers, "hams" who use licensed amateur radio frequencies to control UAS, drone hobbyists, and others who custom build UAS all need means of participating in UAS RID that are sensitive to both generic CSWaP and application-specific considerations.
UASコスト、サイズ、重量、および電源（CSWAP）の制約は厳しくなります。CSWAPは、販売のための新しいUASの設計者だけでなく、既存のUASの所有者にも後付けでなければならない負担です。AMATURの無線周波数を使用してUAS、ドローンホビーリストなどを使用するラジオ制御（RC）航空機モデラー、「ハム」は、一般的なCSWAPとアプリケーション固有の考慮事項の両方に敏感なUAS RIDに参加する手段を必要としています。。
To accommodate the most severely constrained cases, all of the concerns described above conspire to motivate system design decisions that complicate the protocol design problem.
最も厳しい拘束されたケースに対応するために、上記のすべての懸念は、プロトコル設計上の問題を複雑にするシステム設計決定をやると協調しています。
Broadcast RID uses one-way local data links. UAS may have Internet connectivity only intermittently, or not at all, during flight.
ブロードキャストRIDは一方向のローカルデータリンクを使用します。フライト中に、UASは断続的にインターネット接続性を持つことができます。
Internet-disconnected operation of Observer devices has been deemed by ASTM F38.02 as too infrequent to address. However, the preamble to [FRUR] cites "remote and rural areas that do not have reliable Internet access" as a major reason for requiring Broadcast rather than Network RID. [FRUR] also states:
オブザーバーデバイスのインターネット切断操作は、アドレスにはまれにあまりにも頻度であまりにも、ASTM F38.02と見なされています。ただし、ネットワークRIDではなくブロードキャストを要求する主な理由として、[凍結枠の区域と農村部と農村部の分野]を占めています。[Fru]また：
| Personal wireless devices that are capable of receiving 47 CFR
| part 15 frequencies, such as smart phones, tablets, or other
| similar commercially available devices, will be able to receive
| broadcast remote identification information directly without
| reliance on an Internet connection.
Internet-disconnected operation presents challenges, e.g., for Observers needing access to the [F3411-19] web-based Broadcast Authentication Verifier Service or needing to do external lookups.
インターネット切断操作は、例えば、[F3411-19] Webベースのブロードキャスト認証検証サービスまたは外部検索を行う必要がある観察者の課題を提示する。
As RID must often operate within these constraints, heavyweight cryptographic security protocols or even simple cryptographic handshakes are infeasible, yet trustworthiness of UAS RID information is essential. Under [F3411-19], _even the most basic datum, the UAS ID itself, can be merely an unsubstantiated claim_.
RIDがしばしばこれらの制約の中で動作しなければならない、ヘビー級の暗号化セキュリティプロトコル、あるいは単純な暗号化ハンドシェイクでさえも不可能でありながら、UAS RID情報の信頼性が不可欠です。[F3411-19]では、_evenでは、最も基本的な基準であるUAS ID自体は、単に非タンク付けされたクレームです。
Observer devices are ubiquitous; thus, they are popular targets for malware or other compromise, so they cannot be generally trusted (although the user of each device is compelled to trust that device, to some extent). A "fair witness" functionality (inspired by [Stranger]) is desirable.
オブザーバーデバイスはユビキタスです。したがって、それらはマルウェアまたは他の妥協のための人気のあるターゲットであるので、それらは一般的に信頼されることはできません（ただし、各デバイスのユーザーはそのデバイスをある程度信頼するために強制されています）。「公正な証人」機能（[STRANGER]に触発された）が望ましいです。
Despite work by regulators and SDOs, there are substantial gaps in UAS standards generally and UAS RID specifically. [Roadmap] catalogs UAS-related standards, ongoing standardization activities, and gaps (as of 2020); Section 7.8 catalogs those related specifically to UAS RID. DRIP will address the most fundamental of these gaps, as foreshadowed above.
規制当局やSDOの仕事にもかかわらず、一般的にUAS規格にはかなりのギャップがあり、特にUAS RIDがあります。[RoadMap] UAS関連の基準、継続的な標準化活動、およびギャップをカタログ化します（2020年現在）。セクション7.8は、特にUAS RIDに関連するものをカタログ化します。上記のように、DRIPはこれらのギャップの最も基本的なものに対処します。
DRIP's initial objective is to make RID immediately actionable, especially in emergencies, in severely constrained UAS environments (both Internet and local-only connected scenarios), balancing legitimate (e.g., public safety) authorities' Need To Know trustworthy information with UAS operators' privacy. The phrase "immediately actionable" means information of sufficient precision, accuracy, and timeliness for an Observer to use it as the basis for immediate decisive action (e.g., triggering a defensive counter-UAS system, attempting to initiate communications with the UAS operator, accepting the presence of the UAS in the airspace where/when observed as not requiring further action, etc.) with potentially severe consequences of any action or inaction chosen based on that information. For further explanation of the concept of immediate actionability, see [ENISACSIRT].
DRIPの最初の目的は、特に緊急事態で、深刻な制約のあるUAS環境（インターネットとローカルオンリー接続シナリオの両方）で、すぐに実用的にすること、正当な（例えば、公安）当局のバランスをとると、UASオペレータのプライバシーとの信頼できる情報を知る必要があります。。「すぐに実用的」という句は、即時決定的な行動の基礎としてそれを使用するのに十分な精度、正確さ、および適時性の情報を意味する（例えば、障害のあるカウンタUASシステムを誘発し、UASオペレータとの通信を開始しようとし、受け入れているその情報に基づいて選択された任意の行動や不作為の潜在的に厳しい影響を伴う、空域内のUASの存在、またはその情報に基づいて選択された任意の行動や不活性の影響を受けている。即時慣行性の概念の詳細については、[ENISACSIRT]を参照してください。
Note that UAS RID must achieve nearly universal adoption, but DRIP can add value even if only selectively deployed. Authorities with jurisdiction over more sensitive airspace volumes may set a RID requirement, for flight in such volumes, that is higher than generally mandated. Those with a greater need for high-confidence IFF can equip with DRIP, enabling strong authentication of their own aircraft and allied operators without regard for the weaker (if any) authentication of others.
UAS RIDはほぼ普遍的な採用を達成しなければならないが、DRIPは選択的に展開されていても値を追加することができます。より敏感なエアスペースボリュームを超える管轄権を持つ当局は、そのようなボリュームのフライトのためのリッス要件を設定するかもしれません、それは一般的に義務付けられています。高信頼IFFがより高い必要性を持つ人々はDRIPを装備することができ、他の人のより弱い（もしあれば）認証を考慮せずに、独自の航空機と同盟者のオペレータの認証を可能にします。
DRIP (originally "Trustworthy Multipurpose Remote Identification (TM-RID)") could be applied to verifiably identify other types of registered things reported to be in specified physical locations. Providing timely trustworthy identification data is also prerequisite to identity-oriented networking. Despite the value of DRIP to these and other potential applications, UAS RID is the urgent motivation and clear initial focus of DRIP. Existing Internet resources (protocol standards, services, infrastructure, and business models) should be leveraged.
DRIP（もともと「信頼できる多目的リモート識別（TM-RID）」）は、指定された物理的な場所にあることが報告されている他の種類の登録事項を検証可能に識別するために適用できます。タイムリーな信頼できる識別データを提供することは、アイデンティティ指向ネットワーキングにも前提条件です。これらおよび他の潜在的な用途への滴下の価値にもかかわらず、UAS RIDはDRIPの緊急のやる気と明確な初期焦点です。既存のインターネットリソース（プロトコル標準、サービス、インフラストラクチャ、およびビジネスモデル）を活用する必要があります。
This document describes the problem space for UAS RID conforming to proposed regulations and external technical standards, defines common terminology, specifies numbered requirements for DRIP, identifies some important considerations (security, privacy, and transparency), and discusses limitations.
この文書では、提案された規制と外部技術規格に準拠したUAS RIDの問題スペースについて説明し、一般的な用語を定義し、DRIPの番号付き要件を指定し、いくつかの重要な考慮事項（セキュリティ、プライバシー、および透明度）を識別し、制限事項を説明します。
A natural Internet-based approach to meet these requirements is described in a companion architecture document [DRIP-ARCH] and elaborated in other DRIP documents.
これらの要件を満たすための自然なインターネットベースのアプローチは、コンパニオンアーキテクチャ文書[DRIP-ARCH]に記載されており、他のDRIP文書で詳しく説明されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This section defines a non-comprehensive set of terms expected to be used in DRIP documents. This list is meant to be the DRIP terminology reference; as such, some of the terms listed below are not used in this document.
このセクションでは、DRIP文書で使用される予定の非包括的な用語セットを定義します。このリストはDRIP用語リファレンスであることを意味しています。そのため、この文書では、以下にリストされている用語の一部は使用されていません。
To encourage comprehension necessary for adoption of DRIP by the intended user community, the UAS community's norms are respected herein, and definitions are quoted in cases where they have been found in that community's documents. Most of the terms listed below are from that community (even if specific source documents are not cited); any terms that are DRIP-specific or defined by this document are marked "(DRIP)".
意図されたユーザーコミュニティによるDRIPの採用に必要な理解を促進するために、UASコミュニティの規範は本明細書に推奨されており、そのコミュニティの文書にそれらが見つかった場合には定義が引用されています。以下にリストされている用語のほとんどはそのコミュニティからのものです（たとえ特定のソース文書が引用されていなくても）。このドキュメントによってDRIP固有または定義されている用語は、「（DRIP）」とマークされています。
Note that, in the UAS community, the plural form of an acronym, generally, is the same as the singular form, e.g., Unmanned Aircraft System (singular) and Unmanned Aircraft Systems (plural) are both represented as UAS.
なお、UASコミュニティでは、複数形の頭字語が一般的に、一般的には単数形、例えば無人航空機システム（単数）および無人航空機システム（複数）が両方ともUASとして表されていることに留意されたい。
[RFC4949] provides a glossary of Internet security terms that should be used where applicable.
[RFC4949]該当する場合に使用する必要があるインターネットセキュリティ用語の用語集を提供します。
4-D Four-dimensional. Latitude, Longitude, Altitude, Time. Used especially to delineate an airspace volume in which an operation is being or will be conducted.
4次元4次元緯度、経度、高度、時間。特に操作が行われている、または実施される空域の体積を描写するために使用されます。
AAA Attestation, Authentication, Authorization, Access Control, Accounting, Attribution, Audit, or any subset thereof (uses differ by application, author, and context). (DRIP)
AAA認証、認証、承認、アクセス制御、会計、帰属、監査、またはそのサブセット（アプリケーション、作成者、およびコンテキストによって異なります）。（滴下）
ABDAA AirBorne DAA. Accomplished using systems onboard the aircraft involved. Supports "self-separation" (remaining "well clear" of other aircraft) and collision avoidance.
Abdaa Airbone Daa。航空機を搭載したシステムを使用して達成されました。「自己分離」（他の航空機の残りの「明確な」）と衝突回避をサポートします。
ADS-B Automatic Dependent Surveillance - Broadcast. "ADS-B Out" equipment obtains aircraft position from other on-board systems (typically GNSS) and periodically broadcasts it to "ADS-B In" equipped entities, including other aircraft, ground stations, and satellite-based monitoring systems.
ADS-B自動依存監視 - 放送。「ADS-B OUT」機器は、他のオンボードシステム（通常はGNSS）から航空機の位置を取得し、その他の航空機、地上局、および衛星ベースの監視システムを含む「ADS-Bの「ADS-B」に定期的に放送します。
AGL Above Ground Level. Relative altitude, above the variously defined local ground level, typically of a UA, measured in feet or meters. Should be explicitly specified as either barometric (pressure) or geodetic (GNSS) altitude.
地上レベルの上のAGL。典型的にはUAの様々に定義された局所的な地上レベルより上の相対的な高度。フィートまたはメートルで測定される。気圧（圧力）または測地力（GNSS）高度として明示的に指定する必要があります。
ATC Air Traffic Control. Explicit flight direction to pilots from ground controllers. Contrast with ATM.
ATCエアトラフィック制御地上コントローラからのパイロットへの明示的な飛行方向。ATMとの対比。
ATM Air Traffic Management. A broader functional and geographic scope and/or a higher layer of abstraction than ATC. [ICAOATM] defines ATM as the following: "The dynamic, integrated management of air traffic and airspace including air traffic services, airspace management and air traffic flow management -- safely, economically and efficiently -- through the provision of facilities and seamless services in collaboration with all parties and involving airborne and ground-based functions".
ATMエアトラフィック管理。ATCよりも広い機能的および地理的な範囲および/またはより高い抽象化層。[icaoorm] ATMを次のように定義します。「航空交通サービス、空域管理、航空交通量管理を含む航空交通と空域管理の動的、統合管理 - 安全に、経済的かつ効率的に - 施設やシームレスなサービスの提供すべての当事者との協力、そして航空機搭載および地上機能を含む」。
Authentication Message [F3411-19] Message Type 2. Provides framing for authentication data only; the only message that can be extended in length by segmenting it across more than one page.
認証メッセージ[F3411-19]メッセージタイプ2.認証データのフレーミングのみを提供します。複数のページにまたがってセグメント化することによって長さが長くなることができる唯一のメッセージ。
Basic ID Message [F3411-19] Message Type 0. Provides UA Type, ID Type (and Specific Session ID subtype if applicable), and UAS ID only.
基本IDメッセージ[F3411-19]メッセージタイプ0. UAタイプ、IDタイプ（該当する場合は特定のセッションIDサブタイプ）、およびUAS IDのみを提供します。
Broadcast Authentication Verifier Service System component designed to handle any authentication of Broadcast RID by offloading signature verification to a web service [F3411-19].
ブロードキャスト認証検証者サービスシステムコンポーネントは、Webサービスへの署名検証をオフロードすることで、RID RIDSの認証を処理するように設計されています[F3411-19]。
BVLOS Beyond Visual Line Of Sight. See VLOS.
視覚的な視線を超えたbvlos。VLOSを参照してください。
byte Used here in its now-customary sense as a synonym for "octet", as "byte" is used exclusively in definitions of data structures specified in [F3411-19].
ここで使用されているバイトは、「オクテット」の同義語として、「バイト」が[F3411-19]で指定されたデータ構造の定義で使用されています。
CAA Civil Aviation Authority of a regulatory jurisdiction. Often so named, but other examples include the United States Federal Aviation Administration (FAA) and the Japan Civil Aviation Bureau.
規制管轄権のCAA民間航空局。多くの場合、そのように命名されていますが、他の例には、米国連邦航空局（FAA）と日本民間航空局が含まれます。
CSWaP Cost, Size, Weight, and Power
CSWAPコスト、サイズ、重量、および電力
C2 Command and Control. Previously mostly used in military contexts. Properly refers to a function that is exercisable over arbitrary communications, but in the small UAS context, often refers to the communications (typically RF data link) over which the GCS controls the UA.
C2コマンドと制御以前は軍事的文脈で主に使用されていました。適切に任意の通信を介して行使可能な関数を指すが、小さなUASコンテキストでは、GCSがUAを制御する通信（典型的にはRFデータリンク）を指すことが多い。
DAA Detect And Avoid, formerly "Sense And Avoid (SAA)". A means of keeping aircraft "well clear" of each other and obstacles for safety. [ICAOUAS] defines DAA as the following: "The capability to see, sense or detect conflicting traffic or other hazards and take the appropriate action to comply with the applicable rules of flight".
DAAは、以前は「センスを感じさせ（SAA）」を回避しないでください。航空機を「よく明確」に保つ手段と安全のための障害物。[ICAOUAS] DAAを次のように定義します。「矛盾する能力、あるいはその他の危険を見、該当するフライトルールに準拠するための適切な行動をとる機能」。
DRI (not to be confused with DRIP) Direct Remote Identification. EU regulatory requirement for "a system that ensures the local broadcast of information about a UA in operation, including the marking of the UA, so that this information can be obtained without physical access to the UA" [Delegated]. This requirement can presumably be satisfied with appropriately configured [F3411-19] Broadcast RID.
DRI（DRIPと混同しない）直接リモート識別。「UAのマーキングを含むUAに関するUAに関する情報のローカルブロードキャストを確実にするシステム」のためのEU規制要件「委任」。この要件は、おそらく適切に構成された[F3411-19]ブロードキャストRIDを満たすことができる。
DSS Discovery and Synchronization Service. The UTM system overlay network backbone. Most importantly, it enables one USS to learn which other USS have UAS operating in a given 4-D airspace volume, for strategic deconfliction of planned operations and Network RID surveillance of active operations. See [F3411-19].
DSSディスカバリーと同期サービス。UTMシステムはネットワークバックボーンをオーバーレイします。最も重要なことは、1人の米国が他の米国がどのような4D空域で運営されているUASが、計画された運営の戦略的微分および能動的な業務のネットワークRID監視のために習得することを学ぶことができます。[F3411-19]を参照してください。
EUROCAE European Organisation for Civil Aviation Equipment. Aviation SDO, originally European, now with broader membership. Cooperates extensively with RTCA.
民間航空機器のためのEurocaeヨーロッパの組織航空SDOは、もともとヨーロッパのヨーロッパ人が幅広いメンバーシップです。RTCAで広く協力します。
GBDAA Ground-Based DAA. Accomplished with the aid of ground-based functions.
GBDAA地上ベースのDA地上関数の助けを借りて達成されました。
GCS Ground Control Station. The part of the UAS that the Remote Pilot uses to exercise C2 over the UA, whether by remotely exercising UA flight controls to fly the UA, by setting GNSS waypoints, or by otherwise directing its flight.
GCS地面制御局リモートパイロットがUAを介してC2を介して演算するUASの一部は、GNSSウェイポイントを設定することによって、またはそれ以外の場合はフライトを指示することによって、UAのフライトコントロールを行使することによって、UAの中でC2を行使することを使用する。
GNSS Global Navigation Satellite System. Satellite-based timing and/or positioning with global coverage, often used to support navigation.
GNSSグローバルナビゲーション衛星システム。衛星ベースのタイミングおよび/またはグローバルカバレッジによる位置決めは、ナビゲーションをサポートするためによく使用されます。
GPS Global Positioning System. A specific GNSS, but in the UAS context, the term is typically misused in place of the more generic term "GNSS".
GPSグローバル位置決めシステム特定のGNSは、しかしUASコンテキストでは、この用語は通常、より一般的な用語「GNSS」の代わりに誤用されます。
GRAIN Global Resilient Aviation Interoperable Network. ICAO-managed IPv6 overlay internetwork based on IATF that is dedicated to aviation (but not just aircraft). As currently (2021) designed, it accommodates the proposed DRIP identifier.
グレイングローバル弾性航空相互運用可能ネットワーク。ICAO管理IPv6は、航空専用のIATFに基づいてインターネットワークをオーバーレイインターネットワーク（航空機だけではありません）。現在（2021）設計されたように、提案されたDRIP識別子を収容します。
IATF International Aviation Trust Framework. ICAO effort to develop a resilient and secure by design framework for networking in support of all aspects of aviation.
IATF国際航空信託フレームワーク。航空のあらゆる側面を支えるためのネットワーキングのためのデザインフレームワークによって弾力性のない努力を開発するためのicaoの努力。
ICAO International Civil Aviation Organization. A specialized agency of the United Nations that develops and harmonizes international standards relating to aviation.
ICAO国際民間航空機関。航空に関する国際規格を開発し調和させる国連の専門機関。
IFF Identification Friend or Foe. Originally, and in its narrow sense still, a self-identification broadcast in response to interrogation via radar to reduce friendly fire incidents, which led to military and commercial transponder systems such as ADS-B. In the broader sense used here, any process intended to distinguish friendly from potentially hostile UA or other entities encountered.
IFF識別友人や敵。もともと、そしてその狭い意味では、依然として、ADS-Bなどの軍事的および商業的なトランスポンダーシステムにつながった、レーダーを介した尋問に応じて自己識別放送を放送します。ここで使用されているより広い意味では、潜在的に敵対的なUAやその他のエンティティを識別することを目的としたプロセスはすべてです。
LAANC Low Altitude Authorization and Notification Capability. Supports ATC authorization requirements for UAS operations: Remote Pilots can apply to receive a near real-time authorization for operations under 400 feet in controlled airspace near airports. FAA-authorized partial stopgap in the US until UTM comes.
Laanc低高度の承認と通知機能。UASの操作に関するATC認証要件をサポート：遠隔パイロットは、空港の近くの管理された空域で400フィート未満の業務のためのほぼリアルタイム許可を受け取ることができます。UTMが来るまで米国でFAA認定の部分的なストップギャップ。
Location/Vector Message [F3411-19] Message Type 1. Provides UA location, altitude, heading, speed, and status.
場所/ベクトルメッセージ[F3411-19]メッセージタイプ1. UAの場所、高度、見出し、スピード、およびステータスを提供します。
LOS Line Of Sight. An adjectival phrase describing any information transfer that travels in a nearly straight line (e.g., electromagnetic energy, whether in the visual light, RF, or other frequency range) and is subject to blockage. A term to be avoided due to ambiguity, in this context, between RF LOS and VLOS.
LOS視線。近い情報転送（例えば、視覚光、RF、または他の周波数範囲であろう）で、閉塞の対象となる任意の情報転送を説明する。この文脈では、RF LOSとVLOの間のあいまいさのために避けられる用語。
Message Pack [F3411-19] Message Type 15. The framed concatenation, in message type index order, of at most one message of each type of any subset of the other types. Required to be sent in Wi-Fi NAN and in Bluetooth 5 Extended Advertisements, if those media are used; cannot be sent in Bluetooth 4.
メッセージ・パック[F3411-19]メッセージ・タイプ15.他のタイプのサブセットの各タイプの最大1つのメッセージのメッセージタイプ索引順序。これらのメディアが使用されている場合は、Wi-Fi NanおよびBluetooth 5拡張広告で送信する必要があります。Bluetooth 4で送信できません。
MSL Mean Sea Level. Shorthand for relative altitude, above the variously defined mean sea level, typically of a UA (but in [FRUR], also for a GCS), measured in feet or meters. Should be explicitly specified as either barometric (pressure) or geodetic (e.g., as indicated by GNSS, referenced to the WGS84 ellipsoid).
MSLは海面を意味します。様々に定義された平均海面、典型的にはUAの上に、典型的には（ただし、GCSの場合はgCSの場合）、額面またはメートルで測定された範囲での短距離。気圧（圧力）または測地薬（例えば、WGS84楕円体を参照して参照）のいずれかで明示的に指定する必要があります。
Net-RID DP Network RID Display Provider. [F3411-19] logical entity that aggregates data from Net-RID SPs as needed in response to user queries regarding UAS operating within specified airspace volumes to enable display by a user application on a user device. Potentially could provide not only information sent via UAS RID but also information retrieved from UAS RID registries or information beyond UAS RID. Under superseded [NPRM], not recognized as a distinct entity, but as a service provided by USS, including public safety USS that may exist primarily for this purpose rather than to manage any subscribed UAS.
Net-Rid DPネットワークRIDディスプレイプロバイダ。[F3411-19]指定されたAirSpaceボリューム内で動作するUASに関するユーザークエリに応答して、ユーザデバイスで表示を有効にするために必要に応じてNet-RID SPのデータを集約する論理エンティティ。潜在的に、UAS RIDを介して送信された情報だけでなく、UAS RIDレジストリから検索された情報やUAS RIDを超えた情報も提供できます。置き換えられた[NPRM]の下では、明確なエンティティとして認識されていませんが、主にこの目的のために存在する可能性のある公安費を含むUSSによって提供されるサービスとして、購読されているUASを管理するのではなく存在するサービスとして提供されています。
Net-RID SP Network RID Service Provider. [F3411-19] logical entity that collects RID messages from UAS and responds to Net-RID DP queries for information on UAS of which it is aware. Under superseded [NPRM], the USS to which the UAS is subscribed (i.e., the "Remote ID USS").
NET-RID SPネットワークRIDサービスプロバイダ。[F3411-19] UASからのRIDメッセージを収集し、それが注意しているUASに関する情報のためにNet-Rud DPクエリに応答する論理エンティティ。置き換えられた[NPRM]の下で、UASが購読されているUS（すなわち、「リモートID US」）。
Network Identification Service EU regulatory requirement in [Opinion1], corresponding to the Electronic Identification for which Minimum Operational Performance Standards are specified in [WG105], which presumably can be satisfied with appropriately configured [F3411-19] Network RID.
ネットワーク識別サービスEUの規制要件[WG105]で最低運用性能基準が指定されている電子識別に対応して、おそらく適切に構成された[F3411-19]ネットワークRIDで満たすことができる。
Observer An entity (typically, but not necessarily, an individual human) who has directly or indirectly observed a UA and wishes to know something about it, starting with its ID. An Observer typically is on the ground and local (within VLOS of an observed UA), but could be remote (observing via Network RID or other surveillance), operating another UA, aboard another aircraft, etc. (DRIP)
UAを直接的または間接的に観察し、そのIDについての何かを知りたいエンティティ（通常は、必ずしも、必ずしも個々の人間ではありません）。オブザーバーは通常、地上および局所（観測されたUAのVLO内）にありますが、遠隔地（ネットワークRIDまたは他の監視経由で観察する）、別のUAを操作し、別の航空機などに乗って（DRIP）
Operation A flight, or series of flights of the same mission, by the same UAS, separated by, at most, brief ground intervals. (Inferred from UTM usage; no formal definition found.)
操作と同じ任務の一連のフライト、または同じ任務の一連のフライト、ほとんどの短いグラウンド間隔で区切られています。（UTM使用状況から推測されていません。正式な定義は見つかりませんでした。）
Operator "A person, organization or enterprise engaged in or offering to engage in an aircraft operation" [ICAOUAS].
オペレーター「航空機の操作に従事している人、組織または企業」[ICAOUAS]。
Operator ID Message [F3411-19] Message Type 5. Provides CAA-issued Operator ID only. Operator ID is distinct from UAS ID.
オペレータIDメッセージ[F3411-19]メッセージタイプ5. CAA発行演算子IDのみを提供します。オペレータIDはUAS IDとは異なります。
page Payload of a frame, containing a chunk of a message that has been segmented, that allows transport of a message longer than can be encapsulated in a single frame. See [F3411-19].
セグメント化されたメッセージのチャンクを含むフレームのペイロード、それは1つのフレームでカプセル化することができるメッセージのトランスポートを可能にする。[F3411-19]を参照してください。
PIC Pilot In Command. "The pilot designated by the operator, or in the case of general aviation, the owner, as being in command and charged with the safe conduct of a flight" [ICAOUAS].
コマンドのPIC Pilot。「オペレータによって指定されたパイロット、または一般的な航空、所有者、所有者の場合は、命令を維持し、飛行の安全な行動で課金されている」[icaouas]。
PII Personally Identifiable Information. In the UAS RID context, typically of the UAS Operator, PIC, or Remote Pilot, but possibly of an Observer or other party. This specific term is used primarily in the US; other terms with essentially the same meaning are more common in other jurisdictions (e.g., "personal data" in the EU). Used herein generically to refer to personal information that the person might wish to keep private or may have a statutorily recognized right to keep private (e.g., under the EU [GDPR]), potentially imposing (legally or ethically) a confidentiality requirement on protocols/systems.
PII個人識別可能な情報。UAS RIDコンテキストでは、通常はUASオペレータ、PIC、またはリモートパイロットのものですが、おそらくオブザーバーまたは他のパーティーの。この特定の用語は主に米国で使用されています。本質的に同じ意味を持つ他の用語は、他の管轄区域（例えば、EU内の「個人データ」）でより一般的です。本明細書で使用されるのは、個人が個人的に保持したいと思うかもしれない個人情報を指すものであるか、または潜在的に（例えば、EU [GDPR]の下で）潜在的に（合法的または倫理的に）潜在的に課すことを潜在的に課すことを潜在的に課すことができます。システム
Remote Pilot A pilot using a GCS to exercise proximate control of a UA. Either the PIC or under the supervision of the PIC. "The person who manipulates the flight controls of a remotely-piloted aircraft during flight time" [ICAOUAS].
リモートパイロットGCSを使用してPILOTを使用してUAの近接制御を行使します。写真の写真または写真の監督の下にあります。「飛行中に遠隔操作航空機の飛行制御を操作する人」[Icaouas]。
RF Radio Frequency. Can be used as an adjective (e.g., "RF link") or as a noun.
RF無線周波数形容詞（例えば、 "RFリンク"）または名詞として使用できます。
RF LOS RF Line Of Sight. Typically used in describing a direct radio link between a GCS and the UA under its control, potentially subject to blockage by foliage, structures, terrain, or other vehicles, but less so than VLOS.
RF LOSの視力線。典型的には、その制御下でのGCSとUAとの間の直接無線リンクを説明するのに使用され、潜在的に葉、構造、地形、または他の車両による閉塞が潜在的に、しかしVLOSよりも少ない。
RTCA Radio Technical Commission for Aeronautics. US aviation SDO. Cooperates extensively with EUROCAE.
航空宇宙研究所のRTCAラジオ技術委員会。米国航空SDO。Eurocaeと広く協力します。
Safety "The state in which risks associated with aviation activities, related to, or in direct support of the operation of aircraft, are reduced and controlled to an acceptable level" (from Annex 19 of the Chicago Convention, quoted in [ICAODEFS]).
安全性「航空機の運営に関する航空活動に関連するリスクが、航空機の運営に関する、または直接支援する州は、（[ICAODEFS]で引用されているシカゴ条約の附属書19から）を許容レベルに減少し、制御されています。
Security "Safeguarding civil aviation against acts of unlawful interference" (from Annex 17 of the Chicago Convention, quoted in [ICAODEFS]).
セキュリティ「違法干渉の行為に対する民間航空を保護する」（Chicago規約の附属書17から、icaodefs]で引用されています）。
Self-ID Message [F3411-19] Message Type 3. Provides a 1-byte descriptor and 23-byte ASCII free text field, only. Expected to be used to provide context on the operation, e.g., mission intent.
セルフIDメッセージ[F3411-19]メッセージタイプ3. 1バイトの記述子と23バイトのASCIIフリーテキストフィールドのみを提供します。操作上のコンテキストを提供するために使用されること、例えばミッションの意図。
SDO Standards Development Organization, such as ASTM, IETF, etc.
ASTM、IETFなどのSDO規格開発編成
SDSP Supplemental Data Service Provider. An entity that participates in the UTM system but provides services (e.g., weather data) beyond those specified as basic UTM system functions. See [FAACONOPS].
SDSP補足データサービスプロバイダ。UTMシステムに参加しているが、基本的なUTMシステム機能として指定されたものを超えてサービス（例えば、気象データ）を提供する実体。[Faaconops]を参照してください。
System Message [F3411-19] Message Type 4. Provides general UAS information, including Remote Pilot location, multiple UA group operational area, etc.
システムメッセージ[F3411-19]メッセージタイプ4.リモートパイロットの場所、複数のUAグループの操作エリアなどを含む一般的なUAS情報を提供します。
U-space EU concept and emerging framework for integration of UAS into all types of airspace, including but not limited to volumes that are in high-density urban areas and/or shared with manned aircraft [InitialView].
高密度の都市部にある、および/または有人航空機と共有されているボリュームを含むがこれらに限定されない、すべてのタイプの空域へのUASの統合のためのU空間EUの概念および新興枠組み。
UA Unmanned Aircraft. In popular parlance, "drone". "An aircraft which is intended to operate with no pilot on board" [ICAOUAS].
UA無人航空機。人気のあるarlanceでは、「ドローン」。「パイロットのないパイロットのない操作を目的とした航空機」[Icaouas]。
UAS Unmanned Aircraft System. Composed of UA, all required on-board subsystems, payload, control station, other required off-board subsystems, any required launch and recovery equipment, all required crew members, and C2 links between UA and control station [F3411-19].
UAS無人航空機システム。UAで構成されているすべてのオンボードサブシステム、ペイロード、制御ステーション、その他のオフボードサブシステム、必要な起動および回復機器、すべての必要な乗務部材、およびUAとControl Stationの間のC2リンク[F3411-19]。
UAS ID UAS identifier. Although called "UAS ID", it is actually unique to the UA, neither to the operator (as some UAS registration numbers have been and for exclusively recreational purposes are continuing to be assigned), nor to the combination of GCS and UA that comprise the UAS. _Maximum length of 20 bytes_ [F3411-19]. If the ID Type is 4, the proposed Specific Session ID, then the 20 bytes includes the subtype index, leaving only 19 bytes for the actual identifier.
UAS ID UAS識別子。「UAS ID」と呼ばれていますが、それは実際にはUAに固有のものですが、（一部のUAS登録番号が専用で、専用のレクリエーションの目的が継続されているため）、またはそれを構成するGCSとUAの組み合わせにもいません。UAS。_最大長20バイト_ [F3411-19]。IDタイプが4の場合、提案された特定のセッションIDは、20バイトにサブタイプインデックスが含まれ、実際の識別子の場合は19バイトしか残します。
ID Type UAS identifier type index. 4 bits. See Section 3, Paragraph 6 for current standard values 0-3 and currently proposed additional value 4. See also [F3411-19].
IDタイプUAS識別子型インデックス。4ビット現在の標準値0~3については3、4項を参照して、現在提案されている追加値4.「F3411-19」を参照してください。
UAS RID UAS Remote Identification and tracking. System to enable arbitrary Observers to identify UA during flight.
UASはUASリモートの識別と追跡を取り除きます。飛行中に任意のオブザーバーを識別できるようにするシステム。
USS UAS Service Supplier. "A USS is an entity that assists UAS Operators with meeting UTM operational requirements that enable safe and efficient use of airspace" [FAACONOPS]. In addition, "USSs provide services to support the UAS community, to connect Operators and other entities to enable information flow across the USS Network, and to promote shared situational awareness among UTM participants" [FAACONOPS].
USS UASサービスサプライヤー。「USSは、AirSpaceの安全で効率的な使用を可能にするUTMの運用要件を満たすUASオペレータを支援するエンティティです。さらに、USSSは、USSネットワーク全体で情報の流れを可能にするためのオペレータやその他のエンティティを接続し、UTM参加者の間での共有状況認識を促進するためのUSSSコミュニティをサポートするサービスを提供し、[Faaconops]。
UTM UAS Traffic Management. "A specific aspect of air traffic management which manages UAS operations safely, economically and efficiently through the provision of facilities and a seamless set of services in collaboration with all parties and involving airborne and ground-based functions" [ICAOUTM]. In the US, according to the FAA, a "traffic management" ecosystem for "uncontrolled" UAS operations at low altitudes, separate from, but complementary to, the FAA's ATC system for "controlled" operations of manned aircraft.
UTM UASトラフィック管理「すべての当事者と共同で、航空機搭載および地上機能を伴う施設の提供とシームレスなサービスのシームレスなサービスを提供し、航空輸入および地上機能を巻き込むサービスのシームレスなサービスを経済的かつ効率的に管理する航空交通管理の特定の側面。FAAによると、FAAによると、「管理されていない」UAS操作のための「無制限の」UAS操作のための、しかし、有人航空機の「制御された」演算のためのFAAのATCシステム。
V2V Vehicle-to-Vehicle. Originally communications between automobiles, now extended to apply to communications between vehicles generally. Often, together with Vehicle-to-Infrastructure (V2I) and similar functions, generalized to V2X.
V2V車間車両もともと自動車間の通信は、現在車両間の通信に適用されるように拡張されました。多くの場合、ビークルからインフラストラクチャ（V2i）と同様の機能と一緒に、V2Xに一般化されています。
VLOS Visual Line Of Sight. Typically used in describing operation of a UA by a "remote" pilot who can clearly and directly (without video cameras or any aids other than glasses or, under some rules, binoculars) see the UA and its immediate flight environment. Potentially subject to blockage by foliage, structures, terrain, or other vehicles, more so than RF LOS.
VLOS視覚的な視線。明確かつ直接（ガラス以外のあらゆるエイズまたはいくつかの規則の下で、あるいは双眼鏡で）、UAとその即時飛行環境を参照してください。潜在的に、葉、構造、地形、または他の車両、RF LOSよりも多くの車両による閉塞を受けます。
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.
世界中のCAASはUAS RIDを義務付けています。欧州連合の航空安全庁（EASA）は、委任状と[実施]規制を発表しました。米国FAAは「最終的な」規則[Fru]を発表し、UAS RIDが[Faaconops]（特に2.6節）でUASトラフィック管理（UTM）で再生する重要な役割を説明しました。書き込み時には、CAASは、手法を指定しないが、むしろ業界の合意技術基準を許容可能なコンプライアンスの手段として、むしろCITE業界のコンセンサスを提供しています。
The most widely cited such industry consensus technical standard for UAS RID is [F3411-19], which defines two means of UAS RID:
UAS RIDのための最も広く引用されているそのような業界コンセンサス技術規格は、2つのUAS RIDの手段を定義する[F3411-19]です。
* 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.
* ネットワークRIDは、インターネットを介してインターネットを介してグローバルに利用可能にするためのUASのための情報のセットを定義します。
* 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.
* ブロードキャストRIDは、ローカルオブザーバによってリアルタイムで受信されるBluetoothまたはWi-Fiに対してローカルに直接送信するためのUAのメッセージのセットを定義します。
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.
両方の手段を使用するUASは、各[F3411-19]を介して同じUAS RIDアプリケーション層情報を送信する必要があります。ネットワークRIDがデータ辞書を定義するため、プレゼンテーションは異なる場合がありますが、ブロードキャストRIDはメッセージフォーマット（同じデータディクショナリからの項目を搬送する）を定義します。ネットワークRIDがUAS更新と非同期に非同期クエリに対応できるように、それが送信される間隔（またはレート）は異なる場合があります（これは一般に場所、変更などの情報のみを送信する必要があります）。それらが送信されたときのメッセージ。
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).
ネットワークRIDは、UASから各オブザーバへの複数のセグメント内のインターネット接続に依存します。ブロードキャストRIDは、データベースルックアップの主な固有キーとして、レジストリ情報を取得するための、インターネット（または他のワイドエリアネットワーク）接続を必要とする必要があります。放送RIDはUASのIP接続を想定していません。メッセージは、リンク層フレーム（Bluetooth 4、Bluetooth 5、Wi-Fi Nan、IEEE 802.11ビーコン、またはおそらく将来の他の人の他の人）で直接UA _のUA _にカプセル化されています。
[F3411-19] specifies three ID Type values, and its proposed revision (at the time of writing) adds a fourth:
[F3411-19] 3つのIDタイプ値を指定し、提案されたリビジョン（書き込み時）を4番目に追加します。
1 A static, manufacturer-assigned, hardware serial number as defined in "Small Unmanned Aerial Systems Serial Numbers" [CTA2063A].
1「小さな無人航空システムシリアル番号」[CTA2063A]で定義されている静的、製造業者が割り当てられたハードウェアシリアル番号。
2 A CAA-assigned (generally static) ID, like the registration number of a manned aircraft.
2有人航空機の登録番号のように、CAAが割り当てられた（一般的に静的な）IDです。
3 A UTM-system-assigned Universally Unique Identifier (UUID) [RFC4122], which can but need not be dynamic.
3 UTMシステムが割り当てられた汎用一意の識別子（UUID）[RFC4122]。動的である必要はありません。
4 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.
4 ASTMの外部に定義されている8ビット範囲のサブタイプのいずれかの特定のセッションIDは、DRIPエンティティIDのためにサブタイプ1がASTMで予約されているICAOに登録されています。
Per [Delegated], 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.
[委任]、EUはIDタイプ1のみを許可する。[Frur]では、米国はIDタイプ1とIDタイプ3を許可しています。オペレータに追加のプライバシーを提供するように設計されたフライトベースでリモートID UASサービスサプライヤ（USS）によって割り当てられていますが、[Frur]からネットワークリッダーの省略を考えると、これが米国でどのように割り当てられるべきか決断される。
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.
まだ、IDタイプ2を使用するためのCAAの公開提案はありません。RIDはFAAや他の政府機関に制限されるべきであり、セッションIDが登録データベースのシリアル番号を介して間接的にのみ登録番号にリンクされることを意味します。特定の状況下で明らかにできるように、暗号的に盲目的に登録番号の可能性があることは、適用される規制または外部技術規格で言及されているとは思われません。
Per [Delegated], 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.
[委任]ごとに、EUは[F3411-19]オプションのオプションIDメッセージで実行できるオペレータ登録番号（UAS IDとは異なる追加の識別子）も必要です。
[FRUR] 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:
[Frur]はUA自体のどちらかで、「標準的な遠隔識別無人航空機」、またはアドオン「リモート識別放送モジュール」と指定されているUA自体のいずれかで、RID要件を満たすことができます。モジュールの要件は、標準のRID UAとは異なります。モジュール：
* must transmit its own serial number (neither the serial number of the UA to which it is attached, nor a Session ID),
* 独自のシリアル番号を送信する必要があります（それが接続されているUAのシリアル番号もセッションIDも）、
* must transmit takeoff location as a proxy for the location of the pilot/GCS,
* Pilot / GCSの場所のプロキシとして離陸場所を送信する必要があります。
* need not transmit UA emergency status, and
* UA緊急状態を送信する必要はありません
* is allowed to be used only for operations within VLOS of the Remote Pilot.
* リモートパイロットのVLOS内の操作にのみ使用できます。
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.
管轄区域は、特定の事業者および/または特定の条件下でリラックスまたは放棄することがあります。例えば、[Frur]は、「FAA認識識別領域（FRIAS）」という名前の「FAA認識識別領域（FRIAS）」という名前でVLOS演算を行うためのUASが装備されていないオペレータを使用する。ラジコンモデルの航空機フライングクラブやその他の適格な組織は、そのような事業領域の認識のためにFAAに適用できます。
Figure 3 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).
ネットワークRID情報の流れを示す図である。UAS（UA-GCS、UAインターネット、およびGCSインターネット）を含む3つの通常の無線リンクのうちの2つだけが、C2とネットワークRIDをサポートするために存在する必要があります。3つすべてが、特にBVLOOS操作では、同じまたは異なる時間に存在する可能性があります。後者の上にC2を演じるために、GCSとUAとの間の少なくとも1つの情報流路（直接または間接的）がなければならない。この経路が双方向である場合（安価な小型UASであっても）、UAはまた、その状態（例えばGNSSを用いて）GCSにその状態（および適切に装備されている場合）を送信する。前者のために、米国にのステータスと位置の更新を送信するために、UAS（UAまたはGCS）の少なくとも1つのサブシステムとインターネットとの間の経路がなければならない（Net-RIDS SPとしてのとおり）。
+-------------+ ******************
| UA | * Internet *
+--o-------o--+ * *
| | * *
| | * * +------------+
| '--------*--(+)-----------*-----o |
| * | * | |
| .--------*--(+)-----------*-----o Net-RID SP |
| | * * | |
| | * .------*-----o |
| | * | * +------------+
| | * | *
| | * | * +------------+
| | * '------*-----o |
| | * * | Net-RID DP |
| | * .------*-----o |
| | * | * +------------+
| | * | *
| | * | * +------------+
+--o-------o--+ * '------*-----o Observer's |
| GCS | * * | Device |
+-------------+ ****************** +------------+
Figure 3: Network RID Information Flow
図3：ネットワークRID情報の流れ
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).
直接UAインターネットワイヤレスリンクは、特に大きなUAS上でより一般的になると予想されますが、書き込み時にはまれです。代わりに、RIDデータフローは通常、UAに由来し、GCSを通過するか、GCSに発生します。ネットワークRIDデータは、インターネットを通じて3回のトリップを行います（それらのいずれかがない限り）、IPの使用（および他の中間層プロトコル、例えばTLS / TCPまたはDTLS /）の使用を意味します。UDP）旅行に。UA-GCSリンクでは必ずしも使用またはサポートされているわけではありません（通常は直接リンクが存在するのではある場合は、BVLOOS操作では頻繁にはしません）。
Network RID is publish-subscribe-query. In the UTM context:
Network RIDは公開購読クエリです。UTMのコンテキストで：
1. 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).
1. UASオペレータは、その操作のためにUAS（UAS＃1を呼び出す）に役立つであろう（Minoned Aviationのフライトプランに対応するUTMの現在の期間）をプッシュします（USS＃1を呼び出します）。主に、その操作の4-D空間ボリュームに潜入している潜在的に衝突することを可能にする（ボリューム＃1を呼び出す）。
2. 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.
2. 操作が承認され始めて開始されると仮定すると、UAS＃1は定期的に場所/ステータスの更新をUSS＃1にプッシュします。これは、Inter AliaとのとりわけネットワークRIDサービスプロバイダ（Net-Rids SP）として機能します。
3. 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.
3. 他のUSSのユーザー（他のUAS演算子またはオブザーバーであるか）のユーザーが、4Dの空域ボリュームに関心を伸ばしたとき（たとえば、オペレーショナルの意図を提出したい場合、またはUAを監視しているため）、それらは自分でクエリを照会します。彼らが興味を持っている体積の米国。
4. 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.
4. UTMディスカバリーと同期サービス（DSS）、UTMシステム内の他のすべてのUSS（それらのボリュームと交差する任意のボリュームを含む）を学びました。したがって、クエリボリュームがボリューム＃1を交差させる米国（米国の＃2を通じて、USS＃2を通して呼び出す）は、USS＃1がそのような操作を持っていることを学びます。
5. 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.
5. 利害関係者は、その操作のためのネットワークRIDディスプレイプロバイダ（Net RID DPS）として機能する、US＃1のその操作に関する更新を追跡することができます。
6. 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).
6. USS＃1（Net-RIDS SPとして）は、USS＃2からUSS＃2を介して他のすべての購読されたUSSにUAS＃1ステータスと位置の更新を公開します（Net-Rud DPとして）。
7. 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).
7. UAS＃1のその操作を登録した全てのNET RID DPは、そのトラック情報をUAS＃1（via via via vian単位は、F3411-19]によって指定されていないが一般的にWebと推定される）にそのトラック情報を提供するであろう。ブラウザベース）
Network RID has several connectivity scenarios:
ネットワークRIDには、いくつかの接続シナリオがあります。
* _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).
* _persistredにインターネット接続されたUA_は、一貫して直接RID情報をソースにします。これは、意図された動作空間ボリュームを通して、プラスバッファ（例えば、WINDSがボリュームからUAを駆動する可能性がある）を介して無線カバレッジを必要とする。
* _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.
* _INTERMITTINDインターネット接続UA_は、通常、情報を直接ソファイすることができますが、OFFLINEの場合（例えば、UASを使用して検査されている大きな構造による信号遮断による信号遮断により）、GCSがプロキシソースRID情報に必要です。
* _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).
* _INDIRECTLEに接続されているUA_は、インターネットに転送されるが、インターネットにリレーまたはプロキシRID情報を中継することができる他のノードと他のノードとの通信をいくつか持っています。通常、このノードはGCSになります（C2のリンク停止は発生しますが、その機能を実行する必要があります。
* _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.
* _non-connected ua_は、RID情報をソウシングする手段はありません。その場合、演算子で使用可能なGCSまたは他のいくつかのインタフェースはそれをソース化する必要があります。極端な場合、これは、Webブラウザまたはアプリケーションを使用して、Webブラウザまたはアプリケーションを使用して、米国または他のUTMエンティティを使用して、操作が行われる時限空間ボリュームを使用することができます。これは、「エリア操作」に従事する「非搭載ネットワーク参加者」と呼ばれます。複数のUASが同じまたは重複する4Dボリュームで動作する場合、これはIDの曖昧さを妨げる可能性があります。ほとんどの空域ボリュームでは、接続されていない場合、ほとんどのクラスのUAは飛行することは許可されません。
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.
ほとんどの場合（2021）、ネットワークRIDファーストホップデータリンクはセルラー（既存の大規模なカバレッジエリアを介してBVLOS C2をサポートすることもできます）またはWi-Fi（Broadcast RIDをサポートできます）のどちらかである可能性があります。 。しかしながら、データリンクが少なくともUDP / IPをサポートし、理想的にはTCP / IPをサポートすることができるならば、そのタイプは一般により高い層のプロトコルにとって重要ではない。 UASは、ネットワークRID情報の最終的なソースとして、Net-RidS SP（通常はUASオペレータが購読するUS）をフィードし、これはUASおよび他のデータソースのプロキシをプロキシします。ネットワークRID情報のオブザーバーまたは他の究極の消費者は、Net-Rid DP（典型的には米国）からそれを取得しており、これは複数のNet-Rid SPSからの情報を統括して興味のある体積の範囲のカバレッジを提供します。ネットワークRIDサービスおよび表示プロバイダは、よく接続されたインフラストラクチャ内のサーバーとして実装され、インターネットを介して互いに通信し、Webアプリケーションプログラミングインターフェイス（API）およびブラウザなどの手段を介してオブザーバーによってアクセスできるようになります。
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.
ネットワークRIDは、UAS RIDの定義された手段の拘束が少ないです。[F3411-19] Net-Rid SPからNet-RID DPへの情報交換のみを指定します。より拘束された放送RID（次のセクションを参照）をサポートするIETFの取り組みは、ネットワークRIDおよび潜在的にUASからUSSまたはその他のUTM通信にも一般化できます。
Figure 4 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.
放送RID情報フローを示す図である。図からインターネットがないことに注意してください。これは、ブロードキャストRIDが、UAからローカルオブザーバデバイスへのRFデータリンク（IPなし）を介したアプリケーション層メッセージの一方向直接送信であるためです。インターネット接続は、Webベースのブロードキャスト認証検証サービスを使用した検証署名などの情報を受信した情報と、UAS IDをプライマリ固有のキーとして使用しているレジストリ内の情報を検索することだけが、オブザーバーが受信した情報にのみ関係しています。
+-------------------+
| Unmanned Aircraft |
+---------o---------+
|
|
|
| app messages directly over one-way RF data link
|
|
v
+------------------o-------------------+
| Observer's device (e.g., smartphone) |
+--------------------------------------+
Figure 4: Broadcast RID Information Flow
図4：RIDS情報の流れを放送する
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.
放送RIDは、自動依存監視 - 放送（ADS-B）と概念的に似ています。ただし、さまざまな技術的およびその他の理由で、EASAを含む規制当局は許可する意図を示していません。
[F3411-19] 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.
[F3411-19] 4つの放送RIDデータリンクを指定します.Bluetooth 4.x、拡張広告付きBluetooth 5.x、長距離コード化PHY（S = 8）、2.4 GHzのWi-Fi Nan、Wi-Fi Nan5 GHz。これらのうちの少なくとも1つに（他のオプションがブロードキャストがサポートされていない広告メカニズムを使用して）UAを放送する必要があります。Bluetooth 5.xで送信する場合は、4.x（F3411-19]では「Bluetooth Legacy」として参照されている）で同時に実行する必要があります。ヨーロッパの基準のドラフトによって動機づけられた、「F3411-19」を修正するための現在（2021）の議論は、Bluetoothバージョンの両方が要求されることを示唆しています。5 GHzでWi-Fi Nanを放送する場合は、2.4 GHzで同時に実行する必要があります。ASTM F38.02における現在の議論はこれをリラックスしています。Wi-Fiビーコンも検討中です。[F3411-19]の将来の改訂は、他のデータリンクを可能にし得る。
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.
放送RIDメディアの選択は、「地面」ユニット（スマートフォンとタブレット）で一般的に利用可能なものと、UAでは一般的なものまたは「手頃な価格」と見込まれたものに研究によって推進されました。さらに、オブザーバーの受信アプリケーションがこれらのメッセージにアクセスできるようにするためのAPIが必要です。まだ、Bluetooth 4.xサポートのみが簡単に利用できます。したがって、現在の焦点は、ビーコンチャネル上の「広告」として送信されたBluetooth 4.xの「ブロードキャストフレーム」の31バイトのペイロード制限内で動作することである。オーバーヘッド後、これによりRIDメッセージを25バイト、UAS ID文字列を最大20バイトに制限します。
A single Bluetooth 4.x advertisement frame can just barely fit any UAS ID long enough to be sufficiently unique for its purpose.
単一のBluetooth 4.x広告フレームは、その目的のために十分にユニットであるのに十分な長さのUAS IDをほとんど適切に適合させることができます。
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.
主張されたUAS IDが確かに送信者によって所有されていることを確認するために、2）関連情報は確かにその同じUAS IDの所有者によって確かに送信され、認証データ要素は通常、従来の暗号化署名で長くなるでしょう。スキーム現在標準化されている最新のスキームでも、それらは1フレームに収まるには長すぎるでしょう。
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.
したがって、それは、単一のBluetooth 4.xフレーム内のUAS IDおよび対応する認証データ要素に関する情報をバンドルすることができる。それでも、どういうわけかこれらすべてが一緒にしっかりと束縛されなければなりません。
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).
単一のフレームにカプセル化できないメッセージ（これまで、認証メッセージのみ）をメッセージ "Pages"にセグメント化する必要があります（[F3411-19]の用語）。メッセージページは、どういうわけか同じメッセージに属すると相関がある必要があります。Position、Velocity、およびその他のデータを搬送するメッセージは、どういうわけか、UAS IDを搭載した基本IDメッセージと相関させる必要があります。この相関関係は、メディアアクセス制御（MAC）アドレスに基づいて行われると予想されます。これはMACアドレスのランダム化によって複雑になる可能性があります。Oververによって使用されると予想されるすべての一般的なデバイスが、送信者MACアドレスをユーザーSpace Receiverアプリケーションに使用できるようにするAPIを持っています。MACアドレスは簡単になりすましています。データ要素は他のメディアではそれほど切り離されていません（次の段落のメッセージパックを参照）。
[F3411-19] 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).
[F3411-19] Broadcast RIDは複数のメッセージタイプを指定します（[F3411-19のセクション5.4.5]および表3を参照）。以下の表は、これらのメッセージタイプを示しています。ヘッダー内の4ビットメッセージタイプフィールドは、最大16種類のインデックスを参照できます。書き込み時に7つだけ定義されます。2つだけが必須です。他のすべては、管轄権機関、例えばCAAによって必要とされない限り、オプションです。EASAとFAAの両方の規則を満たすために、ルールによって必要とされるデータ要素が複数のメッセージタイプにわたって（ルールでは必要ないデータ要素と共に）複数のメッセージタイプに分散されているため、すべてのタイプが必要です。
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).
Message Pack（Type 0xf）は実際にはメッセージではありませんが、他のタイプのサブセットの各タイプの最大1つのメッセージの枠ではありません。カプセル化できるメッセージのいくつかは必須です。その他はオプションです。メッセージパック自体は、単一のフレーム（Bluetooth 5.xとWi-Fi）でカプセル化できるデータリンクに必須です。
+-------+-----------------+-----------+---------------+
| Index | Name | Req | Notes |
+-------+-----------------+-----------+---------------+
| 0x0 | Basic ID | Mandatory | - |
+-------+-----------------+-----------+---------------+
| 0x1 | Location/Vector | Mandatory | - |
+-------+-----------------+-----------+---------------+
| 0x2 | Authentication | Optional | paged |
+-------+-----------------+-----------+---------------+
| 0x3 | Self-ID | Optional | free text |
+-------+-----------------+-----------+---------------+
| 0x4 | System | Optional | - |
+-------+-----------------+-----------+---------------+
| 0x5 | Operator ID | Optional | - |
+-------+-----------------+-----------+---------------+
| 0xF | Message Pack | - | BT5 and Wi-Fi |
+-------+-----------------+-----------+---------------+
Table 1: Message Types Defined in [F3411-19]
表1：[F3411-19]で定義されているメッセージタイプ
[F3411-19] 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.
[F3411-19] Broadcast RIDは非常に少ない定量的性能要件を指定します。静的情報は少なくとも3秒に1回送信されなければならず、動的情報（場所/ベクトルメッセージ）は少なくとも1秒間に1回以上送信されなければならず、送信されたとき[Frur]少なくとも毎秒全ての情報を送信する必要があります。
[F3411-19] 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.
[F3411-19] Broadcast RIDはすべての情報をClearText（ASCIIまたはバイナリ）として送信するため、静的IDSは使用パターンの些細な相関関係を有効にします。
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.
任意のUAは、[F3411-19]必須の基本IDメッセージを使用してIDをアサートできます。これにより、検証の規定が不足しています。Location / Vector Messageは、同様に検証のための規定を欠いていて、IDを含まないので、基本IDメッセージでどういうわけか相関がある必要があります。[F3411-19]の開発者は、ブロードキャストRIDデータリンクのMACアドレスを使用して提案しています。しかし、これらは静的識別子の敵対的な相関問題を回避するためにオペレーティングシステムスタックによってランダム化されてもよい。
The [F3411-19] 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.
[F3411-19]オプション認証メッセージは認証データのフレーミングを指定しますが、認証方法は指定されていません。）。インターネットを介した証明書をフェッチすることは、必ずしも可能ではありません（例えば、国家森林などの遠隔地で働くオブザーバー）、それによって証明書をブロードキャストRIDで輸送することができる方式を考案することが必要です。ブロードキャストRIDの一方向の性質は、チャレンジ応答セキュリティプロトコル（例えば、署名されたメッセージに返されるために、UAに送信するオブザーバ）を妨げる。[F3411-19]へのドリップ拡張なしで、オブザーバは、アサートされたUAS IDまたはUASまたはそのオペレータに関するその他の情報を検証するために重大な課題になります。
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.
書き込み時に、[F3411-19]の提案されているリビジョンは、ASTM以外のSDOを有効にして認証ペイロードフォーマットを定義できるようにするための新しい認証タイプ5（「固有認証方法（SAM）」）を定義します。ペイロードの最初のバイトはSAMタイプで、そのようなバリアントフォーマットを分離するために使用されます。すべてのフォーマット（プライベート実験用のものとは別に）SAMタイプを割り当てるICAOに登録する必要があります。現在指定されているすべてのブロードキャストRIDメディアを介して正確に同じ形式で送信される認証メッセージペイロードは、201バイトの合計長まで下位レイヤの制約によって制限されています。DRIPで使用される予定の認証タイプ5の場合、SAMタイプバイトはこれらの最初のものを消費し、DRIP認証ペイロードフォーマットを最大200バイトに制限します。
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.
UAS RIDとUTMは補完的です。ネットワークRIDはUTMサービスです。UTMシステムのバックボーンは複数のUSSから構成されています。USSはまた、オペレータおよびUASのための唯一のインターフェース、またはUAS環境への唯一のインターフェースとしても役立ちます。各オペレータは少なくとも1つのUSSを購読する。各UAは、少なくとも1つのUSSでオペレータによって登録されています。各運用意図は1人のUSSに提出されます。承認された場合、そのUASとオペレータはその操作を開始できます。動作中、そのUASのステータスと場所は、そのUSSに報告されなければならず、それはその演算子、UAS、およびUTMシステムへの操作、およびネットワーク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.
USSはネットワークRIDに限定されないサービスを提供します。実際、主要なUSS関数は、異なるUAS（およびそれらの演算子）間の空域使用量の偏侵害です。有人航空機やロケットの発売など、UAS以外の操作からUASを定義します。与えられた操作を含むほとんどの歪みは、その操作を開始する前に完了することが期待されています。これは「戦略的偏降量」と呼ばれます。それが失敗した場合、「戦術的な脱骨は遊び」になります。空中DAA（ABDAA）は、米国を巻き込まないかもしれませんが、地上ベースのDAA（GBDAA）は可能性があります。以前は「UASボリューム制限（UVRS）」と呼ばれる動的制約は、地元の緊急事態や極端な天候などの状況によって、地面の当局によって指定され、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.
ブロードキャストRIDの米国の役割は、現在規制当局または[F3411-19]によって指定されています。ただし、USSは、UAS（およびおそらく演算子）のレジストリ（またはおそらくレジストラ）として機能する可能性があります。もしそうなら、USSはすべての形式のRIDに役割を果たします。補足データサービスプロバイダ（SDSPS）は、UTMだけでなく、UAS RIDおよび関連サービスの強化においても、役割を見つける可能性があります。RIDサービスは、USS、SDSP、またはその他のUTMエンティティとのコンサートで（必要に応じて、必要に応じて利用可能）に使用されます。狭く定義されている、RIDサービスはレギュレータ指定の識別情報を提供します。より広く定義されている、RIDサービスは、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.
上記のギャップに加えて、UAS RIDのためのほとんどすべての電流または提案された規制および技術基準に基本的なギャップがある。上記のように、IDはそれ自体の終わりではなく、手段です。 [F3411-19]に指定されたプロトコルは、緊急時にUAS操作に関するさらなる情報を要求するために、PILOTと通信するための観察者が可能な限られた情報を提供する（しかし技術的な手段はありません）。システムメッセージは、Pilot / GCSの場所を提供するので、オブザーバはリモートパイロットを探すために物理的にアサートされた場所に移動することができます。これは遅く、せいぜい、実行可能ではないかもしれません。パイロットが峡谷の反対側の縁にある場合、またはすべてのGCSがオブザーバーから異なる方向にあると連絡するための複数のUASオペレータがある場合はどうなりますか？インターネット接続とアクセス権限を持つオブザーバは、演算子PIIをレジストリに検索してから、UAS操作にすぐに影響を与えることができる人がその操作中に速やかに答えることを期待して電話番号を呼び出します。これは信頼できない、せいぜい慎重ではないかもしれません。飛行中にパイロットが電話に答えることをお勧めしますか？インターネット技術はこれよりはるかに優れていることができます。
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):
したがって、UASの安全で安全な動作をサポートするRIDシステムの広範な採用を達成するためには、プロトコルは以下のことを行わなければならない（これらの目的の中では固有の張力にもかかわらず）。
* 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.
[F3411-19]のように、UAS RID規制の基本的な手段として規制当局によって承認されると予想されているように、DRIPは同様にセッションIDの作成と登録から始めて、さらなる問題に取り組むことが承認されると予想されます。
DRIP will focus on making information obtained via UAS RID immediately usable:
DRIPは、UAS RIDを介して取得した情報をすぐに使用可能にすることに焦点を当てます。
1. by making it trustworthy (despite the severe constraints of Broadcast RID);
1. それを信頼できるようにすることによって（放送RIDの厳しい制約にもかかわらず）。
2. 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);
2. 検証を有効にすることで、UASがRIDに登録されていること、およびそうであれば（既知のレジストリベッティングに基づいて信頼できる演算子の分類のための、観測時間でインターネット接続を欠く観察者によっても）。
3. 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;
3. UA航空データ（場所、速度など）の独立した報告を促進することによって、UAS RIDおよびUTM追跡が基づくオペレータの自己報告を確認または反論することによって。
4. by enabling instant establishment, by authorized parties, of secure communications with the Remote Pilot.
4. 即時確立を可能にすることによって、許可されたパーティーによって、遠隔操作との安全な通信の。
The foregoing considerations, beyond those addressed by baseline UAS RID standards such as [F3411-19], imply the requirements for DRIP detailed in Section 4.
上記の考察は、[F3411-19]のようなベースラインUAS RID規格で対処されるものを超えて、セクション4に詳述されているDRIPの要件を意味します。
The following requirements apply to DRIP as a set of related protocols, various subsets of which, in conjunction with other IETF and external technical standards, may suffice to comply with the regulations in any given jurisdiction or meet any given user need. It is not intended that each and every protocol of the DRIP set, alone, satisfy each and every requirement. To satisfy these requirements, Internet connectivity is required some of the time (e.g., to support DRIP Entity Identifier creation/registration) but not all of the time (e.g., authentication of an asserted DRIP Entity Identifier can be achieved by a fully working and provisioned Observer device even when that device is off-line so is required at all times).
以下の要件は、他のIETFおよび外部の技術基準と組み合わせて、特定の管轄内の規制に準拠しているか、または特定のユーザーのニーズを満たすことができます。ドリップセットの各プロトコルを単独で、それぞれの要件を満たすことを意図していません。これらの要件を満たすために、インターネット接続は（例えば、DRIPエンティティ識別子の作成/登録をサポートするために）、すべての時間ではなく（例えば、アサートされたドリップエンティティ識別子の認証が完全に機能し、プロビジョニングされることによって達成され得る）必要とされる。そのデバイスがオフラインである場合でもオブザーバデバイスは常に必要です。
GEN-1 Provable Ownership: DRIP MUST enable verification that the asserted entity (typically UAS) ID is that of the actual current sender (i.e., the Entity ID in the DRIP authenticated message set is not a replay attack or other spoof), even on an Observer device lacking Internet connectivity at the time of observation.
GEN-1証明できる所有権：DRIPは、アサートされたエンティティ（通常はUAS）IDが実際の送信者のID（すなわち、DRIP認証されたメッセージセット内のエンティティIDが再生攻撃または他のスプーフィングではない）であることを確認できるようにする必要があります。観察時のインターネット接続を欠くオブザーバ装置。
GEN-2 Provable Binding: DRIP MUST enable the cryptographic binding of all other [F3411-19] messages from the same actual current sender to the UAS ID asserted in the Basic ID Message.
GEN-2証明できるバインディング：DRIPは、同じ実際の送信側から基本IDメッセージでアサートされたUAS IDへの他のすべての[F3411-19]メッセージの暗号化バインディングを有効にする必要があります。
GEN-3 Provable Registration: DRIP MUST enable cryptographically secure verification that the UAS ID is in a registry and identification of that registry, even on an Observer device lacking Internet connectivity at the time of observation; the same sender may have multiple IDs, potentially in different registries, but each ID must clearly indicate in which registry it can be found.
GEN-3証明されている登録：DRIPは、観察時にインターネット接続を欠いているオブザーバーデバイスでさえ、UAS IDがそのレジストリのレジストリと識別にあることを暗号的に安全な検証を有効にする必要があります。同じ送信者は、異なるレジストリに潜在的に複数のIDを持つことができますが、各IDはそれが見つけることができるレジストリに明確に示されなければなりません。
GEN-4 Readability: DRIP MUST enable information (regulation required elements, whether sent via UAS RID or looked up in registries) to be read and utilized by both humans and software.
GEN-4読みやすさ：DRIPは、人間とソフトウェアの両方で読み取られて利用されるように、情報（UAS RIDを介して送信されたか、レジストリに検索されているかどうか）を有効にする必要があります。
GEN-5 Gateway: DRIP MUST enable application-layer gateways from Broadcast RID to Network RID to stamp messages with precise date/time received and receiver location, then relay them to a network service (e.g., SDSP or distributed ledger) whenever the gateway has Internet connectivity.
GEN-5ゲートウェイ：DRIPは、RED RIDSからネットワークRIDへのアプリケーションレイヤゲートウェイを有効にして、ゲートウェイがあるたびにネットワークサービス（例えば、SDSPまたは分散元帳など）にリレーを実行します。インターネット接続
GEN-6 Contact: DRIP MUST enable dynamically establishing, with AAA, per policy, strongly mutually authenticated, end-to-end strongly encrypted communications with the UAS RID sender and entities looked up from the UAS ID, including at least the (1) pilot (Remote Pilot or Pilot In Command), (2) the USS (if any) under which the operation is being conducted, and (3) registries in which data on the UA and pilot are held. This requirement applies whenever each party to such desired communications has a currently usable means of resolving the other party's DRIP Entity Identifier to a locator (IP address) and currently usable bidirectional IP (not necessarily Internet) connectivity with the other party.
GEN-6連絡先：DRIPは、ポリシーごとのAAA、AAA、AAA、急速に認証された、UAS RID送信者およびエンティティがUAS IDから検索され、少なくとも（1）を含むUAS IDから見上げたエンドツーエンドのエンドツーエンドを有効にする必要があります。パイロット（リモートパイロットまたはコマンドのパイロット）、（2）操作が行われているUSS（もしあれば）、および（3）UAおよびパイロットのデータが保持されている登録。この要件は、そのような所望の通信に対する各当事者が、他の当事者のDRIPエンティティ識別子をロケータ（IPアドレス）および現在使用可能な双方向IP（必ずしもインターネットではない）接続性を他の当事者との接続性に解決するための現在使用可能な手段を有するたびに適用される。
GEN-7 QoS: DRIP MUST enable policy-based specification of performance and reliability parameters.
GEN-7 QoS：DRIPは、パフォーマンスと信頼性パラメータのポリシーベースの仕様を有効にする必要があります。
GEN-8 Mobility: DRIP MUST support physical and logical mobility of UA, GCS, and Observers. DRIP SHOULD support mobility of essentially all participating nodes (UA, GCS, Observers, Net-RID SP, Net-RID DP, Private Registries, SDSP, and potentially others as RID and UTM evolve).
GEN-8移動度：DRIPは、UA、GCS、およびオブザーバーの身体的および論理的な移動性をサポートしている必要があります。DRIPは、本質的にすべての参加ノード（UA、GCS、オブザーバー、NET-RIDS SP、NET-RID DP、プライベートレジストリ、SDSP、および潜在的にはRIDおよびUTM Evolve）のモビリティをサポートする必要があります。
GEN-9 Multihoming: DRIP MUST support multihoming of UA and GCS, for make-before-break smooth handoff and resiliency against path or link failure. DRIP SHOULD support multihoming of essentially all participating nodes.
GEN-9マルチホーム：DRIPは、経路やリンク障害に対する滑らかなハンドオフと回復力の前に、UAとGCSのマルチホームをサポートしている必要があります。DRIPは、本質的にすべての参加ノードのマルチホームをサポートする必要があります。
GEN-10 Multicast: DRIP SHOULD support multicast for efficient and flexible publish-subscribe notifications, e.g., of UAS reporting positions in designated airspace volumes.
GEN-10マルチキャスト：DRIPは、指定された空域ボリューム内のUAS報告ポジションの、効率的で柔軟な公開購読通知のためのマルチキャストをサポートする必要があります。
GEN-11 Management: DRIP SHOULD support monitoring of the health and coverage of Broadcast and Network RID services.
GEN-11管理：DRIPは、ブロードキャストおよびネットワークRIDサービスの健康とカバレッジの監視をサポートする必要があります。
Requirements imposed either by regulation or by [F3411-19] are not reiterated in this document, but they drive many of the numbered requirements listed here. The regulatory performance requirement in [FRUR] currently would be satisfied by ensuring information refresh rates of at least 1 Hertz, with latencies no greater than 1 second, at least 80% of the time, but these numbers may vary between jurisdictions and over time. Instead, the DRIP QoS requirement is that parameters such as performance and reliability be specifiable by user policy, which does not imply satisfiable in all cases but does imply (especially together with the Management requirement) that when specifications are not met, appropriate parties are notified.
規制または[F3411-19]によって課される要件は、この文書では繰り返されていませんが、ここに記載されている番号の多くの要件を駆動します。[Frur]の規制性能要件は、現在1秒以上、少なくとも80％以上の時間を持たない、少なくとも1秒以上の情報のリフレッシュレートを確保することで満足されるでしょうが、これらの数は管轄区域と経時的に変わる可能性があります。代わりに、DRIP QoSの要件は、パフォーマンスと信頼性などのパラメータはユーザーポリシーによって指定できます。これは、すべての場合において満足のいくものを意味するのではなく、仕様が満たされていない場合に（特に管理要件とともに）適切な当事者が通知されます。。
The Provable Ownership requirement addresses the possibility that the actual sender is not the claimed sender (i.e., is a spoofer). DRIP could meet this requirement by, for example, verifying an asymmetric cryptographic signature using a sender-provided public key from which the asserted UAS ID can be at least partially derived. The Provable Binding requirement addresses the problem with MAC address correlation [F3411-19] noted in Section 3.2. The Provable Registration requirement may impose burdens not only on the UAS sender and the Observer's receiver, but also on the registry; yet, it cannot depend upon the Observer being able to contact the registry at the time of observing the UA. The Readability requirement pertains to the structure and format of information at endpoints rather than its encoding in transit, so it may involve machine-assisted format conversions (e.g., from binary encodings) and/or decryption (see Section 4.3).
証明可能な所有権要件は、実際の送信者がクレームされた送信者ではない可能性を解決しています（すなわち、スプーファーである）。DRIPは、例えば、アサートされたUAS IDが少なくとも部分的に導出され得る送信者提供公開鍵を使用して非対称暗号署名を検証することによってこの要求を満たすことができる。証明されたバインディング要件は、MACアドレス相関[F3411-19]の問題を3.2節で注意しています。証明可能な登録要件は、UAS送信者およびオブザーバの受信者だけでなく、レジストリ上でも負担を課す可能性がある。それでも、UAを観察する際には、観察者がレジストリに連絡できることに依存することはできません。読みやすさの要件は、通過中の符号化ではなくエンドポイントでの情報の構造とフォーマットに関するものであるため、機械支援フォーマット変換（例えば、バイナリエンコーディングから）や復号化を含めることがあります（セクション4.3を参照）。
The Gateway requirement is in pursuit of three objectives: (1) mark up a RID message with where and when it was actually received, which may agree or disagree with the self-report in the set of messages; (2) defend against replay attacks; and (3) support optional SDSP services such as multilateration, to complement UAS position self-reports with independent measurements. This is the only instance in which DRIP transports [F3411-19] messages; most of DRIP pertains to the authentication of such messages and identifiers carried in them.
ゲートウェイ要件は3つの目的を追求しています。（1）実際に受信した場合とそのメッセージのセット内の自己報告に同意または反対して、RIDメッセージをマークアップします。（2）リプレイ攻撃に対して守る。（3）独立した測定でUAS位置の自己レポートを補完するために、多層化などのオプションのSDSPサービスをサポートします。これはDRIPトランスポート[F3411-19]メッセージの唯一のインスタンスです。ほとんどのドリップは、そのようなメッセージの認証とそれらの中で運ばれる識別子に関係します。
The Contact requirement allows any party that learns a UAS ID (that is a DRIP Entity Identifier rather than another ID Type) to request establishment of a communications session with the corresponding UAS RID sender and certain entities associated with that UAS, but AAA and policy restrictions, inter alia on resolving the identifier to any locators (typically IP addresses), should prevent unauthorized parties from distracting or harassing pilots. Thus, some but not all Observers of UA, receivers of Broadcast RID, clients of Network RID, and other parties can become successfully initiating endpoints for these sessions.
連絡要件は、対応するUAS RID送信者とそのUASに関連する特定のエンティティとの通信セッションの確立を要求するためのUAS ID（別のIDタイプではなくDRIPエンティティ識別子である）を学習する任意の当事者を可能にしますが、AAAおよびポリシーの制限事項、識別子を任意のロケーター（通常はIPアドレス）に解決する際のとりわけ、不正な当事者がパイロットを気を散らすか嫌がらせを防ぐべきである。したがって、UAのすべての観察者、ブロードキャストRIDの受信機、ネットワークRIDのクライアント、および他の当事者は、これらのセッションのエンドポイントの開始に成功することがあります。
The QoS requirement is only that performance and reliability parameters can be _specified_ by policy, not that any such specifications must be guaranteed to be met; any failure to meet such would be reported under the Management requirement. Examples of such parameters are the maximum time interval at which messages carrying required data elements may be transmitted, the maximum tolerable rate of loss of such messages, and the maximum tolerable latency between a dynamic data element (e.g., GNSS position of UA) being provided to the DRIP sender and that element being delivered by the DRIP receiver to an application.
QoS要件は、そのような仕様が満たされることが保証されている必要があることではありません。そのような会合の失敗は、管理要件の下で報告されます。そのようなパラメータの例は、必要なデータ要素を搬送するメッセージが送信され得る最大時間間隔、そのようなメッセージの損失の最大許容率、および提供されている動的データ要素（例えば、UAのGNSS位置）間の最大許容待ち時間である。ドリップ送信者に、その要素はDRIP受信機によってアプリケーションに配信されています。
The Mobility requirement refers to rapid geographic mobility of nodes, changes of their points of attachment to networks, and changes to their IP addresses; it is not limited to micro-mobility within a small geographic area or single Internet access provider.
モビリティ要件は、ノードの迅速な地理的移動性、ネットワークへの添付要素の変化、およびそれらのIPアドレスへの変更を指します。それは、小さな地理的領域または単一のインターネットアクセスプロバイダ内のマイクロモビリティに限定されない。
ID-1 Length: The DRIP Entity Identifier MUST NOT be longer than 19 bytes, to fit in the Specific Session ID subfield of the UAS ID field of the Basic ID Message of the proposed revision of [F3411-19] (at the time of writing).
ID-1長さ：DRIPエンティティ識別子は19バイトを超えてはいけません[F3411-19]の提案されているリビジョンの基本IDメッセージのVASIC IDフィールドの特定のセッションIDサブフィールドに収まりません（時点で）書き込み）。
ID-2 Registry ID: The DRIP identifier MUST be sufficient to identify a registry in which the entity identified therewith is listed.
ID-2レジストリID：DRIP識別子は、それによって識別されたエンティティがリストされているレジストリを識別するのに十分でなければなりません。
ID-3 Entity ID: The DRIP identifier MUST be sufficient to enable lookups of other data associated with the entity identified therewith in that registry.
ID-3エンティティID：DRIP識別子は、そのレジストリ内で識別されたエンティティに関連付けられている他のデータの検索を有効にするのに十分でなければなりません。
ID-4 Uniqueness: The DRIP identifier MUST be unique within the applicable global identifier space from when it is first registered therein until it is explicitly deregistered therefrom (due to, e.g., expiration after a specified lifetime, revocation by the registry, or surrender by the operator).
ID-4一意性：DRIP識別子は、それが最初にそこから明示的に登録されたとき（指定された有効期間の後の有効期限、レジストリによる失効、またはによって降伏のために、または降伏のために）から該当するグローバル識別子空間内で固有でなければならない。オペレーター）。
ID-5 Non-spoofability: The DRIP identifier MUST NOT be spoofable within the context of a minimal Remote ID broadcast message set (to be specified within DRIP to be sufficient collectively to prove sender ownership of the claimed identifier).
ID-5非スプーフィズム：DRIP識別子は、最小限のリモートIDブロードキャストメッセージセットのコンテキスト内でスプーフ可能ではありません（DRIP内で指定されているために、クレームされた識別子の送信者の所有権を証明するのに十分なものにするために）。
ID-6 Unlinkability: The DRIP identifier MUST NOT facilitate adversarial correlation over multiple operations. If this is accomplished by limiting each identifier to a single use or brief period of usage, the DRIP identifier MUST support well-defined, scalable, timely registration methods.
ID-6リンク許可：DRIP識別子は、複数の操作上の需要相関を容易にしてはいけません。これが各識別子を単一の使用または短時間の使用期間に制限することによって達成される場合、DRIP識別子は明確に定義されたスケーラブル、タイムリーな登録方法をサポートしなければならない。
The DRIP identifier can refer to various entities. In the primary initial use case, the entity to be identified is the UA. Entities to be identified in other likely use cases include, but are not limited to, the operator, USS, and Observer. In all cases, the entity identified must own the identifier (i.e., have the exclusive capability to use the identifier, such that receivers can verify the entity's ownership of it).
DRIP識別子はさまざまなエンティティを参照できます。一次初期使用例では、識別されるエンティティはUAである。他の可能性のある使用例で識別されるエンティティには、オペレータ、USS、およびオブザーバが含まれますが、これらに限定されません。すべての場合において、識別されたエンティティは識別子を所有している必要があります（すなわち、受信機がエンティティの所有権を検証することができるように、識別子を使用するための排他的能力を有する）。
The DRIP identifier can be used at various layers. In Broadcast RID, it would be used by the application running directly over the data link. In Network RID, it would be used by the application running over HTTPS (not required by DRIP but generally used by Network RID implementations) and possibly other protocols. In RID-initiated V2X applications such as DAA and C2, it could be used between the network and transport layers (e.g., with the Host Identity Protocol (HIP) [RFC9063] [RFC7401]) or between the transport and application layers (e.g., with DTLS [RFC6347]).
DRIP識別子は様々な層で使用できます。ブロードキャストRIDでは、データリンクを直接実行しているアプリケーションによって使用されます。ネットワークRIDでは、HTTPSを介して実行されているアプリケーション（DRIPでは必要ではなく、通常はネットワークRID実装で使用されています）およびおそらく他のプロトコルで使用されます。DAAおよびC2のようなRID - 開始されたV2Xアプリケーションでは、ネットワーク層とトランスポート層（例えば、ホストIDプロトコル（HIP）[RFC9063] [RFC7401]）またはトランスポート層とアプリケーション層の間で使用できます（たとえば、DTLS [RFC6347]。
Registry ID (which registry the entity is in) and Entity ID (which entity it is, within that registry) are requirements on a single DRIP Entity Identifier, not separate (types of) ID. In the most common use case, the entity will be the UA, and the DRIP identifier will be the UAS ID; however, other entities may also benefit from having DRIP identifiers, so the entity type is not prescribed here.
レジストリID（エンティティが属している）とエンティティID（そのレジストリ内にあるエンティティ）は、単一のDRIPエンティティ識別子の要件で、別々の（タイプ）IDではありません。最も一般的なユースケースでは、エンティティはUAになり、DRIP識別子はUAS IDになります。しかしながら、他のエンティティもDRIP識別子を有することから利益を得ることができるので、エンティティタイプはここで規定されていない。
Whether a UAS ID is generated by the operator, GCS, UA, USS, registry, or some collaboration among them is unspecified; however, there must be agreement on the UAS ID among these entities. Management of DRIP identifiers is the primary function of their registration hierarchies, from the root (presumably IANA), through sector-specific and regional authorities (presumably ICAO and CAAs), to the identified entities themselves.
UAS IDがオペレータによって生成されたかどうか、GCS、UA、USS、レジストリ、またはそれらの間のいくつかのコラボレーションは指定されていません。ただし、これらのエンティティ間でUAS IDについて合意が必要です。DRIP識別子の管理は、根（おそらくIANA）から、セクター固有および地域当局（おそらくICAOおよびCAAS）を通じて、識別されたエンティティ自体を通じて、登録階層の主な機能です。
While Uniqueness might be considered an implicit requirement for any identifier, here the point of the explicit requirement is not just that it should be unique, but also where and when it should be unique: global scope within a specified space, from registration to deregistration.
一意性があらゆる識別子の暗黙の要件と見なされるかもしれませんが、明示的な要件のポイントはそれが一意であるべきであるだけでなく、それがユニークであるべきか、そしてそれが指定されたスペース内のグローバルスコープ、登録までのグローバルスコープでもあります。
While Non-spoofability imposes requirements for and on a DRIP authentication protocol, it also imposes requirements on the properties of the identifier itself. An example of how the nature of the identifier can support non-spoofability is embedding a hash of both the Registry ID and a public key of the entity in the entity identifier, thus making it self-authenticating any time the entity's corresponding private key is used to sign a message.
スプーフ性がDRIP認証プロトコルの要件を課し、それはまた識別子自体のプロパティに要件を課す。識別子の性質がスプーフィ社の非スプーフィビリティをサポートできる方法の例は、エンティティ識別子内のエンティティIDと実体の公開鍵の両方のハッシュを埋め込むことであるため、エンティティ対応する秘密鍵が使用されている時間を自己認証することができる。メッセージに署名する。
While Unlinkability is a privacy desideratum (see Section 4.3), it imposes requirements on the DRIP identifier itself, as distinct from other currently permitted choices for the UAS ID (including primarily the static serial number of the UA or RID module).
アンネルリンク許可はプライバシー望まれていますが（セクション4.3を参照）、それは、UAS IDの他の現在許容されている選択とは異なる（主にUAまたはRIDモジュールの静的なシリアル番号を含む）。
PRIV-1 Confidential Handling: DRIP MUST enable confidential handling of private information (i.e., any and all information that neither the cognizant authority nor the information owner has designated as public, e.g., personal data).
PRIV-1機密処理：DRIPは、個人情報の機密処理を有効にしなければなりません（すなわち、認識者権限も情報所有者も公衆データ、例えば個人データとして指定されていないすべての情報）。
PRIV-2 Encrypted Transport: DRIP MUST enable selective strong encryption of private data in motion in such a manner that only authorized actors can recover it. If transport is via IP, then encryption MUST be end-to-end, at or above the IP layer. DRIP MUST NOT encrypt safety critical data to be transmitted over Broadcast RID in any situation where it is unlikely that local Observers authorized to access the plaintext will be able to decrypt it or obtain it from a service able to decrypt it. DRIP MUST NOT encrypt data when/where doing so would conflict with applicable regulations or CAA policies/procedures, i.e., DRIP MUST support configurable disabling of encryption.
PRIV-2暗号化トランスポート：DRIPは、許可されたアクターのみがそれを回復できるように、動きの選択的な強力な暗号化を有効にする必要があります。トランスポートがIPを介している場合、暗号化はIPレイヤの中または上または上にエンドツーエンドでなければなりません。DRIPは、平文にアクセスすることを許可された地元のオブザーバーがそれを復号化することができるか、またはそれを復号化できるサービスから入手できるような状況で、放送RIDを介して送信される安全性の重要なデータを暗号化してはいけません。該当する規制またはCAAポリシー/手順と矛盾する場合、DRIPはデータを暗号化してはいけません。
PRIV-3 Encrypted Storage: DRIP SHOULD facilitate selective strong encryption of private data at rest in such a manner that only authorized actors can recover it.
PRIV-3暗号化ストレージ：DRIPは、許可されたアクターのみを回復できるように、休憩時の個人データの選択的強い暗号化を促進するはずです。
PRIV-4 Public/Private Designation: DRIP SHOULD facilitate designation, by cognizant authorities and information owners, of which information is public and which is private. By default, all information required to be transmitted via Broadcast RID, even when actually sent via Network RID or stored in registries, is assumed to be public; all other information held in registries for lookup using the UAS ID is assumed to be private.
PRIV-4公開/プライベート指定：DRIPは、認識者当局および情報所有者によって指定され、その情報が一般に公開されています。デフォルトでは、実際にネットワークRIDを介して送信されるか、レジストリに格納されている場合でも、放送RIDを介して送信するのに必要なすべての情報が、公開されていると見なされます。UAS IDを使用しているルックアップのレジストリで保持されている他のすべての情報はプライベートであると見なされます。
PRIV-5 Pseudonymous Rendezvous: DRIP MAY enable mutual discovery of and communications among participating UAS operators whose UA are in 4-D proximity, using the UAS ID without revealing pilot/operator identity or physical location.
PRIV-5仮名Rendezvous：DRIPは、Pilot / Operator IDまたは物理的な場所を明らかにすることなく、UAが4D近接にある参加UAS演算子の相互発見と通信を可能にします。
Most data to be sent via Broadcast RID or Network RID is public; thus, the Encrypted Transport requirement for private data is selective, e.g., for the entire payload of the Operator ID Message, but only the pilot/GCS location fields of the System Message. Safety critical data includes at least the UA location. Other data also may be deemed safety critical, e.g., in some jurisdictions the pilot/GCS location is implied to be safety critical.
ブロードキャストRIDまたはネットワークRIDを介して送信されるほとんどのデータは公開されています。したがって、プライベートデータに対する暗号化されたトランスポート要件は、例えば、オペレータIDメッセージのペイロード全体について選択的であるが、システムメッセージのPilot / GCSロケーションフィールドのみである。安全性の重要なデータには、少なくともUAの場所が含まれています。他のデータも安全性が重要であると考えされてもよい。
UAS have several potential means of assessing the likelihood that local Observers authorized to access the plaintext will be able to decrypt it or obtain it from a service able to decrypt it. If the UAS is not participating in UTM, an Observer would have no means of obtaining a decryption key or decryption services from a cognizant USS. If the UAS is participating in UTM but has lost connectivity with its USS, then an Observer within visual LOS of the UA is also unlikely to be able to communicate with that USS (whether due to the USS being offline or the UAS and Observer being in an area with poor Internet connectivity). Either of these conditions (UTM non-participation or USS unreachability) would be known to the UAS.
UASには、平文にアクセスすることを許可されている地元のオブザーバーが復号化したり、復号化できるサービスから入手できる可能性を評価する可能性がいくつかあります。UASがUTMに参加していない場合、オブザーバーは、認識されたUSSから復号化キーまたは復号化サービスを取得する手段はありません。UASがUTMに参加しているが、そのUSSとの接続性を失った場合、UAの視覚的LOS内のオブザーバーは、その米国と通信することができることもありそうもない（米国がオフラインまたはUASおよびオブザーバーに参加しているかどうかにかかわらず）。インターネット接続が悪い領域）。これらの条件（UTMの非参加またはUSSの到達不能）のいずれかがUASに知られているでしょう。
In some jurisdictions, the configurable enabling and disabling of encryption may need to be outside the control of the operator. [FRUR] mandates that manufacturers design RID equipment with some degree of tamper resistance; the preamble of [FRUR] and other FAA commentary suggest this is to reduce the likelihood that an operator, intentionally or unintentionally, might alter the values of the required data elements or disable their transmission in the required manner (e.g., as cleartext).
いくつかの管轄区域では、暗号化の設定可能な有効化および無効化は、オペレータの制御の外側にある必要があるかもしれません。[Fru]製造業者は、ある程度の耐タンパー抵抗を持つ装置を設計することを義務付けています。[Frur]および他のFAA解説のプリアンブルは、演算子が意図的または意図的に必要なことを変更する可能性を減らすこと、または必要な方法でそれらの送信を無効にすること（例えば、ClearTextとして）演算子が変更される可能性を減らすことを示唆している。
How information is stored on end systems is out of scope for DRIP. Encouraging privacy best practices, including end system storage encryption, by facilitating it with protocol design reflecting such considerations is in scope. Similar logic applies to methods for designating information as public or private.
エンドシステムに情報が保存されている方法は、DRIPの範囲外です。このような考慮事項を反映してプロトコル設計を容易にすることで、エンドシステムストレージ暗号化を含むプライバシーのベストプラクティスを奨励します。同様の論理は、公開またはプライベートとして情報を指定するための方法に適用されます。
The Privacy requirements above are for DRIP, neither for [F3411-19] (which, in the interest of privacy, requires obfuscation of location to any Network RID subscriber engaging in wide area surveillance, limits data retention periods, etc.), nor for UAS RID in any specific jurisdiction (which may have its own regulatory requirements). The requirements above are also in a sense parameterized: who are the "authorized actors", how are they designated, how are they authenticated, etc.?
上記のプライバシー要件は、[F3411-19]ではなく（プライバシーの興味があるため、広域監視で任意のネットワークRID加入者に難読化する必要があり、データ保存期間など）、またはUASは、特定の管轄（独自の規制要件を持っている可能性があります）で除去されます。上記の要件も意味があります。
REG-1 Public Lookup: DRIP MUST enable lookup, from the UAS ID, of information designated by cognizant authority as public and MUST NOT restrict access to this information based on identity or role of the party submitting the query.
REG-1 Public Lookup：DRIPは、Publicとして認識権限によって指定された情報の検索をUAS IDから有効にする必要があり、クエリを送信するパーティーのIDまたは役割に基づいてこの情報へのアクセスを制限してはなりません。
REG-2 Private Lookup: DRIP MUST enable lookup of private information (i.e., any and all information in a registry, associated with the UAS ID, that is designated by neither cognizant authority nor the information owner as public), and MUST, according to applicable policy, enforce AAA, including restriction of access to this information based on identity or role of the party submitting the query.
REG-2プライベートルックアップ：DRIPは、個人情報の検索（すなわち、認識者の認識局でも情報所有者でも情報所有者でも指定されていません）、およびによると、該当するポリシーは、クエリを送信するパーティーの身元または役割に基づいて、この情報へのアクセスの制限を含むAAAを強制します。
REG-3 Provisioning: DRIP MUST enable provisioning registries with static information on the UAS and its operator, dynamic information on its current operation within the U-space/UTM (including means by which the USS under which the UAS is operating may be contacted for further, typically even more dynamic, information), and Internet direct contact information for services related to the foregoing.
REG-3プロビジョニング：DRIPは、UAS / UTM内の現在の動作に関する動的情報（UASが動作しているUSSがコンタクトされる手段を含む）を使用して、UASとそのオペレータの動的情報を使用してプロビジョニングレジストリを有効にする必要があります（さらに、典型的にはさらに動的、情報）、および上記に関連するサービスのためのインターネット直接連絡先情報。
REG-4 AAA Policy: DRIP AAA MUST be specifiable by policies; the definitive copies of those policies must be accessible in registries; administration of those policies and all DRIP registries must be protected by AAA.
REG-4 AAAポリシー：DRIP AAAはポリシーによって指定できる必要があります。これらのポリシーの決定的なコピーは、レジストリ内でアクセス可能でなければなりません。これらのポリシーの管理とすべてのドリップレジストリは、AAAによって保護されている必要があります。
Registries are fundamental to RID. Only very limited information can be transmitted via Broadcast RID, but extended information is sometimes needed. The most essential element of information sent is the UAS ID itself, the unique key for lookup of extended information in registries. The regulatory requirements for the registry information models for UAS and their operators for RID and, more broadly, for U-space/UTM needs are in flux. Thus, beyond designating the UAS ID as that unique key, the registry information model is not specified in this document. While it is expected that registry functions will be integrated with USS, who will provide them is expected to vary between jurisdictions and has not yet been determined in most jurisdictions. However this evolves, the essential registry functions, starting with management of identifiers, are expected to remain the same, so those are specified herein.
レジストリは、取り除くのが基本です。ブロードキャストRIDを介して送信することができるだけでは、非常に限られた情報のみが送信されますが、拡張情報が必要です。送信された情報の最も重要な要素は、UAS ID自体であり、レジストリ内の拡張情報を検索するための固有のキーです。UASのためのレジストリ情報モデルの規制要件とRIDのためのオペレータ、そしてより広く、U-Space / UTMのニーズにとっては、フラックスです。したがって、UAS IDをその固有キーとして指定することを超えて、この文書ではレジストリ情報モデルが指定されていません。レジストリ関数が私たちと統合されることが予想されているが、それらを提供する予定のものは、法学規制の間で異なると予想され、そしてまだほとんどの管轄区域で決定されていない。ただし、これは、識別子の管理から始まる本質的なレジストリ関数が同じままであると予想されるので、それらは本明細書で指定されている。
While most data to be sent via Broadcast or Network RID is public, much of the extended information in registries will be private. Thus, AAA for registries is essential, not just to ensure that access is granted only to strongly authenticated, duly authorized parties, but also to support subsequent attribution of any leaks, audit of who accessed information when and for what purpose, etc. Specific AAA requirements will vary by jurisdictional regulation, provider philosophy, customer demand, etc., so they are left to specification in policies. Such policies should be human readable to facilitate analysis and discussion, be machine readable to enable automated enforcement, and use a language amenable to both, e.g., eXtensible Access Control Markup Language (XACML).
ブロードキャストまたはネットワークRIDを介して送信されるデータは公開されていますが、レジストリ内の拡張情報の多くはプライベートになります。したがって、登録のためのAAAが不可欠であるため、強く認証された正式な承認された当事者にのみアクセスが許可されているだけでなく、どのような漏洩の後続の帰属も支援するだけでなく、情報がどのような目的の監査を支援するか、任意の目的のための監査など。要件は、管轄規制、プロバイダー哲学、顧客の需要などによって異なりますので、ポリシーで仕様が残ります。そのようなポリシーは、分析および議論を容易にするために、自動化された執行を可能にするために読みやすい機械であるために、そして、例えば拡張可能なアクセス制御マークアップ言語（XACML）に適している言語を使用することを容易にするべきである人間であるべきである。
The intent of the negative and positive access control requirements on registries is to ensure that no member of the public would be hindered from accessing public information, while only duly authorized parties would be enabled to access private information. Mitigation of denial-of-service attacks and refusal to allow database mass scraping would be based on those behaviors, not on identity or role of the party submitting the query per se; however, information on the identity of the party submitting the query might be gathered on such misbehavior by security systems protecting DRIP implementations.
レジストリに関するマイナスおよび正のアクセス制御要件の意図は、公衆情報へのアクセスから公衆のメンバーが妨げられないようにすることですが、正式な情報にアクセスするために有効になるでしょう。サービス拒否攻撃の緩和とデータベースの大量削除を許可することを拒否することは、それらの行動に基づいています。ただし、クエリを送信するパーティのIDに関する情報は、DRIP実装を保護するセキュリティシステムによってそのような不正行為に集められます。
"Internet direct contact information" means a locator (e.g., IP address), or identifier (e.g., FQDN) that can be resolved to a locator, which enables initiation of an end-to-end communication session using a well-known protocol (e.g., SIP).
「インターネット直接連絡先情報」とは、ロケータ（例えば、IPアドレス）、またはロケータに解決され得る識別子（例えば、FQDN）を意味し、それは周知のプロトコルを使用してエンドツーエンド通信セッションの開始を可能にする（たとえば、SIP）。
This document has no IANA actions.
この文書にはIANAの行動がありません。
DRIP is all about safety and security, so content pertaining to such is not limited to this section. This document does not define any protocols, so security considerations of such are speculative. Potential vulnerabilities of DRIP solutions to these requirements include but are not limited to:
DRIPはすべて安全とセキュリティについてのものですので、その内容に関連するコンテンツはこのセクションに限定されません。この文書はプロトコルを定義していないため、セキュリティ上の考慮事項は投機的です。これらの要件に対するDRIPソリューションの潜在的な脆弱性には、以下が含まれますが、これらに限定されません。
* Sybil attacks
* シビル攻撃
* confusion created by many spoofed unsigned messages
* 多くの偽装されていないメッセージによって作成された混乱
* processing overload induced by attempting to verify many spoofed signed messages (where verification will fail but still consume cycles)
* 多くの偽装署名付きメッセージを検証しようとすることで発生した処理過負荷（検証は失敗するが依然としてサイクルを消費する）
* malicious or malfunctioning registries
* 悪意のあるまたは故障のレジストリ
* interception by on-path attacker of (i.e., man-in-the-middle attacks on) registration messages
* 登録メッセージのオンパス攻撃者による傍受（すなわち、中間攻撃）
* UA impersonation through private key extraction, improper key sharing, or carriage of a small (presumably harmless) UA, i.e., as a "false flag", by a larger (malicious) UA
* 秘密鍵の抽出、不適切な鍵共有、または小さい（おそらく無害な）UA、すなわち「偽の旗」として、より大きな（悪意のある）UAによる偽装
It may be inferred from the General requirements (Section 4.1) for Provable Ownership, Provable Binding, and Provable Registration, together with the Identifier requirements (Section 4.2), that DRIP must provide:
証明できる所有権、証明可能な拘束力のある拘束力、および証明可能な登録のための一般的な要件（セクション4.1）から推測されるかもしれません。
* message integrity
* メッセージの整合性
* non-repudiation
* 否認
* defense against replay attacks
* リプレイ攻撃に対する防御
* defense against spoofing
* スプーフィングに対する防御
One approach to so doing involves verifiably binding the DRIP identifier to a public key. Providing these security features, whether via this approach or another, is likely to be especially challenging for Observers without Internet connectivity at the time of observation. For example, checking the signature of a registry on a public key certificate received via Broadcast RID in a remote area presumably would require that the registry's public key had been previously installed on the Observer's device, yet there may be many registries and the Observer's device may be storage constrained, and new registries may come on-line subsequent to installation of DRIP software on the Observer's device. See also Figure 1 and the associated explanatory text, especially the second paragraph after the figure. Thus, there may be caveats on the extent to which requirements can be satisfied in such cases, yet strenuous effort should be made to satisfy them, as such cases are important, e.g., firefighting in a national forest. Each numbered requirement a priori expected to suffer from such limitations (General requirements for Gateway and Contact functionality) contains language stating when it applies.
そのために1つのアプローチは、DRIP識別子を公開鍵に検証できるようにすることを含みます。このアプローチを介して、観察時にインターネット接続性を持たない観察者にとって特に挑戦的であるかどうかにかかわらず、これらのセキュリティ機能を提供することが特に困難である可能性があります。たとえば、リモートエリアでブロードキャストRIDを介して受信した公開鍵証明書のレジストリの署名を確認すると、レジストリの公開鍵がオブザーバーのデバイスに以前にインストールされていたことが必要です。 Observerのデバイス上のDRIPソフトウェアのインストールに続く新しいレジストリが拘束され、新しいレジストリがオンラインである可能性があります。図1および関連する説明文、特に図の後の2番目の段落も参照してください。したがって、そのような場合には要件を満たすことができる程度に注意が払われてもよく、そのような場合が重要であるので、例えば国立林における消防上であるので、それらを満たすために激しい努力をなさなければならない。そのような制限（ゲートウェイおよび連絡先機能のための一般的な要件）に苦しむことが予想される先験的な各要件は、それが適用されるときに述べる言語を含む。
Privacy and transparency are important for legal reasons including regulatory consistency. [EU2018] states:
規制当局の一貫性を含む法的な理由から、プライバシーと透明性が重要です。[EU2018]状態：
| harmonised and interoperable national registration systems ...
| should comply with the applicable Union and national law on
| privacy and processing of personal data, and the information
| stored in those registration systems should be easily accessible.
Transparency (where essential to security or safety) and privacy are also ethical and moral imperatives. Even in cases where old practices (e.g., automobile registration plates) could be imitated, when new applications involving PII (such as UAS RID) are addressed and newer technologies could enable improving privacy, such opportunities should not be squandered. Thus, it is recommended that all DRIP work give due regard to [RFC6973] and, more broadly, to [RFC8280].
透明性（セキュリティまたは安全に不可欠な場合）およびプライバシーも倫理的および道徳的な命令です。PII（UAS RIDなど）を含む新しいアプリケーションが扱われ、新しい技術を含む新しいテクノロジがプライバシーを向上させることができる場合、そのような機会は浪費されるべきではない。したがって、すべてのDRIP作業が[RFC6973]に関して、より広く[RFC8280]に予期することをお勧めします。
However, privacy and transparency are often conflicting goals, demanding careful attention to their balance.
しかし、プライバシーと透明性はしばしば矛盾する目標であり、彼らのバランスに慎重な注意を求めます。
DRIP information falls into two classes:
DRIP情報は2つのクラスに分類されます。
* that which, to achieve the purpose, must be published openly as cleartext, for the benefit of any Observer (e.g., the basic UAS ID itself); and
* 目的を達成するためには、任意の観察者（例えば、基本的なUAS ID自体）の利益のために、クリアテキストとして公開されなければならないこと。と
* that which must be protected (e.g., PII of pilots) but made available to properly authorized parties (e.g., public safety personnel who urgently need to contact pilots in emergencies).
* 保護されなければならない（例えば、パイロットのPII）が適切に認定された当事者（例えば、緊急事態のパイロットに接触させる必要がある公安担当者）に利用可能にされたもの。
How properly authorized parties are authorized, authenticated, etc. are questions that extend beyond the scope of DRIP, but DRIP may be able to provide support for such processes. Classification of information as public or private must be made explicit and reflected with markings, design, etc. Classifying the information will be addressed primarily in external standards; in this document, it will be regarded as a matter for CAA, registry, and operator policies, for which enforcement mechanisms will be defined within the scope of the DRIP WG and offered. Details of the protection mechanisms will be provided in other DRIP documents. Mitigation of adversarial correlation will also be addressed.
正しく認証されたパーティーが許可され、認証されているなど、DRIPの範囲を超えて延びる質問は、DRIPがそのようなプロセスのサポートを提供できる可能性があります。公開またはプライベートとしての情報の分類は、マーキング、設計などで明確で反映されなければなりません。情報を主に外部標準に分類します。この文書では、CAA、レジストリ、およびオペレータのポリシーの問題と見なされます。これは、執行メカニズムがDRIP WGの範囲内で定義され、提供されます。保護メカニズムの詳細は他のドリップ文書に記載されています。敵対的相関の緩和も対処されます。
[F3411-19] ASTM International, "Standard Specification for Remote ID and Tracking", ASTM F3411-19, DOI 10.1520/F3411-19, February 2020, <http://www.astm.org/cgi-bin/resolver.cgi?F3411>.
[F3411-19] ASTM International、「リモートIDと追跡のための標準仕様」、ASTM F3411-19、DOI 10.1520 / F3411-19、2020年2月、<http://www.astm.org/cgi-bin/Resolver。CGI？F3411>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[Amended] European Parliament and Council, "Commission Delegated Regulation (EU) 2020/1058 of 27 April 2020 amending Delegated Regulation (EU) 2019/945 as regards the introduction of two new unmanned aircraft systems classes", April 2020, <https://eur-lex.europa.eu/eli/reg_del/2020/1058/oj>.
[修正]欧州議会議事堂、「委員会議委員会規則（EU）2020/1058 2020年4月27日の27年4月27日の委任規則（EU）2019/945「2つの新しい無人航空機システムクラスの導入」、2020年4月、<https：//eur-lex.europa.eu/eli/reg_del/2020/1058/jj>。
[ASDRI] ASD-STAN, "Introduction to the European UAS Digital Remote ID Technical Standard", January 2021, <https://asd-stan.org/wp-content/uploads/ASD-STAN_DRI_Introduction_to_t he_European_digital_RID_UAS_Standard.pdf>.
[ASDRI] ASD-STAN「ヨーロッパのUASデジタルリモートID技術規格の紹介」、<https：//asd-stan.org/wp-content/uploads/asd-stan_dri_introduction_to_t he_european_digital_rid_uas_standard.pdf>。
[ASDSTAN4709-002] ASD-STAN, "Aerospace series - Unmanned Aircraft Systems - Part 002: Direct Remote Identification", ASD-STAN prEN 4709-002 P1, October 2021, <https://asd-stan.org/downloads/asd-stan-pren-4709-002-p1/>.
[ASDSTAN4709-002] ASD-STAN、「航空宇宙シリーズ - 無人航空機システム - パート002：直接リモート識別」、ASD-Stan Pren 4709-002 P1、2021年10月、<https://asd-stan.org/downloads/ASD-STAN-PREN-4709-002-P1 />。
[CPDLC] Gurtov, A., Polishchuk, T., and M. Wernberg, "Controller-Pilot Data Link Communication Security", Sensors 18, no. 5: 1636, DOI 10.3390/s18051636, 2018, <https://www.mdpi.com/1424-8220/18/5/1636>.
[CPDLC] Gurtov、A.、Polishchuk、T.、およびM.Wernberg、「コントローラパイロットデータリンク通信セキュリティ」、センサ18、NO。5：1636、DOI 10.3390 / S18051636,2018、<https://www.mdpi.com/1424-8220/18/1424>。
[CTA2063A] ANSI, "Small Unmanned Aerial Systems Serial Numbers", ANSI/CTA 2063-A, September 2019, <https://shop.cta.tech/products/small-unmanned-aerial-systems-serial-numbers>.
[CTA2063A] ANSI、「スモール無人航空システムシリアル番号」、ANSI / CTA 2063-A、2019年9月、<https://shop.cta.tech/products/small-unmanned-aerial-Serial-Numbers>。
[Delegated] European Parliament and Council, "Commission Delegated Regulation (EU) 2019/945 of 12 March 2019 on unmanned aircraft systems and on third-country operators of unmanned aircraft systems", March 2019, <https://eur-lex.europa.eu/eli/reg_del/2019/945/oj>.
【代議付け】欧州議会議事堂「委任規則（EU）2019/945 2019年3月12日、無人航空機システムの第三国事業者および2019年3月12日、<https：// EUR-LEX。europa.eu/eli/reg_del/2019/945/j>。
[DRIP-ARCH] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Architecture", Work in Progress, Internet-Draft, draft-ietf-drip-arch-20, 28 January 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch-20>.
[DRIP-ARCH]カード、S、Wiethuechter、A.、Moskowitz、R.、Zhao、S.、Ed。、およびA. Gurtov、「ドローンリモート識別プロトコル（DRIP）アーキテクチャ」、進行中、インターネット - ドラフト、ドラフトIETF-DRIP-ARCH-20、<https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch-20>。
[ENISACSIRT] European Union Agency for Cybersecurity (ENISA), "Actionable information for Security Incident Response", November 2014, <https://www.enisa.europa.eu/topics/csirt-cert-services/reactive-services/copy_of_actionable-information/actionable-information>.
[ENISACSIRT]サイバーセキュリティ（ENISA）、2014年11月、2014年11月、<https：//www.enisa.europa.eu/topics/csirt-cert-services/Reactive-Services/Copy_of_Actionable情報/実用的情報>。
[EU2018] European Parliament and Council, "2015/0277 (COD) PE-CONS 2/18", June 2018, <https://www.consilium.europa.eu/media/35805/easa-regulation-june-2018.pdf>.
【EU2018】2015年6月2日（COD）PE-COND 2/18 "2015/0277（COD）PE-CONS 2/18"、<https：//www.consilium.europa.eu/media/35805/easa-regulation-June-2018.pdf>。
[FAACONOPS] FAA Office of NextGen, "UTM Concept of Operations v2.0", March 2020, <https://www.faa.gov/uas/research_development/ traffic_management/media/UTM_ConOps_v2.pdf>.
[Faaconops] FAA Office of Nextgen、「オペレーションのUTM概念v2.0」、<https://www.faa.gov/uas/research_development/ traffic_management / media / utm_conops_v2.pdf>。
[FR24] Flightradar24, "About Flightradar24", <https://www.flightradar24.com/about>.
[FR24] Flightradar24、 "Flightradar24"、<https://www.flightradar24.com/about>。
[FRUR] Federal Aviation Administration (FAA), "Remote Identification of Unmanned Aircraft", January 2021, <https://www.federalregister.gov/ documents/2021/01/15/2020-28948/remote-identification-of-unmanned-aircraft>.
[Frur]連邦航空管理（FAA）、「無人航空機の遠隔識別」、2021年1月、<https：//www.federalRegister.gov/文書/ 2021/01/15/2020-28948 /リモート識別 - 無人航空機>。
[GDPR] European Parliament and Council, "Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)", April 2016, <https://eur-lex.europa.eu/eli/reg/2016/679/oj>.
[GDPR]欧州議会議事堂、2016年4月27日、2016年4月27日、個人データの加工とそのようなデータの自由な動きに関する自然人の保護に関する「規制（EU）2016/6792016年4月、<https://eur-lex.europa.eu/eli/reg/2016/679/oj>。
[ICAOATM] International Civil Aviation Organization, "Procedures for Air Navigation Services: Air Traffic Management", Doc 4444, November 2016, <https://store.icao.int/en/ procedures-for-air-navigation-services-air-traffic-management-doc-4444>.
[ICAOAROARM]国際民間航空機関、「エアビジョンサービスの手続き：航空交通管理」、DOC 4444、2016年11月、<https：//store.ica.int/en/ / ain/航空ナビゲーションサービス - 空気 - トラフィック管理 - DOC-4444>。
[ICAODEFS] International Civil Aviation Organization, "Defined terms from the Annexes to the Chicago Convention and ICAO guidance material", July 2017, <https://www.icao.int/safety/cargosafety/Documents/ Draft%20Glossary%20of%20terms.docx>.
[ICAODEFS]国際民間航空機関、「附属書からの附属書からシカゴ条約と伊藤師ガイダンス資料」、<https：//www.ica.int/safety/cargosafety/documents/ドラフト％20glossary％20of％20tterms.docx>。
[ICAOUAS] International Civil Aviation Organization, "Unmanned Aircraft Systems", Circular 328, 2011, <https://www.icao.int/meetings/uas/documents/ circular%20328_en.pdf>.
[ICAOUAS]国際民間航空機関、「無人航空機システム」、Circular 328,2011、<https://www.ica.int/meetings/uww.ica.int/meetings/ua s/documents/円形％20328_En.pdf>。
[ICAOUTM] International Civil Aviation Organization, "Unmanned Aircraft Systems Traffic Management (UTM) - A Common Framework with Core Principles for Global Harmonization, Edition 3", October 2020, <https://www.icao.int/safety/UA/Documents/ UTM%20Framework%20Edition%203.pdf>.
[ICAOUTM]国際民間航空機関、「無人航空機システム交通管理（UTM） - 2020年10月、2020年10月、2020年10月、<https://www.ica.int/safety/ua.ine.int/safety/ua/文書/ UTM％20Framework％20edition％203.pdf>。
[Implementing] European Parliament and Council, "Commission Implementing Regulation (EU) 2019/947 of 24 May 2019 on the rules and procedures for the operation of unmanned aircraft", May 2019, <https://eur-lex.europa.eu/eli/reg_impl/2019/947/oj>.
[実施]欧州議会議事堂、2019年5月24日、2019年5月24日、2019年5月24日、2019年5月24日、2019年5月、2019年5月、2019年5月、2019年5月、<https：//eur-lex.europa.eu/ ELI / REG_IMPL / 2019/947 / OJ>。
[InitialView] SESAR Joint Undertaking, "Initial view on Principles for the U-space architecture", July 2019, <https://www.sesarju.eu/sites/default/files/documents/u-space/SESAR%20principles%20for%20U-space%20architecture.pdf>.
[InitialView] SESAR共同開始、2019年7月、<https://www.sesarju.eu/sites/default/files/documents/u-space/sesar%20PRinciples%20UPERFER％20ARCHITECTERE.PDF>。
[LDACS] Maeurer, N., Ed., Graeupl, T., Ed., and C. Schmitt, Ed., "L-band Digital Aeronautical Communications System (LDACS)", Work in Progress, Internet-Draft, draft-ietf-raw-ldacs-09, 22 October 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-raw-ldacs-09>.
[LDACS] Maeurer、N.、Ed。、Graeupl、T.、Ed。、C. Schmitt、Ed。、「Lバンドデジタル航空コミュニケーションシステム（LDACS）」、進行中の作業、インターネットドラフト、ドラフト - IETF-Raw-LDACS-09,2021、<https://datatracker.ietf.org/doc/html/draft-ietf-raw-ldacs-09>。
[NPRM] United States Federal Aviation Administration (FAA), "Notice of Proposed Rule Making on Remote Identification of Unmanned Aircraft Systems", December 2019, <https://www.federalregister.gov/ documents/2019/12/31/2019-28100/remote-identification-of-unmanned-aircraft-systems>.
[NPRM]アメリカ合衆国連邦航空管理（FAA）、2019年12月、2019年12月、<https://www.federalRegister.gov/文書/ 2019/12/31 / 2019-28100 /リモート識別 - 非航空機 - システム>。
[OpenDroneID] "The Open Drone ID specification", commit c4c8bb8, March 2020, <https://github.com/opendroneid/specs>.
[OpenDroneID] "オープンドローンID仕様" "C4C8BB8、2020年3月、<https：//github.com/opendroneId/specs>をコミットします。
[OpenSky] OpenSky Network, "About the OpenSky Network", <https://opensky-network.org/about/about-us>.
[OpenSky] OpenSkyネットワーク、「OpenSkyネットワークについて」、<https://opensky-network.org/about/about-us>。
[Opinion1] European Union Aviation Safety Agency (EASA), "High-level regulatory framework for the U-space", Opinion No 01/2020, March 2020, <https://www.easa.europa.eu/document-library/opinions/opinion-012020>.
[expection1]欧州連合の航空安全庁（EASA）、「U空間のための高級規制枠組み」、<https：//ww.easa.europa.eu/document-library/意見/意見 - 012020>。
[Part107] Code of Federal Regulations, "Part 107 - SMALL UNMANNED AIRCRAFT SYSTEMS", June 2016, <https://www.ecfr.gov/cgi-bin/text-idx?node=pt14.2.107>.
[PART107]連邦規制の規範、「第107部 - 小型無人機システム」、2016年6月、<https：//www.ecfr.gov/cgi-bin/text-idx?node=pt14.2.107>。
[Recommendations] FAA UAS Identification and Tracking (UAS ID) Aviation Rulemaking Committee (ARC), "UAS Identification and Tracking (UAS ID) Aviation Rulemaking Committee (ARC): ARC Recommendations Final Report", September 2017, <https://ww w.faa.gov/regulations_policies/rulemaking/committees/ documents/media/ UAS%20ID%20ARC%20Final%20Report%20with%20Appendices.pdf>.
[勧告] FAA UAS識別および追跡（UAS ID）航空ルーメーキアーション委員会（ARC）、「UAS識別・追跡（UAS ID）航空ルーメーキング委員会（ARC）：ARC勧告最終報告書「2017年9月、<https：// www.faa.gov/Regulations_policies/RuleMaking/Committes/文書/ media / UAS％20id％20arc％20final％20report％20％20appendices.pdf>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.
[RFC4122]リーチ、P.、Mealling、M.、R. Salz、「普遍的にユニークな識別子（UUID）URN名前空間」、RFC 4122、DOI 10.17487 / RFC4122、2005年7月、<https：///www.rfc-editor.org/info/rfc4122>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R.、 "Internet Security Glossary、バージョン2"、FYI 36、RFC 4949、DOI 10.17487 / RFC4949、2007年8月、<https：//www.rfc-editor.org/info/rfc4949>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E.およびN. ModAdugu、「データグラムトランスポート層セキュリティバージョン1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https：//www.rfc-editor.org/info/rfc6347>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M.、R. Smith、「インターネットプロトコルに関するプライバシーに関する考察」、RFC 6973、DOI2017487 / RFC6973、2013年7月、<https：//www.rfc-editor.org/info/rfc6973>。
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, <https://www.rfc-editor.org/info/rfc7401>.
[RFC7401] Moskowitz、R.、Ed。、Heer、T.、Jokela、P.、T. Henderson、「Host Identity Protocol Version 2（HIPv2）」、RFC 7401、DOI 10.17487 / RFC7401、2015年4月、<HTTPS//www.rfc-editor.org/info/rfc7401>。
[RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280, October 2017, <https://www.rfc-editor.org/info/rfc8280>.
[RFC8280] 10エバー、N.およびC Cath、「人権プロトコルに関する研究」、RFC 8280、DOI 10.17487 / RFC8280、2017年10月、<https：//www.rfc-editor.org/info/rfc8280>。
[RFC9063] Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021, <https://www.rfc-editor.org/info/rfc9063>.
[RFC9063] Moskowitz、R.、Ed。2021年7月、<https://www.rfc-editor.org/info/rfc9063>。
[Roadmap] ANSI Unmanned Aircraft Systems Standardization Collaborative (UASSC), "Standardization Roadmap for Unmanned Aircraft Systems", Working Draft, Version 2.0, April 2020, <https://share.ansi.org/Shared Documents/ Standards Activities/UASSC/ UASSC_20-001_WORKING_DRAFT_ANSI_UASSC_Roadmap_v2.pdf>.
[RoadMap] ANSI無人航空機システム標準化協調（UASSC）、「無人航空機システム用標準ロードマップ」、編集ドラフト、バージョン2.0、2020年4月、<https：//share.ansi.org/shared文書/標準アクティビティ/ UASSC /UASSC_20-001_WORKING_DRAFT_ANSI_UASSC_ROADMAP_V2.PDF>。
[Stranger] Heinlein, R., "Stranger in a Strange Land", June 1961.
[見知らぬ人] Heinlein、R.、「奇妙な土地の見知らぬ人」、1961年6月。
[WG105] EUROCAE, "Minimum Operational Performance Standards (MOPS) for Unmanned Aircraft System (UAS) Electronic Identification", WG-105 SG-32 draft ED-282, June 2020.
[WG105] Eurocae、「無人航空機システム（UAS）電子識別（UAS）電子識別のための最低運用性能基準（MOP）、WG-105 SG-32ドラフトED-282、2020年6月。
[WiFiNAN] Wi-Fi Alliance, "Wi-Fi Aware", October 2020, <https://www.wi-fi.org/discover-wi-fi/wi-fi-aware>.
[WiFinan] Wi-Fi Alliance、「Wi-Fi Aware」、2020年10月、<https：//www.wi-fi.org/discover-wi-fi/wi-fi-aware>。
This document is largely based on the process of one SDO -- ASTM. Therefore, it is tailored to specific needs and data formats of ASTM's "Standard Specification for Remote ID and Tracking" [F3411-19]. Other organizations (for example, in the EU) do not necessarily follow the same architecture.
この文書は主に1つのSDO - ASTMのプロセスに基づいています。したがって、ASTMの「リモートIDとトラッキングの標準仕様」[F3411-19]の特定のニーズとデータフォーマットに合わせて調整されています。他の組織（例えば、EU内）は必ずしも同じアーキテクチャに従うわけではありません。
The need for drone ID and operator privacy is an open discussion topic. For instance, in the ground vehicular domain, each car carries a publicly visible plate number. In some countries, for nominal cost or even for free, anyone can resolve the identity and contact information of the owner. Civil commercial aviation and maritime industries also have a tradition of broadcasting plane or ship ID, coordinates, and even flight plans in plaintext. Community networks such as OpenSky [OpenSky] and Flightradar24 [FR24] use this open information through ADS-B to deploy public services of flight tracking. Many researchers also use these data to perform optimization of routes and airport operations. Such ID information should be integrity protected, but not necessarily confidential.
ドローンIDとオペレータのプライバシーの必要性は、開いているディスカッショントピックです。例えば、地上車両ドメインでは、各車は公的に目に見える板数を運んでいます。一部の国では、名目費用または無料でさえ、誰でも所有者のアイデンティティと連絡先情報を解決できます。市民の商業航空および海事産業には、プレーンテキストの放送の伝統や船のID、座標、座標、さらにはフライトプランの伝統があります。OpenSky [OpenSky]やFlightradar24 [FR24]などのコミュニティネットワーク[FR24] ADS-Bを介してこのオープン情報を使用して、フライトトラッキングの公共サービスを展開してください。多くの研究者はまた、ルートと空港の操作の最適化を実行するためにこれらのデータを使用します。そのようなID情報は整合性保護されるべきであるが、必ずしも機密ではない。
In civil aviation, aircraft identity is broadcast by a device known as transponder. It transmits a four-octal digit squawk code, which is assigned by a traffic controller to an airplane after approving a flight plan. There are several reserved codes, such as 7600, that indicate radio communication failure. The codes are unique in each traffic area and can be re-assigned when entering another control area. The code is transmitted in plaintext by the transponder and also used for collision avoidance by a system known as Traffic alert and Collision Avoidance System (TCAS). The system could be used for UAS as well initially, but the code space is quite limited and likely to be exhausted soon. The number of UAS far exceeds the number of civil airplanes in operation.
民間航空では、航空機の身分証明はトランスポンダとして知られている装置によって放送されています。フライトプランを承認した後、トラフィックコントローラによって割り当てられている4桁の数字スコークコードを航空機に送信します。ラジオ通信の失敗を示す7600など、いくつかの予約コードがあります。コードは各トラフィック領域で固有のもので、別のコントロールエリアに入るときに再割り当てできます。コードはトランスポンダによって平文で送信され、また、トラフィックアラートと衝突回避システム（TCA）として知られるシステムによる衝突回避にも使用されます。システムは最初はUASに使用できますが、コードスペースはかなり制限されており、すぐに使い果たされる可能性があります。UASの数は、運用中の民間飛行機の数をはるかに超えています。
The ADS-B system is utilized in civil aviation for each "ADS-B Out" equipped airplane to broadcast its ID, coordinates, and altitude for other airplanes and ground control stations. If this system is adopted for drone IDs, it has additional benefit with backward compatibility with civil aviation infrastructure; then, pilots and dispatchers will be able to see UA on their control screens and take those into account. If not, a gateway translation system between the proposed drone ID and civil aviation system should be implemented. Again, system saturation due to large numbers of UAS is a concern.
ADS-Bシステムは、そのID、座標、および他の飛行機および地面制御ステーションのためのID、座標、および高度を放送するために、各「ADS-B OUT」搭乗航空機に民間航空に利用されています。このシステムがドローンIDに採用されている場合は、民間航空インフラストラクチャとの下位互換性を伴う追加の利益があります。それから、パイロットとディスパッチャは彼らのコントロールスクリーンでUAを見ることができ、それらを考慮に入れることができます。そうでなければ、提案されたドローンIDと民間航空システム間のゲートウェイ翻訳システムを実装する必要がある。繰り返しますが、大量のUASによるシステム飽和は懸念です。
The Mode S transponders used in all TCAS and most "ADS-B Out" installations are assigned an ICAO 24-bit "address" (arguably really an identifier rather than a locator) that is associated with the aircraft as part of its registration. In the US alone, well over 2^20 UAS are already flying; thus, a 24-bit space likely would be rapidly exhausted if used for UAS (other than large UAS flying in controlled airspace, especially internationally, under rules other than those governing small UAS at low altitudes).
すべてのTCASおよびほとんどの「ADS-B OUT」インストールで使用されているモードSトランスポンダには、登録の一部として航空機に関連付けられているICAO 24ビットの「アドレス」（LOCATERではなく実際には実際には識別子）が割り当てられています。アメリカだけでは、2 ^ 20 UASがすでに飛んでいます。したがって、24ビットのスペースは、UASに使用される場合（特に低いUASの低いUAS以外の規則の下で、特に国際的に、制御空間内の大きなUAS以外の大型UAS以外）、急速に排出されるであろう。
Wi-Fi and Bluetooth are two wireless technologies currently recommended by ASTM specifications due to their widespread use and broadcast nature. However, those have limited range (max 100s of meters) and may not reliably deliver UAS ID at high altitude or distance. Therefore, a study should be made of alternative technologies from the telecom domain (e.g., WiMAX / IEEE 802.16, 5G) or sensor networks (e.g., Sigfox, LoRa). Such transmission technologies can impose additional restrictions on packet sizes and frequency of transmissions but could provide better energy efficiency and range.
Wi-FiとBluetoothは、広範囲の使用とブロードキャストのために、現在ASTMの仕様が推奨されている2つのワイヤレステクノロジです。しかしながら、それらは限られた範囲（最大100代）を有し、そして高度または距離でUAS IDを確実に提供しない可能性がある。したがって、テレコムドメイン（例えば、WiMAX / IEEE 802.16,5G）またはセンサネットワーク（例えばSIGFOX、LORA）からの代替技術を検討する必要がある。そのような送信技術は、パケットサイズおよび送信頻度に追加の制限を課すことができ、より良いエネルギー効率および範囲を提供することができる。
In civil aviation, Controller-Pilot Data Link Communications (CPDLC) is used to transmit command and control between the pilots and ATC. It could be considered for UAS as well due to long-range and proven use despite its lack of security [CPDLC].
民間航空では、コントローラパイロットデータリンク通信（CPDLC）は、パイロットとATCの間のコマンドと制御を送信するために使用されます。セキュリティ不足にもかかわらず、長距離で実証済みの使用のために、UASのために考慮される可能性があります[CPDLC]。
L-band Digital Aeronautical Communications System (LDACS) is being standardized by ICAO and IETF for use in future civil aviation [LDACS]. LDACS provides secure communication, positioning, and control for aircraft using a dedicated radio band. It should be analyzed as a potential provider for UAS RID as well. This will bring the benefit of a global integrated system creating awareness of global airspace use.
Lバンドデジタル航空通信システム（LDACS）は、将来の民間航空[LDACS]で使用するためにICAOとIETFによって標準化されています。LDACSは、専用の無線帯域を使用して、航空機用の安全な通信、位置決め、および制御を提供します。それはUAS RIDのための潜在的なプロバイダとして分析されるべきです。これにより、グローバルな統合システムの利点がGlobal Airspaceの使用の認識を生み出します。
Acknowledgments
謝辞
The work of the FAA's UAS Identification and Tracking Aviation Rulemaking Committee (ARC) is the foundation of later ASTM [F3411-19] and IETF DRIP efforts. The work of Gabriel Cox, Intel Corp., and their Open Drone ID collaborators opened UAS RID to a wider community. The work of ASTM F38.02 in balancing the interests of diverse stakeholders is essential to the necessary rapid and widespread deployment of UAS RID. IETF volunteers who have extensively reviewed or otherwise contributed to this document include Amelia Andersdotter, Carsten Bormann, Toerless Eckert, Susan Hares, Mika Jarvenpaa, Alexandre Petrescu, Saulo Da Silva, and Shuai Zhao. Thanks to Linda Dunbar for the SECDIR review, Nagendra Nainar for the OPSDIR review, and Suresh Krishnan for the Gen-ART review. Thanks to IESG members Roman Danyliw, Erik Kline, Murray Kucherawy, and Robert Wilton for helpful and positive comments. Thanks to chairs Daniel Migault and Mohamed Boucadair for direction of our team of authors and editor, some of whom are newcomers to writing IETF documents. Thanks especially to Internet Area Director Éric Vyncke for guidance and support.
FAAのUAS識別と追跡航空ルーティング委員会（ARC）の作業は、後のASTM [F3411-19]とIETFの点滴努力の基盤です。 Gabriel Cox、Intel Corp.、およびそのオープンドローンIDコラボレータの作品は、UAS RIDを幅広いコミュニティに開放しました。多様な利害関係者の興味をバランスさせる際のASTM F38.02の作品は、UAS RIDの必要な迅速かつ広範な展開にとって不可欠です。この文書に広く審査されているか、そうでなければ貢献したIETFボランティアには、Amelia Andersdotter、Carsten Bormann、ToreLess Eckert、Susan Hares、Mika Jarvenpaa、Alexandre Petrescu、Saulo da Silva、Shuai Zhaoが含まれます。 Secdir Review、Opsdir ReviewのためのNagendra Nainar、およびGen-Art ReviewのためのSuresh Krishnanのためのリンダ・ダンバーのおかげで。 IESGのメンバーのDanyliw、Erik Kline、Murray Kucherawy、およびRobert Wiltonのおかげで、有用で好評のコメント。私たちの著者や編集者のチームの方向にDaniel MigauteとMohamed Boucadairを務めています。特にインターネットエリアディレクターの携帯電話の指導とサポートのためにありがとう。
This work was partly supported by the EU project AiRMOUR (enabling sustainable air mobility in urban contexts via emergency and medical services) under grant agreement no. 101006601.
この作品は、付与契約の下でEUプロジェクトAirmour（緊急および医療サービスを介した都市状況における持続可能な空気の移動を可能にする）によって部分的に支えられていました。101006601。
Authors' Addresses
著者の住所
Stuart W. Card (editor) AX Enterprize 4947 Commercial Drive Yorkville, NY 13495 United States of America
Stuart W. Card（編集）AX Enterprize 4947 Commercial Drive Yorkville、NY 13495アメリカ合衆国
Email: stu.card@axenterprize.com
Adam Wiethuechter AX Enterprize 4947 Commercial Drive Yorkville, NY 13495 United States of America
Adam Wiethuechter AX enterprize 4947 Commercial Drive Yorkville、NY 13495アメリカ合衆国
Email: adam.wiethuechter@axenterprize.com
Robert Moskowitz HTT Consulting Oak Park, MI 48237 United States of America
Robert Moskowitz Htt Consulting Oak Park、MI 48237アメリカ合衆国
Email: rgm@labs.htt-consult.com
Andrei Gurtov Linköping University IDA SE-58183 Linköping Sweden
Andrei GurtovLinköpingUniversity IDA SE-58183Linköpingスウェーデン
Email: gurtov@acm.org