[要約] RFC 9450は、有線の決定論的ネットワークと同様の性質を無線ネットワークで実現するための課題を示し、航空通信、産業用途、エッジロボティクスなどの無線利用事例における信頼性と利用可能性を要求している。
Internet Engineering Task Force (IETF) CJ. Bernardos, Ed.
Request for Comments: 9450 UC3M
Category: Informational G. Papadopoulos
ISSN: 2070-1721 IMT Atlantique
P. Thubert
Cisco
F. Theoleyre
CNRS
August 2023
The wireless medium presents significant specific challenges to achieve properties similar to those of wired deterministic networks. At the same time, a number of use cases cannot be solved with wires and justify the extra effort of going wireless. This document presents wireless use cases (such as aeronautical communications, amusement parks, industrial applications, pro audio and video, gaming, Unmanned Aerial Vehicle (UAV) and vehicle-to-vehicle (V2V) control, edge robotics, and emergency vehicles), demanding reliable and available behavior.
ワイヤレス媒体は、有線の決定論的ネットワークの特性と同様の特性を達成するための重要な特定の課題を提示します。同時に、多くのユースケースをワイヤで解決することはできず、ワイヤレスになるという余分な努力を正当化することはできません。このドキュメントでは、ワイヤレスユースケース（航空通信、遊園地、産業用途、プロオーディオとビデオ、ゲーム、無人航空機（UAV）、車両から車両への制御、エッジロボット工学、緊急車両）など）など、信頼性の高い利用可能な行動を要求します。
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/rfc9450.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9450で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Aeronautical Communications
2.1. Problem Statement
2.2. Specifics
2.3. Challenges
2.4. The Need for Wireless
2.5. Requirements for RAW
2.5.1. Non-latency-critical Considerations
3. Amusement Parks
3.1. Use Case Description
3.2. Specifics
3.3. The Need for Wireless
3.4. Requirements for RAW
3.4.1. Non-latency-critical Considerations
4. Wireless for Industrial Applications
4.1. Use Case Description
4.2. Specifics
4.2.1. Control Loops
4.2.2. Monitoring and Diagnostics
4.3. The Need for Wireless
4.4. Requirements for RAW
4.4.1. Non-latency-critical Considerations
5. Professional Audio and Video
5.1. Use Case Description
5.2. Specifics
5.2.1. Uninterrupted Stream Playback
5.2.2. Synchronized Stream Playback
5.3. The Need for Wireless
5.4. Requirements for RAW
5.4.1. Non-latency-critical Considerations
6. Wireless Gaming
6.1. Use Case Description
6.2. Specifics
6.3. The Need for Wireless
6.4. Requirements for RAW
6.4.1. Non-latency-critical Considerations
7. Unmanned Aerial Vehicles and Vehicle-to-Vehicle Platooning and
Control
7.1. Use Case Description
7.2. Specifics
7.3. The Need for Wireless
7.4. Requirements for RAW
7.4.1. Non-latency-critical Considerations
8. Edge Robotics Control
8.1. Use Case Description
8.2. Specifics
8.3. The Need for Wireless
8.4. Requirements for RAW
8.4.1. Non-latency-critical Considerations
9. Instrumented Emergency Medical Vehicles
9.1. Use Case Description
9.2. Specifics
9.3. The Need for Wireless
9.4. Requirements for RAW
9.4.1. Non-latency-critical Considerations
10. Summary
11. IANA Considerations
12. Security Considerations
13. Informative References
Acknowledgments
Authors' Addresses
Based on time, resource reservation, and policy enforcement by distributed shapers [RFC2475], Deterministic Networking (DetNet) provides the capability to carry specified unicast or multicast data streams for real-time applications with extremely low data loss rates and bounded latency so as to support time-sensitive and mission-critical applications on a converged enterprise infrastructure.
時間、リソースの予約、分散シェイパー[RFC2475]によるポリシー施行に基づいて、決定論的ネットワーキング（DETNET）は、非常に低いデータ損失率と境界レイテンシを持つリアルタイムアプリケーション用に指定されたユニキャストまたはマルチキャストデータストリームを運ぶ機能を提供します。収束したエンタープライズインフラストラクチャでの時間に敏感でミッションクリティカルなアプリケーションをサポートします。
DetNet aims at eliminating packet loss for a committed bandwidth, while ensuring a worst-case end-to-end latency, regardless of the network conditions and across technologies. By leveraging lower layer (Layer 2 (L2) and below) capabilities, Layer 3 (L3) can exploit the use of a service layer, steering over multiple technologies and using media independent signaling to provide high reliability, precise time delivery, and rate enforcement. DetNet can be seen as a set of new Quality of Service (QoS) guarantees of worst-case delivery. IP networks become more deterministic when the effects of statistical multiplexing (jitter and collision loss) are mostly eliminated. This requires a tight control of the physical resources to maintain the amount of traffic within the physical capabilities of the underlying technology, e.g., by using time-shared resources (bandwidth and buffers) per circuit, by shaping or scheduling the packets at every hop, or by using a combination of these techniques.
DetNetは、ネットワーク条件やテクノロジー全体に関係なく、最悪のエンドツーエンドのレイテンシを確保しながら、コミットされた帯域幅のパケット損失を排除することを目的としています。下層（レイヤー2（L2）および下）機能を活用することにより、レイヤー3（L3）は、サービスレイヤーの使用を活用し、複数のテクノロジーを操縦し、メディアに依存しないシグナル伝達を使用して、高い信頼性、正確な時間配信、レートの施行を提供することができます。。Detnetは、最悪のケース配信の新しい品質（QOS）保証のセットと見なすことができます。IPネットワークは、統計的多重化（ジッターと衝突損失）の影響がほとんど排除されると、より決定的になります。これには、すべてのホップでパケットを形成またはスケジュールすることにより、回路ごとに時間共有リソース（帯域幅とバッファー）を使用することにより、基礎となるテクノロジーの物理的能力内のトラフィックの量を維持するための物理リソースの厳しい制御が必要です。または、これらの手法の組み合わせを使用します。
Key attributes of DetNet include:
DETNETの重要な属性は次のとおりです。
* time synchronization on all the nodes,
* すべてのノードの時間同期、
* multi-technology path with co-channel interference minimization,
* 共チャネル干渉の最小化を備えたマルチテクノロジーパス、
* frame preemption and guard time mechanisms to ensure a worst-case delay, and
* 最悪の遅延を確保するためのフレームプリエンプションとガードタイムメカニズム、および
* new traffic shapers, both within and at the edge, to protect the network.
* ネットワークを保護するために、端の内外の両方の新しいトラフィックシェイパー。
Wireless operates on a shared medium, and transmissions cannot be guaranteed to be fully deterministic due to uncontrolled interferences, including self-induced multipath fading. The term RAW stands for "Reliable and Available Wireless" and refers to the mechanisms aimed for providing high reliability and availability for IP connectivity over a wireless medium. Making wireless reliable and available is even more challenging than it is with wires, due to the numerous causes of loss in transmission that add up to the congestion losses and due to the delays caused by overbooked shared resources.
ワイヤレスは共有媒体で動作し、自己誘発マルチパスフェードを含む制御されていない干渉のために、送信が完全に決定的であることを保証することはできません。RAWという用語は、「信頼性の高い利用可能なワイヤレス」の略であり、ワイヤレスメディア上のIP接続の高い信頼性と可用性を提供することを目的としたメカニズムを指します。ワイヤレスを信頼性と利用可能にすることは、渋滞の損失につながるトランスミッションの損失の多くの原因と、オーバーブッキングされた共有リソースによって引き起こされる遅延により、ワイヤよりもさらに困難です。
The wireless and wired media are fundamentally different at the physical level. While the generic Problem Statement in [RFC8557] for DetNet applies to the wired as well as the wireless medium, the methods to achieve RAW necessarily differ from those used to support Time-Sensitive Networking over wires, e.g., due to the wireless radio channel specifics.
ワイヤレスメディアと有線メディアは、物理レベルで根本的に異なります。Detnetの[RFC8557]の一般的な問題ステートメントは有線およびワイヤレス媒体に適用されますが、RAWを達成する方法は、ワイヤレスラジオチャネルの仕様により、ワイヤを介した時間に敏感なネットワーキングをサポートするために使用されるものと必然的に異なります。。
So far, open standards for DetNet have prevalently been focused on wired media, with Audio Video Bridging (AVB) and Time-Sensitive Networking (TSN) at the IEEE and DetNet [RFC8655] at the IETF. However, wires cannot be used in several cases, including mobile or rotating devices, rehabilitated industrial buildings, wearable or in-body sensory devices, vehicle automation, and multiplayer gaming.
これまでのところ、Detnetのオープンスタンダードは、IEEEおよびIETFのIEEEおよびDetnet [RFC8655]でオーディオビデオブリッジング（AVB）と時間依存ネットワーキング（TSN）を使用して、有線メディアに焦点を当てています。ただし、モバイルや回転装置、リハビリされた工業用建物、ウェアラブルまたはボディ内の感覚デバイス、車両の自動化、マルチプレイヤーゲームなど、いくつかのケースでは、ワイヤーを使用することはできません。
Purpose-built wireless technologies such as [ISA100], which incorporates IPv6, were developed and deployed to cope with the lack of open standards, but they yield a high cost in Operational Expenditure (OPEX) and Capital Expenditure (CAPEX) and are limited to very few industries, e.g., process control, concert instruments, or racing.
IPv6を組み込んだ[ISA100]などの専用ワイヤレステクノロジーは、オープン基準の欠如に対処するために開発および展開されましたが、運用支出（OPEX）と資本支出（CAPEX）のコストが高く、制限されています。たとえば、プロセス制御、コンサート楽器、レースなど、産業はほとんどありません。
This is now changing (as detailed in [RAW-TECHNOS]):
これは現在変化しています（[Raw-Technos]で詳述されています）：
* IMT-2020 has recognized Ultra-Reliable Low Latency Communication (URLLC) as a key functionality for the upcoming 5G.
* IMT-2020は、今後の5Gの重要な機能として、超信頼性の低い低レイテンシ通信（URLLC）を認識しています。
* IEEE 802.11 has identified a set of real applications [IEEE80211RTA], which may use the IEEE802.11 standards. They typically emphasize strict end-to-end delay requirements.
* IEEE 802.11は、IEEE802.11標準を使用する可能性のある一連の実際のアプリケーション[IEEE80211RTA]を特定しました。彼らは通常、厳密なエンドツーエンド遅延要件を強調します。
* The IETF has produced an IPv6 stack for IEEE Std. 802.15.4 Time-Slotted Channel Hopping (TSCH) and an architecture [RFC9030] that enables RAW on a shared MAC.
* IETFは、IEEE STD用のIPv6スタックを作成しました。802.15.4時間スロット付きチャネルホッピング（TSCH）と共有MACのRAWを可能にするアーキテクチャ[RFC9030]。
Experiments have already been conducted with IEEE802.1 TSN over IEEE802.11be [IEEE80211BE]. This mode enables time synchronization and time-aware scheduling (trigger based access mode) to support TSN flows.
IEEE802.11BE [IEEE80211BE]を介してIEEE802.1 TSNを使用して実験が既に実施されています。このモードにより、TSNフローをサポートするための時間同期と時間認識スケジューリング（トリガーベースのアクセスモード）が可能になります。
This document extends the "Deterministic Networking Use Cases" document [RFC8578] and describes several additional use cases that require "reliable/predictable and available" flows over wireless links and possibly complex multi-hop paths called "Tracks". This is covered mainly by the "Wireless for Industrial Applications" (Section 5 of [RFC8578]) use case, as the "Cellular Radio" (Section 6 of [RFC8578]) is mostly dedicated to the (wired) link part of a Radio Access Network (RAN). Whereas, while the "Wireless for Industrial Applications" use case certainly covers an area of interest for RAW, it is limited to IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH), and thus, its scope is narrower than the use cases described next in this document.
このドキュメントは、「決定論的ネットワークユースケース」ドキュメント[RFC8578]を拡張し、ワイヤレスリンクと「トラック」と呼ばれる複雑なマルチホップパスを介して「信頼できる/予測可能で利用可能な」フローを必要とするいくつかの追加のユースケースを説明します。これは、主に「産業用途向けのワイヤレス」（[RFC8578]のセクション5）ユースケースでカバーされています。アクセスネットワーク（RAN）。一方、「産業用アプリケーションのワイヤレス」のユースケースは確かにRAWの関心分野をカバーしていますが、IEEE 802.15.4E（6tisch）のTSCHモードでIPv6に限定されているため、その範囲はユースケースよりも狭くなります。このドキュメントで次に説明します。
Aircraft are currently connected to Air-Traffic Control (ATC) and Airline Operational Control (AOC) via voice and data communication systems through all phases of a flight. Within the airport terminal, connectivity is focused on high-bandwidth communications, whereas en route it's focused on high reliability, robustness, and range.
航空機は現在、飛行のすべての段階を介して音声通信システムとデータ通信システムを介して、航空輸送制御（ATC）および航空会社の運用制御（AOC）に接続されています。空港ターミナル内では、接続性は高帯域幅通信に焦点を当てていますが、途中で高い信頼性、堅牢性、範囲に焦点を当てています。
Up to 2020, civil air traffic had been growing constantly at a compound rate of 5.8% per year [ACI19], and despite the severe impact of the COVID-19 pandemic, air-traffic growth is expected to resume very quickly in post-pandemic times [IAT20] [IAC20]. Thus, legacy systems in Air-Traffic Management (ATM) are likely to reach their capacity limits, and the need for new aeronautical communication technologies becomes apparent. Especially problematic is the saturation of VHF band in high density areas in Europe, the US, and Asia [SESAR] [FAA20], calling for suitable new digital approaches such as the Aeronautical Mobile Airport Communications System (AeroMACS) for airport communications, SatCOM for remote domains, and the L-band Digital Aeronautical Communication System (LDACS) as the long-range terrestrial aeronautical communication system. Making the frequency spectrum's usage a more efficient transition from analog voice to digital data communication [PLA14] is necessary to cope with the expected growth of civil aviation and its supporting infrastructure. A promising candidate for long-range terrestrial communications, already in the process of being standardized in the International Civil Aviation Organization (ICAO), is LDACS [ICAO2022] [RFC9372].
2020年まで、民間航空交通は年間5.8％の複合速度で絶えず成長していました[ACI19]。Times [IAT20] [IAC20]。したがって、航空交通管理（ATM）のレガシーシステムは容量制限に達する可能性が高く、新しい航空通信技術の必要性が明らかになります。特に問題のあることは、ヨーロッパ、米国、アジア[SESAR] [FAA20]の高密度地域におけるVHFバンドの飽和であり、空港通信のための航空モバイル空港通信システム（Aeromacs）などの適切な新しいデジタルアプローチを求めています。リモートドメイン、および長距離の陸生通信システムとしてのLバンドデジタル航空通信システム（LDACS）。周波数スペクトルの使用法をアナログ音声からデジタルデータ通信[PLA14]へのより効率的な移行にすることは、民間航空の予想される成長とその支援インフラストラクチャに対処するために必要です。すでに国際民間航空機関（ICAO）で標準化されている長期陸生コミュニケーションの有望な候補者は、LDACS [ICAO2022] [RFC9372]です。
Note that the large scale of the planned Low Earth Orbit (LEO) constellations of satellites can provide fast end-to-end latency rates and high data-rates at a reasonable cost, but they also pose challenges, such as frequent handovers, high interference, and a diverse range of system users, which can create security issues since both safety-critical and not safety-critical communications can take place on the same system. Some studies suggest that LEO constellations could be a complete solution for aeronautical communications, but they do not offer solutions for the critical issues mentioned earlier. Additionally, of the three communication domains defined by ICAO, only passenger entertainment services can currently be provided using these constellations. Safety-critical aeronautical communications require reliability levels above 99.999%, which is higher than that required for regular commercial data links. Therefore, addressing the issues with LEO-based SatCOM is necessary before these solutions can reliably support safety-critical data transmission [Maurer2022].
衛星の計画された低地球軌道（LEO）の星座の大規模は、適切なコストで速いエンドツーエンドのレイテンシレートと高いデータレートを提供できるが、頻繁な手見船、高い干渉などの課題ももたらすことに注意してください。、およびさまざまな範囲のシステムユーザー。安全性が批判的ではなく、安全性が批判的な通信の両方が同じシステムで行われるため、セキュリティの問題を作成できます。いくつかの研究は、レオ星座が航空通信の完全な解決策である可能性があることを示唆していますが、前述の重要な問題に対する解決策を提供していません。さらに、ICAOによって定義された3つの通信ドメインのうち、現在、これらの星座を使用して乗客エンターテイメントサービスのみが提供できます。安全性が批判的な航空通信には、99.999％を超える信頼性レベルが必要です。これは、通常のコマーシャルデータリンクに必要なものよりも高いです。したがって、LEOベースのSATCOMの問題に対処することは、これらのソリューションが安全性の高いデータ送信を確実にサポートできるようにする前に必要です[MAURER2022]。
During the creation process of a new communication system, analog voice is replaced by digital data communication. This sets a paradigm shift from analog to digital wireless communications and supports the related trend towards increased autonomous data processing that the Future Communications Infrastructure (FCI) in civil aviation must provide. The FCI is depicted in Figure 1:
新しい通信システムの作成プロセス中、アナログ音声はデジタルデータ通信に置き換えられます。これにより、アナログからデジタルワイヤレス通信へのパラダイムシフトが設定され、民間航空の将来の通信インフラストラクチャ（FCI）が提供する自律データ処理の増加に向けた関連する傾向をサポートします。FCIを図1に示します。
Satellite
# #
# # #
# # #
# # #
# # #
# # #
# # #
# Satellite-based # #
# Communications # #
# SatCOM (#) # #
# # Aircraft
# # % %
# # % %
# # % Air-Air %
# # % Communications %
# # % LDACS A/A (%) %
# # % %
# Aircraft % % % % % % % % % % Aircraft
# | Air-Ground |
# | Communications |
# | LDACS A/G (|) |
# Communications in | |
# and around airports | |
# AeroMACS (-) | |
# | |
# Aircraft-------------+ | |
# | | |
# | | |
# Ground network | | Ground network |
SatCOM <---------------------> Airport <----------------------> LDACS
ground ground ground
transceiver transceiver transceiver
Figure 1: The Future Communication Infrastructure (FCI)
図1：将来の通信インフラストラクチャ（FCI）
FCI includes:
FCIは次のとおりです。
* AeroMACS for airport and terminal maneuvering area domains,
* 空港およびターミナル操縦エリアドメイン用の航空、
* LDACS Air/Ground for terminal maneuvering area and en route domains,
* ターミナル操縦エリアと途中のドメインのLDACSエア/グランド、
* LDACS Air/Ground for en route or oceanic, remote, and polar regions, and
* 途中または海洋、遠隔、極地の領域のためのLDACS空気/地面、および
* SatCOM for oceanic, remote, and polar regions.
* 海洋、リモート、極地のSATCOM。
This paradigm change brings a lot of new challenges:
このパラダイムの変更は、多くの新しい課題をもたらします。
* Efficiency: It is necessary to keep latency, time, and data overhead of new aeronautical data links to a minimum.
* 効率：新しい航空データリンクの遅延、時間、およびデータオーバーヘッドを最小限に抑える必要があります。
* Modularity: Systems in avionics usually operate for up to 30 years. Thus, solutions must be modular, easily adaptable, and updatable.
* モジュール性：アビオニクスのシステムは通常、最大30年間動作します。したがって、ソリューションはモジュール式で、簡単に順応性があり、更新可能でなければなりません。
* Interoperability: All 192 members of the ICAO must be able to use these solutions.
* 相互運用性：ICAOの192人のメンバー全員がこれらのソリューションを使用できる必要があります。
* Dynamicity: The communication infrastructure needs to accommodate mobile devices (airplanes) that move extremely fast.
* ダイナミティ：通信インフラストラクチャは、非常に速く移動するモバイルデバイス（飛行機）に対応する必要があります。
In a high-mobility environment, such as aviation, the envisioned solutions to provide worldwide coverage of data connections with in-flight aircraft require a multi-system, multi-link, multi-hop approach. Thus, air, ground, and space-based data links that provide these technologies will have to operate seamlessly together to cope with the increasing needs of data exchange between aircraft, air-traffic controller, airport infrastructure, airlines, air network service providers (ANSPs), and so forth. Wireless technologies have to be used to tackle this enormous need for a worldwide digital aeronautical data link infrastructure.
航空などの高モビリティ環境では、飛行中の航空機とのデータ接続の世界的なカバレッジを提供する想定されているソリューションには、マルチシステム、マルチリンク、マルチホップアプローチが必要です。したがって、これらのテクノロジーを提供する空気、地面、および宇宙ベースのデータリンクは、航空機、航空輸送コントローラー、空港インフラ、航空会社、航空ネットワークサービスプロバイダー間のデータ交換の増加するニーズに対処するためにシームレスに操作する必要があります（ANSPS）、その他。ワイヤレステクノロジーは、世界的なデジタル航空データリンクインフラストラクチャに対するこの大きなニーズに取り組むために使用する必要があります。
Different safety levels need to be supported. All network traffic handled by the Airborne Internet Protocol Suite (IPS) System are not equal, and the QoS requirements of each network traffic flow must be considered n order to avoid having to support QoS requirements at the granularity of data flows. These flows are grouped into classes that have similar requirements, following the Diffserv approach [ARINC858P1]. These classes are referred to as Classes of Service (CoS), and the flows within a class are treated uniformly from a QoS perspective. Currently, there are at least eight different priority levels (CoS) that can be assigned to packets. For example, a high-priority message requiring low latency and high resiliency could be a "WAKE" warning indicating two aircraft are dangerously close to each other, while a less safety-critical message with low-to-medium latency requirements could be the "WXGRAPH" service providing graphical weather data.
さまざまな安全レベルをサポートする必要があります。Airborne Internet Protocol Suite（IPS）システムによって処理されるすべてのネットワークトラフィックは等しくなく、各ネットワークトラフィックフローのQoS要件は、データフローの粒度でQoS要件をサポートする必要がないようにして、N順序を考慮する必要があります。これらのフローは、diffservアプローチ[ARINC858P1]に従って、同様の要件を持つクラスにグループ化されます。これらのクラスはサービスのクラス（COS）と呼ばれ、クラス内のフローはQoSの観点から均一に扱われます。現在、パケットに割り当てることができる少なくとも8つの異なる優先レベル（cos）があります。たとえば、低遅延と高い回復力を必要とする高優先度メッセージは、2つの航空機が互いに危険なほど近くにあることを示す「ウェイク」警告である可能性がありますが、低から中程度のレイテンシの要件を持つ安全性が低いメッセージは「」である可能性があります。グラフィカルな気象データを提供するwxgraph "サービス。
Overhead needs to be kept to a minimum since aeronautical data links provide comparatively small data rates on the order of kbit/s.
航空データリンクはKBIT/sのオーダーで比較的小さなデータレートを提供するため、オーバーヘッドを最小限に抑える必要があります。
Policy needs to be supported when selecting data links. The focus of RAW here should be on the selectors that are responsible for the track a packet takes to reach its end destination. This would minimize the amount of routing information that must travel inside the network because of precomputed routing tables, with the selector being responsible for choosing the most appropriate option according to policy and safety.
データリンクを選択する際には、ポリシーをサポートする必要があります。ここでのRAWの焦点は、パケットがエンドの目的地に到達するために取るトラックの原因となるセレクターにあるべきです。これにより、事前に計算されたルーティングテーブルのためにネットワーク内を移動する必要があるルーティング情報の量が最小限に抑えられ、セレクターはポリシーと安全に応じて最も適切なオプションを選択する責任があります。
Achieving low latency is a requirement for aeronautics communications, though the expected latency is not extremely low, and what is important is to keep the overall latency bounded under a certain threshold. Low latency in LDACS communications [RFC9372] translates to a latency in the Forward Link (FL - Ground -> Air) of 30-90 ms and a latency in the Reverse Link (RL - Air -> Ground) of 60-120 ms. This use case is not latency critical from that view point. On the other hand, given the controlled environment, end-to-end mechanisms can be applied to guarantee bounded latency where needed.
低遅延を達成することは、航空通信の要件ですが、予想される遅延は極端に低くはありません。重要なのは、全体的なレイテンシーを特定のしきい値で囲むことです。LDACS通信[RFC9372]の低レイテンシーは、30〜90ミリ秒のフォワードリンク（fl-グラウンド - >空気）のレイテンシと、60〜120 msのリバースリンク（RL -Air->グランド）のレイテンシに変換されます。このユースケースは、その観点からは遅延が重要ではありません。一方、制御された環境を考えると、エンドツーエンドのメカニズムを適用して、必要に応じて境界潜時を保証できます。
The digitalization of amusement parks is expected to significantly decrease the cost for maintaining the attractions. Such deployment is a mix between multimedia (e.g., Virtual and Augmented Reality and interactive video environments) and non-multimedia applications (e.g, access control, industrial automation for a roller coaster).
アミューズメントパークのデジタル化は、アトラクションを維持するためのコストを大幅に削減すると予想されます。このような展開は、マルチメディア（仮想および拡張現実とインタラクティブなビデオ環境など）と非マルチメディアアプリケーション（例えば、アクセス制御、ジェットコースター用の産業自動化など）の間の組み合わせです。
Attractions may rely on a large set of sensors and actuators, which react in real time. Typical applications comprise:
アトラクションは、リアルタイムで反応するセンサーとアクチュエーターの大規模なセットに依存する場合があります。典型的なアプリケーションは次のとおりです。
* Emergency: the safety of the operators and visitors has to be preserved, and the attraction must be stopped appropriately when a failure is detected.
* 緊急事態：オペレーターと訪問者の安全性を保存する必要があり、失敗が検出されたときに魅力を適切に停止する必要があります。
* Video: augmented and virtual realities are integrated in the attraction. Wearable mobile devices (e.g., glasses and virtual reality headsets) need to offload one part of the processing tasks.
* ビデオ：拡張および仮想現実は、アトラクションに統合されています。ウェアラブルモバイルデバイス（メガネや仮想現実ヘッドセットなど）は、処理タスクの一部をオフロードする必要があります。
* Real-time interactions: visitors may interact with an attraction, like in a real-time video game. The visitors may virtually interact with their environment, triggering actions in the real world (through actuators) [KOB12].
* リアルタイムのインタラクション：訪問者は、リアルタイムビデオゲームのように、アトラクションと対話する場合があります。訪問者は、実質的に環境と相互作用し、現実の世界（アクチュエーターを介して）で行動を引き起こす可能性があります[KOB12]。
* Geolocation: visitors are tracked with a personal wireless tag, so that their user experience is improved. This requires special care to ensure that visitors' privacy is not breached, and users are anonymously tracked.
* ジオロケーション：訪問者は個人のワイヤレスタグで追跡されるため、ユーザーエクスペリエンスが向上します。これには、訪問者のプライバシーが侵害されず、ユーザーが匿名で追跡されるようにするために特別な注意が必要です。
* Predictive maintenance: statistics are collected to predict the future failures or to compute later more complex statistics about the attraction's usage, the downtime, etc.
* 予測メンテナンス：統計が収集され、将来の障害を予測したり、アトラクションの使用状況、ダウンタイムなどに関するより複雑な統計を計算したりします。
* Marketing: to improve the customer experience, owners may collect a large amount of data to understand the behavior and the choices of their clients.
* マーケティング：カスタマーエクスペリエンスを改善するために、所有者は大量のデータを収集して、クライアントの行動と選択を理解することができます。
Amusement parks comprise a variable number of attractions, mostly outdoor, over a large geographical area. The IT infrastructure is typically multiscale:
アミューズメントパークは、大きな地理的エリアにわたって、ほとんどが屋外でさまざまな数のアトラクションで構成されています。ITインフラストラクチャは通常、マルチスケールです。
* Local area: The sensors and actuators controlling the attractions are colocated. Control loops trigger only local traffic, with a small end-to-end delay, typically less than 10 ms, like classical industrial systems [IEEE80211RTA].
* ローカルエリア：アトラクションを制御するセンサーとアクチュエーターがコロッキングされています。制御ループは、古典的な産業システム[IEEE80211RTA]のように、通常は10ミリ秒未満で、エンドツーエンドの遅延がわずかなローカルトラフィックのみをトリガーします。
* Wearable devices: Wearable mobile devices are free to move in the park. They exchange traffic locally (identification, personalization, multimedia) or globally (billing, child-tracking).
* ウェアラブルデバイス：ウェアラブルモバイルデバイスは公園に自由に移動できます。トラフィックをローカルで交換します（識別、パーソナライズ、マルチメディア）またはグローバル（請求、児童追跡）。
* Edge computing: Computationally intensive applications offload some tasks. Edge computing seems to be an efficient way to implement real-time applications with offloading. Some non-time-critical tasks may rather use the cloud (predictive maintenance, marketing).
* エッジコンピューティング：いくつかのタスクをオフロードする計算集中的なアプリケーション。エッジコンピューティングは、オフロードでリアルタイムアプリケーションを実装する効率的な方法のようです。一部の非時間的なタスクでは、クラウド（予測メンテナンス、マーケティング）を使用する場合があります。
Removing cables helps to easily change the configuration of the attractions or upgrade parts of them at a lower cost. The attraction can be designed modularly and can upgrade or insert novel modules later on in the life cycle of the attraction. Novelty of attractions tends to increase the attractiveness of an amusement park, encouraging previous visitors to regularly visit the park.
ケーブルの削除は、アトラクションの構成を簡単に変更したり、低コストでアトラクションの部分をアップグレードしたりするのに役立ちます。アトラクションはモジュール式に設計でき、アトラクションのライフサイクルで後で新しいモジュールをアップグレードまたは挿入できます。アトラクションの斬新さは、娯楽公園の魅力を高める傾向があり、以前の訪問者が定期的に公園を訪れることを奨励しています。
Some parts of the attraction are mobile, like trucks of a roller-coaster or robots. Since cables are prone to frequent failures in this situation, wireless transmissions are recommended.
アトラクションの一部は、ローラーコースターやロボットのトラックのようにモバイルです。この状況ではケーブルが頻繁に故障する傾向があるため、ワイヤレス送信が推奨されます。
Wearable devices are extensively used for a user experience personalization. They typically need to support wireless transmissions. Personal tags may help to reduce the operating costs [DISNEY15] and increase the number of charged services provided to the audience (e.g., VIP tickets or interactivity). Some applications rely on more sophisticated wearable devices, such as digital glasses or Virtual Reality (VR) headsets for an immersive experience.
ウェアラブルデバイスは、ユーザーエクスペリエンスのパーソナライズに広く使用されています。通常、ワイヤレス送信をサポートする必要があります。個人のタグは、運用コストを削減し[Disney15]、視聴者に提供される充電されたサービスの数（たとえば、VIPチケットやインタラクティブ性）を増やすのに役立ちます。一部のアプリケーションは、デジタルグラスや仮想現実（VR）ヘッドセットなど、より洗練されたウェアラブルデバイスに依存しており、没入型の体験をしています。
The network infrastructure must support heterogeneous traffic, with very different critical requirements. Thus, flow isolation must be provided.
ネットワークインフラストラクチャは、非常に異なる重要な要件を持つ不均一なトラフィックをサポートする必要があります。したがって、フロー分離を提供する必要があります。
The transmissions must be scheduled appropriately, even in the presence of mobile devices. While [RFC9030] already proposes an architecture for synchronized, IEEE Std. 802.15.4 Time-Slotted Channel Hopping (TSCH) networks, the industry requires a multi-technology solution that is able to guarantee end-to-end requirements across heterogeneous technologies with strict Service Level Agreement (SLA) requirements.
モバイルデバイスが存在する場合でも、送信は適切にスケジュールする必要があります。[RFC9030]はすでに同期したアーキテクチャを提案していますが、IEEE STD。802.15.4時間スロットされたチャネルホッピング（TSCH）ネットワークでは、業界には、厳格なサービスレベル契約（SLA）要件を備えた不均一なテクノロジー全体でエンドツーエンドの要件を保証できるマルチテクノロジーソリューションが必要です。
Nowadays, long-range wireless transmissions are used mostly for best-effort traffic. On the contrary, [IEEE802.1AS] is used for critical flows using Ethernet devices. However, we need an IP-enabled technology to interconnect large areas, independent of the Physical (PHY) and Medium Access Control (MAC) layers.
現在、長距離ワイヤレストランスミッションは、主にベストエフォルトトラフィックに使用されています。それどころか、[IEEE802.1AS]は、イーサネットデバイスを使用した重要なフローに使用されます。ただし、物理（PHY）および中アクセス制御（MAC）層とは無関係に、大きな領域を相互接続するためのIP対応テクノロジーが必要です。
It is expected that several different technologies (long vs. short range) are deployed, which have to cohabit the same area. Thus, we need to provide L3 mechanisms able to exploit multiple co-interfering technologies (i.e., different radio technologies using overlapping spectrum, and therefore, potentially interfering with each other).
いくつかの異なるテクノロジー（長距離対短距離）が展開され、同じエリアを同居する必要があると予想されます。したがって、複数の共同介入技術を活用できるL3メカニズムを提供する必要があります（つまり、重複するスペクトルを使用して、互いに潜在的に干渉する可能性があります）。
It is worth noting that low-priority flows (e.g., predictive maintenance, marketing) are delay tolerant; a few minutes or even hours would be acceptable. While classical unscheduled wireless networks already accommodate best-effort traffic, this would force several colocated and subefficient deployments. Unused resources could rather be used for low-priority flows. Indeed, allocated resources are consuming energy in most scheduled networks, even if no traffic is transmitted.
低優先順位（予測メンテナンス、マーケティングなど）が遅延許容範囲であることは注目に値します。数分または時間さえ許容されるでしょう。古典的な予定外のワイヤレスネットワークはすでに最高のエフォルトトラフィックに対応していますが、これにより、いくつかのコロッケージおよびサブ効率の展開が強制されます。未使用のリソースは、むしろ優先順位のフローに使用できます。実際、割り当てられたリソースは、トラフィックが送信されなくても、ほとんどのスケジュールされたネットワークでエネルギーを消費しています。
While some of the applications in this use case involve control loops (e.g., sensors and actuators) that require bounded latencies below 10 ms that can therefore be considered latency critical, there are other applications as well that mostly demand reliability (e.g., safety-related or maintenance).
このユースケースのいくつかのアプリケーションには、10ミリ秒未満の潜在的なレイテンシーを必要とする制御ループ（センサーやアクチュエーターなど）が含まれますが、レイテンシーが重要であると見なすことができますが、主に信頼性を要求する他のアプリケーションもあります（例えば、安全関連またはメンテナンス）。
A major use case for networking in industrial environments is the control networks where periodic control loops operate between a collection of sensors that measure a physical property (such as the temperature of a fluid), a Programmable Logic Controller (PLC) that decides on an action (such as "warm up the mix"), and actuators that perform the required action (such as the injection of power in a resistor).
産業環境でのネットワーキングのための主要なユースケースは、アクションを決定するプログラム可能なロジックコントローラー（PLC）である物理的プロパティ（流体の温度など）を測定するセンサーのコレクション間で定期的な制御ループが動作する制御ネットワークです。（「ミックスをウォームアップ」など）、および必要なアクションを実行するアクチュエーター（抵抗器内の電力の注入など）。
Process Control designates continuous processing operations, like heating oil in a refinery or mixing up soda. Control loops in the Process Control industry operate at a very low rate, typically four times per second. Factory Automation, on the other hand, deals with discrete goods, such as individual automobile parts, and requires faster loops, to the rate of milliseconds. Motion control that monitors dynamic activities may require even faster rates on the order of and below the millisecond.
プロセス制御は、製油所でオイルを加熱したり、ソーダを混合したりするなど、継続的な処理操作を指定します。プロセス制御業界の制御ループは、通常4回、非常に低いレートで動作します。一方、ファクトリーオートメーションは、個々の自動車部品などの個別の商品を扱い、ミリ秒の速度までより速いループを必要とします。動的なアクティビティを監視するモーション制御は、ミリ秒以下のオーダー以下でさらに速いレートを必要とする場合があります。
In all those cases, a packet must flow reliably between the sensor and the PLC, be processed by the PLC, and be sent to the actuator within the control loop period. In some particular use cases that inherit from analog operations, jitter might also alter the operation of the control loop. A rare packet loss is usually admissible, but typically, a loss of multiple packets in a row will cause an emergency halt of the production and incur a high cost for the manufacturer.
これらのすべての場合において、パケットはセンサーとPLCの間を確実に流れ、PLCによって処理され、コントロールループ期間内にアクチュエータに送信する必要があります。アナログ操作から継承する特定のユースケースでは、ジッターはコントロールループの動作も変更する場合があります。通常、まれなパケットの損失は許容されますが、通常、複数のパケットを連続して損失すると、生産の緊急停止が発生し、メーカーに高コストが発生します。
Additional details and use cases related to industrial applications and their RAW requirements can be found in [RAW-IND-REQS].
産業用アプリケーションに関連する追加の詳細とユースケースとその生の要件は、[Raw-ind-reqs]に記載されています。
A secondary use case deals with monitoring and diagnostics. This data is essential to improve the performance of a production line, e.g., by optimizing real-time processing or by maintenance windows using Machine Learning predictions. For the lack of wireless technologies, some specific industries such as Oil and Gas have been using serial cables, literally by the millions, to perform their process optimization over the previous decades. However, few industries would afford the associated cost. One of the goals of the Industrial Internet of Things is to provide the same benefits to all industries, including SmartGrid, transportation, building, commercial, and medical. This requires a cheap, available, and scalable IP-based access technology.
二次ユースケースは、監視と診断を扱います。このデータは、リアルタイム処理を最適化するか、機械学習予測を使用してウィンドウをメンテナンスすることにより、生産ラインのパフォーマンスを改善するために不可欠です。ワイヤレステクノロジーの不足のために、石油やガスなどの特定の産業の中には、文字通り何百万人ものシリアルケーブルを使用して、過去数十年にわたってプロセスの最適化を実行しています。ただし、関連するコストを支払う余裕がある産業はほとんどありません。産業用インターネットの目標の1つは、SmartGrid、輸送、建築、商業、医療など、すべての業界に同じ利益を提供することです。これには、安価で利用可能なスケーラブルなIPベースのアクセステクノロジーが必要です。
Inside the factory, wires may already be available to operate the control network. However, monitoring and diagnostics data are not welcome in that network for several reasons. On the one hand, it is rich and asynchronous, meaning that it may influence the deterministic nature of the control operations and impact the production. On the other hand, this information must be reported to the operators over IP, which means the potential for a security breach via the interconnection of the Operational Technology network with the Internet Technology network and the potential of a rogue access.
工場内では、制御ネットワークを操作するためにすでにワイヤが利用できる場合があります。ただし、いくつかの理由で、そのネットワークで監視および診断データは歓迎されません。一方では、それは豊かで非同期です。つまり、制御操作の決定論的な性質に影響を与え、生産に影響を与える可能性があります。一方、この情報は、IPを介してオペレーターに報告する必要があります。これは、インターネットテクノロジーネットワークと不正アクセスの可能性を介したオペレーショナルテクノロジーネットワークの相互接続を介したセキュリティ侵害の可能性を意味します。
Wires used on a robot arm are prone to breakage, after a few thousand flexions, a lot faster than a power cable that is wider in diameter and more resilient. In general, wired networking and mobile parts are not a good match, mostly in the case of fast and recurrent activities, as well as rotation.
ロボットアームで使用されるワイヤーは、数千の屈曲の後に破損する傾向があり、直径が広く弾力性のある電源ケーブルよりもはるかに速いです。一般に、有線ネットワーキングとモバイル部品は、主に高速で再発性のアクティビティと回転の場合には良好な一致ではありません。
When refurbishing older premises that were built before the Internet age, power is usually available everywhere, but data is not. It is often impractical, time consuming and expensive to deploy an Ethernet fabric across walls and between buildings. Deploying a wire may take months and cost tens of thousands of US Dollars.
インターネット時代以前に構築された古い施設を改装する場合、通常はどこでも電力が利用できますが、データは利用できません。多くの場合、壁を越えて建物間でイーサネットファブリックを展開するのは非現実的で、時間がかかり、費用がかかります。ワイヤーの展開には数か月かかり、数万米ドルかかる場合があります。
Even when wiring exists, like in the case of an existing control network, asynchronous IP packets, such as diagnostics, may not be welcome for operational and security reasons. For those packets, the option to create a parallel wireless network offers a credible solution that can scale with the many sensors and actuators that equip every robot, valve, and fan that are deployed on the factory floor. It may also help detect and prevent a failure that could impact the production, like the degradation (vibration) of a cooling fan on the ceiling. IEEE Std. 802.15.4 TSCH [RFC7554] is a promising technology for that purpose, mostly if the scheduled operations enable the use of the same network by asynchronous and deterministic flows in parallel.
既存の制御ネットワークの場合のように配線が存在する場合でも、診断などの非同期IPパケットは、運用上およびセキュリティ上の理由から歓迎されない場合があります。これらのパケットの場合、並列ワイヤレスネットワークを作成するオプションは、工場の床に展開されているすべてのロボット、バルブ、ファンを装備する多くのセンサーとアクチュエーターとともにスケーリングできる信頼できるソリューションを提供します。また、天井の冷却ファンの劣化（振動）など、生産に影響を与える可能性のある故障を検出および防止するのに役立ちます。IEEE STD。802.15.4 TSCH [RFC7554]は、主にスケジュールされた操作が非同期および決定論的な流れによって同じネットワークを使用できる場合、その目的のための有望な技術です。
As stated by the "Deterministic Networking Problem Statement" [RFC8557], a deterministic network is backwards compatible with (capable of transporting) statistically multiplexed traffic while preserving the properties of the accepted deterministic flows. While the "6TiSCH Architecture" [RFC9030] serves that requirement, the work at 6TiSCH was focused on best-effort IPv6 packet flows. RAW should be able to lock so-called "hard cells" (i.e., scheduled cells [6TiSCH-TERMS]) for use by a centralized scheduler and leverage time and spatial diversity over a graph of end-to-end paths called a "Track" that is based on those cells.
「決定論的ネットワーク問題ステートメント」[RFC8557]で述べられているように、決定論的ネットワークは、受け入れられている決定論的流量の特性を保存しながら、統計的に多重化されたトラフィックとの逆方向に互換性があります。「6Tisch Architecture」[RFC9030]はその要件を提供していますが、6tischでの作業は、Best-Effort IPv6パケットフローに焦点を当てていました。RAWは、集中スケジューラが使用するために、いわゆる「ハードセル」（すなわち、スケジュールされたセル[6tisch-terms]）をロックできるはずです。「それはそれらのセルに基づいています。
Over recent years, major industrial protocols have been migrating towards Ethernet and IP. (For example, [ODVA] with EtherNet/IP [EIP] and [PROFINET], where ODVA is the organization that supports network technologies built on the Common Industrial Protocol (CIP) including EtherNet/IP.) In order to unleash the full power of the IP hourglass model, it should be possible to deploy any application over any network that has the physical capacity to transport the industrial flow, regardless of the MAC/PHY technology, wired, or wireless, and across technologies. RAW mechanisms should be able to set up a Track over a wireless access segment and a wired or wireless backbone to report both sensor data and critical monitoring within a bounded latency and should be able to maintain the high reliability of the flows over time. It is also important to ensure that RAW solutions are interoperable with existing wireless solutions in place and with legacy equipment whose capabilities can be extended using retrofitting. Maintainability, as a broader concept than reliability, is also important in industrial scenarios [MAR19].
近年、主要な産業プロトコルがイーサネットとIPに移行しています。（たとえば、[ODVA]イーサネット/IP [EIP]および[Profinet]を使用しています。ODVAは、Ethernet/IP。を含む一般的な産業プロトコル（CIP）に基づいて構築されたネットワークテクノロジーをサポートする組織です）。IP砂時計モデルのうち、Mac/Phyテクノロジー、有線、またはワイヤレス、およびテクノロジー全体に関係なく、産業の流れを輸送する物理的能力を持つネットワーク上にアプリケーションを展開することが可能です。生のメカニズムは、ワイヤレスアクセスセグメントと有線またはワイヤレスバックボーン上にトラックをセットアップできる必要があります。また、RAWソリューションが既存のワイヤレスソリューションと、改装を使用して機能を拡張できるレガシー機器と相互運用可能であることを確認することも重要です。信頼性よりも幅広い概念としての保守性は、産業シナリオでも重要です[Mar19]。
Monitoring and diagnostics applications do not require latency-critical communications but demand reliable and scalable communications. On the other hand, process-control applications involve control loops that require a bounded latency and, thus, are latency critical. However, they can be managed end-to-end, and therefore DetNet mechanisms can be applied in conjunction with RAW mechanisms.
監視および診断アプリケーションでは、潜在的な批判的な通信は必要ありませんが、信頼性の高いスケーラブルな通信を必要とします。一方、プロセス制御アプリケーションには、境界のあるレイテンシを必要とする制御ループが含まれ、したがって、レイテンシーが重要です。ただし、それらはエンドツーエンドで管理できます。したがって、デットネットメカニズムは、生のメカニズムと組み合わせて適用できます。
Many devices support audio and video streaming [RFC9317] by employing 802.11 wireless LAN. Some of these applications require low latency capability, for instance, when the application provides interactive play or when the audio plays in real time -- meaning being live for public addresses in train stations or in theme parks.
多くのデバイスは、802.11ワイヤレスLANを採用することにより、オーディオおよびビデオストリーミング[RFC9317]をサポートしています。これらのアプリケーションの一部は、たとえば、アプリケーションがインタラクティブなプレイを提供する場合、またはオーディオがリアルタイムで再生されるとき、つまり、鉄道局やテーマパークで公開住所のためにライブであることを意味する低いレイテンシ機能を必要とします。
The professional audio and video industry (ProAV) includes:
プロのオーディオおよびビデオ業界（PROAV）には以下が含まれます。
* Virtual Reality / Augmented Reality (VR/AR)
* バーチャルリアリティ /拡張現実（VR / AR）
* Production and post-production systems, such as CD and Blu-ray disk mastering.
* CDやBlu-rayディスクのマスタリングなどの生産およびポストプロダクションシステム。
* Public address, media, and emergency systems at large venues (e.g., airports, train stations, stadiums, and theme parks).
* 大規模な会場（空港、鉄道駅、スタジアム、テーマパークなど）のパブリックアドレス、メディア、および緊急システム。
Considering the uninterrupted audio or video stream, a potential packet loss during the transmission of audio or video flows cannot be tackled by re-trying the transmission, as it is done with file transfer, because by the time the lost packet has been identified, it is too late to proceed with packet re-transmission. Buffering might be employed to provide a certain delay that will allow for one or more re-transmissions. However, such an approach is not viable in applications where delays are not acceptable.
途切れないオーディオまたはビデオストリームを考慮すると、ファイル転送で行われるように、トランスミッションを再試行することで、オーディオまたはビデオフローの送信中の潜在的なパケット損失に取り組むことはできません。パケットの再送信を進めるには遅すぎます。バッファリングを使用して、1つ以上の再輸送を可能にする特定の遅延を提供する場合があります。ただし、このようなアプローチは、遅延が受け入れられないアプリケーションでは実行可能ではありません。
In the context of ProAV over packet networks, latency is the time between the transmitted signal over a stream and its reception. Thus, for sound to remain synchronized to the movement in the video, the latency of both the audio and video streams must be bounded and consistent.
ProAVオーバーパケットネットワークのコンテキストでは、レイテンシとは、ストリーム上の送信信号とその受信の間の時間です。したがって、サウンドはビデオの動きに同期し続けるためには、オーディオストリームとビデオストリームの両方のレイテンシを制限し、一貫している必要があります。
Audio and video devices need the wireless communication to support video streaming via IEEE 802.11 wireless LAN, for instance. Wireless communications provide huge advantages in terms of simpler deployments in many scenarios where the use of a wired alternative would not be feasible. Similarly, in live events, mobility support makes wireless communications the only viable approach.
オーディオおよびビデオデバイスには、たとえばIEEE 802.11ワイヤレスLANを介したビデオストリーミングをサポートするワイヤレス通信が必要です。ワイヤレス通信は、有線の代替品の使用が実行不可能な多くのシナリオで、より単純な展開の点で大きな利点を提供します。同様に、ライブイベントでは、モビリティサポートにより、ワイヤレス通信が唯一の実行可能なアプローチになります。
Deployed announcement speakers, for instance, along the platforms of the train stations, need the wireless communication to forward the audio traffic in real time. Most train stations are already built, and deploying novel cables for each novel service seems expensive.
たとえば、列車の駅のプラットフォームに沿って、展開されたアナウンススピーカーには、オーディオトラフィックをリアルタイムで転送するワイヤレス通信が必要です。ほとんどの列車はすでに建設されており、新しいサービスごとに新しいケーブルを展開すると高価に思えます。
The network infrastructure needs to support heterogeneous types of traffic (including QoS).
ネットワークインフラストラクチャは、不均一なタイプのトラフィック（QOを含む）をサポートする必要があります。
Content delivery must have bounded latency (to the lowest possible latency).
コンテンツの配信には、（可能な限り低いレイテンシまで）境界のあるレイテンシが必要です。
The deployed network topology should allow for multipath. This will enable for multiple streams to have different (and multiple) paths (Tracks) through the network to support redundancy.
展開されたネットワークトポロジは、マルチパスを可能にするはずです。これにより、複数のストリームがネットワークを介して異なる（および複数の）パス（トラック）を持つことができ、冗長性をサポートします。
For synchronized streaming, latency must be bounded. Therefore, depending on the actual requirements, this can be considered as "latency critical". However, the most critical requirement of this use case is reliability, which can be achieved by the network providing redundancy. Note that in many cases, wireless is only present in the access where RAW mechanisms could be applied, but other wired segments are also involved (like the Internet), and therefore latency cannot be guaranteed.
同期されたストリーミングの場合、レイテンシを境界する必要があります。したがって、実際の要件に応じて、これは「遅延が重要」と見なすことができます。ただし、このユースケースの最も重要な要件は信頼性であり、これはネットワークが冗長性を提供することで達成できます。多くの場合、ワイヤレスは生のメカニズムを適用できるアクセスにのみ存在するが、他の有線セグメントも関与しているため（インターネットなど）、したがってレイテンシを保証できないことに注意してください。
The gaming industry includes [IEEE80211RTA] real-time mobile gaming, wireless console gaming, wireless gaming controllers, and cloud gaming. Note that they are not mutually exclusive (e.g., a console can connect wirelessly to the Internet to play a cloud game). For RAW, wireless console gaming is the most relevant one. We next summarize the four:
ゲーム業界には、[IEEE80211RTA]リアルタイムモバイルゲーム、ワイヤレスコンソールゲーム、ワイヤレスゲームコントローラー、クラウドゲームが含まれます。それらは相互に排他的ではないことに注意してください（たとえば、コンソールはワイヤレスでインターネットに接続してクラウドゲームをプレイできます）。生の場合、ワイヤレスコンソールゲームが最も関連性の高いものです。次に、4つを要約します。
* Real-time mobile gaming:
* リアルタイムモバイルゲーム：
* Real-time mobile gaming is very sensitive to network latency and stability. The mobile game can connect multiple players together in a single game session and exchange data messages between game server and connected players. Real-time means the feedback should present on-screen as users operate in-game. For good game experience, the end-to-end latency plus game servers processing time must be the same for all players and should not be noticeable as the game is played. RAW technologies might help in keeping latencies low on the wireless segments of the communication.
* リアルタイムのモバイルゲームは、ネットワークの遅延と安定性に非常に敏感です。モバイルゲームは、単一のゲームセッションで複数のプレーヤーを結び付け、ゲームサーバーと接続されたプレーヤー間でデータメッセージを交換できます。リアルタイムとは、ユーザーがゲーム内で動作するときにフィードバックが画面上で表示されることを意味します。優れたゲームエクスペリエンスのために、エンドツーエンドのレイテンシとゲームサーバーの処理時間はすべてのプレーヤーで同じでなければならず、ゲームが再生されるときに目立たないはずです。生のテクノロジーは、通信の無線セグメントのレイテンシを低く保つのに役立つかもしれません。
* Wireless console gaming:
* ワイヤレスコンソールゲーム：
* While gamers may use a physical console, interactions with a remote server may be required for online games. Most of the gaming consoles today support Wi-Fi 5 but may benefit from a scheduled access with Wi-Fi 6 in the future. Previous Wi-Fi versions have an especially bad reputation among the gaming community, the main reasons being high latency, lag spikes, and jitter.
* ゲーマーは物理コンソールを使用する場合がありますが、オンラインゲームにはリモートサーバーとのやり取りが必要になる場合があります。今日のゲームコンソールのほとんどは、Wi-Fi 5をサポートしていますが、将来的にはWi-Fi 6へのスケジュールされたアクセスの恩恵を受ける可能性があります。以前のWi-Fiバージョンは、ゲームコミュニティの間で特に評判が悪く、主な理由は高い遅延、ラグスパイク、ジッターです。
* Wireless Gaming controllers:
* ワイヤレスゲームコントローラー：
* Most controllers are now wireless for the freedom of movement. Controllers may interact with consoles or directly with the gaming server in the cloud. A low and stable end-to-end latency is here of predominant importance.
* 現在、ほとんどのコントローラーは、移動の自由のためにワイヤレスになっています。コントローラーは、コンソールと、またはクラウド内のゲームサーバーと直接対話する場合があります。低く安定したエンドツーエンドのレイテンシは、ここで主要な重要性を持っています。
* Cloud Gaming:
* クラウドゲーム：
* Cloud gaming requires low-latency capability as the user commands in a game session are sent back to the cloud server. Then, the cloud server updates the game context depending on the received commands, renders the picture/video to be displayed on the user devices, and streams the picture/video content to the user devices. User devices might very likely be connected wirelessly.
* クラウドゲームには、ゲームセッションのユーザーコマンドがクラウドサーバーに送信されるため、低遅延機能が必要です。次に、クラウドサーバーは、受信したコマンドに応じてゲームのコンテキストを更新し、ユーザーデバイスに表示される画像/ビデオをレンダリングし、画像/ビデオコンテンツをユーザーデバイスにストリーミングします。ユーザーデバイスは、ワイヤレスで接続されている可能性が非常に高い場合があります。
While a lot of details can be found at [IEEE80211RTA], we next summarize the main requirements in terms of latency, jitter, and packet loss:
[IEEE80211RTA]には多くの詳細がありますが、次に、レイテンシ、ジッター、パケット損失の観点から主な要件を要約します。
* Intra Basic Service Set (BSS) latency is less than 5 ms.
* 基本的なサービスセット（BSS）のレイテンシは5ミリ秒未満です。
* Jitter variance is less than 2 ms.
* ジッターの分散は2ミリ秒未満です。
* Packet loss is less than 0.1%.
* パケット損失は0.1％未満です。
Gaming is evolving towards wireless, as players demand being able to play anywhere, and the game requires a more immersive experience including body movements. Besides, the industry is changing towards playing from mobile phones, which are inherently connected via wireless technologies. Wireless controllers are the rule in modern gaming, with increasingly sophisticated interactions (e.g., haptic feedback, augmented reality).
プレイヤーがどこでもプレイできることを要求するため、ゲームはワイヤレスに向かって進化しており、ゲームには身体の動きを含むより没入型の体験が必要です。それに加えて、業界は携帯電話からの遊びに向けて変化しています。携帯電話は、ワイヤレステクノロジーを介して本質的に接続されています。ワイヤレスコントローラーは、近代的なゲームのルールであり、ますます洗練された相互作用（触覚フィードバック、拡張現実など）があります。
Time-sensitive networking extensions:
時間に敏感なネットワーキング拡張機能：
Extensions, such as time-aware shaping and redundancy, can be explored to address congestion and reliability problems present in wireless networks. As an example, in haptics, it is very important to minimize latency failures.
時間認識の形状や冗長性などの拡張機能を検討して、ワイヤレスネットワークに存在する混雑と信頼性の問題に対処することができます。例として、触覚では、遅延の障害を最小限に抑えることが非常に重要です。
Priority tagging (Stream identification):
優先タグ付け（ストリーム識別）：
One basic requirement to provide better QoS for time-sensitive traffic is the capability to identify and differentiate time-sensitive packets from other (like best-effort) traffic.
時間に敏感なトラフィックに優れたQoSを提供するための基本的な要件の1つは、他の（ベストエフォートなど）トラフィックから時間に敏感なパケットを特定して区別する機能です。
Time-aware shaping:
時間を手にした形状：
This capability (defined in IEEE 802.1Qbv) consists of gates to control the opening and closing of queues that share a common egress port within an Ethernet switch. A scheduler defines the times when each queue opens or closes, therefore, eliminating congestion and ensuring that frames are delivered within the expected latency bounds. Though, note that while this requirement needs to be signaled by RAW mechanisms, it would actually be served by the lower layer.
この機能（IEEE 802.1QBVで定義）は、イーサネットスイッチ内の一般的な出口ポートを共有するキューの開閉を制御するためのゲートで構成されています。スケジューラは、各キューが開閉する時間を定義し、したがって、輻輳を排除し、予想されるレイテンシの境界内でフレームが配信されることを保証します。ただし、この要件は生のメカニズムによってシグナルを受信する必要がありますが、実際には下層によって提供されることに注意してください。
Dual/multiple link:
デュアル/マルチリンク：
Due to the fact that competitions and interference are common and hardly in control under wireless network, to improve the latency stability, dual/multiple link proposal is brought up to address this issue.
競争と干渉は一般的であり、ワイヤレスネットワークではほとんど制御されていないという事実により、レイテンシの安定性を改善するために、この問題に対処するためにデュアル/マルチリンクの提案が提起されます。
Admission Control:
入場管理：
Congestion is a major cause of high/variable latency, and it is well known that if the traffic load exceeds the capability of the link, QoS will be degraded. QoS degradation may be acceptable for many applications today. However, emerging time-sensitive applications are highly susceptible to increased latency and jitter. To better control QoS, it is important to control access to the network resources.
輻輳は高/可変遅延の主な原因であり、トラフィック負荷がリンクの能力を超えるとQOが劣化することはよく知られています。QoSの劣化は、今日の多くのアプリケーションで受け入れられるかもしれません。ただし、新たな時間に敏感なアプリケーションは、レイテンシやジッターの増加に非常に影響を受けやすくなっています。QoSをより適切に制御するには、ネットワークリソースへのアクセスを制御することが重要です。
Depending on the actual scenario, and on use of Internet to interconnect different users, the communication requirements of this use case might be considered as latency critical due to the need of bounded latency. However, note that, in most of these scenarios, part of the communication path is not wireless, and DetNet mechanisms cannot be applied easily (e.g., when the public Internet is involved), and therefore, reliability is the critical requirement.
実際のシナリオ、および異なるユーザーを相互接続するためにインターネットを使用することにより、このユースケースの通信要件は、ランドレイテンシが必要なため、遅延が重要と見なされる場合があります。ただし、これらのシナリオのほとんどでは、通信パスの一部はワイヤレスではなく、デットネットメカニズムを簡単に適用できないことに注意してください（たとえば、パブリックインターネットが関与している場合）。したがって、信頼性は重要な要件です。
Unmanned Aerial Vehicles (UAVs) are becoming very popular for many different applications, including military and civil use cases. The term "drone" is commonly used to refer to a UAV.
無人航空機（UAV）は、軍事および民間のユースケースを含む多くの異なるアプリケーションで非常に人気があります。「ドローン」という用語は、一般にUAVを参照するために使用されます。
UAVs can be used to perform aerial surveillance activities, traffic monitoring (i.e., the Spanish traffic control has recently introduced a fleet of drones for quicker reactions upon traffic congestion related events [DGT2021]), support of emergency situations, and even transporting of small goods (e.g., medicine in rural areas). Note that the surveillance and monitoring application would have to comply with local regulations regarding location privacy of users. Different considerations have to be applied when surveillance is performed for traffic rules enforcement (e.g., generating fines), as compared to when traffic load is being monitored.
UAVは、空中監視活動、交通監視（つまり、スペインの交通規制が最近、交通渋滞関連のイベント[DGT2021]に迅速な反応のためにドローンのフリートを導入しました）、緊急事態の支援、さらには少量商品の輸送さえあります。（例えば、農村部の薬）。監視および監視アプリケーションは、ユーザーのロケーションプライバシーに関するローカル規制を遵守する必要があることに注意してください。交通規則の執行（例：罰金の生成など）のために監視が行われる場合、交通量が監視されている場合と比較して、さまざまな考慮事項を適用する必要があります。
Many types of vehicles, including UAVs but also others, such as cars, can travel in platoons, driving together with shorter distances between vehicles to increase efficiency. Platooning imposes certain vehicle-to-vehicle considerations, most of these are applicable to both UAVs and other vehicle types.
UAVを含む多くの種類の車両だけでなく、車などの他の車両も小隊を移動し、効率を高めるために車両間のより短い距離と一緒に運転することができます。小隊は特定の車両から車両間の考慮事項を課します。これらのほとんどは、UAVと他の車両タイプの両方に適用できます。
UAVs and other vehicles typically have various forms of wireless connectivity:
UAVやその他の車両には、通常、さまざまな形式のワイヤレス接続があります。
* Cellular: for communication with the control center, remote maneuvering, and monitoring of the drone;
* Cellular：コントロールセンターとの通信、リモート操縦、ドローンの監視。
* IEEE 802.11: for inter-drone communications (i.e., platooning) and providing connectivity to other devices (i.e., acting as Access Point).
* IEEE 802.11：ドローン間通信（つまり、小隊）および他のデバイスへの接続を提供する（つまり、アクセスポイントとして機能する）。
Note that autonomous cars share many of the characteristics of the aforementioned UAV case. Therefore, it is of interest for RAW.
自動運転車は、前述のUAVケースの特性の多くを共有していることに注意してください。したがって、それはRAWにとって興味深いものです。
Some of the use cases and tasks involving UAVs require coordination among UAVs. Others involve complex computing tasks that might not be performed using the limited computing resources that a drone typically has. These two aspects require continuous connectivity with the control center and among UAVs.
UAVを含むユースケースとタスクの一部は、UAV間の調整が必要です。その他は、ドローンが通常持っている限られたコンピューティングリソースを使用して実行されない可能性のある複雑なコンピューティングタスクを伴います。これらの2つの側面には、コントロールセンターとUAVとの継続的な接続が必要です。
Remote maneuvering of a drone might be performed over a cellular network in some cases, but there are situations that need very low latency and deterministic behavior of the connectivity. Examples involve platooning of drones or sharing of computing resources among drones (like a drone offloading some function to a neighboring drone).
ドローンのリモート操作は、場合によってはセルラーネットワーク上で実行される場合がありますが、接続性の非常に低いレイテンシと決定論的動作が必要な状況があります。例には、ドローンの小隊やドローン間のコンピューティングリソースの共有（隣接するドローンに何らかの機能をオフロードするドローンなど）が含まれます。
UAVs cannot be connected through any type of wired media, so it is obvious that wireless is needed.
UAVは、あらゆる種類の有線メディアを介して接続できないため、ワイヤレスが必要であることは明らかです。
The network infrastructure is composed of the UAVs themselves, requiring self-configuration capabilities.
ネットワークインフラストラクチャは、UAV自体で構成されており、自己構成機能が必要です。
Heterogeneous types of traffic need to be supported, from extremely critical traffic types requiring ultra-low latency and high resiliency to traffic requiring low-to-medium latency.
不均一なタイプのトラフィックをサポートする必要があります。非常に重要なトラフィックタイプから、超低レイテンシと高い回復力を必要とする非常に重要なトラフィックタイプから、低から中程度のレイテンシを必要とするトラフィックまで。
When a given service is decomposed into functions (which are hosted at different UAVs and chained), each link connecting two given functions would have a well-defined set of requirements (e.g., latency, bandwidth, and jitter) that must be met.
特定のサービスが関数（異なるUAVでホストされ、チェーンでホストされている）に分解されると、2つの指定された関数を接続する各リンクには、明確に定義された一連の要件（潜時、帯域幅、ジッターなど）を満たす必要があります。
Today's solutions keep the processing operations that are critical local (i.e., they are not offloaded). Therefore, in this use case, the critical requirement is reliability, and, only for some platooning and inter-drone communications, latency is critical.
今日のソリューションは、重要なローカルである処理操作を保持します（つまり、オフロードされていません）。したがって、このユースケースでは、重要な要件は信頼性であり、一部の小隊とドローン間の通信のみでのみ、遅延が重要です。
The edge robotics scenario consists of several robots, deployed in a given area (like a shopping mall) and inter-connected via an access network to a network edge device or a data center. The robots are connected to the edge so that complex computational activities are not executed locally at the robots but offloaded to the edge. This brings additional flexibility in the type of tasks that the robots perform, reduces the costs of robot-manufacturing (due to their lower complexity), and enables complex tasks involving coordination among robots (that can be more easily performed if robots are centrally controlled).
エッジロボットシナリオは、特定のエリア（ショッピングモールなど）に展開され、アクセスネットワークを介してネットワークエッジデバイスまたはデータセンターに相互接続されたいくつかのロボットで構成されています。ロボットはエッジに接続されているため、複雑な計算アクティビティがロボットでローカルに実行されるのではなく、エッジにオフロードされます。これにより、ロボットが実行するタスクの種類に追加の柔軟性がもたらされ、ロボット製造のコストが削減され（複雑さが低いため）、ロボット間の調整を含む複雑なタスクが可能になります（ロボットが中央に制御されると、より簡単に実行できます）。
Simple examples of the use of multiple robots are cleaning, video surveillance (note that this have to comply with local regulations regarding user privacy at the application level), search and rescue operations, and delivering of goods from warehouses to shops. Multiple robots are simultaneously instructed to perform individual tasks by moving the robotic intelligence from the robots to the network's edge. That enables easy synchronization, scalable solution, and on-demand option to create flexible fleet of robots.
複数のロボットの使用の簡単な例は、クリーニング、ビデオ監視（アプリケーションレベルでのユーザープライバシーに関するローカル規制に準拠する必要があることに注意してください）、倉庫からショップへの商品の配信です。ロボットインテリジェンスをロボットからネットワークのエッジに移動することにより、個々のタスクを実行するように複数のロボットが同時に指示されます。これにより、簡単な同期、スケーラブルなソリューション、およびオンデマンドオプションが柔軟なロボットフリートを作成できます。
Robots would have various forms of wireless connectivity:
ロボットには、さまざまな形式のワイヤレス接続があります。
* Cellular: as an additional communication link to the edge, though primarily as backup, since ultra-low latency is needed.
* Cellular：超低レイテンシが必要なため、主にバックアップとして、追加の通信リンクとしてエッジへのリンクとして。
* IEEE 802.11: for connection to the edge and also inter-robot communications (i.e., for coordinated actions).
* IEEE 802.11：エッジへの接続およびロボット間通信（つまり、調整されたアクションの場合）。
Some of the use cases and tasks involving robots might benefit from decomposition of a service into small functions that are distributed and chained among robots and the edge. These require continuous connectivity with the control center and among drones.
ロボットを含むユースケースとタスクの一部は、ロボットとエッジの間に分布して接続された小さな機能へのサービスの分解から恩恵を受ける可能性があります。これらには、コントロールセンターとドローン間の継続的な接続が必要です。
Robot control is an activity requiring very low latency (0.5-20 ms [Groshev2021]) between the robot and the location where the control intelligence resides (which might be the edge or another robot).
ロボット制御は、ロボットとコントロールインテリジェンスが存在する場所（エッジまたは別のロボットかもしれない）の間の非常に低いレイテンシ（0.5〜20ミリ秒[Groshev2021]）を必要とするアクティビティです。
Deploying robots in scenarios such as shopping malls for the applications mentioned cannot be done via wired connectivity.
上記のアプリケーション用のショッピングモールなどのシナリオにロボットを展開することは、有線接続を介して行うことはできません。
The network infrastructure needs to support heterogeneous types of traffic, from robot control to video streaming.
ネットワークインフラストラクチャは、ロボット制御からビデオストリーミングまで、不均一なタイプのトラフィックをサポートする必要があります。
When a given service is decomposed into functions (which are hosted at different UAVs and chained), each link connecting two given functions would have a well-defined set of requirements (e.g., latency, bandwidth, and jitter) that must be met.
特定のサービスが関数（異なるUAVでホストされ、チェーンでホストされている）に分解されると、2つの指定された関数を接続する各リンクには、明確に定義された一連の要件（潜時、帯域幅、ジッターなど）を満たす必要があります。
This use case might combine multiple communication flows, with some of them being latency critical (like those related to robot-control tasks). Note that there are still many communication flows (like some offloading tasks) that only demand reliability and availability.
このユースケースは、複数の通信フローを組み合わせており、そのうちのいくつかはレイテンシーが重要です（ロボット制御タスクに関連するものと同様）。信頼性と可用性のみを必要とするだけの多くの通信フロー（一部のオフロードタスクのように）があることに注意してください。
An instrumented ambulance would have one or multiple network segments that are connected to end systems such as:
計装された救急車には、次のようなエンドシステムに接続されている1つまたは複数のネットワークセグメントがあります。
* vital signs sensors attached to the casualty in the ambulance to relay medical data to hospital emergency room,
* 病院の緊急治療室に医療データを中継するために、救急車の犠牲者に接続されたバイタルサインセンサー
* a radio-navigation sensor to relay position data to various destinations including dispatcher,
* ディスパッチャーを含むさまざまな目的地に配置データを中継する無線具体的なセンサー、
* voice communication for ambulance attendant (likely to consult with ER doctor), and
* 救急車のアテンダントのための音声コミュニケーション（ERドクターと相談する可能性が高い）、および
* voice communication between driver and dispatcher.
* ドライバーとディスパッチャーの間の音声通信。
The LAN needs to be routed through radio-WANs (a radio network in the interior of a network, i.e., it is terminated by routers) to complete the network linkage.
LANは、ネットワークリンケージを完了するには、ラジオワン（ネットワークの内部にあるラジオネットワーク、つまりルーターによって終了します）を介してルーティングする必要があります。
What we have today is multiple communication systems to reach the vehicle via:
今日私たちが持っているのは、以下を介して車両に到達する複数の通信システムです。
* a dispatching system,
* 派遣システム、
* a cellphone for the attendant,
* アテンダントのための携帯電話、
* a special purpose telemetering system for medical data,
* 医療データのための特別な目的のテレメーターシステム、
* etc.
* 等エトセトラ
This redundancy of systems does not contribute to availability.
このシステムの冗長性は、可用性に貢献しません。
Most of the scenarios involving the use of an instrumented ambulance are composed of many different flows, each of them with slightly different requirements in terms of reliability and latency. Destinations might be either the ambulance itself (local traffic), a near edge cloud, or the general Internet/cloud. Special care (at application level) have to be paid to ensure that sensitive data is not disclosed to unauthorized parties by properly securing traffic and authenticating the communication ends.
計装された救急車の使用を含むシナリオのほとんどは、信頼性と遅延に関してわずかに異なる要件を持つ多くの異なるフローで構成されています。目的地は、救急車自体（ローカルトラフィック）、近いエッジクラウド、または一般的なインターネット/クラウドのいずれかです。特別なケア（アプリケーションレベルで）は、トラフィックを適切に保護し、通信の終了を認証することにより、機密データが不正な当事者に開示されないようにするために支払わなければなりません。
Local traffic between the first responders and ambulance staff and the ambulance equipment cannot be done via wired connectivity as the responders perform initial treatment outside of the ambulance. The communications from the ambulance to external services must be wireless as well.
応答者が救急車の外で初期治療を行うため、ファーストレスポンダーと救急車のスタッフと救急車の間のローカルトラフィックは、有線接続を介して行うことはできません。救急車から外部サービスへの通信もワイヤレスでなければなりません。
We can derive some pertinent requirements from this scenario:
このシナリオからいくつかの適切な要件を導き出すことができます。
* High availability of the internetwork is required. The exact level of availability depends on the specific deployment scenario, as not all emergency agencies share the same type of instrumented emergency vehicles.
* インターネットワークの高度な可用性が必要です。すべての緊急機関が同じタイプの緊急車両を共有しているわけではないため、可用性の正確なレベルは特定の展開シナリオに依存します。
* The internetwork needs to operate in damaged state (e.g., during an earthquake aftermath, heavy weather, a wildfire, etc.). In addition to continuity of operations, rapid restore is a needed characteristic.
* インターネットワークは、損傷した状態で動作する必要があります（たとえば、地震の余波、激しい天気、山火事など）。運用の連続性に加えて、迅速な復元は必要な特性です。
* The radio-WAN has characteristics similar to the cellphone's -- the vehicle will travel from one radio coverage area to another, thus requiring some hand-off approach.
* ラジオワンには携帯電話と同様の特性があります。車両は、あるラジオカバレッジエリアから別のラジオカバレッジエリアに移動するため、ハンドオフアプローチが必要です。
In this case, all applications identified do not require latency-critical communication but do need high reliability and availability.
この場合、特定されたすべてのアプリケーションは、潜在的な批判的な通信を必要としませんが、高い信頼性と可用性を必要とします。
This document enumerates several use cases and applications that need RAW technologies, focusing on the requirements from reliability, availability, and latency. While some use cases are latency critical, there are also several applications that are not latency critical but do pose strict reliability and availability requirements.
このドキュメントは、信頼性、可用性、および遅延からの要件に焦点を当てた、生のテクノロジーを必要とするいくつかのユースケースとアプリケーションを列挙しています。一部のユースケースは潜在的な重要性が重要ですが、遅延が重要ではないが、厳格な信頼性と可用性の要件をもたらすいくつかのアプリケーションもあります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document covers several representative applications and network scenarios that are expected to make use of RAW technologies. Each of the potential RAW use cases will have security considerations from both the use-specific perspective and the RAW technology perspective. [RFC9055] provides a comprehensive discussion of security considerations in the context of DetNet, which are generally also applicable to RAW.
このドキュメントでは、生のテクノロジーを利用することが期待されるいくつかの代表的なアプリケーションとネットワークシナリオをカバーしています。潜在的な生のユースケースのそれぞれには、使用固有の観点と生のテクノロジーの観点からセキュリティ上の考慮事項があります。[RFC9055]は、一般的にRAWにも適用されるDetNetのコンテキストで、セキュリティ上の考慮事項に関する包括的な議論を提供します。
[6TiSCH-TERMS]
Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q.
Wang, "Terms Used in IPv6 over the TSCH mode of IEEE
802.15.4e", Work in Progress, Internet-Draft, draft-ietf-
6tisch-terminology-10, 2 March 2018,
<https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-
terminology-10>.
[ACI19] Airports Council International, "Annual World Airport
Traffic Report, 2019", 2019,
<https://store.aci.aero/product/annual-world-airport-
traffic-report-2019/>.
[ARINC858P1]
SAE International, "Internet Protocol Suite (IPS) for
Aeronautical Safety Services Part 1 Airborne IPS System
Technical Requirements", ARINC858P1, June 2021,
<https://www.sae.org/standards/content/arinc858p1/>.
[DGT2021] Menéndez, J., "Drones: así es la vigilancia" [Drones: this
is surveillance], January 2021,
<https://revista.dgt.es/es/reportajes/2021/01ENERO/0126-
Como-funciona-un-operativo-con-drones.shtml>.
[DISNEY15] Kuang, C., "Disney's $1 Billion Bet on a Magical
Wristband", March 2015,
<https://www.wired.com/2015/03/disney-magicband/>.
[EIP] ODVA, "EtherNet/IP | ODVA Technologies | Industrial
Automation", <https://www.odva.org/technology-standards/
key-technologies/ethernet-ip/>.
[FAA20] U.S. Department of Transportation: Federal Aviation
Administration (FAA), "Next Generation Air Transportation
System (NextGen)", <https://www.faa.gov/nextgen/>.
[Groshev2021]
Groshev, M., Guimarães, C., de la Oliva, A., and R. Gazda,
"Dissecting the Impact of Information and Communication
Technologies on Digital Twins as a Service", IEEE Access,
Volume 9, DOI 10.1109/ACCESS.2021.3098109, July 2021,
<https://doi.org/10.1109/ACCESS.2021.3098109>.
[IAC20] Iacus, S., Natale, F., Santamaria, C., Spyratos, S., and
M. Vespe, "Estimating and projecting air passenger traffic
during the COVID-19 coronavirus outbreak and its socio-
economic impact", Safety Science, Volume 129,
DOI 10.1016/j.ssci.2020.104791, September 2020,
<https://doi.org/10.1016/j.ssci.2020.104791>.
[IAT20] IATA, "Economic Performance of the Airline Industry",
November 2020, <https://www.iata.org/en/iata-
repository/publications/economic-reports/airline-industry-
economic-performance---november-2020---report/>.
[ICAO2022] International Civil Aviation Organization (ICAO), "CHAPTER
13 L-Band Digital Aeronautical Communications System
(LDACS)", International Standards and Recommended
Practices, Annex 10 - Aeronautical Telecommunications,
Volume III, Communication Systems, 2022,
<https://www.ldacs.com/wp-content/uploads/2023/03/
WP06.AppA-DCIWG-6-LDACS_SARPs.pdf>.
[IEEE802.1AS]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Timing and Synchronization for Time-Sensitive
Applications", DOI 10.1109/IEEESTD.2020.9121845, IEEE
802.1AS-2020, June 2020,
<https://doi.org/10.1109/IEEESTD.2020.9121845>.
[IEEE80211BE]
Cavalcanti, D. and G. Venkatesan, "802.1 TSN over 802.11
with updates from developments in 802.11be", IEEE plenary
meeting, November 2020,
<https://www.ieee802.org/1/files/public/docs2020/new-
Cavalcanti-802-1TSN-over-802-11-1120-v02.pdf>.
[IEEE80211RTA]
IEEE standard for Information Technology, "IEEE 802.11
Real Time Applications TIG Report", November 2018.
[ISA100] ISA, "ISA100, Wireless Systems for Automation",
<https://www.isa.org/isa100/>.
[KOB12] Kober, J., Glisson, M., and M. Mistry, "Playing catch and
juggling with a humanoid robot",
DOI 10.1109/HUMANOIDS.2012.6651623, November 2012,
<https://doi.org/10.1109/HUMANOIDS.2012.6651623>.
[MAR19] Martinez, B., Cano, C., and X. Vilajosana, "A Square Peg
in a Round Hole: The Complex Path for Wireless in the
Manufacturing Industry", IEEE Communications Magazine,
Volume 57, Issue 4, DOI 10.1109/MCOM.2019.1800570, April
2019, <https://doi.org/10.1109/MCOM.2019.1800570>.
[Maurer2022]
Mäurer, N., Guggemos, T., Ewert, T., Gräupl, T., Schmitt,
C., and S. Grundner-Culemann, "Security in Digital
Aeronautical Communications A Comprehensive Gap Analysis",
International Journal of Critical Infrastructure
Protection, Volume 38, DOI 10.1016/j.ijcip.2022.100549,
September 2022,
<https://doi.org/10.1016/j.ijcip.2022.100549>.
[ODVA] ODVA, "ODVA | Industrial Automation | Technologies and
Standards", <https://www.odva.org/>.
[PLA14] Plass, S., Hermenier, R., Lücke, O., Gomez Depoorter, D.,
Tordjman, T., Chatterton, M., Amirfeiz, M., Scotti, S.,
Cheng, Y., Pillai, P., Gräupl, T., Durand, F., Murphy, K.,
Marriott, A., and A. Zaytsev, "Flight Trial Demonstration
of Seamless Aeronautical Networking", IEEE Communications
Magazine, Volume 52, Issue 5,
DOI 10.1109/MCOM.2014.6815902, May 2014,
<https://doi.org/10.1109/MCOM.2014.6815902>.
[PROFINET] PROFINET, "PROFINET Technology",
<https://us.profinet.com/technology/profinet/>.
[RAW-IND-REQS]
Sofia, R. C., Kovatsch, M., and P. Mendes, "Requirements
for Reliable Wireless Industrial Services", Work in
Progress, Internet-Draft, draft-ietf-raw-industrial-
requirements-00, 10 December 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-
industrial-requirements-00>.
[RAW-TECHNOS]
Thubert, P., Ed., Cavalcanti, D., Vilajosana, X., Schmitt,
C., and J. Farkas, "Reliable and Available Wireless
Technologies", Work in Progress, Internet-Draft, draft-
ietf-raw-technologies-08, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-
technologies-08>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015,
<https://www.rfc-editor.org/info/rfc7554>.
[RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem
Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019,
<https://www.rfc-editor.org/info/rfc8557>.
[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases",
RFC 8578, DOI 10.17487/RFC8578, May 2019,
<https://www.rfc-editor.org/info/rfc8578>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
[RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time-
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>.
[RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker,
"Deterministic Networking (DetNet) Security
Considerations", RFC 9055, DOI 10.17487/RFC9055, June
2021, <https://www.rfc-editor.org/info/rfc9055>.
[RFC9317] Holland, J., Begen, A., and S. Dawkins, "Operational
Considerations for Streaming Media", RFC 9317,
DOI 10.17487/RFC9317, October 2022,
<https://www.rfc-editor.org/info/rfc9317>.
[RFC9372] Mäurer, N., Ed., Gräupl, T., Ed., and C. Schmitt, Ed.,
"L-Band Digital Aeronautical Communications System
(LDACS)", RFC 9372, DOI 10.17487/RFC9372, March 2023,
<https://www.rfc-editor.org/info/rfc9372>.
[SESAR] SESAR, "SESAR Joint Undertaking",
<https://www.sesarju.eu/>.
Nils Mäurer, Thomas Gräupl, and Corinna Schmitt have contributed significantly to this document, providing input for the Aeronautical communication section. Rex Buddenberg has also contributed to the document, providing input to the "Instrumented Emergency Medical Vehicles" section.
NilsMäurer、ThomasGräupl、およびCorinna Schmittは、この文書に大きく貢献し、航空通信セクションの入力を提供しています。Rex Buddenbergもこの文書に貢献し、「緊急医療車両」セクションに入力を提供しています。
The authors would like to thank Toerless Eckert, Xavi Vilajosana Guillen, Rute Sofia, Corinna Schmitt, Victoria Pritchard, John Scudder, Joerg Ott, and Stewart Bryant for their valuable comments on draft versions of this document.
著者は、Toerless Eckert、Xavi Vilajosana Guillen、Rute Sofia、Corinna Schmitt、Victoria Pritchard、John Scudder、Joerg Ott、およびStewart Bryantに感謝します。
The work of Carlos J. Bernardos in this document has been partially supported by the Horizon Europe PREDICT-6G (Grant 101095890) and UNICO I+D 6G-DATADRIVEN-04 project.
この文書におけるCarlos J. Bernardosの作業は、Horizon Europe Predict-6G（助成金101095890）およびUnico I D 6G-Datadriven-04プロジェクトによって部分的にサポートされています。
Carlos J. Bernardos (editor)
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Madrid
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Georgios Papadopoulos
IMT Atlantique
Office B00 - 114A
2 Rue de la Chataigneraie
35510 Cesson-Sevigne - Rennes
France
Phone: +33 299 12 70 04
Email: georgios.papadopoulos@imt-atlantique.fr
Pascal Thubert
Cisco Systems, Inc
Building D
45 Allee des Ormes - BP1200
06254 MOUGINS - Sophia Antipolis
France
Phone: +33 497 23 26 34
Email: pthubert@cisco.com
Fabrice Theoleyre
CNRS
ICube Lab, Pole API
300 boulevard Sebastien Brant - CS 10413
67400 Illkirch
France
Phone: +33 368 85 45 33
Email: fabrice.theoleyre@cnrs.fr
URI: https://fabrice.theoleyre.cnrs.fr/